ICX200 REV0919 SG L PDF

ICX 200
Ruckus Certified
Network Associate
Student Guide
Revision 0919
ICX 200
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: September, 2019

ICX 200 Introduction
ICX 200
Ruckus Certified Network Associate
Revision 0919
Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved
Revision 0919 1-1

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, Dynamic
PSK, FastIron, ICX, Multi-Chassis Trunking and relevant wired technologies 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 2
Revision 0919 1-2

Module 1
Introduction
Revision 0919 1-3

Course Overview
• This course provides an in-depth study of core competencies of configuration, operations,

maintenance and troubleshooting of Ruckus wired ICX family of devices
• This course covers L2/L3 protocol configurations including MSTP, OSPF, BGP, QoS, LLDP, PIM
and Ruckus proprietary protocols including MCT, VRRP-E and FDP
• Topics also include Virtual Routing and Forwarding Tables (VRFs) and foundational IP
version 6 protocol configuration on Ruckus ICX switches
• Additional topics include Multicast routing, traffic management and DHCP configuration on
ICX switches
• This course is based on the Ruckus FastIron OS (FI) v8.0.90 release
Revision 0919 1-4

Course Objectives
• Upon successful completion of this course, the student should be able to:
– Configure, implement and manage standard protocols on Ruckus equipment
– Configure and manage VLANs, Virtual Ethernet routed interfaces, topology groups, as well as create Link
Aggregation Groups (LAGs)
– Configure Layer 2 advanced features and discovery protocols
– Understand Layer 3 configuration including redundancy protocols
– Understand and configure management and monitoring features on an ICX switch
– Implement and maintain OSPF routing protocol
– Configure foundational BGP peering and route advertising
– Configure DHCP features on an ICX switch
– Understand and configure traffic management features
– Understand and configure Multicast routing protocols
Revision 0919 1-5

Course Agenda
• M01: Introduction
• M02: Advanced Layer 2 Features
• M03: Port Monitoring and Management
• M04: Discovery Protocols
• M05: MCT
• M06: Layer 3 Fundamentals
• M07: Client Access Services
• M08: IP Gateway Redundancy
Revision 0919 1-6

Course Agenda (cont.)
• M09: Troubleshooting
• M10: Open Shortest Path First (OSPF) and Virtual Route and Forwarding (VRF)
• M11: Border Gateway Protocol (BGP)
• M12: Traffic Management
• M13: Multicast
Revision 0919 1-7

Course Prerequisites
• Before taking this course, attendees should have:

– Completed RSP 100: Routing and Switching Protocols course (or have equivalent knowledge)
– Completed ICX 150: Implementer course (or have equivalent knowledge)
– Passed the ICX Implementer Exam
Revision 0919 1-8

Gilmore and eBooks
• Ruckus uses Gilmore Global to provide training material used for all instructor-led classes
• Students will need to:

– Create an account
– Download the viewing application
– Download the course eBook (Student Guide)
– Download additional support documents
• Refer to the notes section for detailed steps on accessing the Gilmore Bookshelf
Your course email contains the following:

URL for the Bookshelf application
Your individual redemption code for the eBook
URL for additional course materials needed for the class
Bookshelf Application Access
Create a VitalSource account.
https://online.vitalsource.com/user/new
Download the Bookshelf application.
https://support.vitalsource.com/hc/en-us/sections/360002383594-Download-
Bookshelf
Launch the Bookshelf application and login using the username and password created
in step 1.
Select Account followed by Redeem Code. Enter the redemption code in the
course email.
Double-click the eBook icon to open the file.
Revision 0919 1-9

Training Facility and Policies
• Facility information
• Lab policies
• Start and stop times
• Regular breaks
• Set your cell phone to silent or vibrate
• Share relevant networking experiences
• Have fun!
Revision 0919 1 - 10
Introductions
• Take a moment and share with us:

– Your name
– Your employer
– Your location
– Your overall networking experience
– Your goals for attending this training
– An interesting fact about yourself
End of Module 1
Introduction
ICX 200 Advanced Layer 2 Features
Module 2:
Advanced Layer 2 Features
Revision 0919 2-1

Module Objectives
• After completing this module, attendees will be able to:
– Understand and deploy Link Aggregation Groups (LAG) advanced features
– Describe and configure protected ports
– Configure VLAN and VE interfaces
– Describe and configure aggregated VLANs (Q-in-Q)
– Understand Q-in-Q BPDU tunneling
– Describe and deploy advanced Spanning Tree features
– Understand and configure Multiple Spanning Tree Protocol
– Understand the benefits of Virtual eXtensible Local Area Network (VxLAN)
Revision 0919 2-2

Link Aggregation Groups (LAG)
Revision 0919 2-3

Link Aggregation Groups (LAG)
• 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
• 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)
• 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
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.
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.
Revision 0919 2-4

lag lag-name { dynamic | static } { id { number | auto } }
LAG Configuration
• Create a LAG by giving it a name and defining it as static, dynamic or keep-alive then
adding port members
Ruckus(config)# lag blue1 dynamic id 1
Ruckus(config-lag-blue1)# ports e 1/1/9 to 1/1/11
LAG blue1 deployed successfully!
Ruckus(config-lag-blue1)# port-name "Ruckus lag 1of3" ethernet 1/1/9
• Syntax: [no] lag lag-name { dynamic | static } { id { number | auto } }
• LAG virtual interface is created allowing LAG specific configuration

– Changes made to the LAG virtual interface is propagated to all port members in the LAG
– It is a good practice to manually set speed of LAG under the vLAG interface if possible
Ruckus(config-lag-blue1)# interface lag 1
Ruckus(config-lag-if-lg1)# spanning-tree 802-1w admin-pt2pt-mac
Ruckus(config-lag-if-lg1)# spanning-tree root-protect
Ruckus(config-lag-if-lg1)# stp-bpdu-guard
Ruckus(config-lag-if-lg1)# stp-protect
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. If you enter a
duplicate ID, you will receive an error: Error: LAG id 123 is already
used. The next available LAG id is 2.
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.
For a complete list of configurations that can be used under the LAG virtual interface,
refer to the ICX layer 2 configuration guide.
Revision 0919 2-5

Load Sharing over LAG
• Traffic is balanced across LAG ports using a hash index as described below:1
– Non-IP:
• Source and destination MACs
– IP Packets
• IPv4 TCP/UDP:
– Source and destination IP addresses, and source and destination TCP/UDP ports
• IPv4 Non-TCP/UDP:
– Source and destination IP address, source and destination MACs
• IPv6 TCP/UDP:
– Source and destination IP addresses, source and destination TCP/UDP ports, flow label
• IPv6 Non-TCP/UDP:
– Source and destination TCP and UDP ports, and flow label
• Symmetric load balancing option provides IPv4/6 bidirectional source and destination
address pair traffic flows out of the same member of a trunk group2
– Enabled on router code switches using:
Ruckus(config)# load-balance symmetric
Footnote 1: In ICX 7150 devices, the LAG hashing scheme is different from other ICX
platforms. As a result, the user may observe uneven distribution of packets when the
traffic pattern is sequential or incremental in the same step, for example, when both
the source and the destination IP address are incremented in the same step.
Footnote 2: Symmetric load balancing is supported on Ruckus ICX 7850, Ruckus ICX
7750, Ruckus ICX 7450, and Ruckus ICX 7250. Not supported on non-IP data traffic or
where MCT is deployed.
ICX devices support load-sharing over a LAG:
Traffic type Load balancing method1
Layer 2 bridged non-IP Source and destination MAC addresses
Source and destination MAC addresses, source and destination IP addresses,

Layer 2 bridged TCP/UDP
and source and destination TCP/UDP ports
Source and destination MAC addresses, and source and destination IP

Layer 2 bridged IP non TCP/UDP
addresses
Source and destination IP addresses, and source and destination TCP/UDP

Layer 2 bridged IPv4 TCP/UDP
ports
Layer 2 bridged IPv4 non TCP/UDP Source and destination IP addresses
Source and destination IP addresses, source and destination TCP and UDP
Layer 2 bridged IPv6 TCP/UDP
ports, and flow label
Layer 2 bridged IPv6 non TCP/UDP Source and destination TCP and UDP ports, and flow label
Layer 3 routed traffic Source and destination IP addresses and protocol field
Source and destination IP addresses and protocol field, and, for TCP/UDP
Layer 3 multicast
packets, Layer 4 source and destination ports
Revision 0919 2-6

In ICX 7150 devices, the LAG hashing scheme is different from other ICX platforms.
Please refer to documentation for details.
For many monitoring and security applications, bidirectional conversations flowing
through the system must be carried on the same port of a LAG. This enables the
firewall between Ruckus ICX devices to be configured to allow the bidirectional
conversations per link of the LAG if preferred. Network telemetry applications also
require symmetric load balancing on the LAGs between the devices. Symmetric load
balancing is supported on Ruckus ICX 7850, Ruckus ICX 7750, Ruckus ICX 7450, and
Ruckus ICX 7250.
You can enable symmetric load balancing for IPv4 and IPv6 data traffic on Ruckus ICX
devices using the load-balance symmetric command.
Revision 0919 2-7

LACP Timeout Configuration
• Dynamic or keep-alive LAG timeout can be configured as short (3 seconds) or long (120
seconds)
– Once configured the port remains in that timeout mode
• Regardless if it is up or down and whether or not it is part of a LAG
– All the ports in a LAG should have the same timeout mode
• This requirement is checked when the LAG is enabled on the ports
– No flap on active dynamic LAG interface when LACP mode/timeout change (FI 8.0.80 and above)
• To configure a port for a short LACP timeout:
Ruckus(config)# lag blue dynamic id auto
Ruckus(config-lag-blue)# lacp-timeout short
• Syntax: [no] lacp-timeout { long | short }
• Dynamic LACP LAGs are configured in active mode by default

– LAGs can be set to passive mode using:
Ruckus(config-lag-blue)# lacp-mode passive
The long keyword configures the port for the long timeout mode-120 seconds. With
the long timeout, an LACPDU is sent every 30 seconds. If no response comes from its
partner after 3 LACPDUs are sent, a timeout event occurs, and the LACP state
machine transition to the appropriate state based on its current state.
The short keyword configures the port for the short timeout mode--3 seconds. In the
short timeout configuration, an LACPDU is sent every second. If no response comes
from its partner after 3 LACPDUs are sent, a timeout event occurs, and the LACP state
machine transitions to the appropriate state based on its current state.
If you specify neither long nor short , the state machine operates based on the
standard IEEE specification as its default behavior. The original IEEE specification says
that the state machine starts with short the timeout and moves to the long timeout
after the LAG is established. However, sometimes a vendor’s implementation always
uses either the short timeout or the long timeout without changing the timeout.
Brocade provides this command so that you can configure Brocade devices to
interoperate with other vendor’s devices.
NOTE
This configuration is applicable to the configuration of dynamic or keep-alive LAGs
only.
Additionally for dynamic LAGs, LACP is set to active on all of the LAG ports. To set
LACP as passive you can use the lacp-mode passive command to set the LAG to the
passive mode. This is performed under the LAG configuration and applies to an
individuel LAG.
Revision 0919 2-8

Static LAG Threshold
• Allows the ability to disable all of the ports in a static LAG group when the number of
active member ports drops below a specified threshold value
– Provides the ability for failover to redundant link where there is adequate bandwidth
– LAG is kept intact and it is re-enabled if enough ports become active to satisfy the threshold configured
– The trunk-threshold command should be configured only at one end of the trunk
Ruckus(config)# lag blue static id 1

Ruckus(config-lag-blue)# ports ethernet 1/3/1 to 1/3/4
Ruckus(config-lag-blue)# trunk-threshold 3
• Configuration above will disable port members if the number of active ports drops below 3
– If the amount of active ports meets the threshold requirement the LAG is re-enabled
The trunk-threshold command should be configured only at one end of the trunk. If it
is set on both sides, link failures will result in race-conditions and will not function
properly.
Revision 0919 2-9

Protected Ports
Protected Port
• Commonly used to isolate traffic in:

– Hospitality
– Public Wi-Fi
– Campuses
– Condominium deployments
• Protected ports restrict all but CPU–bound traffic to

end hosts
– Port-level, per-device/stack only, security feature restricting
system level communication irrespective of their VLAN
membership
• Used on access point (AP) aggregator switches isolating traffic by
limiting access between users
• User traffic is only permitted to uplink and not any

other protected ports
To further isolate user traffic within a switch in environments where APs are deployed
especially when public Wi-Fi is used, The ports where APs are connected can be
configured as a protected port. This insures that user traffic does not communicate
with other members of the VLAN or broadcast domain. Instead the traffic can only be
forwarded out the uplink port limiting access by other connected users.
Protected Port Considerations
• The following configurations are supported with the protected port feature:
– Port MAC security
– 802.1x security
– DHCP snooping
– Control protocols
– Aggregated ports (LAGs)
• The following should not be configured as protected ports:1

– Uplink ports
– DHCP server ports
– ARP inspection trusted ports
– Ports on an active xSTP path in a device
– IGMP/MLD snooping router ports
– IGMP/MLD source ports
Footnote 1: The following features are not supported on protected ports:

• Layer 3 interfaces (Port or LAGs with IP addresses are not supported)
• Mirror or monitor ports
• Private VLAN (PVLAN)
• PVLAN extension to protected-port switches
• Virtual Ethernet (VE) and group VE interfaces
• Loopback interfaces
• Management interfaces
• OpenFlow ports
• SPX provider edge (PE) ports
• SPX ZTP–enabled ports
• Multi-Chassis Trunk (MCT) ICL and CCEP ports
Protected Port Configuration
• Configured on a single interface on switch
ICX(config)# interface ethernet 1/1/1

ICX(config-if-e1000-1/1/1)# protected-port
• Range and multiple ports on switch can be configured using:1
ICX(config-if-e1000-1/1/1)# interface ethernet 2/1/1 ethernet 3/1/1

ICX(config-if-e1000-2/1/1,3/1/1)# protected-port
• LAGs can also be identified as a protected port
ICX(config-if-e1000-2/1/1,3/1/1)# interface lag 1

ICX(config-lag-if-lg1)# protected-port
Footnote 1: You can also use ranging, as in the following example.

ICX(config)# interface ethernet 2/1/1 to ethernet 2/1/48
Protected Port Output
• Protected ports can be viewed on Individual ports or globally on the switch
– Individual:
ICX# show interface ethernet 1/1/1
GigabitEthernet1/1/1 is up, line protocol is up
Port up for 1 day(s) 18 hour(s) 43 minute(s) 30 second(s)
Hardware is GigabitEthernet, address is 609c.9fe6.0e40 (bia 609c.9fe6.0e40)
Configured speed auto, actual 1Gbit, configured duplex fdx, actual fdx
Configured mdi mode AUTO, actual MDI
Untagged member of L2 VLAN 100, port state is FORWARDING
<Output Truncated>
9740757 packets output, 12609042459 bytes, 0 underruns
Transmitted 118050 broadcasts, 607658 multicasts, 9015049 unicasts
0 output errors, 0 collisions
Relay Agent Information option: Disabled
Protected: Yes
– Globally:
ICX# show protected-ports
System-Wide Protected Ports: ethe 1/1/1 ethe 2/1/1 ethe 3/1/1 lag lg1
Configured on a port basis, each port configured as a protected port will be indicated
on the ports output. Although configured on each port specifically, all ports
configured as a protected port can be viewed from a global perspective using the
show protected-ports command.
VLANs
149_VLANs.png
VLAN Assignments
• ICX devices support port-based and

protocol-based VLANs
VLAN VLAN – The Default VLAN is 1

10 20 – By default, all interfaces belong to VLAN 1
– The default VLAN can be changed using the
default-vlan-id command
• Example Configuration: – Default VLAN cannot be tagged on any
Ruckus2(config)# vlan 10 name GRAY interfaces
Ruckus2(config-vlan-10)# tagged e 1/1/9
Ruckus2(config-vlan-10)# untagged e 1/1/2
Ruckus2(config-vlan-10)# vlan 20 • VLAN ID range is 1 to 4095
Ruckus2(config-vlan-20)# tagged e 1/1/9
– Reserved VLANs: 4087, 4090, and 4093 for

Ruckus2(config)# vlan 4
Ruckus internal, and VLAN 4094 for Single STP
Ruckus2(config-vlan-4)# untagged e 1/1/2
Error! Port 1/1/2 is already untagged
member of non default VLAN 10
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.
162_vlan
VLANs with 802.1Q Tagging
• 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 must be exclusively removed as an untagged member of a
VLAN to drop untagged frames
• Example Configuration:
Switch1(config)# vlan 10
Switch1(config-vlan-10)# tagged e 1/1/5
Switch1(config-vlan-1)# no untagged ethernet 1/1/5
Switch1(config-vlan-1)# no untagged ethernet 1/1/6
Error! Port 1/1/6 is member of default VLAN only. Cannot
remove
VLAN tagging is necessary when VLAN traffic is forwarded on the same link between
two switches known 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.
VLAN Feature Configuration
• In FI 8.0.80 and above configurations under VLAN can be performed before adding ports
– VLAN becomes active once user configures the VLAN
• Port member associations are not required for applications can be configured
– Allows VLAN feature configuration to be retained even if all port members are removed
• Example:
– Create VE interface even before adding ports to VLAN
Ruckus(config)# vlan 100

Ruckus(config-vlan-100)# router-interface ve 100
Ruckus(config-vlan-100)# interface ve 100
Ruckus(config-vif-100)# ip address 10.1.1.1/23
When VLANs are configured they become active and additional configurations can be
added without the requirement of port members being identified. This allows a VLAN
to be fully configured before the ports have to be committed to it.
VLANs can also be configured as routed VLANs allowing them to forward traffic
between locally configured routed VLANs. Each VLAN has to have a router interface
configured before it can be routed and the switch has to be running router code. We
will go into more detail on VLAN routing features later in this course.
Aggregated VLANs (Q-in-Q)
Aggregated VLANs (Q-in-Q) 149_aggregated-vlan-Q-in-Q.png
• Q-in-Q is a technique used by service providers to

transparently tunnel customer traffic between
customer sites
– Service providers encapsulate customer traffic using an
unique service VLAN tag
• Aggregated VLANs allow multiple VLAN tags to be

placed within another VLAN and forwarded
– The outer VLAN tag (path) and the inner VLAN tag (channel)
use different tag-type values
– Expands the limitation of 4095 VLANs
– Channels are isolated from other channels
– Provides point-to-point and point-to-multipoint
connections
An aggregated VLAN allows multiple VLAN tags to be placed within another VLAN,
sometimes referred to as Q-in-Q. The outer VLAN tag is the “path” on which all VLANs
are aggregated, and the inner VLAN tag, or the “channel”, is the client VLAN. The
outer and inner VLANs use different VLAN tags.
Aggregated VLANs expand the limitation of 4095 VLANs in a network by
encapsulating multiple VLANs into a single VLAN ID. In this configuration, end devices
within a channel are not visible to devices in other channels. It provides point-to-
point and point-to-multipoint connections.
Aggregated VLAN Example
VLAN 500 VLAN 501
• Aggregation VLANs 500 and 501 in the core allow for overlapping Customer VLANs to be used
– VLAN 500 provides forwarding of customer VLANs 101 to 105 on Device A and F
– VLAN 501 provides forwarding of customer VLANs 101 to 105 on Device B and E
Here we see an example aggregated VLAN topology.

Device C and Device D are the core devices where the client VLANs are aggregated.
(Gray)
The ports on the link between the core devices, ports 1/2/4, must be tagged for VLAN
500 and 501, and they must use the same tag-type, 9100 to allow other aggregated
switches to identify it as a tagged frame. Also, the uplink ports coming from the edge
devices A and F are untagged member of VLAN 500 along with edge devices B and E
are untagged member of VLAN 501.
As for the client VLANs, each port on an edge device, like Device A, are added as
untagged ports to accommodate edge devices. The uplink port going to the core, (in
this case port 1/2/1 on Device A), going to port 1/2/1 on Device C is tagged so it can
pass on edge device traffic which in case is VLANs 101 through 105. (Green)
Note: that the client VLAN tag is considered payload by the aggregated switch and is
not read but instead it is simply forwarded like the rest of the payload.
Aggregated VLAN Configuration
• On each edge switch:

– Configure a separate port-based VLAN for each client connected to the edge switch (channel)
– The port connected to the core device (the device that will aggregate the VLANs) must be tagged with
each client VLAN
• On each core device:

– Enable with the aggregated-vlan command at the global CONIFIG level
• Allows the core device to add an additional tag to each Ethernet frame that contains a VLAN packet from the edge
device
• Additional tag can cause the frame to be longer than the maximum supported frame size
– To allow frames larger than 1522 on core devices due to the additional tag, you must enable jumbo
frames
• Enable jumbo frames
Ruckus(config)# jumbo
Jumbo mode setting requires a reload to take effect!
– Configure a VLAN tag profile (tag ID) that is different than the tag ID (Default 8100) used on the edges
Here we see the steps for configuring aggregated VLANs on the edge and core
devices.
We start with the edge switches and configure a VLAN for each client connected to
the edge switch, also referred to as the channel. Within each VLAN, add the port
connected to the client edge device as untagged, then add the port connected to the
core device as tagged.
On each core device, at the global CONFIG level, enter the aggregated-vlan
command. This command allows the core devices to add the additional tag to each
Ethernet frame containing the VLAN (or channel) packet from the edge device.
Next, configure a VLAN tag-type that is different than the tag-type used on the edge
devices. If you use the default tag-type of 8100 (default) on the edge devices, set the
tag-type on the core devices to another value, such as 9100. The tag-type must be
the same on all the core devices. All the edge devices also must have the same tag-
type but different from the tag-type on the core devices.
Also, ICX devices used at the core need to have support for larger frames enabled.
This is done using the jumbo command at the global CONFIG level. This change does
require a system reload.
Aggregated VLAN Configuration (cont.)
• Edge Switch Configuration

DeviceA(config)# vlan 101
DeviceA(config-vlan-101)# tagged ethernet 1/2/1
DeviceA(config-vlan-101)# untagged ethernet 1/1/1
DeviceA(config-vlan-101)# exit
DeviceA(config)# vlan 102
DeviceA(config-vlan-102)# tagged ethernet 1/2/1
DeviceA(config-vlan-102)# untagged ethernet 1/1/2
DeviceA(config-vlan-102)# exit
• Continue for VLANS 103 through 105

• All edge devices will receive similar
configuration
• Note: that the port facing the core device (1/2/1)
is tagged because all client VLANs share the port
as an uplink
Here we see the configuration for edge Device A.

Shown is the configuration for two of the five VLANs, but all five VLANs need to be
configured.
We start with the VLAN, and add the tagged uplink port to the core, and then the
untagged port to the client device.
Aggregated VLAN Configuration (cont.)
• Core Device C Configuration

DeviceC(config)# aggregated-vlan
DeviceC(config)# tag-profile 9100
DeviceC(config)# vlan 500
DeviceC(config-vlan-500)# tagged ethernet 1/2/4
DeviceC(config-vlan-500)# untagged ethernet 1/2/1
DeviceC(config-vlan-500)# vlan 501
DeviceC(config-vlan-501)# tagged ethernet 1/2/4
DeviceC(config-vlan-501)# untagged ethernet 1/2/2
DeviceC(config-vlan-501)# interface 1/2/1 to 1/2/2
DeviceC(config-mif-1/2/1-1/2/2)# tag-profile enable
• The tag-profile used (9100) must be the same on all the core devices
– Ports towards client switches are configured as untagged1
• Device D will have same VLAN, tag-profile and port tagging configuration on adjoining
ports
• Because client VLAN IDs are encapsulated in the core, duplicate IDs on different channels
are possible
Footnote 1: Since these ports are configured as untagged they simply accept the tag
placed on the frame from the client switches as payload and will encapsulate the tag
and consider it payload.
Next for core device configuration, set the tag-type globally using the tag-
profile command on the ICX 7000 series devices. Remember, each core device
must use the same tag-profile
Next, create your VLAN and add the uplink port between the core devices as tagged,
and the ports to the edge devices as untagged.
Because VLAN IDs used on edge devices are considered as payload when entering the
core, the use of duplicate channel VLAN IDs on other connecting switches is possible.
Device D Configuration Example:
DeviceD(config)# aggregated-vlan
DeviceD(config)# tag-profile 9100
DeviceD(config)# vlan 500
DeviceD(config-vlan-500)# tagged ethernet 1/2/4
DeviceD(config-vlan-500)# untagged ethernet 1/2/1
DeviceD(config-vlan-500)# vlan 501
DeviceD(config-vlan-501)# tagged ethernet 1/2/4
DeviceD(config-vlan-501)# untagged ethernet 1/2/2
DeviceD(config-vlan-501)# interface 1/2/1 to 1/2/2
DeviceD(config-mif-1/2/1-1/2/2)# tag-profile enable
Q-in-Q Protocol/BPDU Tunneling
Protocol/BPDU Tunneling Overview
• In ICX Q-in-Q, customer BPDU may be consumed and terminate in core devices
– Customers protocol traffic become ineffective by not reaching the rest of their devices
• BPDU Tunneling provides the ability for BPDU packets to be forwarded without local
processing
– BPDU tunneling can be enabled per protocol (STP (PVST, RSTP, MSTP)/CDP/LLDP/LACP)
– Tunneled protocol will use special destination MAC (0100.0ccd.cdd1)
– BPDU Tunneling supported in two Q-in-Q modes
• Legacy Tag-profile based Q-in-Q
• Selective Q-in-Q1
– Will interoperate with other vendors using same special destination MAC
Footnote 1: Selective Q-in-Q is beyond the scope of this class.
BPDU Tunneling Topology
Service Provider Network
1/1/1,2- Tag Profile Enable (0x9100) 1/1/1,2- Tag Profile Enable (0x9100)
l2protocol dot1q-tunnel stp l2protocol dot1q-tunnel stp
Customer Edge-A SVLAN 100 SVLAN 100
(0x8100) CVLAN 1-10
SVLAN 100 Customer Edge-B
ICX-one ICX-two ICX-three (0x8100) CVLAN 1-10
1/1/1,2
Customer-Site-A
Customer-Site-B
1/1/1,2
BM TM TM BM
CV SV SV CV
B CV CV B
P P
D B B D
U P P U
D D
U U BM: BPDU MAC
TM: Tunnel MAC
CV: Customer VLAN (1 to 10)
SV: Service Provider VLAN (100)
BPDU Tunnel Configuration Commands
• Configuration and Implementation process and commands1
Command Description
l2protocol dot1q-tunnel STP Enable STP tunneling on physical interface or LAG
l2protocol dot1q-tunnel LACP Enable LACP tunneling on physical interface or LAG
l2protocol dot1q-tunnel LLDP Enable LLDP tunneling on physical interface or LAG
l2protocol dot1q-tunnel CDP Enable CDP tunneling on physical interface or LAG
Enable all protocols (STP, LACP, LLDP & CDP) tunneling on
l2protocol dot1q-tunnel
physical interface or LAG
• Syntax: show l2protocol dot1q-tunnel { counters [ unit / slot / port | lag-id ] | port { unit / slot / port | lag-id
} | summary |vlan vlan-id }
Footnote 1: Enable BPDU tunneling on tag-profile enabled port or Selective Q-in-Q

enabled port.
Enable BPDU tunneling on a tag-profile-enabled port.
ICX(config-if-e1000-1/1/1)# tag-profile enable
ICX(config-if-e1000-1/1/1)# l2protocol dot1q-tunnel
(Optional) Specify a global Class of Service (CoS) value on all Q-in-Q tunneling ports
from the global configuration mode.
ICX(config)# l2protocol dot1q-tunnel cos 6
BPDU Tunnel Configuration
• Configure Tag-Profile based Q-in-Q or Selective Q-in-Q

• Enable BPDU tunnel per protocol or per interface (Physical port or LAG)
• Optionally you can configure rate limiting and CoS values to the tunnel protocol1
ICX# show running

tag-profile 9100
interface ethernet 3/1/1

tag-profile enable
l2protocol dot1q-tunnel stp
l2protocol dot1q-tunnel lacp
l2protocol dot1q-tunnel cdp
l2protocol dot1q-tunnel lldp
!
interface lag 1
tag-profile enable
l2protocol dot1q-tunnel stp
l2protocol dot1q-tunnel cdp
l2protocol dot1q-tunnel lldp
Footnote 1: Each interface can limit the L2 traffic forwarded though the tunnel along
with drop value and shutdown threshold for each L2 protocol.
Syntax: l2protocol dot1q-tunnel drop-threshold { all | cdp | lacp | lldp | stp } threshold-
value
You can clear the counters within a switch using the clear l2protocol dot1q-tunnel
counters [ unit / slot / port | lag-id ] command
ICX(config-if-e1000-1/1/10)# l2protocol dot1q-tunnel

cdp Enable CDP Tunneling on interface
drop-threshold Configure drop threshold on interface
lacp Enable LACP Tunneling on interface
lldp Enable LLDP Tunneling on interface
shutdown-threshold Configure shutdown threshold on interface
stp Enable xSTP Tunneling on interface
<cr>
A CoS value for L2 protocols can be configured on the core switch.
ICX(config)# l2protocol dot1q-tunnel cos
DECIMAL CoS value (1 to 7)
<cr>
Syntax: l2protocol dot1q-tunnel cos cos-value
BPDU Tunnel Show Commands
ICX# show l2p dot1q-tunnel summary

BPDU Tunnel original MAC disabled
BPDU Tunnel MAC =0100.0ccd.cdd1
BPDU Tunnel CoS =5
STP Tunnel Ports: 3/1/1 3/1/2 lg1

LACP Tunnel Ports: 3/1/1 3/1/2
LLDP Tunnel Ports: 3/1/1 3/1/2 lg1
CDP Tunnel Ports: 3/1/1 3/1/2 lg1
Rate limit enabled Ports: None
BPDU Tunnel Show Commands (cont.)

ICX# show l2protocol dot1q-tunnel port 3/1/2
BPDU Tunnel enabled on 3/1/2 for following protocols
Protocols: CDP LACP LLDP STP
STP drop Threshold: 100 pkts/sec

STP shutdown Threshold: 200 pkts/sec
STP current Rx Rate: 0 pkts/sec
STP last Rx Time: 1 second(s) ago
LACP drop Threshold: Not enabled

LACP shutdown Threshold: Not enabled
LLDP drop Threshold: Not enabled
LLDP shutdown Threshold: Not enabled
CDP drop Threshold: Not enabled
CDP shutdown Threshold: Not enabled
All protocol drop drop Threshold: Not enabled
All protocol shutdown Threshold: Not enabled
BPDU Tunnel Show Tunnel VLAN

ICX# show l2p dot1q-tunnel vlan 100
BPDU Tunnel enabled on 3/1/1 for following protocols
Protocols: CDP LACP LLDP STP
STP drop Threshold: Not enabled

STP shutdown Threshold: Not enabled
LACP drop Threshold: Not enabled
LACP shutdown Threshold: Not enabled
LLDP drop Threshold: Not enabled
LLDP shutdown Threshold: Not enabled
CDP drop Threshold: Not enabled
CDP shutdown Threshold: Not enabled
All protocol drop drop Threshold: Not enabled
All protocol shutdown Threshold: Not enabled
BPDU Tunnel BPDU Tunnel Rate Limiting
• Per protocol or per port level (drop) rate limiting of incoming BPDUs
• Per protocol or per port level (shutdown) rate limiting of incoming BPDUs
ICX(config-if-e10000-3/1/2)# l2protocol dot1q-tunnel drop-threshold

all Set all protocol packets drop threshold in packets per sec
cdp Set CDP packet drop threshold in packets per sec
lacp Set LACP BPDU drop threshold in packets per sec
lldp Set LLDP packet drop threshold in packets per sec
stp Set xSTP BPDU drop threshold in packets per sec
ICX(config-if-e10000-3/1/2)# l2protocol dot1q-tunnel shutdown-threshold

all Set all protocols packet shutdown threshold in packets per sec
cdp Set CDP packet shutdown threshold in packets per sec
lacp Set LACP BPDU shutdown threshold in packets per sec
lldp Set LLDP packet shutdown threshold in packets per sec
stp Set xSTP BPDU shutdown threshold in packets per sec
ICX(config-if-e10000-3/1/2)# l2protocol dot1q-tunnel drop-threshold stp 100
ICX(config-if-e10000-3/1/2)# l2protocol dot1q-tunnel shutdown-threshold stp 200
Spanning Tree
Spanning Tree Protocol Support 153_spanning-tree.png
• All Spanning Tree standards are incorporated into IEEE

802.1Q-2014
• ICX supports:
– IEEE 802.1D, original standard for Spanning Tree (STP) and PVST
– Rapid Spanning Tree (RSTP) (802.1w)
– Multiple Spanning Tree (802.1s)
• Allows multiple VLANs to be managed by a single STP instance
• Default Spanning Tree configuration for ICX devices

– Switch code – 802.1D enabled globally
– Router code – STP disabled globally
• Supported STP enhancements:
– Single Instance Spanning Tree (SSTP) – 802.1D Fast Port Span
– Root Guard – 802.1D Fast Uplink Span
– BPDU Guard
– STP Protect
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.
802.1D Timers
• Timers can be adusted to allow for faster forwarding and convergence times when using
802.1D
– These variable timing values are:
• forward-delay seconds
– The forward delay is the value of time that a switch spends each the listening and learning states
– Values can be set between 4 through 30 seconds. The default is 15 seconds
• hello-time seconds (applies to the root bridge)
– Configures the time interval between two Hello packets
– This value ranges from 1 through 10 seconds. The default is 2 seconds
• max-age seconds
– Configures the time period the device waits to receive a Hello packet before it initiates a topology change
– The time period ranges from 6 through 40 seconds. The default is 20 seconds.
– Configuration can be performed individually or combined as shown

Ruckus(config-vlan-100)# spanning-tree forward-delay 4 hello-time 5 max-age 12
• If you plan to change STP bridge timers, you are required to stay within the following ranges, from section 8.10.2 of
the IEEE STP specification:
– 2 * (forward_delay -1) >= max_age>= 2 * (hello_time +1)
Spanning Tree Path Cost (802.1D)
• New higher link speeds have prompted the need for more granular link costs
• Feature provides the ability to adjust the STP path cost from 802.1D 1998 to 802.1D 2004
defined values
– Syntax: spanning-tree path-cost-method [long | short]
– Default option is short
– Configuring the long mode will upgrade spanning-tree Port Path Cost
path cost to 2004 defined values Link Speed IEE 802.1D 1998 IEE 802.1D 2004
– The short option will fallback to 1998 defined values
10 Mbps 100 2000000
– Switching between modes will remove any
interface path costs that have been configured 100 Mbps 19 200000
• Individual port cost value ranges vary depending
1 Gbps 4 20000
on which mode is configured on switch 2.5 Gbps 3 8000
5 Gbps 3 4000
Ruckus(config-vlan-100)# spanning-tree 10 Gbps 2 2000
ethernet 1/1/5 path-cost ?
DECIMAL short mode: 1 to 65535,
25 Gbps 1 800
long mode: 1 to 200000000 40 Gbps 1 500
100 Gbps 1 200
Higher port speeds have caused the need for more granular path cost values to
ensure the best path is chosen to the Root Bridge. By default the 1998 path cost
values are used when 802.1D is enabled. Newer values defined in the 2004
rectification of the standard makes room for 25Gbps and above values however this
effects all other port values as well. These values can be used within an ICX by using
the spanning-tree path-cost-method command which will count the path costs based
on the newer standard. It is recommended that all switches participating in the
instance have matching path cost values to avoid unexpected results. LAG interfaces
cost is calculated by the link speed of the LAG interface therefore it is suggested that
when a LAG is deployed in a STP environment that the cost be manually set to
correctly identify the link speed.
Make sure if you add interface path cost values you are aware of the proper cost
values that match the mode that you are using.
Ruckus(config-vlan-100)# spanning-tree ethernet 1/1/5
path-cost 20000000
STP Path Cost Configuration Example (Short/Long)

Ruckus(config)# spanning-tree path-cost-method short
Ruckus(config)# show span
<Output truncated>
Port STP Parameters:
Port Prio Path State Fwd Design Designated Designated
Num rity Cost Trans Cost Root Bridge
Hex
1/1/1 80 4 FORWARDING 2 0 8000609c9fe60858 8000609c9fe60858
Ruckus(config)# spanning-tree path-cost-method long

Ruckus(config)# show span
<Output Truncated>
Port STP Parameters:
Port Prio Path State Fwd Design Designated Designated
Num rity Cost Trans Cost Root Bridge
Hex
1/1/1 80 20000 FORWARDING 2 0 8000609c9fe60858 8000609c9fe60858
• Syslog entries
SYSLOG: <12> Jan 1 03:33:20 ICX7650-48P STP: VLAN 100 Port 1/1/5 - PathCostDefaulted
SYSLOG: <12> Jan 1 03:33:20 ICX7650-48P STP: VLAN 100 Port 1/1/6 - PathCostDefaulted
This setting is applied globally and effects all VLANs using 802.1D on the switch.
SYSLOG entries are also entered when this value changes and setting takes effect
immediately when applied.
802.1s Multiple Spanning Tree

(MSTP)
Multiple Spanning-Tree Regions
• Groups VLANs within a

instance of Spanning-
Tree
– Each instance appears as a
single node to other
instances outside the
grouping
• From SW1 perspective:

– Connected to 2 logical
switches that represent
the Region
– Link put in blocked state
are identified from the CST
connectivity
– Topology changes within
an MSTI instance are not
seen
From SW1 perspective it views its connections as connecting to 2 virtual switches

represented as the Region and not the single physical switch it is connected to. Any
topology changes that take place within the MSTI instances in each region is not
shared to SW1 unless it would effect the connections of the CST instance. It also will
not participate in the forming of the logical path within each of the MSTI instances.
Multiple Spanning Tree (MSTP) Key Concepts
• Common Spanning (CST)

– The one spanning-tree instance that encompasses the entire bridged network
• Regardless of the amount of VLANs within the bridged network
– A configured region is represented as a single virtual bridge that runs CST
• Within a region:
– Internal Spanning Tree (IST) instance is established Physical layout
• Allows for the CST instance to be brought into a region
– An MSTP bridge must handle at least these two instances:

• One IST (instance 0)
– Instance 0 is a special instance which extends CST inside the MST region
– In an ICX the IST is automatically created when MSTP is enabled
• One (or more) Multiple Spanning Tree Instances (MSTIs)
– MSTP can maintain multiple spanning-tree instances (MSTI) within each
MST region
– All switches in that region must run RSTP
Common Spanning (CST) – is defined as one spanning-tree instance that

encompasses the entire bridged network regardless of the number of VLANs
configured. In MSTP, from the CST perspective an MSTP region appears as a virtual
bridge that runs CST.
Once the system is configured into MSTP mode, CIST (sometimes referred to as
“instance 0”) is created and all existing VLANs inside the MSTP scope are controlled
by CIST. Once the system is configured into MSTP mode, CIST (sometimes referred to
as “instance 0”) is created and all existing VLANs inside the MSTP scope are
controlled by CIST. A VLAN whose ID is pre-mapped, will attach to the specified MSTI
instead of to the CIST when created.
Each MSTI has the ability to assign unique priorities along with its own link costs to
allow for its own logical topology which is separate from the IST. BPDUs are not sent
for each MSTI however their information is included into the IST's BPDUs using M-
Record fields in the form of a TLV’s (Type-Length-Value). This provides the ability to
carry root priority, designated bridge priority, port priority and root path cost etc.
within the IST BPDU. The IST BDPUs include all details of the IST instance but
additionally carry an M-Record for every active MSTI.
MSTP uses RSTP convergence processes (Proposal & Agreement), separate STP
instances are constructed for the IST and every MSTI. It is important to notice that
fundamental STP timers such as Hello, Forward Time, Max Age could only be tuned
for the IST. All other instances (MSTI’s) inherit the timers from the IST - this is the
natural result of all MSTI information being piggybacked in IST BPDUs.
MSTP Mode
• When a system is enabled for MSTP mode, the following changes are made to the system
configuration:
– All 802.1D and 802.1w STP instances are deleted regardless of whether the VLAN is inside the MSTP scope
or not
– All topology groups are deleted
– Any VSRP configuration is deleted
– Single-span (if configured) is deleted
– Metro Ring Protocol (MRP) running on a VLAN inside MSTP scope is deleted
• The common and internal spanning trees (CIST) collection is created and all VLANS inside
the MSTP scope are attached with the CIST
• Make sure that no physical Layer 2 loops exist prior to switching from non-MSTP mode to
MSTP mode. If, for example, you have a Layer 2 loop topology configured as a redundancy
mechanism before you perform the switch, a Layer 2 storm should be expected
In standard MSTP deployments the MSTP scope defines the VLANs that are under
direct MSTP control. You cannot run 802.1D or 802.1w on any VLAN (even outside of
MSTP scope) and you cannot create topology groups when a system is under MSTP
mode. While a VLAN group will still be supported when a system is under MSTP
mode, the member VLAN should either be all in the MSTP scope or all out of the
MSTP scope.
MSTP scope defines the VLANs that are under direct MSTP control. You cannot run
802.1D or 802.1w on any VLAN (even outside of MSTP scope) and you cannot create
topology groups when a system is under MSTP mode. While a VLAN group will still be
supported when a system is under MSTP mode, the member VLAN should either be
all in the MSTP scope or all out of the MSTP scope.
Make sure that no physical Layer 2 loops exist prior to switching from non-MSTP
mode to MSTP mode. Because many system configurations are deleted once MSTP is
enabled it can cause a loop and spike the CPU.
Configuring MSTP Mode
• To configure a system into MSTP mode, use the following command at the Global
Configuration level1
Ruckus(config)# mstp scope all

Enter MSTP scope would remove STP and topology group related configuration for
system
Are you sure? (enter 'y' or 'n'):
• This enables MSTP but is not operational until the mstp start command
• Once the system is configured into MSTP mode:

– CIST (instance 0) is created
• All existing VLANs inside the MSTP scope are controlled by CIST
– Whenever a new VLAN inside MSTP scope is created it is put under CIST control by default
Footnote 1: There is an additional option when using MSTP mode which is to enable
MSTP+. The MSTP+ feature allows you to selectively include VLANs in the MSTP
scope. The MSTP+ feature is an enhancement that allows you to exclude one or
more VLANs from the MSTP scope and configure them in a non-MSTP topology. Use
the mstp scope command with the pvst keyword to configure MSTP+. Because
MSTP+ is beyond the scope of this class, more details on MSTP+ can be found in the
ICX layer 2 guide.
In the Ruckus ICX MSTP implementation however, a VLAN ID can be pre-mapped to
another MSTI as described in the “Configuring an MSTP instance” section. A VLAN
whose ID is pre-mapped, will attach to the specified MSTI instead of to the CIST when
created.
Once under MSTP mode, CIST always controls all ports in the system. If you do not
want a port to run MSTP, configure the no spanning-tree command under the
specified interface configuration.
Once under MSTP mode, CIST always controls all ports in the system. If you do not
want a port to run MSTP, configure the no spanning-tree command under the
specified interface configuration.
MSTP Name and Revision Configuration
• Each switch that is running MSTP is configured with a name

– It applies to the switch which can have many different VLANs and can belong to many different MSTP
regions
Ruckus(config)# mstp name Ruckus
• Each switch that is running MSTP is configured with a revision number
Ruckus(config)# mstp revision 4
• If you want switches to be members of the same region, you must match the following:1
– MSTP configured name
– MSTP revision number (16 bit value)
Footnote 1: A hash value composed from the Revision number, VLAN-to-Instance

mapping, and Name is sent inside its BPDU. A BPDU received from a switch will be
able to identify if it is in the same region using this hash value. If different values
received in any of these fields are different from its own it can detect that it is in a
different region from the other switch.
If you want switches to be members of the same region, you must match attributes:
MSTP configured name
MSTP revision number (16 bit value)
The default MSTP values are:
Revision number for a device is 0 and can range from 0 through 65535
All VLANs are mapped to the IST
MSTP Name is null
Default MSTP configuration without name and revision configured
Ruckus(config)# show mstp configuration
MSTP CONFIGURATION
------------------
Scope : all system
Name :
Revision : 0
Version : 3 (MSTP mode)
Config Digest: 0xac36177f50283cd4b83821d8ab26de62
Status : Started
Instance VLANs
-------- ------------------------------------------------------
0 1 30
MSTP Instance Configuration
• An MSTP instance is configured with an MSTP ID for each region

– Each region can contain one or more VLANs
– ICX allows you to assign VLANS or ranges of VLANs to a MSTP instance before or after they have been
defined
• If pre-defined, a VLAN will be immediately placed in the MSTI that it was assigned to when the VLAN is created
• Default operation is to assign all new VLANs to the CIST (can be moved later to a specified MSTI)
• To configure an MSTP instance and map one or more VLANs to that MSTI
Ruckus(config)# mstp instance 7 vlan 4 to 7
• MSTI requires VLANs to be mapped to it

– Removing all VLANs from an MSTI, deletes the MSTI from the system
– CIST will remain regardless of whether or not any VLANs are assigned and remain functional
ICX devices can support up to 16 spanning tree instances in an MSTP enabled bridge
which means that it can support up to 16 different Layer 2 topologies.
Display of configuration:
Ruckus(config)# show mstp config
MSTP CONFIGURATION
------------------
Scope : all system
Name : Ruckus
Revision : 4
Version : 3 (MSTP mode)
Config Digest: 0x2821e3577953b25a6e9d2179d1679940
Status : Started
Instance VLANs
-------- ---------------------------------------------
0 1
7 4 to 7
Setting Parameters For an MSTP Instance
• Configuring bridge priority for an MSTP instance or port priority can be configured for a
specified instance
– To configure priority for an MSTP instance
Ruckus(config)# mstp instance 7 priority 8192
– To configure port members unique values

Ruckus(config)# mstp instance 7 ethernet 1/1/1
ethernet Ethernet port
path-cost Configure MSTP port path cost
priority Configure MSTP port priority
to To an end range
• MSTP global parameters

– MSTP has many of the options available in RSTP as well as some unique values
– To configure MSTP Global parameters for all instances on a switch
Ruckus(config)# mstp force-version 0 forward-delay 10 hello-time 4 max-age 12

max-hops 9
Specific priorities can be applied to configured instances on a switch controlling the

root bridge election within the instance. Each instance can be configured for a unique
value allowing for efficient bandwidth usage on redundant links within the region.
Port priorities of port members of an instance along with path cost can be configured
for further control of path selection.
MSTP Operational Edge Ports
• You can define specific ports as edge ports for the region connecting devices (such as a
host) that are not running any STP instance
– Configure ports as operational edge ports:
Ruckus(config)# mstp admin-edge-port ethernet 3/1/1
• Automatic operational edge ports1

– An MSTP switch can be configured to automatically set a port as an operational edge port if the port does
not receive any BPDUs
– If a port receives a BPDU, it is automatically reset to become an operational non-edge port
Ruckus(config)# mstp edge-port-auto-detect
• Point-to-point link
– You can set a point-to-point link between ports to increase the speed of convergence
– At the global configuration level issue:
Ruckus(config)# mstp admin-pt2pt-mac ethernet 1/2/5 ethernet 1/4/5
Footnote 1: This feature is set globally to apply to all ports on an MSTP switch where
it is configured. Note that after configuring, it takes the port about three seconds
longer to come to the enable state.
MSTP Show Commands
• To display information about a specific MSTP instance:
SW-Switch# show mstp 22

##### MST 22 vlans mapped: 22
Member ports: ethe 1/1/9 to 1/1/16
Bridge ID: address 00e0.52aa.2f00 priority 32790 (32768 sysid 22)
Reg Root ID: address 00e0.52c2.cf60 priority 22 (0 sysid 22)
port 1/1/9 int path cost: 200000
Remaining hops: 19
Interface Role State Designated ID Ext-cost Int-cost Prio.Num Pt2Pt Edge
1/1/9 Root FWD 001600e052c2cf60 -- 200000 128.73 Y N
1/1/10 Altr BLK 001600e052c2cf60 -- 200000 128.74 Y N
1/1/11 Altr BLK 001600e052c2cf60 -- 200000 128.75 Y N
1/1/12 Altr BLK 001600e052c2cf60 -- 200000 128.76 Y N
1/1/13 Altr BLK 8016000cdb310400 -- 200000 128.77 Y N
1/1/14 Altr BLK 8016000cdb310400 -- 200000 128.78 Y N
1/1/16 Altr BLK 801600e05202dc00 -- 20000 128.129 Y N
Syntax: show mstp instance-number | 0
MSTP Show Commands (cont.)
• To display information about the CIST instance:
SW-Switch# show mstp 0

##### MST 0 vlans mapped: 1 to 4094
Member ports: ethe 1/1/1 to 1/1/18
Bridge ID: address 0004.8089.3300 priority 0 (0 sysid 0)
Root ID: self
Reg Root ID: self
Message age: 0 remaining hops: 20
Interface Role State Designated ID Ext-cost Int-cost Prio.Num Pt2Pt Edge
1/1/10 Desg FWD 0000000480893300 200000 200000 128.10 Y N
1/1/11 Desg FWD 0000000480893300 200000 200000 128.11 Y N
1/1/12 Desg FWD 0000000480893300 200000 200000 128.12 Y N
1/1/13 Desg FWD 0000000480893300 200000 200000 128.13 N N
1/1/14 Desg FWD 0000000480893300 2000 2000 128.193 Y N
Field descriptions:
Field Descriptors for Show MSTP 0
Field Description
In the 0 instance, the Root ID is the MAC address of the Root

Root ID Bridge for the CIST. This value is "self" if the device being
accessed is the Root Bridge for the CIST
In the 0 instance, the Reg Root ID is the MAC address of the
Reg Root ID Root Bridge for the local region. This value is "self" if the
device being accessed is the Root Bridge for the local region
The amount of the max age value that the message used in
Message Age
transit from the root bridge external to the local region
The configured path cost on a link connected to this port to an
Ext-Cost
external MSTP region
Virtual eXtensible Local Area

Network (VXLAN)
physical server now has multiple Virtual Machines (VMs) each with its own Media Access Control (MAC) address
VxLAN Overview/Use Case
• VxLAN is intended to address limitations effecting modern data center networks including:
– Modern virtualization of physical servers

• Traditional STP does not support modern highly redundant networks and causes many disabled links
• 4095 VLAN IDs is no longer a scalable solution
• Inadequate table sizes at ToR switch
– Multiple Virtual Machines (VMs) on physical servers cause large Media Access Control (MAC) address tables
– The need of multi-tenant environments over the same physical environment

• On-demand provisioning of resources for multiple customers/tenants
– The need to independently assign tenant MAC addresses and VLAN IDs requiring VLAN ID overlap
• Contiguous Layer 2 network connections for co-location solutions are limited
• Layer 3 solutions can overcome some of these limitations however:

– Increases complexity if multiple tenants use same set of Layer 3 addresses within their network
– VMs cannot migrate across L3 boundaries
VxLAN As A Solution
• VxLAN – Virtual EXtensible Local Access Network (RFC 7348)

– A framework for overlay networks within a virtualized data center
• Provides L2 connectivity isolating multi-tenant’s resources within DC or locations

– Uses “MAC in UDP” tunneling encapsulation allowing the forwarding of L2 frames across L3 networks
– Enables increased scaling by logically isolating virtual applications and tenants
• VxLAN segments provide an isolated overlay environment
– Only VMs within the same VxLAN segment can reach each other
• Each VxLAN segment is identified by a 24 bit segment ID called a VxLAN Network Identifier (VNI)
– 16M VxLAN segments can coexist within the same administrative domain
• Eliminates the limitation of:

– Spanning Tree and classic VLAN Id space
• 16 million VxLAN segments instead of 4095 VLAN Ids
– Inadequacy of MAC table size in ToR switch
VXLAN uses a tunneling method to carry the Layer 2 overlay network traffic over the
Layer 3 network. Communication is established between two tunnel endpoints called
Virtual Tunnel Endpoints (VTEPs). VXLAN is a MAC Address-in-User Datagram Protocol
(MAC-in-UDP) encapsulation, which encapsulates MAC frames at Layer 2 into a Layer
3 UDP header with an outer Ethernet header, outer IP header, outer UDP header, and
VXLAN header. The outer IP header contains the corresponding source and
destination VTEP IP addresses.
VTEPs are the nodes that provide the encapsulation and decapsulation functions and
also map the tenant traffic to the virtual network and vice versa. The tenant’s Layer 2
frame is encapsulated with the Layer 3 UDP header to send it to the remote location
(VTEP). The remote end decapsulates the outer header, and send the original Layer 2
packet to the remote tenant.
Module Summary
• Attendees will now be able to:
– Understand and deploy Link Aggregation Groups (LAG) advanced features
– Describe and configure protected ports
– Configure VLAN and VE interfaces
– Describe and configure aggregated VLANs (Q-in-Q)
– Understand Q-in-Q BPDU tunneling
– Describe and deploy advanced Spanning Tree features
– Understand and configure Multiple Spanning Tree Protocol
– Understand the benefits of Virtual eXtensible Local Area Network (VxLAN)
End of Module 2:
Advanced Layer 2 Features
Appendix A:
Topology Groups
Topology Group Overview
• Topology groups allow multiple VLANs to share a single Layer 2 topology protocol
– Simplifies configuration
– Enhances scalability
• Topology groups are supported for following per VLAN L2 protocols:

– PVST
– Rapid PVST
• If STP, RSTP or MSTP is globally enabled topology groups are not allowed to be configured
on the switch
A topology group is a named set of VLANs that share a Layer 2 topology. Topology
groups simplify configuration and enhance scalability of Layer 2 protocols by allowing
you to run a single instance of a Layer 2 protocol on multiple VLANs.
You can use topology groups with the following Layer 2 protocols:
• Spanning Tree Protocol (STP)
• 802.1W
• Metro Ring Protocol (MRP)
• Virtual Switch Redundancy Protocol (VSRP)
Topology groups simplify Layer 2 configuration and provide scalability by enabling you
to use the same instance of a Layer 2 protocol for multiple VLANs. For example, if a
Ruckus device is deployed in a Metro network and provides forwarding for two MRP
rings that each contain 128 VLANs, you can configure a topology group for each ring.
If a link failure in a ring causes a topology change, the change is applied to all the
VLANs in the ring topology group. Without topology groups, you would need to
configure a separate ring for each VLAN.
In a simple topology with a L2-loop where spanning-tree is enabled to break the loop
and if the topology has 100 VLANs configured and per VLAN spanning tree is chosen,
then we need 100 instances of spanning tree to be running one for each VLAN. This
means that the number of VLANs deployed will be limited by the number of spanning
tree instances supported. Also a higher number of instances can impact CPU
performance. With topology groups one VLAN can be spanning tree enabled
becoming a master VLAN allowing other VLANs to become members of the group.
This allows to scale the number of VLANs past the STP instance limitation and with
much less of a CPU burden.
Topology Group Terminologies
• Master VLAN
– Contains configuration information of any Layer 2 protocols configured for the group
• Parameter changes within this VLAN will be applied to the member VLANs
• Member VLAN
– Additional VLANs that share ports with the master VLAN
• Layer 2 topology resolution is controlled entirely by the master VLAN
– Member VLANs cannot not independently run a loop avoidance protocol
Each topology group contains a master VLAN and can contain one or more member
VLANs and VLAN groups:
• Master VLAN - The master VLAN contains the configuration information for the
Layer 2 protocol. For example, if you plan to use the topology group for MRP,
the topology group master VLAN contains the ring configuration information.
• Member VLANs - The member VLANs are additional VLANs that share ports
with the master VLAN. The Layer 2 protocol settings for the ports in the master
VLAN apply to the same ports in the member VLANs. A change to the master
VLAN Layer 2 protocol configuration or Layer 2 topology affects all the member
VLANs. Member VLANs do not independently run a Layer 2 protocol.
When a Layer 2 topology change occurs on a port in the master VLAN, the same
change is applied to that port in all the member VLANs that contain the port. For
example, if you configure a topology group whose master VLAN contains ports 1/1/1
and 1/1/2, a Layer 2 state change on port 1/1/1 applies to port 1/1/1 in all the
member VLANs that contain that port. However, the state change does not affect port
1/1/1 in VLANs that are not members of the topology group.
Topology Group Port Types
• A port in a topology group is identified as either a control port or a free port
• Control port - A port in the master VLAN, controlled by a Layer 2 protocol

– All member VLANs on a control port are controlled by the master VLAN Layer 2 protocol
– Member VLANs must contain all of the control ports and can contain additional ports
• Free port - A free port is not controlled by the master VLAN’s loop avoidance protocol
– Any ports in the member VLANs that are not also associated with the master VLAN are free ports
– Ports in master VLAN with the loop avoidance protocol disabled are free ports
– Free ports are always in a forwarding state
• As they are not controlled by the master VLAN Layer 2 protocol
A port that is in a topology group can be a control port or a free port:

• Control port - A control port is a port in the master VLAN, and is therefore
controlled by the Layer 2 protocol configured in the master VLAN. The same
port in all the member VLANs is controlled by the master VLAN Layer 2 protocol.
Each member VLAN must contain all of the control ports and can contain
additional ports.
• Free port - A free port is not controlled by the master VLAN Layer 2 protocol.
The master VLAN can contain free ports. (In this case, the Layer 2 protocol is
disabled on those ports.) In addition, any ports in the member VLANs that are
not also in the master VLAN are free ports.
NOTE - Since free ports are not controlled by the master port Layer 2 protocol, they
are assumed to always be in the Forwarding state.
Topology Group Configuration
• Topology groups are configured at the global configuration level
• Define the topology group ID:

ICX(config)# topology-group 1
ICX(conf-topo-group-1)#
• Syntax: [no] topology-group group-id
• Master VLAN is assigned to the topology group

ICX(conf-topo-group-1)# master-vlan 100
• Syntax: [no] master-vlan vlan-id
• Configure member VLANs

ICX(conf-topo-group-1)# member-vlan 200 to 201
• Syntax: [no] member-vlan vlan-id [ to vlan-id | [ vlan-id to vlan-id | vlan-id]... ]
From the global configuration topology groups are configured where the master
VLAN and the member VLANs are identified. Keep in mind that globally enabled STP,
RSTP or MSTP eliminates the possibility of configuring a topology group. Spanning
tree configuring for the master VLAN allows the single instance to manage the
topology group VLAN members. The master VLAN and member VLANs need to be
previously configured before they can be assigned to a topology group.
The master-vlan command adds the master VLAN. The VLAN must already be
configured. Make sure all the Layer 2 protocol settings in the VLAN are correct for
your configuration before you add the VLAN to the topology group. A topology group
can have only one master VLAN.
If you remove the master VLAN (by entering no master-vlan vlan-id ), the software
selects the new master VLAN from member VLANs. For example, if you remove
master VLAN 100 from the example above, the CLI converts member VLAN 200 into
the new master VLAN. The new master VLAN inherits the Layer 2 protocol settings of
the older master VLAN.
If you add a new master VLAN to a topology group that already has a master VLAN,
the new master VLAN replaces the older master VLAN. All member VLANs follow the
Layer 2 protocol settings of the new master VLAN.
Once you add a VLAN or VLAN group as a member of a topology group, all the Layer 2
protocol configuration information for the VLAN or group is deleted. For example, if
STP is configured on a VLAN and you add the VLAN to a topology group, the STP
configuration is removed from the VLAN. Once you add the VLAN to a topology
group, the VLAN uses the Layer 2 protocol settings of the master VLAN.
Topology Groups Show Commands
• Once configured topology group details can be displayed using the command:
ICX# show topology-group

Topology Group 1
=================
master-vlan 100
member-vlan 200 to 201
Number of Member VLANs 2

Common control ports L2 protocol
ethe 1/1/8 802-1W
ethe 1/1/9 802-1W
ethe 1/1/10 802-1W
Per vlan free ports
Display of the topology group provides the master VLAN, L2 protocol type and
member VLANs. Free ports within a specific VLAN or bridge domain are displayed
indicating that the layer 2 protocol is not controlling the status of those ports.
Control Ports vs. Free Ports
• If layer 2 protocols are disabled on any master VLAN controlled ports they become free
ports
STP disabled on port
ICX(config)# vlan 100 in Master VLAN
ICX(config-vlan-100)# spanning-tree 802-1w ethernet 1/1/10 disable
ICX(config-vlan-100)# vlan 200
ICX(config-vlan-200)# tagged e 1/1/11
Port tagged in
L2 protocol is disabled by default on topology group interfaces Member VLAN only
ICX(config-vlan-200)# show topology-group

Topology Group 1
=================
master-vlan 100
member-vlan 200 to 201
Number of Member VLANs 2
Common control ports L2 protocol
ethe 1/1/8 802-1W
ethe 1/1/9 802-1W Port 1/1/10 is free on all VLANs
Per vlan free ports because STP disabled on Master
ethe 1/1/10 Vlan 100
ethe 1/1/10 Vlan 200 VLAN
ethe 1/1/11 Vlan 200
ethe 1/1/10 Vlan 201 Port 1/1/11 is free because it is
not a member of the Master VLAN
All ports associated with the Master VLAN or any changes made to the Master VLAN
are reflected to other VLAN members. Any disabled later 2 ports will cause the ports
to become free ports. Additionally, any ports belonging to member VLANs that are
not part of the Master VLAN will also be identified as free ports.
Topology Group Considerations

You must configure the master VLAN and member VLANs before you configure the
topology group. The topology group must contain a master VLAN and can also
contain individual member VLANs.
If you add a new master VLAN to a topology group that already has a master VLAN:
• The new master VLAN replaces the older master VLAN
• All member VLANs and VLAN groups follow the Layer 2 protocol settings of the
new master VLAN
If you remove the master VLAN, the software selects the new master VLAN from
member VLANs. When creating a new Topology group the first member VLAN added
will be selected as the candidate master VLAN. After a reload of an ICX with existing
Topology groups, the member VLAN with the lowest VLAN ID will be selected as the
candidate master VLAN. The topology group will be deleted if the master is deleted
and there are no member VLANs.
Once you add a VLAN as a member of a topology group, all the Layer 2 protocol
information on that VLAN is deleted.
A default VLAN cannot be a member of a topology group.
End of Appendix A:
Topology Groups
ICX 200 Port Monitoring and Management
Module 3:
Port Monitoring and
Management
Revision 0919 3-1

Module Objectives
– Understand and configure link monitoring

• Interface errors
• Packet InError detection
• Optical Monitoring
• Uni-Directional Link Detection (UDLD)
• Link Fault Signaling (LFS)
• Remote Fault Notification on 1Gbps fiber
• Keep-alive LAG
– Discuss and configure port management capabilities

• Port Flap Dampening
– Describe and execute device health show commands
Revision 0919 3-2

Link Monitoring
Revision 0919 3-3

Interface errors
Revision 0919 3-4

Displaying Interface Errors
• Each interface records traffic along with port errors to help identify issues with the connection
Ruckus# show int e 1/1/3
GigabitEthernet1/1/3 is up, line protocol is up
Errors are divided into
Port up for 138 day(s) 23 hour(s) 9 minute(s) 25 second(s)
Hardware is GigabitEthernet, address is 609c.9fe6.0e42 (bia 609c.9fe6.0e42) input and output
<Output truncated>
300 second input rate: 2749888 bits/sec, 292 packets/sec, 0.27% utilization
300 second output rate: 25224 bits/sec, 28 packets/sec, 0.00% utilization
counters from the last
3079862649 packets input, 3478182772867 bytes, 0 no buffer
Received 2885777 broadcasts, 3803946 multicasts, 3073172926 unicasts
time they were cleared
3 input errors, 3 CRC, 0 frame, 0 ignored
0 runts, 0 giants or from system boot
Relay Agent Information option: Disabled
Protected: No
MAC Port Security: Disabled
This port is not being monitored for queue drops
Egress queues:
Queue counters Queued packets Dropped Packets
0 751458052 0
1
2
0
8
0
0
Errors are accumulative
3
4
0
2492566
0
0 from the last time they
5 935717 0
6
7
0
6568827
0
0
were cleared or from
system boot
Port errors are stored and can be displayed showing not only traffic statistics but also
any errors that may have occurred on the interface. Some errors shown can be from
temporary or older events however if they are incrementing then there is a good
chance there is packet loss impacting the network.
Errors can be seen inbound and outbound as well as inbound CRC and frame errors.
Be aware that if the upstream device is configured to provide cut-through forwarding
the CRC errors shown may be coming from a device further upstream.
Revision 0919 3-5

Display Errors on All Ports
Ruckus# show statistics
Port In Packets Out Packets In Errors Out Errors

1/1/1 113140 135474 0 0
1/1/2 2864391529 959094482 0 0
1/1/3 3106084559 767060354 3 0
1/1/4 40080484 228342953 0 0
1/1/5 5851481 25358325 0 0
1/1/6 12113992 37411887 1 0
1/1/7 1041445 3336769 0 0 Allows for a quick
1/1/8 0 0 0 0
1/1/9
1/1/10
138201386
0
2577505674
0
0
0
0
0
review of all switch
1/1/11
1/1/12
143310150
9529481
2899118413
55678764
0
0
0
0
ports for errors
1/2/1 4021143318 1800799756 0 0
1/2/2 5677510408 5723361613 0 0
1/3/1 0 0 0 0
1/3/2 0 0 0 0
lg1 281511536 5476624087 0 0
mgmt1 23423 2345432 0 0
TOTAL 16300882909 20553828551 4 0
You can quickly look at a switch to tell if any ports are taking errors by using the show
statistics command. By repeating this command you can see if any errors are
incrementing and further investigation may need to take place.
Revision 0919 3-6

Interface Statistics
• The clear statistics command clears many counters including interface statistics
– Helpful to understand if errors shown are recent or from a past issue
Ruckus# clear statistics ethernet 1/1/3

• Syntax:
clear statistics [ dos-attack | traffic-policy traffic-policy-name ]
clear statistics [ rate-counters ] [ethernet unit/slot/port | lag lag-id | management number | tunnel [ number] | unit number ]
– Using the clear unit command clears all statistics from that switch for all counters listed in command for
the identified unit
• The port-statistics-reset-timestamp enable global command can be configured to display

the elapsed timestamp information in output
Ruckus# show statistics ethernet 1/1/13
Port Link State Dupl Speed Trunk Tag Pvid Pri MAC Name
1/1/13 Up Forward Full 1G None No 1 0 748e.f893.065c
Port 1/1/13 Counters:
*Last time counter reset (Elapsed Timestamp): 1 hour(s) 21 minute(s) 12 second(s)
InOctets 50218819740 OutOctets 50216689676
InPkts 63180119 OutPkts 63428168
InBroadcastPkts 5 OutBroadcastPkts 3
<Output truncated>
Clearing the counters during troubleshooting is a common practice to allow you to

see only current counters and also monitor not only the amount of traffic though a
port but also if errors are still taking place.
A helpful tool can be configured allowing you to have a timestamp from the last time
the counters were cleared. This allows you to have a timeframe to which the counters
represent. If the clearing of the counters was very recent and you still show errors,
further troubleshooting me need to take place.
Revision 0919 3-7

Packet InError Detection
Revision 0919 3-8

Packet InError Detection
• Monitoring of a port for InError packets can be enabled by defining the maximum number
of InError packets allowed during the specified sampling interval
– Commonly used in active/passive redundant uplinks to eliminate faulty passive links dropping PDU’s
causing it to revert to forwarding state and creating loops
• InError packets are counted on an ingress frame that has one or more of the following:
– Alignment error
– CRC error
– Oversized frame error
– Internal received MAC address error (Errors that do not fall in the above 3 types)
– Symbol error (includes the fragmented, short, or undersized frames)
• Configuration consists of setting allowed InError packet counts during a sampling interval
• Once the port receives more than the configured number of inError packets in two consecutive sampling intervals
the port becomes error-disabled
It is recommended to use Packet InError Detection only on required ports. heavy CPU
usage can occur if enabled on large number of ports especially if very short sampling
intervals are used.
The inError count configured on the LAG virtual interface of a LAG is inherited by
other member ports of the LAG. However, the LAG ports are individually sampled for
inError packets. Therefore, inError packets on a port disable only that port and not
the entire LAG.
The clear statistics command will clear the counters for inerror packets as well so use
with caution when troubleshooting.
The output of the show interface ethernet command for the affected port will show
the status of the port as “ERR-DISABLED (packet-inerror)”.
Revision 0919 3-9

Configuring Packet InError Detection
• Globally enable errdisable packet-inerror-detect command and define the sampling time
interval (in seconds 2-60)
Ruckus(config)# errdisable packet-inerror-detect interval 3
• Set (optional) recovery cause and interval (10-65535 in seconds Default 300)1
Ruckus(config)# errdisable recovery cause packet-inerror-detect
Ruckus(config)# errdisable recovery interval 500
• Enable the packet-inerror-detect command in interface configuration mode on ports you

want to monitor for inError packets
Ruckus(config)# interface ethernet 1/2/3
Ruckus(config-if-e1000-1/2/3)# packet-inerror-detect 10
– The ethernet interface 1/2/3 becomes disabled if more than 10 InError packets are received in each of
two consecutive 3-second intervals
– After the interface is disabled, it automatically recovers to the enabled state after 500 seconds
Footnote 1: Error disable recovery. (Optional) If you want the ports to automatically
recover from the error-disabled state after the expiry of a configured recovery timer,
run the errdisable recovery cause and errdisable recovery interval commands in
global configuration mode.
When automatic recovery re-enables the port, the port is not in the error-disabled
state, but it can remain down for other reasons, such as the Tx/Rx of the fiber optic
issues, BPDU Guard violation, loop detection violation or any other errdisable state
configured a port is placed into an error-disabled state, which is functionally
equivalent to a disable state. Once in an error-disabled state, the port remains in that
state until it is enabled either automatically or manually. Recovery interval is applied
to all enabled recovery causes.
The following syslog message is generated when a port is error-disabled because of
inError packets.
0d01h38m44s:I:PORT: 1/1/37 is ERR-DISABLED due to number
of packet inErrors exceeded the threshold
Port Re-enable From Error-disabled State
• Enabling an error-disabled port automatically

– As shown previously ports can be set to autorecover using the errdisable recovery cause command in
global configuration mode
• This can be used for many port monitoring options:
Ruckus(config)# errdisable recovery cause
all Enable auto-recovery from all causes
bpdu-tun-threshold Enable auto-recovery from bpdu tunnel threshold error disable state
bpduguard Enable auto-recovery from BPDU guard error disable state
loam-critical-event Enable auto-recovery from LOAM remote critical event disable state
loop-detection Enable auto-recovery from loop-detection error disable state
packet-inerror-detect Enable auto-recovery from packet inError disable state
pvstplus-protect Enable auto-recovery from pvstplus-protect error disable state
• Enabling an error-disabled port manually

– If a recovery statement is not configured for the errdisable state of the interface a manual disable/enable
of the port is necessary for it to recover
There are other recovery options that can be configured however some are
configured under the protocol or the associated feature. For those configuration
options consult the ICX config guide. Recovery interval configured previously effects
all causes that are configured.
Display Errdisable Recovery Configuration

Ruckus# show errdisable recovery
ErrDisable Reason Timer Status
-----------------------------------------------------------------------------
all reason Disabled
bpduguard Enabled
loopDetection Disabled
invalid license Disabled
packet-inerror Enabled
loam-critical-event Disabled
Reload the switch or stack to enable this port in 10G speed Disabled
broadcast traffic threshold exceeded Disabled
multicast traffic threshold exceeded Disabled
unknown unicast traffic threshold exceeded Disabled Recovery options are
stack-port-resiliency Disabled
invalid spx topology Disabled configured on an
pvstplus-protect Disabled
bpdu tunnel threshold exceeded Disabled individual feature
Timeout Value: 500 seconds
PoD Timeout Value: 30 seconds
basis
Interface that will be enabled at the next timeout:
Interface Errdisable reason Time left (sec)
-------------- ----------------- ---------------
Error disable can be configured for many different protocols and events within a
switch. You can display the current status of these by using the show errdisable
revovery command. Additionally if any ports are currently error disabled they will be
displayed at the bottom with details on what caused the errdisable status. It will also
display the remaining time the port will be effected by the errdisable action.
Recovery State For All Conditions
• Use the show errdisable recovery command to display all the default error disable
recovery state for all possible conditions
• Port 1/2/3 is undergoing a recovery

Ruckus# show errdisable recovery
ErrDisable Reason Timer Status
--------------------------------------
all reason Disabled
packet-inerror Enabled
Timeout Value: 500 seconds
Interface that will be enabled at the next timeout:
Interface Errdisable reason Time left (sec)
-------------- ----------------- ---------------
Port 1/2/3 packet-inerror 297
As you can see port 1/2/3 has crossed the threshold configured and has caused it to
be disabled. A counter of the remaining time for the port to remain disabled will be
displayed. If you choose to bypass this time remaining you can manually
disable/enable the port to put it back into active status. Do know that if the threshold
is crossed again the port may be put back into errdisable state.
Error Disable Recovery State By Interface
• The errdisabled state of an interface is displayed in the show interface output and the
show interface brief commands
Ruckus# show interfaces ethernet 1/2/3
GigabitEthernet1/2/3 is ERR-DISABLED (packet-inerror),
line protocol is down
BPDU guard is Enabled, ROOT protect is Disabled
Port down for 0 hours 3 minutes 50 seconds
Hardware is GigabitEthernet, address is 0000.00a0.7100 (bia 0000.00a0.7100)
Configured speed auto, actual unknown, configured duplex fdx, actual unknown
Configured mdi mode AUTO, actual unknown
Member of L2 VLAN ID 2, port is untagged, port state is DISABLED
STP configured to ON, priority is level0, flow control enabled
mirror disabled, monitor disabled
<Output Truncated>
4717256657 packets input, 6172668548255 bytes, 0 no buffer
Received 0 broadcasts, 0 multicasts, 4717256657 unicasts
13452 input errors, 23453245 CRC, 0 frame, 0 ignored
0 runts, 0 giants
Spanning Tree Protocol
Error disable recovery
The port status is also displayed when using the show interface command and will
reflect if the port is active or being disabled along with the reason. A timer of the port
down condition is also displayed allowing you to identify if any known event took
place at the time of disablement.
Recovery State By Port Number and Cause
• Ports that are under an errdisabled state can be displayed using the show errdisable
summary command
– Shows the port number and the reason for errdisable state along with the method used to recover the
port
• Output shows port 1/2/1 is errdisabled for a BPDU guard violation

Ruckus# show errdisable summary
Port 1/2/1 ERR_DISABLED for bpduguard
• A Syslog message is generated after a port is placed into or removed from an errdisable
state
STP: VLAN 50 BPDU-guard port 1/2/1 detect (Received BPDU), putting into err-disable
state
– A Syslog message such as the following is generated after the recovery timer expires
ERR_DISABLE: Interface ethernet 1/2/1, err-disable recovery timeout
And ports that are actively in errdisabled state can be viewed using the show
errdisable summary command. Syslog messages are generated when the port is
transitioned to the disabled and enabled state due to a errdisable event.
Optical Monitoring
Configuring Optical Monitoring
• Digital optical monitoring (DOM) provides diagnostic monitoring for SFP and SFP+ optics
– DOM Support is available on all ICX switches using Ruckus optics which monitors:1
• Optical output/input power
• Temperature
• Laser bias current
• Transceiver voltage
– If monitoring is enabled, console/syslog messages
and SNMP traps are sent2
• Global enabling of monitoring
Ruckus(config)# optical-monitor 5
Enable optical monitoring and set alarm/warn interval to 5 minute(s)
• Specific SPF or SFP+ port optical monitoring3

Ruckus(config-if-e10000-1/1/1)# optical-monitor 10
Enable optical monitoring and set alarm/warn interval to 10 minute(s)
– Syntax: [no] optical-monitor [ alarm-interval ]
• The optional alarm-interval variable sets an interval (minutes) between which alarms or messages are sent
Footnote 1: For a list of supported media types, refer to the Ruckus Ethernet Optics
data sheet.
Footnote 2: Console messages and syslog messages are printed when optical
operating conditions fall below or rise above the SFP, SFP28, SFP+, QSFP, QSFP+, and
QSFP28 manufacturer-recommended thresholds
Footnote 3: Ranges (in minutes) for the alarm-interval parameter for various ICX
switches is 71xx 72xx [3-65535], 74xx 77xx [8-65535]: optical monitoring alarm/warn
interval in minutes, 0 to disable
Normal port configuration options such as range commands can be used when
configuring optical monitoring.
Ruckus(config)# interface ethernet 1/1/1 to 1/1/2
Ruckus(config-mif-e10000-1/1/1-1/1/2)# optical-monitor
You can also review the timer interval for a port by
using:
Ruckus# show optic-timer 1/3/1
Optical monitoring timer Interval for Port 1/3/1 is 10
mins
Interface Module Show Commands
• Optics information for XFP and SFP ports provide detection of temperature, transmit
power, receive power, transmit bias, and current1
– These measurements are indications of overall health of transceivers2
ICX# show optic 1/2/2

Port Temperature Tx Power Rx Power Tx Bias Current
+-----+------------+--------------+--------------+----------------+
1/2/2 30.7070 C -014.8017 dBm -002.3210 dBm 0.166 mA
Normal Low-Alarm Normal Low-Alarm
• Use the show optic threshold command to display threshold settings
Footnote 1: Output description table
Field Description
Port The Ruckus Port Number
Temperature The operating temperature, in degreed

Celsius, of the option transceiver
The alarm status, as described in the
next table.
Tx Power The transmit power signal, in decibels
(dB), of the measured power referenced
to one milliwatt (mW).
next table.
Rx Power The receive power signal, in decibels
(dB), of the measured power referenced
to one milliwatt (mW).
next table.
Tx Bias Current The transmit bias power signal, in
milliamperes (mA).
next table.
Footnote 2: Alarm status value descriptions

For temperature, Tx Power, Rx Power, and Tx Bias Current in the show optic command
output, values are displayed along with their meaning in the following table.
Status Value Description
Low-Alarm Monitored level has dropped below the “low-alarm” threshold set by the
manufacturer of the optical transceiver.
Low-Warn Monitored level has dropped below the “low-warn” threshold set by the
Normal Monitored level is within the “normal” range set by the manufacturer of
the optical transceiver.
High-Warn Monitored level has climbed above the “high-warn” threshold set by the
High-Alarm Monitored level has climbed above the “high-alarm” threshold set by the
Displaying Media Information
• Ensure you have the proper media installed based on distance and purpose
– Verification of DOM media support will also be displayed1
Ruckus# show media validation
Port Supported Vendor Type

----------------------------------------------------------------------
1/3/1 Yes RUCKUS Type : 10GE SR 300m (SFP+)
1/3/2 Yes RUCKUS Type : 10GE SR 300m (SFP+)
• Further details can be obtained using:

Ruckus# show media ethernet 1/3/1
Port 1/3/1: Type : 10GE SR 300m (SFP+)
Vendor: RUCKUS Version: A
Part# : 57-0000075-01 Serial#: AAF2104400017HF
Footnote 1: DOM is supported only on Ruckus optics.
Uni-Directional Link Detection (UDLD)
Uni-Directional Link Detection (UDLD) 149_UDLD.png
• UDLD is a layer two protocol using a keep-alive mechanism that monitors physical ports
providing fast disablement of failed links
– Provides port disablement at both ends of the link
• Available for individual Ethernet ports or LAGs for both fiber optic and twisted-pair
copper1
– Highly useful on fiber where a looped circuit is not present (unlike copper) or CWDM/DWDM multiplexing
technologies are deployed
– Copper links benefit by detecting failures along paths where intermediate devices cause link “sections”
like with media converters
Active Port Media Media Active Port
Converter Fiber Converter
Copper Copper
2 Port Static Trunk 2 Port Static Trunk
Ruckus Switch Copper Copper Ruckus Switch
(UDLD Enabled) Link Failure (UDLD Enabled)
Media Media
Active Port Active Port
Converter Fiber Converter
Footnote 1: Dynamic LAG is not supported. If you want to configure a LAG group that
contains ports on which UDLD is enabled, you must remove the UDLD configuration
from the ports. After you create the LAG group, you can re-add the UDLD
configuration.
Uni-directional Link Detection (UDLD) monitors a link between two devices and
provides a fast detection of link failures. UDLD brings the ports on both ends of the
link down if the link goes down at any point between the two devices. This feature is
useful for links that are individual ports and for LAG links.
UDLD – Features and Considerations
• Default behavior of UDLD-enabled ports is to exchange proprietary health-check packets

once every 500 ms (keep-alive interval)1
– Dead interval is set to 5 keep-alive failures causing a transition of link-disable state of a port
• UDLD Considerations
– Both ends must be compatible devices
– Must be enabled on both ends of a link
– Not available on dynamic LAGs2
– UDLD LAG configuration requires enablement of UDLD on each port of the group individually
Footnote 1: By default, ports enabled for UDLD exchange proprietary health-check

packets once every 500 ms (the keepalive interval). If a port does not receive a
health-check packet from the port at the other end of the link within the keepalive
interval, the port waits for four more intervals. If the port still does not receive a
health-check packet after waiting for five intervals, the port concludes that the link
has failed and takes the port down.
Footnote 2: Dynamic LAG is not supported. If you want to configure a LAG group that
contains ports on which UDLD is enabled, you must remove the UDLD configuration
from the ports. After you create the LAG group, you can re-add the UDLD
configuration. You must also enable and configure the feature on each port of the
LAG individually. When UDLD is enabled on a LAG port, LAG threshold is not
supported.
UDLD Configuration
• Configure UDLD from the global configuration level

– From global config specify the individual port
ICX(config)# link-keepalive ethernet 1/1/10
• To enable UDLD on a LAG group, enter the following commands

ICX(config)# lag red static id 2
ICX(config-lag-red)# ports e 1/1/11 to 1/1/12
LAG red deployed successfully!
ICX(config-lag-red)# ports e 1/1/23 to 1/1/24
ICX(config-lag-red)# exit
– You can specify up to two ports on the same command line
ICX(config)# link-keepalive ethernet 1/1/11 ethernet 1/1/12
ICX(config)# link-keepalive ethernet 1/1/23 ethernet 1/1/24
• Syntax: [no] link-keepalive ethernet { unit/slot/port } [ to unit/slot/port [ ethernet unit/slot/port [ to

unit/slot/port ] ... ] [ vlan vlanID ]
When UDLD is enabled on a LAG port, LAG threshold is not supported
UDLD on Tagged Ports
• By default UDLD sends untagged packets across tagged ports

– Because third-party switches may reject the untagged packets, ports can be configured to tag UDLD
control packets on a specified VLAN1
– For tagged operation, all of the following conditions must be met:
• A VLAN is specified when UDLD is configured
• The port belongs to the configured VLAN as tagged member
• All the devices across the UDLD link are in the same VLAN
• UDLD control messages traverse the link as tagged frames as specified below
ICX(config)# link-keepalive ethernet 1/1/18 vlan 22
• VLANs used for UDLD monitoring must be configured consistently between the connected
devices
Footnote 1: You must configure the same VLANs that will be used for UDLD on all
devices across the network; otherwise, the UDLD link cannot be maintained. UDLD
can be enabled on only one VLAN for tagged port.
Syntax: [no] link-keepalive ethernet { unit/slot/port } [ to unit/slot/port [ ethernet
unit/slot/port [ to unit/slot/port ] ... ] [ vlan vlanID ]
Changing Keepalive Settings
• The keepalive interval can be changed from the default of 500ms to a value from 1 – 60
– Each numeric value represents 100ms1
ICX(config)# link-keepalive interval 3
• The number of keepalive attempts can be changed from the default (7) to a value from 3 –
64
ICX(config)# link-keepalive retries 4
• This configuration will cause a port disable state after 1200ms after failure
• Disabled UDLD ports are recovered by manually disable/enabling the port
Footnote 1: Low UDLD link-keepalive interval and retry options are not
recommended as they are more sensitive and prone to flaps.
The Keepalive Interval and Keepalive Retries can be configured to values other than
the default:
Syntax: [no] link-keepalive interval time
The <num> parameter specifies how often the ports send a UDLD packet. You can
specify from 1 – 60, in 100 ms increments. The default is 5 (500 ms).
Syntax: [no] link-keepalive retries number
The <num> parameter specifies the maximum number of times the port will try the
health check. You can specify a value from 3 – 10. The default is 5.
UDLD Show Commands
• Use the show link-keepalive command to display UDLD including:

– UDLD-enabled ports
– Configured VLANs
– Keepalive Interval
– Keepalive retries
ICX# show link-keepalive

Total link-keepalive enabled ports: 1
Keepalive Retries: 4 Keepalive Interval: 3 * 100 MilliSec.
Port Physical Link Logical Link State Link-vlan

1/1/18 up up FORWARDING 22
• Syntax: show link-keepalive [ ethernet stackid/slot/port ]
Command output fields:

• Total link-keepalive enabled ports - The total number of ports on which UDLD is
enabled.
• Keepalive Retries - The number of times a port will attempt the health check
before concluding that the link is down.
• Keepalive Interval - The number of seconds between health check packets.
• Port - The port number.
• Physical Link - The state of the physical link. This is the link between the ICX port
and the directly connected device.
• Link-keepalive - Shows if the keepalive link is up or down.
• Logical Link - The state of the logical link. This is the state of the link between this
device port and the device port on the other end of the link. If the states of both
Physical Link and Link-keepalive are up, then Logical link is up. If either or both
Physical Link and Link-keepalive states are down, then Logical Link displays “down”.
• Link-vlan – If configured, the VLAN that the port is configured to tag the UDLD
packets with.
UDLD Show Commands (cont.)
• The show link-keepalive command can also be used to display UDLD information for a
specific port
ICX# show link-keepalive ethernet 1/1/18

Current State : up Remote MAC Addr : 609c.9f41.b5ec
Local Port : 1/1/18 Remote Port : 1/1/18
Local System ID : 9f41ca74 Remote System ID : 9f41b5ec
Packets sent : 379 Packets received : 380
Transitions : 0 Link-vlan : 22
Syntax: show link-keepalive ethernet <unit>/<slot>/<portnum>

Command output fields:
• Current State - The state of the logical link. This is the link between this device port
and the device port on the other end of the link.
• Remote MAC Addr - The MAC address of the port or device at the remote end of
the logical link.
• Local Port - The port number on this router.
• Remote Port - The port number on the router at the remote end of the link.
NOTE: The Remote Port number shown in this parameter reflects the port ID sent
by the other router or switch and interpreted by this local router. In cases where
this router interprets the port ID different than the router that sent the port ID, the
port shown can be incorrect.
• Local System ID - A unique value that identifies this router. The ID can be used by
technical support for troubleshooting.
• Remote System ID - A unique value that identifies the router at the remote end of
the link.
• Packets sent - The number of UDLD health-check packets sent on this port.
• Packets received - The number of UDLD health-check packets received on this port.
• Transitions - The number of times the logical link state has changed between up
and down.
• Link-vlan - The VLAN that the port is configured to tag the UDLD packets with.
UDLD Show Commands (cont.)
• If a port is disabled by UDLD, the change is indicated in the output of the show interfaces
brief command
– If the port was already down before UDLD was enabled for the port, the port’s state is listed as None
(config)# show interface brief

Slot/
Port Link State Dupl Speed Trunk Tag Priori MAC
1/1/10 Up LK-DISABLE None None None No level0 00e0.52a9.bb00
Link Fault Signaling (LFS)
Link Fault Signaling (LFS)
• Link Fault Signaling is a physical layer protocol that can be enabled on 10 Gbps Ethernet
ports
– When configured the port can detect and report fault conditions on transmit and receive ports to other
connected device
• Transmit LFS must be enabled on both ends of a link
• When a link fault occurs, the Link and Activity LEDs turn off
No Signal
Rx 10 GbE Tx
e 1/3/1 e 1/3/1
Tx Rx
Link down Disable LED
LFS has an advantage over UDLD by performing its operations in hardware which
lowers CPU usage which also provides improved scalability.
If LFS is configured on an interface, the following Syslog messages are generated

when that interface goes up or down or when the TX or RX fiber is removed from one
or both sides of the link that has LFS configured:
Interface ethernet1/1/1, state down - link down
Interface ethernet1/1/1, state up
The Link and Activity LEDs turn ON when there is traffic traversing the link after the
fiber is installed.
LFS Configuration
• LFS can be enabled on a per port basis using the link-fault-signal command (TX disabled by
default)1
– RX LFS is always enabled by default and cannot be disabled
• LFS configuration only applies to enabling or disabling TX LFS
• Enable LFS on any device prior to connecting the device to ICX platforms
– Any connecting device should have LFS enabled to ensure interoperability
• Syslog messages are generated when the link goes up or down or if TX or RX fiber is
removed from one or both sides of the link
Ruckus(config)# interface e 1/3/1

Ruckus(config-if-e10000-1/3/1)# link-fault-signaling
Footnote 1: When you enable this feature, the transmit port notifies the remote port
whenever the fiber cable is either physically disconnected or has failed. When this
occurs and the feature is enabled, the device disables the link and turns OFF both
LEDs associated with the ports.
LFS Show Commands
• The show interface ethernet command shows the status of an LFS-enabled link1
• This output shows the LFS-enabled link is down because of an error on the remote port as
indicated by “remote fault”
LFS has detected a link
fault on the remote side
ICX # show interface ethernet 1/3/1
10GigabitEthernet1/3/1 is down (remote fault), line protocol is down
Hardware is 10GigabitEthernet, address is 0012.f227.79d8 (bia 0012.f227.79d8)
Configured speed 10Gbit, actual unknown, configured duplex fdx,actual unknown
Member of L2 VLAN ID 1, port is untagged, port state is BLOCKING
BPDU guard is Disabled, ROOT protect is Disabled
Link Fault Signaling is Enabled, Link Error Dampening is Disabled
STP configured to ON, priority is level0
<Output Truncated >
Footnote 1: The Link Fault Signaling is Enabled is added to the output when it is
enabled. If disabled any reference to Link Fault signaling will be completely omitted
from the output.
The show interface brief command will also display the port as down due to LFS error.
ICX# show interface brief
Port Link State Dupl Speed Trunk Tag Pvid Pri MAC
Name
1/2/1 Err-LFS None None None None No 1 0 0012.f227.79d8
Remote Fault Notification on 1Gbps fiber
Remote Fault Notification on 1Gbps fiber
• Remote Fault Notification (RFN) is only available for 1 Gbps Ethernet Fiber ports (enabled
by default)
– When enabled the device disables the link and turns OFF both LEDs associated with the ports
• When enabled the transmit port notifies the remote port whenever the fiber cable is
either:
– Physically disconnected
– Failed
• You can enable/disable RFN:

– Globally, on the entire device
– On a trunk group
– On an individual interface
Remote Fault Notification on 1Gbps Fiber Connections
• For 1Gbps fiber-optic connections, you can optionally configure a transmit port to notify
the receive port whenever the transmit port becomes disabled1
– RFN is enabled by default and can be disabled in an individual interface basis
• To disable RFN on an interface

Ruckus(config)# interface e 1/1/1
Ruckus(config-if-e1000-1/1/1)# gig-default neg-off
• To re-enable RFN
Ruckus(config-if-e1000-1/1/1)# gig-default auto-gig
Footnote 1: When you enable this feature, the transmit port notifies the remote port
whenever the receive fiber cable is either physically disconnected or has failed.
The globally configured Gbps negotiation mode is the default mode for all Gbps fiber
ports. You can override the globally configured default and set individual ports to the
following:
• neg-full-auto - The port first tries to perform a handshake with the other port to
exchange capability information. If the other port does not respond to the
handshake attempt, the port uses the manually configured configuration
information (or the defaults if an administrator has not set the information). This is
the default.
• auto-gig - The port tries to perform a handshake with the other port to exchange
capability information.
• neg-off - The port does not try to perform a handshake. Instead, the port uses
configuration information manually configured by an administrator.
• Manual configuration example:

ICX(config-if-e10000-1/3/1)# speed-duplex 1000-full
Keep-alive LAG
Keep-alive LAG
• Keep-alive LAG link between two devices allows you to configure a LAG for use in keep-
alive applications similar to the UDLD feature
– This configuration does not aggregate ports but uses the LACP PDUs to maintain/monitor the connection
status between the two device ports
• Disables link when LACP messages are not able to be exchanged
– Provide high compatibility between vendor devices due to the use of LACP standard
• Configure a keep-alive LAG

ICX(config)# lag kblue keep-alive
– Syntax: [no] lag lag-name keep-alive
• Add port to the keep-alive LAG

ICX(config-lag-kblue)# ports ethernet 1/1/10
LAG kblue deployed successfully!
For a keep-alive LAG, sFlow can be enabled only at the interface level and not at a
LAG context. To configure sFLow for an interface belonging to the keep-alive LAG,
configure directly under the interface.
Ruckus(config-lag-kblue)# interface ethernet 1/1/10
Ruckus(config-if-e1000-1/1/10)# sflow forwarding
Because deployments of UDLD along with other link monitoring protocols can vary
causing incompatibility. LACP however is primarily used for link aggregation and is a
very stable and widely supported and provides an effective link monitoring tool
especially across different vendor connections. This is highly recommended if you are
using different vendors on each side of the link you want to monitor.
ICX# show lag keep-alive

Total number of LAGs: 2
Total number of deployed LAGs: 2
Total number of trunks created:1 (127 available)
LACP System Priority / ID: 1 / 609c.9fe6.0e40
LACP Long timeout: 90, default: 90
LACP Short timeout: 3, default: 3
=== LAG “kblue" (keep-alive Deployed) ===
LAG Configuration:
Ports: e 1/1/10
Port Count: 1
Lag Interface: 1/1/10
Trunk Type: hash-based
LACP Key: 9990
Deployment:
Port Link State Dupl Speed Trunk Tag Pvid Pri MAC Name
1/1/10 Up Forward Full 1G None No 100 0 609c.9fe6.0e49
Port [Sys P] [Port P] [ Key ] [Act][Tio][Agg][Syn][Col][Dis][Def][Exp][Ope]
1/1/10 1 1 9990 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 1-0000.0000.0000 9 3 5
Port Flap Dampening
Port Flap Dampening
• Port Flap Dampening increases the resilience and availability of the network by limiting the
number of port state transitions on an interface
– Links are monitored for down transitions
• If transitions exceed a specified threshold within a given time the link is physically disabled for the specified time
• When the timer expires the port is re-enabled
• Considerations
– Only down transitions are counted
– Sampling time is started after the first down transition occurs
– UDLD toggles as well as physical link states are counted
– For a LAG the link-error-disable command is applied to the LAG interface1
Footnote 1: Once configured on the LAG virtual interface, the feature is enabled on
all ports that are members of the LAG. You cannot configure port flap dampening on
port members of the LAG.
Port Flap Dampening Configuration
• Configuration can be applied to a physical link or LAG interface

– When configuring you set:
• State toggle threshold (from 1 – 50)
– Amount of times port goes down
• Sampling period (1 - 65535 seconds)
– Time period to monitor down transitions
• Wait period (0 - 65535 seconds)
ICX# show link-error-disable all
– Time to restore port to up state after dampening event Port -----------------Config--------------- ------Oper----
# Threshold Sampling-Time Shutoff-Time State Counter
------- --------- ------------- ------------ ----- -------
1/2/1 4 60 900 Err 2

ICX(config-if-e10000-1/2/1)# link-error-disable 4 60 900
– Syntax: [no] link-error-disable [toggle-threshold sampling-time-in-sec wait-time-in-sec]
• To display the status of a port and its Link error status use:
ICX# show link-error-disable all
toggle-threshold -Specifies the number of times a port link state goes from up to
down and down to up before the wait period is activated. The value ranges from 1
through 50.
sampling-time-in-sec - Specifies the amount of time, in seconds, during which the
specified toggle threshold can occur before the wait period is activated. The default
value is 0 and indicates that the time is forever. The value ranges from 0 through
65535.
wait-time-in-sec - Specifies the amount of time, in seconds, for which the port
remains disabled (down) before it becomes enabled. The value ranges from 0 through
65535. A value of 0 indicates that the port will stay down until an administrative
override occurs.
Device Health Show Commands
Display Chassis Details
• Use the show chassis command to view power supply, fan and temperature information
– Also at the bottom of the output is the chassis MAC address
ICX# show chassis

The stack unit 1 chassis info:
Power supply 1 (AC - PoE) present, status ok
Fanless model
Slot 1 Current Temperature: 81.6 deg-C (Sensor 1), 10.0 deg-C (Sensor 2), 60.7 deg-C (Sensor 3), 62.2
deg-C (Sensor 4)
Slot 2 Current Temperature: NA
Slot 3 Current Temperature: NA
Warning level.......: 100.0 deg-C
Shutdown level......: 109.0 deg-C
Boot Prom MAC : 609c.9fe6.0e40
Management MAC: 609c.9fe6.0e40
The show chassis command displays information on power supplies, fans and
temperature.
The output shows ICX stack unit one with a single, AC PoE power supply installed.
There are 2 fan trays installed and their status is OK. Also note the temperature
readings for the both the management thermal plane and the PoE thermal plane.
Also, the management MAC address is displayed.
Displaying Module Information
• Use the show module command to view each module type installed
– Interface modules should have a status of OK
ICX# show module

Module Status Ports Starting MAC
U1:M1 ICX7150-C12 POE 12-port Management Module OK 12 609c.9fe6.0e40
U1:M2 ICX7150-2X1GC 2-port 2G Module OK 2 609c.9fe6.0e4d
U1:M3 ICX7150-2X10GF 2-port 20G Module OK 2 609c.9fe6.0e4f
The show module command displays the modules currently installed in the unit and
their status.
Display CPU Status
• Use the show cpu command to see CPU usage for an ICX switch
ICX# show cpu-utilization

98 percent busy, from 2 sec ago
1 sec avg: 98 percent busy
The output from the show cpu command displays the usage of the single CPU that
runs on the switch. It is broken up by time periods of 1, 5, 60 and 300 seconds. These
time periods allow better understanding of the duration of a high CPU usage event.
ICX# show cpu-utilization tasks

... Usage average for all tasks in the last 1 second ...
=========================================================
=
Name %
SigHdlrTsk 0
OsTsk 0
TimerTsk 0
FlashTsk 0
MainTsk 0
MportPollTsk 0
IntrTsk 0
itc 0
syslog 0
<Output Truncated>
Display Default Values
• To view the default, maximum, current and configured system-max values use the show
default values command
Ruckus# show default values

sys log buffers:4000 mac age time:300 sec telnet sessions:5
System Parameters Default Maximum Current Configured

ip-filter-port 511 511 511 511
ip-filter-sys 2048 8192 2048 2048
l3-vlan 32 1024 32 32
mac 16384 16384 16384 16384
ip-route 800 1000 800 800
vlan 1024 4095 1024 1024
spanning-tree 32 253 32 32
mac-filter-port 16 16 16 16
mac-filter-sys 64 384 64 64
< Output Truncated>
The table is broken up into the following columns:

• Default – The default maximum value for the parameter that is set at the factory
when the device ships
• Maximum – The maximum value the parameter can be set to
• Current – The current maximum value for the parameter
• Configured – The currently configured maximum for the parameter. Is typically
only different than current if a reset has not taken place since the configuration
was changed. A reboot is required after changing system-max values.
Module Summary
• Attendees should now be able to:
– Understand and configure link monitoring

• Interface errors
• Packet InError detection
• Optical Monitoring
• Uni-Directional Link Detection (UDLD)
• Link Fault Signaling (LFS)
• Remote Fault Notification on 1Gbps fiber
• Keep-alive LAG
– Discuss and configure port management capabilities

• Port Flap Dampening
– Describe and execute device health show commands
End of Module 3:
Port Monitoring and Management
ICX 200 Layer 2 Discovery Protocols
Module 4:
Layer 2 Discovery Protocols
Revision 0919 4-1

Module Objectives
– Describe LLDP supported features and configuration on ICX platforms
– Describe the Ruckus proprietary protocol Foundry Discovery Protocol (FDP) and its configuration
Revision 0919 4-2

Supported Discovery Protocols
• Link Layer Discovery Protocol (LLDP)

– Useful in a mixed vendor environment
– Provides features in VOIP networks using Media Endpoint Discovery
– Location Identification
• Foundry Discovery Protocol (FDP)

– Compatible on all ICX switches
– Intercepts CDP updates providing support for VOIP devices using CDP discovery
Link Layer Discovery Protocol is a standard protocol that is widely used and supported
by many vendors and devices.
Revision 0919 4-3

Link Layer Discovery Protocol
Revision 0919 4-4

Link Layer Discovery Protocol (LLDP)
• ICX devices support LLDP providing:

– Discover other stations in the same LAN segment
• Network Inventory (including multi-vendor environments)
• Can detect speed and duplex mismatches simplifying troubleshooting
• Discover devices with misconfigured or unreachable IP addresses
– Network Management
• Supports network management tools in multivendor environments
• Supports discovery of accurate physical network topologies including connecting ports
• Enables discovery of stations in multi-vendor environments
• Provides device details including model number, version of hardware type, and operating system
• Provides capabilities, such as switch, router, or WLAN access point
• Accessible using a management protocol such as the Simple Network Management

Protocol (SNMP) or CLI
– Data gathered on a ICX device is stored in a standard Management Information Base (MIB)
– Accessible by a Network Management System (NMS)
Ruckus ICX devices support many of the features that LLDP provides including station
discovery, Network management as well as Media Endpoint Discovery attribute
advertisements. As a result directly connected devices can be discovered and
recorded by LLDP advertisements in a multi vendor environment. This aids in
topology mapping and troubleshooting along with inventory. End devices can benefit
from LLDP as well by the advertisement of MED attributes allowing the successful
onboarding of end devices providing emergency service information and VLAN
assignment.
Revision 0919 4-5

LLDP Operating Modes and TLV Types
• LLDP support for the following operating modes on physical interfaces:

– Transmit and Receive LLDP information (System default)
– Transmit LLDP information only
– Receive LLDP information only
• Supported Type Length Value (TLV) types:1

– Basic Management (Management address, port description, system capabilities and system name)
– Mandatory
– Organizationally-specific (802.1 and 802.3)
• Port VLAN ID
• Untagged VLAN ID
• MAC/PHY configuration/status
• Link aggregation
• Maximum frame size
• Power over Ethernet (PoE)
Footnote 1: Type-Length-Value (TLV) object allows protocols to forward optional

information within its protocol communication method. Not only does the provide an
ability for a protocol to quickly adapt to new features a node that do not recognize
the TLV information can skip the TLV information and still parse the remaining
information. Each LLDPDU consists of an untagged Ethernet header and a sequence
of short, variable length information elements known as type/length/value (TLVs).
The management address is an IPv4 address that can be used to manage the device.
If no management address is explicitly configured to be advertised, the ICX device will
use the first available IPv4 address configured on the following types of interfaces, in
the following order of preference:
• Physical port on which LLDP will be transmitting the packet
• Loopback interface
• Virtual routing interface (VE)
• Router interface on a VLAN of which the port is a member
• Other physical interface
If no IP address is configured, the port’s current MAC address will be advertised. To
advertise the IPv4 management address, enter the lldp advertise management-
address ipv4 command.
ICX(config)# lldp advertise management-address ipv4 10.157.2.1
ports e 1/4
Other TLVs can be disabled or specified to the admin preference. Refer to the config
guide for specific configuration needs.
Revision 0919 4-6

Transmit mode: An LLDP agent initiates the transmission of LLDP packets whenever
the transmit countdown timing counter expires, or whenever LLDP information has
changed. When a transmit cycle is initiated, the LLDP manager extracts the MIB
objects and formats this information into TLVs. The TLVs are inserted into an LLDPDU,
addressing parameters are prepended to the LLDPDU, and the information is sent out
LLDP-enabled ports to adjacent LLDP-enabled devices.
Receive mode: When an LLDP agent receives LLDP packets, it checks to ensure that
the LLD PDUs contain the correct sequence of mandatory TLVs, then validates
optional TLVs. If the LLDP agent detects any errors in the LLDPDUs and TLVs, it drops
them in software. TLVs that are not recognized but do not contain basic formatting
errors, are assumed to be valid and are assigned a temporary identification index and
stored for future possible alter retrieval by network management. All validated TLVs
are stored in the neighbor database.
Revision 0919 4-7

LLDP Considerations
• Cisco Discovery Protocol (CDP) and Foundry Discovery Protocol (FDP) run independently of
LLDP1
– These discovery protocols can run simultaneously on the same device
• LLDP packets have the standard Multicast Destination MAC address (01:80:c2:00:00:0e)
and are sent with highest priority (7)
• By default, the ICX device limits the number of neighbors per port to four2
• LLDP advertisements are limited to a single 1500 byte packet
Footnote 1: Details about CDP and FDP are discussed later in this module.
Footnote 2: If the advertisements by the neighbor exceed the maximum value of the
neighbor per port or if it exceeds the maximum neighbors configured at the global
level then the new advertisements will be dropped. ICX devices stagger transmission
of LLDP packets on different ports to minimize any high-usage spikes to the CPU. To
change the maximum number of neighbors for which LLDP data is retained for the
entire system, use the lldp max-total-neighbors command at the global config
prompt. Default LLDP neighbors per device is 392 and the configurable range is range
of 16 to 8192. To change the maximum number of LLDP neighbors per port, use the
LLDP max-neighbors-per-port command. Default per port is 4 and the configurable
range is 1 to 64.
LLDP typically uses Ethernet to forward its LLDPPDUs. The Ethernet type used for
LLDP is 0x88cc
Revision 0919 4-8

LLDP Configuration
• Disabling LLDP (enabled by default)

ICX(config)# no lldp run
• Re-enable LLDP
ICX(config)# lldp run
• Disabling specific ports from LLDP using the default (send/receive) mode
ICX(config)# no lldp enable ports ethernet 1/1/1
• Enabling transmit or receive mode only1

ICX(config)# no lldp enable ports ethernet 1/1/4 1/1/5 1/1/6
ICX(config)# lldp enable transmit ports ethernet 1/1/4 1/1/5
ICX(config)# lldp enable receive ports ethernet 1/1/6
Footnote 1: Ports enabled for LLDP using the default mode requires removing ports
from the default before placing them in transmit or receive mode.
By default, Ruckus devices do not accept tagged LLDP packets from other vendor
devices. To enable support for tagged LLDP packets:
ICX(config)# lldp tagged-packets process
When enabled, the device accepts incoming LLDP tagged packets if the VLAN tag
matches with a configured VLAN on the port, the default VLAN for a tagged port.
Specify the maximum number of LLDP neighbors per device.
ICX(config)# lldp max-total-neighbors 500
This example changes the maximum number of LLDP neighbors for the entire device
to 500
Specify the maximum number of LLDP neighbors per port .
ICX(config)# lldp max-neighbors-per-port 6
This example changes the maximum number of LLDP neighbors per port to 6.
Revision 0919 4-9

LLDP- Media Endpoint Discovery (MED)
• Extension to LLDP
– Enables advanced LLDP features
– Discovery between Network Connectivity devices
and media Endpoints
• Example: IP telephones, softphones, VoIP gateways
and conference bridges
• Benefits:
– Vendor-independent management capabilities
• Enables different IP telephony systems to interoperate
– Automatic deployment network policies
• Layer 2 and Layer 3 QoS policies and Voice VLANs
– Supports E-911 Emergency Call Services (ECS) for IP
telephony
– Collects Endpoint inventory information
– Network troubleshooting
• Helps to detect improper network policy configuration
An LLDP-MED class specifies an Endpoint type and its capabilities. An Endpoint can
belong to one of three LLDP-MED class types:
• Class 1 (Generic endpoint) - A Class 1 Endpoint requires basic LLDP discovery
services, but does not support IP media nor does it act as an end-user
communication appliance. A Class 1 Endpoint can be an IP communications
controller, other communication-related server, or other device requiring basic
LLDP discovery services.
• Class 2 (Media endpoint) - A Class 2 Endpoint supports media streams and may or
may not be associated with a particular end user. Device capabilities include media
streaming, as well as all of the capabilities defined for Class 1 Endpoints. A Class 2
Endpoint can be a voice/media gateway, conference, bridge, media server, etc.
• Class 3 (Communication endpoint) - A Class 3 Endpoint supports end user IP
communication. Capabilities include aspects related to end user devices, as well as
all of the capabilities defined for Class 1 and Class 2 Endpoints. A Class 3 Endpoint
can be an IP telephone, softphone (PC-based phone), or other communication
device that directly supports the end user.
Discovery services defined in Class 3 include location identifier (ECS/E911)
information and inventory management.
The LLDP-MED device class is advertised when LLDP-MED is enabled on a port.
LLDP MED Options
• MED specific options are available

– Fast-start-repeat-count
• Enables a Network Connectivity Device to initially advertise itself at a faster rate (in seconds) for a specified time
when an LLDP-MED Endpoint has been newly detected
– Location-id
• enables the Ruckus device to set the physical location that an attached Class III Endpoint will use for location-based
applications
– Network-policy
• Defines an Endpoint VLAN configuration (VLAN type and VLAN ID) and associated Layer 2 and Layer
3 priorities that apply to a specific set of applications on a port
ICX(config)# lldp med ?

fast-start-repeat-count Specify the LLDP-MED fast start transmit count
location-id Define an LLDP-MED location ID
network-policy Define an LLDP-MED network policy
LLDP MED enhancement provides onboarding assistance and information to end

devices by providing an configurable fast start repeat count, location-id, and network
policy options
Fast start repeat: Allows for a more frequent advertisements allowing connecting
devices the information they need to successfully onboard on the network. To set (in
seconds) the amount of time you want the switch to send higher frequency of
packets use the global command lldp med fast-start-repeat-count amount seconds
Location-id: Plays an important part for emergency services. This feature is important
for applications such as IP telephony, for example, where emergency responders
need to quickly determine the physical location of a user in North America that has
just dialed 911. Configuration allows for configuration based on the perspective of
either the client, dhcp-server or a network element that is closest to the client
device.
Network policy: Defines an Endpoint VLAN configuration (VLAN type and VLAN ID)
and associated Layer 2 and Layer 3 priorities that apply to a specific set of
applications on a port.
lldp med network-policy application application-type tagged vlan vlan-id priority priority-
value dscp dscp-value ports { all | [ ethernet unit/slot/port [ to unit/slot/port ] ... ] }
lldp med network-policy application application-type untagged dscp dscp-value ports {
all | [ ethernet unit/slot/port [ to unit/slot/port ] ... ] }
lldp med network-policy application application-type priority-tagged priority priority-
value dscp dscp-value ports { all | [ ethernet unit/slot/port [ to unit/slot/port ] ... ] }
LLDP MED Location ID
• Defining a location ID
– Extension enables the Ruckus device to set the physical location that an attached Class III Endpoint will
use for location-based applications
– For each port, you can define one or more of the following location ID formats:
• Geographic location (coordinate-based)
• Civic address
• Emergency Call Services (ECS) Emergency Location Identification Number (ELIN)
• To configure a civic address-based location for LLDP-MED within the global configuration
mode use:1
ICX(config)# lldp med location-id civic-address refers-to client country US
elem 1 CA elem 3 "Sunnyvale“ elem 6 “350 W Java Dr" elem 24 94089 elem 27 5
elem 28 151 elem 29 office elem 23 "John Doe"
Footnote 1: Elements are attributes that are defined in the civic address and are
listed in the following notes pages. Each element value is associated with a specific
element of the address.
Graphic location addressing is associated with a lat/long attribute with additional
values shown below.
ICX(config)# lldp med location-id coordinate-based
latitude 41.87884 resolution 18 longitude 87.63602
resolution 18 altitude floors 103 resolution 30 wgs84
The above configuration shows the following:
Latitude is 41.87884 degrees north (or 41.87884 degrees) - Longitude is 87.63602
degrees west (or 87.63602 degrees1
The location is inside a structure, on the 103rd floor
The WGS 84 map was used as the basis for calculating the location
The Emergency Call Service (ECS) location is used specifically for Emergency Call
Services applications.
ICX(config)# lldp med location-id ecs-elin 4083335745
To display the conferred ECS details use the show lldp localinfo command.
+ MED Location ID
Data Format: ECS ELIN
Value : 4083335745
Civic address
Description Acceptable values / examples
(CA) type
The ISO 639 language code used for
0 Language
presenting the address information.
National subdivisions (state, canton, Japan - Metropolis
1
region, province, or prefecture) United States – State
County, parish, gun (JP), or district Canada - County

2
(IN) Korea – County
Japan - Ward or village

3 City, township, or shi (JP)
United States - City or town
City division, borough, city district, Korea - Urban district

4
ward, or chou (JP) United States - N/A
Korea - Neighborhood
5 Neighborhood or block
United States - N/A
Canada - Street
6 Street
Japan – Block
N (north), E (east), S (south), W (west), NE,
16 Leading street direction
NW, SE, SW
N (north), E (east), S (south), W (west), NE,
17 Trailing street suffix
NW, SE, SW
United States Postal Service
18 Street suffix
Example: Ave, Place
19 House number The house number (street address)
House number suffix A modifier to Additional location information An
the house number. It does not unstructured string name that conveys
include parts of the house number. additional information about the location.
Example: A, ½ Landmark or vanity Example: west wing Name (residence and
address A string name for a location. office occupant) Identifies the person or
20
It conveys a common local organization associated with the address.
designation of a structure, a group of Example: Textures Beauty Salon
buildings, or a place that helps to Postal / zip code The valid postal / zip code
locate the place. for the address. Example: 95054-1234
Example: UC Berkeley
The name of a single building if the street
address includes more than one building or
25 Building (structure)
if the building name is helpful in identifying
the location. Example: Law Library
Civic address
Description Acceptable values / examples
(CA) type
The name or number of a part of a
structure where there
are separate administrative units, owners,
or tenants,
such as separate companies or families
26 Unit (apartment, suite)
who occupy that
structure. Common examples include suite
or apartment
designations.
Example: Apt 27
27 Floor Example: 4
The smallest identifiable subdivision of a
28 Room number
structure. Example: 7A
Place type The type of place
described by the civic coordinates.
For
example, a home, office, street, or
other public space.
Example: Office
29 Postal community name When the
postal community name is defined,
the civic
community name (typically CA type
3) is replaced by this
value.
Example: Alviso
When a P.O. box is defined, the street
address components (CA types 6, 16, 17,
31 Post office box (P.O. box)
18, 19, and 20) are replaced with this
value. Example: P.O. Box 1234
An additional country-specific code that
identifies the location. For example, for
Japan, this is the Japan Industry
32 Additional code Standard (JIS) address code. The JIS
address code provides a unique address
inside of Japan, down to the level of
indicating the floor of the building.
The script (from ISO 15924 [14]) used to
present the address information.
128 Script Example: Latn NOTE If not manually
configured, the system assigns
the default value Latn.
Defining an LLDP-MED Network Policy
• Network policies apply to applications that have specific real-time network policy
requirements, such as interactive voice or video services
– Intended to run on links between Network Connectivity devices and Endpoints
– Can provide VLAN assignment as well as priority settings for an end device
• To define an LLDP-MED network policy for an Endpoint:

ICX(config)# lldp med network-policy application voice tagged vlan 99 priority
3 dscp 22 port e 1/1/6
• The network policy advertisement will appear similar to the following on the remote
device, and in the CLI display output on the Ruckus ICX
ICX# show lldp local-info
+ MED Network Policy
Application Type : Voice
Policy Flags : Known Policy, Tagged
VLAN ID : 99
L2 Priority : 3
DSCP Value : 22
Endpoints will advertise a policy as "unknown" in the show lldp neighbor detail
command output, if it is a policy that is required by the Endpoint and the Endpoint
has not yet received it.
LLDP SNMP Options
• By default, LLDP SNMP notifications and corresponding syslog messages are disabled
– Notifications are set based on identified ports
ICX(config)# lldp enable snmp notifications ports ?
all All LLDP-capable ports
ethernet Ethernet port
• LLDP-MED topology changes can be enabled providing syslog messages when an endpoint
neighbor entry is added or removed1
ICX(config)# lldp enable snmp med-topo-change-notifications ports ethernet

1/1/4 to 1/1/6
Footnote 1: When you enable LLDP-MED SNMP notifications, corresponding syslog

messages are enabled as well.
By default LLDP does not create SNMP/syslog messages when enabled. To have syslog
entries for received LLDP messages the lldp enable snmp command is required. This
can be applied to all or a specific set of ports. You can specify a list of ports, separated
by a space, or a range of ports, or you can combine lists and ranges.
Additionally you can enable SNMP LLDP-MED endpoint notifications as well
specifying the ports you would like it to be applied to.
LLDP Show Commands
• You can use the following CLI show commands to display information about LLDP settings
and statistics:
– show lldp – Displays a summary of the LLDP configuration
– show lldp statistics – Displays LLDP global and per-port statistics
– show lldp neighbors – Displays a list of the current LLDP neighbors
– show lldp neighbors detail – Displays the details of the latest advertisements received from
LLDP neighbors
• Clearing LLDP statistics

ICX# clear lldp statistics
LLDP Statistics
ICX# show lldp statistics
Last neighbor change time: 1 day(s) 3 hour(s) 34 minute(s) 12 second(s) ago
Neighbor entries added : 67

Neighbor entries deleted : 61
Neighbor entries aged out : 40
Neighbor advertisements dropped : 0
Port Tx Pkts Rx Pkts Rx Pkts Rx Pkts Rx TLVs Rx TLVs Neighbors

Total Total w/Errors Discarded Unrecognz Discarded Aged Out
1/1/1 308290 308277 0 0 308277 0 1
1/1/2 308303 308287 0 0 308287 0 2
1/1/3 308288 308301 0 0 308301 0 0
1/1/4 279732 0 0 0 0 0 0
1/1/5 154233 0 0 0 0 0 0
1/1/6 279737 0 0 0 0 0 0
1/1/7 28562 0 0 0 0 0 0
1/1/8 0 0 0 0 0 0 0
1/1/9 278955 0 0 0 0 0 0
1/1/10 0 0 0 0 0 0 0
< Output Truncated>
The Table below describes the fields above in more detail.
This field... Displays...

Last neighbor change The elapsed time (in hours, minutes, and seconds) since a neighbor last advertised
time information. For example, the elapsed time since a neighbor was last added, deleted, or
its advertised information changed.
Neighbor entries added The number of new LLDP neighbors detected since the last reboot or since the last time
the clear lldp statistics all command was issued. This number includes the number
entries added after timing out or aging out.
Neighbor entries The number of LLDP neighbors deleted since the last reboot or since the last time the
deleted clear lldp statistics all command was issued. This number includes the number of
entries deleted after timing out or aging out.
Neighbor entries aged The number of LLDP neighbors dropped on all ports after the time-to-live expired.
out Note that LLDP entries age out naturally when a port’s cable or module is disconnected
or when a port becomes disabled. However, if a disabled port is re-enabled, the system
will delete the old LLDP entries.
Neighbor The number of valid LLDP neighbors the device detected, but could not add. This can
advertisements occur, for example, when a new neighbor is detected and the device is already
dropped supporting the maximum number of neighbors possible. This can also occur when an
LLDPDU is missing a mandatory TLV or is not formatted correctly.
Port The local port number.
Tx Pkts Total The number of LLDP packets the port transmitted.
Rx Pkts Total The number of LLDP packets the port received.
Rx Pkts w/Errors The number of LLDP packets the port received that have one or more detectable errors.
Rx Pkts Discarded The number of LLDP packets the port received then discarded.
Rx TLVs Unrecognz The number of TLVs the port received that were not recognized by the LLDP local agent.
Unrecognized TLVs are retained by the system and can be viewed in the output of the
show LLDP neighbors detail command or retrieved through SNMP.
Rx TLVs Discarded The number of TLVs the port received then discarded.
Neighbors Aged Out The number of times a neighbor’s information was deleted because its TTL timer
expired.
LLDP Neighbors and TLV Advertisements

ICX# show lldp neighbor
Lcl Port Chassis ID Port ID Port Description System Name
1/1/1 903a.721c.10a0 903a.721c.10a0 eth0 Ruckus-1-R510
1/1/2 94f6.6518.16f0 94f6.6518.16f0 eth0 Ruckus-2-R510
1/1/3 903a.721c.0e50 903a.721c.0e50 eth0 Ruckus-3-R510
• LLDP TLVs advertised by the Ruckus device

– When LLDP is enabled on a global basis, the Ruckus device will automatically advertise the following
information, except for the features noted:
– General system information: • 802.1 capabilities:

• Management address – VLAN name (not automatically advertised)
• Port description – Untagged VLAN ID
• System capabilities • 802.3 capabilities:
• System description (not automatically advertised) – Link aggregation information
• System name – MAC/PHY configuration and status
– Maximum frame size
– Power-via-MDI information (not automatically advertised)
The Below Table describes the fields above in more detail.

Port ID The identifier for the port.
Brocade devices use the permanent MAC address associated with the port as the port ID.
Port The description for the port.
Description Brocade devices use the ifDescr MIB object from MIB-II as the port description.
System Name The administratively-assigned name for the system.
Brocade devices use the sysName MIB object from MIB-II, which corresponds to the CLI
hostname command setting.
NOTE: A tilde (~) at the end of a line indicates that the value in the field is too long to display in
full and is truncated.
LLDP Neighbors
ICX# Local port: 1/1/1
Neighbor: 609c.9fe6.0e4b, TTL 116 seconds
+ Chassis ID (MAC address): 609c.9fe6.0e40
+ Port ID (MAC address): 609c.9fe6.0e4b
+ Time to live: 120 seconds
+ System name : "Second_Floor_MDF"
+ Port description : "GigabitEthernet1/1/12"
+ System capabilities : bridge
Enabled capabilities: bridge
+ 802.3 MAC/PHY : auto-negotiation enabled
Advertised capabilities: 10BaseT-HD, 10BaseT-FD, 100BaseTX-HD,
100BaseTX-FD, fdxSPause, fdxBPause,
1000BaseT-HD, 1000BaseT-FD
Operational MAU type : 1000BaseT-FD
+ 802.3 Power via MDI: PSE port, power enabled, class 0
Power Pair : A (not controllable)
<Output Truncated>
+ MED Extended Power via MDI
Power Type : PSE device
Power Source : Unknown Power Source
Power Priority : Low (3)
Power Value : 0.0 watts (PSE equivalent: 0 mWatts)
+ Port VLAN ID: 100
+ Management address (IPv4): 10.1.1.254<Output Truncated>
The Below Table describes the fields above in more detail.

Port ID The identifier for the port.
Brocade devices use the permanent MAC address associated with the port as the port ID.
Port The description for the port.
Description Brocade devices use the ifDescr MIB object from MIB-II as the port description.
System Name The administratively-assigned name for the system.
Brocade devices use the sysName MIB object from MIB-II, which corresponds to the CLI
hostname command setting.
NOTE: A tilde (~) at the end of a line indicates that the value in the field is too long to display in
full and is truncated.
Limiting LLDP Advertisements
• Using the show lldp local-info command displays the details of the Link Layer Discovery
Protocol (LLDP) advertisements on a per port basis
– LLDP Advertisements can be limited by port using the lldp advertise command
• Note: Many LLDP TLVs are advertised by default and will need to be explicitly disabled
– Examples:1
ICX(config)# no lldp advertise
link-aggregation Advertise 802.3 link aggregation information
mac-phy-config-status Advertise 802.3 MAC/PHY configuration/status
management-address Advertise a management address
max-frame-size Advertise 802.3 maximum frame size
med-capabilities Advertise LLDP-MED capabilities
med-location-id Advertise LLDP-MED location id information
med-network-policy Advertise LLDP-MED network policy information
med-power-via-mdi Advertise LLDP-MED power-via-MDI information
port-description Advertise port description
port-id-subtype Advertise advertise lldp port id subtype
port-vlan-id Advertise 802.1 port untagged VLAN id (PVID)
power-via-mdi Advertise 802.3 power-via-MDI information
system-capabilities Advertise system capabilities
system-description Advertise system description
system-name Advertise system name
vlan-name Advertise 802.1 VLAN name
Footnote 1: For a full list of LLDP advertising control options refer to the ICX
Management guide. Note that many of these are advertised automatically therefore
will need to be disabled on ports you do not want the information shared. Below is
an example of disabling of the system name being advertised on Ethernet 1/1/2.
ICX(config)# no lldp advertise system-name ports e 1/1/2
ICX(config)# show lldp local-info ports e 1/1/1 to 1/1/2

Local port: 1/1/1
+ Chassis ID (MAC address): 609c.9fe6.0858
+ Port ID (MAC address): 609c.9fe6.0858
+ System name : "Lab-ICX01"
<Output Truncated>
Local port: 1/1/2
+ Chassis ID (MAC address): 609c.9fe6.0858
+ Port ID (MAC address): 609c.9fe6.0859
<Output Truncated>
LLDP Default Behavior
Global Task Default Behavior or value when LLDP is enabled

Enabling LLDP on a global basis Default
Specifying the maximum number of LLDP neighbors per device Automatically set to 392 neighbors per device
Specifying the maximum number of LLDP neighbors per port Automatically set to 4 neighbors per port
Enabling SNMP notifications and syslog messages Disabled
Changing the minimum time between SNMP traps and syslog Automatically set to 2 seconds when SNMP notifications and syslog
messages messages for LLDP are enabled
When LLDP transmit is enabled, by default the Ruckus device
automatically advertises LLDP capabilities, except for the system
Enabling and disabling TLV advertisements description, VLAN name, and power-via-MDI information, which
may be configured by the system administrator. Also, if desired, you
can disable the advertisement of individual TLVs.
Changing the minimum time between LLDP transmissions Automatically set to 2 seconds
Changing the interval between regular LLDP transmissions Automatically set to 30 seconds
Changing the holdtime multiplier for transmit TTL Automatically set to 4
Changing the minimum time between port reinitializations Automatically set to 2 seconds
By default, if a port is 802.1X-enabled, the transmission and reception of LLDP

packets takes place only while the port is authorized. The lldp-pass-through
command overrides this behavior.
Foundry Discovery Protocol
Foundry Discovery Protocol (FDP)
• FDP provides neighbor discovery of directly connected devices by sending Layer 2 frames
to MAC address 00-00-00-CC-CC-CC
• Periodically advertises information including the following:

– Hostname (device ID)
– Product platform and capability
– Software version
– VLAN and Layer 3 protocol address information of the port sending the update. IP, IPX, and AppleTalk
Layer 3 information is advertised
– Intercepts and displays the contents of CDP packets
• FDP is disabled by default

– Devices in this default state or that do not support FDP, passes the update through the device at Layer 2
Enabling FDP
• FDP can be enabled globally or at the interface level providing greater control and security
• Globally enable configure:
ICX(config)# fdp run
– Enabling FDP at the interface level

• By default, FDP is enabled at the interface level after FDP is enabled globally
• You can disable and re-enable FDP on individual ports
• Disable FDP by entering commands such as the following:
ICX(config)# int e 1/1/2
ICX(config-if-e10000-1/1/2)# no fdp enable
• Enable or re-enable FDP on a specific interface enter:

ICX(config-if-e10000-1/1/2)# fdp enable
FDP – Update and Hold Timer
• FDP sends an FDP update every 60 seconds

– Value can be changed from 5 - 900 seconds
ICX(config)# fdp timer 120
• FDP update holds the information until either:

– The device receives a new update
– 180 seconds have passed since receipt of the last update1
– Once either of these events occurs, the device discards the update
– Value can be changed from 10 - 255 seconds (Default is 180)
ICX(config)# fdp holdtime 250
Footnote 1: This is three times the default update timer
FDP – CDP Handling
• Cisco Discovery Protocol (CDP) packets are used by Cisco devices to advertise themselves
to other Cisco devices
– ICX devices forward these packets without examining their contents (Default)
– An ICX device can intercept and display the contents of CDP version 1 and version 2 packets1
• Interception of CDP packets can be enabled globally or per interface2

– Globally
ICX(config)# cdp run
– Interface Level
ICX(config-if-e10000-1/1/2)# cdp enable
Footnote 1: The Ruckus device can interpret only the information fields that are
common to both CDP version 1 and CDP version 2 . When you enable interception of
CDP packets, the Ruckus device drops the packets and will not provide the forwarding
of packets like it did when disabled.
Footnote 2: CDP runs as a companion to the FDP protocol therefore for CDP
interception to take place FDP needs to be enabled for it to function.
CDP complementary to the IEEE 802.1AB standard Link Layer Discovery Protocol
(LLDP) that is implemented by multiple vendors and is functionally similar to CDP.
ICX# show fdp interface

Sending FDP packets every 60 seconds
Holdtime is 180 seconds
GigabitEthernet1/1/1 is up, FDP is enabled, and CDP is enabled
FDP Show Commands
• Displaying Neighbor Information1
ICX# show fdp neighbors

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
(*) indicates a CDP device
Device ID Local Interface Holdtm Capblty Platform PortID

-------------- --------------- ------ ------- --------- ------
(*) IDF-3750-2 ethernet1/1/12 132 R S I cisco WS-C37 GigabitEthernet1/0/4
(*)vm.cloudpatheduca ethernet1/2/2 129 S VMware ESX vmnic0
– Syntax: show fdp neighbors [ detail | ethernet stack-id/slot/port ]
Footnote 1: If CDP intercept is enabled on an ICX device the information and statistics
gathered is displayed using the same commands described in the following slides.
Displaying CDP Information
• ICX displays the following CDP information:

– Cisco neighbors
– CDP entries for all Cisco neighbors or a specific neighbor
– CDP packet statistics
ICX# show fdp entry *

Device ID: Second_Floor_MDF
configured as tag-type8100
Entry address(es):
IP address: 10.1.1.254
Platform: ICX7150-C12 Switch, Capabilities: Switch
Interface: ethernet1/1/1
Port ID (outgoing port): ethernet1/1/12 is UNTAGGED in VLAN 100
Holdtime : 169 seconds
Ruckus Wireless, Inc. ICX7150-C12-POE, IronWare Version 08.0.80dT211 Compiled
on Nov 20 2018 at 00:09:55 labeled as SPS08080d
<Output Truncated>
ICX# show fdp neighbors detail

Device ID: 3750-2
Entry address(es):
IP address: 0.0.0.0
Platform: cisco WS-C3750G-48TS, Capabilities: Router,
Switch, IGMP
Interface: ethernet1/1/12, Port ID (outgoing port):
GigabitEthernet1/0/4
Cisco IOS Software, C3750 Software (C3750-IPSERVICES-M),
Version 12.2(35)SE5, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Thu 19-Jul-07 19:15 by nachen
Device ID: vm.cloudpatheducation.com
Entry address(es):
IP address: 10.1.2.1
Platform: VMware ESX, Capabilities: Switch
Interface: ethernet1/2/2, Port ID (outgoing port):
vmnic0
Releasebuild-5969303
FDP Show Commands – FDP and CDP Statistics
• Displaying FDP and CDP packet counters

ICX-07# show fdp traffic
CDP/FDP counters:
Total packets output: 6, Input: 5
Hdr syntax: 0, Chksum error: 0, Encaps failed: 0
No memory: 0, Invalid packet: 0, Fragmented: 0
Internal errors: 0
• Clearing information received in FDP and CDP updates

– Clearing FDP and CDP neighbor information
ICX# clear fdp table
– Clearing FDP and CDP statistics
ICX# clear fdp counters
Module Summary
– Describe LLDP supported features and configuration on ICX platforms
– Describe the Ruckus proprietary protocol Foundry Discovery Protocol (FDP) and its configuration
End of Module 4:
Layer 2 Discovery Protocols
ICX 200 Multi-Chassis Trunking
Module 5:
Multi-Chassis Trunking
Revision 0919 5-1

Module Objectives
• After completing this lesson, attendees should be able to:
– Describe the purpose and components of Multi-Chassis Trunking
– Explain how to configure an MCT cluster
– Describe the different methods of adding MCT clients to a cluster
– Use show commands to review and analyze status of MCT cluster operations
– Explain MCT failover scenarios
– Describe MCT operations when used with VRRP-E
Revision 0919 5-2

Multi-Chassis Trunk (MCT)
Revision 0919 5-3

Multi-Chassis Trunk (MCT) Overview
• Expands the features of LAGs by:

– 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 re-allocation of traffic
• Currently supported on ICX 7650, 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.
Revision 0919 5-4

MCT Terminology
• Inter-Chassis Link (ICL) – a single-port or multi-port 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
• Cluster Client Edge Port (CCEP) - ports on a

cluster switch connecting it with cluster client
• Cluster Edge Port (CEP) - a regular non-MCT

port on a single MCT cluster switch
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
ICL, two control routing protocols are being managed. One is CCP which is Cluster
Communication Protocol based on TCP. The other is the MAC Database Update
Protocol (MDUP). It is recommended that you set up the 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 (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, including Cluster ID, RBridge
ID, Keep Alive time, Hold time, and Fast failover. Once keep alive messages are
exchanged, CCP will migrate into an UP state.
MDUP is used to synchronize 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 the other switch in the MCT cluster.
Revision 0919 5-5

MCT Terminology (cont.)
• RBridge
– Any device involved in the MCT cluster including peer and client
• RBridge ID
– A 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 distributed across the MCT pair
• MCT Session VLAN

– A VLAN used to provide Cluster Communication Protocol (CCP) operations
• MCT Keep-alive VLAN

– A VLAN configured to provide alternative communication path between MCT peers during ICL/CCP failure
Cluster Edge Port (CEP) is a port on an MCT cluster device that belongs to the MCT
VLAN and connects to a switch, router or host but is neither a CCEP nor an ICL. CEPs
do not benefit from the MCT features, they allow connectivity to single homed clients
or routed interfaces.
An RBridge is any device involved in the MCT cluster, including peer and clients. Each
RBridge in the cluster has a unique ID.
The RBridge ID is a value assigned to MCT cluster devices and clients that uniquely
identifies them and helps associate learned MAC addresses with MCT clients.
Cluster RBridge IDs cannot conflict with any client RBridge ID. Client RBridge IDs
should match between cluster peers for 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 Session VLAN is the VLAN used by the MCT cluster for control operations.
CCP runs over this VLAN. The MCT session VLAN subnet is not distributed in routing
protocols using redistribute commands.
The MCT Keep-alive VLAN is a VLAN configured to provide an alternate
communication path between MCT peers during ICL/CCP failure.
Revision 0919 5-6

MCT Limitations
• The following ICX features are not supported with MCT:

– ACLs on VLAN session (ICL) ports
– LACP on ICL
– MSTP, VSRP, and RIP
– MSDP, Anycast RP, and embedded RP
– IPv6, VRRP-E (IPv6), and VRRPv3
– GRE on the ICL VE interfaces
– Dynamic ARP Inspection (DAI) on the CCEPs
– Egress ACLs on MCT CCEPs
– Host security features (port MAC security, multiport authentication, 802.1X, DAI, DHCP snooping) on
CCEPs
– Multiport ARP on ICL or CCEPs
– Port MAC security is not supported on CEPs
• However, ICX devices do not restrict the port MAC security commands to be enabled on the CEPs
– Web authentication on MCT VLANs
Revision 0919 5-7

MCT Configuration
Revision 0919 5-8

MCT Cluster Configuration Steps
• Configure ICL LAG

– Static LAG is required
• Configure MCT VLANs
– MCT Session VLAN
– MCT Keep-alive VLAN (optional, recommended)
• Configure IP interfaces
– On Router – Configure IPv4 VE on MCT session VLAN1
– On Switch – Configure global IPv4 address2
• Create MCT cluster
– Assign local RBridge ID
– Identify session VLAN
– Identify keep-alive VLAN (if deployed)
– Identify ICL port
– Specify MCT peer
– Deploy cluster
Footnote 1: IPv6 is not supported with MCT. All IP configurations used with MCT must use
IPv4.
Footnote 2: When running switch code, the global IP address of each MCT peer must be in
the same subnet to establish MCT CCP session.
These are the basic configuration steps necessary to configure an MCT cluster. The steps to
configure cluster clients will be covered in later slides. These steps will include:
• Configuring the LAG used for the Inter-Chassis Link (ICL), which can only be configured
as a static LAG.
• The required Session VLAN must be configured and the optional, but highly
recommended keep-alive VLAN should be as well.
• IP interfaces used for Cluster Communication Protocol (CCP) messages will be
configured. When running switch code, this be accomplished with the global IP
address, as it is the only IP address on the device. When running router code, it will be
a Virtual Ethernet (VE) interface on the Session VLAN.
• The cluster will be defined with all necessary parameters for establishing a CCP session
between MCT peer nodes.
The configuration examples provided in the following slides are completed on the switch
labeled MCT1 in the graphic. In order for MCT to function properly the equivalent commands
must also be completed on the switch labeled MCT2. The commands for configuring MCT2
will be provided in the notes section of this guide.
The steps above are applied in this order to provide a logical flow of how MCT is configured.
The steps are not required to be completed in this order. However, some of the steps defined
do have dependencies that will dictate the order of configuration steps.
Revision 0919 5-9

MCT Cluster Configuration
Example for MCT1

• Configure ICL LAG
MCT1(config)# lag MCT-ICL static id 2
MCT1(config-lag-MCT-ICL)# ports eth 1/1/1 to 1/1/2
• Configure MCT Keep-alive VLAN

MCT1(config)# vlan 3001 name MCT-keep-alive
MCT1(config-vlan-3001)# tagged ethernet 1/1/24
• Configure MCT Session VLAN for CCP communication

MCT1(config)# vlan 3000 name Session-VLAN
MCT1(config-vlan-3000)# tagged lag 2
MCT1(config-vlan-3000)# no spanning-tree1
Footnote 1: On a switch image, STP is enabled by default for all the VLANs; however,
for MCT, Layer 2 protocols such as STP and RSTP must not be enabled on the session
VLAN. Therefore, STP must be disabled explicitly for the session VLAN. STP is
automatically disabled in the router image.
Here we configure the ICL LAG as a static LAG and ports 1/1/1 and 1/1/2 are added as
members. Next, the recommended keep-alive VLAN is created using VLAN ID 3001
and port 1/1/24 is added as a member. Lastly, the session VLAN is created using VLAN
ID 3000, the ICL LAG is added as a member and Spanning Tree is explicitly disabled.
MCT2 Configuration Example:
MCT2(config)# lag MCT-ICL static id 2
MCT2(config-lag-MCT-ICL)# ports eth 1/1/1 to 1/1/2
MCT2(config-lag-MCT-ICL)# vlan 3000 name Session-VLAN
MCT2(config-vlan-3000)# no spanning-tree
MCT2(config-vlan-3000)# vlan 3001 name MCT-keep-alive
MCT2(config-vlan-3001)# tagged ethernet 1/1/24
MCT Cluster Configuration (cont.)
Example for MCT1

• Create VE on MCT session VLAN
MCT1(config-vlan-3000)# router-interface ve 3000
• Configure VE interface
MCT1(config)# interface ve 3000
MCT1(config-vif-3000)# ip address 1.1.1.1/30
• Create MCT cluster

MCT1(config)# cluster MCT 1
MCT1(config-cluster-MCT)#
In this example, the MCT peers are running router code, therefore the next step is to
create Virtual Ethernet (VE) interface 3000 in VLAN 3000. Once created, the interface
can be accessed with the interface ve 3000 command and an IP address can be
assigned. Next, the cluster is created with the cluster command. This command
requires the name of the cluster as well as the desired cluster ID to be provided.
MCT2(config-vlan-3000)# router-interface ve 3000
MCT2(config-vlan-3000)# interface ve 3000
MCT2(config-vif-3000)# ip address 1.1.1.2/30
MCT2(config-vif-3000)# cluster MCT 1
MCT Cluster Configuration (cont.)
Example for MCT1

• Assign RBridge ID
MCT1(config-cluster-MCT)# rbridge-id 1
• Associate session VLAN with cluster
MCT1(config-cluster-MCT)# session-vlan 3000
• Specify Keep-alive VLAN
MCT1(config-cluster-MCT)# keep-alive-vlan 3001
• Specify ICL ports
MCT1(config-cluster-MCT)# icl MCT-ICL lag 2
• Define MCT peer
MCT1(config-cluster-MCT)# peer 1.1.1.2 rbridge-id 2 icl MCT-ICL
• Deploy MCT Cluster
MCT1(config-cluster-MCT)# deploy
Once in the cluster configuration context, an RBridge ID is assigned. Remember that

each cluster member and client must have a unique RBridge ID.
Next, associate the Session VLAN to the cluster, which in this case is VLAN 3000,
created in previous steps.
The keep-alive VLAN is also associated here with the keep-alive-vlan command. VLAN
3001, which was configured in previous steps was created for this purpose and is
configured in the example here.
Then assign the ICL created previously to the cluster using the icl command followed
by a name and the LAG used to carry the CCP traffic.
Next, define the cluster peer by providing the peer IP address and RBridge ID, and
identify the ICL they will use to communicate.
Finally, deploy the cluster by executing the deploy command.
MCT2(config-cluster-MCT)# rbridge-id 2
MCT2(config-cluster-MCT)# session-vlan 3000
MCT2(config-cluster-MCT)# keep-alive-vlan 3001
MCT2(config-cluster-MCT)# icl MCT-ICL lag 2
MCT2(config-cluster-MCT)# peer 1.1.1.1 rbridge-id 1 icl
MCT-ICL
MCT2(config-cluster-MCT)# deploy
MCT Considerations
• The MCT cluster can be deployed separately without any clients configured
– When the cluster is deployed, it will check any deployed clients and start the state machine for the clients
– Clients can be configured and deployed as needed
• Once the cluster is deployed, only cluster clients, cluster member VLANs and client
isolation mode can be modified
– Cluster must be “un-deployed” to make any other changes
MCT1(config-cluster-MCT)# no deploy
You could stop the configuration here and deploy the MCT cluster separately without
any clients configured.
When the cluster is deployed, it will check for any deployed clients and start the state
machine for any that are found.
Clients can then be configured and deployed as needed.
However, once the cluster is deployed, only cluster clients, cluster member VLANs
and client isolation mode can be modified. No other cluster settings can be modified
unless the cluster is “un-deployed” with the no deploy command in the cluster
configuration context.
Client Isolation Mode
• Client isolation mode defines actions to be taken on client ports in the event of CCP failure
• MCT peers isolate client ports in two modes:

– Loose mode (default):
• If the keep-alive VLAN is not configured, both nodes become master which will result in loops and MAC learning
problems
• Best practice method when used with Keep-alive VLAN
• If the keep-alive VLAN is configured, when the CCP goes down the peers perform the Master/Slave negotiation.
After negotiation, the Slave shuts down its client ports while the Master client ports continue to forward traffic
– Strict mode:
• When the CCP goes down, the client interfaces on both the cluster nodes are administratively shutdown. In this
mode, the clients are completely isolated from the network if CCP is not operational
• Preferred when keep-alive VLAN is not configured
MCT1(config-cluster-MCT)# client-isolation strict

• Syntax: [no] client-isolation strict
When using loose mode, When the CCP is down in loose mode, the following results
occur.
• If the keep-alive VLAN is configured, CCRR messages, used to exchange
information between peer devices, are sent every second over that VLAN.
• When CCP is down and a keep-alive VLAN is configured, active/standby
selection is based on the following criteria:
• If one device’s CCEPs are up and the peer’s CCEPs are down, the peer with
the local CCEPs down becomes the standby.
• Otherwise, the device with the higher RBridge ID becomes the standby.
• If no packets are received from the peer device for a period of three seconds,
the peer is considered down.
The CLI will allow modification of the client-isolation mode on MCT cluster nodes
even when the cluster is deployed. You must configure the same isolation mode on
both cluster nodes.
To configure client isolation strict mode enter the following command:
MCT1(config-cluster-MCT)# client-isolation strict
Syntax: [no] client-isolation strict
To revert back to the default of client isolation loose mode, use the “no” form of the
command:
MCT1(config-cluster-MCT)# no client-isolation strict
Display Cluster Peer Information
• Display cluster peer information and status
MCT1# show cluster 1 peer

Cluster MCT 1
=============
Rbridge Id: 1, Session Vlan: 3000, Keep-Alive Vlan: 3001
Cluster State: Deploy
Client Isolation Mode: Loose
Member Vlan Range: 1000
MCT Peer's Reachability using Keep-Alive Vlan: Peer Reachable
Peer Info:
----------
Peer IP: 1.1.1.2, Peer Rbridge Id: 2, ICL: MCT-ICL
KeepAlive Interval: 10 , Hold Time: 90, Fast Failover
Active Vlan Range: 1000
Last Reason for CCP Down: Not Down
Peer State: CCP Up (Up Time: 3 days:17 hr:55 min:34 sec)
The show cluster {cluster-id | cluster-name} peer command will display information
related to peer communications and status.
Output begins with local peer node information, including:
• Rbridge ID
• Session VLAN
• Keep-alive VLAN
• Cluster status
• Client isolation mode
• List of member VLANs
• Status of peer reachability over the keep-alive VLAN
Below that is information about the MCT peer node, including:
• Peer IP
• Peer RBridge ID
• ICL used for CCP
• MCT timers
• Active member VLANs on peer
• Reason for last CCP failure (if any)
• Peer CCP state
MCT Client Configuration
• There are two methods for configuring MCT cluster clients
– Manual – Administrator defines settings for each cluster client, including:

• Name
• RBridge ID
• Client ports
• Deployment
– Automatic – Cluster clients are automatically discovered using LLDP

• No ability for user-friendly client names
• No ability to control RBridge ID assignment
• Can be automatically deployed upon discovery
• Both client deployments methods will be covered using the topology shown here
– Client #1 will be configured using manually method
– Client #2 will be configured using automatic method
Manual client configuration includes administratively setting the client name, client
RBridge ID (unique identification for each client), client interface (CCEP), and
deployment settings on both MCT cluster devices. When many cluster clients are
being configured in a cluster, manual configuration can take a considerable amount of
time.
Cluster client automatic configuration saves the time that would be required to
complete the entire configuration manually. However it also comes with some
limitations, for example:
• There is no ability to configure client names, they are automatically generated
• No ability to control RBridge ID assignment, they are automatically generated
• Can be automatically deployed upon discovery. Optionally, the discovered
clients can be added to the running configuration in an undeployed state. To be
manually deployed at a later time.
MCT Client Configuration Overview
1. Configure client LAGs

– Required for manual configuration method
– For dynamic/LACP cluster client deployments, single port
connections must be configured as a LAG1
– Static LAG cluster clients with single interface
connections to both cluster peers do not require the
ports to be configured as a LAG although it is
recommended
2. Create client VLANs

– Required for both manual and automatic configuration
methods
3. Identify and deploy clients in the cluster

– Unique steps required for manual and automatic cluster
client configuration
Footnote 1: If a cluster client endpoint is configured for dynamic/LACP LAGs, it will

use LACP to establish the LAG connection. Therefore, a single port connection from
the cluster must also send/receive LACP. This can only be done if a dynamic LAG is
configured with this single CCEP as the sole port member.
The configuration examples provided in the following slides are completed on the
switch labeled MCT1. In order for MCT to function properly the equivalent commands
must also be completed on the switch labeled MCT2. Where feasible, the MCT2 node
configuration commands will be provided in the notes section of the printed
materials for this course.
When employing the manual client configuration method, you start by configuring
the LAGs to the clients.
Client VLANs must be created for both manual and automatic configuration methods.
It is very important that client VLANs (or MCT VLANs) are configured on both cluster
members as VLAN configurations are not shared between the cluster members.
Then the client ports must be identified and deployed.
The steps above are applied in this order to provide a logical flow of how MCT is
configured. The steps are not required to be completed in this order. However, some
of the steps defined do have dependencies that will dictate the order of configuration
steps.
MCT Manual Client Configuration
Example for MCT1

• Configure client LAGs
MCT1(config)# lag Client1 dynamic id 21
MCT1(config-lag-Client1)# ports eth 1/1/5 to 1/1/6
• Create client VLAN

MCT1(config)# vlan 1000 name Client-VLAN
ICL
MCT1(config-vlan-1000)# untagged lag 21 LAG
• Identify and deploy clients in cluster

(config-cluster-MCT)# client Client1
(config-cluster-MCT-Client1)# rbridge-id 100
(config-cluster-MCT-Client1)# client-interface lag 21
(config-cluster-MCT-Client1)# deploy
Here we configure the Client1 LAG and assign the port members.
Next, we create the client VLAN and add the client LAG as well as the ICL LAG.
Remember the ICL must be a member of each MCT/Client VLAN.
Finally, from the MCT cluster configuration context, the client is defined with the
client command followed by a client name. This will move you to the client
configuration context, where you will:
• Define the RBridge ID, which must be unique
• Define the client interface, which will typically be a LAG
• Deploy the cluster client with the deploy command
In the example topology, Client #1 is connected to MCT2 through a single port.
However, because dynamic LAGs are being used on the client switches, it must still be
configured as a single-port LAG on the MCT switch. This is because if LACP is not
running on the interface, the dynamic LAG on the client-side will not be able to
negotiate trunk capabilities and the port will not be allowed as a member.
If static LAGs are used on the Client switches, the LAG configuration step for single-
port connections from MCT peers is optional and the client-interface command will
identify an ethernet port, rather than a LAG. For example:
MCT2(config-cluster-MCT-Client1)# client-interface ethernet 1/1/3

MCT2(config)# lag Client1 dynamic id 21
MCT2(config-lag-Client1)# ports eth 1/1/3
MCT2(config-lag-Client1)# vlan 1000 name Client-VLAN
MCT2(config-vlan-1000)# untagged lag 21
MCT2(config-vlan-1000)# cluster MCT 1
MCT2(config-cluster-MCT)# client Client1
MCT2(config-cluster-MCT-Client1)# rbridge-id 100
MCT2(config-cluster-MCT-Client1)# client-interface lag 21
MCT2(config-cluster-MCT-Client1)# deploy
Cluster Client Automatic Configuration
• Automatically discovers, configures and optionally deploys new cluster clients
• Useful when many clients need to be configured at one time
• Reduces repetitive configuration commands required for each cluster client
• Cluster prerequisites:
– The cluster must be configured on both MCT cluster devices
– Any client VLAN/s must be configured on both MCT cluster devices
• Client-facing ports must be members
– Trunk group/LAG configuration must be removed from the client-facing interfaces
– The client interfaces must be up and operational
• Client side prerequisites:

– VLAN and trunk group/LAG configuration must be completed – Static and dynamic LAGs are supported
– Link Level Discovery Protocol (LLDP) must be enabled
Client configuration includes setting the client name, client RBridge ID (unique
identification for each client), client interface (CCEP), and deployment settings on
both MCT cluster devices. With a significant number of clients per cluster, manual
configuration can take a considerable amount of time.
Cluster client automatic configuration saves the time that would be required to
complete the entire configuration manually.
For cluster client automatic configuration to work, the following prerequisites are
required on the cluster side:
• The cluster must be configured on both MCT cluster devices.
• An MCT VLAN must be configured on both MCT cluster devices.
• The trunk group configuration must be removed from the client interfaces.
• The client interfaces must be up and operational.
• The cluster ID must be unique when there are multiple clusters interconnected
in a topology. For example, in a cascaded stage 2 MCT cluster, the cluster ID on
a stage 1 pair of switches must be different from the cluster ID on a stage 2 pair
of switches.
The following prerequisites are required on the client side:
• VLAN and trunk group configuration must be completed. Both static and
dynamic LAG types are supported.
• Link Level Discovery Protocol (LLDP) must be enabled.
The following limitations apply to cluster client automatic configuration:

• Cluster client automatic configuration is designed for generating new clients,
not for updating an existing client.
• A single client spanning across multiple devices is not supported (cascading
MCT). For example, the configuration of cascading MCT through cluster client
automatic configuration is not supported.
• A single downstream switch being discovered as different clients for more than
one client side LAG is not supported.
• LACP client interface auto-detection is supported only for devices running
FastIron 07.0.40 and later releases.
• When hash collisions occur (RBridge ID collisions), cluster client automatic
configuration reports errors, and manual intervention is required.
Cluster Client Automatic Configuration Steps
• From the cluster configuration context:

– Enable the client auto-detect ports on both MCT devices

• Syntax: client-auto-detect ethernet ports [ethernet <ports>]
– Start the client auto-detect process on both

cluster devices
• Syntax: client-auto-detect start
– Check and fix the automatically detected clients

• Syntax: show cluster {cluster-id | cluster-name} client-auto-detect
– Configure automatically detected clients into the running configuration

• Syntax: client-auto-detect config [ deploy-all ]
– Without deploy-all option, configuration is saved to running-config, but clients are not deployed
Performing cluster client automatic configuration is a fairly straightforward process.

First, the client ports must be identified with the client-auto-detect command
followed by the individual and/or range of ports where clients are connected. This
should be completed on both peer devices before proceeding to the next step.
Next, the client automatic detection process is started with the client-auto-detect
start command. Within one minute, the system reports information and errors (if
there are mismatches such as an LACP configuration mismatch). You can fix the client-
side mismatches while the process is running.
The discovered information can be reviewed while the process is running by
executing the show cluster {cluster-id | cluster-name} client-auto-detect command.
Finally, you apply the discovered results to the running-config with the client-auto-
detect config command. Optionally you can append the deploy-all option to the
command to have the newly discovered clients deployed at this time as well. Without
this option, each discovered client must be deployed manually.
All automatically configured client information is now published into the running
configuration, and the static trunk configuration is generated, created, and deployed.
LACP is started. Ports that are successfully programmed as CCEP are removed from
the autoconfiguration-enabled port list. If the port list is empty, which means all ports
are configured into clients successfully, the automatic configuration process stops.
The original LLDP configuration is restored. Otherwise, the automatic configuration
process continues only on the ports still left in the list.
Cluster Client Automatic Configuration Example
MCT1(config-cluster-MCT)# client-auto-detect ethernet 1/1/7 to 1/1/8

MCT1(config-cluster-MCT)# client-auto-detect start
CLUSTER AUTOCONFIG INFO - Cluster 1 client auto-config process started
CLUSTER AUTOCONFIG INFO - New Client: A-Client2-609c9f41cc24 with rbridge

id: 2446 discovered on port 1/1/7 with dynamic lag(lacp) capability
CLUSTER AUTOCONFIG INFO - Port 1/1/8 added as LACP interface to Client:A-

Client2-609c9f41cc24
Discovered client’s
hostname and MAC
address
Here we see the execution of the automatic configuration commands on the example
topology from the MCT1 peer. Ports 1/1/7 and 1/1/8 are identified as client-auto-
detect ports and then the auto-detect process is started.
The console output shows that the process has indeed started. Then, a client
discovered on port 1/1/7 and is running LACP. Next port 1/1/8 and is added to the
dynamic/LACP LAG connecting to the same client.
Notice the client hostname and MAC address are included in the client identifier, in
this case the hostname is “Client1”.
MCT2(config-cluster-MCT)# client-auto-detect ethernet
1/1/5 to 1/1/6
MCT2(config-cluster-MCT)# client-auto-detect start
CLUSTER AUTOCONFIG INFO - Cluster 1 client auto-config
process started
CLUSTER AUTOCONFIG INFO - New Client: A-Client2-
609c9f41cc24 with rbridge id: 2446 discovered on port
1/1/6 with dynamic lag(lacp) capability
CLUSTER AUTOCONFIG INFO - Port 1/1/5 added as LACP
interface to Client:A-Client2-609c9f41cc24
Cluster Client Automatic Configuration Example (cont.)
• To display auto-detect process status

MCT1(config-cluster-MCT)# show cluster 1 client-auto-detect
cluster MCT 1
rbridge-id 1
session-vlan 3000
keep-alive-vlan 3001
icl MCT-ICL lag 2
peer 1.1.1.2 rbridge-id 2 icl MCT-ICL
client-auto-detect ethernet 1/1/7 to 1/1/8
client-auto-detect start
deploy
client A-Client2-609c9f41cc24
rbridge-id 2446
client-interface ethernet 1/1/7
• Will be written to the running-config with client-auto-detect config execution

Using the show cluster {cluster-id | cluster-name} client-auto-detect command

displays information about the automatic configuration process as well as some of
the configurations that will be added to the running-config if the results are accepted.
This output shows the ports that are configured for auto-detection and that the
process is still in the start (or discovery) state.
Below that is the discovered client/s. In this case it is the single client that is
connected to the auto-detect ports. The Rbridge ID is automatically generated. Also
note that only the first port that was discovered is displayed as a client-interface.
Don’t worry, the port that was discovered as an LACP interface connected to the
same client will be added when the results are put into the running-config.
MCT2(config-cluster-MCT)# show cluster 1 client-auto-
detect
cluster MCT 1
rbridge-id 2
session-vlan 3000
icl MCT-ICL lag 2
client-auto-detect ethernet 1/1/5 to 1/1/6
client-auto-detect start
deploy
rbridge-id 2446
client-interface ethernet 1/1/5
Cluster Client Automatic Configuration Example (cont.)
• Use the client-auto-detect config command to save the discovered clients to the running-
config
– Optionally, use deploy-all to automatically deploy the discovered clients
MCT1(config-cluster-MCT)# client-auto-detect config deploy-all

LAG MCT-CCAC-LAG_3 deployed successfully!
Spanning tree is disabled on CCEP port lg3 of MCT Client: A-Client2-
609c9f41cc24.
CLUSTER AUTOCONFIG INFO - Port 1/1/7 is successfully programmed as client
interface. Removing from autoconfig port list.
CLUSTER AUTOCONFIG INFO - Port 1/1/8 is successfully programmed as client
interface. Removing from autoconfig port list.
CLUSTER AUTOCONFIG INFO - Cluster 1 client auto-config process stopped
Lastly, the client-auto-detect config deploy-all command is used to apply the changes
to the running-configuration. Using the deploy-all option ensures the newly
discovered clients are also deployed after creation. If the deploy-all option is not
used, the clients will be added to the running-configuration but they will not be
deployed, requiring manual deployment by the administrator.
Also notice the output that indicates a new LAG was configured and deployed and
Spanning Tree was disabled on the CCEP LAG interface. Next, we see both ports being
removed from the auto-config port list. Finally, since those were all of the ports in the
auto-config port list, the auto-config process is stopped automatically.
MCT2(config-cluster-MCT)# client-auto-detect config
deploy-all
LAG MCT-CCAC-LAG_3 deployed successfully!
Spanning tree is disabled on CCEP port lg3 of MCT
Client: A-Client2-609c9f41cc24.
CLUSTER AUTOCONFIG INFO - Port 1/1/5 is successfully
programmed as client interface. Removing from
autoconfig port list.
CLUSTER AUTOCONFIG INFO - Port 1/1/6 is successfully
programmed as client interface. Removing from
autoconfig port list.
CLUSTER AUTOCONFIG INFO - Cluster 1 client auto-config
process stopped
Displaying MCT Configuration
• Display cluster configuration

MCT1# show cluster MCT config
cluster MCT 1
rbridge-id 1
session-vlan 3000
icl MCT-ICL lag 2
deploy
client Client1
rbridge-id 100
client-interface lag 21
deploy
rbridge-id 2446
deploy
!
Once the cluster is configured, you can use the show cluster {cluster-id | cluster-
name} config command to view the configuration. Remember to always make sure
the cluster and each configured client are deployed for proper operation.
MCT2# show cluster MCT config
cluster MCT 1
rbridge-id 2
session-vlan 3000
icl MCT-ICL lag 2
deploy
client Client1
rbridge-id 100
deploy
rbridge-id 2446
deploy
!
Displaying Client Information
• Display a list of clients and information FSM-States

Up – CCEP ports up on both peers
MCT1# show cluster MCT client Local UP – CCEP ports up only on local peer
Remote Up – CCEP ports up only on remote peer
Admin Up – All CCEP ports enabled & deployed but down
Client Info:
------------
Number of Clients Configured: 2
Name Rbridge-id Config Port Trunk FSM-State
A-Client2-609c9f41cc24 2446 Deployed lg1 1 Up
Client1 100 Deployed lg21 21 Up
Configured clients by name State of the client:

and RBridge ID LAG interfaces
Deployed or Undeployed and Trunk ID
The show cluster client command displays the client information including the client
name, RBridge ID, configured/deployment state, LAG interface and trunk ID of the
LAG connected to the client and the FSM-State.
The FSM-State displays status of the Finite State Machine (FSM). This can be very
helpful as a validation and troubleshooting tool. Valid FSM-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.
Display MCT Cluster Status
• Display cluster information

MCT1# show cluster 1
Cluster MCT 1
=============
Rbridge Id: 1, Session Vlan: 3000, Keep-Alive Vlan: 3001
Cluster State: Deploy
Client Isolation Mode: Loose
ICL Info: Combines show cluster peer and

---------
Name Port Trunk show cluster client information
MCT-ICL lg2 2
along with ICL information from a
Peer Info:
---------- single command
Peer IP: 1.1.1.2, Peer Rbridge Id: 2, ICL: MCT-ICL
KeepAlive Interval: 10 , Hold Time: 90, Fast Failover
Active Vlan Range: 1000
Last Reason for CCP Down: Not Down
Peer State: CCP Up (Up Time: 3 days:17 hr:52 min:52 sec)
Client Info:
------------
Number of Clients configured: 2
Client1 100 Deployed lg21 21 Up
The show cluster command displays a lot of useful information including the local
peer’s RBridge ID, the Session VLAN, and the cluster state, and more. The Peer Info
section shows connection information and status. These two sections are the same
information and display format as the show cluster {cluster-id | cluster-name} peer
output.
The ICL Info section displays the configured name and ports that make up the ICL.
At the bottom of the output, the Client Info section displays details about each
configured. This output is identical to the show cluster {cluster-id | cluster-name}
client command output.
Displaying Detailed Client Information
• Display client details by client name or RBridge ID

MCT1# show cluster MCT client Client1
Cluster MCT 1
=============
Rbridge Id: 1, Session Vlan: 3000, Keep-Alive Vlan: 3001 Cluster Information including,
Cluster State: Deploy RBridge ID, Session VLAN,
Client Isolation Mode: Loose and Member VLANs
Client Info:
------------ Client Information
Client: Client1, rbridge-id: 100, Deployed including, RBridge ID,
Client Port: lg21, Trunk Id :21 client ports, and state
Client portmask: ethe 1/1/5 to 1/1/6 lag 21
State: Up
Number of times Local CCEP down: 0 Client
statistics
Number of times Remote CCEP down: 0
Number of times Remote Client undeployed: 0
<Output Truncated>
Display more client details using the show cluster { cluster-id | cluster-name } client [
client-name ] command. Here we see the cluster information, as well as the client
information and statistics.
Displaying CCP Peer 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 13 days:18 hr:34 min:23 sec
To display the CCP status between cluster peers, use the show cluster {cluster-id |
cluster-name} ccp peer command. Here we see that the peer at IP address 10.1.1.2 is
operational, and the amount of time CCP communications have been up to the peer.
Displaying Detailed CCP Peer Information
• Use the detail parameter to view more CCP information

MCT1# show cluster MCT ccp peer detail
Peer Session Details
--------------------
IP address of the peer 1.1.1.2
Rbridge ID of the peer 2
Session state of the peer OPERATIONAL
Next message ID to be send 32204
Keep Alive interval in seconds 10
Hold Time Out in seconds 90
Fast Failover is enable for the session
UP Time 3 days:18 hr:35 min: 8 sec
Number of tcp packet allocations failed 0
Message Init Keepalive Notify Application Badmessages
Send 2 32203 0 401 0
Receive 1 32214 0 394 0
<Continued on next page>
Add the detail parameter, and you can see peer connection information as well as the
communication between the peers on the TCP port. There is lengthy data here that is
typically most useful in analysis and troubleshooting situations.
Displaying Detailed CCP Peer Information (cont.)
• Use the detail parameter to view more CCP information

MCT1# show cluster MCT ccp peer detail
<Continuation>
TCP connection is up
TCP connection is initiated by 1.1.1.2
TCP connection tcbHandle not pending
TCP connection packets received
TCP Connection Details
----------------------
TCP Connection state: ESTABLISHED Maximum segment size: 1436
Local host: 1.1.1.1, Local Port: 4175
Remote host: 1.1.1.2, Remote Port: 12148
ISentSeq: 1186266851 SendNext: 1186956087 TotUnAck: 0
TotSent: 689236 ReTrans: 0 UnAckSeq: 1186956087
IRcvSeq: 1222766851 RcvNext: 1223443067 SendWnd: 16384
TotalRcv: 676216 DupliRcv: 0 RcvWnd: 16384
SendQue: 0 RcvQue: 0 CngstWnd: 1436
Here we have the continuation of the output from the show {cluster-id | cluster-
name} ccp peer detail command. This section displays the status of the TCP
connection and statistics of the various messages used to maintain the MCT cluster
and clients.
MCT Failover Scenarios
Client (CCEP) Interface Goes Down
There are two links on the CCEP side on Client. If only one link fails, the trunk is still
up and there is minimal impact. If both links are down, MCT is designed to handle
that scenario. In other words, if MCT1 CCEPs are down then it will use MCT2 CCEPs
and data loss should be minimal or sub-second.
Client Information After CCEP Failure
• Use show cluster mct client command to display client status after CCEP failure
FSM-States
MCT1# show cluster MCT client Up – CCEP ports up on both peers
Client Info: Local UP – CCEP ports up only on local peer
------------ Remote Up – CCEP ports up only on remote peer
Number of Clients Configured: 2 Admin Up – All CCEP ports enabled & deployed but down
Client1 100 Deployed lg21 21 Remote Up
MCT2# show cluster MCT client

Client Info:
------------
Number of Clients Configured: 2
Client1 100 Deployed lg21 21 Local Up
The show cluster client command displays the client information including the client
name, RBridge ID, configured/deployment state, LAG interface and trunk ID of the
LAG connected to the client and the FSM-State.
The FSM-State displays status of the Finite State Machine (FSM). This can be very
helpful as a validation and troubleshooting tool. Valid FSM-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.
MCT Cluster Peer Goes Down
When an MCT cluster device goes down (for example, due to a power failure), the
traffic fails over to the other MCT cluster device.
ICL/CCP Goes Down With Keep-alive VLAN
Master-Standby negotiation
occurs on a per-client basis
If a keep-alive VLAN is used, the devices in the cluster can communicate even if the
ICL goes down. If the peer device is reachable over the keep-alive VLAN, the MCT
peers perform the active/standby negotiation per client. After negotiation, the
standby shuts down its client ports, and the active client ports continue to forward
the traffic.
The active/standby negotiation is performed per MCT client on the basis of RBridge
ID and client local or remote accessibility. If the client is reachable from both MCT
devices, the lower RBridge ID becomes the active device. If the client can be accessed
only from one of the MCT devices, the cluster device on which it is reachable
becomes the active device.
If the peer device cannot be reached over the keep-alive VLAN, then both cluster
devices keep forwarding.
ICL/CCP Goes Down Without Keep-alive VLAN
Use strict client-isolation mode

to isolate clients and prevent
irregular forwarding behavior
when no keep-alive VLAN is used
When the keep-alive VLAN is not configured, both cluster devices keep forwarding.
Use the client-isolation strict command to disable the client interface as soon as the
ICL link goes down to completely isolate the client.
MCT Layer 3 VRRP-E Redundancy

Capabilities
MCT with VRRP-E Layer 3 – Active-Standby Operation
• Layer 3 redundancy is provided by VRRP-E
– All traffic is forwarded via the VRRP-E Master VRRP-E

Master
– VRRP-E standby only forwards Layer 2 traffic
– Provides Active-Standby capability at Layer 3

• Routing only occurs at standby if the master fails
VRRP-E
Standby
HostA HostB
Host A Traffic
Host B Traffic
Virtual Router Redundancy Protocol (VRRP) is a standard redundancy protocol to

increase the availability of the default gateway servicing hosts on the same subnet via
advertising a "virtual router” as the default gateway to the host instead of one
physical router. VRRP-E is the Ruckus proprietary version of VRRP with a number of
enhancements. Both VRRP and VRRP-E are supported with MCT, which provides
switch-level redundancy for VRRP/VRRP-E.
The MCT switch that acts as backup router needs to ensure that packets sent to a
VRRP-E virtual IP address can be L2 switched to the VRRP-E master router for
forwarding. The MCT switch that acts as master router syncs the VRRP-E MAC to the
other MCT switch that acts as a backup router. Both data traffic and VRRP-E control
traffic travel through the ICL unless the short-path forwarding feature is enabled.
MCT with VRRP-E Server Virtualization
Layer 3 Active-Active Operation VRRP-E backup w/

short path forwarding
• VRRP-E is capable of providing Active-Active
capability at Layer 3 with VRRP-E Server VRRP-E
Virtualization1 Master
– short-path-forwarding
• Allows backup VRRP-E router to forward Layer 3
traffic if a forwarding path is available
• Provides Active-Active capability at Layer 3
– Routing occurs at standby if a forwarding path is
available VRRP-E
Standby
– Traffic forwards to Master if:
• No route is matched
• Only default route is matched HostA HostB
Host A Traffic
Host B Traffic
Footnote 1: With the VRRP-E server virtualization feature, short-path-forwarding,

enabled, the MCT VRRP-E backup switch can forward both Layer 2 and Layer 3
packets without going through the ICL, which provides a VRRP active-active topology.
Example VRRP-E Configuration:
MCT1(config)# interface ve 7
MCT1(config-vif-7)# ip address 10.10.200.11
255.255.255.0
MCT1(config-vif-7)# ip vrrp-extended vrid 7
MCT1(config-vif-7-vrid-7)# backup priority 110 track-
priority 20
MCT1(config-vif-7-vrid-7)# ip-address 10.10.200.1
MCT1(config-vif-7-vrid-7)# short-path-forwarding
MCT1(config-vif-7-vrid-7)# track-port e 1/1/11
MCT1(config-vif-7-vrid-7)# enable
When using the short-path-forwarding feature any packets being routed towards the
rest of the network can be routed by either the master or backup VRRP-E router. Any
packets that have the VIP as the destination layer-3 address (ping, traceroute, Telnet)
will be routed to the master router and will show an additional layer 3 hop if they
were forwarded through the backup. This additional hop will show the IP address of
the interface on the backup router instead of the VIP address in traceroute output.
Module Summary
– Describe the purpose and components of Multi-Chassis Trunking
– Explain how to configure an MCT cluster
– Describe the different methods of adding MCT clients to the cluster
– Use show commands to review and analyze status of MCT cluster operations
– Explain MCT failover scenarios
– Describe MCT operations when used with VRRP-E
End of Module 5:
Multi-Chassis Trunking
ICX 200 Layer 3 Fundamentals
Module 6:
Layer 3 Fundamentals
Revision 0919 6-1

Module Objectives
– Describe how to apply IPv4 and IPv6 addresses to network interfaces
– Discuss Layer 3 Features

• Route-only
• Virtual Ethernet (VE) Interfaces
• Static routes
• Null Routes
• Route-maps
• Default route
– Explain and configure standard and extended IP Access Control Lists (ACLs)
– Describe the configuration and capabilities of Policy-Based Routing (PBR)
Revision 0919 6-2

IP Addressing
Revision 0919 6-3

Layer 3 Interfaces
• Layer 3 addresses can be applied to:

– Physical
– Virtual Ethernet (VE)
– Loopback
– GRE tunnels
– VRIDs (VRRP/VRRP-E)
• Multiple IP subnets can be assigned to a single interface (multi-netted)

– Configured IP addresses are not replaced when an additional address is configured in a different subnet
• A secondary IP addresses within the same subnet can be added to a interface with the
secondary parameter
Layer 3 IPv4 and IPv6 addresses can be assigned to each of the interface types shown
here. On these interfaces, multiple IP addresses can be assigned. The function of
assigning IP addresses for multiple subnets on a single interface is referred to as
“multi-netting”. There are limits to how many IP addresses can be assigned to a single
interface, but the limit is based on hardware platform.
When IP addresses are configured on an interface, any existing IP addresses are not
removed. Unused/undesired IP addresses must be manually removed.
If there is a need to assign an interface with two IP addresses from the same subnet,
the secondary parameter must be used when defining the second IP address.
NOTE: By default, all physical and virtual routing interfaces configured on the device
use the base MAC address of the device or the configured stack MAC address. You
can specify a different MAC address for each physical or virtual routing interface. To
specify the MAC address for routing interfaces, enter commands such as the
following.
ICX(config)# interface ve 1000
ICX(config-vif-1000)# ip-mac aaaa.bbbb.cccc
ICX(config-vif-1000)# interface ethernet 1/1/13
ICX(config-if-e1000-1/1/13)# ip-mac 1234.5678.9abc
• Syntax: [no] ip-mac mac-addr
Revision 0919 6-4

IPv4 Addressing
• IPv4 addresses are defined with the ip address command within the interface
configuration context
– Either dotted decimal or CIDR notation can be used for subnet mask
ICX-Router(config)# interface ethernet 1/1/1

ICX-Router(config-if-e10000-1/1/1)# ip address 10.45.6.1 255.255.255.0
or
ICX-Router(config-if-e10000-1/1/1)# ip address 10.45.6.1/24
– Syntax: [no] ip address { ip-address mask | ip-address/mask } [ secondary ]
• Delete an IPv4 address, enter the no ip address command

ICX-Router(config-if-e10000-1/1/1)# no ip address 10.1.6.1
ICX-Router(config-if-e10000-1/1/1)# no ip address *
Ruckus Layer 3 devices support Internet Protocol version 4 (IPv4) and IPv6. IP support
on Ruckus Layer 2 switches consists of host services and functionality to support
management access and access to a default gateway.
All Ruckus IPv4 addresses can be configured and displayed in two formats:
• Classical subnet format with the IP address and subnet mask in dotted decimal
format.
• Classless Interdomain Routing (CIDR) format with the IP address in dotted
decimal but followed by a forward slash and a number representing the subnet
mask.
You can use either format when configuring IP address information. IP addresses are
displayed in classical subnet format by default, but you can change the display format
to CIDR.
To remove an IP address from an interface, the no ip address command is used. No
subnet mask is needed to remove IP address from interface. Additionally, you can
remove all IP addresses assigned to an interface with the * option.
While not shown on the slide, you can replace the primary IP address assigned to an
interface with by appending replace to the end of the ip address command. This will
in affect remove the primary IP address that is in the same subnet as the address
being added. This is supported on a router image only and does not allow the
changing of the subnet mask.
ICX-Router(config-if-e1000-1/1/1)# ip address
10.45.6.100/24 replace
Revision 0919 6-5

IPv6 Addressing
• IPv6 capabilities are globally enabled with the ipv6 unicast-routing command
– IPv6 traffic forwarding can be disabled globally by using the no ipv6 unicast-routing command
• Must be explicitly enabled on interfaces that forward IPv6 traffic
• When configuring a global or unique local IPv6 unicast address (ULA)

– IPv6 is also enabled on the interface
– Options for the low-order 64 bits:
• A manually configured interface ID
• An automatically computed EUI-64 interface ID
– To automatically generate a link-local IPv6 address on an interface, you must explicitly enable IPv6
• Link-local addresses can be manually assigned
To forward IPv6 traffic on a router interface, the interface must have an IPv6 address,
or IPv6 must be enabled. By default, an IPv6 address is not configured on a router
interface. You must enable IPv6 and configure an IPV6 address to forward IPv6 traffic
on a router interface.
If you choose to configure a global or site-local IPv6 address for an interface, IPv6 is
also enabled on the interface. Further, when you configure a global IPv6 address, you
must decide on one of the following in the low-order 64 bits:
• A manually configured interface ID
• An automatically computed EUI-64 interface ID
If you prefer to assign a link-local IPv6 address to the interface, you must specifically
enable IPv6 on the interface, which causes a link-local address to be automatically
computed for the interface. If preferred, you can override the automatically
configured link-local address with an address that you manually configure.
Revision 0919 6-6

Configuring Global or Unique Local IPv6 Unicast Address
• Manually configured interface

ICX(config-if-e10000-1/1/3)# ipv6 address 2001:DB8:12D:1300:240:D0FF:FE48:4672/64
• Automatically computed EUI-64 Interface ID

ICX(config-if-e10000-1/1/4)# ipv6 address 2001:DB8:12D:1300::/64 eui-64
– Syntax: [no] ipv6 address ipv6-prefix [ eui-64 ]

• ipv6-prefix - Specifies the IPv6 prefix address in the format X:X::X:X/M
• eui-64 - Configures the global address with an EUI-64 interface ID in the low-order 64 bits
Configuring a global or site-local IPv6 address on an interface does the following:

• Automatically configures an interface ID (a link-local address), if specified
• Enables IPv6 on that interface
Additionally, the configured interface automatically joins the following required
multicast groups for that link:
• Solicited-node multicast group FF02:0:0:0:0:1:FF00::/104 for each unicast
address assigned to the interface.
• Solicited-node for subnet anycast address for each unicast assigned address
• Solicited-node for anycast address FF02:0:0:0:0:1:FF00::0000
• All-nodes link-local multicast group FF02::1
• All-routers link-local multicast group FF02::2
The neighbor discovery feature sends messages to these multicast groups.
Revision 0919 6-7

Configuring a Link-local IPv6 Address
• Enabling IPv6 on an interface without configuring a global or unique local unicast address
– Auto-assigned link-local address

ICX(config-if-e10000-1/1/3)# ipv6 enable
• Syntax: [no] ipv6 enable
– Manually assigned link-local

ICX(config-if-e10000-1/1/4)# ipv6 address FE80::240:D0FF:FE48:4672 link-local
• Syntax: [no] ipv6 address ipv6-address link-local
• When multiple VLANs share a port or VE, manually assigned link-local addresses should be
used
– All physical and VE interfaces share the same MAC address, resulting in duplicate link-local addresses
Link-local addresses can be assigned manually or automatically. When the ipv6

enable command is used on interface, IPv6 is enabled on the interface and specifies
that the interface is assigned an automatically computed link-local address.
Note: When configuring VLANs that share a common tagged interface with a physical
or Virtual Ethernet (VE) interface, Ruckus recommends that you override the
automatically computed link-local address with a manually configured unique address
for the interface. If the interface uses the automatically computed address, which in
the case of physical and VE interfaces is derived from a global MAC address, all
physical and VE interfaces will have the same MAC address.
The link-local keyword indicates that the ICX device interface should use the
manually configured link-local address instead of the automatically computed link-
local address.
Revision 0919 6-8

IPv6 Anycast Addresses
• An anycast address is allocated from the unicast address space
• The anycast keyword allows the device to recognize the assigned address as an anycast
address

ICX(config-if-e10000-1/1/2)# ipv6 address 2001:db8::6/64 anycast
– Syntax: [no] ipv6 address ipv6-prefix anycast
In IPv6, an anycast address is an address for a set of interfaces belonging to different

nodes. Sending a packet to an anycast address results in the delivery of the packet to
the closest interface configured with the anycast address.
An anycast address looks similar to a unicast address, because it is allocated from the
unicast address space. If you assign an IPv6 unicast address to multiple interfaces, it is
an anycast address. Use the anycast option when defining an IPv6 address on an
interface to classify the address as anycast.
IPv6 anycast addresses are described in detail in RFC 1884. Refer to RFC 2461 for a
description of how the IPv6 Neighbor Discovery mechanism handles anycast
addresses.
Revision 0919 6-9

IPv4 and IPv6 on Same Interface
• ICX interfaces can support both IPv4 ands IPv6 forwarding (dual-stacking) on the same
interface automatically
– No additional steps needed
ICX(config)# ipv6 unicast-routing

ICX(config-if-e1000-1/3/1)# ip address 10.168.1.1/24
ICX(config-if-e1000-1/3/1)# ipv6 address 2001:db8:12d:1300::/64 eui-64
A router interface can be configured to support both the IPv4 and IPv6 protocol
stacks.
Each router interface that sends and receives both the IPv4 and IPv6 traffic must be
configured with an IPv4 address and an IPv6 address. In this task, IPv6 is globally
enabled, an IPv4 address and an IPv6 address are configured for a specific interface.
IPv6 Neighbor Discovery
• The neighbor discovery feature for IPv6 uses IPv6 ICMP messages to perform the following
tasks:
– Determine the link-layer address of a neighbor on the same link
– Verify that a neighbor is reachable
– Track neighbor devices
– Perform Duplicate Address Detection (DAD)
• An IPv6 host is required to listen for and recognize the following addresses that identify
itself:
– Link-local address
– Assigned unicast address
– Loopback address
– All-nodes multicast address
– Solicited-node multicast address
– Multicast address to all other groups to which it belongs
Neighbor solicitation and advertisement messages enable a node to determine the

link-layer address of another node (neighbor) on the same link. (This function is
similar to the function provided by the Address Resolution Protocol [ARP] in IPv4.)
Router advertisement and solicitation messages enable a node on a link to discover
the routers on the same link.
At system startup, a host on a link sends a router solicitation message to the all-
routers multicast address (FF01). Sending a router solicitation message, which has a
value of 133 in the Type field of the ICMP packet header, enables the host to
automatically configure its IPv6 address immediately instead of awaiting the next
periodic router advertisement message.
Because a host at system startup typically does not have a unicast IPv6 address, the
source address in the router solicitation message is usually the unspecified IPv6
address (0:0:0:0:0:0:0:0). If the host has a unicast IPv6 address, the source address is
the unicast IPv6 address of the host interface sending the router solicitation message.
Entering the ipv6 unicast-routing command automatically enables the sending of
router advertisement messages on all configured router Ethernet interfaces. You can
configure several router advertisement message parameters.
Although the stateless auto configuration feature assigns the 64-bit interface ID
portion of an IPv6 address using the MAC address of the host’s NIC, duplicate MAC
addresses can occur. Therefore, the duplicate address detection (DAD) feature verifies
that a unicast IPv6 address is unique before it is assigned to a host interface by the
stateless auto configuration feature. Duplicate address detection verifies that a
unicast IPv6 address is unique.
Virtual Routing Interfaces
• Logical routing interface the ICX device uses to route Layer 3 protocol traffic between
VLANs
– Configure a virtual routing interface on each VLAN that needs routing capabilities
• Routing parameters are configured on the virtual routing interfaces allowing for routing
outside the local switch
– These parameters can include:
• IPv4/v6 addresses
Routing
• Static routing associated with the VE interface
(next hop)
eth1/1/1 ve10 ve2 ve20
• Routing protocols such as OSPF providing
dynamic routing to and from the VLAN
• Layer 3 redundancy protocols such as
VRRP/VRRP-E VLAN VLAN VLAN
10 2 22
A virtual interface is a logical port associated with a Layer 3 Virtual LAN (VLAN)
configured on a Layer 3 switch. You can configure routing parameters on the virtual
interface to enable the Layer 3 switch to route protocol traffic from one Layer 3 VLAN
to the other, without using an external router.
You can configure IP routing interface parameters on a virtual interface, including:
• Configuring IPv4 and IPv6 addresses
• Configure static routing which points to a VE as the next-hop
• Configure and enable dynamic routing protocols, including OSPF and BGP
• Configure Layer 3 gateway redundancy protocols such as VRRP and VRRP-E
Configuring Routable VLANs
• Configure port-based VLAN

– Associate Tagged and/or untagged ports
– Define Virtual Interface (VE)
ICX-Router(config)# vlan 10
ICX-Router(config-vlan-10)# tagged e 1/1/5 to 1/1/10
Added tagged port(s) ethe 1/1/5 to 1/1/10 to port-vlan 10.
ICX-Router(config-vlan-10)# router-interface ve 10
• Configure the virtual Ethernet (VE) interface

– Assign an IP address
ICX-Router(config)# interface ve 10
ICX-Router(config-vif-10)# ip address 10.1.1.1/24
ICX-Router(config-vif-10)# ipv6 address 2001:db8:12d:1011::/64 eui-64
– Optionally configure routing protocols
Routing between VLANs is accomplished by defining a virtual router interface, and

assigning an IP address to the virtual interface. Hosts within the subnet set their
default gateway to the IP address that has been assigned to the virtual interface.
A virtual Ethernet (VE) interface can be configured on a VLAN with the router-
interface command. While ports are not required to be assigned to the VLAN to
configure the VE, the IP interface will not transition to an UP state until ports are
added and devices are connected.
The configuration parameters for VE interfaces are the same as when you configure a
physical interface for routing.
ICX devices use the lowest MAC address on the device (the MAC address of port 1/1)
as the MAC address for all ports within all virtual routing interfaces you configure on
the device. However, this MAC can be changed using the ip-mac command while in
the interface’s configuration context.
Configuring Routable VLANs (cont.)
ICX-Router(config)# vlan 2
ICX-Router(config-vlan-2)# untag ethernet 1/1/11 to 1/1/16
ICX-Router(config-vlan-2)# router-interface ve 2
ICX-Router(config-vlan-2)# interface ve 2
ICX-Router(config-vif-2)# ipv6 address
2001:db8:12d:2::/64 eui-64
ICX-Router(config-vif-10)# vlan 22
ICX-Router(config-vlan-22)# untag ethernet 1/1/17 to 1/1/24
ICX-Router(config-vlan-22)# router-interface ve 20 Not required
to match
ICX-Router(config-vlan-22)# interface ve 20 (but should)
ICX-Router(config-vif-2)# ipv6 address 2001:db8:12d:22::/64 eui-64
Here we have examples adding additional VLANs and VEs. In VLAN 2, router interface
VE 2 is created and in VLAN 22, VE 20 is created. Notice that VLAN 22 does not have
the same ID value as its router interface (VE20). These are two values are not
required to match however it is a best practice to do so.
The graphic shows that, upon creation, each of theses virtual interfaces, as well as
the physically interface configured earlier are “connected to the same routing engine
of the switch. This allows local routing between devices that are connected to these
interfaces (virtual and physical) to communicate, as long as those devices are
properly configured themselves.
Interface and VEs in IP Route Table
• If the interfaces with IP addresses configured are up, their routes will be present in the IP
route table
– A tagged or untagged port member of a VLAN must be up in order for the VE interface in the same VLAN
to be up
ICX# show ip route

Total number of IP routes: 4
Type Codes - B:BGP D:Connected O:OSPF R:RIP S:Static; Cost - Dist/Metric
BGP Codes - i:iBGP e:eBGP
OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2
Destination Gateway Port Cost Type Uptime
1 10.1.1.0/24 DIRECT ve 10 0/0 D 1m59s
2 10.168.1.0/24 DIRECT e 1/1/1 0/0 D 2m53s
3 192.123.2.0/24 DIRECT ve 2 0/0 D 0m38s
4 192.123.22.0/24 DIRECT ve 20 0/0 D 0m4s
Jumbo Frames and MTU
• Hardware forwarding of Layer 2 jumbo frames is supported

ICX-Router(config)# jumbo
– Reload of the device is required for this change to take effect
• When jumbo frame support is enabled, the IP Maximum Transmission Unit (MTU) default
value increases based on Ethernet encapsulation type:
– Ethernet II – From 1,500 to 10,178
– SNAP – From 1,492 to 10,174
• IP MTU values can be decreased per interface if necessary

– May cause IP payload fragmentation
ICX-Router(config-if-e1000-1/1/1)# ip mtu 1300
• Syntax: [no] ip mtu value
ICX devices support Layer 2 jumbo frames on 10/100, 10/100/1000, 40GbE and
10GbE ports. Conventionally, jumbo frames can carry up to 9,000 bytes MTU. In cut-
through mode, in jumbo mode, the MTU is 10200 which uses 20 buffers. In non-
jumbo mode MTU is 1522 which uses 3 buffers. Support for jumbo frames can be
enabled using the jumbo command.
When jumbo mode is not enabled, the maximum Ethernet MTU sizes are as follows:
• 1,500 bytes - The maximum for Ethernet II encapsulation (Default MTU: 1500)
• 1,492 bytes - The maximum for SNAP encapsulation (Default MTU: 1492)
When jumbo mode is enabled, the maximum Ethernet MTU sizes are as follows:
• 10,178 bytes - The maximum for Ethernet II encapsulation
• 10,174 bytes - The maximum ‐ for SNAP encapsulation
Layer 3 Features
Address Resolution Protocol (ARP)
• ARP is a Layer 2 (L2) protocol used to determine a MAC address when only an L3 IP address
is known
– Each device caches any discovered MAC addresses in a table
• The table is a mapping of IP addresses to MAC addresses
• Addresses are typically cached for 300 seconds by default
• To display the ICX ARP caching table

ICX# show arp
Total number of ARP entries: 3
Entries in default routing instance:
No. IP Address MAC Address Type Age Port Status
1 10.25.224.1 02e0.526a.3e3e Dynamic 0 1/1/1 Valid
2 10.25.224.2 001b.ed0c.c200 Dynamic 2 3/1/13 Valid
3 10.25.224.3 001b.ed0f.bc00 Dynamic 0 1/1/22 Valid
If a host wants to send a message to some other device on the LAN and knows its
destination IP address, the host must discover the Ethernet MAC address of the
target. This requirement occurs because Ethernet hardware does not understand IP
protocols or IP addresses. The destination IP address is associated with a MAC
address belonging to the target, and is present on the LAN.
Before sending an IP packet, the host must send a broadcast message onto the LAN
using ARP to discover the MAC address of its intended target. The switch or router
that has that MAC address in its tables can now send its IP packet to the destination.
The host’s operating system also stores the newly discovered MAC address in a table
(the result is cached). This table of mappings from IP addresses to MAC addresses is
retained and consulted multiple times, so the ARP discovery procedure only has to be
performed if the ARP cache does not have an entry.
A timer is set when information is entered into the ARP cache. Mappings occur when
the timer expires (five minutes by default for most devices).
ARP Aging
• ARP entries for learned devices age out of the ARP cache at a set interval
– Default ARP age interval is 10 minutes
• ARP age interval can be adjusted globally, for all IP interfaces

ICX(config)# ip arp-age 24
– Syntax: [no] ip arp-age age-time
• age-time - Specifies the ARP age time in minutes. Valid range is from 0 to 240, 0 disables aging. The default is 10
minutes.
• ARP age can be overridden per interface

ICX(config)# interface eth 1/1/1
ICX(config-if-e1000-1/1/1)# ip arp-age 30

ICX(config-vif-3000)# ip arp-age 60
When the Layer 3 switch places an entry in the ARP cache, the Layer 3 switch also
starts an aging timer for the entry. The aging timer ensures that the ARP cache does
not retain learned entries that are no longer valid. An entry can become invalid when
the device with the MAC address of the entry is no longer on the network.
The ARP age affects dynamic (learned) entries only, not static entries. The default ARP
age is ten minutes. On Layer 3 switches, you can change the ARP age to a value from
0 through 240 minutes. If you set the ARP age to zero, aging is disabled and entries
do not age out. You cannot change the ARP age on Layer 2 switches.
The following task configures the ARP aging time globally.
1. Enter the global configuration mode
device# configure terminal
2. Enter the ip arp-age command followed by the aging time in minutes.
device(config)# ip arp-age 100
The following task overrides the global ARP aging time.
1. Enter the global configuration mode
device# configure terminal
2. Specify the interface to be configured in the interface mode.
device(config)# interface ethernet 1/1/1
3. Enter the ip arp-age command followed by the aging time in minutes.
device(config-if-e1000-1/1/1)# ip arp-age 30
Static ARP Entries
• Static entries are useful in cases:

– Pre-configure ARP entries
– Prevent entries from aging out
– Help speed access for frequently used servers/hosts
ICX(config)# arp 10.53.4.2 1245.7654.2348 ethernet 1/1/2
– Syntax: [no] arp ip-address mac-address { ethernet unit/slot/port | lag lag-id | inspection }
• The ethernet unit/slot/port option specifies the port number attached to the device that has the MAC address of
the entry
• The lag lag-id option specifies the LAG interface attached to the device that has the MAC address of the entry
• The inspection option is related to the Dynamic ARP Inspection (DAI) feature which will be covered in another
section of this course
Static ARP entries are added to the ARP cache when they are configured. Static ARP
entries are useful in cases where you want to pre-configure an entry for a device that
is not connected to the Layer 3 switch, or you want to prevent a particular entry from
aging out.
Ruckus Layer 3 switches have a static ARP table, in addition to the regular ARP cache.
Unlike static ARP entries, dynamic ARP entries are removed from the ARP cache if the
ARP aging interval expires before the entry is refreshed. Static entries do not age out,
regardless of whether the Ruckus device receives an ARP request from the device
that has the entry address.
Enter the following command to create a static ARP entry in the ARP cache.
device(config)# arp 10.53.4.2 0000.0054.2348 ethernet 1/1/2
NOTE: You cannot create static ARP entries on a Layer 2 switch.
Route-only
• By default, Ruckus Layer 3 devices support Layer 2 switching
• Layer 2 switching can be disabled globally or on individual ports with the route-only
command
• The route-only feature can be configured globally, causing all ports to disable Layer 2
switching functionality
ICX-Router(config)# route-only
• Individual ports can be configured to allow Layer 2 switching functionality

ICX-Router(config)# interface ethernet 1/1/17 to 1/1/18
ICX-Router(config-mif-1/1/17-1/1/18)# no route-only
– These ports will now allow layer 2 switching between them and could still support Layer 3 forwarding with
a VE interface
Enabling or disabling layer 2 switching:

By default, Ruckus Layer 3 devices support Layer 2 switching. If you want to disable
Layer 2 switching, you can do so globally or on individual ports, depending on the
version of software your device is running.
Be aware of the following restrictions and limitations when disabling Layer 2
switching:
• Enabling or disabling Layer 2 switching is supported in Layer 3 software images
only.
• Ruckus ICX devices support disabling Layer 3 switching at the interface
configuration mode as well as the global configuration mode.
• Enabling or disabling Layer 2 switching is not supported on virtual interfaces.
The system will allow you to enable any L2 (switching protocols) even if route-only is
configured, but they will not work.
Any protocol that needs to be switched in the same broadcast domain will not work if
route-only is configured.
Displaying the IPv4 Route Table

ICX-Router# show ip route
1 10.1.1.0/24 DIRECT ve 10 0/0 D 1m20s
2 10.45.6.0/24 DIRECT e 1/1/1 0/0 D 5m16s
3 192.123.2.0/24 DIRECT ve 2 0/0 D 2m4s
4 192.123.22.0/24 DIRECT ve 20 0/0 D 0m35s
– Destination — The destination network and network mask of the route

– Gateway — The next-hop router
– Port — The local router port used to send packets to the destination route
– Cost — The route's cost or metric
– Type — The source of the learned route
Here is an example of an entry in the IP route table. It is displayed when the show ip
route command is executed.
Each IP route table entry contains the destination IP address and subnet mask and
the IP address of the next-hop router interface to the destination. Each entry also
indicates the port attached to the destination or the next-hop to the destination, the
route IP metric (cost), and the type. The type column indicates how the IP route table
received the route.
The route type, can be one of the following:
• B - The route was learned from BGP.
• D - the destination is directly connected to this Ruckus device.
• R- The route was learned from RIP.
• S - The route is a static route.
• * - The route is a candidate default route.
• O - The route is an OSPF route. Unless you use the OSPF option to display the
route table, 'O' is used for all OSPF routes. If you do not use the OSPF option,
the following type codes are used:
• O - OSPF intra area route (within the same area.)
• IA - The route is an OSPF inter area route (a route that passes from one area
in another area.)
• E1 - The route is an OSPF external type 1 route.
• E2 - The route is an external type 2 route.
Displaying the IPv6 Route Table

ICX-Router# show ipv6 route
IPv6 Routing Table - 4 entries:
Type Codes: C - Connected, S - Static, R - RIP, O - OSPF, B - BGP
OSPF Sub Type Codes: O - Intra, Oi - Inter, O1 - Type1 external, O2 - Type2
external
Type IPv6 Prefix Next Hop Router Interface Dis/Metric
C 2000:4::/64 :: ethe 1/3/2 0/0
C 2001:DB8:46a::/64 :: ethe 1/3/2 0/0
C 2001:DB8::1/128 :: loopback 2 0/0
O 2001:DB8::2/128 fe80::2e0:52ff:fe91:bb37 ethe 1/3/2 110/1
– Type — The source of the learned route

– IPv6 Prefix — The destination network and network mask of the route
– Next Hop Router — The next-hop router
– Interface — The local router port used to send packets to the destination route
– Dis/Metric — The route’s administrative distance and metric value
Here is an example of an entry in the IPv6 route table. It is displayed when the show
ipv6 route command is executed.
Each IPv6 route table entry contains the destination IP address and subnet mask and
the IP address of the next-hop router interface to the destination. Each entry also
indicates the port attached to the destination or the next-hop to the destination, the
route IP metric (cost), and the type. The type column indicates how the IP route table
received the route.
The route type, can be one of the following:
• C - the destination is directly connected to this Ruckus device
• S - The route is a static route
• R- The route was learned from RIPng
• O - The route is an OSPFv3 route. Unless you use the OSPF option to display the
route table, 'O' is used for all OSPF routes. If you do not use the OSPF option,
the following type codes are used:
• O - OSPF intra area route (within the same area.)
• Oi - The route is an OSPF inter area route (a route that passes from one area
in another area.)
• O1 - The route is an OSPF external type 1 route
• O2 - The route is an external type 2 route
• B - The route was learned from BGP4
Learning IP Routes
• Routing tables are populated by:
– Directly connected routes — The networks that are directly connected to the router are always known
and added to the routing table
• A router knows a network is reachable because it has an interface in the address range
– Static routes — Manually configured on the router

• Network Administrator instructs a router to send packets for remote network to another neighboring router
– Dynamic routes — A routing protocol populates routes it has learned from other routers
• A router learns of remote networks from a neighboring router
The IP route table contains paths to IP destinations.

The IP route table can receive the paths from the following sources and it can contain
leaked routes as well (from other VRFs).
• A directly-connected destination, which means there are no router hops to the
destination
• A static IP route, which is a user-configured route
• A route learned through dynamic routing protocols, including:
• RIP
• OSPF
• BGP4
The IP route table contains the best path to a destination:
• When the software receives paths from more than one of the sources listed
above, the software compares the administrative distance of each path and
selects the path with the lowest administrative distance. The administrative
distance is a protocol-independent value from 0 through 255.
• When the software receives two or more best paths to a destination and the
paths have the same metric (cost), the software can load share traffic among
the paths based on destination host or network address (based on the
configuration and the Layer 3 device model).
Static Routes
• A static route is created manually by a network administrator and is locally significant

• Each router in a data path needs a next-hop route to reach the destination
Router A Router B Router C

10.1.2.2/30 10.1.1.2/30
192.168.1.0/24 10.1.2.1/30 10.1.1.1/30 172.16.1.0/24
Generic Configuration Example

Router_A(config)# ip route 172.16.1.0/24 10.1.2.1
Router_B(config)# ip route 172.16.1.0/24 10.1.1.1
Router_C(config)# ip route 192.168.1.0/24 10.1.1.2
A static route is a route manually created by a network administrator to instruct a

router how to reach a particular remote network. A local next-hop IP address or a
local outgoing interface number can be used in the static route configuration.
Static routes (when no routing protocols are employed) are only applicable to the
router they are configured on. This means that static routes are likely required on all
routers in a data path to allow end-to-end communications.
Routing is needed when data needs to reach a remote network that is not directly
connected to the local router.
Static routes will be removed from the route table if: the next-hop interface or route
pointing towards the next-hop IP address are offline.
The example in the slide above shows how static routes are configured for the routers
to allow connectivity between the two hosts on the remote networks. However, this
does not mean that all devices in the data path can reach each other. With only the
configuration information provided, Router A is incapable of communicating directly
with Router C. For Router A to communicate with Router C, Router A would require a
static route to the 10.1.1.0/30 network and Router C would require a static route to
10.1.2.0/30.
Static Routes Quiz
Question:
Given the static routes shown, can Host A ping interfaces on the 10.1.1.0/30 network?

10.1.2.2/30 10.1.1.2/30
192.168.1.0/24 10.1.2.1/30 10.1.1.1/30 172.16.1.0/24
Host A Host B

Router_C(config)# ip route 192.168.1.0/24 10.1.1.2
Answer: No
There is no route to the 10.1.1.0/30 network in Router_A
Default Routes
• A default route is used when an explicit route to a destination network is not known
– Is last in the order of execution of the routing table and can be dynamically learned by a routing protocol
– To configure a static default route:

Router_A(config)# ip route 0.0.0.0/0 10.1.2.1 distance 115
• Syntax: [no] ip route dest-ip-addr next-hop-addr [ metric ] [ distance distance ] [ name string ] [ tag tag ]
You can manually create a static default route that the router uses if there are no
other routes to a destination network.
To configure a static default route, use the ip route command with 0.0.0.0 0.0.0.0 as
the destination route and network mask followed by a valid next-hop address.
device(config)# ip route 0.0.0.0 0.0.0.0 10.24.4.1
This example on the slide configures two different default routes however the second
has a higher administrative distance. If both routes are available the first will be
preferred because of its more favorable Administrative Distance (default 1). If the first
route becomes unavailable the second route will then be placed into the routing
table allowing for an alternate path as a default route.
Default Route in IP Routing Table
• The default route is always displayed first in the IP routing table, as it is the least specific
ICX-Router# show ip route

1 0.0.0.0/0 10.45.6.2 e 1/1/1 1/1 S 0m3s
2 10.1.1.0/24 DIRECT ve 10 0/0 D 17m20s
3 10.45.6.0/24 DIRECT e 1/1/1 0/0 D 21m16s
4 192.123.2.0/24 DIRECT ve 2 0/0 D 18m4s
5 192.123.22.0/24 DIRECT ve 20 0/0 D 16m35s
If you configure 10.1.1.0/24 as a candidate default network route, if the IP route table
does not contain an explicit default route (0.0.0.0/0), the software uses the default
network route and automatically uses that route's next hop gateway as the default
gateway. If a topology change occurs and as a result the default network route's next
hop gateway changes, the software can still use the default network route.
However, if a default route is configured, the default network will only be used if the
default route becomes invalid and is removed from the IP routing table.
Null Route
• Null route is a static route that drops packets going to a specific network or host address
– Sometimes referred to as a “null 0” or “black hole” route
– A quick and easy way to block traffic going to a single route such as:
• Restricted websites
• Illegal IP address filtering
• Unused subnets within a summarized route1
• Attack mitigation (DDoS)
• To configure a null route to drop traffic destined for network 10.255.22.0:
ICX-Router(config)# ip route 10.255.22.0/24 null0
Footnote 1: When routes are summarized the ICX device will automatically add a null
route for the summarized address range to prevent routing loops.
You can configure a null static route to drop packets to a certain destination. This is
useful when the traffic should not be forwarded if the preferred route is unavailable.
Null Route in IP Route Table
• Null routes are displayed in the IP routing table with a port of drop
ICX-Router(config)# show ip route

1 0.0.0.0/0 10.45.6.2 e 1/1/1 1/1 S 17h48m
2 10.1.1.0/24 DIRECT ve 10 0/0 D 18h5m
3 10.45.6.0/24 DIRECT e 1/1/1 0/0 D 18h9m
4 10.255.22.0/24 DIRECT drop 1/1 S 0m3s
5 192.123.2.0/24 DIRECT ve 2 0/0 D 18h6m
6 192.123.22.0/24 DIRECT ve 20 0/0 D 18h4m
In the IP routing table, a null route is identified with the word “drop” in the port
column of the show ip route output.
Access Control Lists (ACLs)
IPv4/IPv6 ACLs
• IPv4 and IPv6 access control lists (ACLs) permit or deny packets according to defined rules
• ACLs include the following benefits:

– Providing security and traffic management
– Monitoring network and user traffic
– Saving network resources by classifying traffic
– Protecting against denial of service (DoS) attacks
• ICX ACLs are programmed into the Content Addressable Memory (CAM)
– Packets are permitted or denied in the hardware
– No requirement to send the packets to the CPU for processing
Layer 3 (IPv4 and IPv6) access control lists (ACLs) permit or deny packets according to
rules included in the ACLs.
When a packet is received or sent, the device compares its header fields against the
rules in applied ACLs. This comparison is done according to a rule sequence, which
you can specify. Based on the comparison, the device either forwards or drops the
packet.
ACLs include the following benefits:
• Providing security and traffic management
• Monitoring network and user traffic
• Saving network resources by classifying traffic
• Protecting against denial of service (DoS) attacks
Because applied ACLs are programmed into the Content Addressable Memory (CAM),
packets are permitted or denied in the hardware, without sending the packets to the
CPU for processing.
General Guidelines for Using ACLs
• By default, all packets are allowed on an ICX switch
• When an ACL is applied to a interface, all traffic not explicitly permitted is denied/blocked
• When a packet is received or sent, the device compares its header fields against the rules
in applied ACLs
– Comparison follows a specified rule sequence
• The sequence of rules in an ACL is critical
• The first rule that matches the traffic stops further processing of the packet
– Based on the comparison, the device either forwards or drops the packet
• There is an implicit deny all statement at the end of each ACL

– All traffic not specifically permitted will be automatically denied
The default action when no ACLs are configured on a device is to permit all traffic.
However, once you configure an ACL and apply it to a port, the default action for that
port is to deny all traffic that is not explicitly permitted on the port:
• If you want to tightly control access, configure ACLs consisting of permit entries
for the access you want to permit. The ACLs implicitly deny all other access.
• If you want to secure access in environments with many users, you may want to
configure ACLs that consist of explicit deny entries, and then add an entry to
permit all access to the end of each ACL. The software permits packets that are
not denied by the deny entries.
IPv4 and IPv6 ACL Flow
• Layer 3 ACLs are implemented using the following flow:
1. Create the ACL, using the ip access-list or ipv6 access-list command
2. Define permit and deny rules, using the optional sequence numbers and deny or permit command
3. Apply the ACL to one or more interfaces, using the relevant command:
• IPv4: ip access-group
• IPv6: ipv6 traffic-filter
IPv4 ACLs
• There are two types of filtering options for IPv4 ACLs

– Standard ACLs: Permit or deny traffic according to source address only.
– Extended ACLs: Permit or deny traffic according to source and destination addresses, as well as other
parameters
• There are two naming types for IPv4 ACLs:

– Numbered ACLs
• You can assign numbers 1 through 99 to standard numbered IPv4 ACLs
• You can assign numbers 100 through 199 to extended numbered IPv4 ACLs
– Named ACLs, which must begin with an alphabetical character
• How to configure and apply IPv4 ACLs:

1. Create the ACL, using the ip access-list command
2. Define permit and deny rules, using the sequence option when necessary
3. Apply the ACL to one or more interfaces, using the ip access-group command
Standard ACLs filter exclusively on source addresses. The default action is to deny all
traffic that has not been explicitly permitted. Permitted or denied packets can be sent
to the system log.
Extended ACLs permit or deny traffic according to source and destination addresses,
as well as other parameters, including:
• Port name or number
• Protocol (for example, TCP or UDP)
• TCP flags
In ICX release 8.0.90, there are two naming types for IPv4 standard and extended
ACLs that be configured; numbered and named.
Standard numbered ACLs can be in the numerical range of 1-99. Extended numbered
ACLs can be in the numerical range of 100-199. If the number selected is outside of
this range of the selected type when configuring, an error will be generated.
Named ACLs allow you to configure a user friendly name for the ACL. Named ACLs
must begin with an alphabetic character.
While ACLs can be used for many purposes, the basic process of configuring and
applying ACLs is to create the ACL globally, then assign it to one or more interfaces.
Configuring Standard ACLs
• Enter the ip access-list standard command to create the ACL

ICX(config)# ip access-list standard 19
ICX(config-std-nacl)#
– Syntax: [no] ip access-list standard { acl-num(1-99) | acl-name }
• For each rule, enter the deny or permit command, specifying the needed parameters:
ICX(config-std-nacl)# permit host 10.157.10.26 log
ICX(config-std-nacl)# deny 10.157.10.0 0.0.0.255 log
ICX(config-std-nacl)# deny 10.157.20.0/24 log
ICX(config-std-nacl)# permit any
– Partial Syntax: [ permit | deny ] { S_IPaddress [ mask ] | host S_IPaddress | any } [ log ] [ mirror ]
• Apply the ACL to an interface:

ICX(config-if-e1000-1/1/1)# ip access-group 19 in
– Syntax: [no] ip access-group { acl-num | acl-name } { in | out }
Standard ACL deny/permit Syntax:

The S_IPaddress parameter specifies the source IP address or hostname for the
policy. If you want the policy to match on all source addresses, enter any.
The mask parameter specifies the portion of the source IP host address to match
against. The mask is a four-part value in dotted-decimal notation (IP address format)
consisting of ones and zeros. Zeros in the mask mean the packet’s source address
must match the S_IPaddress. Ones mean any value matches.
For example, the S_IPaddress and mask values 209.157.22.26 0.0.0.255 mean that all
hosts in the Class C sub-net 209.157.22.x match the policy.
If you prefer to specify the mask value in Classless Interdomain Routing (CIDR)
format, you can enter a forward slash after the IP address, then enter the number of
significant bits in the mask. For example, you can enter the CIDR equivalent of
“209.157.22.26 0.0.0.255” as “209.157.22.26/24”. The CLI automatically converts the
CIDR number into the appropriate ACL mask (where zeros instead of ones are the
significant bits) and changes the non-significant portion of the IP address into zeros.
For example, if you specify 209.157.22.26/24 or 209.157.22.26 0.0.0.255, then save
the changes to the startup-config file, the value appears as 209.157.22.0/24 (if you
have enabled display of sub-net lengths) or 209.157.22.0 0.0.0.255 in the startup-
config file.
The host option Indicates the source IP address is a host address. When used, the
system automatically applies a 0.0.0.0 (or /32) mask to the S_IPaddress.
Display ACLs
• To display ACLs, use the show access-list command followed by the ACL number or name
ICX(config)# show access-list 19

Standard IP access list 19 : 3 entry
10: permit host 10.157.10.26 log
20: deny 10.157.10.0 0.0.0.255 log
30: deny 10.157.20.0 0.0.0.255 log
40: permit any
– Syntax: show access-list { std-acl-num | extd-acl-num | named-acl acl-name | all }
• Each statement is automatically given a sequence number, when not specified

– Sequence numbers begin at 10 and increase by ten with each statement added
For details of commands for displaying IPv4 ACLs, refer to the following commands in
the Ruckus FastIron Command Reference Guide:
• show access-list
• show access-list accounting
• show access-list named-acl
• show ip access-lists
To display the number of Layer 4 CAM entries used by each ACL, enter the following
command:
device# show access-list all
Extended IP access list 100 (Total flows: N/A, Total packets: N/A,
Total rule cam use: 3)
permit udp host 192.168.2.169 any (Flows: N/A, Packets: N/A, Rule
cam use: 1)
permit icmp any any (Flows: N/A, Packets: N/A, Rule cam use: 1)
deny ip any any (Flows: N/A, Packets: N/A, Rule cam use: 1)
The Rule cam use field lists the number of CAM entries used by the ACL or entry. The
number of CAM entries listed for the ACL itself is the total of the CAM entries used by
the ACL entries.
For flow-based ACLs, the Total flows and Flows fields list the number of Layer 4
session table flows in use for the ACL.
The Total packets and Packets fields apply only to flow-based ACLs.
Adding Statements to Existing ACLs
• Based on the ACL configured on the previous slide, only one host on the 10.157.10.0/24
subnet will be permitted
• What if you wanted to allow another host? Would adding the following statement to the
existing ACL work?
10.157.10.0/24 Subnet ICX(config)# ip access-list standard 19

ICX(config-std-nacl)# permit host 10.157.10.45 log
Host
10.157.10.45
Host
10.157.10.26
Sequence Matters
• After the change shown on the previous slide is applied:

20: deny 10.157.10.0 0.0.0.255 log
30: deny 10.157.20.0 0.0.0.255 log
40: permit any
• The filter at sequence 20 will match and deny the packet before sequence 50
• Statements can be added to ACLs between existing statements with sequence command
ICX(config-std-nacl)# sequence 15 permit host 10.157.10.45 log
You can specify and modify the sequence in which ACL rules are applied to traffic. By
default, the order in which ACL rules run is determined by the sequence in which they
are added to the ACL. Beginning with FastIron 08.0.50—preserving this order—
sequence numbers are automatically added to existing ACL rules in the following
manner:
• The first rule within each ACL is numbered 10.
• The sequence number for each succeeding rule is incremented by 10.
In new ACLs that you create, specifying rule sequence numbers is optional. However,
sequence numbers are assigned automatically in the previously mentioned order.
Sequence numbers have the following advantages:
• If you need a new rule to run between existing rules, you assign the new rule a
sequence number between those two rules.
• New rules are implemented seamlessly, with no need to re-apply ACLs.
• If you delete a rule, there is no need to re-apply the ACL.
If you add a rule to an ACL without specifying its sequence, the rule is added at the
end of the list. Such a rule is automatically assigned the next multiple of 10 as a
sequence number.
Sequence Matters (cont.)
• New permit statement is inserted between sequence 10 and 20:

20: deny 10.157.10.0 0.0.0.255 log
30: deny 10.157.20.0 0.0.0.255 log
40: permit any
• Statements can be removed from an ACL by identifying sequence number

ICX(config-std-nacl)# no sequence 50
Deleting statements is accomplished with the no sequence command within the

access list configuration context. Displaying the access-list will confirm the removal of
the statement:
20: deny 10.157.10.0 0.0.0.255 log
30: deny 10.157.20.0 0.0.0.255 log
40: permit any
Resequencing ACLs
• Sequence numbers can be reverted back to sequence-numbering-by-tens

• Use the regenerate-seq-number command within the access-list configuration context

ICX(config-std-nacl)# regenerate-seq-number
ICX(config-std-nacl)# show access-list 19
30: deny 10.157.10.0 0.0.0.255 log
40: deny 10.157.20.0 0.0.0.255 log
50: permit any
If you prefer the sequence numbers to revert back to sequence-numbering-by-tens,

you can regenerate them with the regenerate-seq-number command within the
access-list configuration context.
Extended ACLs
• Extended ACLs permit or deny traffic according to source and destination addresses, as
well as other parameters
– For example, in an extended ACL, you can also filter by one or more of the following parameters:
• Port name or number
• Protocol (for example, TCP or UDP)
• TCP flags
• There are two types of IPv4 extended ACLs:

– Numbered ACLs
• You can assign numbers 100 through 199 to extended numbered IPv4 ACLs
– Named ACLs, which must begin with an alphabetical character
• How to configure ACLs:

– Define the ACL(s) globally
– Assign them to interface(s)
Extended ACLs filter traffic according to source and destination addresses, as well as
other parameters. The default action is to deny all traffic that has not been explicitly
permitted. Permitted or denied packets can be referenced in the system log.
In ICX release 8.0.90, there are two types of IPv4 extended ACLs that be configured;
numbered and named.
Numbered extended ACLs can be in the numerical range of 100-199. If the number
selected is outside of this range when configuring an extended ACL, an error will be
generated.
Named ACLs allow you to configure a user friendly name for the ACL. Named ACLs
must begin with an alphabetic character.
While ACLs can be used for many purposes, the basic process of configuring and
applying ACLs is to create the ACL globally, then assign it to one or more interfaces.
Extended ACL Protocols
• Extended ACLs let you filter packets based on the protocols

• You can either specify a protocol number (from 0 through 255) or a supported protocol
name, for example:
Protocol CLI Protocol Acronym Number
Internet Control Message Protocol ICMP 1
Internet Group Management Protocol IGMP 2
Open Shortest Path First OSPF 89
Transmission Control Protocol TCP 6
User Datagram Protocol UDP 17
• Different protocols allow unique filtering options

– TCP/UDP – Allow filtering of port numbers with comparison operators (=, >, <, ≠, and range)
– ICMP – Allows filtering on specific ICMP numbers and types
Use the following syntax to define a TCP or UDP rule that will deny or permit packets:
[ no ] [deny | permit] { tcp | udp } { S_IPaddress [ mask ] | host S_IPaddress | any
} [ source-comparison-operators ] { D_Ipaddress [ mask ] | host D_IPaddress | any }
[ established ] [ destination-comparison-operators ] [ precedence {
precedencename | precedence-value } ] [ tos { tos-name | tos-value } ] [ dscp-
matching dscp-value ] [ dscp-marking dscp-value ] [ 802.1p-priority-matching
802.1p-value ] [ 802.1p-priority-marking 802.1p-value ] [ internal-priority-
marking queuing-priority ] [ 802.1p-and-internal-marking priority-value ] [ traffic-
policy name ] [log] [mirror]
Use the following syntax to define an ICMP rule that will deny or packets:
[ no ] [deny | permit] icmp { S_IPaddress [ mask ] | host S_IPaddress | any } {
D_IPaddress [ mask ] | host D_IPaddress | any } [ icmpnum | icmp-type ] [
precedence { precedence-name | precedence-value } ] [ tos { tos-name | tos-value }
] [ dscpmatching dscp-value ] [ dscp-marking dscp-value ] [ 802.1p-priority-
matching 802.1p-value ] [ 802.1p-prioritymarking 802.1p-value ] [ internal-
priority-marking queuing-priority ] [ 802.1p-and-internal-marking priority-value ] [
traffic-policy name ] [ log ] [ mirror ]
Use the following syntax to define a rule for protocols other than TCP, UDP, or ICMP
that will deny or permit packets:
[ no ] [deny | permit] ip-protocol { S_IPaddress [ mask ] | host S_IPaddress | any }
{ D_IPaddress [ mask ] | host D_IPaddress | any } [ precedence { precedence-name
| precedence-value } ] [ tos { tos-name | tos-value } ] [ dscp-matching dscp-value ] [
dscp-marking dscp-value ] [ 802.1p-priority-matching 802.1p-value ] [ 802.1p-
priority-marking 802.1p-value ] [ internal-priority-marking queuing-priority ] [
802.1p-and-internal-marking priority-value ] [ traffic-policy name ] [log] [mirror]
ip-protocol
Specifies the type of IPv4 packet to filter. You can either specify a protocol number
(from 0 through 255) or a supported protocol name. For a complete list of protocols,
type ? after deny. Supported protocols include:
• icmp—Internet Control Message Protocol
• igmp—Internet Group Management Protocol
• igrp—Internet Gateway Routing Protocol
• ip—any IPv4 protocol
• ospf—Open Shortest Path First
• tcp—Transmission Control Protocol
• udp—User Datagram Protocol
S_IPaddress
Specifies a source address for which you want to filter the subnet.
D_IPaddress
Specifies a destination address for which you want to filter the subnet.source-
comparison-operators and destination-comparison-operators
If you specified tcp or udp, the following optional operators are available:
• eq - Specifies the address is equal to the port name or number you enter after
eq.
• gt - Specifies port numbers that are equal to or greater than the port number or
that are equal to or greater than the numeric equivalent of the port name you
enter after gt.
• lt - Specifies port numbers that are equal to or less than the port number or
that are equal to or less than the numeric equivalent of the port name you
enter after lt.
• neq - Specifies all port numbers except the port number or port name you enter
after neq.
• range - Specifies all port numbers that are between the first port name or
number and the second name or number you enter following the range
keyword. Enter the range as two values separated by a space. The first port
number in the range must be less than the last number in the range. For
example, to apply the policy to all ports between and including 23 (Telnet) and
53 (DNS), enter the following: 23 53 .
Configuring Extended ACLs
• Enter the ip access-list extended command to create the ACL

ICX(config)# ip access-list extended block_telnet
ICX(config-std-nacl)#
– Syntax: [no] ip access-list extended { acl-num(100-199) | acl-name }
ICX(config-ext-nacl)# deny tcp host 209.157.10.26 any eq telnet log
ICX(config-ext-nacl)# permit ip any any
– Basic Syntax: [ permit | deny ] { tcp | udp } { S_IPaddress [ mask ] | host S_IPaddress | any } { D_Ipaddress
[ mask ] | host D_IPaddress | any } [ log ] [ mirror ]
• Apply the ACL to an interface with ip access-group command

– Same as standard ACLs
The commands in this example configure a extended ACL named block_telnet. The
ACL blocks telnet traffic from the host with IP address 209.157.10.26. The second
entry allows all other traffic types to pass through.
Extended ACL Example
ICX# show access-list named-acl block_telnet

Extended IP access list block_telnet : 2 entry
10: deny tcp host 209.157.10.26 any eq telnet log
20: permit ip any any
Here we see the how traffic is affected by the ACL. Telnet from the denied host is
filtered at the interface while all other traffic types from the host, or any host on the
port, is permitted.
The show access-list named-acl command is used to view standard and extended
named ACLs on an ICX switch.
IPv6 ACLs
• IPv6 ACLs enable traffic filtering based on the following information:

– IPv6 protocol
– Source IPv6 address
– Destination IPv6 address
– IPv6 message type
– Source TCP or UDP port (if the IPv6 protocol is TCP or UDP)
– Destination TCP or UDP port (if the IPv6 protocol is TCP or UDP)
• No concepts of standard or numbered ACLs for IPv6

– All IPv6 ACLs are essentially named, extended ACLs filtering on source and destination information
• IPv6 ACLs have 3 implicit rules at the end of every list:

– permit icmp any any nd-na: Allows ICMP neighbor discovery acknowledgements
– permit icmp any any nd-ns: Allows ICMP neighbor discovery solicitations
– deny ipv6 any any: Denies IPv6 traffic
There are default actions and implicit IPv6 ACL rules.

The default action when no ACLs are configured on an interface is to permit all traffic.
However, once you configure an ACL and apply it to an interface, the default action
for that interface is to deny all traffic that is not explicitly permitted on the interface.
• If you want to tightly control access, configure ACLs consisting of permit rules
for the access you want to permit. The ACLs implicitly deny all other access.
• If you want to secure access in environments with many users, you may want to
configure ACLs that consist of explicit deny rules, with a permit ipv6 any any
rule at the end of each ACL.
IPv6 ACLs have the following concluding implicit rules:
• permit icmp any any nd-na: Allows ICMP neighbor discovery
acknowledgements.
• permit icmp any any nd-ns: Allows ICMP neighbor discovery solicitations.
• deny ipv6 any any: Denies IPv6 traffic. You must enter permit ipv6 any any as
the last statement in the access list if you want to permit IPv6 traffic that was
not denied by the previous statements.
NOTE - In an IPv6 ACL, if you do not override the implicit deny ipv6 any any rule,
make sure to include rules that permit the IPv6 link-local address and the global
unicast address. Otherwise, routing protocols such as OSPF will not work. To view the
link-local address, use the show ipv6 interface command.
IPv6 ACL Configuration
• Enter the ipv6 access-list command to create the ACL

ICX(config)# ipv6 access-list ipv6_test
ICX(config-ipv6-access-list ipv6_test)#
– Syntax: [no] ipv6 access-list acl-name
ICX(config-ipv6-access-list ipv6_test)# deny tcp host 2001:DB8:e0bb::2 any eq telnet
ICX(config-ipv6-access-list ipv6_test)# permit ipv6 any any
– Basic Syntax: [ permit | deny ] { tcp | udp } { S_IPaddress [ mask ] | host S_IPaddress | any } { D_Ipaddress [ mask ] |
host D_IPaddress | any } [ log ] [ mirror ]
• Apply the ACL to an interface with ipv6 traffic-filter command

ICX(config)# interface eth 1/1/1
ICX(config-if-e1000-1/1/1)# ipv6 traffic-filter ipv6_test in
– Syntax: [no] ipv6 traffic-filter acl-name { in | out }
The IPv6 protocol can be one of the following well-known names or any IPv6 protocol
number from 0 through 255:
• Authentication Header (AH) protocol
• Encapsulating Security Payload (ESP)
• Internet Control Message Protocol (ICMP)
• Internet Protocol Version 6 (IPv6)
• Stream Control Transmission Protocol (SCTP)
• Transmission Control Protocol (TCP)
• User Datagram Protocol (UDP)
For TCP and UDP, you also can specify a comparison operator and port name or
number. For example, you can configure a policy to block web access to a specific
website by denying all TCP port 80 (HTTP) packets from a specified source IPv6
address to the website IPv6 address.
IPv6 ACLs also provide support for filtering packets based on DSCP.
Policy Based Routing (PBR)
Policy Based Routing Overview
• Policy Based Routing (PBR) is a mechanism that allows the administrator to identify
incoming packets and forward them out a different next hop interface instead of the one
chosen by the routing protocol
Policy-based routing (PBR) is the process of altering a packet's path based on criteria
other than the destination address. PBR allows you to use access control lists (ACLs)
and route maps to selectively route an IP packet. The ACLs classify the traffic and the
route maps that match on the ACLs set routing attributes for the traffic.
A PBR policy specifies the routing attributes for traffic that matches the policy. Using
standard ACLs with route maps in PBR, an IP packet is routed based on its source IP
address. With extended ACLs, you can route IP packets based on all of the clauses in
the extended ACL.
Policy Based Routing Overview (cont.)
• PBR is locally significant

– Each router along the altered path may need to have a PBR configuration1
• Configured using a match/set process (Route map)

– Traffic to be routed by PBR will be matched using an ACL and then have its path changed using a series of
set commands
• To configure a PBR policy:

– Configure ACLs that contain the source IP addresses for the IP traffic you want to route using PBR
– Configure a route map that matches on the ACLs and sets the route information
– Apply the route map to an interface
Footnote 1: The need for PBR can vary depending on the network design. In some
situations only one router needs to alter the routing path. Because PBR is locally
significant it is possible each router needs to be configured.
The following are the basic steps used to configure a PBR policy:
1. Configure ACLs that specify all the conditions required to match the desired
packets to be routed using PBR.
2. Configure a route map that matches on the ACLs and sets the route information.
3. Enable PBR by applying the route map globally or on an untagged interface or
virtual interface.
Configuration guidelines for IPv4 PBR

• PBR is supported in the full Layer 3 code only.
• PBR is not supported together with ingress ACLs on the same port.
• Global PBR is not supported with per-port-per-VLAN ACLs.
• Global PBR is supported only on the default VRF.
• A PBR policy on an interface takes precedence over a global PBR policy.
• You cannot apply PBR on a port if that port already has ingress ACLs, ACL-based
rate limiting, DSCP-based QoS, or MAC address filtering.
• The number of route maps that you can define is limited by the available system
memory, which is determined by the system configuration and how much
memory other features use. When a route map is used in a PBR policy, the PBR
policy uses up to 21 instances of a route map, up to five ACLs in a matching
policy of each route map instance, and up to six next hops in a set policy of each
route map instance. Note that the CLI allows you to configure more than six
next hops in a route map; however, the extra next hops will not be placed in the
PBR database. The route map could be used by other features such as BGP or
OSPF, which may use more than six next hops.
• Denial of Service (DoS) protection is supported in PBR.
• IPv4 ACL accounting is supported in PBR.
• ACLs with the log option configured in the access-list command should not be
used for PBR purposes.
• PBR will not apply the “set” clause to explicit or implicit deny ip any any ACL
entries to ensure that the traffic is compared to all ACLs for route maps that use
multiple ACLs. PBR also ignores any deny clauses in an ACL. Traffic that matches
a deny clause is routed normally using Layer 3 paths.
• PBR always selects the first next hop from the next-hop list that is up. If a PBR
policy next hop goes down, the policy uses another next hop if available. If no
next hops are available, the device routes the traffic in the normal way.
• PBR is not supported for fragmented packets. If the PBR ACL filters on Layer 4
information such as TCP/UDP ports, fragmented packets are routed normally.
• You can change route maps or ACL definitions dynamically and do not need to
rebind the PBR policy to an interface.
Route Maps
• Route maps are commonly used for policy-based routing but may also be used for:
– Redistribution manipulation between routing protocols
– Route metric modification
– Attribute and route manipulation between BGP neighbors
– Route filtering
• A sequential series of match and set statements that either permit or deny the identified
traffic
– Match statement - can include such things as an interface, IP information, BGP attribute and protocol
types
– Set statement - identified traffic within the match statement can be manipulated by either excluding it
from normal processes, changing its characteristics or its forwarding behavior
Route maps are very versatile and can be used to enhance many routing processes
and protocols. Here we focus on route maps used for policy based routing (PBR).
Route maps enable you to define routing policy for the traffic causing a packet to be
forwarded to a predetermined next-hop interface, bypassing the path determined by
normal routing. Each entry in a route map statement contains a combination of
match and set statements. A route map specifies the match criteria that correspond
to ACLs, followed by a set statement that specifies the resulting action if all of the
match clauses are met. You can define multiple match and next-hop specifications on
the same interface. When a PBR policy has multiple next hops to a destination, PBR
selects the first live next hop specified in the policy that is up. If none of the policy's
direct routes or next hops is available, the packets are forwarded as per the routing
table.
• Match statement – IP standard or extended ACLs can be used to establish the
match criteria. Using the standard ACLs with route maps in PBR, an IP packet is
routed based on its source IP address. Using the extended ACLs, you can route
IP packets based on all of the clauses in the extended ACL.
• Set statement – Traffic that matches a match statement in the route map is
forwarded as defined by set commands. Multiple set commands can be
configured and when a match condition is met, the device works sequentially
through the list of set commands until it finds the first "next hop" that is
operational and uses it. If that "next hop" goes down, the next available next-
hop as defined in a set command is chosen and if all next hop interfaces in the
list are down, the packet is routed as determined in the IP Route Table. If a next-
hop interface that was down comes back up, the next hop selection process
begins again and restarts its selection process from the top of the list.
Route Map for Policy Based Routing (PBR)
• When applied to an interface:

– Received traffic is filtered through the route map
– Traffic that is identified (matched) within the route map will be subject to the set statement within the
route map
• Basic configuration steps:

– Create ACL
ICX(config)# access-list 1 permit 10.1.1.0 0.0.0.255
– Create route map
ICX(config)# route-map prvt_ip permit 10
– Define match criteria1
ICX(config-routemap prvt_ip)# match ip address 1
– Define set action2
ICX(config-routemap prvt_ip)# set interface null0
Footnote 1: Available match options are dependent on the ICX hardware platform
used and licenses applied.
Footnote 2: Available set options are dependent on the ICX hardware platform used
and licenses applied.
Route maps are configured globally with the route-map command.
Syntax: [no] route-map map-name [ permit | deny ] num
num - controls the order in which multiple route-maps of the same name are
evaluated, from lowest to highest.
Match statements for PBR match on standard and extended ACLs. With standard
ACLs, only the source IP address is matched. With extended ACLs, filtering can be
based on all of the ACL clauses. This is accomplished with match ip address
command.
Next-hop PBR actions are applied with the set command. Multiple set statements can
be configured and will be applied sequentially, only moving to the next in sequence if
the current next-hop selection is down. If all next-hop options are down, the IP
routing table will be used to forward the packet. If a next-hop of null0 is used, it will
always be processed last, no mater where it is placed in the sequence, and will
prevent the packet from being routed according the IP routing table.
Use Case – HTTP Proxy Service
• Filtering HTTP traffic

through a Proxy server
can be accomplished
by PBR
– All source traffic forwarding
to ports 80 or 443 can be
routed to the proxy server
for processing
• If next-hop is down, drop
RTR1
10.1.2.2
RTR1(config)# ip access-list extended WEB
RTR1(config-ext-nacl)# permit tcp any any eq 80
RTR1(config-ext-nacl)# permit tcp any any eq 443
RTR1(config-ext-nacl)# route-map ForceNH permit 10
RTR1(config-routemap ForceNH)# match ip address WEB
RTR1(config-routemap ForceNH)# set ip next-hop 10.1.2.2
RTR1(config-routemap ForceNH)# set interface null0
In the example, RTR1 is configured with an access list the matches all traffic with the
destination TCP port marked as either 80 or 443.
Next, a route map is created to match the ACL. If the traffic matches the ACL, the next
hop is set to 10.1.2.2.
The last entry in the route map ensures that the default IP forwarding behavior is not
used if the configured next-hop goes down, in that case the traffic is discarded by
routing it to Null0.
Use Case – NAT/Firewall Filtering
• Normal routing would forward traffic from both networks up link N1 because of the
favorable metric
• The 10.x network however needs to be translated into a public IP before it is sent out to
the internet
R1(config)# ip access-list standard 99
R1(config-std-nacl)# permit 10.1.0.0 0.0.1.255
R1(config-std-nacl)# route-map to-nat permit 10
R1(config-routemap to-nat)# match ip address 99
R1(config-routemap to-nat)# set ip next-hop 10.2.2.2
R1(config-routemap to-nat)# set interface null0
10.2.2.2
In the example, router R1 is configured with an access list the matches all traffic
originating from the 10.1.0.0/23 subnet.
Next, a route map is created to match the ACL. If the traffic matches the ACL, the next
hop is set to the address of the firewall/NAT device at 10.2.2.2.
The last entry in the route map ensures that the default IP forwarding behavior is not
used if the configured next-hop goes down, in that case the traffic is discarded by
routing it to Null0.
Use Case – WAN Traffic Forwarding Multiple Exits
• Traffic can be forwarded to a specific exit based on attributes such as source address,
traffic type, ports used, etc.
R1(config)# ip access-list standard Group1

R1(config-std-nacl)# permit 10.255.0.0/16
R1(config-std-nacl)# route-map WAN1 permit 10
R1(config-routemap WAN1)# match ip address Group1
10.10.10.254 10.2.2.2
R1(config-routemap WAN1)# set ip next-hop 10.2.2.2
R1(config-routemap WAN1)# exit
R1(config)# ip access-list standard Group2

R1(config-std-nacl)# permit 10.100.0.0/16
R1(config-std-nacl)# route-map WAN2 permit 10
R1(config-routemap WAN2)# match ip address Group2
R1(config-routemap WAN2)# set ip next-hop 10.10.10.254
In the example, router at the bottom of the image is configured with an two access
lists and route maps. The ACLs match all traffic originating from specific subnets.
Next, a route map are created to match each of the ACLs. If the traffic matches the
ACLs, the next hop is set to one of the WAN routers, thus ensuring traffic from Group
1 is sent to the WAN 2 router and traffic from Group 2 is sent to the WAN 1router.
Notice that there is not additional items in the route map to use in the event that the
next hop is down, or unavailable. In this example, if one WAN router goes down,
traffic will follow normal routing behavior and use the only available WAN router.
Module Summary
– Describe how to apply IPv4 and IPv6 addresses to network interfaces
– Discuss Layer 3 Features

• Route-only
• Virtual Interfaces (VE)
• Static routes
• Null Routes
• Route-maps
• Default route
– Explain and configure standard and extended IP Access Control Lists (ACLs)
– Describe the configuration and capabilities of Policy-Based Routing (PBR)
End of Module 6:
Layer 3 Fundamentals
ICX 200 Client Access Services
Module 7:
Client Access Services
Revision 0919 7-1

Module Objectives
– Describe DHCP helpers on network devices, including DHCP assist and relay
– Explain the capabilities and configuration options for Ruckus ICX DHCP server
– Describe the security and filtering functions of:

• DHCP snooping
• Dynamic ARP Inspection (DAI)
• IP Source Guard
Revision 0919 7-2

DHCP Overview
• Dynamic Host Configuration Protocol (DHCP)
– Allows automatic configuration of network clients
– Assigns leased or permanent IP address to client systems
– Delivers host-specific configuration parameters to network clients, including:

• Default router
• DNS server
• Domain name
• TFTP server
• Boot file
The Dynamic Host Configuration Protocol (DHCP) is based on the Bootstrap Protocol
(BOOTP) and provides several configuration parameters stored in DHCP server
databases to DHCP clients upon request.
DHCP enables the automatic configuration of client systems. DHCP removes the need
to configure devices individually. Clients can set network properties by connecting to
the DHCP server instead. This protocol consists of two components; a protocol to
deliver host-specific configuration parameters from a DHCP server to a host, and a
mechanism to allocate leased or permanent IP addresses to hosts. DHCP is built on a
client-server model, where designated DHCP server hosts allocate network addresses
and deliver configuration parameters to dynamically configured hosts.
Revision 0919 7-3

DHCP Relay and Assist
Revision 0919 7-4

DHCP Relay – Helping DHCP at Layer3
• By default, Layer 3 devices do not pass DHCP requests DHCP

between subnets Server
10.1.5.25
• DHCP Relay solves this with ip helper-address e7 Router

IP Helper Address
10.1.5.25e12
• Helper address on interface forwards DHCP request
to server
L2 Switch
• Request is stamped with incoming gateway interface

address, allowing server to choose correct address pool
DHCP
Request
• Source IP received at the DHCP server will be the
helper’s interface facing the server
– Port e7 in the example DHCP Client
The following parameters control the Layer 3 switch forwarding of BootP and DHCP
requests:
• Helper address - The BootP/DHCP server IP address. You must configure the
helper address on the interface that receives the BootP/DHCP requests from the
client. The Layer 3 switch cannot forward a request to the server unless you
configure a helper address for the server.
• Gateway address - The Layer 3 switch places the IP address of the interface that
received the BootP/DHCP request in the request packet Gateway Address field
(sometimes called the Router ID field). When the server responds to the
request, the server sends the response as a unicast packet to the IP address in
the Gateway Address field. (If the client and server are directly attached, the
Gateway ID field is empty, and the server replies to the client using a unicast or
broadcast packet, depending on the server.)
By default, the Layer 3 switch uses the lowest-numbered IP address on the
interface that receives the request as the Gateway address. You can override
the default by specifying the IP address you want the Layer 3 switch to use.
Revision 0919 7-5

DHCP Relay Configuration
• Up to 16 Server IP addresses can be configured on an interface

– Can be configured on a physical or VE interface
– ICX devices require a number identifying the server being configured (1 through 16)

ICX(config-if-e10000-1/1/2)# ip helper-address 1 10.95.7.6
• Syntax: [no] ip helper-address address-number [ ip-address [ unicast ] ]
• Additional parameters can be specified, including:

– ICX reply to client can contain server as source, instead of ICX interface
– Maximum hop count can be adjusted
To forward a client broadcast request for a UDP application when the client and
server are on different networks, you must configure a helper address on the
interface connected to the client.
Specify the server IP address or the subnet directed broadcast address of the server's
IP subnet as the helper address. You can configure up to 16 helper addresses on each
interface. You can configure a helper address on an Ethernet port or a virtual
interface.
The commands in the example above add a helper address for server 10.95.7.6 to the
port. If the port receives a client request for any of the applications that the Layer 3
switch is enabled to forward, the Layer 3 switch forwards the client request to the
server.
You can configure the ICX device so that a BOOTP/DHCP reply to a client contains the
server IP address as the source address instead of the router IP address. To do so,
enter the following command at the Global CONFIG level of the CLI.
ICX(config)# ip helper-use-responder-ip
To modify the maximum number of BootP/DHCP hops, enter the following command.
ICX(config)# bootp-relay-max-hops 10
Revision 0919 7-6

DHCP Relay Options
• By default, when DHCP replies are sent to the client from the helper router, the source
address is the interface facing the client
– You can configure the helper to use the DHCP server IP instead with the ip helper-use-responder-ip
command
ICX (config)# ip helper-use-responder-ip
• By default, a DHCP helper forwards a DHCP request if its hop count is four or less
– Requests with a hop count greater than four are discarded
– The maximum hop count can be modified with the bootp-relay-max-hops command
ICX(config)# bootp-relay-max-hops 10
• Syntax: [no] bootp-relay-max-hops max-hop

– max-hop value range: 1 - 15
Changing the DHCP reply source address - You can configure the device so that a
BOOTP/DHCP reply to a client contains the server IP address as the source address
instead of the router IP address with the ip helper-use-responder-ip command in the
global configuration context.
Changing the maximum number of hops to a BootP relay server - Each router that
forwards a BootP/DHCP packet increments the hop count by one. Routers also
discard a forwarded BootP/DHCP request instead of forwarding the request if the hop
count is greater than the maximum number of BootP/DHCP hops allowed by the
router. By default, a Ruckus Layer 3 switch forwards a BootP/DHCP request if its hop
count is four or less but discards the request if the hop count is greater than four. You
can change the maximum number of hops the Layer 3 switch allows to a value from 1
through 15.
Revision 0919 7-7

DHCP Assist – Helping DHCP at Layer2
• DHCP Assist on Layer 2 switch inserts gateway information into DHCP Discovery packets
• Assists multi-netted routers that

perform DHCP relay function
Router
DHCP
Server
Multi-netted Interface
• L2 switch stamps gateway on Subnet 1: 10.175.1.1
Discovery packets based on port Subnet 2: 172.16.25.1
1/1/1 L2 Switch Subnet 3: 192.168.10.1
GW 10.175.1.1
• Router passes gateway info to server1 1/1/5

1/1/12
GW 192.168.10.1
GW 172.16.25.1
• Server assigns address from

corresponding pool
Subnet 1 Host Subnet 2 Host Subnet 3 Host
Footnote 1: The DHCP relay function of the connecting router must be turned on.
DHCP Assist allows a Ruckus Layer 2 switch to assist a router that is performing multi-
netting on its interfaces as part of its DHCP relay function.
DHCP Assist ensures that a DHCP server that manages multiple IP subnets can readily
recognize the requester IP subnet, even when that server is not on the client local
LAN segment. The Ruckus Layer 2 switch does so by stamping each request with its IP
gateway address in the DHCP discovery packet.
By allowing multiple subnet DHCP requests to be sent on the same wire, you can
reduce the number of router ports required to support secondary addressing, as well
as reduce the number of DHCP servers required by allowing a server to manage
multiple subnet address assignments.
DHCP Assist works on initiation of a DHCP session, when the client sends out a DHCP
discovery packet for an address from the DHCP server. When the DHCP discovery
packet is received at a Ruckus Layer 2 switch with the DHCP Assist feature enabled,
the gateway address configured on the receiving interface is inserted into the packet.
This address insertion is also referred to as stamping.
When the stamped DHCP discovery packet is then received at the router, it is
forwarded to the DHCP server. The DHCP server then extracts the gateway address
from each request and assigns an available IP address within the corresponding IP
subnet. The IP address is then forwarded back to the workstation that originated the
request.
Revision 0919 7-8

DHCP Assist Configuration
• Configuring DHCP Assist is a two step process
– Configure gateway lists

ICX(config)# dhcp-gateway-list 1 10.175.1.1
• Syntax: [no] dhcp-gateway-list num ip-address
– Assign gateway list to interface

ICX(config-if-e1000-1/1/1)# dhcp-gateway-list 1
ICX(config-if-e1000-1/1/1)# interface ethernet 1/1/5
ICX(config-if-e1000-1/1/5)# interface ethernet 1/1/12
• Syntax: [no] dhcp-gateway-list num
You can associate a gateway list with a port. You must configure a gateway list when
DHCP Assist is enabled on a Ruckus Layer 2 switch.
The gateway list contains a gateway address for each subnet that will be requesting
addresses from a DHCP server. The list allows the stamping process to occur. Each
gateway address defined on the Layer 2 switch corresponds to an IP address of the
Ruckus router interface or other router involved.
When multiple IP addresses are configured for a gateway list, the Layer 2 switch
inserts the addresses into the discovery packet in a round-robin fashion. Up to 32
gateway lists can be defined for each Layer 2 switch.
Revision 0919 7-9

DHCP Server
DHCP Server
• All ICX devices can be configured as a DHCP server
• Capable of providing IP address and several configuration parameters to clients
• Clients can include:

– Wireless access points
– IP phones
– Desktop computers
– Networking devices
• Available options enhance device operation without manual, individual configuration
All FastIron devices can be configured to function as DHCP servers.

DHCP introduces the concept of a lease on an IP address. The DHCP server can
allocate an IP address for a specified amount of time or can extend a lease for an
indefinite amount of time. DHCP provides greater control of address distribution
within a subnet. This feature is crucial if the subnet has more devices than available IP
addresses. In contrast to BOOTP, which has two types of messages that can be used
for leased negotiation, DHCP provides seven types of messages.
DHCP allocates temporary or reserved network IP addresses to clients. When a client
requests the use of an address for a time interval, the DHCP server guarantees not to
reallocate that address within the requested time and tries to return the same
network address each time the client makes a request. The period of time for which a
network address is allocated to a client is called a lease. The client may extend the
lease through subsequent requests. When the client is done with the address, the
address can be released back to the server. By asking for an indefinite lease, clients
may receive a permanent assignment.
DHCP clients can be IP phones, desktops, or network devices. The clients can be
connected directly or through other networks using relays. The DHCP server provides
information such as the DNS server name, TFTP server name, and also the image to
pick for bootup to the DHCP client. Once the client obtains the IP address, TFTP
server name, and boot image name, the client can download the image from the
TFTP server and boot with that image.
The DHCP server is disabled by default on all FastIron devices.
DHCP Server Configuration
• Follow these steps to enable the server and configure the pool scope
– Enable the DHCP server

ICX(config)# ip dhcp-server enable
• Syntax: [no] ip dhcp-server enable
– Create an address pool

ICX(config)# ip dhcp-server pool Building6
• Syntax: [no] ip dhcp-server pool name
– Configure pool IP address scope

ICX(config-dhcp-Building6)# network 172.16.1.0/24
• Syntax: network subnet/mask
Before you can configure the various DHCP server options, you must create an
address pool on your FastIron device.
The first step is to enable the DHCP server with the ip dhcp-server enable command.
Next, create a server pool with the ip dhcp-server pool command, which puts intot
he DHCP pool configuration context. From here you can configure several optional
parameters.
If the pool will provide IP addresses to clients, the scope of IP addresses must be
defined with the network command.
DHCP Server Configuration – Pool and Lease Settings
• IP assignment and lease settings:
– Exclude used address from scope

ICX(config-dhcp-Building6)# excluded-address 172.16.1.1 172.16.1.3
• Syntax: excluded-address { address | address-low address-high }
– Static IP mapping
ICX(config-dhcp-Building6)# static-mac-ip-mapping 10.10.10.29 0010.9400.0005
• Syntax: static-mac-ip-mapping ip-address mac-address
– Lease settings
ICX(config-dhcp-Building6)# lease 2
• Syntax: lease days
– Deploy the address pool

ICX(config-dhcp-Building6)# deploy
• Syntax: deploy
You can specify a single address or a range of addresses that should be excluded from
the address pool. This is accomplished with the excluded-address command from the
pool configuration context. You can enter a single IP address or a range of IP
addresses to exclude from the pool.
Based on the client MAC address, you can statically configure the IP address to the
MAC address in the DHCP server. This configuration is useful when you want to have
selected clients assigned with particular IP addresses from the server. Whenever a
DHCP discover message is received from these clients, based on the static
configuration, the IP address will be assigned with the other required parameters.
The lease duration for assigned IP addresses can be modified from the default of 1
day with the lease command. The range available is from 1 to 8 days.
Once the address pool is configured, it must be deployed with the deploy command.
DHCP Options
• DHCP options allow DHCP servers to pass additional configuration parameters to clients
• Common options include:
– Default router
– DNS server
– Host name
– Domain name
• Prior to 8.0.70, specific commands were used to set options
– Beginning in 8.0.70, commands will be displayed by option number, not command keyword
The list of supported DHCP options is extensive. However, the number of options that
can be passed to the client is limited by the size of the ACK packet. It is recommended
that you configure essential options only for the specific DHCP server address pool.
The following options (if configured) are prioritized, with additional options added as
needed:
• 3 - Router Option
• 6 - Domain Name Server
• 12 - Hostname
• 15 - Domain name
• 66 - TFTP server hostname or IP address
• 67 - Boot file name
• 60 - Vendor-Specific Information
DHCP options are not validated by the DHCP server. You must ensure the values are
configured correctly.
In FastIron 08.0.61 or earlier releases, it was possible to configure a subset of these
DHCP options using specific commands. For example, dhcp-default-router allows
configuration of the DHCP default router (which is now also configurable using DHCP
option 3). When upgrading to FastIron 08.0.70, any configured DHCP options are
retained. However, the configuration is stored and shown in the new options format.
The following table shows the options available in earlier releases and a mapping
between the new option format and the corresponding commands available in earlier
releases.
DHCP Options Configuration
• Define options:
– Default router
ICX(config-dhcp-Building6)# option 3 ip 172.16.1.1
• Syntax: option 3 ip router-ip
– Domain name
ICX(config-dhcp-Building6)# option 15 ascii ruckuswireless.com
• Syntax: option 15 ascii domain-name
– DNS servers
ICX(config-dhcp-Building6)# option 6 ip 172.16.1.2 172.16.1.3
• Syntax: option 6 ip server-ip-address …
– NTP servers
ICX(config-dhcp-Building6)# option 42 ip 172.16.1.44
• Syntax: option 42 ip server-ip-address …
Note that the existing commands are still supported. Here we have the configuration
of the default router, the domain name, DNS servers and an NTP server using the
option command. These configurations could have been completed with the
following commands, respectively:
ICX(config-dhcp-Building6)# dhcp-default-router 172.16.1.1
ICX(config-dhcp-Building6)# domain-name ruckuswireless.com
ICX(config-dhcp-Building6)# dns-server172.16.1.2 172.16.1.3
ICX(config-dhcp-Building6)# netbios-name-server 172.16.1.2
However the configuration will be stored and shown in the option command format.
It is recommended that you configure these using the option command.
DHCP Vendor Specific Information - SmartZone
• DHCP options 60 and 43 allow identification of vendor-specific clients and provide them
with vendor-specific information
– Option 60 defines the vendor type and configuration value
– Option 43 defines vendor specific information
– If option 60 is configured, the vendor specific information (defined in option 43) is returned to clients that
provide the appropriate vendor type and configuration value
– If option 60 is not configured, the vendor specific information is sent to all clients
• Ruckus devices running as DHCP servers can be configured with option 43 and option 60 to
direct certain Ruckus devices to the Ruckus SmartZone network controller
ICX(config-dhcp-Building6)# option 60 ascii “Ruckus CPE”
ICX(config-dhcp-Building6)# option 43 hex 060b31302e31302e31302e3130
Translates to 10.10.10.10
Ruckus devices running as DHCP servers can be configured with option 43 and option
60. Configuring the DHCP option 60 helps in identifying the incoming DHCP client. If
the vendor class identifier (VCI) advertised by the DHCP client matches with the DHCP
server, the server makes a decision to exchange the vendor-specific information (VSI)
configured as part of DHCP option 43.
The Ruckus ICX DHCP server can recognize the DHCP client device using the VCI
(option 60) and pass specific information to this device type only (using option 43).
However, the DHCP server can be configured to always pass additional information
using option 43 (regardless of the client).
In summary:
• Option 60 defines the vendor type and configuration value.
• Option 43 defines vendor specific information.
• If option 60 is configured, the vendor specific information (defined in option 43)
is returned to clients that provide the appropriate vendor type and
configuration value.
• If option 60 is not configured, the vendor specific information is sent to all
clients.
DHCP Server Considerations
• Consider the following when implementing DHCP server
– Supported on L2 and L3 software images
– Only supported on the default VRF
– If any addresses in the scope of the DHCP pool are statically used, they must be excluded from the pool
– DHCP request packets larger that 1500 bytes will be dropped
The following configuration considerations apply to DHCP servers, the DHCP binding
database, and DHCP address pools:
• The DHCP server is supported in the Layer 2 and Layer 3 software images.
• The DHCP server is not supported on non-default VRF.
• In the event of a controlled or forced switchover, a DHCP client requests from
the DHCP server the same IP address and lease assignment that it had before
the switchover. After the switchover, the DHCP server will be automatically
reinitialized on the new Active Controller or management module.
• For DHCP client hitless support in a stack, the stack mac command must be
used to configure the MAC address, so that the MAC address does not change
in the event of a switchover or failover. If stack mac is not configured, the MAC
address/IP address pair assigned to a DHCP client will not match after a
switchover or failover. Furthermore, in the Layer 3 router image, if the stack
mac configuration is changed or removed and the management port has a
dynamic IP address, when a DHCP client tries to renew its lease from the DHCP
server, the DHCP server will assign a different IP address.
• If any address from the configured DHCP pool is used, for example, by the DHCP
server or TFTP server, you must exclude the address from the network pool.
• Ensure that DHCP clients do not send DHCP request packets with a Maximum
Transmission Unit (MTU) larger than 1500 bytes. Ruckus devices do not support
DHCP packets with an MTU larger than 1500 bytes.
DHCP Snooping
DHCP Snooping Overview
• DHCP snooping enables the device to filter untrusted DHCP packets in a subnet which can:
– Protect from rogue DHCP servers
– Prevent malicious user posing as a DHCP server sending false DHCP server reply packets
– Can stop unauthorized DHCP servers connected to the network (personal home routers)
Untrusted Trusted Untrusted Untrusted Trusted

Ports Port Port Port Port
DHCP Request
DHCP Reply
Rogue Rogue Trusted
DHCP Server DHCP Server DHCP Server
DHCP snooping enables the Ruckus device to filter untrusted DHCP packets in a
subnet. DHCP snooping can ward off MiM attacks, such as a rogue DHCP server
sending false DHCP server reply packets with the intention of misdirecting other
users. DHCP snooping can also stop unauthorized DHCP servers and prevent errors
stemming from user misconfiguration of DHCP servers.
DHCP snooping is often used with Dynamic ARP Inspection and IP Source Guard.
When enabled on a VLAN, DHCP snooping stands between untrusted ports (those
connected to host ports) and trusted ports (those connected to DHCP servers). A
VLAN with DHCP snooping enabled forwards DHCP request packets from clients and
discards DHCP server reply packets on untrusted ports. DHCP server reply packets on
trusted ports to DHCP clients are forwarded.
DHCP Binding Database
• Client IP-to-MAC address binding data learned on trusted ports are stored in a database
• Binding database data includes:

– MAC address
– IP address
– Lease time
– VLAN number
– Port number
• Database information can be used to support other protective mechanisms, such as:
– Dynamic ARP Inspection(DAI)
– Source Guard
DHCP server reply packets are forwarded to DHCP clients on trusted ports. From the
DHCP server reply packets, the switch collects client IP-to-MAC address binding
information, which is saved in the DHCP binding database. This information includes
MAC addresses, IP addresses, lease time, VLAN numbers, and port numbers.
Beginning with FastIron release 8.0.30b, the DHCP binding database in the Ruckus
device is decoupled from the ARP database.
The lease time is refreshed when the client renews its IP address with the DHCP
server; otherwise, the Ruckus device removes the entry when the lease time expires.
Client IP addresses need not be on directly connected networks, as long as the client
MAC address is learned on the client port and the client port is on the same VLAN as
the DHCP server port. In this case, the system learns the client IP-to-MAC port
mapping. Therefore, a VLAN with DHCP snooping enabled does not require a VE
interface.
Displaying the DHCP Binding Database
• Use the show ip dhcp snooping info command to view the DHCP binding database
device# show ip dhcp snooping info

Dhcp snooping Info
Total learnt entries 8
Learnt DHCP Snoop Entries
IP Address Mac Address Port Virtual Port vlan lease VRF
10.1.1.5 0000.7e49.6183 lg256 v3 3 585 default-vrf
10.1.1.6 0000.0034.1234 1/1/24 v3 3 224 default-vrf
10.25.1.5 000c.2900.0011 lg5 v100 100 185 default-vrf
10.25.1.12 0050.0000.6c88 lg5 v100 100 500 default-vrf
10.25.1.29 0013.0002.9012 lg5 v100 100 319 default-vrf
10.44.11.2 0000.0018.747c 2/1/7 v44 44 200 default-vrf
10.44.11.5 748e.f8f9.6300 2/1/11 v44 44 200 default-vrf
10.44.11.9 cc4e.246c.f190 3/1/22 v44 44 200 default-vrf
DHCP Snooping Configuration
• To run DHCP snooping, ACL filtering based on VLAN membership or VE port membership
must be enabled
ICX(config)# enable acl-per-port-per-vlan
ICX(config)# write mem
ICX(config)# exit
ICX# reload
– Syntax: [no] enable acl-per-port-per-vlan
• Snooping is enabled on per VLAN basis

ICX(config)# ip dhcp snooping vlan 100 to 150 160 170 to 200
– Syntax: [no] ip dhcp snooping vlan vlan-id [ to vlan-id … ]
• Change trust setting on interface connected toward DHCP server

ICX(config-if-e10000-1/1/1)# dhcp snooping trust
– Syntax: [no] dhcp snooping trust
DHCP snooping should be enabled on VLANs, after which the trust setting of ports
connected to a DHCP server must be changed to trusted. DHCP packets for a VLAN
with DHCP snooping enabled are inspected.
To run DHCP snooping, you must first enable support for ACL filtering based on VLAN
membership or VE port membership with the enable acl-per-port-per-vlan
command. Note that you must save the configuration and reload for the changes to
take effect.
Next, you enable DHCP snooping on a VLAN with the ip dhcp snooping vlan
command.
Then, you change the trust setting of the ports that are connected to the DHCP server
to trusted at the interface configuration level with the dhcp snooping trust
command.
NOTE: DHCP snooping is disabled by default and the trust setting of ports is untrusted
by default. DHCP snooping must be enabled on the client and the DHCP server
VLANs.
Dynamic ARP Inspection
Dynamic ARP Inspection Overview
• Dynamic ARP Inspection (DAI) allows only valid ARP requests and responses to be
forwarded
– Can prevent common man-in-the-middle (MiM) attacks such as ARP cache poisoning
– Disallows misconfiguration of client IP addresses
• A Ruckus device on which DAI is configured does the following:

– Intercepts and inspects all ARP requests and responses received on untrusted ports
– Verifies that each of the intercepted packets has a valid IP-to-MAC address binding before updating the
local ARP table, or before forwarding the packet to the appropriate destination
– Drops invalid ARP packets
For enhanced network security, you can configure the Ruckus device to inspect and
keep track of Dynamic Host Configuration Protocol (DHCP) assignments.
Dynamic ARP Inspection (DAI) enables the Ruckus device to intercept and examine all
ARP request and response packets in a subnet and discard packets with invalid IP-to-
MAC address bindings. DAI can prevent common man-in-the-middle (MiM) attacks
such as ARP cache poisoning, and disallow misconfiguration of client IP addresses.
DAI allows only valid ARP requests and responses to be forwarded and supports
Multi-VRFs with overlapping address spaces.
How DAI Works
• ARP packets on untrusted ports are inspected against the switches local ARP table and the
DHCP Snooping table
• Status of each ARP entry is either valid or pending
– Valid - The mapping is valid, and the port is resolved
– Pending - Normal dynamic ARP entries before they are resolved
• Their status changes to valid when they are resolved, and the port is mapped
When you enable DAI on a VLAN, by default, all member ports are untrusted. You
must manually configure trusted ports. In a typical network configuration, ports
connected to host ports are untrusted. You configure ports connected to other
switches or routers as trusted.
DAI inspects ARP packets received on untrusted ports, as shown in the here. DAI
carries out the inspection based on IP-to-MAC address bindings stored in a trusted
binding database. For the Ruckus device, the binding database is the ARP table and
the DHCP snooping table, which supports DAI, DHCP snooping, and IP Source Guard.
To inspect an ARP request packet, DAI checks the source IP address and source MAC
address against the ARP table. For an ARP reply packet, DAI checks the source IP,
source MAC, destination IP, and destination MAC addresses. DAI forwards the valid
packets and discards those with invalid IP-to-MAC address bindings.
When ARP packets reach a trusted port, DAI lets them through, as shown here.
DAI uses the IP-to-MAC mappings in the ARP table to validate ARP packets received
on untrusted ports. DAI relies on the following entries:
• Dynamic ARP - Normal ARP learned from trusted ports.
• Static ARP - Statically configured IP/MAC/port mapping.
• Inspection ARP - Statically configured IP-to-MAC mapping, where the port is
initially unspecified. The actual physical port mapping will be resolved and
updated from validated ARP packets.
• DHCP-Snooping ARP - Information collected from snooping DHCP packets when
DHCP snooping is enabled on VLANs. DHCP snooping entries are stored in a
different table and are not part of the ARP table.
DAI Configuration
• Like DHCP snooping, ACL filtering based on VLAN membership or VE port membership
must be enabled for DAI with the global enable acl-per-port-per-vlan command
• DAI is enabled on per VLAN basis

ICX(config)# ip arp inspection vlan 100 to 150 160 170 to 200
– Syntax: [no] ip arp inspection vlan vlan-id [ to vlan-id … ]
• Define trusted interfaces (DAI will not occur)

ICX(config-if-e10000-1/1/1)# arp inspection trust
– Syntax: [no] arp inspection trust
• If static IP addresses operate on VLANs with DAI configured, static inspection entries must
be configured
ICX(config)# arp 10.20.20.12 0000.0002.0003 inspection
The following prerequisites apply while configuring Dynamic ARP Inspection:

• You must first configure static ARP or static inspect ARP entry for hosts
configured with a static IP address. Otherwise, when DAI checks ARP packets
from these hosts against entries in the ARP table, it will not find any entries for
them, and the Ruckus device will not allow or learn ARP from an untrusted host.
• To run Dynamic ARP Inspection, you must first enable support for ACL filtering
based on VLAN membership or VE port membership. Enter the enable acl-per-
port-per-vlan command to enable ACL-per-port-per-VLAN. The configuration
must be saved and the device reloaded for this change to take affect.
Next, you enable Dynamic ARP Inspection on a VLAN with the ip arp inspection vlan
command.
Then, you change the trust setting of the ports that will be allowed to bypass DAI to
trusted at the interface configuration level with the arp inspection trust command.
IP Source Guard
IP Source Guard Overview
• Prevents IP traffic from unknown hosts on untrusted interfaces
• Uses the DHCP snooping binding database to validate traffic
• When first enabled, only DHCP is allowed until valid IP addresses are learned from DHCP
snooping
• Can be enabled per port, per VLAN, per port/per VLAN and per VE
You can use IP Source Guard together with Dynamic ARP Inspection on untrusted
ports. This feature leverages the DHCP snooping binding database to limit traffic that
is allowed on untrusted ports. This helps to prevent IP spoofing attacks.
The Ruckus implementation of the IP Source Guard technology supports
configuration on a port, specific VLAN memberships on a port (Layer 2 devices only),
and specific ports on a Virtual Ethernet (VE) interface (Layer 3 devices only).
When IP Source Guard is first enabled, only DHCP packets are allowed, while all other
IP traffic is blocked. IP Source Guard allows IP traffic when the system learns valid IP
addresses. The system learns of a valid IP address from DHCP snooping.
When a new IP source entry binding on the port is created or deleted, the ACL is
recalculated and reapplied in the hardware to reflect the change in IP source
bindings. By default, if IP Source Guard is enabled without any IP source binding on
the port, an ACL that denies all IP traffic is loaded on the port.
IP Source Guard Configuration
• To configure IP Source Guard on specific ports:

device(config-if-e10000-1/1/1)# source-guard enable
• To configure IP Source Guard on all ports on a VLAN

ICX(config)# vlan 12
ICX(config-vlan-12)# untagged ethernet 1/1/5 to 1/1/8
ICX(config-vlan-12)# tagged ethernet 1/1/23 to 1/1/24
ICX(config-vlan-12)# source-guard enable
IP Source Guard Configuration (cont.)
• To configure IP Source Guard on a specific ports in a VLAN

ICX(config-vlan-12)# untagged ethernet 1/1/5 to 1/1/8
ICX(config-vlan-12)# source-guard enable ethernet 1/1/8 ethernet 1/1/23
• To configure IP Source Guard on a VE

ICX(config)# vlan 2
ICX(config-vlan-2)# tagged ethe 2/1/38 to 2/1/39 ethe 7/2/2
ICX(config-vlan-2)# untagged ethe 8/1/5 to 8/1/6 ethe 8/2/3
ICX(config-vlan-2)# router-interface ve 2
ICX(config-vlan-2)# interface ve 2
ICX(config-vif-2)# source-guard enable ethernet 2/1/39 eth 8/1/6
Module Summary
– Describe DHCP helpers on network devices, including DHCP assist and relay
– Explain the capabilities and configuration options for Ruckus ICX DHCP server
– Describe the security and filtering functions of:

• DHCP snooping
• Dynamic ARP Inspection (DAI)
• IP Source Guard
End of Module 7:
Client Access Services
ICX 200 IP Gateway Redundancy
Module 8:
IP Gateway Redundancy
Revision 0919 8-1

Module Objectives
– Describe the benefits of ICX Virtual Routing Redundancy Protocol Enhanced
– Discuss VRRP-E advantages over the standard VRRP
– Understand and Configure ICX VRRP-E
Revision 0919 8-2

VRRP-E
Revision 0919 8-3

Virtual Router Redundancy Protocol Enhanced
• VRRP-E is a Ruckus enhanced version of the VRRP standard (RFC 3768)1 that overcomes
limitations in the standard protocol
– No default owner and all routers start as backup
• All members have a configurable priority unlike VRRP
• The router with the highest active priority becomes the master
• If there is a tie for highest priority, the router with the highest interface IP address becomes master
– The Virtual IP (VIP) is not owned by any members of the VRRP-E instance
• There is no concept of an owner of the VIP, as a real interface IP is not used
• The elected master hosts the VIP address and answers ICMP requests
– More granular control of track port management
• Multiple track ports can be monitored providing thresholds on a member
– Security is available allowing MD5 authentication
Footnote 1: VRRP standard was established in RFC 3768 however was updated by RFC
5798 in 2010 to include IPv6 addressing.
NOTE: VRRP-E is supported in the full Layer 3 code only. It is not supported in the
base Layer 3 code.
Virtual Router Redundancy Protocol Enhanced (VRRP-E)
• All routers are backups for a given Virtual Router ID (VRID). The router with the
highest priority becomes master. If there is a tie for highest priority, the router
with the highest IP address becomes master. The elected master owns the virtual
IP address and answers ICMP and ARP requests.
• VRRP-E uses UDP to send hello messages in IP multicast messages. The hello
packets use the interface's actual MAC address and IP address as the source
addresses. The destination MAC address is 01-00-5E-00-00-02, and the destination
IP address is 224.0.0.2 (the well-known IP multicast address for all routers). Both
the source and destination UDP port number is 8888. VRRP-E messages are
encapsulated in the data portion of the packet.
• The virtual IP (VIP) must be an unique IP address on the same subnet where VRRP-
E is enabled.
• VRRP-E uses the interface's actual MAC address as the source MAC address for
VRRP-E Advertisements. A virtual MAC address is used for the gateway or VIP
address on the client subnet. The virtual MAC address is 02-E0-52-<hash-value>-
<vrid> where the <hash-value> is a two-octet hex hash value of the Virtual IP
Address and <vrid> is the Virtual Router ID value.
Revision 0919 8-4

VRRP-E Requirements
• To correctly configure VRRP-E on a Ruckus ICX consider:

– ICX switch must be running full layer 3 routing code
– The VRRP-E virtual router IP address must be in the same subnet as a real IP address assigned to a physical
interface
• Must not be the same as any of the actual IP addresses on any router interface
• Configuring VRRP-E uses the same task steps for all devices; there are no differences between master and backup
device configuration
– Router configured with the highest active priority assumes the master role
– VRRP-E is not supported on non-Ruckus devices and does not interoperate with standards-based VRRP
sessions
– Virtual router IDs can range from 1-255
– Up to 16 VRRP-E instances can be configured on an ICX router
Note that only one of these protocols (VRRP/VRRP-E) can be enabled at the same
time on an ICX device.
Revision 0919 8-5

VRRP-E Management and MAC Address
• Unlike the standard VRRP protocol:
– VRRP-E uses UDP (port 8888) to send multicast hello messages to the "all routers" multicast address
224.0.0.2
• Only devices listening to the all routers multicast address will receive the message
– The MAC address is 02-E0-52-<hash-value>-<vrid>

• <hash-value> is a two-octet hashed value for the virtual IP address and <vrid> is the Virtual Router ID
Revision 0919 8-6

VRRP vs. VRRP-E
VRRP VRRP-E
Routers are either IP address owner
All routers are backup
or backup
VIP is any unused IP address within
VIP is interface IP on owner
the same subnet
Virtual MAC Virtual MAC with hash1
00-00-5E-00-01 <vrid> 02-E0-52<hash><vrid>
hello packets use UDP port 8888 and
hello Packets are multicast to
send to “all routers” multicast
224.0.0.18
224.0.0.22
Track port priority becomes VRRP Reduces VRRP-E priority by amount of
priority tracked port’s priority3
Can ping VIP regardless of who is
Cannot ping VIP if owner is not master
master
Footnote 1: MAC hashing allows multiple routers within overlapping VRID groups in
the same broadcast domain to operate without creating MAC conflicts.
Footnote 2: The multicast address for VRRP-E advertisements was changed to
224.0.0.2:8888 (UDP) since the .18 address was reserved for VRRP usage. By sending
to UDP port 8888 on the all routers multicast address this allows the advertisements
to go to a unique destination and will be ignored by non-VRRP-E routers.
Footnote 3: The advantage that VRRP-E has over VRRP is that two or more track ports
can be defined on one router. There may be an application that involves two track
ports where it is preferred to keep one router as the master after one track port
failures, but decrement the routers current priority so that the next failure will
change its state to backup.
Revision 0919 8-7

VRRP-E Master Selection
• All VRRP-E routers start as backup and send hello messages to determine the master
router
– Router with the highest VRRP-E priority becomes master

– Master sends hellos as a keep-alive and responds to ARP and ICMP requests
(i.e. ping)
When using VRRP-E all configured routers start in backup mode for each VRRP
instance. Hello’s are sent and received to decide who has the highest priority. Once
the highest priority router for that instance has been identified it transitions to the
Master role it continues to send hello messages to inform the other backup routers of
its status. Backup routers will use the received hello message as a keep alive message
and will also continue to monitor the priority of the Master router.
If it does not receive a hello message from the current Master router before the keep
alive timer expires it will take over the Master role and begin sending out its own
hello messages. In addition, if at any time the priority received from the Master
router is lower that its own current priority it will begin sending its own hello
messages indicating it has a higher priority and will then migrate to the Master role as
well. Anytime there is a transition of the Master role the new Master will send out a
gratuitous ARP updating the inline switch tables of the new virtual MAC location.
No matter what router is Master it will respond to ICMP requests from hosts.
Revision 0919 8-8

149_multiple_VRRPe_router
VRRP-E Instance
To correctly configure this we will enable VRRP-E on both routers with a matching
Virtual Router ID (VRID) and priority value. On router A however we will configure its
priority higher than router b to ensure it becomes the master of this VRRP-E instance.
If the priorities happen to be set the same or not set at all (default 100) on both
routers the router with the highest physical IP address configured would become the
master of this VRRP-E instance. (It is suggested to always configure unique priorities
to ensure expected behavior)
Question: Based on this configuration which router should become the Master of this
VRRP-E instance? Router A
Revision 0919 8-9

Multiple VRRP-E Instance on Routers
Example of Multiple VRRP-E Groups

In this example, Router A and Router B use VRRP-E to load balance as well as provide
redundancy to the hosts. The load balancing is accomplished by creating two unique
VRRP-E groups. Each group has its own virtual IP address and ID. The clients in the left
subnet point to virtual IP address of VRID 1 as their default gateway and the right
subnet point to virtual IP address of VRID 2 as their default gateway. This potentially
enables outbound traffic for each subnet to be forwarded by a different router if the
VRRP-E instances are configured to establish the unique paths.
Now for the next subnet we will configure a different instance of VRRP-E using a
different IP subnet and Virtual Router ID. This time we will set the priority of this
VRRP-E instance higher in Router B causing it to become the Master of this instance.
As a result it will forward the traffic for this subnet while Router A forwards for the
192.53.5.0/24 subnet allowing for the outgoing traffic to be balanced between the
two routers.
VRRP-E Failover
Dead interval
Default: 3x Hello interval1
Configurable backup: 1-84 seconds
Hello interval
Default: 1 second
Configurable: 1-84 seconds
In the event of a router failure the backup router for the VRRP-E instance will stop
receiving hello’s from the Master causing its dead interval to expire and will migrate
to the Master role and take over the duties of forwarding traffic and responding to
host requests.
Hello interval: The number of seconds or milliseconds between Hello messages from
the Master to the Backups for a given VRID. The interval can be from 1 through 84
seconds ( 1 second default) for VRRP v2, VRRP-E v2, and IPv6 VRRP-E. The interval for
VRRP v3 can be from 100 through 8400 milliseconds (1000 default) and can be
configured in seconds or milliseconds.
Dead interval: The number of seconds or milliseconds a Backup waits for a Hello
message from the Master for the VRID before determining that the Master is no
longer active. Can be configured in seconds (v2 mode) or centiseconds (v3 mode).
Footnote 1: If the Master does not send a Hello message before the dead interval
expires, the Backups negotiate (compare priorities) to select a new Master for the
VRID.
If the value for the dead interval is not configured, then the current dead interval is
equal to three times the Hello interval plus the Skew time (where Skew time is equal
to (256 - priority) divided by 256). Note: The hello intervals must be set to the same
value on both owner and backup devices for the same VRID
VRRP Backup Pre-emption
• If original Master is restored it can assume it’s duties again by default (pre-emption)
Disabling prevents
a backup device
with a higher
priority than the Pre-emption can be
current backup disabled eliminating
acting as a master the original master
to assume the from taking over
master role
When the original master is recovered/restored it will begin to receive hello packets
from the acting master. Because the original master had a higher priority configured it
will to take over the master duties from the acting master which is a process called
pre-emption. This is on by default in ICX device but can be disabled if desired. This
allows for the ability to stabilize the environment reverting back to the original router
at a later date such as during a change window instead of the possibility of flapping. If
the original router continues to preempt, migration between the original and backup
could continue, leading to an unstable environment.
VRRP-E Track Port Monitoring
• Track port failure causes track priority to be subtracted from configured backup priority
– Each track port failure causes the tracking value to be subtracted (possibly
multiple times)
Backup priority - (failed track ports x track port priority) = current priority
VRRP-E RouterB VirtualRouter VRRP-E RouterA Configured priority 115
VRID 1 VRID 1 VRID 1
2 track port failure -20
Backup
Master Virtual IP 10.1.1.1 Master
Backup
Priority 100 Virtual MAC to 02-EO-52-A3-23-01 Priority
Priority115
105
95 Current priority 95
Configured priority 115

1 track port failure -10
Current priority 105
IP: 10.1.1.2 IP: 10.1.1.3
Track Port Priority 10
Host 1
Default Gateway
10.1.1.1
When track port priorities are configured under the VRRP-E instance any failed track
port will cause its priority will be counted against the configured priority. Depending
on the VRRP-E configuration this could cause a migration of the Master duties to
another router.
In a situation where only one track port fails you might not want to migrate to a
different router. VRRP-E has the option to allow for one track port to fail and still
allow the original master to remain. However you can configure in a way that if two
track ports fail then the switch takes place. This is an advantage over the VRRP
standard by providing more flexibility in controlling when a failover would take place.
If a failover occurs, once the new master is selected it sends out a gratuitous ARP
updating the virtual MAC location forcing any inline switches in the VRRP-E
environment to update their MAC tables.
Configuring VRRP-E
Configuring VRRP-E
• Configuring VRRP-E virtual router

RouterA(config)# router vrrp-extended Physical Interface IP
(same subnet as VRID IP)
RouterA(config-VRRP-E-router)# interface ethernet 1/1/1
RouterA(config-if-e1000-1/1/1)# ip address 10.1.1.3/24
RouterA(config-if-e1000-1/1/1)# ip vrrp-extended vrid 1
RouterA(config-if-e1000-1/1/1-vrid-1)# backup priority 115 track-priority 10
RouterA(config-if-e1000-1/1/1-vrid-1)# ip-address 10.1.1.1
VRID Virtual IP
RouterA(config-if-e1000-1/1/1-vrid-1)# track-port ethernet 1/1/16
RouterA(config-if-e1000-1/1/1-vrid-1)# activate
VRRPE router 1 for this interface is activating
• RouterB’s configuration is similar to RouterA
VRRP-E is configured in the order described below, which corresponds to the

commands displayed in the slide:
• VRRP-E is enabled globally on RouterA
• CLI context is changed to interface e 1/1/1
• Interface e 1/1/1 is addressed
• VRRP-E VRID 1 definition is initialized on e1
• Backup Priority is set to 110 and Track Priority is set to 20
• The IP address for VRID 1 is specified
• The track port is defined
• the VRID is activated
• The router sends out a gratuitous ARP indicating its MAC address and VRID’s IP
Configuration Rules for VRRP-E:

• The router interfaces in a VRID must be in the same IP subnet
• The hello interval must be set to the same value on all the VRRP-E enabled devices
• The dead interval must be set to the same value on all the Layer 3 Switches
• The track priority for a VRID must be lower than the VRRP-E priority
VRID 2 RouterA
RouterA(config)# inter e1/1/2
RouterA(config-if-e1000-1/1/2)# ip addr 10.2.1.2/24
RouterA(config-if-e1000-1/1/2)# ip vrrp-e vrid 2
RouterA(config-if-e1000-1/1/2-vrid-2)# backup priority 100
track-priority 10
RouterA(config-if-e1000-1/1/2-vrid-2)# ip-add 10.2.1.1
RouterA(config-if-e1000-1/1/2-vrid-2)# track-p e 1/1/16
VRRP-E router 2 for this interface is activating
VRID 1 RouterB
RouterB(config)# router vrrp-e
RouterB(config-VRRP-E-router)# inter e1/1/2
RouterB(config-if-e1000-1/1/2)# ip addr 10.1.1.2/24
RouterB(config-if-e1000-1/1/2)# ip vrrp-e vrid 1
RouterB(config-if-e1000-1/1/2-vrid-1)# backup priority 100
track-priority 10
RouterB(config-if-e1000-1/1/2-vrid-1)# ip-add 10.1.1.1
RouterB(config-if-e1000-1/1/2-vrid-1)# track-port e 1/1/12
RouterB(config-if-e1000-1/1/2-vrid-1)# activate
VRRPE router 1 for this interface is activating
VRID 2 RouterB
RouterB(config)# inter e1/1/1
RouterB(config-if-e1000-1/1/1)# ip addr 10.2.1.3/24
RouterB(config-if-e1000-1/1/1-vrid-2)# backup priority 115
track-priority 10
RouterB(config-if-e1000-1/1/1-vrid-2)# ip-add 10.2.1.1
RouterB(config-if-e1000-1/1/1-vrid-2)# activate
VRRP-E router 2 for this interface is activating
Verify VRRP-E Configuration — Master

RouterA# show ip vrrp-e
Total number of VRRP-Extended routers defined: 1
Interface ethernet 1/1/1 Elected master due to higher
auth-type no authentication
priority
VRID 1
state master
administrative-status enabled Configured priority
priority 115
current priority 115 Priority in use
track-priority 10
backup-hello-interval 60 sec
hello-interval 1000 msec Configured dead-interval. 0
dead-interval 0 msec = not configured and default
current dead-interval 3500 msec value 3.5 sec is being used
preempt-mode true
accept-mode disabled Dead-interval in use
virtual ip address 10.1.1.1
virtual mac address 02e0.522f.2701 Virtual IP and MAC
advertise backup: disabled
next hello sent in 00:00:00.1
backup router 10.1.1.2 expires in 00:02:37.9 Backup router advertisement
track-port 1/1/16(up) 1/1/17(up) 1/1/18(up)
short-path-forwarding disabled Track-ports state are up
activate-backup: disabled
Continued command output from show ip VRRP-E above:
Interface ethernet 1/1/2

VRID 2
state backup
administrative-status enabled
priority 100
current priority 100
track-priority 10
hello-interval 1000 msec
dead-interval 0 msec
current dead-interval 3600 msec
preempt-mode true
accept-mode disabled
virtual MAC 02e0.52e5.7902
master router 192.10.1.2 expires in 00:00:03.0
short-path-forwarding disabled
State: This device VRRP state for the VRID. The state can be one of the following:
• initialize – The VRID is not enabled (activated). If the state remains “initialize” after
you activate the VRID, make sure that the VRID is also configured on the other routers
and that the routers can communicate with each other.
NOTE: If the state is initialize and the mode is incomplete, make sure you have
specified the IP address for the VRID.
• Standby – This device is a backup for the VRID.
• Master – This device is the master for the VRID.
Administrative-status: The administrative status of the VRID. The administrative status
can be one of the following:
• disabled – The VRID is configured on the interface but VSRP or VRRP-E has not been
activated on the interface.
• enabled – VSRP has been activated on the interface.
Priority: The device preference for becoming the master for the VRID. During
negotiation, the backup with the highest priority becomes the master. If two or more
backups are tied with the highest priority, the backup interface with the highest IP
address becomes the master for the VRID.
Current priority: The current VRRP or VRRP-E priority of this Layer 3 Switch for the VRID.
The current priority can differ from the configured priority (see the row above) for the
following reasons:
• The VRID is still in the initialization stage and has not become a master or backup yet.
In this case, the current priority is 0.
• The VRID is configured with track ports and the link on a tracked interface has gone
down.
Hello-interval: The number of seconds between hello messages from the master to the
backups for a given VRID.
Dead-interval: The configured value for the dead interval. The dead interval is the
number of seconds a backup waits for a hello message from the master for the VRID
before determining that the master is no longer active. If the master does not send a
hello message before the dead interval expires, the backups negotiate (compare
priorities) to select a new master for the VRID. NOTE: If the value is 0, then you have not
configured this parameter.
Current dead-interval: The current value of the dead interval. This is the value actually in
use by this interface for the VRID. Note: This field does not apply to VRRP owners
Preempt-mode: Whether the backup preempt mode is enabled. Note: This field does not
apply to VRRP owners.
Virtual ip address: The virtual IP addresses that this VRID is backing up.
Advertise-backup: The IP addresses of backups that have advertised themselves to this

Layer 3 Switch by sending hello messages. Note: hello messages from backups are
disabled by default. You must enable the hello messages on the backup for the backup to
advertise itself to the current master.
Next hello sent in <time>: How long until the backup sends its next hello message. Note:
This field applies only when this Layer 3 Switch is the master and the backup is configured
to send hello messages (the advertise backup option is enabled).
Track port: The interfaces that the VRIDs interface is tracking. If the link for a tracked
interface goes down, the VRRP or VRRP-E priority of the VRID interface is changed,
causing the devices to renegotiate for master. Note: This field is displayed only if track
interfaces are configured for this VRID.
Short path forwarding: Allows Ruckus devices to bypass the VRRP-E master router and
directly forward packets to their destination through interfaces on the VRRP-E backup
router. This is called short-path forwarding. A backup router participates in a VRRP-E
session only when short-path forwarding is enabled. More details on this feature will be
discussed in the MCT module of this course.
Activate backup: This is a command issued within the router VRRP-E stanza causing the
router to change the current VRRP-E priority to 1 causing it to relinquish its master duties.
This allows for ISSU servicing and removed once the upgrade is complete. Because it is a
configuration command it will need to be removed from the config using the no activate
backup command.
Ruckus(config)# router vrrp-e

Ruckus(config-vrrpe-router)# activate backup
Ruckus(config-vrrpe-router)# show ip vrrp-e

Interface v30
VRID 1
state initialize
priority 115
current priority 1
preempt-mode true
virtual mac address 02e0.522f.2a01
track-port 1/1/1(up)
activate-backup: enabled
Verify VRRP-E Configuration - Backup

RouterB# show ip vrrp-extended
auth-type no authentication Backup state due to lower
VRID 1 priority
state backup
priority 100 Configured priority
track-priority 10
backup-hello-interval 60 sec Master router IP
preempt-mode true Amount of time until dead
accept-mode disabled interval expires
virtual mac address 02e0.522f.2701
Track-ports state are up
master down timer expires in 00:00:03.3
Continued command output from show ip VRRP-E above

VRID 2
state master
Virtual MAC 02e0.52e5.7902
priority 110
track-priority 20
preempt-mode true
track-port 1/1/12(up)
VRRP-E For IPv6 Support
• IPv6 address support for VRRP Enhanced (VRRP-E)

– Both IPv4 and IPv6 VRRP-E instances can be enabled simultaneously for dual-stack networks1
– Provide faster switchover to backup devices than using standard IPv6 neighbor discovery mechanisms
– Allows both master and non-master routers to respond to ICMP/telnet/management requests
The same VRID must not be
– VRRP-E IPv6 configuration used across IPv6 VRRP-E and
RouterA(config)# ipv6 unicast-routing IPv4 VRRP-E if they are in
RouterA(config)# ipv6 router vrrp-extended the same broadcast domain
RouterA(config-ipv6-vrrp-router)# interface ethernet 1/1/4
RouterA(config-if-e1000-1/1/4)# ipv6 address fd4b::4/64
RouterA(config-if-e1000-1/1/4)# ipv6 vrrp-extended vrid 2
RouterA(config-if-e1000-1/1/4-vrid-4)# backup priority 110
RouterA(config-if-e1000-1/1/4-vrid-4)# ipv6-address fd4b::1
VRRPE router for this interface is activating
Footnote 1: IPv4 and IPv6 support can be activated at the same time however either
VRRP or VRRP-E instances can be activated at the same time. Example: You can not
have VRRPv3 and IPv6 VRRP-E activated at the same time.
IPv6 VRRP-E
• Display of IPv6 VRRP-E instances can also be displayed using:

RouterA# show ipv6 vrrp-e
Interface v30
VRID 2
state master
administrative-status disabled
priority 110
preempt-mode true
virtual ipv6 address fd2b::1
virtual mac address 02e0.5200.2501
VRRP Backup Preemption
• Backup preemption is enabled by default for VRRP and VRRP-E which allows the original
master or other backups to take over if their priority becomes higher than the active
master
– Feature can be disabled:
• Preventing route flapping
• Protects from bouncing due to unstable original master
• Ensures fall back is controlled by the administrator
• To avoid a backup device (acting as the master) from being preempted by another backup
device with a higher priority value use the following command1
RouterA(config)# interface ethernet 1/1/5
RouterA(config-if-e1000-1/1/5)# ip vrrp-extended vrid 1
RouterA(config-if-e1000-1/1/5-vrid-1)# non-preempt-mode
• Backup device will not assume the role of the VRRP master even if a backup device has a
higher priority than the current master device
Footnote 1: non-preempt-mode is only run on the original master, not on the backup.
Setting a VRRP-E instance in non-preempt-mode causes the device to ignore priorities
after a failure even if other VRID members have a lower priority. In non-preemt-mode
a router will still take over master state if it no longer receives hello messages from
the current master and the dead timer expires.
VRRP-E Advertise Backup
• Backup VRRP-E routers can be configured to advertise allowing it to be visible to the

master router
– No need to log into the backup to see its availability in the VRRP-E instance
• When enabled the backup router will advertise to the master router by sending a backup-
hello message (default every 1 min.)
RouterB(config)# int e 1/1/2
RouterB(config-if-e1000-1/1/2-vrid-1)# advertise backup
• You can adjust the frequency of hello messages from the backup router by using (in
seconds):1
RouterB(config-if-e1000-1/1/2-vrid-1)# backup-hello-interval 150
Footnote 1: The Master router once it receives a backup hello message it displays the
backup advertisement in its vrrp-e output. Additionally it sets a dead timer for the
backup router next advertisement to 3 minutes. If you set a backup-hello-interval on
the master the dead timer locally will be set for 3x the timer value.
RouterB# show ip vrrp-e

VRID 1
state backup
priority 100
track-priority 10
preempt-mode true
advertise backup: enabled
ICX6450-C12PD Router#
VRRP-E Advertise Backup Output

RouterA# show ip vrrp-e
VRID 1
state master
priority 115
track-priority 10
preempt-mode true
backup router 10.1.1.2 expires in 00:02:37.9
VRRP-E Slow Start Timer
• Slow start timer provides a delay in migrating back to the original master after its priority
has become higher than the acting master
– Extends the time interval beyond the dead interval before the original master assumes its role
– Provides stability in the environment by:
• Guarding against pre-mature migration back to original master (bouncing track port)
• Allows for routing table to update (OSPF convergence)
• To globally enable VRRP-E, enter the router vrrp-extended command

Ruckus(config)# router vrrp-extended
Ruckus(config-vrrpe-router)# slow-start 40
• Syntax: [no] slow-start seconds

– Range from 1 through 255
VRRP/-E Authentication
• VRRP along with VRRP-E provide the ability to use authentication when communicating
with other members participating in the VRRP VRID
• The following VRRP and VRRP-E authentication types are supported:

– No authentication— default for VRRPE
– Simple— simple text string as a password in packets that they send
• Must use the same authentication type and the same password on each participating interface
– HMAC MD5— Specific MD5 digest algorithm is used to ensure authentic packets and not modified in
transit
• Syslog and SNMP traps are generated when a packet is dropped due to MD5 authentication failure
• MD5 authentication is supported only in VRRP-E, and the device configuration is unique on a per-interface basis
• The MD5 authentication configuration on an interface takes effect for all VRRP-E virtual routers configured on a
particular interface
VRRP/-E Authentication (cont.)
• Configuration of VRRP-E authentication is configured on each interface participating in the

VRRP-E VRID
– The interfaces on which you configure the virtual router use authentication, the VRRP-E packets on those
interfaces must use the same authentication
– VRRP-E Example:
Ruckus(config-if-e1000-1/1/6)# ip vrrp-extended auth-type md5-auth gy42mb
• VRRP-E Syntax: [no] ip vrrp-extended auth-type { no-auth | simple-text-auth auth-text | md5-auth auth-text }
• VRRP Syntax: [no] ip vrrp auth-type { no-auth | simple-text-auth auth-text }
• The password will be hidden or encrypted when saved in the configuration file
– When an MD5 authentication password is configured on an interface, a syslog message is displayed
VRRP Statistics
• VRRP statistics can be viewed based on all or specific ports or VRIDs1

Ruckus# show ip vrrp-e stat
Interface ve 30
rxed vrrp header error count = 0
rxed vrrp auth error count = 0
rxed vrrp auth passwd mismatch error count = 0
rxed vrrp vrid not found error count = 0
VRID 1
rxed arp packet drop count = 0
rxed ip packet drop count = 0
rxed vrrp port mismatch count = 0
rxed vrrp number of ip address mismatch count = 0
rxed vrrp ip address mismatch count = 0
rxed vrrp hello interval mismatch count = 0
rxed vrrp priority zero from master count = 0
rxed vrrp higher priority count = 0
transitioned to master state count = 1
transitioned to backup state count = 0
total number of vrrp-extended packets received = 3
backup advertisements received = 0
total number of vrrp-extended packets sent = 1547
backup advertisements sent = 0
Ruckus# show ip vrrp-e statistics

RX master adv TX master adv RX backup adv TX backup adv VR Errors Port Errors
v30 0
VR 1 3 1547 0 0 0
Footnote 1: Output changes depending on if you use stat or status. Note the
difference in slide to the output preferred.
Ruckus# show ip vrrp-e statistics ?
ethernet port
lag Interface
ve Virtual Ethernet port
vrid show pkt stats for a VRID
To clear the VRRP/-E statistics

Ruckus# clear ip vrrp-stat
VRRP-E Considerations
• Consider the following rules when configuring an instance of VRRP-E
– The VIP cannot be configured on any interfaces
– The Hello and dead interval must be set to the same value on configured devices
– The track priority must be lower than the VRRP-E backup priority
– The same VRID must not be used across IPv6 VRRP-E and IPv4 VRRP-E if they are in the same broadcast
domain
– All configuration is removed from running config if the protocol VRRP-E is removed using the no router
vrrp-extended command
VRRP-E Troubleshooting
Troubleshooting VRRP-E – VRID Interface Failure

RouterA(config)# show ip vrrp-e
Initialize state is due to client WAN
VRID 1
facing interface being down
state initialize
Virtual MAC 02e0.5279.a401
Router A e16 e12 Router B
priority 115
track-priority 10 e1 e1
192.53.5.2 192.53.5.3
preempt-mode true
virtual ip address 192.53.5.1 Host 2
advertise backup: disabled Default Gateway
192.53.5.1
Troubleshooting VRRP-E – Track Port Failure
RouterA(config)# show ip vrrp-e

auth-type no authentication WAN
VRID 1 State has changed to
state backup backup
Virtual MAC 02e0.5279.a401 Router A e16 e12 Router B
priority 115
Priority has been e1 e1
current priority 95
reduced by track- 192.53.5.2 192.53.5.3
track-priority 10 priority
preempt-mode true Host 2
Default Gateway
virtual ip address 192.53.5.1 192.53.5.1
track-port 1/1/16(down) 1/1/17(down) 1/1/18(up) Multiple Track-ports
are down
In the slide above, RouterA’s track port has failed. The current priority is reduced by
the amount of the track-port priority. The track-priority is subtracted from the VRRP-E
priority and as a result Router As current priority is less than Router Bs which results
in a failover.
Module Summary
– Describe the benefits of ICX Virtual Routing Redundancy Protocol Enhanced
– Discuss VRRP-E advantages over the standard VRRP
– Understand and Configure ICX VRRP-E
End of Module 8:
IP Gateway Redundancy
Appendix A:
VRRP Function
Virtual Router Redundancy Protocol (VRRP)
• VRRP provides redundancy to default gateways servicing hosts on the same subnet, RFC
5798
– Allows an alternate router path for a host without changing the IP address or MAC address of its gateway
– Reliability is achieved by advertising a virtual router as the default gateway
– Two or more physical routers are configured to host a virtual router, with only one doing the actual
routing at any given time
VRRP Router Virtual Router VRRPe Router
Master Virtual IP 192.53.5.1 Backup
Virtual MAC 00-00-5E-00-01-01
WAN WAN
Host 1
Default Gateway
192.53.51
VRRP Terminology
• VRRP router: A router running the Virtual Router Redundancy Protocol

– May participate in (backup) one or more virtual routers
• Virtual router: An object managed by VRRP that acts as a default router for hosts on a
shared LAN and consists of:
– A Virtual Router Identifier (VRID)
– A virtual IP address (VIP)
– A virtual MAC address
• Virtual Router Identifier (VRID): Used to identify each virtual router in the subnet
– Supported range is 1-255 in decimal
– There is no default
VRRP Terminology (cont.)
• Virtual MAC: The first five octets are a multicast standard MAC prefix for VRRP and the last
octet is the VRID1
MAC Prefix VRID #
00-00-5E-00-01-xx
Where XX is the VRID number in hex
• Virtual IP (VIP): The IP address used by the virtual router
• IP address owner: The VRRP router that has the same real interface IP address as the
virtual router's IP address
– When the owner router is up, it responds to ICMP pings
– When up, this router always becomes the master
Footnote 1: The first five octets of the address are the standard multiast MAC prefix
for VRRP packets, as described in RFC 2338. The last octet is the VRID. The VRID
number becomes the final octet in the virtual MAC address associated with the
virtual router. When you configure a VRID, the software automatically assigns its MAC
address. When a VRID becomes active, the master router broadcasts a gratuitous ARP
request containing the virtual router MAC address for each IP address associated with
the virtual router. In Figure 154, Switch 1 sends a gratuitous ARP with MAC address
00-00-5e-00-01-01 and IP address 192.53.5.1. Hosts use the virtual router MAC
address in routed traffic they send to their default IP gateway (in this example,
192.53.5.1).
VRRP Terminology (cont.)
• Master: The VRRP router responsible for forwarding packets sent to the VIP associated
with the virtual router
– Creates and responds to ARP requests for the VIP
– If the IP address owner is up, it becomes the master1
• Backup: The set of VRRP routers available to assume forwarding responsibility for a virtual
router should the current master fail
• VRRP priority: Each router has a priority set for each VRID it hosts to determine which
router becomes the master2
– Priority can be from 3-255 (255 is the highest priority)
– 255 is reserved for the IP address owner to guarantee it always becomes the master
– 3-254 is used for backups (default value for backups is 100)
Footnote 1: This may not be true if track ports are used. Track ports are covered in
more detail later.
Footnote 2:
The routers within a VRID use the VRRP priority values associated with each router to
determine which router becomes the master. When configuring the VRID on a router
interface, specify whether the router is the owner of the IP address or a backup. If the
router is the owner of the IP address, the software automatically sets the router VRRP
priority for the VRID to 255, the highest VRRP priority. The router with the highest priority
becomes the master. Backup routers can have a priority from 3 – 254, which are assigned
when the VRID is configured on the backup router interfaces. The default VRRP priority for
backup routers is 100. Because the router that owns the IP address associated with the
VRID always has the highest priority, when all the routers are operating normally, the
negotiation process results in the owner of the VRID IP addresses becoming the master
router.
VRRP Master Selection
• All VRRP routers send multicast VRRP advertisements called hellos to determine the
master1
– Owner: The router whose interface IP address matches the virtual IP address;
the default priority is 255, which causes the owner to become the default
master
– Master: Sends hellos as a keep-alive and responds to ARP and ICMP requests
(i.e. ping)
Footnote 1: VRRP routers use hello messages to determine the master router. VRRP
routers send hello messages to IP multicast address 224.0.0.18.
VRRP Failover
• Master sends hellos1 based on hello interval (default 1 sec)

– Backup routers use the dead interval to track the last hello from the master
– If the dead interval expires before a hello is received, the backup router with the
highest priority becomes the master2
New master sends gratuitous ARP (GARP) to update MAC tables in the LAN
Owner interface is no
longer available so VIP
can not be pinged
Footnote 1: VRRP routers use hello messages to determine the master router. VRRP
routers send hello messages to IP multicast address 224.0.0.18. The frequency with
which the master sends hello messages is the hello Interval. Only the master sends
hello messages. However, a backup will use the configured hello interval if it becomes
the master. The backup routers wait for a period of time called the Dead Interval for a
hello message from the master. If a backup router does not receive a hello message
by the time the dead interval expires, the backup router assumes that the master
router is dead and negotiates with the other backups to select a new master router.
The backup router with the highest priority becomes the new master.
Footnote 2: If the owner becomes unavailable, but then comes back online, the
owner again becomes the master router. The owner becomes the master router again
because it has the highest priority. The owner always becomes the master again
when it comes back online.
VRRP Track Port
• A track port is an egress interface on the router that it is configured to be monitored

– The track priority value is set to a lower value than the VRRP priority
• Default track priority for the IP address owner is 2
• Default track priority for backup routers is 1
- If the tracked interface goes down, the VRRP priority is reduced to the track priority
causing a new master to be selected1
Footnote 1: When track port state becomes operational again, the VRRP priority
reverts back to original state (255) and an advertisement is generated. When the
master sees a higher priority advertisement it relinquishes the role of master back to
the owner.
VRRP Considerations
• Consider the following rules when configuring VRRP:

– The interfaces of all routers in a virtual router instance must be in the same IP subnet
• Must have only one router with VIP and be pre-configured on Owner router
– Hello and dead intervals must match on participating routers per VRRP instance
– The track priority configured must be lower than the router’s VRRP priority1
– The Owner router's priority is always 255
– Only the owner router can respond to ping requests for the VIP address
– Mixed mode VRRP v2 and VRRP v3 is not supported in the same VRRP group
– Maximum numbers of VRIDs per logical interface is 12
Footnote 1: The track priority on the Owner must be higher than the track priority on
the Backups as well. The tracking-port configuration for IPv6 VRRP v3 is not allowed if
the router is configured as the VRRP Owner.
VRRP IPv4 Owner Configuration
• To configure the VRRP Owner router for IPv4, enter the following commands on the
router1
Router1(config)# router vrrp
Router1(config)# interface ethernet 1/1/6
Router1(config-if-e10000-1/1/6)# ip address 10.53.5.1/24
Router1(config-if-e10000-1/1/6)# ip vrrp vrid 1
Router1(config-if-e10000-1/1/6)# version v3|v2
Router1(config-if-e10000-1/1/6-vrid-1)# owner
Router1(config-if-e10000-1/1/6-vrid-1)# ip-address 10.53.5.1
Router1(config-if-e10000-1/1/6-vrid-1)# activate
VRRP router 1 for this interface is activating
Footnote 1: Both VRRP and VRRP-E cannot be activated on a device at the same time.
Syntax: [no] router vrrp
Syntax: [no] ip-address ip-address-address
Syntax: [no] ip vrrp vrid num (The num variable specifies the virtual router ID. Valid range is
between 1 through 255.)
Syntax: [no] owner [ track-priority value ] (The track-priority value option changes the track-
port priority for this interface and the VRID from the default (255) to a value from 1 through
254.)
Syntax: [no] version num (The version num specifies the version - v3 or v2.)
Syntax: [no] activate
The (vrid-#)# ip-address variable specifies the IPv4 address of the Owner router. The
IP address assigned to the Owner must be an IP address configured on an interface
that belongs to the virtual router.
Configuring the Owner for IPv6 VRRP
To configure the VRRP Owner router for IPv6, enter the following commands on the
router. You must first configure the ipv6 unicast-routing command at the global
configuration level to enable IPv6 VRRP on the router.
Router1(config)# ipv6 unicast-routing
Router1(config)# ipv6 router vrrp
Router1(config-if-e10000-1/1/6)# ipv6-address 2001:DB8::1/64
Router1(config-if-e10000-1/1/6)# ipv6 vrrp vrid 1
Router1(config-if-e10000-1/1/6-vrid-1)# owner
Router1(config-if-e10000-1/1/6-vrid-1)# ipv6-address 2001:DB8::1
VRRP router 1 for this interface is activating
VRRP IPv4 Backup Configuration
• To configure the VRRP Owner router for IPv4, enter the following commands on the
router1
Router2(config-if-e1000-1/1/5)# ip-address 192.53.5.3
Router2(config-if-e1000-1/1/5-vrid-1)# backup
Router2(config-if-e1000-1/1/5-vrid-1)# version v3|v2
Router2(config-if-e1000-1/1/5-vrid-1)# hello-interval 10
Router2(config-if-e1000-1/1/5-vrid-1)# advertise backup
VRRP router 2 for interface is activating
Footnote 1: To configure the VRRP Owner router for IPv4, enter the following
commands on the router1
Router2(config-if-e1000-1/1/5)# ip-address 192.53.5.3
Router2(config-if-e1000-1/1/5-vrid-1)# version v3|v2
VRRP router 2 for interface is activating
Configuring a Backup for IPv6 VRRP

To configure the VRRP Backup router for IPv6, enter the following commands.
Router2(config)# ipv6 router vrrp
Router2(config-if-e1000-1/1/5)# ipv6-address 2001:DB8::3/64
Router2(config-if-e1000-1/1/5-vrid-1)# ipv6-address
2001:DB8::1
VRRP Options
• Disabling VRRP or VRRP-E, the switch removes ALL configuration for the disabled protocol
from running-config
ICX(config)# no router vrrp
router vrrp mode is disabled. All vrrp config data will be lost when
writing to flash!
• ICX devices allow non-Owner Master router to respond to ping, traceroute, and Telnet
packets destined for the virtual IPv4 or IPv6 address of a VRRP cluster in accept mode1
Footnote 1: Introduced in FI version 08.0.01. Configuration example:

ICX(config-vif-3)# ipv6 vrrp vrid 2
ICX(config-vif-3-vrid-2)# backup
ICX(config-vif-3-vrid-2)# advertise backup
ICX(config-vif-3-vrid-2)# ipv6-address 2001:DB8::1
ICX(config-vif-3-vrid-2)# accept-mode
ICX(config-vif-3-vrid-2)# activate
VRRP Options – Hello and Dead Intervals
• Hello-interval on IPv4 VRRP changed from default1

– VRRP v2 changed to 20 sec. (default 1 sec.)
– VRRPv3 changed to 200 milliseconds. (default 1000 ms.)
Router3(config-if-e1000-1/1/6-vrid-1)# hello-interval msec 200
• If dead interval is not configured:
– Equal to three times Hello interval plus the Skew time2
– Can be manually configured3
Footnote 1: The syntax is the same for VRRP and VRRP-E.

Footnote 2: The skew time is equal to (256 - priority) divided by 256
Footnote 3: Dead Interval Config Example:
ICX(config-if-e1000-1/1/5)# ip vrrp vrid 1
ICX(config-if-e1000-1/1/5-vrid-1)# dead-interval 30
VRRP Options – Track Port Configuration
• Ruckus enhanced VRRP to monitor uplink ports

– Tracking the link state changes of uplinks causes software to change the VRRP priority of the virtual router
to the configured track priority value
• Master device config

ICX(config-if-e1000-1/1/6)# vrrp vrid 1
ICX(config-if-e1000-1/1/6-vrid-1)# owner track-priority 20
ICX(config-if-e1000-1/1/6-vrid-1)# track-port ethernet 1/1/24
• Backup device config
ICX(config-if-e1000-1/1/5)# vrrp vrid 1
ICX(config-if-e1000-1/1/5-vrid-1)# backup priority 100 track-priority 19
ICX(config-if-e1000-1/1/6-vrid-1)# track-port ethernet 1/1/24
• Enter a value from 3 through 254 for the track-priority value1
Footnote 1: The default track priority for a VRRP Owner is 2. The default track priority
for Backups is 1. You can specify a value from 3 through 254
VRRP Options – Authentication
• Although authentication was described in the original VRRP standard (RFC 2338) current
standards do not identify authentication
• For backward compatibility, ICX supports VRRP authentication using simple passwords1
– Simple-password authentication using password “ourpword”

ICX(config-if-e1000-1/1/6)# ip vrrp auth-type simple-text-auth ourpword
• Syntax: [no] ip vrrp auth-type no-auth | simple-text-auth auth-data | md5-auth auth-data
Footnote 1: VRRP authentication type is not a parameter specific to the VRID.

Instead, VRRP uses the authentication type associated with the interfaces the VRID is
configured. The MD5 authentication type is not supported by VRRP. Authentication is
not supported by VRRP v3.
Syntax: [no] ip vrrp auth-type no-auth | simple-text-auth auth-data | md5-auth auth-
data
The auth-type no-auth parameter indicates that the virtual router and the interface it
is configured on do not use authentication. The auth-data parameter is the password.
If you use this parameter, If you use this parameter, make sure all interfaces on all the
routers supporting this virtual router are configured for simple password
authentication and use the same password. MD5-authentication is not supported in
VRRP however is in VRRP-Enhanced.
End of Appendix A:
VRRP Function
ICX 200 Troubleshooting
Module 9:
Troubleshooting
Revision 0919 9-1

Module Objectives
– Understand and perform general troubleshooting steps
– Discuss troubleshooting LAG/LACP Issues
– Discuss troubleshooting Spanning Tree issues
– Discuss real time troubleshooting tools
– Discuss and configure different versions of Switched Port ANalyzer (SPAN)
– Implement Denial of Service attack features on ICX
Revision 0919 9-2

General Troubleshooting Steps
Revision 0919 9-3

Troubleshooting with CLI
• Narrow down issue and gather data using feature/function specific commands
• show commands provides valuable insight
– Displays a variety of configuration and statistical information about devices
Layer Functions Verification/solution Methods

1- Physical Physical connectivity show modules
show running-config
show interface
show statistics
2- Data Link ARP resolving accurately show arp
MAC address tables accurate show mac
Ethernet connectivity/switching
3 - Network Logical addressing, Routing and show <protocol> interfaces brief
Encapsulation, OSPF, BGP show route-map
When troubleshooting Layer 1-3, consider the OSI model as a framework for
verification. Ensure that Layer 1 and 2 elements are functioning as intended before
verifying Layer 3 operations. Verify Layer 3 before troubleshooting at Layers 4 through
7.
Consider verifying these operations at each layer of the OSI model
Layer 1 – Physical – Ethernet connectivity. Also consider the switched network
environment between devices and if the devices are running switch or router code.
Layer 2 – Data Link – Ethernet connectivity, ARP resolving accurately, MAC address
tables accurate.
Layer 3 – Network – Real IP to VIP mapping is accurate. Consider routed paths
between the device and remote servers and clients.
The steps in this model are:
• Collect available information and analyze the symptoms of issue
• Localize the problem to within a single network segment, a single complete
module or unit, or to a single user
• Isolate the trouble to specific hardware or software within the unit, module, or
user’s network account.
• Locate and correct the specific problem.
• Verify that the problem has been solved.
Revision 0919 9-4

Troubleshooting Steps (Layer 1)
• Layer 1 issues that should be checked include:

– Bad, missing, or mis-wired cables (especially with static LAGs)
• Check optical or SFPs for failure using optical monitoring options
– Bad ports
• Verify the port has not become disabled due to monitoring such as UDLD, Port Flap Dampening, Keep-alives, LFS
• Test cable and check the switch port LEDs to ensure that layer 1 is functioning correctly
– Power failure
• Verify that power supplies are up and heathy
– PoE issues could be caused by secondary power supply failure
– Device problems
• ICX module or SFP failure or possible breakout port issues
• Possible Layer 1 configuration issues

– Port/speed & type must be the same
– Fiber mismatch (transmit/receive)
It is important to begin your troubleshooting efforts at Layer 1 connectivity and move

up the layers after the lower level troubleshooting has been performed. This has
proven to be the best troubleshooting method to not only provide a consistent
process but also provides troubleshooting from the most obstructive to more specific
issue that might be only effecting a specific traffic flow or protocol.
Revision 0919 9-5

Host Connectivity Issues (Layer 1)
• Check switch’s interface configuration and statistics

– Use the show interface ethernet command
• Errors such as collisions can indicate speed/duplex mismatch between attached devices
– Use the show statistics command to check whether there are CRC errors transmitted or received on the
interface
• Errors of this nature are usually the result of physical problems such as bad cable or NIC
– The show rmon statistics ethernet command provides additional interface statistics for promiscuous
traffic on an interface
ICX# show rmon statistics e 1/2/1
Ethernet statistics 65 is active, owned by monitor
Interface 1/2/1 (ifIndex 65) counters
Octets 199634908639
Drop events 0 Packets 190493299
Broadcast pkts 440 Multicast pkts 8507
CRC align errors 0 Undersize pkts 0
Oversize pkts 0 Fragments 0
Jabbers 0 Collisions 0
Packet size counters

64 6448637 65 to 127 42585494
128 to 255 5659209 256 to 511 2463658
512 to 1023 2033670 1024 to 1518 131388239
Before verifying VLAN functionality and Layer 2 troubleshooting in general, it is

important that Layer 1 is functioning properly. Check port LEDs to ensure the port is
up.
For connectivity and throughput issues within a VLAN, it is important to check the
switch’s interface and interface statistics. The show interface command can also to be
used to check port utilization. A port oversaturated with traffic will affect throughput
and proper host connectivity.
Use show rmon statistics command to view count information on multicast and
broadcast packets, total packets sent, undersized and oversized packets, CRC
alignment errors, jabbers, collision, fragments and dropped events is collected for
each port on a ICX Layer 2 Switch or Layer 3 Switch. The statistics group collects
statistics on promiscuous traffic across an interface. The interface group collects
statistics on total traffic into and out of the agent interface. No configuration is
required to activate collection of statistics for the Layer 2 Switch or Layer 3 Switch.
This activity is by default automatically activated at system start-up.
• Syntax: show rmon statistics [ethernet <unit/slot/port>]
Revision 0919 9-6

Troubleshooting Steps (Layer 2)
• Common Layer 2 issues:
– Stuck/incorrect MAC move

• Migrating MACs can sometimes be “stuck” (verification of correct binding required)
– Missing or wrong VLANs

• Transient switch might not have all necessary VLANs configured
• Tagged/untagged misconfiguration
– Wrong VLAN setting on access ports

• Port might be in wrong VLAN/subnet
– Missing or misconfigured tagged ports

• VLAN packets are being dropped due to incorrect tagging or VLAN association on a port
– Spanning tree port states and data path

• Port might be in error-disabled state, due to events such as BPDU guard
When a MAC move occurs due to end host roaming via AP or because of failover, the
ICX management software should move the MAC address from the old port to the
specified new port it has learned in its forwarding table. It is good practice to look at
the mac table to ensure that the MAC to port binding is accurate and that the frames
for that host is accurate. Occasionally due to certain circumstances this process does
not take place or the MAC address remains bound to the original port. In this event
the MAC needs to be removed using a manual process.
Revision 0919 9-7

MAC Move History
• When wireless hosts roam between APs, their MACs will migrate between ports on a ICX
– Tracking of this activity can be stored on the switch for reference and troubleshooting
• By default, mac-movement information is not stored in the system

ICX(config)# show notification mac-movement interval-history
Interval-History Mac Movement Notification is DISABLED
• MAC movement history storing can be enabled using:

ICX(config)# mac-movement notification threshold-rate 5 sampling-interval 100
• Syntax: [no] mac-movement notification { interval-history seconds | threshold-rate moves sampling-interval seconds }
• To display MAC movement history entries:

ICX# show notification mac-movement interval-history
Interval-History Mac Movement Notification is ENABLED

Configured Interval : 100 seconds
Number of macs that moved in the interval : 2
Total number of moves in the interval : 108
MAC-Address from-Port to-Port Interval Move-Count Last Move-Time Vlan-id

-------------- --------- ------ ------------------- -------------- -------
0010.9400.0002 1/1/41 3/1/27 54 Jan 17 17:07:41 1
0010.9400.0e02 1/1/41 3/1/27 54 Jan 17 17:07:41 1
As hosts of an AP roam their MACs will migrate from AP to AP resulting in a MAC

move on the switch. Having an ability to record for later review in a switch is
beneficial for reference as well as a troubleshooting tool. In some rare instances a
MAC might be mapped incorrectly and will require a manual clearing of the MAC.
Storing data of the MAC migrations can be helpful in diagnosing the issue.
When this feature is enabled the supportsave utility gathers mac-movement history
related information.
Revision 0919 9-8

Clear MAC Options
• Check that the learned MAC address entries are correct in the MAC address table
– Stuck MAC may require clearing
• MAC addresses that can be removed:1

– All MAC address entries
– All MAC address entries for a specified Ethernet port
– All MAC address entries for a specified VLAN
– All specified MAC address entry in all VLANs
• If the clear mac command is used, the MDB and FDB are rebuilt for those cleared using
standard MAC learning and unknown unicast flooding processes
• To remove entries for the MAC address 0000.0080.00d0 in all VLANs, enter the following:
ICX# clear mac-address 0000.0080.00d0
• Syntax: clear mac-address [ mac-address | ethernet unit/slot/port | lag lag-id | vlan vlan-id ]
Footnote 1: Static MAC entries are not removed. If you enter clear mac-address
without any parameter, the software removes all MAC address entries.
Use the mac-address parameter to remove a specific MAC address from all VLANs.
Specify the MAC address in the following format: HHHH.HHHH.HHHH.
Use the ethernet unit/slot/port parameter to remove all MAC addresses for a specific
Ethernet port.
Use the vlan-id parameter to remove all MAC addresses for a specific VLAN.
When a MAC move occurs due to end host roaming via AP or because of failover, the
ICX management software should move the MAC address from the old port to the
specified new port it has learned in its forwarding table. It is good practice to look at
the mac table to ensure that the MAC to port binding is accurate and that the frames
for that host are accurate. Occasionally due to certain circumstances this process
does not take place or the MAC address remains bound to the original port. In this
event the MAC needs to be removed using a manual process.
The clear arp command can be used to clear the learned ARP entries
Static ARP entries are not removed
ICX# clear arp 10.1.2.1
• Syntax: clear arp [ IP-address | ethernet unit/slot/port | lag lag-id | mac-
address mac-address ]
Revision 0919 9-9

Helpful Layer 2 Discovery Tools
• Leverage Layer 2 neighbor discovery protocols to:

– Map out network topology
– Verify correct wiring
– Discover possible loops in the environment
– Verify correct data path flows
• Enable Foundry Discovery Protocol or Link Layer Discovery Protocol on all devices to verify
topology and connectivity1
ICX(config)# fdp run
or
ICX(config)# lldp run
– Both commands when run in global config enable all ports for send/receive discovery packets
Footnote 1: If FDP is globally enabled on an ICX device, all the interfaces, by default,
have FDP enabled on them.
Troubleshooting With ICMP
• Internet Control Message Protocol provides an effective way to test L3 connectivity within
a network
– Address Resolution Protocol table within the ICX maps an IP address to MAC address
ICX# 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=64
Success rate is 100 percent (1/1), round-trip min/avg/max=1/1/1 ms.
• Syntax: ping { ip-addr | host-name | vrf vrf-name | ipv6 [ ipv6-addr | host-name | vrf vrf-name ] [ outgoing-interface type
number ] } [ source ip-addr ] [ count num ] [ timeout msec ] [ ttl num ] [ size num ] [ quiet ] [ numeric ] [ nofragment ] [ verify ] [ data 1-to-4-byte-hex ] [ brief [ max-print-
per-sec number ] ]
• Occasionally IP-to-MAC mapping can be incorrect or needs to be cleared due to changes in

the network
– Clearing of ARP entries can be done on an individual interface or for a specific IP address
ICX# clear arp 10.1.1.1

– Static ARP entries are not removed1
• To remove a static ARP entry, it must be deleted in configuration
Footnote 1: Static ARP entries binding an IP to a MAC can be configured using the
ARP command.
Syntax: arp ip-address mac-address { ethernet unit/slot/port | lag lag-id | inspection
}
Verify VLAN Information and Configuration
• If hosts within the same VLAN cannot communicate, verify their VLAN membership and
configuration
– Use show vlan command to verify switch port access membership
PORT-VLAN 10, Name [None],

Untagged Ports: (U1/M1)
Tagged Ports: (U1/M1) 2 12
e 1/1/2 e 1/1/12 e 1/1/11 e 1/1/12 e 1/1/11 e 1/1/12 e 1/1/11 e 1/1/8
10.2.1.12 10.2.1.20
• User is not able to reach its destination which is within the same subnet
– With current information provided, what might be the problem?
As shown here the access port of the host is configured as a tagged port although the
host is not sending tagged frames. This causes the host frames to either be placed in
the default VLAN of that port or to be dropped.
configuration
PORT-VLAN 10, Name [None],

Untagged Ports: (U1/M1) 2
Tagged Ports: (U1/M1) 12
e 1/1/2 e 1/1/12 e 1/1/11 e 1/1/12 e 1/1/11 e 1/1/12 e 1/1/11 e 1/1/8
10.2.1.12 10.2.1.20
Now any untagged frames coming from the host is now correctly placed into VLAN
10.
configuration
– Verify proper tagged/untagged assignments to adjacent switches
PORT-VLAN 10, Name [None], PORT-VLAN 10, Name [None], PORT-VLAN 10, Name [None],
Untagged Ports: (U1/M1) 2 Untagged Ports: (U1/M1) Untagged Ports: (U1/M1) 11
Tagged Ports: (U1/M1) 12 Tagged Ports: (U1/M1) 11 12 Tagged Ports: (U1/M1) 12
e 1/1/2 e 1/1/12 e 1/1/11 e 1/1/12 e 1/1/11 e 1/1/12 e 1/1/11 e 1/1/8
10.2.1.12 10.2.1.20
• With current information provided, what might be the problem now?
Any switches along the path are required to carry the VLAN ID value allowing for the
successful delivery of the frame. When ports along the path remove the tag the
receiving switch either has to have its port set up as an access port associated with
that VLAN. Mismatch port types (tagged/untagged) along the path can cause frames
to be dropped or to be placed in the wrong VLAN.
configuration
PORT-VLAN 10, Name [None], PORT-VLAN 10, Name [None], PORT-VLAN 10, Name [None],
Untagged Ports: (U1/M1) 2 Untagged Ports: (U1/M1) Untagged Ports: (U1/M1)
Tagged Ports: (U1/M1) 12 Tagged Ports: (U1/M1) 11 12 Tagged Ports: (U1/M1) 11 12
e 1/1/2 e 1/1/12 e 1/1/11 e 1/1/12 e 1/1/11 e 1/1/12 e 1/1/11 e 1/1/8
10.2.1.12 10.2.1.20
configuration
– Confirm VLAN continuity along data path
PORT-VLAN 10, Name [None], PORT-VLAN 10, Name [None], PORT-VLAN 10, Name [None], PORT-VLAN 11, Name [None],
Untagged Ports: (U1/M1) 2 Untagged Ports: (U1/M1) Untagged Ports: (U1/M1) Untagged Ports: (U1/M1) 8
Tagged Ports: (U1/M1) 12 Tagged Ports: (U1/M1) 11 12 Tagged Ports: (U1/M1) 11 12 Tagged Ports: (U1/M1) 11
e 1/1/2 e 1/1/12 e 1/1/11 e 1/1/12 e 1/1/11 e 1/1/12 e 1/1/11 e 1/1/8
10.2.1.12 10.2.1.20
• With current information provided, what might be the problem now?
VLAN continuity is important to deliver the frame to its destination in most all cases.
Each switch along the path need to have the correct VLAN ID configured and the
proper ports are associated in either tagged or untagged depending on its position on
its path.
configuration
– Confirm VLAN continuity along data path
PORT-VLAN 10, Name [None], PORT-VLAN 10, Name [None], PORT-VLAN 10, Name [None], PORT-VLAN 10, Name [None],
Untagged Ports: (U1/M1) 2 Untagged Ports: (U1/M1) Untagged Ports: (U1/M1) Untagged Ports: (U1/M1) 8
Tagged Ports: (U1/M1) 212
12 Tagged Ports: (U1/M1) 11 12 Tagged Ports: (U1/M1) 11 12 Tagged Ports: (U1/M1) 11
e 1/1/2 e 1/1/12 e 1/1/11 e 1/1/12 e 1/1/11 e 1/1/12 e 1/1/11 e 1/1/8
10.2.1.12 10.2.1.20
Contiguous VLAN from source to destination allows for intra VLAN communication of
the member devices that belong to the same Layer 3 subnet.
Scenario 1: Common VLAN Troubleshooting
• Working Scenario - Incorrect VLAN configuration

– Switch 2 has tagged port e1 in VLAN 20, but not in VLAN 10
– At present, PC5 can reach PC3 and FTP server
E1 is configured for VLAN 20,

but not VLAN 10
An often missed parameter is the configuration of the appropriate ports into all the
required VLANs. In this example, Switch 2 has tagged ethernet 1 placed in VLAN 20,
but not for VLAN 10. PC5 can reach PC3 and the FTP server currently by way of the
ethernet 2 links on Switch 2 and 3.
• Problem - Incorrect VLAN configuration

– Link (e2) between Switch 2 and Switch 3 goes down
– STP changes the blocked port 1 on Switch 3 to forwarding mode
• Switch 2 will now receive traffic on e1 from PC5, but will drop it
• PC5 cannot reach PC3 and FTP server
E1 interface will drop traffic from PC5
Link (e2) goes down
Suppose Ethernet 2 on Switch2 and Switch 3 goes down. The Spanning Tree Protocol
will change the blocked port on Ethernet 1 (Switch 3) to forwarding mode. Now,
Switch 2 will receive the same PC5 traffic on Ethernet 1 instead. However, Switch 2
will drop this traffic because it will be tagged with VLAN 10. Tagged port e1 has not
been configured for VLAN 10.
In this example, PC5 cannot reach PC3 and the FTP server in VLAN 10. We will start
by verifying the ports in Switch2 using the show vlan command:
Switch2(config-vlan-10)# show vlan 10

Total PORT-VLAN entries: 2
Maximum PORT-VLAN entries: 64
Legend: [Stk=Stack-Id, S=Slot]
PORT-VLAN 10, Name [None], Priority level0, Spanning tree On
Untagged Ports: (U1/1/M1) 3 5
Tagged Ports: (U1/1/M1) 2  Port ethernet 1/1/1 is not in
VLAN 10
Uplink Ports: None
DualMode Ports: None
Mac-Vlan Ports: None
Monitoring: Disabled
The output of the command above shows that Ethernet 1/1/1 interface on switch
Switch2 does not belong to VLAN 10.
To find the VLAN that ethernet 1/1/1 belongs to, use the below command:
Switch2# show vlan ethernet 1/1/1
Total PORT-VLAN entries: 3
Maximum PORT-VLAN entries: 64
Legend: [Stk=Stack-Id, S=Slot]

Untagged Ports: (U1/1/M1) 4
Tagged Ports: (U1/1/M1) 1 2
Uplink Ports: None
Monitoring: Disabled
• The above output shows that tagged ethernet 1/1/1 belongs to VLAN 20, but not VLAN
10.
You can gather more data by using the show interfaces e 1/1/1 to 1/1/2
command on Switch2:
Switch2# show interface brief e 1/1/1 to 1/1/3
Port Link State Dupl Speed Trunk Tag Pvid Pri MAC
Name
1/1/1 Up Forward Full 1G None Yes N/A 0 0024.38b7.f2c0
1/1/2 Up Forward Full 1G None Yes N/A 0 0024.38b7.f2c1
1/1/3 Up Forward Full 1G None No 10 0 0024.38b7.f2c2
Both ports are tagged which causes the output not to show the VLAN. However if this port
was untagged the PVID displays the VLAN membership. This is due to the fact that a
tagged port can potentially be a member of too many VLANs to list here.
• Solution - Incorrect VLAN configuration

– Add Ethernet 1 on switch 2 as a tagged member of VLAN 10
• PC5 can now reach PC3 and FTP server
ICX(config-vlan-10)# tagged e 1/1/1
The solution is simple, but finding the problem first is always the challenge. Add
tagged Ethernet 1 into VLAN 10. Once Ethernet 1 on Switch 2 is placed into VLAN 10,
PC5’s traffic will be able to communicate with all nodes on the VLAN. Furthermore,
Ethernet 1 will also be able to process the traffic that needs to be routed.
Solution:
Ethernet 1/1/1 on Switch2 needs to be added to VLAN 10 using
the tag ethernet 1/1/1 command:
Switch2# config term

Switch2(config-vlan-10)# tag e 1/1/1
Added tagged port(s) ethe 1/1/1 to port-vlan 10.
PC5> ping 10.10.10.11

Pinging 10.10.10.11 with 32 bytes of data:
Reply from 10.10.10.11: bytes=32 time<1ms TTL=64

Troubleshooting VLANs Summary
• VLANs are a fairly straightforward feature which rarely require troubleshooting
• Problems seen are mostly configuration errors
• Use the commands to verify the configuration:

show vlan
show running-config
• Use the commands to verify traffic loss between hosts:

show interface ethernet unit/slot/port
show statistics brief
show rmon statistics
ping <host>
Troubleshooting LAG/LACP Issues
Link Aggregation Groups
• Improperly formed/deployed or malfunctioning LAGs can cause:

– High CPU
– Loops
– Packet loss
– Forwarding issues
• LAG requirements may vary for different vendors and platforms

– Consult LAG formation rules of platforms participating in LAG
– Verify what is supported at both ends:
• Number of links in the LAG
• Specific port boundaries
• Timers (short/long)
Troubleshooting LAGs
• Whether it’s a static or dynamic LAG, it is important to configure port groups that are the
same number of ports set to the same speed at both ends
– Individual interfaces can only be members of a single LAG
• Troubleshoot Layer 1 to rule out physical issues first:

– Check members port health by using show interface and show statistics commands1
• If any member ports are experiencing errors it can cause packet loss and may cause flapping
• Verify that port members are not taking errors within the LAG causing an overall degradation
– Check if member ports are up or down and the Layer 2 state is in forwarding and not blocking
– Check optical monitoring for any alarms or warnings
– Check UDLD, Packet InError Detection, Link Fault Signaling (LFS), Remote Fault Signaling (RFN) for port
status
Footnote 1: Each port in the LAG will operate at the speed of the slowest link. For
example if one LAG is created with 2 ports and one is running at 1 Gbps and the other
is running at 100 Mbps; each link will run at 100 Mbps. This behavior will occur if the
ports are configured to auto, and negotiate to different speeds.
Troubleshooting LAG Considerations
• Other things to consider:

– Verify LAG ports are configured correctly and is enabled on both devices1
• Common issue with newly deployed LAGs is that one end was not configured or incorrect ports configured
• Manually set the speed at the LAG layer (LAG virtual anchor speed) to avoid ports being error disabled
• Individual ports within a LAG can be disabled in configuration causing the port not to be active in a LAG
– Verify LAG threshold is configured properly and is being met2

• If a threshold was configured make sure there are either enough ports active to meet the minimum requirement
– Verify LACP timers match3

• The original IEEE specification says that the state machine starts with short the timeout and moves to the long
timeout after the LAG is established
• Some vendors only use a short timeout value
– General troubleshooting commands for LAGs:

show lag show interface ethernet <unit/slot/port>
show interface lag show statistics brief
show interface lag <id> show cpu
Footnote 1: If the incorrect ports are configured port members will act independently
and can cause loops and possibly STP port blocking. Make sure both platforms have
the correct ports configured in the LAG. 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 using:
Ruckus(config-lag-if-lg1)# speed-duplex 1000-full
Footnote 2:. If there are not enough ports to meet the threshold the LAG will not be
active.
device(config)# lag blue static
device(config-lag-blue)# ports ethernet 1/3/1 to 1/3/4
device(config-lag-blue)# trunk-threshold 3
Footnote 3: If you specify neither long nor short, the state machine operates based
on the standard IEEE specification as its default behavior.
LACP State Values
• Verify the LACP status of the member ports

Ruckus# show lag blue Ports are set to LACP? Timeout set
<Truncated Output> Active (Yes) or Passive (No) long (L) (default) or short (S)
=== LAG "blue" ID 1 (dynamic Deployed) ===
LAG Configuration:
Ports: e 1/1/10 e 1/1/11 Ports set to aggregation mode
Port Count: 2 Yes (Agg) No (No)
Lag Interface: lg1
Trunk Type: hash-based
LACP Key: 20001
Deployment: HW Trunk ID 1
Port Link State Dupl Speed Trunk Tag Pvid Pri MAC Name LACP port states:
1/1/10 Up Forward Full 1G 1 No 100 0 609c.9fe6.0e48 bluelag Dwn - not a LAG active port
1/1/11 Up Forward Full 1G 1 No 100 0 609c.9fe6.0e48 bluelag Ina - transitioning to Ope
Port [Sys P] [Port P] [ Key ] [Act][Tio][Agg][Syn][Col][Dis][Def][Exp][Ope] state
1/1/10 1 1 20001 Yes L Agg Syn Col Dis No No Ope Ope - Operational
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 Is port in expired state
System ID Key Rx Count Tx Count Yes/No
1/1/10 65535-0011.32a0.e8a1 9 48045 1309850
1/1/11 65535-0011.32a0.e8a1 9 48043 1309839
Port in sync with what is being Collecting traffic received Sending traffic on the port Port using received LACP PDU
received in LACP frames Yes (Col) No (No) Yes (Dis) No (No) parameters (No) or default
Yes (Syn) No (No) (admin defined) (Yes)
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
Troubleshooting Spanning Tree
Spanning Tree – Common Issues
• Loop in network with no STP deployed

– Lack of spanning tree provides no loop detection mechanism
• Route-only on interface
– BPDU’s will not be processed by a port in route-only mode
• Spanning Tree BPDU guard configured on aggregation or core layers

– Prevents proper spanning tree operation
• CPU over-utilization on switches

– BPDUs may not be sent out before max-age timer expires
• RSTP slow re-convergence between switches

– admin-pt2pt-mac not configured between switches
– One of the two switches are not compatible or configured for RSTP
Basically, if Spanning Tree (or other equivalent loop avoidance protocol) is not
configured, a loop can easily occur. There are common issues that can affect and
impede the performance and normal operation of the Spanning Tree protocol.
If STP ports are configured for half duplex because the auto-negotiation handshake
didn’t work, STP BPDUs may be lost due to collisions. Use the show interface or show
interface brief command to make sure all ports are in full-duplex mode.
The route-only feature disables MAC learning and Layer 2 forwarding. As a result, STP
BPDUs or any Layer 2 traffic will not be forwarded.
STP protection features like BPDU guard should only be configured on the edge ports
and never on trunks or on uplinks to other switches.
If CPU is too busy (due to another process) to respond or send BDPUs, STP may
recoverge.
Troubleshooting Spanning Tree
• Useful commands:
– show span
– show 802-1w
– show log
– show interface brief
– show interface <port#>
– show cpu
– debug 802.1w messages vlan <vlan #>
– show mac-address
– show arp
Spanning Tree – Logging
• Use the show log command to display recent STP events

•
Switch# show log

Syslog logging: enabled (0 messages dropped, 0 flushes, 30 overruns)
Buffer logging: level ACDMEINW, 50 messages logged
level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning
<Output Truncated>
Dynamic Log Buffer (50 lines):
Jul 6 16:26:44:I:Security: running-config was changed from console
Jul 6 16:26:14:I:System: Interface ethernet 1/1/19, State down - link down
Jul 6 16:26:14:I:System: Interface ethernet 1/1/20, State down - disabled
Jul 6 16:26:14:I:STP: BPDU Guard port 1/1/20 disable
Jul 6 16:26:14:I:STP: VLAN VLAN: 100 Port 1/1/20 - State LEARNING (FwdDlyExpiry)
Jul 6 16:26:14:I:STP: VLAN VLAN: 100 Port 1/1/19 - State LEARNING (FwdDlyExpiry)
Jul 6 16:26:12:I:STP: VLAN VLAN: 100 Port 1/1/20 - State LISTENING (MakeFwding)
Jul 6 16:26:12:I:STP: VLAN VLAN: 100 Port 1/1/19 - State LISTENING (MakeFwding)
Jul 6 16:26:12:I:System: Interface ethernet 1/1/20, state up
Jul 6 16:26:12:I:System: Interface ethernet 1/1/19, state up
<Output Truncated>
The show log output is also a good way to see recent STP events. In this output, port
1/1/19 and 1/1/20 is constantly transitioning between STP states.
Real-time Troubleshooting Tools
Live Troubleshooting
• Root cause cannot always be determined by the use of statistics

– Live trace of traffic and processes is necessary to further diagnose issues
• Three possible tools:
– Supportsave
• Allows for the collecting logs from the driver, internal libraries, and firmware
– Debug
• Must know the category of the problem to use this effectively – OSPF, STP, LACP, etc.
– Mirror port
• Allows to capture packets for review using an analyzer
• Requires 3rd party capture tool (Wireshark is common option)
Supportsave
Supportsave
• Utility for collecting logs from the driver, internal libraries, and firmware
• Logs can be sent to technical support1
– Collection of relevant information of different categories as shown below:
• All - collects os,platform,l2,l3,core & system logs • Spx - collects spx related
• Core - collects core & system log files • System - collects generic system related
• Infra - collects infrastructure related
• L2 - collects layer 2 related • Custom - collects custom commands
• L3 - collects layer 3 related • Add_cust_cmd - add a custom option command
• OS - collects os related • Del_cust_cmd - delete a custom option command
• Platform - collects platform related • List_cust_cmd - lists all stored custom commands
• The supportsave command has the following advantages over the show tech-support
command:2
– Allows you to add additional commands to collect additional data
– Allows to transfer the collected data to an external server such as Secure Copy (SCP)
Footnote 1: The supportsave is an important utility for collecting logs from the driver,
internal libraries, and firmware. The collected logs are shared with the technical
support personnel for investigating issues seen on the device. It is recommended to
use the all variable to collect complete logs. There are many variables when it comes
to support save so refer to the FastIron debug command reference guide for more
details.
Footnote 2: It is a best practice to create a healthy baseline supportsave of your
network environment to be used as a comparison when trying to diagnose network
issues and periodically update it according to the change management cycle of your
network. Up to date supportsaves can provide critical information to help quickly
resolve network outages.
Supportsave Commands
• Once collected the Supportsave data can be transferred to a remote server using TFTP or
SCP
– SCP Example:
ICX# supportsave all scp 10.1.1.104
User name:root
Password:
Supportsave started. This operation may take several minutes.
Press "Shift-A" to abort supportsave operation.
####################################################################
Connecting to remote host......
Sending data (8192 bytes per dot)
..............................................
SCP transfer from device completed
Connection Closed
Supportsave completed in 100 seconds
• Partial syntax: supportsave [add_cust_cmd | all | core | custom | del_cust_cmd | info | infra | l2 | l3 |
list_cust_cmd | os | platform | spx | system] [ tftp-ip | scp] scp-ip remote-server-file-path
TFTP Example:
ICX# supportsave all 10.37.2.40 fi/prince/supportsave
Supportsave started. This operation may take several
minutes.
Press "A" to abort supportsave operation.
ICX7750-48C
ICX#.***********************.............................
....................
.........................................................
........................
Supportsave completed in 100 seconds
Debug
Debug
• Monitor and troubleshoot ICX switch behaviors1
• Accessible from the Privileged EXEC mode only
• Can be configured to send output to a specified destination
• Can noticeably affect system performance

– To conserve performance and prevent system disruption, use the brief option whenever possible
– Can be used in conjunction with calls to technical support
Footnote 1: Debug is used to monitor and troubleshoot ICX switch configurations.

Most of the debug commands can be configured to send output to a specified
destination.
When enabled, the debug commands can noticeably affect system performance.
Many debug commands are specifically designed to be used in conjunction with calls
to technical support. If you report a problem, the support engineer may ask you to
execute one or more of the debug commands described here.
Command options for forwarding output to alternate destinations:
ICX# debug destination
all Send debug message to all destinations
console Send debug message to console
logging Default
ssh Send debug message to SSH session
telnet Send debug message to telnet session
Debug Commands
• Using the debug destination command – Allows you to select an output destination;
Telnet, SSH, console(default), or logging 1
– To send debug output to a SSH session, first determine the session number using the show who command
SSH@ICX# show who | b SSH
SSH connections:
SSH connections (inbound):
1 established, client ip address 10.1.1.104, server hostkey RSA, user is admin, privilege super-user
using vrf default-vrf.
you are connecting to this session 4 minute(s) 13 second(s) in idle
<Output truncated>
– Once the session number is determined the debug output can be modified
SSH@ICX# debug destination ssh 1
• Debug commands can generate excessive output and can significantly slow device
operation
– Use debug commands with caution (Never use this command during periods of peak network activity)
– Issuing the undebug all command – Disables all debug functions currently enabled
– Issuing the show debug command– Shows all enabled debug settings
Footnote 1: To direct debug output to a different destination other than the default
console by selecting an active connection from the below options.
all, console, logging (automatic), SSH, telnet (both SSH and Telnet are from a number
from 1 through 5).
telnet Send debug message to telnet session (a number from 1 through 5).
Syntax: debug destination [ console | logging | telnetnum | sshnum]
This example indicates that you are connected through active SSH session 1. To
redirect the debug output to your SSH session, follow the command entry below.
SSH@ICX# show debug
Debug message destination: Console
SSH@ICX# debug destination ssh 1
SSH@ICX# show debug
Debug message destination: Console
Debug message destination: SSH session 1
Spanning Tree – Debug Command Options
• Debug commands for STP/RSTP enabled on per instance/VLAN basis
Switch-02# debug span

all_802_1d_events STP (802.1D) ALL events, Timers and Packets
config STP (802.1D) Config BPDUs
tcn STP (802.1D) TCNs, TC-ACKs
timers STP (802.1D) Timer expirations
transitions STP (802.1D) Events
Switch-02# debug 802.1w

all_802_1w_events RSTP (802.1w) ALL Transitions, Timers and Packets
messages RSTP (802.1w) Config BPDUs, RST BPDUs and TCNs
timers RSTP (802.1w) Timer expirations
transitions RSTP (802.1w) State Machine transition
• Syntax example: [no] debug 802.1w messages vlan decimal
As seen in this output, there are various debug spanning-tree options. Descriptions
are provided to explain output.
Debug Example
• Depending on output selected the

display will rapidly flow
– Issuing this command might not be seen
while executed
– Upon completion the below output will
confirm debug has been disabled
SSH@Second_Floor_MDF# undebug all

Debug message destination: default (console)
All possible debuggings have been turned off
tracking is off and all results are cleared
This command activates the debugging of RSTP BPDU packets. BPDU packet types
along with the port it was received/sent along with the VLAN/802.1w instance can be
determined.
Port Mirror Port Mirroring/Switched

Port ANalyzer (SPAN)
Port Mirroring/Switched Port ANalyzer (SPAN)
• SPAN: Switched traffic is mirrored from multiple ports to one or more ports within the
same local switch facilitating exact packet capture on the destination port
– The monitor ports packets are copied and sent to a destination port (mirror port)
Uplink
• Monitor port options:

– Specific traffic flows of monitored port can be mirrored1
• Incoming, Outgoing, Both directions Monitored Monitored Mirror
– The same port can be monitored by multiple mirror ports: port port port
• Example: one mirror port for ingress traffic and another mirror port
for egress traffic
– More than one monitored port can be assigned to the same
mirror port2
– The monitored port and its mirror port do not need to belong
to the same port-based VLAN:
• Frames are tagged with the monitor port VLAN ID if the mirror port is in a different VLAN from the monitored port
• Frames are tagged or untagged, depending on the mirror port configuration for mirror/monitored ports in the
same VLAN
Footnote 1: If a port is configured as a mirror port, all traffic will be forwarded in the
raw state that is was received or transmitted in from the monitor port, egress
information is not modified for configuration parameters of the mirror port.
Footnote 2: The mirror port cannot be a trunk port. Mirror ports speed is not related
to the speed of the ingress or egress monitored ports. Traffic that is being monitored
can possibly exceed the rate limit of the mirror port therefore any excess traffic in the
mirror port will be dropped.
SPAN Individual Port Configuration
• Monitoring of a port can be done on an individual basis and can have ingress/egress or
both traffic forwarded to the mirror port
e 1/1/6 e 1/1/48
• Identify the port the sniffer device will be attached

ICX(config)# mirror-port ethernet 1/1/48
• Syntax: [no] mirror-port ethernet stackid/slot/port [ input | output ]
• Enter the slot and port number of the port that will be the mirrored and direct the
mirroring to the port indicating the traffic flow preference
ICX(config-if-e1000-1/1/6)# monitor ethernet 1/1/48 output
• Syntax: [no] monitor [ ethernet stackid/slot/port ] { both | input | output }
VLAN-based Mirroring
• The VLAN-based mirroring feature allows users to monitor all incoming traffic in one or
more VLANs by sending a mirror image of that traffic to a configured mirror port1
• VLAN-based mirroring requirements:

– A VLAN must have at least one port member configured before monitoring can be configured
– Maximum number of monitor-configured VLANs is 8 within a switch
– As with other ports on the switch, If the amount of traffic to the mirror port exceeds the available
bandwidth, some of that traffic may be dropped
– All incoming traffic (tagged and untagged) in the VLAN is mirrored

• Mirroring is "as-is" and is not affected by the configuration of the mirror port itself2
– VLAN-based mirroring is supported on both Layer 2 and Layer 3 images
Footnote 1: Supported on ICX 7750, ICX 7450 and ICX 7250 devices.
Footnote 2: Incoming tagged traffic is sent out tagged and incoming untagged traffic
is sent out untagged, regardless of which VLANs the mirror port belongs to, and
whether the mirror port is tagged or untagged.
Configuring VLAN-based Mirroring
• VLAN-based mirroring can be configured in VLAN configuration mode

ICX(config)# mirror-port ethernet 1/1/21 input
ICX(config-VLAN-10)# monitor ethernet 1/1/21
• Verification of monitoring on a VLAN can be viewed using:

ICX# show vlan 10
Untagged Ports: (Stk0/S1) 1
Tagged Ports: None
Uplink Ports: None
Monitoring: Enabled
Configuring ACL-based Inbound Mirroring
• Select traffic passing through an interface can be mirrored by using the mirror option when
configuring an ACL
1. Mirror keyword in IPv4, Layer 2 and IPv6 ACL clauses directs matching traffic to be mirrored1
• ACL is used to direct IP traffic to a mirror port
ICX(config)# ip access-list extended mirror-list
ICX(config-ext-nacl)# permit icmp any any echo mirror
ICX(config-ext-nacl)# deny icmp host 192.0.2.100 any echo-reply mirror
ICX(config-ext-nacl)# permit ospf any any mirror
ICX(config-ext-nacl)# permit ip any any
• MAC address filter-based mirroring

ICX(config)# mac filter 1 permit 0000.0000.0010 ffff.ffff.ffff 0000.0000.0020
ffff.ffff.ffff mirror
ICX(config)# mac filter 2 permit 0000.0000.0050 ffff.ffff.ffff 0000.0000.0020
ffff.ffff.ffff mirror
ICX(config)# mac filter 3 permit any any
• Syntax: [no] mac filter filter-num { permit | deny } { source-mac source-mask | any } { destination-mac
destination-mask | any } [ mirror ]
Footnote 1: As with any ACL, the final clause must permit desired traffic to flow: be
sure to add an appropriate permit any any clause to the end of any ACL intended to
mirror (and not filter) traffic. Failure to include the permit clause will result in
disruption of traffic through any interface to which the ACL is applied.
The following sections describe how to configure ACL-based Inbound Mirroring on an
ICX device:
• Creating an ACL with a mirroring clause
• Applying the ACL to an interface
• Specifying a destination mirror port
• Specifying the destination mirror port for physical ports
• Specifying the destination mirror port for a LAG
• Configuring ACL-based mirroring for ACLs bound to virtual interfaces
• Specifying the destination mirror port for IP receive ACLs
If both ACL mirroring and ACL-based rate limiting are applied on the same port, then
all packets that match are mirrored (including the packets that exceed the rate limit)
Configuring ACL-based Inbound Mirroring (Cont.)
2. Applying the ACL to an interface

ICX(config-if-e10000-1/1/1)# ip access-group mirror-list in
– Applying the MAC filtering to an interface

ICX(config-if-e10000-1/1/1)# mac filter-group 1 to 3
3. Specifying the destination mirror port for physical ports1

– ACL mirroring traffic from port 1/1/1 is mirrored to port 1/1/48
ICX(config-if-e10000-1/1/1)# acl-mirror-port ethernet 1/1/48
Footnote 1: If you complete the rest of the configuration but do not specify a
destination mirror port, the port-mirroring ACL is non-operational.
Configuring Mirroring on a LAG
• If the LAG virtual interface is enabled for monitoring, the entire LAG is monitored1
– An individual member port of a LAG can also be configure for monitoring using the monitor command
from the LAG configuration mode
• Configuring an mirroring on a LAG:

ICX(config)# lag mylag static id auto
ICX(config-lag-mylag)# ports ethernet 1/1/2 to 1/1/4
LAG mylag deployed successfully!
ICX(config-lag-mylag)# interface lag 1
ICX(config-lag-if-lg1)# monitor ethernet 1/1/48 both
• Syntax: [no] monitor [ ethernet stackid/slot/port ] { both | input | output }
• Configuring on an individual port of LAG:

ICX(config)# lag to-sw2 static id 1
ICX(config-lag-to-sw2)# ports ethernet 1/1/6 to 1/1/9
LAG to-sw2 deployed successfully!
ICX(config-lag-to-sw2)# monitor ethe-port-monitored 1/1/2 ethernet 1/1/1 both
Footnote 1: ACL based monitoring can be performed on a LAG interface as well.

• Syntax: [no] acl-mirror-port ethernet unit/slot/port
ACL Based Mirroring of a VE Interface
• To configure an ACL for ACL-based mirroring bound to a virtual interface, you must use the
acl-mirror-port command on a physical port that is a member of the same VLAN as the
virtual interface
ICX(config)# ip access-list extended mirror-list

ICX(config-std-nacl)# permit igmp any any mirror
ICX(config-std-nacl)# permit ip any any
ICX(config-std-nacl)# vlan 10
ICX(config-vlan-10)# router-interface ve 10
ICX(config-vlan-10)# interface ethernet 1/1/1
ICX(config-if-e1000-1/1/1)# acl-mirror-port ethernet 1/1/48
ICX(config-if-e1000-1/1/1)# interface ve 10
ICX(config-vif-10)# ip address 10.10.10.254/24
ICX(config-vif-10)# ip access-group mirror-list in
Displaying SPAN Mirror Configuration
• Mirror configuration within a switch can be displayed using:
– All mirrors configured on switch
ICX# show mirror

Mirror port 1/1/1
Input monitoring : (U1/M1) 1
Output monitoring : (U1/M1) 1
– Mirror configuration on a port
ICX# show mirror ethernet 1/1/1

Mirror port 1/1/1
Remote Switched Port Analyzer (RSPAN)
Remote Switched Port Analyzer
• Remote Switched Port Analyzer (RSPAN) enables remote monitoring of multiple switches
across a Layer 2 network
– Monitors traffic from source ports distributed over multiple switches and forwarded to capture devices
that are centralized
• The configured source port or ports are mirrored to an RSPAN VLAN
– Ports that are members of this VLAN receive the mirrored traffic
– Trunking of the RSPAN VLAN can be configured forwarding traffic to the monitoring devices1
– As with other SPANs traffic transmitted, received, or both directions of traffic can be mirrored to the
RSPAN VLAN
Footnote 1: RSPAN considerations:

• All participating devices must be connected by Layer 2 trunks, and the remote
VLAN must be configured on all devices participating in the RSPAN session.
20 source ports are supported
• There is no limitation on the number of member ports
• The RSPAN VLAN must be a non-existent VLAN in a switch and must be the same
across the network
• If the RSPAN VLAN is also used as a forwarding VLAN, each switch in the RSPAN
network receives two streams of traffic (one stream of flooded traffic and
another stream of mirrored traffic)
• A source port cannot be a member of the RSPAN VLAN
• A source port cannot be configured unless a destination port is already configured
• Management ports, stack ports, MCT ports, and PE ports are not supported
• Only one RSPAN VLAN can be configured in a single network
• STP and RSTP is supported on the RSPAN VLAN
• Normal VLAN commands are not applicable.
• MAC learning is disabled on the RSPAN VLAN
• Any VLAN can be configured as an RSPAN VLAN as long as all participating network
devices support the configuration of RSPAN VLANs. If tagged, outgoing packets
carry the RSPAN VLAN 802.1Q tag
• All packets are HW forwarded with no effect on the CPU
• RSPAN does not support double tagged packets at source
Configuring RSPAN at Source
• Configure the RSPAN VLAN by using the rspan-vlan command source switch
S1(config)# rspan-vlan 4000
• Add the forwarding port to RSPAN VLAN

S1(config-rspan-vlan-4000)# tagged ethernet 1/1/2
Added tagged port(s) ethe 1/1/2 to rspan-vlan 4000.
• Associate the forwarding port as the RSPAN traffic destination port

S1(config-rspan-vlan-4000)# rspan destination ethernet 1/1/2
• Add source ports that are to be monitored specifying traffic flow capture
S1(config-rspan-vlan-4000)# rspan source monitor-both ethernet 1/1/1
Configuring RSPAN Intermediate Devices
• Configure RSPAN VLAN and add ports that will be forwarding traffic to the destination
S2(config-rspan-vlan-4000)# tagged ethernet 1/1/1 ethernet 1/1/2 tagged
ethernet
• Continue this configuration on any switches along the path to the destination
S1 S2 S3
e 1/1/1 e 1/1/2 e 1/1/2 e 1/1/2
e 1/1/1 e 1/1/1
RSPAN VLAN 4000 Tunnel
The RSPAN VLAN will need to remain the same through the network so it is important
verify the VLAN ID chosen is not being used on any switches along the path. Repeat
this step on any intermediate devices to ensure the traffic is forwarded correctly to
the destination.
Configuring RSPAN Destination Switch
• Define the RSPAN VLAN and associate incoming and destination ports as member ports1
S3(config-rspan-vlan-4000)# tagged ethernet 1/1/1 ethernet 1/1/2
• Specify an interface as the RSPAN destination port

S3(config-rspan-vlan-4000)# rspan destination ethernet 1/1/2
• Configuration of RSPAN VLAN can be viewed on all configured switches using:

S3# show rspan-vlan
RSPAN details:
VLAN: 4000
RSPAN destination port: ethe 1/1/2
S1 S2 S3
e 1/1/1 e 1/1/2 e 1/1/2 e 1/1/2
e 1/1/1 e 1/1/1
RSPAN VLAN 4000 Tunnel
Footnote 1: Destination port must be a tagged member of the RSPAN VLAN

otherwise you will receive an error when trying to identify it as the destination port.
Destination port 1/1/2 must be a tagged member of RSPAN
vlan 4000
Encapsulated Remote Switched Port

Analyzer (ERSPAN)
Encapsulated Remote Switched Port Analyzer (ERSPAN)
• Allows mirroring of packets across a Layer 3 network Analyzer 2.2.2.2

– Encapsulation of monitored traffic can be sent to a remote port
• ERSPAN encapsulates mirrored packets using GRE with IP delivery
ERSPAN Tunnel
– Encapsulated traffic is forwarded using a special Layer 3 tunnel
• The data payload contains the original mirrored packet
• ERSPAN allows port mirroring from any port to any port

regardless of the port type and the modularity of the switch
– Ingress traffic only, egress traffic only, or both traffic flows can be
configured
ERSPAN Tunnel
• ERSPAN is available only in Layer 3 images e 1/2/1 1.1.1.1
e 1/1/5 e 1/1/6
Host 1 Host 2
ERSPA adds an additional feature to mirroring by allowing the forwarding of the

mirrored traffic over a layer 3 network. This is done by encapsulating the traffic
through a GRE tunnel terminating on the analyzer/host. Multiple ports to be mirrored
and forwarded to a centralized collection point where analyzers can reside. This
ERSPAN Configuration
• Create an ERSPAN profile and assign it a number Analyzer 2.2.2.2

ICX(config)# monitor-profile 1 type erspan
• This command puts you in monitor-profile mode
ERSPAN Tunnel
• Enter any preconfigured IP address configured on this source
router
ICX(config-monitor-profile 1)# source-ip 1.1.1.1
• Enter the IP address of the destination host
ICX(config-monitor-profile 1)# destination-ip 2.2.2.2
• The IP address is for the host/analyzer that is collecting the mirrored traffic,
not the destination switch
ERSPAN Tunnel
• Add mirroring to the profile on the interface
ICX(config-monitor-profile 1)# interface e 1/1/5
e 1/2/1 1.1.1.1
ICX(config-if-e1000-1/1/5)# monitor profile 1 both
ICX(config-if-e1000-1/1/5)# interface e 1/1/6 e 1/1/5 e 1/1/6
ICX(config-if-e1000-1/1/6)# monitor profile 1 in
• Either input, output or both can be chosen
Host 1 Host 2
ERSPAN feature limitations:

• The maximum number of mirroring sessions per device is four
• VLAN mirroring is not supported
• In some cases, speed mismatches may prevent mirroring of all traffic
You cannot terminate the Generic Routing Encapsulation (GRE) tunnel on an ICX
switch. ERSPAN must be terminated on the host/analyzer.
Verify ERSPAN Configuration
• Verify the configuration Analyzer

ICX# show erspan profile 1 2.2.2.2
Profile 1 ERSPAN Tunnel

Type ERSPAN
Mirror destination Reachable.
Destination IP 2.2.2.2
Destination MAC 000c.2930.7e60
Source IP 1.1.1.1
Source MAC 609c.9fe6.0858
Outgoing port 1/1/10
Ports monitored: ERSPAN Tunnel
Input monitoring : (U1/M1) 5 6
Output monitoring : (U1/M1) 5 e 1/2/1 1.1.1.1
HW destination id for each device:
stack_id/device:dest_id 1/1:3c000000 e 1/1/5 e 1/1/6
Host 1 Host 2
Additional ports can be added to this profile using the monitor profile command
under the physical interface. If multiple interfaces are configured they will be shown
in the display as shown below.
ERSPAN configured on multiple local interfaces example:
ICX# show erspan profile
Profile 1
Type ERSPAN
Mirror destination Reachable.
Destination IP 2.2.2.2
Destination MAC 000c.2930.7e60
Source IP 1.1.1.1
Source MAC 609c.9fe6.0858
Outgoing port 1/1/1
Ports monitored:
Input monitoring : (U1/M1) 5 6
Output monitoring : (U1/M1) 5 6
stack_id/device:dest_id 1/1:3c000000
If the Mirror destination indicates it is not reachable check the IP addresses

configured and that the destination IP address is routable from the local device.
Additionally many times the output will help identify the failure reason to help
resolve the problem.
Example: ICX(config)# show erspan profile 1

Profile 1
Type ERSPAN
Mirror destination Not reachable.
Reason: ***********
Destination IP 10.1.1.100Destination MAC
0000.0000.0000Source IP 10.1.1.1
Source MAC cc4e.0000.0000
Ports monitored:
stack_id/device:dest_id
There are seven reasons why a Mirror destination Not reachable error occurs.
Case Reason:
1 ARP is not resolved.
2 Route does not exist.
3 Outgoing port is a management port.
4 Outgoing port is a loopback port.
5 Outgoing port is a GRE IP tunnel port.
6 Outgoing port is not known.
7 Outgoing port is a sink port.
Denial of Service Attacks
Preventing DoS Attacks
• ICX switches includes several defenses to combat the two most popular types of DoS
attacks:
– Smurf attacks where ICMP is used to flood a victim and TCP SYN attacks which use a partial TCP 3-way
handshake1
• Avoiding being an intermediary in a smurf attack when using Layer 3 router code globally
ICX(config)# no ip directed-broadcast
• Avoiding being a victim in a smurf attack globally2

– Provides defense for ICMP targeted at the router itself or passing through an interface resulting in dropping them when the
thresholds are exceeded
ICX(config)# ip icmp attack-rate burst-normal 5000 burst-max 10000 lockup 300
• Syntax: ip icmp attack-rate burst-normal num-packets burst-max num-packets lockup time
– In this example, if ICMP packets received per second exceeds 5,000, the excess packets are dropped
– If ICMP packets received per second exceeds 10,000, all ICMP packets are dropped for the next 300 seconds
– Can be applied to a specific interface3

ICX(config-if-e1000-1/1/11)# ip icmp attack-rate burst-normal 5000 burst-max 10000
lockup 300
Footnote 1: A smurf attack relies on the intermediary to broadcast ICMP echo

request packets to hosts on a target subnet. When the ICMP echo request packet
arrives at the target subnet, it is converted to a Layer 2 broadcast and sent to the
connected hosts. This conversion takes place only when directed broadcast
forwarding is enabled on the device.
To avoid being an intermediary in a smurf attack, make sure forwarding of directed
broadcasts is disabled on the device. Directed broadcast forwarding is disabled by
default. To disable directed broadcast forwarding, enter the command shown the
slide example above.
Footnote 2: Configurable values:
The burst-normal value can be from 1 – 100000.
The burst-max value can be from 1 – 100000.
The lockup value can be from 1 – 10000.
The number of incoming ICMP packets per second are measured and compared to
the threshold values, as follows:
• If the number of ICMP packets exceeds the burst-max value, all ICMP packets are
dropped for the number of seconds specified by the lockup value. When the
lockup period expires, the packet counter is reset and measurement is restarted.
Footnote 3: For Layer 3 router code, if the interface is part of a VLAN that has a
router VE, you must configure ICMP attack protection at the VE level. Otherwise, you
can configure this feature at the interface level as shown above. When ICMP attack
protection is configured at the VE level, it will apply to routed traffic only. It will not
affect switched traffic.
Preventing DoS Attacks (cont.)
• TCP SYN attacks exploit the process of how TCP connections are established to disrupt
normal traffic flow
– Destination hosts keep track of the incomplete TCP connections in a connection queue
– In a TCP SYN attack, an attacker floods a host with TCP SYN packets that have random source IP addresses
filling the connection queue rapidly and possibly disallowing legitimate traffic
• To protect against participating in TCP SYN attacks on Ethernet and Layer 3 interfaces
ICX(config)# ip tcp burst-normal 1000 burst-max 3000 lockup 300
– Syntax: ip tcp burst-normal num-packets burst-max num-packets lockup time

ICX(config-if-e1000-1/2/1)# ip tcp burst-normal 1000 burst-max 3000 lockup 300
– The number of incoming TCP SYN packets per second are compared to the threshold values:
– If the number of TCP SYN packets exceeds the burst-normal value, the excess TCP SYN packets are dropped
– If the number of TCP SYN packets exceeds the burst-max value, all TCP SYN packets are dropped for the number of
seconds specified by the lockup value
It is important to understand that this feature helps keep your devices from being
participants in a botnet DDOS attack but does not protect servers from a TCP SYN
flood.
Great care must be taken to understand the normal SYN traffic rates from devices
connected to ports with TCP SYN attack protection enabled. Setting thresholds too
low can cause downstream clients to lose ability to create new TCP connections for
the lockup interval specified.
Syntax: ip tcp burst-normal value burst-max value lockup seconds
The burst-normal value can be from 1 – 100000.
The burst-max value can be from 1 – 100000.
The lockup value can be from 1 – 10000.
In this example, if the number of TCP SYN packets received per second exceeds 1000,
the excess packets are dropped. If the number of TCP SYN packets received per
second exceeds 3000, the device drops all TCP SYN packets for the next 300 seconds
(five minutes).
When incoming TCP SYN packets exceed the burst-max value, the following message
is logged.
<date> <time>:N:Local TCP exceeds <burst-max> burst
packets, stopping for <lockup> seconds!!
For Layer 3 router code, if the interface is part of a VLAN that has a router VE, you
must configure TCP SYN attack protection at the VE level. When TCP SYN attack
protection is configured at the VE level, it will apply to routed traffic only. It will not
affect switched traffic.
The following example sets the threshold value for TCP SYN packets received on VE
31.
ICX(config-vif-31)# ip tcp burst-normal 5000 burst-max
10000 lockup 300
Display DOS Attack Statistics
• This command displays information about ICMP and TCP SYN packets dropped because
burst thresholds were exceeded
ICX# show statistics dos-attack
------------------------------ Local Attack Statistics -------------------------
ICMP TCP-SYN
-------------------------------------- --------------------------------------
Dropped pkts Blocked pkts Lockup Count Dropped pkts Blocked pkts Lockup Count
------------ ------------ ------------ ------------ ------------ ------------
0 0 0 0 0 0
---------------------------- Transit Attack Statistics ------------------------------
ICMP TCP-SYN
------------------------------------------- --------------------------------------
Port/VE Dropped pkts Blocked pkts Lockup Count Dropped pkts Blocked pkts Lockup Count
------- ------------ ------------ ------------ ------------ ------------ ------------
1/1/11 0 0 0 0 0 0
• Clearing of statistics provide the ability to identify if the threat is ongoing or prepare for
possible future events
ICX# clear statistics dos-attack
Module Summary
• Attendees should now be will be able to:
– Perform general troubleshooting steps
– Troubleshoot LAG/LACP Issues
– Troubleshoot Spanning Tree issues
– Implement real time troubleshooting tools
– Configure different versions of Switched Port ANalyzer (SPAN)
– Implement Denial of Service attack features on ICX
End of Module 9:
Troubleshooting
ICX 200 OSPF & VRF
Module 10:
OSPF and
Virtual Route Forwarding (VRF)
ICX 200 OSPF & VRF
Module Objectives
– Understand OSPF features and their benefits
– Describe how to configure OSPF on ICX devices

• OSPFv2 and v3
– Explain advanced OSPF features
– Use show and debug commands to assess and troubleshoot an OSPF network
– Describe Virtual Route Forwarding capabilities on an ICX device
ICX 200 OSPF & VRF
OSPF Overview
• OSPF is a robust Interior Gateway Protocol (IGP) for medium to large networks
• Route topology database is created based on Shortest Path First (SPF) algorithm—Dijkstra’s
algorithm
• Link state routing protocol
• Route metric is based on aggregated link cost
• OSPF version supported:

– OSFPv2 – Exchanges IPv4 network prefixes
– OSPFv3 – Exchanges IPv6 network prefixes
Open Shortest Path First (OSPF) is a link-state routing protocol. Each OSPF device
originates link-state advertisement (LSA) packets to describe its link information.
These LSAs are flooded throughout the OSPF area. The flooding algorithm ensures
that every device in the area has an identical database. Each device in the area then
calculates a Shortest Path Tree (SPT) that shows the shortest distance to every other
device in the area, using the topology information in the Link State database.
OSPF Version 2 (OSPFv2) supports the exchange of IPv4 network prefixes.
OSPF Version 3 (OSPFv3) supports the exchange of IPv6 prefixes, which functions
similarly to OSPFv2, for IPv4 prefixes, except for the following enhancements:
• Ability to configure several IPv6 addresses on a device interface. (While OSPFv2
runs per IP subnet, OSPFv3 runs per link. In general, you can configure several
IPv6 addresses on a router interface, but OSPFv3 forms one adjacency per
interface only, using the link local address of the interface as the source for
OSPF protocol packets. On virtual links, OSPFv3 uses the global IP address of the
egress interface as the source. OSPFv3 imports all or none of the address
prefixes configured on a router interface. You cannot select the addresses to
import.)
• Ability to run one instance of OSPFv2 and one instance of OSPFv3 concurrently
on a link.
• Support for IPv6 link-state advertisements (LSAs).
NOTE – Although OSPFv2 and OSPFv3 function in a similar manner, Ruckus has
implemented the user interface for each version independently of the other.
Therefore, any configuration of OSPFv2 features will not affect the configuration of
OSPFv3 features and vice versa.
ICX 200 OSPF & VRF
OSPF Support
• ICX switches support the following types of LSAs

– Type 1 – Router LSA
– Type 2 – Network LSA
– Type 3 – Summary LSA
– Type 4 – Autonomous system (AS) summary LSA
– Type 5 – AS external LSA
– Type 7 – Not-So-Stubby Area (NSSA) external LSA
– Type 8 – Link LSA (OSPFv3)
– Type 9 – Intra-Area Prefix LSA (OSPFv3)
• Also used for Graceful Restart (OSPFv2 and OSPFv3)
• Area Types:
– Normal, Stub, Not-So-Stubby Area (NSSA), Totally Stub
Ruckus devices support the following types of LSAs, which are described in RFC 2328
and 3101:
• Router LSA (Type 1)
• Network LSA (Type 2)
• Summary LSA (Type 3)
• Autonomous system summary LSA (Type 4)
• AS external LSA (Type 5)
• Not-So-Stubby Area (NSSA) external LSA (Type 7)
• Grace LSAs (opaque LSA type 9)
Communication among areas is provided by means of link state advertisements
(LSAs). The LSAs supported for each area type are as follows:
• Backbone (area 0) supports LSAs 1, 2, 3, 4, and 5.
• Non-backbone area supports LSAs 1, 2, 3, 4, and 5.
• Stub area supports LSAs 1, 2, and 3.
• Totally stubby area (TSA) supports LSAs 1 and 2, and also supports a single LSA 3
per ABR, advertising a default route.
• No so stubby area (NSSA) supports LSAs 1, 2, 3, and 7.
• LSAs 8 and 9 are link-local, not area-wide.
ICX 200 OSPF & VRF
ICX OSPF Features
• ICX switches support other optional features:
– OSPF Authentication
– OSPF Virtual-Links
– OSPF Graceful Restart
– OSPF distribute list (local route filtering)
– OSPF Route Summarization
– Default Route Advertisements
– Administrative distance route type manipulation
All of the features listed here will be discussed in the remainder of this module.
ICX 200 OSPF & VRF
Router ID Requirement
• Routing protocols use a single value to identify devices

– Therefore it is recommended to configure the Router ID to improve troubleshooting and device
identification
• If no Router ID is configured, an ICX device uses the following to select a router ID:
– IP address configured on the lowest numbered loopback interface (loopback 1 > loopback 2)
– If there is no loopback interface configured the lowest numbered IP interface address on the device is
used (10.255.1.1 > 172.16.1.1)
• Router ID always uses the same format as an IPv4 address

– Even when used in IPv6-only environments
• Layer 3 ICX switches use the same router ID for both OSPF and BGP4
Router(config)# ip router-id 10.157.22.26
Although a Layer 3 device may have multiple IP addresses configured on different

interfaces, some routing protocols require a single, unique identifier for each router
in the network. This is what the router ID is for.
In most configurations, a Layer 3 device has multiple IP addresses, usually configured
on different interfaces. As a result, a Layer 3 device’s identity to other devices varies
depending on the interface to which the other device is attached. Some routing
protocols, including Open Shortest Path First (OSPF) and Border Gateway Protocol
version 4 (BGP4), identify a Layer 3 device by a unique identifier, which is often
derived from just one of the IP addresses configured on the Layer 3 device, regardless
of the interfaces that connect between the Layer 3 devices. This unique identifier is
the router ID.
The router ID on a Ruckus layer 3 switch, where an explicit router ID has not been
configured, is one of the following:
• If the router has loopback interfaces, the default router ID is the IP address
configured on the lowest numbered loopback interface configured on the Layer
3 device. For example, if you configure loopback interfaces 2 and 3 as follows,
the default router ID is 10.4.4.4:
• Loopback interface 2, 10.4.4.4/24
• Loopback interface 3, 10.1.1.1/24
• If the device does not have any loopback interfaces, the default router ID is the
lowest numbered IP interface configured on the device.
Unless a router ID is explicitly configured, a reload of the device may result in new
router ID being used. Based on example here, if Loopback 1 is configured. On the next
reboot, the router ID of the device will use the address of Loopback 1.
ICX 200 OSPF & VRF
OSPF Basic Configuration Overview
• To implement OSPFv2 and/or OSPFv3
1. Enter the router ospf and/or ipv6 router ospf command in global configuration mode to enable OSPF
on the device
2. Assign the areas to which the device will be attached
3. Assign individual interfaces to an OSPF area
4. Optionally, assign a virtual link to any ABR that does not have a direct link to the OSPF backbone area
5. Optionally, change any desired default settings
Ruckus ICX switches allow the running of both OSPFv2 and OSPFv3 at the same time.
This is due to the independent configuration methods for each. Therefore, any
configuration of features for one version will not affect the configuration of the other.
As with all IPv6 features, the ipv6 unicast-routing command must be executed prior
to configuring any protocols that support the exchange of IPv6 addresses.
In most cases, the features described in the material can be used in both OSPFv2 and
OSPFv3 with minor changes in command syntax. The OSPFv3 versions of commands
and options available for them will be available in the notes section of the page.
ICX 200 OSPF & VRF
OSPF Areas
• OSPF areas can be identified by either number1 or in dotted decimal (IPv4 address) format
– By default an area is normal, unless identified otherwise
– Each interface on a router can support only one area
• Area can be configured as:

– Normal area
Router(config-ospf-router)# area 0 Decimal value = 256
– Stub Area
Router(config-ospf-router)# area 40 stub
– Not-So-Stubby-Area (NSSA)
Router(config-ospf-router)# area 0.0.1.0 nssa
– Totally Stubby Area
Router(config-ospf-router)# area 255 stub no-summary
Footnote 1: If you specify a number, the number can be from 0 - 2,147,483,647.

• Normal - OSPF routers within a normal area can send and receive External Link
State Advertisements (LSAs).
• Stub - OSPF routers within a stub area cannot send or receive External LSAs. In
addition, OSPF routers in a stub area must use a default route to the area’s Area
Border Router (ABR) or Autonomous System Boundary Router (ASBR) to send
traffic to any external routes that exist outside of the area.
• NSSA - The ASBR of an NSSA can import external route information into the area.
Additional options are available.
ASBRs redistribute (import) external routes into the NSSA as type 7 LSAs. Type-7
External LSAs are a special type of LSA generated only by ASBRs within an NSSA,
and are flooded to all the routers within only that NSSA.
• ABRs translate type 7 LSAs into type 5 External LSAs, which can then be flooded
throughout the AS. You can configure address ranges on the ABR of an NSSA so
that the ABR converts multiple type-7 External LSAs received from the NSSA
into a single type-5 External LSA.
• When an NSSA contains more than one ABR, OSPF elects one of the ABRs to
perform the LSA translation for NSSA. OSPF elects the ABR with the highest
router ID. If the elected ABR becomes unavailable, OSPF automatically elects
the ABR with the next highest router ID to take over translation of LSAs for the
NSSA. The election process for NSSA ABRs is automatic.
• Totally Stubby – When an area is identified as a totally stubby area the ABR will
stop sending summary LSAs (type 3 LSAs) into the area. Instead it will send one
summary LSA which is a default route.
ICX 200 OSPF & VRF
OSPF Basic Configuration Steps
• On each router:
e1 e1
1. Enable OSPF globally
Router_B(config)# router ospf
Router A Router B
2. Configure an OSPF area1

Router_B(config-ospf-router)# area 0
3. Assign an IP address to the interface

Router_B(config-ospf-router)# interface e1/1/1
Router_B(config-if-e1000-1/1/1)# ip address 172.16.1.2/24
4. Assign interfaces to an area2

Router_B(config-if-e1000-1/1/1)# ip ospf area 0
Footnote 1: If the device is acting as an ABR, all areas in which the ABR is
participating need to be configured.
Footnote 2: When an interface is assigned to an area, the subnets assigned to that
interface are included in OSPF LSAs and OSPF hello messages are sent on each
subnet, by default.
You can configure and save the following OSPF changes without resetting the system:
• All OSPF interface-related parameters (for example: area, hello timer, router
dead time cost, priority, re-transmission time, transit delay)
• All area parameters
• All area range parameters
• All virtual-link parameters
• All global parameters
• Creation and deletion of an area, interface or virtual link
• Changes to address ranges
• Changes to global values for redistribution
• Addition of new virtual links
OSPFv3 Example:
Router_B(config)# ipv6 router ospf
Router_B(config-ospf6-router)# area 0
Router_B(config-ospf6-router)# interface e1/1/1
Router_B(config-if-e1000-1/1/1)# ipv6 address
2001:db8:12d:1011::/64 eui-64
Router_B(config-if-e1000-1/1/1)# ipv6 ospf area 0
ICX 200 OSPF & VRF
OSPF Authentication
• Authentication can be used to secure the OSPF network

– It prevents the connecting of an unknown router into the AS
– Authentication parameters are carried in every OSPF packet
• Supported methods of authenticating OSPF packets from neighbors:

– Simple text password
ICX(config-if-e1000-1/1/1)# ip ospf authentication plain-text SimpleTextKey
• Syntax: [no] ip ospf authentication plain-text key-string
– MD5/HMAC SHA1/HMAC SHA256 authentication
ICX(config-if-e1000-1/1/1)# ip ospf authentication md5 key-id 128 key MD5EncryptedKey
• Syntax: [no] ip ospf authentication { md5 | hmac-sha-1 | hmac-sha-256} key-id key-id-val key key-string
• Wait timers can be modified to allow more time before enforcing the security policy
(default 300 seconds)
ICX(config-if-e1000-1/1/1)# ip ospf authentication key-activation-wait-time 600
• Syntax: [no] ip ospf authentication key-activation-wait-time wait-time
Ruckus ICX devices have no authentication by default. OSPFv2 supports plain-text,

md5, HMAC-SHA1 and HMAC-SHA256 authentication. OSPFv3 only supports HMAC-
SHA1 and HMAC-SHA256 authentication.
Configuring simple text password authentication:
Router(config-if-e1000-1/1/1)# ip ospf authentication
plain-text SimpleTextKey
Syntax: [no] ip ospf authentication plain-text key-string
Configuring MD5/HMAC-SHA1/HMAC-SHA256 password authentication:
Router(config-if-e1000-1/1/1)# ip ospf authentication md5
key-id 128 key MD5EncryptedKey
Syntax: [no] ip ospf authentication { md5 | hmac-sha-1 | hmac-sha-256} key-id
key-id-val key key-string
Syntax: [no] ipv6 ospf authentication {hmac-sha-1 | hmac-sha-256} key-id key-id-
val key key-string
OSPF gracefully implements authentication changes to allow all routers to implement
the change and thus prevent disruption to neighbor adjacencies. During the
authentication-change interval, both the old and new authentication information is
supported. The default authentication-change interval is 300 seconds (5 minutes).
You change the interval to a value from 0 - 14400 seconds.
Router(config-if-e1000-1/1/1)# ip ospf authentication
key-activation-wait-time 600
Syntax: [no] ip ospf authentication key-activation-wait-time wait-time
Syntax: [no] ipv6 ospf authentication key-activation-wait-time wait-time
Revision 0919 10 - 10
ICX 200 OSPF & VRF
OSPF Virtual Links
• OSPF requires all non-backbone areas be directly connected to the backbone area (Area 0)
• Virtual links create a virtual connection through a non-backbone area
• Virtual links are created between Area Border Routers (ABR)
Area 2
• To create a virtual link: Router A Router E
RID: 10.10.10.1 RID: 209.157.22.1
– Both routers must share a common area Virtual Link
– The transit area cannot be a stub area

– One of the ABRs must be connected to Area 0
Area 0 Area 5
All ABRs must have either a direct or indirect link to the OSPFv2 backbone area
(0.0.0.0 or 0). If an ABR does not have a physical link to the area backbone, the ABR
can configure a virtual link to another router within the same area, which has a
physical connection to the backbone area.
The path for a virtual link is through an area shared by the neighbor ABR (router with
a physical backbone connection), and the ABR requires a logical connection to the
backbone.
Two parameters fields must be defined for all virtual links—transit area ID and
neighbor router:
• The transit area ID represents the shared area of the two ABRs and serves as
the connection point between the two routers. This number should match the
area ID value.
• The neighbor router field is the router ID (IP address) of the router that is
physically connected to the backbone, when assigned from the router interface
requiring a logical connection. When assigning the parameters from the router
with the physical connection, be aware that the neighbor router field uses the
router ID of the router requiring a logical connection to the backbone.
Virtual links cannot be configured in stub areas and NSSAs.
Revision 0919 10 - 11
ICX 200 OSPF & VRF
OSPF Virtual Link Configuration
• Configure OSPF Virtual Links

– Define the virtual link on RouterA:
RouterA(config-ospf-router)# area 2 virtual-link 209.157.22.1
– Define the virtual link on RouterE:

RouterE(config-ospf-router)# area 2 virtual-link 10.10.10.1
Area 2
Router A Router E
RID: 10.10.10.1 RID: 209.157.22.1
Virtual Link
• Authentication can be configured: Area 0 Area 5
RouterE(config-ospf-router)# area 2 virtual-link 10.10.10.1

authentication md5 key-id 128 key MD5EncryptedKey
– OSPFv2 – Plain-text, MD5, HMAC-SHA1 and HMAC-SHA256 are supported
– OSPFv3 – HMAC-SHA1 and HMAC-SHA256 are supported
Virtual links are configured with the area id virtual-link command.

Syntax: area { ip-addr | decimal } virtual-link E.F.G.H [ dead-interval time ] [ hello-
interval time ] [ retransmit-interval time ] [ transmit-delay time ]
• The area { ip-addr | decimal } parameter specifies the transit area.
• The E.F.G.H parameter specifies the router ID of the OSPF router at the
remote end of the virtual link. To display the router ID on an ICX Layer 3
Switch, enter the show ip command.
Note: The area virtual-link command for OSPFv3 also supports a hello-jitter
parameter that sets a threshold for allowed jitter between hello packets.
Optionally, authentication can be configured on a virtual link. Plain-text, MD5, HMAC-
SHA1 and HMAC-SHA256 are the supported authentication methods. They are
configured as additional arguments to the area virtual-link command. For example:
RouterA(config-ospf-router)# area 2 virtual-link
209.157.22.1 authentication md5 key-id 128 key
MD5EncryptedKey
RouterE(config-ospf-router)# area 2 virtual-link
10.10.10.1 authentication md5 key-id 128 key
MD5EncryptedKey
Syntax: [no] area { ip-addr | decimal } virtual-link E.F.G.H authentication plain-text
key-string
Syntax: [no] area { ip-addr | decimal } virtual-link E.F.G.H authentication { md5 |
hmac-sha-1 | hmac-sha-256} key-id key-id-val key key-string
Revision 0919 10 - 12
ICX 200 OSPF & VRF
OSPF Graceful Restart
• Allows an OSPF router to reset without impacting neighbor SPF trees or Link State
Databases1
• Sends grace-LSAs to neighbor routers indicating it will restart within a specified amount of
time (grace period)
• Helper routers2 continue advertising the resetting router’s LSAs as if they were still fully
adjacent
• When the restarting router comes up it uses pre-reset routes to forward packets while re-
establishing neighbor relationships
• All grace-LSAs are flushed once neighbor relationships are fully established
Footnote 1: Useful for ISSU on non stop routing supporting devices, use with care on
devices without non-stop where other redundant paths exist since graceful restart
can black hole otherwise valid traffic.
The ICX implementation of Graceful Restart supports RFC 3623: Graceful OSPF
Restart. With this feature enabled, disruptions in forwarding are minimized and route
flapping diminished to provide continuous service during times when a router
experiences a restart.
A restarting router sends special LSAs to its neighbors called grace-lsas. These LSAs
are sent to neighbors either before a planned OSPF restart or immediately after an
unplanned restart. A grace LSA contains a grace period value that the requesting
routers asks its neighbor routers to use for the existing routes, to and through the
router after a restart.
The restarting router comes up, it continues to use its existing OSPF routes to forward
packets. In the background, it re-establishes OSPF adjacencies with its neighboring
router, relearns all OPSF LSAs, recalculates its OSPF routes, and replaces them with
new routes as necessary.
Once the restarting router relearns all OSPF routes, it flushes the grace LSAs from the
network, informing the helper routers of the completion of the restart process. If the
restarting router does not re-establish adjacencies with the helper router within the
restart time, the helper router stops the helping function and flushes the stale OSPF
routes.
Revision 0919 10 - 13
ICX 200 OSPF & VRF
Graceful Restart Configuration
• Graceful Restart and Graceful Restart Helper are enabled by default

– Use the following command to disable the graceful restart:
Router(config)# router ospf
Router(config-ospf-router)# no graceful-restart
– To re-enable graceful restart for the global instance:
Router(config-ospf-router)# graceful-restart
• You can specify the maximum amount of time advertised to a neighbor router to maintain
routes from and forward traffic to a restarting router
Router(config-ospf-router)# graceful-restart restart-time 180
• You can prevent your router from participating in the OSPF Graceful Restart helper
function
Router(config-ospf-router)# graceful-restart helper-disable
OSPF graceful restart and graceful restart helper are enabled by default on ICX
devices. Use the following command to disable the graceful restart feature for the
global instance on a device.
Router(config-ospf-router)# no graceful-restart
To re-enable graceful restart for the global instance:
Router(config-ospf-router)# graceful-restart
Use the following command to specify the maximum amount of time advertised to a
neighbor router to maintain routes from and forward traffic to a restarting router.
Router(config-ospf-router)# graceful-restart restart-
time 180
You can prevent your router from participating in OSPF Graceful Restart by using the
following command.
Router(config-ospf-router)# graceful-restart helper-
disable
Syntax: [no] graceful-restart [ helper-disable | restart-time seconds ]
Graceful restart and graceful restart helper capabilities are enabled by default.
Parameters:
• helper-disable - Disables the GR helper capability.
• restart-time - Specifies the maximum restart wait time, in seconds, advertised
to neighbors. The default value is 120 seconds. The configurable range of values
is from 10 through 1800 seconds.
Revision 0919 10 - 14
ICX 200 OSPF & VRF
OSPF Cost Metric
• Cost (metric): Indicates the overhead required to send a packet across an interface
– Default cost is calculated by dividing reference-bandwidth, 100 Mbps by default, by the link speed
• 10 Mbps = 10
• 100 Mbps = 1
• 1 Gbps = 1
• 10 Gbps = 1
• 100 Gbps = 1
– Reference bandwidth can be modified
Link Cost = _Reference-Bandwidth_

Link Speed (Mbps)
Each interface on which OSPFv2 is enabled has a cost associated with it. The device
advertises its interfaces and their costs to OSPFv2 neighbors. For example, if an
interface has an OSPFv2 cost of ten, the device advertises the interface with a cost of
ten to other OSPFv2 routers.
By default, an interface’s OSPFv2 cost is based on the port speed of the interface. The
cost is calculated by dividing the reference bandwidth by the port speed. The default
reference bandwidth is 100 Mbps, which results in the following default costs:
• 10 Mbps port - 10
• All other port speeds - 1
You can change the reference bandwidth. The following formula is used to calculate
the cost:
Cost = reference-bandwidth/interface-speed
The bandwidth for interfaces that consist of more than one physical port is calculated
as follows:
• LAG group - The combined bandwidth of all the ports.
• Virtual interface - The combined bandwidth of all the ports in the port-based
VLAN that contains the virtual interface.
The default reference bandwidth is 100 Mbps. You can change the reference
bandwidth to a value from 1—4294967.
If a change to the reference bandwidth results in a cost change to an interface, the
device sends a link-state update to update the costs of interfaces advertised by the
device.
Revision 0919 10 - 15
ICX 200 OSPF & VRF
OSPF Cost Metric (cont.)
• As a best-practice the default reference bandwidth should be the same for all routers in
the network
• For networks with interfaces over 100 Mbps, it is recommended to modify the reference
bandwidth
• To change the default reference bandwidth (in Mbps):

Router_B(config-ospf-router)# auto-cost reference-bandwidth 40000
• To manually assign a cost to an interface:

Router_B(config-ospf-router)# int ethernet 1/1/2
Router_B(config-if-e1000-1/1/2)# ip ospf cost 100
The chart below lists the recommended reference-bandwidth setting for routers
based on the routers highest interface speed. For routers with mixed
10/100/1000/10,000 Mbps Ethernet ports the recommended reference-bandwidth is
set equal to the highest-speed network link in Mbps.
Link Speed Reference-Bandwidth
100 Mbps or lower 100 Mbps (Default )
1 Gbps 1000 Mbps
10 Gbps 10000 Mbps
40 Gbps 40000 Mbps
100 Gbps 100000 Mbps
If you specify the cost for an individual interface, the cost you specify overrides the
cost calculated by the software.
OSPFv3 Example:
Router_B(config-ospf6-router)# auto-cost reference-
bandwidth 10000
Router_B(config)# int ethernet 1/1/2
Router_B(config-if-e1000-1/1/2)# ipv6 ospf cost 100
Revision 0919 10 - 16
ICX 200 OSPF & VRF
IP Load Sharing
• If the IP route table contains multiple paths to a destination, each having the lowest cost,
then the router uses IP load sharing to distribute the traffic
– You can enable a Layer 3 switch to load-balance above the
default of 4 equal-cost paths
Router(config)# ip load-sharing 5
Router(config)# show ip route
1 10.1.1.0/24 DIRECT e 1/1/17 0/0 D 4h21m
2 10.168.1.0/24 DIRECT e 1/1/1 0/0 D 4h22m
3 10.255.255.0/24 10.1.1.2 e 1/1/17 110/2 O 17h27m
10.255.255.0/24 10.168.1.2 e 1/1/1 110/2 O 17h27m
10.255.255.0/24 192.123.2.2 e 1/1/8 110/2 O 17h27m
10.255.255.0/24 192.123.22.2 e 2/1/22 110/2 O 17h27m
10.255.255.0/24 192.123.44.2 e 3/1/24 110/2 O 1m27s
4 192.123.2.0/24 DIRECT ve 2 0/0 D 4h20m
5 192.123.22.0/24 DIRECT ve 20 0/0 D 4h20m
The IP route table can contain more than one path to a given destination. When this
occurs, the Layer 3 Switch selects the path with the lowest cost as the path for
forwarding traffic to the destination. If the IP route table contains more than one
path to a destination and the paths each have the lowest cost, then the Layer 3
Switch uses IP load sharing to select a path to the destination.
IP load sharing is based on the destination address of the traffic. Layer 3 Switches
support load sharing based on individual host addresses or on network addresses.
Stackable Layer 3 Switches support load sharing based on host addresses.
You can enable a Layer 3 Switch to load balance across up to eight equal-cost paths.
The default maximum number of equal-cost load sharing paths is four.
IP load sharing is not based on source routing, only on next-hop routing.
The term “path” refers to the next-hop router to a destination, not to the entire route
to a destination. Thus, when the software compares multiple equal-cost paths, the
software is comparing paths that use different next-hop routers, with equal costs, to
the same destination.
Equal cost paths can include OSPF, RIP and static routes. Maximum equal cost paths
vary between switch families. Consult your switch documentation on its load sharing
capabilities.
NOTE: On ICX 7650, ICX 7750, and ICX 7850 devices, the value range for the
maximum number of load-sharing paths is from 2 through 32 ,which is controlled by
the system-max max-ecmp command.
Revision 0919 10 - 17
ICX 200 OSPF & VRF
Redistribution
• Allows routes learned from other mechanisms and protocols to be advertised into OSPF
– Connected interfaces
– Static routes
– Dynamic routing protocols
• Redistribution for ICX devices:

Router_B(config-ospf-router)# redistribute ?
bgp Border Gateway Protocol (BGP)
connected Connected
rip Routing Information Protocol (RIP)
static Static routes
• Redistribution of external routes into OSPF automatically makes the router an ASBR
The redistribution command under the routing protocol configuration context allows
routes learned from other mechanisms to be advertised into the protocol.
Redistribution enables one routing protocol to learn and advertise routes that exist
under some other process. The other process could be another dynamic routing
protocol (another instance of the same routing protocol or a different routing
protocol), static routes, or directly connected interfaces on which no routing protocol
has been enabled.
The redistribution rip command under router-ospf takes RIP routes and sends them
out as OSPF LSAs.
OSPF does not include directly connected networks in routing updates. The
redistribution connected command takes directly connected routes and sends them
out as OSPF LSAs.
Redistribution should be employed in conjunction with a redistribution route map.
Otherwise, you might accidentally overload the network with routes you did not
intend to redistribute.
OSPFv3 Example:
Router_B(config-ospf6-router)# redistribute ?
Revision 0919 10 - 18
ICX 200 OSPF & VRF
OSPF External Metric
• OSPF external routes are advertised with two possible metrics:

– Type 1: Cost is calculated by adding the external cost metric to the internal link costs
– Type 2: Cost is calculated using only the external cost metric, no internal link costs are added
• Default metric type for ICX ASBRs

Router_B(config-ospf-router)# metric-type type1
External Link Link Cost = 10 External Link Link Cost = 10

Cost=2 Cost=2 Router C – IP Route Table
10.10.10.0/24 20.20.20.0/24 Network Cost
Redistributed w/ Redistributed w/ 10.10.10.0/24 2
Type 2 metric Type 1 metric
20.20.20.0/24 12
By default, Ruckus ICX ASBRs advertise external routes with a Type 2 metric.
In the graphic above, Router A (the ASBR) is advertising the external 10.10.10.0/24
network with a Type 2 metric. Router B is advertising the 20.20.20.0/24 network with
a Type 1 metric. Both external routes are assigned an external link cost of 2 when
advertised. For the route with a Type 1 metric, each router will add the OSPF link
cost before inserting it into the IP routing table. The route with a Type 2 metric does
not have the internal link costs added to the metric.
It is also important to note that a Type 1 external route is always preferred over a
Type 2 external route, regardless of the cost.
Revision 0919 10 - 19
ICX 200 OSPF & VRF
Originate A Default Route with OSPF
• A static default route with redistribute static will not propagate 0.0.0.0/0 into OSPF
• The default-information originate

command is used to propagate
default routes into OSPF1
Router_B(config-ospf-router)# default-information-originate
Footnote 1: A statically configured default route also requires default-information-

originate in order to propagate the route into OSFP. The redistribute static command
does not apply to the statically configured default route.
Other examples of default-information-originate are:
Router(config-ospf-router)# default-information-originate route-
map defaultToOspf
Router(config-ospf-router)# default-information-originate always
Router(config-ospf-router)# default-information-originate metric
200
In the above example, default-information-originate is enabled with the route-map

parameter for the first CLI and then the always and metric is appended to the existing
configuration. The running configuration of the above three split commands would be
as follows:
Router(config-ospf-router)# default-information-originate
always metric 200 route-map defaultToOspf
Syntax: [no] default-information-originate [ always ] [ metric metric ] [ metric-type {
type1 | type2 } ] [ route-map name ]
Note: the always parameter will advertise a default route even when one is not
statically configured. This may result in routing issues and problems with other
routing protocols .
OSPFv3 Example:
Router_B(config-ospf6-router)# default-information-originate
Revision 0919 10 - 20
ICX 200 OSPF & VRF
Passive Interface
• In some cases, networks on an interface should be advertised into OSPF, but should never
form adjacency with another OSPF router
• A passive interface does not send or process OSPF hello messages
• Can be configured on the entire interface, impacting all configured IPs
• Can be configured for specific IP address only

Salt_Lake(config-if-e1000-1/1/7)# ip address 192.168.40.129/28 ospf-passive
Salt_Lake(config-if-e1000-1/1/7)# ip address 192.168.40.145/28
Salt_Lake(config-if-e1000-1/1/7)# ip ospf area 2
When an interface is configured as passive, it allows the IP networks configured on

the interface to be included in the OSPF area, but the interface does not send or
listen to OSPF hello messages.
In the graphic above, Salt Lake advertises the 192.168.40.128/26 block of networks in
a Type 1 LSA, however it does not send or listen to OSPF hellos on any of the IP
networks configured on multi-netted interface e1/1/7.
While this behavior is similar to route redistribution, the key difference is that a
passive interface is advertised as local to the AS (Type 1 LSA) and redistributed routes
are advertised as AS-external (Type 5 or Type 7)
In addition to the example provided above, ospf-passive can be also be configured on
a single IP instance of a multinetted interface:
Salt_Lake(config-if-e1000-1/1/7)# ip address
192.168.40.129/28 ospf-passive
Salt_Lake(config-if-e1000-1/1/7)# ip address
192.168.40.145/28
Note: To set all the OSPFv2 interfaces to passive, enter the following command. (VRF
interfaces are supported as well using the router ospf vrf <name> command)
Router(config-ospf-router)# default-passive-interface
Revision 0919 10 - 21
ICX 200 OSPF & VRF
OSPF-Ignore
• By default, all IPs on an interface are advertised when OSPF is enabled

• To filters individual subnets on multi-netted interfaces, use ospf-ignore
ASBR BGP Peer

e7 e1 e2 e1 e1
Salt Lake Seattle Portland Vancouver
192.168.90.1/25 192.168.90.2/25
Area 2 Area 0
Salt_Lake(config-if-e1000-1/1/7)# ip address 192.168.40.145/28

Salt_Lake(config-if-e1000-1/1/7)# ip address 192.168.40.129/28 ospf-ignore
• Network 192.168.40.128/28 is not available as an OSPF route
Networks configured with ospf-ignore are not represented as OSPF networks, but are
available for local routing.
This filter is used in cases where OSPF must be enabled on a multi-netted interface,
but not all IP networks configured are meant to be advertised to OSPF neighbors.
In the graphic above, the 192.168.40.129 interface does not send or respond to OSPF
message. In addition, the 192.168.40.128/28 network is not advertised to OSPF
neighbors because of the ospf-ignore argument applied to the IP address statement.
OSPFv3 Example:
Salt_Lake(config-if-e1000-1/1/7)# ipv6 address
2001:db8:144::1/64
Salt_Lake(config-if-e1000-1/1/7)# ipv6 address
2001:db8:128::1/64 ospf-ignore
Salt_Lake(config-if-e1000-1/1/7)# ipv6 ospf area 2
Revision 0919 10 - 22
ICX 200 OSPF & VRF
OSPF Route Filters and Summarization
Revision 0919 10 - 23
ICX 200 OSPF & VRF
Distribution Lists
• Allow you to filter OSPF routes from being installed in the IP routing table
– Leverages Access Control Lists to define network filters
• Scenario: Salt Lake should not be allowed to reach the 192.168.60.64/26 block of networks
in Vancouver1
Footnote 1: This feature does not block receipt of LSAs for the denied routes being
sent to other routers. The Layer 3 switch still receives the routes and installs them in
the OSPF database. The feature only prevents the software from installing the denied
OSPF routes into the local IP route table. By default, all OSPF routes in the OSPF route
table are eligible for installation in the IP route table.
Revision 0919 10 - 24
ICX 200 OSPF & VRF
Configuring Distribution Lists
• Configure an ACL to filter the desired network

• Apply distribute-list in global OSPF process to filter on received (inbound) routes
192.168.60.64/26 block
ASBR BGP Peer

e7 e1 e2 e1 e1
192.168.90.1/25 192.168.90.2/25
Area 2 Area 0
Salt_Lake(config)# ip access-list standard PARTNER-net

Salt_Lake(config-std-nac1)# deny 192.168.60.64/26
Salt_Lake(config-std-nac1)# permit any
Salt_Lake(config-std-nac1)# router ospf
Salt_Lake(config-ospf-router)# distribute-list PARTNER-net in
In the example above, an access-list (ACL) is created to define the network and mask
to deny. The ACL is then applied as a distribution list under the global OSPF router
configuration context to filter it in any incoming LSAs. In this manner, the distribution
list will prevent the denied network from being added to the IP routing table.
However, this does not prevent the route advertised in an LSA from entering Salt
Lake’s LSDB. It only prevents the SPF algorithm from installing the filtered route into
Salt Lake’s IP route table. This distribution-list is applied locally and only impacts the
router on which it is configured. All other routers that require this filter must have a
similar distribution list configured.
To configure an OSPFv2 distribution list using ACLs:
• Configure an ACL that identifies the routes you want to deny. Using a standard
ACL allows you deny routes based on the destination network, but does not
filter based on the network mask. To also filter based on the network mask of
the destination network, use an extended ACL.
• Configure an OSPFv2 distribution list that uses the ACL as input.
Syntax: distribute-list access-list list-name in
Revision 0919 10 - 25
ICX 200 OSPF & VRF
You can filter the routes to be placed in the OSPFv3 route table by configuring
distribution lists.
The functionality of OSPFv3 distribution lists is similar to that of OSPFv2 distribution
lists. However, unlike OSPFv2 distribution lists, which filter routes based on criteria
specified in an Access Control List (ACL), OSPFv3 distribution lists can filter routes
using information specified in an IPv6 prefix list or a route map.
Prefix lists are configured in a similar manner to ACLS, but offer additional
functionality.
For example:
Salt_Lake(config)# ipv6 prefix-list PARTNER-net deny
2001:db8:e0bb::/64
Salt_Lake(config)# ipv6 router ospf
Salt_Lake(config-ospf6-router)# distribute-list prefix-list
PARTNER-net in
Syntax:
• ipv6 prefix-list { name | sequence-number } deny ipv6-prefix/prefix-length [ ge
ge-value ] [ le le-value ]
• ipv6 prefix-list { name | sequence-number } description string
• ipv6 prefix-list { name | sequence-number } permit ipv6-prefix/prefix-length [
ge ge-value ] [ le le-value ]
• ipv6 prefix-list { name | sequence-number } seq sequence-number permit ipv6-
prefix/prefix-length [ ge ge-value ] [ le levalue ]
• ipv6 prefix-list { name | sequence-number } seq sequence-number deny ipv6-
prefix/prefix-length [ ge ge-value ] [ le levalue ]
Revision 0919 10 - 26
ICX 200 OSPF & VRF
OSPF Route Summarization
• Saves device resources by grouping IP networks together to minimize advertisements
• Achieved by adjusting the subnet mask of network advertisements allowing a single

advertisement to announce multiple networks
• Made possible through use of Classless Inter-Domain Routing (CIDR)
• OSPF is capable of performing two types of summarization:

– Inter-area summarization: Configured on an ABR to minimize advertisements into an adjoining area
– External summarization: Configured on an ASBR to minimize external network advertisements into the
OSPF AS
Example of determining a summary address

Write each network address in binary
For example:
192.1.1.0 = 11000000.00000001.00000001.00000000
192.1.2.0 = 11000000.00000001.00000010.00000000
192.1.3.0 = 11000000.00000001.00000011.00000000
Determine the number of matching bits in all network addresses, these become the
network mask. In the example below, the matching bits are enclosed the box:
11000000.00000001.000000 01.00000000
11000000.00000001.000000 10.00000000
11000000.00000001.000000 11.00000000
Matching bits = 22
Document the summarized address by taking the matching bits, setting the remaining
bits to zero and adding the mask determined in the previous step
For example:
11000000.00000001.00000000.00000000 + mask = 192.1.0.0/22
Revision 0919 10 - 27
ICX 200 OSPF & VRF
Summarizing External Routes Scenario
• Non-summarized routes consume database resources
Also fills the

route table OSPF BGP
Area 3 ASBR
e1 e1 e3 e3 e7
1.3.0.2/24 1.3.0.1/24 1.2.0.2/24 1.2.0.1/24
Seattle Portland Vancouver
Multinetted e7
Mask=24
1.1.0.1
1.1.1.1
1.1.2.1
1.1.3.1
1.1.4.1
1.1.5.1
1.1.6.1
1.1.7.1
Problem: Non-summarized routes abuse database resources; excessive LSAs

The above graphic shows the external LSAs recorded in Seattle’s database. These LSAs
are from outside the OSPF autonomous system.
An ASBR can be configured to advertise one external route as an aggregate for all
redistributed routes that are covered by a specified address range.
When you configure a summary address range, the range takes effect immediately.
All the imported routes are summarized according to the configured summary
address range. Imported routes that have already been advertised and that fall within
the range are flushed out of the autonomous system and a single route
corresponding to the range is advertised.
If a route that falls within a configured summary address range is imported by the
device, no action is taken if the device has already advertised the aggregate route;
otherwise, the device advertises the aggregate route. If an imported route that falls
within a configured summary address range is removed by the device, no action is
taken if there are other imported routes that fall within the same summary address
range; otherwise, the aggregate route is flushed.
You can configure up to 32 summary address ranges.
Revision 0919 10 - 28
ICX 200 OSPF & VRF
Summarizing External Routes
• Summarize the external networks at the ASBR
OSPF BGP
Area 3 ASBR
e1 e1 e3 e3 e7
1.3.0.2/24 1.3.0.1/24 1.2.0.2/24 1.2.0.1/24
Multinetted e7
Mask=24
1.1.0.1
1.1.1.1
1.1.2.1
1.1.3.1
1.1.4.1
1.1.5.1
1.1.6.1
1.1.7.1
Matching Bits Summary Address/
= 21 Summary Mask = 1.1.0.0/21
The summary-address command can only be used to summarize external OSPF

routes on the ASBR; this only applies to the ASBR. It has no affect when configured
anywhere else.
To configure a summary address on an ASBR, enter commands such as the following:
Router(config-ospf-router)# summary-address 1.1.0.0
255.255.248.0
The command in this example configures summary address 1.1.0.0/21, which

includes addresses 1.1.1.0, 1.1.2.0, 1.1.3.0, and so on. For all of these networks, only
the address 1.1.0.0 is advertised in external LSAs.
Syntax: summary-address A.B.C.D E.F.G.H
The A.B.C.D parameter specifies the network address.
The E.F.G.H parameter specifies the network mask.
Note: In the graphic above CIDR notation is used to define the network and subnet
mask in the summary-address command. This notation is permitted on Ruckus ICX
routers.
Revision 0919 10 - 29
ICX 200 OSPF & VRF
Result of Summarizing External Routes
• Summarized external routes reduced the number of entries in the LSDB
OSPF BGP
Area 3 ASBR
e1 e1 e3 e3 e7
1.3.0.2/24 1.3.0.1/24 1.2.0.2/24 1.2.0.1/24
Seattle# show ip ospf database external Multinetted e7
Type-5 AS External Link States Mask=24
Index Age LS ID Router Netmask Metric Flag Fwd Address SyncState
1 209 1.2.0.0 1.2.0.2 ffffff00 8000000a 0000 10.3.3.1 Done
1.1.0.1
2 209 1.1.0.0 1.2.0.2 fffff800 8000000a 0000 10.3.3.1 Done 1.1.1.1
1.1.2.1
Seattle# show ip route
1.1.3.1
Type Codes - B:BGP D:Connected O:OSPF R:RIP S:Static; Cost - Dist/Metric 1.1.4.1
BGP Codes - i:iBGP e:eBGP 1.1.5.1
1.1.6.1
1 1.1.0.0/21 1.3.0.1 e 1/1/1 10/2 O 1h31m 1.1.7.1
3 1.2.0.0/24 1.3.0.1 e 1/1/1 10/2 O 1h31m
4 1.3.0.0/24 DIRECT e 1/1/1 0/0 D 1h31m
The summarized external routes reduced the number of entries in the OSPF database
and the IP routing table.
The above graphic displays the OSPF external LSDB and IP routing table after the
summarization command has been executed on the ASBR, Portland. When looking at
the external LSAs in Portland’s database, the number of LSAs in the external LSDB has
dropped from eight to two. The number of routes in the IP routing table has dropped
from nine to three.
Enabling summarization on the ASBR does not summarize the routes in the ASBRs
route table. It only impacts advertised routes from the ASBR. They still appear as
individual routes in the ASBRs IP route table, but they are summarized in the
neighbor’s IP route table.
Revision 0919 10 - 30
ICX 200 OSPF & VRF
Summarizing Inter-area Routes Scenario
• Inter-area routes are overloading the LSDB
Area 2 Area 0
ABR ASBR BGP Router
e7 e2 e2 e1 e1 e3 e3
1.4.0.2/24 1.4.0.1/24 1.3.0.2/24 1.3.0.1/24 1.2.0.2/24 1.2.0.1/24
Multinetted e7
Mask=24
1.4.1.1
1.4.2.1
1.4.3.1
1.4.4.1
1.4.5.1
1.4.6.1
1.4.7.1
Problem: Inter-area routes overloading database

In the graphic above, the report only lists the internal link-states in Portland’s
database that originated from Salt Lake. There are three other LSAs that are not
advertised. Below is Portland’s routing table, minus the RIP routes received from
Vancouver.
Portland(config)# show ip route
Start index: 1 D:Connected R:RIP S:Static O:OSPF *:Candidate
default
Destination NetMask Gateway Port Cost Type
1 1.1.0.0 255.255.248.0 0.0.0.0 drop 0 O
:
9 1.2.0.0 255.255.255.0 0.0.0.0 3 1 D
10 1.3.0.0 255.255.255.0 0.0.0.0 1 1 D
11 1.4.0.0 255.255.255.0 1.3.0.2 1 2 O
12 1.4.1.0 255.255.255.0 1.3.0.2 1 10 O
13 1.4.2.0 255.255.255.0 1.3.0.2 1 10 O
14 1.4.3.0 255.255.255.0 1.3.0.2 1 10 O
15 1.4.4.0 255.255.255.0 1.3.0.2 1 10 O
16 1.4.5.0 255.255.255.0 1.3.0.2 1 10 O
17 1.4.6.0 255.255.255.0 1.3.0.2 1 10 O
18 1.4.7.0 255.255.255.0 1.3.0.2 1 10 O
Revision 0919 10 - 31
ICX 200 OSPF & VRF
Summarizing Inter-area Routes (cont.)
• Summarize the inter-area networks at the ABR
Area 2 Area 0
ABR ASBR BGP Router
e7 e2 e2 e1 e1 e3 e3
1.4.0.2/24 1.4.0.1/24 1.3.0.2/24 1.3.0.1/24 1.2.0.2/24 1.2.0.1/24
Multinetted e7
Mask=24
1.4.1.1
1.4.2.1
1.4.3.1
1.4.4.1
1.4.5.1
1.4.6.1
1.4.7.1
The area range command can only be used to summarize native OSPF routes at ABRs.
The ABR creates an aggregate value based on the address range. The aggregate value
becomes the address that the ABR advertises instead of advertising the individual
addresses represented by the aggregate. Only this aggregate or summary address is
advertised into other areas instead of all the individual addresses that fall in the
configured range. Area range configuration can considerably reduce the number of
Type 3 summary LSAs advertised by a device. You have the option of adding the cost
to the summarized route. If you do not specify a value, the cost value is the default
range metric calculation for the generated summary LSA cost.
You can assign up to 32 ranges in an OSPF area.
This feature only applies to the ABR, when configured anywhere else it has no affect.
Revision 0919 10 - 32
ICX 200 OSPF & VRF
OSPF Show Commands
Revision 0919 10 - 33
ICX 200 OSPF & VRF
OSPF Show Commands
OSPFv2 Command OSPFv3 Command Displays

show ip route show ipv6 route All learned routes
show ip ospf route show ipv6 ospf route Only routes learned by OSPF
show ip ospf database show ipv6 ospf database Link state database
show ip ospf area show ipv6 ospf area OSPF area information
show ip ospf neighbor show ipv6 ospf neighbor Neighbor information
show ip ospf interface show ipv6 ospf interface Area ID and adjacency info
show ip ospf config show ipv6 ospf config General OSPF configuration information
Footnote 1: OSPFv3 show commands are also available as you see here using ipv6
within the command. Example: show ipv6 route
show ip route – displays routes, use show ip ospf route to display only OSPF routes
show ip ospf route – route tables can be extremely long; this command allows you to
see only OSPF routes; especially important if doing redistribution of other routing
protocols, like BGP
show ip ospf database – displays link state database; used for troubleshooting
corrupted databases, a possible problem with large OSPF implementations
show ip ospf area – displays type of area (Normal, Stub, NSSA). NSSA is Not So
Stubby Area. Used when troubleshooting neighbor problems when converting stub
area to normal or vice versa. All routers in an area must be configured for the same
area type.
show ip ospf neighbor – common command used when troubleshooting OSPF
neighbor problems. Tells you the current neighbor state.
show ip ospf interface - displays area ID and adjacency information on a per interface
basis. Gives more detail than show ip ospf neighbor.
show ip ospf border-routers - shows router’s that are ABRs or ASBRs.
show ip ospf config - displays only the OSPF part of your startup-config.
Revision 0919 10 - 34
ICX 200 OSPF & VRF
Display OSPF Interface Information
Router_B# show ip ospf interface

e 1/1/1 admin up, oper up, ospf enabled, state up
IP Address 172.16.1.2, Area 0
State DR, Pri 1, Cost 1, Options 2, Type broadcast Events 13
Timers(sec): Transit 1, Retrans 5, Hello 10, Dead 40
DR: Router ID 172.16.1.2 Interface Address 172.16.1.2
BDR: Router ID 172.16.4.9 Interface Address 172.16.1.1
Packets Received Packets Sent
Hello 83769 83755
Database 3 3
LSA Req 1 0
LSA Upd 438 439
LSA Ack 438 438
Neighbor Count = 1, Adjacent Neighbor Count = 1
Neighbor: 172.16.1.1 [id 172.16.4.9] (BDR)
In-Use Authentication: None, Key: None, Key-Id: None
The above slide is a report from show ip ospf interface executed on Router_B. This is
shown for the 172.16.1.2 interface. It states what area the interface is in and its title;
Designated Router (DR) or Backup Designated Router (BDR). It also states the router
ID for the DR and BDR with their corresponding interface addresses. Note that the
router ID for the DR and the interface addresses are the same. However, for the BDR,
the router ID and the interface address are different. The address 172.16.1.2 is the
lowest numerical address on any of Router_B interfaces, so it becomes Router_B’s
router ID. Router_A, on the other hand, has a loopback interface defined, so the
lowest numbered loopback is chosen to be the router ID for Router_A. By lowest
numbered, we mean that if both Lo1 and Lo2 were configured, Lo1 would be chosen
as the router ID.
During the election process, the router with the highest router ID wins. Based on this
report it would seem that Router_A would win the election with a high ID. However,
if Router_A is power cycled, the router ID will change and a new election will take
place making Router_A the new DR. Therefore during the OSPF election, Router_A
lost with a lower router ID of 172.16.1.1. This did not change with configuration of
the loopback on Router_A. However, if Router_B is power cycled, a new election
occurs, and Router_A will take over as DR.
OSPFv3 Example:
Router_B# show ipv6 ospf interface
Syntax: show ipv6 ospf interface [ brief ] [ ethernet unit/slot/port ] [ loopback
number ] [ tunnel number ] [ ve vlan_id ]
Revision 0919 10 - 35
ICX 200 OSPF & VRF
Display OSPF Interface Information
• Use the show ip ospf interface brief to quickly see status of OSPF connections
Router_B# show ip ospf interface brief
Number of Interfaces is 4
Interface Area IP Addr/Mask Cost State Nbrs(F/C)

e 1/1/1 0 10.168.1.1/24 1 DR 1/1
e 1/1/17 0 10.1.1.1/24 1 BDR 1/1
e 1/1/8 0 192.123.2.1/24 1 BDR 1/1
e 2/1/22 0 192.123.22.1/24 1 BDR 1/1
e 3/1/24 0 192.123.44.1/24 1 BDR 1/1
Router B
More details about OSPF interfaces can be gathered from the show ip ospf interface
command, without the brief option. These details are useful if you inspecting a
particular OSPF interface. In most cases the brief option is used to provide a quick
view of all OSPF interfaces.
OSPFv3 Example:
Router_B# show ipv6 ospf interface
Syntax: show ipv6 ospf interface [ brief ] [ ethernet unit/slot/port ] [ loopback
number ] [ tunnel number ] [ ve vlan_id ]
Revision 0919 10 - 36
ICX 200 OSPF & VRF
Examining OSPF Link-State Database
• LSAs populating the OSPF Database can be viewed using the following command:
Router# show ip ospf database
• Specific LSA types can also be displayed

– Example:
Router# show ip ospf database external-link-state
Index Aging LS ID Router Netmask Metric Flag
1 83 192.168.60.80 10.3.3.1 fffffff8 8000000a b500 0.0.0.0
2 83 192.168.60.72 10.3.3.1 fffffff8 8000000a b500 0.0.0.0
3 83 192.168.60.64 10.3.3.1 fffffff8 8000000a b500 0.0.0.0
4 108 192.168.90.0 10.3.3.1 ffffff80 8000000a b500 0.0.0.0
5 83 192.168.60.120 10.3.3.1 fffffff8 8000000a b500 0.0.0.0
6 83 192.168.60.112 10.3.3.1 fffffff8 8000000a b500 0.0.0.0
7 83 192.168.60.104 10.3.3.1 fffffff8 8000000a b500 0.0.0.0
8 83 192.168.60.96 10.3.3.1 fffffff8 8000000a b500 0.0.0.0
The OSPFv2 show ip ospf database command is very robust and provides several
options to look at specific information related to the OSPF link-state database. These
include:
• database-summary – Displays how many link state advertisements (LSAs) of
each type exist for each area, as well as total number of LSAs.
• external-link-state – Displays information by external link state, i.e.
redistributed routes.
• link-state – Displays networks originated within the OSPF domain.
• grace-link-state – Displays LSAs generated as part of the graceful restart
process.
The show ipv6 ospf database command displays information related to the OSPFv3
link-state database.
• extensive - Displays detailed lists of LSA information.
• as-external - Displays information about external LSAs.
• inter-prefix - Displays information about inter area prefix LSAs.
• inter-router - Displays information about inter area router LSAs.
• intra-prefix - Displays information about intra area prefix LSAs.
• link decimal - Displays information about the link LSAs.
• network - Displays information about network LSAs.
• router - Displays information about router LSAs.
• area - Displays LSAs by scope within a specified area.
• as - Displays autonomous system (AS) LSAs by scope.
• summary - Displays LSA summary information.
Revision 0919 10 - 37
ICX 200 OSPF & VRF
Display OSPF Neighbor Information
• To display useful information about an OSPF neighbor, use the show ip ospf neighbor
command
• Displays neighbor specific information including:
– OSPF priority
– Adjacency state and role
– IP address OSPF messages originate from
– Router-ID
– Number of state change events
The above slide is a report from show ip ospf neighbor executed on Router B. The
following are the descriptions of the fields:
• Port: The port through which the Layer 3 Switch is connected to the neighbor.
• Address: The IP address of this Layer 3 Switch’s interface with the neighbor.
• Pri: The OSPF priority of the neighbor. The priority is used during election of the
Designated Router (DR) and Backup Designated Router (BDR).
• State: The state of the conversation between the Layer 3 Switch and the
neighbor, and the title of the neighbor. The state field can have one of the
following values: Down, Init, 2-way, ExStart, Exchange, Loading, Full. The
neighbors title field can be: DR, BDR or other.
• Neigh Address: The IP address of the neighbors connected interface.
• Neigh ID: The neighbors router ID
• EV: The number of times a neighbor’s state has changed.
Syntax: show ip ospf neighbor [ extensive | num | router-id A.B.C.D ]
OSPFv3 Example:
Router_B# show ipv6 ospf neighbor
Total number of neighbors in all states: 1
Number of neighbors in state Full : 1
RouterID Pri State DR BDR Interface [State] Bfd-State
161.79.5.1 1 Full 161.79.8.1 161.79.5.1 e 1/1/1 [DR] NA
Syntax: show ipv6 ospf neighbor [ detail | router-id A.B.C.D ]
Revision 0919 10 - 38
ICX 200 OSPF & VRF
Debug of Neighbor Adjacency Process

SaltLake# debug ip ospf packet detail
OSPF: send to:224.0.0.5 Intf:e 3
Hello L:48 Auth:0 ID:10.2.2.1 DR:0.0.0.0 BDR:0.0.0.0
Init State
OSPF: recv from:192.168.10.1 to 224.0.0.5 Intf:e 3
Hello L:48 Auth:0 ID:10.2.0.1 DR:192.168.10.2 BDR:192.168.10.1
Two-way
DD L:32 Auth:0 ID:10.2.2.1 0207 seq=000005d2, Cnt:0
Exchange Start
DD L:192 Auth:0 ID:10.2.0.1 0200 seq=000005d2, Cnt:3
Exchange
1 Router(1), LSID:10.2.0.1 Adv:10.2.0.1, age=41, len=36, seq=80000003
2 Summary(3), LSID:10.0.0.1 Adv:10.2.0.1, age=36, len=28, seq=80000001
192.168.10.2
Salt Lake San Diego
LS-Req L:120 Auth:0 ID:10.2.2.1Cnt:3
Loading Area 3 192.168.10.1 Area 0
1 Router(1), LSID:10.2.0.1 Adv:10.2.0.1
2 Summary(3), LSID:10.0.0.1 Adv:10.2.0.1
3 Summary(3), LSID:10.0.3.1 Adv:10.2.0.1
LS-Upd L:260 Auth:0 ID:10.2.0.1 Cnt:8
1 Router(1) Age:42 ID:10.2.0.1 Adv:10.2.0.1 seq:80000003 len:36 Opt:0100 Lk#: 1
2 Summary(3) Age:37 ID:10.0.0.1 Adv:10.2.0.1 seq:80000001 len:28
3 Summary(3) Age:37 ID:10.0.3.1 Adv:10.2.0.1 seq:80000001 len:28
LS-Ack L:184 Auth:0 ID:10.2.2.1 Full
1 Router(1), LSID:10.2.0.1 Adv:10.2.0.1, age=42, len=36, seq=80000003
In the above slide, debug ip ospf packet is enabled on Salt Lake. The link between Salt
Lake and San Diego is down. When the link is connected, the subsequent adjacency
states are revealed by the packets that are transferred.
Note that contents of the packet types are indented under the packet title.
In the “Exchange” block, San Diego has advertised its Database contents. Note that
Salt Lake will recognize its own LSA and LSAs that are from Area 0.
The states that a router passes through during the adjacency process: Init, 2-way,
ExStart (Exchange Start), Exchange, Loading, and Full can be viewed with the debug ip
ospf adj command.
Revision 0919 10 - 39
ICX 200 OSPF & VRF
OSPF Debug Commands
• Aids in troubleshooting many aspects of the OSPF protocol

Router# debug ip ospf ?
adj OSPF adjacency events
debug-detail detailed debug, with matched ip/mask
display-detail detailed display
error display possible error in run time
events OSPF events
flood OSPF flooding
graceful-restart OSPF grace-restart
ip-route IP route related
log-debug-message Enable OSPF debug message logging
log-empty-lsa Enable OSPF empty LSA logging
lsa LS Adv or database
ospf-route OSPF route related
packet OSPF packets
retransmission OSPF retransmission events
show show debug info
spf OSPF spf trace
<Output Truncated>
• adj – Reports OSPF neighbor-states leading to forming and tearing down a neighbor
adjacency. Example neighbor states are: Down, Initializing, One-way to 2-way, Exchange-
start, Loading, and Full. The sending and receiving of hellos causing the transitions through
these states are reported. The transitions back through these states, from Full to Down
are also reported due to an inactivity timer. This state information is limited to links
directly connected to the reporting router.
• events – Reports when a DR/BDR election is occurring, what is the final BDR and DR for a
LAN segment, and reports post election Database Exchanges. This router title information
is limited to links directly connected to the reporting router.
• flood – Reports OSPF flooding code paths, and the messages will also indicate the flooding
destinations (such as the area or the whole AS). It will report instances when OSPF is
receiving self-originated LSAs as well. Note: enabling this command will also copy debug
messages to the log buffer.
• log-debug-message – Enables/disable the logging (in "show log") of OSPF log messages. It
is used when there is repetitive OSPF log messages constantly filling up the log buffer. Use
this command to disable OSPF from logging log messages, thus allow other log messages
to stay in log buffer longer.
• log-empty-lsa – Will enable/disable logging of empty-lsa messages. This log message
quickly fills the log buffer, potentially overwriting more relevant log entries.
• lsa-generation – Reports when OSPF receives and processes LSAs and indicates if/why the
LSA is bad. Also tracks the receiving of LSA ACKs and when OSPF is installing a new LSA in
the database.
• packet – Provides a continuously decoded dump of all messages sent and received
by OSPF. Use with caution, will cause extensive screen activity.
• retransmission – Reports when OSPF adds or removes LSAs into the retransmission list.
• spf -short – This command enables displaying of a message on console when SPF
calculation is being invoked.
Revision 0919 10 - 40
ICX 200 OSPF & VRF
Virtual Routing
and Forwarding (VRF)
Revision 0919 10 - 41
ICX 200 OSPF & VRF
Multi-VRF
• Virtual Routing and Forwarding

(VRF) allows multiple, independent
routing and forwarding tables on
the same router
– Sometimes referred to as VRF-Lite
– Allows multiple instances of routing

protocols (BGP/OSPF) to exchange of
route information
– Overlapping L3 addresses can be

maintained between VRF instances
Virtual Routing and Forwarding (VRF) allows routers to maintain multiple routing
tables and forwarding tables on the same router. A Multi-VRF router can run multiple
instances of routing protocols with a neighboring router with overlapping address
spaces configured on different VRF instances.
Central to VRF-Lite is the ability to maintain multiple VRF tables on the same Provider
Edge (PE) Router. VRF-Lite uses multiple instances of a routing protocol such as OSPF
or BGP to exchange route information for a VPN among peer PE routers. The VRFLite
capable PE router maps an input customer interface to a unique VPN instance. The
router maintains a different VRF table for each VPN instance on that PE router.
Multiple input interfaces may also be associated with the same VRF on the router, if
they connect to sites belonging to the same VPN. This input interface can be a
physical interface or a virtual Ethernet interface on a port.
In Multi-VRF deployments:
• Two VRF-capable routers must be directly connected at Layer 3, deploying BGP,
OSPF, or static routes.
• Each VRF maintains unique routing and forwarding tables.
• Each VRF can be assigned one or more Layer 3 interfaces on a router to be part
of the VRF.
• Each VRF can be configured with IPv4 address family, IPv6 unicast address
family, or both.
• A packet’s VRF instance is determined based on the VRF index of the interface
on which the packet is received.
• Separate routing protocol instances are required for each VRF instance.
• Overlapping address spaces can be configured on different VRF instances.
Revision 0919 10 - 42
ICX 200 OSPF & VRF
VRF Configuration Limitations and Prerequisites
• Multi-VRF is not supported on the ICX 7150
• On the ICX 7250:

– By default, all memory reserved for IP routing tables is allocated to the default VRF
– To store routes for a non-default VRF, the ICX system-max values must be modified
– To reassign resources to non-default VRF:

• Verify resources assigned to ip-route-default-vrf (ip6-route-default-vrf for IPv6 implementations) with the show
default values command
• Reduce those resources to accommodate the needs of the non-default VRF/s
• Assign resources to the ip-route-vrf (ip6-route-vrf for IPv6 implementations)
• Save the configuration and reload the device
The default ICX 7250 configuration does not allow space for VRF routing tables. As a
result, you must modify VRF-related system-max values before configuring a VRF
instance. The following table lists commands that configure system-max values at the
global level.
Revision 0919 10 - 43
ICX 200 OSPF & VRF
Configuring Multi-VRF
• Define a VRF routing instance

• Assign a Route Distinguisher to a VRF
To simplify management,
• Enable routing rules and protocols to the VRF instance the VRF name and Route
Distinguisher should match
• Assign the VRF routing instance to an interface on connecting devices
ICXPE1(config)# vrf tenent1 Defines an OSPF instance

ICXPE1(config-vrf-tenent1)# rd 20:20 to run within the VRF
ICXPE1(config-vrf-tenent1)# address-family ipv4 Does not impact OSPF
instances in other VRFs
ICXPE1(config-vrf-tenent1-ipv4)# exit
ICXPE1(config)# router ospf vrf tenent1
Defines the interface
ICXPE1(config-ospf-router-vrf-tenent1)# area 0 to operate within the
ICXPE1(config-ospf-router-vrf-tenent1)# exit specified VRF
ICXPE1(config)# interface ethernet 1/1/1
ICXPE1(config-if-e1000-1/1/1)# vrf forwarding tenent1
ICXPE1(config-if-e1000-1/1/1)# ip address 192.0.2.1/30
ICXPE1(config-if-e1000-1/1/1)# ip ospf area 0
A device can be configured with more than one VRF instance. You should define each
VRF instance before assigning the VRF to a Layer 3 interface. The range of the
instance name is from 1 through 255 alphanumeric characters. Each VRF instance is
identified by a unique Route Distinguisher (RD), which is prepended to the address
being advertised. Because the RD provides overlapping client address space with a
unique identifier, the same IP address can be used for different VRFs without conflict.
The RD can be an AS number, followed by a colon (:) and a unique arbitrary number
as shown below. Alternatively, it can be a local IP address followed by a colon (:) and
a unique arbitrary number, as in "1.1.1.1:100."
Use the address-family command in VRF configuration mode to specify an IPv4 or
IPv6 address family. For a specific address family you can also configure static route,
static ARP, IGMP, and multicast for IPv4, and static route, IPv6 neighbor, and multicast
for IPv6.
ICXPE2 Configuration Example:
ICXPE2(config)# vrf red
ICXPE2(config-vrf-tenent1)# rd 20:20
ICXPE2(config-vrf-tenent1)# address-family ipv4
ICXPE2(config-vrf-tenent1-ipv4)# exit
ICXPE2(config)# router ospf vrf tenent1
ICXPE2(config-ospf-router-vrf-tenent1)# area 0
ICXPE2(config-ospf-router-vrf-tenent1)# exit
ICXPE2(config)# interface ethernet 1/1/3
ICXPE2(config-if-e1000-1/1/1)# vrf forwarding tenent1
ICXPE2(config-if-e1000-1/1/1)# ip address 192.0.2.2/30
ICXPE2(config-if-e1000-1/1/1)# ip ospf area 0
Revision 0919 10 - 44
ICX 200 OSPF & VRF
Multi-VRF Configuration Example1
• Both Green and Red VRFs maintain their own routing table in each PE router
– Each VRF also maintains their own OSPF routing instance
CE1 CE3
OSPF Area 0
Routes Routes
100.1.2.0/24 100.2.2.0/24
100.1.3.0/24 100.3.1.0/30 for green 100.2.3.0/24
VRF (vlan 10)
.2 100.3.1.0/30 for red .2
100.1.1.0/30 VRF (vlan 20) 100.2.1.0/30
OSPF Area 3 .1 e2 PE1 PE2 e2 .1 OSPF Area 2
e1 e1
CE2 CE4
.1 .2
Routes .1 e3 e3 .1 Routes
100.1.2.0/24 100.1.1.0/30 100.2.1.0/30 100.2.2.0/24
100.1.3.0/24 This link carries traffic 100.2.3.0/24
.2 from both green and .2
red VRFs (VPN)
Footnote 1: Multi-VRF uses the input interface to uniquely identify the associated
VPN, which is why the two PE routers should be directly connected at Layer 3
The 2 PEs routers have to be routers that are capable of supporting VRF routing
(either with or without MPLS support). They connect all four CE routers together with
a single link between the two of them. Note that this single link between the 2 PEs
could also be replaced by a layer-2 switched network if direct physical connection
between the PEs is not possible. The only requirement for the connections is that the
2 PEs have to be “directly connected” at layer 3.
PE1 configuration:
In this configuration, VLANs 10 and 20 are created as a link on a tagged port (e1)
between PE1 and PE2. Two VRFs (“RED” and “GREEN”) are then defined with each
having a unique Route Distinguisher (RD). VRF “Green” is assigned an RD value of
10:10, and VRF “Red” is assigned an RD value of 20:20. Because OSPF is the only
routing protocol used in this set-up, multiple OSPF areas are used. Area 0 is
configured between the two PEs. Area 1 is configured PE1 and CE’s 1 and 2. Area 0 is
configured between the two PEs. Area 2 is configured PE2 and CE’s 3 and 4. The
virtual Interfaces (ve10 and ve20) are configured with the same IP address
(10.3.1.1/30) and for VRF forwarding in the appropriate VRF (Green or Red). Both
VRFs on both PEs have OSPF adjacency in Area 0.
Revision 0919 10 - 45
ICX 200 OSPF & VRF
PE1 Configuration Example
PE1(config)# vlan 10
PE1(config-vlan-10)# tagged e 1/1/1
PE1(config-vlan-10)# router-interface ve 10
PE1(config-vlan-10)# vlan 20
PE1(config-vlan-20)# exit-vrf
PE1(config)# vrf green
PE1(config-vrf-green) rd 10:10
PE1(config-vrf-green) address-family ipv4
PE1(config-vrf-green) vrf red
PE1(config-vrf-red) rd 20:20
PE1(config-vrf-red) address-family ipv4
PE1(config-vrf-red) exit-vrf
PE1(config)# router ospf vrf green
PE1(config-ospf-router-vrf-green)# area 0
PE1(config-ospf-router-vrf-green)# exit
PE1(config)# router ospf vrf red
PE1(config-ospf-router-vrf-red)# area 0
PE1(config-ospf-router-vrf-red)# exit
PE1(config)# interface ethernet 1/1/2
PE1(config-if-e1000-1/1/2)# vrf forwarding green
PE1(config-if-e1000-1/1/2)# ip ospf area 1
PE1(config-if-e1000-1/1/2)# ip address 100.1.1.1/30
PE1(config-if-e1000-1/1/2)# interface ethernet 1/1/3
PE1(config-if-e1000-1/1/3)# vrf forwarding red
PE1(config-if-e1000-1/1/3)# exit
PE1(config)# interface ve 10
PE1(config-vif-10)# vrf forwarding green
PE1(config-vif-10)# ip ospf area 0
PE1(config-vif-10)# ip address 100.3.1.1/30
PE1(config-vif-10)# Interface ve 20
PE1(config-vif-20)# vrf forwarding red
Revision 0919 10 - 46
ICX 200 OSPF & VRF
PE2 Configuration Example
PE2(config)# vlan 10
PE2(config-vlan-10)# vlan 20
PE2(config-vlan-20)# exit-vrf
PE2(config)# vrf green
PE2(config-vrf-green) rd 10:10
PE2(config-vrf-green) address-family ipv4
PE2(config-vrf-green) vrf red
PE2(config-vrf-red) rd 20:20
PE2(config-vrf-red) address-family ipv4
PE2(config-vrf-red) exit-vrf
PE2(config)# router ospf vrf green
PE2(config-ospf-router-vrf-green)# exit
PE2(config)# router ospf vrf red
PE2(config-ospf-router-vrf-red)# exit
PE2(config)# interface ethernet 1/1/2
PE2(config-if-e1000-1/1/2)# vrf forwarding green
PE2(config-if-e1000-1/1/2)# interface ethernet 1/1/3
PE2(config-if-e1000-1/1/3)# vrf forwarding red
PE2(config-if-e1000-1/1/3)# exit
PE2(config)# interface ve 10
PE2(config-vif-10)# vrf forwarding green
PE2(config-vif-10)# Interface ve 20
PE2(config-vif-20)# vrf forwarding red
Revision 0919 10 - 47
ICX 200 OSPF & VRF
Multi-VRF Show Commands

PE1# show ip route vrf red
1 100.1.1.0/30 DIRECT e 1/1/3 0/0 D 5m3s
3 100.1.2.0/24 100.1.1.2 e 1/1/3 110/2 O 5m3s
4 100.1.3.0/24 100.1.1.2 e 1/1/3 110/2 O 5m3s
5 100.2.1.0/30 100.3.1.2 e 1/1/1 110/2 O 5m3s
6 100.2.2.0/24 100.3.1.2 e 1/1/1 110/3 O 5m3s
7 100.2.3.0/24 100.3.1.2 e 1/1/1 110/3 O 5m3s
8 100.3.1.0/30 DIRECT e 1/1/1 0/0 D 5m3s
PE1#
Revision 0919 10 - 48
ICX 200 OSPF & VRF
Multi-VRF Show Commands (cont.)
• Display all VRFs

PE1# show vrf
Total number of VRFs configured: 2
Status Codes - A:active, D:pending deletion, I:inactive
Name Default RD vrf|v4|v6 V4Routes V6Routes Interfaces
green 10:10 A | A| I 8 0 eth1/1/1 eth1/1/2
red 20:20 A | A| I 8 0 eth1/1/1 eth1/1/3
Total number of IPv4 unicast route for all non-default VRF is 16
Total number of IPv6 unicast route for all non-default VRF is 0
• Display specific VRF

PE1# show vrf red
VRF red, default RD 20:20, Table ID 2
IP Router-Id: 10.1.1.1
Interfaces: e1/1/1 e1/1/3
Address Family IPv4
Max Routes: 5500
Number of Unicast Routes: 8
Revision 0919 10 - 49
ICX 200 OSPF & VRF
Management VRF
Revision 0919 10 - 50
ICX 200 OSPF & VRF
Management VRF Overview
• Isolates management traffic from the network data traffic

• Management traffic is only sent on OOB management port and any interfaces with vrf
forwarding for management VRF
• The management VRF is supported by the following management applications:
– SNMP server
– SNMP trap generator
– Telnet server
– SSH client
– SSH server
– Telnet client
– RADIUS client
– TACACS+ client
– TFTP
– SCP
– Syslog
A management VRF is used to provide secure management access to the device by

sending inbound and outbound management traffic through the VRF specified as a
global management VRF and through the out-of-band management port.
By default, the inbound traffic is unaware of VRF and allows incoming packets from
any VRF, including the default VRF. Outbound traffic is sent only through the default
VRF. The default VRF consists of an out-of-band management port and all the LP ports
that do not belong to any other VRFs.
Any VRF, except the default VRF, can be configured as a management VRF. When a
management VRF is configured, the management traffic is allowed through the ports
belonging to the specified VRF and the out-of-band management port. The
management traffic through the ports belonging to the other VRFs and the default
VRF are dropped, and the rejection statistics are incremented.
The management VRF is supported by the following management applications:
• SNMP server
• SNMP trap generator
• Telnet server
• SSH server
• Telnet client
• RADIUS client
• TACACS+ client
• TFTP
• SCP
• Syslog
Revision 0919 10 - 51
ICX 200 OSPF & VRF
Configuring Management VRF for OOB Interface
• Create non-default VRF

ICX(config)# vrf mgmt-vrf
ICX(config-vrf-mgmt-vrf)# rd 1:1
ICX(config-vrf-mgmt-vrf)# address-family ipv4
ICX(config-vrf-mgmt-vrf-ipv4)# exit
• Define it as the management VRF

ICX(config)# management-vrf mgmt-vrf
• Enable VRF forwarding on OOB Management interface

ICX(config)# interface management 1
ICX(config-if-mgmt-1)# vrf forwarding mgmt-vrf
Warning: All IPv4 and IPv6 addresses (including link-local) on this
interface have been removed
ICX(config-if-mgmt-1)# ip address 192.168.10.22/24
Revision 0919 10 - 52
ICX 200 OSPF & VRF
Configuring Management VRF for VLAN Interface
• Create non-default VRF

• Define it as the management VRF
• Configure VLAN for management use
device(config)# vlan 10 name MGMT

device(config-vlan-10)# tag e 1/1/12
device(config-vlan-10)# router-interface ve 10
device(config-vlan-10)# interface ve 10
device(config-vif-10)# vrf forwarding mgmt-vrf
Warning: All IPv4 and IPv6 addresses (including link-local) on this
interface have been removed
device(config-vif-10)# ip address 10.255.10.12/24
device(config-vif-10)# exit
Revision 0919 10 - 53
ICX 200 OSPF & VRF
Module Summary
– Understand OSPF features and their benefits
– Describe how to configure OSPF on ICX devices

• OSPFv2 and v3
– Explain advanced OSPF features
– Use show and debug commands to assess and troubleshoot an OSPF network
– Describe Virtual Route Forwarding capabilities on an ICX device
Revision 0919 10 - 54
ICX 200 OSPF & VRF
End of Module 10:

OSPF and
Virtual Route Forwarding (VRF)
Revision 0919 10 - 55
ICX 200 OSPF & VRF
Revision 0919 10 - 56
ICX 200 Border Gateway Protocol
Module 11:
Border Gateway Protocol (BPG)
Module Objectives
– Understand Border Gateway Protocol (BGP) features and benefits
– Configure BGP on ICX devices
– View BGP configuration and troubleshoot
BGP Overview
• BGP is standard Exterior Gateway Protocol (EGP) used on the Internet today for inter-
domain AS routing
• RFC 4271 (obsoletes RFC 1771) – BGP4 specification

– RFC 2545 – Multi-protocol extensions for IPv6
• A path-vector routing protocol
• Two connection types of BGP:

– External BGP (EBGP)
– Internal BGP (IBGP)
• BGP peers only exchange full routing tables after peer establishment
– No periodic updates
Border Gateway Protocol version 4 (BGP4) is an exterior gateway protocol that

performs inter-autonomous system (AS) or interdomain routing. It peers to other
BGP-speaking systems over TCP to exchange network reachability and routing
information. BGP primarily performs two types of routing: inter-AS routing, and intra-
AS routing. BGP peers belonging to different autonomous systems use the inter-AS
routing, referred to as External BGP (EBGP). On the other hand, within an AS BGP can
be used to maintain a consistent view of network topology, to provide optimal
routing, or to scale the network, referred to as Internal BGP (IBGP).
BGP is a path vector protocol and implements this scheme on large scales by treating
each AS as a single point on the path to any given destination. For each route
(destination), BGP maintains the AS path and uses this to detect and prevent loops
between autonomous systems.
Devices within an AS can use different Interior Gateway Protocols (IGPs) such as RIP
and OSPF to communicate with one another. However, for devices in different
autonomous systems to communicate, they need to use an EGP. BGP4 is the standard
EGP used by Internet devices and therefore is the EGP implemented on Ruckus
devices.
BGP General Operation
• BGP messages use TCP port 179

– Connection-oriented between neighbors
– TCP ensures reliable delivery
• BGP session consists of two routers which exchange prefixes
• Prefixes are placed in BGP database, where the best path to each prefix is placed in the
BGP database
– BGP validates prefixes received for viable next hop
– If BGP peer is dropped, routes are withdrawn
• No routes are advertised by default

– A network statement or redistribution advertises a route
BGP4+
• Multiprotocol BGP (MBGP) extensions that allows the BGP protocol to distribute IPv6
routing information
• Supports all of the same features and functionality of IPv4 BGP (BGP4)
• IPv6 MBGP enhancements include:

– IPv6 unicast address family and network layer reachability information (NLRI)
– Next hop attributes that use IPv6 addresses
• Only IPv6 unicast routing supported on ICX

– IPv6 multicast routes are not supported
– No other MBGP extensions are supported
• BGP4+ is covered in the appendix at the end of this presentation
EBGP vs. IBGP
• EBGP: Connecting between different Autonomous Systems (AS)

– Peers are generally directly connected (IP TTL is set to 1)1
– Only best routes are advertised to EBGP neighbors
• IBGP: A connection within the same AS
– IBGP peers do not advertise other IBGP learned routes
• Therefore a full mesh to all IBGP peers is required2
– All feasible prefixes are advertised to IBGP peers
EBGP IBGP Mesh

AS 20
AS 10
AS 10 AS 30
Footnote 1: Multi-hop EBGP connections can be accomplished through additional

configuration.
Footnote 2: This restriction is established due to the loop detection process in BGP.
EBGP peers add their local AS number to the prefix advertisement as an as-path
attribute. If the EBGP neighbor identifies his own AS in the as-path attribute he will
drop the prefix due to loop detection. When a prefix is advertised to an IBGP peer,
the local AS numbers are not added therefore loops cannot be detected. To avoid this
a few rules that are different for IBGP peers and EBGP peers:
• Routes learned from EBGP peer will be advertised to other peers (BGP or
IBGP); however, routes learned from IBGP peer will not be advertised to other
IBGP peers.
• EBGP routes have administrative distance of 20, whereas IBGP has 200.
• Next hop remains unchanged when route is advertised to IBGP peer; however,
it is changed when it is advertised to EBGP peer by default.
Four-byte Autonomous Systems (AS4)
• Two-byte AS numbers provide a range of AS values of 0-65535

– Depletion of Autonomous System numbers issued by IANA has caused the use of AS4 AS numbers
• Four-byte AS numbers (AS4) allow backwards compatibility with two byte AS BGP speakers
– AS4 capabilities are discovered during neighbor establishment
– AS advertisements are limited to a two byte format by replacing their AS4 number with AS 23456
• Global AS4 configuration

Router(config-bgp)# capability as4 enable
– Syntax: [no] capability as4 { disable | enable }
• Overriding global AS4 capability to a neighbor

Router(config-bgp)# neighbor 10.1.1.11 capability as4 disable
– Syntax: [no] neighbor { ip-address | ipv6-address | peer-group-name } capability as4 [ disable | enable ]
Four-byte autonomous system numbers (ASNs) can be optionally configured on a

device, peer-group, or neighbor. If this is enabled, the device announces and
negotiates "AS4" capability with its neighbors.
You can configure AS4 capability to be enabled or disabled either at the BGP global
level or at the neighbor or peer-group level.
You can configure AS4 capability to be enabled for a neighbor while still keeping AS4
numbers disabled at the global level, or vice-versa. The neighbor AS4 capability
configuration takes precedence. If AS4 capability is not configured on the neighbor,
then the peer-group configuration takes effect. The global configuration is used if AS4
capability is configured neither at the neighbor nor at the peer-group level. If a device
having a 4-byte ASN tries to connect to a device that does not have AS4 support,
peering will not be established.
ASN 23456 is a reserved AS and used as the local ASN towards a non AS4 capable
device. AS path attributes are also modified if they are carrying any AS4 numbers and
a new optional transitive attribute AS4_PATH is also added to prefix advertisement.
Between two AS4 capable routers the AS_PATH attribute is modified to carry 4 byte
ASNs. When sending prefixes to non AS4 neighbors the AS_PATH message remains in
the standard format and any AS4 AS numbers that are found are replaced with the
AS_TRANS AS number of 23456. In addition it adds a new attribute AS4_PATH to the
prefix which carries both full list of both 4 and 2 byte AS path numbers.
BGP Basic Configuration Tasks
• BGP is a very robust and functional protocol
• The tasks listed here, and shown in the module, describe the basic steps for configuring
BGP connectivity and route exchange:
– Enabling BGP on the router (required)

– Setting the local AS number (required)
– Adding BGP neighbors (required)
• Adding EBGP neighbors
• Adding IBGP neighbors
– Using update-source loopback
– Specifying a network or list of networks to advertise
– Verifying configuration
BGP Configuration Scenario
• Router_A and Router_C are in different Autonomous Systems (AS)

– They will be configured as EBGP neighbors
• Router_A and Router_B are in the same AS
– They will be configured as IBGP neighbors
AS 33090
AS 22787 EBGP L1: 10.1.1.10/32 IBGP L1: 10.1.1.11/32
Router_C e1: 198.135.207.2/30 e1: 198.135.207.1/30 Router_A Router_B
• NOTE: Interface and loopback IP addresses are already configured as shown
Enable BGP and Setting Local AS Number
• BGP is disabled by default on ICX devices

AS 33090
• BGP is enabled from the CLI global configuration mode: Router_A
Router_A(config)# router bgp

BGP: Please configure 'local-as' parameter in order to run BGP4.
• Once enabled, the router’s local AS number (ASN) must be assigned

Router_A(config-bgp-router)# local-as 33090
• The same steps are required on Router_B and Router_C

– Router_B will define the same ASN (33090)
– Router_C will define a different ASN (22787)
When using CLI, you set global level parameters at the BGP CONFIG Level of the CLI.
You can reach the BGP CONFIG level by entering the router bgp CLI command.
The system will display the next step to take:
BGP: Please configure 'local-as' parameter in order to
enable BGP.
Set the router’s local AS number using the following local-as command.
Syntax: [no] local-as num
The num parameter specifies local AS number.
The local AS number identifies the AS the Ruckus BGP router is in. The AS number can
be from 1– 4,294,967,296. There is no default. AS numbers 64512 – 65535 are the
well-known private BGP AS numbers and are not advertised to the Internet
community.
Note: The Ruckus ICX complies with RFC 4893 - BGP Support for Four-octet (32-bit)
AS Number Space
These global configuration steps are the same when implementing either BGP4 (IPv4)
or BGP4+ (IPv6).
Revision 0919 11 - 10
Adding BGP EBGP Neighbors
AS 22787 AS 33090
e1: e1:
198.135.207.2/30 198.135.207.1/30
Router C Router A
• Neighbors are added manually and are automatically identified as IBGP or EBGP peers
– Determined by comparing local-as to remote-as
• Match = IBGP
• No match = EBGP
• Example of adding EBGP neighbor for Router A and Router C:

Router_A(config-bgp-router)# neighbor 198.135.207.2 remote-as 22787
Router_C(config-bgp-router)# neighbor 198.135.207.1 remote-as 33090
– Syntax: neighbor { ip-address | ipv6-address | peer-group-name } remote-as num
• As soon as a BGP neighbor is added, the router tries to establish a BGP session
The BGP protocol does not contain a peer discovery process. Therefore, for each of
the router BGP neighbors (peers), you must indicate the neighbor IP address and the
AS each neighbor is in. Neighbors that are in different ASs communicate using EBGP.
Neighbors within the same AS communicate using IBGP.
When BGP is enabled on an ICX Layer 3 Switch, you do not need to reset the system.
The protocol is activated as soon as you enable it. Moreover, the router begins a BGP
session with a BGP neighbor as soon as you add the neighbor.
When adding a BGP neighbor, the configured neighbor IP address must be valid and
reachable.
Revision 0919 11 - 11
Adding BGP IBGP Neighbors
• Example of adding an IBGP neighbor:
Router_A(config-bgp-router)# neighbor 10.1.1.11 remote-as 33090

Same
ASN
Router_B(config-bgp-router)# neighbor 10.1.1.10 remote-as 33090
AS 33090
L1: 10.1.1.10/32 IBGP L1: 10.1.1.11/32
Router A Router B
• Important: The neighbor IP addresses must be reachable

To summarize, IBGP is used to carry Internet prefixes across a Service Provider’s

backbone. It is also used to transit an AS to exchanges prefixes with other AS’s. IBGP
neighbors need to be fully meshed because they do not advertise or forward the
prefixes learned from other IBGP speakers. The full mesh requirement can be solved
by using either route reflectors or confederations. Route reflectors and BGP
confederations are advanced topics beyond the scope of this course.
Just as in the previous example of configuring EBGP neighbors, as soon as the IBGP
neighbors are configured, the routers will try to attempt to establish a BGP session
with each other.
In this example, to configure the IBGP neighbor for Router A and Router B, we are
using the loopback interfaces IP addresses of their neighbor to establish BGP
sessions.
Revision 0919 11 - 12
View IBGP Peering Status - Active
• IBGP neighbor is stuck in Active state AS 33090
Router_A# show ip bgp summary L1: 10.1.1.10/32 IBGP L1: 10.1.1.11/32

BGP4 Summary
Router A Router B
Router ID: 10.1.1.10 Local AS Number: 33090
Confederation Identifier: not configured
Confederation Peers:
Maximum Number of IP ECMP Paths Supported for Load Sharing: 1
Number of Neighbors Configured: 2, UP: 1
Number of Routes Installed: 0
Number of Routes Advertising to All Neighbors: 0 (0 entries)
Number of Attribute Entries Installed: 0
Neighbor Address AS# State Time Rt:Accepted Filtered Sent ToSend
10.1.1.11 33090 ACTIV 0h 1m24s 0 0 0 0
198.135.207.2 22787 ESTAB 0h 4m23s 0 0 0 0
Because loopback interfaces are being used for the IBGP peering session, additional
configuration steps are required. Until those steps are taken, the state of the peers
will be Active (ACTIV). The explanation for this behavior is related to the default
behavior of a router’s interface use when attempting to establish a peer session.
Revision 0919 11 - 13
IBGP – Using Loopbacks
• IBGP requires full-mesh connectivity between peers over Interior Gateway Protocol (IGP)
• For redundant paths, use loopbacks to establish session
• The update-source command forces the router to use an alternate interface for peer
(neighbor) communication
AS 100
Loopback Loopback
AS 300
IGBP IGBP EBGP
ISP Customer 2
IGBP
IGBP IGBP
Loopback
Loopback Loopback
IGBP
Loopback
• Without update-source, TCP connection source IP address is the outbound interface -

which is physical and can go down!
By default, BGP will use the IP address of the physical interface as the source IP in the
packets sent to the peer. If the physical interface goes down, even though there is
another path to the peer, the packets can’t be sent.
The solution is to configure all IBGP peering to use loopback addresses. This loopback
address needs to be advertised and included in the IGP routing table. Neighboring
routers will need to have an explicit route to the IBGP peer loopback address. If this is
done, the peering will continue to be established providing the routers have some
level of IP connectivity. As links fail and return, the traffic is automatically rerouted,
usually with no interruption to the peering session. This loopback address needs to
be advertised and included in the IGP routing table. Neighboring routers will need to
have an explicit route to the IBGP peer loopback address.
Revision 0919 11 - 14
IBGP – Loopback as Update Source
• Loopback addresses should be used for this purpose, as they can never go down
– Syntax: neighbor ip-address update-source loopback num
AS 33090
IBGP
Loopback 1 Loopback 1
10.1.1.10 Router A e1 e5 Router B 10.1.1.11
10.255.43.10 10.255.43.9
!Router A !Router B
router bgp router bgp
local-as 33090 local-as 33090
neighbor 10.1.1.11 remote-as 33090 neighbor 10.1.1.10 remote-as 33090
neighbor 10.1.1.11 update-source loopback 1 neighbor 10.1.1.10 update-source loopback 1
! !
interface loopback 1 interface loopback 1
ip address 10.1.1.10/32 ip address 10.1.1.11/32
! !
ip route 10.1.1.11/32 10.255.43.9 ip route 10.1.1.10/32 10.255.43.10
• Important: Both neighbor addresses used for peering must be routable and reachable
To configure a BGP router to communicate with its IBGP neighbor, through a specified
interface (e.g. Loopback 1) use the CLI command:
Syntax: neighbor ip-address update-source loopback num
The loopback address must be a routable and reachable IP address.
The neighbor command has some additional parameters, as shown in the following:
Syntax: [no] neighbor { ip-address | ipv6-address | peer-group-name } update-source
{ ip-address | ipv6-address | ethernet unit/slot/port | lag lag-id | loopback num | ve
vlan_id }
The examples shown configures the router to communicate with the neighbor
through the specified interfaces.
Revision 0919 11 - 15
View IBGP Peering Status - Established
• IBGP neighbors transition to Established state AS 33090
Router_A# show ip bgp summary L1: 10.1.1.10/32 IBGP L1: 10.1.1.11/32

BGP4 Summary
Router A Router B
10.1.1.11 33090 ESTAB 0h 1m24s 0 0 0 0
198.135.207.2 22787 ESTAB 0h 4m23s 0 0 0 0
Because loopback interfaces are being used for the IBGP peering session, additional
configuration steps are required. Until those steps are taken, the state of the peers
will be Active (ACTIV). The explanation for this behavior is related to the default
behavior of a router’s interface use when attempting to establish a peer session.
Revision 0919 11 - 16
BGP Neighbor Authentication
• MD5 password for securing sessions between the neighbors can be used for additional
security
• Password parameters are:
– Up to 63 characters long
– Can contain any alphanumeric (first character cannot be a number)
– Spaces can be used if the words are placed inside quotes
• Passwords are applied on a per neighbor basis and must match on neighbor
Router_A(config-bgp)# neighbor 10.1.1.11 password pr0t3ct$
The system adds an encryption code followed by the encrypted text of the original
password. One of the following may be displayed:
• 0 = the password is not encrypted and is in clear text
• 1 = the password uses proprietary simple cryptographic 2-way algorithm
If you want the software to assume that the value you enter is the clear-text form,
and to encrypt display of that form, do not enter 0 or 1. Instead, omit the encryption
option and allow the software to use the default behavior. If you specify encryption
option 1, the software assumes that you are entering the encrypted form of the
password or authentication string. In this case, the software decrypts the password or
string you enter before using the value for authentication. If you accidentally enter
option 1 followed by the clear-text version of the password or string, authentication
will fail because the value used by the software will not match the value you intended
to use.
Revision 0919 11 - 17
Limiting BGP Neighbor Prefix Advertisements
• You can specify the maximum number of IP network prefixes (routes) that can be learned
from the specified neighbor
– Value 0 through 4,294,967,295 (Default is 0 (unlimited))
Router_A(config-bgp)# neighbor 198.135.207.2 maximum-prefix 2000 80 teardown

• Syntax: [no] neighbor { ip-address | ipv6-address | peer-group-name } maximum-prefix num [ threshold ] [
teardown ]
– Threshold parameter specifies the percentage of the value you specified for the maximum prefix which
when crossed will generate a Syslog message (Range 1-100%)
– Teardown parameter tears down the neighbor session if the maximum-prefix limit is exceeded1
Footnote 1: The session remains shutdown (if the teardown parameter is configured)
until you clear the prefixes using the clear ip bgp neighbor all or clear ip bgp
neighbor command, or change the maximum prefix configuration. The software also
generates a Syslog message.
Revision 0919 11 - 18
Display BGP Neighbor

Router_A# show ip bgp neighbor
Total number of BGP Neighbors: 2
1 IP Address: 10.1.1.11, AS: 33090 (IBGP), RouterID: 10.1.1.11, VRF: default-vrf
State: ESTABLISHED, Time: 0h21m12s, KeepAliveTime: 60, HoldTime: 180
KeepAliveTimer Expire in 15 seconds, HoldTimer Expire in 127 seconds
Minimal Route Advertisement Interval: 0 seconds
UpdateSource: Loopback 1
RefreshCapability: Received
GracefulRestartCapability: Received
Restart Time 120 sec, Restart bit 0
afi/safi 1/1, Forwarding bit 0
GracefulRestartCapability: Sent
Messages: Open Update KeepAlive Notification Refresh-Req
Sent : 6 2 31 3 0
Received: 5 2 25 2 0
Last Update Time: NLRI Withdraw NLRI Withdraw
Tx: --- --- Rx: --- ---
Last Connection Reset Reason:Rcv Notification
Notification Sent: Cease/Administrative Reset
Notification Received: Cease/Administrative Reset
Neighbor NLRI Negotiation:
<Output Truncated>
This command shows the router’s peers and whether the peer is an IBGP or EBGP
neighbor.
To view BGP neighbor information including the values for all the configured
parameters, enter the following command: show ip bgp neighbor
The display shows information regarding connection and exchange with all BGP
neighbors.
Revision 0919 11 - 19
Display BGP Neighbor (cont.)

2 IP Address: 198.135.207.2, AS: 22787 (EBGP), RouterID: 12.12.12.12, VRF: default-vrf
Sent : 3 2 33 3 0
Received: 3 2 30 0 0
Tx: --- --- Rx: --- ---
Last Connection Reset Reason:User Reset Peer Session
Notification Received: Unspecified
Peer Negotiated IPV4 unicast capability
Peer configured for IPV4 unicast Routes
Neighbor AS4 Capability Negotiation:
<Output Truncated>
This is the second part of the command, with Router_A’s second neighbor (EBGP)
information.
Revision 0919 11 - 20
No Routes Advertised
• Peering established to all neighbors but no routes are being shared
Router_A# show ip bgp summary

BGP4 Summary
10.1.1.11 33090 ESTAB 0h 1m24s 0 0 0 0
198.135.207.2 22787 ESTAB 0h 4m23s 0 0 0 0
You can display the local AS number, the maximum number of routes and neighbors
supported, and some BGP statistics.
To view summary BGP information for the router, enter the following command at
any CLI prompt: show ip bgp summary
Some of the fields of interest are:
• Time - The time that has passed since the state last changed.
• Rt: Accepted - The number of routes received from the neighbor that this router
installed in the BGP4 route table. Usually, this number is lower than the
RoutesRcvd number. The difference indicates that this router filtered out some of
the routes received in the UPDATE messages
• Filtered - The routes or prefixes that have been filtered out:
• If soft reconfiguration is enabled, this field shows how many routes were
filtered out (not placed in the BGP4 route table) but retained in memory.
• If soft reconfiguration is not enabled, this field shows the number of BGP4
routes that have been filtered out.
• Sent - The number of BGP4 routes that the Layer 3 switch has sent to the neighbor.
• ToSend - The number of routes the Layer 3 switch has queued to send to this
neighbor
Revision 0919 11 - 21
Specify Network To Advertise
• A BGP router does originate an network advertisement unless there is a valid entry in the
IP routing table for the network
– The exact route and subnet mask must exist in the IP route table
• Network prefixes can be explicitly advertised into BGP using:

– A network command
– Redistribution
• Advertising prefix with the network command:

Router_A(config-bgp-router)# network 198.135.208.0/22
– Syntax: [no] network network/mask [ backdoor | route-map map-name | weight num ]
• Advertising prefixes with redistribution command:

Router_A(config-bgp-router)# redistribute connected
– Syntax: [no] redistribute { connected| ospf | rip | static } [ metric num ] [ route-map string ]
In order to advertise a network, the exact route must exist in the IP route table before
the Layer 3 Switch can create a local BGP route.
To configure the Layer 3 Switch to advertise network 161.79.45.0/24, enter the
command shown on the slide. The options are defined as:
• network/mask - specifies the network number and network mask.
• route-map map-name - specifies the name of the route map you want to use to
set or change BGP attributes for the network you are advertising. The route map
must already be configured.
• weight num - specifies a weight to be added to routes to this network.
• backdoor - changes the administrative distance of the route to this network from
the EBGP administrative distance (20 by default) to the Local BGP weight (200 by
default), thus tagging the route as a backdoor route. Use this parameter when you
want the router to prefer IGP routes such as RIP or OSPF routes over the EBGP
route for the network.
In practice, the aggregate-address command may be used instead of network
command.
You can also configure the device to redistribute RIP routes, OSPF routes, directly
connected routes, or static routes into BGP4 and BGP4+. This is accomplished with
the redistribute command followed by the protocol which the routes are being
redistributed from. An optional metric or route-map can be applied to the
redistributed protocol.
Revision 0919 11 - 22
Disabling BGP Neighbors
• For maintenance and troubleshooting you may need to temporarily disable BGP neighbors
• To disable a BGP peer, issue the command:

Router_A(config-bgp-router)# neighbor 10.1.1.11 shutdown
– Adds neighbor entry to the running-configuration disabling the neighbor but maintaining all BGP
configuration parameters relating to the neighbor
• To re-enable the BGP session to the peer issue the following command
Router_A(config-bgp-router)# no neighbor 10.1.1.11 shutdown
Note: All BGP configurations or all configurations related to that neighbor will be lost
when no router bgp or no neighbor is issued.
Revision 0919 11 - 23
Displaying BGP Information
Revision 0919 11 - 24
Displaying BGP Information and Configuration
• Common BGP commands:

– Summary BGP configuration information for the router
show ip bgp summary
– Active BGP configuration information
show ip bgp config
– Neighbor information
show ip bgp neighbor
show ip bgp neighbors x.x.x.x advertised-routes
– Information about the paths from which BGP selects routes using the BGP route table
show ip bgp routes
– BGP database
show ip bgp
– Active route maps
show route-map
You can display the following configuration information and statistics for the BGP
protocol on the router:
• Summary BGP configuration information for the router
• Active BGP configuration information (the BGP information in the running-config)
• CPU utilization statistics
• Neighbor information
• Peer-group information
• Information about the paths from which BGP selects routes
• Summary BGP route information
• The router BGP route table
• Route flap dampening statistics
• Active route maps (the route map configuration information in the running-config)
Revision 0919 11 - 25
Display BGP Summary
• Display summary of BGP information
Router_A# show ip bgp summary

BGP4 Summary
Number of Routes Installed: 4, Uses 344 bytes
Number of Routes Advertising to All Neighbors: 6 (6 entries), Uses 288 bytes
Number of Attribute Entries Installed: 2, Uses 180 bytes
10.1.1.11 33090 ESTAB 1h 9m21s 0 0 4 0
198.135.207.2 22787 ESTAB 1h12m19s 2 0 2 0
neighbor
Revision 0919 11 - 26
Display BGP Configuration
• Display active BGP configuration information:
Router_A# show ip bgp config

Current BGP configuration:
router bgp
local-as 33090
neighbor 10.1.1.11 remote-as 33090
neighbor 10.1.1.11 update-source loopback 1
neighbor 198.135.207.2 remote-as 22787
address-family ipv4 unicast

network 198.135.208.0/22
network 198.135.212.0/23
exit-address-family
end
To view the active BGP configuration information contained in the running-config

without displaying the entire running-config, use the command show ip bgp config.
The example displays the device active BGP configuration.
Revision 0919 11 - 27
Display Neighbor Advertised Routes
• Display the routes advertised to a specific neighbor:
Router_A# show ip bgp neighbor 198.135.207.2 advertised-routes

There are 2 routes advertised to neighbor 198.135.207.2
Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST E:EBGP I:IBGP L:LOCAL
Prefix Next Hop MED LocPrf Weight Status
1 198.135.208.0/22 198.135.207.1 0 32768 BL
AS_PATH: 33090
2 198.135.212.0/23 198.135.207.1 0 32768 BL
AS_PATH: 33090
– Syntax: show ip bgp neighbors ip-addr advertised-routes [ detail | / mask-bits ]
The CLI displays the routes the Layer 3 Switch has advertised to a specific neighbor for
a specific network.
Revision 0919 11 - 28
Display BGP Route Summary
• Displays the summary statistics for all the routes in the Layer 3 Switch BGP route table,
example:
Router_A# show ip bgp routes summary

Total number of BGP routes (NLRIs) Installed : 4
Distinct BGP destination networks : 4
Filtered bgp routes for soft reconfig : 0
Routes originated by this router : 2
Routes selected as BEST routes : 4
BEST routes not installed in IP forwarding table : 0
Unreachable routes (no IGP route for NEXTHOP) : 0
IBGP routes selected as best routes : 0
EBGP routes selected as best routes : 2
To display summary statistics for all the routes in the Layer 3 Switch BGP route table,
enter a command such as the above at any level of the CLI. The fields display are
described as follows:
• Total number of BGP routes (NLRIs) Installed: The number of BGP routes the Layer
3 Switch has installed in the BGP route table.
• Distinct BGP destination networks: The number of destination networks the
installed routes represent. The BGP route table can have multiple routes to the
same network.
• Filtered BGP routes for soft reconfig: The number of route updates received from
soft-reconfigured neighbors or peer groups that have been filtered out but
retained.
• Routes originated by this router: The number of routes in the BGP route table that
this Layer 3 Switch originated.
• Routes selected as BEST routes: The number of routes in the BGP route table that
this Layer 3 Switch has selected as the best routes to the destinations.
• BEST routes not installed in IP forwarding table: The number of BGP routes that
are the best BGP routes to their destinations but were not installed in the IP route
table because the Layer 3 Switch received better routes from other sources (such
as OSPF, RIP, or static IP routes).
• Unreachable routes (no IGP route for NEXTHOP): The number of routes in the BGP
route table whose destinations are unreachable because the next hop is
unreachable.
• IBGP routes selected as best routes: The number of “best” routes in the BGP route
table that are IBGP routes.
• EBGP routes selected as best routes: The number of “best” routes in the BGP
route table that are EBGP routes.
Revision 0919 11 - 29
Display BGP Route Table
• Displays entries in the IPv4 Border Gateway Protocol prefix table:
Router# show ip bgp

Total number of BGP Routes: 4
Status codes: s suppressed, d damped, h history, * valid, > best, i
internal, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop MED LocPrf Weight Path
*> 134.242.24.0/22 198.135.207.2 0 100 0 22787 i
*> 134.242.220.0/22 198.135.207.2 0 100 0 22787 i
*> 198.135.208.0/22 0.0.0.0 0 100 32768 i
*> 198.135.212.0/23 0.0.0.0 0 100 32768 i
Revision 0919 11 - 30
Troubleshooting BGP Peering
Revision 0919 11 - 31
View BGP Peer State
• Use the show ip bgp summary command to view the current state of the BGP peering session
Cust-01# show ip bgp summary

BGP4 Summary
172.16.56.1 64469 IDLE 0h18m20s 0 0 0 0
• The peering state for the customer-side router is stuck in IDLE

– Brief transitions to Active (ACTIV) may be seen as peers will continue attempting session establishment
BGP Session States:

Idle: Indicates that a BGP session is starting; searches for and certifies route to
neighbor; new (or incoming) BGP connections are not permitted.
Connect: The session enters this state while the router is waiting for the TCP
connection to complete. A session stuck in Connect usually indicated an IP
connectivity issue.
Active: The session enters this state if the TCP connection is unsuccessful, and then
returns to the Connect state. A session state stuck in Active usually indicates either a
TCP connection failure.
OpenSent: After a successful TCP connection, the BGP sends an open message and
waits for one in return.
OpenConfirm: The session enters this state when an open message is returned in the
OpenSent state.
Established: The session enters this state when peers send update messages to
exchange information about each route being advertised.
Revision 0919 11 - 32
BGP State Machine
Revision 0919 11 - 33
Review Configuration
• Each router’s local-as value should match the peer router’s remote-as value
Cust-01# show ip bgp config ISP1# show ip bgp config
Current BGP configuration: Current BGP configuration:
router bgp router bgp

local-as 18816 local-as 64496
neighbor 172.16.56.1 remote-as 64469 neighbor 172.16.56.2 remote-as 18816
address-family ipv4 unicast address-family ipv4 unicast

exit-address-family exit-address-family
end end
Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved © 2017 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION 34
For eBGP peering to be migrate to the Established state, each router’s local-as must
match the neighbor’s configured remote-as. The local AS number is provided in the
OpenSent BGP message. If the received AS number does not match the configured
local-as number, a Notification is sent and the in-progress session establishment is
torn down and BGP will start over again due to its finite state model. In this example
the configuration is showing an eBGP adjacency configuration. It is important to verify
that both peers have the correct neighbor IP address and the expected As number of
the neighbor. As both of these peers attempt TCP connections with each other they
will compare their local configuration and only accept TCP connections to configured
neighbors. If the peer receiving the SYN message does not see the source IP address
configured in a neighbor statement it will not respond to the request. Therefore care
needs to be taken to ensure the neighbors IP address and its correct AS number is
configured.
Revision 0919 11 - 34
Debug Peering Process
• The misconfiguration can be confirmed by viewing the output of the debug ip bgp
neighbor command
Cust-01# debug ip bgp neighbor 172.16.56.1
BGP: 172.16.56.1 start peer
BGP: 172.16.56.1 Init TCP Connection to peer, local IP 172.16.56.2
BGP: 172.16.56.1 Active TCP Connection is Open, local address 172.16.56.2
BGP: 172.16.56.1 TCP Connection opened
BGP: 172.16.56.1 sending MultiProtocol cap, afi/safi=1/1, length 4
BGP: 172.16.56.1 sending Graceful Restart cap, rbit 0, time 120, length 6
BGP: 172.16.56.1 sending OPEN, My asn=18816 holdTime=180 route_refresh=1 cooperative= 1, restart 1/0
BGP: 172.16.56.1 rcv OPEN w/Option parameter length 16, My asn 64496, hold_time 180
BGP: 172.16.56.1 rcv OPEN w/Option parameter length 16
BGP: 172.16.56.1 rcv MP_EXT capability 1, len 4, afi/safi=1/1
BGP: 172.16.56.1 rcv capability 2, len 0
BGP: 172.16.56.1 rcv capability 128, len 0
BGP: 172.16.56.1 rcv OPEN: bad peer AS number 64496, expected 64469
BGP: 172.16.56.1 rcv OPEN: bad peer AS number 64496, expected 64469
BGP: 172.16.56.1 sending NOTIFICATION 2/2 (Bad Peer AS Number)
BGP: 172.16.56.1 reset due to BGP notification sent
BGP: 172.16.56.1 Closing TCP connection 0x255bac94
In this debug output we can see a TCP connection was established which indicates
the correct neighbor IP address configured on the remote router. If it was not the
remote router would have refused the TCP connection and that would be reflected in
this output. Other misconfigurations can also be confirmed in the debug output
which shows that the ISP router received a different local-AS number in the OPEN
exchange than was configured for the remote node. This results in a notification
being sent to the peer which will cause a reset of the connection. This will continue
until the configuration is corrected. Other notification messages can be obtained in
the debug output which can indicate other problems with establishing and
maintaining adjacency. In this example we sent a notification 2/2 indicating a bad
Peer As number. Other notification messages are available as well.
Revision 0919 11 - 35
Module Summary
– Understand Border Gateway Protocol (BGP) features and benefits
– Configure BGP on ICX devices
– View BGP configuration and troubleshoot
Revision 0919 11 - 36
End of Module 11:

Border Gateway Protocol v4 (BPG4)
Revision 0919 11 - 37
Appendix A:
Policy Changes
Revision 0919 11 - 38
BGP Policy Changes
• Policies are applied while prefixes are exchanged

– Routes already sent or received on BGP neighbors will not reflect policy changes
• To apply changes to existing prefixes received or sent, you need to enter a clear command
• Three methods:
– Hard clear – Downs BGP session & all routes are resent
– Soft-reconfiguration – Keeps copies of old updates, no routes sent
– Route refresh – BGP session remains up & all routes are resent
Revision 0919 11 - 39
1 – Hard Clear
• Disruptive and should be used with caution
• To clear a neighbor session and re-learn all exchanged routes, use the
clear ip bgp command
– Example to clear all neighbor sessions:
Router_A# clear ip bgp neighbor all
– Example to clear a specific neighbor session:

Router_A# clear ip bgp neighbor 161.79.5.2
– Syntax: clear ip bgp neighbor all|<ip-addr>| <peer-group-name>|<as-num> [soft-outbound | soft

[in|out]]
Once a notification is sent, a neighbor session is closed, once the session is

re-established route updates are resent to the neighbor. The all parameter
specifies all neighbors.
When the neighbors establish a new BGP session, they exchange route tables again.
Use this method if you want to relearn routes from the neighbor and resend your
own route table to the neighbor.
Note: Clearing neighbors triggers prefixes to be removed/added throughout the
Internet. Handle the use of “hard clear” with caution. Neighboring ISPs might
penalize you.
Revision 0919 11 - 40
Soft Reconfiguration & Router Memory
• Soft reconfiguration consumes large amounts of memory

ISP 1 ISP 2 ISP 3
(400,000 Routes) (400,000 Routes) (400,000 Routes)
Copies of all the ISPs’ route

tables are stored in memory
ISP 1: 400,000 routes
ISP 2: 400,000 routes
BGP Table ISP 3: 400,000 routes
(ISP 2) BGP Table: 400,000 routes
Total: 1,600,000 routes
BGP Table BGP Table

(ISP 1) (ISP 3)
BGP Table
BGP Router
Soft Reconfiguration keeps a complete copy of each EBGP peers route table.
Hence, instead of asking it’s neighbor to resend it’s entire route table, each time it
changes it’s configuration, it simply uses the copy stored in memory.
The soft reconfiguration feature places policy changes into effect without resetting
the BGP session. Soft reconfiguration does not request the neighbor or group to send
its entire BGP table, nor does the feature reset the session with the neighbor or
group. Instead, the soft reconfiguration feature stores all the route updates received
from the neighbor or group. When you request a soft reset of inbound routes, the
software performs route selection by comparing the policies against the stored route
updates, instead of requesting the neighbor BGP route table or resetting the session
with the neighbor. To use soft reconfiguration:
• Enable the feature
• Make the policy changes
• Apply the changes by requesting a soft reset of the inbound updates from the
neighbor or group
Note: Route refresh is preferred for most configurations. Soft reconfiguration can be
useful as a temporary solution when several configuration changes would result in
significant WAN link saturation for BGP updates.
Revision 0919 11 - 41
2 – Soft Reconfiguration
• Consumes high amount of memory
• Soft reconfiguration requires configuration during initial BGP neighbor setup:

Router_A(config-bgp-router)# neighbor 161.79.5.2 soft-reconfiguration
inbound
– Syntax: [no] neighbor { ip-address | ipv6-address | peer-group-name } soft-reconfiguration inbound
• To place policy changes into effect, use this command:

Router_A(config)# clear ip bgp neighbor 161.79.5.2 soft in
– Syntax: clear ip bgp neighbor { all | as-num | peer-group-name | ip-addr } soft [ in | out ]
Use the following CLI methods to configure soft configuration, apply policy changes,
and display information for the updates that are filtered out by the policies.
To configure a neighbor for soft reconfiguration, enter a command such as the
following.
Router(config-bgp-router)# neighbor 161.79.5.2 soft-
reconfiguration inbound
This command enables soft reconfiguration for updates received from
10.10.200.102. The software dynamically refreshes or resets the session with the
neighbor, then retains all route updates from the neighbor following the reset.
Syntax: [no] neighbor { ip-address | ipv6-address | peer-group-name } soft-
reconfiguration inbound
To place policy changes into effect, enter a command such as the following.
ICX# clear ip bgp neighbor 161.79.5.2 soft in
Revision 0919 11 - 42
3 – Route Refresh – RFC 2918
• RFC 2918 compatibility is negotiated during neighbor adjacency
• Requests neighbor to resend routes

– Does not require the BGP session to close
– Does not require additional memory
– No down-time
• Typically used after configuration changes to update BGP table (route-map, prefix list,
MED)
Router# clear ip bgp neighbor 161.79.5.2 soft in

– Syntax: clear ip bgp neighbor all| <ip-addr> | <peer-group-name> | <as-num> [soft-outbound | soft [in |
out]]
The dynamic route refresh capability is enabled by default and cannot be disabled.
When the Layer 3 Switch sends a BGP OPEN message to a neighbor, the Layer 3
Switch includes a Capability Advertisement to inform the neighbor that the Layer 3
Switch supports dynamic route refresh. This command is the same used for a soft
refresh. The only difference is that the software tables have been enabled.
Note: The option for dynamically refreshing routes received from a neighbor requires
the neighbor to support dynamic route refresh. If the neighbor does not support this
feature, the option does not take effect and the software displays an error message.
The option for dynamically re-advertising routes to a neighbor does not require the
neighbor to support dynamic route refresh.
Revision 0919 11 - 43
End of Appendix A:
Policy Changes
Revision 0919 11 - 44
Appendix B:
BGP4+ Configuration
Revision 0919 11 - 45
Adding BGP4+ EBGP Neighbors – Global Address
AS 22787 AS 33090
Router C e1/1/1: e1/1/1: Router A

2001:db8:cc::1/64 2001:db8:cc::2/64
fe80:4398:ab30:45de::1 fe80:609c:9f41:ca74::1
• IPv6 neighbors can use link-local or global IPv6 address

• Neighbor must be activated in IPv6 address family configuration mode using the neighbor
activate command
• Example of adding EBGP neighbor for Router A:
Router_A(config-bgp-router)# neighbor 2001:db8:cc::1 remote-as 22787
Router_A(config-bgp-router)# address-family ipv6 unicast
Router_A(config-bgp-ipv6u)# neighbor 2001:db8:cc::1 activate
– Syntax: [no] neighbor { ip-address | ipv6-address | peer-group-name } activate
BGP4+ neighbors can be configured using link-local addresses or global addresses.

BGP4+ neighbors that are configured using global addresses are configured in the
same manner as BGP4 neighbors, by identifying the neighbors IPv6 global address in
the neighbor remote-as command. An additional step required for BGP4+ to
exchange IPv6 prefixes is to run the neighbor activate command from the IPv6
address family configuration mode.
The example on slide shows the configuration for Router A to neighbor with the
global IPv6 address of Router C.
Below is the corresponding configuration steps for Router C:
Router_C(config-bgp-router)# neighbor 2001:db8:cc::2
remote-as 700
Router_C(config-bgp-router)# address-family ipv6
unicast
Router_C(config-bgp-ipv6u)# neighbor 2001:db8:cc::2
activate
Revision 0919 11 - 46
BGP4+ neighbors can be configured using link-local addresses or global addresses.

BGP4+ neighbors can be created using link-local addresses for peers in the same link.
For link-local peers, the neighbor interface over which the neighbor and local device
exchange prefixes is specified through the neighbor update-source command, and a
route map is configured to set up a global next hop for packets destined for the
neighbor.
To configure BGP4+ neighbors that use link-local addresses, you must do the
following:
• Add the IPv6 address of a neighbor in a remote autonomous system (AS) to the
BGP4+ neighbor table of the local device.
• Identify the neighbor interface over which the neighbor and local device will
exchange prefixes using the neighbor update-source command.
• Configure a route map to set up a global next hop for packets destined for the
neighbor.
The neighbor should be activated in the IPv6 address family configuration mode using
the neighbor activate command.
Link-local example:
ICX(config)# router bgp
ICX(config-bgp-router)# local-as 1000
ICX(config-bgp-router)# neighbor fe80:4398:ab30:45de::1 remote-as 1001
ICX(config-bgp-router)# neighbor fe80:4398:ab30:45de::1 update-source
ethernet 1/3/1
ICX(config-bgp-router)# address-family ipv6 unicast
ICX(config-bgp-ipv6u)# neighbor fe80:4398:ab30:45de::1 activate
ICX(config-bgp-ipv6u)# neighbor fe80:4398:ab30:45de::1 route-map out
myroutemap
ICX(config-bgp-ipv6u)# exit
ICX(config)# route-map myroutemap permit 10
ICX(config-route-mapmyroutemap)# set ipv6 next-hop 2001::10
Revision 0919 11 - 47
Specify IPv6 Network To Advertise
• Network prefixes must be explicitly advertised using the network command or by

redistribution into BGP
• IPv6 prefixes are defined in the IPv6 unicast address-family under the router bgp
configuration context
• Example: Configure the router to advertise network 2001:db8:444:9b9b::0/64

Router_A(config)# router bgp
Router_A(config-bgp-router)# address-family ipv6 unicast
Router_A(config-bgp-ipv6u)# network 2001:db8:444:9b9b::0/64
– Syntax: [no] network network/mask [ backdoor | route-map map-name | weight num ]
In order to advertise a network, the exact route must exist in the IP route table before
the Layer 3 Switch can create a local BGP route.
To configure the Layer 3 Switch to advertise network 161.79.5.0/24, enter the
command shown on the slide. The options are defined as:
• network/mask - specifies the network number and network mask.
• route-map map-name - specifies the name of the route map you want to use to
set or change BGP attributes for the network you are advertising. The route map
must already be configured.
• weight num - specifies a weight to be added to routes to this network.
• backdoor - changes the administrative distance of the route to this network from
the EBGP administrative distance (20 by default) to the Local BGP weight (200 by
default), thus tagging the route as a backdoor route. Use this parameter when you
want the router to prefer IGP routes such as RIP or OSPF routes over the EBGP
route for the network.
In practice, the aggregrate-address command may be used instead of network
command.
Revision 0919 11 - 48
Verify BGP4+ Peering
AS 33090
L1: 10.1.1.10/32 L1: 10.1.1.11/32
2001:0db8:79:7::1/128 2001:0db8:79:8::1/128
AS 22787 EBGP IBGP
Router C e1: e1: Router A Router B

2001:db8:cc::1/64 2001:db8:cc::2/64
Router_A(config-bgp-router)# show ipv6 bgp summary

BGP Summary
Router ID: 10.1.1.10 Local AS Number : 33090
Confederation Identifier : not configured
Maximum Number of Paths Supported for Load Sharing : 1
Number of Neighbors Configured : 2, UP: 2
Number of Routes Installed : 19
Number of Routes Advertising to All Neighbors : 6
Number of Attribute Entries Installed : 15
2001:db8:cc::1 22787 ESTAB 9h 1m 7s 0 0 0 0
2001:db8:79:8::1 33090 ESTAB 7h 18m 10s 13 0 6 0
neighbor
Revision 0919 11 - 49
Display BGP4+ Neighbor Information

Router_A(config-bgp-router)# show ipv6 bgp neighbor
Total number of BGP Neighbors: 2
1 IP Address: 2001:db8:cc::1, AS: 22787 (EBGP), RouterID: 12.12.12.12, VRF: default-vrf
Sent : 7 15 320 9 2
Received: 7 16 319 2 1
Tx: --- --- Rx: --- ---
Last Connection Reset Reason:Reset All Peer Sessions
Notification Received: Cease/CEASE Message
<Output Truncated>
This command shows the router’s peers and whether the peer is an IBGP or EBGP
neighbor.
To view BGP neighbor information including the values for all the configured
parameters, enter the following command: show ip bgp neighbor
The display shows all the configured parameters for the neighbor. Only the
parameters that have values different from their defaults are shown.
Revision 0919 11 - 50
Display BGP4+ Neighbor Information (cont.)

2 IP Address: 2001:db8:bb::2, AS: 33090 (IBGP), RouterID: 10.1.1.11, VRF: default-vrf
Sent : 1 1 1 0 0
Received: 1 1 1 0 0
Tx: --- --- Rx: --- ---
Last Connection Reset Reason:Rcv Notification
Notification Received: Cease/Administrative Reset
Peer Negotiated IPV6 unicast capability
Peer configured for IPV6 unicast Routes
<Output Truncated>
This is the second part of the command, with Router_A’s second neighbor (IBGP)
information.
Revision 0919 11 - 51
End of Appendix B:
BGP4+ Configuration
Revision 0919 11 - 52
ICX 200 Traffic Management
Module 12:
Traffic Management
Module Objectives
– Define the elements that make up Quality of Service (QoS)
– Describe QoS classification methods at both Layer 2 and Layer 3
– Explain QoS switch queues and weighting
– Differentiate between the different methods of QoS queue scheduling
– Describe the difference between rate limiting and rate shaping
Quality of Service Overview
What Is Quality of Service? 149_QoS.png
• QoS is an umbrella term for tools and protocols that control and manage the use of
network resources
• Network traffic is prioritized to ensure appropriate resources are available for the most
critical traffic
• Optimizes bandwidth utilization and enforces Service Level Agreements (SLAs) for different
services and applications
– Allows performance to be more predictable and bandwidth utilization more effective
– Provides protection from network attacks (DoS)
Quality of Service (QoS) provides preferential treatment to specific traffic.

Quality of Service (QoS) features are used to prioritize the use of bandwidth in a
switch. When QoS features are enabled, traffic is classified as it arrives at the switch,
and processed through on the basis of configured priorities. Traffic can be dropped,
prioritized for guaranteed delivery, or subject to the delivery options as configured by
a number of different mechanisms.
Here are some example QoS targets:
• Voice – No drop calls, no static
• (latency <150 ms, jitter<30 ms, loss<1%)
• Video – High quality, smooth video
• (latency <150 ms, jitter<50 ms, loss<0.05%)
• Data – Different SLAs for business users/applications
• Control delay, jitter, and packet loss
QoS Elements
• Classification
– Traffic is differentiated and processed based on prioritization
• Queueing
– QoS values are mapped to various “lanes” on outbound ports
– Segregation of outbound traffic providing opportunity of preferential treatment of forwarding
– Queue congestion avoidance can be controlled by algorithms such as Random Early Detection (RED) or
Weighted Random Early Detection (WRED)
• Scheduling
– Scheduling determines how the frames/packets in the queues are served, such as Weighted Round Robin
(WRR) scheduling algorithm and Strict Priority scheduling algorithm
Classification is the process of selecting packets on which to perform QoS, reading or

ignoring the QoS information, and assigning a priority to the packets. The
classification process assigns a priority to packets as they enter the switch. These
priorities can be determined on the basis of information contained within the packet
or assigned to the packet as it arrives at the switch. Once a packet or traffic flow is
identified and marked, then it is mapped to a forwarding priority queue.
Queueing is the process in which packets on Ruckus devices are classified in up to
eight traffic classes with values from 0 to 7. Packets with higher priority classifications
are given a precedence for forwarding.
There are two traffic types in QoS:
• Data—These can be either network-to-network traffic or traffic from the CPU.
QoS parameters can be assigned and modified for data traffic. The device also
supports setting or modifying the IEEE 802.1p user priority or the IP header
DSCP field.
• Control—Packets to and from the CPU is considered control traffic. The QoS
parameters associated with the control traffic are preassigned and not
configurable.
Scheduling is the process of mapping a packet to an internal forwarding queue based
on its QoS information and servicing the queues according to a queueing method.
The following QoS queueing methods are supported for the FastIron devices:
• Weighted Round Robin (WRR)
• Strict Priority (SP)
• Hybrid WRR and SP
QoS Elements (cont.)
• Remarking
– Remarking is typically the last phase of the QoS process
– The remarking engine has the option of rewriting the QoS value of a packet before it is put out onto the
wire
– The QoS values that can be remarked include 802.1p, IP precedence/DCSP bits
• Policing
– Manages traffic congestion by determining whether packets are conforming to administratively defined
traffic rates and takes action accordingly (passing, remarking, or dropping a packet)
Remarking, also referred to as QoS marking, is the process of initially changing the
packet QoS information for the next hop. You can mark a packet’s Layer 2 Cost of
Service (CoS) value, its Layer 3 Differentiated Services Code Point (DSCP) value, or
both values. The Layer 2 CoS or DSCP value that the device marks in the packet is the
same value that results from mapping the packet QoS value into a Layer 2 CoS or
DSCP value. Marking is optional and is disabled by default.
Policing, or rate limiting, allows the configuration of administratively defined
thresholds to apply to incoming and outgoing traffic. If the traffic is not in
conformance with the configured policy, action may be taken by the switch to force
conformity. Some of these actions include passing, remarking, or dropping non-
confirming packets.
QoS Classification
Classification
• Defines how traffic is treated based on ingress Ethernet frame and IP packet data
Layer 2 Switch Layer 3 Router
Incoming Tagged Ethernet Frame Incoming IP Packet

802.1p value is used to classify DSCP value is used to classify
Classification occurs at ingress
– At Layer 2, 802.1p priority bits in 802.1Q header are used
– At Layer 3, Differentiates Services Code Point in IP header are used
Classification of network data occurs at ingress on a networking device. Classically,

switches and routers use different fields in frames and packets, respectively, to
determine the trust level of data.
Layer 2 switches leverage the 802.1Q Ethernet frame header to classify traffic, the
Class of Service (CoS) value, this is the 802.1p priority value in the header of an
802.1Q Ethernet frame. It can be a value from 0 through 7. The 802.1p priority is also
called the Class of Service.
Routers, which operate at Layer 3, leverage the Differentiated Services Code Point
(DSCP). This is the value in the six most significant bits of the IP packet header 8-bit
DSCP field. It can be a value from 0 through 63. These values are described in RFCs
2472 and 2475. The DSCP value is sometimes called the DiffServ value.
This process is potentially more complicated when a devices operates as a Layer3
switch, i.e. both a switch and a router. Ruckus employs a precedence process to
determine which of the available classification processes is factored when multiple
methods are employed. These processes and precedencies will be covered in more
detail throughout this presentation.
Layer 2 QoS Classification
• IEEE Ethernet 802.1Q Class of Service (CoS)

• 802.1Q adds space in the Ethernet frame for: 1
– 16-bit Tag Protocol ID Field (TPID)
– 3-bit CoS value allowing for eight levels of QoS
– 12-bit VLAN ID field
Footnote 1: Bit four, not defined in the graphic, is a 1 bit CFI field used for
compatibility between Ethernet and Token Ring networks.
Class of Service (CoS) is a 3-bit field within an Ethernet frame header known as the
Priority Code Point (PCP) when using a 802.1 network. This field specifies a priority
value between 0 and 7, inclusive, that can be used by Quality of Service (QoS) to
differentiate traffic.
Layer 3 QoS Classification
• IPv4/IPv6 Packets
• DSCP: Six most significant bits of ToS (Type of Service) byte are called Differentiated
Services Code Point (DSCP) – remaining two bits used for flow control
– A default DSCP decode table is used to derive a 3-bit priority value and a 2-bit drop precedence value for
incoming packets1
– Custom decode DSCP policy maps configured in a switch can be configured and takes precedence over the
default DSCP decode table2
Version ToS
Len ID Offset TTL Proto FCS IP SA IP DA Data
Length Byte
Standard IPv4
7 IP Precedence
6 5 4 3 2
Unused 1 0
DiffServ Code Point (DSCP) IP ECN DiffServ Extensions
Footnote 1: Default table described in following notes slides. Table mapping

categorizes a DSCP value to a priority value (0 to 7) and a drop precedence value (0 to
3) for the packet
Footnote 2: It is best practice to keep policy maps consistent on all devices through a
network environment to allow consistent and deterministic packet forwarding.
The Differentiated Services Code Point (DSCP) is a 6-bit field in an IP header for the
classification of packets. Differentiated Services is a technique used to classify and
manage network traffic and it helps to provide QoS for modern Internet networks. It
can provide services to all kinds of networks.
Ruckus FastIron releases support basic DSCP-based QoS (also called Type of Service
[ToS]-based QoS). However, the FastIron family of switches does not support other
advanced DSCP-based QoS features.
Ruckus FastIron releases also support marking of the DSCP value. The software can
read Layer 3 Quality of Service (QoS) information in an IP packet and select a
forwarding queue for the packet based on the information. The software interprets
the value in the six most significant bits of the IP packet header 8-bit ToS field as a
DSCP value, and maps that value to an internal forwarding priority.
The internal forwarding priorities are mapped to one of the eight forwarding queues
(qosp0 through qosp7) on the Ruckus device. During a forwarding cycle, the device
gives more preference to the higher-numbered queues, so that more packets are
forwarded from these queues. For example, queue qosp7 receives the highest
preference, while queue qosp0, the best-effort queue, receives the lowest
preference.
Revision 0919 12 - 10
Why Multiple QoS Markings?
• QoS capabilities vary based on the location or roll of a device (switches and routers) as well
as host capabilities
• Many times different marking techniques are used within a network

– PCP marking in Ethernet frames allows layer 2 devices to forward the packet at the data link layer
– DSCP to mark the QoS requirements of packets through the routed layers of the network
• More granular control is achieved when a blend of marking techniques are used within a
network
Revision 0919 12 - 11
Classifying Traffic on ICX
• Using port ACLs

– Overwrites incoming CoS/DSCP based on ACL rules
• Source MAC address
– Overwrites incoming CoS with configured values
• Layer 3 Differentiated Services Code Point (DSCP)
– This is the value in the six most significant bits of the IP packet header 8-bit DSCP field
– It can be a value from 0 through 63
– Switch does not honor incoming DSCP values by default, but can configured to do so
• When configured, switch automatically maps the DSCP value of a packet to a hardware forwarding queue
• Layer 2 Class of Service (CoS) value – Priority Code Point (PCP)1

– This is the 802.1p priority value in the Ethernet frame
– It can be a value from 0 through 7
– Switch honors incoming value by default, unless overwritten
• Static port configuration (default = 0)
Footnote 1: The Priority Code Point (PCP) field was formerly called IEEE 802.1p.
802.1p and PCP are used interchangeably throughout this module.
The trust level in effect on an interface determines the type of QoS information the
device uses for performing QoS. A Ruckus ICX device establishes the trust level based
on the configuration of various features and whether the traffic is switched or routed.
The trust level can be one of the following:
• ACL keyword—An ACL can also prioritize traffic and mark it before sending it
along to the next hop.
• Static MAC address—If the packet does not match on an ACL that defines a
priority and the MAC address of the packet matches a static entry, the packet is
classified with the priority of the static MAC entry.
• Layer 3 Differentiated Services Code Point (DSCP)—This is the value in the six
most significant bits of the IP packet header 8-bit DSCP field. It can be a value
from 0 through 63. These values are described in RFCs 2472 and 2475. The
DSCP value is sometimes called the DiffServ value.
• Layer 2 Class of Service (CoS) value—This is the 802.1p priority value in the
Ethernet frame. It can be a value from 0 through 7. The 802.1p priority is also
called the Class of Service.
• Ingress port default priority.
Given the variety of different criteria, there are many possibilities for traffic
classification within a stream of network traffic. For this reason, the priority of
packets must be resolved based on which criteria takes precedence.
Revision 0919 12 - 12
Queueing and Remarking
Revision 0919 12 - 13
QoS Queues
• There are eight queues designated from 0 through 7 per port

– Internal forwarding priority maps to one of these eight queues
• A queue is used to store traffic until it can be processed
• An egress queue stores packets until the switch or router can serialize the data onto the
physical wire
• When QoS is enabled, packets and frames are mapped to one of eight internal QoS queues
PCP Priority DCSP QoS Queue PCP DCSP Value QoS Queue
Value Priority
0 0–7 qosp0 (lowest priority queue) 4 32 – 39 qosp4
1 8 – 15 qosp1 5 40 – 47 qosp5
2 16 – 23 qosp2 6 48 – 55 qosp6
3 24 – 31 qosp3 7 56 – 63 qosp7 (highest priority queue)
Revision 0919 12 - 14
Default Layer 2 Frame Processing and Forwarding
• By default, switched • If egress port is tagged,

traffic is mapped to a frame maintains CoS
queue based on the CoS markings
value in the 802.1Q – If untagged, all marking
header are stripped with 802.1Q
header
7
6 6 6
Tagged Port
Tagged Port
802.1Q Frame
5
802.1Q Frame
w/ 802.1p CoS (0-8) 4 w/ 802.1p CoS (0-8)
(with or without DSCP)
3 3 3
2
0 6 6
3
0 1
– By default, the ingress
0 0 0
DSCP value, if present, is
– DSCP, if present, is
passed without change
ignored by default
Revision 0919 12 - 15
Classifying Untagged Layer 2 Traffic
• All tagged frames contain CoS markings and are honored by default
• Untagged frames are not received with CoS, and are assigned the priority defined on an
interface
– Default priority is 0
• To change the hardware queue of unmarked ingress frames on port 1/1/1 to the queue 4
(qosp4):
ICX(config-if-e1000-1/1/1)# priority 4
– The device assigns priority 4 to untagged switched traffic received on port 1/1/1
– Syntax: [no] priority num

• The num variable can be from 0 through 7 and specifies the IEEE 802.1 equivalent to one of the eight QoS queues
Revision 0919 12 - 16
Default DSCP Classification
• By default, DSCP is ignored

OR
• Untagged frames with IP DSCP

markings are placed into the
ports default queue 7
– If port priority is
statically defined, 6
Untagged Port
traffic is placed in 5
the defined queue IP DSCP Marked
Packet 4
3
• Tagged frames will be 2
placed in queue 0 48 48
25
0 1
matching the 802.1p 0 48
25
0
field in the 802.1Q header
Revision 0919 12 - 17
DSCP Trust
• To classify on the received DSCP value, the port must be trusted
• 6 most significant bits of IP DSCP field are mapped to internal forwarding priority (0-7)
– The default DSCP-to-Priority values are show in the table
DSCP Value Internal Forwarding Priority

• Takes precedence over CoS value in 802.1Q header 0-7 0 (Lowest Priority)
8-15 1
16-23 2
• To enable DSCP trust:
24-31 3
32-39 4
ICX(config-if-e1000-1/1/18)# trust dscp
40-47 5
– Syntax: [no] trust dscp 48-55 6
56-63 7 (Highest Priority)
DSCP-based QoS is not automatically honored for routed and switched traffic. The
default is 802.1p to CoS mapping. To honor DSCP-based QoS, you must either use an
ACL or enable trust DSCP.
When the trust dscp command is enabled, the interface honors the Layer 3 DSCP
value. The switch uses the six most significant bits of the IP packet header 8-bit ToS
field as a DSCP value, and maps that value to an internal forwarding priority. The
internal forwarding priorities are mapped to one of the eight forwarding queues
based on the table shown here, by default.
Revision 0919 12 - 18
DSCP Trust Classification
• When dscp trust is enabled, DSCP ranges are

OR
mapped to internal forwarding queues
• Default DSCP-to priority queue mapping

follows simple mathematic formula: 7
Tagged or Untagged Port

– Priority = DSCP / 8 (whole number) 6 48
IP Packet
5
– Examples: w/ DSCP 4
• 48 / 8 = 6 (with or without 802.1p CoS markings)
• 25 / 8 = 3.125 = 3
3 25
• 0/8=0 2
0 48 48
25
0 1
0 0
Revision 0919 12 - 19
Default QoS mappings for ICX platforms
Revision 0919 12 - 20
Displaying DSCP-to-Priority Mapping
• The show qos-tos command is used to display the DSCP-to-Priority mapping table
ICX# show qos-tos

DSCP-->Traffic-Class map: (DSCP = d1d2: 00, 01...63)
d2| 0 1 2 3 4 5 6 7 8 9
d1 |
-----+----------------------------------------
0 | 0 0 0 0 0 0 0 0 1 1 DSCP value of 24 (d1d2)
1 | 1 1 1 1 1 1 2 2 2 2 maps to a priority of 3
2 | 2 2 2 2 3 3 3 3 3 3
3 | 3 3 4 4 4 4 4 4 4 4
4 | 5 5 5 5 5 5 5 5 6 6
5 | 6 6 6 6 6 6 7 7 7 7
6 | 7 7 7 7
The show qos-tos command displays the DSCP-to-priority mappings that will be used
when DSCP is trusted on an interface. The default DSCP-to-priority mapping is
displayed here. To read this output, select the first part of the DSCP value from the d1
column and select the second part of the DSCP value from the d2 row.
Revision 0919 12 - 21
Changing DSCP Priority Mappings
• DSCP values can be re-mapped to user-specified priority queue

– Up to 8 DSCP values can mapped per command
• To change the DSCP to internal forwarding priority mappings:

ICX(config)# qos-tos map dscp-priority 48 49 50 51 52 53 54 55 to 0
ICX(config)# qos-tos map dscp-priority 56 57 58 59 60 61 62 63 to 0
ICX(config)# qos-tos map dscp-priority 24 to 2
– Syntax: [no] qos-tos map dscp-priority dscp-value1 [ ...dscp-value8 ] to priority
You can change the DSCP to internal forwarding mappings. Use the qos-tos map
dscp-priority command to assign up to 8 DSCP priority values (per command) to one
of the internal forwarding priorities.
Revision 0919 12 - 22
DSCP-to-Priority Mapping Table After Change
• The remapped DSCP-to-Priority table can be displayed with the show qos-tos command
ICX# show qos-tos

DSCP-->Traffic-Class map: (DSCP = d1d2: 00, 01...63)
d2| 0 1 2 3 4 5 6 7 8 9
d1 |
-----+----------------------------------------
0 | 0 0 0 0 0 0 0 0 1 1
1 | 1 1 1 1 1 1 2 2 2 2
2 | 2 2 2 2 2 3 3 3 3 3
3 | 3 3 4 4 4 4 4 4 4 4
4 | 5 5 5 5 5 5 5 5 0 0
5 | 0 0 0 0 0 0 0 0 0 0
6 | 0 0 0 0
Here, the changes to the DSCP-to-priority mapping as a result of the changes shown
on the previous slide are displayed. The changes from default values are highlighted.
Revision 0919 12 - 23
Assigning a Static MAC Entry
• Static MAC address assignments can be used to specify a QoS level
• To configure a static MAC entry and assign the entry to queue 4:

ICX(config)# vlan 9
ICX(config-vlan-9)# static-mac-address 1145.1163.67FF ethernet 1/1/1
priority 4
– Syntax: [no] static-mac-address ethernet-mac-address [ lag lag-id | ethernet unit/slot/port [ to

unit/slot/port ] ... ] [ priority number ]
• A static MAC entry that does not specify the priority will be assigned to queue 0 if no other
interface or QoS markings exist
Note: The location of the static-mac-address command in the CLI depends on

whether you configure port-based VLANs on the device. If the device does not have
more than one port-based VLAN (VLAN 1, which is the default VLAN containing all
ports), the static-mac-address command is at the global CONFIG level of the CLI. If
the device has more than one port-based VLAN, then the static-mac-address
command is not available at the global CONFIG level. In this case, the command is
available at the configuration level for each port-based VLAN.
Revision 0919 12 - 24
CoS Remarking
• Switch can remark CoS values of all incoming packets to specified values
– Can be applied globally or on individual ports
– Assigned ACLs or individual port settings override global settings
– Traffic is queued based on ingress classification, remarking occurs on egress
– Disabled by default
• Set CoS value to an interface

ICX(config if-e1000-1/1/1)# ip pcp-remark 3
– Marks all incoming traffic on the interface with a priority of 3
– Syntax: [no] ip pcp-remark pcp-value
The Class of Service can be remarked globally, but there are very few use cases for it.
This can be accomplished with the following configuration in global configuration
mode:
ICX(config)# ip pcp-remark 4
• Marks all incoming traffic on the device with a priority of 4
Revision 0919 12 - 25
DSCP Remarking
• Switch can remark DSCP values of all incoming packets to specified values
– Can be applied globally or on individual ports
– Assigned ACLs or individual port settings override global settings
– Traffic is queued based on ingress classification, remarking occurs on egress
– Disabled by default
• Set DSCP value globally

ICX(config)# ip dscp-remark 0
• Set DSCP value to an interface

ICX(config if-e1000-1/1/1)# ip dscp-remark 24
– Syntax: [no] ip dscp-remark dscp-value
Revision 0919 12 - 26
IP ACLs for QoS Classification and Remarking
• ACLs can be used to classify traffic and/or remark DSCP/CoS values
– dscp-marking – remarks outgoing DSCP with specified value

ICX(config-ext-nacl)# permit ip any any dscp-marking 43
– 802.1p-priority-marking – remarks the 802.1p value in the 802.1Q header with specified value
ICX(config-ext-nacl)# permit tcp any any 802.1p-priority-marking 4
– internal-priority-marking – assigns the traffic to the specified internal forwarding queue without
remarking
ICX(config-ext-nacl)# permit ip host 10.45.6.12 any internal-priority-marking 5
– 802.1p-and-internal-marking – remarks the 802.1p value in the 802.1Q header AND assigns the traffic to
the internal forwarding queue
ICX(config-ext-nacl)# permit udp any any 802.1p-and-internal-marking 4
– Note: dscp-marking can be used with any one of the 802.1p and/or internal markings in a single rule
ACL Quality of Service (QoS) parameters enable you to perform QoS for packets that
match the ACLs.
Using an ACL to perform QoS is an alternative to directly setting the internal
forwarding priority based on incoming port, VLAN membership, and so on.
The following QoS ACL marking options are supported:
• dscp-marking: Marks the DSCP value in the outgoing packet with the value you
specify.
• internal-priority-marking: Assigns traffic that matches the ACL to a hardware
forwarding queue (internal-priority-marking).
• 802.1p-priority-marking: Remarks the packets that match the ACL with the
802.1p priority (802.1p-priority-marking).
• 802.1p-and-internal-marking: Remarks the 802.1p priority and assign traffic to
a hardware forwarding queue.
The following QoS ACL matching options are supported:
• dscp-matching: Matches on the packet DSCP value. This option does not change
the packet forwarding priority through the device or mark the packet.
• 802.1p-priority-matching: Inspects the 802.1p bit in the ACL that can be used
with adaptive rate limiting.
Revision 0919 12 - 27
QoS Classification Flowchart
• QoS classification (Trust) process for most ICX device models

– The ICX 7150 classification process is displayed on the notes page
The image above illustrates how most ICX series devices determine the trust level of
a packet. As shown in the flowchart, the first criteria considered is whether the
packet matches on an ACL that defines a priority. If this is not the case and the MAC
address of the packet matches a static entry, the packet is classified with the priority
of the static MAC entry. If neither of these is true, the packet is next classified with
the ingress port default priority, then DSCP/ToS value, then 802.1p CoS value, and
finally the default priority of zero (0).
NOTE: ICX 7150 devices determine internal priority differently. The image below
illustrates how the ICX 7150 determines the trust level of a packet. ACL matches are
first considered, and DSCP/ToS priority is considered next, followed by the priority of
the static MAC entry, then default ingress port priority, 802.1p CoS value, and finally
the default priority of zero (0).
Revision 0919 12 - 28
Queue Servicing Mechanisms
Revision 0919 12 - 29
Three Queueing Mechanisms Available
• There are three queueing mechanisms available on a Ruckus ICX device:
– Weighted Round Robin (WRR)

• Ensures all queues are serviced
• Default mechanism for ICX devices
• Modified when operating as a stack1
– Strict Priority
• Only ensures service for high-priority traffic
– Mixed-Strict Priority-WRR
• A combination of WWR and strict priority
• Strict priority is applied to specific queues with round-robin service to remaining queues after SP queues are
emptied
Footnote 1: In stacking mode, the qosp7 queue is reserved as Strict Priority under the
weighted queuing mechanism. Attempts to change the qosp7 setting are ignored.
Scheduling is the process of mapping a packet to an internal forwarding queue based
on its QoS information and servicing the queues according to a queueing method.
The following QoS queueing mechanisms are supported for the FastIron devices:
Weighted Round Robin (WRR)—This method ensures that all queues are serviced
during each cycle and is the default queueing method on ICX devices.
Strict Priority (SP)—This ensures service for high-priority traffic.
Mixed SP and WWR—This configurable queueing mechanism combines both the SP
and WRR mechanisms. This combined method enables the device to give strict
priority to delay-sensitive traffic such as VoIP traffic, and weighted round robin
priority to other traffic types.
Revision 0919 12 - 30
Weighted Round Robin
• Ensures that all queues are serviced during each cycle

– A WRR algorithm is used to rotate service among the eight queues on the devices
• The rotation is based on the weights you assign to each queue

– The software automatically converts the ratios you specify into weights for the queues
• This method rotates service among the queues, forwarding a specific number of bytes in
one queue before moving on to the next one
A WRR algorithm is used to rotate service among the eight queues on the FastIron
devices. The rotation is based on the weights you assign to each queue. This method
rotates service among the queues, forwarding a specific number of packets in one
queue before moving on to the next one.
WRR is the default queueing method and uses a default set of queue weights. The
number of packets serviced during each visit to a queue depends on the percentages
you configure for the queues. The software automatically converts the percentages
you specify into weights for the queues.
Revision 0919 12 - 31
Weighted Traffic Flow and Configuration
7
6
5
Ingress 4
Egress
Traffic 3 Traffic
2
1
0
• To configure weighted
round robin scheduling
ICX(config)# qos mechanism weighted
– Syntax: [no] qos mechanism { strict | weighted | mixed-sp-wrr }
Revision 0919 12 - 32
Strict Priority
• Strict Priority (SP) ensures service for high-priority traffic
• The software assigns the maximum weights to each queue, to cause the queueing
mechanism to serve all packets in one queue before moving to a lower queue
• This method biases the queueing mechanism to favor the higher queues over the lower
queues
– For example, strict queueing processes all packets in qosp3 before processing any packets in qosp2, then
processes all packets in qosp2 before processing any packets in qosp1, etc
– With high volumes of high priority traffic, lower traffic may be starved and never be processed
• IMPORTANT: Use this function with caution as under heavy traffic load this may result in
no ability to transmit queue 0 (unmarked) traffic, which is a bulk of traffic in most network
environments.
With Strict Priority queueing the software assigns the maximum weights to each
queue, to cause the queueing mechanism to serve as many packets in one queue as
possible before moving to a lower queue. This method biases the queueing
mechanism to favor the higher queues over the lower queues.
Revision 0919 12 - 33
Strict Priority Traffic Flow and Configuration
7
6
5
Ingress 4
Egress
Traffic 3 Traffic
2
1
0
• To configure strict
priority-based
scheduling
ICX(config)# qos mechanism strict
Revision 0919 12 - 34
Mixed Weighted Round Robin and Strict Priority
• The combined method enables strict priority to delay-sensitive traffic such as VoIP traffic,
and weighted round robin priority to other traffic types
• By default, the ICX devices assign strict priority to traffic in qosp7 and qosp6, and weighted
round robin priority to traffic in qosp0 through qosp5
By default, when you select the combined SP and WRR queueing method, the device
assigns strict priority to traffic in qosp7 and qosp6, and weighted round robin priority
to traffic in qosp0 through qosp5. Thus, the device schedules traffic in queue 7 and
queue 6 first, based on the strict priority queueing method. When there is no traffic
in queue 7 and queue 6, the device schedules the other queues in round-robin
fashion from the highest priority queue to the lowest priority queue.
Revision 0919 12 - 35
Mixed Scheduling Traffic Flow and Configuration
7
6
5
Ingress 4
Egress
Traffic 3 Traffic
2
1
0
• To configure mixed
strict priority/WWR scheduling
Priority 6-7 = Strict Priority
ICX(config)# qos mechanism mixed-sp-wrr Priority 0-5 = Weighted Round Robin
Weight is a relative value. The easiest way to calculate the correlation between
weight and bandwidth is to have the total weight of all queues sum up to 100, then
the weight itself will be the % bandwidth available for that queue.
Revision 0919 12 - 36
Default Queue Weights for Standalone Units
• Weights are the designated size of the queue (bandwidth)

– Eight are used with WRR or Mixed Scheduling
– When Strict Priority scheduling is used no weight is considered
Traffic SP SP WRR WRR Mixed Mixed

Class Jumbo Jumbo Jumbo
0 SP SP 3% 8% 15% 15%
1 SP SP 3% 8% 15% 15%
2 SP SP 3% 8% 15% 15%
3 SP SP 3% 8% 15% 15%
4 SP SP 3% 8% 15% 15%
5 SP SP 3% 8% 25% 25%
6 SP SP 7% 8% SP SP
7 SP SP 75% 44% SP SP
SP = Strict Priority
WRR = Weighted Round Robin
Jumbo = Jumbo frame support enabled
Revision 0919 12 - 37
Default Queue Weights for Stacks
• Weights are the designated size of the queue (bandwidth)

– Eight are used with WRR or Mixed Scheduling
– When Strict Priority scheduling is used no weight is considered
Traffic SP SP WRR WRR Mixed Mixed

Class Jumbo Jumbo Jumbo
0 SP SP 3% 8% 15% 15%
1 SP SP 3% 8% 15% 15%
2 SP SP 3% 8% 15% 15%
3 SP SP 3% 8% 15% 15%
4 SP SP 3% 8% 15% 15%
5 SP SP 10% 16% 25% 25%
6 SP SP 75% 44% SP SP
7 SP SP SP SP SP SP
SP = Strict Priority
WRR = Weighted Round Robin
Jumbo = Jumbo frame support enabled
Revision 0919 12 - 38
Setting the Scheduler Profile
• The user-configurable scheduler profile can be created by specifying weights from qosp0
through qosp7 as shown in the following command format1
• Configure a QoS scheduler profile named user1

ICX(config)# qos scheduler-profile user1 mechanism weighted
ICX(config)# qos scheduler-profile user1 profile qosp0 5 qosp1 5 qosp2 5
qosp3 10 qosp4 40 qosp5 15 qosp6 10 qosp7 10
– Syntax: [no] qos scheduler-profile user-profile-name { mechanism scheduling-mechanism | profile [

qosp0 wt0 | qosp1 wt1 | qosp2 wt2 | qosp3 wt3 | qosp4 wt4 | qosp5 wt5 | qosp6 wt6 | qosp7 wt7 ] }
Footnote 1: If you create a profile specifying only the weights (qosp0 through qosp7)
without specifying the mechanism, the default mechanism is used.
• The default mechanism for stacking systems is Mixed, and WRR for stand-alone
systems
If you change the profile mechanism, the weights also get changed according to the
mechanism
The weights can be modified according to the following requirements:
• If the mechanism is changed to WRR, the default system weights get assigned
• If the mechanism is changed to Mixed, the default mix weights get assigned
• If the mechanism is changed to Strict, the weights are ignored and remain
untouched
Scheduler-profile modifications take effect dynamically on an active profile
Revision 0919 12 - 39
Displaying the Scheduler Profile
• To display the specified user-configurable scheduler profile configuration, use the

show qos scheduler-profile command
– A specific profile can be displayed by appending the profile name or all profiles can be displayed
ICX# show qos scheduler-profile user1

User Scheduler Profile: user1 Scheduling Option: Weighted round-robin
Ports attached: (U1) --

Ports attached: (LAG) --
Ports attached: (LAG) --Unicast per Queue details: Bandwidth%
Traffic Class 0 5%
Traffic Class 1 5%
Traffic Class 2 5%
Traffic Class 3 10%
Traffic Class 4 40%
Traffic Class 5 15%
Traffic Class 6 10%
Traffic Class 7 10%
<Output Truncated>
Revision 0919 12 - 40
Policing
Revision 0919 12 - 41
Rate Limiting
• Rate limiting enforces bandwidth on inbound traffic at a port
• ICX supports the following types of rate limiting:

– Port-based fixed rate limiting
• Strict limits on traffic into a port based on bytes per second
– Broadcast, unknown unicast and multicast (BUM) rate limiting

• Strict limits on bytes or packets of each type of BUM traffic
– Traffic policy ACL-based rate limiting1

• Fixed rate – Strict bandwidth limit with exceeding traffic dropped or remarked to lowest priority
• Dynamic rate – Flexible bandwidth limit allowing periodic bursts above the limit
Footnote 1: Traffic policy ACL-based rate limiting is a complex topic and therefore are
too advanced for this course. It is only referenced here to make you aware of the
capability.
Revision 0919 12 - 42
Port-based Fixed Rate Limiting
• Allows configuration of maximum limit of traffic on an interface
• Traffic exceeding configured limit is dropped
• Applies to inbound traffic on a port
• Traffic is measured in kilobits per second (kbps)
• This feature should not be used on uplinks and ports that perform routing or receive
protocol control traffic
You can configure a fixed rate limiting policy on a ports inbound direction only. This
feature allows you to specify the maximum number of bytes in kilobits per second
(kbps), a given port can receive. The port drops bytes that exceed the limit you
specify.
Fixed rate limiting applies to all traffic on the rate limited port. It counts the number
of bytes that a port receives in one second intervals. If the number exceeds the
maximum number you specified when you configured the rate, the port drops all
further inbound packets for the duration of the one-second interval. Unused
bandwidth is not carried over from one interval to the next. Once the one-second
interval is complete, the port clears the counter and re-enables traffic.
NOTE - Ruckus recommends that you do not use fixed rate limiting on ports that
receive route control traffic or Spanning Tree Protocol (STP) control traffic. If the port
drops control packets due to the fixed rate limiting policy, routing or STP can be
disrupted.
All ICX devices support line-rate rate limiting in hardware.
Revision 0919 12 - 43
Port-based Fixed Rate Limiting in Process
• Traffic is only dropped within the one second interval where the configured limit is
exceeded
• At each new
interval the
counter is reset
to zero
• Unused band-
width is not
carried over to
the next
interval
The following figure shows an example of how fixed rate limiting works. In this
example, a fixed rate limiting policy is applied to a port to limit the inbound traffic to
500000 bits (62500 bytes) a second. During the first two one-second intervals, the
port receives less than 500000 bits in each interval. However, the port receives more
than 500000 bits during the third and fourth one-second intervals, and consequently
drops the excess traffic.
The software counts the bytes by polling statistics counters for the port every 100
milliseconds, which provides 10 readings each second. As such, the fixed rate limiting
policy has an accuracy of within 10% of the port's line rate. It is possible then for the
policy to sometimes allow more traffic than the limit you specify, but the extra traffic
is never more than 10% of the port's line rate.
Revision 0919 12 - 44
Port-based Fixed Rate Limiting Configuration
• The rate-limit command is used to define the traffic limit, in kbps, per port

ICX(config-if-e1000-1/1/2)# rate-limit input fixed 5120
– Syntax: [no] rate-limit input fixed average-rate [ burst burst-size ]

• average-rate - Specifies the maximum number of kilobits per second (kbps) 5 Mbps
• burst burst-size – (optional) Specifies the burst size in kilobits
Follow these steps to configure a ports rate limiting policy.

These commands configure a fixed rate limiting policy that allows Ethernet port 1/1/2
to receive a maximum of 5,120 kbps. If the port receives additional bytes during a
given one-second interval, all inbound packets on the port are dropped until the next
one-second interval starts.
When traffic reaches the rate limiting threshold, Traffic Domain 2 (TD2) sends
traditional pause or Priority Flow Control (PFC) frames, depending on the flow-control
configuration. When PFC is enabled, TD2 transmits PFC for all priorities mapped to
the lossless priority group that reaches the XOFF limit (TD2 chip limitation).
You can enable rate limiting on static LAG only
• You cannot enable rate limiting on other types of LAG
• You can configure rate limiting on individual ports of the LAG
• You cannot configure rate limiting on the LAG itself
LAG configuration example:
ICX(config)# lag blue static id 1
ICX(config-lag-blue)# ports 1/1/12 to 1/1/15
LAG blue deployed successfully!
ICX(config-lag-blue)# rate-limit input fixed ethernet 1/1/12
10240
Revision 0919 12 - 45
Rate Limiting BUM Traffic
• Limits the number of BUM packets or bytes received each second on a port
– The kbps option determines if the num represents packets or kbps
– Limit broadcast traffic

Limits to 500
ICX(config-if-e1000-1/1/10)# broadcast limit 500 kbps kbps
• Syntax: [no] broadcast limit num [ kbps ]
– Limit unknown unicast traffic

Limits to 100
ICX(config-if-e1000-1/1/10)# unknown-unicast limit 100 packets
• Syntax: [no] unknown-unicast limit num [ kbps ]
– Limit multicast traffic

ICX(config-if-e1000-1/1/10)# multicast limit 40000 kbps
• Syntax: [no] multicast limit num [ kbps ]
Ruckus ICX devices can forward all flooded traffic at wire speed within a VLAN.
However, some third party networking devices cannot handle high rates of broadcast,
unknown unicast, and multicast (BUM) traffic.
If high rates of traffic are being received by the device on a given port of that VLAN,
you can limit the number of BUM packets or bytes received each second on that port.
This can help to control the number of such packets or bytes that are flooded on the
VLAN to other devices.
Ruckus ICX devices support byte-based and packet-based BUM rate limiting.
NOTE - BUM rate-limiting is not supported on PE ports in an SPX environment.
Revision 0919 12 - 46
Rate Shaping
• Rate shaping controls bandwidth of outbound traffic
• Smooths excess and bursting traffic before sending out a port
• Excess traffic is stored in buffers until bandwidth is available
• Prevents exceeding connected device limits
• Ruckus supports shaping from 128 kbps up to the interface line rate
Outbound rate shaping is a port-level feature that is used to shape the rate and
control the bandwidth of outbound traffic on a port.
Rate shaping smooths excess and bursting traffic to the configured maximum limit
before it is sent out on a port. Packets are stored in available buffers and then
forwarded at a rate no greater than the configured limit. This process provides for
better control over the inbound traffic of neighboring devices.
The following apply when configuring outbound rate shaping:
• Outbound rate shaping can be configured only on physical ports, not on virtual
or loopback ports.
• Ruckus ICX devices have one global rate shaper for a port and one rate shaper
for each port priority queue. Rate shaping is done on a single-token basis,
where each token is defined to be 1 byte.
• When outbound rate shaping is enabled on a port on an IPv4 device, the port
QoS queueing method (qos mechanism ) will be strict mode. This applies to IPv4
devices only. On IPv6 devices, the QoS mechanism is whatever method is
configured on the port, even when outbound rate shaping is enabled.
• You can configure a rate shaper for a port and for the individual priority queues
of that port. However, if a port rate shaper is configured, that value overrides
the rate shaper value of a priority queue if the priority queue rate shaper is
greater than the rate shaper for the port.
• You can configure rate shaping on individual ports of the link aggregation group
(LAG). You cannot configure rate shaping on the LAG itself.
Revision 0919 12 - 47
Rate Shaping Configuration
• The rate-limit output command is used to apply configuration to an interface
– To configure the maximum rate for a port:

ICX(config-if-e1000-1/1/2)# rate-limit output shaping 1300
Outbound Rate Shaping on Port 1/1/2 Config: 1300 Kbps, Actual: 1304 Kbps
– To configure the maximum for a priority queue:

ICX(config-if-e1000-1/1/2)# rate-limit output shaping 500 priority 7
Outbound Rate Shaping on Port 1/1/2 for Priority 7
Config: 500 Kbps, Actual: 500 Kbps
– Verify configuration:
ICX # show rate-limit output-shaping
Outbound Rate Shaping Limits in Kbps:
Port PortMax Prio0 Prio1 Prio2 Prio3 Prio4 Prio5 Prio6 Prio7
1/1/2 1304 - - - - - - - 500
Follow these steps to configure outbound rate shaping on an Ethernet link.

1. Enter interface configuration mode.
2. Configure the maximum rate at which outbound traffic is sent out on a port.
device(config-if-e1000-1/1/2)# rate-limit output shaping
1300
Outbound Rate Shaping on Port 1/1/2 Config: 1300 Kbps,
Actual: 1304 Kbps
3. Configure the maximum rate at which outbound traffic is sent out on a port
priority queue.
device(config-if-e1000-1/1/2)# rate-limit output shaping 500
priority 7
Outbound Rate Shaping on Port 1/1/2 for Priority 7
Config: 500 Kbps, Actual: 500 Kbps
4. Verify the configuration.

device# show rate-limit output-shaping
Outbound Rate Shaping Limits in Kbps:
Port PortMax Prio0 Prio1 Prio2 Prio3 Prio4 Prio5 Prio6 Prio7
1/1/2 1304 - - - - - - - 500
Revision 0919 12 - 48
Module Summary
– Define the elements that make up Quality of Service (QoS)
– Describe QoS classification methods at both Layer 2 and Layer 3
– Explain QoS switch queues and weighting
– Differentiate between the different methods of QoS queue scheduling
– Describe the difference between rate limiting and rate shaping
Revision 0919 12 - 49
End of Module 12:

Traffic Management
Revision 0919 12 - 50
ICX 200 IP Multicast
Module 13:
IPv4 Multicast
Module Objectives
– Explain Layer 2 and Layer 3 (IPv4) multicast addressing
– Discuss and Configure Protocol Independent Multicast (PIM)

• Independent Group Management Protocol (IGMP) query processing and PIM message generation
• Dense Mode
• Sparse Mode
Multicast Addressing Overview
IP Addressing - Packet Types
• IPv4 networks support three types of packets:

– Unicast: Sent from a single source to a single destination address
– Broadcast: Sent from a single source to all destination addresses
– Multicast: Sent from a single source to a specific group of destinations
• By default, not forwarded between subnets by routers
Multicast Traffic
Source
Nodes Nodes
Nodes
In multicast environments, hosts receiving the multicast traffic respond using unicast
back to the single source.
Multicast traffic is not always aware of which hosts on the network that are going to
join the group. Thus, multicast uses UDP (connectionless) rather than TCP.
Routers do not forward multicast by default, it must be enabled.
Layer-2 switches flood the packets by default.
Multicast IP Addressing
• Network devices must have a way to distinguish multicast from other types of traffic
• At L3, Class D IP addresses (224.0.0.0–239.255.255.255) are reserved for multicast

– The first four bits of a multicast IP address are always 1110, making them easily distinguishable from other
types of traffic
• Specific Class D addresses are reserved for different purposes

– Examples of specific IP address reservations:
• 224.0.0.1 – all systems on a subnet
• 224.0.0.2 – all routers on a subnet
• 224.0.0.5 – all OSPF routers
• 224.0.0.9 – all RIPv2 routers
• 224.0.0.13 – PIMv2
• 224.0.0.251 – Multicast DNS (mDNS)
IP Class D addresses are used for identifying and routing multicast traffic. The address
range of 224.0.0.0/4 is used for this purpose. This allows for more than 1 million
unique multicast IP addresses. These addresses are easy to identify because the first
four bytes of the IP address will always begin with 1110.
The Internet Assigned Numbers Authority (IANA) has several reserved IPv4 multicast
addresses to be used for specific purposes. Some of the more well known reserved
addresses are listed here.
The multicast in the range of 224.0.0.0 – 224.0.0.255 is reserved for the use of
routing, topology discovery and maintenance protocols. Multicast destinations in this
range will not be forwarded by a multicast router.
Multicast MAC Addressing
• Multicast addresses are recognizable to Layer-2 devices because each one is mapped to a
MAC address
• The first 24 bits of that MAC address are a specific OUI - 0100.5e, and the 25th bit is always
0
• The lower 23 bits are copied from the lower 23 bits of the multicast IP address
• This creates the situation where there are 32 multicast IP addresses for each multicast
MAC address
Because 5 bits are lost in the address translation, MAC addresses could match 32
different multicast IP addresses. Therefore, the hosts inspect multicast frame that has
the MAC address of the multicast source of the group it has joined, regardless of
which IP address the frame is traveling toward. The host then inspects the destination
IP address to verify that the IP multicast address is intended for a joined multicast
group. If not, the packet is discarded.
Internet Group Management

Protocol (IGMP)
Internet Group Membership Protocol (IGMP)
Overview
• Dynamic registration of interested hosts into multicast group is performed by IGMP
– Multicast flows are forwarded into LANs with registered members
• Three versions of IGMP are available and are supported by ICX switches
– IGMP v1 is defined in RFC 11121
– IGMP v2 is defined in RFC 2236 (Default)
– IGMP v3 is defined in RFC 3376
• IGMP v2 is enabled by default

– You must enable IGMP v3 globally or per interface
Footnote 1: IGMP version 1, due to it’s limitations, is rarely used in todays networks
and will not be covered with the detail of the IGMP versions 2 and 3 in this course.
When a Layer 2 device processes a multicast packet, by default, it broadcasts the
packets to all ports except the incoming port of a VLAN. Packets are flooded by
hardware without going to the CPU. This behavior causes some clients to receive
unwanted traffic.
IGMP snooping provides multicast containment by forwarding traffic to only the ports
that have IGMP receivers for a specific multicast group (destination address). A device
maintains the IGMP group membership information by processing the IGMP reports
and leave messages, so traffic can be forwarded to ports receiving IGMP reports.
In ICX switch supports IGMV v1/v2/v3 and IGMP v2 is enabled by default.
An IPv4 multicast address is a destination address in the range of 224.0.0.0 to
239.255.255.255. Addresses of 224.0.0.X are reserved. Because packets destined for
these addresses may require VLAN flooding, devices do not snoop in the reserved
range. Data packets destined to addresses in the reserved range are flooded to the
entire VLAN by hardware, and mirrored to the CPU. Multicast data packets destined
for the non-reserved range of addresses are snooped. A client must send IGMP
reports in order to receive traffic.
IGMP Version Comparisons
IGMP Message Types Features New features over previous

Version version
IGMP v1 1. Membership Query Host membership Requests -
2. Membership Report Router Queries
IGMP v2 1. Membership Query group-specific router query 1. Queries to specific group

2. Membership 2. Max Response Time (query)
Reportv11 3. Host leave request
3. Membership 4. Querier election mechanism2
Reportv2
4. Leave group
IGMP v3 1. Version 3 Host source request 1. Host source filtering4

membership query New multicat (All IGMPv3 2. Response Interval for report
2. Version 3 Routers) address 224.0.0.223 management
membership report
3. Membership tracking and fast leave
Footnote 1: for backwards compatibility to IGMPv1

Footnote 2: Allows for the election of only one router in a redundant LAN segment to
be selected to send queries to that segment
Footnote 3: All IGMPv3 Hosts send reports to 224.0.0.22 “All IGMPv3 Routers”
instead of the target group address as in IGMPv1/v2
• All version 3 routers listen to this address
• Hosts do not listen to this address
• They can’t hear responses from other hosts - No Response Suppression
• All hosts on the segment respond to queries
• Response Interval created to allow administrators to manage the frequency of
response reports.
Footnote 4: The host can supply a list of IP addresses representing multicast sources
from which it will accept traffic (called the include list). The host can also supply a list
of IP addresses representing multicast sources from which it will not accept traffic
(called the exclude list)
IGMP Snooping
• IGMP Snooping allows a switch to identify hosts that request multicast traffic and limit
forwarding of multicast addresses to specific ports
– Enabled by default
• An IGMP v2 switch examines contents of every IGMP message to determine which ports to
forward the traffic
• IGMP v3 switch examines only 224.0.0.22 group messages not general IGMP data traffic
– Lowers CPU utilization
IGMP snooping can be enabled on some VLANs or on all VLANs. Each VLAN can be
independently configured to be a querier or non-querier and can be configured for
IGMP v2 or IGMP V3. In general, the ip multicast commands apply globally to all
VLANs except those configured with VLAN-specific multicast commands. The VLAN-
specific multicast commands supersede the global ip multicast commands.
IGMP snooping can be configured for IGMP v2 or IGMP v3 on individual ports of a
VLAN. An interface or router sends the queries and reports that include its IGMP
version specified on it. The version configuration only applies to sending queries.
Lower versions cannot recognize and process higher version reports. Higher versions
can recognize and process both lower and higher versions.
To avoid version deadlock, an interface retains its version configuration even when it
receives a report with a lower version.
With IGMP v1/v2, the switch listens to the IGMP conversations between hosts and
switches. This requires extra CPU resources in the switch to identify and intercept all
IGMP packets flowing between routers and hosts. This can impact the switch’s
performance.
When all clients and switches employ IGMP v3, only multicast address 224.0.0.22 is
used for group messages and therefor minimizes CPU utilization.
Revision 0919 13 - 10
IGMP Querying
• Defines IGMP querying behavior of an ICX device
• Active
– In general, this mode should only be used in Layer 2 switched network with no multicast routers
• In a Layer 2 switched environment, only one device should be configured as Active, others should be Passive
• Active switch should be closest to the multicast source
– The Ruckus device sends IGMP queries to identify multicast groups
– Populates IGMP table from membership reports it receives
• Passive
– VLANs on Ruckus device do not send queries
– Received queries are flooded to the VLAN
– Forwards membership reports to router ports which receive queries
An IGMP snooping-enabled Ruckus ICX device can be configured as a querier (active)

or non-querier (passive). An IGMP querier sends queries; a non-querier listens for
IGMP queries and forwards them to the entire VLAN. VLANs can be independently
configured to be queriers or non-queriers. If a VLAN has a connection to a PIM-
enabled port on another router, the VLAN must be configured as a non-querier. When
multiple IGMP snooping devices are connected together, and there is no connection
to a PIM-enabled port, one of the devices must be configured as a querier. If multiple
devices are configured as queriers, after these devices exchange queries, then all
except the winner stop sending queries. The device with the lowest address becomes
the querier. Although the system will work when multiple devices are configured as
queriers, Ruckus recommends that only one device (preferably the one with the
traffic source) is configured as a querier.
The non-queriers always forward multicast data traffic and IGMP messages to router
ports which receive IGMP queries or PIM hellos. Ruckus recommends that you
configure the device with the data traffic source (server) as a querier. If a server is
attached to a non-querier, the non-querier always forwards traffic to the querier
regardless of whether there are any clients on the querier.
NOTE – In a topology of one or more connecting devices, at least one device must be
configured as active. Otherwise, none of the devices can send out queries, and traffic
cannot be forwarded to clients.
Revision 0919 13 - 11
IGMP Configuration
Revision 0919 13 - 12
Enabling IGMP
• To globally enable
ICX(config)# ip multicast
– Syntax: [no] ip multicast [ active | passive ]
• Default: passive
• To globally identify the IGMP version on an ICX device, enter the ip multicast command
ICX(config)# ip multicast version 3
– Syntax: [no] ip multicast version [ 2 | 3 ]
• Default: version 2
• To specify the IGMP mode for a VLAN, enter a command such as the following:
ICX(config-vlan-10)# multicast active
– Syntax: [no] multicast { active | passive }
• Default: Globally configured mode
You can configure active or passive IGMP modes on the Ruckus device. The default
mode is passive. The default can be changed with the ip multicast active global
configuration command.
The default global IGMP version on an ICX switch is v2 and this version is inherited by
all interfaces. The global version can be changed with ip multicast version command
in the global configuration context. If changed, this version will be inherited by all
interfaces. As long as those interface do not have a different version already explicitly
configured.
The IGMP mode can be configured at the VLAN level to override the global configured
mode using the multicast active or multicast passive command in the VLAN
configuration context.
Revision 0919 13 - 13
Enabling IGMP (cont.)
• To specify the IGMP version for a VLAN:

ICX(config-vlan-10)# multicast version 2
– Syntax: [no] multicast version [ 2 | 3 ]
• Default: Globally configured version
• To specify the IGMP version for individual ports in a VLAN:

ICX(config-vlan-10)# multicast port-version 3 ethernet 1/2/4 to 1/2/6
– Syntax: [no] multicast port-version { 2 | 3 } { [ ethernet unit/slot/port [ to unit/slot/port ] ... ] [ lag lag-id [
to lag-id ] ... ] }
• To configure static groups to specific ports:

ICX(config-vlan-10)# multicast static-group 224.1.1.1 count 2 ethernet
1/1/3 ethernet 1/1/5 to 1/1/7
– Syntax: [no] multicast static-group ipv4-address [ count num ] { [ ethernet unit/slot/port [ to
unit/slot/port ] ... ] [ lag lag-id [ to lagid ] ... ] }
Even if the IGMP mode and version have been configured globally, specifying the
mode and version for a VLAN overrides the global settings.
You can specify an IGMP version for a VLAN. If no IGMP version is specified on a
VLAN, then the globally-configured IGMP version is used.
You can specify the IGMP version for individual ports in a VLAN. You can specify a list
of ports, a range of ports, or a combination of lists and ranges. If an IGMP version is
specified for individual ports, those ports use that version, instead of the VLAN
version.
A snooping-enabled VLAN cannot forward multicast traffic to ports that do not
receive IGMP membership reports. If clients cannot send reports, you can configure a
static group which applies to specific ports. The static group allows packets to be
forwarded to the static group ports even though they have no client membership
reports.
Revision 0919 13 - 14
Configuring IGMP Timers
• To define the IGMP active query interval:

ICX(config)# ip multicast query-interval 30
– Syntax: [no] ip multicast query-interval interval
• Default: 125 seconds
• To define an IGMP membership time:

ICX(config)# ip multicast age-interval 70
– Syntax: [no] ip multicast age-interval [ vlan vlan-id ] interval
• To define the IGMP maximum response time:

ICX(config)# ip multicast max-response-time 5
– Syntax: [no] ip igmp max-response-time interval
The ip multicast query-interval period defines how often a switch will query an
interface for group membership when the mode is set to active. Possible values are
10-3600 seconds and the default value is 125 seconds.
The ip multicast age-interval command specifies the time that group entries can
remain in an IGMP group table on a specific VLAN or on all VLANs. Enter a value from
20 through 2600 seconds. When multiple devices are connected, they must all be
configured for the same age interval, which must be at least twice the length of the
query interval, so that missing one report does not stop traffic.
The ip multicast max-response-time command defines the maximum number of
seconds that a client can wait before it replies to the query sent by the router.
Possible values are 1 – 25. The default is 10.
Revision 0919 13 - 15
IGMPv3 Membership Tracking and Fast Leave
• IGMPv3 provides membership tracking and fast leave capability

– When a client leaves a group, group-specific queries are sent to see if other clients on that interface need
the data stream of the client who is leaving
– All IGMPv3 clients are required to respond
– If there are no clients for the group, the traffic immediately stops on the interface
– Requires the entire VLAN be configured for IGMPv3 (No IGMPv2 clients)
• To enable the tracking and fast leave feature on a VLAN:

ICX(config-vlan-10)# multicast tracking
– Syntax: [no] multicast tracking
IGMP v3 gives clients membership tracking and fast leave capability. IGMP v3 requires
every client to respond to queries, allowing the device to track all clients. When
tracking is enabled, and an IGMP v3 client sends a leave message and there is no
other client, the device immediately stops forwarding traffic to the interface. This
feature requires the entire VLAN be configured for IGMP v3 with no IGMP v2 clients.
If a client does not send a report during the specified group membership time (the
default is 260 seconds), that client is removed from the tracking list.
Every group on a physical port keeps its own tracking record. However, it can only
track group membership; it cannot track by (source, group). For example, Client A and
Client B belong to group1 but each receives traffic streams from different sources.
Client A receives a stream from (source_1, group1) and Client B receives a stream
from (source_2, group1). The device still waits for the configured leave-wait-time
before it stops the traffic because these two clients are in the same group. If the
clients are in different groups, then the waiting period is not applied and traffic is
stopped immediately.
Revision 0919 13 - 16
IGMPv2 Leave Wait Time
• By default, when an IGMPv2 client leaves a group, group-specific queries are sent to see if
other clients on that interface need the data stream of the client who is leaving
– If no client responds, the device waits a few seconds before it stops the traffic
• To adjust the amount of time to wait before stopping the traffic:

ICX(config)# ip multicast leave-wait-time 3
– Syntax: [no] ip multicast leave-wait-time num
In IGMP v2, only one client on an interface needs to respond to a router's queries.
This can leave some clients invisible to the router, making it impossible to track the
membership of all clients in a group. When a client leaves the group, the device sends
group-specific queries to the interface to see if other clients on that interface need
the data stream of the client who is leaving. If no client responds, the device waits a
few seconds before it stops the traffic. You can configure the wait time using the ip
multicast leave-wait-time command.
Revision 0919 13 - 17
IGMPv2 Fast Leave
• IGMPv2 can be configured for fast leave capability

– When an IGMPv2 client leaves a group, the device immediately stops the traffic to the client port
– No group-specific queries are sent
– Should only be configured on a VLAN where only one client is present on each interface
• To enable the IGMPv2 fast leave feature on a VLAN:

ICX(config-vlan-20)# multicast fast-leave-v2
– Syntax: [no] multicast fast-leave-v2
When a device receives an IGMP v2 leave message, it sends out multiple group-
specific queries. If no other client replies within the waiting period, the device stops
forwarding traffic. When fast leave version 2 is configured, and when the device
receives a leave message, it immediately stops forwarding to that port. The device
does not send group-specific queries. When fast leave version 2 is configured on a
VLAN, you must not have multiple clients on any port that is part of the VLAN. In a
scenario where two devices connect, the querier device should not be configured for
fast leave version 2 because the port might have multiple clients through the non-
querier. The number of queries, and the waiting period (in seconds) can be
configured.
Revision 0919 13 - 18
Protocol Independent Multicast

(PIM)
Revision 0919 13 - 19
Protocol Independent Multicast (PIM)
• PIM is a routing protocol used for forwarding multicast traffic between IP subnets or
network segments
• As the name implies, PIM works independently of any particular routing protocol
– PIM does not create and maintain a multicast routing table
• It uses the unicast routing table, which, since it can be populated by more than one protocol, is also
protocol independent
• There are two operating modes for PIM
– Dense mode - suitable for densely populated multicast groups, primarily in the LAN environment (RFC
3973)
– Sparse mode - suitable for sparsely populated multicast groups with the focus on WAN (RFC 2362)
PIM was introduced to simplify some of the complexity of the routing protocol at the
cost of additional overhead tied with a greater replication of forwarded multicast
packets. PIM builds source-routed multicast delivery trees and employs reverse path
check when forwarding multicast packets.
PIM uses the IP routing table instead of maintaining its own, thereby being routing
protocol dependent.
There are two modes in which PIM operates: Dense and Sparse. The Dense Mode is
suitable for densely populated multicast receivers, primarily in the LAN environment.
The Sparse Mode is suitable for sparsely populated multicast receivers with the focus
on WAN.
Revision 0919 13 - 20
Protocol Independent Multicast (PIM) (Cont.)
• The ICX device supports only PIM v2

– PIM DM v2 sends messages to the multicast address 224.0.0.13 (ALL-PIM-ROUTERS) with protocol
number 103
• Modification of the following parameters are available:1
– Neighbor timeout
– Hello timer
– Prune timer
– Prune wait timer
– Graft retransmit timer
– Inactivity timer
Footnote 1: Default values for these parameters work well in most network
environments. In some cases it is necessary to adjust these based on certain
accommodations needed.
Revision 0919 13 - 21
PIM Global Configuration Commands
• Additional global configuration:

device(config-pim-router)# nbr-timeout 360
• Value from 3 through 65535 seconds, and it must not be less than 3.5 times the hello timer. Default value is 105.
device(config-pim-router)# hello-timer 120

• The hello timer interval can be set from 10 through 3600 seconds, and the default is 30.
device(config-pim-router)# prune-timer 90
• The prune timer range is from 60 through 3600 seconds. The default is 180.
device(config-pim-router)# prune-wait 1
• Value from 0 through 30 seconds. The default is 3.
device(config-pim-router)# graft retransmit-timer 90

• Range is from 60 through 3600 second. The default is 180.
device(config-pim-router)# inactivity-timer 90
• The value of the inactivity timer can be set from 60 through 3600 seconds. The default is 180.
Many PIM options can be modified from their default values in global configuration
mode. PIM global parameters come with preset values. The defaults work well in
most networks, but you can modify the following parameters if necessary:
• Neighbor timeout—Neighbor timeout is the interval after which a PIM device
will consider a neighbor to be absent.
• Hello timer – The hello timer defines the interval at which periodic hellos are
sent out PIM interfaces.
• Prune timer – The prune timer defines how long a PIM device will maintain a
prune state for a forwarding entry. A prune state is maintained until the prune
timer expires or a graft message is received for the forwarding entry.
• Prune wait timer – The prune wait timer allows you to configure the amount of
time a PIM device will wait before stopping traffic to neighbor devices that do
not want the traffic. A prune wait value of zero causes the PIM device to stop
traffic immediately upon receiving a prune message.
• Graft retransmit timer – The graft retransmit timer defines the interval between
the transmission of graft messages. A graft message is sent by a device to cancel
a prune state. When a device receives a graft message, the device responds
with a Graft Ack (acknowledge) message. If this Graft Ack message is lost, the
device that sent the graft message will resend it.
• Inactivity timer – The device deletes a forwarding entry if the entry is not used
to send multicast packets. The PIM inactivity timer defines how long a
forwarding entry can remain unused before the device deletes it.
Revision 0919 13 - 22
PIM Dense
Revision 0919 13 - 23
PIM Dense Mode (PIM-DM)
• This mode works on the premise that there are multicast stream listeners throughout the
entire network
• PIM-DM builds its multicast tree by flooding traffic from the source to all dense mode
routers in the network
– This will propagate unnecessary traffic for a short time
• Each router checks to see if it has active group members waiting for the data
– If so, the router remains quiet and lets the traffic flow
– If no hosts have registered for that group, the router sends a prune message toward the source, and that
branch of the tree is “pruned” off to stop unnecessary traffic flow
• Trees built with this flood and prune method are called source trees1
• Reverse path forwarding (RPF) checks are used to ensure loop-free topology
Footnote 1: A source tree is method of establishing a branching path throughout the

domain with the source of a multicast stream as the root. As multicast streams flow
from the root, it may branch our from each router until a path to all receivers is
established. To maintain the source tree, each PIM-DM router will maintain a source,
group (S,G) table. Entries in this table track the IP address of the multicast source (S)
and the multicast group address (G). A multicast group may be generated by multiple
sources, in this case there may be multiple (S,G) entries for the group.
Revision 0919 13 - 24
Reverse Path Forwarding (RPF)
• Ensures loop-free forwarding of multicast packets
• Uses unicast routing table to compare against source of the multicast stream
– Multicast flow is reviewed on ingress
– The port and source address are compared against the unicast routing table
• If the source of the stream matches a routing table entry and the port associated with the route entry, the RPF
check passes and the stream is forwarded out other multicast interfaces
• If it does not match, the stream is dropped1
Source
• RPF is applicable to both PIM modes - Dense and Sparse

Footnote 1: Depending on the multicast routing protocol being used, this may also
result in a “prune” message being sent to the forwarding router. Some multicast
routing protocols use prune messages to instruct the sending router to cease sending
multicast traffic from that source.
Revision 0919 13 - 25
PIM-DM Overview - Flooding
• Initial flooding
– Multicast traffic that passes

RPF check continues to be
flooded through the entire
domain
– Interfaces where RPF check

fails discard packets in the
multicast stream
– Each router creates Source,

Group (S,G) state
Multicast traffic sent by the source is flooded throughout the entire network. RPF
ensures proper traffic flow by avoiding loops. RPF is applied to every multicast packet
received by all routers.
As each router receives the multicast traffic via its RPF interface (the interface in the
direction of the source), it forwards the multicast traffic to all of its PIM-DM
neighbors. This causes traffic to arrive at some routers multiple times via a non-RPF
interface. This is normal for the initial flooding of data and are corrected by the
normal PIM-DM pruning mechanism.
Revision 0919 13 - 26
PIM-DM Overview – Pruning
• Pruning unwanted traffic
– Prune messages are sent to instruct the

sender to stop forwarding the stream
– Prunes are sent from:

• Routers with no receivers attached
• Router interfaces where RPF check fails
In the diagram, two of the routers receive multicast traffic on a non-RPF interface
from a neighboring router, which results in a prune messages sent between them.
The routers with no receivers attached also send prune messages toward the source,
via the RPF interface.
PIM-DM prunes are sent to neighbor routers toward the source on the RPF interface
to stop the flow of unwanted traffic:
• Prunes are sent when the router has no downstream members that need the
multicast traffic.
• Prunes are also sent to shut off the flow of multicast traffic that is received on
the wrong interface (non-RPF interfaces).
• For equal cost paths, router vendors each define their own proprietary method
of pruning down to a single path. Possible methods could be hash-based,
source-based, based on the IP address of the next-hop routers, or the IP
addresses of the receiving interfaces.
Revision 0919 13 - 27
PIM-DM Overview – Prune and Flood
• Once pruning process completes, • Every 3 minutes, by default, the flood and
multicast traffic only flows to active prune process repeats
receivers
After multicast traffic has been pruned off unnecessary links, this results in a Shortest
Path Tree (SPT) being built from the source to the receiver. At this point, multicast
traffic is no longer flowing to all routers in the network. However, the (S, G) state still
remains in all routers. This (S, G) state will remain until the source stops transmitting.
In PIM-DM, a prune state expires after three minutes. A refresh state message is then
sent up the tree to verify if the source is still active. If it does not receive a response,
the (S, G) entry times out and is dropped.
Revision 0919 13 - 28
PIM Dense
Configuration Example
Revision 0919 13 - 29
PIM Dense Configuration Example
• To configure an ICX Layer 3 router for PIM Dense, perform the following tasks:
– Globally enable PIM

ICX(config)# router pim
– Enter interface configuration mode

ICX(config-pim-router)# interface ethernet 1/1/3
– Enter the IP address for the interface (if not already present)
ICX(config-if-e10000-1/1/3)# ip address 10.9.9.9/32
– Configure PIM DM on the interface

ICX(config-if-e10000-1/1/3)# ip pim
Revision 0919 13 - 30
PIM Sparse
Revision 0919 13 - 31
PIM Sparse Mode (PIM-SM)
• Sparse mode works on the premise that multicast receivers are not positioned in all areas
of the network
• One router is designated as the Rendezvous Point (RP) and should be located close to the
source in the network
– Receiver routers generate PIM join messages, based on received IGMP Membership Reports, to the RP to
identify which multicast groups they are interested in
– Source routers send register messages to the RP to identify which groups they are sending
– Multicast traffic from all source routers is sent to the RP for redistribution to the receivers
– This mode is referred to as a shared tree, because initially all source traffic flows through the RP
Source Receiver
Rendezvous Point
Multicast Packets IGMP Membership Report

PIM Register Message PIM Join Message
Footnote 1: A shared tree is somewhat similar to the source tree, except that instead
of being rooted from the source and growing towards the receivers, it is rooted at a
common point, the Rendezvous Point (RP). Because the source is not necessarily
known to receivers, a (*,G) notation is used to maintain the multicast table between
receivers and the RP. A source tree is maintained only between the multicast source
and the RP.
The tree from the RP to the group members is a subset of the main tree. When
members join a group, the local router forwards the membership report toward the
RP. Each router along the way adds that branch to the shared tree.
Pruning is performed when a group member is removed from the group. Only routers
with active group members join the tree.
Revision 0919 13 - 32
Sender Registration
• The router local to the source is responsible for registering the source with the RP and
building a tree between them
– A PIM router receives multicast traffic

from the source
– A register message is sent from the

source router to the RP
• It encapsulates the multicast
data and is unicast to the RP
– The RP sends an (S, G) join back toward

the source network
• This (S, G) state is created in all
the routers along the Source Tree
– Shortest Path Tree, from source to RP
Revision 0919 13 - 33
Receivers Join the Shared Tree
• A PIM router receives an IGMP Membership

Report for multicast group address (G)
• The router obtains the IP address

of the RP for group address (G) from:
– The Bootstrap Router (BSR)
– Statically defined RP
• It sends a (*,G) join packet for

the group toward the RP
• This (*, G) join packet travels to the RP,

building a branch of the shared tree at each
router along the way—extends from the RP
to the last router directly connected to the
receiver
Revision 0919 13 - 34
Combining Trees
• The source tree and shared tree

are joined at the RP
• Traffic flows through the newly

created tree to the member
receivers
• Each PIM router will maintain an

incoming and outgoing port list for
each multicast group it is passing
Revision 0919 13 - 35
Shortest Path Tree
• At configured thresholds routers examine

source to determine shortest path
– Default SPT-threshold is 1 packet
• Sends PIM Join message to the

router closest to the source
Revision 0919 13 - 36
Shortest Path Tree Transition
• Multicast traffic from the source transitions to the shortest routing path between the
source and the client
• PIM Prune messages sent along previous

path to stop multicast flow
• Each PIM router will update their

incoming and outgoing port lists as
a result of the prune and SPT change
Revision 0919 13 - 37
Multicast Inbound/Outbound Interfaces
• Each PIM-Sparse router manages multicast flows using inbound (IIF) and outbound
interface (OIF) tables for each multicast group address
RP
• IIF is the port facing the

source of the multicast
traffic stream e1/1/9
e1/1/1
Source e1/1/22
e1/1/4 e1/1/33 IIF OIF
• OIF is the port, or list of IIF OIF
e1/1/7 e 1/1/33 e 1/1/7
e 1/1/1 e 1/1/9
ports, facing receivers
of the multicast stream IIF OIF
e1/1/14
e 1/1/22 e 1/1/4 IIF OIF
e1/1/44
e 1/1/14 e 1/1/44
Traffic Flow
Receiver
Revision 0919 13 - 38
PIM Sparse
Configuration Example
Revision 0919 13 - 39
Example PIM Sparse Configuration
• To configure an ICX Layer 3 router for PIM Sparse, perform the following tasks:
– Configure the following global parameter:
• Enable the PIM Sparse mode of multicast routing
– Configure the following interface parameters:

• Configure an IP address on the interface
• Enable PIM Sparse
• Define PIM domain borders
– Configure the following PIM Sparse global parameters:

• Identify the Layer 3 switch as a candidate PIM Sparse Bootstrap Router (BSR), if applicable
• Identify the Layer 3 switch as a candidate PIM Sparse Rendezvous Point (RP), if applicable
• Specify the IP address of the RP (if you want to statically select the RP)
To enhance overall network performance, the ICX device uses the RP to forward only
the first packet from a group source to the group’s receivers. After the first packet,
the ICX device calculates the shortest path between the receiver and source (the
Shortest Path Tree, or SPT) and uses the SPT for subsequent packets from the source
to the receiver. The ICX device calculates a separate SPT for each source-receiver pair.
Revision 0919 13 - 40
Enabling PIM
• To configure basic global PIM Sparse parameters, enter commands such as the following
on each Layer 3 switch within the PIM Sparse domain1
• To enable PIM Sparse mode on an interface, enter commands such as the following:
ICX(config-if-e10000-1/1/2)# ip address 207.95.7.1 255.255.255.0
ICX(config-if-e10000-1/1/2)# ip pim-sparse
Footnote 1: Enabling PIM globally allows you to configure either dense or sparse
mode on interfaces. Dense and Sparse mode however cannot be run simultaneously.
Revision 0919 13 - 41
PIM Borders
• Defining an interface as a PIM border defines the edge of the PIM-Sparse Domain
• Prevents the following messages from being sent or received on an interface:

– Bootstrap
– Candidate-RP
– Auto-RP
• Enabled with ip pim border command per interface

ICX(config-if-e1000-e1/1/2) ip pim border
Revision 0919 13 - 42
Configuring BSR and RP Candidates
• For PIM Sparse mode to work you need to identify at least one Layer 3 switch interface as
a candidate for a boot strap router (BSR) and PIM Sparse Rendezvous Point (RP)
– To configure the Layer 3 switch as a candidate BSR, enter commands such as the following:
ICX(config-pim-router)# bsr-candidate loopback 1 30 255
BSR address: 207.95.7.1, hash mask length: 30, priority: 255
– Enter a command such as the following to configure the Layer 3 switch as a candidate rendezvous point
(RP):
ICX(config-pim-router)# rp-candidate loopback 1
• PIM Sparse mode must be enabled on any interface configured as a BSR or RP candidate
The bsr-candidate command configures the PIM Sparse interface loopback 1 as a BSR
candidate, with a hash mask length of 30 and a priority of 255. The CLI displays a summary of
the applied configuration once the command is executed.
Syntax: [no] bsr-candidate {ethernet unit/slot/port | lag lag-id | loopback num | ve num |
tunnel num} hash-mask-length [priority]
The device will advertise the IP address of the specified interface as a candidate BSR.
The hash-mask-length parameter specifies the number of bits in a group address that are
significant when calculating the group-to-RP mapping. You can specify a value from 1–32.
The priority specifies the BSR priority. You can specify a value from 0 - 255. When the
election process for BSR takes place, the candidate BSR with the highest priority becomes the
BSR. The default is 0.
It is recommended that you use the PIM Sparse protocol’s RP election process so that a
backup RP can automatically take over if the active RP router becomes unavailable. This is
accomplished with the rp-candidate command, followed by the interface to be used.
Revision 0919 13 - 43
RP for Specific Multicast Address Ranges
• Rendezvous Point routers should be placed as close to the multicast source as possible
– Each RP can be configured to only represent multicast groups they are near to
• When a candidate RP is configured, by default, it serves all multicast prefixes

– Seen in running config after defining rp-candidate interface
! Referred to as the
router pim DEFAULT PREFIX
rp-candidate loopback 1 Covers all multicast
rp-candidate add 224.0.0.0 4 addresses from
! 224.x.x.x to 239.x.x.x
– To specify which multicast group addresses an RP will represent, use the rp-candidate add command
ICX(config-pim-router)# rp-candidate add 224.126.0.0 16
• Adding any multicast prefix will automatically remove the default prefix (224.0.0.0 4) from the running config
– To remove an added multicast group address (or a specific group address), use the rp-candidate delete
command
ICX(config-pim-router)# rp-candidate delete 224.126.0.0 16
You can configure the device as a candidate RP with the rp-candidate command. By
default, this command configures the device as a candidate RP for all group numbers
beginning with 224. As a result, the device is a candidate RP for all valid PIM Sparse
group numbers. You can change this by adding or deleting specific address ranges.
To add a group number range for which the device is a candidate RP, use the add
option to explicitly add a range.
ICX(config-pim-router)# rp-candidate add 224.126.0.0 16
The group-addr mask-bits variable specifies the group address and the number of
significant bits in the subnet mask. In this example, the device is a candidate RP for
all groups that begin with 224.126. When you add a range, you override the
default. The device then becomes a candidate RP only for the group address
ranges you add.
To delete a group number range for which the device is a candidate RP, use the delete
option to explicitly remove a range that was previously added.
ICX(config-pim-router)# rp-candidate delete 224.126.0.0
16
This example deletes an address group from the devices for which it is a candidate
RP.
Revision 0919 13 - 44
Consider the following when configuring the RP.

• When the candidate RP is configured, before explicitly specifying the groups
that it serves, the c-rp does, by default, serve all the groups in the PIMSM
multicast range, but this includes all groups beginning with 224.x.x.x all the way
up to 239.x.x.x. This is reflected in the“rp-candidate add 224.0.0.0 4” line
displayed as part of the runtime configs. This entry will be referred to as the
DEFAULT PREFIX
• When any group prefix is explicitly added (and the 224.0.0.0/4 prefix itself can
also be explicitly added through CLI), the default prefix is implicitly removed.
Now, the only groups served by the candidate RP, are the groups that have been
explicitly added.
• All explicitly added groups can be removed using the “delete” option or “no …
add” option. However, once all the explicitly added groups are deleted from the
Candidate RP group prefix list, the default prefix becomes active once more.
This default group prefix CANNOT BE REMOVED.
• It is not possible to punch holes in the group prefix range. For example,
executing rp-candidate add 228.0.0.0/16 and then rp-candidate delete
228.0.1.0/24 is not allowed. This syntax cannot be used to ensure that the rp-
candidate will serve all group prefixes in the 228.0.0.0/16 range except those in
the 228.0.1.0/24 range.
Revision 0919 13 - 45
Defining a Static Rendezvous Point
• A static rendezvous point can be configured
– If configured, the router will use this RP for all multicast group prefixes
– Can be used instead of a Bootstrap Router (BSR)

• If no BSR is present, the static configuration must be applied to all PIM routers in the domain
– Overrides any candidate RPs provided by the BSR, if present
– To statically identify a rendezvous point (RP), use the rp-address command

ICX(config-pim-router)# rp-address 207.95.7.1
If you do not want the RP to be selected by the RP election process but instead you
want to explicitly identify the RP by IP address, use the rp-address command.
If you explicitly specify the RP, the device uses the specified RP for all group-to-RP
mappings and overrides the set of candidate RPs supplied by the BSR.
Revision 0919 13 - 46
Displaying PIM Sparse Details
Revision 0919 13 - 47
PIM Sparse Mode Topology
• Below is the topology that will be used to demonstrate the capabilities of the show
commands available on the Ruckus ICX for multicast routing using PIM-SM
– Client is joined to multicast group 224.1.1.1

– The source is actively sending traffic to
multicast group address 224.1.1.1
– There are two rendezvous points (RP), one
for each of the group address ranges:
• 224.1.1.0/24
• 239.0.1.0/24
– There is a BSR present in the PIM
domain (not shown in topology)
Client-Edge Core-Aggregation Server-Edge
RP RP
Client 244.1.1.0/24 239.0.1.0/24 Source
224.1.1.1
224.1.1.1
The topology used for the demonstrations of the show commands is shown here. In
the examples all focus will be on one multicast stream for group address 244.1.1.1
between the client and server shown. The path for this multicast stream will flow
between the routers shown. In some examples, output will be shown from each
router to display the different information that can be obtained from each router’s
perspective. Others will only be displayed from a single device
Revision 0919 13 - 48
Displaying PIM Neighbors
• Use the show ip pim interface command to display PIM-enabled interfaces

Core-Agg# show ip pim interface
Flags : SM - Sparse Mode v2, DM - Dense Mode v2, P - Passive Mode
---------+---------------+----+---+--------------------------+---+---------+---------------+-------+------+---------+
Interface|Local |Mode|St | Designated Router |TTL|Multicast| Filter | VRF | DR | Override
|Address | | |Address Port|Thr|Boundary | ACL | | Prio | Interval
---------+---------------+----+---+--------------------------+---+---------+---------------+-------+------+---------+
e1/1/18 172.16.241.5 SM Ena Itself 1 None None default 1 3000ms
e1/1/20 172.16.240.5 SM Ena 172.16.240.6 1/1/20 1 None None default 1 3000ms
e1/1/21 172.16.240.13 SM Ena 172.16.240.14 1/1/21 1 None None default 1 3000ms
v4 10.254.4.5 SM Ena 10.254.4.7 1/1/14 1 None None default 1 3000ms
l1 10.254.255.2 SM Ena Itself 1 None None default 1 3000ms
l2 10.255.255.1 SM Ena Itself 1 None None default 1 3000ms
Total Number of Interfaces : 8
Client-Edge Core-Aggregation Server-Edge
RP RP
Client 244.1.1.0/24 239.0.1.0/24 Source
224.1.1.1
224.1.1.1
The show ip pim interface command displays the following information:
Revision 0919 13 - 49
Displaying PIM Neighbors
• Use the show ip pim neighbor command to display neighboring PIM routers
Client-Edge# show ip pim neighbor Client
--------+---------+-------------+--------+---+---------+---------+-----+--------------+-----------+----+
Port |PhyPort |Neighbor |Holdtime|T |PropDelay|Override |Age |UpTime |VRF |Prio
| | |sec |Bit|msec |msec |sec | | |
--------+---------+-------------+--------+---+---------+---------+-----+--------------+-----------+----+
e1/1/19 e1/1/19 172.16.240.5 105 1 500 3000 3 89d 08:35:22 default 1
Client-Edge
<Output Truncated>
Core-Agg# show ip pim neighbor
--------+---------+-------------+--------+---+---------+---------+-----+--------------+-----------+----+
Port |PhyPort |Neighbor |Holdtime|T |PropDelay|Override |Age |UpTime |VRF |Prio Core-Agg
--------+---------+-------------+--------+---+---------+---------+-----+--------------+-----------+----+
e1/1/20 e1/1/20 172.16.240.6 105 1 500 3000 15 89d 08:43:45 default 1
Srvr-Edge
v4 e1/1/14 10.254.4.3 105 1 500 3000 1 91d 04:49:33 default 1
<Output Truncated>
Srvr-Edge# show ip pim neighbor
--------+---------+-------------+--------+---+---------+---------+-----+--------------+-----------+----+
Port |PhyPort |Neighbor |Holdtime|T |PropDelay|Override |Age |UpTime |VRF |Prio
--------+---------+-------------+--------+---+---------+---------+-----+--------------+-----------+----+
v4 e1/1/16 10.254.4.5 105 1 500 3000 15 91d 04:44:58 default 1
Source
<Output Truncated> 224.1.1.1
The show ip pim neighbor command displays the following information:
Revision 0919 13 - 50
Displaying Rendezvous Points
• Use the show ip pim rp-set command to display known RPs in the PIM domain
– Typically, RP information should be the same for all PIM routers in the domain Client
Client-Edge# show ip pim rp-set
Number of group prefixes Learnt from BSR: 2 Client-Edge
Group prefix = 239.0.1.0/24 # RPs: 1 Core-Agg

RP 1: 10.255.250.2 priority=0 age=20 holdtime=150 RP L1:
244.1.1.0/24 10.255.255.1
Srvr-Edge
Group prefix = 224.1.1.0/24 # RPs: 1
RP L1:
RP 1: 10.255.255.1 priority=0 age=20 holdtime=150 239.0.1.0/24 10.255.250.2
Source
224.1.1.1
The show ip pim rp-set command displays the following information:
Revision 0919 13 - 51
Displaying RP for Specific Multicast Group
• Use the show ip pim rp-hash command to display RP information for specific multicast
group prefixes Client
Client-Edge# show ip pim rp-hash 224.1.1.1

RP: 10.255.255.1, v2
Client-Edge
Info source: 10.254.255.1, via bootstrap
Core-Agg# show ip pim rp-hash 224.1.1.1 Core-Agg

RP: 10.255.255.1, v2 RP L1:
RP learned 244.1.1.0/24 10.255.255.1
Info source: 10.254.255.1, via bootstrap from BSR Srvr-Edge
RP L1:
Srvr-Edge# show ip pim rp-hash 224.1.1.1 239.0.1.0/24 10.255.250.2
RP: 10.255.255.1, v2
Info source: 10.254.255.1, via bootstrap
Source
224.1.1.1
The show ip pim rp-hash command displays the following information:
Revision 0919 13 - 52
Displaying the Multicast Cache – Source Router
• The multicast cache (mcache) contains all know multicast source-groups (S,G)
Client
• Use the show ip pim mcache command to display a router’s multicast cache
Srvr-Edge# show ip pim mcache

IP Multicast Mcache Table Source, Group (S,G) Incoming port of
<Output Truncated> multicast group traffic Client-Edge
Total entries in mcache: 2
1 (10.254.51.50, 224.1.1.1) in v51 (tag e1/1/22), Uptime 16:14:54 (SM)
Core-Agg
Source is directly connected. RP 10.255.255.1 RP
Flags (0x2042ace1) SM SPT L2REG REGSUPP LSRC HW FAST TAG
fast ports: ethe 1/1/16 Srvr-Edge 1/1/16
AgeSltMsk: 1, IPMC: 3549
Forwarding_oif: 2, Immediate_oif: 2, Blocked_oif: 0 1/1/22
Outgoing interface list
L3 (HW) 1:
e1/1/16(VL4), 00:10:57/3, Flags: IM
L2 (HW) 1:
e1/1/16, 04:05:34/200, Flags: IM
Src-Vlan: 51 Source
224.1.1.1
<Output Truncated>
The output from the show ip pim mcache command provides a robust set of
information.
The output show here is from the Server Distribution router which is closest to the
multicast source.
For the purposes of this course, the most important information to view is related to
the data associated with a specific source, group (S,G) entry. Most especially the
incoming and outgoing ports for the multicast stream. The incoming interface, which
may display as a VE, still indicates the physical interface that incoming multicast
stream traffic is coming from.
The output also provides a list of forwarding ports. These are the ports that multicast
stream is being forwarded to. These ports have either received PIM Join messages or
IGMP Group Membership Queries for the multicast group.
I tis important to note that each router is only capable of determining it’s own
responsibility in forwarding multicast traffic. When multiple PIM routers are in the
path of multicast stream, each will have it’s own perspective on correct forwarding
behavior. Consistency of configuration and deployment is critical for predictable
operation and behavior between PIM routers.
Detailed descriptions of output fields are provided in the notes pages following this
slide.
Revision 0919 13 - 53
Revision 0919 13 - 54
Revision 0919 13 - 55
Tracking the Multicast Cache – Transit Router

Core-Agg# show ip pim mcache
IP Multicast Mcache Table
<Output Truncated> Client
1 (*, 224.1.1.1) RP 10.255.255.1, in NIL (NIL), Uptime 16:14:57 (SM)

No upstream neighbor because RP 10.255.255.1 is itself
Flags (0x002204a0) SM RPT TAG Client-Edge
slow ports: ethe 1/1/20
AgeSltMsk: 0, IPMC: NotReq, RegPkt: 0
Core-Agg
L3 (SW) 1: RP
e1/1/20(VL1), 04:05:36/171, Flags: IM
1/1/14
2 (10.254.51.50, 224.1.1.1) in v4 (tag e1/1/14), Uptime 04:10:31 (SM) Srvr-Edge 1/1/16
upstream neighbor 10.254.4.3
Flags (0x2002c4e1) SM SPT HW FAST TAG MSDPADV 1/1/22
fast ports: ethe 1/1/20
AgeSltMsk: 1, IPMC: 5524 , RegPkt: 0
Forwarding_oif: 1, Immediate_oif: 1, Blocked_oif: 0
L3 (HW) 1:
e1/1/20(VL1), 04:05:35/171, Flags: IM IH
Src-Vlan: 4 Source
Here we show the output from the show ip pim mcache command on the Core
Aggregation router.
Revision 0919 13 - 56
Tracking the Multicast Cache – Client Router

Client-Edge# show ip pim mcache
IP Multicast Mcache Table
<Output Truncated> Client
1 (*, 224.1.1.1) RP 10.255.255.1, in e1/1/19 (NIL), Uptime 16:09:58 (SM)

Flags (0x002604a0) SM RPT LRCV TAG Client-Edge 1/1/24
slow ports: lag 2
AgeSltMsk: 0, IPMC: NotReq 1/1/19
Core-Agg
L3 (SW) 1: RP
lg2(VL10), 04:19:06/0, Flags: MJ
1/1/14
2 (10.254.51.50, 224.1.1.1) in e1/1/19 (e1/1/19), Uptime 04:19:06 (SM) Srvr-Edge 1/1/16
Flags (0x200680e1) SM SPT LRCV HW FAST TAG 1/1/22
fast ports: lag 2
AgeSltMsk: 1, IPMC: 525
Forwarding_oif: 1, Immediate_oif: 0, Blocked_oif: 0
L3 (HW) 1:
e1/1/24(VL10), 04:19:06/0, Flags: MJ
Src-Vlan: 1 Source
Lastly, we show the output from the show ip pim mcache command on the Client
Distribution router, which is closest to the client receiving the multicast traffic.
Revision 0919 13 - 57
Module Summary
– Layer 2 and Layer 3 (IPv4) multicast addressing
– Discuss and Configure Protocol Independent Multicast (PIM)

• Independent Group Management Protocol (IGMP) query processing and generation
• Dense Mode
• Sparse Mode
Revision 0919 13 - 58
End of Module 13:

Multicast
Revision 0919 13 - 59
Revision 0919 13 - 60

ICX200 REV0919 SG L PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ICX200 REV0919 SG L PDF

Uploaded by

Copyright:

Available Formats

ICX 200

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

Revision: September, 2019

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved

Revision 0919 1-1

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved 2

Revision 0919 1-2

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved

Revision 0919 1-3

• This course provides an in-depth study of core competencies of configuration, operations,

• This course is based on the Ruckus FastIron OS (FI) v8.0.90 release

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved 4

Revision 0919 1-4

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved 5

Revision 0919 1-5

• M02: Advanced Layer 2 Features

• M03: Port Monitoring and Management

• M04: Discovery Protocols

• M06: Layer 3 Fundamentals

• M07: Client Access Services

• M08: IP Gateway Redundancy

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved 6

Revision 0919 1-6

Course Agenda (cont.)

• M11: Border Gateway Protocol (BGP)

• M12: Traffic Management

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved 7

Revision 0919 1-7

• Before taking this course, attendees should have:

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved 8

Revision 0919 1-8

Gilmore and eBooks

• Students will need to:

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved 9

Your course email contains the following:

Revision 0919 1-9

Training Facility and Policies

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved 10

• Take a moment and share with us:

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved 11

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved

Revision 0919 2-1

• After completing this module, attendees will be able to:

– Understand and deploy Link Aggregation Groups (LAG) advanced features

– Describe and configure protected ports

– Configure VLAN and VE interfaces

– Describe and configure aggregated VLANs (Q-in-Q)

– Understand Q-in-Q BPDU tunneling

– Describe and deploy advanced Spanning Tree features

– Understand and configure Multiple Spanning Tree Protocol

– Understand the benefits of Virtual eXtensible Local Area Network (VxLAN)

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved 2

Revision 0919 2-2

Link Aggregation Groups (LAG)

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved

Revision 0919 2-3

Link Aggregation Groups (LAG)

• LAG member ports must connect to the same adjacent switch

Copyright 2019 – ARRIS Enterprises, LLC. All rights reserved 4

Revision 0919 2-4

lag lag-name { dynamic | static } { id { number | auto } }

• Syntax: [no] lag lag-name { dynamic | static } { id { number | auto } }