ICX150 Rev0419 SG L

ICX 150
Ruckus ICX Implementer
Student Guide
Revision 0419
Copyright © 2019 Ruckus Networks, an ARRIS company All rights reserved.

350 West Java Dr., Sunnyvale, CA 94089 USA
All or some of the products detailed in this document may still be under development and certain
specifications, including but not limited to, release dates, prices, and product features, may
change. The products may not function as intended and a production version of the products may
never be released. Even if a production version is released, it may be materially different from the
pre-release version discussed in this document.
Nothing in this document shall be deemed to create a warranty of any kind, either express or
implied, statutory or otherwise, including but not limited to, any implied warranties of
merchantability, fitness for a particular purpose, or non-infringement of third-party rights with
respect to any products and services referenced herein.
The Ruckus, Ruckus Wireless, Ruckus logo, Big Dog design, BeamFlex, ChannelFly, Xclaim, ZoneFlex
and OPENG trademarks are registered in the U.S. and other countries. Ruckus Networks,
MediaFlex, FlexMaster, ZoneDirector, SpeedFlex, SmartCast, SmartCell, and Dynamic PSK are
Ruckus trademarks worldwide. Other names and brands mentioned in this document or website
may be claimed as the property of others. 18-1-B
Revision: April, 2019

ICX 150 Introduction
ICX 150
Revision 0419
Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved
Revision 0419 1 ‐ 1
Module 1:
Course Introduction
Revision 0419
We’ll begin with an overview of the course content.
Legal Disclaimer
All or some of the products detailed in this presentation may still be under development and
certain specifications, including but not limited to, release dates, prices, and product
features, may change. The products may not function as intended and a production version
of the products may never be released. Even if a production version is released, it may be
materially different from the pre‐release version discussed in this presentation.
Nothing in this presentation shall be deemed to create a warranty of any kind, either express
or implied, statutory or otherwise, including but not limited to, any implied warranties of
merchantability, fitness for a particular purpose, or non‐infringement of third‐party rights
with respect to any products and services referenced herein.
The Ruckus, Ruckus Wireless, Ruckus logo, Big Dog design, BeamFlex, ChannelFly, Xclaim,
ZoneFlex and OPENG trademarks are registered in the U.S. and other countries. Ruckus
Networks, MediaFlex, FlexMaster, ZoneDirector, SpeedFlex, SmartCast, SmartCell, and
Dynamic PSK are Ruckus trademarks worldwide. Other names and brands mentioned in this
document or website may be claimed as the property of others. 18‐1‐B
Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved 3
Please take a moment to review our legal disclaimer, then advance to the next slide
Course Overview
• This self‐paced, web‐based training course concentrates on the Implementor functions
within a network environment and focuses on the Ruckus ICX series of switches
• Features and functions covered in this course include, Ruckus technologies, hardware
architecture, software upgrades, basic CLI configuration, layer 2 feature configuration
along with device access and security
This self‐paced, web‐based training course concentrating duties performed by an network
Implementor within a typical network environment and focuses on the Ruckus ICX series of
switches running FastIron 8.0.90.
Features and functions covered in this course include, Ruckus technologies, hardware
architecture, software upgrades, basic CLI configuration, layer 2 feature configuration along
with device access and security.
Course Objectives
• After completing this course, attendees should be able to:

– Understand Ruckus technologies and how to access the resources available
– Discuss the available ICX hardware and their capabilities
– Discuss the major features and functions of Ruckus ICX switches
– Understand hardware configurations for Ruckus ICX switches including stacking
– Describe the Command Line (CLI) structure of Ruckus ICX switches
– Describe the different methods available for device management including, the console port, Telnet, SSH,
and web management
– Use Authentication, Authorization, and Accounting (AAA) to secure a Ruckus ICX switch
– Describe the software upgrade process for Ruckus ICX switches
– Configure Virtual LANs (VLANs) and Link Aggregation Groups (LAGs)
– Configure interface settings including, name, VLAN association, speed and duplex, and PoE capabilities
– Describe and configure Spanning Tree Protocol (STP) features supported on Ruckus ICX switches
– Describe the features and function of Multi-Chassis Trunking (MCT)
– Describe and configure the Power over Ethernet capabilities of Ruckus ICX switches
– Describe and configure Campus Fabrics
Let’s take a look at the objectives for this course.
After completing this course, attendees should be able to:
Understand Ruckus technologies and how to access the resources available
Discuss the available ICX hardware and their capabilities
Discuss the major features and functions of Ruckus ICX switches
Understand hardware configurations for Ruckus ICX switches including stacking
Describe the Command Line (CLI) structure of Ruckus ICX switches
Describe the different methods available for device management including, the console
port, Telnet, SSH, and web management
Use Authentication, Authorization, and Accounting (AAA) to secure a Ruckus ICX switch
Describe the software upgrade process for Ruckus ICX switches
Configure Virtual LANs (VLANs) and Link Aggregation Groups (LAGs)
Configure interface settings including, name, VLAN association, speed and duplex, and
PoE capabilities
Describe and configure Spanning Tree Protocol (STP) features supported on Ruckus ICX
switches
Describe the features and function of Multi‐Chassis Trunking (MCT)
Describe and configure the Power over Ethernet capabilities of Ruckus ICX switches
Describe and configure Campus Fabrics
Course Modules
• Course Introduction
• Ruckus ICX Technologies
• Hardware Overview
• CLI Basics
• Software Upgrade & Licensing
• Access and Management
• Security and Monitoring
• Layer 2 Fundamentals
• Layer 2 Redundancy
• ICX Stacking
• Power over Ethernet (PoE)
• Ruckus ICX Campus Fabric
This course is composed of the following course modules:
Course Introduction
Ruckus ICX Technologies
Hardware Overview
CLI Basics
Software Upgrade & Licensing
Access and Management
Security and Monitoring
Layer 2 Fundamentals
Layer 2 Redundancy
ICX Stacking
Power over Ethernet (PoE)
Ruckus ICX Campus Fabric
Course Prerequisites
• Before taking this course, attendees should have foundational knowledge of:
– Network management protocols and their function including:
• Telnet/SSH
• SNMP
• sFlow
– Network features:
• Routing/switching
• VLAN
• Link aggregation (LAG)
• PoE
– Network protocols including:
• STP
• 802.1Q
• LACP
• 802.1X
• CDP/LLDP
The prerequisites for this course include:
Knowledge of Ruckus IP hardware and its designated roles in a network along with Network
management protocols and their function such as Telnet or SSH, SNMP and sflow.
Knowledge for network functions and features such as a general understanding of
Routing/switching along with specific functions such as VLANs, Link Aggregation (LAGs) and
Power over Ethernet
Because this course does not go into detail on how various protocols function along with
their purpose it is good for students to have a working knowledge of L2 protocols an
functions such as Spanning Tree, VLAN tagging, Link Aggregation Control Protocol, 802.1X
security and neighbor discovery protocols like Cisco Discovery Protocol or Link Layer
Discovery Protocol.
Network protocols including:
• STP
• 802.1Q
• LACP
• 802.1X
• CDP/LLDP
End of Module 1:
Course Introduction
Revision 0419
This concludes the Course Introduction and encourage you to move on to the next module
to continue this ICX Implementor course. Thank you.
ICX 150 ICX Technologies
Module 2:
Ruckus Technologies
Revision 0419
Welcome to the ICX 150 Implementer course. This course consists of 12 modules

and is based on the FastIron 8.0.90 software release. Subjects discussed in this
course concentrate on the Implementor functions within a network
environment however does not represent all functions or capabilities of an ICX
switch. In this module we will provide an overview of Ruckus technologies and
resources available.
So, let’s get started
Objectives
• In this module, you will learn
– Ruckus products overview
– Ruckus resources
– Ruckus technologies
When you first start to learn about the Ruckus product line, the range and diversity of
choices can seem confusing.
It’s important to know the different hardware and software options Ruckus provides
ensuring seamless integration of any implementations you many be planning.
In this section you will learn about the main Ruckus products and technologies, as well as
additional tools.
Ruckus Products Overview
Lets first take a look at Ruckus products and solutions.
Ruckus SmartZone and Wireless Products
Controllers
SZ300 vSZ SZ100 Series ZoneDirector Unleashed Cloud Wi‐Fi
INDOOR AP High Density Enterprise Small Business
R7xx Series R6xx Series R5xx Series R3xx Series H5xx Series
OUTDOOR AP
The Ruckus SmartZone products are Wireless LAN Controllers that provide management
and control for Ruckus ZoneFlex indoor and outdoor Access Points.
The Ruckus controllers are:
• SmartZone 300 – can support up to 10,000 Access Points per node, and 30,000 in a
cluster, running SmartZone in High Scale mode.
• Virtual SmartZone – Virtualized versions of the SmartZone controllers, both High
Scale and Essentials.
• SmartZone 100 – managing networks up to 1,024 Access Points, or 3,000 in a cluster,
running SmartZone in Essentials mode.
• ZoneDirector ‐ manages small networks of up to 150 Access Points. The ZoneDirector
is not classed in the SmartZone product line. It’s included here as it’s important to
know that a ZoneDirector’s configuration can be imported into a SmartZone
controller.
• Unleashed – Offers management of a small group or organizations supporting of up
to 50 APs without the need of a dedicated controller. This is perfect for small
deployments in retail and small offices potentially supporting up to 1024 client
devices. Unleashed also has dedicated mobile apps to allow for easy provisioning and
management.
• Cloud ‐ Ruckus Cloud Wi‐Fi simplifies deployment, monitoring and management of
your distributed wireless network.
• Simply put, Ruckus controllers manage Ruckus Access Points providing a solution for
every deployment scenario from Small Business WLANs to mission‐critical, high‐
density carrier grade installations.
Indoor APs provide solutions for a wide range of environments including small offices to
large scale high density deployments such as stadiums. Each were designed to provide a
unique solution for each environment they are deployed providing the best technologies
for high performance.
Ruckus Outdoor Access Points are used in a range of environments
• mounting and antenna options to suit your needs
• Outdoor Point‐to‐Bridges provide connectivity between remote sites.
For a full overview of all of these Ruckus products, please refer to the Ruckus website for
more details.
Ruckus ICX 7000 Switch Portfolio – Overview
Aggregation/Core
ICX 7850
Access Premium Aggregation‐Core
ICX 7750
Aggregation‐Core
ICX 7150 Z‐Series ICX 7650
Entry‐Level Access
Premium Access‐Aggregation + Highest Performance
High Availability + Campus Fabric
ICX 7450
Price/Performance
Multi‐gigabit (2.5 GbE) + MCT
Access‐Aggregation + Highest Performance
Price/Performance
+ Campus Fabric CB + 10G/25G/40G/100G
+ MCT Aggregation
ICX 7250 + 6.4 Tbps Switching
ICX 7150 + Higher Performance + 10G/40G Aggregation Capacity
Access + 40G/100G Uplinks + Medium‐to‐Large Core
+ Multigigabit 2.5/5/10G
PoE/PoE+ or non‐PoE
+ 10G Aggregation
+ Higher Performance
+ Hot‐swap PSU & Fans
+ L3: IPv4/IPv6, Multicast
+ L3: VRF/GRE + 1G Aggregation
+ EEE
Function and Scalability
ICX multi‐purpose switches can be deployed standalone, stacked or within a campus fabric.
Each were designed to provide a unique function inside a network infrastructure with
feature rich options and performance.
Along with CLI configuration and management of the ICX switches, SmartZone now has the
ability to manage the Ruckus ICX switch family as well.
SmartzoneOS5 offers Switch management features which include:
• Discovery and Inventory
• SNMP
• Monitoring
• Link discovery
• Software upgrades
• Backup and restore functions
And future releases of SmartZone will greatly expand the capabilities of switch
management
SmartZone provides organizations the ability to proactively monitor the network and
perform network‐wide:
• Troubleshooting
• Generate traffic reports
• Visibility into network activity from the wireless edge to the core
• Centralizes management of the entire family of Ruckus switches and wireless Access
Points with a single easy to deploy management platform
Cloudpath – Secure, Automated Device Enablement
https://www.ruckuswireless.com/products/smart‐wireless‐services/cloudpath
Many WLAN Administrators face the challenge of providing strong WLAN security, and for
many, the requirements of deployment can be complex and difficult.
Cloudpath is a security and policy management platform that offers control over users and
devices, and the provision of safe, secure WLAN access.
SPoT ‐ Smart Positioning Technology LBS
https://www.ruckuswireless.com/products/smart‐wireless‐services/location‐services
When commercial enterprises invest in WLAN deployments, they often want to maximize
their investment.
SPoT is Ruckus’ Location Based Solution. Data gathered in SPoT is used to allow venues to
understand the footfall traffic through their operational areas, and to engage directly with
customers.
SmartCell Insight – Big Data Wi‐Fi Analytics
https://www.ruckuswireless.com/products/smart‐wireless‐services/analytics
Ruckus SmartZone controllers provide an amount of reporting and reporting options for
Administrators. However, for very large‐scale deployments with hundreds, thousands, and
tens of thousands of Access Points, Administrators often require a deeper level of
information.
SmartCell Insight is designed for large‐scale service providers and integrators, and provides
Administrators the means to extract high level performance analytics, and monitor Key
Performance Indicators for mission critical networks.
ZonePlanner – RF Planning Tool
https://www.ruckuswireless.com/products/smart‐wireless‐services/rf‐planning
When new WLAN installation projects are being initiated, it’s vital to make structured plans
of the possible Access Point deployment.
ZonePlanner is a Ruckus software product that allows WLAN designers to make detailed
predictive maps of WLAN coverage before the installation begins. By predicting WLAN
coverage potential problems can be anticipated and corrected, and project spending can be
accurately assessed.
Ruckus Mobile Apps
https://www.ruckuswireless.com/products/mobile‐apps
SpeedFlex – Performance Testing
ZD Remote – Monitoring
SPoT – Location Analytics
SWiPE ‐ Provisioning
Ruckus Mobile Apps are available for Apple and Android devices and provide a number of
options for managing your networks.
Mobile Apps are dynamic and subject to frequent updates, so please ensure you check the
Ruckus website for the latest Ruckus Mobile App offerings.
SpeedFlex ‐ Is a wireless performance testing tool. Based on the open source
performance test tool, Zap, this comprehensive yet easy to use application from
Ruckus gives users a simple way to collect site performance data
ZoneDirector Remote ‐ Is a groundbreaking application that monitors and
configures Ruckus ZoneDirectors and Access Points.
SPoT ‐ generates operationally significant data that help businesses build an in‐
depth understanding of their venue and improve overall efficiency. Deployed on top
of Ruckus WLANs, Ruckus SPoT has flexible deployment options, doesn’t require
any additional hardware, and has unlimited scalability in the cloud.
SWiPE ‐ With Ruckus Smart Wireless Installation & Provisioning Engine (SWIPE), you
can easily register the Ruckus Access Points (APs) being managed by the Ruckus SZ
or vSZ.
Ruckus Resources
Lets take a look at the resources available to help inform and guide as well as provide the
latest software of all product lines.
Online Resources ‐ Rucktionary
https://www.ruckuswireless.com/rucktionary
The Rucktionary offers a short definition of a concept and then explains its relevance to
WLAN deployments.
Links are provided to help you see how the technologies relate to WLAN projects.
You can access the Rucktionary at https://www.ruckuswireless.com/rucktionary
Online Resources ‐ Ruckus Products
https://www.ruckuswireless.com/products
The best place to research Ruckus products is always the Ruckus website:
https://www.ruckuswireless.com/products
Here you will find the most up to date information on all of our products, including:
• Software and Software as a Service (SAAS) solutions
• System Management and Control
• Wi‐Fi Access Points
• ICX 7000 series Switches
You can also change the language and location of the website – selecting the globe icon will
show the available options.
Online Resources ‐ ICX Portfolio
https://www.ruckuswireless.com/products/ruckus‐icx‐family‐switches
You can further research Ruckus products by navigating directly to:
https://www.ruckuswireless.com/products/system‐management‐control/smartzone
By selecting one of the product ranges, you will be able to access and download more
resources that give you more details on each of the products including:
• Data Sheets
• At‐a‐Glance Sheet
Other resources will be available depending on the selection you choose.
Online Resources ‐ Support
https://support.ruckuswireless.com/
You can receive support documentation and firmware details on the Ruckus support site.
Upgrade Guides, Warranty & RMA as well as Knowledge Bases and Forums are accessible
on the support page. You can navigate directly to the support page by using the URL:
https://support.ruckuswireless.com/
Resources will be available depending on the selection you choose.
ICX Guide Zip Package
• Grouping of the most common documentation for the ICX family of switches supporting
the given release
– Documents are broken into logical guides providing details on a specific subject
– Examples:
• Layer 2 features
• Command References
• Security
• Stacking
• Monitoring
• Management
• Release notes along with a Feature Support Matrix are included
– Release notes are independent of the zip file
A Zip file is created for each release providing details of features that firmware provides. It
consists of a grouping of guides providing information of the features and their
configuration. Guides are broken into logical sections of the feature matrix of the release.
Each file included in the Zip are independently available on the Ruckus website however
using the Zip provides most all the guides needed to deploy an ICX switch.
Online Training – Introduction to Ruckus Products
https://training.ruckuswireless.com
The Ruckus Training website offers a complete range of self‐study courses that allow you to
learn at your own pace. Registration is free.
https://training.ruckuswireless.com
Without a doubt, the best course with which to begin your journey is Introduction to
Ruckus Products. This dynamic course offers a complete overview of Ruckus products and
technologies and is regularly updated to include new content.
Introduction to Ruckus Products is an essential course for Ruckus internal staff, partners
and end users.
Ruckus ICX Technologies
Lets now take a look at the Ruckus ICX technologies that provide superior performance and
solutions within a network environment.
ICX Stacking Advantages
• Standard Ethernet cables (not
proprietary)
• Long‐distance stacking—Up to 40 km
• Up to 12 units per stack
• In Service Software Upgrade (ISSU)
• Hitless failover of management
• Simple setup and deployment
Why Do You Care?
– Guided step‐by‐step walkthrough
• Greater scalability
– Zero Touch provisioning • Reduced costs
• No additional cost • Stacking cables
• Stacking modules/licenses
– No optional modules required
• Simpler management
– No dedicated stacking‐only ports • Flexible deployment
– No license add‐on required • High availability
Most switch vendors offer stacking with their access switches.
We are the ONLY networking vendor that offers stacking technology that makes managing
your network “effortless”.
Our unique stacking technology allows customers to reduce management costs while
delivering the performance and scalability needed to meet today’s customer challenges
Our stacking technology is standards‐based using flexible 10GbE and 40GbE connectors for
stacking ports eliminating proprietary and costly approaches found in competitor solutions.
Using standard Ethernet cables, you can stack across long distances: between multiple
wiring closets, multiple floors, between buildings, up to 10km.
We support stacking up to 12 switches per stack. No other vendor offers more than 9, and
most are less than that.
ISSU across a stack, which allows for software upgrades to switches in a stack, one at a
time, with no downtime
We also provide continuous service delivery using our hitless stack member insertion and
removal.
And, stacking is “standard”, no extra costs
No dedicated ports just for stacking
No optional modules required for stacking.
No license add‐ons required.
Ruckus stacking technology provides the reliability, performance, and ease of ownership
customers demand.
Now you’d think all these premium capabilities would come at a high cost. If you were
looking at competitive solutions, you’d probably be right.
But not with Ruckus Campus Networking…
Greater scalability (up to 12 switches)
No extra costs for stacking or for expensive stacking cables
Simplified management and flexible deployment
High reliability
Stack Trunks
• Stack ports can be combined to form a single logical link (LAG/Trunk) to stack members
– Trunk consists of multiple stacking ports and is treated as one logical link
– Provides more bandwidth and better resilience than individually connected ports
• Stack trunks can be used in linear or ring topologies
― Supported on all ICX 7000 Series switches
― Stacking trunks can be configured as part of the stack
interactive‐setup process
Stack ports of the ICX switches can be configured as trunks acting as a single link known as
a stack trunk. This formation of a stack trunk not only provides link redundancy within a
stack port but also increases the bandwidth between the switch stack. Stack trunks can be
used in either a linear or ring topology switch stack and is supported on all of the ICX 7000
switches. Stack trunks can be configured independently or part of the interface setup
process when forming the switch stack.
Long Distance Stacking
• In a Ruckus distributed chassis topology, members are physically separated
– Distance between stacking members depends on the platform and type of media used and can be up to
40Km
Optics and Cable Documentation:
www.ruckuswireless.com
As we have seen, the distributed chassis architecture of the Ruckus ICX switches allows the
components to be spread across the entire campus—due to the use of long‐distance
optical links—yet, the whole system can be managed as a single entity.
Supported maximum distance depends on the platform or type of media used: the ICX
7150, 7250, 7450, and 7750 support up to 10km
Supported optics and cables can be found in the documentation for each device on our
Ruckus website at www.ruckuswireless.com
ICX 7450 IPsec VPN Module
• 1 module per switch
– Multiple modules per stack for redundancy
(1 active per stack)
• Hardware assisted AES‐128, AES‐256 and IKEv2
encryption
• Up to 20 IPsec tunnels per module
• 10Gbps total throughput, max 10G per tunnel
• FIPS certification and Suite‐B compliant
• Interoperates with any standard IPsec
implementation
When installed, only one IPsec VPN module can be active. However, a second can installed
for redundancy.
It provides hardware assisted AES‐128, AES‐256 and IKEv2 encryption over up to 20 IPsec
tunnels.
With 10Gbps of total throughput it offers a maximum of 10G per tunnel.
The module is Federal Information Processing Standards, or FIPS, certified and NSA Suite‐B
compliant.
It is also capable of interoperating with any standard IPsec implementation.
IPsec VPN Use Case 1
• Path isolation in a campus network for communities of interest
Headquarters Office:
IPSec Termination
Community C IPSec tunnel
ICX 7450 stacks in wiring closet Campus Network
with IPSec Service Module
One use case for the IPsec VPN solution is to provide isolation between different
communities of interest in the campus network. This allows complete traffic separation and
security of traffic as it transits the infrastructure network, between the wiring closets of
each community and the headquarters office or core. This insures no data capture
capability anywhere between the terminating endpoints of the individual IPsec tunnels.
IPsec VPN Use Case 2
• ICX 7450 stacks in branch offices; IPSec termination in central office
Branch Offices:
ICX 7450 stacks with
IPSec Service Module
Central Office:
IPSec Termination
Public Network
IPSec tunnel enables secure
connectivity from branch to private
or public clouds
Branch offices need to access resources in
central site securely
© 2017 RUCKUS WIRELESS, INC. COMPANY PROPRIETARY INFORMATION
Another scenario is to provide secure transmission between remote branch offices and the
central office. Each branch office is capable of terminating an IPsec tunnel, thus securing all
data transmissions across a public network, whether that be a provider network or the
public Internet. Not only does this solution provide branch‐to‐CO security, but also branch‐
to‐branch security through the CO.
Campus Fabric
• Collapses multiple network layers into a
single logical switch
– Flattens the network
– Eliminating deployment complexity
– Simplifies network management
• Creates large management domain
– Eliminates individual switch touch points
– Reduces configuration errors
• Combines premium and
entry‐level switches together
into a single logical switch
– Shares advanced Layer 2 and
Layer 3 (L2/L3) services
Based on open standard IEEE 802.1BR Bridge Port Extension technology, Ruckus
Campus Fabric integrates premium, mid‐range, and entry‐level switches by
collapsing the network access, aggregation, and core layers into a single domain
that shares services. Campus fabrics consist of two types of switch rolls known as
either a control bridge or a port extender providing increased resiliency and
simplified control of a network environment. More details of campus fabrics will be
discussed later in the course.
Multi‐Chassis Trunking 162_MCT.png
• Providing switch level redundancy in addition to the
link level redundancy provided by LAGs
– Provides an active‐active connection of connected devices for
increased capacity and forwarding
• Expands the features of LAGs by:
– Eliminates single point of failure
– Integrated loop detection
– Easy deployment without fundamentally changing the existing
architecture
– Sub second failure detection and allocation of traffic
• Currently supported on ICX 7750 and 7850
MCT is an enhancement to Link Aggregation Control Protocol (LACP), IEEE standard 802.3ad
and (802.1ax revision). MCT is supported on the ICX 7750 and 7850. Other ICX however can
be used to connect to the MCT cluster to provide device level redundancy for its clients.
A regular trunk or LAG is a switch‐to‐switch link that provides redundancy.
A Multi‐Chassis Trunk is a trunk that initiates at a single MCT‐unaware switch and
terminates at two MCT‐aware switches that form one MCT logical switch. From this picture
here, we can see that each of the MCT‐unaware switches on the left have a trunk going to
each of the MCT switches in the cluster. From the MCT logical switches point of view, these
trunks are a single trunk.
MCT is an Active‐Active network architecture. It provides high availability, high reliability
and provides efficient utilization of bandwidth. Compared with a regular trunk which
provides link‐level redundancy: If the trunk is one‐to‐one and the switch goes down, then
the whole connection is lost. In addition to port‐level redundancy, MCT provides switch‐
level redundancy by extending the trunk across two switches providing high availability.
Virtual Router Redundancy Protocol Enhanced
• VRRP is a standard protocol that provides the ability to provide IP gateway redundancy for
edge devices
– Secondary routers will monitor and take over routing if master gateway fails
• VRRP‐E is a Ruckus enhanced version of VRRP that addresses the limitations in the
standard protocol
– Features VRRP‐E provide over standard:
• Default gateway is always pingable
– Even when master gateway fails secondary routers will respond to ICMP requests
• More granular control of track port management
– Unlike the standard, multiple track ports (uplinks) can be monitored
– Provides the ability to configure a failover when a threshold has been reached
• Additional security is available allowing MD5 authentication
Virtual Router Redundancy Protocol provides failover protection of end devices IP gateway. In the
event of a failure of the gateway router other routers will take over and assume the gateway
routers duties. Virtual Router redundancy protocol enhanced is a Ruckus proprietary protocol that
is an improvement over the VRRP standard providing improved reliability and features to end
devices.
NOTE: VRRP‐E is supported in the full Layer 3 code only. It is not supported in the base Layer 3
code. VSRP can be used if full Layer 3 code is not installed.
Unified Firmware Image Upgrade
• Unified FastIron Image (UFI) was introduced in 08.0.80 which simplifies the upgrade
process of ICX switches
– Combines both the FastIron application image and boot code along with the FI signature
• Application image also now includes the PoE firmware
• From 08.0.80, it is now possible to update all the necessary software components in a
setup using one command
– The UFI is recommended for all image upgrades
• A stack can be upgraded using a UFI bundle, and all stack members are also upgraded
• The manifest Image will use the UFI to upgrade images in future releases
The UFI (which was introduced in 08.0.80) consists of the application image, the boot code
image, and the signature file, and can be downloaded in a single file. This provides the
ability to upgrade a FastIron switch with a single command simplifying the upgrade process.
Moving forward it is recommended to use the UFI process to upgrade images due to the
ease of use and the automation of code compatibility functions. Stacked switches can also
be upgraded using the UFI process which upgrades all switches in the stack. Beginning with
FastIron 08.0.90, any new ICX hardware platform (starting with the ICX 7850 ) will use only
UFIs.
Licensing
• Software licensing provides increased scalability and rapid deployment of hardware
– Permanent license can be ordered pre‐installed in a Ruckus device
– Ordered separately after delivery
• Self‐Authenticated Upgrade Licensing provides a “pay‐as‐you‐grow” capabilities
– SAU licensing allows you to upgrade or downgrade to a licensed feature set with a single command
• License options include:1
– Ports on Demand (PoD)
– Layer 3 Base Features (L3‐BASE)
– L3 Premium Features (L3 PREM)
– Media Access Control Security (Prem‐MACsec)
Flexible licensing allows organizations to optimize network performance based on
specific requirements by simply applying a software license. This eliminates the
need to pull and replace hardware equipment but instead simply add license to
your existing devices as your network grows or to simply provide additional features
that were not previously needed. This makes network or infrastructure upgrades
much easier and decreases downtime required to make these changes.
Footnote 1: License options are not available on all switch types. Refer to the ICX License
Guide for specific license available for each switch.
End of Module 2:
Ruckus Technologies
This completes the Ruckus technologies module. I encourage you to continue to the next
module of the ICX 150 Implementer course. Thank you.
ICX 150 ICX Hardware Overview
Module 3:
ICX Hardware Overview
Revision 0419
This module will provide an overview of Ruckus ICX Hardware.
Objectives
• After completing this module, attendees will be able to:
– Describe the evolution of the network
– Understand where in the network topology you would find different ICX switches
– Describe the different configurations available with each ICX switch model, including:
• ICX 7150
• ICX 7250
• ICX 7450
• ICX 7650
• ICX 7750
• ICX 7850
– Explain stacking, optic and cabling capabilities of Ruckus ICX switches
This module will describe the evolution of the network, and where in the network you
would find the different types of Ruckus ICX switches.
Then we will look a the different hardware configurations available within the ICX family
covering all of the models here.
Lastly, we will review some of the additional capabilities of ICX switches including stacking
capabilities, Ruckus optics and unique cabling options.
Building a New Network
Core
Problems:
• Complex network architecture,
Aggregation
with too many layers and
inactive links
• Many points of management
• High upfront and maintenance
Access
costs
• Underutilized chassis
• Forklift upgrades only
Lets begin with the evolution of the Campus network.
Traditionally, networks were deployed using chassis at the core, aggregation and access
layers. These networks tended to be large with many points of management.
Chassis are inherently big, bulky, and require a large up‐front investment. Typically, they
had unused capacity for anticipated growth.
Maintenance was difficult and expensive and upgrades were expensive as well. Once
maximum capacity was reached, upgrades could only be done through forklift upgrades.
Fixed Switches at Access Benefits
Core
Benefits:
• Scale‐out, “pay as you grow”
Aggregation
networking
• Greater scalability
Access • Flexible network
deployment options
• Lower power consumption
Enterprises are now commonly deployed using stackable switches at the access layer. They
offer more flexibility and can be deployed exactly where they are needed in the campus.
Ruckus has been a pioneer in delivering fixed access switches with open standards and
multi‐vendor support. The fixed‐switch and stackable design of the Ruckus ICX switches,
provides the flexibility that allows users to pay‐as‐you‐grow, with market‐leading
performance.
Customers can purchase what they need today and know that they will be able to easily
add switches, without requiring a forklift upgrade.
Fixed Switches at Aggregation & Core
Benefits:
Core • Lower up‐front capital
investment
Core &
Aggregation
• Scale‐out, “pay as you grow”
networking
• Increased scalability
• Distributed chassis with long
Access
distance stacking
• Reduced power, cooling and
footprint
The Ruckus distributed chassis technology collapses the aggregation and core layers using
the Ruckus ICX 7750 and 7850 switches. These aggregation/core switches deliver industry‐
leading 10 GbE, 40 GbE and 100 GbE port densities, advanced high‐availability capabilities,
and flexible stacking architecture, making it the most robust aggregation and core
distributed chassis switch offering for enterprise LANs. In addition to rich Layer 3 features,
both of these switch models scale to a 12‐unit distributed chassis stack or a Multi‐Chassis
Trunking (MCT) topology.
Though stacking distances depend on the ICX platform, optics, and cables used, the ICX
7750 and 7850 can form a distributed chassis of up to 40 kilometers.
Simplified Architecture with Campus Fabric
Benefits:
Campus Network as a Single Logical Domain
• Single point of
management & control
• Collapsed Core,
Aggregation and Access
• STP‐free Layer 2 design
• Edges switches inherit all
the features of the core
devices
• Greater scalability – over
1,700 ports in a single
system
• Flexible edge deployment
options for optimized cost
and performance
The Ruckus Campus Fabric (also known as Switch Port Extender) is the evolution of the
HyperEdge Architecture. It is based on the IEEE 802.1BR standard for Bridge Port Extension,
and it collapses multiple network layers into a single logical switch, flattening the network
and eliminating deployment complexity.
Campus Fabric simplifies network management. All switches are managed as if they are a
single switch. It offers a great opportunity for enterprises to replace aging legacy chassis
with Ruckus ICX switches and Campus Fabric technology, extending the life of their
network, and dramatically reducing total cost of ownership.
The Campus Fabric also eliminates the inefficiency of Spanning Tree Protocol. The entire
domain runs from a unified control and forwarding plane, eliminating the need to deploy a
loop avoidance protocol, or complex Layer 3 protocol like OSPF in the fabric domain.
Multi‐pathing is supported by design within a Campus Fabric domain. All links between
switches are active at all times, and traffic is load balanced, and optimizes performance,
while delivering fast failover recovery from link failure with no impact on network service.
Ruckus ICX 7000 Switch Portfolio – Overview
Aggregation/Core
ICX 7850
Access Premium Aggregation‐Core
ICX 7750
Aggregation‐Core
ICX 7150 Z‐Series ICX 7650
Premium Access‐Aggregation + Highest Performance
High Availability + Campus Fabric
ICX 7450
Price/Performance
Multi‐gigabit (2.5 GbE) + MCT
Access‐Aggregation + Highest Performance
Price/Performance
+ Campus Fabric CB + 10G/25G/40G/100G
+ MCT Aggregation
ICX 7250 + 6.4 Tbps Switching
ICX 7150 + Higher Performance + 10G/40G Aggregation Capacity
Access + 40G/100G Uplinks + Medium‐to‐Large Core
+ Multigigabit 2.5/5/10G
PoE/PoE+ or non‐PoE
+ 10G Aggregation
+ Hot‐swap PSU & Fans
+ L3: IPv4/IPv6, Multicast
+ L3: VRF/GRE + 1G Aggregation
+ EEE
Function and Scalability
Here we have all of the switches currently in the ICX 7000 series family. Starting from the
left we have our ICX 7150 series which offers entry‐level access capabilities offered with or
without Power‐over‐Ethernet (PoE) capabilities. In addition, the ICX 7150 Z‐series switches
offers 2.5 GbE capabilities at an entry‐level price. The next access‐level switch is the ICX
7250, which offers the same capabilities as the 7150 and then some, including Higher
performance throughput, advanced Layer2 capabilities including VRF and GRE. Moving up
in function and scalability, we have the ICX 7450 and 7650 switches. These are both
capable of operating in the access and aggregation space with hop‐swappable components
and high speed uplinks capabilities. An in the core space, the ICX 7750 and 7850 switches
provide the most enhanced capabilities, including Campus Fabric control bridge
functionality and Multi‐chassis trunking as well the support for 10, 40 and 100GbE
aggregation.
All of these options allow you to select the appropriate device to meet your current
requirements as well as the ability to grow to meet your future needs.
Hardware Overview
Now, lets take a deeper look at the hardware configuration for each switch in the ICX
product family.
We will start with the entry level devices and work our way up to the high end products.
ICX 7150 ‐ Overview
120W PoE 2xSFP+ and 2xUTP High performance and port density

Fanless budget uplink ports • 6 models with 12/24/48 ports and optional PoE/PoE+
• All downlink ports 10/100/1000 with PoE and PoE+
• 4 x 1/10G flexible uplink/stacking SFP+ ports
C12P • 2 x 1G UTP uplink ports
• Stack up to 12 units and 576 ports
• Any combination of switch versions (not compact)
24
High availability
24P • Redundant 10G Ethernet stack links
• Hitless stacking failover
Advanced scalability and features
48 • L2 and L3 features including STP/RSTP/MSTP and OSPF
48P • sFlow for granular network traffic accounting
48PF
Deployment flexibility
• 4 x 10G SFP+ ports configurable for stacking or uplinks
Optional fanless 370W (P) and 4xSFP+ and 2xUTP • 24/48 are fanless for quiet operation
mode 740W (PF) PoE uplink ports • Support for OpenFlow and Campus Fabric
budget options
• Optional fanless operation for 24P/48P (150W PoE budget)
Let’s start with a look at the ICX 7150.
The ICX7150 comes in seven hardware configurations. The first six are shown here:
• First is the compact 12 port (C12P) with PoE on all 12 ports, 2 ports of 10 Gigs, as
well as 2 additional ports with 1 Gig copper uplinks.
• Next, there is the 24 port (labeled 24) and 24 port PoE configuration (labeled 24P)
that has PoE+ capabilities on every port. It also has up to 370 Watts of PoE budget
that allows for 15.4 Watts of PoE assigned to all 24 ports. If one were to need 30
Watts of PoE+ assigned to the ports, this configuration provides up to 12 ports of
PoE+ power. To reiterate, this is a high value position because a lot of other similar
products in this category only offer 190 to 195 Watts of PoE budget assigned to their
24 port switches.
• Finally, there are three 48 port versions – non‐PoE (48), PoE (48P), and one (48PF)
that has double the PoE budget with 740 Watts. This provides 48 ports of 15.4 Watts
(802.3af PoE) assigned to every port. If one were to need 30 Watts of PoE+ power
assigned to the ports, this configuration can allow up to 24 ports.
ICX 7150‐48ZP
High performance and port density
• 16 x 1/2.5G ports with PoH
16x1/2.5G 32x10/100/1G 8xSFP+ • 32 x 10/100/1G ports with PoE+
PoE/PoE+/PoH PoE/PoE+ Stacking/Uplink
• 4 x 1/10G uplink SFP+ ports
• Stack up to 12 units with other ICX7150 family members
High availability
• Redundant PSU and fans
• Redundant 8x10G Ethernet stack/uplinks
• L2 and L3 features
• Campus Fabric PE capabilities
Dual Fan Trays Dual PSU

Up to 1480W PoE • 8 x 10G SFP+ ports configurable for stacking or uplinks
budget • Support for OpenFlow and Campus Fabric
• PoE power budget 1xPSU: 820W 2xPSU: 1480W
The 48‐port “Z‐Series” adds Multi‐gigabit (2.5G), high availability and higher performance
for 802.11ac and ac Wave 2 deployments.
The ICX 7150 Z‐Series, 48‐port switch adds:
• Multi‐gigabit technology, with 16 2.5G ports.
• Dual, hot‐swap power supplies and fans
• An impressive PoE budget
• Stacks with the rest of the ICX 7150 switch family.
ICX 7150‐C12P – LEDs
Status button is pushed to cycle through LEDs light in Amber or Green to
different interpretations of the Port display status of the System,
LEDs, including: Link, Speed, Member ID, Master/Slave, SW Update,
USB status and PoE status Diagnostics, Cloud Management
and Power
View the ICX 7150 Hardware Installation Guide for interpreting each of these LEDs
The LEDs on the ICX 7150‐C12P provide valuable insight into the operations of the switch.
Above the management interface there are LEDs to indicated the status of the Operating
System, the master/slave status if the unit is a member of a stack, a software update,
diagnostics and power. There is also an LED, intended for future use, to indicate if the
device is cloud managed.
On the left near the console port status LED section. There is a button that changes what
the status of the port LEDs represent. It cycles through various statuses including port link,
port speed, stack member ID, USB and PoE status.
Full interpretation of each of these LEDs is available in the Ruckus ICX 7150 Switch
Hardware Installation Guide, found on the Ruckus Networks web site.
ICX 7150‐24/48/P – LEDs
and Power
The LEDs on the ICX 7150‐24‐port, 48‐port and their PoE derivatives provide the same
valuable insight as the 7150‐C12P. There is no difference in the available LEDs or their
interpretation. The only difference is the placement on the front of the unit.
Full interpretation of the LEDs for all ICX 7150 devices can be found in the Ruckus ICX 7150
Switch Hardware Installation Guide, found on the Ruckus Networks web site.
ICX 7150 – Hardware‐based Factory Reset
• The RESET button on the front of the ICX 7150 can be used to
perform a factory reset of the switch
– This is applicable from R08.0.70 and later
• Perform the following steps to perform hardware‐based
factory reset
1. Remove power from the switch.
2. Press and hold the reset button and apply power to the switch.
3. Release the reset button after all of the system LEDs flash amber.
– When all the system LEDs blink green, all the configuration data is being
erased and the switch is returned to its factory configuration
– When all the system LEDs are solid green, the erase process is complete
and the system will reload
– Once reloaded and the SYST LED is steady green the factory reset is
complete
Another feature of all of the ICX 7150 switches is the ability to perform a factory default
reset from the front of the switch. The button is recessed and can only be depressed with a
small tool, like a paperclip. The functionality of this button was first enabled with release
8.0.70.
The button‐press factory default process is fairly simple and requires no management/CLI
connection the switch as the LEDs will indicate each phase of the reset process.
To initiate the factory reset, simply remove power from the device. Next, press and hold
the reset then apply power again. Keep the button pressed until all of the System LEDs flash
AMBER, then release it. At this point the system will begin the factory reset. All of the
system LEDs will blink green when all of the configuration data is being erased, returning
the switch to its factory configuration. The system LEDs will turn solid GREEN when the
erase process is complete and then the system will reload. Once reloaded a solid GREEN
SYST LED indicates completion.
10/100/1000 Ports 8 x 1/10G integrated
• 4 models with 24/48 ports and optional PoE/PoE+
PoE, PoE+ SFP+ ports
• 80G stacking bandwidth
• Stack up to 12 units and 576 ports
24 • Any combination of switch versions
24P
High availability
• Redundant 10G Ethernet stack links
48
• Optional external redundant PSU shelf
48P
• Up to 16 switches monitored per EPS shelf
• L2 and L3 features
EPS • Campus Fabric PE capabilities
• 8 x 10G SFP+ ports configurable for stacking or uplinks
Quad Modular Supports up to • Support for EEE. OpenFlow 1.3
PSU Trays 16 x 7250
switches
The ICX 7250 Switch is our “work horse” access switch. All ICX 7250 models provide either
24 or 48 1Gbps Ethernet connectivity.
Each of the models are equipped with 8x1/10G uplink/stacking ports for high throughput
stack capabilities.
Additionally the “P” models provide PoE+ capabilities to supply current to many devices
including IP phones and Wi‐Fi access points.
It delivers higher performance than the ICX 7150, with up to 8 10G uplink ports, more Layer
3 features and Energy‐Efficient Ethernet.
An external power shelf (EPS) is also available to provide redundant system power, as well
as additional PoE power. While not hot‐swappable, you can use any of the 4 external power
supplies in it to backup up to 16 switches.
ICX 7250 – LEDs
• The ICX 7250 has System and Port‐level LEDs indicators
• System LEDs to indicate status of:
– Power Supply
– External Power Supply (EPS)
• ICX 7250‐48P supports two EPS
• All others support only one
– Diagnostics
– Master/Slave
– Uplink
– Downlink
– Stack Unit ID
• Port LEDs indicate:
– Valid link and TX/RX
– PoE status
The LEDs on the ICX 7250 provide valuable insight into the operations of the switch. There
LEDs for power status, both local and power from an External Power Supply (EPS). Note
that only the ICX 7250‐48P supports connecting to two EPS devices and is the only device
with two EPS LEDs. Diagnostic LED indicates if the system is in diagnostic mode. The
remaining LEDs provide insight when the unit is operating in a stack. These indicate master
slave status, uplink and downlink port status and the unit’s stack ID. You may notice that
there are only 10 LEDs but the 7250 has ability to have 12 units in a stack. In the case of
unit IDs higher than 10, the 10+ LED and the 1 or 2 LED will be lit, indicating unit ID 11 or
12, respectively.
In addition to these, LEDs on each port indicate link status, activity and PoE status.
ICX 7450 – Overview
1 x Module Slot
4x1G SFP
4x10G SFP+
PoE, PoE+, PoE++
4x10G Copper • 5 models supporting 24/48 POE+ and 48‐port SFP
and PoH
1x40G* • 8 ports of PoE+ (65W) and PoH (95W)
• Flexible uplink modules
24
24P • 2 x 40G QSPF+ stack connections, 160G stack bandwidth
24
24P • Stack up to 12 units and 576 PoE ports
48 • Any combination of port types
48 48P High availability
48P • Hitless stacking failover and redundant 40G stack links
48F • Redundant hot‐swap load‐sharing power supplies and fans
48F Advanced scalability and features
• L2 and advanced L3 features
• Campus Fabric PE capabilities
• AC or DC power
• Reversible front‐to‐back or back‐to‐front airflow
2 x Module Slots
Dual Modular • 10G or 40GbE uplink and stacking options
4x10G SFP+ Dual Modular Power Supply • Support for EEE, MACsec, IPsec and OpenFlow 1.3
4x10G Copper Fan Trays AC/DC
1x40G
The ICX 7450 delivers high performance and flexibility with a backbone of up to 40G. It can
serve as a high‐end access switch or as an aggregation device. Its unique design includes 3
modular slots that can be used for 1G, 10G or 40G uplink/stacking ports. There’s also an
IPsec encryption module for security‐minded customers.
The ICX 7450 also offers dual hot‐swap power supplies and fans, MACsec, Energy Efficient
Ethernet (EEE) and advanced Layer 3 features. A truly premium access switch.
The ICX7450 comes in five basic configurations that are primarily differentiated based on
the port density (i.e. 24 port and 48 port) and the PoE/PoH capabilities (i.e. with PoE/PoH
and without PoE).
• The first is the ICX7450‐24 that has 24x10/100/1000 Mbps RJ‐45 ports. This does not
support PoE.
• Second is the ICX7450‐24P that features 24×10/100/1000 Mbps RJ‐45 PoE+ ports
with eight pre‐assigned ports supporting PoH (90 W). These ports are identified by
the yellow markings above/below the ports.
• The next three models, the ICX 7450‐48, the 48P, and the 48F have 48 port density.
The ICX 7450‐48 does not have PoE capability. It has 48×10/100/1000 Mbps RJ‐45
ports. The ICX 7450‐48P has 48×10/100/1000 Mbps RJ‐45 PoE+ ports with eight pre‐
assigned ports supporting PoH (90 W), again indicated by yellow markings. The
ICX7450‐48F comes with 48×100/1000 Mbps SFP ports.
ICX 7450 Interface Modules
ICX7400‐1X40GQ ICX7400‐4X10GF ICX7400‐4X10GC ICX7400‐4X1GF
Bandwidth 80Gbps 80Gbps 80Gbps 8Gbps

Port Type 1x40GE QSFP+ 4x10GE SFP+ 4x10GE RJ‐45 4x1GE SFP
Front (24) or
Module Slot Front or Rear Front or Rear Front only
Rear (24/48)
Stacking (front)
Stacking (rear),
Function Uplink with MACsec Uplink Uplink
Uplink
LRM optic support
Here we have the interface modules for the ICX7450. They offer 1, 10 or 40Gigabit Ethernet
connectivity options. Some have specific installation location requirements, that are based
on interface type as well as location on the switch, either on the front or the back of the
unit. Two offer stacking as well as uplink capabilities while the remaining two only offer
uplink.
• Industry first hardware based IPsec solution for
stackable switch
• Flexible deployment, can encrypt traffic from/to
any stack port
• Rich feature set
– IPv4 unicast, OSPF, QoS, PBR, VRF, ACL and Jumbo frames
supported on IPsec tunnels
• Futureproofing via field‐upgradeable FPGA based
Packet Processor
The ICX 7450 IPsec VPN module is the industry’s first hardware based IPsec solution for
stackable switch.
It is capable of encrypting traffic to or from any stack port on the switch.
It supports a vast number of features over the IPsec tunnel, including: IPv4 unicast, OSPF,
QoS, PBR, VRF, ACL and Jumbo frames.
The module is future‐proofed by leveraging a field‐upgradeable Field Programmable Gate
Array (FPGA) based Packet Processor.
• 1 module per switch
– Multiple modules per stack for redundancy
(1 active per stack)
• Hardware assisted AES‐128, AES‐256 and IKEv2
encryption
• Up to 20 IPsec tunnels per module
• 10Gbps total throughput, max 10G per tunnel
• FIPS certification and Suite‐B compliant
• Interoperates with any standard IPsec
implementation
When installed, only one IPsec VPN module can be active. However, a additional modules
can be installed for redundancy.
It provides hardware assisted AES‐128, AES‐256 and IKEv2 encryption over up to 20 IPsec
tunnels.
With 10Gbps of total throughput it offers a maximum of 10G per tunnel.
The module is Federal Information Processing Standards (FIPS) certified and NSA Suite‐B
compliant.
It is also capable of interoperating with any standard IPsec implementation.
ICX 7450 – LEDs
• The ICX 7450 has System and Port‐level LEDs indicators
• Front System LEDs to indicate status of:
– Power Supply 1
– Power Supply 2
– Diagnostics
– Master/Slave
– Media Expansion Modules 2‐4
– Stack Unit ID
• Port LEDs indicate:
– Valid link and TX/RX
– PoE status
The LEDs on the ICX 7450 provide the same insights to switch operations as the ICX 7250
switch. There is an LED for power status of each hot‐swappable power supply and a
diagnostic LED indicates if the system is in diagnostic mode. There are LEDs indicating
Media Expansion Modules in slots 2‐4. And the remaining LEDs provide insight when the
unit is operating in a stack. These indicate master slave status, uplink and downlink port
status and the unit’s stack ID. Like with the 7250 when the unit ID is higher than 10, the 10+
LED and the 1 or 2 LED will be lit, indicating unit ID 11 or 12, respectively.
In addition to these, LEDs on each port indicate link status, activity and PoE status.
ICX 7650 Overview
4x10G, 2 x 40G, High performance and port density
1 x 100G uplink ports
• 48ZP: 1, 2.5, 5 and 10G copper downlinks
• 48P: 48 x 10/100/1G copper downlinks
• 48F: 1 and 10G fiber downlinks
48ZP • 10, 40 and 100G uplinks
• Stack up to 12 units via 40G or 100G links
• Any combination of port types
48P High availability
• Hitless stacking failover and redundant stack links
• Redundant hot‐swap load‐sharing power supplies and fans
48F Advanced scalability and features
• Campus Fabric CB/PE capability
• L2 and advanced L3 features including BGP and VRF
• sFlow for granular network traffic accounting
Dual Fixed 2 x 100G or Dual Modular • AC or DC power
Modular 4x40G AC or DC • PoE overdrive
Fan Trays stacking/uplink Power • Reversible front‐to‐back or back‐to‐front airflow
Ports Supplies
• Support for MACsec256, EEE and OpenFlow 1.3
The ICX 7650 can serve as a premium access switch or a medium core/aggregation switch.
There are three models in this family:
• First is the ICX 7650‐48ZP, where the “Z” indicates is its compliance to the IEEE
802.3bz Multigigabit standard. It has 24 Multigigabit 2.5/5/10G ports, each with PoE
up to 90Watts (compatible with the 802.3bt standard, as well as compatible with
60W PoE). Plus an additional 24 x 1G ports, with PoE+.
• Next is the ICX 7650‐48P that has 48 x 1G ports with PoE+, 8 of those supporting up
to 90W of PoE power.
• Lastly, ICX 7650‐48F model offers a medium core/aggregation switch with fiber
connectivity via 24 x 10G ports, plus 24 1G ports.
All of the ICX 7650 switches offers fully redundant, hot‐swappable load‐sharing AC or DC
power supplies and fans.
ICX 7650 Interface Modules (Front ‐ Optional)
ICX7650‐1x100GQ ICX7650‐2X40GQ ICX7650‐4x10GF
1 × 40/100 GbE 2 x 40 GbE 4 × 10 GbE

Port Type QSFP28 QSFP+ SFP+
Module Slot Front Front Front
Function Uplink Uplink Uplink
Bandwidth 100 Gbps 80 Gbps 40 Gbps
Here we have the interface modules for the ICX7650. They offer 10, 40 and 100 Gigabit
Ethernet connectivity options. All are installed in the front module slots of the switch and
provide uplink functionality only, as stacking is accomplished through the fixed ports on the
rear of the switch.
ICX 7650 – LEDs
• ICX 7650 LEDs and interpretations are similar to ICX 7150
and Power
The LEDs on the ICX 7650 are very similar to the LEDs on the ICX 7150 platform. To the right
of the console interface there are LEDs to indicate the status of the Operating System, the
master/slave status if the unit is a member of a stack, a software update, diagnostics and
power. There is also an LED, intended for future use, to indicate if the device is cloud
managed.
On the left near the console port status LED section. There is a button that changes what
the status of the port LEDs represent. It cycles through various statuses including port link,
port speed, stack member ID, USB and PoE status.
48F • 3 models supporting 10G fibre and copper plus 40G QSFP+
• 6 x QSFP+ 40G module
• Up to 12 x 40G QSPF+ stack connections, 5.76T stack bandwidth
48C • Stack up to 12 units and 576 10G ports
• Any combination of port types
High availability
26Q • Hitless stacking failover and redundant 40G stack links
• L2 and advanced L3 features including BGP and VRF
• Campus Fabric CB/PE capabilities
• AC or DC power
Non blocking • Support for OpenFlow 1.3
6 x 40G Dual Modular
2Tbps switch
Module Slot Power Supply
capacity
AC/DC
The ICX 7750 is the first of our Aggregation and Core layer switches.
It is designed to compete in the data center and the campus aggregation and core market.
The high‐port density distributed chassis system architecture is one of the most important
features that makes the ICX7750 such a robust asset in these network segments.
The ICX7750 comes in three basic configurations:
• First is the ICX 7750‐48F that features 48, 1/10 GbE SFP+ ports and 6, 40 GbE QSFP+
ports that can each be split into 4×10 GbE SFP+ ports.
• Next is the ICX 7750‐48C. This comes with 48 x 10GBASE‐T ports and 6 x 40 GbE
QSFP+ ports that can each be split into 4×10 GbE SFP+ ports.
• Lastly, we have the ICX 7750‐26Q that features 26 x 40 GbE QSFP+ ports that can be
split into as many as 96 x 10 GbE SFP+ ports.
It is a 10 and 40GbE (Gigabit Ethernet) switch in a 1RU form factor for campus aggregation
and core applications. It provides the chassis‐level reliability using Ruckus’ High Availability
(HA) stacking technology. It also offers hitless stack failover, In‐Service Software Upgrade
(ISSU), hot‐swappable power supplies, fan trays, and a plug‐in module. In addition, it has
market‐leading density, physical and logical redundancy, and a highly efficient cooling
design. It also provides low‐latency, cut‐through routing, non‐blocking architecture with
excellent scalability. All these features make the ICX 7750 very suitable for data center
applications.
ICX 7750 – LEDs
• Each ICX 7750 has the same
System Status LEDs, containing:
– Power Supply 1
– Power Supply 2
– Master/Slave
– Diagnostics
– High Availability
Upper port
– Redundant 4x10/40GbE QSFP+ 1/10GbE SFP+
• Port Status LEDs vary by model
– Green and Amber LEDs indicate Link and Speed
1/10GbE RJ‐45
Lower port
The LEDs on the ICX 7750 provides valuable insight into switch operations. There is an LED
for power status of each hot‐swappable power supply and a diagnostic LED indicates if the
system is in diagnostic mode. There are LEDs indicating master/slave status in a stack, the
presence of redundant power supplies and fans and High Availability operation.
In addition to these, LEDs on each port indicate link status, activity and PoE status. These
LEDs vary by model, therefor for full interpretation of each of these LEDs view the Ruckus
ICX 7750 Switch Hardware Installation Guide, found on the Ruckus Networks web site.
• Up to 32x 40/100 GbE ports per switch
32Q • Up to 8x 40/100GbE standard QSFP28 stacking ports
• Up to 8x 100 GbE stacking ports, 1.6 Tbps of stacking bandwidth
per switch
High availability
• Hitless stacking failover and redundant 10G and 40G stack links
48F/FS • L2 and advanced L3 features including BGP and VRF
• sFlow for granular network traffic accounting
• AC or DC power
• Support for OpenFlow 1.3
Modular Fan Dual Modular • MACSec for data privacy and EEE for power efficiency
Trays Power Supply
AC/DC
The ICX 7850 switches offer 40GbE and 100GbE for maximum performance in the
aggregation and core layers as well as highly efficient top of rack switches in datacenters. If
offers up to 32x 40/100 GbE ports per switch and up to 8x 100 GbE stacking ports, resulting
in 1.6 Tbps of stacking bandwidth per switch. The ICX 7850 can deliver the performance
and scalability required by future generations of wireless access points, IoT and LTE devices.
It provides highly efficient core switching with redundant, hot‐swappable power supplies
and fans, In‐Service Software Upgrades (ISSU), Multi‐Chassis Trunking (MCT) for core
failover with load‐balancing, and hitless stack insertion and removal.
It supports advanced IPv4 and IPv6 routing functionality including, BGP, OSPF, VRRP, PIM,
PBR, VRF.
The ICX 7850 comes in three models:
• The ICX 7850‐48F stackable aggregation switches comes with 48x 1/10/25 GbE SFP28
ports and 8x 40/100 GbE QSFP28 ports for uplinks or stacking.
• The ICX 7850‐48FS stackable aggregation switches comes standard with 8‐QSFP28
ports for 40/100 GbE for stacking or uplinks and offers 48x 1/10 GbE fiber SPF+ ports
with MACsec and LRM.
• The ICX 7850‐32Q aggregation/core switch comes standard with 32 40/100 GbE
QSFP28 ports and up to 8 of these ports can be used for stacking. The QSFP28 ports
are capable of native 40 GbE or 100 GbE Ethernet, or may be broken out to 4x10
Gbps or 4x25 Gbps links to give up to 128 10/25GbE ports for server aggregation in a
Data Center, or switch aggregation in the campus.
ICX 7850 – Power and Cooling
Dual Hot Swap Power Supplies
Hot Swap N+1 Redundant Fan Trays AC or DC
Exhaust airflow or Intake airflow Exhaust airflow or Intake airflow
48F/FS
32Q
Dual Hot Swap Power Supplies
Hot Swap N+1 Redundant Fan Trays AC or DC
Exhaust airflow or Intake airflow Exhaust airflow or Intake airflow
Here we have a view of the back of the ICX 7850‐48F/FS and the ‐32Q devices. All models
offer 2x hot‐swappable load sharing power supplies and 5x hot‐ swappable fan assemblies
with reversible airflow options.
ICX 7850 – LEDs
• ICX 7850 LEDs and interpretations are similar to ICX 7150 and ICX 7650
and Power
The LEDs on the ICX 7850 are very similar to the LEDs on the ICX 7150 and 7650 platforms.
On the front of the switch are LEDs to indicate the status of the Operating System, the
master/slave status if the unit is a member of a stack, a software update, diagnostics and
power. There is also an LED, intended for future use, to indicate if the device is cloud
managed.
Again, there is group of LEDs with a button that changes what the status of the port LEDs
represent. It cycles through various statuses including port link, port speed, stack member
ID, USB and PoE status.
Reversible Airflow – ICX 7450, 7650, 7750 and 7850
• ICX 7450, 7650, 7750 and 7850 support reversable airflow options to support any
datacenter deployment
• Exhaust • Intake
– Standard airflow for pre‐configured versions of – Option for ICX 7450, 7650, 7750 and 7850
the ICX 7450, 7650, 7750 and 7850 – Can be changed to Exhaust by swapping ALL
– Can be changed to Intake by swapping ALL PSUs PSUs and fans
and fans
• ICX 7150 and 7250 have fixed exhaust airflow
Two airflow options are supported on the ICX 7450, 7650, 7750 and 7850. Air can flow as
exhaust, where air flows from the front of the unit to the back. Alternatively, it can operate
in intake mode where air flows from the back to the front.
It is important to note that the airflow must be consistent for all installed PSUs and fan
units, meaning they must all flow the same way.
Exhaust airflow PSUs and fans are labeled with a green, downward pointing arrow marked
with the letter “E”.
Intake airflow PSUs and fans are labeled with an orange, upward pointing arrow marked
with the letter “I”.
The ICX 7150 and 7250 switch are only offered with fixed power supplies and flow only in
exhaust mode, or front‐back
ICX 7150, 7650 and 7850 – Console Ports
USB console port
RJ45 console port
• USB Type‐C connector on switch
• Plug‐and‐Play
– Windows OS will install automatically
– MacOS will download the driver
• USB cable Type‐C to Type‐A
• Drivers for Windows, MacOS and Linux
available from
https://support.ruckuswireless.com
The ICX 7150, 7650 and 7850 switches offer two console connection options.
The first is a Type‐C USB connector on the switch. This allows the use of a Type‐C to Type‐A
cable to access the CLI. This connection option requires a driver be installed that allows
your devices USB port to operate as a serial interface. The driver can be found at:
http://support.ruckuswireless.com
An RJ‐45 interface is also provided for true serial connectivity. This allows connectivity to a
serial interface on the management device, typically a DB9 connector.
ICX 7250, 7450 and 7750 Console Port
Serial console port
• USB type connector on switch but it’s actually a serial
interface!
• Other end is an RJ45 connector and RJ45/DB9F adapter
The ICX 7250, 7450 and 7750 offer only a serial interface for connecting to the CLI. The
interface itself is a USB‐type connector, but only provides serial connectivity. Each unit is
shipped with a cable that connects to the switch interface, has an RJ54 connector that in‐
turn connects to an adapter that modifies the RJ45 to a DB9 female serial interface for
connecting to your management device’s serial port.
Stack Connections
Maximum Number of Stack Link Maximum Links Per Maximum Stack

Platform
Switches in a Stack Speeds Stack Trunk Bandwidth
ICX 7150 12 10G 2 x 10G 480Gbps
ICX 7250 12 10G 2 x 10G 480Gbps
ICX 7450 12 10G or 40G 2 x 10G or 1 x 40G 960Gbps
ICX 7650 12 40G or 100G 2 x 40G or 1 x 100G 1.128Tbps
ICX 7750 12 40G 6 x 40G 5.76Tbps
ICX 7850 12 40G or 100G 4 x 40G or 4 x 100G 9.6Tbps
Maximum Stack Bandwidth Calculation
Link speed x number of links per stack trunk x number switches in stack x Full Duplex
e.g. ICX 7250: 10G x 2 x 12 x 2
Each switch in the ICX 7000 family allows for 12 units in a stack. The various models provide
link speeds from 10 to 40 to 100Gbps. Each also has multiple connection options from
multiple 10G, 40G or 100G ports dedicated to stacking. This allows for very high
throughput within the stack ranging between 480Gbps all the way up to 9.6Tbps.
The maximum bandwidth is calculated by multiplying the stack link speed times the
number of stack links, times the number of switches in the stack, times 2 due to the stack’s
full‐duplex operation.
Ruckus Ethernet Optics
• Ruckus‐qualified optic transceivers are available for ICX switches and APs
• Benefits include:
– Guaranteed compatibility with Ruckus ICX switches
– Full compliance with industry standards
• 802.3z
• 802.3ah
• 802.3u
• 802.3ae
• 802.3ak
• 802.3ba
– Factory tested to assure functionality and reliability
– Hot‐swappable flexibility in the field for greater ease and lower total cost of ownership
– Digital Optical Monitoring (DOM) support
• Ruckus supports digital optical monitoring only on Ruckus optics
For a list of Ruckus‐certified optics, refer to the Ruckus Ethernet Optics data sheet
Ruckus offers a unique set of high‐performance, reliable, and cost‐effective optical
transceivers to help enterprises and service providers meet the challenges of diverse
network topologies. To ensure maximum quality, Ruckus selects and tests the most reliable,
highest‐performing optical transceivers on the market, and then warrants their availability,
capacity, and performance in Ruckus products.
Ruckus optics are fully compliant with the industry standards displayed here and are
compliant with Restrictions on Hazardous Substances (RoHS), meeting RoHS 6 European
Union (EU) requirements.
Using Ruckus optics also enables the support of Digital Optical Monitoring (DOM) on ICX
switches. DOM supports monitoring of optical output power, optical input power,
temperature, laser bias current, and transceiver voltage. This capability is only available
with Ruckus optics.
Breakout Cables
• Breakout cables allow the splitting of certain high‐speed ports into 4 lower‐speed ports
– On ICX 7750, 40 GbE QSPF+ ports can be split into 4‐10 GbE ports
– On ICX 7850, QSFP28 40 GbE/100 GbE ports can be split into 4‐10 GbE and 4‐25 GbE ports, respectively
• When employed, port numbering on the device changes
• A switch reload is required when enabled
The ICX 7750 and 7850 support the use of breakout cables that allows a single high‐speed
interface to be split into four separate interfaces.
On the ICX 7750, the 40 GbE QSPF+ ports can be split into 4‐10 GbE ports.
On the ICX 7850, the QSFP28 ports that operate at 40 GbE/100 GbE can be split into 4‐10
GbE and 4‐25 GbE ports, respectively.
Switch configuration is required to allow use of the breakout functionality. This change
creates sub‐ports on the device which can be configured the same way as any other
physical interface. In order for system to manage these sub‐interfaces, the switch must be
reloaded whenever breakout mode is enabled or disabled.
Summary
• Attendees should now be able to:
– Describe the evolution of the network
– Understand where in the network topology you would find different ICX switches
– Describe the different configurations available with each ICX switch model, including:
• ICX 7150
• ICX 7250
• ICX 7450
• ICX 7650
• ICX 7750
• ICX 7850
– Explain stacking, optic and cabling capabilities of Ruckus ICX switches
This concludes the ICX Hardware overview module. You should now be able to:
• Describe the evolution of the network
• Understand where in the network topology you would find different ICX switches
• Describe the different configurations available with each ICX switch model
• Explain stacking, optic and cabling capabilities of Ruckus ICX switches
End of Module 3:
ICX Hardware Overview
This concludes the ICX Hardware Overview training module.
ICX 150 CLI Basics
Module 4:
CLI Basics
Revision 0419
This module will cover the ICX CLI basic commands.
ICX 150 CLI Basics
Objectives
• After completing this module, attendees should be able to:
– Explain the Command Line (CLI) structure of ICX devices
– Manage device configuration files
– Configure switch hostname, IP address, and default gateway
– Configure interface settings including, name, IP address, speed and duplex
– Use show commands to view switch information
The objectives of this module include:
• Explaining the CLI structure of ICX devices
• Managing device configuration files
• Configuring global switch settings like hostname, IP address, and default gateway
• Configuring interface settings like name, IP address, and speed and duplex
• Finally, we'll look at using show commands to verify switch information
ICX 150 CLI Basics
CLI Overview
Let’s start with an overview of the CLI structure.
ICX 150 CLI Basics
Initial Startup – Factory Defaults
• Beginning with software version 8.0.90, factory default ICX switches will start with:
– SSH enabled
– Local user account created for initial login
• SSH and local user accounts will be covered in detail in later modules
– By default CLI, Web and SSH require authentication before allowing access
Press Enter key to login
Default username and password is:
User Access Verification super / sp-admin
Please Enter Login Name: super
Please Enter Password: sp-admin
User login successful.
User ‘super’ login successful with default password. Please change the password.
Once logged in, you are

Enter the new password for user super: NewPa$$word required to change the
Enter the reconfirm password for user super: NewPa$$word
Password modified successfully for user super password for user: super
Authentication is enabled in the device for Console/WEB/SSH.
ICX7150-C12-Switch>
Beginning with ICX software version 8.0.90, there has been a major change to the default
behavior of a factory defaulted switch. In previous releases, SSH was disabled and there
were no local user accounts required to login. In this release, SSH is enabled and because of
this a user account is required.
This impacts all enabled access methods on the switch, including console, web UI and SSH.
Note, in release 8.0.90 Telnet is disabled by default.
On initial boot and logon, you will be presented with a login prompt. The default username
is super and the password is sp‐admin. Once successfully logged in, you are required to
change the password for user: super. You must input the new password twice to ensure
accuracy.
ICX 150 CLI Basics
CLI Command Tree
User EXEC
• User EXEC level >
– Prompt: >
– View basic system info Privileged EXEC
– Verify connectivity (such as ping and traceroute) #
• Privileged EXEC level Global Configuration (CONFIG)

– Enter using the enable command (config)#
– Prompt: #
– Can be password protected The CONFIG level contains sub-
– View detailed information using show commands levels for configuring individual
interfaces, VLANs, routing
– Execute system‐wide commands (boot system, reload)
protocols, and other configuration
• Configuration (CONFIG) level areas. The prompts for these
– Enter using the configure terminal command levels change to indicate the
current level
– Prompt: (config)#
– Make global or local system changes (VLANs, interfaces, etc.)
– Save changes using the write memory command
Once logged into the ICX, you will see the commands in the CLI are organized into the
following levels:
First, we have User EXEC, this level (or mode) is indicated by the greater than sign (>), here
you can display information and perform basic tasks such as ping and traceroute.
Next, we move into the Privileged EXEC level using the enable command. This level is
indicated by the pound or number sign (#). Here there are many more commands that can
be run along with the User EXEC commands.
The next level is configuration (or CONFIG), this level is Indicated by the (config)#
prompt. Here you can make configuration changes to the device and they are put into the
running‐config file.
To save the changes across reboots, you need to save them to the startup‐config file using
the write memory command. The CONFIG level contains sub‐levels for individual ports,
VLAN’s, routing protocols, and other configuration areas.
Prompts for these levels will change to indicate the current level.
ICX 150 CLI Basics
CLI Prompts
• The prompt changes to indicate your current status
From the User EXEC level, enter enable
ICX7150-C12-Switch> to move to the Privilege EXEC level
ICX7150-C12-Switch> enable
From the Privilege EXEC level,
No password has been assigned yet... enter config terminal to
ICX7150-C12-Switch# move to the global CONFIG
level
ICX7150-C12-Switch# config terminal
ICX7150-C12-Switch(config)# interface ethernet 1/1/1
ICX7150-C12-Switch(config-if-e1000-1/1/1)# ?
100-fx 100 FX Mode
acl-logging enable logging of From the global
deny aclCONFIG
level, enter a sub command
acl-mirror-port Set acl based inbound mirroring
arp Assign IP ARP option to this interface
authentication Configure flexible authentication on
interface
Here we see an example of how the prompt changes to indicate where you are in the CLI
structure.
We start at the User EXEC level as designated by the greater than sign (>). Next, we enter
the enable command and we get a message that no password has been assigned yet. We
will talk more about assigning passwords later in the course.
Once we enter the enable command, the prompt changes to the pound sign or number
sign, this puts us into Privileged EXEC level. To move into configuration level we enter
config terminal. Note that, all of these commands can be shortened, for instance
you can use config t instead of the full command.
We will discuss using abbreviated commands later in this module.
Now that we are in CONFIG mode, we can go into a sublevel. Here we are going into the
interface configuration level for interface 1/1/1. As you can see the prompt changes to
show that you are now in the interface configuration level.
ICX 150 CLI Basics
CLI Prompts (cont.)
• Move back up the menu tree using exit
ICX7150-C12-Switch(config-if-e1000-1/1/1)# exit
ICX7150-C12-Switch(config)# exit
ICX7150-C12-Switch# exit
ICX7150-C12-Switch>
• Use end or Ctrl+z to return to # prompt from any lower level
• Use quit to return to > prompt from any lower level
To go back and forth between the different levels, issue the exit command. This will
move you one level up the command hierarchy.
Pressing Ctrl‐Z or the end command will move the prompt to the Privileged EXEC level (#)
from any lower level.
Use the quit command to return to the User EXEC level from any lower level.
ICX 150 CLI Basics
CLI Command Properties
• CLI commands are not case sensitive
• The CLI accepts abbreviations for commands, as long as it is a unique string
– For example, for the show interfaces brief command use the abbreviation:
ICX7150-C12-Switch# sh int br
• Most commands only display feedback or error messages upon failure
• Most configuration commands have a [no] option to undo the configuration
ICX7150-C12-Switch(config)# no vlan 200
• Use up and down arrow keys for command memory recall
Let’s take a look at the properties of the CLI commands.
First, the only time a CLI command is case sensitive is for passwords. The CLI does accept
abbreviated commands, as long as the string is unique. If a string is not unique you will get
an “ambiguous input” message. For instance, if you just enter the letter s, you will get the
Ambiguous input -> s message, because there is more than one command that
starts with the letter s.
Most commands will only give you an error message if the command is incorrect,
otherwise the system will take the command and display no message.
Most commands have a no option to undo the command. For instance, if you create VLAN
200 and decide it is a mistake, just enter the no vlan 200 command.
To view previously used commands use the up and down arrow keys. This is very helpful if
you are entering a command over and over, or making a small change to a previously
entered command.
ICX 150 CLI Basics
CLI Command Properties (cont.)
• Certain commands, such as ping, reload and debug, can only be entered from the
Privileged EXEC or User EXEC level, not the CONFIG level
ICX7150-C12-Switch(config)# ping 10.1.1.1

Invalid input -> ping 10.1.1.1
Type ? for a list
ICX7150-C12-Switch(config)# exit
ICX7150-C12-Switch# ping 10.1.1.1
Sending 1, 16-byte ICMP Echo to 10.1.1.1, timeout 5000 msec, ttl 64
Type Control-c to abort
Reply from 10.1.1.1 : bytes=16 time<1ms ttl=128
Success rate is 100 percent <1/1> round-trip min/avg/max=0/0/0ms.
There are some commands, like ping and traceroute, that cannot be run from
CONFIG mode. You must exit to Privilege EXEC or User EXEC mode to run the command.
If a command cannot be run from a particular level, you will get an invalid input command
as we see here when we try to ping from the CONFIG mode. At this level in the hierarchy,
typing exit, end or pressing Ctrl-Z will return to the Privileged EXEC prompt allowing
the command to be run.
ICX 150 CLI Basics
CLI Help
• Use question mark (?) help to display available options at a CLI level
– For example, to view all available commands at the User EXEC level, enter ? or enter Tab at the prompt:
ICX7150-C12-Switch> ?
enable Enter Privileged mode
exit Exit from EXEC mode
nslookup Nslookup Utility
ping Ping IP node
show Display system information
stop-traceroute Stop current TraceRoute
traceroute TraceRoute to IP Node
To view all available commands at a certain level of the CLI, you can use question mark
help. Simply enter a ? or use the Tab key at the prompt.
The example here shows the available commands at the User EXEC level.
ICX 150 CLI Basics
CLI Help (cont.)
• Use a ? or the Tab key to view possible options for an individual command
ICX7150-C12-Switch# copy ?
disk0 From an external USB disk
flash From flash
https From https server
pdc PDC file
running-config From running config
scp From a scp file
startup-config From startup config
tftp From a tftp file
– Enter copy flash followed by a ?, or enter Tab, to view the next available options
ICX7150-C12-Switch# copy flash ?

disk0 To an external USB disk file
flash To flash memory
scp To a scp file
tftp To a tftp file
You can also use question mark help to view the options for an individual command. For
example, to view the options for the copy command, enter the command followed by a
space then use a question mark.
You can then chose an option, and use the question mark again to view available options.
This way you can work your way through the CLI without having to learn every available
command option.
ICX 150 CLI Basics
CLI Help (cont.)
• To display a list of commands that begin with a particular string, add a ? at the end of the
string
– For example, enter s? to view all commands starting with “s”
ICX7150-C12-Switch> s?
show Display system information
skip-page-display Enable continuous display
ssh SSH by name or IP address / hostkeys
stack stacking runtime commands
stop-traceroute Stop TraceRoute operation
supportsave support save related
sz On Premise SZ Exec Mode
ICX7150-C12-Switch> st?
stack stacking runtime commands
stop-traceroute Stop TraceRoute operation
You can also use a question mark to see a list of commands that start with a particular
letter.
For example, enter the letter s with a question mark. Note that there is no space between
the letter and the question mark. Adding additional characters further filters the available
commands, as shown when st? is typed.
ICX 150 CLI Basics
Managing the Configuration File
• Save changes from the running
configuration to the startup configuration
ICX7150-C12-Switch# write memory
• Display the running configuration
ICX7150-C12-Switch# show running-config
• Display the startup configuration
ICX7150-C12-Switch# show configuration
Here we see the RAM and flash memory of the device. RAM is where the currently running
configuration file, referred to as “running‐config”, is stored. All real‐time changes to the
current running configuration file are kept here, and are temporary in nature. If there is a
power failure, RAM is erased. Running the write memory command copies the contents
of the running‐config to the startup‐config in flash.
Flash memory is where the startup configuration file is stored. This file is loaded into RAM
when the system boots or is reloaded. The configuration file in flash memory is changed by
executing the write memory command, or a file copy from a TFTP server.
You can view the contents of RAM using the show running-config command, or
view the contents of the flash with the show configuration command. Note that
the files may not necessarily be the same since the running configuration may contain
changes that have not been saved to the startup configuration.
ICX 150 CLI Basics
Configuration File Management
• The running or startup configuration can be saved to/restored from an external device
• Supported external methods are:
– USB
– HTTPS
– TFTP
– SCP
• File management options for ICX devices:
Ruckus# copy startup-config tftp <tftp-ip-addr> <filename>
– Uploads a copy of the startup configuration file from the ICX switch to a TFTP server
Ruckus# copy running-config scp <scp-ip-addr> <filename>
– Uploads a copy of the running configuration file from the ICX switch to an SCP server
Ruckus# copy https startup-config <https-ip-addr> <filename>
– Downloads a copy of the startup configuration file from a the HTTPS server to the ICX switch
Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved © 2017 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION 14
For easy configuration management, all Ruckus devices support both the download and
upload of configuration files between the devices and external servers on the network.
Supported external servers are:
• USB
• HTTPS
• TFTP
• SCP
The examples show variations of copying the startup‐config and the running‐config to/from
external servers.
ICX 150 CLI Basics
Erasing the Configuration File
• Erase the startup configuration and reload the device with a blank configuration
ICX7150-C12-Switch# erase startup-config
– This erases the startup‐config file stored in flash
– It does not change the running‐configuration stored in NVRAM
• In order to complete the restoration of an empty/factory configuration, the device must
be reset
ICX7150-C12-Switch# reload
– After reload, the startup‐config and running‐config will have the default/factory configuration parameters
If you want to erase the startup configuration on a device, effectively resetting the unit
back to factory defaults, issue the erase startup‐config command and then reload the
device. When the device boots up the configuration will revert back to the default
configuration.
When you execute the reload command, the system will prompt to you for verification
that you want to reload to an empty configuration. After verification the system will reset.
Be sure not to perform a write memory after erase startup-config, that will
end up re‐writing the configuration to the file you just erased.
ICX 150 CLI Basics
Basic Switch Configurations
Now that we’ve gone over the structure of the CLI and the navigational commands. Let’s
start making some configurations.
ICX 150 CLI Basics
Hostname
• Configure a system name for the device using the hostname command at the global
CONFIG level
• The name can be up to 255 alphanumeric characters
• The example changes the hostname to Ruckus, from the default hostname of ICX7150‐C12‐
Switch
ICX7150-C12-Switch# config t
ICX7150-C12-Switch(config)# hostname Ruckus
Ruckus(config)#
Let’s start by giving the device a hostname.
We use the config t command to move into CONFIG mode, and use the hostname
command to assign the name. The name can be up to 255 alphanumeric characters.
This example changes the name of the device from the default of ICX7150‐C12‐Switch to
Ruckus.
Note that the prompt changes to the new hostname when the command is entered.
ICX 150 CLI Basics
Port Numbering Format
• The port address format is stack_unit_ID/slot/port
– Stack_unit_ID – specifies the stack ID of the unit
• For all ICX 7000 series switches valid stack unit IDs are 1 to 12
– Slot – specifies the slot number
• Slot numbers vary by device type
– Port – specifies the port number in the slot
• Port numbers vary by device type
• Example specifies port 1, in slot 1, of stack unit 3 in an ICX 7250‐48 stack
Ruckus(config)# interface ethernet 3/1/1
Ruckus(config-if-e1000-3/1/1)#
ICX devices use the stack_unit_ID/slot/port format for port numbering. The stack_unit_ID
indicates where in the stack the unit sits. A device that is not participating in a stack uses
the ID of 1. If the unit is in a stack, the ID is assigned from the active controller in the stack.
For all ICX 7000 series switches valid stack unit IDs are 1 to 12
Note: Stacking is covered in separate presentation.
The slot number indicates which slot the port is in. for instance, The 48‐port ICX 7250 has
two slots: Slot 1 has the 48 x 1 GbE ports, and slot 2 has the 8 x SFP+ uplink or stacking
ports.
Finally, the port is the port number in the slot. Remember, port numbers vary by device
type, so refer to the Hardware Installation Guide for your specific device.
Here we see an example of the port number on a 48‐port ICX 7250. The command entered
at the CONFIG level is for port 3/1/1. That is port 1, in slot 1, of stack unit 3.
ICX 150 CLI Basics
Breakout Port Number and Configuration
• ICX 7750 and 7850 allow 40 GbE ports to be split into 4‐10 GbE ports using breakout cable

• ICX 7850 allows 100 GbE port to be split into 4‐25 GbE ports
• Configured with the breakout ethernet command
ICX7750-26Q# configure terminal
ICX7750-26Q(config)# breakout ethernet 1/1/11
– If port has any configuration, command is rejected
– Requires write memory and reload after enabling/disabling breakout mode
• Breakout ports are viewed and configured as sub‐ports
ICX7750-26Q# show interface brief | in 1/1/11
1/1/11:1 Up Forward Full 10G None No 1 0 cc4e.2439.3721
The ICX 7750 and 7850 support the use of breakout cables that allows a single high‐speed
interface to be split into four separate interfaces.
On the ICX 7750, the 40 GbE QSPF+ ports can be split into 4‐10 GbE ports.
On the ICX 7850, the QSFP28 ports that operate at 40 GbE/100 GbE can be split into 4‐10
GbE and 4‐25 GbE ports, respectively.
This functionality is configured with the breakout command at the global configuration
level. This command requires that the port referenced does not have any configuration. If it
does, the breakout command will be rejected.
Executing this command requires the creation of sub‐ports on the device. Because of this,
the switch must be reloaded whenever breakout mode is enabled or disabled.
After enabling and resetting, breakout ports are configured and viewed in the same way as
regular Ethernet ports except they will be referenced as sub‐interfaces.
In the example you can see that when interface 1/1/11 was broken out, it created sub‐
interfaces 1/1/11:1 through 1/1/11:4.
ICX 150 CLI Basics
Enabling Ports
• By default, all interfaces on ICX devices are enabled
• To disable or enable a specific interface, or range of interfaces, use the following
commands:

Ruckus(config-if-e1000-1/1/9)# disable
Ruckus(config)# interface ethernet 1/1/10 ethernet 1/1/15 ethernet 1/1/20

Ruckus(config-mif-1/1/10,1/1/15,1/1/20)# enable
Ruckus(config)# interface ethernet 1/1/1 to 1/1/8

Ruckus(config-mif-1/1/1-1/1/8)# disable
By default, all interfaces on ICX devices are enabled. If you need to disable a port, or range
of ports, enter the configuration level for the desired ports and enter the disable
command.
Notice how the prompt changes to show that you are in the sub‐configuration level for the
port or ports. If you then want to enable a port, use the enable command.
Port configurations can be applied to a single port, a list of specific ports or a range of
ports.
• A single port is configured by specifying only that port in the interface command.
• Example: interface ethernet 1/1/9
• A port list if configured by including multiple, single ports in a list.
• Example: interface ethernet 1/1/10 ethernet 1/1/15
ethernet 1/1/20
• A range of ports can be configured by using the keyword “to”. This is an inclusive list
of all ports from the first port listed to the last port listed.
• Example: interface ethernet 1/1/1 to 1/1/8
ICX 150 CLI Basics
Port Addressing
• Ruckus ICX switches can operate as strictly Layer2 or Layer2/3 devices based on firmware
type: switch ‐or‐ router1
• On Layer 2 switches, the IP address and default gateway are assigned globally, only one per
switch
– Addresses can be IPv4 or IPv6
Switch(config)# ip address 192.22.33.45/24
Switch(config)# ip default-gateway 192.22.33.1
Switch(config)# ipv6 address 2001:DB8:12D:1300:240:D0FF:FE48:1/64
• On Layer 3 switches, IP addresses are assigned per interface
– Addresses can be IPv4 or IPv6
Router(config)# interface ethernet 1/1/9
Router(config-if-e1000-1/1/9)# ip address 192.22.33.45/24
Router(config-if-e1000-1/1/9)# ipv6 address 2001:2000:F00D:1::1/64
Footnote 1: Switching and router code will covered in an upcoming presentation.
On a Layer 2 switch, the IP address and default gateway are assigned globally and are used
for management access through Telnet, SSH, or the Web GUI. Only one IPv4 and one IPv6
address can be assigned. If you try to add another address using the ip address, or
ipv6 address command, the most recently entered address becomes the switch
address. Though, you can have both an IPv4 and an IPv6 address configured at the same
time.
Also, it is important to note that Ruckus does support the use of CIDR notation for the
subnet mask, as well as the dotted‐decimal format.
ICX devices also have an out‐of‐band managed port that can be used for management
access. The management port is discussed later in this course.
For an ICX running Layer 3 routing code, each interface is assigned an IPv4 or IPv6 address
individually.
Note that interfaces can be multi‐netted, meaning they can be assigned more than one
IPv4 or IPv6 address. In fact, by default you can configure up to 24 IP addresses on each
interface.
ICX 150 CLI Basics
Port Naming
• Use a text string to identify a port with a meaningful name
• Assign a name to an individual port, or a group of ports
• Names can be assigned to physical ports, virtual interfaces, and loopback interfaces
• For example, assign a name to interface 1/1/1
Ruckus(config-if-e1000-1/1/1)# port-name PortToPC1
• Port names display in various CLI output including the running configuration and show
interfaces brief
Ruckus(config)# show interfaces brief
Port Link State Dupl Speed Trunk Tag Pvid Pri MAC Name
1/1/1 Down None None None None No 1 0 0024.38b7.4f40 PortToPC1
1/1/2 Down None None None None No 1 0 0024.38b7.4f41
<Output Truncated>
In many cases it is useful to assign a name to your ports so you know what they are used
for. Use the port-name command to assign a meaningful name to an individual port, or a
group of ports. Names can be assigned to physical ports, virtual interfaces, and loopback
interfaces. Port names can be up to 255 characters long and cannot contain any blanks. The
name can contain special characters, but if the name ends in a percentage sign (%), it is
dropped.
When configured, port names are displayed in show commands like show interfaces
brief, but only the first ten characters are displayed. However, the full name is displayed
in the running and startup configs.
ICX 150 CLI Basics
Speed & Duplex
Ruckus(config-if-e1000-1/1/1)# speed-duplex ?
• By default, all ICX 10-full 10M, full duplex
copper Ethernet 10-half 10M, half duplex
100-full 100M, full duplex
interfaces are set to 100-half 100M, half duplex
auto‐negotiation 1000-full
1000-full-master
1G, full duplex
1G, full duplex, master
– Use the speed-duplex 1000-full-slave 1G, full duplex, slave
command to change the 100g-full 100G, full duplex
10g-full 10G, full duplex
speed and duplex of the 10g-full-master 10G, full duplex, master
interface 10g-full-slave 10G, full duplex, slave
2500-full 2.5G, full duplex
• Use the no form of the
2500-full-master 2.5G, full duplex, master
command to restore the 2500-full-slave 2.5G, full duplex, slave
default 40g-full 40G, full duplex
auto Autonegotiation
Copper Ethernet ports are designed to auto‐sense and auto‐negotiate the speed and
duplex mode of the connected device. If the attached device does not support this
operation, you can manually enter the port speed to operate anywhere between 10 Mbps
and 10 Gbps, depending on the specific device. This configuration is referred to as force
mode. The default and recommended setting is auto for 10/100/1000 auto‐sense. Port
duplex mode and port speed are modified by the same command. View the notes section
of this slide to view some considerations for speed and duplex settings on ICX devices, then
advance to the next slide when you’re ready.
Use care when configuring speed and duplex on a switchport as a misconfiguration on one
side of the link could result in connectivity issues and errors.
ICX 150 CLI Basics
Displaying Switch Information
Now that we’ve made some configurations, let’s take a look at displaying the information.
ICX 150 CLI Basics
Show Commands
Show Command Description
version Software version and uptime
interface Interface status
statistics Interface statistics
ip IP information
span Spanning Tree information
mac-address MAC forwarding table
mac-address statistics Number of MACs learned per port
flash Flash memory images
vlan Configured VLANs
telnet IP address of active telnet sessions
lag Configured, active link aggregation groups
Technical details for help troubleshooting issues when
tech-support
working with technical support
There are many show commands available on the ICX switches. The table displays a few of
the options and a brief description of some commonly executed show commands.
Advance to the next slide when you are ready.
ICX 150 CLI Basics
Searching and Filtering CLI Output
• Use pipe “|” to modify the output of show commands according to operators:
– Begin – Display all output beginning with the first line that contains the matched text string
– Include – Display only lines that include the matched text string
– Exclude – Display only lines that to not include the matched text string
• Used for searching and filtering purposes
• Only one pipe allowed per command string
• Matching strings are case‐sensitive
• Examples:
show interfaces | include Up
show interfaces | begin 1/1/5
show interfaces | include Disable
show interfaces brief | exclude Down
Searching and filtering using pipe “|” and its operators can save you time when searching
through long outputs of show commands.
The operators available are:
• Begin – Display all output beginning with the first line that contains the matched text
string
• Include – Display only lines that include the matched text string
• Exclude – Display only lines that to not include the matched text string
I tis important to note that only one pipe can be used per command string, and that
searched strings are case‐sensitive.
For example, if you want to view ports that are active, use show interfaces |
include Up. If you want to view ports that are manually disabled, use show
interfaces | include Disable.
ICX 150 CLI Basics
Show Commands ‐ System Verification
• show chassis
– Displays system temperature, fans, power supplies, MAC address, etc.
• show module
– Displays the module type, status, number of ports, and MAC address
• show version
– Displays the software version that the device is currently running
There are some useful commands for viewing overall system information.
The show chassis command displays the power supply and fan status, temperature
reading, and the MAC address of the system.
The show module command is very useful when trying to figure out which ports are in
which module. It also displays the number of ports in the module and the starting MAC of
the ports in the module.
The show version command displays the software version and boot version running
on the device, any installed licenses, slot information, stack unit ID, and system uptime.
ICX 150 CLI Basics
Show Commands ‐ System Verification (cont.)
• show flash
– Displays the primary and secondary software codes stored in the flash memory (versions and sizes)
• show memory
– Displays the amount of total/used/free DRAM
• show dir | show files

– Displays the contents of the system flash, including amount of flash available and the amount taken by the
primary and secondary images
• show dir disk0 | show files disk0

– Displays the contents of the USB flash drive and the amount of flash taken by each of the files
The show flash command displays the software versions loaded in the primary and

secondary flash partitions as well as the boot image installed. It also displays the amount of
free flash on the device.
The show memory command displays the amount of DRAM used and free on the device.
The show dir and show files commands will list the contents of system flash
including the size of primary and secondary images installed on the system.
The show dir disk0 and show files disk0 commands display the contents of a
connected USB flash drive. This is especially useful when upgrading the switch from the
USB drive.
ICX 150 CLI Basics
Show Configuration
Ruckus(config)# show running-config
• Display the running configuration Current configuration:
!
Ruckus# show running-config ver 08.0.90T211
!
stack unit 1
module 1 icx7150-c12-poe-port-management-module
module 2 icx7150-2-copper-port-2g-module
• Display the startup configuration module 3 icx7150-2-sfp-plus-port-20g-module
stack-port 1/3/1
stack-port 1/3/2
Ruckus# show configuration !
!
vlan 1 name DEFAULT-VLAN by port
!
vlan 10 by port
• The example displays a partial running tagged ethe 1/1/2
untagged ethe 1/1/3 to 1/1/5
configuration on a ICX 7150‐C12 !
!
aaa authentication web-server default local
aaa authentication login default local
enable aaa console
ip address 192.168.1.121 255.255.255.0
ip default-gateway 192.168.1.1
!
no telnet server
username super password .....
<Output Truncated>
As previously mentioned, the ICX has a running configuration and a startup configuration.
The commands to view the configuration files are show running-config and show
configuration.
Here we see an example of the running configuration on a 24‐port ICX7450. The output has
been truncated as these files can be rather long. But you can see here, starting from the
top, the software version, the stack unit ID, the modules installed, configured VLANs, the
hostname, and the IP address and default gateway configured on the device.
ICX 150 CLI Basics
Displaying Interfaces
• The show interfaces brief command can be used to quickly check port operational status
Spanning Tree State: Forward,
802.1q Tagged
Listen, Blocked, etc.
Yes or No
Ruckus# show interfaces brief

1/1/1 Up Forward Full 1G None No 1 0 748e.f87b.fe40 Server
1/1/2 Up Blocked Full 1G None No 1 0 748e.f87b.fe41
1/1/3 Down None None None None No 1 0 748e.f87b.fe42
1/1/4 Disable None None None None No 1 0 748e.f87b.fe43
1/1/5 Up Forward Full 1G None No 1 0 748e.f87b.fe44 Router
<Output Truncated>
Current Link State Speed & Duplex

Up, Down, Disabled
When it comes to displaying interface information there is a brief command and a detailed
command. Here we see an example of the, show interfaces brief command. This
allows you to quickly check the general status of all interfaces. Some of the details provided
include:
• Link – which is the physical connectivity state. Typical values range between
Up, Down and Disable.
• State – displays the Spanning Tree state for all Spanning Tree flavors, 802.1D,
802.1w etc., here you might see states like Forward, Listen, Learning, or
Blocked.
• Tag – displays if the port is tagged 802.1Q or not. No means the port is
untagged.
The output also shows the MAC address of the port, the QoS priority, as well as the Pvid or
VLAN ID.
ICX 150 CLI Basics
Displaying Interface Details
Ruckus# show interfaces ethernet 1/1/1 Interface up/down status

GigabitEthernet1/1/1 is up, line protocol is up
Speed and duplex
Port up for 2 minute(s) 5 second(s)
Hardware is GigabitEthernet, address is 0024.38b7.7056 (bia 0024.38b7.7056)
Configured speed auto, actual 1Gbit, configured duplex fdx, actual fdx
Configured mdi mode AUTO, actual MDIX
Untagged member of L2 VLAN 1, port state is FORWARDING
<Output Truncated>
VLAN membership, STP state
MTU 1500 bytes
300 second input rate: 127536 bits/sec, 239 packets/sec, 0.16% utilization
300 second output rate: 37642168 bits/sec, 53507 packets/sec, 46.16% utilization
29939 packets input, 1992836 bytes, 0 no buffer
Received 0 broadcasts, 29 multicasts, 29910 unicasts Throughput
1826 input errors, 20119 CRC, 0 frame, 0 ignored statistics & input
0 runts, 0 giants and output errors
7032695 packets output, 615654919 bytes, 0 underruns
Transmitted 251641 broadcasts, 0 multicasts, 6781054 unicasts
0 output errors, 0 collisions
Relay Agent Information option: Disabled
To view the details of an interface, use the show interfaces ethernet command

with the interface number. This output displays a lot of useful information including:
interface up/down status, VLAN membership with tagged or untagged status, the STP state,
and port MTU.
Also shown are input/output throughput statistics (including utilization percentage) and
any input and output errors seen on the interface.
In the example output, we can see that there are Cyclic Redundancy Check (CRC) errors on
the port. CRC errors can often be caused by faulty hardware, such as cables, SFPs, switch
port or any other component of the physical connections.
ICX 150 CLI Basics
Displaying Interface Statistics
• Use the show statistics command to view port statistics and detailed error counters
Ruckus# show statistics ethernet 1/1/1
Port 1/1/1 Counters:
InOctets 1992836 OutOctets 694011939
InPkts 29939 OutPkts 8021550
InBroadcastPkts 0 OutBroadcastPkts 266281
InMulticastPkts 29 OutMulticastPkts 0
InUnicastPkts 29910 OutUnicastPkts 7755269
InBadPkts 20119
InFragments 1707
InDiscards 0 OutErrors 0
CRC 20119 Collisions 0
InErrors 0 LateCollisions 0
InGiantPkts 0
InShortPkts 0
InJabber 0 OutDiscards 0
InFlowCtrlPkts 0 OutFlowCtrlPkts 0
InBitsPerSec 118088 OutBitsPerSec 40742424
InPktsPerSec 221 OutPktsPerSec 58810
InUtilization 0.15% OutUtilization 50.15%
The show statistics command offers a more in‐depth look at the port statistics,

including detailed error counters.
ICX 150 CLI Basics
Summary
– Explain the Command Line (CLI) structure of ICX devices
– Manage device configuration files
– Configure switch hostname, IP address, and default gateway
– Configure interface settings including, name, IP address, speed and duplex
– Use show commands to view switch information
This concludes the CLI Basics module. You should now be able to:
• Explaining the CLI structure of ICX devices
• Managing device configuration files
• Configuring global switch settings like hostname, IP address, and default gateway
• Configuring interface settings like name, IP address, and speed and duplex
• Finally, we'll look at using show commands to verify switch information
ICX 150 CLI Basics
End of Module 4:
CLI Basics
Revision 0419
This concludes Module 4 – CLI Basics
ICX 150 Software Upgrade and Licensing
Module 5:
Revision 0419
Welcome to the ICX 150 Implementor course. This course consists of 12 modules

switch. This module will cover ICX software upgrades and licensing.
.
Objectives
• After completing this module, you should be able to:
– Discuss the upgrade considerations when upgrading a ICX switch
• Use the Target Path Selection Guide to find which software version is right for your device
– Discuss the Software Image Files
– Describe the simplified upgrade process
– Perform the process of verifying the current software version
– Perform a software upgrade using both legacy and Unified FastIron Image processes
– Describe and install Software Licensing
After completing this module you’ll be able to:
Discuss the upgrade considerations when upgrading a ICX switch
• Use the Target Path Selection Guide to find which software version is right for your
device
Discuss the Software Image Files
Describe the simplified upgrade process
Perform the process of verifying the current software version
Perform a software upgrade using both legacy and Unified FastIron Image processes
Describe and install Software Licensing
Upgrade Considerations
Let’s take a look at the different software image files for Ruckus ICX products.
Software Release Notes
• Every time you upgrade or downgrade to
a software version, you must read the
Ruckus Software Release Notes
• Software Release Notes can be found on
– https://support.ruckuswireless.com/software
• Software Release Notes contain:
– Supported devices and new enhancements
– Upgrade/downgrade considerations and
procedures
– Bug fixes in the release
Before you upgrade or down grade software on any Ruckus product, refer to the Software
Release Notes on the Ruckus support website at:
https://support.ruckuswireless.com/software
Software Release Notes will show you the supported devices for the release, and new
enhancements.
Also, it provides any upgrade or downgrade considerations, as well as the upgrade
procedure.
Finally, the release notes provide any bug fixes in the release.
Be aware that the software downloaded from the Ruckus support site will be in the form of
a zip file. Many of the transfer processes require the zip file to be unzipped and place on
the server you intend to transfer the software with.
Target Path Selection Guides
• Target Path releases are
recommended code levels for Ruckus
IP platforms
• Target Path releases meet the
following criteria:
– Stability and reliability
• Typically does not contain new major
software features
• It is not used for support of new hardware
• It may contain reliability, availability, and
serviceability (RAS) improvements and
enhancements
– Deployed in large number of end‐user
production environments for a specified
Target Path Selection Guides an be found on time
https://support.ruckuswireless.com/documents/1591‐fastiron‐target‐path‐selection‐guide
• Must have no known critical or pervasive
issues or defects
Target path releases are recommended code levels for Ruckus IP platforms. A target path
release meets the following criteria:
• It is a release created primarily for stability and reliability, and typically does
not contain new major software features
• It is not used for the support of any new hardware, although it may contain
reliability, availability, and serviceability (RAS) improvements and
enhancements
• It has been deployed in a sufficient number of end‐user production
environments for a specific period of time and must have no known critical or
pervasive issues or defects
Target Path Selection Guides for each product line can be found on the Ruckus support
website under the ICX Technical Documents section.
Example Target Path
• The following table is from the FastIron Target Path Selection Guide for software version
08.0.90
– In most cases there are more recent versions of code available that provide additional functionality
– Customers who wish to deploy these features, and cannot wait for a Target Path designation on that
release, should use the latest release available
– Customers who do not have an immediate need for the latest features should follow the provided Target
Path recommendations
Enterprise/Campus Current Target Recommended Release if No Target

Product Path Version Path Version Exist
ICX 7150 FI 08.0.70d
ICX 7250 FI 08.0.70d
ICX 7450 FI 08.0.70d
ICX 7650 FI 08.0.70d
ICX 7750 FI 08.0.70d
ICX 7850 FI 08.0.90
Here we see an example of the ICX target path releases as of software version FI 08.0.90
As you can see the target path varies on each platform and in most cases the target path is
not the most current revision of the software.
If you do not need a later version of software for specific features, Ruckus suggests using
the recommended target path release.
Software Image Files
Let’s take a look at the different software image files for Ruckus ICX products.
Unified FastIron Image (UFI)
• The new process (UFI) contains all files within one file allowing a single image download to
update all necessary software components
– The UFI contains components/packages
• Application image
• Application image’s signature file
• U‐boot
• PoE firmware
• Python libraries
• HTTP package
• DHCP package
• <Any other package in future>
• ICX7850 was introduced with this software release
– Supports only the UFI upgrade process
– Supports router code only
8.0.80 release introduces the Unified FastIron Image which combines all the necessary files
together into one file simplifying the upgrade process with a single command to assure all
is upgraded uniformly on the switch.
Its important to note that since the ICX7850 was introduced with the 8.0.90 software
release it only supports UFI image and is not backwards compatible with previous software
management solutions. Additionally it only support Router image code unlike the other ICX
switch families. The UFI will be supported moving forward with other releases and
eventually the legacy simplified software upgrade option will be phased out.
Legacy Software Upgrade (Simplified Software Upgrade)
• Manifest file
– Makes use of a manifest file
• Manifest file specifies the directory path of all images to be upgraded
– When used it will upload the necessary boot and application software
• Downloads the boot image to the device only if a newer boot image version is available/required
– Can be done through a single CLI command or through SNMP MIB set‐request operations
– The command will only accept a manifest file with a .txt extension
– Each software release maintains its own version of the manifest file
– Specifies images for both router and switch code
• Based on the device family and the type of image that are installed
– Performs multiple copies of images specified in the manifest file
– Specifies which flash partition to install software to (primary/secondary)
Prior to FI 8.0.80 a manifest file was used in a process known as the Simplified Software
Upgrade for switch software. This manifest file identified the u‐boot and Image file
locations however both were still individual files along with separate PoE file as well.
Because these were still individual files there was still the possibility of a u‐boot and image
software mis‐match. The Simplified Software Upgrade process was an improvement over
the original upgrade process used in the early stages of the ICX platform however did not
eliminate the possibility of mis‐matched files which UFI eliminates.
The simplified upgrade process uses a single CLI command and a manifest file to perform
the upgrade.
When the single copy command is run, it performs multiple copies of the images specified
in the manifest file. The upgrade can be done using the CLI command, or through SNMP
MIB set‐request operations.
The simplified upgrade process includes a version‐check of the images to determine if it is
necessary to upgrade the image or not. The command also allows for the specification of
where the upgrade files should be stored either in the primary or secondary location. More
details on the flash partitions will be discussed later in the module.
Legacy Software Migration (Excluding 7850)
• Application and U‐Boot image compatibility issue solved
– Prior legacy process led to the possibility of U‐Boot and Image software mis‐match
– UFI process eliminates the issue due to the unified code
• Both legacy and UFI will be available for the 8.0.90 release
– Switches will not support full 8.0.90 functionality without UFI update
– Beyond 8.0.90 only a single release of a UFI image will be available
• Upgrades from 8.0.80 or older software to 8.0.90 requires a two step process
• Downgrading from UFI software
– Recommended to use only manifest for downgrading to non‐UFI version
The 8.0.90 release provides support for both legacy and the new UFI upgrade process
however the legacy release does not support the full functionality of the new code.
Therefore it is important to treat the legacy code as more of a migration mechanism to the
UFI update process. More details about the legacy upgrade process and migration steps will
be discussed later in this module. If downgrading to code prior to 8.0.90 it is recommended
to only use the manifest file process for downgrading.
ICX 7150, 7250 and 7450 Image Files
ICX 7150
Access • Both legacy and UFI images provide:
ICX 7450 – Two software images for the ICX 7150, 7250 and
Access-Aggregation 7450 platforms (Layer 2 or Layer 3)
• The file type is identified by the 3rd letter
in the file name
– Image File Names:
ICX 7250
Access Legacy Flash Image File UFI File (boot, image)
•
SPS08090.bin (Layer 2) SPS08090ufi.bin (Layer 2)
SPR08090.bin (Layer 3) SPR08090ufi.bin (Layer 3)
– Boot File Name:
• 7150 mnz10115.bin
• 7250 & 7450 spz10115.bin
The ICX 7150, 7250, and 7450 switches use the same image files. The file type, either Layer
2 or Layer 3 is designated by “S” or “R” in the fie name in either the flash or UFI images.
Also shown here is the boot file used for the 7150, 7250 and 7450 series switches. The
boot file begins with “mnz” for the 7150 and “spz” for the 7250 and 7450.
ICX 7650 Image Files
• Both legacy and UFI images provide:
– Two software images for the ICX 7650, 7250 and
7450 platforms (Layer 2 or Layer 3)
ICX 7650 • The file type is identified by the 3rd letter
Access-Aggregation-Core
in the file name
Legacy Flash Image File UFI File (boot, image)
TNS08090.bin (layer 2) TNS08090ufi.bin (Layer 2)
•
TNR08090.bin (Layer 3) TNR08090ufi.bin (Layer 3)
– Boot File Name:
• tnu10115.bin
The ICX 7650 switch uses a unique image file. The file type, either Layer 2 or Layer 3 is
designated by “S” or “R” in the fie name.
Also shown here is the boot file used for the 7650 series switches. The boot file begins with
“tnu”.
• Both legacy and UFI images provide:
– Two software images for the ICX 7750 platform
(Layer 2 or Layer 3)
• The file type is identified by the 3rd letter
in the file name
Legacy Flash Image File UFI File(boot, image) ICX 7750

SWS08090.bin (layer 2) SWS08090ufi.bin (Layer 2) Aggregation-Core
SWR08090.bin (Layer 3)
• SWR08090ufi.bin (Layer 3)
– Boot File Name:
• swz10115.bin
The ICX 7750 switch also uses a unique image file. Like the others, file types are designated
by “S” or “R” in the fie name.
The boot file for the 7750 begins with “swz”.
• Single UFI software image available for the
ICX 7850 platform (Layer 3)
ICX 7850
Aggregation-Core • Supports UFI image file only
– Image File Name:
• TNR08090ufi.bin (Layer 3)
– Boot File Name:
• n/a
And finally the 7850 has one image file which is router code however it is still identified in
the software file by the use of the r in the third position.
Because the 7850 was introduces in this release and only supports the UFI image a
separate boot code file is not needed.
ICX Image Files
ICX 7450
ICX 7250 Access-
Access Aggregation ICX 7650
ICX 7150 Access-Aggregation-Core ICX 7850
Access
Aggregation-Core
Device Boot image file name Flash image file name UFI file name (boot, image)
ICX 7150 mnz10115.bin SPR08090.bin/SPS08090.bin SPR08090ufi.bin/SPS08090ufi.bin

ICX 7250 spz10115.bin SPR08090.bin/SPS08090.bin SPR08090ufi.bin/SPS08090ufi.bin
ICX 7450 spz10115.bin SPR08090.bin/SPS08090.bin SPR08090ufi.bin/SPS08090ufi.bin
ICX 7650 tnu10115.bin TNR08090.bin/ TNS08090.bin TNR08090ufi.bin/TNS08090ufi.bin
ICX 7750 swz10115.bin SWR08090.bin/ SWS08090.bin SWR08090ufi.bin/SWS08090ufi.bin
ICX 7850 n/a n/a TNR08090ufi.bin
Here is another view of the files specific to their switch family with both legacy and UFI file
names.
Verify Current Software Version
Now that we have reviewed the different types of files, lets take a look at how to verify
what software is running on a device.
ICX Flash Partitions
• Ruckus ICX devices have two flash memory modules:
– Primary flash ‐ The default local storage device for image files and configuration files
– Secondary flash ‐ A second flash storage device
• To preserve one software image while testing another one
• You can use secondary flash to store redundant images for additional booting reliability
– It is best practice on switches in production to have the same image on both partitions to ensure failover
capabilities
• To specify which flash to boot
– To immediately boot to a specific partition, issue below command from Privilege Exec mode
Ruckus# boot system flash [primary | secondary]
– This does not get saved to startup config file
– For persistent boot flash preference you will configure the switch
Ruckus(config)# boot system flash [primary | secondary]
Ruckus(config)# write memory
– Any future reboots will load from the configured partition
Two separate flash locations are available in the ICX devices and can be specifically booted
from the software that is stored there. This can provide redundancy in the switch software
and the ability to evaluate new software by uploading to one flash location and booting
from it. You then can easily revert back to the previous software by simply booting the
switch to the flash partition that contains the previous code.
ICX switches by default boot from the primary partition however you can prompt a switch
to boot from a specified flash (such as the secondary) by issuing the boot system flash
secondary from privilege exec mode. This will prompt the switch to immediately reload
using the flash partition specified. Please note that any future reloads of the switch will
revert back to the default behavior or boot based on configuration previously specified. To
cause the switch to boot from the secondary flash consistently you will configure the
switch under configure mode using the boot system flash [primary | secondary] command.
This configuration will need to be saved prior to any reload of the switch otherwise it will
revert back to default behavior or its previous boot configuration.
Displaying Software Version
• Use show version to view the current software version
Ruckus# show version
Copyright (c) 2017 Ruckus Wireless, Inc. All rights reserved.
VersionUNIT
Number
1: compiled on Nov 20 2018 at 00:09:55 labeled as SPS08080d
(25968884 bytes) from Primary SPS08080d.bin Image file name
SW: Version 08.0.80dT211
Compressed Boot-Monitor Image size = 786944, Version:10.1.14T225 (mnz10114)
Compiled on Thu Nov 15 06:59:22 2018
HW: Stackable ICX7150-C12-POE
==========================================================================
UNIT 1: SL 1: ICX7150-C12-2X10GR POE 12-port Management Module Boot version
Serial #:FEK3237N0B4
Software Package: BASE_SOFT_PACKAGE and file name
Current License: 2X10GR
P-ASIC 0: type B160, rev 11 Chip BCM56160_B0
==========================================================================
UNIT 1: SL 2: ICX7150-2X1GC 2-port 2G Module
==========================================================================
UNIT 1: SL 3: ICX7150-2X10GF 2-port 20G Module
==========================================================================
1000 MHz ARM processor ARMv7 88 MHz bus
8192 KB boot flash memory
2048 MB code flash memory
1024 MB DRAM
STACKID 1 system uptime is 36 day(s) 3 hour(s) 6 minute(s) 7 second(s)
The system started at 11:48:06 Central Tue Feb 26 2019
The system : started=cold start
The show version output displays the current software version along with the .bin file

name.
Also shown is the boot version and file name.
The output also displays each module or slot (SL) in the device, and the details of the
module, including any licenses installed on the management module.
Displaying Flash Versions
• Use show flash to view which files are installed in the flash partitions
8.0.80dT211 L2 code is installed in

the primary partition, L3 code is
Ruckus# show flash installed in the secondary partition
Stack unit 1:
NAND Type: Micron NAND 2GiB (x 1)
Compressed Pri Code size = 25968884, Version:08.0.80dT211 (SPS08080d.bin)
Compressed Sec Code size = 25968884, Version:08.0.80dT211 (SPR08080d.bin)
Compressed Boot-Monitor Image size = 786944, Version:10.1.14T225
Code Flash Free Space = 1292234752
The show flash command displays both the primary and secondary partitions and the

version of software installed in each. The output also shows the amount of free flash on
the device.
Notice that the switch code is loaded in the primary partition designated by the SWS in the
.bin file name, and the router code SWR is loaded in the secondary partition.
Software Upgrade
Next, we will look at the software upgrade.
Upgrade Transfer Options
• Software images for all Ruckus ICX devices can be uploaded and downloaded using:
– TFTP (manifest file)
– SCP
– HTTPS (8.0.80 or newer)
– USB module
– Between flash modules (partitions) on the switch
• Transfer of software images can be designated to the primary or secondary flash memory
• Flash image boot options:
– Download UFI image to primary, all the components will be updated for primary
• Boot from primary: all the components installed with primary UFI image is applicable
– Downloaded UFI image to secondary, all the components will be updated for secondary
• Boot from secondary: all the components installed with secondary UFI image is applicable
• Only one image/flash partition is active at one time
There are many different transfer methods that can be used to upgrade a switch however it
is important to note that only TFTP utilizes the manifest file process. Other transfer options
require the U‐Boot and image software to be transferred separately. Moving forward using
the UFI process all transfer options will support a single command pointing to the single
UFI file for the upgrade.
When transferring the software you will specify the flash partition you will place the new
code. Once downloaded it is required that the switch be booted from the flash where the
new software is stored. Note that only one flash partition can be active and switching
between the two options requires a reload of the switch.
Upgrade Methods
• Legacy and UFI commands depending on transfer method used
Transfer Method Commands
Ruckus# copy tftp system-manifest 10.176.132.11
Legacy FI08090_Manifest.txt primary
TFTP
Ruckus# copy tftp system-manifest 10.176.132.11
UFI FI08090_Manifest.txt primary
Ruckus# copy scp flash 10.176.132.13 SPR08090.bin primary
Legacy Ruckus# copy scp flash 10.176.132.13 spz10115.bin bootrom
SCP
UFI Ruckus# copy scp flash 10.176.132.11 SPR08090ufi.bin primary
Ruckus# copy https flash 10.176.132.132 SPR08090.bin primary

HTTPS Legacy Ruckus# copy https flash 10.176.132.132 spz10115.bin bootrom
[FastIron release 08.0.80 and above]
UFI Ruckus# copy https flash 10.176.132.132 SPR08090ufi.bin primary
Ruckus# copy disk0 flash SPR08090_B22.bin primary
Legacy Ruckus# copy disk0 flash spz10115.bin bootrom
USB1
UFI Ruckus# copy disk0 flash SPR08090_B22ufi.bin primary
You can reference the command needed to upgrade a switch which will depend on you
transfer method along with your migration to UFI code. If you are migrating to the UFI
process from software previous to 8.0.90 it will require a two step process to complete.
More details on that process in the next few slides. You can also select this flash partition
you plan to transfer the software however in these examples all transfers are being placed
in the primary partition.
For TFTP upgrade process using the manifest file can be used however will need to be
performed twice to install the UFI image. The first step is to upgrade the to 8.0.90 software
(non UFI) and when run again it will install the UFI version of the software. When
performing legacy upgrade methods other that TFTP (which supports the simplified
manifest process) the software and boot file will need to be uploaded independently.
It is not always necessary to upgrade the boot code on the device. Refer to the Software
Release Notes for your specific version to see if the boot code needs to be upgraded.
The UFI process combines all software needed including the boot image and all other
software therefore only a single command pointing to the UFI file is needed.
Footnote 1: Image upgrade using USB is not supported for stacking in FastIron
release 08.0.80 and 08.0.80 patches. The workaround is to upgrade using the TFTP
or SCP protocol.
UFI Software Upgrade
Upgrade from previous
• Legacy to UFI application upgrade involves 2 step upgrade software
– Old releases do not understand UFI format
From the existing software
CLI
• Image update procedure to 8.0.90 from previous software
1. From 8.0.30 application download 8.0.90 legacy image Download 8090 legacy
image using transfer
2. Reboot the system with 8.0.90 image method to preferred flash
Primary/Secondary
3. Download 8.0.90 UFI image from 8.0.90 image
4. Reboot the system Boot from flash to new
8.0.90 legacy software
Download the 8.0.90 UFI

• If update UFI in step 3 is not performed: software using transfer
method to flash
• Unsupported state Primary/Secondary
• Some functionality is limited if not using UFI image
• Indication is displayed in the show version command and syslog Boot from flash to new
8.0.90 UFI software
Upgrade complete
As mentioned the Unified FastIron Image combines all software files together into one
single file eliminating application and U‐Boot image compatibility issue seen in the legacy
upgrade process.
Migrating from the Legacy to the UFI requires a 2 step process allowing you to use the full
potential of the UFI features.
The first step requires the traditional upgrade process to the non‐UFI image. Once that is
installed the switch can be migrated to the UFI image where all the necessary files will be
upgraded automatically.
ICX7150 running 8060 will require one more reload (total of 3 reloads)
New CPLD was released in 8061
If the system already runs new CPLD, no additional reload
Manifest File Upgrade
• You will issue the TFTP command below to start the upgrade process
Ruckus# copy tftp system-manifest 10.1.1.117 08090\FI08090_Manifest.txt primary
Ruckus# Flash Memory Write (8192 bytes per dot)
DOWNLOADING MANIFEST FILE Done.
Manifest upgrade in progress...

telnet@Lab-ICX01#Flash Memory Write (8192 bytes per dot)
<Output Truncated>
Copy ICX7150 from TFTP to Flash Done
Manifest file upgrade done, please reload the system
• Reload of the switch is required
Ruckus# boot system flash primary
• After reboot you will now be on non‐ufi 8.0.90 code
Copyright (c) Ruckus Networks, Inc. All rights reserved.
UNIT 1: compiled on Feb 19 2019 at 13:48:49 labeled as SPR08090
32454468 bytes) from Primary SPR08090.bin(Non-UFI)
SW: Version 08.0.90T213
Compressed Primary Boot Code size = 786944, Version:10.1.15T225 (mnz10115)
Compiled on Thu Jan 31 01:08:55 2019
Its important to see that the process identified the router software that was previously
running on the switch and the manifest process upgraded accordingly. If switch software
were running on this switch it would have updated using switch software.
If you are using a method other than TFTP manifest process you will have to transfer both
the image and boot code independently using the commands in the previous slide. Both
manifest or independent files require the 2 step process. This is the first step of the two
step press for both TFTP manifest and other transfer methods.
Manifest File Upgrade (cont.)
• Indication of non UFI software displays warning message can be seen from show version or
during boot
==========================================================================================
=================== WARNING: FI image is not booted from UFI!!! ===============
========== Please download UFI image and reboot the system for full functionality ======
==========================================================================================
• Below syslog message will be logged if image is not booted with UFI image
SYSLOG: <14> Jul 5 08:01:05 WARNING: FI image is not booted from UFI, download UFI and
reboot system for full functionality.
• You will again issue the TFTP command below to start the upgrade process to UFI code
Ruckus# copy tftp system-manifest 10.1.1.117 08090\FI08090_Manifest.txt primary
Ruckus# Flash Memory Write (8192 bytes per dot)
DOWNLOADING MANIFEST FILE Done.
Manifest upgrade in progress...

telnet@Lab-ICX01#Flash Memory Write (8192 bytes per dot)
<Output Truncated>
Post processing bundle image...
Bundle image processed successfully
If a switch is running 8.0.90 code that is not the UFI image you will receive a warning
message in both the show version command or when the switch is booted up. Syslog
entries will also be recorded indicating the switch is not running UFI code.
To now migrate to the UFI code using the manifest file you will issue the previous
command again to allow the manifest to now migrate to the UFI code on the switch. Notice
that when it completes it indicates that the bundle image was used and process
successfully
Upgrade Results
• Use show flash to verify that the image and boot code has been successfully copied

Ruckus# show flash
Stack unit 1:
Compressed Pri Code size = 32454872, Version:08.0.90T213 (SPR08090.bin)
Compressed Sec Code size = 30778540, Version:08.0.80T213 (SPR08080b276.bin)
Compressed Pri Boot Code size = 786944, Version:10.1.15T225 (mnz10115)
Compressed Sec Boot Code size = 786944, Version:10.1.15T225 (mnz10115)
• Once transfer is complete you must reboot the device to complete the upgrade process
Ruckus# boot system flash primary
• When reloaded the switch will reflect the UFI code is loaded and running
Copyright (c) Ruckus Networks, Inc. All rights reserved.
UNIT 1: compiled on Feb 19 2019 at 13:48:49 labeled as SPR08090
(32454872 bytes) from Primary SPR08090.bin (UFI)
SW: Version 08.0.90T213
Compressed Primary Boot Code size = 786944, Version:10.1.15T225 (mnz10115)
Compiled on Thu Jan 31 01:08:55 2019
After the second upgrade step and boot you can issue the show flash command to verify
that the new software has been loaded into the partition you have chosen. Also there are
now two boot code locations instead of the one that was used in previous code.
Additionally you will see there is a mismatch of code between the primary and secondary
code which once the new software is verified can be copied over to the secondary partition
shown later.
Once the switch is reloaded it is now running on the UFI code indicated by the output.
Upgrade Results (cont.)
• Once verified issue the copy flash flash primary | secondary to copy to

other flash partition
Ruckus# copy flash flash secondary
Flash Memory Write (8192 bytes per dot)
Ruckus#.........................................................................................................
<output Truncated>
Processing the bundle image...
Flashing application image to Secondary partition...
SYNCING IMAGE TO FLASH. DO NOT SWITCH OVER OR POWER DOWN THE UNIT(65536 bytes per dot)...
............................................................................
Flashing bootrom image to Secondary partition...
<output Truncated>
SYNCING IMAGE TO FLASH. DO NOT SWITCH OVER OR POWER DOWN THE UNIT(65536 bytes per dot)...
............
Copy Done
• Both partitions now reflect the now UFI code
Ruckus# show flash
Stack unit 1:
Compressed Pri Code size = 32454872, Version:08.0.90T213 (SPR08090.bin)
Compressed Sec Code size = 32454872, Version:08.0.90T213 (SPR08090.bin)
Compressed Pri Boot Code size = 786944, Version:10.1.15T225 (mnz10115)
Compressed Sec Boot Code size = 786944, Version:10.1.15T225 (mnz10115)
After you are running in the new software you can then copy it over to the secondary
partition allowing for backup in case the primary partition software becomes currupted.
After this is completed you can issue the show flas command to verify the software is
copied over to the secondary.
Software Licensing
Our next topic is software licensing for ICX devices.
Self‐Authenticated Upgrade (SAU) Licensing
• Software licensing provides increased scalability and rapid deployment of hardware
– Permanent license can be ordered pre‐installed in a Ruckus device
– Ordered separately after delivery
• Self‐Authenticated Upgrade Licensing provides a “pay‐as‐you‐grow” capabilities
– SAU licensing allows you to upgrade or downgrade to a licensed feature set with a single command
• Software Licensing Terminology
– Certificate of Entitlement (CoE): The proof‐of‐purchase certificate issued by Ruckus when a license is
purchased
– Licensed feature: Any hardware or software feature or set of features that require a valid software license
to operate
– Activation Code: A unique key, along with the serial number, used to generate a CoE on the Ruckus
Support site
• Activation Code is delivered in an email message after the order is placed
Licensing provides the convenient and budget friendly way of purchasing equipment
with advanced features sets that may or may not be used when deployed. As the
network changes or advances, these features might be needed and can be activated by
the use of a license. These features include Ports on Demand (PoD), Layer 3 Base
Features (L3‐BASE), L3 Premium Features (L3 PREM), Media Access Control
Security (Prem‐MACsec) depending on the switch series. This is an upgrade option that
does not require a pull and replace process but rather the enabling of a license for the
specific feature set.
Footnote 1: License options are not available on all switch types. Refer to the ICX License
Guide for specific license available for each switch.
There are a few terms used when working with Ruckus licenses on ICX devices. This
include:
Certificate of Entitlement – This is a certificate issued once the license purchased has been
registered and will provide a code that can be associated with an enabled license feature
set
Licensed feature – If a switch is being configured for a feature that requires a license you
will receive an error when entering the commands until a license has been succussfully
installed on the switch
Activication code – This is a unique key that is delivered once a license has been purchased
and is used to register and generate a Certificate of Entitlement.
License Available
License Install License Delete Default

Platform Licensed Feature Possible Packages
Options Options Package
ICX 7150‐24/48 L3 PREM, PoD 4x1g, 2x10g, 4x10gr 2x10g, 4x10gr 4x1G 4x1G, 2x10G, 4x10GR
ICX 7150‐48ZP L3 PREM, PoD 2x10g, 8x10gr 8x10gr 2x10G 2X10G, 8x10GR
ICX 7150‐C12 L3 PREM, PoD 2x1g, 2x10gr 2x10gr 2x1G 2x1G, 2x10GR

l3‐base, l3‐prem
l3‐ base‐2x10G
L3 PREM l3‐prem l3‐prem
ICX 7250 l3‐base l3‐prem‐2x10G
PoD 2x10g, 8x10g 2x10g, 8x10g
l3‐base‐8x10G
l3‐prem‐8x10G
l3‐base, l3‐prem
ICX 7450 l3‐base l3‐base‐macsec
MACSec macsec macsec
l3‐prem‐macsec
l3‐base, l3‐prem,
ICX 7650 l3‐base l3‐base‐macsec
MACSec macsec macsec
l3‐prem‐macsec
ICX 7750 L3 PREM L3 PREM L3 PREM l3‐base l3‐prem
ICX 7850 L3 PREM l3‐prem l3‐prem l3‐base l3‐base, l3‐prem
Software licensing enables premium features in the software, such as premium Layer 3
features.
Most switch families have multiple license that can be applied to them allowing for specific
advanced features or capabilities. Once a package is chosen (fulfilling the environments
requirements) they can be ordered and can be activated on the switch. Switches can have
unique license requirement so please refer to the ICX license guide for additional license
information including stacking ports and limitations.
Licensing Rules
• The following licensing rules apply to all ICX devices that support Self‐Authenticated
Upgrade (SAU) software licensing:
• A license is not tied to a specific device
– It can be removed from one device and redeployed on another device
• Licensed features can be activated prior to obtaining a valid license and used for a trial
period of 45 days, based on an agreement to obtain a license
– Trial licenses for all licensed features are built into the device
– Enabling any licensed feature will activate a 45‐day trial period
– A trial license cannot replace or supersede a normal license
• More than one license can be installed per device concurrently
The Self‐Authenticated Upgrade process allows for many of the license options to be
reused by removing the feature from one switch and redeployed in another. The is handy
when replacing a failed switch or if a switch is being repurposed. Licensed features can be
installed prior to the purchase of a license however it will be considered a temporary trial
license until the valid license is purchased and applied to the switch. As mentioned many
switch families have multiple license options and can be installed on the switch at the same
time however you will receive an error if the same license is applied providing the same
enablement of a feature or feature set.
Licensing Configuration Tasks
The following tasks must be performed in the following order
1. Order the desired license
2. Obtain your license Activation Code, which will be delivered via email
3. Log in to the Ruckus Support portal (https://support.ruckuswireless.com) to generate
the Certificate of Entitlement (CoE)
4. Install the SAU license on the Ruckus device add the CoE serial number
5. Verify that the license is installed
To obtain a valid license it will need to be ordered allowing for an activation code will be
sent. Next you will access the Ruckus support portal and obtaining a Certificate of
Entitlement which will tie the serial number of the switch. This CoE will contain a serial
number that references this association of license and switch which will allow you to
proceed with the install of the SAU license and adding the CoE serial number into the
switch. You can then verify the install and be able to verify the feature is enabled. Lets walk
through these steps in more detail.
Certificate of Entitlement (CoE)
• The following procedure demonstrates how to generate a CoE
– Log into Ruckus support portal at https://support.ruckuswireless.com/
Once your activation code is sent from your order being placed you will proceed to the
ruckus support site at support.ruckuswireless.com. There you will click on the activate
purchase link on the right of the page.
Certificate of Entitlement (CoE) (cont.)
• Enter the Activation Code received by email, and click Validate
• Software license details appear
– Accept the terms and conditions
– Click Activate Purchase
The site will prompt you for your activation code which you can validate to ensure the
activation code enables the license ordered. Once verified you will activate the purchase
and a certificate of entitlement will be generated. This serial number will be entered when
the license is being enabled on the switch.
Adding a Software License
• Enter the license install perpetual command, followed by the unit number

and the purchased license name
Ruckus# license install perpetual 1 4x10gr
Syntax: license {delete|install} perpetual [unit id] [license name]
• Add the license serial number to the switch license installed
Ruckus# license set serial 1 icx7150 PR24235324
Syntax: license set serial [unit ID] [switch type] [license serial number]
• You can confirm the license is installed
Ruckus# show license installed
Unit License Name L3 Prem PoD Speed Ports MACsec SerialNo(L3/ICX7150) SerialNo(PoD/MACsec)
1 2X10GR Yes Yes 10G 2 NA PR24235324 NA
Connect to the switch and with the CoE license serial number you will then use the
license install perpetual command to add the feature to the switch. As
you can see with the syntax this command can also be used to remove a license
from a switch if it can be reused. Next you will configure the serial number of the
CoE certificate using the license set serial command shown. Once these
two steps are completed the CoE serial number will be displayed as part of the
show license installed command output, and also available via SNMP.
Displaying License Features
• Display the license
Ruckus # show license
Unit License Name L3 Premium Port Speed Upgrade Speed Ports MACsec
1 2X10GR Yes Yes 10G 2 NA

Copyright (c) 2017 Ruckus Wireless, Inc. All rights reserved.
UNIT 1: compiled on Nov 20 2018 at 00:09:55 labeled as SPS08080d
(25968884 bytes) from Primary SPS08080d.bin
SW: Version 08.0.80dT211
Compressed Boot-Monitor Image size = 786944, Version:10.1.14T225 (mnz10114)
Compiled on Thu Nov 15 06:59:22 2018
HW: Stackable ICX7150-C12-POE

==========================================================================
UNIT 1: SL 1: ICX7150-C12-2X10GR POE 12-port Management Module
Serial #:FEK3237N0B4
Software Package: BASE_SOFT_PACKAGE
Current License: 2X10GR
P-ASIC 0: type B160, rev 11 Chip BCM56160_B0
==========================================================================
<Output Truncated>
Once a license is loaded, you can use the show license command to view a list of

installed licenses.
Information provided in the show license output indicates if the license is a combo
license or for a specific feature. The output includes:
• The name of the license installed and for what unit
• Features of the license
• If it is a port speed license it will indicate what speed it provides
• The amount of ports it is good for
Finally, there is the capacity, which is the port capacity of a Ports on Demand (PoD) license.
The capacity differs on each ICX platform.
Configuring PoD on an Interface (ICX 7150/7250)
• PoD ports require the port speed to be added to a port
• After license has been installed:
– Insert the 10‐Gbps optic transceiver
– Enter the speed-duplex 10g-full command on a single, multiple or an interface range

Ruckus(config-if-e10000-1/2/2)# speed-duplex 10g-full
• The show pod displays the license configurations for all PoD ports on the switch

Ruckus# show pod
Unit-Id: 1
PoD license capacity: 8
PoD license capacity used: 1
PoD-ports Lic-Available Lic-Used
1/2/1 Yes no
1/2/2 Yes Yes
1/2/3 Yes no
1/2/4 Yes no
1/2/5 Yes no
1/2/6 Yes no
1/2/7 Yes no
<Output Truncated>
To take advantage of the PoD license on the 7150 and 7250 ICX switch the new speed has
to be manually set on the ports. This is performed after the license is installed and the
10Gbps optic is installed in the switch. Once both are installed enter the interface
command line and use speed-duplex 10g-full command to enable. Once saved in
the config the port will remain at 10G until modified.
Summary
– Discuss the upgrade considerations when upgrading a ICX switch
• Use the Target Path Selection Guide to find which software version is right for your device
– Discuss the Software Image Files
– Describe the simplified upgrade process
– Perform the process of verifying the current software version
– Perform a software upgrade using both legacy and Unified FastIron Image processes
– Describe and install Software Licensing
This concludes the Software Upgrade & Licensing module. You should now be able to:
Discuss the upgrade considerations when upgrading a ICX switch
• Use the Target Path Selection Guide to find which software version is right for your
device
Discuss the Software Image Files
Describe the simplified upgrade process
Perform the process of verifying the current software version
Perform a software upgrade using both legacy and Unified FastIron Image processes
Describe and install Software Licensing
End of Module 5:
This completes the Software upgrade and licensing module. I encourage you to continue to
the next module of the ICX 150 Implementer course. Thank you.
ICX 150 Device Access & Management
Module 6:
Device Access & Management
Revision 0419
This module will introduce you to ICX device access and management
Objectives
• After completing this module you will be able to:
– Describe the different methods available for device connection including the console port, Telnet, SSH,
and Web management access
– Describe the function of the management port
– Know how to create local user accounts and passwords
– Describe and configure Simple Network Management Protocol (SNMP)
– Explain how to connect ICX devices to SmartZone network controller
After completing this module you will be able to:
• Describe the different methods available for device connection including the
console port, Telnet, SSH, and Web management access.
• Describe the function of the management port
• Know how to create local user accounts and passwords,
• Describe and configure Simple Network Management Protocol (SNMP)
• Configure an ICX switch to connect to and be managed by the SmartZone
network controller
Access Management
Now let’s discuss access management on the ICX.
Access Management
• There are several methods which can be used to access ICX devices:
– Serial console port
– Telnet
– SSH (Secure Shell)
– Web management GUI
– SNMP‐based management applications
– Ruckus SmartZone
SmartZone
There are several methods available to access ICX devices. You can use the serial console
port, Telnet, Secure Shell (SSH), or the Web management GUI.
Management applications that run SNMP version 1, 2, or 3 can also be used.
As well as the newly added capability that allows an ICX switch to be managed by the
Ruckus SmartZone network controller, which is traditionally known to manage Ruckus
access points.
Console Connection
• ICX devices have the following console ports
– ICX 7150, 7650 and 7850 – USB Type‐C
– ICX 7250, 7450 and 7750 – Mini‐USB
• Use the provided console cable to connect to a PC running terminal emulation software
– Session parameters should be set to:
• Baud rate: 9600 bps
• Data bits: 8
• Parity: None
• Stop bits: 1
• Flow control: None
Different ICX families of switches have different types of console ports. For the 7000 series,
there is a mini‐USB serial ports and USB‐C ports. ICX devices with mini‐USB serial ports ship
with a console cable to connect the device to a PC running a terminal emulation software,
like Putty. Devices with USB‐C ports will require the user to provide the cable.
Regardless of the ICX model, the connection parameters for the session are the same: the
baud rate should be 9600 bits per second, the data bits are 8, the stop bit is 1, and parity
and flow control should be set to none.
Remote Access Options
• Telnet access to CLI
– NOT secure – plain text login & activity
– Can open multiple sessions
– Disabled by default in 8.0.90, enabled prior
• SSH access to CLI
– Secure – encrypted login and activity
– Can open multiple sessions
– Recommended method for CLI access
– Enabled by default in 8.0.90, disabled prior
• Web management GUI (Web GUI)
– HTTP/HTTPS access
– Secure when using HTTPS encrypted login
and activity
– Can open multiple read‐only sessions
For remote access, you have three options:
The first method is a Telnet session. It is important to note that Telnet is not secure. It uses
plain text to transport both username and password information, as well as command
activity. Starting in release 8.0.90, Telnet is disabled by default. In previous versions it was
enabled by default.
The second method is Secure Shell (SSH). SSH provides a secure, encrypted connection for
both login and command activity. Ruckus recommends that you use SSH for remote CLI
access. Starting in release 8.0.90, SSH is enabled by default. In previous versions it was
disabled by default.
The third method is to use HTTP or HTTPS to access the Web management GUI (Web GUI).
When using HTTPS, your connection to the GUI is encrypted, so it provides the same
security benefits as SSH does for the CLI.
Management IP Address
• On Layer 2 switches, the management IP address and the default gateway are assigned
globally, only one per switch
– For example:
Switch(config)# ip address 192.22.33.45/24
Switch(config)# ip default-gateway 192.22.33.1
• On Layer 3 switches, each IP address is assigned at the interface level, not at the global
level
– The IP address of any interface on the router can be used for management
– For example:
Router(config)# interface ethernet 1/1/9
Router(config-if-e1000-1/1/9)# ip address 192.22.33.45/24
When setting the management IP address on a Layer 2 switch, the address is configured
globally, 1 per switch, using the ip address command, or for IPv6, using the ipv6
address command.
Also, the default gateway can be set globally. You can configure an IPv4 and an IPv6 address
for management access.
On a Layer 3 switch running router code, each interface can be assigned an IPv4 and/or
IPv6 address, and any of the interfaces can be used for management.
Optionally, the ICX devices have an out‐of‐band management port which we will discussed
on the next slide.
Management Port
• ICX devices have an out‐of‐band management port to manage devices without interfering
with in‐band ports
• Can be used for remote management, as well as downloading images and configurations
• The following command configures the management port
– The management port number is always 1
Ruckus(config)# interface management 1
• The management port is not part of any VLAN
• Protocols are not supported on the management port
• Creating a management VLAN disables the management port on the device
The management port is an out‐of‐band port that customers can use to manage their
devices without interfering with the in‐band ports. The management port is widely used to
download images and configurations, for Telnet sessions, and for Web management. Use
the interface management 1 command to configure the port. The management
port is always the # 1.
The following rules apply to management ports:
• Only packets that are specifically addressed to the management port MAC
address or the broadcast MAC address are processed by the Layer 2 switch or
Layer 3 switch. All other packets are filtered out.
• A packet received on the management port is not sent to any in‐band ports,
and no packets received on in‐band ports are sent to a management port.
• The management port is not part of any VLAN.
• Configuring a strict management VRF disables certain features on the
management port.
• Protocols are not supported on the management port.
• Creating a management VLAN disables the management port on the device.
Enabling & Displaying Telnet
• Enable Telnet from global CONFIG mode
Ruckus(config)# telnet server
– Disable Telnet
Ruckus(config)# no telnet server
• Display Telnet configuration and connections
Ruckus(config)# show telnet
Telnet server status: Enabled
Telnet connections (inbound):
1 established, client ip address 192.168.1.200, user is super,
privilege super-user using vrf default-vrf.
19 second(s) in idle
<Output Truncated>
• Optional features such as authentication retries, listening port and idle timeouts can be
configured
In previous releases the Telnet server is enabled by default. Beginning with release 8.0.90,
the Telnet server is disabled by default. The command to enable Telnet is telnet
server. This is entered in the global CONFIG mode. Use the no form of the command to
disable Telnet.
Remember to save your changes.
The show telnet command will show you the status of Telnet, the number of
connections, and client connection information.
SSH Support
• SSHv2 server and client functions can be performed on ICX devices
• Implementation of SSHv2 server supports three kinds of user authentication:
– DSA challenge‐response authentication
– RSA challenge‐response authentication
– Password authentication (local)
• Beginning with release 8.0.90, SSH server is enabled by default
• Restrictions of the above authentication types as well as access filtering can be specified
• Optional features such as authentication retries, listening port and idle timeouts can be
configured
ICX devices support SSHv2. The implementation of SSH server supports three kinds
of user authentication:
• DSA (Digital Signature Algorithm) challenge‐response authentication, where a
collection of public keys are stored on the device. Only clients with a private
key that corresponds to one of the stored public keys can gain access to the
device using SSH server.
• RSA challenge‐response authentication, where a collection of public keys are
stored on the device. Only clients with a private key that corresponds to one
of the stored public keys can gain access to the device using SSH server.
• Password authentication, where users attempting to gain access to the device
using an SSH client are authenticated with passwords stored on the device or
on a TACACS+ or RADIUS server.
You can adjust the following SSH server settings on the device:
• Number of SSH server authentication retries
• User authentication method the device uses for SSH server connections
• Whether or not the device allows users to log in without supplying a password
• Port number for SSH server connections
• SSH server login timeout value
• A specific interface to be used as the source for all SSH server traffic from the
device
• Maximum idle time for SSH server sessions
• Disable 3‐DES support
Enable/Disable SSH
• Beginning with release 8.0.90, SSH is enabled by default with the following settings:
– Authentication type: RSA
– Modulus (key size): 2048 bits
• Was disabled by default in previous releases
• SSH can be disabled at the Global CONFIG level:
Ruckus(config)# crypto key zeroize [rsa | dsa]
• Use rsa or dsa to delete a specific key. If not specified, both are deleted.
• It can be re‐enabled with:
Ruckus(config)# crypto key generate rsa modulus 2048
– Syntax: crypto key generate [ dsa | rsa [ modulus key-size ] ]
• Modulus: 1024 or 2048
Beginning with release 8.0.90, the SSH server is enabled on an ICX device by default. The
default authentication type is RSA with 2048 bit modulus. The SSH server can be disabled
by entering the crypto key zeroize command at the global CONFIG level.
If disabled, SSH can be re‐enabled using the crypto key generate command followed by the
algorythm (DSA or RSA) and the modulus, which can be 1024 bits or 2048 bits.
SSH Authentication
• Authentication takes place by either sharing the generated key, or by client password
challenge
– Password challenge requires that AAA be configured for “local” login, and a matching username and
password created on the device. The following is the default configuration in release 8.0.90:
Ruckus# show run | include aaa

Ruckus# show run | include username
– Additional users can be configured with the following command:
Ruckus(config)# username icx-admin priv 0 password Testpwd
• AAA configuration is covered in a separate Security and Monitoring presentation
Authentication takes place by either sharing the generated key, or by client password
challenge. On an ICX running firmware version 8.0.90 is booted from a factory default
configuration, the user super is created. The default password for this user is sp‐admin. This
password is required to be changed on initial login to the device. The show run output
here shows that the web‐server and device login now require a local user account to
permit access. There is also a username entry for the default username of super.
In releases prior to 8.0.90, the password challenge method required you to manually
configure AAA for “local” login, and you must configure a matching username and
password on the device. Users are created at the global CONFIG level. The example here
creates a user named icx‐admin. Note that the privilege of 0 creates a Super User account.
We will discuss these privileges later in this presentation.
Displaying SSH Configuration
• Use the show ip ssh config command to verify SSH parameters configured
Ruckus(config)# show ip ssh config

SSH server : Enabled Default SSH Port
SSH port : tcp\22 and authentication
Host Key : RSA 2048
Encryption : aes256-cbc, aes192-cbc, aes128-cbc, aes256-ctr,
aes192-ctr, aes128-ctr, 3des-cbc
Permit empty password : No
Authentication methods : Password, Public-key, Interactive
Authentication retries : 3
Login timeout (seconds) : 120 Authentication
Idle timeout (minutes) : 0 methods configured
SCP : Enabled
SSH IPv4 clients : All
SSH IPv6 clients : All
SSH IPv4 access-group : 12 ACL 12 is configured and
SSH IPv6 access-group : applied to SSH access
SSH Client Keys :
Client Rekey : 0 Minute, 0 KB
Server Rekey : 0 Minute, 0 KB
The show ip ssh config command displays the status of the SSH server, either

enabled or disabled, as well as the TCP port being used. The default SSH port is 22.
Next, you will see the type of host key being used, the default is RSA 2048, and the types of
encryption being used. This example, shows all the default encryption types.
Then we see the authentication information, including the methods being used, and the
number of retries. Also shown are any IPv4 or IPv6 ACLs applied to SSH access. Here we see
ACL 12 has been applied.
Web Management
• By default, HTTP access to the Web GUI is enabled on all ICX devices
• HTTP access can be disabled:
Ruckus(config)# no web-management http
• For enhanced security HTTPS can be enabled
Ruckus(config)# web-management https
• Web management can be limited only to specific VLAN
Ruckus(config)# web-management enable vlan 10
• The example limits web access to VLAN 10
By default, HTTP access to the Web GUI is enabled. This method of management can be
disabled with the no web-management http command.
For the more security conscious administrators, you can enable HTTPS access using the
same web-management command followed the https parameter.
Additionally, Web GUI access can be restricted to a specific VLAN with the web-
management enable vlan command followed by the VLAN ID, which will be the only
VLAN to allow access.
Web Management Configuration – Release 8.0.90
• With the 8.0.90 release, by default, the Web GUI uses local user accounts for access
• The following is the default configuration:
Ruckus# show run | include aaa

Ruckus# show run | include username

username icx-admin password .....
Beginning with release 8.0.90, the default method of accessing the Web GUI is logging with
the default user: super. As you can see in the output AAA authentication is enabled for the
web‐server and uses local accounts. The second output shows the default user that is
configured on a factory default ICX. Additional local users can be created to allow other
forms or access. Local users will be covered later in this presentation.
In previous releases, the default usernames were based on SNMP community string
settings. Beginning with release 8.0.90, there are no longer any default SNMP community
configurations on an ICX switch.
Privilege EXEC Passwords
• By default, passwords are not assigned to the Privileged EXEC (enable) level
– Allowing super‐user access to all commands and settings
• Three levels of authorization can be assigned to a user’s Privileged EXEC access
– Permissions depend on which password is entered
• The three levels are:
– Super User: Complete read and write access to the system
• Generally reserved for system administration
• This is the only level that that allows password configuration
• Must be set before any other passwords can be set
– Port Configuration: Read and write access for interface configuration but not for global parameters
• The user can also use show commands
– Read‐only: Access to Privileged EXEC mode, but only with read access
• No configuration is allowed at this access level
By default, the CLI Privilege EXEC mode is not protected by passwords. Do not confuse this
with device authentication. Device authentication allows you to communicate with the CLI
in User EXEC mode. The enable password is used to restrict what you can do once you have
access. To secure enable access, you need to assign passwords. There are three types of
passwords that can be created, each giving different levels of access. The three levels are
Super User, Port Configuration and Read‐Only.
• Super User can be considered administrative access, with complete read and write
access to the system. This is the only level that that allows password configuration,
and it must be set before any other passwords can be created.
• Port Configuration allows for read and write access for interface configuration but
not for global parameters. This user can also use show commands.
• Read‐only allows access to Privileged EXEC mode, but only with read access.
Privilege EXEC Passwords (cont.)
• Passwords may be up to 32 characters in length, are case sensitive, and cannot begin with
a number, for example:
– Super User
Ruckus(config)# enable super-user-password AdM1naCCe$$
– Port Configuration
Ruckus(config)# enable port-config-password P0rta((es$
– Read‐only
Ruckus(config)# enable read-only-password Re@daC(e$s
• If a password has not been set, a warning is displayed
Ruckus> enable
No password has been assigned yet...
• Syntax: enable [super-user-password | read-only-password | port-

config-password] <text>
Passwords can be up to 32 characters long and are case sensitive. Passwords cannot begin
with a number.
Here we see configuration examples of each type of password. Once a password, or
passwords, are configured and you go from User EXEC mode to Privilege EXEC mode using
the enable command, you will be prompted for a password. And depending on which
password you enter, you will be provided with that type of access. If a password has not
been created, you will see a message that no password has been assigned yet.
Syntax: enable [super-user-password | read-only-password | port-
config-password] <text>
User Access Control
• Up to 32 local user accounts can be created to allow access to management functions
including:
– Telnet and SSH connections
– Web management GUI
– SNMP access
• You can assign a username a password, or use the nopassword parameter when
creating the user account
• A Privilege EXEC level can be assigned for each user account
– 0 = Super User
– 4 = Port Configuration
– 5 = Read‐only
Ruckus(config)# username PortConfig privilege-level 4 password KLMpwd

Ruckus(config)# username No-Changes privilege-level 5 nopassword
The system also allows for the creation of up to 32 local user accounts.
Usernames can be up to 48 characters in length. Local user accounts provide greater
flexibility for controlling management access to Ruckus devices than do management
Privilege EXEC (enable) passwords and SNMP community strings. You can continue to use
the Privilege EXEC passwords and the SNMP community strings as additional means of
access authentication.
You can assign each user a password using the password parameter followed by the
password string. Passwords can be up to 48 characters.
You can also use the nopassword parameter to allow the user to log in with out
providing a password.
Optionally, you can assign each username a Privilege EXEC level as discussed previously. If a
privilege level is not specified, the user defaults to Super User.
Controlling Access
• Use the following commands to restrict SNMP, Telnet, SSH or Web GUI access to a single IP
address:
Ruckus(config)# snmp-client 209.157.22.14

Ruckus(config)# telnet client 209.157.22.26
Ruckus(config)# ssh client 209.157.22.27
Ruckus(config)# web-client 209.157.22.12
• Or use the all‐client command to restrict access of all of the above
Ruckus(config)# all-client 209.157.22.69
Once remote access is enabled for SNMP, Telnet, SSH, or the Web GUI, you can restrict
access to a specific IP addresses. Enter up to 10 different IP addresses per service. You must
enter the command for each address.
Optionally, you can use the all-client command to restrict access for all four services.
Access Filtering
• Telnet, SSH and SNMP access can be limited to specific client source IP addresses using
Access Control Lists (ACL)
– Create an ACL
Ruckus(config)# access-list 12 permit host 10.157.22.98
Ruckus(config)# access-list 12 permit 10.157.23.0/24
Ruckus(config)# access-list 12 permit 10.157.24.0/24
Ruckus(config)# access-list 12 deny any log
– Apply the ACL to access service
Ruckus(config)# ssh access-group 12
Ruckus(config)# telnet access-group 12
Ruckus(config)# web access-group 12
Ruckus(config)# snmp-server community private rw 12
You can also limit access to the remote access services using an ACL.
First create the ACL with the IP addresses or subnets you want to restrict access to, then
apply the ACL to the service (SSH, Telnet, SNMP, or Web GUI).
Remember that ACLs have an implicit deny at the end, dropping packets that do not match
the previous permit statements.
In this example, we have configured the deny statement with the log parameter allowing
us to capture any attempts from unauthorized client source addresses.
Password Recovery
• Recovering from a lost password requires direct access to the serial port and a system
reset
– This procedure can only be accomplished from the console port
• To recover from a lost password:
– Start a CLI session over the serial interface on the device, and reload the device by cycling its power
– From the CLI established session you will see the initial boot sequence during system startup
– Enter “b” to enter the boot monitor mode
Recovering from a lost password requires direct access to the console port and a system
reset. To recover from a lost password, start a CLI session over the console interface, and
manually power‐cycle the device.
From the CLI established session you will see the initial boot sequence during system
startup. Enter “b” to enter the boot monitor mode.
Password Recovery (cont.)
• Enter no password at the prompt
ICX7150-Boot> no password
OK! Skip password check when the system is up.
– This command will bypass the system password check once and cannot be abbreviated (this will not erase
any existing passwords)
• Boot the system
ICX7150-Boot> boot 1
device 0 offset 0x0, size 0xc0000
BOOTING image from Primary
<Output Truncated>
Ruckus>
• Once the console prompt reappears, enter configuration mode and assign a new password
• Save the new password using write memory
Footnote 1: In releases prior to 8.0.90 is necessary to indicate which flash to boot from
with the boot system flash [primary | secondary] command.
At the boot monitor prompt, enter the no password command. This command will
bypass the system password check once and cannot be abbreviated (this will not erase any
existing passwords).
Next, issue the boot command.
Once the console prompt reappears, enter global CONFIG mode and assign a new
password. Finally, use the write memory command to save the new password. If you do
not save the new password, the next login session will revert to the old password.
Simple Network Management Protocol
(SNMP)
Our next topic is Simple Network Management Protocol (or SNMP).
SNMP Management Applications
• ICX devices can be managed by the Ruckus SmartZone Network Controller 1, or third party
management applications which support SNMP v1/v2 or SNMPv3
• SNMP v1/v2c, prior to release 8.0.90
– By default, when an ICX device is configured as an SNMP server, the read‐only (RO) community string is
set to public
– Read‐write (RW) access is only permitted when a RW community string is explicitly configured
– Multiple read‐only and read‐write community strings can be created
• SNMP v1/v2c, release 8.0.90 defaults
– By default, the SNMP server is enabled
– There are no pre‐configured community strings
– Multiple read‐only and read‐write community strings can be created
Footnote 1: ICX management using the SmartZone Network Controller was first introduced
in SmartZoneOS 5 and ICX firmware version 8.0.80.
ICX devices can be managed by the Ruckus SmartZone network controller or third‐party
management applications as long as they support SNMP version 1, 2, or 3.
SNMP is a set of protocols for managing complex networks. SNMP sends messages called
protocol data units (PDUs), to different parts of a network. SNMP‐compliant devices, called
agents, store data about themselves in Management Information Bases (MIBs) and return
this data to the SNMP requesters. Ruckus’s private MIBs and MIB Guide can be found on
the Ruckus website at: ruckuswireless.com
SNMPv1 or v2 uses a community‐based security approach with different community
strings (think passwords) for read‐only and read‐write access.
You can assign other SNMP community strings and indicate if the string is read‐only or
read‐write.
Community strings can be configured as encrypted or clear. By default, the string is
encrypted.
SNMP Management Applications (cont.)
• SNMPv3
– Defined in RFCs 3411 to 3415
– Strengthens security of SNMPv1 and SNMPv2c
– Provides secure access to devices by authenticating and encrypting packets over the network
– The security features provided in SNMPv3 include:
• Encryption of protocol data units (PDUs)
• Authentication of the users sending the PDUs
• Specify users access to tables in a read‐only, read‐write, or notify role
• The creation of views and associating user groups to various views
• Communication with both authentication and encryption
SNMP version 3 made significant improvements in security and manageability by
introducing three major concepts:
• The first is the User‐Based Security Model or USM. Instead of having generic
group keys as with version 2, version 3 allows you to define individual
username/password combinations for user authentication. You can optionally
enable encryption. The standard also defines timeliness checks. Since SNMP
messages are often time‐critical, making sure that messages are current is
important for accuracy of information.
• The second is the Transport Security Model or TSM which uses the Public Key
Infrastructure for access authentication and encryption. PKI uses certificates to
identify devices, and those certificates must be generated and managed by a
Certificate Authority. TSM provides the same benefits as USM, using
certificates rather than username/password strings.
• Finally, version 3 introduced the concept of View‐Based Access Control. The
administrator, can group specific MIB objects into views, then use groups to
define who can access a view or set of views. For each group, you can specify
an action of read‐write or read‐only.
SNMPv1/v2 Configuration
We’ll begin with the configuration of SNMPv1/v2.
Configuring SNMP v1/v2
• Configure SNMP by configuring community strings
– Strings can be up to 32 characters
– Specify whether the string is read‐only (ro) or read‐write (rw)
• Examples:
– Configure the read‐only community string of lookaccess
Ruckus(config)# snmp-server community lookaccess ro
– Configure a read/write community string of allaccess
Ruckus(config)# snmp-server community allaccess rw
To configure version 1 and 2, you need to setup community strings using the snmp-
server community command, followed by the community string which can be up to
32 characters long. Then, specify if the string is read‐only using the ro parameter, or read‐
write using the rw parameter.
Beginning with release 8.0.90, there is no default read‐only or read‐write community
strings. You can configure as many read‐only and read‐write community strings as you
need. The number of strings you can configure depends on the memory available on the
device. There is no practical limit.
Note that the SNMP server is enabled by default, however if there are no community
strings configured, there will be no SNMP v1/2 access to the device.
SNMP Server Parameters
• Specify an SNMP trap receiver
– Host that receives SNMP notifications of events
Ruckus(config)# snmp-server host 10.2.2.2 version v2c community
• Traps for specific events can be disabled
Ruckus(config)# no snmp-server enable traps trap_name
• Change the holddown time for SNMP traps
– The delay after startup before an ICX device begins sending traps, allowing L2/L3 protocol convergence
Ruckus(config)# snmp-server enable traps holddown-time time
DECIMAL <1..600> Seconds
• Default: 60 seconds
You can specify a trap receiver to ensure that all SNMP traps sent by the Ruckus device go
to the same host, or multiple hosts, on the network.
This is done with the snmp-server host command. In the command you specify a
host, the SNMP version and additional information specific to the version selected.
All traps are enabled by default. However, specific traps can be disabled, if desired. Specific
traps are disabled with the no snmp-server enable traps command, followed by
the desired trap to be disabled. The traps vary based on whether the device is running
switch or router code.
Finally, you can disable the holddown timer for traps to be sent after the device starts up.
This allows the configured Layer2 and Layer3 protocols to converge before traps are sent.
This is meant to allow network stability before sending messages to remote devices. To
adjust the holddown timer from the default of 60 seconds use the snmp-server
enable traps holddown-time command followed by the time in seconds, ranging
from 1 to 600 seconds.
Details about all of the configurable options for each of these commands can be found in
the Ruckus FastIron Management Configuration Guide.
Displaying SNMP Settings
Ruckus(config)# show snmp server
Status: Enabled
Contact: TAC Support 1-800-555-4357
Location:
Community(ro): ..... Configured community
Community(rw): .....
Max Ifindex per module: 64 strings are encrypted
Traps
Cold start: Enable
Link up: Enable
Link down: Enable
Authentication: Enable
Power supply failure: Enable
Fan failure: Enable
Fan speed change: Enable All traps are
Module inserted: Enable enabled by default
Module removed: Enable
Redundant module state change: Enable
Temperature warning: Enable
STP new root: Enable
STP topology change: Enable
MAC notification: Enable
MAC-AUTH notification: Enable
VSRP: Enable
MRP: Enable Configured trap receivers
UDLD: Enable
VRF: Enable
link-oam: Enable
cfm: Enable
nlp-phy: Enable
Total Trap-Receiver Entries: 1
Trap-Receiver IP-Address Version Port-Number Comm-or-Security
1 10.255.243.60 v1 162 .....
Use the show snmp server command to view if community strings are configured.

Remember community strings are encrypted by default, so it will likely only display as dots.
You can also see a list of all enabled traps. This example is of from an ICX device running
switch code. Different traps will be included in the router codes. You can also see any IP
addresses of trap receivers, if they are configured.
SNMPv3 Configuration
Now we will look at configuring SNMP version 3.
SNMPv3 Configuration Steps
1. Define engine ID (optional)
2. Create Views
– Include or exclude OIDs for MIB objects
3. Create Groups
– Assign views to groups
– Authentication method
– Encryption
4. Define Users
– Assign to group
– Authentication method
– Encryption
To configure SNMP version 3, follow these steps:
• First, you can optionally define a non‐default engine ID.
• Then, create your views. You need to have a MIB browser or a list of OIDs available
in order to configure the views.
• Next, create the groups and assign the views you want available to each group.
• Finally, define the SNMP users. You can use both the User‐based Security Model and
the Transport Security Model. You’ll need to define the authentication method,
optionally enable encryption, and assign the user to a group.
Define Engine ID
• During system start up, a default engine ID is generated
Ruckus(config)# show snmp engineid

Local SNMP Engine ID: 800007c703d4c19e1f31db
Engine Boots: 32
Engine time: 57498
Engine uptime: 1 hour(s) 35 minute(s) 49 second(s)
• Use the following command to change the default engine ID, used by SNMPv3
– The local parameter indicates that engine ID to be entered is the ID of this device, representing an SNMP
management entity
Ruckus(config)# snmp-server engineid local 800007c70300e05290ab60
A default engine ID is generated during system start up. To determine the default engine ID
of the device, enter the show snmp engineid command and find the line that begins
with “Local SNMP Engine ID”.
Once you have located the engine ID, use the snmp-server engineid local
command to define the ID.
It is important to note that if the engine ID is changed after users have been created, those
users must be reconfigured after setting the new engine ID.
Creating Groups, Users, and Views
• The OID structure is a tree. If you include an object with sub‐branches, those sub‐branches
will also be included in the view
SNMP MIB Object Tree

View name:
All IP Information
View name:
All Interface
Information
View name:
Traffic Counters
Let’s look at how users, groups, and views fit together.
A view is a list of SNMP Object Identifiers, or OIDs. The administrator determines how to
group these OIDs.
The OID structure is a tree, so if you include an object with sub‐branches, those sub‐
branches will also be included in the view.
The understanding of SNMP OIDs is critical to the implementation of SNMP v3. This is an
advanced topic and therefore beyond the scope of this course.
Defining Views
• SNMP views are named groups of
MIB objects to be associated with users Group:
to allow limited access for viewing and NetAdmins
modification of SNMP statistics
View
and system configuration
• Configure SNMP views, using View
the following commands:
Users
Ruckus(config)# snmp-server view Support1 system included

Ruckus(config)# snmp-server view Support1 system.2 excluded
Syntax: [no]snmp-server view name mib_tree included | excluded
SNMP views are named groups of MIB objects to be associated with users to allow limited
access for viewing and modifying SNMP statistics and system configuration.
To create a view, use the snmp-server view command followed by the viewname
and mib_tree. Then specify if you want to included or exclude the MIB in the view.
If you include a tree, but do not want some of the objects (or branches) within that tree,
you can use the exclude parameter for those objects.
Defining Groups
• Groups map users to views
– For each group, you can configure a read view, Group:
a write view, or both NetAdmins
– Users mapped to a group will use the views
for access control View
• Configure an SNMP group, View
using the following command
Users
Ruckus(config)# snmp-server group NetAdmins v3 auth read

all write all
Syntax: [no] snmp-server group groupname { v1 | v2c | v3 { auth |

noauth | priv } } [ access {standard-ACL-id | ipv6 ipv6-ACL-
name } ] [ read viewname ] [ write viewname ]
A group is a list of views. You can have one or more views per group, and you can use the
same view in multiple groups.
The v1 , v2c , or v3 parameter indicates which version of SNMP is used. In most cases,
you will be using v3, since groups are automatically created in versions 1 and 2 through
community strings.
The auth or noauth parameter determines whether or not authentication will be
required to access the supported views. If auth is selected, then only authenticated
packets are allowed to access the view. Selecting noauth means that no authentication is
required to access the specified view. Selecting priv means that an authentication
password will be required from the users.
The access standard-ACL-id parameter is optional. It allows incoming SNMP
packets to be filtered based on the standard ACL attached to the group. IPv6 ACLS can be
applied with the ipv6 ipv6-ACL-name option.
The read viewname or write viewname parameter is optional. It indicates that
users who belong to this group have either read or write access to the MIB. The
viewname variable is the name of the view to which the SNMP group members have
access. If no view is specified, then the group has no access to the MIB. The value of
viewname is defined using the snmp-server view command discussed previously.
The SNMP agent comes with the default view of all, which provides access to the entire
MIB; however, it must be specified when creating the group. The all view also allows
SNMPv3 to be backwards compatible with SNMPv1 and 2.
Defining Users
• Create SNMP users and map the user
to the group Group:
– Define the type of authentication for NetAdmins
SNMP access
– Specify the type of encryption to encrypt View
the privacy password
– Users mapped to a group will use the views
View
for access control
Users
• Configure an SNMP user, using the following
command
Ruckus(config)# snmp-server user bob NetAdmins v3 access

2 auth md5 bobmd5 priv des bobdes
Syntax: [no] snmp-server user name groupname v3 [ [ access standard-ACL-

id ] [ [ encrypted ] [auth md5 md5-password | sha sha-password ] [
priv [ encrypted ] des des-password-key | aes aespassword-key ] ] ]
The next step is to create SNMP users and map them to the groups. Use the snmp-
server user command followed by the username and the groupname, and the v3
parameter.
The access standard-ACL-id parameter is optional. It indicates that incoming
SNMP packets are filtered based on the ACL attached to the user account.
The encrypted parameter means that the MD5 or SHA password will be a digest value.
MD5 has 16 octets in the digest. SHA has 20. The digest string has to be entered as a
hexadecimal string. In this case, the agent need not generate an explicit digest. If the
encrypted parameter is not used, the user is expected to enter the authentication
password string for MD5 or SHA. The agent will convert the password string to a digest, as
described in RFC 2574.
The auth md5 or sha parameter is optional. It defines the type of encryption that the
user must have to be authenticated.
The md5-password and sha-password define the password the user must use to be
authenticated. These password have a minimum of 8 characters.
The priv [encrypted] parameter is optional after you enter the MD5 or SHA
password. The priv parameter specifies the encryption type (DES or AES) used to
encrypt the privacy password. If the encrypted keyword is used, either enter des
followed by a 16‐octet DES key in hexadecimal format, or enter aes followed by the AES
password key.
ICX Management with SmartZone
Finally, let’s discuss ICX management with the Ruckus SmartZone network controller.
ICX Management with SmartZone Overview
• Single pane of glass
– ICX On‐Premise Management Solution is designed for managing the ICX 7K switches
• The solution is modelled after SZ based controller solution of Ruckus AP’s
– The ICX would identify the SZ controller based on DHCP discovery or configuration and connect
• In the first release only monitoring of Switches will be supported
• Key Features
– Switch registration and authentication – Switch Config file – Backup & Restore
– Inventory – Clustering and High availability
– Network health monitoring & alarms – Hierarchical switch groups
– Switch Firmware update
Ruckus SmartZone has been enhanced to provide a single pane of glass view for managing
Ruckus ICX switches and access points. The ICX management portion is designed to provide
the same look and feel as the one that has been used for APs for a long time. An ICX device
can discover the SMartZone network controller though static configuration, as we will
review here or through DHCP, which is beyond the scope of this course. As of ICX release
8.0.90 and
SmartZone release 5.0, only monitoring, configuration management and firmware upgrade
are supported. But with each new release of SmartZone the capabilities are expected to
expand into full ICX configuration.
Some of the key features include:
• Switch registration and authentication
• Inventory
• Network health monitoring & alarms
• Switch Firmware update
• Switch Config file – Backup & Restore
• Clustering and High availability
• Hierarchical switch groups
Connecting to SmartZone Network Controller
• ICX connects to SmartZone in order below:
– Statically configured active list of SmartZone network controllers
– Learned through DHCP Option 43
– Statically configured passive list of SmartZone network controller
• Configuration commands
– Active List of SmartZone controllers
Ruckus(config)# sz active-list IP-address1 [IP-address2] [IP-address3]
– Passive List of SmartZone controllers
Ruckus(config)# sz passive-list IP-address1 [IP-address2] [IP-address3]
– Disable SmartZone management
Ruckus(config)# sz disable
– Disconnect from current SmartZone controller
Ruckus# sz disconnect
SZ Disconnect initiated…
The ICX switch will attempt to connect to SmartZone by sending a query to
SmartZone IP addresses in the following order:
• SmartZone IP addresses configured on the ICX switch using the sz active
command
• SmartZone IP addresses received through DHCP Option 43
• Backup SmartZone IP addresses configured on the ICX switch using the sz
passive command
You configure Active List of SmartZone controllers with the sz active-list command
followed by up to three SmartZone controller IP addresses.
There is no configuration necessary for DHCP, by default.
You configure Passive List of SmartZone controllers with the sz passive-list
command followed by up to three SmartZone controller IP addresses.
You can disable SmartZone management completely with the sz disable command.
And you can disconnect from the currently connected SmartZone controller with the sz
disconnect command. This would be used in cases where you change which controller
you want managing the ICX device. Also note that the sz disconnect command is run
from privileged EXEC mode, not global config like the others.
SmartZone Connection and Management
• On successful connection to the SmartZone controller a CLI message is displayed
Ruckus#
################################
# Welcome to vSZ #
################################
• Sessions used by SmartZone to manage the switch
– Telnet
• For administrative operations – currently only image download
– Syslog
• All syslogs generated by switch are sent to SZ, which gets classified based on user preferences
– SNMP
• The SZ Queries the Switch operational status periodically (every 5 mins) via the SNMP Channel
On successful connection to the SmartZone network controller, a message will displayed
indicating connection.
Once connected, the SmartZone network controller uses the following connections to
manage an ICX device:
• Telnet – For administrative operations – currently only image download
• Syslog – All syslog messages generated by switch are sent to SZ, which gets classified
based on user preferences
• SNMP – The SZ Queries the Switch operational status every 5 minutes
Displaying SmartZone Connection Status
ICX7250-24 Switch# show sz status
============ SZ Agent State Info ===================
Config Status: None Operation Status: Enabled
State: SZ SSH CONNECTED Prev State: SZ SSH CONNECTING Event: NONE
Active List : 10.176.187.195
DHCP Option 43 : Yes
DHCP Opt 43 List : 10.176.160.115
Passive List : 10.176.160.120
Merged List : 10.176.187.195, 10.176.160.115, 10.176.160.120
Merged Idx: 1 IP : 10.176.160.115
SZ IP Used : 10.176.187.195
SZ Query Status :
Response Received
SSH Tunnel Status - :
Tunnel Status : Established
CLI IP/Port : 127.255.255.253/43951
SNMP IP/Port : 127.255.255.254/13573
Syslog IP/Port : 127.0.0.1/20514
Timer Status : Not Running
The show sz status command displays various details of the management

connection. This includes the state, highlighted here. It also shows all known SmartZone
controllers whether learned through statically defined active and standby lists as well as
any learned through DHCP option 43. Lastly, it shows the status of all of the tunnels used to
manage the ICX device.
Summary
• You should now be able to:
– Describe the different methods available for device connection including the console port, Telnet, SSH,
and Web management access
– Describe the function of the management port
– Know how to create local user accounts and passwords
– Describe and configure Simple Network Management Protocol (SNMP)
– Explain how to connect ICX devices to SmartZone network controller
You should now be able to:
• Describe the different methods available for device connection including the console
port, Telnet, SSH, and Web management access.
• Describe the function of the management port
• Know how to create local user accounts and passwords
• Describe and configure Simple Network Management Protocol (SNMP)
• Configure an ICX switch to connect to and be managed by the SmartZone network
controller
End of Module 6:
Device Access & Management
ICX 150 Device Security and Monitoring
Module 7:
Device Security & Monitoring
This module will cover Device security and monitoring
Objectives
• After completing this module, you will be able to:
– Use Authentication, Authorization, and Accounting (AAA), RADIUS and TACACS+ to secure an ICX device
– Enable 802.1X to provide port‐based network access control using authentication
– View system log (Syslog) messages to monitor an ICX device
– Collect a show tech-support or supportsave file
– Use sFlow to collect traffic information
After completing this module, you will be able to:
• Use Authentication, Authorization, and Accounting (AAA), RADIUS and TACACS+ to
secure an ICX device
• Enable 802.1X to provide port‐based network access control using authentication
• View system log (Syslog) messages to monitor an ICX device
• Collect a Show Tech‐support or Supportsave file
• Use sFlow to collect traffic information
Device Security
Let’s start with a look at device security.
Authentication, Authorization, and Accounting (AAA)
• AAA is a term for a framework for intelligently controlling access to computer resources,
enforcing policies, and auditing usage
• Authentication provides a way of identifying a user
– The AAA server compares a user's authentication credentials with other user credentials stored in a
database
– If the credentials match, the user is granted access
– If the credentials differ, authentication fails and network access is denied
• Authorization maintains what a user is allowed to do
• Accounting is a method of tracking user behavior
AAA is a term for a framework for intelligently controlling access to computer resources,
enforcing policies, and auditing usage generally using a remote server running the RADIUS
or TACACS/TACACS+ protocol.
Authentication provides a way of identifying a user, typically by having the user enter a
unique, valid user name and password before access is granted.
RADIUS stands for Remote Authentication Dial‐in User Service, and is a client/server
protocol that runs in the application layer, using UDP as transport. The Remote Access
Server, the Virtual Private Network server, the Network switch with port‐based
authentication, and the Network Access Server, are all gateways that control access to the
network, and all have a RADIUS client component that communicates with the RADIUS
server.
TACACS stands for Terminal Access Controller Access‐Control System, commonly used in
Unix networks, and is a remote authentication protocol used to communicate with a
remote authentication server.
TACACS+ offers multiprotocol support, such as IP and AppleTalk. Normal operation fully
encrypts the body of the packet for more secure communications. It is not backwards
compatible with TACACS. It is a Cisco proprietary enhancement to the original TACACS
protocol, and has, for all intents and purposes, replaced TACACS.
Factory Default Authentication Behavior
• The following configuration is present in the factory default configuration of an ICX switch
running release 8.0.90
enable aaa console
no telnet server
username super password ******* (default = sp‐admin)
• aaa authentication – Specifies a service and methods for authenticating access to
that service
– Services include web management interface (web-server) and Telnet/SSH access to CLI (login)
– Method is local (local username) for both
• enable aaa console – Ensures console port requires authentication
• no telnet server – Disables the Telnet server
• username – Sets user and password allowed authentication access
The configuration displayed here is present in the factory default configuration of an ICX
switch running release 8.0.90.
The aaa authentication command specifies a service and methods for
authenticating access to that service. These services include web management interface
(web-server) and Telnet/SSH access to CLI (login).
The enable aaa console command ensures console port requires authentication.
The no telnet server command disables the Telnet server.
The username command and password define a local user account that is allowed
authentication access.
AAA Configuration
• The AAA process can be configured to use the below authentication methods/servers
– RADIUS
– TACACS or TACACS+
– Local user accounts
– Enable (Privilege EXEC level)
– Line (Telnet)
– None
• Authentication servers are required to be identified in a device if used for AAA services
Ruckus(config)# radius-server host 10.157.22.99

Ruckus(config)# tacacs-server host 10.94.6.161
The AAA process can be configured to use these authentication methods/servers:
• For the RADIUS server, you also must identify the server to the device using the
radius-server command.
• For a TACACS/TACACS+ server, you can use either parameter. You also must identify
the server to the device using the tacacs-server command
• You configure a local user name and password on the device. Local user names and
passwords are configured using the username command.
• Enable (Privilege EXEC Level) gives you super‐user control. You would use the
password you configured on the device. The enable password is configured using the
enable super-userpassword command.
• Line (Telnet): This is the password you configure for Telnet access. The Telnet
password is configured using the enable telnet password command
• None: Means no authentication is used. The device automatically permits access.
Multiple servers for an authentication method can be configured however they will be used
in the order they were entered into the configuration. If the first is not available the next
server entry will be used.
AAA Methodology
• Authentication methods can be listed in order of preference
– If a remote server is not available the next method will be attempted
• Use the login parameter to use AAA authentication for access by either console or Telnet
– Try the TACACS+ server, then the local database, then allow access
Ruckus(config)# aaa authentication login default tacacs+ local none
Ruckus(config)# enable telnet authentication
• Use the enable parameter to use AAA authentication for access to the Privilege EXEC
level of the CLI
– Try the RADIUS server, then the local user database
Ruckus(config)# aaa authentication enable default radius local
Up to 7 authentication methods can be configured and are considered in the order they are

listed. If the first authentication method is successful, the software grants access and stops
the authentication process. If the access is rejected by the first authentication method, the
software denies access and stops checking. However, if an error occurs with an
authentication method, the software tries the next method on the list, and so on.
For example, if the first authentication method is the TACACS+ server but the link to the
server is down, the software will try the next authentication method in the list. If an
application method is working properly but the password (and username, if applicable) is
not known to that method, this is not a system error. The authentication attempt stops,
and the user is denied access.
Once AAA authentication preferences are configured they can be applied to an access
method. In addition to the examples shown here, AAA can be used for SNMP, 802.1X and
Web GUI access.
Use the commands aaa authentication snmp-server default, aaa
authentication dot1x default and aaa authentication web-
server default followed by the desired authentication methods.
You should exercise great caution when configuring
authentication method lists. It is possible to lock yourself
out from access to the switch if each of the methods in the
list are not properly configured.
IEEE 802.1X
Next, we will take a look at port security using the IEEE 802.1X standard
802.1X Overview
• Designed to provide port‐based network access control at the network edge
• Network access is blocked until client credentials are provided to authentication server
• 802.1X Highlights:
– 802.1x compliant client devices provide username/password
• Also allows non‐compliant/headless devices based on MAC address
– Dynamic VLAN assignment
– Restrict client to specific VLAN on authentication failure
• The ICX implementation of 802.1X supports the following RFCs:
– RFC 2284 PPP Extensible Authentication Protocol (EAP)
– RFC 2865 Remote Authentication Dial In User Service (RADIUS)
– RFC 2869 RADIUS Extensions
ICX devices support the IEEE 802.1X standard for authenticating devices attached to LAN
ports. Using 802.1X port security, you can configure a device to grant access to a port based
on information supplied by a client to an authentication server.
When a user logs on to a network that uses 802.1X port security, the Ruckus device grants
(or does not grant) access to network services after the user is authenticated by an
authentication server. The user‐based authentication in 802.1X provides an alternative to
granting network access based on a user's IP address, MAC address, or sub network.
Extensible Authentication Protocol On the LAN (or EAPOL), encapsulates the Extensible
Authentication Protocol (EAP) for delivery on the Ethernet network. EAP is the protocol
used by 802.1X for authentication communication, and is referenced in RFC 2284.
802.1X Operation
• Device roles in an 802.1X configuration:
– Client/Supplicant PAE – Network client device requiring access
– Authenticator PAE – Ruckus ICX switch
– Authentication Server – RADIUS server
• Using Extensible Authentication Protocol over LAN (EAPOL):
– Clients provide authentication credentials to authenticator
– Authenticator send credential to authentication server for validation
– If authenticated, network access is granted to the client
• Controlled and uncontrolled ports
– Uncontrolled ports allow EAPOL message exchange during authentication, no user traffic
– Controlled ports allow user traffic after successful authentication
A physical port on the device using 802.1X has two virtual access points: a controlled port
and an uncontrolled port. The controlled port provides full access to the network. The
uncontrolled port provides access only for EAPOL traffic between the client and the
authentication server. When a client is successfully authenticated, the controlled port is
opened to the client.
Before a client is authenticated, only the uncontrolled port on the authenticator is open.
The uncontrolled port allows only EAPOL frames to be exchanged between the client and
the authentication server. The controlled port is in the unauthorized state and allows no
traffic to pass through.
During authentication, EAPOL messages are exchanged between the supplicant and the
authenticator Port Access Entity (PAE), and RADIUS messages are exchanged between the
authenticator PAE and the authentication server which is a RADIUS server.
If the client is successfully authenticated, the controlled port becomes authorized, and
traffic from the client can flow through the port normally.
802.1X Example
• Supplicant PAE
– Supplies client information to Authenticator PAE using
EAP encapsulated in EAPOL
• Authenticator acts as a client to the RADIUS
authentication server
• RADIUS server authenticates user
– On success, port transitions to Controlled
• User traffic flows
– On failure, port remains Uncontrolled
• User traffic still blocked
Here we see 802.1X device roles and how they communicate.
When the client initiates network access, credentials are passed to the ICX switch
encapsulated in EAP over LAN (EAPOL) messages. The authenticator uses RADIUS messages
to pass this information to the authentication server, which determines whether the client
can access services provided by the authenticator. If the client is successfully authenticated
by the RADIUS server, the port transitions to a Controlled port. If authentication fails, or
when the client logs off, the port becomes unauthorized again and transitions to
Uncontrolled, allowing EAPOL messages but no user traffic.
Ruckus's 802.1X implementation also supports dynamic VLAN assignment. If one of the
attributes in the Access‐Accept message sent by the RADIUS server specifies a VLAN
identifier, and this VLAN is available on the Ruckus device, the client's port is moved from
its default VLAN to the specified VLAN. When the client disconnects from the network, the
port is placed back in its default VLAN.
When a client that supports 802.1X attempts to gain access through a non‐802.1X‐enabled
port, it sends an EAP start frame to the Ruckus device. When the device does not respond,
the client considers the port to be authorized, and starts sending normal traffic.
802.1X Configuration for Supplicant PAE
• Identify the RADIUS server to the Ruckus device
Ruckus(config)# radius-server host 10.157.22.99 auth-port 1812 acct-port
1813 default key mirabeau dot1x
Syntax: radius-server { hostip-addr | ipv6-addr | server-name } [ auth-port

num | acct-port num |default ] [ key string ] [ dot1x ]
• Assigning the authentication method
Ruckus(config)# aaa authentication dot1x default radius
• Enable 802.1X on switch and specify ports
Ruckus(config)# authentication
Ruckus(config-authen)# dot1x enable
Ruckus(config-authen)# dot1x enable ethernet 1/1/11 to 1/1/16
To enable 802.1X, first configure the RADIUS server, or servers, being used for
authentication. Provide the IP address and the authentication port for the server, the
default port is 1812.
Also specify the default RADIUS key string followed by the dot1x parameter. The RADIUS
key is configured globally using the radius‐server key command followed by a 1‐32
character string.
Next, configure the AAA authentication parameters for 802.1X, the default method is
RADIUS.
Finally, configure 802.1X on the Ethernet interfaces by accessing the authentication
configuration sub‐level, enabling dot1x globally, then enable the desired interface or range
of interfaces.
Device Monitoring
Next we will take a look at some system monitoring tools including system logging, show
tech, supportsave, and sFlow.
System Logging
Let’s start with system logging using the Syslog.
System Logging (Syslog) Overview
• Ruckus ICX switches maintain local Syslog database which can be viewed using the show
logging command
• By default, local Syslog database is erased on system reboot or power loss
• By default, the local Syslog database retains 50 messages
– Can be changed to 1 to 1000 messages
– The change requires a reload of the device
Ruckus(config)# logging buffered 1000

Ruckus(config)# write memory
Ruckus(config)# exit
Ruckus# reload
Devices write messages to a local system log (Syslog), which by default stores 50 messages.
Older messages will be flushed to make room for new messages (FIFO). You can change the
number of messages the Syslog buffer can store, the value is 1 to 1000 messages. If you
make a change to the Syslog buffer, you must save the configuration and reload the device
for the change to take effect.
If you decrease the size of the buffer, the software clears the buffer before placing the
change into effect.
If you increase the size of the Syslog buffer, the software will clear some of the older locally
buffered Syslog messages.
Remote Syslog Servers
• Defined in RFC 5424, Syslog can send event messages to a remote logging server using UDP
port 514, by default
• Sending to a remote server ensures logging events are saved, even after a system reboot
• For example, log messages may be sent to a Syslog server at IP address 10.255.252.10
Ruckus(config)# logging host 10.255.252.10
– Up to six external servers can be configured
– Messages are written to the local Syslog and the remote server
You can specify the IP address or host name of up to six external Syslog servers. When you
specify a Syslog server, the Ruckus device writes the messages to both to the local system
log and to the Syslog server.
Using a Syslog server ensures that the messages remain available even after a system
reload. The local Syslog is cleared during a system reload or reboot, but the Syslog
messages sent to the Syslog server remain on the server.
Real‐Time Display of Syslog Events
• Enable real‐time display of Syslog messages to the serial console
Ruckus(config)# logging console
– Enter no logging console to turn it off
• Both logging console and terminal monitor commands are required to

monitor on Telnet and SSH
– Command is a toggle, enter terminal monitor to turn logging on
Ruckus# terminal monitor
Syslog trace was turned ON
SYSLOG: <9>device, Power supply 2, power supply on left connector, failed
SYSLOG: <14>device, Interface ethernet 6, state down
SYSLOG: <14>device, Interface ethernet 2, state up
– Enter terminal monitor again to turn logging off
Ruckus# terminal monitor
Syslog trace was turned OFF
To view a real‐time display of Syslog messages on your console, use the logging
console command at the CONFIG level.
To turn this feature off, use no logging console command.
If you are logged in remotely using SSH or Telnet, you will not see the Syslog messages on
your screen. To see the messages, you need to configure the logging console
command and then run the terminal monitor command at the Privilege EXEC level.
This only applies to the current active Telnet or SSH session. Does not affect any other
active session.
To turn this off you toggle the terminal monitor command.
Disabling Message Levels
• Message levels have the following values in order of severity:
– Alerts (A) – Errors (E)
– Critical (C) – Informational (I)
– Debugging (D) – Notifications (N)
– Emergencies (M) – Warnings (W)
• The example shows that all levels are being logged
Ruckus# show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Buffer logging: level ACDMEINW, 3 messages logged
level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning
• Individual message levels can be disabled
Ruckus(config)# no logging buffered warning
– The example disables warning (W) messages
– Message levels are disabled on an individual basis
– Changes also apply to messages sent to external Syslog servers
Ruckus software writes syslog messages at the following severity levels:
• Emergencies
• Alerts
• Critical
• Errors
• Warnings
• Notifications
• Informational
• Debugging
In the show logging command output shown here you can see that all levels are being
logged, as designated by the first letter of each level, "A" for Alerts etc.
You can disable specific message levels using the no logging buffered command
followed by the desired level. The example disables Warning messages from being logged.
These changes also apply to messages sent to the external Syslog servers.
Show Tech‐Support
Next we will take a look at collecting technical support data using the show tech-
support command.
show tech-support Output
• The show tech-support command displays the following

information:
– Header for all the show commands – Active stack (if applicable)
– Running configuration – Last packet (Application Data)
– Image version – Possible data structure
– Port status – MCT cluster details
– Port counters – License details
– Static and dynamic log buffers – Stacking information
– dm statistics – Dot1x
– Boot, monitor, and system – DHCP snooping
– Registers information – SSH
– Possible stack trace – System Health
When calling Ruckus Technical Support (TAC) with an issue, the first thing they will ask for is a
“show tech”. The show tech-support command displays the output of several show
commands at once. This output can then be sent to Ruckus TAC. The output from this command
varies depending on the device configuration. The default information includes the following
information on this slide. Take some time to view this slide, then advance to the next slide
• Header for all the show commands
• Running configuration
• Image version
• Port status
• Port counters
• Static and dynamic log buffers
• dm statistics
• Boot, monitor, and system
• Registers information
• Possible stack trace
• Active stack (if applicable)
• Last packet (Application Data)
• Possible data structure
• MCT cluster details
• License details
• Stacking information
• Dot1x
• DHCP snooping
• SSH
• System Health
show tech-support Example
Ruckus# show tech-support

==========================================================================
BEGIN : show running-config The start of each show
CONTEXT : CONSOLE#0 : CONFIG command output is
TIME STAMP : 23:10:57.051 GMT+00 Tue Jan 04 2000
HW/SW INFO : ICX7150-C12-POE/SPS08090 designated by BEGIN:
==========================================================================
Current configuration:
!
<Output Truncated>
==========================================================================
TIME STAMP : 23:10:57.072 GMT+00 Tue Jan 04 2000 The end of each show
END : show running-config command output is
TIME TAKEN : 12702394 ticks (12702394 nsec) designated by END:
==========================================================================
==========================================================================
BEGIN : show version
CONTEXT : CONSOLE#0 : HW INFO
TIME STAMP : 23:10:57.072 GMT+00 Tue Jan 04 2000
HW/SW INFO : ICX7150-C12-POE/SPS08090
==========================================================================
<Output Truncated>
The format of the show tech-support output is modified to include a header for each

of the subcommands which gets called from the CLI to help in automated parsing and
lookup of the output. The header contains the following keywords:
• BEGIN ‐ which indicates the start of the subcommand output. If the command is an
internal command, a textual description of the command is displayed.
• CONTEXT ‐ indicates where the subcommands are executed (INTERNAL, MP, MP‐OS,
LP, or LP‐OS).
• TIME‐STAMP ‐ A time stamp, with millisecond granularity, helps in determining the
time difference between separate runs of the same command.
• HW/SW INFO ‐ Indicates the hardware and software version information of the
device.
The footer contains the following information:
• TIME STAMP ‐ A time stamp, with millisecond granularity, helps to determine
the time difference between separate runs of the same command.
If NTP or local clock is not set in a device, then header displays Epoch time in
the TIMESTAMP field. Epoch time is a universal time which starts from Jan 1,
1970. Therefore, for Linux platforms, the Epoch time format is 00:00:00.000
GMT+00 Thu Jan 01 1970. For non‐Linux platforms, the Epoch time format is
Jan 01 00:00:00.000.
• END ‐ Indicates the sub‐command which has completed execution.
• TIME TAKEN ‐ Indicates the total time taken in nanoseconds for the command
execution.
In addition to the header, the show clock command is run at the beginning and the end
of the show tech for elapsed time calculation.
show tech-support Options
• There are several options that can be added to the output of show tech-support
show tech-support [ acl | cluster | cpu | l2 | l3 { ipv4-uc | ipv6-uc } |

license | memory | multicast | multicast6 | openflow | packet-loss | poe
| stack ]
– For example, the packet-loss option can be used to add packet statistic debug information to the
output
Additional options can be added to the show tech output that may be specifically

related to the type of issue you are collecting data for. These include:
• acl – Generates system and debugging information specific to ACL configurations and
counters.
• cluster – Generates system and debugging information specific to cluster
configurations.
• cpu – Generates CPU‐related information.
• license – Generates license‐related information.
• l2 – Generates system and debugging information specific to Layer 2 configurations.
• l3 – Generates system and debugging information specific to Layer 3 configurations.
• memory – Generates memory‐related information of the device.
• multicast – Generates system and debugging information specific to Layer 2 and
Layer 3 multicast configurations.
• multicast6 – Generates system and debugging information specific to Layer 2 and
IPv6 Layer 3 multicast configurations
• openflow – Displays Openflow related details.
• packet‐loss – Generates packet statistics‐related debugging information.
• poe – Generates system and debug information related to Power over Ethernet
configurations.
• stack – Generates system and debugging information specific to stacking
configurations.
SupportSave
When the information in the show tech-support is not enough, TAC may have you

run a SupportSave.
Supportsave
• Supportsave is useful when collecting a large amount of debug information for
troubleshooting purposes
– Often requested Ruckus technical support when troubleshooting a issue
• Advantages over a show tech
– Allows you add custom commands (show or debug) to collect specific data that is not included in show
tech-support
– Allows the transfer of collected data to an external server such as a Trivial File Transfer Protocol (TFTP)
server
• If you add a large number of custom commands to the supportsave, it may collect a large
amount of data
– Try not to collect a supportsave during peak network activity
Another useful troubleshooting tool is Supportsave. By default the supportsave
command collects the same information found in the show tech-support command,
but it allows you to add custom show and debug commands to collect specific data not
found in a show tech-support.
If you add a large number of custom commands to the Supportsave, it may greatly increase
the file size. If possible, do not collect the Supportsave during peak network activity.
When supportsave is executed, it collects all the required logs and information and
saves it to an external TFTP server.
On an ICX stack, you do not need to run the supportsave command on all the members
in a stack, you only need to run it from the active controller. The active controller will
collect logs from all stack members and send them to the TFTP server.
Supportsave
• Supportsave parameters
supportsave [all | os | platform | l2 | l3 | custom | core | system |
infra] [display | tftp_server_IP] tftp_server_relative_pathname
[user_tag]
– Specify which logs to collect
• all ‐ all related log files
• os ‐ operating system (OS) related information
• platform ‐ platform related information
• l2 ‐ Layer 2 related information
• l3 ‐ Layer 3 related information
– Specify output destination (display or TFTP server)
• Options include
– user_tag – a string to uniquely identify the supportsave file
– tftp_server_IP – TFTP server where logs are uploaded
As previously mentioned, by default, the Supportsave collects the same information found
in the show tech‐support, but it can be customized to collect even more by specifying
which logs or customer commands to collect. By using the custom parameter, you can
enter a list of custom command data to collect.
A few of the different log types are listed here, for a full list, please refer to the ICX
documentation on the Ruckus website.
Once you have specified the logs and command information to collect, you can use the
user_tag parameter to name the Supportsave file, and specify the IP address of the TFTP
server.
Supportsave Limitations
• Only one supportsave can be executed at a time
• When supportsave is being collected, other CLIs are not allowed on that session
– Other sessions can be used to execute other commands
• Use supportsave show to view the status of the file collection
• Use supportsave cancel to terminate the file capture
At any given time, only one Supportsave can be run. If you have a Telnet session and run
the supportsave command you will see a progress bar indicating the progress of the file
collection. Once the Supportsave is run, the Telnet session is blocked for other commands.
However, other Telnet sessions to the same switch can be used to execute commands.
The supportsave show command gives the status of the file collection, and
supportsave cancel will terminate file capture.
sFlow
Our final topic in this module is sFlow.
sFlow Overview
• sFlow is a Industry standard system for collecting information about traffic flow patterns
and quantities for a set of devices
– Ruckus supports sFlow v5 by default(RFC 3176)
• Configure an ICX device to perform the following tasks:
– Sample packet flows
– Collect packet headers from sampled packets to gather ingress and
egress information on these packets
– Compose flow sample messages from the collected information
– Relay messages to an external device known as a collector
sFlow is a industry standard system for collecting information about traffic flow patterns
and quantities of packets for a set of devices. Ruckus supports sFlow version 5, which
replaces version 4 in RFC 3176.
You can configure a Ruckus device to perform the following tasks:
• Collect sample packet flows.
• Collect packet headers from sampled packets to gather ingress and egress
information about these packets.
• Compose flow sample messages from the collected information.
• Relay messages to an external device known as a collector.
sFlow Deployment
• Sample data is collected from inbound traffic on ports enabled for sFlow
• Real time at central collector(s)
– Support for up to
4 collectors
– IPv4 and IPv6
supported
Ruckus ICX devices support sFlow packet sampling of inbound traffic only.
These devices do not sample outbound packets. However, ICX devices
support byte and packet count statistics for both traffic directions.
sFlow is supported on all Ethernet ports (10/100 Mbps, 1 GbE, and 10 GbE).
The ICX has support for up to 4 sFlow collectors, which can be configured by IPv4 and IPv6
addresses.
sFlow Components
• Sampling rate
– Is the average ratio of the number of packets incoming on an sFlow‐enabled port, to the number of flow
samples taken from those packets (1 in every N packets)
• sFlow sampling requires increased LP CPU usage and can affect switch performance in some configurations
– Best Practice
• Begin with a conservative capture ratio and scale up as needed to ensure that the management CPU is not
overwhelmed
• Polling interval
– The polling interval defines how often sFlow byte and packet counter data for a port is sent to the sFlow
collectors
The sampling rate is the average ratio of the number of packets incoming on an sFlow‐
enabled port. The sampling rate is a fraction in the form of 1/N, meaning that, on average,
one out of every N packets is sampled. The sflow sample command at the global
CONFIG level or port level specifies the value of N, the denominator of the fraction. Thus a
higher number for the denominator means a lower sampling rate since fewer packets are
sampled. Likewise, a lower number for the denominator means a higher sampling rate
because more packets are sampled. For example, if you change the denominator from 512
to 128, the sampling rate increases, because four times as many packets will be sampled.
It is important to note that setting a high sampling rate can have a detrimental result in
switch performance.
The polling interval is how often sFlow byte and packet counter data for a port is sent to
the sFlow collector.
The sFlow collector is the external device to which you are exporting the sFlow data. If
multiple ports are enabled for sFlow, the Ruckus device staggers transmission of the
counter data to smooth performance. For example, if sFlow is enabled on two ports and
the polling interval is 20 seconds, the Ruckus switch will send counter data every ten
seconds with data for one of the sFlow enabled ports.
Sflow Configuration
• Enable sFlow on the switch
Ruckus(config)# sflow enable
• Specify sFlow collectors
Ruckus(config)# sflow destination 10.10.10.1
• Change the polling interval and sampling rate (optional)
– Globally
Ruckus(config)# sflow polling-interval 30
Ruckus(config)# sflow sample 6144
– Individual port sample rates
Ruckus(config-if-e1000-1/1/1)# sflow sample 4096
• Configure sFlow collection on interfaces
Ruckus(config-mif-1/1/1-1/1/8)# sflow forwarding
The process for configuring sFlow starts with enabling sFlow globally.

Next, configure the sFlow collectors, up to 4 of them, using the sflow destination
command followed by the IP address of the collector. You have to enter this command for
each collector. The default UDP port used to listen for sFlow data is 6343. This can be
changed by specifying a port after the IP address of the destination.
Syntax: [no] sflow destination ip-addr [dest-udp-port]
Next, configure the polling interval and sampling rate. The default polling interval is 20
seconds. You can change the interval to a value from 1 to any higher value. The interval
value applies to all interfaces on which sFlow is enabled. If you set the polling interval to 0,
counter data sampling is disabled.
Syntax: [no] sflow polling-interval secs
You can change the default global sampling rate. You also can change the rate on an
individual port basis, overriding the global sampling rate. The default rate is 2048. Care
should be taken in choosing a sampling rate. If you change the denominator from 2048 to
512, for example, the sampling rate increases four times. In other words, the lower the
number chosen for the sample, the higher the increase in system utilization.
Syntax: [no] sflow sample num
Finally, configure sFlow forwarding on the interfaces.
Summary
– Use Authentication, Authorization, and Accounting (AAA), RADIUS and TACACS+ to secure an ICX device
– Enable 802.1X to provide port‐based network access control using authentication
– View system log (Syslog) messages to monitor an ICX device
– Collect show tech‐support or Supportsave outputs
– Use sFlow to collect traffic information
This concludes the Device Security and Monitoring module. You should now be able to:

• Secure an ICX device using AAA
• Configure 802.1x on Ethernet interfaces
• Describe the different levels of Syslog messages
• Explain the difference between Show Tech‐support and Supportsave files
• Describe how sFlow can collect traffic flowing through an ICX device
End of Module 7:
Device Security & Monitoring
This is the end of Module 8, Device Security and Monitoring.
ICX 150 Layer 2 Fundamentals
Module 8:
Revision 0419

switch. In this module we will discuss Layer 2 Fundamentals.
Objectives
– Configure VLANs and associate tagged and untagged ports
– Describe and configure Virtual Routing Interfaces (VE ports)
– Describe Link Aggregation Groups and the supported types on ICX devices
– Configure LAGs on ICX devices
– Explain how to effectively manage LAGs along with member ports of a LAG
After completing this module, you should be able to:
Configure VLANs and associate tagged and untagged ports
Describe and configure Virtual Routing Interfaces (VE ports)
Describe Link Aggregation Groups and the supported types on ICX devices
Configure LAGs on ICX devices
Explain how to effectively manage LAGs along with member ports of a LAG
VLAN Configuration
We’ll start with how to configure VLANs on the Ruckus ICX devices.
149_VLANs.png
VLANs
• ICX devices support port‐based and
protocol‐based VLANs
– The Default VLAN is 1
– By default, all interfaces belong to VLAN 1
– The Default VLAN can be changed using the
command:
default-vlan-id vlanid
For more details on ICX VLANs, please refer to the
Ruckus FastIron Layer 2 Switching Configuration Guide, • VLAN ID range is 1 to 4095
on: www.ruckuswireless.com.
– Reserved VLANs: 4087, 4090, and 4093 for Ruckus
internal, and VLAN 4094 for Single STP
ICX devices support port‐based and protocol‐base VLANs. By default VLANs are
port‐based and this module focuses on port‐based VLANs.
For more details on ICX VLANs, please refer to the Ruckus FastIron Layer 2 Switching
Configuration Guide, on www.ruckuswireless.com.
On all ICX devices, VLAN 1 is considered the Default VLAN and it is a port‐based
VLAN.
All ports start out as members of VLAN 1. The Default VLAN can be changed using
the default-vlan-id command. Valid VLAN IDs are 1 through 4095, though
some IDs are reserved. VLAN ID 4094 is reserved for Single Spanning Tree, and
VLANs 4087, 4090, and 4093 are reserved for Ruckus internal functions.
VLANs with 802.1Q Tagging
• VLAN tagging allows multiple VLANs to span switches
over a single physical link
– When VLANs span multiple switches, a trunk data link is required
between the switches providing VLAN tagging
• Provides VLAN membership information within the
frame when forwarded to other devices
• Example Configuration:
Ruckus2(config)# vlan 10 name GRAY
Ruckus2(config-vlan-10)# tagged e 1/1/9
Ruckus2(config-vlan-10)# vlan 20
Ruckus2(config-vlan-20)# tagged e 1/1/9
VLAN tagging is necessary when VLAN traffic is forwarded on the same link between two
switches know as a trunk. Frames moving between switches are tagged so that the next
switch in the traffic flow path knows the destination VLAN of the frame.
In any part of the network that are or need to be VLAN‐aware include VLAN tags. The VLAN
tag represents the VLAN membership of the frame's port or the port/protocol combination,
depending on whether the network uses port‐based or port‐and‐protocol‐based VLAN
classification.
The VLAN ID that is in the tag enables each device that receives the frame to determine
which VLAN the frame belongs to. Each frame must be distinguishable as being within
exactly one VLAN.
A port that is a member of only one VLAN, like a end device port, can be associated with a
VLAN however it is added as untagged. We will discuss untagged ports next.
Creating VLANs is done at the global CONFIG level using the vlan command followed by a
VLAN ID. Again, valid IDs are from 1 to 4095. Optionally, you can configure a name for each
VLAN using the name parameter. VLAN names can be up to 32 characters long, and can
have spaces as long has the name is put in double quotations.
The next step is to add the ports to the VLAN as either tagged or untagged. Here we have
added interface 1/1/9 as tagged to both VLAN 10 and VLAN 20. Notice that VLAN 10 was
configured with a name, but VLAN 20 was not. Remember, VLAN names are optional.
VLANs without 802.1Q Tagging 153_vlans‐no‐tagging.png
• Without VLAN tagging, when multiple VLANs are configured
on a switch:
– Each VLAN requires dedicated uplinks for each VLAN between switches
– Bandwidth on the dedicated ports might not be fully utilized
– Higher cost due to port requirements
– Impossible if a high number of VLANs
are configured Untagged VLAN
Association
association
• Example Configuration:
Ruckus2(config)# vlan 10
Ruckus2(config-vlan-10)# untagged e 1/1/9
Error! Port 1/1/2 is already untagged member of
non default VLAN 3
It is possible for connected switches to have a port associated with a singe VLAN which will
send and receive packets with no tag. When doing so, these are considered untagged
frames and the end device is unaware of its VLAN association and simply forwards and
receives untagged frames.
For VLAN consistency between the two devices the directly connecting interfaces must
configured on the same VLAN and traffic associated with that particular VLAN is being
forwarded. Optionally if you want to make a VLAN migration each end can be different
associated with different VLANs. Because the VLAN ID is not being included in the frames
being forwarded each device will simply associate the incoming traffic to the VLAN the
incoming port is assigned to.
As you can see by this example, each VLAN requires a dedicated uplink which is not very
efficient or scalable, and in most cases the ports are under‐utilized.
The configuration of untagged interfaces use the untagged command before the
associated port the VLAN is being assigned to.
Notice in this example, we have two VLANs (10 and 20), being applied to two different
interfaces which are being added as untagged. This is because only one VLAN can be
associated as untagged on an interface otherwise you will receive an error as we see when
trying to apply Interface 12 as an untagged member of VLAN 4.
Mixed VLAN Traffic (tagged/untagged)
• Ports are members of the default VLAN (default VLAN 1)
• Ports can be an untagged member of 1 VLAN and a tagged member of 1 or more VLANs
• Ports when assigned as tagged in a VLAN will remain untagged in its current VLAN
assignment
– Port has to be exclusively removed as an untagged member of a VLAN to drop untagged frames
Ruckus(config)# vlan 1
Ruckus(config-vlan-1)# no untagged ethernet 1/2/2
Ruckus(config-vlan-1)# no untagged ethernet 1/3/1
Error! Port 1/3/1 is member of default VLAN only.
Cannot remove
Configuring an interface to be a tagged member of the non‐default VLAN allows it to accept
VLAN tagged frames. Any untagged frames received on the same interface are accepted
and forwarded within its default VLAN membership. In previous firmware version prior to
FastIron 8.0.80 this process was configured using the dual mode command.
In FastIron 8.0.80 or newer when an untagged membership of an interface is removed from
a non‐default VLAN, the interface will be added back to the default VLAN as an untagged
interface. Additionally an interface will be moved to the default VLAN when the last non‐
default VLAN is disassociated from the interface (tagged or untagged). In order for an
interface to be removed from the default VLAN it has to be associated with a non‐default
VLAN first otherwise you will receive an error when trying to remove it from its default
VLAN as shown.
Multi‐range VLAN
– You can specify the VLAN number and range using the to keyword between two num options that specify
the VLAN ID
• To create a continuous range of VLANs, enter command such as the following.
Ruckus(config)# vlan 2 to 7
Ruckus(config-mvlan-2-7)#
• Discontinuous VLANs
Ruckus(config)# vlan 2 4 7
Ruckus(config-mvlan-2*7)#
• Continuous and discontinuous VLANs together
Ruckus(config)# vlan 2 to 7 20 25
Ruckus(config-mvlan-2*25)#
Similar to configuring a range of interfaces, VLANs can be configured independently or a
range of VLANs if needed. Here are a few examples
Virtual Routing Interfaces
• Integrated Switch Routing (ISR)
– Ability to route between VLANs with virtual routing interfaces (VEs)
• Virtual Interfaces (VE) are logical routing interfaces used to route L3 protocol traffic
between VLANs
– Configure a VE on each VLAN that needs routing capabilities
• Routing parameters are configured on the VE, allowing for routing outside the local switch
– Parameters include:
• IPv4/v6 addresses
• Static routing associated with the VE (next‐hop) Values not
• Routing protocols such as OSPF providing bound to the
dynamic routing to and from the VLAN same ID #
• L3 redundancy protocols such as
VRRP/VRRP‐E
– It is required that the switch run ICX routing software
for this feature to work
Ruckus allows the ability to route between VLANs which is called Integrated Switch Routing
(or ISR).
ISR enables VLANs configured on the ICX to forward traffic between VLANs by routing
traffic using Layer 3 interfaces. ISR eliminates the need for an external router by routing
between VLANs internally using virtual routing interfaces known as Virtual Ethernet or VEs.
For routing between VLANs to take place a separate VE belonging to a different Layer 3
subnet to be associated to each VLAN you want to route packets. Routing parameters, ,
next‐hop static routing, routing protocols, and Layer 3 redundancy protocols can be
configured on the VE
Note that in our example, VLAN 22 does not have the same ID value as its router interface
(ve 20). When configuring these parameters they are not required to match, however it is
a best practice to do so.
Configuring Routable VLANs
• Configure port‐based VLAN
– Associate tagged or untagged ports
– Define Virtual Interface (VE)
Ruckus(config-vlan-10)# tagged e 1/1/1 to 1/1/2
Ruckus(config-vlan-10)# router-interface ve 10
• Enter into VE interface configuration
– Assign an IP address
– Associate routing protocols
Ruckus(config)# interface ve 10
Ruckus(config-ve-1)# ip address 10.1.1.1/24
First steps to allow routing between VLANs is to create and associate VE interface to a
VLAN and then assign it an IP address. Create the VE under the VLAN configuration using
the router-interface ve command with a VE ID.
For ICX devices, valid VE numbers are 1 to 4095. However, the total number of
virtual routing interfaces that are configured must not exceed the system‐max limit.
Once the VE interface is created, enter into the VE configuration to set the IP
address and any other routing parameters. The routing parameters and the syntax
for configuring them are the same as when you configure a physical interface for
routing.
ICX devices require you to assign interfaces to a VLAN before you can enter into the VE
configuration level of the CLI. Although you can see the VE configured you will receive an
error Error‐invalid ethernet interface number, until ports are assigned to the VLAN. The
example shown here configures the VE interface for VLAN 10.
ICX devices use the lowest MAC address on the device (the MAC address of port
1/1/1) as the MAC address for all ports within all virtual routing interfaces you
configure on the device.
Configuring Routable VLANs (cont.)
Ruckus(config-vlan-2)# untag eth 1/1/1 to 1/1/12
Ruckus(config-vlan-2)# interface ve 2
Ruckus(config-vif-2)# ip address 192.123.22.1/24
Ruckus(config-vif-2)# vlan 22
Ruckus(config-vlan-22)# untag eth 1/1/13 to 1/1/24
Ruckus(config-vlan-22)# interface ve 20
Ruckus(config-vif-20)# ip address 192.123.44.1/24
Here we have the configuration examples for VLANs 2 and 22.
Note that VLAN 22 does not have the same ID value as its router interface (ve 20).
These are not required to match however it is best practice to do so.
Link Aggregation Groups (LAG)
Our next topic is Link Aggregation Groups, or LAGs.
Link Aggregation Groups (LAG)
• Link Aggregation Groups (LAG) allow the combining of multiple Ethernet links into a larger
logical trunk
• The switch treats the LAG as a single logical link
– Increases bandwidth, stability, and port failure protection
• LAG member ports must connect to the same adjacent switch
– LAG requirements may vary for different platforms, such as the number of links in the LAG, specific port
boundaries, etc.
– Always check what is supported at both ends
• The benefits of link aggregation:
– Increased bandwidth (The logical bandwidth can be dynamically changed as the demand changes)
– Increased availability
– Load sharing
– Rapid configuration and reconfiguration
Link Aggregation Groups or LAGs have many names, such as trunks, NIC teaming, and port
channels.
In any case, LAGs allow the combining of multiple Ethernet links into a larger logical trunk.
This provides benefits to the link by increasing its overall bandwidth, increases stability of
the overall link since it is not dependent on just a single ports health which also provides
increase failure protection.
In a LAG, individual port members can fail but do not cause traffic interruption since other
remaining healthy port members can still forward traffic.
For ports to participate in a LAG, the physical links must have similar characteristics and
must connect to the same adjacent switch or group of switches represented as one like in
Multi‐Chassis‐Trunking.
LAG requirements may vary for different platforms, such as the number of member in the
LAG, specific port boundaries, etc., always check what is supported on the devices on both
ends of the LAG.
LAG Creation Rules
• All ports configured in a LAG must have these same attributes
– VLAN membership and port tag‐type (tagged/untagged)
– Port speed and duplex
– QoS priority
– L3 configuration (member ports) or Policy Based Routing (PBR)
– Are not configured as member ports of another LAG
• Ruckus provides support for static and dynamic LAGs on the same switch
• Starting in FastIron 8.0.61, all member ports of the LAG are treated as secondary ports
– Physical port can be added or removed from the LAG without tearing down the LAG
– LAG virtual interface is created when a LAG is configured
– A mode called LAG virtual interface is introduced and the properties of the LAG can be modified using the
respective commands in the LAG virtual interface mode (similar to an Ethernet interface)
– The first physical port added to the LAG becomes the MAC provider for the LAG virtual interface
When combining ports into a LAG, the ports must have same attributes. LAG formation
rules are checked when a new port is associate with the LAG. Items that will be checked
are:
• VLAN membership and port tag‐type (tagged/untagged)
• Port speed and duplex
• QoS priority
• Layer 3 configuration. member ports cannot have L3 or Policy Based Routing
(PBR) configured
ICX devices support the use of static and dynamic LAGs on the same device.
LAG Types
• ICX devices support the following LAG types:
– Dynamic LAG – uses Link Aggregation Control Protocol (LACP), to maintain aggregate links over multiple
ports
• LACP PDUs are exchanged between ports on each device to determine if the connection is still active
• LAG shuts down ports whose connection is no longer active
– Static LAG – groups are manually‐configured aggregate links containing multiple ports
– Keep‐alive LAG – a single LACP port connection
• Preferred method for detecting uni‐directional links across multi‐vendor devices instead of link keep‐alive (UDLD)
• If the connection is no longer active, the ports are blocked
ICX devices support three types of LAGs.
The first is a Dynamic LAG: – a dynamic LAG uses the Link Aggregation Control
Protocol (LACP) to maintain aggregate links over multiple ports. LACP PDUs are
exchanged between ports on each device to determine if the connection is still
active. The LAG shuts down ports whose connection is no longer active.
The second is a Static LAG. In a static LAG, groups are manually‐configured aggregate
links containing multiple ports.
The third type of LAG is a Keep‐alive LAG: this type of LAG is a single LACP port
connection which is based on a standard rather than on a proprietary solution. It is
the preferred method for detecting unidirectional links across multi‐vendor devices
instead of link keep‐alive (UDLD). If it is determined that the connection is no longer
active, the ports are blocked.
This course focuses on the configuration of static and dynamic LAGs.
Dynamic LAG
• Dynamic link aggregation uses Link Aggregation Control Protocol (LACP), IEEE standard
802.3ad
– Used to control the bundling of several physical ports to form a single logical link
• LACP allows a device to negotiate an automatic bundling of links by sending Link
Aggregation Control Protocol Data Units (LACP PDUs) to a directly connected device
– Both devices must be configured to use LACP
Dynamic LAGs use the IEEE 802.3ad standard for link aggregation. LACP is a mechanism for
allowing ports on both sides of a redundant link to communicate to form a trunk.
When link aggregation is enabled on a group of ports, the Ruckus ports can negotiate with
the remote end ensuring proper configuration of each port member including verifying the
physical ports are properly connected all performed by LACP on both devices.
Ruckus ports follow the same configuration rules for dynamically created aggregate links as
they do for statically configured LAGs.
Static LAGs
• A static LAG does not use LACP and essentially enables the ports to join a port channel
• Static configuration is used when connecting to another switch or device that does not
support LACP
• When using a static configuration, a cabling or configuration mistake by either end of the
LAG could go undetected and thus cause undesirable network behavior
Static LAGs do not use a protocol to establish the connection like LACP, instead they are
manually‐configured aggregate links containing multiple ports and assumes that the ports
on the remote end are properly configured. This can lead to possible problems like wrong
ports connected between the devices etc. since there is no verification process taking
place.
Static configuration is useful when connecting to another switch or device that does not
support LACP. Because a static LAG does not use LACP, it essentially forces the ports to join
a port channel, and the links come up automatically regardless of a configuration mistake.
ICX LAG Specifications
• ICX switches provide a large number of LAGs that can be configured on a switch or a switch
stack with up to 16 port members per LAG
Model Maximum number of LAGs Valid number of ports in a group

Static LACP
ICX 7850
1 to 16
ICX 7750
NOTE
ICX 7450 256 256
The Ruckus ICX device can scale up to a maximum
ICX 7250
of 2048 LAG ports only
ICX 7650
1 to 8
ICX 7150 128 128 Ruckus ICX 7150 can scale up to 1024 and is also
limited to the number of ports on the device
ICX switches provide a large number of LAGs that can be configured on a switch or a
switch stack with up to 16 port members per LAG on all but ICX 7150 switches.
LAG Configuration
Now that we understand the benefits and the need for LAGs, let’s take a look at the LAG
configuration.
LAG Configuration Steps
Create the LAG
• The following configuration procedures are used to configure a LAG
1. Creating a Link Aggregation Group (static, dynamic, keep‐alive)
2. Adding Ports to a LAG
3. Configuring the properties of the LAG on the LAG virtual interface (vLAG)
4. Configuring LACP operation mode as active or passive (dynamic option)
• The LACP operation mode is Active by default
The configuration of a LAGs starts with defining a LAG and identifying if it will be a
dynamic, static or a keep-alive configured LAG.
Next the LAG port members will be identified. Once the first port is associated with the
LAG it is automatically deployed and the LAG virtual interface is automatically created. As a
result you can now navigate to the newly created virtual LAG interface and configure
parameters which are applied to all port members of the LAG.
Other parameters that pertain to the LAG formation can be configure such as its active or
passive mode when using LACP and others.
LAG Configuration Steps
Create the LAG
1. Create a LAG by giving it a name and defining it as static, dynamic or keep‐alive
Ruckus(config)# lag blue1 dynamic id auto
Syntax: [no] lag <name> [static | dynamic | keep-alive] [id <number/auto>]
– The ID parameter is optional, value is 1 to 256
– The LAG ID can be automatically generated and assigned to a LAG using the auto option
– LAG IDs are unique for each LAG in the switch
2. Add ports to the LAG
Ruckus(config-lag-blue1)# ports e 1/1/9 to 1/1/11
LAG blue1 deployed successfully!
– All port parameters must match for ports to be added to the LAG
– Upon the addition of the first physical port to a LAG, a LAG virtual interface is created and is available for
user configuration
The configuration of a LAGs starts with defining a name for the LAG and entering the
keyword dynamic or static, depending on which type of LAG you are configuring
followed by id and the id value. The auto parameter is optional and provides an id
automatically.
This example creates a LAG named “blue1” as dynamic, but it could easily be configured as
static using the static keyword since they are configured in the same manner. The
maximum length for a LAG name is 64 characters. The name can have spaces if you enclose
the name in quotations.
The LAG ID is optional, and valid IDs are 1 to 256. If you do not specify a LAG ID, the system
generates one automatically when the auto option is used. LAG IDs are unique for each
LAG in the local system, if you enter a duplicate ID, you will receive an error, and be told the
next available ID: Error: LAG id 123 is already used. The next
available LAG id is 2.
The second step is to add your ports to the LAG, using the ports ethernet command.

As mentioned previously, all port parameters must match for the ports to be successfully
added to the LAG.
LAG Configuration Steps (cont.)
Configuring the LAG virtual interface
3. Configure a LAG virtual interface which allows you to enter the LAG virtual interface
mode
Ruckus(config)# interface lag 1

Ruckus(config-lag-if-lg1)#
• You can configure the properties of the LAG on the LAG virtual interface
– Changes made to the LAG virtual interface is propagated to all port members in the LAG
• Examples of Layer 2 LAG configurations:1
Ruckus(config-lag-if-lg11)# spanning-tree 802-1w admin-pt2pt-mac
Ruckus(config-lag-if-lg11)# spanning-tree root-protect
Ruckus(config-lag-if-lg11)# speed-duplex
Ruckus(config-lag-if-lg11)# stp-bpdu-guard
Ruckus(config-lag-if-lg11)# stp-protect
The third step is to enter into the LAG virtual interface and configure LAG
parameters.
All configurations are done on the LAG virtual interface are then applied to all
member ports in the LAG. When viewing the running configuration, it will show the
LAG virtual interface similar to physical Ethernet ports in the configuration.
Static LAGs are configured in the same manner as shown including port
membership and layer 2 options.
Footnote 1: For a complete list of configurations that can be used under the LAG
virtual interface, refer to the ICX layer 2 configuration guide.
LAG Virtual Anchor Speed
• When ports are added to a LAG without manually configured speed:
– LAG module chooses first “UP” ports operational speed as anchor speed
• anchor speed can change depending on port bring‐up sequence
– Configuration speed will be compared when port is added to a LAG against LAG’s anchor speed
– LAG ports which comes up with different operational speed as compared to LAG anchor speed will be
error disabled
• LAG ports will be error disabled with reason lag-operSpeed-mismatch
• Error disabled LAG port can be recovered using below methods,
– Configuring auto error disable recovery for lag‐operSpeed‐mismatch reason
• Port flapping can occur corrective action is taken to match operational speed against anchor speed
– Disable and Re‐enabling the LAG interface
– Applying an explicit speed configuration for LAG interface
• It is a good practice to manually set speed of LAG under the vLAG interface if possible
When the LAG moves to operational state it will establish an anchor speed which is chosen
by the first physical ports operation speed. It is important to note that if member ports are
not manually set to the same port speed (not capable speed) the anchor speed can change
based on the first up LAG ports operational speed. The reset of the anchor speed could
potentially cause port of the LAG to become error disabled if a member is not capable of
the anchor speed. Therefore it is a good practice to manually set speed of LAG under the
vLAG interface establishing the expected anchor speed of the LAG.
LAG Speed Configuration
• To ensure LAG speed consistency between disable state and reboots:
– Manually configure the vLAG port with a set speed which is applied to all members
Ruckus(config-lag-if-lg1)# speed-duplex 1000-full
– The configured speed will become the anchor speed for the LAG
– Error message will be created if speed configured is not supported by at least one of the physical
interfaces under LAG
• Port will be err‐disabled if it cannot support the configured speed
Ruckus(config-lag-if-lg10)# show interface ethernet 2/1/3
GigabitEthernet2/1/3 is ERR-DISABLED (lag-operSpeed-mismatch), line protocol is down
Port down for 55 second(s)
Hardware is GigabitEthernet, address is cc4e.246c.d7a9 (bia cc4e.246c.c982)
Configured speed auto, actual unknown, configured duplex fdx, actual unknown
Configured mdi mode AUTO, actual unknown
Here is an example of manually setting the LAG anchor speed under the vLAG interface.
Once configured the LAG speed will be consistent lowering the chance that member ports
will become error disabled due to an anchor speed mismatch.
Adding LAG to VLAN
• VLAN association is applied to Virtual LAG interface
Ruckus(config-vlan-100)# untagged lag 1
Added untagged port(s) lag lg1 to port-vlan 100
• VLAN membership configured on vLAG is applied to all port members
Ruckus# show interface e 1/1/9
GigabitEthernet1/1/9 is up, line protocol is up
<Output Truncated>
Untagged member of L2 VLAN 100, port state is FORWARDING
<Output Truncated>
• VLAN membership configuration is not allowed on physical port members
Ruckus(config-vlan-100)# tagged e 1/1/9
Error - Vlan 100 Operation on Lag 1 Secondary port 1/1/9 is not Allowed.
LAGs VLAN membership is applied to the virtual LAG interface and is dynamically applied to
all physical port members. Member ports will reflect the VLAN membership when
displaying the physical port details. If VLAN membership is applied to port members you
will receive an error.
Disabling and Naming Physical Ports Within a LAG
• You can disable an individual port within a LAG using the disable command within the LAG
configuration
Ruckus(config)# lag blue1 dynamic id 1
Ruckus(config-lag-blue1)# disable ethernet 1/1/9
• Configuration to physical member interfaces is disabled
– Attempts to enter into the physical port changes to LAG configuration context
Ruckus(config)# int e 1/1/9
Ruckus(config-lag-if-lg1)#
• Assigning a name to a physical port within a LAG
– Use the port-name command within the LAG configuration as shown in the following
Ruckus(config-lag-blue1)# port-name "Ruckus lag 1/3" ethernet 1/1/9
It is important to understand that any enabling/disabling of any of the physical
port members of the LAG or the disabling of the LAG virtual port will disable the
entire LAG. Disabling of an individual port member within a LAG is performed
under the LAG configuration using the disable command. Ports disabled in this
manner are still LAG port members however are not forwarding data for the
given LAG. Enabling of the physical port in the LAG can be achieved using the
enable ethernet command as well. Once a physical port is a member of a LAG
configuration on the individual port is very limited. Therefore any configuration
applied to the physical port is accomplished under the LAG including naming of
the physical port.
The name can be up to 255 characters long port name with spaces must be enclosed
within double quotation marks
Renaming or Removing Ports From an Existing LAG
• Renaming an existing LAG
– Changing the name of an existing LAG will not cause any impact on the functionality of the LAG
– Rename the LAG using the update-lag-name command within the LAG configuration mode
– New name provided must be unique and unused
– LAG configuration mode will exit after successful name update
Ruckus(config-lag-blue1)# update-lag-name blue
– LAG “blue1” name is now updated to the name “blue”
• Removing a physical port from an existing LAG
Ruckus(config)# lag blue static id 1
Ruckus(config-lag-blue)# no ports ethernet 1/1/9
– When you remove a port from an operational LAG, the physical port is disabled automatically
Naming and identifying LAG and ports are very important and sometimes name
change is required. ICX devices allow this without having to disable or recreate the
LAG by using the update‐lag‐name command. Enter into the lag under its current
name and issue this command to update the lag name to your preference. Other
LAG maintenance might require you to remove physical ports from an existing LAG
which can be performed while the LAG is still deployed. When using the no port
ethernet command under the LAG stanza allows the port to be removed. To
eliminate the possibility of loops in the environment the removed port is
immediately disabled. Also new ports can be added to a LAG as well keeping in
mind that for it to properly function it has to meet the requirements of the LAG
discussed earlier. These include VLAN membership and speed to name a few.
Displaying LAG Information
• Use the show lag lag_name command to view LAG configuration and

status
Ruckus# show lag blue
<Truncated Output>
=== LAG "blue" ID 1 (dynamic Deployed) ===
LAG Configuration:
Ports: e 1/1/10 e 1/1/11
Port Count: 2
Lag Interface: lg1
Trunk Type: hash-based
LACP Key: 20001
Deployment: HW Trunk ID 1
1/1/10 Up Forward Full 1G 1 No 100 0 609c.9fe6.0e48 Ruckus lag 1/2
1/1/11 Up Forward Full 1G 1 No 100 0 609c.9fe6.0e48 Ruckus lag 2/2
Port [Sys P] [Port P] [ Key ] [Act][Tio][Agg][Syn][Col][Dis][Def][Exp][Ope]
1/1/10 1 1 20001 Yes L Agg Syn Col Dis No No Ope
1/1/11 1 1 20001 Yes L Agg Syn Col Dis No No Ope
Partner Info and PDU Statistics
Port Partner Partner LACP LACP
System ID Key Rx Count Tx Count
1/1/10 65535-0011.32a0.e8a1 9 48045 1309850
1/1/11 65535-0011.32a0.e8a1 9 48043 1309839
The show lag command can be used with or without a specific LAG name. If you do not

reference a specific LAG, the system will display information for each LAG configured.
Some important things to note in the output are:
• Whether the LAG is deployed, and whether it is dynamic or static. For example, the
output here shows the LAG as (dynamic deployed). Next, you can see the ports in
the LAG and their status.
• Note the Link, is it Up or Down? And the Layer 2 state, is it Forwarding or Blocking?
• Also the LACP status of the port
• Under Partner Info and PDU Statistics you want to see the Partner's MAC, and the LACP
receive and transmit counters incrementing.
• You can also use the brief option with the show lag command to provide high
level information on all the LAGs configured on the switch.
The LACP state are as follows:
Sys P ‐ System Priority
Port P ‐ Port Priority
Key ‐ LACP key
Act ‐ Identifies if ports are set to LACP Active (Yes) or Passive (No)
Tio ‐ Timeout set to long (L) (default) or short (S)
Agg ‐ Is the port set to aggregation mode Yes (Agg) No (No)
Syn ‐ Is port in sync with what is being advertised in received LACP frames Yes
(Syn) No (No)
Col ‐ Collecting traffic received on port Yes (Col) No (No)
Dis ‐ Sending traffic on the port Yes (Dis) No (No)
Def ‐ Is port using received LACP PDU parameters (No) or default (admin
defined) (Yes) parameters
Exp ‐ Is port in expired state Yes/No
Ope ‐ LACP port states
Dwn ‐ Down (not active port in the LAG)
Ina ‐ Port is transitioning to Ope state
Ope ‐ Operational
Displaying LAG Virtual Interface
• Use the show interface lag # command to view port status
– Ruckus# show interface lag 1

Lag lg1 is up, line protocol is up
Configured speed Auto, actual 2G, configured duplex fdx, actual fdx
Untagged member of L2 VLAN 100, port state is Forward
BPDU guard is Disabled, ROOT protect is Disabled, Designated protect is Disabled
STP configured to ON, priority is level0, mac-learning is enabled
Mirror disabled, Monitor disabled
Mac-notification is disabled
VLAN-Mapping is disabled
Member of active trunk ports 1/1/10,1/1/11,lg1, Lag Interface is lg1
Member of configured trunk ports 1/1/10,1/1/11,lg1, Lag Interface is lg1
Port name is blue
300 second input rate: 21664 bits/sec, 9 packets/sec, 0.00% utilization
300 second output rate: 7544800 bits/sec, 712 packets/sec, 0.37% utilization
101690811 packets input, 68742066511 bytes, 0 no buffer
Received 29030 broadcasts, 169349 multicasts, 101492432 unicasts
0 input errors, 0 CRC, 0 frame, 0 ignored
0 runts, 0 giants
846052771 packets output, 1094990442930 bytes, 0 underruns
Transmitted 2527876 broadcasts, 6848877 multicasts, 836676018 unicasts
0 output errors, 0 collisions
Relay Agent Information option: Disabled
The show interface lag command shows the LAG virtual interface operational

state similar to a physical interface output. Details such as VLAN membership, STP status,
trunk membership and port statistics. Statistics displayed are a collection of all port
members therefore if errors are displayed the show command can be issued on each
physical port member to see which might be causing errors etc.
Summary
– Configure VLANs and associate tagged and untagged ports
– Describe and configure Virtual Routing Interfaces (VE ports)
– Describe Link Aggregation Groups and the supported types on ICX devices
– Configure LAGs on ICX devices
– Explain how to effectively manage LAGs along with member ports of a LAG
This concludes the module on VLANs and Link Aggregation Groups. You should now be able
to:
Configure VLANs and associate tagged and untagged ports
Describe and configure Virtual Routing Interfaces (VE ports)
Describe Link Aggregation Groups and the supported types on ICX devices
Configure LAGs on ICX devices
Explain how to effectively manage LAGs along with member ports of a LAG
End of Module 8:
This completes the Ruckus Layer 2 Fundamentals module. I encourage you to continue to
ICX 150 Layer 2 Redundancy
Module 9:
Layer 2 Redundancy
Revision 0419

and is based on the FastIron 8.0.90 software release. Subjects discussed in this course
concentrate on the Implementor functions within a network environment however does
not represent all functions or capabilities of an ICX switch. This module focuses on Layer 2
redundancy protocols, specifically Spanning Tree Protocol (STP) and Ruckus’s Multi‐Chassis
Trunking (MCT)..
Objectives
• After completing this module, you will be able to:
– Identify supported Spanning Tree Protocols
– Configure Spanning Tree and Rapid Spanning Tree
– Identify Ruckus enhanced features to Spanning Tree
– Describe Multiple Spanning Tree (MSTP) 802.1s and its purpose
– Describe the benefits of Multi‐Chassis Trunking (MCT)
– Understand and discuss MCT terminology
– Display MCT operational status
Identify supported Spanning Tree Protocols
Configure Spanning Tree and Rapid Spanning Tree
Identify Ruckus enhanced features to Spanning Tree
Describe Multiple Spanning Tree (MSTP) 802.1s and its purpose
Describe the benefits of Multi‐Chassis Trunking (MCT)
Understand and discuss MCT terminology
Display MCT operational status
Spanning Tree Protocols
We’ll start with Spanning Tree Protocol.
Spanning Tree Protocol Overview 153_spanning‐tree.png
• All Spanning Tree standards are incorporated into IEEE 802.1Q‐2014
– Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol (RSTP), Multiple
Spanning Tree Protocol (MSTP)
• IEEE 802.1D, original standard for Spanning Tree (STP)
• Purpose of STP
– Spanning Tree uses an algorithm to ensure a loop‐free topology by enabling
a single path through any physical arrangement of switches. It detects
redundant links, blocks redundant links, and allows for failover to
redundant links. STP creates a loop‐free topology without disconnecting or
disabling interfaces
• Rapid Spanning Tree (RSTP) (802.1w)
– An evolution of 802.1D
– Provides rapid convergence and takes advantage of
Spanning Tree’s point‐to‐point wiring configuration
– Backward compatible with 802.1D
• Multiple Spanning Tree (802.1s)
– Allows multiple VLANs to be managed by a single STP instance
In 2014, the three main types of Spanning Tree, 802.1D (the original specification), 802.1w
(Rapid Spanning Tree), and 802.1s (Multiple Spanning Tree) were all incorporated into the
802.1Q‐2014 specification. The original specifications are still commonly used when
comparing the functionality of one version against another.
Regardless of the version being used, the purpose of Spanning Tree is the same. Spanning
Tree uses an algorithm to ensure a loop‐free topology by enabling a single path through any
physical arrangement of switches. It detects redundant links, blocks redundant links, and
allows for failover to redundant links. STP creates a loop‐free topology without
disconnecting or disabling interfaces.
Rapid Spanning Tree Protocol (RSTP) is seen as an evolution of the original standard. RSTP
uses most of same terminology as 802.1D, and most of the parameters have been left
unchanged so that users familiar with 802.1D can rapidly configure RSTP comfortably.
RSTP is backward compatible to 802.1D in order to interoperate with legacy bridges on a
per‐port basis In a mixed environment, the benefits that RSTP introduces are dropped.
RSTP provides rapid convergence and takes advantage of Spanning Tree's point‐to‐point
wiring configuration. Failure in one forwarding path does not affect other forwarding paths.
RSTP improves the operation of Spanning Tree while maintaining backward compatibility.
Then we have Multiple Spanning Tree (MSTP) it allows multiple VLANs to be managed by a
single STP instance and supports per‐VLAN Spanning Tree. As a result, several VLANs can be
mapped to a reduced number of Spanning Tree instances. This ensures a loop‐free
topology for one or more VLANs that have similar Layer 2 characteristics.
Default STP Settings
• Default Spanning Tree configuration for ICX devices
– Switch code – 802.1D enabled globally
– Router code – STP disabled globally
• Newly configured VLANs in switch code will have 802.1D enabled by default
• 802.1w (RSTP) can be enabled per VLAN, or per interface
• Supported STP enhancements:
– Single Instance Spanning Tree (SSTP)
– Root Guard
– BPDU Guard
– STP Protect
– 802.1D Fast Port Span
– 802.1D Fast Uplink Span
By default, Ruckus ICX devices running Layer 2 code have 802.1D enabled globally, whereas,
devices running Layer 3 code have STP disabled completely. To migrate to RSTP for faster
recovery, you can enable RSTP on a per‐VLAN, or per‐port basis. When you create a port‐
based VLAN, the new VLAN STP state is the same as the default STP state on the
device due to the same default values being applied.
ICX devices support enhancements made to STP including, Single Instance Spanning Tree
(SSTP), Root Guard, BPDU Guard, STP protect, 802.1D Fast Port Span, and 802.1D Fast
Uplink Span . We will be discussing these features throughout this module.
Per‐VLAN Spanning Tree 153_PVST.png
• STP uses Bridge Protocol Data Units (BPDUs) for operation
– Pass from switch to switch, building and maintaining the tree
• Devices run Per‐VLAN Spanning Tree (PVST)
• Each VLAN maintains its own STP instance
– PVST treats each VLAN as a separate network
– On switch code, 802.1D is enabled on all added VLANs
• Each device has a default VLAN (VLAN 1) with 802.1D enabled
• Commands are run per VLAN
– For example:
show 802.1w detail vlan 2
show 802.1w detail vlan 33
Spanning Tree uses Bridge Protocol Data Units (BPDUs), for operation. These are the frames
that pass from switch to switch, building and maintaining the tree for a given VLAN.
By default Ruckus ICX devices run PVST on each VLAN when they are created.
Per‐VLAN Spanning Tree (PVST) is an enhancement to a single instance of STP on a switch
by allowing each VLAN create a different tree within the network. Meaning that PVST
maintains a Spanning Tree instance for each VLAN configured and enables a link to be
forwarding for some VLANs, but blocked others. Because PVST treats each VLAN as a
separate network, it can load balance Layer 2 traffic by forwarding some VLANs on one
trunk, and other VLANs on another trunk without causing a Spanning Tree loop.
Spanning Tree Protocol
802.1D
Let’s take a look at configuring the original 802.1D standard.
Enabling STP (802.1D)
• You can enable or disable STP on the following levels:
– All ports in a port‐based VLAN
• Ruckus(config)# vlan 222
• Ruckus(config-vlan-222)# no spanning-tree
– On an individual port
• Ruckus(config)# interface 1/1/1
• Ruckus(config-if-e1000-1/1/1)# no spanning-tree
As we previously mentioned, 802.1D is configured by default on VLAN 1 (default) on all
switches running Layer 2 software, but is disabled completely on switches running Layer 3
software.
Enabling or disabling 802.1D is performed within the VLAN as shown here and will apply to
all ports that belong to that VLAN. If you want to disable STP on an interface you can do so
within the interface stanza.
Be aware that port settings override VLAN global settings. Thus, you can enable or disable
STP on a specific port however it effects all spanning tree instances for all VLANs it may be
a member of. Therefore caution should be taken when do so to ensure a loop is not
created.
Changing STP Priority
• When non‐default VLANs are created each can have their own bridge priority
– Provides diverse forwarding paths in the layer 2 environment
– Default priority value is 32768
• Change bridge priority per VLAN
Ruckus-04(config)# vlan 222
Ruckus-04(config-vlan-222)# spanning-tree priority 40000
Path cost value
• Ports can also have a priority set to • A 10 Mbps link has a cost of 100
favor it over others • A 100 Mbps link has a cost of 19
– Path cost value specifies the value • A 1 Gbps link has a cost of 4
added to BPDUs received from that • A 10 Gbps link has a cost of 2
port
– Change port priority and cost
Ruckus(config-vlan-10)# spanning-tree ethernet 1/1/1 path-cost 15 priority 64
You can change the STP bridge priority on an ICX device, thus increasing its possibility to becoming the root
bridge for a given VLAN. Because this is performed on a per VLAN basis, it allows different bridge priorities to
be set on each configured VLAN. This provides the ability to create diverse bridge elections thus causing their
layer 2 topology to form different paths. This not only allows better utilization of the redundant links but
provides balance of the traffic over more links.
Using the spanning-tree priority command enter a value from 0 to 65535 within each VLAN. The

default priority is 32768. The bridge with the lowest value has the highest priority, thus setting a bridge to
zero will cause it to have the highest priority.
The last command we see here changes the path‐cost and priority for a specific interface. The path‐cost value
specifies the port cost added to received BPDUs and helps calculate the path to the root bridge. STP prefers
the path with the lowest cost. You can specify a value from 0 ‐ 65535. The default depends on the port type:
• A 10 Mbps link has a cost of 100
• A 100 Mbps link has a cost of 19
• A 1 Gbps link has a cost of 4
• A 10 Gbps link has a cost of 2
The interface priority specifies the preference that STP gives this port relative to other ports for forwarding
traffic out of the Spanning Tree. The value can be set from 0 to 240, the default is 128. The cost of using the
port to reach the root bridge. When selecting among multiple links to the root bridge, STP chooses
the link with the lowest path cost and blocks the other paths. Each port type has its own default STP
path cost however if two ports have the same cost to the root bridge the one that receives a BPDU
with the lower port priority will be chosen.
Because of recent changes to the BPDU it is required that the port priority be set to a value divisible
by 16. If you enter a port priority value that is not divisible by 16, you will received an error Error
– STP Port Priority should be in steps of 16. Default port priority is 128
and can be configured in the range of 0 to 240.
802.1D Show Commands
Ruckus‐03
• Ports 5 and 7 are redundant links between switches with STP 1/1/5 1/1/7 Root

enabled on VLAN 222
VLAN 222
Ruckus-04# show spanning-tree vlan 222

1/1/5 1/1/7
STP instance owned by VLAN 222
Global STP (IEEE 802.1D) Parameters: Ruckus‐04
VLAN Root Root Root Prio Max He- Ho- Fwd Last Chg Bridge
ID ID Cost Port rity Age llo ld dly Chang cnt Address
Hex sec sec sec sec sec
222 8000cc4e24c0deb0 4 1/1/5 9c40 20 2 1 15 14 58 609c9fe60858
Port STP Parameters:
Port Prio Path State Fwd Design Designated Designated
Num rity Cost Trans Cost Root Bridge
Hex
1/1/5 80 4 FORWARDING 3 0 8000cc4e24c0deb0 8000cc4e24c0deb0
1/1/7 80 4 BLOCKING 2 0 8000cc4e24c0deb0 8000cc4e24c0deb0
Syntax: show spanning-tree [blocked] [vlan vlan-id] | [pvst-mode] | detail [vlan vlan-id [ethernet slot/port ]]
[begin expression | exclude expression | include expression ]
Use the show spanning-tree command to view 802.1D details. If you do not specify

a VLAN, the output will show the details for each VLAN on the switch that has spanning
tree enabled.
This example: the show output is from switch Ruckus‐04 and displays the root bridge
(Ruckus‐03) along with the local bridge priority (in HEX) along with its ID. Because we
previously changed Ruckus‐04 bridge priority to 40000 (changed in decimal) from the
default of 32768 it caused it not to become the root bridge. Additionally each port and its
STP state along with the designated root and bridge are displayed as well. Because of the
redundant links between these two bridges, port 1/1/5 is Forwarding, and 1/1/7 is
Blocking.
The Syntax is shown to see the granular output you can receive from this command.
802.1D Show Commands (cont.)
Ruckus-04# show span detail vlan 222 ethernet 1/1/5

Port 1/1/5 is FORWARDING
Port - Path cost: 4, Priority: 128, Root: 0x8000cc4e24c0deb0
Designated - Bridge: 0x8000cc4e24c0deb0, Interface: 0, Path cost: 0
Active Timers - Message age: 0
BPDUs - Sent: 281, Received: 1335
Ruckus-04# show span detail vlan 222 ethernet 1/1/7

Port 1/1/7 is BLOCKING
Port - Path cost: 4, Priority: 128, Root: 0x8000cc4e24c0deb0
Designated - Bridge: 0x8000cc4e24c0deb0, Interface: 2, Path cost: 0
Active Timers - Message age: 0
BPDUs - Sent: 274, Received: 1433
Use the show spanning-tree detail command (abbreviated here to show

span) with a specific VLAN and port number to view even more STP information including,
the port's priority, and number of BPDUs sent and received.
Also shown is the BPDUs sent and received. Because the Ruckus‐03 switch is the root
bridge there are many more BPDUs received than sent. Once the topology is established,
only if a failure, a change in the topology or bridge priority change would cause these
BPDUs to possibly to be sent by this interface.
Fast Port Span (802.1D) 149_fast‐port‐scan.png
• Fast Port Span allows faster convergence on ports that are attached to edge devices
• Enabled by default on ICX devices
– To disable use
Ruckus(config)# no fast port-span
Syntax:(no) fast port-span exclude <ethernet | LAG> < LAG ID | STACKID/SLOT/PORT>
• Because edge devices will not cause loops, state changes can be completed faster
– Reduces the number of STP topology change
notifications on the network1
• Performs the convergence in four seconds
– Two seconds for listening
– Two seconds for learning
• Used in 802.1D only
Fast Port Span for 802.1D allows faster convergence on ports that are attached to end
stations and therefore do not present the potential to cause a Layer 2 loop.
Since the end stations do not generally cause forwarding loops, they can safely go through
the STP state changes (Blocking to Listening to Learning to Forwarding) more quickly than is
allowed by the standard STP convergence time of 30 seconds. This is beneficial for end
stations to migrate quickly and to allow DHCP assignments to not time out.
Fast Port Span performs the convergence on these ports in four seconds (two seconds for
Listening and two seconds for Learning). Whereas, the original standard can take up to 30
seconds for convergence.
With Fast Port Span configured, if the connection to the end node fails, Spanning Tree will
re‐converge in 4 seconds. This can occur because the end nodes do not cause loops
through their single connection.
Footnote 1: When an end station attached to a Fast Span port comes up or down, the
Ruckus device does not generate a topology change notification for the port. In this
situation, the notification is unnecessary since a change in the state of the host does not
affect the network topology.
Fast Port Span (cont.)
• Fast Port Span functionality is disabled if the switch detects any of the following conditions
on a port:
a) It has an 802.1Q tag
b) It is a member of a LAG
c) The switch detects more than one MAC address on the port
d) The switch sees an STP BPDU coming in on the port
Fast Port Span is overridden any time the switch detects any of the following conditions on
a port:
• it has an 802.1Q tag
• it is a member of a LAG
• the switch detects more than one MAC address on the port
• or the switch sees an STP BPDU coming in on the port.
Fast Uplink Span (802.1D)
• Provides features (similar to Fast Port Span) on uplink ports of a switch with redundant
uplinks
– Reduces delay of convergence of redundant link by allowing it to begin forwarding in one second
• The new uplink port directly goes to forward mode (bypassing listening and learning modes)
• Can be configured even if uplink is different vendor switch
• To configure the group of uplink ports are identified on the ICX switch
– All Fast Uplink Span‐enabled ports are members of a single Fast Uplink Span group
– It is recommended to be used only on edge switches to avoid temporary bridge loops
Ruckus(config)# fast uplink-span ethernet 1/1/1 to 1/1/4
– Within a VLAN
Ruckus(config-vlan-10)# untag ethernet 1/1/5 to 1/1/8
Ruckus(config-vlan-10)# fast uplink-span ethernet 1/1/5 to 1/1/8
The Fast Uplink Span feature enhances STP performance for wiring closet switches
with redundant uplinks. Using the default value for the standard STP forward delay,
convergence following a transition from an active link to a redundant link can take
30 seconds (15 seconds for listening and an additional 15 seconds for learning).
You can use the Fast Uplink Span feature to decrease the convergence time for the
uplink ports to another device to just one second. The new Uplink port directly goes
to forward mode (bypassing listening and learning modes). the device at the other
end of the link can be a Ruckus ICX device or another vendor’s switch.
To configure the Fast Uplink Span feature, specify a group of ports that have
redundant uplinks on the ICX switch. If the active link becomes unavailable, the Fast
Uplink Span feature transitions the forwarding to one of the other redundant uplink
ports in just one second. All Fast Uplink Span‐enabled ports are members of a single
Fast Uplink Span group
Active uplink port failure
The active uplink port is the port elected as the root port using the standard STP
rules. All other ports in the group are redundant uplink ports. If an active uplink
port becomes unavailable, Fast Uplink Span transitions the forwarding of traffic to
one of the redundant ports in the Fast Uplink Span group in one second bypassing
listening and learning port states.
Switchover to the active uplink port
When a failed active uplink port becomes available again, switchover from the redundant
port to the active uplink port is delayed by 30 seconds. The delay allows the remote port to
transition to forwarding mode using the standard STP rules. After 30 seconds, the blocked
active uplink port begins forwarding in just one second and the redundant port is blocked
Rapid Spanning Tree Protocol (RSTP)
802.1w
Now let’s take a closer look at Rapid Spanning Tree.
RSTP Configuration 162_rstp‐config.png
• Enable RSTP:
Ruckus(config-vlan-2)# spanning-tree 802-1w
• Define priorities:
Ruckus(config-vlan-2)# spanning-tree 802-1w priority 4096
Ruckus(config-vlan-2)# spanning-tree 802-1w e 1/1/1 priority 16
• Define port parameters/function:
Ruckus(config-vlan-2)# span 802-1w e 1/1/4 admin-edge-port
Ruckus(config-vlan-2)# span 802-1w e 1/1/1 admin-pt2pt-mac
Ruckus(config-vlan-2)# span 802-1w e 1/1/2 admin-pt2pt-mac
Because RSTP is disabled by default, you must enabled it on a per‐VLAN or per‐port basis.
The example shown here enables RSTP on VLAN 2.
To force a switch to be the root bridge, set the bridge priority to a low value/high priority
value. The default bridge priority for RSTP is 8000 Hex (32768) as well. The example sets
the RSTP instance to 4096 and the port e 1/1/1 priority to 16, vastly improving the
possibility of this switch becoming the root bridge for this VLAN..
Edge ports are ports of a bridge that connect to end workstations or computers. Edge ports
assume the Designated port role and do not anticipate any incoming BPDU activity. Setting
a port as an edge port in RSTP eliminating an port flapping to cause any topology change
events to take place since RSTP does not consider edge ports in the Spanning Tree
calculation. Use the admin-edge-port command to configure a port as an edge port.
To take advantage of the fast convergence time of RSTP, ports between switches should be
explicitly configured as point‐to‐point links using the admin-pt2pt-mac command. The
point‐to‐point link configuration increases the speed of re‐convergence by allowing
the local switch to know this is a single connection to another switch. This
parameter, however, does not auto‐detect whether or not the link is a physical
point‐to‐point link
Ports in the Discarding state are equivalent to the 802.1D Blocking state. The bridge on the
right shown here is receiving BPDUs on ports 1/1/3 and 1/1/5 that have equivalent fields
for: root bridge ID, path‐cost, and sender's bridge ID. They differ however, on the port ID.
Since the port priority for port 1/1/1 on the root bridge has been set to 16 (default 128),
the connected port (1/1/3) on the other switch goes into the Forwarding state, while port
1/1/5 goes into the Discarding state.
802.1w Show Commands
Ruckus(config)# show 802-1w
IEEE 802-1w is not configured on port-vlan 1
--- VLAN 2 [ STP Instance owned by VLAN 2 ] ----------------------------
Bridge IEEE 802.1W Parameters:
Bridge Bridge Bridge Bridge Force tx
Identifier MaxAge Hello FwdDly Version Hold
hex sec sec sec cnt
1000609c9fe60e40 20 2 15 Default 3
RootBridge RootPath DesignatedBri- Root Max Fwd Hel
Identifier Cost dge Identifier Port Age Dly lo
hex hex sec sec sec
1000609c9fe60e40 0 1000609c9fe60e40 Root 20 15 2
Port IEEE 802.1W Parameters:
<--- Config Params --><-------------- Current state ----------------->
Port Pri PortPath P2P Edge Role State Designa- Designated
Num Cost Mac Port ted cost bridge
1/1/1 16 20000 T F DESIGNATED FORWARDING 0 1000609c9fe60e40
1/1/2 128 20000 T F DESIGNATED FORWARDING 0 1000609c9fe60e40
1/1/4 128 20000 F T DESIGNATED FORWARDING 0 1000609c9fe60e40
The show 802-1w command (or show 8 for short) displays all RSTP information per

VLAN. Important things to note in this output, are the Bridge Identifier, which is the MAC
address of this bridge, and the Root Bridge Identifier which is the MAC address of the root
bridge. Also the bridge priority has been lowered from the default value to the value of
4096 as shown in the previous slide. The first 4 numeric values in the bride identifier
provide the bridge priority displayed in hex.
In this example, the MACs are the same, which means that this is the root bridge.
Also shown is the state of each port. In this case, all ports are Designated and Forwarding.
Also notice the P2P MAC, and the Edge Port values are either “T” for true, or “F” for false,
meaning the admin-pt2pt-mac parameter, or the admin-edge-port parameter is
configured for the port.
Each port has a priority and designated cost associated with it. The priority of port 1/1/1 is
16 causing it to be preferred over other ports to other switches while the other ports have
the default priority of 128.
BPDU Guard (STP, RSTP and MSTP)
• BPDU enforces the STP domain borders helping keep the topology predictable
– Removes a node that reflects BPDUs back in the network eliminating the ability to participate in STP
– Do not allow rouge switches to be attached and start participating in STP
– It is a best practice to enable BPDU Guard on these edge ports
• BPDU Guard disables an interface that expectedly receives BPDUs
Ruckus(config)# interface 1/1/1

Ruckus(config-if-e1000-1/1/1)# stp-bpdu-guard
• BPDU Guard disables the port by putting it into an Errdisable state
– Log messages and a console messages are displayed
As we previously mentioned, in an STP environment, switches, end stations, and other
Layer 2 devices use BPDUs to exchange information that STP uses to determine the best
path for data flow.
BPDU Guard, is an enhancement, which removes a node that reflects BPDUs back into the
network. It enforces the STP domain borders and keeps the active topology predictable by
not allowing any network devices behind a BPDU Guard‐enabled port to participate in STP.
In most instances, it is not necessary for a connected device, such as an end station, to
initiate or participate in Spanning Tree topology changes. Therefore, you can enable BPDU
Guard on the port to which the end station is connected. If a BPDU is detected on the port,
BPDU Guard will shut it down and put it into an Errdisable state.
A log message is generated for each BPDU Guard violation, and a console message is
displayed to warn the network administrator of the violation.
BPDU guard is supported on tagged ports as long as it is tagged on both sides to the
same VLAN
How BPDU Guard Works
162_BPDU‐guard.png
• The port goes to Errdisable state, ensuring network stability
– If no recovery interval is set the port will have to be manually “bounced” to recover:
Ruckus(config)# interface 1/1/1
Ruckus(config-if-e1000-1/1/1)# disable
Ruckus(config-if-e1000-1/1/1)# enable
– A recovery interval can be configured to allow for auto recovery of port
• Global Configuration
Ruckus(config)# errdisable recovery cause bpduguard
Ruckus(config)# errdisable recovery interval 20 (seconds)
Root Bridge
3
Port State
1/1/1 Errdisable
Edge port with BPDU Guard enabled 1/1/1
1 2
Rogue BPDUs
In our example, BPDU Guard is enabled on the edge port to prevent BPDUs coming from a rogue
switch that has been attached. When BPDUs are received on a BPDU Guard‐enabled port, the port
goes to Errdisable state. The port can be brought out of the Errdisable state by either manually
disabling and re‐enabling the port, or by configuring the errdisable recovery cause
bpduguard command, along with a errdisable recovery interval.
In this example we set the interval to 20 seconds. Now, after 20 seconds, the port will be put back
in action.
Displaying the BPDU guard status of ports can performed using:
device# show stp‐bpdu‐guard
BPDU Guard Enabled on:
Interface Violation
Port 1/1/1 No
Port 1/1/2 No
Port 1/1/3 No
Port 1/1/4 No
Port 1/1/5 No
Port 1/1/6 No
Port 1/1/7 No
Port 1/1/8 No
Port 1/1/9 No
Port 1/1/10 No
Port 1/1/11 No
Port 1/1/12 Yes
Port 1/1/13 No
Spanning Tree Root Guard (STP, RSTP and MSTP)
• Ensures that the L2 topology does not change with the introduction of a STP device on an
edge port
• Superior BPDUs received from a Root Guard enabled port
– Port transitions to a ROOT-INCONSISTENT state
– Port is set to blocking/discarding
– Triggers Syslog message and SNMP trap
– No further traffic will be forwarded on the port
• Once the port stops receiving superior BPDUs, Root Guard reverts the port back to a
forwarding state using the STP algorithm
• Root Guard should be configured on all ports where the root bridge should not appear
Spanning Tree Root Guard can be used to predetermine the location of the root bridge and
prevent rogue or unwanted switches from becoming the root bridge.
When Root Guard is enabled on a port, it keeps the port in a Designated role. If the port
receives a superior BPDU, it puts the port into a ROOT‐INCONSISTANT state and triggers a
log message and an SNMP trap. The ROOT‐INCONSISTANT state is equivalent to the
BLOCKING state in 802.1D and to the DISCARDING state in 802.1w. No further traffic is
forwarded on this port.
Once the port stops receiving superior BPDUs, Root Guard automatically sets the port back
to Learning, and eventually to a Forwarding state.
STP Root Guard – Configuration and How it Works
• Configuring root guard

Ruckus(config-if-e10000-1/1/5)# spanning-tree root-protect
• When the port is put into ROOT‐INCONSISTANT state, data traffic is not forwarded
Root Bridge
3
Port State
1/1/1 Root Inconsistent
Edge port with BPDU Guard enabled 1/1/1
1 2
BPDUs with superior Bridge ID
Here we see how Root Guard works.
First, Root Guard is enabled on an edge port. ‘
Next the new switch is connected to the edge and begins sending BPDUs into the network,
Then Root Guard detects the BPDUs and sets port 1/1/1 to ROOT‐INCONSISTANT. This halts
traffic and prevents the BPDUs from entering the network and, potentially, forcing an
election.
Multiple Spanning Tree (MSTP)
802.1s
Our next topic is 802.1s, or Multiple Spanning Tree ‐ MSTP.
Multiple Spanning Tree Protocol Purpose
• 802.1s defines an extension to the RSTP protocol
• Provides scaling of spanning tree
– Improves STP management by grouping multiple VLANs with similar layer 2 topologies together
• Conserves switch resources allowing a reduced number of spanning‐tree instances known as Internal Spanning
Tree (IST)
– Isolates failures by limiting the STP topology change notifications within an STP group instance/region
– Fast convergence by utilizing RSTP features allowing for rapid
• Multiple spanning‐tree regions
– ICX switches support up to 16 spanning tree instances in an MSTP enabled bridge
• 16 different Layer 2 topologies supported
• VLAN 4092 is reserved for instance 0, the Internal Spanning Tree (IST)
Multiple Spanning Tree Protocol (MSTP), is defined in IEEE standard 802.1s. Because of the
overhead required for Spanning tree to function in a switch when large amount of STP
instances is deployed it can put a strain on devices especially when many instances are
deployed. Multiple Spanning Tree provides the ability to associate multiple VLANs with the
same topology together into one instance of STP. Not only does the reduce the resource
requirement in a switch but provides an effective way to deploy STP in a large scale such as
with ISP or large layer 2 networks. Other advantages of MSTP include isolating link failures
change notifications within a “region” cutting down on the advertisement of topology
change notification within the STP instance instead of the whole STP environment.
The Ruckus implementation supports up to 16 Spanning Tree instances in an MSTP enabled
bridge which means that it can support up to 16 different Layer 2 topologies.
The Spanning Tree algorithm used by MSTP is RSTP which provides quick convergence.
VLAN 4092 is reserved for instance 0, which is the Internal Spanning Tree (IST) instance. We
will discuss the IST on the next slide.
802.1s Key Concepts
• Common Spanning (CST)
– Assumes one Spanning Tree instance for the entire bridged network regardless of the number of VLANs
– In MSTP, a region appears as a virtual bridge that runs CST
• Internal Spanning Tree (IST)
– An MSTP bridge must handle at least these two instances:
• One IST (instance 0)
• One or more MSTIs (Multiple Spanning Tree Instances)
– Instance 0 extends CST inside the MST region
– IST always exists if the switch runs MSTP
– Within each MST region, MSTP maintains multiple Spanning Tree instances
• All switches in that region must run RSTP
Here are some of the key concepts of MSTP.
First is Common Spanning Tree (or CST). CST is defined as one Spanning Tree instance for
the entire bridged network regardless of the number of VLANs. In MSTP, a region appears
as a virtual bridge that runs in the CST.
Next, we have the Internal Spanning Tree (or IST) which extends the CST into the region.
An MSTP bridge must handle at least these two instances: one IST and one or more
Multiple Spanning Tree Instances (MSTIs). Ruckus's MSTP implementation allows for up to
16 instances within each region.
The IST is always instance 0, which leaves 15 MSTIs which can be numbered from 1 to
4094.
An older switch that only supports 802.1D may be added as a part of the CST but not
inside a region; RSTP must be run within a region.
802.1s Key Concepts (cont.)
• Multiple Spanning Tree Instance (MSTI)
– The MSTI is identified by an MSTid value between 1 and 4094
• Common and Internal Spanning Trees (CIST)
– CIST is a collection of the ISTs in each MSTP region, and the CST that interconnects the MSTP regions and
single spanning trees
• MSTP Regions
– Clusters of bridges that run multiple instances of the MSTP protocol
– Multiple bridges detect that they are in the same region by exchanging their configuration information
– One or more VLANs can be mapped to one MSTP instance, but a VLAN cannot be mapped to multiple
MSTP instances
Each instance of Multiple Spanning Tree is identified by an MST identifier (MSTid). Valid
MSTids are between 1 and 4094.
Then we have the Common and Internal Spanning Tree (or CIST) which is the collection of
the ISTs in each region and the CST that interconnects the regions and single Spanning
Trees.
MSTP regions are clusters of bridges that run multiple instances of the MSTP protocol.
Multiple bridges detect that they are in the same region by exchanging their configurations,
which includes, their instance to VLAN mapping, name, and revision‐level. Therefore, if you
need to have two bridges in the same region, make sure these configurations match.
It is important to note that one or more VLANs can be mapped to one MSTP instance (IST
or MSTI), but a VLAN cannot be mapped to multiple MSTP instances.
Multiple Spanning Tree Regions
Using MSTP, the entire network runs a common instance of RSTP. Within that common
instance, one or more VLANs can be individually configured into distinct regions. The entire
network runs the common spanning tree instance (CST) and the regions run a local instance.
The local instance is known as Internal Spanning Tree (IST). The CST treats each instance of IST
as a single bridge. Consequently, ports are blocked to prevent loops that might occur within an
IST and also throughout the CST. With the exception of the provision for multiple instances,
MSTP operates exactly like RSTP.
For example, the network shown here is configured with two regions: Region1 and Region2.
The entire network is running an instance of CST. Each of the regions is running an instance of
IST. In addition, this network contains Switch1 at the very top running MSTP that isn't
configured in a region and is running in the CIST. In this configuration, the regions are each
regarded as a single bridge to the rest of the network, as is Switch1. The CST prevents loops
from occurring across the network. As a result, port e2 is blocked on switch6. Additionally,
loops must be prevented in each of the IST instances. Within IST Region1, port e2 on switch4 is
blocked to prevent a loop in that region. Within IST Region2, port e2 on switch3 is blocked to
prevent a loop in that region. Once the system is configured for MSTP, CIST (sometimes
referred to as instance 0) is created and all existing VLANs inside the MSTP scope are
controlled by CIST. In addition, whenever a new VLAN is created inside the MSTP scope, it is
put under CIST control by default. In the Ruckus MSTP implementation however, a VLAN ID can
be pre‐mapped to another MSTI. A VLAN whose ID is pre‐mapped will attach to the specified
MSTI instead of to the CIST when created. Once MSTP is configured, CIST always controls all
ports in the system. (Configure the no spanning‐tree command under the specified interface
configuration to keep a specific port from running MSTP.)
An MSTP instance is configured with an MSTPid for each region. Each region can contain one or
more VLANs.
802.1s Show Commands
• To display information about a specific MSTP instance:
SW2# show mstp 1

MSTP Instance 1 - VLANs: 2
----------------------------------------------------------------------------
Bridge Max RegionalRoot IntPath Designated Root Root
Identifier Hop Bridge Cost Bridge Port Hop
hex cnt hex hex cnt
8001000cdb80af01 20 8001000cdb80af01 0 8001000cdb80af01 Root 20

Port Pri PortPath Role State Designa- Designated
Num Cost ted cost bridge
1/3/1 128 2000 MASTER FORWARDING 0 8001000cdb80af01
Use the show mstp command, followed by an instance number to display information

about a specific MSTP instance. The output displays the ports in the instance, the ID of the
bridge where the show command is run, and the ID of the root bridge along with their
perspective priorities. Also shown are the ports in the instance along with their role, state,
costs and priority.
802.1s Show Commands (cont.)
• To display information about the CIST instance:
SW1# show mstp 0

MSTP Instance 0 (CIST) - VLANs: 1
-------------------------------------------------------------------
Bridge Bridge Bridge Bridge Bridge Root Root Root Root
Identifier MaxAge Hello FwdDly Hop MaxAge Hello FwdDly Hop
hex sec sec sec cnt sec sec sec cnt
8000000cdb80af01 20 2 15 20 20 2 15 19
Root ExtPath RegionalRoot IntPath Designated Root

Bridge Cost Bridge Cost Bridge Port
hex hex hex
8000000480bb9876 2000 8000000cdb80af01 0 8000000480bb9876 3/1/1
Port Pri PortPath P2P Edge Role State Designa- Designated

Num Cost Mac Port ted cost bridge
3/1/1 128 2000 T F ROOT FORWARDING 0 8000000480bb9876
To display information for the entire CIST bridge network, use the show mtsp 0
command, as the CIST is instance 0 within the CST. As you can see the output of this
command differs from the output of the show mstp command for an individual MSTI.
This output includes the MSTP information for communication between all the MSTP
regions.
Multi‐Chassis Trunking (MCT)
Our next Layer 2 redundancy protocol is Ruckus’s Multi‐Chassis Trunking, or MCT.
Multi‐Chassis Trunking 162_MCT.png
• Currently supported on ICX 7750 and 7850
• Expands the features of LAGs by:
– Eliminates single point of failure
• Providing switch level redundancy in addition to the link level
redundancy provided by LAGs
– Providing an active‐active connection for increased capacity
and forwarding
– Making the topology loop‐free without Spanning Tree
• Other features:
– Integrated loop detection, which allows all links to be active
– Easy deployment without fundamentally changing the existing
architecture
– Sub second failure detection and allocation of traffic
MCT is an enhancement to Link Aggregation Control Protocol (LACP), IEEE standard 802.3ad
and (802.1ax revision). MCT is supported on the ICX 7750 and 7850. Other ICX however can
be used to connect to the MCT cluster to provide device level redundancy for its clients.
A regular trunk or LAG is a switch‐to‐switch link that provides redundancy.
A Multi‐Chassis Trunk is a trunk that initiates at a single MCT‐unaware switch and
terminates at two MCT‐aware switches that form one MCT logical switch. From this picture
here, we can see that each of the MCT‐unaware switches on the left have a trunk going to
each of the MCT switches in the cluster. From the MCT logical switches point of view, these
trunks are a single trunk.
MCT is an Active‐Active network architecture. It provides high availability, high reliability
and provides efficient utilization of bandwidth. Compared with a regular trunk which
provides link‐level redundancy: If the trunk is one‐to‐one and the switch goes down, then
the whole connection is lost. In addition to port‐level redundancy, MCT provides switch‐
level redundancy by extending the trunk across two switches providing high availability.
Multi‐Chassis Trunking (cont.) 162_MCT2.png
• MCT is compatible with standard LAG operations
– Any device that supports IEEE 802.3ad can be used at the edge
• Edge devices:
– Are transparent to the MCT protocol
– Can be 3rd party vendor devices with
LAG support
Edge devices are transparent to the MCT peers and protocol. An edge device can be any
Ruckus, or 3rd party device that supports static LAG configuration, or the LACP 802.3ad
standard.
MCT Terminology
• Inter‐Chassis Link (ICL) ‐ a single‐port or multi‐port, 1 GbE, 10 GbE, or 40 GbE static LAG
between two MCT cluster devices to communicate data flow and control messages
between them
• Cluster Communication Protocol (CCP) ‐ protocol used between MCT aware devices
• MAC Database Update Protocol
(MDUP) ‐ control plane protocol
used to sync MAC entries between
MCT cluster peers
• Customer Client Edge Port
(CCEP) ‐ ports on a cluster switch
connecting it with cluster client
• Customer Edge Port
(CEP) ‐ a regular non‐MCT port on
an MCT cluster switch
Lets take a look at some of the terminology of MCT.
The ICL is the Inter‐Chassis Link between MCT logical peers. On ICX devices this must be a static
LAG. It provides data flow and control messages between them. On the ICLs, two control routing
protocols are being managed. One is a CCP which is Cluster Communication Protocol based on TCP.
The other is the MAC Database Update Protocol (MDUP).
Cluster Communication Protocol (CCP) provides reliable, point‐to‐point transport of cluster
communication and sync between MCT peers. CCP works on TCP port 4175. Applications such as
MAC Database Update between cluster peers can use CCP to synchronize their MAC tables.
Applications (MAC Manager, STP, etc.) can register with CCP dynamically. Since CCP protocol is
based on TCP, an IP address is needed for CCP to function. Peer nodes exchange session parameters
(ClusterID, RBridgeID, Keep Alive time, Hold time, Fast failover). Once a keep alive message is
exchanged, CCP will migrate into an UP state.
MDUP is used to sync MAC addresses between the peers. ICL ports should not be untagged
members of any VLAN. The ICL is a tagged Layer 2 link, which carries packets for multiple VLANs. An
ICL is preferably a LAG that provides port level redundancy and higher bandwidth for cluster
communication.
Customer Client Edge Port (CCEP) are physical ports on one of the MCT cluster switches that is a
member of the LAG interface to the MCT client. Ultimately another physical port of the LAG will
also be connected to other switch in the MCT cluster.
Although the physical port is connected to one of the MCT cluster switches a CEP port, or Customer
Edge Port is not benefitting from the MCT features. Therefore a CEP port is a non‐MCT port that is
not connected to a MCT client. However it still provides connectivity to the network.
MCT Terminology (cont.)
• RBridge ‐ any device involved in the MCT cluster including peer or client
• RBridgeID ‐ unique ID assigned to each MCT peer and client
• MCT Peers:
– Pair of physical switches which act
as one logical switch
– Edge switches or servers are connected
via a LAG
– LAGs are spread across the MCT pair
• MCT Keep‐alive VLAN ‐ A VLAN
configured to provide alternate
communication between MCT peers during ICL/CCP failure
An RBridge is any device involved in the MCT cluster, including peer or client. Each RBridge
in the cluster has a unique ID.
The RBridgeID is a value assigned to MCT cluster devices and clients that uniquely identifies
them and helps associate the source MAC address with an MCT device.
Cluster RBridgeIDs cannot conflict with any client RBridgeID. Client RBridgeIDs should
match between cluster peers on the same common client.
MCT Peers are the pair of physical switches which act as one logical switch. Edge switches
or servers are connected via a LAG. LAGs are spread across the MCT pair. The MCT Keep‐
alive VLAN is a VLAN configured to provide alternate communication between MCT peers
during ICL/CCP failure.
It is recommended that you set up ICL as a static LAG with at least two ports. This
provides port‐level redundancy and higher bandwidth for cluster communication.
An ICL cannot be a regular port link or an LACP trunk. It must be a single or multiple
port static LAG.
Cluster Communication Protocol
• Cluster Communication Protocol (CCP) – proprietary protocol providing reliable, point‐to‐
point transport between peers using TCP port 4175
– An IPv4 address is needed for CCP to function1
– Different applications use this connection for communication by registering with CCP dynamically
• CCP comprises two main components:
– CCP peer management:
• Initialization, establishment, maintenance, and termination of TCP transport session between MCT peers
– CCP client management:
• Client port association, identification, and establishment
• MAC learning (MAC Database Update Protocol (MDUP))
Cluster Communication Protocol (CCP) is the Ruckus proprietary protocol that provides
reliable, point‐to‐point transport to synchronize information between MCT cluster devices.
It provides the default MCT control path between the two peer devices.
CCP comprises two main components: CCP peer management and CCP client management.
CCP peer management deals with establishing and maintaining a TCP transport session
between peers, while CCP client management provides event‐based, reliable packet
transport to CCP peers.
Footnote1: IPv6 addressing is not supported in MCT
MCT MAC Learning
• Client LAGs terminating on a MCT cluster cause MACs to be associated with multiple ports
• MAC Database Update Protocol (MDUP) applies a cost and categorizes learned MACs
based on the port type and location they are received
– CL: Cluster Local MACs
– CCL: Cluster Client Local MACs
– CR: Cluster Remote MACs
– CCR: Cluster Client Remote MACs
• MAC Database (MDB) ‐ can have multiple MAC entries for the same address
• Forwarding MAC Database (FDM) ‐ will only have the best MAC installed
As we have seen, LAGs are connected to multiple peers in a MCT cluster, this can cause the
learning of MACs to be bound to multiple ports, either a local port or the ICL. To address
this, the MACs are categorized based on what type of port they where learned on, a local
or remote port. Each MAC type serves a purpose and allows for preferred MACs to be
placed in the Forwarding MAC Database. For legacy MAC learning, we only maintain a
Forwarding Database (FDB). But for a MCT switch, we maintain a FDB and an MAC
Database (MDB). The best entries of the MDB get inserted into FDB.
Cluster Local MACs, designated by CL, are MACs that are learned on the MCT VLAN and on
CEPs locally. These MACs are synchronized to the cluster peer and are subject to aging.
Cluster Remote MACs, designated by CR, are learned via MDUP messages from the peer
(these are considered Cluster Local MACs on the peer). These MACs are always
programmed on the ICL and do not age. They are deleted only when it is deleted from the
peer. A MDB entry is created for these MACs with a cost of 1, and associated with the peer
RBridgeID.
Cluster Client Local MACs, designated by CCL, are locally learned on CCEP ports in MCT
VLANs.
Cluster Client Remote MACs, designated by CCR, are MACs that are learned via MDUP
message from the peer (these are considered Cluster Client Local on the peer). These MACs
are always programmed on the corresponding CCEP port and do not age. They are deleted
only when it is deleted from the peer. A MDB entry is created for these MACs with the cost
of 1, and are associated with the client and peer RBridgeIDs.
MCT MAC Learning (cont.)
• MAC addresses learned (local or MDUP) are added
to the MAC Database (MDB)
– MAC addresses learned on the local cluster node are
added to the local MDB with a cost of 0
– MAC addresses learned from the peer cluster node are
added to the remote MDB with a cost of 1
• When multiple MACs exist in the MDB, the MAC
with the lowest cost is selected and added to the
forwarding database (FDB)
MACs learned locally or by MDUP are added to the MAC Database (or MDB). MAC
addresses learned on the local cluster node are added to the local MDB with a cost of 0,
and those learned from the peer cluster node are added to the remote MDB with a cost of
1.
The MACs that are learned locally are given the highest priority or the cost of 0 so they are
always selected as best MAC. Each MAC is advertised with a cost. Low cost MACs are given
preference over high cost MACs. If a MAC moves from a CCEP port to a CEP port, a MAC
move message is sent to the peer and the peer moves the MAC from its CCEP ports to the
ICL links.
Cluster local MACs are always given preference over cluster remote MACs.
Display Local MAC Addresses
• Use the show mac‐address cluster command with the cluster ID to display all local MAC addresses
for the cluster
– CL: Cluster Local MACs
– CCL: Cluster Client Local MACs
– CR: Cluster Remote MACs
– CCR: Cluster Client Remote MACs
– CML: Static MAC configured locally on the MCT VLAN
– CMR: Static MAC configured on the MCT VLAN on the peer side and has no associated local configuration
Ruckus# show mac-address cluster 1000

Total Cluster Enabled(CL+CR+CCL+CCR) MACs: 1
Total Cluster Local(CL) MACs: 1
CCL: Cluster Client Local CCR:Cluster Client Remote CL:Local CR:Remote
Total active entries from all ports = 1
Total static entries from all ports = 3
MAC-Address Port Type MCT-Type VLAN
0000.0022.3333 1/8/1 Static CML 20
0000.0022.3333 1/8/3 Static CML 20
0000.0022.3333 1/8/13 Static CML 20
Use the show mac-address cluster command with the cluster ID to display all

local MAC addresses for the cluster. We've already looked at the different types of MAC
addresses, but here we see two more. CML, which are static MACs configured locally on
the MCT VLAN, and CMRs which are static MACs configured on the MCT VLAN on the peer
side and has no associated local configuration.
MCT VLANs
• Session VLAN: Provides control channel for CCP
– Ruckus recommends keeping only ICL ports in the Session VLAN
– Layer 2 software, disable STP/RSTP on the Session VLAN
– Layer 3 software, configure a virtual interface on the Session VLAN
• Used to address the link between the MCT peers
• MCT VLAN: VLANs identified and serviced by MCT to forward customer data through the
MCT cluster
– The ICL must belong to every single MCT VLAN to provide data path between two cluster switches
– For MCT VLANs, MAC learning is disabled on ICL ports
MCT has two VLANs which are needed to function. The first is the MCT Session VLAN. This
is the VLAN used by the cluster for control operations. CCP protocol runs over this VLAN.
The interface can be a single link or LAG port. ICL ports are tagged in the session VLAN. It is
recommended to use a high VLAN number that would not be touched by data VLANs. Note:
MCT session VLAN's subnet will not be distributed in routing protocols using redistribute
commands.
The second are MCT VLANs. These are the VLANs on which MCT clients are operating.
These VLANs are explicitly configured in the MCT configuration by the user. The ICL must
belong to each MCT VLAN. For MCT VLANs, MAC learning is disabled on ICL ports, while
MAC learning is enabled on the ICL port for non‐MCT VLANs. Any VLAN that has an ICL port
is an MCT VLAN, even though if it does not have any clients.
Typical MCT Scenarios
• MCT • Cascading MCT
– Two peers (AGG‐MCT1 & AGG‐MCT2) form one – Two MCT clusters: AGG‐MCT1 & AGG‐MCT2 and
MCT cluster with switches Edge‐1 – Edge‐4 Core‐MCT1 & Core‐MCT2
acting as active clients – Four links between the 2 MCT clusters form one
trunk (LAG)
Core‐1 Core‐2 Core‐MCT1 ICL Core‐MCT2
AGG‐MCT1 ICL AGG‐MCT2 AGG‐MCT1 ICL AGG‐MCT2
Edge‐1 Edge‐2 Edge‐3 Edge‐4 Edge‐1 Edge‐2 Edge‐3 Edge‐4
Single MCT Cascading MCT
For MCT, there are two typical usage topologies. The first one is a single MCT. In this
topology we have one cluster, AGG‐MCT1 and AGG‐MCT2. These two peers form one
cluster and switches Edge‐1 through Edge‐4 act as clients connected to the cluster. Usually
on this topology, the cluster switches are running Layer 2 code only, so it will act as switch
and Layer 3 will be running on Core‐1 and Core‐2.
Also supported is a cascading MCT topology. In this scenario, there are two clusters, AGG‐
MCT1 and AGG‐MCT2 form one cluster and Core‐MCT1 and Core‐MCT2 form another
cluster. So, the four links between them form one trunk. In both instances a VRRP‐type of
technology will be used to provide redundancy.
MCT Operation
Active‐Active Topology, all nodes and all links forwarding traffic
Traffic is forwarded
2 On SW1 local
MCT LAG
MCT Pair Traffic is forwarded based on
1
the hashing algorithm of the
edge switch
Server B SW1
MAC B
Client A
SW2 MAC A
4 Traffic load balanced Learned MAC A
by the hashing 3 On SW1 is
algorithm on communicated to SW2 across Traffic is forwarded on
5
the server NIC ICL SW2 local MCT LAG
Ethernet Traffic
Ethernet Link
Let's take a look at MCT in action. In the example shown here, Client A is initiating a
conversation with Server B. The Client A edge switch will employ a hashing algorithm to
determine which egress port to use for forwarding the frame.
Once received at an MCT peer (SW1 in the example) the frame is forwarded out of the
egress port connected to the Server B switch. Simultaneously, SW1 will share the
information for Client A's MAC address with SW2 over the ICL.
The response from Server B to Client A is handled in the same way. The Server B switch will
deploy a hashing algorithm to determine the egress port for forwarding (in this case the
link to SW2). SW2 will forward out the local link towards Client A while simultaneously
providing Server B's MAC information to SW1 over the ICL.
MCT Operation (cont.)
Fast failover regardless of the failure type (link/module/node) due to detection at the physical level
Link failure detected
MCT Pair 1
at the access switch
Server B SW1
MAC B
Client A
SW2 MAC A
2 Access switch hashing algorithm
moves traffic to the remaining
MCT switch has already
3 link of the LAG
learned MAC‐B address
so can forward traffic
without disruption Normal Traffic Path
Ethernet Link
Alternate Traffic Path
Now we see a link failure occurring between the Client A switch and MCT peer, SW1.
The link failure forces the Client A switch to forward traffic over the only remaining link
(connecting to SW2).
SW2 will forward the traffic out of it’s local Server B interface.
The return traffic from Server B to Client A is not impacted by this link failure because the
return traffic can be passed over the ICL link and then forwarded to client A from the SW2
connection.
MCT Show Commands
Now that we’ve see how MCT operates, let’s take a look at the show commands to verify it
is functioning.
Displaying MCT Configuration
• Display cluster configuration
MCT1# show cluster MCT config
cluster MCT 1
rbridge-id 1
session-vlan 150
icl ICL ethernet 1/1/1
peer 1.1.1.2 rbridge-id 2 icl ICL
deploy
client Client1
rbridge-id 100
client-interface ethernet 1/1/3
deploy
client Client2
rbridge-id 200
client-interface ethernet 1/1/5
deploy
Once the cluster is configured, you can use the show cluster <cluster ID>

config command to view the configuration. Remember to make sure each client and
the cluster are deployed.
Display MCT Cluster
• Display cluster information
MCT1(config)# show cluster 1
Cluster MCT 1
=============
Rbridge Id: 1, Session Vlan: 150
Cluster State: Deploy
Client Isolation Mode: Loose
Member Vlan Range: 2
ICL Info:
---------
Name Port Trunk
ICL 1/1/1 1
Peer Info:
----------
Peer IP: 10.1.1.2, Peer Rbridge Id: 2, ICL: ICL
KeepAlive Interval: 10 , Hold Time: 90, Fast Failover
Active Vlan Range: 2
Last Reason for CCP Down: Not Down
Peer State: CCP Up (Up Time: 2 days: 1 hr: 6 min:48 sec)
Client Info:
------------
Number of Clients configured: 2
Name Rbridge-id Config Port Trunk FSM-State
Client1 100 Deployed 1/1/3 2 Up
The show cluster command displays a lot of useful information including this peers

RBridgeID, the Session VLAN, and the cluster state, which is deploy. It also shows the ICL
port number and the peer information. Notice that the Peer State is CCP Up. At the bottom
of the output, are the clients. Notice that they are deployed.
Displaying Client Information
• Display a list of clients and information
MCT1# show cluster MCT client

Client Ports
Client Info: and Trunk ID
------------
Number of Clients Configured: 2
Name Rbridge-id Config Port Trunk FSM-State
Configured clients by name State of the client, Finite State

and RBridgeID deployed or undeployed Machine
status
The show cluster client command displays the client information including the

client name, RBridgeID, state, primary port, number of ports in the LAG connected to the
client and the FSM‐State. The FSM‐State displays status of the Finite State Machine (FSM).
Valid states are:
• Up – CCEP ports on both MCT peers are up.
• Local Up – CCEP ports are up on local MCT peer, but down on remote peer.
• Remote Up – CCEP ports are down on local MCT peer, but up on remote peer.
• Admin Up – CCEP ports on both MCT peers are enabled and deployed but down.
Displaying Client Information
• Display client details by client name or RBridgeID
MCT1# show cluster MCT client Client2
Cluster MCT 1
=============
Rbridge Id: 1, Session Vlan: 150 Cluster Information including,
Cluster State: Deploy RBridgeID, Session VLAN,
Client Isolation Mode: Loose and Member VLANs
Member Vlan Range: 2
Client Info:
------------
Client: Client2, rbridge-id: 200, Deployed Client Information
Client Port: 1/1/5, Trunk Id :3 including, RBridgeID,
Client portmask: ethe 1/1/5 client ports, and state
State: Up
Number of times Local CCEP down: 0
Number of times Remote CCEP down: 0 Client
Number of times Remote Client undeployed: 0 statistics
Total CCRR packets sent: 2
Total CCRR packets received: 1
Display more client details using the show cluster command followed by the cluster

name and client name. Here we see the cluster information, as well as the client
information and statistics.
Displaying CCP Information
• Display a list of peers
– You can also specify a peer by IP address to view information specific to that peer
MCT1# show cluster MCT ccp peer

PEER IP ADDRESS STATE UP TIME
--------------- ------------- --------------
10.1.1.2 OPERATIONAL 0 days: 2 hr:25 min:16 sec
Peers by address
State, none or
operational, Up-time
To display a list of cluster peers, use the show cluster ccp peer command with

the cluster name. Here we see that the peer at IP address 10.1.1.2 is operational, and the
amount of time the peer has been up.
Displaying CCP Information (cont.)
• Use the detail parameter to view more CCP information
MCT1# show cluster MCT ccp peer detail
**************Peer Session Details*********************
IP address of the peer 10.1.1.2
Rbridge ID of the peer 2
Session state of the peer OPERATIONAL
Next message ID to be send 287
Keep Alive interval in seconds 30
Hold Time Out in seconds 90
Fast Failover is enable for the session
UP Time 0 days: 2 hr:25 min:16 sec
Number of tcp packet allocations failed 0
Message Init Keepalive Notify Application Badmessages
Send 3 2421 2 53 0
Receive 3 2415 0 37 0
TCP connection is up
TCP connection is initiated by 10.1.1.1
TCP connection tcbHandle not pending
TCP connection packets not received
TCP connection packets not received
**************TCP Connection Details*********************
TCP Connection state: ESTABLISHED Maximum segment size: 1436
Local host: 10.1.1.1, Local Port: 12203
Remote host: 10.1.1.2, Remote Port: 4175
<Output Truncated>
Add the detail parameter, and you can see peer connection information as well as the
communication between the peers on the TCP port. Here we see the TCP connection is
ESTABLISHED.
Summary
– Identify supported Spanning Tree Protocols
– Configure Spanning Tree and Rapid Spanning Tree
– Identify Ruckus enhanced features to Spanning Tree
– Describe Multiple Spanning Tree (MSTP) 802.1s and its purpose
– Describe the benefits of Multi‐Chassis Trunking (MCT)
– Understand and discuss MCT terminology
– Display MCT operational status
This concludes the Layer 2 Redundancy module. You should now be able to:
Identify supported Spanning Tree Protocols
Configure Spanning Tree and Rapid Spanning Tree
Identify Ruckus enhanced features to Spanning Tree
Describe Multiple Spanning Tree (MSTP) 802.1s and its purpose
Describe the benefits of Multi‐Chassis Trunking (MCT)
Understand and discuss MCT terminology
Display MCT operational status
End of Module 9:
Layer 2 Redundancy
This completes the layer 2 redundancy module. I encourage you to continue to the next
module of the ICX 150 Implementer course. Thank you.
ICX 150 ICX Stacking Technology
Module 10:
ICX Stacking Technology
Revision 0419
This module focuses on Ruckus stacking technology using the different ICX switches.
Objectives
• After completing this module, attendees should be able to:
– Describe stacking technology and its benefits
– Describe stacking features including long‐distance stacking and hitless stacking
– Explain how to configure stacking using the interactive‐setup utility
– Display stack information once the stack is formed
– Explain how to replace and add new units to a stack
At the completion of this module you will be able to:
• Describe stacking technology and its benefits
• Describe stacking features including long‐distance stacking and hitless stacking
• Explain how to configure stacking using the interactive‐setup utility
• Display stack information once the stack is formed
• Explain how to replace and add new units to a stack
Stacking Benefits
• Some of the benefits and features of stacking include:
– Stacking without any additional hardware cards or software licenses1
– Single point of management
– Standards‐based dual‐purpose stacking/uplink ports
– Trunk‐able stacking ports
– Large port density per stack
– Ring and linear topologies
– Interactive‐setup utility to make stacking
configuration easy and secure
– Packet switching in hardware between ports on stack units
– Protocols operate on a stack in the same way as on a chassis‐based system
Footnote 1: Some ICX switch SKUs require a 10Gbps license to support stacking.
Here we list some of the features and benefits of stacking:
• Stacking on ICX devices does not require any additional hardware cards. Nor any
stacking‐specific software licenses, however some ICX switches require a 10Gbps
port licenses.
• Stacking offers a single point of management with the active controller in the stack.
• Most ICX models offer dual‐purpose ports for stacking or uplink. As well as, trunk‐
able stacking ports.
• Stacking offers a large port density per stack.
• ICX devices can be stacked in different topologies for your environment, including
ring and linear.
• The interactive‐setup utility makes stacking configuration easy and secure.
• The Ruckus stacking technology allows for packet switching in hardware between
ports on stack units.
• And protocols operate on a stack in the same way as on a chassis‐based system.
We’ll take a closer look at most of these features in this module.
Stacking Topologies
• Linear topology
– End units of the stack use
one stack port, leaving the
other port for data
• Ring topology
– Ruckus recommended topology
for redundancy and resiliency
– All stack members must have
two stacking ports
This slide shows the two supported topologies for a traditional stack. They are the ring and
linear.
In the linear topology there is a single stack cable connection between each switch that
carries two‐way communications across the stack. In a ring topology, an extra cable is
connected between the top and bottom switches forming a “ring” or “closed‐loop.” The
closed‐loop cable provides a redundant path for the stack link, so if one link fails, stack
communications can be maintained.
Ring is the Ruckus recommended topology because it offers the best redundancy and the
most resilient operation. Unicast switching follows the shortest path in a ring topology.
When the ring is broken, the stack recalculates the forwarding path and then resumes the
flow of traffic within a few seconds.
Trunked Stacking
• Stacking trunks can be configured to increase stacking bandwidth and provide better
resiliency
• As long as one port of the trunk is connected, communication between the neighboring
units will continue
• Traffic is load balanced to the trunk ports
• If one stacking port on a trunk goes down, no stack
election or topology changes occur
– Traffic interruption should be in the sub‐second range
• Stacking trunks range in size from 2‐6 ports, depending on switch model
A stack‐trunk increases the stacking port bandwidth up to 400 Gbps, depending on switch
model, and provides better resilience than a single port‐to‐port link. As long as at least one
port on the trunk is connected properly, communication between the neighboring units will
work. Traffic is load balanced to the trunk ports.
When only one stacking port on a trunk goes down, no stack election or topology changes
should occur. The resulting traffic interruption time should be in the sub‐second range as
the system detects that the port is down and re‐programs hardware.
Stacking trunks range in size from 2‐6 ports, depending on switch model and other factors,
which will be discussed later in this presentation.
Stacking Hardware
Lets start with an overview of the stacking hardware on the different Ruckus ICX switches.
Valid Stack Port Sets
• Beginning with release 8.0.90, stacking ports cannot be chosen arbitrarily
• Valid‐stack‐port sets define the starting ports, in each direction of a stack, or stack trunk
• Each ICX device has specific valid stack port sets
View the release 8.0.90 Stacking
Configuration Guide for a complete
list of valid‐stack‐port sets on each
ICX model
In previous releases of ICX firmware, you had some flexibility in determining which ports
could be used for stacking. However, to maximize stack functionality, release 8.0.90
introduces a concept of valid stack ports. These ports define the single stack ports, one in
each direction, or the first port in a stack trunk. Due to this change there is no longer a
concept or configuration command defining a default‐stack‐port.
Because of the flexibility and variance of ICX switch models, each may have several
combinations of valid‐stack‐ports. Therefor, it is essential to review the Ruckus FastIron
Stacking Configuration Guide for release 08.0.90 to identify all of the potential valid‐stack‐
port pairs on an ICX switch. The example here shows valid‐stack‐port pairs for the ICX 7750
and 7850. As you can see the ICX 7750 has several more valid‐stack‐port pairs than the
7850.
Looking at how the valid‐stack‐ports are represented, you see two ports followed by a
number. The ports identify a pair of ports that can be defined as stack‐ports. The third
number indicates the maximum size of a stack trunk, if this stack‐port pair is selected. So as
you can see, your selection of stack‐ports could impact the overall bandwidth increase
available using stack‐trunks.
ICX 7150‐C12P Stacking Hardware
• 2 x 1/10 GbE SFP+ ports in slot 3:
– x/3/1 and x/3/2 for stacking
• Both ports can be upgraded to 10 GbE SFP+
– Stacking is only supported on 10 GbE ports
x/3/1
x/3/2
The ICX 7150‐C12P has two 1/10 GbE SPF+ ports on the front of the device. These ports are
in slot 3. These ports are the only vlaid‐stack‐port pair for this model of ICX 7150. If you do
not use these ports for stacking, they can be used for uplink.
ICX 7150‐48ZP Stacking Hardware and Trunks
– x/2/1 to x/2/4 for stacking
– x/2/5 to x/2/8 for uplink x/2/1 x/2/3
• All 8 ports can be upgraded to 10 GbE SFP+
• Valid‐stack‐port set is x/2/1 and x/2/3
• Stacked trunks can be formed on ports x/2/1 and x/2/2, ‐ x/2/1 x/2/3

and x/2/3 and x/2/4
x/2/2 x/2/4
Ruckus(config)# stack unit 1
Ruckus(config-unit-1)# stack-trunk 1/2/1 to 1/2/2
The ICX 7150‐48ZP has eight 1/10 GbE SPF+ ports on the front of the device. The ICX 7150‐
48ZP has only one valid‐stack‐port pair, ports x/2/1 and x/2/3. Stack trunks can be
configured bundling ports x/2/1 and 1/2/2 in one direction and bundling ports x/2/3 and
x/2/4 in the other direction. Any ports not used for stacking can be used for uplink.
By default all eight of the ports in slot 2 are 1 GbE, but they can be upgraded to 10 GbE
with a Ports on Demand software license. Stacking is only supported on 10 GbE ports.
ICX 7150‐24 and ‐48 Stacking Hardware and Trunks
• All other ICX 7150 models support the following stacking capabilities
– x/3/1 to x/3/4 for stacking
– All 4 ports must be license upgraded to 10 GbE
• Stacking is only supported on 10 GbE ports x/3/1 x/3/3
• Valid‐stack‐port set is
x/3/1 and x/3/3
• Stacked trunks can be formed on ports x/3/1 and x/3/2, ‐
x/3/1 x/3/3
and x/3/3 and x/3/4
Ruckus(config)# stack unit 1 x/3/2 x/3/4

The remaining ICX 7150 24‐ and 48‐port variants support stacking on the 4 x1/10 SFP+
ports in sot 3. There is only one valid‐stack‐port pair for these and those are x/3/1 and
x/3/3. In order to allow stacking all of the stack ports must be upgraded to 10 GbE, as
stacking is not supported in 1 GbE mode.
You can for stack port trunks using ports x/3/1 to x/3/2 and ports x/3/3 to x/3/4.
The configuration example shows the stack-trunk command being employed to
manually configure these ports as stack trunks. Manual configuration may not be necessary
if you are using the stack interactive‐setup utility, which will be discussed later in this
presentation.
Revision 0419 10 ‐ 10
ICX 7250 Stacking Hardware
• 8 x 1/10 GbE SFP+ ports in slot 2
• You can change the 4 stacking ports to use x/2/1 to x/2/4
or x/2/5 to x/2/8
• All 8 ports can be upgraded to 10 GbE SFP+
• Default valid‐stack‐port set is x/2/1 and x/2/3
– Can be changed to
x/2/5 and x/2/7 x/2/1 x/2/3 x/2/5 x/2/7
Ruckus(config-unit-1)# stack-port 1/2/5

stack-port 1/2/5 replaces stack-port 1/2/1 and stack-port 1/2/3
The ICX 7250 has eight 1 GbE SPF ports on the front of the device. These ports are in slot 2.
Four ports are reserved for stacking, ports x/2/1 through x/2/4, and four ports are reserved
for uplink, ports x/2/5 through x/2/8. If you do not uses all four ports for stacking, the
other ports can be used for uplink.
On the ICX 7250, stacking is only supported on 10 GbE ports. By default all eight ports in
slot 2 are 1 GbE, but they can be upgraded to 10 GbE with a Ports on Demand software
license.
The default stacking ports are x/2/1 and x/2/3, but they can be changed to x/2/5 and x/2/7
using the stack-port command. This is a two‐step process, changing the stacking port
to x/2/5 will result in stacking being disabled on ports x/2/1 and x/2/3. Next you are
required to designate port x/2/7 as a stacking port by using the stack-port command
again for the port.
Revision 0419 10 ‐ 11
ICX 7250 Stack Trunks
• Stacked trunks can be formed using the following port combinations:
– If stacking is enabled on ports x/2/1 – x/2/4, trunks can be formed on ports x/2/1 to x/2/2, and x/2/3 to
x/2/4
– If stacking is enabled on ports x/2/5 – x/2/8, trunks can be formed on ports x/2/5 to x/2/6, and x/2/7 to
x/2/8
x/2/1 x/2/3 x/2/5 x/2/7
x/2/2 x/2/4 x/2/6 x/2/8

As I mentioned the ports are divided in groups of four. Ports x/2/1 – x/2/4 on the left, and
ports x/2/5 – x/2/8 on the right. You can create the following stack trunks:
• If stacking is enabled on the default stacking ports (x/2/1 – x/2/4), trunks can be
formed on ports x/2/1 to x/2/2, and x/2/3 to x/2/4
• If stacking is enabled on ports x/2/5 – x/2/8, trunks can be formed on ports x/2/5 to
x/2/6, and x/2/7 to x/2/8
Revision 0419 10 ‐ 12
• The two 1 x 40 QSFP+ modules on the back of the device are the default stacking ports for
the ICX 7450
– Slots are number 3 and 4 from left to right
– System default valid‐stack‐port set is x/3/1 and x/4/1
• Alternative valid‐stack‐port‐set is x/2/1 and x/2/3
x/3/1 x/4/1
The ICX 7450 has two 1 x 40 QSFP+ stacking ports on the rear of the device. These are the
default stacking ports and are in slots 3 and 4 from left to right. These ports are numbered
x/3/1 and x/4/1.
Revision 0419 10 ‐ 13
ICX 7450 Stacking Hardware (cont.)
• Slot 2 on the front of the ICX 7450 supports a 4 x 10 GbE SFP+ module for uplink or
stacking
– You can use front slot 2, or back slots 3 and 4 for stacking, not both
– To use the 4 x 10 GbE ports, change the stacking‐ports from x/3/1 and x/4/1 to ports x/2/1 and x/2/3
using the stack-port command
ICX7450-24P Router(config-unit-1)# stack-port 1/2/1
Reload required to form a stack with Module 2 ports. Please write memory and
then reload or power cycle.
ICX7450-24P Router(config-unit-1)# stack-port 1/2/3
x/2/1 x/2/3
The ICX 7450 also has a 4 x 10 SFP+ module on the front of the device for uplink or
stacking. These ports are in slot 2.
You can create a stack using the default ports on the back of the device, or the ports in slot
2 shown here, but not both.
You can change the stacking ports using the stack-port command. This is a two‐step
process, changing the stacking port to x/2/1 will result in stacking being disabled on ports
x/3/1 and x/4/1. Next you are required to designate port x/2/3 as a stacking port by using
the stack-port command again for the port.
You must change the stack ports from the back ports x/3/1 and x/4/1, to the front ports
x/2/1 and x/2/3 if they are going to be used. A reload is required after changing the stack
ports.
Revision 0419 10 ‐ 14
• If the stack ports are changed to x/2/1 and x/2/3, two stack trunks can be formed, pairing
ports x/2/1 to x/2/2, and x/2/3 to x/2/4
x/2/1 x/2/3
x/2/2 x/2/4

You can create two stacking trunks on the 7450 using the front ports, but remember, you
have to define them as stack ports first. Two 2‐port trunks can be configured combining
ports x/2/1 and x/2/2 together, and ports x/2/3 and x/2/4 together.
Revision 0419 10 ‐ 15
• By default, the two 100 GbE ports on the rear are the default stacking ports for the ICX
7650
– When rear ports are operating in 100 Gbps mode (default), the valid‐stack‐port pair is x/3/1 and x/3/2
x/3/2 x/3/1
– When rear ports are operating in 40 Gbps mode, the valid‐stack‐port pair is x/3/1 and x/3/3
x/3/3 x/3/1
On the ICX 7650, ports x/3/1 and x/3/2 are used for stacking when the ports are being used
in 100 Gpbs mode, which is the default. However, the ports can also be configured to
operate in 40 Gbps mode. In this case the valid‐stack‐port pair is ports x/3/1 and x/3/3.
40GbE mode is the only mode on the ICX 7650 that supports stack‐trunks.
Note that the rear‐facing ports on the ICX 7650 are numbered from right‐to‐left.
Revision 0419 10 ‐ 16
• When the rear ports are operating in 40 Gbps mode, two stack trunks can be formed
between x/3/1 and x/3/2, and between x/3/3 and x/3/4
x/3/4 x/3/3 x/3/2 x/3/1
Ruckus(config) rear-module stack-40g

Ruckus(config) write mem
[ Reload required ]

You can create stacking trunks on the 7650, but only when the rear port are operating in 40
Gbps mode. This a accomplished with the rear‐module stack‐40g command. The change in
functionality requires a reset. Be sure to save your configuration before performing the
switch reset. After the reboot, the valid‐stack‐ports will be x/3/1 and x/3/3. Then two 2‐
port trunks can be configured combining ports x/3/1 to x/3/2, and ports x/3/3 to x/3/4.
Revision 0419 10 ‐ 17
• The ICX 7750 has 2 slots containing 6 x 40 GbE ports that can be used simultaneously for
stacking
• Slot 2 on the front has ports x/2/1 to x/2/6
• Default valid‐stack‐port pair is x/2/1 and x/2/4
– Other valid‐stack‐port pairs include:
• x/3/1, x/3/4 x/2/1 x/2/3 x/2/5
• x/2/1, x/3/1
• x/2/5, x/2/6 x/2/2 x/2/4 x/2/6
• x/3/5, x/3/6
• x/2/5, x/3/5
x/3/1 x/3/3 x/3/5
x/3/2 x/3/4 x/3/6
The 7750 has 2 slots with six 40 GbE ports, slot 2 on the front has ports x/2/1 to x/2/6, slot
3 on the rear has port x/3/1 to x/3/6. The default factory stacking ports are x/2/1 and
x/2/4.
There are various pairings of stack ports available on the ICX 7750, including those shown
here. The pairing being selected affects the number of ports that can be configured in a
stack‐trunk.
Revision 0419 10 ‐ 18
• Configure up to 2 stack trunks on the ICX 7750
• Possibilities include:
6‐port Trunk 3‐port Trunk 2‐port Trunk
x/2/1 through x/2/6 (down) x/2/1 through x/2/3 (down) x/2/5 through x/2/6 (down)
x/3/1 through x/3/6 (up) x/2/4 through x/2/6 (up) x/3/5 through x/3/6 (up)
x/3/1 through x/3/3 (down)
x/3/4 through x/3/6 (up)
Front Ports Back Ports

x/2/1 x/2/3 x/2/5 x/3/5
x/3/1 x/3/3
x/2/2 x/2/4 x/2/6 x/3/2 x/3/4 x/3/6
On the ICX 7750, it is possible to configure up to two stack trunks. This chart shows the
different options for creating 6‐port, 3‐port, or 2‐port trunks. Take a minute to review the
chart, and continue when you are ready.
NOTE: Stacking cannot be enabled on Ruckus ICX 7750 devices that have a breakout
configuration on any 40 GbE ports, and vice versa.
Revision 0419 10 ‐ 19
• The ICX 7850‐32Q has 8 ports in slot 3 that can be used for stacking
– The valid‐stack‐port pair is x/3/1 and x/3/5
x/3/1 x/3/5
• The ICX 7850‐48FS/F has 8 ports in slot 2 that can be used for stacking
– The valid‐stack‐port pair is x/2/1 and x/2/5
x/2/1 x/2/5
All three variants of the ICX 7850 support 8 ports for stacking. On the ICX 7850‐32Q these
ports are located in slot 3. On the two 48‐port versions, the stacking ports are located on
slot 2. Therefore the default valid‐stack‐ports on the 7850‐32Q are ports x/3/1 and x/3/5.
and on the 48‐port versions they are ports x/2/1 and x/2/5,
Revision 0419 10 ‐ 20
• On the ICX 7850‐32Q stacking trunks of up to 4 ports can be configured using ports x/3/1
to x/3/4 and ports x/3/5 to x/3/8
x/3/1 x/3/3 x/3/5 x/3/7
x/3/2 x/3/4 x/3/6 x/3/8
• On the ICX 7850‐48FS/F stacking trunks of up to 4 ports can be configured using ports
x/2/1 to x/2/4 and ports x/2/5 to x/2/8
x/2/1 x/2/3 x/2/5 x/2/7
x/2/2 x/2/4 x/2/6 x/2/8
All three models of ICX 7850 support 4‐port stacking trunks in each direction. The ICX 7850‐
32Q supports these trunks on ports in slot 3. The ICX 7850‐48F/FS support these trunks on
ports in slot 2.
Revision 0419 10 ‐ 21
Next we’ll look at how we can configure the distributed chassis solution with long distance
stacking.
Revision 0419 10 ‐ 22
• Distances between stack units is extened:
– Up to 40 kilometers using 40G QSFP‐ER4 optics
– Up to 10 kilometers using 100G QSFP28 and 40G QSFP‐LR4 optics
• Currently supported on:
– ICX 7450
– ICX 7650
– ICX 7750
– ICX 7850
The long distance stacking, distributed chassis topology offers the ability to house stacking
units in geographically separate locations, like different buildings, as shown here. Using 40G
QSFP‐ER4 optics, distances up to 40 kilometers can be achived between stack units. !00G
ports with QSFP28 optics and 40G ports with QSFP‐LR4 optics can reach distances of 10
kilometer.
Long distance stacking is available on the ICX 7450, 7650, 7750, and 7850 switch models.
Revision 0419 10 ‐ 23
100‐Gbps Long Distance Stacking – 10 km
• QSPF28 100‐Gbps ports support long distance stacking up to 10 kilometers
– ICX 7650 supports 100‐Gbps long distance stacking up to 10km on ports x/3/1 and x/3/2
– ICX 7850‐32Q supports 100‐Gbps long distance stacking up to 10km on ports x/3/1 to x/3/8
– ICX 7850‐48FS/F supports 100‐Gbps long distance stacking up to 10km on ports x/2/1 to x/2/8
The ICX 7650 and both variants of the ICX 7850 support 100‐Gbps port speeds used for
long distance stacking at distance up to 10 kilometers.
The ICX 7650 supports 100‐Gbps long distance stacking on ports x/3/1 and x/3/2 when the
rear slot is operating in the default 100 Gbps‐mode.
The ICX 7850‐32Q supports 100‐Gbps long distance stacking on ports x/3/1 through x/3/8.
ICX 7850‐48FS/F supports 100‐Gbps long distance stacking on ports x/2/1 through x/2/8.
Note: The distances reachable at these speeds is dependent on the optics installed in the
QSFP28 interface. 10km distances require 100G‐QSFP28‐LR4 optics.
Revision 0419 10 ‐ 24
40‐Gbps Long Distance Stacking – Up to 40 km
• QSPF‐ER4 optics on some ICX switches support long distance stacking up to 40 kilometers
– QSFP‐LR4 optics in the same ports only support distances up to 10km
– All ICX 7750 models support 40‐Gbps long
distance stacking up to 40km on:
• Front ports x/2/1 to x/2/6
• Rear ports x/3/1 to x/3/6
– ICX 7850‐32Q supports 40‐Gbps long distance stacking up to 40km on ports x/3/1 to x/3/8
– ICX 7850‐48FS/F supports 40‐Gbps long distance stacking up to 40km on ports x/2/1 to x/2/8
ICX devices that support QSFP‐ER4 optics support long distance stacking up to 40 km.
These include the ICX 7750 and 7850.
The ICX 7750 supports 40‐Gbps long distance stacking on ports x/2/1 through x/2/6 on the
front of the unit and ports x/3/1 through x/3/6 on the back of the unit.
The ICX 7850‐32Q supports 40‐Gbps long distance stacking on ports x/3/1 through x/3/8
ICX 7850‐48FS/F supports 40‐Gbps long distance stacking on ports x/2/1 through x/2/8
QSFP+ interface. 40km distances require 40G‐QSFP‐ER4 optics. Distances of 10km can be
reached using these same interface with 40G‐QSFP‐LR4 optics.
Revision 0419 10 ‐ 25
40‐Gbps Long Distance Stacking – 10 km
• QSPF‐LR4 optics on some ICX switches support long distance stacking up to 10 kilometers
– ICX 7750 and 7850 devices that support QSFP‐ER4 for 40 km also support QSFP‐LR4 for 10 km
– All ICX 7450 models support 40‐Gbps long distance stacking up to 10km on ports x/3/1 and x/4/1
– All ICX 7650 models support 40‐Gbps long distance stacking up to 10km on ports x/3/1 to x/3/4
The ICX 7750 and 7850 ports described on the previous slide also support stacking
distances up to10km when using 40G‐QSFP‐LR4 optics.
In addition to this, the ICX 7450 supports 40‐Gbps long distance stacking on ports x/3/1
and x/4/1 on the back of the unit.
The ICX 7650 supports 40‐Gbps long distance stacking on ports x/3/1 through x/3/8 which
are also on the rear of the unit.
QSFP interface. 10km distances require 40G‐QSFP‐LR4 optics.
Revision 0419 10 ‐ 26
Stacking Cables & Optics
• Each ICX model supports different
https://www.ruckuswireless.com/ optics and cables for long distance and
short distance stacking
• Download the Ethernet Optics Family
Datasheet and Support Matrix for the
latest information on ICX optics and
cable support for stacking
As we have just seen, the different ICX models support different optics and cables for long
distance and short distance stacking.
For the most up‐to‐date information on ICX optics and cable support for stacking, please
download the Ethernet Optics Family Datasheet and Support Matrix.
These can be found on the ruckuswireless.com website.
Revision 0419 10 ‐ 27
Stacking Architecture
Now that we have gone over the hardware components of stacking, let’s take a look at the
architecture of stacking.
Revision 0419 10 ‐ 28
Stack Roles
• Active controller
– Stack member with highest priority, handles stack management
– Console redirection from all units to active controller
• Standby controller
– Stack member with 2nd highest priority
– Will take over active controller duties if active controller fails
• Member
– Unit in the stack that is neither active nor standby controller
– Eligible for election to standby or active controller if necessary
Switches in a stack have one of the following roles:
• The active controller is the stack member with highest priority, and it handles all
stack management through its console. Configuration of all stack units is directed
from the active controller.
• The standby controller is the stack member with 2nd highest priority. The standby
takes over active controller duties if the active controller fails.
• Member units are neither active nor standby controllers, but they are eligible for
election to standby or active if necessary.
Revision 0419 10 ‐ 29
Active Controller
• The active controller handles all stack management including:
– SW image downloads to stack members
– Controlling the console CLI
Active Controller
CLI
Config
– Building and propagating the Forwarding Database Config
FDB
(FDB) to all stack members SWFDB
image
SW image
– Configuring all system and interface‐level features
– Pushing configuration to each stack member
– Synchronizing runtime configuration to the
standby controller
– Sending incremental CLI changes to the
standby controller
– Insuring the standby controller receives a copy
of all control packets and protocols running on
the active controller
The responsibility of the active controller is to handle all stack management including:
• Downloading software images to all stack members, and controlling the console for the
entire stack. All stack configuration is done from the active controller, including all
system and interface‐level features. The active controller then pushes the configuration
to each stack member.
• The active controller builds and propagates the Forwarding Database (FDB) to all stack
members, synchronizes runtime configurations to the standby controller, and sends
incremental CLI changes to the standby controller.
• The active controller also insures that the standby controller receives a copy of all
control packets and protocols running on the active controller.
Revision 0419 10 ‐ 30
Stack Unit Assignment
• During the active controller election process,
switches are assigned a switch ID automatically
– Switch ID does not designate physical switch position in
the stack
• Valid switch ID numbers are 1 through 12
• Switches that receive a different switch ID from
the default of 1, reload and take the newly
assigned ID
• Switch IDs can be pre‐assigned or renumbered
the using the stack interactive-setup
command
During the active controller election process, switches are assigned a switch ID. This ID
does not designate the switches physical position in the stack, it is just an identifier. All ICX
switch families use switch IDs from 1 through 12.
By default all switches have the ID of 1. Switches that receive a different ID from the active
controller, reload and take the newly assigned ID.
Switch IDs can be pre‐assigned or renumbered the using the stack interactive-
setup command.
Revision 0419 10 ‐ 31
Hitless Stacking
Next we’ll take a look at the hitless stacking feature.
Revision 0419 10 ‐ 32
Hitless Stacking Overview
• A high availability feature set that ensures sub‐second or no loss of data traffic during the
following events:
– Active controller failure or role change
– Software failure
– Addition or removal of units in a stack
– Removal or disconnection of the stacking cable between the active controller and the standby controller
• Standby controller takes over the active role, and the system continues to forward traffic
seamlessly
• Enabled by default as of software version 8.0.20
– Use the hitless-failover command on earlier versions of software
Hitless stacking is a high availability feature set that ensures sub-second or

no loss of data traffic during the following events:
• Active controller failure or role change.
• Software failure.
• Addition or removal of units in a stack.
• Removal or disconnection of the stacking cable between the active controller
and the standby controller.
During such events, the standby controller takes over the active role, and the
system continues to forward traffic seamlessly, as if no failure or topology
change has occurred. In software releases that do not support hitless
stacking, events such as these could cause most of the units in a stack to
reset, affecting data traffic.
Hitless stacking is supported on ICX units in a traditional stack, and is enabled by default as
of software version 8.0.20 and above.
Revision 0419 10 ‐ 33
Supported Events
• Events supported by hitless stacking:
– Active controller failure or role change
– Software failure
– Addition or removal of units in a stack
– Removal or disconnection of the stacking cable between the active controller and the standby controller
• Events not supported by hitless stacking:
– Unit ID change (during stack formation or using interactive‐setup)
– Stack merge
– Software upgrade
• Can be disabled using the no hitless-failover enable command
Hitless stacking is supported during a switchover or failover. A hitless stacking switchover is
a manually‐controlled (CLI‐driven) or automatic switchover of the active controller and
standby controller without reloading the stack and without any packet loss to the services
and protocols that are supported by hitless stacking. A switchover is activated by the stack
switch‐over command. A switchover may also be activated by the priority command,
depending on the configured priority value.
A hitless stacking failover is an automatic, forced switchover of the active controller and
standby controller because of a failure or abnormal termination of the active controller.
During a failover, the active controller abruptly leaves the stack, and the standby controller
immediately assumes the active role. As with a switchover, a failover occurs without the
stack being reloaded. Unlike a switchover, a failover generally occurs without warning and
is likely to result in sub‐second packet loss (although packets traversing the stacking link
may be lost).
The following events are not supported by hitless stacking because they require a software
reload, which affects all data traffic:
• A unit ID change, either when a stack is formed, or when a unit is renumbered using
interactive‐setup.
• A stack merge, because when the old active controller comes back up, it reboots. If it
has fewer members than the present active controller, it loses the election,
regardless of its priority. If it has a higher priority, it becomes the standby controller
and is synchronized with the active controller.
• Stack upgrade, because software cannot be upgraded on stack units without impact
on traffic.
Revision 0419 10 ‐ 34
Supported Protocols and Services
• Protocols and services supported by hitless stacking:
– L2 switched traffic
– Layer3 IPv4 unicast routed traffic
– Layer3 IPv6 unicast ad multicast routed traffic
– Security
• Some protocols require addition configuration to achieve truly hitless failover
– For example, OSPF v2/v3 requires non‐stop routing to be enabled
View the release 8.0.90 Stacking Configuration Guide for a complete
list of protocols and services supported by hitless stacking
You can find a list of protocols that support hitless stacking in in the FastIron Ethernet
Switch Stacking Configuration Guide.
Revision 0419 10 ‐ 35
Revision 0419 10 ‐ 36
Revision 0419 10 ‐ 37
Manual Hitless Switchover
• Use the stack switch-over command to switchover from the active controller to the

standby controller without reloading the stack
• There is no packet loss to the services and protocols supported by hitless stacking
• A manual switchover could also be accomplished by lowering the priority of the active
controller
A switchover is activated by the stack switch-over command, but it can also be

activated by lowering the priority of the active controller to a value lower than the priority
of the current standby controller.
Revision 0419 10 ‐ 38
Stack Formation
Revision 0419 10 ‐ 39
Stack Formation Methods
1. Stack interactive‐setup utility
– Gives you control over the design of your stack topology
– The switch where the stack interactive-setup command is run becomes the active controller
2. Stack zero‐touch provisioning
– All member units must be “clean” with no startup or running configuration
– Member units are pre‐connected
– Device where stack zero-touch-enable is run will become the active controller
– Equivalent to selecting option 2 of stack interactive-setup where all suggested values are
accepted
3. Manual stack configuration
– Configure stacking on each unit individually, and enable stacking
– ID assignment is determined by the sequence in which you physically connect the units
There are three ways to form a stack. The first is the interactive‐setup utility which we will
be focusing on in this course. Using the interactive‐setup tool gives you control over the
design of your stack topology without having to apply configuration changes to each unit in
the stack. The switch where the stack interactive-setup command is run,
becomes the active controller.
The second method is stack zero‐touch provisioning. When you enable stack zero‐touch
provisioning on pre‐cabled stack of switches, the unit you start the provisioning on
becomes the active controller and the rest of the stack forms automatically. This method
requires that you start with clean units (except for the active controller), that do not
contain startup or run time configurations. This perfoms the same activity as selecting
option 2 of the stack interactive‐setup utility where all default suggestions are accepted
automatically, without administrative input.
The third method is manual stack configuration. With this method, you configure every unit
individually, and enable stacking on each unit. Once the units are connected together, they
will automatically operate as a stack. With this method the unit with the highest priority
becomes the active controller, and ID assignment is determined by the sequence in which
you physically connect the units.
Revision 0419 10 ‐ 40
Stack Interactive‐Setup
Now we’ll take a look at stack formation using stack interactive‐setup.
Revision 0419 10 ‐ 41
Interactive‐setup Utility
• Follow these steps to form a stack using interactive‐setup
1. Connect the devices using the stacking ports and cables
2. Power on the units
3. Configure stack enable on the intended Active controller at the global CONFIG level
Ruckus(config)# stack enable
4. Define stack‐ports on the intended Active controller – if using non‐default valid‐stack‐port pairs
Let’s take a look at the steps to form a stack using the interactive‐setup utility.
First you need to connect the devices using the correct stacking ports and cables, then you
need to power on the units.
Next, you enable stacking on the unit you want to be the active controller. You do this with
the stack enable command at the global CONFIG level.
If you are using stack ports that are not the default valid‐stack‐port pair, configure them
now. This is done with the stack-port command in the stack unit configuration context.
Revision 0419 10 ‐ 42
Interactive‐setup Utility (cont.)
5. Run the stack interactive-setup command

– A proprietary discovery protocol begins the discovery process in both upstream and downstream
directions
Ruckus# stack interactive-setup

You can abort stack interactive-setup at any stage by <ctrl-c>
0: quit
1: change stack unit IDs
2: discover and convert new units (no startup-config flash) to members
3: discover and convert existing/new standalone units to members
2&3 can also find new links and auto-trunk or convert chain(s) to ring.
Please type your selection: 2
Probing topology to find clean units...
T=2h45m53.1: Sending probes to ports: u1: 1/2/5 1/2/7,
The stack interactive‐setup is utility that walks you through creating and modifying ICX
switch stacks. When the utility is launched, you are given 4 options.
Option 0 allows you to quit the utility with no changes
Option 1 allows the changing of stack unit IDs on existing device within an operational
stack
Option 2 allows the discovery and conversion of new “clean” ICX devices that have no
startup‐config in the local flash into stack members
Option 3 allows the discovery and conversion of existing or new standalone units into stack
members
Both options 2 and 3 are a capable of discovering new links, automatically configure stack‐
trunks and convert from linear stack to a ring.
In this example we will choose option 2 to discover new units with no configuration. Probes
will be sent out of the configured stack‐ports to discover stack‐capable devices.
Revision 0419 10 ‐ 43
Accept the Topology
6. The example discovers a stack with a ring topology, enter y to accept the topology
Existing stack: ============================================================
+---+
2/5| 1 |2/7
+---+
Horizontal bars link to discovered units. Vertical bars link to stack units.
Chain #0: ==================================================================
#1: icx7250-24-port-management 609c.9f42.4100
#2: icx7250-48-port-management cc4e.24e0.5cd6
#3: icx7250-48p-poe-port-management cc4e.24e1.dc82
#4: icx7250-24p-poe-port-management 78a6.e121.10a4
1/2/5 1/2/7
| |
| |
2/3 2/1
+---+ +---+ +---+ +---+
|#1 |2/1==2/3|#2 |2/1==2/3|#3 |2/1--2/3|#4 |
+---+ +---+ +---+ +---+
Discovered 1 chain/ring
Chain #0: Do you want to select this chain? (enter 'y' or 'n’): y
After the probes are sent, a topology will be discovered and displayed for you. First it
displays an existing stack. Since this is a new stack, the devices in the existing stack is unit 1,
the unit where the stack interactive-setup command was ran. It also shows the
known stack‐ports.
Next, it shows the discovered units. First they are listed in the order they were discovered
and are given a number that will be referenced throughout the rest of the interactive‐setup
process. It also displays the specific device model and MAC address.
Beneath that is displayed the physical topology. At the top of this topology are the ports of
the discovering device. Then each connection is drawn out and labeled, detailing all of the
connecting ports between each discovered switch. Notice the numbering of each unit
corresponds with the numbered list above.
If the topology matches your intended design, select “y” for yes. If it does not match, check
the physical connection between devices to make sure they connected properly.
Revision 0419 10 ‐ 44
Automatic Creation of Stack Trunks
• Trunks are automatically detected in the stack interactive‐setup process
– Single stack ports are identified by “‐‐”
– Stack trunks are identified by “==“
1/2/5 1/2/7
| |
| |
2/3 2/1
+---+ +---+ +---+ +---+
|#1 |2/1==2/3|#2 |2/1==2/3|#3 |2/1--2/3|#4 |
+---+ +---+ +---+ +---+2
If the ICX switches in the stack support stack‐trunks and the connections are part of valid‐
stack‐port pairings the system will automatically detect the stack trunk links and configure
them appropriately.
Single stack links are identified by two dashes (‐‐) and stack trunks between units are
identified by two equal signs (==).
Revision 0419 10 ‐ 45
Accept or Assign the Unit IDs
7. Accept or define unit IDs
• You can accept the default unit IDs or you can change them here
Suggested stack unit number
• Pressing Enter accepts the suggested default
#1: icx7250-24-port 609c.9f42.4100, type an ID (No: 0, default: 2): [Enter]

#2: icx7250-48-port cc4e.24e0.5cd6, type an ID (No: 0, default: 3): [Enter]
#3: icx7250-48p-poe-port cc4e.24e1.dc82, type an ID (No: 0, default: 4): [Enter]
#4: icx7250-24p-poe-port 78a6.e121.10a4, type an ID (No: 0, default: 5): [Enter]
Device discovery order

You selected 4 unit(s): #1: ID=2, #2: ID=3, #3: ID=4, #4: ID=5,
Links U1--U2, #=1: 2/5--2/3

Links U2--U3, #=2: 2/1--2/3 2/2--2/4
Links U3--U4, #=2: 2/1--2/3 2/2--2/4
Links U4--U5, #=1: 2/1--2/3
Links U5--U1, #=1: 2/1--2/7
<Output Truncated>
You are now given the option to accept the new unit IDs. This proceeds in the same
sequence as the discovery process, beginning with discovered unit #1. Press the
Enter key to accept them. If you do not accept the numbers, the system prompts you to
enter different IDs, warns you that changing the IDs manually may modify the stack
configuration, and recommends that you save the configuration and reload it after the
stack is ready.
After IDs are selected, notice the correlation between the discovered unit # and the ID
assigned i.e. discovered unit #1 is assigned unit ID 2.
Next, a summary is displayed, again indicating what ID each discovered units will take on
and all of the links connecting each of the units together.
Revision 0419 10 ‐ 46
Accept Topology
8. Review and accept the topology
• Once topology is accepted the stack units will begin resetting and adding themselves to the stack
#1 #2 #3 #4
+---+ +---+ +---+ +---+ +---+
-2/7| 1 |2/5--2/3| 2 |2/1==2/3| 3 |2/1==2/3| 4 |2/1--2/3| 5 |2/1-
| +---+ +---+ +---+ +---+ +---+ |
| |
|---------------------------------------------------------------|
Proceeding will produce the above topology. Do you accept it? (enter 'y' or 'n'): y
stack interactive-setup discovers 4 unit(s) and sends stack-port/trunk to chain 0:
#1 609c.9f42.4100 U2, D0: 2/1 to 2/2, D1: 2/3
#2 cc4e.24e0.5cd6 U3, D0: 2/1 to 2/2, D1: 2/3 to 2/4
#3 cc4e.24e1.dc82 U4, D0: 2/1, D1: 2/3 to 2/4
#4 78a6.e121.10a4 U5, D0: 2/1, D1: 2/3
Ruckus#
Next, the full graphical view of the topology is displayed. This topology
includes all units in the discovered stack, all ports connecting them and
whether those connections are stack-ports or stack-trunks.
Then the interactive-setup utility will ask if you would like to begin the
process of producing the new stack. Select “y” for yes, if you accept.
You will be displayed one final summary and the stack information will begin
being pushed to all of the member units. They will all reset if needed and join
the stack upon bootup.
Revision 0419 10 ‐ 47
Stack Formation
9. Once the unit IDs are assigned, the active controller is elected, the stack is formed, and a standby
controller is designated
T=2h50m25.4: Election, was alone --> active, ID=1, pri=128, 5U(1-5), A=u1, nbr#=4 4, reason: u5: port-
up, ,
Debug: Apr 3 05:03:07 Detect stack unit 2 has different startup config flash, will synchronize it
Debug: Apr 3 05:03:07 Detect stack unit 2 has different ssh rsahost key, will synchronize it
Detect stack member 5 POE capable
Debug: Apr 3 05:03:07 Detect stack unit 5 has different startup config flash, will synchronize it
Debug: Apr 3 05:03:07 Detect stack unit 5 has different ssh rsahost key, will synchronize it
T:2h50m27.1: Done hot swap: active controller u1 sets u2 to Ready.
All entries are cleared on unit 1 for unit 5
<Output Truncated>
Debug: Apr 3 05:03:17 T=2h50m35.9: Synchronize ssh rsa host key to u2
T=2h51m30.2: Assigned unit 2 to be standby
Debug: Apr 3 05:04:13 T=2h51m32.2: start running config sync to standby u2
Debug: Apr 3 05:04:15 T=2h51m33.5: Running config sync to standby u2 is complete
Ruckus# write mem
Now that IDs have been assigned, the active controller is elected and the stack is formed.
You can see here that the active controller has a stack ID of 1 and a priority of 128.
You then see messages indicating detection of stack units as the finish reloading and join
the stack. This includes messaging indicating the need to synchronize the startup‐config
and SSH RSA host keys.
The last phase of the process of building a new stack is choosing the standby controller. In a
new stack, it should always be stack unit 2, and the running config will be synchronized to it
from the active controller.
Be sure to save the configuration with the write mem command when stack formation is
complete.
Revision 0419 10 ‐ 48
Displaying Stack Information
• The show stack command displays stack topology information

Ruckus# show stack
T=2h7m44.5: alone: standalone, D: dynamic cfg, S: static
ID Type Role Mac Address Pri State Comment
1 S ICX7250-24P active cc4e.24de.f3aa 128 local Ready
2 S ICX7250-24 standby 609c.9f42.4100 0 remote Ready
3 S ICX7250-48 member cc4e.24e0.5cd6 0 remote Ready
4 S ICX7250-48P member cc4e.24e1.dc82 0 remote Ready
5 S ICX7250-24P member 78a6.e121.10a4 0 remote Ready
Stack
active Unit ID standby
+---+ +---+ +---+ +---+ +---+
-2/5| 1 |2/7--2/1| 5 |2/3--2/1| 4 |2/3==2/1| 3 |2/3==2/1| 2 |2/3-
| +---+ +---+ +---+ +---+ +---+ |
| -- represents stack-port |
== represents stack-trunk
|---------------------------------------------------------------|
connections
Standby u2 - protocols ready, can failover ports
Role history: N: standalone, A: active, S: standby, M: member
U1: N->A->N->A
Current stack management MAC is cc4e.24de.f3aa

You can display information about any and all of the members in a traditional stack by
entering show commands from the active controller console. If you enter show commands
from the console port of a unit that is not the active controller, the information may not be
displayed correctly.
The show stack command displays general information about a traditional stack,
including the stack topology. You can also view additional information using the detail
parameter.
You can see here that stack ID 1 is the active controller with a priority of 128, and stack ID 2
is the standby. The output also shows the topology of the stack including the connections
between each unit. The stack ID is in the box, stack IDs are in hexadecimal (1‐9, A‐C) and
the slot/port of the connection is on either side of the ID. Double hyphens (‐‐) designate
single connections, and double equal signs (==) designate trunk ports.
Revision 0419 10 ‐ 49
Stack Zero‐Touch Deployment
Revision 0419 10 ‐ 50
Zero‐Touch Stack Deployment
• The Zero‐touch deployment only works with “clean” ICX units
– No startup‐config can be present
• Essentially performs stack interactive-setup, option #2 with no user
intervention and uses default selections
• Follow the same initial steps as stack interactive‐setup
– Connect devices
– Power on devices
– On unit intended to be the Active controller:
• Enable stacking
• Configure stack‐ports (if necessary)
The Zero‐touch deployment only works with “clean” ICX units that have no startup‐config
present. The utility essentially performs stack interactive‐setup, option #2 with no user
intervention and automatically applies the default selections.
The initial setup steps are the same as stack interactive‐setup:
• Connect devices
• Power on devices
• On unit intended to be the Active controller:
• Enable stacking
• Configure stack‐ports (if necessary)
Revision 0419 10 ‐ 51
Zero‐Touch Deployment – Start Process
• Start stack zero‐touch process
ICX7250-24P Router(config)# stack zero-touch-enable
– Zero‐touch stacking probes are sent every three minutes, so it may be necessary to wait for it to initialize
ICX7250-24P Router(config)#
Stack zero-touch-enable detects the following links:
Links U1--U6, #=1: 2/1--2/3
Links U6--U5, #=1: 2/1--2/3
Links U5--U4, #=1: 2/1--2/3
Links U4--U3, #=2: 2/1--2/3 2/2--2/4
Links U3--U2, #=1: 2/1--2/3
Links U2--U1, #=1: 2/1--2/3
#1 #2 #3 #4 #5
+---+ +---+ +---+ +---+ +---+ +---+
-2/3| 1 |2/1--2/3| 6 |2/1--2/3| 5 |2/1--2/3| 4 |2/1==2/3| 3 |2/1--2/3| 2 |2/1-
| +---+ +---+ +---+ +---+ +---+ +---+ |
| |
|----------------------------------------------------------------------------|
<Output Truncated>
The Zero‐touch stacking process is initiated with the stack zero-touch-enable
command from the global configuration context. This process sends probes down stack‐
ports every three minutes. Therefor, it may be necessary to wait for feedback that it is
discovering stack units. Keep in mind, there is no user intervention during this process.
Whatever is discovered is automatically configured, so it is critical to ensure all cables
between devices are connected properly before starting the zero‐touch process.
Once units are discovered, information will begin displaying on the console. First it will
display a list all of the discovered links between devices, including any stack‐trunks. Next
you will see the topology drawn out, again showing stack‐ports and stack‐trunks.
Revision 0419 10 ‐ 52
Zero‐Touch Deployment – Process Output
• Output Continued
stack zero-touch discovers 5 unit(s) and sends stack-port/trunk to chain 0:

#1 609c.9f42.4100 U6, D0: 2/1, D1: 2/3
#2 609c.9f41.be5c U5, D0: 2/1, D1: 2/3
#3 cc4e.24e0.5cd6 U4, D0: 2/1 to 2/2, D1: 2/3
#4 cc4e.24e1.dc82 U3, D0: 2/1, D1: 2/3 to 2/4
#5 78a6.e121.10a4 U2, D0: 2/1, D1: 2/3
<Output Truncated>
T=8m42.7: Assigned unit 2 to be standby

Debug: Apr 12 05:51:35 T=8m44.7: start running config sync to standby u2
Debug: Apr 12 05:51:36 T=8m46.3: Running config sync to standby u2 is complete
ICX7250-24P Router(config)#
Finally we see a message very much like the one seen when using the stack interactive‐
setup utility where a summary is displayed of the devices that will be instructed to reload
with the stack parameters shown.
After the stack units reload, messages detailing synchronization of startup‐config files and
RSA keys will be displayed, just like the stack interactive‐setup utility. And finally it will
display the synchronization to the standby unit to signal process completion.
Revision 0419 10 ‐ 53
Zero‐Touch Deployment – Display Results
• Display zero‐touch deployment results
ICX7250-24P Router(config)# show stack
T=16m15.2: alone: standalone, D: dynamic cfg, S: static
2 D ICX7250-24P standby 78a6.e121.10a4 0 remote Ready
3 D ICX7250-48P member cc4e.24e1.dc82 0 remote Ready
4 D ICX7250-48 member cc4e.24e0.5cd6 0 remote Ready
5 D ICX7250-24P member 609c.9f41.be5c 0 remote Ready
6 D ICX7250-24 member 609c.9f42.4100 0 remote Ready
active standby
+---+ +---+ +---+ +---+ +---+ +---+
-2/1| 1 |2/3--2/1| 2 |2/3--2/1| 3 |2/3==2/1| 4 |2/3--2/1| 5 |2/3--2/1| 6 |2/3-
| +---+ +---+ +---+ +---+ +---+ +---+ |
| |
|----------------------------------------------------------------------------|
Standby u2 - protocols ready, can failover
Role history: N: standalone, A: active, S: standby, M: member
U1: N->A
Here we can see the completed stack with all discovered units, stack‐ports and stack‐
trunks. This was all created without any user intervention, only to start the zero‐touch
discovery process with the stack zero-touch-enable command.
Revision 0419 10 ‐ 54
Zero‐Touch Deployment – Disable Upon Completion
• The zero‐touch process will continue running every three minutes as long as it is enabled
• After discovery completes, disable the feature with the no zero-touch-enable
command
ICX7250-24P Router(config)# no stack zero-touch-enable
ICX7250-24P Router(config)# write mem
Lastly we have an important note on the behavior of zero‐touch‐enable. It was stated
earlier that it sends discovery messages out stack ports every three minutes, well after you
complete your discovery, it continues to send discovery probes every three minutes. That is
why it should be disabled with the no stack zero-touch-enable command as
soon as the discovery is finished. And once this is complete, the configuration should be
saved with the write memory command.
Revision 0419 10 ‐ 55
Stack Unit Addition & Replacement
Revision 0419 10 ‐ 56
Adding a New Unit to a Stack
• Install a new unit in a stack using stack interactive-setup
• This method can be applied to clean units (option 2) or units that have existing
configurations (option 3)
1. Connect the new unit to the stack by connecting the appropriate stacking ports
2. Run stack interactive-setup on the active controller, and assign an ID to the new unit

• The active controller resets the new unit
3. Once the new unit boots and joins the stack, enter the write memory command on the active

controller
You can add, remove, or replace stack units using interactive‐setup or manually using static
configuration. The recommended method is to connect units to the stack before you supply
power to the units; however, you can also connect powered units.
Installing a new unit in a stack using stack interactive‐setup can be applied to clean units or
units that have existing configurations.
1. Connect the new unit to the stack by connecting the appropriate stacking ports.
2. Run stack interactive-setup on the active controller, and assign an ID to
the new unit. The active controller resets the new unit.
3. Once the new unit boots and joins the stack, enter the write memory command
on the active controller.
Revision 0419 10 ‐ 57
Adding a New Unit to a Stack (Cont.)
• To maintain sequential stack, install new unit between first and last unit in stack
• New units inserted in the middle of a stack, for example between existing units 2 and 3,
cause non‐sequential numbering
Ruckus# show stack
2 S ICX7250-24 standby 609c.9f42.4100 0 remote Ready
3 S ICX7250-24P member 78a6.e121.10a4 0 remote Ready
4 S ICX7250-48 member cc4e.24e0.5cd6 0 remote Ready
5 S ICX7250-48P member cc4e.24e1.dc82 0 remote Ready
6 S ICX7250-24P member 609c.9f41.be5c 0 remote Ready
active standby
+---+ +---+ +---+ +---+ +---+ +---+
-2/5| 1 |2/7--2/1| 5 |2/3--2/1| 4 |2/3==2/1| 3 |2/3--2/1| 6 |2/3--2/1| 2 |2/3-
| +---+ +---+ +---+ +---+ +---+ +---+ |
| |
|----------------------------------------------------------------------------|
Standby u2 - protocols ready, can failover
Revision 0419 10 ‐ 58
Replacing a Stack Unit ‐ Automatically
• Replacing a stack unit automatically with a clean unit
1. Enter the show stack command on the active controller, and check for an "S" beside the unit to

confirm that the configuration for the unit you are replacing is static1
2. Remove the old unit from the stack
• Although the unit is absent, the provisional configuration for the unit is still retained on the active controller
3. Make sure that the hardware (module) configuration of the replacement unit is identical to the
hardware configuration of the unit you removed
4. Connect the new unit to the stack using the same stacking ports as the old unit
• If the replacement unit configuration matches the configuration retained on the active controller, the active
controller resets the new unit
• The new unit becomes a member and joins the stack, and the stack keeps its original topology
Footnote 1: If the configuration is not static, enter the write memory command to
change all dynamic configurations to static. A static configuration remains after the
unit is removed.
Replacing a stack unit automatically with a clean unit:
1. Enter the show stack command on the active controller, and check for an "S" beside
the unit to confirm that the configuration for the unit you are replacing is static.
2. Remove the old unit from the stack. Although the unit is absent, the provisional
configuration for the unit is still retained on the active controller.
3. Make sure that the hardware (module) configuration of the replacement unit is
identical to the hardware configuration of the unit you removed.
4. Connect the new unit to the stack using the same stacking ports as the old unit. If
the replacement unit configuration matches the configuration retained on the active
controller, the active controller resets the new unit. The new unit becomes a
member and joins the stack, and the stack keeps its original topology.
Revision 0419 10 ‐ 59
Replacing a Stack Unit Using Interactive‐setup
• The replacement can be added using Interactive‐setup
1. Enter the show stack command on the active controller, and check for an "S" beside the unit to
confirm that the configuration for the unit you are replacing is static1
2. Remove the old stack unit from the stack
3. Connect the new unit to the existing stack using the same stacking ports as the old unit
4. Enter the stack interactive-setup command

• Select interactive‐setup option 2 if the replacement unit is a clean unit
• Select interactive‐setup option 3 if the replacement unit contains configuration
5. Stack interactive‐setup suggests an ID based on matching the new unit with the static configurations
• You can overwrite the suggested ID by entering the ID of the old unit
6. The active controller resets the unit, and it joins the stack
Footnote 1: If the configuration is not static, enter the write memory command to
change all dynamic configurations to static. A static configuration remains after the
unit is removed.
To replace a stack unit with stack interactive‐setup, perform the following steps:
1. Enter the show stack command on the active controller, and check for an "S" beside
the unit to confirm that the configuration for the unit you are replacing is static.
2. If the configuration is not static, enter the write memory command to change all
dynamic configurations to static. A static configuration remains after the unit is
removed.
3. Remove the old stack unit from the stack.
4. Connect the new unit to the existing stack using the same stacking ports as the old
unit.
5. Enter the stack interactive‐setup command. Select interactive‐setup option 2 if the
replacement unit is a clean unit. Select interactive‐setup option 3 if the replacement
unit contains configuration. Stack interactive‐setup suggests an ID based on
matching the new unit with the static configurations. You can overwrite the
suggested ID by entering the ID of the old unit.
6. The active controller resets the unit, and it joins the stack.
Revision 0419 10 ‐ 60
Summary
– Describe stacking technology and its benefits
– Describe stacking features including long‐distance stacking and hitless stacking
– Explain how to configure stacking using the interactive‐setup utility
– Display stack information once the stack is formed
– Explain how to replace and add new units to a stack
This concludes the Stacking module. You should now be able to:
• Describe stacking technology and its benefits
• Describe stacking features including long‐distance stacking and hitless stacking
• Explain how to configure stacking using the interactive‐setup utility
• Display stack information once the stack is formed
• Explain how to replace and add new units to a stack
Revision 0419 10 ‐ 61
End of Module 10:
ICX Stacking Technology
Revision 0419
This concludes the ICX Stacking Technology module.
Revision 0419 10 ‐ 62
ICX 150 Power Over Ethernet
Module 11:
Power over Ethernet
Revision 0419

and is based on the FastIron 8.0.90 software release. Subjects discussed in this course
concentrate on the Implementor functions within a network environment however does
not represent all functions or capabilities of an ICX switch. This module discusses Power
over Ethernet (PoE), and how to configure PoE on the different Ruckus ICX devices.
Objectives
• After completing this module, attendees will be able to:
– Describe the function of Power over Ethernet (PoE)
– Understand the capabilities of each Ruckus ICX family
– Configure PoE on Ruckus campus switches
– Change the various features offered on an ICX PoE interface
– Display PoE information
Describe the function of Power over Ethernet (PoE)
Understand the capabilities of each Ruckus ICX family
Configure PoE on Ruckus campus switches
Change the various features offered on an ICX PoE interface
Display PoE information
PoE Overview
• Power over Ethernet (PoE) is the method for transferring electrical power, as well as data,
to remote devices such as VoIP phones or video cameras
• Ruckus ICX switches have embedded PoE technology, and are considered power‐sourcing
equipment (PSE)
• A PSE is the source of power, or the device that integrates the power onto the network
• A powered device (PD), is an Ethernet device that requires power and is situated on the
end of the cable opposite the PSE
PD
VoIP Phone
Ruckus PSE
ICX 7250‐48P
PD
Security Camera
Power over Ethernet is a method whereby power is transmitted to Ethernet‐connected
equipment from a central switch.
By using the existing CAT 5 (or better) cabling, the need for AC power (and wiring costs) can
be eliminated. The switch is also able to control power distribution to the powered devices
allowing sophisticated uninterruptible power management for vital systems.
Ruckus ICX switches offer PoE technology and are what we call power‐sourcing equipment,
or PSEs. The devices being powered by the switch are called powered devices, or PDs. PDs
include devices like VoIP telephones or security cameras.
PoE Specifications
• Ruckus PoE devices are compliant with both the 802.3af and 802.3at standards
– 802.3af (PoE) ‐ provides 15.4 watts (44 to 50 volts) from the power‐sourcing device
– 802.3at 2008 (PoE+) ‐ provides 30 watts (52 to 55 volts) from the power‐sourcing device
– 802.3at 2009 (High PoE) ‐ provides 60 watts for High PoE and 95 watts for Power over HDBase‐T (PoH)
• Ruckus devices that support PoH allocate 95 watts for PoE+, High PoE, and PoH PDs
• Ruckus PoE devices support autodiscovery, to detect if a PD is 802.3af‐ or 802.3at‐
compatible
Ruckus PoE devices are compliant with both the 802.3af and 802.3at specifications. The
802.3af specification defined the original standard for delivering power over the existing
network cabling infrastructure, providing up to 15.4 watts (44 to 50 volts) of power to
powered devices.
The 802.3at specification expanded the standard to support higher power levels for
more demanding powered devices. 802.3at provides 30 watts (52 to 55 volts) to the
powered devices.
In 2009, the 802.3at standard was expanded to support even greater power levels,
which provides 60 watts for High PoE devices, and 95 watts for Power over HDBase‐
T (or PoH).
Except where noted, we use will be using the term PoE to refer to PoE, PoE+, and
High PoE.
PoE autodiscovery is a detection mechanism that identifies whether or not an installed
device is 802.3af‐ or 802.3at‐compatible. When you plug a device into an interface that is
capable of providing inline power, the autodiscovery mechanism detects whether or not
the device requires power and how much power is needed.
Ruckus ICX PoE Switches
• ICX 7150 Series
– 7150‐12P PoE/PoE+ 12 ports
– 7150‐24P PoE/PoE+ 24 ports
– 7150‐48P/PF PoE/PoE+ 48 ports
– 7150‐48ZP PoE/PoE+ 32 ports
• 16 PoH / PoE / PoE+ 802.3bt ready ports1
PoE capable ports are in orange

PoH capable ports are in yellow
• ICX 7250‐24P and ICX 7250‐48P
– PoE/PoE+ support on 24‐port
and 48‐port models
The Ruckus ICX series of switches offers several different PoE configurations. PoE models
are designated by the “P” at the end of the switch name.
The 7150‐12P provides fanless 12‐port options with PoE support on the copper interfaces
with a 124 W PoE Budget.
The 7150P has 24‐port and 48‐port options with PoE support on the copper interfaces with
a 370 W PoE Budget.
The 7150PF has 48‐port options with PoE support on the copper interfaces with a 740 W
PoE Budget.
The 7150PF has 32‐ports with PoE support with on the copper interfaces with 16 of them
providing PoH 820.3bt support. Provides a 1480 W (2 PSU) PoE Budget.
Class 4 PoE+ power (30 watts) to every port and PoH power (90 watts) on eight dedicated
ports.
All ICX switches providing 802.3bt ports (90 W per port) are compatible with
PoE/PoE+/Cisco uPoE
The 7250 has 24‐port and 48‐port options with PoE support on the copper interfaces with
370W and 740W budget respectively.
Footnote 1: Up to 90W per port, IEEE 802.3bt standard finalized in September 2018.
Compatible with uPoE
Ruckus ICX PoE Switches
• ICX 7450‐24P, ICX 7450‐48P
– PoE/PoE+ support on 24‐port
and 48‐port models
– 8 PoH ports highlighted in yellow
• ICX 7650‐48P, ICX 7650‐48ZP
– Both provide 48x PoE/PoE+ ports
– 7650‐48P 8x PoH/802.3bt ready ports
– 7650‐48ZP 24x PoH/802.3bt ready ports
PoH Capable
The 7450 also has 24‐port and 48‐port options with PoE support on the copper interfaces,
and it offers PoH support on the 8 ports highlighted in yellow on the switch. Both provide
1500W AC / 516W DC PoE budget when using two power supplies.
Finally, we have the ICX 7650‐48P and ICX 7650‐48ZP provide 48 PoE+ ports but also
designates ports for PoH support. The 7650‐48P provides 8 PoE/+/PoH ports and the 7650‐
48ZP provides 24 PoE/+/PoH ports. Both providing1500 W PoE Power budget when using
two power supplies.
As you can see, the ICX 7750 is not included in the PoE product portfolio, this is
because the 7750 is Ruckus’s Campus Fabric core/aggregation device where PoE is
not required. However, with the introduction of IEEE standard 802.1br, for Switch
Port Extender, or what Ruckus calls Campus Fabric, you can configure and monitor
PoE functionality from the core ICX 7750 in a distributed stack. This feature is
supported on ICX 7750 control bridge devices and ICX 7450 port extender devices.
PoE can now be managed and monitored from a single point for all connected port
extenders with the PoE driver running on an ICX 7450 and the configuration and
monitoring run from an ICX 7750 device.
Please refer to the Campus Fabric module on the Ruckus website for more information.
PoE Delivery Methods 162_PWWNs.png
162_twisted‐pairs2.png
• There are two methods for delivering PoE as defined in the 802.3af and 802.3at
specifications
– Endspan ‐ used by Ruckus PoE devices, delivers power through the Ethernet ports on a power‐sourcing
device
• Power and data signals travel along the same pairs of wires at different frequencies
Switch with Power over Ethernet ports IP Phone
Switch
– Midspan ‐ power is supplied by an
intermediate power‐sourcing device
Intermediate Device
placed between the switch and the PD
IP Phone
There are two methods for delivering PoE as defined in the 802.3af and 802.3at
specifications. The first is Endspan. Endspan is the Ruckus solution as the Ruckus PoE
device delivers power through the Ethernet ports to the PDs. Here, power and data signals
travel along the same pairs of wires at different frequencies
In the Midspan method, power is supplied by an intermediate power‐sourcing device
placed between the switch and the PD. Here, power travels on the unused spare pairs of
wires, while data travels on the other wire pairs.
ICX switches support PoE on 10, 100, and 1000 Mbps along with multi‐gigabit ports, each
with PoH up to 90 watt capabilities
PoE Types
Type 2 Type 3
Commonly known as: PoE+, PoE Plus Commonly known as: 4‐pair PoE, 4P
Type 1 Standard: IEEE 802.3at PoE, PoE++, UPOE Type 4
Commonly known as: PoE Maximum power provided: 30W Standard: IEEE 802.3bt Commonly known as: higher‐power
Standard: IEEE 802.3af Maximum power provided: 60W PoE, POH
Maximum power provided: 15.4W Standard: IEEE 802.3bt
Maximum power provided: 100W
• Class 5 and higher utilizes 4 twisted pairs to provide power
• Backwards compatibility to existing PDs are supported with Type 3 / Type 4 PSEs
– Traditional 2 pair
– 4 pairs allowing cable power losses being reduced
The third revision of the IEEE standard of power transfer of low voltage over Ethernet is
known as 802.3bt. As mentioned earlier the previous PoE Standards known as 802.3af
(2003) introduced 13W to network devices. 802.3at introduced in 2009 increased the
power up to 25.5W delivery. The new 802.3bt standard increases the power significantly by
providing devices up to 71.3W by utilizing 4‐pairs of the Ethernet connection.
The newly introduced Type 3 / Type 4 PSEs still provide backwards compatibly to PDs
however they may utilize 4 pairs to deliver the lower power to PDs, lower cable losses to
half the normal loss.
PoE Type 1 uses two pairs for power delivery to many lower‐powered devices. Common
type 1 devices include VoIP phones, sensors, minimal antenna APs and simple IP cameras.
PoE Type 2 provide devices additional power that can be handled by the Type 1 standard.
Type 2 is backwards compatible but provides needed power to devices including
multifunction IP cameras capable of Pan, Tilt, and Zoom (PTZ) features, higher antenna APs
and minimal LCD displays.
PoE Type 3 uses all four twisted pairs in the Ethernet cable supplying the needed power of
current PoE devices including videoconferencing appliances, remote switches, APs
requiring high power and automated entry management devices.
PoE Type 4 supplies up to 100W of power for devices which has the ability to power
laptops along with large displays including TVs as well as cameras that deploy fans or
heaters.
Power Classes for Powered Devices
• PoE autodiscovery is a detection mechanism that identifies whether an installed device is
802.3af‐ or 802.3at‐compatible
– A power class identifies the maximum power consumption of a PD will receive from the PSE
– PSEs perform power classification by inducing a specific voltage to the PD and measuring the current
consumption
• Power classes include any power loss through the cables
• PDs that do not support classification are assigned class 0 (UnknownClass)
Power (watts) from Power-Sourcing Equipment

Class Usage
PoE PoE+ PoH
0 Default 15.4 15.4 15.4
1 Optional 4 4 4
2 Optional 7 7 7
3 Optional 15.4 15.4 15.4
4 Optional 15.4 30 60/ Overdrive 95
Adding to the four existing classes (1‐4) four new are introduced providing 8
different classes. Ruckus PoE switches however still allocate power using a 4 class
system identified in the table. Specific class allocations can be configured on ICX
interfaces allowing for greater control of PoE budget and power consumption. The
power class listed includes any power loss through the cables. The following table shows
the different power classes and their respective power consumption needs.
For example, a PoE port with a power class of 3, or 15.4 watts, receives a maximum of
12.95 watts of power after 2.45 watts of power is lost through the cable. This is compliant
with the IEEE 802.3af and 802.3at specifications for delivering inline power.
Devices that are configured to receive less PoE power, for example, a class 1 device, which
receives 4.0 watts of power, will experience a lower rate of power loss through the cable.
External Power Supplies
• Optional external power supplies (EPS) are available for ICX 7250 devices to provide the
increased PoE power requirements
• ICX‐EPS4000 provides additional power for
up to 16 ICX 7250 switches
Ruckus offers external power supplies (or EPS) for the ICX family of
switches. External power supplies can be used for system power redundancy and
increased PoE/PoE+ power budget.
The ICX-EPS4000 can provide power for up to 16 ICX 7250 switches. All 7250
24‐port and 48‐port devices are supported on the EPS4000, except for the ICX 7250‐24G
(non‐PoE device).
Revision 0419 11 ‐ 10
PoE Firmware Files And Features (FI 08.0.70)
• PoE devices require specific PoE firmware
– Beginning with FastIron 08.0.70 release, a unified PoE firmware is used across the supported devices
– During PoE firmware installation power to the connected PDs is disabled until update is complete
Product PoE Firmware File

ICX 7150, ICX 7250, ICX 7450, ICX 7650 icx7xxx_poe_02.1.0.b002.fw
Feature ICX 7150 ICX 7250 ICX 7450 ICX 7650 ICX 77501 ICX 7850

Auto PoE firmware upgrade 8.0.70 8.0.70 8.0.70 8.0.70 8.0.70 No
PoE enabled by default 8.0.70 8.0.70 8.0.70 8.0.70 8.0.70 No
Power over HDBaseT (PoH) 8.0.612 No 8.0.20 8.0.70 No No
uPoE 8.0.612 No 8.0.20 8.0.70 No No
PoE+ (802.3at) 8.0.60 8.0.30 8.0.20 8.0.70 No No
PoE (802.3af) 8.0.60 8.0.30 8.0.20 8.0.70 No No
Detection of PoE power requirements advertised through CDP 8.0.60 8.0.30 8.0.20 8.0.70 No No
Maximum power level for a PoE power‐consuming device for
8.0.60 8.0.30 8.0.20 8.0.70 No No
LLDP‐MED or CDP
Power class for PoE power‐consuming device 8.0.60 8.0.30 8.0.20 8.0.70 No No
Power limit per port 8.0.60 8.0.30 8.0.20 8.0.70 No No
PoE compatibility and features are unique to each switch depending on the software
release it is running. Traditional updates to software can require an additional PoE firmware
to be updated depending on the release however with the new ICX Unified FastIron Image
the individual PoE firmware is no longer required but rather included in the UFI file. If you
are updating software of an ICX switch other than FastIron 8.0.90 please check the release
notes to see if a PoE firmware update is required.
Footnote 1: In 08.0.50, when the ICX 7750 is a control bridge (CB) in a campus fabric
configuration, it supports PoE to the control plane
Footnote 2: Supported on the ICX 7150 Z Series only
Revision 0419 11 ‐ 11
Unified FastIron Image (UFI) Firmware and PoE
• New image format introduced in FI Release 8.0.80 known as Unified FastIron Image (UFI)
– Combines both the FastIron application image and boot code
– POE Firmware is bundled as part of the application image
• No longer its own image and does not need to up upgraded independently
– UFI bundle contains below components/packages
1. Application image
2. Application image’s signature file
3. U‐boot
4. Python libraries
5. HTTP package
6. DHCP package
7. <Any other package in future>
As mentioned the UFI file now includes all necessary files including the PoE application
image allowing for assurance that the UFI software you are using has the correct PoE
firmware allowing you to take advantage of all the PoE capabilities of the ICX switch.
Revision 0419 11 ‐ 12
PoE Configuration
Now let’s take a look at the configuration of PoE.
Revision 0419 11 ‐ 13
Enabling/Disabling PoE
• All PoE capable ports are enabled by default introduced in FI 08.0.70 Release
• To enable/disable a port to provide inline power at the interface configuration:

Ruckus(config-if-e1000-1/1/1)# inline power

Ruckus(config-if-e1000-1/1/1)# no inline power
• It is best practice to disable inline power on ports where it is not required
– Limiting power on PoH capable ports is recommended if PoH devices are not deployed on the port
PoE is enabled by default but can be disabled using the inline power command.

It is a best practice to only provide PoE features on interfaces where it is required.
Depending on the number of PoE‐configured interfaces that have powered devices
connected, CPU utilization will increase slightly, though typically PoE does not affect the
functionality of other features on the switch.
To disable PoE the Syntax on a port level is: [no] inline power
Disabling PoE capabilities on non PoE required ports is
recommended along with limiting power on PoH ports to
assure your PoE budget is predictable. More details on
disabling the PoH capabilities will be discussed later in
this module.
Revision 0419 11 ‐ 14
Power Levels for PoE Interfaces
• By default, ICX PoE devices pre‐allocate 15.4W for PoE ports, 30W for PoE+ ports, and 95W
for PoH ports
• The maximum amount of power that the switch will supply at each port can be manually
configured
– Power class
– Maximum power level
• Cannot configure both on the same interface
• Setting the power level on a port does not take power loss during transmission into
consideration
When PoE is enabled on a port to which a power consuming device or PD is attached, by
default, a Ruckus PoE device will supply 15.4 watts of power at the RJ‐45 port, minus any
power loss through the cables.
A PoE+ device will supply either 15.4 or 30 watts of power (depending on the type of PD
connected to the port), minus any power loss through the cables.
If desired, you can manually configure the maximum amount of power that the Ruckus PoE
device will supply at the RJ‐45 port.
Revision 0419 11 ‐ 15
Configuring Power Classes
• To set the power class for a port, use the power‐by‐class command at the interface level

Ruckus(config-if-e1000-1/1/1)# inline power power-by-class 3
Power (watts) from Power-Sourcing Device

Class Usage
Standard PoE PoE+ PoH
0 Default 15.4 15.4 15.4
1 Optional 4 4 4
2 Optional 7 7 7
3 Optional 15.4 15.4 15.4
4 Optional 15.4 30 60/ Overdrive 951
As we mentioned previously, the PoE switch will pre‐allocate 15.4 watts of power to a PoE
port, 30 watts of power to a PoE+ port, and 95 watts of power to a PoH port. However, you
can use the power-by-class command to set the desired power class per interface,
thus configuring the amount of power sent to the attached PD.
Footnote1: For PoH ports, the range is 1000‐95000mW. By default maximum
range is 60000mW and in PoE overdrive mode up to 95000mW is supported. Will
discuss the overdrive feature later in this module.
Revision 0419 11 ‐ 16
Power Levels for PoE Interfaces (cont.)
• The Ruckus PoE device will adjust the power on a port only if there are available power
resources
• If power resources are not available, the following message displays on the console and in
the Syslog:
PoE: Failed power allocation of 30000 mwatts on port 1/1/21. Will retry
when more power budget.
There are two ways to configure the power level for a PoE power consuming device,
configuring a power class, or configuring a maximum power level. Both of these cannot be
configured on the same port.
The Ruckus PoE device will adjust the power on a port only if there are available power
resources. If power resources are not available, a message displays on the console and in
the Syslog that POE failed the power allocation for a specific port. It also states that it will
try to allocate power again when more power budget is available.
Revision 0419 11 ‐ 17
Configuring Maximum Power Level
• Configure the maximum power level for a PoE port:
Ruckus# configure terminal
Ruckus(config-if-e1000-1/1/1)# inline power power-limit 14000
– The example configures inline power on interface 1/1/1, and sets the maximum power level to 14,000
milliwatts (14 watts)
• Maximum power level values:
– PoE ‐ 1000 through 15,400, the default is 15,400
– PoE+ ‐ 1000 through 30,000, the default is 30,000
– PoH ‐ 1000 through 95,000, the default is 95,000
• Value is adjusted to nearest multiple of 5
• Configuring a power level higher than the default, could damage the PD
The second way to configure the power level, is to set a maximum power level using the
inline power power-limit <power level> command. The <power
level> variable is the maximum power level in number of milliwatts. The following
values are supported:
• PoE – Enter a value from 1000 through 15,400. The default is 15,400.
• PoE+ – Enter a value from 1000 through 30,000. The default is 30,000.
The example enables inline power on interface 1/1/1, and sets the PoE power level to
14,000 milliwatts (14 watts).
Note! Setting a power level higher than what the attached PD can support could damage
the device.
Revision 0419 11 ‐ 18
Enabling Cisco Discovery Protocol (CDP)
• Some power consuming devices use Cisco Discovery Protocol (CDP) to advertise power
requirements
– Ruckus switches are compatible with other vendors’ power consuming devices
– They can detect and process power requirements for these devices automatically
– CDP packet interception is disabled by default on all interfaces
• Configure the Ruckus device to use CDP:
Ruckus# configure terminal
Ruckus(config)# cdp run
– If CDP packet interception is to be disabled for an individual interface, the configuration is applied in
interface configuration mode
Many power‐consuming devices, such as Cisco VoIP phones and other vendors' devices,
use the Cisco Discovery Protocol (CDP) to advertise their power requirements to power‐
sourcing devices like Ruckus PoE devices.
Ruckus power‐sourcing equipment is compatible with Cisco and other vendor's power
consuming devices, and can detect and process power requirements for these devices
automatically.
If you configure a port with a maximum power level or a power class for a power
consuming device, the power level or power class will take precedence over the CDP power
requirement. Therefore, if you want the device to adhere to the CDP power requirement,
do not configure a power level or power class on the port.
Configure the cdp run command globally to enable CDP.
Revision 0419 11 ‐ 19
PoE Overdrive
• Not part of the IEEE standard (Ruckus proprietary enhancement)
• Allows the Class 0 and Class 4 PD to negotiate for power greater than 30‐watt allocation
– PoE overdrive is a per port configuration and can be configured on a range of ports
– PoE overdrive on PoE+ ports is available only for Ruckus PD
Ruckus AP (PDs) Ruckus ICX (PSEs)
R720 ICX 7150
R730 ICX 74501
ICX 7650
• PoE overdrive is disabled by default
– PoE+ ports that support overdrive through LLDP‐MED messages, (automatically enabled)
– To avoid power cycle caused by auto enablement manually overdrive mode

Ruckus(config-mif-1/1/1-1/1/5)# inline power overdrive
Overdrive feature allows the Class 0 and Class 4 PD to negotiate for power greater than 30‐
watt allocation. The maximum power that can be processed based on LLDP‐MED
negotiation is limited to the hardware capability of the PSE. If the PD negotiates for power
more than the hardware limit, the PSE allocates only up to the hardware capability of the
PSE.
PoE overdrive is disabled by default. When Ruckus PDs negotiate for power greater than
30‐watt allocation on PoE+ ports that support overdrive through LLDP‐MED messages, PoE
overdrive gets automatically enabled and will be displayed in the configuration. When the
port mode dynamically changes to overdrive mode, the power is cycled (off and on) on the
port. To avoid PD reload, manually apply the inline power overdrive configuration
on the port before connecting the PD. PoE overdrive is a per port configuration and can be
configured on a range of ports. Do note that when the PD that requires overdrive is
disconnected, the port mode changes back to non‐overdrive mode. If the port mode
dynamically changes to overdrive mode, the inline power overdrive configuration is not
displayed in the running configuration.
When the PD that requires overdrive is disconnected, the port mode changes back to non‐
overdrive mode. If the port mode dynamically changes to overdrive mode, the inline power
overdrive configuration is not displayed in the running configuration.
Footnote 1: ICX 7450 only support overdrive on its PoH ports.
Revision 0419 11 ‐ 20
PoE Overdrive (cont.)
• Overdrive can be configured on PoE and PoH capable ports
– Power allocation is as follows based on the switch
Overdrive ‐ Max
Overdrive ‐ Max Power
ICX Platforms PoH Ports PoE+ Ports Power
Capability
Capability
ICX 7450 (all PoE SKUs) 1 to 8 95W 9 to 48 NA
45W1
ICX 7650‐48P 1 to 8 9 to 48
ICX 7150‐48ZP 1 to 16 17 to 48

ICX 7650‐48ZP 25 to 48 1 to 24
ICX 7150‐24P, ICX 7150‐
48P, ICX 7150‐C12P, ICX None All PoE ports NA
7250‐24P, ICX 7250‐48P
By default, the initial power allocation is 60W on PoH port and 30W on PoE+ port.
With PoE overdrive configuration, the initial power allocation is 95W on PoH ports
and 30W on PoE+ ports. When the PD that requires overdrive is disconnected, the
port mode changes back to non‐overdrive mode. If the port mode dynamically
changes to overdrive mode, the inline power overdrive configuration is not
displayed in the running configuration.
Footnote1: Only Ruckus PDs can go up to 45W.
Revision 0419 11 ‐ 21
PoE Power Priority Configuration
• Power priority can be configured in the event that power is not available to provide power
to all PoE enabled ports:
– Priorities are set per port
– Higher priority ports are allocated power first
– Priority values:
• 3 ‐ Low priority
• 2 ‐ High priority
• 1 ‐ Critical priority
• To configure the power priority for a PoE port:
Ruckus(config-if-e1000-1/1/1)# inline power priority 2
– The example enables inline power on interface 1/1/1 and sets the inline power priority to high (2)
In a configuration where PoE power consuming devices collectively have a greater demand
for power than the PoE power supply or supplies can provide, the ICX PoE switch must
place the PoE ports that it cannot power in standby or denied mode (waiting for power)
until the available power increases. The available power increases when one or more PoE
ports are powered down, or, if applicable, when an additional PoE power supply is installed
in the switch.
When PoE ports are in standby or denied mode and the switch receives additional power
resources, by default, the device will allocate newly available power to the standby ports in
priority order, with the highest priority ports first, followed by the next highest priority
ports, and so on.
Within a given priority, standby ports are considered in ascending order, by slot number
then by port number, provided enough power is available for the ports.
For example, PoE port 1/1/1 should receive power before PoE port 1/2/1. However, if PoE
port 1/1/1 needs 12 watts of power and PoE port 1/2/1 needs 10 watts of power, and 11
watts of power become available on the device, the device will allocate the power to port
1/2/1 because it does not have sufficient power for port 1/1/1.
Use the inline power priority command to set a priority for a port. The
priority values are 1 to 3, with 1 being the highest or most critical.
Revision 0419 11 ‐ 22
Enabling PoE on LAG Ports
• ICX switches support PoE on LAG ports
– Apply inline power to a member port with a specific power class
Ruckus(config)# inline power ethernet 1/1/1 power-by-class 3
– Configure another member port with default config
Ruckus(config)# inline power ethernet 1/1/2
– Configure another member port with a power priority
Ruckus(config)# inline power ethernet 1/1/3 priority 2
– Configure another member port, specifying a maximum power level
Ruckus(config)# inline power ethernet 1/1/4 power-limit 12000
– Configure overdrive support on a member port
Ruckus(config)# inline power ethernet 1/1/1 overdrive
PoE is available on LAG ports using the inline power ethernet command, this

command is done in global CONIFIG mode.
Once a LAG is created and deployed, you can enable inline power on each secondary port
in the LAG. Each port can be configured with different power settings.
The example here, configures inline power on first port 1/1/1, with a power class of 3.
Next, the secondary ports are configured. Notice that each port is configured differently.
The first option, configures secondary port 1/1/2 with the default inline power settings, as
no other power parameters are set.
The second option, configures secondary port 1/1/3 with a power priority of 2.
And the third option, configures secondary port 1/1/4 with a maximum power level of
12000 mWatts.
Revision 0419 11 ‐ 23
Support for PoE Legacy Devices
• Legacy devices are not compliant with 802.3af or 802.3at
• On a non‐stackable device, configure at the global level:
Ruckus(config)# no legacy-inline-power
• On a stackable device, configure at the stack unit level:
Ruckus(config-unit-2)# no legacy-inline-power
Ruckus PoE devices automatically support most legacy PDs that are not compliant with
802.3af and 802.3at. If desired, you can disable or re‐enable support for legacy PoE power
consuming devices on a global basis. When you disable legacy support, 802.3af and 802.3at
compliant devices are not affected.
The no legacy-inline-power command does not require a software reload if it is
entered prior to connecting the PDs. If the command is entered after the PDs are
connected, the configuration must be saved (write memory) and a software reloaded is
needed for the change to take effect.
To re‐enable support for legacy power consuming device after it has been disabled, enter
the legacy-inline-power command.
View the running configuration to see if support for PoE legacy devices is enabled or
disabled.
Revision 0419 11 ‐ 24
Displaying PoE Information
• Use the show inline power command to view PoE operational information
Total PoE power supply
capacity, and available power
Ruckus# show inline power
Power Capacity: Total is 720000 mWatts. Current Free is 384000 mWatts.
Power Allocations: Requests Honored 146 times
Port Admin Oper ---Power(mWatts)--- PD Type PD Class Pri Fault/
State State Consumed Allocated Error
--------------------------------------------------------------------------
1/1/1 On On 6385 7000 802.3af Class 2 3 n/a
1/1/2 On On 6479 7000 802.3af Class 2 3 n/a
1/1/3 On On 6479 7000 802.3af Class 2 3 n/a
1/1/4 On On 6573 7000 802.3af Class 2 3 n/a
1/1/5 On On 6479 7000 802.3af Class 2 3 n/a
<Truncated Output> Milliwatts allocated to the
port, and current Type of PD connected,
--------------------------------------------------------------------------
milliwatts the PD is and maximum amount of
Total Is PoE enabled (on) or 306950consuming 33600 power the PD can receive
disabled (off) on the port
Use the show inline power command to view PoE operational information.

The output shows a lot of useful information including:
• The total PoE power supply capacity and available power
• The status of each PoE port, and if it is configured for PoE.
• The Power (in milliwatts), being allocated to the port, and how many
milliwatts the PD is consuming.
• And finally, the type of PD connected, is it a 802.3af or 802.3at device,
and what power class does the PD support.
Revision 0419 11 ‐ 25
Displaying PoE Power Supply Details
• Use the show inline power detail command to view detailed information for the

PoE power supplies
Ruckus# show inline power detail
Power Supply Data On stack 1: PoE power supply
++++++++++++++++++ details, including PoE
Power Supply #1: firmware version
Max Curr: 7.5 Amps
Voltage: 54.0 Volts
Capacity: 410 Watts
POE Details Info. On Stack 1 :
General PoE Data:
+++++++++++++++++ Admin-On – ports enabled for inline power
Firmware Version Admin-Off – ports not enabled for line power
-------- Oper-Off – ports not receiving inline power
02.1.0 Off-No-PD – ports where no PDs are connected
Cumulative Port State Data:
+++++++++++++++++++++++++++
#Ports #Ports #Ports #Ports #Ports #Ports #Ports
Admin-On Admin-Off Oper-On Oper-Off Off-Denied Off-No-PD Off-Fault
24 0 0 24 0 0 0
Cumulative Port Power Data: Number of ports per
+++++++++++++++++++++++++++
PoE priority, and total
#Ports #Ports #Ports Power Power
Pri: 1 Pri: 2 Pri: 3 Consumption Allocation number of watts
----------------------------------------------- consumed by PDs
0 0 24 679.371 W 720.0 W
Using the detail parameter with the show inline power command displays even

more PoE information, including details about the PoE power supplies, as well as the
current PoE firmware running on the switch.
The output also shows the number of ports enabled for inline power, and the power
consumption and allocation of the total number of ports.
Revision 0419 11 ‐ 26
Summary
– Describe the function of Power over Ethernet (PoE)
– Understand the capabilities of each Ruckus ICX family
– Configure PoE on Ruckus campus switches
– Change the various features offered on an ICX PoE interface
– Display PoE information
This concludes the module on Power over Ethernet. You should now be able to
Describe the function of Power over Ethernet (PoE)
Understand the capabilities of each Ruckus ICX family
Configure PoE on Ruckus campus switches
Change the various features offered on an ICX PoE interface
Display PoE information
Revision 0419 11 ‐ 27
End of Module 11:
Power over Ethernet
This completes the Ruckus Power over Ethernet module. I encourage you to continue to
Revision 0419 11 ‐ 28
ICX 150 ICX Campus Fabric
Module 12:
ICX Campus Fabric
Revision 0419
This module will cover the ICX Campus Fabric.
Objectives
– Describe the ICX Campus Fabric
– Explain the components of the Campus Fabric
– Configure Camps Fabric Control Bridge (CB)
– Configure SPX Port Extenders (PE) using Interactive‐Setup and Zero‐Touch deployment
– Use show commands to view the configuration of the SPX environment
After completing this module, you should be able to:
• Describe the ICX Campus Fabric
• Explain the components of the Campus Fabric
• Configure Camps Fabric Control Bridge (CB)
• Configure SPX Port Extenders (PE) using Interactive‐Setup and Zero‐Touch
deployment
• Use show commands to view the configuration of the SPX environment
Overview
• Switch Port Extender Control Bridge (CB)
ICX 7650 & ICX 7750
IEEE 802.1BR
– Extends a bridge, and the management of
its objects, beyond its physical enclosure
using 802 LAN technologies
– Simplifying management by collapsing and
unifying core, aggregation, and access
functions
– Managing Control Bridge (CB) and Port
Extenders (PEs), in one domain with single
point of management Port Extender (PE)
ICX 7150, ICX 7250 & ICX 7450
Switch Port Extender (SPX) technology is covered in IEEE standard 802.1BR. This technology
extends a bridge, and the management of its objects, beyond its physical enclosure using
802 LAN technologies.
This technology collapses and unifies the core, aggregation, and access functions. SPX
creates a single point of management for all devices in the environment we see here in the
diagram.
The Control Bridge (CB) on the top contains the ICX 7650 or 7750 devices which form a
distributed stack, and the ICX 7150, 7250 and 7450 Port Extender (PE) devices on the
bottom connecting to the CB. The master ICX in the Control Bridge becomes the this single
point of management for the entire topology.
Key Components
Component Definition
Control Bridge The CB has ports that link to one or more Port
(CB) Extenders (PEs)
Port Extender (PE) A dummy device that contains multiple ports.
Forwards all traffic to a CB, they do not perform
switching
Access PE (Base A PE connecting to end hosts. Located at the end

PE) of the CB‐PE chain
SPX port PE port that links to CB or other PE
Cascade port Egress CB port connecting to a PE
Extended port PE port that serves as an access port to a host
Control & Status The SPX communication protocol between the
Protocol (CSP) CB master and the PEs
Let's take a look at the key components of the SPX environment.
The CB consists of a traditional stack of ICX 7750 units, and is managed by the active
controller in the stack.
The CB has the ports that link to one or more Port Extenders (PEs), PEs are managed as
virtual ports (or VPs) from the CBs perspective.
An Access PE has ports connecting to network hosts. The CB handles traffic to and from
PE ports as if these ports were local ports. A Port Extender (or PE) is a dummy device
that contains multiple ports like the ICX 7450 that has 24 or 48 port models. PEs forward
all traffic to the CB, they do not perform local switching. An access PE is located at the
end of the CB‐PE tree.
The SPX port is a PE port that links to the CB or another PE. SPX ports can be combined
into a Link Aggregation Group (LAG) as we see here. The PE on the left connects to the
CB with a 4 port Link Aggregation Group (LAG.)
A Cascade port is an egress CB port connecting to a PE. The link between the cascade
port and the PE port is configured and displayed as an SPX port or SPX LAG.
An extended port is a PE port that serves as an access port to a host. Internal extended
ports provide connectivity to the ports of the C‐VLAN component. External extended
ports operate as ports of the extended bridge. Each internal extended port is linked
through an E‐channel to an external extended port. Additional E‐channels provide
linkage between an internal extended port and multiple external extended ports in
support of multicast frame delivery.
Control and Status Protocol (or CSP) serves as the SPX communication protocol between
the CB master and the PE units in its control plane.
Key Components (cont.)
Component Definition
Upstream port A PE port that connects to a transit PE
toward the CB or directly to the CB.
PE mode A special boot‐up role that causes a unit to
perform as a dummy device
Provisional‐PE mode A temporary mode activated with spx pe‐
enable, but the unit has not been reloaded
E‐channel Bidirectional path between the external
extended port and corresponding internal
extended port
E‐Channel Identifier Identifies PE destination port in CSP. ME‐CID
(E‐CID) for multicast
E‐Tag Tag added to SPX packets that contains an E‐
CID
Continuing with the key components we have the upstream port. An upstream port is a PE
port that connects to a transit PE toward the CB or directly to the CB. An upstream port is
an "ingress" port from the perspective of the CB.
Next, we have PE mode. A unit operating in PE mode does not parse the startup
configuration flash during boot‐up. The unit does not perform local switching, it only runs
protocols available to a PE, such as LLDP. Most commands and configurations are blocked.
Provisional‐PE mode is a temporary mode created when a user manually configures the spx
pe‐enable command, but has not yet reloaded the unit. Because the unit previously booted
up in regular mode, it continues to perform as a regular device until the next reload. That
is, the unit still acts like a regular switch or router. Although, most commands or
configuration are blocked the same way as in PE mode.
An E‐channel is a bidirectional path between an external extended port and corresponding
internal extended port. E‐channels are identified by
E‐Channel ID (or E‐CID), IDs range from 0x1000 to 0x3FFF. E‐Channels can be point‐to‐point,
point‐to‐multipoint, or multipoint‐to‐point links. An ME‐CID is a multicast E‐channel
Identifier which carries a value of 0x1000 to 0x3FFF to indicate a specific multicast channel.
The E‐CID or ME‐CID are inserted into an E‐tag which is carried in SPX packets.
PE Standalone and PE Chain Topologies
Here we see two common campus fabric topologies. On the left, we have a Control Bridge
(CB) stack in a ring topology with members directly attached to Port Extender (PE) units.
The directly connected PE units supply extended port connectivity to end devices.
On the right, we have a very similar configuration with a Control Bridge stack ring, but in
this example the directly connected PEs function as transit PEs forming an SPX chain. Each
SPX chain is capable of supporting 6 Port Extender (PE) units.
CB‐PE LAG Topology
• A single SPX LAGs can be configured from a Port Extender to one or more Control Bridge
units
The topology shown here is a single SPX Link Aggregation Group (LAG) shared across
multiple CB members. One PE unit can be connected to more than one CB unit when the
connection is configured as a single LAG. If one of the connected units in the CB fails, the
PE unit still maintains a connection to the CB. In the following figure, PE 17 is connected to
more than one CB unit by a single LAG.
PE Ring Topology
• Connections between two PE chains or connecting end of chain back to CB creates a ring
Lastly we have the PE ring topology. A redundant SPX link can be connected from a CB unit
to the edge PE of an existing PE chain or between two edge PEs of two existing PE chains to
form a PE ring. You can combine ICX 7150, ICX 7250, and ICX 7450 devices in a PE ring just
as you can in a PE chain.
The topology shows a Control Bridge stack ring between CB1 and CB2. PE17 and PE19 have
SPX LAG trunks up to the CBs. PE18 and PE20 have SPX LAG trunks to PE17 and PE19,
respectively, forming two PE chains. To complete the ring, an SPX LAG trunk is connected
between the two PEs at the end of each chain to form a ring.
The same rules apply to a PE ring as PE chains, there can be no more than six PE units in a
ring.
Un‐supported Topology – Redundant PE Links
• A single PE unit cannot be used to form a ring
• If a single PE is connected to multiple CB devices, and not a single LAG, one of the SPX link
paths will be blocked
A complete list of supported and unsupported physical
configurations can be found in the FastIron Campus Fabric
Configuration Guide at www.ruckuswireless.com
Certain physical configurations are not supported in a campus fabric implementation. You
cannot connect a PE unit to a Control Bridge with multiple SPX links or trunks. Likewise, you
cannot connect a PE unit to another PE unit with multiple SPX links or trunks.
If you attempt to configure a redundant link between a CB unit and a PE unit or between
two PE units in a chain, the configuration is error‐disabled because the second link creates
a loop. Correct the problem by adding the second link to a single SPX LAG.
A complete list of supported and unsupported physical topologies can be found in the
FastIron Campus Fabric Configuration Guide on the Ruckus website.
CB & PE Control Plane Bring‐up
• Single CB and PE discovery
Control Bridge (CB)
1. Configure CB mode,
4. CB validates the define SPX LAG on CB
topology, assigns unit
ID and starts CSP 1/1/1 1/1/4
4x10G SPX LAG
17/2/1 17/2/4 2. Configure PE mode,

3. PE sends LLDP with define SPX LAG on PE
port extender (PE) TLV PE *ICX interactive-setup
utility automates
I these
steps C(2-4)
Host A Host B
1G host link (down)
• An interactive setup utility is available to automate steps 2‐4 in this process and is the
preferred method of adding PEs to an ICX Campus Fabric
Let’s take a look at the steps to configure SPX and the process it goes through to form the
Campus Fabric. The example is only showing a single switch CB attached to a single PE.
First, we configure the CB for SPX and define the port (or ports) to the PE, which in this case
is a 4‐port LAG.
Second, we have the option to configure the PE for SPX and define the LAG to the CB.
Third, the PE sends an LLDP packet to the CB with the Port Extender TLV.
Fourth, the CB validates the topology, assigns the unit IDs and starts CSP communication.
Steps 2 through 4 in this process have been automated using an interactive‐setup utility
available in release 8.0.90. The interactive‐setup utility is the preferred method of adding
PEs to an ICX Campus Fabric.
Revision 0419 12 ‐ 10
CB & PE Control Plane Bring‐up (cont.)
Single point of management
Control Bridge (CB)
8. PE port up/ready
5. CSP creates VP, and assigns
for applications E-CID for each PE port
1/1/1 1/1/4
4x10G SPX LAG
17/2/1 17/2/4
6. Programming forwarding
7. Once PE is ready, it entry for each PE port
PE 17
brings up data ports
I
17/1/1 17/1/2
(E-CID 1) (E-CID 2) C
Host A Host B
1G host link (up)
Continuing on.
Fifth, CSP creates a virtual port (VP) for each PE extended port and assigns it an E‐CID.
Sixth, each SPX port on the PE programs a forwarding entry.
Seventh, once the PE is up and ready, it brings up the data ports.
Finally, in step 8, the CB validates that the PE is up and ready for application traffic.
Now, we have a single point of management for the SPX environment.
Revision 0419 12 ‐ 11
Packet Walk‐through
CB and PE Data Path
1. Host A pings Host B
2. PE adds E‐CID 1 to the packet received
from Host A, and sends packet to CB over
SPX LAG
3. CB performs look‐up for MAC B,
destination 17/1/2. Adds E‐CID 2 and sends
to PE over SPX LAG
4. PE performs look‐up for E‐CID 2 forwarding
entry, finds destination port 17/1/2,
removes E‐CID and sends packet to Host B
Now, let’s take a look at a packet walk‐through in the SPX environment.
In this topology we have a four member control bridge stack ring. PE 17 is connected to
two of the CB units through a single SPX LAG. Host A and Host B are each connected
directly to PE17 extended ports and the E‐CIDs for each port are shown.
1. Host A pings Host B.
2. The packet arrives at the PE, and the PE adds E‐CID 1 to the packet, and sends the
packet to the CB over SPX LAG.
3. The packet arrives at the CB, and the CB performs a MAC look‐up for MAC B, which
is destinated for port 17/1/2. It adds E‐CID 2 to the packet and sends it to the PE
over the SPX LAG.
4. The packet arrives at the PE, and the PE performs a look‐up of the E‐CID 2
forwarding entry, and finds destination port 17/1/2.
5. It removes the E‐CID and sends the packet to Host B.
Revision 0419 12 ‐ 12
Port Extender ‐ CSP
Control & Status Protocol
• CB configures all of the forwarding tables
for each downstream switch
– Occurs at PE initialization
– No additional programming required as a
result of MAC learning/aging
• PE CSP is transported over
Edge Control Protocol (ECP)
• ECP runs on top of LLDP at L2
• PE CSP communications are connection‐
oriented, enabling retransmission if a
command or response is lost
In the SPX environment, the CB configures all of the forwarding tables for each downstream
switch. This occurs at PE initialization, and no additional programming is required as a
result of MAC learning and aging.
PE Control & Status Protocol (CSP is) transported over Edge Control Protocol (or ECP),
which runs on top of LLDP at Layer 2 and provides ACK and retransmit responses. PE CSP
communications are connection‐oriented, enabling retransmission if a command or
response is lost
Revision 0419 12 ‐ 13
Deployment Considerations
• No local switching on PE ports
• Maximum 4 VLANs per PE port (including Default
VLAN)
• No IP addressing on physical PE port (VEs are
supported)
• If Spanning Tree is enabled on CB, it requires a
reload
• During manual initialization, ICX PEs require write
memory and reload to enter PE mode
• Only 1 SPX link/LAG allowed between PEs
• No speed configuration allowed on SPX ports
When deploying a Campus Fabric, there are some considerations to keep in mind.
First, as we have said, there is no local switching on the PE ports, all data and control
packet processing is done at the CB.
Also, there is a maximum 4 VLANs per PE port, this includes the Default VLAN. And, there is
no IP addressing on physical PE ports, although, virtual router interfaces (or VEs) are
supported.
If Spanning Tree is enabled on the Control Bridge, it requires you to reload the device.
During initialization, manually configured ICX PE devices will require you to save the
configuration with the write memory command, then reload the device to enter into PE
mode.
You are allowed only one SPX link or SPX LAG between PE devices
Finally, you cannot configure speed on SPX ports.
Revision 0419 12 ‐ 14
Topology Scalability
• Scalability limits in a single Campus Fabric
domain as of version 8.0.90
– Maximum 4 CB stack units (ICX 7650 and 7750)
– Maximum 8 PE chains
– Maximum 6 PE units per chain or ring
– Maximum of 16 stand‐alone PEs
• In addition to 8 PE chains
– Maximum 36 PE units per domain
– Maximum PE ports is 1,728 per domain
As of ICX software version 8.0.90, there are a few capability limits in a single SPX domain:
• There can be a maximum of four Control Bridge stack units, which can be ICX 7650 or
7750 stacks.
• There can be a maximum of 8 Port Extender chains with each chain having a
maximum of 6 units.
• In addition to PE chains, there is a maximum of 16 stand‐alone PEs.
• The total number of PE units, whether stand‐alone or in PE chains is 36.
• If you have the maximum number of units and each stack units has 48 ports, that has
the potential to provide support for 1,728 ports for connecting devices.
Revision 0419 12 ‐ 15
Configuration & Confirmation
16
Now that we have an understanding of how the SPX environment works, let’s take a look at
the configuration.
Revision 0419 12 ‐ 16
Campus Fabric Configuration Overview
• To configure a Campus Fabric domain, the following steps must be completed:
1. Configure and connect two to four ICX 7650 devices or two to four ICX 7750 devices in a traditional
stack, or configure a standalone ICX 7650 or ICX 7750
• Configuring two or more devices in a stack provides redundancy for the control bridge (CB)
2. Enable and configure the ICX 7650 or ICX 7750 stack or standalone device as a CB
3. Connect ICX 7150, ICX 7250, or ICX 7450 PE devices to the CB
4. PE configuration options:
• SPX Interactive Setup
• Zero‐touch Deployment
• Manually enable and configure the ICX 7150, ICX 7250, or ICX 7450 devices as PE units
Configuring a campus fabric is a fairly straight‐forward process. First you configure your ICX
7650 or 7750 devices into a stack, or single unit if you prefer. Stacking however provides
redundancy to the CB. Next you enable the device or stack as a CB.
Then you connect your ICX 7150, 7250 and/or 7450 devices to the CB. Lastly, you have
three choices of how to convert your ICX 7150, 7250 or 7450 devices to PEs.
• SPX interactive‐setup – The recommended method for Campus Fabric configuration.
SPX interactive‐setup is a tool that can be used even in more complex deployments
to convert PE candidates in router or switch mode to PE units. The tool allows you to
select PE IDs and configure SPX ports and LAGs. SPX interactive‐setup recognizes
some invalid SPX topologies that cannot be handled by zero‐touch deployment and
requests user input to convert them to valid topologies. SPX interactive‐setup also
allows you to change PE IDs interactively without detaching cables or shutting down
units.
• Zero‐touch deployment – Converts clean PE candidates in router or switch mode to
active PE units without user intervention. In supported topologies, zero‐touch detects
potential PE units, assigns them IDs, defines SPX ports or LAGs, and reloads them as
PE units.
• Manual deployment – In some situations, you may choose to configure the Campus
Fabric domain manually. For example, in manual configuration, there is no
requirement that configured ports be non‐base module ports. Manual configuration
is recommended if connecting candidate PE units involves LAGs or loops. Multiple
links between two candidate PEs cause packet looping. You can use manual
configuration to create an SPX LAG for multiple links before physically connecting
links.
Revision 0419 12 ‐ 17
Enabling Control Bridge Mode
• SPX Control Bridge (CB) can be enabled on ICX 7650 or 7750 single units or stacks
• SPX CB can be enabled on the unit or stack with the spx cb-enable command
ICX7750-48C Router# configure terminal

ICX7750-48C Router(config)# spx cb-enable
LLDP is globally disabled on enabling of SPX mode
System is now in 802.1br control bridge (CB) mode.
We start in global CONFIG mode on the active controller for the ICX 7650 or 7750 stack that
will serve as the Control Bridge, and enter the spx cb-enable command.
The CB must be running LLDP to support a Campus Fabric environment. If LLDP is not
already running, it is enabled on SPX ports by the spx cb-enable command. Enabling
or disabling SPX does not affect LLDP on data ports, and enabling or disabling LLDP on data
ports does not affect enabled SPX ports. Therefore you may see various LLDP related
messages when executing the spx cb-enable command.
The same configuration method is used whether it is a stack or stand‐alone CB unit.
When creating the CB stack, the same port cannot be configured as a stacking port or
trunk, and as an SPX port or SPX LAG.
Output will confirm the system is now operating as an 802.1BR control bridge (CB).
Revision 0419 12 ‐ 18
CB Configuration
• Use the spx cb-configure command to enter CB configuration mode

ICX7750-48C Router(config)# spx cb-config
ICX7750-48C Router(config-spx-cb)# ?
clear Clear table/statistics/keys
end End Configuration level and go to Privileged
level
exit Exit current level
max-vlans-per-pe-port Configure max allowed VLANs per PE port
multi-spx-lag Configure two lags of a live link
multi-spx-port Configure two ports of a live link
no Undo/disable commands
pe-id PE ID assignment provision
quit Exit to User level
show Show system information
spx-lag Configure one CB lag
spx-port Configure one or more CB ports
write Write running configuration to flash or terminal
zero-touch-enable actively send probe
zero-touch-ports Configure zero touch ports
<cr>
Once the CB is enabled, use the spx cb-configure command to enter into CB

configuration mode. You can see that the prompt changes to reflect the CB configuration
level. Here we use question mark help to view the different commands available for CB
configuration.
It is this configuration mode that you will configure specifics of the SPX domain, including
defining SPX ports/LAGs, PE ID assignments and start the zero‐touch provisioning process.
Revision 0419 12 ‐ 19
CB SPX Port/LAG Configuration
• Configure SPX ports on CB connecting to the PEs
ICX7750-48C Router(config-spx-cb)# spx-port 1/1/9
ICX7750-48C Router(config-spx-cb)# spx-port 1/1/10 1/1/20 to 1/1/24
– The spx-port command defines one or more separate PE devices
• An SPX LAG can be configured for 2 to 16 ports
ICX7750-48C Router(config-spx-cb)# spx-lag 2/1/10 to 2/1/11 3/1/10
– The spx-lag command defines connections to a single PE device
• Optionally, give the SXP port or LAG a group name
ICX7750-48C Router(config-spx-cb)# spx-port 1/1/10 pe-group finance
ICX7750-48C Router(config-spx-cb)# spx-lag 2/1/10 to 2/1/11 3/1/10 pe-
group marketing
Next, configure the SPX ports on the CB connecting to the PE devices. To do this, use the
spx-port command, and specify the SPX port number.
You can specify an individual port, or multiple ports with a space between each port, the
ports can be listed in no particular order. Or, use the to parameter to list a range of ports.
Instead of an SXP port, you can configure an SPX LAG using the spx-lag command and a
range of ports. Like the individual port configuration, you can list each port with a space
between them, or use the to parameter to list a range of ports. Please note that SPX LAGs
are different than regular LAGs on the switch. It is not required to configure switching LAGs
prior to configuring SPX LAGs.
While both of these commands look similar, it is important to note that each port
referenced in the spx-port command defines a separate PE device, while the spx-lag
command defines all of the ports connecting to a single PE device.
Optionally, you can give the SPX port or LAG a name in the form of a PE‐group name. This
can be used to identify the PE chain connected to the SPX port or LAG. Use the pe-group
command and enter a name.
Revision 0419 12 ‐ 20
Valid Campus Fabric Topologies
• Three valid PE topologies exist for connecting to a Campus Fabric domain Control Bridge
– A single PE unit connected to the campus
fabric domain CB through a spx‐link or
spx‐trunk
– A chain of PE units with a single unit at the
end of the chain connected to the campus
fabric domain CB through an spx‐link or
spx‐trunk
– A ring of PE units with each end of the chain
connecting to the campus fabric domain
CB through an spx‐link or spx‐trunk
PE connections to a configured campus fabric Control Bridge are required to adhere to one
of three valid topologies.
The first valid topology consists of a single Port Extender (PE) unit connected to the campus
fabric domain Control Bridge through a single SPX link or a single SPX LAG trunk.
The second valid topology consists of a chain of PE units with only the unit at one end of
the chain connected to the campus fabric domain CB through single SPX link or using an
SPX LAG trunk.
The final valid topology is to use a ring of PE units with the units at each end of the chain
connecting to the Control Bridge through single SPX link or using an SPX LAG trunk.
Revision 0419 12 ‐ 21
SPX Interactive Setup – Invalid Topology Detection
• Certain invalid configurations can be resolved using interactive‐setup
– Utility will provide different options to make configuration valid
On of the great benefits of the SPX interactive‐setup utility is that it is capable of detecting
invalid topologies. Not only does it detect, but it provides the administrator options to
resolve the cause of invalidity. The interactive‐setup utility will analyze the topology and
indicate which links could be removed to make the topology valid. Here see six invalid
topologies that are not allowed in a campus fabric.
• The first in invalid because the connection to the CB is from the end of a chain.
• The second is invalid because a loop must connect to both ends of the PE chain.
• The third and fourth are invalid because PE units are not allowed to form a loop
between themselves, only to the CB.
• The last two are invalid for multiple reasons and have several solutions for making
them valid.
And here are some of the examples of SPX interface removal options that may be
presented if these topologies are discovered by the SPX interactive‐setup utility. Keep in
mind most of these display one of many potential methods of making a PE topology valid.
• The first topology can be resolved by disabling one of the PE‐to‐PE links on the PE at
the start of the chain.
• The second can be resolved by removing the SPX link connecting CB to the middle PE.
• The third and fourth can be resolved by removing the looping connection on either
side of the PE connected to the CB.
• The last two have multiple resolutions that can discovered and resolved with SPX
interactive‐setup.
Revision 0419 12 ‐ 22
SPX Interactive‐Setup
Revision 0419 12 ‐ 23
SPX Interactive Setup ‐ Launch
• The spx interactive-setup command walks you through discovering PE devices,

building a campus fabric and modifying existing fabrics
ICX7750-48C Router# spx interactive-setup

You can abort spx interactive-setup at any stage by <ctrl-c>
0: quit
1: change PE IDs
2: discover and convert new units (no startup-config flash) to PEs
3: discover and convert existing/new standalone units to PEs
2&3 can also find new links and convert chain(s) to ring.
Please type your selection:
The SPX interactive setup is utility that walks you through creating and modifying campus
fabrics. When the utility is launched, you are given 4 options.
• Option 0 allows you to quit the utility with no changes
• Option 1 allows the changing of PE IDs on existing device within the fabric domain
• Option 2 allows the discovery and conversion of new PE units from ICX devices that have
no startup‐config in the local flash
• Option 3 allows the discovery and conversion of existing or new standalone PE units
Both options 2 and 3 are a capable of discovering new links and the ability to convert a
chain to a ring with minimal user intervention.
Revision 0419 12 ‐ 24
SPX Interactive Setup ‐ Discovery
• In the example, we will select option 2 to discover 6 new, unconfigured units
– Probes are sent out of the ports identified as SPX ports with the spx-port command
– Discovered devices are listed and the physical topology is displayed
Please type your selection: 2

T=59m5.2: Sending probes to ports: u1: 1/1/1,
Horizontal bars link to discovered units. Vertical bars link to CB or PEs.
#1: icx7250-24p-poe-port-management cc4e.24de.f3aa

#3: icx7250-24p-poe-port-management 609c.9f41.be5c
1/1/1
|
|
[ Output Truncated ]
In this example we will go through the process of discovering 6 potential PE units that are
ICX devices that have no configuration on them. So we will select option 2, which is used to
discover and convert new units.
Once selected, the CB begins sending probes out of all configured SPX ports. These are
ports that were configured using the spx-port or spx-trunk commands in SPX CB
configuration mode which we recently discussed.
If any devices are discovered, they will be displayed in a list. Here we see there were 6 units
discovered and their model information and system MAC address are displayed. Then a
physical topology will be displayed, which we’ll look at next.
Revision 0419 12 ‐ 25
SPX Interactive Setup – Discovered Topology
• Does discovered topology match physical connections?
1/1/1
|
|
1/1
+----+ +----+ +----+ +----+ +----+
-2/3| 1 |2/1--2/3| 2 |2/1--2/3| 3 |2/1--2/3| 4 |2/1==2/3| 5 |2/1-
| +----+ +----+ +----+ +----+ +----+ |
| |
| +----+ |
---------------------------------------------------------2/1| 6 |2/3-
+----+
Discovered 1 chain/ring
Chain #0: Do you want to select this chain? (enter 'y' or 'n’):
A topology is presented starting from the CB, on port 1/1/1. If there were additional CBs in
the topology, they would be displayed along the top. Then it shows the connections from
each unit to the next. Notice that the interactive setup is also capable of discovering trunks
between discovered PE units 4 and 5. Single SPX ports links are identified with dashes (‐)
while discovered SPX trunk links are identified with equal signs (=).
If this topology matches all of the devices you intended, select y, for yes.
Revision 0419 12 ‐ 26
SPX Interactive Setup – Invalid Topologies
• The discovered topology is evaluated against valid topologies
– If invalid, interactive setup attempts to give you options to make it valid
PE-PE Ring
is an invalid
1/1/1 topology
|
|
1/1
+----+ +----+ +----+ +----+ +----+
-2/3| 1 |2/1--2/3| 2 |2/1--2/3| 3 |2/1--2/3| 4 |2/1==2/3| 5 |2/1-
| +----+ +----+ +----+ +----+ +----+ |
| |
| +----+ |
---------------------------------------------------------2/1| 6 |2/3-
+----+
[ Output truncated ]
New units form a ring. If you want to select all units, you must remove a link.
Type the link to be removed: 0: no, 1: (#6 2/1 -- #1 2/3), 2: (#1 2/1 -- #2 2/3) (default:
0): 1
Next, interactive compares the discovered topology against valid topologies. If the topology
is invalid, the interactive setup utility will provide options to make the topology valid.
In the example, the connection between PE switches forms a ring. this is an invalid
topology because PE units, by themselves, cannot form a ring.
In this scenario, there are two links that can be removed to make the topology valid. The
interactive setup utility will provide you with a selection to pick which solution you would
like to choose. We will choose option 1, to remove the SPX link between PE #1 and PE #6.
Please note this only specifies that the port will not be configured as an SPX port. It will still
be an enabled switching port on both devices and is connected. Which may cause a
problematic loop condition. In this case, it might be best to physically disconnect this link
between units 1 and 6 as well.
Revision 0419 12 ‐ 27
SPX Interactive Setup – Modified Topology
Type the link to be removed: 0: no, 1: (#6 2/1 -- #1 2/3), 2: (#1 2/1 -- #2 2/3)
(default: 0): 1
#1: icx7250-24p-poe-port-management cc4e.24de.f3aa
#3: icx7250-24p-poe-port-management 609c.9f41.be5c
1/1/1
|
|
1/1
+----+ +----+ +----+ +----+ +----+
| 1 |2/1--2/3| 2 |2/1--2/3| 3 |2/1--2/3| 4 |2/1==2/3| 5 |2/1-
+----+ +----+ +----+ +----+ +----+ |
|
+----+ |
| 6 |2/3-
+----+
After the selection, the interactive setup utility will display the new SPX topology. Notice
that the connection between unit #1 and unit #6 is not longer present, indicating it will not
be configured as an SPX port.
Again, please note this only specifies that the port will not be configured as an SPX port. It
will still be an enabled switching port on both devices and is connected. Which may cause a
problematic loop condition. In this case, it might be best to physically disconnect this link
between units 1 and 6 as well.
Revision 0419 12 ‐ 28
SPX Interactive Setup – Define PE IDs
• Next, define the PE ID of each discovered unit
#1: icx7250-24p-poe-port cc4e.24de.f3aa, type an ID (No: 0, default: 17): [Enter]

#2: icx7250-24-port 609c.9f42.4100, type an ID (No: 0, default: 18): [Enter]
#3: icx7250-24p-poe-port 609c.9f41.be5c, type an ID (No: 0, default: 19): [Enter]
#4: icx7250-48-port cc4e.24e0.5cd6, type an ID (No: 0, default: 20): [Enter]
#5: icx7250-48p-poe-port cc4e.24e1.dc82, type an ID (No: 0, default: 21): [Enter]
#6: icx7250-24p-poe-port 78a6.e121.10a4, type an ID (No: 0, default: 22): [Enter]
You selected 6 unit(s): #1: ID=17, #2: ID=18, #3: ID=19, #4: ID=20, #5: ID=21, #6: ID=22,
#1 #2 #3 #4 #5
+----+ +----+ +----+ +----+ +----+
1/1/1--1/1| 17 |2/1--2/3| 18 |2/1--2/3| 19 |2/1--2/3| 20 |2/1==2/3| 21 |2/1-
+----+ +----+ +----+ +----+ +----+ |
#6 |
+----+ |
| 22 |2/3-
+----+
Proceeding will produce the above topology. Do you accept it? (enter 'y' or 'n’):
Next, the interactive setup utility will allow you to define the PE ID of each unit in the
discovered chain or ring. The first unit will default to PE ID of 17. You can change it here or
accept the default by pressing the Enter key. The valid range of PE IDs is from 17 to 56. If
you modify a PE ID of one of the units, the next unit will default to next number in
sequence. For example, if you select PE ID 25, the next PE will default to PE ID 26. I the
example here, all of the default values were selected and the topology is redrawn with
chosen PE IDs.
Revision 0419 12 ‐ 29
SPX Interactive Setup – Confirm Topology
Proceeding will produce the above topology. Do you accept it? (enter 'y' or 'n'): y
spx interactive-setup discovers 1 chain (valid#= 1, selected#= 1)

spx interactive-setup discovers 6 unit(s) and sends reload to chain 0:
#1 cc4e.24de.f3aa U17, D0: 1/1, D1: 2/1
#2 609c.9f42.4100 U18, D0: 2/3, D1: 2/1
#3 609c.9f41.be5c U19, D0: 2/3, D1: 2/1
#4 cc4e.24e0.5cd6 U20, D0: 2/3, D1: 2/1 to 2/2
#5 cc4e.24e1.dc82 U21, D0: 2/3 to 2/4, D1: 2/1
#6 78a6.e121.10a4 U22, D0: 2/3
ICX7750-48C Router#
Finally, you confirm acceptance of the topology. After selecting yes, a summary of the
discovery is displayed, including:
• Then number of discovered chains of rings
• The number of discovered units
Then finally a summary of each discovered unit, which includes MAC address, the selected
PE ID and the SPX links being used.
At this point any newly discovered units that are converted to PEs will be reset to assume
their configured roles. This may take a few minutes. The system log can be viewed to
monitor the new devices joining the campus fabric.
Revision 0419 12 ‐ 30
Displaying CB Configuration
• show running-config on CB spx unit 19

module 1 icx7250-24p-poe-port-management-module
displays SPX units with module and SPX module 2 icx7250-sfp-plus-8port-80g-module
spx-port 19/2/1
port details spx-port 19/2/3
spx unit 20
module 1 icx7250-48-port-management-module
ICX7750-48C Router# show running-config module 2 icx7250-sfp-plus-8port-80g-module
Current configuration: spx-lag 20/2/1 to 20/2/2
! spx-port 20/2/3
ver 08.0.90T203 spx unit 21
! module 1 icx7250-48p-poe-port-management-module
stack unit 1 module 2 icx7250-sfp-plus-8port-80g-module
module 1 icx7750-48-xgc-port-management-module spx-port 21/2/1
module 2 icx7750-qsfp-6port-qsfp-240g-module spx-lag 21/2/3 to 21/2/4
stack-port 1/2/1 spx unit 22
stack-port 1/2/4 module 1 icx7250-24p-poe-port-management-module
spx unit 17 module 2 icx7250-sfp-plus-8port-80g-module
module 1 icx7250-24p-poe-port-management-module spx-port 22/2/3
module 2 icx7250-sfp-plus-8port-80g-module !
spx-port 17/1/1 !
spx-port 17/2/1 !
spx unit 18 spx cb-enable
module 1 icx7250-24-port-management-module spx cb-configure
module 2 icx7250-sfp-plus-8port-80g-module spx-port 1/1/1
spx-port 18/2/1 pe-id 1/1/1 17 18 19 20 21 22
spx-port 18/2/3 <Truncated Output>
To check your configuration on the CB use the show running-config command. The

output displays the SPX units with details on installed modules and all SPX ports and LAGs.
Revision 0419 12 ‐ 31
Displaying SPX Configuration From CB
• show spx on CB displays the CB stack and PE unit/PE‐chain with a cascade port

ICX7750-48C Router# show spx
T=1h6m40.1: alone: standalone, D: dynamic cfg, S: static
1 S ICX7750-48XGC alone 609c.9f20.3b00 0 local Ready
17 D ICX7250-24P spx-pe cc4e.24de.f3aa N/A remote Ready
18 D ICX7250-24 spx-pe 609c.9f42.4100 N/A remote Ready
19 D ICX7250-24P spx-pe 609c.9f41.be5c N/A remote Ready
20 D ICX7250-48 spx-pe cc4e.24e0.5cd6 N/A remote Ready
21 D ICX7250-48P spx-pe cc4e.24e1.dc82 N/A remote Ready
22 D ICX7250-24P spx-pe 78a6.e121.10a4 N/A remote Ready
+---+
2/1| 1 |2/4
+---+
+----+ +----+ +----+ +----+ +----+
1/1/1--1/1| 17 |2/1--2/3| 18 |2/1--2/3| 19 |2/1--2/3| 20 |2/1==2/3| 21 |2/1-
+----+ +----+ +----+ +----+ +----+ |
|
+----+ |
| 22 |2/3-
+----+
With both CB and PEs configured, use the show spx command on the CB to view the

details of each unit in the SPX environment including the active and standby members of
the CB, and each PE.
One field to pay attention to after running SPX interactive setup is the letter next to the
unit ID. It will either be a “D” for dynamic or an “S” for static. A static PE unit has saved
configuration in startup configuration flash. The PE unit continues to exist if the system
reloads. A PE unit with dynamic configuration does not have its configuration stored in
startup flash. Consequently, the dynamically configured PE configuration is removed when
the system reloads.
The bottom of the output shows the topology of the SPX environment. The IDs for each
unit is in the box, and the connecting ports are on the outside of each box.
Revision 0419 12 ‐ 32
Zero‐Touch Deployment
Revision 0419 12 ‐ 33
Zero‐Touch Deployment
• The Zero‐touch deployment only works with “clean” candidate PE units
– No startup‐config can be present
• Essentially performs SPX Interactive‐setup, option #2 with no user intervention and uses
default selections
– Only works on valid topologies
• Enable CB and configure zero‐touch ports
ICX7750-48F Router(config)# spx cb-enable
ICX7750-48F Router(config)# spx cb-config
ICX7750-48F Router(config-spx-cb)# zero-touch-ports 1/1/3 1/1/16
ICX7750-48F Router(config-spx-cb)# zero-touch-enable
The Zero‐touch deployment only works with “clean” ICX units that have no startup‐config
present. The utility essentially performs spx interactive‐setup, option #2 with no user
intervention and automatically applies the default selections and only works on valid
topologies.
The initial setup steps are the same as stack interactive‐setup:
1. Enable control bridge functionality with the spx cb-enable command
2. Enter CB configuration mode with the spx cb-config command
3. Define the zero‐touch ports where PEs are/will be connected with the zero-touch-
ports command
4. Then begin the zero‐=touch process with the zero-touch-enable command
Revision 0419 12 ‐ 34
Zero‐Touch Deployment (cont.)
• Messages display discovery progress
ICX7750-48F Router(config-spx-cb)#
Send reload to chain0: #2 CC4E.24DC.E9CE ID=18, D0: 2/3, D1: 2/5 to 2/6 2/8
#1 CC4E.24DC.F166 ID=17, D0: 2/5 to 2/6 2/8, D1: 2/4
T=12m23.5: Add spx-port 1/1/16 for a discovered unit to join
T=12m23.6: Add spx-port 1/1/3 for a discovered unit to join
PE-port=17/2/4 CB-port=1/1/16
Sica Unit id:17, PoD License Capacity:8
PE-port=18/2/3 CB-port=1/1/3
Sica Unit id:18, PoD License Capacity:8
Stack unit 18 Power supply 1 is up
Stack unit 18 Power supply 2 is down
Stack unit 17 Power supply 1 is up
Stack unit 17 Power supply 2 is down
If connected to the console messages will display indicating the status of the zero‐touch
provisioning process. Nearly all of these outputs are after the discovery of PE devices.
It will typically start wit the sending of a reload command to units. Then when the units
come back up as PEs, the remaining messages providing information about:
• PEs joining the campus fabric
• Ports connecting CB to PE
• Licensing on PE units
• Power supply statuses of PE units
Revision 0419 12 ‐ 35
Zero‐Touch Deployment (cont.)
• Display results
ICX7750-48F Router(config-spx-cb)# show spx
T=20m3.1: alone: standalone, D: dynamic cfg, S: static
1 S ICX7750-48XGF alone cc4e.24d2.2c00 0 local Ready
17 D ICX7250-24 spx-pe cc4e.24dc.f166 N/A remote Ready
18 D ICX7250-24 spx-pe cc4e.24dc.e9ce N/A remote Ready
+---+
2/1| 1 |2/4
+---+
+----+ +----+
1/1/3--2/3| 18 |2/5==2/5| 17 |2/4--1/1/16
+----+ +----+
• After discovery completes, disable zero-touch-enable, remove
zero-touch-ports and save configuration
ICX7750-48F Router(config-spx-cb)# no zero-touch-enable
ICX7750-48F Router(config-spx-cb)# no zero-touch-ports 1/1/3 1/1/16
ICX7750-48F Router(config-spx-cb)# write mem
The show spx output displays the details of the newly added PE units.

When first added the configuration for each PE unit will display a “D” for dynamic.
Executing a write memory command should be executed to save the configuration to flash.
Lastly, after the discovery is completed, zero‐touch discovery probes will continue being
sent out of the configured zero‐touch‐ports. That is why it should be disabled with the no
zero-touch-enable and no zero-touch-ports commands as soon as the
discovery is finished. And once this is complete, the configuration should be saved with the
write memory command.
Revision 0419 12 ‐ 36
Summary
– Describe the ICX Campus Fabric
– Explain the components of the Campus Fabric
– Configure Camps Fabric Control Bridge (CB)
– Configure SPX Port Extenders (PE) using Interactive‐Setup and Zero‐Touch deployment
– Use show commands to view the configuration of the SPX environment
Now that we have completed this module, you should be able to:
• Describe the ICX Campus Fabric
• Explain the components of the Campus Fabric
• Configure Camps Fabric Control Bridge (CB)
• Configure SPX Port Extenders (PE) using Interactive‐Setup and Zero‐Touch
deployment
• Use show commands to view the configuration of the SPX environment
Revision 0419 12 ‐ 37
End of Module 12:
ICX Campus Fabric
Revision 0419
This concludes the ICX campus Fabric training module.
Revision 0419 12 ‐ 38
Appendix A:
PE Manual Configuration
39
This appendix covers the manual configuration of the PE units.
Revision 0419 12 ‐ 39
Switch Port Extender Modes
• Regular mode: a standalone ICX 7150, 7250 or 7450 unit behaves like a normal (pre‐SPX)
routing or switching device
• Provisional‐PE mode: an ICX PE‐capable unit enters provisional‐PE mode after the user
configures the spx pe-enable command but has not reloaded the unit
– The unit acts like a non‐SPX switch or router
• PE mode: the SPX‐enabled unit boots‐up in PE mode and operates as a dummy SPX device
– It does not parse startup‐config flash upon boot‐up
– It runs protocols only available to a PE unit, such as LLDP
– It does not perform local switching
PE devices go through these modes of operation during the enabling of SPX:
All units start in Regular mode, where a standalone ICX 7450 unit behaves like a normal
pre‐SPX enabled routing or switching device.
Then it enters Provisional‐PE mode. This is when the user has configured the spx pe-
enable command but has not reloaded the unit.
The unit is still acting like a non‐SPX switch or router.
Once the unit is reloaded, it boots into PE mode, and starts acting like a PE. The unit
operates as a dummy device. It does not parse startup‐config flash upon boot‐up and it
only runs protocols available to a PE unit, such as LLDP. The PE does not perform local
switching, and most commands, including configuration commands, are blocked.
Revision 0419 12 ‐ 40
PE Configuration
Port Extender Units (ICX 7150, 7250 and 7450)
• Configure each PE using spx pe-enable
ICX7450-48P Router# configure terminal
ICX7450-48P Router(config)# spx pe-enable
Enter provisional PE mode. CLI is limited to spx unit 1.
After finishing all configuration, please "write memory" and reload this unit
to be a PE.
– System enters Provisional‐PE mode
– In Provisional‐PE mode, the text [Provisional_PE] is appended to the front of the system prompt
• Optionally, suggest a PE‐ID for the PE
[Provisional-PE]ICX7450-48P Router(config)# spx suggested-id 20
– IDs are from 17 to 56
– May be overridden by the CB
Now let's configure the PE devices.
We start in global CONFIG mode with the spx pe-enable command. And the system

then enters the Provisional‐PE mode.
Now the system automatically assigns the 2 default SPX ports.
The default SPX PE ports can be changed on a device in Provisional‐PE mode, which we will
see on the next slide.
You can configure a suggested ID (from 17 to 56) on the PE unit before it joins the CB.
However, the suggested ID may be overridden by the CB if it matches a reserved
configuration. The PE unit will be assigned the PE ID from the reserved configuration
instead of the suggested ID. If the suggested is already in use on another active PE, or if the
ID exists in a saved configuration, the PE will not be assigned the suggested ID.
Revision 0419 12 ‐ 41
PE Configuration (cont.)
• The following parameters can be changed on the PE from Provisional‐PE mode
– Change the default SPX ports
[Provisional-PE]ICX7450-48F Router(config-spx-unit-1)# no spx-port 1/2/3
spx-port 1/2/3 is removed.
[Provisional-PE]ICX7450-48F Router(config-spx-unit-1)# spx-port 1/2/4
– Configure an SPX LAG on PE
[Provisional-PE]ICX7450-48F Router(config-spx-unit-1)# spx-lag 1/2/1 to 1/2/2
– Optionally, assign a Name to the PE unit (on PE)
[Provisional-PE]ICX7450-48F Router(config-spx-unit-1)# pe-name finance
As I just mentioned, there are some configurations that can be preformed in Provisional‐PE
mode.
First, you can change the default SPX PE ports. In our example on this slide, notice that the
prompt has [Pro‐PE] prepended to it. This signifies that the device is in Provisional‐PE mode.
Now, you can change the default ports using the no spx-ports command followed by the

default SPX port number, then use the spx-port command followed by the desired port or
ports.
Also from Provisional‐PE mode, you can configure an SPX LAG. Use the spx-lag command
followed by the port range.
As we saw with the CB configuration, a range of ports can be listed with a space between
them, or you can use the parameter “to” to specify a sequence of ports.
Optionally, you can assign a name to the PE using the pe-name command.
Revision 0419 12 ‐ 42
Displaying PE Configuration
• show running-config on PE can only be used in Provisional‐PE mode
– In PE mode the console is not available, it can only be accessed through the CB
[Pro-PE]ICX7450-48F Router(config-spx-unit-1)# show running-config

Current configuration:
!
ver 08.0.40b1T213
!
spx pe-enable
spx suggested-id 20
pe-name finance
spx unit 1
module 1 icx7450-48f-sf-port-management-module
module 2 icx7400-xgf-4port-40g-module
module 4 icx7400-qsfp-1port-40g-module
spx-lag 1/2/1 to 1/2/2
spx-port 1/2/4
<Truncated Output>
To check your configuration, use the show running-config command on the PE in

Provisional‐PE mode to view the changes made.
This can only be done from Provisional‐PE mode because the console will not be available
once the changes are saved and the system is reloaded into PE mode.
Revision 0419 12 ‐ 43
Revision 0419 12 ‐ 44

ICX150 Rev0419 SG L

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ICX150 Rev0419 SG L

Caricato da

Copyright:

Formati disponibili

ICX 150

Ruckus ICX Implementer

Copyright © 2019 Ruckus Networks, an ARRIS company All rights reserved.

Revision: April, 2019

We’ll begin with an overview of the course content.

• After completing this course, attendees should be able to:

Welcome to the ICX 150 Implementer course. This course consists of 12 modules

SZ300 vSZ SZ100 Series ZoneDirector Unleashed Cloud Wi‐Fi

INDOOR AP High Density Enterprise Small Business

R7xx Series R6xx Series R5xx Series R3xx Series H5xx Series

120W PoE 2xSFP+ and 2xUTP High performance and port density

Dual Fan Trays Dual PSU

ICX7400‐1X40GQ ICX7400‐4X10GF ICX7400‐4X10GC ICX7400‐4X1GF

Bandwidth 80Gbps 80Gbps 80Gbps 8Gbps

ICX7650‐1x100GQ ICX7650‐2X40GQ ICX7650‐4x10GF

1 × 40/100 GbE 2 x 40 GbE 4 × 10 GbE

Module Slot Front Front Front

Function Uplink Uplink Uplink

Bandwidth 100 Gbps 80 Gbps 40 Gbps

Maximum Number of Stack Link Maximum Links Per Maximum Stack

ICX 7250 12 10G 2 x 10G 480Gbps

ICX 7450 12 10G or 40G 2 x 10G or 1 x 40G 960Gbps

ICX 7650 12 40G or 100G 2 x 40G or 1 x 100G 1.128Tbps

ICX 7750 12 40G 6 x 40G 5.76Tbps

ICX 7850 12 40G or 100G 4 x 40G or 4 x 100G 9.6Tbps

Once logged in, you are

• Privileged EXEC level Global Configuration (CONFIG)

• Use end or Ctrl+z to return to # prompt from any lower level

• Use quit to return to > prompt from any lower level

ICX7150-C12-Switch(config)# no vlan 200

ICX7150-C12-Switch(config)# ping 10.1.1.1

– Enter copy flash followed by a ?, or enter Tab, to view the next available options

ICX7150-C12-Switch# copy flash ?

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved © 2017 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION 14

ICX7150-C12-Switch# erase startup-config

• ICX 7750 and 7850 allow 40 GbE ports to be split into 4‐10 GbE ports using breakout cable

Ruckus(config)# interface ethernet 1/1/9

Ruckus(config)# interface ethernet 1/1/10 ethernet 1/1/15 ethernet 1/1/20

Ruckus(config)# interface ethernet 1/1/1 to 1/1/8

• show dir | show files

• show dir disk0 | show files disk0

The show flash command displays the software versions loaded in the primary and

Ruckus# show interfaces brief

Current Link State Speed & Duplex

Ruckus# show interfaces ethernet 1/1/1 Interface up/down status

To view the details of an interface, use the show interfaces ethernet command

The show statistics command offers a more in‐depth look at the port statistics,

Welcome to the ICX 150 Implementor course. This course consists of 12 modules

Enterprise/Campus Current Target Recommended Release if No Target

Legacy Flash Image File UFI File(boot, image) ICX 7750

Device Boot image file name Flash image file name UFI file name (boot, image)

ICX 7150 mnz10115.bin SPR08090.bin/SPS08090.bin SPR08090ufi.bin/SPS08090ufi.bin

The show version output displays the current software version along with the .bin file

8.0.80dT211 L2 code is installed in

The show flash command displays both the primary and secondary partitions and the

Ruckus# copy https flash 10.176.132.132 SPR08090.bin primary

Download the 8.0.90 UFI

Manifest upgrade in progress...

Compiled on Thu Jan 31 01:08:55 2019

Manifest upgrade in progress...

• Use show flash to verify that the image and boot code has been successfully copied

• Once verified issue the copy flash flash primary | secondary to copy to

License Install License Delete Default