OS6450 AOS 6.7.1 R03 Network Configuration Guide
OS6450 AOS 6.7.1 R03 Network Configuration Guide
A
August 2016
OmniSwitch 6250/6350/
6450 Network Configuration
Guide
enterprise.alcatel-lucent.com
This user guide documents release 6.7.1 of the OmniSwitch 6250, 6350, 6450.
The functionality described in this guide is subject to change without notice.
Alcatel-Lucent and the Alcatel-Lucent Enterprise logo are trademarks of Alcatel-Lucent. To view other
trademarks used by affiliated companies of ALE Holding, visit: enterprise.alcatel-lucent.com/trademarks.
All other trademarks are the property of their respective owners. The information presented is subject to
change without notice. Neither ALE Holding nor any of its affiliates assumes any responsibility for inac-
curacies contained herein.
This OmniSwitch 6250/6350/6450 Network Configuration Guide describes how to set up and monitor soft-
ware features that allows your switch to operate in a live network environment. The software features
described in this manual are shipped standard with your OmniSwitch 6250, 6350, 6450 switches. These
features are used when setting up your OmniSwitch in a network of switches and routers.
Supported Platforms
The information in this guide applies to the following products:
• Omniswitch 6250 Series
• Omniswitch 6350 Series
• Omniswitch 6450 Series
Note. This OmniSwitch 6250/6350/6450 Network Configuration Guide covers Release 6.7.1, which is
supported on the OmniSwitch 6250, 6350, 6450.
Unsupported Platforms
The information in this guide does not apply to the following products:
• OmniSwitch 9000 Series
• OmniSwitch 6400 Series
• OmniSwitch 6600 Family
• OmniSwitch 6800 Family
• OmniSwitch 6850 Series
• OmniSwitch 6855 Series
• OmniSwitch (original version with no numeric model name)
• OmniSwitch 7700/7800
• OmniSwitch 8800
• Omni Switch/Router
• OmniStack
• OmniAccess
Anytime
The OmniSwitch CLI Reference Guide contains comprehensive information on all CLI commands
supported by the switch. This guide includes syntax, default, usage, example, related CLI command, and
CLI-to-MIB variable mapping information for all CLI commands supported by the switch. This guide can
be consulted anytime during the configuration process to find detailed and specific information on each
CLI command.
Note. To take advantage of the documentation CD’s global search feature, it is recommended that you
select the option for searching PDF files before downloading Acrobat Reader freeware.
To verify that you are using Acrobat Reader with the global search option, look for the following button in
the toolbar:
Note. When printing pages from the documentation PDFs, de-select Fit to Page if it is selected in your
print dialog. Otherwise pages may print with slightly smaller margins.
Technical Support
An Alcatel-Lucent Enterprise service agreement brings your company the assurance of 7x24 no-excuses
technical support. You will also receive regular software updates to maintain and maximize your Alcatel
product’s features and functionality and on-site hardware replacement through our global network of
highly qualified service delivery partners. Additionally, with 24-hour-a-day access to Alcatel’s Service
and Support web page, you’ll be able to view and update any case (open or closed) that you have reported
to Alcatel’s technical support, open a new case or access helpful release notes, technical bulletins, and
manuals. For more information on Alcatel’s Service Programs, see our web page at service.esd.alcatel-
lucent.com, call us at
1-800-995-2696, or email us at [email protected].
The Ethernet software is responsible for a variety of functions that support Ethernet and Gigabit Ethernet,
ports on OmniSwitch Series switches. These functions include diagnostics, software loading,
initialization, configuration of line parameters, gathering statistics, and responding to administrative
requests from SNMP or CLI.
In This Chapter
This chapter describes your Ethernet port parameters of the switch, and how to configure them through the
Command Line Interface (CLI). CLI Commands are used in the configuration examples. For more details
about the syntax of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.OmniSwitch
6250/6350/6450 Transceivers Guide
Configuration procedures described in this chapter include:
• “Setting Ethernet Parameters for All Port Types” on page 1-7
• “Configuring Flood Rate Limiting” on page 1-9
• “Configuring Digital Diagnostic Monitoring (DDM)” on page 1-12
• “Configuring Energy Efficient Ethernet (802.3az)” on page 1-13
• “Setting Ethernet Combo Port Parameters” on page 1-18
• “Monitoring the Inter-stack Connection” on page 1-23
• “Using TDR Cable Diagnostics” on page 1-24
• “Interface Violation Recovery” on page 1-27
• “Verifying Ethernet Port Configuration” on page 1-30
For information about CLI commands that can be used to view Ethernet port parameters, see the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
Ethernet Specifications
IEEE Standards Supported 802.3 Carrier Sense Multiple Access with Collision Detection
(CSMA/CD)
802.3u (100BaseTX)
802.3ab (1000BaseT)
802.3z (1000Base-X)
802.3ae (10GBase-X)
TDR Specifications
Platforms Supported OmniSwitch 6250 (Normal TDR Test only)
OmniSwitch 6450 (Normal & Extended TDR Test)
Ports Supported Fast Ethernet (100 Mbps)
Gigabit Ethernet (1 Gb/1000 Mbps)
Non-Combo Copper Ports
TDR Test Only one TDR test can be executed at a time.
Note. See “Valid Port Settings on OmniSwitch” on page 1-5 for more information on combo ports. In
addition, refer to the OmniSwitch 6250/6350/6450 Hardware Users Guide for each type of switch.
See “Setting Interface Line Speed for Combo Ports” on page 1-18 for more information on configuring
combo ports.
Note: Settings for SFPs are dependent upon the type of transceiver being used. Refer to the
OmniSwitch 6250/6350/6450 Transceivers Guide for information on supported SFPs.
OmniSwitch 6450 and OmniSwitch 6250 are now CE 2.0 certified across all four service definitions.
CE 2.0 certification ensures service compliance to specifications and inter-working between vendors by
testing product compliance across the four MEF service types — E-Line, E-LAN, E-Tree and E-Access.
Service providers with any of the Alcatel-Lucent CE 2.0 Certified products deployed can deliver CE 2.0
Certified services for any MEF service type. The CE 2.0 product certification designation applies to the
tested configuration and, through compliance, to currently supported hardware and software in general.
Note. TDR Operations is not supported on ports that use copper SFP.
See the OmniSwitch 6250/6350/6450 Hardware Users Guide for more information about the OmniSwitch
hardware.
Autonegotiation Guidelines
The following tables summarize the valid autonegotiation port settings between the OmniSwitch and
another device.
If autonegotiation is disabled, the configured flow control settings are applied to the local interface. See
“Configuring Flow Control on Non-Combo Ports” on page 1-17 and “Configuring Flow Control on
Combo Ports” on page 1-22 for more information.
To enable trap port link messages on a single port, enter trap followed by the slot number, a slash (/), the
port number, and port link enable. For example, to enable trap port link messages on slot 2 port 3, enter:
-> trap 2/3 port link enable
To enable trap port link messages on a range of ports, enter trap followed by the slot number, a
slash (/), the first port number, a hyphen (-), the last port number, and port link enable. For example, to
enable trap port link messages ports 3 through 5 on slot 2, enter:
-> trap 2/3-5 port link enable
To disable trap port link messages on a single port, enter trap followed by the slot number, a slash (/), the
port number, and port link disable. For example, to disable trap port link messages on slot 2 port 3, enter:
-> trap 2/3 port link disable
To disable trap port link messages on a range of ports, enter trap followed by the slot number, a
slash (/), the first port number, a hyphen (-), the last port number, and port link disable. For example, to
disable trap port link messages ports 3 through 5 on slot 2, enter:
-> trap 2/3-5 port link disable
To reset Layer 2 statistics on a single port, enter interfaces followed by the slot number, a slash (/), the
port number, and no l2 statistics. For example, to reset all Layer 2 statistics counters on port 3 on slot 2,
enter:
-> interfaces 2/3 no l2 statistics
To reset Layer 2 statistics on a range of ports, enter interfaces followed by the slot number, a slash (/), the
first port number, a hyphen (-), the last port number, and no l2 statistics. For example, to reset all Layer 2
statistics counters on ports 1 through 3 on slot 2, enter:
-> interfaces 2/1-3 no l2 statistics
Note. The show interfaces, show interfaces accounting, and show interfaces counters commands can
be used to display Layer 2 statistics (for example, input, and output errors, deferred frames received,
unicast packets transmitted). For information on using these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
To enable or disable a single port, enter interfaces followed by the slot number, a slash (/), the port
number, admin, and the desired administrative setting (either up or down). For example, to
administratively disable port 3 on slot 2, enter:
-> interfaces 2/3 admin down
To enable or disable a range of ports, enter interfaces followed by the slot number, a slash (/), the first
port number, a hyphen (-), the last port number, admin, and the desired administrative setting (either up or
down). For example, to administratively disable ports 1 through 3 on slot 2, enter:
-> interfaces 2/1-3 admin down
To configure the rate limit based on storm type, use the interfaces flood rate command. For example, to
configure the rate limit on slot 4, enter:
-> interfaces 4 flood broadcast rate pps 500
Similarly, you can configure the individual rate limit for each storm type like unknown-unicast and multi-
cast. For more information, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Note that, by default,
• 4Mbps rate limit shall be applied for 10 Mbps port for all storm type.
• 49Mbps rate limit shall be applied for 100 Mbps port for all storm type.
• 496Mbps rate limit shall be applied for 1G port for all storm type.
• 997Mbps rate limit shall be applied for 10G port for all storm type.
The configured flood rate can be displayed for specific interface and also for a range of ports. For more
information, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
parameter default
Mbps (10 Ethernet) 4
Mbps (100 Fast Ethernet) 49
Mbps (Gigabit Ethernet) 496
Mbps (10 Gigabit Ethernet) 997
Note. The default value for low threshold is ‘0’. This means, by default, auto recovery is not enabled. It
will be enabled only by configuring low threshold.
To change the peak flood rate for broadcast traffic for an entire slot, enter interfaces followed by the slot
number, flood broadcast rate, and the flood rate in megabits. For example, to configure the peak flood
rate on slot 2 as 49 megabits, enter:
-> interfaces 2 flood broadcast rate mbps 49
To change the peak flood rate for all traffic types for a single port, enter interfaces followed by the slot
number, a slash (/), the port number, flood all rate, and the flood rate in megabits. For example, to config-
ure the peak flood rate on port 3 on slot 2 as 49 megabits, enter:
-> interfaces 2/3 flood all rate mbps 49
To change the peak flood rate for all traffic types for a range of ports, enter interfaces followed by the slot
number, a slash (/), the first port number, a hyphen (-), the last port number, flood all rate, and the flood
rate in megabits. For example, to configure the peak flood rate on ports 1 through 3 on slot 2 as 49 mega-
bits, enter:
-> interfaces 2/1-3 flood all rate mbps 42
To change the peak flood rate and low threshold for all traffic types for an entire slot, enter interfaces
followed by the slot number, flood all rate, peak flood rate value in megabits. For example, to configure
the peak flood rate on slot 2 with peak flood rate and low threshold values as 49 megabits and 40 mega-
bits, enter:
-> interfaces 2 flood all rate mbps 49
To specify the type of traffic eligible for rate limiting, see “Configuring a Port Alias” on page 1-12 and
“Configuring a Port Alias” on page 1-12 for more information.
Note. Spaces must be contained within quotes (for example, “IP Phone 1”).
To configure the maximum frame size on a single port, enter interfaces followed by the slot number, a
slash (/), the port number, max frame, and the frame size in bytes. For example, to set the maximum
frame size on port 3 on slot 2 to 9216 bytes, enter:
-> interfaces 2/3 max frame 9216
To configure the maximum frame size on a range of ports, enter interfaces followed by the slot number, a
slash (/), the first port number, a hyphen (-), the last port number, max frame, and the frame size in bytes.
For example, to set the maximum frame size on ports 1 through 3 on slot 2 to 9216 bytes, enter:
-> interfaces 2/1-3 max frame 9216
To enable the DDM capability on the switch use the interfaces transceiver ddm command. For example,
enter:
-> interfaces transceiver ddm enable
Note. In order to take advantage of the DDM capability, the transceiver must support the DDM functional-
ity. Not all transceivers support DDM, refer to the Transceivers Guide for additional DDM information.
To set the line speed on an entire switch, enter interfaces followed by the slot number and the desired
speed. For example, to set slot 2 to 100 Mbps, enter:
-> interfaces 2 speed 100
To set the line speed on a single port, enter interfaces followed by the slot number, a slash (/), the port
number, and the desired speed. For example, to set the line speed on slot 2 port 3 at 100 Mbps, enter:
-> interfaces 2/3 speed 100
To set the line speed on a range of ports, enter interfaces followed by the slot number, a slash (/), the first
port number, a hyphen (-), the last port number, and the desired speed. For example, to set the line speed
on ports 1 through 3 on slot 2 at 100 Mbps, enter:
-> interfaces 2/1-3 speed 100
Note. The Auto option sets both the duplex mode and line speed settings to autonegotiation.
To configure the duplex mode on an entire slot, enter interfaces followed by the slot number, duplex, and
the desired duplex setting (auto, full, or half). For example, to set the duplex mode on slot 2 to full, enter:
-> interfaces 2 duplex full
To configure the duplex mode on a single port, enter interfaces followed by the slot number, a slash (/),
the port number, duplex, and the desired duplex setting (auto, full, or half). For example, to set the
duplex mode on port 3 on slot 2 to full, enter:
-> interfaces 2/3 duplex full
To configure the duplex mode on a range of ports, enter interfaces followed by the slot number, a slash
(/), the first port number, a hyphen (-), the last port number, duplex, and the desired duplex setting (auto,
full, or half). For example, to set the duplex mode on ports 1 through 3 on slot 2 to full, enter:
-> interfaces 2/1-3 duplex full
To configure the inter-frame gap on an entire slot, enter interfaces, followed by the slot number, ifg, and
the desired inter-frame gap value. For example, to set the inter-frame gap value on slot 2 to 10 bytes,
enter:
-> interfaces 2 ifg 10
To configure the inter-frame gap on a single port, enter interfaces, followed by the slot number, a slash
(/), the port number, ifg, and the desired inter-frame gap value. For example, to set the inter-frame gap
value on port 20 on slot 2 to 10 bytes, enter:
-> interfaces 2/20 ifg 10
To configure the inter-frame gap on a range of ports, enter interfaces, followed by the slot number, a slash
(/), the first port number, a hyphen (-), the last port number, ifg, and the desired inter-frame gap value. For
example, to set the inter-frame gap value on ports 20 through 22 on slot 2 to 10 bytes, enter:
-> interfaces 2/20-22 ifg 10
To enable or disable autonegotiation on a single port, enter interfaces, followed by the slot number, a
slash (/), the port number, autoneg, and either enable or disable. For example, to enable autonegotiation
on port 3 on slot 2, enter:
-> interfaces 2/3 autoneg enable
To enable or disable autonegotiation on a range of ports, enter interfaces, followed by the slot number, a
slash (/), the first port number, a hyphen (-), the last port number, autoneg, and either enable or disable.
For example, to enable autonegotiation on ports 1 through 3 on slot 2, enter:
-> interfaces 2/1-3 autoneg enable
To configure crossover settings on a single port, enter interfaces, followed by the slot number, a slash (/),
the port number, crossover, and the desired setting. For example, to set the crossover configuration to auto
on port 3 on slot 2, enter:
-> interfaces 2/3 crossover auto
To configure crossover settings on a range of ports, enter interfaces, followed by the slot number, a slash
(/), the first port number, a hyphen (-), the last port number, crossover, and the desired setting. For
example, to set the crossover configuration to auto on ports 1 through 3 on slot 2, enter:
-> interfaces 2/1-3 crossover auto
To disable flow control for one or more ports, specify the disable parameter with the interfaces pause
command. For example:
-> interfaces 1/10 pause disable
For more information about the interfaces pause command syntax, see the “Ethernet Port Commands”
chapter in the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Note. In the interfaces hybrid speed command, the copper keyword is used to configure the copper
RJ-45 10/100/1000 port while the fiber keyword is used to configure the fiber SFP connectors.
To set the line speed for all combo ports on an entire switch, enter interfaces, followed by the slot
number, hybrid, either fiber or copper, and the desired speed. For example, to set all combo copper ports
on slot 2 to 100 Mbps, enter:
-> interfaces 2 hybrid copper speed 100
Note. Using the interfaces hybrid speed command to set all combo ports on a switch does not affect the
configurations of the non-combo ports.
To set the line speed on a single combo port, enter interfaces, followed by the slot number, a slash (/), the
combo port number, hybrid, either fiber or copper, and the desired speed. For example, to set the line
speed on slot 2 combo copper RJ-45 port 25 to 100 Mbps, enter:
-> interfaces 2/25 hybrid copper speed 100
To set the line speed on a range of combo ports, enter interfaces, followed by the slot number, a slash (/),
the first combo port number, a hyphen (-), the last combo port number, hybrid, either fiber or copper, and
the desired speed. For example, to set the line speed on combo copper ports 25 through 26 on slot 2 to 100
Mbps, enter:
-> interfaces 2/25-26 hybrid copper speed 100
Note. In the interfaces hybrid duplex command the copper keyword is used to configure the copper
RJ-45 10/100/1000 port while the fiber keyword is used to configure the fiber SFP connector.
To configure the duplex mode on an entire slot, enter interfaces, followed by the slot number, hybrid,
either fiber or copper, duplex, and the desired duplex setting (auto, full, or half). For example, to set the
duplex mode on all fiber combo ports on slot 2 to full, enter:
-> interfaces 2 hybrid fiber duplex full
Note. Using the interfaces hybrid duplex command to set all combo ports on a switch does not affect the
configurations of the non-combo ports.
To configure the duplex mode on a single combo port, enter interfaces, followed by the slot number, a
slash (/), the combo port number, hybrid, either fiber or copper, duplex, and the desired duplex setting
(auto, full, or half). For example, to set the duplex mode on the fiber combo port 23 on slot 2 to full,
enter:
-> interfaces 2/25 hybrid fiber duplex full
To configure the duplex mode on a range of combo ports, enter interfaces, followed by the slot number, a
slash (/), the first combo port number, a hyphen (-), the last combo port number, hybrid, either fiber or
copper, duplex, and the desired duplex setting (auto, full, or half). For example, to set the duplex mode
on fiber combo ports 25 through 26 on slot 2 to full, enter:
-> interfaces 2/25-26 hybrid fiber duplex full
Note. In the interfaces hybrid autoneg command, the copper keyword is used to configure the copper
RJ-45 10/100/1000 port while the fiber keyword is used to configure the fiber SFP connector.
To enable or disable autonegotiation on all combo ports in an entire switch, enter interfaces, followed by
the slot number, hybrid, either fiber or copper, autoneg, and either enable or disable. For example, to
enable autonegotiation on all copper combo ports on slot 2, enter:
-> interfaces 2 hybrid copper autoneg enable
Note. Using the interface hybrid autoneg command to set all combo ports on a switch does not affect the
configurations of the non-combo ports.
To enable or disable autonegotiation on a single combo port, enter interfaces, followed by the slot
number, a slash (/), the combo port number, hybrid, either fiber or copper, autoneg, and either enable or
disable. For example, to enable autonegotiation on copper combo port 25 on slot 2, enter:
-> interfaces 2/25 hybrid copper autoneg enable
To enable or disable autonegotiation on a range of combo ports, enter interfaces, followed by the slot
number, a slash (/), the first combo port number, a hyphen (-), the last combo port number, hybrid, either
fiber or copper, autoneg, and either enable or disable. For example, to enable autonegotiation on copper
combo ports 25 through 26 on slot 2, enter:
-> interfaces 2/25-26 hybrid copper autoneg enable
As an option, you can document the interface type by entering ethernet, fastethernet, or gigaethernet
before the slot number. For example, to enable autonegotiation on copper combo port 23 on slot 2 and
document the combo port as Gigabit Ethernet, enter:
-> interfaces gigaethernet 2/23 hybrid copper autoneg enable
Note. In the interfaces hybrid crossover command, the copper keyword is used to configure the copper
RJ-45 10/100/1000 port.
Setting the crossover configuration to auto configures the interface or interfaces to detect crossover
settings automatically. Setting crossover configuration to mdix configures the interface or interfaces for
MDIX (Media Dependent Interface with Crossover), which is the standard for hubs and switches. Setting
crossover to mdi configures the interface or interfaces for MDI (Media Dependent Interface), which is the
standard for end stations.
To configure crossover settings for all combo ports on an entire switch, enter interfaces, followed by the
slot number, hybrid, copper, crossover, and the desired setting. For example, to set the crossover
configuration to auto on for all copper combo ports slot 2, enter:
-> interfaces 2 hybrid copper crossover auto
Note. Using the interface hybrid crossover command to set all combo ports on a switch does not affect
the configurations of the non-combo ports.
To configure crossover settings on a single combo port, enter interfaces, followed by the slot number, a
slash (/), the combo port number, hybrid, copper, crossover, and the desired setting. For example, to set
the crossover configuration to auto on copper combo port 23 on slot 2, enter:
-> interfaces 2/25 hybrid copper crossover auto
To configure crossover settings on a range of combo ports, enter interfaces, followed by the slot number,
a slash (/), the first combo port number, a hyphen (-), the last combo port number, hybrid, copper,
crossover, and the desired setting. For example, to set the crossover configuration to auto on copper
combo ports 25 through 26 on slot 2, enter:
-> interfaces 2/25-26 hybrid copper crossover auto
Note. In the interfaces hybrid pause command, the copper keyword is used to configure the copper
RJ-45 10/100/1000 port while the fiber keyword is used to configure the fiber SFP connector.
For example, the following command configures port 1/25 to transmit and honor PAUSE frames:
-> interfaces 1/25 hybrid fiber pause tx-and-rx
To disable flow control, use the disable parameter with the interfaces hybrid pause command.
For example:
-> interfaces 1/25 hybrid fiber pause disable
For more information about the interfaces hybrid pause command syntax, see the “Ethernet Port
Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Reference Guide.
• The TDR Test (CLIs related to TDR-Test) can run on both OS 6250 and OS 6450 platforms. While the
Extended-TDR Test (CLIs related to Extended-TDR Test) can run only on a switch with 1 GIG link
capability (OS 6450).
• Extended TDR is a feature that is used to know the attached cable characteristics. It is implemented by
monitoring the transmitted signals amplitude received from the link partner. Both the tests are used to
find out different parameter of a cable under different scenarios. These Cable Diagnostic feature are
supported and are integrated into the CPSS SDK.
• The Extended-TDR Test results (cable-length) between different pairs and between multiple readings
within each pair can vary based on the link partner’s differential voltage and temperature conditions of
the device under test. If the same cable is measured several times, occasionally there can be a major
deviation in the reading exceeding +/- 10 meters.
A Extended-TDR test is initiated using the interfaces tdr-extended-test-start CLI command.
For example, the following command starts the test on port 2/1:
-> interfaces 2/1 tdr-extended-test-start
• Extended TDR can work only when the gigabit link is established between the two link partners.
• Extended TDR operations cannot be performed on fiber, stacking and combo ports.
Slot/ No of Cable Pair1 Pair1 Pair2 Pair2 Pair3 Pair3 Pair4 Pair4 Test
port pairs State State Length State Length State Length State Length Result
-----+-----+------+-----+-----+-----+------+------+-----+------+-----+------+------
1/3 4 ok 0 ok 3 ok 3 ok 3 ok 3 success
The show interfaces tdr-extended-statistics command is used to display the results of the last Extended
TDR test performed on a port. For example:
--> show interfaces 1/5 tdr-extended-statistics
Pair Swap
Channel 1:straight
Channel 2:straight
Pair Polarity
Pair 1:positive
Pair 2:positive
Pair 3:positive
Pair 4:positive
Pair Skew (in n-seconds)
Pair 1:0
Pair 2:0
Pair 3:8
Pair 4:0
Accurate Cable Length (in meters)
Pair 1:15
Pair 2:15
Pair 3:15
Pair 4:15
Downshift:No Downshift
The following cable states are indicated in the show interfaces tdr-statistics command output:
• OK—Wire is working properly
• Open:—Wire is broken
• Short—Pairs of wire are in contact with each other
• Impedance Mismatch -
• Two cable of different quality or resistance are connected to each other through patch connector.
• If the pair is short in a cable, it may affect the resistance of another pair hence it will result Imped-
ance mismatch on that particular pair.
• Unknown - Cable diagnostic test unable to find the state of a cable.
• Pair Swap - Determines the channel associated with the MDI pair (cross or not for each two MDI
pairs).
• Pair Polarity- Detects if the pairs are connected with reverse polarity (reverse on one side between
two conductors in one pair)
• Pair Skew-The skew among the four pairs of cable (delay between pairs, in n-seconds)
• Cable Length - The length of the cable, in meters.
• Downshift - Gives the downshift status of the port, when the gigabit link cannot be established.
TDR statistics from a previous test are also cleared when a new test starts on the same port.
TDR extended statistics from a previous test are also cleared when a new test starts on the same port.
The violation recovery time value configured for a specific interface overrides the global value config-
ured for all switch interfaces. To set the port-level value back to the global value, use the default parame-
ter with the interfaces violation-recovery-time command. For example, the following command sets the
violation recovery time for port 2/1 back to the global value of 600:
-> interfaces 2/1 violation-recovery-time default
To disable the violation recovery timer mechanism, set the recovery time to zero. For example:
The maximum recovery attempts value configured for a specific interface overrides the global value
configured for all switch interfaces. To set the port-level value back to the global value, use the default
parameter with the interfaces violation-recovery-maximum command. For example, the following
command sets the number of recovery attempts for port 2/1 back to the global value of 3:
-> interfaces 2/1 violation-recovery-maximum default
To disable the violation recovery maximum attempts mechanism, set the number of attempts to zero. For
example:
show interfaces port Displays the administrative status (up or down), link status, violations,
recovery time, maximum recovery attempts.
show interfaces violation- Displays the globally configured recovery time, SNMP recovery trap
recovery enable or disable status and maximum recovery attempts.
For more information about the resulting displays from these commands, see the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
show interfaces pause Displays the flow control pause configuration for switch interfaces.
show interfaces Displays general interface information, such as hardware, MAC
address, input, and output errors.
show interfaces accounting Displays interface accounting information.
show interfaces counters Displays interface counters information.
show interfaces counters Displays interface error frame information for Ethernet and Fast
errors Ethernet ports.
show interfaces collisions Displays collision statistics information for Ethernet and Fast Ethernet
ports.
show interfaces status Displays line status information.
show interfaces port Displays port status information.
show interfaces ifg Displays inter-frame gap values.
show interfaces flood rate Displays peak flood rate settings.
show interfaces traffic Displays interface traffic statistics.
show interfaces capability Displays autonegotiation, flow, speed, duplex, and crossover settings.
show interfaces hybrid Displays general interface information (for example, hardware, MAC
address, input errors, output errors) for combo ports.
show interfaces hybrid status Displays line status information for combo ports.
show interfaces hybrid flow Displays interface flow control wait time settings in nanoseconds for
control combo ports.
show interfaces hybrid pause Displays the flow control pause configuration for combo ports.
show interfaces hybrid Displays autonegotiation, flow, speed, duplex, and crossover settings
capability for combo ports.
show interfaces hybrid Displays interface accounting information (for example, packets
accounting received/transmitted, deferred frames received) for combo ports.
show interfaces hybrid Displays interface counters information (for example, unicast, broad-
counters cast, multi-cast packets received/transmitted) for combo ports.
show interfaces hybrid Displays interface error frame information (for example, CRC errors,
counters errors transit errors, receive errors) for combo ports.
show interfaces hybrid Displays interface collision information (for example, number of
collisions collisions, number of retries) for combo ports.
show interfaces hybrid traffic Displays interface traffic statistics for combo ports.
show interfaces hybrid port Displays interface port status (up or down) for combo ports.
show interfaces hybrid flood Displays interface peak flood rate settings for combo ports.
rate
show interfaces hybrid ifg Displays interface inter-frame gap values for combo ports.
These commands can be useful in troubleshooting and resolving potential configuration issues or prob-
lems on your switch. For more information about the resulting displays from these commands, see the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
Transparent bridging relies on a process referred to as source learning to handle traffic flow. Network
devices communicate by sending and receiving data packets that each contain a source MAC address and a
destination MAC address. When packets are received on switch network interface (NI) module ports,
source learning examines each packet and compares the source MAC address to entries in a MAC address
database table. If the table does not contain an entry for the source address, then a new record is created
associating the address with the port it was learned on. If an entry for the source address already exists in
the table, a new one is not created.
Packets are also filtered to determine if the source and destination address are on the same LAN segment.
If the destination address is not found in the MAC address table, then the packet is forwarded to all other
switches that are connected to the same LAN. If the MAC address table does contain a matching entry for
the destination address, then there is no need to forward the packet to the rest of the network.
In This Chapter
This chapter describes how to manage source learning entries in the switch MAC address table (often
referred to as the forwarding or filtering database) through the Command Line Interface (CLI). CLI
commands are used in the configuration examples; for more details about the syntax of commands, see the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
Configuration procedures described in this chapter include:
• “Using Static MAC Addresses” on page 2-5.
• “Using Static Multicast MAC Addresses” on page 2-7
• “Configuring MAC Address Table Aging Time” on page 2-9.
• “Configuring the Source Learning Status” on page 2-10.
• “Displaying Source Learning Information” on page 2-11.
Note. Optional. Creating a static MAC address involves specifying an address that is not already used in
another static entry or already dynamically learned by the switch. To determine if the address is already
known to the MAC address table, enter show mac-address-table. If the address does not appear in the
show mac-address-table output, then it is available to use for configuring a static MAC address entry. For
example,
-> show mac-address-table
Legend: Mac Address: * = address not valid
The show mac-address-table command is also useful for monitoring general source learning activity and
verifying dynamic VLAN assignments of addresses received on mobile ports.
1 Create VLAN 200, if it does not already exist, using the following command:
2 Assign switch ports 2 through 5 on slot 3 to VLAN 200–if they are not already associated with VLAN
200–using the following command:
-> vlan 200 port default 3/2-5
3 Create a static MAC address entry using the following command to assign address 002D95:5BF30E to
port 3/4 associated with VLAN 200 and to specify a permanent management status for the static address:
-> mac-address-table permanent 00:2d:95:5B:F3:0E 3/4 200
4 Change the MAC address aging time to 500 seconds (the default is 300 seconds) using the following
command:
-> mac-address-table aging-time 500
Note. Optional. To verify the static MAC address configuration, enter show mac-address-table. For
example:
-> show mac-address-table
Legend: Mac Address: * = address not valid
To verify the new aging time value, enter show mac-address-table aging-time. For example,
Since permanent and bridging options for a static MAC are default settings, it is not necessary to enter
them as part of the command.
Use the no form of this command to clear MAC address entries from the table. If the MAC address status
type (permanent or learned) is not specified, then only permanent addresses are removed from the table.
The following example removes a MAC address entry that is assigned on port 2 of slot 3 for VLAN 855
from the MAC address table:
-> no mac-address-table 00:00:02:CE:10:37 3/2 855
If a slot/port and VLAN ID are not specified when removing MAC address table entries, then all MACs
defined with the specified status are removed. For example, the following command removes all learned
MAC addresses from the table, regardless of their slot/port or VLAN assignments:
-> no mac-address-table learned
To verify static MAC address configuration and other table entries, use the show mac-address-table
command. For more information about this command, see the OmniSwitch 6250/6350/6450 CLI Refer-
ence Guide.
For more information about configuring a link aggregate of ports, see Chapter 25, “Configuring Static
Link Aggregation” and Chapter 26, “Configuring Dynamic Link Aggregation.”
To assign a multicast address to more than one port, enter a range of ports and/or multiple port entries on
the same command line separated by a space. For example, the following command assigns the multicast
address 01:25:9a:5c:2f:10 to port 1/24 and ports 2/1 through 2/6 in VLAN 20:
-> mac-address-table static-multicast 01:25:9a:5c:2f:10 1/24 2/1-6 20
Use the no form of the mac-address-table static-multicast command to delete static multicast MAC
address entries. For example, the following command deletes a static multicast address that is assigned to
port 2 on slot 3 for VLAN 855:
-> no mac-address-table static-multicast 01:00:02:CE:10:37 3/2 855
If a a MAC address, slot/port and VLAN ID are not specified with this form of the command, then all
static multicast addresses are deleted. For example, the following command deletes all static MAC
addresses, regardless of their slot/port or VLAN assignments:
-> no mac-address-table static-multicast
To verify the static MAC address configuration and other table entries, use the show mac-address-table
and show mac-address-table static-multicast commands. For more information about these commands,
see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
For more information about configuring a link aggregate of ports, see Chapter 13, “Configuring Static Link
Aggregation” and Chapter 14, “Configuring Dynamic Link Aggregation.”
ASCII-File-Only Syntax
When a static multicast MAC address is configured and saved (typically through the snapshot or write
memory commands), the mac-address-table static-multicast command captured in the ASCII text file or
boot.cfg file includes an additional group parameter. This parameter indicates the number of the multi-
cast group that the switch has assigned to the multicast MAC address for the given VLAN association. For
example:
-> mac-address-table static-multicast 01:25:9a:5c:2f:10 1/24 2/1-6 20 group 1
In this example, the multicast MAC address, 01:25:9a:5c:2f:10, is associated with ports 1/24 and 2/1
through 2/6 in VLAN 20. The additional group parameter value shown in the example indicates that the
switch assigns the multicast-VLAN association created with the mac-address-table static-multicast to
multicast group one.
Note. If the port assigned to a multicast MAC address is down or administratively disabled when the
configuration snapshot or write memory command is used, the multicast MAC address is not saved to
the resulting ASCII file or boot.cfg file.
Each multicast MAC address association with a VLAN is treated as a unique instance and is assigned a
multicast group number specific to that instance. This is also the case when the same multicast address is
associated with more than one VLAN; each VLAN association is assigned a multicast group number even
though the MAC address is the same for each instance. Note that up to 1022 multicast address-VLAN
associations are supported per switch.
A MAC address learned on any VLAN port will age out if the time since a packet with that address was
last seen on the port exceeds 500 seconds.
Note. An inactive MAC address may take up to twice as long as the aging time value specified to age out
of the MAC address table. For example, if an aging time of 60 seconds is specified, the MAC will age out
any time between 60 and 120 seconds of inactivity.
When using the mac-address-table aging-time command in a switch configuration file (for example,
boot.cfg), include an instance of this command specifying the VLAN ID for each VLAN configured on
the switch. This is necessary even though all VLANs has the same aging time value.
To set the aging time back to the default value, use the no form of the mac-address-table aging-time
command. For example, the following sets the aging time for all VLANs back to the default of 300
seconds:
-> no mac-address-table aging-time
Note. The MAC address table aging time is also used as the timeout value for the Address Resolution
Protocol (ARP) table. This timeout value determines how long the switch retains dynamically learned
ARP table entries. See Chapter 28, “Configuring IP,” for more information.
To display the aging time value for one or all VLANs, use the show mac-address-table aging-time
command. For more information about this command, see the OmniSwitch 6250/6350/6450 CLI Refer-
ence Guide.
To enable the source learning status for a port or link aggregate, use the source-learning command with
the enable option. For example:
Disabling source learning on a port or link aggregate is useful on a ring configuration, where a switch
within the ring does not need to learn the MAC addresses that the same switch is forwarding to another
switch within the ring,. This functionality is also useful in Transparent LAN Service configurations, where
the service provider device does not need to learn the MAC addresses of the customer network.
Configuring the source learning status is not allowed on the following types of switch ports:
• Mobile ports, including 802.1X ports (802.1X is enabled on mobile ports only).
• Ports enabled with Learned Port Security (LPS).
• Member ports of a link aggregate.
Consider the following guidelines when changing the source learning status for a port or link aggregate:
• Disabling source learning on a link aggregate disables MAC address learning on all member ports of
the link aggregate.
• MAC addresses dynamically learned on a port or aggregate are cleared when source learning is
disabled.
• Statically configured MAC addresses are not cleared when source learning is disabled for the port or
aggregate. In addition, configuring a new static MAC address is allowed even when source learning is
disabled.
show mac-address-table Displays a list of all MAC addresses known to the MAC address
table, including static MAC addresses.
show mac-address-table static- Displays a list of all static multicast MAC addresses known to the
multicast MAC address table. Note that only static multicast addresses
assigned to ports that are up and enabled are displayed with this
command.
show mac-address-table count Displays a count of the different types of MAC addresses (learned,
permanent, reset, and timeout). Also includes a total count of all
addresses known to the MAC address table.
show mac-address-table aging-time Displays the current MAC address aging timer value by switch or
VLAN.
For more information about the resulting displays from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide. An example of the output for the show mac-address-table and show mac-
address-table aging-time commands is also given in “Sample MAC Address Table Configuration” on
page 2-3.
Learned Port Security (LPS) provides a mechanism for authorizing source learning of MAC addresses on
Ethernet and Gigabit Ethernet ports.
Learned Port Security (LPS) provides a mechanism for authorizing source learning of MAC addresses on
Ethernet and Gigabit Ethernet ports. LPS does not support link aggregate and tagged (trunked) link
aggregate ports. Using LPS to control source MAC address learning provides the following benefits:
• A configurable source learning time limit that applies to all LPS ports.
• Two methods for handling unauthorized traffic: stopping all traffic on the port or only blocking traffic
that violates LPS criteria.
In This Chapter
This chapter describes how to configure LPS parameters through the Command Line Interface (CLI). CLI
commands are used in the configuration examples; for more details about the syntax of commands, see the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Enabling LPS for a port on page 3-9.
• Specifying a source learning time limit for all LPS ports on page 3-10.
• Configuring the maximum number of MAC addresses learned per port on page 3-16.
• Configuring the maximum number of filtered MAC addresses learned per port on page 3-17.
• Configuring a list of authorized MAC addresses for an LPS port on page 3-17.
• Configuring a range of authorized MAC addresses for an LPS port on page 3-18.
• Selecting the security violation mode for an LPS port on page 3-19.
For more information about source MAC address learning, see Chapter 3, “Managing Source Learning.”
• Defining the maximum number of learned MAC addresses allowed on an LPS port.
• Defining the time limit to allow source learning on all LPS ports.
LPS is supported on Ethernet and Gigabit Ethernet fixed, mobile, tagged and authenticated ports. LPS is
not supported on link aggregate and tagged (trunked) link aggregate ports.
1 Enable LPS on ports 6 through 12 on slot 3, 4, and 5 using the following command:
2 Set the total number of learned MAC addresses allowed on the same ports to 25 using the following
command:
-> port-security 3/6-12 4/6-12 5/6-12 maximum 25
3 Configure the amount of time in which source learning is allowed on all LPS ports to 30 minutes using
the following command:
-> port-security shutdown 30
Optional: Provide infinite learning window mode where the learning window does not expire. Infinite
learning window can be configured for all the LPS learning options when the shutdown value is set to
zero:
-> port-security shutdown 0
Optional: The MAC addresses learned during the learning window are directly converted to static with
learn-as-static option enabled, per port or globally when no-aging is enabled.
-> port-security shutdown 30 no-aging enable learn-as-static enable
Note. See “Configuring Automatic Conversion of MAC Addresses” on page 3-15, “Configuring MAC
Movement” on page 3-15 , and “Configuring Infinite Learning Window” on page 3-14 for configuration
options on port-security shutdown command.
4 Select shutdown for the LPS violation mode using the following command:
Note. Optional. To verify LPS port configurations, use the show port-security command. For example:
To verify the new source learning time limit value, use the show port-security shutdown command. For
example:
-> show port-security shutdown
Additional LPS functionality allows the user to specify how the LPS port handles unauthorized traffic.
The following two options are available for this purpose:
• Block only traffic that violates LPS port restrictions; authorized traffic is forwarded on the port.
• Disable the LPS port when unauthorized traffic is received; all traffic is stopped and a port reset is
required to return the port to normal operation.
LPS functionality is supported on the following Ethernet and Gigabit Ethernet port types:
• Fixed (non-mobile)
• Mobile
• 802.1Q tagged
• Authenticated
• 802.1x
• Is the number of MAC addresses learned on the port below the maximum number allowed?
• Is the number of MAC addresses learned on the port below the maximum Filtered MAC allowed?
• Is there a configured authorized MAC address entry for the LPS port that matches the packet’s source
MAC address?
Using the above criteria, the following table shows the conditions under which a MAC address is learned
or blocked on an LPS port:
When the learning window expires the system will learn the filtering MACs up to the maximum limit and
the LPS port will go on violation.
When a source MAC address violates any of the LPS conditions, the address is considered unauthorized.
The LPS violation mode determines if the unauthorized MAC address is simply blocked (filtered) on the
port or if the entire port is disabled (see “Selecting the Security Violation Mode” on page 3-19).
Regardless of which mode is selected, notice is sent to the Switch Logging task to indicate that a violation
has occurred.
Note. A dynamic MAC address learned on an LPS port is flushed when a port goes down, or MAC ages
out, or the MAC address entry in the LPS table is not saved.
On enabling "no-aging" on an LPS port, the MAC addresses are automatically learned as pseudo static
MAC addresses during the LPS learning window time period. These learned MAC addresses are not
affected by aging and flushing operations that occur during the learning window.
Once the learning window expires, if the ‘convert-to-static’ option is disabled, these MAC addresses
remain as pseudo static. Else if the ‘convert-to-static’ is enabled, the pseudo static MAC addresses are
converted to static address.
Note. Statically configured authorized MAC addresses are displayed permanently in the MAC address
table for the specified LPS port; they will not be learned on any other port in the same VLAN.
Example:
-> vlan 2
-> vlan 2 port default 1/3
-> vlan 2 port default 1/4
-> port-security 1/3 mac 00:00:00:00:00:01
-> port-security 1/4 mac 00:00:00:00:00:01
Note.
• Static MAC Address movement is not allowed on LPS ports configured as UNI ports.
• System supports static MAC moves only on the LPS ports where static MAC is configured on
different ports in a given VLAN.
• When static MAC is configured on different LPS ports in a VLAN, the static MAC is valid only on one
port. This port is either an ingress port or the first port on which LPS static MAC is configured.
• The maximum number of MAC addresses that can be filtered on the port.
• The violation mode selected for the port; restrict, shutdown or discard.
• The management status for the MAC address entry; configured or dynamic.
If the LPS port is shut down or the network device is disconnected from the port, the LPS table entries and
the source learning MAC address table entries for the port are automatically cleared. In addition, if an LPS
table entry is intentionally cleared from the table, the MAC address for this entry is automatically cleared
from the source learning table at the same time. To override this behavior, a dynamic MAC address can be
converted to a static MAC address using the port-security convert-to-static command.
To view the contents of the LPS table, use the show port-security command. Refer to the OmniSwitch
6250/6350/6450 CLI Reference Guide for more information about this command.
To enable LPS on multiple ports, specify a range of ports or multiple slots. For example:
-> port-security 4/1-5 admin-status enable
-> port-security 5/12-20 6/10-15 admin-status enable
When LPS is enabled on an active port, all MAC addresses learned on that port prior to the time LPS was
enabled are cleared from the source learning MAC address table.
To disable LPS on a port, use the port-security command with the disable parameter. For example, the
following command disables LPS on a range of ports:
-> port-security 5/21-24 6/1-4 admin-status disable
To convert all learned bridge MAC address on LPS port into static MAC address, use the port-security
chassis command with the convert-to-static parameter. For example:
-> port-security chassis convert-to-static
To disable all the LPS ports on a chassis, use the port-security chassis disable command, as shown:
-> port-security chassis disable
When LPS is disabled on a port, MAC address entries for that port are retained in the LPS table. The next
time LPS is enabled on the port, the same LPS table entries are again active. If there is a switch reboot
before the switch configuration is saved, however, dynamic MAC address entries are discarded from the
table.
To disable source learning on the specified LPS port(s), use the port-security command with the locked
parameter. For example, the following command disables source learning on port 3 of slot 4:
-> port-security 4/3 admin-status locked
Use the no form of this command to remove LPS and clear all entries (configured and dynamic) in the
LPS table for the specified port. For example:
-> no port-security 5/10
After LPS is removed, all the dynamic and static MAC addresses will be flushed and the learning of new
MAC addresses will be enabled.
The LPS source learning time limit is a switch-wide parameter that applies to all LPS enabled ports, not
just one or a group of LPS ports. The following command example sets the time limit value to 30 minutes:
-> port-security shutdown time 30
Once the time limit value expires, source learning of any new dynamic MAC addresses is stopped on all
LPS ports even if the number of addresses learned does not exceed the maximum allowed.
Note. The LPS source learning time window has a higher priority over the maximum number of MAC
addresses allowed. Therefore, if the learning interval expires before the port has learned the maximum
MAC addresses allowed, the port will not learn anymore MAC addresses.
When the source learning time window expires, all the dynamic MAC addresses learned on the LPS ports
start to age out. To prevent aging out, all dynamic MAC addresses must be converted to static MAC
addresses. The convert-to-static parameter used with the port-security shutdown command enables or
disables the conversion of dynamic MAC addresses to static MAC addresses on LPS ports when the
source learning time window expires.
To enable the conversion of dynamic MAC addresses to static MAC addresses on LPS ports when the
source learning time window expires, use the port-security shutdown command with the
convert-to-static parameter, as shown:
-> port-security shutdown 30 convert-to-static enable
To disable the conversion of dynamic MAC addresses to static MAC addresses when the source learning
time window expires, use the port-security shutdown command with the convert-to-static parameter, as
shown:
-> port-security shutdown 30 convert-to-static disable
To convert the dynamically learned MAC addresses to static addresses on a specific LPS port at any time
irrespective of the source learning time window, use the port-security convert-to-static command. For
example, to convert the dynamic MAC addresses on port 8 of slot 4 to static ones, enter:
-> port-security 4/8 convert-to-static
When the no-aging parameter is enabled with the port-security shutdown command, all the bridged LPS
MAC addresses learned during the learning window are not aged-out from the system. These MAC
addresses are learned as pseudo static MAC addresses. For example:
-> port-security shutdown 60 no-aging enable
The bridged LPS MACs will be removed from the system when the no port-security command or no
mac-address-table command is issued.
To start the learning window automatically at boot-up time or on switch restart, use the port-security
shutdown command with the boot-up parameter enabled. For example:
-> port-security shutdown 60 boot-up enable
Note.
• The number of converted static MAC addresses cannot exceed the maximum number of MAC
addresses allowed on the LPS ports.
• The conversion of dynamic MAC addresses to static ones does not apply to LPS mobile and
authenticated ports.
The following table displays the behavior of switch and ports and when learning window is active and
after expiry of learning window.
The dynamically learned (pseudo-static) MAC addresses automatically convert-to-static after learning
window expires.
Note. The port-security shutdown 0 default option can be used to set all the options for learning window
to their default values. For example:
-> port-security shutdown 0 default
When mac-move is enabled, pure static MACs are learned as static on new port and marked as
duplicate MAC entries on old port. Thus duplicate MAC entries are stored on multiple ports.
MAC movement behavior for configured static MACs is as follows:
• When a MAC is learned as static, the MAC address is stored when it comes to any port other than the
origin port, in any slot in the switch.This entry is stored on all the slots.
• A port specific with forwarding” action is applied. When mac-move is enabled, MACs are stored on
all the ports except the one on which the MAC has come originally.
• Mac-move can not be enabled if total number of configured MACs are greater than 64 or when total
maximum bridging count at system level is greater than or equal to 64.
• When mac-move is disabled then, a port specific entry with action is created in the system for all
duplicate static MACs at that instance.
• When mac-move is disabled, the 64 MAC restriction does not apply.
If a pseudo static MAC learned is present on more than one port in the same VLAN, the MAC is allowed
to move to the new port and is learned as pseudo-static MAC on the new port.
The option 'mac-move' in learning window, allows pseudo-static MACs to move from one port to another
based on condition applied. This can be used only when 'no-aging' option is enabled.
To enable MAC movement for pseudo-static MAC, use the port-security shutdown command with the
mac-move parameter. For example, to enable MAC movement for 20 minutes across all LPS ports within
the same VLAN, enter:
-> port-security shutdown 20 no-aging enable mac-move enable
To specify a maximum number of MAC addresses allowed for multiple ports, specify a range of ports or
multiple slots. For example:
-> port-security 1/10-15 maximum 10
-> port-security 2/1-5 4/2-8 5/10-14 maximum 25
Configured MAC addresses count towards the maximum number allowed. For example, if there are 10
configured authorized MAC addresses for an LPS port and the maximum number of addresses allowed is
set to 15, then only five dynamically learned MAC address are allowed on this port.
If the maximum number of MAC addresses allowed is reached before the switch LPS time limit expires,
then all source learning of dynamic and configured MAC addresses is stopped on the LPS port.
Sending a trap when this threshold is reached provides notification of newly learned bridged MAC
addresses. Trap contents includes identifying information about the MAC, such as the address itself, the
corresponding IP address, switch identification, and the slot and port number on which the MAC was
learned.
To specify a maximum number of filtered MAC addresses learned on multiple ports, specify a range of
ports or multiple slots. For example:
-> port-security 5/9-15 max-filtering 10
-> port-security 1/1-5 7/2-8 2/10-14 max-filtering 25
If the maximum number of filtered MAC addresses allowed is reached, either the LPS port is disabled
(Shutdown Violation mode) or MAC address learning is disabled (Restrict Violation mode). Under both
these modes, SNMP traps are generated and the events are logged in the switch log. For information on
configuring the security violation modes, see “Selecting the Security Violation Mode” on page 3-19.
Note. If a VLAN is not specified, the default VLAN for the port is used.
Use the no form of this command to clear configured and/or dynamic MAC address entries from the LPS
table. For example, the following command removes a MAC address entry for port 4 of slot 6 that belongs
to VLAN 10 from the LPS table:
-> port-security 6/4 no mac 00:20:da:9f:58:0c vlan 10
Note that when a MAC address is cleared from the LPS table, it is automatically cleared from the source
learning MAC address table at the same time.
To configure a source MAC address range for multiple ports, specify a range of ports or multiple slots. For
example:
-> port-security 4/1-5 mac-range low 00:20:da:00:00:10 high 00:20:da:00:00:50
-> port-security 2/1-4 4/5-8 mac-range low 00:20:d0:59:0c:9a high
00:20:d0:59:0c:9f
To set the range back to the default values, enter port-security followed by the port’s slot/port designa-
tion, then mac-range. Leaving off the low and high MAC addresses will reset the range back to
00:00:00:00:00:00 and ff:ff:ff:ff:ff:ff. For example, the following command sets the authorized MAC
address range to the default values for port 12 of slot 4:
-> port-security 4/12 mac-range
In addition, specifying a low end MAC and a high end MAC is optional. If either one is not specified, the
default value is used. For example, the following commands set the authorized MAC address range on the
specified ports to 00:da:25:59:0c:10–ff:ff:ff:ff:ff:ff and 00:00:00:00:00:00–00:da:25:00:00:9a:
-> port-security 2/8 mac-range low pp:da:25:59:0c
-> port-security 2/10 mac-range high 00:da:25:00:00:9a
Refer to the OmniSwitch 6250/6350/6450 CLI Reference Guide for more information about this command.
To configure the security violation mode for multiple LPS ports, specify a range of ports or multiple slots.
For example:
-> port-security 4/1-10 violation shutdown
-> port-security 1/10-15 2/1-10 violation restrict
-> port-security 3/4 violation discard
show port-security Displays Learned Port Security (LPS) configuration and table
entries.
show port-security shutdown Displays the amount of time during which source learning can
occur on all LPS ports.
show port-security brief Displays the per port LPS parameters configured for all the ports.
For more information about the resulting display from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide. An example of the output for the show port-security and show port-security
shutdown commands is also given in “Sample Learned Port Security Configuration” on page 3-3.
In a flat bridged network, a broadcast domain is confined to a single LAN segment or even a specific
physical location, such as a department or building floor. In a switch-based network, such as one
comprised of Alcatel switching systems, a broadcast domain—or VLAN— can span multiple
physical switches and can include ports from a variety of media types. For example, a single VLAN could
span three different switches located in different buildings and include 10/100 Ethernet, Gigabit Ethernet,
802.1q tagged ports and/or a link aggregate of ports.
In This Chapter
This chapter describes how to define and manage VLAN configurations through the Command Line
Interface (CLI). CLI commands are used in the configuration examples; for more details about the syntax
of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Configuration procedures described in this chapter include:
• “Creating/Modifying VLANs” on page 4-5.
• “Defining VLAN Port Assignments” on page 4-6.
• “Enabling/Disabling VLAN Mobile Tag Classification” on page 4-8.
• “Enabling/Disabling Spanning Tree for a VLAN” on page 4-9.
• “Configuring VLAN Router Interfaces” on page 4-10.
• “Bridging VLANs Across Multiple Switches” on page 4-10.
• “Verifying the VLAN Configuration” on page 4-12.
For information about statically and dynamically assigning switch ports to VLANs, see Chapter 7,
“Assigning Ports to VLANs.”
For information about defining VLAN rules that allow dynamic assignment of mobile ports to a VLAN,
see Chapter 9, “Defining VLAN Rules.”
For information about Spanning Tree, see Chapter 12, “Configuring Spanning Tree.”
For information about routing, see Chapter 28, “Configuring IP.”
VLAN Specifications
Note that the maximum limit values provided in the following Specifications table are subject to available
system resources:
VLAN Defaults
Parameter Description Command Default
VLAN identifier (VLAN ID) vlan VLAN 1 predefined on each
switch.
VLAN administrative state vlan Enabled
VLAN description vlan name VLAN identifier (VLAN ID)
VLAN Spanning Tree state vlan stp Enabled (Disabled if VLAN
count exceeds 254)
VLAN mobile tag status vlan mobile-tag Disabled
VLAN IP router interface ip interface VLAN 1 router interface.
VLAN port associations vlan port default All ports initially associated
with default VLAN 1.
Note. Optional. Creating a new VLAN involves specifying a VLAN ID that is not already assigned to an
existing VLAN. To determine if a VLAN already exists in the switch configuration, enter show vlan. If
VLAN 255 does not appear in the show vlan output, then it does not exist on the switch. For example:
-> show vlan
stree mble
vlan type admin oper 1x1 flat auth ip tag name
----+-----+-----+----+-----+--------+------+----+-----+----------+--------------
1 std on on on on off NA off VLAN 1
2 gvrp on on off off off NA off GVRPVLAN 2
3 ipmv on on off off off NA off IPMVVLAN 3
4 vstk on on on on off NA off SVLAN 4
1 Create VLAN 255 with a description (for example, Finance IP Network) using the following
command:
-> vlan 255 name “Finance IP Network”
2 Define an IP router interface using the following command to assign an IP host address of 21.0.0.10 to
VLAN 255 that enables routing of VLAN traffic to other subnets:
-> ip interface vlan-255 address 21.0.0.10 vlan 255
3 Assign switch ports 2 through 4 on slot 3 to VLAN 255 using the following command:
Note. Optional. To verify the VLAN 255 configuration, use the show vlan command. For example:
To verify that ports 3/2-4 were assigned to VLAN 255, use the show vlan port command. For example:
• The VLAN operational state, which is inactive until at least one active switch port is associated with
the VLAN.
Creating/Modifying VLANs
The initial configuration for all Alcatel switches consists of a default VLAN 1 and all switch ports are
initially assigned to this VLAN. When a switching module is added to the switch, the module’s physical
ports are also assigned to VLAN 1. If additional VLANs are not configured on the switch, then the entire
switch is treated as one large broadcast domain. All ports receives all traffic from all other ports.
Up to 4094 VLANs are supported per switch, including default VLAN 1. In compliance with the IEEE
802.1Q standard, each VLAN is identified by a unique number, referred to as the VLAN ID. The user
specifies a VLAN ID to create, modify or remove a VLAN and to assign switch ports to a VLAN. When a
packet is received on a port, the port’s VLAN ID is inserted into the packet. The packet is then bridged to
other ports that are assigned to the same VLAN ID. In essence, the VLAN broadcast domain is defined by
a collection of ports and packets assigned to its VLAN ID.
The operational status of a VLAN remains inactive until at least one active switch port is assigned to the
VLAN. This means that VLAN properties, such as Spanning Tree or router interfaces, also remain inac-
tive. Ports are considered active if they are connected to an active network device. Non-active port assign-
ments are allowed, but do not change the VLAN’s operational state.
Ports are either statically or dynamically assigned to VLANs. When a port is assigned to a VLAN, a
VLAN port association (VPA) is created and tracked by VLAN management switch software. For more
information about VPAs, see “Defining VLAN Port Assignments” on page 4-6 and Chapter 7, “Assigning
Ports to VLANs.”
Adding/Removing a VLAN
To add a VLAN to the switch configuration, enter vlan followed by a unique VLAN ID number between 2
and 4094, an optional administrative status, and an optional description. For example, the following
command creates VLAN 755 with a description:
-> vlan 755 enable name “IP Finance Network”
By default, administrative status and Spanning Tree are enabled when the VLAN is created and the VLAN
ID is used for the description if one is not specified. Note that quotation marks are required if the descrip-
tion contains multiple words separated by spaces. If the description consists of only one word or multiple
words separated by another character, such as a hyphen, then quotes are not required.
You can also specify a range of VLAN IDs with the vlan command. Use a hyphen to indicate a contigu-
ous range and a space to separate multiple VLAN ID entries. For example, the following command creates
VLANs 10 through 15, 100 through 105, and VLAN 200 on the switch:
-> vlan 10-15 100-105 200 name “Marketing Network”
To remove a VLAN from the switch configuration, use the no form of the vlan command.
-> no vlan 755
-> no vlan 100-105
-> no vlan 10-15 200
When a VLAN is deleted, any router interfaces defined for the VLAN are removed and all VLAN port
associations are dropped. For more information about VLAN router interfaces, see “Configuring VLAN
Router Interfaces” on page 4-10.
Note that up to 253 Spanning Tree instances per switch are supported in the 1x1 Spanning Tree mode.
Since each VLAN with Spanning Tree enabled uses one of these instances, only 253 VLANs can have an
active Spanning Tree instance at any given time.
To create more than 253 VLANs on a switch running in the 1x1 Spanning Tree mode, use the vlan stp
disable, vlan 1x1 stp disable, or vlan flat stp disable command to create a VLAN with Spanning Tree
disabled. See “Enabling/Disabling Spanning Tree for a VLAN” on page 4-9 for more information.
To view a list of VLANs already configured on the switch, use the show vlan command. See “Verifying
the VLAN Configuration” on page 4-12 for more information.
When the administrative status for a VLAN is disabled, VLAN port assignments are retained but traffic is
not forwarded on these ports. If any rules were defined for the VLAN, they are also retained and continue
to classify mobile port traffic. See Chapter 9, “Defining VLAN Rules,” for more information.
Note that quotation marks are required if the description consists of multiple words separated by spaces. If
the description consists of only one word or words are separated by another character, such as a hyphen,
then quotes are not required. For example,
-> vlan 455 name Marketing-IP-Network
• Using the vlan 802.1q command to define tagged VLANs for non-mobile ports. This method allows
the switch to bridge traffic for multiple VLANs over one physical port connection. (See Chapter 24,
“Configuring 802.1Q.”)
• Configuring ports as members of a link aggregate that is assigned to a configured default VLAN. (See
Chapter 25, “Configuring Static Link Aggregation,” and Chapter 26, “Configuring Dynamic Link
Aggregation,” for more information.)
Dynamic assignment applies only to mobile ports. When traffic is received on a mobile port, the packets
are classified using one of the following methods to automatically determine VLAN assignment (see
Chapter 7, “Assigning Ports to VLANs,” for more information):
• Packet is tagged with a VLAN ID that matches the ID of another VLAN that has mobile tagging
enabled. (See “Enabling/Disabling VLAN Mobile Tag Classification” on page 4-8.)
• Packet contents matches criteria defined in a VLAN rule. (See “Configuring VLAN Rule Classifica-
tion” on page 4-8 and Chapter 9, “Defining VLAN Rules.”)
All ports initially belong to default VLAN 1. When the vlan port default command is used, the port’s
default VLAN assignment is changed to the specified VLAN. In the above example, VLAN 955 is now
the default VLAN for port 5 on slot 2 and this port is no longer associated with VLAN 1.
The vlan port default command is also used to change the default VLAN assignment for an aggregate of
ports. The link aggregate control number is specified instead of a slot and port. For example, the follow-
ing command assigns link aggregate 10 to VLAN 755:
-> vlan 755 port default 10
For more information about configuring an aggregate of ports, see Chapter 25, “Configuring Static Link
Aggregation,” and Chapter 26, “Configuring Dynamic Link Aggregation.”
Use the no form of the vlan port default command to remove a default VPA. When this is done, VLAN 1
is restored as the port’s default VLAN.
-> vlan 955 no port default 2/5
1 Use the vlan port mobile command to enable mobility on switch ports that participates in dynamic
VLAN assignment. See Chapter 7, “Assigning Ports to VLANs,”for detailed procedures.
2 Enable/disable mobile port properties that determine mobile port behavior. See Chapter 7, “Assigning
Ports to VLANs,” for detailed procedures.
3 Create VLANs that receives and forward mobile port traffic. See “Adding/Removing a VLAN” on
page 4-5 for more information.
4 Configure the method of traffic classification (VLAN rules or tagged VLAN ID) that triggers dynamic
assignment of mobile ports to the VLANs created in Step 3. See “Configuring VLAN Rule Classification”
on page 4-8 and “Enabling/Disabling VLAN Mobile Tag Classification” on page 4-8.
Once the above configuration steps are completed, dynamic VLAN assignment occurs when a device
connected to a mobile port starts to send traffic. This traffic is examined by switch software to determine
which VLAN has to carry the traffic based on the type of classification, if any, defined for a particular
VLAN.
Note that VLAN mobile tag classification takes precedence over VLAN rule classification. If a mobile
port receives traffic that matches a VLAN rule and also has an 802.1Q VLAN ID tag for a VLAN with
mobile tagging enabled, the port is dynamically assigned to the mobile tag VLAN and not the matching
rule VLAN.
See Chapter 7, “Assigning Ports to VLANs,” and Chapter 9, “Defining VLAN Rules,” for more informa-
tion and examples of dynamic VLAN port assignment.
If a mobile port that is statically assigned to VLAN 10 receives an 802.1Q tagged packet with a VLAN ID
of 1525, the port and packet are dynamically assigned to VLAN 1525. In this case, the mobile port now
has a VLAN port association defined for VLAN 10 and for VLAN 1525. If a mobile port, however,
receives a tagged packet containing a VLAN ID tag of 224, the packet is discarded because the VLAN
mobile tag classification attribute is disabled on VLAN 224.
In essence, the VLAN mobile tag attribute provides a dynamic 802.1Q tagging capability. Mobile ports
can now receive and process 802.1Q tagged packets destined for a VLAN that has this attribute enabled.
This feature also allows the dynamic assignment of mobile ports to more than one VLAN at the same time,
as discussed in the above example.
VLAN mobile tagging differs from 802.1Q tagging as follows:
If 802.1Q tagging is required on a fixed (non-mobile) port, then the vlan 802.1q command is still used to
statically tag VLANs for the port. See Chapter 24, “Configuring 802.1Q,” for more information.
Note the following when using the vlan stp command. For more information about the vlan stp command,
see the OmniSwitch 6250/6350/6450 CLI Reference Guide:
• If the VLAN ID specified with this command is that of a VLAN that does not exist, the VLAN is auto-
matically created.
• This command configures the VLAN STP status for both the 1x1 and flat Spanning Tree modes. Using
the 1x1 or flat parameter with this command, configures the STP status only for the mode specified by
the parameter.
• Up to 253 Spanning Tree instances per switch are supported in the 1x1 Spanning Tree mode. Since
each VLAN with Spanning Tree enabled uses one of these instances, only 253 VLANs can have an
active Spanning Tree instance at any given time.
• To create more than 253 VLANs on a switch running in the 1x1 Spanning Tree mode, use the vlan stp
disable, vlan 1x1 stp disable, or vlan flat stp disable form of this command to create a VLAN with
Spanning Tree disabled.
STP does not become operationally active on a VLAN unless the VLAN is operationally active, which
occurs when at least one active port is assigned to the VLAN. Also, STP is enabled/disabled on individual
ports. So even if STP is enabled for the VLAN, a port assigned to that VLAN must also have STP enabled.
See Chapter 12, “Configuring Spanning Tree.”
To determine the total number of VLANs configured on the switch, and the number of VLANs with IP
router interfaces configured, use the show vlan router mac status command. For more information about
this command, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
1 Create a VLAN on each switch with the same VLAN ID number (for example, VLAN 10).
2 If using mobile ports for end user device connections, define VLAN rules that classifies mobile port
traffic into the VLAN created in Step 1.
3 On each switch, assign the ports that provides connections to other switches to the VLAN created in
Step 1.
4 On each switch, assign the ports that provides connections to end user devices (for example, worksta-
tions) to the VLAN created in Step 1. (If using mobile ports, this step occurs automatically when the
device connected to the mobile port starts to send traffic.)
The following diagram shows the physical configuration of an example VLAN bridging domain:
Switch B Switch C
138.0.0.3 138.0.0.4
2/2 3/10
VLAN 10 VLAN 10
2/3 3/9
2/10 3/2
VLAN 10 VLAN 10
2/9 3/1
VLAN 10 VLAN 10 VLAN 10 VLAN 10
3/8 3/3
Switch A Switch D
138.0.0.5
138.0.0.2
In the above diagram, VLAN 10 exists on all four switches and the connection ports between these
switches are assigned to VLAN 10. The workstations can communicate with each other because the ports
to which they are connected are also assigned to VLAN 10. It is important to note that connection cables
do not have to connect to the same port on each switch. The key is that the port must belong to the same
VLAN on each switch. To carry multiple VLANs between switches across a single physical connection
cable, use the 802.1Q tagging feature (see Chapter 24, “Configuring 802.1Q”).
The connection between Switch C and D is shown with a broken line because the ports that provide this
connection are in a blocking state. Spanning Tree is active by default on all switches, VLANs and ports.
The Spanning Tree algorithm determined that if all connections between switches were active, a network
loop would exist that could cause unnecessary broadcast traffic on the network. The path between Switch
C and D was shut down to avoid such a loop. See Chapter 12, “Configuring Spanning Tree,” for informa-
tion about how Spanning Tree configures network topologies that are loop free.
The following diagram shows the same bridging domain example as seen by the end user workstations.
Because traffic between these workstations is bridged across physical switch connections within the
VLAN 10 domain, the workstations are basically unaware that the switches even exist. Each workstation
believes that the others are all part of the same VLAN, even though they are physically connected to
different switches.
VLAN 10
138.0.0.3
138.0.0.4
138.0.0.2
138.0.0.5
Creating a VLAN bridging domain across multiple switches and/or stacks of switches allows VLAN
members to communicate with each other, even if they are not connected to the same physical switch. This
is how a logical grouping of users can traverse a physical network setup without routing and is one of the
many benefits of using VLANs.
show vlan Displays a list of all VLANs configured on the switch and the status of
related VLAN properties (for example, admin and Spanning Tree status
and router port definitions).
show vlan port Displays a list of VLAN port assignments.
show ip interface Displays VLAN IP router interface information.
show vlan router mac status Displays the current MAC router operating mode (single or multiple)
and VLAN router port statistics.
For more information about the resulting displays from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide. An example of the output for the show vlan and show vlan port commands is
also given in “Sample VLAN Configuration” on page 4-3.
The GARP VLAN Registration Protocol (GVRP) facilitates in controlling virtual local area networks
(VLANs) in a large network. It is an application of Generic Attribute Registration Protocol (GARP) and
provides VLAN registration service. GVRP enables devices to dynamically learn their VLAN
memberships.
GVRP is compliant with 802.1Q standard. It dynamically learns and propagates VLAN membership
information across a bridged network. GVRP dynamically maintains and updates the registration and
de-registration of VLANs and prunes unnecessary broadcast and unicast traffic. From the GVRP
information, a device can continuously update its knowledge of the set of VLANs that currently have
active nodes and on the ports through which those nodes can be reached.
In This Chapter
This chapter describes the basic components of GVRP and their configuration through the Command Line
Interface (CLI). CLI commands are used in the configuration examples; for more details about the syntax
of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Enabling GVRP on page 5-7.
• Enabling Transparent Switching on page 5-8.
• Configuring Maximum Number of VLANs on page 5-8.
• Configuring GVRP Registration on page 5-9.
• Configuring GVRP Applicant Mode on page 5-10.
• Modifying GVRP Timers on page 5-10.
• Restricting VLAN Registration on page 5-11.
• Restricting Static VLAN Registration on page 5-12.
• Restricting VLAN Advertisements on page 5-12.
GVRP Specifications
IEEE Standards Supported IEEE Std. 802.1D - 2004, Media Access Control
(MAC) Bridges
IEEE Draft Std. P802.1Q-REV/D5.0
Platforms Supported OmniSwitch 6250, 6350, 6450
Maximum GVRP VLANs 256
GVRP Defaults
The following table lists the defaults for GVRP configuration:
GARP Overview
GARP was introduced to avoid manual configuration of devices and applications in a large network. It
enables dynamic configuration of devices and applications in a network. It also provides a generic
framework whereby devices in a bridged LAN can register and de-register attribute values, such as VLAN
identifiers, with each other. These attributes are propagated through devices in the bridged LAN. GARP
consists of:
GARP Information Declaration (GID)—The part of GARP that generates data from the switch.
GARP Information Propagation (GIP)—The part of GARP that distributes data to different switches.
A GARP applicant may or may not choose to actively participate in declaring and registering an attribute
value. By declaring an attribute, a GARP applicant indicates to other applicants that it is either associated
with the attribute or it is interested to know about the other applicants associated with that attribute. A
GARP applicant that declares attributes is referred to as an active member. A passive member is an appli-
cant interested in an attribute but does not initiate GARP PDUs when it is aware that other applicants have
also registered the attribute.
The following messages are used in GARP:
JoinIn and JoinEmpty—Used by an applicant (including itself) associated with an attribute. Receiving
JoinIn messages from other applicants or transmitting JoinEmpty messages enables an applicant to regis-
ter the attribute.
LeaveIn and LeaveEmpty—Used by an applicant to withdraw its declaration when it is no more associ-
ated with an attribute.
LeaveAll—Used for periodic declarations and registration maintenance. An applicant periodically sends
LeaveAll messages, which enable other applicants to indicate their attributes’ registered states.
These messages indicate the current state of the sender applicant device to other GARP applicant devices.
With this information, these GARP applicant devices can modify their behavior associated with the attri-
bute (declare and withdraw).
GVRP Overview
GVRP, an application of GARP, is designed to propagate VLAN information from device to device. With
GVRP, a single switch is manually configured with all the desired VLANs for the network, and all the
other switches on the network learn those VLANs dynamically. An end station can be plugged into a
switch and be connected to its desired VLAN. However, end stations need GVRP-aware Network
Interface Cards (NIC) to make use of GVRP.
GVRP sends information encapsulated in an Ethernet frame to a specific MAC address
(01:80:C2:00:00:21). Based on the received registration information (Join message of GARP), VLAN
information is learned on a system. GVRP enables new dynamic VLANs on a device or dynamically regis-
ters a port to an existing VLAN. In effect, based on the received registration information of a VLAN, the
port becomes associated with that VLAN. Similarly, whenever de-registration information is received for a
VLAN (Leave message of GARP) on a particular port, the association of that VLAN with the port may get
deleted.
A GVRP-enabled port sends GVRP PDUs advertising the VLAN. Other GVRP-aware ports receiving
advertisements over a link can dynamically join the advertised VLAN. All ports of a dynamic VLAN
operate as tagged ports for that VLAN. Also, a GVRP-enabled port can forward an advertisement for a
VLAN it learned about from other ports on the same switch. However, that forwarding port does not join
that VLAN until an advertisement for that VLAN is received on that port.
1 2 3 4 5
Switch A has 3 VLANs configured as static VLANs (10, 20, and 30). Other switches on the same network
learns these 3 VLANs as dynamic VLANs. Also, the end station connected on port 5 is statically config-
ured for VLAN 50. Port 1 on Switch A is manually configured for VLANs 10, 20, and 30. Hence, as the
diagram above shows,
1 Port 1 on Switch A advertises VLAN IDs (VIDs) 10, 20, and 30.
2 Port 2 on Switch B receives the advertisements. VLANs 10, 20, and 30 are created as dynamic VLANs
on this switch and Port 2 becomes a member of VLANs 10, 20, and 30.
3 Port 3 on Switch B is triggered to advertise VLANs 10, 20, and 30, but does not become a member of
these VLANs.
4 Port 4 on Switch C receives the advertisements. VLANs 10, 20, and 30 are created as dynamic VLANs
on this switch and Port 4 becomes a member of VLANs 10, 20, and 30.
5 Port 5 advertises VLANs 10, 20, and 30, but this port is not a member of these VLANs.
Note. Default VLAN (VLAN 1) exists on all switches, but it is not considered here.
The above sequence of advertisements and registration of VLANs results in the following configuration:
1 2 3 4 5
Here, the end station advertises itself as a member of VLAN 50. As the above diagram shows,
1 Port 5 receives the advertisement and Switch C creates VLAN 50 as a dynamic VLAN. Port 5 of
Switch C becomes a member of VLAN 50.
2 Port 4 advertises VLAN 50, but is not a member of VLAN 50.
3 Port 3 of Switch B receives the advertisement, Switch B creates the dynamic VLAN 50, and Port 3
becomes a member of VLAN 50.
5 Port 1 on Switch A receives the advertisement, creates dynamic VLAN 50. Port 1 becomes a member
of VLAN 50.
The resulting configuration is depicted below:
1 2 3 4 5
Note. Every port on a switch is not a member of all the VLANs. Only those ports that receive the
advertisement become members of the VLAN being advertised.
2 Assign a port to the VLAN using the vlan port default command. For example:
3 Propagate the VLAN out of the assigned port using the vlan 802.1q command. For example, the
following command propagates VLAN 5 out of port 3/2:
-> vlan 5 802.1q 3/2
-> gvrp
5 Enable GVRP on the port by using the gvrp port command. For example, the following command
enables GVRP on port 3/2 of the switch:
-> gvrp port 3/2
6 Restrict a port from becoming a member of the statically created VLAN by using the
gvrp static-vlan restrict command. For example, the following command restricts port 3/5 from becom-
ing a member of static VLAN 10:
-> gvrp static-vlan restrict port 3/5 10
7 To view the global configuration details of the router, enter the show gvrp configuration command.
The globally configured details is displayed as shown:
-> show gvrp configuration
8 To view GVRP configuration for a specific port, enter the show gvrp configuration linkagg/port
command.The configuration details of the particular port is displayed as shown:
-> show gvrp configuration port 1/21
Port 1/21:
GVRP Enabled : yes,
Registrar Mode : normal,
Applicant Mode : participant,
Join Timer (msec) : 600,
Leave Timer (msec) : 1800,
LeaveAll Timer (msec) : 30000,
Legacy Bpdu : disabled
VLAN Memberships:
VLAN Id Static Restricted Restricted
Registration Registration Applicant
---------------+---------------+---------------+-----------
1 LEARN FALSE FALSE
2 LEARN FALSE FALSE
11 LEARN FALSE FALSE
12 LEARN FALSE FALSE
13 LEARN FALSE FALSE
14 LEARN FALSE FALSE
15 LEARN FALSE FALSE
16 LEARN FALSE FALSE
17 LEARN FALSE FALSE
18 LEARN FALSE FALSE
19 LEARN FALSE FALSE
20 LEARN FALSE FALSE
51 RESTRICT FALSE FALSE
52 RESTRICT FALSE FALSE
53 LEARN TRUE FALSE
54 LEARN TRUE FALSE
55 LEARN FALSE TRUE
56 LEARN FALSE TRUE
57 LEARN FALSE FALSE
58 LEARN FALSE FALSE
59 LEARN FALSE FALSE
60 LEARN FALSE FALSE
Configuring GVRP
This section describes how to configure GVRP using Alcatel’s Command Line Interface (CLI) commands.
Enabling GVRP
GVRP is used primarily to prune unnecessary broadcast and unknown unicast traffic, and dynamically
create and manage VLANs. GVRP has to be globally enabled on a switch before it can start forwarding
GVRP frames.
To enable GVRP globally on the switch, enter the gvrp command at the CLI prompt as shown:
-> gvrp
To disable GVRP globally on the switch, use the no form of the gvrp command as shown:
-> no gvrp
Note. Disabling GVRP globally leads to the deletion of all learned VLANs.
GVRP can be enabled on ports regardless of whether it is globally enabled or not. However, for the port to
become an active participant, you have to enable GVRP globally on the switch. By default, GVRP is
disabled on the ports. To enable GVRP on a specified port, use the gvrp port command.
For example, to enable GVRP on port 2 of slot 1, enter:
-> gvrp port 1/2
To disable GVRP on a specific port, use the no form of the command as shown:
-> no gvrp port 1/2
Note. GVRP can be configured only on fixed, 802.1 Q and aggregate ports. It cannot be configured on
mirror, aggregable, mobile, and MSTI Trunking ports.
Note. If GVRP is globally enabled on a switch, transparent switching has no effect on the switch.
You can configure the switch to propagate GVRP frames transparently using the gvrp transparent
switching command, as shown:
-> gvrp transparent switching
Use the no form of this command to disable the transparent switching capability of the switch. For exam-
ple:
-> no gvrp transparent switching
Note. When both GVRP and GVRP transparent switching are globally disabled, the switch discards the
GVRP frames.
Here, the number of dynamic VLANs the switch can create is set to a maximum of 150.
To view the registration mode of the port, use the show gvrp configuration linkagg/port command. For
example:
-> show gvrp configuration port 3/2
Note. The registration mode for the default VLANs of all the ports in the switch is set to fixed.
To view the registration mode of the port, use the show gvrp configuration linkagg/port command. For
example, to view the mode of port 1/21, enter the following:
-> show gvrp configuration port 3/2
The GVRP registration mode of the port can be set to default value by using the no form of
gvrp registration command.
To set the GVRP registration mode of port 3/2 to default mode (normal mode) enter the following
command:
-> no gvrp registration port 3/2
When a port is set to participant mode, GVRP protocol exchanges are allowed only if the port is set to the
STP forwarding state.
To set the applicant mode of port 3/2 to participant mode, enter the following:
-> gvrp applicant participant port 3/2
When a port is set to non-participant mode, GVRP PDUs are not sent through the STP forwarding and
blocking ports.
To set the applicant mode of port 3/2 to non-participant mode, enter the following:
-> gvrp applicant non-participant port 3/2
The applicant mode of the port can be set to the default value by using the no form of the gvrp applicant
command. To set the GVRP applicant mode of port 3/2 to the default mode (participant mode), enter the
following command:
-> no gvrp applicant port 3/2
The default values of the Join, Leave, and LeaveAll timers are 200 ms, 600 ms, and 10000 ms,
respectively.
When you set the timer values, the value for the Leave timer has to be greater than or equal to thrice the
Join timer value (Leave>=Join * 3). The LeaveAll timer value must be greater than the Leave timer value
(LeaveAll > Leave). If you attempt to set a timer value that does not adhere to these rules, an error
message is displayed.
For example, if you set the Leave timer to 900 ms and attempt to configure the Join timer to 450 ms, an
error is returned. You need to set the Leave timer to at least 1350 ms and then set the Join timer to 450 ms.
To modify the Join timer value, use the gvrp timer command. For example, to modify the Join timer value
of port 3/2, enter the following:
-> gvrp timer join 400 port 3/2
The Join timer value of port 3/2 is now set to 400 ms.
To set the Join timer to the default value, use the no form of the command as shown:
-> no gvrp timer join port 3/2
To set the Leave timer value of port 3/2 to 1200 ms, enter the command as shown:
-> gvrp timer leave 1200 port 3/2
To set the LeaveAll timer of port 3/2 to 1400 ms, enter the command as shown:
-> gvrp timer leaveall 1200 port 3/2
To view the timer value assigned to a particular port, use the show gvrp timer command. For example, to
view the timer value assigned to port 1/21, enter the command as shown:
-> show gvrp configuration port 1/21
Note. Set the same GVRP timer value on all the connected devices.
Here, VLAN 4 cannot be learned by the device dynamically. However, if the VLAN already exists on the
device as a static VLAN, it can be mapped to the receiving port.
To allow dynamic VLAN registrations on the port, use the no form of the gvrp restrict-vlan-registration
command as shown:
-> no gvrp restrict-vlan-registration port 3/1 4
Here, the port 1/2 is restricted from becoming a GVRP member of VLAN 5.
To restrict a port from becoming a member of a range of statically created VLANs, enter the
gvrp static-vlan restrict command as shown:
-> gvrp static-vlan restrict port 1/2 5-9
clear gvrp statistics Clears GVRP statistics for all the ports, an aggregate of ports, or a spe-
cific port.
show gvrp last-pdu-origin Displays the source MAC address of the last GVRP message received
on a specified port or an aggregate of ports.
show gvrp configuration Displays the global configuration for GVRP.
show gvrp configuration port Displays the GVRP configuration status for all the ports.
show gvrp configuration link- Displays the GVRP configuration for a specific port or an aggregate of
agg/port ports.
show gvrp timer Displays the timer values configured for all the ports or a specific port.
For more information about the displays that result from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
Multiple VLAN Registration Protocol (MVRP) is standards-based Layer 2 network protocol for
automatic configuration of VLAN information on switches. It was defined in the 802.1ak amendment to
802.1Q-2005.
MVRP provides a method to share VLAN information dynamically and configure the needed VLANs
within a layer 2 network. For example, in order to add a switch port to a VLAN, only the end port, or the
VLAN-supporting network device connected to the switchport, has to be reconfigured, and all necessary
VLAN trunks are dynamically created on the other MVRP-enabled switches. MVRP helps to maintain
VLAN configuration dynamically based on current network configurations.
In This Chapter
This chapter describes the MVRP feature and how to configure it through the Command Line Interface
(CLI). CLI commands are used in the configuration examples; for more details about the syntax of
commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide. This chapter provides an overview
of MVRP and includes the following information:
• “Enabling MVRP” on page 6-10
MVRP Specifications
IEEE Standards Supported IEEE 802.1ak-2007 Amendment 7: Multiple Registration Protocol
IEEEStd802.1Q-2005 Corrigendum 2008
Platforms Supported OmniSwitch 6250, 6350, 6450
Maximum MVRP VLANs 256
MVRP Defaults
The following table lists the defaults for MVRP configuration.
2 Assign a port to the VLAN using the vlan port default command. For example:
3 Tag the port with one or more VLANs using the vlan 802.1q command. For example:
Note. If MVRP is configured, GVRP cannot be configured on that switch and GVRP frames are ignored
by the switch.
5 Enable MVRP on the port by using the mvrp port command. For example, the following command
enables MVRP on port 1/2 of the switch:
-> mvrp port 1/2 enable
6 (Optional) Restrict a port from becoming a member of the statically created VLAN by using the mvrp
static-vlan-restrict command. For example, the following command restricts port 1/5 from becoming a
member of static VLAN 10:
-> mvrp port 1/5 static-vlan-restrict vlan 10
Note. To view the global configuration details of the router, enter the show mvrp configuration
command. The globally configured details are displayed as shown:
-> show mvrp configuration
MVRP Enabled : yes,
Transparent Switching Enabled: no,
Maximum VLAN Limit : 256
To view the MVRP configuration for a specific port, enter the show mvrp port command. The configura-
tion data of the particular port is displayed as shown:
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for information about the fields in this display.
MRP Overview
Multiple Registration Protocol (MRP) was introduced as a replacement for GARP with the IEEE
802.1ak-2007 amendment. The Multiple VLAN Registration Protocol (MVRP) defines a MRP
Application that provides the VLAN registration service.
MVRP provides a mechanism for dynamic maintenance of the contents of dynamic VLAN registration
Entries for each VLAN, and for propagating the information they contain to other bridges. This
information allows MVRP-aware devices to dynamically establish and update their knowledge of the set
of VLANs that currently have active members, and through which ports those members can be reached.
The main purpose of MVRP is to allow switches to automatically discover some of the VLAN
information that would otherwise need to be manually configured.
MVRP Overview
MVRP acts as an MRP application, sending and receiving MVRP information encapsulated in an ethernet
frame on a specific MAC address. MVRP allows both end stations and bridges in a bridged local area
network to issue and revoke declarations relating to membership of VLANs. Each MVRP device that
receives the declaration in the network creates or updates a dynamic VLAN registration entry in the
filtering database to indicate that the VLAN is registered on the reception port.
In this way, MVRP provides a method to share VLAN information within a layer 2 network dynamically,
and configure the needed VLANs. For example, in order to add a switch port to a VLAN, only the end
port, or the VLAN-supporting network device connected to the switchport, need be reconfigured, and all
necessary VLAN trunks are dynamically created on the other MVRP-enabled switches. Without using
MVRP, either a manual configuration of VLAN trunks or use of a manufacturer-specific proprietary
method is necessary. In short, MVRP helps to maintain VLAN configuration dynamically based on current
network configurations.
1 2 3 4 5
Switch A has 3 VLANs configured as static VLANs (10, 20, and 30). Other switches on the same network
learn these 3 VLANs as dynamic VLANs. Also, the end station connected on port 5 is statically
configured for VLAN 50. Port 1 on Switch A is manually configured for VLANs 10, 20, and 30. All the
ports are in the same Spanning tree instance and are in forwarding state. Hence, as the
Initial Configuration of MVRP diagram shows,
1 Port 1 on Switch A advertises VLAN IDs (VIDs) 10, 20, and 30.
2 Port 2 on Switch B receives the advertisements. VLANs 10, 20, and 30 are created as dynamic VLANs
on this Switch B and Port 2 becomes a member of VLANs 10, 20, and 30.
3 Port 3 on Switch B is triggered to advertise VLANs 10, 20, and 30, but does not become a member of
these VLANs.
4 Port 4 on Switch C receives the advertisements. VLANs 10, 20, and 30 are created as dynamic VLANs
on Switch C and Port 4 becomes a member of VLANs 10, 20, and 30.
5 Port 5 advertises VLANs 10, 20, and 30, but this port is not a member of these VLANs.
Note. Default VLAN (VLAN 1) exists on all switches, but it is not considered here.
The configuration sequence of advertisements and registration of VLANs results in the following
configuration.
1 2 3 4 5
Here, the end station advertises itself as a member of VLAN 50. As the Dynamic Learning of VLANs 10, 20,
and 30 diagram shows,
1 Port 5 receives the advertisement and Switch C creates VLAN 50 as a dynamic VLAN. Port 5 of
Switch C becomes a member of VLAN 50.
2 Port 4 advertises VLAN 50, but is not a member of VLAN 50.
3 Port 3 of Switch B receives the advertisement, Switch B creates the dynamic VLAN 50, and Port 3
becomes a member of VLAN 50.
4 Port 2 advertises VLAN 50, but is not a member of this VLAN.
5 Port 1 on Switch A receives the advertisement, creates dynamic VLAN 50. Port 1 becomes a member
of VLAN 50.
The resulting configuration is depicted as follows:
1 2 3 4 5
Note. Every port on a switch is not a member of all the VLANs. Only those ports that receive the
advertisement become members of the VLAN being advertised.
GVRP
If MVRP is configured, GVRP cannot be configured and the GVRP frames are ignored on that switch.
MVRP is functionally independent of the GVRP.
When the device has legacy GVRP commands in the boot.cfg (for example, during image upgrade from a
previous release which does not support MVRP) and the default mode is configured for MVRP, the GVRP
commands are still accepted and the VLAN registration mode is internally changed to GVRP.
There is an option to change the operational mode between MVRP and GVRP. But, when you change the
mode, it results in the complete deletion of static as well as dynamic configurations of the existing
operational mode.
STP
MVRP feature is supported only in STP flat mode. If MVRP is configured in the system with STP flat
mode, then STP mode cannot be changed to 1x1 mode. When a topology change is detected by STP,
MAC addresses for the dynamic VPAs learned by MVRP is also deleted.
IPM VLAN
MVRP is not supported on IP Multicast VLANs (IPMVLANs). If MVRP PDU for IPMVLAN
registration is received on standard/network port, the PDUs are discarded. IPMVLAN is not advertised by
MVRP.
Configuring MVRP
This section describes how to configure MVRP using the Command Line Interface (CLI) commands.
Enabling MVRP
MVRP is used primarily to prune unnecessary broadcast and unknown unicast traffic, and dynamically
create and manage VLANs. MVRP has to be globally enabled on a switch before it can start forwarding
MVRP frames. When MVRP is configured on a switch, GVRP cannot be configured on that switch and
when a port is enabled for MVRP, it cannot be converted as a mobile, mirroring, aggregate, VPLS Access,
or a VLAN stacking User port.
To enable MVRP globally on the switch, enter the mvrp command at the CLI prompt as shown:
-> mvrp enable
To disable MVRP globally on the switch, use disable option of the mvrp command as shown:
-> mvrp disable
Note. Disabling MVRP globally leads to the deletion of all learned VLANs.
MVRP can be enabled on ports regardless of whether it is globally enabled or not. However, for the port to
become an active participant, MVRP must be globally enabled on the switch. By default, MVRP is
disabled on the ports. To enable MVRP on a specified port, use the mvrp port command.
For example, to enable MVRP on port 2 of slot 1, enter:
-> mvrp port 1/2 enable
To disable MVRP on a specific port, use disable option of the mvrp port command as shown:
-> mvrp port 1/2 enable
Note. MVRP can be configured only on fixed, 802.1 Q and aggregate ports. It cannot be configured on
mirror, aggregate, mobile, VPLS Access, and VLAN Stacking User ports.
Note. If MVRP is globally enabled on a switch, transparent switching does not have any effect on the
switch.
You can configure the switch to propagate MVRP frames transparently using the mvrp port command, as
shown:
-> mvrp transparent-switching enable
Use the disable option of this command to disable the transparent switching capability of the switch. For
example:
-> mvrp transparent-switching disable
Note. When both MVRP and MVRP transparent switching are globally disabled, the switch discards the
MVRP frames.
To view the registration mode of the port, use the show mvrp port command. For example:
-> show mvrp port 1/2
To view the registration mode of the port, use the show mvrp port command. For example,
-> show mvrp port 1/2
Note. The registration mode for the default VLANs of all the ports in the switch is set to normal.
To view the registration mode of the port, use the show mvrp port command. For example,
-> show mvrp port 1/2
MVRP Enabled : no,
Registrar Mode : forbidden,
Applicant Mode : participant,
Join Timer (msec) : 600,
Leave Timer (msec) : 1800,
LeaveAll Timer (msec) : 30000,
Periodic Timer (sec) : 1,
Periodic Tx status : disabled
To view the MVRP configurations for all the ports, including timer values, registration and applicant
modes, enter the following:
-> show mvrp port enabled
When a port is set to participant mode, MVRP protocol exchanges are allowed only if the port is set to the
STP forwarding state.
To set the applicant mode of port 1/2 to participant mode, enter the following:
-> mvrp port 1/2 applicant participant
When a port is set to non-participant mode, MVRP PDUs are not sent through the STP forwarding and
blocking ports.
To set the applicant mode of port 1/2 to non-participant mode, enter the following:
-> mvrp port 1/2 non-participant
The applicant mode of the port can be set to the default value by using the mvrp applicant command. To
set the MVRP applicant mode of port 1/2 to the default mode (active mode), enter the following
command:
-> mvrp port 1/2 active
• Leave timer—The wait time taken to remove the port from the VLAN after receiving a Leave message
on that port.
• LeaveAll timer—The time an MVRP instance takes to generate LeaveAll messages. The LeaveAll
message instructs the port to modify the MVRP state of all its VLANs to Leave.
• Periodic timer—The time frequency with which the messages are transmitted again and again.
The default values of the Join, Leave, and LeaveAll timers are 600 ms, 1800 ms, and 30000 ms,
respectively.
When you set the timer values, the value for the Leave timer must be greater than or equal to twice the
Join timer value plus 100 milliseconds.(Leave>=Join * 2 +100). The LeaveAll timer value must be
greater than or equal to the Leave timer value (LeaveAll >= Leave). If you attempt to set a timer value
that does not adhere to these rules, an error message is displayed.
For example, if you set the Leave timer to 1700 ms and attempt to configure the Join timer to 400 ms, an
error is returned. Set the Leave timer to at least 1800 ms and then set the Join timer to 600 ms.
To modify the Join timer value, use the mvrp timer join command. For example, to modify the Join timer
value of port 1/2, enter the following:
-> mvrp port 1/2 timer join 600
The Join timer value of port 1/2 is now set to 600 ms.
To set the Leave timer value of port 1/2 to 1800 ms, enter the command as shown:
-> mvrp port 1/2 timer leave 1800
To set the LeaveAll timer of port 1/2 to 30000 ms, enter the command as shown:
-> mvrp port 1/2 timer leaveall 30000
To set the Periodic timer of port 1/2 to 1 second, enter the command as shown:
-> mvrp port 1/2 timer periodic-timer 1
To view the timer value assigned to a particular port, use the show mvrp timer command.
-> show mvrp port 1/2 timer
Note. Set the same MVRP timer value on all the connected devices.
Here, VLAN 4 cannot be learned by the device dynamically. However, if the VLAN exists on the device
as a static VLAN, it can be mapped to the receiving port.
To allow dynamic VLAN registrations on the port, use the no form of the
mvrp restrict-vlan-registration command as shown:
-> no mvrp port 1/1 restrict-vlan-registration vlan 4
Here, the port 1/9 is restricted from becoming a MVRP member of VLAN 5.
To restrict a port from becoming a member of a range of statically created VLANs, enter the
mvrp static-vlan-restrict command as shown:
-> mvrp port 1/9 static-vlan-restrict vlan 5-9
show mvrp last-pdu-origin Displays the source MAC address of the last MVRP message
received on specific ports or aggregates.
show mvrp configuration Displays the global configuration for MVRP.
show mvrp linkagg Displays the MVRP configuration for a specific port or an aggregate
of ports.
show mvrp port Displays the MVRP configurations for all the ports, including timer
values, registration and applicant modes.
show mvrp vlan-restrictions Displays the list of VLANS learned through MVRP and their details.
show mvrp timer Displays the timer values configured for all the ports or a specific
port.
show mvrp statistics Displays the MVRP statistics for all the ports, aggregates, or specific
ports.
mvrp clear-statistics Clears MVRP statistics for all the ports, an aggregate of ports, or a
specific port.
For more information about the output details that result from these commands, see the OmniSwitch 6250/
6350/6450 CLI Reference Guide.
Initially all switch ports are non-mobile (fixed) and are assigned to VLAN 1, which is also their config-
ured default VLAN. When additional VLANs are created on the switch, ports are assigned to the VLANs
so that traffic from devices connected to these ports is bridged within the VLAN domain. Switch ports are
either statically or dynamically assigned to VLANs.
Methods for statically assigning ports to VLANs include the following:
• Using the vlan port default command to define a new configured default VLAN for both non-mobile
(fixed) and mobile ports. (See “Statically Assigning Ports to VLANs” on page 7-4.)
• Using the vlan 802.1q command to define tagged VLANs for non-mobile ports. This method allows
the switch to bridge traffic for multiple VLANs over one physical port connection. (See Chapter 24,
“Configuring 802.1Q.”)
• Configuring ports as members of a link aggregate that is assigned to a configured default VLAN. (See
Chapter 25, “Configuring Static Link Aggregation,” and Chapter 26, “Configuring Dynamic Link
Aggregation.”)
Dynamic assignment applies only to mobile ports. When traffic is received on a mobile port, the packets
are classified using one of the following methods to determine VLAN assignment (see “Dynamically
Assigning Ports to VLANs” on page 7-5 for more information):
• Packet is tagged with a VLAN ID that matches the ID of another VLAN that has mobile tagging
enabled.
• Packet contents matches criteria defined in a VLAN rule.
Regardless of how a port is assigned to a VLAN, once the assignment occurs, a VLAN port association
(VPA) is created and tracked by VLAN management software on each switch.
In This Chapter
This chapter describes how to statically assign ports to a new default VLAN and configure mobile ports
for dynamic assignment through the Command Line Interface (CLI). CLI commands are used in the
configuration examples; for more details about the syntax of commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Statically assigning ports to VLANs on page 7-4.
• Dynamically assigning ports to VLANs (port mobility) page 7-10.
• Configuring mobile port properties (including authentication) on page 7-16.
2 Assign switch ports 2 through 5 on slot 3 to VLAN 255 using the following command:
VLAN 255 is now the configured default VLAN for ports 2 through 5 on slot 3.
4 Disable the default VLAN parameter for mobile ports 3/4 and 3/5 using the following command:
With this parameter disabled, VLAN 255 does not carry any traffic received on 3/4 or 3/5 that does not
match any VLAN rules configured on the switch.
Note. Optional. To verify that ports 2 through 5 on slot 3 were assigned to VLAN 255, enter show vlan
followed by 255 then port. For example:
-> show vlan 255 port
port type status
--------+---------+--------------
3/2 default inactive
3/3 default inactive
3/4 default inactive
3/5 default inactive
To verify the mobile status of ports 4 and 5 on slot 3 and determine which mobile port parameters are
enabled, enter show vlan port mobile followed by a slot and port number. For example:
-> show vlan port mobile 3/4
Mobility : on,
Config Default Vlan: 255,
Default Vlan Enabled: off,
Default Vlan Perm : on,
Default Vlan Restore: on,
Authentication : off,
Ignore BPDUs : off
Port 3/2 is now assigned to VLAN 755 and no longer associated with VLAN 1. In addition, VLAN 755 is
now the new configured default VLAN for the port.
A configured default VLAN is the VLAN statically assigned to a port. Any time the vlan port default
command is used, the VLAN assignment is static and a new configured default VLAN is defined for the
port. This command is also the only way to change a non-mobile port VLAN assignment. In addition, non-
mobile ports can only retain one VLAN assignment, unlike mobile ports that can dynamically associate
with multiple VLANs. See “Dynamically Assigning Ports to VLANs” on page 7-5 for more information
about mobile ports.
Additional methods for statically assigning ports to VLANs include the following:
• Using the vlan 802.1q command to define tagged VLANs for non-mobile ports. This method allows
the switch to bridge traffic for multiple VLANs over one physical port connection. (See Chapter 24,
“Configuring 802.1Q,” for more information.)
• Configuring ports as members of a link aggregate that is assigned to a configured default VLAN. (See
Chapter 25, “Configuring Static Link Aggregation,” and Chapter 26, “Configuring Dynamic Link
Aggregation,” for more information.)
When a port is statically assigned to a VLAN, a VLAN port association (VPA) is created and tracked by
VLAN management software on each switch. To display a list of all VPAs, use the show vlan port
command. For more information, see “Verifying VLAN Port Associations and Mobile Port Properties” on
page 7-18.
mobile tagging enabled, the port is dynamically assigned to the mobile tag VLAN and not the match-
ing rule VLAN.
• If the administrative status of a mobile tag VLAN is disabled, dynamic mobile port assignments are
retained but traffic on these ports is filtered for the disabled VLAN. However, the VLAN mobile tag
attribute remains active and continues to classify mobile port traffic for VLAN membership.
The following example shows how mobile ports are dynamically assigned using VLAN mobile tagging to
classify mobile port traffic. This example includes diagrams showing the initial VLAN port assignment
configuration and a diagram showing how the configuration looks after mobile port traffic is classified.
In the initial VLAN port assignment configuration shown below,
• All three ports have workstations that are configured to send packets with an 802.1Q VLAN ID tag for
three different VLANs (VLAN 2, 3, and 4).
• Mobility is enabled on each of the workstation ports.
• VLAN 1 is the configured default VLAN for each port.
• VLANs 2, 3, and 4 are configured on the switch, each one has VLAN mobile tagging enabled.
OmniSwitch
VLAN 2
Mobile Tag Enabled
VLAN 4
Mobile Tag Enabled
VLAN 1
Default VLAN VLAN 3
Mobile Tag Enabled
As soon as the workstations start sending traffic, switch software checks the 802.1Q VLAN ID tag of the
frames and looks for a VLAN that has the same ID and also has mobile tagging enabled. Since the work-
stations are sending tagged packets destined for the mobile tag enabled VLANs, each port is assigned to
the appropriate VLAN without user intervention. As the diagram on page 7-7 shows,
• Port 1 is assigned to VLAN 2, because the workstation is transmitting tagged packets destined for
VLAN 2.
• Port 2 is assigned to VLAN 3 because the workstation is transmitting tagged packets destined for
VLAN 3.
• Port 3 is assigned to VLAN 4 because the workstation is transmitting tagged packets destined for
VLAN 4.
• All three ports, however, retain their default VLAN 1 assignment, but now have an additional VLAN
port assignment that carries the matching traffic on the appropriate rule VLAN.
OmniSwitch
VLAN 2 VLAN 4
IP Network 130.0.0.0 IP Network 140.0.0.0
VLAN 1
Default VLAN
VLAN 3
IP Network 138.0.0.0
Dynamic VPA
Default VLAN
OmniSwitch
VLAN 2
IP Network 130.0.0.0
VLAN 4
IP Network 140.0.0.0
VLAN 1
Default VLAN VLAN 3
IP Network 138.0.0.0
As soon as the workstations start sending traffic, switch software checks the source subnet of the frames
and looks for a match with any configured IP network address rules. Since the workstations are sending
traffic that matches a VLAN rule, each port is assigned to the appropriate VLAN without user interven-
tion. As the diagram on page 7-10 shows,
• Port 1 is assigned to VLAN 2, because the workstation is transmitting IP traffic on network 130.0.0.0
that matches the VLAN 2 network address rule.
• Port 2 is assigned to VLAN 3 because the workstation is transmitting IP traffic on network 138.0.0.0
that matches the VLAN 3 network address rule.
• Port 3 is assigned to VLAN 4 because the workstation is transmitting IP traffic on network 140.0.0.0
that matches the VLAN 4 network address rule.
OmniSwitch
VLAN 2 VLAN 4
IP Network 130.0.0.0 IP Network 140.0.0.0
VLAN 1
Default VLAN
VLAN 3
IP Network 138.0.0.0
Dynamic VPA
Default VLAN
1 Use the vlan port mobile command to enable mobility on switch ports that participates in dynamic
VLAN assignment. See “Enabling/Disabling Port Mobility” on page 7-11 for detailed procedures.
2 Enable/disable mobile port properties that determine mobile port behavior. See “Configuring Mobile
Port Properties” on page 7-16 for detailed procedures.
3 Create VLANs that receives and forward mobile port traffic. See Chapter 4, “Configuring VLANs,” for
more information.
4 Configure the method of traffic classification (VLAN rules or tagged VLAN ID) that triggers dynamic
assignment of a mobile port to the VLANs created in Step 3. See “VLAN Rule Classification” on page 7-8
and “VLAN Mobile Tag Classification” on page 7-5 for more information.
Once the above configuration steps are completed, dynamic VLAN assignment occurs when a device
connected to a mobile port starts to send traffic. This traffic is examined by switch software to determine
which VLAN should carry the traffic based on the type of classification, if any, defined for a particular
VLAN. See “Dynamically Assigning Ports to VLANs” on page 7-5 for more information and examples of
dynamic VLAN port assignment.
To enable mobility on multiple ports, specify a range of ports and/or multiple slots.
-> vlan port mobile 4/1-5 5/12-20 6/10-15
Only Ethernet and gigabit Ethernet ports are eligible to become mobile ports. If any of the following
conditions are true, however, these ports are considered non-mobile ports and are not available for
dynamic VLAN assignment:
• The mobile status for the port is disabled (the default).
• The port is an 802.1Q tagged port.
• The port belongs to a link aggregate of ports.
• Spanning Tree is active on the port and the BPDU ignore status is disabled for the port. (See “Ignoring
Bridge Protocol Data Units (BPDU)” on page 7-11 for more information.)
• The port is configured to mirror other ports.
Note. Mobile ports are automatically trusted ports regardless of the QoS settings. See Chapter 39,
“Configuring QoS,” for more information.
Use the show vlan port mobile command to display a list of ports that are mobile or are eligible to
become mobile. For more information about this command, see the OmniSwitch 6250/6350/6450 CLI
Reference Guide.
When BPDU ignore is enabled and the mobile port receives a BPDU, the following occurs:
• The port retains its mobile status and remains eligible for dynamic VLAN assignment.
• The port is not included in the Spanning Tree algorithm.
Note. Enabling BPDU ignore is not recommended. In specific cases where it is required, such as connect-
ing legacy networks to mobile port networks, make sure that ignoring BPDU on a mobile port does not
cause network loops to go undetected. Connectivity problems could also result if a mobile BPDU port
dynamically moves out of its configured default VLAN where it provides traffic flow to/from the network.
The following command enables mobility and BPDU ignore on port 8 of slot 3:
-> vlan port mobile 3/8 BPDU ignore enable
Enabling mobility on an active port that sends or receives BPDU (for example, ports that connect two
switches and Spanning Tree is enabled on both the ports and their assigned VLANs) is not allowed. If
mobility is required on this type of port, enable mobility and the BPDU ignore parameter when the port is
not active.
The effects of enabling or disabling mobile port properties are described through the following diagrams:
• How Mobile Port Traffic that Does Not Match any VLAN Rules is Classified on page 7-14.
• How Mobile Port VLAN Assignments Age on page 7-15.
OmniSwitch
Configured Default
VLAN 1
VLAN 3
If device traffic does not match any VLAN rules, then the default
VLAN property determines if the traffic is forwarded on the port’s
configured default VLAN (VLAN 1 in this example).
VLAN 3 VLAN 3
Device traffic that does not match any Device traffic that does not match
VLAN rules is forwarded on the mobile any VLAN rules is discarded.
port’s configured default VLAN.
How Mobile Port Traffic that Does Not Match any VLAN Rules is Classified
Secondary Secondary
VLAN 3 VLAN 3
Why enable restore default VLAN? Why disable restore default VLAN?
Security. VLANs only contain mobile port VPAs are retained even when port traffic is
traffic that has recently matched rule criteria. idle for some time. When traffic resumes, it is
not necessary to relearn the same VPA again.
VPAs created from occasional network users Appropriate for devices that only send occa-
(for example, laptop) are not unnecessarily sional traffic.
retained.
Command Description
vlan port default vlan Enables or disables forwarding of mobile port traffic on the port’s con-
figured default VLAN that does not match any existing VLAN rules.
vlan port default vlan restore Enables or disables the retention of VLAN port assignments when
mobile port traffic ages out.
vlan port authenticate Enables or disables authentication on a mobile port.
vlan port 802.1x Enables or disables 802.1X port-based access control on a mobile port.
Use the show vlan port mobile command to view the current status of these properties for one or more
mobile ports. See “Verifying VLAN Port Associations and Mobile Port Properties” on page 7-18 for more
information.
To enable or disable the configured default VLAN on multiple ports, specify a range of ports and/or multi-
ple slots.
-> vlan port 2/1-12 3/10-24 4/3-14 default vlan enable
Note. It is recommended that mobile ports with their default VLAN disabled should not share a VLAN
with any other types of ports (for example, mobile ports with default VLAN enabled or non-mobile, fixed
ports).
See “Understanding Mobile Port Properties” on page 7-12 for an overview and illustrations of how this
property affects mobile port behavior.
To enable or disable default VLAN restore on multiple ports, specify a range of ports and/or multiple slots.
-> vlan port 2/1-12 3/10-24 4/3-14 default vlan restore enable
Note the following when changing the restore default VLAN status for a mobile port:
• If a hub is connected to a mobile port, enabling default VLAN restore on that port is recommended.
• VLAN port rule assignments are exempt from the effects of the restore default VLAN status. See
Chapter 9, “Defining VLAN Rules,” for more information about using port rules to forward mobile
port traffic.
• When a mobile port link is disabled and then enabled, all secondary VPAs for that port are automati-
cally dropped regardless of the restore default VLAN status for that port. Switch ports are disabled
when a device is disconnected from the port, a configuration change is made to disable the port, or
switch power is turned off.
See “Understanding Mobile Port Properties” on page 7-12 for an overview and illustrations of how this
property affects mobile port behavior.
To enable or disable 802.1X on multiple ports, specify a range of ports and/or multiple slots.
-> vlan port 6/1-32 8/10-24 9/3-14 802.1x enable
-> vlan port 5/3-6 9/1-4 802.1x disable
Only mobile ports are eligible for 802.1X port-based access control. If enabled, the mobile port partici-
pates in the authentication and authorization process defined in the IEEE 802.1X standard and supported
by Alcatel switches. For more information, see Chapter 37, “Configuring 802.1X.”
show vlan port Displays a list of VLAN port assignments, including the type and status
for each assignment.
show vlan port mobile Displays the mobile status and current mobile parameter values for each
port.
Type Description
default The port was statically assigned to the VLAN using the vlan port default
command. The VLAN is now the port’s configured default VLAN.
qtagged The port was statically assigned to the VLAN using the vlan 802.1q com-
mand. The VLAN is a static secondary VLAN for the 802.1Q tagged port.
mobile The port is mobile and was dynamically assigned when traffic received on
the port matched VLAN criteria (VLAN rules or tagged VLAN ID). The
VLAN is a dynamic secondary VLAN assignment for the mobile port.
mirror The port is assigned to the VLAN because it is configured to mirror another
port that is assigned to the same VLAN. For more information about the
Port Mirroring feature, see Chapter 43, “Diagnosing Switch Problems.”
Status Description
inactive Port is not active (administratively disabled, down, or nothing connected to
the port) for the VPA.
blocking Port is active, but not forwarding traffic for the VPA.
forwarding Port is forwarding all traffic for the VPA.
filtering Mobile port traffic is filtered for the VPA; only traffic received on the port
that matches VLAN rules is forwarded. Occurs when a mobile port’s VLAN
is administratively disabled or the port’s default VLAN status is disabled.
Does not apply to fixed ports.
The following example uses the show vlan port command to display VPA information for all ports in
VLAN 200:
-> show vlan 200 port
port type status
--------+---------+--------------
3/24 default inactive
5/11 mobile forwarding
5/12 qtagged blocking
Note that the show vlan port mobile command only displays ports that are mobile or are eligible to
become mobile ports. For example, ports that are part of a link aggregate or are configured for 802.1Q
VLAN tagging are not included in the output of this command.
Another example of the output for the show vlan port mobile command is also given in “Sample VLAN
Port Assignment” on page 7-3. For more information about the resulting display from this command, see
the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Port Mapping is a security feature, which controls communication between peer users. Each session
comprises a session ID, a set of user ports, and/or a set of network ports. The user ports within a session
cannot communicate with each other and can only communicate via network ports. In a port mapping
session with user port set A and network port set B, the ports in set A can only communicate with the ports
in set B. If set B is empty, the ports in set A can communicate with rest of the ports in the system.
A port mapping session can be configured in the unidirectional or bidirectional mode. In the unidirec-
tional mode, the network ports can communicate with each other within the session. In the bidirectional
mode, the network ports cannot communicate with each other. Network ports of a unidirectional port
mapping session can be shared with other unidirectional sessions, but cannot be shared with any sessions
configured in the bidirectional mode. Network ports of different sessions can communicate with each
other.
In This Chapter
This chapter describes the port mapping security feature and explains how to configure the same through
the Command Line Interface (CLI).
Configuration procedures described in this chapter include:
• Creating/Deleting a Port Mapping Session—see “Creating a Port Mapping Session” on page 8-3 or
“Deleting a Port Mapping Session” on page 8-3.
• Enabling/Disabling a Port Mapping Session—see “Enabling a Port Mapping Session” on page 8-4 or
“Disabling a Port Mapping Session” on page 8-4.
• Configuring a Port Mapping Direction—see “Configuring Unidirectional Port Mapping” on page 8-4
and “Restoring Bidirectional Port Mapping” on page 8-4.
• Configuring an example Port Mapping Session—see “Sample Port Mapping Configuration” on
page 8-5.
• Verifying a Port Mapping Session—see “Verifying the Port Mapping Configuration” on page 8-6.
2 Enable the port mapping session with the port mapping command. For example:
Note. You can verify the configuration of the port mapping session by entering show port mapping
followed by the session ID.
-> show port mapping 3
You can also verify the status of a port mapping session by using the port mapping dynamic-proxy-arp
command.
You can create a port mapping session with link aggregate network ports. For example, to create a port
mapping session 3 with network ports of link aggregation group 7, you would enter:
-> port mapping 3 network-port linkagg 7
You can specify all the ports of a slot to be assigned to a mapping session. For example, to create a port
mapping session 3 with all the ports of slot 1 as network ports, you would enter:
-> port mapping 3 network-port slot 1
You can specify a range of ports to be assigned to a mapping session. For example, to create a port
mapping session 4 with ports 5 through 8 on slot 2 as user ports, you would enter:
-> port mapping 4 user-port 2/5-8
Similarly, to delete the network ports of link aggregation group 7 of a mapping session 4, you would enter:
-> port mapping 4 no network-port linkagg 7
Note. You must delete any attached ports with the port mapping user-port network-port command
before you can delete a port mapping session.
Note. To change the direction of an active session with network ports, delete the network ports of the
session, change the direction, and recreate the network ports.
Switch A Switch C
1/1 1/1 3/1
2/1
1/2 3/2
2/2
1/3 Switch B Switch D
1/1 2/1
2/1
2/2
2/2
3/1 3/1
2 Create two port mapping sessions on Switch A using the following commands:
Similarly, create and enable a port mapping session 1 on Switch D by entering the following commands:
-> port mapping 1 user-port 2/1-2 network-port 1/1
port mapping dynamic-proxy- Displays the status of one or more port mapping sessions.
arp
show port mapping Displays the configuration of one or more port mapping sessions.
For more information about the displays that result from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
VLAN rules are used to classify mobile port traffic for dynamic VLAN port assignment. Rules are defined
by specifying a port, MAC address, protocol, network address, or DHCP criteria to capture certain types of
network device traffic. It is also possible to define multiple rules for the same VLAN. A mobile port is
assigned to a VLAN if its traffic matches any one VLAN rule.
There is an additional method for dynamically assigning mobile ports to VLANs that involves enabling
VLAN mobile tagging. This method is similar to defining rules in that the feature is enabled on the VLAN
that is going to receive the mobile port tagged traffic. The difference, however, is that tagged packets
received on mobile ports are classified by their 802.1Q VLAN ID tag and not by whether or not their
source MAC, network address, or protocol type matches VLAN rule criteria.
In This Chapter
This chapter contains information and procedures for defining VLAN rules through the Command Line
Interface (CLI). CLI commands are used in the configuration examples; for more details about the syntax
of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide. Refer to Chapter 4, “Configur-
ing VLANs,” and Chapter 7, “Assigning Ports to VLANs,” for information about the VLAN mobile
tagging feature.
Configuration procedures described in this chapter include:
• Defining DHCP rules on page 9-9.
• Defining MAC address rules on page 9-10.
• Defining IP network address rules on page 9-11.
• Defining protocol rules on page 9-12.
• Defining forwarding-only port rules on page 9-13.
• Verifying the VLAN rule configuration on page 9-17.
For information about creating and managing VLANs, see Chapter 4, “Configuring VLANs.”
For information about enabling port mobility and defining mobile port properties, see Chapter 7, “Assign-
ing Ports to VLANs.”
1 Create VLAN 255 with a description (for example, Finance IP Network) using the following
command:
-> vlan 255 name "Finance IP Network"
2 Define an IP network address rule for VLAN 255 that captures mobile port traffic containing a network
21.0.0.0 IP source address. For example:
-> vlan 255 ip 21.0.0.0
3 Define a DHCP MAC range rule for VLAN 255 that captures mobile port DHCP traffic that contains a
source MAC address that falls within the range specified by the rule. For example:
-> vlan 255 dhcp mac 00:DA:95:00:59:10 00:DA:95:00:59:9F
Note. Optional. To verify that the rules in this tutorial were defined for VLANs 255, 355, and 1500, enter
show vlan rules. For example:
-> show vlan rules
The type of rule defined determines the type of traffic that triggers a dynamic port assignment to the
VLAN and the type of traffic the VLAN forwards within its domain. Refer to the following sections (listed
in the order of rule precedence) for a description of each type of VLAN rule:
Rule See
DHCP MAC Address “DHCP Rules” on page 9-5
DHCP MAC Range
DHCP Port
DHCP Generic
MAC Address “MAC Address Rules” on page 9-5
MAC Address Range
Network Address “Network Address Rules” on page 9-5
Protocol “Protocol Rules” on page 9-5
Port “Port Rules” on page 9-6
Use the show vlan rules command to display a list of rules already configured on the switch. For more
information about this command, refer to the OmniSwitch 6250/6350/6450 CLI Reference Guide.
DHCP Rules
Dynamic Host Configuration Protocol (DHCP) frames are sent from client workstations to request an IP
address from a DHCP server. The server responds with the same type of frames, which contain an IP
address for the client. If clients are connected to mobile ports, DHCP rules are used to classify this type of
traffic for the purposes of transmitting and receiving DHCP frames to and from the server.
When a mobile port receives a DHCP frame that matches a DHCP rule, the port is temporarily assigned to
the VLAN long enough to forward the DHCP requests within the VLAN broadcast domain. The source
MAC address of the DHCP frame, however, is not learned for that VLAN port association. As a result, the
show mac-address-table command output does not contain an entry for the DHCP source MAC address.
The show vlan port command output, however, contains an entry for the temporary VLAN port associa-
tion that occurs during this process.
Once a device connected to a mobile port receives an IP address from the DHCP server, the VLAN port
assignment triggered by the device’s DHCP frames matching a VLAN DHCP rule is dropped unless regu-
lar port traffic matches another rule on that same VLAN. If this match occurs, or the traffic matches a rule
on another VLAN, then the source MAC address of the mobile port’s frames is learned for that VLAN
port association.
DHCP rules are most often used in combination with IP network address rules. A DHCP client has an IP
address of all zeros (0.0.0.0) until it receives an IP address from a DHCP server, so initially it would not
match any IP network address rules.
MAC address rules, and protocol rules also capture DHCP client traffic. The following DHCP rule types
are available:
• DHCP MAC Address
• DHCP MAC Range
• DHCP Port
• DHCP Generic
Protocol Rules
Protocol rules determine VLAN assignment based on the protocol a device uses to communicate. When
defining this type of rule, there are several generic protocol values to select from: IP, AppleTalk, or
DECNet. If none of these are sufficient, it is possible to specify an Ethernet type, Destination and Source
Service Access Protocol (DSAP/SSAP) header values, or a Sub-network Access Protocol (SNAP) type.
Note that specifying a SNAP protocol type restricts classification of mobile port traffic to the ethertype
value found in the IEEE 802.2 SNAP LLC frame header.
IP protocol rules also capture DHCP traffic, if no other DHCP rule exists that would classify the DHCP
traffic into another VLAN. Therefore, it is not necessary to combine DHCP rules with IP protocol rules for
the same VLAN.
Port Rules
Port rules are fundamentally different from all other supported rule types, in that traffic is not required to
trigger dynamic assignment of the mobile port to a VLAN. As soon as this type of rule is created, the spec-
ified port is assigned to the VLAN only for the purpose of forwarding broadcast types of VLAN traffic to
a device connected to that same port.
Port rules are mostly used for silent devices, such as printers, that require VLAN membership to receive
traffic forwarded from the VLAN. These devices usually don’t send traffic, so they do not trigger dynamic
assignment of their mobile ports to a VLAN.
It is also possible to specify the same port in more than one port rule defined for different VLANs. The
advantage to this is that traffic from multiple VLANs is forwarded out the one mobile port to the silent
device. For example, if port 3 on slot 2 is specified in a port rule defined for VLANs 255, 355, and 755,
then outgoing traffic from all three of these VLANs is forwarded on port 2/3.
Port rules only apply to outgoing mobile port traffic and do not classify incoming traffic. If a mobile port
is specified in a port rule, its incoming traffic is still classified for VLAN assignment in the same manner
as all other mobile port traffic.
VLAN assignments that are defined using port rules are exempt from the port’s default VLAN restore
status. See Chapter 7, “Assigning Ports to VLANs,” for more information regarding a port’s default
VLAN restore status and other mobile port properties.
Note. Another type of mobile traffic classification, referred to as VLAN mobile tagging, takes precedence
over all VLAN rules. If a mobile port receives an 802.1Q packet that contains a VLAN ID tag that
matches a VLAN that has mobile tagging enabled, the port and its traffic are assigned to this VLAN, even
if the traffic matches a rule defined on any other VLAN. See Chapter 7, “Assigning Ports to VLANs,” for
more information about VLAN mobile tag classification.
The VLAN rule precedence table on page 9-7 provides a list of all VLAN rules, including the two internal
rules mentioned above, in the order of precedence that switch software applies to classify mobile port
frames. The first column lists the rule type names, the second and third columns describe how the switch
handles frames that match or don’t match rule criteria. The higher the rule is in the list, the higher its level
of precedence.
When a frame is received on a mobile port, switch software starts with rule one in the rule precedence
table and progresses down the list until there is a successful match between rule criteria and frame
contents.
Rule See
DHCP MAC Address “Defining DHCP MAC Address Rules” on page 9-9
DHCP MAC Range “Defining DHCP MAC Range Rules” on page 9-9
DHCP Port “Defining DHCP Port Rules” on page 9-10
DHCP Generic “Defining DHCP Generic Rules” on page 9-10
MAC Address “Defining MAC Address Rules” on page 9-10
MAC Address Range “Defining MAC Range Rules” on page 9-11
Network Address “Defining IP Network Address Rules” on page 9-11 and
“Defining Protocol Rules” on page 9-12
Rule See
Protocol “Defining Protocol Rules” on page 9-12
Port “Defining Port Rules” on page 9-13
To display a list of VLAN rules already configured on the switch, use the show vlan rules command. For
more information about this command, refer to the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Only one MAC address is specified when using the vlan dhcp mac command to create a DHCP MAC
rule. Therefore, to specify multiple MAC addresses for the same VLAN, create a DHCP MAC rule for
each address. If dealing with a large number of MAC addresses in sequential order, consider using a
DHCP MAC range rule described in the next section.
Use the no form of the vlan dhcp mac command to remove a DHCP MAC address rule.
-> vlan 255 no dhcp mac 00:00:da:59:0c:11
Only valid source MAC addresses are allowed for the low and high end boundary MACs. For example,
multicast addresses (for example, 01:00:00:c5:09:1a) are ignored even if they fall within a specified MAC
range and are not allowed as the low or high end boundary MAC. If an attempt is made to use a multicast
address for one of the boundary MACs, an error message is displayed and the rule is not created.
Use the no form of the vlan dhcp mac range command to remove a DHCP MAC range rule. Note that it
is only necessary to enter the low end MAC address to identify which rule to remove.
-> vlan 1000 no dhcp mac range 00:00:da:00:00:01
To specify multiple ports and/or slots, use a hyphen to specify a range of ports and a space to specify
multiple slots. For example,
-> vlan 255 dhcp port 4/1-5 5/12-20 6/10-15
Use the no form of the vlan dhcp port command to remove a DHCP port rule.
-> vlan 255 no dhcp port 2/10-12 3/1-5 6/1-9
Use the no form of the vlan dhcp generic command to remove a DHCP generic rule.
-> vlan 255 no dhcp generic
Only one MAC address is specified when using the vlan mac command to create a MAC address rule.
Therefore, to specify multiple MAC addresses for the same VLAN, create a separate rule for each address.
If dealing with a large number of MAC addresses, consider using MAC address range rules described in
the next section.
Use the no form of the vlan mac command to remove a MAC address rule.
-> vlan 255 no mac 00:00:da:59:0c:11
Only valid source MAC addresses are allowed for the low and high end boundary MACs. For example,
multicast addresses (for example, 01:00:00:c5:09:1a) are ignored even if they fall within a specified MAC
range and are not allowed as the low or high end boundary MAC. If an attempt is made to use a multicast
address for one of the boundary MACs, an error message is displayed and the rule is not created.
Use the no form of the vlan mac range command to remove a MAC range rule. Note that it is only neces-
sary to enter the low end MAC address to identify which rule to remove.
-> vlan 1000 no mac range 00:00:da:00:00:01
Note. IP network address rules are applied to traffic received on both mobile and fixed (non-mobile) ports.
As a result, fixed port traffic that contains an IP address that is included in the IP subnet specified by the
rule is dropped. However, if the IP network address rule VLAN is also the default VLAN for the fixed
port, then the fixed port traffic is forwarded and not dropped.
To define an IP network address rule, enter vlan followed by an existing VLAN ID then ip followed by a
valid IP network address and an optional subnet mask. For example, the following command creates an IP
network address rule for VLAN 1200:
-> vlan 1200 ip 31.0.0.0 255.0.0.0
In this example, frames received on any mobile port must contain a network 31.0.0.0 source IP address
(for example, 31.0.0.10, 31.0.0.4) to qualify for dynamic assignment to VLAN 1200.
If a subnet mask is not specified, the default class for the IP address is used (Class A, B, or C). For exam-
ple, either one of the following commands creates an IP network address rule for network 134.10.0.0:
-> vlan 1200 ip 134.10.0.0 255.255.0.0
-> vlan 1200 ip 134.10.0.0
The pool of available internet IP addresses is divided up into three classes, as shown in the following table.
Each class includes a range of IP addresses. The range an IP network address belongs to determines the
default class for the IP network when a subnet mask is not specified.
Use the no form of the vlan ip command to remove an IP network address rule.
-> vlan 1200 no ip 134.10.0.0
The first example command specifies that frames received on any mobile port must contain an IP SNAP
protocol type to qualify for dynamic assignment to VLAN 1503. The second command specifies that
frames received on any mobile port must contain a DSAP/SSAP protocol value of f0/f0 to qualify for
dynamic assignment to VLAN 1504.
If an attempt is made to define an ethertype rule with a protocol type value that is equal to the value
already captured by one of the generic IP protocol rule, a message displays recommending the use of the
IP generic rule. The following example shows what happens when an attempt is made to create a protocol
rule with an ethertype value of 0800 (IP Ethertype):
-> vlan 200 protocol ethertype 0800
ERROR: Part of ip ethernet protocol class - use <vlan # protocol ip-e2> instead
Note that specifying a SNAP protocol type restricts classification of mobile port traffic to the ethertype
value found in the IEEE 802.2 SNAP LLC frame header.
Use the no form of the vlan protocol command to remove a protocol rule.
-> vlan 1504 no protocol dsapssap f0/f0
In this example, all traffic on VLAN 755 is flooded out mobile port 2 on slot 3.
Note that it is possible to define a port rule for a non-mobile (fixed, untagged) port, however, the rule is
not active until mobility is enabled on the port.
Use the no form of the vlan port command to remove a port rule.
-> vlan 755 no port 2/3
The VLANs
This application example contains three (3) VLANs. These VLANs are called Test, Production, and
Branch. The Test VLAN connects to the main network, the Production VLAN, through an external router.
The configuration of this VLAN is self-contained, making it easy to duplicate for testing purposes. The
Test VLAN contains its own DHCP server and DHCP clients. The clients gain membership to the VLAN
through DHCP port rules.
The Production VLAN carries most of the traffic in this network. It does not contain a DHCP server, but
does contain DHCP clients that gain membership through DHCP port rules. Two external routers connect
this VLAN to the Test VLAN and a Branch VLAN. One of the external routers—the one connected to the
Branch VLAN—has DHCP Relay functionality enabled. It is through this router that the DHCP clients in
the Production VLAN access the DHCP server in the Branch VLAN.
The Branch VLAN contains a number of DHCP client stations and its own DHCP server. The DHCP
clients gain membership to the VLAN through both DHCP port and MAC address rules. The DHCP server
allocates IP addresses to all Branch and Production VLAN clients.
OmniSwitch
Client 1
DHCP Port
Rule
Server 1 Test VLAN
10.15.14.16 IP Subnet 10.15.X.X Client 2
DHCP Port Rules DHCP Port
Rule
Client 3
Router 1 DHCP
No DHCP Port Rule
Relay
Production VLAN Client 4
IP Subnet 10.15.128.X DHCP
DHCP Port Rules Port Rule
Router 2
DHCP
Relay On Client 5
DHCP
Port Rule
Client 7
DHCP
MAC
Client 8
DHCP Servers DHCP
Both DHCP servers become members in their MAC
respective VLANs via IP subnet rules.
DHCP Clients
Routers
Clients 1 to 6 are assigned to their respective
Router 1 provides connectivity between the Test VLANs through DHCP port rules. Clients 3 and
VLAN and the Production VLAN. It does not 4 are not in a VLAN with a DHCP server so they
have Bootup functionality enabled so it cannot must rely on the server in the Branch VLAN for
connect DHCP servers and clients from different initial addressing information. Clients 7 and 8
VLANs. share a port with other devices, so they are
assigned to the Branch VLAN via DHCP MAC
Router 2 connects the Production VLAN and the address rules.
Branch VLAN. With DHCP Relay enabled, this
router can provide connectivity between the
DHCP server in the Branch VLAN and the DHCP
clients in the Production VLAN.
show vlan rules Displays a list of rules for one or all VLANs configured on the switch.
For more information about the resulting display from this command, see the OmniSwitch 6250/6350/6450
CLI Reference Guide. An example of the output for the show vlan rules command is also given in
“Sample VLAN Rule Configuration” on page 9-3.
VLAN Stacking provides a mechanism to tunnel multiple customer VLANs (CVLAN) through a service
provider network using one or more service provider VLANs (SVLAN) by way of 802.1Q double-tagging
or VLAN Translation. This feature enables service providers to offer their customers Transparent LAN
Services (TLS). This service is multipoint in nature to support multiple customer sites or networks
distributed over the edges of a service provider network.
Standard VLAN support on NNI ports' allows any standard (non-service) VLAN to be associated to NNI
ports of type untagged or 8021q tagged. However, VLAN 1, cannot be associated as untagged member to
a NNI port. 802.1q services, QinQ service and untagged services can be configured using the same uplink
NNI port. This allows the customer to use an untagged management VLAN to manage the switch through
NNI ports.
This implementation of VLAN Stacking offers the following functionality:
• An Ethernet service-based approach that is similar to configuring a virtual private LAN service
(VPLS).
• Ingress bandwidth sharing across User Network Interface (UNI) ports.
• Ingress bandwidth rate limiting on a per UNI port, per CVLAN, or CVLAN per UNI port basis.
• Built in UNI profiles IEEE-FWD-ALL and IEEE-DROP-ALL to tunnel or discard all IEEE multicast
MAC addresses traffic associated to UNI port.
• Multiple TPIDs (0x8100, 0x88a8 & 0x9100) supported and interpreted on UNI ports.
• L2 control frames with up to 8 VLAN tag headers are accepted and on UNI ports.
• Custom L2 protocol entry for proprietary protocol with multicast MAC addresses for specific packet
control.
• CVLAN (inner) tag 802.1p-bit mapping to SVLAN (outer) tag 802.1p bit.
• CVLAN (inner) tag DSCP mapping to SVLAN (outer) tag 802.1p bit.
• Profiles for saving and applying traffic engineering parameter values.
In This Chapter
This chapter describes the basic components of VLAN Stacking and how to define a service-based or
port-based configuration through the Command Line Interface (CLI). CLI commands are used in the
configuration examples; for more details about the syntax of commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
This chapter provides an overview of VLAN Stacking and includes the following topics:
• “VLAN Stacking Specifications” on page 10-3.
• “VLAN Stacking Defaults” on page 10-3.
• “VLAN Stacking Overview” on page 10-4.
• “Interaction With Other Features” on page 10-10.
• “Configuring VLAN Stacking Services” on page 10-14
• “Configuring Custom L2 Protocol” on page 10-26
• “Configuring MAC-Tunneling for SVLAN” on page 10-29
• “VLAN Stacking Application Examples” on page 10-30.
• “Wire-Speed Ethernet Loopback Test” on page 10-33.
• “Control Protocol Tunneling Frame Statistics” on page 10-27
• “Control HW Tunneling” on page 10-28
Tunneled Frames:
STP, GVRP, MVRP
Discarded Frames:
802.1x, 802.1ab, AMAP, VTP
VLAN, Uplink Fast, PVST,
PAGP, DTP, CDP
• Network Network Interface (NNI)—An NNI is a port that resides on either a PE Bridge or a Transit
Bridge and connects to a service provider network. Traffic ingressing on a network port is considered
SVLAN traffic and is switched to a customer-facing port or to another network port.
• User Network Interface (UNI)—A UNI is a port that resides on a PE bridge that connects to a
customer network and carries customer traffic. The UNI can consist of a single port or an aggregate of
ports, and can accept tagged or untagged traffic.
The following illustration shows how VLAN Stacking is used to tunnel customer traffic through a service
provider network:
Provider
Customer A
LAN
Site 2
Provider Edge 2
Customer A
Site 1
Transit Bridge
Customer B
EMAN Site 2
Provider Edge 1
Provider Edge 3
Customer B
Site 1
NNI Port
UNI Port
NNI Port
Note. MAC processing and tunneling is supported for up to 8 VLAN tag headers at a UNI port.
Similarly, MAC processing and tunneling is supported for up to 8 VLAN tag headers at an NNI port.
2 Double Tagging inserts the SVLAN tag in the packet. The packet is sent out the network port with
double tags (SVLAN+Additional tag for SVLAN).
Addi- Inner
MAC DAMAC SASVLAN Tag Inner ETYPE Payload
tional VLAN ..... VLAN
(6) (6) (4) Tag 0x0800
Note. Double tagging is applied when preserve mode is configured using the ethernet-service sap profile
command.
3 VLAN Translation replaces the CVLAN Tag with SVLAN Tag. The packet is sent out the network
port with a single tag (SVLAN).
Note. VLAN Translation is applied when translate mode is configured using the ethernet-service sap
profile command
L2 Control Maximum
Frames UNI Port VLAN tag
Mode Action at Egress NNI
Treatment headers
processed
STP BPDU Preserve Tunnel >8 Tunnel
STP BPDU Preserve Mac Tunnel 7 Tunnel
STP BPDU Preserve Peer 7 -
STP BPDU Preserve Discard/Drop - -
L2 Control Maximum
Frames UNI Port VLAN tag
Mode Action at Egress NNI
Treatment headers
processed
STP BPDU Translate Tunnel >8 Tunnel
STP BPDU Translate Mac Tunnel 8 Tunnel
STP BPDU Translate Peer 8 -
STP BPDU Translate Discard/Drop - -
LACP PDU Preserve Tunnel 7 Tunnel
LACP PDU Preserve Mac Tunnel 7 Tunnel
LACP PDU Preserve Peer 7 -
LACP PDU Preserve Discard/Drop - -
LACP PDU Translate Tunnel 8 Tunnel
LACP PDU Translate Mac Tunnel 8 Tunnel
LACP PDU Translate Peer 8 -
LACP PDU Translate Discard/Drop - -
IP Multicast VLANs
The IP Multicast VLAN (IPMV) application has the following interactions with VLAN Stacking
functionality and commands:
• IPMV operates in one of two modes:
- Enterprise Mode.
- VLAN Stacking Mode.
When the enterprise mode is active, IPMV uses sender and receiver ports for IP multicast traffic. When
the IPMV VLAN Stacking mode is active, IPMV maps sender and receiver ports to VLAN Stacking
NNI and UNI ports.
• If IPMV is operating in the enterprise mode, there are no CLI usage changes.
• If IPMV is operating in the VLAN Stacking mode, the following VLAN Stacking CLI commands are
used to configure interoperability with IPMV:
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for more information on VLAN Stacking
commands.
Link Aggregation
• Both static and dynamic link aggregation are supported with VLAN Stacking.
• A link aggregate must consist of all UNI or all NNI ports. VLAN Stacking functionality is not
supported on link aggregates that consist of a mixture of VLAN Stacking ports and conventional
switch ports.
• Transparent bridging is not supported for link aggregate NNIs.
Spanning Tree
• Spanning Tree is enabled by default for VLAN Stacking SVLANs. The Spanning Tree status for an
SVLAN is configurable through VLAN Stacking commands. The SVLAN Spanning Tree status
applies only to the service provider network topology.
• BPDU frames are tunneled by default. See “Configuring a UNI Profile” on page 10-25 for information
on configuring VLAN Stacking to tunnel or discard Spanning Tree BPDU.
• See “Configuring VLAN Stacking Network Ports” on page 10-18 for information on configuring
VLAN Stacking interoperability with legacy Spanning Tree BPDU systems.
• A back door link configuration is not supported. Back door link occurs when there is a link between
two-customer sites connected to a VLAN Stacking provider edge switch.
• A dual home configuration is not supported. Dual home configuration consists of a single customer site
connected to two different VLAN Stacking switches or two switches at a customer site connect to two
different VLAN Stacking switches.
1 Create a VLAN Stacking VLAN (SVLAN) 1001 using the ethernet-service command.
2 Create a VLAN Stacking service and associate the service with SVLAN 1001 using the
ethernet-service service-name command.
-> ethernet-service service-name CustomerA svlan 1001
3 Configure port 3/1 as a VLAN Stacking Network Network Interface (NNI) port and associate the port
with SVLAN 1001 using the ethernet-service svlan nni command.
-> ethernet-service svlan 1001 nni 3/1
4 Create a VLAN Stacking Service Access Point (SAP) and associate it to the “CustomerA” service
using the ethernet-service sap command.
-> ethernet-service sap 10 service-name CustomerA
5 Configure port 1/49 as a VLAN Stacking User Network Interface (UNI) port and associate the port
with SAP ID 10 using the ethernet-service sap uni command.
-> ethernet-service sap 10 uni 1/49
6 Associate traffic from customer VLANs (CVLAN) 10 and 20 with SAP 10 using the ethernet-service
sap cvlan command.
-> ethernet-service sap 10 cvlan 10
-> ethernet-service sap 10 cvlan 20
7 (Optional) Create an SAP profile that applies an ingress bandwidth of 10, translates the CVLAN tag,
and maps the CVLAN priority to the SVLAN priority using the ethernet-service sap-profile command.
-> ethernet-service sap-profile sap-video1 ingress-bandwidth 10 cvlan translate
priority map-inner-to-outer-p
8 (Optional) Associate the “sap-video1” profile with SAP 10 using the ethernet-service sap sap-profile
command.
-> ethernet-service sap 10 sap-profile sap-video1
9 (Optional) Create a UNI port profile to block GVRP and STP control frames received on UNI ports
using the ethernet-service uni-profile command.
-> ethernet-service uni-profile uni_1 l2-protocol stp gvrp discard
10 (Optional) Associate the “uni_1” profile with port 1/49 using the ethernet-service uni uni-profile
command.
-> ethernet-service uni 1/49 uni-profile uni_1
Note. Verify the VLAN Stacking Ethernet service configuration using the show ethernet-service
command:
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for information on the fields in the show
command.
3 Configure Network Network Interface (NNI) ports. An NNI port is associated with an SVLAN and
carries the encapsulated SVLAN traffic through the provider network. See “Configuring VLAN Stacking
Network Ports” on page 10-18.
4 Configure a VLAN Stacking service access point (SAP). SAP binds UNI ports, the type of customer
traffic, and traffic engineering parameter attributes to the VLAN Stacking service. Each SAP is associated
to one service name, but a single service can have multiple SAPs to which it is associated.
See “Configuring a VLAN Stacking Service Access Point” on page 10-20.
5 Configure User Network Interface (UNI) ports. UNI ports are associated with an SAP to identify to
the service from which the switch ports receive customer traffic. The SAP tunnels this traffic through the
provider network. When a UNI port is associated with an SAP, the SAP parameter attributes are applied to
traffic received on the UNI port. See “Configuring VLAN Stacking User Ports” on page 10-21.
6 Associate CVLAN traffic with an SAP. This step specifies the type of customer traffic that is allowed
on UNI ports and then tunneled through the SVLAN. The type of customer traffic is associated with an
SAP and applies to all UNI ports associated with the same SAP. See “Configuring the Type of Customer
Traffic to Tunnel” on page 10-22.
7 Define SAP profile attributes. An SAP profile contains traffic engineering attributes to specify
bandwidth sharing, rate limiting, CVLAN translation or double-tagging, and priority bit mapping. A
default profile is automatically associated with an SAP at the time the SAP is created. If the default profile
values are not sufficient, configure an SAP profile to specify different attribute values. See “Configuring a
Service Access Point Profile” on page 10-23.
8 Define UNI profile attributes. A default UNI profile is automatically assigned to a UNI port at the
time a port is configured as a VLAN Stacking UNI. This profile determines how control frames received
on the port are processed. If the default profile values are not sufficient, configure a UNI profile to
specify different attribute values. See “Configuring a UNI Profile” on page 10-25.
The following table provides a summary of commands used in these procedures:
Configuring SVLANs
There are three types of SVLAN:
• Customer SVLAN: An SVLAN that carries customer traffic
• Management SVLAN: An SVLAN that carries provider management traffic
• IPMVLAN: An SVLAN that carries IP Multicast VLAN traffic.
SVLANs cannot be configured or modified using standard VLAN commands. As an exception, it is
possible to configure an IP interface for a provider management SVLAN, however, traffic is not routed on
this interface.
The ethernet-service command is used to create an SVLAN. This command provides parameters to
specify the type of SVLAN: svlan (customer traffic), management-vlan (provider management traffic),
or ipmv (IP Multicast traffic). For example, the following commands create a customer SVLAN,
management SVLAN, and IP Multicast VLAN:
-> ethernet-service svlan 300
-> ethernet-service management-vlan 200
-> ethernet-service impv 500
Similar to standard VLANs, the administrative and Spanning Tree status for the SVLAN is enabled by
default and the SVLAN ID is used as the default name. The ethernet-service svlan command also
provides parameters for changing any of the status values and the name. These parameters are used to
change the values for standard VLANs. For example, the following commands change the administrative
and Spanning Tree status and name for SVLAN 300:
-> ethernet-service svlan 300 disable
-> ethernet-service svlan 300 stp disable
-> ethernet-service svlan 300 name “Customer A”
To delete an SVLAN from the switch configuration, use the no form of the ethernet-service svlan
command. For example, to delete SVLAN 300 enter:
-> no ethernet-service svlan 300
When an SVLAN is deleted, all port associations with the SVLAN are also removed.
Use the show ethernet-service vlan command to display a list of VLAN Stacking VLANs configured for
the switch.
The SVLAN or IPMPVLAN ID specified with this command must exist in the switch configuration;
entering a standard VLAN ID is not allowed. See “Configuring SVLANs” on page 10-16 for more
information.
Once the VLAN Stacking service is created, the service name is used to configure and display all
components associated with that service. The service name provides a single point of reference for a
specific VLAN Stacking configuration.
For example, the following show ethernet-service command display shows how the service name
identifies a VLAN Stacking service and components related to that service:
-> show ethernet-service
To delete a service from the switch configuration, use the no form of the ethernet-service service-name
command. For example, the following command deletes the “Video-Service” service:
-> no ethernet-service servic-name Video-Service
When a VLAN Stacking service is deleted, the SVLAN or IMPVLAN ID association with the service is
automatically deleted. However, if one or more VLAN Stacking service access point (SAP) are associated
with the service, remove the associated SAP before deleting the service.
When a port is associated with an SVLAN using this command, the port is automatically defined as an
NNI to carry traffic for the specified SVLAN. In addition, the default VLAN for the port is changed to a
VLAN that is reserved for the VLAN Stacking application. The port is now no longer configurable using
standard VLAN port commands.
To delete an NNI port association with an SVLAN, use the no form of the ethernet-service svlan nni
command. For example, the following command deletes the association between NNI 2/1 and SVLAN
300:
-> no ethernet-service svlan 300 nni 2/1
When the last SVLAN association for the port is deleted, the port automatically reverts to a conventional
switch port, and is no longer VLAN Stacking capable.
Use the show ethernet-service port command to verify the NNI port configuration for the switch.
• Enable legacy BPDU support only on VLAN Stacking network ports that are connected to legacy
BPDU switches. Enabling legacy BPDU between AOS switches can cause flooding or an unstable
network.
• If legacy BPDU is enabled on a network port while at same time BPDU flooding is enabled on user
ports, ensure that tagged customer BPDUs are not interpreted by intermediate switches in the provider
network.
• If the peer switch connected to the VLAN Stacking network port supports the Provider MAC address
(that is, STP, 802.1ad/D6.0 MAC), then enabling legacy BPDU support is not required on the network
port. Refer to the following table to determine the type of STP or GVRP MAC used:
STP
Customer MAC {0x01, 0x80, 0xc2, 0x00, 0x00, 0x00}
Provider MAC address (802.1ad/D6.0) {0x01, 0x80, 0xc2, 0x00, 0x00, 0x08}
Provider MAC address (Legacy MAC) {0x01, 0x80, 0xc2, 0x00, 0x00, 0x00}
GVRP
Customer MAC address {0x01, 0x80, 0xc2, 0x00, 0x00, 0x21}
Provider MAC address {0x01, 0x80, 0xc2, 0x00, 0x00, 0x0D}
• GVRP legacy BPDU are supported only on network ports that already have GVRP enabled for the
port.
• STP legacy BPDU are supported only when the flat Spanning Tree mode is active on the switch.
Use the show ethernet-service nni command to display the NNI port configuration for the switch.
Hybrid NNI mode with QinQ and 802.1Q VLANS on same NNI port
The tagged packets received on an NNI port, with TPID other than the one configured for a port, are
treated as untagged packets. If there is a TPID mismatch, these packets are accepted and flooded in the
default VLAN (other than 4095) of the NNI port.
All features/properties supported with the standard VLANs (standard VLAN being configured on fixed
ports) are now supported on standard VLANs, configured on NNI interface. Some of these are
- mobile-tag enable/disable, mac or mac-range rule, IP-rules and so on.
The following commands are now supported on an NNI interface:
• vlan port default
• vlan 802.1q
If the default VLAN is removed from the NNI interface, then the default VLAN must be changed to 4095.
It is not possible to configure VLAN 1 as default VLAN of an NNI interface.
To delete a VLAN Stacking SAP from the switch configuration, use the no form of the ethernet-service
sap command. For example, the following command deletes SAP 20:
-> no ethernet-service sap 20
When the SAP is deleted, all the UNI ports, CVLAN, and profile associations are automatically dropped.
A VLAN Stacking SAP identifies the following information:
• Location where customer traffic enters the provider network edge,
• The type of customer traffic to service,
• Parameters to apply to the traffic,
• The service that processes the traffic for tunneling through the provider network.
Consider the following when configuring a VLAN Stacking SAP:
• An SAP can be assigned to only one service, but a service can have multiple SAPs. So, a single service
can process and tunnel traffic for multiple UNI ports and customers.
• Associating multiple UNI ports to one SAP is allowed.
• A default SAP profile is associated with the SAP at the time the SAP is created. This profile contains
the following default attribute values:
The default attribute values of the profile are applied to customer traffic associated with the SAP. Only
one profile is assigned to each SAP; however, it is possible to use the same profile for multiple SAPs.
• To use different profile attribute values, create a profile and associate it with the SAP.
See “Configuring a Service Access Point Profile” on page 10-23. Each time a profile is assigned to an
SAP, the existing profile is overwritten with the new one.
Use the show ethernet-service sap command to display the SAPs configured for the switch. Use the
show ethernet-service command to display a list of VLAN Stacking services and the SAPs associated
with each service.
A UNI port is a customer-facing port on which traffic enters the VLAN Stacking service. When the port is
associated with a service access point, the port is automatically defined as a UNI port and the default
VLAN for the port is changed to a VLAN that is reserved for the VLAN Stacking application.
To delete a UNI port association with a VLAN Stacking SAP, use the no form of the ethernet-service sap
uni command. For example, the following command deletes the association between UNI 1/1 and SAP
20:
-> no ethernet-service sap 20 uni 1/1
When the last SAP association for the port is deleted, the port automatically reverts to a conventional
switchport, and is no longer VLAN Stacking capable.
Consider the following when configuring VLAN Stacking UNI ports:
• All customer traffic received on the UNI port is dropped until customer VLANs (CVLAN) are
associated with the port. See “Configuring the Type of Customer Traffic to Tunnel” on page 10-22.
• If the SAP ID specified with this command is associated with an IPMVLAN, the SAP profile must
specify CVLAN translation. In addition, multicast traffic is not associated with the IPMVLAN until the
UNI port is associated with the IPMVLAN as a receiver port. For more information, see the
“Configuring IP Multicast VLANs” chapter in this guide.
• A default UNI profile is assigned to the port at the time the port is configured. This profile defines how
control frames received on the UNI ports are processed. By default, GVRP and Spanning Tree frames
are tunneled. All other protocol control frames are dropped.
• To use different profile attribute values, create a profile and associate it with the UNI port. See
“Configuring a UNI Profile” on page 10-25. Each time a profile is assigned to a UNI, the existing
profile is overwritten with the new one.
Use the show ethernet-service nni l2pt-statistics command to display a list of UNI ports and the profile
association for each port.
In this example, customer frames tagged with VLAN ID 500 that are received on SAP 20 UNI ports are
processed by the service to which SAP 20 is associated. This includes applying profile attributes
associated with SAP 20 to the qualifying customer frames. If no other customer traffic is specified for SAP
20, all other frames received on SAP 20 UNI ports are dropped.
In addition to specifying one or more CVLANs, it is also possible to specify the following parameters
when using the ethernet-service sap cvlan command:
• all—Specifies that all untagged and tagged frames are accepted on the UNI ports. If this parameter is
combined with a CVLAN ID and bandwidth sharing and rate limiting are enabled for the SAP profile,
then frames tagged with the CVLAN ID are given a higher bandwidth priority than all other frames
received on the port.
• untagged—Specifies that only untagged frames are accepted on the UNI ports. If this parameter is
combined with a CVLAN ID, then all untagged frames plus frames tagged with the CVLAN ID are
accepted on the UNI ports.
For example, the following command specifies that all untagged frames and frames tagged with CVLAN
ID 500 is accepted on UNI ports associated with SAP 20:
-> ethernet-service sap 20 cvlan 500 untagged
Use the no form of the ethernet-service sap cvlan command to delete an association between customer
traffic and a VLAN Stacking SAP. For example, the following command deletes the association between
CVLAN 500 and SAP 20:
-> ethernet-service sap 20 no cvlan 500
When the last customer traffic association is deleted from an SAP, the SAP itself is not automatically
deleted. No traffic is accepted or processed by an SAP in this state, but the SAP ID is still known to the
switch.
Consider the following when configuring the type of customer traffic to tunnel:
• If no customer traffic is associated with a VLAN Stacking SAP, then the SAP does not process any
traffic for the service.
• Only one all or untagged designation is allowed for any given SAP; specifying both for the same SAP
is not allowed.
• Only one untagged designation is allowed per UNI port even if the UNI port is associated with
multiple SAPs.
• Only one all designation is allowed per UNI port even if the UNI port is associated with multiple
SAPs.
• Associating customer traffic with a service using an IP Multicast VLAN (IPMVLAN) is not allowed.
Use the show ethernet-service command to display the type of customer traffic associated with each
SAP configured for the switch
A default profile, named “default-sap-profile”, is automatically assigned to the SAP at the time the SAP is
created (see “Configuring a VLAN Stacking Service Access Point” on page 10-20). If the default profile
values are not sufficient, create a profile to specify different attribute values.
The following command provides an example of creating a new SAP profile to specify a different method
for mapping the SVLAN priority value:
-> ethernet-service sap-profile map_pbit priority map-inner-to-outer-p
In this example, the map_pbit profile specifies priority mapping of the CVLAN inner tag 802.1p value to
the SVLAN outer tag value. The other attributes in this profile are set to their default values.
Note. When CIR and CBS is set to 0 and a PIR/PBS value is defined, then it is saved in the running
configuration. Use the show configuration snapshot command to verify whether the SAP profile
configuration is saved in the running configuration.
The PIR, PBS values can also be set to 0. If all the values - cir, cbs, pir, and pbs are set to zero, this
configuration is not saved in the sap-profile running configuration. The ingress bandwidth is shared
equally between the traffic ingressing through the ports associated with the SAP profile. For example,
-> ethernet-service sap-profile P1 shared cir 0k cbs 0K pir 0k pbs 0K
To delete an SAP profile, use the no form of the ethernet-service sap-profile command. For example, the
following command deletes the map_pbit profile:
-> no ethernet-service sap-profile P1
Use the show ethernet-service sap-profile command to view a list of profiles that are already configured
for the switch. This command also displays the attribute values for each profile.
Consider the following when associating a profile with a VLAN Stacking SAP:
• To change the profile associated with the SAP back to the default profile, specify “default-sap-profile”
for the profile name. For example:
-> ethernet-service sap 20 sap-profile default-sap-profile
• If the SAP ID specified with this command is associated with an IPMVLAN, the profile associated
with the SAP ID must specify CVLAN tag translation. Double tagging is not supported with
IPMVLAN SAPs that are also associated with a UNI port.
Use the show ethernet-service sap command to display the SAP configuration, which includes the profile
association for each SAP.
A default UNI profile, named “default-uni-profile”, is automatically associated with a UNI port. The
default UNI profile specifies how control frames ingressing on the UNI port.
To delete a UNI profile, use the no form of the ethernet-service uni-profile command. For example, the
following command deletes the discard-gvrp profile:
-> no ethernet-service uni-profile discard-gvrp
Use the show ethernet-service uni l2pt-statistics command to view a list of profiles that are already
configured for the switch. This command also displays the attribute values for each profile.
Note. The VLAN Stacking provider edge (PE) switch does not tunnel GVRP frames unless the GVRP
feature and/or GVRP transparent switching functionality is enabled on the PE switch. This is true even if
GVRP processing is enabled for the VLAN Stacking port.
To change the profile associated with the UNI port back to the default profile, specify
default-uni-profile for the profile name. For example:
-> ethernet-service uni 1/1 uni-profile default-uni-profile
Use the show ethernet-service nni l2pt-statistics command to display the profile associations for each
UNI port.
The custom L2 protocol can be applied to specific actions (tunnel, MAC-tunnel and discard). The
following table describes the actions that can be associated:
Action Description
Tunnel Tunnels the specified PDU across the provider network without
modifying the MAC address.
MAC-tunnel Changes the destination MAC address to the configured tunnel
MAC address of the UNI profile before forwarding.
Discard Discards the specified PDU.
Based on the configuration the custom L2 protocols are classified as qualified L2 protocols and
unqualified L2 protocols.
The qualified L2 protocols are the custom L2 protocols that are fully defined with an Ether-Type and
optionally a Sub-Type or ssap/dsap. The action can be set to "Tunnel", "Discard” or "Mac-Tunnel".
The unqualified L2 protocols are the custom L2 protocols that are only defined with a Mac-address or
Mac-address with mask. The action can be set to "Tunnel" or "Discard".
The custom L2 protocol is associated to a UNI profile for specific packet control (Tunnel, MAC-tunnel
and Discard) for proprietary protocol with multicast MAC addresses. To associate a UNI profile to a
specific action use the ethernet-service uni-profile custom-L2-protocol command. For example, the
following command specifies the action “mac-tunnel” to the custom L2 protocol “tunnel-mac-ethertype”
associated to the UNI profile “profile1”:
-> ethernet-service uni-profile profile1 custom-L2-protocol
tunnel-mac-ethertype mac-tunnel
Use the show ethernet-service sap command to view the configuration information of the custom-L2-
protocol entry.
IPCL entry. Along with the number of frames received per protocol, the action taken, that is, the hardware
action configured for the IPCL entry is also shown.
Also, the total number of frames received per UNI profile is also displayed.
In the case of UNI profile, following information is provided:
• Total number of frames received per UNI profile.
• Total number of frames received per protocol, only per IPCL, per UNI profile for hardware treatment
DROP and TUNNEL. For L2 protocols, which have hardware treatment set as TRAP, UNI-profile
statistics will account the software statistics.
• The actual treatment applied in hardware for each L2 protocol.
For more information on the statistic commands see “VLAN Stacking Commands” on page 27-1
Control HW Tunneling
A new feature is introduced to unconditionally forward all MAC tunnel packets irrespective of its UNI
profile as and when required.
This feature can be enabled or disabled using global flag "noMacTunnelFeature" in the AlcatelDe-
bug.cfg file. The feature is functional after reboot. The global tunnel-mac PCL entry is not applied if this
flag is enabled. Therefore, all the tunneled-mac PDUs will be hardware tunneled from NNI.
The flag "noMacTunnelFeature" is set to enable in AlcatelDebug.cfg file using following:
• Debug set noMacTunnelFeature 1
• Reboot the switch after setting the variable in debug file, as the tunnel-mac PCL entry gets applied
during bootup.
Once the system gets rebooted, all the mac-tunnel packets will not be trapped to CPU at NNI and will get
tunneled from hardware.
Warning: When the "noMacTunnelFeature" is enabled, all MAC tunnel packets are tunneled and there is
no check on which protocol it is associated with.
Note. When MAC-tunneling is enabled globally, per SVLAN MAC-tunneling configuration will not be
active.
When MAC-tunneling is disabled globally, the MAC-tunnel status of the SVLANs configured will be
active.
Customer A Customer A
Site 1 Site 2
MAN CLOUD
PE1 PE2
NNI 3/1 NNI 3/1
SVLAN 200
UNI 2/1 UNI 2/1
CVLAN 10 CVLAN 10
Customer B Customer B
Site 1 Site 2
VLAN Stacking Application
2 Configure two VLAN Stacking services on PE1 and PE2 using the ethernet-service service-name
command. Configure one service with the name “CustomerA” and the other service with the name
“Customer B”. Assign “CustomerA” service to SVLAN 100 and “CustomerB” service to SVLAN 200.
-> ethernet-service service-name CustomerA svlan 100
3 Configure port 3/1 on PE1 and PE2 as VLAN Stacking NNI ports using the ethernet-service svlan
nni command. Associate each port with both SVLAN 100 and SVLAN 200.
-> ethernet-service svlan 100 nni 3/1
4 Configure a VLAN Stacking SAP with ID 20 on PE1 and PE2 using the ethernet-service sap.
Associate the SAP with the “CustomerA” service.
-> ethernet-service sap 20 service-name CustomerA
5 Configure a VLAN Stacking SAP with ID 30 on PE1 and PE2 using the ethernet-service sap
command. Associate the SAP with the “CustomerB” service.
-> ethernet-service sap 30 service-name CustomerB
6 Configure port 1/1 on PE1 and PE2 as a VLAN Stacking UNI port and associate 1/1 with SAP 20
using the ethernet-service sap uni command.
-> ethernet-service sap 20 uni 1/1
7 Configure port 2/1 on PE1 and PE2 as a VLAN Stacking UNI port and associate 2/1 with SAP 30
using the ethernet-service sap uni command.
-> ethernet-service sap 30 uni 2/1
8 Configure SAP 20 on PE1 and PE2 to accept all customer traffic on UNI port 1/1 using the
ethernet-service sap cvlan command.
-> ethernet-service sap 20 cvlan all
9 Configure SAP 30 on PE1 and PE2 to accept only customer traffic that is tagged with CVLAN 10
using the ethernet-service sap cvlan command.
-> ethernet-service sap 30 cvlan 10
10 Create an SAP profile on PE1 and PE2 that maps to the inner CVLAN tag 802.1p value to the outer
SVLAN tag using the ethernet-service sap-profile command.
-> ethernet-service sap-profile map_pbit priority map-inner-to-outer-p
11 Associate the “map_pbit” profile to SAP 30 using the ethernet-service sap sap-profile command. It is
not necessary to associate the profile with SAP 20 as this profile is applicable only to Customer B traffic.
-> ethernet-service sap 30 sap-profile map_pbit
12 Verify the VLAN Stacking service configuration using the show ethernet-service command.
The following is an example of what the sample configuration commands look like when entered
sequentially on the command line of the provider edge switches:
The following commands enable and disable the PE1-inward-UNI profile attributes for the switch:
-> loopback-test PE1-inward-UNI enable
Use the show loopback-test command to display the loopback test profile configuration.
Note. Conducting an outward loopback test disrupts the flow of customer traffic on the loopback port and
can cause network reachability problems.
Test Head
MAC A
MAC A MAC B
MAC A MAC B
Test Head
MAC A
MAC A MAC N
MAC A MAC N
ethernet-service uni-profile Displays the active VLAN Stacking mode for the switch.
custom-L2-protocol
show ethernet-service vlan Displays the SVLAN configuration for the switch.
show ethernet-service Displays the VLAN Stacking service configuration for the switch.
show ethernet-service sap Displays the VLAN Stacking service access point (SAP)
configuration for the switch.
show ethernet-service port Displays configuration information for VLAN Stacking ports.
show ethernet-service nni Displays configuration information for NNI port parameters.
show ethernet-service nni l2pt- Displays profile associations for UNI ports.
statistics
show ethernet-service uni l2pt- Displays UNI profile attribute values.
statistics
show ethernet-service sap-profile Displays SAP profile attribute values.
show ethernet-service statistics Displays Tri-Color Marking (TCM) results by showing the number
of packets marked green, yellow, and red.
show ethernet-service sap Displays configuration information of the specific custom-L2-proto-
col entry if specified or displays
information of all the configured custom-L2-protocol entries in the
system.
ethernet-service uni-profile Creates a UNI profile that is used to specify how to process control
packets ingressing on UNI ports.
ethernet-service uni-profile Associates a custom-L2-protocol entry to a UNI profile.
custom-L2-protocol
ethernet-service uni uni-profile Associates a VLAN Stacking UNI profile with a UNI port.
show ethernet-service nni l2pt- Displays the profile associations for VLAN Stacking User Network
statistics Interface (UNI) ports.
show ethernet-service uni l2pt- Displays the statistics of all protocols configured per UNI port.
statistics
show ethernet-service uni-profile Displays the profile statistics for VLAN Stacking User Network
l2pt- statistics Interface (UNI) profiles.
clear ethernet-service uni l2pt- Clears the statistics of all protocols configured per UNI port.
statistics
clear ethernet-service uni-profile Clears the statistics of all UNI profiles.
l2pt-statistics
clear ethernet-service nni l2pt- Clears all Network Network Interface (NNI) ports statistics.
statistics
For more information on the resulting displays from the show commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide. An example of the output for the show ethernet-service command is also
given in “Quick Steps for Configuring VLAN Stacking” on page 10-12.
The Alcatel Multiple Spanning Tree (MST) implementation provides support for the Multiple Spanning
Tree Protocol (MSTP) as defined in the IEEE 802.1Q 2005 standard. In addition to the 802.1D Spanning
Tree Algorithm and Protocol (STP) and the 802.1w Rapid Spanning Tree Algorithm and Protocol (RSTP),
MSTP also ensures that there is always only one data path between any two switches for a given Spanning
Tree instance to prevent network loops.
MSTP is an enhancement to the 802.1Q Common Spanning Tree (CST), which is provided when an
Alcatel switch is running in the flat Spanning Tree operating mode. The flat mode applies a single span-
ning tree instance across all VLAN port connections on a switch. MSTP allows the configuration of Multi-
ple Spanning Tree Instances (MSTIs) in addition to the CST instance. Each MSTI is mapped to a set of
VLANs. As a result, flat mode can support the forwarding of VLAN traffic over separate data paths.
In addition to MSTP support, the STP and RSTP are still available in either the flat or 1x1 mode.
However, if using STP or RSTP in the flat mode, the single Spanning Tree instance per switch algorithm
applies.
In This Chapter
This chapter describes MST in general and how MSTP works on the switch. It provides information about
configuring MSTP through the Command Line Interface (CLI). For more details about the syntax of
commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide. For more information about Span-
ning Tree
configuration commands as they apply to all supported protocols (STP, RSTP, and MSTP), see
Chapter 12, “Configuring Spanning Tree.”
The following topics are included in this chapter as they relate to the Alcatel implementation of the MSTP
standard:
• “MST General Overview” on page 11-4.
• “MST Configuration Overview” on page 11-9.
• “Using Spanning Tree Configuration Commands” on page 11-10.
• “MST Interoperability and Migration” on page 11-11.
• “Quick Steps for Configuring an MST Region” on page 11-13.
• “Quick Steps for Configuring MSTIs” on page 11-15.
• “Verifying the MST Configuration” on page 11-18.
3/1 2/1
VLAN 100 VLAN 100
4/2 5/1
VLAN 200 VLAN 200
|| 5/2
4/8
3/1 2/1
VLAN 100 VLAN 100
4/2 5/1
||
VLAN 200 VLAN 200
|| 5/2
4/8
3/1 2/1
VLAN 100 VLAN 100
CIST-0 CIST-0
4/2 5/1
VLAN 150 || VLAN 150
4/8 5/2
VLAN 200 || VLAN 200
MSTI-2 MSTI-2
2/12 3/6
VLAN 250 || VLAN 250
Using MSTP has the following items in common with STP (802.1D) and RSTP (802.1w) protocols:
• Each protocol ensures one data path between any two switches within the network topology. This
prevents network loops from occurring while at the same time allowing for redundant path configura-
tion.
• Each protocol provides automatic reconfiguration of the network Spanning Tree topology in the event
of a connection failure and/or when a switch is added to or removed from the network.
• All three protocols are supported in the flat Spanning Tree operating mode.
• The flat mode CST instance automatically determines port states and roles across VLAN port and
MSTI associations. This is because the CST instance is active on all ports and only one BPDU is used
to forward information for all MSTIs.
• MSTP is based on RSTP.
Using MSTP differs from STP and RSTP as follows:
• MSTP is only supported when the switch is running in the flat Spanning Tree mode. STP and RSTP are
supported in both the 1x1 and flat modes.
• MSTP allows for the configuration of up to 16 Multiple Spanning Tree Instances (MSTI) in addition to
the CST instance. Flat mode STP and RSTP protocols only use the single CST instance for the entire
switch. See “What is a Multiple Spanning Tree Instance (MSTI)” on page 11-7 for more information.
• MSTP applies a single Spanning Tree instance to an MSTI ID number that represents a set of VLANs;
a one to many association. STP and RSTP in the flat mode apply one Spanning Tree instance to all
VLANs; a one to all association. STP and RSTP in the 1x1 mode apply a single Spanning Tree instance
to each existing VLAN; a one to one association.
• The port priority and path cost parameters are configurable for an individual MSTI that represents the
VLAN associated with the port.
• The flat mode 802.1D or 802.1w CST is identified as instance 1. When using MSTP, the CST is identi-
fied as CIST (Common and Internal Spanning Tree) instance 0. See “What is the Common and Inter-
nal Spanning Tree Instance” on page 11-9 for more information.
• MSTP allows the segmentation of switches within the network into MST regions. Each region is seen
as a single virtual bridge to the rest of the network, even though multiple switches may belong to the
one region. See “What is a Multiple Spanning Tree Region” on page 11-8 for more information.
• MSTP has lower overhead than a 1x1 configuration. In 1x1 mode, because each VLAN is assigned a
separate Spanning Tree instance, BPDUs are forwarded on the network for each VLAN. MSTP only
forwards one BPDU for the CST that contains information for all configured MSTI on the switch.
Switch A Switch D
|| CST
IST
||
||
In addition to the attributes described above, the MST maximum hops parameter defines the number of
bridges authorized to propagate MST BPDU information. In essence, this value defines the size of the
region in that once the maximum number of hops is reached, the BPDU is discarded.
The maximum number of hops for the region is not one of the attributes that defines membership in the
region. See “Quick Steps for Configuring an MST Region” on page 11-13 for a tutorial on how to config-
ure MST region parameters.
segment switch VLANs into separate instances. See “What is a Multiple Spanning Tree Instance
(MSTI)” on page 11-7 for more information.
• Map VLANs to MSTI. By default, all existing VLANs are mapped to the CIST instance 0. Associat-
ing a VLAN to an MSTI specifies which Spanning Tree instance determines the best data path for traf-
fic carried on the VLAN. In addition, the VLAN-to-MSTI mapping is also one of three MST
configuration attributes used to determine that the switch belongs to a particular MST region.
For a tutorial on setting up an example MST configuration, see “Quick Steps for Configuring an MST
Region” on page 11-13 and “Quick Steps for Configuring MSTIs” on page 11-15.
Even though the above command is accepted in the 1x1 mode, the new priority value does not take effect
until the switch mode is changed to flat mode.
Note that explicit commands using the cist and msti keywords are required to define an MSTP configura-
tion. Implicit commands are only allowed for defining STP or RSTP configurations.
Implicit commands resemble previously implemented Spanning Tree commands, but apply to the appro-
priate instance based on the current mode and protocol that is active on the switch. For example, if the 1x1
mode is active, the instance number specified with the following command implies a VLAN ID:
-> bridge 255 priority 16384
If the flat mode is active, the single flat mode instance is implied and thus configured by the command.
Since the flat mode instance is implied in this case, there is no need to specify an instance number. For
example, the following command configures the protocol for the flat mode instance:
-> bridge protocol mstp
Similar to previous releases, it is possible to configure the flat mode instance by specifying 1 for the
instance number (for example, bridge 1 protocol rstp). However, this is only available when the switch is
already running in the flat mode and STP or RSTP is the active protocol.
Note. When a snapshot is taken of the switch configuration, the explicit form of all Spanning Tree
commands is captured. For example, if the priority of MSTI 2 was changed from the default value to a
priority of 16384, then bridge msti 2 priority 16384 is the command captured to reflect this in the snap-
shot file. In addition, explicit commands are captured for both flat and 1x1 mode configurations.
For more information about Spanning Tree configuration commands as they apply to all supported proto-
cols (STP, RSTP, and MSTP), see Chapter 12, “Configuring Spanning Tree.”
it responds with the appropriate protocol BPDU to provide interoperability between the two switches. This
interoperability also serves to indicate the edge of the MST region.
Interoperability between MSTP switches and 1x1 mode switches is not recommended. The 1x1 mode is a
proprietary implementation that creates a separate Spanning Tree instance for each VLAN configured on
the switch. The MSTP implementation is in compliance with the IEEE standard and is only supported on
flat mode switches.
Tagged BPDU transmitted from a 1x1 switch are ignored by a flat mode switch, which can cause a
network loop to go undetected. Although it is not recommended, it may be necessary to temporarily
connect a 1x1 switch to a flat mode switch until migration to MSTP is complete. If this is the case, then
only configure a fixed, untagged connection between VLAN 1 on both switches.
• Making a backup copy of the switch boot.cfg file before changing the protocol to MSTP is highly
recommended. Having a backup copy makes it easier to revert to the non-MSTP configuration if neces-
sary. Once MSTP is active, commands are written in their explicit form and not compatible with previ-
ous releases of Spanning Tree.
• Using MSTP requires changing the switch mode from 1x1 to flat. When the mode is changed from 1x1
to flat, ports still retain their VLAN associations but are now part of a single, flat mode Spanning Tree
instance that spans across all VLANs. As a result, a path that was forwarding traffic in the 1x1 mode
may transition to a blocking state after the mode is changed to flat.
• Once the protocol is changed, MSTP features are available for configuration. Multiple Spanning Tree
Instances (MSTI) are now configurable for defining data paths for VLAN traffic. See “How MSTP
Works” on page 11-4 for more information.
• Note that STP/RSTP use a 16-bit port path cost (PPC) and MSTP uses a 32-bit PPC. When the proto-
col is changed to MSTP, the bridge priority and PPC values for the flat mode CIST instance are reset to
their default values.
• It is possible to configure the switch to use 32-bit PPC value for all protocols (see the bridge path cost
mode command page for more information). If this is the case, then the PPC for the CIST is not reset
when the protocol is changed to/from MSTP.
• This implementation of MSTP is compliant with the IEEE 802.1Q 2005 standard and thus provides
interconnectivity with MSTP compliant systems.
This section provides a tutorial for defining a sample MST region configuration, as shown in the diagram
below:
Switch A Switch D
|| CST
IST
||
||
In order for switches A, B, and C in the above diagram to belong to the same MST region, they must all
share the same values for region name, revision level, and configuration digest (VLAN-to-MSTI
mapping).
The following steps are performed on each switch to define Alcatel Marketing as the MST region name,
2000 as the MST region revision level, map exiting VLANs to existing MSTIs, and 3 as the maximum
hops value for the region:
1 Configure an MST Region name using the bridge mst region name command. For example:
2 Configure the MST Region revision level using the bridge mst region revision level command. For
example:
-> bridge mst region revision level 2000
3 Map VLANs 100 and 200 to MSTI 2 and VLANs 300 and 400 to MSTI 4 using the bridge msti vlan
command to define the configuration digest. For example:
-> bridge msti 2 vlan 100 200
-> bridge msti 4 vlan 300 400
See “Quick Steps for Configuring MSTIs” on page 11-15 for a tutorial on how to create and map
MSTIs to VLANs.
4 Configure 3 as the maximum number of hops for the region using the bridge mst region max hops
command. For example:
-> bridge mst region max hops 3
Note. (Optional) Verify the MST region configuration on each switch with the show spantree mst region
command. For example:
-> show spantree mst region
Configuration Name : Alcatel Marketing,
Revision Level : 2000,
Configuration Digest : 0x922fb3f 31752d68 67fe1155 d0ce8380,
Revision Max hops : 3,
Cist Instance Number : 0
All switches configured with the exact same values as shown in the above example are considered
members of the Alcatel Marketing MST region.
3/1 2/1
VLAN 100 VLAN 100
CIST-0 CIST-0
4/2 5/1
VLAN 150 || VLAN 150
4/8 5/2
VLAN 200 || VLAN 200
MSTI-1 MSTI-1
2/12 3/6
VLAN 250 || VLAN 250
Switch A Switch B
Flat Mode MSTP Quick Steps Example
1 Change the Spanning Tree operating mode, if necessary, on Switch A and Switch B from 1x1 to flat
mode using the bridge mode command. For example:
-> bridge mode flat
Note that defining an MSTP configuration requires the use of explicit Spanning Tree commands, which
are available in both the flat and 1x1 mode. As a result, this step is optional. See “Using Spanning Tree
Configuration Commands” on page 11-10 for more information.
2 Change the Spanning Tree protocol to MSTP using the bridge protocol command. For example:
3 Create VLANs 100, 200, 300, and 400 using the vlan command. For example:
4 Assign switch ports to VLANs, as shown in the above diagram, using the vlan port default command.
For example, the following commands assign ports 3/1, 4/2, 4/8, and 2/12 to VLANs 100, 150, 200, and
250 on Switch A:
-> vlan 100 port default 3/1
-> vlan 150 port default 4/2
-> vlan 200 port default 4/8
-> vlan 250 port default 2/12
The following commands assign ports 2/1, 5/1, 5/2, and 3/6 to VLANs 100, 150, 200, and 250 on
Switch B:
-> vlan 100 port default 2/1
-> vlan 150 port default 5/1
-> vlan 200 port default 5/2
-> vlan 250 port default 3/6
5 Create one MSTI using the bridge msti command. For example:
By default, all VLANs are associated with the CIST instance. As a result, VLANs 100 and 150 do not
require any configuration to map them to the CIST instance.
7 Configure the port path cost (PPC) for all ports on both switches associated with MSTI 1 to a PPC
value that is lower than the PPC value for the ports associated with the CIST instance using the bridge
msti slot/port path cost command. For example, the PPC for ports associated with the CIST instance is
set to the default of 200,000 for 100 MB connections. The following commands change the PPC value for
ports associated with the MSTI 1 to 20,000:
-> bridge msti 1 4/8 path cost 20,000
-> bridge msti 1 2/12 path cost 20,000
-> bridge msti 1 5/2 path cost 20,000
-> bridge msti 1 3/6 path cost 20,000
Note that in this example, port connections between VLANs 150, 200, and 250 on each switch initially
were blocked, as shown in the diagram on page 11-15. This is because in flat mode MSTP, each instance
is active on all ports resulting in a comparison of connections independent of VLAN and MSTI associa-
tions.
To avoid this and allow VLAN traffic to flow over separate data paths based on MSTI association, Step 7
of this tutorial configures a superior port path cost value for ports associated with MSTI 1. As a result,
MSTI 1 selects one of the data paths between its VLANs as the best path, rather than the CIST data paths,
as shown in the diagram on page 11-17.
3/1 2/1
VLAN 100 VLAN 100
CIST-0 CIST-0
4/2 5/1
VLAN 150 || VLAN 150
4/8 5/2
VLAN 200 VLAN 200
MSTI-1 MSTI-1
2/12 3/6
VLAN 250 || VLAN 250
Switch A Switch B
Note that of the two data paths available to MSTI 1 VLANs, one is still blocked because it is seen as
redundant for that instance. In addition, the CIST data path still remains available for CIST VLAN traffic.
Another solution to this scenario is to assign all VLANs to an MSTI, leaving no VLANs controlled by the
CIST. As a result, the CIST BPDU contains only MSTI information. See “How MSTP Works” on
page 11-4 for more information.
show spantree cist Displays the Spanning Tree bridge configuration for the flat mode Com-
mon and Internal Spanning Tree (CIST) instance.
show spantree msti Displays Spanning Tree bridge information for a Multiple Spanning
Tree Instance (MSTI).
show spantree cist ports Displays Spanning Tree port information for the flat mode Common and
Internal Spanning Tree (CIST) instance.
show spantree msti ports Displays Spanning Tree port information for a flat mode Multiple Span-
ning Tree Instance (MSTI).
show spantree mst region Displays the Multiple Spanning Tree (MST) region information for the
switch.
show spantree cist vlan-map Displays the range of VLANs associated with the flat mode Common
and Internal Spanning Tree (CIST) instance.
show spantree msti vlan-map Displays the range of VLANs associated with the specified Multiple
Spanning Tree Instance (MSTI).
show spantree map-msti Displays the Multiple Spanning Tree Instance (MSTI) that is associated
to the specified VLAN.
show spantree mst port Displays a summary of Spanning Tree connection information and
instance associations for the specified port or a link aggregate of ports.
For more information about the resulting displays from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
The Spanning Tree Algorithm and Protocol (STP) is a self-configuring algorithm that maintains a loop-
free topology while providing data path redundancy and network scalability. Based on the IEEE 802.1D
standard, the Alcatel STP implementation distributes the Spanning Tree load between the primary
management module and the network interface modules. In the case of a stack of switches, the STP load is
distributed between the primary management switch and other switches in the stack. This functionality
improves network robustness by providing a Spanning Tree that continues to respond to BPDUs (Bridge
Protocol Data Unit) and port link up and down states in the event of a fail over to a backup management
module or switch.
The Alcatel distributed implementation also incorporates the following Spanning Tree features:
• Configures a physical topology into a single Spanning Tree to ensure that there is only one data path
between any two switches.
• Supports fault tolerance within the network topology. The Spanning Tree is configured again in the
event of a data path or bridge failure or when a new switch is added to the topology.
• Supports two Spanning Tree operating modes; flat (single STP instance per switch) and 1x1 (single
STP instance per VLAN). The 1x1 mode can be configured to interoperate with Cisco’s properiatary
Per VLAN Spanning Tree instance (PVST+).
• Supports four Spanning Tree Algorithms; 802.1D (STP), 802.1w (RSTP), 802.1Q 2005 (MSTP), and
RRSTP.
• Allows 802.1Q tagged ports and link aggregate logical ports to participate in the calculation of the STP
topology.
The Distributed Spanning Tree software is active on all switches by default. As a result, a loop-free
network topology is automatically calculated based on default Spanning Tree switch, VLAN, and port
parameter values. It is only necessary to configure Spanning Tree parameters to change how the topology
is calculated and maintained.
In This Chapter
This chapter provides an overview about how Spanning Tree works and how to configure Spanning Tree
parameters through the Command Line Interface (CLI). CLI commands are used in the configuration
examples; for more details about the syntax of commands, see the OmniSwitch 6250/6350/6450 CLI Refer-
ence Guide.
Configuration procedures described in this chapter include:
• Selecting the switch Spanning Tree operating mode (flat or 1x1) on page 12-14.
• Configuring Spanning Tree bridge parameters on page 12-20.
• Configuring Spanning Tree port parameters on page 12-29.
• Configuring Ring Rapid Spanning Tree on page 12-42.
• Configuring an example Spanning Tree topology on page 12-43.
The following table provides a list of port role types and the port and/or bridge properties that the Span-
ning Tree Algorithm examines to determine which role to assign to the port.
Note. The distinction between a backup port and an alternate port was introduced with the IEEE 802.1w
standard to help define rapid transition of an alternate port to a root port.
The role a port plays or may potentially play in the active Spanning Tree topology determines the port’s
operating state; discarding, learning, or forwarding. The port state is also configurable in that it is possi-
ble to enable or disable a port’s administrative status and/or specify a forwarding or blocking state that is
only changed through user intervention.
The Spanning Tree Algorithm only includes ports in its calculations that are operational (link is up) and
have an enabled administrative status. The following table compares and defines 802.1D and 802.1w port
states and their associated port roles:
STP Port State RSTP Port State Port State Definition Port Role
Disabled Discarding Port is down or administratively disabled Disabled
and is not included in the topology.
Blocking Discarding Frames are dropped, nothing is learned or Alternate, Backup
forwarded on the port. Port is temporarily
excluded from topology.
Learning Learning Port is learning MAC addresses that are seen Root, Designated
on the port and adding them to the bridge
forwarding table, but not transmitting any
data. Port is included in the active topology.
Forwarding Forwarding Port is transmitting and receiving data and is Root, Designated
included in the active topology.
Once the Spanning Tree is calculated, there is only one root bridge, one designated bridge for each LAN,
and one root port on each bridge (except for the root bridge). Data travels back and forth between bridges
over forwarding port connections that form the best, non-redundant path to the root. The active topology
ensures that network loops do not exist.
Root ID The Bridge ID for the bridge that this bridge believes is the root.
Root Path Cost The sum of the Path Costs that lead from the root bridge to this bridge port.
The Path Cost is a configurable parameter value. The IEEE 802.1D standard specifies a
default value that is based on port speed. See “Configuring Port Path Cost” on
page 12-34 for more information.
Bridge ID An eight-byte hex value that identifies this bridge within the Spanning Tree. The first
two bytes contain a configurable priority value and the remaining six bytes contain a
bridge MAC address. See “Configuring the Bridge Priority” on page 12-23 for more
information.
Each switch chassis is assigned a dedicated base MAC address. This is the MAC
address that is combined with the priority value to provide a unique Bridge ID for the
switch. For more information about the base MAC address, see the OmniSwitch 6250/
6350/6450 Hardware Users Guide for the switch.
Port ID A 16-bit hex value that identifies the bridge port that transmitted this BPDU. The first 4
bits contain a configurable priority value and the remaining 12 bits contain the physical
switch port number. See “Configuring Port Priority” on page 12-33 for more informa-
tion.
The sending and receiving of Configuration BPDU between switches participating in the bridged network
constitute the root bridge election; the best path to the root is determined and then advertised to the rest of
the network. BPDU provide enough information for the STP software running on each switch to deter-
mine the following:
• Which bridge will serve as the root bridge.
• The shortest path between each bridge and the root bridge.
• Which bridge will serve as the designated bridge for the LAN.
• Which port on each bridge will serve as the root port.
• The port state (forwarding or discarding) for each bridge port based on the role the port will play in the
active Spanning Tree topology.
The following events trigger the transmitting and/or processing of BPDU in order to discover and main-
tain the Spanning Tree topology:
• When a bridge first comes up, it assumes it is the root and starts transmitting Configuration BPDU on
all its active ports advertising its own bridge ID as the root bridge ID.
• When a bridge receives BPDU on its root port that contains more attractive information (higher prior-
ity parameters and/or lower path costs), it forwards this information on to other LANs to which it is
connected for consideration.
• When a bridge receives BPDU on its designated port that contains information that is less attractive
(lower priority values and/or higher path costs), it forwards its own information to other LANs to
which it is connected for consideration.
STP evaluates BPDU parameter values to select the best BPDU based on the following order of prece-
dence:
1 The lowest root bridge ID (lowest priority value, then lowest MAC address).
3 If root path costs are equal, the bridge ID of the bridge sending the BPDU.
4 If the previous three values tie, then the port ID (lowest priority value, then lowest port number).
When a topology change occurs, such as when a link goes down or a switch is added to the network, the
affected bridge sends Topology Change Notification (TCN) BPDU to the designated bridge for its LAN.
The designated bridge then forwards the TCN to the root bridge. The root then sends out a Configuration
BPDU and sets a Topology Change (TC) flag within the BPDU to notify other bridges that there is a
change in the configuration information. Once this change is propagated throughout the Spanning Tree
network, the root stops sending BPDU with the TC flag set and the Spanning Tree returns to an active,
stable topology.
Note. You can restrict the propagation of TCNs on a port. To restrict TCN propagation on a port, see
“Configuring STP Port Parameters” on page 12-29.
Topology Examples
The following diagram shows an example of a physical network topology that incorporates data path
redundancy to ensure fault tolerance. These redundant paths, however, create loops in the network config-
uration. If a device connected to Switch A sends broadcast packets, Switch A floods the packets out all of
its active ports. The switches connected to Switch A in turn floods the broadcast packets out their active
ports, and Switch A eventually receives the same packets back and the cycle starts over again. This causes
severe congestion on the network, often referred to as a broadcast storm.
Switch D Switch C
Switch A
Switch B
The Spanning Tree Algorithm prevents network loops by ensuring that there is always only one active link
between any two switches. This is done by transitioning one of the redundant links into a blocking state,
leaving only one link actively forwarding traffic. If the active link goes down, then Spanning Tree transi-
tions one of the blocked links to the forwarding state to take over for the downed link. If a new switch is
added to the network, the Spanning Tree topology is automatically recalculated to include the monitoring
of links to the new switch.
The following diagram shows the logical connectivity of the same physical topology as determined by the
Spanning Tree Algorithm:
Switch D Switch C
(Root Bridge)
2/3 PC=4 3/8
Bridge ID Bridge ID
10, 00:00:00:00:00:01 13, 00:00:00:00:00:04
2/2 PC=19 3/9
2/1
3/10
PC=19 PC=100
2/10 3/2
Bridge ID Bridge ID
11, 00:00:00:00:00:02 PC=19 12, 00:00:00:00:00:03
2/9 3/1
Switch A
(Designated Bridge) Switch B
In the above active Spanning Tree topology example, the following configuration decisions were made as
a result of calculations performed by the Spanning Tree Algorithm:
• Switch D is the root bridge because its bridge ID has a priority value of 10 (the lower the priority value,
the higher the priority the bridge has in the Spanning Tree). If all four switches had the same priority,
then the switch with the lowest MAC address in its bridge ID would become the root.
• Switch A is the designated bridge for Switch B, because it provides the best path for Switch B to the
root bridge.
• Port 2/9 on Switch A is a designated port, because it connects the LAN from Switch B to Switch A.
• All ports on Switch D are designated ports, because Switch D is the root and each port connects to a
LAN.
• Ports 2/10, 3/1, and 3/8 are the root ports for Switches A, B, and C, respectively, because they offer the
shortest path towards the root bridge.
• The port 3/9 connection on Switch C to port 2/2 on Switch D is in a discarding (blocking) state, as the
connection these ports provides is redundant (backup) and has a higher path cost value than the 2/3 to
3/8 connection between the same two switches. As a result, a network loop is avoided.
• The port 3/2 connection on Switch B to port 3/10 on Switch C is also in a discarding (blocking) state,
as the connection these ports provides has a higher path cost to root Switch D than the path between
Switch B and Switch A. As a result, a network loop is avoided.
The following diagram shows a flat mode switch with STP (802.1D) as the active protocol. All ports,
regardless of their default VLAN configuration or tagged VLAN assignments, are considered part of one
Spanning Tree instance. To see an example of a flat mode switch with MSTP (802.1s) as the active proto-
col, see Chapter 11, “Using 802.1Q Multiple Spanning Tree.”
Flat STP
In the above example, if port 8/3 connects to another switch and port 10/5 connects to that same switch,
the Spanning Tree Algorithm would detect a redundant path and transition one of the ports into a blocking
state. The same holds true for the tagged ports.
The following diagram shows a switch running in the 1x1 Spanning Tree mode and shows Spanning Tree
participation for both fixed and tagged ports.
STP 2 STP 3
STP 4
Switch
Port 1/3 Port 1/5
Default VLAN 5 Default VLAN 10
VLAN 2 (tagged)
Port 2/5
Port 2/3
Default VLAN 2
Default VLAN 5
VLAN 10 (tagged)
In the above example, STP2 is a single Spanning Tree instance since VLAN 5 contains only fixed ports.
STP 3 and STP 4 are a combination of single and 802.1Q Spanning Tree instances because VLAN 2
contains both fixed and tagged ports. On ports where VLAN 2 is the default VLAN, BPDU are not tagged.
On ports where VLAN 2 is a tagged VLAN, BPDU are also tagged.
Configuration Overview
You can use the bridge mode 1X1 pvst+ command to globally enable the PVST+ interoperability mode
on an OmniSwitch:
-> bridge mode 1x1 pvst+ enable
To disable the PVST+ mode interoperability mode on an OmniSwitch, use the following command:
-> bridge mode 1x1 pvst+ disable
The bridge port pvst+ command is used to configure how a particular port handles BPDUs when
connecting to a Cisco switch.
You can use the bridge port pvst+ command with the enable option to configure the port to handle only
the PVST+ BPDUs and IEEE BPDUs for VLAN 1 (Cisco native VLAN for CST). For example:
-> bridge port 1/3 pvst+ enable
You can use the bridge port pvst+ command with the auto option to configure the port to handle IEEE
BPDUs initially (that is, disable state). Once a PVST+ BPDU is received, it then handles PVST+ BPDUs
and IEEE BPDUs for a Cisco native VLAN. For example:
-> bridge port 1/3 pvst+ auto
Note that explicit commands using the cist and msti keywords are required to define an MSTP (802.1s)
configuration. Implicit commands are only allowed for defining STP or RSTP configurations. See
Chapter 11, “Using 802.1Q Multiple Spanning Tree,” for more information about these keywords and
using implicit and explicit commands.
The following is a summary of Spanning Tree bridge configuration commands. For more information
about these commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Note. When a snapshot is taken of the switch configuration, the explicit form of all Spanning Tree
commands is captured. For example, if the bridge protocol for the flat mode instance was changed from
STP to MSTP, then bridge cist protocol mstp is the command syntax captured to reflect this in the snap-
shot file. In addition, explicit commands are captured for both flat and 1x1 mode configurations.
The following sections provide information and procedures for using implicit bridge configuration
commands and also includes explicit command examples.
Note that when configuring the protocol value for a VLAN instance, MSTP is not an available option. This
protocol is only supported on the flat mode instance.
In addition, the explicit bridge 1x1 protocol command configures the protocol for a VLAN instance
regardless of which mode (1x1 or flat) is active on the switch. For example, the following command also
changes the protocol for VLAN 455 to RSTP:
-> bridge 1x1 455 protocol rstp
To configure the protocol for the single flat mode instance when the switch is running in either mode (1x1
or flat), use the bridge protocol command but do not specify an instance number. This command config-
ures the flat mode instance by default, so an instance number is not needed, as shown in the following
example:
-> bridge protocol mstp
As in previous releases, it is possible to configure the flat mode instance with the bridge protocol
command by specifying 1 as the instance number (for example, bridge 1 protocol rstp). However, this is
only available when the switch is already running in the flat mode and STP or RSTP is the active protocol.
In addition, the explicit bridge cist protocol command configures the protocol for the flat mode instance
regardless of which mode (1x1 or flat) is active on the switch. For example, the following command
selects the RSTP protocol for the flat mode instance:
-> bridge cist protocol mstp
Note. Configuring a Spanning Tree bridge instance with a priority value that causes the instance to
become the root is recommended, instead of relying on the comparison of switch base MAC addresses to
determine the root.
If the switch is running in the 1x1 Spanning Tree mode, then a priority value is assigned to each VLAN
instance. If the switch is running in the flat Spanning Tree mode, the priority is assigned to the flat mode
instance or a Multiple Spanning Tree Instance (MSTI). In both cases, the default priority value assigned is
32768. Note that priority values for an MSTI must be multiples of 4096.
To change the bridge priority value for a VLAN instance, specify a VLAN ID with the bridge priority
command when the switch is running in the 1x1 mode. For example, the following command changes the
priority for VLAN 455 to 25590:
-> bridge 455 priority 25590
The explicit bridge 1x1 priority command configures the priority for a VLAN instance when the switch
is running in either mode (1x1 or flat). For example, the following command performs the same function
as the command in the previous example:
-> bridge 1x1 455 priority 25590
Note. If PVST+ mode is enabled on the switch, then the priority values can be assigned only in the multi-
ples of 4096 to be compatible with the Cisco MAC Reduction mode; any other values results in an error
message.
To change the bridge priority value for the flat mode instance, use either the bridge priority command or
the bridge cist priority command. Note that both commands are available when the switch is running in
either mode (1x1 or flat) and an instance number is not required. For example, the following commands
change the priority value for the flat mode instance to 12288:
-> bridge priority 12288
-> bridge cist priority 12288
As in previous releases, it is possible to configure the flat mode instance with the bridge protocol
command by specifying 1 as the instance number (for example, bridge 1 protocol rstp). However, this is
only available when the switch is already running in the flat mode and STP or RSTP is the active protocol.
The bridge priority value is also configurable for a Multiple Spanning Tree Instance (MSTI). To configure
this value for an MSTI, use the explicit bridge msti priority command and specify the MSTI ID for the
instance number and a priority value that is a multiple of 4096. For example, the following command
configures the priority value for MSTI 10 to 61440:
-> bridge msti 10 priority 61440
Note that when MSTP is the active flat mode protocol, explicit Spanning Tree bridge commands are
required to configure parameter values. Implicit commands are for configuring parameters when the STP
or RSTP protocols are in use. See Chapter 11, “Using 802.1Q Multiple Spanning Tree,” for more informa-
tion.
If the switch is running in the 1x1 Spanning Tree mode, then a hello time value is defined for each VLAN
instance. If the switch is running in the flat Spanning Tree mode, then a hello time value is defined for the
single flat mode instance. In both cases, the default hello time value used is 2 seconds.
To change the bridge hello time value for a VLAN instance, specify a VLAN ID with the bridge hello
time command when the switch is running in the 1x1 mode. For example, the following command
changes the hello time for VLAN 455 to 5 seconds:
-> bridge 455 hello time 5
The explicit bridge 1x1 hello time command configures the hello time value for a VLAN instance when
the switch is running in either mode (1x1 or flat). For example, the following command performs the same
function as the command in the previous example:
-> bridge 1x1 455 hello time 5
To change the bridge hello time value for the flat mode instance, use either the bridge hello time
command or the bridge cist hello time command. Note that both commands are available when the switch
is running in either mode (1x1 or flat) and an instance number is not required. For example, the following
commands change the hello time value for the flat mode instance to 12288:
-> bridge hello time 10
-> bridge cist hello time 10
As in previous releases, it is possible to configure the flat mode instance with the bridge hello time
command by specifying 1 as the instance number (for example, bridge 1 hello time 5). However, this is
only available when the switch is already running in the flat mode and STP or RSTP is the active protocol.
Note that the bridge hello time is not configurable for Multiple Spanning Tree Instances (MSTI). These
instances inherit the hello time from the flat mode instance (CIST).
The explicit bridge 1x1 max age command configures the max age time for a VLAN instance when the
switch is running in either mode (1x1 or flat). For example, the following command performs the same
function as the command in the previous example:
-> bridge 1x1 455 max age 10
To change the max age time value for the flat mode instance, use either the bridge max age command or
the bridge cist max age command. Note that both commands are available when the switch is running in
either mode (1x1 or flat) and an instance number is not required. For example, the following commands
change the max age time for the flat mode instance to 10:
-> bridge max age 10
-> bridge cist max age 10
As in previous releases, it is possible to configure the flat mode instance with the bridge max age
command by specifying 1 as the instance number (for example, bridge 1 max age 30). However, this is
only available when the switch is already running in the flat mode and STP or RSTP is the active protocol.
Note that the max age time is not configurable for Multiple Spanning Tree Instances (MSTI). These
instances inherit the max age time from the flat mode instance (CIST).
The explicit bridge 1x1 forward delay command configures the forward delay time for a VLAN instance
when the switch is running in either mode (1x1 or flat). For example, the following command performs the
same function as the command in the previous example:
-> bridge 1x1 455 forward delay 20
To change the forward delay time value for the flat mode instance, use either the bridge forward delay
command or the bridge cist forward delay command. Note that both commands are available when the
switch is running in either mode (1x1 or flat) and an instance number is not required. For example, the
following commands change the forward delay time for the flat mode instance to 10:
As in previous releases, it is possible to configure the flat mode instance with the bridge forward delay
command by specifying 1 as the instance number (for example, bridge 1 forward delay 30). However,
this is only available when the switch is already running in the flat mode and STP or RSTP is the active
protocol.
Note that the forward delay time is not configurable for Multiple Spanning Tree Instances (MSTI). These
instances inherit the forward delay time from the flat mode instance (CIST).
Note. Make sure that disabling BPDU switching on a Spanning Tree disabled VLAN will not cause
network loops to go undetected.
Note. Cisco supports two default path cost modes: long or short just like in OmniSwitch 1x1 implementa-
tion. If you have configured PVST+ mode in the OmniSwitch, it is recommended that the same default
path cost mode has to be configured in the same way in all the switches, so that, the path costs for similar
interface types is consistent when connecting ports between OmniSwitch and Cisco Switches.
VLAN 1 VLAN 1
4/2 5/1
802.1q tag
MSTI-1 VLAN 2 VLAN 2 MSTI-1
In the above diagram, port 4/2 is the Root port and port 5/1 is a Designated port for MSTI 1. AVC is not
enabled. If another link with the same speed and lower port numbers is added to default VLAN 1 on both
switches, the new link becomes the root for MSTI 1 and the tagged link between VLAN 2 is blocked, as
shown below:
3/1 2/1
VLAN 1 VLAN 1
||
4/2 802.1q tag 5/1
MSTI-1 VLAN 2 VLAN 2 MSTI-1
If AVC was enabled in the above example, AVC would have assigned the new link an infinite path cost
value that would make this link undesirable as the root for MSTI 1.
Balancing VLANs across links according to their Multiple Spanning Tree Instance (MSTI) grouping is
highly recommended to ensure that there is not a loss of connectivity during any possible topology
changes. Enabling AVC on the switch is another way to prevent undesirable ports from becoming the root
for an MSTI.
By default AVC is disabled on the switch. Use the bridge auto-vlan-containment command to globally
enable this feature for all MSTIs. Once AVC is globally enabled, then it is possible to disable AVC for
individual MSTIs using the same command. For example, the following commands globally enable AVC
and then disable it for MSTI 10:
-> bridge auto-vlan-containment enable
-> bridge msti 10 auto-vlan-containment disable
Note that an administratively set port path cost takes precedence and prevents AVC configuration of the
path cost. The exception to this is if the port path cost is administratively set to zero, which resets the path
cost to the default value. In addition, AVC does not have any effect on root bridges.
The following is a summary of Spanning Tree port configuration commands. For more information about
these commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
The following sections provide information and procedures for using implicit Spanning Tree port configu-
ration commands and also includes explicit command examples.
Note. When a snapshot is taken of the switch configuration, the explicit form of all Spanning Tree
commands is captured. For example, if the bridge protocol for the flat mode instance was changed from
STP to MSTP, then bridge cist protocol mstp is the command syntax captured to reflect this in the snap-
shot file. In addition, explicit commands are captured for both flat and 1x1 mode configurations.
The explicit bridge 1x1 slot/port command configures the priority for a VLAN instance when the switch
is running in either mode (1x1 or flat). For example, the following commands perform the same function
as the commands in the previous example:
-> bridge 1x1 10 8/1 enable
-> bridge 1x1 20 6/2 disable
To change the port Spanning Tree status for the flat mode instance, use either the bridge slot/port
command or the bridge cist slot/port command. Note that both commands are available when the switch
is running in either mode (1x1 or flat) and an instance number is not required. For example, the following
commands disable the Spanning Tree status on port 1/24 for the flat mode instance:
-> bridge 1/24 disable
-> bridge cist 1/24 disable
As in previous releases, it is possible to configure the flat mode instance with the bridge slot/port
command by specifying 1 as the instance number (for example, bridge 1 1/24 enable). However, this is
only available when the switch is already running in the flat mode and STP or RSTP is the active protocol.
For more information about configuring an aggregate of ports, see Chapter 25, “Configuring Static Link
Aggregation,” and Chapter 26, “Configuring Dynamic Link Aggregation.”
The explicit bridge cist slot/port priority command configures the port priority value for a VLAN
instance when the switch is running in either mode (1x1 or flat). For example, the following command
performs the same function as the command in the previous example:
-> bridge 1x1 10 8/1 priority 3
To change the port priority value for the flat mode instance, use either the bridge slot/port priority
command or the bridge cist slot/port priority command. Note that both commands are available when
the switch is running in either mode (1x1 or flat) and an instance number is not required. For example, the
following commands change the priority value for port 1/24 for the flat mode instance to 15:
-> bridge 1/24 priority 15
-> bridge cist 1/24 priority 10
As in previous releases, it is possible to configure the flat mode instance with the bridge slot/port prior-
ity command by specifying 1 as the instance number (for example, bridge 1 1/24 priority 15). However,
this is only available when the switch is already running in the flat mode and STP or RSTP is the active
protocol.
The port priority value is also configurable for a Multiple Spanning Tree Instance (MSTI). To configure
this value for an MSTI, use the explicit bridge msti slot/port priority command and specify the MSTI ID
for the instance number. For example, the following command configures the priority value for port 1/12
for MSTI 10 to 5:
-> bridge msti 10 1/12 priority 5
Note that when MSTP is the active flat mode protocol, explicit Spanning Tree bridge commands are
required to configure parameter values. Implicit commands are for configuring parameters when the STP
or RSTP protocols are in use. See Chapter 11, “Using 802.1Q Multiple Spanning Tree,” for more informa-
tion.
For more information about configuring an aggregate of ports, see Chapter 25, “Configuring Static Link
Aggregation,” and Chapter 26, “Configuring Dynamic Link Aggregation.”
IEEE 802.1D
Link Speed
Recommended Value
10 MB 2,000,000
100 MB 200,000
1 GB 20,000
Is a 16-bit path cost value is in use and the path_cost is set to zero, the following IEEE 802.1D recom-
mended default path cost values based on link speed are used:
IEEE 802.1D
Link Speed
Recommended Value
4 Mbps 250
10 Mbps 100
16 Mbps 62
100 Mbps 19
1 Gbps 4
By default, Spanning Tree is enabled on a port and the path cost is set to zero. If the switch is running in
the 1x1 Spanning Tree mode, then the port path cost applies to the specified VLAN instance associated
with the port. If the switch is running in the flat Spanning Tree mode, then the port path cost applies across
all VLANs associated with the port. The flat mode instance is specified as the port’s instance, even if the
port is associated with other VLANs.
To change the port path cost value for a VLAN instance, specify a VLAN ID with the bridge slot/port
path cost command when the switch is running in the 1x1 mode. For example, the following command
configures a 16-bit path cost value for port 8/1 for VLAN 10 to 19 (the port speed is 100 MB, 19 is the
recommended value).
-> bridge 10 8/1 path cost 19
The explicit bridge 1x1 slot/port path cost command configures the port path cost value for a VLAN
instance when the switch is running in either mode (1x1 or flat). For example, the following command
performs the same function as the command in the previous example:
-> bridge 1x1 10 8/1 path cost 19
To change the port path cost value for the flat mode instance, use either the bridge slot/port path cost
command or the bridge cist slot/port path cost command. Note that both commands are available when
the switch is running in either mode (1x1 or flat) and an instance number is not required. For example, the
following commands configure a 32-bit path cost value for port 1/24 for the flat mode instance to 20,000
(the port speed is 1 GB, 20,000 is the recommended value):
-> bridge 1/24 path cost 20000
-> bridge cist 1/24 path cost 20000
As in previous releases, it is possible to configure the flat mode instance with the bridge slot/port path
cost command by specifying 1 as the instance number (for example, bridge 1 1/24 path cost 19).
However, this is only available when the switch is already running in the flat mode and STP or RSTP is
the active protocol.
The port path cost value is also configurable for a Multiple Spanning Tree Instance (MSTI). To configure
this value for an MSTI, use the explicit bridge msti slot/port path cost command and specify the MSTI
ID for the instance number. For example, the following command configures the path cost value for port 1/
12 for MSTI 10 to 19:
-> bridge msti 10 1/12 path cost 19
Note that when MSTP is the active flat mode protocol, explicit Spanning Tree bridge commands are
required to configure parameter values. Implicit commands are for configuring parameters when the STP
or RSTP protocols are in use. See Chapter 11, “Using 802.1Q Multiple Spanning Tree,” for more informa-
tion.
If a 16-bit path cost value is in use and the path_cost for a link aggregate is set to zero, the following
default values based on link speed and link aggregate size are used. Note that for Gigabit ports the aggre-
gate size is not applicable in this case:
To change the path cost value for a link aggregate, use the bridge slot/port path cost commands
described above, but specify a link aggregate control number instead of a slot and port. For example, the
following command sets the path cost for link aggregate 10 associated with VLAN 755 to 19:
-> bridge 755 10 path cost 19
For more information about configuring an aggregate of ports, see Chapter 25, “Configuring Static Link
Aggregation,” and Chapter 26, “Configuring Dynamic Link Aggregation.”
The explicit bridge 1x1 slot/port mode command configures the port mode for a VLAN instance when
the switch is running in either mode (1x1 or flat). For example, the following command performs the same
function as the command in the previous example:
-> bridge 1x1 10 8/1 mode forwarding
To change the port Spanning Tree mode for the flat mode instance, use either the bridge slot/port mode
command or the bridge cist slot/port mode command. Note that both commands are available when the
switch is running in either mode (1x1 or flat) and an instance number is not required. For example, the
following commands configure the Spanning Tree mode on port 1/24 for the flat mode instance:
-> bridge 1/24 mode blocking
-> bridge cist 1/24 mode blocking
As in previous releases, it is possible to configure the flat mode instance with the bridge slot/port mode
command by specifying 1 as the instance number (for example, bridge 1 1/24 mode dynamic). However,
this is only available when the switch is already running in the flat mode and STP or RSTP is the active
protocol.
For more information about configuring an aggregate of ports, see Chapter 25, “Configuring Static Link
Aggregation,” and Chapter 26, “Configuring Dynamic Link Aggregation.”
Note. Configure ports that connects to a host (PC, workstation, server, and so on.) as edge ports so that
these ports transitions directly to a forwarding state and not trigger an unwanted topology change when a
device is connected to the port. If a port is configured as a point to point or no point to point connection
type, the switch assumes a topology change when this port goes active and will flush and relearn all
learned MAC addresses for the port’s assigned VLAN.
By default, Spanning Tree is enabled on the port and the connection type is set to auto point to point. The
auto point to point setting determines the connection type based on the operational status of the port.
If the switch is running in the 1x1 Spanning Tree mode, then the connection type applies to the specified
VLAN instance associated with the port. If the switch is running in the flat Spanning Tree mode, then the
connection type applies across all VLANs associated with the port. The flat mode instance is referenced as
the port’s instance, even if the port is associated with other VLANs.
To change the port connection type for a VLAN instance, specify a VLAN ID with the bridge slot/port
connection command when the switch is running in the 1x1 mode. For example, the following command
defines an edge port connection type for port 8/1 associated with VLAN 10.
-> bridge 10 8/1 connection edgeport
The explicit bridge 1x1 slot/port connection command configures the connection type for a VLAN
instance when the switch is running in either mode (1x1 or flat). For example, the following command
performs the same function as the command in the previous example:
-> bridge 1x1 10 8/1 connection edgeport
To change the port Spanning Tree mode for the flat mode instance, use either the bridge slot/port connec-
tion command or the bridge cist slot/port connection command. Note that both commands are available
when the switch is running in either mode (1x1 or flat) and an instance number is not required. For exam-
ple, the following commands configure the connection type for port 1/24 for the flat mode instance:
-> bridge 1/24 connection ptp
-> bridge cist 1/24 connection ptp
As in previous releases, it is possible to configure the flat mode instance with the bridge slot/port connec-
tion command by specifying 1 as the instance number (for example, bridge 1 1/24 connection noptp).
However, this is only available when the switch is running in the flat mode and STP or RSTP is the active
protocol. Note that the bridge slot/port connection command only configures one port at a time.
For more information about configuring an aggregate of ports, see Chapter 25, “Configuring Static Link
Aggregation,” and Chapter 26, “Configuring Dynamic Link Aggregation.”
To enable the auto-edge functionality of the port, enter the following command:
-> bridge cist 8/23 auto-edge enable
The administrative edge port status (admin-edge) is used to determine the status of the port when auto-
matic edge port configuration (auto-edge) is disabled.
To define the administrative edge port status (admin-edge) of a port in a CIST instance, use the bridge
cist slot/port admin-edge command. Similarly for a port in 1x1 instance, use the bridge 1x1 slot/port
admin-edge command.
To enable the administrative edge port status for a port in CIST mode, enter the following command:
-> bridge cist 8/23 admin-edge disable
Note that the above commands also provide optional syntax; restricted-role or root-guard. For example,
the following two commands perform the same function:
-> bridge 1x1 2/1 restricted-role enable
When root guard is enabled for a port, it cannot become the root port, even if it is the most likely candi-
date for becoming the root port. It is selected as the alternate port when the root port is selected.
Using RRSTP
The Ring Rapid Spanning Tree Protocol (RRSTP) is complimentary to both the Spanning Tree Protocol
(STP) as well as the Multiple Spanning Tree Protocol (MSTP). It is designed to provide faster conver-
gence time when switches are connected point to point in a ring topology. RRSTP can only be configured
on an OmniSwitch running in flat mode.
RRSTP reduces convergence time by finding the bridge that hosts the alternate (ALT) port and immedi-
ately changing the ALT port state to forwarding without altering the MSTP port state. This process quickly
enables the data path. The RRSTP frame travels from the point of failure to the ALT port in both direc-
tions. The MAC addresses corresponding to the ports in the ring are flushed to make the data path conver-
gence time much faster than the normal MSTP.
While RRSTP is already reacting to the loss of connectivity, the standard MSTP BPDU carrying the link
down information is processed in normal fashion at each hop. When this MSTP BPDU reaches the bridge
whose ALT port is now in the "ALT FWD" state, due to RRSTP frame processing, it updates the MSTP
state of the two ports in the ring as per the MSTP standard.
The following limitations has to be noted when using RRSTP:
• There can be no alternate connections for the same instance between any two switches within an
RRSTP ring topology.
• A port on a bridge can only be part of one RRSTP ring at any given instance.
• All bridges, which need to be made part of a ring, can be configured only statically.
• Fast convergence does not occur if an RRSTP frame is lost. However, MSTP convergence still takes
place at a later time because there is no way of knowing about the RRSTP frame loss.
• RRSTP convergence may not happen when changes in configuration result in an unstable topology.
• If either of the two ports of the RRSTP ring on a bridge goes down or if one of the bridges in the ring
goes down, the RRSTP convergence may not happen. However, MSTP convergence continues without
interruption.
• A single switch can participate in up to 128 RRSTP rings.
Configuring RRSTP
This section describes how to use Alcatel’s Command Line Interface (CLI) commands to configure Ring
Rapid Spanning Tree Protocol (RRSTP) on a switch.
When configuring RRSTP parameters, you must perform the following steps:
1 Enable RRSTP on your switch. To enable RRSTP globally on a switch, use the bridge rrstp
command, which is described in “Enabling and Disabling RRSTP” on page 12-42.
2 Create RRSTP ring comprising of two ports. To create an RRSTP ring comprising of two ports, use
the bridge rrstp ring command, which is described in “Creating and Removing RRSTP Rings” on
page 12-42.
You can display the current RRSTP status at a global level using the show bridge rrstp configuration
command.
-> show bridge rrstp configuration
RRSTP Global state is Enabled
To modify the vlan-tag associated with the ring, use the bridge rrstp ring vlan-tag command by entering:
-> bridge rrstp ring 1 vlan-tag 20
To remove an RRSTP ring comprising of two ports, use the no form of the command by entering:
-> no bridge rrstp ring 1
You can display the information of a specific ring or all the rings on the switch using the show bridge
rrstp ring command, as shown:
-> show bridge rrstp ring
RingId Vlan-Tag Ring-Port1 Ring-Port2 Ring Status
-----------+------------+---------------+--------------+---------------
2 1000 1/19 1/10 enabled
6 20 1/1 1/8 disabled
128 1 0/1 0/31 enabled
Switch D Switch C
(Root Bridge)
VLAN 255 Bridge ID 2/3 PC=4 3/8 VLAN 255 Bridge ID
10, 00:d0:95:00:00:01 32768, 00:d0:95:00:00:04
3/10
PC=4 PC=19
3/2
2/10
2/8 PC=4 3/3
VLAN 255 Bridge ID VLAN 255 Bridge ID
32768, 00:d0:95:00:00:02 32768, 00:d0:95:00:00:03
2/9 PC=4 3/1
Switch A
(Designated Bridge)
Switch B
Forwarding Root Port
Blocking Designated Port
Path Cost PC
• The path cost for each port connection defaults to a value based on the link speed. For example, the
connection between Switch B and Switch C is a 100 Mbps link, which defaults to a path cost of 19.
• VLAN 255 on Switch D is configured with a Bridge ID priority value of 10, which is less than the
same value for VLAN 255 configured on the other switches. As a result, VLAN 255 was elected the
Spanning Tree root bridge for the VLAN 255 broadcast domain.
• A root port is identified for VLAN 255 on each switch, except the root VLAN 255 switch. The root
port identifies the port that provides the best path to the root VLAN.
• VLAN 255 on Switch A was elected the designated bridge because it offers the best path cost for
Switch B to the root VLAN 255 on Switch D.
• Port 2/9 on Switch A is the designated port for the Switch A to Switch B connection because Switch A
is the designated bridge for Switch B.
• Redundant connections exist between Switch D and Switch C. Ports 2/2 and 3/9 are in a discarding
(blocking) state because this connection has a higher path cost than the connection provided through
ports 2/3 and 3/8. As a result, a network loop condition is avoided.
• Redundant connections also exist between Switch A and Switch B. Although the path cost value for
both of these connections is the same, ports 2/8 and 3/3 are in a discarding state because their port
priority values (not shown) are higher than the same values for ports 2/10 and 3/1.
• The ports that provide the connection between Switch B and Switch C are in a discarding (blocking)
state, because this connection has a higher path cost than the other connections leading to the root
VLAN 255 on Switch D. As a result, a network loop is avoided.
2 Assign the switch ports that provide connections between each switch to VLAN 255. For example, the
following commands entered on Switches A, B, C, and D, respectively, assign the ports shown in the
example network diagram on page 12-43 to VLAN 255:
-> vlan 255 port default 2/8-10
-> vlan 255 port default 3/1-3
-> vlan 255 port default 3/8-10
-> vlan 255 port default 2/1-3
3 Change the Spanning Tree protocol for VLAN 255 to 802.1w (rapid reconfiguration) on each switch
using the following command:
-> bridge 255 protocol 1w
4 Change the bridge priority value for VLAN 255 on Switch D to 10 using the following command
(leave the priority for VLAN 255 on the other three switches set to the default value of 32768):
-> bridge 255 priority 10
VLAN 255 on Switch D has the lowest Bridge ID priority value of all four switches, which qualifies it as
the Spanning Tree root VLAN for the VLAN 255 broadcast domain.
Note. To verify the VLAN 255 Spanning Tree configuration on each switch use the following show
commands. The following outputs are for example purposes only and may not match values shown in the
sample network configuration:
-> show spantree 255
Spanning Tree Parameters for Vlan 255
Spanning Tree Status : ON,
Protocol : IEEE 802.1W (Fast STP),
mode : 1X1 (1 STP per Vlan),
Priority : 32768(0x0FA0),
Bridge ID : 8000-00:d0:95:00:00:04,
Designated Root : 000A-00:d0:95:00:00:01,
Cost to Root Bridge : 4,
Root Port : Slot 3 Interface 8,
Next Best Root Cost : 0,
Next Best Root Port : None,
Tx Hold Count : 6,
Topology Changes : 3,
Topology age : 0:4:37
Current Parameters (seconds)
Max Age = 30,
Forward Delay = 15,
Hello Time = 2
Parameters system uses when attempting to become root
System Max Age = 30,
System Forward Delay = 15,
System Hello Time = 2
bridge rrstp ring vlan-tag Displays VLAN Spanning Tree information, including parameter values
and topology change statistics.
show spantree ports Displays Spanning Tree information for switch ports, including parame-
ter values and the current port state.
For more information about the resulting displays from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide. An example of the output for the show spantree and show spantree ports
commands is also given in “Example Network Configuration Steps” on page 12-44.
The ITU-T G.8032/Y.1344 Ethernet Ring Protection (ERP) switching mechanism is a self-configuring
algorithm that maintains a loop-free topology while providing data path redundancy and network scalabil-
ity. ERP provides fast recovery times for Ethernet ring topologies by utilizing traditional Ethernet MAC
and bridge functions.
In This Chapter
This chapter provides an overview about how Ethernet Ring Protection (ERP) works and how to config-
ure its parameters through the Command Line Interface (CLI). CLI commands are used in the configura-
tion examples; for more details about the syntax of commands, see the OmniSwitch 6250/6350/6450 CLI
Reference Guide.
The following information and configuration procedures are included in this chapter include:
• “ERP Overview” on page 13-3.
• “Interaction With Other Features” on page 13-8.
• “ERP Configuration Overview and Guidelines” on page 13-11.
• “Configuring an ERP Ring” on page 13-12.
• “Sample Ethernet Ring Protection Configuration” on page 13-19.
• “Verifying the ERP Configuration” on page 13-21.
ERP Specifications
ITU-T G.8032/Y.1344 Ethernet Ring Protection
(Hold-off timer not supported)
(Non-revertive mode not supported)
ITU-T Y.1731/IEEE 802.1ag ERP packet compliant with OAM PDU format for CFM
Supported Platforms OmniSwitch 6250, 6350, 6450
Metro license required for OmniSwitch 6450 and
OmniSwitch 6250 Enterprise models.
Maximum number of rings per node 4
Maximum number of rings per ring port 1
Maximum number of nodes per ring 16 (recommended)
Maximum number of ERP protected 252 on switch operating in the 1x1 Spanning Tree mode.
VLANs per switch.
Range for ring ID 1 - 2147483647
Range for remote MEPID 1 - 8191
Range for wait-to-restore timer 1 - 12 minutes
Range for guard timer 1 - 200 centi-seconds
ERP Defaults
Parameter Description Command Default
ERP ring status erp-ring Disabled
RPL status for the node erp-ring rpl-node Disabled
The wait-to-restore timer value for erp-ring wait-to-restore 5 minutes
the RPL node
The guard-timer value for the ring erp-ring guard-timer 50 centi-seconds
node
ERP interaction with Ethernet OAM erp-ring ethoam-event remote- Events are dropped
(accept or drop loss of connectivity endpoint
events from remote endpoint).
The NNI-SVLAN association type. ethernet-service svlan nni STP
ERP Overview
Ethernet Ring Protection (ERP) is a protection switching mechanism for Ethernet ring topologies, such as
multi-ring and ladder networks. This implementation of ERP is based on Recommendation ITU-T G.8032/
Y.1344 and uses the ring Automatic Protection Switching (APS) protocol to coordinate the prevention of
network loops within a bridged Ethernet ring.
Loop prevention is achieved by allowing the traffic to flow on all but one of the links within the protected
Ethernet ring. This link is blocked and is referred to as the Ring Protection Link (RPL). When a ring fail-
ure condition occurs, the RPL is unblocked to allow the flow of traffic to continue through the ring.
One designated node within the ring serves as the RPL owner and is responsible for blocking the traffic
over the RPL. When a ring failure condition occurs, the RPL owner is responsible for unblocking the RPL
so that the link can forward traffic to maintain ring connectivity.
ERP Terms
Ring Protection Link (RPL)—A designated link between two ring nodes that is blocked to prevent a
loop on the ring.
RPL Owner—A node connected to an RPL. This node blocks traffic on the RPL during normal ring oper-
ations and activates the link to forward traffic when a failure condition occurs on another link in the ring.
Link Monitoring—Ring links are monitored using standard ETH CC OAM messages (CFM). Note that
for improved convergence times, this implementation also uses Ethernet link up and link down events.
Signal Fail (SF)—Signal fail is declared when a failed link or node is detected.
No Request (NR)—No Request is declared when there are no outstanding conditions (for example, SF) on
the node.
Ring APS (R-APS) Messages—Protocol messages defined in Y.1731 and G.8032 that determine the
status of the ring.
ERP Service VLAN—Ring-wide VLAN used exclusively for transmission of messages, including R-APS
messages.
ERP Protected VLAN—A VLAN that is added to the ERP ring. ERP determines the forwarding state of
protected VLANs.
ERP Timers
Wait To Restore (WTR) Timer. To prevent link flapping, this timer is used by the RPL to verify that the
ring has stabilized. This timer determines the number of minutes the RPL switch waits before returning the
RPL ports to a blocked state after the ring has recovered from a link failure.
Some important points about the WTR Timer are as follows:
• The timer is started when the RPL node receives an R-APS (NR) message that indicates ring protec-
tion is no longer required.
• The timer is stopped when the RPL owner receives an R-APS (SF) message while WTR is running,
which indicates that an error still exists in the ring.
• When the time runs out, the RPL port is blocked and an R-APS (NR, RB) message is transmitted from
both the ring ports to indicate that the RPL is blocked.
• Refer to the “ERP Specifications” on page 13-2 for timer defaults and valid ranges.
Guard Timer. When the failed link recovers, a ring node starts the Guard Timer. The Guard Timer is used
to prevent the ring nodes from receiving outdated R-APS messages that are no longer relevant.
Some important points about the Guard Timer are as follows:
• When the Guard Timer is running, any R-APS messages received are not forwarded.
• The Guard Timer value should be greater than the maximum expected forwarding delay time for which
it takes one R-APS message to circulate around the ring. This calculated value is required to prevent
any looping scenarios within the ring.
• Refer to the “ERP Specifications” on page 13-2 for timer defaults and valid ranges.
Normal Mode
If a link or node failure occurs in the ring shown in the above illustration, the ring transitions as follows
into the protection mode:
• Nodes adjacent to the failure detect and report the failure using the R-APS (SF) message.
• The R-APS (SF) message triggers the RPL owner to unblock the RPL.
• All nodes in the ring flush all the dynamic MAC addresses learned on their ring ports.
• The ring is now operating in the protection mode, as shown below:
Protection Mode
When the failed link shown in the above illustration recovers, the ring transitions as follows back to the
idle mode:
• Nodes adjacent to the recovered link initiate an R-APS (NR) message and start the Guard Timer.
• When the RPL owner receives the R-APS (NR) message, it starts the Wait-To-Restore timer (WTR),
which is the set period of time that must elapse before the RPL owner blocks the RPL.
• Once the WTR timer expires, the RPL owner blocks the RPL and transmits an R-APS (NR, RB)
message indicating that RPL is blocked (RB).
• On receiving the R-APS (NR, RB) message, ring nodes flush all the dynamic MAC addresses learned
on their ring ports and unblock any previously blocked ports.
• The ring is now operating in the idle mode. The RPL is blocked and all other ring links are operational.
In this example each of the ERP rings has a different Service VLAN configured which allows the ERP
PDUs to be processed by the corresponding ERP ring node. The protected VLANS can be shared across
ERP rings. The Service VLAN configured for ERP ring 1 is configured as a protected VLAN for ERP ring
2 and the Service VLAN for ERP ring 2 is configured as a protected VLAN for ERP ring 1.
• The two ERP rings must be configured with the same VLAN type; standard or VLAN stacking.
• Only a single node can be shared between the ERP rings; multiple shared nodes could result in a loop if
the rings that are configured on shared nodes have common protected VLANS.
• Traffic for a protected VLAN is not passed if the protected VLAN is deleted from either ERP ring or if
the shared node goes down.
Spanning Tree
ERP has the following interactions with Spanning Tree.
• Disabling Spanning Tree on the ring ports is required before changing the switch Spanning Tree oper-
ating mode from 1x1 to flat mode.
1X1 Mode
• 1X1 STP and ERP can co-exist on different ports on the same switch but not on the same VLAN-port
association (VPA). STP continues to operate as usual on non-ERP ring ports even for the ERP
Protected VLANs. On the ERP ring ports, the forwarding state is controlled by ERP.
• Maximum number of Protected VLANs supported is 252.
Flat Mode
• MSTP and ERP can co-exist on the same switch but are not supported on the same MSTI. ERP
Protected VLANs can not be part of the same MSTI as non-ERP Protected VLANs.
• RSTP and ERP can co-exist on a node only if STP is disabled on ERP ports, the default-VLAN of ERP
ports is disabled, and ERP protected VLANs are not configured on non-ERP ports. Also, non-ERP
Protected VLANs should not be configured on ERP ports.
• RRSTP and ERP cannot be configured on the same port.
VLAN Stacking
The VLAN Stacking application has the following interactions with ERP:
• ERP is supported on Network Network Interface (NNI) ports; it is not supported on UNI ports.
• Tunneling of STP BPDUs across ERP links is not supported. However, tunneling of STP BPDUs
across UNI ports is supported in a VLAN stacking configuration.
See “Configuring ERP with VLAN Stacking NNIs” on page 13-16 for more information.
Ethernet OAM
ERP ring ports can be configured to accept a loss of connectivity event for a Remote Ethernet OAM Main-
tenance End Point (MEP). See “Monitoring Remote Ethernet OAM End Points with ERP” on page 13-15
for more information.
2 Create ERP ring ID 1, ERP Service VLAN and MEG Level and associate two ports to the ring using
the erp-ring command.
-> erp-ring 1 port 1/1 port2 1/2 service-vlan 1001 level 5
3 Configure the RPL on one node using the erp-ring rpl-node command.
5 Enable the ERP ring configuration using the erp-ring enable command.
2 Create a VLAN Stacking service and associate the service with SVLAN 1001 using the ethernet-
service service-name command.
-> ethernet-service service-name CustomerA svlan 1001
3 Configure ports 1/1 and 1/2 as VLAN Stacking Network Network Interface (NNI) ports, associate the
ports with SVLAN 1001, and configure them for use with ERP using the ethernet-service svlan nni
command.
4 Create ERP ring ID 1 and associate the two NNI ports to the ring using the erp-ring command.
5 Configure the RPL on one node using the erp-ring rpl-node command.
6 Create additional SVLANs to add to the ring using the ethernet-service command.
7 Configure the SVLANs created in Step 6 as ERP protected VLANs using the erp-ring protected-vlan
command.
-> erp-ring 1 protected-vlan 1002-1005
Note that when two VLAN Stacking NNI ports are associated with the same SVLAN and both those ports
serve as the ring ports for the node, the SVLAN is automatically added to the list of protected SVLANs for
the ERP ring. For example, the following commands designate SVLAN 1002 as a protected VLAN:
8 Enable the ERP ring configuration using the erp-ring enable command.
1 Configure the basic components of an ERP ring (ring ports, service VLAN, and MEG level). See
“Configuring an ERP Ring” on page 13-12.
2 Tag VLANs for ring protection. See “Adding Protected VLANs” on page 13-13.
3 Configure an RPL port. When a ring port is configured as an RPL port, the node to which the port
belongs becomes the RPL owner. The RPL owner is responsible for blocking and unblocking the RPL.
See “Configuring an RPL Port” on page 13-13.
4 Change the Wait-To-Restore timer value. This timer value determines how long the RPL owner waits
before restoring the RPL to a forwarding state. See “Setting the Wait-to-Restore Timer” on page 13-14.
5 Change the Guard timer value. This timer value determines an amount of time during which ring nodes
ignore R-APS messages. See “Setting the Guard Timer” on page 13-14.
6 Configure the ring port to receive the loss of connectivity event for a Remote Ethernet OAM endpoint.
See “Monitoring Remote Ethernet OAM End Points with ERP” on page 13-15.
7 Configure a VLAN Stacking NNI-to-SVLAN association for ERP control. This is done to include an
SVLAN in a ring configuration. See “Configuring ERP with VLAN Stacking NNIs” on page 13-16.
8 Clear ERP statistics. Commands to clear ERP statistics for a single ring or multiple rings are described
in “Clearing ERP Statistics” on page 13-18.
Configuration Guidelines
Use the following guidelines when configuring ERP for the switch:
• Physical switch ports and logical link aggregate ports can be configured as ERP ring ports. This also
includes VLAN Stacking Network Network Interface (NNI) ports.
• ERP is not supported on mobile ports, mirroring ports, link aggregate member ports, high availability
ports, multicast VLAN receiver ports (ERP is supported on Multicast VLAN sender ports only), VLAN
Stacking User Network Interface (UNI) ports, or RRSTP ring ports.
• An ERP ring port can belong to only one ERP ring at a time.
• When configuring a ring for a switch that is operating in the flat Spanning Tree mode using STP or
RSTP (not MSTP), administratively disable the default VLAN for the ring port. In this case, if the
switch is using RSTP, disabling Spanning Tree on the ring port is also required.
• When configuring a ring for a switch that is operating in the flat Spanning Tree mode using MSTP,
make sure the standard VLAN to which the ring port is assigned is not a member of an MSTI that is
also associated with ERP protected VLANs.
• The specified service VLAN ID must not participate in a Spanning Tree instance that is associated with
non-ERP VLANs. This may require changing the Spanning Tree configuration for the VLAN ID prior
to using this command.
• If the ERP switch participates in an Ethernet OAM MaintenanceDomain(MD), configure the Manage-
ment Entity Group (MEG) level of the ERP service VLAN with the number that is used for the Ether-
net OAM MD.
• The Service VLAN can belong to only one ERP ring at a time and must be a static VLAN. Note that
the service VLAN is also a protected VLAN.
1 Determine which two ports on the switch become the ring ports. For example, ports 1/2 and 3/1.
2 Administratively disable the VLAN that serves as the default VLAN for the ring ports if the switch is
operating in the flat Spanning Tree mode without MSTP. For example, if VLAN 10 is the default VLAN
for ports 1/2 and 3/1, before configuring 1/2 and 3/1 as a ring ports, disable VLAN 10.
-> vlan 10 disable
3 Disable Spanning Tree on the ports that becomes the ring ports if the switch is operating in the flat
Spanning Tree mode and using RSTP. For example, disable the Spanning Tree for the VLAN 10 port 1/2
instance and VLAN 10 port 3/1 instance:
4 Determine which VLAN on the switch becomes the ERP service VLAN for the ring. If the VLAN does
not exist, create the VLAN. For example:
-> vlan 500
5 Determine the APS Management Entity Group (MEG) level number to assign to the service VLAN. If
the ERP switch participates in an Ethernet OAM MaintenanceDomain(MD), configure the MEG level
with the same number used for the Ethernet OAM MD.
6 Create the ERP ring configuration on each switch using the erp-ring command. For example the
following command configures an ERP ring with ring ID 1 on ports 1/2 and 3/1 along with service VLAN
1001 and MEG level 2.
To configure link aggregate logical ports as ring ports, use the erp-ring command with the linkagg param-
eter. For example:
7 Repeat Steps 1 through 6 for each switch that participates in the ERP ring. Make sure to use the same
VLAN ID and MEG level for the service VLAN on each switch.
Use the show erp command to verify the ERP ring configuration. For more information about this
command, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Note. Administratively disable ring ports before deleting the ring to avoid creating any network loops.
Once a ring is deleted, then administratively enable the ports under Spanning Tree protocol.
To delete a protected VLAN or group of VLANs from the ring, use the no form of the erp-ring
protected-vlan command. For example:
Use the show erp protected-vlan command to view the protected VLANs. For more information about
this command, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Note. RPL node can be configured only when the ring is disabled; RPL configuration applied to the ring
while it is enabled is rejected.
To remove the RPL node configuration for the specified ring, use the no form of the erp-ring rpl-node
command. For example:
-> no erp-ring 1 rpl-node
To verify the RPL node configuration for the switch, use the show erp command. For more information
about this command, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
The above command is only used on a switch that serves as the RPL node for the ERP ring. The specified
ERP ring ID must already exist in the switch configuration.
To restore the timer back to the default setting, use the no form of the erp-ring wait-to-restore command.
For example:
-> no erp-ring 1 wait-to-restore
To verify the WTR configuration, use the show erp command. For more information about this command,
see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
To restore the Guard Timer back to the default value, use the no form of the erp-ring guard-timer
command. For example:
-> no erp-ring 1 guard-timer
To verify the configured Guard Timer, use the show erp command. For more information about this
command, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
The above command configures ring port 1/1 on ERP ring 1 to accept loss of connectivity events from
remote endpoint 10.
The erp-ring ethoam-event remote-endpoint command is also used to configure a link aggregate logical
port to accept or drop loss of connectivity events. For example:
-> erp-ring 1 ethoam-event linkagg 1 remote-endpoint 20
To configure the ERP ring port to drop loss of connectivity events, use the no form of the erp-ring
ethoam-event remote-endpoint command. For example:
-> no erp-ring 1 ethoam-event port 1/1
To verify the Ethernet OAM event configuration for a specific ring port, use the show erp command with
the port parameter. For example:
Ring-Id : 1
Ring Port Status : forwarding,
Ring Port Type : non-rpl,
Ethoam Event : disabled
For more information about these commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
The above commands configure ports 1/1 and 1/2 as NNI ports for SVLAN 1001 with ERP control over
the VPA. Note that the SVLAN specified must already exist in the switch configuration.
To configure an ERP ring with NNI-SVLAN associations, use the erp-ring command but specify an
SVLAN ID for the service VLAN and the associated NNI ports as the ring ports. For example:
Note the following when configuring an ERP ring with VLAN Stacking NNI-SVLAN associations:
• Only two ERP type NNI associations are allowed per SVLAN.
• Configuring an ERP ring on 8021q tagged port associations with SVLANs is not allowed.
• Configuring an ERP Ring on an STP type NNI association with an SVLAN is not allowed.
• Configuring an IMPVLAN as an ERP service VLAN is not allowed.
• If an SVLAN that is not associated with any NNI ports is configured as the service VLAN for an ERP
ring, the NNI ring ports are automatically associated with that SVLAN at the time the ring is created.
• SVLAN User Network Interface (UNI) associations are not eligible for ERP ring protection.
• If the ERP type NNI ports are connected to the STP path via UNI ports, then STP BPDUs can be
tunneled with the help of VLAN-stacking mechanism.
• Deleting an ERP service VLAN and it’s associated NNI ports is only allowed when the ERP ring itself
is deleted using the no for of the erp-ring command. None of the VLAN Stacking CLI commands can
remove a service VLAN consisting of an NNI-SVLAN association.
The following sequence of configuration commands provides an example of configuring an ERP ring
consisting of VLAN Stacking NNI ports and SVLANs:
2 Port 1/3 is associated with SVLAN 100, but no erp parameter is used. As a result, port 1/3 is an STP
type NNI association by default.
3 Ports 1/1 and 1/2 are associated with VLAN 100 using the erp parameter. These ports are now ERP
type NNI associations.
4 The ERP ring is created specifying NNI ports 1/1 and 1/2 as the ring ports, SVLAN 200 as the service
VLAN, and an MEG level of 3.
5 When ERP ring 10 is created, ERP type NNI associations are automatically configured between the
ring ports and SVLAN 200. Note that prior to creating this ring, SVLAN 200 had no configured NNI asso-
ciations.
To clear ERP statistics for a specific ring in the switch, use the clear erp statistics command with the ring
parameter to specify a ring ID. For example:
-> clear erp statistics ring 5
To clear ERP statistics for a specific ring port, use the clear erp statistics command with the ring and
port parameters. For example:
-> clear erp statistics ring 5 port 1/2
To clear ERP statistics for a specific link aggregate ring port, use clear erp statistics command with the
ring and linkagg parameters. For example:
-> clear erp statistics ring 5 linkagg 2
Use the show erp statistics command to verify ERP statistics. For more information about this command,
see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
RI
2/1 Fa NG
Fa ] 1/2 Pr
17 ot
6.1. [17
2.1 ec
.1 tio
72 6.1
nL
[1 .14
] IN
K
NK (R
LI PL
NG )
RI [17
2.1
6.1 Fa
.13 2/1
8] RPL ]
2/2 6.1.1 Switch C
a Port
Switch E F 2.1
7
[1
Fa
1/2
]
[17
.10
1/2
Fa
2.1
6.1
RPL Owner
6.1
2.1
.21
[17
RIN ]
INK
GL
GL
INK
RIN
[17
.9]
2.1
6.1
2/2
Fa
6.1
2.1
Fa
RING LINK
2/1
.22
[17
]
Fa 2/2 Fa 1/1
[172.16.1.5] [172.16.1.6]
Switch A Switch B
Configuring the sample ERP ring network shown in the above diagram involves the following tasks:
1 Configure an ERP ring with ERP ring ID 1 on all switches in the network.
3 Set the Management Entity Group (MEG) level to 2 for all switches.
4 Switch C is the RPL owner; configure the port connected to the Ring Protection Link as a RPL port.
7 Use the default settings for the guard timer and WTR timer values. These values can be adjusted as
necessary.
2 Configure Switch C as the RPL owner for the ring using the following commands to designate port 2/1
as the RPL port:
3 Verify the ERP ring configuration on any switch using the following command:
Ring Id : 1,
Ring Port1 : 2/1,
Ring Port2 : 1/2,
Ring Status : enabled,
Service VLAN : 10,
WTR Timer (min) : 5,
Guard Timer (centi-sec) : 50,
MEG Level : 2,
Ring State : idle,
Ring Node Type : rpl,
RPL Port : 2/1,
Last State Change : SUN DEC 25 06:50:17 2016 (sysUpTime 00h:01m:31s)
The above output example shows that ERP ring 1 is created on ring ports 2/1 and 1/2 with service VLAN
10, WTR timer of 5 mins, Guard timer of 50 centi-seconds, MEG level 2, and port 2/1 is the RPL port.
4 Verify that VLANs 11 through 20 are protected VLANs for ERP ring 1 using the following command:
5 Verify the status of an ERP ring port on any switch using the following command:
Ring-Id : 1
Ring Port Status : forwarding,
Ring Port Type : non-rpl,
Ethoam Event : disabled
The above command shows the forwarding status of the port, the type of ring port (RPL or non-RPL), and
ETHOAM event status.
show erp Displays the ERP configuration information for all rings, a specific ring,
or for a specific ring port.
show erp protected-vlan Displays the protected VLAN configuration for all ERP rings or for a
specific ring.
show erp statistics Displays the ERP statistics for all rings, a specific ring, or a specific ring
port.
show ethernet-service Displays configuration information for VLAN Stacking Ethernet ser-
vices, which includes SVLANs and NNI port associations.
show ethernet-service nni Displays the VLAN Stacking NNI configuration.
show ethernet-service vlan Displays a list of SVLANs configured fro the switch.
For more information about the displays that result from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
Loopback Detection (LBD) automatically detects and prevents forwarding loops on ports and Link Aggre-
gations (LAGs) that have forwarded network traffic which has looped back to the originating switch. LBD
detects and prevents Layer 2 forwarding loops on a port either in the absence of other loop detection
mechanisms such as STP/RSTP/MSTP, or when these mechanisms cannot detect it (for example, a client's
equipment may drop BPDUs, or the STP protocol may be restricted to the network edge).
In This Chapter
This chapter describes the LBD feature and how to configure it through the Command Line Interface
(CLI). CLI commands are used in the configuration examples; for more details about the syntax of
commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide. This chapter provides an overview
of LBD and includes the following information:
• “LBD Specifications” on page 14-2
• “Quick Steps for Configuring LBD” on page 14-3
• “LBD Overview” on page 14-4
• “Configuring LBD” on page 14-5
• “Verifying the LBD Configuration” on page 14-6
LBD Specifications
RFCs supported NA
IEEE Standards Supported NA
Platforms Supported OmniSwitch 6250, 6450
Ports Supported There is no restriction on type of ports on which the LBD can be
enabled. But it is recommended LBD has to be enabled on the edge
ports.
Transmission Timer The valid range is from 5 to 600 seconds.
Autorecovery Timer The valid range is from 30 to 86400 seconds.
LBD Defaults
The following table shows LBD default values.
2 To enable the LBD protocol on a port, use the loopback-detection port command by entering LBD
port, followed by the slot and port number, and enable. For example:
-> loopback-detection port 1/1 enable
Note. Optional. Verify the LBD global configuration by entering the show loopback-detection configura-
tion command or verify the LBD configuration on a port by entering the show loopback-detection port
command. For example:
-> show loopback-detection
To verify the LBD statistics of a port, use the show loopback-detection statistics port command. For
example:
LBD Overview
Loopback Detection (LBD) automatically detects and prevents L2 forwarding loops on a port. LBD oper-
ates in addition to STP which detects forwarding loops. When a loopback is detected, the port is disabled
and goes into a shutdown state. Once a loop is discovered, the port from where the loops originated is
placed into shutdown state. A trap is sent and the event is logged. Network managers can define a Recov-
ery Interval which automatically places the port into an normal state, after the defined time period.
When enabling and configuring Loopback Detection:
• Enable Loopback Detection globally on the switch.
• Enable Loopback Detection on edge port.
The switch periodically sends out LBD frame from loopback detection enabled port and concludes that the
port is looped back if it receives the frame on any of the loop-back detection enabled ports.
Transmission Timer
Transmission timer is the time duration in seconds at which the port sends LBD frame on the link. When
any of the port is getting blocked due to loopback detection, there is no further transmission and receiving
of any traffic on the blocked port. The port goes to shutdown state.
Autorecovery
When the ports are shutdown due to LBD, the auto recovery mechanism moves the ports to a normal state
after a specific time period. Autorecovery is available on all the ports that have been disabled due to loop-
back detection and also be configured on the switch by using CLI command. The autorecovery time period
can be configured globally on the switch.
Link Aggregation
When loopback is detected on any one of the Linkagg port, all the ports of the linkagg is shutdown due to
loopback detection.
Configuring LBD
This section describes how to use Alcatel-Lucent’s Command Line Interface (CLI) commands to config-
ure LBD on a switch.
• Enable LBD on a switch or port (see “Enabling LBD” on page 14-5)
• Configure the LBD transmission timer (see “Configuring the LBD Transmission Timer” on page 14-5)
• Configure the autorecovery timer (see “Configuring the Autorecovery Timer” on page 14-5)
• View the LBD statistics on a port (see “Viewing LBD Statistics” on page 14-5)
• Recover a port from LBD shutdown (see “Recovering a Port from LBD Shutdown” on page 14-6)
Enabling LBD
By default, LBD is disabled on the switch. To enable LBD on a switch, use the loopback-detection
command. For example, the following command enables LBD on a switch:
-> loopback-detection enable
show loopback-detection Displays the global LBD configuration information for the switch.
show loopback-detection port Displays LBD configuration information for all ports on the switch.
show loopback-detection statistics Displays LBD statistics information for a specific port on the switch.
port
Note. For more information about the resulting display from these commands, see the OmniSwitch 6250/
6350/6450 CLI Reference Guide.
The Customer Provider Edge (CPE) Test Head traffic generator and analyzer is a Test-OAM (Operation,
Administration and Maintenance) tool used in the Metro Ethernet Network to validate the customer
Service Level Agreements (SLA). This functionality allows the operator to validate the Metro Ethernet
Network between customer end points, which is critical when provisioning or troubleshooting network
services.
This implementation of CPE Test Head supports Unidirectional and Bidirectional, ingress tests. Traffic is
generated at the UNI port as if the traffic was generated from a test head connected to the UNI port.This
validates the actual customer SLA by subjecting the test traffic to the ingress QoS defined at the UNI port
(Ethernet SAP profile or QoS policy rules for priority and bandwidth control) and the egress QoS defined
at the egress NNI port and carrier network.
In unidirectional test, the test traffic is unidirectional. The traffic analysis is performed by the analyzer
switch.
In bidirectional test, the test traffic is bidirectional. The traffic analysis is performed by the generator
switch. The test traffic is sent to the generator switch using the hardware loopback function on the
analyzer switch (Loopback switch).
The feature provides single-stream and multi-stream test capability.
The CPE Test Group (multi-stream) feature is supported on non-metro switches with metro license. The
feature supports a stack containing up to 8 switches with a maximum of 8 test streams added to a test
group.
The CPE test is non-disruptive to traffic running on other UNI ports that are associated with the same SAP
profile as the test UNI port. All UNI ports, including CPE test ports, are subject to any SAP profile or QoS
configuration associated with the port. This is important to consider when analyzing test results.
In This Chapter
This chapter describes the CPE Test Head feature, CPE Test Group feature, and how to configure it
through the Command Line Interface (CLI). CLI commands are used in the configuration examples; for
more details about the syntax of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
This includes the following information:
• “CPE Test Head Specifications” on page 15-2
• “Quick Steps for Configuring CPE Test Head” on page 15-3
• “CPE Test Head Overview” on page 15-5
• “CPE Test Head Configuration Overview” on page 15-6
• “Configuring a CPE Test Profile” on page 15-7
• “Configuring the L2 SAA Test” on page 15-9
• “Running a CPE Test” on page 15-10
• “Verifying the CPE Test Configuration and Results” on page 15-11
• “Configuring CPE Test Group” on page 15-13
• “CPE Test Head Advanced Configuration” on page 15-25
• “Sample Test Configurations” on page 15-27
2 Configure the source and destination end point for the test, use the test-oam src-endpoint dst-
endpoint command. For example:
-> test-oam Test1 src-endpoint SW1
3 Configure the source MAC address, destination MAC address and the SVLAN for the test frame using
the test-oam vlan test-frame command. For example:
-> test-oam Test1 vlan 100 test-frame src-mac 00:00:00:00:00:01 dst-mac
00:00:00:00:00:02
4 Configure the test direction using the test-oam direction command. For example:
5 Configure the type of role the switch will perform using the test-oam role command. For example:
6 Configure the test port on the switch using the test-oam port command. For example:
7 Configure the test packet parameters using the test-oam frame command. For example:
To configure a Layer 3 test frame, specify ipv4 as the Ether type value.
-> test-oam Test1 frame vlan-tag 1 priority 2 drop-eligible false ether-type
ipv4 src-ip 1.1.1.1 dst-ip 2.2.2.2 ttl 4 tos 0x01 protocol udp src-port 2000
dst-port 3000 data-pattern 0x0010
8 Configure the test duration, rate and packet-size using the test-oam duration rate packet-size
command. For example:
-> test-oam Test1 duration 10 rate 8kbps packet-size 64
For bidirectional test use the fetch-remote-stats parameter with the test-oam start stop command. For
example:
-> test-oam Test1 start fetch-remote-stats
When the test runs the amount of time specified for the test duration, the test automatically stops.
2 To stop an active test from running, use the stop form of the test-oam start stop command.
For example:
-> test-oam Test1 stop
Note. Verify the test configuration and status with the show test-oam command. For example:
-> show test-oam tests
Total Test-Ids: 1
Test-Id Port Src-Mac Dst-Mac Vlan Direction Status Remote-Sys-Mac
-------+-----+-----------------+-----------------+-----+---------------+-----------+-----------------------
Test1 none 00:00:00:00:00:00 00:00:00:00:00:00 none unidirectional not-started 00:00:00:00:00:00
To verify test results, use the show test-oam statistics command. For example:
-> show test-oam Test1 statistics
Test-Id TX-Ingress TX-Egress RX-Ingress Remote-Stats Throughput(Mbs)
--------+------------+------------+---------------+----------------+--------------
Test1 19017 19017 19017 19017 9.98
To clear test statistics, use the clear test-oam statistics command. For example:
-> clear test-oam Test1 statistics
This clears all the statistics related to “Test1”.
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for more information about these commands.
• Generate specific flow-based traffic across the customer’s Ethernet Virtual Circuit (EVC) to help iden-
tify flow-based issues.
• Identify the impact of QoS settings (SAP profile or QoS policies) on the overall traffic.
• Confirm throughput across the provider network.
• Debug flow-specific traffic forwarding across the provider network.
• Analyze the behavior of various user-defined traffic patterns across the provider network.
• Perform the handover testing after initial deployment.
• Perform on-demand testing and results monitoring using a central entity.
The OmniSwitch implementation of CPE Test Head supports the ability to run unidirectional, ingress
tests.Test setup involves configuring one CPE switch as the generator and a remote switch as the analyzer/
loopback.
The following diagram shows an example of an OmniSwitch CPE Test Head configuration:
Carrier Network
Customer CPE Customer CPE
Generator Analyzer/Loopback
Customer Domain - One Way
100K 100K
packets counted packets counted
sent on egress NNI received on ingress NNI
100K
packets generated,
counted on ingress UNI
CPE Test Head Example - Unidirectional, Ingress Test
In this example:
1 The CPE test is started first on the analyzer/loopback switch and then on the generator switch. The
analyzer/loopback switch sends packets to the generator switch to learn the source.
2 A configurable amount of traffic is generated and counted on the ingress UNI port of the generator
switch, as if the traffic was generated from a test head connected to the UNI port. This subjects the test
traffic to the ingress UNI SAP profile policies.
3 Traffic is counted and sent out on the SAP NNI port. This subjects the test frames to the egress NNI
QoS policies.
4 Test frames are forwarded through the provider network over the customer EVC to the ingress NNI on
the analyzer switch, where the packets are received and counted. Note that test frames are dropped after
they are counted.
5 CPE Test Head CLI show commands are used on the generator and analyzer switches to display and
verify test statistics, such as packets transmitted and received.
Note. The CPE test is non-disruptive to traffic running on other UNI ports that are associated with the
same SAP profile as the test UNI port. All UNI and NNI ports, including CPE test ports, are subject to any
SAP profile or QoS configuration associated with the SAP profile. This is important to consider when
analyzing test results.
Analyzer/
Generator
Test Profile Parameters Loopback CLI Command
Switch
Switch
Profile name Yes Yes test-oam
Source and destination endpoints Yes Yes test-oam src-endpoint dst-endpoint
Test frame source and destination Yes Yes test-oam vlan test-frame
MAC addresses
Service VLAN Yes Yes test-oam vlan test-frame
Test role (generator or analyzer or Yes Yes test-oam role
loopback)
UNI port for test packet generation Yes No test-oam port
Test frame parameters, such as Yes No test-oam frame
VLAN tag, priority, and frame type
Test duration, rate, and packet size Yes No test-oam duration rate packet-size
Remote Sys MAC Yes No test-oam remote-sys-mac
Configuration Guidelines
Consider the following guidelines when configuring the OmniSwitch CPE Test Head:
• Make sure the same test profile name (test ID) is used on the generator and analyzer/loopback switch.
• A switch can only perform one role (generator or analyzer or loopback) for a specific test.
• Only one test can be active for the switch at any given time.
• Up to 32 test profiles are allowed per switch.
• Regular traffic is disrupted on the ingress UNI port that is used to generate the test traffic. However,
traffic on other UNI ports associated with the same SAP profile is not disrupted. Therefore, running the
test on a UNI port that is not in use is recommended.
• For bidirectional test the role of the destination switch must be configured as loopback.
• Multicast and broadcast address must not be configured for bidirectional test.
• For the bidirectional test it is mandatory to configure the remote sys MAC address and activate the
remote-fetch-stats option while starting the test.
Provider Network
1 Configure the test profile name and an optional description on the generator (CPE-1 switch) and
analyzer (CPE-2 switch) using the test-oam command. For example:
-> test-oam 100M_L2 descr “60 sec 100MB L2 test”
When the “100M_L2” test is created, a profile associated with this name is automatically created. This
initial profile contains default parameter settings, where applicable. However, in some cases the default
values are set to zero as a placeholder, but these parameters require additional configuration.
2 Configure the source (generator) and destination (analyzer) endpoints on CPE-1 and CPE-2 using the
test-oam src-endpoint dst-endpoint command. For example:
-> test-oam 100M_L2 src-endpoint "CPE-1" dst-endpoint "CPE-2"
The endpoint is identified using the DNS host name for the switch. In this example, “CPE-1” and
“CPE-2” are the configured host names for the generator and analyze switch.
3 Configure the service VLAN and the source and destination MAC for the test frame on CPE-1 and
CPE-2 using the test-oam vlan test-frame command. For example:
-> test-oam 100M_L2 vlan 100 test-frame src-mac 00:00:00:11:11:11 dst-mac
00:00:00:22:22:22
4 Configure CPE-1 as the generator switch using the test-oam role command. For example:
Use this command with the generator option on the CPE-1 switch. This will configure the role param-
eter in the “100M_L2” test profile that resides on CPE-1.
5 Configure CPE-2 as the analyzer switch using the test-oam role command. For example:
Use this command with the analyzer option on the CPE-2 switch. This will configure the role parame-
ter in the “100M_L2” test profile that resides on CPE-2.
Note that a switch can only serve as the generator or the analyzer for any given test.
6 Configure port 1/4 on CPE-1 as the port on which the test is run, using the test-oam port command.
For example:
-> test-oam 100M_L2 port 1/4
This is the ingress UNI port that will generate test packets. The packets are then subject to the SAP
profile and QoS policies that are associated with the port.
7 Configure the test duration, rate, and size of the test packet on CPE-1 using the test-oam duration rate
packet-size command. For example:
-> test-oam 100M_L2 duration 100 rate 100m packet-size 1518
The test duration is the length of time, in seconds, that the test will run. The rate determines the rate at
which packets are generated, in bps or Mbps. The packet size specifies the size of the test packet that is
generated.
8 Configure a Layer 2 or Layer 3 test frame on CPE-1 using the test-oam frame command. The type of
test needed determines the type of frame that is configured for the test. If a Layer 2 test is required, config-
ure a Layer 2 frame type; if a Layer 3 test is required, configure a Layer 2 frame type. For example:
To configure a Layer 2 test frame, specify a hexadecimal value for the Ether type.
-> test-oam 100M_L2 frame vlan-tag 20 priority 5 ether-type 0x8101 data-pattern
0xabcd
To configure a Layer 3 test frame, specify the ipv4 keyword for the Ether type.
-> test-oam 100M_IP frame vlan-tag 10 priority 5 ether-type ipv4 src-ip
10.10.10.111 dst-ip 10.10.10.222
See the test-oam frame command page in the OmniSwitch 6250/6350/6450 CLI Reference Guide for
frame type parameter requirements and definitions.
The following provides a summary of the CLI commands used in the configuration example:
Refer to the OmniSwitch 6250/6350/6450 CLI Reference Guide for more information about these
commands.
Note. The CPE test-oam string must be configured before using it in the L2-SAA test. The L2-SAA test
derives the source MAC address, destination MAC address, and the VLAN ID from the test-oam configu-
ration of the individual test frames.
To run the L2-SAA test continuously until the test-oam session ends, use the continuous parameter. For
example:
-> test-oam test1 l2-saa continuous priority 5 interval 1000 size 100 drop-
eligible false
On receiving the SAA reply for every frame, the minimum RTT, maximum RTT, total RTT, minimum
Jitter, maximum Jitter, total Jitter and number of packets received will be calculated and stored in a global
buffer to analyze the network performance between the devices.
Use the show test-oam command to view the L2-SAA configuration details.
This command also includes the following optional parameters used to specify runtime (active) values for
the specified test:
• vlan—the service VLAN to use for the test.
• port—the port on which the test will generate test frames.
• packet-size—the size of the test frame to transmit.
• fetch-remote-stats—Triggers the test at the remote device from the generator. The statistics are
collected during the test and the test is stopped after receiving the test results. The fetch-remote-stats
parameter must be used while starting a bidirectional test.
When one or more of these runtime parameters are specified with the test-oam start command, the param-
eter value is used instead of the value configured for the same parameter in the CPE test profile. For exam-
ple, if the “100M_L2” profile specifies port 1/10 for the test, the following command will run the
“100M_L2” test on port 1/4:
-> test-oam 100M_L2 port 1/4 start
In case the test is a bidirectional test, the fetch-remote-stats parameter must be used. For example:
-> test-oam "test2" port 1/2 start fetch-remote-stats
Note. The runtime values specified for any of the optional test-oam start command parameters do not
overwrite the configured values for the test profile. In addition, if there are no configured values for these
parameters in the profile and a runtime value is not specified with the command, the test will not run.
Stopping the CPE test on both the generator and analyzer is recommended. The analyzer switch may
continue to send out packets attempting to learn the test source if the test is not stopped on the analyzer
switch as well.
The show test-oam command displays a summary of CPE test information or more detailed information
for a specific test. For example:
-> show test-oam tests
Legend: Port: * = Inactive port
Total Test-Ids: 1
Test-Id Port Src-Mac Dst-Mac Vlan Direction Status Remote-Sys-Mac
-------+----+-----------------+-----------------+-----+---------------+-----------+----------------
test1 1/5 00:11:22:12:44:55 00:22:33:12:44:55 1001 bidirectional running
Frame Configuration :
Frame Type : ipv6,
Vlan : 200,
Priority : 7,
Pattern : 0x0001,
Dei : true,
Source Ip : 00:00:00:00:10.20.30.50,
Destination Ip : 00:00:00:00:10.30.40.60,
Source Port : 10,
Destination Port : 20,
Next Header : tcp,
Hop-Count : 50,
Traffic-Class : 0xff
Flow-Label : 0x0
L2-SAA Configuration :
L2-SAA Count : 7
L2-SAA Interval : 1000
L2-SAA DE : TRUE
The show test-oam statistics command displays packet counts for the number of test
packets transmitted and received. For example:
-> show test-oam statistics
Test-Id TX-Ingress TX-Egress RX-Ingress Remote-Stats Throughput(Mbps)
--------------+------------+------------+------------+------------+-----------
Test1 1200366 1200366 0 1200366 8
Test2 0 0 1200366 1200366 8
Test3 95553 95553 95553 95553 7.33
The packet counts displayed are based on the role the switch plays for the specific test. For example,
“Test1” shows statistics for TX-Ingress (packets transmitted on ingress UNI) and TX-Egress (packets
transmitted on egress NNI), but not for RX-Ingress (packets received on ingress NNI). This is because the
show command was performed on the generator switch for “Test1”. The “Test2” display output only for
shows statistics for RX-Ingress because the switch is the analyzer for “Test2”. The “Test3”displays the
statistics for remote test, the number of test frames received by the analyzer/loopback and fetched by the
generator device. TX-Ingress, TX-Egress, RX-Ingress, Remote-Stats, and Throughput (Mbps). Through-
put (Mbps), displays the traffic throughput of the test.
To verify the received test packet count for “Test1”, use the show test-oam statistics command on the
analyzer switch. To verify the transmitted test packet count for “Test2”, use the same show command on
the generator switch.
Note. For more information about the resulting display from these commands, see the OmniSwitch 6250/
6350/6450 CLI Reference Guide.
2 Configure the name for the CPE test group, use the test-oam group command. For example:
3 Configure the list of tests that need to be added in the CPE test group, use the test-oam group tests
command. For example:
-> test-oam group Testgroup1 tests test1 test2 test3 test4 test5 test6 test7
test8
4 Configure the source and destination end point for the CPE test group, use the test-oam group src-
endpoint dst-endpoint command. For example:
-> test-oam group Testgroup1 src-endpoint SW1
5 Configure the test direction using the test-oam group direction command. For example:
6 Configure the required role for the switch using the test-oam group role command. For example:
Note. For bidirectional test the role of the destination switch must be configured as loopback.
Direction cannot be set Bidirectional when role is Analyzer and vice-versa.
7 Configure the CPE test group port on the generator switch using the test-oam group port command.
For example:
-> test-oam group Testgroup1 port 1/2
8 Configure the CPE test group duration and rate using the test-oam group duration rate command. For
example:
-> test-oam group Testgroup1 duration 10 rate 8 kbps
9 Configure the remote sys mac for the CPE group using the test-oam group remote-sys-mac
command. This configuration is mandatory in case of bidirectional test. For example:
-> test-oam group "Testgroup1" remote-sys-mac E8:E7:32:32:A6:EE
When the test runs for the amount of time specified in the test duration, the test automatically stops.
In case the test is a bidirectional test, the fetch-remote-stats parameter must be used. For example:
-> test-oam group Testgroup1 port 1/2 start fetch-remote-stats
2 To stop an active test from running, use the test-oam group stop command.
For example:
-> test-oam group Testgroup1 stop
Note. Verify the CPE test group configuration and status with the show test-oam group command. For
example:
-> show test-oam group tests
Total Test-Groups: 2
Feeder Port : none
Test-Group Port Duration Rate Nb of Direction Status Remote-Sys-Mac
(secs) Flows
----------+-----+----------+---------+-----+---------------+------------+---------------------
Testgroup1 none 5 - 2 unidirectional not-started 00:00:00:00:00:00
Testgroup2 none 5 - 3 unidirectional not-started 00:00:00:00:00:00
To verify test results, use the show test-oam group statistics command. For example:
-> show test-oam group statistics
Test-Group Flow TX-Ingress TX-Egress RX-Ingress Remote-Stats Throughput(Mbps)
----------+------+------------+------------+-------------+-------------+----------------
Testgroup1 test1 309911 309911 309911 309911 4.13
Testgroup1 test2 309730 309730 309730 309730 4.13
To clear test statistics, use the clear test-oam group statistics command. For example:
-> clear test-oam group Testgroup1 statistics
This clears all the statistics related to “Testgroup1”.
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for more information about these commands.
• Generate specific flow-based traffic across the customer’s Ethernet Virtual Circuit (EVC) to help
identify flow-based issues.
• Identify the impact of QoS settings (SAP profile or QoS policies) on the overall traffic.
• Confirm throughput across the provider network.
• Debug flow-specific traffic forwarding across the provider network.
• Analyze the behavior of various user-defined traffic patterns across the provider network.
• Perform the handover testing after initial deployment.
• Perform on-demand testing and results monitoring using a central entity.
The OmniSwitch implementation of CPE Test group supports the ability to run unidirectional and bidirec-
tional, ingress tests. Test setup involves configuring one CPE switch as the generator and a remote switch
as the analyzer/loopback.
The following diagram shows an example of an OmniSwitch CPE Test Group configuration:
In this example:
1 A feeder port must be configured in the system to feed the traffic to the generator. The feeder port is
required while running a CPE test group.
2 The CPE test group is started first on the analyzer switch and then on the generator switch. The
analyzer switch sends packets to the generator switch to learn the source.
3 A configurable amount of traffic is generated and counted on the ingress UNI port of the generator
switch, as if the traffic was generated from a test head connected to the UNI port. This subjects the test
traffic to the ingress UNI SAP profile policies.
4 Traffic is counted and sent out on the SAP NNI port. This subjects the test frames to the egress NNI
QoS policies.
5 Test frames are forwarded through the provider network over the customer EVC to the ingress NNI on
the analyzer switch, where the packets are received and counted. Note that test frames are dropped after
they are counted.
6 CPE Test group CLI show commands are used on the generator and analyzer switches to display and
verify CPE test group statistics, such as packets transmitted and received.
Note. The CPE test is non-disruptive to traffic running on other UNI ports that are associated with the
same SAP profile as the test UNI port. All UNI and NNI ports, including CPE test ports, are subject to any
SAP profile or QoS configuration associated with the SAP profile. This is important to consider when
analyzing test results.
Analyzer/
Generator
CPE Test group Parameters Loopback CLI Command
Switch
Switch
Profile name Yes Yes test-oam group
Source and destination endpoints Yes Yes test-oam group src-endpoint dst-
endpoint
Test-oam role (generator or analyzer Yes Yes test-oam group role
or loopback)
UNI port for test packet generation Yes No test-oam group port
Test-oam duration and rate Yes No test-oam group duration rate
Remote Sys MAC Yes No test-oam group remote-sys-mac
Configuration Guidelines
Consider the following guidelines when configuring the OmniSwitch CPE Test group:
• Make sure the same CPE test group name (test ID) is used on the generator and analyzer switch.
• A switch can only perform one role (generator or analyzer) for a specific test.
• Each test which will be configured in the list of tests in the CPE test group that needs to run
concurrently must be configured before adding in the list.
• Each flow is properly configured to be classified into the correct CoS or QoS profile.
• The sum of bandwidth of the grouped test streams must not exceed the supported line-rate of
100 Mbps for copper port and 1 Gig for fiber port.
• Only one CPE test group can be active for the switch at any given time.
• Up to 32 CPE test groups are allowed per switch.
• The feeder port must be configured to start a CPE test group.
• The VLAN used for a CPE test group must be a service VLAN.
• Each test in a CPE test group must have a unique VLAN, source mac-address, and destination
mac-address.
• The modification to the test which is part of the active CPE test group is not allowed.
• The CPE test group supports eight-test flows that can run concurrently.
• For bidirectional test, the role of the destination switch must be configured as loopback.
• Multicast and broadcast address must not be configured for bidirectional test.
1 Configure the feeder port globally in the system to feed the test traffic to generator port, use the test-
oam feeder command. For example:
-> test-oam feeder-port 1/3
The configured feeder port 1/3 will feed the test traffic from the CPE test group to the generator port.
2 Configure the CPE test group profile name and an optional description on the generator (SW-1 switch)
and analyzer (SW-2 switch) using the test-oam group command. For example:
-> test-oam group Testgroup1 descr first-testgroup
When the “Testgroup1” CPE test group is created, a profile associated with this name is automatically
created.
3 Configure the list of CPE test group tests that need to be added in the CPE test group using the test-
oam group tests command. For example:
-> test-oam group Testgroup1 tests test1 test2 test3 test4 test5 test6 test7
test8
The configured list of CPE test group tests will run concurrently when the CPE test group Testgroup1
is started.
4 Configure the source (generator) and destination (analyzer) endpoints on SW-1 and SW-2 using the
test-oam group src-endpoint dst-endpoint command. For example:
-> test-oam group Testgroup1 src-endpoint SW1 dst-endpoint SW2
The endpoint is identified using the DNS host name for the switch. In this example, “SW-1” and
“SW-2” are the configured host names for the generator and analyze switch.
5 Configure SW-1 as the generator switch using the test-oam group role command. For example:
Use this command with the generator option on the SW-1 switch. This will configure the role
parameter in the “Testgroup1” CPE test group profile that resides on SW-1.
6 Configure SW-2 as the analyzer switch using the test-oam group role command. For example:
Use this command with the analyzer option on the SW-2 switch. This will configure the role
parameter in the “Testgroup1” CPE test group profile that resides on SW-2.
Note that a switch can only serve as the generator or the analyzer for any given test.
7 Configures the port in SW-1 on which the CPE test group test will run, using the test-oam group port
command. For example:
-> test-oam group Testgroup1 port 1/2
This is the ingress UNI port that will generate test packets. The packets are then subject to the SAP
profile and QoS policies that are associated with the port.
8 Configure the test duration and rate of the CPE test group packet on SW-1 using the test-oam group
duration rate command. For example:
-> test-oam group Testgroup1 duration 20 rate 8m
The test duration is the length of time, in seconds, that the test will run. The rate determines the rate at
which packets are generated, in kbps or mbps. The group rate configuration is optional. The test band-
width is considered by default if the group rate is not configured.
The following table provides a summary of the CLI commands used in the configuration example:
Refer to the OmniSwitch 6250/6350/6450 CLI Reference Guide for more information about these
commands.
This command also includes the following optional parameter used to specify runtime (active) values for
the specified test:
port—the port on which the test will generate test frames.
When this runtime parameter is specified with the test-oam group start command, the parameter value is
used instead of the value configured for the same parameter in the CPE test group profile. For
example, if the “Testgroup1” profile specifies port 1/10 for the test, the following command will run the
“Testgroup1” test on port 1/4:
-> test-oam group Testgroup1 port 1/4 start
Note. The runtime values specified for any of the optional test-oam group start command parameters do
not overwrite the configured values for the test profile. In addition, if there are no configured values for
these parameters in the profile and a runtime value is not specified with the command, the test will not run.
Stopping the CPE test group on both the generator and analyzer is recommended. The analyzer switch will
continue to send out packets attempting to learn the test source if the test is not stopped on the analyzer
switch as well.
show test-oam group Displays the configuration and status of the CPE test groups.
show test-oam group statistics Displays the statistics for all CPE test groups or for a specific CPE
test group.
show test-oam group Displays the SAA test statistics for all CPE test groups or for a spe-
cific test name.
The show test-oam group command displays the configuration and status of the CPE test groups. For
example:
-> show test-oam group tests
Total Test-Groups: 2
Feeder Port : none
Test-Group Port Duration Rate Nb of Direction Status Remote-Sys-Mac
(secs) Flows
----------+-----+----------+---------+-----+---------------+------------+---------------------
Testgroup1 none 5 - 2 unidirectional not-started 00:00:00:00:00:00
Testgroup2 none 5 - 3 unidirectional not-started 00:00:00:00:00:00
Flow1:
Test Name : test_1,
Vlan: 1001
Tx Rate : 1M,
Source MAC: 00:00:00:00:01:01,
Destination MAC: 00:00:00:00:01:02,
Remote Sys MAC : E8:E7:32:72:01:A4,
Frame size: 64,
L2-SAA DE : False,
L2-SAA Payload Size : 100,
L2-SAA Count : 5,
L2-SAA Interval : 1000,
L2-SAA Priority : 0
Flow2:
Test Name : test_2,
Vlan: 1002
Tx Rate : 10M,
Source MAC: 00:00:00:00:02:01,
Destination MAC: 00:00:00:00:02:02,
Remote Sys MAC : E8:E7:32:72:01:A4,
Frame size: 1518,
L2-SAA DE : False,
L2-SAA Payload Size : 100,
L2-SAA Count : 5,
L2-SAA Interval : 1000,
L2-SAA Priority : 0
Flow3:
Test Name : test_3,
Vlan: 1003
Tx Rate: 15M,
Source MAC: 00:00:00:00:03:01,
Destination MAC: 00:00:00:00:03:02,
Remote Sys MAC : E8:E7:32:72:01:A4,
Frame size: 1518,
L2-SAA DE : False,
L2-SAA Payload Size : 100,
L2-SAA Count : 5,
L2-SAA Interval : 1000,
L2-SAA Priority : 0
Flow4:
Test Name : test_4,
Vlan: 1004
Tx Rate: 5M,
Source MAC: 00:00:00:00:04:01,
Destination MAC: 00:00:00:00:04:02,
Remote Sys MAC : E8:E7:32:72:01:A4,
Frame size: 1518,
L2-SAA DE : False,
L2-SAA Payload Size : 100,
L2-SAA Count : 5,
L2-SAA Interval : 1000,
L2-SAA Priority : 0
The show test-oam group statistics command displays the statistics for all CPE test
groups or for a specific CPE test group. For example:
The packet counts displayed are based on the role the switch plays for the specific test. For example,
“TestGroup1” shows statistics for TX-Ingress (packets transmitted on ingress UNI) and TX-Egress
(packets transmitted on egress NNI), but not for RX-Ingress (packets received on ingress NNI). This is
because the show command was performed on the generator switch for “TestGroup1”.
To verify the received test packet count for “TestGroup1”, use the show test-oam group statistics
command on the analyzer switch.
Note. For more information about the resulting display from these commands, see the OmniSwitch 6250/
6350/6450 CLI Reference Guide.
Note. Use the show test-oam saa statistics command to view the test results.
In case of multi stream test, use the test-oam group remote-sys-mac command to configure the remote
device to receive the test OAM messages. For example:
-> test-oam group Testgroup1 remote-sys-mac 00:e0:b1:7c:7a:fa
Note. Use the more command to read the test results stored on the switch.
The CLI configuration for the displayed scenario is shown in the following table:
The CLI configuration for the displayed scenario is shown in the following table:
Note. For bidirectional test, the role of the destination switch must be configured as loopback.
The CLI configuration for the displayed scenario is shown in the following table:
Note. The individual tests must be configured before being added to the test group.
A maximum of eight test can be added in a group.
Point-to-Point Protocol over Ethernet (PPPoE) provides the ability to connect a network of hosts over a
simple bridging access device to a Remote Access Concentrator (RAC). For example, Broadband Network
Gateway. In PPPoE model, each host utilizes its own Point-to-Point Protocol (PPP) stack and the user is
presented with a familiar user interface. Access control, billing, and type of service can be configured on a
per-user, rather than a per-site, basis.
PPPoE Intermediate Agent (PPPoE-IA) solution is designed for the PPPoE access method and is based on
the access node implementing a PPPoE-IA function to insert the access loop identification.
In This Chapter
This chapter describes the PPPoE-IA feature and how to configure it through the Command Line
Interface (CLI). CLI commands are used in the configuration examples. For more details about the syntax
of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
This chapter includes the following:
• “PPPoE-IA Specifications” on page 16-2
• “PPPoE-IA Defaults” on page 16-2
• “Quick Steps for Configuring PPPoE-IA” on page 16-3
• “PPPoE Intermediate Agent Overview” on page 16-5
• “Configuring PPPoE-IA” on page 16-6
• “Verifying PPPoE-IA Configuration” on page 16-9
PPPoE-IA Specifications
Platforms Supported OmniSwitch 6250, 6350, 6450
Metro license required for OmniSwitch 6250 and OmniS-
witch 6450 Enterprise models.
Maximum number of options 5
supported for Circuit-Identifier
Maximum Circuit-Identifier 63 Bytes
length supported
Maximum Remote-Identifier length 63 Bytes
supported
PPPoE-IA Defaults
Following are the PPPoE-IA default values:
Note. All PPPoE-IA parameters are configurable irrespective of the global status of PPPoE-IA. It is
mandatory to enable PPPoE-IA globally as well as on a port for the PPPoE-IA feature to function.
2 Enable PPPoE-IA on a port or a link aggregate port using the pppoe-ia port command. For
example, the following command enables PPPoE-IA on port 1/1 of the switch.
-> pppoe-ia port 1/1 enable
3 Configure a port or a link aggregate port as trusted or client port for PPPoE-IA using the pppoe-ia port
{trust | client} command. By default, all ports are client ports. For example, the following command
configures port 1/1 as a trusted port.
-> pppoe-ia port 1/1 trust
Note. The port that is connected to the PPPoE server must be configured as trusted, whereas the port
connected to the host must be configured as a client port. Both client and trust ports must be in the same
VLAN.
4 Configure a format to form an identifier that uniquely identifies an access node globally using the
pppoe-ia access-node-id command. For example, the following command uses the base MAC address of
the switch to identify an access node.
-> pppoe-ia access-node-id base-mac
5 Configure a Circuit-ID format that forms an identifier that uniquely identifies an access node globally,
and an access loop that receives the PADI/PADR/PADT from the user side using the pppoe-ia circuit-id
command. For example, the following command uses the base MAC address in ASCII format as the
Circuit-ID.
-> pppoe-ia circuit-id ascii base-mac vlan
6 Configure a format to form an identifier that uniquely identifies the user attached to the access loop
globally using the pppoe-ia remote-id command. For example, the following command uses the user
configured string as the format for Remote-ID:
-> pppoe-ia remote-id user-string "remote-id-1"
Note. To view the global configuration for PPPoE-IA, enter the show pppoe-ia configuration command.
The PPPoE-IA configuration is displayed as shown:
-> show pppoe-ia configuration
Status : enabled,
Access Node Identifier
Access-node-id Format : system-name,
Access-node-id String : vxTarget,
Circuit Identifier
Circuit-Id Format : ascii,
Circuit-id Field1 : system-name,
Circuit-id Field1 String : vxTarget,
Circuit-id Field2 : base-mac,
Circuit-id Field2 String : 00:d0:95:ee:fb:02,
Circuit-id Field3 : interface,
Circuit-id Field3 String : ,
Circuit-id Field4 : none,
Circuit-id Field4 String : ,
Circuit-id Field5 : none,
Circuit-id Field5 String : ,
Circuit-id Delimiter : "|",
Remote Identifier
Remote-id Format : mgnt-address,
Remote-id String : 172.21.161.106
Configuring PPPoE-IA
This section describes how to configure PPPoE-IA using the CLI commands.
Note. All PPPoE-IA parameters are configurable irrespective of the global status of PPPoE-IA. It is
mandatory to enable PPPoE-IA globally as well as on a port for the PPPoE-IA to function.
Note. PPPoE-IA is not supported on port mirroring destination ports, however, the configurations are
accepted. PPPoE-IA is not supported on aggregable ports.
For example, the following command uses the user configured string to identify an access node:
-> pppoe-ia access-node-id user-string acessnode1
If the management address format is used as the Access Node Identifier, then the IP address of the Loop-
back0 interface (if configured and active) or the first active IP interface address is used as the manage-
ment address. If none of them are available, IP address ‘0.0.0.0’ is used as management address.
The access-node-identifier can have a maximum of 32 characters. The access-node-identifier longer than
32 characters is truncated to 32 characters when encoded in the VSA tag.
Default Circuit ID
default: When the PPPoE Circuit-ID is configured as default, the access-node-id is formed from either of
the four supported formats: base-mac, system-name, mgnt-address, or user configurable string.
For example, the following command is used to configure the Circuit-ID as default.
-> pppoe-ia circuit-id default
When the Circuit-ID is configured as default, the Circuit-ID format in the Circuit-Identifier will display as
“ethernet”. For more information, see show pppoe-ia configuration command in the OmniSwitch 6250/
6350/6450 CLI Reference Guide
default ATM: When the PPPoE-IA Circuit-ID format is configured as “default atm” the Circuit-ID
encoding happens for “ATM” (Asynchronous Transfer Mode) parameter along with ethernet parameter.
For example, the following command is used to configure the Circuit-ID as “default ATM”.
-> pppoe-ia circuit-id default atm
When the Circuit-ID is configured as default ATM, the Circuit-ID format in the Circuit-Identifier will
display as “atm”. For more information, see show pppoe-ia configuration command in the OmniSwitch
6250/6350/6450 CLI Reference Guide
ASCII Circuit ID
In the ascii Circuit-ID, the fields (maximum of five) are separated by delimiter up to a maximum of 63
characters.
For example, the following command uses the base-mac in ASCII format of the Circuit-ID:
-> pppoe-ia circuit-id ascii base-mac vlan
If the management address format is used as the Remote-ID, the IP address of the Loopback0 interface (if
configured and active) or the first active IP interface address is used as the management address. If none of
them are available, IP address ‘0.0.0.0’ is used as management address.
To clear the statistics for all the physical or link-aggregate ports, a single port or a link aggregate port, or a
range of physical ports for PPPoE-IA, use the clear pppoe-ia statistics command.
For more information about the output details that result from these commands, see the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
The rise in the number of Ethernet service instances has resulted in service providers requiring a powerful
and robust set of management tools to maintain Ethernet service networks. Service provider networks are
large and intricate, often comprising of different operators that work together to provide the customers
with end-to-end services. The challenge for the service providers is to provide a highly available
convergent network to its customer base. Ethernet OAM (Operations, Administration, and Maintenance)
provides the detection, resiliency, and monitoring capability for end-to-end service guarantee in an
Ethernet network.
In This Chapter
This chapter describes the Ethernet OAM feature, how to configure it and display Ethernet OAM
information through the Command Line Interface (CLI). For more details about the syntax of commands,
see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
The following procedures are described in this chapter:
• “Ethernet OAM Overview” on page 17-3.
• “Elements of Service OAM” on page 17-3.
• “Fault Management” on page 17-6.
• “Performance Monitoring” on page 17-6.
• “Interoperability with ITU-T Y.1731” on page 17-8.
• “Configuring Ethernet OAM” on page 17-10.
• “Verifying the Ethernet OAM Configuration” on page 17-17.
• “CVLANs for EVC MEPs” on page 17-14.
Customer
Domain
Provider
Domain
Customer Customer
Network Network
Fault Management
Service OAM Connectivity Fault Management consists of three types of messages that are used to help
network administrators detect, verify, and isolate when a problem occurs in the network:
• Continuity Check Messages (CCM)—These are multicast messages exchanged periodically by MEPs
to detect loss of service connectivity between MEPs. These messages are also used by MEPs and MIPs
to discover other MEPs within a domain.
• Linktrace Messages (LTM)—These messages are transmitted by a MEP to trace the path to a
destination maintenance point. The receiving maintenance point responds to LTMs with a linktrace
reply (LTR). This mechanism is similar to the UDP Trace Route function. The transmission of
linktrace messages is requested by an administrator.
• Loopback Messages (LBM)—These messages are transmitted by a MEP to a specified MIP or MEP
to determine whether or not the maintenance point is reachable. The receiving maintenance point
responds to LBMs with a loopback reply (LBR). This mechanism is not used to discover a path to the
destination; it is similar to the Ping function. The transmission of loopback messages is requested by an
administrator.
Any MEP can initiate or reply to an ETH-DM request, depending on the type of delay measurement
requested. However during the phase of exchanging messages, five defects can be encountered by an
MEP.
• Cross-connect defect
• Error CCM defect
• Remote defect
• MAC defect
• RDI defect
These defects are logged whenever there is a loss in connectivity between two connected MEPs. This
feature is supported only on Metro models.
Performance Monitoring
The ITU-T Y.1731 Recommendation addresses the need to monitor performance to help enforce customer
service level agreements (SLAs). Frame delay (latency) and frame delay variation (jitter) are important
performance objectives, especially for those applications (such as voice) that cannot function with a high
level of latency or jitter.
This implementation of Service OAM supports Ethernet frame delay measurement (ETH-DM) and is
compliant with Y.1731. The ETH-DM feature allows for the configuration of on-demand OAM to
measure frame delay and frame delay variation between endpoints.
Frame delay measurement is performed between peer MEPs (measurements to MIPs are not done) within
the same MA. Although the OmniSwitch implementation of ETH-DM is compliant with ITU-T Y.1731,
delay measurement can be performed for both ITU-T Y.1731 and IEEE 802.1ag MEPs.
There are two types of delay measurements supported: one-way and two-way.
One-way ETH-DM
• A MEP sends one-way delay measurement (1DM)) frames to a peer MEP. The sending MEP inserts
the transmission time into the 1DM frame at the time the frame is sent.
• When a MEP receives a 1DM frame, the MEP calculates the one-way delay as the difference between
the time at which the frame was received and the transmission time indicated by the frame timestamp
(receive time minus transmission time).
• One-way delay measurement statistics are gathered and stored on the receiving MEP (the MEP that
receives a 1DM request).
• One-way ETH-DM requires clock synchronization between the sending and receiving MEPs. Using
NTP for clock synchronization is recommended.
Two-way ETH-DM
• A MEP sends delay measurement message (DMM) frames to a peer MEP to request a two-way ETH-
DM. The sending MEP inserts the transmission time into the DMM frame at the time the frame is sent.
• When a MEP receives a DMM frame, the MEP responds to the DMM with a delay message reply
(DMR) frame that contains the following timestamps:
– Timestamp copied from the DMM frame.
– Timestamp indicating when the DMM frame was received.
– Timestamp indicating the time at which the receiving MEP transmitted the DMR frame back to the
sending MEP.
• When a MEP receives a DMR frame, the MEP compares all the DMR timestamps with the time at
which the MEP received the DMR frame to calculate the two-way delay.
• The two-way delay is the difference between the time the originating MEP sent a DMM request and
the time at which the originating MEP received a DMR frame minus the time taken by the responding
MEP to process the DMM request.
• Two-way delay measurement statistics are gathered and stored on the originating MEP (the MEP that
initiates a DMM request).
• This method does not require clock synchronization between the transmitting and receiving MEPs.
• Two-way ETH-DM is an on-demand OAM performance measurement. To set up continuous two-way
delay measurement, see the “Service Assurance Agent Commands” chapter in the OmniSwitch 6250/
6350/6450 CLI Reference Guide for information about how to configure a SAA for continuous two-
way frame delay measurement.
Support for both the IEEE and ITU-T Ethernet CFM standards allows interoperability between OmniS-
witch 802.1ag and Y.1731 CFM with the following minor configuration requirements:
• The OmniSwitch MD format must be configured as “none”.
• ITU-T Y.1731 uses the “icc-based” format for a MEG, so the OmniSwitch MA format must also be
configured to use the “icc-based” format.
• When the OmniSwitch MA is configured with the “icc-based” format, the MA name is automatically
padded with zeros if the name specified is less than 13 characters.
The OmniSwitch CLI commands to configure an MD and MA include the “none” and “icc-based” format
options. See “Configuring Ethernet OAM” on page 17-10 for more information.
2 Create an Ethernet OAM Maintenance Association using the ethoam association command.
For example:
-> ethoam association alcatel-lucent-sales format string domain esd.alcatel.com
primary-vlan 10
3 Create an Configure the endpoint list for the Ethernet OAM Maintenance End Point Association using
the ethoam endpoint admin-stateethoam association endpoint-list command. For example:
-> ethoam association alcatel-lucent-sales domain esd.alcatel-lucent.com
endpoint-list 100
4 Create an Ethernet OAM Maintenance End Point using the ethoam endpoint admin-state command.
For example:
-> ethoam endpoint 100 domain esd.alcatel.com association alcatel-lucent-sales
direction up port 1/10
5 Administratively enable the Ethernet OAM Maintenance End Point using the ethoam endpoint
admin-state command. For example:
-> ethoam endpoint 100 domain esd.alcatel-lucent.com association
alcatel-lucent-sales admin-state enable
6 Enable Continuity Check Messages for the Ethernet OAM Maintenance End Point using the ethoam
endpoint ccm command. For example:
-> ethoam endpoint 100 domain esd.alcatel-lucent.com association
alcatel-lucent-sales ccm enable
7 Configure the Message Handling Function (MHF) value of an Ethernet OAM Maintenance Domain
using the ethoam domain mhf command. For example:
-> ethoam domain esd.alcatel-lucent.com mhf explicit
8 Enable the maintenance entity to initiate transmitting loopback messages to obtain loopback replies
using the ethoam loopback command. For example:
-> ethoam loopback target-endpoint 15 source-endpoint 100 domain esd.alca-
tel.com association alcatel-lucent-sales
Note that with this implementation of Ethernet OAM, it is only possible to delete an MD when there is no
Maintenance Association, End Point, or Intermediate Point associated with the MD.
To modify the default Ethernet OAM Maintenance Domain, use the ethoam default-domain level
command, as shown:
-> ethoam default-domain primary vlan 100 level 4 mhf none
Note. The no form of this command restores the default Ethernet OAM Maintenance Domain value.
Note that with this implementation of Ethernet OAM, it is only possible to delete an MA when there is no
Maintenance End Point (MEP) or Maintenance Intermediate Point (MIP) associated with the MA.
By default, the CCM interval is set to 10 seconds. To modify this value for an MA, use the ethoam asso-
ciation ccm-interval command:
-> ethoam association alcatel-lucent-sales domain esd.alcatel.com ccm-interval
interval1m
To modify the MEP list of an MA, use the ethoam association endpoint-list command, as shown:
-> ethoam association alcatel-lucent-sales domain esd.alcatel.com endpoint-list
100-200
To remove the MEP list from an Ethernet OAM Maintenance Association, enter:
-> no ethoam association alcatel-lucent-sales domain esd.alcatel.com endpoint-
list 100-200
To configure the administrative state of a MEP, use the ethoam endpoint admin-state command. For
example:
-> ethoam end-point 100 domain esd.alcatel.com association alcatel-lucent-sales
admin-state enable
To configure the priority values for Continuity Check Messages and Linktrace Messages transmitted by a
MEP, use the ethoam endpoint priority command. For example:
-> ethoam end-point 100 domain esd.alcatel.com association alcatel-lucent-sales
priority 6
To configure the lowest priority fault alarm for the lowest priority defect for a MEP, use the ethoam
endpoint lowest-priority-defect command. For example:
-> ethoam end-point 100 domain esd.alcatel.com association alcatel-lucent-sales
lowest-priority-defect all-defect
Configuring Loopback
To initiate transmitting Loopback messages (LBMs) and obtaining Loopback replies (LBRs), use the
ethoam loopback command. For example:
Configuring Linktrace
To initiate transmitting Linktrace messages (LTMs) and detecting Linktrace replies (LTR), use the
ethoam linktrace command. For example:
-> ethoam linktrace 10:aa:ac:12:12:ad end-point 4 domain esd.alcatel.com
association alcatel-lucent_sales flag fdbonly hop-count 32
One-Way ETH-DM
The ethoam one-way-delay command is used to configure a one-way ETH-DM (1DM) to monitor perfor-
mance between two MEPs. For example, the following command is used to initiate the transmission of
1DM frames to a target MEP:
-> ethoam one-way-delay target-endpoint 10 source-endpoint 12 domain MD1 associ-
ation MA1 vlan-priority 4
This command initiates the sending of 1DM frames from MEP 12 to MEP 10, which does not reply to
frames received from MEP 12. The latency and jitter statistics are gathered and stored on the receiving
MEP, which is MEP 10 in this example.
An option to specify a target MAC address, instead of a MEP ID, is also supported. For example:
-> ethoam one-way-delay target-macaddress 00:e0:b1:6a:52:4c source-endpoint 12
domain MD association MA vlan-priority 4
One-way delay measurement statistics are gathered and stored on the receiving MEP (the MEP that
receives a 1DM request).
Note. One-way ETH-DM requires clock synchronization between the sending and receiving MEPs. Using
NTP for clock synchronization is recommended.
Two-Way ETH-DM
The ethoam two-way-delay command is used to configure a two-way ETH-DM to monitor round-trip
performance between two MEPs. For example, the following command is used to initiate the transmission
of delay measurement message (DMM) frames to a target MEP:
This command initiates the sending of DMM frames from MEP 12 to MEP 10. However, with two-way
delay measurement, the receiving MEP replies with delay message response (DMR) frames to the sending
MEP. In this example, MEP 10 sends DMR frames back to MEP 12.
An option to specify a target MAC address, instead of a MEP ID, is also supported. For example:
The direction of the MEP must be UP and the port should be a UNI port using Ethernet service, for which
the CVLAN is configured.
Note. The CVLAN ID must be part of the allowed CVLAN list before being configured.
Note. Remote Fault Propagation (RFP) is configurable on per MEP basis supported only for UP MEPs.
RFP is not supported on virtual UP MEPs.
Note. The CVLANs configured in the allowed CVLAN list must be associated with the SVLAN of the
MA.
If the priority value is not configured, by default the outer-tag priority is configured to the inner-tag prior-
ity. The priority value range is 0 to 7.
To associate the CVLAN as untagged to the UNI port, use the command ethernet-service sap uni
untagged-cvlan command. For example:
-> ethernet-service sap 10 uni 1/7 untagged-cvlan 10
To configure an SVLAN interface which would map the SVLAN to the CVLAN, use the command Ip
interface cvlan command. For example:
-> ip interface "vlan10" address 10.10.10.1 mask 255.255.255.0 cvlan 10 vlan
1001
Note. To view the status of the CVLAN insertion for untagged packets feature, use the command show
ethernet-service untagged-cvlan-insert. To view CVLAN mapped interface, use the command show ip
interface cvlan. For more information, see OmniSwitch 6250/6350/6450 CLI Reference Guide.
show ethoam domain Displays the CVLANs configured for the MEPs in the MA.
association
show ethoam domain Displays the CVLAN configured for the MEP.
association end-point
show ethoam domain Displays the allowed CVLAN list configured for the MEP.
show ethoam Displays the information of all the Management Domains configured on
the switch.
show ethoam domain Displays the information of a specific Management Domain configured
on the switch.
show ethoam domain Displays the information of a specific MA in a Management Domain
association configured on the switch.
show ethoam domain Displays the information of a specific MEP in a Management Domain
association end-point configured on the switch.
show ethoam default-domain Displays all the default MD information for all the VLANs or a specific
VLAN.
show ethoam remote-endpoint Displays the information of all remote MEPs learned as a part of the
CCM message exchange.
show ethoam cfmstack Displays the contents of CFM Stack Managed Object, which determines
the relationships among MEPs and MIPs on a specific switch port.
show ethoam linktrace-reply Displays the content of the Linktrace reply (LTR) returned by a previ-
ously transmitted LTM. This command displays the LTR based on the
transaction identifier or sequence number of the LTM for which the
LTR is to be displayed
show ethoam linktrace-tran-id Displays the transaction identifiers returned by previously generated
LTMs from a specified MEP.
show ethoam vlan Displays the Ethernet OAM statistics of all the Management Domains
configured on the switch. Also, displays the statistics of all the MAs and
matching MEPs for all the MDs.
With SAAs, users can verify service guarantees, increase network reliability by validating network
performance, proactively identify network issues, and increase Return on Investment (ROI) by easing the
deployment of new services. SAA uses active monitoring to generate traffic in a continuous, reliable, and
predictable manner, thus enabling the measurement of network performance and health.
IP SAAs enhance the service level monitoring to become IP application-aware by measuring both end-to-
end and at the IP layer. IP SAA allows performance measurement against any IP addresses in the network
(for example, switch, server, PC). ETH-LB/DMM can be used to measure delay and jitter by sending out
frames with DM information to the peer MEP and receiving frames with DM information from the peer
MEP.
In This Chapter
This chapter describes the various types of SAAs that can be configured on an OmniSwitch.
Configuration procedures described in this chapter include:
• Configuring SAA for MAC Address on page 18-4.
• Configuring SAA for IP on page 18-4.
• Configuring SAA for Ethoam Loopback on page 18-4.
• Configuring SAA for ETH-DMM on page 18-4.
• Displaying SAA Configuration on page 18-5.
SAA Specifications
The following table lists Ethernet OAM specifications.
Note. SAA interval value can be configured as 1, 2, 5 or 10 to 1500. Depending on the configuration, it
may not be possible to run 128 SAAs. A SAA scheduler resource check is implemented to guarantee the
start of a new SAA.
SAA Defaults
The following table shows SAA default values.
2 Configure SAA for MAC using the saa type mac-ping command. For example:
3 Configure SAA for Ethoam loopback using the saa type ethoam-loopback command.
For example:
-> saa “saa-lb” type ethoam-loopback target-endpoint 10 source endpoint 1 domain
md1 association ma1 vlan-priority 5 drop-eligible false
4 Configure SAA for ETH-DMM using saa type ethoam-two-way-delay command. For example:
show saa Displays generic configuration parameters of all the SAAs maintained at
a given time.
show saa statistics Displays SAA statistics.
show saa type config Displays configured SAAs of the given type.
Ethernet in the First Mile (EFM), also known as LINK OAM, is a collection of protocols specified in
IEEE 802.3ah, defining Ethernet in the access networks that connects subscribers to their immediate
service provider. EFM, EFM-OAM and LINK OAM refers to IEEE 802.3ah standard.
LINK OAM (Operation, Administration, and Maintenance) is a tool monitoring Layer-2 link status by
sending OAM protocol data units (OAMPDUs) between networked devices on the first mile. The first
mile network refers to the connection between the subscriber and the public carrier network. LINK OAM
is mainly used to address common link-related issues on the first mile. It helps network administrators
manage their networks effectively.
By enabling LINK OAM on two devices connected by a point-to-point connection, network administra-
tors can monitor the status of the link, detect faults in network segments, and probe link errors by using
loopback testing.
In This Chapter
This chapter describes the LINK OAM feature and how to configure it through the Command Line Inter-
face (CLI). CLI commands are used in the configuration examples; for more details about the syntax of
commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide. This chapter provides an overview
of LINK OAM and includes the following information:
• “LINK OAM Specifications” on page 19-2
• “LINK OAM Defaults” on page 19-3
• “Quick Steps for Configuring LINK OAM” on page 19-4
• “Interaction With Other Features” on page 19-7
• “Configuring Link Monitoring” on page 19-9
• “Configuring LINK OAM” on page 19-8
• “Verifying the LINK OAM Configuration” on page 19-11
2 Enable LINK OAM protocol for a specific port using the efm-oam port status command. For example
3 Configure the LINK AOM port to active mode by using the efm-oam port mode command.
For example:
-> efm-oam port 1/1 mode active
Note. The above step is optional. By default, LINK OAM mode is active on all ports.
4 Configure the timeout interval (keep-alive) for the dynamically learned neighboring devices on the port
by using the efm-oam port keepalive-interval command. For example:
-> efm-oam port 1/1 keepalive-interval 10
5 Configure the time interval by which the information OAMPDUs has to be transmitted out of an LINK
OAM enabled port by using the efm-oam port hello-interval command. For example:
-> efm-oam port 1/1 hello-interval 5
6 Activate remote loop back processing on the port by using the efm-oam port remote-loopback
command. For example:
-> efm-oam port 1/1 remote-loopback process
7 Activate propagation of critical events and dying gasp events on the port by using the efm-oam port
propagate-events command. For example:
-> efm-oam port 1/1 propagate-events critical-event enable
Note. The above step is optional. By default, propagation of critical events and dying gasp is enabled on
the port.
8 Configure the threshold, window frame values and notify status for errored frame period events on the
port by using the efm-oam errored-frame-period command. For example:
-> efm-oam port 1/1 errored-frame-period window 3000000 threshold 1 notify
enable
9 Configure the threshold, window, and notify status for errored frame events on the port by using the
efm-oam errored-frame command. For example:
-> efm-oam port 1/1 errored-frame window 32 threshold 10 notify enable
10 Configure the threshold, window and notify-status for errored-frame-seconds-summary on the port by
using the efm-oam errored-frame-seconds-summary command. For example:
-> efm-oam port 1/1 errored-frame-seconds-summary window 700 threshold 1 notify
enable
Site A Site B
OAM information is conveyed in slow protocol frames called OAM Protocol Data Units (OAMPDUs).
OAMPDUs contain the appropriate control and status information used to monitor, test and troubleshoot
OAM-enabled links. OAMPDUs traverse a single link, being passed between peer OAM nodes, and as
such, are not forwarded by MAC clients (e.g., bridges or switches). OAM does not include functions such
as station management, bandwidth allocation or provisioning functions.
The mandatory LINK OAM functions include discovery operations (determining if the other end of the
link is OAM capable and what OAM functions it supports), state machine implementation and some criti-
cal event flows. OAM remote loopback can be used for fault localization and link performance testing.
The features of the LINK OAM protocol discussed in this section are:
• “Discovery” on page 19-6
• “Link Monitoring” on page 19-6
• “Remote Fault detection” on page 19-6
• “Remote Loopback Testing” on page 19-7
Discovery
Discovery is the first phase of the IEEE 802.3ah OAM protocol. During discovery, information about
LINK OAM node’s capabilities, configuration, and identity are exchanged in the form of OAM protocol
data units (OAMPDUs).
The interconnected LINK OAM nodes notify the peer of their OAM configuration information and the
OAM capabilities of the local nodes by exchanging Information OAMPDUs and determine whether LINK
OAM connections can be established. A LINK OAM connection between two nodes is established only
when the settings concerning Loopback, link detecting, and link event of the both sides match.
Note. LINK OAM requires that frames be exchanged with a minimum frequency to maintain the relation-
ship( keep-alive). If no OAMPDUs are received in a 5 second window, the OAM peering relationship is
lost and must be restored to perform OAM functions. Use efm-oam port keepalive-interval command to
configure the keepalive time interval.
Link Monitoring
Error detection in an Ethernet network is difficult, especially when the physical connection in the network
is not disconnected but network performance is degrading gradually. Link monitoring is used to detect and
indicate link faults in various environments. Link monitoring uses the Event Notification OAMPDU, and
sends events to the remote OAM node when there is a disorder detected on the link. The error events
defined are:
Errored frame event - An errored frame event occurs when the number of detected error frames over a
specific interval exceeds the predefined threshold.
Errored frame period event - An errored frame period event occurs if the number of frame errors in
specific number of received frames exceeds the predefined threshold.
Errored frame seconds event - When the number of error frame seconds detected on a port over a detec-
tion interval reaches the error threshold, an errored frame seconds event occurs.
For configuring errored frame, errored frame period, and errored frame seconds events on a port, see
“Configuring Link Monitoring” on page 19-9
For setting up the notification of critical events on a port, see “Enabling and Disabling Propagation of
Events” on page 19-9
Link Aggregate
LINK OAM does not work on the logical link aggregate port. But, it can run on the individual aggregable
(physical) port.
ERP
LINK OAM is supported in Ethernet Ring Protection (ERP) switching mechanism. ERP (ITU-T G.8032/
Y.1344) is a self-configuring algorithm that maintains a loop-free topology while providing data path
redundancy and network scalability. ERP provides fast recovery times for Ethernet ring topologies by
utilizing traditional Ethernet MAC and bridge functions.
To enable LINK OAM globally on a range of ports, use the efm-oam command, as shown:
-> efm-oam port 2/1-10 status enable
To disable LINK OAM globally on a range of ports, use the disable form of the command, as shown:
-> efm-oam port 2/1-10 status disable
To enable LINK OAM mode to active, use the port mode command, as shown:
-> efm-oam port 2/1-10 mode active
To configure the time interval by which the information OAMPDUs has to be transmitted out of an LINK
OAM enabled port, use the efm-oam port hello-interval command.
-> efm-oam port 2/1-10 hello-interval 10
Note. By default, the keep-alive interval value is 5 seconds and the hello-interval value is set to 1 second.
Note. The above commands are optional. By default, propagation of critical events and dying gasp is
enabled on the port.
To disable notification of errored frame period events, use the following command.
-> efm-oam port 2/1-10 errored-frame-period notify disable
When the remote-loopback is in ignore mode, the session started by peer LINK OAM is not processed by
the local port.
For remote loop back processing to be ignored on the port, use the following command.
-> efm-oam port 2/1-10 remote-loopback ignore
After configuring the port to process remote loopback, the port has to be initiated for loopback session to
start.
-> efm-oam port 1/1 remote-loopback start
The above command initiates the loopback control PDU towards the peer port to start. To stop the remote-
loopback sessionl, use the following command.
-> efm-oam port 1/1 remote-loopback stop
To configure the number of frames to be sent by the current LINK OAM port to the remote port’s MAC
address (l1 ping) and the delay between each consecutive sent frames and to start the ping operation, use
the following command.
-> efm-oam port 1/20 l1-ping num-frames 12 delay 500 start
Note. By default, the number of frames value is 5 frames and the delay is set to 1000 milliseconds.
UniDirectional Link Detection (UDLD) is a protocol for detecting and disabling unidirectional Ethernet
fiber or copper links caused by mis-wiring of fiber strands, interface malfunctions, media converter faults,
and so on. The UDLD operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detec-
tion mechanisms.
UDLD is a lightweight protocol that can be used to detect and disable one-way connections before they
create dangerous situations such as Spanning Tree loops or other protocol malfunctions. The protocol is
mainly used to advertise the identities of all the UDLD-capable devices attached to the same LAN
segment and to collect the information received on the ports of each device to determine whether the Layer
2 communication is functioning properly. All connected devices must support UDLD for the protocol to
successfully identify and disable unidirectional links. When UDLD detects a unidirectional link, the proto-
col administratively shuts down the affected port and generates a trap to alert the user.
In This Chapter
This chapter describes how to configure UDLD parameters through the Command Line Interface (CLI).
CLI commands are used in the configuration examples; for more details about the syntax of commands,
see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Configuration procedures described in this chapter include the following:
• Configuring UDLD on page 20-6.
• Configuring the operational mode on page 20-7.
• Configuring the probe-message advertisement timer on page 20-7.
• Configuring the echo-based detection timer on page 20-7.
• Clearing UDLD statistics on page 20-8.
• Recovering a port from UDLD shutdown on page 20-8.
• Displaying UDLD information on page 20-8.
UDLD Specifications
RFCs supported Not applicable at this time
IEEE Standards supported Not applicable at this time
Platforms Supported OmniSwitch 6250, 6350, 6450
Probe-message advertisement timer 7 to 90 in seconds
Echo-based detection timer 4 to 15 in seconds
Maximum neighbors per UDLD 32
port
Maximum number of UDLD ports 128
per system
UDLD Defaults
Parameter Description Command Default
UDLD administrative state udld Disabled
UDLD status of a port udld port Disabled
UDLD operational mode udld mode Normal
Probe-message advertisement timer udld probe-timer 15 seconds
Echo-based detection timer udld echo-wait-timer 8 seconds
2 To enable the UDLD protocol on a port, use the udld port command by entering udld port, followed
by the slot and port number, and enable. For example:
-> udld port 1/6 enable
3 Configure the operational mode of UDLD by entering udld port, followed by the slot and port
number, mode, and the operational mode. For example:
-> udld port 1/6 mode aggressive
4 Configure the probe-message advertisement timer on port 6 of slot 1 as 17 seconds using the following
command:
-> udld port 1/6 probe-timer 17
Note. Optional. Verify the UDLD global configuration by entering the show udld configuration
command or verify the UDLD configuration on a port by entering the show udld configuration port
command. For example:
-> show udld configuration
Global UDLD Status : Disabled
To verify the UDLD statistics of a port, use the show udld statistics port command. For example:
-> show udld statistics port 1/42
UDLD Port Statistics
Hello Packet Send :8,
Echo Packet Send :8,
Flush Packet Recvd :0
UDLD Neighbor Statistics
Neighbor ID Hello Pkts Recv Echo Pkts Recv
--------------+--------------------+--------------
1 8 15
2 8 15
3 8 21
4 8 14
5 8 15
6 8 20
UDLD Overview
UDLD is a Layer 2 protocol used to examine the physical configuration connected through fiber-optic or
twisted-pair Ethernet cables. UDLD detects and administratively shuts down the affected port, and alerts
the user when a unidirectional link exists. Unidirectional links can create hazardous situations such as
Spanning-Tree topology loops caused, for instance, by unwiring of fiber strands, interface malfunctions,
media converter’s faults, and so on.
The UDLD feature is supported on the following port types:
• Copper ports
• Fiber ports
Normal Mode
In this mode, the protocol depends on explicit information instead of implicit information. If the protocol
is unable to retrieve any explicit information, the port is not put in the shutdown state; instead, it is marked
as Undetermined. The port is put in the shutdown state only when it is explicitly determined that the link is
defective when it is determined on the basis of UDLD-PDU processing that link has become unidirec-
tional. In any such state transition, a trap is raised.
Aggressive Mode
In this mode, UDLD checks whether the connections are correct and the traffic is flowing bidirectionally
between the respective neighbors. The loss of communication with the neighbor is considered an event to
put the port in shutdown state. Thus, if the UDLD PDUs are not received before the expiry of a timer, the
port is put in the UDLD-shutdown state. Since the lack of information is not always due to a defective
link, this mode is optional and is recommended only for point-to-point links.
UDLD shuts down the affected interface when one of these problems occurs:
• On fiber-optic or twisted-pair links, one of the interfaces cannot send or receive traffic.
• On fiber-optic or twisted-pair links, one of the interfaces is down while the other is up.
• One of the fiber strands in the cable is disconnected.
Echo detection
UDLD depends on an echo-detection mechanism. UDLD restarts the detection window on its side of the
connection and sends echo messages in response to the request, whenever a UDLD device learns about a
new neighbor or receives a re-synchronization request from an out-of-sync neighbor. This behavior is the
same on all UDLD neighbors because the sender of the echoes expects to receive an echo as a response.
If the detection window ends and no valid response is received, the link will be shut down, depending on
the UDLD mode. When UDLD is in normal mode, the link is considered to be undetermined and will not
be shut down. When UDLD is in aggressive mode, the link is considered to be unidirectional, and the
interface is shut down.
In normal mode, if UDLD is in the advertisement or in the detection phase and all the neighbor cache
entries are aged out, UDLD restarts the link-up sequence to re-synchronize with potentially out-of-sync
neighbors.
In aggressive mode, if UDLD is in the advertisement or in the detection phase and all the neighbors of a
port are aged out, UDLD restarts the link-up sequence to re-synchronize with potentially out-of-sync
neighbors. UDLD shuts down the port, after the continuous messages, if the link state is undetermined.
Configuring UDLD
This section describes how to use Command Line Interface (CLI) commands for enabling and disabling
UDLD on a switch or port (see “Enabling and Disabling UDLD” on page 20-6), configuring the opera-
tional mode (see “Configuring mode” on page 20-7), configuring and resetting probe-message advertise-
ment timer (see “Configuring probe-timer” on page 20-7), configuring and resetting echo-based detection
timer (see “Configuring echo-wait-timer” on page 20-7), clearing the UDLD statistics on a switch or port
(see “Clearing UDLD Statistics” on page 20-8), and recovering a port from UDLD shutdown (see
““Recovering a port from UDLD shutdown” on page 20-8).
Note. See the “UDLD Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Reference Guide for
complete documentation of UDLD CLI commands.
Configuring mode
To configure the operational mode, use the udld mode command as shown:
-> udld mode aggressive
To configure the mode for multiple ports, specify a range of ports. For example:
-> udld port 2/7-18 mode normal
Configuring probe-timer
To configure the probe-message advertisement timer, use the udld probe-timer command as shown:
-> udld probe-timer 20
To configure the probe-timer for multiple ports, specify a range of ports. For example:
-> udld port 1/8-21 probe-timer 18
Use the no form of this command to reset the timer. For example, the following command resets the timer
for port 4 of slot 6:
-> no udld port 6/4 probe-timer
Note that when a timer is reset, the default value of 15 seconds is set.
Configuring echo-wait-timer
To configure the echo-based detection timer, use the udld echo-wait-timer command as shown:
-> udld echo-wait-timer 9
To configure the echo-wait-timer for multiple ports, specify a range of ports. For example:
-> udld port 1/8-21 echo-wait-timer 9
Use the no form of this command to reset the timer. For example, the following command resets the timer
for port 6 of slot 4:
-> no udld port 4/6 echo-wait-timer
Note that when a timer is reset, the default value of 8 seconds is set.
For more information about the resulting display from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide. An example of the output for the show udld configuration port and show
udld statistics port commands is also given in “Quick Steps for Configuring UDLD” on page 20-3.
MAC Retention allows a system of stackable switches to retain the MAC address of the primary switch for
a fixed or indefinite time, even after multiple takeovers. This minimizes the recalculation of protocols,
such as Spanning Tree and Link Aggregation. It also minimizes the updation of tables, such as the Address
Resolution Protocol (ARP) table for IPv4 routing and the Neighbor Discovery table for IPv6 routing.
In This Chapter
This chapter describes the basic components of MAC Address Retention and how to configure them
through the Command Line Interface (CLI). CLI commands are used in the configuration examples; for
more details about the syntax of the commands, see the OmniSwitch 6250/6350/6450 CLI Reference
Guide.
Configuration procedures described in this chapter include:
• Enabling MAC Retention on page 21-4.
• Detecting a Duplicate MAC Address on page 21-4.
• Configuring MAC Release on page 21-5.
1 a Primary Element
2 a
Secondary Element
3 a
Switch 1
Idle Element
Stack 1
In the above diagram, Stack 1 has the stack address M1. When a takeover occurs, the secondary element
starts functioning as the new primary element and the stack address is also changed, for example, to M2,
the new primary element’s MAC address. Stack 1 advertises its new stack address M2. Switch 1, which
had previously associated Stack 1 with the stack address M1, now has to change its ARP tables to associ-
ate Stack 1 with the new stack address M2.
Similarly, in IPv6 routing, Switch 1 has to change its Neighbor Discovery tables to associate Stack 1 with
the new stack address M2.
Another aspect that may be impacted is the recalculation of the Spanning Tree in accordance with the
Spanning Tree Protocol (STP). If the stack address is changed due to the election of a new primary
element, a new Spanning Tree has to be recalculated to account for this change. This becomes even more
difficult when the newly elected primary element becomes the new root bridge.
Link Aggregation Control Protocol (LACP) is another application that is influenced by the takeover. This
application uses the base MAC address of the switch as the system ID while exchanging the LACP PDUs
in the network. After takeover, the aggregate ports will administratively go down and then come up again
due to the change in the system ID.
Therefore, to avoid these recalculations, when a primary element fails in a stack, the secondary element,
which takes over as the new primary element uses the MAC address of the former primary element.This
feature of retaining the base MAC address of the former primary element for a fixed or indefinite period of
time is called MAC Address Retention. In this way, recalculation of protocols, such as Spanning Tree and
Link Aggregation and updation of tables, such as the Address Resolution Protocol (ARP) table for IPv4
routing and the Neighbor Discovery table for IPv6 routing is minimized.
Note. The MAC Retention feature is only supported on the switch that operates in the single MAC mode.
If the primary element does not return to the stack after the elapse of the specified time interval, a trap is
generated, which notifies the administrator of a possible MAC address duplication. The trap and syslog
provide details about the slot number and the base MAC address of the removed former primary element.
Note. The duplication of MAC addresses in the network cannot be prevented in case of simultaneous fail-
ure of stacking links connected to primary stack element.
Note. When the administrative status of MAC retention is enabled, the stack performance is enhanced.
Note. A switch will not be allowed to release the MAC address derived from its EEPROM.
To view the MAC Retention status, use the show mac-retention status command as shown:
-> show mac-retention status
Software Failure
In the following diagram, if the primary element faces a fatal software exception, the MAC Retention
feature will remain enabled and the base MAC address will be retained during takeover.
Primary Element
1 a
2 a
Secondary Element
3 a Switch 1
Idle Element
Stack 1
In the above diagram, when the primary element in Stack 1 fails, the secondary element becomes the new
primary element and shares the MAC address of the former primary element of the stack. In this scenario,
the decision to retain the base MAC address is acceptable. This feature also works well during the
following failures:
• Power failure of the primary element
• Hardware failure of the primary element
Link Failure
In the following diagram, even if both stack links "a" and "b" of the primary element of Stack 1 go down
almost at the same time (removed by the user or actual link failures), the MAC Retention feature will
remain enabled and the base MAC address will be retained during takeover.
1 a Primary Element
2 a
Secondary / New
Primary Element
3 a
Switch 1
Stack 1
Link Failure
In the above diagram, if the links between the primary and the secondary element and the primary and the
idle element fail, the entire stack will split into two separate stacks. The primary element will become an
independent stack, and the new primary element (after takeover) and the new secondary element will form
another separate stack. Both the stacks will share the same base MAC address.This will lead to the dupli-
cation of MAC address because the software running on the elements will not be able to distinguish
between a crash or two link failures.
In the above scenario, although the duplication of MAC address cannot be prevented, the element can be
configured to generate an SNMP trap. If an SNMP trap is generated, the administrator can release the base
MAC address from the stack consisting of the new primary and secondary elements. This stack will use
the base MAC address from the EEPROM of the new primary element of the stack.
Link Layer Discovery Protocol (LLDP) is an emerging standard to provide a solution for the
configuration issues caused by expanding networks. LLDP supports the network management software
used for complete network management. LLDP is implemented as per the IEEE 802.1AB standard. LLDP
specifically defines a standard method for Ethernet network devices to exchange information with its
neighboring devices and maintain a database of the information. The exchanged information passed as
LLDPDU is in TLV (Type, Length, Value) format. The information available to the network management
software must be as new as possible; hence, the remote device information is periodically updated.
The LLDP Agent Security mechanism can be configured manually for secure access to the network by
detecting rogue devices and preventing them from accessing the internal network.
In This Chapter
This chapter describes the basic components of 802.1AB and how to configure them through the
Command Line Interface (CLI). The CLI commands are used in the configuration examples; for more
details about the syntax of commands, see Chapter 13, “802.1AB Commands,” in the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
Configuration procedures described in this chapter include the following:
• “Quick Steps for Configuring 802.1AB” on page 22-4
• “Quick Steps for Configuring LLDP-MED Network Policy” on page 22-5
• “Configuring LLDPDU Flow” on page 22-16.
• “Nearest Bridge/Edge Mode” on page 22-14
• “Enabling and Disabling Notification” on page 22-16.
• “Enabling and Disabling Management TLV” on page 22-17.
• “Enabling and Disabling 802.1 TLV” on page 22-17.
• “Enabling and Disabling 802.3 TLV” on page 22-18.
• “Enabling and Disabling MED TLV” on page 22-18.
• “Setting the Transmit Interval” on page 22-19.
• “Setting the Transmit Hold Multiplier Value” on page 22-19.
• “Setting the Transmit Delay” on page 22-19.
• “Setting the Transmit Fast Start Count” on page 22-19
• “Setting the Transmit Fast Start Count” on page 22-19.
802.1AB Specifications
IEEE Specification IEEE 802.1AB-2005 Station and Media Access
Control Connectivity Discovery
TIA Specifications TIA-1057 - Link Layer Discovery Protocol for
Media Endpoint Devices
Platforms Supported OmniSwitch 6250, 6350, 6450
Transmit time interval for LLDPDUs 5 to 32768 in seconds
Transmit hold multiplier value 2 to 10
Fast start count 1 to 10
Transmit delay 1 to 8192 in seconds
Reinit delay 1 to 10 in seconds
Notification interval 5 to 3600 in seconds
Maximum number of network policies that 8
can be associated with a port
Maximum number of network policies 32
that can be configured on the switch
VLAN ID Range for assigning explicit 1 to 4094
LLDP-MED Network Policy
DSCP range 0 to 63
802.1p priority range 0 to 7
Nearest Bridge MAC Address 01:80:c2:00:00:0e
Nearest Edge MAC Address 01:20:da:02:01:73
2 To control per port notification status about the remote device change on a port, use the
lldp notification command. For example:
-> lldp 2/47 notification enable
3 To control per port management TLV to be incorporated in the LLDPDUs, use the
lldp tlv management command. For example:
-> lldp 2/47 tlv management port-description enable
4 Set the transmit time interval for LLDPDUs. To set the timer for a 50 second delay, use the
lldp transmit interval command. For example:
-> lldp transmit interval 50
5 Set the minimum time interval between successive LDPDUs. To set the interval for a 20 second delay,
use the lldp transmit delay command. For example:
-> lldp transmit delay 20
6 Set the LLDPDUs transmit fast start count required for LLDP Fast Restart mechanism to be activated.
Note. Optional. Verify the LLDP per port statistics by entering the show lldp statistics command. For
example:
-> show lldp statistics
----------+--------------------------------------+---------------------+----------
| LLDPDU | TLV | Device
Slot/Port| Tx Rx Errors Discards | Unknown Discards | Ageouts
----------+--------+----------+----------+----------+----------+----------+-----
1/23 52 0 0 0 0 0 0
2/47 50 50 0 0 0 0 0
2/48 50 50 0 0 0 0 0
To verify the remote system information, use the show lldp remote-system command. For example:
-> show lldp remote-system
Remote LLDP Agents on Local Slot/Port: 2/47,
Chassis ID Subtype = 4 (MAC Address),
Chassis ID = 00:d0:95:e9:c9:2e,
Port ID Subtype = 7 (Locally assigned),
Port ID = 2048,
Port Description = (null),
System Name = (null),
System Description = (null),
Capabilities Supported = none supported,
Capabilities Enabled = none enabled,
For more information about this display, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Note. A VLAN and VPA must be created for LLDP-MED to work on fixed, mobile or 802.1x ports.
However, if the VLAN is not created and the VLAN is added in the LLDP-MED Network Policy, no error
is displayed.
1 Enable the transmission of network policy through a VLAN port using the lldp tlv med command.
Configure the LLDP-MED TLVs to be transmitted through a particular port using this command.
For example:
-> lldp 1/10 tlv med network-policy enable
2 Configure a local network policy on the switch for a specific application type using the
lldp network-policy command. Assign a network policy identifier (ID) to a particular application type
using this command. For example:
-> lldp network-policy 1 application voice vlan 10 l2-priority 5
3 Bind the network policy to the VLAN port using the lldp med network-policy command.
For example:
-> lldp 1/10 med network-policy 1
3 Enable network policy using the lldp tlv med command. Configure LLDP-MED TLVs for a particular
port using this command.
-> lldp 2/10 tlv med network-policy enable
4 Configure a local network policy on the switch for a specific application type using the
lldp network-policy command.
-> lldp network-policy 1 application voice vlan 10 l2-priority 5
5 Bind the network policy to a port associated with a VLAN using the lldp med command.
3 Use the aaa radius-server command to configure the radius server to be used for port authentication.
Configure the radius server to return the VLAN ID for the incoming MAC address of the LLDP device.
-> aaa radius-server rad1 host 10.10.2.1 timeout 25
4 Associate the RADIUS server with authentication for 802.1X ports using the aaa authentication
command.
-> aaa authentication 802.1x rad1
5 Configure the User Network Profile and add a classification rule for the MAC address using the
following command.
-> aaa classification-rule mac-address <mac-address-of-the-lldp-device>
user-network-profile name engineering
6 Enable network policy using the lldp tlv med command. Configure LLDP-MED TLVs for a particular
port using this command.
-> lldp 3/10 tlv med network-policy enable
7 Configure a local network policy on the switch for a specific application type using the lldp network
policy application command.
-> lldp network-policy 1 application voice vlan 10 l2-priority 5
8 Bind the network policy to a port associated with a VLAN using the lldp med command.
If the authentication server returns a VLAN ID, then the client device is assigned to the related VLAN.
Note. Optional. Verify the LLDP network policies enabled with regard to different network policy IDs, by
entering the show lldp network-policy command. For example:
-> show lldp network-policy
To verify the network policies enabled on different slots and ports, use the show lldp med network-policy
command. For example:
For more information about this display, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
802.1AB Overview
LLDP is a Layer 2 protocol for detecting adjacent devices in a network. Each device in a network sends
and receives LLDPDUs through all its ports, when the protocol is enabled. If the protocol is disabled on a
port or on a device, then LLDPDUs received on that port or device are dropped.
The LLDPDUs are transmitted at a certain interval that can be configured. When an LLDPDU is received
from a neighboring device, the LLDPDU software validates the frame and stores the information in its
remote device Management Information Base (MIB). This information is aged periodically, if an
LLDPDU is not received from the same device within the time mentioned in the TTL TLV of the
LLDPDU. By exchanging information with all the neighbors, each device learns its neighbor on each port.
The information within the LLDPDU is transmitted in TLV (Type, Length, Value) format and falls under
two categories:
• Mandatory
• Optional
Each LLDPDU contains all the four mandatory TLVs and optional TLVs.
Mandatory TLVs
The mandatory TLV information contains the MAC service access point (MSAP) identifier and the time
period for the validity of the associated information of the LAN device. The following are the mandatory
TLVs contained in an LLDPDU:
• Chassis ID TLV
• Port ID TLV
• VLAN ID TLV
• Time to live TLV
• End of LLDPDU TLV
Optional TLVs
The optional TLVs defined as part of LLDP are grouped into the following sets listed below:
Basic management TLV set
• Port Description TLV
• System Name TLV
• System Description TLV
• System capabilities TLV
• Management address TLV
Note. This optional TLV set is required for all LLDP implementation.
Note. If one TLV from this set is included in the LLDPDU, then all the TLVs must be included.
mac-phy TLV
When mac-phy is configured the power class detection is done via hardware by the switch’s PoE control-
ler and the maximum power for the port is based on the class of the powered device. Powered devices can
draw up to the maximum amount of power allowed for it’s class without any negotiation with the switch.
power-via-mdi TLV
When power-via-mdi is configured the power for the powered device is negotiated using the optional
power via MDI TLV in the LLDPDU. The powered device can request additional power using the power
via MDI TLV. The switch will check the current PoE budget and if power is available the switch will
provide the requested power to the powered device. If power is unavailable, the switch will respond with
the existing maximum power information.
• Voice Signaling
• Guest Voice
• Guest Voice Signaling
• Soft phone voice
• Video Conferencing
• Streaming voice
• Video Signaling
Aging Time
The LLDP-specific information of the remote system is stored in the LLDP MIB. The TTL TLV carries a
positive value in seconds, and informs the other device as to how long this information is valid. Once a
remote device is learned on a local port, the local device discards that entry from its database if the
receiving device does not receive an LLDPDU from the same remote device and on the same local port
within the TTL mentioned in the previous LLDPDU. This is called the aging time and can be set by the
user.
Configuring 802.1AB
The following sections list detailed procedures to enable 802.1AB, assign ports, network policies to
802.1AB, and configure the LLDP security mechanism for OmniSwitch.
To set the LLDPDU flow on port 4 of slot 3 as receive, enter the following command at the CLI prompt:
-> lldp 3/4 lldpdu rx
To disable the flow of LLDPDU on a switch, enter the lldp lldpdu command, as shown:
-> lldp chassis lldpdu disable
To disable the flow of LLDPDU on port 5 of slot 1, enter the following command at the CLI prompt:
-> lldp 1/5 lldpdu disable
To enable notification on port 2 of slot 1, enter the following command at the CLI prompt:
-> lldp 1/2 notification enable
To disable notification on port 4 of slot 1, enter the following command at the CLI prompt:
-> lldp 1/4 notification disable
To enable the management TLV on port 3 of slot 2, enter the following command at the CLI prompt:
-> lldp 2/3 tlv management system-capabilities enable
To disable the management TLV on a switch, enter the lldp tlv management command, as shown:
-> lldp chassis tlv management port-description disable
To disable management TLV on port 3 of slot 2, enter the following command at the CLI prompt:
-> lldp 2/3 tlv management system-capabilities disable
To enable the 802.1 TLV on port 1 of slot 5, enter the following command at the CLI prompt:
-> lldp 5/1 tlv dot1 vlan-name enable
To disable the 802.1 TLV on a switch, enter the lldp tlv dot1 command, as shown:
-> lldp chassis tlv dot1 port-vlan disable
To disable 802.1 TLV on port 2 of slot 5, enter the following command at the CLI prompt:
-> lldp 5/2 tlv dot1 vlan-name disable
To enable the 802.3 TLV on port 4 of slot 2, enter the following command at the CLI prompt:
-> lldp 2/4 tlv dot3 mac-phy enable
To disable the 802.3 TLV on a switch, enter the lldp tlv dot3 command, as shown:
-> lldp chassis tlv dot3 mac-phy disable
To disable 802.3 TLV on port 5 of slot 3, enter the following command at the CLI prompt:
-> lldp 3/5 tlv dot3 mac-phy disable
To enable the MED TLV on port 4 of slot 4, enter the following command at the CLI prompt:
-> lldp 4/4 tlv med capability enable
To disable the MED TLV on a switch, enter the lldp tlv med command, as shown:
-> lldp chassis tlv med power disable
To disable MED TLV on port 3 of slot 4, enter the following command at the CLI prompt:
-> lldp 4/3 tlv med capability disable
To enable the voice application network policy for a MED TLV on the port 3 of slot 4, enter the
following command at the CLI prompt:
-> lldp 4/3 tlv med network policy 1 enable
To disable a MED TLV voice network policy on the port 3 of slot 4, enter the following command at the
CLI prompt:
Note: The Time To Live is a multiple of the transmit interval and transmit hold-multiplier.
By default, the transmit delay is less than or equal to the multiplication of the transmit interval and 0.25.
Note: In a specified interval, generating more than one notification-event is not possible.
To enable LLDP trust agent at slot number 1, enter the command as shown:
-> lldp 1 trust-agent enable
To enable LLDP trust agent at individual port 3 of slot 1, enter the command as shown:
-> lldp 1/3 trust-agent enable
The chassis ID subtype is configured to validate the remote agent as a trust agent. To set the
chassis-id-subtype for the LLDP trust agent globally at chassis level as chassis-component, enter the lldp
trust-agent command as shown:
-> lldp chassis trust-agent chassis-id-subtype chassis-component
To set the chassis-id-subtype for the LLDP trust agent on the individual port 3 of slot 1 as
port-component, enter the lldp trust-agent command as shown:
-> lldp 1/3 trust-agent chassis-id-subtype port-component
Note. By default, the first remote agent with any chassis ID sub type is accepted as a trust agent, if no
chassis-id-subtype component is specified to validate the remote agent.
To set the action to be performed when a violation is detected globally at the chassis level, use the
lldp trust-agent violation-action command as shown:
-> lldp chassis trust-agent violation-action trap-and-shutdown
To set the action to be performed when a violation is detected at the individual slot level, use the
lldp trust-agent violation-actioncommand as shown:
-> lldp 1 trust-agent violation-action shutdown
Note. For further details on verifying LLDP configuration and trust agent information, see “Verifying
802.1AB Configuration” on page 22-21.
Note.
The show lldp trust-agent command is used to verify the LLDP security configuration. When LLDP
security is disabled, the show lldp trust-agent command displays the Admin Status as Disabled for all
the ports. However, default values are displayed for the output fields - Violation Action as Trap only, the
Violation Status as Trusted, and Chassis ID Subtype as 8 (Any).
Example
For more information about the resulting display, see Chapter 13, “802.1AB Commands,” in the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
Alcatel Interswitch Protocol (AIP) is used to discover adjacent switches in the network. The following
protocol is supported:
Alcatel Mapping Adjacency Protocol (AMAP), which is used to discover the topology of OmniSwitches
and Omni Switch/Router (Omni S/R). See “AMAP Overview” on page 23-3.
This protocol is described in detail in this chapter.
In This Chapter
This chapter describes the AMAP protocol and how to configure it through the Command Line Interface
(CLI). CLI commands are used in the configuration examples; for more details about the syntax of
commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Activating AMAP on page 23-5.
• Configuring the AMAP discovery time-out interval on page 23-5.
• Configuring the AMAP common time-out interval on page 23-6.
For information about statically and dynamically assigning switch ports to VLANs, see Chapter 7,
“Assigning Ports to VLANs.”
For information about defining VLAN rules that allow dynamic assignment of mobile ports to a VLAN,
see Chapter 9, “Defining VLAN Rules.”
AIP Specifications
Standards Not applicable at this time. AMAP is an Alcatel propri-
etary protocol.
Platforms Supported OmniSwitch 6250, 6350, 6450
Maximum number of IP addresses 255
propagated by AMAP
AMAP Defaults
Parameter Description Command Default
AMAP status amap Enabled
Discovery time interval amap discovery time 30 seconds
Common time interval amap common time 300 seconds
AMAP Overview
The Alcatel Mapping Adjacency Protocol (AMAP) is used to discover the topology of OmniSwitches in a
particular installation. Using this protocol, each switch determines which OmniSwitches are adjacent to it
by sending and responding to Hello update packets. For the purposes of AMAP, adjacent switches are
those that:
• have a Spanning Tree path between them
• do not have any switch between them on the Spanning Tree path that has AMAP enabled
In the illustration here, all switches are on the Spanning Tree path. OmniSwitch A and OmniSwitch C
have AMAP enabled. OmniSwitch B does not. OmniSwitch A is adjacent to OmniSwitch C and vice
versa. If OmniSwitch B enables AMAP, the adjacency changes. OmniSwitch A would be next to OmniS-
witch B, B would be adjacent to both A and C, and C would be adjacent to B.
Note. All Hello packet transmissions are sent to a well-known MAC address (0020da:007004).
No
Yes Any No
Hello packet received Common Hello packet
before discovery Transmission State received?
time-out interval?
Configuring AMAP
AMAP is active by default. In addition to disabling or enabling AMAP, you can view a list of adjacent
switches or configure the time-out intervals for Hello packet transmission and reception.
Note. Ports in the common transmission state send out Hello packets based on the common time-out inter-
val described later.
The discovery time-out interval is set to 30 seconds by default. To display the current discovery time-out
interval, enter the following command:
-> show amap
To change the discovery time-out interval, use either of these forms of the command with the desired
value (any value between 1 and 65535). Note that the use of the time command keyword is optional. For
example:
-> amap discovery 60
-> amap discovery time 60
Note. Switches avoid synchronization by jittering the common time-out interval plus or minus 10 percent
of the configured value. For example, if the default common time-out interval is used (300 seconds), the
jitter is plus or minus 30 seconds.
When a Hello packet is received from an adjacent switch before the common time-out interval expires, the
switch sends a Hello reply and restarts the common transmission timer.
The common time-out interval is set to 300 seconds by default. To display the current common time-out
interval, enter the following command:
-> show amap
To change the common time-out interval, use either of these forms of the command with the desired value
(any value between 1 and 65535). Note that the use of the time command keyword is optional. For exam-
ple:
-> amap common 600
-> amap common time 600
AMAP:
Operational Status = enabled,
Common Phase Timeout Interval (seconds) = 300,
Discovery Phase Timeout Interval (seconds) = 30
Remote Host ‘OmniSwitch B’ On Port 4/1 Vlan 1:
Remote Device = OS6250,
Remote Base MAC = 00:20:da:03:2c:40,
Remote Interface = 2/1,
Remote VLAN = 1,
Number of Remote IP Address(es) Configured = 4,
Remote IP(s) =
18.1.1.1
27.0.0.2
192.168.10.1
192.206.184.40
Remote OmniSwitch
Remote interface 2/1 B
OmniSwitch A (local)
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for information about the show amap
command.
802.1Q is the IEEE standard for segmenting networks into VLANs. 802.1Q segmentation is done by
adding a specific tag to a packet.
In this Chapter
This chapter describes the basic components of 802.1Q VLANs and how to configure them through the
Command Line Interface (CLI). The CLI commands are used in the configuration examples; for more
details about the syntax of commands, see “802.1Q Commands” in the OmniSwitch 6250/6350/6450 CLI
Reference Guide.
Configuration procedures described in this chapter include:
• Setting up an 802.1Q VLAN for a specific port. See “Enabling Tagging on a Port” on page 24-5.
• Setting up an 802.1Q VLAN for a link aggregation group. See “Enabling Tagging with Link Aggrega-
tion” on page 24-5.
• Configuring 802.1Q VLAN parameters. See “Configuring the Frame Type” on page 24-6.
For information on creating and managing VLANs, see Chapter 4, “Configuring VLANs.”
For information on creating and managing link aggregation groups, see Chapter 25, “Configuring Static
Link Aggregation” and Chapter 26, “Configuring Dynamic Link Aggregation.”
802.1Q Specifications
IEEE Specification Draft Standard P802.1Q/D11 IEEE Standards for
Local And Metropolitan Area Network: Virtual
Bridged Local Area Networks, July 30, 1998
Platforms Supported OmniSwitch 6250, 6350, 6450
Maximum Tagged VLANs per Port 4093
Maximum Untagged VLANs per Port One untagged VLAN per port.
Maximum VLAN Port Associations (VPA) 32768
per switch
Maximum 802.1Q VLAN port associations 2500
per switch
Force Tag Internal Not configurable on the OmniSwitch 6250, 6350,
6450.
Note. Up to 4093 VLANs can be assigned to a tagged port or link aggregation group. However, each
assignment counts as a single VLAN port association. Once the maximum number of VLAN port
associations is reached, no more VLANs can be assigned to ports. For more information, see the chapter
titled Chapter 7, “Assigning Ports to VLANs.”
802.1Q Overview
Alcatel’s 802.1Q is an IEEE standard for sending frames through the network tagged with VLAN identifi-
cation. This chapter details procedures for configuring and monitoring 802.1Q tagging on a single port in a
switch or a link aggregation group in a switch.
802.1Q tagging is the IEEE version of VLANs. It is a method for segregating areas of a network into
distinct VLANs. By attaching a label or tag to a packet, the packet can be identified as being from a
specific area or identified as being destined for a specific area.
When enabling a tagged port, you will also need to specify whether only 802.1Q tagged traffic is allowed
on the port, or whether the port accepts both tagged and untagged traffic.
“Tagged” refers to four bytes of reserved space in the header of the packet. The four bytes of “tagging” are
broken down as follows: the first two bytes indicate whether the packet is an 802.1Q packet, and the next
two bytes carry the VLAN identification (VID) and priority.
On the ingress side, packets are classified in a VLAN. After classifying a packet, the switch adds an
802.1Q header to the packet. Egress processing of packets is done by the switch hardware. Packets have an
802.1Q tag, which may be stripped off based on 802.1Q tagging/stripping rules.
If a port is configured to be a tagged port, then all the untagged traffic (including priority tagged or VLAN
0 traffic) received on the port will be dropped. You do not need to reboot the switch after changing the
configuration parameters.
Note. Priority tagged traffic or traffic from VLAN 0 is used for Quality of Service (QoS) functionality.
802.1Q views priority tagged traffic as untagged traffic.
Mobile ports can be configured to accept 802.1Q traffic by enabling the VLAN mobile tagging feature as
described in Chapter 4, “Configuring VLANs.”
The following diagram illustrates a simple network by using tagged and untagged traffic:
VLAN 1 VLAN 1
untagged untagged
Stack 1 Stack 2
port 4/3
VLAN 2 tagged VLAN 2
tagged port 2/1 tagged
tagged/
untagged
VLAN 3 VLAN 3
tagged tagged
Stack 1 and 2 have three VLANs, one for untagged traffic and two for tagged traffic. The ports connecting
Stack 1 and 2 are configured in such a manner that Port 4/3 will only accept tagged traffic, while Port 2/1
will accept both tagged and untagged traffic.
The port can only be assigned to one untagged VLAN (in every case, this will be the default VLAN). In
the example above the default VLAN is VLAN 1. The port can be assigned to as many 802.1Q VLANs as
necessary, up to 4093 per port or 32768 VLAN port associations.
For the purposes of Quality of Service (QoS), 802.1Q ports are always considered to be trusted ports. For
more information on QoS and trusted ports, see Chapter 39, “Configuring QoS.”
Alcatel’s 802.1Q tagging is done at wire speed, providing high-performance throughput of tagged
frames.The procedures below use CLI commands that are thoroughly described in “802.1Q Commands” of
the OmniSwitch 6250/6350/6450 CLI Reference Guide.
The tagged port would now also be labeled port tag. Note that you must use quotes around the text
description.
The VLAN used to handle traffic on the tagged port must be created prior to using the vlan 802.1q
command. Creating a VLAN is described in Chapter 4, “Configuring VLANs.”
For more specific information, see the vlan 802.1q command section in the OmniSwitch 6250/6350/6450
CLI Reference Guide.
(For further information on creating link aggregation groups, see Chapter 25, “Configuring Static Link
Aggregation,” or Chapter 26, “Configuring Dynamic Link Aggregation.”)
To add tagging to a port or link aggregation group and label it with a text name enter the text identifica-
tion following the slot and port number or link aggregation group identification number. For example, to
enable tagging on link aggregation group 8 with a text name of agg port tag, enter the command in the
following manner:
-> vlan 5 802.1q 8 “agg port tag”
The tagged port would now also be labeled agg port tag. Note that you must use quotes around the text
description.
To remove 802.1Q tagging from a selected port, use the same command as above with a no keyword
added, as shown:
-> vlan 5 no 802.1q 8
Note. The link aggregation group must be created first before it can be set to use 802.1Q tagging
For more specific information, see the vlan 802.1q command section in the OmniSwitch 6250/6350/6450
CLI Reference Guide.
To configure a port back to accepting both tagged and untagged traffic, use the same command with the all
keyword, as shown:
-> vlan 802.1q 3/4 frame type all
Note. If you configure a port to accept only VLAN-tagged frames, then any frames received on this port
that do not carry a VLAN identification (i.e., untagged frames or priority-tagged frames) will be discarded
by the ingress rules for this port. Frames that are not discarded by this ingress rule are classified and
processed according to the ingress rules for this port.
When a port is set to support both tagged and untagged traffic, multiple VLANs for 802.1Q traffic can be
added to the port, but only one VLAN can be used to support untagged traffic. The untagged traffic VLAN
will always be the port’s default VLAN.
Note. You cannot configure a link aggregation group to accept only tagged frames.
For more specific information, see the vlan 802.1q frame type command section in the OmniSwitch 6250/
6350/6450 CLI Reference Guide.
Application Example
In this section the steps to create 802.1Q connections between switches are shown.
The following diagram shows a simple network employing 802.1Q on both regular ports and link aggrega-
tion groups.
VLAN 1
Switch 2
(untagged)
VLAN 1 Stack 1
(untagged) Port 2/1
(tagged) VLAN 2
(tagged)
Port 1/1
VLAN 2
(untagged/
(tagged) tagged)
Ports VLAN 3
3/1, 3/2 (tagged)
Aggregate
Link 5
Ports
4/1, 4/2
VLAN 1
(untagged)
Stack 3
VLAN 3
(tagged)
The following sections show how to create the network illustrated above.
1 Create VLAN 2 by entering vlan 2 as shown below (VLAN 1 is the default VLAN for the switch):
-> vlan 2
2 Set port 1/1 as a tagged port and assign it to VLAN 2 by entering the following:
The following steps apply to Switch 2. They will attach port 2/1 to VLAN 2 and set the port to accept
802.1Q tagged traffic only:
1 Create VLAN 2 by entering vlan 2 as shown below (VLAN 1 is the default VLAN for the switch):
-> vlan 2
2 Set port 2/1 as a tagged port and assign it to VLAN 2 by entering the following:
3 Set port 2/1 to accept only tagged traffic by entering the following:
2 Assign ports 3/1 and 3/2 to static aggregate VLAN 5 by entering the following two commands:
-> vlan 3
4 Configure 802.1Q tagging with a tagging ID of 3 on link aggregation group 5 (on VLAN 3) by enter-
ing vlan 3 802.1q 5 as shown below:
-> vlan 3 802.1q 5
The following steps apply to Stack 3. They will attach ports 4/1 and 4/2 as link aggregation group 5 to
VLAN 3.
1 Configure static link aggregation group 5 by entering the following:
2 Assign ports 4/1 and 4/2 to static link aggregation group 5 by entering the following two commands:
-> vlan 3
4 Configure 802.1Q tagging with a tagging ID of 3 on static link aggregation group 5 (on VLAN 3) by
entering the following:
-> vlan 3 802.1q 5
show 802.1q Displays 802.1Q tagging information for a single port or a link aggrega-
tion group.
For more information about the resulting display, see Chapter 15, “802.1Q Commands,” in the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
Alcatel static link aggregation software allows you to combine several physical links into one large virtual
link known as a link aggregation group. Using link aggregation provides the following benefits:
• Scalability. It is possible to configure up to 32 link aggregation groups (128 groups on chassis-based
switches) that consist of 2, 4, or 8 10-Mbps, 100-Mbps, 1-Gbps, or 10-Gbps Ethernet links.
• Reliability. If one of the physical links in a link aggregate group goes down (unless it is the last one)
the link aggregate group can still operate.
• Ease of Migration. Link aggregation can ease the transition from 100-Mbps Ethernet backbones to
Gigabit Ethernet backbones.
In This Chapter
This chapter describes the basic components of static link aggregation and how to configure them through
the Command Line Interface (CLI). CLI commands are used in the configuration examples; for more
details about the syntax of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Configuring static link aggregation groups on page 25-7.
• Adding and deleting ports from a static aggregate group on page 25-9.
Note. You can also configure and monitor static link aggregation with WebView, Alcatel embedded web-
based device management application. WebView is an interactive and easy-to-use GUI that can be
launched from OmniVista or a web browser. Refer to WebView Online documentation for more informa-
tion on configuring and monitoring static link aggregation with WebView.
1 Create the static aggregate link on the local switch with the static linkagg size command. For example:
2 Assign all the necessary ports with the static agg agg num command. For example:
3 Create a VLAN for this static link aggregate group with the vlan command. For example:
4 Create the equivalent static aggregate link on the remote switch with the static linkagg size command.
For example:
-> static linkagg 1 size 4
5 Assign all the necessary ports with the static agg agg num command. For example:
6 Create a VLAN for this static link aggregate group with the vlan command. For example:
Note. Optional. You can verify your static link aggregation settings with the show linkagg command. For
example:
-> show linkagg 1
Static Aggregate
SNMP Id : 40000001,
Aggregate Number : 1,
SNMP Descriptor : Omnichannel Aggregate Number 1 ref 40000001 size 4,
Name : ,
Admin State : ENABLED,
Operational State : UP,
Aggregate Size : 4,
Number of Selected Ports : 4,
Number of Reserved Ports : 4,
Number of Attached Ports : 4,
Primary Port : 1/1
You can also use the show linkagg port port command to display information on specific ports. See
“Displaying Static Link Aggregation Configuration and Statistics” on page 25-12 for more information on
the show commands.
An example of what these commands look like entered sequentially on the command line on the local
switch:
-> static linkagg 1 size 4
-> static agg 1/1 agg num 1
-> static agg 1/2 agg num 1
-> static agg 1/3 agg num 1
-> static agg 1/4 agg num 1
-> vlan 10 port default 1
And an example of what these commands look like entered sequentially on the command line on the
remote switch:
-> static linkagg 1 size 4
-> static agg 1/9 agg num 1
-> static agg 1/10 agg num 1
-> static agg 1/11 agg num 1
-> static agg 1/12 agg num 1
-> vlan 10 port default 1
This chapter describes static link aggregation. For information on dynamic link aggregation, please refer
to Chapter 26, “Configuring Dynamic Link Aggregation.”
Note. Static aggregate groups cannot be created between an OmniSwitch and some switches from other
vendors.
The figure below shows a static aggregate group that has been configured between Switch A and Switch
B. The static aggregate group links four ports on a single OS9-GNI-C24 on Switch A to two ports on one
OS9-GNI-C24 and two ports on another OS9-GNI-C24 on Switch B. The network administrator has
created a separate VLAN for this group so users can use this high speed link.
Switch A Switch B
Static Group
Example of a Static Link Aggregate Group Network
See “Configuring Static Link Aggregation Groups” on page 25-7 for information on using Command Line
Interface (CLI) commands to configure static aggregate groups and see “Displaying Static Link Aggrega-
tion Configuration and Statistics” on page 25-12 for information on using CLI to monitor static aggregate
groups.
• 802.1Q. For more information on configuring and monitoring 802.1Q see Chapter 24, “Configuring
802.1Q.”
• Spanning Tree. For more information on Spanning Tree see Chapter 25, “Configuring Static Link
Aggregation.”
Note. See “Application Example” on page 25-11 for tutorials on using link aggregation with other
features.
Note. See “Quick Steps for Configuring Static Link Aggregation” on page 25-3 for a brief tutorial on
configuring these mandatory parameters.
Alcatel link aggregation software is preconfigured with the default values for static aggregate groups as
shown in the table in “Static Link Aggregation Default Values” on page 25-2. If you need to modify any
of these parameters, please see “Modifying Static Aggregation Group Parameters” on page 25-10 for more
information.
Note. See the “Link Aggregation Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Reference
Guide for complete documentation of CLI commands for link aggregation.
1 Create the Static Aggregate Group on the Local and Remote Switches. To create a static aggregate
group use the static linkagg size command, which is described in “Creating and Deleting a Static Link
Aggregate Group” on page 25-8.
2 Assign Ports on the Local and Remote Switches to the Static Aggregate Group. To assign ports to
the static aggregate group you use the static agg agg num command, which is described in “Adding and
Deleting Ports in a Static Aggregate Group” on page 25-9.
Note. Depending on the needs of your network you can need to configure additional parameters.
Commands to configure optional static aggregate parameters are described in “Modifying Static Aggrega-
tion Group Parameters” on page 25-10.
Note. The number of links assigned to a static aggregate group must always be close to the number of
physical links that you plan to use. For example, if you are planning to use 2 physical links you must
create a group with a size of 2 and not 4 or 8.
As an option you can also specify a name and/or the administrative status of the group by entering static
linkagg followed by the user-specified aggregate number, size, the number of links in the static aggregate
group, name, the optional name (which can be up to 255 characters long), admin state, and either enable
or disable (the default is enable).
For example, to create static aggregate group 5 called “static1” consisting of eight links that is administra-
tively disabled enter:
-> static linkagg 5 size 8 name static1 admin state disable
Note. If you want to specify spaces within a name for a static aggregate group the name must be specified
within quotes (for example, “Static Aggregate Group 5”).
Note. You must delete any attached ports with the static agg agg num command before you can delete a
static link aggregate group.
Note. A port can belong to only one aggregate group. In addition, mobile ports cannot be aggregated. See
Chapter 7, “Assigning Ports to VLANs,” for more information on mobile ports.
As an option, you can use the ethernet, fastethernet, and gigaethernet keywords before the slot and port
number to document the interface type or make the command look consistent with early-generation
Alcatel CLI syntax. For example, to assign port 1 in slot 1 to static aggregate group 10 and document that
port 1 in slot 5 is a Giga Ethernet port you would enter:
-> static gigaethernet agg 1/1 agg num 10
Note. The ethernet, fastethernet, and gigaethernet keywords do not modify a port configuration. See
Chapter 25, “Configuring Static Link Aggregation,” for information on configuring Ethernet ports.
Ports must be deleted in the reverse order in which they were assigned. For example, if port 9 through 16
were assigned to static aggregate group 2 you must first delete port 16, then port 15, and so forth. The
following is an example of how to delete ports in the proper sequence from the console:
-> static agg no 1/24
-> static agg no 1/23
-> static agg no 1/22
• Static aggregate group administrative state (see “Modifying the Static Aggregate Group Administra-
tive State” on page 25-10)
Note. If you want to specify spaces within a name for a static aggregate group the name must be specified
within quotes (for example, “Static Aggregate Group 4”).
Application Example
Static link aggregation groups are treated by the switch software the same way it treats individual physi-
cal ports. This section demonstrates this by providing a sample network configuration that uses static link
aggregation along with other software features. In addition, a tutorial is provided that shows how to
configure this sample network using Command Line Interface (CLI) commands.
The figure below shows VLAN 8, which has been configured on static aggregate 1 and uses 802.1Q
tagging. The actual physical links connect ports 4/1, 4/2, 4/3, and 4/4 on Switch A to port 2/41, 2/42, 2/43,
and 2/44 on Switch B.
Switch A Switch B
Note. Only the steps to configure the local (Switch A) switch are provided here since the steps to config-
ure the remote (Switch B) switch would not be significantly different.
1 Configure static aggregate group 1 by entering static linkagg 1 size 4 as shown below:
2 Assign ports 4/1, 4/2, 4/3, and 4/4 to static aggregate group 1 by entering:
-> vlan 8
4 Configure 802.1Q tagging with a tagging ID of 8 on static aggregate group 1 (on VLAN 8) by enter-
ing:
-> vlan 8 802.1q 1
5 Repeat steps 1 through 4 on Switch B. All the commands would be the same except you would substi-
tute the appropriate port numbers.
Note. Optional. Use the show 802.1q command to display 802.1Q configurations.
When you use the show linkagg command without specifying the link aggregation group number and
when you use the show linkagg port command without specifying the slot and port number these
commands provide a “global” view of switch-wide link aggregate group and link aggregate port informa-
tion, respectively.
For example, to display global statistics on all link aggregate groups (both static and dynamic) you would
enter:
-> show linkagg
When you use the show linkagg command with the link aggregation group number and when you use the
show linkagg port command with the slot and port number these commands provide detailed views of
link aggregate group and link aggregate port information, respectively. These detailed views provide
excellent tools for diagnosing and troubleshooting problems.
For example, to display detailed statistics for port 1 in slot 4 that is attached to static link aggregate group
1 you would enter:
-> show linkagg port 4/1
Note. See the “Link Aggregation Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Reference
Guide for complete documentation of show commands for link aggregation.
Alcatel dynamic link aggregation software allows you to combine several physical links into one large
virtual link known as a link aggregation group. Using link aggregation provides the following
benefits:
• Scalability. It is possible to configure up to 32 link aggregation groups (128 groups on chassis-based
switches) that consist of 2, 4, or 8 10-Mbps, 100-Mbps, 1-Gbps, or 10-Gbps Ethernet links.
• Reliability. If one of the physical links in a link aggregate group goes down (unless it is the last one)
the link aggregate group can still operate.
• Ease of Migration. Link aggregation can ease the transition from 100-Mbps Ethernet backbones to
Gigabit Ethernet backbones.
In This Chapter
This chapter describes the basic components of dynamic link aggregation and how to configure them
through the Command Line Interface (CLI). CLI commands are used in the configuration examples; for
more details about the syntax of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Configuring dynamic link aggregation groups on page 26-9.
• Configuring ports so they can be aggregated in dynamic link aggregation groups on page 26-11.
Note. You can also configure and monitor dynamic link aggregation with WebView, Alcatel embedded
Web-based device management application. WebView is an interactive and easy-to-use GUI that can be
launched from OmniVista or a Web browser. Please refer to WebView Online
documentation for more information on configuring and monitoring dynamic link aggregation with
WebView.
1 Create the dynamic aggregate group on the local (actor) switch with the lacp linkagg size command as
shown below:
-> lacp linkagg 2 size 8 actor admin key 5
2 Configure ports (the number of ports should be less than or equal to the size value set in step 1) with
the same actor administrative key (which allows them to be aggregated) with the lacp agg actor admin
key command. For example:
-> lacp agg 1/1 actor admin key 5
-> lacp agg 1/4 actor admin key 5
-> lacp agg 3/3 actor admin key 5
-> lacp agg 5/4 actor admin key 5
-> lacp agg 6/1 actor admin key 5
-> lacp agg 6/2 actor admin key 5
-> lacp agg 7/3 actor admin key 5
-> lacp agg 8/1 actor admin key 5
3 Create a VLAN for this dynamic link aggregate group with the vlan command. For example:
4 Create the equivalent dynamic aggregate group on the remote (partner) switch with the lacp linkagg
size command as shown below:
-> lacp linkagg 2 size 8 actor admin key 5
5 Configure ports (the number of ports should be less than or equal to the size value set in step 4) with
the same actor administrative key (which allows them to be aggregated) with the lacp agg actor admin
key command. For example:
-> lacp agg 2/1 actor admin key 5
-> lacp agg 3/1 actor admin key 5
-> lacp agg 3/3 actor admin key 5
-> lacp agg 3/6 actor admin key 5
-> lacp agg 5/1 actor admin key 5
-> lacp agg 5/6 actor admin key 5
-> lacp agg 8/1 actor admin key 5
-> lacp agg 8/3 actor admin key 5
6 Create a VLAN for this dynamic link aggregate group with the vlan command. For example:
Note. As an option, you can verify your dynamic aggregation group settings with the show linkagg
command on either the actor or the partner switch. For example:
-> show linkagg 2
Dynamic Aggregate
SNMP Id : 40000002,
Aggregate Number : 2,
SNMP Descriptor : Dynamic Aggregate Number 2 ref 40000002 size 8,
Name : ,
Admin State : ENABLED,
Operational State : UP,
Aggregate Size : 8,
Number of Selected Ports : 8,
Number of Reserved Ports : 8,
Number of Attached Ports : 8,
Primary Port : 1/1,
LACP
MACAddress : [00:1f:cc:00:00:00],
Actor System Id : [00:20:da:81:d5:b0],
Actor System Priority : 0,
Actor Admin Key : 5,
Actor Oper Key : 0,
Partner System Id : [00:20:da:81:d5:b1],
Partner System Priority : 0,
Partner Admin Key : 5,
Partner Oper Key : 0
You can also use the show linkagg port port command to display information on specific ports. See
“Displaying Dynamic Link Aggregation Configuration and Statistics” on page 26-33 for more
information on show commands.
An example of what these commands look like entered sequentially on the command line on the actor
switch:
-> lacp linkagg 2 size 8 actor admin key 5
-> lacp agg 1/1 actor admin key 5
-> lacp agg 1/4 actor admin key 5
-> lacp agg 3/3 actor admin key 5
-> lacp agg 5/4 actor admin key 5
-> lacp agg 6/1 actor admin key 5
-> lacp agg 6/2 actor admin key 5
-> lacp agg 7/3 actor admin key 5
-> lacp agg 8/1 actor admin key 5
-> vlan 2 port default 2
An example of what these commands look like entered sequentially on the command line on the partner
switch:
-> lacp linkagg 2 size 8 actor admin key 5
-> lacp agg 2/1 actor admin key 5
-> lacp agg 3/1 actor admin key 5
-> lacp agg 3/3 actor admin key 5
-> lacp agg 3/6 actor admin key 5
-> lacp agg 5/1 actor admin key 5
-> lacp agg 5/6 actor admin key 5
-> lacp agg 8/1 actor admin key 5
This chapter describes dynamic link aggregation. For information on static link aggregation, please refer to
Chapter 9, “Configuring Static Link Aggregation.”
Dynamic Group
Dynamic aggregate groups can be created between each of the following OmniSwitch products:
• two OmniSwitch 6250, 6450 switches.
• an OmniSwitch 6250, 6450 switch and another vendor switch if that vendor supports IEEE 802.3ad
LACP.
See “Configuring Dynamic Link Aggregate Groups” on page 26-9 for information on using Command
Line Interface (CLI) commands to configure dynamic aggregate groups and see “Displaying Dynamic
Link Aggregation Configuration and Statistics” on page 26-33 for information on using the CLI to
monitor dynamic aggregate groups.
• 802.1Q. For more information on configuring and monitoring 802.1Q, see Chapter 6, “Configuring
802.1Q.”
• Spanning Tree. For more information on Spanning Tree, see Chapter 5, “Configuring Spanning Tree
Parameters.”
• Edge Feature - LACP WTR Delay on Bootup. For more information on WTR timer, see “Edge
Feature - LACP WTR Delay on Bootup” on page 10-28
Note. See “Application Examples” on page 26-29 for tutorials on using link aggregation with other
features.
Note. See “Quick Steps for Configuring Dynamic Link Aggregation” on page 26-4 for a brief tutorial on
configuring these mandatory parameters.
Alcatel link aggregation software is preconfigured with the default values for dynamic aggregate groups
and ports shown in the table in “Dynamic Link Aggregation Default Values” on page 26-3. For most
configurations, using only the steps described in “Creating and Deleting a Dynamic Aggregate Group” on
page 26-10 will be necessary to configure a dynamic link aggregate group. However, if you need to
modify any of the parameters listed in the table on page 26-3, please see “Modifying Dynamic Link
Aggregate Group Parameters” on page 26-13 for more information.
Note. See the “Link Aggregation Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Reference
Guide for complete documentation of show commands for link aggregation.
1 Create the Dynamic Aggregate Groups on the Local (Actor) and Remote (Partner) Switches. To
create a dynamic aggregate group use the lacp linkagg size command, which is described in “Creating
and Deleting a Dynamic Aggregate Group” on page 26-10.
2 Configure the Same Administrative Key on the Ports You Want to Join the Dynamic Aggregate
Group. To configure ports with the same administrative key (which allows them to be aggregated), use
the lacp agg actor admin key command, which is described in “Configuring Ports to Join and Removing
Ports in a Dynamic Aggregate Group” on page 26-11.
Note. Depending on the needs of your network you may need to configure additional parameters.
Commands to configure optional dynamic link aggregate parameters are described in “Modifying
Dynamic Link Aggregate Group Parameters” on page 26-13.These commands must be executed after you
create a dynamic aggregate group.
You can create up to 32 link aggregation (both static and dynamic) groups for a standalone switch or a
stack of switches and up to 128 groups for a chassis-based switch. In addition, you can also specify
optional parameters shown in the table below. These parameters must be entered after size and the
user-specified number of links.
For example, Alcatel recommends assigning the actor admin key when you create the dynamic aggregate
group to help ensure that ports are assigned to the correct group. To create a dynamic aggregate group with
aggregate number 3 consisting of two ports with an admin actor key of 10, for example, enter:
-> lacp linkagg 3 size 2 actor admin key 10
Note. The optional keywords for this command may be entered in any order as long as they are entered
after size and the user-specified number of links.
Note. You cannot delete a dynamic aggregate group if it has any attached ports. To remove attached ports
you must disable the dynamic aggregate group with the lacp linkagg admin state command, which is
described in “Disabling a Dynamic Aggregate Group” on page 26-14.
Note. A port may belong to only one aggregate group. In addition, mobile ports cannot be aggregated. See
Chapter 5, “Assigning Ports to VLANs,” for more information on mobile ports.
You must execute the lacp agg actor admin key command on all ports in a dynamic aggregate group. If
not, the ports will be unable to join the group.
In addition, you can also specify optional parameters shown in the table below. These keywords must be
entered after the actor admin key and the user-specified actor administrative key value.
Note. The actor admin state and partner admin state keywords have additional parameters, which are
described in “Modifying the Actor Port System Administrative State” on page 26-18 and “Modifying the
Partner Port System Administrative State” on page 26-22, respectively.
All of the optional keywords listed above for this command may be entered in any order as long as they
appear after the actor admin key keywords and their user-specified value.
For example, to configure actor administrative key of 10, a local system ID (MAC address) of
00:20:da:06:ba:d3, and a local priority of 65535 to slot 4 port 1, enter:
-> lacp agg 4/1 actor admin key 10 actor system id 00:20:da:06:ba:d3 actor
system priority 65535
As an option, you can use the ethernet, fastethernet, and gigaethernet keywords before the slot and port
number to document the interface type or make the command look consistent with early-generation
Alcatel CLI syntax. For example, to configure an actor administrative key of 10 and to document that the
port is a 10-Mbps Ethernet port to slot 4 port 1, enter:
-> lacp agg ethernet 4/1 actor admin key 10
Note. The ethernet, fastethernet, and gigaethernet keywords do not modify a port configuration. See
Chapter 1, “Configuring Ethernet Ports,” for information on configuring Ethernet ports.
Ports must be deleted in the reverse order in which they were configured. For example, if port 9 through
16 were configured to join dynamic aggregate group 2 you must first delete port 16, then port 15, and so
forth. The following is an example of how to delete ports in the proper sequence from the console:
-> lacp agg no 4/24
-> lacp agg no 4/23
-> lacp agg no 4/22
Note. You must create a dynamic aggregate group before you can modify group or port parameters. See
“Configuring Dynamic Link Aggregate Groups” on page 26-9 for more information.
• Group administrative state (see “Modifying the Dynamic Aggregate Group Administrative State” on
page 26-14)
• Group local (actor) switch actor administrative key (see “Configuring and Deleting the Dynamic
Aggregate Group Actor Administrative Key” on page 26-15)
• Group local (actor) switch system priority (see “Modifying the Dynamic Aggregate Group Actor
System Priority” on page 26-15)
• Group local (actor) switch system ID (see “Modifying the Dynamic Aggregate Group Actor System
ID” on page 26-16)
• Group remote (partner) administrative key (see “Modifying the Dynamic Aggregate Group Partner
Administrative Key” on page 26-16)
• Group remote (partner) system priority (see “Modifying the Dynamic Aggregate Group Partner System
Priority” on page 26-17)
• Group remote (partner) switch system ID (see “Modifying the Dynamic Aggregate Group Partner
System ID” on page 26-17)
Note. If you want to specify spaces within a name, the name must be enclosed in quotes. For example:
-> lacp linkagg 4 name "Engineering Lab"
• Actor port system priority (see “Modifying the Actor Port System Priority” on page 26-20)
• Actor port priority (see “Modifying the Actor Port Priority” on page 26-21)
Note. See “Configuring Ports to Join and Removing Ports in a Dynamic Aggregate Group” on page 26-11
for information on modifying a dynamic aggregate group administrative key.
All of the commands to modify actor port parameters allow you to add the ethernet, fastethernet, and
gigaethernet keywords before the slot and port number to document the interface type or make the
command look consistent with early-generation Alcatel CLI syntax. However, these keywords do not
modify a port configuration. See Chapter 1, “Configuring Ethernet Ports,” for information on configuring
Ethernet ports.
Note. A port may belong to only one aggregate group. In addition, mobile ports cannot be aggregated. See
Chapter 5, “Assigning Ports to VLANs,” for more information on mobile ports.
Note. Specifying none removes all administrative states from the LACPDU configuration. For example:
-> lacp agg 5/49 actor admin state none
For example, to set bits 0 (active) and 2 (aggregate) on dynamic aggregate actor port 49 in slot 5 you
would enter:
-> lacp agg 5/49 actor admin state active aggregate
As an option you can use the ethernet, fastethernet, and gigaethernet keywords before the slot and port
number to document the interface type or make the command look consistent with early-generation
Alcatel CLI syntax. For example, to set bits 0 (active) and 2 (aggregate) on dynamic aggregate actor port
49 in slot 5 and document that the port is a Gigabit Ethernet port you would enter:
-> lacp agg gigaethernet 5/49 actor admin state active aggregate
Note. Since individual bits with the LACPDU frame are set with the lacp agg actor admin state
command you can set some bits on and restore other bits within the same command. For example, if you
wanted to restore bit 2 (aggregate) to its default settings and set bit 0 (active) on dynamic aggregate actor
port 49 in slot 5 you would enter:
-> lacp agg 5/49 actor admin state active no aggregate
As an option, you can use the ethernet, fastethernet, and gigaethernet keywords before the slot and port
number to document the interface type or make the command look consistent with early-generation
Alcatel CLI syntax. For example, to modify the system ID of the dynamic aggregate actor port 3 in slot 7
to 00:20:da:06:ba:d3 and document that the port is 10 Mbps Ethernet you would enter:
-> lacp agg ethernet 7/3 actor system id 00:20:da:06:ba:d3
As an option, you can use the ethernet, fastethernet, and gigaethernet keywords before the slot and port
number to document the interface type or make the command look consistent with early-generation
Alcatel CLI syntax. For example, to modify the system priority of dynamic aggregate actor port 5 in slot 2
to 200 and document that the port is a Giga Ethernet port you would enter:
-> lacp agg gigaethernet 2/5 actor system priority 200
As an option, you can use the ethernet, fastethernet, and gigaethernet keywords before the slot and port
number to document the interface type or make the command look consistent with early-generation
Alcatel CLI syntax. For example, to modify the actor port priority of dynamic aggregate actor port 1 in
slot 2 to 100 and document that the port is a Giga Ethernet port you would enter:
-> lacp agg gigaethernet 2/1 actor port priority 100
• Partner port system ID (see “Modifying the Partner Port System ID” on page 26-24)
• Partner port system priority (see “Modifying the Partner Port System Priority” on page 26-25)
• Partner port administrative state (see “Modifying the Partner Port Administrative Status” on
page 26-26)
• Partner port priority (see “Modifying the Partner Port Priority” on page 26-26)
All of the commands to modify partner port parameters allow you to add the ethernet, fastethernet, and
gigaethernet keywords before the slot and port number to document the interface type or make the
command look consistent with early-generation Alcatel CLI syntax. However, these keywords do not
modify a port configuration. See Chapter 1, “Configuring Ethernet Ports,” for information on configuring
Ethernet ports.
Note. A port may belong to only one aggregate group. In addition, mobile ports cannot be aggregated. See
Chapter 5, “Assigning Ports to VLANs,” for more information on mobile ports.
Keyword Definition
active Specifies that bit 0 in LACPDU frames is set, which indicates that the
link is able to exchange LACPDU frames. By default, this bit is set.
timeout Specifies that bit 1 in LACPDU frames is set, which indicates that a
short time-out is used for LACPDU frames. When this bit is disabled, a
long time-out is used for LACPDU frames. By default, this bit is set.
aggregate Specifies that bit 2 in LACPDU frames is set, which indicates that the
system considers this link to be a potential candidate for aggregation. If
this bit is not set, the system considers the link to be individual (it can
only operate as a single link). By default, this bit is set.
Keyword Definition
synchronize Specifies that bit 3 in the partner state octet is enabled. When this bit is
set, the port is allocated to the correct dynamic aggregation group. If
this bit is not enabled, the port is not allocated to the correct aggrega-
tion group. By default, this value is disabled.
collect Specifying this keyword has no effect because the system always deter-
mines its value. When this bit (bit 4) is set by the system, incoming
LACPDU frames are collected from the individual ports that make up
the dynamic aggregate group.
distribute Specifying this keyword has no effect because the system always deter-
mines its value. When this bit (bit 5) is set by the system, distributing
outgoing frames on the port is disabled.
default Specifying this keyword has no effect because the system always deter-
mines its value. When this bit (bit 6) is set by the system, it indicates
that the partner is using defaulted actor information administratively
configured for the partner.
expire Specifying this keyword has no effect because the system always deter-
mines its value. When this bit (bit 7) is set by the system, the actor can-
not receive LACPDU frames.
Note. Specifying none removes all administrative states from the LACPDU configuration. For example:
-> lacp agg 7/49 partner admin state none
For example, to set bits 0 (active) and 2 (aggregate) on dynamic aggregate partner port 49 in slot 7 you
would enter:
-> lacp agg 7/49 partner admin state active aggregate
As an option, you can use the ethernet, fastethernet, and gigaethernet keywords before the slot and port
number to document the interface type or make the command look consistent with early-generation
Alcatel CLI syntax. For example, to set bits 0 (active) and 2 (aggregate) on dynamic aggregate partner
port 49 in slot 7 and document that the port is a Gigabit Ethernet port you would enter:
-> lacp agg gigaethernet 7/49 partner admin state active aggregate
Note. Since individual bits with the LACPDU frame are set with the lacp agg partner admin state
command you can set some bits on and restore other bits to default values within the same command. For
example, if you wanted to restore bit 2 (aggregate) to its default settings and set bit 0 (active) on dynamic
aggregate partner port 1 in slot 7 you would enter:
-> lacp agg 7/1 partner admin state active no aggregate
As an option, you can use the ethernet, fastethernet, and gigaethernet keywords before the slot and port
number to document the interface type or make the command look consistent with early-generation
Alcatel CLI syntax. For example, to modify the administrative key of a dynamic aggregate group partner
port 1 in slot 6 to 1000 and document that the port is a 10 Mbps Ethernet port you would enter:
-> lacp agg ethernet 6/1 partner admin key 1000
As an option, you can use the ethernet, fastethernet, and gigaethernet keywords before the slot and port
number to document the interface type or make the command look consistent with early-generation
Alcatel CLI syntax. For example, to modify the system ID of dynamic aggregate partner port 49 in slot 6
to 00:20:da:06:ba:d3 and document that the port is a Gigabit Ethernet port you would enter:
-> lacp agg gigaethernet 6/49 partner admin system id 00:20:da:06:ba:d3
As an option, you can use the ethernet, fastethernet, and gigaethernet keywords before the slot and port
number to document the interface type or make the command look consistent with early-generation
Alcatel CLI syntax. For example, to modify the administrative priority of dynamic aggregate
partner port 49 in slot 4 to 100 and specify that the port is a Gigabit Ethernet port you would enter:
-> lacp agg gigaethernet 4/49 partner admin system priority 100
As an option, you can use the ethernet, fastethernet, and gigaethernet keywords before the slot and port
number to document the interface type or make the command look consistent with early-generation
Alcatel CLI syntax. For example, to modify the administrative status of dynamic aggregate
partner port 1 in slot 7 to 200 and document that the port is a Giga Ethernet port you would enter:
-> lacp agg gigaethernet 7/1 partner admin port 200
For example, to modify the port priority of dynamic aggregate partner port 3 in slot 4 to 100 you would
enter:
-> lacp agg 4/3 partner admin port priority 100
As an option, you can use the ethernet, fastethernet, and gigaethernet keywords before the slot and port
number to document the interface type or make the command look consistent with early-generation
Alcatel CLI syntax. For example, to modify the port priority of dynamic aggregate partner port 3 in slot 4
to 100 and document that the port is a Giga Ethernet port you would enter:
-> lacp agg gigaethernet 4/3 partner admin port priority 100
The LACP WTR delay on bootup is applied on access switches connected to upstream Multi-Chassis or
Virtual-Chassis devices using multiple links. It improves convergence when an upstream chassis that went
down comes back up. By delaying the restoration of the LACP link long enough to allow L3 to converge,
the traffic loss is kept to a minimum. As an added benefit, if an LACP link starts flapping, no traffic will
be sent through that link until it is stable (until it is up longer that the WTR timer).
When a chassis which is part of Multi-Chassis or Virtual-Chassis powers up, the VFL links come up
immediately and all other links come up after a configured delay (usually 45 seconds). The non VFL links
include Network links which connect to upstream switches/routers and Access links which connect to L2
Access switches.
The LACP sync-up within milliseconds after the links come up and traffic originating from the Access
switches re-hash and are re-sent to the recovering upstream chassis. At that time, L3 protocols on the MC/
VC chassis is not up yet and traffic is redirected to the other MC/VC chassis (or black-holed). Later, after
the L3 protocols converge, the traffic is re-routed using the new best routes. This causes a reconvergence
double-hit which may exceed 1 second.
Without this feature, the LACP links sync up within milliseconds after the links come up and traffic
originating from the access switches re-hash and are re-sent to the recovering upstream chassis. At that
time, L3 protocols on the MC/VC chassis is not up yet and traffic is redirected to the other MC/VC
chassis (or black-holed). Later, after the L3 protocols converge, the traffic is re-routed using the new best
routes. This causes a reconvergence double-hit which may exceed 1 second.
Perform the following procedure to enable WTR timer to edge switches that are unaware that they are
connected to multi-chassis so it applies to regular links.
When a LACP comes up, it is required check if there is a WTR enabled for the linkagg.
If there is no WTR enabled for this linkagg, bring up the link. If there is a WTR configured for this
linkagg, do the following:
1 If there are no other links attached to the same linkagg, bypass the WTR and bring up the link
immediately.
2 If there are links attached to the same linkagg, start the WTR.
See “lacp linkagg wait-to-restore-timer” on page 4-233 in Chapter 4, “Link Aggregation Commands”
to configure the wait-to-restore timer.
Application Examples
Dynamic link aggregation groups are treated by the switch software the same way it treats individual
physical ports.This section demonstrates this feature by providing sample network configurations that use
dynamic aggregation along with other software features. In addition, tutorials are provided that show how
to configure these sample networks by using Command Line Interface (CLI) commands.
Switch A
Dynamic Aggregate Group 5
VLAN 10 has been configured to
use this group with Spanning
Tree with a priority of 15.
Switch C
The steps to configure VLAN 10 (Spanning Tree example) are described in “Link Aggregation and Span-
ning Tree Example” on page 26-30. The steps to configure VLAN 12 (802.1Q and 802.1p example) are
described in “Link Aggregation and QoS Example” on page 26-31.
Note. Although you would need to configure both the local ( Switch A) and remote ( Switch B and C)
switches, only the steps to configure the local switch are provided since the steps to configure the remote
switches are not significantly different.
Note. Only the steps to configure the local (Switch A) are provided here since the steps to configure the
remote ( Switch B) would not be significantly different.
2 Configure ports 5/5 and 5/6 with the same actor administrative key (5) by entering:
-> vlan 10
4 If the Spanning Tree Protocol (STP) has been disabled on this VLAN (STP is enabled by default),
enable it on VLAN 10 by entering:
-> vlan 10 stp enable
Note. Optional. Use the show spantree ports command to determine if the STP is enabled or disabled and
to display other STP parameters. For example:
-> show spantree 10 ports
Spanning Tree Port Summary for Vlan 10
Adm Oper Man. Path Desig Fw Prim. Adm Op
Port Pri St St mode Cost Cost Role Tx Port Cnx Cnx Desig Bridge ID
-----+---+---+----+----+-----+-----+----+---+-----+---+---+---------------------
3/13 7 ENA FORW No 100 0 DESG 1 3/13 EDG NPT 000A-00:d0:95:6b:0a:c0
2/10 7 ENA FORW No 19 0 DESG 1 2/10 PTP PTP 000A-00:d0:95:6b:0a:c0
5/2 7 ENA DIS No 0 0 DIS 0 5/2 EDG NPT 0000-00:00:00:00:00:00
0/5 7 ENA FORW No 4 0 DESG 1 0/10 PTP PTP 000A-00:d0:95:6b:0a:c0
In the example above the link aggregation group is indicated by the “0” for the slot number.
5 Configure VLAN 10 (which uses dynamic aggregate group 5) to the highest (15) priority possible by
entering:
-> bridge 10 5 mode priority 15
6 Repeat steps 1 through 5 on Switch B. All the commands would be the same except you would substi-
tute the appropriate port numbers.
Note. Only the steps to configure the local ( Switch A) switch are provided here since the steps to config-
ure the remote ( Switch C) switch would not be significantly different.
2 Configure ports 4/1, 4/2, 4/3, and 4/4 the same actor administrative key (7) by entering:
-> vlan 12
4 Configure 802.1Q tagging with a tagging ID (VLAN ID) of 12 on dynamic aggregate group 7 by enter-
ing:
-> vlan 12 802.1q 7
5 If the QoS Manager has been disabled (it is enabled by default) enable it by entering:
Note. Optional. Use the show qos config command to determine if the QoS Manager is enabled or
disabled.
7 Configure an 802.1p policy action with the highest priority possible ( 7) for VLAN 12 called
“vlan12_action” by entering:
-> policy action vlan12_action 802.1P 7
8 Configure a QoS rule called “vlan12_rule” by using the policy condition and policy rules you config-
ured in steps 8 and 9 above by entering:
-> policy rule vlan12_rule enable condition vlan12_condition action vlan12_ac-
tion
9 Enable your 802.1p QoS settings by entering qos apply as shown below:
10 Repeat steps 1 through 9 on Switch C. All the commands would be the same except you would substi-
tute the appropriate port numbers.
Note. If you do not use the qos apply command any QoS policies you configured will be lost on the next
switch reboot.
When you use the show linkagg command without specifying the link aggregation group number and
when you use the show linkagg port command without specifying the slot and port number, these
commands provide a “global” view of switch-wide link aggregate group and link aggregate port informa-
tion, respectively.
For example, to display global statistics on all link aggregate groups (both dynamic and static) you would
enter:
-> show linkagg
When you use the show linkagg command with the link aggregation group number and when you use the
show linkagg port command with the slot and port number, these commands provide detailed views of
the link aggregate group and port information, respectively. These detailed views provide excellent tools
for diagnosing and troubleshooting problems.
For example, to display detailed statistics for port 1 in slot 2 that is attached to dynamic link aggregate
group 1 you would enter:
-> show linkagg port 2/1
Note. See the “Link Aggregation Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Reference
Guide for complete documentation of show commands for link aggregation.
Dual-Home Link (DHL) is a high availability feature that provides fast failover between core and edge
switches without implementing Spanning Tree.
DHL Active-Active—an edge technology that splits a number of VLANs between two active links. The
forwarding status of each VLAN is modified by DHL to prevent network loops and maintain connectivity
to the core when one of the links fails. This solution does not require link aggregation.
In This Chapter
This chapter describes the basic components of DHL solutions and how to configure them through the
Command Line Interface (CLI). CLI commands are used in the configuration examples; for more details
about the syntax of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Information and procedures described in this chapter include:
• “Dual-Home Link Aggregation Specifications” on page 27-3.
IEEE Specifications Supported IEEE Std 802.1D, Media Access Control (MAC)
Bridges
Platforms Supported OmniSwitch 6250, 6350, 6450
DHL session supported 1 per switch
Maximum number of vlans per DHL group 128
Number of links per group supported 2, 4, or 8
• Two DHL links associated with the session (link A and link B). A physical switch port or a logical link
aggregate (linkagg) ID are configurable as a DHL link.
• A group of VLANs (or pool of common VLANs) in which each VLAN is associated (802.1q tagged)
with both link A and link B.
• A VLAN-to-link mapping that specifies which of the common VLANs each DHL link will service.
This mapping prevents network loops by designating only one active link for each VLAN, even though
both links remain active and are associated with each of the common VLANs.
When one of the two active DHL links fails or is brought down, the VLANs mapped to that link are then
forwarded on the remaining active link to maintain connectivity to the core. When the failed link comes
back up, DHL waits a configurable amount of time before the link resumes forwarding of its assigned
VLAN traffic.
The following diagram shows how DHL works when operating in a normal state (both links up) and when
operating in a failed state (one link is down):
Edge Edge
Protected VLANs
A protected VLAN is one that is assigned to both links in a DHL session. This means that if the link to
which the VLAN is mapped fails, the VLAN is moved to the other active DHL link to maintain connectiv-
ity with the core switches.
Any VLAN that is only assigned to one of the DHL links is considered an unprotected VLAN. This type
of VLAN is not eligible for DHL support if the link to which the VLAN is assigned fails.
• LPS ports
• NNI ports
• Mobile ports
• 802.1x ports
• GVRP ports.
• UNI ports
Note. No CLI error message is displayed when DHL is configured using a port type that is not supported.
topology change event and the MAC address table is not automatically flushed. This can create stale MAC
address entries that are looking for end devices over the wrong link.
To avoid stale MAC address entries in the forwarding tables of the core switches, some type of communi-
cation needs to occur between the edge uplink switch and the core switches. The DHL Active-Active
feature provides two methods for clearing stale MAC address entries: MVRP Enhanced Operation or Raw
Flooding. Selecting which one of these methods to use is done on a per-DHL session basis.
Raw Flooding
When a DHL link fails or recovers and Raw Flooding is enabled for the DHL session, the switch performs
the following tasks to trigger MAC movement:
• Identify a list of MAC addresses within the effected VLANs that were learned on non-DHL ports
(MAC addresses that were reachable through the effected VLANs).
• Create a tagged packet for each of these addresses. The SA for the packet is one of the MAC addresses
from the previously-generated list; the VLAN tag is the resident VLAN for the MAC address; the DA
is set for broadcast (all Fs); the body is just filler.
• Transmit the generated packet once for each VLAN-MAC address combination. These packets are sent
on the link that takes over for the failed link or on a link that has recovered from a failure.
The MAC movement triggered by the Raw Flooding method should clear any stale MAC entries.
However, flooded packets are often assigned a low priority and the switch may filter such packets in a
highly utilized network.
• Do not change the link assignments for the DHL session while the session is enabled.
• Configuring a MAC address flush method (MVRP or Raw Flooding) is recommended if the DHL
session ports span across switch modules or the DHL ports are on the same module but the data port is
on a different module. Doing so will improve convergence time.
• To improve convergence time for uni-directional traffic, specify Raw Flooding as the MAC flush
method for the DHL session.
• Enabling the registrar mode as “forbidden” is recommended before MVRP is enabled on DHL links.
1 Configure a set of VLANs that the two DHL session links will service.
2 Identify two ports or link aggregates that will serve as the links for the DHL session then assign both
links to the same default VLAN. Make sure the default VLAN is one of the VLANs created in Step 1. For
example, the following commands assign VLAN 100 as the default VLAN for port 1/10 and linkagg 5:
-> vlan 100 port default 1/10
-> vlan 100 port default 5
3 Associate (802.1q tag) the ports identified in Step 2 to each one of the VLANs created in Step 1, except
for the default VLAN already associated with each port. For example, the following commands associate
port 1/10 and linkagg 5 with VLANs 101-110:
-> vlan 101-110 802.1q 1/10
-> vlan 101-110 802.1q 1
In the above command example, port 1/10 and linkagg 1 are only tagged with VLANs 101-110 because
VLAN 100 is already the default VLAN for both ports.
4 Create a DHL session using the dhl num command. For example:
5 Configure the pre-emption (recovery) timer for the DHL session using the dhl num pre-emption-time
command. By default, the timer is set to 30 seconds, so it is only necessary to change this parameter if the
default value is not sufficient. For example, the following command changes the timer value 500 seconds:
-> dhl num 10 pre-emption-time 500
6 Configure the MAC address flushing method for the DHL session using the dhl num mac-flushing
command and specify either the raw or mvrp parameter option. By default, the MAC flushing method is
set to none. For example, the following command selects the MVRP method:
-> dhl num 10 mac-flushing mvrp
7 Configure two links (linkA and linkB) for the DHL session using the dhl num linka linkb command.
Specify the ports identified in Step 1 as linkA and linkB. For example:
-> dhl num 10 linka linkagg 1 linkb port 1/10
8 Select VLANs from the set of VLANs created in Step 2 and map those VLANs to linkB using the dhl
num vlan-map linkb command. Any VLAN not mapped to linkB is automatically mapped to linkA. By
default, all VLANs are mapped to linkA. For example, the following command maps VLANs 11-20 to
linkB:
-> dhl num 10 vlan-map linkb 11-20
9 Administratively enable the DHL session using the dhl num admin-state command. For example:
See “Dual-Home Link Active-Active Example” on page 27-10 for a DHL application example.
2 Configure 802.1q tagging on VLANs 2-10 for port 1/10. Because VLAN 1 is the default VLAN for
port 1/10, there is no need to tag VLAN 1.
-> vlan 2-10 802.1q 1/10
3 Configure 802.1q tagging on the VLANs 2-10 for port 2/10. Because VLAN 1 is the default VLAN for
port 2/10, there is no need to tag VLAN 1.
-> vlan 2-10 802.1q 2/10
5 Configure port 1/10 and port 2/10 as the dual-home links (linkA, linkB) for the DHL session.
7 Specify Raw Flooding as the MAC flushing technique to use for this DHL session.
8 Enable the administrative state of the DHL session using the following command:
Core Switches:
2 Configure 802.1q tagging on VLANs 2-10 for port 1/10 on the Core 1 switch. VLAN 1 is the default
VLAN for port 1/10, so there is no need to tag VLAN 1.
-> vlan 2-10 802.1q 1/10
3 Configure 802.1q tagging on VLANs 2-10 for port 2/10 on the Core 2 switch. VLAN 1 is the default
VLAN for port 2/10, so there is no need to tag VLAN 1.
-> vlan 2-10 802.1q 2/10
4 Configure 802.1q tagging on VLANs 2-10 for LACP 1 on both of the Core switches. VLAN 1 is the
default VLAN for LACP 1 on both Core switches, so there is no need to tag VLAN 1.
-> vlan 2-10 802.1q 1
Core 1 Switch:
-> vlan 2-10
-> vlan 2-10 802.1q 1/10
-> vlan 2-10 802.1q 1
Core 2 Switch:
-> vlan 2-10
-> vlan 2-10 802.1q 2/10
-> vlan 2-10 802.1q 1
In the above topology, all uplinked switches are connected to the core network through redundant links,
and the links are configured to use DHL Active-Active. Spanning Tree is disabled on all the DHL enabled
ports of the uplinked devices.
In the above topology, the link between the uplink device other than core network is not recommended as
it will create a loop in the network. This topology violates the principle that uplink switches can only be
connected to the network cloud through the core network.
Note. See the “Link Aggregation Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Reference
Guide for complete documentation of show commands for link aggregation.
Internet Protocol (IP) is primarily a network-layer (Layer 3) protocol that contains addressing and control
information that enables packets to be forwarded. Along with Transmission Control Protocol (TCP), IP
represents the heart of the Internet protocols. IP has two primary responsibilities:
• providing connectionless, best-effort delivery of datagrams through an internetwork,
• providing fragmentation and reassembly of datagrams to support data links with different
Maximum Transmission Unit (MTU) sizes.
Note. IP routing (Layer 3) can be accomplished using static routes or by using an IP routing protocol such
as Routing Information Protocol (RIP). For more information see Chapter 23, “Configuring RIP”.
There are two versions of Internet Protocol supported, IPv4 and IPv6. For more information about using
IPv6, see Chapter 29, “Configuring IPv6.”
In This Chapter
This chapter describes IP and how to configure it through the Command Line Interface (CLI). It includes
instructions for enabling IP forwarding, configuring IP route maps, as well as basic IP configuration
commands (for example, ip default-ttl). CLI commands are used in the configuration examples; for more
details about the syntax of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide. This
chapter provides an overview of IP and includes information about the following procedures:
• IP Forwarding
– Configuring an IP Router Interface (see page 28-6)
– Creating a Static Route (see page 28-9)
– Creating a Default Route (see page 28-11)
– Configuring Address Resolution Protocol (ARP) (see page 28-12)
• IP Configuration
– Configuring a DHCP Client Interface (see page 28-17)
– Configuring the Router Primary Address (see page 28-17)
– Configuring the Router ID (see page 28-17)
– Configuring the Time-to-Live (TTL) Value (see page 28-18)
– Configuring Route Map Redistribution (see page 28-18)
– IP-Directed Broadcasts (see page 28-25)
– Protecting the Switch from Denial of Service (DoS) attacks (see page 28-25)
• Managing IP
– Internet Control Message Protocol (ICMP) (see page 28-31)
– Using the Ping Command (see page 28-34)
– Tracing an IP Route (see page 28-35)
– Displaying User Datagram Protocol (UDP) Information (see page 28-35)
– Two-Way Active Measurement Protocol (TWAMP) (see page 28-36)
• Network Address Translation
– Configuring NAT (see page 28-39)
IP Specifications
Note. The maximum limit values provided in the following Specifications table are subject to
available system resources.
IP Defaults
The following table lists the defaults for IP configuration through the ip command.
Note. The operational status of a VLAN remains inactive until at least one active switch port is assigned
to the VLAN. Ports are considered active if they are connected to an active network device. Non-active
port assignments are allowed, but do not change the operational state of the VLAN.
To forward packets to a different VLAN on a switch, create a router interface on each VLAN. The
following steps show you how to enable IP forwarding between VLANs “from scratch”. If active VLANs
have already been created on the switch, you only need to create router interfaces on each VLAN (Steps 5
and 6).
1 Create VLAN 1 with a description (for example, VLAN 1) by using the vlan command. For example:
2 Create VLAN 2 with a description (for example, VLAN 2) by using the vlan command. For example:
3 Assign an active port to VLAN 1 by using the vlan port default command. For example, the
following command assigns port 1 on slot 1 to VLAN 1:
-> vlan 1 port default 1/1
4 Assign an active port to VLAN 2 by using the vlan port default command. For example, the
following command assigns port 2 on slot 1 to VLAN 2:
-> vlan 2 port default 1/2
5 Create an IP router interface on VLAN 1 using the ip interface command. For example:
6 Create an IP router interface on VLAN 2 using the ip interface command. For example:
Note. See Chapter 4, “Configuring VLANs.” for more information about how to create VLANs and
VLAN router interfaces.
IP Overview
IP is a network-layer (Layer 3) protocol that contains addressing and control information that enables
packets to be forwarded on a network. IP is the primary network-layer protocol in the Internet protocol
suite. Along with TCP, IP represents the heart of the Internet protocols.
IP Protocols
IP is associated with several Layer 3 and Layer 4 protocols. These protocols are built into the base code
loaded on the switch. A brief overview of supported IP protocols is included in the following sections.
Transport Protocols
IP is both connectionless (it forwards each datagram separately) and unreliable (it does not guarantee
delivery of datagrams). This means that a datagram can be damaged in transit, thrown away by a busy
switch, or never reach its destination. The resolution for these transit problems is to use a Layer 4
transport protocol, such as:
• TCP—A major data transport mechanism that provides reliable, connection-oriented, full-duplex data
streams. While the role of TCP is to add reliability to IP, TCP relies upon IP to do the actual
delivering of datagrams.
• UDP—A secondary transport-layer protocol that uses IP for delivery. UDP is not connection-oriented
and does not provide reliable end-to-end delivery of datagrams. But some applications can safely use
UDP to send datagrams that do not require the extra overhead added by TCP. For more information on
UDP, see Chapter 32, “Configuring DHCP.”
Application-Layer Protocols
Application-layer protocols are used for switch configuration and management:
• Bootstrap Protocol (BOOTP)/Dynamic Host Configuration Protocol (DHCP)—can be used by an end
station to obtain an IP address. The switch provides a DHCP Relay that allows BOOTP requests/replies
to cross different networks.
• Simple Network Management Protocol (SNMP)—Allows communication between SNMP managers
and SNMP agents on an IP network. Network administrators use SNMP to monitor network
performance and manage network resources. For more information, see the “Using SNMP” chapter in
the OmniSwitch 6250/6350/6450 Switch Management Guide.
• Telnet—Used for remote connections to a device. You can telnet to a switch and configure the switch
and the network by using the CLI.
• File Transfer Protocol (FTP)—Enables the transfer of files between hosts. This protocol is used to load
new images onto the switch.
Additional IP Protocols
There are several additional IP-related protocols that can be used with IP forwarding. These protocols are
included as part of the base code.
• Address Resolution Protocol (ARP)—Used to match the IP address of a device with its physical
(MAC) address. For more information, see “Configuring Address Resolution Protocol (ARP)” on
page 28-12.
• Internet Control Message Protocol (ICMP)—Specifies the generation of error messages, test packets,
and informational messages related to IP. ICMP supports the ping command used to determine if hosts
are online. For more information, see “Internet Control Message Protocol (ICMP)” on page 28-31.
• Router Discovery Protocol (RDP)—Used to advertise and discover routers on the LAN. For more
information, see Chapter 31, “Configuring RDP.”
• Multicast Services—Includes IP multicast switching (IPMS). For more information, see Chapter 41,
“Configuring IP Multicast Switching.”
IP Forwarding
Network device traffic is bridged or switched at the Layer 2 level between ports that are assigned to the
same VLAN. However, if a device needs to communicate with another device that belongs to a different
VLAN, Layer 3 routing is used to transmit traffic between the VLANs. Bridging decides on where to
forward packets based on the packet destination MAC address; routing decides on where to forward
packets based on the packet IP network address (for example, IP - 21.0.0.10).
Alcatel switches support routing of IP traffic. A VLAN is available for routing when at least one router
interface is defined for that VLAN and at least one active port is associated with the VLAN. If a VLAN
does not have a router interface, the ports associated with that VLAN are in essence firewalled from other
VLANs.
IP multinetting is also supported. A network is said to be multinetted when multiple IP subnets are brought
together within a single broadcast domain. It is now possible to configure up to 32 IP interfaces per
VLAN. Each interface is configured with a different subnet. As a result, traffic from each configured
subnet can coexist on the same VLAN.
In the following illustration, an IP router interface has been configured on each VLAN. Therefore,
workstations connected to ports on VLAN 1 on Switch 1 can communicate with VLAN 2; and
workstations connected to ports on VLAN 3 on Switch 2 can communicate with VLAN 2. Also, ports
from both switches have been assigned to VLAN 2, and a physical connection has been made between the
switches. Hence, workstations connected to VLAN 1 on Switch 1 can communicate with workstations
connected to VLAN 3 on Switch 2.
Switch 2
Switch 1
= IP Router Interface
Physical
VLAN 1 VLAN 2 Connection VLAN 2 VLAN 3
110.0.0.0 120.0.0.0 120.0.0.0 130.0.0.0
IP Forwarding
If the switch is running in single MAC router mode, a maximum of 4094 VLANs can have IP interfaces
defined. In this mode, each router VLAN is assigned the same MAC address, which is the base chassis
MAC address for the switch.
Note. The router interface IP addresses must be unique. You cannot have two router interfaces with the
same IP address.
• A subnet mask (defaults to the IP address class). It is possible to specify the mask in dotted decimal
notation (for example, 255.255.0.0) or with a slash (/) after the IP address followed by the number of
bits to specify the mask length (for example, 193.204.173.21/64).
• The forwarding status for the interface (defaults to forwarding). A forwarding router interface sends IP
frames to other subnets. A router interface that is not forwarding can receive frames from other hosts
on the same subnet.
• An Ethernet-II or SNAP encapsulation for the interface (defaults to Ethernet-II). The encapsulation
determines the framing type the interface uses when generating frames that are forwarded out of
VLAN ports. Select an encapsulation that matches the encapsulation of the majority of VLAN traffic.
• The Local Proxy ARP status for the VLAN. If enabled, traffic within the VLAN is routed instead of
bridged. ARP requests return the MAC address of the IP router interface defined for the VLAN. For
more information about Local Proxy ARP, see “Local Proxy ARP” on page 28-13.
• The primary interface status. Designates the specified IP interface as the primary interface for the
VLAN. By default, the first interface bound to a VLAN becomes the primary interface for that VLAN.
The following ip interface command example creates an IP interface named Marketing with an IP
network address of 21.0.0.1 and binds the interface to VLAN 455:
-> ip interface Marketing address 21.0.0.1 vlan 455
The name parameter is the only parameter required with this command. Specifying additional parameters
is only necessary to configure a value other than the default value for that parameter. For example, all of
the following commands create an IP router interface for VLAN 955 with a class A subnet mask, an
enabled forwarding status, Ethernet-II encapsulation, and a disabled Local Proxy ARP and primary
interface status:
-> ip interface Accounting address 71.0.0.1 mask 255.0.0.0 vlan 955 forward e2
no local-proxy-arp no primary
-> ip interface Accounting address 71.0.0.1/8 vlan 955
-> ip interface Accounting address 71.0.0.1 vlan 955
Note. When the IP address for the interface is changed, the subnet mask reverts to the default mask value
if it was previously set to a non-default value and no mask value is specified when the IP address is
changed.
For example, the following command changes the IP address for the Accounting interface:
-> ip interface Accounting address 40.0.0.1
The subnet mask for the Accounting interface was previously set to 255.255.255.0. The previous example
resets the mask to the default value of 255.0.0.0 because 40.0.0.1 is a Class A address and no other mask
was specified with the command. This only occurs when the IP address is modified; all other parameter
values remain unchanged unless otherwise specified.
To avoid the problem in the above example, enter the non-default mask value whenever the IP address is
changed for the interface. For example:
-> ip interface Accounting address 40.0.0.1 mask 255.255.255.0
-> ip interface Accounting address 40.0.0.1/8
Use the show ip interface command to verify IP router interface changes. For more information about
these commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Note. It is only necessary to specify the name of the IP interface, along with the no form of the command.
For example:
-> no ip interface Marketing
To view a list of IP interfaces configured on the switch, use the show ip interface command. For more
information about this command, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Note. RIP advertises the host route to the Loopback0 IP interface as a redistributed (directhost) route.
Gateway and destination IP address must be on different subnets. The subnet mask is not required if you
want to use the natural subnet mask. By default, the switch imposes a natural mask on the IP address. In
the above example, the Class B mask of 255.255.0.0 is implied. If you do not want to use the natural
mask, enter a subnet mask. For example, to create a static route to IP address 10.255.11.0, you would have
to enter the Class C mask of 255.255.255.0:
Note. You can also specify the length of the mask in bits.
For example, the above static route is also configurable using the following command:
-> ip static-route 10.255.11.0/24 gateway 171.11.2.1
When you create a static route, the default metric value of 1 is used. However, you can change the
priority of the route by increasing its metric value. The lower the metric value, the higher the priority. This
metric is added to the metric cost of the route. The metric range is 1 to 15. For example:
-> ip static-route 10.255.11.0/24 gateway 171.11.2.1 metric 5
Static routes do not age out of the IP Forwarding table; hence, delete them from the table. Use the
no ip static route command to delete a static route. Specify the destination IP address of the route as well
as the IP address of the first hop (gateway). For example, to delete a static route to IP address 171.11.0.0
through gateway 171.11.2.1, you would enter:
-> no ip static-route 171.11.0.0 gateway 171.11.2.1
The IP Forwarding table includes routes learned through RIP as well as any static routes that are
configured. Use the show ip route command to display the IP Forwarding table.
Note. A static route is not active unless the gateway it is using is active.
D1 D2
10.1.1.1/24
10.1.1.2/24
11.1.1.1/24
D3 D4
11.1.1.2/24
10.1.1.33/27 10.1.1.34/27
Note. You can specify the length of the mask in bits also.
For example, the above default route is also configurable using the following command:
-> ip static-route 0.0.0.0/0 gateway 171.11.2.1
Note. You cannot create a default route by using the EMP port as a gateway.
When you add an entry to the ARP table, the IP address and hardware address (MAC address) are
required. Optionally, you can also specify:
• Alias. Use the alias keyword to configure the switch to act as an alias (proxy) for this IP address. When
the alias option is used, the switch responds to all ARP requests for the specified IP address with its
own MAC address. This option is not related to Proxy ARP as defined in RFC 925.
For example:
-> arp 171.11.1.1 00:05:02:c0:7f:11 alias
Note. Because most hosts support the use of address resolution protocols to determine and cache address
information (called dynamic address resolution), you do not need to specify permanent ARP entries.
Use the show arp command to display the ARP table and verify that the entry was deleted.
Note. You can also use the no arp command to delete a dynamic entry from the table.
Note. Dynamic entries remain in the ARP table until they time out. If the switch does not receive data
from a host for this user-specified time, the entry is removed from the table. If another packet is received
from this host, the switch goes through the discovery process again to add the entry to the table. The
switch uses the MAC Address table time-out value as the ARP time-out value. Use the mac-address-table
aging-time command to set the time-out value.
Note. Local Proxy ARP takes precedence over any switch-wide Proxy ARP or ARP function. In
addition, it is not necessary to configure Proxy ARP in order to use Local Proxy ARP. The two features
are independent of each other.
By default, Local Proxy ARP is disabled when an IP interface is created. To enable this feature, use the ip
interface command. For example:
-> ip interface Accounting local-proxy-arp
Note. When Local Proxy ARP is enabled for any one IP router interface associated with a VLAN, the
feature is applied to the entire VLAN. It is not necessary to enable it for each interface. However, if the IP
interface that has this feature enabled is moved to another VLAN, Local Proxy ARP is enabled for the
new VLAN and must be enabled on another interface for the old VLAN.
The example above considers that all devices are in VLAN 1, Clients 1 and 2 are connected to ports 1/1
and 1/2, and the head end router is connected to port 1/3.
ARP Filtering
ARP filtering is used to determine whether the switch responds to ARP requests that contain a specific IP
address. ARP filtering feature is used in conjunction with the Local Proxy ARP application; however,
ARP filtering is available for use on its own and/or with other applications.
By default, no ARP filters exist in the switch configuration. When there are no filters present, all ARP
packets are processed, unless they are blocked or redirected by some other feature.
Use the arp filter command to specify the following parameter values required to create an ARP filter:
• An IP address (for example, 193.204.173.21) used to determine whether an ARP packet is filtered.
• An IP mask (for example 255.0.0.0) used to identify which part of the ARP packet IP address is
compared to the filter IP address.
• An optional VLAN ID to specify that the filter is only applied to ARP packets from that VLAN.
• Which ARP packet IP address to use for filtering (sender or target). If the target IP address in the ARP
packet matches a target IP specified in a filter, then the disposition for that filter applies to the ARP
packet. If the sender IP address in the ARP packet matches a sender IP specified in a filter, then the
disposition for that filter applies to the ARP packet.
• The filter disposition (block or allow). If an ARP packet meets filter criteria, the switch is either
blocked from responding to the packet or allowed to respond to the packet depending on the filter
disposition. Packets that do not meet any filter criteria are responded to by the switch.
The following arp filter command example creates an ARP filter, that blocks the switch from responding
to ARP packets that contain a sender IP address that starts with 198:
-> arp filter 198.0.0.0 mask 255.0.0.0 sender block
Up to 200 ARP filters can be defined on a single switch. To remove an individual filter, use the no form of
the arp filter command. For example:
-> no arp filter 198.0.0.0
To clear all ARP filters from the switch configuration, use the clear arp filter command. For example:
-> clear arp filter
Use the show arp filter command to verify the ARP filter configuration. For more information on all
supported ARP filter commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
IP Configuration
IP is enabled on the switch by default and there are few options that can, or need to be, configured. This
section provides instructions for some basic IP configuration options.
Refer to the “Configuring the DHCP Client Interface” on page 32-17 for more detailed information
regarding DHCP client.
To display the current route preference configuration, use the show ip route-pref command:
-> show ip route-pref
Protocol Route Preference Value
------------+------------------------
Local 1
Static 2
RIP 120
The default hop count is 64. The valid range is 1 to 255. Use the show ip config command to display the
default TTL value.
Refer to the “IP Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Reference Guide for more
information about the ip route-map command parameters and usage guidelines.
Once a route map is created, it is then applied using the ip redist command. See “Configuring Route Map
Redistribution” on page 28-23 for more information.
The above command creates the static-to-rip route map, assigns a sequence number of 10 to the route
map, and specifies a permit action.
To optionally filter routes before redistribution, use the ip route-map command with a match parameter
to configure match criteria for incoming routes. For example,
-> ip route-map static-to-rip sequence-number 10 match tag 8
The above command configures a match statement for the static-to-rip route map to filter routes based on
their tag value. When this route map is applied, only Static routes with a tag value of eight are
redistributed into the RIP network. All other routes with a different tag value are dropped.
Note. Configuring match statements is not required. However, if a route map does not contain any match
statements and the route map is applied using the ip redist command, the router redistributes all routes
into the network of the receiving protocol.
To modify route information before it is redistributed, use the ip route-map command with a set
parameter. For example,
-> ip route-map static-to-rip sequence-number 10 set tag 5
The above command configures a set statement for the static-to-rip route map that changes the route tag
value to five. Because this statement is part of the static-to-rip route map, it is only applied to routes that
have an existing tag value equal to eight.
The following is a summary of the commands used in the above examples:
-> ip route-map static-to-rip sequence-number 10 action permit
-> ip route-map static-to-rip sequence-number 10 match tag 8
-> ip route-map static-to-rip sequence-number 10 set tag 5
To delete a specific sequence number within a route map, enter no ip route-map followed by the route
map name, then sequence-number followed by the actual number. For example, the following command
deletes sequence 10 from the redistipv4 route map:
-> no ip route-map redistipv4 sequence-number 10
Note that in this example, the redistripv4 route map is not deleted. Only those statements associated with
sequence 10 are removed from the route map.
To delete a specific statement within a route map, enter no ip route-map followed by the route map name,
then sequence-number followed by the sequence number for the statement, then either match or set and
the match or set parameter and value. For example, the following command deletes only the match tag 8
statement from route map redistipv4 sequence 10:
-> no ip route-map redistipv4 sequence-number 10 match tag 8
To configure a new sequence of statements for an existing route map, specify the same route map name
but use a different sequence number. For example, the following commands create a new sequence - 20,
for the rm_1 route map:
-> ip route-map rm_1 sequence-number 20 action permit
-> ip route-map rm_1 sequence-number 20 match ipv4-interface to-finance
-> ip route-map rm_1 sequence-number 20 set metric 5
Sequence 10 and sequence 20 are both linked to route map rm_1 and are processed in ascending order
according to their sequence number value. Note that there is an implied logical OR between sequences. As
a result, if there is no match for the tag value in sequence 10, then the match interface statement in
sequence 20 is processed. However, if a route matches the tag 8 value, then sequence 20 is not used. The
set statement for whichever sequence was matched is applied.
A route map sequence can contain multiple match statements. If these statements are of the same kind (for
example, match tag 5, match tag 8, and so on) then a logical OR is implied between each like statement. If
the match statements specify different types of matches (for example match tag 5, match ip4 interface
to-finance, and so on), then a logical AND is implied between each statement. For example, the following
route map sequence redistributes a route if its tag is either 8 or 5:
-> ip route-map rm_1 sequence-number 10 action permit
-> ip route-map rm_1 sequence-number 10 match tag 5
-> ip route-map rm_1 sequence-number 10 match tag 8
The following route map sequence redistributes a route if the route has a tag of 8 or 5 and the route was
learned on the IPv4 interface to-finance:
-> ip route-map rm_1 sequence-number 10 action permit
-> ip route-map rm_1 sequence-number 10 match tag 5
-> ip route-map rm_1 sequence-number 10 match tag 8
-> ip route-map rm_1 sequence-number 10 match ipv4-interface to-finance
To add addresses to an access list, use the ip access-list address (IPv4) or the ipv6 access-list address
(IPv6) command. For example, the following commands add addresses to an existing access list:
-> ip access-list ipaddr address 10.0.0.0/8
-> ipv6 access-list ip6addr address 2001::/64
Use the same access list name each time the above mentioned commands are used to add additional
addresses to the same access list. In addition, both commands provide the ability to configure if an address
and/or its matching subnet routes are permitted (the default) or denied redistribution. For example:
-> ip access-list ipaddr address 16.24.2.1/16 action deny redist-control
all-subnets
-> ipv6 access-list ip6addr address 2001::1/64 action permit redist-control
no-subnets
For more information about configuring access list commands, see the “IP Commands” chapter in the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
Static routes received by the router interface are processed based on the contents of the static-to-rip route
map. Routes that match criteria specified in this route map are either allowed or denied redistribution into
the RIP network. The route map can also specify the modification of route information before the route is
redistributed. See “Using Route Maps” on page 28-19 for more information.
To remove a route map redistribution configuration, use the no form of the ip redist command. For
example:
-> no ip redist static into rip route-map staic-to-rip
Source Destination
Protocol Protocol Status Route Map
------------+------------+---------+--------------------
The resulting static-to-rip route map redistribution configuration does the following
• Denies the redistribution of routes with a tag set to five.
• Redistributes into RIP all routes learned on the intf_rip interface and sets the metric for such routes to
255.
• Redistributes into RIP all other routes (for routes not processed by sequence 10 or 20) and sets the tag
for such routes to eight.
IP-Directed Broadcasts
An IP directed broadcast is an IP datagram that has all zeros or all 1 in the host portion of the destination
IP address. The packet is sent to the broadcast address of a subnet to which the sender is not directly
attached. Directed broadcasts are used in denial-of-service “smurf” attacks. In a smurf attack, a
continuous stream of ping requests is sent from a falsified source address to a directed broadcast address,
resulting in a large stream of replies, which can overload the host of the source address. By default, the
switch drops directed broadcasts. Ideally, directed broadcasts must not be enabled.
Use the ip directed-broadcast command to enable or disable IP-directed broadcasts. For example:
-> ip directed-broadcast off
Use the show ip config command to display the IP-directed broadcast state.
• Invalid IP Attack—Packets with invalid source or destination IP addresses are received by the switch.
When such an Invalid-IP attack is detected, the packets are dropped, and SNMP traps are generated.
Examples of some invalid source and destination IP addresses are listed as follows:
• 255.255.255.255.
Note. In both the conditions described here in “Multicast IP and MAC Address Mismatch”, packets are
dropped and SNMP traps are generated.
• the destination IP is a unicast IP and the destination MAC address is either a Broadcast or Multicast
address. In such a condition, an event is recorded in the DoS statistics. No SNMP traps are
generated because valid packets can also fall under this category.
• Ping overload—Floods a switch with a large number of ICMP packets, resulting in the switch using a
large amount of CPU time to respond to these packets. If the number of ICMP packets exceed 100 per
second, a DoS attack is detected. By default, the detection of attack is disabled.
• Packets with loopback source IP address—Packets with an invalid source address of 127.0.0.0/8 (loop-
back network) are received by the switch. When such packets are detected, they are dropped, and
SNMP traps are generated.
The switch can be set to detect various types of port scans by monitoring for TCP or UDP packets sent to
open or closed ports. Monitoring is done in the following manner:
• Packet penalty values set. TCP and UDP packets destined for open or closed ports are assigned a
penalty value. Each time a packet of this type is received, its assigned penalty value is added to a
running total. This total is cumulative and includes all TCP and UDP packets destined for open or
closed ports.
• Port scan penalty value threshold.The switch is given a port scan penalty value threshold. This
number is the maximum value the running penalty total can achieve before triggering an SNMP trap.
• Decay value. A decay value is set. The running penalty total is divided by the decay value every
minute.
• Trap generation. If the total penalty value exceeds the set port scan penalty value threshold, a trap is
generated to alert the administrator that a port scan is in progress.
For example, imagine that a switch is set so that TCP and UDP packets destined for closed ports are given
a penalty of 10, TCP packets destined for open ports are given a penalty of 5, and UDP packets destined
for open ports are given a penalty of 20. The decay is set to 2, and the switch port scan penalty value
threshold is set to 2000:
.
DoS Settings
UDP/TCP closed = 10
UDP open = 20
TCP open = 5
Threshold = 2000
Decay = 2
Penalty Total = 0
In one minute, 10 TCP closed port packets and 10 UDP closed port packets are received. This would bring
the total penalty value to 200, as shown using the following equation:
(10 TCP X 10 penalty) + (10 UDP X 10 penalty) = 200
This value would be divided by 2 (due to the decay) and decreased to 100. The switch would not record a
port scan:
DoS Settings
UDP/TCP closed = 10
UDP open = 20
TCP open = 5
Threshold = 2000
Decay = 2
In the next minute, 10 more TCP and UDP closed port packets are received, along with 200 UDP open-
port packets. This would bring the total penalty value to 4300, as shown using the following equation:
(100 previous minute value) + (10 TCP X 10 penalty) + (10 UDP X 10 penalty) +
(200 UDP X 20 penalty) = 4300
This value would be divided by 2 (due to decay) and decreased to 2150. The switch would record a port
scan and generate a trap to warn the administrator:
DoS Settings
UDP/TCP closed = 10
UDP open =20
TCP open = 5
Threshold = 2000
Decay = 2
10 TCP closed port packets
The function usage and how to set their values are covered in the sections that follow.
To assign a penalty value to TCP packets bound for an open port, use the ip dos scan tcp open-port-
penalty command with a penalty value. For example, to assign a penalty value of 10 to TCP packets
destined for opened ports, enter the following:
-> ip dos scan tcp open-port-penalty 10
To assign a penalty value to UDP packets bound for an open port, use the ip dos scan udp open-port-
penalty command with a penalty value. For example, to assign a penalty value of 10 to TCP/UDP packets
destined for closed ports, enter the following:
-> ip dos scan udp open-port-penalty 10
To disable DoS traps, enter the same ip dos trap command, as shown:
-> ip dos trap disable
ARP Poisoning
ARP Poisoning allows an attacker to sniff and tamper the data frames on a network. It also modifies or
halts the traffic. The principle of ARP Poisoning is to send false or spoofed ARP messages to an Ethernet
LAN.
Alcatel-Lucent introduces the functionality that detects the presence of an ARP poisoning host on a
network. This functionality uses a configured restricted IP addresses, so that the switch does not get ARP
response on sending an ARP request. If an ARP response is received, then an event is logged and the user
is alerted using an SNMP trap.
Use the ip dos arp-poison restricted-address command to add an ARP Poison restricted address. Enter
the command, followed by the IP address. For example, to add an ARP Poison restricted address as
192.168.1.1, you would enter:
-> ip dos arp-poison restricted-address 192.168.1.1
To verify the number of attacks detected for configured ARP poison restricted addresses, use the show ip
dos arp-poison command. For more information about this command, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
Enabling/Disabling IP Services
When a switch initially boots up, all supported TCP/UDP well-known service ports are enabled (open).
Although these ports provide access for essential switch management services, such as telnet, ftp, snmp,
and so on, they also are vulnerable to DoS attacks. It is possible to scan open service ports and launch such
attacks based on well-known port information.
The ip service command allows you to selectively disable (close) TCP/UDP well-known service ports and
enable them when necessary. This command only operates on TCP/UDP ports that are opened by default.
It has no effect on ports that are opened by loading applications, such as RIP.
In addition, the ip service command allows you to designate which port to enable or disable by specifying
the name of a service or the well-known port number associated with that service. For example, both of the
following commands disable the telnet service:
-> no ip service telnet
-> no ip service port 23
Note that specifying a port number requires the use of the optional port keyword.
To enable or disable more than one service in a single command line, enter each service name separated by
a space. For example, the following command enables the telnet, ftp, and snmp service ports:
-> ip service telnet ftp snmp
The following table lists ip service command options for specifying TCP/UDP services and also includes
the well-known port number associated with each service:
service port
ftp 21
ssh 22
telnet 23
http 80
secure-http 443
udp-relay 67
network-time 123
snmp 161
proprietary 1024
proprietary 1025
Managing IP
The following sections describe IP commands that can be used to monitor and troubleshoot IP forwarding
on the switch.
The following table is provided to identify the various ICMP messages, and their type and code:
In addition to the icmp type command, several commonly used ICMP messages have been separate CLI
commands for convenience. These commands are listed with the ICMP message name, type, and code:
These commands are entered as the icmp type command, only without specifying a type or code. The
echo, timestamp, and address mask commands have options for distinguishing between a request or a
reply, and the unreachable command has options distinguishing between a network, host, protocol, or port.
For example, to enable an echo request message, enter the following:
-> icmp echo request enable
Note. Enabling host-unreachable and net-unreachable messages are not recommended as it can cause
the switch instability due to high-CPU conditions depending upon the volume of traffic required by these
messages.
See Chapter 34, “IP Commands,” for specifics on the ICMP message commands.
To disable all ICMP messages, enter the same command with the disable keyword. For example:
-> icmp messages enable
Likewise, to set the Timestamp Reply minimum packet gap to 100 microseconds, enter the following:
-> icmp timestamp reply min-pkt-gap 100
When you ping a device, the device IP address or host name (maximum of 19 characters) is required. You
can also specify the following parameters:
• count -- Use the count keyword to set the number of frames to be transmitted
• size -- Use the size keyword to set the size, in bytes, of the data portion of the packet sent for this ping.
You can specify a size or a range of sizes up to 60000
• interval -- Use the interval keyword to set the frequency, in seconds, that the switch uses to poll the
host.
• time-out -- Use the time-out keyword to set the number of seconds the program must wait for a
response before timing out.
• source-ip -- Use the source-ip keyword to set the source IP address for receiving the ping packets. The
source IP can also be a Loopback address
• tos -- Use the tos keyword to set the type of service value for the ping packet being transmitted.
• dont-fragment -- Use the dont-fragment keyword to set the DF bit in the transmitted ping packet
• pattern - Use the pattern keyword to set the data pattern string
-> ping 10.0.0.1 pattern AB1234
• sweep-range - Use the sweep-range keyword to set the sweep range size. The sweep range requires 3
parameters. start_size specifies the size in bytes of the first packet to be sent, diff_size specifies the
increment factor of size for the next packet, and end_size specifies the maximum size of the packet.
Here, if sweep-range is used in the ping command, then the count and size parameters become
redundant. So if sweep-range is used, then count and size parameters are not configurable. Also the
values for minsize (greater than 4 bytes) and maxSize (greater than minimum size) are validated.
-> ping 10.0.0.1 sweep-range 10 110 20
For example, to send a ping with a count of 2, a size of 32 bytes, an interval of 2 seconds, and a time-out
of 10 seconds you would enter:
-> ping 172.22.2.115 count 2 size 32 interval 2 timeout 10
Note. If you change the default values, they only apply to the current ping. The next time you use the ping
command, the default values are used unless you enter different values again.
Tracing an IP Route
The traceroute command is used to find the path taken by an IP packet from the local switch to a
specified destination. This command displays the individual hops to the destination as well as some timing
information. When using this command, enter the name of the destination as part of the command line
(either the IP address or host name). Use the optional max-hop parameter to set a
maximum hop count to the destination. If the trace reaches this maximum hop count without reaching the
destination, the trace stops.
For example, to perform a traceroute to a device with an IP address of 172.22.2.115 with a maximum hop
count of 10 you would enter:
-> traceroute 172.22.2.115 max-hop 10
TWAMP on OmniSwitch
The TWAMP protocol operates based on four logical entities Server, Control Client, Sender and Reflec-
tor. TWAMP protocol uses TWAMP Control and TWAMP Test:
• TWAMP Control, establishes a session between the client and the server.
• TWAMP Test, manages the test session between the sender and receiver.
Establish Connection
Client Server
Controller TWAMP Control
On Successful On Successful
Client/Server Connection
Client/Server Connection
Accept/Process
Start/Stop test session test session
Session Session
Sender/ Reflector
Receiver
TWAMP Test
The switch can be configured to manage the TWAMP sessions. The current TWAMP implementation
supports only:
• Server and Reflector configuration
• Unauthenticated mode
• IPv4 address
• OmniSwitch 6250 and OmniSwitch 6450
In the TWAMP Server/Reflector Mode Operation, on configuring the TWAMP server on the switch, the
switch will:
• Respond to TCP open messages from various clients and establish TWAMP control connection.
• Accept TWAMP test session requests from clients and manage the sessions.
• Respond to the TWAMP test packets with TWAMP reflector test packets.
Note. Maximum 32 control sessions are allowed per switch. A control session can have 128 test sessions.
Maximum 128 test sessions are allowed per switch.
TWAMP Operation
TWAMP Control connection must be established between the Control Client and Server before initiating
any test sessions. Control Connection establishment involves the following steps:
1 The Control-Client initiates a TCP connection on TWAMP's well-known port 862 or the user config-
ured port, and the server responds with greeting message, indicating the security/integrity mode(s) it is
willing to support. Currently, only unauthenticated mode is supported.
2 The Control-Client responds with the chosen mode of communication and information supporting
integrity protection and encryption, if the mode requires them.
3 The Server responds to accept the mode and give its start time. This completes the control-connection
setup.
4 The Control-Client requests a test session with a unique TWAMP-Control message. The Server
responds with its acceptance and supporting information. More than one test session may be requested
with additional messages.
5 The Control-Client initiates all requested testing with a Start-Session message, and the Server acknowl-
edges.
6 The Session-Sender and the Session-Reflector exchange test packets according to the TWAMP-Test
protocol for each active session.
7 When appropriate, the Control-Client sends a message to stop all test sessions.
4 Encode a reflector packet with the Rx, Tx timestamp of the reflector, sequence number and the sender
fields timestamp, sequence number and TTL.
5 Transmit the reflector packet for every test packet received.
6 The session sender will receive the reflector frames and calculate the RTT, jitter, and delay metrics for
the session.
Note.
• When the TWAMP server is configured on the switch, the loopback0 IP address will be taken as the
IP address of the server.
• Only one TWAMP server can be configured on a switch at a given point of time.
• When TWAMP server port is reconfigured, a system reload is needed for the reconfigured port to
come into effect.
For more information on the CLI, refer the twamp server command in the OmniSwitch 6250/6350/6450
CLI Reference Guide.
TWAMP Server
Port: 30333
Inactivity timeout: 20 mins
Allowed-Client: 172.16.1.1/16
The TWAMP client connection information displays the client connection details such as the client IP
address, connection status, time when run, number of packets sent, number of packets received, and the
session identifier. The statistics details for the established connections is updated every two minutes. The
statistics for maximum 128 test sessions after the timeout value from the client side is updated with the
connection status as “ENDED”. To view the TWAMP client connection details, use the show twamp
server connections command. For example, to view the client connection details for the client with IP
200.200.1.1, enter:
-> show twamp server connections client 200.200.1.1
Client IP Conn Status Time of Last Run Pkts Sent Pkts Received Session Identifier
-----------------------------------------------------------------------------------------------------------
200.200.1.1 SETUP_DONE THU OCT 08 2015 19:39:13 10 10 2eb0b7b6a5c405df
200.200.1.1 SETUP_DONE THU OCT 08 2015 19:39:13 10 10 2eb0b7b6fe7fb742
Note.
- AOS supports only Many to one Dynamic NAT. Telnet, Ping, SSH, SNMP packets are not considered
for NAT packets.
- NAT is supported only in standalone switches.
- When NAT is configured, traceroute does not work with public network.
Configuring NAT
To configure NAT, QoS policy rule must be mapped with a policy condition and action using the follow-
ing commands.
• Enable NAT policy condition for a source or destination IP/network using the policy condition
command with source or destination IP address which needs to be natted.
• Enable policy action, that is, configure the source or destination IP which needs to be rewritten to
global IP, use the policy action rewrite command.
• Configure a policy rule to map the NAT condition with the action using the policy rule command. For
example,
Note. Refer to the “QoS Policy Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Reference
Guide for more information on QoS policy rule, policy condition, and policy action commands.
2 Enable NAT policy condition (cond1) for the source IP (128.110.124.120) which needs to be rewritten.
3 Enable policy action (action1) for the source IP which needs to be rewritten to global IP
(155.100.39.163).
4 Map the NAT condition with the action to the policy rule that will rewrite the source address.
When the traffic arrives on the switch with a source address of 128.110.124.120, the switch will rewrite
the source address as 155.100.39.163.
Example 2: Configuring Many-to-one NAT
For this type of translation, a single policy rule is required. A network address is given in the condition,
and a single address is given in the action.
1 Create a policy rule (nat) on the switch.
2 Enable NAT policy condition (internal) for the source IP (IP 10.0.0.0 and mask 255.0.0.0) which needs
to be rewritten. Note that the mask must be specified for the source address.
3 Enable policy action (external) for the source IP which needs to be rewritten to global IP
(143.209.92.42).
4 Map the NAT condition with the action to the policy rule that will rewrite the source address.
The policy nat will rewrite the source address for any traffic from the 10.0.0.0 network to the Internet
friendly address, 143.209.92.42. Traffic destined for the 10.0.0.0 network will be rewritten to the original
IP addresses based on the dynamic TCP/UDP port assignment.
show ip interface Displays the usability status of interfaces configured for IP.
show ip route Displays the IP Forwarding table.
show ip route-pref Displays the configured route preference of a router.
show ip router database Displays a list of all routes (static and dynamic) that exist in the IP
router database.
show ip route-pref Displays a list of all routes (static and dynamic) that exist in the IP
router database.
show ip config Displays IP configuration parameters.
show ip protocols Displays switch routing protocol information and status.
show ip service Displays the status of TCP/UDP service ports. Includes service name
and well-known port number.
show arp Displays the ARP table.
show arp filter Displays the ARP filter configuration for the switch.
show icmp control This command allows the viewing of the ICMP control settings.
show ip dos config Displays the configuration parameters of the DoS scan for the switch.
show ip dos statistics Displays the statistics on detected port scans for the switch.
show ip dos arp-poison Displays the number of attacks detected for a restricted address.
show twamp server info Displays the configuration details of the TWAMP server on the
switch.
show twamp server connections Displays the TWAMP Client connections established with the
TWAMP server on the switch at a given point of time. The TWAMP
connections can also be viewed for a specific client.
show qos nat flows Displays the flow inbound and outbound traffic details.
For more information about the displays that result from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
Internet Protocol version 6 (IPv6) is the next generation of Internet Protocol version 4 (IPv4). Both
versions are supported. Implementing IPv6 solves the limited address problem currently facing IPv4,
which provides a 32-bit address space. IPv6 increases the address space available to 128 bits.
In This Chapter
This chapter describes IPv6 and how to configure it through Command Line Interface (CLI). The CLI
commands are used in the configuration examples; for more details about the syntax of commands, see the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
This chapter provides an overview of IPv6 and includes information about the following procedures:
• Configuring an IPv6 interface (see page 29-9)
• Assigning IPv6 Addresses (see page 29-11)
• Creating a Static Route (see page 29-12)
• Configuring the Route Preference of a Router (see page 29-13)
• Configuring Route Map Redistribution (see page 29-13)
• Configuring Router Advertisement (RA) Filtering (see page 29-20)
IPv6 Specifications
Note that the maximum limit values provided in the following Specifications table are subject to available
system resources:
IPv6 Defaults
The following table lists the defaults for IPv6 configuration through the ip command.
Note that when the IPv6 interface is configured, the switch automatically generates a link-local address
for the interface. This allows for communication with other interfaces and/or devices on the same link,
but does not provide routing between interfaces.
2 Assign a unicast address to the v6if-v200 interface by using the ipv6 address command. For example:
3 Configure an IPv6 interface for VLAN 300 by using the ipv6 interface command. For example:
4 Assign a unicast address to the v6if-v300 interface by using the ipv6 address command. For example:
Note. Optional. To verify the IPv6 interface configuration, enter show ipv6 interface For example:
5 Enable RIPng for the switch by using the ipv6 load rip command. For example:
6 Create a RIPng interface for each of the IPv6 VLAN interfaces by using the ipv6 rip interface
command. For example:
-> ipv6 rip interface v6if-v200
-> ipv6 rip interface v6if-v300
IPv6 routing is now configured for VLAN 200 and VLAN 300 interfaces, but it is not active until at least
one port in each VLAN goes active.
IPv6 Overview
IPv6 provides the basic functionality that is offered with IPv4 but includes the following enhancements
and features not available with IPv4:
• Increased IP address size—IPv6 uses a 128-bit address, a substantial increase over the 32-bit IPv4
address size. Providing a larger address size also significantly increases the address space available,
thus eliminating the concern over running out of IP addresses. See “IPv6 Addressing” on page 29-5 for
more information.
• Autoconfiguration of addresses—When an IPv6 interface is created or a device is connected to the
switch, an IPv6 link-local address is automatically assigned for the interface and/or device. See “Auto
Configuration of IPv6 Addresses” on page 29-7 for more information.
• Anycast addresses—A new type of address. Packets sent to an anycast address are delivered to one
member of the anycast group.
• Simplified header format—A simpler IPv6 header format is used to keep the processing and band-
width cost of IPv6 packets as low as possible. As a result, the IPv6 header is only twice the size of the
IPv4 header despite the significant increase in address size.
• Improved support for header options—Improved header option encoding allows more efficient
forwarding, fewer restrictions on the length of options, and greater flexibility to introduce new options.
• Security improvements—Extension definitions provide support for authentication, data integrity, and
confidentiality.
• Neighbor Discovery protocol—A protocol defined for IPv6 that detects neighboring devices on the
same link and the availability of those devices. Additional information that is useful for facilitating the
interaction between devices on the same link is also detected (e.g., neighboring address prefixes,
address resolution, duplicate address detection, link MTU, and hop limit values, etc.).
This implementation of IPv6 also provides the following mechanisms to maintain compatibility between
IPv4 and IPv6:
• Dual-stack support for both IPv4 and IPv6 on the same switch.
• Configuration of IPv6 and IPv4 interfaces on the same VLAN.
• Embedded IPv4 addresses in the four lower-order bits of the IPv6 address.
The remainder of this section provides a brief overview of the new IPv6 address notation and autoconfigu-
ration of addresses.
IPv6 Addressing
One of the main differences between IPv6 and IPv4 is that the address size has increased from 32 bits to
128 bits. Going to a 128-bit address also increases the size of the address space to the point where running
out of IPv6 addresses is not a concern.
The following types of IPv6 addresses are supported:
Link-local—A link-local address is a private unicast address that identifies an interface or device on the
local network. This type of address allows communication with devices and/or neighboring nodes that are
attached to the same physical link. Note that when the communication is between two nodes that are not
attached to the same link, both nodes must have a configured global unicast address. Routing between
link-local addresses is not available because link-local addresses are not known or advertised to the
general network.
Unicast—Standard unicast addresses, similar to IPv4.
Multicast—Addresses that represent a group of devices. Traffic sent to a multicast address is delivered to
all members of the multicast group.
Anycast—Traffic that is sent to this type of address is delivered to one member of the anycast group. The
device that receives the traffic is usually the one that is easiest to reach as determined by the active rout-
ing protocol.
Note. IPv6 does not support the use of broadcast addresses. This functionality is replaced using improved
multicast addressing capabilities.
IPv6 address types are identified by the high-order bits of the address, as shown in the following table:
Note that anycast addresses are unicast addresses that are not identifiable by a known prefix.
2 1234:531F:0:0:BCD2:F34A::
With IPv6 addresses that have long strings of zeros, the benefit of zero compression is more dramatic. For
example, address FF00:0:0:0:0:0:4501:32 becomes FF00::4501:32.
Note that hexadecimal notation used for IPv6 addresses resembles the notation which is used for MAC
addresses. However, it is important to remember that IPv6 addresses still identify a device at the Layer 3
level and MAC addresses identify a device at the Layer 2 level.
Another supported IPv6 address notation includes embedding an IPv4 address as the four lower-order bits
of the IPv6 address. This is especially useful when dealing with a mixed IPv4/IPv6 network. For example:
0:0:0:0:0:0:212.100.13.6
Refer to the ipv6 interface command page in the OmniSwitch 6250/6350/6450 CLI Reference Guide
for more details regarding these parameters.
• Each VLAN can have one IPv6 interface. Configuring both an IPv4 and IPv6 interface on the same
VLAN is allowed. Note that the VLAN interfaces of both types are not active until at least one port
associated with the VLAN goes active.
• A link-local address is automatically configured for an IPv6 interface when the interface is configured.
For more information regarding how this address is formed, see “Auto Configuration of IPv6
Addresses” on page 29-7.
• Assigning more than one IPv6 address to a single IPv6 interface is allowed.
• Assigning the same link-local address to multiple interfaces is allowed. Each global unicast prefix,
however, can only exist on one interface. For example, if an interface for a VLAN 100 is configured
with an address 4100:1000::1/64, an interface for VLAN 200 cannot have an address 4100:1000::2/64.
• Each IPv6 interface anycast address must also have a unique prefix. However, multiple devices may
share the same anycast address prefix to identify themselves as members of the anycast group.
To create an IPv6 interface for a VLAN, enter ipv6 interface followed by an interface name, then
followed by a VLAN ID. For example, the following command creates an IPv6 interface for VLAN 200:
-> ipv6 interface v6if-v200 vlan 200
Use the show ipv6 interface command to verify the interface configuration for the switch. For more infor-
mation about this command, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
When an existing interface name is specified with the ipv6 interface command, the command modifies
specified parameters for that interface. If an unknown interface name is entered along with an existing
VLAN parameter, a new interface is created with the name specified.
In the above example, 4100:1000:: is specified as the subnet prefix and 20 is the interface identifier. Note
that the IPv6 address is expressed using CIDR notation to specify the prefix length. In the above example,
/64 indicates a subnet prefix length of 64 bits.
To use the MAC address of an interface or device as the interface ID, specify the eui-64 option with this
command. For example:
-> ipv6 address 4100:1000::/64 eui-64 v6if-v200
The above command example creates address 4100:1000::2d0:95ff:fe12:fab2/64 for interface v6if-v200.
Note the following when configuring IPv6 addresses:
• It is possible to assign more than one address to a single interface.
• Any field of an address may contain all zeros or all ones. The exception to this is the interface identi-
fier portion of the address, which cannot be all zeros. If the eui-64 option is specified with the ipv6
address command, this is not an issue.
• The EUI-64 interface identifier takes up the last 64 bits of the 128-bit IPv6 address. If the subnet prefix
combined with the EUI-64 interface ID is longer than 128 bits, an error occurs and the address is not
created.
• A subnet router anycast address is automatically created when a global unicast address is assigned to an
interface. The anycast address is derived from the global address by adding an interface ID of all zeros
to the prefix of the global address. For example, the global address 4100:1000::20/64 generates the
anycast address 4100:1000::/64.
• Devices, such as a PC, are eligible for stateless autoconfiguration of unicast addresses in addition to the
link-local address. If this type of configuration is in use on the network, manual configuration of
addresses is not required.
• IPv6 VLAN interfaces are only eligible for stateless autoconfiguration of their link-local addresses.
Manual configuration of addresses is required for all additional addresses.
See “IPv6 Addressing” on page 29-5 for an overview of IPv6 address notation. Refer to RFC 4291 for
more technical address information.
Note that the subnet router anycast address is automatically deleted when the last unicast address of the
same subnet is removed from the interface.
Note that in the example above the IPv6 interface name for the gateway was included. This parameter is
required only when a link local address is specified as the gateway.
When you create a static route, the default metric value of 1 is used. However, you can change the priority
of the route by increasing its metric value. The lower the metric value, the higher the priority. This metric
is added to the metric cost of the route. The metric range is 1 to 15. For example:
-> ipv6 static-route 212:95:5::/64 gateway fe80::2d0:95ff:fe6a:f458 v6if-137 metric
3
Static routes do not age out of the IPv6 Forwarding table; you must delete them from the table. Use the
no ipv6 static-route command to delete a static route. You must specify the destination IPv6 address of
the route as well as the IPv6 address of the first hop (gateway). For example, to delete a static route to
IPv6 address 212:95:5::/64 through gateway fe80::2d0:95ff:fe6a:f458 on interface v6if-137, you
would enter:
-> no ip static-route 212:95:5::/64 gateway fe80::2d0:95ff:fe6a:f458 v6if-137
The IPv6 Forwarding table includes routes learned through RIP as well as any static routes that are config-
ured. Use the show ipv6 routes command to display the IPv6 Forwarding table.
Note. A static route is not active unless the gateway it is using is active.
To display the current route preference configuration, use the show ipv6 route-pref command:
-> show ipv6 route-pref
Protocol Route Preference Value
------------+------------------------
Local 1
Static 2
RIP 120
2 Configure redistribution to apply a route map, as described in “Configuring Route Map Redistribu-
tion” on page 29-18.
Refer to the “IP Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Reference Guide for more
information about the ip route-map command parameters and usage guidelines.
Once a route map is created, it is then applied using the ipv6 redist command. See “Configuring Route
Map Redistribution” on page 29-18 for more information.
The above command creates the static-to-rip route map, assigns a sequence number of 10 to the route
map, and specifies a permit action.
To optionally filter routes before redistribution, use the ip route-map command with a match parameter
to configure match criteria for incoming routes. For example,
-> ip route-map static-to-rip sequence-number 10 match tag 8
The above command configures a match statement for the static-to-rip route map to filter routes based on
their tag value. When this route map is applied, only Static routes with a tag value of eight are redistrib-
uted into the RIP network. All other routes with a different tag value are dropped.
Note. Configuring match statements is not required. However, if a route map does not contain any match
statements and the route map is applied using the ipv6 redist command, the router redistributes all routes
into the network of the receiving protocol.
To modify route information before it is redistributed, use the ip route-map command with a set parame-
ter. For example,
-> ip route-map static-to-rip sequence-number 10 set tag 5
The above command configures a set statement for the static-to-rip route map that changes the route tag
value to five. Because this statement is part of the static-to-rip route map, it is only applied to routes that
have an existing tag value equal to eight.
The following is a summary of the commands used in the above examples:
-> ip route-map static-to-rip sequence-number 10 action permit
-> ip route-map static-to-rip sequence-number 10 match tag 8
-> ip route-map static-to-rip sequence-number 10 set tag 5
To delete a specific sequence number within a route map, enter no ip route-map followed by the route
map name, then sequence-number followed by the actual number. For example, the following command
deletes sequence 10 from the redistipv4 route map:
-> no ip route-map redistipv4 sequence-number 10
Note that in the above example, the redistripv4 route map is not deleted. Only those statements associated
with sequence 10 are removed from the route map.
To delete a specific statement within a route map, enter no ip route-map followed by the route map name,
then sequence-number followed by the sequence number for the statement, then either match or set and
the match or set parameter and value. For example, the following command deletes only the match tag 8
statement from route map redistipv4 sequence 10:
-> no ip route-map redistipv4 sequence-number 10 match tag 8
To configure a new sequence of statements for an existing route map, specify the same route map name
but use a different sequence number. For example, the following command creates a new sequence 20 for
the rm_1 route map:
-> ip route-map rm_1 sequence-number 20 action permit
-> ip route-map rm_1 sequence-number 20 match ipv4-interface to-finance
-> ip route-map rm_1 sequence-number 20 set metric 5
Sequence 10 and sequence 20 are both linked to route map rm_1 and are processed in ascending order
according to their sequence number value. Note that there is an implied logical OR between sequences. As
a result, if there is no match for the tag value in sequence 10, then the match interface statement in
sequence 20 is processed. However, if a route matches the tag 8 value, then sequence 20 is not used. The
set statement for whichever sequence was matched is applied.
A route map sequence may contain multiple match statements. If these statements are of the same kind
(e.g., match tag 5, match tag 8, etc.) then a logical OR is implied between each like statement. If the match
statements specify different types of matches (e.g. match tag 5, match ip4 interface to-finance, etc.), then a
logical AND is implied between each statement. For example, the following route map sequence will
redistribute a route if its tag is either 8 or 5:
-> ip route-map rm_1 sequence-number 10 action permit
-> ip route-map rm_1 sequence-number 10 match tag 5
-> ip route-map rm_1 sequence-number 10 match tag 8
The following route map sequence will redistribute a route if the route has a tag of 8 or 5 and the route
was learned on the IPv6 interface to-finance:
-> ip route-map rm_1 sequence-number 10 action permit
-> ip route-map rm_1 sequence-number 10 match tag 5
-> ip route-map rm_1 sequence-number 10 match tag 8
-> ip route-map rm_1 sequence-number 10 match ipv6-interface to-finance
To add addresses to an access list, use the ip access-list address (IPv4) or the ipv6 access-list address
(IPv6) command. For example, the following commands add addresses to an existing access list:
-> ip access-list ipaddr address 10.0.0.0/8
-> ipv6 access-list ip6addr address 2001::/64
Use the same access list name each time the above commands are used to add additional addresses to the
same access list. In addition, both commands provide the ability to configure if an address and/or its
matching subnet routes are permitted (the default) or denied redistribution. For example:
-> ip access-list ipaddr address 16.24.2.1/16 action deny redist-control all-
subnets
-> ipv6 access-list ip6addr address 2001::1/64 action permit redist-control no-
subnets
For more information about configuring access list commands, see the “IP Commands” chapter in the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
Note. A router automatically becomes an Autonomous System Border Router (ASBR) when redistribu-
tion is configured on the router.
A source protocol is a protocol from which the routes are learned. A destination protocol is the one into
which the routes are redistributed. Make sure that both protocols are loaded and enabled before configur-
ing redistribution.
Redistribution applies criteria specified in a route map to routes received from the source protocol. There-
fore, configuring redistribution requires an existing route map. For example, the following command
configures the redistribution of Static routes into the RIPng network using the static-to-rip route map:
-> ipv6 redist static into rip route-map static-to-rip
Static routes received by the router interface are processed based on the contents of the static-to-rip route
map. Routes that match criteria specified in this route map are either allowed or denied redistribution into
the RIPng network. The route map may also specify the modification of route information before the route
is redistributed. See “Using Route Maps” on page 29-14 for more information.
To remove a route map redistribution configuration, use the no form of the ipv6 redist command. For
example:
-> no ipv6 redist static into rip route-map static-to-rip
Use the show ipv6 redist command to verify the redistribution configuration:
-> show ipv6 redist
Source Destination
Protocol Protocol Status Route Map
------------+------------+---------+--------------------
localIPv6 RIPng Enabled ipv6rm
Static RIPng Enabled static-to-rip
The resulting static-to-rip route map redistribution configuration does the following:
• Denies the redistribution of routes with a tag set to five.
• Redistributes into RIPng all routes learned on the intf_static interface and sets the metric for such
routes to 255.
• Redistributes into RIPng all other routes (those not processed by sequence 10 or 20) and sets the tag for
such routes to eight.
This enables RA filtering on VLAN 5. All RAs received on the VLAN will be dropped.
To specify a trusted port or linkagg, specify the port or linkagg using the ipv6 ra-filter command with the
'trusted-port' option. For. For example:
-> ipv6 ra-filter vlan 5 trusted-port 1/22
This specifies that port 1/22 is trusted port in VLAN 5. RAs received on this port will be forwarded to all
other clients connected through the VLAN. RAs received on any other port will still be dropped.
To remove a trusted port, use the following command. This will remove port 2 as a trusted port on VLAN
5.
-> no ipv6 ra-filter vlan 5 trusted-port 1/22
To disable RA filtering on a VLAN, use the no ipv6 ra-filter command. For example:
-> no ipv6 ra-filter vlan 5
show ipv6 rip Displays the RIPng status and general configuration parameters.
show ipv6 redist Displays the route map redistribution configuration.
show ipv6 interface Displays the status and configuration of IPv6 interfaces.
show ipv6 routes Displays the IPv6 Forwarding Table.
show ipv6 route-pref Displays the configured route preference of a router.
show ipv6 router database Displays a list of all routes (static and dynamic) that exist in the IPv6
router database.
show ipv6 prefixes Displays IPv6 subnet prefixes used in router advertisements.
show ipv6 hosts Displays the IPv6 Local Host Table.
show ipv6 neighbors Displays the IPv6 Neighbor Table.
show ipv6 traffic Displays statistics for IPv6 traffic.
show ipv6 icmp statistics Displays ICMP6 statistics.
show ipv6 pmtu table Displays the IPv6 Path MTU Table.
show ipv6 tcp ports Displays TCP Over IPv6 Connection Table. Contains information
about existing TCP connections between IPv6 endpoints.
show ipv6 udp ports Displays the UDP Over IPv6 Listener Table. Contains information
about UDP/IPv6 endpoints.
show ipv6 ra-filter vlan Displays the list of VLANs configured for RA filtering.
show ipv6 ra-filter counters Displays the counter statistics of the NIs which are up.
For more information about the displays that result from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
Routing Information Protocol (RIP) is a widely used Interior Gateway Protocol (IGP) that uses hop count
as its routing metric. RIP-enabled routers update neighboring routers by transmitting a copy of their own
routing table. The RIP routing table uses the most efficient route to a destination, that is, the route with the
fewest hops and longest matching prefix.
The switch supports RIP version 1 (RIPv1), RIP version 2 (RIPv2), and RIPv2 that is compatible with
RIPv1. It also supports text key and MD5 authentication, on an interface basis, for RIPv2.
In This Chapter
This chapter describes RIP and how to configure it through the Command Line Interface (CLI). It includes
instructions for configuring basic RIP routing and fine-tuning RIP by using optional RIP configuration
parameters (e.g., RIP send/receive option and RIP interface metric). It also details RIP redistribution. CLI
commands are used in the configuration examples; for more details about the syntax of commands, see the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
This chapter provides an overview of RIP and includes information about the following procedures:
• RIP Routing
– Loading RIP (see page 30-7)
– Enabling RIP (see page 30-7)
– Creating a RIP Interface (see page 30-7)
– Enabling a RIP Interface (see page 30-8)
• RIP Options
– Configuring the RIP Forced Hold-Down Interval (see page 30-10)
– Configuring the RIP Update Interval (see page 30-10)
– Configuring the RIP Invalid Timer (see page 30-10)
– Configuring the RIP Garbage Timer (see page 30-11)
– Configuring the RIP Hold-Down Timer (see page 30-11)
– Enabling a RIP Host Route (see page 30-11)
• RIP Redistribution
– Configuring Route Redistribution (see page page 30-12)
• RIP Security
– Configuring Authentication Type (see page 30-18)
– Configuring Passwords (see page 30-18)
RIP Specifications
RFCs Supported RFC 1058–RIP v1
RFC 2453–RIP v2
RFC 1722–RIP v2 Protocol Applicability Statement
RFC 1724–RIP v2 MIB Extension
Platforms Supported OmniSwitch 6250, 6350, 6450
Maximum Number of RIP Peers 10
Maximum Number of RIP Interfaces 10
Maximum Number of RIP Routes 256
Maximum number of ECMP gateways 4
RIP Defaults
The following table lists the defaults for RIP configuration through the ip rip command.
1 Create VLAN 1 with a description (e.g., VLAN 1) by using the vlan command. For example:
2 Create VLAN 2 with a description (e.g., VLAN 2) by using the vlan command. For example:
3 Assign an active port to VLAN 1 by using the vlan port default command. For example, the follow-
ing command assigns port 1 on slot 1 to VLAN 1:
-> vlan 1 port default 1/1
4 Assign an active port to VLAN 2 by using the vlan port default command. For example, the follow-
ing command assigns port 2 on slot 1 to VLAN 2:
-> vlan 2 port default 1/2
5 Configure an IP interface to enable IP routing on a VLAN by using the ip interface command. For
example:
-> ip interface vlan-1 address 171.10.1.1 vlan 1
6 Configure an IP interface to enable IP routing on a VLAN by using the ip interface command. For
example:
-> ip interface vlan-2 address 171.11.1.1 vlan 2
7 Load RIP into the switch memory by using the ip load rip command. For example:
8 Enable RIP on the switch by using the ip rip status command. For example:
9 Create a RIP interface on VLAN 1 by using the ip rip interface command. For example:
10 Enable the RIP interface by using the ip rip interface status command. For example:
11 Create an RIP interface on VLAN 2 by using the ip rip interface command. For example:
Note. For more information on VLANs and router ports, see Chapter 4, “Configuring VLANs.”
RIP Overview
In switching, traffic may be transmitted from one media type to another within the same VLAN. Switch-
ing happens at Layer 2, the link layer; routing happens at Layer 3, the network layer. In IP routing, traffic
can be transmitted across VLANs. When IP routing is enabled, the switch uses routing protocols to build
routing tables that keep track of stations in the network and decide the best path for forwarding data. When
the switch receives a packet to be routed, it strips off the MAC header and examines the IP header. It looks
up the source/destination address in the routing table, and then adds the appropriate MAC address to the
packet. Calculating routing tables and stripping/adding MAC headers to packets is performed by switch
software.
IP is associated with several Layer 3 routing protocols. RIP is built into the base code loaded onto the
switch. Others are part of Alcatel’s optional Advanced Routing Software. RIP is an IGP that defines how
routers exchange information. RIP makes routing decisions by using a “least-cost path” method. RIPv1
and RIPv2 services allow the switch to learn routing information from neighboring RIP routers. For more
information and instructions for configuring RIP, see “RIP Routing” on page 30-6.
When RIP is initially enabled on a switch, it issues a request for routing information, and listens for
responses to the request. If a switch configured to supply RIP hears the request, it responds with a
response packet based on information in its routing database. The response packet contains destination
network addresses and the routing metric for each destination. When a RIP response packet is received,
RIP takes the information and rebuilds the switch’s routing database, adding new routes and “better”
(lower metric) routes to destinations already listed in the database.
RIP uses a hop count metric to measure the distance to a destination. In the RIP metric, a switch adver-
tises directly connected networks at a metric of 1. Networks that are reachable through one other gateway
are 2 hops, networks that are reachable through two gateways are 3 hops, etc. Thus, the number of hops (or
hop count) along a path from a given source to a given destination refers to the number of networks that
are traversed by a datagram along that path. When a switch receives a routing update that contains a new
or changed destination network entry, the switch adds one to the metric value indicated in the update and
enters the network in the routing table. After updating its routing table, the switch immediately begins
transmitting routing updates to inform other network switches of the change. These updates are sent inde-
pendently of the regularly scheduled updates. By default, RIP packets are broadcast every 30 seconds,
even if no change has occurred anywhere in a route or service.
RIP deletes routes from the database if the next switch to that destination says the route contains more than
15 hops. In addition, all routes through a gateway are deleted by RIP if no updates are received from that
gateway for a specified time period. If a gateway is not heard from for 120 seconds, all routes from that
gateway are placed in a hold-down state. If the hold-down timer value is exceeded, the routes are deleted
from the routing database. These intervals also apply to deletion of specific routes.
RIP Version 2
RIP version 2 (RIPv2) adds additional capabilities to RIP. Not all RIPv2 enhancements are compatible
with RIPv1. To avoid supplying information to RIPv1 routes that could be misinterpreted, RIPv2 can only
use non-compatible features when its packets are multicast. Multicast is not supported by RIPv1. On inter-
faces that are not compatible with IP multicast, the RIPv1-compatible packets used do not contain poten-
tially confusing information. RIPv2 enhancements are listed below.
• Next Hop—RIPv2 can advertise a next hop other than the switch supplying the routing update. This
capability is useful when advertising a static route to a silent switch not using RIP, since packets pass-
ing through the silent switch do not have to cross the network twice.
• Network Mask—RIPv1 assumes that all subnetworks of a given network have the same network mask.
It uses this assumption to calculate the network masks for all routes received. This assumption prevents
subnets with different netmasks from being included in RIP packets. RIPv2 adds the ability to specify
the network mask with each network in a packet. Because RIPv1 switches ignore the network mask in
RIPv2 packets, their calculation of the network mask could possibly be wrong. For this reason, RIPv1-
compatible RIPv2 packets cannot contain networks that would be misinterpreted by RIPv1. These
networks must only be provided in native RIPv2 packets that are multicast.
• Authentication—RIPv2 packets can contain an authentication key that may be used to verify the valid-
ity of the supplied routing data. Authentication may be used in RIPv1-compatible RIPv2 packets, but
RIPv1 switches will ignore authentication information. Authentication is a simple password in which
an authentication key of up to 16 characters is included in the packet. If this key does not match the
configured authentication key, the packet is discarded. For more information on RIP authentication, see
“RIP Security” on page 30-18.
• IP Multicast—IP Multicast Switching (IPMS) is a one-to-many communication technique employed by
emerging applications such as video distribution, news feeds, netcasting, and resource discovery.
Unlike unicast, which sends one packet per destination, multicast sends one packet to all devices in any
subnetwork that has at least one device requesting the multicast traffic. For more information on IPMS,
see Chapter 36, “Configuring IP Multicast Switching.”
RIP Routing
IP routing requires IP router interfaces to be configured on VLANs and a routing protocol to be enabled
and configured on the switch. RIP also requires a RIP interface to be created and enabled on the routing
interface. In the illustration below, a router interface and RIP interface have been configured on each
VLAN. Therefore, workstations connected to ports on VLAN 1 on Switch 1 can communicate with VLAN
2; workstations connected to ports on VLAN 3 on Switch 2 can communicate with VLAN 2. Also, ports
from both switches have been assigned to VLAN 2, and a physical connection has been made between the
switches. Therefore, workstations connected to VLAN 1 on Switch 1 can communicate with workstations
connected to VLAN 3 on Switch 2.
Switch 1 Switch 2
Router interface/
= RIP Interface
Physical
VLAN 1 VLAN 2 Connection VLAN 3
VLAN 2
110.0.0.0 120.0.0.0 130.0.0.0
120.0.0.0
RIP Routing
Loading RIP
When the switch is initially configured, RIP must be loaded into the switch memory. Use the ip load rip
command to load RIP.
To remove RIP from the switch memory, you must manually edit the boot.cfg file. The boot.cfg file is an
ASCII text-based file that controls many of the switch parameters. Open the file and delete all references
to RIP. You must reboot the switch when this is complete.
Note. In simple networks where only IP forwarding is required, you may not want to use RIP. If you are
not using RIP, it is best not to load it to save switch resources.
Enabling RIP
RIP is disabled by default. Use the ip rip status command to enable RIP routing on the switch. For exam-
ple:
-> ip rip status enable
Use the ip rip status disable command to disable RIP routing on the switch. Use the show ip rip
command to display the current RIP status.
Use the no ip rip interface command to delete a RIP interface. Use the show ip rip interface command
to display configuration and error information for a RIP interface.
Note. You can create a RIP interface even if an IP router interface has not been configured. However, RIP
will not function unless a RIP interface is created and enabled on an IP router interface. See Chapter 4,
“Configuring VLANs,” and Chapter 25, “Configuring IP,” for more information.
To disable an RIP interface, use the disable keyword with the ip rip interface status command. For
example to disable RIP routing on a RIP interface rip-1 you would enter:
-> ip rip interface rip-1 status disable
• both. Both RIPv1 and RIPv2 packets will be received by the switch.
• none. Interface ignores any RIP packets received.
The default RIP receive option is both.
Note. When you configure a metric for a RIP interface, this metric cost is added to the metric of the
incoming route.
Use the ip rip interface metric command to configure the RIP metric or cost for routes generated by a
RIP interface. Enter the IP address of the RIP interface as well as a metric value. For example, to set a
metric value of 2 for the RIP interface rip-1 you would enter:
-> ip rip interface rip-1 metric 2
RIP Options
The following sections detail procedures for configuring RIP options. RIP must be loaded and enabled on
the switch before you can configure any of the RIP configuration options.
Configuring Redistribution
It is possible to configure the RIP protocol to advertise routes learned from other routing protocols into the
RIP network. Such a process is referred to as route redistribution and is configured using the ip redist
command.
Redistribution uses route maps to control how external routes are learned and distributed. A route map
consists of one or more user-defined statements that can determine which routes are allowed or denied
access to the RIP network. In addition a route map may also contain statements that modify route parame-
ters before they are redistributed.
When a route map is created, it is given a name to identify the group of statements that it represents. This
name is required by the ip redist command. Therefore, configuring route redistribution involves the
following steps:
1 Create a route map, as described in “Using Route Maps” on page 30-12.
2 Configure redistribution to apply a route map, as described in “Configuring Route Map Redistribu-
tion” on page 30-16.
Refer to the “IP Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Reference Guide for more
information about the ip route-map command parameters and usage guidelines.
Once a route map is created, it is then applied using the ip redist command. See “Configuring Route Map
Redistribution” on page 30-16 for more information.
The above command creates the static-to-rip route map, assigns a sequence number of 10 to the route
map, and specifies a permit action.
To optionally filter routes before redistribution, use the ip route-map command with a match parameter
to configure match criteria for incoming routes. For example,
-> ip route-map static-to-rip sequence-number 10 match tag 8
The above command configures a match statement for the static-to-rip route map to filter routes based on
their tag value. When this route map is applied, only Staic routes with a tag value of eight are redistrib-
uted into the RIP network. All other routes with a different tag value are dropped.
Note. Configuring match statements is not required. However, if a route map does not contain any match
statements and the route map is applied using the ip redist command, the router redistributes all routes
into the network of the receiving protocol.
To modify route information before it is redistributed, use the ip route-map command with a set parame-
ter. For example,
-> ip route-map static-to-rip sequence-number 10 set tag 5
The above command configures a set statement for the static-to-rip route map that changes the route tag
value to five. Because this statement is part of the static-to-rip route map, it is only applied to routes that
have an existing tag value equal to eight.
The following is a summary of the commands used in the above examples:
-> ip route-map static-to-rip sequence-number 10 action permit
-> ip route-map static-to-rip sequence-number 10 match tag 8
-> ip route-map static-to-rip sequence-number 10 set tag 5
To delete a specific sequence number within a route map, enter no ip route-map followed by the route
map name, then sequence-number followed by the actual number. For example, the following command
deletes sequence 10 from the redistipv4 route map:
-> no ip route-map redistipv4 sequence-number 10
Note that in the above example, the redistripv4 route map is not deleted. Only those statements associated
with sequence 10 are removed from the route map.
To delete a specific statement within a route map, enter no ip route-map followed by the route map name,
then sequence-number followed by the sequence number for the statement, then either match or set and
the match or set parameter and value. For example, the following command deletes only the match tag 8
statement from route map redistipv4 sequence 10:
-> no ip route-map redistipv4 sequence-number 10 match tag 8
To configure a new sequence of statements for an existing route map, specify the same route map name
but use a different sequence number. For example, the following command creates a new sequence 20 for
the rm_1 route map:
-> ip route-map rm_1 sequence-number 20 action permit
-> ip route-map rm_1 sequence-number 20 match ipv4-interface to-finance
-> ip route-map rm_1 sequence-number 20 set metric 5
Sequence 10 and sequence 20 are both linked to route map rm_1 and are processed in ascending order
according to their sequence number value. Note that there is an implied logical OR between sequences. As
a result, if there is no match for the tag value in sequence 10, then the match interface statement in
sequence 20 is processed. However, if a route matches the tag 8 value, then sequence 20 is not used. The
set statement for whichever sequence was matched is applied.
A route map sequence may contain multiple match statements. If these statements are of the same kind
(e.g., match tag 5, match tag 8, etc.) then a logical OR is implied between each like statement. If the match
statements specify different types of matches (e.g. match tag 5, match ip4 interface to-finance, etc.), then a
logical AND is implied between each statement. For example, the following route map sequence will
redistribute a route if its tag is either 8 or 5:
-> ip route-map rm_1 sequence-number 10 action permit
-> ip route-map rm_1 sequence-number 10 match tag 5
-> ip route-map rm_1 sequence-number 10 match tag 8
The following route map sequence will redistribute a route if the route has a tag of 8 or 5 and the route
was learned on the IPv4 interface to-finance:
-> ip route-map rm_1 sequence-number 10 action permit
-> ip route-map rm_1 sequence-number 10 match tag 5
-> ip route-map rm_1 sequence-number 10 match tag 8
-> ip route-map rm_1 sequence-number 10 match ipv4-interface to-finance
To add addresses to an access list, use the ip access-list address (IPv4) or the ipv6 access-list address
(IPv6) command. For example, the following commands add addresses to an existing access list:
-> ip access-list ipaddr address 16.24.2.1/16
-> ipv6 access-list ip6addr address 2001::1/64
Use the same access list name each time the above commands are used to add additional addresses to the
same access list. In addition, both commands provide the ability to configure if an address and/or its
matching subnet routes are permitted (the default) or denied redistribution. For example:
-> ip access-list ipaddr address 16.24.2.1/16 action deny redist-control all-
subnets
-> ipv6 access-list ip6addr address 2001::1/64 action permit redist-control no-
subnets
For more information about configuring access list commands, see the “IP Commands” chapter in the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
RIP routes received by the router interface are processed based on the contents of the static-to-rip route
map. Routes that match criteria specified in this route map are either allowed or denied redistribution into
the RIP network. The route map may also specify the modification of route information before the route is
redistributed. See “Using Route Maps” on page 30-12 for more information.
To remove a route map redistribution configuration, use the no form of the ip redist command. For exam-
ple:
-> no ipv6 redist static into rip route-map static-to-rip
Source Destination
Protocol Protocol Status Route Map
------------+------------+---------+--------------------
The resulting static-to-rip route map redistribution configuration does the following:
• Denies the redistribution of routes with a tag set to five.
• Redistributes into RIP all routes learned on the intf_static interface and sets the metric for such routes
to 255.
• Redistributes into RIP all other routes (those not processed by sequence 10 or 20) and sets the tag for
such routes to eight.
RIP Security
By default, there is no authentication used for a RIP. However, you can configure a password for a RIP
interface. To configure a password, you must first select the authentication type (simple or MD5), and then
configure a password.
To configure the RIP interface rip-1 for MD5 authentication you would enter:
-> ip rip interface rip-1 md5 auth-type md5
Configuring Passwords
If you configure simple or MD5 authentication you must configure a text string that will be used as the
password for the RIP interface. If a password is used, all switches that are intended to communicate with
each other must share the same password.
After configuring the interface for simple authentication as described above, configure the password for
the interface by using the ip rip interface auth-key command. Enter the IP address of the RIP interface,
and then enter a 16-byte text string. For example to configure a password “nms” you would enter:
-> ip rip interface rip-1 auth-key nms
show ip rip Displays the RIP status and general configuration parameters (e.g.,
forced hold-down timer).
show ip rip routes Displays the RIP routing database. The routing database contains all
the routes learned through RIP.
show ip rip interface Displays the RIP interface status and configuration.
show ip rip peer Displays active RIP neighbors (peers).
show ip redist Displays the currently configured RIP redistribution filters.
For more information about the displays that result from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
Router Discovery Protocol (RDP) is an extension of ICMP that allows end hosts to discover routers on
their networks. This implementation of RDP supports the router requirements as defined in RFC 1256.
In This Chapter
This chapter describes the RDP feature and how to configure RDP parameters through the Command Line
Interface (CLI). CLI commands are used in the configuration examples; for more details about the syntax
of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
The following procedures are described:
• “Enabling/Disabling RDP” on page 31-8.
• “Creating an RDP Interface” on page 31-8.
• “Specifying an Advertisement Destination Address” on page 31-9.
• “Defining the Advertisement Interval” on page 31-9.
• “Setting the Advertisement Lifetime” on page 31-10.
• “Setting the Preference Levels for Router IP Addresses” on page 31-10.
• “Verifying the RDP Configuration” on page 31-11.
RDP Specifications
RFCs Supported RFC 1256–ICMP Router Discovery Messages
Platforms Supported OmniSwitch 6250, 6350, 6450
Router advertisements Supported
Host solicitations Only responses to solicitations supported.
Maximum number of RDP interfaces per One for each available IP interface configured
switch on the switch.
Advertisement destination addresses 224.0.0.1 (all systems multicast)
255.255.255.255 (broadcast)
RDP Defaults
Parameter Description CLI Command Default Value/Comments
RDP status for the switch ip router-discovery Disabled
RDP status for switch interfaces ip router-discovery Disabled
(router VLAN IP addresses) interface
Advertisement destination address ip router-discovery All systems multicast (224.0.0.1)
for an active RDP interface. interface advertise-
ment-address
Maximum time between advertise- ip router-discovery 600 seconds
ments sent from an active RDP inter- interface max-adver-
face tisement-interval
Minimum time between advertise- ip router-discovery 450 seconds
ments sent from an active RDP inter- interface min-adver- (0.75 * maximum advertisement interval)
face tisement-interval
Maximum time IP addresses con- ip router-discovery 1800 seconds
tained in an advertisement packet are interface advertise- (3 * maximum advertisement interval)
considered valid ment-lifetime
Preference level for IP addresses ip router-discovery 0
contained in an advertisement packet interface preference-
level
Note. Optional. To verify the global RDP configuration for the switch, enter the show ip router-discov-
ery command. The display is similar to the one shown below:
For more information about this command, refer to the “RDP Commands” chapter in the OmniSwitch
6250/6350/6450 CLI Reference Guide.
2 Use the following command to create an RDP interface for an IP router interface. In this example, an
RDP interface is created for the IP router interface named Marketing (note that the IP interface is refer-
enced by its name).
-> ip router-discovery interface Marketing enable
3 When an RDP interface is created, default values are set for the interface advertisement destination
address, transmission interval, lifetime, and preference level parameters. If you want to change the
default values for these parameters, see “Creating an RDP Interface” on page 31-8.
Note. Optional. To verify the RDP configuration for all RDP interfaces, enter the show ip router-
discovery interface command. The display is similar to the one shown below:
To verify the configuration for a specific RDP interface, specify the interface name when using the show
ip router-discovery interface command. The display is similar to the one shown below:
For more information about this command, refer to the “RDP Commands” chapter in the OmniSwitch
6250/6350/6450 CLI Reference Guide.
RDP Overview
End host (clients) sending traffic to other networks need to forward their traffic to a router. In order to do
this, hosts need to find out if one or more routers exist on their LAN, then learn their IP addresses. One
way to discover neighboring routers is to manually configure a list of router IP addresses that the host
reads at startup. Another method available involves listening to routing protocol traffic to gather a list of
router IP addresses.
RDP provides an alternative method for hosts to discover routers on their network that involves the use of
ICMP advertisement and solicitation messages. Using RDP, hosts attached to multicast or broadcast
networks send solicitation messages when they start up. Routers respond to solicitation messages with an
advertisement message that contains the router IP addresses. In addition, routers first send advertisement
messages when their RDP interface becomes active, and then subsequently at random intervals.
When a host receives a router advertisement message, it adds the IP addresses contained in the message to
its list of default router gateways in the order of preference. As a result, the list of router IP addresses is
dynamically created and maintained, eliminating the need for manual configuration of such a list. In addi-
tion, hosts do not have to recognize many different routing protocols to discover router IP addresses.
The following diagram illustrates an example of using RDP in a typical network configuration:
RS-1
2/3
H-1
1/1
2/4
H-2
RS-2
1/2
Network 17.0.0.0
When interfaces 2/3 and 2/4 on hosts H-1 and H-2, respectively, become active, they transmit router solici-
tation ICMP messages on Network 17.0.0.0. The RDP enabled routers RS-1 and RS-2 pick up these pack-
ets on their RDP interfaces 1/1 and 1/2 and respond with router advertisement ICMP messages. RS-1 and
RS-2 also periodically send out router advertisements on their RDP interfaces.
RDP Interfaces
An RDP interface is created by enabling RDP on a VLAN router IP address. Once enabled, the RDP inter-
face becomes active and joins the all-routers IP multicast group (224.0.0.2). The interface then transmits
three initial router advertisement messages at random intervals that are no greater than 16 seconds apart.
This process occurs upon activation to increase the likelihood that end hosts will quickly discover this
router.
After an RDP interface becomes active and transmits its initial advertisements, subsequent advertisements
are transmitted at random intervals that fall between a configurable range of time. This range of time is
defined by specifying a maximum and minimum advertisement interval value. See “Defining the Adver-
tisement Interval” on page 31-9 for more information. Because advertisements are transmitted at random
intervals, the risk of system overload is reduced as advertisements from other routers on the same link are
not likely to transmit at the same time.
It is important to note that advertisements are only transmitted on RDP interfaces if the following condi-
tions are met:
• The RDP global status is enabled on the switch.
• An IP interface exists and is in the enabled state.
• An RDP interface exists and is in the enabled state.
The router advertisement is a multicast packet sent to the all-systems IP multicast group (224.0.0.1) or the
broadcast address. Note that RDP is not recommended for detecting neighboring router failures, referred to
as black holes, in the network. However, it is possible to use RDP as a supplement for black hole detec-
tion by setting RDP interface advertisement interval and lifetime values to values lower than the default
values for these parameters. See “Defining the Advertisement Interval” on page 31-9 and “Setting the
Advertisement Lifetime” on page 31-10 for more information.
Security Concerns
ICMP RDP packets are not authenticated, which makes them vulnerable to the following attacks:
• Passive monitoring—Attackers can use RDP to re-route traffic from vulnerable systems through the
attacker’s system. This allows the attacker to monitor or record one side of the conversation. However,
the attacker must reside on the same network as the victim for this scenario to work.
• Man in the middle—Attacker modifies any of the outgoing traffic or plays man in the middle, acting
as a proxy between the router and the end host. In this case, the victim thinks that it is communicating
with an end host, not an attacker system. The end host thinks that is it communicating with a router
because the attacker system is passing information through to the host from the router. If the victim is a
secure Web server that uses SSL, the attacker sitting in between the server and an end host could inter-
cept unencrypted traffic. As is the case with passive monitoring, the attacker must reside on the same
network as the victim for this scenario to work.
• Denial of service (DoS)—Remote attackers can spoof these ICMP packets and remotely add bad
default-route entries into a victim’s routing table. This would cause the victim to forward frames to the
wrong address, thus making it impossible for the victim’s traffic to reach other networks. Because of
the large number of vulnerable systems and the fact that this attack will penetrate firewalls that do not
stop incoming ICMP packets, this DoS attack can become quite severe. (See Chapter 28, “Configuring
IP,” and Chapter 39, “Configuring QoS,” for more information about DoS attacks.)
Note. Security concerns associated with using RDP are generic to the feature as defined in RFC 1256 and
not specific to this implementation.
Enabling/Disabling RDP
RDP is included in the base software and is available when the switch starts up. However, by default this
feature is not operational until it is enabled on the switch.
To enable RDP operation on the switch, use the following command:
-> ip router-discovery enable
Once enabled, any existing RDP interfaces on the switch that are also enabled will activate and start to
send initial advertisements. See “RDP Interfaces” on page 31-6 for more information.
To disable RDP operation on the switch, use the following command:
-> ip router-discovery disable
Use the show ip router-discovery command to determine the current operational status of RDP on the
switch.
The IP router interface name is the name assigned to the interface when it was first created. For more
information about creating IP router interfaces, see Chapter 28, “Configuring IP.”
The first time an RDP interface is enabled, it is not necessary to enter enable as part of the command.
However, if the interface is subsequently disabled, then entering enable is required the next time this
command is used. For example, the following sequence of commands initially enables an RDP interface
for the Marketing IP router interface, then disables and again enables the same interface:
-> ip router-discovery interface Marketing
-> ip router-discovery interface Marketing disable
-> ip router-discovery interface Marketing enable
When the above RDP interface becomes active, advertisement packets are transmitted on all active ports
that belong to the VLAN associated with the Marketing interface. These packets contain the IP address
associated with the Marketing interface for the purposes of advertising this interface on the network.
When an RDP interface is created, it is automatically configured with the following default parameter
values:
It is only necessary to change the above parameter values if the default value is not sufficient. The follow-
ing subsections provide information about how to configure RDP interface parameters if it is necessary to
use a different value.
Enter all-systems-multicast when using this command to change the destination address to 224.0.0.1. For
example:
-> ip router-discovery interface Marketing advertisement-address all-systems-
multicast
Make sure that the value specified with this command is greater than the current minimum advertisement
interval value. By default, this value is set to 600 seconds.
Make sure that the value specified with this command is less than the current maximum advertisement
interval value. By default, this value is set to 0.75 * the default maximum interval value (450 seconds if
the maximum interval is set to its default value of 600 seconds).
By default, the lifetime value is set to 3 * the current maximum interval value (1800 seconds if the maxi-
mum interval is set to its default value of 600 seconds).
Note that router IP address preference levels are only compared with the preference levels of other routers
that exist on the same subnet. Set low preference levels to discourage selection of a specific router.
show ip router-discovery Displays the current operational status of RDP on the switch. Also
includes the number of advertisement packets transmitted and the num-
ber of solicitation packets received by all RDP interfaces on the switch.
show ip router- Displays the current RDP status, related parameter values, and RDP
discovery interface traffic statistics for one or more switch router RDP interfaces.
For more information about the resulting displays from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide. An example of the output for the show ip router-discovery and show ip
router-discovery interface commands is also given in “Quick Steps for Configuring RDP” on page 31-3.
The User Datagram Protocol (UDP) is a connectionless transport protocol that runs on top of IP networks.
The DHCP Relay allows you to use nonroutable protocols (such as UDP) in a routing environment. UDP
is used for applications that do not require the establishment of a session and end-to-end error checking.
Email and file transfer are two applications that could use UDP. UDP offers a direct way to send and
receive datagrams over an IP network and is primarily used for broadcasting messages. This chapter
describes the DHCP Relay feature. This feature allows UDP broadcast packets to be forwarded across
VLANs that have IP routing enabled.
In This Chapter
This chapter describes the basic components of DHCP Relay and how to configure them. CLI commands
are used in the configuration examples. For more details about the syntax of commands, see the OmniS-
witch 6250/6350/6450 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Quick steps for configuring DHCP Relay on page 32-7.
• Setting the IP address for global DHCP on page 32-14.
• Identifying the VLAN for per-VLAN DHCP on page 32-15.
• Enabling BOOTP/DHCP Relay on page 32-15.
• Setting the forward delay time on page 32-16.
• Setting the maximum hops value on page 32-16.
• Setting the relay forwarding option to standard or Per-VLAN on page 32-16.
• Configuring the DHCP client interface to obtain an ip address for the switch on page 32-17.
• Vendor Class Identifier and Preference to OXO DHCP Server page 32-20
• Configuring relay for generic UDP service ports on page 32-20.
• Using the relay agent information option (Option-82) on page 32-24.
• Using DHCP snooping on page 32-27.
The different sections describing the DHCPv6 Relay functionality in this chapter are as follows:
• “Quick Steps for Setting Up DHCPv6 Relay” on page 32-8
• “DHCPv6 Relay Overview” on page 32-40
• “Configuring DHCPv6 Relay” on page 32-41
• “Verifying the DHCPv6 Relay Configuration” on page 32-50
For information about the IP protocol, see Chapter 28, “Configuring IP.” and IPv6 protocol see
Chapter 15, “IPv6 Commands”.
IPv6 addresses supported for the Maximum of 8 IPv6 addresses for each VLAN relay service.
Per-VLAN service Maximum of 256 VLAN relay services.
Maximum number of DHCPv6 1
Client interfaces
Maximum number of DHCPv6 64
Snooping VLANs
2 Set the forward delay timer for the BOOTP/DHCP relay. To set the timer for a 15 second delay, use
the following command:
-> ip helper forward delay 15
3 Set the maximum hop count value. To set a hop count of 3, use the following command:
Note. Optional. To verify the DHCP Relay configuration, enter the show ip helper command:
For more information about on the show command, see the “DHCP Relay” chapter in the OmniSwitch
6250/6350/6450 CLI Reference Guide.
2 Set the maximum hops count for the DHCPv6 relay. To set the hop count to 32, use the following
command:
-> ipv6 helper maximum hops 32
Note. Optional. To verify the DHCPv6 Relay configuration, enter the show ipv6 helper command. The
display shown for the DHCPv6 Relay configured in the above Quick Steps is shown here:
For more information about this display, see the “Configuring IPv6” chapter in the OmniSwitch 6250/
6350/6450 CLI Reference Guide.
DHCP
DHCP (Dynamic Host Configuration Protocol) provides a framework for passing configuration
information to Internet hosts on a TCP/IP network. It is based on the Bootstrap Protocol (BOOTP), adding
the ability to allocate reusable network addresses and additional configuration options automatically.
DHCP consists of the following two components:
• A protocol for delivering host-specific configuration parameters from a DHCP server to a host.
• A mechanism for allocating network addresses to hosts.
DHCP is built on a client-server model in which a designated DHCP server allocates network addresses
and delivers configuration parameters to dynamically configured hosts. It supports the following three
mechanisms for IP address allocation.
Dynamic—DHCP assigns an IP address to a host for a limited period (or until the host explicitly
relinquishes the address).
Manual—The network administrator assigns an IP address of a host and DHCP simply conveys the
assigned address to the host.
OmniSwitch
External Router
with
DHCP Relay
125.0.0.1
DHCP Clients VLAN 1
IN OUT
125.0.0.2
DHCP Server
130.0.0.13
DHCP Clients
The external router inserts the subnet address of the first hop segment into the DHCP request frames from
the DHCP clients. This subnet address allows the DHCP server to locate the segment on which the
requesting client resides. In this example, all clients attached to the OmniSwitch are DHCP-ready and
have the same subnet address (130.0.0.0) inserted into each of the requests by the DHCP Relay function of
the router. The DHCP server assigns a different IP address to each of the clients. The switch does not need
an IP address assigned and all DHCP clients will be members of either a default VLAN or an IP protocol
VLAN.
DHCP Relay
125.0.0.21 130.0.0.21
(Router Port IP Address) (Router Port IP Address)
VLAN 2 VLAN 3
130.0.0.14 130.0.0.15
DHCP Clients
125.0.0.1 125.0.0.2
DHCP Client DHCP Server 130.0.0.13
DHCP Client
DHCP Clients in Two VLANs
During initialization, each network client forwards a DHCP request frame to the DHCP server using the
local broadcast address. For those locally attached stations, the frame will be switched.
In this case, the DHCP server and clients must be members of the same VLAN (they could also all be
members of the default VLAN). One way to accomplish this is to use DHCP rules in combination with IP
protocol rules to place all IP frames in the same VLAN. See Chapter 9, “Defining VLAN Rules,” for more
information.
Because the clients in the application example are not members of the same VLAN as the DHCP server,
they must request an IP address through the DHCP Relay routing entity in the switch. When a DHCP
request frame is received by the DHCP Relay entity, it is forwarded from VLAN 3 to VLAN 2. All the
DHCP-ready clients in VLAN 3 must be members of the same VLAN, and the switch must have the
DHCP Relay function configured.
Global DHCP
For the global DHCP service, identify an IP address for the DHCP server.
The DHCP Relay forwards BOOTP/DHCP broadcasts to and from the specified address. If multiple
DHCP servers are used, one IP address must be configured for each server. A maximum of 256 addresses
can be configured for each relay service.
To delete an IP address, use the no form of the ip helper address command. The IP address specified with
this syntax is deleted. If an IP address is not specified with this syntax, then all IP helper addresses are
deleted. The following command deletes an IP helper address:
-> ip helper no address 125.255.17.11
Per-VLAN DHCP
For the Per-VLAN DHCP service, identify the number of the VLAN that makes the relay request.
The following syntax identifies two DHCP servers for VLAN 4 at two different IP addresses:
-> ip helper address 125.255.17.11 125.255.18.11 vlan 4
To delete an IP address, use the no form of the ip helper address command. The IP address specified
with this syntax is deleted. If an IP address is not specified with this syntax, then all IP helper addresses
are deleted. The following command deletes a helper address for IP address 125.255.17.11:
-> ip helper no address 125.255.17.11
The range for the forward delay time value is 0 seconds to 65535 seconds.
The hops value represents the maximum number of relays. The range is from one to 16 hops. The default
maximum hops value is set to four. This maximum hops value only applies to DHCP Relay. All other
switch services ignores this value.
When the switch receives a valid IP address lease from a DHCP server:
• The IP address and the subnet mask (DHCP Option-1) are assigned to the DHCP Client IP interface.
• A default static route is created according to DHCP Option-3 (Router IP Address).
• The lease is periodically renewed and rebound according to the renew time (DHCP Option-58) and
rebind time (DHCP Option-59) returned by the DHCP server. If the lease cannot be renewed within the
lease time (DHCP Option-51) returned by the DHCP server, the IP address is released. When not
specified by the DHCP server, a default lease time of seven days is allocated.
• The system name and the time zone of the OmniSwitch is set according to the system name (DHCP
Option-12) and time zone (DHCP Option-2) assigned by the DHCP server. However, if user
configures the system name and time zone to non-default values, DHCP server does not assign the
system name and time zone values.
• The DHCP Client-enabled IP address serves as the primary IP address when multiple addresses are
configured for a VLAN.
Note. User-defined values for the system name and time zone can be set using system name and system
timezone CLI commands.
• Periodic DHCPINFORM message is sent to the DHCP server every ten minutes requesting for
Option-2 and Option-12 (only after successfully acquiring the DHCP lease from the server). The
DHCP server values are compared to the existing time zone and system name values, and the values
are applied only if there is a change in value and the user have not configured them. This helps in
applying the changes done in the DHCP server on the fly.
Note. The string "alcatel.a4400.0" is hard coded. This will be used to match with the extracted vendor
specific information from DHCP response during the RCL process.
The OXO DHCP server can be changed only after the RCL process by configuring the desired OXO
server address in the VSI filter.
Note. The OXO DHCP server response will be sent only on default VLAN 1.
In order to retain the same OXO server which was configured before RCL, the VSI filter must match the
hard coded string configuration “alcatel.a4400.0”.
Note. If the relay service for BOOTP/DHCP is disabled when the switch reboots, the service is
automatically enabled when the switch comes back up. If there were three non-BOOTP/DHCP relay
services already enabled before the reboot, the most recent service enabled is disabled and replaced with
the BOOTP/DHCP relay service.
• The ip helper commands are used to configure BOOTP/DHCP relay and the ip udp port commands
are used to configure UDP port relay. The ip udp relay command, however, is also used to enable or
disable relay for BOOTP/DHCP known ports 67 and 68.
• If the BOOTP/DHCP relay service is disabled, the ip helper configuration is not retained and all
dependant functionality (that is, automatic IP configuration for VLAN 1) is disrupted.
• Relaying BOOTP/DHCP traffic is available on a global and per-VLAN basis. Using this function on a
per-VLAN basis requires setting the DHCP relay forwarding mode to per-vlan only. UDP port relay
for generic services is only available on a per-VLAN basis, but does not require enabling the per-vlan
only forwarding option.
Configuring UDP Port Relay for generic UDP services is a two-step process. The first step involves
enabling UDP Port Relay on the generic service port. The second step involves specifying a VLAN that
relay will forward traffic destined for the generic service port. Both steps are required and are described in
the following section.
To enable relay on a user-defined (not well-known) UDP service port, then enter the service port number
instead of the service name. For example, the following command enables relay on service port 3047:
-> ip udp relay 3047
To disable a relay operation for a UDP service port, use the no form of the ip udp relay command. For
example, the following command disables relay on the DNS well-known service port:
-> no ip udp relay dns
For more information about using the ip udp relay command, see the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
The ip udp relay vlan command only works if UDP Port Relay is already enabled on the specified service
port. In addition, when assigning a VLAN to the BOOTP/DHCP service ports, set the DHCP relay
forwarding mode to per-vlan only first before trying to assign the VLAN.
It is also possible to assign up to 256-forwarding VLANs to each generic service port. To specify more
than one VLAN with a single command, enter a range of VLANs. For example, the following command
assigns VLANs 6 through 8 and VLAN 10 as forwarding VLANs for the NBNS/NBDD well-known
service ports:
-> ip udp relay nbnsnbdd vlan 6-8 10
If UDP Port Relay was enabled on a not well-known service port, then enter the service port number
instead of the service name. For example, the following command assigns VLAN 100 as a forwarding
VLAN for UDP service port 3047:
-> ip udp relay 3047 vlan 100
To remove a VLAN association with a UDP service port, use the no form of the ip udp relay vlan
command. For example, the following command removes the VLAN 6 association with the NBNS/NBDD
well-known service port:
-> no ip udp relay nbnsnbdd vlan 6
For more information about using the ip udp relay vlan command, see the OmniSwitch 6250/6350/6450
CLI Reference Guide.
The following sections provide additional information about each DHCP security feature and how to
configure feature parameters using the Command Line Interface (CLI).
How the Relay Agent Processes DHCP Packets from the Client
The following table describes how the relay agent processes DHCP packets received from clients when
the Option-82 feature is enabled for the switch:
If the DHCP packet from the client ... The relay agent ...
Contains a zero gateway IP address (0.0.0.0) and Inserts Option-82 with unique information to
no Option-82 data. identify the client source.
Contains a zero gateway IP address (0.0.0.0) and Drops the packet, keeps the Option-82 data, and
Option-82 data. forwards the packet, or replaces the Option-82
data with its own Option-82 data and forwards the
packet.
How the Relay Agent Processes DHCP Packets from the Server
If a DHCP server does not support Option-82, the server strips the option from the packet. If the server
does support this option, the server retains the Option-82 data received and sends it back in a reply packet.
When the relay agent receives a DHCP packet from the DHCP server and the Option-82 feature is
enabled, the agent will:
1 Extract the VLAN ID from the Circuit ID suboption field in the packet and compare the MAC address
of the IP router interface for that VLAN to the MAC address contained in the Remote ID suboption field
in the same packet.
2 If the IP router interface MAC address and the Remote ID MAC address are not the same, then the
agent drops the packet.
3 If the two MAC addresses match, then a check is made to see if the slot/port value in the Circuit ID
suboption field in the packet matches a port that is associated with the VLAN also identified in the Circuit
ID suboption field.
4 If the slot/port information does not identify an actual port associated with the Circuit ID VLAN, then
the agent drops the packet.
5 If the slot/port information does identify an actual port associated with the Circuit ID VLAN, then the
agent strips the Option-82 data from the packet and unicasts the packet to the port identified in the Circuit
ID suboption.
This same command is also used to disable this feature. For example:
-> ip helper agent-information disable
DHCP Option-82 functionality is not restricted to ports associated with a specific VLAN as this feature is
not available on a per-VLAN basis. Instead, DHCP traffic received on all ports is eligible for Option-82
data insertion when it is relayed by the agent.
DHCP Option-82 policy applies to all DHCP packets received on all switch ports. In addition, if a packet
that contains existing Option-82 data also contains a gateway IP address that matches a local subnet
address, the relay agent drops the packet and not apply any existing Option-82 policy.
If none of the above are true, then DHCP Snooping accepts and forwards the packet. When a DHCPACK
packet is received from a server, the following information is extracted from the packet to create an entry
in the DHCP Snooping binding table:
• MAC address of the DHCP client.
• IP address for the client that was assigned by the DHCP server.
• The port from where the DHCP packet originated.
• The VLAN associated with the port from where the DHCP packet originated.
• The lease time for the assigned IP address.
• The binding entry type; dynamic or static (user-configured).
After extracting the above information and populating the binding table, the packet is then forwarded to
the port from where the packet originated. Basically, the DHCP Snooping features prevents the normal
flooding of DHCP traffic. Instead, packets are delivered only to the appropriate client and server ports.
Note. DHCP Snooping drops server packets received on untrusted ports (ports that connect to devices
outside the network or firewall). It is important to configure ports connected to DHCP servers as trusted
ports so that traffic to/from the server is not dropped.
When DHCP Snooping is enabled at the switch level, all DHCP packets received on all switch ports are
screened/filtered by DHCP Snooping. By default, only client DHCP traffic is allowed on the ports, unless
the trust mode for a port is configured to block or allow all DHCP traffic. See “Configuring the Port Trust
Mode” on page 32-31 for more information.
In addition, the following functionality is also activated by default when switch-level DHCP Snooping is
enabled:
• The DHCP Snooping binding table is created and maintained. To configure the status or add a static
entry to this table, use the ip helper dhcp-snooping binding command.
• MAC address verification is performed to compare the source MAC address of the DHCP packet with
the client hardware address contained in the packet. To configure the status of MAC address
verification, use the ip helper dhcp-snooping mac-address verification command.
• Option-82 data is inserted into the packet and then DHCP reply packets are only sent to the port from
where the DHCP request originated, instead of flooding these packets to all ports. To configure the
status of Option-82 data insertion, use the ip helper dhcp-snooping option-82 data-insertion
command.
• The base MAC address of the switch is inserted into the Circuit ID and Remote ID suboptions of the
Option-82 field. To configure the type of data (base MAC address, system name, or user-defined) that
is inserted into the Option-82 suboptions, use the ip helper dhcp-snooping option-82 format
command.
Note the following when disabling DHCP Snooping functionality:
• If the binding table is enabled, disabling Option-82 is not allowed.
• If Option-82 data insertion is not enabled at either the switch or VLAN level, enabling the binding
table is not allowed.
When this feature is enabled at the VLAN level, DHCP Snooping functionality is only applied to ports that
are associated with a VLAN that has this feature enabled. Up to 64 VLANs can have DHCP Snooping
enabled. Enabling DHCP Snooping at the switch level is not allowed if it is enabled for one or more
VLANs.
By default, when DHCP Snooping is enabled for a specific VLAN, MAC address verification and
Option-82 data insertion is also enabled for the VLAN by default. To disable or enable either of these two
features, use the ip helper dhcp-snooping vlan command with either the mac-address verification or
option-82 data-insertion parameters. For example:
-> ip helper dhcp-snooping vlan 200 mac-address verification disable
If the binding table functionality is enabled, disabling Option-82 data insertion for the VLAN is not
allowed. See “Configuring the DHCP Snooping Binding Table” on page 32-35 for more information.
Note. If DHCP Snooping is not enabled for a VLAN, then all ports associated with the VLAN are
considered trusted ports. VLAN-level DHCP Snooping does not filter DHCP traffic on ports associated
with a VLAN that does not have this feature enabled.
It is also possible to specify a range of ports. For example, the following command changes the trust mode
for ports 2/1 through 2/10 to trusted:
-> ip helper dhcp-snooping port 2/1-10 trust
It is necessary to configure ports connected to DHCP servers within the network and/or firewall as trusted
ports so that necessary DHCP traffic to/from the server is not blocked. Configuring the port mode as
trusted also identifies the device connected to that port as a trusted device within the network.
When IP source filtering is enabled, the maximum number of clients supported is 125 per switching ASIC.
Each switching ASIC controls 24 ports (for example, ports 1–24, 25–48, and so on) on a module.
Note. The command ip helper dhcp-snooping port ip-source-filter is deprecated from the release 6.6.4.
The command is supported for backward compatibility. The command ip helper dhcp-snooping ip-
source-filter is used to configure IP source filtering.
IP source filtering applies to DHCP Snooping ports and restricts port traffic to only packets that contain
the proper client source information in the packet. The DHCP Snooping binding table is used to verify the
client information for the port that is enabled for IP source filtering.
Port Source Filtering -Filters based on interface number, source MAC-address and source IP address.
By default IP source filtering is disabled for a DHCP Snooping port. Use the
ip helper dhcp-snooping ip-source-filter command to enable or disable this function.
For example, to enable source filtering on individual port 1/1, enter:
-> ip helper dhcp-snooping ip-source-filter port 1/1 enable
Note.
• Source filtering can be enabled only on the VLANs on which the DHCP Snooping is enabled.
• Source filtering can be enabled
- on the ports that are associated with a VLAN on which DHCP Snooping is enabled.
- on all the ports when DHCP Snooping is globally enabled for the switch.
To enable the IP source filtering capability at a port, link aggregation, or VLAN level, use the ip helper
dhcp-snooping ip-source-filter command. By default, IP source filtering is disabled for a port or link
aggregate, or VLAN.
For example, to enable source filtering on individual port 1/1, enter:
-> ip helper dhcp-snooping ip-source-filter port 1/1 enable
Note. A maximum of 16 subnets are allowed to be excluded from source filtering on OmniSwitch 6450
and OmniSwitch 6250. On OmniSwitch 6350, only 8 subnets are allowed.
show ip helper dhcp-snooping ip-source-filter vlan displays the subnet information on which IP source
filtering is excluded.
Enabling the binding table functionality is not allowed if Option-82 data insertion is not enabled at either
the switch or VLAN level.
In addition, it is also possible to configure static binding table entries. This type of entry is created using
available ip helper dhcp-snooping binding command parameters to define the static entry. For example,
the following command creates a static DHCP client entry:
-> ip helper dhcp-snooping binding 00:2a:95:51:6c:10 port 1/15 address
17.15.3.10 lease-time 3 vlan 200
To remove a static binding table entry, use the no form of the ip helper dhcp-snooping binding
command. For example:
-> no ip helper dhcp-snooping binding 00:2a:95:51:6c:10 port 1/15 address
17.15.3.10 lease-time 3 vlan 200
To view the DHCP Snooping binding table contents, use the show ip helper dhcp-snooping binding
command. See the OmniSwitch 6250/6350/6450 CLI Reference Guide for example outputs of this
command.
Note. Do not manually change the dhcpBinding.db file. This file is used by DHCP Snooping to preserve
and maintain binding table entries. Changing the file name or contents can cause problems with this
functionality or with the DHCP Snooping application itself.
The amount of time, in seconds, between each automatic save is referred to as the binding table timeout
value. By default, the timeout value is 300 seconds. To configure this value, use the
ip helper dhcp-snooping binding timeout command. For example, the following command sets the
timeout value to 1500 seconds:
-> ip helper dhcp-snooping binding timeout 1500
Each time an automatic save is performed, the dhcpBinding.db file is time stamped.
Synchronizing the binding table is only done when this command is used. There is no automatic
triggering of this function. In addition, it is important to note that synchronizing the binding table loads
dhcpBinding.db file contents into memory. This is the reverse of saving the binding table contents in
memory to the dhcpBinding.db file, which is done at automatic time intervals as defined by the binding
table timeout value. See “Configuring the Binding Table Timeout” on page 32-35 for more information.
When binding table retention is enabled, entries remain in the table for the term of their DHCP lease and
are not removed even when the MAC address for the entry is cleared from the MAC address table.
To disable binding table retention, use the following command:
-> ip helper dhcp-snooping binding persistency disable
Use the show ip helper command to determine the status of binding table retention.
DHCP Snooping and ISF must be enabled before enabling this function. On enabling this feature an entry
is made in the ISF table hence the number of binding entry is reduced by one.
To disable the DHCP Snooping ISF ARP-allow function, enter:
Use the show ip helper command to view the operational status of the DHCP Snooping ISF ARP allow
function.
DHCP Server
1/2
VLAN 2
1/9 1/9
SW1 SW2
1/1
VLAN 1
DHCP Client
The DHCP client connected to the Switch 1 (SW1) uses the untrusted port 1/1 on VLAN 1 to send the
DHCP client packets. The switch makes a binding table entry and forwards the packet to the DHCP relay
agent (SW2) through the trusted port 1/9. The relay agent resends the packet back to the switch (SW1) on
which the DHCP server is configured on VLAN 2 on trusted port 1/2. The switch (SW1) overwrites the
binding table entry for the packet sent on the trusted port. When the DHCP server responds, the DHCP
server packets are dropped when received on the client VLAN since the binding table is overwritten with
the trusted port information.
When Globaluturn is enabled on the switch the binding table will not be built for the unicast BOOTP
packets sent on the trusted ports, hence avoiding the overwrite of the binding table entry and dropping of
the DHCP server packets on the client VLAN.
For more information on using the CLI, See the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Use the show ip helper command to verify the trap-mode of the DHCP snooping global mode setting.
Note.
The global DHCP snooping settings will not work:
• If the DHCP server message such as OFFER, NAK, and ACK are received on untrusted ports such has
client only or blocked ports.
• If the client VLAN is a plain L2 network, that is either source MAC or the destination MAC is same as
the BOOTP MAC.
show ip helper Displays the current forward delay time, the maximum number of hops,
the forwarding option, and each of the DHCP server IP addresses
configured. Also displays the current configuration status for the DHCP
relay agent information option (Option-82) and DHCP Snooping fea-
tures.
show ip helper stats Displays the number of packets the DHCP Relay service has received
and transmitted, the number of packets dropped due to forward delay
and maximum hops violations, and the number of packets processed
since the last time these statistics were displayed.
show ip udp relay service Displays the current configuration for UDP services by service name or
by service port number.
show ip udp relay statistics Displays the current statistics for each UDP port relay service. These
statistics include the name of the service, the forwarding VLAN
configured for that service, and the number of packets the service has
sent and received.
show ip helper dhcp-snooping Displays the ports or VLANs on which IP source filtering is enabled or
ip-source-filter the binding table for IP source filtering enabled ports.
show ip helper dhcp-snooping Displays a list of VLANs that have DHCP Snooping enabled and
vlan whether MAC address verification and Option-82 data insertion are
enabled for each VLAN.
show ip helper dhcp-snooping Displays the DHCP Snooping trust mode for the port and the number of
port packets destined for the port that were dropped due to a DHCP
Snooping violation.
show ip helper dhcp-snooping Displays the contents of the DHCP Snooping binding table (database).
binding
Global DHCPv6
For the global DHCPv6 service, you must identify an IP address for the DHCPv6 server.
The DHCPv6 Relay forwards DHCPv6 broadcasts to and from the specified address. If multiple DHCPv6
servers are used, one IP address must be configured for each server. You can configure up to 256
addresses for each relay service.
To delete an IPv6 address, use the no form of the ipv6 helper address command. The IP address speci-
fied with this syntax is deleted. If an IP address is not specified with this syntax, then all IPv6 helper
addresses are deleted. This is not applicable for per VLAN mode.
The following command deletes an IP helper address:
-> ipv6 helper no address 2001::5
Per-VLAN DHCPv6
For the Per-VLAN DHCPv6 service, you must identify the number of the VLAN that makes the relay
request.
The following syntax identifies the IPv6 address 2001::5 as the DHCPv6 server for range of VLANs
from 100 to 105:
-> ipv6 helper address 2001::5 vlan 100-105
To delete an IPv6 address, use the no form of the ipv6 helper address command. The IPv6 address
specified with this syntax is deleted. If an IPv6 address is not specified with this syntax, then all IPv6
helper addresses are deleted. The following command deletes a helper address for IPv6 address 2001::5
for the specified VLAN:
-> ipv6 helper no address 2001::5 vlan 200
The hops value represents the maximum number of relays. The range is from one to 32 hops. The default
maximum hops value is set to 32. This maximum hops value only applies to DHCPv6 Relay. All other
switch services ignore this value.
Configuring Interface ID
Use the ipv6 helper interface-id prefix command to configure Interface ID manually with a user-defined
string. For example,
-> ipv6 helper interface-id prefix pool-1
Configuring Remote ID
Use the ipv6 helper remote-id format command to configures the type of information that is inserted into
the Remote ID sub option. The information is inserted into the Remote ID field in ASCII text string
format.
Use the following commands to set the remote-id in the relevant formats. For details on syntax definition
refer the ipv6 helper remote-id format command in OmniSwitch 6250/6350/6450 CLI Reference Guide.
-> ipv6 helper remote-id enterprise-number 100
To configure the switch to use the interface-alias previously configured using the interfaces alias
command:
-> ipv6 helper remote-id format interface-alias
To configure the switch to automatically generate the interface-alias in the system name and slot/port
format use the following command:
-> ipv6 helper remote-id format auto-interface-alias
To disable remote-id or remove the enterprise-number use the disable option as follows:
-> ipv6 helper remote-id format disable
VRF Support
The global relay IPv6 address or per-VLAN relay IPv6 address can only be configured on the default
VRF.
Note. DHCPv6 Snooping drops server packets received on untrusted ports (ports that connect to devices
outside the network or firewall). It is important to configure ports connected to DHCPv6 servers as trusted
ports so that traffic to/from the server is not dropped.
When DHCPv6 Snooping is enabled at the switch level, all DHCPv6 packets received on all switch ports
and link aggregates are screened/filtered by DHCPv6 Snooping. By default, only client DHCPv6 traffic is
allowed on the ports, unless the trust mode for a port is configured to block or allow all DHCPv6 traffic.
See “Configuring the Trust Mode for Ports and Link Aggregates” on page 32-46 for more information.
In addition, the following functionality is also activated by default when switch-level DHCPv6
Snooping is enabled:
• The DHCPv6 Snooping binding table is created and maintained. To configure the status of DHCPv6
snooping, use the ipv6 helper dhcp-snooping binding command.
When this feature is enabled at the VLAN level, DHCPv6 Snooping functionality is only applied to ports
that are associated with a VLAN that has this feature enabled. Up to 256 VLANs can have DHCPv6
Snooping enabled. Note that enabling DHCPv6 Snooping at the switch level is not allowed if it is enabled
for one or more VLANs.
Note. If DHCPv6 Snooping is not enabled for a VLAN, then all ports associated with the VLAN are
considered trusted ports.
It is also possible to specify a range of ports. For example, the following command changes the trust mode
for ports 2/1 through 2/10 to trusted:
-> ipv6 helper dhcp-snooping port 2/1-10 trusted
Note. It is necessary to configure ports connected to DHCPv6 servers within the network and/or
firewall as trusted ports so that necessary DHCPv6 traffic to/from the server is not blocked.
Configuring the port mode as trusted also identifies the device connected to that port as a trusted device
within the network.
Similarly, to configure the trust mode for link aggregates, use the ipv6 helper dhcp-snooping linkagg
command. For example,
-> ipv6 helper dhcp-snooping linkagg 1 trusted
Note. Do not manually change the dhcpv6bind.db file. This file is used by DHCPv6 Snooping to
preserve and maintain binding table entries. Changing the file name or contents can cause problems with
this functionality or with the DHCPv6 Snooping application itself.
The amount of time, in seconds, between each automatic save is referred to as the binding table timeout
value. By default, the timeout value is 300 seconds. To configure this value, use the
ipv6 helper dhcp-snooping binding timeout command. For example, the following command sets the
timeout value to 1500 seconds:
-> ipv6 helper dhcp-snooping binding timeout 1500
Each time an automatic save is performed, the dhcpv6bind.db file is time stamped.
Synchronizing the binding table is only done when this command is used. There is no automatic
triggering of this function. In addition, it is important to note that synchronizing the binding table loads
dhcpv6bind.db file contents into memory. This is the reverse of saving the binding table contents in
memory to the dhcpv6bind.db file, which is done at automatic time intervals as defined by the binding
table timeout value. See “Configuring the Binding Table Timeout” on page 32-35 for more information.
When binding table retention is enabled, entries remain in the table for the term of their DHCPv6 lease and
are not removed even when the MAC address for the entry is cleared from the MAC address table.
To disable binding table retention, use the following command:
-> ipv6 helper dhcp-snooping binding persistency disable
Use the show ipv6 helper command to determine the status of binding table retention.
Note.
- In case of OmniSwitch 6350, source filtering for both IPv4 and IPv6 cannot be configured on the same
switch.
- DHCPv6 snooping must be enabled for IPv6 source filtering to be enabled.
show ipv6 helper Displays the current DHCPv6 Relay, Relay Agent information and
DHCPv6 snooping configurations.
show ipv6 helper stats Displays the IPv6 helper statistics information.
show ipv6 helper dhcp- Displays a list of VLANs that have DHCPv6 Snooping enabled.
snooping vlan
show ipv6 helper dhcp- Displays the trust mode and DHCPv6 Snooping violation statistics for
snooping port all switch ports that are filtered by DHCPv6 Snooping.
show ipv6 helper dhcp- Displays the contents of DHCPv6 Snooping binding table (database).
snooping binding
show ipv6 helper dhcp- Displays the ports or VLANs on which IPv6 source filtering is enabled.
snooping ip-source-filter
show ipv6 helper dhcp- Displays the binding entries for IPv6 source filtering.
snooping ip-source-filter
binding
The Dynamic Host Configuration Protocol (DHCP) offers a framework to provide configuration
information to client interfaces on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP)
and provides additional capabilities like dynamic allocation of reusable network addresses and
configuration options.
A DHCP server provides dynamic IP addresses on lease for client interfaces on a network. It manages a
pool of IP addresses and information about client configuration parameters. The DHCP server obtains an
IP address request from the client interfaces. After obtaining the requests, the DHCP server assigns an IP
address, a lease period, and other IP configuration parameters, such as the subnet mask and the default
gateway.
This chapter describes how to configure the internal DHCP server on the OmniSwitch.
In This Chapter
This chapter describes configuration of the DHCP server and how to modify the configuration through the
Command Line Interface (CLI). CLI commands are used in the configuration examples; for more details
on the syntax of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Configuration procedures described in this chapter include:
• “DHCP Server Specifications” on page -2.
Static DHCP:
The network administrator assigns an IP address to the
DHCP client. DHCP conveys the address assigned by the
DHCP server to the client.
Dynamic DHCP:
The DHCP server assigns an IP address to a client for
a limited period of time or until the client explicitly
releases the address.
Maximum number of leases 2048
Maximum lease information file size 375 KB
DHCP server packets processing ~50 packets per second
Note. For detailed information on how to configure the DHCP server on OmniSwitch, see the Configuring
DHCP Server on OmniSwitch section.
2 Copy the dhcpd.conf.template file and save it as dhcpd.conf. The dhcpd.conf file can then be
customized as necessary.
-> cp dhcpd.conf.template dhcpd.conf
3 Copy the dhcpd.pcy.template file and save it as dhcpd.pcy. The dhcpd.pcy file can then be custom-
ized as necessary.
4 Customize the dhcp.conf and dhcpd.pcy files according to your requirements. Use the vi command to
modify the existing configuration file.
-> vi dhcpd.conf
Declare dynamic DHCP options, global options, and server configuration parameters for client
interfaces in the dhcpd.conf file. Add DHCP related information for a particular subnet.
For example, for the subnet 200.0.0.0, define the dynamic DHCP range, router option, domain name and
other details using the following code:
server-identifier sample.example.com;
Note. See “Configuration File Parameters and Syntax” on page -13 topic of the Configuring DHCP Server
section for details on what each of the optional keywords specify.
5 After entering the required information in the dhcpd.conf file. Type :wq to save the changes made to
the dhcpd.conf file.
Note.
• If the dhcpd.conf file is corrupted, the dhcpd.conf.lastgood file is used as a backup file.
• If the dhcpd.conf file is updated successfully, then the dhcpd.conf.lastgood file is over written with
the configurations present in the dhcpd.conf file.
• Properly configured dhcpd.conf and dhcpd.pcy files can be transferred to the switch remotely instead
of using the vi editor.
6 Restart the DHCP server using the dhcp-server restart command. The changes made in the
dhcpd.conf file are applied to the OmniSwitch.
-> dhcp-server restart
Note. The dhcp-server restart command automatically updates the dhcpd.conf, dhcpd.conf.lastgood
and dhcpd.pcy files.
A DHCP server uses the Dynamic Host Configuration Protocol to provide initialization parameters to the
clients in the network.
4 The server responds with a dynamic address in a defined range or one based on a MAC address.
• Dynamically modify the DHCP configuration, using the vi editor, or through an accurately configured
text file transferred to the switch.
• Restart the DHCP server.
• View the DHCP server statistics through the command line interface.
BootP/UDP Relay
The BootP/UDP relay is automatically disabled on the default VRF when the internal DHCP server is
enabled on the switch.
DHCP Snooping
Internal DHCP server and DHCP snooping are mutually exclusive and cannot function together in the
default VRF. DHCP snooping security is disabled when the DHCP server feature is enabled on the switch
since the DHCP server is internal and secure.
IP Interfaces
The DHCP client gets a lease only if the switch has an IP interface and the DHCP server is configured for
that particular subnet. If there are no IP address ranges defined for the incoming client interface, then the
client is not assigned a lease.
In case of IP multinetting, the primary interface address is used to calculate the subnet of the interface. If
there are no IP interfaces configured in the system, then the packet sent from the client is dropped.
• DHCP Configuration files: The dhcpd.conf file is used to configure specific DHCP server settings on
the switch such as IP address ranges and options. The dhcpd.conf.lastgood file is a backup for the
dhcpd.conf file.
• DHCP Server Database file: The dhcpSrv.db file is activated only during takeover and server restart
of the DHCP server. It contains lease details of the client IP addresses.
Policy file
The policy file is used to configure the DHCP related policies according to user requirements. The
dhcpd.pcy.template file provides a basic template to create a policy file. The DHCP server policy
parameters can be defined using the policy file. Ideally, most of the server parameters are kept static.
The updated dhcpd.pcy file is effective only after the dhcp-server command on page 20-73 is ip helper
address performed.
See the Policy File Parameters and Syntax table for additional information on individual policy
parameters and how to apply the policies for internal DHCP server on the OmniSwitch.
• dhcpd.conf.lastgood file
The following sections provide detailed information on the dhcpd.conf and dhcpd.conf.lastgood files.
dhcpd.conf File
The dhcpd.conf file is used to declare DHCP options and global options for the DHCP clients. The
dhcpd.conf.template file contains the default configuration parameters to setup the internal DHCP server.
The template file can be copied to the dhcpd.conf file for editing.
The dhcpd.conf can be used to define the following:
• IP subnets
• Declarations: Describe the topology of the network and provide addresses for the clients. Parameters
can be listed under declarations that override the global parameters.
• Comments: Provide a description for the parameters and declarations. Lines beginning with a hash
mark (#) are considered comments and they are optional.
#IP subnet
subnet 200.0.0.0 netmask 255.255.255.0
{
#Dynamic scope and parameters that apply to this scope overriding global params.
Note. A subnet declaration must be included for every subnet in the network related to the DHCP server.
Details about valid parameters and declarations are listed in the table - Configuration File Parameters and
Syntax
dhcpd.conf.lastgood File
The dhcpd.conf.lastgood file is used as a backup file when the dhcpd.conf file is corrupted. If the
dhcpd.conf file is affected, then the DHCP server generates an error. In such an instance, the DHCP
server configuration is updated according to the dhcpd.conf.lastgood file. The dhcpd.conf.lastgood file
is now used to configure the internal DHCP server, provide IP addresses on lease, and maintain DHCP
related information.
The dhcpd.conf.lastgood file is overwritten with the configurations in the dhcpd.conf file when the
DHCP configurations are setup or updated and the internal DHCP server is restarted successfully. At this
point, the dhcpd.conf and dhcpd.conf.lastgood files are identical.
If any modifications are made in the dhcpd.conf file, the DHCP server must be restarted so that the
configuration is updated on the OmniSwitch. The dhcp-server command automatically updates the
dhcpd.conf and dhcpd.conf.lastgood files.
3 The dhcpd.conf file defines the 200.0.0.X network and 220.0.0.X network.
4 The subnet mask and DNS server address are global declarations since they are the same for each
subnet.
5 The default router address and lease times are declared as a part of the scope since they are different for
each subnet.
6 The resulting sample code for the dhcpd.conf file is as follows:
#Global parameters
option subnet-mask 255.255.255.0;
option domain-name-servers 200.0.0.99;
subnet 200.0.0.0 netmask 255.255.255.0
{
dynamic-dhcp range 200.0.0.11 200.0.0.20
{
option routers 200.0.0.254;
option dhcp-lease-time 20000;
}
}
OmniSwitch
200.0.0.254
with
DHCP Relay
IP ROUTER AND
10 DHCP SERVER
11 13
12
IN OUT
...
200.0.0.11-20 200.0.0.99
DHCP Clients DNS Server
220.0.0.103
DHCP Clients
Illustration of Internal DHCP Server application example
show dhcp-server leases Displays the leases offered by the DHCP server.
show dhcp-server statistics Displays the statistics of the DHCP server.
option 177
[010378797a020
378797a0303787
97a040378797a0
50378797a06037
8797a070100080
100090378797a]
;
TSP Primary ip_address N/A Specifies the IP address of the
DHCP Server TSP’s primary DHCP server from
Address which an MTA is permitted to
accept a DHCP OFFER.
TSP ip_address N/A Specifies the IP address of the
Secondary TSP’s secondary DHCP server
DHCP Server from which an MTA is permitted to
Address accept a DHCP OFFER.
TSP IP_address MTAs communicate with the
Provisioning Provisioning server at various
Server stages in their provisioning process.
Address Enter either the IP address or the
FQDN of the TSP's Provisioning
server.
TSP ASREQ/ sub-option N/A Configures an MTA’s Kerberos
AS-REP ASREQ/AS-REP timeout, back-
Backoff and off, and retry mechanism. Enter a
Retry Nominal Timeout value in millisec-
onds, a Maximum Timeout value in
seconds and a Maximum Retry
value. All these values are
unsigned.
Default
Num Policy Usage Description
Value
6 Honor Honor True If this policy is set to True, the DHCP server provides
Requested Requested the requested lease time to the client.
Lease
LeaseTime Time = False
If this policy is set to False, the server offers the
configured lease time.
7 Lease Lease 60000 Specifies the time interval in milli seconds after which
Expiration Expiration msecs the lease expiration processing occurs.
SleepTime =
SleepTime 120000
Note: This value must not be less than 1 minute.
8 MaxPending MaxPending 10 Specifies the number of seconds that an offered lease
Seconds Seconds = 20 remains in a pending state.
Default
Num Policy Usage Description
Value
15 PingRetention Ping 0 Specifies the number of seconds for which a ping is
Retention valid. If a ping is attempted and no response is returned,
= 200
then the address is considered to be available. During
the ping retention period, other ping requests are
ignored.
18 PingBefore PingBefore True If this value is set to True, the DHCP server performs a
ManualDhcp ManualDhcp ping before assigning a static DHCP address. If an
= False
ICMP_REPLY is received from the ping, then the
DHCP offer is not sent to the client and the address is
marked as unavailable.
19 PingBefore PingBefore False If this value is set to True, the DHCP server performs a
ManualBootp ManualBootp ping before assigning a static BootP address. If an
= True
ICMP_REPLY is received, the BootP reply is not sent
to the client, and the BootP address is marked as
unavailable.
20 Registered Registered False This poilcy is used when the MAC pool addresses are
ClientsOnly Clients defined at either the global or the subnet level.
Only = True
If this value is set to True, the DHCP information is
provided to the clients that have a known MAC address
(configured in a MAC pool). If MAC pool addresses
are not defined at either the global or the subnet level,
the none of the devices are provided a DHCP lease.
The Virtual Router Redundancy Protocol (VRRPv2/VRRPv3) is a standard router redundancy protocol
supported in IPv4/IPv6, based on RFC 3768 and RFC 2787. It provides redundancy by eliminating the
single point of failure inherent in a default route environment. The VRRPv2/VRRPv3 router, which
controls the IPv4/IPv6 address associated with a virtual router is called the master router, and is
responsible for forwarding virtual router advertisements. If the master router becomes unavailable, the
highest priority backup router transitions to the master state. The Alcatel-Lucent implementation of VRRP
also supports the collective management of virtual routers on a switch.
Note. The VRRPv3 implementation is based on the latest Internet Draft, Virtual Router Redundancy
Protocol for IPv6, September 2004.
Note. RFC 3768, which obsoletes RFC 2338, does not include support for authentication types. As a
result, configuring VRRP authentication is no longer supported in this release.
In This Chapter
This chapter describes VRRPv2/VRRPv3 and how to configure it through the Command Line Interface
(CLI). CLI commands are used in the configuration examples; for more details about the syntax of
commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
This chapter provides an overview of VRRP and includes information about the following:
• Virtual routers—see “Creating/Deleting a Virtual Router” on page 34-10.
• IP addresses for virtual routers—see “Specifying an IP Address for a Virtual Router” on page 34-11.
• Preempting virtual routers—see “Setting Preemption for Virtual Routers” on page 34-13.
• IPv6 addresses for VRRPv3 virtual routers—see “Specify an IPv6 Address for a VRRPv3 Virtual
Router” on page 34-22.
• Accept mode for master router—see “Configuring the VRRPv3 Advertisement Interval” on
page 34-22.
• VRRPv3 advertisement interval—see “Configuring the VRRPv3 Advertisement Interval” on
page 34-22.
• VRRPv3 Virtual router priority—see “Configuring the VRRPv3 Virtual Router Priority” on
page 34-23.
• Preempting VRRPv3 virtual routers—see “Setting Preemption for VRRPv3 Virtual Routers” on
page 34-23.
• VRRPv3 traps—see “Setting VRRPv3 Traps” on page 34-25.
• Verifying the VRRP configuration—see “Verifying the VRRPv3 Configuration” on page 34-26.
VRRP Specifications
RFCs Supported RFC 3768–Virtual Router Redundancy Protocol
RFC 2787–Definitions of Managed Objects for the Virtual
Router Redundancy Protocol
Platforms Supported OmniSwitch 6250, 6450
Compatible with HSRP? No
Maximum number of VRRPv2 and VRRPv3 255 per switch
virtual routers combined
Maximum number of IP addresses 255 per virtual router
VRRP Defaults
The following table lists the defaults for VRRP configuration through the vrrp command and the relevant
command keywords:
The following table lists the defaults for VRRP configuration using the VRRP collective management
features and the relevant command:
-> vrrp 6 4
The VLAN must already be created on the switch. For information about creating VLANs, see
Chapter 4, “Configuring VLANs.”
4 Repeat steps 1 through 2 on all of the physical switches that participates in backing up the addresses
associated with the virtual router. The authentication password must be the same on each switch.
5 Enable VRRP on each switch.
Note. Optional. To verify the VRRP configuration, enter the show vrrp command. The display is similar
to the one shown here:
VRRP trap generation: Enabled
VRRP startup delay: 45 (expired)
IP Admin Adv
VRID VLAN Address(es) Status Priority Preempt Interval
----+ ----+ -------------+----------+----------+--------+---------
6 4 10.10.2.3 Enabled 100 yes 1
For more information about this display, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
VRRP Overview
VRRP allows the routers on a LAN to back up a default route. VRRP dynamically assigns responsibility
for a virtual router to a physical router (VRRP router) on the LAN. The virtual router is associated with an
IP address (or set of IP addresses) on the LAN. A virtual router master is elected to forward packets to the
IP address of the virtual router. If the master router becomes unavailable, the highest priority backup
router transitions to the master state.
Note. The IP address that is backed up can be the IP address of a physical router, or it can be a virtual IP
address.
The example provided here is intended for understanding VRRP and does not show a configuration that
would be used in an actual network.
VRRP Routers
OmniSwitch A OmniSwitch B
VRID 1
Master 1 Backup 1 Virtual Router
IP A
IP A IP B
default gateway to IP A
client station
In this example, each physical router is configured with a virtual router, VRID 1 which is associated with
IP address A. OmniSwitch A is the master router because it contains the physical interface to which IP
address A is assigned. OmniSwitch B is the backup router. The client is configured with a gateway address
of IP A.
When VRRP is configured on these switches, and both the switches are available, OmniSwitch A responds
to ARP requests for IP address A using the MAC address (00:00:5E:00:01:01) of the virtual router instead
of the physical MAC address assigned to the interface. OmniSwitch A accepts the packets sent to the
virtual MAC address and forward them as appropriate; it also accepts the packets addressed to IP address
A (such as ICMP ping requests).
OmniSwitch B responds to ARP requests for IP address B using the physical MAC address of the
interface. It does not respond to ARP requests for IP address A or to the virtual router MAC address.
If OmniSwitch A becomes unavailable, OmniSwitch B becomes the master router. OmniSwitch B then
responds to ARP requests for IP address A using the MAC address (00:00:5E:00:01:01) of the virtual
router. It also forwards the packets for IP address B and respond to ARP requests for IP address B using
the OmniSwitch’s physical MAC address.
OmniSwitch B uses IP address B to access the LAN. However, IP address B is not backed up. Therefore,
when OmniSwitch B becomes unavailable, IP address B also becomes unavailable.
Note. A limitation of the OmniSwitch is that a single VRID can be associated with a VLAN.
Each VRRP router can back up one or more virtual routers. The VRRP router containing the physical
interfaces to which the virtual router IP addresses are assigned is called the IP address owner. If it is
available, the IP address owner functions as the master router. The master router assumes the
responsibility of forwarding packets sent to the IP addresses associated with the virtual router and
answering ARP requests for these addresses.
To minimize network traffic, only the master router sends VRRP advertisements on the LAN. The IP
address assigned to the physical interface on the current master router is used as the source address in
VRRP advertisements. The advertisements communicate the priority and state of the master router
associated with the VRID to all VRRP routers. The advertisements are IP multicast datagrams sent to the
VRRP multicast address 224.0.0.18 (as determined by the Internet Assigned Numbers Authority).
If a master router becomes unavailable, it stops sending VRRP advertisements on the LAN. The backup
routers know that the master is unavailable based on the following algorithm:
Master Down Interval = (3 * Advertisement Interval) + Skew Time
where Advertisement Interval is the time interval between VRRP advertisements, and Skew Time is
calculated based on the priority value of the VRRP router as follows:
Skew Time = (256 - Priority) / 256
If the backup routers are configured with priority values that are close in value, there can be a timing
conflict, and the first backup to take over cannot be the one with the highest priority; and a backup with a
higher priority then preempts the new master. The virtual router can be configured to prohibit any
preemption attempts, except by the IP address owner. An IP address owner, if it is available, always
becomes the master of any virtual router associated with its IP addresses.
Note. Duplicate IP address or MAC address messages may display when a backup router takes over for a
master, depending on the timing of the takeover and the configured advertisement interval. This is true if
more than one backup is configured.
This mapping provides for up to 255 virtual routers (VRRPv2 and VRRPv3 combined) on an OmniSwitch.
ARP Requests
Each virtual router has a single well-known MAC address, which is used as the MAC address in ARP
instead of a VRRP router's physical MAC address. When an end host sends an ARP request to the IP
address of the master router, the master router responds to the ARP request using the virtual router MAC
address. If a backup router takes over for the master, and an end host sends an ARP request, the backup
replies to the request using the virtual router MAC address.
Gratuitous ARP requests for the virtual router IP address or MAC address are broadcast when the OmniS-
witch becomes the master router. For VRRP interfaces, gratuitous ARP requests are delayed at system
boot until both the IP address and the virtual router MAC address are configured.
If an interface IP address is shared by a virtual router, the routing mechanism does not send a gratuitous
ARP for the IP address (since the virtual router sends a gratuitous ARP). This prevents traffic from being
forwarded to the router before the routing tables are stabilized.
ICMP Redirects
ICMP redirects are not sent out over VRRP interfaces.
VRRP Tracking
Priority of the virtual router can be conditionally modified to prevent another router from taking over as
master. Tracking policies are used to conditionally modify the priority setting whenever a slot/port, IP
address and or IP interface associated with a virtual router goes down.
A tracking policy consists of a tracking ID, the value used to decrease the priority value, and the slot/port
number, IP address, or IP interface name to be monitored by the policy. The policy is then associated with
one or more virtual routers.
Note. VRRP3 does not support the collective management functionality in this release.
• Router Discovery Protocol (RDP)—If RDP is enabled on the switch, and VRRP is enabled, RDP
advertises VLAN IP addresses of virtual routers depending on whether there are virtual routers active
on the LAN, and whether those routers are backups or masters. When there are no virtual routers active
on the VLAN (either acting as master or backup), RDP advertises all VLAN IP addresses. However, if
virtual routers are active, RDP advertises IP addresses for any master routers; RDP does not
advertise IP addresses for backup routers.
For more information about RDP, see Chapter 31, “Configuring RDP.”
• Preempt mode. By default, preempt mode is enabled. Use no preempt to turn it off, and preempt to
turn it back on. For more information about the preempt mode, see “Setting Preemption for Virtual
Routers” on page 34-13.
• Advertising interval (in seconds). Use the interval keyword with the desired number of seconds for the
delay in sending VRRP advertisement packets. The default is 1 second. See
“Configuring the Advertisement Interval” on page 34-12.
• VRRP authentication. By default, VRRP packets are not authenticated; use authenticate to enable
simple text password authentication. A password of up to 16 characters must be entered. Use no
authenticate to disable authentication. See “Configuring VRRP Authentication” on page 34-13.
The following example creates a virtual router (with VRID 7) on VLAN 2 with a priority of 75. The
preempt mode of the router is enabled and VRRP advertisements are sent at intervals of 2 seconds, and
VRRP packets will be authenticated with the password wwwtoe:
-> vrrp 7 2 priority 75 preempt interval 2
Note. All virtual routers with the same VRID on the same LAN must be configured with the same
advertising interval; otherwise the network can produce duplicate IP or MAC address messages. These
virtual routers should be configured with the same authentication setting. If authentication is enabled, all
routers must have the same password.
The vrrp command can also be used to specify whether the virtual router is enabled or disabled (it is
disabled by default). However, the virtual router must have an IP address assigned to it before it can be
enabled. Use the vrrp address command as described in the next section to specify an IP address or
addresses.
To delete a virtual router, use the no form of the vrrp command with the relevant VRID and VLAN ID.
For example:
-> no vrrp 7 3
Virtual router 7 on VLAN 3 is deleted from the configuration. (The virtual router does not have to be
disabled before you delete it.)
For more information about the vrrp command syntax, see the OmniSwitch 6250/6350/6450 CLI Refer-
ence Guide.
In this example, the vrrp address command specifies that virtual router 6 on VLAN 4 is used to back up
IP address 10.10.2.3. The virtual router is then enabled with the vrrp command.
If a virtual router is to be the IP address owner, then all addresses on the virtual router must match an
address on the switch interface.
To remove an IP address from a virtual router, use the no form of the vrrp address command. For
example:
In this example, virtual router 6 is disabled. (A virtual router must be disabled before IP addresses can be
added or removed from the router.) IP address 10.10.2.3 is then removed from the virtual router with the
no form of the vrrp address command.
In this example, virtual router 6 is disabled. (If you are modifying an existing virtual router, the virtual
router must be disabled before modification.) The vrrp command is then used to set the advertising inter-
val for virtual router 6 seconds to 5 seconds.
In this example, virtual router 6 is disabled. (If you are modifying an existing virtual router, it must be
disabled before it is modified.) The virtual router priority is then set to 50. Since the default priority is 100,
setting the value to 50 provides the router with lower priority in the VRRP network.
Note. In certain cases, this is not a desirable behavior, as when the original master comes back, and
immediately causes all the traffic to switch back to it.
If all virtual routers have the preempt mode enabled (the default), the virtual router with the highest
priority becomes the master. If the master router goes down, the highest priority backup router becomes
the master. If the previous master or any other virtual router comes up with the preempt mode enabled and
has a higher priority value, this router becomes the new master.
To prevent a router with a higher priority value from automatically taking control from a master router
with a lower priority value, disable the preempt mode for the higher priority router. This is done by using
the no preempt keywords with the vrrp command. For example:
-> vrrp 6 4 disable
-> vrrp 6 4 no preempt
Note. The virtual router that owns the IP addresses associated with the physical router always becomes the
master router if it is available, regardless of the preempt mode setting and the priority values of the backup
routers.
In the above example, the first command administratively disables virtual router 6. (If you are modifying
an existing virtual router, it must be disabled before it is modified.). The second command disables the
preempt mode for the same router. Henceforth, router 6 does not preempt another virtual router with a
lower priority. For more information about priority, see “Configuring Virtual Router Priority” on
page 34-12.
Note. The only scenario where authentication is not recommended is an environment with minimal secu-
rity risk and little chance for configuration error (such as two VRRP routers on a LAN).
Typically, simple text password authentication should be configured for VRRP. Simple text password
authentication is similar to simple text authentication for the Open Shortest Path First (OSPF) routing
protocol.
Simple text authentication is recommended because it protects against accidental misconfiguration of rout-
ers on a LAN and inadvertently backing up another router. If authentication is used, all virtual routers on
the LAN must be configured with the same password and the password must not be the same as any signif-
icant security password.
This type of authentication is recommended when there is minimal risk of nodes on a LAN actively
disrupting VRRP operation. If this type of authentication is used, the user should be aware that the clear
text password is sent out frequently. It is possible for the password to be learned by a node snooping
VRRP packets on the LAN; however, the simple text authentication combined with VRRP’s built-in TTL
check make it difficult for a VRRP packet to be sent from a remote network to disrupt VRRP operation.
To configure authentication for a virtual router, use the authenticate keyword and the desired password
with the vrrp command. For example:
-> vrrp 6 4 disable
-> vrrp 6 4 authenticate wwwtoe
In this example, virtual router 6 is disabled. (If you are modifying an existing virtual router, the virtual
router must be disabled before it may be modified.) The virtual router is then configured for authentica-
tion with the password wwwtoe. VRRP packets will be authenticated with this password.
Note. All VRRP routers on the same LAN should be configured with the same authentication setting. If
authentication is enabled, all routers must have the same password.
To remove authentication from a virtual router, use the keyword with no. For example:
-> vrrp 6 4 no authenticate
Note that if you are modifying an existing virtual router, the virtual router must be disabled before authen-
tication may be disabled.
In this example, a virtual router is created on VLAN 3 with a VRID of 7. An IP address is then assigned to
the virtual router. The virtual router is then enabled on the switch.
A virtual router must be disabled before it is modified. Use the vrrp command to disable the virtual router
first; then use the command again to modify the parameters. For example:
-> vrrp 7 3 disable
-> vrrp 7 3 priority 200
-> vrrp 7 3 enable
In this example, virtual router 7 on VLAN 3 is disabled. The virtual router is then modified to change its
priority setting. (For information about configuring the priority setting, see “Configuring Virtual Router
Priority” on page 34-12.) The virtual router is then re-enabled and become active on the switch.
The switch now waits 75 seconds after its reboot before it becomes available to take over as master for
another router.
You can change the default priority value of all the virtual routers on a switch using the vrrp priority
command. For example:
-> vrrp priority 50
You can change the default preempt mode of all the virtual routers on a switch using the vrrp preempt
command. For example:
-> vrrp no preempt
These commands sets the new default values only for the virtual routers that are newly created. However,
you can apply the new default value to the existing virtual routers. To apply the new default value to the
existing virtual routers; first disable the virtual routers, then apply the new default value using the vrrp set
command and enable the virtual routers again.
For example, to change the default priority value to 50 on all the existing virtual routers on a switch, enter
the following:
-> vrrp priority 50
-> vrrp disable
-> vrrp set priority
-> vrrp enable
The first command configures the default priority value as 50 for all the virtual routers on the switch. The
next command disables all the virtual routers on the switch. The vrrp set command in this sequence
applies the new default priority value to the existing virtual routers. This value is applied only to those
virtual routers already having the default values and not the values configured either individually or
through a group. This is because the configured values take priority over the default values.
For the modified default values to effect the virtual routers which are configured with a value either
individually or through a group, you can use the same command in addition with the override option. For
example:
-> vrrp set priority override
Note. You can specify a parameter such as interval, priority, preempt or all in the vrrp set command to set
and/or override the existing value with the new default values. By default, the option all is applied. The all
option resets and/or overrides the existing advertising interval value, priority value and preempt mode with
the modified default values.
The next command enables all the virtual routers on the switch except the virtual routers that are disabled
individually or through a group. To enable all the virtual routers on the switch including those which are
disabled individually or through a group, you can use the same command with the enable all option as
follows:
-> vrrp enable all
Note. This collective virtual routers management functionality does not affect the ability to change the
administrative status and parameter values of an individual virtual router.
This command creates a virtual router group 25. Use the no form of the same command to delete a virtual
router group. For example:
-> no vrrp group 25
Note. When a virtual router group is deleted, the virtual routers assigned to the group become unassigned.
However, this does not have any impact on the virtual routers.
After creating a virtual router group, add virtual routers to the group using the vrrp group-association
command as follows:
-> vrrp 10 1 group-association 25
The vrrp group-association command adds the virtual router 10 on VLAN 1 to the virtual router group
25. A virtual router need not be disabled in order to be added to a virtual router group. However, the
virtual router does not adopt the default parameter values of the group until those values are applied by
re-enabling the virtual router.
To remove a virtual router from a virtual router group, use the no form of the same command as follows:
-> vrrp 10 1 no group-association 25
The vrrp group command configures the default values for advertising interval as 50 seconds, priority as
150 and preempting mode as no preempt. These parameters can be modified at any time. This does not
affect the virtual routers in the group until you disable, then apply the group default value using the vrrp
group set command and enable the virtual router group again.
For the modified default values to be applied to the virtual routers in a group, disable the virtual router
group, then apply the group default value using the vrrp group set command and enable the virtual router
group again. For example:
The first command configures the default interval value as 50 for all the virtual routers in the virtual router
group 25. The next command disables all the virtual routers in the group. The vrrp group set command in
this sequence applies the new default interval value to all the virtual routers in the group. This value is
applied only to the virtual routers in the group that already have the default value and not the values
configured individually. This is because the configured values take priority over the default values.
For the modified default values to affect the virtual routers in the group, including the virtual routers that
are configured with a value individually, you can use the same command in addition with the override
option. For example:
-> vrrp group set interval override
Note. You can specify a parameter such as interval, priority, preempt or all in the vrrp group set
command to set and/or override the existing value with the new default values. By default the option all is
applied. The all option resets and/or overrides the existing advertising interval value, priority value and
preempt mode with the modified default values.
The next command enables all the virtual routers in the group except the virtual routers that are disabled
individually. To enable all the virtual routers in the group including the routers that are disabled
individually, use the command with the enable all option as follows:
-> vrrp group 25 enable all
Note. Even though a virtual router can be assigned to a group, its parameter values and administrative
status can still be modified individually.
show vrrp Displays the virtual router configuration for all virtual routers or for a
particular virtual router.
show vrrp statistics Displays statistics about VRRP packets for all virtual routers configured
on the switch or for a particular virtual router.
show vrrp track Displays information about tracking policies on the switch.
show vrrp track-association Displays the tracking policies associated with virtual routers.
show vrrp group Displays the default parameter values for all the virtual router groups or
for a specific virtual router group.
show vrrp group-association Displays the virtual routers that are associated with a group.
For more information about the displays that result from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
• Preempt mode. By default, preempt mode is enabled. Use no preempt to turn it off, and preempt to
turn it back on. For more information about the preempt mode, see “Setting Preemption for VRRPv3
Virtual Routers” on page 34-23.
• Accept mode. By default, the accept mode is enabled. This mode allows the master router to accept
packets addressed to the IPv6 address owner as its own. Use the no accept mode to prevent the master
router from accepting packets addressed to the IPv6 address owner.
• Advertising interval (in centiseconds). Use the interval keyword with the desired number of
centiseconds for the delay in sending VRRPv3 advertisement packets. The default is 100 centiseconds.
See “Configuring the VRRPv3 Advertisement Interval” on page 34-22.
Note. The maximum number of virtual routers supported is based on the 100 centisecond interval. A
smaller interval results in a relatively lesser number of virtual routers.
• VRRP authentication. By default, VRRP packets are not authenticated; use authenticate to enable
simple text password authentication. A password of up to 16 characters must be entered. Use no
authenticate to disable authentication. See “Configuring VRRP Authentication” on page 34-13.
The following example creates a VRRPv3 virtual router (with VRID 7) on VLAN 2 with a priority of 75,
and no preempt. VRRPv3 advertisements are sent at intervals of 200 centiseconds, and VRRP packets will
be authenticated with the password wwwtoe:
-> vrrp3 7 2 priority 75 no preempt interval 200
Note. All VRRPv3 virtual routers with the same VRID on the same LAN must be configured with the
same advertisement interval; otherwise the network can produce duplicate IPv6 or MAC address
messages. These virtual routers should be configured with the same authentication setting. If authentica-
tion is enabled, all routers must have the same password.
The vrrp3 command can also be used to specify whether the VRRPv3 virtual router is enabled or disabled
(it is disabled by default). For more information about the vrrp3 command syntax, see the OmniSwitch
6250/6350/6450 CLI Reference Guide.
To delete a VRRPv3 virtual router, use the no form of the vrrp3 command with the relevant VRID and
VLAN ID. For example:
-> no vrrp3 7 3
VRRPv3 virtual router 7 on VLAN 3 is deleted from the configuration. (The virtual router does not have
to be disabled before you delete it.)
In the above example, the vrrp3 address command specifies that VRRPv3 virtual router 6 on VLAN 4 is
used to back up IPv6 address fe80::200:5eff:fe00:20a. The virtual router is then enabled with the
vrrp3 command.
If a virtual router is to be the IP address owner, then all addresses on the virtual router must match an
address on the switch interface. This includes the virtual router's link local address. In other words, a
virtual router cannot be the IP address owner if its link local address does not match the interface link local
address.
To remove an IPv6 address from a virtual router, use the no form of the vrrp3 address command. For
example:
-> vrrp3 6 4 disable
-> vrrp3 6 4 no address fe80::200:5eff:fe00:20a
In this example, VRRPv3 virtual router 6 is disabled. (A VRRPv3 virtual router must be disabled before
IPv6 addresses can be added or removed from the router.) IP address fe80::200:5eff:fe00:20a is then
removed from the virtual router with the no form of the vrrp3 address command.
In this example, VRRPv3 virtual router 6 is disabled. (If you are modifying an existing virtual router, the
virtual router must be disabled before it is modified.) The vrrp3 command is then used to set the advertis-
ing interval for virtual router 6 to 500 centiseconds.
In this example, VRRPv3 virtual router 6 is disabled. (If you are modifying an existing virtual router, the
virtual router must be disabled before it is modified.) The virtual router priority is then set to 50. The
priority value is relative to the priority value configured for other virtual routers backing up the same IPv6
address. Since the default priority is 100, setting the value to 50 would typically provide a router with
lower priority in the VRRPv3 network.
Note. The VRRPv3 virtual router that owns the IPv6 addresses associated with the physical router always
becomes the master router if it is available regardless of the preempt mode setting and the priority values
of the backup routers.
To disable preemption for a VRRPv3 virtual router, use the vrrp3 command with the no preempt
keywords. For example:
In this example, virtual router 6 is disabled. (If you are modifying an existing virtual router, the virtual
router must be disabled before it is modified.) The virtual router is then configured to disable preemption.
If this virtual router takes over for an unavailable router, a router with a higher priority will not be able to
preempt it. For more information about priority, see “Configuring the VRRPv3 Virtual Router Priority” on
page 34-23.
Note. The only scenario where authentication is not recommended is an environment with minimal secu-
rity risk and little chance for configuration error (such as two VRRP routers on a LAN).
Typically, simple text password authentication should be configured for VRRP. Simple text password
authentication is similar to simple text authentication for the Open Shortest Path First (OSPF) routing
protocol.
Simple text authentication is recommended because it protects against accidental misconfiguration of rout-
ers on a LAN and inadvertently backing up another router. If authentication is used, all virtual routers on
the LAN must be configured with the same password and the password must not be the same as any signif-
icant security password.
This type of authentication is recommended when there is minimal risk of nodes on a LAN actively
disrupting VRRP operation. If this type of authentication is used, the user should be aware that the clear
text password is sent out frequently. It is possible for the password to be learned by a node snooping
VRRP packets on the LAN; however, the simple text authentication combined with VRRP’s built-in TTL
check make it difficult for a VRRP packet to be sent from a remote network to disrupt VRRP operation.
To configure authentication for a virtual router, use the authenticate keyword and the desired password
with the vrrp command. For example:
-> vrrp 6 4 disable
-> vrrp 6 4 authenticate wwwtoe
In this example, virtual router 6 is disabled. (If you are modifying an existing virtual router, the virtual
router must be disabled before it may be modified.) The virtual router is then configured for authentica-
tion with the password wwwtoe. VRRP packets will be authenticated with this password.
Note. All VRRP routers on the same LAN should be configured with the same authentication setting. If
authentication is enabled, all routers must have the same password.
To remove authentication from a virtual router, use the keyword with no. For example:
-> vrrp 6 4 no authenticate
Note that if you are modifying an existing virtual router, the virtual router must be disabled before authen-
tication may be disabled.
In this example, a VRRPv3 virtual router is created on VLAN 3 with a VRID of 7. An IPv6 address is
then assigned to the virtual router. The virtual router is then enabled on the switch.
To disable a VRRPv3 virtual router, use the disable keyword.
-> vrrp 7 3 disable
A VRRPv3 virtual router must be disabled before it is modified. Use the vrrp3 command to disable the
virtual router first; then use the command again to modify the parameters. For example:
-> vrrp3 7 3 disable
-> vrrp3 7 3 priority 200
-> vrrp3 7 3 enable
In this example, VRRPv3 virtual router 7 on VLAN 3 is disabled. The VRRPv3 virtual router is then
modified to change its priority setting. (For information about configuring the priority setting, see
“Configuring the VRRPv3 Virtual Router Priority” on page 34-23.) The virtual router is then re-enabled
and becomes active on the switch.
show vrrp3 Displays the VRRPv3 virtual router configuration for all virtual routers
or for a particular virtual router.
show vrrp3 statistics Displays statistics about VRRPv3 packets for all VRRPv3 virtual
routers configured on the switch or for a particular virtual router.
show vrrp3 track-association Displays the tracking policies associated with VRRPv3 virtual routers.
For more information about the displays that result from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
In this example, a tracking policy ID (3) is created and enabled for IP address 20.1.1.3. If this address
becomes unreachable, a virtual router associated with this track ID has its priority decremented by 50. The
enable keyword administratively activates the tracking policy, but the policy does not take effect until it is
associated with one or more virtual routers (see the next section).
Similarly, to create a tracking policy ID (3) for IPv6 address 213:100:1::56, use the following command:
-> vrrp track 3 enable priority 50 address 213:100:1::56
If this address becomes unreachable, a virtual router associated with this track ID has its priority
decremented by 50.
Note the following:
• A virtual router must be administratively disabled before a tracking policy for the virtual router can be
added.
• VRRP tracking does not override IP address ownership (the IP address owner will always have
priority to become master, if it is available).
When the virtual router is re-enabled, tracking policy 3 is used for that virtual router.
A tracking policy must not be associated with a virtual router on the same port or interface. For example:
-> ip interface vlan-4 address 10.1.1.1 vlan 4
-> vrrp track 2 ipv4-interface vlan-4
-> vrrp 5 4 track-association 2
This configuration is allowed but does not affect. If the associated interface goes down, the virtual router
goes down as well and the tracking policy is not applied.
Note. A master and a backup virtual router must not track the same IP address. Else, when the IP address
becomes unreachable, the priority of both virtual routers is decremented, and the backup can temporarily
take over if the master discovers that the IP address is unreachable before the backup.
It is recommended not to configure the same IP address tracking policies on physical VRRP routers that
back up each other; otherwise, the priority is decremented for both master and backup when the entity
being tracked goes down.
VRID 1
Master 1 Backup 1
10.10.2.250
Virtual Routers
VRID 2
Backup 2 Master 2
10.10.2.245
10.10.2.250 10.10.2.245
VLAN 5
1 First, create two virtual routers for VLAN 5. (VLAN 5 must already be created and available on the
switch.)
-> vrrp 1 5
-> vrrp 2 5
Note. The same VRRP configuration must be set up on each switch. The VRRP router that contains, or
owns, the IP address automatically becomes the master for that virtual router. If the IP address is a virtual
address, the virtual router with the highest priority becomes the master router.
In this scenario, the master of VRID 1 responds to ARP requests for IP address A using the virtual router
MAC address for VRID 1 (00:00:5E:00:01:01). OmniSwitch 1 is the master for VRID 1 since it contains
the physical interface to which 10.10.2.250 is assigned. If OmniSwitch A must become
unavailable, OmniSwitch B becomes the master for VRID 1.
In the same way, the master of VRID 2 responds to ARP requests for IP address B using the virtual router
MAC address for VRID 2 (00:00:5E:00:01:02). OmniSwitch B is the master for VRID 2 since it contains
the physical interface to which 10.10.2.245 is assigned. If OmniSwitch B must become
unavailable, OmniSwitch A becomes the master for 10.10.2.245. This configuration provides
uninterrupted service for the end hosts.
VRID 1
Master 1 Backup 1
10.10.2.250
Virtual Routers
VRID 2
Backup 2 Master 2
10.10.2.245
10.10.2.250 10.10.2.245
VLAN 5
In this example, the master for virtual router 1 has a priority of 100 and the backup for virtual router 1 has
a priority of 75. The virtual router configuration for VRID 1 and 2 on VRRP router A is as follows:
-> vrrp 1 5 priority 100 preempt
The virtual router configuration for VRID 1 and 2 on VRRP router B is as follows:
-> vrrp 1 5 priority 75
To ensure workstation clients 1 and 2 have connectivity to the internet, configure a tracking policy on
VRRP router A to monitor port 3/1 and associate the policy with VRID 1.
-> vrrp track 1 enable priority 50 port 3/1
-> vrrp 1 5 track-association 1
If port 3/1 on VRRP router A goes down, the master for virtual router A continue to function but
workstation clients 1 and 2 will not be able access the Internet. With this tracking policy enabled, the
priority of the master router 1 is temporarily decremented to 50, allowing backup router 1 to take over and
provide connectivity for the workstations. When port 3/1 on VRRP router A comes backup, master 1 takes
over again.
Note. Preempt must be set on switch A virtual router 1, and switch B virtual router 2 for the correct master
to assume control once their respective ports 3/1 return to viability. In our example, once port 3/1 on
switch A is functioning again, switch A must reestablish itself as the master. See “Setting Preemption for
Virtual Routers” on page 34-13 for more information about enabling preemption.
VRID 1
Master 1 Backup 1
213:100:1::56
Virtual Routers
VRID 2
Backup 2 Master 2
213:100:1::57
213:100:1::56 213:100:1::57
VLAN 5
1 First, create two VRRPv3 virtual routers for VLAN 5. (VLAN 5 must already be created and available
on the switch.)
-> vrrp3 1 5
-> vrrp3 2 5
Note. The same VRRPv3 configuration must be set up on each switch. The VRRPv3 router that contains,
or owns, the IPv6 address automatically becomes the master for that virtual router. If the IPv6 address is a
virtual address, the virtual router with the highest priority becomes the master router.
In this scenario, the master of VRID 1 responds to neighbor solicitation with a neighbor advertisement for
IPv6 address A using the virtual router MAC address for VRID 1 (00:00:5E:00:02:01). OmniSwitch 1 is
the master for VRID 1 since it contains the physical interface to which 213:100:1::56s assigned. If
OmniSwitch A must become unavailable, OmniSwitch B becomes master for VRID 1.
In the same way, the master of VRID 2 responds to neighbor solicitation for IPv6 address B using the
virtual router MAC address for VRID 2 (00:00:5E:00:02:02). OmniSwitch B is the master for VRID 2
since it contains the physical interface to which 213:100:1::57 is assigned. If OmniSwitch B must
become unavailable, OmniSwitch A becomes the master for 213:100:1::57. This configuration provides
uninterrupted service for the end hosts.
VRID 1
Master 1 Backup 1
213:100:1::56
Virtual Routers
VRID 2
Backup 2 Master 2
213:100:1::57
213:100:1::56 213:100:1::57
VLAN 5
In this example, the master for virtual router 1 has a priority of 100 and the backup for virtual router 1 has
a priority of 75. The virtual router configuration for VRID 1 and 2 on VRRPv3 router A is as follows:
-> vrrp3 1 5 priority 100 preempt
The virtual router configuration for VRID 1 and 2 on VRRPv3 router B is as follows:
-> vrrp3 1 5 priority 75
To ensure workstation clients 1 and 2 have connectivity to the internet, configure a tracking policy on
VRRPv3 router A to monitor port 3/1 and associate the policy with VRID 1.
-> vrrp3 track 1 enable priority 50 port 3/1
If port 3/1 on VRR3 router A goes down, the master for virtual router A is still functioning, but
workstation clients 1 and 2 will not be able to get to the Internet. With this tracking policy enabled,
however, master router 1’s priority will be temporarily decremented to 50, allowing backup router 1 to
take over and provide connectivity for those workstations. When port 3/1 on VRRPv3 router A comes
backup, master 1 takes over again.
Note. Preempt must be set on switch A virtual router 1, and switch B virtual router 2 for the correct master
to assume control once their respective ports 3/1 return to viability. In our example, once port 3/1 on
switch A is functioning again, switch A must reestablish itself as the master. See “Setting Preemption for
Virtual Routers” on page 34-13 for more information about enabling preemption.
Access Guardian refers to the following Alcatel-Lucent security functions that work together to provide a
dynamic, proactive network security solution:
• Authentication and Classification—Access control is configured on 802.1X-enabled ports using
device classification policies. A policy can specify the use of one or more types of authentication
methods (802.1X, MAC-based, or Web-based Captive Portal) for the same port. For each type of
authentication, the policy also specifies the classification method (RADIUS, Group Mobility, default
VLAN, or block device access).
• Host Integrity Check (HIC)—An integrated solution for device integrity verification. This solution
consists of the HIC server, a permanent or web-based download-able agent to verify host compliance,
and User Network Profiles (UNP). HIC is triggered when a UNP is applied to a device and HIC is
enabled for the UNP.
Note. For an enhanced solution using the ClearPass server and posture checking please refer to the BYOD
section.
• User Network Profiles (UNP)—One of the configurable options of a device classification policy is to
classify a device with a UNP. When the policy applies the UNP to one or more devices, the UNP
determines the VLAN assignment for the device, whether or not HIC is required for the device, and if
any QoS access control list (ACL) policies are applied to the device.
• Virtual Network Profile (VNP) - Also referred to as the Universal Network Profile (UNP), it
provides a method for dynamically assigning network devices to VLAN domains. A profile consists of
configurable attributes that help to define a group of users or devices that have similar requirements for
access to network resources. A device sending traffic that matches such attributes is then assigned to a
VLAN associated with the UNP. The UNP may also specify a QoS policy list that is subsequently
applied to device traffic associated with the UNP VLAN. For more information on UNP commands,
see OmniSwitch 6250/6350/6450 CLI Reference Guide and for UNP configuration, see chapter
“Configuring Universal Network Profiles”.
• Bring Your Own Device (BYOD) - OmniSwitch / ClearPass Integration: Guest users and user
devices information can be allowed to access specific network resources. BYOD support provides
restricted access to the network so that the end user device can be validated, user roles identified,
compliance checked, and have the correct access policies applied. The OmniSwitch leverages the
Access Guardian features along with the ClearPass Policy Manager to provide the overall BYOD
solution. See the “Bring Your Own Device (BYOD) Overview” on page 35-58 for information on the
Access Guardian/ClearPass solution. This section focuses on the OmniSwitch/Clearpass integration.
For additional information refer to the following:
• OmniAccess WLAN documentation
• ClearPass Policy Manager documentation for in-depth server configuration and licensing
requirements
• Alcatel-Lucent’s ClearPass and OmniSwitch Configuration Video.
Note.
Find the ClearPass and OmniSwitch Configuration Videos on youtube in the following location:
https://www.youtube.com/watch?v=PyueDr-GAFM&list=PLrzAZN530GJ8kfUJCNsjIhJW6cAV5AACb
In This Chapter
This chapter provides an overview of Access Guardian security features and describes how to configure
these features through the Command Line Interface (CLI). CLI commands are used in the configuration
examples; for more details about the syntax of commands, see the OmniSwitch 6250/6350/6450 CLI Refer-
ence Guide.
The following information and procedures are included in this chapter:
• “Quick Steps for Configuring Access Guardian” on page 35-6
• “Access Guardian Overview” on page 35-13.
• “Interaction With Other Features” on page 35-24
• “Setting Up Port-Based Network Access Control” on page 35-25
• “Configuring Access Guardian Policies” on page 35-30
• “Configuring 802.1x Authentication Bypass” on page 35-39
• “Configuring Captive Portal Authentication” on page 35-41
• “Configuring Host Integrity Check” on page 35-48
• “Configuring User Network Profiles” on page 35-50
• “Verifying Access Guardian Users” on page 35-54
• “Verifying the Access Guardian Configuration” on page 35-57
• “Bring Your Own Device (BYOD) Overview” on page 35-58
• “Multicast Domain Name System (mDNS)” on page 35-68
For more information about configuring 802.1X on switch ports, see Chapter 37, “Configuring 802.1X.”.
1 To configure an Access Guardian policy that authenticates and classifies 802.1x users (supplicants),
use the 802.1x supplicant policy authentication command.
-> 802.1x 2/12 supplicant policy authentication pass group-mobility default-vlan
fail vlan 10 captive-portal
2 To configure an Access Guardian policy that authenticates and classifies non-802.1x users
(non-supplicants), use the 802.1x non-supplicant policy authentication command.
-> 802.1x 2/12 non-supplicant policy authentication pass group-mobility
default-vlan fail vlan 10 captive-portal
3 To associate a UNP with maximum ingress and egress bandwidth along with maximum default depth,
use the aaa user-network-profile command with maximum-ingress-bandwidth, maximum-egress-band-
width, and maximum-default-depth parameters.
-> aaa user-network-profile name "profile1" vlan 50 maximum-ingress-bandwidth
1024 maximum-egress-bandwidth 256 maximum-default-depth 128
4 To configure an Access Guardian Captive Portal policy that classifies web-based clients, use the
802.1x captive-portal policy authentication command.
Note. This policy is triggered only when the Captive Portal option of a supplicant or non-supplicant policy
is applied.
-> 802.1x 2/12 captive-portal policy authentication pass vlan 100 block fail
vlan 10
5 To configure the length of a Captive Portal session, use the 802.1x captive-portal session-limit
command.
-> 802.1x 3/1 captive-portal session-limit 8
6 To configure the number of Captive Portal login attempts allowed before a device is classified as a
failed login, use the 802.1x captive-portal retry-count command.
-> 802.1x 3/1 captive-portal retry-count 5
7 To bypass authentication and restrict device classification of non-802.1x users to VLANs that are not
authenticated VLANs, use the 802.1x non-supplicant policy command.
-> 802.1x 3/10 non-supplicant policy vlan 43 block
8 To set the Access Guardian policy back to the default classification policy for an 802.1x port, use the
802.1x policy default command.
-> 802.1x 3/10 policy default
Note. Verify the Access Guardian configuration using the show 802.1x device classification policies
command:
-> show 802.1x device classification policies
To verify the Captive Portal configuration for an 802.1X-enabled port, use the 802.1x auth-server-down
command:
-> show 802.1x 1/13
direction = both,
operational directions = both,
port-control = auto,
quiet-period (seconds) = 60,
tx-period (seconds) = 30,
supp-timeout (seconds) = 30,
server-timeout (seconds) = 30,
max-req = 2,
re-authperiod (seconds) = 3600,
reauthentication = no
Supplicant polling retry count = 2
Captive Portal Session Limit (hrs) = 12
Captive Portal Login Retry Count = 3
To verify the global Captive Portal configuration for the switch, use the show 802.1x auth-server-down
command:
-> show 802.1x captive-portal configuration
To display the number of non-802.1x users learned on the switch, use the show 802.1x non-supplicant
command:
-> show 802.1x non-supplicant
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for information about the fields in this display.
2 To enable the Host Integrity Check option for a UNP, use the aaa user-network-profile command
with the hic enable parameter.
-> aaa user-network-profile name guest_user vlan 500 hic enable
3 To associate a UNP with maximum ingress and egress bandwidth along with maximum default depth,
use the aaa user-network-profile command with maximum-ingress-bandwidth, maximum-egress-band-
width, and maximum-default-depth parameters.
-> aaa user-network-profile name "profile1" vlan 50 maximum-ingress-bandwidth
1024 maximum-egress-bandwidth 256 maximum-default-depth 128
4 To assign a list of QoS policies to a UNP, use the aaa user-network-profile command with the
policy-list-name parameter. Note that the policy list specified must already exist in the switch configura-
tion.
-> aaa user-network-profile name guest_user vlan 500 policy-list name temp_rules
5 To configure an Access Guardian device classification policy to apply a user profile, use the 802.1x
supplicant policy authentication, 802.1x non-supplicant policy authentication, 802.1x captive-portal
policy authentication, or 802.1x non-supplicant policy command with the user-network-profile param-
eter. For example:
-> 802.1x 1/10 supplicant policy authentication user-network-profile guest_user
Note. Verify the UNP configuration using the show aaa user-network-profile command:
-> show aaa user-network-profile
To verify the UNP configuration for a device classification policy, use the show 802.1x device classifica-
tion policies command:
-> show 802.1x device classification policies
Device classification policies on 802.1x port 2/26
Supplicant:
authentication:
pass: group-mobility, default-vlan (default)
fail: block (default)
Non-Supplicant:
block (default)
Captive Portal:
authentication:
pass: default-vlan (default)
fail: block (default)
Device classification policies on 802.1x port 2/48
Supplicant:
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for information about the fields in this display.
See “Configuring User Network Profiles” on page 35-50 for more information about configuring profiles.
2 To configure a UNP mobile rule for a range of MAC addresses, use the aaa classification-rule mac-
address-range command.
-> aaa classification-rule mac-address-range 00:00:2a:33:44:01 00:00:2a:33:44:10
user-network-profile name accounting
3 To configure an IP address UNP mobile rule, use the aaa classification-rule ip-address command.
4 To configure an Access Guardian Group Mobility device classification policy to authenticate and clas-
sify devices using UNP mobile rules, use the 802.1x supplicant policy authentication, 802.1x non-
supplicant policy authentication, 802.1x captive-portal policy authentication, or 802.1x non-suppli-
cant policy command with the group-mobility parameter. For example:
-> 802.1x 6/1 supplicant policy authentication pass group-mobility default-vlan
fail captive-portal
Note. If the default VLAN for port is same as User Network Profile (UNP) VLAN, then the UNP QoS
Policy List is not applied. Default VLAN of the port must be different from that of the UNP VLAN.
Verify the UNP mobile rule configuration using the show aaa classification-rule command:
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for information about the fields in this display.
See “Configuring User Network Profile Mobile Rules” on page 35-53 for more information.
2 Enable the HIC feature for the switch using the aaa hic command.
3 Enable the HIC option for the UNP using the aaa user-network-profile command.
4 Optional. Configure a server name and IP address entry for the HIC exception list using the aaa classi-
fication-rule mac-address command.
-> aaa hic allowed-name rem_srv1 ip-address 10.1.1.1
5 Optional. Configure the URL for the web-agent download server using the aaa hic web-agent-url
command.
-> aaa hic web-agent-url http://10.10.10.10:2146
6 Optional. Configure the proxy port number for the host device using the aaa hic custom-proxy-port
command.
-> aaa hic custom-proxy-port 8878
Note. Verify the HIC configuration for the switch using the show aaa classification-rule command:
-> show aaa hic
HIC Global Status: Enabled
HIC Allowed 1: rem-serv1
HIC Web Agent URL: http://100.100.100.100:8080/CGAgentLauncher.htm
HIC Proxy Port: 8383
HIC Reconnect-timer: 16
HIC Server-fail-mode: Passthrough
To verify the HIC InfoSys CyberGatekeeper server information configured for the switch, use the show
aaa classification-rule command:
-> show aaa hic server
Server Server Server Server
Name IP Address UDP Port Role Connection Status
----------------+-----------------+---------+---------+------------+---------
hic-srv1 10.2.2.2 11707 Primary Active Down
hic 2.2.2.1 11707 Backup Inactive Down
To display the HIC status for host devices, use the show aaa hic host command:
See “Configuring Host Integrity Check” on page 35-48 for more detailed configuration information.
Quarantine Manager
(Reactive)
Qua
rant
ine
Intr
usio
nD etect
ion
Role
Access Guardian -Bas
(Proactive)
ed A
c cess
Host
Inte User Network Profiles (UNP)
grit y QoS ACL Lists
Auth
e ntica
tion Host Integrity Check (HIC) using
InfoExpress CyberGatekeeper
• For details on MAC authentication see “Enabling MAC Authentication” on page 35-25
Note. Default VLAN of the port must be different from that of the UNP VLAN. UNP Policy list is not
applied with UNP classified to UNP VLAN if it is same as the default VLAN assigned to the port.
1 Captive Portal—redirects the user device to a Web-based login screen and requires the user to enter
credentials to gain network access. This option is used only with the 802.1X, MAC, or Non-supplicant
policies. The Captive Portal policy is applied after Web-based authentication is attempted, so this option is
not valid for Captive Portal policies. See “Configuring the Captive Portal Policy” on page 35-37.
2 Group Mobility—uses Group Mobility VLAN rules and User Network Profile (UNP) mobile rules to
determine the VLAN assignment for a device. UNP rules apply a profile to any device that matches the
UNP rule criteria. Note that UNP mobile rules take precedence over VLAN rules. See “What are UNP
Mobile Rules?” on page 35-22.
4 Default VLAN—assigns a device to the default VLAN for the 802.1x port.
6 User Network Profile (UNP)—applies a pre-configured profile to a user device. The profile specifies
a required VLAN ID, the optional Host Integrity Check (HIC) status, and an optional QoS policy list
name. See “User Network Profiles (Role-Based Access)” on page 35-21.
7 mac-authentication—allows basic network access to trusted devices that failed in 802.1x supplicant
authentication by subjecting the user through non-supplicant MAC authentication.
It is possible to configure one or more of the classification options for a single policy. The order in which
the policy options are applied to a device is determined by the order in which the option was configured.
For example, if a MAC-based authentication policy is configured to use the Group Mobility and default
VLAN options, then the policy actions are applied in the following sequence:
1 MAC-based authentication is performed.
2 If authentication was successful and provided a VLAN ID, the client is assigned to that VLAN and no
further policy options are applied.
3 If a VLAN ID was not provided or authentication failed, then Group Mobility applies VLAN rules.
4 If there are no Group Mobility VLAN rules that match the client traffic, then the device is learned in
the default VLAN for the 802.1X port.
Note. Default VLAN of the port must be different from that of the UNP VLAN. UNP Policy list is not
applied with UNP classified to UNP VLAN if it is same as the default VLAN assigned to the port.
See “Configuring Access Guardian Policies” on page 35-30 for more information about how to use and
configure policies.
Note. It is possible to bypass 802.1x authentication and classify supplicants connected to an 802.1x port as
non-supplicants (see the “Configuring the Number of Polling Retries” section in
Chapter 37, “Configuring 802.1X,” for more information). When bypassing, all devices (including
supplicants) are then classified as non-supplicants. As a result, non-supplicant policies that use
MAC-based authentication are now applicable to supplicant devices, but not on non-supplicant devices.
The following diagram illustrates the conceptual flow of Access Guardian policies, including the separate
Web-based authentication branch provided by Captive Portal:
As shown in the Access Guardian Policy Flow diagram, Captive Portal is an optional policy that is
available for both supplicant and non-supplicant policies. When successful RADIUS authentication does
not return a VLAN ID or a device fails authentication, policies configured for the port are examined. If the
Captive Portal policy is configured for the port and invoked by device traffic, then the user must
authenticate through the switch through standard web browser software.
For more information, see “Configuring Access Guardian Policies” on page 35-30 and “Configuring
Captive Portal Authentication” on page 35-41.
Note. The HIC feature is not available unless the feature is enabled for the switch. This is true even if HIC
servers are configured for the switch or the HIC attribute is enabled for a profile. See “Configuring Host
Integrity Check” on page 35-48 for more information.
How it Works
The Access Guardian HIC process is triggered when a device initially connects to an 802.1X port and a
device classification policy for that port applies a HIC-enabled UNP to the device. The host device is then
granted limited access to the network; only DHCP, DNS, ARP, and any IP traffic between the host and
any HIC-related servers is allowed. During this time, the host invokes the HIC compliance agent (desktop
or Web-based) to complete the verification process.
If the HIC server determines the host is compliant, the host is then granted the appropriate access to the
network. If the HIC server determines the host is not compliant, the host network access remains restricted
to the HIC-related servers and any other remediation servers that can provide the host with the necessary
updates to achieve compliance.
This integrated solution to provide device integrity verification is also "always-on". The HIC agent
continues to check the integrity of the host device as long as the device remains connected to the switch. If
the compliance agent detects a violation of the security policies or the agent itself is disabled or
terminated, the HIC server notifies the switch to limit the network access for that device.
Note: The keepalive steps above are the same for the backup server if it becomes the ACTIVE server.
Note: The random reconnect value prevents a HIC server from being overwhelmed by HIC requests from
multiple switches simultaneously once the server becomes ACTIVE again.
• Once primary server is ACTIVE again, the backup server becomes inactive.
Dynamic UNP
The OmniSwitch can associate a client MAC address with a UNP based on an authentication result, such
as 802.1X or MAC authentication, or based on classification rules, such as IP or MAC ranges.
Dynamic UNP extends this capability by enhancing the protocol between the HIC server and the OmniS-
witch allowing the HIC server to return the UNP that a user must be associated with. This allows users to
be classified into UNPs based on Active Directory group memberships, machine specific parameters or
any other parameters the HIC agent supports. Once classified into a UNP, specific access rights can be
enforced by applying the policy list associated with the UNP to the user.
CMD-RESET Keyword
In the case of HIC failure if a UNP is returned with a special keyword of CMD-RESET, the associated
MAC address is flushed from the switch and forced to re-initiate the 802.1x classification.
In this example, the rad1 server is used for authenticating 802.1X ports. If rad1 becomes
unavailable, the switch uses rad2 for 802.1X authentication. When this command is used, 802.1X is
automatically enabled on the switch.
Note. The same RADIUS servers can be used for 802.1x (supplicant) and MAC (non-supplicant)
authentication. Using different servers for each type of authentication is allowed but not required.
For non-supplicant authentication and other details on configuring authentication servers, see chapter
Chapter 35, “Configuring Access Guardian”
For more information about using MAC authentication and classifying non-supplicant devices, see
“Authentication and Classification” on page 35-14, “Configuring Access Guardian Policies” on
page 35-30, and “Configuring User Network Profiles” on page 35-50.
MAC accounting
Use the aaa accounting mac command to create an accounting server entry for the non-supplicant
mac-based authentication. This verifies if the RADIUS server is configured as the authentication server for
MAC.
The following example specifies the accounting server rad1 for the non-supplicant MAC-based
authentication:
-> aaa accounting mac rad1 local
The 802.1x auth-server-down command is also used to enable or disable a policy. For example:
The authentication server down policy and re-authentication time period configuration applies to all
802.1x ports on the switch. To verify the authentication server down policy configuration, use the show
802.1x auth-server-down command.
Note. When device authentication fails due to an unreachable RADIUS server, an event message is sent to
the switch logging utility (swlog). See Chapter 44, “Using Switch Logging,” for more information.
Note. RADIUS server status can be checked periodically by enabling server polling using the 802.1x
server-polling command. show aaa server command displays the reachability status of different
RADIUS servers configured on the switch.
Classification Guidelines:
1 If the authentication server is down when an IP phone is connected for the first time and the initial
packet from the IP phone is not an LLDP packet, such as a EAP packet, the IP phone will not be seen as
an IP phone and will not be classified according to the voice-policy UNP. In such case, the IP phone will
be classified in data-auth-server-down policy.
2 After being classified, if the IP phone then sends an LLDP packet, the information will be passed on to
check if that device is already classified based on data-auth server down policy. If yes, then the client will
be re-authenticated automatically (does not wait for the re-auth interval) and moved to the voice-auth
server down policy, if the server is still unreachable.
3 During this re-authentication process, the device/authentication details in supplicant or non-supplicant
table will be modified to initial state, but the old VPA association and the MAC address will not be
deleted/modified until the server returns the result of the new authentication. If the returned/classified
VLAN/UNP of new authentication is same as the old VLAN/UNP, then the device/authentication details
in supplicant or non-supplicant table will be updated. If the returned/classified VLAN/UNP of new authen-
tication is different from the old VLAN/UNP, then the VPA is updated for new VLAN. Additionally, the
old MAC entry for that device will be removed and new entry will be added.
4 The above re-authentication procedure is applicable for the re-authentication scenarios listed below:
• Auth-server down re-authentication (auth-server down re-authentication only applies to data
devices).
• 802.1x re-authentication initiated by the switch.
• Client initiated EAP start.
5 During the re-authentication, the “port state” in show 802.1x users for that client shall display as
“Authenticating” until the authentication gets completed. Meanwhile MAC address table shall have the
client in previous classified VLAN. The MAC entry may get changed based on the result of the re-authen-
tication.
On removal of the voice policy, the UNP is applied with the auth-server-down policy.
Status = Enabled
Re-authentication Interval = 30 seconds
Classification policy = UNP 'unp1', block
Classification Voice Policy = UNP 'unp2'
To verify the classification type, use the show 802.1x non-supplicant command.
Example:
-> show 802.1x non-supplicant
The IP Phone when classified on a Voice Policy shows the classification policy type as AuthSvrDwn-VP-
UNP.
The vlan port 802.1x command enables 802.1X on port 1 of slot 3. The port is set up with defaults listed
in “802.1X Defaults” of the Chapter 37, “Configuring 802.1X.”
To disable 802.1X on a port, use the disable option with vlan port 802.1x command. For more
information about vlan port commands, See Chapter 7, “Assigning Ports to VLANs.”.”
Note. If no policies are configured on an 802.1x port, access from non-supplicant devices is blocked and
the following default classification policy is applied to supplicant devices:
2 If authentication fails or successful authentication returns a VLAN ID that does not exist, the device is
blocked.
3 If authentication is successful and returns a VLAN ID that exists in the switch configuration, the
supplicant is assigned to that VLAN.
4 If authentication is successful but does not return a VLAN ID, Group Mobility checks if there are any
VLAN rules or User Network Profile mobile rules that classify the supplicant.
5 If Group Mobility classification fails, the supplicant is assigned to the default VLAN ID for the 802.1x
port.
If no policy keywords are specified with this command (for example, 802.1x 1/10 supplicant policy
authentication), then supplicants are blocked if 802.1x authentication fails or does not return a VLAN ID.
Note that the order in which parameters are configured determines the order in which they are applied. For
example, the following commands apply Group Mobility rules at different times during the classification
process:
-> 802.1x 2/12 supplicant policy authentication pass group-mobility vlan 10
block fail vlan 10 default-vlan
The first command in the supplicant policy example checks Group Mobility rules first then checks for
VLAN 10 next. The second command checks for VLAN 10 first then checks for Group Mobility rules.
Use the pass keyword to specify which options to apply when 802.1x authentication is successful but does
not return a VLAN ID. Use the fail keyword to specify which options to apply when 802.1x
authentication fails or returns a VLAN ID that does not exist. The pass keyword is implied and therefore
an optional keyword. If the fail keyword is not used, the default action is to block the device.
Note. When a policy option is configured as a fail condition, device classification is restricted to
assigning supplicant devices to VLANs that are not authenticated VLANs.
The order in which parameters are configured determines the order in which they are applied. For
example, the following commands apply Group Mobility rules at different times during the classification
process:
-> 802.1x 2/12 non-supplicant policy authentication pass group-mobility vlan 10
block fail vlan 10 default-vlan
The first command in the non-supplicant policy example checks Group Mobility rules first then checks for
VLAN 10 next. The second command checks for VLAN 10 first then checks for Group Mobility rules.
Use the pass keyword to specify which options to apply when 802.1x authentication is successful but does
not return a VLAN ID. Use the fail keyword to specify which options to apply when 802.1x
authentication fails or returns a VLAN ID that does not exist. The pass keyword is implied and therefore
an optional keyword. If the fail keyword is not used, the default action is to block the device.
Use the pass keyword to specify which options to apply when MAC authentication is successful but does
not return a VLAN ID. Use the fail keyword to specify which options to apply when MAC authentication
fails. The pass keyword is implied and therefore an optional keyword. If the fail keyword is not used, the
default action is to block the device when authentication fails.
Note. When a policy option is configured as a fail condition, device classification is restricted to assigning
supplicant devices to VLANs that are not authenticated VLANs.
To configure a non-supplicant policy that does not perform MAC authentication, use the
802.1x non-supplicant policy command. The following parameter keywords are available with this
command to specify one or more policies for classifying devices:
Note that this type of policy does not use 802.1x or MAC authentication. As a result, all of the available
policy keywords restrict the assignment of the non-supplicant device to only those VLANs that are not
authenticated VLANs. The pass and fail keywords are not used when configuring this type of policy.
the port if the device failed authentication. As a result, it is only necessary to change the policy if the
default pass and fail cases are not sufficient.
To change the Captive Portal policy configuration, use the 802.1x captive-portal policy authentication
command. The following keywords are available with this command to specify one or more policies for
classifying devices.
The first command in the captive-portal policy example checks Group Mobility rules first then checks
for VLAN 10 next. The second command checks for VLAN 10 first then checks for Group Mobility
rules.
• When a policy is specified as a policy to apply when authentication fails, device classification is
restricted to assigning non-supplicant devices to VLANs that are not authenticated VLANs.
Configuration Guidelines
Consider the following guidelines before configuring 802.1x authentication bypass:
• The 802.1x bypass operation is only supported on 802.1x ports configured for auto access control
mode. See “Enabling 802.1X on Ports” on page 35-29 for more information about configuring the
access control mode.
• If a port has supplicants connected, and 802.1x bypass is enabled for that port, the supplicants are
automatically logged off to undergo authentication according to the enabled bypass configuration.
• When the 802.1x bypass configuration is modified or disabled, any non-supplicant devices are auto-
matically logged off the port. This will free up those devices to undergo the authentication specified by
the new bypass configuration.
• If re-authentication is configured for the 802.1x port and supplicant bypass is enabled, the MAC
authentication followed by 802.1x authentication is initially performed as configured. However, only
802.1x authentication is performed during the re-authentication process, so there is no recheck to see if
the MAC address of the user device is restricted.
• When successful MAC authentication returns a VLAN ID or User Network Profile (UNP) and the
802.1x bypass operation is configured to initiate 802.1x authentication when a device passes MAC
authentication, the device is not moved into that VLAN or UNP. Instead, the device is moved into the
VLAN or UNP returned by 802.1x authentication. If 802.1x authentication does not provide such infor-
mation, the device is moved based on the supplicant device classification policies for the port.
• When supplicant bypass is enabled after MAC authentication, till it completes the supplicant
authentication, the port will be in mac_authenticated_await8021x state.
• Configuring 802.1x supplicant bypass is not allowed on ports where the 802.1x supplicant polling retry
count is set to zero. Both operations are mutually exclusive on the same port.
• Using the 802.1x non-supplicant allow-eap command with the none parameter is similar to setting the
supplicant polling retry counter to zero (see “Configuring the Number of Polling Retries” section in
Chapter 34, “Configuring 802.1X,”). However, the functionality configured with each command differs
as follows:
> When the supplicant polling retry is set to zero, EAP frames are ignored. MAC authentication is
only triggered when a non-EAP frame is received, which is when the supplicant times out and is in
an open state.
> When the allow EAP is set to none, EAP frames are ignored but MAC authentication is triggered
when the first EAP frame is received and the supplicant is not in an open state.
The resulting Access Guardian authentication process for a device connected to 802.1x port 2/1 is as
follows for this example:
• MAC authentication is triggered when the first frame from the new user is received, whether it is an
EAP frame or not.
• EAP frames for this user are ignored until MAC authentication completes (RADIUS returns an
Access-Accept or a Access-Reject response).
• Once the initial MAC authentication passes (that is, Access-Accept), 802.1x authentication is bypassed
for this user and all EAP frames are ignored. The user is permanently authenticated through MAC
authentication and 802.1x is permanently bypassed.
• Once the initial MAC authentication fails (that is, Access-Reject), 802.1x authentication is allowed for
this user. The user is authenticated through 802.1x authentication. During this transition, the EAP
frames are allowed and the switch must force the supplicant to restart a fresh EAP session by sending a
multicast Request Identity EAPOL on the port. This is because the supplicant may have already sent an
EAPOL Start.
• Configure the homepage URL for the client browser. The Captive Portal authentication process
responds only to browser queries that contain the “www”, “http”, or “https” prefix in the URL. As a
result, it is necessary to configure the homepage URL for the browser with at least one of these three
prefixes.
• Configure a specific proxy server URL. Captive Portal looks for the word “proxy” to identify the
proxy server URL used by the client. If this URL does not contain the word “proxy”, use the 802.1x
captive-portal proxy-server-url command to specify the URL address to use.
• Configure an 802.1x device classification policy for Captive Portal authentication. A supplicant or
non-supplicant policy configured with Captive Portal as a pass or fail condition is required to invoke
Captive Portal authentication. For more information, see “Configuring Supplicant Policies” on
page 35-31 and “Configuring Non-supplicant Policies” on page 35-33.
• Configure a Captive Portal device classification policy. A separate Captive Portal policy is required
to classify devices when successful web-based authentication does not return a VLAN ID or
authentication fails. For more information, see “Configuring the Captive Portal Policy” on page 35-37.
• Configure the Captive Portal session time limit. This time limit determines the length of the Captive
Portal login session. When this time limit expires, the user is automatically logged out and network
access is blocked. For more information, see “Configuring Captive Portal Session Parameters” on
page 35-42.
• Configure the number of Captive Portal login attempts allowed. This number determines the
number of failed login attempts a user is allowed when initiating a Captive Portal session. For more
information, see “Configuring Captive Portal Session Parameters” on page 35-42.
The 802.1x captive-portal retry-count command is used to configure the maximum number of times a
user can try to log in through the Captive Portal login web page. When this limit is reached without
achieving a successful login, the fail case of the Captive Portal device classification policy configured for
the 802.1x port is applied to the user device. The default login retry count is set to 3. To specify an
unlimited amount of login retries, specify 0 for this parameter value.
-> 802.1x 1/10 captive-portal retry-count 0
Use the 802.1x auth-server-down command to display the current values for the Captive Portal session
parameters. An example of this command is available in the “Quick Steps for Configuring Access Guard-
ian” on page 35-6.
Once the custom files are created with the images and information the file type requires, download the
files to the /flash/switch directory on the switch. When a Captive Portal session is initiated, the switch
checks to see if there are any files in this directory; if so, then the custom files are incorporated and
displayed by Captive Portal. If no files are found, the default Captive Portal Web page components are
used.
Consider the following guidelines when customizing Captive Portal Web page components:
• Filenames are case sensitive. When creating a custom file, ensure that the filename matches the
filename exactly as shown in the list of file types described.
• Create custom logo and background pages using the .gif, .jpg, or .png formats. Captive Portal checks
the flash/switch directory on the switch.for a .gif file, then a .jpg file, and finally a .png file.
Whichever file type Captive Portal encounters first is the file used to display the custom logo or
background.
• The .inc files, which are used to present customized welcome messages, are partial HTML files that
can include only text or text and other HTML tags, such as links. Note that .inc files are wrapped in a
paragraph HTML tag within the body of a Captive Portal default page.
The following is an example of a customized Captive Portal login page:
Note. Captive Portal does not require the configuration of IP interfaces, a UDP Relay agent, or an
external DHCP server to provide an IP address for the client device. A temporary IP address derived from
the Captive Portal subnet is assigned to the client for use during the authentication process. For more
information, see “Configuring Captive Portal Authentication” on page 35-41.
When the browser window opens and after the certificate warning message, if any, is cleared, Captive
Portal displays a login screen similar to the one shown in the following example:
4 Click on the “Acceptable Use Policy” box to activate the “Submit” and “Bypass” buttons, as follows:
5 Click the “Submit” button to login to the network or click the “Bypass” button to bypass Captive Portal
authentication (see “Bypassing Captive Portal Login” on page 35-46). If the “Submit” button is clicked,
Captive Portal sends the user information provided in the login window to the RADIUS server for
authentication. The following status message appears during the authentication process:
6 If user authentication is successful, the following status and logout messages are displayed:
The user is now logged in to the network and has access to all network resources in the VLAN to
which this user was assigned. The VLAN membership for the user was either returned through
RADIUS authentication or determined through Captive Portal device classification (invoked when
RADIUS does not return a VLAN ID or authentication fails).
7 Click on “Bookmark the CP-Logout link” and note the http://captive-portal/logout URL before leaving
the Captive Portal status page or closing the browser window. See “Logging Off the Network with Captive
Portal” on page 35-47 for more information.
Note. The http://captive-portal/logout URL is used to display a Captive Portal logout page. If a user does
not log out of a Captive Portal session using this URL, the session remains active until the Captive Portal
session limit is reached (default is 12 hours). Adding a bookmark for this URL is highly
recommended.
To log off from a Captive Portal session, the user clicks the “Submit” button. The user is then logged off
the network and the user device returns to the Captive Portal state (device MAC address is unknown to the
switch).
The following logout confirmation page appears when the logout process is done.
Note. A user is automatically logged out of the network if the Captive Portal session time limit is reached.
For more information, see “Configuring Captive Portal Session Parameters” on page 35-42.
In addition to enabling HIC for a UNP, the following configuration tasks are involved in setting up the
HIC feature to run on the switch:
1 Configure the identity of the HIC server. Use the aaa hic server-name command to configure the
name and IP address of the InfoExpress CyberGatekeeper server, a shared secret, and the UDP port
number used for HIC requests.
-> aaa hic server-name hic-srv1 ip-address 2.2.2.2 key wwwtoe
Note that configuring the server is required before HIC can be enabled for the switch.
2 Configure the Web agent download server URL. A host can use the InfoExpress desktop compli-
ance agent or a Web-based agent. If the desktop agent is not installed on the host, the switch redirects the
host to a Web agent download server. The URL of the download server is configured for the switch using
the aaa hic web-agent-url command.
-> aaa hic web-agent-url http://10.10.10.10:2146
When the HIC process is initiated for a host device, the host has limited access to the network for commu-
nicating with the HIC server and any servers included in the exception list. Make sure the Web agent
download server is added to the server exception list, as described below.
3 Configure a server exception list.There are specific servers that a host device may need access to
during the HIC process. For example, if the host is going to use the Web-based compliance agent, access
to the Web agent download server is required. Use the aaa hic allowed-name command to add the name
and IP address of up to four servers to the HIC server exception list.
-> aaa hic allowed-name websrv1 ip-address 123.10.5.1 ip-mask 255.255.255.0
4 Configure a custom proxy port number. By default, the switch uses 8080 for the host proxy port
number. If a different number is used by the host device, use the aaa hic custom-proxy-port command to
configure the switch to use the host value.
-> aaa hic custom-proxy-port 8878
5 Enable the HIC feature for the switch. By default, the HIC feature is disabled for the switch. This
means that all HIC functionality is disabled. For example, if the HIC attribute of a UNP is enabled, the
HIC process is not invoked when the profile is applied if the HIC feature is not enabled for the switch. Use
the aaa hic command to enable or disable the HIC feature for the switch.
-> aaa hic enable
Note that enabling the HIC feature for the switch is not allowed if the HIC server information is not
configured. Check to see if the server configuration exists before attempting to enable this feature.
Use the show aaa hic host command to see a list of host MAC addresses the switch has learned and the
HIC status for each host. The show aaa classification-rule, show aaa classification-rule, and show aaa
hic server-failure policy commands provide information about the HIC status and configuration for the
switch.
For more information about HIC, see “Host Integrity Check (End-User Compliance)” on page 35-18.
• Pass-Through Mode (Fail Open): In Pass-through mode HIC users are moved to the HIC
PASSTHROUGH state. Users in this state are treated the same as a HIC SUCCESS and have network
access according to the policy list for their UNP, for example:
-> aaa hic server-failure mode passthrough
• Mapping Users to Temporary UNP: Mapping can be used to move all users in the HIC IN PROG-
RESS state from their current UNP to a temporary UNP while the servers are down, for example:
-> aaa hic server-failure policy user-network-profile change unp_x to unp_y
While the servers are down, all HIC new and existing HIC users in the HIC IN PROGRESS state are
temporarily moved to the unp_y. When any one of the HIC servers comes back up the HIC hosts in unp_y
is moved back to unp_x and restart the HIC validation.
• Maximum ingress and egress bandwidth, maximum default depth: Specifies maximum ingress and
egress bandwidth limiting, and maximum default depth configuration on a port. See “Port Bandwidth
Through RADIUS” on page 35-51 for more information.
To verify the UNP configuration for the switch, use the show aaa user-network-profile command. For
more information about user profiles, see “User Network Profiles (Role-Based Access)” on page 35-21.
Note the following guidelines when configuring QoS policy rules and lists:
• A default policy list exists in the switch configuration. Rules are added to this list when the rule is
created. A rule can belong to multiple policy lists. As a result, the rule remains a member a of the
default list even when it is subsequently assigned to additional lists.
• Each time a rule is assigned to a policy list, an instance of that rule is created. Each instance is allo-
cated system resources. To exclude a rule from the default policy list, use the no default-list option of
the policy rule command when the rule is created. For example:
-> policy rule r1 condition c1 action a1 no default-list
• Up to 13 policy lists (including the default list) are supported per switch. Only one policy list per UNP
is allowed, but a policy list can be associated with multiple profiles.
• If a rule is a member of multiple policy lists but one or more of these lists are disabled, the rule is still
active for those lists that are enabled.
• If the QoS status of an individual rule is disabled, then the rule is disabled for all policy lists, even if a
list to which the policy belongs is enabled.
• Policy lists are not active on the switch until the qos apply command is issued.
Use the show policy list command to display the QoS policy rule configuration for the switch.
Note.
• Bandwidth limitation applied on a port by UNP classification is not removed on user log out or aging.
User can either overwrite the bandwidth through “QoS port” command or disable 802.1x on the port to
remove the UNP applied bandwidth active on the port. Administratively bringing down the port also
removes the applied UNP configurations on the port.
• Run time modification of ingress and egress bandwidth is allowed but it does not affect the user
already authenticated, instead, it is applied on the new user authenticating under UNP. That is, if a user
modifies the UNP profile during the run time, the modified profile is not applied to those users already
authenticated with the same UNP. If any user disconnects and then authenticates again, then the
modified profile is applied to the user.
• If any parameter (egress bandwidth, ingress bandwidth, default depth) associated with a UNP profile is
modified, then the other parameters must be reconfigured, otherwise, they will be set to their default
values.
For example, consider a UNP profile with egress and ingress bandwidth as 100M, and default depth as
10M. Modify only the egress bandwidth as 200M. In this scenario, only the modified egress
bandwidth is considered, but the ingress and the default depth is set to their default values unless
specifically configured to the required values.
Note. The same bandwidth behavior applies when the user is authenticated with QoS port bandwidth, QoS
port configuration being the latest configuration.
To configure a UNP MAC address range rule, use the aaa classification-rule mac-address-range
command. For example, the following command applies the “accounting” profile to a device with a source
MAC address that falls within the specified range of MAC addresses:
-> aaa classification-rule mac-address-range 00:00:2a:33:44:01 00:00:2a:33:44:10
user-network-profile name accounting
To configure a UNP IP address rule, use the aaa classification-rule ip-address command. For example,
the following command applies the “accounting” profile to a device with the specified source IP address:
-> aaa classification-rule ip-address 10.1.1.1 user-network-profile name
accounting
Use the show aaa classification-rule command to verify the UNP mobile rule configuration for the
switch. For more information about UNP rules, see “What are UNP Mobile Rules?” on page 35-22.
2 The show aaa-device supplicant-users command displays the Access Guardian status of all suppli-
cant (802.1x) users learned on the switch:
-> show aaa-device supplicant-users
3 The show aaa-device non-supplicant-users command displays the Access Guardian status of all non-
supplicant (non-802.1x) users learned on the switch:
-> show aaa-device non-supplicant-users
4 The show aaa-device captive-portal-users command displays the Access Guardian status of all users
that attempted network access through the switch using Captive Portal web-based authentication:
-> show aaa-device captive-portal-users
For more information about the displays that result from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
• port slot/port—Logs out all users connected to the specified slot and port number. For example:
-> aaa admin-logout port 1/9
• user user_name—Logs out the user device accessing the network with the specified user name account.
For example:
-> aaa admin-logout user j_smith
• user-network-profile name profile_name—Logs out all users classified with the specified profile
name. For example:
-> aaa admin-logout user-network-profile name marketing
Logging a group of users out of the network is particularly useful if configuration changes are required to
any Access Guardian features. For example, if the Host Integrity Check (HIC) feature is globally disabled
for the switch, all User Network Profiles (UNP) with the HIC attribute enabled no longer check devices
for compliance. This could allow users that don’t comply with security requirements to access the
network. The solution:
1 Log out all users associated with the profile using the aaa admin-logout command.
2 Disable the HIC feature for the switch using the aaa hic disable command.
3 Make any necessary configuration changes to the HIC feature (for example, add a remediation server to
the HIC exception list).
4 Enable the HIC feature for the switch using the aaa hic enable command. When HIC is enabled, all
users associated with the HIC-enabled UNP are checked for compliance.
Note. The aaa admin-logout command is only available to the switch admin user. The admin account,
however, is protected from any attempts to log out the admin user.
For more information about HIC and user profiles, see “Host Integrity Check (End-User Compliance)” on
page 35-18 and “User Network Profiles (Role-Based Access)” on page 35-21.
802.1x auth-server-down Displays information about ports configured for 802.1X. Includes
Captive Portal session timeout and login retry parameter values.
show 802.1x auth-server-down Displays global information about the Access Guardian Captive Portal
configuration.
show 802.1x device Displays Access Guardian device classification policies configured for
classification policies 802.1x-enabled ports.
show aaa user-network-profile Displays the User Network Profile (UNP) configuration for the switch.
show aaa classification-rule Displays the UNP mobile classification rule configuration for the
switch.
show aaa classification-rule Displays the global Host Integrity Check (HIC) configuration for the
switch.
show aaa hic host Displays a list of the learned host MAC addresses and the HIC status for
each host.
show aaa classification-rule Displays the HIC server configuration for the switch.
show aaa hic server-failure Displays the Host Integrity Check (HIC) server exception list.
policy
show aaa classification-rule Displays the global Host Integrity Check (HIC) configuration for the
switch.
show aaa authentication 802.1x Displays information about the global 802.1X configuration on the
switch.
show aaa authentication mac Displays a list of RADIUS servers configured for MAC-based
authentication.
For more information about the displays that result from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
Note
See “Configuring User Network Profiles” on page 35-50 and Chapter 41, “Configuring 802.1X.” for
additional information on UNPs and 802.1x authentication.
RADIUS/Active Directory
Wireless
Edge Switch Controller/Authenticator
Access Points
non-supplicant
(guest) Non-Supplicant
ClearPass Guest
The OmniSwitch BYOD solution supports guest self registration, sponsored guest access and
pre-registration of guest devices using MAC and Captive Portal authentication.
• Self Registration
• An integrated external Captive Portal for guest or visitor registration.
• Redirection to a customizable guest registration Captive Portal
• Sponsored Access
• SMS and text email notification
ClearPass Onboard
The BYOD solution supports the following services for device on-boarding and device
management for guest and registered devices:
• Automatic configuration of Wireless, Wired 802.1X, VPN settings of personal and corporate devices
that are connecting to the network for the first time.
• Management of digital certificates.
• Device on-boarding system is integrated with the External Captive portal that is separate from
OmniSwitch captive portal.
• Integration with Enterprise Active Directory for authentication of employee credentials before issuing
device credentials.
• Device provisioning supported through Aruba Quick Connect or Apple OTA API.
• Quick Connect supports native supplicants on Windows Vista, XP, 7, Apple, and Android devices.
ClearPass OnGuard
ClearPass OnGuard agents perform advanced endpoint posture checking to ensure compliance is met
before the devices connect. OnGuard has the following functionalities:
• Enhanced capabilities for endpoint compliance and control.
• Supports Microsoft, Apple, and Linux operating systems.
• Anti-virus, anti-spyware, firewall checks and more using the persistent or dissolvable agent.
• Optional auto-remediation and quarantine capabilities.
• System-wide endpoint messaging, notifications and session control.
• Centrally view the Online status of all devices from the ClearPass Policy Manager platform.
RFC-3576 Attributes
ClearPass RADIUS servers and the OmniSwitch can be configured with particular attributes defined in
RFC 3576. These attributes carry specific authentication, authorization, and configuration details about
RADIUS requests to and replies from the server. This section describes the attributes specific to an
OmniSwitch BYOD solution.
1 Download the Alcatel-Lucent-Enterprise.xml file from the Service & Support website.
Import Dictionary:
Dictionary->Import
Dictionary
Reboot CPPM
Server Configuration-
>Reboot
Port Bounce
A port bounce is used to terminate a user session and discard all associated session context for
non-supplicants. This is done by disabling and re-enabling the port and clearing any authentication state
for the devices on the port.
• Port bounce is used for MAC authenticated non-supplicant users.
• On receipt of Disconnect Request or CoA message, the OmniSwitch determines if the user needs to
move or change VLANs. The switch clears the device authentication state information and waits a
configurable amount of time prior to allowing the device to re-authenticate.
• If the new UNP specifies a different VLAN ID, the port bouncing feature is enforced as per
configuration for non-supplicants.
• When a device changes VLANs and it is the only device on the port, the switch port is bounced to
ensure a clean reconnection and get the correct IP address through DHCP.
• Port bouncing is enforced only if the non-supplicant user is the only user on the port. Also
if a CoA message is received for a non-supplicant user and port bouncing is disabled globally but is
enabled on the port on which the non-supplicant user has been classified, then the port is bounced.
Pause timer
Based on the port bouncing logic, the switch clears all authentication states of the device by pausing for
some period of time. The value for the period of time is configurable through the
aaa redirect pause-timer command.
When supplicant devices are detected, the switch must clear all authentication states on the device and
pause for some period of time before redirection to the specified URLs. The pause mechanism is enforced
when the following conditions are met.
• COA message received by the switch indicates VLAN movement for the non-supplicant user and
• Port bouncing is disabled for the user port or UNP.
The pause mechanism ensures that all traffic from the user is dropped until the global pause timer expires
and the corresponding user context is removed. This process triggers re-authentication of the user.
Configuring 802.1x
802.1x supplicant and non-supplicant settings must be enabled on the ports for the authentication process
to begin. Configure the port as a mobile and 802.1X port using the vlan and 802.1x commands.
For example:
-> vlan port mobile 1/4
-> vlan port 1/4 802.1x enable
-> 802.1x 1/4 supplicant policy authentication pass block fail block
-> 802.1x 1/4 non-supplicant policy authentication pass block fail block
4 The OmniSwitch assigns the user to the UNP obtained from the ClearPass server.
2 The OmniSwitch sends a request to the ClearPass server that authenticates the device based on the
devices MAC address and the profiles and policies configured on the ClearPass server.
3 ClearPass classifies the device to a UNP and returns the UNP information to the OmniSwitch.
4 The OmniSwitch assigns the device to the UNP obtained from the ClearPass server.
2 ClearPass initially classifies the device to a temporary UNP and returns a redirection URL that allows
for guest registration or employee onboarding.
3 OmniSwitch assigns the user to the specified UNP. Since redirection is also set, all DHCP or DNS
traffic is allowed but HTTP traffic from the user is redirected towards the URL returned in the UNP.
4 The user is presented with a guest login page or an onboarding page to enter user credentials.
5 ClearPass determines the appropriate role of the user after doing registration and sends the final UNP
to the Omniswitch through a CoA request or RADIUS packet for the case of onboarding.
1 Create and associate a GRE tunnel interface on the OmniSwitch using the mdns-relay tunnel
command. For example:
-> ip interface byod_dev tunnel source 1.1.1.1 destination 1.1.1.2 protocol gre
-> mdns-relay tunnel byod_dev
Associates the ip interface "byod_dev" as the GRE tunnel from the OmniSwitch to the WLAN control-
ler.
Note. The GRE tunnel interface must be created before being associated with the mDNS tunnel relay.
Only layer 2 GRE tunnel is supported.
The GRE tunnel must also be configured on the WLAN controller. Refer the OmniAccess WLAN user
guide for additional information on configuring a WLAN controller.
2 Enable the mDNS feature on the switch by using the mdns-relay command. For example:
The mDNS feature is enabled on the OmniSwitch to support the mDNS service. A Layer 2 GRE tunnel
interface is configured from the WLAN controller to the OmniSwitch to relay the mDNS messages.
The mDNS message from the Bonjour capable wired service device is encapsulated and relayed from the
OmniSwitch to the configured WLAN controller over the GRE tunnel. The WLAN controller then relays
the mDNS messages received via the OmniSwitch GRE tunnel to the APs over the AP GRE tunnels.
Note. The WLAN controller uses a multicast optimization algorithm and forwards Bonjour response
messages to targeted user devices, instead of all devices on all APs. This limits the unnecessary flooding
of the Bonjour/mDNS traffic to improve the Wi-Fi performance.
On disabling the mDNS relay on the switch, the mDNS packets will be handled in the conventional way.
Note. For more information on the CLI command usage, refer the OmniSwitch 6250/6350/6450 CLI Refer-
ence Guide.
ClearPass
RADIUS Server RADUS/RADIUS
Proxy
“alu-cppm”
(10.255.13.250)
authentication
request authorization
response
OmniSwitch (10.255.13.26)
Create Profile:
Attributes (tab)
- Type: Radius:IETF
- Filter-ID (11)
- Value = UNP-employee
(Note: must match UNP
Profile on OmniSwitch)
Create Enforcement
Policy:
Rules (tab)
Summary
Add OmniSwitch to
ClearPass Database
Devices (tab)
Service (tab)
Configure 802.1x
Authentication
Authentication (tab)
Configure Enforcement
Enforcement (tab)
Reorder Authentication
Devices
Devices
Configure PC
Properties
Configure PC
Advanced Settings
Confirm device
Authentication
OmniSwitch
Confirm Device
Authentication
ClearPass
-> 802.1x 1/13 non-supplicant policy authentication pass default-vlan fail block
Create Authentication
Source
Authentication-Sources-
Add Authentication
Source
Create Profile:
Profile (tab)
- Name: ALU IP Phone
Profile
- Template: Aruba
RADIUS Enforcement
Attributes (tab)
- Type: Radius:IETF
- Filter-ID (11)
- Value = UNP-phone
(Note: must match UNP
Profile on OmniSwitch)
Create Enforcement
Policy:
Rules (tab)
- Type: Authentication
- Name: Source
- Operator: EQUALS
- Value: Static Mac
Database
- Profile Name: ALU IP
Phone Profile
Add MAC
Authentication Service
Service (tab)
-Type: MAC
Authentication
Authentication (tab)
- Authentication
Sources: Static MAC
Database
Enforcement (tab)
- Enforcement Policy:
ALU IP Phone
Enforcement Policy
Name- Alcatel-Lucent
Secure Access
Page name: secure-
access
Vendor Settings:
Alcatel-Lucent
Login Method: Server-
initiated
Pre-Auth Check:None
Terms: checked
Default URL:
www.google.com
Override Destination:
checked
Create Restricted
Profile:
Enforcement->Profiles
Template: RADIUS
Based Enforcement
Name: ALU Restricted
Profile
Type: RADIUS
Action: Accept
Attribute Type:
Radius:IETF, Alcatel-
Lucent-Enterprise
Attribute Name: Filter-
ID, Alcatel-Redirection-
URL
Attribute Value: UNP-
restricted, (redirect URL)
Enforcement->Profiles
Template: RADIUS
Change of Authorization
(CoA)
Name: ALU Guest CoA
Profile
RADIUS CoA Template:
Aruba-Change-User-Role
Attributes Type:
Radius:IETF
Attribute Name: Filter-
ID
Attribute Value: UNP-
guest
Add MAC
Authentication Service
Configuration->Services
Type: MAC
Authentication
Name: ALU Wired
MAC Authentication
Service
Monitor Mode:
Disabled
Service Rule Type:
Radius:IETF
Service Rule Name:
NAS-Port-Type
Service Rule
Operator:
BELONGS_TO
Service Rule Value:
Ethernet (15)
Authentication
Methods: Allow All
MAC AUTH
Enforcement Policy:
ALU Wired MAC
Enforcement Policy
Add Web
Authentication Service
Configuration->Services
Type: Web-based
Authentication
Name: ALU Wired
Captive Portal
Authentication Service
Authentication
Sources: [Guest user
Repository] [Local SQL
DB]
Enforcement Policy:
ALU Wired Captive
Portal Enforcement
Policy
Example Redirect
Example login
show aaa redirect-server Displays redirection server name and its details.
show aaa port-bounce status Displays the status of global and port specific port bounce
configuration.
show aaa redirect pause-timer Displays the configured global pause-timer value.
show byod host Displays the status of the new BYOD clients that come to the
network.
show byod status Displays the status of the new client that enters the network at the
particular port.
This chapter describes authentication servers and how they are used with the switch. The types of servers
described include Remote Authentication Dial-In User Service (RADIUS), Lightweight Directory Access
Protocol (LDAP), Terminal Access Controller Access Control System (TACACS+), and
SecurID-ACE/Server.
In This Chapter
The chapter includes information about attributes that must be configured on the servers, but it primarily
addresses configuring the switch through the Command Line Interface (CLI) to communicate with the
servers to retrieve authentication information about users.
Configuration procedures described include:
• Configuring an ACE/Server. This procedure is described in “ACE/Server” on page 36-9.
• Configuring a RADIUS Server. This procedure is described in “RADIUS Servers” on page 36-10.
• Configuring a TACACS+ Server. This procedure is described in “TACACS+ Server” on page 36-26.
• Configuring an LDAP Server. This procedure is described in “LDAP Servers” on page 36-28.
For information about using servers for authenticating users to manage the switch, see the
“Switch Security” chapter in the OmniSwitch 6250/6350/6450 Switch Management Guide.
Server Defaults
The defaults for authentication server configuration on the switch are listed in the tables in the following
sections.
* The port defaults are based on the older RADIUS standards; some servers are set up with port numbers
based on the newer standards (ports 1812 and 1813, respectively).
2 Use the aaa radius-server, aaa tacacs+-server, and/or aaa ldap-server commands to configure the
authentication servers. For example:
-> aaa radius-server rad1 host 10.10.2.1 10.10.3.5 key amadeus
-> aaa tacacs+-server tac3 host 10.10.4.2 key otna timeout 10
-> aaa ldap-server ldap2 host 10.10.3.4 dn cn=manager password tpub base c=us
Note. (Optional) Verify the server configuration by entering the show aaa server command. For example:
-> show aaa server
3 If you are using ACE/Server, switch configuration is not required; however, FTP the sdconf.rec file
from the server to the /network directory of the switch.
4 Configure authentication on the switch. This step is described in other chapters. For a quick overview
of using the configured authentication servers for 802.1X and MAC-based authentication, see Chapter 32,
“Configuring 802.1X.”. For a quick overview of using the configured authentication servers with
Authenticated Switch Access, see the OmniSwitch 6250/6350/6450 Switch Management Guide.
Server Overview
Authentication servers are sometimes referred to as AAA servers (authentication, authorization, and
accounting). These servers are used for storing information about users who want to manage the switch
(Authenticated Switch Access) and users who need access to a particular VLAN or VLANs.
RADIUS, TACACS+, LDAP, and SecurID-ACE/Server can be used for Authenticated Switch Access.
However, only RADIUS servers are supported for 802.1X Port-based Network Access Control.
The following table describes how each type of server can be used with the switch:
A RADIUS server supporting the challenge and response mechanism as defined in RADIUS RFC 2865
can access an ACE/Server for authentication purposes. The ACE/Server is then used for user
authentication, and the RADIUS server is used for user authorization.
user
The switch polls the server The switch polls the server OmniSwitch 6648
privileges
and receives login and privi- for login information, and
lege information about the OmniSwitch checks the switch for OmniSwitch
user. privilege information.
Authentication
Authenticator PAE
Server
Supplicant
authentication
login request request
authorization
PC OmniSwitch granted
RADIUS server
For more information about configuring 802.1X ports on the switch, see Chapter 32, “Configuring
802.1X.”
ACE/Server
An external ACE/Server can be used for authenticated switch access. It cannot be used for Layer 2
authentication or for policy management. Attributes are not supported on ACE/Servers. These values must
be configured on the switch through the user commands. See the “Switch Security” chapter of the OmniS-
witch 6250/6350/6450 Switch Management Guide for more information about setting up the local user
database.
Since an ACE/Server does not store or send user privilege information to the switch, user privileges for
Secur/ID logins are determined by the switch. When a user attempts to log in to the switch, the user ID
and password is sent to the ACE/Server. The server determines whether the login is valid. If the login is
valid, the user privileges must be determined. The switch checks its user database for the privileges of the
user. If the user is not in the database, the switch uses the default privilege, which is determined by the
default user account. For information about the default user account, see the “Switch Security” chapter of
the OmniSwitch 6250/6350/6450 Switch Management Guide.
Server-specific parameter configurations are not required for the switch to communicate with an attached
ACE/Server; however, FTP the sdconf.rec file from the server to the /network directory of the switch.
sdconf.rec file is required so that the switch knows the IP address of the ACE/Server. For information
about loading files on to the switch, see the OmniSwitch 6250/6350/6450 Switch Management Guide.
The ACE client in the switch is version 4.1; it does not support the replicating and locking feature of ACE
5.0, but it can be used with an ACE 5.0 server if a legacy configuration file is loaded on the server. The
legacy configuration must specify authentication to two specific servers (master and slave). See the RSA
Security ACE/Server documentation for more information.
To display information about servers configured for authentication, use the show aaa server command.
For more information about the output for this command, see the OmniSwitch 6250/6350/6450 CLI Refer-
ence Guide.
Also, clear the ACE/Server secret occasionally for misconfiguration or required changes in configuration.
When you clear the secret on the switch, it is also required to clear the secret on the ACE/Server as
described in the RSA Security ACE/Server documentation.
RADIUS Servers
RADIUS is a standard authentication and accounting protocol defined in RFC 2865 and RFC 2866. A
built-in RADIUS client is available in the switch. A RADIUS server that supports Vendor Specific Attri-
butes (VSAs) is required. The Alcatel-Lucent attributes can include VLAN information, time-of-day, or
slot/port restrictions.
Standard Attributes
The following tables list RADIUS server attributes 1–39 and 60–63, their descriptions, and whether the
Alcatel-Lucent RADIUS client in the switch supports them. Attribute 26 is for vendor-specific informa-
tion and is discussed in “Vendor-Specific Attributes for RADIUS” on page 36-13. Attributes 40–59 are
used for RADIUS accounting servers and are listed in “RADIUS Accounting Server Attributes” on
page 36-14.
Standard
Attribute Standard Attribute Notes
Number
1 User-Name Used in access-request and account-request packets.
2 User-Password Used in access-request.
3 CHAP-Password Not supported.
4 NAS-IP-Address Sent with every access-request. Specifies the switches a
user can have access to. More than one of these attributes
is allowed per user.
5 NAS-Port Virtual port number sent with access-request and
account-request packets. Slot/port information is supplied
in attribute 26 (vendor-specific).
6 Service-Type Framed-User (2) if authentication request type is:
- supplicant/802.1x authentication
- captive-portal authentication
- ASA authentication
Standard
Attribute Standard Attribute Notes
Number
6 Service-Type Framed-User (2) if authentication request type is:
- supplicant/802.1x authentication
- captive-portal authentication
- ASA authentication
Standard
Attribute Standard Attribute Notes
Number
29 Termination-Action Not supported. These attributes are used for dial-up
30 Called-Station-Id sessions; not applicable to the RADIUS client in the
32 NAS-Identifier switch.
33 Proxy-State
34 Login-LAT-Service
35 Login-LAT-Node
36 Login-LAT-Group
37 Framed-AppleTalk-Link
38 Framed-AppleTalk-Network
39 Framed-AppleTalk-Zone
60 CHAP-Challenge
61 NAS-Port-Type
62 Port-Limit
63 Login-LAT-Port
The Alcatel-Auth-Group attribute is used for Ethernet II only. If a different protocol, or more than one
protocol is required, use the Alcatel-Auth-Group-Protocol attribute instead. For example:
Alcatel-Auth-Group-Protocol 23: IP_E2 IP_SNAP
In this example, authenticated users on VLAN 23 can use Ethernet II or SNAP encapsulation.
2 On the RADIUS server, configure the functional privilege attributes with the bitmask values.
Note. For more information about configuring users on the switch, see the “Switch Security” chapter in
the OmniSwitch 6250/6350/6450 Switch Management Guide.
The following table lists the VSAs supported for RADIUS accounting servers. You can modify the attri-
butes in the radius.ini file, if necessary.
Note.
• Authentication and accounting server must be configured as RADIUS for 802.1x supplicant clients,
non-supplicant clients, ASA users, and captive portal users. For more information on configuring
authentication and accounting server, see chapter “AAA Commands” in the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
• This feature is not supported when the authentication server and accounting server is configured as
LDAP server, TACACS+ server, or ACE server.
The following table shows the default behavior of Calling-Station-ID attribute in RADIUS packets:
RADIUS
ASA users Supplicant users Non-Supplicant users Captive Portal users
Message
Access- Not applicable Access request is sent Access request is sent Not applicable
Request with Calling-Station- with Calling-Station-
ID (MAC address of ID (MAC address of
the supplicant user) the non-supplicant
connecting to the user) connecting to the
OmniSwitch. OmniSwitch.
Accounting- Account request Accounting request is Accounting request is Access request is sent
Request message is sent sent with sent with with Calling-Station-
with Calling-Station-ID Calling-Station-ID ID (IP address of the
Calling-Station- (MAC address of the (MAC address of the captive portal user)
ID (IP address of supplicant user) con- non-supplicant user) connecting to the
the ASA user/ necting to the OmniS- connecting to the OmniSwitch.
host) connecting witch. OmniSwitch.
to the OmniS-
witch.
To specify that the MAC address format and other IDs sent to RADIUS server will be in uppercase, use
the command as follows:
-> aaa radius-server "Server1" mac-address-format-status enable
mac-address-format uppercase
Note.
• Authentication and accounting server must be configured as RADIUS for 802.1x supplicant clients,
non-supplicant clients, and ASA users prior to NAS port configuration. For more information on
configuring authentication and accounting server, see chapter “AAA Commands” in the OmniSwitch
6250/6350/6450 CLI Reference Guide.
• This feature is not supported when the authentication server and accounting server is configured as
LDAP server, TACACS+ server, or ACE server.
To configure NAS port configuration for the RADIUS, use the aaa radius-server command. For
example, the following command configures NAS port ID as ‘enable’ with NAS port type ‘async’:
-> aaa radius-server pubs2 host 1.1.1.1 key 762fefc9f0a32227 nas-port-id enable
nas-port-type async
All the users that get authenticated through the above RADIUS server uses the specified NAS port attri-
butes for authentication and accounting.
Note. NAS port and NAS port ID configurations are mutually exclusive. Either NAS port or NAS port ID
can be configured at a time for the RADIUS server.
Use show aaa server and show configuration snapshot aaa commands to view the NAS port, NAS port
ID, and NAS port type attributes configured for the RADIUS server. However, NAS port configuration is
not displayed when these attributes are configured with default value.
The following table shows the behavior of the NAS port configuration for supplicant or non-supplicant
clients, and ASA users.
NAS port ID will be ‘disable’ and will NAS port ID will be ‘disable’ and will
not be sent in the access request/ not be sent in the access request/
accounting request packet. accounting request packet.
When NAS port is Authenticating port is converted to NAS port attribute is sent as 0.
‘ifindex’ ifIndex (slot*1000+port) and sent using
the NAS port attribute.
NAS port attribute will not be applicable NAS port attribute will not be
and will not be sent in the access request/ applicable and will not be sent in the
accounting request packet. access request/accounting request
packet.
When NAS port ID Access request/accounting request Access request/accounting request
is ‘disable’ packet is sent with NAS port value as 77. packet is sent with NAS port value as 77.
NAS port ID will be ‘disable’ and will NAS port ID will be ‘disable’ and will
not be sent in the access request/account- not be sent in the access request/
ing request packet. accounting request packet.
Note.
• Authentication server and accounting server must be configured as RADIUS prior to unique session ID
configuration. For more information on configuring authentication and accounting server for 802.1x
supplicant clients, 802.1x non-supplicant clients, captive portal users, and ASA users, see chapter
“AAA Commands” in the OmniSwitch 6250/6350/6450 CLI Reference Guide.
• This feature is not supported when the authentication and accounting server is configured as LDAP
server, TACACS+ server, or ACE server.
• This feature is not supported for local accounting.
Note. When non-supplicant gets passed without authentication, the accounting session ID is generated
with the combination of MAC address and 0.
For example,
-> 802.1x 2/5 non-supplicant policy pass vlan 10 block
For management sessions (FTP, telnet, HTTP, console, HTTPS, and SSH):
• When accounting is enabled, accounting session ID is generated with the combination of virtual MAC
address and time stamp (time stamp is based on the user name and the session number), and passed to
the RADIUS server.
• When accounting is disabled, virtual MAC address is generated as the accounting session ID.
To enable session ID for RADIUS accounting, use the aaa radius-server command as shown. By default,
accounting session ID is disabled.
-> aaa radius-server pubs2 host 1.1.1.1 key 762fefc9f0a32227 unique-acct
session-id enable
When a new session is established, a "START" packet is sent and a session ID is generated. For example,
if MAC address is 00:00:00:00:00:01, then session ID will be 000000000001-132434 where 132434 is
time stamp for supplicant or non-supplicant client. For management sessions, the session ID will be in
Virtual_mac_address-TimeStamp format.
To disable session ID for RADIUS accounting, use the disable option as shown:
-> aaa radius-server pubs2 host 1.1.1.1 key 762fefc9f0a32227 unique-acct-
session-id disable
When a user logs out or a session is disabled, an exit event is triggered and a "STOP" packet is sent. For
example, if MAC address is 00:00:00:00:00:01, then session ID will be 000000000001. For management
sessions, the session ID will be in Virtual_mac_address format.
Use show configuration snapshot aaa and show aaa server commands to view the unique session ID
configuration.
When creating a server, at least one-host name or IP address (specified by the host keyword) is required as
well as the shared secret (specified by the key keyword).
In this example, the server name is rad1, the host address is 10.10.2.1, the backup address is 10.10.3.5,
and the shared secret is amadeus. The shared secret must be configured the same as on the server.
-> aaa radius-server rad1 host 10.10.2.1 10.10.3.5 key amadeus
To modify a RADIUS server, enter the server name and the desired parameter to be modified.
-> aaa radius-server rad1 key mozart
If you are modifying the server and have entered the aaa radius-server command to create or modify the
server, you can use command prefix recognition. For example:
-> aaa radius-server rad1 retransmit 5
-> timeout 5
For information about server defaults, see “Server Defaults” on page 36-3.
To remove a RADIUS server, use the no form of the command.
-> no aaa radius-server rad1
Note. This command is deprecated and replaced with aaa radius-health-check command. Refer section
“Configuring RADIUS Health Check” on page 36-24.
This feature provides the functionality to test the reachability of RADIUS server from the AOS Switch by
enabling server polling, which polls all the configured RADIUS servers periodically to obtain the server
status (Up/Down).
To enable polling of the RADIUS server, use 802.1x server-polling enable command. By default,
RADIUS server polling is disabled.
-> 802.1x server-polling enable
To disable polling of the RADIUS server, use 802.1x server-polling disable command.
-> 802.1x server-polling disable
show aaa server command displays the reachability status of different RADIUS servers configured on the
switch.
Note. You need to configure “port bounce”, to bounce the port for non-supplicant re-authentication, when
auth-server comes up.
To configure the RADIUS Health check for a RADIUS server, use aaa radius-health-check command.
It is recommended that Radius Health Check is enabled on all the radius servers configured for 802.1x and
MAC-authentication in the system. This improves the time in which the 802.1x users are authenticated.
For example, the following command enables the radius health check for the radius server rad1 and polls
the server every 700 sec with the username “admin” and password “Password1”. Since the failover param-
eter is enabled, it takes action if the authentication server status is changed from DOWN to UP.
-> aaa radius-health-check rad1 status enable polling-interval 700 username
admin password Password1 failover enable
Note. When the RADIUS Health check determines the auth-server has changed status from down to up,
then only the data clients that are in auth-server down UNP list are re-authenticated when failover parame-
ter is enabled. The auth-server down voice clients will remain in the auth-server down UNP list in order to
not disturb the ongoing sessions.
The maximum time before which the failover mechanism gets initiated from the time the server is up will
be 20 seconds more than the configured polling interval. Since the polling frequency for a radius server
may have lag of 20 seconds from the polling interval.
You can verify the radius health check configuration information of radius servers by using the show aaa
radius-health-check config command.
TACACS+ Server
Terminal Access Controller Access Control System (TACACS+) is a standard authentication and
accounting protocol defined in RFC 1321 that employs TCP for reliable transport. A built-in TACACS+
client is available in the switch. A TACACS+ server allows access control for routers, network access
servers, and other network devices through one or more centralized servers. The protocol also allows
separate authentication, authorization, and accounting services. By allowing arbitrary length and content
authentication exchanges, it allows clients to use any authentication mechanism.
The TACACS+ client offers the ability to configure multiple TACACS+ servers. This can be done by the
user. When the primary server fails, the client tries the subsequent servers. Multiple server configurations
are applicable only for backup and not for server chaining.
In the TACACS+ protocol, the client queries the TACACS+ server by sending TACACS+ requests. The
server responds with reply packets indicating the status of the request.
• Authentication. TACACS+ protocol provides authentication between the client and the server. It also
ensures confidentiality as all the exchanges are encrypted. The protocol supports fixed passwords,
one-time passwords, and challenge-response queries. Authentication is not a mandatory feature, and it
can be enabled without authorization and accounting. During authentication if a user is not found on
the primary TACACS+ server, the authentication fails. The client does not try to authenticate with the
other servers in a multiple server configuration. If the authentication succeeds, then authorization is
performed.
• Authorization. Enabling authorization determines if the user has the authority to execute a specified
command. TACACS+ authorization cannot be enabled independently. The TACACS+ authorization is
enabled automatically when the TACACS+ authentication is enabled. However, the implementation of
authorization in TACACS+ server is based on the status of aaa tacacs command-authorization
command. If the command is enabled, the authorization of every command executed on the switch is
command based. CLI commands executed on the switch are sent to the TACACS+ server for authori-
zation, along with-mode of operation (read or read-write). After authorization, the server sends the
response message to the TACACS+ client. If the command is disabled, then in the TACACS+ server
the authorization is based on partition-management family, that is, partition-management family is sent
for authorization.
When an user configures or modifies a TACACS+ server for Authenticated Switch Access using aaa
tacacs+-server command, authorization is passed on to the AAA task for authorization with a server-
wait-time of only 5 seconds. However, if the TACACS sever timeout is configured to a value greater
than 5 seconds and multiple servers are configured, then the TACACS server takes longer time than 5
seconds to respond to authorization request. In such scenario, The CLI task is timed out on the
TACACS+ server and a positive response for the previous authorization request is assigned to the next
authorization request. Thus increasing the risk of authorizing server access to an unauthorized user. To
avoid such unauthorized access, user can configure the server-wait-time of TACACS+ server during
command authorization process using aaa tacacs server-wait-time.
• Accounting. The process of recording what the user is attempting to do or what the user has done is
accounting. The TACACS+ accounting must be enabled on the switches for accounting to succeed.
Accounting can be enabled irrespective of authentication and authorization. TACACS+ supports three
types of accounting:
Start Records—Indicates the service is about to begin.
Stop Records—Indicates the services has terminated.
Update Records—Indicates the services are still being performed.
When creating a server, at least one-host name or IP address (specified by the host keyword) is required as
well as the shared secret (specified by the key keyword).
In this example, the server name is tac1, the host address is 10.10.5.2, the backup address is 10.10.5.5, and
the shared secret is otna. The shared secret must be configured the same as on the server.
-> aaa tacacs+-server tac1 host 10.10.5.2 10.10.5.5 key otna
To modify a TACACS+ server, enter the server name and the desired parameter to be modified.
-> aaa tacacs+-server tac1 key tnemelc
If you are modifying the server and have entered the aaa tacacs+-server command to create or modify the
server, you can use command prefix recognition. For example:
-> aaa tacacs+-server tac1 timeout 5
For information about server defaults, see “Server Defaults” on page 36-3.
To remove a TACACS+ server, use the no form of the command:
-> no aaa tacacs+-server tac1
LDAP Servers
Lightweight Directory Access Protocol (LDAP) is a standard directory server protocol. The LDAP client
in the switch is based on several RFCs: 1798, 2247, 2251, 2252, 2253, 2254, 2255, and 2256. The
protocol was developed as a way to use directory services over TCP/IP and to simplify the directory access
protocol (DAP) defined as part of the Open Systems Interconnection (OSI) effort. Originally, it was a front
end for X.500 DAP.
The protocol synchronizes and governs the communications between the LDAP client and the LDAP
server. The protocol also dictates how its databases of information, which are normally stored in
hierarchical form, are searched from the root directory down to distinct entries.
In addition, LDAP has its own format that permits LDAP-enabled Web browsers to perform directory
searches over TCP/IP.
2 Copy the relevant schema LDIF files from the Alcatel-Lucent software CD to the configuration
directory on the server. (Each server type has a command line tool or a GUI tool for importing LDIF files.)
Database LDIF files can also be copied and used as templates. The schema files and the database files are
specific to the server type. The files available on the Alcatel-Lucent software CD include the following:
aaa_schema.microsoft.ldif
aaa_schema.netscape.ldif
aaa_schema.novell.ldif
aaa_schema.openldap.schema
aaa_schema.sun.ldif
aaa_database.microsoft.ldif
aaa_database.netscape.ldif
aaa_database.novell.ldif
aaa_database.openldap.ldif
aaa_database.sun.ldif
3 After the server files have been imported, restart the server.
Information in the server files must match information configured on the switch through the
aaa ldap-server command. For example, the port number configured on the server must be the same as
the port number configured on the switch. See “Configuring the LDAP Authentication Client” on
page 36-39 for information about using this command.
entries definition
dn: <distinguished name> Defines the DN (required).
objectClass: top Defines top object class (at least one is required). Object
class defines the list of attributes required and allowed in
directory server entries.
objectClass: organizationalUnit Specifies that organizational unit must be part of the object
class.
ou: <organizationalUnit name> Defines the name of the organizational unit.
<list of attritbutes> Defines the list of optional entry attributes.
Common Entries
The most common LDIF entries describe people in companies and organizations. The structure for such an
entry looks like the following:
dn: <distinguished name>
objectClass: top
objectClass: person
objectClass: organizational Person
cn: <common name>
sn: <surname>
<list of optional attributes>
This is how the entry would appear with actual data in it.
dn: uid=yname, ou=people, o=yourcompany
objectClass: top
objectClass: person
objectClass: organizational Person
cn: your name
sn: last name
givenname: first name
uid: yname
ou: people
description:
<list of optional attributes>
...
Directory Entries
Directory entries are used to store data in directory servers. LDAP–enabled directory entries contain
information about an object (person, place, or thing) in the form of a Distinguished Name (DN) that must
be created in compliance with the LDAP protocol naming conventions.
Distinguished names are constructed from Relative Distinguished Names (RDNs). These related entries
share only one-attribute value with a DN. RDNs are the components of DNs, and DNs are string
representations of entry names in the directory servers.
Distinguished names consist of descriptive information about the entries. Generally, DNs include full
names of individuals in a network, their E-mail addresses, TCP/IP addresses, and related attributes such as
department name to distinguish the DNs. Entries include one or more object classes, and often a number of
attributes that are defined by values.
Object classes define all required and optional attributes (a set of object classes is referred to as a
“schema”). As a minimum, every entry must include the DN and one defined object class, like the name of
an organization. Attributes required by a particular object class must also be defined. Some commonly
used attributes that comprise a DN include the following:
Country (c), State or Province (st), Locality (l),
Organization (o), Organization Unit (ou),
and Common Name (cn)
Although each attribute would necessarily have its own values, the attribute syntax determines the values
that are allowed for a particular attribute. For example, (c=US), where country is the attribute and US is
the value. Extra consideration for attribute language codes is necessary if entries are made in more than
one language.
Entries are based on the physical locations and established policies in a Directory Information Tree (DIT);
the DN locates an entry in the hierarchy of the tree. Alias entries pointing to other entries can also be used
to circumvent the hierarchy during searches for entries.
Once a directory is set up, DN attributes must thereafter be specified in the same order to keep the
directory paths consistent. DN attributes are separated by commas as shown in this example:
cn=your name, ou=your function, o= your company, c=US
As there are other conventions used, refer to the appropriate RFC specification for further details.
In addition to managing attributes in directory entries, LDAP makes the descriptive information stored in
the entries accessible to other applications. The general structure of entries in a directory tree is shown in
the following illustration. It also includes example entries at various branches in the tree.
ROOT
dn=c=US
c=Canada c=US
dn=o=your company,c=US
Directory Searches
DNs are always the starting point for searches unless indicated otherwise in the directory schema.
Searches involve the use of various criteria including scopes and filters which must be predefined, and
utility routines, such as Sort. Searches must be limited in scope to specific durations and areas of the
directory. Some other parameters used to control LDAP searches include the size of the search and
whether to include attributes associated with name searches.
Base objects and scopes are specified in the searches, and indicate where to search in the directory. Filters
are used to specify entries to select in a given scope. The filters are used to test the existence of object
class attributes, and enable LDAP to emulate a “read” of entry listings during the searches. All search
preferences are implemented by means of a filter in the search. Filtered searches are based on some
component of the DN.
Directory Modifications
Modifications to directory entries contain changes to DN entry attribute values, and are submitted to the
server by an LDAP client application. The LDAP-enabled directory server uses the DNs to find the entries
to either add or modify their attribute values.
Attributes are automatically created for requests to add values if the attributes are not already contained in
the entries.
All attributes are automatically deleted when requests to delete the last value of an attribute are submitted.
Attributes can also be deleted by specifying delete value operations without attaching any value.
Modified attribute values are replaced with other given values by submitting replace requests to the server,
which then translates and performs the requests.
LDAP URLs use the percent symbol to represent commas in the DN. The following table shows the basic
components of LDAP URLs.
components description
<ldap> Specifies TCP/IP connection for LDAP protocol. (The <ldaps>
prefix specifies SSL connection for LDAP protocol.)
<hostname> Host name of directory server or computer, or its IP address (in dot-
ted decimal format).
<port> TCP/IP port number for directory server. If using TCP/IP and
default port number (389), port need not be specified in the URL.
SSL port number for directory server (default is 636).
<base_dn> DN of directory entry where search is initiated.
<attributes> Attributes to be returned for entry search results. All attributes are
returned if search attributes are not specified.
<scope> Different results are retrieved depending on the scopes associated
with entry searches.
“base” search: retrieves information about distinguished name as
specified in URL. This is a <base_dn> search. Base searches are
assumed when the scope is not designated.
“one” (one-level) search: retrieves information about entries one
level under distinguished name (<base_dn> as specified in the
URL, excluding the base entry.
“sub” (subtree) search: retrieves information about entries from all
levels under the distinguished name (<base_dn>) as specified in
the URL, including the base entry.
<filter> Search filters are applied to entries within specified search scopes.
Default filter objectClass=* is used when filters are not designated.
(Automatic search filtering not yet available.)
Note. Configure server schema extensions before the aaa ldap-server command is configured.
attribute description
bop-asa-func-priv-read-1 Read privileges for the user.
bop-asa-func-priv-read-2 Read privileges for the user.
bop-asa-func-priv-write-1 Write privileges for the user.
bop-asa-func-priv-write-2 Write privileges for the user.
bop-asa-allowed-access Whether the user has access to configure the switch.
bop-asa-snmp-level-security Whether the user can have SNMP access, and the
type of SNMP protocol used.
bop-shakey A key computed from the user password with the
alp2key tool.
bop-md5key A key computed from the user password with the
alp2key tool.
allowedtime The periods of time the user is allowed to log in to the
switch.
switchgroups The VLAN ID and protocol (IP_E2, IP_SNAP).
For more information about configuring users on the switch, see the Switch Security chapter of the
OmniSwitch 6250/6350/6450 Switch Management Guide.
1 Use the alp2key application to calculate the authentication key from the password of the user. The
switch automatically computes the authentication key, but for security reasons the key is never displayed
in the CLI.
2 Cut and paste the key to the relevant attribute on the server.
An example using the alp2key tool to compute the SHA and MD5 keys for mypassword:
ors40595{}128: alp2key mypassword
bop-shakey: 0xb1112e3472ae836ec2b4d3f453023b9853d9d07c
bop-md5key: 0xeb3ad6ba929441a0ff64083d021c07f1
ors40595{}129:
Note. The bop-shakey and bop-md5key values must be recomputed and copied to the server any time a
user’s password is changed.
AccountStartTime
User account start times are tracked in the AccountStartTime attribute of the user’s directory entry that
keeps the time stamp and accounting information of user logins. The following fields (separated by
carriage returns “|”) are contained in the Login log. Some fields are only used for Layer 2 Authentication.
Fields Included For Any Type of Authentication
• User account ID or user name client entered to log in: variable length digits.
• Time Stamp (YYYYMMDDHHMMSS (YYYY:year, MM:month, DD:day, HH:hour, MM:minute,
SS:second)
• Switch serial number: Alcatel.BOP.<switch name>.<MAC address>
• Client IP address: variable length digits.
AccountStopTime
User account stop times are tracked in the AccountStopTime attribute that keeps the time stamp and
accounting information of successful user logouts. The same fields as above (separated by carriage returns
“|”) are contained in the Logout log. A different carriage return such as the # sign can be used in some
situations. Additionally, these fields are included but apply only to the Logout log:
Fields For Any Type of Authentication
• Log-out reason code, for example LOGOFF(18) or DISCONNECTED BY ADMIN(19)
• User account ID or user name client entered to log in: variable length digits.
Fields For Layer 2 Authentication Only
• Number of bytes received on the port during the client session from login to logout: variable length
digits.
• Number of bytes sent on the port during the client session from login to logout: variable length digits.
• Number of frames received on the port during the client session from login to logout: variable length
digits.
• Number of frames sent on the port during the client session from login to logout: variable length digits.
AccountFailTime
The AccountFailTime attribute log records the time stamp and accounting information of unsuccessful
user logins. The same fields in the Login Log—which are also part of the Logout log (separated by
carriage returns “|”)—are contained in the Login Fail log. A different carriage return such as the # sign can
be used in some situations. Additionally, these fields are included but apply only to the Login Fail log.
• User account ID or user name client entered to log in: variable length digits.
• Log in fail error code: nn. For error code descriptions refer to the vendor-specific listing for the
specific directory server in use.
• Log out reason code, for example PASSWORD EXPIRED(7) or AUTHENTICATION FAILURE(21).
Dynamic Logging
Dynamic logging can be performed by an LDAP-enabled directory server if an LDAP server is
configured first in the list of authentication servers configured through the aaa accounting session
command. Any other servers configured are used for accounting (storing history records) only. For
example:
-> aaa accounting session ldap2 rad1 rad2
In this example, server ldap2 are used for dynamic logging, and servers rad1 and rad2 will be used for
accounting.
If you specify a RADIUS server first, all of the servers specified are used for recording history records
(not logging). For example:
-> aaa accounting session rad1 ldap2
In this example, both the rad1 and ldap2 servers are used for history only. Dynamic logging does not take
place on the LDAP server.
Dynamic entries are stored in the LDAP-enabled directory server database from the time the user
successfully logs in until the user logs out. The entries are removed when the user logs out.
• Entries are associated with the switch the user is logged into.
• Each dynamic entry contains information about the user connection. The related attribute in the server
is bop-logged users.
A specific object class called alcatelBopSwitchLogging contains three attributes as follows:
Attribute Description
bop-basemac MAC range, which uniquely identifies the switch.
bop-switchname Host name of the switch.
bop-loggedusers Current activity records for every user logged on
to the switch identified by bop-basemac.
Each switch that is connected to the LDAP-enabled directory server has a DN starting with
bop-basemac-xxxxx, ou=bop-logging. If the organizational unit ou=bop.logging exists somewhere in the
tree under searchbase, logging records are written on the server. See the server manufacturer
documentation for more information about setting up the server.
For example:
“ASA 0 : CONSOLE IP 65.97.233.108 Jones”
Note. Configure the server with the appropriate schema before the aaa ldap-server command is
configured.
The keywords for the aaa ldap-server command are listed here:
In this example, the switch will be able to communicate with an LDAP server (called ldap2) that has an IP
address of 10.10.3.4, a domain name of cn=manager, a password of tpub, and a searchbase of c=us. These
parameters must match the same parameters configured on the server itself.
Note. The distinguished name must be different from the searchbase name.
In this example, an existing LDAP server is modified with a different password, and then the timeout is
modified on a separate line. These two-command lines are equivalent to:
-> aaa ldap-server ldap2 password my_pass timeout 4
The switch automatically sets the port number to 636 when SSL is enabled. The 636 port number is
typically used on LDAP servers for SSL. The port number on the switch must match the port number
configured on the server. If the port number on the server is different from the default, use the
aaa ldap-server command with the port keyword to configure the port number. For example, if the server
port number is 635, enter the following:
-> aaa ldap-server ldap2 port 635
The switch will now be able to communicate with the server on port 635.
To remove SSL from the server, use no with the ssl keyword. For example:
-> aaa ldap-server ldap2 no ssl
show aaa server Displays information about a particular AAA server or AAA servers.
An example of the output for this command is given in “Quick Steps For Configuring Authentication
Servers” on page 36-5. For more information about the output of this command, see the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
Physical devices attached to a LAN port on the switch through a point-to-point LAN connection is authen-
ticated through the switch through port-based network access control. This control is available through the
IEEE 802.1X standard implemented on the switch.
In This Chapter
This chapter describes 802.1X ports used for port-based access control and how to configure them through
the Command Line Interface (CLI). CLI commands are used in the configuration examples; for more
details about the syntax of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
This chapter provides an overview of 802.1X and includes the following information:
• “Setting Up Port-Based Network Access Control” on page 37-9
• “Enabling 802.1X on Ports” on page 37-9
• “Setting 802.1X Switch Parameters” on page 37-9
• “Configuring 802.1X Port Parameters” on page 37-10
• “Verifying the 802.1X Port Configuration” on page 37-13
802.1X Specifications
RFCs Supported RFC 2284–PPP Extensible Authentication Protocol (EAP)
RFC 2865–Remote Authentication Dial In User Service
(RADIUS)
RFC 2866–RADIUS Accounting
RFC 2867–RADIUS Accounting Modifications for Tun-
nel Protocol Support
RFC 2868–RADIUS Attributes for Tunnel Protocol Sup-
port
RFC 2869–RADIUS Extensions
IEEE Standards Supported IEEE 802.1X-2001–Standard for Port-based Network
Access Control
802.1X RADIUS Usage Guidelines
Platforms Supported OmniSwitch 6250, 6350, 6450
Maximum number of 802.1x users per NI 256 (supplicants and non-supplicants)
module.
802.1X Defaults
The following table lists the defaults for 802.1X port configuration through the 802.1x command and the
relevant command keywords:
The port is set up automatically with 802.1X defaults. See “802.1X Defaults” on page 37-3 for informa-
tion about the defaults. For more information about vlan port commands, see Chapter 6, “Assigning Ports
to VLANs.”
See Chapter 31, “Managing Authentication Servers,” for more information about configuring RADIUS
authentication servers for 802.1X authentication.
3 Associate the RADIUS server (or servers) with authentication for 802.1X ports:
4 (Optional) Associate the server (or servers) to be used for accounting (logging) 802.1X sessions. For
example:
-> aaa accounting 802.1x rad2 ldap3 local
5 (Optional) Configure port-access control parameters for the 802.1X port using the 802.1x command:
6 (Optional) Configure the number of times supplicant devices are polled for identification using the
802.1x supp-polling retry command:
-> 802.1x 3/1 supp-polling retry 10
Note. Verify the 802.1X port configuration using the 802.1x command:
-> show 802.1x 1/13
802.1x configuration for slot 1 port 13:
direction = both,
operational directions = both,
port-control = auto,
quiet-period (sec) = 60,
tx-period (sec) = 30,
supp-timeout (sec) = 30,
server-timeout (sec) = 30,
max-req = 2,
re-authperiod (sec) = 3600,
reauthentication = no
Supplicant polling retry count = 2
Optional. To display the number of 802.1x users on the switch, use the show 802.1x users command:
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for information about the fields in this display.
802.1X Overview
The 802.1X standard defines port-based network access controls, and provides the structure for authenti-
cating physical devices attached to a LAN. It uses the Extensible Authentication Protocol (EAP).
There are three components for 802.1X:
• The Supplicant—This is the device connected to the switch that supports the 802.1x protocol. The
device may be connected directly to the switch or through a point-to-point LAN segment. Typically the
supplicant is a PC or laptop.
• The Authenticator Port Access Entity (PAE)—This entity requires authentication from the suppli-
cant. The authenticator is connected to the supplicant directly or through a point-to-point LAN
segment. The OmniSwitch acts as the authenticator.
• The Authentication Server—This component provides the authentication service and verifies the
credentials (username, password, challenge, and so on) of the supplicant. On the OmniSwitch, only
RADIUS servers are currently supported for 802.1X authentication.
Authentication
Authenticator PAE
Server
Supplicant
authentication
login request request
authorization
PC OmniSwitch granted
RADIUS server
802.1X Components
A device that does not use the 802.1x protocol for authentication is referred to as a non-supplicant. The
Access Guardian feature provides configurable device classification policies to authenticate access of both
supplicant and non-supplicant devices on 802.1x ports. See Chapter 30, “Configuring Access Guardian,”
for more information.
Supplicant Classification
When an EAP frame or an unknown source data frame is received from a supplicant, the switch sends an
EAP packet to request the identity of the supplicant. The supplicant then sends the information (an EAP
response), which is validated on an authentication server set up for authenticating 802.1X ports. The server
determines whether additional information (a challenge, or secret) is required from the supplicant.
After the supplicant is successfully authenticated, the MAC address of the supplicant is learned in the
appropriate VLAN depending on the following conditions:
• If the authentication server returned a VLAN ID, then the supplicant is assigned to that VLAN. All
subsequent traffic from the supplicant is then forwarded on that VLAN.
• If the authentication server does not return a VLAN ID, then the supplicant is classified according to
any device classification policies that are configured for the port. See Chapter 30, “Configuring Access
Guardian,” for more information.
• If the authentication server does not return a VLAN ID and there are no user-configured device classi-
fication policies for the port, then by default Group Mobility is used to classify the supplicant. If Group
Mobility is unable to classify the supplicant, then the supplicant is assigned to the default VLAN for
the 802.1X port.
• If the authentication server returns a VLAN ID that does not exist or authentication fails, the suppli-
cant is blocked.
The multiple supplicants can be authenticated on a given 802.1X port. Each supplicant MAC address
received on the port is authenticated and learned separately. Only those that authenticate successfully are
allowed on the port, as described in the previous conditions. Those that fail authentication are blocked on
the 802.1X port.
The global configuration of this feature is controlled by the aaa authentication 802.1x command. This
command enables 802.1X for the switch and identifies the primary and backup authentication servers. See
“Setting 802.1X Switch Parameters” on page 37-9 for more information about configuring this command.
Using the 802.1x command, an administrator may force an 802.1X port to always accept any frames on
the port (therefore not requiring a device to authenticate on the port first) or an administrator may force the
port to never accept any frames on the port. See “Configuring the Port Authorization” on page 37-10.
Re-authentication
After a supplicant has successfully authenticated through an 802.1X port, the switch may be configured to
periodically re-authenticate the supplicant (re-authentication is disabled by default). In addition, the
supplicant may be manually re-authenticated (see “Re-authenticating an 802.1X Port” on page 37-11).
The re-authentication process is transparent to a user connected to the authorized port. The process is used
for security and allows the authenticator (the OmniSwitch) to maintain the 802.1X connection.
Note. If the MAC address of the supplicant has aged out during the authentication session, the 802.1X
software in the switch alerts the source learning software in the switch to re-learn the address.
802.1X ports may also be initialized if there a problem on the port. Initializing a port drops connectivity to
the port and requires the port to be re-authenticated. See “Initializing an 802.1X Port” on page 37-12.
802.1X Accounting
If servers are set up for 802.1X accounting the 802.1X authentication sessions may be logged. Accounting
may also be done through the local Switch Logging feature. For information about setting up accounting
for 802.1X, see “Configuring Accounting for 802.1X” on page 37-12.
In this example, the rad1 server is used for authenticating 802.1X ports. If rad1 becomes unavailable, the
switch uses rad2 for 802.1X authentication. When this command is used, 802.1X is automatically enabled
for the switch.
Note. The same RADIUS servers can be used for 802.1x (supplicant) and MAC (non-supplicant) authenti-
cation. Using different servers for each type of authentication is allowed but not required.
For more information about using MAC authentication and classifying non-supplicant devices, see
Chapter 30, “Configuring Access Guardian.”
The vlan port 802.1x command enables 802.1X on port 1 of slot 3. The port is set up with defaults listed
in “802.1X Defaults” on page 37-3.
To disable 802.1X on a port, use the disable option with vlan port 802.1x command. For more informa-
tion about vlan port commands, See Chapter 6, “Assigning Ports to VLANs.”
In this example, the port control direction is set to incoming traffic only on port 1 of slot 3.
The type of port control (or authorization) is configured with the port-control parameter described in the
next section.
In this example, the port control on port 1 of slot 3 is always authorized for any traffic.
The auto option configures the port to be open for traffic when a device successfully completes an 802.1X
authentication exchange with the switch.
This command changes the quiet timeout to 50 sec; the transmit timeout to 25 sec; and the user timeout to
25 sec.
Note. The authentication server timeout may also be configured (with the server-timeout keyword) but
the value is always superseded by the value set for the RADIUS server through the aaa radius-server
command.
In this example, the maximum number of times a device is polled is set to 10. If no EAP frames are
received, the device is considered a non-supplicant, and any non-supplicant classification policies config-
ured for the port are applied to the device.
To bypass 802.1x authentication and classify supplicants connected to the port as non-supplicants, set the
number of polling retries to zero:
-> 802.1x 3/1 supp-polling retry 0
Note. Setting the number of polling retries to zero turns off 802.1x authentication for the port; all devices
(including supplicants) are then classified as non-supplicants. As a result, non-supplicant policies that use
MAC-based authentication are now applicable to supplicant devices and not only non-supplicant devices.
The re-authperiod parameter may be used to configure the time that must expire before automatic re-
authentication attempts. For example:
-> 802.1x 3/1 reauthentication re-authperiod 25
In this example, automatic re-authentication is enabled, and re-authentication takes place on the port every
25 sec.
To manually re-authenticate a port, use the 802.1x re-authenticate command. For example:
-> 802.1x re-authentication 3/1
This command drops connectivity on port 1 of slot 3. The switch sends out a Request Identity message and
restores connectivity when the port is successfully re-authenticated.
In this example, the RADIUS server rad1 is used for accounting. If rad1 becomes unavailable, the local
Switch Logging function in the switch will log 802.1X sessions. For more information about Switch
Logging, see Chapter 39, “Using Switch Logging.”
This delays the 802.1X authentication process by 300 secs during the switch reboot.
Use the show 802.1x auth-server-down command to view the configured delay learning interval.
show 802.1x users Displays a list of all users (supplicants) for one or more 802.1X ports.
show 802.1x non-supplicant Displays a list of all non-802.1x users (non-supplicants) learned on one
or more 802.1x ports.
show 802.1x statistics Displays statistics about 802.1X ports.
show 802.1x device Displays Access Guardian 802.1x device classification policies config-
classification policies ured for 802.1x ports.
show aaa authentication 802.1x Displays information about the global 802.1X configuration on the
switch.
show aaa accounting 802.1x Displays information about accounting servers configured for 802.1X
port-based network access control.
show aaa authentication mac Displays a list of RADIUS servers configured for MAC-based authenti-
cation.
For more information about the displays that result from these commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
Quality of Service (QoS) policies that are configured through Alcatel’s PolicyView network management
application are stored on a Lightweight Directory Access Protocol (LDAP) server. PolicyView is an
OmniVista application that runs on an attached workstation.
In This Chapter
This chapter describes how LDAP directory servers are used with the switch for policy management.
There is no required configuration on the switch. When policies are created on the directory server through
PolicyView, the PolicyView application automatically configures the switch to communicate with the
server. This chapter includes information about modifying configuration parameters through the
Command Line Interface (CLI) if manual reconfiguration is necessary. For more details about the syntax
of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Throughout this chapter the term policy server is used to refer to LDAP directory servers used to store
policies. Procedures described in this chapter include:
• “Installing the LDAP Policy Server” on page 38-3
• “Modifying Policy Servers” on page 38-4
• “Verifying the Policy Server Configuration” on page 38-7
Note. The switch has separate mechanisms for managing QoS policies stored on an LDAP server and QoS
policies configured directly on the switch. For more information about creating policies directly on the
switch, see Chapter 39, “Configuring QoS.”
Information about installing the LDAP policy server is included in this chapter. Consult the server manu-
facturer’s documentation for detailed information about configuring the server.
OmniSwitch
PolicyView workstation
IP traffic;
voice and video
traffic
LDAP server
See your server documentation for additional details on setting up the server.
See the next sections of this chapter for information about modifying policy server parameters or viewing
information about policy servers.
Note. SSL configuration must be done manually through the policy server command.
For information about policy server parameter defaults, see “Policy Server Defaults” on page 38-2.
In this example, an LDAP server with an IP address of 10.10.2.3 will not be used to download policies.
Any policies already downloaded to the switch are not affected by disabling the server.
To re-enable the server, specify up.
-> policy server 10.10.2.3 admin up
If the policy server is not created on the default port, the no form of the command must include the port
number. For example:
-> no policy server 10.10.2.4 5000
Note that the port number must match the port number configured on the policy server.
If the port number is modified, any existing entry for that policy server is not removed. Another entry is
simply added to the policy server table.
Note. If you enable SSL, the port number is automatically set to 636. (This does not create another entry in
the port table.)
For example, if you configure a policy server with port 389 (the default), and then configure another
policy server with the same IP address but port number 5000, two entries will display on the show policy
server screen.
-> policy server 10.10.2.3
-> policy server 10.10.2.3 port number 5000
-> show policy server
Server IP Address port enabled status primary
------+--------------+-----+---------+--------+--------
1 10.10.2.3 389 Yes Up X
2 10.10.2.3 5000 No Down -
To remove an entry, use the no form of the policy server command. For example:
-> no policy server 10.10.2.3 port number 389
If this command is entered, a user with a user name of kandinsky and a password of blue will be able to
access the LDAP server to modify parameters on the server itself.
Note that the searchbase path must be a valid path in the server directory structure.
SSL is now enabled between the specified server and the switch. The port number in the switch configura-
tion will be automatically set to 636, which is the port number typically used for SSL; however, the port
number should be configured with whatever port number is set on the server. For information about
configuring the port number, see “Modifying the Port Number” on page 38-5.
To disable SSL, use no ssl with the command:
-> policy server 10.10.2.3 no ssl
SSL is disabled for the 10.10.2.3 policy server. No additional policies may be saved to the directory server
from the PolicyView application.
Use the show policy server long command to display the last load time. For example:
-> show policy server long
LDAP server 0
IP address : 10.10.2.3,
TCP port : 16652,
Enabled : Yes,
Operational Status : Down,
Preference : 99,
Authentication : password,
SSL : Disabled,
login DN : cn=DirMgr
searchbase : o=company
Last load time : 02/14/02 16:38:18
Note. If polices are applied from PolicyView or vice versa, it will activate all current configuration.
For more information about configuring policies through the CLI, see Chapter 39, “Configuring QoS.”
show policy server Displays information about servers from which policies may be down-
loaded to the switch.
show policy server long Displays detailed information about an LDAP policy server.
show policy server statistics Displays statistics about policy directory servers.
show policy server rules Displays the names of policies originating on a directory server that
have been downloaded to the switch.
show policy server events Displays any events related to a directory server.
Alcatel QoS software provides a way to manipulate data flows coming through the switch based on
user-configured policies. Manipulation of the data flow (referred to as Quality of Service or QoS) can be as
simple as allowing or denying traffic. It can also be as complicated as remapping 802.1p bits from a Layer
2 network to ToS values in a Layer 3 network.
While policies are used in many different types of network scenarios, there are several typical types
discussed in this chapter:
• Basic QoS—includes traffic prioritization and bandwidth shaping.
• ICMP policies—includes filtering, prioritizing, and/or rate limiting ICMP traffic for security.
• 802.1p/ToS/DSCP—includes policies for marking and mapping.
• Policy Based Routing (PBR)—includes policies for redirecting routed traffic.
• Policy Based Mirroring—includes mirror-to-port (MTP) policies for mirroring ingress, egress, or both
ingress and egress traffic.
• Access Control Lists (ACLs)—ACLs are a specific type of QoS policy used for Layer 2 and
Layer 3/4 filtering. Since filtering is used in many different network situations, ACLs are described in a
separate chapter (see Chapter 40, “Configuring ACLs”).
In This Chapter
This chapter describes QoS in general and how policies are used on the switch. It provides information
about configuring QoS through the Command Line Interface (CLI). CLI commands are used in the
configuration examples; for more details about the syntax of commands, see the OmniSwitch 6250/6350/
6450 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Setting up global QoS parameters (see page 39-15)
• Configuring QoS Ports and Queueing Schemes page 39-23
• Setting up policy components, such as policy conditions and actions (see page 39-33)
• Configuring specific types of policies (see page 39-65)
Note. Policies can also be configured through the PolicyView NMS application and stored on an attached
LDAP server. LDAP policies are downloaded to the switch and managed through the Policy Manager
feature in the switch. For more information about managing LDAP policies, see Chapter 38, “Managing
Policy Servers.”
QoS Specifications
The QoS functionality described in this chapter is supported on OmniSwitch 6250, 6350, 6450 switches.
Any maximum limits provided in the Specifications table are subject to available system resources.
Maximum number of policy rules 1024 (ingress and egress rules combined)
Maximum number of egress policy rules 512
Maximum number of policy conditions 2048
Maximum number of policy actions 2048
Maximum number of policy validity periods 128
Number of predefined QoS profiles 16
Maximum number of user-defined QoS profiles 112
Maximum number of policy services 256
Maximum number of TCP and UDP port ranges 4
Maximum number of groups 1024
Maximum number of group entries 1024 per group (512 per service group)
Maximum number of port groups per policy 8
Maximum number of bandwidth shaping rules per 640
slot
Maximum configurable shaper value on 10 Gig 8 Gbps
Maximum number of ToS or DSCP rules per slot 57
Maximum number of QoS policy lists per switch 13 (includes the default list)
Maximum number of priority queues per port 8
Default value of shared buffers 1500
Shared buffers range 0-4095
CLI Command Prefix Recognition Some QoS commands support prefix recognition.
See the “Using the CLI” chapter in the
OmniSwitch 6250/6350/6450 Switch Manage-
ment Guide for more information.
OmniSwitch
email server
Note. Polices must be modified using the same source used to create them. Policies configured through
PolicyView can be edited only through PolicyView. Policies created directly on the switch through the
CLI or WebView can be edited only on the switch. However, to override policies created in PolicyView,
use CLI or WebView.
This chapter discusses policy configuration using the CLI. For information about using WebView to
configure the switch, see the OmniSwitch 6250/6350/6450 Switch Management Guide. For information
about configuring policies through PolicyView, see the PolicyView online help.
Valid Policies
The switch does not allow you to create invalid condition or action combinations; if you enter an invalid
combination, an error message is displayed.
A list of valid condition and condition or action combinations is given in “Condition Combinations” on
page 39-7 and “Action Combinations” on page 39-9.
It is possible to configure a valid QoS rule that is active on the switch, however the switch is not able to
enforce the rule because some other switch function (for example, routing) is disabled. See the condition
and condition/action combinations tables for more information about valid combinations (“Condition
Combinations” on page 39-7 and “Action Combinations” on page 39-9).
Policy Lists
By default, QoS policy rules are applied to traffic ingressing on QoS ports. The ingress traffic is then
bridged or routed to a destination port where the frames are serviced by the egress port/queue scheduler.
Once the frames are serviced, policy rules can be applied to the frames before they are transmitted on the
egress port.
Policy rules are not automatically applied to egress traffic. To apply a rule to egress traffic, the rule must
belong to a QoS egress policy list. A policy list consists of a group of policy rules that is identified by the
list name. There are three types of lists available:
• Default—All rules are associated with a default policy list when the rules are created. This list is not
configurable, but it is possible to direct QoS not to assign a rule to this list. Default policy list rules are
applied to ingress traffic.
• User Network Profile (UNP)—This type of policy list is associated with an Access Guardian UNP.
The rules in this list are applied to ingress traffic that is classified into the user profile. See Chapter 35,
“Configuring Access Guardian,” for more information.
• Egress—When a list is configured as an egress policy list, all rules associated with that list are applied
to traffic egressing on QoS destination ports. Egress rules (members of an egress policy list) do not
support all available policy actions and conditions. See “Condition Combinations” on page 39-7 and
“Action Combinations” on page 39-9 to determine which conditions and actions are supported.
The policy list is configured as UNP or egress list when the list is created. For more information, see
“Creating Policy Lists” on page 39-40.
Condition Combinations
The CLI prevents you from configuring invalid condition combinations that are never allowed; however, it
does allow you to create combinations that are supported in some scenarios. For example, you can
configure source ip and a destination ip for the same condition.
The following conditions are supported and can be combined with other conditions and/or actions. Certain
conditions are not supported when the condition is associated with an egress rule (a rule that is a member
of an egress policy list. See “Creating Policy Lists” on page 39-40 for more information).
• In a given rule, ToS or DSCP can be specified for a condition with priority specified for the action.
• IP multicast (IGMP) conditions can only be combined with destination conditions: destination
slot/port, destination VLAN, destination MAC address, and destination IP address.
• The IP multicast condition works in combination with Layer 1, Layer 2, and Layer 3 destination
conditions only if these conditions specify the device that sends the IGMP report packet.
• IP multicast traffic (not IGMP) is treated as regular traffic; QoS functionality works the same way with
this type of traffic.
• The IP multicast condition works in combination with Layer 1, Layer 2, and Layer 3 destination
conditions only if these conditions specify the device that sends the IGMP report packet.
• The Layer 1 destination port condition only applies to bridged traffic, not routed traffic.
• Individual items and their corresponding groups cannot be combined in the same condition. For
example, a source IP address cannot be included in a condition with a source IP network group.
• Layer 2 and Layer 3 rules are always effected on bridged and routed traffic. As a result, combining
source or destination TCP/UDP port and IP protocol in a condition is allowed.
• To apply a Layer 2 rule to IPv6 traffic using the source or destination MAC address, add the "ipv6"
keyword to a condition for that rule.
• Unless the ipv6 keyword is used in a policy condition, Layer 4 conditions apply only to IPv4 traffic.
• Classification of fragmented packets is not supported.
Use the following “Policy Condition Combinations Table” together with the
“Supported Policy Conditions Table” as a guide when configuring policy conditions:
IP Multicast
Layer 1 Layer 2 Layer 3* Layer 4* (IGMP)
Layer 1 All All All All destination only
*IP multicast traffic (not IGMP) is treated as regular traffic; QoS functionality works the same way with
this type of traffic, with the exception that the destination port condition does not apply.
For more information about combining policy actions or policy actions with conditions, see “Action
Combinations” on page 39-9 and “Condition and Action Combinations” on page 39-11.
For specific information about how to configure policy conditions and actions to create a policy rule, see
“Creating Policies” on page 39-33.
Action Combinations
The CLI prevents you from configuring invalid action combinations that are never allowed; however, it
does allow you to create combinations that are supported in some scenarios. For example, an action
specifying maximum bandwidth can be combined with an action specifying priority.
The following actions are supported and can be combined with other actions. Certain actions are not
supported when the action is associated with an egress rule (a rule that is a member of an egress policy
list. See “Creating Policy Lists” on page 39-40 for more information).
Egress Rules
Policy Action Ingress Rules (Egress Policy List)
ACL (disposition accept, drop, deny) Yes Yes
Priority/CoS Yes No
802.1p ToS/DCSP Stamping and Mapping (only applies to Yes Yes
the outer 802.1p value; cannot modify the inner value)
Maximum Bandwidth Yes Yes
Maximum Depth Yes Yes
Tri-Color Marking (TCM) Rate Limiting Yes No
Shared (schedules multiple flows on the same queue when Yes Yes
multiple rules use the same action)
Port Redirection Yes No
Link Aggregate Redirection Yes No
No Cache (disables the logging of rule entries to the Yes No
hardware cache)
Port Disable Yes No
Permanent Gateway IP Yes No
Mirror Yes No
Use the following “Policy Action Combinations Table” together with the “Supported Policy Actions
Table” as a guide when creating policy actions.
Drop N/A No No No No No No No No
For more information about combining policy conditions or policy conditions and actions, see “Condition
Combinations” on page 39-7 and “Condition and Action Combinations” on page 39-11.
For specific information about how to configure policy conditions and actions to create a policy rule, see
“Creating Policies” on page 39-33.
Note. Additional policy condition or action combination restrictions can be applied depending on whether
the policy rule is being applied to ingress or egress traffic. See “Condition Combinations” on page 39-7
and “Action Combinations” on page 39-9 for more information.
QoS Defaults
The following tables list the defaults for global QoS parameters, individual port settings, policy rules, and
default policy rules.
The deny and drop options produce the same effect, that is, the traffic is silently dropped.
2 Configuring QoS Port Parameters. This configuration includes setting up QoS parameters on a per
port basis. Typically, it is not required to change any of the port defaults. See “QoS Port Defaults” on
page 39-13 for a list of port defaults. See “QoS Ports and Queues” on page 39-23 for information about
configuring port parameters.
3 Setting Up Policies. Most QoS configuration involves setting up policies. See “Creating Policies” on
page 39-33.
4 Applying the Configuration. Use qos apply command to configure policy rule and some global
parameters before they are active on the switch. See “Applying the Configuration” on page 39-62.
Enabling/Disabling QoS
By default QoS is enabled on the switch. If QoS policies are configured and applied, the switch attempts
to classify traffic and apply relevant policy actions.
To disable the QoS, use the qos command. For example:
-> qos disable
QoS is immediately disabled. When QoS is disabled globally, any flows coming into the switch are not
classified (matched to policies).
To re-enable QoS, enter the qos command with the enable option:
-> qos enable
QoS is immediately re-enabled. Any policies that are active on the switch are used to classify traffic
coming into the switch.
Individual policy rules can be enabled or disabled with the policy rule command.
To activate the setting, enter the qos apply command. For more information about the qos apply
command, see “Applying the Configuration” on page 39-62.
The default disposition for routed flows is not configurable on a global basis for the switch. Policies can be
configured to deny any routed traffic through the switch.
Typically, the disposition is only configured when you are using policies for Access Control Lists (ACLs).
Set the qos default bridged disposition to deny to effectively drop all Layer 2 traffic that does not match
any policy. If you want to create ACLs to allow some Layer 2 traffic through the switch, you must
configure two rules for each type of Layer 2 traffic, one for source and one for destination. For more
information about ACLs, see Chapter 40, “Configuring ACLs.”
For more information about the available queuing schemes and configuring the servicing mode for
individual ports, see “Prioritizing and Queue Mapping” on page 39-23.
Note the following when configuring the status of automatic NMS traffic prioritization:
• Only the NMS traffic associated with the first eight active IP interfaces is prioritized; any such traffic
from additional interfaces is not prioritized.
• The precedence of an active IP interface is determined by the value of the SNMP interface index
(ifindex), which was assigned to the interface when it was created. The lower the ifindex value the
higher the precedence; the higher the ifindex value the lower the precedence. Therefore, the eight IP
interfaces with the lowest ifindex values are eligible for automatic prioritization of NMS traffic.
• To change the precedence of an IP interface, use the ip interface ifindex command and specify a
higher (lower precedence) or lower (higher precedence) ifindex value.
• When automatic NMS prioritization is enabled, QoS policies that specify priority are not applied to the
NMS traffic. Other QoS policies, however, are applied to this type of traffic as usual. If a policy
specifies rate limiting, then the policy with the lowest rate limiting value is applied.
To disable automatic IP phone traffic prioritization for the switch, enter the following command:
-> qos no phones
When automatic prioritization of IP phone traffic is enabled, QoS policies that specify priority are not
applied to the IP phone traffic. Other QoS policies, however, are applied to this type of traffic as usual. If a
policy specifies rate limiting, then the policy with the lowest rate limiting value is applied.
To display information about any QoS rules on the switch, enter debug qos rule:
-> debug qos rules
To change the type of debugging, use no with the relevant type of information that you want to remove.
For example:
-> debug qos no rule
To turn off debugging (which effectively turns off logging), enter the following:
-> no debug qos
The number of lines in the log is changed. To activate the change, enter the qos apply command.
Note. If you change the number of log lines, the entire QoS log is cleared. To change the log lines without
clearing the log, set the log lines in the boot.cfg file. At the next reboot, the log is set to the specified
number of lines.
The log level is changed immediately but the setting is not saved in flash. To activate the change, enter the
qos apply command. For more information about the qos apply command, see
“Applying the Configuration” on page 39-62.
Note. A high log level value impacts the performance of the switch.
To activate the change, enter the qos apply command. For more information about the qos apply
command, see “Applying the Configuration” on page 39-62.
If event forwarding is disabled, NMS applications can still query the QoS software for events, but the
events are not sent in real time.
To disable immediate forwarding of events to switch logging, enter the following command:
-> qos no log console
To activate the change, enter the qos apply command. For more information about the qos apply
command, see “Applying the Configuration” on page 39-62.
Use the swlog output flash file-size command to configure switch logging to output logging events to the
console in addition to sending log events to a file in the flash file system of the switch. See the “Using
Switch Logging” chapter in the OmniSwitch 6250/6350/6450 Network Configuration Guide for more
information.
Insert rule 0
Rule index at 0
Insert rule 1
Rule index at 1
Insert rule 2
Rule index at 2
Enable rule r1 (1) 1,1
Enable rule r2 (0) 1,1
Enable rule yuba1 (2) 1,1
Verify rule r1(1)
Enable rule r1 (1) 1,1
Really enable r1
Update condition c1 for rule 1 (1)
Verify rule r2(1)
Enable rule r2 (0) 1,1
Really enable r2
Update condition c2 for rule 0 (1)
Verify rule yuba1(1)
Enable rule yuba1 (2) 1,1
Really enable yuba1
Update condition yubamac for rule 2 (1)
QoS Manager started TUE MAR 10 13:46:50 2002
Match rule 2 to 1
Match rule 2 to 2
Match rule 2 to 3
Use the qos log lines, qos log level, and debug qos commands to modify the log display. The log display
can also be output to the console through the qos log console command or sent to the policy software in
the switch (that manages policies downloaded from an LDAP server) through the qos forward log
command.
show qos log command also displays the IP Source Filtering drop entries.
-> show qos log
**QOS Log**
9/16/01 18:09:18 [@18:09:18] rule ISF-DROP matched
9/16/01 18:09:18 Tagged. 802.1p 0
9/16/01 18:09:18 svlan 10 VRF (null) port 1/9
9/16/01 18:09:18 MAC 00:00:1E:1D:EE:14 -> E8:E7:32:77:BB:A2
9/16/01 18:09:18 TOS 0x00 (p255) 10.10.10.10 -> 10.10.10.100
9/16/01 18:09:18 [@18:09:18] rule ISF-DROP matched
Statistics are displayed through the show qos statistics command. A sample output is as follows:
-> show qos statistics
Software resources
Applied Pending
Table CLI LDAP ACLM Blt Total CLI LDAP ACLM Blt Total Max
rules 0 0 0 0 0 0 0 0 0 0 2048
actions 0 0 0 0 0 0 0 0 0 0 2048
conditions 0 0 0 0 0 0 0 0 0 0 2048
services 0 0 0 0 0 0 0 0 0 0 256
service groups 1 0 0 0 1 1 0 0 0 1 1024
network groups 0 0 0 1 1 0 0 0 1 1 1024
port groups 2 0 0 8 10 2 0 0 8 10 1024
mac groups 0 0 0 0 0 0 0 0 0 0 1024
map groups 0 0 0 0 0 0 0 0 0 0 1024
vlan groups 0 0 0 0 0 0 0 0 0 0 1024
Note. The qos reset command only affects the global configuration. It does not affect any policy
configuration.
show qos config Displays global information about the QoS configuration.
show qos statistics Displays statistics about QoS events.
For more information about the syntax and displays of these commands, see the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
Shared Queues
Eight-priority queues are available at startup for each port. Flows always share queues; however, when a
shared action is specified in policies, the policies use the same values to implement the maximum
bandwidth.
1 If a packet matches a QoS policy rule that sets a priority value, the egress priority for the packet is set
using the value specified in the rule.
2 If a port is a UNI port, considering the SAP profile information, the DHCP packet is parsed to get the
802.1p tag.
3 The internal priority, 802.1p and DSCP value are set based on the actions configured for this rule. The
rule can be set with the following criteria:
a Internal priority only.
b Set the 802.1p and internal priority (always overwrite the priority and ToS/DSCP action).
c Set the ToS/DSCP and the internal priority only when priority is not specified.
e Modify the packet outer 802.1p value when applicable. Enqueue the packet to the appropriate egress
port queue
4 If the port is trusted, only the internal priority value is retrieved based on the default classification of
the port and the DHCP packet 802.1p or DSCP fields.
5 If a port is untrusted, the internal priority and 802.1p value is set based on the port default 802.1p
setting and the DSCP value is set based on the port default DSCP setting.
6 If a packet ingressing on a trusted port does not match any QoS policy rule that sets the priority, then
the egress priority for the packet is set using the existing DSCP value (IP packets), the existing 802.1p
value (non-IP packets), or the default classification priority value for the port. See “Configuring Trusted
Ports” on page 39-32 for more information.
7 If the default classification priority value for the port is set to DSCP, the DSCP value of a tagged IP
packet is mapped to the 802.1p value for that same packet. In other words, the 802.1p priority is
overwritten with the DSCP value. This does not apply to Layer 2 packets. See “Maintaining the 802.1p
Priority for IP Packets” on page 39-24 for more information.
8 If a packet ingressing on a trusted port does not have an 802.1p value, the egress priority for the packet
is set using the default 802.1p priority value configured for the port.
9 The egress priority for a packet ingressing on a VLAN Stacking port (a trusted port) is set using the
existing 802.1p value or configured through an associated VLAN Stacking service.
10 If a packet ingressing on an untrusted port does not match any QoS rule that sets the priority, then the
egress priority for the packet is set using the default 802.1p value configured for the port on which the
packet was received. See “Configuring the Egress Queue Maximum Bandwidth” on page 39-27 for more
information.
11 The 802.1p bit for tagged packets ingressing on untrusted ports is set with the default 802.1p value,
which is configured using the qos port default 802.1p command. If the packet is untagged, however, then
the DSCP bit is set with the default DSCP value, which is configured using the qos port default dscp
command.
Use the following table to see how packets are directed to the appropriate queues:
2 Define policy conditions for the port group; one condition for each L2 priority (802.1p) value.
3 Define policy actions that stamps the IP traffic with the L2 priority value.
4 Define policy rules using the conditions and actions created in Steps 2 and 3.
For example:
For pure Layer 2 packets, trusted ports retain the 802.1p value of the packet and queue the packets
according to that priority value.
• A Priority-WRR scheme is configured by assigning a weight of zero to one or more WRR queues to
make them Strict-Priority queues and a non-zero weight to the other WRR queues.
• If there are multiple SPQs configured, the SPQs are scheduled according to their CoS queue number
before any WFQs are scheduled.
• The weight assigned to a WRR queue designates the number of packets the queue sends out before the
scheduler moves on to the next queue. For example, a queue weight of 10 sends out 10 packets at each
interval.
• The weight assigned to a DRR queue determines the number of bytes that the queue will service. The
higher the queue weight assigned to a DRR queue, the higher the percentage of traffic that is serviced
by that queue. For example, a queue with a weight of three sends four times as much traffic as a queue
with a weight of one.
• On OmniSwitch, each DRR weight value is associated with the following number of bytes: 1=2K,
2=4K, 3=6K, 4=8K, 5=10K, 6=12K, 7=14K, 8=16K, 9=18K, 10=20K, 11=22K, 12=24K, 13=26K,
14=28K, 15=30K. For example, if the configured DRR queue weights are 1 1 2 2 3 3 4 4, queues 1 and
2 will service up to 2K each, queues 3 and 4 will service up to 4K each, queues 5 and 6 will service up
to 6K each, and queues 7 and 8 will service up to 8K.
The queuing scheme selected is the scheme that is used to shape traffic on destination (egress) ports and is
referred to as the QoS servicing mode for the port. It is possible to configure a default servicing mode to
apply to all switch ports (see “Setting the Global Default Servicing Mode” on page 39-16) or configure the
servicing mode on an individual port basis (see “Configuring the Servicing Mode for a Port” on
page 39-26).
The QoS servicing mode only applies to destination ports because it is where traffic shaping is effected on
the flows. In addition, different ports can use different servicing modes.
The following command selects the WRR scheme for port 1/8:
-> qos port 1/8 servicing mode wrr
In the above example, a weight for each of the eight WRR queues was not specified; therefore, the default
value of 1 is used for each queue. The following example selects the WRR scheme for port 1/10 and
assigns a weighted value to each queue:
-> qos port 1/10 servicing mode wrr 0 2 3 4 8 1 1 7
To reset the servicing mode for the port back to the global default mode, use the default parameter with
this command and do not specify a queueing scheme. For example,
-> qos port 1/10 servicing mode default
The qos default servicing mode command is used to set the global default queuing scheme that is used
for all ports. See “Setting the Global Default Servicing Mode” on page 39-16 for more information.
Bandwidth Shaping
Bandwidth shaping is configured on a per port basis. Bandwidth policing is applied using QoS policies
(see “Port Groups and Maximum Bandwidth” on page 39-55 and “Policy Applications” on page 39-65 for
more information).
QoS supports configuring maximum bandwidth on ingress and egress ports. In addition, the maximum
egress bandwidth is configurable on a per Class-of-Service (COS) queue basis for each port (see
“Configuring the Egress Queue Maximum Bandwidth” on page 39-27 for more information).
To limit the ingress or egress bandwidth for a QoS port, use the qos port maximum egress-bandwidth or
qos port maximum ingress-bandwidth commands. For example,
-> qos port 1/1 maximum egress-bandwidth 10M
Note the following when configuring the ingress or egress bandwidth limit for a port:
• Maximum bandwidth limiting is done using a granularity of 64 Kbps. Any value specified that is not a
multiple of 64K is rounded up to the next highest multiple of 64 K.
• The maximum bandwidth value cannot exceed the maximum bandwidth of the interface type
associated with the port.
• Modifying the maximum bandwidth is most useful for low-bandwidth links.
• The bandwidth limit configured using the qos port maximum egress-bandwidth command takes
precedence over an egress queue limit configured on the same port.
Configuring the bandwidth values for different queues requires a separate command for each queue.
To configure the DEI bit operation for an individual port, use the qos port dei with the egress parameter
option. For example:
-> qos port 1/10 dei egress
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for more information about these commands.
When equal scheduling of yellow traffic is configured, yellow traffic on all the queues is equally shared
between medium and best effort.
When equal scheduling is configured for yellow traffic, medium with priority 3 gets 100 Mbps green
traffic and 100 Mbps yellow traffic; the best effort gets 200 Mbps yellow traffic.
The equal scheduling is calculated according to the following formula:
Yellow traffic generated by Premium traffic = 0 Mbps
Yellow traffic generated by Medium traffic = 200 Mbps
Yellow traffic generated by Best Effort traffic = 400 Mbps
The remaining bandwidth is distributed in the ratio 0:200:400 (0:1:2 between Medium and Best Effort
traffic)
Medium gets 1/3*300 Mbps = 100 Mbps
Best Effort gets 2/3*300 Mbps = 200 Mbps
The following diagram depicts the traffic behavior after configuring equal scheduling of yellow traffic:
Use the no form of the command to remove the equal scheduling of yellow traffic. This removes the
priority configured for the yellow traffic. For example:
-> qos no force-yellow-priority
Note . Mobile ports are not Q-tagged in the same manner as fixed ports; however, a mobile port joins a
VLAN if tagged traffic for that VLAN comes in on the mobile port, and the vlan mobile-tag function is
enabled for that VLAN. For more information about tagging mobile port traffic, see Chapter 4, “Configur-
ing VLANs.”
Ports must be both trusted and configured for 802.1Q traffic to accept 802.1p traffic.
The following applies to ports that are trusted (for 802.1p traffic, the ports must also be able to accept
802.1Q packets):
• The 802.1p or ToS/DSCP value is preserved.
• If the incoming 802.1p or ToS/DSCP flow does not match a policy, the switch places the flow into a
default queue and prioritizes the flow based on the 802.1p or ToS/DSCP value in the flow.
• If the incoming 802.1p or ToS/DSCP flow matches a policy, the switch queues the flow based on the
policy action.
• If the incoming 802.1p flow does not contain an 802.1p value, the switch uses the default 802.1p value
configured for the port to prioritize the flow.
The switch can be set globally so that all ports are trusted. Individual ports can be configured to override
the global setting.
To configure individual ports as trusted, use the qos port trusted command with the desired slot/port
number. For example:
-> qos port 3/2 trusted
The global setting is active immediately; however, the port setting requires qos apply to activate the
change. See “Applying the Configuration” on page 39-62 for information about the qos apply command.
To activate the configuration, enter the qos apply command. For more information about the qos apply
command, see “Applying the Configuration” on page 39-62.
For actions that set 802.1p bits, a limited set of policy conditions are supported. For information about the
conditions to be used with an 802.1p action, see “Condition Combinations” on page 39-7 and “Action
Combinations” on page 39-9.
Note. 802.1p mapping can also be set for Layer 3 traffic, which typically has the 802.1p bits set to zero.
show qos port Displays information about all QoS ports or a particular port.
show qos queue Displays information for all QoS queues or only those queues associated
with a particular slot/port.
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for more information about the syntax and
displays for these commands.
Creating Policies
This section describes how to create policies in general. For information about configuring specific types
of policies, see “Policy Applications” on page 39-65.
Basic commands for creating policies are as follows:
policy condition
policy action
policy rule
This section describes generally how to use these commands. For additional details about command
syntax, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Note. A policy rule can include a policy condition or a policy action that was created through PolicyView
rather than the CLI. But a policy rule, policy action, or policy condition can only be modified through the
source that created it. For example, if an action was created in PolicyView, it can be included in a policy
rule configured through the CLI, but it cannot be modified through the CLI.
Policies are not used to classify traffic until the qos apply command is entered. See
“Applying the Configuration” on page 39-62.
To view information about how the switch classifies particular condition parameters, use the show policy
classify command. This is useful to test conditions before actually activating the policies on the switch.
See “Testing Conditions” on page 39-46.
Note. (Optional) Test the rule with the show policy classify command using information from the policy
condition. For example:
-> show policy classify l3 source ip 10.10.2.3
This command displays information about whether the indicated parameter can be used to classify traffic
based on policies that are configured on the switch.
2 Create a policy action with the policy action command. For example:
-> policy action action2 priority 7
3 Create a policy rule with the policy rule command. For example:
-> policy rule my_rule condition cond3 action action2
4 Use the qos apply command to apply the policy to the configuration. For example:
-> qos apply
Note. (Optional) To verify that the rule has been configured, use the show policy rule command. The
display is similar to the following:
-> show policy rule
Policy From Prec Enab Act Refl Log Trap Save
r1 cli 0 Yes Yes No No Yes Yes
(L2/3): cond1 -> action1
This command displays information about whether the indicated parameter can be used to classify traffic
based on policies that are configured on the switch. For more information about this display, see
“Verifying Policy Configuration” on page 39-45.
An example of how the example configuration commands display when entered sequentially on the
command line is given here:
-> policy condition cond3 source ip 10.10.2.3
-> policy action action2 priority 7
-> policy rule my_rule condition cond3 action action2
-> qos apply
ASCII-File-Only Syntax
When the policy rule, policy condition, and policy action commands as well as any of the condition
group commands are configured and saved in an ASCII file (through the snapshot command), the
commands included in the file includes syntax indicating the origin of the commands. The origin specifies
where the rule, condition, condition group, or action was created, either an LDAP server or the CLI (from
ldap or from cli). For built-in QoS objects, the syntax displays as from blt. For example:
-> policy action A2 from ldap disposition accept
The from option is configurable (for LDAP or CLI only) on the command line; however, it is not
recommended that a QoS object origin be modified. The blt keyword indicates built-in; this keyword
cannot be used on the command line. For information about built-in policies and QoS groups, see “How
Policies Are Used” on page 39-4.
Note. Policy condition configuration is not active until the qos apply command is entered. See “Applying
the Configuration” on page 39-62.
To create or modify a policy condition, use the policy condition command with the keyword for the type
of traffic you want to classify, for example, an IP address or group of IP addresses. In this example, a
condition (c3) is created for classifying traffic from source IP address 10.10.2.1:
-> policy condition c3 source ip 10.10.2.1
There are many options for configuring a condition, depending on how you want the switch to classify
traffic for this policy. An overview of the options is given here. Later sections of this chapter describe how
to use the options in particular network situations.
Note. The group options in this command refer to groups of addresses, services, or ports that you
configure separately through policy group commands. Rather than create a separate condition for each
address, service, or port, use groups and attach the group to a single condition. See “Using Condition
Groups in Policies” on page 39-48 for more information about setting up groups.
More than one-condition parameter can be specified. Some condition parameters are mutually exclusive.
For supported combinations of condition parameters, see “Condition Combinations” on page 39-7.
Note. The source ipv6, destination ipv6, ipv6, source port, and source port group condition keywords
are not supported by egress policies.
The condition will not be active on the switch until you enter the qos apply command.
The specified parameter (in this case, a source IP address) is removed from the condition (c3) at the next
qos apply.
Note. You cannot remove all parameters from a policy condition. A condition must be configured with at
least one parameter.
The condition (c3) cannot be deleted if it is currently being used by a policy rule. If a rule is using the
condition, the switch displays an error message. For example:
ERROR: c3 is being used by rule ‘my_rule’
In this case, the condition is not deleted. The condition (c3) must first be removed from the policy rule
(my_rule). See “Creating Policy Rules” on page 39-37 for more information about setting up rules.
If c3 is not used by a policy rule, it is deleted after the next qos apply.
In this example, the action (Block) has a disposition of drop (disposition determines whether a flow is
allowed or dropped on the switch). This action can be used in a policy rule to deny a particular type of
traffic specified by a policy condition.
Note. Policy action configuration is not active until the qos apply command is entered. See “Applying the
Configuration” on page 39-62.
More than one-action parameter can be specified. Some parameters are mutually exclusive. In addition,
some action parameters are only supported with particular condition parameters. For information about
supported combinations of condition and action parameters, see “Condition Combinations” on page 39-7
and “Action Combinations” on page 39-9. See the OmniSwitch 6250/6350/6450 CLI Reference Guide for
details about command syntax.
This example removes the configured priority value from action a6. If any policy rule is using action a6,
the default action is to allow the flow classified by the policy condition.
The specified parameter (in this case, priority) is removed from the action at the next qos apply.
The action cannot be deleted if it is currently being used by a policy rule. If a rule is using the action, the
switch displays an error message. For example:
ERROR: a6 is being used by rule ‘my_rule’
In this case, the action is not deleted. The action (a6) must first be removed from the policy rule
(my_rule). See “Creating Policy Rules” on page 39-37 for more information about setting up rules.
If a6 is not used by a policy rule, it is deleted after the next qos apply.
The rule (rule5) only takes effect after the qos apply command is entered. For more information about the
qos apply command, see “Applying the Configuration” on page 39-62.
The policy rule command specifies the following keywords:
In addition, use the policy rule command to administratively disable or re-enable the policy rule. By
default, rules are enabled. For a list of rule defaults, see “Policy Rule Defaults” on page 39-13.
Information about using the policy rule command options is given in the next sections.
Note the following when using validity periods to restrict the times when a rule is active:
• Only one-validity period is associated with a policy rule. Each time this command is entered with a
validity period name specified, the existing period name is overwritten with the new one.
• A rule is only in effect when all the parameters of its validity period are true. In the above example,
rule r01 is only applied between 13:00 and 19:00 on Mondays and Fridays. During all other times and
days, the rule is not applied.
• Software and hardware resources are allocated for rules associated with a validity period even if the
validity period is not active. Pre-allocating the resources ensures that the rule can be enforced when the
validity period becomes active.
Disabling Rules
By default, rules are enabled. Use the policy rule command to disable or re-enable the rules. For example:
-> policy rule rule5 disable
Rule Precedence
The switch attempts to classify flows coming into the switch according to policy precedence. Only the rule
with the highest precedence is applied to the flow. This is true even if the flow matches more than one
rule.
Precedence is important for Access Control Lists (ACLs). For more details about precedence and
examples for using precedence, see Chapter 40, “Configuring ACLs.”
Saving Rules
The save option marks the policy rule so that the rule is captured in an ASCII text file (using the
configuration snapshot command) and saved to the working directory (using the write memory
command or copy running-config working command). By default, rules are saved.
If the save option is removed from a rule, the qos apply command can activate the rule for the current
session, but the rule is not saved over a reboot. The no save option is used for temporary policies that you
do not want saved in the switch configuration file.
To remove the save option from a policy rule, use no with the save keyword. For example:
-> policy rule rule5 no save
To reconfigure the rule as saved, use the policy rule command with the save option. For example:
-> policy rule rule5 save
For more information about the configuration snapshot, write memory, and copy running-config
working commands, see the OmniSwitch 6250/6350/6450 Switch Management Guide and the OmniS-
witch 6250/6350/6450 CLI Reference Guide.
For more information about applying rules, see “Applying the Configuration” on page 39-62.
Logging Rules
Logging a rule is useful for determining the source of firewall attacks.
To specify that the switch must log information about flows that match the specified policy rule, use the
policy rule command with the log option. For example:
-> policy rule rule5 log
To stop the switch from logging information about flows that match a particular rule, use no with the log
keyword. For example:
-> policy rule rule5 no log
When logging is active for a policy rule, a logging interval is applied to specify how often to look for
flows that match the policy rule. By default, the interval time is set to 30 seconds. To change the log
interval time, use the optional interval keyword with the log option. For example:
-> policy rule rule5 log interval 1500
Deleting Rules
To remove a policy rule, use the no form of the command.
-> no policy rule rule1
By default, a policy list is enabled at the time the list is created. To disable or enable a policy list, use the
following commands:
To remove an individual rule from an egress policy list, use the following command:
-> policy list egress_rules no r5
To remove an entire egress policy list from the switch configuration, use the following command:
-> no policy list egress_rules
Use the show policy list command to display the QoS policy rule configuration for the switch.
The no default-list option can also remove an existing rule from the default list. For example, the r2 rule
exists in the switch configuration but was not excluded from the default list at the time the rule was
created. The following command removes the rule from the default list:
-> policy rule r2 condition c1 action a1 no default-list
To add an existing rule to the default list, use the default-list parameter option of the policy rule
command. For example:
-> policy rule r2 condition c1 action a1 default-list
Rules associated with the default policy list are applied only to ingress traffic, unless the rule is also
assigned to an egress policy list.
The rules associated with an egress list are created in the same manner as all other policy rules. However,
the following policy conditions and actions are not supported within egress rules:
• IPv6 conditions (any condition using the ipv6 keyword).
• Source port and source port group conditions.
• Destination VLAN and destination VLAN group conditions.
• Internal priority/CoS actions.
• Tri-Color Marking (TCM) policy actions
• Port or linkagg redirect actions.
• Port disable, no caches, and permanent gateway IP actions.
See “Condition Combinations” on page 39-7 and “Action Combinations” on page 39-9 for more
information about policy conditions and actions supported by both ingress and egress rules.
Consider the following additional guidelines for using egress policy lists:
• QoS changes DSCP and 802.1p values for traffic ingressing on an untrusted port. As a result, the new
values may not match any egress policy list rules as expected. To avoid this scenario, trust the ingress
port or configure a default ToS/DSCP/802.1p value as required.
• If an egress policy list rule contains an 802.1p condition and the ingress port is trusted, set the default
classification of the ingress port to 802.1p. If the default classification of the ingress port is set to
DSCP, the 802.1p value of the traffic is changed as per the DSCP classification and will not match the
egress 802.1p condition.
• An egress policy rule supports a maximum of two-destination port groups.
• Accounting mode is not supported for egress policy list. So if accounting mode is enabled for the rule
then that rule can't be part of egress policy list and vice versa.
• Egress policy lists and VLAN translation Service Access Point (SAP) configurations are mutually
exclusive. The switch only allows whichever of these two features is configured first.
• Egress rate limiting configured through an Ethernet Service SAP profile takes precedence over egress
rate limiting specified within a QoS egress policy list rule.
• If there are no system resources available to assign a rule to an ingress policy list (the default list),
assigning that same rule to an egress list is not allowed.
-> policy condition cond1 source mac 00:11:22:33:44:55 source vlan 100
-> policy action act1 disposition drop
-> policy rule rule1 condition cond1 action act1
-> qos apply
In this example, the policy rule command does not use the no default-list parameter, so the rule is
automatically assigned to the default policy list. The default list always exists and is not configurable. As a
result, the policy list command is not required to assign the rule to the default list.
-> policy condition cond1 source mac 00:11:22:33:44:55 source vlan 100
-> policy condition cond2 source ip 1.2.3.4
-> policy action act1 disposition drop
-> policy action act2 maximum bandwidth 1.00M
-> policy rule rule1 condition cond1 action act1 no default-list
-> policy rule rule2 condition cond2 action act2 no default-list
-> policy list egress_rules1 type egress rules rule1 rule2
-> qos apply
In this example, the policy rule commands use the no default-list parameter so that rule1 and rule2 are
not assigned to the default policy list. The policy list command is then used to assign rule1 and rule2 to
the egress_rules1 policy list. Because these two rules are assigned to the egress_rules1 policy list and not
the default list, the rules are applied only to egress traffic.
Example 3: Default List and Egress List - Ingress and Egress Rules
The following example creates and assigns policy rules to the default policy list and an egress policy list.
In this example, rule1, rule2, and rule3 are assigned to the default policy list and rule1 and rule4 are
assigned to the egress_rules1 list. As a result, these rules are applied as follows:
• Rules rule2 and rule3 are applied only to ingress traffic because they are associated with the default
policy list and not the egress_rules1 policy list.
• Rule rule1 is applied to both ingress and egress traffic because the rule is associated with both the
default policy list and the egress_rules1 policy list.
• Rule rule4 is applied only to egress traffic because the rule is associated with the egress_rules1 policy
list and not the default list.
show policy rule Displays information about all pending and applied policy conditions or
a particular policy condition configured on the switch. Use the applied
keyword to display information about applied conditions only.
show policy action Displays information about all pending and applied policy actions or a
particular policy action configured on the switch. Use the applied
keyword to display information about applied actions only.
show policy rule Displays information about all pending and applied policy rules or a
particular policy rule. Use the applied keyword to display information
about applied rules only.
show active policy rule Displays applied policy rules that are active (enabled) on the switch.
show active policy rule meter- Displays the Tri-color Marking (TCM) counter color statistics for active
statistics policy rules. See “Tri-Color Marking” on page 39-67 for information.
show policy list Displays information about pending and applied policy lists.
When the command is used to show output for all pending and applied policy configuration, the following
characters appear in the display:
character definition
+ Indicates that the policy rule has been modified or has
been created since the last qos apply.
- Indicates the policy object is pending deletion.
# Indicates that the policy object differs between the pend-
ing/applied objects.
For example:
The above display indicates that my_rule is inactive and is not used to classify traffic on the switch (the
Inact field displays Yes). The rule my_rule5 has been configured since the last qos apply command was
entered, as indicated by the plus (+) sign. The rule is not used to classify traffic until the next qos apply.
Only mac1 is actively being used on the switch to classify traffic.
To display only policy rules that are active (enabled and applied) on the switch, use the show active
policy rule command. For example:
Policy From Prec Enab Act Refl Log Trap Save Matches
mac1 cli 0 Yes Yes No No Yes Yes 0
{L2/3}: dmac1 -> pri2
In this example, the rule my_rule does not display because it is inactive. Rules are inactive if they are
administratively disabled through the policy rule command, or if the rule cannot be enforced by the
current hardware. Although my_rule5 is administratively active, it is still pending and not yet applied to
the configuration. Only mac1 is displayed here because it is active on the switch.
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for more information about the output of these
commands.
Testing Conditions
Before applying policies to the configuration, to see how the policies are used to classify traffic or how
theoretical traffic is classified by policies that are already applied on the switch, use qos apply command.
Use the show policy classify commands to see how the switch classifies certain condition parameters.
This command is used to examine the set of pending policies only. Use the applied keyword with the
command to examine the applied set of policies only. The command includes a keyword (l2, l3, multicast)
to
indicate whether the Layer 2, Layer 3, or multicast classifier must be used to classify the traffic.
The keywords used with these commands are similar to the keywords used for the policy condition
command. The keyword must be relevant to the type of traffic as listed in the table here:
To test a theoretical condition against the set of pending policies, enter the command and the relevant
keyword and value. The switch displays the information about the potential traffic and attempt to match it
to a policy (pending policies only). For example:
-> show policy classify l2 destination mac 08:00:20:d1:6e:51
Packet headers:
L2:
*Port : 0/0 -> 0/0
*IfType : any -> any
*MAC : 000000:000000 -> 080020:D1E51
*VLAN : 0 -> 0
*802.1p : 0
L3/L4:
*IP : 0.0.0.0 -> 0.0.0.0
*TOS/DSCP : 0/0
Classify L2 Source:
*No rule matched: (accept)
The display shows Layer 2 or Layer 3 information, depending on the type of traffic you are attempting to
classify. In this example, the display indicates that the switch found a rule, yuba, to classify destination
traffic with the specified Layer 2 information.
To test a theoretical condition against the set of applied policies, enter the command with the applied
keyword. The switch displays the information about the potential traffic and attempt to match it to a policy
(applied policies only). For example:
-> show policy classify l3 applied source ip 143.209.92.131 destination ip
198.60.82.5
Packet headers:
L2:
*Port : 0/0 -> 0/0
*IfType : any -> any
*MAC : 000000:000000 -> 000000:000000
*VLAN : 0 -> 0
*802.1p : 0
L3/L4:
*IP : 143.209.92.131 -> 198.60.82.5
*TOS/DSCP : 0/0
In this example, the display indicates that the switch found an applied rule, r1, to classify Layer 3 flows
with the specified source and destination addresses.
To activate any policy rules that have not been applied, use the qos apply command. To delete rules that
have not been applied (and any other QoS configuration not already applied), use the qos revert
command. See “Applying the Configuration” on page 39-62.
ACLs
Access Control Lists (ACLs) typically use condition groups in policy conditions to reduce the number
of rules required to filter particular types of traffic. For more information about ACLs, see Chapter 40,
“Configuring ACLs.”
2 Attach the group to a policy condition. For more information about configuring conditions, see
“Creating Policy Conditions” on page 39-35.
-> policy condition cond3 source network group netgroup1
Note. (Optional) Use the show policy network group command to display information about the network
group. Each type of condition group has a corresponding show command. For example:
-> show policy network group
Group Name: From Entries
Switch blt 4.0.1.166
10.0.1.166
+netgroup1 cli 10.10.5.1/255.255.255.0
10.10.5.2/255/255/255.0
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for more information about the output of this
display. See “Verifying Condition Group Configuration” on page 39-57 for more information about using
show commands to display information about condition groups.
3 Attach the condition to a policy rule. (For more information about configuring rules, see “Creating
Policy Rules” on page 39-37.) In this example, action act4 has already been configured. For example:
-> policy rule my_rule condition cond3 action act4
4 Apply the configuration. See “Applying the Configuration” on page 39-62 for more information about
this command.
-> qos apply
Note. Network group configuration is not active until the qos apply command is entered.
In this example, a policy network group called netgroup2 is created with two-IPv4 addresses. No mask is
specified, so the IPv4 addresses are assumed to be host addresses.
-> policy network group netgroup2 10.10.5.1 10.10.5.2
In the next example, a policy network group called netgroup3 is created with two-IPv4 addresses. The
first address also specifies a mask.
-> policy network group netgroup3 173.21.4.39 mask 255.255.255.0 10.10.5.3
In this example, the 173.201.4.39 address is subnetted, so that any address in the subnet is included in the
network group. For the second address, 10.10.5.3, a mask is not specified; the address is assumed to be a
host address.
The network group can then be associated with a condition through the policy condition command. The
network group must be specified as a source network group or destination network group. In this
example, netgroup3 is configured for condition c4 as source network group:
-> policy condition c4 source network group netgroup3
To remove addresses from a network group, use no and the relevant addresses. For example:
-> policy network group netgroup3 no 173.21.4.39
This command deletes the 173.21.4.39 address from netgroup3 after the next qos apply.
To remove a network group from the configuration, use the no form of the policy network group
command with the relevant network group name. The network group must not be associated with any
policy condition or action. For example:
-> no policy network group netgroup3
If the network group is not currently associated with any condition or action, the network group
netgroup3 is deleted from the configuration after the next qos apply.
If a condition or an action is using netgroup3, the switch displays an error message similar to the
following:
ERROR: netgroup3 is being used by condition 'c4'
In this case, remove the network group from the condition first, then enter the no form of the policy
network group command. For example:
-> policy condition c4 no source network group
-> no policy network group netgroup3
The policy condition command removes the network group from the condition. (See “Creating Policy
Conditions” on page 39-35 for more information about configuring policy conditions.) The network group
is deleted at the next qos apply.
Creating Services
Policy services are made up of TCP or UDP ports or port ranges. They include source or destination ports,
or both, but the ports must be the same type (TCP or UDP). Mixed port types cannot be included in the
same service.
Policy services can be associated with policy service groups, which are then associated with policy
conditions; or they can be directly associated with policy conditions.
To create a service, use the policy service command. With this command, there are two different methods
for configuring a service. You can specify the protocol and the IP port; or you can use shortcut keywords.
The following table lists the keyword combinations:
An IP protocol (TCP or UDP), source IP port and/or destination IP port (or port range) must be associated
with a service. IP port numbers are well-known port numbers defined by the IANA. For example, port
numbers for FTP are 20 and 21; Telnet is 23.
In this example, a policy service called telnet1 is created with the TCP protocol number (6) and the
well-known Telnet destination port number (23).
-> policy service telnet1 protocol 6 destination ip port 23
A shortcut for this command replaces the protocol and destination ip port keywords with destination
tcp port:
-> policy service telnet1 destination tcp port 23
In the next example, a policy service called ftp2 is created with port numbers for FTP (20 and 21):
-> policy service ftp2 protocol 6 source ip port 20-21 destination ip port 20
A shortcut for this command replaces the protocol, source ip port, and destination ip port keywords
with source tcp port and destination tcp port:
-> policy service ftp2 source tcp port 20-21 destination tcp port 20
Multiple services created through the policy service command can be associated with a policy service
group; or, individual services can be configured for a policy condition. If you have multiple services to
associate with a condition, configure a service group and attach it to a condition. Service groups are
described in “Creating Service Groups” on page 39-51.
Note. Service configuration is not active until the qos apply command is entered.
The ftp2 service is deleted from the configuration at the next qos apply if the service is not currently
associated with a policy condition or a service group.
In this example, a policy service group called serv_group is created with two-policy services (telnet1 and
ftp2). The policy services were created with the policy service command. (See “Creating Services” on
page 39-50 for information about configuring policy services.)
Note. The policy service group can include only services with all source ports, all destination ports, or all
source and destination ports. For example, the group cannot include a service that specifies a source port
and another service that specifies a destination port.
The service group can then be associated with a condition through the policy condition command. For
example:
-> policy condition c6 service group serv_group
This command configures a condition called c6 with service group serv_group. All of the services
specified in the service group is included in the condition. (For more information about configuring
conditions, see “Creating Policy Conditions” on page 39-35.)
Note. Service group configuration must be applied to the configuration with the qos apply command.
To delete a service from the service group, use no with the relevant service name. For example:
-> policy service group serv_group no telnet1
In this example, the service telnet1 is removed from policy service group serv_group.
To delete a service group from the configuration, use the no form of the policy service group command.
The service group must not be associated with any condition. For example:
-> no policy service group serv_group
Service group serv_group is deleted at the next qos apply. If serv_group is associated with a policy
condition, an error message is displayed instead. For example:
ERROR: serv_group is being used by condition 'c6'
In this case, remove the service group from the condition first; then enter the no policy service group
command. For example:
-> policy condition c6 no service group
-> no policy service group serv_group
The policy condition command removes the service group from the policy condition. (See “Creating
Policy Conditions” on page 39-35 for more information about configuring policy conditions.) The service
group is deleted at the next qos apply.
This command creates MAC group macgrp2 with two MAC addresses. The first address includes a MAC
address mask, so that any MAC address starting with 08:00:20 is included in macgrp2.
The MAC group can then be associated with a condition through the policy condition command. The
policy condition specifies whether the group must be used for source or destination. For example:
-> policy condition cond3 source mac group macgrp2
This command creates a condition called cond3 that can be used in a policy rule to classify traffic by
source MAC addresses. The MAC addresses are specified in the MAC group. For more information about
configuring conditions, see “Creating Policy Conditions” on page 39-35.
Note. MAC group configuration is not active until the qos apply command is entered.
To delete addresses from a MAC group, use no and the relevant addresses:
-> policy mac group macgrp2 no 08:00:20:00:00:00
This command specifies that MAC address 08:00:20:00:00:00 be deleted from macgrp2 at the next qos
apply.
To delete a MAC group, use the no form of the policy mac group command with the relevant MAC
group name. The group must not be associated with any policy condition. For example:
-> no policy mac group macgrp2
MAC group macgrp2 is deleted at the next qos apply. If macgrp2 is associated with a policy condition,
an error message is displayed instead:
ERROR: macgrp2 is being used by condition 'cond3'
In this case, remove the MAC group from the condition first; then enter the no policy mac group
command. For example:
-> policy condition cond3 no source mac group
-> no policy mac group macgrp2
The policy condition command removes the MAC group from the condition. See
“Creating Policy Conditions” on page 39-35 for more information about configuring policy conditions.
The MAC group is deleted at the next qos apply.
The port group can then be associated with a condition through the policy condition command. The
policy condition specifies whether the group must be used for source or destination. For example:
-> policy condition cond4 source port group techpubs
This command creates a condition called cond4 that can be used in a policy rule to classify traffic by
source port number. The port numbers are specified in the port group. For more information about
configuring conditions, see “Creating Policy Conditions” on page 39-35.
Note. Port group configuration is not active until the qos apply command is entered.
To delete ports from a port group, use no and the relevant port numbers.
-> policy port group techpubs no 2/1
This command specifies that port 2/1 be deleted from the techpubs port group at the next qos apply.
To delete a port group, use the no form of the policy port group command with the relevant port group
name. The port group must not be associated with any policy condition. For example:
-> no policy port group techpubs
The port group techpubs is deleted at the next qos apply. If techpubs is associated with a policy
condition, an error message is displayed instead:
ERROR: techpubs is being used by condition 'cond4'
In this case, remove the port group from the condition first; then enter the no policy port group
command. For example:
-> policy condition cond4 no source port group
-> no policy port group techpubs
The policy condition command removes the port group from the policy condition. (See “Creating Policy
Conditions” on page 39-35 for more information about configuring policy conditions.) The port group is
deleted at the next qos apply.
To configure rate limiting to non-split mode in a defined port group, use the following command. For
example:
-> policy port group techpubs mode non-split 1/1-2
Note. Rate limiting is not supported for destination port group, and an error is displayed at the time of rule
creation for the destination port group condition.
In this example, if both ports 1 and 2 are active ports, the 10k maximum bandwidth is shared by both
ports.
In this example, if both ports 1 and 2 are active ports, the maximum bandwidth of the 10k is applied to
both the ports separately.
This command creates VLAN group vlangrp1 with two VLAN IDs and a range of VLAN IDs. This group
can then be associated with a condition through the policy condition command. For example:
-> policy condition cond3 source vlan group vlangrp1
This command creates a condition called cond3 that can be used in a policy rule to classify traffic by
source VLAN IDs. The VLAN IDs are specified in the VLAN group. For more information about
configuring conditions, see “Creating Policy Conditions” on page 39-35.
Note. VLAN group configuration is not active until the qos apply command is entered.
To delete VLAN IDs from a VLAN group, use no and the relevant addresses:
-> policy mac group vlangrp1 no 15
This command specifies that VLAN ID 15 be deleted from vlangrp1 at the next qos apply.
When deleting a VLAN ID that falls within a specified range of VLAN IDs for the group, the entire range
must be deleted. For example, to delete VLAN 23 from the group, the range 20-25 is specified:
-> policy mac group vlangrp1 no 20-25
This command specifies that VLAN IDs 20, 21, 22, 23, 24, and 25 be deleted from vlangrp1 at the next
qos apply.
To delete a VLAN group, use the no form of the policy vlan group command with the relevant VLAN
group name. The group must not be associated with any policy condition. For example:
-> no policy vlan group vlangrp1
VLAN group vlangrp1 is deleted at the next qos apply. If vlangrp1 is associated with a policy condition,
an error message is displayed instead:
ERROR: vlangrp1 is being used by condition 'cond3'
In this case, remove the VLAN group from the condition first; then enter the no policy vlan group
command. For example:
-> policy condition cond3 no source vlan group
-> no policy vlan group vlangrp1
The policy condition command removes the VLAN group from the condition. See “Creating Policy
Conditions” on page 39-35 for more information about configuring policy conditions. The MAC group is
deleted at the next qos apply.
show policy network group Displays information about all pending and applied policy network
groups or a particular network group. Use the applied keyword to
display information about applied groups only.
show policy service Displays information about all pending and applied policy services or a
particular policy service configured on the switch. Use the applied
keyword to display information about applied services only.
show policy service group Displays information about all pending and applied policy service
groups or a particular service group. Use the applied keyword to display
information about applied groups only.
show policy mac group Displays information about all pending and applied MAC groups or a
particular policy MAC group configured on the switch. Use the applied
keyword to display information about applied groups only.
show policy port group Displays information about all pending and applied policy port groups
or a particular port group. Use the applied keyword to display
information about applied groups only.
show policy vlan group Displays information about all pending and applied policy VLAN
groups or a particular VLAN group. Use the applied keyword to display
information about applied groups only.
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for more information about the syntax and
output for these commands.
When the command is used to show output for all pending and applied condition groups, the following
characters appear in the display:
character definition
+ Indicates that the policy rule has been modified or has
been created since the last qos apply.
- Indicates the policy object is pending deletion.
# Indicates that the policy object differs between the pend-
ing/applied objects.
In the example shown here, netgroup1 is a new network group that has not yet been applied to the
configuration.
-> show policy network group
Group Name: From Entries
Switch blt 4.0.1.166
10.0.1.166
143.209.92.166
192.85.3.1
+netgroup1 cli 143.209.92.0/255.255.255.0
172.28.5.0/255/255/255.0
When the qos apply command is entered, the plus sign (+) is removed from netgroup1 in the display. See
“Applying the Configuration” on page 39-62 for more information about the qos apply command.
2 Attach the map group to a policy action. See “Creating Policy Actions” on page 39-36 for more
information about creating policy actions.
-> policy action tosMap map tos to 802.1p using tosGroup
Note. (Optional) Use the show policy map group command to verify the map group.
-> show policy map group
Group Name From Entries
+tosGroup cli 1-2:5
4:5
5-6:7
For more information about this command, see “Verifying Map Group Configuration” on page 39-61 and
the OmniSwitch 6250/6350/6450 CLI Reference Guide.
3 Attach the action to a policy rule. In this example, the condition Traffic is already configured. For
more information about configuring rules, see “Creating Policy Rules” on page 39-37.
-> policy rule r3 condition Traffic action tosMap
4 Apply the configuration. For more information about this command, see “Applying the Configuration”
on page 39-62.
-> qos apply
The to and from values are separated by a colon (:). If traffic with 802.1p bits comes into the switch and
matches a policy that specifies the Map1 action, the bits are remapped according to Group2. If the
incoming 802.1p value is 1 or 2, the value is mapped to 5. If the incoming 802.1p value is 3, the outgoing
value will be 3 (the map group does not specify any mapping for a value of 3). If the incoming 802.1p
value is 4, the value is mapped to 5. If the incoming 802.1p value is 5 or 6, the value is mapped to 7.
When mapping to a different type of value; however, (ToS/DSCP to 802.1p), any values in the incoming
flow that matches the rule but are not included in the map group are zeroed out. For example, the
following action specifies the same map group but instead specifies mapping 802.1p to ToS:
-> policy action Map2 map tos to 802.1p using Group2
In this case, if ToS traffic comes into the switch and matches a policy that specifies the Map2 action, the
ToS value is mapped according to Group2 if the value is specified in Group2. If the incoming ToS value
is 2, the value is mapped to 5; however, if the incoming value is 3, the switch maps the value to zero as
there is no mapping in Group2 for a value of 3.
Note. Ports on which the flow is mapped must be a trusted port; otherwise the flow is dropped.
The to and from values are separated by a colon (:). For example, a value of 2 is mapped to 5.
Note. Map group configuration is not active until the qos apply command is entered.
The remapping group can then be associated with a rule through the policy action command. In this exam-
ple, a policy condition called Traffic has already been configured.
-> policy action tosMap map tos to 802.1p using tosGroup
-> policy rule r3 condition Traffic action tosMap
To delete mapping values from a group, use no and the relevant values:
-> policy map group tosGroup no 1-2:4
The specified values are deleted from the map group at the next qos apply.
To delete a map group, use the no form of the policy map group command. The map group must not be
associated with a policy action. For example:
-> no policy map group tosGroup
If tosGroup is currently associated with an action, an error message similar to the following is displayed:
ERROR: tosGroup is being used by action 'tosMap'
In this case, remove the map group from the action, then enter the no policy map group command:
-> policy action tosMap no map group
-> no policy map group tosGroup
Note. For Layer 2 flows, you cannot have more than one action that maps DSCP.
character definition
+ Indicates that the policy rule has been modified or has
been created since the last qos apply.
- Indicates the policy object is pending deletion.
# Indicates that the policy object differs between the pend-
ing/applied objects.
In the example here, a new map group, tosGroup, has not yet been applied to the configuration.
-> show policy map group
Group Name From Entries
+tosGroup cli 1-2:5
4:5
5-6:7
When the qos apply command is entered, the plus sign (+) is removed from tosGroup in the display. See
“Applying the Configuration” on page 39-62 for more information about the qos apply command.
The qos apply command must be included in an ASCII text configuration file when QoS commands are
included. The command must be included after the last QoS command.
When the configuration is not yet applied, it is referred to as the pending configuration.
Global Commands. Many global QoS commands are active immediately on the switch without qos
apply. The settings configured by these commands become active immediately. Other global commands
must be applied. The commands are listed in the following table:
Port and Policy Commands. All port parameters and policy parameters must be applied with the qos
apply command.
The pending configuration is useful for reviewing policy rules before actually applying them to the switch.
The show policy classify commands can be used to review information about new conditions before they
are applied on the switch. See “Testing Conditions” on page 39-46.
Applied policy rules can also be administratively disabled (inactive). If a rule is administratively disabled,
the rule exists in the applied configuration but not used to classify flows. For more information about
disabling/re-enabling a policy rule, see “Creating Policy Rules” on page 39-37.
This command ignores any pending policies (any additions, modifications, or deletions to the policy
configuration since the last qos apply) and writes the last applied policies to the pending configuration. At
this point, the pending policies are the same as the last applied policies.
In this example, there are two new pending policies and three applied policies:
In this scenario, you can do one of two things. To write the applied policies back to the pending
configuration, use qos revert. Or, to delete all policy rule configuration, enter qos apply. If qos apply is
entered, the empty set of pending policies are written to the applied policies and all policy rule
configuration is deleted.
show policy condition Displays information about all pending and applied policy conditions or
a particular policy condition configured on the switch. Use the applied
keyword to display information about applied conditions only.
show policy action Displays information about all pending and applied policy actions or a
particular policy action configured on the switch. Use the applied
keyword to display information about applied actions only.
show policy rule Displays information about all pending and applied policy rules or a
particular policy rule. Use the applied keyword to display information
about applied rules only.
show policy network group Displays information about all pending and applied policy network
groups or a particular network group. Use the applied keyword to
display information about applied groups only.
show policy service Displays information about all pending and applied policy services or a
particular policy service configured on the switch. Use the applied
keyword to display information about applied services only.
show policy service group Displays information about all pending and applied policy service
groups or a particular service group. Use the applied keyword to display
information about applied groups only.
show policy mac group Displays information about all pending and applied MAC groups or a
particular policy MAC group configured on the switch. Use the applied
keyword to display information about applied groups only.
show policy port group Displays information about all pending and applied policy port groups
or a particular port group. Use the applied keyword to display
information about applied groups only.
show policy vlan group Displays information about pending and applied policy VLAN groups.
Use the applied keyword to display information about applied groups
only.
show policy map group Displays information about all pending and applied policy map groups
or a particular map group. Use the applied keyword to display
information about applied groups only.
show policy classify Sends Layer 2, Layer 3, or multicast information to the classifier to see
how the switch handles the packet. Use the applied keyword to examine
only applied conditions.
For more information about these commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Policy Applications
Policies are used to classify incoming flows and treat the relevant outgoing flows. There are many ways to
classify the traffic and many ways to apply QoS parameters to the traffic.
Classifying traffic can be as simple as identifying a Layer 2 or Layer 3 address of an incoming flow.
Treating the traffic can involve prioritizing the traffic or rewriting an IP address. How the traffic is treated
(the action in the policy rule) typically defines the type of policy:
Note. The redirection policies, policy based mirroring, and policy based routing (PBR) are not
supported by egress policies.
This section describes how to configure basic QoS policies and 802.1p/ToS/DSCP marking and mapping
policies. Policies used for Layer 2 and Layer 3/4 filters, are commonly referred to as Access Control Lists
(ACLs). Filtering is discussed in Chapter 40, “Configuring ACLs.”
Policies can also be used for prioritizing traffic in dynamic link aggregation groups. For more information
about dynamic link aggregates, see Chapter 26, “Configuring Dynamic Link Aggregation.”
OmniSwitch
ingress flow
queues for egress traffic
policy condition
classifies the flow
policy action determines
how packets are queued
Note. To configure same priority for multiple addresses, services, or ports, use a policy condition group to
specify the group and associate the group with the condition. See “Using Condition Groups in Policies” on
page 39-48 for more information about groups.
Some condition parameters can be used in combination only under particular circumstances; also, there are
restrictions on condition/action parameter combinations. See “Using Condition Groups in Policies” on
page 39-48 and “Condition Combinations” on page 39-7.
Basic Commands
The following policy action commands are used for traffic prioritization or shaping:
policy action priority
policy action maximum bandwidth
To set up traffic prioritization and/or bandwidth shaping, follow the steps in the next section. For more
information about command syntax and options, see the OmniSwitch 6250/6350/6450 CLI Reference
Guide.
QoS ports can also be configured for bandwidth shaping through the qos port commands.
OmniSwitch
Network 1 Any
10.10.4.0 Network
priority applied
To create a policy rule to prioritize the traffic from Network 1, first create a condition for the traffic that
you want to prioritize. In this example, the condition is called ip_traffic. Then create an action to
prioritize the traffic as highest priority. In this example, the action is called high. Combine the condition
and the action into a policy rule called rule1.
-> policy condition ip_traffic source ip 10.10.4.0 mask 255.255.255.0
-> policy action high priority 7
-> policy rule rule1 condition ip_traffic action high
The rule is not active on the switch until the qos apply command is entered on the command line. When
the rule is activated, any flows coming into the switch from 10.10.4.0 is given the highest priority.
Tri-Color Marking
This implementation of a Tri-Color Marking (TCM) provides a mechanism for policing network traffic by
limiting the rate at which traffic is sent or received on a switch interface. The TCM policier meters traffic
based on user-configured packet rates and burst sizes and then marks the metered packets as green,
yellow, or red based on the metering results.
The following diagram illustrates the basic operation of TCM:
The TCM policier meters each packet and passes the metering result along with the packet to the Marker.
Depending upon the result sent by the Meter, the packet is then marked with either the green, yellow, or
red color. The marked packet stream is then transmitted on the egress based on the color-coded priority
assigned.
The TCM Meter operates in Color-Blind mode (the Color-Aware mode is not supported). In the
Color-Blind mode, the Meter assumes that the incoming packet stream is uncolored.
There are two types of TCM marking supported:
• Single-Rate TCM (srTCM)—Packets are marked based on a Committed Information Rate (CIR) value
and two associated burst size values: Committed Burst Size (CBS) and Peak Burst Size (PBS).
• Two-Rate TCM (trTCM)—Packets are marked based on a CIR value and a Peak Information Rate
(PIR) value and two associated burst size values: CBS and PBS.
Both srTCM and trTCM operate in the same basic manner, as shown in the above diagram. The main
difference between the two types is that srTCM uses one rate limiting value (CIR) and trTCM uses two
rate limiting values (CIR and PIR) to determine packet marking.
The type of TCM used is determined when the policier is configured; depending on which rates and burst
size values are configured, TCM functions in ether single-rate or two-rate mode. There is no explicit
command to select the type of TCM. See “Configuring TCM Policies” on page 39-68 for more
information.
Based on the TCM type used, packets are marked as follows:
For information about configuring these parameters for a VLAN Stacking SAP profile, see the
“Configuring VLAN Stacking” chapter in this guide.
To configure a TCM QoS policy action, use the show policy classify command with one or more of the
above parameters. Configuring the cbs and pbs parameters is optional. If a value is not specified for either
one, the default value is used for both parameters. For example:
-> policy action A1 cir 10M
To specify one or both of the burst size values, use the cbs and pbs parameters. For example:
All of the above command examples configure the TCM meter to operate in the Single-Rate TCM
(srTCM) mode. To configure the meter to operate in the Two-Rate TCM (trTCM) mode, use the pir
parameter and specify a peak information rate value that is greater than the committed information rate
value. For example, the following commands configure the meter to use the trTCM mode:
The policy action has a no command to remove the CIR, CBS, PIR, PBS information.To remove the TCM
configuration from a QoS policy action, use the no form of the policy action cir command. For example:
-> policy action A6 no cir
The rates and burst sizes can be specified in abbreviated units, in this case, 10m.
The rule is not active on the switch until the qos apply command is entered. When the rule is activated,
any flows coming into the switch from source IP address 10.10.5.3 are metered and marked
according to the TCM policier parameters specified in the tcm1 policy action.
Redirection Policies
A redirection policy sends traffic that matches the policy to a specific port or link aggregate instead of the
originally intended destination. This type of policy can use any condition; the policy action determines
which port or link aggregate to which the traffic is sent.
The following policy action commands are used for port and link aggregate redirection:
policy action redirect port
policy action redirect linkagg
Redirection policies apply to bridged traffic. When redirecting traffic on VLAN A, the redirect port or link
aggregate ID must belong to VLAN A (tagged or default VLAN). In other words, the ingress port and
redirect port must both reside in the same VLAN.
Note the following regarding the use and configuration of redirection policies:
• Redirection policies apply to both bridged and routed traffic.
• When redirecting routed traffic from VLAN A to VLAN B, the redirect port or link aggregate ID
must belong to VLAN A (tagged or default VLAN).
• Routed packets (from VLAN A to VLAN B) are not modified after they are redirected; the source and
MAC address remain the same. In addition, if the redirect port or link aggregate ID is tagged, the
redirected packets have a tag from the ingress VLAN A.
• If a route exists for the redirected flow, then redirected packets are the final post-routing packets.
• If a route does not exist for the redirected flow, the flow is not redirected to the specified port or link
aggregate ID and is “blackholed”. As soon as a route is available, the flow is then redirected as
specified in the policy.
In most cases, a redirected flow will not trigger an update to the routing and ARP tables. When the ARP
table is cleared or timed out, port/link aggregate redirection will cease until the ARP table is refreshed. If
necessary, create a static route for the flow or assign the redirect port or link aggregate ID to the ingress
VLAN (VLAN A) to send packets to the redirect port until a route is available.
In the following example, flows destined for UDP port 80 is redirected to switch port 3/2:
-> policy condition L4PORTCOND destination udp port 80
-> policy action REDIRECTPORT redirect port 3/2
-> policy rule L4PORTRULE condition L4PORTCOND action REDIRECTPORT
In the following example, flows destined for IP address 40.2.70.200 are redirected to link aggregate 10:
-> policy condition L4LACOND destination IP 40.2.70.200
-> policy action REDIRECTLA redirect linkagg 10
-> policy rule L4LARULE condition L4LACOND action REDIRECTLA
In both examples above, the rules are not active on the switch until the qos apply command is entered on
the command line.
Policy-Based Mirroring
A mirroring policy sends a copy of ingress packets that match the policy condition to a specific port. This
type of policy can use any condition; the mirror policy action determines the type of traffic to mirror and
the port on which the mirrored traffic is received.
The policy action mirror command is used to configure mirror-to-port (MTP) action for the policy. For
example, the following policy mirrors ingress packets to port 1/10:
-> policy condition c1 source ip 192.168.20.1
-> policy action a1 mirror ingress 1/10
-> policy rule r1 condition c1 action a1
-> qos apply
When the above rule is activated, flows coming into the switch from source IP address 192.168.20.1 are
mirrored to port 1/10. For example:
-> policy condition c1 source ip 192.168.20.1
-> policy action a1 mirror ingress 1/10 disposition deny
-> policy rule r1 condition c1 action a1
-> qos apply
This policy rule example combines the MTP action with the deny action. As a result, this rule denies
ingress traffic with a source IP of 192.168.20.1, but the mirrored traffic from this source is not dropped
and is forwarded to port 1/10.
Note the following regarding the use and configuration of mirroring policies:
• The policy source and destination ports must reside on different NI modules. Mirroring policies with
the source and destination port on the same module are not supported.
• Only ingress policy-based mirroring is supported.
• Only one policy-based MTP session is supported at any given time. As a result, all mirroring policies
must specify the same destination port.
• In addition to one policy-based MTP session, the switch can support one port-based mirroring session,
one remote port mirroring (RPM) session, and one-port monitoring session all running at the same
time.
• If a packet qualifies for a policy-based MTP session and a port-based mirroring session (including
remote port mirroring), the packet is copied to the destination port for both sessions.
• Policy-based mirroring and the port-based mirroring feature can run simultaneously on the same port.
• Rule precedence is applied to all mirroring policies that are configured for the same switch ASIC. If
traffic matches a mirror rule on one ASIC with a lower precedence than a non-mirroring rule on a
different ASIC, the traffic is mirrored in addition to the actions specified by the higher precedence rule.
• Control PDUs are not mirrored.
This policy (icmpRule) drops all ICMP traffic. To limit the dropped traffic to ICMP echo requests (pings)
and/or replies, use the policy condition icmptype to specify the appropriate condition. For example,
-> policy condition echo icmptype 8
-> policy condition reply icmptype 0
In the next example, the policy map group command specifies a group of values that must be mapped; the
policy action map command specifies what must be mapped (802.1p to 802.1p, ToS/DSCP to 802.1p) and
the mapping group that must be used. For more details about creating map groups, see “Creating Map
Groups” on page 39-60.
Here, traffic from two different subnets must be mapped to 802.1p values in a network called Network C.
A map group (tosGroup) is created with mapping values.
The map_action specifies that ToS values are mapped to 802.1p with the values specified in tos_group.
With these conditions and action set up, two-policy rules can be configured for mapping Subnet A and
Subnet B to the ToS network:
-> policy rule RuleA condition SubnetA action map_action
-> policy rule RuleB condition SubnetB action map_action
Subnet A
10.10.5.0 OmniSwitch
Network C
Mapping
Subnet B policy
12.12.2.0
Mapping Application
Policy-Based Routing
Policy-Based Routing (PBR) allows a network administrator to define QoS policies that overrides the
normal routing mechanism for traffic matching the policy condition.
Note. When a PBR QoS rule is applied to the configuration, it is applied to the entire switch, unless you
specify a built-in port group in the policy condition.
Policy-Based Routing can be used to redirect traffic to a particular gateway based on source or destination
IP address, source or destination network group, source or destination TCP/UDP port, a service or service
group, IP protocol, or built-in source port group.
Traffic can be redirected to a particular gateway regardless of what routes are listed in the routing table.
The gateway address does not have to be on a directly connected VLAN; the address can be on any
network that is learned by the switch.
Note. If the routing table has a default route of 0.0.0.0, traffic matching a PBR policy is redirected to the
route specified in the policy. For information about viewing the routing table, see
Chapter 28, “Configuring IP.”
Policy-Based Routing can be used to redirect untrusted traffic to a firewall. In this case, reply packets are
not allowed back through the firewall.
174.26.1.0
173.10.2.0
10.3.0.0
Firewall
173.5.1.0
173.5.1.254
OmniSwitch
In this example, all traffic originating in the 10.3 network is routed through the firewall, regardless of
whether a route exists.
-> policy condition Traffic3 source ip 10.3.0.0 mask 255.255.0.0
-> policy action Firewall permanent gateway ip 173.5.1.254
-> policy rule Redirect_All condition Traffic3 action Firewall
The functionality of the firewall is important. In the example, the firewall is sending the traffic to be
routed remotely. Instead, if you set up a firewall to send the traffic back to the switch to be routed, set up
the policy condition with a built-in source port group so that traffic coming back from the firewall does not
get looped and is sent back to the firewall.
For example:
174.26.1.0
173.10.2.0
10.3.0.0
Firewall
173.5.1.0
173.5.1.254
OmniSwitch
In this scenario, traffic from the firewall is sent back to the switch to be rerouted. But because the traffic
re-enters the switch through a port that is not in the Slot01 port group, the traffic does not match the Redi-
rect_All policy and is routed normally through the switch.
-> policy condition Traffic3 source ip 10.3.0.0 mask 255.255.0.0 source port
group Slot01
-> policy action Firewall permanent gateway ip 173.5.1.254
-> policy rule Redirect_All condition Traffic3 action Firewall
Ensure to use the qos apply command to activate the policy rule on the switch. Otherwise, the rule is
saved as a part of the pending configuration. However this rule is not activated.
Access Control Lists (ACLs) are Quality of Service (QoS) policies used to control whether or not packets
are allowed or denied at the switch or router interface. ACLs are sometimes referred to as filtering lists.
ACLs are distinguished by the kind of traffic they filter. In a QoS policy rule, the type of traffic is speci-
fied in the policy condition. The policy action determines whether the traffic is allowed or denied. For
detailed descriptions about configuring policy rules, see Chapter 39, “Configuring QoS.”
In general, the types of ACLs include:
• Layer 2 ACLs—for filtering traffic at the MAC layer. Usually uses MAC addresses or MAC groups for
filtering.
• Layer 3/4 ACLs—for filtering traffic at the network layer. Typically uses IP addresses or IP ports for
filtering.
• Multicast ACLs—for filtering IGMP traffic.
In This Chapter
This chapter describes ACLs and how to configure them through the Command Line Interface (CLI). CLI
commands are used in the configuration examples; for more details about the syntax of commands, see the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Setting the Global Disposition. The disposition specifies the general allow/deny policy on the switch.
See “Setting the Global Disposition” on page 40-7.
• Creating Condition Groups for ACLs. Groups are used for filtering on multiple addresses, ports, or
services. The group is then associated with the policy condition. See “Creating Condition Groups For
ACLs” on page 40-8.
• Creating Policy Rules for ACLs. Policy rules for ACLs are basically QoS policy rules. Specific
parameters for ACLs are described in this chapter. See “Configuring ACLs” on page 40-8.
• Using ACL Security Features. Specific port group, action, service group, and policy rule combina-
tions are provided to help improve network security. See “Using ACL Security Features” on
page 40-15.
Note. ACLs may also be created on an external LDAP server through a network management application
such as PolicyView and downloaded to the switch. For information about managing rules on an LDAP
server, see Chapter 2, “Managing Policy Servers.”
ACL Specifications
The QoS/ACL functionality described in this chapter is supported on the OmniSwitch 6250 and OmniS-
witch 6450. Note that any maximum limits provided in the Specifications table are subject to
available system resources.
ACL Defaults
The following table shows the defaults for ACLs:
Note that in the current software release, the deny and drop options produce the same effect; that is, that
traffic is silently dropped.
For more information about QoS defaults in general, see Chapter 39, “Configuring QoS.”
2 Create policy condition groups for multiple addresses or services that you want to filter. (If you have a
single address to filter, you can skip this step and simply include the address, service, or port in the policy
condition.) An example:
-> policy network group NetGroup1 192.68.82.0 mask 255.255.255.0 192.60.83.0
mask 255.255.255.0
3 Create a policy condition using the policy condition command. If you created a network group, MAC
group, service group, or port group, specify the group as part of the condition.
-> policy condition Lab3 source network group NetGroup1
Note. (Optional) Test the condition with the show policy classify command using information from the
policy condition. For example:
-> show policy classify l3 source ip 192.68.82.0
This command displays information about whether the indicated parameter may be used to classify traffic
based on policies that are configured on the switch. For more information about testing conditions, see
“Testing Conditions” on page 39-46 in Chapter 39, “Configuring QoS.”
4 Create a policy action with the policy action command. Use the keyword disposition and indicate
whether the flow(s) should be accepted or denied.
-> policy action Yes disposition accept
5 Create a policy rule with the policy rule command and include the relevant condition and action. Use
the keyword precedence to specify the priority of this rule over other rules for traffic matching the speci-
fied condition.
-> policy rule lab_rule1 condition Lab3 action Yes precedence 65535
6 Apply the policy configuration using the qos apply command. For details about using this command,
see “Applying the Configuration” on page 39-62 in Chapter 39, “Configuring QoS.”
ACL Overview
ACLs provide moderate security between networks. The following illustration shows how ACLs may be
used to filter subnetwork traffic through a private network, functioning like an internal firewall for LANs.
OmniSwitch
Subnetwork
Router
Private
Network Public
Network
Filtering Rules
Subnetwork
(ACLs)
Subnetwork
OmniSwitch
When traffic arrives on the switch, the switch checks its policy database to attempt to match Layer 2 or
Layer 3/4 information in the protocol header to a filtering policy rule. If a match is found, it applies the
relevant disposition to the flow. Disposition determines whether a flow is allowed or denied. There is a
global disposition (the default is accept), and individual rules may be set up with their own dispositions.
Note. In some network situations, it is recommended that the global disposition be set to deny, and that
rules be created to allow certain types of traffic through the switch. To set the global disposition to deny,
use the qos default bridged disposition and qos default multicast disposition command. See “Setting
the Global Disposition” on page 40-7 for more information about these commands.
When multiple policy rules exist for a particular flow, each policy is applied to the flow as long as there
are no conflicts between the policies. If there is a conflict, then the policy with the highest precedence is
applied to the flow. See “Rule Precedence” on page 40-6 for more information about precedence.
Note. QoS policy rules may also be used for traffic prioritization and other network scenarios. For a
general discussion of QoS policy rules, see Chapter 39, “Configuring QoS.”
Rule Precedence
The switch attempts to classify flows coming into the switch according to policy precedence. Only the rule
with the highest precedence will be applied to the flow. This is true even if the flow matches more than
one rule.
Valid Combinations
There are limitations to the types of policy conditions and actions that may be combined in a single rule.
For more information about supported combinations, see “Condition Combinations” on page 39-7 and
“Action Combinations” on page 39-9 in Chapter 39, “Configuring QoS.”
1 Set the global disposition. This step is described in “Setting the Global Disposition” on page 40-7.
2 Create a condition for the traffic to be filtered. This step is described in “Creating Condition Groups
For ACLs” on page 40-8 and “Creating Policy Conditions For ACLs” on page 40-9.
3 Create an action to accept or deny the traffic. This step is described in “Creating Policy Actions For
ACLs” on page 40-10.
4 Create a policy rule that combines the condition and the action. This step is described in “Creating
Policy Rules for ACLs” on page 40-10.
For a quick tutorial on how to configure ACLs, see “Quick Steps for Creating ACLs” on page 40-4.
Note. Note that the global disposition setting applies to all policy rules on the switch, not just those that
are configured for ACLs.
Important. If you set the global bridged disposition (using the qos default bridged disposition
command) to deny or drop, it will result in dropping all Layer 2 traffic from the switch that does not
match any policy to accept traffic. You must create policies (one for source and one for destination) to
allow traffic on the switch.
If you set the bridged disposition to deny or drop, and you configure Layer 2 ACLs, you will need two
rules for each type of filter. For more information, see “Layer 2 ACLs” on page 40-11.
This command configures a network group (netgroup2) of three IP addresses. The network group is then
configured as part of a policy condition (cond2). The condition specifies that the addresses in the group
are source addresses. (For all condition groups except service groups, the policy condition specifies
whether the condition group is a source or destination group.)
If a network group was not used, a separate condition would have to be created for each IP address. Subse-
quently, a corresponding rule would have to be created for each condition. Using a network group reduces
the number of rules required.
For more details about using groups in policy conditions, see “Using Condition Groups in Policies” on
page 39-48 in Chapter 39, “Configuring QoS.”
Configuring ACLs
This section describes in detail the procedures for configuring ACLs. For more information about how to
configure policies in general, see Chapter 39, “Configuring QoS.” Command syntax is described in detail
in the OmniSwitch 6250/6350/6450 CLI Reference Guide.
The basic commands for configuring ACL rules are the same as those for configuring policy rules:
policy condition
policy action
policy rule
In this example, a Layer 2 condition (c2) specifies that traffic matches the ports included of the pgroup1
port group. The condition also specifies that the port group is a source group. Any traffic coming in on
ports 1 or 2 on slot 3, port 3 on slot 4, or port 4 on slot 5 will match condition c2.
For more information about condition groups, see “Creating Condition Groups For ACLs” on page 40-8.
The following table lists the keywords for the policy condition command that are typically used for the
different types of ACLs:
Layer 2 ACL Condition Layer 3/4 ACL Condition Multicast ACL Condition
Keywords Keywords Keywords
source mac source ip multicast ip
source mac group source ipv6 multicast ipv6
destination mac source network group multicast network group
destination mac group destination ip destination ip
source vlan destination ipv6 destination vlan
source vlan group destination network group destination port
source port source ip port destination port group
source port group destination ip port destination mac
ethertype service destination mac group
802.1p service group
ip protocol
ipv6
icmptype
icmpcode
tos
dscp
source tcp port
destination tcp port
source udp port
destination udp port
established
tcpflags
Note that the individual address, service, or port cannot be used in conjunction with the same type of
condition group. For example, you cannot specify in the same rule both a source MAC address and a
source MAC group.
If you do not specify a disposition for the policy action, the default (accept) will be used.
In this example, any traffic matching condition c3 will match rule7; rule7 is configured with the highest
precedence value. If any other rules are configured for traffic with a source address of 10.10.4.8, rule7
will take precedence over the other rules only if one of the following is true:
• A conflict exists with another rule and rule7 has a higher precedence.
• A conflict exists with another rule that has the same precedence value, but rule7 was created first.
The action configured for the rule, a1, allows traffic from 10.10.4.8, so the flow will be accepted on the
switch.
The rule will not be used to classify traffic or enforce the policy until the qos apply command is entered.
For information about applying policy parameters, see “Applying the Configuration” on page 39-62 in
Chapter 39, “Configuring QoS.”
Layer 2 ACLs
Layer 2 filtering filters traffic at the MAC layer. Layer 2 filtering may be done for both bridged and routed
packets. As MAC addresses are learned on the switch, QoS classifies the traffic based on:
• MAC address or MAC group
• Source VLAN
• Physical slot/port or port group
The switch classifies the MAC address as both source and destination.
The following policy condition keywords are used for Layer 2 ACLs:
A group and an individual item cannot be specified in the same condition. For example, a source MAC
address and a source MAC group cannot be specified in the same condition.
Note that combining Layer 2 and Layer 3 conditions in the same policy is supported. Refer to “Condition
Combinations” on page 39-7 and “Action Combinations” on page 39-9 in Chapter 39, “Configuring QoS.”
In this scenario, traffic with a source MAC address of 08:00:20:11:22:33 coming in on VLAN 5 would
match condition Address1, which is a condition for a policy rule called FilterA. FilterA is then applied to
the flow. Since FilterA has an action (BlockTraffic) that is set to deny traffic, the flow would be denied
on the switch.
Note that although this example contains only Layer 2 conditions, it is possible to combine Layer 2 and
Layer 3 conditions in the same policy.
Layer 3 ACLs
The QoS software in the switch filters routed and bridged traffic at Layer 3.
For Layer 3 filtering, the QoS software in the switch classifies traffic based on:
• Source IP address or source network group
• Destination IP address or destination network group
• IP protocol
• ICMP code
• ICMP type
• Source TCP/UDP port
• Destination TCP/UDP port or service or service group
The following policy condition keywords are used for Layer 3 ACLs:
Note that combining Layer 2 and Layer 3 conditions in the same policy is supported. Refer to “Condition
Combinations” on page 39-7 and “Action Combinations” on page 39-9 in Chapter 39, “Configuring QoS.”
Traffic with a source IP address of 192.68.82.0, a source IP port of 23, using protocol 6, will match condi-
tion addr2, which is part of FilterL31. The action for the filter (Block) is set to deny traffic. The flow will
be dropped on the switch.
Note that although this example contains only Layer 2 conditions, it is possible to combine Layer 2 and
Layer 3 conditions in the same policy.
In this example, a network group, GroupA, is configured with three IP addresses. Condition cond7
includes GroupA as a destination group. Flows coming into the switch destined for any of the specified IP
addresses in the group will match rule FilterL32. FilterL32 is configured with an action (Ok) to allow the
traffic on the switch.
Note that although this example contains only Layer 2 conditions, it is possible to combine Layer 2 and
Layer 3 conditions in the same policy.
IPv6 ACLs
An ACL is considered an IPv6 ACL if the ipv6 keyword and/or any of the following specific policy condi-
tion keywords are used in the ACL to classify/filter IPv6 traffic:
Note that IPv6 ACLs are effected only on IPv6 traffic. All other ACLs/policies with IP conditions that do
not use the IPv6 keyword are effected only on IPv4 traffic. For example:
-> policy condition c1 tos 7
In the above example, c1 is an IPv4 condition and c2 is an IPv6 condition. ACLs that use c1 are consid-
ered IPv4 policies; ACLs that use c2 are considered IPv6 policies. In addition, consider the following
examples:
-> policy condition c3 source port 1/10
Condition c3 applies to all traffic ingressing on port 1/10. However, condition c4 applies only to IPv6 traf-
fic ingressing on port 1/10.
Note the following when configuring IPv6 ACLs:
• Trusted/untrusted behavior is the same for IPv6 traffic as it is for IPv4 traffic.
• IPv6 policies do not support the use of network groups, service groups, map groups, or MAC groups.
• IPv6 multicast policies are not supported.
• IPv6 policies are not supported by egress policy conditions.
If a destination group is specified, the corresponding single value keyword cannot be combined in the
same condition. For example, if a destination port is specified, a destination port group cannot be speci-
fied in the same condition.
To filter multicast clients, specify the multicast IP address, which is the address of the multicast group or
stream, and specify the client IP address, VLAN, MAC address, or slot/port. For example:
-> qos default multicast disposition deny
-> policy condition Mclient1 multicast ip 224.0.1.2 destination vlan 5
-> policy action ok disposition accept
-> policy rule Mrule condition Mclient1 action ok
In this example, any traffic coming in on VLAN 5 requesting membership to the 224.0.1.2 multicast group
will be allowed.
Note that the UserPorts group applies to both bridged and routed traffic, and it is not necessary to include
the UserPorts group in a condition and/or rule for the group to take effect. Once ports are designated as
members of this group, IP spoofed traffic is blocked while normal traffic is still allowed on the port.
The UserPorts group is also used in conjunction with the DropServices group. If a flow received on a port
that is a member of the UserPorts group is destined for a TCP or UDP port (service) specified in the Drop-
Services group, the flow is dropped. See “Configuring a DropServices Group” on page 40-17 for more
information.
To specify multiple types of traffic on the same command line, enter each type separated by a space. For
example:
-> qos user-port filter bdpu rip
Note that a slot and port is not required with the qos user-port command. This is because the command
applies to all ports that are members of the UserPorts group.
The following qos user-port command example uses the shutdown option to administratively disable the
user port if the specified type of traffic is received on that port:
-> qos user-port shutdown bpdu
Note that an SNMP trap is sent whenever a user port shutdown occurs. To enable a port disabled by a user
port shutdown operation, use the interfaces admin command to administratively enable the port or
disconnect and reconnect the port cable.
To disable the filter or shutdown function, use the no form of the qos user-port command. For example,
the following command disables the filtering operation for all user ports:
-> qos no user-port filter
Note that any changes to the UserPorts profile (e.g., adding or removing a traffic type) are not made until
the qos apply command is performed.
2 Add the services created in Step 1 to a service group called DropServices using the policy service
group command, as shown below:
-> policy service group DropServices tcp135 tcp445 udp137 udp138 udp445
Note that the DropServices group must be specified using the exact capitalization as shown in the
above example.
3 Add ports to the port group called UserPorts using the policy port group command, as shown below:
Note that the UserPorts group must be specified using the exact capitalization as shown in the above
example.
When the above steps are performed, an implicit ACL is created on the switch that applies to all VLANs.
This internal ACL takes precedence over any other policies configured on the switch.
Note that the above policy only blocks ICMP echo traffic, all other ICMP traffic is still allowed.
This example ACL policy will prevent any TCP connection from being initiated to the 192.168.10.0
network and all other IP traffic to the 192.168.10.0 network. Only TCP connections initiated from the
192.168.10.0 network are allowed.
Note that the above example ACL would prevent FTP sessions. See the policy condition established
command page in the OmniSwitch 6250/6350/6450 CLI Reference Guide for more information.
An ACL can also be defined using the tcpflags parameter to examine and qualify specific TCP flags indi-
vidually or in combination with other flags. This parameter can be used to prevent specific DOS attacks,
such as the christmas tree.
The following example use the tcpflags condition parameter to determine if the F (fin) and S (syn) TCP
flag bits are set to one and the A (ack) bit is set to zero:
-> policy condition c1 tcpflags all f s mask f s a
In this example, a match must occur on all the flags or the packet is not allowed. If the optional command
keyword any was used, then a match need only occur on any one of the flags. For example, the following
condition specifies that either the A (ack) bit or the R (rst) bit must equal one:
-> policy condition c1 tcpflags any a r mask a r
Note that if a flag is specified on the command line after the any or all keyword, then the match value is
one. If the flag only appears as part of the mask, then the match value is zero. See the policy condition
tcpflags command page in the OmniSwitch 6250/6350/6450 CLI Reference Guide for more information.
show policy list Displays information about all pending and applied policy conditions or
a particular policy condition configured on the switch. Use the applied
keyword to display information about applied conditions only.
show policy action Displays information about all pending and applied policy actions or a
particular policy action configured on the switch. Use the applied key-
word to display information about applied actions only.
show active policy rule meter- Displays information about all pending and applied policy rules or a par-
statistics ticular policy rule.
show active policy list Displays the pending and applied policy rules that are active (enabled)
on the switch.
show qos config Displays global QoS configuration parameters.
When a show command is used to display output for all pending and applied policy configuration, the
following characters may appear in the display:
character definition
+ Indicates that the policy rule has been modified or has
been created since the last qos apply.
- Indicates the policy object is pending deletion.
# Indicates that the policy object differs between the pend-
ing/applied objects.
The following example shows all policy rules configured on the switch:
The display indicates that my_rule is active and is used to classify traffic on the switch (the Act field
displays Yes). The rule my_rule5 has been configured since the last qos apply command was entered, as
indicated by the plus (+) sign. The rule will not be used to classify traffic until the next qos apply. The
rule mac1 is not active, as indicated by the No in the Act field.
To display only policy rules that are active (enabled) on the switch, use the show active policy rule
command, as shown in the following example:
In this example, the rule my_rule does not display because it is inactive. Rules are inactive if they are
administratively disabled through the policy rule command, or if the rule cannot be enforced by the
current hardware. Both my_rule5 and mac1 are displayed here because they are active; however,
my_rule5 is a pending rule and will not be used to classify traffic until the qos apply command is entered.
See the OmniSwitch 6250/6350/6450 CLI Reference Guide for more information about the output of these
commands.
OmniSwitch
Set up a policy rule called outside to deny Telnet traffic to the private network.
1 Create a policy service (traffic_in) for traffic originating from the well-known Telnet port number 23.
4 Then combine the condition and the action in a policy rule (outside).
An example of what these commands look like together on consecutive command lines:
-> policy service traffic_in source ip port 23 protocol 6
-> policy condition outside_cond service traffic_in
-> policy action outside_action disposition drop
-> policy rule outside condition outside_cond action outside_action
In This Chapter
This chapter describes the basic components of IPMS and how to configure them through the Command
Line Interface (CLI). CLI commands are used in the configuration examples; for more details about the
syntax of commands, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Enabling and disabling IP Multicast Switching on page 41-8.
• Enabling and disabling IP Multicast Dynamic Control on page 41-9
• Configuring and removing an IGMP static neighbor on page 41-11.
• Configuring and removing an IGMP static querier on page 41-12.
• Configuring and removing an IGMP static group on page 41-13.
• Modifying IPMS parameters beginning on page 41-14.
• Enabling and disabling IPv6 Multicast Switching on page 41-24.
• Configuring and removing an MLD static neighbor on page 41-26.
• Configuring and removing an MLD static querier on page 41-27.
• Configuring and removing an MLD static group on page 41-27.
Note. You can also configure and monitor IPMS with WebView, Alcatel embedded Web-based device
management application. WebView is an interactive and easy-to-use GUI that can be launched from
OmniVista or a Web browser. Please refer to WebView online documentation for more information on
configuring and monitoring IPMS/IPMSv6 with WebView.
IPMS Specifications
The table below lists specifications for Alcatel IPMS software.
IPMSv6 Specifications
The table below lists specifications for Alcatel IPMSv6 software.
IPMS Overview
A multicast group is defined by a multicast group address, which is a Class D IP address in the range
224.0.0.0 to 239.255.255.255. (Addresses in the range 239.0.0.0 to 239.255.255.255 are reserved for
boundaries.) The multicast group address is indicated in the destination address field of the IP header.
(See “Reserved IP Multicast Addresses” on page 41-7 for more information.)
IPMS tracks the source VLAN on which the Internet Group Management Protocol (IGMP) requests are
received. The network interfaces verify that a multicast packet is received by the switch on the source (or
expected) port.
IPMS Example
The figure on the following page shows an IPMS network where video content can be provided to clients
that request it. A server is attached to the switch that provides the source (multicast) IP addresses. Clients
from two different attached networks send IGMP reports to the switch to receive the video content.
OmniSwitch
Video
Source Port
Multicast Group
(dynamically built)
Multicast Stream
(destination IP address)
Multicast Server
Ports on end stations send (source IP address)
IGMP requests to receive
multicast traffic.
Network A
Network B
Note. See the “IP Multicast Switching Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Refer-
ence Guide for complete documentation of IPMS CLI commands.
Note. If IP Multicast switching is enabled on the system, the VLAN configuration overrides the system
configuration.
You can also enable IP Multicast switching on the specified VLAN by entering:
-> ip multicast vlan 2 status enable
You can also disable IP Multicast switching on the specified VLAN by entering:
-> ip multicast vlan 2 status disable
Note. This feature should not be enabled if routing protocol or VRRP is configured on the switch.
You can also enable the IGMP querier-forwarding on the specified VLAN by entering:
-> ip multicast vlan 2 querier-forwarding enable
You can also change the IGMP protocol version on the specified VLAN by entering:
-> ip multicast vlan 5 version 1
Note. The IGMS implementation frame (join/leave report & query) now supports multiple tagging of up to
8 VLAN tags in the frame.
The following subsections describe how to configure and remove a IGMP static neighbor port by using the
ip multicast static-neighbor command.
You can also configure a link aggregation group as an IGMP static neighbor port by entering
ip multicast static-neighbor followed by vlan, a space, VLAN number (which must be between 0 and
4095), a space, followed by port, a space, and the link aggregation group number.
For example, to configure link aggregation group 7 with designated VLAN 2 as a static neighbor enter:
-> ip multicast static-neighbor vlan 2 port 7
You can also configure a link aggregation group as an IGMP static querier port by entering ip multicast
static-querier followed by vlan, a space, VLAN number (which must be between 0 and 4095), a space,
followed by port, a space, and the link aggregation group number.
For example, to configure link aggregation group 7 with designated VLAN 2 as a static querier, enter:
-> ip multicast static-querier vlan 2 port 7
You can also configure a link aggregation group as an IPMS static group by entering
ip multicast static-group followed by vlan, a space, VLAN number (which must be between 0 and 4095),
a space, followed by port, a space, and the link aggregation group number.
For example, to configure link aggregation group 7 with designated VLAN 2 as a static group, enter:
-> ip multicast static-group 225.0.0.2 vlan 2 port 7
You can also modify the IGMP query interval on the specified VLAN by entering:
-> ip multicast vlan 2 query-interval 60
You can also modify the IGMP last member query interval on the specified VLAN by entering:
-> ip multicast vlan 3 last-member-query-interval 60
To restore the IGMP last member query interval to its default value.
You can also restore the IGMP last member query interval on the specified VLAN by entering:
-> ip multicast vlan 2 last-member-query-interval 0
To restore the IGMP last member query interval to its default value.
You can also modify the IGMP query response interval on the specified VLAN by entering:
-> ip multicast vlan 3 query-response-interval 6000
You can also modify the IGMP router timeout on the specified VLAN by entering:
-> ip multicast vlan 2 router-timeout 360
You can also restore the IGMP router timeout on the specified VLAN by entering:
-> ip multicast vlan 2 router-timeout 0
You can also modify the source timeout on the specified VLAN by entering:
-> ip multicast vlan 2 source-timeout 360
You can also enable the IGMP querying on the specified VLAN by entering:
-> ip multicast vlan 2 querying enable
Note. If the links are known to be lossy, then robustness variable can be set to a higher value (7).
You can also modify the IGMP robustness variable from 1 to 7 on the specified VLAN by entering:
You can also enable IGMP spoofing on the specified VLAN by entering:
-> ip multicast vlan 2 spoofing enable
You can also enable IGMP zapping on the specified VLAN by entering:
-> ip multicast vlan 2 zapping enable
that can be learned. Once the configured limit is reached, a configurable action decides whether the new
IGMP report is dropped or replaces an existing IGMP membership.
The maximum group limit can be applied globally, per VLAN, or per port. Port settings override VLAN
settings, which override global settings.
If the maximum number of groups is reached an action can be configured to either drop the new member-
ship request or replace an existing group membership as show below.
To set the IGMP group limit for a VLAN and replace an existing session use the ip multicast vlan max-
group command as shown below:
-> ip multicast vlan 10 max-group 25 action replace
To set the IGMP group limit for a port and drop any requests above the limit, use the ip multicast port
max-group command as shown below:
-> ip multicast port 1/1 max-group 25 action drop
IPMSv6 Overview
An IPv6 multicast address identifies a group of nodes. A node can belong to any number of multicast
groups. IPv6 multicast addresses are classified as fixed scope multicast addresses and variable scope
multicast addresses.(See the “Reserved IPv6 Multicast Addresses” on page 41-22.)
IPMSv6 tracks the source VLAN on which the Multicast Listener Discovery Protocol (MLD) requests are
received. The network interfaces verify that a multicast packet is received by the switch on the source (or
expected) port.
IPMSv6 Example
The figure on the following page shows an IPMSv6 network where video content can be provided to
clients that request it. A server is attached to the switch that provides the source (multicast) IPv6
addresses. Clients from two different attached networks send MLD reports to the switch to receive the
video content.
OmniSwitch
Video
Source Port
Multicast Group
(dynamically built)
Multicast Stream
(destination IPv6 address)
Multicast Server
Ports on end stations send (source IPv6 address)
MLD requests to receive
multicast traffic.
Network A
Network B
Address Description
FF00:0:0:0:0:0:0:0 reserved
Address Description
FF01:0:0:0:0:0:0:0 node-local scope address
FF02:0:0:0:0:0:0:0 link-local scope
FF03:0:0:0:0:0:0:0 unassigned
FF04:0:0:0:0:0:0:0 unassigned
FF05:0:0:0:0:0:0:0 site-local scope
FF06:0:0:0:0:0:0:0 unassigned
FF07:0:0:0:0:0:0:0 unassigned
FF08:0:0:0:0:0:0:0 organization-local scope
FF09:0:0:0:0:0:0:0 unassigned
FF0A:0:0:0:0:0:0:0 unassigned
FF0B:0:0:0:0:0:0:0 unassigned
FF0C:0:0:0:0:0:0:0 unassigned
FF0D:0:0:0:0:0:0:0 unassigned
FF0E:0:0:0:0:0:0:0 global scope
FF0F:0:0:0:0:0:0:0 reserved
MLD Version 2
MLD is used by IPv6 systems (hosts and routers) to report their IPv6 multicast group memberships to any
neighboring multicast routers. MLD Version 1 (MLDv1) handles forwarding by IPv6 multicast destina-
tion addresses only. MLD Version 2 (MLDv2) handles forwarding by source IPv6 addresses and IPv6
multicast destination addresses. Both MLDv1 and MLDv2 are supported.
Note. See “Configuring the MLD Version 2” on page 41-25 for information on configuring the IGMP
version.
MLDv2 uses source filtering and reports multicast memberships to neighboring routers by sending
membership reports. MLDv2 also supports Source Specific Multicast (SSM) by allowing hosts to report
interest in receiving packets only from specific source addresses or from all but specific source addresses.
Note. See the “IP Multicast Switching Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Refer-
ence Guide for complete documentation of IPMSv6 CLI commands.
Note. If IPv6 Multicast switching is enabled on the system, the VLAN configuration overrides the system
configuration.
You can also enable IPv6 Multicast switching on the specified VLAN by entering:
-> ipv6 multicast vlan 2 status enable
You can also enable the MLD querier-forwarding on the specified VLAN by entering:
-> ipv6 multicast vlan 2 querier-forwarding enable
You can also configure a link aggregation group as an MLD static neighbor port by entering
ipv6 multicast static-neighbor followed by vlan, a space, VLAN number (which must be between 0 and
4095), a space, followed by port, a space, and the link aggregation group number.
For example, to configure link aggregation group 7 with designated VLAN 2 as a static neighbor, enter:
-> ipv6 multicast static-neighbor vlan 2 port 7
You can also configure a link aggregation group as an MLD static querier port by entering
ipv6 multicast static-querier, followed by vlan, a space, VLAN number (which must be between 0 and
4095), a space, followed by port, a space, and the link aggregation group number.
For example, to configure link aggregation group 7 with designated VLAN 2 as a static querier, enter:
-> ipv6 multicast static-querier vlan 2 port 7
You can also configure a link aggregation group as an MLD static group by entering
ipv6 multicast static-group, followed by vlan, a space, VLAN number (which must be between 0 and
4095), a space, followed by port, a space, and the link aggregation group number.
For example, to configure link aggregation group 7 with designated VLAN 2 as a static group, enter:
You can also modify the MLD query interval on the specified VLAN by entering:
-> ipv6 multicast vlan 2 query-interval 160
You can also restore the MLD query interval on the specified VLAN by entering:
-> no ipv6 multicast vlan 2 query-interval
You can also modify the MLD last member query interval on the specified VLAN by entering:
-> ipv6 multicast vlan 3 last-member-query-interval 2200
To restore the MLD last member query interval to its default (1000 milliseconds) value.
You can also restore the MLD last member query interval on the specified VLAN by entering:
-> ipv6 multicast vlan 2 last-member-query-interval 0
To restore the MLD last member query interval to its default (1000 milliseconds) value.
You can also modify the MLD query response interval on the specified VLAN by entering:
-> ipv6 multicast vlan 3 query-response-interval 20000
You can also restore the MLD query response interval on the specified VLAN by entering:
-> ipv6 multicast van 2 query-response-interval 0
You can also modify the MLD router timeout on the specified VLAN by entering:
-> ipv6 multicast vlan 2 router-timeout 360
You can also modify the source timeout on the specified VLAN by entering:
-> ipv6 multicast vlan 2 source-timeout 60
You can also enable the MLD querying on the specified VLAN by entering:
-> ipv6 multicast vlan 2 querying enable
Note. If the links are known to be lossy, then robustness can be set to a higher value (7).
You can also modify the MLD robustness variable from 1 to 7 on the specified VLAN by entering:
-> ipv6 multicast vlan 2 robustness 3
You can also enable MLD spoofing on the specified VLAN by entering:
-> ipv6 multicast vlan 2 spoofing enable
You can also enable MLD zapping on the specified VLAN by entering:
-> ipv6 multicast vlan 2 zapping enable
You can also disable MLD zapping on the specified VLAN by entering:
-> ipv6 multicast vlan 2 zapping disable
To set the MLD group limit for a VLAN and replace any requests above the limit, use the ipv6 multicast
vlan max-group command as shown below:
-> ipv6 multicast vlan 10 max-group 25 action replace
To set the MLD group limit for a port and drop any requests above the limit, use the ipv6 multicast port
max-group command as shown below:
-> ipv6 multicast port 1/1 max-group 25 action drop
Video OmniSwitch
Multicast Server
(source IP address)
Static Neighbor
Attached to Slot 1, Port 5.
Static Querier
Attached to Slot 1, Port 2.
Network Clients
Network clients send IGMP
requests to receive multicast
traffic.
The network administrator has determined that the network is too lossy and therefore the robustness vari-
able needs to be set to a higher (7) value.
Follow the steps below to configure this network:
Note. All the steps following Step 1 (which must be executed first) can be entered in any order.
2 Configure the client attached to Port 5 as a static neighbor belonging to VLAN 5 by entering:
3 Configure the client attached to Port 2 as a static querier belonging to VLAN 5 by entering:
An example of what these commands look like entered sequentially on the command line:
-> ip multicast status enable
-> ip multicast static-neighbor vlan 5 port 1/5
-> ip multicast static-querier vlan 5 port 1/2
-> ip multicast robustness 7
As an option, you can use the show ip multicast, show ip multicast neighbor, and
show ip multicast querier commands to confirm your settings as shown below:
-> show ip multicast
Status: enabled,
Querying: enabled,
Proxying: disabled,
Spoofing: disabled,
Zapping: disabled,
Querier Forwarding: disabled,
Flood Unknown: disabled,
Dynamic control status: disabled,
Dynamic control drop-all status: disabled,
Buffer Packet: disabled,
Version: 2,
Robustness: 7,
Query Interval (seconds): 125,
Query Response Interval (tenths of seconds): 100,
Last Member Query Interval (tenths of seconds): 10,
Unsolicited Report Interval (seconds): 1,
Router Timeout (seconds): 90,
Source Timeout (seconds): 30,
Max-group: 0,
Max-group action: none,
Helper-address: 0.0.0.0
Total 1 Neighbors
Host Address VLAN Port Static Count Life
---------------+-----+-----+-------+------+-----
1.0.0.2 5 1/5 no 1 86
Total 1 Queriers
Host Address VLAN Port Static Count Life
---------------+-----+-----+-------+------+-----
1.0.0.3 5 1/2 no 1 250
OmniSwitch
Video
Multicast Server
(source IPv6 address)
Static Neighbor
Attached to Slot 1, Port 5.
Static Querier
Attached to Slot 1, Port 2.
Network Clients
Network clients send MLD
requests to receive multicast
traffic.
The network administrator has determined that the network is too lossy and therefore the robustness vari-
able needs to be set to a higher (7) value.
Follow the steps below to configure this network:
Note. All the steps following Step 1 (which must be executed first) can be entered in any order.
2 Configure the client attached to Port 5 as a static MLD neighbor belonging to VLAN 5 by entering:
3 Configure the client attached to Port 2 as a static MLD querier belonging to VLAN 5 by entering:
An example of what these commands look like entered sequentially on the command line:
-> ipv6 multicast status enable
-> ipv6 multicast static-neighbor vlan 5 port 1/5
-> ipv6 multicast static-querier vlan 5 port 1/2
-> ipv6 multicast robustness 7
As an option, you can use the show ipv6 multicast, show ipv6 multicast neighbor, and
show ipv6 multicast querier commands to confirm your settings as shown below:
-> show ipv6 multicast
Status: = Enabled
Querying: = Disabled
Proxying: = Disabled
Spoofing: = Disabled
Zapping: = Disabled
Querier Forwarding: = Disabled
Version: = 1
Robustness: = 2
Query Interval (seconds): = 125
Query Response Interval (milliseconds): = 10000
Last Member Query Interval(milliseconds): = 1000
Unsolicited Report Interval (seconds) = 1,
Router Timeout (seconds): = 90
Source Timeout (seconds): = 30
Total 1 Neighbors
Host Address VLAN Port Static Count Life
-------------------------+-----+-----+-------+------+-----
fe80::2a0:ccff:fed3:2853 5 1/5 no 1 6
Total 1 Queriers
Host Address VLAN Port Static Count Life
-------------------------+-----+-----+-------+------+-----
fe80::2a0:ccff:fed3:2854 5 1/2 no 1 6
If you are interested in a quick look at IPMS groups on your switch you could use the
show ip multicast group command. For example:
-> show ip multicast group
Total 3 Groups
Group Address Source Address VLAN Port Mode Static Count Life
---------------+---------------+-----+-----+--------+-------+------+-----
231.0.0.3 1.0.0.5 1 2/1 exclude no 1 257
234.0.0.4 0.0.0.0 1 2/1 exclude no 1 218
229.0.0.1 0.0.0.0 1 2/13 exclude yes 0 0
Note. See the “IP Multicast Switching Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Refer-
ence Guide for complete documentation on IPMS show commands.
show ipv6 multicast Displays the general IPv6 Multicast switching configuration parameters
on a switch.
show ipv6 multicast group Displays all detected multicast groups that have members. If you do not
specify an IPv6 address, then all multicast groups on the switch will be
displayed.
show ipv6 multicast neighbor Displays all neighboring IPv6 multicast routers.
show ipv6 multicast querier Displays all IPv6 multicast queriers.
show ipv6 multicast forward Displays the IPMSv6 multicast forwarding table. If you do not specify a
multicast group IPv6 address, then the forwarding table for all multicast
groups will be displayed.
show ipv6 multicast source Displays the IPMSv6 multicast source table. If you do not specify a
multicast group IPv6 address, then the source table for all multicast
groups will be displayed.
If you are interested in a quick look at IPMSv6 groups on your switch you could use the
show ipv6 multicast group command. For example:
-> show ipv6 multicast group
Total 3 Groups
Group Address Source Address VLAN Port Mode Static Count Life
----------------+---------------+-----+-----+--------+-------+------+-----
ff05::5 :: 1 2/1 exclude no 1 145
ff05::6 3333::1 1 2/1 exclude no 1 242
Note. See the “IPv6 Multicast Switching Commands” chapter in the OmniSwitch 6250/6350/6450 CLI
Reference Guide for complete documentation on IPMS show commands.
In This Chapter
This chapter describes the basic components of IP Multicast VLAN and shows how to configure them
through the Command Line Interface (CLI). CLI commands are used in configuration examples. For more
details on command syntax, see the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Creating and Deleting IPMVLAN on page 42-9.
• Assigning and Deleting IPv4/IPv6 Addresses on page 42-10.
• Assigning and Deleting a C-Tag on page 42-10.
• Creating and Deleting a Sender Port on page 42-10.
• Creating and Deleting a Receiver Port on page 42-11.
• Associating an IPMVLAN with a Customer VLAN on page 42-12.
Note. You can also configure and monitor IPMV through WebView. It is the embedded web-based device
management application of Alcatel. WebView is an interactive and easy-to-use GUI that can be launched
from OmniVista or a web browser. See the online documentation on WebView for more information on
configuring and monitoring IPMV through WebView.
Note. It is recommended to use any one of the methods on the receiver port and not both.
Note. CVLAN-tag translation rule applies only in the VLAN Stacking mode.
You can use the vlan ipmvlan ctag command to define the translation rule for replacing the outer s-tag
with an IPMVLAN ID. The inner tag is the customer tag (c-tag).
Note. No checks is performed on c-tags as they are simple translation rules. VLAN addition or deletion
rules do not affect them.
Enterprise Mode
IP Multicast VLANs in the Enterprise mode contain normal user ports (fixed/tagged) as their member
ports.
Core Unicast
and
Multicast Router
5 Receiver port
4
Legends
Sender port
Multicast Data Packets
3 Customer A
Multicast Control Packets 2
Ethernet Switch
1 6
Customer C
Customer B
The paths taken by the packets are described in the following subsections:
1 Untagged IPMS join reports for the multicast group G1 are sent to the receiver port.
2 The IPMS reports sent to the CPU of the Ethernet switch are single-tagged with the default SVLAN tag
(s-tag).
3 IPMS overwrites the SVLAN tag with the IPMV tag after IPMV table lookup.
4 A single IPMS report, single-tagged with IPMV, is sent to the multicast server for group G1.
5 The single multicast data packet, single-tagged with IPMV, is generated by the multicast server for
group G1.
6 The generated multicast data packets are flooded on the receiver port. These data packets are untagged.
1 The IPMS join reports for multicast group G1, which are single-tagged with the CVLAN tag (c-tag) are
sent to the receiver port.
2 SVLAN tags are attached before the CVLAN tags in all the IPMS reports going to the CPU of the
Ethernet switch.
3 IPMS overwrites the SVLAN tags with the IPMV tags after IPMV table lookup for the inner c-tag.
4 A single IPMS double-tagged report with an IPMV outer tag and a CVLAN inner tag is sent to the
multicast server for group G1.
5 The single multicast double-tagged data packets with an IPMV outer tag and a CVLAN inner tag are
generated by the multicast server for group G1.
6 The VLAN Stacking egress logic removes the IPMV outer tag. The generated multicast data packets
flooded on the receiver port are single-tagged with CVLAN.
4 A single IPMS double-tagged report with an IPMV outer tag and a CVLAN inner tag is sent to the
multicast server for group G1.
5 The single multicast double-tagged data packets with an IPMV outer tag and a CVLAN inner tag are
generated by the multicast server for group G1.
6 The VLAN Stacking egress logic removes the IPMV outer tag. The generated multicast data packets
flooded on the receiver port are single-tagged with CVLAN.
Note. All the IPMS control traffic specified for a single multicast service has to be tagged with the same
CVLAN.
3 IPMS overwrites the SVLAN tags with the IPMV tags after IPMV table lookup.
4 A single IPMV-tagged IPMS report is sent to the multicast server for Group G1.
5 The single multicast packets single-tagged with IPMV are generated by the multicast server for group
G1.
6 The VLAN Stacking egress logic replaces the IPMV tag with the CVLAN tag. The multicast data
packets flooded on the receiver port are single-tagged with CVLAN.
Note. All the IPMS control traffic specified for a single multicast service has to be tagged with the same
CVLAN.
Enterprise Mode
In the Enterprise mode, two types of control packets ingress on the receiver ports. The paths taken by the
packets (as shown in the diagram on page 42-5) are described in the following subsections.
1 Untagged IPMS join reports for the multicast group G1 are sent to the receiver port.
2 The IPMS reports sent to the CPU of the Ethernet switch are single-tagged with the default VLAN.
3 IPMS overwrites the tag with the IPMV tag after IPMV table lookup.
4 A single IPMS report, single-tagged with IPMV, is sent to the multicast server for group G1.
5 The single multicast data packet, single-tagged with IPMV, is generated by the multicast server for
group G1.
6 The generated multicast data packets are flooded on the receiver port. These data packets are untagged.
1 The single-tagged IPMS join reports for the multicast group G1 are sent to the receiver port.
2 The IPMS reports are sent to the CPU of the Ethernet switch.
3 IPMS overwrites the tag with the IPMV tag after IPMV table lookup.
4 A single IPMS report, single-tagged with IPMV, is sent to the multicast server for group G1.
5 The single multicast data packet, single-tagged with IPMV, is generated by the multicast server for
group G1.
6 The generated multicast data packets are flooded on the receiver port. These data packets are untagged.
Configuring IPMVLAN
This section describes how to use Command Line Interface (CLI) commands to complete the following
configuration tasks:
• Creating and deleting IPMVLAN (see “Creating and Deleting IPMVLAN” on page 42-9).
• Assigning IPv4/IPv6 address to an existing IPMVLAN and removing it (see “Assigning and Deleting
IPv4/IPv6 Address” on page 42-10)
• Assigning and removing the c-tag in an IPMVLAN (see “Assigning and Deleting a Customer VLAN
Tag” on page 42-10).
• Creating and deleting a sender port in an IPMVLAN (see “Creating and Deleting a Sender Port” on
page 42-10).
• Creating and deleting a receiver port in an IPMVLAN (see “Creating and Deleting a Receiver Port” on
page 42-11).
• Configuring a VLAN translation of a CVLAN to an IPMVLAN (see “Associating an IPMVLAN with
a Customer VLAN” on page 42-12).
In addition, a tutorial is provided in “IPMVLAN Application Example” on page 42-13 that shows you how
to use CLI commands to configure a sample network.
Note. See the “IP Multicast VLAN Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Refer-
ence Guide for complete documentation of IPMVLAN CLI commands.
Creating IPMVLAN
To create an IPMVLAN, use the vlan ipmvlan command as shown in the following example.
-> vlan ipmvlan 1003 name
"multicast vlan"
For example, to create an IPMVLAN in the 1x1 Spanning Tree mode, enter:
-> vlan ipmvlan 1333 1x1 stp enable name “nvlan”
Deleting IPMVLAN
To remove an IPMVLAN, use the no form of the vlan ipmvlan command by entering no vlan ipmvlan
followed by the IPMVLAN ID, as shown in the following example.
-> no vlan ipmvlan 1003
To create multiple sender ports in an IPMVLAN, specify a range of ports. For example:
-> vlan ipmvlan 1003 sender-port port 1/45-48
In the VLAN Stacking mode, the port that you want to configure as a sender port has to be a VLAN Stack-
ing port (network port). To create a sender port in an IPMVLAN configured in the VLAN Stacking mode,
use the vlan ipmvlan sender-port command as shown in the following example.
-> vlan ipmvlan 1033 sender-port port 1/49
To configure the the port (or a range of ports) as receiver port for the IPMVLAN and associate RVLAN to
receiver port (or a range of receiver ports), use the vlan ipmvlan receiver-port as shown in the following
example.
-> vlan ipmvlan 1003 receiver-port port 1/51 receiver-vlan 10
In the VLAN Stacking mode, the port you want to configure as a receiver port has to be a VLAN Stacking
user port (UNI).To create a receiver port in an IPMVLAN configured in the VLAN Stacking mode, use
the vlan ipmvlan receiver-port command as shown in the following example.
-> vlan ipmvlan 1002 receiver-port port 1/1
To delete receiver port association with a receiver VLAN, use the no form of the vlan ipmvlan receiver-
port command by entering no vlan ipmvlan followed by the IPMVLAN ID, the keyword receiver-port,
and the port number, as shown in the following example.
-> no vlan ipmvlan 1003 receiver-port port 1/51 receiver-vlan 10
To delete Receiver port from an IPMVLAN, and delete all the RVLAN associations to the receiver port,
use the no form of the vlan ipmvlan receiver-port command by entering no vlan ipmvlan followed by
the IPMVLAN ID, the keyword receiver-port, and the port number, as shown in the following example.
-> no vlan ipmvlan 1000 receiver-port port 1/51
The above CLI command will delete all the RVLAN associations to receiver port 1/51.
This above command will associate the IPMVLAN to the receiver-port/receiver-vlan pair.
To associate an IPMVLAN with a linkagg, use the command as follows:
-> vlan ipmvlan 1002 receiver-port linkagg 1
Note. The maximum number of RVLANs that can be configured per receiver-port is limited to eight
VLANs.
Ethernet Switch
Customer C
Customer B
Customer A
Note. All the steps following step 1 (which must be executed first) may be entered in any order.
Alternatively, a sender port can also be created in the VLAN Stacking mode by entering:
-> vlan ipmvlan 1033 sender-port port 1/49
Alternatively, a receiver port can also be created in the VLAN Stacking mode by entering:
-> vlan ipmvlan 1002 receiver-port port 1/1
An example of what these commands look like when entered sequentially on the command line:
-> vlan ipmvlan 1003 name "multicast vlan"
-> vlan ipmvlan 1003 address 225.0.0.1
-> vlan ipmvlan 1003 sender-port port 1/50
-> vlan ipmvlan 1003 receiver-port port 1/51-60
An example of what these commands look like when entered sequentially in E-service mode on the
command line:
-> ethernet-service svlan 1000
-> ethernet-service ipmvlan 1001
-> ethernet-service svlan 1000 nni 1/23
-> ethernet-service service-name "customerA" svlan 1000 ethernet-service sap 10
service-name "customerA"
-> ethernet-service sap 10 uni 1/3
-> ethernet-service sap 10 cvlan 2000
As an option, you can use the show vlan ipmvlan c-tag, show vlan ipmvlan address, show vlan
ipmvlan port-config, and show vlan ipmvlan port-binding commands to confirm your settings. For
example:
-> show vlan
stree mble
vlan type admin oper 1x1 flat auth ip tag name
+----+-----+-----+-------+----------+------+----+-----+-----+--------
1 std on on on on off NA off VLAN 1
2 ipmtv on on off off off NA off IPMVLAN 2
3 ipmtv on on off off off NA off IPMVLAN 3
4 vstk on on on on off NA off SVLAN 4
IpAddress ipAddressType
----------+---------------
224.1.1.1 Ipv4
224.1.1.2 Ipv4
224.1.1.3 Ipv4
ffae::1 Ipv6
ffae::2 Ipv6
ffae::3 Ipv6
show vlan ipmvlan Displays IPMVLAN information for a specific IPMVLAN, a range
of IPMVLANs, or all IPMVLANs.
show vlan ipmvlan c-tag Displays the customer VLAN IDs associated with a single IP Multi-
cast VLAN or all the configured IP Multicast VLANs.
show vlan ipmvlan address Displays the IPv4 and IPv6 addresses assigned to a single IP Multi-
cast VLAN or all the configured IP Multicast VLANs.
show vlan ipmvlan port-config Displays the sender and receiver ports for a specific IP Multicast
VLAN or all the IP Multicast VLANs.
show ipmvlan port-config Displays the sender and receiver IPMVLANs for a specific slot or
port.
show vlan ipmvlan port-binding Displays the translation bindings of an IP Multicast VLAN on a port,
an aggregate of ports, or all ports.
Several tools are available for diagnosing problems that may occur with the switch. These tools include:
• Port Mirroring
• Port Monitoring
• sFlow
• Remote Monitoring (RMON) probes
• Switch Health Monitoring
Port mirroring copies all incoming and outgoing traffic from a single mirrored Ethernet port to a second
mirroring Ethernet port, where it can be monitored with a Remote Network Monitoring (RMON) probe or
network analysis device without disrupting traffic flow on the mirrored port. The port monitoring feature
allows you to examine packets to and from a specific Ethernet port. sFlow is used for measuring high
speed switched network traffic. It is also used for collecting, storing, and analyzing the traffic data. Switch
Health monitoring software checks previously configured threshold levels for the consumable resources,
on the switch, and notifies the Network Monitoring Station (NMS) if those limits are violated.
In This Chapter
This chapter describes port mirroring, port monitoring, remote monitoring (RMON) probes, sFlow, and
switch health features and explains how to configure the same through the Command Line Interface (CLI).
Configuration procedures described in this chapter include:
Port Mirroring
• Creating or Deleting a Port Mirroring Session—see “Creating a Mirroring Session” on page 43-18 or
“Deleting A Mirroring Session” on page 43-22.
• Protection from Spanning Tree changes (Port Mirroring)—see “Unblocking Ports (Protection from
Spanning Tree)” on page 43-19.
• Enabling or Disabling Port Mirroring Status—see “Enabling or Disabling Mirroring Status” on
page 43-20 or “Disabling a Mirroring Session (Disabling Mirroring Status)” on page 43-20.
• Configuring Port Mirroring Direction—see “Configuring Port Mirroring Direction” on page 43-20.
• Enabling or Disabling a Port Mirroring Session—see “Enabling or Disabling a Port Mirroring Session
(Shorthand)” on page 43-21.
Port Monitoring
• Configuring a Port Monitoring Session—see “Configuring a Port Monitoring Session” on page 43-26.
• Enabling a Port Monitoring Session—see “Enabling a Port Monitoring Session” on page 43-26.
• Disabling a Port Monitoring Session—see “Disabling a Port Monitoring Session” on page 43-26.
• Deleting a Port Monitoring Session—see “Deleting a Port Monitoring Session” on page 43-26.
• Pausing a Port Monitoring Session—see “Pausing a Port Monitoring Session” on page 43-27.
• Configuring the persistence of a Port Monitoring Session—see “Configuring Port Monitoring Session
Persistence” on page 43-27.
• Configuring a Port Monitoring data file—see “Configuring a Port Monitoring Data File” on
page 43-27.
• Suppressing creation of a Port Monitoring data file—see “Suppressing Port Monitoring File Creation”
on page 43-28.
• Configuring a Port Monitoring direction—see “Configuring Port Monitoring Direction” on page 43-28.
• Displaying Port Monitoring Status and Data—see “Displaying Port Monitoring Status and Data” on
page 43-29.
sFlow
• Configuring a sFlow Session—see “Configuring a sFlow Session” on page 43-31.
• Configuring a Fixed Primary Address—see “Configuring a Fixed Primary Address” on page 43-32.
• Displaying a sFlow Receiver—see “Displaying a sFlow Receiver” on page 43-32.
• Displaying a sFlow Sampler—see “Displaying a sFlow Sampler” on page 43-33.
• Displaying a sFlow Poller—see “Displaying a sFlow Poller” on page 43-33.
• Displaying a sFlow Agent—see “Displaying a sFlow Agent” on page 43-33.
• Deleting a sFlow Session—see “Deleting a sFlow Session” on page 43-34.
RMON
• Enabling or Disabling RMON Probes—see “Enabling or Disabling RMON Probes” on page 43-36.
Note. The console messages "+++ healthMonCpuStatus Crossed Below The Threshold Limit "
can be seen on switch bootup if it is configured to receive health monitoring debug messages on console
or swlog file using the swlog appid and swlog output commands.
Note. Optional. To verify the port mirroring configuration, enter show port mirroring status followed by
the port mirroring session ID number. The display is similar to the one shown below:
-> show port mirroring status 6
For more information about this command, see “Displaying Port Mirroring Status” on page 43-22 or the
“Port Mirroring and Monitoring Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Reference
Guide.
2 Enable the port monitoring session by entering port monitoring, followed by the port monitoring
session ID, source, the slot and port number of the port to be monitored, and enable. For example:
-> port monitoring 6 source 2/3 enable
3 Optional. Configure optional parameters. For example, to create a file called “monitor1” for port moni-
toring session 6 on port 2/3, enter:
-> port monitoring 6 source 2/3 file monitor1
Note. Optional. To verify the port monitoring configuration, enter show port mirroring status, followed
by the port monitoring session ID number. The display is similar to the one shown below:
-> show port monitoring status
For more information about this command, see “Port Monitoring” on page 43-25 or the “Port Mirroring
and Monitoring Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Reference Guide.
sFlow Overview
The following sections detail the specifications, defaults, and quick set up steps for the sFlow feature.
Detailed procedures are found in “sFlow” on page 43-30.
sFlow Specifications
RFCs Supported 3176 - sFlow Management Information Base
Platforms Supported OmniSwitch 6250, 6350, 6450
Sampling Sampling rate of one (1) counts all packets and 0
(zero) disables sampling.
Agent IP Address As it need to send a fixed IP address in the data-
gram, loopback0 IP address is used.
sFlow Defaults
The following table shows sFlow default values:
sFlow Defaults
1 To create a sFlow receiver session, use the sflow receiver command by entering sflow
receiver, followed by the receiver index, name, and the address to be monitored. For example:
-> sflow receiver 1 name Golden address 198.206.181.3
2 Optional. Configure optional parameters. For example, to specify the timeout value “65535” for sFlow
receiver session on address 198.206.181.3, enter:
-> sflow receiver 1 name Golden address 198.206.181.3 timeout 65535
Note. Optional. To verify the sFlow receiver configuration, enter show sflow receiver, followed by the
sFlow receiver index. The display is similar to the one shown below:
-> show sflow receiver
Receiver 1
Name = Golden
Address = IP_V4 198.206.181.3
UDP Port = 6343
Timeout = 65535
Packet Size= 1400
DatagramVer= 5
For more information about this command, see “sFlow” on page 43-30 or the “sFlow Commands” chapter
in the OmniSwitch 6250/6350/6450 CLI Reference Guide.
1 To create a sFlow sampler session, use the sflow sampler command by entering sflow
sampler, followed by the instance ID, port list, receiver, and the rate. For example:
-> sflow sampler 1 2/1-5 receiver 1 rate 2048
2 Optional. Configure optional parameters. For example, to specify the sample-hdr-size value “128” for
sFlow sampler instance 1 on ports 2/1-5, enter:
-> sflow sampler 1 2/1-5 receiver 1 rate 2048 sample-hdr-size 128
Note. Optional. To verify the sFlow sampler configuration, enter show sflow sampler, followed by the
sFlow sampler instance ID. The display is similar to the one shown below:
-> show sflow sampler 1
For more information about this command, see “sFlow” on page 43-30 or the “sFlow Commands” chapter
in the OmniSwitch 6250/6350/6450 CLI Reference Guide.
1 To create a sFlow poller session, use the sflow poller command by entering sflow
poller, followed by the instance ID, port list, receiver, and the interval. For example:
-> sflow poller 1 2/6-10 receiver 1 interval 30
Note. Optional. To verify the sFlow poller configuration, enter show sflow poller, followed by the sFlow
poller instance ID. The display is similar to the one shown below:
-> show sflow poller
For more information about this command, see “sFlow” on page 43-30 or the “sFlow Commands” chapter
in the OmniSwitch 6250/6350/6450 CLI Reference Guide.
RMON Specifications
RFCs Supported 2819 - Remote Network Monitoring
Management Information Base
Platforms Supported OmniSwitch 6250, 6350, 6450
RMON Functionality Supported Basic RMON 4 group implementation
–Ethernet Statistics group
–History (Control and Statistics) group
–Alarms group
–Events group
RMON Functionality Not Supported RMON 10 group*
RMON2*
–Host group
–HostTopN group
–Matrix group
–Filter group
–Packet Capture group
(*An external RMON probe that includes
RMON 10 group and RMON2 may be used
where full RMON probe functionality is
required.)
Flavor (Probe Type) Ethernet/History/Alarm
Status Active/Creating/Inactive
History Control Interval (seconds) 1 to 3600
History Sample Index Range 1 to 65535
Alarm Interval (seconds) 1 to 2147483647
Alarm Startup Alarm Rising Alarm/Falling Alarm/
RisingOrFalling Alarm
Alarm Sample Type Delta Value/Absolute
RMON Traps Supported RisingAlarm/FallingAlarm
These traps are generated whenever an Alarm
entry crosses either its Rising Threshold or its
Falling Threshold and generates an event con-
figured for sending SNMP traps.
2 To verify the RMON probe configuration, enter the show rmon probes command, with the keyword
for the type of probe. For example, to display the statistics probes, enter the following:
-> show rmon probes stats
3 To view statistics for a particular RMON probe, enter the show rmon probes command, with the
keyword for the type of probe, followed by the entry number for the desired RMON probe. For example:
-> show rmon probes 1011
For more information about these commands, see “Displaying a List of RMON Probes” on page 43-37,
“Displaying Statistics for a Particular RMON Probe” on page 43-38, or the “RMON Commands” chapter
in the OmniSwitch 6250/6350/6450 CLI Reference Guide.
The default settings for the command you entered will be displayed. For example:
Rx Threshold = 80
TxRx Threshold = 80
Memory Threshold = 80
CPU Threshold = 80
Temperature Threshold = 60
2 Enter the appropriate command to change the required health threshold or health sampling interval
parameter settings or reset all health statistics for the switch. For example:
-> health threshold memory 85
Note. Optional. To verify the Switch Health configuration, enter show health threshold, followed by the
parameter you modified (for example, memory). The display is similar to the one shown below:
Memory Threshold = 85
For more information about this command, see “Displaying Health Threshold Limits” on page 43-45 or
the “Health Monitoring Commands” chapter in the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Port Mirroring
On chassis-based or standalone switches, you can set up port mirroring sessions between Ethernet ports
within the same switch, while on stackable switches, you can set up port mirroring sessions across
switches within the same stack.
Ethernet ports supporting port mirroring include 10BaseT/100BaseTX/1000BaseT (RJ-45), 1000BaseSX/
LX/LH, and 10GBaseS/L (LC) connectors. When port mirroring is enabled, the active “mirrored” port
transmits and receives network traffic normally, and the “mirroring” port receives a copy of all transmit
and receive traffic to the active port. You can connect an RMON probe or network analysis device to the
mirroring port to see an exact duplication of traffic on the mirrored port without disrupting network traffic
to and from the mirrored port.
Port mirroring runs in the Chassis Management software and is supported for Ethernet (10 Mbps), Fast
Ethernet (100 Mbps), Gigabit Ethernet (1000 Mpbs), and 10 Gigabit Ethernet (10000 Mbps) ports. In
addition, the switch supports “N-to-1” port mirroring, where up to 24 source ports can be mirrored to a
single destination port.
Note the following restriction when configuring a port mirroring session:
• Two (2) port mirroring sessions are supported per standalone chassis-based switch or in a stack
consisting of two or more switches.
• You cannot configure a port mirroring and a port monitoring session on the same NI module in an
OmniSwitch chassis-based switch.
• You cannot configure port mirroring and monitoring on the same switching ASIC. Each switching
ASIC controls 24 ports (ports 1–24, 25–48, etc.). For example, if a port mirroring session is config-
ured for ports 1/12 and 1/22, then configuring a port monitoring session for any of the ports between 1
and 24 is not allowed.
• If a port mirroring session is configured across two switching ASICs, then configuring a monitoring
session is not allowed on any of the ports controlled by each of the ASICs involved. For example, if a
port mirroring session is configured for ports 1/8 and 1/30 on a 48-port switch, then configuring a port
monitoring session involving any of the ports between 1 and 48 is not allowed.
Note that when port mirroring is enabled, there may be some performance degradation, since all frames
received and transmitted by the mirrored port need to be copied and sent to the mirroring port.
NMS
Workstation
Mirrored
(Active) Port
(w/ Incoming &
Outgoing Frames)
Mirroring
(Monitoring) Port
(w/ Copied Incoming
& Outgoing Frames)
Relationship Between Mirrored and Mirroring Ports
Note. If the mirroring port monitors mirrored traffic on an RMON probe belonging to a different VLAN
than the mirrored port, it should be protected from blocking due to Spanning Tree updates. See “Unblock-
ing Ports (Protection from Spanning Tree)” on page 43-19 for details.
The diagram on the following page illustrates how port mirroring can be used with an external RMON
probe to copy RMON probe frames and Management frames to and from the mirroring and mirrored
ports. Frames received from an RMON probe attached to the mirroring port can be seen as being received
by the mirrored port. These frames from the mirroring port are marked as if they are received on the
mirrored port before being sent over the switch backplane to an NMS station. Therefore, management
frames destined for the RMON probe are first forwarded out of the mirrored port. After being received on
the mirrored port, copies of the frames are mirrored out of the mirroring port—the probe attached to the
mirroring port receives the management frames.
NMS Workstation
A. RMON probe frames sent from the mirroring port
Mirroring Port
Mirrored
C. Management frames from the NMS Workstation are sent to the mirrored port....
D. ...and port mirroring sends copies of the
Management frames to the mirroring port.
NMS Workstation
Mirroring Port
Mirrored Port
RMON Probe
OmniSwitch
• On the intermediate and destination switches, source learning must be disabled or overridden on the
ports belonging to the Remote Port Mirroring VLAN.
• The QoS redirect feature can be used to override source learning on an OmniSwitch.
The following types of traffic will not be mirrored:
• Link Aggregation Control Packets (LACP)
• 802.1AB (LLDP)
• 802.1x port authentication
• 802.3ag (OAM)
• Layer 3 control packets
• Generic Attribute Registration Protocol (GARP)
• BPDUs.
For more information and an example of a Remote Port Mirroring configuration, see “Remote Port Mirror-
ing” on page 43-17.
Note. To prevent the mirroring (destination) port from being blocked due to Spanning Tree changes, be
sure to specify the VLAN ID number (from 1 to 4094) for the port that will remain unblocked (protected
from these changes while port mirroring is active). This parameter is optional; if it is not specified,
changes resulting from Spanning Tree could cause the port to become blocked (default). See Unblocking
Ports (Protection from Spanning Tree) below for details.
To create a mirroring session, enter the port mirroring source destination command and include the port
mirroring session ID number and the source and destination slot/ports, as shown in the following example:
-> port mirroring 6 source 2/3 destination 2/4
This command line specifies mirroring session 6, with the source (mirrored) port located in slot 2/port 3,
and the destination (mirroring) port located in slot 3/port 4.
To create a remote port mirroring session, enter the port mirroring source destination command and
include the port mirroring session ID number, the source and destination slot/ports, and the remote port
mirroring VLAN ID as shown in the following example:
-> port mirroring 8 source 1/1 destination 1/2 rpmir-vlan 1000
This command line specifies remote port mirroring session 8, with the source (mirrored) port located on
slot 1/port 1, the destination (mirroring) port on slot 1/port 2, and the remote port mirroring VLAN 1000.
Note. Neither the mirrored nor the mirroring ports can be a mobile port. See Chapter 7, “Assigning Ports
to VLANs,” for information on mobile ports.
Creating an “N-to-1” port mirroring session is supported, where multiple source ports can be mirrored to a
single destination port. In the following example, port 1/2, 2/1, and 2/3 are mirrored on destination port 2/
4 in session 1:
-> port mirroring 1 source 1/2 destination 2/4
-> port mirroring 1 source 2/1 destination 2/4
-> port mirroring 1 source 2/3 destination 2/4
As an option, you can specify a range of source ports and/or multiple source ports. In the following exam-
ple, ports 1/2 through 1/6 are mirrored on destination port 2/4 in session 1:
-> port mirroring 1 source 1/2-6 destination 2/4
In the following example, ports 1/9, 2/7, and 3/5 are mirrored on destination port 2/4 in session 1:
-> port mirroring 1 source 1/9 2/7 3/5 destination 2/4
In the following example, 1/2 through 1/6 and 1/9, 2/7, and 3/5 are mirrored on destination port 2/4 in
session 1:
-> port mirroring 1 source 1/2-6 1/9 2/7 3/5 destination 2/4
Note. Ports can be added after a port mirroring session has been configured.
This command line specifies mirroring session 6, with the source (mirrored) port located in slot 2/port 3,
and the destination (mirroring) port located in slot 2/port 4. The mirroring port on VLAN 750 is protected
from Spanning Tree updates.
Note. If the unblocked VLAN identifier is not specified, the mirroring port could be blocked due to
changes in Spanning Tree.
Note. You can modify the parameters of a port mirroring session that has been disabled.
Keep in mind that the port mirroring session configuration remains valid, even though port mirroring has
been turned off. Note that the port mirroring session identifier and slot/port locations of the designated
interfaces must always be specified.
Note. Note that the port mirroring session identifier and slot/port locations of the designated interfaces
must always be specified.
Note. Optionally, you can also specify the optional unblocked VLAN ID number and either enable or
disable on the same command line.
In this example, the command specifies port mirroring session 6, with the mirrored (active) port located in
slot 2/port 3 and the mirroring port located in slot 6/port 4. The mirroring direction is unidirectional and
inward bound:
In this example, the command specifies port mirroring session 6, with the mirrored (active) port located in
slot 2/port 3, and the mirroring port located in slot 6/port 4. The mirroring direction is unidirectional and
outward bound:
-> port mirroring 6 source 2/3 destination 6/4 outport
You can use the bidirectional keyword to restore a mirroring session to its default bidirectional configura-
tion. For example:
-> port mirroring 6 source 2/3 destination 6/4 bidirectional
Note. Note that the port mirroring session identifier and slot/port locations of the designated interfaces
must always be specified.
Note. Port mirroring session parameters cannot be modified when a mirroring session is enabled. Before
you can modify parameters, the mirroring session must be disabled.
To disable a port mirroring session, enter the port mirroring command, followed by the port mirroring
session ID number and the keyword disable. The following command disables port mirroring session 6
(turning port mirroring off):
-> port mirroring 6 disable
Destination switch
Intermediate
switch
3/1
Local MTP
Source switch 1/2 2/2 3/2
2/1
Destination Port
RPMir
Source VLAN - 1000
Port
1/1
Note. If the intermediate switches are not OmniSwitches, refer to the vendor's documentation for instruc-
tions on disabling or overriding source learning.
Port Monitoring
An essential tool of the network engineer is a network packet capture device. A packet capture device is
usually a PC-based computer, such as the Sniffer®, that provides a means for understanding and measur-
ing data traffic of a network. Understanding data flow in a VLAN-based switch presents unique chal-
lenges, primarily because traffic moves inside the switch, especially on dedicated devices.
The port monitoring feature allows you to examine packets to and from a specific Ethernet port. Port
monitoring has the following features:
• Software commands to enable and display captured port data.
• Captures data in Network General® file format.
• A file called pmonitor.enc is created in the /flash memory when you configure and enable a port
monitoring session.
• Data packets time stamped.
• One port monitored at a time.
• RAM-based file system.
• Statistics gathering and display.
The port monitoring feature also has the following restrictions:
• All packets cannot be captured. (Estimated packet capture rate is around 500 packets/second.)
• The maximum number of monitoring sessions is limited to one per chassis and/or stack.
• You cannot configure a port mirroring and a port monitoring session on the same NI module in an
OmniSwitch chassis-based switch.
• You cannot configure port mirroring and monitoring on the same switching ASIC. Each switching
ASIC controls 24 ports (for example, ports 1–24, 25–48, etc.). For example, if a port mirroring session
is configured for ports 1/12 and 1/22, then configuring a port monitoring session for any of the ports
between 1 and 24 is not allowed.
• If a port mirroring session is configured across two switching ASICs, then configuring a monitoring
session is not allowed on any of the ports controlled by each of the ASICs involved. For example, if a
port mirroring session is configured for ports 1/8 and 1/30 on a 48-port switch, then configuring a port
monitoring session involving any of the ports between 1 and 48 is not allowed.
• Only the first 64 bytes of the traffic will be captured.
• Link Aggregation ports can be monitored.
• If both mirroring and monitoring are enabled, then packets will either be mirrored or monitored (sent
to CPU), whichever comes first. See “Mirroring on Multiple Ports” on page 43-16 for more informa-
tion.
You can select to dump real-time packets to a file. Once a file is captured, you can FTP it to a Sniffer or
PC for viewing.
Note. One port monitoring session can be configured per chassis or stack.
In addition, you can also specify optional parameters shown in the table below. These parameters must be
entered after the slot and port number.
keywords
file no file size
no overwrite inport outport
bidirectional timeout enable
disable
For example, to configure port monitoring session 6 on port 2/3 and administratively enable it, enter:
-> port monitoring 6 source 2/3 enable
These keywords can be used when creating the port monitoring session or afterwards. See the sections
below for more information on using these keywords.
To resume a paused port monitoring session, use the port monitoring command by entering port
monitoring, followed by the port monitoring session ID and resume. For example, to resume port moni-
toring session 6, enter:
-> port monitoring 6 resume
Optionally, you can also configure the size of the file and/or you can configure the data file so that more-
recent packets will not overwrite older packets in the data file if the file size is exceeded.
To create a file and configure its size, use the port monitoring source CLI command by entering port
monitoring, followed by the user-specified session ID number, source, the slot number of the port to be
monitored, a slash (/), the port number of the port, file, the name of the file, size, and the size of the file in
16K byte increments. (The maximum size is 140K bytes.)
For example, to configure port monitoring session 6 on port 2/3 with a data file called “user_port” in the
/flash directory with a size of 49152 (3 * 16K), enter:
-> port monitoring 6 source 2/3 file /flash/user_port size 3
To prevent more recent packets from overwriting older packets in the data file, if the file size is exceeded,
use the port monitoring source CLI command by entering port monitoring, followed by the user-speci-
fied session ID number, source, the slot number of the port to be monitored, a slash (/), the port number of
the port, file, the name of the file, and overwrite off.
For example, to configure port monitoring session 6 on port 2/3 with a data file called “user_port” in the
/flash directory that will not overwrite older packets if the file size is exceeded, enter:
-> port monitoring 6 source 2/3 file user_port overwrite off
To allow more recent packets from overwriting older packets in the data file if the file size is exceeded
(the default), use the port monitoring source CLI command by entering port monitoring, followed by
the user-specified session ID number, source, the slot number of the port to be monitored, a slash (/), the
port number of the port, file, the name of the file, and overwrite on.
For example, to configure port monitoring session 6 on port 2/3 with a data file called “user_port” in the
/flash directory that will not overwrite older packets if the file size is exceeded, enter:
-> port monitoring 6 source 2/3 file /flash/user_port overwrite on
Note. The size and no overwrite options can be entered on the same command line.
To configure port monitoring session 6 on port 2/3 as unidirectional and outward bound, for example,
enter:
-> port monitoring 6 source 2/3 outport
For example, to restore port monitoring session 6 on port 2/3 to its bidirectional direction, enter:
-> port monitoring 6 source 2/3 bidirectional
For example, to display port monitoring data, use the show port monitoring file command as shown
below:
-> show port monitoring file
Note. For more information about the displays that result from these commands, see the OmniSwitch
6250/6350/6450 CLI Reference Guide.
sFlow
sFlow is a network monitoring technology that gives visibility in to the activity of the network, by provid-
ing network usage information. It provides the data required to effectively control and manage the network
usage. sFlow is a sampling technology that meets the requirements for a network traffic monitoring solu-
tion.
sFlow is an industry standard with many vendors delivering products with this support. Some of the appli-
cations of the sFlow data include:
• Detecting, diagnosing, and fixing network problems
• Real-time congestion management
• Detecting unauthorized network activity
• Usage accounting and billing
• Understanding application mix
• Route profiling and peer optimization
• Capacity planning
sFlow is a sampling technology embedded within switches/routers. It provides the ability to monitor the
traffic flows. It requires a sFlow agent software process running as part of the switch software and a sFlow
collector which receives and analyses the monitored data. The sFlow collector makes use of SNMP to
communicate with a sFlow agent in order to configure sFlow monitoring on the device (switch).
sFlow agent running on the switch/router, combines interface counters and traffic flow (packet) samples
preferably on all the interfaces into sFlow datagrams that are sent across the network to a sFlow collector.
Packet sampling on the switch/router is typically performed by the switching/routing ASICs, providing
wire-speed performance. In this case, sFlow agent does very little processing, by packaging data into
sFlow datagrams that are immediately sent on network. This minimizes the memory and CPU utilization
by sFlow agent.
sFlow Manager
The sFlow manager is the controller for all the modules. It initializes all other modules. It interfaces with
the Ethernet driver to get the counter samples periodically and reads sampled packets from the Q-
Dispatcher module. The counter samples are given to the poller module and sampled packets are given to
the sampler to format a UDP. The sFlow manager also has a timer which periodically sends timer ticks to
other sections.
Each sFlow manager instance has multiples of receiver, sampler, and poller instances. Each user
programmed port will have an individual sampler and poller. The sampler and poller could be potentially
pointing to multiple receivers if the user has configured multiple destination hosts.
Receiver
The receiver module has the details about the destination hosts where the sFlow datagrams are sent out. If
there are multiple destination then each destination has an instance of the receiver. All these receivers are
attached to the sFlow manager instance and to an associated sample/poller.
Sampler
The sampler is the module which gets hardware sampled from Q-Dispatcher and fills up the sampler part
of the UDP datagram.
Poller
The poller is the module which gets counter samples from Ethernet driver and fills up the counter part of
the UDP datagram.
In addition, you can also specify optional parameters shown in the table below. These parameters can be
entered after the IP address.
keywords
timeout packet-size
forever version
udp-port
For example, to configure sFlow receiver session 6 on switch 10.255.11.28 and to specify the packet-size
and timeout value, enter:
-> sflow receiver 6 name sflowtrend address 10.255.11.28 packet-size 1400 time-
out 600
To configure a sFlow sampler session, use the sflow sampler command by entering sflow sampler,
followed by the instance ID number, the slot number of the port to be monitored, a slash (/), and the port
number and receiver, the receiver_index.
For example, to configure sampler session 1 on port 2/3, enter:
-> sflow sampler 1 2/3 receiver 6
In addition, you can also specify optional parameters shown in the table below. These parameters can be
entered after the receiver index.
keywords
rate
sample-hdr-size
For example, to configure sFlow sampler session 1 on port 2/3 and to specify the rate and sample-hdr-size,
enter:
-> sflow sampler 1 2/3 receiver 6 rate 512 sample-hdr-size 128
To configure a sFlow poller session, use the sflow poller command by entering sflow poller, followed by
the instance ID number, the slot number of the port to be monitored, a slash (/), and the port number of the
port and receiver, then receiver_index.
For example, to configure poller session 3 on port 1/1, enter:
-> sflow poller 3 1/1 receiver 6
In addition, you can also specify the optional interval parameter after the receiver index value. For exam-
ple, to configure sFlow poller session 3 on port 1/1 with an interval of 5, enter:
-> sflow poller 3 1/1 receiver 6 interval 5
Receiver 1
Name = Golden
Address = IP_V4 198.206.181.3
UDP Port = 6343
Timeout = 65535
Packet Size= 1400
DatagramVer= 5
Note. For more information about the displays that result from these commands, see the OmniSwitch 6250/
6350/6450 CLI Reference Guide.
Note. For more information about the displays that result from these commands, see the OmniSwitch
6250/6350/6450 CLI Reference Guide.
Note. For more information about the displays that result from these commands, see the OmniSwitch
6250/6350/6450 CLI Reference Guide.
Note. For more information about the displays that result from these commands, see the OmniSwitch 6250/
6350/6450 CLI Reference Guide.
To delete a sFlow sampler session, use the no form of the sflow sampler command by entering no sflow
sampler, followed by the instance ID number, the slot number of the port to delete, a slash (/), and the port
number of the port, enter:
-> no sflow sampler 1 2/3
To delete a sFlow poller session, use the no form of the sflow poller command by entering no sflow
poller, followed by the instance ID number, the slot number of the port to delete, a slash (/), and the port
number of the port, enter:
-> no sflow poller 3 1/1
C. Management frames from the NMS Workstation are sent to the mirrored port....
NMS Workstation
RMON Probe
OmniSwitch
RMON probes can be enabled or disabled through CLI commands. Configuration of Alarm threshold
values for RMON traps is a function reserved for RMON-monitoring NMS stations.
This feature supports basic RMON 4 group implementation in compliance with RFC 2819, including the
Ethernet Statistics, History (Control & Statistics), Alarms and Events groups (described below).
Note. RMON 10 group and RMON2 are not implemented in the current release. An external RMON probe
that includes RMON 10 group and RMON2 may be used where full RMON probe functionality is
required.
Ethernet Statistics
Ethernet statistics probes are created whenever new ports are inserted and activated in the chassis. When a
port is removed from the chassis or deactivated, the Ethernet statistics group entry associated with the
physical port is invalidated and the probe is deleted.
The Ethernet statistics group includes port utilization and error statistics measured by the RMON probe for
each monitored Ethernet interface on the switch. Examples of these statistics include CRC (Cyclic Redun-
dancy Check)/alignment, undersized/oversized packets, fragments, broadcast/multicast/unicast, and band-
width utilization statistics.
Alarm
The Alarm group collects periodic statistical samples from variables in the probe and compares them to
previously configured thresholds. If a sample crosses a previously configured threshold value, an Event is
generated. Examples include Absolute or Relative Values, Rising or Falling Thresholds on the Utilization
Frame Count and CRC Errors.
Event
The Event group controls generation and notification of events from the switch to NMS stations. For
example, customized reports based on the type of Alarm can be generated, printed and/or logged.
Note. The following RMON groups are not implemented: Host, HostTopN, Matrix, Filter, and Packet
Capture.
To enable or disable an entire group of RMON probes of a particular flavor type (such as Ethernet
Statistics, History, or Alarm), enter the command without specifying an entry-number, as shown in the
following examples.
The following command disables all currently defined (disabled) RMON Ethernet Statistics probes:
-> rmon probes stats disable
The following command enables all currently defined (disabled) RMON History probes:
-> rmon probes history enable
The following command enables all currently defined (disabled) RMON Alarm probes:
-> rmon probes alarm enable
Note. Network activity on subnetworks attached to an RMON probe can be monitored by Network
Management Software (NMS) applications.
A display showing all current statistics RMON probes should appear, as shown in the following example:
Entry Slot/Port Flavor Status Duration System Resources
-------+-----------+-----------+----------+---------------+---------------------
4001 4/1 Ethernet Active 00:25:00 275 bytes
4008 4/8 Ethernet Active 00:25:00 275 bytes
4005 4/5 Ethernet Active 00:25:00 275 bytes
This table entry displays probe statistics for all probes on the switch. The probes are active, utilize 275
bytes of memory, and 25 minutes have elapsed since the last change in status occurred.
To show a list of the history probes, enter:
-> show rmon probes history
A display showing all current history RMON probes should appear, as shown in the following example:
Entry Slot/Port Flavor Status Duration System Resources
-------+----------+---------+-----------+------------+----------------
1 1/1 History Active 92:52:20 5464 bytes
30562 1/35 History Active 00:31:22 312236 bytes
30817 1/47 History Active 00:07:31 5200236 bytes
The table entry displays statistics for RMON History probes on the switch.
To show a list of the alarm probes, enter:
-> show rmon probes alarm
A display showing all current alarm RMON probes should appear, as shown in the following example:
Entry Slot/Port Flavor Status Duration System Resources
-------+-----------+-----------+----------+---------------+--------------------
31927 1/35 Alarm Active 00:25:51 608 bytes
A display showing statistics for the specified RMON probe will appear, as shown in the following
sections.
A display showing all logged RMON Events should appear, as shown in the following example:
Entry Time Description
---------+----------------+-----------------------------------------------------
1 00:08:00 etherStatsPkts.4008: [Falling trap] “Falling Event”
2 00:26:00 etherStatsCollisions.2008: “Rising Event”
3 00:39:00 etherStatsCollisions.2008: “Rising Event”
The display shown above identifies the Entry number of the specified Event, along with the elapsed time
since the last change in status (measured in hours/minutes/seconds) and a description of the Alarm condi-
tion detected by the probe for all RMON Logged Events. For example, Entry number 3 is linked to ether-
StatsCollisions.2008: [Rising trap] “Rising Event,” an Alarm condition detected by the RMON probe in
which a trap was generated based on a Rising Threshold Alarm, with an elapsed time of 39 minutes since
the last change in status.
A display showing the specific logged RMON Event should appear, as shown in the following example:
Entry Time Description
---------+----------------+-----------------------------------------------------
3 00:39:00 etherStatsCollisions.2008: “Rising Event”
The display shown above identifies the Entry number of the specified Event, along with the elapsed time
since the last change in status (measured in hours/minutes/seconds) and a description of the Alarm condi-
tion detected by the probe for the specific RMON Logged Event. For example, Entry number 3 is linked to
etherStatsCollisions.2008: [Rising trap] “Rising Event,” an Alarm condition detected by the RMON probe
in which a trap was generated based on a Rising Threshold Alarm, with an elapsed time of 39 minutes
since the last change in status.
NMS Workstation
OmniSwitch
The following sections include a discussion of CLI commands that can be used to configure resource
parameters and monitor or reset statistics for switch resources. These commands include:
• health threshold—Configures threshold limits for input traffic (RX), output/input traffic (TX/RX),
memory usage, CPU usage, and chassis temperature. See page 43-42 for more information.
• show health threshold—Displays current health threshold settings. See page 43-45 for details.
• health threshold port-trap—Enables or disables health threshold monitoring on a slot, port, or a
range of ports. See page 43-45 for details.
• show health threshold port-trap—Displays the current status of the health threshold settings for a
slot, port, or a range of ports. See page 43-45 for details.
• health interval—Configures sampling interval between health statistics checks. See page 43-45 for
more information.
• show health interval—Displays current health sampling interval, measured in seconds. See page
43-46 for details.
• show health —Displays health statistics for the switch, as percentages of total resource capacity. See
page 43-46 for more information.
• health statistics reset—Resets health statistics for the switch. See page 43-48 for details.
Note. When a resource falls back below the configured threshold, an addition trap is sent to the user. This
indicates that the resource is no longer operating beyond its configured threshold limit.
The health threshold command is used to configure threshold limits for input traffic (RX), output/input
traffic (TX/RX), memory usage, CPU usage and chassis temperature.
The health threshold port-trap command is used to enable or disable the health threshold monitoring on
the user ports. Health threshold monitoring traps can be enabled only on uplink ports or only on a set of
configured ports. This is to prevent the NMS from being flooded with too many threshold monitoring
messages in big networks and prevent overwriting of threshold monitoring traps.
To configure thresholds for these resources, enter the health threshold command, followed by the input
traffic, output/input traffic, memory usage, CPU usage, or chassis temperature value, where:
For example, to specify a CPU usage threshold of 85 percent, enter the following command:
-> health threshold cpu 85
Note. Do not configure the port health threshold (Rx and TxRx) value close to the line rate (rate at which
traffic is sent). For example, if the traffic is sent at 50 % line rate, then configure the health threshold
value of about 80% and not about 60%.
For more information on the health threshold command, refer to Chapter 42, “Health Monitoring
Commands,” in the OmniSwitch 6250/6350/6450 CLI Reference Guide.
Note. When you specify a new value for a threshold limit, the value is automatically applied across all
levels of the switch (switch, module, and port). You cannot select differing values for each level.
To disable health threshold monitoring on port 1/2, enter the following command:
-> health threshold port-trap 1/2 disable
To disable health threshold monitoring on range of ports from 1/1 to 1/4, enter the following command:
-> health threshold port-trap 1/3-6 disable
Note. To verify health threshold monitoring settings for a slot, port, or a range of ports, use the
show health threshold port-trap command. For example:
-> show health threshold port-trap 1
Slot/Port Status
----------+----------
1/1 enabled
1/2 disabled
1/3 disabled
1/4 disabled
1/5 disabled
1/6 disabled
1/7 enabled
.
.
.
1/26 enabled
To display a specific health threshold, enter the show health threshold command, followed by the appro-
priate suffix syntax:
• rx
• txrx
• memory
• cpu
• temperature
For example, if you want to view only the health threshold for memory usage, enter the following
command:
-> show health threshold memory
Memory Threshold = 80
Note. For detailed definitions of each of the threshold types, refer to “Configuring Resource and Tempera-
ture Thresholds” on page 43-42, as well as Chapter 42, “Health Monitoring Commands,” in the
OmniSwitch 6250/6350/6450 CLI Reference Guide.
Valid values for the seconds parameter include 1, 2, 3, 4, 5, 6, 10, 12, 15, 20, or 30.
In the screen sample shown above, the Device Resources field displays the device resources that are being
measured (for example, Receive displays statistics for traffic received by the switch; Transmit/Receive
displays statistics for traffic transmitted and received by the switch; Memory displays statistics for switch
memory; and CPU displays statistics for the switch CPU). The Limit field displays currently configured
device threshold levels as percentages of available bandwidth. The Curr field displays current bandwidth
usage for the specified device resource. 1 Min. Avg. refers to the average device bandwidth used over a 1
minute period. 1 Hr. Avg. refers to the average device bandwidth used over a 1 hour period, and 1 Hr.
Max. refers to the maximum device bandwidth used over a 1 hour period.
Note. If the Current value appears with an asterisk displayed next to it, the Current value exceeds the
Threshold limit. For example, if the Current value for Memory is displayed as 85* and the Threshold
Limit is displayed as 80, the asterisk indicates that the Current value has exceeded the Threshold Limit
value.
In the screen sample shown above, the port 04/03 Resources field displays the port resources that are
being measured (for example, Receive displays statistics for traffic received by the switch, while Trans-
mit/Receive displays statistics for traffic transmitted and received by the switch). The Limit field displays
currently configured resource threshold levels as percentages of available bandwidth. The Curr field
displays current bandwidth usage for the specified resource. 1 Min. Avg. refers to the average resource
bandwidth used over a 1 minute period. 1 Hr. Avg. refers to the average resource bandwidth used over a 1
hour period, and 1 Hr. Max. refers to the maximum resource bandwidth used over a 1 hour period.
Switch logging is an event logging utility that is useful in maintaining and servicing the switch. Switch
logging uses a formatted string mechanism to either record or discard event data from switch applications.
The log records are copied to the output devices configured for the switch. Log records can be sent to a
text file and written into the flash file system. The log records can also be scrolled to the switch console or
to a remote IP address.
Switch logging information can be customized and configured through Command Line Interface (CLI)
commands, WebView, and SNMP. Log information can be helpful in resolving configuration or
authentication issues, as well as general switch errors.
This chapter describes the switch logging feature, how to configure it and display switch logging
information through the Command Line Interface (CLI). CLI commands are used in the configuration
examples. For more details about the syntax of commands, see the OmniSwitch 6250/6350/6450 CLI
Reference Guide.
In This Chapter
The following procedures are described:
• “Enabling Switch Logging” on page 44-6
• “Setting the Switch Logging Severity Level” on page 44-6
• “Specifying the Switch Logging Output Device” on page 44-9
• “Displaying Switch Logging Status” on page 44-10
• “Configuring the Switch Logging File Size” on page 44-10
• “Configuring Password to View the Switch Logging Data” on page 44-11
• “Displaying Switch Logging Records” on page 44-12
Note.
Switch logging commands are not intended for use with low-level hardware and software debugging. It is
recommended that you contact an Alcatel Customer Service representative for assistance with debugging
functions.
The console messages "+++ healthMonCpuStatus Crossed Below The Threshold Limit " can be seen on
switch bootup if it is configured to receive health monitoring debug messages on console or swlog file
using the swlog appid and swlog output commands.
-> swlog
2 Specify the ID of the application to be logged along with the logging severity level.
Here, the application ID specifies bridging and the severity is set to the “warning” level.
3 Specify the output device to which the switch logging information is sent.
In this example, the switch logging information is sent to the console port.
Note. Optional. To verify the switch logging configuration, enter the show swlog command. The display
is similar to the following output:
-> show swlog
Application ID Level
--------------------+----------------
For more information about this command, or the “Switch Logging Commands” chapter in the OmniS-
witch 6250/6350/6450 CLI Reference Guide.
Notes. Although switch logging provides complementary functionality to switch debugging facilities, the
switch logging commands are not intended for use with low-level hardware and software debugging
functions.
The configuration snapshot command can be used to capture and save all switch logging configuration
settings in a text file that can be viewed, edited, and used as a configuration file. See the “Working with
Configuration Files” chapter of the OmniSwitch 6250/6350/6450 Switch Management Guide.
Numeric
CLI Keyword Application ID
Equivalent
IDLE 255 APPID_IDLE
DIAG 0 APPID_DIAGNOSTICS
IPC-DIAG 1 APPID_IPC_DIAGNOSTICS
QDRIVER 2 APPID_QDRIVER
QDISPATCHER 3 APPID_QDISPATCHER
IPC-LINK 4 APPID_IPC_LINK
NI-SUPERVISION 5 APPID_NI_SUP_AND_PROBER
INTERFACE 6 APPID_ESM_DRIVER
802.1Q 7 APPID_802.1Q
VLAN 8 APPID_VLAN_MGR
GM 9 APPID_GROUPMOBILITY (RESERVED)
BRIDGE 10 APPID_SRCLEANING
Numeric
CLI Keyword Application ID
Equivalent
STP 11 APPID_SPANNINGTREE
LINKAGG 12 APPID_LINKAGGREGATION
QOS 13 APPID_QOS
RSVP 14 APPID_RSVP
IP 15 APPID_IP
IPMS 17 APPID_IPMS
AMAP 18 APPID_XMAP
GMAP 19 APPID_GMAP
AAA 20 APPID_AAA
IPC-MON 21 APPID_IPC_MON
IP-HELPER 22 APPID_BOOTP_RELAY
PMM 23 APPID_MIRRORING_MONITORING
MODULE 24 APPID_L3HRE
SLB 25 APPID_SLB
EIPC 26 APPID_EIPC
CHASSIS 64 APPID_CHASSISUPER
PORT-MGR 65 APPID_PORT_MANAGER
CONFIG 66 APPID_CONFIGMANAGER
CLI 67 APPID_CLI
SNMP 68 APPID_SNMP_AGENT
WEB 69 APPID_WEBMGT
MIPGW 70 APPID_MIPGW
SESSION 71 APPID_SESSION_MANAGER
TRAP 72 APPID_TRAP_MANAGER
POLICY 73 APPID_POLICY_MANAGER
DRC 74 APPID_DRC
SYSTEM 75 APPID_SYSTEM_SERVICES
HEALTH 76 APPID_HEALTHMON
NAN-DRIVER 78 APPID_NAN_DRIVER
RMON 79 APPID_RMON
TELNET 80 APPID_TELNET
PSM 81 APPID_PSM
FTP 82 APPID_FTP
SMNI 83 APPID_SMNI
DISTRIB 84 APPID_DISTRIB
Numeric
CLI Keyword Application ID
Equivalent
EPILOGUE 85 APPID_EPILOGUE
LDAP 86 APPID_LDAP
NOSNMP 87 APPID_NOSNMP
SSL 88 APPID_SSL
DBGGW 89 APPID_DBGGW
LANPOWER 108 APPID_LANPOWER
Note. The console messages "+++ healthMonCpuStatus Crossed Below The Threshold Limit " can be
seen on switch bootup if it is configured to receive health monitoring debug messages on console or swlog
file using the swlog appid and swlog output commands.
The following syntax assigns the “warning” severity level (or 5) to the “system” application (ID number
75) by using the severity level and application names.
-> swlog appid system level warning
The following command makes the same assignment by using the severity level and application numbers.
-> swlog appid 75 level 3
To disable the switch logging output to the console, enter the following command:
-> no swlog output console
To disable the switch logging output to flash memory, enter the following command:
-> no swlog output flash
Note. You can also send syslog files to multiple hosts (maximum of twelve).
For this example, switch logging is enabled. Switch logging information is being sent to the switch’s flash
memory and to the console. Additionally, the severity level for the chassis application ID has been set to
the “debug3” (or “9”) severity level.
Note. Use the ls command, which is described in the OmniSwitch 6250/6350/6450 Switch Management
Guide, to determine the amount of available flash memory.
For example, to set the switch logging file to 500000 bytes enter:
-> swlog output flash file-size 500000
This command causes the switch to clear all the switch logging information and begin recording again. As
a result, the switch displays a shorter file when you execute the show log swlog command. You can use
the swlog clear command when the switch logging display is too long due to some of the data being old or
out of date.
No confirmation message appears on the screen.
Note. Switch logging frequently records a large volume of data. It can take several minutes for all the
switch logging information to scroll to the console screen.
------------------------+-----------+-------+--------------------------------
MON NOV 11 12:42:11 2005 SYSTEM info Switch Logging files cleared by command
MON NOV 11 13:07:26 2005 WEB info The HTTP session login successful!
MON NOV 11 13:18:24 2005 WEB info The HTTP session login successful!
MON NOV 11 13:24:03 2005 TELNET info New telnet connection, Address,
128.251.30.88
MON NOV 11 13:24:03 2005 TELNET info Session 4, Created
MON NOV 11 13:59:04 2005 WEB info The HTTP session user logout successful!
The fields in the show log swlog output are defined as follows:
• The FILE ID field specifies the File name (for example, swlog1.log), endPtr Global Sequence ID
reference number (for example, 9968), Configuration Size (for example, 10000), Current Size (for
example, 10000), and Mode (for example, 2).
• The Timestamp field indicates when the swlog entry occurred (for example, MON, NOV 11, 12:42:11
2005).
• The Application field specifies the application ID for which the stored swlog information is displayed
(for example, SYSTEM).
• The Level field specifies the severity level for which the stored information is displayed (for example,
Warning).
• The Log Message field specifies the condition recorded by the switch logging feature. The
information in this field usually wraps around to the next line of the screen display as shown in this
example.
This appendix contains Alcatel-Lucent and third-party software vendor license and copyright statements.
IMPORTANT. Please read the terms and conditions of this license agreement carefully before opening
this package.
By opening this package, you accept and agree to the terms of this license agreement. If you are not
willing to be bound by the terms of this license agreement, do not open this package. Please
promptly return the product and any materials in unopened form to the place where you obtained it
for a full refund.
1. License Grant. This is a license, not a sales agreement, between you (the “Licensee”) and Alcatel-
Lucent. Alcatel-Lucent hereby grants to Licensee, and Licensee accepts, a non-exclusive license to use
program media and computer software contained therein (the “Licensed Files”) and the accompanying
user documentation (collectively the “Licensed Materials”), only as authorized in this License Agreement.
Licensee, subject to the terms of this License Agreement, may use one copy of the Licensed Files on the
Licensee’s system. Licensee agrees not to assign, sublicense, transfer, pledge, lease, rent, or share their
rights under this License Agreement. Licensee may retain the program media for backup purposes with
retention of the copyright and other proprietary notices. Except as authorized under this paragraph, no
copies of the Licensed Materials or any portions thereof may be made by Licensee and Licensee shall not
modify, decompile, disassemble, reverse engineer, or otherwise attempt to derive the Source Code.
Licensee is also advised that Alcatel-Lucent products contain embedded software known as firmware
which resides in silicon. Licensee may not copy the firmware or transfer the firmware to another medium.
2. Alcatel-Lucent’s Rights. Licensee acknowledges and agrees that the Licensed Materials are the sole
property of Alcatel-Lucent and its licensors (herein “its licensors”), protected by U.S. copyright law, trade-
mark law, and are licensed on a right to use basis. Licensee further acknowledges and agrees that all rights,
title, and interest in and to the Licensed Materials are and shall remain with Alcatel-Lucent and its licen-
sors and that no such right, license, or interest shall be asserted with respect to such copyrights and trade-
marks. This License Agreement does not convey to Licensee an interest in or to the Licensed Materials,
but only a limited right to use revocable in accordance with the terms of this License Agreement.
3. Confidentiality. Alcatel-Lucent considers the Licensed Files to contain valuable trade secrets of
Alcatel-Lucent, the unauthorized disclosure of which could cause irreparable harm to Alcatel-Lucent.
Except as expressly set forth herein, Licensee agrees to use reasonable efforts not to disclose the Licensed
Files to any third party and not to use the Licensed Files other than for the purpose authorized by this
License Agreement. This confidentiality obligation shall continue after any termination of this License
Agreement.
4. Indemnity. Licensee agrees to indemnify, defend and hold Alcatel-Lucent harmless from any claim,
lawsuit, legal proceeding, settlement or judgment (including without limitation Alcatel-Lucent’s reason-
able United States and local attorneys’ and expert witnesses’ fees and costs) arising out of or in connec-
tion with the unauthorized copying, marketing, performance or distribution of the Licensed Files.
5. Limited Warranty. Alcatel-Lucent warrants, for Licensee’s benefit alone, that the program media
shall, for a period of ninety (90) days from the date of commencement of this License Agreement (referred
to as the Warranty Period), be free from defects in material and workmanship. Alcatel-Lucent further
warrants, for Licensee benefit alone, that during the Warranty Period the Licensed Files shall operate
substantially in accordance with the functional specifications in the User Guide. If during the Warranty
Period, a defect in the Licensed Files appears, Licensee may return the Licensed Files to Alcatel-Lucent
for either replacement or, if so elected by Alcatel-Lucent, refund of amounts paid by Licensee under this
License Agreement. EXCEPT FOR THE WARRANTIES SET FORTH ABOVE, THE LICENSED
MATERIALS ARE LICENSED “AS IS” AND ALCATEL-LUCENT AND ITS LICENSORS
DISCLAIM ANY AND ALL OTHER WARRANTIES, WHETHER EXPRESS OR IMPLIED, INCLUD-
ING (WITHOUT LIMITATION) ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. SOME STATES DO NOT ALLOW THE EXCLUSION
OF IMPLIED WARRANTIES SO THE ABOVE EXCLUSIONS MAY NOT APPLY TO LICENSEE.
THIS WARRANTY GIVES THE LICENSEE SPECIFIC LEGAL RIGHTS. LICENSEE MAY ALSO
HAVE OTHER RIGHTS WHICH VARY FROM STATE TO STATE.
6. Limitation of Liability. Alcatel-Lucent’s cumulative liability to Licensee or any other party for any
loss or damages resulting from any claims, demands, or actions arising out of or relating to this License
Agreement shall not exceed the license fee paid to Alcatel-Lucent for the Licensed Materials. IN NO
EVENT SHALL ALCATEL-LUCENT BE LIABLE FOR ANY INDIRECT, INCIDENTAL, CONSE-
QUENTIAL, SPECIAL, OR EXEMPLARY DAMAGES OR LOST PROFITS, EVEN IF ALCATEL-
LUCENT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO
NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY FOR INCIDENTAL OR CONSE-
QUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION TO INCIDENTAL OR
CONSEQUENTIAL DAMAGES MAY NOT APPLY TO LICENSEE.
7. Export Control. This product is subject to the jurisdiction of the United States. Licensee may not
export or reexport the Licensed Files, without complying with all United States export laws and regula-
tions, including but not limited to (i) obtaining prior authorization from the U.S. Department of Commerce
if a validated export license is required, and (ii) obtaining “written assurances” from licensees, if required.
8. Support and Maintenance. Except as may be provided in a separate agreement between Alcatel-
Lucent and Licensee, if any, Alcatel-Lucent is under no obligation to maintain or support the copies of the
Licensed Files made and distributed hereunder and Alcatel-Lucent has no obligation to furnish Licensee
with any further assistance, documentation or information of any nature or kind.
9. Term. This License Agreement is effective upon Licensee opening this package and shall continue until
terminated. Licensee may terminate this License Agreement at any time by returning the Licensed Materi-
als and all copies thereof and extracts therefrom to Alcatel-Lucent and certifying to Alcatel-Lucent in writ-
ing that all Licensed Materials and all copies thereof and extracts therefrom have been returned or erased
by the memory of Licensee’s computer or made non-readable. Alcatel-Lucent may terminate this License
Agreement upon the breach by Licensee of any term hereof. Upon such termination by Alcatel-Lucent,
Licensee agrees to return to Alcatel-Lucent or destroy the Licensed Materials and all copies and portions
thereof.
10. Governing Law. This License Agreement shall be construed and governed in accordance with the
laws of the State of California.
11. Severability. Should any term of this License Agreement be declared void or unenforceable by any
court of competent jurisdiction, such declaration shall have no effect on the remaining terms herein.
12. No Waiver. The failure of either party to enforce any rights granted hereunder or to take action against
the other party in the event of any breach hereunder shall not be deemed a waiver by that party as to
subsequent enforcement of rights or subsequent actions in the event of future breaches.
13. Notes to United States Government Users. Software and documentation are provided with restricted
rights. Use, duplication or disclosure by the government is subject to (i) restrictions set forth in GSA ADP
Schedule Contract with Alcatel-Lucent’s reseller(s), or (ii) restrictions set forth in subparagraph (c) (1)
and (2) of 48 CFR 52.227-19, as applicable.
14.Third Party Materials. Licensee is notified that the Licensed Files contain third party software and
materials licensed to Alcatel-Lucent by certain third party licensors. Some third party licensors (e.g., Wind
River and their licensors with respect to the Run-Time Module) are third part beneficiaries to this License
Agreement with full rights of enforcement. Please refer to the section entitled “Third Party Licenses and
Notices” on page A-4 for the third party license and notice terms.
2 Redistributions in binary form must reproduce applicable copyright statements and notices, this list of
conditions, and the following disclaimer in the documentation and/or other materials provided with the
distribution.
3 Redistributions must contain a verbatim copy of this document.
4 The names and trademarks of the authors and copyright holders must not be used in advertising or
otherwise to promote the sale, use or other dealing in this Software without specific, written prior permis-
sion.
6 The OpenLDAP Foundation may revise this license from time to time. Each revision is distinguished
by a version number. You may use the Software under terms of this license revision or under the terms of
any subsequent revision of the license.
THIS SOFTWARE IS PROVIDED BY THE OPENLDAP FOUNDATION AND CONTRIBUTORS “AS
IS” AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OPENLDAP FOUNDATION OR ITS
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEM-
PLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCURE-
MENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
OpenLDAP is a trademark of the OpenLDAP Foundation.
Copyright 1999-2000 The OpenLDAP Foundation, Redwood City,
California, USA. All Rights Reserved. Permission to copy and
distributed verbatim copies of this document is granted.
C. Linux
Linux is written and distributed under the GNU General Public License which means that its source code
is freely-distributed and available to the general public.
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By
contrast, the GNU General Public License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This General Public License applies to most of
the Free Software Foundation’s software and to any other program whose authors commit to using it.
(Some other Free Software Foundation software is covered by the GNU Library General Public License
instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are
designed to make sure that you have the freedom to distribute copies of free software (and charge for this
service if you wish), that you receive source code or can get it if you want it, that you can change the soft-
ware or use pieces of it in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask
you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute
copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the
recipients all the rights that you have. You must make sure that they, too, receive or can get the source
code. And you must show them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which
gives you legal permission to copy, distribute and/or modify the software.
Also, for each author’s protection and ours, we want to make certain that everyone understands that there
is no warranty for this free software. If the software is modified by someone else and passed on, we want
its recipients to know that what they have is not the original, so that any problems introduced by others
will not reflect on the original authors’ reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that
redistributors of a free program will individually obtain patent licenses, in effect making the program
proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone’s free use
or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRI-
BUTION AND MODIFICATION
0 This License applies to any program or other work which contains a notice placed by the copyright
holder saying it may be distributed under the terms of this General Public License. The “Program”, below,
refers to any such program or work, and a “work based on the Program” means either the Program or any
derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either
verbatim or with modifications and/or translated into another language. (Hereinafter, translation is
included without limitation in the term “modification”.) Each licensee is addressed as “you”.
Activities other than copying, distribution and modification are not covered by this License; they are
outside its scope. The act of running the Program is not restricted, and the output from the Program is
covered only if its contents constitute a work based on the Program (independent of having been made by
running the Program). Whether that is true depends on what the Program does.
1 You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any
medium, provided that you conspicuously and appropriately publish on each copy an appropriate copy-
right notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the
absence of any warranty; and give any other recipients of the Program a copy of this License along with
the Program.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer
warranty protection in exchange for a fee.
2 You may modify your copy or copies of the Program or any portion of it, thus forming a work based on
the Program, and copy and distribute such modifications or work under the terms of Section 1 above,
provided that you also meet all of these conditions:
a You must cause the modified files to carry prominent notices stating that you changed the files and
the date of any change.
b You must cause any work that you distribute or publish, that in whole or in part contains or is
derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties
under the terms of this License.
c If the modified program normally reads commands interactively when run, you must cause it, when
started running for such interactive use in the most ordinary way, to print or display an announcement
including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you
provide a warranty) and that users may redistribute the program under these conditions, and telling the
user how to view a copy of this License. (Exception: if the Program itself is interactive but does not
normally print such an announcement, your work based on the Program is not required to print an
announcement.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not
derived from the Program, and can be reasonably considered independent and separate works in them-
selves, then this License, and its terms, do not apply to those sections when you distribute them as sepa-
rate works. But when you distribute the same sections as part of a whole which is a work based on the
Program, the distribution of the whole must be on the terms of this License, whose permissions for other
licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is
not the intent of this section to claim rights or contest your rights to work written entirely by you; rather,
the intent is to exercise the right to control the distribution of derivative or collective works based on the
Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work
based on the Program) on a volume of a storage or distribution medium does not bring the other work
under the scope of this License.
3 You may copy and distribute the Program (or a work based on it, under Section 2) in object code or
executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a Accompany it with the complete corresponding machine-readable source code, which must be
distributed under the terms of Sections 1 and 2 above on a medium customarily used for software inter-
change; or,
b Accompany it with a written offer, valid for at least three years, to give any third party, for a charge
no more than your cost of physically performing source distribution, a complete machine-readable
copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a
medium customarily used for software interchange; or,
c Accompany it with the information you received as to the offer to distribute corresponding source
code. (This alternative is allowed only for noncommercial distribution and only if you received the
program in object code or executable form with such an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for making modifications to it. For an
executable work, complete source code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to control compilation and installation of the
executable. However, as a special exception, the source code distributed need not include anything that is
normally distributed (in either source or binary form) with the major components (compiler, kernel, and so
on) of the operating system on which the executable runs, unless that component itself accompanies the
executable.
If distribution of executable or object code is made by offering access to copy from a designated place,
then offering equivalent access to copy the source code from the same place counts as distribution of the
source code, even though third parties are not compelled to copy the source along with the object code.
4 You may not copy, modify, sublicense, or distribute the Program except as expressly provided under
this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will
automatically terminate your rights under this License. However, parties who have received copies, or
rights, from you under this License will not have their licenses terminated so long as such parties remain
in full compliance.
5 You are not required to accept this License, since you have not signed it. However, nothing else grants
you permission to modify or distribute the Program or its derivative works. These actions are prohibited
by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any
work based on the Program), you indicate your acceptance of this License to do so, and all its terms and
conditions for copying, distributing or modifying the Program or works based on it.
6 Each time you redistribute the Program (or any work based on the Program), the recipient automati-
cally receives a license from the original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the
rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
7 If, as a consequence of a court judgment or allegation of patent infringement or for any other reason
(not limited to patent issues), conditions are imposed on you (whether by court order, agreement or other-
wise) that contradict the conditions of this License, they do not excuse you from the conditions of this
License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and
any other pertinent obligations, then as a consequence you may not distribute the Program at all. For
example, if a patent license would not permit royalty-free redistribution of the Program by all those who
receive copies directly or indirectly through you, then the only way you could satisfy both it and this
License would be to refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the
balance of the section is intended to apply and the section as a whole is intended to apply in other circum-
stances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or
to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the
free software distribution system, which is implemented by public license practices. Many people have
made generous contributions to the wide range of software distributed through that system in reliance on
consistent application of that system; it is up to the author/donor to decide if he or she is willing to distrib-
ute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this
License.
8 If the distribution and/or use of the Program is restricted in certain countries either by patents or by
copyrighted interfaces, the original copyright holder who places the Program under this License may add
an explicit geographical distribution limitation excluding those countries, so that distribution is permitted
only in or among countries not thus excluded. In such case, this License incorporates the limitation as if
written in the body of this License.
9 The Free Software Foundation may publish revised and/or new versions of the General Public License
from time to time. Such new versions will be similar in spirit to the present version, but may differ in
detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies a version number of this
License which applies to it and “any later version”, you have the option of following the terms and condi-
tions either of that version or of any later version published by the Free Software Foundation. If the
Program does not specify a version number of this License, you may choose any version ever published by
the Free Software Foundation.
10 If you wish to incorporate parts of the Program into other free programs whose distribution conditions
are different, write to the author to ask for permission. For software which is copyrighted by the Free Soft-
ware Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our
decision will be guided by the two goals of preserving the free status of all derivatives of our free soft-
ware and of promoting the sharing and reuse of software generally.
NO WARRANTY
E. University of California
Provided with this product is certain TCP input and Telnet client software developed by the University of
California, Berkeley.
Copyright (C) 1987. The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms are permitted provided that the above copyright notice
and this paragraph are duplicated in all such forms and that any documentation, advertising materials, and
other materials related to such distribution and use acknowledge that the software was developed by the
University of California, Berkeley. The name of the University may not be used to endorse or promote
products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
F. Carnegie-Mellon University
Provided with this product is certain BOOTP Relay software developed by Carnegie-Mellon University.
G. Random.c
PR 30872 B Kesner created May 5 2000
PR 30872 B Kesner June 16 2000 moved batch_entropy_process to own task iWhirlpool to make code
more efficient
random.c -- A strong random number generator
Version 1.89, last modified 19-Sep-99
Copyright Theodore Ts’o, 1994, 1995, 1996, 1997, 1998, 1999. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided
that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, and the entire permission notice
in its entirety, including the disclaimer of warranties.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials provided with the distribution.
3. The name of the author may not be used to endorse or promote products derived from this software
without specific prior written permission. ALTERNATIVELY, this product may be distributed under the
terms of the GNU Public License, in which case the provisions of the GPL are required INSTEAD OF the
above restrictions. (This clause is necessary due to a potential bad interaction between the GPL and the
restrictions contained in a BSD-style copyright.)
THIS SOFTWARE IS PROVIDED “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE, ALL OF WHICH ARE HEREBY DISCLAIMED. IN
NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROF-
ITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABIL-
ITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF NOT
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
H. Apptitude, Inc.
Provided with this product is certain network monitoring software (“MeterWorks/RMON”) licensed from
Apptitude, Inc., whose copyright notice is as follows: Copyright (C) 1997-1999 by Apptitude, Inc. All
Rights Reserved. Licensee is notified that Apptitude, Inc. (formerly, Technically Elite, Inc.), a California
corporation with principal offices at 6330 San Ignacio Avenue, San Jose, California, is a third party bene-
ficiary to the Software License Agreement. The provisions of the Software License Agreement as applied
to MeterWorks/RMON are made expressly for the benefit of Apptitude, Inc., and are enforceable by
Apptitude, Inc. in addition to Alcatel-Lucent. IN NO EVENT SHALL APPTITUDE, INC. OR ITS
SUPPLIERS BE LIABLE FOR ANY DAMAGES, INCLUDING COSTS OF PROCUREMENT OF
SUBSTITUTE PRODUCTS OR SERVICES, LOST PROFITS, OR ANY SPECIAL, INDIRECT,
CONSEQUENTIAL OR INCIDENTAL DAMAGES, HOWEVER CAUSED AND ON ANY THEORY
OF LIABILITY, ARISING IN ANY WAY OUT OF THIS AGREEMENT.
I. Agranat
Provided with this product is certain web server software (“EMWEB PRODUCT”) licensed from Agranat
Systems, Inc. (“Agranat”). Agranat has granted to Alcatel-Lucent certain warranties of performance,
which warranties [or portion thereof] Alcatel-Lucent now extends to Licensee. IN NO EVENT,
HOWEVER, SHALL AGRANAT BE LIABLE TO LICENSEE FOR ANY INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES OF LICENSEE OR A THIRD PARTY AGAINST LICENSEE ARIS-
ING OUT OF, OR IN CONNECTION WITH, THIS DISTRIBUTION OF EMWEB PRODUCT TO
LICENSEE. In case of any termination of the Software License Agreement between Alcatel-Lucent and
Licensee, Licensee shall immediately return the EMWEB Product and any back-up copy to Alcatel-
Lucent, and will certify to Alcatel-Lucent in writing that all EMWEB Product components and any copies
of the software have been returned or erased by the memory of Licensee’s computer or made non-read-
able.
N. Remote-ni
Provided with this product is a file (part of GDB), the GNU debugger and is licensed from Free Software
Foundation, Inc., whose copyright notice is as follows: Copyright (C) 1989, 1991, 1992 by Free Software
Foundation, Inc. Licensee can redistribute this software and modify it under the terms of General Public
License as published by Free Software Foundation Inc.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without
even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
O. GNU Zip
GNU Zip -- A compression utility which compresses the files with zip algorithm.
Copyright (C) 1992-1993 Jean-loup Gailly.
BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR
THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO
THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
Copyright (C) by Beman Dawes, David Abrahams, 1998-2003. All rights reserved.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-
INFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR ANYONE
DISTRIBUTING THE SOFTWARE BE LIABLE FOR ANY DAMAGES OR OTHER
LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.
R. U-Boot
Provided with this product is a software licensed from Free Software Foundation Inc. This is used as OS
Bootloader; and located in on-board flash. This product is standalone and not linked (statically or dynami-
cally) to any other software.
Version 1.1.0
Copyright (C) 2000-2004. All rights reserved.
S. Solaris
Provided with this product is free software; Licensee can redistribute it and/or modify it under the terms of
the GNU General Public License.
Copyright (C) 1992-1993 Jean-loup Gailly. All rights reserved.
4. Neither the name of the University nor the names of its contributors may be used to
endorse or promote products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS “AS IS'' AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE. FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL.
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS.
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION). HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT. LIABIL-
ITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The copyright of the products such as crypto, dhcp, net, netinet, netinet6, netley, netwrs, libinet6 are same
as that of the internet protocol version 6.
U. CURSES
Copyright (C) 1987. The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms are permitted provided that the above copyright notice
and this paragraph are duplicated in all such forms and that any documentation, advertising materials, and
other materials related to such distribution and use acknowledge that the software was developed by the
University of California, Berkeley. The name of the University may not be used to endorse or promote
products derived from this software without specific prior written permission.
V. ZModem
Provided with this product is a program or code that can be used without any restriction.
Copyright (C) 1986 Gary S. Brown. All rights reserved.
X. OpenLDAP
Provided with this software is an open source implementation of the Lightweight Directory Access Proto-
col (LDAP).
Version 3
Copyright (C) 1990, 1998, 1999, Regents of the University of Michigan, A. Hartgers, Juan C. Gomez. All
rights reserved.
This software is not subject to any license of Eindhoven University of Technology.Redistribution and use
in source and binary forms are permitted only as authorized by the OpenLDAP Public License.
This software is not subject to any license of Silicon Graphics Inc.or Purdue University. Redistribution and
use in source and binary forms are permitted without restriction or fee of any kind as long as this notice is
preserved.
Y. BITMAP.C
Provided with this product is a program for personal and non-profit use.
Copyright (C) Allen I. Holub, All rights reserved.
Z. University of Toronto
Provided with this product is a code that is modified specifically for use with the STEVIE editor. Permis-
sion is granted to anyone to use this software for any purpose on any computer system, and to redistribute
it freely, subject to the following restrictions:
1. The author is not responsible for the consequences of use of this software, no matter how awful, even if
they arise from defects in it.
2.The origin of this software must not be misrepresented, either by explicit claim or by omission.
3. Altered versions must be plainly marked as such, and must not be misrepresented as being the original
software.
Version 1.5
Copyright (C) 1986 by University of Toronto and written by Henry Spencer.
AA.Free/OpenBSD
Copyright (c) 1982, 1986, 1990, 1991, 1993 The Regents of University of California. All Rights Reserved.
W
warnings 44-8