Foundry BigIron RX Network Switch Configuration Guide
Below you will find brief information for Network Switch BigIron RX. This guide contains detailed information on how to configure the device's various features, including access security, VLANs, and trunk groups. It is a helpful resource for setting up and managing the device for reliable network operations.
Advertisement
Advertisement
Foundry BigIron RX Series
Configuration Guide
™
2100 Gold Street
P.O. Box 649100
San Jose, CA 95164-9100
Tel 408.586.1700
Fax 408.586.1900
November 2005
Copyright © 2005 Foundry Networks, Inc. All rights reserved.
No part of this work may be reproduced in any form or by any means – graphic, electronic or mechanical, including photocopying, recording, taping or storage in an information retrieval system – without prior written permission of the copyright owner.
The trademarks, logos and service marks ("Marks") displayed herein are the property of Foundry or other third parties.
You are not permitted to use these Marks without the prior written consent of Foundry or such appropriate third party.
Foundry Networks, BigIron, FastIron, IronView, JetCore, NetIron, ServerIron, TurboIron, IronWare, EdgeIron, IronPoint, the Iron family of marks and the Foundry Logo are trademarks or registered trademarks of Foundry Networks, Inc. in the United States and other countries.
F-Secure is a trademark of F-Secure Corporation. All other trademarks mentioned in this document are the property of their respective owners.
Contents
HAPTER
BOUT
HIS
UIDE
..................................................................................... 1-1
HAPTER
ETTING
TARTED WITH THE
OMMAND
INE
NTERFACE
............................ 2-1
........................................................... 2-5
.................................................................................... 2-5
November 2005 © 2005 Foundry Networks, Inc.
i
Foundry BigIron RX Series Configuration Guide
................................................................................................2-7
........................................................ 2-8
.................................................... 2-10
............................................................. 2-11
HAPTER
ECURING
CCESS TO
ANAGEMENT
UNCTIONS
....................................... 3-1
.....................................................................3-4
.......................................................................................3-4
............................................................................... 3-4
.................................................................................. 3-5
............................................................ 3-5
.................................................................................. 3-6
.........................................3-7
............................................................ 3-7
................................................................ 3-7
.......................................... 3-7
............................................................. 3-7
.............................. 3-7
....................................3-8
...............................................3-8
VLAN...................................................................... 3-8
VLAN.................................................... 3-8
VLAN ....................................................................... 3-8
VLAN ........................................................................ 3-9
...............................................................................................3-9
........................................................................................ 3-9
............................................ 3-9
........................................................ 3-10
ii © 2005 Foundry Networks, Inc.
November 2005
Contents
..............................................................3-11
........................................................................... 3-11
..............................................................................................3-12
......................................................................................3-13
......................................................................................3-13
.............................................................................................3-14
..................................................................... 3-15
.....................................................3-15
RX ..............................................................................3-15
........................................................................... 3-15
........................................................3-16
.........................................................................................3-16
TACACS .........................................................................................3-17
.......................................3-17
TACACS/TACACS+............................................................................... 3-19
............................. 3-20
....................................................................3-20
....................................................................................... 3-20
.................................................................................... 3-20
...............................................................................3-21
...................................................3-21
.....................................................................3-22
........................................................................................... 3-23
.......................................................................................... 3-23
............................................................................................. 3-23
TACACS/TACACS+ .........................................3-23
......................................... 3-24
................................. 3-24
...................................... 3-24
.........................................................................................3-24
........................................................................................... 3-24
.................................................................................... 3-26
..............................................................................................3-27
................................. 3-27
....................................................... 3-27
...................................................... 3-28
..............................3-29
..........................................................3-30
November 2005 © 2005 Foundry Networks, Inc.
iii
Foundry BigIron RX Series Configuration Guide
.............................. 3-33
......................................................................................3-33
..............................................................................................3-33
..........................................3-34
RX ....................................................................3-35
...................................................3-35
........................................................................................... 3-36
............................................................................................. 3-36
RADIUS ............................................................3-37
......................................... 3-37
................................. 3-37
.............................................................................................3-38
........................................................................................... 3-38
.................................................................................... 3-38
..................................... 3-39
.................................... 3-39
.......................................................... 3-39
......................................................... 3-40
.........................................3-40
..........................................................................3-41
........................................................................................3-42
............................................3-43
..................................................................................3-43
HAPTER
ONFIGURING
ASIC
ARAMETERS
............................................................. 4-1
.....................................................................................4-2
.................................................................4-2
...............................................................................................4-2
........................................................................................4-4
...............................................................4-5
...................................................................... 4-5
............................................................................. 4-5
....................................................4-6
......................................................................................4-6
................................................4-6
............................................................4-7
............................................................4-10
iv © 2005 Foundry Networks, Inc.
November 2005
Contents
.........................................................................................4-11
.............................................................................4-12
.................................................................................4-12
........................................................................................4-13
......................................................4-13
.......................................................................................4-16
HAPTER
ONFIGURING
NTERFACE
ARAMETERS
...................................................... 5-1
..................................................................................5-3
...............................................................................5-4
.............................................................................................5-5
.........................................................................5-5
................................................................................................5-5
......................................................................................5-6
......................................................................5-6
...............................................................................5-6
........................................................5-8
....................................................................5-9
................................................................................5-9
.......................................................................5-10
HAPTER
ONFIGURING
RUNK
ROUPS
................................................................... 6-1
...............................................................................................6-2
November 2005 © 2005 Foundry Networks, Inc.
v
Foundry BigIron RX Series Configuration Guide
..............................................................6-3
........................................................................................6-5
.........................................................6-6
.........................................................................6-7
HAPTER
YNAMIC
INK
GGREGATION
..................................................................... 7-1
..............................................................................................7-4
.......................................................................7-5
.........................................................................................7-5
............................................. 7-8
.............................................. 7-8
.............................................................7-9
............................................... 7-10
...................................................... 7-12
HAPTER
ONFIGURING
NI
IRECTIONAL
INK
ETECTION
(UDLD) ......................... 8-1
...........................................................................................8-2
....................................................................................8-4
HAPTER
ONFIGURING
IRTUAL
S
S
)...................................................... 9-1
VLAN ..................................................................9-3
vi © 2005 Foundry Networks, Inc.
November 2005
Contents
VLAN .................................................................9-6
VLAN ............................................................................ 9-7
VLAN.......................................................................... 9-7
..........................................................................................9-8
LL PORTS MUST BE EXPLICITLY DESIGNATED AS STATIC PORTS OR EXCLUDED FROM A
.............................................................................................9-9
.............................................................................................9-9
.......................................................................................9-10
............................................................................................9-10
................................................................................................9-10
............................................9-11
...........................................................9-16
.............................................. 9-17
........................................................................ 9-24
...................................9-24
............................................9-27
.............................................................................................9-28
........................................................... 9-30
............................................................. 9-31
November 2005 © 2005 Foundry Networks, Inc.
vii
Foundry BigIron RX Series Configuration Guide
.........................................................................................9-36
........................................................................................9-39
..............................................9-42
.................................................................................9-43
......................................................................9-44
HAPTER
ONFIGURING
PANNING
REE
ROTOCOL
............................................... 10-1
(STP) .....................................................................................10-1
..................................................................................... 10-2
VLAN................................................................................... 10-2
.................................................................................... 10-2
.................................................................................10-2
...............................................................................................10-3
............................................................... 10-5
.................................................. 10-8
................................................................10-14
................................................................ 10-15
STP................................. 10-15
................................. 10-16
STP ....................................................................................... 10-17
..................................................................................... 10-18
............................................................................................10-19
viii © 2005 Foundry Networks, Inc.
November 2005
Contents
..................................................................................... 10-21
....................................................................................10-21
VLAN .......................................... 10-22
VLAN.......................................................... 10-23
HAPTER
ONFIGURING
APID
PANNING
REE
ROTOCOL
..................................... 11-1
...............................................................................................11-5
.......................................................................... 11-7
.............................................................. 11-12
.............................................................................................11-21
.............................................................................................11-21
....................................................................................11-22
.............................................................................................11-24
VLAN .................................................................11-28
.........................................................11-28
......................................................................................11-29
...........................................................................................11-29
HAPTER
ETRO
ING
ROTOCOL
(MRP) ............................................................... 12-1
1) ...................................................................12-2
2) ..........................................................................12-3
......................................................................12-4
November 2005 © 2005 Foundry Networks, Inc.
ix
Foundry BigIron RX Series Configuration Guide x
......................................................................................12-7
.............................................................12-9
........................................................................12-12
..................................................................................12-14
) ......................................................................................12-16
HAPTER
IRTUAL
WITCH
EDUNDANCY
ROTOCOL
(VSRP) ................................. 13-1
................................................................. 13-6
..........................................................................................13-9
..................................................................................13-10
VLAN ............................................................................. 13-10
........................................................................................... 13-11
............................................................................................. 13-11
......................................................... 13-11
................................................................ 13-13
...................................................................................... 13-13
................................................................................. 13-13
.................................................................. 13-14
.................................................................. 13-14
VRID ..................................................................... 13-18
.......................................... 13-19
...................................................... 13-19
............................................................................................. 13-19
© 2005 Foundry Networks, Inc.
November 2005
Contents
..................................... 13-20
HAPTER
OPOLOGY
ROUPS
................................................................................. 14-1
MRP ....................................................................................14-2
...........................................................................................14-3
....................................................................................14-3
HAPTER
ONFIGURING
AND
VRRPE ........................................................... 15-1
............................................................................................ 15-4
........................................ 15-4
............................................. 15-5
BGP4 ................................................................................. 15-5
VRRP .....................................................................................15-10
VRRPE ..................................................................................15-11
.................................................................15-12
...............................................................................15-14
.........................................................................15-15
.......................................................................................15-16
November 2005 © 2005 Foundry Networks, Inc.
xi
Foundry BigIron RX Series Configuration Guide
........................................................................................15-22
HAPTER
ONFIGURING
UALITY OF
ERVICE
.......................................................... 16-1
..........................................................................16-4
..........................................................16-5
..................................................................................... 16-5
................................................................. 16-5
.............................................. 16-6
.........................................................................................16-7
......................................................................................16-7
..............................................16-8
................................................16-8
....................................................................................16-10
WRED ............................................................................16-11
...................................................................................16-13
WRED ............................................................................16-13
........................................................................16-13
.......................................................................16-14
............................................................................... 16-14
..................................................... 16-14
......................................................................................... 16-15
.........................................................................................16-15
.................................................... 16-16
.................................. 16-16
xii © 2005 Foundry Networks, Inc.
November 2005
Contents
................................................. 16-17
........................................................ 16-17
...................................................... 16-18
....................................................... 16-18
........................................................................... 16-19
...................................................................................16-19
................................................16-20
HAPTER
ONFIGURING
IP....................................................................................... 17-1
.......................................................................................17-5
................................................................... 17-11
............................................................. 17-11
................................................................ 17-12
..........................................................17-13
.............................................................................................17-13
..................................................................17-13
..................................................................... 17-14
......................................................................................... 17-17
....................................................................................... 17-18
PPCR .............................................................................. 17-18
..............................................................................................17-26
November 2005 © 2005 Foundry Networks, Inc.
xiii
Foundry BigIron RX Series Configuration Guide
.................................................................. 17-26
....................................................... 17-27
................................................ 17-27
...........................................................................................17-29
.......................................................................... 17-31
............................................................................................. 17-32
.....................................................................................17-36
.............................................................................. 17-37
............................................. 17-38
.................................................... 17-40
....................................................................................... 17-40
................................................................................... 17-41
........................................................17-42
..................................................................... 17-43
...................................................................................... 17-44
................................................................17-44
................................................................................ 17-44
...................................................................................... 17-45
............................ 17-45
................................. 17-45
.............................................................. 17-46
..........................................................................................17-48
.........................................................................................17-49
......................................................................................... 17-51
..............................................................................................17-52
xiv © 2005 Foundry Networks, Inc.
November 2005
Contents
HAPTER
ONFIGURING
ATE
IMITING
.................................................................. 18-1
...........................................................................................18-1
RX .....................................................................18-2
.........................................................................18-2
...................................................18-3
.......................................................18-3
............................................................18-3
..........................................................18-5
ACL .................................................................. 18-5
.................................................18-5
HAPTER
AYER
S
........................................................................................ 19-1
.............................................................................19-4
..............................................................................19-4
.......................................19-4
.........................................................................19-4
HAPTER
CCESS
ONTROL
IST
............................................................................ 20-1
................................................................................................20-2
........................................................................................ 20-2
) ..................................................................20-2
....................................................................20-3
............................................................................................20-3
.......................................................................................20-4
.......................................................................................20-5
.....................................................................20-15
November 2005 © 2005 Foundry Networks, Inc.
xv
Foundry BigIron RX Series Configuration Guide
..................................................................................20-17
..................................................................................... 20-19
.................................................................................. 20-19
ACL................................................................... 20-19
........................................................................................ 20-20
........................................................................20-22
...............................................................................20-23
.............................................................................20-23
.......................................................................20-26
......................................................................................20-27
..........................................20-28
....................................20-29
HAPTER
OLICY
ASED
OUTING
.......................................................................... 21-1
................................................................21-6
xvi © 2005 Foundry Networks, Inc.
November 2005
Contents
HAPTER
ONFIGURING
ULTICAST
RAFFIC
EDUCTION
.................................... 22-1
..........................................................................................22-1
..............................................................................................22-6
................................................................................................22-7
...............................................................................................22-9
...............................................................................................22-10
HAPTER
ONFIGURING
ULTICAST
ROTOCOLS
................................................. 23-1
.......................................................................................23-2
....................................................................23-2
..........................................................23-2
.................................................................23-2
........................................................................................23-3
............................................................ 23-3
...................................................................... 23-3
.......................................................... 23-3
.......................................................................................23-4
......................................................................................23-4
..................................................................... 23-8
........................................................................................ 23-9
....................................................................................23-11
..................................................................... 23-14
November 2005 © 2005 Foundry Networks, Inc.
xvii
Foundry BigIron RX Series Configuration Guide
............................................................................. 23-14
......................................................... 23-17
......................................................... 23-17
.........................................23-17
................................................. 23-18
................................................................................ 23-20
................................................................................. 23-22
....................................................................................... 23-23
......................................................... 23-23
....................................................................... 23-25
.......................................... 23-25
................................................................................... 23-26
........................................................................................ 23-28
.............................................................................23-29
.......................................................................23-31
DVMRP ........................................................................... 23-32
........................................................................................ 23-32
......................................................................................23-32
.............................................................................................. 23-33
............................................................................................. 23-33
........................................................................................ 23-33
.................................................................................23-34
.................................................23-35
............................................................................................23-35
HAPTER
ONFIGURING
RIP .................................................................................... 24-1
xviii © 2005 Foundry Networks, Inc.
November 2005
Contents
...................................... 24-4
.........................................................................................24-4
....................................................................................... 24-5
....................................................................... 24-5
.......................................................24-6
........................................................................... 24-6
........................................................................................ 24-6
...........................................................................24-6
................................................................24-7
HAPTER
ONFIGURING
ERSION
V
4) .................................................... 25-1
.........................................................................25-2
...........................................................25-2
.........................................................................................25-4
...............................................................................25-4
......................................................................... 25-5
E ....................................................................................25-6
.............................................................................25-7
(NSSA) ................................................................................. 25-10
) ..........................................................................................25-12
.............................................................25-15
.........................................25-16
.................................................................................. 25-20
...............................25-21
........................... 25-22
November 2005 © 2005 Foundry Networks, Inc.
xix
Foundry BigIron RX Series Configuration Guide
.................................................................................... 25-22
...............................................................................25-23
...........................................................................................25-25
...............................................................................25-26
.......................................................................................25-27
............................................................................................25-29
............................................. 25-29
...........................................25-30
...................................................................................... 25-30
.............................................................................25-31
....................................................................25-32
............................................................25-33
.................................................................25-34
............................................................................................25-35
....................................................................................25-36
....................................................................................25-38
..........................................................................................25-40
OSPF .................................... 25-42
..................................................................25-42
..................................................................25-43
...........................................................................25-44
........................................................25-45
...................................................................................... 25-46
......................................................................... 25-47
HAPTER
ONFIGURING
V
4) ..................................................................... 26-1
....................................26-2
.......................................................................................26-3
xx © 2005 Foundry Networks, Inc.
November 2005
Contents
.......................................................................................26-9
.................................................................................... 26-10
............................................................... 26-10
....................................................26-11
....................................................................26-14
.....................................................26-15
......................................................26-16
...................................................................26-16
...................................................................................... 26-18
........................................................................................26-20
.................................................................26-20
AS ............................................................................26-22
.................................................................26-23
...................................................................................26-23
.........................................26-27
........................................................................26-28
................................................................................. 26-29
................................................................................. 26-32
.................................. 26-32
...................................................................................26-32
............................................26-33
November 2005 © 2005 Foundry Networks, Inc.
xxi
Foundry BigIron RX Series Configuration Guide
.................................................... 26-34
..................................................... 26-35
............................................................................... 26-36
..............................................................................................26-36
....................................................................................... 26-37
............................................................................... 26-37
.........................................................................................26-38
...................................................................................26-39
...................................................................................26-39
................................................26-41
..................................................................... 26-41
....................................................................................26-41
........................................................................................26-48
............................................................................................26-48
...................................................................... 26-50
......................................................................................... 26-50
ACL ......................................................................................... 26-51
ACL ..................................................................................... 26-52
........................................................................... 26-52
................................................................................. 26-52
................................................................................ 26-52
...................................... 26-53
...................................................................................... 26-53
.............................................................................. 26-55
......................................................................... 26-55
.....................................................................26-55
........................................................................................... 26-56
................................................................... 26-57
...........................................................................................26-58
.......................................................................... 26-60
.............................................. 26-60
xxii © 2005 Foundry Networks, Inc.
November 2005
Contents
............................................26-62
.................................. 26-64
.......................................................................... 26-66
........................................... 26-67
...............................................................................26-68
.....................................................................................26-69
..............................................................................26-72
...............................................................................26-73
.....................................................................................26-75
................................................................... 26-84
...........................................................................................26-87
....................................................................................26-88
..............................................................................................26-89
....................................................................................... 26-90
..................................... 26-91
..................................................................... 26-91
................................................................................26-96
.............................................26-97
............................................................................26-98
......................................................................26-99
HAPTER
ONFIGURING
V
4) ....................................................................... 27-1
......................................................................................27-2
..........................................................................................27-3
.......................................................................................... 27-4
...........................................................................................27-5
.............................................................................................27-7
November 2005 © 2005 Foundry Networks, Inc.
xxiii
Foundry BigIron RX Series Configuration Guide
........................................................................................... 27-8
............................................................................................. 27-8
..............................................................................................27-8
..........................................................................27-9
.........................................................................27-9
.............................................................................................27-9
..........................................................................................27-10
..........................................................................................27-10
...............................................................27-10
..................................................................27-11
..........................................................................................27-12
....................................................................27-12
...........................................................27-12
............................................................................27-12
4 IS-IS ..............................................................27-13
........................................................................................ 27-14
...........................................................................27-15
4 IS-IS ....................................................................27-15
4 IS-IS ....................................................27-16
4 IS-IS ............................................................................27-16
4 IS-IS ...........................................................27-16
4 IS-IS ...........................................................................27-16
4 IS-IS ..................................................................27-17
.................................................................................27-17
.......................................................................27-17
...............................................................27-18
.....................................................................27-18
.....................................................................27-19
.................................................................................27-19
...........................................................27-19
..................................................................27-20
.....................................................27-21
...............................................................................................27-22
.............................................................................................27-23
..............................................................................................27-25
...............................................................................................27-28
......................................................................................... 27-29
.......................................................................................... 27-30
xxiv © 2005 Foundry Networks, Inc.
November 2005
Contents
HAPTER
ONFIGURING
ECURE
HELL
................................................................... 28-1
2 .................................................................... 28-2
............................................ 28-2
..................................................................................... 28-3
............................................................28-3
RX ...................................................... 28-3
............................................................ 28-5
........................................................... 28-5
......................................................................................... 28-5
.......................................................................................... 28-5
............................................................................................... 28-6
................................................................................... 28-6
......................................... 28-6
............................................................... 28-6
......................................................................................... 28-7
...........................................................................................28-7
HAPTER
ONFIGURING
ULTI
EVICE
ORT
UTHENTICATION
................................ 29-1
.................................................................................29-1
...........................................................................................29-2
.................................29-3
................................................................................29-3
...............................................................................29-3
..........................29-3
............................................................................29-4
......................................................................................29-5
SSIGNMENTS TO THE RUNNING CONFIGURATION
...................................29-6
....................................................................................29-6
..................................................................29-7
...........................................................29-7
November 2005 © 2005 Foundry Networks, Inc.
xxv
Foundry BigIron RX Series Configuration Guide
..............................................................29-8
................................................................29-8
.............................29-9
.........................................................................29-12
.................................................................29-12
HAPTER
SING THE
ORT
ECURITY
EATURE
.............................................. 30-1
..................................................................................30-1
..................................................................................30-2
............................30-2
..........................................................................................30-2
..............................................................................................30-3
.............................................30-3
............................................................................................30-3
......................................................................................30-4
........................................................................................30-4
..............................................................................................30-5
...............................................................30-5
............................................................................................30-6
............................................................................................30-7
HAPTER
ONFIGURING
ORT
ECURITY
..................................................... 31-1
....................................................................................31-1
...........................................................................................31-2
.........................................................................................31-3
.................................................................................31-4
...............................................31-6
............................................................ 31-6
802.1X ...........................................................31-8
........................................................31-9
............................................................................................. 31-10
......................... 31-10
xxvi © 2005 Foundry Networks, Inc.
November 2005
Contents
.................................................31-12
........................................................31-13
.................................................................................31-15
..........................................................................................31-15
.........................31-16
............................31-16
.................................................................31-17
................................................................... 31-17
............................................................ 31-18
..........................................................................31-18
...............................................................31-22
............................. 31-23
.................................................... 31-23
...................................31-24
HAPTER
ROTECTING
GAINST
ENIAL OF
ERVICE
TTACKS
................................ 32-1
.....................................................................32-2
.............................................................................................32-2
............................................................................ 32-2
...............................................................................................32-3
..................................... 32-4
.................................... 32-4
....................................................................... 32-4
............................................................................ 32-4
.............................................................................................32-5
November 2005 © 2005 Foundry Networks, Inc.
xxvii
Foundry BigIron RX Series Configuration Guide
HAPTER
ECURING
CCESS
....................................................................... 33-1
.............................................................................................33-1
...................................................................................33-2
.............................................................................................33-2
....................................................................................33-3
..............................................................................................33-3
RX .......................................................................33-3
...................................................................................33-7
...............................................................................................33-9
.............................................................................................. 33-9
................................................................................ 33-9
HAPTER
NABLING THE
OUNDRY
ISCOVERY
ROTOCOL
AND
EADING
ISCO
ISCOVERY
ROTOCOL
ACKETS
........................................ 34-1
.................................................................................... 34-2
............................................................................................ 34-2
........................................................................................... 34-3
...................................................................... 34-5
....................................................................................... 34-5
.............................................................................................34-5
..................................................................... 34-5
......................................................................................... 34-5
......................................................................34-6
...........................................................34-6
xxviii © 2005 Foundry Networks, Inc.
November 2005
Contents
HAPTER
EMOTE
ETWORK
ONITORING
.............................................................. 35-1
.............................................................................................35-1
HAPTER
S
LOW
............................................................................................... 36-3
PPENDIX
SING
YSLOG
...........................................................................................A-1
................................................................. A-2
........................................................................................... A-3
...................................................................................... A-7
......................................................................................... A-8
................................................... A-8
................................................................... A-9
........................................................... A-10
........................................................ A-10
November 2005 © 2005 Foundry Networks, Inc.
xxix
Foundry BigIron RX Series Configuration Guide
PPENDIX
OMMANDS
HAT
EQUIRE A
ELOAD
........................................................B-1
NDEX OF
OMMANDS
...................................................................Index-1
xxx © 2005 Foundry Networks, Inc.
November 2005
Chapter 1
About This Guide
Introduction
This guide describes how to configure the features in the BigIron RX-Series switches from Foundry Networks.
Procedures focus on how to configure the features using the Command Line Interface (CLI).
This guide also describes how to monitor Foundry products using statistics and summary commands.
Audience
This manual is designed for system administrators with a working knowledge of Layer 2 and Layer 3 switching and routing concepts. They should be familiar with the following protocols if applicable to their network – IP, RIP, OSPF,
BGP4, MBGP, IGMP, PIM, VRRP, and VRRPE. They should also be familiar with IPv4 network protocols.
Nomenclature
This guide uses the following typographical conventions to show information:
Italics
Bold
Bold Italic
NOTE:
CAUTION:
WARNING:
Highlights the title of another publication and occasionally emphasizes a word or phrase.
Highlights a CLI command.
Highlights a term that is being defined.
A note emphasizes an important fact or calls your attention to a dependency.
A caution calls your attention to a possible hazard that can damage equipment.
A warning calls your attention to a possible hazard that can cause injury or death.
November 2005 © 2005 Foundry Networks, Inc.
1-1
Foundry BigIron RX Series Configuration Guide
List of Publications
The following guides apply to the BigIron RX:
• Foundry BigIron RX Series Installation and Basic Configuration Guide. This guide describes the BigIron RX
Series Switch from Foundry Networks. It provides procedures for installing the interface modules, power supplies, and other components of the switch. It also provides basic configuration procedures of the software.
The guide explains how to perform tasks using the CLI.
• Management Information Base Reference. This document contains the Simple Network Management
Protocol (SNMP) Management Information Base (MIB) objects that are supported in Foundry devices.
To order additional copies of these manuals, do one of the following:
• Call 1.877.TURBOCALL (887.2622) in the United States or 1.408.586.1881 outside the United States.
• Send email to [email protected].
List of Supported Features
Table 1.1 lists the supported features on the BigIron RX Series switches.
Category
System Level Features
• Denial of Service (DoS) protection
Table 1.1: List of Supported Features
Feature Description
•
•
•
Management Options
Security
CPU protection:
Protection from SYN attacks
Protection from Smurf attacks
Serial and Telnet access to industry-standard Command Line
Interface (CLI)
Web-based GUI
SNMP versions 1, 2, and 3
IronView Network Manager Network Manager.
AAA Authentication
Local passwords
RADIUS
Secure Shell (SSH) version 2
Secure Copy (SCP)
TACACS/TACACS+
User accounts
802.1X: MD5-challenge EAP type
Multi-device port authentication
There are no CLI commands for CPU protection. The BigIron RX forwards unknown unicast, broadcast and multicast packets in hardware; therefore, the CPU is automatically 'protected' from having to handle too many packets.
Multiple SysLogD server logging • SysLogD Server Logging
1-2 © 2005 Foundry Networks, Inc.
November 2005
Category
•
• sFlow
Layer 2 Features
802.1d
• 802.1p
• 802.1q
• 802.1w
• 802.3ad
• Jumbo packets
• MRP
• PVST / PVST+
• Rate Limiting
• SuperSpan
• Topology Groups
• Trunk Groups
• VLANs
About This Guide
Table 1.1: List of Supported Features (Continued)
Feature Description
sFLow version 5
Spanning Tree Protocol (STP) and
Single Spanning Tree Protocol (SSTP)
Quality of Service (QoS) queue mapping see VLANs, below
Rapid Spanning Tree Protocol (RSTP)
Dynamic Link Aggregation on tagged and untagged trunks
Layer 2 jumbo packet support
Metro Ring Protocol (MRP) Phase 1 and Phase 2
Per-VLAN Spanning Tree (PVST)
Port-based, port-and-priority based, port-and-vlan-based, and portand-ACL-based rate limiting on inbound ports are supported.
802.1Q tagging
Port-based VLANs
Super Aggregated VLANs (SAV)
Dual-mode VLAN ports
Virtual Switch Redundancy Protocol (VSRP)
Replaces MAC filters
• VSRP
• Layer 2 ACLs
• Layer 2 IGMP Snooping
Layer 3 Features
• ACLs
• BGP
• IP Forwarding
Standard or Extended
Only Inbound ACLs supported
BGP routes
BGP peers
BGP dampening
Route table
November 2005 © 2005 Foundry Networks, Inc.
1-3
Foundry BigIron RX Series Configuration Guide
Category
• IP Static entries
Table 1.1: List of Supported Features (Continued)
Feature Description
Routes
ARPs
Virtual interfaces
Secondary addresses
• IS-IS
• Multicast Routing
•
•
OSPF
PBR
• RIP versions 1 and 2
• VRRP and VRRPE
Multicast cache
L2 IGMP table
DVMRP routes
PIM-DM
PIM-SM
OSPF routes
OSPF adjacencies - Dynamic
OFPF LSAs
OSPF filtering of advertised routes
Policy-Based Routing
RIP routes
Virtual Router Redundancy Protocol (VRRP) and
VRRP Extended (VRRPE)
The following features are not supported in the BigIron RX Series switches software releases 02.2.00 or 02.2.01:
NOTE:
Commands for some of the following features may exist in the CLI, but they are not supported.
• AppleTalk
• Dynamic IP Routing
• GVRP
• IPX
• Mirroring across VLANs
• MBGP
• MPLS
• MSDP
• MSDP Mesh Groups
• NAT
• RARP
• IGMPv3
• IPv6 and all protocols related to it
1-4 © 2005 Foundry Networks, Inc.
November 2005
• VLANs
• Dynamic VLANs
• Private VLANs
• VLAN translation
• Source IP Port Security
About This Guide
November 2005 © 2005 Foundry Networks, Inc.
1-5
Foundry BigIron RX Series Configuration Guide
1-6 © 2005 Foundry Networks, Inc.
November 2005
Chapter 2
Getting Started with the Command Line Interface
This chapter presents information to help you become familiar with the BigIron RX command line interface (CLI).
As with other Foundry devices, you can manage a BigIron RX using any of the following applications:
• Command Line Interface (CLI) – a text-based interface accessible directly from a PC or terminal attached to the management module’s serial (Console) port or 10BaseT/100BaseTX Ethernet (management) port, or from a Telnet connection to the PC or terminal.
• Web management interface – a GUI-based management interface accessible through an HTTP (web browser) connection.
• IronView Network Manager – an optional SNMP-based standalone GUI application.
This user guide describes how to configure the features using the CLI. This chapter how to use the CLI.
NOTE:
This user guide assumes that an IP address and default gateway have been assigned to the BigIron RX when it was installed. If you need to assign an IP address or default gateway to the device, see the Foundry
BigIron RX Installation Guide.
Logging on Through the CLI
Once an IP address is assigned to the BigIron RX’s management port, you can access the CLI through a PC or terminal attached to the management module’s serial (Console) port or 10BaseT/100BaseTX Ethernet
(management) port, or from a Telnet or SSH connection to the PC or terminal.
You can initiate a local Telnet, SSH or SNMP connection by specifying the management port’s IP address.
The commands in the CLI are organized into the following levels:
• User EXEC – Lets you display information and perform basic tasks such as pings and traceroutes.
• Privileged EXEC – Lets you use the same commands as those at the User EXEC level plus configuration commands that do not require saving the changes to the system-config file.
• CONFIG – Lets you make configuration changes to the device. To save the changes across software reloads and system resets, you need to save them to the system-config file. The CONFIG level contains sub-levels for individual ports, for VLANs, for routing protocols, and other configuration areas.
NOTE:
By default, any user who can open a direct or Telnet connection to a BigIron RX Switch can access all these CLI levels. To secure access, you can configure Enable passwords or local user accounts, or you can configure the device to use a RADIUS or TACACS/TACACS+ server for authentication. See the Foundry Security
Guide.
November 2005 © 2005 Foundry Networks, Inc.
2-1
Foundry BigIron RX Series Configuration Guide
On-Line Help
To display a list of available commands or command options, enter “?” or press Tab. If you have not entered part of a command at the command prompt, all the commands supported at the current CLI level are listed. If you enter part of a command, then enter “?” or press Tab, the CLI lists the options you can enter at this point in the command string.
If you enter an invalid command followed by ?, a message appears indicating the command was unrecognized.
For example:
BigIron RX(config)# rooter ip
Unrecognized command
Command Completion
The CLI supports command completion, so you do not need to enter the entire name of a command or option. As long as you enter enough characters of the command or option name to avoid ambiguity with other commands or options, the CLI understands what you are typing.
Scroll Control
By default, the CLI uses a page mode to paginate displays that are longer than the number of rows in your terminal emulation window. For example, if you display a list of all the commands at the global CONFIG level but your terminal emulation window does not have enough rows to display them all at once, the page mode stops the display and lists your choices for continuing the display.
Here is an example: aaa access-list all-client arp banner base-mac-addr boot
some lines omitted for brevity...
default-vlan-id
enable
enable-acl-counter
end
exit
--More--, next page: Space, next line: Return key, quit: Control-c
The software provides the following scrolling options:
• Press the Space bar to display the next page (one screen at time).
• Press the Return or Enter key to display the next line (one line at a time).
• Press Ctrl-C cancel the display.
2-2 © 2005 Foundry Networks, Inc.
November 2005
Getting Started with the Command Line Interface
Line Editing Commands
The CLI supports the following line editing commands. To enter a line-editing command, use the CTRL-key combination for the command by pressing and holding the CTRL key, then pressing the letter associated with the command.
Table 2.1: CLI Line-Editing Commands
Ctrl-Key Combination
Ctrl-A
Ctrl-B
Ctrl-C
Ctrl-D
Ctrl-E
Ctrl-F
Ctrl-K
Ctrl-L; Ctrl-R
Ctrl-N
Ctrl-P
Ctrl-U; Ctrl-X
Ctrl-W
Ctrl-Z
Description
Moves to the first character on the command line.
Moves the cursor back one character.
Escapes and terminates command prompts and ongoing tasks (such as lengthy displays), and displays a fresh command prompt.
Deletes the character at the cursor.
Moves to the end of the current command line.
Moves the cursor forward one character.
Deletes all characters from the cursor to the end of the command line.
Repeats the current command line on a new line.
Enters the next command line in the history buffer.
Enters the previous command line in the history buffer.
Deletes all characters from the cursor to the beginning of the command line.
Deletes the last word you typed.
Moves from any CONFIG level of the CLI to the
Privileged EXEC level; at the Privileged EXEC level, moves to the User EXEC level.
EXEC Commands
There are two different levels of EXEC commands, the User Level and the Privileged Level.
User Level
The User level commands are at the top of the CLI hierarchy. These are the first commands that you have access to when connected to the device through the CLI. For example, when you first connect to the BigIron RX, you may see the following prompt.
BigIron RX>
The "BigIron RX" part of the prompt is configurable. Your system may display a different string.
At this level, you can view basic system information and verify connectivity but cannot make any changes to the device configuration. To make changes to the configuration, you must move to other levels of the CLI hierarchy. such as the Privileged EXEC level.
November 2005 © 2005 Foundry Networks, Inc.
2-3
Foundry BigIron RX Series Configuration Guide
Privileged EXEC Level
Commands at the Privileged EXEC level enable you to transfer and store software images and configuration files between the network and the system, and review the configuration.
You reach this level by entering the enable [<password>] or enable <username> <password> at the User EXEC level. For example:
BigIron RX>enable or
BigIron RX>enable user1 mypassword
After entering the enable command, you see the following prompt:
BigIron RX>#
The prompt indicates that you are at the Privilege EXEC level.
When you are at the Privilege EXEC level, you can enter commands that are available at that level. It is also at this level where you enter the configure terminal command to Global Configuration level.
Global Level
The global CONFIG level allows you to globally apply or modify parameters for ports on the device. You reach this level by entering configure terminal at the privileged EXEC level.
BigIron RX>enable
BigIron RX>#configuration terminal
The prompt changes to the Global Configuration level.
BigIron RX(config)#
CONFIG Commands
CONFIG commands modify the configuration of a BigIron RX. Once you are at the Global Configuration level, you can enter commands to configure the features in the BigIron RX. This section describes the following CONFIG CLI levels.
Redundancy Level
This redundancy level allows you to configure redundancy parameters for redundant management modules. You reach this level by entering the redundancy command at the global CONFIG level.
Interface Level
The interface level allows you to assign or modify specific port parameters on a port-by-port basis. You reach this level by entering the following at the global CONFIG level:
• interface ethernet <slot/port>
• interface loopback <num>
• interface management <portnum>
• interface ve <num>
• interface tunnel <tunnel_id>
• interface group-ve <vlan_group_id>
Trunk Level
The trunk level allows you to change parameters for statically-configured trunk groups. You reach this level by entering a trunk command with the appropriate port parameters.
2-4 © 2005 Foundry Networks, Inc.
November 2005
Getting Started with the Command Line Interface
Router RIP Level
The RIP level allows you to configure parameters for the RIP routing protocol. You reach this level by entering the
router rip command at the global CONFIG level.
Router OSPF Level
The OSPF level allows you to configure parameters for the OSPF routing protocol. You reach this level by entering the router ospf command at the global CONFIG level.
BGP Level
The BGP level allows you to configure Border Gateway Protocol version 4 (BGP4) features. You reach this level by entering the router bgp command at the global CONFIG level.
Global BGP and BGP4 Unicast Address Family Level
The global BGP and BGP4 unicast address family levels are present only on Foundry devices that support IPv6.
The global BGP level allows you to configure the BGP routing protocol. The BGP4 unicast address family level allows you to configure a BGP4 unicast route. For backward compatibility, you can currently access BGP4 unicast address family commands at both global BGP configuration and BGP4 unicast address family configuration levels.
Therefore, the global BGP and BGP4 unicast address family commands are documented together.
You reach the global BGP level by entering the router bgp command at the global CONFIG level. You reach the
BGP4 unicast address family level by entering the address-family ipv4 unicast command at the global BGP level.
BGP4 Multicast Address Family Level
The BGP4 multicast address family level allows you to configure BGP4 multicast routes. You reach this level by entering the address-family ipv4 multicast command at the global BGP, BGP4 unicast address family, or IPv6
BGP unicast address family levels.
Router DVMRP Level
The DVMRP level allows you to configure details for the DVMRP multicast protocol. You reach this level by entering the router dvmrp command at the global CONFIG level.
Router PIM Level
The PIM level allows you to configure parameters for the Protocol Independent Multicast (PIM) routing protocol.
You reach this level by entering the router pim command at the global CONFIG level.
Route Map Level
The Route Map level allows you to configure parameters for a BGP4 route map. You reach this level by entering the route-map <name> command at the global CONFIG level.
Router VRRP Level
The VRRP level allows you to configure parameters for the Virtual Router Redundancy Protocol (VRRP). You reach this level by entering the router vrrp command at the global CONFIG level, then entering the ip vrrp vrid
<num> command at the interface configuration level.
Router VRRPE Level
The VRRPE level allows you to configure parameters for VRRP Extended. You reach this level by entering the
router vrrp-extended command at the global CONFIG level, then entering the ip vrrp-extended vrid <num> command at the interface configuration level.
VLAN Level
Policy-based VLANs allow you to assign VLANs to a protocol, port, or 802.1q tags.
You reach this level by entering the vlan <vlan-id> command at the Global CONFIG Level.
Metro Ring Level
Metro rings provide Layer 2 connectivity and fast failover in ring topologies.
November 2005 © 2005 Foundry Networks, Inc.
2-5
Foundry BigIron RX Series Configuration Guide
You reach this level by entering the metro-ring <ring-id> command at the Global CONFIG Level.
VSRP Level
The VSRP level allows you to configure parameters for the Virtual Switch Redundancy Protocol (VSRP). You reach this level by entering the vsrp vrid <num> command at the VLAN configuration level, then entering the vsrp
vrid <num> command at the VLAN configuration level.
Topology Group Level
A topology group enables you to control the Layer 2 protocol configuration and Layer 2 state of a set of ports in multiple VLANs based on the configuration and states of those ports in a single master VLAN. One instance of the Layer 2 protocol controls all the VLANs.
You reach this level by entering the topology-group <group-id> command at the Global CONFIG Level.
802.1X Port Security Level
The 802.1X port security level allows you to configure the 802.1X port security. You reach this level by entering the
dot1x-enable command at the at the Global level.
MAC Port Security Level
The MAC port security level allows you to configure the port security feature. You reach this level by entering the
port security command at the at the Global or Interface levels.
Accessing the CLI
The CLI can be accessed through both serial and Telnet connections. For initial log on, you must use a serial connection. Once an IP address is assigned, you can access the CLI through Telnet.
Once connectivity to the device is established, you will see the following prompt:
BigIron RX>
When accessing the CLI through Telnet, you maybe prompted for a password. By default, the password required is the password you enter for general access at initial setup. You also have the option of assigning a separate password for Telnet access with the enable telnet password <password> command, found at the Global Level.
At initial log on, all you need to do is type enable at the prompt, then press Return. You only need to enter a password after a permanent password is entered at the Global CONFIG Level of the CLI.
NOTE:
If you install switch code on a router, the command prompt begins with "SW-" to indicate the software change. This is true even if you change the system name.
To reach the Global CONFIG Level, the uppermost level of the CONFIG commands, enter the following commands:
BigIron RX> enable
BigIron RX# configure terminal
BigIron RX(config)#
User Level commands
Privileged Level-EXEC commands
Global Level-CONFIG commands
You can then reach all other levels of the CONFIG command structure from this point.
2-6 © 2005 Foundry Networks, Inc.
November 2005
Getting Started with the Command Line Interface
The CLI prompt will change at each level of the CONFIG command structure, to easily identify the current level:
BigIron RX>
User Level EXEC Command
BigIron RX#
Privileged Level EXEC Command
BigIron RX(config)#
Global Level CONFIG Command
BigIron RX(config-if-e10000-5/1)#
Interface Level CONFIG Command
BigIron RX(config-lbif-1)#
Loopback Interface CONFIG Command
BigIron RX(config-ve-1)#
Virtual Interface CONFIG Command
BigIron RX(config-trunk-4/1-4/8)#
Trunk group CONFIG Command
BigIron RX(config-if-e10000-tunnel)#
IP Tunnel Level CONFIG Command
BigIron RX(config-bgp-router)#
BGP Level CONFIG Command
BigIron RX(config-dvmrp-router)#
DVMRP Level CONFIG Command
BigIron RX(config-ospf-router)#
OSPF Level CONFIG Command
BigIron RX(config-isis-router)#IS-IS
Level CONFIG Command
BigIron RX(config-pim-router)#
PIM Level CONFIG Command
BigIron RX(config-redundancy)#
Redundant Management Module CONFIG Command
BigIron RX(config-rip-router)#
RIP Level CONFIG Command
BigIron RX(config-port-80)#
Application Port CONFIG Command
BigIron RX(config-bgp-routemap Map_Name)#
Route Map Level CONFIG Command
BigIron RX(config-vlan-1)#
VLAN Port-based Level CONFIG Command
BigIron RX(config-vlan-atalk-proto)#
VLAN Protocol Level CONFIG Command
NOTE:
The CLI prompt at the interface level includes the port speed. The speed is one of the following:
BigIron RX(config-if–e100-5/1)# – The interface is a 10/100 port.
BigIron RX(config-if–e1000-5/1)# – The interface is a Gigabit port.
For simplicity, the port speeds sometimes are not shown in example Interface level prompts in this manual.
Navigating Among Command Levels
To reach other CLI command levels, you need to enter certain commands. At each level there is a launch command that allows you to move either up or down to the next level.
CLI Command Structure
Many CLI commands may require textual or numeral input as part of the command.
Required or Optional Fields
These fields are either required or optional depending on how the information is bracketed. For clarity, a few CLI command examples are explained below.
EXAMPLE:
Syntax: [no] deny redistribute <value> all | bgp | rip | static address <ip-addr> <ip-mask>
[match-metric <value> | set-metric <value>]
When an item is bracketed with “< >” symbols, the information requested is a variable and required.
When an item is not enclosed by “< >” or “[ ]” symbols, the item is a required keyword.
When an item is bracketed with “[ ]” symbols, the information requested is optional.
Optional Fields
When two or more options are separated by a vertical bar, “ | “, you must enter one of the options as part of the command.
November 2005 © 2005 Foundry Networks, Inc.
2-7
Foundry BigIron RX Series Configuration Guide
EXAMPLE:
Syntax: priority normal | high
For example, the "normal | high" entry in the Syntax above means that priority can be either priority normal or priority high. The command in the syntax above requires that you enter either normal or high as part of the command.
List of Available Options
To get a quick display of available options at a CLI level or for the next option in a command string, enter a question mark (?) at the prompt or press TAB.
EXAMPLE:
To view all available commands at the user EXEC level, enter the following or press TAB at the User EXEC CLI level:
BigIron RX> ? <return> enable exit fastboot ping show stop-trace-route traceroute
You also can use the question mark (?) with an individual command, to see all available options or to check context.
EXAMPLE:
To view possible copy command options, enter the following:
BigIron RX# copy ?
flash
running-config
startup-config
tftp
BigIron RX# copy flash ?
tftp
Searching and Filtering Output
You can filter CLI output from show commands and at the --More-- prompt. You can search for individual characters, strings, or construct complex regular expressions to filter the output.
Searching and Filtering Output from show Commands
You can filter output from show commands to display lines containing a specified string, lines that do not contain a specified string, or output starting with a line containing a specified string. The search string is a regular expression consisting of a single character or string of characters. You can use special characters to construct
complex regular expressions. See “Using Special Characters in Regular Expressions” on page 2-11 for
information on special characters used with regular expressions.
Displaying Lines Containing a Specified String
The following command filters the output of the show interface command for port 3/11 so it displays only lines containing the word “Internet”. This command can be used to display the IP address of the interface.
BigIron RX# show interface e 3/11 | include Internet
Internet address is 192.168.1.11/24, MTU 1518 bytes, encapsulation ethernet
Syntax: <show-command> | include <regular-expression>
NOTE:
The vertical bar ( | ) is part of the command.
2-8 © 2005 Foundry Networks, Inc.
November 2005
Getting Started with the Command Line Interface
Note that the regular expression specified as the search string is case sensitive. In the example above, a search string of “Internet” would match the line containing the IP address, but a search string of “internet” would not.
Displaying Lines That Do Not Contain a Specified String
The following command filters the output of the show who command so it displays only lines that do not contain the word “closed”. This command can be used to display open connections to the Foundry device.
BigIron RX# show who | exclude closed
Console connections:
established
you are connecting to this session
2 seconds in idle
Telnet connections (inbound):
1 established, client ip address 192.168.9.37
27 seconds in idle
Telnet connection (outbound):
SSH connections:
Syntax: <show-command> | exclude <regular-expression>
Displaying Lines Starting with a Specified String
The following command filters the output of the show who command so it displays output starting with the first line that contains the word “SSH”. This command can be used to display information about SSH connections to the
BigIron RX.
BigIron RX# show who | begin SSH
SSH connections:
1 established, client ip address 192.168.9.210
7 seconds in idle
2 closed
3 closed
4 closed
5 closed
Syntax: <show-command> | begin <regular-expression>
November 2005 © 2005 Foundry Networks, Inc.
2-9
Foundry BigIron RX Series Configuration Guide
Searching and Filtering Output at the --More-- Prompt
The --More-- prompt is displayed when output extends beyond a single page. From this prompt, you can press the
Space bar to display the next page, the Return or Enter key to display the next line, or Ctrl-C or Q to cancel the display. You can also search and filter output from this prompt. For example:
BigIron RX# ?
append Append one file to another
attrib Change file attribute
boot Boot system from bootp/tftp server/flash image
cd Change current working directory
chdir Change current working directory
clear Clear table/statistics/keys
clock Set clock
configure Enter configuration mode
copy Copy between flash, tftp, config/code
cp Copy file commands
debug Enable debugging functions (see also 'undebug')
delete Delete file on flash
dir List files
dm test commands
dot1x 802.1X
erase Erase image/configuration files from flash
exit Exit Privileged mode
fastboot Select fast-reload option
force-sync-standby Sync active flash (pri/sec/mon/startup config/lp images)
to standby
format Format PCMCIA card
hd Hex dump
ipc IPC commands
--More--, next page: Space, next line: Return key, quit: Control-c
At the --More-- prompt, you can press the forward slash key ( / ) and then enter a search string. The Foundry device displays output starting from the first line that contains the search string, similar to the begin option for
show commands. For example:
--More--, next page: Space, next line: Return key, quit: Control-c
/telnet
The results of the search are displayed: searching...
telnet Telnet by name or IP address terminal Change terminal settings traceroute TraceRoute to IP node undelete Recover deleted file whois WHOIS lookup write Write running configuration to flash or terminal
To display lines containing only a specified search string (similar to the include option for show commands) press the plus sign key ( + ) at the --More-- prompt and then enter the search string.
--More--, next page: Space, next line: Return key, quit: Control-c
+telnet
2-10 © 2005 Foundry Networks, Inc.
November 2005
Getting Started with the Command Line Interface
The filtered results are displayed: filtering...
telnet Telnet by name or IP address
To display lines that do not contain a specified search string (similar to the exclude option for show commands) press the minus sign key ( - ) at the --More-- prompt and then enter the search string.
--More--, next page: Space, next line: Return key, quit: Control-c
-telnet
The filtered results are displayed: filtering...
sync-standby Sync active flash (pri/sec/mon/startup config/lp images)
to standby if different terminal Change terminal settings traceroute TraceRoute to IP node undelete Recover deleted file whois WHOIS lookup write Write running configuration to flash or terminal
As with the commands for filtering output from show commands, the search string is a regular expression consisting of a single character or string of characters. You can use special characters to construct complex regular expressions. See the next section for information on special characters used with regular expressions.
Using Special Characters in Regular Expressions
You use a regular expression to specify a single character or multiple characters as a search string. In addition, you can include special characters that influence the way the software matches the output against the search string. These special characters are listed in the following table.
.
Character
*
+
Table 2.2: Special Characters for Regular Expressions
Operation
The period matches on any single character, including a blank space.
For example, the following regular expression matches “aaz”, “abz”, “acz”, and so on, but not just “az”: a.z
The asterisk matches on zero or more sequential instances of a pattern.
For example, the following regular expression matches output that contains the string
“abc”, followed by zero or more Xs: abcX*
The plus sign matches on one or more sequential instances of a pattern.
For example, the following regular expression matches output that contains "de", followed by a sequence of “g”s, such as “deg”, “degg”, “deggg”, and so on: deg+
November 2005 © 2005 Foundry Networks, Inc.
2-11
Foundry BigIron RX Series Configuration Guide
Character
?
^
$
_
[ ]
Table 2.2: Special Characters for Regular Expressions (Continued)
Operation
The question mark matches on zero occurrences or one occurrence of a pattern.
For example, the following regular expression matches output that contains "dg" or "deg": de?g
Note: Normally when you type a question mark, the CLI lists the commands or options at that CLI level that begin with the character or string you entered. However, if you enter Ctrl-
V and then type a question mark, the question mark is inserted into the command line, allowing you to use it as part of a regular expression.
A caret (when not used within brackets) matches on the beginning of an input string.
For example, the following regular expression matches output that begins with “deg”:
^deg
A dollar sign matches on the end of an input string.
For example, the following regular expression matches output that ends with “deg”: deg$
An underscore matches on one or more of the following:
• , (comma)
• { (left curly brace)
• } (right curly brace)
• ( (left parenthesis)
• ) (right parenthesis)
• The beginning of the input string
• The end of the input string
• A blank space
For example, the following regular expression matches on “100” but not on “1002”, “2100”, and so on.
_100_
Square brackets enclose a range of single-character patterns.
For example, the following regular expression matches output that contains “1”, “2”, “3”, “4”, or “5”:
[1-5]
You can use the following expression symbols within the brackets. These symbols are allowed only inside the brackets.
• ^ – The caret matches on any characters except the ones in the brackets. For example, the following regular expression matches output that does not contain “1”,
“2”, “3”, “4”, or “5”:
[^1-5]
• - The hyphen separates the beginning and ending of a range of characters. A match occurs if any of the characters within the range is present. See the example above.
2-12 © 2005 Foundry Networks, Inc.
November 2005
Getting Started with the Command Line Interface
|
Character
( )
Table 2.2: Special Characters for Regular Expressions (Continued)
Operation
A vertical bar separates two alternative values or sets of values. The output can match one or the other value.
For example, the following regular expression matches output that contains either “abc” or
“defg”: abc|defg
Parentheses allow you to create complex expressions.
For example, the following complex expression matches on “abc”, “abcabc”, or “defg”, but not on “abcdefgdefg”:
((abc)+)|((defg)?)
If you want to filter for a special character instead of using the special character as described in the table above, enter “\” (backslash) in front of the character. For example, to filter on output containing an asterisk, enter the asterisk portion of the regular expression as “\*”.
BigIron RX# show ip route bgp | include \*
Syntax Shortcuts
A command or parameter can be abbreviated as long as enough text is entered to distinguish it from other commands at that level. For example, given the possible commands copy tftp… and config tftp…, possible shortcuts are cop tftp and con tftp respectively. In this case, co does not properly distinguish the two commands.
Saving Configuration Changes
You can make configuration changes while the device is running. The type of configuration change determines whether or not it becomes effective immediately or requires a save to flash (write memory) and reset of the system (reload), before it becomes active.
This approach in adopting configuration changes:
• Allows you to make configuration changes to the operating or running configuration of the device to address a short-term requirement or validate a configuration without overwriting the permanent configuration file, the startup configuration, that is saved in the system flash, and;
• Ensures that dependent or related configuration changes are all cut in at the same time.
In all cases, if you want to make the changes permanent, you need to save the changes to flash using the
write memory command. When you save the configuration changes to flash, this will become the configuration that is initiated and run at system boot.
NOTE:
Most configuration changes are dynamic and thus do not require a software reload. If a command requires a software reload to take effect, the documentation states this.
November 2005 © 2005 Foundry Networks, Inc.
2-13
Foundry BigIron RX Series Configuration Guide
2-14 © 2005 Foundry Networks, Inc.
November 2005
Chapter 3
Securing Access to Management Functions
This chapter explains how to secure access to management functions on the BigIron RX. It contains the following sections:
•
and the ways you can secure each one
•
“Restricting Remote Access to Management Functions” on page 3-4 explains how to restrict access to
management functions from remote sources, including Telnet, the Web management interface, and SNMP
•
“Setting Passwords” on page 3-10 explains how to set passwords for Telnet access and management
privilege levels
•
access management functions.
•
“Configuring TACACS/TACACS+ Security” on page 3-16 explains how to configure SNMP read-only and
read-write community strings on the BigIron RX.
•
“Configuring TACACS/TACACS+ Security” on page 3-16 explains how to configure TACACS/TACACS+
authentication, authorization, and accounting.
•
“Configuring RADIUS Security” on page 3-30 explains how to configure RADIUS authentication,
authorization, and accounting.
•
methods are consulted when more than one is used with an access method.
NOTE:
For the BigIron RX, RADIUS Challenge is supported for 802.1x authentication but not for login authentication. Also, multiple challenges are supported for TACACS+ login authentication.
November 2005 © 2005 Foundry Networks, Inc.
3-1
Foundry BigIron RX Series Configuration Guide
Securing Access Methods
The following table lists the management access methods available on the BigIron RX, how they are secured by default, and the ways in which they can be secured.
Access method
Table 3.1: Ways to secure management access to the BigIron RX
Ways to secure the access method
Serial access to the CLI
How the access method is secured by default
Not secured
Access to the Privileged EXEC and CONFIG levels of the CLI
Telnet access
Not secured
Not secured
See page
Establish passwords for management privilege levels
Establish a password for Telnet access to the
CLI
Establish passwords for management privilege levels
Set up local user accounts
Configure TACACS/TACACS+ security
Configure RADIUS security
Regulate Telnet access using ACLs
Allow Telnet access only from specific IP addresses
Allow Telnet access only to clients connected to a specific VLAN
Specify the maximum number of login attempts for Telnet access
Disable Telnet access
Establish a password for Telnet access
Establish passwords for privilege levels of the
CLI
Set up local user accounts
Configure TACACS/TACACS+ security
Configure RADIUS security
3-2 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
Table 3.1: Ways to secure management access to the BigIron RX (Continued)
Access method How the access method is secured by default
Ways to secure the access method See page
Secure Shell (SSH) access
For more information on SSH,
see “Configuring Secure Shell” on page 29-1
Web management access
SNMP (IronView Network
Manager) access
Not configured
SNMP read or readwrite community strings
SNMP read or readwrite community strings and the password to the Super
User privilege level
Note: SNMP read or read-write community strings are always required for SNMP access to the device.
Configure SSH
Regulate SSH access using ACLs
Allow SSH access only from specific IP addresses
Establish passwords for privilege levels of the
CLI
Set up local user accounts
Configure TACACS/TACACS+ security
Configure RADIUS security
Regulate Web management access using
ACLs
Allow Web management access only from specific IP addresses
Allow Web management access only to clients connected to a specific VLAN
Disable Web management access
Configure SSL security for the Web management interface
Set up local user accounts
Establish SNMP read or read-write community strings for SNMP versions 1 and 2
Establishing user groups for SNMP version 3
Configure TACACS/TACACS+ security
Configure RADIUS security
Regulate SNMP access using ACLs
Allow SNMP access only from specific IP addresses
Disable SNMP access
Allow SNMP access only to clients connected to a specific VLAN
Establish passwords to management levels of the CLI
Set up local user accounts
Establish SNMP read or read-write community strings
November 2005 © 2005 Foundry Networks, Inc.
3-3
Foundry BigIron RX Series Configuration Guide
Access method
Table 3.1: Ways to secure management access to the BigIron RX (Continued)
Ways to secure the access method
TFTP access
How the access method is secured by default
Not secured Allow TFTP access only to clients connected to a specific VLAN
See page
Restricting Remote Access to Management Functions
You can restrict access to management functions from remote sources, including Telnet, the Web management interface, and SNMP. The following methods for restricting remote access are supported:
• Using ACLs to restrict Telnet, Web management interface, or SNMP access
• Allowing remote access only from specific IP addresses
• Allowing remote access only to clients connected to a specific VLAN
• Specifically disabling Telnet, Web management interface, or SNMP access to the device
Using ACLs to Restrict Remote Access
You can use standard ACLs to control the following access methods to management functions on the BigIron RX:
• Telnet access
• SSH access
• Web management access
• SNMP access
To configure access control for these management access methods:
1.
Configure an ACL with the IP addresses you want to allow to access the device
2.
Configure a Telnet access group, SSH access group, web access group, and SNMP community strings. Each of these configuration items accepts an ACL as a parameter. The ACL contains entries that identify the IP addresses that can use the access method.
Control List” chapter for more information on configuring ACLs.
NOTE:
ACL filtering for remote management access is done in hardware.
Using an ACL to Restrict Telnet Access
To configure an ACL that restricts Telnet access to the device, enter commands such as the following:
BigIron RX(config)# access-list 10 deny host 209.157.22.32 log
BigIron RX(config)# access-list 10 deny 209.157.23.0 0.0.0.255 log
BigIron RX(config)# access-list 10 deny 209.157.24.0 0.0.0.255 log
BigIron RX(config)# access-list 10 deny 209.157.25.0/24 log
BigIron RX(config)# access-list 10 permit any
BigIron RX(config)# telnet access-group 10
BigIron RX(config)# write memory
The commands configure ACL 10, then apply it as the access list for Telnet access. The device allows Telnet access to all IP addresses except those listed in ACL 10.
Syntax: telnet access-group <num> | <name>
The <num> parameter specifies the number of a standard ACL, 1 – 99.
3-4 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
The <name> parameter specifies the standard access list name.
To configure a more restrictive ACL, create permit entries and omit the permit any entry at the end of the ACL.
For example:
BigIron RX(config)# access-list 10 permit host 209.157.22.32
BigIron RX(config)# access-list 10 permit 209.157.23.0 0.0.0.255
BigIron RX(config)# access-list 10 permit 209.157.24.0 0.0.0.255
BigIron RX(config)# access-list 10 permit 209.157.25.0/24
BigIron RX(config)# telnet access-group 10
BigIron RX(config)# write memory
The ACL in the example permits Telnet access only to the IP addresses in the permit entries and denies Telnet access from all other IP addresses.
Using an ACL to Restrict SSH Access
To configure an ACL that restricts SSH access to the device, enter commands such as the following:
BigIron RX(config)# access-list 12 deny host 209.157.22.98 log
BigIron RX(config)# access-list 12 deny 209.157.23.0 0.0.0.255 log
BigIron RX(config)# access-list 12 deny 209.157.24.0/24 log
BigIron RX(config)# access-list 12 permit any
BigIron RX(config)# ssh access-group 12
BigIron RX(config)# write memory
Syntax: ssh access-group <num> | <name>
The <num> parameter specifies the number of a standard ACL, 1 – 99.
The <name> parameter specifies the standard access list name.
These commands configure ACL 12, then apply the ACL as the access list for SSH access. The device denies
SSH access from the IP addresses listed in ACL 12 and permits SSH access from all other IP addresses. Without the last ACL entry for permitting all packets, this ACL would deny SSH access from all IP addresses.
NOTE:
In this example, the command ssh access-group 10 could have been used to apply the ACL configured in the example for Telnet access. You can use the same ACL multiple times.
Using an ACL to Restrict Web Management Access
To configure an ACL that restricts Web management access to the device, enter commands such as the following:
BigIron RX(config)# access-list 12 deny host 209.157.22.98 log
BigIron RX(config)# access-list 12 deny 209.157.23.0 0.0.0.255 log
BigIron RX(config)# access-list 12 deny 209.157.24.0/24 log
BigIron RX(config)# access-list 12 permit any
BigIron RX(config)# web access-group 12
BigIron RX(config)# write memory
Syntax: web access-group <num> | <name>
The <num> parameter specifies the number of a standard ACL, 1 – 99.
The <name> parameter specifies the standard access list name.
These commands configure ACL 12, then apply the ACL as the access list for Web management access. The device denies Web management access from the IP addresses listed in ACL 12 and permits Web management access from all other IP addresses. Without the last ACL entry for permitting all packets, this ACL would deny
Web management access from all IP addresses.
November 2005 © 2005 Foundry Networks, Inc.
3-5
Foundry BigIron RX Series Configuration Guide
3-6
Using ACLs to Restrict SNMP Access
To restrict SNMP access to the device using ACLs, enter commands such as the following:
NOTE:
The syntax for using ACLs for SNMP access is different from the syntax for controlling Telnet, SSH, and
Web management access using ACLs.
BigIron RX(config)# access-list 25 deny host 209.157.22.98 log
BigIron RX(config)# access-list 25 deny 209.157.23.0 0.0.0.255 log
BigIron RX(config)# access-list 25 deny 209.157.24.0 0.0.0.255 log
BigIron RX(config)# access-list 25 permit any
BigIron RX(config)# access-list 30 deny 209.157.25.0 0.0.0.255 log
BigIron RX(config)# access-list 30 deny 209.157.26.0/24 log
BigIron RX(config)# access-list 30 permit any
BigIron RX(config)# snmp-server community public ro 25
BigIron RX(config)# snmp-server community private rw 30
BigIron RX(config)# write memory
The commands configure ACLs 25 and 30, then apply the ACLs to community strings. ACL 25 is used to control read-only access using the “public” community string. ACL 30 is used to control read-write access using the
“private” community string.
Syntax: snmp-server community <string> ro | rw
<standard-acl-name> | <standard-acl-id>
The <string> parameter specifies the SNMP community string the user must enter to gain SNMP access.
The ro parameter indicates that the community string is for read-only (“get”) access. The rw parameter indicates the community string is for read-write (“set”) access.
The <standard-acl-name> | <standard-acl-id> parameter specifies which ACL will be used to filter incoming
SNMP packets.
The <standard-acl-id> parameter specifies the number of a standard ACL, 1 – 99.
The <standard-acl-name> parameter specifies the standard access list name.
NOTE:
When snmp-server community is configured, all incoming SNMP packets are validated first by their community strings and then by their bound ACLs. Packets are permitted if no filters are configured for an ACL.
Configuring Hardware-Based Remote Access Filtering on the BigIron RX
The following is an example of configuring BigIron RX to perform hardware filtering for Telnet access.
BigIron RX(config)# vlan 3 by port
BigIron RX(config-vlan-3)# untagged ethe 3/1 to 3/5
BigIron RX(config-vlan-3)# router-interface ve 3
BigIron RX(config-vlan-3)# exit
BigIron RX(config)# interface ve 3
BigIron RX(config-ve-1)# ip address 10.10.11.1 255.255.255.0
BigIron RX(config-ve-1)# exit
BigIron RX(config)# access-list 10 permit host 10.10.11.254
BigIron RX(config)# access-list 10 permit host 192.168.2.254
BigIron RX(config)# access-list 10 permit host 192.168.12.254
BigIron RX(config)# access-list 10 permit host 192.64.22.254
BigIron RX(config)# access-list 10 deny any
BigIron RX(config)# telnet access-group 10 vlan 3
BigIron RX(config)# ssh access-group 10 vlan 3
BigIron RX(config)# web access-group 10 vlan 3
© 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
BigIron RX(config)# snmp-server community private rw 10 vlan 3
In this example, a Layer 3 VLAN is configured as a remote-access management VLAN and a router interface. The
IP address specified for the router interface becomes the management IP address of the VLAN.
Restricting Remote Access to the Device to Specific IP Addresses
By default, a BigIron RX does not control remote management access based on the IP address of the managing device. You can restrict remote management access to a single IP address for the following access methods:
• Telnet access
• Web management access
• SNMP access
In addition, if you want to restrict all three access methods to the same IP address, you can do so using a single command.
The following examples show the CLI commands for restricting remote access. You can specify only one IP address with each command. However, you can enter each command ten times to specify up to ten IP addresses.
NOTE:
You cannot restrict remote management access using the Web management interface.
Restricting Telnet Access to a Specific IP Address
To allow Telnet access to the BigIron RX only to the host with IP address 209.157.22.39, enter the following command:
BigIron RX(config)# telnet client 209.157.22.39
Syntax: [no] telnet client <ip-addr>
Restricting SSH Access to a Specific IP Address
To allow SSH access to the BigIron RX only to the host with IP address 209.157.22.39, enter the following command:
BigIron RX(config)# ip ssh client 209.157.22.39
Syntax: [no] ip ssh client <ip-addr>
Restricting Web Management Access to a Specific IP Address
To allow Web management access to the BigIron RX only to the host with IP address 209.157.22.26, enter the following command:
BigIron RX(config)# web client 209.157.22.26
Syntax: [no] web client <ip-addr>
Restricting SNMP Access to a Specific IP Address
To allow SNMP access (which includes IronView Network Manager) to the BigIron RX only to the host with IP address 209.157.22.14, enter the following command:
BigIron RX(config)# snmp-client 209.157.22.14
Syntax: [no] snmp-client <ip-addr>
Restricting All Remote Management Access to a Specific IP Address
To allow Telnet, Web, and SNMP management access to the BigIron RX only to the host with IP address
209.157.22.69, you can enter three separate commands (one for each access type) or you can enter the following command:
BigIron RX(config)# all-client 209.157.22.69
Syntax: [no] all-client <ip-addr>
November 2005 © 2005 Foundry Networks, Inc.
3-7
Foundry BigIron RX Series Configuration Guide
3-8
Specifying the Maximum Number of Login Attempts for Telnet Access
If you are connecting to the BigIron RX using Telnet, the device prompts you for a username and password. By default, you have up to 4 chances to enter a correct username and password. If you do not enter a correct username or password after 4 attempts, the BigIron RX disconnects the Telnet session.
You can specify the number of attempts a Telnet user has to enter a correct username and password before the
BigIron RX disconnects the Telnet session. For example, to allow a Telnet user up to 5 chances to enter a correct username and password, enter the following command:
BigIron RX(config)# telnet login-retries 5
Syntax: [no] telnet login-retries <number>
You can specify from 0 – 5 attempts. The default is 4 attempts.
Restricting Remote Access to the Device to Specific VLAN IDs
You can restrict management access to a BigIron RX to ports within a specific port-based VLAN. VLAN-based access control applies to the following access methods:
• Telnet access
• Web management access
• SNMP access
• TFTP access
By default, access is allowed for all the methods listed above on all ports. Once you configure security for a given access method based on VLAN ID, access to the device using that method is restricted to only the ports within the specified VLAN.
VLAN-based access control works in conjunction with other access control methods. For example, suppose you configure an ACL to permit Telnet access only to specific client IP addresses, and you also configure VLAN-based access control for Telnet access. In this case, the only Telnet clients that can access the device are clients that have one of the IP addresses permitted by the ACL and are connected to a port that is in a permitted VLAN.
Clients who have a permitted IP address but are connected to a port in a VLAN that is not permitted still cannot access the device through Telnet.
Restricting Telnet Access to a Specific VLAN
To allow Telnet access only to clients in a specific VLAN, enter a command such as the following:
BigIron RX(config)# telnet server enable vlan 10
The command configures the device to allow Telnet management access only to clients connected to ports within port-based VLAN 10. Clients connected to ports that are not in VLAN 10 are denied management access.
Syntax: [no] telnet server enable vlan <vlan-id>
Restricting Web Management Access to a Specific VLAN
To allow Web management access only to clients in a specific VLAN, enter a command such as the following:
BigIron RX(config)# web-management enable vlan 10
The command configures the device to allow Web management access only to clients connected to ports within port-based VLAN 10. Clients connected to ports that are not in VLAN 10 are denied management access.
Syntax: [no] web-management enable vlan <vlan-id>
Restricting SNMP Access to a Specific VLAN
To allow SNMP access only to clients in a specific VLAN, enter a command such as the following:
BigIron RX(config)# snmp-server enable vlan 40
The command configures the device to allow SNMP access only to clients connected to ports within port-based
VLAN 40. Clients connected to ports that are not in VLAN 40 are denied access.
© 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
Syntax: [no] snmp-server enable vlan <vlan-id>
Restricting TFTP Access to a Specific VLAN
To allow TFTP access only to clients in a specific VLAN, enter a command such as the following:
BigIron RX(config)# tftp client enable vlan 40
The command in this example configures the device to allow TFTP access only to clients connected to ports within port-based VLAN 40. Clients connected to ports that are not in VLAN 40 are denied access.
Syntax: [no] tftp client enable vlan <vlan-id>
Disabling Specific Access Methods
You can specifically disable the following access methods:
• Telnet access
• Web management access
• SNMP access
NOTE:
If you disable Telnet access, you will not be able to access the CLI except through a serial connection to the management module, nor will you be able to use some of the features in IronView Network Manager. If you disable SNMP access, you will not be able to use IronView Network Manager or third-party SNMP management applications.
Disabling Telnet Access
Telnet access is enabled by default. You can use a Telnet client to access the CLI on the device over the network.
If you do not plan to use the CLI over the network and want to disable Telnet access to prevent others from establishing CLI sessions with the device, enter the following command:
BigIron RX(config)# no telnet-server
To re-enable Telnet operation, enter the following command:
BigIron RX(config)# telnet-server
Syntax: [no] telnet-server
Disabling Web Management Access
If you want to prevent access to the device through the Web management interface, you can disable the Web management interface.
NOTE:
As soon as you make this change, the device stops responding to Web management sessions. If you make this change using your Web browser, your browser can contact the device, but the device will not reply once the change takes place.
To disable the Web management interface, enter the following command:
BigIron RX(config)# no web-management
To re-enable the Web management interface, enter the following command:
BigIron RX(config)# web-management
Syntax: [no] web-management
Disabling Web Management Access by HP ProCurve Manager
By default, TCP ports 80 is enabled on the Foundry device. TCP port 80 (HTTP) allows access to the device’s
Web management interface.
By default, TCP port 280 for HP Top tools is disabled. This tool allows access to the device by HP ProCurve
Manager.
November 2005 © 2005 Foundry Networks, Inc.
3-9
Foundry BigIron RX Series Configuration Guide
The no web-management command disables both TCP ports. However, if you want to disable only port 280 and leave port 80 enabled, use the hp-top-tools option with the command. Here is an example.
BigIron RX(config)# no web-management hp-top-tools
Syntax: [no] web-management hp-top-tools
The hp-top-tools parameter disables TCP port 280.
Disabling SNMP Access
SNMP is enabled by default on the BigIron RX. SNMP is required if you want to manage a BigIron RX using
IronView Network Manager.
To disable SNMP management of the device:
BigIron RX(config)#no snmp-server enable
To later re-enable SNMP management of the device:
BigIron RX(config)#snmp-server enable
Syntax: [no] snmp-server enable
Setting Passwords
Passwords can be used to secure the following access methods:
•
• Access to the Privileged EXEC and CONFIG levels of the CLI can be secured by setting passwords for
management privilege levels. See “Setting Passwords for Management Privilege Levels” on page 3-11.
This section also provides procedures for enhancing management privilege levels, recovering from a lost password, and disabling password encryption.
NOTE:
You also can configure up to 16 user accounts consisting of a user name and password, and assign each
user account a management privilege level. See “Setting Up Local User Accounts” on page 3-13.
Setting a Telnet Password
By default, the device does not require a user name or password when you log in to the CLI using Telnet.
To set the password “letmein” for Telnet access to the CLI, enter the following command at the global CONFIG level:
BigIron RX(config)# enable telnet password letmein
Syntax: [no] enable telnet password <string>
Suppressing Telnet Connection Rejection Messages
By default, if a BigIron RX denies Telnet management access to the device, the software sends a message to the denied Telnet client. You can optionally suppress the rejection message. When you enable the option, a denied
Telnet client does not receive a message from the BigIron RX. Instead, the denied client simply does not gain access.
To suppress the connection rejection message sent by the device to a denied Telnet client, enter the following command at the global CONFIG level of the CLI:
BigIron RX(config)# telnet server suppress-reject-message
Syntax: [no] telnet server suppress-reject-message
3-10 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
Setting Passwords for Management Privilege Levels
You can set one password for each of the following management privilege levels:
• Super User level – Allows complete read-and-write access to the system. This is generally for system administrators and is the only management privilege level that allows you to configure passwords.
• Port Configuration level – Allows read-and-write access for specific ports but not for global (system-wide) parameters.
• Read Only level – Allows access to the Privileged EXEC mode and CONFIG mode of the CLI but only with read access.
You can assign a password to each management privilege level. You also can configure up to 16 user accounts consisting of a user name and password, and assign each user account to one of the three privilege levels. See
“Setting Up Local User Accounts” on page 3-13.
NOTE:
You must use the CLI to assign a password for management privilege levels. You cannot assign a password using the Web management interface.
If you configure user accounts in addition to privilege level passwords, the device will validate a user’s access attempt using one or both methods (local user account or privilege level password), depending on the order you
To set passwords for management privilege levels:
1.
At the opening CLI prompt, enter the following command to change to the Privileged level of the EXEC mode:
BigIron RX> enable
BigIron RX#
2.
Access the CONFIG level of the CLI by entering the following command:
BigIron RX# configure terminal
BigIron RX(config)#
3.
Enter the following command to set the Super User level password:
BigIron RX(config)# enable super-user-password
<text>
NOTE:
You must set the Super User level password before you can set other types of passwords. The
Super User level password can be an alphanumeric string, but cannot begin with a number.
4.
Enter the following commands to set the Port Configuration level and Read Only level passwords:
BigIron RX(config)# enable port-config-password
<text>
BigIron RX(config)# enable read-only-password
<text>
Syntax: enable super-user-password <text>
Syntax: enable port-config-password <text>
Syntax: enable read-only-password <text>
NOTE:
If you forget your Super User level password, see “Recovering from a Lost Password” on page 3-12.
Augmenting Management Privilege Levels
Each management privilege level provides access to specific areas of the CLI by default:
• Super User level provides access to all commands and displays.
• Port Configuration level gives access to:
• The User EXEC and Privileged EXEC levels
• The port-specific parts of the CONFIG level
November 2005 © 2005 Foundry Networks, Inc.
3-11
Foundry BigIron RX Series Configuration Guide
• All interface configuration levels
• Read Only level gives access to:
• The User EXEC and Privileged EXEC levels
You can grant additional access to a privilege level on an individual command basis. To grant the additional access, you specify the privilege level you are enhancing, the CLI level that contains the command, and the individual command.
NOTE:
This feature applies only to management privilege levels on the CLI. You cannot augment management access levels for the Web management interface.
To enhance the Port Configuration privilege level so users also can enter IP commands at the global CONFIG level:
BigIron RX(config)# privilege configure level 4 ip
In this command, configure specifies that the enhanced access is for a command at the global CONFIG level of the CLI. The level 4 parameter indicates that the enhanced access is for management privilege level 4 (Port
Configuration). All users with Port Configuration privileges will have the enhanced access. The ip parameter indicates that the enhanced access is for the IP commands. Users who log in with valid Port Configuration level user names and passwords can enter commands that begin with “ip” at the global CONFIG level.
Syntax: [no] privilege <cli-level> level <privilege-level> <command-string>
The <cli-level> parameter specifies the CLI level and can be one of the following values:
• exec – EXEC level; for example, BigIron RX> or BigIron RX#
• configure – CONFIG level; for example, BigIron RX(config)#
• interface – Interface level; for example, BigIron RX(config-if-e10000-6)#
• virtual-interface – Virtual-interface level; for example, BigIron RX(config-vif-6)#
• rip-router – RIP router level; for example, BigIron RX(config-rip-router)#
• ospf-router – OSPF router level; for example, BigIron RX(config-ospf-router)#
• bgp-router – BGP4 router level; for example, BigIron RX(config-bgp-router)#
• port-vlan – Port-based VLAN level; for example, BigIron RX(config-vlan)#
• protocol-vlan – Protocol-based VLAN level
• dot1x
• loopback-interface
• tunnel-interface
• vrrp-router
The <privilege-level> indicates the number of the management privilege level you are augmenting. You can specify one of the following:
• 0 – Super User level (full read-write access)
• 4 – Port Configuration level
• 5 – Read Only level
The <command-string> parameter specifies the command you are allowing users with the specified privilege level to enter. To display a list of the commands at a CLI level, enter “?” at that level's command prompt.
Recovering from a Lost Password
Recovery from a lost password requires direct access to the serial port and a system reset.
3-12 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
NOTE:
You can perform this procedure only from the CLI.
To recover from a lost password:
1.
Start a CLI session over the serial interface to the device.
2.
Reboot the device.
3.
At the initial boot prompt at system startup, enter b to enter the boot monitor mode.
4.
Enter no password at the prompt. (You cannot abbreviate this command.) This command will cause the device to bypass the system password check.
5.
Enter boot system flash primary at the prompt.
6.
After the console prompt reappears, assign a new password.
Displaying the SNMP Community String
If you want to display the SNMP community string, enter the following commands:
BigIron RX(config)# enable password-display
BigIron RX(config)# show snmp server
The enable password-display command enables display of the community string, but only in the output of the
show snmp server command. Display of the string is still encrypted in the startup configuration file and running configuration. Enter the command at the global CONFIG level of the CLI.
Disabling Password Encryption
When you configure a password, then save the configuration to the Foundry device’s flash memory, the password is also saved to flash as part of the configuration file. By default, the passwords are encrypted so that the passwords cannot be observed by another user who displays the configuration file. Even if someone observes the file while it is being transmitted over TFTP, the password is encrypted.
If you want to remove the password encryption, you can disable encryption by entering the following command:
BigIron RX(config)# no service password-encryption
Syntax: [no] service password-encryption
Specifying a Minimum Password Length
By default, the Foundry device imposes no minimum length on the Line (Telnet), Enable, or Local passwords. You can configure the device to require that Line, Enable, and Local passwords be at least a specified length.
For example, to specify that the Line, Enable, and Local passwords be at least 8 characters, enter the following command:
BigIron RX(config)# enable password-min-length 8
Syntax: enable password-min-length <number-of-characters>
The <number-of-characters> can be from 1 – 48.
Setting Up Local User Accounts
You can define up to 16 local user accounts on a BigIron RX. User accounts regulate who can access the management functions in the CLI using the following methods:
• Telnet access
• Web management access
• SNMP access
November 2005 © 2005 Foundry Networks, Inc.
3-13
Foundry BigIron RX Series Configuration Guide
3-14
Local user accounts provide greater flexibility for controlling management access to the BigIron RX than do management privilege level passwords and SNMP community strings of SNMP versions 1 and 2. You can continue to use the privilege level passwords and the SNMP community strings as additional means of access authentication. Alternatively, you can choose not to use local user accounts and instead continue to use only the privilege level passwords and SNMP community strings. Local user accounts are backward-compatible with
If you configure local user accounts, you also need to configure an authentication-method list for Telnet access,
Web management access, and SNMP access. See “Configuring Authentication-Method Lists” on page 3-42.
For each local user account, you specify a user name which can have up to 255 characters. You also can specify the following parameters:
• A password
• A management privilege level, which can be one of the following:
• Super User level – Allows complete read-and-write access to the system. This is generally for system administrators and is the only privilege level that allows you to configure passwords. This is the default.
• Port Configuration level – Allows read-and-write access for specific ports but not for global (system-wide) parameters.
• Read Only level – Allows access to the Privileged EXEC mode and CONFIG mode but only with read access.
Configuring a Local User Account
To configure a local user account, enter a command such as the following at the global CONFIG level of the CLI.
BigIron RX(config)# username wonka password willy
This command adds a local user account with the user name “wonka” and the password “willy”. This account has the Super User privilege level; this user has full access to all configuration and display features.
NOTE:
If you configure local user accounts, you must grant Super User level access to at least one account before you add accounts with other privilege levels. You need the Super User account to make further administrative changes.
BigIron RX(config)# username waldo privilege 5 password whereis
This command adds a user account for user name “waldo”, password “whereis”, with the Read Only privilege level. Waldo can look for information but cannot make configuration changes.
Syntax: [no] username <user-string> privilege <privilege-level> password | nopassword <password-string>
Enter up to 255 characters for <user-string>.
The privilege parameter specifies the privilege level for the account. You can specify one of the following:
• 0 – Super User level (full read-write access)
• 4 – Port Configuration level
• 5 – Read Only level
The default privilege level is 0. If you want to assign Super User level access to the account, you can enter the command without privilege 0, as shown in the command example above.
The password | nopassword parameter indicates whether the user must enter a password. If you specify
password, enter the string for the user's password.
NOTE:
You must be logged on with Super User access (privilege level 0) to add user accounts or configure other access parameters.
To display user account information, enter the following command:
© 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
BigIron RX(config)# show users
Syntax: show users
Note About Changing Local User Passwords
The BigIron RX stores not only the current password configured for a local user, but the previous two passwords configured for the user as well. The local user's password cannot be changed to one of the stored passwords.
Consequently, if you change the password for a local user, you must select a password that is different from the current password, as well as different from the previous two passwords that had been configured for that user.
For example, say local user waldo originally had a password of "whereis", and the password was subsequently changed to “whois”, then later changed to “whyis”. If you change waldo's password again, you cannot change it to
"whereis", "whois", or "whyis".
The current and previous passwords are stored in the device’s running configuration file in encrypted form. For example:
BigIron RX# show run
...
username waldo password 8 $1$Ro2..Ox0$udBu7pQT5XyuaXMUiUHy9. history
$1$eq...T62$IfpxIcxnDWX7CSVQKIodu. $1$QD3..2Q0$DYxgxCI64ZOSsYmSSaA28/
...
In the running configuration file, the user’s previous two passwords are displayed in encrypted form following the
history parameter.
Configuring SSL Security for the Web Management Interface
When enabled, the SSL protocol uses digital certificates and public-private key pairs to establish a secure connection to the BigIron RX. Digital certificates serve to prove the identity of a connecting client, and publicprivate key pairs provide a means to encrypt data sent between the device and the client.
Configuring SSL for the Web management interface consists of the following tasks:
• Enabling the SSL server on the BigIron RX
• Importing an RSA certificate and private key file from a client (optional)
• Generating a certificate
Enabling the SSL Server on the BigIron RX
To enable the SSL server on the BigIron RX, enter the following command:
BigIron RX(config)# web-management https
Syntax: [no] web-management http | https
You can enable either the HTTP or HTTPs servers with this command. You can disable both the HTTP and
HTTPs servers by entering the following command:
BigIron RX(config)# no web-management
Syntax: no web-management
Specifying a Port for SSL Communication
By default, SSL protocol exchanges occur on TCP port 443. You can optionally change the port number used for
SSL communication.
For example, the following command causes the device to use TCP port 334 for SSL communication:
BigIron RX(config)# ip ssl port 334
Syntax: [no] ip ssl port <port-number>
The default port for SSL communication is 443.
November 2005 © 2005 Foundry Networks, Inc.
3-15
Foundry BigIron RX Series Configuration Guide
Importing Digital Certificates and RSA Private Key Files
To allow a client to communicate with the other BigIron RX using an SSL connection, you configure a set of digital certificates and RSA public-private key pairs on the device. A digital certificate is used for identifying the connecting client to the server. It contains information about the issuing Certificate Authority, as well as a public key. You can either import digital certificates and private keys from a server, or you can allow the Foundry device to create them.
transfer the files.
For example, to import a digital certificate using TFTP, enter a command such as the following:
BigIron RX(config)# ip ssl certificate-data-file tftp 192.168.9.210 certfile
Syntax: [no] ip ssl certificate-data-file tftp <ip-addr> <certificate-filename>
NOTE:
If you import a digital certificate from a client, it can be no larger than 2048 bytes.
To import an RSA private key from a client using TFTP, enter a command such as the following:
BigIron RX(config)# ip ssl private-key-file tftp 192.168.9.210 keyfile
Syntax: [no] ip ssl private-key-file tftp <ip-addr> <key-filename>
The <ip-addr> is the IP address of a TFTP server that contains the digital certificate or private key.
Generating an SSL Certificate
If you did not already import a digital certificate from a client, the device can create a default certificate. To do this, enter the following command:
BigIron RX(config)# crypto-ssl certificate generate
Syntax: [no] crypto-ssl certificate generate
Deleting the SSL Certificate
To delete the SSL certificate, enter the following command:
BigIron RX(config)# crypto-ssl certificate zeroize
Syntax: [no] crypto-ssl certificate zeroize
Configuring TACACS/TACACS+ Security
You can use the security protocol Terminal Access Controller Access Control System (TACACS) or TACACS+ to authenticate the following kinds of access to the BigIron RX:
• Telnet access
• SSH access
• Web management access
• Access to the Privileged EXEC level and CONFIG levels of the CLI
NOTE:
You cannot authenticate IronView Network Manager (SNMP) access to a BigIron RX using TACACS/
TACACS+.
The TACACS and TACACS+ protocols define how authentication, authorization, and accounting information is sent between a BigIron RX and an authentication database on a TACACS/TACACS+ server. TACACS/TACACS+ services are maintained in a database, typically on a UNIX workstation or PC with a TACACS/TACACS+ server running.
3-16 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
How TACACS+ Differs from TACACS
TACACS is a simple UDP-based access control protocol originally developed by BBN for MILNET. TACACS+ is an enhancement to TACACS and uses TCP to ensure reliable delivery.
TACACS+ is an enhancement to the TACACS security protocol. TACACS+ improves on TACACS by separating the functions of authentication, authorization, and accounting (AAA) and by encrypting all traffic between the
BigIron RX and the TACACS+ server. TACACS+ allows for arbitrary length and content authentication exchanges, which allow any authentication mechanism to be utilized with the BigIron RX. TACACS+ is extensible to provide for site customization and future development features. The protocol allows the BigIron RX to request very precise access control and allows the TACACS+ server to respond to each component of that request.
NOTE:
TACACS+ provides for authentication, authorization, and accounting, but an implementation or configuration is not required to employ all three.
TACACS/TACACS+ Authentication, Authorization, and Accounting
When you configure a BigIron RX to use a TACACS/TACACS+ server for authentication, the device prompts users who are trying to access the CLI for a user name and password, then verifies the password with the TACACS/
TACACS+ server.
If you are using TACACS+, Foundry recommends that you also configure authorization, in which the BigIron RX consults a TACACS+ server to determine which management privilege level (and which associated set of commands) an authenticated user is allowed to use. You can also optionally configure accounting, which causes the BigIron RX to log information on the TACACS+ server when specified events occur on the device.
NOTE:
By default, a user logging into the device via Telnet or SSH would first enter the User EXEC level. The user can enter the enable command to get to the Privileged EXEC level.
A user that is successfully authenticated can be automatically placed at the Privileged EXEC level after login. See
“Entering Privileged EXEC Mode After a Telnet or SSH Login” on page 3-24.
TACACS Authentication
NOTE:
Also, multiple challenges are supported for TACACS+ login authentication.
When TACACS authentication takes place, the following events occur:
1.
A user attempts to gain access to the BigIron RX by doing one of the following:
• Logging into the device using Telnet, SSH, or the Web management interface
• Entering the Privileged EXEC level or CONFIG level of the CLI
2.
The user is prompted for a username and password.
3.
The user enters a username and password.
4.
The BigIron RX sends a request containing the username and password to the TACACS server.
5.
The username and password are validated in the TACACS server’s database.
6.
If the password is valid, the user is authenticated.
TACACS+ Authentication
When TACACS+ authentication takes place, the following events occur:
1.
A user attempts to gain access to the BigIron RX by doing one of the following:
• Logging into the device using Telnet, SSH, or the Web management interface
• Entering the Privileged EXEC level or CONFIG level of the CLI
2.
The user is prompted for a username.
November 2005 © 2005 Foundry Networks, Inc.
3-17
Foundry BigIron RX Series Configuration Guide
3.
The user enters a username.
4.
The BigIron RX obtains a password prompt from a TACACS+ server.
5.
The user is prompted for a password.
6.
The user enters a password.
7.
The BigIron RX sends the password to the TACACS+ server.
8.
The password is validated in the TACACS+ server’s database.
9.
If the password is valid, the user is authenticated.
TACACS+ Authorization
The BigIron RX supports two kinds of TACACS+ authorization:
• Exec authorization determines a user’s privilege level when they are authenticated.
• Command authorization consults a TACACS+ server to get authorization for commands entered by the user.
When TACACS+ exec authorization takes place, the following events occur:
1.
A user logs into the BigIron RX using Telnet, SSH, or the Web management interface
2.
The user is authenticated.
3.
The BigIron RX consults the TACACS+ server to determine the privilege level of the user.
4.
The TACACS+ server sends back a response containing an A-V (Attribute-Value) pair with the privilege level of the user.
5.
The user is granted the specified privilege level.
When TACACS+ command authorization takes place, the following events occur:
1.
A Telnet, SSH, or Web management interface user previously authenticated by a TACACS+ server enters a command on the BigIron RX.
2.
The BigIron RX looks at its configuration to see if the command is at a privilege level that requires TACACS+ command authorization.
3.
If the command belongs to a privilege level that requires authorization, the BigIron RX consults the TACACS+ server to see if the user is authorized to use the command.
4.
If the user is authorized to use the command, the command is executed.
TACACS+ Accounting
TACACS+ accounting works as follows:
1.
One of the following events occur on the BigIron RX:
• A user logs into the management interface using Telnet or SSH
• A user enters a command for which accounting has been configured
• A system event occurs, such as a reboot or reloading of the configuration file
2.
The BigIron RX checks its configuration to see if the event is one for which TACACS+ accounting is required.
3.
If the event requires TACACS+ accounting, the BigIron RX sends a TACACS+ Accounting Start packet to the
TACACS+ accounting server, containing information about the event.
4.
The TACACS+ accounting server acknowledges the Accounting Start packet.
5.
The TACACS+ accounting server records information about the event.
6.
When the event is concluded, the BigIron RX sends an Accounting Stop packet to the TACACS+ accounting server.
7.
The TACACS+ accounting server acknowledges the Accounting Stop packet.
3-18 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
AAA Operations for TACACS/TACACS+
The following table lists the sequence of authentication, authorization, and accounting operations that take place when a user gains access to a BigIron RX that has TACACS/TACACS+ security configured.
User Action
User attempts to gain access to the
Privileged EXEC and CONFIG levels of the CLI
User logs in using Telnet/SSH
User logs into the Web management interface
User logs out of Telnet/SSH session
User enters system commands
(for example, reload, boot system)
Applicable AAA Operations
Enable authentication: aaa authentication enable default <method-list>
Exec authorization (TACACS+): aaa authorization exec default tacacs+
System accounting start (TACACS+): aaa accounting system default start-stop <method-list>
Login authentication: aaa authentication login default <method-list>
Exec authorization (TACACS+): aaa authorization exec default tacacs+
Exec accounting start (TACACS+): aaa accounting exec default <method-list>
System accounting start (TACACS+): aaa accounting system default start-stop <method-list>
Web authentication: aaa authentication web-server default <method-list>
Exec authorization (TACACS+): aaa authorization exec default tacacs+
Command accounting (TACACS+): aaa accounting commands <privilege-level> default start-stop
<method-list>
EXEC accounting stop (TACACS+): aaa accounting exec default start-stop <method-list>
Command authorization (TACACS+): aaa authorization commands <privilege-level> default <method-list>
Command accounting (TACACS+): aaa accounting commands <privilege-level> default start-stop
<method-list>
System accounting stop (TACACS+): aaa accounting system default start-stop <method-list>
November 2005 © 2005 Foundry Networks, Inc.
3-19
Foundry BigIron RX Series Configuration Guide
3-20
User Action
User enters the command:
[no] aaa accounting system default start-stop <method-list>
User enters other commands
Applicable AAA Operations
Command authorization (TACACS+): aaa authorization commands <privilege-level> default <method-list>
Command accounting (TACACS+): aaa accounting commands <privilege-level> default start-stop
<method-list>
System accounting start (TACACS+): aaa accounting system default start-stop <method-list>
Command authorization (TACACS+): aaa authorization commands <privilege-level> default <method-list>
Command accounting (TACACS+): aaa accounting commands <privilege-level> default start-stop
<method-list>
AAA Security for Commands Pasted Into the Running Configuration
If AAA security is enabled on the BigIron RX, commands pasted into the running configuration are subject to the same AAA operations as if they were entered manually.
When you paste commands into the running configuration, and AAA command authorization and/or accounting is configured on the device, AAA operations are performed on the pasted commands. The AAA operations are performed before the commands are actually added to the running configuration. The server performing the AAA operations should be reachable when you paste the commands into the running configuration file. If the device determines that a pasted command is invalid, AAA operations are halted on the remaining commands. The remaining commands may not be executed if command authorization is configured.
TACACS/TACACS+ Configuration Considerations
• You must deploy at least one TACACS/TACACS+ server in your network.
• The BigIron RX supports authentication using up to eight TACACS/TACACS+ servers. The device tries to use the servers in the order you add them to the device’s configuration.
• You can select only one primary authentication method for each type of access to a device (CLI through
Telnet, CLI Privileged EXEC and CONFIG levels). For example, you can select TACACS+ as the primary authentication method for Telnet CLI access, but you cannot also select RADIUS authentication as a primary method for the same type of access. However, you can configure backup authentication methods for each access type.
• You can configure the Foundry device to authenticate using a TACACS or TACACS+ server, not both.
TACACS Configuration Procedure
For TACACS configurations, use the following procedure:
1.
Identify TACACS servers. See “Identifying the TACACS/TACACS+ Servers” on page 3-21.
2.
Set optional parameters. See “Setting Optional TACACS/TACACS+ Parameters” on page 3-22.
3.
TACACS+ Configuration Procedure
For TACACS+ configurations, use the following procedure:
1.
Identify TACACS+ servers. See “Identifying the TACACS/TACACS+ Servers” on page 3-21.
© 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
2.
Set optional parameters. See “Setting Optional TACACS/TACACS+ Parameters” on page 3-22.
3.
4.
Optionally configure TACACS+ authorization. See “Configuring TACACS+ Authorization” on page 3-24.
5.
Optionally configure TACACS+ accounting. See “Configuring TACACS+ Accounting” on page 3-27.
Identifying the TACACS/TACACS+ Servers
To use TACACS/TACACS+ servers to authenticate access to a BigIron RX, you must identify the servers to the
BigIron RX.
For example, to identify three TACACS/TACACS+ servers, enter commands such as the following:
BigIron RX(config)# tacacs-server host 207.94.6.161
BigIron RX(config)# tacacs-server host 207.94.6.191
BigIron RX(config)# tacacs-server host 207.94.6.122
Syntax: tacacs-server host <ip-addr> |<hostname> [auth-port <number>]
The <ip-addr> |<hostname> parameter specifies the IP address or host name of the server. You can enter up to eight tacacs-server host commands to specify up to eight different servers.
NOTE: To specify the server's host name instead of its IP address, you must first identify a DNS server using the
ip dns server-address <ip-addr> command at the global CONFIG level.
If you add multiple TACACS/TACACS+ authentication servers to the BigIron RX, the device tries to reach them in the order you add them. For example, if you add three servers in the following order, the software tries the servers in the same order:
1.
207.94.6.161
2.
207.94.6.191
3.
207.94.6.122
You can remove a TACACS/TACACS+ server by entering no followed by the tacacs-server command. For example, to remove 207.94.6.161, enter the following command:
BigIron RX(config)# no tacacs-server host 207.94.6.161
NOTE: If you erase a tacacs-server command (by entering “no” followed by the command), make sure you also
erase the aaa commands that specify TACACS/TACACS+ as an authentication method. (See “Configuring
mode or from a Telnet session, the system continues to believe it is TACACS/TACACS+ enabled and you will not be able to access the system.
The auth-port parameter specifies the UDP (for TACACS) or TCP (for TACACS+) port number of the authentication port on the server. The default port number is 49.
Specifying Different Servers for Individual AAA Functions
In a TACACS+ configuration, you can designate a server to handle a specific AAA task. For example, you can designate one TACACS+ server to handle authorization and another TACACS+ server to handle accounting. You can set the TACACS+ key for each server.
November 2005 © 2005 Foundry Networks, Inc.
3-21
Foundry BigIron RX Series Configuration Guide
To specify different TACACS+ servers for authentication, authorization, and accounting:
BigIron RX(config)# tacacs-server host 1.2.3.4 auth-port 49 authentication-only key abc
BigIron RX(config)# tacacs-server host 1.2.3.5 auth-port 49 authorization-only key def
BigIron RX(config)# tacacs-server host 1.2.3.6 auth-port 49 accounting-only key ghi
Syntax: tacacs-server host <ip-addr> | <server-name> [auth-port <number> [authentication-only | authorizationonly | accounting-only | default] [key <string>] ]
The default parameter causes the server to be used for all AAA functions.
After authentication takes place, the server that performed the authentication is used for authorization and/or accounting. If the authenticating server cannot perform the requested function, then the next server in the configured list of servers is tried; this process repeats until a server that can perform the requested function is found, or every server in the configured list has been tried.
Setting Optional TACACS/TACACS+ Parameters
You can set the following optional parameters in a TACACS/TACACS+ configuration:
• TACACS+ key – This parameter specifies the value that the Foundry device sends to the TACACS+ server when trying to authenticate user access.
• Retransmit interval – This parameter specifies how many times the Foundry device will resend an authentication request when the TACACS/TACACS+ server does not respond. The retransmit value can be from 1 – 5 times. The default is 3 times.
• Dead time – This parameter specifies how long the Foundry device waits for the primary authentication server to reply before deciding the server is dead and trying to authenticate using the next server. The dead-time value can be from 1 – 5 seconds. The default is 3 seconds.
• Timeout – This parameter specifies how many seconds the Foundry device waits for a response from a
TACACS/TACACS+ server before either retrying the authentication request, or determining that the TACACS/
TACACS+ servers are unavailable and moving on to the next authentication method in the authenticationmethod list. The timeout can be from 1 – 15 seconds. The default is 3 seconds.
Setting the TACACS+ Key
The key parameter in the tacacs-server command is used to encrypt TACACS+ packets before they are sent over the network. The value for the key parameter on the BigIron RX should match the one configured on the
TACACS+ server. The key can be from 1 – 32 characters in length and cannot include any space characters.
NOTE: The tacacs-server key command applies only to TACACS+ servers, not to TACACS servers. If you are configuring TACACS, do not configure a key on the TACACS server and do not enter a key on the BigIron RX.
To specify a TACACS+ server key, enter the following command:
BigIron RX(config)# tacacs-server key rkwong
Syntax: tacacs-server key [0 | 1] <string>
When you display the configuration of the BigIron RX, the TACACS+ keys are encrypted. For example:
BigIron RX(config)# tacacs-server key 1 abc
BigIron RX(config)# write terminal
...
tacacs-server host 1.2.3.5 auth-port 49 tacacs key 1 $!2d
3-22 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
NOTE:
Encryption of the TACACS+ keys is done by default. The 0 parameter disables encryption. The 1 parameter is not required; it is provided for backwards compatibility.
Setting the Retransmission Limit
The retransmit parameter specifies how many times the BigIron RX will resend an authentication request when the TACACS/TACACS+ server does not respond. The retransmit limit can be from 1 – 5 times. The default is 3 times.
To set the TACACS/TACACS+ retransmit limit, enter the following command:
BigIron RX(config)# tacacs-server retransmit 5
Syntax: tacacs-server retransmit <number>
Setting the Dead Time Parameter
The dead-time parameter specifies how long the BigIron RX waits for the primary authentication server to reply before deciding the server is dead and trying to authenticate using the next server. The dead-time value can be from 1 – 5 seconds. The default is 3 seconds.
To set the TACACS/TACACS+ dead-time value, enter the following command:
BigIron RX(config)# tacacs-server dead-time 5
Syntax: tacacs-server dead-time <number>
Setting the Timeout Parameter
The timeout parameter specifies how many seconds the Foundry device waits for a response from the TACACS/
TACACS+ server before either retrying the authentication request, or determining that the TACACS/TACACS+ server is unavailable and moving on to the next authentication method in the authentication-method list. The timeout can be from 1 – 15 seconds. The default is 3 seconds.
BigIron RX(config)# tacacs-server timeout 5
Syntax: tacacs-server timeout <number>
Configuring Authentication-Method Lists for TACACS/TACACS+
You can use TACACS/TACACS+ to authenticate Telnet/SSH access and access to Privileged EXEC level and
CONFIG levels of the CLI. When configuring TACACS/TACACS+ authentication, you create authenticationmethod lists specifically for these access methods, specifying TACACS/TACACS+ as the primary authentication method.
Within the authentication-method list, TACACS/TACACS+ is specified as the primary authentication method and up to six backup authentication methods are specified as alternates. If TACACS/TACACS+ authentication fails due to an error, the device tries the backup authentication methods in the order they appear in the list.
When you configure authentication-method lists for TACACS/TACACS+ authentication, you must create a separate authentication-method list for Telnet/SSH CLI access, and for access to the Privileged EXEC level and
CONFIG levels of the CLI.
To create an authentication-method list that specifies TACACS/TACACS+ as the primary authentication method for securing Telnet/SSH access to the CLI:
BigIron RX(config)# enable telnet authentication
BigIron RX(config)# aaa authentication login default tacacs local
The commands above cause TACACS/TACACS+ to be the primary authentication method for securing Telnet/SSH access to the CLI. If TACACS/TACACS+ authentication fails due to an error with the server, authentication is performed using local user accounts instead.
To create an authentication-method list that specifies TACACS/TACACS+ as the primary authentication method for securing access to Privileged EXEC level and CONFIG levels of the CLI:
BigIron RX(config)# aaa authentication enable default tacacs local none
November 2005 © 2005 Foundry Networks, Inc.
3-23
Foundry BigIron RX Series Configuration Guide
The command above causes TACACS/TACACS+ to be the primary authentication method for securing access to
Privileged EXEC level and CONFIG levels of the CLI. If TACACS/TACACS+ authentication fails due to an error with the server, local authentication is used instead. If local authentication fails, no authentication is used; the device automatically permits access.
NOTE:
For examples of how to define authentication-method lists for types of authentication other than TACACS/
TACACS+, see “Configuring Authentication-Method Lists” on page 3-42.
Entering Privileged EXEC Mode After a Telnet or SSH Login
By default, a user enters User EXEC mode after a successful login through Telnet or SSH. Optionally, you can configure the device so that a user enters Privileged EXEC mode after a Telnet or SSH login. To do this, use the following command:
BigIron RX(config)# aaa authentication login privilege-mode
Syntax: aaa authentication login privilege-mode
The user’s privilege level is based on the privilege level granted during login.
Configuring Enable Authentication to Prompt for Password Only
If Enable authentication is configured on the device, by default, a user is prompted for a username (up to 255 characters) and password when the user attempts to gain Super User access to the Privileged EXEC and
CONFIG levels of the CLI. You can configure the Foundry device to prompt only for a password. The device uses the username entered at login, if one is available. If no username was entered at login, the device prompts for both username and password.
To configure the BigIron RX to prompt only for a password when a user attempts to gain Super User access to the
Privileged EXEC and CONFIG levels of the CLI:
BigIron RX(config)# aaa authentication enable implicit-user
Syntax: [no] aaa authentication enable implicit-user
Telnet/SSH Prompts When the TACACS+ Server is Unavailable
When TACACS+ is the first method in the authentication method list, the device displays the login prompt received from the TACACS+ server. If a user attempts to login through Telnet or SSH, but none of the configured TACACS+ servers are available, the following takes place:
• If the next method in the authentication method list is "enable", the login prompt is skipped, and the user is prompted for the Enable password (that is, the password configured with the enable super-user-password command).
• If the next method in the authentication method list is "line", the login prompt is skipped, and the user is prompted for the Line password (that is, the password configured with the enable telnet password command).
Configuring TACACS+ Authorization
The BigIron RX supports TACACS+ authorization for controlling access to management functions in the CLI.
Two kinds of TACACS+ authorization are supported:
• Exec authorization determines a user’s privilege level when they are authenticated
• Command authorization consults a TACACS+ server to get authorization for commands entered by the user
Configuring Exec Authorization
When TACACS+ exec authorization is performed, the BigIron RX consults a TACACS+ server to determine the privilege level of the authenticated user.
To configure TACACS+ exec authorization on the BigIron RX, enter the following command:
3-24 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
BigIron RX(config)# aaa authorization exec default tacacs+
Syntax: aaa authorization exec default tacacs+ | radius | none
If you specify none, or omit the aaa authorization exec command from the device’s configuration, no exec authorization is performed.
A user’s privilege level is obtained from the TACACS+ server in the “foundry-privlvl” A-V pair. If the aaa
authorization exec default tacacs command exists in the configuration, the device assigns the user the privilege level specified by this A-V pair. If the command does not exist in the configuration, then the value in the “foundryprivlvl” A-V pair is ignored, and the user is granted Super User access.
NOTE:
If the aaa authorization exec default tacacs+ command exists in the configuration, following successful authentication the device assigns the user the privilege level specified by the “foundry-privlvl” A-V pair received from the TACACS+ server. If the aaa authorization exec default tacacs+ command does not exist in the configuration, then the value in the “foundry-privlvl” A-V pair is ignored, and the user is granted Super User access.
Also note that in order for the aaa authorization exec default tacacs+ command to work, either the
aaa authentication enable default tacacs+ command, or the aaa authentication login privilege-mode command must also exist in the configuration.
Configuring an Attribute-Value Pair on the TACACS+ Server
During TACACS+ exec authorization, the Foundry device expects the TACACS+ server to send a response containing an A-V (Attribute-Value) pair that specifies the privilege level of the user. When the BigIron RX receives the response, it extracts an A-V pair configured for the Exec service and uses it to determine the user’s privilege level.
To set a user’s privilege level, you can configure the “foundry-privlvl” A-V pair for the Exec service on the
TACACS+ server. For example: user=bob {
default service = permit
member admin
# Global password
global = cleartext "cat"
service = exec {
foundry-privlvl = 0
}
}
In this example, the A-V pair foundry-privlvl = 0 grants the user full read-write access. The value in the foundry-privlvl A-V pair is an integer that indicates the privilege level of the user. Possible values are 0 for superuser level, 4 for port-config level, or 5 for read-only level. If a value other than 0, 4, or 5 is specified in the foundryprivlvl A-V pair, the default privilege level of 5 (read-only) is used. The foundry-privlvl A-V pair can also be embedded in the group configuration for the user. See your TACACS+ documentation for the configuration syntax relevant to your server.
If the foundry-privlvl A-V pair is not present, the BigIron RX extracts the last A-V pair configured for the Exec service that has a numeric value. The BigIron RX uses this A-V pair to determine the user’s privilege level. For example: user=bob {
default service = permit
member admin
# Global password
global = cleartext "cat"
service = exec {
privlvl = 15
}
}
November 2005 © 2005 Foundry Networks, Inc.
3-25
Foundry BigIron RX Series Configuration Guide
The attribute name in the A-V pair is not significant; the BigIron RX uses the last one that has a numeric value.
However, the BigIron RX interprets the value for a non-”foundry-privlvl” A-V pair differently than it does for a
“foundry-privlvl” A-V pair. The following table lists how the BigIron RX associates a value from a non-”foundryprivlvl” A-V pair with a Foundry privilege level.
Table 3.2: Foundry Equivalents for non-“foundry-privlvl” A-V Pair Values
Value for non-“foundry-privlvl” A-V Pair
15
From 14 – 1
Any other number or 0
Foundry Privilege Level
0 (super-user)
4 (port-config)
5 (read-only)
In the example above, the A-V pair configured for the Exec service is privlvl = 15. The BigIron RX uses the value in this A-V pair to set the user’s privilege level to 0 (super-user), granting the user full read-write access.
In a configuration that has both a “foundry-privlvl” A-V pair and a non-”foundry-privlvl” A-V pair for the Exec service, the non-”foundry-privlvl” A-V pair is ignored. For example: user=bob {
default service = permit
member admin
# Global password
global = cleartext "cat"
service = exec {
foundry-privlvl = 4
privlvl = 15
}
}
In this example, the user would be granted a privilege level of 4 (port-config level). The privlvl = 15 A-V pair is ignored by the BigIron RX.
If the TACACS+ server has no A-V pair configured for the Exec service, the default privilege level of 5 (read-only) is used.
Configuring Command Authorization
When TACACS+ command authorization is enabled, the BigIron RX consults a TACACS+ server to get authorization for commands entered by the user.
You enable TACACS+ command authorization by specifying a privilege level whose commands require authorization. For example, to configure the BigIron RX to perform authorization for the commands available at the Super User privilege level (that is, all commands on the device), enter the following command:
BigIron RX(config)# aaa authorization commands 0 default tacacs+
Syntax: aaa authorization commands <privilege-level> default tacacs+ | radius | none
The <privilege-level> parameter can be one of the following:
• 0 – Authorization is performed for commands available at the Super User level (all commands)
• 4 – Authorization is performed for commands available at the Port Configuration level (port-config and readonly commands)
• 5 – Authorization is performed for commands available at the Read Only level (read-only commands)
3-26 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
NOTE:
TACACS+ command authorization can be performed only for commands entered from Telnet or SSH sessions, or from the console. No authorization is performed for commands entered at the Web management interface or IronView Network Manager.
TACACS+ command authorization is not performed for the following commands:
• At all levels: exit, logout, end, and quit.
• At the Privileged EXEC level: enable or enable <text>, where <text> is the password configured for the Super
User privilege level.
If configured, command accounting is performed for these commands.
AAA Support for Console Commands
To enable AAA support for commands entered at the console, enter the following command:
BigIron RX(config)# enable aaa console
Syntax: [no] enable aaa console
NOTE:
AAA support for commands entered at the console can include the following:
• Login prompt that uses AAA authentication, using authentication-method lists
• Exec Authorization
• Exec Accounting
• System Accounting
Configuring TACACS+ Accounting
The BigIron RX supports TACACS+ accounting for recording information about user activity and system events.
When you configure TACACS+ accounting on a BigIron RX, information is sent to a TACACS+ accounting server when specified events occur, such as when a user logs into the device or the system is rebooted.
Configuring TACACS+ Accounting for Telnet/SSH (Shell) Access
To send an Accounting Start packet to the TACACS+ accounting server when an authenticated user establishes a
Telnet or SSH session on the BigIron RX, and an Accounting Stop packet when the user logs out:
BigIron RX(config)# aaa accounting exec default start-stop tacacs+
Syntax: aaa accounting exec default start-stop radius | tacacs+ | none
Configuring TACACS+ Accounting for CLI Commands
You can configure TACACS+ accounting for CLI commands by specifying a privilege level whose commands require accounting. For example, to configure the BigIron RX to perform TACACS+ accounting for the commands available at the Super User privilege level (that is; all commands on the device), enter the following command:
BigIron RX(config)# aaa accounting commands 0 default start-stop tacacs+
An Accounting Start packet is sent to the TACACS+ accounting server when a user enters a command, and an
Accounting Stop packet is sent when the service provided by the command is completed.
NOTE:
If authorization is enabled, and the command requires authorization, then authorization is performed before accounting takes place. If authorization fails for the command, no accounting takes place.
Syntax: aaa accounting commands <privilege-level> default start-stop radius | tacacs+ | none
The <privilege-level> parameter can be one of the following:
• 0 – Records commands available at the Super User level (all commands)
November 2005 © 2005 Foundry Networks, Inc.
3-27
Foundry BigIron RX Series Configuration Guide
• 4 – Records commands available at the Port Configuration level (port-config and read-only commands)
• 5 – Records commands available at the Read Only level (read-only commands)
Configuring TACACS+ Accounting for System Events
You can configure TACACS+ accounting to record when system events occur on the BigIron RX. System events include rebooting and when changes to the active configuration are made.
The following command causes an Accounting Start packet to be sent to the TACACS+ accounting server when a system event occurs, and a Accounting Stop packet to be sent when the system event is completed:
BigIron RX(config)# aaa accounting system default start-stop tacacs+
Syntax: aaa accounting system default start-stop radius | tacacs+ | none
Configuring an Interface as the Source for All TACACS/TACACS+ Packets
You can designate the lowest-numbered IP address configured an Ethernet port, loopback interface, or virtual interface as the source IP address for all TACACS/TACACS+ packets from the BigIron RX. Identifying a single source IP address for TACACS/TACACS+ packets provides the following benefits:
• If your TACACS/TACACS+ server is configured to accept packets only from specific links or IP addresses, you can use this feature to simplify configuration of the TACACS/TACACS+ server by configuring the Foundry device to always send the TACACS/TACACS+ packets from the same link or source address.
• If you specify a loopback interface as the single source for TACACS/TACACS+ packets, TACACS/TACACS+ servers can receive the packets regardless of the states of individual links. Thus, if a link to the TACACS/
TACACS+ server becomes unavailable but the client or server can be reached through another link, the client or server still receives the packets, and the packets still have the source IP address of the loopback interface.
The software contains separate CLI commands for specifying the source interface for Telnet, TACACS/TACACS+, and RADIUS packets. You can configure a source interface for one or more of these types of packets.
To specify an Ethernet, loopback, or virtual interface as the source for all TACACS/TACACS+ packets from the device, use the following CLI method. The software uses the lowest-numbered IP address configured on the port or interface as the source IP address for TACACS/TACACS+ packets originated by the device.
To specify the lowest-numbered IP address configured on a virtual interface as the device’s source for all TACACS/
TACACS+ packets, enter commands such as the following:
BigIron RX(config)# int ve 1
BigIron RX(config-vif-1)# ip address 10.0.0.3/24
BigIron RX(config-vif-1)# exit
BigIron RX(config)# ip tacacs source-interface ve 1
The commands in this example configure virtual interface 1, assign IP address 10.0.0.3/24 to the interface, then designate the interface as the source for all TACACS/TACACS+ packets from the BigIron RX.
Syntax: ip tacacs source-interface ethernet <portnum> | loopback <num> | ve <num>
The <num> parameter is a loopback interface or virtual interface number. If you specify an Ethernet, the
<portnum> is the port’s number (including the slot number, if you are configuring a device).
3-28 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
Displaying TACACS/TACACS+ Statistics and Configuration Information
The show aaa command displays information about all TACACS+ and RADIUS servers identified on the device.
For example:
BigIron RX# show aaa
Tacacs+ key: foundry
Tacacs+ retries: 1
Tacacs+ timeout: 15 seconds
Tacacs+ dead-time: 3 minutes
Tacacs+ Server: 207.95.6.90 Port:49:
opens=6 closes=3 timeouts=3 errors=0
packets in=4 packets out=4 no connection
Radius key: networks
Radius retries: 3
Radius timeout: 3 seconds
Radius dead-time: 3 minutes
Radius Server: 207.95.6.90 Auth Port=1645 Acct Port=1646:
opens=2 closes=1 timeouts=1 errors=0
packets in=1 packets out=4 no connection
Syntax: show aaa
The following table describes the TACACS/TACACS+ information displayed by the show aaa command.
Field
Tacacs+ key
Tacacs+ retries
Tacacs+ timeout
Tacacs+ dead-time
Tacacs+ Server connection
Table 3.3: Output of the show aaa command for TACACS/TACACS+
Description
The setting configured with the tacacs-server key command. At the Super User privilege level, the actual text of the key is displayed. At the other privilege levels, a string of periods (....) is displayed instead of the text.
The setting configured with the tacacs-server retransmit command.
The setting configured with the tacacs-server timeout command.
The setting configured with the tacacs-server dead-time command.
For each TACACS/TACACS+ server, the IP address, port, and the following statistics are displayed: opens Number of times the port was opened for communication with the server closes timeouts
Number of times the port was closed normally
Number of times port was closed due to a timeout errors packets in
Number of times an error occurred while opening the port
Number of packets received from the server packets out Number of packets sent to the server
The current connection status. This can be “no connection” or “connection active”.
November 2005 © 2005 Foundry Networks, Inc.
3-29
Foundry BigIron RX Series Configuration Guide
The show web command displays the privilege level of Web management interface users. For example:
BigIron RX(config)#show web
User Privilege IP address set 0 192.168.1.234
Syntax: show web
Configuring RADIUS Security
You can use a Remote Authentication Dial In User Service (RADIUS) server to secure the following types of access to the BigIron RX:
• Telnet access
• SSH access
• Web management access
• Access to the Privileged EXEC level and CONFIG levels of the CLI
NOTE:
The BigIron RX does not support RADIUS security for SNMP (IronView Network Manager) access.
3-30
RADIUS Authentication, Authorization, and Accounting
When RADIUS authentication is implemented, the BigIron RX consults a RADIUS server to verify user names and passwords. You can optionally configure RADIUS authorization, in which the BigIron RX consults a list of commands supplied by the RADIUS server to determine whether a user can execute a command he or she has entered, as well as accounting, which causes the BigIron RX to log information on a RADIUS accounting server when specified events occur on the device.
NOTE:
By default, a user logging into the device via Telnet or SSH first enters the User EXEC level. The user can then enter the enable command to get to the Privileged EXEC level.
A user that is successfully authenticated can be automatically placed at the Privileged EXEC level after login. See
“Entering Privileged EXEC Mode After a Telnet or SSH Login” on page 3-37.
RADIUS Authentication
When RADIUS authentication takes place, the following events occur:
1.
A user attempts to gain access to the BigIron RX by doing one of the following:
• Logging into the device using Telnet, SSH, or the Web management interface
• Entering the Privileged EXEC level or CONFIG level of the CLI
2.
The user is prompted for a username and password.
3.
The user enters a username and password.
4.
The BigIron RX sends a RADIUS Access-Request packet containing the username and password to the
RADIUS server.
5.
The RADIUS server validates the BigIron RX using a shared secret (the RADIUS key).
6.
The RADIUS server looks up the username in its database.
7.
If the username is found in the database, the RADIUS server validates the password.
8.
If the password is valid, the RADIUS server sends an Access-Accept packet to the BigIron RX, authenticating the user. Within the Access-Accept packet are three Foundry vendor-specific attributes that indicate:
• The privilege level of the user
© 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
• A list of commands
• Whether the user is allowed or denied usage of the commands in the list
The last two attributes are used with RADIUS authorization, if configured.
9.
The user is authenticated, and the information supplied in the Access-Accept packet for the user is stored on the BigIron RX. The user is granted the specified privilege level. If you configure RADIUS authorization, the user is allowed or denied usage of the commands in the list.
RADIUS Authorization
When RADIUS authorization takes place, the following events occur:
1.
A user previously authenticated by a RADIUS server enters a command on the BigIron RX.
2.
The BigIron RX looks at its configuration to see if the command is at a privilege level that requires RADIUS command authorization.
3.
If the command belongs to a privilege level that requires authorization, the BigIron RX looks at the list of commands delivered to it in the RADIUS Access-Accept packet when the user was authenticated. (Along with the command list, an attribute was sent that specifies whether the user is permitted or denied usage of the commands in the list.)
NOTE:
After RADIUS authentication takes place, the command list resides on the BigIron RX. The RADIUS server is not consulted again once the user has been authenticated. This means that any changes made to the user’s command list on the RADIUS server are not reflected until the next time the user is authenticated by the RADIUS server, and the new command list is sent to the BigIron RX.
4.
If the command list indicates that the user is authorized to use the command, the command is executed.
RADIUS Accounting
RADIUS accounting works as follows:
1.
One of the following events occur on the BigIron RX:
• A user logs into the management interface using Telnet or SSH
• A user enters a command for which accounting has been configured
• A system event occurs, such as a reboot or reloading of the configuration file
2.
The BigIron RX checks its configuration to see if the event is one for which RADIUS accounting is required.
3.
If the event requires RADIUS accounting, the BigIron RX sends a RADIUS Accounting Start packet to the
RADIUS accounting server, containing information about the event.
4.
The RADIUS accounting server acknowledges the Accounting Start packet.
5.
The RADIUS accounting server records information about the event.
6.
When the event is concluded, the BigIron RX sends an Accounting Stop packet to the RADIUS accounting server.
7.
The RADIUS accounting server acknowledges the Accounting Stop packet.
November 2005 © 2005 Foundry Networks, Inc.
3-31
Foundry BigIron RX Series Configuration Guide
AAA Operations for RADIUS
The following table lists the sequence of authentication, authorization, and accounting operations that take place when a user gains access to a BigIron RX that has RADIUS security configured.
User Action
User attempts to gain access to the
Privileged EXEC and CONFIG levels of the CLI
User logs in using Telnet/SSH
User logs into the Web management interface
User logs out of Telnet/SSH session
User enters system commands
(for example, reload, boot system)
Applicable AAA Operations
Enable authentication: aaa authentication enable default <method-list>
System accounting start: aaa accounting system default start-stop <method-list>
Login authentication: aaa authentication login default <method-list>
EXEC accounting Start: aaa accounting exec default start-stop <method-list>
System accounting Start: aaa accounting system default start-stop <method-list>
Web authentication: aaa authentication web-server default <method-list>
Command authorization for logout command: aaa authorization commands <privilege-level> default <method-list>
Command accounting: aaa accounting commands <privilege-level> default start-stop
<method-list>
EXEC accounting stop: aaa accounting exec default start-stop <method-list>
Command authorization: aaa authorization commands <privilege-level> default <method-list>
Command accounting: aaa accounting commands <privilege-level> default start-stop
<method-list>
System accounting stop: aaa accounting system default start-stop <method-list>
3-32 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
User Action
User enters the command:
[no] aaa accounting system default start-stop <method-list>
User enters other commands
Applicable AAA Operations
Command authorization: aaa authorization commands <privilege-level> default <method-list>
Command accounting: aaa accounting commands <privilege-level> default start-stop
<method-list>
System accounting start: aaa accounting system default start-stop <method-list>
Command authorization: aaa authorization commands <privilege-level> default <method-list>
Command accounting: aaa accounting commands <privilege-level> default start-stop
<method-list>
AAA Security for Commands Pasted Into the running configuration
If AAA security is enabled on the device, commands pasted into the running configuration are subject to the same
AAA operations as if they were entered manually.
When you paste commands into the running configuration, and AAA command authorization and/or accounting is configured on the device, AAA operations are performed on the pasted commands. The AAA operations are performed before the commands are actually added to the running configuration. The server performing the AAA operations should be reachable when you paste the commands into the running configuration file. If the device determines that a pasted command is invalid, AAA operations are halted on the remaining commands. The remaining commands may not be executed if command authorization is configured.
NOTE:
Since RADIUS command authorization relies on a list of commands received from the RADIUS server when authentication is performed, it is important that you use RADIUS authentication when you also use RADIUS command authorization.
RADIUS Configuration Considerations
• You must deploy at least one RADIUS server in your network.
• The BigIron RX supports authentication using up to eight RADIUS servers. The device tries to use the servers in the order you add them to the device’s configuration. If one RADIUS server is not responding, the
Foundry device tries the next one in the list.
• You can select only one primary authentication method for each type of access to a device (CLI through
Telnet, CLI Privileged EXEC and CONFIG levels). For example, you can select RADIUS as the primary authentication method for Telnet CLI access, but you cannot also select TACACS+ authentication as the primary method for the same type of access. However, you can configure backup authentication methods for each access type.
RADIUS Configuration Procedure
Use the following procedure to configure a BigIron RX for RADIUS:
1.
Configure Foundry vendor-specific attributes on the RADIUS server. See “Configuring Foundry-Specific
Attributes on the RADIUS Server” on page 3-34.
2.
November 2005 © 2005 Foundry Networks, Inc.
3-33
Foundry BigIron RX Series Configuration Guide
3.
Set RADIUS parameters. See “Setting RADIUS Parameters” on page 3-36.
4.
5.
Optionally configure RADIUS authorization. See “Configuring RADIUS Authorization” on page 3-38.
6.
Optionally configure RADIUS accounting. “Configuring RADIUS Accounting” on page 3-39.
Configuring Foundry-Specific Attributes on the RADIUS Server
NOTE:
For the BigIron RX, RADIUS Challenge is supported for 802.1x authentication but not for login authentication.
During the RADIUS authentication process, if a user supplies a valid username and password, the RADIUS server sends an Access-Accept packet to the BigIron RX, authenticating the user. Within the Access-Accept packet are three Foundry vendor-specific attributes that indicate:
• The privilege level of the user
• A list of commands
• Whether the user is allowed or denied usage of the commands in the list
You must add these three Foundry vendor-specific attributes to your RADIUS server’s configuration, and configure the attributes in the individual or group profiles of the users that will access the BigIron RX.
Foundry’s Vendor-ID is 1991, with Vendor-Type 1. The following table describes the Foundry vendor-specific attributes.
Attribute Name
foundry-privilege-level
Table 3.4: Foundry vendor-specific attributes for RADIUS
Attribute ID Data Type Description
1 integer Specifies the privilege level for the user.
This attribute can be set to one of the following:
0
Super User level – Allows complete read-and-write access to the system.
This is generally for system administrators and is the only management privilege level that allows you to configure passwords.
4
5
Port Configuration level – Allows readand-write access for specific ports but not for global (system-wide) parameters.
Read Only level – Allows access to the Privileged EXEC mode and
CONFIG mode of the CLI but only with read access.
3-34 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
Table 3.4: Foundry vendor-specific attributes for RADIUS
Attribute Name
foundry-command-string foundry-command-exception-flag
Attribute ID Data Type Description
2 string
3 integer
Specifies a list of CLI commands that are permitted or denied to the user when
RADIUS authorization is configured.
The commands are delimited by semicolons (;). You can specify an asterisk (*) as a wildcard at the end of a command string.
For example, the following command list specifies all show and debug ip commands, as well as the write terminal command: show *; debug ip *; write term*
Specifies whether the commands indicated by the foundry-command-string attribute are permitted or denied to the user. This attribute can be set to one of the following:
0
Permit execution of the commands indicated by foundry-command-string, deny all other commands.
1
Deny execution of the commands indicated by foundry-command-string, permit all other commands.
Identifying the RADIUS Server to the BigIron RX
To use a RADIUS server to authenticate access to a BigIron RX, you must identify the server to the BigIron RX.
For example:
BigIron RX(config)# radius-server host 209.157.22.99
Syntax: radius-server host <ip-addr> | <server-name> [auth-port <number> acct-port <number>]
The host <ip-addr> | <server-name> parameter is either an IP address or an ASCII text string.
The <auth-port> parameter is the Authentication port number; it is an optional parameter. The default is 1812.
The <acct-port> parameter is the Accounting port number; it is an optional parameter. The default is 1813.
Specifying Different Servers for Individual AAA Functions
In a RADIUS configuration, you can designate a server to handle a specific AAA task. For example, you can designate one RADIUS server to handle authorization and another RADIUS server to handle accounting. You can specify individual servers for authentication and accounting, but not for authorization. You can set the RADIUS key for each server.
To specify different RADIUS servers for authentication, authorization, and accounting:
BigIron RX(config)# radius-server host 1.2.3.4 authentication-only key abc
BigIron RX(config)# radius-server host 1.2.3.5 authorization-only key def
BigIron RX(config)# radius-server host 1.2.3.6 accounting-only key ghi
Syntax: radius-server host <ip-addr> | <server-name> [auth-port <number> acct-port <number> [authenticationonly | authorization-only | accounting-only | default] [key <string>] ]
The default parameter causes the server to be used for all AAA functions.
November 2005 © 2005 Foundry Networks, Inc.
3-35
Foundry BigIron RX Series Configuration Guide
After authentication takes place, the server that performed the authentication is used for authorization and/or accounting. If the authenticating server cannot perform the requested function, then the next server in the configured list of servers is tried; this process repeats until a server that can perform the requested function is found, or every server in the configured list has been tried.
Setting RADIUS Parameters
You can set the following parameters in a RADIUS configuration:
• RADIUS key – This parameter specifies the value that the BigIron RX sends to the RADIUS server when trying to authenticate user access.
• Retransmit interval – This parameter specifies how many times the BigIron RX will resend an authentication request when the RADIUS server does not respond. The retransmit value can be from 1 – 5 times. The default is 3 times.
• Timeout – This parameter specifies how many seconds the BigIron RX waits for a response from a RADIUS server before either retrying the authentication request, or determining that the RADIUS servers are unavailable and moving on to the next authentication method in the authentication-method list. The timeout can be from 1 – 15 seconds. The default is 3 seconds.
Setting the RADIUS Key
The key parameter in the radius-server command is used to encrypt RADIUS packets before they are sent over the network. The value for the key parameter on the BigIron RX should match the one configured on the RADIUS server. The key can be from 1 – 32 characters in length and cannot include any space characters.
To specify a RADIUS server key:
BigIron RX(config)# radius-server key mirabeau
Syntax: radius-server key [0 | 1] <string>
When you display the configuration of the BigIron RX, the RADIUS key is encrypted. For example:
BigIron RX(config)# radius-server key 1 abc
BigIron RX(config)# write terminal
...
radius-server host 1.2.3.5 radius key 1 $!2d
NOTE:
Encryption of the RADIUS keys is done by default. The 0 parameter disables encryption. The 1 parameter is not required; it is provided for backwards compatibility.
Setting the Retransmission Limit
The retransmit parameter specifies the maximum number of retransmission attempts. When an authentication request times out, the Foundry software will retransmit the request up to the maximum number of retransmissions configured. The default retransmit value is 3 retries. The range of retransmit values is from 1 – 5.
To set the RADIUS retransmit limit:
BigIron RX(config)# radius-server retransmit 5
Syntax: radius-server retransmit <number>
Setting the Timeout Parameter
The timeout parameter specifies how many seconds the BigIron RX waits for a response from the RADIUS server before either retrying the authentication request, or determining that the RADIUS server is unavailable and moving on to the next authentication method in the authentication-method list. The timeout can be from 1 – 15 seconds.
The default is 3 seconds.
BigIron RX(config)# radius-server timeout 5
Syntax: radius-server timeout <number>
3-36 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
Configuring Authentication-Method Lists for RADIUS
You can use RADIUS to authenticate Telnet/SSH access and access to Privileged EXEC level and CONFIG levels of the CLI. When configuring RADIUS authentication, you create authentication-method lists specifically for these access methods, specifying RADIUS as the primary authentication method.
Within the authentication-method list, RADIUS is specified as the primary authentication method and up to six backup authentication methods are specified as alternates. If RADIUS authentication fails due to an error, the device tries the backup authentication methods in the order they appear in the list.
When you configure authentication-method lists for RADIUS, you must create a separate authentication-method list for Telnet or SSH CLI access and for CLI access to the Privileged EXEC level and CONFIG levels of the CLI.
To create an authentication-method list that specifies RADIUS as the primary authentication method for securing
Telnet access to the CLI:
BigIron RX(config)# enable telnet authentication
BigIron RX(config)# aaa authentication login default radius local
The commands above cause RADIUS to be the primary authentication method for securing Telnet access to the
CLI. If RADIUS authentication fails due to an error with the server, local authentication is used instead.
To create an authentication-method list that specifies RADIUS as the primary authentication method for securing access to Privileged EXEC level and CONFIG levels of the CLI:
BigIron RX(config)# aaa authentication enable default radius local none
The command above causes RADIUS to be the primary authentication method for securing access to Privileged
EXEC level and CONFIG levels of the CLI. If RADIUS authentication fails due to an error with the server, local authentication is used instead. If local authentication fails, no authentication is used; the device automatically permits access.
NOTE:
For examples of how to define authentication-method lists for types of authentication other than RADIUS,
see “Configuring Authentication-Method Lists” on page 3-42.
Entering Privileged EXEC Mode After a Telnet or SSH Login
By default, a user enters User EXEC mode after a successful login through Telnet or SSH. You can configure the device so that a user enters Privileged EXEC mode after a Telnet or SSH login. To do this, use the following command:
BigIron RX(config)# aaa authentication login privilege-mode
Syntax: aaa authentication login privilege-mode
The user’s privilege level is based on the privilege level granted during login.
Configuring Enable Authentication to Prompt for Password Only
If Enable authentication is configured on the device, by default, a user is prompted for a username and password. when the user attempts to gain Super User access to the Privileged EXEC and CONFIG levels of the CLI. You can configure the BigIron RX to prompt only for a password. The device uses the username (up to 255 characters) entered at login, if one is available. If no username was entered at login, the device prompts for both username and password.
To configure the BigIron RX to prompt only for a password when a user attempts to gain Super User access to the
Privileged EXEC and CONFIG levels of the CLI:
BigIron RX(config)# aaa authentication enable implicit-user
Syntax: [no] aaa authentication enable implicit-user
November 2005 © 2005 Foundry Networks, Inc.
3-37
Foundry BigIron RX Series Configuration Guide
Configuring RADIUS Authorization
The BigIron RX supports RADIUS authorization for controlling access to management functions in the CLI. Two kinds of RADIUS authorization are supported:
• Exec authorization determines a user’s privilege level when they are authenticated
• Command authorization consults a RADIUS server to get authorization for commands entered by the user
Configuring Exec Authorization
NOTE:
Before you configure RADIUS exec authorization on the BigIron RX, make sure that the aaa
authentication enable default radius command and/or the aaa authentication login privilege-mode command exist in the configuration.
When RADIUS exec authorization is performed, the BigIron RX consults a RADIUS server to determine the privilege level of the authenticated user.
To configure RADIUS exec authorization on the BigIron RX, enter the following command:
BigIron RX(config)# aaa authorization login default radius
BigIron RX(config)# aaa authorization enable default radius
BigIron RX(config)# aaa authorization login privilege-mode
BigIron RX(config)# aaa authorization exec default radius
Syntax: aaa authorization exec default radius | none
If you specify none, or omit the aaa authorization exec command from the device’s configuration, no exec authorization is performed.
NOTE:
If the aaa authorization exec default radius command exists in the configuration, following successful authentication the device assigns the user the privilege level specified by the foundry-privilege-level attribute received from the RADIUS server. If the aaa authorization exec default radius command does not exist in the configuration, then the value in the foundry-privilege-level attribute is ignored, and the user is granted Super User access.
For the aaa authorization exec default radius command to work, either the aaa authentication enable default
radius command, or the aaa authentication login privilege-mode command must also exist in the configuration.
Configuring Command Authorization
When RADIUS command authorization is enabled, the BigIron RX consults the list of commands supplied by the
RADIUS server during authentication to determine whether a user can execute a command he or she has entered.
You enable RADIUS command authorization by specifying a privilege level whose commands require authorization. For example, to configure the BigIron RX to perform authorization for the commands available at the Super User privilege level (that is; all commands on the device), enter the following command:
BigIron RX(config)# aaa authorization commands 0 default radius
Syntax: aaa authorization commands <privilege-level> default radius | tacacs+ | none
The <privilege-level> parameter can be one of the following:
• 0 – Authorization is performed (that is, the BigIron RX looks at the command list) for commands available at the Super User level (all commands)
• 4 – Authorization is performed for commands available at the Port Configuration level (port-config and readonly commands)
• 5 – Authorization is performed for commands available at the Read Only level (read-only commands)
3-38 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
NOTE:
RADIUS command authorization can be performed only for commands entered from Telnet or SSH sessions, or from the console. No authorization is performed for commands entered at the Web management interface or IronView Network Manager.
NOTE:
Since RADIUS command authorization relies on the command list supplied by the RADIUS server during authentication, you cannot perform RADIUS authorization without RADIUS authentication.
Command Authorization and Accounting for Console Commands
The BigIron RX supports command authorization and command accounting for CLI commands entered at the console. To configure the device to perform command authorization and command accounting for console commands, enter the following:
BigIron RX(config)# enable aaa console
Syntax: [no] enable aaa console
CAUTION:
If you have previously configured the device to perform command authorization using a RADIUS server, entering the enable aaa console command may prevent the execution of any subsequent commands entered on the console.
This happens because RADIUS command authorization requires a list of allowable commands from the RADIUS server. This list is obtained during RADIUS authentication. For console sessions, RADIUS authentication is performed only if you have configured Enable authentication and specified RADIUS as the authentication method
(for example, with the aaa authentication enable default radius command). If RADIUS authentication is never performed, the list of allowable commands is never obtained from the RADIUS server. Consequently, there would be no allowable commands on the console.
Configuring RADIUS Accounting
The BigIron RX supports RADIUS accounting for recording information about user activity and system events.
When you configure RADIUS accounting on BigIron RX, information is sent to a RADIUS accounting server when specified events occur, such as when a user logs into the device or the system is rebooted.
Configuring RADIUS Accounting for Telnet/SSH (Shell) Access
To send an Accounting Start packet to the RADIUS accounting server when an authenticated user establishes a
Telnet or SSH session on the BigIron RX, and an Accounting Stop packet when the user logs out:
BigIron RX(config)# aaa accounting exec default start-stop radius
Syntax: aaa accounting exec default start-stop radius | tacacs+ | none
Configuring RADIUS Accounting for CLI Commands
You can configure RADIUS accounting for CLI commands by specifying a privilege level whose commands require accounting. For example, to configure the BigIron RX to perform RADIUS accounting for the commands available at the Super User privilege level (that is; all commands on the device), enter the following command:
BigIron RX(config)# aaa accounting commands 0 default start-stop radius
An Accounting Start packet is sent to the RADIUS accounting server when a user enters a command, and an
Accounting Stop packet is sent when the service provided by the command is completed.
NOTE:
If authorization is enabled, and the command requires authorization, then authorization is performed before accounting takes place. If authorization fails for the command, no accounting takes place.
Syntax: aaa accounting commands <privilege-level> default start-stop radius | tacacs | none
The <privilege-level> parameter can be one of the following:
• 0 – Records commands available at the Super User level (all commands)
November 2005 © 2005 Foundry Networks, Inc.
3-39
Foundry BigIron RX Series Configuration Guide
• 4 – Records commands available at the Port Configuration level (port-config and read-only commands)
• 5 – Records commands available at the Read Only level (read-only commands)
Configuring RADIUS Accounting for System Events
You can configure RADIUS accounting to record when system events occur on the BigIron RX. System events include rebooting and when changes to the active configuration are made.
The following command causes an Accounting Start packet to be sent to the RADIUS accounting server when a system event occurs, and a Accounting Stop packet to be sent when the system event is completed:
BigIron RX(config)# aaa accounting system default start-stop radius
Syntax: aaa accounting system default start-stop radius | tacacs+ | none
Configuring an Interface as the Source for All RADIUS Packets
You can designate the lowest-numbered IP address configured an Ethernet port, loopback interface, or virtual interface as the source IP address for all RADIUS packets from the BigIron RX. Identifying a single source IP address for RADIUS packets provides the following benefits:
• If your RADIUS server is configured to accept packets only from specific links or IP addresses, you can use this feature to simplify configuration of the RADIUS server by configuring the BigIron RX to always send the
RADIUS packets from the same link or source address.
• If you specify a loopback interface as the single source for RADIUS packets, RADIUS servers can receive the packets regardless of the states of individual links. Thus, if a link to the RADIUS server becomes unavailable but the client or server can be reached through another link, the client or server still receives the packets, and the packets still have the source IP address of the loopback interface.
The software contains separate CLI commands for specifying the source interface for Telnet, TACACS/TACACS+, and RADIUS packets. You can configure a source interface for one or more of these types of packets.
To specify an Ethernet or a loopback or virtual interface as the source for all RADIUS packets from the device, use the following CLI method. The software uses the lowest-numbered IP address configured on the port or interface as the source IP address for RADIUS packets originated by the device.
To specify the lowest-numbered IP address configured on a virtual interface as the device’s source for all RADIUS packets, enter commands such as the following:
BigIron RX(config)# int ve 1
BigIron RX(config-vif-1)# ip address 10.0.0.3/24
BigIron RX(config-vif-1)# exit
BigIron RX(config)# ip radius source-interface ve 1
The commands in this example configure virtual interface 1, assign IP address 10.0.0.3/24 to the interface, then designate the interface as the source for all RADIUS packets from the BigIron RX.
Syntax: ip radius source-interface ethernet <portnum> | loopback <num> | ve <num>
The <num> parameter is a loopback interface or virtual interface number. If you specify an Ethernet port, the
<portnum> is the port’s number (including the slot number, if you are configuring a device).
3-40 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
Displaying RADIUS Configuration Information
The show aaa command displays information about all TACACS/TACACS+ and RADIUS servers identified on the device. For example:
BigIron RX# show aaa
Tacacs+ key: foundry
Tacacs+ retries: 1
Tacacs+ timeout: 15 seconds
Tacacs+ dead-time: 3 minutes
Tacacs+ Server: 207.95.6.90 Port:49:
opens=6 closes=3 timeouts=3 errors=0
packets in=4 packets out=4 no connection
Radius key: networks
Radius retries: 3
Radius timeout: 3 seconds
Radius dead-time: 3 minutes
Radius Server: 207.95.6.90 Auth Port=1645 Acct Port=1646:
opens=2 closes=1 timeouts=1 errors=0
packets in=1 packets out=4 no connection
Syntax: show aaa
The following table describes the RADIUS information displayed by the show aaa command.
Field
Radius key
Radius retries
Radius timeout
Radius dead-time
Radius Server connection
Table 3.5: Output of the show aaa command for RADIUS
Description
The setting configured with the radius-server key command. At the Super User privilege level, the actual text of the key is displayed. At the other privilege levels, a string of periods (....) is displayed instead of the text.
The setting configured with the radius-server retransmit command.
The setting configured with the radius-server timeout command.
The setting configured with the radius-server dead-time command.
For each RADIUS server, the IP address, and the following statistics are displayed:
Auth Port RADIUS authentication port number (default 1645)
Acct Port opens closes
RADIUS accounting port number (default 1646)
Number of times the port was opened for communication with the server
Number of times the port was closed normally timeouts errors
Number of times port was closed due to a timeout
Number of times an error occurred while opening the port packets in Number of packets received from the server packets out Number of packets sent to the server
The current connection status. This can be “no connection” or “connection active”.
November 2005 © 2005 Foundry Networks, Inc.
3-41
Foundry BigIron RX Series Configuration Guide
The show web command displays the privilege level of Web management interface users. For example:
BigIron RX(config)# show web
User Privilege IP address set 0 192.168.1.234
Syntax: show web
Configuring Authentication-Method Lists
To implement one or more authentication methods for securing access to the device, you configure authenticationmethod lists that set the order in which the authentication methods are consulted.
In an authentication-method list, you specify the access method (Telnet, Web, SNMP, and so on) and the order in which the device tries one or more of the following authentication methods:
• Local Telnet login password
• Local password for the Super User privilege level
• Local user accounts configured on the device
• Database on a TACACS or TACACS+ server
• Database on a RADIUS server
• No authentication
NOTE:
The TACACS/TACACS+, RADIUS, and Telnet login password authentication methods are not supported for SNMP access.
NOTE:
To authenticate Telnet access to the CLI, you also must enable the authentication by entering the
enable telnet authentication command at the global CONFIG level of the CLI. You cannot enable Telnet authentication using the Web management interface.
NOTE:
You do not need an authentication-method list to secure access based on ACLs or a list of IP addresses.
In an authentication-method list for a particular access method, you can specify up to seven authentication methods. If the first authentication method is successful, the software grants access and stops the authentication process. If the access is rejected by the first authentication method, the software denies access and stops checking.
However, if an error occurs with an authentication method, the software tries the next method on the list, and so on. For example, if the first authentication method is the RADIUS server, but the link to the server is down, the software will try the next authentication method in the list.
NOTE:
If an authentication method is working properly and the password (and user name, if applicable) is not known to that method, this is not an error. The authentication attempt stops, and the user is denied access.
The software will continue this process until either the authentication method is passed or the software reaches the end of the method list. If the Super User level password is not rejected after all the access methods in the list have been tried, access is granted.
3-42 © 2005 Foundry Networks, Inc.
November 2005
Securing Access to Management Functions
NOTE:
If a user cannot be authenticated using local authentication, then the next method on the authentication methods list is used to try to authenticate the user. If there is no method following local authentication, then the user is denied access to the device.
Configuration Considerations for Authentication-Method Lists
• For CLI access, you must configure authentication-method lists if you want the device to authenticate access using local user accounts or a RADIUS server. Otherwise, the device will authenticate using only the locally based password for the Super User privilege level.
• When no authentication-method list is configured specifically for Web management access, the device performs authentication using the SNMP community strings:
• For read-only access, you can use the user name “get” and the password “public”. The default read-only community string is “public”.
• There is no default read-write community string. Thus, by default, you cannot open a read-write management session using the Web management interface. You first must configure a read-write community string using the CLI. Then you can log on using “set” as the user name and the read-write
• If you configure an authentication-method list for Web management access and specify “local” as the primary authentication method, users who attempt to access the device using the Web management interface must supply a user name and password configured in one of the local user accounts on the device. The user
cannot access the device by entering “set” or “get” and the corresponding SNMP community string.
• For devices that can be managed using IronView Network Manager, the default authentication method (if no authentication-method list is configured for SNMP) is the CLI Super User level password. If no Super User level password is configured, then access through IronView Network Manager is not authenticated. To use local user accounts to authenticate access through IronView Network Manager, configure an authenticationmethod list for SNMP access and specify “local” as the primary authentication method.
Examples of Authentication-Method Lists
EXAMPLE:
The following example shows how to configure authentication-method lists for the Web management interface,
IronView Network Manager, and the Privileged EXEC and CONFIG levels of the CLI. In this example, the primary authentication method for each is “local”. The device will authenticate access attempts using the locally configured user names and passwords first.
To configure an authentication-method list for the Web management interface, enter a command such as the following:
BigIron RX(config)# aaa authentication web-server default local
This command configures the device to use the local user accounts to authenticate access to the device through the Web management interface. If the device does not have a user account that matches the user name and password entered by the user, the user is not granted access.
To configure an authentication-method list for IronView Network Manager, enter a command such as the following:
BigIron RX(config)# aaa authentication snmp-server default local
This command configures the device to use the local user accounts to authenticate access attempts through any network management software, such as IronView Network Manager.
To configure an authentication-method list for the Privileged EXEC and CONFIG levels of the CLI, enter the following command:
BigIron RX(config)# aaa authentication enable default local
November 2005 © 2005 Foundry Networks, Inc.
3-43
Foundry BigIron RX Series Configuration Guide
This command configures the device to use the local user accounts to authenticate attempts to access the
Privileged EXEC and CONFIG levels of the CLI.
EXAMPLE:
To configure the device to consult a RADIUS server first to authenticate attempts to access the Privileged EXEC and CONFIG levels of the CLI, then consult the local user accounts if the RADIUS server is unavailable, enter the following command:
BigIron RX(config)# aaa authentication enable default radius local
Syntax: [no] aaa authentication snmp-server | web-server | enable | login | dot1x default <method1> [<method2>]
[<method3>] [<method4>] [<method5>] [<method6>] [<method7>]
The snmp-server | web-server | enable | login | dot1x parameter specifies the type of access this authentication-method list controls. You can configure one authentication-method list for each type of access.
NOTE:
If you configure authentication for Web management access, authentication is performed each time a page is requested from the server. When frames are enabled on the Web management interface, the browser sends an HTTP request for each frame. The Foundry device authenticates each HTTP request from the browser.
To limit authentications to one per page, disable frames on the Web management interface.
NOTE:
TACACS/TACACS+ and RADIUS are not supported with the snmp-server parameter.
The <method1> parameter specifies the primary authentication method. The remaining optional <method> parameters specify additional methods to try if an error occurs with the primary method. A method can be one of
the values listed in the Method Parameter column in Table 3.6.
Table 3.6: Authentication Method Values
Method Parameter
line enable local tacacs tacacs+ radius none
Description
Authenticate using the password you configured for Telnet access. The
Telnet password is configured using the enable telnet password…
command. See “Setting a Telnet Password” on page 3-10.
Authenticate using the password you configured for the Super User privilege level. This password is configured using the enable super-
user-password… command. See “Setting Passwords for Management
Privilege Levels” on page 3-11.
Authenticate using a local user name and password you configured on the device. Local user names and passwords are configured using the
username… command. See “Configuring a Local User Account” on page 3-14.
Authenticate using the database on a TACACS server. You also must identify the server to the device using the tacacs-server command.
Authenticate using the database on a TACACS+ server. You also must identify the server to the device using the tacacs-server command.
Authenticate using the database on a RADIUS server. You also must identify the server to the device using the radius-server command.
Do not use any authentication method. The device automatically permits access.
3-44 © 2005 Foundry Networks, Inc.
November 2005
Chapter 4
Configuring Basic Parameters
This chapter describes how to configure the following basic system parameters:
•
System name, contact, and location – see “Entering System Administration Information” on page 4-2.
•
SNMP trap receiver, trap source address, and other parameters – see “Configuring Simple Network
Management (SNMP) Traps” on page 4-2.
•
•
•
•
Broadcast, Multicast, or Unknown-Unicast Rates” on page 4-10.
•
Banners that are displayed on users’ terminals – see “Configuring CLI Banners” on page 4-11.
•
Terminal display length – see “Configuring Terminal Display” on page 4-12.
•
•
Layer 2 switching – see “Enabling or Disabling Layer 2 Switching” on page 4-16
•
MAC age time – see “Changing the MAC Age Time” on page 4-17
•
Static MAC address entries – “Configuring Static MAC Addresses” on page 4-17
•
Static ARP entries – “Configuring Static ARP Entries” on page 4-18
NOTE:
For information about the Syslog buffer and messages, see “Using Syslog” on page A-1.
The BigIron RX is configured with default parameters to allow you to begin using the basic features of the system immediately. However, many advanced features, such as VLANs or routing protocols for the router, must first be enabled at the system (global) level before they can be configured.
You can find system level parameters at the Global CONFIG level of the CLI.
NOTE:
Before assigning or modifying any router parameters, you must assign the IP subnet (interface) addresses for each port.
November 2005 © 2005 Foundry Networks, Inc.
4-1
Foundry BigIron RX Series Configuration Guide
Entering System Administration Information
You can configure a system name, contact, and location for the BigIron RX and save the information locally in the configuration file for future reference. The information is not required for system operation but recommended.
When you configure a system name, it replaces the default system name in the CLI command prompt.
To configure a system name, contact, and location, enter commands such as the following:
BigIron RX(config)# hostname home home(config)# snmp-server contact Suzy Sanchez home(config)# snmp-server location Centerville home(config)# end home# write memory
The system name you configure home replaces the system name BigIron RX.
Syntax: hostname <string>
Syntax: snmp-server contact <string>
Syntax: snmp-server location <string>
The name, contact, and location each can be up to 32 alphanumeric characters. The text strings can contain blanks. The SNMP text strings do not require quotation marks when they contain blanks but the host name does.
NOTE:
The chassis name command does not change the CLI prompt. Instead, the command assigns an administrative ID to the device.
Configuring Simple Network Management (SNMP) Traps
This section explains how to do the following:
• Specify an SNMP trap receiver.
• Specify a source address and community string for all traps that the BigIron RX sends.
• Change the holddown time for SNMP traps.
• Disable individual SNMP traps. (All traps are enabled by default.)
• Disable traps for CLI access that is authenticated by a local user account, a RADIUS server, or a TACACS/
TACACS+ server.
NOTE:
Management Functions” on page 3-1.
Specifying an SNMP Trap Receiver
You can specify a trap receiver to ensure that all SNMP traps sent by the BigIron RX go to the same SNMP trap receiver or set of receivers, typically one or more host devices on the network. When you specify the host, you also specify a community string. The BigIron RX sends all the SNMP traps to the specified host(s) and includes the specified community string. Administrators can therefore filter for traps from a BigIron RX based on IP address or community string.
When you add a trap receiver, you can specify whether to have the community string encrypted or to have it shown in the clear. In either case, the software does not encrypt the string in the SNMP traps sent to the receiver.
To specify an SNMP trap receiver, enter a command such as the following:
BigIron RX(config)# snmp-server host 2.2.2.2 1 mypublic port 200
BigIron RX(config)# write memory
4-2 © 2005 Foundry Networks, Inc.
November 2005
Configuring Basic Parameters
The first commands adds trap receiver 2.2.2.2, configures the software to encrypt display of the community string, and designates the UDP port that will be used to receive traps. The second command saves the community string to the startup configuration file, and the software adds the following command to the file: snmp-server host 2.2.2.2 1 <encrypted-string>
Syntax: snmp-server host <ip-addr> [0 | 1] <string> [port <value>]
The <ip-addr> parameter specifies the IP address of the trap receiver.
The 0 | 1 parameter specifies whether you want the software to encrypt the string (1) or show the string in the clear
(0). The default is 0.
The <string> parameter specifies an SNMP community string configured on the BigIron RX. It can be a read-only string or a read-write string. It is not used to authenticate access to the trap host, but it is a useful method for filtering traps on the host. For example, if you configure each of your BigIron RX devices that use the trap host to send a different community string, you can easily distinguish among the traps from the devices based on the community strings.
The port <value> parameter specifies the UDP port that will be used to receive traps. This parameter allows you to configure several trap receivers in a system. With this parameter, IronView Network Manager and another network management application can coexist in the same system. The BigIron RX can be configured to send copies of traps to more than one network management application.
Specifying a Single Trap Source
You can specify a single trap source to ensure that all SNMP traps sent by the BigIron RX use the same source IP address. When you configure the SNMP source address, you specify the Ethernet port, loopback interface, or virtual routing interface that is the source for the traps. The BigIron RX then uses the lowest-numbered IP address configured on the port or interface as the source IP address in the SNMP traps it sends.
Identifying a single source IP address for SNMP traps provides the following benefits:
• If your trap receiver is configured to accept traps only from specific links or IP addresses, you can simplify configuration of the trap receiver by configuring the BigIron RX to always send the traps from the same link or source address.
• If you specify a loopback interface as the single source for SNMP traps, SNMP trap receivers can receive traps regardless of the states of individual links. Thus, if a link to the trap receiver becomes unavailable but the receiver can be reached through another link, the receiver still receives the trap, and the trap still has the source IP address of the loopback interface.
To configure the BigIron RX to send all SNMP traps from the first configured IP address on port 4/11, enter the following commands:
BigIron RX(config)# snmp-server trap-source ethernet 4/11
BigIron RX(config)# write memory
Syntax: snmp-server trap-source loopback <num> | ethernet <slot/port> | ve <num>
The <num> parameter is a loopback interface or virtual routing interface number.
To specify a loopback interface as the device’s SNMP trap source, enter commands such as the following:
BigIron RX(config)# int loopback 1
BigIron RX(config-lbif-1)# ip address 10.0.0.1/24
BigIron RX(config-lbif-1)# exit
BigIron RX(config)# snmp-server trap-source loopback 1
The commands configure loopback interface 1, gives it IP address 10.00.1/24, then designate it as the SNMP trap source for the BigIron RX. Regardless of the port the BigIron RX uses to send traps to the receiver, the traps always arrive from the same source IP address.
November 2005 © 2005 Foundry Networks, Inc.
4-3
Foundry BigIron RX Series Configuration Guide
Setting the SNMP Trap Holddown Time
When a BigIron RX starts up, the software waits for Layer 2 convergence (STP) and Layer 3 convergence (OSPF) before beginning to send SNMP traps to external SNMP servers. Until convergence occurs, the BigIron RX might not be able to reach the servers, in which case the messages are lost.
By default, the BigIron RX uses a one-minute holddown time to wait for the convergence to occur before starting to send SNMP traps. After the holddown time expires, the BigIron RX sends the traps, including traps such as “cold start” or “warm start” that occur before the holddown time expires.
You can change the holddown time to a value from one second to ten minutes.
To change the holddown time for SNMP traps, enter a command such as the following at the global CONFIG level of the CLI:
BigIron RX(config)# snmp-server enable traps holddown-time 30
The command changes the holddown time for SNMP traps to 30 seconds. The BigIron RX waits 30 seconds to allow convergence in STP and OSPF before sending traps to the SNMP trap receiver.
Syntax: [no] snmp-server enable traps holddown-time <secs>
The <secs> parameter specifies the number of seconds (1 – 600). The default is 60.
Disabling SNMP Traps
The BigIron RX comes with SNMP trap generation enabled by default for all traps.
NOTE:
By default, all SNMP traps are enabled at system startup.
You can selectively disable one or more of the following traps:
• SNMP authentication key
• Power supply failure
• Fan failure
• Cold start
• Link up
• Link down
• Bridge new root
• Bridge topology change
• Locked address violation
• Module insert
• Module remove
• BGP4
• OSPF
• FSRP
• VRRP
• VRRPE
To stop link down occurrences from being reported, enter the following:
BigIron RX(config)# no snmp-server enable traps link-down
Syntax: [no] snmp-server enable traps <trap-type>
A list of Foundry traps is available in the Foundry Management Information Base Guide.
4-4 © 2005 Foundry Networks, Inc.
November 2005
Configuring Basic Parameters
Disabling Syslog Messages and Traps for CLI Access
The BigIron RX sends Syslog messages and SNMP traps when a user logs into or out of the User EXEC or
Privileged EXEC level of the CLI. The feature, enabled by default, applies to users whose access is authenticated by an authentication-method list based on a local user account, RADIUS server, or TACACS/TACACS+ server.
NOTE:
The Privileged EXEC level is sometimes called the “Enable” level, because the command for accessing this level is enable.
Examples of Syslog Messages for CLI Access
When a user whose access is authenticated by a local user account, a RADIUS server, or a TACACS/TACACS+ server logs into or out of the CLI’s User EXEC or Privileged EXEC mode, the software generates a Syslog message and trap containing the following information:
• The time stamp
• The user name
• Whether the user logged in or out
• The CLI level the user logged into or out of (User EXEC or Privileged EXEC level)
NOTE:
Messages for accessing the User EXEC level apply only to access through Telnet. The device does not authenticate initial access through serial connections but does authenticate serial access to the Privileged EXEC level. Messages for accessing the Privileged EXEC level apply to access through the serial connection or Telnet.
The following examples show login and logout messages for the User EXEC and Privileged EXEC levels of the
CLI:
BigIron RX(config)# show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Buffer logging: level ACDMEINW, 12 messages logged level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning
Static Log Buffer:
Dec 15 19:04:14:A:Fan 1, fan on right connector, failed
Dynamic Log Buffer (50 entries):
Oct 15 18:01:11:info:dg logout from USER EXEC mode
Oct 15 17:59:22:info:dg logout from PRIVILEGE EXEC mode
Oct 15 17:38:07:info:dg login to PRIVILEGE EXEC mode
Oct 15 17:38:03:info:dg login to USER EXEC mode
Syntax: show logging
The first message (the one on the bottom) indicates that user “dg” logged in to the CLI’s User EXEC level on
October 15 at 5:38 PM and 3 seconds (Oct 15 17:38:03). The same user logged into the Privileged EXEC level four seconds later.
The user remained in the Privileged EXEC mode until 5:59 PM and 22 seconds. (The user could have used the
CONFIG modes as well. Once you access the Privileged EXEC level, no further authentication is required to access the CONFIG levels.) At 6:01 PM and 11 seconds, the user ended the CLI session.
Disabling the Syslog Messages and Traps
Logging of CLI access is enabled by default. To disable logging of CLI access, enter the following commands:
BigIron RX(config)# no logging enable user-login
BigIron RX(config)# write memory
BigIron RX(config)# end
November 2005 © 2005 Foundry Networks, Inc.
4-5
Foundry BigIron RX Series Configuration Guide
BigIron RX# reload
Syntax: [no] logging enable user-login
Refer to the MIB Guide for a list of traps.
Configuring an Interface as the Source for All Telnet Packets
You can designate the lowest-numbered IP address configured an interface as the source IP address for all Telnet packets from the BigIron RX. Identifying a single source IP address for Telnet packets provides the following benefits:
• If your Telnet server is configured to accept packets only from specific links or IP addresses, you can simplify configuration of the Telnet server by configuring the BigIron RX to always send the Telnet packets from the same link or source address.
• If you specify a loopback interface as the single source for Telnet packets, Telnet servers can receive the packets regardless of the states of individual links. Thus, if a link to the Telnet server becomes unavailable but the client or server can be reached through another link, the client or server still receives the packets, and the packets still have the source IP address of the loopback interface.
The software contains separate CLI commands for specifying the source interface for Telnet, TACACS/TACACS+, and RADIUS packets. You can configure a source interface for one or more of these types of packets.
The software uses the lowest-numbered IP address configured on the interface as the source IP address for
Telnet packets originated by the BigIron RX.
To specify the lowest-numbered IP address configured on a virtual routing interface as the device’s source for all
Telnet packets, enter commands such as the following:
BigIron RX(config)# int loopback 2
BigIron RX(config-lbif-2)# ip address 10.0.0.2/24
BigIron RX(config-lbif-2)# exit
BigIron RX(config)# ip telnet source-interface loopback 2
The commands configure loopback interface 2, assign IP address 10.0.0.2/24 to it, then designate it as the source for all Telnet packets from the BigIron RX.
Syntax: ip telnet source-interface ethernet <portnum> | loopback <num> | ve <num>
The following commands configure an IP interface on an Ethernet port and designate the address port as the source for all Telnet packets from the BigIron RX.
BigIron RX(config)# interface ethernet 1/4
BigIron RX(config-if-e10000-1/4)# ip address 209.157.22.110/24
BigIron RX(config-if-e10000-1/4)# exit
BigIron RX(config)# ip telnet source-interface ethernet 1/4
Cancelling an Outbound Telnet Session
If you want to cancel a Telnet session from the console to a remote Telnet server (for example, if the connection is frozen), you can terminate the Telnet session by doing the following:
1.
At the console, press Ctrl-^ (Ctrl-Shift-6).
2.
Press the X key to terminate the Telnet session.
Pressing Ctrl-^ twice in a row causes a single Ctrl-^ character to be sent to the Telnet server. After you press
Ctrl-^, pressing any key other than X or Ctrl-^ returns you to the Telnet session.
Configuring an Interface as the Source for All TFTP Packets
You can configure the BigIron RX to use the lowest-numbered IP address configured on a loopback interface, virtual routing interface, or Ethernet port as the source for all TFTP packets it sends. The software uses the lowest-numbered IP address configured on the interface as the source IP address for the packets.
4-6 © 2005 Foundry Networks, Inc.
November 2005
Configuring Basic Parameters
For example, to specify the lowest-numbered IP address configured on a virtual routing interface as the BigIron
RX’s source for all TFTP packets, enter commands such as the following:
BigIron RX(config)# int ve 1
BigIron RX(config-vif-1)# ip address 10.0.0.3/24
BigIron RX(config-vif-1)# exit
BigIron RX(config)# ip tftp source-interface ve 1
The commands configure virtual routing interface 1, assign IP address 10.0.0.3/24 to it, then designate the address as the source address for all TFTP packets.
Syntax: [no] ip tftp source-interface ethernet <portnum> | loopback <num> | ve <num>
The default is the lowest-numbered IP address configured on the port through which the packet is sent. The address therefore changes, by default, depending on the port.
Specifying a Simple Network Time Protocol (SNTP) Server
You can configure the BigIron RX to consult SNTP servers for the current system time and date.
NOTE:
The BigIron RX does not retain time and date information across power cycles. Unless you want to reconfigure the system time counter each time the system is reset, Foundry Networks recommends that you use the SNTP feature.
To identify an SNTP server with IP address 208.99.8.95 to act as the clock reference for a BigIron RX, enter the following:
BigIron RX(config)# sntp server 208.99.8.95
Syntax: sntp server <ip-addr> | <hostname> [<version>]
The <version> parameter specifies the SNTP version the server is running and can be from 1 – 4. The default is 1. You can configure up to three SNTP servers by entering three separate sntp server commands.
By default, the BigIron RX polls its SNTP server every 30 minutes (1800 seconds). To configure the BigIron RX to poll for clock updates from a SNTP server every 15 minutes, enter the following:
BigIron RX(config)# sntp poll-interval 900
Syntax: [no] sntp poll-interval <1-65535>
To display information about SNTP associations, enter the following command:
BigIron RX# show sntp associations
address ref clock st when poll delay disp
~207.95.6.102 0.0.0.0 16 202 4 0.0 5.45
~207.95.6.101 0.0.0.0 16 202 0 0.0 0.0
* synced, ~ configured
Syntax: show sntp associations
November 2005 © 2005 Foundry Networks, Inc.
4-7
Foundry BigIron RX Series Configuration Guide
The following table describes the information displayed by the show sntp associations command.
address ref clock st when poll delay disp
This Field...
(leading character)
Table 4.1: Output from the show sntp associations command
Displays...
One or both of the following:
* Synchronized to this peer
~ Peer is statically configured
IP address of the peer
IP address of the peer’s reference clock
NTP stratum level of the peer
Amount of time since the last NTP packet was received from the peer
Poll interval in seconds
Round trip delay in milliseconds
Dispersion in seconds
To display information about SNTP status, enter the following command:
BigIron RX# show sntp status
Clock is unsynchronized, stratum = 0, no reference clock precision is 2**0 reference time is 0 .0
clock offset is 0.0 msec, root delay is 0.0 msec root dispersion is 0.0 msec, peer dispersion is 0.0 msec
Syntax: show sntp status
The following table describes the information displayed by the show sntp status command.
This Field...
unsynchronized synchronized stratum reference clock precision reference time clock offset root delay root dispersion
Table 4.2: Output from the show sntp status command
Indicates...
System is not synchronized to an NTP peer.
System is synchronized to an NTP peer.
NTP stratum level of this system
IP Address of the peer (if any) to which the unit is synchronized
Precision of this system's clock (in Hz)
Reference time stamp
Offset of clock to synchronized peer
Total delay along the path to the root clock
Dispersion of the root path
4-8 © 2005 Foundry Networks, Inc.
November 2005
Configuring Basic Parameters
This Field...
peer dispersion
Table 4.2: Output from the show sntp status command (Continued)
Indicates...
Dispersion of the synchronized peer
Setting the System Clock
In addition to SNTP support, the BigIron RX also allows you to set the system time counter. It starts the system time and date clock with the time and date you specify. The time counter setting is not retained across power cycles and is not automatically synchronized with an SNTP server.
NOTE:
To synchronize the time counter with your SNTP server time, enter the sntp sync command from the
Privileged EXEC level of the CLI.
NOTE:
Unless you identify an SNTP server for the system time and date, you will need to re-enter the time and date following each reboot.
To set the system time and date to 10:15:05 on October 15, 2005, enter the following command:
BigIron RX# clock set 10:15:05 10-15-05
Syntax: [no] clock set <hh:mm:ss> <mm-dd-yy> | <mm-dd-yyyy>
By default, the BigIron RX does not change the system time for daylight savings time. To enable daylight savings time, enter the following command:
BigIron RX# clock summer-time
Syntax: clock summer-time
Although SNTP servers typically deliver the time and date in Greenwich Mean Time (GMT), you can configure the
BigIron RX to adjust the time for any one-hour offset from GMT or for one of the following U.S. time zones:
• US Pacific (default)
• Alaska
• Aleutian
• Arizona
• Central
• East-Indiana
• Eastern
• Hawaii
• Michigan
• Mountain
• Pacific
• Samoa
The default is US Pacific.
To change the time zone to Australian East Coast time (which is normally 10 hours ahead of GMT), enter the following command:
BigIron RX(config)# clock timezone gmt gmt+10
Syntax: clock timezone gmt gmt | us <time-zone>
November 2005 © 2005 Foundry Networks, Inc.
4-9
Foundry BigIron RX Series Configuration Guide
You can enter one of the following values for <time-zone>:
• US time zones (us): alaska, aleutian, arizona, central, east-indiana, eastern, hawaii, michigan, mountain, pacific, samoa.
• GMT time zones (gmt): gmt+12, gmt+11, gmt+10...gmt+01, gmt+00, gmt-01...gmt-10, gmt-11, gmt-12.
Limiting Broadcast, Multicast, or Unknown-Unicast Rates
The BigIron RX can forward all traffic at wire speed. However, some third-party networking devices cannot handle high forwarding rates for broadcast, multicast, or unknown-unicast packets.
The limits are individually configurable for broadcasts, multicasts, and unknown-unicasts. You can configure limits globally and on individual ports. The valid range is 1 – 4294967295 packets per second. The default is 0, which disables limiting.
NOTE:
By default, IP Multicast (including IGMP) is disabled. You can enable it using the ip multicast passive |
active command. As long as IP Multicast is enabled (regardless of whether it is passive or active), no IP Multicast
Limiting Broadcasts
To globally limit the number of broadcast packets a BigIron RX forwards to 100,000 per second, enter the following command at the global CONFIG level of the CLI:
BigIron RX(config)# broadcast limit 100000
BigIron RX(config)# write memory
To limit the number of broadcast packets sent on port 1/3 to 80,000, enter the following commands:
BigIron RX(config)# int ethernet 1/3
BigIron RX(config-if-e10000-1/3)# broadcast limit 80000
BigIron RX(config-if-e10000-1/3)# write memory
Syntax: broadcast limit <number>
Limiting Multicasts
To globally limit the number of multicast packets a BigIron RX forwards to 120,000 per second, enter the following command at the global CONFIG level of the CLI:
BigIron RX(config)# multicast limit 120000
BigIron RX(config)# write memory
To limit the number of multicast packets sent on port 3/6 to 55,000, enter the following commands:
BigIron RX(config)# int ethernet 3/6
BigIron RX(config-if-e10000-3/6)# multicast limit 55000
BigIron RX(config-if-e10000-3/6)# write memory
Syntax: multicast limit <number>
NOTE:
The multicast limit is configured at the global level, but the value you enter applies to each management module (slot) installed on the device.
Limiting Unknown Unicasts
To globally limit the number of unknown unicast packets a BigIron RX forwards to 110,000 per second, enter the following command at the global CONFIG level of the CLI:
BigIron RX(config)# unknown-unicast limit 110000
BigIron RX(config)# write memory
4-10 © 2005 Foundry Networks, Inc.
November 2005
Configuring Basic Parameters
To limit the number of unknown unicast packets sent on port 4/2 to 40,000, enter the following commands:
BigIron RX(config)# int ethernet 4/2
BigIron RX(config-if-e10000-4/2)# unknown-unicast limit 40000
BigIron RX(config-if-e10000-4/2)# write memory
Syntax: unknown-unicast limit <number>
NOTE:
Only the unknown-unicast limit is configured on the global level, but the value you enter applies to each management module (slot) installed on the device.
Configuring CLI Banners
The BigIron RX can be configured to display a greeting message on users’ terminals when they enter the
Privileged EXEC CLI level or access the device through Telnet. In addition, a BigIron RX can display a message on the Console when an incoming Telnet CLI session is detected.
Setting a Message of the Day Banner
You can configure the BigIron RX to display a message on a user’s terminal when he or she establishes a Telnet
CLI session. For example, to display the message “Welcome to BigIron!” when a Telnet CLI session is established:
BigIron RX(config)# banner motd $
(Press Return)
Enter TEXT message, End with the character '$'.
Welcome to BigIron!! $
A delimiting character is established on the first line of the banner motd command. You begin and end the message with this delimiting character. The delimiting character can be any character except “ (double-quotation mark) and cannot appear in the banner text. In this example, the delimiting character is $ (dollar sign). The text in between the dollar signs is the contents of the banner. The banner text can be up to 2048 characters long and can consist of multiple lines. To remove the banner, enter the no banner motd command.
Syntax: [no] banner <delimiting-character> | [motd <delimiting-character>]
NOTE:
The banner <delimiting-character> command is equivalent to the banner motd <delimiting-character> command.
When you access the Web management interface, the banner is displayed:
November 2005 © 2005 Foundry Networks, Inc.
4-11
Foundry BigIron RX Series Configuration Guide
Setting a Privileged EXEC CLI Level Banner
You can configure the BigIron RX to display a message when a user enters the Privileged EXEC CLI level. For example:
BigIron RX(config)# banner exec_mode #
(Press Return)
Enter TEXT message, End with the character '#'.
You are entering Privileged EXEC level
Don’t foul anything up! #
As with the banner motd command, you begin and end the message with a delimiting character; in this example, the delimiting character is # (pound sign). To remove the banner, enter the no banner exec_mode command.
Syntax: [no] banner exec_mode <delimiting-character>
Displaying a Message on the Console When an Incoming Telnet Session Is
Detected
You can configure the BigIron RX to display a message on the Console when a user establishes a Telnet session.
This message indicates where the user is connecting from and displays a configurable text message.
For example:
BigIron RX(config)# banner incoming $
(Press Return)
Enter TEXT message, End with the character '$'.
Incoming Telnet Session!! $
When a user connects to the CLI using Telnet, the following message appears on the Console:
Telnet from 209.157.22.63
Incoming Telnet Session!!
Syntax: [no] banner incoming <delimiting-character>
To remove the banner, enter the no banner incoming command.
Configuring Terminal Display
You can configure and display the number of lines displayed on a terminal screen during the current CLI session.
The terminal length command allows you to determine how many lines will be displayed on the screen during the current CLI session. This command is useful when reading multiple lines of displayed information, especially those that do not fit on one screen.
To specify the maximum number of lines displayed on one page, enter a command such as the following:
BigIron RX(config)# terminal length 15
Syntax: terminal length <number-of-lines>
The <number-of-lines> parameter indicates the maximum number of lines that will be displayed on a full screen of text during the current session. If the displayed information requires more than one page, the terminal pauses.
Pressing the space bar displays the next page.
The default for <number-of-lines> is 24. Entering a value of 0 prevents the terminal from pausing between multiple output pages:
Checking the Length of Terminal Displays
The show terminal command specifies the number of lines that will be displayed on the screen as specified by the terminal length, page display, and skip-page-display commands. It also shows if the enable skip-page-
display command has been configured. The enable skip-page-display command allows you to use the skippage-display to disable the configured page-display settings.
BigIron RX(config)# show terminal
Length: 24 lines
4-12 © 2005 Foundry Networks, Inc.
November 2005
Configuring Basic Parameters
Page display mode (session): enabled
Page display mode (global): enabled
Syntax: show terminal
Enabling or Disabling Routing Protocols
The BigIron RX supports the following protocols:
• BGP4
• DVMRP
• FSRP
• IP
• OSPF
• PIM
• RIP
• VRRP
• VRRPE
By default, IP routing is enabled on the BigIron RX. All other protocols are disabled, so you must enable them to configure and use them.
NOTE:
The following protocols require a system reset before the protocol will be active on the system: PIM,
DVMRP, RIP, FSRP. To reset a system, enter the reload command at the privileged level of the CLI.
To enable a protocol on a BigIron RX, enter router at the global CONFIG level, followed by the protocol to be enabled. The following example shows how to enable OSPF:
BigIron RX(config)# router ospf
BigIron RX(config)# end
BigIron RX# write memory
BigIron RX# reload
Syntax: router bgp | dvmrp | fsrp | ospf | pim | rip | vrrp | vrrpe
Displaying and Modifying System Parameter Default Settings
The BigIron RX has default table sizes for the following parameters. The table sizes determine the maximum number of entries the tables can hold. You can adjust individual table sizes to accommodate your configuration needs.
• MAC address entries
• Layer 2 Port VLANs supported on a system
• Layer 3 Protocol VLANs supported on a system
• Layer 4 sessions supported
• IP cache size
• ARP entries
• IP routes
• IP route filters
• IP subnets per port and per device
November 2005 © 2005 Foundry Networks, Inc.
4-13
Foundry BigIron RX Series Configuration Guide
• Static routes
The tables you can configure as well the defaults and valid ranges for each table differ depending on the BigIron
RX you are configuring.
NOTE:
If you increase the number of subnet addresses you can configure on each port to a higher amount, you might also need to increase the total number of subnets that you can configure on the device.
NOTE:
Changing the table size for a parameter reconfigures the device’s memory. Whenever you reconfigure the memory on a BigIron RX, you must save the change to the startup configuration file, then reload the software to place the change into effect.
4-14 © 2005 Foundry Networks, Inc.
November 2005
Configuring Basic Parameters
To display the configurable tables, their defaults and maximum values, enter the following command at any level of the CLI:
BigIron RX# show default values telnet@ro(config)#show default values sys log buffers:50 mac age time:300 sec telnet sessions:5 ip arp age:10 min bootp relay max hops:4 ip ttl:64 hops ip addr per intf:24 when multicast enabled : igmp group memb.:140 sec igmp query:60 sec when ospf enabled : ospf dead:40 sec ospf hello:10 sec ospf retrans:5 sec ospf transit delay:1 sec when bgp enabled : bgp local pref.:100 bgp keep alive:60 sec bgp hold:180 sec bgp metric:10 bgp local as:1 bgp cluster id:0 bgp ext. distance:20 bgp int. distance:200 bgp local distance:200 when IS-IS enabled : isis hello interval:10 sec isis hello multiplier:3 isis port metric:10 isis priority:64 isis csnp-interval:10 sec isis default-metric:10 isis distance:115 isis lsp-gen-interval:10 sec isis lsp-interval:33 msec isis lsp-refresh-interval:900 sec isis max-lsp-lifetime:1200 sec isis maximum-paths:4 isis retransmit-interval:5 sec isis spf-interval:5 sec
System Parameters Default Maximum Current mac 32768 65536 32768 vlan 512 4095 512 spanning-tree 32 128 32 rstp 32 128 32 ip-arp 8192 65536 8192 ip-static-arp 2048 4096 2048 multicast-route 8192 153600 8192 dvmrp-route 2048 16384 2048 dvmrp-mcache 4096 4096 4096 pim-mcache 4096 4096 4096 igmp-max-group-addr 1024 4096 1024 ip-cache 204800 524288 524288 ip-route 204800 524288 524288 ip-subnet-port 24 128 24 virtual-interface 255 4095 255 session-limit 32768 163840 32768 ip-filter-sys 4096 4096 4096 mgmt-port-acl-size 20 100 20 l2-acl-table-entries 64 256 64 vlan-multicast-flood 0 4095 0
Syntax: show default values
November 2005 © 2005 Foundry Networks, Inc.
4-15
Foundry BigIron RX Series Configuration Guide
Information for the configurable tables appears under the columns shown in bold type. To simplify configuration, the command parameter you enter to configure the table is used for the table name. For example, to increase the capacity of the IP route table, enter the following commands:
BigIron RX(config)# system-max ip-route 120000
BigIron RX(config)# write memory
BigIron RX(config)# exit
BigIron RX# reload
NOTE:
If you enter a value that is not within the valid range of values, the CLI will display the valid range for you.
To increase the number of IP subnet interfaces you can configure on each port on a BigIron RX from 24 to 64, then increase the total number of IP interfaces you can configure from 256 to 512, enter the following commands:
BigIron RX(config)# system-max subnet-per-interface 64
BigIron RX(config)# write memory
BigIron RX(config)# exit
BigIron RX# reload
Syntax: system-max subnet-per-interface <num>
The <num> parameter specifies the maximum number of subnet addresses per port and can be from 1 – 64. The default is 24.
Syntax: system-max subnet-per-system <num>
The <num> parameter specifies the maximum number of subnet addresses for the entire device and can be from
1 – 512. The default is 256.
BigIron RX(config)# system-max subnet-per-system 512
BigIron RX(config)# write memory
BigIron RX(config)# exit
BigIron RX# reload
To increase the size of the IP route table for static routes, enter the following command:
NetIron(config)# system-max ip-static-route 8192
Syntax: system-max ip-static-route <num>
The maximum number of static routes you can define is 4096.
NOTE:
You must reload the software for the change to take effect.
Enabling or Disabling Layer 2 Switching
By default, Foundry BigIron RX supports Layer 2 switching and switches the routing protocols that are not supported. You can disable Layer 2 switching globally or on individual ports.
NOTE:
Make sure you really want to disable all Layer 2 switching operations before actually disabling it. Consult your reseller or Foundry Networks for information.
To globally disable Layer 2 switching on the BigIron RX, enter commands such as the following:
BigIron RX(config)# route-only
BigIron RX(config)# exit
BigIron RX# write memory
BigIron RX# reload
4-16 © 2005 Foundry Networks, Inc.
November 2005
Configuring Basic Parameters
To re-enable Layer 2 switching globally, enter the following:
BigIron RX(config)# no route-only
BigIron RX(config)# exit
BigIron RX# write memory
BigIron RX# reload
Syntax: [no] route-only
To disable Layer 2 switching only on a specific interface, go to the Interface configuration level for that interface, then disable the feature. The following commands show how to disable Layer 2 switching on port 3/2:
BigIron RX(config)# interface ethernet 3/2
BigIron RX(config-if-e10000-3/2)# route-only
Syntax: [no] route-only
To re-enable Layer 2 switching, enter the command with “no”:
BigIron RX(config-if-e10000-3/2)# no route-only
Changing the MAC Age Time
The MAC age time sets the aging period for ports on the device, defining how long (how many seconds) a port address remains active in the address table.
To change the aging period for MAC addresses from the default of 300 seconds to 600 seconds:
BigIron RX(config)# mac-age-time 600
Syntax: [no] mac-age-time <age-time>
The <age-time> can be 0 or a number from 67 – 65535. The zero results in no address aging. The default is 300
(seconds).
Configuring Static MAC Addresses
You can assign static MAC addresses to the BigIron RX.
NOTE:
The BigIron RX also supports the assignment of static IP Routes, and static ARP entries. For details on configuring these types of static entries, see the “Configuring Static Routes” and “Creating Static ARP Entries” sections in the “Configuring IP” chapter.
You can manually input the MAC address of a device to prevent it from being aged out of the system address table, to prevent traffic for a specific device, such as a server, from flooding the network with traffic when it is down, and to assign higher priorities to specific MAC addresses.
You can specify port priority (QoS) and VLAN membership (VLAN ID) for the MAC Address as well as specify device type of either router or host.
The default and maximum configurable MAC table sizes can differ depending on the device. To determine the
Modifying System Parameter Default Settings” on page 4-13.
The BigIron RX can have up to 16,000 static and dynamic MAC address entries stored in the CAM. The ability of the CAM to store depends on the following:
• The number of source MAC address being learned by the CAM.
• The number of destination MAC addresses being forwarded by the CAM
• The distribution of the MAC address entries across ports. For example, it one port is learning all the source
MAC addresses, the available of the CAM for that port will be depleted.
Also, a large number of MAC address entries in the MAC table could increase CPU utilization. To alleviate the load on the CPU, use this feature with the Control Plane Security option.
November 2005 © 2005 Foundry Networks, Inc.
4-17
Foundry BigIron RX Series Configuration Guide
EXAMPLE:
To add a static entry for a server with a MAC address of 1145.5563.67FF and a priority of 7 to port 2 of module 1 of a BigIron RX:
BigIron RX(config)# static-mac-address 1145.5563.67FF e 1/2 priority 7
Syntax: [no] static-mac-address <mac-addr> ethernet <portnum> [to <portnum> ethernet <portnum>]
[priority <number>] [host-type | router-type | fixed-host]
The priority can be 0 – 7. The default priority is 0 or normal-priority.
The default type is host-type.
NOTE:
The location of the static-mac-address command in the CLI depends on whether you configure portbased VLANs on the device. If the device does not have more than one port-based VLAN (VLAN 1, which is the default VLAN that contains all the ports), the static-mac-address command is at the global CONFIG level of the
CLI. If the device has more than one port-based VLAN, then the static-mac-address command is not available at the global CONFIG level. In this case, the command is available at the configuration level for each port-based
VLAN.
Configuring Static ARP Entries
When you create a static ARP entry, the BigIron RX automatically creates a static MAC entry.
NOTE:
To delete the static MAC entry, you must delete the static ARP entry first.
4-18 © 2005 Foundry Networks, Inc.
November 2005
Chapter 5
Configuring Interface Parameters
This chapter describes how to configure the following interface parameters:
•
Name – see “Assigning a Port Name” on page 5-2
•
IP address – see “Assigning an IP Address to a Port” on page 5-2
•
Speed – see “Modifying Port Speed” on page 5-2
•
Mode (half-duplex or full-duplex) – see “Modifying Port Mode” on page 5-3
•
Status – see “Disabling or Re-Enabling a Port” on page 5-3
•
Flow control – see “Disabling or Re-Enabling Flow Control” on page 5-5
•
Gigabit negotiate mode – see “Changing the 802.3x Gigabit Negotiation Mode” on page 5-3
•
QoS priority – see “Modifying Port Priority (QoS)” on page 5-6
•
“Locking a Port to Restrict Addresses” on page 5-5
•
“Assigning a Mirror Port and Monitor Ports” on page 5-6
•
“Monitoring an Individual Trunk Port” on page 5-7
•
“Monitoring 802.3ad Aggregate Links” on page 5-8
•
“Mirror Ports for Policy-Based Routing (PBR) Traffic” on page 5-9
•
“Displaying Mirror and Monitor Port Configuration” on page 5-10
•
“Enabling WAN PHY Mode Support” on page 5-11
Other interface parameters are discussed in the remaining chapters of this manual.
NOTE:
To modify Layer 2, Layer 3, or Layer 4 features on a port, see the appropriate section in this chapter or
Port Parameters” on page 10-4.
To configure trunk groups or dynamic link aggregation, see “Configuring Trunk Groups” on page 6-1.
All BigIron RX ports are pre-configured with default values that allow the device to be fully operational at initial startup without any additional configuration. However, in some cases, changes to the port parameters may be necessary to adjust to attached devices or other network requirements.
November 2005 © 2005 Foundry Networks, Inc.
5-1
Foundry BigIron RX Series Configuration Guide
Assigning a Port Name
A port name can be assigned to help identify interfaces on the network. You can assign a port name to physical ports, virtual routing interfaces, and loopback interfaces.
To assign a name to a port:
BigIron RX(config)# interface e 2/8
BigIron RX(config-if-e10000-2/8)# port-name Marsha Markey
Syntax: port-name <text>
The <text> parameter is an alphanumeric string. The name can be up to 255 characters long on the BigIron RX.
The name can contain blanks. You do not need to use quotation marks around the string, even when it contains blanks.
Assigning an IP Address to a Port
To assign an IP address to an interface, enter the following commands:
BigIron RX(config)# interface e 1/8
BigIron RX(config)# ip address 192.45.6.110 255.255.255.0
Syntax: ip address <ip-addr> <ip-mask> or
Syntax: ip address <ip-addr>/<mask-bits>
NOTE:
You also can enter the IP address and mask in CIDR format, as follows:
BigIron RX(config)# ip address 192.45.6.1/24
Modifying Port Speed
Each of the 10/100/1000BaseTX ports is designed to auto-sense and auto-negotiate the speed and mode of the connected device. If the attached device does not support this operation, you can manually enter the port speed to operate at either 10 Mbps or 100 Mbps. The default value is 10 or 100 half- or full-duplex.
NOTE:
Modifying the port speed of a port that has a pre-configured rate limit policy may result in the inability to remove the port's rate limit policy.
To change the port speed of interface 1/8 from the default of 10/100 auto-sense to 10 Mbps operating at fullduplex, enter the following:
BigIron RX(config)# interface e 1/8
BigIron RX(config-if-e10000-1/8)# speed-duplex 10-full
Syntax: speed-duplex <value>
The <value> can be one of the following:
• 10-full
• 10-half
• 100-full
• 100-half
• 1000-full
• 1000-half
5-2 © 2005 Foundry Networks, Inc.
November 2005
Configuring Interface Parameters
• auto
The default is auto.
Modifying Port Mode
You can configure a port to accept either full-duplex (bi-directional) or half-duplex (uni-directional) traffic. Port duplex mode and port speed are modified by the same command.
To change the port speed of interface 1/8 from the default of 10/100 auto-sense to 10 Mbps operating at fullduplex, enter the following:
BigIron RX
(config)# interface e 1/8
BigIron RX(config-if-e10000-1/8)# speed-duplex 10-full
Syntax: speed-duplex <value>
The <value> can be one of the following:
• 10-full
• 10-half
• 100-full
• 100-half
• 1000-full
• 1000-half
• auto
The default is auto.
Disabling or Re-Enabling a Port
The port can be made inactive (disable) or active (enable) by selecting the appropriate status option. The default value for a port is enabled.
To disable port 8 on module 1 of a BigIron RX, enter the following:
BigIron RX(config)# interface e 1/8
BigIron RX(config-if-e10000-1/8)# disable
Syntax: disable
Syntax: enable
You also can disable or re-enable a virtual routing interface. To do so, enter commands such as the following:
BigIron RX(config)# interface ve v1
BigIron RX(config-vif-1)# disable
Syntax: disable
To re-enable a virtual routing interface, enter the enable command at the Interface configuration level. For example, to re-enable virtual routing interface v1, enter the following command:
BigIron RX(config-vif-1)# enable
Syntax: enable
Changing the 802.3x Gigabit Negotiation Mode
The globally configured Gigabit negotiation mode for 802.3x flow control is the default mode for all Gigabit ports.
You can override the globally configured default and set individual ports to the following:
November 2005 © 2005 Foundry Networks, Inc.
5-3
Foundry BigIron RX Series Configuration Guide
• Negotiate-full-auto – The port first tries to perform a handshake with the other port to exchange capability information. If the other port does not respond to the handshake attempt, the port uses the manually configured configuration information (or the defaults if an administrator has not set the information). This is the default.
• Auto-Gigabit – The port tries to perform a handshake with the other port to exchange capability information.
• Negotiation-off – The port does not try to perform a handshake. Instead, the port uses configuration information manually configured by an administrator.
To change the mode for individual ports, enter commands such as the following:
BigIron RX(config)# int ethernet 4/1 to 4/4
BigIron RX(config-mif-4/1-4/4)# gig-default auto-gig
This command overrides the global setting and sets the negotiation mode to auto-Gigabit for ports 4/1 – 4/4.
Syntax: gig-default neg-full-auto | auto-gig | neg-off
Changing the Default Gigabit Negotiation Mode
You can configure the default Gigabit negotiation mode to be one of the following:
• Negotiate-full-auto – The port first tries to perform a handshake with the other port to exchange capability information. If the other port does not respond to the handshake attempt, the port uses the manually configured configuration information (or the defaults if an administrator has not set the information). This is the default for Chassis devices.
• Auto-Gigabit – The port tries to perform a handshake with the other port to exchange capability information.
• Negotiation-off – The port does not try to perform a handshake. Instead, the port uses configuration information manually configured by an administrator.
Although the standard for 100BaseTX ports provides an option for a negotiating port to link with a non-negotiating port, the 802.3x standard for Gigabit ports does not provide this option. As a result, unless the ports at both ends of a Gigabit Ethernet link use the same mode (either auto-Gigabit or negotiation-off), the ports cannot establish a link. An administrator must intervene to manually configure one or both sides of the link to enable the ports to establish the link.
BigIron RX software provides a solution by changing the default negotiation behavior for Gigabit Ethernet ports on the BigIron RX. The new default behavior allows a port to establish a link with another port whether the other port is configured for auto-Gigabit or negotiation-off. By default, Gigabit Ethernet ports first attempt auto-Gigabit. If auto-Gigabit does not succeed (typically because the port at the other end is not configured for auto-Gigabit), the port switches to negotiation-off.
Changing the Negotiation Mode
You can change the negotiation mode globally and for individual ports.
To change the mode globally, enter a command such as the following:
BigIron RX(config)# gig-default neg-off
This command changes the global setting to negotiation-off. The global setting applies to all Gigabit Ethernet ports except those for which you set a different negotiation mode on the port level.
To change the mode for individual ports, enter commands such as the following:
BigIron RX(config)# int ethernet 4/1 to 4/4
BigIron RX(config-mif-4/1-4/4)# gig-default auto-gig
This command overrides the global setting and sets the negotiation mode to auto-Gigabit for ports 4/1 – 4/4.
Here is the syntax for globally changing the negotiation mode.
Syntax: gig-default neg-full-auto | auto-gig | neg-off
Here is the syntax for changing the negotiation mode on individual ports.
5-4 © 2005 Foundry Networks, Inc.
November 2005
Configuring Interface Parameters gig-default neg-full-auto | auto-gig | neg-off
Disabling or Re-Enabling Flow Control
You can configure full-duplex ports on a system to operate with or without flow control (802.3x). Flow control is enabled by default.
To disable flow control on full-duplex ports on a system, enter the following:
BigIron RX(config)# no flow-control
To turn the feature back on:
BigIron RX(config)# flow-control
Syntax: [no] flow-control
Specifying Threshold Values for Flow Control
The 802.3x flow control specification provides a method for slowing traffic from a sender when a port is receiving more traffic than it can handle. Specifically, the receiving device can send out 802.3x PAUSE frames that request that the sender stop sending traffic for a period of time.
The BigIron RX generates 802.3x PAUSE frames when the number of buffers available to a module's Buffer
Manager (BM) drops below a threshold value. A module's BM can start running out of buffers when a port receives more traffic than it can handle. In addition, the device drops the lowest priority traffic when the number of available buffers drops below a second threshold. When the number of available buffers returns to a higher level, the device sends out another PAUSE frame that tells the sender to resume sending traffic normally. You can specify values for both thresholds, as well as the module where the thresholds are to take effect.
NOTE:
To use this feature, 802.3x flow control must be enabled globally on the device. By default, 802.3x flow control is enabled on the BigIron RX, but can be disabled with the no flow-control command.
To specify threshold values for flow control, enter the following command:
BigIron RX(config)# qd-flow sink 75 sunk 50 slot 1
Syntax: qd-flow sink <sinking-threshold> sunk <sunk-threshold> slot <slot>
The threshold values are percentages of the total number of buffers available to a module's Buffer Manager.
When the <sinking-threshold> is reached, the BigIron RX sends out 802.3x PAUSE frames telling the sender to stop sending traffic for a period of time.
When the <sunk-threshold> is reached, the BigIron RX drops traffic at the specified priority level.
The <slot> parameter specifies the location of the module where the thresholds are to take effect.
Locking a Port to Restrict Addresses
Address-lock filters allow you to limit the number of devices that have access to a specific port. Access violations are reported as SNMP traps. By default this feature is disabled. A maximum of 2048 entries can be specified for access. The default address count is eight.
EXAMPLE:
To enable address locking for port 2/1 and place a limit of 15 entries:
BigIron RX(config)# lock e 2/1 addr 15
Syntax: lock-address ethernet <portnum> [addr-count <num>]
November 2005 © 2005 Foundry Networks, Inc.
5-5
Foundry BigIron RX Series Configuration Guide
Modifying Port Priority (QoS)
You can give preference to the inbound traffic on specific ports by changing the Quality of Service (QoS) level on
those ports. For information and procedures, see “Configuring Quality of Service” on page 16-1.
Assigning a Mirror Port and Monitor Ports
You can monitor traffic on Foundry ports by configuring another port to “mirror” the traffic on the ports you want to monitor. By attaching a protocol analyzer to the mirror port, you can observe the traffic on the monitored ports.
Monitoring traffic on a port is a two-step process:
• Enable a port to act as the mirror port. This is the port to which you connect your protocol analyzer.
• Enable monitoring on the ports you want to monitor.
You can monitor input traffic, output traffic, or both.
On a 4 X 10G module, any port can operate as a mirror port and you can configure more than one mirror port. You can configure up to 64 mirror ports. You can configure the mirror ports on different modules and you can configure more than one mirror port on the same module.
Each mirror port can have its own set of monitored ports. For example, you can configure ports 1/1 and 5/1 as mirror ports, and monitor ports 1/2 – 1/8 on port 1/1 and ports 5/2 – 5/8 on port 5/1. The mirror port and monitored ports also can be on different slots.
However, on a 24 X 1G module, you can configure only one mirror port per packet processor (PPCR). For example, if you configure port 3/1 to be mirrored by port 5/1, all other ports that you want to be mirrored must use
5/1 as the mirror port. The following table shows which ports share the same PPCR:
5-6
PPCR
1
2
Port Numbers
1 – 12
13 – 24
Configuration Guidelines for Monitoring Traffic
Use the following considerations when configuring mirroring for inbound and outbound traffic:
• Any port can be mirrored and monitored except for the management port.
• There can be only one mirror port per packet processor on a 24 X 1G module.
• For outbound traffic, there can be up to 8 active mirror ports system wide.
• A port that has sFlow enabled cannot be enable for port monitoring; however, that port can be configured as a mirror port.
Configuring Port Mirroring and Monitoring
You can configure multiple mirror ports on the same module. However, if you mirror inbound traffic to any of the mirror ports on the module, the traffic is mirrored to all the mirror ports on the module. If you plan to mirror outbound traffic only, you can use multiple mirror ports on the same module without the traffic being duplicated on the other mirror ports on the module.
NOTE:
You cannot monitor outbound traffic from one armed router traffic.
The following example configures two mirror ports on the same module and one mirror port on another module. It will illustrate how inbound traffic is mirrored to the two mirror ports on the same module even if the traffic is configured to be mirrored to only one mirror port on the module.
© 2005 Foundry Networks, Inc.
November 2005
Configuring Interface Parameters
BigIron RX(config)# mirror-port ethernet 1/1
BigIron RX(config)# mirror-port ethernet 1/2
BigIron RX(config)# mirror-port ethernet 2/1
BigIron RX(config)# interface ethernet 3/1
BigIron RX(config-if-e10000-3/1)# monitor ethernet 1/1 both
BigIron RX(config-if-e10000-3/1)# monitor ethernet 2/1 in
BigIron RX(config-if-e10000-3/1)# interface ethernet 4/13
BigIron RX(config-if-e10000-4/1)# monitor ethernet 1/2 both
This example configures two mirror ports 1/1 and 1/2 on the same module. It also configures input and output traffic from port 3/1 to be mirrored to mirror port 1/1 and input and output traffic from port 4/1 to be mirrored to mirror port 1/2. Because mirror ports 1/1 and 1/2 are configured on the same module, mirror port 1/1 will receive the input traffic from port 3/1 as well as port 4/1 and mirror port 1/2 will receive input traffic from port 4/1 as well as port 3/1 even if they are not explicitly configured to do so. The outbound traffic from port 3/1 is mirrored to port 1/1 only, as configured and the outbound traffic from port 4/1 is mirrored to port 1/2 only as configured.
This example also configures one mirror port 2/1 on another module, to which inbound traffic from port 3/1 is mirrored. Because only one mirror port is configured on this module, the traffic is mirrored as configured.
If input monitoring is enabled on two ports controlled by the same packet processor, then the input traffic on these two ports will be mirrored to all the ports configured as mirror ports for these two monitored ports. This restriction does not apply to outbound monitoring.
BigIron RX(config)# mirror-port ethernet 1/1
BigIron RX(config)# mirror-port ethernet 2/1
BigIron RX(config)# interface ethernet 3/1
BigIron RX(config-if-e1000-3/1)# monitor ethernet 1/1 both
BigIron RX(config-if-e1000-3/1)# interface ethernet 3/2
BigIron RX(config-if-e1000-3/2)# monitor ethernet 2/1 both
The above example configures two mirror ports 1/1 and 2/1 on different modules. Port 3/1 uses port 1/1 for inbound and outbound mirroring. Port 3/2 uses port 2/1 for inbound and outbound mirroring. If 3/1 and 3/2 are controlled by the same packet processor, inbound traffic from 3/1 will be mirrored to 1/1 as well as 2/1 and similarly, inbound traffic from 3/2 will be mirrored to 2/1 as well as 1/1. The outbound traffic on 3/1 and 3/2 are mirrored according to the configuration.
The syntax for the examples above are:
Syntax: mirror-port ethernet <slot>/<portnum>
Enter the slot and port number of the port that will be the mirrored.
Syntax: monitor ethernet <slot>/<portnum> both | input | output
The monitor command is available at the interface level. Enter the slot and port number of the port that will serve as the monitor port. This port cannot be the same as the mirror port.
Specify input if the port will monitor incoming traffic, output to monitor outgoing traffic, or both to monitor both types of traffic.
Monitoring an Individual Trunk Port
By default, when you monitor the primary port in a trunk group, aggregated traffic for all the ports in the trunk group is copied to the mirror port. You can configure the device to monitor individual ports in a trunk group. You can monitor the primary port or a secondary port individually.
NOTE:
You can use only one mirror port for each monitored trunk port.
To monitor traffic on an individual port in a trunk group, enter commands such as the following:
BigIron RX(config)# mirror ethernet 2/1
BigIron RX(config)# trunk switch ethernet 4/1 to 4/8
November 2005 © 2005 Foundry Networks, Inc.
5-7
Foundry BigIron RX Series Configuration Guide
BigIron RX(config-trunk-4/1-4/8)# config-trunk-ind
BigIron RX(config-trunk-4/1-4/8)# monitor ethe-port-monitored 4/5 ethernet 2/1 in
Syntax: [no] config-trunk-ind
Syntax: [no] monitor ethe-port-monitored <portnum> | named-port-monitored <portname> ethernet <slot>/<portnum> in | out | both
The config-trunk-ind command enables configuration of individual ports in the trunk group. You need to enter the
config-trunk-ind command only once in a trunk group. After you enter the command, all applicable port configuration commands apply to individual ports only.
NOTE:
If you enter no config-trunk-ind, all port configuration commands are removed from the individual ports and the configuration of the primary port is applied to all the ports. Also, once you enter the no config-trunk-ind command, the enable, disable, and monitor commands are valid only on the primary port and apply to the entire trunk group.
The monitor ethe-port-monitored command in this example enables monitoring of the inbound traffic on port
4/5.
• The ethe-port-monitored <portnum> | named-port-monitored <portname> parameter specifies the trunk port you want to monitor. Use ethe-port-monitored <portnum> to specify a port number. Use named-port-
monitored <portname> to specify a trunk port name.
• The ethernet <slot>/<portnum> parameter specifies the port to which the traffic analyzer is attached.
• The in | out | both parameter specifies the traffic direction to be monitored.
Monitoring 802.3ad Aggregate Links
You can monitor 802.3ad aggregate links, as well as individual ports within 802.3ad aggregate links.
This feature is supported on any port that can be configured with 802.3ad link aggregation.
NOTE:
The terms 802.3ad aggregate link and dynamic trunk group are used interchangeably in this section and mean the same thing.
Configuring Port Monitoring on 802.3ad Aggregate Links
By default, when you enable monitoring on the primary port of an 802.3ad aggregate link, the device copies the traffic for all the ports in the dynamic trunk group to the mirror port.
To monitor all of the ports in an 802.3ad aggregate link, enter commands such as the following on the primary port of the dynamic trunk group:
BigIron RX(config)# interface e1/1
BigIron RX(config-if-e100-1/1)# link-aggregate monitor ethernet-port-monitored e 1/
1 e 1/10 both
These commands enable monitoring of the entire dynamic trunk group and copy both incoming and outgoing traffic to port 1/10, the assigned mirror port. Note that the mirror port (in this case, port 1/10) must already be configured as a mirror port.
Syntax: link-aggregate monitor ethernet-port-monitored ethernet <monitor slot/port> <mirror slot/port> both | in | out
The <monitor slot/port> parameter specifies the port to monitor.
The <mirror slot/port> parameter specifies the port that will receive copies of the monitored port’s traffic.
The both | in | out parameter specifies the traffic direction to monitor. There is no default.
5-8 © 2005 Foundry Networks, Inc.
November 2005
Configuring Interface Parameters
Configuring Port Monitoring on an Individual Port in an 802.3ad Aggregate Link
To monitor traffic on an individual port in a dynamic trunk group, enter commands such as the following:
BigIron RX(config)#interface e1/1
BigIron RX(config-if-e100-1/1)# link-aggregate config-ind-monitor
BigIron RX(config-if-e100-1/1)# link-aggregate monitor ethernet-port-monitored ethernet 1/1 ethernet 1/10 in
Syntax: [no] link-aggregate config-ind-monitor
Syntax: link-aggregate monitor ethernet-port-monitored ethernet <monitor slot/port> <mirror slot/port> in | out | both
The link-aggregate config-ind-monitor command enables configuration of individual ports in the dynamic trunk group. Enter this command only once in a dynamic trunk group configuration. After you enter this command, all applicable port configuration commands apply to individual ports only.
NOTE:
If you enter no link-aggregate config-ind-monitor, the device removes all monitor configuration commands from the individual ports and applies the primary port’s configuration to all the ports. Also, once you enter the no link-aggregate config-ind-monitor command, any monitor configuration command you enter thereafter applies to the entire trunk group.
The link-aggregate monitor ethernet-port-monitored ethernet command in this example enables monitoring of inbound traffic on port 1/1.
• The <monitor slot/port> parameter specifies the port to monitor.
• The <mirror slot/port> parameter specifies the port that will receive copies of the monitored port’s traffic.
• The in | out | both parameter specifies the traffic direction to monitor. There is no default.
Mirror Ports for Policy-Based Routing (PBR) Traffic
You can mirror traffic on ports that have policy-based routing (PBR) enabled. This feature is useful for monitoring traffic, debugging, and enabling application-specific mirroring.
The PBR mirror interface feature allows continued hardware forwarding and, at the same time, enables you to determine exactly which traffic flows get routed using the policies defined by PBR.
The following section provides a general overview of hardware-based PBR.
About Hardware-Based PBR
Hardware-based Policy-Based Routing (PBR) routes traffic in hardware based on policies you define. A PBR policy specifies the next hop for traffic that matches the policy. A PBR policy also can use an ACL to perform QoS mapping and marking for traffic that matches the policy.
To configure PBR, you define the policies using IP ACLs and route maps, then enable PBR globally or on individual interfaces. The device programs the ACLs into the Layer 4 CAM on the interfaces and routes traffic that matches the ACLs according to the instructions in the route maps. You also can map and mark the traffic's QoS information using the QoS options of the ACLs.
Configuring Mirror Ports for PBR Traffic
When you configure a physical or virtual port to act as a mirror port for PBR traffic, outgoing packets that match the permit Access Control List (ACL) clause in the route map are copied to the mirror port(s) that you specify. You can specify up to four mirror ports for each PBR route map instance.
For example, to capture all traffic forwarded to an SSL port and mirror it to port 5, enter commands such as the following:
BigIron RX(config)# route-map ssl-pbr-map permit 1
BigIron RX(config-routemap ssl-pbr-map)# match ip address 100
November 2005 © 2005 Foundry Networks, Inc.
5-9
Foundry BigIron RX Series Configuration Guide
BigIron RX(config-routemap ssl-pbr-map)# set mirror-interface 5
BigIron RX(config-routemap ssl-pbr-map)# set next-hop 10.10.10.1
BigIron RX(config-routemap ssl-pbr-map)# exit
BigIron RX(config)# interface e 5
BigIron RX(config-if-e10000-5)# port-name mirror-port
BigIron RX(config-if-mirror-port)# interface e 10
BigIron RX(config-if-mirror-port-10)# ip policy route-map ssl-pbr-map
BigIron RX(config-if-mirror-port-10)# exit
BigIron RX(config-if-e10000-)#exit
BigIron RX(config)#access-list 100 permit tcp any any eq ssl
The above commands complete the following configuration tasks:
1.
Configures an entry in the PBR route map named “ssl-pbr-map”. The match statement matches on IP information in ACL 100. The set mirror-interface statement specifies interface e 5 as the mirror port for matched ACL permit clauses. The set next-hop statement sets the IP address of the route’s next hop router to 10.10.10.1.
2.
Identifies interface e 5 as a mirror port by assigning the name “mirror-port”.
3.
Enables PBR and applies the route map “ssl-pbr-map” on interface e 10.
4.
Creates an extended ACL (100) that permits all TCP traffic destined for an for an SSL port.
Syntax: set mirror-interface <slot number>/<port number>
The <slot number> parameter specifies the port number on a BigIron RX.
The <port number> parameter specifies the mirror port number.
You can specify up to 4 mirror ports for each PBR route map instance. To do so, enter the set mirror interface command for each mirror port.
Displaying Mirror and Monitor Port Configuration
To display the inbound and outbound traffic mirrored to each mirror port, enter the following command at any level of the CLI:
BigIron RX# show monitor config
Monitored Port 3/1
Input traffic mirrored to: 1/1 2/1
Output traffic mirrored to: 1/1
Monitored Port 4/1
Input traffic mirrored to: 1/2
Output traffic mirrored to: 1/2
Syntax: show monitor config
This output does not display the input traffic mirrored to mirror port 1/2 from port 3/1 and mirrored to mirror port 1/
1 from port 4/1 because the mirroring of this traffic is not explicitly configured.
To display the actual traffic mirrored to each mirror port, enter the following command at any level of the CLI:
BigIron RX# show monitor actual
Monitored Port 3/1
Input traffic mirrored to: 1/1(configured) 1/2 2/1(configured)
Output traffic mirrored to: 1/1
Monitored Port 4/1
Input traffic mirrored to: 1/2(configured) 1/1
Output traffic mirrored to: 1/2
5-10 © 2005 Foundry Networks, Inc.
November 2005
Configuring Interface Parameters
Syntax: show monitor actual
This output displays the input traffic mirrored to mirror port 1/2 from port 3/1 and mirrored to mirror port 1/1 from port 4/1, which are not explicitly configured.
Enabling WAN PHY Mode Support
A 10 Gigabit Ethernet port can be configured to use SONET/SDH framing for Layer 1 transport across a WAN transport backbone by configuring the port in WAN PHY mode. The default is for the port to operate in LAN PHY mode.
To enable a 10 GB Ethernet port to support WAN PHY mode, use the following command:
BigIron RX#(config-if-e10000-6/3)# phy-mode wan
Syntax: [no] phy-mode wan
To change the PHY mode for a port back to the default of LAN PHY mode, use the no condition before the command.
November 2005 © 2005 Foundry Networks, Inc.
5-11
Foundry BigIron RX Series Configuration Guide
5-12 © 2005 Foundry Networks, Inc.
November 2005
Chapter 6
Configuring Trunk Groups
This chapter describes how to configure trunk groups and 802.3ad link aggregation.
• Trunk groups are manually-configured aggregate links containing multiple ports.
• 802.3ad link aggregation is a protocol that dynamically creates and manages trunk groups.
NOTE:
You can use both types of trunking on the same device. However, you can use only one type of trunking for a given port. For example, you can configure port 1/1 as a member of a static trunk group or you can enable
802.3ad link aggregation on the port, but you cannot do both.
Trunk groups are manually-configured aggregate links containing multiple ports. Trunk groups enable load sharing of traffic, and they also provide redundant, alternate paths for traffic if any of the segments fail.
You can configure up to 8 ports as a trunk group, supporting transfer rates of up to 8 Gbps of bi-directional traffic.
The ports in a trunk group make a single logical link. Therefore, all the ports in a trunk group must be connected to the same device at the other end
Figure 6.1 shows an example of a configuration that uses trunk groups.
Figure 6.1
Trunk Group application within BigIron RX devices
BigIron RX
Trunk
Group
BigIron RX-A
Server
Power Users
Gigabit
Backbone
BigIron RX-B
Trunk
Group
November 2005 © 2005 Foundry Networks, Inc.
6-1
Foundry BigIron RX Series Configuration Guide
NOTE:
The ports in a trunk group make a single logical link. Therefore, all the ports in a trunk group must be connected to the same device at the other end.
Trunk Group Connectivity to a Server
To support termination of a trunk group, the server must have either multiple network interface cards (NICs) or either a dual or quad interface card installed. The trunk server is designated as a server with multiple adapters or
trunk group between a server and BigIron RX.
Figure 6.2
Trunk group between a server and a BigIron RX
Multi-homing adapter has the same IP and
MAC address
Multi-homing
Server
Trunk Group
Trunk Group Rules
• You cannot configure a port as a member of a trunk group if 802.3ad link aggregation is enabled on the port.
• You can configure up to 31 trunks on a BigIron RX.
• You cannot combine 10/100 ports and Gigabit ports in the same trunk group.
• You cannot combine Gigabit and 10-Gigabit ports in the same trunk group.
• Ports can be in only one trunk group. For example, ports 1/4 cannot be in the Trunk Group 1 and Trunk Group
2.
• All the ports in a trunk group must be connected to the same device at the other end. For example, a if port 1/
4 and 1/5 in Device 1 are in the same trunk group, both ports must be connected to a ports in Device 2 or in
Device 3. You cannot have one port connected to Device 2 and another port connected to Device 3.
• All trunk group member properties must match the lead port of the trunk group with respect to the following parameters:
• Port tag type (untagged or tagged port)
• Port speed and duplex
• QoS priority
To change port parameters, you must change them on the primary port. The software automatically applies the changes to the other ports in the trunk group.
• Make sure the device on the other end of the trunk link can support the same number of ports in the link. For example, if you configure a five-port trunk group on the FastIron Edge Switch switch and the other end is a different type of switch, make sure the other switch can support a five-port trunk group.
6-2 © 2005 Foundry Networks, Inc.
November 2005
Configuring Trunk Groups
group on one device are connected to two ports in a valid 2-port trunk group on another device. The same rules apply to 4-port trunk groups.
Figure 6.3
Examples of 2-port trunk groups
Port 1/1
Port 1/2
Port 1/3
Port 1/4
Port 1/5
Port 1/6
Port 1/7
Port 1/8
Figure 6.4 shows examples of two devices connected by multi-slot trunk groups.
Figure 6.4
Examples of multi-slot trunk groups
Port 1/1
Port 1/2
Port 1/3
Port 1/4
Port 1/5
Port 1/6
Port 1/7
Port 1/8
Port 2/1
Port 2/2
Port 2/3
Port 2/4
Port 2/5
Port 2/6
Port 2/7
Port 2/8
Port 1/1
Port 1/2
Port 1/3
Port 1/4
Port 1/5
Port 1/6
Port 1/7
Port 1/8
Port 1/1
Port 1/2
Port 1/3
Port 1/4
Port 1/5
Port 1/6
Port 1/7
Port 1/8
Port 2/1
Port 2/2
Port 2/3
Port 2/4
Port 2/5
Port 2/6
Port 2/7
Port 2/8
Specifying a Minimum Number of Ports for a Trunk Group
You can configure the BigIron RX to disable all of the ports in a trunk group when the number of active member ports drops below a specified threshold value. For example, if a trunk group has 8 ports, and the threshold for the trunk group is 5, then the trunk group is disabled if the number of available ports in the trunk group drops below 5.
If the trunk group is disabled, then traffic is forwarded over a different link or trunk group.
For example, the following commands establish a trunk group consisting of 4 ports, then establish a threshold for this trunk group of 3 ports.
BigIron RX(config)# trunk e 3/31 to 3/34
BigIron RX(config-trunk-3/31-3/34)# threshold 3
In this example, if the number of active ports drops below 3, then all the ports in the trunk group are disabled.
Syntax: [no] threshold <number>
You can specify a threshold from 1 (the default) up to the number of ports in the trunk group.
Trunk Formation Rules
The following rules for trunk formation apply to the BigIron RX software release 02.2.01 and later:
• Trunks can be formed from any number of ports, as long as they contain at a minimum of 2 ports and a maximum of ports.
November 2005 © 2005 Foundry Networks, Inc.
6-3
Foundry BigIron RX Series Configuration Guide
• Ports in a trunk must have the same speed, the same negotiation mode, and the same QoS priority; otherwise, the trunk is rejected.
• Rate Limiting and PBR requirements:
Primary port policy will apply to all secondary ports. No trunk is rejected.
• Mirroring/Monitoring requirements:
The trunk is rejected if any trunk port has mirroring or monitoring configured.
• VLAN and inner-VLAN translation:
The trunk is rejected if any trunk port has vlan or inner-vlan translation configured.
• Layer 2 requirements:
The trunk is rejected if the trunk ports:
• do not have the same untagged VLAN component.
• do not share the same SuperSpan customer id (or cid).
• do not share the same vlan membership
• do not share the same uplink vlan membership
• do not share the same protocol-vlan configuration
• are configured as mrp primary and secondary interfaces
• Layer 3 requirements:
The trunk is rejected if any of the secondary trunk port has any Layer 3 configurations, such as Ipv4 or Ipv6 address, ospf, rip, ripng, isis, etc.
• Layer 4 (ACL) requirements:
All trunk ports must have the same ACL configurations; otherwise, the trunk is rejected.
• You can have a maximum of 31 trunks.
Trunk Group Load Sharing
The BigIron RX shares the traffic load evenly across the ports in the trunk group, while ensuring that packets in the flow are not reordered. To select a port in a trunk group where traffic will be forwarded, BigIron RX calculates a hash index as follows:
• For L2 traffic, the hash index is based on MAC source and destination addresses
• For L3 traffic, the hash index is based is based on the following:
• IPv4 non-TCP/UDP packets: destination MAC address and source MAC address, source IP address and destination IP address
• IPv4 TCP packets: destination MAC address and source MAC address, source IP address and destination IP address, and TCP source port and TCP destination port.
• IPv4 UDP packets: destination MAC address and source MAC address, source IP address and destination IP address, and UDP source port and UDP destination port.
The BigIron RX uses the hash index in the following formula, using the modulo operator (written as “%” in C programming language):
(hash index)% (Number of trunk ports in a trunk group) = selected trunk port
6-4 © 2005 Foundry Networks, Inc.
November 2005
Configuring Trunk Groups
Configuring a Trunk Group
Use the following procedure when configuring trunk groups:
1.
Disconnect the cables from those ports on both systems that will be connected by the trunk group. Do not configure the trunk groups with the cables connected.
NOTE:
If you connect the cables before configuring the trunk groups and then rebooting, the traffic on the ports can create a spanning tree loop.
2.
Configure the trunk group on one of the two BigIron RX devices involved in the configuration. See the CLI commands below.
3.
Save the configuration changes to the startup-config file.
4.
If the device at the other end of the trunk group is another BigIron RX devices, repeat Steps 2 – 4 for the other device. If it is not, refer to the user guide for that device.
5.
When the trunk groups on both devices are operational, reconnect the cables to those ports that are now configured as trunk groups, starting with the first port (lead port) of each trunk group.
6.
To verify the link is operational, use the show trunk command.
Naming a Trunk Port
To name an individual port in a trunk group, enter a command such as the following at the trunk group configuration level:
BigIron RX(config-trunk-4/1-4/4)# port-name customer1 ethernet 4/2
Syntax: [no] port-name <text> ethernet <slot>/<portnum>
The <text> parameter specifies the port name. The name can be up to 50 characters long.
This command assigns the name “customer1” to port 4/2 in the trunk group consisting of ports 4/1 – 4/4.
Disabling or Re-Enabling a Trunk Port
You can disable or re-enable individual ports in a trunk group. To disable an individual port in a trunk group, enter commands such as the following at the trunk group configuration level:
BigIron RX(config-trunk-4/1-4/4)# config-trunk-ind
BigIron RX(config-trunk-4/1-4/4)# disable ethernet 4/2
Syntax: [no] config-trunk-ind
Syntax: [no] disable ethernet <slot>/<portnum>
The config-trunk-ind command enables configuration of individual ports in the trunk group. If you do not use this command, the disable command will be valid only for the primary port in the trunk group and will disable all ports in the trunk group. You need to enter the config-trunk-ind command only once in a trunk group. After you enter the command, all applicable port configuration commands apply to individual ports only.
NOTE:
If you enter no config-trunk-ind, all port configuration commands are removed from the individual ports and the configuration of the primary port is applied to all the ports. Also, once you enter the no config-trunk-ind command, the enable, disable, and monitor commands are valid only on the primary port and apply to the entire trunk group.
The disable command disables the port. The states of other ports in the trunk group are not affected.
If you have configured a name for the trunk port, you can specify the port name, as shown in the following example:
BigIron RX(config-trunk-4/1-4/4)# config-trunk-ind
BigIron RX(config-trunk-4/1-4/4)# disable customer1
November 2005 © 2005 Foundry Networks, Inc.
6-5
Foundry BigIron RX Series Configuration Guide
Syntax: disable <portname>
To enable an individual port in a trunk group, enter commands such as the following at the trunk group configuration level:
BigIron RX(config-trunk-4/1-4/4)# config-trunk-ind
BigIron RX(config-trunk-4/1-4/4)# enable ethernet 4/2
Syntax: enable ethernet <slot>/<portnum>
Syntax: enable <portname>
Disabling or Re-Enabling a Range or List of Trunk Ports
To disable a range of ports in a trunk group, enter commands such as the following:
BigIron RX(config)# trunk switch ethernet 2/1 to 2/8
BigIron RX(config-trunk-2/1-2/8)# config-trunk-ind
BigIron RX(config-trunk-2/1-2/8)# disable ethernet 2/2 to 2/5
This command disables ports 2/2 – 2/5 in trunk group 2/1 – 2/8.
To disable a list of ports, enter a command such as the following:
BigIron RX(config-trunk-2/1-2/8)# disable ethernet 2/2 ethernet 2/4 ethernet 2/7
This command disables ports 2/2, 2/4, and 2/7 in the trunk group.
You can specify a range and a list on the same command line. For example, to re-enable some trunk ports, enter a command such as the following:
BigIron RX(config-trunk-2/1-2/8)# enable ethernet 2/2 to 2/5 ethernet 2/7
Syntax: [no] disable ethernet <slot>/<portnum> [to <slot>/<portnum> | ethernet <slot>/<portnum>]
Syntax: [no] enable ethernet <slot>/<portnum> [to <slot>/<portnum> | ethernet <slot>/<portnum>]
The to <slot>/<portnum> parameter indicates that you are specifying a range. Specify the lower port number in the range first, then to, then the higher port number in the range.
The ethernet <slot>/<portnum> parameter specifies an individual port. You can enter this parameter multiple times to specify a list, as shown in the examples above.
Deleting a Trunk Group
To delete a trunk group, use “no” in front of the command you used to create the trunk group. For example, to remove one of the trunk groups configured in the examples above, enter the following command:
BigIron RX(config)# no trunk ethernet 1/1 to 1/2 ethernet 3/3 to 3/4
Syntax: no trunk ethernet <slot>/<portnum> to <slot>/<portnum>
6-6 © 2005 Foundry Networks, Inc.
November 2005
Configuring Trunk Groups
Displaying Trunk Group Configuration Information
To display trunk group information for specific ports, enter a command such as the following:
BigIron RX(config)# show trunk ethernet 1/1 to 1/8
Configured trunks:
Trunk ID: 1
Ports_Configured: 8
Primary Port Monitored: Jointly
Ports 1/1 1/2 1/3 1/4 1/5 1/6 1/7 1/8
Port Names none none none none none longna test none
Port_Status enable enable enable enable disable disable enable enable
Monitor on on off on off off off off
Mirror Port 3/3 3/4 N/A 3/5 N/A N/A N/A N/A
Monitor Dir both in N/A out N/A N/A N/A N/A
Operational trunks:
Trunk ID: 1
Duplex: Full
Speed: 1G
Tag: No
Priority: level0
Active Ports: 6
Ports 1/1 1/2 1/3 1/4 1/5 1/6 1/7 1/8
Link_Status active active active active down down active active
LACP_Status ready ready ready expired down down ready ready
Load Sharing
Mac Address 3 2 2 2 0 0 6 1
Multicast 4 2 5 2 0 0 2 3
Syntax: show trunk ethernet <slot>/<portnum> to <slot>/<portnum>
The display is divided into sections for configured trunks and operational trunks. A configured trunk group is one that has not been activated yet.
Table 6.1 describes the information displayed by the show trunk command.
This Field...
Trunk ID
Table 6.1: CLI Trunk Group Information
Displays...
The trunk group number. The software numbers the groups in the display to make the display easy to use.
November 2005 © 2005 Foundry Networks, Inc.
6-7
Foundry BigIron RX Series Configuration Guide
This Field...
Duplex
Speed
Tag
Priority
Active Ports
Ports
Link_Status
LACP_Status
Load Sharing
Table 6.1: CLI Trunk Group Information (Continued)
Displays...
The mode of the port, which can be one of the following:
• None – The link on the primary trunk port is down.
• Full – The primary port is running in full-duplex.
• Half – The primary port is running in half-duplex.
Note: This field and the following fields apply only to operational trunk groups.
The speed set for the port. The value can be one of the following:
• None – The link on the primary trunk port is down.
• 10 – The port speed is 10 Mbps.
• 100 – The port speed is 100 Mbps.
• IG – The port speed is 1000 Mbps.
Indicates whether the ports have 802.1q VLAN tagging. The value can be Yes or No.
Indicates the Quality of Service (QoS) priority of the ports. The priority can be a value from 0 – 7.
The number of ports in the trunk group that are currently active.
The ports in the trunk group.
The link status or each port in the trunk group.
This field appears in software releases 07.6.03 and later. For more
information about this feature, see the section “Displaying and
Determining the Status of Aggregate Links” on page 7-9.
• Ready - The port is functioning normally in the trunk group and is able to transmit and receive LACP packets.
• Expired - The time has expired (as determined by timeout values) and the port has shut down because the port on the other side of the link has stopped transmitting packets.
• Down - The port’s physical link is down.
The number of traffic flows currently being load balanced on the trunk ports. All traffic exchanged within the flow is forwarded on the same
trunk port. For information about trunk load sharing, see “Trunk
Group Load Sharing” on page 6-4.
6-8 © 2005 Foundry Networks, Inc.
November 2005
Chapter 7
Dynamic Link Aggregation
The software supports the IEEE 802.3ad standard for link aggregation. This standard describes the Link
Aggregation Control Protocol (LACP), a mechanism for allowing ports on both sides of a redundant link to configure themselves into a trunk link (aggregate link), without the need for manual configuration of the ports into trunk groups.
When you enable link aggregation on a group of Foundry ports, the Foundry ports can negotiate with the ports at the remote ends of the links to establish trunk groups.
Usage Notes
• You cannot use 802.3ad link aggregation on a port configured as a member of a static trunk group.
• When the feature dynamically adds or changes a trunk group, the show trunk command displays the trunk as both configured and active. However, the show running-config or write terminal command does not contain a trunk command defining the new or changed trunk group.
• If the feature places a port into a trunk group as a secondary port, all configuration information except information related to link aggregation is removed from the port. For example, if port 1/3 has an IP interface, and the link aggregation feature places port 1/3 into a trunk group consisting of ports 1/1 – 1/4, the IP interface is removed from the port.
• You can enable link aggregation on 802.1q tagged ports (ports that belong to more than one port-based
VLAN).
Configuration Rules
Foundry ports follow the same configuration rules for dynamically created aggregate links as they do for statically
NOTE:
Foundry recommends that you disable or remove the cables from the ports you plan to enable for dynamic link aggregation. Doing so prevents the possibility that LACP will use a partial configuration to talk to the other side of a link. A partial configuration does not cause errors, but does sometimes require LACP to be disabled and re-enabled on both sides of the link to ensure that a full configuration is used. It's easier to disable a port or remove its cable first. This applies both for active link aggregation and passive link aggregation.
Figure 7.1 on page 7-2 shows some examples of valid aggregate links.
November 2005 © 2005 Foundry Networks, Inc.
7-1
Foundry BigIron RX Series Configuration Guide
Figure 7.1
Examples of valid aggregate links
Foundry ports enabled for link aggregation follow the same rules as ports configured for trunk groups.
Port 1/1
Port 1/2
Port 1/3
Port 1/4
Port 1/5
Port 1/6
Port 1/7
Port 1/8
Port 1/1
Port 1/2
Port 1/3
Port 1/4
Port 1/5
Port 1/6
Port 1/7
Port 1/8
7-2
Port 1/1
Port 1/2
Port 1/3
Port 1/4
Port 1/5
Port 1/6
Port 1/7
Port 1/8
In this example, assume that link aggregation is enabled on all of the links between the Foundry device on the left and the device on the right (which can be either a Foundry device or another vendor’s device). Notice that some ports are not able to join an aggregate link even though link aggregation is enabled on them. The ports that are not members of aggregate links in this example are not following the configuration rules for trunk links on Foundry devices.
The Foundry rules apply to a Foundry device even if the device at the other end is from another vendor and uses
different rules. See “Trunk Group Rules” on page 6-2.
The link aggregation feature automates trunk configuration but can coexist with Foundry’s trunk group feature.
Link aggregation parameters do not interfere with trunk group parameters.
© 2005 Foundry Networks, Inc.
November 2005
Dynamic Link Aggregation
NOTE:
Use the link aggregation feature only if the device at the other end of the links you want to aggregate also supports IEEE 802.3ad link aggregation. Otherwise, you need to manually configure the trunk links.
Link aggregation support is disabled by default. You can enable the feature on an individual port basis, in active or passive mode.
• Active mode – When you enable a port for active link aggregation, the Foundry port can exchange standard
LACP Protocol Data Unit (LACPDU) messages to negotiate trunk group configuration with the port on the other side of the link. In addition, the Foundry port actively sends LACPDU messages on the link to search for a link aggregation partner at the other end of the link, and can initiate an LACPDU exchange to negotiate link aggregation parameters with an appropriately configured remote port.
• Passive mode – When you enable a port for passive link aggregation, the Foundry port can exchange
LACPDU messages with the port at the remote end of the link, but the Foundry port cannot search for a link aggregation port or initiate negotiation of an aggregate link. Thus, the port at the remote end of the link must initiate the LACPDU exchange.
November 2005 © 2005 Foundry Networks, Inc.
7-3
Foundry BigIron RX Series Configuration Guide
Adaptation to Trunk Disappearance
The Foundry device will tear down an aggregate link if the device at the other end of the link reboots or brings all the links down. Tearing the aggregate link down prevents a mismatch if the other device has a different trunk
mismatch.
Figure 7.2
Trunk port mismatch
Four ports on each device are eligible for link aggregation. The device negotiates a four-port trunk using the ports.
Port 1/1
Port 1/2
Port 1/3
Port 1/4
Port 1/1
Port 1/2
Port 1/3
Port 1/4
7-4
One device reloads, after which only two of its ports are eligible for link aggregation.
However, the first device is still configured with the four-port trunk group. The trunks are mismatched.
This type of mismatch does not occur in the BigIron RX.
Port 1/1
Port 1/2
Port 1/3
Port 1/4
X
X
Port 1/1
Port 1/2
Adaptation to trunk disappearance prevents trunk mismatches caused when one device changes the number of ports in group of ports that has become part of an 802.3 aggregate link. If a device changes the number of ports in an active aggregate link, the Foundry device on the other end of the link tears down the link. Once the other device recovers, 802.3 can renegotiate the link without a mismatch.
© 2005 Foundry Networks, Inc.
November 2005
Dynamic Link Aggregation
Enabling Link Aggregation
By default, link aggregation is disabled on all ports. To enable link aggregation on a set of ports, enter commands such as the following at the interface configuration level of the CLI.
NOTE:
Configuration commands for link aggregation differ depending on whether you are using the default link aggregation key automatically assigned by the software, or if you are assigning a different, unique key. Follow the
Using the Default Key Assigned by the Software
BigIron RX(config)# interface ethernet 1/1
BigIron RX(config-if-e1000-1/1)# link-aggregate active
BigIron RX(config)# interface ethernet 1/2
BigIron RX(config-if-e1000-1/2)# link-aggregate active
The commands in this example enable the active mode of link aggregation on ports 1/1 and 1/2. The ports can send and receive LACPDU messages. Note that these ports will use the default key, since one has not been explicitly configured.
Assigning a Unique Key
BigIron RX(config)# interface ethernet 1/1
BigIron RX(config-if-e1000-1/1)# link-aggregate configure key 10000
BigIron RX(config-if-e1000-1/1)# link-aggregate active
BigIron RX(config)# interface ethernet 1/2
BigIron RX(config-if-e1000-1/2)# link-aggregate configure key 10000
BigIron RX(config-if-e1000-1/2)# link-aggregate active
The commands in this example assign the key 10000 and enable the active mode of link aggregation on ports 1/1 and 1/2. The ports can send and receive LACPDU messages.
NOTE:
As shown in this example, when configuring a key, it is pertinent that you assign the key prior to enabling link aggregation.
The following commands enable passive link aggregation on ports 1/5 – 1/8:
BigIron RX(config)# interface ethernet 1/5 to 1/8
BigIron RX(config-if-1/5-1/8)# link-aggregate passive
The commands in this example enable the passive mode of link aggregation on ports 1/5 – 1/8. These ports wait for the other end of the link to contact them. After this occurs, the ports can send and receive LACPDU messages.
To disable link aggregation on a port, enter a command such as the following:
BigIron RX(config-if-e1000-1/8)# link-aggregate off
Syntax: [no] link-aggregate active | passive | off
Syntax: [no] link-aggregate configure [system-priority <num>] | [port-priority <num>] | [key <num>] ]
NOTE:
Configuring Link Aggregation Parameters
On a BigIron RX running software release 02.2.01, the lacp system-priority command specifies the Foundry device’s link aggregation priority relative to the devices at the other ends of the links on which link aggregation is enabled. You can change the value of this parameter globally by entering the following command:
November 2005 © 2005 Foundry Networks, Inc.
7-5
Foundry BigIron RX Series Configuration Guide
BigIron RX(config)# lacp system-priority 3
Syntax: lacp system-priority <number>
Specify 1 – 65535 for number. A higher value indicates a lower priority. The default is 1.
NOTE:
If you are connecting the Foundry device to another vendor’s device and the link aggregation feature is not working, set the system priority on the Foundry device to a lower priority (a higher priority value). In some cases, this change allows the link aggregation feature to operate successfully between the two devices.
You can change the settings for the following link aggregation parameters, on an individual port basis:
• Port priority
• Key
Configuring Port Priority
The port priority determines the active and standby links. When a group of ports is negotiating with a group of ports on another device to establish a trunk group, the Foundry port with the highest priority becomes the default active port. The other ports (with lower priorities) become standby ports in the trunk group.
BigIron RX(config)# interface ethernet 1/1
BigIron RX(config-if-e1000-1/1)# priority
Syntax: priority <number>
You can specify a priority from 0 – 65535. A higher value indicates a lower priority. The default is 1.
The primary port in the port group becomes the default active port. The primary port is the lowest-numbered port in a valid trunk-port group.
Configuring Keys for Ports
Every port that is 802.3ad-enabled has a key. The key identifies the group of potential trunk ports to which the port belongs. Ports with the same key are called a key group and are eligible to be in the same trunk group. When you enable link-aggregation on a tagged or untagged port, Foundry’s software assigns a default key to the port.
All ports within an aggregate link must have the same key. However, if the device has ports that are connected to two different devices, and the port groups allow the ports to form into separate aggregate links with the two devices, then each group of ports can have the same key while belonging to separate aggregate links with
different devices. Figure 7.3 on page 7-7 shows an example.
7-6 © 2005 Foundry Networks, Inc.
November 2005
Figure 7.3
Ports with the same key in different aggregate links
Dynamic Link Aggregation
All these ports have the same key, but are in two separate aggregate links with two other devices.
Port 1/1
Port 1/2
Port 1/3
Port 1/4
Port 1/5
Port 1/6
Port 1/7
Port 1/8
System ID: aaaa.bbbb.cccc
Ports 1/1 - 1/8: Key 0
System ID: dddd.eeee.ffff
Ports 1/5 - 1/8: Key 4
System ID: 1111.2222.3333
Ports 1/5 - 1/8: Key 69
Notice that the keys between one device and another do not need to match. The only requirement for key matching is that all the ports within an aggregate link on a given device must have the same key.
Devices that support multi-slot trunk groups can form multi-slot aggregate links using link aggregation. However, the link aggregation keys for the groups of ports on each module must match. For example, if you want to allow link aggregation to form an aggregate link containing ports 1/1 – 1/4 and 3/5 – 3/8, you must change the link
November 2005 © 2005 Foundry Networks, Inc.
7-7
Foundry BigIron RX Series Configuration Guide
Figure 7.4
Multi-slot aggregate link
All ports in a multi-slot aggregate link have the same key.
Port 1/1
Port 1/2
Port 1/3
Port 1/4
Port 3/5
Port 3/6
Port 3/7
Port 3/8
System ID: aaaa.bbbb.cccc
Ports 1/1 - 1/4: Key 0
Ports 3/5 - 3/8: Key 0
By default, the device’s ports are divided into 4-port groups. The software dynamically assigns a unique key to each 4-port group. If you need to divide a 4-port group into two 2-port groups, change the key in one of the groups so that the two 2-port groups have different keys. For example, if you plan to use ports 1/1 and 1/2 in VLAN 1, and ports 1/3 and 1/4 in VLAN 2, change the key for ports 1/3 and 1/4.
For key configuration only, configuration commands differ depending on whether or not link aggregation is enabled on the port(s). Follow the appropriate set of commands below, according to your system’s configuration.
Configuring Keys For Ports with Link Aggregation Disabled
Use the command sequence below to change the key for ports that do not have link aggregation enabled, and for all other link aggregation parameters (i.e., system priority, port priority, and link type).
BigIron RX(config)# interface ethernet 1/1 to 1/4
BigIron RX(config-if-1/1-1/4)# link-aggregate configure key 10000
BigIron RX(config-if-1/1-1/4)# interface ethernet 3/5 to 3/8
BigIron RX(config-if-3/5-3/8)# link-aggregate configure key 10000
NOTE:
If you change the key for a port group, Foundry recommends that you use the value 10000 or higher, to avoid potential conflicts with dynamically created keys.
Configuring Keys For Ports with Link Aggregation Enabled
As shown in this command sequence, to change the key on ports that already have link aggregation enabled, you must first turn OFF link aggregation, configure the new key, then re-enable link aggregation.
BigIron RX(config)# interface ethernet 1/1 to 1/4
BigIron RX(config-if-1/1-1/4)# link-aggregate off
BigIron RX(config-if-1/1-1/4)# link-aggregate configure key 10000
BigIron RX(config-if-1/1-1/4)# link-aggregate active
BigIron RX(config-if-1/1-1/4)# interface ethernet 3/5 to 3/8
BigIron RX(config-if-3/5-3/8)# link-aggregate off
BigIron RX(config-if-3/5-3/8)# link-aggregate configure key 10000
BigIron RX(config-if-3/5-3/8)# link-aggregate active
These commands change the key for ports 1/1 – 1/4 and 3/5 – 3/8 to 10000. Since all ports in an aggregate link must have the same key, the command in this example enables ports 1/1 – 1/4 and 3/5 – 3/8 to form a multi-slot aggregate link.
Syntax: [no] link-aggregate configure [port-priority <num>] | [key <num>]
The port-priority <num> parameter specifies an individual port’s priority within the port group. A higher value indicates a lower priority. You can specify a priority from 0 – 65535. The default is 1.
7-8 © 2005 Foundry Networks, Inc.
November 2005
Dynamic Link Aggregation
The key <num> parameter identifies the group of ports that are eligible to be aggregated into a trunk group. The software automatically assigns a key to each group of ports. The software assigns the keys in ascending numerical order, beginning with 10000. You can change a port group’s key to a value from 10000 – 65535.
NOTE:
If you change the key for a port group, Foundry recommends that you use the value 10000 or higher, to avoid potential conflicts with dynamically created keys.
You can enter one or more of the command’s parameters on the same command line, in any order.
Viewing Keys for Tagged Ports
To display link aggregation information, including the key for a specific port, enter a command such as the following at any level of the CLI:
BigIron RX# show link-aggregation ethernet 1/1
System ID: 00e0.52a9.bb00
Port [Sys P] [Port P] [ Key ] [Act][Tio][Agg][Syn][Col][Dis][Def][Exp]
1/1 1 1 10000 No L No No No No No No
The command in this example shows the key and other link aggregation information for port 1/1.
To display link aggregation information, including the key for all ports on which link aggregation is enabled, enter the following command at any level of the CLI:
BigIron RX# show link-aggregation
System ID: 0004.8055.b200
Long timeout: 90, default: 90
Short timeout: 3, default: 3
Port [Sys P] [Port P] [ Key ] [Act][Tio][Agg][Syn][Col][Dis][Def][Exp][Ope]
1/1 1 1 10000 Yes S Agg Syn Col Dis Def No Dwn
1/2 1 1 10000 Yes S Agg Syn Col Dis Def No Dwn
2/1 1 1 10000 Yes S Agg Syn Col Dis Def No Dwn
2/2 1 1 10000 Yes S Agg Syn Col Dis Def No Dwn
4/1 1 1 10000 Yes S Agg Syn Col Dis Def No Dwn
4/2 1 1 10000 Yes S Agg Syn Col Dis Def No Dwn
4/3 1 1 10000 Yes S Agg Syn Col Dis Def No Dwn
4/4 1 1 48000 Yes S Agg Syn Col Dis Def No Dwn
4/17 1 1 48000 Yes S Agg Syn Col Dis Def No Ope
4/18 1 1 48000 Yes S Agg Syn Col Dis Def No Ope
4/19 1 1 48000 Yes S Agg Syn Col Dis Def No Ope
4/20 1 1 48000 Yes S Agg Syn Col Dis Def No Ope
For information about the fields in this display, see Table 7.1 on page 7-10.
Syntax: show link-aggregation [ethernet <slot>/<portnum>]
Possible values: N/A
Default value: N/A
Displaying and Determining the Status of Aggregate Links
November 2005 © 2005 Foundry Networks, Inc.
7-9
Foundry BigIron RX Series Configuration Guide
Displaying Link Aggregation and Port Status Information
Use the show link-aggregation command to determine the operational status of ports associated with aggregate links.
To display the link aggregation information for a specific port, enter a command such as the following at any level of the CLI:
BigIron RX(config-if-1/1-1/8)# show link-aggregation ethernet 1/1
System ID: 00e0.52a9.bb00
Port [Sys P] [Port P] [ Key ] [Act][Tio][Agg][Syn][Col][Dis][Def][Exp] [Ope]
1/1 1 1 10000 No L No No No No No No Ope
The command in this example shows the link aggregation information for port 1/1.
To display the link aggregation information for all ports on which link aggregation is enabled, enter the following command at any level of the CLI:
BigIron RX(config)# show link-aggregation
System ID: 00e0.52a9.bb00
Port [Sys P] [Port P] [ Key ] [Act][Tio][Agg][Syn][Col][Dis][Def][Exp][Ope]
1/1 1 1 10000 No L Agg Syn No No Def Exp Ope
1/2 1 1 10000 No L Agg Syn No No Def Exp Ina
1/3 1 1 10000 No L Agg Syn No No Def Exp Ina
1/4 1 1 10000 No L Agg Syn No No Def Exp Blo
1/5 1 1 48000 No L Agg No No No Def Exp Ope
1/6 1 1 48000 No L Agg No No No Def Exp Ope
1/7 1 1 48000 No L Agg No No No Def Exp Dwn
1/8 1 1 48000 No L Agg No No No Def Exp Dwn
Syntax: show link-aggregation [ethernet <slot>/<portnum>]
Use ethernet <slot>/<portnum> to display link-aggregation information for a specific port. Ports that are configured as part of an aggregate link must also have the same key.
The show link aggregation command shows the following information.
This Field...
System ID
Port
Sys P
Port P
Key
Table 7.1: CLI Display of Link Aggregation Information
Displays...
Lists the base MAC address of the device. This is also the MAC address of port 1 (or 1/1).
Lists the port number.
Lists the system priority configured for the device.
Lists the port’s link aggregation priority.
Lists the link aggregation key.
7-10 © 2005 Foundry Networks, Inc.
November 2005
This Field...
Act
Tio
Agg
Syn
Col
Dis
Dynamic Link Aggregation
Table 7.1: CLI Display of Link Aggregation Information (Continued)
Displays...
Indicates the link aggregation mode, which can be one of the following:
• No – The mode is passive on the port.
If link aggregation is enabled (and the mode is passive), the port can send and receive LACPDU messages to participate in negotiation of an aggregate link initiated by another port, but cannot search for a link aggregation port or initiate negotiation of an aggregate link.
• Yes – The mode is active. The port can send and receive
LACPDU messages.
Indicates the timeout value of the port. The timeout value can be one of the following:
• L – Long. The trunk group has already been formed and the port is therefore using a longer message timeout for the LACPDU messages exchanged with the remote port. Typically, these messages are used as confirmation of the health of the aggregate link.
• S – Short. The port has just started the LACPDU message exchange process with the port at the other end of the link. The S timeout value also can mean that the link aggregation information received from the remote port has expired and the ports are starting a new information exchange.
Indicates the link aggregation state of the port. The state can be one of the following:
• Agg – Link aggregation is enabled on the port.
• No – Link aggregation is disabled on the port.
Indicates the synchronization state of the port. The state can be one of the following:
• No – The port is out of sync with the remote port. The port does not understand the status of the LACPDU process and is not prepared to enter a trunk link.
• Syn – The port is in sync with the remote port. The port understands the status of the LACPDU message exchange process, and therefore knows the trunk group to which it belongs, the link aggregation state of the remote port, and so on.
Indicates the collection state of the port, which determines whether the port is ready to send traffic over the trunk link.
• Col – The port is ready to send traffic over the trunk link.
• No – The port is not ready to send traffic over the trunk link.
Indicates the distribution state of the port, which determines whether the port is ready to receive traffic over the trunk link.
• Dis – The port is ready to receive traffic over the trunk link.
• No – The port is not ready to receive traffic over the trunk link.
November 2005 © 2005 Foundry Networks, Inc.
7-11
Foundry BigIron RX Series Configuration Guide
This Field...
Def
Exp
Ope
Table 7.1: CLI Display of Link Aggregation Information (Continued)
Displays...
Indicates whether the port is using default link aggregation values.
The port uses default values if it has not received link aggregation information through LACP from the port at the remote end of the link.
This field can have one of the following values:
• Def – The port has not received link aggregation values from the port at the other end of the link and is therefore using its default link aggregation LACP settings.
• No – The port has received link aggregation information from the port at the other end of the link and is using the settings negotiated with that port.
Indicates whether the negotiated link aggregation settings have expired. The settings expire if the port does not receive an LACPDU message from the port at the other end of the link before the message timer expires. This field can have one of the following values:
• Exp – The link aggregation settings this port negotiated with the port at the other end of the link have expired. The port is now using its default link aggregation settings.
• No – The link aggregation values that this port negotiated with the port at the other end of the link have not expired, so the port is still using the negotiated settings.
• Ope (operational) - The port is operating normally.
• Ina (inactive) - The port is inactive because the port on the other side of the link is down or has stopped transmitting LACP packets.
• Blo (blocked) - The port is blocked because the adjacent port is not configured with link aggregation or because it is not able to join a trunk group. An LACP port is blocked until it becomes part of a trunk. Also, an LACP is blocked if its state becomes “default”.
To unblock the port and bring it to an operational state, enable link aggregation on the adjacent port and ensure that the ports have the same key.
Displaying Trunk Group and LACP Status Information
7-12 © 2005 Foundry Networks, Inc.
November 2005
Chapter 8
Configuring Uni-Directional Link Detection (UDLD)
Uni-directional Link Detection (UDLD) monitors a link between two BigIron RX and provides a fast detection of link failures. UDLD brings the ports on both ends of the link down if the link goes down at any point between the two
Figure 8.1
UDLD example
Without link keepalive, the Foundry ports remain enabled. Traffic continues to be load balanced to the ports connected to the failed link.
When link keepalive is enabled, the feature brings down the Foundry ports connected to the failed link.
X
Ports enabled for UDLD exchange proprietary health-check packets once every 500 ms (the keepalive interval). If a port does not receive a health-check packet from the port at the other end of the link within the keepalive interval, the port waits for two more intervals. If the port still does not receive a health-check packet after waiting for three intervals, the port concludes that the link has failed and takes the port down.
Configuration Considerations
• The feature is supported only on Ethernet ports.
• To configure UDLD on a trunk group, you must configure the feature on each port of the group individually.
Configuring UDLD on a trunk group’s primary port enables the feature on that port only.
• Dynamic trunking is not supported. If you want to configure a trunk group that contains ports on which UDLD is enabled, you must remove the UDLD configuration from the ports. After you create the trunk group, you can re-add the UDLD configuration.
November 2005 © 2005 Foundry Networks, Inc.
8-1
Foundry BigIron RX Series Configuration Guide
Configuring UDLD
To enable UDLD on a port, enter a command such as the following at the global CONFIG level of the CLI:
BigIron RX(config)# link-keepalive ethernet 1/1
Syntax: [no] link-keepalive ethernet <slot>/<portnum> [ethernet <slot>/<portnum>]
To enable the feature on a trunk group, enter commands such as the following:
BigIron RX(config)# link-keepalive ethernet 1/1 ethernet 1/2
BigIron RX(config)# link-keepalive ethernet 1/3 ethernet 1/4
These commands enable UDLD on ports 1/1 – 1/4. You can specify up to two ports on the same command line.
Changing the Keepalive Interval
By default, ports enabled for UDLD send a link health-check packet once every 500 ms. You can change the interval to a value from 1 – 60, where 1 is 100 ms, 2 is 200 ms, and so on. To change the interval, enter a command such as the following:
BigIron RX(config)# link-keepalive interval 3
Syntax: [no] link-keepalive interval <num>
The <num> parameter specifies how often the ports send a UDLD packet. You can specify from 1 – 60, in 100 ms increments. The default is 5 (500 ms).
Changing the Keepalive Retries
You can change the maximum number of keepalive attempts to a value from 3 – 10. To change the maximum number of attempts, enter a command such as the following:
BigIron RX(config)# link-keepalive retries 4
Syntax: [no] link-keepalive retries <num>
The <num> parameter specifies the maximum number of times the port will try the health check. You can specify a value from 3 – 10. The default is 5.
Displaying UDLD Information
Displaying Information for All Ports
To display UDLD information for all ports, enter the following command:
BigIron RX(config)# show link-keepalive
Total link-keepalive enabled ports: 4
Keepalive Retries: 5 Keepalive Interval: 1 Sec.
Port Physical Link Link-keepalive Logical Link
4/1 up up up
4/2 up up up
4/3 down down down
4/4 up down down
8-2 © 2005 Foundry Networks, Inc.
November 2005
Configuring Uni-Directional Link Detection (UDLD)
Syntax: show link-keepalive [ethernet <slot>/<portnum>]
Keepalive Interval
Port
Physical Link
Link-keepalive
Logical Link
Table 8.1: CLI Display of UDLD Information
This Field...
Total link-keepalive enabled ports
Keepalive Retries
Displays...
The total number of ports on which UDLD is enabled.
The number of times a port will attempt the health check before concluding that the link is down.
The number of seconds between health check packets.
The port number.
The state of the physical link. This is the link between the BigIron RX port and the directly connected device.
Show if the keepalive link is up or down.
The state of the logical link. This is the state of the link between this
BigIron RX port and the BigIron RX port on the other end of the link. If the states of both Physical Link and Link-keepalive are up, then
Logical link is up. If either or both Physical Link and Link-keepalive states are down, then Logical Link displays "down".
If a port is disabled by UDLD, the change also is indicated in the output of the show interfaces brief command.
Here is an example:
BigIron RX(config)# show interface brief
Port Link State Dupl Speed Trunk Tag Priori MAC Name
1/1 Up LK-DISABLE None None None No level0 00e0.52a9.bb00
1/2 Down None None None None No level0 00e0.52a9.bb01
1/3 Down None None None None No level0 00e0.52a9.bb02
1/4 Down None None None None No level0 00e0.52a9.bb03
If the port was already down before you enabled UDLD for the port, the port’s state is listed as None.
Syntax: show interface brief
The show link-keepalive command shows the following:
BigIron RX(config)# show link-keepalive ethernet
Current State : down Remote MAC Addr : 0000.0000.0000
Local Port : 1/1 Remote Port : n/a
Local System ID : e0eb8e00 Remote System ID : 00000000
Packets sent : 0 Packets received : 0
Transitions : 0
Syntax: show link-keepalive ethernet
November 2005 © 2005 Foundry Networks, Inc.
8-3
Foundry BigIron RX Series Configuration Guide
Displaying Information for a Single Port
To display detailed UDLD information for a specific port, enter a command such as the following:
BigIron RX(config)# show link-keepalive ethernet 4/1
Current State : up Remote MAC Addr : 00e0.52d2.5100
Local Port : 4/1 Remote Port : 2/1
Local System ID : e0927400 Remote System ID : e0d25100
Packets sent : 254 Packets received : 255
Transitions : 1
This Field...
Current State
Remote MAC Addr
Local Port
Remote Port
Local System ID
Remote System ID
Packets sent
Packets received
Transitions
Port blocking
Table 8.2: CLI Display of Detailed UDLD Information
Displays...
The state of the logical link. This is the link between this BigIron RX port and the BigIron RX port on the other end of the link.
The MAC address of the port or device at the remote end of the logical link.
The port number on this BigIron RX.
The port number on the BigIron RX at the remote end of the link.
A unique value that identifies this BigIron RX. The ID can be used by
Foundry technical support for troubleshooting.
A unique value that identifies the BigIron RX at the remote end of the link.
The number of UDLD health-check packets sent on this port.
The number of UDLD health-check packets received on this port.
The number of times the logical link state has changed between up and down.
Information used by Foundry technical support for troubleshooting.
8-4 © 2005 Foundry Networks, Inc.
November 2005
Configuring Uni-Directional Link Detection (UDLD)
The show interface ethernet <slot>/<portnum> command also displays the UDLD state for an individual port. In addition, the line protocol state listed in the first line will say “down” if UDLD has brought the port down. Here is an example:
BigIron RX(config)# show interface ethernet 1/1
GigabitEthernet2/1 is disabled, line protocol is down, link keepalive is enabled
Hardware is GigabitEthernet, address is 000c.dbe2.5900 (bia
000c.dbe2.5900)
Configured speed 1Gbit, actual unknown, configured duplex fdx, actual unknown
Configured mdi mode AUTO, actual unknown
Member of 2 L2 VLANs, port is tagged, port state is Disabled
STP configured to ON, Priority is level7, flow control enabled
Force-DSCP disabled
mirror disabled, monitor disabled
Not member of any active trunks
Not member of any configured trunks
No port name
MTU 1522 bytes, encapsulation ethernet
300 second input rate: 0 bits/sec, 0 packets/sec, 0.00% utilization
300 second output rate: 0 bits/sec, 0 packets/sec, 0.00% utilization
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 multicasts, 0 unicasts
0 input errors, 0 CRC, 0 frame, 0 ignored
0 runts, 0 giants, DMA received 0 packets
0 packets output, 0 bytes, 0 underruns
Transmitted 0 broadcasts, 0 multicasts, 0 unicasts
0 output errors, 0 collisions, DMA transmitted 0 packets
In this example, the port has been brought down by UDLD. Notice that in addition to the information in the first line, the port state on the fourth line of the display is listed as DISABLED.
Clearing UDLD Statistics
To clear UDLD statistics, enter the following command:
BigIron RX# clear link-keepalive statistics
Syntax: clear link-keepalive statistics
This command clears the Packets sent, Packets received, and Transitions counters in the show link keepalive
ethernet <slot>/<portnum> display.
November 2005 © 2005 Foundry Networks, Inc.
8-5
Foundry BigIron RX Series Configuration Guide
8-6 © 2005 Foundry Networks, Inc.
November 2005
Chapter 9
Configuring Virtual LANs (VLANs)
This chapter describes how to configure Virtual LANs (VLANs) on a BigIron RX. Topics include:
•
•
•
“Layer 2 Port-Based VLANs” on page 9-3
•
“Layer 3 Protocol-Based VLANs” on page 9-7
•
“Spanning Tree Protocol (STP) in VLANs” on page 9-9
•
“Trunk Group Ports and VLAN Membership” on page 9-10
•
“Summary of VLAN Configuration Rules” on page 9-10
•
“Configuration Examples of Port-Based and Protocol-Based VLANs” on page 9-11
•
“Virtual Routing Interfaces” on page 9-15
•
“Routing Between VLANs Using Virtual Routing Interfaces” on page 9-16
•
“Configuring VLAN Groups” on page 9-23
•
“Configuring the Same IP Subnet Address on Multiple Port-Based VLANs” on page 9-24
•
“Allocating Memory for More VLANs or Virtual Routing Interfaces” on page 9-27
•
“Configuring Super Aggregated VLANs” on page 9-28
•
“Configuring 802.1q-in-q Tagging” on page 9-34
•
“Hardware Flooding for Layer 2 Multicast and Broadcast Packets” on page 9-42
•
“Unicast Flooding on VLAN Ports” on page 9-43
•
“Displaying VLAN Information” on page 9-43
Types of VLANs
You can configure the following types of VLANs on a BigIron RX:
• Layer 2 port-based VLAN – a set of physical ports that share a common, exclusive Layer 2 broadcast domain
• Layer 3 protocol-based VLANs – a subset of ports within a port-based VLAN that share a common, exclusive broadcast domain for Layer 3 broadcasts of the specified protocol. The following protocol-based VLANs are supported:
November 2005 © 2005 Foundry Networks, Inc.
9-1
Foundry BigIron RX Series Configuration Guide
• IP protocol VLAN
• IPv6 protocol VLANs
• IPX protocol VLAN
• AppleTalk protocol VLAN
• VLANs for other protocols
Default VLAN
By default, all the ports on a BigIron RX are in a single port-based VLAN. This VLAN is called DEFAULT-VLAN and is VLAN number 1. The BigIron RX does not contain any protocol VLANs or IP subnet, IPX network, or
AppleTalk VLANs by default.
Figure 9.1 shows an example of the default Layer 2 port-based VLAN.
Figure 9.1
Default Layer 2 port-based VLAN
DEFAULT-VLAN
VLAN ID = 1
Layer 2 Port-based VLAN
9-2
By default, all ports belong to a single port-based VLAN, DEFAULT-VLAN.
Thus, all ports belong to a single
Layer 2 broadcast domain.
When you configure a port-based VLAN, one of the configuration items you provide is the ports that are in the
VLAN. When you configure the VLAN, the BigIron RX automatically removes the ports that you place in the VLAN from DEFAULT-VLAN. By removing the ports from the default VLAN, the BigIron RX ensures that each port resides in only one Layer 2 broadcast domain.
Some network configurations may require that a port be able to reside in two or more Layer 2 broadcast domains
(port-based VLANs). In this case, you can enable a port to reside in multiple port-based VLANs by tagging the
port. See “IEEE 802.1q Tagging” on page 9-4.
© 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
If your network requires that you use VLAN ID 1 for a user-configured VLAN, you can reassign the default VLAN to another valid VLAN ID.
Assigning a Different VLAN ID to the Default VLAN
The default VLAN is not configurable. If you want to use the default VLAN ID 1 as a configurable VLAN, you can assign a different VLAN ID to the default VLAN. For example, enter the following command:
BigIron RX(config)# default-vlan-id 4094
Syntax: [no] default-vlan-id <vlan-id>
You must specify a VLAN ID that is not already in use. For example, if VLAN 10 exists, do not use “10” as the new
VLAN ID for the default VLAN. Valid VLAN IDs are from 1 – 4094.
NOTE:
Changing the default VLAN name does not change the properties of the default VLAN. Changing the name allows you to use the VLAN ID “1” as a configurable VLAN. Also, VLAN 4092 is a reserved VLAN for BigIron
RX.
Layer 2 Port-Based VLANs
A port-based VLAN is a subset of ports on a BigIron RX that constitutes a Layer 2 broadcast domain.
By default, all the ports on a BigIron RX are members of the default VLAN. Thus, all the ports on the BigIron RX constitute a single Layer 2 broadcast domain. You can configure multiple port-based VLANs. When you configure a port-based VLAN, the BigIron RX automatically removes the ports you add to the VLAN from the default VLAN.
November 2005 © 2005 Foundry Networks, Inc.
9-3
Foundry BigIron RX Series Configuration Guide
Figure 9.2 shows an example of a BigIron RX on which a Layer 2 port-based VLAN has been configured.
Figure 9.2
BigIron RX containing user-defined Layer 2 port-based VLAN
DEFAULT-VLAN
VLAN ID = 1
Layer 2 Port-based VLAN
User-configured port-based VLAN
9-4
A port can belong to only one port-based VLAN, unless you apply 802.1q tagging to the port. 802.1q tagging allows the port to add a four-byte tag field, which contains the VLAN ID, to each packet sent on the port. You also can configure port-based VLANs that span multiple devices by tagging the ports within the VLAN. The tag enables each device that receives the packet to determine the VLAN the packet belongs to. 802.1q tagging applies only to Layer 2 VLANs, not to Layer 3 VLANs.
Since each port-based VLAN is a separate Layer 2 broadcast domain, by default each VLAN runs a separate instance of the Spanning Tree Protocol (STP).
Layer 2 traffic is bridged within a port-based VLAN, and Layer 2 broadcasts are sent to all the ports within the
VLAN.
IEEE 802.1q Tagging
802.1q tagging is an IEEE standard that allows a networking device to add information to a Layer 2 packet in order to identify the VLAN membership of the packet. A BigIron RX tag a packet by adding a four-byte tag to the packet.
The tag contains the tag value, which identifies the data as a tag, and also contains the VLAN ID of the VLAN from which the packet is sent.
• The default tag value is 8100 (hexadecimal). This value comes from the 802.1q specification. You can change this tag value on a global basis on BigIron RX if needed to be compatible with other vendors’ equipment.
• The VLAN ID is determined by the VLAN on which the packet is being forwarded.
the tag for VLANs configured across multiple devices, make sure all the devices support the same tag format.
© 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
Figure 9.3
Packet containing Foundry’s 802.1QVLAN tag
Untagged Packet Format
6 bytes
Destination
Address
6 bytes
Source
Address
6 bytes
Destination
Address
6 bytes
Source
Address
2 bytes
Type
Field
2 bytes
Length
Field
Up to 1500 bytes
Data
Field
Up to 1496 bytes
Data
Field
4 bytes
CRC
Ethernet II
4 bytes
CRC
IEEE 802.3
802.1q Tagged Packet Format
6 bytes
Destination
Address
6 bytes
Source
Address
6 bytes
Destination
Address
6 bytes
Source
Address
2 bytes
Type
Field
2 bytes
Length
Field
Data
Field
Data
Field
Data
Field
Data
Field
4 bytes
CRC
4 bytes
CRC
4 bytes
Ethernet II with 802.1q tag
4 bytes
IEEE 802.3 with 802.1q tag
Octet 1 Octet 2
Tag Protocol Id (TPID)
1 2 3 4
802.1p
(3 bits)
5 6 7 8 Octet 4
VLAN ID (12 bits)
NOTE:
You cannot configure a port to be a member of the default port-based VLAN and another port-based
VLAN at the same time. Once you add a port to a port-based VLAN, the port is no longer a member of the default
VLAN. The port returns to the default VLAN only if you delete the other VLAN(s) that contains the port.
If you configure a VLAN that spans multiple devices, you need to use tagging only if a port connecting one of the devices to the other is a member of more than one port-based VLAN. If a port connecting one device to the other is a member of only a single port-based VLAN, tagging is not required.
If you use tagging on multiple devices, each device must be configured for tagging and must use the same tag value. In addition, the implementation of tagging must be compatible on the devices. The tagging on all BigIron
RX switches is compatible with other Foundry devices.
November 2005 © 2005 Foundry Networks, Inc.
9-5
Foundry BigIron RX Series Configuration Guide
them. Notice that only one of the VLANs requires tagging.
Figure 9.4
VLANs configured across multiple devices
User-configured port-based VLAN
T = 802.1Q tagged port
T
T
T T
Segment 1
T
T
T
Segment 2
9-6
Segment 1
Tagging is required for the ports on Segment 1 because the ports are in multiple port-based VLANs.
Without tagging, a device receiving
VLAN traffic from the other device would not be sure which VLAN the traffic is for.
Segment 2
Tagging is not required for the ports on Segment 2 because each port is in only one port-based VLAN.
Configuring a Port-Based VLAN
To configure a port-based VLAN, enter commands such as the following:
BigIron RX(config)# vlan 2
BigIron RX(config-vlan-2)# untag e 1/9 to 1/16
The commands configure port-based VLAN 2 and add untagged ethernet ports 1/9 through 1/16 to it.
Syntax: vlan <vlan-id> [name <vlan-name>]
Syntax: untagged | tagged ethernet <slot/port> [to <slot/port> | ethernet <slot/port>]
The untag command takes ports from the default VLAN and puts them in the port-based VLAN. (The default
VLAN contains all the ports in the system by default.) The untag command also allows the ports to process packets that do not contain 802.1q tagging.
Configuring Uplink Ports Within a Port-Based VLAN
You can configure a subset of the ports in a port-based VLAN as uplink ports. When you configure uplink ports in a port-based VLAN, the device sends all broadcast and unknown-unicast traffic from a port in the VLAN to the uplink ports, but not to other ports within the VLAN. Thus, the uplink ports provide tighter broadcast control within the VLAN.
For example, if two ports within a port-based VLAN are Gigabit ports attached to the network and the other ports in the VLAN are 10/100 ports attached to clients, you can configure the two ports attached to the network as uplink ports. In this configuration, broadcast and unknown-unicast traffic in the VLAN does not go to all ports in the
VLAN. The traffic goes only to the uplink ports. The clients on the network do not receive broadcast and unknown-unicast traffic from other ports, including other clients.
To configure a port-based VLAN containing uplink ports, enter commands such as the following:
BigIron RX(config)# vlan 10
BigIron RX(config-vlan-10)# untag ethernet 1/1 to 1/24
BigIron RX(config-vlan-10)# untag ethernet 2/1 to 2/2
© 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
BigIron RX(config-vlan-10)# uplink-switch ethernet 2/1 to 2/2
Syntax: [no] uplink-switch ethernet <slot>/<portnum> [to <slot>/<portnum> | ethernet <slot>/<portnum>]
In this example, 24 ports on a 10/100 module and two Gigabit ports on a Gigabit module are added to port-based
VLAN 10. The two Gigabit ports are then configured as uplink ports.
Modifying a Port-Based VLAN
You can make the following modifications to a port-based VLAN:
• Add or remove a port.
• Change its priority.
•
Enable or disable STP. See “IEEE 802.1D Spanning Tree Protocol (STP)” on page 10-1.
Removing a Port from a Port-Based VLAN
To remove a port from a port-based VLAN, enter the commands such as the following:
BigIron RX(config)# vlan 4
BigIron RX(config-vlan-4)# no untag ethernet 1/11
The command removes the untagged port 1/11 from VLAN 4 and puts it in the default VLAN.
Syntax: no untagged | tagged ethernet <slot/port> [to <slot/port> | ethernet <slot/port>]
Assigning or Changing a Priority to a VLAN
You can prioritize traffic on a VLAN by assigning a priority to a VLAN.
BigIron RX(config-vlan-2)# priority 2
Syntax: priority <num>
Possible Values: 0 - 7, "0" assigns the lowest priority and "7", the highest priority. The default is "0".
Removing a Port-Based VLAN
To remove a VLAN, enter a vlan command at the global CONFIG level, such as the following:
BigIron RX(config)# no vlan 5
Syntax: no vlan <vlan-id>
Layer 3 Protocol-Based VLANs
Protocol-based VLANs provide the ability to define separate broadcast domains for Layer 3 protocols such as IP,
IPv6, IPX, AppleTalk, and others, within a single Layer 2 broadcast domain. Some applications for this feature might include security between departments with unique protocol requirements. This feature enables you to limit the amount of broadcast traffic to end-stations, servers, and routers.
If you want some or all of the ports within a port-based VLAN to be organized according to Layer 3 protocol, you must configure a Layer 3 protocol-based VLAN within the port-based VLAN. You can configure the following types of protocol-based VLAN within a port-based VLAN. All the ports in the Layer 3 VLAN must be in the same Layer 2
VLAN.
• AppleTalk – The device sends AppleTalk broadcasts to all ports within the AppleTalk protocol VLAN.
• IP – The device sends IP broadcasts to all ports within the IP protocol VLAN.
• IPv6 – a subset of ports in a port-based VLAN that share a common, exclusive network broadcast domain for
IPv6 packets The device sends IPv6 broadcasts to all ports within the IPv6 protocol VLAN.
• IPX – The device sends IPX broadcasts to all ports within the IPX protocol VLAN.
• Other – The device sends broadcasts for all protocol types other than those listed above to all ports within the
November 2005 © 2005 Foundry Networks, Inc.
9-7
Foundry BigIron RX Series Configuration Guide
VLAN.
You can configure a protocol-based VLAN as a broadcast domain for IPv6 traffic. When the BigIron RX receives an IPv6 multicast packet (a packet with 06 in the version field and 0xFF as the beginning of the destination address), the BigIron RX forwards the packet to all other ports in the VLAN.
NOTE:
The BigIron RX forwards all IPv6 multicast packets to all ports in the VLAN except the port that received the packet, and does not distinguish among subnet directed multicasts.
Figure 9.5 shows a Layer 3 protocol-based VLANs configured within a Layer 2 port-based VLAN.
Figure 9.5
Layer 3 protocol VLANs within a Layer 2 port-based VLAN
DEFAULT-VLAN
VLAN ID = 1
Layer 2 Port-based VLAN
User-configured port-based VLAN
User-configured protocol VLAN
9-8
Layer 3 protocol-based VLANs cannot span Layer 2 port-based VLANS.
However, Layer 3 protocol-based VLANs can overlap within a Layer 2 port-based VLAN.
Static and Excluded Port Membership
Protocol-based VLANs have the following membership types:
• Static ports
• Excluded ports
© 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
All ports must be explicitly designated as static ports or excluded from a VLAN.
Static Ports
Static ports are permanent members of a protocol-based VLAN; they never age out. They remain active members of the protocol-based VLAN regardless of whether they receive traffic for the VLAN’s protocol.
To add static ports to a protocol-based VLAN, you explicitly identify ports as static when you configure a protocolbased VLAN.
Excluded Ports
To prevent a port in a port-based VLAN from becoming a member of a protocol VLAN, you can explicitly exclude the port when you configure the protocol-based VLAN.
Excluded ports do not leak broadcast packets.
Configuring Protocol-Based VLANs
The following example configures IP protocol, IPv6 protocol, and other-protocol VLANs within a port-based VLAN.
Although AppleTalk and IPX protocol VLANs are not part of the example, the configuration steps are alike.
To configure IP, IPv6, and other protocol VLANs, enter commands as shown in the following:
1.
Create a port-based VLAN and assign untagged and tagged ports to it.
BigIron RX(config)# vlan 2
BigIron RX(config-vlan-2)# untag e 1/1 to 1/8
BigIron RX(config-vlan-2)# tag e 1/24
2.
Enable STP and set the priority to make the device the root bridge for the port-based VLAN 2.
BigIron RX(config-vlan-2)# spanning-tree
BigIron RX(config-vlan-2)# spanning-tree priority 500
3.
Create the IP and IPv6 protocol VLANs and assign static ports to them.
BigIron RX(config-vlan-2)# ip-proto name Gray
BigIron RX(config-vlan-group-ip-proto)# static e 1/1 to 1/4 e 1/24
BigIron RX(config-vlan-group-ip-proto)# exclude e 1/5 to 1/8
BigIron RX(config-vlan-group-ip-proto)# ipv6-proto name Blue
BigIron RX(config-vlan-group-ipv6-proto)# static e 1/1 e 1/24
BigIron RX(config-vlan-group-ipv6-proto)# exclude e 1/2 to 1/4
4.
To prevent machines with non-IP and non-IPv6 protocols from getting into VLAN 2, create another protocol
VLAN to exclude all other protocols from VLAN 2. To do so, enter the following commands:
BigIron RX(config-vlan-group-ipx-proto)# other-proto name Block_other_proto
BigIron RX(config-vlan-group-other-proto)# exclude e 1/1 to 1/8 e 1/24
BigIron RX(config-vlan-group-other-proto)#
Syntax: ip-proto | ipv6-proto | ipx-proto | atalk-proto | other-proto [<protocol-vlan-name>]
[static | exclude ethernet <slot/port> [to <slot/port>] [router-interface ve <num>]
The static ethernet <slot/port> [to <slot/port>] parameter adds the specified port(s) within the port-based VLAN as static port(s) to the protocol VLAN.
The exclude ethernet <slot/port> [to <slot/port>] parameter excludes the specified port(s) from the protocol
VLAN.
The router-interface ve <num> parameter adds a configured virtual routing interface to the protocol VLAN.
Spanning Tree Protocol (STP) in VLANs
STP is a Layer 2 protocol. Thus, you cannot enable or disable STP for individual protocol VLANs. The STP state of a port-based VLAN determines the STP state for all the Layer 2 broadcasts within the port-based VLAN. This is true even though Layer 3 protocol broadcasts are sent on Layer 2 within the VLAN.
November 2005 © 2005 Foundry Networks, Inc.
9-9
Foundry BigIron RX Series Configuration Guide
It is possible that STP will block one or more ports in a protocol VLAN that uses a virtual routing interface to route to other VLANs. For IP protocol and IP subnet VLANs, even though some of the physical ports of the virtual routing interface are blocked, the virtual routing interface can still route so long as at least one port in the virtual routing interface’s protocol VLAN is not blocked by STP.
If you enable Single STP (SSTP) on the device, the ports in all VLANs on which STP is enabled become members of a single spanning tree. The ports in VLANs on which STP is disabled are excluded from the single spanning tree.
For more information, see “Configuring Spanning Tree Protocol” .
Trunk Group Ports and VLAN Membership
A trunk group is a set of physical ports that are configured to act as a single physical interface. Each trunk group’s port configuration is based on the configuration of the lead port, which is the lowest numbered port in the group.
If you add a trunk port to a VLAN, all of the ports in the trunk group become members of that VLAN.
Assigning Trunk Group Ports
When a trunk group port is assigned to a VLAN, all other members of the trunk group are automatically added to
that VLAN. See “Trunk Group Rules” on page 6-2 for more information.
Summary of VLAN Configuration Rules
VLAN Hierarchy
A hierarchy of VLANs exists between the Layer 2 and Layer 3 protocol-based VLANs:
• Port-based VLANs are at the lowest level of the hierarchy.
• Layer 3 protocol-based VLANs, IP, IPv6, IPX, AppleTalk, Decnet, and NetBIOS are at the middle level of the hierarchy.
NOTE:
You cannot have a protocol-based VLAN and a subnet or network VLAN of the same protocol type in the same port-based VLAN. For example, you can have an IPX protocol VLAN and IP subnet VLAN in the same portbased VLAN, but you cannot have an IP protocol VLAN and an IP subnet VLAN in the same port-based VLAN, nor can you have an IPX protocol VLAN and an IPX network VLAN in the same port-based VLAN.
As a BigIron RX receives packets, the VLAN classification starts from the highest level VLAN first. Therefore, if an interface is configured as a member of both a port-based VLAN and an IP protocol VLAN, IP packets coming into the interface are classified as members of the IP protocol VLAN because that VLAN is higher in the VLAN hierarchy.
When a port of a VLAN on a BigIron RX receives a packet, the device forwards the packet based on the following
VLAN hierarchy:
• If the port belongs to an IP subnet VLAN, IPX network VLAN, or AppleTalk protocol VLAN and the packet belongs to the corresponding IP subnet, IPX network, or AppleTalk protocol range, the device forwards the packet to all the ports within that VLAN.
• If the packet is a Layer 3 packet but cannot be forwarded as described above, but the port is a member of a
Layer 3 protocol VLAN for the packet’s protocol, the device forwards the packet on all the Layer 3 protocol
VLAN’s ports.
• If the packet cannot be forwarded based on either of the VLAN membership types listed above, but the packet can be forwarded at Layer 2, the device forwards the packet on all the ports within the receiving port’s portbased VLAN.
Multiple VLAN Membership Rules
• A port can belong to multiple, unique, overlapping Layer 3 protocol-based VLANs.
9-10 © 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
• A port can belong to multiple, overlapping Layer 2 port-based VLANs only if the port is a tagged port. Packets sent out of a tagged port use an 802.1q-tagged frame.
• When both port and protocol-based VLANs are configured on a given device, all protocol VLANs must be strictly contained within a port-based VLAN. A protocol VLAN cannot include ports from multiple port-based
VLANs. This rule is required to ensure that port-based VLANs remain loop-free Layer 2 broadcast domains.
• IP protocol VLANs and IP subnet VLANs cannot operate concurrently on the system or within the same portbased VLAN.
• One of each type of protocol VLAN is configurable within each port-based VLAN on the BigIron RX.
• Removing a configured port-based VLAN from a BigIron RX automatically removes any protocol-based
VLAN, IP subnet VLAN, or IPX network VLAN, or any virtual Ethernet router interfaces defined within the port-based VLAN.
Configuration Considerations
Note the following configuration limitations:
• The dynamic protocol VLAN option is not supported.
• The other-protocol option defines a protocol-based VLAN for protocols that do not require a singular protocol broadcast domain or are not currently supported on the Foundry device. It is used as a catch-all rule to mean all other protocols in addition to those already assigned.
For example, in the following VLAN configuration, IP protocol is defined and the "other-proto" option is set to become operational when a non-IPv4 packet is received.
BigIron RX(config)#vlan 5
BigIron RX(config-vlan-5)#ip-proto
BigIron RX(config-vlan-5)#other-proto
Configuration Examples of Port-Based and Protocol-Based VLANs
Configuring Port-Based VLANs
Port-based VLANs allow you to provide separate spanning tree protocol (STP) domains or broadcast domains on a port-by-port basis.
EXAMPLE:
are untagged. One untagged port within each VLAN is used to connect the BigIron RX for Layer 3 connectivity between the two port-based VLANs.
November 2005 © 2005 Foundry Networks, Inc.
9-11
Foundry BigIron RX Series Configuration Guide
Figure 9.6
Port-based VLANs 222 and 333
BigIron RX interface e 1
IP Subnet 1
IPX Network 1
Appletalk ZonePrepress interface e 2
IP Subnet 2
IPX Network 2
Appletalk Zone CTP
VLAN 222
Ports 1 - 8
Port 1
BigIron RX
Port 9
VLAN 333
Ports 9 - 16
Ports 2 - 8
IP Subnet 1
IPX Network 1
Appletalk ZonePrepress
Ports 9 - 16
IP Subnet 2
IPX Network 2
Appletalk Zone CTP
To create the two port-based VLANs shown in Figure 9.6, use the following commands:
BigIron RX(config)# vlan 222 by port
BigIron RX(config-vlan-222)# untag e 1/1 to 1/8
BigIron RX(config-vlan-222)# vlan 333 by port
BigIron RX(config-vlan-333)# untag e 1/9 to 1/16
Syntax: vlan <vlan-id> by port
Syntax: untagged ethernet <slot>/<portnum> [to <slot>/<portnum> | ethernet <slot>/<portnum>]
EXAMPLE:
802.1q VLAN tagging. The backbone link connecting the three BigIron RX is tagged. One untagged port within each port-based VLAN BigIron RX A connects each separate network wide Layer 2 broadcast domain to the router for Layer 3 forwarding between broadcast domains. The STP priority is configured to force BigIron RX to be the root bridge for VLANs RED and BLUE. The STP priority on BigIron RX B is configured so that BigIron RX B is the root bridge for VLANs GREEN and BROWN.
9-12 © 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
Figure 9.7
More complex port-based VLAN
VLAN “BROWN”
VLAN “GREEN”
= STP blocked VLAN
IP sub-net 1
IPX network 1
Atalk 100.1
Zone “A” port 1/4
BigIron RX
BigIron RX
IP sub-net 2
IPX network 2
Atalk 200.1
Zone “B” port 1/5
Root Bridge for
VLAN “BROWN”
VLAN 2
“BROWN”
Ports 1/1 - 1/3
IP sub 1
IPX net 1
Atalk 100
Zone “A”
VLAN 3
“GREEN”
Ports 1/6 - 1/8
IP sub 2
IPX net 2
Atalk 200
Zone “B”
BigIron RX
Root Bridge for
VLAN “GREEN”
BigIron RX
VLAN 2
“BROWN”
Ports 1/1 - 1/3
IP sub 1
IPX net 1
Atalk 100
Z “A”
VLAN 3
“GREEN”
Ports 1/6 - 1/8
IP sub 2
IPX net 2
Atalk 200
Zone “B”
VLAN 2
“BROWN”
Ports 1/1 - 1/3
IP sub 1
IPX net 1
Atalk 100
Z “A”
To configure the Port-based VLANs on the BigIron RX, use the following method.
Configuring BigIron RX-A
Enter the following commands to configure BigIron RX-A:
BigIron RX> enable
BigIron RX# configure terminal
BigIron RX(config)# hostname BigIron RX-A
BigIron RX-A(config)# vlan 2 name BROWN
BigIron RX-A(config-vlan-2)# untag ethernet 1/1 to 1/4 ethernet 1/17
BigIron RX-A(config-vlan-2)# tag ethernet 1/25 to 1/26
BigIron RX-A(config-vlan-2)# spanning-tree
BigIron RX-A(config-vlan-2)# vlan 3 name GREEN
BigIron RX-A(config-vlan-3)# untag ethernet 1/5 to 1/8 ethernet 1/18
BigIron RX-A(config-vlan-3)# tag ethernet 1/25 to 1/26
BigIron RX-A(config-vlan-3)# spanning-tree
BigIron RX-A(config-vlan-3)# vlan 4 name BLUE
BigIron RX-A(config-vlan-4)# untag ethernet 1/9 to 1/12 ethernet 1/19
BigIron RX-A(config-vlan-4)# tag ethernet 1/25 to 1/26
BigIron RX-A(config-vlan-4)# spanning-tree
BigIron RX-A(config-vlan-4)# spanning-tree priority 500
BigIron RX-A(config-vlan-4)# vlan 5 name RED
BigIron RX-A(config-vlan-5)# untag ethernet 1/13 to 1/16 ethernet 1/20
VLAN 3
“GREEN”
Ports 1/6 - 1/8
IP sub 2
IPX net 2
Atalk 200
Z “B”
November 2005 © 2005 Foundry Networks, Inc.
9-13
Foundry BigIron RX Series Configuration Guide
BigIron RX-A(config-vlan-5)# tag ethernet 1/25 to 1/26
BigIron RX-A(config-vlan-5)# spanning-tree
BigIron RX-A(config-vlan-5)# spanning-tree priority 500
BigIron RX-A(config-vlan-5)# end
BigIron RX-A# write memory
Configuring BigIron RX-B
Enter the following commands to configure BigIron RX-B:
BigIron RX> en
BigIron RX# configure terminal
BigIron RX(config)# hostname BigIron RX-B
BigIron RX-B(config)# vlan 2 name BROWN
BigIron RX-B(config-vlan-2)# untag ethernet 1/1 to 1/4
BigIron RX-B(config-vlan-2)# tag ethernet 1/25 to 1/26
BigIron RX-B(config-vlan-2)# spanning-tree
BigIron RX-B(config-vlan-2)# spanning-tree priority 500
BigIron RX-B(config-vlan-2)# vlan 3 name GREEN
BigIron RX-B(config-vlan-3)# untag ethernet 1/5 to 1/8
BigIron RX-B(config-vlan-3)# tag ethernet 1/25 to 1/26
BigIron RX-B(config-vlan-3)# spanning-tree
BigIron RX-B(config-vlan-3)# spanning-tree priority 500
BigIron RX-B(config-vlan-3)# vlan 4 name BLUE
BigIron RX-B(config-vlan-4)# untag ethernet 1/9 to 1/12
BigIron RX-B(config-vlan-4)# tag ethernet 1/25 to 1/26
BigIron RX-B(config-vlan-4)# vlan 5 name RED
BigIron RX-B(config-vlan-5)# untag ethernet 1/13 to 1/16
BigIron RX-B(config-vlan-5)# tag ethernet 1/25 to 1/26
BigIron RX-B(config-vlan-5)# end
BigIron RX-B# write memory
Configuring BigIron RX-C
Enter the following commands to configure BigIron RX-C:
BigIron RX> en
BigIron RX# configure terminal
BigIron RX(config)# hostname BigIron RX-C
BigIron RX-C(config)# vlan 2 name BROWN
BigIron RX-C(config-vlan-2)# untag ethernet 1/1 to 1/4
BigIron RX-C(config-vlan-2)# tag ethernet 1/25 to 1/26
BigIron RX-C(config-vlan-2)# vlan 3 name GREEN
BigIron RX-C(config-vlan-3)# untag ethernet 1/5 to 1/8
BigIron RX-C(config-vlan-3)# tag ethernet 1/25 to 1/26
BigIron RX-C(config-vlan-3)# vlan 4 name BLUE
BigIron RX-C(config-vlan-4)# untag ethernet 1/9 to 1/12
BigIron RX-C(config-vlan-4)# tag ethernet 1/25 to 1/26
BigIron RX-C(config-vlan-4)# vlan 5 name RED
BigIron RX-C(config-vlan-5)# untag ethernet 1/13 to 1/16
BigIron RX-C(config-vlan-5)# tag ethernet 1/25 to 1/26
BigIron RX-C(config-vlan-5)# end
BigIron RX-C# write memory
Syntax: vlan <vlan-id> by port
Syntax: untagged ethernet <slot>/<portnum> [to <slot>/<portnum> | ethernet <slot>/<portnum>]
Syntax: tagged ethernet <slot>/<portnum> [to <slot>/<portnum> | ethernet <slot>/<portnum>]
Syntax: [no] spanning-tree
9-14 © 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
Syntax: spanning-tree [ethernet <slot>/<portnum> path-cost <value> priority <value>] forward-delay <value> hello-time <value> maximum-age <time> priority <value>
Virtual Routing Interfaces
The BigIron RX sends Layer 3 traffic at Layer 2 within a protocol VLAN. However, Layer 3 traffic from one protocol
VLAN to another must be routed. If you want the device to be able to send Layer 3 traffic from one protocol VLAN to another, you must configure a virtual routing interface on each protocol VLAN, then configure routing parameters on the virtual routing interfaces.
A virtual routing interface is a logical routing interface that the BigIron RX uses to route Layer 3 protocol traffic between protocol VLANs. It is a logical port on which you can configure Layer 3 routing parameters.
For example, to enable a BigIron RX to route IP traffic from one IP protocol VLAN to another, you must configure a virtual routing interface on each IP protocol VLAN, then configure the appropriate IP routing parameters on each of the virtual routing interfaces.
Figure 9.8
Use virtual routing interfaces for routing between Layer 3 protocol VLANs
User-configured port-based VLAN
User-configured protocol VLAN, IP sub-net VLAN,
IPX network VLAN, or AppleTalk cable VLAN
VE = virtual interface
(”VE” stands for “Virtual Ethernet”)
VE 3
VE 1
VE 2
VE 4
November 2005
Layer 2 and Layer 3 traffic within a VLAN is bridged at Layer 2.
Layer 3 traffic between protocol VLANs is routed using virtual interfaces (VE).
To route to one another, each protocol
VLAN must have a virtual interface.
© 2005 Foundry Networks, Inc.
9-15
Foundry BigIron RX Series Configuration Guide
Integrated Switch Routing (ISR)
Foundry Networks’ Integrated Switch Routing (ISR) feature enables VLANs configured on the BigIron RX to route Layer 3 traffic from one protocol VLAN or IP subnet, IPX network, or AppleTalk protocol VLAN to another.
Normally, to route traffic from one IP subnet, IPX network, or AppleTalk protocol VLAN to another, you would need to forward the traffic to an external router. The VLANs provide Layer 3 broadcast domains for these protocols but do not in themselves provide routing services for these protocols. This is true even if the source and destination IP subnets, IPX networks, or AppleTalk protocol ranges are on the same device.
ISR eliminates the need for an external router by allowing you to route between VLANs using virtual routing interfaces (ves). You configure a separate virtual routing interface on each VLAN that you want to be able to route from or to. For example, if you configure two IP subnet VLANs on a BigIron RX, you can configure a virtual routing interface on each VLAN, then configure IP routing parameters for the subnets. Thus, the BigIron RX forwards IP subnet broadcasts within each VLAN at Layer 2 but routes Layer 3 traffic between the VLANs using the virtual routing interfaces.
NOTE:
The BigIron RX uses the lowest MAC address on the device (the MAC address of port 1 or 1/1) as the
MAC address for all ports within all virtual routing interfaces you configure on the device.
The routing parameters and the syntax for configuring them are the same as when you configure a physical interface for routing. The logical interface allows the BigIron RX to internally route traffic between the protocolbased VLANs without using physical interfaces.
All the ports within a protocol-based VLAN must be in the same port-based VLAN. The protocol-based VLAN cannot have ports in multiple port-based VLANs, unless the ports in the port-based VLAN to which you add the protocol-based VLAN are 802.1q tagged.
You can configure multiple protocol-based VLANs within the same port-based VLAN. In addition, a port within a port-based VLAN can belong to multiple protocol-based VLANs of the same type or different types. For example, if you have a port-based VLAN that contains ports 1 – 10, you can configure port 5 as a member of an AppleTalk protocol VLAN, an IP protocol VLAN, and an IPX protocol VLAN, and so on.
Routing Between VLANs Using Virtual Routing Interfaces
Routing Between VLANs
The BigIron RX can locally route IP between VLANs defined within a single router. All other routable protocols or protocol VLANs (for example, IPX and AppleTalk) must be routed by another external router capable of routing the protocol.
Virtual Routing Interfaces
You need to configure virtual routing interfaces if an IP, IPX, or AppleTalk protocol VLAN, IP subnet VLAN,
AppleTalk protocol VLAN, or IPX network VLAN needs to route protocols to another port-based VLAN on the same router. A virtual routing interface can be associated with the ports in only a single port-based VLAN. Virtual router interfaces must be defined at the highest level of the VLAN hierarchy.
If you do not need to further partition the port-based VLAN by defining separate Layer 3 VLANs, you can define a single virtual routing interface at the port-based VLAN level and enable IP, IPX, and Appletalk routing on a single virtual routing interface.
Bridging and Routing the Same Protocol Simultaneously on the Same Device
Some configurations may require simultaneous switching and routing of the same single protocol across different sets of ports on the same router. When IP, IPX, or Appletalk routing is enabled on a BigIron RX, you can route these protocols on specific interfaces while bridging them on other interfaces. In this scenario, you can create two separate backbones for the same protocol, one bridged and one routed.
To bridge IP, IPX, or Appletalk at the same time these protocols are being routed, you need to configure an IP protocol, IPX protocol, or Appletalk protocol VLAN and not assign a virtual routing interface to the VLAN. Packets for these protocols are bridged or switched at Layer 2 across ports on the router that are included in the Layer 3
VLAN. If these VLANs are built within port-based VLANs, they can be tagged across a single set of backbone
9-16 © 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs) fibers to create separate Layer 2 switched and Layer 3 routed backbones for the same protocol on a single physical backbone.
Routing Between VLANs Using Virtual Routing Interfaces
Foundry calls the ability to route between VLANs with virtual routing interfaces Integrated Switch Routing (ISR).
There are some important concepts to understand before designing an ISR backbone.
Virtual router interfaces can be defined on port-based, IP protocol, IP subnet, IPX protocol, IPX network, and
AppleTalk protocol VLANs.
To create any type of VLAN on a BigIron RX, Layer 2 forwarding must be enabled. When Layer 2 forwarding is enabled, the BigIron RX becomes a Switch on all ports for all non-routable protocols.
If the router interfaces for IP, IPX, or AppleTalk are configured on physical ports, then routing occurs independent of the Spanning Tree Protocol (STP). However, if the router interfaces are defined for any type VLAN, they are virtual routing interfaces and are subject to the rules of STP.
If your backbone is consisted of virtual routing interfaces all within the same STP domain, it is a bridged backbone, not a routed one. This means that the set of backbone interfaces that are blocked by STP will be blocked for routed protocols as well. The routed protocols will be able to cross these paths only when the STP state of the link is FORWARDING. This problem is easily avoided by proper network design.
When designing an ISR network, pay attention to your use of virtual routing interfaces and the spanning-tree domain. If Layer 2 switching of your routed protocols (IP, IPX, AppleTalk) is not required across the backbone, then the use of virtual routing interfaces can be limited to edge switch ports within each router. Full backbone routing can be achieved by configuring routing on each physical interface that connects to the backbone. Routing is independent of STP when configured on a physical interface.
If your ISR design requires that you switch IP, IPX, or Appletalk at Layer 2 while simultaneously routing the same protocols over a single backbone, then create multiple port-based VLANs and use VLAN tagging on the backbone links to separate your Layer 2 switched and Layer 3 routed networks.
There is a separate STP domain for each port-based VLAN. Routing occurs independently across port-based
VLANs or STP domains. You can define each end of each backbone link as a separate tagged port-based VLAN.
Routing will occur independently across the port-based VLANs. Because each port-based VLAN’s STP domain is a single point-to-point backbone connection, you are guaranteed to never have an STP loop. STP will never block the virtual router interfaces within the tagged port-based VLAN, and you will have a fully routed backbone.
A BigIron RX offers the ability to create a virtual routing interface within a Layer 2 STP port-based VLAN or within each Layer 3 protocol, IP subnet, or IPX network VLAN. This combination of multiple Layer 2 and/or Layer 3 broadcast domains and virtual routing interfaces are the basis for Foundry Networks’ very powerful Integrated
Switch Routing (ISR) technology. ISR is very flexible and can solve many networking problems. The following example is meant to provide ideas by demonstrating some of the concepts of ISR.
Example: Suppose you want to move routing out to each of three buildings in a network. Remember that the only protocols present on VLAN 2 and VLAN 3 are IP and IPX. Therefore, you can eliminate tagged ports 25 and 26 from both VLAN 2 and VLAN 3 and create new tagged port-based VLANs to support separate IP subnets and IPX networks for each backbone link.
You also need to create unique IP subnets and IPX networks within VLAN 2 and VLAN 3 at each building. This will create a fully routed IP and IPX backbone for VLAN 2 and VLAN 3. However, VLAN 4 has no protocol restrictions across the backbone. In fact there are requirements for NetBIOS and DecNet to be bridged among the three building locations. The IP subnet and IPX network that exists within VLAN 4 must remain a flat Layer 2 switched STP domain. You enable routing for IP and IPX on a virtual routing interface only on BigIron RX-A. This will provide the flat IP and IPX segment with connectivity to the rest of the network. Within VLAN 4 IP and IPX will follow the STP topology. All other IP subnets and IPX networks will be fully routed and have use of all paths at all times during normal operation.
Figure 9.9 shows the configuration described above.
November 2005 © 2005 Foundry Networks, Inc.
9-17
Foundry BigIron RX Series Configuration Guide
Figure 9.9
Routing between protocol-based VLANs
VLAN 2
VLAN 3
VLAN 4
VLAN 5
VLAN 6
VLAN 7
VLAN 8
= STP blocked VLAN
BigIron RX-A
VLAN 2
Ports 1 - 4
VE 1
-IP sub-net 2
-OSPF area 0.0.0.0
VLAN 8
Ports 5 - 8
VE 2
-IPX network 2
VLAN 3
Ports 9 - 16
IP sub-net 1 (ports 9 - 12, VE 3)
IPX network 1 (ports 13 - 16, VE 4)
VE 3
-IP sub-net 1
-OSPF area 0.0.0.0
VE 4
-IPX network 1
VLAN 4
Ports 17 - 24 (untagged)
Ports 25 - 26 (tagged)
VE 5
-IP sub-net 3
-OSPF area 0.0.0.0
-IPX network 3
VLAN 5
Port 25 (tagged)
VE 6
-IP sub-net 4
-OSPF area 0.0.0.0
-IPX network 4
VLAN 6
Port 26 (tagged)
VE 7
-IP sub-net 5
-OSPF 0.0.0.0
-IPX network 5
VE 4, VE 6
VE 4, VE 5
BigIron RX-B
VLAN 2
Ports 1 - 4
VE 1
-IP sub-net 6
VLAN 8
Ports 5 - 8
VE 2
-IPX network 6
VLAN 3
Ports 9 - 16
IP sub-net 7 (ports 9 - 12, VE 3)
IPX network 7 (ports 13 - 16, VE 4)
VE 3
-IP sub-net 7
-OSPF area 0.0.0.0
VE 4
-IPX network 7
VLAN 4
Ports 17 - 24 (untagged)
Ports 25 - 26 (tagged)
VLAN 5
Port 25 (tagged)
VE 5
-IP sub-net 4
-OSPF area 0.0.0.0
-IPX network 4
VLAN 7
Port 26 (tagged)
VE 6
-IP sub-net 8
-IPX network 8
VE 4, VE 7
(STP is blocking VE 4)
BigIron RX-C
VLAN 2
Ports 1 - 4
VE 1
-IP sub-net 9
-OSPF area 0.0.0.0
VLAN 8
Ports 5 - 8
VE 2
-IPX network 9
VLAN 3
Ports 9 - 16
IP sub-net 10 (ports 9 - 12, VE 3)
IPX network 10 (ports 13 - 16, VE 4)
VE 3
-IP sub-net 10
-OSPF area 0.0.0.0
VE 4
-IPX network 10
VLAN 4
Ports 17 - 24 (untagged)
Ports 25 - 26 (tagged)
VLAN 7
Port 25 (tagged)
VE 5
-IP sub-net 8
-OSPF area 0.0.0.0
-IPX network 8
VLAN 6
Port 26 (tagged)
VE 6
-IP sub-net 5
-OSPF area 0.0.0.0
-IPX network 5
9-18
To configure the Layer 3 VLANs and virtual routing interfaces on the BigIron RX, use the following procedure.
Configuring BigIron RX-A
Enter the following commands to configure BigIron RX-A. The following commands enable OSPF or RIP routing and IPX routing.
BigIron RX> en
© 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
No password has been assigned yet...
BigIron RX# configure terminal
BigIron RX(config)# hostname BigIron RX-A
BigIron RX-A(config)# router ospf
BigIron RX-A(config-ospf-router)# area 0.0.0.0 normal
BigIron RX-A(config-ospf-router)# router ipx
ipx routing enabled for next power cycle.
Please save configuration to flash and reboot.
BigIron RX-A(config-ospf-router)#
The following commands create the port-based VLAN 2. In the previous example, an external BigIron RX defined the router interfaces for VLAN 2. With ISR, routing for VLAN 2 is done locally within each BigIron RX. Therefore, there are two ways you can solve this problem. One way is to create a unique IP subnet and IPX network VLAN, each with its own virtual routing interface and unique IP or IPX address within VLAN 2 on each BigIron RX. In this example, this is the configuration used for VLAN 3. The second way is to split VLAN 2 into two separate portbased VLANs and create a virtual router interface within each port-based VLAN. Later in this example, this second option is used to create a port-based VLAN 8 to show that there are multiple ways to accomplish the same task with ISR.
You also need to create the Other-Protocol VLAN within port-based VLAN 2 and 8 to prevent unwanted protocols from being Layer 2 switched within port-based VLAN 2 or 8. Note that the only port-based VLAN that requires
STP in this example is VLAN 4. You will need to configure the rest of the network to prevent the need to run STP.
BigIron RX-A(config-ospf-router)# vlan 2 name IP-Subnet_1.1.2.0/24
BigIron RX-A(config-vlan-2)# untag e 1/1 to 1/4
BigIron RX-A(config-vlan-2)# no spanning-tree
BigIron RX-A(config-vlan-2)# router-interface ve1
BigIron RX-A(config-vlan-2)# other-proto name block_other_protocols
BigIron RX-A(config-vlan-other-proto)# exclude e 1/1 to 1/4
Once you have defined the port-based VLAN and created the virtual routing interface, you need to configure the virtual routing interface just as you would configure a physical interface.
BigIron RX-A(config-vlan-other-proto)# interface ve1
BigIron RX-A(config-vif-1)# ip address 1.1.2.1/24
BigIron RX-A(config-vif-1)# ip ospf area 0.0.0.0
Do the same thing for VLAN 8.
BigIron RX-A(config-vif-1)# vlan 8 name IPX_Network2
BigIron RX-A(config-vlan-8)# untag ethernet 1/5 to 1/8
BigIron RX-A(config-vlan-8)# no spanning-tree
BigIron RX-A(config-vlan-8)# router-interface ve 2
BigIron RX-A(config-vlan-8)# other-proto name block-other-protocols
BigIron RX-A(config-vlan-other-proto)# exclude ethernet 1/5 to 1/8
BigIron RX-A(config-vlan-other-proto)# int ve2
BigIron RX-A(config-vif-2)# ipx network 2 ethernet_802.3
BigIron RX-A(config-vif-2)#
The next thing you need to do is create VLAN 3. This is very similar to the previous example with the addition of virtual routing interfaces to the IP subnet and IPX network VLANs. Also there is no need to exclude ports from the
IP subnet and IPX network VLANs on the router.
BigIron RX-A(config-vif-2)# vlan 3 name IP_Sub_&_IPX_Net_VLAN
BigIron RX-A(config-vlan-3)# untag e 1/9 to 1/16
BigIron RX-A(config-vlan-3)# no spanning-tree
BigIron RX-A(config-vlan-3)# ip-subnet 1.1.1.0/24
BigIron RX-A(config-vlan-ip-subnet)# static e 1/9 to 1/12
BigIron RX-A(config-vlan-ip-subnet)# router-interface ve3
BigIron RX-A(config-vlan-ip-subnet)# ipx-network 1 ethernet_802.3
BigIron RX-A(config-vlan-ipx-network)# static e 1/13 to 1/16
BigIron RX-A(config-vlan-ipx-network)# router-interface ve4
BigIron RX-A(config-vlan-ipx-network)# other-proto name block-other-protocols
November 2005 © 2005 Foundry Networks, Inc.
9-19
Foundry BigIron RX Series Configuration Guide
9-20
BigIron RX-A(config-vlan-other-proto)# exclude e 1/9 to 1/16
BigIron RX-A(config-vlan-other-proto)# interface ve 3
BigIron RX-A(config-vif-3)# ip addr 1.1.1.1/24
BigIron RX-A(config-vif-3)# ip ospf area 0.0.0.0
BigIron RX-A(config-vif-3)# int ve4
BigIron RX-A(config-vif-4)# ipx network 1 ethernet_802.3
BigIron RX-A(config-vif-4)#
Now configure VLAN 4. Remember this is a flat segment that, in the previous example, obtained its IP default gateway and IPX router services from an external BigIron RX. In this example, BigIron RX-A will provide the routing services for VLAN 4. You also want to configure the STP priority for VLAN 4 to make BigIron RX-A the root bridge for this VLAN.
BigIron RX-A(config-vif-4)# vlan 4 name Bridged_ALL_Protocols
BigIron RX-A(config-vlan-4)# untag ethernet 1/17 to 1/24
BigIron RX-A(config-vlan-4)# tag ethernet 1/25 to 1/26
BigIron RX-A(config-vlan-4)# spanning-tree
BigIron RX-A(config-vlan-4)# spanning-tree priority 500
BigIron RX-A(config-vlan-4)# router-interface ve5
BigIron RX-A(config-vlan-4)# int ve5
BigIron RX-A(config-vif-5)# ip address 1.1.3.1/24
BigIron RX-A(config-vif-5)# ip ospf area 0.0.0.0
BigIron RX-A(config-vif-5)# ipx network 3 ethernet_802.3
BigIron RX-A(config-vif-5)#
It is time to configure a separate port-based VLAN for each of the routed backbone ports (Ethernet 25 and 26).
If you do not create a separate tagged port-based VLAN for each point-to-point backbone link, you need to include tagged interfaces for Ethernet 25 and 26 within VLANs 2, 3, and 8. This type of configuration makes the entire backbone a single STP domain for each VLAN 2, 3, and 8. In this scenario, the virtual routing interfaces within port-based VLANs 2, 3, and 8 will be accessible using only one path through the network. The path that is blocked by STP is not available to the routing protocols until it is in the STP FORWARDING state.
BigIron RX-A(config-vif-5)# vlan 5 name Rtr_BB_to_Bldg.2
BigIron RX-A(config-vlan-5)# tag e 1/25
BigIron RX-A(config-vlan-5)# no spanning-tree
BigIron RX-A(config-vlan-5)# router-interface ve6
BigIron RX-A(config-vlan-5)# vlan 6 name Rtr_BB_to_Bldg.3
BigIron RX-A(config-vlan-6)# tag ethernet 1/26
BigIron RX-A(config-vlan-6)# no spanning-tree
BigIron RX-A(config-vlan-6)# router-interface ve7
BigIron RX-A(config-vlan-6)# int ve6
BigIron RX-A(config-vif-6)# ip addr 1.1.4.1/24
BigIron RX-A(config-vif-6)# ip ospf area 0.0.0.0
BigIron RX-A(config-vif-6)# ipx network 4 ethernet_802.3
BigIron RX-A(config-vif-6)# int ve7
BigIron RX-A(config-vif-7)# ip addr 1.1.5.1/24
BigIron RX-A(config-vif-7)# ip ospf area 0.0.0.0
BigIron RX-A(config-vif-7)# ipx network 5 ethernet_802.3
BigIron RX-A(config-vif-7)#
This completes the configuration for BigIron RX-A. The configuration for BigIron RX-B and C is very similar except for a few issues.
• IP subnets and IPX networks configured on BigIron RX-B and BigIron RX-C must be unique across the entire network, except for the backbone port-based VLANs 5, 6, and 7 where the subnet is the same but the IP address must change.
• There is no need to change the default priority of STP within VLAN 4.
• There is no need to include a virtual router interface within VLAN 4.
• The backbone VLAN between BigIron RX-B and BigIron RX-C must be the same at both ends and requires a new VLAN ID. The VLAN ID for this port-based VLAN is VLAN 7.
© 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
Configuring BigIron RX-B
Enter the following commands to configure BigIron RX-B.
BigIron RX> en
No password has been assigned yet...
BigIron RX# config t
BigIron RX(config)# hostname BigIron RX-B
BigIron RX-B(config)# router ospf
BigIron RX-B(config-ospf-router)# area 0.0.0.0 normal
BigIron RX-B(config-ospf-router)# router ipx
BigIron RX-B(config-ospf-router)# vlan 2 name IP-Subnet_1.1.6.0/24
BigIron RX-B(config-vlan-2)# untag e 1/1 to 1/4
BigIron RX-B(config-vlan-2)# no spanning-tree
BigIron RX-B(config-vlan-2)# router-interface ve1
BigIron RX-B(config-vlan-2)# other-proto name block-other-protocols
BigIron RX-B(config-vlan-other-proto)# exclude e 1/1 to 1/4
BigIron RX-B(config-vlan-other-proto)# int ve1
BigIron RX-B(config-vif-1)# ip addr 1.1.6.1/24
BigIron RX-B(config-vif-1)# ip ospf area 0.0.0.0
BigIron RX-B(config-vif-1)# vlan 8 name IPX_Network6
BigIron RX-B(config-vlan-8)# untag e 1/5 to 1/8
BigIron RX-B(config-vlan-8)# no span
BigIron RX-B(config-vlan-8)# router-int ve2
BigIron RX-B(config-vlan-8)# other-proto name block-other-protocols
BigIron RX-B(config-vlan-other-proto)# exclude e 1/5 to 1/8
BigIron RX-B(config-vlan-other-proto)# int ve2
BigIron RX-B(config-vif-2)# ipx net 6 ethernet_802.3
BigIron RX-B(config-vif-2)# vlan 3 name IP_Sub_&_IPX_Net_VLAN
BigIron RX-B(config-vlan-3)# untag e 1/9 to 1/16
BigIron RX-B(config-vlan-3)# no spanning-tree
BigIron RX-B(config-vlan-3)# ip-subnet 1.1.7.0/24
BigIron RX-B(config-vlan-ip-subnet)# static e 1/9 to 1/12
BigIron RX-B(config-vlan-ip-subnet)# router-interface ve3
BigIron RX-B(config-vlan-ip-subnet)# ipx-network 7 ethernet_802.3
BigIron RX-B(config-vlan-ipx-network)# static e 1/13 to 1/16
BigIron RX-B(config-vlan-ipx-network)# router-interface ve4
BigIron RX-B(config-vlan-ipx-network)# other-proto name block-other-protocols
BigIron RX-B(config-vlan-other-proto)# exclude e 1/9 to 1/16
BigIron RX-B(config-vlan-other-proto)# interface ve 3
BigIron RX-B(config-vif-3)# ip addr 1.1.7.1/24
BigIron RX-B(config-vif-3)# ip ospf area 0.0.0.0
BigIron RX-B(config-vif-3)# int ve4
BigIron RX-B(config-vif-4)# ipx network 7 ethernet_802.3
BigIron RX-B(config-vif-4)# vlan 4 name Bridged_ALL_Protocols
BigIron RX-B(config-vlan-4)# untag ethernet 1/17 to 1/24
BigIron RX-B(config-vlan-4)# tag ethernet 1/25 to 1/26
BigIron RX-B(config-vlan-4)# spanning-tree
BigIron RX-B(config-vlan-4)# vlan 5 name Rtr_BB_to_Bldg.1
BigIron RX-B(config-vlan-5)# tag e 1/25
BigIron RX-B(config-vlan-5)# no spanning-tree
BigIron RX-B(config-vlan-5)# router-interface ve5
BigIron RX-B(config-vlan-5)# vlan 7 name Rtr_BB_to_Bldg.3
BigIron RX-B(config-vlan-7)# tag ethernet 1/26
BigIron RX-B(config-vlan-7)# no spanning-tree
BigIron RX-B(config-vlan-7)# router-interface ve6
BigIron RX-B(config-vlan-7)# int ve5
BigIron RX-B(config-vif-5)# ip addr 1.1.4.2/24
BigIron RX-B(config-vif-5)# ip ospf area 0.0.0.0
November 2005 © 2005 Foundry Networks, Inc.
9-21
Foundry BigIron RX Series Configuration Guide
9-22
BigIron RX-B(config-vif-5)# ipx network 4 ethernet_802.3
BigIron RX-B(config-vif-5)# int ve6
BigIron RX-B(config-vif-6)# ip addr 1.1.8.1/24
BigIron RX-B(config-vif-6)# ip ospf area 0.0.0.0
BigIron RX-B(config-vif-6)# ipx network 8 ethernet_802.3
BigIron RX-B(config-vif-6)#
Configuring BigIron RX-C
Enter the following commands to configure BigIron RX-C.
BigIron RX> en
No password has been assigned yet...
BigIron RX# config t
BigIron RX(config)# hostname BigIron RX-C
BigIron RX-C(config)# router ospf
BigIron RX-C(config-ospf-router)# area 0.0.0.0 normal
BigIron RX-C(config-ospf-router)# router ipx
BigIron RX-C(config-ospf-router)# vlan 2 name IP-Subnet_1.1.9.0/24
BigIron RX-C(config-vlan-2)# untag e 1/1 to 1/4
BigIron RX-C(config-vlan-2)# no spanning-tree
BigIron RX-C(config-vlan-2)# router-interface ve1
BigIron RX-C(config-vlan-2)# other-proto name block-other-protocols
BigIron RX-C(config-vlan-other-proto)# exclude e 1/1 to 1/4
BigIron RX-C(config-vlan-other-proto)# int ve1
BigIron RX-C(config-vif-1)# ip addr 1.1.9.1/24
BigIron RX-C(config-vif-1)# ip ospf area 0.0.0.0
BigIron RX-C(config-vif-1)# vlan 8 name IPX_Network9
BigIron RX-C(config-vlan-8)# untag e 1/5 to 1/8
BigIron RX-C(config-vlan-8)# no span
BigIron RX-C(config-vlan-8)# router-int ve2
BigIron RX-C(config-vlan-8)# other-proto name block-other-protocols
BigIron RX-C(config-vlan-other-proto)# exclude e 1/5 to 1/8
BigIron RX-C(config-vlan-other-proto)# int ve2
BigIron RX-C(config-vif-2)# ipx net 9 ethernet_802.3
BigIron RX-C(config-vif-2)# vlan 3 name IP_Sub_&_IPX_Net_VLAN
BigIron RX-C(config-vlan-3)# untag e 1/9 to 1/16
BigIron RX-C(config-vlan-3)# no spanning-tree
BigIron RX-C(config-vlan-3)# ip-subnet 1.1.10.0/24
BigIron RX-C(config-vlan-ip-subnet)# static e 1/9 to 1/12
BigIron RX-C(config-vlan-ip-subnet)# router-interface ve3
BigIron RX-C(config-vlan-ip-subnet)# ipx-network 10 ethernet_802.3
BigIron RX-C(config-vlan-ipx-network)# static e 1/13 to 1/16
BigIron RX-C(config-vlan-ipx-network)# router-interface ve4
BigIron RX-C(config-vlan-ipx-network)# other-proto name block-other-protocols
BigIron RX-C(config-vlan-other-proto)# exclude e 1/9 to 1/16
BigIron RX-C(config-vlan-other-proto)# interface ve 3
BigIron RX-C(config-vif-3)# ip addr 1.1.10.1/24
BigIron RX-C(config-vif-3)# ip ospf area 0.0.0.0
BigIron RX-C(config-vif-3)# int ve4
BigIron RX-C(config-vif-4)# ipx network 10 ethernet_802.3
BigIron RX-C(config-vif-4)# vlan 4 name Bridged_ALL_Protocols
BigIron RX-C(config-vlan-4)# untag ethernet 1/17 to 1/24
BigIron RX-C(config-vlan-4)# tag ethernet 1/25 to 1/26
BigIron RX-C(config-vlan-4)# spanning-tree
BigIron RX-C(config-vlan-4)# vlan 7 name Rtr_BB_to_Bldg.2
BigIron RX-C(config-vlan-7)# tag e 1/25
BigIron RX-C(config-vlan-7)# no spanning-tree
BigIron RX-C(config-vlan-7)# router-interface ve5
BigIron RX-C(config-vlan-7)# vlan 6 name Rtr_BB_to_Bldg.1
© 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
BigIron RX-C(config-vlan-6)# tag ethernet 1/26
BigIron RX-C(config-vlan-6)# no spanning-tree
BigIron RX-C(config-vlan-6)# router-interface ve6
BigIron RX-C(config-vlan-6)# int ve5
BigIron RX-C(config-vif-5)# ip addr 1.1.8.2/24
BigIron RX-C(config-vif-5)# ip ospf area 0.0.0.0
BigIron RX-C(config-vif-5)# ipx network 8 ethernet_802.3
BigIron RX-C(config-vif-5)# int ve6
BigIron RX-C(config-vif-6)# ip addr 1.1.5.2/24
BigIron RX-C(config-vif-6)# ip ospf area 0.0.0.0
BigIron RX-C(config-vif-6)# ipx network 5 ethernet_802.3
BigIron RX-C(config-vif-6)#
Configuring VLAN Groups
To simplify configuration when you have many VLANs with the same configuration, you can configure VLAN groups. When you create a VLAN group, the VLAN parameters you configure for the group apply to all the VLANs within the group.
The VLAN group feature allows you to create multiple port-based VLANs with identical port members. Since the member ports are shared by all the VLANs within the group, you must add the ports as tagged ports. This feature not only simplifies VLAN configuration but also allows you to have a large number of identically configured VLANs in a startup configuration file on the device’s flash memory module. Normally, a startup configuration file with a large number of VLANs might not fit on the flash memory module. By grouping the identically configured VLANs, you can conserve space in the startup configuration file so that it fits on the flash memory module.
You can create up to 32 VLAN groups
NOTE:
Depending on the size of the VLAN ID range you want to use for the VLAN group, you might need to
Virtual Routing Interfaces” on page 9-27.
Configuring a VLAN Group
To configure a VLAN group, enter commands such as the following:
BigIron RX(config)# vlan-group 1 vlan 2 to 1000
BigIron RX(config-vlan-group-1)# tagged e 1/1 to 1/2
The first command begins configuration for VLAN group 1, creates VLANs 2 through 1000 and assigns them to the group. The second command adds ports 1/1 and 1/2 as tagged ports to the group. Since all the VLANs in the group share the ports, you must add the ports as tagged ports.
Syntax: vlan-group <num> vlan <vlan-id> to <vlan-id>
Syntax: tagged ethernet [to <slot/port> | ethernet <slot/port>]
The <num> parameter with the vlan-group command specifies the VLAN group ID and can be from 1 – 32.
The vlan <vlan-id> to <vlan-id> parameters specify a range (with no gaps) of VLAN IDs. Specify the low VLAN
ID first and the high VLAN ID second. The command adds all the specified VLANs to the VLAN group.
NOTE:
The device’s memory must be configured to contain at least the number of VLANs you specify for the higher end of the range. For example, if you specify 2048 as the VLAN ID at the high end of the range, you first
Virtual Routing Interfaces” on page 9-27.
If a VLAN within the range you specify is already configured, the CLI does not add the group but instead displays an error message. In this case, create the group by specifying a valid contiguous range. Then add more VLANs to the group after the CLI changes to the configuration level for the group. See the following example.
November 2005 © 2005 Foundry Networks, Inc.
9-23
Foundry BigIron RX Series Configuration Guide
You can add and remove individual VLANs or VLAN ranges from at the VLAN group configuration level. For example, to add VLANs 1001 and 1002 to VLAN group 1 and remove VLANs 900 through 1000, enter the following commands:
BigIron RX(config-vlan-group-1)# add-vlan 1001 to 1002
BigIron RX(config-vlan-group-1)# remove-vlan 900 to 1000
Syntax: [no] add-vlan <vlan-id> [to <vlan-id>]
Syntax: remove-vlan <vlan-id> [to <vlan-id>]
Displaying Information about VLAN Groups
To display VLAN group configuration information, enter the following command:
BigIron RX# show vlan-group vlan-group 1 vlan 2 to 20
tagged ethe 1/1 to 1/2
!
vlan-group 2 vlan 21 to 40
tagged ethe 1/1 to 1/2
!
The example shows configuration information for two VLAN groups, group 1 and group 2.
Syntax: show vlan-group [<group-id>]
The <group-id> specifies a VLAN group. If you do not use this parameter, the configuration information for all the configured VLAN groups is displayed.
Displaying the VLAN Group
To verify configuration of VLAN groups, display the running configuration file. If you have saved the configuration to the startup configuration file, you also can verify the configuration by displaying the startup configuration file.
The following example shows the running configuration information for the VLAN group configured in the previous examples. The information appears in the same way in the startup configuration file.
BigIron RX(config)# show running-config
lines not related to the VLAN group omitted...
vlan-group 1 vlan 2 to 900
add-vlan 1001 to 1002
tagged ethe 1/1 to 1/2
router-interface-group
If you have enabled display of subnet masks in CIDR notation, the IP address information is shown as follows: 10.10.10.1/24.
Configuring the Same IP Subnet Address on Multiple Port-Based
VLANs
For a BigIron RX to route between port-based VLANs, you must add a virtual routing interface to each VLAN.
Generally, you also configure a unique IP subnet address on each virtual routing interface. For example, if you have three port-based VLANs, you add a virtual routing interface to each VLAN, then add a separate IP subnet address to each virtual routing interface. The IP address on each of the virtual routing interfaces must be in a separate subnet. The BigIron RX routes Layer 3 traffic between the subnets using the subnet addresses.
NOTE:
Before using the method described in this section, see “Configuring VLAN Groups” on page 9-23. You
might be able to achieve the results you want using the methods in that section instead.
9-24 © 2005 Foundry Networks, Inc.
November 2005
Figure 9.10 shows an example of this type of configuration.
Figure 9.10
Multiple port-based VLANs with separate protocol addresses
VLAN 2
VLAN 3
VLAN 4
Configuring Virtual LANs (VLANs)
BigIron RX
VLAN 2
VE 1
-IP 10.0.0.1/24
VLAN 3
VE 2
-IP 10.0.1.1/24
VLAN 4
VE 3
-IP 10.0.2.1/24
As shown in this example, each VLAN has a separate IP subnet address. If you need to conserve IP subnet
November 2005 © 2005 Foundry Networks, Inc.
9-25
Foundry BigIron RX Series Configuration Guide
Figure 9.11
Multiple port-based VLANs with the same protocol address
VLAN 2
VLAN 3
VLAN 4
BigIron RX
9-26
VLAN 2
VE 1
-IP 10.0.0.1/24
VLAN 3
VE 2
-Follow VE 1
VLAN 4
VE 3
-Follow VE 1
Each VLAN still requires a separate virtual routing interface. However, all three VLANs now use the same IP subnet address.
In addition to conserving IP subnet addresses, this feature allows containment of Layer 2 broadcasts to segments within an IP subnet. For ISP environments where the same IP subnet is allocated to different customers, placing each customer in a separate VLAN allows all customers to share the IP subnet address, while at the same time isolating them from one another’s Layer 2 broadcasts.
NOTE:
You can provide redundancy to an IP subnet address that contains multiple VLANs using a pair of BigIron
RX switches configured for Foundry’s VRRP (Virtual Router Redundancy Protocol).
The BigIron RX performs proxy Address Resolution Protocol (ARP) for hosts that want to send IP traffic to hosts in other VLANs that are sharing the same IP subnet address. If the source and destination hosts are in the same
VLAN, the BigIron RX does not need to use ARP.
• If a host attached to one VLAN sends an ARP message for the MAC address of a host in one of the other
VLANs using the same IP subnet address, the BigIron RX performs a proxy ARP on behalf of the other host.
The BigIron RX then replies to the ARP by sending the virtual routing interface MAC address. The BigIron RX uses the same MAC address for all virtual routing interfaces.
When the host that sent the ARP then sends a unicast packet addressed to the virtual routing interface’s MAC address, the device switches the packet on Layer 3 to the destination host on the VLAN.
© 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
NOTE:
If the BigIron RX’s ARP table does not contain the requested host, the BigIron RX forwards the ARP request on Layer 2 to the same VLAN as the one that received the ARP request. Then the device sends an
ARP for the destination to the other VLANs that are using the same IP subnet address.
• If the destination is in the same VLAN as the source, the BigIron RX does not need to perform a proxy ARP.
To configure multiple VLANs to use the same IP subnet address:
• Configure each VLAN, including adding tagged or untagged ports.
• Configure a separate virtual routing interface for each VLAN, but do not add an IP subnet address to more than one of the virtual routing interfaces.
• Configure the virtual routing interfaces that do not have the IP subnet address to “follow” the virtual routing interface that does have the address.
To configure the VLANs shown in Figure 9.11, you could enter the following commands.
BigIron RX(config)# vlan 1 by port
BigIron RX(config-vlan-1)# untag ethernet 1/1
BigIron RX(config-vlan-1)# tag ethernet 1/8
BigIron RX(config-vlan-1)# router-interface ve 1
The commands above configure port-based VLAN 1. The VLAN has one untagged port (1/1) and a tagged port
(1/8). In this example, all three VLANs contain port 1/8 so the port must be tagged to allow the port to be in multiple VLANs. You can configure VLANs to share a Layer 3 protocol interface regardless of tagging. A combination of tagged and untagged ports is shown in this example to demonstrate that sharing the interface does not change other VLAN features.
Notice that each VLAN still requires a unique virtual routing interface.
The following commands configure port-based VLANs 2 and 3.
BigIron RX(config-vlan-1)# vlan 2 by port
BigIron RX(config-vlan-2)# untag ethernet 1/2
BigIron RX(config-vlan-2)# tag ethernet 1/8
BigIron RX(config-vlan-2)# router-interface ve 2
BigIron RX(config-vlan-2)# vlan 3 by port
BigIron RX(config-vlan-3)# untag ethernet 1/5 to 1/6
BigIron RX(config-vlan-3)# tag ethernet 1/8
BigIron RX(config-vlan-3)# router-interface ve 3
The following commands configure an IP subnet address on virtual routing interface 1.
BigIron RX(config-vlan-3)# interface ve 1
BigIron RX(config-vif-1)# ip address 10.0.0.1/24
Allocating Memory for More VLANs or Virtual Routing Interfaces
By default, you can configure up to 512 VLANs and virtual routing interfaces on the BigIron RX. This is the default maximum. However, BigIron RX can support up to 4095 VLANs and 4095 virtual routing interfaces, but VLAN IDs
0, 4092 and 4095 are reserved; therefore, only 4093 VLANs are user configurable.
NOTE:
If many of your VLANs will have an identical configuration, you might want to configure VLAN groups.
To increase the maximum number of VLANs you can configure, enter commands such as the following at the global CONFIG level of the CLI:
BigIron RX(config)# system-max vlan 2048
BigIron RX(config)# write memory
BigIron RX(config)# end
BigIron RX# reload
November 2005 © 2005 Foundry Networks, Inc.
9-27
Foundry BigIron RX Series Configuration Guide
Syntax: system-max vlan <num>
The <num> parameter specifies the maximum number of VLANs. Enter 1 – 4093 since VLAN IDs 0, 4092 and
4095 are reserved.
Configuring Super Aggregated VLANs
You can aggregate multiple VLANs within another VLAN. This feature allows you to construct Layer 2 paths and channels. This feature is particularly useful for Virtual Private Network (VPN) applications in which you need to provide a private, dedicated Ethernet connection for an individual client to transparently reach its subnet across multiple networks.
Conceptually, the paths and channels are similar to Asynchronous Transfer Mode (ATM) paths and channels. A path contains multiple channels, each of which is a dedicated circuit between two end points. The two devices at the end points of the channel appear to each other to be directly attached. The network that connects them is transparent to the two devices.
You can aggregate up to 4094 VLANs within another VLAN. This provides a total VLAN capacity on one BigIron
RX of 16,760,836 channels (4094 * 4094).
The devices connected through the channel are not visible to devices in other channels. Therefore, each client has a private link to the other side of the channel.
The feature allows point-to-point and point-to-multipoint connections.
provide a path for multiple client channels. The channels do not receive traffic from other channels. Thus, each channel is a private link.
Figure 9.12
Conceptual Model of the Super Aggregated VLAN Application
. . .
Client 3
. . .
Client 5 Client 1
Client 1
192.168.1.69/24
Path = a single VLAN into which client VLANs are aggregated
Channel = a client VLAN nested inside a Path
9-28 sub-net
192.168.1.0/24
© 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
Each client connected to the edge device is in its own port-based VLAN, which is like an ATM channel. All the clients’ VLANs are aggregated by the edge device into a single VLAN for connection to the core. The single VLAN that aggregates the clients’ VLANs is like an ATM path.
The device that aggregates the VLANs forwards the aggregated VLAN traffic through the core. The core can consist of multiple devices that forward the aggregated VLAN traffic. The edge device at the other end of the core separates the aggregated VLANs into the individual client VLANs before forwarding the traffic. The edge devices forward the individual client traffic to the clients. For the clients’ perspective, the channel is a direct point-to-point link.
connections shown in Figure 9.12.
Figure 9.13
Example Super Aggregated VLAN Application
Client 1
192.168.1.69/24
Client 1
Port 1/1
VLAN 101
. . .
Client 3
Port 1/3
VLAN 103
. . .
Client 5
Port 1/5
VLAN 105
Client 6
Port 1/1
VLAN 101
. . .
Client 8
Port 1/3
VLAN 103
. . .
Client 10
Port 1/5
VLAN 105
209.157.2.12/24
Ports 1/1 - 1/5
Untagged
Ports 1/1 - 1/5
Untagged
Device A
Tag Type 8100
Device B
Tag Type 8100
Port 2/1
Tagged
Port 3/1
Untagged
Device C
Tag Type 9100
VLAN Aggregation
Enabled
Port 4/1
Tagged
Port 4/1
Tagged
Port 3/2
Untagged
Device D
Tag Type 9100
VLAN Aggregation
Enabled
Port 3/1
Untagged
Port 2/1
Tagged
Port 3/2
Untagged
Port 2/1
Tagged
Port 2/1
Tagged
Device E
Tag Type 8100
Ports 1/1 - 1/5
Untagged
Ports 1/1 - 1/5
Untagged
Device F
Tag Type 8100
192.168.1.129/24
In this example, a collocation service provides private channels for multiple clients. Although the same devices are used for all the clients, the VLANs ensure that each client receives its own Layer 2 broadcast domain, separate from the broadcast domains of other clients. For example, client 1 cannot ping client 5.
The clients at each end of a channel appear to each other to be directly connected and thus can be on the same subnet and use network services that require connection to the same subnet. In this example, client 1 is in subnet
192.168.1.0/24 and so is the device at the other end of client 1’s channel.
Since each VLAN configured on the core devices is an aggregate of multiple client VLANs, the aggregated VLANs greatly increase the number of clients a core device can accommodate.
November 2005 © 2005 Foundry Networks, Inc.
9-29
Foundry BigIron RX Series Configuration Guide
This example shows a single link between the core devices. However, you can use a trunk group to add link-level redundancy.
Configuring Aggregated VLANs
A maximum of 1526 bytes are supported on ports where super-aggregated VLANs are configured. This allows for an additional 8 bytes over the untagged port maximum to allow for support of two VLAN tags.
To configure aggregated VLANs, perform the following tasks:
• On each edge device, configure a separate port-based VLAN for each client connected to the edge device. In each client VLAN:
• Add the port connected to the client as an untagged port.
• Add the port connected to the core device (the device that will aggregate the VLANs) as a tagged port.
This port must be tagged because all the client VLANs share the port as an uplink to the core device.
• On each core device:
• Enable VLAN aggregation. This support allows the core device to add an additional tag to each Ethernet frame that contains a VLAN packet from the edge device. The additional tag identifies the aggregate
VLAN (the path). However, the additional tag can cause the frame to be longer than the maximum supported frame size. The larger frame support allows Ethernet frames up to 1530 bytes long.
NOTE:
Enable the VLAN aggregation option only on the core devices.
• Configure a VLAN tag type (tag ID) that is different than the tag type used on the edge devices. If you use the default tag type (8100) on the edge devices, set the tag type on the core devices to another value, such as 9100. The tag type must be the same on all the core devices. The edge devices also must have the same tag type but the type must be different from the tag type on the core devices.
NOTE:
You can enable the Spanning Tree Protocol (STP) on the edge devices or the core devices, but not both.
If you enable STP on the edge devices and the core devices, STP will prevent client traffic from travelling through the core to the other side.
Configuring Aggregated VLANs on an Edge Device
BigIron RX(config)# vlan 101 by port
BigIron RX(config-vlan-101)# tagged ethernet 2/1
BigIron RX(config-vlan-101)# untagged ethernet 1/1
BigIron RX(config-vlan-101)# exit
BigIron RX(config)# vlan 102 by port
BigIron RX(config-vlan-102)# tagged ethernet 2/1
BigIron RX(config-vlan-102)# untagged ethernet 1/2
BigIron RX(config-vlan-102)# exit
BigIron RX(config)# vlan 103 by port
BigIron RX(config-vlan-103)# tagged ethernet 2/1
BigIron RX(config-vlan-103)# untagged ethernet 1/3
BigIron RX(config-vlan-103)# exit
BigIron RX(config)# vlan 104 by port
BigIron RX(config-vlan-104)# tagged ethernet 2/1
BigIron RX(config-vlan-104)# untagged ethernet 1/4
BigIron RX(config-vlan-104)# exit
BigIron RX(config)# vlan 105 by port
BigIron RX(config-vlan-105)# tagged ethernet 2/1
BigIron RX(config-vlan-105)# untagged ethernet 1/5
BigIron RX(config-vlan-105)# exit
BigIron RX(config)# write memory
9-30 © 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
Syntax: [no] vlan <vlan-id> [by port]
Syntax: [no] untagged | tagged ethernet <slot/port> [to <slot/port> | ethernet <slot/port>]
The tagged command adds the port that the device uses for the uplink to the core device.
The untagged command adds the ports connected to the individual clients.
Configuring Aggregated VLANs on a Core Device
BigIron RX(config)# tag-type 9100
BigIron RX(config)# aggregated-vlan
BigIron RX(config)# vlan 101 by port
BigIron RX(config-vlan-101)# tagged ethernet 4/1
BigIron RX(config-vlan-101)# untagged ethernet 3/1
BigIron RX(config-vlan-101)# exit
BigIron RX(config)# vlan 102 by port
BigIron RX(config-vlan-102)# tagged ethernet 4/1
BigIron RX(config-vlan-102)# untagged ethernet 3/2
BigIron RX(config-vlan-102)# exit
BigIron RX(config)# write memory
Syntax: [no] tag-type <num>
Syntax: [no] aggregated-vlan
The <num> parameter specifies the tag type. It can be a hexadecimal value from 0 – ffff. The default is 8100.
Complete CLI Examples
NOTE:
In these examples, the configurations of the edge devices (A, B, E, and F) are identical. The configurations of the core devices (C and D) also are identical. The aggregated VLAN configurations of the edge and core devices on one side must be symmetrical (in fact, a mirror image) to the configurations of the devices on
numbers. This allows the configurations for both sides of the link to be the same. If your configuration does not use symmetrically arranged port numbers, the configurations should not be identical but must use the correct port numbers.
Commands for Device A
BigIron RX-A(config)# vlan 101 by port
BigIron RX-A(config-vlan-101)# tagged ethernet 2/1
BigIron RX-A(config-vlan-101)# untagged ethernet 1/1
BigIron RX-A(config-vlan-101)# exit
BigIron RX-A(config)# vlan 102 by port
BigIron RX-A(config-vlan-102)# tagged ethernet 2/1
BigIron RX-A(config-vlan-102)# untagged ethernet 1/2
BigIron RX-A(config-vlan-102)# exit
BigIron RX-A(config)# vlan 103 by port
BigIron RX-A(config-vlan-103)# tagged ethernet 2/1
BigIron RX-A(config-vlan-103)# untagged ethernet 1/3
BigIron RX-A(config-vlan-103)# exit
BigIron RX-A(config)# vlan 104 by port
BigIron RX-A(config-vlan-104)# tagged ethernet 2/1
BigIron RX-A(config-vlan-104)# untagged ethernet 1/4
BigIron RX-A(config-vlan-104)# exit
BigIron RX-A(config)# vlan 105 by port
BigIron RX-A(config-vlan-105)# tagged ethernet 2/1
November 2005 © 2005 Foundry Networks, Inc.
9-31
Foundry BigIron RX Series Configuration Guide
BigIron RX-A(config-vlan-105)# untagged ethernet 1/5
BigIron RX-A(config-vlan-105)# exit
BigIron RX-A(config)# write memory
Commands for Device B
The commands for configuring device B are identical to the commands for configuring device A. Notice that you can use the same channel VLAN numbers on each device. The devices that aggregate the VLANs into a path can distinguish between the identically named channel VLANs based on the ID of the path VLAN.
BigIron RX-B(config)# vlan 101 by port
BigIron RX-B(config-vlan-101)# tagged ethernet 2/1
BigIron RX-B(config-vlan-101)# untagged ethernet 1/1
BigIron RX-B(config-vlan-101)# exit
BigIron RX-B(config)# vlan 102 by port
BigIron RX-B(config-vlan-102)# tagged ethernet 2/1
BigIron RX-B(config-vlan-102)# untagged ethernet 1/2
BigIron RX-B(config-vlan-102)# exit
BigIron RX-B(config)# vlan 103 by port
BigIron RX-B(config-vlan-103)# tagged ethernet 2/1
BigIron RX-B(config-vlan-103)# untagged ethernet 1/3
BigIron RX-B(config-vlan-103)# exit
BigIron RX-B(config)# vlan 104 by port
BigIron RX-B(config-vlan-104)# tagged ethernet 2/1
BigIron RX-B(config-vlan-104)# untagged ethernet 1/4
BigIron RX-B(config-vlan-104)# exit
BigIron RX-B(config)# vlan 105 by port
BigIron RX-B(config-vlan-105)# tagged ethernet 2/1
BigIron RX-B(config-vlan-105)# untagged ethernet 1/5
BigIron RX-B(config-vlan-105)# exit
BigIron RX-B(config)# write memory
Commands for Device C
Since device C is aggregating channel VLANs from devices A and B into a single path, you need to change the tag type and enable VLAN aggregation.
BigIron RX-C(config)# tag-type 9100
BigIron RX-C(config)# aggregated-vlan
BigIron RX-C(config)# vlan 101 by port
BigIron RX-C(config-vlan-101)# tagged ethernet 4/1
BigIron RX-C(config-vlan-101)# untagged ethernet 3/1
BigIron RX-C(config-vlan-101)# exit
BigIron RX-C(config)# vlan 102 by port
BigIron RX-C(config-vlan-102)# tagged ethernet 4/1
BigIron RX-C(config-vlan-102)# untagged ethernet 3/2
BigIron RX-C(config-vlan-102)# exit
BigIron RX-C(config)# write memory
Commands for Device D
Device D is at the other end of path and separates the channels back into individual VLANs. The tag type must be the same as tag type configured on the other core device (Device C). In addition, VLAN aggregation also must be enabled.
BigIron RX-D(config)# tag-type 9100
BigIron RX-D(config)# aggregated-vlan
BigIron RX-D(config)# vlan 101 by port
BigIron RX-D(config-vlan-101)# tagged ethernet 4/1
BigIron RX-D(config-vlan-101)# untagged ethernet 3/1
BigIron RX-D(config-vlan-101)# exit
BigIron RX-D(config)# vlan 102 by port
9-32 © 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
BigIron RX-D(config-vlan-102)# tagged ethernet 4/1
BigIron RX-D(config-vlan-102)# untagged ethernet 3/2
BigIron RX-D(config-vlan-102)# exit
BigIron RX-D(config)# write memory
Commands for Device E
identical to the commands for configuring device A.
BigIron RX-E(config)# vlan 101 by port
BigIron RX-E(config-vlan-101)# tagged ethernet 2/1
BigIron RX-E(config-vlan-101)# untagged ethernet 1/1
BigIron RX-E(config-vlan-101)# exit
BigIron RX-E(config)# vlan 102 by port
BigIron RX-E(config-vlan-102)# tagged ethernet 2/1
BigIron RX-E(config-vlan-102)# untagged ethernet 1/2
BigIron RX-E(config-vlan-102)# exit
BigIron RX-E(config)# vlan 103 by port
BigIron RX-E(config-vlan-103)# tagged ethernet 2/1
BigIron RX-E(config-vlan-103)# untagged ethernet 1/3
BigIron RX-E(config-vlan-103)# exit
BigIron RX-E(config)# vlan 104 by port
BigIron RX-E(config-vlan-104)# tagged ethernet 2/1
BigIron RX-E(config-vlan-104)# untagged ethernet 1/4
BigIron RX-E(config-vlan-104)# exit
BigIron RX-E(config)# vlan 105 by port
BigIron RX-E(config-vlan-105)# tagged ethernet 2/1
BigIron RX-E(config-vlan-105)# untagged ethernet 1/5
BigIron RX-E(config-vlan-105)# exit
BigIron RX-E(config)# write memory
Commands for Device F
The commands for configuring device F are identical to the commands for configuring device E. In this example,
configuration of device F is also identical to the configuration of device A and device B.
BigIron RX-F(config)# vlan 101 by port
BigIron RX-F(config-vlan-101)# tagged ethernet 2/1
BigIron RX-F(config-vlan-101)# untagged ethernet 1/1
BigIron RX-F(config-vlan-101)# exit
BigIron RX-F(config)# vlan 102 by port
BigIron RX-F(config-vlan-102)# tagged ethernet 2/1
BigIron RX-F(config-vlan-102)# untagged ethernet 1/2
BigIron RX-F(config-vlan-102)# exit
BigIron RX-F(config)# vlan 103 by port
BigIron RX-F(config-vlan-103)# tagged ethernet 2/1
BigIron RX-F(config-vlan-103)# untagged ethernet 1/3
BigIron RX-F(config-vlan-103)# exit
BigIron RX-F(config)# vlan 104 by port
BigIron RX-F(config-vlan-104)# tagged ethernet 2/1
BigIron RX-F(config-vlan-104)# untagged ethernet 1/4
BigIron RX-F(config-vlan-104)# exit
BigIron RX-F(config)# vlan 105 by port
BigIron RX-F(config-vlan-105)# tagged ethernet 2/1
BigIron RX-F(config-vlan-105)# untagged ethernet 1/5
BigIron RX-F(config-vlan-105)# exit
BigIron RX-F(config)# write memory
November 2005 © 2005 Foundry Networks, Inc.
9-33
Foundry BigIron RX Series Configuration Guide
Configuring 802.1q-in-q Tagging
You can configure 802.1Q tag-types on a group of ports, thereby enabling the creation of two identical 802.1Q tags (802.1Q-in-Q tagging) on a single device. This improves SAV interoperability between Foundry devices and other vendors’ devices that support the 802.1Q tag-types, but is not very flexible with the tag-types they accept.
Figure 9.14 shows an 802.1Q configuration example.
Figure 9.14
802.1Q Configuration Example
To customer interface
Provider
Edge Switch
Uplink to provider cloud
Untagged Tagged
DA SA 8100
Customer
VLAN
DA SA 9100
Provider
VLAN
8100
Customer
VLAN
cloud are tagged, because multiple client VLANs share the uplink to the provider cloud. In this example, the
BigIron RX treats the customer’s private VLAN ID and 8100 tag type as normal payload, and adds the 9100 tag type to the packet when the packet is sent to the uplink and forwarded along the provider cloud.
As long as the switches in the provider’s network are BigIron RX that can use the 9100 tag type, the data gets switched along the network. However, devices along the provider’s cloud that do not support the 9100 tag type may not properly handle the packets.
802.1Q-in-Q tagging enables you to configure 802.1Q tag-types on a group of ports, thereby enabling the creation of two identical 802.1Q tags (802.1Q-in-Q tagging) on a single device. This enhancement improves SAV interoperability between Foundry devices and other vendors’ devices that support the 802.1Q tag-types, but are not very flexible with the tag-types they accept.
Figure 9.17 shows an example application of the 802.1Q-in-Q enhancement.
Figure 9.15
802.1Q-in-Q Configuration Example
To customer interface
Provider
Edge Switch
Uplink to provider cloud
Configured tag-type 9100 Default tag-type 8100
Untagged Tagged
9-34
DA SA 8100
Customer
VLAN
DA SA 8100
Provider
VLAN
8100
Customer
VLAN
than the configured tag-type 9100. These packets are considered untagged on this incoming port and are retagged when they are sent out of the uplink towards the provider. The 802.1Q tag-type on the uplink port is
8100, so the BigIron RX will switch the frames to the uplink device with an additional 8100 tag, thereby supporting devices that only support this method of VLAN tagging.
© 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
Configuration Rules
• Since the uplink (to the provider cloud) and the edge link (to the customer port) must have different 802.1Q tags, make sure the uplink and edge link are in different port regions.
• If you configure a port with an 802.1Q tag-type, the BigIron RX automatically applies the 802.1Q tag-type to all ports within the same port region.
• If you remove the 802.1Q tag-type from a port, the BigIron RX automatically removes the 802.1Q tag-type from all ports within the same port region.
• The BigIron RX supports on configured tag-type per device, along with the default tag-type of 8100. For example, if you configure an 802.1Q tag of 9100 on ports 1 – 8, then later configure an 802.1Q tag of 5100 on port 9, the device automatically applies the 5100 tag to all ports in the same port region as port 9, and also changes the 802.1Q tag-type on ports 1 – 8 to 5100.
Enabling 802.1Q-in-Q Tagging
To enable the 802.1Q-in-Q feature, configure an 802.1Q tag on the untagged edge links (the customer ports) to
untagged edge links (ports 11 and 12) is 9100, whereas, the 802.1Q tag for incoming traffic is 8100.
untagged edge links of devices C and D:
BigIron RX(config)# tag-type 9100 e 11 to 12
BigIron RX(config)# aggregated-vlan
Note that since ports 11 and 12 belong to the port region 9 – 16, the 802.1Q tag actually applies to ports 9 – 16.
Syntax: [no] tag-type <num> [ethernet <slot/port> [to <slot/port>]]
The <num> parameter specifies the tag-type number and can be a hexadecimal value from 0 - ffff. The default is
8100.
The e <port number> to <port number> parameter specifies the port(s) that will use the defined 802.1Q tag.
This parameter operates with the following rules:
• If you specify a single port number, the 802.1Q tag applies to all ports within the port region. For example, if you enter the command tag-type 9100 e 1, the BigIron RX automatically applies the 802.1Q tag to ports 1 – 8 since all of these ports are in the same port region. You can use the show running-config command to view how the command has been applied.
• If you do not specify a port or range of ports, the 802.1Q tag applies to all Ethernet ports on the device.
Example Configuration
Figure 9.16 shows an example 802.1Q-in-Q configuration.
November 2005 © 2005 Foundry Networks, Inc.
9-35
Foundry BigIron RX Series Configuration Guide
Figure 9.16
Example 802.1Q-in-Q Configuration
Client 1
Port 1/1
VLAN 101
. . .
Client 3
Port 1/3
VLAN 103
. . .
Client 5
Port 1/5
VLAN 105
Client 1
192.168.1.69/24
Ports 1/1 - 1/5
Untagged
Client 5
209.157.2.12/24
Device A
Tag Type 8100
Client 6
Port 1/1
VLAN 101
. . .
Client 8
Port 1/3
VLAN 103
. . .
Client 10
Port 1/5
VLAN 105
Ports 1/1 - 1/5
Untagged
9100
Port 3/2
Untagged
Device B
Tag Type 8100
Port 2/1
Tagged
Port 2/1
Tagged
9100
Port 3/1
Untagged
Device C
Tag Type 9100 on ports 3/1 and 3/2
Port 4/1
Tagged
8100
8100
Port 4/1
Tagged
Device D
Tag Type 9100 on ports 3/1 and 3/2
Port 2/1
Tagged
Port 3/1
Untagged
9100
Device E
Tag Type 8100
Ports 1/1 - 1/5
Untagged
This is the link over which 802.1Q-in-Q applies. This link can also be replaced by a cloud or core of other vendors’ devices that use the 802.1Q tag type of
8100.
9100
Port 3/2
Untagged
Port 2/1
Tagged
Device F
Tag Type 8100
Ports 1/1 - 1/5
Untagged
192.168.1.129/24
Configuring 802.1q Tag-type Translation
The introduction of 802.1q tag-type translation provides finer granularity for configuring multiple 802.1q tag-types on a single device, by enabling you to configure 802.1q tag-types per port group. This enhancement allows for tag-type translation from one port group to the next on tagged interfaces.
802.1Q tag-type translation enables you to configure 802.1q tag-types per port group, allowing for tag-type translation from one port group to the next on tagged interfaces.
Figure 9.17 shows a basic example application of the 802.1q tag-type translation feature.
9-36 © 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
Figure 9.17
802.1q Tag-type Translation Configuration Example 1
Network Core
Customer
Edge Switch 1
Provider
Core Switch 1
Provider
Core Switch 2
Tagged
8100
Tagged
8100
Tagged
9100
Tagged
9100
Tagged
8100
Tagged
8100
Customer
Edge Switch 2
DA SA 8100
Customer
VLAN
DA SA 9100
Provider
VLAN
DA SA 8100
Customer
VLAN
As illustrated in Figure 9.17, the devices process the packet as follows:
• Customer Edge Switch 1 sends a packet with an 802.1q tag-type of 8100 to Provider Core Switch 1.
• Since the customer-facing interface on Provider Core Switch 1 has the same 802.1q tag-type as the incoming packet, it removes the 8100 tag-type and replaces (translates) it with the 9100 tag-type as it sends the packet to the uplink (Provider Core Switch 2).
• The same process occurs between Provider Core Switch 2 and Customer Edge Switch 2.
the tag-types between devices match. In this example, each device performs the 802.1q tag-type translation as the packet traverses the network.
between devices match, and the core devices have multiple tag-types. In this example, the tag-type translation feature integrates packets that have single and double tag-types.
November 2005 © 2005 Foundry Networks, Inc.
9-37
Foundry BigIron RX Series Configuration Guide
Figure 9.18
802.1q Tag-type Translation Configuration Example 2
Edge Switch 2 Edge Switch 3
Global 802.1Q
tag-type
8500
T
Edge Switch 1
Global 802.1Q
tag-type
8200
8200
T
U
T
8200
Multiple
802.1Q
tag-types
8300
Core Switch 1
T
Global 802.1Q
tag-type
8200
8200
T
T
T
T
8200
Multiple
802.1Q
tag-types
8300
Core Switch 2
U
Path A
Path B
Incoming Frame on Core Switch 1
DA SA 8500
Customer
VLAN
DA SA 8200
Customer
VLAN
Outgoing Frame on Core Switch 1
DA SA 9100
8500
Provider
VLAN
DA SA 9100
Provider
VLAN
Outgoing Frame on Core Switch 2
DA SA 8500
Customer
VLAN
DA SA 8200
Customer
VLAN
T
Global 802.1Q
tag-type
8500
Edge Switch 4
9-38
Legend:
T - Tagged port
U - Untagged port
XXXX - DMA or port group
Path A
Path B
As illustrated in Figure 9.18, the devices process the packets as follows:
• Path A: When Core Switch 1 receives the tagged packet from Edge Switch 1, it keeps the 8500 tag-type in the frame header (because the incoming port on Core Switch 1 is untagged) and adds the 9100 tag-type as it sends the packet to the uplink (Core Switch 2). In this case, the packet is double-tagged as it travels between the core devices.
• Path B: When Core Switch 1 receives the tagged packet from Edge Switch 2, it removes the 8200 tag-type and replaces (translates) it with the 9100 tag-type as it sends the packet to the uplink (Core Switch 2).
For more information, see “Configuring 802.1q Tag-type Translation” on page 9-36.
Configuration Rules
• On the supported devices, you configure 802.1q tag-types per port region. Use the show running-config command at any level of the CLI to view port regions. Note that on Gigabit Ethernet modules, ports 1 and 2 belong to the same port region.
• Since the uplink (to the provider cloud) and the edge link (to the customer port) must have different 802.1q tag-types, make sure the uplink and edge link are in different port regions.
© 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
• If you configure a port with an 802.1q tag-type, the BigIron RX automatically applies the 802.1q tag-type to all ports within the same port region.
• If you remove the 802.1q tag-type from a port, the BigIron RX automatically removes the 802.1q tag-type from all ports within the same port region.
• Foundry does not recommend configuring different 802.1q tag-types on ports that are part of a multi-slot trunk. Use the same 802.1q tag-type for all ports in a multi-slot trunk.
• Multiple 802.1Q tag types can be assigned to an interface module. Depending on the module, an 802.1Q tag
of the BigIron RX interface modules can have 802.1Q tag-types assigned.
Table 9.1: 802.1Q tag-type assignments by module module type
4 x 10G
24 x 1G
802.1Q tag-type assignment
per port per 12 ports:
1 - 12,
13 - 24,
Enabling 802.1q Tag-type Translation
To enable 802.1q tag-type translation, configure an 802.1q tag-type on the provider core link, between the provider
core switches (see Figure 9.17). Enter commands such as the following:
BigIron RX(config)# tag-type 9100 e 11 to 12
BigIron RX(config)# aggregated-vlan
Note that since ports 11 and 12 belong to the port region 9 – 16, the 802.1q tag-type actually applies to ports 9 –
16.
NOTE:
Do not configure 802.1q tag-type translation on the edge link (to the customer edge switch).
Syntax: [no] tag-type <num> [ethernet <slot/port> [to <slot/port>]]
The <num> parameter specifies the tag-type number and can be a hexadecimal value from 0 - ffff. The default is
8100. Note that you must specify a value other than 8100.
The <slot/port> [to <slot/port>] parameter specifies the port(s) that will use the defined 802.1q tag-type. This parameter operates with the following rules:
• If you specify a single port number, the 802.1q tag-type applies to all ports within the port region. For example, if you enter the command tag-type 9100 e 1, the BigIron RX automatically applies the 802.1q tag to ports 1 – 8 since all of these ports are in the same port region (controlled by the same DMA). Use the show
running-config command at any level of the CLI to view port regions. Note that on Gigabit Ethernet modules, ports 1 and 2 belong to the same port region.
• If the port that you specify is part of a multi-slot trunk, the device automatically applies the 802.1q tag-type to all of the ports that are part of the multi-slot trunk.
• If you do not specify a port or range of ports, the 802.1q tag-type applies to all Ethernet ports on the device.
November 2005 © 2005 Foundry Networks, Inc.
9-39
Foundry BigIron RX Series Configuration Guide
Dual-Mode VLAN Ports
Configuring a tagged port as a dual-mode port allows it to accept and transmit both tagged traffic and untagged traffic at the same time. A dual-mode port accepts and transmits frames belonging to VLANs configured for the port, as well as frames belonging to the default VLAN (that is, untagged traffic).
traffic for the default VLAN, flows from a hubs to this port. The dual-mode feature allows traffic for VLAN 20 and untagged traffic to go through the port at the same time.
Figure 9.19
Dual-mode VLAN port example
VLAN 20
Traffic
Untagged
Traffic
Hub
Port 2/11
Tagged, VLAN 20 dual-mode
Port 2/9
Tagged, VLAN 20
Port 2/10
Untagged
VLAN 20
Traffic
Untagged
Traffic
To enable the dual-mode feature on port 2/11 in Figure 9.19:
BigIron RX(config)# vlan 20
BigIron RX(config-vlan-20)# tagged e 2/11
BigIron RX(config-vlan-20)# tagged e 2/9
BigIron RX(config-vlan-20)# int e 2/11
BigIron RX(config-if-e100-2/11)# dual-mode
BigIron RX(config-if-e100-2/11)# exit
Syntax: [no] dual-mode
A dual-mode port accepts and transmits frames belonging to VLANs configured for the port, as well as frames belonging to the DEFAULT-VLAN (VLAN 1). Traffic for the DEFAULT-VLAN is transmitted untagged, and traffic for other VLANs is tagged.
You can configure a dual-mode port to transmit traffic for a specified VLAN (other than the DEFAULT-VLAN) as
9-40 © 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
Figure 9.20
Specifying a default VLAN ID for a dual-mode port
VLAN 10
Untagged
Traffic
Hub
Dual-mode Port 2/11
Default VLAN ID 10
Tagged, VLAN 20
Port 2/10
Untagged, VLAN 10
Port 2/9
Tagged, VLAN 20
VLAN 10
Untagged
Traffic
VLAN 20
Tagged
Traffic
VLAN 20
Tagged
Traffic
to this dual-mode port is 10. This means that the port transmits tagged traffic on VLAN 20 (and all other VLANs to which the port belongs) and transmits untagged traffic on VLAN 10.
The dual-mode feature allows tagged traffic for VLAN 20 and untagged traffic for VLAN 10 to go through port 2/11 at the same time. A dual-mode port transmits only untagged traffic on its default VLAN (that is, either VLAN 1, or a user-specified VLAN ID), and only tagged traffic on all other VLANs.
20, then designated a dual-mode port whose specified default VLAN is 10. In this configuration, port 2/11 transmits only untagged traffic on VLAN 10 and only tagged traffic on VLAN 20.
BigIron RX(config)# vlan 10 by port
BigIron RX(config-vlan-10)# untagged e 2/10
BigIron RX(config-vlan-10)# tagged e 2/11
BigIron RX(config-vlan-10)# exit
BigIron RX(config)# vlan 20 by port
BigIron RX(config-vlan-20)# tagged e 2/9
BigIron RX(config-vlan-20)# tagged e 2/11
BigIron RX(config-vlan-20)# exit
BigIron RX(config)# int e 2/11
BigIron RX(config-if-e100-2/11)# dual-mode 10
BigIron RX(config-if-e100-2/11)# exit
Syntax: [no] dual-mode [<vlan-id>]
Notes:
• If you do not specify a <vlan-id> in the dual mode command, the port’s default VLAN is set to 1. The port transmits untagged traffic on the DEFAULT-VLAN.
• The dual-mode feature is disabled by default. Only tagged ports can be configured as dual-mode ports.
• In trunk group, either all of the ports must be dual-mode, or none of them can be.
November 2005 © 2005 Foundry Networks, Inc.
9-41
Foundry BigIron RX Series Configuration Guide
The show vlan command displays a separate row for dual-mode ports on each VLAN. For example:
BigIron RX(config)# show vlan
Total PORT-VLAN entries: 3
Maximum PORT-VLAN entries: 16 legend: [S=Slot]
PORT-VLAN 1, Name DEFAULT-VLAN, Priority level0, Spanning tree Off
Untagged Ports: (S1) 1 2 3 4 5 6 7 8
Untagged Ports: (S2) 1 2 3 4 5 6 7 8 12 13 14 15 16 17 18 19
Untagged Ports: (S2) 20 21 22 23 24
Tagged Ports: None
Uplink Ports: None
DualMode Ports: None
PORT-VLAN 10, Name [None], Priority level0, Spanning tree Off
Untagged Ports: (S2) 10
Tagged Ports: None
Uplink Ports: None
DualMode Ports: (S2) 11
PORT-VLAN 20, Name [None], Priority level0, Spanning tree Off
Untagged Ports: None
Tagged Ports: (S2) 9
Uplink Ports: None
DualMode Ports: (S2) 11
Hardware Flooding for Layer 2 Multicast and Broadcast Packets
Broadcast and multicast packets do not have a specific recipient. In order for these "special" packets to reach their intended recipient, they needed to be sent on all ports of the VLAN (or "flooded" across the VLAN).
By default, the BigIron RX performs hardware flooding for Layer 2 multicast and broadcast packets. (Layer 2 multicast packets have a multicast address in the destination MAC address field.) However, if uplink VLANs or protocol VLANs are configured, this default behavior is overridden and software flooding is enabled.
You can disable hardware flooding for Layer 2 multicast and broadcast packets on a per-VLAN basis. For example:
BigIron RX(config)#
BigIron RX(config)# vlan 2
BigIron RX(config-vlan-2)# no multicast-flooding
BigIron RX(config-vlan-2)# exit
BigIron RX(config)# reload
Syntax: [no] multicast-flooding
After entering the multicast-flooding command for a VLAN, you must reboot the BigIron RX to activate the feature.
Notes:
• This feature is supported on the 10 Gigabit Ethernet module.
• This feature cannot be enabled on an empty VLAN; the VLAN must already have ports assigned to it prior to enabling this feature.
• This feature is not supported on Layer 3 protocol-based VLANs.
• This feature is not supported on private VLANs.
• You cannot enable this feature on the designated management VLAN for the device.
9-42 © 2005 Foundry Networks, Inc.
November 2005
Configuring Virtual LANs (VLANs)
• If you enable this feature on a VLAN that includes a trunk group, hardware flooding for Layer 2 multicast and broadcast packets occurs only on the trunk group’s primary port. Multicast and broadcast traffic for the other ports in the trunk group is handled by software.
Unicast Flooding on VLAN Ports
Unknown unicast packets do not have a specific (or unicast) recipient. In order for these "special" packets to reach their intended recipient, they needed to be sent on all ports of the VLAN (or "flooded" across the VLAN).
By default, the BigIron RX performs hardware flooding for unknown unicast packets. However, if uplink VLANs or protocol VLANs are configured, this default behavior is overridden and software flooding is enabled.
To disable unicast hardware flooding on a VLAN ports and enable software flooding, enter commands such as the following:
BigIron RX(config)# vlan 2
BigIron RX(config-vlan-2)# no unknown-unicast-flooding
BigIron RX(config-vlan-2)# exit
BigIron RX(config)# reload
Syntax: [no] unknown-unicast-flooding
Displaying VLAN Information
After you configure the VLANs, you can view and verify the configuration.
Displaying System-Wide VLAN Information
Enter the following command at any CLI level:
BigIron RX(config)# show vlan
Total PORT-VLAN entries: 2
Maximum PORT-VLAN entries: 8 legend: [S=Slot]
PORT-VLAN 1, Name DEFAULT-VLAN, Priority level0, Spanning tree Off
Untagged Ports: (S2) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Untagged Ports: (S2) 17 18 19 20 21 22 23 24
Untagged Ports: (S4) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Untagged Ports: (S4) 17 18 19 20 21 22 23 24
Tagged Ports: None
PORT-VLAN 10, Name IP_VLAN, Priority level0, Spanning tree Off
Untagged Ports: (S1) 1 2 3 4 5 6
Tagged Ports: None
November 2005 © 2005 Foundry Networks, Inc.
9-43
Foundry BigIron RX Series Configuration Guide
Displaying VLAN Information for Specific Ports
To display VLAN information for all the VLANs of which port 7/1 is a member, enter the following command:
BigIron RX(config)# show vlan e 7/1
Total PORT-VLAN entries: 3
Maximum PORT-VLAN entries: 8 legend: [S=Slot]
PORT-VLAN 100, Name [None], Priority level0, Spanning tree Off
Untagged Ports: (S7) 1 2 3 4
Tagged Ports: None
IP-subnet VLAN 207.95.11.0 255.255.255.0,
Static ports: (S7) 1 2
Exclude ports: None
Syntax: show vlan [<vlan-id> | ethernet <slot/port> | detail | | begin <expression> | exclude <expression> | include <expression>]
The <vlan-id> parameter specifies a VLAN for which you want to display the configuration information.
The ethernet <slot/port> parameter specifies a port. The command lists all the VLAN memberships for the port.
9-44 © 2005 Foundry Networks, Inc.
November 2005
Chapter 10
Configuring Spanning Tree Protocol
This chapter the Spanning Tree Protocol (STP) that are supported in the BigIron RX. The chapter contains the following sections:
•
“IEEE 802.1D Spanning Tree Protocol (STP)” on this page
•
“IEEE Single Spanning Tree (SSTP)” on page 10-10
•
•
“PVST/PVST+ Compatibility” on page 10-20
IEEE 802.1D Spanning Tree Protocol (STP)
The BigIron RX supports Spanning Tree Protocol (STP) as described in the IEEE 802.10-1998 specification. STP eliminates Layer 2 loops in networks, by selectively blocking some ports and allowing other ports to forward traffic, based on configurable bridge and port parameters. STP also ensures that the least cost path is taken when multiple paths exist between ports or VLANs. If the selected path fails, STP searches for and then establishes an alternate path to prevent or limit retransmission of data.
Enabling or Disabling STP
STP is disabled by default on the BigIron RX. Thus, new VLANs you configure on the BigIron RX have STP
disabled by default. Table 10.1 lists the default STP states for the BigIron RX.
Device Type
BigIron RX
Table 10.1: Default STP States
Default STP Type
Foundry’s multiple instances of spanning tree
Default STP State Default STP State of New VLANs
Disabled Disabled
By default, each VLAN on a BigIron RX runs a separate spanning tree instance. Each BigIron RX has one VLAN
(VLAN 1) by default that contains all of its ports. However, if you configure additional port-based VLANs on a
BigIron RX, then each of those VLANs on which STP is enabled and VLAN 1 all run separate spanning trees.
You can enable or disable STP on the following levels:
• Globally – Affects all VLANs on the BigIron RX.
November 2005 © 2005 Foundry Networks, Inc.
10-1
Foundry BigIron RX Series Configuration Guide
• Individual VLAN – Affects all ports within the specified VLAN. When you enable or disable STP within a
VLAN, the setting overrides the global setting. Thus, you can enable STP for the ports within a VLAN even when STP is globally disabled, or disable the ports within a port-based VLAN when STP is globally enabled.
• Individual port – Affects only the individual port. However, if you change the STP state of the primary port in a trunk group, the change affects all ports in the trunk group.
Enabling or Disabling STP Globally
Use the following methods to enable or disable STP on the BigIron RX on which you have not configured VLANs.
NOTE:
When you configure a VLAN, the VLAN inherits the global STP settings. However, once you begin to define a VLAN, you can no longer configure standard STP parameters globally using the CLI. From that point on, you can configure STP only within individual VLANs.
To enable STP for all ports in all VLANs on a BigIron RX, enter the following command:
BigIron RX(config)# spanning-tree
This command enables a separate spanning tree in each VLAN, including the default VLAN.
Syntax: [no] spanning-tree
Enabling or Disabling STP on a VLAN
Use the following procedure to disable or enable STP on a BigIron RX on which you have configured a VLAN.
Changing the STP state in a VLAN affects only that VLAN.
To enable STP for all ports in a port-based VLAN, enter commands such as the following:
BigIron RX(config)# vlan 10
BigIron RX(config-vlan-10)# spanning-tree
Syntax: [no] spanning-tree
Enabling or Disabling STP on a Port
Use the following procedure to disable or enable STP on an individual port.
NOTE:
If you change the STP state of the primary port in a trunk group, the change affects all ports in the trunk group.
To enable STP on an individual port, enter commands such as the following:
BigIron RX(config)# interface 1/1
BigIron RX(config-if-e1000-1/1)# spanning-tree
Syntax: [no] spanning-tree
Default STP Bridge and Port Parameters
are using MSTP, the parameters affect the VLAN. If you are using SSTP, the parameters affect all VLANs that are members of the single spanning tree.
Parameter
Forward Delay
Table 10.2: Default STP Bridge Parameters
Description
The period of time a bridge will wait (the listen and learn period) before beginning to forward data packets.
Default and Valid Values
15 seconds
Possible values: 4 – 30 seconds
10-2 © 2005 Foundry Networks, Inc.
November 2005
Configuring Spanning Tree Protocol
Parameter
Maximum Age
Hello Time
Priority
Table 10.2: Default STP Bridge Parameters (Continued)
Description
The interval a bridge will wait for a hello packet from the root bridge before initiating a topology change.
The interval of time between each configuration BPDU sent by the root bridge.
A parameter used to identify the root bridge in a spanning tree (instance of STP). The bridge with the lowest value has the highest priority and is the root.
A higher numerical value means a lower priority; thus, the highest priority is 0.
Default and Valid Values
20 seconds
Possible values: 6 – 40 seconds
2 seconds
Possible values: 1 – 10 seconds
32768
Possible values: 0 – 65535
NOTE:
If you plan to change STP bridge timers, Foundry recommends that you stay within the following ranges, from section 8.10.2 of the IEEE specification:
– 2 * (forward_delay -1) >= max_age
– max_age >= 2 * (hello_time +1 )
configurable on each port.
Parameter
Priority
Path Cost
Table 10.3: Default STP Port Parameters
Description Default and Valid Values
The preference that STP gives this port relative to other ports for forwarding traffic out of the spanning tree.
A higher numerical value means a lower priority; thus, the highest priority is 8.
The cost of using the port to reach the root bridge. When selecting among multiple links to the root bridge, STP chooses the link with the lowest path cost and blocks the other paths. Each port type has its own default STP path cost.
128
Possible values: 8 – 252, configurable in increments of 4
10 Mbps – 100
100 Mbps – 19
Gigabit – 4
10 Gigabit – 2
Possible values are 1– 65535
Changing STP Bridge Parameters
To change a BigIron RX’s STP bridge priority to the highest value, so as to make the BigIron RX the root bridge, enter the following command:
BigIron RX(config)# vlan 20
BigIron RX(config-vlan-20)# spanning-tree priority 0
To make this change in the default VLAN, enter the following commands:
BigIron RX(config)# vlan 1
BigIron RX(config-vlan-1)# spanning-tree priority 0
November 2005 © 2005 Foundry Networks, Inc.
10-3
Foundry BigIron RX Series Configuration Guide
Syntax: [no] spanning-tree [forward-delay <value>] | [hello-time <value>] | [max-age <value>] | [priority <value>]
You can specify some or all of the parameters on the same command line. For information on parameters,
possible values and defaults, refer to Table 10.2 on page 10-2.
NOTE:
The hello-time <value> parameter applies only when the device or VLAN is the root bridge for its spanning tree.
Changing STP Port Parameters
To change the path and priority costs for a port, enter commands such as the following:
BigIron RX(config)# vlan 10
BigIron RX(config-vlan-10)# spanning-tree ethernet 1/5 path-cost 15 priority 64
Syntax: spanning-tree ethernet <slot>/<portnum> path-cost <value> | priority <value> | disable | enable
The ethernet <slot>/<portnum> parameter specifies the interface.
enter a priority value that is not divisible by four, the software rounds it to the nearest value.
The disable | enable parameter disables or re-enables STP on the port. The STP state change affects only this
VLAN. The port’s STP state in other VLANs is not changed.
Displaying STP Information
You can display the following STP information:
• All the global and interface STP settings
• Detailed STP information for each interface
• STP state information for a VLAN
• STP state information for an individual interface
10-4 © 2005 Foundry Networks, Inc.
November 2005
Configuring Spanning Tree Protocol
Displaying STP Information for an Entire Device
To display STP information, enter the following command at any level of the CLI:
BigIron RX# show spanning-tree vlan 10
VLAN 10 - STP instance 1
--------------------------------------------------------------------
STP Bridge Parameters:
Bridge Bridge Bridge Bridge Hold LastTopology Topology
Identifier MaxAge Hello FwdDly Time Change Change hex sec sec sec sec sec cnt
8000000480a04000 20 2 15 1 0 0
RootBridge RootPath DesignatedBridge Root Max Hel Fwd
Identifier Cost Identifier Port Age lo Dly hex hex sec sec sec
8000000480a04000 0 8000000480a04000 Root 20 2 15
STP Port Parameters:
Port Prio Path State Designat- Designated Designated
Num rity Cost ed Cost Root Bridge
1/3 128 4 DISABLED 0 0000000000000000 0000000000000000
1/13 128 4 DISABLED 0 0000000000000000 0000000000000000
Syntax: show spanning-tree [vlan <vlan-id>] | [pvst-mode] | [<num>] |
[detail [vlan <vlan-id> [ethernet <slot/port> ] [| begin<expression> | exclude<expression> | include<expression> ]
The vlan <vlan-id> parameter displays STP information for the specified port-based VLAN.
The pvst-mode parameter displays STP information for the BigIron RX’s Per VLAN Spanning Tree (PVST+)
compatibility configuration. See “PVST/PVST+ Compatibility” on page 10-20.
The <num> parameter displays only the entries after the number you specify. For example, on a BigIron RX with three port-based VLANs, if you enter 1, then information for the second and third VLANs is displayed, but information for the first VLAN is not displayed. Information is displayed according to VLAN number, in ascending order. The entry number is not the same as the VLAN number. For example, if you have port-based VLANs 1, 10, and 2024, then the command output has three STP entries. To display information for VLANs 10 and 2024 only, enter show spanning-tree 1.
The detail parameter and its additional optional parameters display detailed information for individual ports. See
“Displaying Detailed STP Information for Each Interface” on page 10-8.
The show spanning-tree command shows the following information.
Table 10.4: CLI Display of STP Information
Displays...
This Field...
Global STP Parameters
VLAN ID The port-based VLAN that contains this spanning tree and the number of STP instance on the VLAN. VLAN 1 is the default VLAN. If you have not configured port-based VLANs on this device, all STP information is for VLAN 1.
November 2005 © 2005 Foundry Networks, Inc.
10-5
Foundry BigIron RX Series Configuration Guide
This Field...
Bridge Parameters
Bridge Identifier
Table 10.4: CLI Display of STP Information (Continued)
Displays...
Bridge MaxAge sec
Bridge Hello sec
Bridge FwdDly sec
Hold Time sec
Last Topology Chang sec
Topology Change cnt
Root Bridge Parameters
Root Identifier
Root Cost
DesignatedBridge Identifier
Root Port
Max Age sec
Hello sec
FwdDly sec
Port STP Parameters
Port Num
Priority
The ID assigned by STP to this bridge for this spanning tree in hexadecimal.
Note: If this address is the same as the Root ID, then this device or
VLAN is the root bridge for its spanning tree.
The number of seconds this bridge waits for a hello message from the root bridge before deciding the root has become unavailable and performing a reconvergence.
The interval between each configuration BPDU sent by the bridge.
The number of seconds this bridge waits following a topology change and consequent reconvergence.
The minimum number of seconds that must elapse between transmissions of consecutive Configuration BPDUs on a port.
The number of seconds since the last time a topology change occurred.
The number of times the topology has changed since this device was reloaded.
The ID assigned by STP to the root bridge for this spanning tree in hexadecimal.
The cumulative cost from this bridge to the root bridge. If this device is the root bridge, then the root cost is 0.
The designated bridge to which the root port is connected. The designated bridge is the device that connects the network segment on the port to the root bridge.
The port on this device that connects to the root bridge. If this device is the root bridge, then the value is “Root” instead of a port number.
The number of seconds this root bridge waits for a hello message from the bridges before deciding a bridges has become unavailable and performing a reconvergence.
The interval between each configuration BPDU sent by the root bridge.
The number of seconds this root bridge waits following a topology change and consequent reconvergence.
The port number.
The port’s STP priority.
Note: If you configure this value, specify it in decimal format. See
“Changing STP Port Parameters” on page 10-4.
10-6 © 2005 Foundry Networks, Inc.
November 2005
This Field...
Path Cost
State
Design Cost
Designated Root
Designated Bridge
Configuring Spanning Tree Protocol
Table 10.4: CLI Display of STP Information (Continued)
Displays...
The port’s STP path cost.
The port’s STP state. The state can be one of the following:
• BLOCKING – STP has blocked Layer 2 traffic on this port to prevent a loop. The device or VLAN can reach the root bridge using another port, whose state is FORWARDING. When a port is in this state, the port does not transmit or receive user frames, but the port does continue to receive STP BPDUs.
• DISABLED – The port is not participating in STP. This can occur when the port is disconnected or STP is disabled on the port.
• FORWARDING – STP is allowing the port to send and receive frames.
• LISTENING – STP is responding to a topology change and this port is listening for a BPDU from neighboring bridge(s) in order to determine the new topology. No user frames are transmitted or received during this state.
• LEARNING – The port has passed through the LISTENING state and will change to the BLOCKING or FORWARDING state, depending on the results of STP’s reconvergence. The port does not transmit or receive user frames during this state. However, the device can learn the MAC addresses of frames that the port receives during this state and make corresponding entries in the
MAC table.
The cost to the root bridge as advertised by the designated bridge that is connected to this port. If the designated bridge is the root bridge itself, then the cost is 0. The identity of the designated bridge is shown in the Design Bridge field.
The root bridge as recognized on this port. The value is the same as the root bridge ID listed in the Root ID field.
The bridge as recognized on this port.
November 2005 © 2005 Foundry Networks, Inc.
10-7
Foundry BigIron RX Series Configuration Guide
Displaying Detailed STP Information for Each Interface
To display the detailed STP information, enter the following command at any level of the CLI:
BigIron RX# show spanning-tree detail vlan 10
VLAN 10 - STP instance 1
--------------------------------------------------------------------
STP Bridge Parameters:
Bridge identifier - 0x8000000480a04000
Root bridge - 0x8000000480a04000
Control ports - ethe 1/3 ethe 1/13
Active global timers - None
STP Port Parameters:
Port 1/3 - DISABLED
Port 1/13 - DISABLED
VLAN 20 - STP instance 2
--------------------------------------------------------------------
STP Bridge Parameters:
Bridge identifier - 0x8000000480a04000
Root bridge - 0x8000000480a04000
Control ports - ethe 1/3 ethe 1/13
Active global timers - None
STP Port Parameters:
Port 1/3 - DISABLED
Port 1/13 - DISABLED
If a port is disabled, the only information shown by this command is “DISABLED”. If a port is enabled, this display shows the following information.
Syntax: show spanning-tree detail [vlan <vlan-id> [ethernet <slot/port>]]
The vlan <vlan-id> parameter specifies a VLAN.
The ethernet <slot>/<portnum> parameter specifies an individual port within the VLAN (if specified).
The <num> parameter specifies the number of VLANs you want the CLI to skip before displaying detailed STP information. For example, if the BigIron RX has six VLANs configured (VLAN IDs 1, 2, 3, 99, 128, and 256) and you enter the command show span detail 4, detailed STP information is displayed for VLANs 128 and 256 only.
NOTE:
If the configuration includes VLAN groups, the show span detail command displays the master VLANs of each group but not the member VLANs within the groups. However, the command does indicate that the VLAN is a master VLAN. The show span detail vlan <vlan-id> command displays the information for the VLAN even if it is a member VLAN. To list all the member VLANs within a VLAN group, enter the show vlan-group [<group-id>] command.
10-8 © 2005 Foundry Networks, Inc.
November 2005
Configuring Spanning Tree Protocol
The show spanning-tree detail command shows the following information for each VLAN participating in the spanning tree.
This Field...
VLAN ID
STP Bridge Parameters:
Bridge identifier
Root
Control ports
Active global timers
Table 10.5: CLI Display of Detailed STP Information for Ports
Displays...
The VLAN that contains the listed ports and the number of STP instances on this VLAN.
The STP type can be one of the following:
• Foundry proprietary multiple Spanning Tree
• IEEE 802.1Q Single Spanning Tree (SSTP)
Note: If STP is disabled on a VLAN, the command displays the following message instead: “Spanning-tree of port-vlan <vlan-id> is disabled.”
The STP identity of this device.
The ID assigned by STP to the root bridge for this spanning tree.
The ports in the VLAN.
The global STP timers that are currently active, and their current values. The following timers can be listed:
• Hello – The interval between Hello packets. This timer applies only to the root bridge.
• Topology Change (TC) – The amount of time during which the topology change flag in Hello packets will be marked, indicating a topology change. This timer applies only to the root bridge.
• Topology Change Notification (TCN) – The interval between
Topology Change Notification packets sent by a non-root bridge toward the root bridge. This timer applies only to non-root bridges.
STP Port Parameters:
November 2005 © 2005 Foundry Networks, Inc.
10-9
Foundry BigIron RX Series Configuration Guide
Table 10.5: CLI Display of Detailed STP Information for Ports (Continued)
This Field...
Port number and STP state
Displays...
The internal port number and the port’s STP state.
The internal port number is one of the following:
• The port’s interface number, if the port is the designated port for the LAN.
• The interface number of the designated port from the received
BPDU, if the interface is not the designated port for the LAN.
The state can be one of the following:
• BLOCKING – STP has blocked Layer 2 traffic on this port to prevent a loop. The device or VLAN can reach the root bridge using another port, whose state is FORWARDING. When a port is in this state, the port does not transmit or receive user frames, but the port does continue to receive STP BPDUs.
• DISABLED – The port is not participating in STP. This can occur when the port is disconnected or STP is administratively disabled on the port.
• FORWARDING – STP is allowing the port to send and receive frames.
• LISTENING – STP is responding to a topology change and this port is listening for a BPDU from neighboring bridge(s) in order to determine the new topology. No user frames are transmitted or received during this state.
• LEARNING – The port has passed through the LISTENING state and will change to the BLOCKING or FORWARDING state, depending on the results of STP’s reconvergence. The port does not transmit or receive user frames during this state. However, the device can learn the MAC addresses of frames that the port receives during this state and make corresponding entries in the
MAC table.
Note: If the state is DISABLED, no further STP information is displayed for the port.
IEEE Single Spanning Tree (SSTP)
By default, each port-based VLAN on the BigIron RX runs a separate spanning tree, which you can enable or disable on an individual VLAN basis.
Alternatively, you can configure the BigIron RX to run a single spanning tree across all of its ports and VLANs.
The SSTP feature is especially useful for connecting a BigIron RX to third-party devices that run a single spanning tree in accordance with the 802.1q specification.
SSTP uses the same parameters, with the same value ranges and defaults, as the default STP supported on the
BigIron RX. See “Default STP Bridge and Port Parameters” on page 10-2.
SSTP Defaults
SSTP is disabled by default. When you enable the feature, all VLANs on which STP is enabled become members of a single spanning tree. All VLANs on which STP is disabled are excluded from the single spanning tree.
• To add a VLAN to the single spanning tree, enable STP on that VLAN.
• To remove a VLAN from the single spanning tree, disable STP on that VLAN.
10-10 © 2005 Foundry Networks, Inc.
November 2005
Configuring Spanning Tree Protocol
When you enable SSTP, all the ports that are in port-based VLANs with STP enabled become members of a single spanning tree domain. Thus, the ports share a single BPDU broadcast domain. The BigIron RX places all the ports in a non-configurable VLAN, 4094, to implement the SSTP domain. However, this VLAN does not affect port membership in the port-based VLANs you have configured. Other broadcast traffic is still contained within the individual port-based VLANs. Therefore, you can use SSTP while still using your existing VLAN configurations without changing your network. In addition, SSTP does not affect 802.1q tagging. Tagged and untagged ports alike can be members of the single spanning tree domain.
NOTE:
When SSTP is enabled, the BPDUs on tagged ports go out untagged.
If you disable SSTP, all VLANs that were members of the single spanning tree run MSTP instead. In MSTP, each
VLAN has its own spanning tree. VLANs that were not members of the single spanning tree were not enabled for
STP. Therefore, STP remains disabled on those VLANs.
Enabling SSTP
NOTE:
If the BigIron RX has only one port-based VLAN (the default VLAN), then it is already running a single instance of STP. In this case, you do not need to enable SSTP. You need to enable SSTP only if the BigIron RX contains more than one port-based VLAN and you want all the ports to be in the same STP broadcast domain.
To configure the BigIron RX to run a single spanning tree, enter the following command at the global CONFIG level:
BigIron RX(config)# spanning-tree single
NOTE:
If the BigIron RX has only one port-based VLAN, the CLI command for enabling SSTP is not listed in the
CLI. The command is listed only if you have configured a port-based VLAN.
To change a global STP parameter, enter a command such as the following at the global CONFIG level:
BigIron RX(config) spanning-tree single priority 2
This command changes the STP priority for all ports to 2.
To change an STP parameter for a specific port, enter commands such as the following:
BigIron RX(config) spanning-tree single ethernet 1/1 priority 10
The commands shown above override the global setting for STP priority and set the priority to 10 for port 1/1.
Here is the syntax for the global STP parameters:
Syntax: [no] spanning-tree single [forward-delay <value>]
[hello-time <value>] | [maximum-age <time>] | [priority <value>]
Here is the syntax for the STP port parameters:
Syntax: [no] spanning-tree single [ethernet <slot>/<portnum> path-cost <value> | priority <value>]
For the parameter definitions and possible values, see “Default STP Port Parameters” on page 10-3.
NOTE:
Both commands listed above are entered at the global CONFIG level.
November 2005 © 2005 Foundry Networks, Inc.
10-11
Foundry BigIron RX Series Configuration Guide
Displaying SSTP Information
To verify that SSTP is in effect, enter the following commands at any level of the CLI:
BigIron RX(config)# show spanning-tree
VLAN 4095 - STP instance 0
--------------------------------------------------------------------
STP Bridge Parameters:
Bridge Bridge Bridge Bridge Hold LastTopology Topology
Identifier MaxAge Hello FwdDly Time Change Change hex sec sec sec sec sec cnt
8000000480a04000 20 2 15 1 0 0
RootBridge RootPath DesignatedBridge Root Max Hel Fwd
Identifier Cost Identifier Port Age lo Dly hex hex sec sec sec
8000000480a04000 0 8000000480a04000 Root 20 2 15
STP Port Parameters:
Port Prio Path State Designat- Designated Designated
Num rity Cost ed Cost Root Bridge
1/3 128 4 DISABLED 0 0000000000000000 0000000000000000
1/13 128 4 DISABLED 0 0000000000000000 0000000000000000
SSTP members: 10 20 30 99 to 100
For information on the command syntax, see “Displaying STP Information” on page 10-4.
SuperSpan™
SuperSpan is a Foundry STP enhancement that allows Service Providers (SPs) to use STP in both SP networks and customer networks. The SP devices are BigIron RX devices and are configured to tunnel each customers'
STP BPDUs through the SP. From the customer's perspective, the SP network is a loop-free non-blocking device or network. The SP network behaves like a hub in the sense that the necessary blocking occurs in the customer network, not in the SP.
The Foundry interfaces that connect the SP to a customer's network are configured as SuperSpan boundary interfaces. Each SuperSpan boundary interface is configured with a customer ID, to uniquely identify the customer's network within SuperSpan.
multiple customers. Each customer network is running its own instance of standard STP. The BigIron RX devices in the SP are running SuperSpan.
10-12 © 2005 Foundry Networks, Inc.
November 2005
Figure 10.1
SuperSpan example
Cust 1
Port 1/1
FWD
Port 1/2
BLK
Port 1/1
Port 1/2
SuperSpan root bridge
Port 1/1
Cust 2
FWD
BLK
Port 1/2
Port 2/1
Port 2/2
Configuring Spanning Tree Protocol
In this example, the SP network contains two devices that are running SuperSpan. The SP is connected to two customer networks. Each customer network is running its own instance of STP. SuperSpan prevents Layer 2 loops in the traffic flow with each customer while at the same time isolating each customer’s traffic and spanning tree from the traffic and spanning trees of other customers. For example, the SP devices provide loop prevention for Customer 1 while ensuring that Customer 1’s traffic is never forwarded to Customer 2. In this example, customer 1 has two interfaces to the SP network, ports 1/1 and 1/2 connected to SP 1. The SP network behaves like a non-blocking hub. BPDUs are tunneled through the network. To prevent a Layer 2 loop, customer 1’s port
1/2 enters the blocking state.
Customer ID
SuperSpan uses a SuperSpan customer ID to uniquely identify and forward traffic for each customer. You assign
spanning trees of customer 1 and customer 2 do not interfere with one another because the SP network isolates each customer’s spanning tree based on the SuperSpan customer IDs in the traffic.
BPDU Forwarding
When the BigIron RX receives a customer's BPDU on a boundary interface, the BigIron RX changes the destination MAC address of the BPDU from the bridge group address (01-80-c2-00-00-00) as follows:
• The first byte (locally administered bit) is changed from 01 to 03, to indicate that the BPDU needs to be tunneled.
• The fourth and fifth bytes are changed to the customer STP ID specified on the boundary interface.
For example, if the customer's STP ID is 1, the destination MAC address of the customer's BPDUs is changed to the following: 03-80-c2-00-01-00.
Each BigIron RX that is configured for SuperSpan forwards the BPDU using the changed destination MAC address. At the other end of the tunnel, the BigIron RX connected to the customer's network changes the destination MAC address back to the bridge group address (01-80-c2-00-00-00).
Preforwarding State
To ensure that the customer's network has time to converge at Layer 2 and prevent loops, the BigIron RX devices configured for SuperSpan use a special forwarding state, Preforwarding. The Preforwarding state occurs between the Learning and Forwarding states and by default lasts for five seconds. During the Preforwarding state, the
November 2005 © 2005 Foundry Networks, Inc.
10-13
Foundry BigIron RX Series Configuration Guide
BigIron RX forwards tunneled BPDUs from customers only and does not forward data traffic. This ensures that the customer’s network will detect the Layer 2 loop and block a port. The SP network remains unblocked. After the Preforwarding state, the Foundry ports change to the Forwarding state and forward data traffic as well as
BPDUs.
The default length of the Preforwarding state is five seconds. You can change the length of the Preforwarding state to a value from 3 – 30 seconds.
Figure 10.2 shows an example of how the Preforwarding state is used.
Figure 10.2
SuperSpan Preforwarding state
SuperSpan root bridge
BPDU
FWD
Preforwarding
Cust 1
BLK
During Preforwarding state, SP forwards all tunneled customer
BPDUs, allowing customer time to detect the loop and block a port.
BPDU
Preforwarding
SP
Tunneled BPD
SP
In this example, a customer has two links to the SP. Since the SP is running SuperSpan, the SP ports enter the
Preforwarding state briefly to allow the customer ports connected to the SP to detect the Layer 2 loop and block one of the ports.
NOTE:
If you add a new BigIron RX to a network that is already running SuperSpan, you must enable
SuperSpan on the BigIron RX, at least on the VLANs that will be tunneling the customer traffic. Otherwise, the new BigIron RX does not use the Preforwarding state. This can cause the wrong ports to be blocked.
Combining Single STP and Multiple Spanning Trees
You can use SuperSpan in any of the following combinations:
• Customer and SP networks both use multiple spanning trees (a separate spanning tree in each VLAN).
• Customer uses multiple spanning trees but SP uses Single STP (all STP-enabled VLANs are in the same spanning tree).
• Customer uses Single STP but SP uses multiple spanning trees.
• Customer and SP networks both use Single STP.
The following sections provide an example of each combination.
NOTE:
All the combinations listed above are supported when the boundary ports joining the SP SuperSpan domain to the client spanning trees are untagged. For example, all these combinations are valid in super aggregated VLAN configurations. If the boundary ports are tagged, you cannot use Single STP in the client network in combination with multiple spanning trees in the SP SuperSpan domain.
10-14 © 2005 Foundry Networks, Inc.
November 2005
Configuring Spanning Tree Protocol
Customer and SP Use Multiple Spanning Trees
spanning trees (a separate spanning tree in each port-based VLAN).
Figure 10.3
Customer and SP using multiple spanning trees
Customer
Region
R
10
1/1
R
20
3/1
2/1
R
100
2/2
Provider
Region
2/1
R
200
2/2 tagged to multiple vlan
R xx
Root bridge for VLAN xx stp-boundary untagged to vlan 100 (Super Aggregated VLAN)
Both the customer and SP regions are running multiple spanning trees (one per port-based VLAN) in the Layer 2 switched network. The customer network contains VLANs 10 and 20 while the SP network contains VLANs 100 and 200. Customer traffic from VLAN 10 and VLAN 20 is aggregated by VLAN 100 in the SP since the boundary ports, 2/1 on R100 and R200, are untagged members of VLAN 100. By adjusting the bridge priority on VLANs 10 and 20, the customer can select a different root bridge for each spanning tree running in the customer network.
In the above example, STP in VLAN 10 will select R10 as the root bridge and make 1/1 on R10 forwarding while blocking port 3/1 on R20. The opposite occurs for STP in VLAN 20. As a result, both links connecting the customer and SP regions are fully utilized and serve as backup links at the same time, providing loop-free, nonblocking connectivity. In the SP network, multiple STP instances are running (one for VLAN 100 and one for VLAN
200) to ensure loop-free, non-blocking connectivity in each VLAN.
SuperSPAN boundaries are configured at port 2/1 of R100 and R200. Since the customer’s traffic will be aggregated into VLAN 100 at the SP, the SP network appears to the customer to be a loop-free non-blocking hub to the customer network when port 2/2 on R200 is blocked by STP in VLAN 100.
Customer Uses Multiple Spanning Trees But SP Uses Single STP
SP network uses Single STP.
November 2005 © 2005 Foundry Networks, Inc.
10-15
Foundry BigIron RX Series Configuration Guide
Figure 10.4
Customer using multiple spanning trees and SP using Single STP
Customer
Region
R
10
1/1
R
20
3/1
2/1
R single span
2/2
Provider
Region
2/1
2/2 tagged to multiple vlan
R xx stp-boundary
Root bridge for VLAN xx untagged to vlan 100 (Super Aggregated VLAN)
Customer traffic from different VLANs is maintained by different spanning trees, while the SP network is maintained by a single spanning tree. The SP can still use multiple VLANs at the core to separate traffic from different customers. However, all VLANs will have the same network topology because they are all calculated by the single spanning tree. The loop-free, non-blocking network acts like a hub for the customer network, with boundary ports 2/1 on each device being untagged members of VLAN 100.
Traffic from all VLANs in the customer network will be aggregated through VLAN 100 at the SP. This setup leaves
hub's loop-free topology is transparent to the customer network.
Customer Uses Single STP But SP Uses Multiple Spanning Trees
multiple spanning trees.
10-16 © 2005 Foundry Networks, Inc.
November 2005
Figure 10.5
Customer using Single STP and SP using multiple spanning trees
Configuring Spanning Tree Protocol
R single span
1/1 customer
Region
3/1
2/1
R
100
2/2
Provider
Region
2/1
R
200
2/2 tagged to multiple vlan
R xx
Root bridge for VLAN xx stp-boundary untagged to vlan 100
(Super Aggregated VLAN)
In this setup, the customer network is running a single spanning tree for VLANs 10 and 20. The traffic from VLAN
10 and 20 will be carried, or aggregated by VLAN 100 at the SP’s network. The main difference between this scenario and the previous tow scenarios is that all traffic at the customer’s network now follows the same path, having the same STP root bridge in all VLANs. Therefore, the customer network will not have the ability to maximize network utilization on all its links. On the other hand, loop-free, non-blocking topology is still separately maintained by the customer network’s single spanning tree and the SP’s per-VLAN spanning tree on VLAN 100.
Customer and SP Use Single STP
Figure 10.6 shows an example of SuperSpan where the customer network and SP both use Single STP.
Figure 10.6
Customer and SP using Single STP
R single span
1/1 customer
Region
3/1
2/1
R single span
2/2
Provider
Region
2/1
2/2
R xx tagged to multiple vlan
Root bridge for VLAN xx stp-boundary untagged to vlan 100 (Super Aggregated VLAN)
In this setup, both the customer and SP networks are running a single spanning tree at Layer 2. The traffic from
VLAN 10 and 20 will be carried, or aggregated by VLAN 100 at the SP network as in the previous scenario. Loop-
November 2005 © 2005 Foundry Networks, Inc.
10-17
Foundry BigIron RX Series Configuration Guide free, non-blocking topology is still separately maintained by the customer's single spanning tree and the SP's single spanning tree.
Configuring SuperSpan
To configure the BigIron RX for SuperSpan:
• Configure each interface on the BigIron RX that is connected to customer equipment as a boundary interface.
This step enables the interface to convert the destination MAC address in the customer's BPDUs.
The software requires you to specify a SuperSpan customer ID when configuring the boundary interface. Use an ID from 1 – 65535. The customer ID uniquely identifies the customer. Use the same customer ID for each
SP interface with the same customer. When tunneling BPDUs through the Foundry network, the BigIron RX devices use the customer ID to ensure that BPDUs are forwarded only to the customer's devices, and not to other customers' devices.
• Globally enable SuperSpan. This step enables the Preforwarding state.
Configuring a Boundary Interface
BigIron RX(config)# interface 1/1
BigIron RX(config-if-e1000-1/1)# stp-boundary 1
BigIron RX(config)# interface 1/2
BigIron RX(config-if-e1000-1/2)# stp-boundary 2
These commands configure two interfaces on the BigIron RX as SuperSpan boundary interfaces. Interface
1/1 is a boundary interface with customer 1. Interface 1/2 is a boundary interface with customer 2. Each boundary interface is associated with a number, which is the SuperSpan ID. The SuperSpan ID identifies the instance of SuperSpan you are associating with the interface. Use the same SuperSpan ID for each boundary interface with the same customer. Use a different SuperSpan ID for each customer. For example, use SuperSpan
ID 1 for all the boundary interfaces with customer 1 and use SuperSpan ID 2 for all boundary interfaces with customer 2.
Syntax: [no] stp-boundary <num>
The <num> parameter specifies the SuperSpan ID. Possible values: 1 – 65535.
BigIron RX(config)# interface 2/1
BigIron RX(config-if-e1000-2/1)# stp-boundary 1
BigIron RX(config)# interface 2/2
BigIron RX(config-if-e1000-2/2)# stp-boundary 2
Enabling SuperSpan
After you configure the SuperSpan boundary interfaces, enable SuperSpan. You can enable SuperSpan globally or on an individual VLAN level. If you enable the feature globally, the feature is enabled on all VLANs.
NOTE:
If you enable the feature globally, then create a new VLAN, the new VLAN inherits the global SuperSpan state. For example, if SuperSpan is globally enabled when you create a VLAN, SuperSpan also is enabled in the new VLAN.
You also can change the length of the preforwarding state.
To globally enable SuperSpan, enter the following command:
BigIron RX(config)# super-span
Syntax: [no] super-span [preforward-delay <secs>]
The <secs> parameter specifies the length of the preforwarding state. You can specify from 3 – 15 seconds. The default is 5 seconds.
10-18 © 2005 Foundry Networks, Inc.
November 2005
Configuring Spanning Tree Protocol
SuperSpan is enabled in all VLANs on the BigIron RX. To disable SuperSpan in an individual VLAN, enter commands such as the following:
BigIron RX(config)# vlan 10
BigIron RX(config-vlan-10)# no super-span
Syntax: [no] super-span
Displaying SuperSpan Information
To display the boundary interface configuration and BPDU statistics, enter the following command:
BigIron RX(config)# show super-span
CID 1 Boundary Ports:
Port Customer Tunnel
BPDU Rx BPDU Rx
1/1 1 1
1/2 0 0
Total 1 1
CID 2 Boundary Ports:
Port Customer Tunnel
BPDU Rx BPDU Rx
2/1 0 3
2/2 0 0
Total 0 3
In this example, the BigIron RX has two SuperSpan customer IDs.
Syntax: show superspan [cid <num>]
The cid <num> parameter specifies a SuperSpan customer ID. If you do not specify a customer ID, information for all the customer IDs configured on the BigIron RX is shown.
This command shows the following information.
Table 10.6: CLI Display of SuperSpan Customer ID Information
This Field...
CID
Port
Customer BPDU Rx
Tunnel BPDU Rx
Displays...
The SuperSpan customer ID number.
The boundary port number.
The number of BPDUs received from the client spanning tree.
The number of BPDUs received from the SuperSpan tunnel.
To display general STP information, see “Displaying STP Information” on page 10-4.
November 2005 © 2005 Foundry Networks, Inc.
10-19
Foundry BigIron RX Series Configuration Guide
PVST/PVST+ Compatibility
Foundry’s support for Cisco's Per VLAN Spanning Tree plus (PVST+) allows the BigIron RX to run multiple spanning trees (MSTP) while also interoperating with IEEE 802.1Q devices
1
. Foundry ports automatically detect
PVST+ BPDUs and enable support for the BPDUs once detected.
When it is configured for MSTP, the BigIron RX can interoperate with PVST.
Overview of PVST and PVST+
Per VLAN Spanning Tree (PVST) is a Cisco proprietary protocol that allows a Cisco device to have multiple spanning trees. The Cisco device can interoperate with spanning trees on other PVST devices but cannot interoperate with IEEE 802.1Q devices. An IEEE 802.1Q device has all its ports running a single spanning tree.
PVST+ is an extension of PVST that allows a Cisco device to also interoperate with devices that are running a single spanning tree (IEEE 802.1Q).
The PVST+ support allows the BigIron RX to interoperate with PVST spanning trees and the IEEE 802.1Q spanning tree at the same time.
IEEE 802.1Q and PVST regions cannot interoperate directly but can interoperate indirectly through PVST+ regions. PVST BPDUs are tunneled through 802.1Q regions, while PVST BPDUs for VLAN 1 (the IEEE 802.1Q
regions.
Figure 10.7
Interaction of IEEE 802.1Q, PVST, and PVST+ regions
PVST BPDUs tunneled through the IEEE 802.1Q region
PVST+ Region
802.1D BPDUs
dual mode port
IEEE 802.1Q Region
802.1D BPDUs
dual mode port
PVST+ Region
Do not connect
PVST BPDUs
(over ISL trunks)
PVST BPDUs
(over ISL trunks)
PVST Region
VLAN Tags and Dual Mode
To support the IEEE 802.1Q (Common Spanning Tree) portion of PVST+, a port must be a member of VLAN 1.
Cisco devices always use VLAN 1 to support the IEEE 802.1Q portion of PVST+.
1.Cisco user documentation for PVST/PVST+ refers to the IEEE 802.1Q spanning tree as the Common
Spanning Tree (CST).
10-20 © 2005 Foundry Networks, Inc.
November 2005
Configuring Spanning Tree Protocol
For the port to also support the other VLANs (the PVST+ VLANs) in tagged mode. The port must be a dual-mode port.
The untagged frames are supported on the port’s native VLAN. By default, the native VLAN is the same as the device’s default VLAN
1
, which by default is VLAN 1. Thus, to support IEEE 802.1Q in a typical configuration, the port must be able to send and receive untagged frames for VLAN 1 and tagged frames for the other VLANs.
If you want to use tagged frames on VLAN 1, you can change the default VLAN ID to an ID other than 1. You also can specify the VLAN on which you want the port to send and receive untagged frames (the native VLAN). The
Port Native VLAN ID does not need to be the same as the default VLAN.
NOTE:
Support for the IEEE 802.1Q spanning tree always uses VLAN 1, regardless of whether the BigIron RX devices are configured to use tagged or untagged frames on the VLAN.
Enabling PVST+ Support
PVST+ support is automatically enabled when the port receives a PVST BPDU. You can manually enable the support at any time or disable the support if desired.
If you want a tagged port to also support IEEE 802.1Q BPDUs, you need to enable the dual-mode feature on the port. The dual-mode feature is disabled by default and must be enabled manually.
A port that is in PVST+ compatibility mode due to auto-detection reverts to the default MSTP mode when one of the following events occurs:
• The link is disconnected or broken
• The link is administratively disabled
• The link is disabled by interaction with the link-keepalive protocol
This allows a port that was originally interoperating with PVST+ to revert to multiple spanning tree when connected to a BigIron RX.
Enabling PVST+ Support Manually
To immediately enable PVST+ support on a port, enter commands such as the following:
BigIron RX(config)# interface ethernet 1/1
BigIron RX(config-if-e1000-1/1)# pvst-mode
Syntax: [no] pvst-mode
NOTE:
If you disable PVST+ support, the software still automatically enables PVST+ support if the port receives a BPDU with PVST+ format.
Displaying PVST+ Support Information
To display PVST+ information for ports on a BigIron RX, enter the following command at any level of the CLI:
BigIron RX(config)# show span pvst-mode
PVST+ Enabled on:
Port Method
1/1 Set by configuration
1/2 Set by configuration
2/10 Set by auto-detect
3/12 Set by configuration
4/24 Set by auto-detect
1.Cisco PVST/PVST+ documentation refers to the Default VLAN as the Default Native VLAN.
November 2005 © 2005 Foundry Networks, Inc.
10-21
Foundry BigIron RX Series Configuration Guide
Syntax: show span pvst-mode
This command displays the following information.
This Field...
Port
Method
Table 10.7: CLI Display of PVST+ Information
Displays...
The Foundry port number.
Note: The command lists information only for the ports on which
PVST+ support is enabled.
The method by which PVST+ support was enabled on the port. The method can be one of the following:
• Set by configuration – You enabled the support.
• Set by auto-detect – The support was enabled automatically when the port received a PVST+ BPDU.
Configuration Examples
The examples use two common configurations:
• Untagged IEEE 802.1Q BPDUs on VLAN 1 and tagged PVST+ BPDUs on other VLANs
• Tagged IEEE 802.1Q BPDUs on VLAN 1 and untagged BPDUs on another VLAN
Tagged Port Using Default VLAN 1 as its Port Native VLAN
tagged VLANs.
Figure 10.8
Default VLAN 1 for untagged BPDUs
Untagged IEEE BPDU for VLAN 1
Untagged PVST BPDU for VLAN 1
Tagged PVST BPDUs for VLANs 2, 3, 4
Cisco device
Port 1/1
Port 3/2
To implement this configuration, enter the following commands on the RX:
BigIron RX(config)# vlan-group 1 vlan 2 to 4
BigIron RX(config-vlan-group-1)# tagged ethernet 1/1
BigIron RX(config-vlan-group-1)# exit
BigIron RX(config)# interface ethernet 1/1
BigIron RX(config-if-e10000-1/1)# pvst-mode
These commands configure a VLAN group containing VLANs 2, 3, and 4, add port 1/1 as a tagged port to the
VLANs, and enable the dual-mode feature and PVST+ support on the port. The dual-mode feature allows the port to send and receive untagged frames for the default VLAN (VLAN 1 in this case) in addition to tagged frames for
VLANs 2, 3, and 4. Enabling the PVST+ support ensures that the port is ready to send and receive PVST+
BPDUs. If you do not manually enable PVST+ support, the support is not enabled until the port receives a PVST+
BPDU.
The configuration leaves the default VLAN and the port’s native VLAN unchanged. The default VLAN is 1 and the port’s Port Native VLAN also is 1. The dual-mode feature supports untagged frames on the default VLAN only.
Thus, port 1/1 can send and receive untagged BPDUs for VLAN 1 and can send and receive tagged BPDUs for the other VLANs.
10-22 © 2005 Foundry Networks, Inc.
November 2005
Configuring Spanning Tree Protocol
Port 1/1 will process BPDUs as follows:
• Process IEEE 802.1Q BPDUs for VLAN 1.
• Process tagged PVST BPDUs for VLANs 2, 3, and 4.
• Drop untagged PVST BPDUs for VLAN 1.
Untagged Port Using VLAN 2 as Port Native VLAN
uses untagged frames.
Figure 10.9
Port Native VLAN 2 for untagged BPDUs
Untagged IEEE BPDU for VLAN 1
Tagged PVST BPDU for VLAN 1
Untagged PVST BPDU for VLAN 2
Cisco device
Port 1/1
Port 3/2
To implement this configuration, enter the following commands on the RX:
BigIron RX(config)# default-vlan-id 4000
BigIron RX(config)# vlan 1
BigIron RX(config-vlan-1)# tagged ethernet 1/1
BigIron RX(config-vlan-1)# exit
BigIron RX(config)# vlan 2
BigIron RX(config-vlan-2)# untagged ethernet 1/1
BigIron RX(config-vlan-2)# exit
BigIron RX(config)# interface ethernet 1/1
BigIron RX(config-if-e10000-1/1)# pvst-mode
BigIron RX(config-if-e10000-1/1)# exit
These commands change the default VLAN ID, configure port 1/1 as a tagged member of VLANs 1 and 2, and enable PVST+ support on port 1/1. Since VLAN 1 is tagged in this configuration, the default VLAN ID must be changed from VLAN 1 to another VLAN ID. Changing the default VLAN ID from 1 allows the port to process tagged frames for VLAN 1. VLAN 2 is the port native VLAN. The port processes untagged frames and untagged
PVST BPDUs on VLAN 2.
Port 1/1 will process BPDUs as follows:
• Process IEEE 802.1Q BPDUs for VLAN 1.
• Process untagged PVST BPDUs for VLAN 2.
• Drop tagged PVST BPDUs for VLAN 1.
Note that when VLAN 1 is not the default VLAN, the ports must have an untagged VLAN enabled in order to process IEEE 802.1Q BPDUs.
For example, the following configuration is incorrect:
BigIron RX(config)# default-vlan-id 1000
BigIron RX(config)# vlan 1
BigIron RX(config-vlan-1)# tagged ethernet 1/1 to 1/2
BigIron RX(config-vlan-1)# exit
BigIron RX(config)# interface ethernet 1/1
BigIron RX(config-if-e10000-1/1)# pvst-mode
BigIron RX(config-if-e10000-1/1)# exit
BigIron RX(config)# interface ethernet 1/2
BigIron RX(config-if-e10000-1/2)# pvst-mode
BigIron RX(config-if-e10000-1/2)# exit
November 2005 © 2005 Foundry Networks, Inc.
10-23
Foundry BigIron RX Series Configuration Guide
In the configuration above, all PVST BPDUs associated with VLAN 1 would be discarded. Since IEEE BPDUs associated with VLAN 1 are untagged, they are discarded because the ports in VLAN 1 are tagged. Effectively, the BPDUs are never processed by the Spanning Tree Protocol. STP assumes that there is no better bridge on the network and sets the ports to FORWARDING. This could cause a Layer 2 loop.
The following configuration is correct:
BigIron RX(config)# default-vlan-id 1000
BigIron RX(config)# vlan 1
BigIron RX(config-vlan-1)# tagged ethernet 1/1 to 1/2
BigIron RX(config-vlan-1)# exit
BigIron RX(config)# interface ethernet 1/1
BigIron RX(config-if-e10000-1/1)# pvst-mode
BigIron RX(config-if-e10000-1/1)# exit
BigIron RX(config)# interface ethernet 1/2
BigIron RX(config-if-e10000-1/2)# pvst-mode
BigIron RX(config-if-e10000-1/2)# exit
Setting the ports as dual-mode ensures that the untagged IEEE 802.1Q BPDUs reach the VLAN 1 instance.
10-24 © 2005 Foundry Networks, Inc.
November 2005
Chapter 11
Configuring Rapid Spanning Tree Protocol
This chapter explains the IEEE 802.1W-2001Rapid Spanning Tree Protocols (RSTP) support on the BigIron RX.
IEEE 802.1W-2001 RSTP provides rapid traffic reconvergence for point-to-point links within a few milliseconds
(< 500 milliseconds), following the failure of a bridge or bridge port.
This reconvergence occurs more rapidly than the reconvergence provided by the IEEE 802.1D Spanning Tree
Protocol or by RSTP Draft 3 because:
• STP requires a newly selected Root port to go through listening and learning stages before traffic convergence can be achieved. The STP traffic convergence time is calculated using the following formula:
2 x FORWARD_DELAY + BRIDGE_MAX_AGE.
• Convergence in RSTP bridges is not based on any timer values. Rather, it is based on the explicit handshakes between Designated ports and their connected Root ports to achieve convergence in less than
500 milliseconds.
NOTE:
The rapid convergence will not occur on ports connected to shared media devices, such as hubs. To take advantage of the rapid convergence provided by RSTP, make sure to explicitly configure all point-to-point links in a topology.
Bridges and Bridge Port Roles
A bridge in an RSTP rapid spanning tree topology is assigned as the root bridge if it has the highest priority
(lowest bridge identifier) in the topology. Other bridges are referred to as non-root bridges.
Unique roles are assigned to ports on the root and non-root bridges. Role assignments are based on the following information contained in the BPDU (RSTp packet):
• Root bridge ID
• Path cost value
• Transmitting bridge ID
• Designated port ID
RSTP algorithm uses this information to determine if the RST BPDU received by a port is superior to the RST
BPDU that the port transmits. The two values are compared in the order as given above, starting with the Root bridge ID. The RST BPDU with a lower value is considered superior. The superiority and inferiority of the RST
BPDU is used to assign a role to a port.
November 2005 © 2005 Foundry Networks, Inc.
11-1
Foundry BigIron RX Series Configuration Guide
If the value of the received RST BPDU is the same as that of the transmitted RST BPDU, then the port ID in the
RST BPDUs are compared. The RST BPDU with the lower port ID is superior. Port roles are then calculated appropriately.
The port’s role is included in the BPDU that it transmits. The BPDU transmitted by an RSTP port is referred to as an RST BPDU, while it is operating in RSTP mode.
Ports can have one of the following roles:
• Root – Provides the lowest cost path to the root bridge from a specific bridge
• Designated – Provides the lowest cost path to the root bridge from a LAN to which it is connected
• Alternate – Provides an alternate path to the root bridge when the root port goes down
• Backup – Provides a backup to the LAN when the Designated port goes down
• Disabled – Has no role in the topology
Assignment of Port Roles
At system start-up, all RSTP-enabled bridge ports assume a Designated role. Once start-up is complete, RSTP algorithm calculates the superiority or inferiority of the RST BPDU that is received and transmitted on a port.
On a root bridge, each port is assigned a Designated port role, except for ports on the same bridge that are physically connected together. In these type of ports, the port that receives the superior RST BPDU becomes the
Backup port, while the other port becomes the Designated port.
On non-root bridges, ports are assigned as follows:
• The port that receives the RST BPDU with the lowest path cost from the root bridge becomes the Root port.
• If two ports on the same bridge are physically connected, the port that receives the superior RST BPDU becomes the Backup port, while the other port becomes the Designated port.
• If a non-root bridge already has a Root port, then the port that receives an RST BPDU that is superior to those it can transmit becomes the Alternate port.
• If the RST BPDU that a port receives is inferior to the RST BPDUs it transmits, then the port becomes a
Designated port.
• If the port is down or if RSTP is disabled on the port, that port is given the role of Disabled port. Disabled ports have no role in the topology. However, if RSTP is enabled on a port with a link down and the link of that port comes up, then that port assumes one of the following port roles: Root, Designated, Alternate, or
Backup.
The following example (Figure 11.1) explains role assignments in a simple RSTP topology.
NOTE:
All examples in this document assume that all ports in the illustrated topologies are point-to-point links and are homogeneous (they have the same path cost value) unless otherwise specified.
Switch 2 through Switch 4 are non-root bridges.
11-2 © 2005 Foundry Networks, Inc.
November 2005
Configuring Rapid Spanning Tree Protocol
Figure 11.1
Simple RSTP Topology
Switch 1
Bridge priority = 100
Port3
Port2
Port7
Port2
Port3
Port4
Port8
Switch 2
Bridge priority = 200
Switch 3
Bridge priority = 300
Port2
Port3
Port4 Port4
Port3
Switch 4
Bridge priority = 400
Ports on Switch 1
All ports on Switch 1, the root bridge, are assigned Designated port roles.
Ports on Switch 2
Port2 on Switch 2 directly connects to the root bridge; therefore, Port2 is the Root port.
Switch 2’s bridge priority value is superior to that of Switch 3 and Switch 4; therefore, the ports on Switch 2 that connect to Switch 3 and Switch 4 are given the Designated port role.
Furthermore, Port7 and Port8 on Switch 2 are physically connected. The RST BPDUs transmitted by Port7 are superior to those Port8 transmits. Therefore, Switch 2 is the Backup port and Port7 is the Designated port.
Ports on Switch 3
Port2 on Switch 3 directly connects to the Designated port on the root bridge; therefore, it assumes the Root port role.
The root path cost of the RST BPDUs received on Port4/Switch 3 is inferior to the RST BPDUs transmitted by the port; therefore, Port4/Switch 3 becomes the Designated port.
Similarly, Switch 3 has a bridge priority value inferior to Switch 2. Port3 on Switch 3 connects to Port 3 on Switch
2. This port will be given the Alternate port role, since a Root port is already established on this bridge.
Ports Switch 4
Switch 4 is not directly connected to the root bridge. It has two ports with superior incoming RST BPDUs from two separate LANs: Port3 and Port4. The RST BPDUs received on Port3 are superior to the RST BPDUs received on port 4; therefore, Port3 becomes the Root port and Port4 becomes the Alternate port.
Edge Ports and Edge Port Roles
Foundry’s implementation of RSTP allows ports that are configured as Edge ports to be present in an RSTP
not register any incoming BPDU activities.
November 2005 © 2005 Foundry Networks, Inc.
11-3
Foundry BigIron RX Series Configuration Guide
Edge ports assume Designated port roles. Port flapping does not cause any topology change events on Edge ports since RSTP does not consider Edge ports in the spanning tree calculations.
Figure 11.2
Topology with Edge Ports
Switch 1
Bridge priority = 600
Port2 Port2
Switch 2
Bridge priority = 1000
Port3 Port3
Port5
Edge Port
Switch 3
Bridge priority = 2000
Port2
Port3
Port5
Edge Port
However, if any incoming RST BPDU is received from a previously configured Edge port, RSTP automatically makes the port as a non-edge port. This is extremely important to ensure a loop free Layer 2 operation since a non-edge port is part of the active RSTP topology.
The bridge detection state module can auto-detect an Edge port and a non-edge port. An administrator can also configure a port to be an Edge port. It is recommended that Edge ports are configured explicitly to take advantage of the Edge port feature, instead of allowing the protocol to auto-detect them.
Point-to-Point Ports
To take advantage of the RSTP features, ports on an RSTP topology should be explicitly configured as point-topoint links. Shared media should not be configured as point-to-point links.
NOTE:
Configuring shared media or non-point-to-point links as point-to-point links could lead to Layer 2 loops.
Figure 11.3, a port on a bridge communicates or is connected to at least two ports.
11-4 © 2005 Foundry Networks, Inc.
November 2005
Configuring Rapid Spanning Tree Protocol
Figure 11.3
Example of Shared Media
Bridge Port States
Ports roles can have one of the following states:
• Forwarding – RSTP is allowing the port to send and receive all packets.
• Discarding – RSTP has blocked data traffic on this port to prevent a loop. The device or VLAN can reach the root bridge using another port, whose state is forwarding. When a port is in this state, the port does not transmit or receive data frames, but the port does continue to receive RST BPDUs. This state corresponds to the listening and blocking states of 802.1D.
• Learning – RSTP is allowing MAC address entries to be added to the filtering database but does not permit forwarding of data frames. The device can learn the MAC addresses of frames that the port receives during this state and make corresponding entries in the MAC table.
• Disabled – The port is not participating in RSTP. This can occur when the port is disconnected or RSTP is administratively disabled on the port.
A port on a non-root bridge with the role of Root port is always in a forwarding state. If another port on that bridge assumes the Root port role, then the old Root port moves into a discarding state as it assumes another port role.
A port on a non-root bridge with a Designated role starts in the discarding state. When that port becomes elected to the Root port role, RSTP quickly places it into a forwarding state. However, if the Designated port is an Edge port, then the port starts and stays in a forwarding state and it cannot be elected as a Root port.
A port with an Alternate or Backup role is always in a discarding state. If the port’s role changes to Designated, then the port changes into a forwarding state.
If a port on one bridge has a Designated role and that port is connected to a port on another bridge that has an
Alternate or Backup role, the port with a Designated role cannot be given a Root port role until two instances of the forward delay timer expires on that port.
Edge Port and Non-Edge Port States
As soon as a port is configured as an Edge port, it goes into a forwarding state instantly (in less than 100 msec):
When the link to a port comes up and RSTP detects that the port is an Edge port, that port instantly goes into a forwarding state.
If RSTP detects that port as a non-edge port, the port goes into a forwarding state within four seconds of link up or after two hello timer expires on the port.
Changes to Port Roles and States
To achieve convergence in a topology, a port’s role and state changes as it receives and transmits new RST
BPDUs. Changes in a port’s role and state constitute a topology change. Besides the superiority and inferiority of the RST BPDU, bridge-wide and per-port state machines are used to determine a port’s role as well as a port’s state. Port state machines also determine when port role and state changes occur.
November 2005 © 2005 Foundry Networks, Inc.
11-5
Foundry BigIron RX Series Configuration Guide
State Machines
The bridge uses the Port Role Selection state machine to determine if port role changes are required on the bridge. This state machine performs a computation when one of the following events occur:
• New information is received on any port on the bridge
• The timer expires for the current information on a port on the bridge
Each port uses the following state machines:
• Port Information – This state machine keeps track of spanning-tree information currently used by the port. It records the origin of the information and ages out any information that was derived from an incoming BPDU.
• Port Role Transition – This state machine keeps track of the current port role and transitions the port to the appropriate role when required. It moves the Root port and the Designated port into forwarding states and moves the Alternate and Backup ports into discarding states.
• Port Transmit – This state machine is responsible for BPDU transmission. It checks to ensure only the maximum number of BPDUs per hello interval are sent every second. Based on what mode it is operating in, it sends out either legacy BPDUs or RST BPDUs. In this document legacy BPDUs are also referred to as STP
BPDUs.
• Port Protocol Migration – This state machine deals with compatibility with 802.1D bridges. When a legacy
BPDU is detected on a port, this state machine configures the port to transmit and receive legacy BPDUs and operate in the legacy mode.
• Topology Change – This state machine detects, generates, and propagates topology change notifications. It acknowledges Topology Change Notice (TCN) messages when operating in 802.1D mode. It also flushes the
MAC table when a topology change event takes place.
• Port State Transition – This state machine transitions the port to a discarding, learning, or forwarding state and performs any necessary processing associated with the state changes.
• Port Timers – This state machine is responsible for triggering any of the state machines described above, based on expiration of specific port timers.
In contrast to the 802.1D standard, the RSTP standard does not have any bridge specific timers. All timers in the
CLI are applied on a per-port basis, even though they are configured under bridge parameters.
RSTP state machines attempt to quickly place the ports into either a forwarding or discarding state. Root ports are quickly placed in forwarding state when both of the following events occur:
• It is assigned to be the Root port.
• It receives an RST BPDU with a proposal flag from a Designated port. The proposal flag is sent by ports with a Designated role when they are ready to move into a forwarding state.
When a the role of Root port is given to another port, the old Root port is instructed to reroot. The old Root port goes into a discarding state and negotiates with its peer port for a new role and a new state. A peer port is the port
port of Port2 of Switch 100.
A port with a Designated role is quickly placed into a forwarding state if one of the following occurs:
• The Designated port receives an RST BPDU that contains an agreement flag from a Root port
• The Designated port is an Edge port
However, a Designated port that is attached to an Alternate port or a Backup port must wait until the forward delay timer expires twice on that port while it is still in a Designated role, before it can proceed to the forwarding state.
Backup ports are quickly placed into discarding states.
Alternate ports are quickly placed into discarding states.
11-6 © 2005 Foundry Networks, Inc.
November 2005
Configuring Rapid Spanning Tree Protocol
A port operating in RSTP mode may enter a learning state to allow MAC address entries to be added to the filtering database; however, this state is transient and lasts only a few milliseconds, if the port is operating in RSTP mode and if the port meets the conditions for rapid transition.
Handshake Mechanisms
To rapidly transition a Designated or Root port into a forwarding state, the Port Role Transition state machine uses handshake mechanisms to ensure loop free operations. It uses one type of handshake if no Root port has been assigned on a bridge, and another type if a Root port has already been assigned.
Handshake When No Root Port is Elected
If a Root port has not been assigned on a bridge, RSTP uses the Proposing -> Proposed -> Sync -> Synced ->
Agreed handshake:
• Proposing – The Designated port on the root bridge sends an RST BPDU packet to its peer port that contains a proposal flag. The proposal flag is a signal that indicates that the Designated port is ready to put itself in a
• Proposed – When a port receives an RST BPDU with a proposal flag from the Designated port on its point-to-
point link, it asserts the Proposed signal and one of the following occurs (Figure 11.4):
• If the RST BPDU that the port receives is superior to what it can transmit, the port assumes the role of a
Root port. (See the section on “Bridges and Bridge Port Roles” on page 11-1.)
• If the RST BPDU that the port receives is inferior to what it can transmit, then the port is given the role of
Designated port.
NOTE:
Proposed will never be asserted if the port is connected on a shared media link.
In Figure 11.4, Port3/Switch 200 is elected as the Root port
November 2005 © 2005 Foundry Networks, Inc.
11-7
Foundry BigIron RX Series Configuration Guide
Figure 11.4
Proposing and Proposed Stage
RST BPDU sent with a
Proposal flag
Port2
Designated port
Proposing
Port1
Root port
Proposed
Switch 100
Root Bridge
Switch 200
Port2
Port3
Switch 300
Port2
Port3
Switch 400
11-8 © 2005 Foundry Networks, Inc.
November 2005
Configuring Rapid Spanning Tree Protocol
• Sync – Once the Root port is elected, it sets a sync signal on all the ports on the bridge. The signal tells the
Designated port change into a discarding state. These ports have to negotiate with their peer ports to establish their new roles and states.
Figure 11.5
Sync Stage
Port2
Sync
Discarding
Port1
Designated port
Switch 100
Root Bridge
Port1
Root port
Sync
BigIron
Switch 200
Port3
Sync
Discarding
Port2
Port3
Switch 300
Switch 400
Indicates a signal
November 2005 © 2005 Foundry Networks, Inc.
11-9
Foundry BigIron RX Series Configuration Guide
• Synced – Once the Designated port changes into a discarding state, it asserts a synced signal. Immediately,
Alternate ports and Backup ports are synced. The Root port monitors the synced signals from all the bridge
Figure 11.6
Synced Stage
Port2
Synced
Discarding
Port1
Designated port
Switch 100
Root Bridge
Port1
Root port
Synced
BigIron
Switch 200
Port3
Synced
Discarding
Port2
Port3
Switch 300
Switch 400
Indicates a signal
11-10 © 2005 Foundry Networks, Inc.
November 2005
Configuring Rapid Spanning Tree Protocol
• Agreed – The Root port sends back an RST BPDU containing an agreed flag to its peer Designated port and moves into the forwarding state. When the peer Designated port receives the RST BPDU, it rapidly transitions into a forwarding state.
Figure 11.7
Agree Stage
Switch 100
Root Bridge
Port1
Designated port
Forwarding
RST BPDU sent with an Agreed flag
Port1
Root port
Synced
Forwarding
BigIron
Switch 200
Port2
Synced
Discarding
Port3
Synced
Discarding
Port2
Port3
Switch 300
Switch 400
Indicates a signal
At this point, the handshake mechanism is complete between Switch 100, the root bridge, and Switch 200.
Switch 200 updates the information on the Switch 200’s Designated ports (Port2 and Port3) and identifies the new root bridge. The Designated ports send RST BPDUs, containing proposal flags, to their downstream bridges, without waiting for the hello timers to expire on them. This process starts the handshake with the downstream bridges.
For example, Port2/Switch 200 sends an RST BPDU to Port2/Switch 300 that contains a proposal flag. Port2/
Switch 300 asserts a proposed signal. Ports in Switch 300 then set sync signals on the ports to synchronize and negotiate their roles and states. Then the ports assert a synced signal and when the Root port in Switch 300 asserts it’s synced signal, it sends an RST BPDU to Switch 200 with an agreed flag.
This handshake is repeated between Switch 200 and Switch 400 until all Designated and Root ports are in forwarding states.
November 2005 © 2005 Foundry Networks, Inc.
11-11
Foundry BigIron RX Series Configuration Guide
Handshake When a Root Port Has Been Elected
11.8, a new root bridge is added to the topology.
Figure 11.8
Addition of a New Root Bridge
Switch 100
Port2
Designated port
Port2 Switch 60
Port1 Port4
Designated port
Switch 200
Port2
Port1
Root port
Port4
Port3
Port2
Port3
Switch 300
Switch 400
11-12 © 2005 Foundry Networks, Inc.
November 2005
Configuring Rapid Spanning Tree Protocol
The handshake that occurs between Switch 60 and Switch 100 follows the one described in the previous section
and establishes a Root port (Figure 11.9).
However, since Switch 200 already had a Root port in a forwarding state, RSTP uses the Proposing -> Proposed
-> Sync and Reroot -> Sync and Rerooted -> Rerooted and Synced -> Agreed handshake:
• Proposing and Proposed – The Designated port on the new root bridge (Port4/Switch 60) sends an RST
BPDU that contains a proposing signal to Port4/Switch 200 to inform the port that it is ready to put itself in a
forwarding state (Figure 11.9). RSTP algorithm determines that the RST BPDU that Port4/Switch 200
received is superior to what it can generate, so Port4/Switch 200 assumes a Root port role.
Figure 11.9
New Root Bridge Sending a Proposal Flag
Switch 100
Handshake
Completed
Port2
Designated port
Port2
Root port
Switch 60
Port1
Port4
Designated port
Proposing
Proposing
Port1
Root port
Forwarding
RST BPDU sent with a Proposing flag
Switch 200
Port2
Port3
Port4
Designated port
Proposed
Switch 300
Port2
Port3
Switch 400
November 2005 © 2005 Foundry Networks, Inc.
11-13
Foundry BigIron RX Series Configuration Guide
• Sync and Reroot – The Root port then asserts a sync and a reroot signal on all the ports on the bridge. The signal tells the ports that a new Root port has been assigned and they are to renegotiate their new roles and states. The other ports on the bridge assert their sync and reroot signals. Information about the old Root port
is discarded from all ports. Designated ports change into discarding states (Figure 11.10).
Figure 11.10
Sync and Reroot
Switch 100
Port2
Designated port
Port1
Port2
Root port
Switch 60
Port4
Designated port
Proposing
Switch 200
Port2
Sync
Reroot
Proposing
Discarding
Port1
Root port
Sync
Reroot
Forwarding
BigIron
Port3
Sync
Reroot
Discarding
Port4
Root port
Sync
Reroot
Discarding
Port2
Port3
Switch 300
Switch 400
Indicates a signal
11-14 © 2005 Foundry Networks, Inc.
November 2005
Configuring Rapid Spanning Tree Protocol
• Sync and Rerooted – When the ports on Switch 200 have completed the reroot phase, they assert their rerooted signals and continue to assert their sync signals as they continue in their discarding states. They
also continue to negotiate their roles and states with their peer ports (Figure 11.11).
Figure 11.11
Sync and Rerooted
Switch 100
Port2
Designated port
Port2
Root port
Switch 60
Port1
Port4
Designated port
Switch 200
Port2
Sync
Rerooted
Discarding
Proposing
Port1
Designated port
Sync
Rerooted
Discarding
BigIron
Port3
Sync
Rerooted
Discarding
Port4
Root port
Sync
Rerooted
Discarding
Switch 300
Port2
Port3
Switch 400
Indicates an 802.1W signal controlled by the current Root port
November 2005 © 2005 Foundry Networks, Inc.
11-15
Foundry BigIron RX Series Configuration Guide
• Synced and Agree – When all the ports on the bridge assert their synced signals, the new Root port asserts
its own synced signal and sends an RST BPDU to Port4/Switch 60 that contains an agreed flag (Figure
11.11). The Root port also moves into a forwarding state.
Figure 11.12
Rerooted, Synced, and Agreed
Switch 100
Port2
Designated port
Port2
Root port
Switch 60
Port1
Port4
Designated port
Forwarding
Proposing
Switch 200
Port2
Rerooted
Synced
Discarding
Port1
Rerooted
Synced
Discarding
BigIron
Port3
Rerooted
Synced
Discarding
Port4
Root port
Rerooted
Synced
Forwarding
RST BPDU sent with an Agreed flag
Port2
Port3
Switch 300
Switch 400
Indicates a signal
to appropriate roles.
The Designated port on Switch 60 goes into a forwarding state once it receives the RST BPDU with the agreed flag.
11-16 © 2005 Foundry Networks, Inc.
November 2005
Configuring Rapid Spanning Tree Protocol
Figure 11.13
Handshake Completed After Election of New Root Port
Switch 100
Port2
Designated port
Port2
Root port
Port1
Proposing
Switch 200
Proposing
Port1
Alternate port
Port4
Root port
Port3
Proposing
Switch 60
Port4
Designated port
Port2
Port3
Switch 300
Switch 400
Recall that Switch 200 sent the agreed flag to Port4/Switch 60 and not to Port1/Switch 100 (the port that connects
Switch 100 to Switch 200). Therefore, Port1/Switch 100 does not go into forwarding state instantly. It waits until two instances of the forward delay timer expires on the port before it goes into forwarding state.
At this point the handshake between the Switch 60 and Switch 200 is complete.
The remaining bridges (Switch 300 and Switch 400) may have to go through the reroot handshake if a new Root port needs to be assigned.
Convergence in a Simple Topology
The examples in this section illustrate how RSTP convergence occurs in a simple Layer 2 topology at start-up.
NOTE:
The remaining examples assume that the appropriate handshake mechanisms occur as port roles and states change.
November 2005 © 2005 Foundry Networks, Inc.
11-17
Foundry BigIron RX Series Configuration Guide
Convergence at Start Up
Port3/Switch 2 and Port3/Switch 3.
Figure 11.14
Convergence Between Two Bridges
Bridge priority = 1500
Routing Switch 2
Port3
Designated port
Port3
Root port
Routing Switch 3
Bridge priority = 2000
At power up, all ports on Switch 2 and Switch 3 assume Designated port roles and are at discarding states before they receive any RST BPDU.
Port3/Switch 2, with a Designated role, transmits an RST BPDU with a proposal flag to Port3/Switch 3. A ports with a Designated role sends the proposal flag in its RST BPDU when they are ready to move to a forwarding state.
Port3/Switch 3, which starts with a role of Designated port, receives the RST BPDU and finds that it is superior to what it can transmit; therefore, Port3/Switch 3 assumes a new port role, that of a Root port. Port3/Switch 3 transmits an RST BPDU with an agreed flag back to Switch 2 and immediately goes into a forwarding state.
Port3/Switch 2 receives the RST BPDU from Port3/Switch 3 and immediately goes into a forwarding state.
Now RSTP has fully converged between the two bridges, with Port3/Switch 3 as an operational root port in forwarding state and Port3/Switch 2 as an operational Designated port in forwarding state.
11-18 © 2005 Foundry Networks, Inc.
November 2005
Configuring Rapid Spanning Tree Protocol
Next, Switch 1 is powered up (Figure 11.15).
Figure 11.15
Simple Layer 2 Topology
Bridge priority = 1500
Port3
Designated port
Switch 2
Port2
Root port
Port3
Designated port
Port2
Designated port
Switch 1
Port4
Designated port
Port5
Backup port
Bridge priority = 1000
Port3
Alternate port
Bridge priority = 2000
Port4
Root port
Switch 3
The point-to-point connections between the three bridges are as follows:
• Port2/Switch 1 and Port2/Switch 2
• Port4/Switch 1 and Port4/Switch 3
• Port3/Switch 2 and Port3/Switch 3
Ports 3 and 5 on Switch 1 are physically connected together.
At start up, the ports on Switch 1 assume Designated port roles, which are in discarding state. They begin sending
RST BPDUs with proposal flags to move into a forwarding state.
When Port4/Switch 3 receives these RST BPDUs RSTP algorithm determines that they are better than the RST
BPDUs that were previously received on Port3/Switch 3. Port4/Switch 3 is now selected as Root port. This new assignment signals Port3/Switch 3 to begin entering the discarding state and to assume an Alternate port role. As it goes through the transition, Port3/Switch 3 negotiates a new role and state with its peer port, Port3/Switch 2.
Port4/Switch 3 sends an RST BPDU with an agreed flag to Port4/Switch 1. Both ports go into forwarding states.
Port2/Switch 2 receives an RST BPDU. The RSTP algorithm determines that these RST BPDUs that are superior to any that any port on Switch 2 can transmit; therefore, Port2/Switch 2 assumes the role of a Root port.
The new Root port then signals all ports on the bridge to start synchronization. Since none of the ports are Edge ports, they all enter the discarding state and assume the role of Designated ports. Port3/Switch 2, which previously had a Designated role with a forwarding state, starts the discarding state. They also negotiate port roles and states with their peer ports. Port3/Switch 2 also sends an RST BPU to Port3/Switch 3 with a proposal flag to request permission go into a forwarding state.
The Port2/Switch 2 bridge also sends an RST BPDU with an agreed flag Port2/Switch 1 that Port2 is the new Root port. Both ports go into forwarding states.
Now, Port3/Switch 3 is currently in a discarding state and is negotiating a port role. It received RST BPDUs from
Port3/Switch 2. The RSTP algorithm determines that the RST BPDUs Port3/Switch 3 received are superior to those it can transmit; however, they are not superior to those that are currently being received by the current Root port (Port4). Therefore, Port3 retains the role of Alternate port.
November 2005 © 2005 Foundry Networks, Inc.
11-19
Foundry BigIron RX Series Configuration Guide
Ports 3/Switch 1 and Port5/Switch 1 are physically connected. Port5/Switch 1 received RST BPDUs that are superior to those received on Port3/Switch 1; therefore, Port5/Switch 1 is given the Backup port role while Port3 is given the Designated port role. Port3/Switch 1, does not go directly into a forwarding state. It waits until the forward delay time expires twice on that port before it can proceed to the forwarding state.
Once convergence is achieved, the active Layer 2 forwarding path converges as shown in Figure 11.16.
Figure 11.16
Active Layer 2 Path
Bridge priority = 1500
Port3
Designated port
Switch 2
Port2
Root port
Port3
Designated port
Port2
Designated port
Switch 1
Port4
Designated port
Port5
Backup port
Bridge priority = 1000
Port3
Alternate port
Bridge priority = 2000
Port4
Root port
Switch 3
Indicates the active Layer 2 path
11-20 © 2005 Foundry Networks, Inc.
November 2005
Configuring Rapid Spanning Tree Protocol
Convergence After a Link Failure
What happens if a link in the RSTP topology fails?
For example, Port2/Switch, which is the port that connects Switch 2 to the root bridge (Switch 1), fails. Both Switch
2 and Switch 1 notice the topology change (Figure 11.17).
Figure 11.17
Link Failure in the Topology
Bridge priority = 1500
Switch 2
Port3
Port2
Port3
Port2
Switch 1
Port5
Bridge priority = 1000
Port4
Port3
Port4
Bridge priority = 2000
Switch 3
Switch 1 sets its Port2 into a discarding state.
At the same time, Switch 2 assumes the role of a root bridge since its root port failed and it has no operational
Alternate port. Port3/Switch 2, which currently has a Designated port role, sends an RST BPDU to Switch 3. The
RST BPDU contains a proposal flag and a bridge ID of Switch 2 as its root bridge ID.
When Port3/Switch 3 receives the RST BPDUs, RSTP algorithm determines that they are inferior to those that the port can transmit. Therefore, Port3/Switch 3 is given a new role, that of a Designated port. Port3/Switch 3 then sends an RST BPDU with a proposal flag to Switch 2, along with the new role information. However, the root bridge ID transmitted in the RST BPDU is still Switch 1.
When Port3/Switch 2 receives the RST BPDU, RSTP algorithm determines that it is superior to the RST BPDU that it can transmit; therefore, Port3/Switch 2 receives a new role; that of a Root port. Port3/Switch 2 then sends an RST BPDU with an agreed flag to Port3/Switch 3. Port3/Switch 2 goes into a forwarding state.
When Port3/Switch 3 receives the RST BPDU that Port3/Switch 2 sent, Port3/Switch 3 changes into a forwarding state, which then completes the full convergence of the topology.
Convergence at Link Restoration
When Port2/Switch 2 is restored, both Switch 2 and Switch 1 recognize the change. Port2/Switch 1 starts assuming the role of a Designated port and sends an RST BPDU containing a proposal flag to Port2/Switch 2.
When Port2/Switch 2 receives the RST BPDUs, RSTP algorithm determines that the RST BPDUs the port received are better than those received on Port3/Switch 3; therefore, Port2/Switch 2 is given the role of a Root port. All the ports on Switch 2 are informed that a new Root port has been assigned which then signals all the ports to synchronize their roles and states. Port3/Switch 2, which was the previous Root port, enters a discarding state and negotiates with other ports on the bridge to establish its new role and state, until it finally assumes the role of a Designated port.
November 2005 © 2005 Foundry Networks, Inc.
11-21
Foundry BigIron RX Series Configuration Guide
Next, the following happens:
• Port3/Switch 2, the Designated port, sends an RST BPDU, with a proposal flag to Port3/Switch 3.
• Port2/Switch 2 also sends an RST BPDU with an agreed flag to Port2/Switch 1 and then places itself into a forwarding state.
When Port2/Switch 1 receives the RST BPDU with an agreed flag sent by Port2/Switch 2, it puts that port into a forwarding state. The topology is now fully converged.
When Port3/Switch 3 receives the RST BPDU that Port3/Switch 2 sent, RSTP algorithm determines that these
RST BPDUs are superior to those that Port3/Switch 3 can transmit. Therefore, Port3/Switch 3 is given a new role, that of an Alternate port. Port3/Switch 3 immediately enters a discarding state.
Now Port3/Switch 2 does not go into a forwarding state instantly like the Root port. It waits until the forward delay timer expires twice on that