Foundry Networks FSX Manual

Foundry FastIron X-Series

Configuration Guide

FastIron Edge Switch X-Series

FastIron Workgroup Switch X-Series

FastIron SuperX Switch

™

2100 Gold Street

P.O. Box 649100

San Jose, CA 95164-9100

Tel 408.586.1700

Fax 408.586.1900

December 2005

Copyright © 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

C

HAPTER

1

A

BOUT

T

HIS

G

UIDE

..................................................................................... 1-1

I NTRODUCTION ...........................................................................................................................................1-1

W HAT ’ S I NCLUDED IN T HIS E DITION ? ...........................................................................................................1-2

A UDIENCE ..................................................................................................................................................1-3

N OMENCLATURE .........................................................................................................................................1-3

R ELATED P UBLICATIONS .............................................................................................................................1-3

H OW TO G ET H ELP .....................................................................................................................................1-4

W EB A CCESS .......................................................................................................................................1-4

E MAIL A CCESS .....................................................................................................................................1-4

T ELEPHONE A CCESS ............................................................................................................................1-4

W ARRANTY C OVERAGE ...............................................................................................................................1-4

C

HAPTER

2

G

ETTING

F

AMILIAR WITH

M

ANAGEMENT

A

PPLICATIONS

................................ 2-1

L OGGING ON T HROUGH THE CLI .................................................................................................................2-1

O N -L INE H ELP .....................................................................................................................................2-2

C OMMAND C OMPLETION .......................................................................................................................2-2

S CROLL C ONTROL ................................................................................................................................2-2

L INE E DITING C OMMANDS .....................................................................................................................2-3

U SING S LOT AND P ORT N UMBERS WITH CLI C OMMANDS ......................................................................2-3

S EARCHING AND F ILTERING O UTPUT FROM CLI C OMMANDS ..................................................................2-4

U SING S PECIAL C HARACTERS IN R EGULAR E XPRESSIONS .....................................................................2-6

L OGGING O N T HROUGH THE W EB M ANAGEMENT I NTERFACE .......................................................................2-8

N AVIGATING THE W EB M ANAGEMENT I NTERFACE ..................................................................................2-9

L OGGING ON T HROUGH I RON V IEW N ETWORK M ANAGER ............................................................................2-11

C

HAPTER

3

C

ONFIGURING

B

ASIC

S

OFTWARE

F

EATURES

................................................ 3-1

C ONFIGURING B ASIC S YSTEM P ARAMETERS ................................................................................................3-2

December 2005 © Foundry Networks, Inc.

iii

Foundry Configuration Guide for the FESX, FSX, and FWSX

E NTERING S YSTEM A DMINISTRATION I NFORMATION ...............................................................................3-2

C ONFIGURING S IMPLE N ETWORK M ANAGEMENT P ROTOCOL (SNMP) P ARAMETERS ...............................3-3

C ONFIGURING AN I NTERFACE AS THE S OURCE FOR A LL T ELNET P ACKETS .............................................3-7

C ANCELLING AN O UTBOUND T ELNET S ESSION ......................................................................................3-7

C ONFIGURING AN I NTERFACE AS THE S OURCE FOR A LL TFTP P ACKETS ................................................3-7

S PECIFYING A S IMPLE N ETWORK T IME P ROTOCOL (SNTP) S ERVER ......................................................3-8

S ETTING THE S YSTEM C LOCK .............................................................................................................3-10

L IMITING B ROADCAST , M ULTICAST , AND U NKNOWN U NICAST T RAFFIC .................................................3-11

C ONFIGURING CLI B ANNERS ..............................................................................................................3-11

C ONFIGURING B ASIC P ORT P ARAMETERS ..................................................................................................3-13

A SSIGNING A P ORT N AME ..................................................................................................................3-13

M ODIFYING P ORT S PEED ...................................................................................................................3-13

E NABLING A UTO NEGOTIATION M AXIMUM P ORT S PEED A DVERTISEMENT AND

P ORT S PEED D OWN SHIFT ...........................................................................................................3-14

M ODIFYING P ORT D UPLEX M ODE .......................................................................................................3-15

C ONFIGURING MDI/MDIX ...................................................................................................................3-16

D ISABLING OR R E -E NABLING A P ORT ..................................................................................................3-16

D ISABLING OR R E -E NABLING F LOW C ONTROL .....................................................................................3-17

C HANGING THE G IGABIT F IBER N EGOTIATION M ODE ............................................................................3-17

M ODIFYING P ORT P RIORITY (Q O S) .....................................................................................................3-17

E NABLING D YNAMIC C ONFIGURATION OF V OICE OVER IP (V O IP) P HONES ............................................3-17

C

HAPTER

4

C

ONFIGURING

B

ASIC

L

AYER

2 F

EATURES

................................................... 4-1

A BOUT P ORT R EGIONS ...............................................................................................................................4-2

E NABLING OR D ISABLING THE S PANNING T REE P ROTOCOL (STP) ................................................................4-2

M ODIFYING STP B RIDGE AND P ORT P ARAMETERS ................................................................................4-3

C HANGING THE MAC A GE T IME ..................................................................................................................4-3

C ONFIGURING S TATIC MAC E NTRIES ..........................................................................................................4-3

E NABLING P ORT -B ASED VLAN S .................................................................................................................4-4

A SSIGNING IEEE 802.1Q T AGGING TO A P ORT .....................................................................................4-5

D EFINING MAC A DDRESS F ILTERS ..............................................................................................................4-5

C ONFIGURATION N OTES .......................................................................................................................4-5

C OMMAND S YNTAX ..............................................................................................................................4-6

E NABLING L OGGING OF P ACKETS D ENIED BY MAC F ILTERS ..................................................................4-7

L OCKING A P ORT T O R ESTRICT A DDRESSES ...............................................................................................4-7

C ONFIGURATION N OTES .......................................................................................................................4-7

C OMMAND S YNTAX ..............................................................................................................................4-8

D ISPLAYING AND M ODIFYING S YSTEM P ARAMETER D EFAULT S ETTINGS ........................................................4-8

C ONFIGURING P ORT M IRRORING AND M ONITORING ...................................................................................4-12

C ONFIGURATION C ONSIDERATIONS .....................................................................................................4-12

C OMMAND S YNTAX ............................................................................................................................4-12

iv © Foundry Networks, Inc.

December 2005

Contents

C

HAPTER

5

C

ONFIGURING

B

ASE

L

AYER

3

AND

E

NABLING

R

OUTING

P

ROTOCOLS

......................................................... 5-1

A DDING A S TATIC IP R OUTE .......................................................................................................................5-2

A DDING A S TATIC ARP E NTRY ....................................................................................................................5-2

M ODIFYING AND D ISPLAYING L AYER 3 S YSTEM P ARAMETER L IMITS ..............................................................5-3

C ONFIGURATION N OTE .........................................................................................................................5-3

M ODIFYING L AYER 3 S YSTEM P ARAMETER L IMITS .................................................................................5-3

D ISPLAYING L AYER 3 S YSTEM P ARAMETER L IMITS ................................................................................5-4

C ONFIGURING RIP ......................................................................................................................................5-4

E NABLING RIP .....................................................................................................................................5-4

E NABLING R EDISTRIBUTION OF IP S TATIC R OUTES INTO RIP .................................................................5-5

E NABLING R EDISTRIBUTION ..................................................................................................................5-6

E NABLING L EARNING OF D EFAULT R OUTES ...........................................................................................5-6

C HANGING THE R OUTE L OOP P REVENTION M ETHOD .............................................................................5-6

O THER L AYER 3 P ROTOCOLS ......................................................................................................................5-7

E NABLING OR D ISABLING R OUTING P ROTOCOLS ..........................................................................................5-7

E NABLING OR D ISABLING L AYER 2 S WITCHING .............................................................................................5-7

C ONFIGURATION N OTES .......................................................................................................................5-7

C OMMAND S YNTAX ..............................................................................................................................5-8

C

HAPTER

6

C

ONFIGURING

P

OWER

O

VER

E

THERNET

...................................................... 6-1

P OWER OVER E THERNET O VERVIEW ...........................................................................................................6-1

T ERMS U SED IN T HIS S ECTION .............................................................................................................6-2

M ETHODS FOR D ELIVERING POE .........................................................................................................6-2

A UTODISCOVERY ..................................................................................................................................6-4

P OWER C LASS .....................................................................................................................................6-4

P OWER S PECIFICATIONS ......................................................................................................................6-4

C ABLING R EQUIREMENTS .....................................................................................................................6-5

S UPPORTED P OWERED D EVICES ..........................................................................................................6-5

E NABLING OR D ISABLING P OWER OVER E THERNET ......................................................................................6-5

E NABLING THE D ETECTION OF POE P OWER R EQUIREMENTS

A DVERTISED VIA CDP ..........................................................................................................................6-6

C ONFIGURATION C ONSIDERATIONS .......................................................................................................6-6

C OMMAND S YNTAX ..............................................................................................................................6-6

S ETTING THE M AXIMUM P OWER L EVEL FOR A POE P OWER C ONSUMING D EVICE .........................................6-6

C ONFIGURATION N OTES .......................................................................................................................6-6

C OMMAND S YNTAX ..............................................................................................................................6-7

S ETTING THE P OWER C LASS FOR A POE P OWER C ONSUMING D EVICE ........................................................6-7

C ONFIGURATION N OTES .......................................................................................................................6-7

C OMMAND S YNTAX ..............................................................................................................................6-8

S ETTING THE I N LINE P OWER P RIORITY FOR A POE P ORT ...........................................................................6-8

C OMMAND S YNTAX ..............................................................................................................................6-9

R ESETTING POE P ARAMETERS ...................................................................................................................6-9

December 2005 © Foundry Networks, Inc.

v

Foundry Configuration Guide for the FESX, FSX, and FWSX

D ISPLAYING P OWER OVER E THERNET I NFORMATION ..................................................................................6-10

D ISPLAYING POE O PERATIONAL S TATUS ............................................................................................6-10

D ISPLAYING D ETAILED I NFORMATION A BOUT POE P OWER S UPPLIES ..................................................6-13

C

HAPTER

7

C

ONFIGURING

S

PANNING

T

REE

P

ROTOCOL

(STP)

AND

I

RON

S

PAN

F

EATURES

......................................................................... 7-1

C HAPTER C ONTENTS ..................................................................................................................................7-1

STP O VERVIEW ..........................................................................................................................................7-2

C ONFIGURING S TANDARD STP P ARAMETERS ..............................................................................................7-2

STP P ARAMETERS AND D EFAULTS .......................................................................................................7-2

E NABLING OR D ISABLING THE S PANNING T REE P ROTOCOL (STP) .........................................................7-4

C HANGING STP B RIDGE AND P ORT P ARAMETERS .................................................................................7-5

STP P ROTECTION E NHANCEMENT ........................................................................................................7-6

D ISPLAYING STP I NFORMATION ............................................................................................................7-8

C ONFIGURING I RON S PAN F EATURES .........................................................................................................7-16

F AST P ORT S PAN ...............................................................................................................................7-16

802.1W R APID S PANNING T REE (RSTP) ............................................................................................7-18

802.1W D RAFT 3 ...............................................................................................................................7-53

S INGLE S PANNING T REE (SSTP) ........................................................................................................7-56

STP PER VLAN G ROUP .....................................................................................................................7-58

PVST/PVST+ C OMPATIBILITY ..................................................................................................................7-61

O VERVIEW OF PVST AND PVST+ ......................................................................................................7-62

VLAN T AGS AND D UAL M ODE ............................................................................................................7-62

C ONFIGURING PVST+ S UPPORT ........................................................................................................7-63

D ISPLAYING PVST+ S UPPORT I NFORMATION ......................................................................................7-64

C ONFIGURATION E XAMPLES ...............................................................................................................7-64

C

HAPTER

8

C

ONFIGURING

M

ETRO

F

EATURES

................................................................ 8-1

T OPOLOGY G ROUPS ...................................................................................................................................8-1

M ASTER VLAN AND M EMBER VLAN S ...................................................................................................8-2

C ONTROL P ORTS AND F REE P ORTS ......................................................................................................8-2

C ONFIGURATION C ONSIDERATIONS .......................................................................................................8-2

C ONFIGURING A T OPOLOGY G ROUP ......................................................................................................8-3

D ISPLAYING T OPOLOGY G ROUP I NFORMATION ......................................................................................8-3

M ETRO R ING P ROTOCOL (MRP) .................................................................................................................8-5

C ONFIGURATION N OTES .......................................................................................................................8-6

MRP R INGS W ITHOUT S HARED I NTERFACES (MRP P HASE 1) ...............................................................8-6

R ING I NITIALIZATION ............................................................................................................................8-7

H OW R ING B REAKS A RE D ETECTED AND H EALED .................................................................................8-8

M ASTER VLAN S AND C USTOMER VLAN S .............................................................................................8-9

C ONFIGURING MRP ...........................................................................................................................8-11

U SING MRP D IAGNOSTICS .................................................................................................................8-12

D ISPLAYING MRP I NFORMATION .........................................................................................................8-13

vi © Foundry Networks, Inc.

December 2005

Contents

MRP CLI E XAMPLE ...........................................................................................................................8-16

V IRTUAL S WITCH R EDUNDANCY P ROTOCOL (VSRP) .................................................................................8-18

L AYER 2 AND L AYER 3 R EDUNDANCY ..................................................................................................8-19

M ASTER E LECTION AND F AILOVER ......................................................................................................8-20

VSRP-A WARE S ECURITY F EATURES ..................................................................................................8-24

VSRP P ARAMETERS ..........................................................................................................................8-24

C ONFIGURING B ASIC VSRP P ARAMETERS ..........................................................................................8-27

C ONFIGURING O PTIONAL VSRP P ARAMETERS ....................................................................................8-28

D ISPLAYING VSRP I NFORMATION .......................................................................................................8-34

C

HAPTER

9

C

ONFIGURING

U

NI

-D

IRECTIONAL

L

INK

D

ETECTION

(UDLD) ......................... 9-1

UDLD O VERVIEW .......................................................................................................................................9-1

C ONFIGURATION C ONSIDERATIONS ..............................................................................................................9-2

E NABLING UDLD ........................................................................................................................................9-2

C HANGING THE K EEPALIVE I NTERVAL ..........................................................................................................9-3

C HANGING THE K EEPALIVE R ETRIES ...........................................................................................................9-3

UDLD FOR T AGGED P ORTS ........................................................................................................................9-3

D ISPLAYING UDLD I NFORMATION ................................................................................................................9-4

D ISPLAYING I NFORMATION FOR A LL P ORTS ...........................................................................................9-4

D ISPLAYING I NFORMATION FOR A S INGLE P ORT ....................................................................................9-5

C LEARING UDLD S TATISTICS .....................................................................................................................9-6

C

HAPTER

10

C

ONFIGURING

T

RUNK

G

ROUPS

AND

D

YNAMIC

L

INK

A

GGREGATION

.......................................................... 10-1

T RUNK G ROUP O VERVIEW ........................................................................................................................10-1

T RUNK G ROUP C ONNECTIVITY TO A S ERVER ......................................................................................10-2

T RUNK G ROUP R ULES ........................................................................................................................10-3

T RUNK G ROUP C ONFIGURATION E XAMPLES ........................................................................................10-4

T RUNK G ROUP L OAD S HARING ...........................................................................................................10-6

C ONFIGURING A T RUNK G ROUP ................................................................................................................10-7

E XAMPLE 1: C ONFIGURING THE T RUNK G ROUPS S HOWN IN F IGURE 10.1 ...........................................10-8

E XAMPLE 2: C ONFIGURING A T RUNK G ROUP T HAT S PANS M ULTIPLE

G IGABIT E THERNET M ODULES IN A C HASSIS D EVICE ....................................................................10-8

CLI S YNTAX .......................................................................................................................................10-9

A DDITIONAL T RUNKING O PTIONS ........................................................................................................10-9

D ISPLAYING T RUNK G ROUP C ONFIGURATION I NFORMATION .....................................................................10-11

D YNAMIC L INK A GGREGATION .................................................................................................................10-13

C ONFIGURATION E XAMPLE ...............................................................................................................10-13

C ONFIGURATION N OTES ...................................................................................................................10-15

A DAPTATION TO T RUNK D ISAPPEARANCE ..........................................................................................10-15

F LEXIBLE T RUNK E LIGIBILITY ............................................................................................................10-16

C OMMAND S YNTAX ..........................................................................................................................10-17

L INK A GGREGATION P ARAMETERS ....................................................................................................10-18

December 2005 © Foundry Networks, Inc.

vii

Foundry Configuration Guide for the FESX, FSX, and FWSX

D ISPLAYING AND D ETERMINING THE S TATUS OF A GGREGATE L INKS .........................................................10-22

A BOUT B LOCKED P ORTS ..................................................................................................................10-23

D ISPLAYING L INK A GGREGATION AND P ORT S TATUS I NFORMATION ....................................................10-23

D ISPLAYING T RUNK G ROUP AND LACP S TATUS I NFORMATION ..........................................................10-26

C LEARING THE N EGOTIATED A GGREGATE L INKS T ABLE ...........................................................................10-26

C

HAPTER

11

C

ONFIGURING

V

IRTUAL

LAN

S

(VLAN

S

).................................................... 11-1

VLAN O VERVIEW ....................................................................................................................................11-2

T YPES OF VLAN S ..............................................................................................................................11-2

D EFAULT VLAN .................................................................................................................................11-6

802.1Q T AGGING ...............................................................................................................................11-7

S PANNING T REE P ROTOCOL (STP) ....................................................................................................11-8

V IRTUAL R OUTING I NTERFACES ..........................................................................................................11-9

VLAN AND V IRTUAL R OUTING I NTERFACE G ROUPS ...........................................................................11-10

D YNAMIC , S TATIC , AND E XCLUDED P ORT M EMBERSHIP .....................................................................11-10

S UPER A GGREGATED VLAN S ...........................................................................................................11-13

T RUNK G ROUP P ORTS AND VLAN M EMBERSHIP ...............................................................................11-13

S UMMARY OF VLAN C ONFIGURATION R ULES ....................................................................................11-13

R OUTING B ETWEEN VLAN S ....................................................................................................................11-14

V IRTUAL R OUTING I NTERFACES (L AYER 3 S WITCHES O NLY ) ..............................................................11-14

B RIDGING AND R OUTING THE S AME P ROTOCOL S IMULTANEOUSLY

ON THE S AME D EVICE (L AYER 3 S WITCHES O NLY ) .....................................................................11-14

R OUTING B ETWEEN VLAN S U SING V IRTUAL R OUTING I NTERFACES (L AYER 3 S WITCHES O NLY ) .........11-14

D YNAMIC P ORT A SSIGNMENT (L AYER 2 S WITCHES AND L AYER 3 S WITCHES ) .....................................11-15

A SSIGNING A D IFFERENT VLAN ID TO THE D EFAULT VLAN ..............................................................11-15

A SSIGNING T RUNK G ROUP P ORTS ....................................................................................................11-15

C ONFIGURING P ORT -B ASED VLAN S .................................................................................................11-15

M ODIFYING A P ORT -B ASED VLAN ....................................................................................................11-18

C ONFIGURING IP S UB NET , IPX N ETWORK AND P ROTOCOL -B ASED VLAN S .............................................11-21

C ONFIGURATION E XAMPLE ...............................................................................................................11-21

C ONFIGURING IP S UB NET , IPX N ETWORK , AND

P ROTOCOL -B ASED VLAN S W ITHIN P ORT -B ASED VLAN S ..................................................................11-23

C ONFIGURING AN IP V 6 P ROTOCOL VLAN ...............................................................................................11-26

R OUTING B ETWEEN VLAN S U SING V IRTUAL R OUTING I NTERFACES (L AYER 3 S WITCHES O NLY ) ...............11-27

C ONFIGURING P ROTOCOL VLAN S W ITH D YNAMIC P ORTS .......................................................................11-33

A GING OF D YNAMIC P ORTS ..............................................................................................................11-33

C ONFIGURATION G UIDELINES ...........................................................................................................11-33

C ONFIGURING AN IP, IPX, OR A PPLE T ALK P ROTOCOL VLAN WITH D YNAMIC P ORTS ..........................11-33

C ONFIGURING AN IP S UB -N ET VLAN WITH D YNAMIC P ORTS .............................................................11-34

C ONFIGURING AN IPX N ETWORK VLAN WITH D YNAMIC P ORTS .........................................................11-34

C ONFIGURING U PLINK P ORTS W ITHIN A P ORT -B ASED VLAN ...................................................................11-35

C ONFIGURING THE S AME IP S UB -N ET A DDRESS ON M ULTIPLE P ORT -B ASED VLAN S ...............................11-35

U SING S EPARATE ACL S ON IP F OLLOWER V IRTUAL R OUTING I NTERFACES ........................................11-39

C ONFIGURING VLAN G ROUPS AND V IRTUAL R OUTING I NTERFACE G ROUPS .............................................11-40

C ONFIGURING A VLAN G ROUP .........................................................................................................11-40

viii © Foundry Networks, Inc.

December 2005

Contents

C ONFIGURING A V IRTUAL R OUTING I NTERFACE G ROUP .....................................................................11-41

D ISPLAYING THE VLAN G ROUP AND V IRTUAL R OUTING I NTERFACE G ROUP I NFORMATION ..................11-42

A LLOCATING M EMORY FOR M ORE VLAN S OR V IRTUAL R OUTING I NTERFACES ...................................11-42

C ONFIGURING S UPER A GGREGATED VLAN S ...........................................................................................11-43

C ONFIGURING A GGREGATED VLAN S ................................................................................................11-45

V ERIFYING THE C ONFIGURATION .......................................................................................................11-47

C OMPLETE CLI E XAMPLES ...............................................................................................................11-47

C ONFIGURING 802.1QIN -Q T AGGING .....................................................................................................11-49

C ONFIGURATION R ULES ...................................................................................................................11-51

E NABLING 802.1QIN -Q T AGGING ....................................................................................................11-51

E XAMPLE C ONFIGURATION ...............................................................................................................11-52

C ONFIGURING P RIVATE VLAN S ..............................................................................................................11-52

I MPLEMENTATION N OTES ..................................................................................................................11-54

C OMMAND S YNTAX ..........................................................................................................................11-54

E NABLING B ROADCAST OR U NKNOWN U NICAST T RAFFIC TO THE P RIVATE VLAN ...............................11-55

CLI E XAMPLE FOR F IGURE 11.21 .....................................................................................................11-56

D UAL -M ODE VLAN P ORTS .....................................................................................................................11-56

D ISPLAYING VLAN I NFORMATION ............................................................................................................11-59

D ISPLAYING S YSTEM -W IDE VLAN I NFORMATION ...............................................................................11-59

D ISPLAYING VLAN I NFORMATION FOR S PECIFIC P ORTS ....................................................................11-60

C

HAPTER

12

R

ULE

-B

ASED

IP A

CCESS

C

ONTROL

L

ISTS

(ACL

S

) .................................... 12-1

ACL O VERVIEW ........................................................................................................................................12-2

T YPES OF IP ACL S ............................................................................................................................12-2

ACL ID S AND E NTRIES .......................................................................................................................12-2

N UMBERED AND N AMED ACL S ...........................................................................................................12-3

D EFAULT ACL A CTION .......................................................................................................................12-3

H OW H ARDWARE -B ASED ACL S W ORK ......................................................................................................12-3

H OW F RAGMENTED P ACKETS ARE P ROCESSED ...................................................................................12-3

H ARDWARE A GING OF L AYER 4 CAM E NTRIES ...................................................................................12-4

C ONFIGURATION C ONSIDERATIONS ............................................................................................................12-4

C ONFIGURING S TANDARD N UMBERED ACL S .............................................................................................12-4

S TANDARD N UMBERED ACL S YNTAX ..................................................................................................12-5

C ONFIGURATION E XAMPLE FOR S TANDARD N UMBERED ACL S .............................................................12-6

C ONFIGURING S TANDARD N AMED ACL S ...................................................................................................12-6

S TANDARD N AMED ACL S YNTAX ........................................................................................................12-6

C ONFIGURATION E XAMPLE FOR S TANDARD N AMED ACL S ...................................................................12-8

C ONFIGURING E XTENDED N UMBERED ACL S ..............................................................................................12-8

E XTENDED N UMBERED ACL S YNTAX ..................................................................................................12-8

C ONFIGURATION E XAMPLES FOR E XTENDED N UMBERED ACL S .........................................................12-12

C ONFIGURING E XTENDED N AMED ACL S ..................................................................................................12-13

E XTENDED N AMED ACL S YNTAX ......................................................................................................12-15

C ONFIGURATION E XAMPLE FOR E XTENDED N AMED ACL S .................................................................12-18

A DDING A C OMMENT TO AN ACL E NTRY .................................................................................................12-18

E NABLING S TRICT C ONTROL OF ACL F ILTERING OF F RAGMENTED P ACKETS ............................................12-20

December 2005 © Foundry Networks, Inc.

ix

Foundry Configuration Guide for the FESX, FSX, and FWSX

E NABLING ACL F ILTERING B ASED ON VLAN M EMBERSHIP OR

VE P ORT M EMBERSHIP ....................................................................................................................12-20

A PPLYING AN ACL TO S PECIFIC VLAN M EMBERS ON A P ORT (L AYER 2 D EVICES O NLY ) ...................12-21

A PPLYING AN ACL TO A S UBSET OF P ORTS ON A V IRTUAL I NTERFACE (L AYER 3 D EVICES O NLY ) .......12-21

F ILTERING ON IP P RECEDENCE AND T O S V ALUES ...................................................................................12-22

Q O S O PTIONS FOR IP ACL S ..................................................................................................................12-23

U SING AN ACL TO M AP THE DSCP V ALUE (DSCP C O S M APPING ) ..................................................12-23

U SING AN IP ACL TO M ARK DSCP V ALUES (DSCP M ARKING ) .........................................................12-23

DSCP M ATCHING ............................................................................................................................12-24

ACL-B ASED R ATE L IMITING ....................................................................................................................12-24

ACL C OUNTING ......................................................................................................................................12-25

U SING ACL S TO C ONTROL M ULTICAST F EATURES ...................................................................................12-25

D ISPLAYING ACL I NFORMATION ..............................................................................................................12-25

T ROUBLESHOOTING ACL S ......................................................................................................................12-25

C

HAPTER

13

C

ONFIGURING

Q

UALITY OF

S

ERVICE

.......................................................... 13-1

C LASSIFICATION .......................................................................................................................................13-1

P ROCESSING OF C LASSIFIED T RAFFIC .................................................................................................13-2

Q O S Q UEUES ..........................................................................................................................................13-6

A SSIGNING Q O S P RIORITIES TO T RAFFIC ............................................................................................13-7

M ARKING ..................................................................................................................................................13-8

C ONFIGURING DSCP-B ASED Q O S ............................................................................................................13-8

A PPLICATION N OTES ..........................................................................................................................13-8

U SING ACL S TO H ONOR DSCPBASED Q O S ......................................................................................13-8

C ONFIGURING THE Q O S M APPINGS ...........................................................................................................13-8

D EFAULT DSCP –> I NTERNAL F ORWARDING P RIORITY M APPINGS .......................................................13-9

C HANGING THE DSCP –> I NTERNAL F ORWARDING P RIORITY M APPINGS ............................................13-10

C HANGING THE I NTERNAL F ORWARDING P RIORITY –> H ARDWARE F ORWARDING Q UEUE M APPINGS ...13-10

S CHEDULING ..........................................................................................................................................13-11

Q O S Q UEUING M ETHODS .................................................................................................................13-11

S ELECTING THE Q O S Q UEUING M ETHOD ..........................................................................................13-12

C ONFIGURING THE Q O S Q UEUES .....................................................................................................13-12

V IEWING Q O S S ETTINGS ........................................................................................................................13-15

V IEWING DSCPBASED Q O S S ETTINGS ..................................................................................................13-16

C

HAPTER

14

C

ONFIGURING

R

ATE

L

IMITING

.................................................................... 14-1

O VERVIEW ................................................................................................................................................14-1

R ATE L IMITING IN H ARDWARE .............................................................................................................14-1

H OW F IXED R ATE L IMITING W ORKS ....................................................................................................14-2

C ONFIGURATION N OTES .....................................................................................................................14-2

C ONFIGURING A P ORT -B ASED R ATE L IMITING P OLICY ................................................................................14-3

C ONFIGURING AN ACL-B ASED R ATE L IMITING P OLICY ...............................................................................14-3

O PTIMIZING R ATE L IMITING .......................................................................................................................14-3

D ISPLAYING THE F IXED R ATE L IMITING C ONFIGURATION ............................................................................14-4

x © Foundry Networks, Inc.

December 2005

Contents

C

HAPTER

15

T

RAFFIC

P

OLICIES

.................................................................................... 15-1

A BOUT T RAFFIC P OLICIES .........................................................................................................................15-1

C ONFIGURATION N OTES AND F EATURE L IMITATIONS ..................................................................................15-2

M AXIMUM N UMBER OF T RAFFIC P OLICIES S UPPORTED ON A D EVICE ..........................................................15-3

S ETTING THE M AXIMUM N UMBER OF T RAFFIC P OLICIES S UPPORTED ON A L AYER 3 D EVICE .................15-3

ACL-B ASED R ATE L IMITING VIA T RAFFIC P OLICIES ....................................................................................15-3

S UPPORT FOR F IXED R ATE L IMITING AND A DAPTIVE R ATE L IMITING .....................................................15-4

C ONFIGURING ACL-B ASED F IXED R ATE L IMITING ................................................................................15-4

C ONFIGURING ACL-B ASED A DAPTIVE R ATE L IMITING ..........................................................................15-5

S PECIFYING THE A CTION TO BE T AKEN FOR P ACKETS THAT ARE O VER THE L IMIT .................................15-6

ACL AND R ATE L IMIT C OUNTING ...............................................................................................................15-7

E NABLING ACL C OUNTING .................................................................................................................15-8

E NABLING ACL C OUNTING WITH R ATE L IMITING T RAFFIC P OLICIES .....................................................15-8

V IEWING ACL A ND R ATE L IMIT C OUNTERS .........................................................................................15-9

C LEARING ACL AND R ATE L IMIT C OUNTERS .....................................................................................15-10

V IEWING T RAFFIC P OLICIES ....................................................................................................................15-10

C

HAPTER

16

C

ONFIGURING

IP....................................................................................... 16-1

B ASIC C ONFIGURATION .............................................................................................................................16-1

O VERVIEW ................................................................................................................................................16-2

IP I NTERFACES ..................................................................................................................................16-2

IP P ACKET F LOW T HROUGH A L AYER 3 S WITCH .................................................................................16-3

IP R OUTE E XCHANGE P ROTOCOLS .....................................................................................................16-7

IP M ULTICAST P ROTOCOLS ................................................................................................................16-7

IP I NTERFACE R EDUNDANCY P ROTOCOLS ...........................................................................................16-8

A CCESS C ONTROL L ISTS AND IP A CCESS P OLICIES ............................................................................16-8

B ASIC IP P ARAMETERS AND D EFAULTS – L AYER 3 S WITCHES ....................................................................16-8

W HEN P ARAMETER C HANGES T AKE E FFECT .......................................................................................16-9

IP G LOBAL P ARAMETERS – L AYER 3 S WITCHES ..................................................................................16-9

IP I NTERFACE P ARAMETERS – L AYER 3 S WITCHES ...........................................................................16-13

B ASIC IP P ARAMETERS AND D EFAULTS – L AYER 2 S WITCHES ..................................................................16-15

IP G LOBAL P ARAMETERS – L AYER 2 S WITCHES ................................................................................16-15

I NTERFACE IP P ARAMETERS – L AYER 2 S WITCHES ...........................................................................16-17

C ONFIGURING IP P ARAMETERS – L AYER 3 S WITCHES .............................................................................16-17

C ONFIGURING IP A DDRESSES ..........................................................................................................16-17

C ONFIGURING D OMAIN N AME S ERVER (DNS) R ESOLVER ..................................................................16-19

C ONFIGURING P ACKET P ARAMETERS ................................................................................................16-20

C HANGING THE R OUTER ID ..............................................................................................................16-23

S PECIFYING A S INGLE S OURCE I NTERFACE FOR T ELNET , TACACS/TACACS+,

OR RADIUS P ACKETS ...............................................................................................................16-24

C ONFIGURING ARP P ARAMETERS ....................................................................................................16-25

C ONFIGURING F ORWARDING P ARAMETERS .......................................................................................16-29

D ISABLING ICMP M ESSAGES ...........................................................................................................16-31

December 2005 © Foundry Networks, Inc.

xi

Foundry Configuration Guide for the FESX, FSX, and FWSX

C ONFIGURING S TATIC R OUTES .........................................................................................................16-32

C ONFIGURING A D EFAULT N ETWORK R OUTE .....................................................................................16-39

C ONFIGURING IP L OAD S HARING ......................................................................................................16-41

C ONFIGURING IRDP .........................................................................................................................16-44

C ONFIGURING RARP .......................................................................................................................16-45

C ONFIGURING UDP B ROADCAST AND IP H ELPER P ARAMETERS ........................................................16-47

C ONFIGURING B OOT P/DHCP F ORWARDING P ARAMETERS ................................................................16-49

C ONFIGURING IP P ARAMETERS – L AYER 2 S WITCHES .............................................................................16-51

C ONFIGURING THE M ANAGEMENT IP A DDRESS AND S PECIFYING THE D EFAULT G ATEWAY ..................16-51

C ONFIGURING D OMAIN N AME S ERVER (DNS) R ESOLVER ..................................................................16-51

C HANGING THE TTL T HRESHOLD ......................................................................................................16-53

C ONFIGURING DHCP A SSIST ...........................................................................................................16-53

D ISPLAYING IP C ONFIGURATION I NFORMATION AND S TATISTICS ...............................................................16-57

C HANGING THE N ETWORK M ASK D ISPLAY TO P REFIX F ORMAT ..........................................................16-57

D ISPLAYING IP I NFORMATION – L AYER 3 S WITCHES ..........................................................................16-57

D ISPLAYING IP I NFORMATION – L AYER 2 S WITCHES ..........................................................................16-74

C

HAPTER

17

C

ONFIGURING

RIP .................................................................................... 17-1

RIP O VERVIEW .........................................................................................................................................17-1

ICMP H OST U NREACHABLE M ESSAGE FOR U NDELIVERABLE ARP S .....................................................17-2

RIP P ARAMETERS AND D EFAULTS .............................................................................................................17-2

RIP G LOBAL P ARAMETERS .................................................................................................................17-2

RIP I NTERFACE P ARAMETERS ............................................................................................................17-3

C ONFIGURING RIP P ARAMETERS ..............................................................................................................17-4

E NABLING RIP ...................................................................................................................................17-4

C ONFIGURING M ETRIC P ARAMETERS ..................................................................................................17-4

C HANGING THE A DMINISTRATIVE D ISTANCE ........................................................................................17-5

C ONFIGURING R EDISTRIBUTION ..........................................................................................................17-6

C ONFIGURING R OUTE L EARNING AND A DVERTISING P ARAMETERS .......................................................17-7

C HANGING THE R OUTE L OOP P REVENTION M ETHOD ...........................................................................17-8

S UPPRESSING RIP R OUTE A DVERTISEMENT ON A VRRP OR VRRPE B ACKUP I NTERFACE ...................17-9

C ONFIGURING RIP R OUTE F ILTERS ....................................................................................................17-9

D ISPLAYING RIP F ILTERS ........................................................................................................................17-10

D ISPLAYING CPU U TILIZATION S TATISTICS ..............................................................................................17-11

C

HAPTER

18

C

ONFIGURING

IP M

ULTICAST

T

RAFFIC

R

EDUCTION

.................................... 18-1

O VERVIEW ................................................................................................................................................18-1

S UPPORT FOR IGMP V2 S NOOPING IN L AYER 3 S OFTWARE I MAGES ..........................................................18-2

C ONFIGURING IP M ULTICAST T RAFFIC R EDUCTION ....................................................................................18-2

E NABLING IP M ULTICAST T RAFFIC R EDUCTION ....................................................................................18-2

C HANGING THE IGMP M ODE ..............................................................................................................18-3

D ISABLING IGMP ON I NDIVIDUAL P ORTS .............................................................................................18-3

M ODIFYING THE Q UERY I NTERVAL ......................................................................................................18-4

M ODIFYING THE A GE I NTERVAL ...........................................................................................................18-4

xii © Foundry Networks, Inc.

December 2005

Contents

F ILTERING M ULTICAST G ROUPS ..........................................................................................................18-4

PIM SM T RAFFIC S NOOPING ....................................................................................................................18-5

C ONFIGURATION N OTES .....................................................................................................................18-5

A PPLICATION E XAMPLES .....................................................................................................................18-5

C ONFIGURATION R EQUIREMENTS ........................................................................................................18-7

E NABLING PIM SM T RAFFIC S NOOPING ..............................................................................................18-8

D ISPLAYING IP M ULTICAST I NFORMATION ..................................................................................................18-8

D ISPLAYING M ULTICAST I NFORMATION ON L AYER 2 S WITCHES ............................................................18-8

D ISPLAYING IP M ULTICAST S TATISTICS .............................................................................................18-16

C LEARING IP M ULTICAST S TATISTICS ...............................................................................................18-16

C LEARING IGMP G ROUP F LOWS ......................................................................................................18-16

C

HAPTER

19

C

ONFIGURING

IP M

ULTICAST

P

ROTOCOLS

................................................. 19-1

O VERVIEW OF IP M ULTICASTING ...............................................................................................................19-2

M ULTICAST T ERMS .............................................................................................................................19-2

C HANGING G LOBAL IP M ULTICAST P ARAMETERS .......................................................................................19-3

C HANGING D YNAMIC M EMORY A LLOCATION FOR IP M ULTICAST G ROUPS .............................................19-3

C HANGING IGMP V1 AND V2 P ARAMETERS ........................................................................................19-5

A DDING AN I NTERFACE TO A M ULTICAST G ROUP .......................................................................................19-6

PIM D ENSE .............................................................................................................................................19-6

I NITIATING PIM M ULTICASTS ON A N ETWORK ......................................................................................19-6

P RUNING A M ULTICAST T REE .............................................................................................................19-7

G RAFTS TO A M ULTICAST T REE ..........................................................................................................19-8

PIM DM V ERSIONS ............................................................................................................................19-8

C ONFIGURING PIM DM .....................................................................................................................19-9

F AILOVER T IME IN A M ULTI -P ATH T OPOLOGY ....................................................................................19-13

M ODIFYING THE TTL ........................................................................................................................19-13

PIM S PARSE .........................................................................................................................................19-13

PIM S PARSE R OUTER T YPES ...........................................................................................................19-14

RP P ATHS AND SPT P ATHS .............................................................................................................19-15

C ONFIGURING PIM S PARSE ..............................................................................................................19-15

D ISPLAYING PIM S PARSE C ONFIGURATION I NFORMATION AND S TATISTICS .........................................19-20

D ROPPING PIM T RAFFIC IN H ARDWARE ...................................................................................................19-31

R ELEASE 02.2.00 ............................................................................................................................19-31

E NHANCEMENT IN R ELEASE 02.3.01 .................................................................................................19-31

C ONFIGURATION S YNTAX .................................................................................................................19-32

C ONFIGURING M ULTICAST S OURCE D ISCOVERY P ROTOCOL (MSDP) .......................................................19-32

P EER R EVERSE P ATH F ORWARDING (RPF) F LOODING ......................................................................19-34

S OURCE A CTIVE C ACHING ................................................................................................................19-34

C ONFIGURING MSDP .......................................................................................................................19-34

D ESIGNATING AN I NTERFACE ’ S IP A DDRESS AS THE RP’ S IP A DDRESS ..............................................19-35

F ILTERING MSDP S OURCE -G ROUP P AIRS ........................................................................................19-36

C ONFIGURING MSDP M ESH G ROUPS ...............................................................................................19-38

D ISPLAYING MSDP I NFORMATION .....................................................................................................19-46

C LEARING MSDP I NFORMATION .......................................................................................................19-52

December 2005 © Foundry Networks, Inc.

xiii

Foundry Configuration Guide for the FESX, FSX, and FWSX

DVMRP O VERVIEW ................................................................................................................................19-52

I NITIATING DVMRP M ULTICASTS ON A N ETWORK .............................................................................19-53

P RUNING A M ULTICAST T REE ...........................................................................................................19-53

G RAFTS TO A M ULTICAST T REE ........................................................................................................19-55

C ONFIGURING DVMRP ...........................................................................................................................19-55

E NABLING DVMRP ON THE L AYER 3 S WITCH AND I NTERFACE ...........................................................19-55

M ODIFYING DVMRP G LOBAL P ARAMETERS ......................................................................................19-56

M ODIFYING DVMRP I NTERFACE P ARAMETERS .................................................................................19-58

D ISPLAYING I NFORMATION A BOUT AN U PSTREAM N EIGHBOR D EVICE .................................................19-59

C ONFIGURING AN IP T UNNEL ..................................................................................................................19-59

U SING ACL S TO C ONTROL M ULTICAST F EATURES ...................................................................................19-60

U SING ACL S TO L IMIT S TATIC RP G ROUPS ......................................................................................19-60

U SING ACL S TO L IMIT PIM RP C ANDIDATE A DVERTISEMENT ............................................................19-61

U SING ACL S TO C ONTROL M ULTICAST T RAFFIC B OUNDARIES ...........................................................19-62

C ONFIGURING A S TATIC M ULTICAST R OUTE ............................................................................................19-63

T RACING A M ULTICAST R OUTE ................................................................................................................19-64

D ISPLAYING A NOTHER M ULTICAST R OUTER ’ S M ULTICAST C ONFIGURATION ..............................................19-66

C

HAPTER

20

C

ONFIGURING

OSPF ................................................................................ 20-1

O VERVIEW OF OSPF ................................................................................................................................20-1

OSPF P OINT TO -P OINT L INKS ............................................................................................................20-3

D ESIGNATED R OUTERS IN M ULTI -A CCESS N ETWORKS .........................................................................20-4

D ESIGNATED R OUTER E LECTION IN M ULTI -A CCESS N ETWORKS ...........................................................20-4

OSPF RFC 1583 AND 2178 C OMPLIANCE .........................................................................................20-5

R EDUCTION OF E QUIVALENT AS E XTERNAL LSA S ...............................................................................20-5

S UPPORT FOR OSPF RFC 2328 A PPENDIX E ....................................................................................20-7

D YNAMIC OSPF A CTIVATION AND C ONFIGURATION .............................................................................20-8

D YNAMIC OSPF M EMORY ..................................................................................................................20-8

C ONFIGURING OSPF ................................................................................................................................20-8

C ONFIGURATION R ULES .....................................................................................................................20-9

OSPF P ARAMETERS ..........................................................................................................................20-9

E NABLE OSPF ON THE R OUTER .......................................................................................................20-10

A SSIGN OSPF A REAS ......................................................................................................................20-10

A SSIGNING AN A REA R ANGE ( OPTIONAL ) ..........................................................................................20-13

A SSIGNING I NTERFACES TO AN A REA ................................................................................................20-14

M ODIFY I NTERFACE D EFAULTS .........................................................................................................20-14

C HANGE THE T IMER FOR OSPF A UTHENTICATION C HANGES .............................................................20-16

B LOCK F LOODING OF O UTBOUND LSA S ON S PECIFIC OSPF I NTERFACES .........................................20-16

C ONFIGURING AN OSPF N ON -B ROADCAST I NTERFACE .....................................................................20-17

A SSIGN V IRTUAL L INKS ....................................................................................................................20-18

M ODIFY V IRTUAL L INK P ARAMETERS .................................................................................................20-20

C HANGING THE R EFERENCE B ANDWIDTH FOR THE C OST ON OSPF I NTERFACES ...............................20-21

D EFINE R EDISTRIBUTION F ILTERS .....................................................................................................20-22

P REVENT S PECIFIC OSPF R OUTES FROM B EING I NSTALLED IN THE IP R OUTE T ABLE ........................20-24

M ODIFY D EFAULT M ETRIC FOR R EDISTRIBUTION ...............................................................................20-27

xiv © Foundry Networks, Inc.

December 2005

Contents

E NABLE R OUTE R EDISTRIBUTION ......................................................................................................20-27

D ISABLE OR R E ENABLE L OAD S HARING ...........................................................................................20-29

C ONFIGURE E XTERNAL R OUTE S UMMARIZATION ...............................................................................20-30

C ONFIGURE D EFAULT R OUTE O RIGINATION .......................................................................................20-31

M ODIFY SPF T IMERS .......................................................................................................................20-32

M ODIFY R EDISTRIBUTION M ETRIC T YPE ............................................................................................20-32

M ODIFY A DMINISTRATIVE D ISTANCE ..................................................................................................20-32

C ONFIGURE OSPF G ROUP L INK S TATE A DVERTISEMENT (LSA) P ACING ...........................................20-33

M ODIFY OSPF T RAPS G ENERATED ..................................................................................................20-34

M ODIFY OSPF S TANDARD C OMPLIANCE S ETTING .............................................................................20-35

M ODIFY E XIT O VERFLOW I NTERVAL ..................................................................................................20-35

C ONFIGURING AN OSPF P OINT TO -P OINT L INK .................................................................................20-35

S PECIFY T YPES OF OSPF S YSLOG M ESSAGES TO L OG ....................................................................20-36

D ISPLAYING OSPF I NFORMATION ............................................................................................................20-36

D ISPLAYING G ENERAL OSPF C ONFIGURATION I NFORMATION ............................................................20-37

D ISPLAYING CPU U TILIZATION S TATISTICS ........................................................................................20-37

D ISPLAYING OSPF A REA I NFORMATION ............................................................................................20-39

D ISPLAYING OSPF N EIGHBOR I NFORMATION ....................................................................................20-39

D ISPLAYING OSPF I NTERFACE I NFORMATION ....................................................................................20-42

D ISPLAYING OSPF R OUTE I NFORMATION ..........................................................................................20-43

D ISPLAYING OSPF E XTERNAL L INK S TATE I NFORMATION ..................................................................20-45

D ISPLAYING OSPF L INK S TATE I NFORMATION ...................................................................................20-46

D ISPLAYING THE D ATA IN AN LSA .....................................................................................................20-47

D ISPLAYING OSPF V IRTUAL N EIGHBOR I NFORMATION .......................................................................20-47

D ISPLAYING OSPF V IRTUAL L INK I NFORMATION ................................................................................20-48

D ISPLAYING OSPF ABR AND ASBR I NFORMATION ...........................................................................20-48

D ISPLAYING OSPF T RAP S TATUS .....................................................................................................20-48

C

HAPTER

21

C

ONFIGURING

BGP4 ................................................................................ 21-1

O VERVIEW OF BGP4 ................................................................................................................................21-2

R ELATIONSHIP B ETWEEN THE BGP4 R OUTE T ABLE AND THE IP R OUTE T ABLE ....................................21-3

H OW BGP4 S ELECTS A P ATH FOR A R OUTE .......................................................................................21-4

BGP4 M ESSAGE T YPES .....................................................................................................................21-5

B ASIC C ONFIGURATION AND A CTIVATION FOR BGP4 .................................................................................21-6

N OTE R EGARDING D ISABLING BGP4 ..................................................................................................21-7

BGP4 P ARAMETERS .................................................................................................................................21-7

W HEN P ARAMETER C HANGES T AKE E FFECT .......................................................................................21-8

M EMORY C ONSIDERATIONS .......................................................................................................................21-9

M EMORY C ONFIGURATION O PTIONS O BSOLETED BY D YNAMIC M EMORY ............................................21-10

B ASIC C ONFIGURATION T ASKS ................................................................................................................21-10

E NABLING BGP4 ON THE R OUTER ....................................................................................................21-10

C HANGING THE R OUTER ID ..............................................................................................................21-11

S ETTING THE L OCAL AS N UMBER .....................................................................................................21-11

A DDING A L OOPBACK I NTERFACE ......................................................................................................21-11

A DDING BGP4 N EIGHBORS ..............................................................................................................21-12

December 2005 © Foundry Networks, Inc.

xv

Foundry Configuration Guide for the FESX, FSX, and FWSX

A DDING A BGP4 P EER G ROUP ........................................................................................................21-17

O PTIONAL C ONFIGURATION T ASKS ..........................................................................................................21-21

C HANGING THE K EEP A LIVE T IME AND H OLD T IME ............................................................................21-21

C HANGING THE BGP4 N EXT -H OP U PDATE T IMER .............................................................................21-21

E NABLING F AST E XTERNAL F ALLOVER ..............................................................................................21-22

C HANGING THE M AXIMUM N UMBER OF P ATHS FOR BGP4 L OAD S HARING .........................................21-22

C USTOMIZING BGP4 L OAD S HARING ................................................................................................21-23

S PECIFYING A L IST OF N ETWORKS TO A DVERTISE .............................................................................21-24

C HANGING THE D EFAULT L OCAL P REFERENCE ..................................................................................21-25

U SING THE IP D EFAULT R OUTE AS A V ALID N EXT H OP FOR A BGP4 R OUTE .....................................21-25

A DVERTISING THE D EFAULT R OUTE ..................................................................................................21-26

C HANGING THE D EFAULT MED (M ETRIC ) U SED FOR R OUTE R EDISTRIBUTION ....................................21-26

E NABLING N EXT -H OP R ECURSION ....................................................................................................21-26

C HANGING A DMINISTRATIVE D ISTANCES ...........................................................................................21-29

R EQUIRING THE F IRST AS TO BE THE N EIGHBOR ’ S AS ......................................................................21-30

D ISABLING OR R E -E NABLING C OMPARISON OF THE AS-P ATH L ENGTH ...............................................21-30

E NABLING OR D ISABLING C OMPARISON OF THE R OUTER ID S .............................................................21-30

C ONFIGURING THE L AYER 3 S WITCH T O A LWAYS C OMPARE M ULTI -E XIT D ISCRIMINATORS (MED S ) ....21-31

T REATING M ISSING MED S AS THE W ORST MED S .............................................................................21-32

C ONFIGURING R OUTE R EFLECTION P ARAMETERS .............................................................................21-32

C ONFIGURING C ONFEDERATIONS ......................................................................................................21-34

A GGREGATING R OUTES A DVERTISED TO BGP4 N EIGHBORS .............................................................21-37

M ODIFYING R EDISTRIBUTION P ARAMETERS ..............................................................................................21-37

R EDISTRIBUTING C ONNECTED R OUTES .............................................................................................21-38

R EDISTRIBUTING RIP R OUTES ..........................................................................................................21-38

R EDISTRIBUTING OSPF E XTERNAL R OUTES .....................................................................................21-39

R EDISTRIBUTING S TATIC R OUTES .....................................................................................................21-39

D ISABLING OR R E -E NABLING R E -A DVERTISEMENT OF A LL L EARNED

BGP4 R OUTES TO A LL BGP4 N EIGHBORS .................................................................................21-39

R EDISTRIBUTING IBGP R OUTES INTO RIP AND OSPF ......................................................................21-40

F ILTERING ..............................................................................................................................................21-40

F ILTERING S PECIFIC IP A DDRESSES .................................................................................................21-40

F ILTERING AS-P ATHS .......................................................................................................................21-41

F ILTERING C OMMUNITIES ..................................................................................................................21-45

D EFINING IP P REFIX L ISTS ...............................................................................................................21-47

D EFINING N EIGHBOR D ISTRIBUTE L ISTS ............................................................................................21-47

D EFINING R OUTE M APS ...................................................................................................................21-48

U SING A T ABLE M AP T O S ET THE T AG V ALUE ...................................................................................21-55

C ONFIGURING C OOPERATIVE BGP4 R OUTE F ILTERING .....................................................................21-55

C ONFIGURING R OUTE F LAP D AMPENING .................................................................................................21-58

G LOBALLY C ONFIGURING R OUTE F LAP D AMPENING ..........................................................................21-59

U SING A R OUTE M AP T O C ONFIGURE R OUTE F LAP D AMPENING FOR S PECIFIC R OUTES ....................21-60

U SING A R OUTE M AP T O C ONFIGURE R OUTE F LAP D AMPENING FOR A S PECIFIC N EIGHBOR ..............21-60

R EMOVING R OUTE D AMPENING FROM A R OUTE ................................................................................21-61

R EMOVING R OUTE D AMPENING FROM A N EIGHBOR ’ S R OUTES S UPPRESSED D UE TO A GGREGATION ..21-61

D ISPLAYING AND C LEARING R OUTE F LAP D AMPENING S TATISTICS .....................................................21-63

xvi © Foundry Networks, Inc.

December 2005

Contents

G ENERATING T RAPS FOR BGP ...............................................................................................................21-64

D ISPLAYING BGP4 I NFORMATION ............................................................................................................21-65

D ISPLAYING S UMMARY BGP4 I NFORMATION .....................................................................................21-65

D ISPLAYING THE A CTIVE BGP4 C ONFIGURATION ..............................................................................21-68

D ISPLAYING CPU U TILIZATION S TATISTICS ........................................................................................21-68

D ISPLAYING S UMMARY N EIGHBOR I NFORMATION ...............................................................................21-70

D ISPLAYING BGP4 N EIGHBOR I NFORMATION .....................................................................................21-73

D ISPLAYING P EER G ROUP I NFORMATION ...........................................................................................21-86

D ISPLAYING S UMMARY R OUTE I NFORMATION ....................................................................................21-87

D ISPLAYING THE BGP4 R OUTE T ABLE ..............................................................................................21-88

D ISPLAYING BGP4 R OUTE -A TTRIBUTE E NTRIES ................................................................................21-96

D ISPLAYING THE R OUTES BGP4 H AS P LACED IN THE IP R OUTE T ABLE .............................................21-97

D ISPLAYING R OUTE F LAP D AMPENING S TATISTICS ............................................................................21-98

D ISPLAYING THE A CTIVE R OUTE M AP C ONFIGURATION ......................................................................21-99

U PDATING R OUTE I NFORMATION AND R ESETTING A N EIGHBOR S ESSION ................................................21-100

U SING S OFT R ECONFIGURATION .....................................................................................................21-100

D YNAMICALLY R EQUESTING A R OUTE R EFRESH FROM A BGP4 N EIGHBOR ......................................21-102

C LOSING OR R ESETTING A N EIGHBOR S ESSION ..............................................................................21-105

C LEARING AND R ESETTING BGP4 R OUTES IN THE IP R OUTE T ABLE ................................................21-106

C LEARING T RAFFIC C OUNTERS .............................................................................................................21-106

C LEARING R OUTE F LAP D AMPENING S TATISTICS ...................................................................................21-106

R EMOVING R OUTE F LAP D AMPENING ....................................................................................................21-107

C LEARING D IAGNOSTIC B UFFERS ..........................................................................................................21-107

C

HAPTER

22

C

ONFIGURING

VRRP

AND

VRRPE ........................................................... 22-1

O VERVIEW ................................................................................................................................................22-2

O VERVIEW OF VRRP .........................................................................................................................22-2

O VERVIEW OF VRRPE .......................................................................................................................22-6

C OMPARISON OF VRRP AND VRRPE .......................................................................................................22-7

VRRP ...............................................................................................................................................22-8

VRRPE .............................................................................................................................................22-8

A RCHITECTURAL D IFFERENCES ...........................................................................................................22-8

VRRP AND VRRPE P ARAMETERS ............................................................................................................22-9

C ONFIGURING B ASIC VRRP P ARAMETERS ..............................................................................................22-11

C ONFIGURING THE O WNER ...............................................................................................................22-11

C ONFIGURING A B ACKUP ..................................................................................................................22-12

C ONFIGURATION R ULES FOR VRRP .................................................................................................22-12

C ONFIGURING B ASIC VRRPE P ARAMETERS ............................................................................................22-12

C ONFIGURATION R ULES FOR VRRPE ...............................................................................................22-12

N OTE R EGARDING D ISABLING VRRP OR VRRPE ....................................................................................22-12

C ONFIGURING A DDITIONAL VRRP AND VRRPE P ARAMETERS .................................................................22-13

F ORCING A M ASTER R OUTER T O A BDICATE TO A S TANDBY R OUTER ........................................................22-18

D ISPLAYING VRRP AND VRRPE I NFORMATION .......................................................................................22-19

D ISPLAYING S UMMARY I NFORMATION ................................................................................................22-19

D ISPLAYING D ETAILED I NFORMATION ................................................................................................22-20

December 2005 © Foundry Networks, Inc.

xvii

Foundry Configuration Guide for the FESX, FSX, and FWSX

D ISPLAYING S TATISTICS ...................................................................................................................22-26

C LEARING VRRP OR VRRPE S TATISTICS ........................................................................................22-27

D ISPLAYING CPU U TILIZATION S TATISTICS ........................................................................................22-28

C ONFIGURATION E XAMPLES ....................................................................................................................22-29

VRRP E XAMPLE ..............................................................................................................................22-29

VRRPE E XAMPLE ............................................................................................................................22-30

C

HAPTER

23

U

PDATING

S

OFTWARE

I

MAGES AND

C

ONFIGURATION

F

ILES

.............................................................................. 23-1

O VERVIEW ................................................................................................................................................23-1

D ETERMINING THE S OFTWARE V ERSIONS I NSTALLED AND R UNNING ON A D EVICE .......................................23-2

D ETERMINING THE F LASH I MAGE V ERSION R UNNING ON THE D EVICE ...................................................23-2

D ETERMINING THE B OOT I MAGE V ERSION R UNNING ON THE D EVICE ....................................................23-3

D ETERMINING THE I MAGE V ERSIONS I NSTALLED IN F LASH M EMORY .....................................................23-4

I MAGE F ILE T YPES ....................................................................................................................................23-4

U PGRADING S OFTWARE ............................................................................................................................23-4

M IGRATING TO THE N EW R ELEASE .....................................................................................................23-4

U PGRADING THE B OOT C ODE .............................................................................................................23-5

U PGRADING THE F LASH C ODE ............................................................................................................23-5

U SING SNMP TO U PGRADE S OFTWARE ....................................................................................................23-6

C HANGING THE B LOCK S IZE FOR TFTP F ILE T RANSFERS ..........................................................................23-7

R EBOOTING ..............................................................................................................................................23-7

L OADING AND S AVING C ONFIGURATION F ILES ............................................................................................23-7

R EPLACING THE S TARTUP C ONFIGURATION WITH THE R UNNING C ONFIGURATION .................................23-8

R EPLACING THE R UNNING C ONFIGURATION WITH THE S TARTUP C ONFIGURATION .................................23-8

L OGGING C HANGES TO THE S TARTUP -C ONFIG F ILE ............................................................................23-8

C OPYING A C ONFIGURATION F ILE TO OR FROM A TFTP S ERVER .........................................................23-8

D YNAMIC C ONFIGURATION L OADING ...................................................................................................23-9

M AXIMUM F ILE S IZES FOR S TARTUP -C ONFIG F ILE AND R UNNING -C ONFIG ..........................................23-10

U SING SNMP TO S AVE AND L OAD C ONFIGURATION I NFORMATION .....................................................23-11

E RASING I MAGE AND C ONFIGURATION F ILES .....................................................................................23-12

S CHEDULING A S YSTEM R ELOAD .............................................................................................................23-12

R ELOADING AT A S PECIFIC T IME .......................................................................................................23-12

R ELOADING AFTER A S PECIFIC A MOUNT OF T IME ..............................................................................23-12

D ISPLAYING THE A MOUNT OF T IME R EMAINING B EFORE A S CHEDULED R ELOAD .................................23-13

C ANCELING A S CHEDULED R ELOAD ..................................................................................................23-13

D IAGNOSTIC E RROR C ODES AND R EMEDIES FOR TFTP T RANSFERS ........................................................23-13

A

PPENDIX

A

U

SING

S

YSLOG

...........................................................................................A-1

O VERVIEW ................................................................................................................................................. A-1

D ISPLAYING S YSLOG M ESSAGES ................................................................................................................ A-2

C ONFIGURING THE S YSLOG S ERVICE ......................................................................................................... A-3

D ISPLAYING THE S YSLOG C ONFIGURATION ........................................................................................... A-4

xviii © Foundry Networks, Inc.

December 2005

Contents

D ISABLING OR R E -E NABLING S YSLOG .................................................................................................. A-7

S PECIFYING A S YSLOG S ERVER ........................................................................................................... A-7

S PECIFYING AN A DDITIONAL S YSLOG S ERVER ...................................................................................... A-7

D ISABLING L OGGING OF A M ESSAGE L EVEL ......................................................................................... A-7

C HANGING THE N UMBER OF E NTRIES THE L OCAL B UFFER C AN H OLD ................................................... A-8

C HANGING THE L OG F ACILITY .............................................................................................................. A-8

D ISPLAYING THE I NTERFACE N AME IN S YSLOG M ESSAGES ................................................................... A-9

C LEARING THE S YSLOG M ESSAGES FROM THE L OCAL B UFFER ............................................................. A-9

D ISPLAYING TCP/UDP P ORT N UMBERS IN S YSLOG M ESSAGES ........................................................ A-10

S YSLOG M ESSAGES ................................................................................................................................. A-10

A

PPENDIX

B

R

EMOTE

N

ETWORK

M

ONITORING

................................................................B-1

B ASIC M ANAGEMENT ................................................................................................................................. B-1

V IEWING S YSTEM I NFORMATION ........................................................................................................... B-1

V IEWING C ONFIGURATION I NFORMATION .............................................................................................. B-2

V IEWING P ORT S TATISTICS .................................................................................................................. B-2

V IEWING STP S TATISTICS ................................................................................................................... B-5

C LEARING S TATISTICS ......................................................................................................................... B-5

RMON S UPPORT ...................................................................................................................................... B-5

S TATISTICS (RMON G ROUP 1) ............................................................................................................ B-6

H ISTORY (RMON G ROUP 2) ............................................................................................................... B-8

A LARM (RMON G ROUP 3) .................................................................................................................. B-9

E VENT (RMON G ROUP 9) ................................................................................................................... B-9

S F LOW ...................................................................................................................................................... B-9

C ONFIGURATION C ONSIDERATIONS .................................................................................................... B-10

C ONFIGURING AND E NABLING S F LOW ................................................................................................ B-11

C ONFIGURING A U TILIZATION L IST FOR AN U PLINK P ORT ........................................................................... B-17

C OMMAND S YNTAX ........................................................................................................................... B-17

D ISPLAYING U TILIZATION P ERCENTAGES FOR AN U PLINK .................................................................... B-17

A

PPENDIX

C

P

OLICIES AND

F

ILTERS

...............................................................................C-1

S COPE ...................................................................................................................................................... C-2

D EFAULT F ILTER A CTIONS ......................................................................................................................... C-2

P OLICY AND F ILTER P RECEDENCE .............................................................................................................. C-3

Q O S ................................................................................................................................................... C-3

P RECEDENCE A MONG F ILTERS ON D IFFERENT L AYERS ........................................................................ C-3

P RECEDENCE A MONG F ILTERS ON THE S AME L AYER ........................................................................... C-4

F OUNDRY P OLICIES ................................................................................................................................... C-4

Q UALITY OF -S ERVICE P OLICIES ........................................................................................................... C-5

L AYER 3 P OLICIES ............................................................................................................................... C-5

F OUNDRY F ILTERS ..................................................................................................................................... C-6

L AYER 2 F ILTERS ................................................................................................................................ C-7

L AYER 3 F ILTERS ................................................................................................................................ C-9

December 2005 © Foundry Networks, Inc.

xix

Foundry Configuration Guide for the FESX, FSX, and FWSX

A

PPENDIX

D

S

OFTWARE

F

EATURES AND

S

PECIFICATIONS

...............................................D-1

F EATURE H IGHLIGHTS ................................................................................................................................ D-1

S UPPORTED F EATURES ....................................................................................................................... D-2

U NSUPPORTED F EATURES ................................................................................................................... D-7

IEEE C OMPLIANCE .................................................................................................................................... D-8

RFC S UPPORT .......................................................................................................................................... D-9

I NTERNET D RAFTS ................................................................................................................................... D-14

A

PPENDIX

E

C

AUTIONS AND

W

ARNINGS

..........................................................................E-1

C AUTIONS ................................................................................................................................................. E-1

W ARNINGS ................................................................................................................................................ E-6

xx © Foundry Networks, Inc.

December 2005

Chapter 1

About This Guide

Introduction

This guide describes the following product families from Foundry Networks:

• FastIron Edge Switch X-Series (FESX) Layer 2/Layer 3 switch

• FastIron Workgroup Switch X-Series (FWSX) Layer 2 switch

• FastIron SuperX Switch (FSX) Layer 2/Layer 3 switch

This guide includes procedures for configuring the software. The software procedures show how to perform tasks using the CLI. This guide also describes how to monitor Foundry products using statistics and summary screens.

This guide applies to the following products:

• FastIron Edge Switch X-Series products:

• FastIron Edge Switch X424

• FastIron Edge Switch X448

• FastIron SuperX Switch

• FastIron Workgroup Switch X-Series products:

• FastIron Workgroup Switch X424

• FastIron Workgroup Switch X448

December 2005 © Foundry Networks, Inc.

1 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX

NOTE: This guide contains the terms FastIron Edge Switch X-Series ( FESX ), FastIron SuperX Switch (FSX) , and FastIron WorkGroup Switch X-Series (FWSX ). Each term refers to a specific set of devices, as shown in

Table 1.1.

Table 1.1: FastIron Family of Switches

This Name

FastIron Edge Switch X-Series (FESX)

FastIron SuperX Switch (FSX)

FastIron Workgroup Switch X-Series

(FWSX)

Refers to These Devices

FESX424 and FESX448

FastIron SuperX

FWSX424 and FWSX448

What’s Included in This Edition?

This edition describes the following software releases:

• For the FastIron Edge Switch X-Series products:

• 02.3.03 (combined FESX/FSX/FWSX release)

• 02.3.02 (combined FESX/FSX/FWSX release)

• 02.3.01 (combined FESX/FSX/FWSX release)

• 02.2.00 (combined FESX/FWSX release)

• 02.1.01

• 02.0.00

• 01.1.00

• 01.0.00

• For the FastIron SuperX Switch

• 02.2.01

• 02.2.00

• 02.1.00

• 02.0.01

NOTE: Software releases for FSX devices were combined with the FESX software releases starting with

FESX release 02.3.01.

• For the FastIron Workgroup Switch X-Series products:

• 02.0.00

NOTE: Software releases for FWSX devices were combined with the FESX software releases starting with

FESX release 02.2.00.

1 - 2 © Foundry Networks, Inc.

December 2005

About This Guide

Audience

This guide is designed for network installers, system administrators, and resellers who will configure the software for the FastIron family of switches. This guide assumes a working knowledge of Layer 2 and Layer 3 switching and routing concepts.

If you are using Layer 3 code, you should be familiar with the following protocols if applicable to your network – IP,

RIP, OSPF, BGP4, DVMRP, MBGP, IGMP, PIM, VRRP, and VRRPE.

Nomenclature

This guide uses the following typographical conventions to show information:

Italic highlights the title of another publication and occasionally emphasizes a word or phrase.

Bold highlights a CLI command.

Bold Italic highlights a term that is being defined.

Underline highlights a link on the Web management interface.

Capitals highlights field names and buttons that appear in the Web management interface.

NOTE: A note emphasizes an important fact or calls your attention to a dependency.

WARNING: A warning calls your attention to a possible hazard that can cause injury or death.

CAUTION: A caution calls your attention to a possible hazard that can damage equipment.

Related Publications

The following Foundry Networks documents supplement the information in this guide.

• Foundry FastIron X-Series Chassis Hardware Installation Guide – provides hardware installation procedures for the FastIron chassis devices (FSX).

• Foundry FastIron Stackable Hardware Installation Guide – provides hardware installation procedures for the

FastIron stackable devices (FES, FESX, and FWSX).

• Foundry Security Guide – provides procedures for securing management access to Foundry devices and for protecting against Denial of Service (DoS) attacks.

• Foundry Management Information Base Reference – contains the Simple Network Management Protocol

(SNMP) Management Information Base (MIB) objects supported on Foundry devices.

• Release Notes for the FastIron Edge Switch X-Series – describes features introduced in each software release, lists features that are supported on the FESX, and describes how configuration procedures or defaults differ from those on other Foundry devices, due to the FastIron Edge Switch X-Series’ hardware architecture.

• Release Notes for the FastIron SuperX Switch – describes features introduced in each software release, lists features that are supported on the FSX, and describes how configuration procedures or defaults differ from those on other Foundry devices, due to the FSX’s hardware architecture.

• Release Notes for the FastIron Workgroup Switch X-Series – describes features introduced in each software release, lists features that are supported on the FWSX, and describes how configuration procedures or defaults differ from those on other Foundry devices, due to the FastIron Workgroup Switch X-Series’ hardware architecture.

December 2005 © Foundry Networks, Inc.

1 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

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].

How to Get Help

Foundry Networks technical support will ensure that the fast and easy access that you have come to expect from your Foundry Networks products will be maintained.

Web Access

• http://www.foundrynetworks.com

Email Access

Technical requests can also be sent to the following email address:

• [email protected]

Telephone Access

• 1.877.TURBOCALL (887.2622) United

• 1.408.586.1881

Outside the United States

Warranty Coverage

Contact Foundry Networks using any of the methods listed above for information about the standard and extended warranties.

1 - 4 © Foundry Networks, Inc.

December 2005

Chapter 2

Getting Familiar with Management Applications

This chapter describes how to manage a Foundry device using the various user interfaces listed in Table 2.1.

Table 2.1: Chapter Contents

Description

Command Line Interface (CLI) – a text-based interface accessible through a direct serial connection or a Telnet session.

Web management interface – A GUI-based management interface accessible through an HTTP (web browser) connection.

You can also use the IronView Network Manager , an optional

SNMP-based standalone GUI application, to manage the

Foundry device. See the Foundry IronView Network

Management User’s Guide for information about using IronView

Network Manager.

See Page

2-1

2-8

2-11

Logging on Through the CLI

Once an IP address is assigned to a Foundry device running Layer 2 software or to an interface on the Foundry device running Layer 3 software, you can access the CLI either through the direct serial connection to the device or through a local or remote Telnet session.

You can initiate a local Telnet or SNMP connection by attaching a cable to a port and specifying the assigned management station 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.

December 2005 © Foundry Networks, Inc.

2 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX

• CONFIG – Lets you make configuration changes to the device. To save the changes across reboots, 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 serial or Telnet connection to the Foundry device 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 .

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:

FESX424 Router(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 all-client appletalk arp boot some lines omitted for brevity...

ipx lock-address logging mac

--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 a time).

• Press the Return or Enter key to display the next line (one line at a time).

• Press Ctrl-C or Ctrl-Q to cancel the display.

2 - 2 © Foundry Networks, Inc.

December 2005

Getting Familiar with Management Applications

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.

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

Table 2.2: CLI Line Editing Commands

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.

For a complete list of CLI commands and syntax information for each command, see the Foundry Switch and

Router Command Line Interface Reference .

Using Slot and Port Numbers with CLI Commands

Many CLI commands and displays use port numbers, or slot numbers with port numbers. The ports are labeled on the front panel of the device.

The FSX uses chassis-based port numbering which consists of a slot number and a port number. When you enter

CLI commands on the FSX, you must specify both the slot number and the port number. The FESX and FWSX devices do not use this type of numbering. When you enter commands on these devices, just specify the port number. The slot numbers used in the FSX CLI examples apply only to Chassis devices.

Here is an example. The following commands change the CLI from the global CONFIG level to the configuration level for the first port on the device.

• FSX commands:

FastIron SuperX Switch(config)# interface e 1/1

FastIron SuperX Switch(config-if-1/1)#

December 2005 © Foundry Networks, Inc.

2 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

• FESX and FWSX commands:

(config)# interface e 1

(config-if-e1000-1)#

Searching and Filtering Output from CLI Commands

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-6 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.

FastIron SuperX Switch# 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.

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.

FESX424 Switch# 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>

2 - 4 © Foundry Networks, Inc.

December 2005

Getting Familiar with Management Applications

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

Foundry device.

FESX424 Switch# 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>

Searching and Filtering Output at the --More-- Prompt

The --More-- prompt displays 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. In addition, you can search and filter output from this prompt.

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

temperature temperature sensor commands

terminal display syslog

traceroute TraceRoute to IP node

undebug Disable debugging functions (see also 'debug')

undelete Undelete flash card files

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

The filtered results are displayed: filtering...

telnet Telnet by name or IP address

December 2005 © Foundry Networks, Inc.

2 - 5

Foundry Configuration Guide for the FESX, FSX, and FWSX

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...

temperature temperature sensor commands

terminal display syslog

traceroute TraceRoute to IP node

undebug Disable debugging functions (see also 'debug')

undelete Undelete flash card files

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.3: 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+

2 - 6 © Foundry Networks, Inc.

December 2005

Getting Familiar with Management Applications

Character

?

^

$

_

[ ]

Table 2.3: 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.

December 2005 © Foundry Networks, Inc.

2 - 7

Foundry Configuration Guide for the FESX, FSX, and FWSX

|

Character

( )

Table 2.3: 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 “ \* ”.

FESX424 Router# show ip route bgp | include \*

Logging On Through the Web Management Interface

To use the Web management interface, open a web browser and enter the IP address of the Foundry device’s management port in the Location or Address field. The web browser contacts the Foundry device and displays a

Login panel, such as the one shown below for the FESX.

Figure 2.1

Web Management Interface Login Panel

NOTE: If you are unable to connect with the device through a Web browser due to a proxy problem, it may be necessary to set your Web browser to direct Internet access instead of using a proxy. For information on how to change a proxy setting, refer to the on-line help provided with your Web browser.

To log in, click on the Login link. The following dialog box is displayed.

Figure 2.2

Web management interface login dialog

2 - 8 © Foundry Networks, Inc.

December 2005

Getting Familiar with Management Applications

The login username and password you enter depends on whether your device is configured with AAA authentication for SNMP. If AAA authentication for SNMP is not configured, you can use the user name “get” and the default read-only password “public” for read-only access. However, for read-write access, you must enter “set” for the user name, and enter a read-write community string you have configured on the device for the password.

There is no default read-write community string. You must add one using the CLI. See the Foundry Security

Guide .

As an alternative to using the SNMP community strings to log in, you can configure the Foundry device to secure

Web management access using local user accounts or Access Control Lists (ACLs). See the Foundry Security

Guide .

Navigating the Web Management Interface

When you log into a device, the System configuration panel is displayed. This panel allows you to enable or disable major system features. You can return to this panel from any other panel by selecting the Home link.

The Site Map link gives you a view of all available options on a single screen.

Figure 2.3 displays the first Web management interface panel for Layer 3 Switch features, while Figure 2.4 displays the first panel for Layer 2 Switch features. These panels allow you to configure the features supported by the Layer 3 Switch and Layer 2 Switch software.

Figure 2.3

First Panel for Layer 3 Switch Features

NOTE: If you are using Internet Explorer 6.0 to view the Web management interface, make sure the version you are running includes the latest service pack(s). Otherwise, the navigation tree (the left-most pane in Figure 2.3) will not display properly. For information on how to load the latest service pack(s), refer to the on-line help provided with your Web browser.

December 2005 © Foundry Networks, Inc.

2 - 9

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 2.4

First Panel for Layer 2 Switch Features

NOTE: If you are using Internet Explorer 6.0 to view the Web management interface, make sure the version you are running includes the latest service pack(s). Otherwise, the navigation tree (the left-most pane in Figure 2.3) will not display properly. For information on how to load the latest service pack(s), refer to the on-line help provided with your Web browser.

The left pane of the Web management interface window contains a “tree view,” similar to the one found in

Windows Explorer. Configuration options are grouped into folders in the tree view. These folders, when expanded, reveal additional options. To expand a folder, click on the plus sign to the left of the folder icon.

You can configure the appearance of the Web management interface by using one of the following methods.

Using the CLI, you can modify the appearance of the Web management interface with the web-management command.

To cause the Web management interface to display the List view by default:

FESX424 Router(config)# web-management list-menu

To disable the front panel frame:

FESX424 Router(config)# no web-management front-panel

When you save the configuration with the write memory command, the changes will take place the next time you start the Web management interface, or if you are currently running the Web management interface, the changes will take place when you click the Refresh button on your browser.

USING THE WEB MANAGEMENT INTERFACE

1.

Click on the plus sign next to Configure in the tree view to expand the list of configuration options.

2.

Click on the plus sign next to System in the tree view to expand the list of system configuration links.

3.

Click on the plus sign next to Management in the tree view to expand the list of system management links.

4.

Click on the Web Preference link to display the Web Management Preferences panel.

2 - 10 © Foundry Networks, Inc.

December 2005

Getting Familiar with Management Applications

5.

Enable or disable elements on the Web management interface by clicking on the appropriate radio buttons on the panel. The following figure identifies the elements you can change.

Front Panel

Front Panel Frame

Menu Type

(Tree View shown)

Page Menu

Bottom Frame

Menu Frame

NOTE: The tree view is available when you use the Web management interface with Netscape 4.0 or higher or Internet Explorer 4.0 or higher browsers. If you use the Web management interface with an older browser, the Web management interface displays the List view only, and the Web Management Preferences panel does not include an option to display the tree view.

6.

When you have finished, click the Apply button on the panel, then click the Refresh button on your browser to activate the changes.

7.

To save the configuration, click the plus sign next to the Command folder, then click the Save to Flash link.

NOTE: The only changes that become permanent are the settings to the Menu Type and the Front Panel

Frame. Any other elements you enable or disable will go back to their default settings the next time you start the Web management interface.

Logging on Through IronView Network Manager

See the Foundry IronView Network Management User’s Guide for information about using IronView Network

Manager.

December 2005 © Foundry Networks, Inc.

2 - 11

Foundry Configuration Guide for the FESX, FSX, and FWSX

2 - 12 © Foundry Networks, Inc.

December 2005

Chapter 3

Configuring Basic Software Features

This chapter describes how to configure basic, non-protocol features on the FastIron family of switches.

Foundry devices are configured at the factory with default parameters that allow you to begin using the basic features of the system immediately. However, many of the advanced features such as VLANs or routing protocols for the device must first be enabled at the system (global) level before they can be configured. If you use the

Command Line Interface (CLI) to configure system parameters, you can find these system level parameters at the

Global CONFIG level of the CLI.

This chapter contains procedures for configuring the following parameters:

Table 3.1: Chapter Contents

Description

Basic system parameters – This section lists the basic system parameters and gives instructions for configuring them.

Basic port parameters – This section lists basic port parameters and gives instructions for configuring them.

See Page

3-2

3-13

NOTE: Before assigning or modifying any router parameters, you must assign the IP subnet (interface) addresses for each port.

NOTE: For information about configuring IP addresses, DNS resolver, DHCP assist, and other IP-related parameters, see the chapter “Configuring IP” on page 16-1.

For information about the Syslog buffer and messages, see the Appendix “Using Syslog” on page A-1.

December 2005 © Foundry Networks, Inc.

3 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX

Configuring Basic System Parameters

The procedures in this section describe how to configure the basic system parameters listed in Table 3.2.

Table 3.2: Basic System Parameters

Basic System Parameter

System name, contact, and location

SNMP trap receiver, trap source address, and other parameters

Single source address for all Telnet packets

Single source address for all TFTP packets

System time using a Simple Network Time

Protocol (SNTP) server or local system counter

Broadcast, multicast, or unknown-unicast limits, if required to support slower third-party devices

Banners that are displayed on users’ terminals when they enter the Privileged EXEC CLI level or access the device through Telnet

See Page

3-2

3-3

3-7

3-7

3-8, 3-10

3-11

3-11

NOTE: For information about the Syslog buffer and messages, see “Using Syslog” on page A-1.

Entering System Administration Information

You can configure a system name, contact, and location for a Foundry device and save the information locally in the configuration file for future reference. This information is not required for system operation but is suggested.

When you configure a system name, the name replaces the default system name in the CLI command prompt.

The name, contact, and location each can be up to 32 alphanumeric characters.

Here is an example of how to configure a system name, system contact, and location:

FastIron SuperX Switch(config)# hostname zappa zappa(config)# snmp-server contact Support Services zappa(config)# snmp-server location Centerville zappa(config)# end zappa# write memory

Syntax: hostname <string>

Syntax: snmp-server contact <string>

Syntax: snmp-server location <string>

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.

3 - 2 © Foundry Networks, Inc.

December 2005

Configuring Basic Software Features

Configuring Simple Network Management Protocol (SNMP) Parameters

Use the procedures in this section to perform the following configuration tasks:

• Specify an SNMP trap receiver.

• Specify a source address and community string for all traps sent by the device.

• 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: To add and modify “get” (read-only) and “set” (read-write) community strings, see the Foundry Security

Guide .

Specifying an SNMP Trap Receiver

You can specify a trap receiver to ensure that all SNMP traps sent by the Foundry device 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 Foundry device sends all the SNMP traps to the specified host(s) and includes the specified community string. Administrators can therefore filter for traps from a Foundry device based on IP address or community string.

When you add a trap receiver, the software automatically encrypts the community string you associate with the receiver when the string is displayed by the CLI or Web management interface. If you want the software to show the community string in the clear, you must explicitly specify this when you add a trap receiver. In either case, the software does not encrypt the string in the SNMP traps sent to the receiver.

To specify the host to which the device sends all SNMP traps, use one of the following methods.

To add a trap receiver and encrypt the display of the community string, enter commands such as the following:

To specify an SNMP trap receiver and change the UDP port that will be used to receive traps, enter a command such as the following:

FESX424 Switch(config)# snmp-server host 2.2.2.2 0 mypublic port 200

FESX424 Switch(config)# write memory

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 Foundry device. The string can be a read-only string or a read-write string. The string is not used to authenticate access to the trap host but is instead a useful method for filtering traps on the host. For example, if you configure each of your Foundry devices that use the trap host to send a different community string, you can easily distinguish among the traps from different Foundry devices based on the community strings.

The command in the example above adds trap receiver 2.2.2.2 and configures the software to encrypt display of the community string. When you save the new community string to the startup-config file (using the write memory command), the software adds the following command to the file: snmp-server host 2.2.2.2 1 <encrypted-string>

To add a trap receiver and configure the software to encrypt display of the community string in the CLI and Web management interface, enter commands such as the following:

FESX424 Switch(config)# snmp-server host 2.2.2.2 0 FastIron-12

FESX424 Switch(config)# write memory

The port <value> parameter allows you to specify which UDP port will be used by the trap receiver. This parameter allows you to configure several trap receivers in a system. With this parameter, IronView Network

December 2005 © Foundry Networks, Inc.

3 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

Manager Network Manager and another network management application can coexist in the same system.

Foundry devices 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 Foundry device use the same source IP address. When you configure the SNMP source address, you specify the Ethernet port, loopback interface, or virtual interface that is the source for the traps. The Foundry device then uses the lowest-numbered

IP address configured on the port or interface as the source IP address in the SNMP traps sent by the device.

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 use this feature to simplify configuration of the trap receiver by configuring the Foundry device 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 specify a port, loopback interface, or virtual interface whose lowest-numbered IP address the Foundry device must use as the source for all SNMP traps sent by the device, use the following CLI method.

To configure the device to send all SNMP traps from the first configured IP address on port 4, enter the following commands:

FESX424 Switch(config)# snmp trap-source ethernet 4

FESX424 Switch(config)# write memory

Syntax: snmp-server trap-source loopback <num> | ethernet [<slotnum>/]<portnum> | 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. If you are configuring a chassis device, specify the slot number as well as the port number (<slotnum>/<portnum>).

To specify a loopback interface as the device’s SNMP trap source, enter commands such as the following:

FESX424 Switch(config)# int loopback 1

FESX424 Switch(config-lbif-1)# ip address 10.0.0.1/24

FESX424 Switch(config-lbif-1)# exit

FESX424 Switch(config)# snmp-server trap-source loopback 1

The commands in this example configure loopback interface 1, assign IP address 10.00.1/24 to the loopback interface, then designate the interface as the SNMP trap source for this device. Regardless of the port the

Foundry device uses to send traps to the receiver, the traps always arrive from the same source IP address.

Setting the SNMP Trap Holddown Time

When a Foundry device 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 device might not be able to reach the servers, in which case the messages are lost.

By default, a Foundry device 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 device 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:

FESX424 Switch(config)# snmp-server enable traps holddown-time 30

The command in this example changes the holddown time for SNMP traps to 30 seconds. The device waits 30 seconds to allow convergence in STP and OSPF before sending traps to the SNMP trap receiver.

3 - 4 © Foundry Networks, Inc.

December 2005

Configuring Basic Software Features

Syntax: [no] snmp-server enable traps holddown-time <secs>

The <secs> parameter specifies the number of seconds and can be from 1 – 600 (ten minutes). The default is 60 seconds.

Disabling SNMP Traps

Foundry devices come with SNMP trap generation enabled by default for all traps. You can selectively disable one or more of the following traps.

NOTE: By default, all SNMP traps are enabled at system startup.

Layer 2 Traps

The following traps are generated on devices running Layer 2 software:

• SNMP authentication keys

• Power supply failure

• Fan failure

• Cold start

• Link up

• Link down

• Bridge new root

• Bridge topology change

• Locked address violation

Layer 3 Traps

The following traps are generated on devices running Layer 3 software:

• SNMP authentication key

• Power supply failure

• Fan failure

• Cold start

• Link up

• Link down

• Bridge new root

• Bridge topology change

• Locked address violation

• BGP4

• OSPF

• VRRP

• VRRPE

To stop link down occurrences from being reported, enter the following:

FESX424 Router(config)# no snmp-server enable traps link-down

Syntax: [no] snmp-server enable traps <trap-type>

NOTE: For a list of the trap values, see the Foundry Switch and Router Command Line Interface Reference .

December 2005 © Foundry Networks, Inc.

3 - 5

Foundry Configuration Guide for the FESX, FSX, and FWSX

3 - 6

Disabling Syslog Messages and Traps for CLI Access

Foundry devices send 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 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 .

The feature is enabled by default.

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:

FESX424 Switch(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. If you want to disable the logging, enter the following commands:

FESX424 Router(config)# no logging enable user-login

FESX424 Router(config)# write memory

© Foundry Networks, Inc.

December 2005

Configuring Basic Software Features

FESX424 Router(config)# end

FESX424 Router# reload

Syntax: [no] logging enable user-login

Configuring an Interface as the Source for All Telnet Packets

You can designate the lowest-numbered IP address configured on an interface as the source IP address for all

Telnet packets from the device. 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 use this feature to simplify configuration of the Telnet server by configuring the Foundry device 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.

To specify an interface as the source for all Telnet packets from the device, use the following CLI method. The software uses the lowest-numbered IP address configured on the interface as the source IP address for Telnet packets originated by the device.

To specify the lowest-numbered IP address configured on a virtual interface as the device’s source for all Telnet packets, enter commands such as the following:

FESX424 Switch(config)# int loopback 2

FESX424 Switch(config-lbif-2)# ip address 10.0.0.2/24

FESX424 Switch(config-lbif-2)# exit

FESX424 Switch(config)# ip telnet source-interface loopback 2

The commands in this example configure loopback interface 2, assign IP address 10.0.0.2/24 to the interface, then designate the interface as the source for all Telnet packets from the device.

Syntax: ip telnet source-interface ethernet [<slotnum>/]<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 device.

FESX424 Switch(config)# interface ethernet 4

FESX424 Switch(config-if-e1000-4)# ip address 209.157.22.110/24

FESX424 Switch(config-if-e1000-4)# exit

FESX424 Switch(config)# ip telnet source-interface ethernet 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 device to use the lowest-numbered IP address configured on a loopback interface, virtual interface, or Ethernet port as the source for all TFTP packets from the device. The software uses the lowestnumbered IP address configured on the interface as the source IP address for the packets.

December 2005 © Foundry Networks, Inc.

3 - 7

Foundry Configuration Guide for the FESX, FSX, and FWSX

For example, to specify the lowest-numbered IP address configured on a virtual interface as the device’s source for all TFTP packets, enter commands such as the following:

FESX424 Switch(config)# int ve 1

FESX424 Switch(config-vif-1)# ip address 10.0.0.3/24

FESX424 Switch(config-vif-1)# exit

FESX424 Switch(config)# ip tftp 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's address as the source address for all TFTP packets.

Syntax: [no] ip tftp source-interface ethernet [<slotnum>/]<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 Foundry devices to consult SNTP servers for the current system time and date.

NOTE: Foundry devices do 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 Foundry device, enter the following:

FESX424 Switch(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 Foundry device polls its SNTP server every 30 minutes (1800 seconds). To configure the Foundry device to poll for clock updates from a SNTP server every 15 minutes, enter the following:

FESX424 Switch(config)# sntp poll-interval 900

Syntax: [no] sntp poll-interval <1-65535>

To display information about SNTP associations, enter the following command:

FESX424 Switch# 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

3 - 8 © Foundry Networks, Inc.

December 2005

Configuring Basic Software Features

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 3.3: 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:

FESX424 Switch# 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 3.4: 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

December 2005 © Foundry Networks, Inc.

3 - 9

Foundry Configuration Guide for the FESX, FSX, and FWSX

This Field...

peer dispersion

Table 3.4: Output from the show sntp status command (Continued)

Indicates...

Dispersion of the synchronized peer

Setting the System Clock

In addition to SNTP support, Foundry switches and routers also allow you to set the system time counter. The time counter setting is not retained across power cycles and is not automatically synchronized with an SNTP server. The counter merely starts the system time and date clock with the time and date you specify.

NOTE: You can synchronize the time counter with your SNTP server time by entering 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.

For more details about SNTP, see “Specifying a Simple Network Time Protocol (SNTP) Server” on page 3-8.

To set the system time and date to 10:15:05 on October 15, 2003, enter the following command:

FESX424 Switch# clock set 10:15:05 10-15-2003

Syntax: [no] clock set <hh:mm:ss> <mm-dd-yy> | <mm-dd-yyyy>

By default, Foundry switches and routers do not change the system time for daylight savings time. To enable daylight savings time, enter the following command:

FESX424 Switch# 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

Foundry device 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:

FESX424 Router(config)# clock timezone gmt+10

Syntax: clock timezone gmt | us <time-zone>

3 - 10 © Foundry Networks, Inc.

December 2005

Configuring Basic Software Features

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, and Unknown Unicast Traffic

FastIron devices 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. You can limit the number of broadcast, multicast, or unknown-unicast packets a Foundry device forwards each second using the procedures in this section. You can configure limits on individual ports or groups of ports.

On the FESX, FWSX, and FSX, unknown unicast limiting is independent of broadcast and multicast limiting.

When you configure unknown-unicast limiting, the rate applies to all ports in the port range for which unknown unicast is enabled. On the FESX, FWSX, and FSX, a 1-Gigabit port range consists of 12 ports. For example, the

FESX424 has 2 port ranges; ports 1 – 12 are one port range, and ports 13 – 24 are another port range. If you enable unknown unicast limiting on port 2, the configuration applies to the ports from 1 – 12 that have unknown unicast limiting enabled. 10-Gigabit ports are not grouped into ranges. So if your device has two 10-Gigabit uplinks, you can configure different unknown-unicast limits for each 10-Gigabit port.

Command Syntax

To enable broadcast limiting on a group of ports, enter commands such as the following:

FESX424 Switch(config)# interface ethernet 1 to 8

FESX424 Switch(config-mif-e1000-1-8)# broadcast limit 65536

These commands configure broadcast limiting on ports 1 – 8. On each port, the total combined number of broadcasts cannot exceed 65,536.

To include multicasts in the 65536 packets per second limit on each of the ports, enter the following command after enabling broadcast limiting:

FESX424 Switch(config-mif-e1000-1-8)# multicast limit

To enable unknown unicast limiting, enter commands such as the following:

FESX424 Switch# config terminal

FESX424 Switch(config)# int e 1

FESX424 Switch(config-if-e1000-1)# unknown unicast limit 65536

The combined number of inbound Unknown Unicast packets permitted

for ports 1 to 12 is now set to 65536

FESX424 Switch((config-if-e1000-1)#

Syntax: [no] broadcast limit <num>

Syntax: [no] multicast limit

Syntax: [no]unknown unicast limit <num>

The <num> parameter specifies the maximum number of packets per second and can be any number that is a multiple of 65536, up to a maximum value of 4294967295. If you enter the multicast limit command, multicast packets are included in the limit you specify. If you specify 0, limiting is disabled. If you specify a number that is not a multiple of 65536, the software rounds the number to the next multiple of 65536. Limiting is disabled by default.

Configuring CLI Banners

Foundry devices 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 Foundry device can display a message on the Console when an incoming Telnet CLI session is detected.

December 2005 © Foundry Networks, Inc.

3 - 11

Foundry Configuration Guide for the FESX, FSX, and FWSX

Setting a Message of the Day Banner

You can configure the Foundry device 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 FESX!” when a Telnet CLI session is established:

FESX424 Switch(config)# banner motd $ (Press Return)

Enter TEXT message, End with the character '$'.

Welcome to FESX! $

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:

Setting a Privileged EXEC CLI Level Banner

You can configure the Foundry device to display a message when a user enters the Privileged EXEC CLI level.

For example:

FastIron SuperX Switch(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 Foundry device 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:

FastIron SuperX Switch(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.

3 - 12 © Foundry Networks, Inc.

December 2005

Configuring Basic Software Features

Configuring Basic Port Parameters

The procedures in this section describe how to configure the port parameters shown in Table 3.5

Table 3.5: Basic Port Parameters

Port Parameter

Name

Speed

Auto-negotiation Maximum port speed advertisement and Port speed down-shift

Duplex mode

MDI/MDIX detection

Port status (enable or disable)

Flow control

Gigabit negotiate mode

QoS priority

Dynamic configuration of Voice over IP (VoIP) phones

See Page

3-13

3-13

3-14

3-15

3-16

3-16

3-17

3-17

3-17

3-17

All Foundry 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.

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 interfaces, and loopback interfaces.

To assign a name to a port:

FESX424 Router(config)# interface e 2

FESX424 Router(config-if-e1000-2)# port-name Marsha

Syntax: port-name <text>

The <text> parameter is an alphanumeric string. The name can be up to 64 characters long. The name can contain blanks. You do not need to use quotation marks around the string, even when it contains blanks.

Modifying Port Speed

The Gigabit Ethernet copper ports on the FESX and FWSX are 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 or 100 Mbps. The default value is 10/100/1000 Auto-sense.

NOTE: You can modify the port speed of copper ports only. This feature does not apply to fiber ports.

December 2005 © Foundry Networks, Inc.

3 - 13

Foundry Configuration Guide for the FESX, FSX, and FWSX

Configuration Syntax

To change the port speed of interface 8 from the default of 10/100/1000 auto-sense, to 10 Mbps operating at fullduplex, enter the following:

FESX424 Router(config)# interface e 8

FESX424 Router(config-if-e1000-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

• auto

The default is auto.

Enabling Auto-negotiation Maximum Port Speed Advertisement and

Port Speed Down-shift

Maximum Port speed advertisement and Port speed down-shift are enhancements to the auto-negotiation feature, a mechanism for accommodating multi-speed network devices by automatically configuring the highest performance mode of inter-operation between two connected devices.

• Port speed down-shift enables Gigabit copper ports on the Foundry device to establish a link at 1000 Mbps over a 4-pair wire when possible, or to down-shift (reduce the speed) to 100 Mbps if the medium is a 2-pair wire.

• Maximum port speed advertisement enables you to configure an auto-negotiation maximum speed that

Gigabit copper ports on the Foundry device will advertise to the connected device. You can configure a port to advertise a maximum speed of either 100 Mbps or 10 Mbps. When the maximum port speed advertisement feature is enabled on a port that is operating at 100 Mbps maximum speed, the port will advertise 10/100 Mbps capability to the connected device. Similarly, if a port is operating at 10 Mbps maximum speed, the port will advertise 10 Mbps capability to the connected device.

The port speed down-shift and maximum port speed advertisement features operate dynamically at the physical link layer between two connected network devices. It examines the cabling conditions and the physical capabilities of the remote link, then configures the speed of the link segment according to the highest physicallayer technology that both devices can accommodate.

The port speed down-shift and maximum port speed advertisement features operate dynamically at the physical link layer, independent of logical trunk group configurations. Although Foundry recommends that you use the same cable types and auto-negotiation configuration on all members of a trunk group, you could utilize the autonegotiation features conducive to your cabling environment. For example, in certain circumstances, you could configure each port in a trunk group to have its own auto-negotiation maximum port speed advertisement or port speed down-shift configuration.

Application Notes

• This feature is available in software release 02.3.01 and later.

• Port speed down-shift and maximum port speed advertisement work only when auto-negotiation is enabled

(CLI command speed-duplex auto ). If auto-negotiation is OFF, the device will reject the port speed downshift and maximum port speed advertisement configuration.

• When port speed down-shift or maximum port speed advertisement is enabled on a port, the device will reject any configuration attempts to set the port to a forced speed mode (100 Mbps or 1000 Mbps).

• When the port speed down-shift feature is enabled on a combo port, the port will not support true media automatic detection, meaning the device will not be able to detect and select the fiber or copper connector

3 - 14 © Foundry Networks, Inc.

December 2005

Configuring Basic Software Features based on link availability.

Enabling Port Speed Down-Shift

To enable port speed down-shift on a port that has auto-negotiation enabled, enter a command such as the following at the Global CONFIG level of the CLI:

FESX424 Switch(config)# link-config gig copper autoneg-control down-shift e 1 e 2

The above command configures Gigabit copper ports 1 and 2 to establish a link at 1000 Mbps over a 4-pair wire when possible, or to down-shift (reduce the speed) to 100 Mbps when the medium is a 2-pair wire.

Syntax: [no] link-config gig copper autoneg-control down-shift ethernet [<slotnum>/]<portnum> [ethernet

[<slotnum>/]<portnum>]

You can enable port speed down-shift on one or two ports at a time.

To disable port speed down-shift after it has been enabled, enter the no form of the command.

Configuring Maximum Port Speed Advertisement

To configure a maximum port speed advertisement of 10 Mbps on a port that has auto-negotiation enabled, enter a command such as the following at the Global CONFIG level of the CLI:

FESX424 Switch(config)# link-config gig copper autoneg-control 10m e 1

To configure a maximum port speed advertisement of 100 Mbps on a port that has auto-negotiation enabled, enter the following command at the Global CONFIG level of the CLI:

FESX424 Switch(config)# link-config gig copper autoneg-control 100m e 2

Syntax: [no] link-config gig copper autoneg-control 10m | 100m ethernet [<slotnum>/]<portnum> [ethernet

[<slotnum>/]<portnum>]

You can enable maximum port speed advertisement on one or two ports at a time.

To disable maximum port speed advertisement after it has been enabled, enter the no form of the command.

Modifying Port Duplex Mode

You can manually configure a 10/100 Mbps port to accept either full-duplex (bi-directional) or half-duplex (unidirectional) traffic.

NOTE: You can modify the port duplex mode of copper ports only. This feature does not apply to fiber ports.

Port duplex mode and port speed are modified by the same command.

Configuration Syntax

To change the port speed of interface 8 from the default of 10/100/1000 auto-sense to 10 Mbps operating at fullduplex, enter the following:

FESX424 Switch(config)# interface e 8

FESX424 Switch(config-if-e1000-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

• auto

The default is auto.

December 2005 © Foundry Networks, Inc.

3 - 15

Foundry Configuration Guide for the FESX, FSX, and FWSX

Configuring MDI/MDIX

The Foundry FastIron devices support automatic Media Dependent Interface (MDI) and Media Dependent

Interface Crossover (MDIX) detection on all Gigabit Ethernet Copper ports.

MDI/MDIX is a type of Ethernet port connection using twisted pair cabling. The standard wiring for end stations is

MDI, whereas the standard wiring for hubs and switches is MDIX. MDI ports connect to MDIX ports using straightthrough twisted pair cabling. For example, an end station connected to a hub or a switch uses a straight-through cable. MDI-to-MDI and MDIX-to-MDIX connections use crossover twisted pair cabling. So, two end stations connected to each other, or two hubs or switches connected to each other, use crossover cable.

The auto MDI/MDIX detection feature can automatically correct errors in cable selection, making the distinction between a straight-through cable and a crossover cable insignificant.

Configuration Notes

• This feature applies to copper ports only.

• The mdi-mdix auto command works only when auto-negotiation is ON. If auto-negotiation is OFF and you enter the command mdi-mdix auto , the device automatically resets the port to an MDIX only port. In this case, although the Foundry device does not apply the mdi-mdix auto configuration, it accepts and saves it.

Consequently, when auto-negotiation is turned back ON, the Foundry device applies the mdi-mdix auto configuration.

• The mdi-mdix mdi and mdi-mdix mdix commands work independently of auto-negotiation. Thus, these commands work whether auto-negotiation is turned ON or OFF.

• Do not use the mdi-mdix commands on ports that are manually configured with a speed/duplex of 100-full .

In this case, make sure the other port (remote end of the connection) is also configured to 100-full and a cross-over cable is used if the connected device is another switch, hub, or router, or a straight-through cable if the connected device is a host NIC.

Configuration Syntax

The auto MDI/MDIX detection feature is enabled on all Gigabit copper ports by default. For each port, you can disable auto MDI/MDIX, designate the port as an MDI port, or designate the port as an MDIX port.

To turn off automatic MDI/MDIX detection and define a port as an MDI only port:

FESX424 Router(config-if-e1000-2)# mdi-mdix mdi

To turn off automatic MDI/MDIX detection and define a port as an MDIX only port:

FESX424 Router(config-if-e1000-2)# mdi-mdix mdix

To turn on automatic MDI/MDIX detection on a port that was previously set as an MDI or MDIX port:

FESX424 Router(config-if-e1000-2)# mdi-mdix auto

Syntax: mdi-mdix <mdi | mdix | auto>

After you enter the mdi-mdix command, the Foundry device resets the port and applies the change.

To display the MDI/MDIX settings, including the configured value and the actual resolved setting (for mdi-mdix auto ), enter the command show interface at any level of the CLI.

Disabling or Re-Enabling a Port

A 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 of a Foundry device, enter the following:

FESX424 Switch(config)# interface e 8

FESX424 Switch(config-if-e1000-8)# disable

Syntax: disable

You also can disable or re-enable a virtual interface. To do so, enter commands such as the following:

3 - 16 © Foundry Networks, Inc.

December 2005

Configuring Basic Software Features

FESX424 Switch(config)# interface ve v1

FESX424 Switch(config-vif-1)# disable

Syntax: disable

To re-enable a virtual interface, enter the enable command at the Interface configuration level. For example, to reenable virtual interface v1, enter the following command:

FESX424 Switch(config-vif-1)# enable

Syntax: enable

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:

FESX424 Switch(config)# no flow-control

To turn the feature back on:

FESX424 Switch(config)# flow-control

Syntax: [no] flow-control

Changing the Gigabit Fiber Negotiation Mode

The globally configured Gigabit negotiation mode is the default mode for all Gigabit fiber ports. You can override the globally configured default and set individual ports to 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.

• 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:

FESX424 Switch(config)# int ethernet 1 to 4

FESX424 Switch(config-mif-1-4)# gig-default auto-gig

This command overrides the global setting and sets the negotiation mode to auto-Gigabit for ports 1 – 4.

Syntax: gig-default neg-full-auto | auto-gig | neg-off

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 the chapter “Configuring Quality of Service” on page 13-1.

Enabling Dynamic Configuration of Voice over IP (VoIP) Phones

You can configure a FastIron device to automatically detect and re-configure a VoIP phone when it is physically moved from one port to another within the same device. To do so, you must configure a voice VLAN ID on the port to which the VoIP phone is connected. The software stores the voice VLAN ID in the port’s database for retrieval by the VoIP phone.

The dynamic configuration of a VoIP phone works in conjunction with the VoiP phone’s discovery process. Upon installation, and sometimes periodically, a VoIP phone will query the Foundry device for VoIP information and will advertise information about itself, such as, device ID, port ID, and platform. When the Foundry device receives the

December 2005 © Foundry Networks, Inc.

3 - 17

Foundry Configuration Guide for the FESX, FSX, and FWSX

VoIP phone’s query, it sends the voice VLAN ID in a reply packet back to the VoIP phone. The VoIP phone then configures itself within the voice VLAN.

As long as the port to which the VoIP phone is connected has a voice VLAN ID, the phone will configure itself into that voice VLAN. If you change the voice VLAN ID, the software will immediately send the new ID to the VoIP phone, and the VoIP phone will re-configure itself with the new voice VLAN.

Configuration Notes

• This feature is supported in software releases 02.2.00 and later for the FESX, FSX, and FWSX devices.

• This feature works with any VoIP phone that:

• Runs CDP

• Sends a VoIP VLAN query message

• Can configure its voice VLAN after receiving the VoIP VLAN reply

• Automatic configuration of a VoIP phone will not work if one of the following applies:

• You do not configure a voice VLAN ID for a port with a VoIP phone

• You remove the configured voice VLAN ID from a port without configuring a new one

• You remove the port from the voice VLAN

• Make sure the port is able to intercept CDP packets ( cdp run command).

• Some VoIP phones may require a reboot after configuring or re-configuring a voice VLAN ID. For example, if your VoIP phone queries for VLAN information only once upon boot up, you must reboot the VoIP phone before it can accept the VLAN configuration. If your phone is powered by a PoE device, you can reboot the phone by disabling then re-enabling the port.

Enabling Dynamic Configuration of a Voice over IP (VoIP) phone

You can create a voice VLAN ID for a port, or for a group of ports.

To create a voice VLAN ID for a port, enter commands such as the following:

FESX424 Switch(config)# interface e 2

FESX424 Switch(config-if-e1000-2)# voice-vlan 1001

To create a voice VLAN ID for a group of ports, enter commands such as the following:

FESX424 Switch(config)# interface e 1-8

FESX424 Switch(config-mif-1-8)# voice-vlan 1001

Syntax: [no] voice-vlan <voice-vlan-num> where <voice-vlan-num> is a valid VLAN ID between 1 – 4095.

To remove a voice VLAN ID, use the no form of the command.

Viewing Voice VLAN Configurations

You can view the configuration of a voice VLAN for a particular port or for all ports.

To view the voice VLAN configuration for a port, use the show voice-vlan <port-num> command. The following example shows the command output results.

FESX424 Switch(config)# show voice-vlan ethernet 2

Voice vlan ID for port 2: 1001

3 - 18 © Foundry Networks, Inc.

December 2005

Configuring Basic Software Features

The following example shows the message that appears when the port does not have a configured voice VLAN.

FESX424 Switch(config)# show voice-vlan ethernet 2

Voice vlan is not configured for port 2.

To view the voice VLAN for all ports, use the show voice-vlan command. The following example shows the command output results.

FESX424 Switch(config)# show voice-vlan

Port ID

2

8

15

Voice-vlan

1001

150

200

Syntax: show voice-vlan [<port-num>]

December 2005 © Foundry Networks, Inc.

3 - 19

Foundry Configuration Guide for the FESX, FSX, and FWSX

3 - 20 © Foundry Networks, Inc.

December 2005

Chapter 4

Configuring Basic Layer 2 Features

The procedures in this chapter describe how to configure basic Layer 2 parameters.

Foundry devices are configured at the factory with default parameters that allow you to begin using the basic features of the system immediately. However, many of the advanced features such as VLANs or routing protocols for the device must first be enabled at the system (global) level before they can be configured. If you use the

Command Line Interface (CLI) to configure system parameters, you can find these system level parameters at the

Global CONFIG level of the CLI.

This chapter contains the topics listed in Table 4.1

Table 4.1: List of Basic Layer 2 Features

Basic Layer 2 Feature

About port regions

Spanning Tree Protocol (STP)

Aging time for learned MAC address entries

Static, non-aging MAC address entries

Port-based VLANs

MAC address filters

Port locks

System parameters

Mirror ports (for traffic diagnosis and troubleshooting)

See Page

4-2

4-2

4-3

4-3

4-4

4-5

4-7

4-8

4-12

NOTE:

• Before assigning or modifying any router parameters, you must assign the IP subnet (interface) addresses for each port.

• For information about configuring IP addresses, DNS resolver, DHCP assist, and other IP-related parameters, see the chapter “Configuring IP” on page 16-1.

• For information about the Syslog buffer and messages, see “Using Syslog” on page A-1.

December 2005 © Foundry Networks, Inc.

4 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX

About Port Regions

Ports on the X-Series devices are grouped into regions. For a few features, you will need to know the region to which a port belongs. However, for most features, a port’s region does not affect configuration or operation of the feature.

NOTE: Port regions do not apply to trunk group configurations on the X-Series devices. However, port regions do apply to port monitoring and unknown unicast configurations.

FastIron Edge Switch X424 and X424HF, and FastIron Workgroup Switch X424:

• Ports 1 – 12

• Ports 13 – 24

• Port 25

• Port 26

FastIron Edge Switch X448 and FastIron Workgroup Switch X448:

• Ports 1 – 12

• Ports 13 – 24

• Port 25 – 36

• Port 37 – 48

• Port 49

• Port 50

FastIron SuperX:

• Management Module:

• Ports 1 – 12

• 24-port Gigabit Ethernet Copper Interface Module

• Ports 1 – 12

• Ports 13 – 24

• 24-port Gigabit Ethernet Fiber Interface Module:

• Ports 1 – 12

• Ports 13 – 24

• 2-port 10-Gigabit Ethernet Fiber Interface Module

• Port 1

• Port 2

Enabling or Disabling the Spanning Tree Protocol (STP)

STP (IEEE 802.1d bridge protocol) is supported on all Foundry devices. STP detects and eliminates logical loops in the network. 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.

NOTE: This section provides instructions for enabling and disabling STP. For configuration procedures and information about Foundry’s IronClad STP, see the chapter “Configuring Spanning Tree Protocol (STP) and

IronSpan Features” on page 7-1 in this guide.

4 - 2 © Foundry Networks, Inc.

December 2005

Configuring Basic Layer 2 Features

STP must be enabled at the system level to allow assignment of this capability on the VLAN level. On devices running Layer 2 code, STP is enabled by default. On devices running Layer 3 code, STP is disabled by default.

To enable STP for all ports on a Foundry device:

FESX424 Switch(config)# spanning tree

Syntax: [no] spanning-tree

You can also enable and disable spanning tree on a port-based VLAN and on an individual port basis, and enable advanced STP features. See “Configuring Spanning Tree Protocol (STP) and IronSpan Features” on page 7-1.

Modifying STP Bridge and Port Parameters

You can modify the following STP Parameters:

• Bridge parameters – forward delay, maximum age, hello time, and priority

• Port parameters – priority and path cost

For configuration details, see “Changing STP Bridge and Port Parameters” on page 7-5.

Changing the MAC Age Time

By default, learned MAC entries do not age out until they are unused for 300 – 600 seconds. You can change the

MAC age time by entering the following command:

FESX424 Router(config)# mac-age-time 60

Syntax: [no] mac-age-time <secs>

You can configure 0 or a value from 60 – 600 (seconds), in 60-second intervals. If you set the MAC age time to 0, aging is disabled.

NOTE: The actual age time is from one to two times the configured value. For example, if you set the MAC age time to 60 seconds, learned MAC entries age out after remaining unused for between 60 – 120 seconds.

To display the MAC table, enter the following command:

FESX424 Router(config)# show mac-address

Total active entries from all ports = 3

Total static entries from all ports = 1

MAC-Address Port Type VLAN

1234.1234.1234 15 Static 1

0004.8038.2f24 14 Dynamic 1

0004.8038.2f00 13 Dynamic 1

0010.5a86.b159 10 Dynamic 1

In the output of the show mac-address command, the Type column indicates whether the MAC entry is static or dynamic. A static entry is one you create using the static-mac-address command. A dynamic entry is one that is learned by the software from network traffic.

The output of the show mac-address command on FESX, FSX, and FWSX devices include an Index column which indicates the index where the entry exists in the hardware MAC table.

Configuring Static MAC Entries

Static MAC addresses can be assigned to Foundry devices.

NOTE: Foundry devices running Layer 3 code also support the assignment of static IP Routes, static ARP, and static RARP entries. For details on configuring these types of static entries, see “Configuring Static Routes” on page 16-32 and “Creating Static ARP Entries” on page 16-28.

December 2005 © Foundry Networks, Inc.

4 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

You can manually input the MAC address of a device to prevent it from being aged out of the system address table.

This option can be used to prevent traffic for a specific device, such as a server, from flooding the network with traffic when it is down. Additionally, the static MAC address entry is used to assign higher priorities to specific

MAC addresses.

You can specify traffic 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 default and maximum MAC table sizes for your device, display the system parameter values. See “Displaying and

Modifying System Parameter Default Settings” on page 4-8.

Command Syntax

To add a static entry for a server with a MAC address of 1145.5563.67FF and a priority of 7 to port 2, enter the following command:

FESX424 Switch(config)# static-mac-address 1145.5563.67FF e 2 priority 7

Syntax: [no] static-mac-address <mac-addr> ethernet [<slotnum>/]<portnum> priority <num>

The <slotnum> parameter is required on chassis devices.

The priority <num> can be 0 – 7 (0 is lowest priority and 7 is highest priority). The default priority is 0. 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.

Enabling Port-Based VLANs

When using the CLI, port and protocol-based VLANs are created by entering one of the following commands at the global CONFIG level of the CLI.

To create a port-based VLAN, enter commands such as the following:

FESX424 Router(config)# vlan 222 by port

FESX424 Router(config)# vlan 222 name Mktg

Syntax: vlan <num> by port

Syntax: vlan <num> name <string>

The <num> parameter specifies the VLAN ID. The valid range for VLAN IDs starts at 1 on all systems but the upper limit of the range differs depending on the device. In addition, you can change the upper limit on some devices using the system max-vlans...

command. See the Foundry Switch and Router Command Line Interface

Reference .

The <string> parameter is the VLAN name and can be a string up to 32 characters. You can use blank spaces in the name if you enclose the name in double quotes (for example, “Product Marketing”.)

You can configure up to 4063 port-based VLANs on a device running Layer 2 code or 4061 port-based VLANs on a device running Layer 3 code. Each port-based VLAN can contain either tagged or untagged ports. A port cannot be a member of more than one port-based VLAN unless the port is tagged. On both device types, valid

VLAN IDs are 1 – 4095. You can configure up to the maximum number of VLANs within that ID range.

4 - 4 © Foundry Networks, Inc.

December 2005

Configuring Basic Layer 2 Features

NOTE: VLAN ID 4094 is reserved for use by Single STP. VLAN IDs 4091 and 4092 are reserved for use in the

Layer 3 Switch and Base Layer 3 images. You can configure these VLAN IDs in the Layer 2 Switch image.

NOTE: The second command is optional and also creates the VLAN if the VLAN does not already exist. You can enter the first command after you enter the second command if you first exit to the global CONFIG level of the CLI.

Assigning IEEE 802.1Q Tagging to a Port

When a port is tagged, it allows communication among the different VLANs to which it is assigned. A common use for this might be to place an email server that multiple groups may need access to on a tagged port, which in turn, is resident in all VLANs that need access to the server.

NOTE: Tagging does not apply to the default VLAN.

When using the CLI, ports are defined as either tagged or untagged at the VLAN level.

Command Syntax

Suppose you want to make port 5 a member of port-based VLAN 4, a tagged port. To do so, enter the following:

FESX424 Router(config)# vlan 4

FESX424 Router(config-vlan-4)# tagged e 5

Syntax: tagged ethernet [<slotnum>/]<portnum> [to [<slotnum>/]<portnum> [ethernet [<slotnum>/]<portnum>...]]

The <slotnum> parameter is required on chassis devices.

Defining MAC Address Filters

MAC layer filtering enables you to build access lists based on MAC layer headers in the Ethernet/IEEE 802.3 frame. You can filter on the source and destination MAC addresses. The filters apply to incoming traffic only.

You configure MAC filters globally, then apply them to individual interfaces. To apply MAC filters to an interface, you add the filters to that interface’s MAC filter group.

The device takes the action associated with the first matching filter. If the packet does not match any of the filters in the access list, the default action is to drop the packet. If you want the system to permit traffic by default, you must specifically indicate this by making the last entry in the access list a permit filter. Here is an example: mac filter <last-index-number> permit any any

For devices running Layer 3 code, the MAC filter is applied only to those inbound packets that are to be switched.

This includes those ports associated with a virtual routing interface. However, the filter is not applied to the virtual routing interface. It is applied to the physical port.

NOTE: Inbound traffic on a port to which a Layer 2 MAC filter is assigned is sent to the CPU for processing.

When you create a MAC filter, it takes effect immediately. You do not need to reset the system. However, you do need to save the configuration to flash memory to retain the filters across system resets.

For complete MAC filter examples, see the Foundry Switch and Router Command Line Interface Reference .

Configuration Notes

• MAC filtering on FastIron devices is performed in hardware.

• Layer 2 MAC filtering on FastIron devices differ from other Foundry devices in that you can only filter on source and destination MAC addresses. Other Foundry devices allow you to also filter on the encapsulation type and frame type.

• Use MAC Layer 2 filters only for switched traffic. If a routing protocol (for example, IP) is configured on an interface, a MAC filter defined on that interface is not applied to inbound packets. If you want to filter inbound

December 2005 © Foundry Networks, Inc.

4 - 5

Foundry Configuration Guide for the FESX, FSX, and FWSX route traffic, configure a route filter.

• Layer 2 MAC filtering on the FESX, FSX, and FWSX differs from the FES and BigIron in that MAC filtering applies to all traffic, including management traffic. To exclude management traffic from being filtered, configure a MAC filter that explicitly permits all traffic headed to the management MAC (destination) address.

The MAC address for management traffic is always the MAC address of port 1.

• You cannot use Layer 2 filters to filter Layer 4 information. To filter Layer 4 information, use IP access policies.

See the appendix “Policies and Filters” on page C-1.

• MAC Layer 2 filters are not supported on tagged ports in the base Layer 3 and full Layer 3 images.

Command Syntax

To configure and apply a MAC filter, enter commands such as the following:

FESX424 Switch(config)# mac filter 1 deny 3565.3475.3676 ffff.0000.0000

FESX424 Switch(config)# mac filter 1024 permit any any

FESX424 Switch(config)# int e 1

FESX424 Switch(config-if-e1000-1)# mac filter-group 1

These commands configure a filter to deny ARP traffic with a source MAC address that begins with “3565” to any destination. The second filter permits all traffic that is not denied by another filter.

NOTE: Once you apply a MAC filter to a port, the device drops all Layer 2 traffic on the port that does not match a

MAC permit filter on the port.

Syntax: mac filter <filter-num> permit | deny any | <H.H.H> any | <H.H.H>

The permit | deny argument determines the action the software takes when a match occurs.

The <src-mac> <mask> | any parameter specifies the source MAC address. You can enter a specific address value and a comparison mask or the keyword any to filter on all MAC addresses. Specify the mask using f’s

(ones) and zeros. For example, to match on the first two bytes of the address aabb.ccdd.eeff, use the mask ffff.0000.0000. In this case, the filter matches on all MAC addresses that contain "aabb" as the first two bytes.

The filter accepts any value for the remaining bytes of the MAC address. If you specify any , do not specify a mask.

In this case, the filter matches on all MAC addresses.

The <dest-mac> <mask> | any parameter specifies the destination MAC address. The syntax rules are the same as those for the <src-mac> <mask> | any parameter.

Syntax: mac filter log-enable

Globally enables logging for filtered packets.

Syntax: mac filter-group log-enable

Enables logging for filtered packets on a specific port.

Syntax: mac filter-group <filter-list>

Applies MAC filters to a port.

NOTE: The filters must be applied as a group. For example, if you want to apply four filters to an interface, they must all appear on the same command line.

NOTE: You cannot add or remove individual filters in the group. To add or remove a filter on an interface, apply the filter group again containing all the filters you want to apply to the port.

NOTE: If you apply a filter group to a port that already has a filter group applied, the older filter group is replaced by the new filter group.

4 - 6 © Foundry Networks, Inc.

December 2005

Configuring Basic Layer 2 Features

Enabling Logging of Packets Denied by MAC Filters

You can configure the Foundry device to generate Syslog entries and SNMP traps for packets that are denied by

Layer 2 MAC filters. You can enable logging of denied packets on a global basis or an individual port basis.

The first time an entry in a MAC filter denies a packet and logging is enabled for that entry, the software generates a Syslog message and an SNMP trap. Messages for packets denied by MAC filters are at the warning level of the

Syslog.

When the first Syslog entry for a packet denied by a MAC filter is generated, the software starts a five-minute MAC filter timer. After this, the software sends Syslog messages every five minutes. The messages list the number of packets denied by each MAC filter during the previous five-minute interval. If a MAC filter does not deny any packets during the five-minute interval, the software does not generate a Syslog entry for that MAC filter.

NOTE: For a MAC filter to be eligible to generate a Syslog entry for denied packets, logging must be enabled for the filter. The Syslog contains entries only for the MAC filters that deny packets and have logging enabled.

When the software places the first entry in the log, the software also starts the five-minute timer for subsequent log entries. Thus, five minutes after the first log entry, the software generates another log entry and SNMP trap for denied packets.

Configuration Notes

MAC filter logging is supported in the following FastIron configurations:

• FESX devices running software release 02.1.01 or later

• All FSX devices and associated software releases

• All FWSX devices and associated software releases

These releases support MAC filter logging of management traffic only.

Command Syntax

To configure Layer 2 MAC filter logging globally, enter the following CLI commands at the global CONFIG level:

FESX424 Switch(config)# mac filter log-enable

FESX424 Switch(config)# write memory

Syntax: [no] mac filter log-enable

To configure Layer 2 MAC filter logging for MAC filters applied to ports 1 and 3, enter the following CLI commands:

FESX424 Switch(config)# int ethernet 1

FESX424 Switch(config-if-e1000-1)# mac filter-group log-enable

FESX424 Switch(config-if-e1000-1)# int ethernet 3

FESX424 Switch(config-if-e1000-3)# mac filter-group log-enable

FESX424 Switch(config-if-e1000-3)# write memory

Syntax: [no] mac filter-group log-enable

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. This feature is disabled by default. A maximum of 2048 entries can be specified for access. The default address count is eight.

Configuration Notes

• Static trunk ports and link-aggregation configured ports on FastIron devices do not support the lock-address option.

• The MAC port security feature is a more robust version of this feature. See “Using the MAC Port Security

December 2005 © Foundry Networks, Inc.

4 - 7

Foundry Configuration Guide for the FESX, FSX, and FWSX

Feature” in the Foundry Security Guide .

Command Syntax

To enable address locking for port 2 and place a limit of 15 entries, enter a command such as the following:

FESX424 Switch(config)# lock e 2 addr 15

Syntax: lock-address ethernet [<slotnum>/]<portnum> [addr-count <num>]

The <slotnum> parameter is required on chassis devices.

The <num> parameter is a value from 1 – 2048.

Displaying and Modifying System Parameter Default Settings

Foundry devices have default table sizes for the system parameters shown in the following display outputs. The table sizes determine the maximum number of entries the tables can hold. You can adjust individual table sizes to accommodate your configuration needs.

The tables you can configure, as well the defaults and valid ranges for each table, differ depending on the Foundry device you are configuring. To display the adjustable tables on your Foundry device, use the show default values command. The following shows example outputs on FESX, FSX, and FWSX devices.

NOTE: If you increase the number of configurable subnet addresses on each port, 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 Foundry device, you must save the change to the startup-config file, then reload the software to place the change into effect.

4 - 8 © Foundry Networks, Inc.

December 2005

Configuring Basic Layer 2 Features

To display the configurable tables and their defaults and maximum values, enter the following command at any level of the CLI. The following shows an example output on the FESX.

FESX424 Router# 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

System Parameters Default Maximum Current ip-arp 4000 64000 4000 ip-static-arp 512 1024 512 atalk-route 1024 1536 1024 atalk-zone-port 64 255 64 atalk-zone-sys 768 2048 768 multicast-route 64 8192 64 dvmrp-route 2048 32000 2048 dvmrp-mcache 512 4096 512 pim-mcache 1024 4096 1024 igmp-max-group-addr 4096 8192 4096 ip-cache 256000 400000 256000 ip-filter-port 1015 1015 1015 ip-filter-sys 2048 4096 2048 ipx-forward-filter 32 128 32 ipx-rip-entry 2048 8192 2048 ipx-rip-filter 32 128 32 ipx-sap-entry 4096 8192 4096 ipx-sap-filter 32 128 32 l3-vlan 32 1024 32 ip-qos-session 1024 16000 1024 mac 16000 16000 16000 ip-route 80000 128000 80000 ip-static-route 64 1024 64 vlan 64 4095 4095 spanning-tree 32 128 32 mac-filter-port 16 256 16 mac-filter-sys 32 512 32 ip-subnet-port 24 128 24 session-limit 65536 160000 65536 view 10 65535 10 virtual-interface 255 512 255 hw-ip-next-hop 2048 6144 2048 hw-logical-interface4096 4096 4096 hw-ip-mcast-mll 1024 4096 1024

December 2005 © Foundry Networks, Inc.

4 - 9

Foundry Configuration Guide for the FESX, FSX, and FWSX

The following shows an example output of the show default values command on the FSX

FastIron SuperX Router# 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

System Parameters Default Maximum Current ip-arp 4000 64000 4000 ip-static-arp 512 1024 512 atalk-route 1024 1536 1024 atalk-zone-port 64 255 64 atalk-zone-sys 768 2048 768 multicast-route 64 8192 64 dvmrp-route 2048 32000 2048 dvmrp-mcache 512 4096 512 pim-mcache 1024 4096 1024 igmp-max-group-addr 4096 8192 4096 ip-cache 256000 400000 256000 ip-filter-port 1015 1015 1015 ip-filter-sys 2048 4096 2048 ipx-forward-filter 32 128 32 ipx-rip-entry 2048 8192 2048 ipx-rip-filter 32 128 32 ipx-sap-entry 4096 8192 4096 ipx-sap-filter 32 128 32 l3-vlan 32 1024 32 ip-qos-session 1024 16000 1024 mac 16000 16000 16000 ip-route 80000 200000 80000 ip-static-route 64 1024 64 vlan 64 4095 4095 spanning-tree 32 255 32 mac-filter-port 16 256 16 mac-filter-sys 32 512 32 ip-subnet-port 24 128 24 session-limit 65536 160000 65536 view 10 65535 10 virtual-interface 255 512 255 hw-ip-next-hop 2048 6144 2048 hw-logical-interface 4096 4096 4096 hw-ip-mcast-mll 1024 4096 1024

4 - 10 © Foundry Networks, Inc.

December 2005

Configuring Basic Layer 2 Features

The following shows an example output of the show default values command on the FWSX

FWSX Switch# show default values sys log buffers:50 mac age time:300 sec telnet sessions:5

System Parameters Default Maximum Current igmp-max-group-addr 255 1024 255 l3-vlan 32 1024 32 mac 16000 16000 16000 vlan 64 4095 4095 spanning-tree 32 128 32 mac-filter-port 32 256 32 mac-filter-sys 64 512 64 view 10 65535 10

Information for the configurable tables appears under the columns that are shown in bold type in the above examples. 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:

FESX424 Switch(config)# system-max ip-route 120000

FESX424 Switch(config)# write memory

FESX424 Switch(config)# exit

FESX424 Switch# reload

NOTE: If you accidentally 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 device running Layer 3 code from 24 to 64, then increase the total number of IP interfaces you can configure on the device from 256 to 512, enter the following commands:

FESX424 Switch(config)# system-max subnet-per-interface 64

FESX424 Switch(config)# write memory

FESX424 Switch(config)# exit

FESX424 Switch# 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.

FESX424 Switch(config)# system-max subnet-per-system 512

FESX424 Switch(config)# write memory

FESX424 Switch(config)# exit

FESX424 Switch# reload

December 2005 © Foundry Networks, Inc.

4 - 11

Foundry Configuration Guide for the FESX, FSX, and FWSX

Configuring Port Mirroring and Monitoring

FastIron devices support monitoring of both inbound and outbound traffic on individual ports. To configure port monitoring, specify the mirror port , then enable monitoring on the monitored port .

• The mirror port is the port to which the monitored traffic is copied. Attach your protocol analyzer to the mirror port.

• The monitored port is the port whose traffic you want to monitor.

Configuration Considerations

Refer to the following rules when configuring port mirroring and monitoring:

• FESX and FWSX devices support sFlow and inbound port monitoring together on the same device, however, these devices do not support port monitoring and sFlow together within the same port region. See the section “About Port Regions” on page 4-2 for a list of valid port ranges on these devices.

• FSX devices running software release 02.2.01 or later support sFlow and inbound port monitoring together on the same device; however, both features cannot coexist within the same port region. See the section “About

Port Regions” on page 4-2 for a list of valid port ranges on FSX devices.

• You can configure a mirror port specifically as an ingress port, an egress port, or both.

• You can configure multiple ingress and egress mirror ports. For 1-Gigabit ports, ports in groups of 12 share one ingress mirror port and one egress mirror port. So ports 1 and 2 cannot have different mirror ports, but ports 1 and 13 can. Each 10-Gigabit port can have one ingress mirror port and one egress mirror port.

• You can configure up to eight egress monitored ports.

• You can configure any number of ingress monitored ports.

• Mirror ports can run at any speed and are not related to the speed of the ingress or egress monitored ports.

• The same port cannot be both a monitored port and the mirror port.

• The same port can be monitored by one mirror port for ingress traffic and another mirror port for egress traffic.

• The mirror port cannot be a trunk port.

• The monitored port and its mirror port do not need to belong to the same port-based VLAN.

• If the mirror port is in a different VLAN from the monitored port, the packets are tagged with the monitor port’s VLAN ID.

• If the mirror port is in the same VLAN as the monitored port, the packets are tagged or untagged, depending on the mirror port’s configuration.

• More than one monitored port can be assigned to the same mirror port.

• If the primary interface of a trunk is enabled for monitoring, the entire trunk will be monitored. You can also enable an individual trunk port for monitoring using the config-trunk-ind command.

Command Syntax

To configure port monitoring, enter commands such as the following:

FESX424 Switch(config)# mirror-port ethernet 4

FESX424 Switch(config)# interface ethernet 11

FESX424 Switch(config-if-e1000-11)# monitor ethernet 4 both|in|out

Syntax: [no] mirror-port ethernet [<slotnum>/]<portnum> [input | output]

Syntax: [no] monitor ethernet [<slotnum>/]<portnum> both | in | out

The <portnum> parameter specifies the mirror port to which the monitored port’s traffic will be copied. If you are configuring a chassis device, specify the slot number as well (<slotnum>/<portnum>).

4 - 12 © Foundry Networks, Inc.

December 2005

Configuring Basic Layer 2 Features

The [input | output] parameters apply to the FESX, FSX, and FWSX devices only. This parameter configures the mirror port exclusively for ingress or egress traffic. If you do not specify one, both types of traffic apply.

The both | in | out parameters specify the traffic direction you want to monitor on the mirror port. There is no default.

To display the port monitoring configuration, enter the show monitor and show mirror commands.

December 2005 © Foundry Networks, Inc.

4 - 13

Foundry Configuration Guide for the FESX, FSX, and FWSX

4 - 14 © Foundry Networks, Inc.

December 2005

Chapter 5

Configuring Base Layer 3 and Enabling Routing Protocols

The Layer 2 with Base Layer 3 software image contains all the system-level features in the Layer 2 images, along with the following:

• Static IP routes

• RIPv1 and RIPv2 (see note, below)

• Routing between directly connected subnets

• RIP advertisements of the directly connected subnets

NOTE:

• Layer 2 with Base Layer 3 images provide static RIP support. The device does not learn RIP routes from other Layer 3 devices. However, the device does advertise directly connected routes. Foundry Networks recommends that you deploy these devices only at the edge of your network, since incoming traffic can learn directly-connected routes advertised by the Foundry device, but outgoing traffic to other devices must use statically configured or default routes.

• The Base Layer 3 images do not support IP multicasting, OSPF, or BGP4.

• The Base Layer 3 images do not support protocol VLANs.

• FWSX devices are Layer 2 switches only. They do not support Base Layer 3 and full Layer 3 features.

The procedures in this chapter describe how to perform the tasks listed in Table 5.1.

Table 5.1: Procedures in This Chapter

Task

Adding a static IP route

Adding a static entry to the ARP table

Modifying and displaying Layer 3 system parameter limits

(FESX and FSX devices only)

Configuring RIP in the Base Layer 3 software image

Enabling or disabling other Layer 3 routing protocols in the full Layer 3 software image

See Page

5-2

5-2

5-3

5-4

5-7

December 2005 © Foundry Networks, Inc.

5 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX

Table 5.1: Procedures in This Chapter (Continued)

Task

Enabling or disabling Layer 2 switching

See Page

5-7

Adding a Static IP Route

To add a static IP route, enter a command such as the following at the global CONFIG level of the CLI:

FESX424 Router(config)# ip route 209.157.2.0 255.255.255.0 192.168.2.1

This command adds a static IP route to the 209.157.2.x/24 subnet.

Syntax: [no] ip route <dest-ip-addr> <dest-mask> <next-hop-ip-addr> [<metric>] or

Syntax: [no] ip route <dest-ip-addr>/<mask-bits> <next-hop-ip-addr> [<metric>]

The <dest-ip-addr> is the route’s destination. The <dest-mask> is the network mask for the route’s destination IP address. Alternatively, you can specify the network mask information by entering a forward slash followed by the number of bits in the network mask. For example, you can enter 192.0.0.0 255.255.255.0 as 192.0.0.0/.24. To configure a default route, enter 0.0.0.0 for <dest-ip-addr> and 0.0.0.0 for <dest-mask> (or 0 for the <mask-bits> if you specify the address in CIDR format). Specify the IP address of the default gateway using the <next-hop-ipaddr> parameter.

The <next-hop-ip-addr> is the IP address of the next-hop router (gateway) for the route.

The <metric> parameter specifies the cost of the route and can be a number from 1 – 16. The default is 1. The metric is used by RIP. If you do not enable RIP, the metric is not used.

NOTE: You cannot specify null0 or another interface as the next hop in the Base Layer 3 image.

Adding a Static ARP Entry

Static entries are useful in cases where you want to pre-configure an entry for a device that is not connected to the

Foundry device, or you want to prevent a particular entry from aging out. The software removes a dynamic entry from the ARP cache if the ARP aging interval expires before the entry is refreshed. Static entries do not age out, regardless of whether the Foundry device receives an ARP request from the device that has the entry’s address.

The software places a static ARP entry into the ARP cache as soon as you create the entry.

To add a static ARP entry, enter a command such as the following at the global CONFIG level of the CLI:

FESX424 Router(config)# arp 1 209.157.22.3 aaaa.bbbb.cccc ethernet 3

This command adds a static ARP entry that maps IP address 209.157.22.3 to MAC address aaaa.bbbb.cccc. The entry is for a MAC address connected to FESX424 Router port 3.

Syntax: [no] arp <num> <ip-addr> <mac-addr> ethernet [<slotnum>/]<portnum>

The <num> parameter specifies the entry number. You can specify a number from 1 up to the maximum number of static entries allowed on the device. You can allocate more memory to increase this amount. To do so, enter the system-max ip-static-arp <num> command at the global CONFIG level of the CLI.

The <ip-addr> command specifies the IP address of the device that has the MAC address of the entry.

The <mac-addr> parameter specifies the MAC address of the entry.

The <portnum> command specifies the port number attached to the device that has the MAC address of the entry.

If you are configuring a chassis device, specify the slot number as well as the port number (<slotnum>/

<portnum>).

5 - 2 © Foundry Networks, Inc.

December 2005

Configuring Base Layer 3 and Enabling Routing Protocols

NOTE: The clear arp command clears learned ARP entries but does not remove any static ARP entries.

Modifying and Displaying Layer 3 System Parameter Limits

You can configure the following Layer 3 system parameters:

• number of IP next hops and IP route entries

• number of hardware logical interfaces (physical port and VLAN pairs)

• number of output interfaces (clients)

T hese parameters are automatically enabled with pre-defined default values. You can however, adjust these values to conform with your network’s topology.

To display the current settings for the Layer 3 system parameters, use the show default value command. See

“Displaying Layer 3 System Parameter Limits” on page 5-4.

To modify the default settings for the Layer 3 system parameters, use the system max command at the Global

CONFIG level of the CLI. See “Modifying Layer 3 System Parameter Limits” on page 5-3.

Configuration Note

Changing the system parameters reconfigures the device’s memory. Whenever you reconfigure the memory on a

Foundry device, you must save the change to the startup-config file, then reload the software to place the change into effect.

Modifying Layer 3 System Parameter Limits

The Layer 3 system parameter limits share the same hardware memory space and, by default, consume all of the hardware memory allocated for these Layer 3 limits. Therefore, to increase the limit for one of the parameters, you must first decrease one or both of the other parameters’ limits. If you enter a value that exceeds the memory limit, the CLI will display an error message and the configuration will not take effect.

For example, if the network topology has a smaller number of IP next hops and routes, but has numerous multicast output interfaces, you could decrease the number of IP next hops and routes, then increase the number of multicast output interfaces. To do so, enter commands such as the following:

FESX424 Router(config)# system-max hw-ip-next-hop 1024

FESX424 Router(config)# system-max hw-ip-mcast-mll 2048

FESX424 Router(config)# write mem

FESX424 Router(config)# reload

Likewise, if the network topology does not have a large number of VLANs, and the VLANs configured on physical ports are not widely distributed, you could decrease the number of hardware logical interfaces, then increase the number of IP next hops and multicast output interfaces. To do so, enter commands such as the following:

FESX424 Router(config)# system-max hw-logical-interface 2048

FESX424 Router(config)# system-max hw-ip-next-hop 3072

FESX424 Router(config)# system-max hw-ip-mcast-mll 2048

FESX424 Router(config)# write mem

FESX424 Router(config)# reload

Syntax: system max hw-ip-next-hop <num>

Syntax: system max hw-logical-interface <num>

Syntax: system max hw-ip-mcast-mll <num>

The hw-ip-next-hop <num> parameter specifies the maximum number of IP next hops and routes supported on the device. Note that the maximum number includes unicast next hops and multicast route entries. Enter a number from 100 to 6144. The default is 2048.

December 2005 © Foundry Networks, Inc.

5 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

The hw-logical-interface <num> parameter specifies the number of hardware logical interface pairs (physical port and VLAN pairs) supported on the device. Enter a number from 0 to 4096. When this parameter is set to

4096 (the maximum), the limit is not enforced. If you enter a number less than 4096, the limit is the total number of physical port and VLAN pairs that are IP-enabled in the system. The default is 4096.

The hw-ip-mcast-mll <num> parameter specifies the maximum number of multicast output interfaces (clients) supported on the device. If a given source or group has clients in n tagged VLANs on the router, then n + 1 mll entries are consumed for that source or group entry. Enter a number from 0 to 4096. The default is 1024.

Displaying Layer 3 System Parameter Limits

To display the Layer 3 system parameter defaults, maximum values, and current values, enter the following command at any level of the CLI:

FESX424 Router# show default value 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 igmp group memb.:140 sec igmp query:60 sec ospf dead:40 sec ospf hello:10 sec ospf retrans:5 sec ospf transit delay:1 sec

System Parameters Default Maximum Current ip-arp 4000 64000 4000 ip-static-arp 512 1024 512 some lines omitted for brevity....

hw-ip-next-hop 2048 6144 2048 hw-logical-interface 4096 4096 4096 hw-ip-mcast-mll 1024 4096 1024

Configuring RIP

RIP is disabled by default. If you want the Foundry device to use RIP, you must enable the protocol globally, then enable RIP on individual ports. When you enable RIP on a port, you also must specify the version (version 1 only, version 2 only, or version 1 compatible with version 2).

Optionally, you also can set or change the following parameters:

• Route redistribution – You can enable the software to redistribute static routes from the IP route table into RIP.

Redistribution is disabled by default.

• Learning of default routes – The default is disabled.

• Loop prevention (split horizon or poison reverse) – The default is poison reverse.

Enabling RIP

RIP is disabled by default. To enable it, use the following CLI method. You must enable the protocol both globally and on the ports on which you want to use RIP.

To enable RIP globally, enter the following command:

5 - 4 © Foundry Networks, Inc.

December 2005

Configuring Base Layer 3 and Enabling Routing Protocols

FESX424 Router(config)# router rip

Syntax: [no] router rip

To enable RIP on a port and specify the RIP version, enter commands such as the following:

FESX424 Router(config-rip-router)# interface ethernet 1

FESX424 Router(config-if-e1000-1)# ip rip v1-only

This command changes the CLI to the configuration level for port 1and enables RIP version 1 on the interface.

You must specify the version.

Syntax: interface ethernet [<slotnum>/]<portnum>

Syntax: [no] ip rip v1-only | v1-compatible-v2 | v2-only

Enabling Redistribution of IP Static Routes into RIP

By default, the software does not redistribute the IP static routes in the route table into RIP. To configure redistribution, perform the following tasks:

• Configure redistribution filters (optional). You can configure filters to permit or deny redistribution for a route based on the route’s metric. You also can configure a filter to change the metric. You can configure up to 64 redistribution filters. The software uses the filters in ascending numerical order and immediately takes the action specified by the filter. Thus, if filter 1 denies redistribution of a given route, the software does not redistribute the route, regardless of whether a filter with a higher ID permits redistribution of that route.

NOTE: The default redistribution action is permit, even after you configure and apply a permit or deny filter.

To deny redistribution of specific routes, you must configure a deny filter.

NOTE: The option to set the metric is not applicable to static routes.

• Enable redistribution.

NOTE: If you plan to configure redistribution filters, do not enable redistribution until you have configured the filters.

When you enable redistribution, all IP static routes are redistributed by default. If you want to deny certain routes from being redistributed into RIP, configure deny filters for those routes before you enable redistribution. You can configure up to 64 RIP redistribution filters. They are applied in ascending numerical order.

NOTE: The default redistribution action is still permit, even after you configure and apply redistribution filters to the port. If you want to tightly control redistribution, apply a filter to deny all routes as the last filter (filter ID 64), then apply filters with lower filter IDs to allow specific routes.

To configure a redistribution filter, enter a command such as the following:

FESX424 Router(config-rip-router)# deny redistribute 1 static address 207.92.0.0

255.255.0.0

This command denies redistribution of all 207.92.x.x IP static routes.

Syntax: [no] permit | deny redistribute <filter-num> static address <ip-addr> <ip-mask>

[match-metric <value> | set-metric <value>]

The <filter-num> specifies the redistribution filter ID. Specify a number from 1 – 64. The software uses the filters in ascending numerical order. Thus, if filter 1 denies a route from being redistributed, the software does not redistribute that route even if a filter with a higher ID permits redistribution of the route.

The address <ip-addr> <ip-mask> parameters apply redistribution to the specified network and subnet address.

Use 0 to specify “any”. For example, “207.92.0.0 255.255.0.0“ means “any 207.92.x.x subnet”. However, to specify any subnet (all subnets match the filter), enter “address 255.255.255.255 255.255.255.255”.

December 2005 © Foundry Networks, Inc.

5 - 5

Foundry Configuration Guide for the FESX, FSX, and FWSX

The match-metric <value> parameter applies redistribution to those routes with a specific metric value; possible values are from 1 – 15.

The set-metric <value> parameter sets the RIP metric value that will be applied to the routes imported into RIP.

NOTE: The set-metric parameter does not apply to static routes.

The following command denies redistribution of a 207.92.x.x IP static route only if the route’s metric is 5.

FESX424 Router(config-rip-router)# deny redistribute 2 static address 207.92.0.0

255.255.0.0 match-metric 5

The following commands deny redistribution of all routes except routes for 10.10.10.x and 20.20.20.x:

FESX424 Router(config-rip-router)# deny redistribute 64 static address

255.255.255.255 255.255.255.255

FESX424 Router(config-rip-router)# permit redistribute 1 static address 10.10.10.0

255.255.255.0

FESX424 Router(config-rip-router)# permit redistribute 2 static address 20.20.20.0

255.255.255.0

Enabling Redistribution

After you configure redistribution parameters, you need to enable redistribution.

To enable RIP redistribution, enter the following command:

FESX424 Router(config-rip-router)# redistribution

Syntax: [no] redistribution

Enabling Learning of Default Routes

By default, the software does not learn RIP default routes.

To enable learning of default RIP routes, enter commands such as the following:

FESX424 Router(config)# interface ethernet 1

FESX424 Router(config-if-e1000-1)# ip rip learn-default

Syntax: interface ethernet [<slotnum>/]<portnum>

Syntax: [no] ip rip learn-default

The <slotnum>/ parameter applies to chassis devices only.

Changing the Route Loop Prevention Method

RIP can use the following methods to prevent routing loops:

• Split horizon – The Foundry device does not advertise a route on the same interface as the one on which it learned the route.

• Poison reverse – The Foundry device assigns a cost of 16 (“infinite” or “unreachable”) to a route before advertising it on the same interface as the one on which it learned the route. This is the default.

NOTE: These methods are in addition to RIP’s maximum valid route cost of 15.

To enable split horizon, enter commands such as the following:

FESX424 Router(config)# interface ethernet 1

FESX424 Router(config-if-e1000-1)# no ip rip poison-reverse

Syntax: [no] ip rip poison-reverse

5 - 6 © Foundry Networks, Inc.

December 2005

Configuring Base Layer 3 and Enabling Routing Protocols

Other Layer 3 Protocols

For information about other IP configuration commands in the Layer 2 with Base Layer 3 image that are not included in this chapter, see the chapter “Configuring IP” on page 16-1.

For information about enabling or disabling Layer 3 routing protocols, see “Enabling or Disabling Routing

Protocols” on page 5-7. For complete configuration information about the routing protocols, see the other chapters in this book.

Enabling or Disabling Routing Protocols

This section describes how to enable or disable routing protocols. For complete configuration information about the routing protocols, see the other chapters in this book.

FESX and FSX devices running full Layer 3 code support the following protocols:

• BGP4

• IGMP

• IP

• IP multicast (DVMRP, PIM-SM, PIM-DM)

• OSPF

• RIPV1 and V2

• VRRP

• VRRPE

• VSRP

IP routing is enabled by default on devices running Layer 3 code. 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, and RIP. To reset a system, enter the reload command at the privileged level of the CLI.

To enable a protocol on a device running full Layer 3 code, enter router at the global CONFIG level, followed by the protocol to be enabled. The following example shows how to enable OSPF:

FESX424 Router(config)# router ospf

FESX424 Router(config)# end

FESX424 Router# write memory

FESX424 Router# reload

Syntax: router bgp | dvmrp | ospf | pim | rip | vrrp | vrrpe | vsrp

Enabling or Disabling Layer 2 Switching

By default, Foundry Layer 3 Switches support Layer 2 switching. These devices switch the routing protocols that are not supported on the devices. If you want to disable Layer 2 switching, you can do so globally or on individual ports, depending on the version of software your device is running.

Configuration Notes

• Make sure you really want to disable all Layer 2 switching operations before you use this option. Consult your reseller or Foundry Networks for information.

• This feature is supported in the following configurations:

• The FESX running software release 01.1.00 or prior, supports disabling Layer 2 switching on a global basis only. Starting in release 02.1.01, the FESX supports disabling Layer 2 switching on an individual

December 2005 © Foundry Networks, Inc.

5 - 7

Foundry Configuration Guide for the FESX, FSX, and FWSX interface as well as on a global basis.

• The FSX running software release 02.2.00 or later supports disabling Layer 2 switching on an individual interface as well as on a global basis.

Command Syntax

To globally disable Layer 2 switching on a Layer 3 Switch, enter commands such as the following:

FESX424 Router(config)# route-only

FESX424 Router(config)# exit

FESX424 Router# write memory

FESX424 Router# reload

To re-enable Layer 2 switching on a Layer 3 Switch, enter the following:

FESX424 Router(config)# no route-only

FESX424 Router(config)# exit

FESX424 Router# write memory

FESX424 Router# 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 2:

FESX424 Router(config)# interface ethernet 2

FESX424 Router(config-if-e1000-2)# route-only

Syntax: [no] route-only

To re-enable Layer 2 switching, enter the command with “no”, as in the following example:

FESX424 Router(config-if-e1000-2)# no route-only

5 - 8 © Foundry Networks, Inc.

December 2005

Chapter 6

Configuring Power Over Ethernet

This chapter provides an overview of Power over Ethernet (POE) and describes how to enable or disable POE and how to configure POE parameters using CLI commands.

NOTE: This chapter applies to POE devices only.

This chapter contains the topics listed in Table 6.1.

Table 6.1: Chapter Contents

Description

Overview of Power over Ethernet

Enabling or disabling Power over Ethernet

Enabling the detection of POE power requirements advertised via CDP

Setting the maximum power level for a POE power consuming device

Specifying the power class for a POE power consuming device

Setting the in-line power priority for a POE port

Resetting POE parameters

Displaying Power over Ethernet information

See Page

6-1

6-5

6-6

6-6

6-7

6-8

6-9

6-10

Power over Ethernet Overview

This section provides an overview of the requirements for delivering power over the LAN, as defined by the

Institute of Electrical and Electronics Engineers Inc. (IEEE) in the 802.3af specification.

December 2005 © Foundry Networks, Inc.

6 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX

Foundry’s FSX (with POE daughter card) provides Power over Ethernet, compliant with the standards described in the IEEE 802.3af specification for delivering in-line power. The 802.3af specification defines the standard for delivering power over existing network cabling infrastructure, enabling multicast-enabled full streaming audio and video applications for converged services, such as, Voice over IP (VoIP), WLAN access points, IP surveillance cameras, and other IP technology devices.

POE technology eliminates the need for an electrical outlet and dedicated UPS near IP powered devices. With power sourcing devices, such as Foundry’s FSX, power is consolidated and centralized in the wiring closets, improving the reliability and resiliency of the network. Because POE can provide power over Ethernet cable, power is continuous, even in the event of a power failure.

Terms Used in This Section

The following terms are introduced in this section:

• Power sourcing device/equipment - This is the source of the power, or the device that integrates the power onto the network. Power sourcing devices/equipment have embedded POE technology. In this case, the power sourcing device is Foundry’s FSX.

• IP powered device or Power consuming device - This is the Ethernet device that requires power and is situated on the other end of the cable opposite the power sourcing equipment.

Methods for Delivering POE

There are two methods for delivering power over the network, as defined in the 802.3af specification:

• Endspan - Power is supplied through the Ethernet ports on a power sourcing device. With the Endspan solution, power can be carried over the two data pairs (Alternative A) or the two spare pairs (Alternative B).

• Midspan - Power is supplied by an intermediate power sourcing device placed between the switch and the powered device. With the Midspan solution, power is carried over the two spare pairs (Alternative B).

With both methods, power is transferred over four conductors, between the two pairs. 802.3af-compliant powered devices are able to accept power from either pairs.

Foundry’s FSX POE devices use the Endspan method, compliant with the 802.3af standard.

The Endspan and Midspan methods are described in more detail in the following sections.

NOTE: All 802.3af-compliant power consuming devices are required to support both application methods defined in the 802.3af specification.

Endspan

The POE Endspan method uses the Ethernet switch ports on power sourcing equipment, such as Foundry’s FSX

POE, which has embedded POE technology to deliver power over the network.

With the Endspan solution, there are two supported methods of delivering power. In Alternative A, four wires deliver data and power over the network. Specifically, power is carried over the live wire pairs that deliver data, as illustrated in Figure 6.1. In Alternative B, the four wires of the spare pairs are used to deliver power over the network. Foundry’s POE devices support Alternative A.

The Endspan method is illustrated in Figure 6.1.

6 - 2 © Foundry Networks, Inc.

December 2005

Figure 6.1

POE Endspan Delivery Method

POE Endspan Delivery Method

POWER

PS1

PS2

49C

50C

CONSOLE

49F

LINK

50F

ACT

1 2 3 4 5 6 7 8 9 10 11 12

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

FastIron Edge 4802 POE

25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

Switch with Power over Ethernet ports

Configuring Power Over Ethernet

IP phone

Power and data signals travel along the same pairs of wires at different frequencies.

Midspan

The POE Midspan solution uses an intermediate device, usually a powered device, to inject power into the network. The intermediate device is positioned between the switch and the powered device and delivers power over the network using the spare pairs of wires (Alternative B). The intermediate device has multiple channels

(typically 6 to 24), and each of the channels has data input and a data plus power RJ-45 output connector.

The Midspan method is illustrated in Figure 6.2.

Figure 6.2

POE Midspan Delivery Method

POE Midspan Delivery Method

POWER

PS1

PS2

49C

50C

CONSOLE

49F

LINK

50F

ACT

1 2 3 4 5 6 7 8 9 10 11 12

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

FastIron Edge 4802 POE

25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

Switch

Intermediate device

Power travels on unused spare pairs while data travels on other wire pairs.

IP phone

December 2005 © Foundry Networks, Inc.

6 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

Autodiscovery

POE autodiscovery is a detection mechanism that identifies whether or not an installed device is 802.3af compatible. When you plug a device into an Ethernet port that is capable of providing in-line power, the autodiscovery mechanism detects whether or not the device requires power and how much power is needed. The autodiscovery mechanism also has a disconnect protection mechanism that shuts down the power once a powered device has been disconnected from the network or when a faulty powered device has been detected.

This feature enables safe installation and prevents high-voltage damage to equipment.

POE autodiscovery is achieved by periodically transmitting current or test voltages that can detect when a powered device is attached to the network. When an 802.3af compatible device is plugged into a POE port, the powered device reflects test voltage back to the power sourcing device (the Foundry device), ultimately causing the power to be switched ON. Non-compatible 802.3af devices do not reflect test voltage back to the power sourcing device.

Power Class

Different power classes determine the amount of power a POE powered device receives. When a valid powered device is detected, the Foundry POE device performs power classification by inducing a specific voltage and measuring the current consumption of the powered device. Depending on the measured current, the Foundry device assigns the appropriate class to the powered device. Powered devices that do not support classification are assigned a class of 0 (zero). Table 6.3 shows the different power classes and their respective power consumption needs.

Table 6.2: Power Classes for Powered Devices

Class

0

1

2

3

4

Usage default optional optional optional future

Power (Watts)

15.4

4

7

15.4

class 0

Power Specifications

The actual implementation of the 802.3af standard limits power to 15.4W (44V to 57V) from the power sourcing device. This is in compliance with safety standards and existing wiring limitations. Though limited by the 802.3af standard, 15.4 watts of power is ample, as most powered devices consume an average of 5 to 12 watts of power.

IP phones, wireless LAN access points, and network surveillance cameras each consume an average of 3.5 to 9 watts of power.

The FSX’s 48-volt power supply (part number SX-POE-AC-PWR) provides power to the POE daughter card, and ultimately to POE power-consuming devices. The number of POE power-consuming devices that one 48-volt power supply can support depends on the number of watts required by each power-consuming device. Each 48volt power supply can provide 1080 watts of power, and each POE port supports a maximum of 15.4 watts of power per POE power-consuming device. For example, if each POE power-consuming device attached to the

FSX consumes 10 watts of power, one 48-volt supply will power up to 108 POE ports. You can install a second

48-volt supply for additional POE power. Power supply specifications are covered in the Foundry FastIron X-

Series Chassis Hardware Installation Guide and in the Foundry FastIron Stackable Hardware Installation Guide .

CAUTION: The SX-POE-AC-PWR power supply is designed exclusively for use with the FSX POE devices.

The power supply produces extensive power to support 802.3af applications. Installing the power supply in a device other than the FSX POE will cause extensive damage to your equipment.

6 - 4 © Foundry Networks, Inc.

December 2005

Configuring Power Over Ethernet

Cabling Requirements

The 802.3af standard currently supports POE on 10/100/1000 Mbps Ethernet ports operating over standard

Category 5 unshielded twisted pair (UTP) cable or better. If your network uses cabling categories less than 5, you cannot implement POE without first upgrading your cables to CAT 5 UTP or better.

Supported Powered Devices

Foundry’s FSX POE devices support the following types of IP powered devices:

• Voice over IP (VoIP) phones

• Wireless LAN access points

• IP surveillance cameras

The following sections briefly describe these IP powered devices.

VoIP

Voice over IP (VoIP) is the convergence of traditional telephony networks with data networks, utilizing the existing data network infrastructure as the transport system for both services. Traditionally, voice is transported on a network that uses circuit-switching technology, whereas data networks are built on packet-switching technology.

To achieve this convergence, technology has been developed to take a voice signal, which originates as an analog signal and transport it within a digital medium. This is done by devices, such as VoIP Telephones, which receive the originating tones and place them in UDP packets, the size and frequency of which is dependant on the Coding

/ Decoding (CODEC) technology that has been implemented in the VoIP Telephone / device. The VoIP control packets use the TCP/IP format.

Wireless LAN Access Points

Wireless LANs enable you to establish and maintain a wireless network connection within or between buildings, without the constraints of wires or cables as imposed by a wired LAN. Wireless LAN access points provide the link between the wired LAN and the wireless LAN.

Foundry’s IronPoint™ Access Point allows wireless clients to connect to your enterprise network. It is a fullfeatured access point that can be managed as a single device or by IronView Network Manager, a network management tool that manages several Foundry devices on a network. For more information about Foundry’s

IronPoint Access Point, see the IronPoint documentation on the Foundry technical support website.

One of the main concerns with wireless LAN access points is the additional protection needed to secure the network. To help ensure continuous security against unauthorized Wireless LAN Access Points deployment, and deliver advanced security for entry-level WLAN Access Points, the Foundry’s POE devices include IEEE 802.1x support for a flexible and dynamic security implementation. All switch ports can be configured as secured, requiring 802.1x authentication, or unsecured, requiring no authentication. For more information about this feature, refer to the Foundry Security Guide .

IP Surveillance Cameras

IP surveillance technology provides digital streaming of video over Ethernet, providing real-time, remote access to video feeds from cameras.

The main benefit of using IP surveillance cameras on the network is that you can view surveillance images from any computer on the network. If you have access to the Internet, you can securely connect from anywhere in the world to view a chosen facility or even a single camera from your surveillance system. By using a Virtual Private

Network (VPN) or the company intranet, you can manage password-protected access to images from the surveillance system. Similar to secure payment over the Internet, images and information are kept secure and can be viewed only by approved personnel.

Enabling or Disabling Power over Ethernet

To enable a port to receive in-line power for 802.3af-compliant and non-compliant power consuming devices, enter commands such as the following:

FastIron SuperX Router# config t

December 2005 © Foundry Networks, Inc.

6 - 5

Foundry Configuration Guide for the FESX, FSX, and FWSX

FastIron SuperX Router(config)# interface e 1/1

FastIron SuperX Router(config-if-e1000-1/1)# inline power

After entering the above commands, the console will display the following message:

FastIron SuperX Router(config-if-e1000-1/1)# PoE Info: Power enabled on port 1/1.

Syntax: [no] inline power

Use the no form of the command to disable the port from receiving in-line power.

NOTE: The FSX with POE can automatically detect whether or not a power consuming device is 802.3afcompliant. Therefore, the CLI command inline power legacy-powerdevice , which is used on FES POE devices to configure 802.3af non-compliant devices, does not apply on the FSX POE.

Enabling the Detection of POE Power Requirements

Advertised via CDP

Many power consuming devices, such as Cisco’s VOIP phones and other vendors’ devices, use CDP to advertise their power requirements to power sourcing devices, such as Foundry’s POE devices. Foundry’s power consuming devices are compatible with Cisco’s and other vendors’ power consuming devices, in that they can detect and process power requirements for these devices automatically.

Configuration Considerations

• This feature is supported in FSX POE devices running software release 02.2.00 or later

• If you configure a port with a maximum power level or a power class for a power consuming device, the power level or power class takes precedence over the CDP power requirement. Therefore, if you want the device to adhere to the CDP power requirement, do not configure a power level or power class on the port.

• The FSX POE will adjust a port’s power only if there are available power resources on the device.

Command Syntax

To enable the Foundry device to detect CDP power requirements, enter the following commands:

FastIron SuperX Switch# config t

FastIron SuperX Switch(config)# cdp run

Syntax: [no] cdp run

Use the no form of the command to disable the detection of CDP power requirements.

Setting the Maximum Power Level for a POE Power Consuming Device

When POE is enabled on a port to which a power consuming device is attached, by default, the Foundry POE device will supply 15.4 watts of power at the RJ45 jack, minus any power loss through the cables. For example, a

POE port with a default maximum power level of 15.4 watts will receive a maximum of 12.95 watts of power after

2.45 watts of power loss through the cable. This is compliant with the IEEE 802.3af specification for delivering inline power. Devices that are configured to receive less POE power, for example, 4.0 watts of power, will experience a lower rate of power loss through the cable.

If desired, you can manually configure the maximum amount of power that the Foundry POE device will supply at the RJ45 jack. You can specify from 1 to 15.4 watts of maximum power for each power consuming device connected to the switch.

Configuration Notes

• This feature is supported in FSX POE devices running release 02.2.00 or later

6 - 6 © Foundry Networks, Inc.

December 2005

Configuring Power Over Ethernet

• There are two ways to configure the power level for a POE power consuming device. The first method is discussed in this section. The other method is provided in the section “Setting the Power Class for a POE

Power Consuming Device” on page 6-7. For each POE port, you can configure either a maximum power level or a power class. You cannot configure both. You can, however, configure a maximum power level on one port and a power class on another port.

• The CLI commands for this feature differ on the FSX POE compared to the FES POE. On the FES POE, there are separate CLI commands for 802.3af-compliant versus 802.3-af non-compliant power consuming devices. On the FSX, there is one command for all power consuming devices. The command syntax is also different on the FSX. To configure your device, refer to the appropriate section, below.

Command Syntax

To configure the maximum power level for a power consuming device, enter commands such as the following:

FastIron SuperX Router# config t

FastIron SuperX Router(config)# interface e 1/1

FastIron SuperX Router(config-if-e1000-1/1)# inline power power-limit 14000

These commands enable in-line power on interface e 1 in slot 1 and set the POE power level to 14,000 milliwatts

(14 watts).

Syntax: inline power power-limit <power level> where <power level> is the number of milliwatts, between 1000 and 15400. The default is 15400.

For information about resetting the maximum power level, see “Resetting POE Parameters” on page 6-9.

Setting the Power Class for a POE Power Consuming Device

A power class specifies the maximum amount of power that a Foundry POE device will supply to a power consuming device. Table 6.3 shows the different power classes and their respective maximum power allocations.

Table 6.3: Power Classes for Power Consuming Devices

Class

0

1

2

3

Maximum

Power (Watts)

15.4 (default)

4

7

15.4

By default, the power class for all power consuming devices is zero (0). As shown in Table 6.3, a power consuming device with a class of 0 receives 15.4 watts of power.

Configuration Notes

• This feature is supported in the FSX POE devices running release 02.2.00 or later

• The power class sets the maximum power level for a power consuming device. Alternatively, you can set the maximum power level as instructed in the section “Setting the Maximum Power Level for a POE Power

Consuming Device” on page 6-6. For each POE port, you can configure either a power class or a maximum power level. You cannot configure both. You can, however, configure a power level on one port and power class on another port.

• The power class includes any power loss through the cables. For example, a POE port with a default power

December 2005 © Foundry Networks, Inc.

6 - 7

Foundry Configuration Guide for the FESX, FSX, and FWSX class of 0 (15.4 watts) will receive a maximum of 12.95 watts of power after 2.45 watts of power loss through the cable. This is compliant with the IEEE 802.3af specification for delivering in-line power. Devices that are configured to receive less POE power, for example, class 1 devices (4.0 watts), will experience a lower rate of power loss through the cable.

• The CLI commands for this feature differ on the FSX POE compared to the FES POE. On the FES POE, there are separate CLI commands for 802.3af-compliant versus 802.3-af non-compliant power consuming devices. On the FSX, there is one command for all power consuming devices. The command syntax is also different on the FSX.

Command Syntax

To configure the power class for a POE power consuming device, enter commands such as the following:

FastIron SuperX Switch# config t

FastIron SuperX Switch(config)# interface e 1/1

FastIron SuperX Switch(config-if-e1000-1/1)# inline power power-by-class 2

These commands enable in-line power on interface e 1 in slot 1 and set the power class to 2.

Syntax: inline power power-by-class <class value> where <class value> is the power class. Enter a value from 0 – 3. See Table 6.3 for the power classes and their respective maximum power allocations. The default is 0 (15.4 watts).

For information about resetting the power class, see “Resetting POE Parameters” on page 6-9.

Setting the In-line Power Priority for a POE Port

Each FSX POE (48V) power supply provides a maximum of 1080 watts of power, and each POE port receives a default maximum value of 15.4 watts of power, minus any power loss through the cable. The power capacity of one or two POE power supplies is shared among all POE power consuming devices attached to the FSX POE.

In a configuration where POE power consuming devices collectively have a greater demand for power than the

POE power supply or supplies can provide, the FSX must place the POE ports that it cannot power in standby or denied mode (waiting for power) until the available power increases. The available power increases when one or more POE ports are powered down, or, if applicable, when an additional POE power supply is installed in the FSX.

When POE ports are in standby or denied mode (waiting for power) and the FSX receives additional power resources, by default, the FSX will allocate newly available power to the standby ports in ascending order, by slot number then by port number, provided enough power is available for the ports. For example, POE port 1/11 should receive power before POE port 2/1. However, if POE port 1/11 needs 12 watts of power and POE port 2/1 needs 10 watts of power, and 11 watts of power become available on the device, the FSX will allocate the power to port 2/1 since it does not have sufficient power for port 1/11.

You can configure an in-line power priority on POE ports, whereby ports with a higher in-line power priority will take precedence over ports with a low in-line power priority. For example, if a new POE port comes on-line and the port is configured with a high priority, if necessary (if power is already fully allocated to power consuming devices), the FSX will remove power from a POE port or ports that have a lower priority and allocate the power to the POE port that has the higher value.

Ports that are configured with the same in-line power priority are given precedence based on the slot number and port number in ascending order, provided enough power is available for the port. For example, if both POE port 1/

2 and POE port 2/1 have a high in-line power priority value, POE port 1/2 will receive power before POE port 2/1.

However, if POE port 1/2 needs 12 watts of power and POE port 2/1 needs 10 watts of power, and 11 watts of power become available on the device, the FSX will allocate the power to POE port 2/1 since it does not have sufficient power for port 1/2. By default, all ports are configured with a low in-line power priority.

6 - 8 © Foundry Networks, Inc.

December 2005

Configuring Power Over Ethernet

Command Syntax

To configure an in-line power priority for a POE port on a FSX, enter commands such as the following:

FastIron SuperX Router# config t

FastIron SuperX Router(config)# interface e 1/1

FastIron SuperX Router(config-if-e1000-1/1)# inline power priority 2

These commands enable in-line power on interface e 1 in slot 1 and set the in-line power priority level to high.

Syntax: [no] inline power priority <priority num> where priority <priority num> is the in-line power priority number. The default is 3 (low priority). You can specify one of the following values:

• 3 – low priority

• 2 – high priority

• 1 – critical priority

Use the inline power command (without a priority number) to reset a port’s priority to the default (low) priority.

Use the no inline power command to disable the port from receiving in-line power.

For information about resetting the in-line power priority, see “Resetting POE Parameters” on page 6-9.

To view the in-line power priority for all POE ports, issue the show inline power command at the Privileged EXEC level of the CLI. See “Displaying POE Operational Status” on page 6-10.

Resetting POE Parameters

NOTE: This feature applies to the FSX POE only.

To override or reset POE port parameters including power priority, power class, and maximum power level, you must specify each POE parameter in the CLI command line. This section provides some examples.

EXAMPLE:

To change a POE port’s power priority from high to low (the default value) and keep the current maximum configured power level of 3000, enter commands such as the following:

FastIron SuperX Router# config t

FastIron SuperX Router(config)# interface e 1/1

FastIron SuperX Router(config-if-e1000-1/1)# inline power priority 3 power-limit

3000

Note that you must specify both the inline power priority and the maximum power level ( power-limit command), even though you are keeping the current configured maximum power level at 3000. If you do not specify the maximum power level, the device will apply the default value of15400 (15.4 watts). Also, you must specify the inline power priority before specifying the power limit.

EXAMPLE:

To change a port’s power class from 2 (4 watts max) to 3 (7 watts max) and keep the current configured power priority of 2, enter commands such as the following:

FastIron SuperX Router# config t

FastIron SuperX Router(config)# interface e 1/1

FastIron SuperX Router(config-if-e1000-1/1)# inline power priority 2 power-by-class

3

Note that you must specify both the power class and the inline power priority, even though you are not changing the power priority. If you do not specify the power priority, the device will apply the default value of 3 (low priority).

Also, you must specify the inline power priority before specifying the power class.

December 2005 © Foundry Networks, Inc.

6 - 9

Foundry Configuration Guide for the FESX, FSX, and FWSX

Displaying Power over Ethernet Information

This section lists the CLI commands for viewing POE information.

Displaying POE Operational Status

The show inline power command displays operational information about Power over Ethernet.

On the FSX, you can view the POE operational status for the entire device, for a specific POE module only, or for a specific interface only. In addition, on the FSX, you can use the show inline power detail command to display in depth information about POE power supplies.

The following shows an example of the show inline power display output on a FSX device.

FastIron SuperX Switch#show inline power

Power Capacity: Total is 2160000 mWatts. Current Free is 18800 mWatts.

Power Allocations: Requests Honored 769 times

... some lines omitted for brevity...

Port Admin Oper ---Power(mWatts)--- PD Type PD Class Pri Fault/

State State Consumed Allocated Error

--------------------------------------------------------------------------

4/1 On On 5070 9500 802.3af n/a 3 n/a

4/2 On On 1784 9500 Legacy n/a 3 n/a

4/3 On On 2347 9500 802.3af n/a 3 n/a

4/4 On On 2441 9500 Legacy n/a 3 n/a

4/5 On On 6667 9500 802.3af Class 3 3 n/a

4/6 On On 2723 9500 802.3af Class 2 3 n/a

4/7 On On 2347 9500 802.3af n/a 3 n/a

4/8 On On 2347 9500 802.3af n/a 3 n/a

4/9 On On 2347 9500 802.3af n/a 3 n/a

4/10 On On 4976 9500 802.3af Class 3 3 n/a

4/11 On On 4882 9500 802.3af Class 3 3 n/a

4/12 On On 4413 9500 802.3af Class 1 3 n/a

4/13 On On 7793 9500 802.3af n/a 3 n/a

4/14 On On 7512 9500 802.3af n/a 3 n/a

4/15 On On 8075 9500 802.3af n/a 3 n/a

4/16 On On 4131 9500 802.3af Class 1 3 n/a

4/17 On On 2347 9500 802.3af n/a 3 n/a

4/18 On Off 0 9500 n/a n/a 3 n/a

4/19 On On 5352 9500 Legacy n/a 3 n/a

4/20 On On 7981 9500 802.3af n/a 3 n/a

4/21 On On 12958 13000 802.3af Class 3 3 n/a

4/22 On On 12958 13000 802.3af Class 3 3 n/a

4/23 On On 13052 13000 802.3af Class 3 3 n/a

4/24 On On 12864 13000 802.3af Class 3 3 n/a

--------------------------------------------------------------------------

Total 137367 242000

... some lines omitted for brevity...

Grand Total 1846673 2127400

6 - 10 © Foundry Networks, Inc.

December 2005

Configuring Power Over Ethernet

Syntax: show inline power [<slot num>] | [<slot num>/<port num>]

Table 6.4 provides definitions for the statistics.

This Column...

Power Capacity

Power Allocations

Port

Admin State

Oper State

Power Consumed

Power Allocated

PD Type

Table 6.4: Field Definitions for the Show Inline Power Command

Displays...

The total POE power supply capacity and the amount of available power (current free) for POE power consuming devices. Both values are shown in milliwatts.

The number of times the FSX fulfilled POE requests for power.

The slot number and port number.

Specifies whether or not Power over Ethernet has been enabled on the port. This value can be one of the following:

• ON – The inline power command was issued on the port.

• OFF – The inline power command has not been issued on the port.

Shows the status of in-line power on the port. This value can be one of the following:

• ON – The POE power supply is delivering in-line power to the powered device.

• OFF – The POE power supply is not delivering in-line power to the powered device.

• DENIED – The port is in standby mode (waiting for power) because the FSX does not currently have enough available power for the port.

The number of current, actual milliwatts that the powered device is consuming.

The number of milliwatts allocated to the port. This value is either the default or configured maximum power level, or the power class that was automatically detected by the FSX.

The type of powered device connected to the port. This value can be one of the following:

• 802.3AF-PD – The powered device connected to this port is 802.3afcompliant.

• LEGACY – The powered device connected to this port is a legacy product

(not 802.3af-compliant).

• N/A – Power over Ethernet is configured on this port, and one of the following is true:

• The device connected to this port is a non-powered device.

• No device is connected to this port.

• The port is in standby or denied mode (waiting for power).

December 2005 © Foundry Networks, Inc.

6 - 11

Foundry Configuration Guide for the FESX, FSX, and FWSX

This Column...

PD Class

Pri

Total

Grand Total

Table 6.4: Field Definitions for the Show Inline Power Command

Displays...

Determines the maximum amount of power a powered device receives. This value can be one of the following:

• Class0 – Receives 15.4 watts maximum.

• Class1 – Receives 4 watts maximum

• Class2 – Receives 7 watts maximum

• Class3 – Receives 15.4 watts maximum

• Unknown – The device attached to the port cannot advertise its class.

The port’s in-line power priority , which determines the order in which the port will receive power while in standby mode (waiting for power). Ports with a higher priority will receive power before ports with a low priority. This value can be one of the following:

• 3 – low priority

• 2 – high priority

• 1 – critical priority

The total power in milliwatts being consumed by all powered devices connected to the Interface module, and the total power in milliwatts allocated to all powered devices connected to the Interface module.

The total number of current, actual milliwatts being consumed by all powered devices connected to the FSX, and the total number of milliwatts allocated to all powered devices connected to the FSX.

6 - 12 © Foundry Networks, Inc.

December 2005

Configuring Power Over Ethernet

Displaying Detailed Information About POE Power Supplies

The show inline power detail command displays detailed operational information about the POE power supplies in FSX POE devices.

To display detailed POE statistics, enter the following command:

FastIron SuperX Switch# show inline power detail

Power Supply Data:

++++++++++++++++++

Power Supply #1:

Firmware Ver: 0.2

Date: 3/15/5

H/W Status: 807

Max Curr: 26.5 Amps

Voltage: 50.0 Volts

Capacity: 1325 Watts

Consumption: 1144 Watts

Power Supply #2:

Firmware Ver: 0.2

Date: 3/15/5

H/W Status: 807

Max Curr: 26.5 Amps

Voltage: 50.0 Volts

Capacity: 1325 Watts

Consumption: 949 Watts

General PoE Data:

+++++++++++++++++

Slot Firmware

Version

--------------

1 04.0.0

2 04.0.0

3 04.0.0

4 04.0.0

5 04.0.0

6 04.0.0

7 04.0.0

8 04.0.0

... continued on next page...

December 2005 © Foundry Networks, Inc.

6 - 13

Foundry Configuration Guide for the FESX, FSX, and FWSX

... continued from previous page...

Cumulative Port State Data:

+++++++++++++++++++++++++++

Slot #Ports #Ports #Ports #Ports #Ports #Ports #Ports

Admin-On Admin-Off Oper-On Oper-Off Off-Denied Off-No-PD Off-Fault

-------------------------------------------------------------------------------

1 24 0 24 0 0 0 0

2 24 0 24 0 0 0 0

3 24 0 23 1 0 1 0

4 24 0 23 1 0 1 1

5 24 0 24 0 0 0 0

6 24 0 24 0 0 0 0

7 24 0 24 0 0 0 0

8 24 0 24 0 0 0 0

-------------------------------------------------------------------------------

Total:192 0 190 2 0 2 1

Cumulative Port Power Data:

+++++++++++++++++++++++++++

Slot #Ports #Ports #Ports Power Power

Pri: 1 Pri: 2 Pri: 3 Consumption Allocation

-----------------------------------------------------

1 24 0 0 310.146 W 312.0 W

2 0 0 24 308.454 W 312.0 W

3 0 0 24 108.727 W 172.500 W

4 0 0 24 137.366 W 232.500 W

5 24 0 0 56.991 W 145.400 W

6 0 0 24 309.112 W 312.0 W

7 0 0 24 308.548 W 312.0 W

8 24 0 0 307.796 W 312.0 W

-----------------------------------------------------

Total:72 0 120 1847.140 W 2110.400 W

Syntax: show inline power detail

6 - 14 © Foundry Networks, Inc.

December 2005

Configuring Power Over Ethernet

Table 6.4 provides definitions for the statistics displayed in the show inline power detail command.

Table 6.5: Field Definitions for the Show Inline Power Detail Command

This Column...

Power Supply Data

Firmware ver

Date

H/W Status

Max Curr

Voltage

Capacity

Consumption

Displays...

The POE power supply’s firmware version.

The POE power supply’s firmware test date in the format mm/dd/yyyy.

The POE power supply’s hardware status code. This field is used by Foundry

Technical Support for troubleshooting.

The POE power supply’s maximum current capacity.

The POE power supply’s current input voltage.

The POE power supply’s total power capacity (in watts).

The total number of watts consumed by POE power consuming devices and POE modules in the system, minus any internal or cable power loss.

General POE Data

Slot

Firmware Version

Cumulative Port State Data

Slot

# Ports Admin-On

The Interface module / slot number

The Interface module’s / slot number’s firmware version.

# Ports Admin-Off

# Ports Oper-On

# Ports Oper-Off

# Ports Off-Denied

# Ports Off-No-PD

# Ports Off-Fault

Total

Cumulative Port Power Data

Slot

# Ports Pri: 1

The Interface module / slot number

The number of ports on the Interface module on which the inline power command was issued.

The number of ports on the Interface module on which the inline power command was not issued.

The number of ports on the Interface module that are receiving in-line power from the POE power supply.

The number of ports on the Interface module that are not receiving in-line power from the POE power supply.

The number of ports on the Interface module that were denied power because of insufficient power.

The number of ports on the Interface module to which no powered devices are connected.

The number of ports on the Interface module that are not receiving power because of a subscription overload.

The totals for all of the fields in the Cumulative Port State Data report.

The Interface module / slot number

The number of POE ports on the Interface module that have a POE port priority of

1.

December 2005 © Foundry Networks, Inc.

6 - 15

Foundry Configuration Guide for the FESX, FSX, and FWSX

This Column...

# Ports Pri: 2

# Ports Pri: 3

Power Consumption

Power Allocation

Total

Table 6.5: Field Definitions for the Show Inline Power Detail Command

Displays...

The number of POE ports on the Interface module that have a POE port priority of

2.

The number of POE ports on the Interface module that have a POE port priority of

3.

The total number of watts consumed by both POE power consuming devices and the POE module (daughter card) attached to the Interface module.

The number of watts allocated to the Interface module’s POE ports. This value is the sum of the ports’ default or configured maximum power levels, or power classes automatically detected by the FSX.

The totals for all of the fields in the Cumulative Port Power Data report.

6 - 16 © Foundry Networks, Inc.

December 2005

Chapter 7

Configuring Spanning Tree Protocol (STP)

and IronSpan Features

This chapter describes how to configure Spanning Tree Protocol (STP) and IronSpan parameters on Foundry

Layer 3 Switches using the CLI. IronSpan features extend the operation of standard STP, enabling you to fine tune standard STP and avoid some of its limitations.

Chapter Contents

Table 7.1: Chapter Contents

Description

Overview of STP

Configuring standard STP parameters

STP Parameters and defaults

Enabling and disabling STP

Changing STP bridge and port parameters

STP Protection enhancement

Displaying STP information

Configuring IronSpan features

Fast Port Span

802.1W Rapid Spanning Tree (RSTP)

802.1W Draft 3 RSTP (both 802.1W Draft 3 and full

802.1W are supported)

Single-instance STP (SSTP)

STP per VLAN group

Per VLAN Spanning Tree (PVST)/PVST+ compatibility

7-8

7-16

7-16

7-18

7-53

7-2

7-4

7-5

7-6

See Page

7-2

7-2

7-56

7-58

7-61

December 2005 © Foundry Networks, Inc.

7 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX

STP Overview

The Spanning Tree Protocol (STP) eliminates Layer 2 loops in networks, by selectively blocking some ports and allowing other ports to forward traffic, based on global (bridge) and local (port) parameters you can configure.

You can enable or disable STP on a global basis (for the entire device), a port-based VLAN basis (for the individual Layer 2 broadcast domain), or an individual port basis.

Configuration procedures are provided for the standard STP bridge and port parameters as well as Foundry

IronSpan parameters.

IronSpan is a set of Layer 2 features that enable you to overcome limitations in the standard 802.1d Spanning Tree

Protocol (STP). IronSpan includes the features listed in Table 7.1.

Configuring Standard STP Parameters

Foundry Layer 2 Switches and Layer 3 Switches support standard STP as described in the IEEE 802.1D specification. STP is enabled by default on Layer 2 Switches but disabled by default on Layer 3 Switches.

By default, each port-based VLAN on a Foundry device runs a separate spanning tree (a separate instance of

STP). A Foundry device has one port-based VLAN (VLAN 1) by default that contains all the device’s ports. Thus, by default each Foundry device has one spanning tree. However, if you configure additional port-based VLANs on a Foundry device, then each of those VLANs on which STP is enabled and VLAN 1 all run separate spanning trees.

If you configure a port-based VLAN on the device, the VLAN has the same STP state as the default STP state on the device. Thus, on Layer 2 Switches, new VLANs have STP enabled by default. On Layer 3 Switches, new

VLANs have STP disabled by default. You can enable or disable STP in each VLAN separately. In addition, you can enable or disable STP on individual ports.

STP Parameters and Defaults

Table 7.2 lists the default STP states for Foundry devices.

Table 7.2: Default STP States

Device Type Default STP Type Default STP State Default STP State of New VLANs a

Layer 2 Switch

MSTP b

MSTP

Enabled Enabled

Layer 3 Switch Disabled Disabled a.When you create a port-based VLAN, the new VLAN’s STP state is the same as the default STP state on the device. The new VLAN does not inherit the STP state of the default VLAN. b.MSTP stands for “Multiple Spanning Tree Protocol”. In this type of STP, each port-based VLAN, including the default VLAN, has its own spanning tree.

References in this documentation to “STP” apply to MSTP. The Single Spanning

Tree Protocol (SSTP) is another type of STP. SSTP includes all VLANs on which

STP is enabled in a single spanning tree. See “Single Spanning Tree (SSTP)” on page 7-56.

7 - 2 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Table 7.3 lists the default STP bridge parameters. The bridge parameters affect the entire spanning tree. If you 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

Maximum Age

Hello Time

Priority

Table 7.3: Default STP Bridge Parameters

Description

The period of time spent by a port in the listening and learning state before moving on to the learning or forwarding state, respectively.

The forward delay value is also used for the age time of dynamic entries in the filtering database, when a topology change occurs.

The interval a bridge will wait for a configuration BPDU 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

15 seconds

Possible values: 4 – 30 seconds

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 STP specification.

2 * (forward_delay -1) >= max_age max_age >= 2 * (hello_time +1 )

Table 7.4 lists the default STP port parameters. The port parameters affect individual ports and are separately configurable on each port.

Parameter

Priority

Table 7.4: Default STP Port Parameters

Description

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.

Default and Valid Values

128

Possible values: 8 – 252

(configurable in increments of 4)

December 2005 © Foundry Networks, Inc.

7 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

Parameter

Path Cost

Table 7.4: Default STP Port Parameters (Continued)

Description Default and Valid Values

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.

10 Mbps – 100

100 Mbps – 19

Gigabit – 4

10 Gigabit – 2

Possible values are 0 – 65535

Enabling or Disabling the Spanning Tree Protocol (STP)

STP is enabled by default on devices running Layer 2 code. STP is disabled by default on devices running Layer

3 code.

You can enable or disable STP on the following levels:

• Globally – Affects all ports and port-based VLANs on the device.

• Port-based VLAN – Affects all ports within the specified port-based VLAN. When you enable or disable STP within a port-based VLAN, the setting overrides the global setting. Thus, you can enable STP for the ports within a port-based 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.

NOTE: The CLI converts the STP groups into topology groups when you save the configuration. For backward compatibility, you can still use the STP group commands. However, the CLI converts the commands into the topology group syntax. Likewise, the show stp-group command displays STP topology groups. See “Topology

Groups” on page 1.

7 - 4

Enabling or Disabling STP Globally

Use the following method to enable or disable STP on a device on which you have not configured port-based

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 Foundry device, enter the following command:

FESX424 Router(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 in a Port-Based VLAN

Use the following procedure to disable or enable STP on a device on which you have configured a port-based

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:

FESX424 Router(config)# vlan 10

FESX424 Router(config-vlan-10)# spanning-tree

Syntax: [no] spanning-tree

© Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Enabling or Disabling STP on an Individual 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:

FastIron SuperX Router(config)# interface 1/1

FastIron SuperX Router(config-if-e1000-1/1)# spanning-tree

Syntax: [no] spanning-tree

Changing STP Bridge and Port Parameters

Table 7.3 on page 7-3 and Table 7.4 on page 7-3 list the default STP parameters. If you need to change the default value for an STP parameter, use the following procedures.

Changing STP Bridge Parameters

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 STP specification.

2 * (forward_delay -1) >= max_age max_age >= 2 * (hello_time +1 )

To change a Foundry device’s STP bridge priority to the highest value to make the device the root bridge, enter the following command:

FESX424 Router(config)# spanning-tree priority 0

The command in this example changes the priority on a device on which you have not configured port-based

VLANs. The change applies to the default VLAN. If you have configured a port-based VLAN on the device, you can configure the parameters only at the configuration level for individual VLANs. Enter commands such as the following:

FESX424 Router(config)# vlan 20

FESX424 Router(config-vlan-20)# spanning-tree priority 0

To make this change in the default VLAN, enter the following commands:

FESX424 Router(config)# vlan 1

FESX424 Router(config-vlan-1)# spanning-tree priority 0

Syntax: [no] spanning-tree [forward-delay <value>] | [hello-time <value>] | [maximum-age <value>] | [priority

<value>]

The forward-delay <value> parameter specifies the forward delay and can be a value from 4 – 30 seconds. The default is 15 seconds.

NOTE: You can configure a Foundry device for faster convergence (including a shorter forward delay) using Fast

Span. See “Configuring IronSpan Features” on page 7-16.

The hello-time <value> parameter specifies the hello time and can be a value from 1 – 10 seconds. The default is 2 seconds.

NOTE: This parameter applies only when this device or VLAN is the root bridge for its spanning tree.

The maximum-age <value> parameter specifies the amount of time the device waits for receipt of a configuration

BPDU from the root bridge before initiating a topology change. You can specify from 6 – 40 seconds. The default is 20 seconds.

December 2005 © Foundry Networks, Inc.

7 - 5

Foundry Configuration Guide for the FESX, FSX, and FWSX

7 - 6

The priority <value> parameter specifies the priority and can be a value from 0 – 65535. A higher numerical value means a lower priority. Thus, the highest priority is 0. The default is 32768.

You can specify some or all of these parameters on the same command line. If you specify more than one parameter, you must specify them in the order shown above, from left to right.

Changing STP Port Parameters

To change the path and priority costs for a port, enter commands such as the following:

FESX424 Router(config)# vlan 10

FESX424 Router(config-vlan-10)# spanning-tree ethernet 5 path-cost 15 priority 64

Syntax: spanning-tree ethernet [<slotnum>/]<portnum> path-cost <value> | priority <value> | disable | enable

The <portnum> parameter specifies the interface. If you are configuring a chassis device, specify the slot number as well as the port number (<slotnum>/<portnum>).

The path-cost <value> parameter specifies the port’s cost as a path to the spanning tree’s root bridge. STP prefers the path with the lowest cost. You can specify a value from 0 – 65535.

The default depends on the port type:

• 10 Mbps – 100

• 100 Mbps – 19

• Gigabit – 4

• 10 Gigabit – 2

The priority <value> parameter specifies the preference that STP gives this port relative to other ports for forwarding traffic out of the spanning tree. You can specify a value from 8 – 252, in increments of 4. If you enter a value that is not divisible by four the software rounds to the nearest value that is. The default is 128. A higher numerical value means a lower priority; thus, the highest priority is 8.

NOTE: If you are upgrading a device that has a configuration saved under an earlier software release, and the configuration contains a value from 0 – 7 for a port’s STP priority, the software changes the priority to the default when you save the configuration while running the new release.

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.

STP Protection Enhancement

STP protection provides the ability to prohibit an end station from initiating or participating in an STP topology change.

The 802.1W Spanning Tree Protocol (STP) detects and eliminates logical loops in a redundant network by selectively blocking some data paths (ports) and allowing only the best data paths to forward traffic.

In an STP environment, switches, end stations, and other Layer 2 devices use Bridge Protocol Data Units

(BPDUs) to exchange information that STP will use to determine the best path for data flow. When a Layer 2 device is powered ON and connected to the network, or when a Layer 2 device goes down, it sends out an STP

BPDU, triggering an STP topology change.

In some instances, it is unnecessary for a connected device, such as an end station, to initiate or participate in an

STP topology change. In this case, you can enable the STP Protection feature on the Foundry port to which the end station is connected. Foundry’s STP Protection feature disables the connected device’s ability to initiate or participate in an STP topology change, by dropping all BPDUs received from the connected device.

Configuration Notes

This feature is supported in the following configurations:

• FESX devices running software release 02.1.01 or later

• All FSX and FWSX devices and associated software releases

© Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Enabling STP Protection

You can enable STP Protection on a per-port basis.

To prevent an end station from initiating or participating in STP topology changes, enter the following command at the Interface level of the CLI:

FESX424 Switch#(config) interface e 2

FESX424 Switch#(config-if-e1000-2)# stp-protect

This command causes the port to drop STP BPDUs sent from the device on the other end of the link.

Syntax: [no] stp-protect

Enter the no form of the command to disable STP protection on the port.

Clearing BPDU Drop Counters

For each port that has STP Protection enabled, the Foundry device counts and records the number of dropped

BPDUs. You can use CLI commands to clear the BPDU drop counters for all ports on the device, or for a specific port on the device.

To clear the BPDU drop counters for all ports on the device that have STP Protection enabled, enter the following command at the Global CONFIG level of the CLI:

FESX424 Switch(config)# clear stp-protect-statistics

To clear the BPDU drop counter for a specific port that has STP Protection enabled, enter the following command at the Global CONFIG level of the CLI:

FESX424 Switch(config)# clear stp-protect-statistics e 2

Syntax: clear stp-protect-statistics [ethernet [<slotnum>/]<port-num>] | [ethernet [<slotnum>/]portnum>]

Viewing the STP Protection Configuration

You can view the STP Protection configuration for all ports on a device, or for a specific port only. The show stpprotect command output shows the port number on which STP Protection is enabled, and the number of BPDUs dropped by each port.

To view the STP Protection configuration for all ports on the device, enter the following command at any level of the CLI:

FESX424 Switch# show stp-protect

Port ID BPDU Drop Count

3 478

5 213

6 0

12 31

To view STP Protection configuration for a specific port, enter the following command at any level of the CLI:

FESX424 Switch# show stp-protect e 3

STP-protect is enabled on port 3. BPDU drop count is 478

If you enter the show stp-protect command for a port that does not have STP protection enabled, the following message displays on the console:

FESX424 Switch# show stp-protect e 4

STP-protect is not enabled on port 4.

Syntax: show stp-protect [ethernet [<slotnum>/]<portnum>]

December 2005 © Foundry Networks, Inc.

7 - 7

Foundry Configuration Guide for the FESX, FSX, and FWSX

Displaying STP Information

You can display the following STP information:

• All the global and interface STP settings

• CPU utilization statistics

• Detailed STP information for each interface

• STP state information for a port-based VLAN

• STP state information for an individual interface

Displaying STP Information for an Entire Device

To display STP information, enter the following command at any level of the CLI:

FastIron SuperX Router# show span

VLAN 1 BPDU cam_index is 3 and the Master DMA Are(HEX)

STP instance owned by VLAN 1

Global STP (IEEE 802.1D) Parameters:

VLAN Root Root Root Prio Max He- Ho- Fwd Last Chg Bridge

ID ID Cost Port rity Age llo ld dly Chang cnt Address

Hex sec sec sec sec sec

1 800000e0804d4a00 0 Root 8000 20 2 1 15 689 1 00e0804d4a00

Port STP Parameters:

Port Prio Path State Fwd Design Designated Designated

Num rity Cost Trans Cost Root Bridge

Hex

1 80 19 FORWARDING 1 0 800000e0804d4a00 800000e0804d4a00

2 80 0 DISABLED 0 0 0000000000000000 0000000000000000

3 80 0 DISABLED 0 0 0000000000000000 0000000000000000

4 80 0 DISABLED 0 0 0000000000000000 0000000000000000

5 80 19 FORWARDING 1 0 800000e0804d4a00 800000e0804d4a00

6 80 19 BLOCKING 0 0 800000e0804d4a00 800000e0804d4a00

7 80 0 DISABLED 0 0 0000000000000000 0000000000000000

<lines for remaining ports excluded for brevity>

Syntax: show span [vlan <vlan-id>] | [pvst-mode] | [<num>] |

[detail [vlan <vlan-id> [ethernet [<slotnum>/]<portnum>] | <num>]]

The vlan <vlan-id> parameter displays STP information for the specified port-based VLAN.

The pvst-mode parameter displays STP information for the device’s Per VLAN Spanning Tree (PVST+) compatibility configuration. See “PVST/PVST+ Compatibility” on page 7-61.

The <num> parameter displays only the entries after the number you specify. For example, on a device 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 span 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 7-12.

7 - 8 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

The show span command shows the following information.

Table 7.5: CLI Display of STP Information

Displays...

This Field...

Global STP Parameters

VLAN ID

Root ID

Root Cost

Root Port

Priority Hex

Max age sec

Hello sec

Hold sec

Fwd dly sec

Last Chang sec

Chg cnt

Bridge Address

The port-based VLAN that contains this spanning tree (instance of

STP). VLAN 1 is the default VLAN. If you have not configured portbased VLANs on this device, all STP information is for VLAN 1.

The ID assigned by STP to the root bridge for this spanning tree.

The cumulative cost from this bridge to the root bridge. If this device is the root bridge, then the root cost is 0.

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.

This device or VLAN’s STP priority. The value is shown in hexadecimal format.

Note : If you configure this value, specify it in decimal format. See

“Changing STP Bridge Parameters” on page 7-5.

The number of seconds this device or VLAN waits for a configuration

BPDU from the root bridge before deciding the root has become unavailable and performing a reconvergence.

The interval between each configuration BPDU sent by the root bridge.

The minimum number of seconds that must elapse between transmissions of consecutive Configuration BPDUs on a port.

The number of seconds this device or VLAN waits following a topology change and consequent reconvergence.

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 STP address of this device or VLAN.

Note : If this address is the same as the Root ID, then this device or

VLAN is the root bridge for its spanning tree.

Port STP Parameters

Port Num

Priority Hex

Path Cost

The port number.

The port’s STP priority, in hexadecimal format.

Note : If you configure this value, specify it in decimal format. See

“Changing STP Port Parameters” on page 7-6.

The port’s STP path cost.

December 2005 © Foundry Networks, Inc.

7 - 9

Foundry Configuration Guide for the FESX, FSX, and FWSX

This Field...

State

Fwd Trans

Design Cost

Designated Root

Designated Bridge

Table 7.5: CLI Display of STP Information (Continued)

Displays...

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 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 number of times STP has changed the state of this port between

BLOCKING and FORWARDING.

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 designated bridge to which this port is connected. The designated bridge is the device that connects the network segment on the port to the root bridge.

Displaying CPU Utilization Statistics

You can display CPU utilization statistics for STP and the IP protocols.

7 - 10 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

To display CPU utilization statistics for STP for the previous one-second, one-minute, five-minute, and fifteenminute intervals, enter the following command at any level of the CLI:

FastIron SuperX Router# show process cpu

Process Name 5Sec(%) 1Min(%) 5Min(%) 15Min(%) Runtime(ms)

ARP

BGP

0.01

0.04

0.03

0.06

0.09

0.08

0.22

0.14

9

13

GVRP

ICMP

IP

OSPF

RIP

STP

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.03

0.00

0.00

0.00

0.00

0.00

0.04

0.00

0.00

0.00

0.00

0.00

0.07

0

0

0

0

0

4

VRRP 0.00

0.00

0.00

0.00

0

If the software has been running less than 15 minutes (the maximum interval for utilization statistics), the command indicates how long the software has been running. Here is an example:

FastIron SuperX Router# show process cpu

The system has only been up for 6 seconds.

Process Name 5Sec(%) 1Min(%) 5Min(%) 15Min(%) Runtime(ms)

ARP 0.01

0.00

0.00

0.00

0

BGP

GVRP

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0

0

ICMP

IP

OSPF

RIP

STP

VRRP

0.01

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

1

0

0

0

0

0

To display utilization statistics for a specific number of seconds, enter a command such as the following:

FastIron SuperX Router# show process cpu 2

Statistics for last 1 sec and 80 ms

Process Name Sec(%) Time(ms)

ARP 0.00

0

BGP

GVRP

ICMP

IP

0.00

0.00

0.01

0.00

0

0

1

0

OSPF

RIP

STP

VRRP

0.00

0.00

0.01

0.00

0

0

0

0

When you specify how many seconds’ worth of statistics you want to display, the software selects the sample that most closely matches the number of seconds you specified. In this example, statistics are requested for the previous two seconds. The closest sample available is actually for the previous 1 second plus 80 milliseconds.

Syntax: show process cpu [<num>]

The <num> parameter specifies the number of seconds and can be from 1 – 900. If you use this parameter, the command lists the usage statistics only for the specified number of seconds. If you do not use this parameter, the command lists the usage statistics for the previous one-second, one-minute, five-minute, and fifteen-minute intervals.

December 2005 © Foundry Networks, Inc.

7 - 11

Foundry Configuration Guide for the FESX, FSX, and FWSX

Displaying the STP State of a Port-Based VLAN

When you display information for a port-based VLAN, that information includes the STP state of the VLAN.

To display information for a port-based VLAN, enter a command such as the following at any level of the CLI. The

STP state is shown in bold type in this example.

FastIron SuperX Router(config)# show vlans

Total PORT-VLAN entries: 2

Maximum PORT-VLAN entries: 16 legend: [S=Slot]

PORT-VLAN 1, Name DEFAULT-VLAN, Priority level0, Spanning tree On

Untagged Ports: (S3) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Untagged Ports: (S3) 17 18 19 20 21 22 23 24

Untagged Ports: (S4) 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Untagged Ports: (S4) 18 19 20 21 22 23 24

Tagged Ports: None

Uplink Ports: None

PORT-VLAN 2, Name greenwell, Priority level0, Spanning tree Off

Untagged Ports: (S1) 1 2 3 4 5 6 7 8

Untagged Ports: (S4) 1

Tagged Ports: None

Uplink Ports: None

Syntax: show vlans [<vlan-id> | ethernet [<slotnum>/]<portnum>

The <vlan-id> parameter specifies a VLAN for which you want to display the configuration information.

The <portnum> parameter specifies a port. If you use this parameter, the command lists all the VLAN memberships for the port. If you use this command on a chassis device, specify the slot number as well as the port number (<slotnum>/]<portnum>).

Displaying Detailed STP Information for Each Interface

To display the detailed STP information, enter the following command at any level of the CLI:

FastIron SuperX Router# show span detail

======================================================================

VLAN 1 - MULTIPLE SPANNING TREE (MSTP) ACTIVE

======================================================================

Bridge identifier - 0x800000e0804d4a00

Active global timers - Hello: 0

Port 1/1 is FORWARDING

Port - Path cost: 19, Priority: 128, Root: 0x800000e052a9bb00

Designated - Bridge: 0x800000e052a9bb00, Interface: 1, Path cost: 0

Active Timers - None

BPDUs - Sent: 11, Received: 0

Port 1/2 is DISABLED

Port 1/3 is DISABLED

Port 1/4 is DISABLED

<lines for remaining ports excluded for brevity>

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.

7 - 12 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Syntax: show span detail [vlan <vlan-id> [ethernet [<slotnum>/]<portnum> | <num>]

The vlan <vlan-id> parameter specifies a VLAN.

The <portnum> parameter specifies an individual port within the VLAN (if specified). If you use the command on a chassis device, specify the slot number as well as the port number (<slotnum>/<portnum>).

The <num> parameter specifies the number of VLANs you want the CLI to skip before displaying detailed STP information. For example, if the device 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.

The show span detail command shows the following information.

Bridge identifier

Active global timers

Table 7.6: CLI Display of Detailed STP Information for Ports

This Field...

Active Spanning Tree protocol

Displays...

The VLAN that contains the listed ports and the active Spanning Tree protocol.

The STP type can be one of the following:

• MULTIPLE SPANNNG TREE (MSTP)

• GLOBAL 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 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.

December 2005 © Foundry Networks, Inc.

7 - 13

Foundry Configuration Guide for the FESX, FSX, and FWSX

Port Path cost

Port Priority

Table 7.6: CLI Display of Detailed STP Information for Ports (Continued)

This Field...

Port number and STP state

Root

Designated Bridge

Designated Port

Designated Path Cost

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.

The port’s STP path cost.

This port’s STP priority. The value is shown as a hexadecimal number.

The ID assigned by STP to the root bridge for this spanning tree.

The MAC address of the designated bridge to which this port is connected. The designated bridge is the device that connects the network segment on the port to the root bridge.

The port number sent from the designated bridge.

The cost to the root bridge as advertised by the designated bridge that is connected to this port. If the bridge is the root bridge itself, then the cost is 0. The identity of the designated bridge is shown in the

Designated Bridge field.

7 - 14 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

This Field...

Active Timers

Table 7.6: CLI Display of Detailed STP Information for Ports (Continued)

BPDUs Sent and Received

Displays...

The current values for the following timers, if active:

• Message age – The number of seconds this port has been waiting for a hello message from the root bridge.

• Forward delay – The number of seconds that have passed since the last topology change and consequent reconvergence.

• Hold time – The number of seconds that have elapsed since transmission of the last Configuration BPDU.

The number of BPDUs sent and received on this port since the software was reloaded.

Displaying Detailed STP Information for a Single Port in a Specific VLAN

Enter a command such as the following to display STP information for an individual port in a specific VLAN.

FastIron SuperX Router(config)# show span detail vlan 1 ethernet 7/1

Port 7/1 is FORWARDING

Port - Path cost: 19, Priority: 128, Root: 0x800000e052a9bb00

Designated - Bridge: 0x800000e052a9bb00, Interface: 7, Path cost: 0

Active Timers - None

BPDUs - Sent: 29, Received: 0

Syntax: show span detail [vlan <vlan-id> [ethernet [<slotnum>/]<portnum> | <num>]

Displaying STP State Information for an Individual Interface

To display STP state information for an individual port, you can use the methods in “Displaying STP Information for an Entire Device” on page 7-8 or “Displaying Detailed STP Information for Each Interface”. You also can display

STP state information for a specific port using the following method.

To display information for a specific port, enter a command such as the following at any level of the CLI:

FastIron SuperX Router(config)# show interface ethernet 3/11

FastEthernet3/11 is up, line protocol is up

Hardware is FastEthernet, address is 00e0.52a9.bb49 (bia 00e0.52a9.bb49)

Configured speed auto, actual 100Mbit, configured duplex fdx, actual fdx

Member of L2 VLAN ID 1, port is untagged, port state is FORWARDING

STP configured to ON , priority is level0, flow control enabled

mirror disabled, monitor disabled

Not member of any active trunks

Not member of any configured trunks

No port name

MTU 1518 bytes, encapsulation ethernet

5 minute input rate: 352 bits/sec, 0 packets/sec, 0.00% utilization

5 minute output rate: 0 bits/sec, 0 packets/sec, 0.00% utilization

1238 packets input, 79232 bytes, 0 no buffer

Received 686 broadcasts, 0 runts, 0 giants

0 input errors, 0 CRC, 0 frame, 0 ignored

529 multicast

918 packets output, 63766 bytes, 0 underruns

0 output errors, 0 collisions

December 2005 © Foundry Networks, Inc.

7 - 15

Foundry Configuration Guide for the FESX, FSX, and FWSX

The STP information is shown in bold type in this example.

Syntax: show interfaces [ethernet [<slotnum>/]<portnum>] | [loopback <num>] | [slot <slot-num>] | [ve <num>] |

[brief]

You also can display the STP states of all ports by entering a command such as the following, which uses the brief parameter:

FastIron SuperX Router(config)# show interface brief

Port Link State Dupl Speed Trunk Tag Priori MAC Name

1/1 Down None 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

1/5 Down None None None None No level0 00e0.52a9.bb04

1/6 Down None None None None No level0 00e0.52a9.bb05

1/7 Down None None None None No level0 00e0.52a9.bb06

1/8 Down None None None None No level0 00e0.52a9.bb07

.

. some rows omitted for brevity

.

3/10 Down None None None None No level0 00e0.52a9.bb4a

3/11 Up Forward Full 100M None No level0 00e0.52a9.bb49

In the example above, only one port, 3/11, is forwarding traffic toward the root bridge.

Configuring IronSpan Features

IronSpan features extend the operation of standard STP, enabling you to fine tune standard STP and avoid some of its limitations.

This section describes how to configure IronSpan parameters on Foundry Layer 3 Switches using the CLI.

Fast Port Span

When STP is running on a device, message forwarding is delayed during the spanning tree recalculation period following a topology change. The STP forward delay parameter specifies the period of time a bridge waits before forwarding data packets. The forward delay controls the listening and learning periods of STP reconvergence.

You can configure the forward delay to a value from 4 – 30 seconds. The default is 15 seconds. Thus, using the standard forward delay, convergence requires 30 seconds (15 seconds for listening and an additional 15 seconds for learning) when the default value is used.

This slow convergence is undesirable and unnecessary in some circumstances. The Fast Port Span feature allows certain ports to enter the forwarding state in four seconds. Specifically, Fast Port Span allows faster convergence on ports that are attached to end stations and thus do not present the potential to cause Layer 2 forwarding loops. Because the end stations cannot cause forwarding loops, they can safely go through the STP state changes (blocking to listening to learning to forwarding) more quickly than is allowed by the standard STP convergence time. Fast Port Span performs the convergence on these ports in four seconds (two seconds for listening and two seconds for learning).

In addition, Fast Port Span enhances overall network performance in the following ways:

• Fast Port Span reduces the number of STP topology change notifications on the network. When an end station attached to a Fast Span port comes up or down, the Foundry device does not generate a topology change notification for the port. In this situation, the notification is unnecessary since a change in the state of the host does not affect the network’s topology.

7 - 16 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

• Fast Port Span eliminates unnecessary MAC cache aging that can be caused by topology change notifications. Bridging devices age out the learned MAC addresses in their MAC caches if the addresses are unrefreshed for a given period of time, sometimes called the MAC aging interval. When STP sends a topology change notification, devices that receive the notification use the value of the STP forward delay to quickly age out their MAC caches. For example, if a device’s normal MAC aging interval is 5 minutes, the aging interval changes temporarily to the value of the forward delay (for example, 15 seconds) in response to an STP topology change.

In normal STP, the accelerated cache aging occurs even when a single host goes up or down. Because Fast

Port Span does not send a topology change notification when a host on a Fast Port Span port goes up or down, the unnecessary cache aging that can occur in these circumstances under normal STP is eliminated.

Fast Port Span is a system-wide parameter and is enabled by default. Thus, when you boot a device, all the ports that are attached only to end stations run Fast Port Span. For ports that are not eligible for Fast Port Span, such as ports connected to other networking devices, the device automatically uses the normal STP settings. If a port matches any of the following criteria, the port is ineligible for Fast Port Span and uses normal STP instead:

• The port is 802.1Q tagged

• The port is a member of a trunk group

• The port has learned more than one active MAC address

• An STP Configuration BPDU has been received on the port, thus indicating the presence of another bridge on the port.

You also can explicitly exclude individual ports from Fast Port Span if needed. For example, if the only uplink ports for a wiring closet switch are Gigabit ports, you can exclude the ports from Fast Port Span.

Disabling and Re-enabling Fast Port Span

Fast Port Span is a system-wide parameter and is enabled by default. Thus all ports that are eligible for Fast Port

Span use it.

To disable or re-enable Fast Port Span, enter the following commands:

FESX424 Router(config)# no fast port-span

FESX424 Router(config)# write memory

Syntax: [no] fast port-span

NOTE: The fast port-span command has additional parameters that let you exclude specific ports. These parameters are shown in the following section.

To re-enable Fast Port Span, enter the following commands:

FESX424 Router(config)# fast port-span

FESX424 Router(config)# write memory

Excluding Specific Ports from Fast Port Span

To exclude a port from Fast Port Span while leaving Fast Port Span enabled globally, enter commands such as the following:

FESX424 Router(config)# fast port-span exclude ethernet 1

FESX424 Router(config)# write memory

To exclude a set of ports from Fast Port Span, enter commands such as the following:

FESX424 Router(config)# fast port-span exclude ethernet 1 ethernet 2 ethernet 3

FESX424 Router(config)# write memory

To exclude a contiguous (unbroken) range of ports from Fast Span, enter commands such as the following:

FESX424 Router(config)# fast port-span exclude ethernet 1 to 24

FESX424 Router(config)# write memory

December 2005 © Foundry Networks, Inc.

7 - 17

Foundry Configuration Guide for the FESX, FSX, and FWSX

Syntax: [no] fast port-span [exclude ethernet [<slotnum>/]<portnum> [ethernet [<slotnum>/]<portnum> | to

[<slotnum>/]<portnum>]]

To re-enable Fast Port Span on a port, enter a command such as the following:

FESX424 Router(config)# no fast port-span exclude ethernet 1

FESX424 Router(config)# write memory

This command re-enables Fast Port Span on port 1 only and does not re-enable Fast Port Span on other excluded ports. You also can re-enable Fast Port Span on a list or range of ports using the syntax shown above this example.

To re-enable Fast Port Span on all excluded ports, disable and then re-enable Fast Port Span by entering the following commands:

FESX424 Router(config)# no fast port-span

FESX424 Router(config)# fast port-span

FESX424 Router(config)# write memory

Disabling and then re-enabling Fast Port Span clears the exclude settings and thus enables Fast Port Span on all eligible ports. To make sure Fast Port Span remains enabled on the ports following a system reset, save the configuration changes to the startup-config file after you re-enable Fast Port Span. Otherwise, when the system resets, those ports will again be excluded from Fast Port Span.

802.1W Rapid Spanning Tree (RSTP)

Foundry’s earlier implementation of Rapid Spanning Tree Protocol (RSTP), which was 802.1W Draft 3, provided only a subset of the IEEE 802.1W standard; whereas the 802.1W RSTP feature provides the full standard. The implementation of the 802.1W Draft 3 is referred to as RSTP Draft 3.

RSTP Draft3 will continue to be supported on Foundry devices for backward compatibility. However, customers who are currently using RSTP Draft 3 should migrate to 802.1W.

The 802.1W feature provides rapid traffic reconvergence for point-to-point links within a few milliseconds (0 – 500 milliseconds), following the failure of a bridge or bridge port. This reconvergence occurs more rapidly than the reconvergence provided by the 802.1D (Spanning Tree Protocol (STP)) or by RSTP Draft 3.

NOTE: This rapid convergence will not occur on ports connected to shared media devices, such as hubs. To take advantage of the rapid convergence provided by 802.1W, make sure to explicitly configure all point-to-point links in a topology.

The convergence provided by the standard 802.1W protocol occurs more rapidly than the convergence provided by previous spanning tree protocols because:

• Classic or legacy 802.1D STP protocol requires a newly selected Root port to go through listening and learning stages before traffic convergence can be achieved. The 802.1D traffic convergence time is calculated using the following formula:

2 x FORWARD_DELAY + BRIDGE_MAX_AGE.

If default values are used in the parameter configuration, convergence can take up to 50 seconds. (In this document STP will be referred to as 802.1D.)

• RSTP Draft 3 works only on bridges that have Alternate ports, which are the precalculated “next best root port”. (Alternate ports provide back up paths to the root bridge.) Although convergence occurs from 0 – 500 milliseconds in RSTP Draft 3, the spanning tree topology reverts to the 802.1D convergence if an Alternate port is not found.

• Convergence in 802.1w bridge 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.

7 - 18 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Bridges and Bridge Port Roles

A bridge in an 802.1W 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 Rapid Spanning Tree Bridge Packet Data Unit (RST BPDU):

• Root bridge ID

• Path cost value

• Transmitting bridge ID

• Designated port ID

The 802.1W 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.

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 802.1W port is referred to as an RST BPDU, while it is operating in 802.1W 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 802.1W-enabled bridge ports assume a Designated role. Once start-up is complete,

802.1W 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 802.1W is disabled on the port, that port is given the role of Disabled port . Disabled ports have no role in the topology. However, if 802.1W 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 7.1) explains role assignments in a simple RSTP topology.

December 2005 © Foundry Networks, Inc.

7 - 19

Foundry Configuration Guide for the FESX, FSX, and FWSX

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.

The topology in Figure 7.1 contains four bridges. Switch 1 is the root bridge since it has the lowest bridge priority.

Switch 2 through Switch 4 are non-root bridges.

Figure 7.1

Simple 802.1W Topology

Switch 1

Bridge priority = 100

Port2

Port3

Port7

Port2 Switch 2

Bridge priority = 200

Port8

Port3 Port4

Port2 Port3

Switch 3

Bridge priority = 300

Port4

Port3

Port4 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, Port8 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.

7 - 20 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Edge Ports and Edge Port Roles

Foundry’s implementation of 802.1W allows ports that are configured as Edge ports to be present in an 802.1W topology. (Figure 7.2). Edge ports are ports of a bridge that connect to workstations or computers. Edge ports do not register any incoming BPDU activities.

Edge ports assume Designated port roles. Port flapping does not cause any topology change events on Edge ports since 802.1W does not consider Edge ports in the spanning tree calculations.

Figure 7.2

Topology with Edge Ports

Switch 1

Bridge priority = 600

Port2

Port3

Port2 Switch 2

Bridge priority = 1000

Port3

Port5

Edge Port

Port2

Switch 3

Bridge priority = 2000

Port5

Edge Port

Port3

However, if any incoming RST BPDU is received from a previously configured Edge port, 802.1W 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 802.1W protocol can auto-detect an Edge port and a non-edge port. An administrator can also configure a port to be an Edge port using the CLI. 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 802.1W features, ports on an 802.1W topology should be explicitly configured as pointto-point links using the CLI. 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.

The topology in Figure 7.3 is an example of shared media that should not be configured as point-to-point links. In

Figure 7.3, a port on a bridge communicates or is connected to at least two ports.

December 2005 © Foundry Networks, Inc.

7 - 21

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 7.3

Example of Shared Media

Bridge Port States

Ports roles can have one of the following states:

• Forwarding – 802.1W is allowing the port to send and receive all packets.

• Discarding – 802.1W 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 – 802.1W is allowing MAC 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 802.1W. This can occur when the port is disconnected or 802.1W 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, 802.1W 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 using the CLI, it goes into a forwarding state instantly (in less than

100 msec):

When the link to a port comes up and 802.1W detects that the port is an Edge port, that port instantly goes into a forwarding state.

If 802.1W detects that port as a non-edge port, the port state is changed as determined by the result of processing the received RST BPDU. The port state change occurs 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.

7 - 22 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

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 802.1W 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.

802.1W 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 on the other bridge to which the port is connected. For example, in Figure 7.4, Port1 of Switch 200 is the peer 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.

A port operating in 802.1W mode may enter a learning state to allow MAC 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 802.1W mode and if the port meets the conditions for rapid transition.

December 2005 © Foundry Networks, Inc.

7 - 23

Foundry Configuration Guide for the FESX, FSX, and FWSX

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, 802.1W 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 forwarding state (Figure 7.4). The Designated port continues to send this flag in its RST BPDU until it is placed in a forwarding state (Figure 7.7) or is forced to operate in 802.1D mode. (See “Compatibility of

802.1W with 802.1D” on page 43.)

• Proposed – When a port receives an RST BPDU with a proposal flag from the Designated port on its point-topoint link, it asserts the Proposed signal and one of the following occurs (Figure 7.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 7-19.)

• 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 7.4, Port3/Switch 200 is elected as the Root port

Figure 7.4

Proposing and Proposed Stage

Switch 100

Root Bridge

RST BPDU sent with a

Proposal flag

Designated port

Proposing

Port1

Root port

Proposed

Switch 200

Port2 Port3

Port2

Switch 300

Port3

Switch 400

7 - 24 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

• Sync – Once the Root port is elected, it sets a sync signal on all the ports on the bridge. The signal tells the ports to synchronize their roles and states (Figure 7.5). Ports that are non-edge ports with a role of

Designated port change into a discarding state. These ports have to negotiate with their peer ports to establish their new roles and states.

Figure 7.5

Sync Stage

Port2

Sync

Discarding

Switch 100

Root Bridge

Port1

Designated port

Port1

Root port

Sync

BigIron

Switch 200

Port3

Sync

Discarding

Port2

Switch 300

Indicates a signal

Port3

Switch 400

December 2005 © Foundry Networks, Inc.

7 - 25

Foundry Configuration Guide for the FESX, FSX, and FWSX

• 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 ports. Once all bridge ports asserts a synced signal, the Root port asserts its own synced signal (Figure 7.6).

Figure 7.6

Synced Stage

Switch 100

Root Bridge

Port1

Designated port

Port2

Synced

Discarding

Port1

Root port

Synced

BigIron

Switch 200

Port3

Synced

Discarding

Port2

Switch 300

Indicates a signal

Port3

Switch 400

7 - 26 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

• 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 7.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

Switch 300

Port3

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.

December 2005 © Foundry Networks, Inc.

7 - 27

Foundry Configuration Guide for the FESX, FSX, and FWSX

Handshake When a Root Port Has Been Elected

If a non-root bridge already has a Root port, 802.1W uses a different type of handshake. For example, in Figure

7.8, a new root bridge is added to the topology.

Figure 7.8

Addition of a New Root Bridge

Port2

Designated port

Switch 100

Switch 60

Port2

Port1 Port4

Designated port

Port1

Root port

Port2

Switch 200

Port4

Port3

Port2

Switch 300

Port3

Switch 400

7 - 28 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

The handshake that occurs between Switch 60 and Switch 100 follows the one described in the previous section

(“Handshake When No Root Port is Elected” on page 7-24). The former root bridge becomes a non-root bridge and establishes a Root port (Figure 7.9).

However, since Switch 200 already had a Root port in a forwarding state, 802.1W 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 7.9). 802.1W 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 7.9

New Root Bridge Sending a Proposal Flag

Switch 100

Port1

Port2

Root port

Handshake

Completed

Port2

Designated port Switch 60

Port4

Designated port

Proposing

Proposing

Port1

Root port

Forwarding

RST BPDU sent with a Proposing flag

Port2

Switch 200

Port3

Port4

Designated port

Proposed

Port2

Switch 300

Port3

Switch 400

December 2005 © Foundry Networks, Inc.

7 - 29

Foundry Configuration Guide for the FESX, FSX, and FWSX

• 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 7.10).

Figure 7.10

Sync and Reroot

Port2

Designated port

Switch 100

Switch 60

Port2

Root port

Port1

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

Switch 300

Port3

Switch 400

Indicates a signal

7 - 30 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

• 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 7.11).

Figure 7.11

Sync and Rerooted

Port2

Designated port

Switch 60

Switch 100

Port2

Root port

Port1

Port4

Designated port

Switch 200

Port2

Sync

Rerooted

Proposing

Discarding

Port1

Designated port

Sync

Rerooted

Discarding

BigIron

Port3

Sync

Rerooted

Discarding

Port4

Root port

Sync

Rerooted

Discarding

Port2

Switch 300

Port3

Switch 400

Indicates an 802.1W signal controlled by the current Root port

December 2005 © Foundry Networks, Inc.

7 - 31

Foundry Configuration Guide for the FESX, FSX, and FWSX

• 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 7.11).

The Root port also moves into a forwarding state.

Figure 7.12

Rerooted, Synced, and Agreed

Port2

Designated port

Switch 100

Switch 60

Port2

Root port

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

Switch 300

Port3

Switch 400

Indicates a signal

The old Root port on Switch 200 becomes an Alternate Port (Figure 7.13). Other ports on that bridge are elected to appropriate roles.

The Designated port on Switch 60 goes into a forwarding state once it receives the RST BPDU with the agreed flag.

7 - 32 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Figure 7.13

Handshake Completed After Election of New Root Port

Port2

Designated port

Switch 100

Port2

Root port

Port1

Proposing

Proposing

Port1

Alternate port

Switch 200

Port4

Root port

Port3

Proposing

Switch 60

Port4

Designated port

Port2

Switch 300

Port3

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.

December 2005 © Foundry Networks, Inc.

7 - 33

Foundry Configuration Guide for the FESX, FSX, and FWSX

Convergence in a Simple Topology

The examples in this section illustrate how 802.1W 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.

Convergence at Start Up

In Figure 7.14, two bridges Switch 2 and Switch 3 are powered up. There are point-to-point connections between

Port3/Switch 2 and Port3/Switch 3.

Figure 7.14

Convergence Between Two Bridges

Bridge priority = 1500

Switch 2

Port3

Designated port

Port3

Root port

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 802.1W 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.

7 - 34 © Foundry Networks, Inc.

December 2005

Next, Switch 1 is powered up (Figure 7.15).

Figure 7.15

Simple Layer 2 Topology

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Bridge priority = 1500

Switch 2

Port3

Designated port

Port2

Root port

Port3

Designated port

Port2

Designated port

Switch 1

Port5

Backup port

Bridge priority = 1000

Port4

Designated port

Bridge priority = 2000

Port3

Alternate port

Switch 3

Port4

Root port

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 802.1W 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 802.1W 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 802.1W 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.

December 2005 © Foundry Networks, Inc.

7 - 35

Foundry Configuration Guide for the FESX, FSX, and FWSX

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 7.16.

Figure 7.16

Active Layer 2 Path

Bridge priority = 1500

Switch 2

Port3

Designated port

Port2

Root port

Port3

Designated port

Port2

Designated port

Switch 1

Port4

Designated port

Port5

Backup port

Bridge priority = 1000

Bridge priority = 2000

Port3

Alternate port

Switch 3

Port4

Root port

Indicates the active Layer 2 path

7 - 36 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Convergence After a Link Failure

What happens if a link in the 802.1W 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 7.17).

Figure 7.17

Link Failure in the Topology

Bridge priority = 1500

Switch 2

Port3

Port2

Port3

Port2

Switch 1

Port5

Bridge priority = 1000

Port4

Bridge priority = 2000

Port3

Switch 3

Port4

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, 802.1W 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, 802.1W 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, 802.1W 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.

December 2005 © Foundry Networks, Inc.

7 - 37

Foundry Configuration Guide for the FESX, FSX, and FWSX

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, 802.1W 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 port while it is still in a Designated role, before it can proceed to the forwarding state.

The wait, however, does not cause a denial of service, since the essential connectivity in the topology has already been established.

When fully restored, the topology is the same as that shown on Figure 7.15.

Convergence in a Complex 802.1W Topology

The following is an example of a complex 802.1W topology.

Figure 7.18

Complex 802.1W Topology

Bridge priority = 200

Bridge priority = 1000

Port2

Port7

Port2

Switch 2

Port8

Port5

Port3 Port4

Port2

Bridge priority = 60

Switch 5

Port3

Port2

Switch 3

Port3

Port4

Port3 Port4

Port5

Port3

Port4

Switch 4

Port5

Switch 6

Bridge priority = 300

Bridge priority = 400

Bridge priority = 900

In Figure 7.18, Switch 5 is selected as the root bridge since it is the bridge with the highest priority. Lines in the figure show the point-to-point connection to the bridges in the topology.

Switch 5 sends an RST BPDU that contains a proposal flag to Port5/Switch 2. When handshakes are completed in

Switch 5, Port5/Switch 2 is selected as the Root port on Switch 2. All other ports on Switch 2 are given Designated port role with discarding states.

Port5/Switch 2 then sends an RST BPDU with an agreed flag to Switch 5 to confirm that it is the new Root port and the port enters a forwarding state. Port7 and Port8 are informed of the identity of the new Root port. 802.1W algorithm selects Port7 as the Designated port while Port8 becomes the Backup port.

7 - 38 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Port3/Switch 5 sends an RST BPDU to Port3/Switch 6 with a proposal flag. When Port3/Switch 5 receives the

RST BPDU, handshake mechanisms select Port3 as the Root port of Switch 6. All other ports are given a

Designated port role with discarding states. Port3/Switch 6 then sends an RST BPDU with an agreed flag to Port3/

Switch 5 to confirm that it is the Root port. The Root port then goes into a forwarding state.

Now, Port4/Switch 6 receives RST BPDUs that are superior to what it can transmit; therefore, it is given the

Alternate port role. The port remains in discarding state.

Port5/Switch 6 receives RST BPDUs that are inferior to what it can transmit. The port is then given a Designated port role.

Next Switch 2 sends RST BPDUs with a proposal flag to Port3/Switch 4. Port3 becomes the Root port for the bridge; all other ports are given a Designated port role with discarding states. Port3/Switch 4 sends an RST BPDU with an agreed flag to Switch 2 to confirm that it is the new Root port. The port then goes into a forwarding state.

Now Port4/Switch 4 receives an RST BPDU that is superior to what it can transmit. The port is then given an

Alternate port role, and remains in discarding state.

Likewise, Port5/Switch 4 receives an RST BPDU that is superior to what it can transmit. The port is also given an

Alternate port role, and remains in discarding state.

Port2/Switch 2 transmits an RST BPDU with a proposal flag to Port2/Switch 1. Port2/Switch 1 becomes the Root port. All other ports on Switch 1 are given Designated port roles with discarding states.

Port2/Switch 1 sends an RST BPDU with an agreed flag to Port2/Switch 2 and Port2/Switch 1 goes into a forwarding state.

Port3/Switch 1 receives an RST BPDUs that is inferior to what it can transmit; therefore, the port retains its

Designated port role and goes into forwarding state only after the forward delay timer expires twice on that port while it is still in a Designated role.

Port3/Switch 2 sends an RST BPDU to Port3/Switch 3 that contains a proposal flag. Port3/Switch 3 becomes the

Root port, while all other ports on Switch 3 are given Designated port roles and go into discarding states. Port3/

Switch 3 sends an RST BPDU with an agreed flag to Port3/Switch 2 and Port3/Switch 3 goes into a forwarding state.

Now, Port2/Switch 3 receives an RST BPDUs that is superior to what it can transmit so that port is given an

Alternate port state.

Port4/Switch 3 receives an RST BPDU that is inferior to what it can transmit; therefore, the port retains its

Designated port role.

Ports on all the bridges in the topology with Designated port roles that received RST BPDUs with agreed flags go into forwarding states instantly. However, Designated ports that did not receive RST BPDUs with agreed flags must wait until the forward delay timer expires twice on those port. Only then will these port move into forwarding states.

The entire 802.1W topology converges in less than 300 msec and the essential connectivity is established between the designated ports and their connected root ports.

December 2005 © Foundry Networks, Inc.

7 - 39

Foundry Configuration Guide for the FESX, FSX, and FWSX

After convergence is complete, Figure 7.19 shows the active Layer 2 path of the topology in Figure 7.18.

Figure 7.19

Active Layer 2 Path in Complex Topology

Bridge priority = 200

Bridge priority = 1000

Switch 1

Port2

Port7

Port2

Switch 2

Port8

Port5

Port3 Port4

Port2

Bridge priority = 60

Switch 5

Port2

Switch 3

Port3

Port4

Bridge priority = 300

Port4

Port3

Switch 4

Bridge priority = 400

Port5

Port4

Port5

Port3

Switch 6

Bridge priority = 900

Indicates the active Layer 2 path

Propagation of Topology Change

The Topology Change state machine generates and propagates the topology change notification messages on each port. When a Root port or a Designated port goes into a forwarding state, the Topology Change state machine on those ports send a topology change notice (TCN) to all the bridges in the topology to propagate the topology change.

NOTE: Edge ports, Alternate ports, or Backup ports do not need to propagate a topology change.

The TCN is sent in the RST BPDU that a port sends. Ports on other bridges in the topology then acknowledge the topology change once they receive the RST BPDU, and send the TCN to other bridges until all the bridges are informed of the topology change.

7 - 40 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

For example, Port3/Switch 2 in Figure 7.20, fails. Port4/Switch 3 becomes the new Root port. Port4/Switch 3 sends an RST BPDU with a TCN to Port4/Switch 4. To propagate the topology change, Port4/Switch 4 then starts a TCN timer on itself, on the bridge’s Root port, and on other ports on that bridge with a Designated role. Then

Port3/Switch 4 sends RST BPDU with the TCN to Port4/Switch 2. (Note the new active Layer 2 path in Figure

7.20.)

Figure 7.20

Beginning of Topology Change Notice

Bridge priority = 200

Bridge priority = 1000

Switch 1

Port3

Port2

Port7

Port2

Switch 2

Port3

Port4

Port8

Port5 Port2

Bridge priority = 60

Switch 5

Port3

Port2

Switch 3

Port3

Port4

Bridge priority = 300

Port4

Port3

Switch 4

Switch 4

Bridge priority = 400

Port5

Indicates the active Layer 2 path

Indicates direction of TCN

Port4

Port5

Port3

Switch 6

Switch 6

Bridge priority = 900

December 2005 © Foundry Networks, Inc.

7 - 41

Foundry Configuration Guide for the FESX, FSX, and FWSX

Switch 2 then starts the TCN timer on the Designated ports and sends RST BPDUs that contain the TCN as follows (Figure 7.21):

• Port5/Switch 2 sends the TCN to Port2/Switch 5

• Port4/Switch 2 sends the TCN to Port4/Switch 6

• Port2/Switch 2 sends the TCN to Port2/Switch 1

Figure 7.21

Sending TCN to Bridges Connected to Switch 2

Bridge priority = 200

Bridge priority = 1000

Switch 1

Port3

Port2

Port7

Port2

Port3

Switch 2

Port8

Port5 Port2

Bridge priority = 60

Switch 5

Port3

Port2

Switch 3

Port3

Port4

Bridge priority = 300

Port4

Port3

Switch 4

Bridge priority = 400

Port5

Indicates the active Layer 2 path

Indicates direction of TCN

Port4

Port5

Port3

Switch 6

Bridge priority = 900

7 - 42 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Then Switch 1, Switch 5, and Switch 6 send RST BPDUs that contain the TCN to Switch 3 and Switch 4 to complete the TCN propagation (Figure 7.22).

Figure 7.22

Completing the TCN Propagation

Switch 1

Bridge priority = 1000

Port2

Port3

Port7 Port8

Port2 Switch 2

Bridge priority = 200

Port5

Port3

Port4

Port2

Switch 5

Bridge priority = 60

Port3

Port2

Port3

Switch 3

Bridge priority = 300

Port4

Port3

Port4 Switch 4

Bridge priority = 400

Port5

Port4

Port3

Port5

Switch 6

Bridge priority = 900

Indicates the active Layer 2 path

Indicates direction of TCN

Compatibility of 802.1W with 802.1D

802.1W-enabled bridges are backward compatible with IEEE 802.1D bridges. This compatibility is managed on a per-port basis by the Port Migration state machine. However, intermixing the two types of bridges in the network topology is not advisable if you want to take advantage of the rapid convergence feature.

Compatibility with 802.1D means that an 802.1W-enabled port can send BPDUs in the STP or 802.1D format when one of the following events occur:

• The port receives a legacy BPDU. A legacy BPDU is an STP BPDU or a BPDU in an 802.1D format. The port that receives the legacy BPDU automatically configures itself to behave like a legacy port. It sends and receives legacy BPDUs only.

• The entire bridge is configured to operate in an 802.1D mode when an administrator sets the bridge parameter to zero at the CLI, forcing all ports on the bridge to send legacy BPDUs only.

Once a port operates in the 802.1D mode, 802.1D convergence times are used and rapid convergence is not realized.

December 2005 © Foundry Networks, Inc.

7 - 43

Foundry Configuration Guide for the FESX, FSX, and FWSX

For example, in Figure 7.23, Switch 10 and Switch 30 receive legacy BPDUs from Switch 20. Ports on Switch 10 and Switch 30 begin sending BPDUs in STP format to allow them to operate transparently with Switch 20.

Figure 7.23

802.1W Bridges with an 802.1D Bridge

Switch 10

802.1W

Switch 20

802.1D

Switch 30

802.1W

Once Switch 20 is removed from the LAN, Switch 10 and Switch 30 receive and transmit BPDUs in the STP format to and from each other. This state will continue until the administrator enables the force-migration-check command to force the bridge to send RSTP BPDU during a migrate time period. If ports on the bridges continue to hear only STP BPDUs after this migrate time period, those ports will return to sending STP BPDUs. However, when the ports receive RST BPDUs during the migrate time period, the ports begin sending RST BPDUs. The migrate time period is non-configurable. It has a value of three seconds.

NOTE: The IEEE standards state that 802.1W bridges need to interoperate with 802.1D bridges. IEEE standards set the path cost of 802.1W bridges to be between 1 and 200,000,000; whereas path cost of 802.1D bridges are set between 1 and 65,535. In order for the two bridge types to be able to interoperate in the same topology, the administrator needs to configure the bridge path cost appropriately. Path costs for either 802.1W bridges or 802.1D bridges need to be changed; in most cases, path costs for 802.1W bridges need to be changed.

Configuring 802.1W Parameters on a Foundry Device

The remaining 802.1W sections explain how to configure the 802.1W protocol in a Foundry device.

Foundry devices are shipped from the factory with 802.1W disabled. Use the following methods to enable or disable 802.1W. You can enable or disable 802.1W at the following levels:

• Port-based VLAN – Affects all ports within the specified port-based VLAN. When you enable or disable

802.1W within a port-based VLAN, the setting overrides the global setting. Thus, you can enable 802.1W for the ports within a port-based VLAN even when 802.1W is globally disabled, or disable the ports within a portbased VLAN when 802.1W is globally enabled.

• Individual port – Affects only the individual port. However, if you change the 802.1W state of the primary port in a trunk group, the change affects all ports in the trunk group.

Enabling or Disabling 802.1W in a Port-Based VLAN

Use the following procedure to disable or enable 802.1W on a device on which you have configured a port-based

VLAN. Changing the 802.1W state in a VLAN affects only that VLAN.

To enable 802.1W for all ports in a port-based VLAN, enter commands such as the following:

FESX424 Router(config)# vlan 10

FESX424 Router(config-vlan-10)# spanning-tree 802-1w

Syntax: [no] spanning-tree 802-1w

Enabling or Disabling 802.1W on a Single Spanning Tree

To enable 802.1W for all ports of a single spanning tree, enter a command such as the following:

FESX424 Router(config-vlan-10)# spanning-tree single 802-1w

Syntax: [no] spanning-tree single 802-1w

7 - 44 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Disabling or Enabling 802.1W on an Individual Port

The spanning-tree 802-1w or spanning-tree single 802-1w command must be used to initially enable 802.1W on ports. Both commands enable 802.1W on all ports that belong to the VLAN or to the single spanning tree.

Once 802.1W is enabled on a port, it can be disabled on individual ports. 802.1W that have been disabled on individual ports can then be enabled as required.

NOTE: If you change the 802.1W state of the primary port in a trunk group, the change affects all ports in that trunk group.

To disable or enable 802.1W on an individual port, enter commands such as the following:

FESX424 Router(config)# interface e 1

FESX424 Router(config-if-e1000-1)# no spanning-tree

Syntax: [no] spanning-tree

Changing 802.1W Bridge Parameters

When you make changes to 802.1W bridge parameters, the changes are applied to individual ports on the bridge.

To change 802.1W bridge parameters, use the following methods.

To designate a priority for a bridge, enter a command such as the following:

FESX424 Router(config)# spanning-tree 802-1w priority 10

The command in this example changes the priority on a device on which you have not configured port-based

VLANs. The change applies to the default VLAN. If you have configured a port-based VLAN on the device, you can configure the parameters only at the configuration level for individual VLANs. Enter commands such as the following:

FESX424 Router(config)# vlan 20

FESX424 Router(config-vlan-20)# spanning-tree 802-1w priority 0

To make this change in the default VLAN, enter the following commands:

FESX424 Router(config)# vlan 1

FESX424 Router(config-vlan-1)# spanning-tree 802-1w priority 0

Syntax: spanning-tree 802-1w [forward-delay <value>] | [hello-time <value>] | [max-age <time>] | [force-version

<value>] | [priority <value>]

The forward-delay <value> parameter specifies how long a port waits before it forwards an RST BPDU after a topology change. This can be a value from 4 – 30 seconds. The default is 15 seconds.

The hello-time <value> parameter specifies the interval between two hello packets. This parameter can have a value from 1 – 10 seconds. The default is 2 seconds; however, set this value to at least 4 seconds to provide enough time for BPDUs to reach the root bridge before the timeout period expires on a non-root bridge port.

The max-age <value> parameter specifies the amount of time the device waits to receive a hello packet before it initiates a topology change. You can specify a value from 6 – 40 seconds. The default is 20 seconds.

The value of max-age must be greater than the value of forward-delay to ensure that the downstream bridges do not age out faster than the upstream bridges (those bridges that are closer to the root bridge).

The force-version <value> parameter forces the bridge to send BPDUs in a specific format. You can specify one of the following values:

• 0 – The STP compatibility mode. Only STP (or legacy) BPDUs will be sent.

• 2 – The default. RST BPDUs will be sent unless a legacy bridge is detected. If a legacy bridge is detected,

STP BPDUs will be sent instead.

The default is 2.

The priority <value> parameter specifies the priority of the bridge. You can enter a value from 0 – 65535. A lower numerical value means a the bridge has a higher priority. Thus, the highest priority is 0. The default is 32768.

December 2005 © Foundry Networks, Inc.

7 - 45

Foundry Configuration Guide for the FESX, FSX, and FWSX

You can specify some or all of these parameters on the same command line. If you specify more than one parameter, you must specify them in the order shown above, from left to right.

Changing Port Parameters

The 802.1W port commands can be enabled on individual ports or on multiple ports, such as all ports that belong to a VLAN.

The 802.1W port parameters are preconfigured with default values. If the default parameters meet your network requirements, no other action is required.

You can change the following 802.1W port parameters using the following method.

FESX424 Router(config)# vlan 10

FESX424 Router(config-vlan-10)# spanning-tree 802-1w ethernet 5 path-cost 15 priority 64

Syntax: spanning-tree 802-1w ethernet [<slotnum>/]<portnum> path-cost <value> | priority <value> | [adminedge-port] | [admin-pt2pt-mac] | [force-migration-check]

The <portnum> parameter specifies the interface used. If you are configuring a chassis device, specify the slot number as well as the port number (<slotnum>/<portnum>).

The path-cost <value> parameter specifies the cost of the port’s path to the root bridge. 802.1W prefers the path with the lowest cost. You can specify a value from 1 – 20,000,000. Table 7.7 shows the recommended path cost values from the IEEE standards.

Table 7.7: Recommended Path Cost Values of 802.1W

Link Speed

Less than 100 kilobits per second

1 Megabit per second

10 Megabits per second

100 Megabits per second

1 Gigabit per second

10 Gigabits per second

100 Gigabits per second

1 Terabits per second

10 Terabits per second

Recommended

(Default) 802.1W Path

Cost Values

200,000,000

20,000,000

2,000,000

200,000

20,000

2,000

200

20

2

Recommended 802.1W Path

Cost Range

20,000,000 – 200,000,000

2,000,000 – 200,000,000

200,000 – 200,000,000

20,000 – 200,000,000

2,000 – 200,000,000

200 – 20,000

20 – 2,000

2 – 200

1 – 20

The priority <value> parameter specifies the preference that 802.1W gives to this port relative to other ports for forwarding traffic out of the topology. You can specify a value from 8 – 252, in increments of 4. If you enter a value that is not divisible by four the software rounds to the nearest value that is. The default is 128. A higher numerical value means a lower priority; thus, the highest priority is 8

Set the admin-edge-port to enabled or disabled. If set to enabled, then the port becomes an edge port in the domain.

Set the admin-pt2pt-mac to enabled or disabled. If set to enabled, then a port is connected to another port through a point-to-point link. The point-to-point link increases the speed of convergence. This parameter, however, does not auto-detect whether or not the link is a physical point-to-point link.

7 - 46 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

The force-migration-check parameter forces the specified port to sent one RST BPDU. If only STP BPDUs are received in response to the sent RST BPDU, then the port will go return to sending STP BPDUs.

EXAMPLE:

Suppose you want to enable 802.1W on a system with no active port-based VLANs and change the hello-time from the default value of 2 to 8 seconds. Additionally, suppose you want to change the path and priority costs for port 5 only. To do so, enter the following commands.

FESX424 Router(config)# spanning-tree 802-1w hello-time 8

FESX424 Router(config)# spanning-tree 802-1w ethernet 5 path-cost 15 priority 64

Displaying Information About 802-1W

To display a summary of 802-1W, use the following command:

FastIron SuperX Router(config)# show 802-1w

--- VLAN 1 [ STP Instance owned by VLAN 1 ] ----------------------------

VLAN 1 BPDU cam_index is 2 and the IGC and DMA master Are(HEX) 0 1 2 3

Bridge IEEE 802.1W Parameters:

Bridge Bridge Bridge Bridge Force tx

Identifier MaxAge Hello FwdDly Version Hold hex sec sec sec cnt

800000e080541700 20 2 15 Default 3

RootBridge RootPath DesignatedBri- Root Max Fwd Hel

Identifier Cost dge Identifier Port Age Dly lo hex hex sec sec sec

800000e0804c9c00 200000 800000e0804c9c00 1 20 15 2

Port IEEE 802.1W Parameters:

<--- Config Params -->|<-------------- Current state ----------------->

Port Pri PortPath P2P Edge Role State Designa- Designated

Num Cost Mac Port ted cost bridge

1 128 200000 F F ROOT FORWARDING 0 800000e0804c9c00

2 128 200000 F F DESIGNATED FORWARDING 200000 800000e080541700

3 128 200000 F F DESIGNATED FORWARDING 200000 800000e080541700

4 128 200000 F F BACKUP DISCARDING 200000 800000e080541700

Syntax: show 802-1w [vlan <vlan-id>]

The vlan <vlan-id> parameter displays 802.1W information for the specified port-based VLAN.

The show 802.1w display command shows the information listed in Table 7.8.

This Field...

VLAN ID

Table 7.8: CLI Display of 802.1W Summary

Displays...

The port-based VLAN that owns the STP instance. VLAN 1 is the default VLAN. If you have not configured port-based VLANs on this device, all 802.1W information is for VLAN 1.

December 2005 © Foundry Networks, Inc.

7 - 47

Foundry Configuration Guide for the FESX, FSX, and FWSX

This Field...

Bridge IEEE 802.1W Parameters

Bridge Identifier

Bridge Max Age

Bridge Hello

Bridge FwdDly

Force-Version txHoldCnt

Root Bridge Identifier

Root Path Cost

Root Port

Max Age

Table 7.8: CLI Display of 802.1W Summary (Continued)

Displays...

Designated Bridge Identifier

The ID of the bridge.

The configured max age for this bridge. The default is 20.

The configured hello time for this bridge.The default is 2.

The configured forward delay time for this bridge. The default is 15.

The configured force version value. One of the following value is displayed:

• 0 – The bridge has been forced to operate in an STP compatibility mode.

• 2 – The bridge has been forced to operate in an 802.1W mode.

(This is the default.)

The number of BPDUs that can be transmitted per Hello Interval. The default is 3.

ID of the Root bridge that is associated with this bridge

The cost to reach the root bridge from this bridge. If the bridge is the root bridge, then this parameter shows a value of zero.

The bridge from where the root information was received.It can be from the root bridge itself, but it could also be from another bridge.

The port on which the root information was received. This is the port that is connected to the Designated Bridge.

The max age is derived from the Root port. An 802.1W-enabled bridge uses this value, along with the hello and message age parameters to compute the effective age of an RST BPDU.

The message age parameter is generated by the Designated port and transmitted in the RST BPDU. RST BPDUs transmitted by a

Designated port of the root bridge contains a message value of zero.

Effective age is the amount of time the Root port, Alternate port, or

Backup port retains the information it received from its peer

Designated port. Effective age is reset every time a port receives an

RST BPDU from its Designated port. If a Root port does not receive an RST BPDU from its peer Designated port for a duration more than the effective age, the Root port ages out the existing information and recomputes the topology.

If the port is operating in 802.1D compatible mode, then max age functionality is the same as in 802.1D (STP).

7 - 48 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

This Field...

Fwd Dly

Hello

Port IEEE 802.1W Parameters

Port Num

Pri

Port Path Cost

P2P Mac

Edge port

Role

Table 7.8: CLI Display of 802.1W Summary (Continued)

Displays...

The number of seconds a non-edge Designated port waits until it can apply any of the following transitions, if the RST BPDU it receives does not have an agreed flag:

• Discarding state to learning state

• Learning state to forwarding state

When a non-edge port receives the RST BPDU it goes into forwarding state within 4 seconds or after two hello timers expire on the port.

Fwd Dly is also the number of seconds that a Root port waits for an

RST BPDU with a proposal flag before it applies the state transitions listed above.

If the port is operating in 802.1D compatible mode, then forward delay functionality is the same as in 802.1D (STP).

The hello value derived from the Root port. It is the number of seconds between two Hello packets.

The port number shown in a slot#/port# format.

The configured priority of the port. The default is 128 or 0x80.

The configured path cost on a link connected to this port.

Indicates if the point-to-point-mac parameter is configured to be a point-to-point link:

• T – The link is configured as a point-to-point link.

• F – The link is not configured as a point-to-point link. This is the default.

Indicates if the port is configured as an operational Edge port:

• T – The port is configured as an Edge port.

• F – The port is not configured as an Edge port. This is the default.

The current role of the port:

• Root

• Designated

• Alternate

• Backup

• Disabled

Refer to “Bridges and Bridge Port Roles” on page 7-19 for definitions of the roles.

December 2005 © Foundry Networks, Inc.

7 - 49

Foundry Configuration Guide for the FESX, FSX, and FWSX

This Field...

State

Designated Cost

Designated Bridge

Table 7.8: CLI Display of 802.1W Summary (Continued)

Displays...

The port’s current 802.1W state. A port can have one of the following states:

• Forwarding

• Discarding

• Learning

• Disabled

Refer to “Bridge Port States” on page 7-22 and “Edge Port and Non-

Edge Port States” on page 7-22.

The best root path cost that this port received, including the best root path cost that it can transmit.

The ID of the bridge that sent the best RST BPDU that was received on this port.

To display detailed information about 802-1W, using the following command:

FESX424 Router(config)#show 802-1w detail

======================================================================

VLAN 1 - MULTIPLE SPANNING TREE (MSTP - IEEE 802.1W) ACTIVE

======================================================================

BridgeId 800000e080541700, forceVersion 2, txHoldCount 3

Port 1 - Role: ROOT - State: FORWARDING

PathCost 200000, Priority 128, AdminOperEdge F, AdminPt2PtMac F

DesignatedPriority - Root: 0x800000e0804c9c00, Bridge: 0x800000e080541700

ActiveTimers - rrWhile 4 rcvdInfoWhile 4

MachineStates - PIM: CURRENT, PRT: ROOT_PORT, PST: FORWARDING

TCM: ACTIVE, PPM: SENDING_STP, PTX: TRANSMIT_IDLE

Received - RST BPDUs 0, Config BPDUs 1017, TCN BPDUs 0

Port 2 - Role: DESIGNATED - State: FORWARDING

PathCost 200000, Priority 128, AdminOperEdge F, AdminPt2PtMac F

DesignatedPriority - Root: 0x800000e0804c9c00, Bridge: 0x800000e080541700

ActiveTimers - helloWhen 0

MachineStates - PIM: CURRENT, PRT: DESIGNATED_PORT, PST: FORWARDING

TCM: ACTIVE, PPM: SENDING_RSTP, PTX: TRANSMIT_IDLE

Received - RST BPDUs 0, Config BPDUs 0, TCN BPDUs 0

Syntax: show 802-1w detail [vlan <vlan-id>]

The vlan <vlan-id> parameter displays 802.1W information for the specified port-based VLAN.

The show spanning-tree 802.1W

command shows the following information.

This Field...

VLAN ID

7 - 50

Displays...

ID of the VLAN that owns the instance of 802.1W and whether or not it is active.

© Foundry Networks, Inc.

December 2005

This Field...

Bridge ID forceVersion txHoldCount

Port

Role

State

Path Cost

Priority

AdminOperEdge

AdminP2PMac

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Displays...

ID of the bridge. the configured version of the bridge:

• 0 – The bridge has been forced to operate in an STP compatible mode.

• 2 – The bridge has been forced to operate in an 802.1W mode.

The number of BPDUs that can be transmitted per Hello Interval. The default is 3.

ID of the port in slot#/port# format.

The current role of the port:

• Root

• Designated

• Alternate

• Backup

• Disabled

Refer to “Bridges and Bridge Port Roles” on page 7-19 for definitions of the roles.

The port’s current 802.1W state. A port can have one of the following states:

• Forwarding

• Discarding

• Learning

• Disabled

Refer to “Bridge Port States” on page 7-22 and “Edge Port and Non-

Edge Port States” on page 7-22.

The configured path cost on a link connected to this port.

The configured priority of the port. The default is 128 or 0x80.

Indicates if the port is an operational Edge port. Edge ports may either be auto-detected or configured (forced) to be Edge ports using the

CLI:

• T – The port is and Edge port.

• F – The port is not an Edge port. This is the default.

Indicates if the point-to-point-mac parameter is configured to be a point-to-point link:

• T – The link is a point-to-point link

• F – The link is not a point-to-point link. This is the default.

© Foundry Networks, Inc.

7 - 51

Foundry Configuration Guide for the FESX, FSX, and FWSX

This Field...

DesignatedPriority

ActiveTimers

Machine States

Received

Displays...

Shows the following:

• Root – Shows the ID of the root bridge for this bridge.

• Bridge – Shows the ID of the Designated bridge that is associated with this port.

Shows what timers are currently active on this port and the number of seconds they have before they expire:

• rrWhile – Recent root timer. A non-zero value means that the port has recently been a Root port.

• rcvdInfoWhile – Received information timer. Shows the time remaining before the information held by this port expires (ages out). This timer is initialized with the effective age parameter.

(See “Max Age” on page 7-48.)

• rbWhile – Recent backup timer. A non-zero value means that the port has recently been a Backup port.

• helloWhen – Hello period timer. The value shown is the amount of time between hello messages.

• tcWhile – Topology change timer. The value shown is the interval when topology change notices can be propagated on this port.

• fdWhile – Forward delay timer. (See the explanation for Fwd Dly on page 49.)

• mdelayWhile – Migration delay timer. The amount of time that a bridge on the same LAN has to synchronize its migration state with this port before another BPDU type can cause this port to change the BPDU that it transmits.

The current states of the various state machines on the port:

• PIM – State of the Port Information state machine.

• PRT – State of the Port Role Transition state machine.

• PST – State of the Port State Transition state machine.

• TCM – State of the Topology Change state machine.

• PPM – State of the Port Protocol Migration.

• PTX – State of the Port Transmit state machine.

Refer to the section “State Machines” on page 7-23 for details on state machines.

Shows the number of BPDU types the port has received:

• RST BPDU – BPDU in 802.1W format.

• Config BPDU – Legacy configuration BPDU (802.1D format).

• TCN BPDU – Legacy topology change BPDU (802.1D format).

7 - 52 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

802.1W Draft 3

As an alternative to full 802.1W, you can configure 802.1W Draft 3. 802.1W Draft 3 provides a subset of the RSTP capabilities described in the 802.1W STP specification.

802.1W Draft 3 support is disabled by default. When the feature is enabled, if a root port on a Foundry device that is not the root bridge becomes unavailable, the device can automatically Switch over to an alternate root port, without reconvergence delays. 802.1W Draft 3 does not apply to the root bridge, since all the root bridge’s ports are always in the forwarding state.

Figure 7.24 shows an example of an optimal STP topology. In this topology, all the non-root bridges have at least two paths to the root bridge (Switch 1 in this example). One of the paths is through the root port. The other path is a backup and is through the alternate port. While the root port is in the forwarding state, the alternate port is in the blocking state.

Figure 7.24

802.1W Draft 3 RSTP ready for failover

The arrow shows the path to the root bridge

Port 1/2

FWD

Root Bridge

Bridge priority = 2

Switch 1

Port 1/4

FWD

Port 1/3

FWD

Port 2/2

FWD

Port 2/4

FWD

Port 2/3

FWD

Switch 2

Bridge priority = 4

Root port = 2/2

Alternate = 2/3, 2/4

Bridge priority = 6

Root port = 3/3

Alternate = 3/4

Port 3/3

FWD

Switch 3

Port 3/4

BLK

Port 4/3

BLK

Port 4/4

FWD

Switch 4

Bridge priority = 8

Root port = 4/4

Alternate = 4/3

If the root port on a Switch becomes unavailable, 802.1W Draft 3 immediately fails over to the alternate port, as shown in Figure 7.25.

December 2005 © Foundry Networks, Inc.

7 - 53

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 7.25

802.1W Draft 3 RSTP failover to alternate root port

The arrow shows the path to the root bridge

Root Bridge

Bridge priority = 2

Port 1/2

FWD

Switch 1

Port 1/3

DISABLED

Port 1/4

FWD

X

Bridge priority = 6

Root port = 3/4

Port 3/3 unavailable

Switch 3

Port 3/4

FWD

Port 2/2

FWD

Port 2/4

FWD

Switch 2

Bridge priority = 4

Root port = 2/2

Alternate = 2/3, 2/4

Port 2/3

FWD

Port 4/3

BLK

Port 4/4

FWD

Switch 4

Bridge priority = 8

Root port = 4/4

Alternate = 4/3

In this example, port 3/3 on Switch 3 has become unavailable. In standard STP (802.1D), if the root port becomes unavailable, the Switch must go through the listening and learning stages on the alternate port to reconverge with the spanning tree. Thus, port 3/4 must go through the listening and learning states before entering the forwarding state and thus reconverging with the spanning tree.

802.1W Draft 3 avoids the reconvergence delay by calculating an alternate root port, and immediately failing over to the alternate port if the root port becomes unavailable. The alternate port is in the blocking state as long as the root port is in the forwarding state, but moves immediately to the active state if the root port becomes unavailable.

Thus, using 802.1W Draft 3, Switch 3 immediately fails over to port 3/4, without the delays caused by the listening and learning states.

802.1W Draft 3 selects the port with the next-best cost to the root bridge. For example, on Switch 3, port 3/3 has the best cost to the root bridge and thus is selected by STP as the root port. Port 3/4 has the next-best cost to the root bridge, and thus is selected by 802.1W Draft 3 as the alternate path to the root bridge.

Once a failover occurs, the Switch no longer has an alternate root port. If the port that was an alternate port but became the root port fails, standard STP is used to reconverge with the network. You can minimize the reconvergence delay in this case by setting the forwarding delay on the root bridge to a lower value. For example, if the forwarding delay is set to 15 seconds (the default), change the forwarding delay to a value from 3 – 10 seconds.

During failover, 802.1W Draft 3 flushes the MAC addresses leaned on the unavailable root port, selects the alternate port as the new root port, and places that port in the forwarding state. If traffic is flowing in both directions on the new root port, addresses are flushed (moved) in the rest of the spanning tree automatically.

7 - 54 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Reconvergence Time

Spanning tree reconvergence using 802.1W Draft 3 can occur within one second.

After the spanning tree reconverges following the topology change, traffic also must reconverge on all the bridges attached to the spanning tree. This is true regardless of whether 802.1W Draft 3 or standard STP is used to reconverge the spanning tree.

Traffic reconvergence happens after the spanning tree reconvergence, and is achieved by flushing the Layer 2 information on the bridges.

• Following 802.1W Draft 3 reconvergence of the spanning tree, traffic reconvergence occurs in the time it takes for the bridge to detect the link changes plus the STP maximum age set on the bridge.

• If standard STP reconvergence occurs instead, traffic reconvergence takes two times the forward delay plus the maximum age.

NOTE: 802.1W Draft 3 does not apply when a failed root port comes back up. In this case, standard STP is used.

Configuration Considerations

802.1W Draft 3 is disabled by default. To ensure optimal performance of the feature before you enable it:

• Configure the bridge priorities so that the root bridge is one that supports 802.1W Draft 3. (Use a Foundry device or third-party device that supports 802.1W Draft 3.)

• Change the forwarding delay on the root bridge to a value lower than the default 15 seconds. Foundry recommends a value from 3 – 10 seconds. The lower forwarding delay helps reduce reconvergence delays in cases where 802.1W Draft 3 is not applicable, such as when a failed root port comes back up.

• Configure the bridge priorities and root port costs so that each device has an active path to the root bridge if its root port becomes unavailable. For example, port 3/4 is connected to port 2/4 on Switch 2, which has the second most favorable bridge priority in the spanning tree.

NOTE: If reconvergence involves changing the state of a root port on a bridge that supports 802.1D STP but not

802.1W Draft 3, then reconvergence still requires the amount of time it takes for the ports on the 802.1D bridge to change state to forwarding (as needed), and receive BPDUs from the root bridge for the new topology.

Enabling 802.1W Draft 3

802.1W Draft 3 is disabled by default. The procedure for enabling the feature differs depending on whether single

STP is enabled on the device.

NOTE: STP must be enabled before you can enable 802.1W Draft 3.

Enabling 802.1W Draft 3 When Single STP Is Not Enabled

By default, each port-based VLAN on the device has its own spanning tree. To enable 802.1W Draft 3 in a portbased VLAN, enter commands such as the following:

FESX424 Router(config)# vlan 10

FESX424 Router(config-vlan-10)# spanning-tree rstp

Syntax: [no] spanning-tree rstp

This command enables 802.1W Draft 3. You must enter the command separately in each port-based VLAN in which you want to run 802.1W Draft 3.

December 2005 © Foundry Networks, Inc.

7 - 55

Foundry Configuration Guide for the FESX, FSX, and FWSX

NOTE: This command does not also enable STP. To enable STP, first enter the spanning-tree command without the rstp parameter. After you enable STP, enter the spanning-tree rstp command to enable 802.1W

Draft 3.

To disable 802.1W Draft 3, enter the following command:

FESX424 Router(config-vlan-10)# no spanning-tree rstp

Enabling 802.1W Draft 3 When Single STP Is Enabled

To enable 802.1W Draft 3 on a device that is running single STP, enter the following command at the global

CONFIG level of the CLI:

FESX424 Router(config)# spanning-tree single rstp

Syntax: [no] spanning-tree single rstp

This command enables 802.1W Draft 3 on the whole device.

NOTE: This command does not also enable single STP. To enable single STP, first enter the spanning-tree single command without the rstp parameter. After you enable single STP, enter the spanning-tree single rstp command to enable 802.1W Draft 3.

To disable 802.1W Draft 3 on a device that is running single STP, enter the following command:

FESX424 Router(config)# no spanning-tree single rstp

Single Spanning Tree (SSTP)

By default, each port-based VLAN on a Foundry device runs a separate spanning tree, which you can enable or disable on an individual VLAN basis.

Alternatively, you can configure a Foundry device to run a single spanning tree across all ports and VLANs on the device. The Single STP feature (SSTP) is especially useful for connecting a Foundry device 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 support on

Foundry devices. See “STP Parameters and Defaults” on page 7-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.

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 Foundry device 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.

7 - 56 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Enabling SSTP

To enable SSTP, use one of the following methods.

NOTE: If the device has only one port-based VLAN (the default VLAN), then the device 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 device contains more than one port-based VLAN and you want all the ports to be in the same STP broadcast domain.

To configure the Foundry device to run a single spanning tree, enter the following command at the global CONFIG level.

FESX424 Router(config)# spanning-tree single

NOTE: If the device 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:

FESX424 Router(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:

FESX424 Router(config) spanning-tree single ethernet 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 [<slotnum>/]<portnum> path-cost <value> | priority <value>]

NOTE: Both commands listed above are entered at the global CONFIG level.

Displaying SSTP information

To verify that SSTP is in effect, enter the following commands at any level of the CLI:

FESX424 Router(config)# show span

Syntax: show span [vlan <vlan-id>] | [pvst-mode] | [<num>] |

[detail [vlan <vlan-id> [ethernet [<slotnum>/]<portnum>] | <num>]]

The vlan <vlan-id> parameter displays STP information for the specified port-based VLAN.

The pvst-mode parameter displays STP information for the device’s Per VLAN Spanning Tree (PVST+) compatibility configuration. See “PVST/PVST+ Compatibility” on page 7-61.

The <num> parameter displays only the entries after the number you specify. For example, on a device 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 span 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 7-12.

December 2005 © Foundry Networks, Inc.

7 - 57

Foundry Configuration Guide for the FESX, FSX, and FWSX

STP per VLAN Group

STP per VLAN group is an STP enhancement that provides scalability while overcoming the limitations of the following scalability alternatives:

• Standard STP – You can configure only 128 instances of standard STP on a Foundry device. It is possible to need more instances of STP than this in large configurations. Using STP per VLAN group, you can aggregate

STP instances.

• Single STP – Single STP allows all the VLANs to run STP, but each VLAN runs the same instance of STP, resulting in numerous blocked ports that do not pass any Layer 2 traffic. STP per VLAN group uses all available links by load balancing traffic for different instances of STP on different ports. A port that blocks traffic for one spanning tree forwards traffic for another spanning tree.

STP per VLAN group allows you to group VLANs and apply the same STP parameter settings to all the VLANs in the group. Figure 7.26 shows an example of a STP per VLAN group implementation.

Figure 7.26

STP per VLAN Group Example

Member

VLAN 3

Member

VLAN 4

Member

VLAN 13

Foundry

Device

STP group 1

Master VLAN 2

Member VLAN 3

Member VLAN 4

STP priority 1

STP group 2

Master VLAN 12

Member VLAN 13

Member VLAN 14

STP priority 2

Member

VLAN 14

A master VLAN contains one or more member VLANs. Each of the member VLANs in the STP Group runs the same instance of STP and uses the STP parameters configured for the master VLAN. In this example, the

Foundry device is configured with VLANs 3, 4, 13, and 14. VLANs 3 and 4 are grouped in master VLAN 2, which is in STP group 1. VLANs 13 and 14 are grouped in master VLAN 12, which is in STP group 2. The VLANs in

STP group 1 all share the same spanning tree. The VLANs in STP group 2 share a different spanning tree.

All the ports in the VLANs are tagged. The ports must be tagged so that they can be in both a member VLAN and the member's master VLAN. For example, ports 1/1 – 1/4 are in member VLAN 3 and also in master VLAN 2

(since master VLAN 2 contains member VLAN 3).

STP Load Balancing

Notice that the STP groups each have different STP priorities. In configurations that use the STP groups on multiple devices, you can use the STP priorities to load balance the STP traffic. By setting the STP priorities for the same STP group to different values on each device, you can cause each of the devices to be the root bridge for a different STP group. This type of configuration distributes the traffic evenly across the devices and also ensures that ports that are blocked in one STP group’s spanning tree are used by another STP group’s spanning tree for forwarding. See “Configuration Example for STP Load Sharing” on page 7-60 for an example using STP load sharing.

Configuring STP per VLAN Group

To configure STP per VLAN group:

• Configure the member VLANs.

• Optionally, configure master VLANs to contain the member VLANs. This is useful when you have a lot of member VLANs and you do not want to individually configure STP on each one. Each of the member VLANs in the STP group uses the STP settings of the master VLAN.

• Configure the STP groups. Each STP group runs a separate instance of STP.

7 - 58 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Here are the CLI commands for implementing the STP per VLAN group configuration shown in Figure 7.26. The following commands configure the member VLANs (3, 4, 13, and 14) and the master VLANs (2 and 12). Notice that changes to STP parameters are made in the master VLANs only, not in the member VLANs.

FastIron SuperX Router(config)# vlan 2

FastIron SuperX Router(config-vlan-2)# spanning-tree priority 1

FastIron SuperX Router(config-vlan-2)# tagged ethernet 1/1 to 1/4

FastIron SuperX Router(config-vlan-2)# vlan 3

FastIron SuperX Router(config-vlan-3)# tagged ethernet 1/1 to 1/4

FastIron SuperX Router(config-vlan-3)# vlan 4

FastIron SuperX Router(config-vlan-4)# tagged ethernet 1/1 to 1/4

FastIron SuperX Router(config-vlan-4)# vlan 12

FastIron SuperX Router(config-vlan-12)# spanning-tree priority 2

FastIron SuperX Router(config-vlan-12)# tagged ethernet 1/1 to 1/4

FastIron SuperX Router(config-vlan-12)# vlan 13

FastIron SuperX Router(config-vlan-13)# tagged ethernet 1/1 to 1/4

FastIron SuperX Router(config-vlan-13)# vlan 14

FastIron SuperX Router(config-vlan-14)# tagged ethernet 1/1 to 1/4

FastIron SuperX Router(config-vlan-14)# exit

The following commands configure the STP groups.

FastIron SuperX Router(config)# stp-group 1

FastIron SuperX Router(config-stp-group-1)# master-vlan 2

FastIron SuperX Router(config-stp-group-1)# member-vlan 3 to 4

FastIron SuperX Router(config-stp-group-1)# exit

FastIron SuperX Router(config)# stp-group 2

FastIron SuperX Router(config-stp-group-2)# master-vlan 12

FastIron SuperX Router(config-stp-group-2)# member-vlan 13 to 14

Syntax: [no] stp-group <num>

This command changes the CLI to the STP group configuration level. The following commands are valid at this level. The <num> parameter specifies the STP group ID and can be from 1 – 32.

Syntax: [no] master-vlan <num>

This command adds a master VLAN to the STP group. The master VLAN contains the STP settings for all the

VLANs in the STP per VLAN group. The <num> parameter specifies the VLAN ID. An STP group can contain one master VLAN.

NOTE: If you delete the master VLAN from an STP group, the software automatically assigns the first member

VLAN in the group to be the new master VLAN for the group.

Syntax: [no] member-vlan <num> [to <num>]

This command adds additional VLANs to the STP group. These VLANs also inherit the STP settings of the master VLAN in the group.

Syntax: [no] member-group <num>

This command adds a member group (a VLAN group) to the STP group. All the VLANs in the member group inherit the STP settings of the master VLAN in the group. The <num> parameter specifies the VLAN group ID.

NOTE: This command is optional and is not used in the example above. For an example of this command, see

“Configuration Example for STP Load Sharing”.

December 2005 © Foundry Networks, Inc.

7 - 59

Foundry Configuration Guide for the FESX, FSX, and FWSX

Configuration Example for STP Load Sharing

Figure 7.27 shows another example of a STP per VLAN group implementation.

Figure 7.27

More Complex STP per VLAN Group Example

Member VLANs

2 - 200

Member VLANs

202 - 400

Member VLANs

402 - 600

Root bridge for master VLAN 1

FWD 1 5/3

FWD 1

5/1

FWD 1

5/2

BLK 1 Root bridge for master VLAN 201

Member VLANs

3802 - 4000

BLK 1

Root bridge for master VLAN 401

Root bridge for master VLAN 3801

In this example, each of the devices in the core is configured with a common set of master VLANs, each of which contains one or more member VLANs. Each of the member VLANs in an STP group runs the same instance of

STP and uses the STP parameters configured for the master VLAN.

The STP group ID identifies the STP instance. All VLANs within an STP group run the same instance of STP. The master VLAN specifies the bridge STP parameters for the STP group, including the bridge priority. In this example, each of the devices in the core is configured to be the default root bridge for a different master VLAN.

This configuration ensures that each link can be used for forwarding some traffic. For example, all the ports on the root bridge for master VLAN 1 are configured to forward BPDUs for master VLAN’s spanning tree. Ports on the other devices block or forward VLAN 1’s traffic based on STP convergence. All the ports on the root bridge for

VLAN 2 forward VLAN 2’s traffic, and so on.

All the ports in the VLANs are tagged. The ports must be tagged so that they can be in both a member VLAN and the member's master VLAN. For example, port 1/1 – and ports 5/1, 5/2, and 5/3 are in member VLAN 2 and master VLAN 1 (since master VLAN a contains member VLAN 2).

Here are the commands for configuring the root bridge for master VLAN 1 in figure Figure 7.26 for STP per VLAN group. The first group of commands configures the master VLANs. Notice that the STP priority is set to a different value for each VLAN. In addition, the same VLAN has a different STP priority on each device. This provides load balancing by making each of the devices a root bridge for a different spanning tree.

FastIron SuperX Router(config)# vlan 1

FastIron SuperX Router(config-vlan-1)# spanning-tree priority 1

FastIron SuperX Router(config-vlan-1)# tag ethernet 1/1 ethernet 5/1 to 5/3

FastIron SuperX Router(config-vlan-1)# vlan 201

FastIron SuperX Router(config-vlan-201)# spanning-tree priority 2

FastIron SuperX Router(config-vlan-201)# tag ethernet 1/2 ethernet 5/1 to 5/3

FastIron SuperX Router(config-vlan-201)# vlan 401

FastIron SuperX Router(config-vlan-401)# spanning-tree priority 3

FastIron SuperX Router(config-vlan-401)# tag ethernet 1/3 ethernet 5/1 to 5/3

...

7 - 60 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

FastIron SuperX Router(config-vlan-3601)# vlan 3801

FastIron SuperX Router(config-vlan-3801)# spanning-tree priority 20

FastIron SuperX Router(config-vlan-3801)# tag ethernet 1/20 ethernet 5/1 to 5/3

FastIron SuperX Router(config-vlan-3801)# exit

The next group of commands configures VLAN groups for the member VLANs. Notice that the VLAN groups do not contain the VLAN numbers assigned to the master VLANs. Also notice that no STP parameters are configured for the groups of member VLANs. Each group of member VLANs will inherit its STP settings from its master VLAN.

Set the bridge priority for each master VLAN to the highest priority (1) on one of the devices in the STP per VLAN group configuration. By setting the bridge priority to the highest priority, you make the device the default root bridge for the spanning tree. To ensure STP load balancing, make each of the devices the default root bridge for a different master VLAN.

FastIron SuperX Router(config)# vlan-group 1 vlan 2 to 200

FastIron SuperX Router(config-vlan-group-1)# tag ethernet 1/1 ethernet 5/1 to 5/3

FastIron SuperX Router(config-vlan-group-1)# vlan-group 2 vlan 202 to 400

FastIron SuperX Router(config-vlan-group-2)# tag ethernet 1/2 ethernet 5/1 to 5/3

FastIron SuperX Router(config-vlan-group-2)# vlan-group 3 vlan 402 to 600

FastIron SuperX Router(config-vlan-group-2)# tag ethernet 1/3 ethernet 5/1 to 5/3

...

FastIron SuperX Router(config-vlan-group-19)# vlan-group 20 vlan 3082 to 4000

FastIron SuperX Router(config-vlan-group-20)# tag ethernet 1/20 ethernet 5/1 to 5/3

FastIron SuperX Router(config-vlan-group-20)# exit

The following group of commands configures the STP groups. Each STP group in this configuration contains one master VLAN, which contains a VLAN group. This example shows that an STP group also can contain additional

VLANs (VLANs not configured in a VLAN group).

FastIron SuperX Router(config)# stp-group 1

FastIron SuperX Router(config-stp-group-1)# master-vlan 1

FastIron SuperX Router(config-stp-group-1)# member-group 1

FastIron SuperX Router(config-stp-group-1)# member-vlan 4001 4004 to 4010

FastIron SuperX Router(config-stp-group-1)# stp-group 2

FastIron SuperX Router(config-stp-group-2)# master-vlan 201

FastIron SuperX Router(config-stp-group-2)# member-group 2

FastIron SuperX Router(config-stp-group-2)# member-vlan 4002 4003 4011 to 4015

FastIron SuperX Router(config-stp-group-2)# stp-group 3

FastIron SuperX Router(config-stp-group-3)# master-vlan 401

FastIron SuperX Router(config-stp-group-3)# member-group 3

...

FastIron SuperX Router(config-stp-group-19)# stp-group 20

FastIron SuperX Router(config-stp-group-20)# master-vlan 3081

FastIron SuperX Router(config-stp-group-20)# member-group 20

PVST/PVST+ Compatibility

The FastIron family of switches provide support for Cisco's Per VLAN Spanning Tree plus (PVST+), by allowing the device to run multiple spanning trees (MSTP) while also interoperating with IEEE 802.1Q devices

1

.

NOTE: Foundry ports automatically detect PVST+ BPDUs and enable support for the BPDUs once detected.

You do not need to perform any configuration steps to enable PVST+ support. However, to support the IEEE

802.1Q BPDUs, you might need to enable dual-mode support.

1.Cisco user documentation for PVST/PVST+ refers to the IEEE 802.1Q spanning tree as the Common

Spanning Tree (CST) .

December 2005 © Foundry Networks, Inc.

7 - 61

Foundry Configuration Guide for the FESX, FSX, and FWSX

Foundry’s support for Cisco's Per VLAN Spanning Tree plus (PVST+), allows a Foundry device to run multiple spanning trees (MSTP) while also interoperating with IEEE 802.1Q devices. Foundry ports automatically detect

PVST+ BPDUs and enable support for the BPDUs once detected. The enhancement allows a port that is in

PVST+ compatibility mode due to auto-detection to revert 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 enhancement allows a port that was originally interoperating with PVST+ to revert to MSTP when connected to a Foundry device.

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 enhanced PVST+ support 1allows a Foundry device 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 tunnelled through 802.1Q regions, while PVST BPDUs for VLAN 1 (the IEEE 802.1Q

VLAN) are processed by PVST+ regions. Figure 7.28 shows the interaction of IEEE 802.1Q, PVST, and PVST+ regions.

Figure 7.28

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+.

7 - 62 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

For the port to also support the other VLANs (the PVST+ VLANs) in tagged mode, the dual-mode feature must be enabled on the port. The dual-mode feature enables the port to send and receive both tagged and untagged frames. When the dual-mode feature is enabled, the port is an untagged member of one of its VLANs and is at the same time a tagged member of all its other VLANs.

The untagged frames are supported on the port’s Port Native VLAN . By default, the Port 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 Port 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 devices are configured to use tagged or untagged frames on the VLAN.

Configuring 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 MSTP when connected to a Foundry device.

Enabling PVST+ Support Manually

To immediately enable PVST+ support on a port, enter commands such as the following:

FastIron SuperX Router(config)# interface ethernet 1/1

FastIron SuperX Router(config-if-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.

NOTE: If 802.1W and pvst-mode (either by auto-detection or by explicit configuration) are enabled on a tagged

VLAN port, 802.1W will treat the PVST BPDUs as legacy 802.1D BPDUs.

Enabling Dual-Mode Support

To enable the dual-mode feature on a port, enter the following command at the interface configuration level for the port:

FastIron SuperX Router(config-if-1/1)# dual-mode

1.Cisco PVST/PVST+ documentation refers to the Default VLAN as the Default Native VLAN .

December 2005 © Foundry Networks, Inc.

7 - 63

Foundry Configuration Guide for the FESX, FSX, and FWSX

Syntax: [no] dual-mode [<vlan-id>]

The <vlan-id> specifies the port’s Port Native VLAN. This is the VLAN on which the port will support untagged frames. By default, the Port Native VLAN is the same as the default VLAN (which is VLAN 1 by default).

For more information about the dual-mode feature, see “Dual-Mode VLAN Ports” on page 11-56.

Displaying PVST+ Support Information

To display PVST+ information for ports on a Foundry device, enter the following command at any level of the CLI:

FastIron SuperX Router(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

Syntax: show span pvst-mode

This command displays the following information.

This Field...

Port

Method

Table 7.9: 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 following examples show configuration examples for 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

Figure 7.29 shows an example of a PVST+ configuration that uses VLAN 1 as the untagged default VLAN and

VLANs 2, 3, and 4 as tagged VLANs.

7 - 64 © Foundry Networks, Inc.

December 2005

Configuring Spanning Tree Protocol (STP) and IronSpan Features

Figure 7.29

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

Port 1/1 Port 3/2

Cisco device

To implement this configuration, enter the following commands.

Commands on the Foundry Device

FastIron SuperX Router(config)# vlan-group 1 vlan 2 to 4

FastIron SuperX Router(config-vlan-group-1)# tagged ethernet 1/1

FastIron SuperX Router(config-vlan-group-1)# exit

FastIron SuperX Router(config)# interface ethernet 1/1

FastIron SuperX Router(config-if-1/1)# dual-mode

FastIron SuperX Router(config-if-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 Port 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.

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

Figure 7.30 shows an example in which a port’s Port Native VLAN is not VLAN 1. In this case, VLAN 1 uses tagged frames and VLAN 2 uses untagged frames.

Figure 7.30

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.

Commands on the Foundry Device

FastIron SuperX Router(config)# default-vlan-id 4000

FastIron SuperX Router(config)# vlan 1

FastIron SuperX Router(config-vlan-1)# tagged ethernet 1/1

FastIron SuperX Router(config-vlan-1)# exit

FastIron SuperX Router(config)# vlan 2

December 2005 © Foundry Networks, Inc.

7 - 65

Foundry Configuration Guide for the FESX, FSX, and FWSX

FastIron SuperX Router(config-vlan-2)# tagged ethernet 1/1

FastIron SuperX Router(config-vlan-2)# exit

FastIron SuperX Router(config)# interface ethernet 1/1

FastIron SuperX Router(config-if-1/1)# dual-mode 2

FastIron SuperX Router(config-if-1/1)# pvst-mode

FastIron SuperX Router(config-if-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 the dual-mode feature and 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 specified with the dual-mode command, which makes

VLAN 2 the port’s Port Native VLAN. As a result, the port processes untagged frames and untagged PVST

BPDUs on VLAN 2.

NOTE: Although VLAN 2 becomes the port’s untagged VLAN, the CLI still requires that you add the port to the

VLAN as a tagged port, since the port is a member of more than one VLAN.

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 the dual-mode feature enabled in order to process IEEE 802.1Q BPDUs.

For example, the following configuration is incorrect:

FastIron SuperX Router(config)# default-vlan-id 1000

FastIron SuperX Router(config)# vlan 1

FastIron SuperX Router(config-vlan-1)# tagged ethernet 1/1 to 1/2

FastIron SuperX Router(config-vlan-1)# exit

FastIron SuperX Router(config)# interface ethernet 1/1

FastIron SuperX Router(config-if-1/1)# pvst-mode

FastIron SuperX Router(config-if-1/1)# exit

FastIron SuperX Router(config)# interface ethernet 1/2

FastIron SuperX Router(config-if-1/2)# pvst-mode

FastIron SuperX Router(config-if-1/2)# exit

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:

FastIron SuperX Router(config)# default-vlan-id 1000

FastIron SuperX Router(config)# vlan 1

FastIron SuperX Router(config-vlan-1)# tagged ethernet 1/1 to 1/2

FastIron SuperX Router(config-vlan-1)# exit

FastIron SuperX Router(config)# interface ethernet 1/1

FastIron SuperX Router(config-if-1/1)# pvst-mode

FastIron SuperX Router(config-if-1/1)# dual-mode

FastIron SuperX Router(config-if-1/1)# exit

FastIron SuperX Router(config)# interface ethernet 1/2

FastIron SuperX Router(config-if-1/2)# pvst-mode

FastIron SuperX Router(config-if-1/2)# dual-mode

FastIron SuperX Router(config-if-1/2)# exit

Setting the ports as dual-mode ensures that the untagged IEEE 802.1Q BPDUs reach the VLAN 1 instance.

7 - 66 © Foundry Networks, Inc.

December 2005

Chapter 8

Configuring Metro Features

This chapter describes how to configure the Metro features listed in Table 8.1. You can use these metro features individually or in combination to provide fast, reliable, and easy to configure Layer 2 connectivity in your Metro network.

Table 8.1: Chapter Contents

Description

Topology groups – 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.

Metro Ring Protocol (MRP) – MRP is an alternative to STP that provides Layer 2 redundancy and sub-second failover in ring topologies.

See Page

8-1

8-5

Virtual Switch Redundancy Protocol (VSRP) – VSRP is an alternative to STP that provides Layer 2 and Layer 3 redundancy and sub-second failover in mesh topologies.

8-18

Topology Groups

A topology group is a named set of VLANs that share a Layer 2 topology. Topology groups simplify configuration and enhance scalability of Layer 2 protocols by allowing you to run a single instance of a Layer 2 protocol on multiple VLANs.

You can use topology groups with the following Layer 2 protocols:

• STP

• MRP

• VSRP

• 802.1W

Topology groups simplify Layer 2 configuration and provide scalability by enabling you to use the same instance of a Layer 2 protocol for multiple VLANs. For example, if a Foundry device is deployed in a Metro network and provides forwarding for two MRP rings that each contain 128 VLANs, you can configure a topology group for each

December 2005 © Foundry Networks, Inc.

8 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX ring. If a link failure in a ring causes a topology change, the change is applied to all the VLANs in the ring’s topology group. Without topology groups, you would need to configure a separate ring for each VLAN.

NOTE: If you plan to use a configuration saved under an earlier software release and the configuration contains

STP groups, the CLI converts the STP groups into topology groups when you save the configuration. For backward compatibility, you can still use the STP group commands. However, the CLI converts the commands into the topology group syntax. Likewise, the show stp-group command displays STP topology groups.

Master VLAN and Member VLANs

Each topology group contains a master VLAN and can contain one or more member VLANs and VLAN groups.

• Master VLAN – The master VLAN contains the configuration information for the Layer 2 protocol. For example, if you plan to use the topology group for MRP, the topology group’s master VLAN contains the ring configuration information.

• Member VLANs – The member VLANs are additional VLANs that share ports with the master VLAN. The

Layer 2 protocol settings for the ports in the master VLAN apply to the same ports in the member VLANs. A change to the master VLAN’s Layer 2 protocol configuration or Layer 2 topology affects all the member

VLANs. Member VLANs do not independently run a Layer 2 protocol.

• Member VLAN groups – A VLAN group is a named set of VLANs. The VLANs within a VLAN group have the same ports and use the same values for other VLAN parameters.

When a Layer 2 topology change occurs on a port in the master VLAN, the same change is applied to that port in all the member VLANs that contain the port. For example, if you configure a topology group whose master VLAN contains ports 1/1 and 1/2, a Layer 2 state change on port 1/1 applies to port 1/1 in all the member VLANs that contain that port. However, the state change does not affect port 1/1 in VLANs that are not members of the topology group.

Control Ports and Free Ports

A port that is in a topology group can be a control port or a free port.

• Control port – A control port is a port in the master VLAN, and is therefore controlled by the Layer 2 protocol configured in the master VLAN. The same port in all the member VLANs is controlled by the master VLAN’s

Layer 2 protocol. Each member VLAN must contain all of the control ports and can contain additional ports.

• Free port – A free port is not controlled by the master VLAN’s Layer 2 protocol. The master VLAN can contain free ports. (In this case, the Layer 2 protocol is disabled on those ports.) In addition, any ports in the member VLANs that are not also in the master VLAN are free ports.

NOTE: Since free ports are not controlled by the master port’s Layer 2 protocol, they are assumed to always be in the Forwarding state.

Configuration Considerations

• Topology groups are supported in all FESX, FSX, and FWSX devices and associated software releases.

• You must configure the master VLAN and member VLANs or member VLAN groups before you configure the topology group.

• You can configure up to 256 topology groups. Each group can control up to 4096 VLANs. A VLAN cannot be controlled by more than one topology group.

• The topology group must contain a master VLAN and can also contain individual member VLANs, VLAN groups, or a combination of individual member VLANs and VLAN groups.

• Once you add a VLAN as a member of a topology group, all the Layer 2 protocol information on the VLAN is deleted.

8 - 2 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

Configuring a Topology Group

To configure a topology group, enter commands such as the following:

FastIron SuperX Router(config)# topology-group 2

FastIron SuperX Router(config-topo-group-2)# master-vlan 2

FastIron SuperX Router(config-topo-group-2)# member-vlan 3

FastIron SuperX Router(config-topo-group-2)# member-vlan 4

FastIron SuperX Router(config-topo-group-2)# member-vlan 5

FastIron SuperX Router(config-topo-group-2)# member-group 2

These commands create topology group 2 and add the following:

• Master VLAN 2

• Member VLANs 2, 3, and 4

• Member VLAN group 2

Syntax: [no] topology-group <group-id>

The <group-id> parameter specifies the topology group ID and can be from 1 – 256.

Syntax: [no] master-vlan <vlan-id>

This command adds the master VLAN. The VLAN must already be configured. Make sure all the Layer 2 protocol settings in the VLAN are correct for your configuration before you add the VLAN to the topology group. A topology group can have only one master VLAN.

NOTE: If you remove the master VLAN (by entering no master-vlan <vlan-id>), the software selects the nexthighest numbered member VLAN as the new master VLAN. For example, if you remove master VLAN 2 from the example above, the CLI converts member VLAN 3 into the new master VLAN. The new master VLAN inherits the

Layer 2 protocol settings of the older master VLAN.

NOTE: If you add a new master VLAN to a topology group that already has a master VLAN, the new master

VLAN replaces the older master VLAN. All member VLANs and VLAN groups follow the Layer 2 protocol settings of the new master VLAN.

Syntax: [no] member-vlan <vlan-id>

The <vlan-id> parameter specifies a VLAN ID. The VLAN must already be configured.

Syntax: [no] member-group <num>

The <num> specifies a VLAN group ID. The VLAN group must already be configured.

NOTE: Once you add a VLAN or VLAN group as a member of a topology group, all the Layer 2 protocol configuration information for the VLAN or group is deleted. For example, if STP is configured on a VLAN and you add the VLAN to a topology group, the STP configuration is removed from the VLAN. Once you add the VLAN to a topology group, the VLAN uses the Layer 2 protocol settings of the master VLAN.

If you remove a member VLAN or VLAN group from a topology group, you will need to reconfigure the Layer 2 protocol information in the VLAN or VLAN group.

Displaying Topology Group Information

The following sections show how to display STP information and topology group information for VLANS.

December 2005 © Foundry Networks, Inc.

8 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

Displaying STP Information

To display STP information for a VLAN, enter a command such as the following:

FESX424 Router(config)# show span vlan 4

VLAN 4 BPDU cam_index is 14344 and the Master DMA Are(HEX) 18 1A

STP instance owned by VLAN 2

This example shows STP information for VLAN 4. The line shown in bold type indicates that the VLAN’s STP configuration is controlled by VLAN 2. This information indicates that VLAN 4 is a member of a topology group and VLAN 2 is the master VLAN in that topology group.

Displaying Topology Group Information

To display topology group information, enter the following command:

FastIron SuperX Router(config)# show topology-group

Topology Group 3

=================

master-vlan 2

member-vlan none

Common control ports L2 protocol

ethernet 1/1 MRP

ethernet 1/2 MRP

ethernet 1/5 VSRP

ethernet 2/22 VSRP

Per vlan free ports

ethernet 2/3 Vlan 2

ethernet 2/4 Vlan 2

ethernet 2/11 Vlan 2

ethernet 2/12 Vlan 2

Syntax: show topology-group [<group-id>]

This display shows the following information.

Table 8.2: CLI Display of Topology Group Information

This Field...

master-vlan member-vlan

Common control ports

L2 protocol

Displays...

The master VLAN for the topology group. The settings for STP, MRP, or VSRP on the control ports in the master VLAN apply to all control ports in the member VLANs within the topology group.

The member VLANs in the topology group.

The master VLAN ports that are configured with Layer 2 protocol information. The Layer 2 protocol configuration and state of these ports in the master VLAN applies to the same port numbers in all the member VLANs.

The Layer 2 protocol configured on the control ports. The Layer 2 protocol can be one of the following:

• MRP

• STP

• VSRP

8 - 4 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

This Field...

Per vlan free ports

Table 8.2: CLI Display of Topology Group Information (Continued)

Displays...

The ports that are not controlled by the Layer 2 protocol information in the master VLAN.

Metro Ring Protocol (MRP)

The Metro Ring Protocol (MRP) is a Foundry proprietary protocol that prevents Layer 2 loops and provides fast reconvergence in Layer 2 ring topologies. It is an alternative to STP and is especially useful in Metropolitan Area

Networks (MANs) where using STP has the following drawbacks:

• STP allows a maximum of seven nodes. Metro rings can easily contain more nodes than this.

• STP has a slow reconvergence time, taking many seconds or even minutes. MRP can detect and heal a break in the ring in sub-second time.

Figure 8.1 shows an example of an MRP metro ring.

Figure 8.1

Metro ring – normal state

Customer A

F

F

Switch B

F

F

Customer A

F

Switch C

F

This interface blocks

Layer 2 traffic to prevent a loop

F

Switch A

Master

Node

B

F

Customer A

F

Switch D

F

F

Customer A

The ring in this example consists of four MRP nodes (Foundry switches). Each node has two interfaces with the ring. Each node also is connected to a separate customer network. The nodes forward Layer 2 traffic to and from the customer networks through the ring. The ring interfaces are all in one port-based VLAN. Each customer interface can be in the same VLAN as the ring or in a separate VLAN.

One node, is configured as the master node of the MRP ring. One of the two interfaces on the master node is configured as the primary interface; the other is the secondary interface. The primary interface originates Ring

Health Packets (RHPs), which are used to monitor the health of the ring. An RHP is forwarded on the ring to the

December 2005 © Foundry Networks, Inc.

8 - 5

Foundry Configuration Guide for the FESX, FSX, and FWSX next interface until it reaches the secondary interface of the master node. The secondary interface blocks the packet to prevent a Layer 2 loops.

Configuration Notes

• When you configure MRP, Foundry recommends that you disable one of the ring interfaces before beginning the ring configuration. Disabling an interface prevents a Layer 2 loop from occurring while you are configuring

MRP on the ring nodes. Once MRP is configured and enabled on all the nodes, you can re-enable the interface.

• MRP I is supported in all FESX, FSX, and FWSX devices and their associated software releases.

• The above configurations are capable of being configured as MRP masters or MRP members (for different rings).

MRP Rings Without Shared Interfaces (MRP Phase 1)

MRP Phase 1 allows you to configure multiple MRP rings, as shown in Figure 8.2, but the rings cannot share the same link. For example, you cannot configure ring 1 and ring 2 to each have interfaces 1/1 and 1/2.

Also, when you configure an MRP ring, any node on the ring can be designated as the master node for the ring. A master node can be the master node of more than one ring. (See Figure 8.2.) Each ring is an independent ring and RHP packets are processed within each ring.

Figure 8.2

Metro ring – multiple rings

Master node

Ring 1 port 1/1 port 4/1 port 1/2 port 4/2

Ring 2

Master node

Ring 3

8 - 6

In this example, two nodes are each configured with two MRP rings. Any node in a ring can be the master for its ring. A node also can be the master for more than one ring.

© Foundry Networks, Inc.

December 2005

Configuring Metro Features

Ring Initialization

The ring shown in Figure 8.1 shows the port states in a fully initialized ring without any broken links. Figure 8.3 shows the initial state of the ring, when MRP is first enabled on the ring’s switches. All ring interfaces on the master node and member nodes begin in the Preforwarding state (PF).

Figure 8.3

Metro ring – initial state

Customer A

F

PF

Switch B

PF

PF

Customer A

F

Switch C

PF

All ports start in

Preforwarding state.

Primary port on Master node sends RHP 1

PF

Switch A

Master

Node

PF

F

Customer A

PF Switch D

PF

F

Customer A

MRP uses Ring Health Packets (RHPs) to monitor the health of the ring. An RHP is an MRP protocol packet. The source address is the MAC address of the master node and the destination MAC address is a protocol address for

MRP. The Master node generates RHPs and sends them on the ring. The state of a ring port depends on the

RHPs.

A ring interface can have one of the following MRP states:

• Preforwarding (PF) – The interface can forward RHPS but cannot forward data. All ring ports being in this state when you enable MRP.

• Forwarding (F) – The interface can forward data as well as RHPs. An interface changes from Preforwarding to Forwarding when the port’s preforwarding time expires. This occurs if the port does not receive an RHP from the Master, or if the forwarding bit in the RHPs received by the port is off. This indicates a break in the ring. The port heals the ring by changing its state to Forwarding. The preforwarding time is the number of milliseconds the port will remain in the Preforwarding state before changing to the Forwarding state, even without receiving an RHP.

• Blocking (B) – The interface cannot forward data. Only the secondary interface on the Master node can be

Blocking.

When MRP is enabled, all ports begin in the Preforwarding state. The primary interface on the Master node, although it is in the Preforwarding state like the other ports, immediately sends an RHP onto the ring. The secondary port on the Master node listens for the RHP.

December 2005 © Foundry Networks, Inc.

8 - 7

Foundry Configuration Guide for the FESX, FSX, and FWSX

• If the secondary port receives the RHP, all links in the ring are up and the port changes its state to Blocking.

The primary port then sends another MRP with its forwarding bit set on. As each of the member ports receives the RHP, the ports changes their state to Forwarding. Typically, this occurs in sub-second time. The ring very quickly enters the fully initialized state.

• If the secondary port does not receive the RHP by the time the preforwarding time expires, a break has occurred in the ring. The port changes its state to Forwarding. The member ports also change their states from Preforwarding to Forwarding as their preforwarding timers expire. The ring is not intact, but data can still travel among the nodes using the links that are up.

Figure 8.4 shows an example.

Figure 8.4

Metro ring – from Preforwarding to Forwarding

Customer A

F

RHP 2

Forwarding bit is on.

Each port changes from

Preforwarding to Forwarding when it receives this RHP.

PF

Switch B

F

PF

Customer A

F

Switch C

PF

Secondary port receives RHP 1 and changes to

Blocking

Primary port then sends RHP 2 with forwarding bit on

F

Switch A

Master

Node

B

F

Customer A

PF Switch D

PF

F

Customer A

Each RHP also has a sequence number. MRP can use the sequence number to determine the round-trip time for

RHPs in the ring. See “Using MRP Diagnostics” on page 8-12.

How Ring Breaks Are Detected and Healed

Figure 8.5 shows ring interface states following a link break. MRP quickly heals the ring and preserves connectivity among the customer networks.

8 - 8 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

Figure 8.5

Metro ring – ring break

Customer A

F

F

Switch B

F

F

Customer A

F

Switch C

F

Switch A

Master

Node

F

F

Customer A

Customer A

Switch D

F

F

If a break in the ring occurs, MRP heals the ring by changing the states of some of the ring interfaces.

• Blocking interface – The Blocking interface on the Master node has a dead timer. If the dead time expires before the interface receives one of its ring’s RHPs, the interface changes state to Preforwarding. Once the secondary interface changes state to Preforwarding:

• If the interface receives an RHP, the interface changes back to the Blocking state and resets the dead timer.

• If the interface does not receive an RHP for its ring before the Preforwarding time expires, the interface changes to the Forwarding state, as shown in Figure 8.5.

• Forwarding interfaces – Each member interface remains in the Forwarding state.

When the broken link is repaired, the link’s interfaces come up in the Preforwarding state, which allows RHPs to travel through the restored interfaces and reach the secondary interface on the Master node.

• If an RHP reaches the Master node’s secondary interface, the ring is intact. The secondary interface changes to Blocking. The Master node sets the forwarding bit on in the next RHP. When the restored interfaces receive this RHP, they immediately change state to Forwarding.

• If an RHP does not reach the Master node’s secondary interface, the ring is still broken. The Master node does not send an RHP with the forwarding bit on. In this case, the restored interfaces remain in the

Preforwarding state until the preforwarding timer expires, then change to the Forwarding state.

Master VLANs and Customer VLANs

All the ring ports must be in the same VLAN. Placing the ring ports in the same VLAN provides Layer 2 connectivity for a given customer across the ring. Figure 8.6 shows an example.

December 2005 © Foundry Networks, Inc.

8 - 9

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 8.6

Metro ring – ring VLAN and customer VLANs

Customer A

VLAN 30

Customer B

VLAN 40

Switch B

====== ring 1 interfaces 1/1, 1/2 topology group 2 master VLAN 2 (1/1, 1/2) member VLAN 30 (1/1, 1/2, 2/1) member VLAN 40 (1/1, 1/2, 4/1) port 2/1 port 1/2

Switch B port 4/1 port 1/1 port 1/2 port 2/1

Switch D port 1/1 port 4/1

Switch D

====== ring 1 interfaces 1/1, 1/2 topology group 2 master VLAN 2 (1/1, 1/2) member VLAN 30 (1/1, 1/2, 2/1) member VLAN 40 (1/1, 1/2, 4/1)

Customer A

VLAN 30

Customer B

VLAN 40

Notice that each customer has their own VLAN. Customer A has VLAN 30 and Customer B has VLAN 40.

Customer A’s host attached to Switch D can reach the Customer A host attached to Switch B at Layer 2 through the ring. Since Customer A and Customer B are on different VLANs, they will not receive each other’s traffic.

You can configure MRP separately on each customer VLAN. However, this is impractical if you have many customers. To simplify configuration when you have a lot of customers (and therefore a lot of VLANs), you can use a topology group.

A topology group enables you to control forwarding in multiple VLANs using a single instance of a Layer 2 protocol such as MRP. A topology group contains a master VLAN and member VLANs. The master VLAN contains all the configuration parameters for the Layer 2 protocol (STP, MRP, or VSRP). The member VLANs use the Layer 2 configuration of the master VLAN.

In Figure 8.6, VLAN 2 is the master VLAN and contains the MRP configuration parameters for ring 1. VLAN 30 and VLAN 40, the customer VLANs, are member VLANs in the topology group. Since a topology group is used, a single instance of MRP provides redundancy and loop prevention for both the customer VLANs.

If you use a topology group:

• The master VLAN must contain the ring interfaces. The ports must be tagged, since they will be shared by multiple VLANs.

• The member VLAN for a customer must contain the two ring interfaces and the interfaces for the customer.

Since these interfaces are shared with the master VLAN, they must be tagged. Do not add another customer’s interfaces to the VLAN.

For more information about topology groups, see “Topology Groups” on page 8-1.

See “MRP CLI Example” on page 8-16 for the configuration commands required to implement the MRP configuration shown in Figure 8.6.

8 - 10 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

Configuring MRP

To configure MRP, perform the following tasks. You need to perform the first task on only one of the nodes.

Perform the remaining tasks on all the nodes.

• Disable one of the ring interfaces. This prevents a Layer 2 loop from occurring while you are configuring the devices for MRP.

• Add an MRP ring to a port-based VLAN. When you add a ring, the CLI changes to the configuration level for the ring, where you can perform the following tasks.

• Optionally, specify a name for the ring.

• On the master node only, enable the device to be the master for the ring. Each ring can have only one master node.

• Specify the MRP interfaces. Each device has two interfaces to an MRP ring.

• Optionally, change the hello time and the preforwarding time. These parameters control how quickly failover occurs following a change in the state of a link in the ring.

• Enable the ring.

• Optionally, add the ring’s VLAN to a topology group to add more VLANs to the ring. If you use a topology group, make sure you configure MRP on the group’s master VLAN. See “Topology Groups” on page 8-1.

• Re-enable the interface you disabled to prevent a Layer 2 loop. Once MRP is enabled, MRP will prevent the

Layer 2 loop.

Adding an MRP Ring to a VLAN

To add an MRP ring to a VLAN, enter commands such as the following.

NOTE: If you plan to use a topology group to add VLANs to the ring, make sure you configure MRP on the topology group’s master VLAN.

FastIron SuperX Router(config)# vlan 2

FastIron SuperX Router(config-vlan-2)# metro-ring 1

FastIron SuperX Router(config-vlan-2-mrp-1)# name CustomerA

FastIron SuperX Router(config-vlan-2-mrp-1)# master

FastIron SuperX Router(config-vlan-2-mrp-1)# ring-interface ethernet 1/1 ethernet 1/

2

FastIron SuperX Router(config-vlan-2-mrp-1)# enable

These commands configure an MRP ring on VLAN 2. The ring ID is 1, the ring name is CustomerA, and this node

(this Foundry device) is the master for the ring. The ring interfaces are 1/1 and 1/2. Interface 1/1 is the primary interface and 1/2 is the secondary interface. The primary interface will initiate RHPs by default. The ring takes effect in VLAN 2.

Syntax: [no] metro-ring <ring-id>

The <ring-id> parameter specifies the ring ID and can be from 1 – 255. Configure the same ring ID on each of the nodes in the ring.

Syntax: [no] name <string>

The <string> parameter specifies a name for the ring. The name is optional, but it can be up to 20 characters long and can include blank spaces. If you use a name that has blank spaces, enclose the name in double quotation marks (for example: “Customer A”).

Syntax: [no] master

Configures this node as the master node for the ring. Enter this command only on one node in the ring. The node is a member (non-master) node by default.

Syntax: [no] ring-interface ethernet <primary-if> ethernet <secondary-if>

December 2005 © Foundry Networks, Inc.

8 - 11

Foundry Configuration Guide for the FESX, FSX, and FWSX

The ethernet <primary-if> parameter specifies the primary interface. On the master node, the primary interface is the one that originates RHPs. Ring control traffic and Layer 2 data traffic will flow in the outward direction from this interface by default. On member nodes, the direction of traffic flow depends on the traffic direction selected by the master node. Therefore, on a member node, the order in which you enter the interfaces does not matter.

The ethernet <secondary-if> parameter specifies the secondary interface.

NOTE: To take advantage of every interface in a Metro network, you can configure another MRP ring and either configure a different Master node for the ring or reverse the configuration of the primary and secondary interfaces on the Master node. Configuring multiple rings enables you to use all the ports in the ring. The same port can forward traffic one ring while blocking traffic for another ring.

Syntax: [no] enable

The enable command enables the ring.

Changing the Hello and PreForwarding Times

You also can change the RHP hello time and preforwarding time. To do so, enter commands such as the following:

FastIron SuperX Router(config-vlan-2-mrp-1)# hello-time 200

FastIron SuperX Router(config-vlan-2-mrp-1)# preforwarding-time 400

These commands change the hello time to 200 ms and change the preforwarding time to 400 ms.

NOTE: The preforwarding time must be at least twice the value of the hello time and must be a multiple of the hello time.

Syntax: [no] hello-time <ms>

Syntax: [no] preforwarding-time <ms>

The <ms> specifies the number of milliseconds. For the hello time, you can specify from 100 – 1000 (one second). The default hello time is 100 ms. The preforwarding time can be from 200 – 5000 ms, but must be at least twice the value of the hello time and must be a multiple of the hello time. The default preforwarding time is

300 ms. A change to the hello time or preforwarding time takes effect as soon as you enter the command.

NOTE: You can use MRP ring diagnostics to determine whether you need to change the hello time and preforwarding time. See “Using MRP Diagnostics”.

Using MRP Diagnostics

The MRP diagnostics feature calculates how long it takes for RHP packets to travel through the ring. When you enable MRP diagnostics, the software tracks RHP packets according to their sequence numbers and calculates how long it takes an RHP packet to travel one time through the entire ring. When you display the diagnostics, the

CLI shows the average round-trip time for the RHP packets sent since you enabled diagnostics. The calculated results have a granularity of 1 microsecond.

Enabling MRP Diagnostics

To enable MRP diagnostics for a ring, enter the following command on the Master node, at the configuration level for the ring:

FastIron SuperX Router(config-vlan-2-mrp-1)# diagnostics

Syntax: [no] diagnostics

NOTE: This command is valid only on the master node.

8 - 12 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

Displaying MRP Diagnostics

To display MRP diagnostics results, enter the following command on the Master node:

FastIron SuperX Router(config)# show metro 1 diag

Metro Ring 1 - CustomerA

============= diagnostics results

Ring Diag RHP average Recommended Recommended id state time(microsec) hello time(ms) Prefwing time(ms)

2 enabled 125 100 300

Diag frame sent Diag frame lost

1230 0

Syntax: show metro <ring-id> diag

This display shows the following information.

This Field...

Ring id

Diag state

RHP average time

Diag frame sent

Diag frame lost

Table 8.3: CLI Display of MRP Ring Diagnostic Information

Recommended hello time

Recommended Prefwing time

Displays...

The ring ID.

The state of ring diagnostics.

The average round-trip time for an RHP packet on the ring. The calculated time has a granularity of 1 microsecond.

The hello time recommended by the software based on the RHP average round-trip time.

The preforwarding time recommended by the software based on the

RHP average round-trip time.

The number of diagnostic RHPs sent for the test.

The number of diagnostic RHPs lost during the test.

If the recommended hello time and preforwarding time are different from the actual settings and you want to change them, see “Configuring MRP” on page 8-11.

Displaying MRP Information

You can display the following MRP information:

• Topology group configuration information

• Ring configuration information and statistics

Displaying Topology Group Information

To display topology group information, enter the following command:

Syntax: show topology-group [<group-id>]

See “Displaying Topology Group Information” on page 8-3 for more information.

December 2005 © Foundry Networks, Inc.

8 - 13

Foundry Configuration Guide for the FESX, FSX, and FWSX

Displaying Ring Information

To display ring information, enter the following command:

FastIron SuperX Router(config)# show metro

Metro Ring 1

=============

Ring State Ring Master Topo Hello Prefwing id role vlan group time(ms) time(ms)

2 enabled member 2 not conf 100 300

Ring interfaces Interface role Forwarding state Active interface Interface Type ethernet 1/1 primary disabled none Regular ethernet 1/2 secondary forwarding ethernet 2 Tunnel

RHPs sent RHPs rcvd TC RHPs rcvd State changes

3 0 0 4

Syntax: show metro [<ring-id>]

This display shows the following information.

This Field...

Ring id

State

Ring role

Master vlan

Topo group

Hello time

Table 8.4: CLI Display of MRP Ring Information

Displays...

The ring ID

The state of MRP. The state can be one of the following:

• enabled – MRP is enabled

• disabled – MRP is disabled

Whether this node is the master for the ring. The role can be one of the following:

• master

• member

The ID of the master VLAN in the topology group used by this ring. If a topology group is used by MRP, the master VLAN controls the MRP settings for all VLANs in the topology group.

Note : The topology group ID is 0 if the MRP VLAN is not the master

VLAN in a topology group. Using a topology group for MRP configuration is optional.

The topology group ID.

The interval, in milliseconds, at which the Forwarding port on the ring’s master node sends Ring Hello Packets (RHPs).

8 - 14 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

This Field...

Prefwing time

Ring interfaces

Interface role

Forwarding state

Active interface

Interface Type

RHPs sent

Table 8.4: CLI Display of MRP Ring Information (Continued)

Displays...

The number of milliseconds an MRP interface that has entered the

Preforwarding state will wait before changing to the Forwarding state.

If a member port in the Preforwarding state does not receive an RHP within the Preforwarding time (Prefwing time), the port assumes that a topology change has occurred and changes to the Forwarding state.

The secondary port on the Master node changes to Blocking if it receives an RHP, but changes to Forwarding if the port does not receive an RHP before the preforwarding time expires.

Note : A member node’s Preforwarding interface also changes from

Preforwarding to Forwarding if it receives an RHP whose forwarding bit is on.

The device’s two interfaces with the ring.

Note : If the interfaces are trunk groups, only the primary ports of the groups are listed.

The interface role can be one of the following:

• primary

• Master node – The interface generates RHPs.

• Member node – The interface forwards RHPs received on the other interface (the secondary interface).

• secondary – The interface does not generate RHPs.

• Master node – The interface listens for RHPs.

• Member node – The interface receives RHPs.

Whether MRP Forwarding is enabled on the interface. The forwarding state can be one of the following:

• blocking – The interface is blocking Layer 2 data traffic and RHPs

• disabled – The interface is down

• forwarding – The interface is forwarding Layer 2 data traffic and

RHPs

• preforwarding – The interface is listening for RHPs but is blocking

Layer 2 data traffic

The physical interfaces that are sending and receiving RHPs.

Note : If a port is disabled, its state is shown as “disabled”.

Note : If an interface is a trunk group, only the primary port of the group is listed.

Shows if the interface is a regular port or a tunnel port.

The number of RHPs sent on the interface.

Note : This field applies only to the master node. On non-master nodes, this field contains 0. This is because the RHPs are forwarded in hardware on the non-master nodes.

December 2005 © Foundry Networks, Inc.

8 - 15

Foundry Configuration Guide for the FESX, FSX, and FWSX

This Field...

RHPs rcvd

TC RHPs rcvd

State changes

Table 8.4: CLI Display of MRP Ring Information (Continued)

Displays...

The number of RHPs received on the interface.

Note : On most Foundry devices, this field applies only to the master node. On non-master nodes, this field contains 0. This is because the RHPs are forwarded in hardware on the non-master nodes.

However, on the FastIron devices, the RHP received counter on nonmaster MRP nodes increment. This is because, on FastIron devices, the CPU receives a copy of the RHPs forwarded in hardware.

The number of Topology Change RHPs received on the interface. A

Topology Change RHP indicates that the ring topology has changed.

The number of MRP interface state changes that have occurred. The state can be one of the states listed in the Forwarding state field.

MRP CLI Example

The following examples show the CLI commands required to implement the MRP configuration shown in Figure

8.6 on page 8-10.

NOTE: For simplicity, the figure shows the VLANs on only two switches. The CLI examples implement the ring on all four switches.

Commands on Switch A (Master Node)

The following commands configure a VLAN for the ring. The ring VLAN must contain both of the node’s interfaces with the ring. Add these interfaces as tagged interfaces, since the interfaces also must be in each of the customer

VLANs configured on the node.

FastIron SuperX Router(config)# vlan 2

FastIron SuperX Router(config-vlan-2)# tag ethernet 1/1 to 1/2

FastIron SuperX Router(config-vlan-2)# metro-ring 1

FastIron SuperX Router(config-vlan-2-mrp-1)# name “Metro A”

FastIron SuperX Router(config-vlan-2-mrp-1)# master

FastIron SuperX Router(config-vlan-2-mrp-1)# ring-interface ethernet 1/1 ethernet 1/

2

FastIron SuperX Router(config-vlan-2-mrp-1)# enable

FastIron SuperX Router(config-vlan-2-mrp-1)# exit

FastIron SuperX Router(config-vlan-2)# exit

The following commands configure the customer VLANs. The customer VLANs must contain both the ring interfaces as well as the customer interfaces.

FastIron SuperX Router(config)# vlan 30

FastIron SuperX Router(config-vlan-30)# tag ethernet 1/1 to 1/2

FastIron SuperX Router(config-vlan-30)# tag ethernet 2/1

FastIron SuperX Router(config-vlan-30)# exit

FastIron SuperX Router(config)# vlan 40

FastIron SuperX Router(config-vlan-40)# tag ethernet 1/1 to 1/2

FastIron SuperX Router(config-vlan-40)# tag ethernet 4/1

FastIron SuperX Router(config-vlan-40)# exit

The following commands configure topology group 1 on VLAN 2. The master VLAN is the one that contains the

MRP configuration. The member VLANs use the MRP parameters of the master VLAN. The control interfaces

(the ones shared by the master VLAN and member VLAN) also share MRP state.

FastIron SuperX Router(config)# topology-group 1

FastIron SuperX Router(config-topo-group-1)# master-vlan 2

8 - 16 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

FastIron SuperX Router(config-topo-group-1)# member-vlan 30

FastIron SuperX Router(config-topo-group-1)# member-vlan 40

Commands on Switch B

The commands for configuring Switches B, C, and D are similar to the commands for configuring Switch A, with two differences: the nodes are not configured to be the ring master. Omitting the master command is required for non-master nodes.

FastIron SuperX Router(config)# vlan 2

FastIron SuperX Router(config-vlan-2)# tag ethernet 1/1 to 1/2

FastIron SuperX Router(config-vlan-2)# metro-ring 1

FastIron SuperX Router(config-vlan-2-mrp-1)# name “Metro A”

FastIron SuperX Router(config-vlan-2-mrp-1)# ring-interface ethernet 1/1 ethernet 1/

2

FastIron SuperX Router(config-vlan-2-mrp-1)# enable

FastIron SuperX Router(config-vlan-2)# exit

FastIron SuperX Router(config)# vlan 30

FastIron SuperX Router(config-vlan-30)# tag ethernet 1/1 to 1/2

FastIron SuperX Router(config-vlan-30)# tag ethernet 2/1

FastIron SuperX Router(config-vlan-30)# exit

FastIron SuperX Router(config)# vlan 40

FastIron SuperX Router(config-vlan-40)# tag ethernet 1/1 to 1/2

FastIron SuperX Router(config-vlan-40)# tag ethernet 4/1

FastIron SuperX Router(config-vlan-40)# exit

FastIron SuperX Router(config)# topology-group 1

FastIron SuperX Router(config-topo-group-1)# master-vlan 2

FastIron SuperX Router(config-topo-group-1)# member-vlan 30

FastIron SuperX Router(config-topo-group-1)# member-vlan 40

Commands on Switch C

FastIron SuperX Router(config)# vlan 2

FastIron SuperX Router(config-vlan-2)# tag ethernet 1/1 to 1/2

FastIron SuperX Router(config-vlan-2)# metro-ring 1

FastIron SuperX Router(config-vlan-2-mrp-1)# name “Metro A”

FastIron SuperX Router(config-vlan-2-mrp-1)# ring-interface ethernet 1/1 ethernet 1/

2

FastIron SuperX Router(config-vlan-2-mrp-1)# enable

FastIron SuperX Router(config-vlan-2)# exit

FastIron SuperX Router(config)# vlan 30

FastIron SuperX Router(config-vlan-30)# tag ethernet 1/1 to 1/2

FastIron SuperX Router(config-vlan-30)# tag ethernet 2/1

FastIron SuperX Router(config-vlan-30)# exit

FastIron SuperX Router(config)# vlan 40

FastIron SuperX Router(config-vlan-40)# tag ethernet 1/1 to 1/2

FastIron SuperX Router(config-vlan-40)# tag ethernet 4/1

FastIron SuperX Router(config-vlan-40)# exit

FastIron SuperX Router(config)# topology-group 1

FastIron SuperX Router(config-topo-group-1)# master-vlan 2

FastIron SuperX Router(config-topo-group-1)# member-vlan 30

FastIron SuperX Router(config-topo-group-1)# member-vlan 40

Commands on Switch D

FastIron SuperX Router(config)# vlan 2

FastIron SuperX Router(config-vlan-2)# tag ethernet 1/1 to 1/2

FastIron SuperX Router(config-vlan-2)# metro-ring 1

FastIron SuperX Router(config-vlan-2-mrp-1)# name “Metro A”

December 2005 © Foundry Networks, Inc.

8 - 17

Foundry Configuration Guide for the FESX, FSX, and FWSX

FastIron SuperX Router(config-vlan-2-mrp-1)# ring-interface ethernet 1/1 ethernet 1/

2

FastIron SuperX Router(config-vlan-2-mrp-1)# enable

FastIron SuperX Router(config-vlan-2)# exit

FastIron SuperX Router(config)# vlan 30

FastIron SuperX Router(config-vlan-30)# tag ethernet 1/1 to 1/2

FastIron SuperX Router(config-vlan-30)# tag ethernet 2/1

FastIron SuperX Router(config-vlan-30)# exit

FastIron SuperX Router(config)# vlan 40

FastIron SuperX Router(config-vlan-40)# tag ethernet 1/1 to 1/2

FastIron SuperX Router(config-vlan-40)# tag ethernet 4/1

FastIron SuperX Router(config-vlan-40)# exit

FastIron SuperX Router(config)# topology-group 1

FastIron SuperX Router(config-topo-group-1)# master-vlan 2

FastIron SuperX Router(config-topo-group-1)# member-vlan 30

FastIron SuperX Router(config-topo-group-1)# member-vlan 40

Virtual Switch Redundancy Protocol (VSRP)

Virtual Switch Redundancy Protocol (VSRP) is a Foundry proprietary protocol that provides redundancy and subsecond failover in Layer 2 and Layer 3 mesh topologies. Based on the Foundry Virtual Router Redundancy

Protocol Extended (VRRPE), VSRP provides one or more backups for a Layer 2 Switch or Layer 3 Switch. If the active Layer 2 Switch or Layer 3 Switch becomes unavailable, one of the backups takes over as the active device and continues forwarding traffic for the network.

The FastIron family of switches support full VSRP as well as VSRP-awareness . A Foundry device that is not itself configured for VSRP but is connected to a Foundry device that is configured for VSRP, is VSRP aware .

You can use VSRP for Layer 2, Layer 3, or for both layers. On Layer 3 Switches, Layer 2 and Layer 3 share the same VSRP configuration information. On Layer 2 Switches, VSRP applies only to Layer 2.

NOTE: VSRP and 802.1Q-n-Q tagging are not supported together on the same device.

Figure 8.7 shows an example of a VSRP configuration.

8 - 18 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

Figure 8.7

VSRP mesh – redundant paths for Layer 2 and Layer 3 traffic

F

VSRP

Master

F F optional link

B

VSRP

Backup

B B

VSRP

Aware

VSRP

Aware

VSRP

Aware

Hello packets

In this example, two Foundry devices are configured as redundant paths for VRID 1. On each of the devices, a

Virtual Router ID (VRID) is configured on a port-based VLAN. Since VSRP is primarily a Layer 2 redundancy protocol, the VRID applies to the entire VLAN. However, you can selectively remove individual ports from the

VRID if needed.

Following Master election (described below), one of the Foundry devices becomes the Master for the VRID and sets the state of all the VLAN’s ports to Forwarding. The other device is a Backup and sets all the ports in its VRID

VLAN to Blocking.

If a failover occurs, the Backup becomes the new Master and changes all its VRID ports to the Forwarding state.

Other Foundry devices can use the redundant paths provided by the VSRP devices. In this example, three

Foundry devices use the redundant paths. A Foundry device that is not itself configured for VSRP but is connected to a Foundry device that is configured for VSRP, is VSRP aware . In this example, the three Foundry devices connected to the VSRP devices are VSRP aware. A Foundry device that is VSRP aware can failover its link to the new Master in sub-second time, by changing the MAC address associated with the redundant path.

When you configure VSRP, make sure each of the non-VSRP Foundry devices connected to the VSRP devices has a separate link to each of the VSRP devices.

Layer 2 and Layer 3 Redundancy

You can configure VSRP to provide redundancy for Layer 2 only or also for Layer 3.

• Layer 2 only – The Layer 2 links are backup up but specific IP addresses are not backed up.

• Layer 2 and Layer 3 – The Layer 2 links are backup up and a specific IP address is also backed up. Layer 3

VSRP is the same as VRRPE. However, using VSRP provides redundancy at both layers at the same time.

Layer 2 Switches support Layer 2 VSRP only. Layer 3 Switches support Layer 2 and Layer 3 redundancy. You can configure a Layer 3 Switch for either Layer 2 only or Layer 2 and Layer 3. To configure for Layer 3, specify the

IP address you are backing up.

December 2005 © Foundry Networks, Inc.

8 - 19

Foundry Configuration Guide for the FESX, FSX, and FWSX

NOTE: If you want to provide Layer 3 redundancy only, disable VSRP and use VRRPE.

Master Election and Failover

Each VSRP device advertises its VSRP priority in Hello messages. During Master election, the VSRP device with the highest priority for a given VRID becomes the Master for that VRID. After Master election, the Master sends

Hello messages at regular intervals to inform the Backups that the Master is healthy.

If there is a tie for highest VSRP priority, the tie is resolved as follows:

• Layer 2 Switches – The Layer 2 Switch with the higher management IP address becomes the Master.

• Switches with management IP addresses are preferred over switches without management IP addresses.

• If neither of the switches has a management IP address, then the switch with the higher MAC address becomes the Master. (VSRP compares the MAC addresses of the ports configured for the VRID, not the base MAC addresses of the switches.)

• Layer 3 Switches – The Layer 3 Switch whose virtual routing interface has a higher IP address becomes the master.

VSRP Failover

Each Backup listens for Hello messages from the Master. The Hello messages indicate that the Master is still available. If the Backups stop receiving Hello messages from the Master, the election process occurs again and the Backup with the highest priority becomes the new Master.

Each Backup waits for a specific period of time, the Dead Interval, to receive a new Hello message from the

Master. If the Backup does not receive a Hello message from the Master by the time the Dead Interval expires, the Backup sends a Hello message of its own, which includes the Backup's VSRP priority, to advertise the

Backup's intent to become the Master. If there are multiple Backups for the VRID, each Backup sends a Hello message.

When a Backup sends a Hello message announcing its intent to become the Master, the Backup also starts a hold-down timer. During the hold-down time, the Backup listens for a Hello message with a higher priority than its own.

• If the Backup receives a Hello message with a higher priority than its own, the Backup resets its Dead Interval and returns to normal Backup status.

• If the Backup does not receive a Hello message with a higher priority than its own by the time the hold-down timer expires, the Backup becomes the new Master and starts forwarding Layer 2 traffic on all ports.

If you increase the timer scale value, each timer’s value is divided by the scale value. To achieve sub-second failover times, you can change the scale to a value up to 10. This shortens all the VSRP timers to 10 percent of their configured values.

VSRP Priority Calculation

Each VSRP device has a VSRP priority for each VRID and its VLAN. The VRID is used during Master election for the VRID. By default, a device’s VSRP priority is the value configured on the device (which is 100 by default).

However, to ensure that a Backup with a high number of up ports for a given VRID is elected, the device reduces the priority if a port in the VRID’s VLAN goes down. For example, if two Backups each have a configured priority of 100, and have three ports in VRID 1 in VLAN 10, each Backup begins with an equal priority, 100. This is shown in Figure 8.8

8 - 20 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

Figure 8.8

VSRP priority

Configured priority = 100

Actual priority = 100 * (3/3) = 100

F

VSRP

Master

F F

Configured priority = 100

Actual priority = 100 * (3/3) = 100 optional link

B

VSRP

Backup

B B

VSRP

Aware

VSRP

Aware

VSRP

Aware

However, if one of the VRID’s ports goes down on one of the Backups, that Backup’s priority is reduced. If the

Master’s priority is reduced enough to make the priority lower than a Backup’s priority, the VRID fails over to the

Backup. Figure 8.9 shows an example.

Figure 8.9

VSRP priority recalculation

Configured priority = 100

Actual priority = 100 * (2/3) = 67

Configured priority = 100

Actual priority = 100 * (3/3) = 100

Link down

VSRP

Backup

B

X

B B optional link

F

VSRP

Master

F F

VSRP

Aware

VSRP

Aware

VSRP

Aware

You can reduce the sensitivity of a VSRP device to failover by increasing its configured VSRP priority. For example, you can increase the configured priority of the VSRP device on the left in Figure 8.9 to 150. In this case, failure of a single link does not cause failover. The link failure caused the priority to be reduced to 100, which is still equal to the priority of the other device. This is shown in Figure 8.10.

December 2005 © Foundry Networks, Inc.

8 - 21

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 8.10

VSRP priority bias

Link down

Configured priority = 150

Actual priority = 150 * (2/3) = 100

VSRP

Master

F

X

F F

Configured priority = 100

Actual priority = 100 * (3/3) = 100 optional link

B

VSRP

Backup

B B

VSRP

Aware

VSRP

Aware

VSRP

Aware

Track Ports

Optionally, you can configure track ports to be included during VSRP priority calculation. In VSRP, a track port is a port that is not a member of the VRID’s VLAN, but whose state is nonetheless considered when the priority is calculated. Typically, a track port represents the exit side of traffic received on the VRID ports. By default, no track ports are configured.

When you configure a track port, you assign a priority value to the port. If the port goes down, VSRP subtracts the track port’s priority value from the configured VSRP priority. For example, if the you configure a track port with priority 20 and the configured VSRP priority is 100, the software subtracts 20 from 100 if the track port goes down, resulting in a VSRP priority of 80. The new priority value is used when calculating the VSRP priority. Figure 8.11 shows an example.

Figure 8.11

Track port priority

Configured priority = 100

Track priority 20

Actual priority = (100 - 0) * (3/3) = 100

Configured priority = 100

Actual priority = 100 * (3/3) = 100

F

VSRP

Master

F F optional link

B

VSRP

Backup

B B

Track port is up

VSRP

Aware

VSRP

Aware

VSRP

Aware

8 - 22 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

In Figure 8.11, the track port is up. SInce the port is up, the track priority does not affect the VSRP priority calculation. If the track port goes down, the track priority does affect VSRP priority calculation, as shown in Figure

8.12.

Figure 8.12

Track port priority subtracted during priority calculation

Configured priority = 100

Track priority 20

Actual priority = (100 - 20) * (3/3) = 80

Configured priority = 100

Actual priority = 100 * (3/3) = 100

F

VSRP

Master

F F

Track link is down

X

B

VSRP

Backup

B B optional link

VSRP

Aware

VSRP

Aware

VSRP

Aware

MAC Address Failover on VSRP-Aware Devices

VSRP-aware devices maintain a record of each VRID and its VLAN. When the device has received a Hello message for a VRID in a given VLAN, the device creates a record for that VRID and VLAN and includes the port number in the record. Each subsequent time the device receives a Hello message for the same VRID and VLAN, the device checks the port number.

• If the port number is the same as the port that previously received a Hello message, the VSRP-aware device assumes that the message came from the same VSRP Master that sent the previous message.

• If the port number does not match, the VSRP-aware device assumes that a VSRP failover has occurred to a new Master, and moves the MAC addresses learned on the previous port to the new port.

The VRID records age out if unused. This can occur if the VSRP-aware device becomes disconnected from the

Master. The VSRP-aware device will wait for a Hello message for the period of time equal to the following:

VRID Age = Dead Interval + Hold-down Interval + (3 x Hello Interval)

The values for these timers are determined by the VSRP device sending the Hello messages. If the Master uses the default timer values, the age time for VRID records on the VSRP-aware devices is as follows:

3 + 2 + (3 x 1) = 8 seconds

In this case, if the VSRP-aware device does not receive a new Hello message for a VRID in a given VLAN, on any port, the device assumes the connection to the Master is unavailable and removes the VRID record.

Timer Scale

The VSRP Hello interval, Dead interval, Backup Hello interval, and Hold-down interval timers are individually configurable. You also can easily change all the timers at the same time while preserving the ratios among their values. To do so, change the timer scale. The timer scale is a value used by the software to calculate the timers.

The software divides a timer’s value by the timer scale value. By default, the scale is 1. This means the VSRP timer values are the same as the values in the configuration.

December 2005 © Foundry Networks, Inc.

8 - 23

Foundry Configuration Guide for the FESX, FSX, and FWSX

VSRP-Aware Security Features

Without VSRP-aware security configured, a VSRP-aware device passively learns the authentication method conveyed by the received VSRP hello packet. The VSRP-aware device then stores the authentication method until it ages out with the aware entry.

With VSRP-aware security, you can:

• Define the specific authentication parameters that a VSRP-aware device will use on a VSRP backup switch.

The authentication parameters that you define will not age out.

• Define a list of ports that have authentic VSRP backup switch connections. For ports included in the list, the

VSRP-aware switch will process VSRP hello packets using the VSRP-aware security configuration.

Conversely, for ports not included in the list, the VSRP-aware switch will not use the VSRP-aware security configuration.

If VSRP hello packets do not meet the acceptance criteria, the VSRP-aware device forwards the packets normally, without any VSRP-aware security processing.

VSRP Parameters

Table 8.5 lists the VSRP parameters.

Table 8.5: VSRP Parameters

Parameter Description

Protocol

Virtual Router

ID (VRID)

Timer scale

VSRP state

Note : On a Layer 3 Switch, you must disable VSRP to use VRRPE or VRRP.

The ID of the virtual switch you are creating by configuring multiple devices as redundant links. You must configure the same VRID on each device that you want to use to back up the links.

The value used by the software to calculate all VSRP timers. Increasing the timer scale value decreases the length of all the VSRP timers equally, without changing the ratio of one timer to another.

Interface Parameters

Authentication type

The type of authentication the VSRP devices use to validate VSRP packets. On Layer 3 Switches, the authentication type must match the authentication type the VRID’s port uses with other routing protocols such as OSPF.

• No authentication – The interfaces do not use authentication. This is the VRRP default.

• Simple – The interface uses a simple text-string as a password in packets sent on the interface. If the interface uses simple password authentication, the VRID configured on the interface must use the same authentication type and the same password.

Note : MD5 is not supported.

Default

Enabled

None

1

No authentication

See page...

8-28

8-27

8-28

8-29

8 - 24 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

Table 8.5: VSRP Parameters (Continued)

Parameter Description

VSRP-Aware Security Parameters

VSRP-Aware

Authentication type

The type of authentication the VSRP-aware devices will use on a VSRP backup switch.

• No authentication – The device does not accept incoming packets that have authentication strings.

• Simple – The device uses a simple text-string as the authentication string for accepting incoming packets.

VRID Parameters

VSRP device type

Whether the device is a VSRP Backup for the VRID.

All VSRP devices for a given VRID are Backups.

VSRP ports

VRID IP address

The ports in the VRID’s VLAN that you want to use as

VRID interfaces. You can selectively exclude individual ports from VSRP while allowing them to remain in the VLAN.

A gateway address you are backing up. Configuring an IP address provides VRRPE Layer 3 redundancy in addition to VSRP LAyer 2 redundancy.

The VRID IP address must be in the same subnet as a real IP address configured on the VSRP interface, but cannot be the same as a real IP address configured on the interface.

Note : This parameter is valid only on Layer 3

Switches.

Backup priority

Preference of timer source

A numeric value that determines a Backup’s preferability for becoming the Master for the VRID.

During negotiation, the device with the highest priority becomes the Master.

In VSRP, all devices are Backups and have the same priority by default.

If two or more Backups are tied with the highest priority, the Backup with the highest IP address becomes the Master for the VRID.

When you save a Backup’s configuration, the software can save the configured VSRP timer values or the VSRP timer values received from the Master.

Saving the current timer values instead of the configured ones helps ensure consistent timer usage for all the VRID’s devices.

Note : The Backup always gets its timer scale value from the Master.

Default

Not configured

Not configured

All ports in the VRID’s

VLAN

None

100 for all Backups

Configured timer values are saved

See page...

8-29

8-27

8-30

8-30

8-30

8-31

December 2005 © Foundry Networks, Inc.

8 - 25

Foundry Configuration Guide for the FESX, FSX, and FWSX

Table 8.5: VSRP Parameters (Continued)

Parameter Description

Time-to-Live

(TTL)

Hello interval

Dead interval

Backup Hello state and interval

Hold-down interval

Track priority

Track port

Backup preempt mode

VRID active state

The maximum number of hops a VSRP Hello packet can traverse before being dropped. You can specify from 1 – 255.

The amount of time between Hello messages from the Master to the Backups for a given VRID.

The interval can be from 1 – 84 seconds.

The amount of time a Backup waits for a Hello message from the Master for the VRID before determining that the Master is no longer active.

If the Master does not send a Hello message before the dead interval expires, the Backups negotiate

(compare priorities) to select a new Master for the

VRID.

The amount of time between Hello messages from a

Backup to the Master.

The message interval can be from 60 – 3600 seconds.

You must enable the Backup to send the messages.

The messages are disabled by default on Backups.

The current Master sends Hello messages by default.

The amount of time a Backup that has sent a Hello packet announcing its intent to become Master waits before beginning to forward traffic for the VRID. The hold-down interval prevents Layer 2 loops from occurring during VSRP’s rapid failover.

The interval can from 1 – 84 seconds.

A VSRP priority value assigned to the tracked port(s).

If a tracked port’s link goes down, the VRID port’s

VSRP priority is reduced by the amount of the tracked port’s priority.

A track port is a port or virtual routing interface that is outside the VRID but whose link state is tracked by the VRID. Typically, the tracked interface represents the other side of VRID traffic flow through the device.

If the link for a tracked interface goes down, the VSRP priority of the VRID interface is changed, causing the devices to renegotiate for Master.

Prevents a Backup with a higher VSRP priority from taking control of the VRID from another Backup that has a lower priority but has already assumed control of the VRID.

The active state of the VSRP VRID.

Default

2

One second

Three times the Hello

Interval

Disabled

60 seconds when enabled

2 seconds

5

None

Enabled

Disabled

See page...

8-31

8-32

8-32

8-32

8-32

8-33

8-33

8-33

8-27

8 - 26 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

Table 8.5: VSRP Parameters (Continued)

Parameter Description

RIP Parameters

Suppression of

RIP advertisements

A Layer 3 Switch that is running RIP normally advertises routes to a backed up VRID even when the

Layer 3 Switch is not currently the active Layer 3

Switch for the VRID. Suppression of these advertisements helps ensure that other Layer 3

Switches do not receive invalid route paths for the

VRID.

Note : This parameter is valid only on Layer 3

Switches.

Default See page...

Disabled

(routes are advertised)

8-34

Configuring Basic VSRP Parameters

To configure VSRP, perform the following required tasks:

• Configure a port-based VLAN containing the ports for which you want to provide VSRP service.

NOTE: If you already have a port-based VLAN but only want to use VSRP on a sub-set of the VLANs ports, you can selectively remove ports from VSRP service in the VLAN. See “Removing a Port from the VRID’s

VLAN” on page 8-30.

• Configure a VRID.

• Specify that the device is a backup. Since VSRP, like VRRPE, does not have an “owner”, all VSRP devices are backups. The active device for a VRID is elected based on the VRID priority, which is configurable.

• Activate the VRID.

The following example shows a simple VSRP configuration.

FastIron SuperX Router(config)# vlan 200

FastIron SuperX Router(config-vlan-200)# tag ethernet 1/1 to 1/8

FastIron SuperX Router(config-vlan-200)# vsrp vrid 1

FastIron SuperX Router(config-vlan-200-vrid-1)# backup

FastIron SuperX Router(config-vlan-200-vrid-1)# activate

Syntax: [no] vsrp vrid <num>

The <num> parameter specifies the VRID and can be from 1 – 255.

Syntax: [no] backup [priority <value>] [track-priority <value>]

This command is required. In VSRP, all devices on which a VRID are configured are Backups. The Master is then elected based on the VSRP priority of each device. There is no “owner” device as there is in VRRP.

For information about the command’s optional parameters, see the following:

• “Changing the Backup Priority” on page 8-30

• “Changing the Default Track Priority” on page 8-33

Syntax: [no] activate or

Syntax: enable | disable

December 2005 © Foundry Networks, Inc.

8 - 27

Foundry Configuration Guide for the FESX, FSX, and FWSX

Configuring Optional VSRP Parameters

The following sections describe how to configure optional VSRP parameters.

Disabling or Re-Enabling VSRP

VSRP is enabled by default on Layer 2 Switches and Layer 3 Switches. On a Layer 3 Switch, if you want to use

VRRP or VRRPE for Layer 3 redundancy instead of VSRP, you need to disable VSRP first. To do so, enter the following command at the global CONFIG level:

FastIron SuperX Router(config)# no router vsrp router vsrp is disabled. All vsrp config data will be lost when writing to flash

To re-enable the protocol, enter the following command:

FastIron SuperX Router(config)# router vsrp

Syntax: [no] router vsrp

Since VRRP and VRRPE do not apply to Layer 2 Switches, there is no need to disable VSRP and there is no command to do so. The protocol is always enabled.

Changing the Timer Scale

To achieve sub-second failover times, you can shorten the duration of all VSRP timers by adjusting the timer scale.

The timer scale is a value used by the software to calculate the timers. By default, the scale value is 1. If you increase the timer scale, each timer’s value is divided by the scale value. Using the timer scale to adjust VSRP timer values enables you to easily change all the timers while preserving the ratios among their values. Here is an example.

Timer

Hello interval

Dead interval

Backup Hello interval

Hold-down interval

Timer Scale

2

1

2

1

2

1

2

1

Timer Value

1 second

0.5 seconds

3 seconds

1.5 seconds

60 seconds

30 seconds

2 seconds

1 second

If you configure the device to receive its timer values from the Master, the Backup also receives the timer scale value from the Master.

NOTE: The Backups always use the value of the timer scale received from the Master, regardless of whether the timer values that are saved in the configuration are the values configured on the Backup or the values received from the Master.

To change the timer scale, enter a command such as the following at the global CONFIG level of the CLI:

FastIron SuperX Router(config)# scale-timer 2

This command changes the scale to 2. All VSRP timer values will be divided by 2.

Syntax: [no] scale-timer <num>

The <num> parameter specifies the multiplier. You can specify a timer scale from 1 – 10.

8 - 28 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

Configuring Authentication

If the interfaces on which you configure the VRID use authentication, the VSRP packets on those interfaces also must use the same authentication. VSRP supports the following authentication types:

• No authentication – The interfaces do not use authentication. This is the default.

• Simple – The interfaces use a simple text-string as a password in packets sent on the interface. If the interfaces use simple password authentication, the VRID configured on the interfaces must use the same authentication type and the same password.

To configure a simple password, enter a command such as the following at the interface configuration level:

FastIron SuperX Router(config-if-1/6)# ip vsrp auth-type simple-text-auth ourpword

This command configures the simple text password “ourpword”.

Syntax: [no] ip vsrp auth-type no-auth | simple-text-auth <auth-data>

The auth-type no-auth parameter indicates that the VRID and the interface it is configured on do not use authentication.

The auth-type simple-text-auth <auth-data> parameter indicates that the VRID and the interface it is configured on use a simple text password for authentication. The <auth-data> value is the password. If you use this parameter, make sure all interfaces on all the devices supporting this VRID are configured for simple password authentication and use the same password.

Configuring Security Features on a VSRP-Aware Device

The VSRP-aware security feature enables you to:

• Define the specific authentication parameters that a VSRP-aware device will use on a VSRP backup switch.

The authentication parameters that you define will not age out.

• Define a list of ports that have authentic VSRP backup switch connections. For ports included in the list, the

VSRP-aware switch will process VSRP hello packets using the VSRP-aware security configuration.

Conversely, for ports not included in the list, the VSRP-aware switch will not use the VSRP-aware security configuration.

If VSRP hello packets do not meet the acceptance criteria, the VSRP-aware device forwards the packets normally, without any VSRP-aware security processing.

Specifying an Authentication String for VSRP Hello Packets

The following configuration defines pri-key as the authentication string for accepting incoming VSRP hello packets. In this example, the VSRP-aware device will accept all incoming packets that have this authorization string.

FastIron SuperX Router(config)# vlan 10

FastIron SuperX Router(config-vlan-10)# vsrp-aware vrid 3 simple-text-auth pri-key

Syntax: vsrp-aware vrid <vrid number> simple text auth <string>

Specifying no Authentication for VSRP Hello Packets

The following configuration specifies no authentication as the preferred VSRP-aware security method. In this case, the VSRP device will not accept incoming packets that have authentication strings.

FastIron SuperX Router(config)# vlan 10

FastIron SuperX Router(config-vlan-10)# vsrp-aware vrid 2 no-auth

Syntax: vsrp-aware vrid <vrid number> no-auth

The following configuration specifies no authentication for VSRP hello packets received on ports 1/1, 1/2, 1/3, and

1/4 in VRID 4. For these ports, the VSRP device will not accept incoming packets that have authentication strings.

FastIron SuperX Router(config)# vlan 10

FastIron SuperX Router(config-vlan-10)# vsrp-aware vrid 4 no-auth port-list ethe 1/

1 to 1/4

Syntax: vsrp-aware vrid <vrid number> no-auth port-list <port range>

December 2005 © Foundry Networks, Inc.

8 - 29

Foundry Configuration Guide for the FESX, FSX, and FWSX

<vrid number> is a valid VRID (from 1 to 255).

no-auth specifies no authentication as the preferred VSRP-aware security method. The VSRP device will not accept incoming packets that have authentication strings.

simple-text-auth <string> specifies the authentication string for accepting VSRP hello packets, where <string> can be up to 8 characters.

port-list <port range> specifies the range of ports to include in the configuration.

Removing a Port from the VRID’s VLAN

By default, all the ports in the VLAN on which you configure a VRID are interfaces for the VRID. You can remove a port from the VRID while allowing it to remain in the VLAN.

Removing a port is useful in the following cases:

• There is no risk of a loop occurring, such as when the port is attached directly to an end host.

• You plan to use a port in an MRP ring.

To remove a port from a VRID, enter a command such as the following at the configuration level for the VRID:

FastIron SuperX Router(config-vlan-200-vrid-1)# no include-port ethernet 1/2

Syntax: [no] include-port ethernet [<slotnum>/]<portnum>

The <slotnum> parameter is required on chassis devices.

The <portnum> parameter specifies the port you are removing from the VRID. The port remains in the VLAN but its forwarding state is not controlled by VSRP. If you are configuring a chassis device, specify the slot number as well as the port number (<slotnum>/<portnum>).

Configuring a VRID IP Address

If you are configuring a Layer 3 Switch for VSRP, you can specify an IP address to back up. When you specify an

IP address, VSRP provides redundancy for the address. This is useful if you want to back up the gateway address used by hosts attached to the VSRP Backups.

VSRP does not require you to specify an IP address. If you do not specify an address, VSRP provides Layer 2 redundancy. If you do specify an address, VSRP provides Layer 2 and Layer 3 redundancy.

The Layer 3 redundancy support is the same as VRRPE support. For information, see the chapter “Configuring

VRRP and VRRPE” on page 22-1.

NOTE: The VRID IP address must be in the same subnet as a real IP address configured on the VSRP interface, but cannot be the same as a real IP address configured on the interface.

NOTE: Failover applies to both Layer 2 and Layer 3.

To specify an IP address to back up, enter a command such as the following at the configuration level for the

VRID:

FastIron SuperX Router(config-vlan-200-vrid-1)# ip-address 10.10.10.1

Syntax: [no] ip-address <ip-addr> or

Syntax: [no] ip address <ip-addr>

Changing the Backup Priority

When you enter the backup command to configure the device as a VSRP Backup for the VRID, you also can change the backup priority and the track priority.

• The backup priority is used for election of the Master. The VSRP Backup with the highest priority value for the

VRID is elected as the Master for that VRID. The default priority is 100. If two or more Backups are tied with

8 - 30 © Foundry Networks, Inc.

December 2005

Configuring Metro Features the highest priority, the Backup with the highest IP address becomes the Master for the VRID.

• The track priority is used with the track port feature. See “VSRP Priority Calculation” on page 8-20 and

“Changing the Default Track Priority” on page 8-33.

To change the backup priority, enter a command such as the following at the configuration level for the VRID:

FastIron SuperX Router(config-vlan-200-vrid-1)# backup priority 75

Syntax: [no] backup [priority <value>] [track-priority <value>]

The priority <value> parameter specifies the VRRP priority for this interface and VRID. You can specify a value from 3 – 254. The default is 100.

For a description of the track-priority <value> parameter, see “Changing the Default Track Priority” on page 8-33.

Saving the Timer Values Received from the Master

The Hello messages sent by a VRID’s master contain the VRID values for the following VSRP timers:

• Hello interval

• Dead interval

• Backup Hello interval

• Hold-down interval

By default, each Backup saves the configured timer values to its startup-config file when you save the device’s configuration.

You can configure a Backup to instead save the current timer values received from the Master when you save the configuration. Saving the current timer values instead of the configured ones helps ensure consistent timer usage for all the VRID’s devices.

NOTE: The Backups always use the value of the timer scale received from the Master, regardless of whether the timer values that are saved in the configuration are the values configured on the Backup or the values received from the Master.

To configure a Backup to save the VSRP timer values received from the Master instead of the timer values configured on the Backup, enter the following command:

FastIron SuperX Router(config-vlan-200-vrid-1)# save-current-values

Syntax: [no] save-current-values

Changing the Time-To-Live (TTL)

A VSRP Hello packet’s TTL specifies how many hops the packet can traverse before being dropped. A hop can be a Layer 3 Switch or a Layer 2 Switch. You can specify from 1 – 255. The default TTL is 2. When a VSRP device

(Master or Backup) sends a VSRP HEllo packet, the device subtracts one from the TTL. Thus, if the TTL is 2, the device that originates the Hello packet sends it out with a TTL of 1. Each subsequent device that receives the packet also subtracts one from the packet’s TTL. When the packet has a TTL of 1, the receiving device subtracts 1 and then drops the packet because the TTL is zero.

NOTE: An MRP ring is considered to be a single hop, regardless of the number of nodes in the ring.

To change the TTL for a VRID, enter a command such as the following at the configuration level for the VRID:

FastIron SuperX Router(config-vlan-200-vrid-1)# initial-ttl 5

Syntax: [no] initial-ttl <num>

The <num> parameter specifies the TTL and can be from 1 – 255. The default TTL is 2.

December 2005 © Foundry Networks, Inc.

8 - 31

Foundry Configuration Guide for the FESX, FSX, and FWSX

Changing the Hello Interval

The Master periodically sends Hello messages to the Backups. To change the Hello interval, enter a command such as the following at the configuration level for the VRID:

FastIron SuperX Router(config-vlan-200-vrid-1)# hello-interval 10

Syntax: [no] hello-interval <num>

The <num> parameter specifies the interval and can be from 1 – 84 seconds. The default is 1 second.

NOTE: The default Dead interval is three times the Hello interval plus one-half second. Generally, if you change the Hello interval, you also should change the Dead interval on the Backups.

NOTE: If you change the timer scale, the change affects the actual number of seconds.

Changing the Dead Interval

The Dead interval is the number of seconds a Backup waits for a Hello message from the Master before determining that the Master is dead. The default is 3 seconds. This is three times the default Hello interval.

To change the Dead interval, enter a command such as the following at the configuration level for the VRID:

FastIron SuperX Router(config-vlan-200-vrid-1)# dead-interval 30

Syntax: [no] dead-interval <num>

The <num> parameter specifies the interval and can be from 1 – 84 seconds. The default is 3 seconds.

NOTE: If you change the timer scale, the change affects the actual number of seconds.

Changing the Backup Hello State and Interval

By default, Backups do not send Hello messages to advertise themselves to the Master. You can enable these messages if desired and also change the message interval.

To enable a Backup to send Hello messages to the Master, enter a command such as the following at the configuration level for the VRID:

FastIron SuperX Router(config-vlan-200-vrid-1)# advertise backup

Syntax: [no] advertise backup

When a Backup is enabled to send Hello messages, the Backup sends a Hello message to the Master every 60 seconds by default. You can change the interval to be up to 3600 seconds.

To change the Backup Hello interval, enter a command such as the following at the configuration level for the

VRID:

FastIron SuperX Router(config-vlan-200-vrid-1)# backup-hello-interval 180

Syntax: [no] backup-hello-interval <num>

The <num> parameter specifies the message interval and can be from 60 – 3600 seconds. The default is 60 seconds.

NOTE: If you change the timer scale, the change affects the actual number of seconds.

Changing the Hold-Down Interval

The hold-down interval prevents Layer 2 loops from occurring during failover, by delaying the new Master from forwarding traffic long enough to ensure that the failed Master is really unavailable.

To change the Hold-down interval, enter a command such as the following at the configuration level for the VRID:

FastIron SuperX Router(config-vlan-200-vrid-1)# hold-down-interval 4

8 - 32 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

Syntax: [no] hold-down-interval <num>

The <num> parameter specifies the hold-down interval and can be from 1 – 84 seconds. The default is 2 seconds.

NOTE: If you change the timer scale, the change affects the actual number of seconds.

Changing the Default Track Priority

When you configure a VRID to track the link state of other interfaces, if one of the tracked interface goes down, the software changes the VSRP priority of the VRID interface.

The software reduces the VRID priority by the amount of the priority of the tracked interface that went down. For example, if the VSRP interface’s priority is 100 and a tracked interface with track priority 60 goes down, the software changes the VSRP interface’s priority to 40. If another tracked interface goes down, the software reduces the VRID’s priority again, by the amount of the tracked interface’s track priority.

The default track priority for all track ports is 1. You can change the default track priority or override the default for an individual track port.

• To change the default track priority, use the backup track-priority command, described below.

• To override the default track priority for a specific track port, use the track-port command. See “Specifying a

Track Port” on page 8-33.

To change the track priority, enter a command such as the following at the configuration level for the VRID:

FastIron SuperX Router(config-vlan-200-vrid-1)# backup track-priority 2

Syntax: [no] backup [priority <value>] [track-priority <value>]

Specifying a Track Port

You can configure the VRID on one interface to track the link state of another interface on the device. This capability is useful for tracking the state of the exit interface for the path for which the VRID is providing redundancy. See “VSRP Priority Calculation” on page 8-20.

To configure a VRID to track an interface, enter a command such as the following at the configuration level for the

VRID:

FastIron SuperX Router(config-vlan-200-vrid-1)# track-port e 2/4

Syntax: [no] track-port ethernet [<slotnum>/]<portnum> | ve <num> [priority <num>]

The priority <num> parameter changes the VSRP priority of the interface. If this interface goes down, the VRID’s

VSRP priority is reduced by the amount of the track port priority you specify here.

NOTE: The priority <num> option changes the priority of the specified interface, overriding the default track port priority. To change the default track port priority, use the backup track-priority <num> command.

Disabling or Re-Enabling Backup Pre-Emption

By default, a Backup that has a higher priority than another Backup that has become the Master can preempt the

Master, and take over the role of Master. If you want to prevent this behavior, disable preemption.

Preemption applies only to Backups and takes effect only when the Master has failed and a Backup has assumed ownership of the VRID. The feature prevents a Backup with a higher priority from taking over as Master from another Backup that has a lower priority but has already become the Master of the VRID.

Preemption is especially useful for preventing flapping in situations where there are multiple Backups and a

Backup with a lower priority than another Backup has assumed ownership, because the Backup with the higher priority was unavailable when ownership changed.

If you enable the non-preempt mode (thus disabling the preemption feature) on all the Backups, the Backup that becomes the Master following the disappearance of the Master continues to be the Master. The new Master is not preempted.

December 2005 © Foundry Networks, Inc.

8 - 33

Foundry Configuration Guide for the FESX, FSX, and FWSX

To disable preemption on a Backup, enter a command such as the following at the configuration level for the VRID:

FastIron SuperX Router(config-vlan-200-vrid-1)# non-preempt-mode

Syntax: [no] non-preempt-mode

Suppressing RIP Advertisement from Backups

Normally, for Layer 3 a VSRP Backup includes route information for a backed up IP address in RIP advertisements. As a result, other Layer 3 Switches receive multiple paths for the backed up interface and might sometimes unsuccessfully use the path to the Backup rather than the path to the Master.

You can prevent the Backups from advertising route information for the backed up interface by enabling suppression of the advertisements.

NOTE: This parameter applies only if you specified an IP address to back up and is valid only on Layer 3

Switches.

To suppress RIP advertisements, enter the following commands:

Router2(config)# router rip

Router2(config-rip-router)# use-vrrp-path

Syntax: [no] use-vrrp-path

Displaying VSRP Information

You can display the following VSRP information:

• Configuration information and current parameter values for a VRID or VLAN

• The interfaces on a VSRP-aware device that are active for the VRID

Displaying VRID Information

To display VSRP information, enter the following command:

FastIron SuperX Router (config-vlan-200-vrid-1)# show vsrp vrid 1

Total number of VSRP routers defined: 2

VLAN 200

auth-type no authentication

VRID 1

State Administrative-status Advertise-backup Preempt-mode save-current

standby enabled disabled true false

Parameter Configured Current Unit

priority 100 80 (100-0)*(4.0/5.0)

hello-interval 1 1 sec/1

dead-interval 3 3 sec/1

hold-interval 3 3 sec/1

initial-ttl 2 2 hops

next hello sent in 00:00:00.8

Member ports: ethe 1/1 to 1/5

Operational ports: ethe 1/1 to 1/4

Forwarding ports: ethe 1/1 to 1/4

Syntax: show vsrp [vrid <num> | vlan <vlan-id>]

8 - 34 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

This display shows the following information when you use the vrid <num> or vlan <vlan-id> parameter. For information about the display when you use the aware parameter, see “Displaying the Active Interfaces for a

VRID” on page 8-37.

This Field...

Table 8.6: CLI Display of VSRP VRID or VLAN Information

Displays...

The total number of VRIDs configured on this device. Total number of VSRP routers defined

VLAN auth-type

VRID parameters

VRID state

The VLAN on which VSRP is configured.

The authentication type in effect on the ports in the VSRP VLAN.

Administrative-status

Advertise-backup

Preempt-mode

The VRID for which the following information is displayed.

This device’s VSRP state for the VRID. The state can be one of the following:

• initialize – The VRID is not enabled (activated). If the state remains “initialize” after you activate the VRID, make sure that the

VRID is also configured on the other routers and that the routers can communicate with each other.

Note : If the state is “initialize” and the mode is incomplete, make sure you have specified the IP address for the VRID.

• standby – This device is a Backup for the VRID.

• master – This device is the Master for the VRID.

The administrative status of the VRID. The administrative status can be one of the following:

• disabled – The VRID is configured on the interface but VSRP or

VRRPE has not been activated on the interface.

• enabled – VSRP has been activated on the interface.

Whether the device is enabled to send VSRP Hello messages when it is a Backup. This field can have one of the following values:

• disabled – The device does not send Hello messages when it is a Backup.

• enabled – The device does send Hello messages when it is a

Backup.

Whether the device can be pre-empted by a device with a higher

VSRP priority after this device becomes the Master. This field can have one of the following values:

• disabled – The device cannot be pre-empted.

• enabled – The device can be pre-empted.

December 2005 © Foundry Networks, Inc.

8 - 35

Foundry Configuration Guide for the FESX, FSX, and FWSX

Table 8.6: CLI Display of VSRP VRID or VLAN Information (Continued)

This Field...

Displays...

save-current

Note : For the following fields:

• Configured – indicates the parameter value configured on this device.

• Current – indicates the parameter value received from the Master.

• Unit – indicates the formula used tor calculating the VSRP priority and the timer scales in effect for the

VSRP timers. A timer’s true value is the value listed in the Configured or Current field divided by the scale value.

priority

The source of VSRP timer values preferred when you save the configuration. This field can have one of the following values:

• false – The timer values configured on this device are saved.

• true – The timer values most recently received from the Master are saved instead of the locally configured values. hello-interval

The device’s preferability for becoming the Master for the VRID.

During negotiation, the Backup with the highest priority becomes the

Master.

If two or more Backups are tied with the highest priority, the Backup interface with the highest IP address becomes the Master for the

VRID.

The number of seconds between Hello messages from the Master to the Backups for a given VRID. dead-interval hold-interval initial-ttl next hello sent in

The configured value for the dead interval. The dead interval is the number of seconds a Backup waits for a Hello message from the

Master for the VRID before determining that the Master is no longer active.

If the Master does not send a Hello message before the dead interval expires, the Backups negotiate (compare priorities) to select a new

Master for the VRID.

Note : If the value is 0, then you have not configured this parameter.

The number of seconds a Backup that intends to become the Master will wait before actually beginning to forward Layer 2 traffic for the

VRID.

If the Backup receives a Hello message with a higher priority than its own before the hold-down interval expires, the Backup remains in the

Backup state and does not become the new Master.

The number of hops a Hello message can traverse after leaving the device before the Hello message is dropped.

Note : An MRP ring counts as one hop, regardless of the number of nodes in the ring.

The amount of time until the Master’s dead interval expires. If the

Backup does not receive a Hello message from the Master by the time the interval expires, either the IP address listed for the Master will change to the IP address of the new Master, or this Layer 3 Switch itself will become the Master.

Note : This field applies only when this device is a Backup.

8 - 36 © Foundry Networks, Inc.

December 2005

Configuring Metro Features

This Field...

Member ports

Operational ports

Forwarding ports

Table 8.6: CLI Display of VSRP VRID or VLAN Information (Continued)

Displays...

The ports in the VRID.

The member ports that are currently up.

The member ports that are currently in the Forwarding state. Ports that are forwarding on the Master are listed. Ports on the Standby, which are in the Blocking state, are not listed.

Displaying the Active Interfaces for a VRID

On a VSRP-aware device, you can display VLAN and port information for the connections to the VSRP devices

(Master and Backups).

To display the active VRID interfaces, enter the following command on the VSRP-aware device:

FastIron SuperX Router(config-vlan-200-vrid-1)# show vsrp aware

Aware port listing

VLAN ID VRID Last Port

100 1 3/2

200 2 4/1

Syntax: show vsrp aware

This display shows the following information when you use the aware parameter. For information about the display when you use the vrid <num> or vlan <vlan-id> parameter, see “Displaying VRID Information” on page 8-

34.

This Field...

VLAN ID

VRID

Last Port

Table 8.7: CLI Display of VSRP-Aware Information

Displays...

The VLAN that contains the VSRP-aware device’s connection with the

VSRP Master and Backups.

The VRID.

The most recent active port connection to the VRID. This is the port connected to the current Master. If a failover occurs, the VSRP-aware device changes the port to the port connected to the new Master. The

VSRP-aware device uses this port to send and receive data through the backed up node.

December 2005 © Foundry Networks, Inc.

8 - 37

Foundry Configuration Guide for the FESX, FSX, and FWSX

8 - 38 © Foundry Networks, Inc.

December 2005

Chapter 9

Configuring Uni-Directional Link Detection (UDLD)

This chapter describes how to configure Uni-directional Link Detection (UDLD) on a Foundry FastIron switch using the CLI.

This chapter contains the topics listed in Table 9.1

Table 9.1: Chapter Contents

Description

Overview of UDLD

Configuration notes

Enabling UDLD and configuring associated parameters

Displaying information about UDLD

Clearing UDLD statistics

See Page

9-1

9-2

9-2

9-4

9-6

UDLD Overview

Uni-directional Link Detection (UDLD) monitors a link between two Foundry devices and brings the ports on both ends of the link down if the link goes down at any point between the two devices. This feature is useful for links that are individual ports and for trunk links. Figure 9.1 shows an example.

December 2005 © Foundry Networks, Inc.

9 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 9.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.

Foundry Device Foundry Device

X

Normally, a Foundry device load balances traffic across the ports in a trunk group. In this example, each Foundry device load balances traffic across two ports. Without the UDLD feature, a link failure on a link that is not directly attached to one of the Foundry devices is undetected by the Foundry devices. As a result, the Foundry devices continue to send traffic on the ports connected to the failed link.

When UDLD is enabled on the trunk ports on each Foundry device, the devices detect the failed link, disable the ports connected to the failed link, and use the remaining ports in the trunk group to forward the traffic.

Ports enabled for UDLD exchange proprietary health-check packets once every second (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

• This feature is supported only on Ethernet ports.

• To configure UDLD on a trunk group, you must enable and 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.

Enabling UDLD

To enable UDLD on a port, enter a command such as the following at the global CONFIG level of the CLI:

FastIron SuperX Router(config)# link-keepalive ethernet 1/1

To enable the feature on a trunk group, enter commands such as the following:

FastIron SuperX Router(config)# link-keepalive ethernet 1/1 ethernet 1/2

FastIron SuperX Router(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.

Syntax: [no] link-keepalive ethernet [<slotnum>/]<portnum> [ethernet [<slotnum>/]<portnum>]

The <slotnum> parameter is required on chassis devices.

9 - 2 © Foundry Networks, Inc.

December 2005

Configuring Uni-Directional Link Detection (UDLD)

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:

FastIron SuperX Router(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

By default, a port waits one second to receive a health-check reply packet from the port at the other end of the link. If the port does not receive a reply, the port tries four more times by sending up to four more health-check packets. If the port still does not receive a reply after the maximum number of retries, the port goes down.

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:

FastIron SuperX Router(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.

UDLD for Tagged Ports

The default implementation of UDLD sends the packets untagged, even across tagged ports. If the untagged

UDLD packet is received by a third-party switch, that switch may reject the packet. As a result, UDLD may be limited only to Foundry devices, since UDLD may not function on third-party switches.

You can configure ports to send out UDLD control packets that are tagged with a specific VLAN ID as tagged

UDLD control packets. This feature also enables third party switches to receive the control packets that are tagged with the specified VLAN.

To enable ports to receive and send UDLD control packets tagged with a specific VLAN ID, enter commands such as the following:

FastIron SuperX Router(config)# link-keepalive ethernet 1/18 vlan 22

This command enables UDLD on port 1/18 and allows UDLD control packet tagged with VLAN 22 to be received and sent on port 1/18.

Syntax: [no] link-keepalive ethernet [<slotnum>/]<portnum> [vlan <vlan-ID>]

The <slotnum> parameter is required on chassis devices.

Enter the ID of the VLAN that the UDLD control packets can contain to be received and sent on the port. If a

VLAN ID is not specified, then UDLD control packets are sent out of the port as untagged packets.

NOTE: You must configure the same VLANs that will be used for UDLD on all devices across the network; otherwise, the UDLD link cannot be maintained.

December 2005 © Foundry Networks, Inc.

9 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

Displaying UDLD Information

Displaying Information for All Ports

To display UDLD information for all ports, enter the following command:

FastIron SuperX Router(config)# show link-keepalive

Total link-keepalive enabled ports: 4

Keepalive Retries: 3 Keepalive Interval: 1 Sec.

Port Physical Link Logical Link State

4/1 up up FORWARDING

4/2 up up FORWARDING

4/3 down down DISABLED

4/4 up down DISABLED

Syntax: show link-keepalive [ethernet [<slotnum>/]<portnum>]

Keepalive Interval

Port

Physical Link

Logical Link

State

Table 9.2: 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 Foundry port and the directly connected device.

The state of the logical link. This is the state of the link between this

Foundry port and the Foundry port on the other end of the link.

The traffic state of the port.

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:

FastIron SuperX Router(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

9 - 4 © Foundry Networks, Inc.

December 2005

Configuring Uni-Directional Link Detection (UDLD)

The show link-keepalive command shows the following:

FastIron SuperX Router(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 Link-vlan : 100

Port blocking : No BM disabled : Yes

The Link-vlan entry shows the ID of the tagged VLAN in the UDLD packet.

Syntax: show link-keepalive ethernet

Displaying Information for a Single Port

To display detailed UDLD information for a specific port, enter a command such as the following:

FastIron SuperX Router(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

Port blocking : No BM disabled : No

This Field...

Current State

Remote MAC Addr

Local Port

Remote Port

Local System ID

Remote System ID

Packets sent

Packets received

Transitions

Port blocking

December 2005

Table 9.3: CLI Display of Detailed UDLD Information

Displays...

The state of the logical link. This is the link between this Foundry port and the Foundry 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 Foundry device.

The port number on the Foundry device at the remote end of the link.

A unique value that identifies this Foundry device. The ID can be used by Foundry technical support for troubleshooting.

A unique value that identifies the Foundry device 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.

© Foundry Networks, Inc.

9 - 5

Foundry Configuration Guide for the FESX, FSX, and FWSX

This Field...

BM disabled

Table 9.3: CLI Display of Detailed UDLD Information (Continued)

Displays...

Information used by Foundry technical support for troubleshooting.

The show interface ethernet [<slotnum>/]<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:

FastIron SuperX Router(config)# show interface ethernet 1/1

FastEthernet1/1 is down, line protocol is down, link keepalive is enabled

Hardware is FastEthernet, address is 00e0.52a9.bbca (bia 00e0.52a9.bbca)

Configured speed auto, actual unknown, configured duplex fdx, actual unknown

Member of L2 VLAN ID 1, port is untagged, port state is DISABLED

STP configured to ON, priority is level0, flow control enabled

mirror disabled, monitor disabled

Not member of any active trunks

Not member of any configured trunks

No port name

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

19 packets output, 1216 bytes, 0 underruns

Transmitted 0 broadcasts, 19 multicasts, 0 unicasts

0 output errors, 0 collisions, DMA transmitted 19 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:

FastIron SuperX Router# 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 [<slotnum>/]<portnum> display.

9 - 6 © Foundry Networks, Inc.

December 2005

Chapter 10

Configuring Trunk Groups

and Dynamic Link Aggregation

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.

This chapter contains the following information:

Table 10.1: Chapter Contents

Description

Trunk group overview

Configuring a Trunk Group

Displaying Trunk Group Configuration Information

Configuring dynamic link aggregation

Determining the status of aggregate links

Clearing the negotiated aggregate links table

See Page

10-1

10-7

10-11

10-13

10-22

10-26

Trunk Group Overview

The Trunk Group feature allows you to manually configure multiple high-speed load-sharing links between two

Foundry Layer 2 Switches or Layer 3 Switches or between a Foundry Layer 2 Switch and Layer 3 Switch and a server. You can configure up to 4 ports as a trunk group, supporting transfer rates of up to 8 Gbps of bi-directional traffic.

In addition to enabling load sharing of traffic, trunk groups provide redundant, alternate paths for traffic if any of the segments fail.

December 2005 © Foundry Networks, Inc.

10 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 10.1 shows an example of a configuration that uses trunk groups.

Figure 10.1

Trunk Group application within a FastIron network

Gigabit

Backbone

Trunk

Group

FESX

Server

. . .

Power Users

Dedicated 100 Mbps

FastIron SuperX Router

FastIron SuperX Router

Trunk

Group

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 a single adapter with multiple ports that share the same MAC and IP address.

10 - 2 © Foundry Networks, Inc.

December 2005

Configuring Trunk Groups and Dynamic Link Aggregation

Figure 10.2 shows an example of a trunk group between a server and a Foundry device.

Figure 10.2

Trunk group between a server and a Foundry Stackable Layer 2 Switch or Layer 3 Switch

Multi-homing adapter has the same IP and MAC address

FastIron Switch

Multi-homing

Server

Trunk Group

Trunk Group Rules

• Table 10.2 lists the maximum number of trunk groups you can configure on a Foundry FastIron device and the valid number of ports in a trunk group.

Model

FESX424 and

FWSX424

FESX448 and

FWSX448

FSX

Table 10.2: Trunk Group Support

Maximum Number of Gigabit Trunk

Groups

Valid Number of

Ports in a Group

13 2, 3, or 4

25

31

2, 3, or 4

2, 3, or 4

• You cannot configure a port as a member of a trunk group if 802.3ad link aggregation is enabled on the port.

• Unlike the FES and other Foundry devices, trunk groups on the FESX, FSX, and FWSX are not classified as switch trunk groups or server trunk groups.

• Table 10.2 lists the maximum number of trunk groups you can configure on a FESX, FSX, and FWSX, and the valid number of ports in a trunk group.

• Multi-slot trunk groups are supported only on FSX devices.

• Although the FESX, FSX, and FWSX devices have port ranges, they do not apply to trunk groups.

• You can select any port to be the primary port of the trunk group.

• You cannot combine Gigabit and 10-Gigabit ports in the same trunk group.

• Port assignment on a module must be contiguous. The port range on the module cannot contain gaps. For example, you can configure ports 1, 2, 3, and 4 on a module together as a trunk group but not ports 1, 3, and

4 (excluding 2).

December 2005 © Foundry Networks, Inc.

10 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

• 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 three-port trunk group on the FESX and the other end is a different type of switch, make sure the other switch can support a three-port trunk group.

• All the ports must be connected to the same device at the other end.

• 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)

• statically configured 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.

Trunk Group Configuration Examples

Figure 10.3 shows some examples of valid 2-port and 3-port trunk group links between devices. The trunk groups in this example are switch trunk groups, between two Foundry devices. Ports in a valid 2-port trunk group on one device are connected to two ports in a valid 2-port trunk group on another device. The same rules apply to 3-port,

4-port, etc., trunk groups.

10 - 4 © Foundry Networks, Inc.

December 2005

Figure 10.3

Examples of 2-port and 3-port trunk groups

Link

Activity

Power

Console

Link

Activity

Configuring Trunk Groups and Dynamic Link Aggregation

Link

Activity

Power

Console

Link

Activity

Link

Activity

Power

Console

Link

Activity

Link

Activity

Power

Console

Link

Activity

Link

Activity

Power

Console

Link

Activity

42XG

Lnk

Act

424C

1

424C

424C

8X-12GM-4

Pwr

Console

Lnk

Act

2

Odd

Even

Lnk

424F

424C

424C

424F

FastIron SuperX

AC OK DC OK ALM

EJECT SYS

AC OK DC OK ALM

EJECT SYS

Odd

Even

424C

Odd

Even

Lnk

Lnk

424F

Odd

Even

POE Lnk

AC OK DC OK ALM

EJECT SYS

AC OK DC OK ALM

EJECT SYS

December 2005 © Foundry Networks, Inc.

10 - 5

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 10.4 shows examples of two Chassis devices connected by multi-slot trunk groups.

Figure 10.4

Examples of multi-slot trunk groups

42XG Lnk

Act

424C

1

424C

424C

8X-12GM-4

Pwr

Console

Lnk

Act

2

Odd

Even

Lnk

424C

424F

424F

424C

FastIron SuperX

AC OK DC OK ALM

EJECT SYS

AC OK DC OK ALM

EJECT SYS

Odd

Even

424C

Odd

Even

Lnk

Lnk

424F

Odd

Even

POE Lnk

AC OK DC OK ALM

EJECT SYS

AC OK DC OK ALM

EJECT SYS

42XG Lnk

Act

424C

1

424C

424C

8X-12GM-4

Pwr

Console

Lnk

Act

2

Odd

Even

Lnk

424C

424F

424F

424C

FastIron SuperX

AC OK DC OK ALM

EJECT SYS

AC OK DC OK ALM

EJECT SYS

Odd

Even

424C

Odd

Even

Lnk

Lnk

424F

Odd

Even

POE Lnk

AC OK DC OK ALM

EJECT SYS

AC OK DC OK ALM

EJECT SYS

42XG Lnk

Act

424C

1

424C

424C

8X-12GM-4

Pwr

Console

Lnk

Act

2

Odd

Even

Lnk

424F

424C

424C

424F

FastIron SuperX

AC OK DC OK ALM

EJECT SYS

AC OK DC OK ALM

EJECT SYS

Odd

Even

424C

Odd

Even

Lnk

Lnk

424F

Odd

Even

POE Lnk

AC OK DC OK ALM

EJECT SYS

AC OK DC OK ALM

EJECT SYS

Trunk Group Load Sharing

Unlike the FES and other Foundry devices, trunk groups on the FESX, FSX, and FWSX devices are not classified as switch trunk groups or server trunk groups.

The Foundry device load shares across the ports in the trunk group. The method used for the load sharing depends on the following:

• Device type – Chassis device or Stackable device

• Traffic type – Layer 2 or Layer 3

• Software version your device is running

NOTE: Layer 2 and Layer 3 AppleTalk traffic is not load-balanced. Layer 3 routed IP or IPX traffic also is not load balanced. These traffic types will however still be forwarded on the trunk ports.

Note Regarding IPv6

Foundry devices that support IPv6 take a packet’s IPv6 address into account when sharing traffic across a trunk group. The load sharing is performed in the same way it is for IPv4 addresses; that is; trunk types whose traffic load is shared based on IPv4 address information can now use IPv6 addresses to make the load sharing decision.

Load sharing occurs as described in Table 10.4 or Table 10.3.

How Trunk Load Sharing Works

Load balancing procedures differ depending on the software version your device is running. In releases prior to

02.2.00 for the FESX/FWSX, and release 02.1.00 for the FSX, the Foundry device load balances all bridged traffic based on source and destination MAC addresses. In subsequent releases, the load balancing method for bridged traffic varies depending on the traffic type.

10 - 6 © Foundry Networks, Inc.

December 2005

Configuring Trunk Groups and Dynamic Link Aggregation

Table 10.3 shows how the FESX, FWSX, and FSX load balance traffic across the ports in a trunk group, if the device is running FESX/FWSX software release 02.2.00 or later or FSX software release 02.1.00 or later.

Likewise, Table 10.4 shows how a FESX and FSX load balance traffic across the ports in a trunk group, if the device is running a FESX/FWSX software release prior to 02.2.00 or a FSX software release prior to 02.1.00.

Note that load balancing on the FESX and FSX is hardware-based.

NOTE: There is no change in load balancing for routed traffic, which is always based on the source and destination IP addresses and protocol field.

.

Table 10.3: Trunk Group Load Sharing on FSX Devices (Release 02.1.00 and Later) and FESX/FWSX Devices

(Release 02.2.00 and Later)

Traffic Type

Layer 2 bridged non-IP

Layer 2 bridged TCP/UDP

Layer 2 bridged IP (non-TCP/UDP)

Layer 3 routed traffic

Load Balancing Method

Source and destination MAC addresses

Source and destination IP addresses and

Source and Destination TCP/UDP ports

Source and destination IP addresses

Source and destination IP addresses and protocol field

Table 10.4: Trunk Group Load Sharing on FSX Devices (Pre-Release 02.1.00) and FESX/FWSX Devices (Pre-

Release 02.2.00)

Traffic Layer

Layer 2

Layer 3

Traffic Type

All traffic types

IP

All other traffic types

Load-Sharing Basis

Destination MAC address

Source MAC address

Destination IP address

Source MAC address

Protocol

Destination MAC address

Source MAC address

Configuring a Trunk Group

To configure a trunk group, do the following:

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.

December 2005 © Foundry Networks, Inc.

10 - 7

Foundry Configuration Guide for the FESX, FSX, and FWSX

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 Layer 2 Switches or Layer 3 Switches involved in the configuration.

3.

Save the configuration changes to the startup-config file.

4.

Dynamically place the new trunk configuration into effect by entering the trunk deploy command at the global

CONFIG level of the CLI.

5.

If the device at the other end of the trunk group is another Layer 2 Switch or Layer 3 Switch, repeat Steps 2 –

4 for the other device.

6.

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.

7.

To verify the link is operational, use the show trunk command.

Example 1: Configuring the Trunk Groups Shown in Figure 10.1

To configure the trunk groups shown in Figure 10.1, enter the following commands. Notice that the commands are entered on multiple devices.

To configure the trunk group link between FSX1 and the FESX:

NOTE: The text shown in italics in the CLI example below shows messages echoed to the screen in answer to the CLI commands entered.

FastIron SuperX Router(config)# trunk e 1/5 to 1/8

Trunk 2 is created for next power cycle.

Please save configuration to flash and reboot.

FastIron SuperX Router(config)# write memory

Write startup-config in progress.

.Write startup-config done.

FastIron SuperX Router(config)# exit

FastIron SuperX Router# reload

To configure the trunk group link between FSX2 and the server:

FastIron SuperX Router(config)# trunk e 1/2 to 1/4

Trunk 0 is created for next power cycle.

Please save configuration to flash and reboot.

FastIron SuperX Router(config)# write memory

Write startup-config in progress.

.Write startup-config done.

FastIron SuperX Router(config)# exit

FastIron SuperX Router# reload

You then configure the trunk group on the FESX.

FESX424 Switch(config)# trunk ethernet 17 to 18

FESX424 Switch(config)# write memory

Write startup-config in progress.

.Write startup-config done.

FESX424 Switch(config)# exit

FESX424 Switch# reload

Example 2: Configuring a Trunk Group That Spans Multiple

Gigabit Ethernet Modules in a Chassis Device

This section shows how to configure a trunk group that spans two modules in a Chassis device.

10 - 8 © Foundry Networks, Inc.

December 2005

Configuring Trunk Groups and Dynamic Link Aggregation

For example, to configure a trunk group consisting of two groups of ports, 1/1 – 1/4 on module 1 and 4/5 – 4/8 on module 4, enter the following commands:

FastIron SuperX Router(config)# trunk ethernet 1/1 to 1/4 ethernet 4/5 to 4/8

FastIron SuperX Router(config-trunk-1/1-4/8)# write memory

FastIron SuperX Router(config-trunk-1/1-4/8)# exit

FastIron SuperX Router(config)# trunk deploy

NOTE: The trunk deploy command dynamically places trunk configuration changes into effect, without a software reload.

CLI Syntax

Syntax: [no] trunk ethernet [<slotnum>/]<primary-portnum> to [<slotnum>/]<portnum> [ethernet [<slotnum>/

]<primary-portnum>

Syntax: trunk deploy

Each ethernet parameter introduces a port group. Enter the slot number (if applicable) and the port number of the

Ethernet port.

The <slotnum> parameter is required on chassis devices.

The <primary-portnum> to <portnum> parameters specify a port group. Notice that each port group must begin with a primary port. After you enter this command, the primary port of the first port group specified (which must be the group with the lower port numbers) becomes the primary port for the entire trunk group.

To configure a trunk group consisting of two groups of two ports each, enter commands such as the following:

FastIron SuperX Router(config)# trunk ethernet 1/1 to 1/2 ethernet 3/3 to 3/4

FastIron SuperX Router(config)# write memory

FastIron SuperX Router(config)# trunk deploy

Notice that the groups of ports meet the criteria for a multi-slot trunk group. Each group contains the same number of ports (two) and begins on a primary port (1/1 and 3/3).

Additional Trunking Options

The CLI contains commands for doing the following:

• Naming a trunk port

• Disabling or re-enabling a trunk port

• Deleting a trunk group

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:

FastIron SuperX Router(config-trunk-4/1-4/4)# port-name customer1 ethernet 4/2

Syntax: [no] port-name <text> ethernet [<slotnum>/]<portnum>

The <text> parameter specifies the port name. The name can be up to 50 characters long.

The <slotnum> parameter is required for chassis devices.

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:

FastIron SuperX Router(config-trunk-4/1-4/4)# config-trunk-ind

December 2005 © Foundry Networks, Inc.

10 - 9

Foundry Configuration Guide for the FESX, FSX, and FWSX

FastIron SuperX Router(config-trunk-4/1-4/4)# disable ethernet 4/2

Syntax: [no] config-trunk-ind

Syntax: [no] disable ethernet [<slotnum>/]<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:

FastIron SuperX Router(config-trunk-4/1-4/4)# config-trunk-ind

FastIron SuperX Router(config-trunk-4/1-4/4)# disable customer1

Syntax: disable <portname>

To enable an individual port in a trunk group, enter commands such as the following at the trunk group configuration level:

FastIron SuperX Router(config-trunk-4/1-4/4)# config-trunk-ind

FastIron SuperX Router(config-trunk-4/1-4/4)# enable ethernet 4/2

Syntax: enable ethernet [<slotnum>/]<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:

FastIron SuperX Router(config)# trunk switch ethernet 2/1 to 2/8

FastIron SuperX Router(config-trunk-2/1-2/8)# config-trunk-ind

FastIron SuperX Router(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:

FastIron SuperX Router(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:

FastIron SuperX Router(config-trunk-2/1-2/8)# enable ethernet 2/2 to 2/5 ethernet 2/

7

Syntax: [no] disable ethernet [<slotnum>/]<portnum> [to [<slotnum>/]<portnum> | ethernet [<slotnum>/

]<portnum>]

Syntax: [no] enable ethernet [<slotnum>/]<portnum> [to [<slotnum>/]<portnum> | ethernet [<slotnum>/

]<portnum>]

The <slotnum> parameter is required on chassis devices.

The to <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.

10 - 10 © Foundry Networks, Inc.

December 2005

Configuring Trunk Groups and Dynamic Link Aggregation

The <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:

FastIron SuperX Router(config)# no trunk ethernet 1/1 to 1/2 ethernet 3/3 to 3/4

Syntax: no trunk ethernet [<slotnum>/]<portnum> to [<slotnum>/]<portnum>

The <slotnum> parameter is required on chassis devices.

Displaying Trunk Group Configuration Information

To display configuration information for the trunk groups, use the show trunk command. This command displays information for configured trunk groups and operational trunk groups. A configured trunk group is one that has been configured in the software but has not been placed into operation by a reset or reboot. An operational trunk group is one that has been placed into operation by a reset or reboot.

Enter the following command at any CLI level:

FastIron SuperX Router(config)# show trunk

Configured trunks:

Trunk ID: 1

HW 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

HW 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

IP 0 0 0 0 0 0 0 0

Multicast 4 2 5 2 0 0 2 3

Syntax: show trunk [ethernet [<slotnum>/]<portnum> to [<slotnum>/]<portnum>]

December 2005 © Foundry Networks, Inc.

10 - 11

Foundry Configuration Guide for the FESX, FSX, and FWSX

The [<slotnum/> applies to chassis devices only.

Table 10.5 describes the information displayed by the show trunk command.

This Field...

Trunk ID

HW Trunk ID

Duplex

Speed

Tag

Priority

Active Ports

Ports

Link_Status

LACP_Status

Load Sharing

Table 10.5: CLI Trunk Group Information

Displays...

The trunk group number. The software numbers the groups in the display to make the display easy to use.

The trunk ID.

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.

For more information about this feature, see the section “Displaying and Determining the Status of Aggregate Links” on page 10-22.

• 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 10-6.

10 - 12 © Foundry Networks, Inc.

December 2005

Configuring Trunk Groups and Dynamic Link Aggregation

Dynamic Link Aggregation

Foundry 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.

Configuration Example

Foundry ports follow the same configuration rules for dynamically created aggregate links as they do for statically configured trunk groups. See “Trunk Group Rules” on page 10-3 and “Trunk Group Load Sharing” on page 10-6.

Figure 10.5 on page 10-14 shows some examples of valid aggregate links.

December 2005 © Foundry Networks, Inc.

10 - 13

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 10.5

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

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). The ports that are members of aggregate links in this example are 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 10-3.

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.

10 - 14 © Foundry Networks, Inc.

December 2005

Configuring Trunk Groups and Dynamic Link Aggregation

NOTE: Use the link aggregation feature only if the device at the other end of the link 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.

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.

Configuration Notes

• You cannot use 802.3ad link aggregation on a port configured as a member of a static trunk group.

• This feature is supported only on Gigabit Ethernet ports.

• The dynamic link aggregation (802.3ad) implementation on the FESX, FSX, and FWSX allow any number of ports up to four to be aggregated into a link. The feature does not require the aggregate link to consist of exactly two or four ports.

• 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.

• If you use this feature on a Layer 3 Switch that is running OSPF or BGP4, the feature causes these protocols to reset when a dynamic link change occurs. The reset includes ending and restarting neighbor sessions with

OSPF and BGP4 peers, and clearing and relearning dynamic route entries and forwarding cache entries.

Although the reset causes a brief interruption, the protocols automatically resume normal operation.

• You can enable link aggregation on 802.1Q tagged ports (ports that belong to more than one port-based

VLAN).

• Dynamic Operation of Allocation Keys (section 43.6.2 in the 802.3ad specification) is supported.

• The trunks that will be formed by link aggregation will strictly adhere to the static trunking rules on the

FastIron family of switches. Be careful in selecting keys if you are manually configuring link aggregation keys.

Make sure that the possible trunks that you expect to be formed conform to the static trunking rules.

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 configuration following the reboot or re-establishment of the links. Once the other device recovers, 802.3 can renegotiate the link without a mismatch.

December 2005 © Foundry Networks, Inc.

10 - 15

Foundry Configuration Guide for the FESX, FSX, and FWSX

Flexible Trunk Eligibility

The criteria for being eligible to be in an aggregate link are flexible. A range of ports can contain down ports and still be eligible to become an aggregate link.

The device groups the device's ports into 2-port groups consisting of an odd-numbered port and the next evennumbered port. For example, ports 1/1 and 1/2 are a two-port group, as are ports 1/3 and 1/4, 9/1 and 9/10, and so on. If either of the ports in a two-port group is up, the device considers both ports to be eligible to be in an aggregate link.

Figure 10.6 shows an example of 2-port groups in a range of four ports on which link aggregation is enabled.

Based on the states of the ports, some or all of them will be eligible to be used in an aggregate link.

Figure 10.6

Two-port groups used to determine aggregation eligibility

Group 1

Group 2

Port 1/1

Port 1/2

Port 1/3

Port 1/4

Table 10.6 shows examples of the ports from Figure 10.6 that will be eligible for an aggregate link based on individual port states.

Link

State

Table 10.6: Port Eligibility for Link Aggregation

Port Group 1

1/1

Up

Up

Up

Up

Down

Up

1/2

Up

Up

Down

Up

Down

Down

Port Group 2

1/3

Up

Up

Up

Down

Down

Down

1/4

Up

Down

Down

Up

Up

Down

Trunk

Eligibility

4-port

1/1 – 1/4

4-port

1/1 – 1/4

4-port

1/1 – 1/4

4-port

1/1 – 1/4

2-port

1/3 – 1/4

2-port

1/1 – 1/2

As shown in these examples, all or a subset of the ports within a port range will be eligible for formation into an aggregate link based on port states. Notice that the sets of ports that are eligible for the aggregate link must be valid static trunk configurations.

10 - 16 © Foundry Networks, Inc.

December 2005

Configuring Trunk Groups and Dynamic Link Aggregation

Command Syntax

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 commands below, according to the type of key you are using. For more information about keys, see “Key” on page 10-18.

Using the Default Key Assigned by the Software

FastIron SuperX Router(config)# interface ethernet 1/1

FastIron SuperX Router(config-if-e1000-1/1)# link-aggregate active

FastIron SuperX Router(config)# interface ethernet 1/2

FastIron SuperX Router(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.

NOTE: In conformance with the 802.3ad specification, the default key assigned to an aggregate link is based on the port type (1-Gigabit port or 10-Gigabit port). The Foundry device assigns different keys to 10-Gigabit ports than 1-Gigabit ports, so that ports with different physical capabilities will not be able to form a trunk.

Assigning a Unique Key

FastIron SuperX Router(config)# interface ethernet 1/1

FastIron SuperX Router(config-if-e1000-1/1)# link-aggregate configure key 10000

FastIron SuperX Router(config-if-e1000-1/1)# link-aggregate active

FastIron SuperX Router(config)# interface ethernet 1/2

FastIron SuperX Router(config-if-e1000-1/2)# link-aggregate configure key 10000

FastIron SuperX Router(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:

FastIron SuperX Router(config)# interface ethernet 1/5 to 1/8

FastIron SuperX Router(config-mif-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:

FastIron SuperX Router(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>] |

[type server | switch]

NOTE: For more information about keys, including details about the syntax shown above, see “Key” on page 10-

18.

December 2005 © Foundry Networks, Inc.

10 - 17

Foundry Configuration Guide for the FESX, FSX, and FWSX

Link Aggregation Parameters

You can change the settings on individual ports for the following link aggregation parameters:

• System priority

• Port priority

• Link type

• Key

System Priority

The system priority parameter 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. A higher value indicates a lower priority. You can specify a priority from 0 – 65535. 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.

Port Priority

The port priority parameter 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. You can specify a priority from 0 – 65535. A higher value indicates a lower priority. The default is 1.

NOTE: This parameter is not supported in the current software release. 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.

Link Type

The link type parameter specifies whether the trunk is connecting to a server (server link) or to another networking device (switch link). The default link type is switch.

Key

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. The default key is based on the position of the port within an eight-port group (the maximum number of ports in a trunk group on a chassis device). The software assigns the keys in ascending numerical order, beginning with key 0 for the first group of eight ports. For example, a 24-port module in chassis slot 1 contains keys 0, 1, and 2 by default. Ports 1/1 – 1/8 have key 0, ports 1/9 – 1/16 have key 1, and so on.

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 10.7 on page 10-19 shows an example.

10 - 18 © Foundry Networks, Inc.

December 2005

Configuring Trunk Groups and Dynamic Link Aggregation

Figure 10.7

Ports with the same key in different aggregate links

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 aggregation key on one or both groups of ports so that the key is the same on all eight ports. Figure 10.8 on page 10-20 shows an example.

December 2005 © Foundry Networks, Inc.

10 - 19

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 10.8

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.

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.

Dynamic Operation of Allocation Keys

The Foundry device dynamically changes a port’s key based on changes to the port’s VLAN membership.

When you change a port’s VLAN membership, the device searches through existing key groups for a port with matching port properties. Specifically, it searches for a match on all three of the following properties:

• VLAN ID

• default key

• port tag type (tagged or untagged)

If it finds a match, the port (whose VLAN membership you are changing) gets the matching port’s key. If it does not find a match, the port gets a new key.

NOTE: For multi-slot trunk groups, you must manually configure the keys in the trunk group(s) to match. For instructions on configuring keys manually, see “Configuring Keys For Ports with Link Aggregation Enabled” on page 10-22.

How Changing a Port’s VLAN Membership Affects Trunk Groups and Dynamic Keys

When you change a port’s VLAN membership and the port is currently a member of a trunk group, the following changes occur:

• The Foundry device tears down the existing trunk group.

• All ports in the trunk group get a new key.

• The new key group aggregates into a new trunk group.

When you change a port’s VLAN membership, and the port is not a member of a trunk group, the following changes occur:

• The port gets a new key depending on changes to the port’s VLAN tag type, as follows:

• Tagged to Tagged VLAN – The primary port of the trunk group gets a new key.

• Tagged to Untagged VLAN –The port gets the default key for untagged ports.

10 - 20 © Foundry Networks, Inc.

December 2005

Configuring Trunk Groups and Dynamic Link Aggregation

• Untagged to Tagged VLAN – If the Foundry device finds a port with matching port properties, the port gets that port’s key. If it doesn’t find one, the port gets a new key.

• Untagged to Untagged VLAN – The port gets a new key depending on whether it’s in the default VLAN or not. If there is a trunk group associated with the key, it is not affected.

• All other ports keep their existing key.

• The new key groups try to aggregate into trunk groups.

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:

FastIron SuperX Router# 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 0 0 0 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:

FastIron SuperX Router# sh link-agg

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 480 Yes S Agg Syn Col Dis Def No Dwn

4/2 1 1 480 Yes S Agg Syn Col Dis Def No Dwn

4/3 1 1 480 Yes S Agg Syn Col Dis Def No Dwn

4/4 1 1 480 Yes S Agg Syn Col Dis Def No Dwn

4/17 1 1 481 Yes S Agg Syn Col Dis Def No Ope

4/18 1 1 481 Yes S Agg Syn Col Dis Def No Ope

4/19 1 1 481 Yes S Agg Syn Col Dis Def No Ope

4/20 1 1 481 Yes S Agg Syn Col Dis Def No Ope

Syntax: show link-aggregation [ethernet [<slotnum>/]<portnum>]

Possible values: N/A

Default value: N/A

Configuring Link Aggregation Parameters

You can configure one or more parameters on the same command line, and you can enter the parameters in any order.

NOTE: 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.

December 2005 © Foundry Networks, Inc.

10 - 21

Foundry Configuration Guide for the FESX, FSX, and FWSX

For example, to change a port group’s key from the one assigned by the software to another value, enter commands such as the following:

NOTE: Use this command sequence 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).

FastIron SuperX Router(config)# interface ethernet 1/1 to 1/4

FastIron SuperX Router(config-mif-1/1-1/4)# link-aggregate configure key 10000

FastIron SuperX Router(config-mif-1/1-1/4)# interface ethernet 3/5 to 3/8

FastIron SuperX Router(config-mif-3/5-3/8)# link-aggregate configure key 10000

Configuring Keys For Ports with Link Aggregation Enabled

NOTE: 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.

FastIron SuperX Router(config)# interface ethernet 1/1 to 1/4

FastIron SuperX Router(config-mif-1/1-1/4)# link-aggregate off

FastIron SuperX Router(config-mif-1/1-1/4)# link-aggregate configure key 10000

FastIron SuperX Router(config-mif-1/1-1/4)# link-aggregate active

FastIron SuperX Router(config-mif-1/1-1/4)# interface ethernet 3/5 to 3/8

FastIron SuperX Router(config-mif-3/5-3/8)# link-aggregate off

FastIron SuperX Router(config-mif-3/5-3/8)# link-aggregate configure key 10000

FastIron SuperX Router(config-mif-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 [system-priority <num>] | [port-priority <num>] | [key <num>] |

[type server | switch]

The system-priority <num> parameter specifies the Foundry device’s link aggregation priority. A higher value indicates a lower priority. You can specify a priority from 0 – 65535. The default is 1.

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.

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 0. You can change a port group’s key to a value from 0 – 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.

The type server | switch parameter specifies whether the port group is connected to a server ( server ) or to another networking device ( switch ). The default is switch .

You can enter one or more of the command’s parameters on the same command line, in any order.

Displaying and Determining the Status of Aggregate Links

The show link-aggregation command provides the ability to view the status of dynamic links. You can determine the status of ports that are members of an aggregate link, and tell whether or not LACPCU messages are being transmitted between the ports.

The following section provides details about the events that can affect the status of ports in an aggregate link and the status of LACP messages exchanged between the ports. Later sections provide instructions for viewing these status reports.

10 - 22 © Foundry Networks, Inc.

December 2005

Configuring Trunk Groups and Dynamic Link Aggregation

About Blocked Ports

Foundry devices can block traffic on a port or shut down a port that is part of a trunk group or aggregate link, when a port joins a trunk group and the port on the other end of the link shuts down or stops transmitting LACP packets.

Depending on the timeout value set on the port, the link aggregation information expires. If this occurs, the

Foundry device shuts down the port and notifies all the upper layer protocols that the port is down.

Foundry devices can also block traffic on a port that is initially configured with link aggregation. The port is blocked until it joins a trunk group. In this case, traffic is blocked, but the port is still operational.

A port remains blocked until one of the following events occur:

• Both ports in the aggregate link have the same key

• LACP brings the port back up

• The port joins a trunk group

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:

FastIron SuperX Router(config-mif-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 0 0 0 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:

FastIron SuperX Router(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 0 No L Agg Syn No No Def Exp Ope

1/2 1 1 0 No L Agg Syn No No Def Exp Ina

1/3 1 1 0 No L Agg Syn No No Def Exp Ina

1/4 1 1 0 No L Agg Syn No No Def Exp Blo

1/5 1 1 1 No L Agg No No No Def Exp Ope

1/6 1 1 1 No L Agg No No No Def Exp Ope

1/7 1 1 1 No L Agg No No No Def Exp Dwn

1/8 1 1 1 No L Agg No No No Def Exp Dwn

Syntax: show link-aggregation [ethernet [<slotnum>/]<portnum>]

The <slotnum> parameter is required on chassis devices.

Use ethernet <portnum> to display link-aggregation information for a specific port.

NOTE: Ports that are configured as part of an aggregate link must also have the same key. For more information about assigning keys, see the section “Link Aggregation Parameters” on page 10-18.

December 2005 © Foundry Networks, Inc.

10 - 23

Foundry Configuration Guide for the FESX, FSX, and FWSX

10 - 24 © Foundry Networks, Inc.

December 2005

Configuring Trunk Groups and Dynamic Link Aggregation

This Field...

Syn

Col

Dis

Def

Exp

Table 10.7: CLI Display of Link Aggregation Information (Continued)

Displays...

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.

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.

December 2005 © Foundry Networks, Inc.

10 - 25

Foundry Configuration Guide for the FESX, FSX, and FWSX

This Field...

Ope

Table 10.7: CLI Display of Link Aggregation Information (Continued)

Displays...

• 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. 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

Use the show trunk command to determine the status of LACP. See “Displaying Trunk Group Configuration

Information” on page 10-11.

Clearing the Negotiated Aggregate Links Table

When a group of ports negotiates a trunk group configuration, the software stores the negotiated configuration in a table. You can clear the negotiated link aggregation configurations from the software. When you clear the information, the software does not remove link aggregation parameter settings you have configured. Only the configuration information negotiated using LACP is removed.

NOTE: The software automatically updates the link aggregation configuration based on LACPDU messages.

However, clearing the link aggregation information can be useful if you are troubleshooting a configuration.

To clear the link aggregation information, enter the following command at the Privileged EXEC level of the CLI:

FastIron SuperX Router# clear link-aggregate

Syntax: clear link-aggregate

10 - 26 © Foundry Networks, Inc.

December 2005

Chapter 11

Configuring Virtual LANs (VLANs)

This chapter describes how to configure Virtual LANs (VLANs) on Foundry Layer 2 Switches and Layer 3

Switches using the CLI.

This chapter contains information and configuration procedures and examples for the following:

Table 11.1: Chapter Contents

Description

Overview of VLANs and VLAN features

Routing between VLANs (Layer 3 Switches Only)

IP subnet, IPX network and protocol-based VLANs

IP subnet, IPX network, and protocol-based VLANs within

Port-Based VLANs

IPv6 protocol VLANs

Routing between VLANs using virtual routing interfaces

(Layer 3 switches only)

Protocol VLANs with dynamic ports

Uplink ports within a port-based VLAN

Same IP subnet address on multiple port-based VLANs

VLAN groups and virtual routing interface groups

Super Aggregated VLANs (SAVs)

802.1Q-in-Q tagging

Private VLANs

Dual-mode VLAN ports

Displaying VLAN information

See Page

11-2

11-14

11-21

11-23

11-26

11-27

11-33

11-35

11-35

11-40

11-43

11-49

11-52

11-56

11-59

December 2005 © Foundry Networks, Inc.

11 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX

VLAN Overview

The following sections provide details about the VLAN types and features supported on the FastIron family of switches.

Types of VLANs

You can configure the following types of VLANs on Foundry devices.

• Layer 2 port-based VLAN – a set of physical ports that share a common, exclusive Layer 2 broadcast domain

• Layer 3 protocol 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 type

• IP sub-net VLANs – a subset of ports in a port-based VLAN that share a common, exclusive sub-net broadcast domain for a specified IP sub-net

• IPv6 VLANs – a subset of ports in a port-based VLAN that share a common, exclusive network broadcast domain for IPv6 packets

• IPX network VLANs – a subset of ports in a port-based VLAN that share a common, exclusive network broadcast domain for a specified IPX network

• AppleTalk cable VLANs – a subset of ports in a port-based VLAN that share a common, exclusive network broadcast domain for a specified AppleTalk cable range

When a Foundry device receives a packet on a port that is a member of a VLAN, the device forwards the packet based on the following VLAN hierarchy:

• If the port belongs to an IP sub-net VLAN, IPX network VLAN, or AppleTalk cable VLAN and the packet belongs to the corresponding IP sub-net, IPX network, or AppleTalk cable 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.

Protocol VLANs differ from IP sub-net, IPX network, and AppleTalk VLANs in an important way. Protocol VLANs accept any broadcast of the specified protocol type. An IP sub-net, IPx network, or AppleTalk VLAN accepts only broadcasts for the specified IP sub-net, IPX network, or AppleTalk cable range.

NOTE: Protocol VLANs are different from IP sub-net, IPX network, and AppleTalk cable VLANs. A port-based

VLAN cannot contain both an IP sub-net, IPX network, or AppleTalk cable VLAN and a protocol VLAN for the same protocol. For example, a port-based VLAN cannot contain both an IP protocol VLAN and an IP sub-net

VLAN.

Layer 2 Port-Based VLANs

On all Foundry devices, you can configure port-based VLANs. A port-based VLAN is a subset of ports on a

Foundry device that constitutes a Layer 2 broadcast domain.

By default, all the ports on a Foundry device are members of the default VLAN. Thus, all the ports on the device constitute a single Layer 2 broadcast domain. You can configure multiple port-based VLANs. When you configure a port-based VLAN, the device automatically removes the ports you add to the VLAN from the default VLAN.

You can configure up to 4094 port-based VLANs on a Layer 2 Switch or Layer 3 Switch. On both device types, valid VLAN IDs are 1 – 4095. You can configure up to the maximum number of VLANs within that ID range.

11 - 2 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

NOTE: VLAN ID 4094 is reserved for use by Single STP. VLAN IDs 4091 and 4092 are reserved for use in the

Layer 3 Switch and Base Layer 3 images. You can configure these VLAN IDs in the Layer 2 Switch image.

Each port-based VLAN can contain either tagged or untagged ports. A port cannot be a member of more than one port-based VLAN unless the port is tagged. 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.

Figure 11.1 shows an example of a Foundry device on which a Layer 2 port-based VLAN has been configured.

Figure 11.1

Foundry device containing user-defined Layer 2 port-based VLAN

DEFAULT-VLAN

VLAN ID = 1

Layer 2 Port-based VLAN

User-configured port-based VLAN

When you add a port-based VLAN, the device removes all the ports in the new VLAN from DEFAULT-VLAN.

Layer 3 Protocol-Based VLANs

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 each of 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.

December 2005 © Foundry Networks, Inc.

11 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

• 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 – 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.

• DECnet – The device sends DECnet broadcasts to all ports within the DECnet protocol VLAN.

• NetBIOS – The device sends NetBIOS broadcasts to all ports within the NetBIOS protocol VLAN.

• Other – The device sends broadcasts for all protocol types other than those listed above to all ports within the

VLAN.

Figure 11.2 shows an example of Layer 3 protocol VLANs configured within a Layer 2 port-based VLAN.

Figure 11.2

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, IP sub-net VLAN,

IPX network VLAN, or AppleTalk cable VLAN

11 - 4

You can add Layer 3 protocol VLANs or

IP sub-net, IPX network, and AppleTalk cable VLANs to port-based VLANs.

Layer 3 VLANs cannot span Layer 2 port-based

VLANs.

However, Layer 3 VLANs can overlap within a Layer 2 port-based VLAN.

© Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

Integrated Switch Routing (ISR)

Foundry Networks’ Integrated Switch Routing (ISR) feature enables VLANs configured on Layer 3 Switches to route Layer 3 traffic from one protocol VLAN or IP sub-net, IPX network, or AppleTalk cable VLAN to another.

Normally, to route traffic from one IP sub-net, IPX network, or AppleTalk cable 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 sub-nets, IPX networks, or AppleTalk cable 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). A virtual routing interface is a logical port on which you can configure Layer 3 routing parameters. 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 sub-net VLANs on a Layer 3 Switch, you can configure a virtual routing interface on each VLAN, then configure IP routing parameters for the sub-nets. Thus, the Layer 3 Switch forwards IP sub-net broadcasts within each VLAN at Layer 2 but routes Layer 3 traffic between the VLANs using the virtual routing interfaces.

NOTE: The Layer 3 Switch 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 Layer 3 Switch 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.

IP Sub-Net, IPX Network, and AppleTalk Cable VLANs

The protocol-based VLANs described in the previous section provide separate protocol broadcast domains for specific protocols. For IP, IPX, and AppleTalk, you can provide more granular broadcast control by instead creating the following types of VLAN:

• IP sub-net VLAN – An IP sub-net broadcast domain for a specific IP sub-net.

• IPX network VLAN – An IPX network broadcast domain for a specific IPX network.

• AppleTalk cable VLAN – An AppleTalk broadcast domain for a specific cable range.

You can configure these types of VLANs on Layer 3 Switches only. The Layer 3 Switch sends broadcasts for the

IP sub-net, IPX network, or AppleTalk cable range to all ports within the IP sub-net, IPX network, or AppleTalk cable VLAN at Layer 2.

The Layer 3 Switch routes packets between VLANs at Layer 3. To configure an IP sub-net, IPX network, or

AppleTalk cable VLAN to route, you must add a virtual routing interface to the VLAN, then configure the appropriate routing parameters on the virtual routing interface.

NOTE: The Layer 3 Switch routes packets between VLANs of the same protocol. The Layer 3 Switch cannot route from one protocol to another.

December 2005 © Foundry Networks, Inc.

11 - 5

Foundry Configuration Guide for the FESX, FSX, and FWSX

NOTE: IP sub-net VLANs are not the same thing as IP protocol VLANs. An IP protocol VLAN sends all IP broadcasts on the ports within the IP protocol VLAN. An IP sub-net VLAN sends only the IP sub-net broadcasts for the sub-net of the VLAN. You cannot configure an IP protocol VLAN and an IP sub-net VLAN within the same port-based VLAN.

This note also applies to IPX protocol VLANs and IPX network VLANs, and to AppleTalk protocol VLANs and

AppleTalk cable VLANs.

Default VLAN

By default, all the ports on a Foundry device are in a single port-based VLAN. This VLAN is called DEFAULT-

VLAN and is VLAN number 1. Foundry devices do not contain any protocol VLANs or IP sub-net, IPX network, or

AppleTalk cable VLANs by default.

Figure 11.3 shows an example of the default Layer 2 port-based VLAN.

Figure 11.3

Default Layer 2 port-based VLAN

DEFAULT-VLAN

VLAN ID = 1

Layer 2 Port-based VLAN

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 Foundry device automatically removes the ports that you place in the

VLAN from DEFAULT-VLAN. By removing the ports from the default VLAN, the Foundry device ensures that each port resides in only one Layer 2 broadcast domain.

NOTE: Information for the default VLAN is available only after you define another VLAN.

11 - 6 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

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 the following section.

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. See “Assigning a Different VLAN ID to the Default VLAN” on page 11-15.

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. Foundry devices 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 Foundry devices if needed to be compatible with other vendors’ equipment.

• The VLAN ID is determined by the VLAN on which the packet is being forwarded.

Figure 11.4 shows the format of packets with and without the 802.1Q tag. The tag format is vendor-specific. To use the tag for VLANs configured across multiple devices, make sure all the devices support the same tag format.

Figure 11.4

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)

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 Foundry devices is compatible with other Foundry devices.

December 2005 © Foundry Networks, Inc.

11 - 7

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 11.5 shows an example of two devices that have the same Layer 2 port-based VLANs configured across them. Notice that only one of the VLANs requires tagging.

Figure 11.5

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

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.

802.1Q-in-Q Tagging

Foundry devices provide finer granularity for configuring 802.1Q tagging, enabling you to configure 802.1Q tagtypes 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.

For example applications and configuration details, see “Configuring 802.1Q-in-Q Tagging” on page 11-49.

Spanning Tree Protocol (STP)

The default state of STP depends on the device type:

• STP is disabled by default on Foundry Layer 3 Switches.

• STP is enabled by default on Foundry Layer 2 Switches.

Also by default, each port-based VLAN has a separate instance of STP. Thus, when STP is globally enabled, each port-based VLAN on the device runs a separate spanning tree.

You can enable or disable STP on the following levels:

• Globally – Affects all ports on the device.

NOTE: If you configure a port-based VLAN on the device, the VLAN has the same STP state as the default

STP state on the device. Thus, on Layer 2 Switches, new VLANs have STP enabled by default. On Layer 3

Switches, new VLANs have STP disabled by default. You can enable or disable STP in each VLAN separately. In addition, you can enable or disable STP on individual ports.

• Port-based VLAN – Affects all ports within the specified port-based VLAN.

STP is a Layer 2 protocol. Thus, you cannot enable or disable STP for individual protocol VLANs or for IP sub-net,

IPX network, or AppleTalk cable VLANs. The STP state of a port-based VLAN containing these other types of

VLANs 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.

11 - 8 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

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 sub-net 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 (STP) and IronSpan Features” on page 7-1.

Virtual Routing Interfaces

A virtual routing interface is a logical routing interface that Foundry Layer 3 Switches use to route Layer 3 protocol traffic between protocol VLANs.

Foundry devices send 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.

For example, to enable a FastIron Layer 3 Switch to route IP traffic from one IP sub-net VLAN to another, you must configure a virtual routing interface on each IP sub-net VLAN, then configure the appropriate IP routing parameters on each of the virtual routing interfaces.

Figure 11.6 shows an example of Layer 3 protocol VLANs that use virtual routing interfaces for routing.

December 2005 © Foundry Networks, Inc.

11 - 9

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 11.6

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 1

VE 2

VE 4

VE 3

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.

VLAN and Virtual Routing Interface Groups

To simplify configuration, you can configure VLAN groups and virtual routing interface groups. When you create a

VLAN group, the VLAN parameters you configure for the group apply to all the VLANs within the group.

Additionally, you can easily associate the same IP sub-net interface with all the VLANs in a group by configuring a virtual routing interface group with the same ID as the VLAN group.

For configuration information, see “Configuring VLAN Groups and Virtual Routing Interface Groups” on page 11-

40.

Dynamic, Static, and Excluded Port Membership

When you add ports to a protocol VLAN, IP sub-net VLAN, IPX network VLAN, or AppleTalk cable VLAN, you can add them dynamically or statically:

• Dynamic ports

• Static ports

You also can explicitly exclude ports.

11 - 10 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

Dynamic Ports

Dynamic ports are added to a VLAN when you create the VLAN. However, if a dynamically added port does not receive any traffic for the VLAN’s protocol within ten minutes, the port is removed from the VLAN. However, the port remains a candidate for port membership. Thus, if the port receives traffic for the VLAN’s protocol, the device adds the port back to the VLAN.

After the port is added back to the VLAN, the port can remain an active member of the VLAN up to 20 minutes without receiving traffic for the VLAN’s protocol. If the port ages out, it remains a candidate for VLAN membership and is added back to the VLAN when the VLAN receives protocol traffic. At this point, the port can remain in the

VLAN up to 20 minutes without receiving traffic for the VLAN’s protocol, and so on.

Unless you explicitly add a port statically or exclude a port, the port is a dynamic port and thus can be an active member of the VLAN, depending on the traffic it receives.

NOTE: You cannot configure dynamic ports in an AppleTalk cable VLAN. The ports in an AppleTalk cable VLAN must be static. However, ports in an AppleTalk protocol VLAN can be dynamic or static.

Figure 11.7 shows an example of a VLAN with dynamic ports. Dynamic ports not only join and leave the VLAN according to traffic, but also allow some broadcast packets of the specific protocol to “leak” through the VLAN.

See “Broadcast Leaks” on page 11-12.

Figure 11.7

VLAN with dynamic ports—all ports are active when you create the VLAN

A = active port

C = candidate port

When you add ports dynamically, all the ports are added when you add the VLAN.

A A A A

A A A A

December 2005 © Foundry Networks, Inc.

11 - 11

Foundry Configuration Guide for the FESX, FSX, and FWSX

Ports in a new protocol VLAN that do not receive traffic for the VLAN’s protocol age out after 10 minutes and become candidate ports. Figure 11.8 shows what happens if a candidate port receives traffic for the VLAN’s protocol.

Figure 11.8

VLAN with dynamic ports—candidate ports become active again if they receive protocol traffic

Ports that time out remain candidates for membership in the VLAN and become active again if they receive traffic for the VLAN’s protocol, IP sub-net, IPX network, or

AppleTalk cable range.

When a candidate port rejoins a VLAN, the timeout for that port becomes 20 minutes.

Thus, the port remains an active member of the VLAN even if it does not receive traffic for 20 minutes. After that, the port becomes a candidate port again.

A A A A

A C A C

Static Ports

Static ports are permanent members of the protocol VLAN. The ports remain active members of the VLAN regardless of whether the ports receive traffic for the VLAN’s protocol. You must explicitly identify the port as a static port when you add it to the VLAN. Otherwise, the port is dynamic and is subject to aging out.

Excluded Ports

If you want to prevent a port in a port-based VLAN from ever becoming a member of a protocol, IP sub-net, IPX network, or AppleTalk cable VLAN configured in the port-based VLAN, you can explicitly exclude the port. You exclude the port when you configure the protocol, IP sub-net, IPX network, or AppleTalk cable VLAN.

Excluded ports do not leak broadcast packets. See “Broadcast Leaks” on page 11-12.

Broadcast Leaks

A dynamic port becomes a member of a Layer 3 protocol VLAN when traffic from the VLAN's protocol is received on the port. After this point, the port remains an active member of the protocol VLAN, unless the port does not receive traffic from the VLAN's protocol for 20 minutes. If the port does not receive traffic for the VLAN's protocol for 20 minutes, the port ages out and is no longer an active member of the VLAN.

To enable a host that has been silent for awhile to send and receive packets, the dynamic ports that are currently members of the Layer 3 protocol VLAN "leak" Layer 3 broadcast packets to the ports that have aged out. When a host connected to one of the aged out ports responds to a leaked broadcast, the port is added to the protocol

VLAN again.

To "leak" Layer 3 broadcast traffic, an active port sends 1/8th of the Layer 3 broadcast traffic to the inactive (aged out) ports.

Static ports do not age out and do not leak broadcast packets.

11 - 12 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

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 sub-net across multiple networks.

For an application example and configuration information, see “Configuring Super Aggregated VLANs” on page 11-43.

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 group’s lead port to a VLAN, all of the ports in the trunk group become members of that VLAN.

Summary of VLAN Configuration Rules

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.

• IP sub-net, IPX network, and AppleTalk cable VLANs are at the top of the hierarchy.

NOTE: You cannot have a protocol-based VLAN and a sub-net 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 sub-net VLAN in the same port-based VLAN, but you cannot have an IP protocol VLAN and an IP sub-net 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 Foundry device 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.

Multiple VLAN Membership Rules

• A port can belong to multiple, unique, overlapping Layer 3 protocol-based VLANs without VLAN tagging.

• 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 sub-net VLANs cannot operate concurrently on the system or within the same portbased VLAN.

• IPX protocol VLANs and IPX network VLANs cannot operate concurrently on the system or within the same port-based VLAN.

• If you first configure IP and IPX protocol VLANs before deciding to partition the network by IP sub-net and IPX network VLANs, then you need to delete those VLANs before creating the IP sub-net and IPX network

VLANs.

• One of each type of protocol VLAN is configurable within each port-based VLAN on the Layer 2 Switch.

• Multiple IP sub-net and IPX network VLANs are configurable within each port-based VLAN on the Layer 2

Switch.

December 2005 © Foundry Networks, Inc.

11 - 13

Foundry Configuration Guide for the FESX, FSX, and FWSX

• Removing a configured port-based VLAN from a Foundry Networks Layer 2 Switch or Layer 3 Switch automatically removes any protocol-based VLAN, IP sub-net VLAN, AppleTalk cable VLAN, or IPX network

VLAN, or any Virtual Ethernet router interfaces defined within the Port-based VLAN.

Routing Between VLANs

Foundry Layer 3 Switches can locally route IP, IPX, and Appletalk between VLANs defined within a single router.

All other routable protocols or protocol VLANs (for example, DecNet) must be routed by another external router capable of routing the protocol.

Virtual Routing Interfaces (Layer 3 Switches Only)

You need to configure virtual routing interfaces if an IP, IPX, or Appletalk protocol VLAN, IP sub-net VLAN,

AppleTalk cable 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 (Layer 3 Switches Only)

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 Foundry Layer 3 Switch, 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, IP sub-net, IPX protocol, IPX network, 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 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 (Layer 3 Switches

Only)

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 sub-net, IPX protocol, IPX network,

AppleTalk protocol, and AppleTalk cable VLANs.

To create any type of VLAN on a Foundry Layer 3 Switch, Layer 2 forwarding must be enabled. When Layer 2 forwarding is enabled, the Layer 3 Switch 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 consists 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.

11 - 14 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

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.

Dynamic Port Assignment (Layer 2 Switches and Layer 3 Switches)

All Switch ports are dynamically assigned to any Layer 3 VLAN on Foundry Layer 2 Switches and any nonroutable VLAN on Foundry Layer 3 Switches. To maintain explicit control of the VLAN, you can explicitly exclude ports when configuring any Layer 3 VLAN on a Foundry Layer 2 Switch or any non-routable Layer 3 VLAN on a

Foundry Layer 3 Switch.

If you do not want the ports to have dynamic membership, you can add them statically. This eliminates the need to explicitly exclude the ports that you do not want to participate in a particular Layer 3 VLAN.

Assigning a Different VLAN ID to the Default VLAN

When you enable port-based VLANs, all ports in the system are added to the default VLAN. By default, the default VLAN ID is “VLAN 1”. The default VLAN is not configurable. If you want to use the VLAN ID “VLAN 1” as a configurable VLAN, you can assign a different VLAN ID to the default VLAN.

To reassign the default VLAN to a different VLAN ID, enter the following command:

FastIron SuperX Router(config)# default-vlan-id 4095

Syntax: [no] default-vlan-d <vlan-id>

You must specify a valid VLAN ID that is not already in use. For example, if you have already defined VLAN 10, do not try to use “10” as the new VLAN ID for the default VLAN. Valid VLAN IDs are numbers from 1 – 4096.

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.

Assigning Trunk Group Ports

When a “lead” trunk group port is assigned to a VLAN, all other members of the trunk group are automatically added to that VLAN. A lead port is the first port of a trunk group port range; for example, “1” in 1 – 4 or “5” in

5 – 8. See “Trunk Group Rules” on page 10-3 for more information.

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.

This section describes how to perform the following tasks for port-based VLANs using the CLI:

• Create a VLAN

• Delete a VLAN

• Modify a VLAN

• Change a VLAN’s priority

• Enable or disable STP on the VLAN

December 2005 © Foundry Networks, Inc.

11 - 15

Foundry Configuration Guide for the FESX, FSX, and FWSX

EXAMPLE: 1

Figure 11.9 shows a simple port-based VLAN configuration using a single Foundry Layer 2 Switch. All ports within each VLAN are untagged. One untagged port within each VLAN is used to connect the Layer 2 Switch to a

Layer 3 Switch (in this example, a FSX) for Layer 3 connectivity between the two port-based VLANs.

Figure 11.9

Port-based VLANs 222 and 333 interface e 1

IP Subnet 1

IPX Network 1

Appletalk Cable-Range 100

Appletalk ZonePrepress

FSX Router

interface e 2

IP Subnet 2

IPX Network 2

Appletalk Cable-Range 200

Appletalk Zone CTP

VLAN 222

Ports 1 - 8

VLAN 333

Ports 9 - 16

Port 1 Port 9

FESX

Ports 2 - 8

IP Subnet 1

IPX Network 1

Appletalk Cable-Range 100

Appletalk ZonePrepress

Ports 9 - 16

IP Subnet 2

IPX Network 2

Appletalk Cable-Range 200

Appletalk Zone CTP

To create the two port-based VLANs shown in Figure 11.9, enter the following commands:

FESX424 Switch(config)# vlan 222 by port

FESX424 Switch(config-vlan-222)# untag e 1 to 8

FESX424 Switch(config-vlan-222)# vlan 333 by port

FESX424 Switch(config-vlan-333)# untag e 9 to 16

Syntax: vlan <vlan-id> by port

Syntax: untagged ethernet [<slotnum>/]<portnum> [to [<slotnum>/]<portnum> | ethernet [<slotnum>/]<portnum>]

EXAMPLE: 2

Figure 11.10 shows a more complex port-based VLAN configuration using multiple Layer 2 Switches and IEEE

802.1Q VLAN tagging. The backbone link connecting the three Layer 2 Switches is tagged. One untagged port within each port-based VLAN on FESX-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 FESX-A to be the root bridge for VLANs RED and BLUE. The STP priority on FESX-B is configured so that FESX-B is the root bridge for VLANs GREEN and BROWN.

11 - 16 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

Figure 11.10

More complex port-based VLAN

IP Subnet1

IPX Net 1

Atalk 100.1

Zone “A”

Port 17

FSX Router

IP Subnet2

IPX Net 2

Atalk 200.1

Zone “B”

IP Subnet3

IPX Net 3

Atalk 300.1

Zone “C”

Port 18 Port 19

FESX-A

= STP Blocked VLAN

ROOT BRIDGE

FOR

VLAN - BROWN

VLAN - GREEN

FESX-B

VLAN 2

Port 1-4

IP Sub1

IPXnet1

AT 100

Zone A

VLAN 3

Port 5-8

IP Sub2

IPXnet2

AT 200

Zone B

VLAN 4

Port 9-12

IP Sub3

IPXnet3

AT 300

Zone C

VLAN 5

Port 13-16

IP Sub4

IPXnet4

AT 400

Zone D

IP Subnet4

IPX Net 4

Atalk 400.1

Zone “D”

Port 20

ROOT BRIDGE

FOR

VLAN - BLUE

VLAN - RED

FESX-C

VLAN 2

Port 1-4

IP Sub1

IPXnet1

AT 100

Zone A

VLAN 3

Port 5-8

IP Sub2

IPXnet2

AT 200

Zone B

VLAN 4

Port 9-12

IP Sub3

IPXnet3

AT 300

Zone C

VLAN 5

Port 13-16

IP Sub4

IPXnet4

AT 400

Zone D

VLAN 2

Port 1-4

IP Sub1

IPXnet1

AT 100

Zone A

VLAN 3

Port 5-8

IP Sub2

IPXnet2

AT 200

Zone B

VLAN 4

Port 9-12

IP Sub3

IPXnet3

AT 300

Zone C

VLAN 5

Port 13-16

IP Sub4

IPXnet4

AT 400

Zone D

To configure the Port-based VLANs on the FESX Layer 2 Switches in Figure 11.10, use the following method.

Configuring FESX-A

Enter the following commands to configure FESX-A:

FESX424 Switch> enable

FESX424 Switch# configure terminal

FESX424 Switch(config)# hostname FESX-A

FESX424 Switch-A(config)# vlan 2 name BROWN

FESX424 Switch-A(config-vlan-2)# untag ethernet 1 to 4 ethernet 17

FESX424 Switch-A(config-vlan-2)# tag ethernet 25 to 26

FESX424 Switch-A(config-vlan-2)# spanning-tree

FESX424 Switch-A(config-vlan-2)# vlan 3 name GREEN

FESX424 Switch-A(config-vlan-3)# untag ethernet 5 to 8 ethernet 18

FESX424 Switch-A(config-vlan-3)# tag ethernet 25 to 26

FESX424 Switch-A(config-vlan-3)# spanning-tree

FESX424 Switch-A(config-vlan-3)# vlan 4 name BLUE

FESX424 Switch-A(config-vlan-4)# untag ethernet 9 to 12 ethernet 19

FESX424 Switch-A(config-vlan-4)# tag ethernet 25 to 26

FESX424 Switch-A(config-vlan-4)# spanning-tree

FESX424 Switch-A(config-vlan-4)# spanning-tree priority 500

FESX424 Switch-A(config-vlan-4)# vlan 5 name RED

FESX424 Switch-A(config-vlan-5)# untag ethernet 13 to 16 ethernet 20

FESX424 Switch-A(config-vlan-5)# tag ethernet 25 to 26

FESX424 Switch-A(config-vlan-5)# spanning-tree

FESX424 Switch-A(config-vlan-5)# spanning-tree priority 500

FESX424 Switch-A(config-vlan-5)# end

FESX424 Switch-A# write memory

December 2005 © Foundry Networks, Inc.

11 - 17

Foundry Configuration Guide for the FESX, FSX, and FWSX

Configuring FESX-B

Enter the following commands to configure FESX-B:

FESX424 Switch> en

FESX424 Switch# configure terminal

FESX424 Switch(config)# hostname FESX-B

FESX424 Switch-B(config)# vlan 2 name BROWN

FESX424 Switch-B(config-vlan-2)# untag ethernet 1 to 4

FESX424 Switch-B(config-vlan-2)# tag ethernet 25 to 26

FESX424 Switch-B(config-vlan-2)# spanning-tree

FESX424 Switch-B(config-vlan-2)# spanning-tree priority 500

FESX424 Switch-B(config-vlan-2)# vlan 3 name GREEN

FESX424 Switch-B(config-vlan-3)# untag ethernet 5 to 8

FESX424 Switch-B(config-vlan-3)# tag ethernet 25 to 26

FESX424 Switch-B(config-vlan-3)# spanning-tree

FESX424 Switch-B(config-vlan-3)# spanning-tree priority 500

FESX424 Switch-B(config-vlan-3)# vlan 4 name BLUE

FESX424 Switch-B(config-vlan-4)# untag ethernet 9 to 12

FESX424 Switch-B(config-vlan-4)# tag ethernet 25 to 26

FESX424 Switch-B(config-vlan-4)# vlan 5 name RED

FESX424 Switch-B(config-vlan-5)# untag ethernet 13 to 16

FESX424 Switch-B(config-vlan-5)# tag ethernet 25 to 26

FESX424 Switch-B(config-vlan-5)# end

FESX424 Switch-B# write memory

Configuring FESX-C

Enter the following commands to configure FESX-C:

FESX424 Switch> en

FESX424 Switch# configure terminal

FESX424 Switch(config)# hostname FESX-C

FESX424 Switch-C(config)# vlan 2 name BROWN

FESX424 Switch-C(config-vlan-2)# untag ethernet 1 to 4

FESX424 Switch-C(config-vlan-2)# tag ethernet 25 to 26

FESX424 Switch-C(config-vlan-2)# vlan 3 name GREEN

FESX424 Switch-C(config-vlan-3)# untag ethernet 5 to 8

FESX424 Switch-C(config-vlan-3)# tag ethernet 25 to 26

FESX424 Switch-C(config-vlan-3)# vlan 4 name BLUE

FESX424 Switch-C(config-vlan-4)# untag ethernet 9 to 12

FESX424 Switch-C(config-vlan-4)# tag ethernet 25 to 26

FESX424 Switch-C(config-vlan-4)# vlan 5 name RED

FESX424 Switch-C(config-vlan-5)# untag ethernet 13 to 16

FESX424 Switch-C(config-vlan-5)# tag ethernet 25 to 26

FESX424 Switch-C(config-vlan-5)# end

FESX424 Switch-C# write memory

Syntax: vlan <vlan-id> by port

Syntax: untagged ethernet [<slotnum>/]<portnum> [to [<slotnum>/]<portnum> | ethernet [<slotnum>/]<portnum>]

Syntax: tagged ethernet [<slotnum>/]<portnum> [to <[<slotnum>/]portnum> | ethernet [<slotnum>/]<portnum>]

Syntax: [no] spanning-tree

Syntax: spanning-tree [ethernet [<slotnum>/]<portnum> path-cost <value> priority <value>] forward-delay

<value> hello-time <value> maximum-age <time> priority <value>

Modifying a Port-Based VLAN

You can make the following modifications to a port-based VLAN:

• Add or delete a VLAN port.

11 - 18 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

• Enable or disable STP.

Removing a Port-Based VLAN

Suppose you want to remove VLAN 5 from the example in Figure 11.10. To do so, use the following procedure.

1.

Access the global CONFIG level of the CLI on FESX-A by entering the following commands:

FESX424 Switch-A> enable

No password has been assigned yet...

FESX424 Switch-A# configure terminal

FESX424 Switch-A(config)#

2.

Enter the following command:

FESX424 Switch-A(config)# no vlan 5

FESX424 Switch-A(config)#

3.

Enter the following commands to exit the CONFIG level and save the configuration to the system-config file on flash memory:

FESX424 Switch-A(config)#

FESX424 Switch-A(config)# end

FESX424 Switch-A# write memory

FESX424 Switch-A#

4.

Repeat steps 1 – 3 on FESX-B.

Syntax: no vlan <vlan-id> by port

Removing a Port from a VLAN

Suppose you want to remove port 11 from VLAN 4 on FESX-A shown in Figure 11.10. To do so, use the following procedure.

1.

Access the global CONFIG level of the CLI on FESX424 Switch-A by entering the following command:

FESX424 Switch-A> enable

No password has been assigned yet...

FESX424 Switch-A# configure terminal

FESX424 Switch-A(config)#

2.

Access the level of the CLI for configuring port-based VLAN 4 by entering the following command:

FESX424 Switch-A(config)#

FESX424 Switch-A(config)# vlan 4

FESX424 Switch-A(config-vlan-4)#

3.

Enter the following commands:

FESX424 Switch-A(config-vlan-4)#

FESX424 Switch-A(config-vlan-4)# no untag ethernet 11 deleted port ethe 11 from port-vlan 4.

FESX424 Switch-A(config-vlan-4)#

4.

Enter the following commands to exit the VLAN CONFIG mode and save the configuration to the systemconfig file on flash memory:

FESX424 Switch-A(config-vlan-4)#

FESX424 Switch-A(config-vlan-4)# end

FESX424 Switch-A# write memory

You can remove all the ports from a port-based VLAN without losing the rest of the VLAN’s configuration.

However, you cannot configure an IP address on a virtual routing interface unless the VLAN contains ports. If the

December 2005 © Foundry Networks, Inc.

11 - 19

Foundry Configuration Guide for the FESX, FSX, and FWSX

VLAN has a virtual routing interface, the virtual routing interface’s IP address is deleted when the ports associated with the interface are deleted. The rest of the VLAN configuration is retained.

Enable Spanning Tree on a VLAN

The spanning tree bridge and port parameters are configurable using one CLI command set at the Global

Configuration Level of each Port-based VLAN. Suppose you want to enable the IEEE 802.1d STP across VLAN 3.

To do so, use the following method.

NOTE: When port-based VLANs are not operating on the system, STP is set on a system-wide level at the global CONFIG level of the CLI.

1.

Access the global CONFIG level of the CLI on FESX-A by entering the following commands:

FESX424 Switch-A> enable

No password has been assigned yet...

FESX424 Switch-A# configure terminal

FESX424 Switch-A(config)#

2.

Access the level of the CLI for configuring port-based VLAN 3 by entering the following command:

FESX424 Switch-A(config)#

FESX424 Switch-A(config)# vlan 3

FESX424 Switch-A(config-vlan-3)#

3.

From VLAN 3’s configuration level of the CLI, enter the following command to enable STP on all tagged and untagged ports associated with VLAN 3.

FESX424 Switch-B(config-vlan-3)#

FESX424 Switch-B(config-vlan-3)# spanning-tree

FESX424 Switch-B(config-vlan-3)#

4.

Enter the following commands to exit the VLAN CONFIG mode and save the configuration to the systemconfig file on flash memory:

FESX424 Switch-B(config-vlan-3)#

FESX424 Switch-B(config-vlan-3)# end

FESX424 Switch-B# write memory

FESX424 Switch-B#

5.

Repeat steps 1 – 4 on FESX-B.

NOTE: You do not need to configure values for the STP parameters. All parameters have default values as noted below. Additionally, all values will be globally applied to all ports on the system or on the port-based VLAN for which they are defined.

To configure a specific path-cost or priority value for a given port, enter those values using the key words in the brackets [ ] shown in the syntax summary below. If you do not want to specify values for any given port, this portion of the command is not required.

Syntax: vlan <vlan-id> by port

Syntax: [no] spanning-tree

Syntax: spanning-tree [ethernet [<slotnum>/]<portnum> path-cost <value> priority <value>] forward-delay

<value> hello-time <value> maximum-age <time> priority <value>

Bridge STP Parameters (applied to all ports within a VLAN)

• Forward Delay – the period of time a bridge will wait (the listen and learn period) before forwarding data packets. Possible values: 4 – 30 seconds. Default is 15.

• Maximum Age – the interval a bridge will wait for receipt of a hello packet before initiating a topology change.

Possible values: 6 – 40 seconds. Default is 20.

• Hello Time – the interval of time between each configuration BPDU sent by the root bridge. Possible values:

11 - 20 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

1 – 10 seconds. Default is 2.

• Priority – a parameter used to identify the root bridge in a network. The bridge with the lowest value has the highest priority and is the root. Possible values: 1 – 65,535. Default is 32,678.

Port Parameters (applied to a specified port within a VLAN)

• Path Cost – a parameter used to assign a higher or lower path cost to a port. Possible values: 1 – 65535.

Default is (1000/Port Speed) for Half-Duplex ports and is (1000/Port Speed)/2 for Full-Duplex ports.

• Priority – value determines when a port will be rerouted in relation to other ports. Possible values: 0 – 255.

Default is 128.

Configuring IP Sub-net, IPX Network and Protocol-Based VLANs

Protocol-based VLANs provide the ability to define separate broadcast domains for several unique Layer 3 protocols 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 end-stations, servers, and routers need to accept.

Configuration Example

Suppose you want to create five separate Layer 3 broadcast domains within a single Layer 2 STP broadcast domain:

• Three broadcast domains, one for each of three separate IP sub-nets

• One for IPX Network 1

• One for the Appletalk protocol

Also suppose you want a single router interface to be present within all of these separate broadcast domains, without using IEEE 802.1Q VLAN tagging or any proprietary form of VLAN tagging.

December 2005 © Foundry Networks, Inc.

11 - 21

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 11.11 shows this configuration.

Figure 11.11

Protocol-based (Layer 3) VLANs

FSX Router

Port 25

IP-Subnet 1

IP-Subnet 2

IP Subnet 3

IPX Net 1

Appletalk Cable 100

Port 25

FESX

IP-Subnet 1 IP-Subnet 2 IP-Subnet 3

Ports 1-16, 25

IPX Net 1

Ports 17-25

Appletalk Cable 100

To configure the VLANs shown in Figure 11.11, use the following procedure.

1.

To permanently assign ports 1 – 8 and port 25 to IP sub-net VLAN 1.1.1.0, enter the following commands:

FESX424 Switch> en

No password has been assigned yet...

FESX424 Switch# config t

FESX424 Switch(config)#

FESX424 Switch(config)# ip-subnet 1.1.1.0/24 name Green

FESX424 Switch(config-ip-subnet)# no dynamic

FESX424 Switch(config-ip-subnet)# static ethernet 1 to 8 ethernet 25

2.

To permanently assign ports 9 – 16 and port 25 to IP sub-net VLAN 1.1.2.0, enter the following commands:

FESX424 Switch(config-ip-subnet)# ip-subnet 1.1.2.0/24 name Yellow

FESX424 Switch(config-ip-subnet)# no dynamic

FESX424 Switch(config-ip-subnet)# static ethernet 9 to 16 ethernet 25

3.

To permanently assign ports 17 – 25 to IP sub-net VLAN 1.1.3.0, enter the following commands:

FESX424 Switch(config-ip-subnet)# ip-subnet 1.1.3.0/24 name Brown

FESX424 Switch(config-ip-subnet)# no dynamic

FESX424 Switch(config-ip-subnet)# static ethernet 17 to 25

4.

To permanently assign ports 1 – 12 and port 25 to IPX network 1 VLAN, enter the following commands:

FESX424 Switch(config-ip-subnet)# ipx-network 1 ethernet_802.3 name Blue

FESX424 Switch(config-ipx-network)# no dynamic

11 - 22 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

FESX424 Switch(config-ipx-network)# static ethernet 1 to 12 ethernet 25

FESX424 Switch(config-ipx-network)#

5.

To permanently assign ports 12 – 25 to Appletalk VLAN, enter the following commands:

FESX424 Switch(config-ipx-proto)# atalk-proto name Red

FESX424 Switch(config-atalk-proto)# no dynamic

FESX424 Switch(config-atalk-proto)# static ethernet 13 to 25

FESX424 Switch(config-atalk-proto)# end

FESX424 Switch# write memory

FESX424 Switch#

Syntax: ip-subnet <ip-addr> <ip-mask> [name <string>]

Syntax: ipx-network <ipx-network-number> <frame-encapsulation-type> netbios-allow | netbios-disallow

[name <string>]

Syntax: ip-proto | ipx-proto | atalk-proto | decnet-proto | netbios-proto | other-proto static | exclude | dynamic ethernet [<slotnum>/]<portnum> [to [<slotnum>/]<portnum>] [name <string>]

Configuring IP Sub-net, IPX Network, and

Protocol-Based VLANs Within Port-Based VLANs

If you plan to use port-based VLANs in conjunction with protocol-based VLANs, you must create the port-based

VLANs first. Once you create a port-based VLAN, then you can assign Layer 3 protocol VLANs within the boundaries of the port-based VLAN. Generally, you create port-based VLANs to allow multiple separate STP domains.

EXAMPLE:

Suppose you need to provide three separate STP domains across an enterprise campus backbone. The first STP domain (VLAN 2) requires a set of ports at each Layer 2 Switch location to be statically mapped to IP only. No other protocols can enter the switches on this set of ports.

A second set of ports within STP domain VLAN 2 will be restricted to only IPX traffic. The IP and IPX protocol

VLANs will overlap on Port 1 of FESX-A to support both protocols on the same router interface. The IP sub-nets and IPX network that span the two protocol VLANs will be determined by the NetIron router configuration. The IP and IPX Protocol VLANs ensure that only the ports included in the each Layer 3 protocol VLAN will see traffic from the NetIron router.

The second STP domain (VLAN 3) requires that half the ports in the domain are dedicated to IP sub-net 1.1.1.0/

24 and the other ports are dedicated to IPX network 1. Similar to VLAN 2, Port 9 from VLAN 3 will be used to carry this IP sub-net and IPX network to the NetIron router. No other protocols will be allowed to enter the network on VLAN 3. Also, no IP packets with a source address on sub-net 1.1.1.0/24 or IPX packets with a source address on network 1 will be allowed to enter the switches on VLAN 3.

There is no need to segment Layer 3 broadcast domains within the STP broadcast domain (VLAN 4). The NetIron router will dictate the IP sub-nets and IPX network that are on VLAN 4. There are no Layer 3 protocol restrictions on VLAN 4; however, the NetIron router is configured to only forward IP and IPX between STP domains.

December 2005 © Foundry Networks, Inc.

11 - 23

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 11.12

More protocol-based VLANs

Port 1

FSX Router

Port 9 Port 17

FESX-A

VLAN 2 VLAN 3 VLAN 4

V2 V3 V4

FESX-B

VLAN 2 VLAN 3 VLAN 4

= STP Blocked VLAN

FESX-C

VLAN 2 VLAN 3 VLAN 4

To configure the Layer 3 VLANs on the FESX Layer 2 Switches in Figure 11.12, use the following procedure.

Configuring FESX-A

Enter the following commands to configure FESX-A:

1.

Create port-based VLAN 2 and assign the untagged and tagged ports that will participate in this VLAN:

FESX424 Switch-A >en

FESX424 Switch-A# config t

FESX424 Switch-A(config)# vlan 2 name IP_IPX_Protocol

FESX424 Switch-A(config-vlan-2)# untag e1 to 8

FESX424 Switch-A(config-vlan-2)# tag e25 to 26

2.

Enable STP and set the priority to force FESX-A to be the root bridge for VLAN 2:

FESX424 Switch-A(config-vlan-2)# spanning-tree

FESX424 Switch-A(config-vlan-2)# spanning-tree priority 500

FESX424 Switch-A(config-vlan-2)#

3.

Create the IP and IPX protocol-based VLANs and statically assign the ports within VLAN 2 that will be associated with each protocol-based VLAN:

FESX424 Switch-A(config-vlan-2)# ip-proto name Red

FESX424 Switch-A(config-vlan-ip-proto)# no dynamic

FESX424 Switch-A(config-vlan-ip-proto)# static e1 to 4 e25 to 26

FESX424 Switch-A(config-vlan-ip-proto)# exclude e5 to 8

FESX424 Switch-A(config-vlan-ip-proto)# ipx-proto name Blue

FESX424 Switch-A(config-vlan-ipx-proto)# no dynamic

FESX424 Switch-A(config-vlan-ipx-proto)# static e1 e5 to 8 e25 to 26

11 - 24 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

FESX424 Switch-A(config-vlan-ipx-proto)# exclude e2 to 4

4.

To prevent machines with non-IP protocols from getting into the IP portion of VLAN 2, create another Layer 3 protocol VLAN to exclude all other protocols from the ports that contains the IP-protocol VLAN. To do so, enter the following commands:

FESX424 Switch-A(config-vlan-ipx-proto)# other-proto name Block_other_proto

FESX424 Switch-A(config-vlan-other-proto)# no dynamic

FESX424 Switch-A(config-vlan-other-proto)# exclude e1 to 8

FESX424 Switch-A(config-vlan-other-proto)#

5.

Create port-based VLAN 3. Note that FESX-B will be the root for this STP domain, so you do not need to adjust the STP priority.

FESX424 Switch-A(config-vlan-other-proto)# vlan 3 name IP-Sub_IPX-Net_Vlans

FESX424 Switch-A(config-vlan-3)# untag e9 to 16

FESX424 Switch-A(config-vlan-3)# tag e25 to 26

FESX424 Switch-A(config-vlan-3)# spanning-tree

FESX424 Switch-A(config-vlan-3)#

6.

Create IP sub-net VLAN 1.1.1.0/24, IPX network 1, and other-protocol VLANs

FESX424 Switch-A(config-vlan-3)# ip-subnet 1.1.1.0/24 name Green

FESX424 Switch-A(config-vlan-ip-subnet)# no dynamic

FESX424 Switch-A(config-vlan-ip-subnet)# static e9 to 12 e25 to 26

FESX424 Switch-A(config-vlan-ip-subnet)# exclude e13 to 16

FESX424 Switch-A(config-vlan-ip-subnet)# ipx-net 1 ethernet_802.3 name Brown

FESX424 Switch-A(config-vlan-ipx-network)# no dynamic

FESX424 Switch-A(config-vlan-ipx-network)# static e9 e13 to 16 e25 to 26

FESX424 Switch-A(config-vlan-ipx-network)# exclude e10 to 12

FESX424 Switch-A(config-vlan-ipx-network)# other-proto name Block_other_proto

FESX424 Switch-A(config-vlan-other-proto)# no dynamic

FESX424 Switch-A(config-vlan-other-proto)# exclude e9 to 16

FESX424 Switch-A(config-vlan-other-proto)#

7.

Configure the last port-based VLAN 4. You need to set the STP priority for this VLAN because FESX-A will be the root bridge for this VLAN. Since you do not need to partition this STP domain into multiple Layer 3 broadcast domains, this is the only configuration required for VLAN 4:

FESX424 Switch-A(config-vlan-other-proto)# vlan 4 name Purple_ALL-Protocols

FESX424 Switch-A(config-vlan-4)# untag e17 to 24

FESX424 Switch-A(config-vlan-4)# tag e25 to 26

FESX424 Switch-A(config-vlan-4)# spanning-tree

FESX424 Switch-A(config-vlan-4)# spanning-tree priority 500

FESX424 Switch-A(config-vlan-4)#

Configuring FESX-B

Enter the following commands to configure FESX-B:

FESX424 Switch# config t

FESX424 Switch(config)# host FESX424 Switch-B

FESX424 Switch-B(config)# vlan 2 name IP_IPX_Protocol

FESX424 Switch-B(config-vlan-2)# untag e1 to 8

FESX424 Switch-B(config-vlan-2)# tag e25 to 26

FESX424 Switch-B(config-vlan-2)# spanning-tree

FESX424 Switch-B(config-vlan-2)# ip-proto name Red

FESX424 Switch-B(config-vlan-ip-proto)# no dynamic

FESX424 Switch-B(config-vlan-ip-proto)# static e1 to 4 e25 to 26

FESX424 Switch-B(config-vlan-ip-proto)# exclude e5 to 8

FESX424 Switch-B(config-vlan-ip-proto)# ipx-proto name Blue

FESX424 Switch-B(config-vlan-ipx-proto)# no dynamic

FESX424 Switch-B(config-vlan-ipx-proto)# static e5 to 8 e25 to 26

FESX424 Switch-B(config-vlan-ipx-proto)# exclude e1 to 4

December 2005 © Foundry Networks, Inc.

11 - 25

Foundry Configuration Guide for the FESX, FSX, and FWSX

FESX424 Switch-B(config-vlan-other-proto)# vlan 3 name IP-Sub_IPX-Net_VLANs

FESX424 Switch-B(config-vlan-3)# untag e9 to 16

FESX424 Switch-B(config-vlan-3)# tag e25 to 26

FESX424 Switch-B(config-vlan-3)# spanning-tree

FESX424 Switch-B(config-vlan-3)# spanning-tree priority 500

FESX424 Switch-B(config-vlan-3)# ip-sub 1.1.1.0/24 name Green

FESX424 Switch-B(config-vlan-ip-subnet)# no dynamic

FESX424 Switch-B(config-vlan-ip-subnet)# static e9 to 12 e25 to 26

FESX424 Switch-B(config-vlan-ip-subnet)# exclude e13 to 16

FESX424 Switch-B(config-vlan-ip-subnet)# ipx-net 1 ethernet_802.3 name Brown

FESX424 Switch-B(config-vlan-ipx-network)# no dynamic

FESX424 Switch-B(config-vlan-ipx-network)# static e13 to 16 e25 to 26

FESX424 Switch-B(config-vlan-ipx-network)# exclude e9 to 12

FESX424 Switch-B(config-vlan-ipx-network)# vlan 4 name Purple_ALL-Protocols

FESX424 Switch-B(config-vlan-4)# untag e17 to 24

FESX424 Switch-B(config-vlan-4)# tag e25 to 26

FESX424 Switch-B(config-vlan-4)# spanning-tree

Configuring FESX-C

Enter the following commands to configure FESX-C:

FESX424 Switch# config t

FESX424 Switch(config)# host FESX424 Switch-C

FESX424 Switch-C(config)# vlan 2 name IP_IPX_Protocol

FESX424 Switch-C(config-vlan-2)# untag e1 to 8

FESX424 Switch-C(config-vlan-2)# tag e25 to 26

FESX424 Switch-C(config-vlan-2)# spanning-tree

FESX424 Switch-C(config-vlan-2)# ip-proto name Red

FESX424 Switch-C(config-vlan-ip-proto)# no dynamic

FESX424 Switch-C(config-vlan-ip-proto)# static e1 to 4 e25 to 26

FESX424 Switch-C(config-vlan-ip-proto)# exclude e5 to 8

FESX424 Switch-C(config-vlan-ip-proto)# ipx-proto name Blue

FESX424 Switch-C(config-vlan-ipx-proto)# no dynamic

FESX424 Switch-C(config-vlan-ipx-proto)# static e5 to 8 e25 to 26

FESX424 Switch-C(config-vlan-ipx-proto)# exclude e1 to 4

FESX424 Switch-C(config-vlan-other-proto)# vlan 3 name IP-Sub_IPX-Net_VLANs

FESX424 Switch-C(config-vlan-3)# untag e9 to 16

FESX424 Switch-C(config-vlan-3)# tag e25 to 26

FESX424 Switch-C(config-vlan-3)# spanning-tree

FESX424 Switch-C(config-vlan-3)# ip-sub 1.1.1.0/24 name Green

FESX424 Switch-C(config-vlan-ip-subnet)# no dynamic

FESX424 Switch-C(config-vlan-ip-subnet)# static e9 to 12 e25 to 26

FESX424 Switch-C(config-vlan-ip-subnet)# exclude e13 to 16

FESX424 Switch-C(config-vlan-ip-subnet)# ipx-net 1 ethernet_802.3 name Brown

FESX424 Switch-C(config-vlan-ipx-network)# no dynamic

FESX424 Switch-C(config-vlan-ipx-network)# static e13 to 16 e25 to 26

FESX424 Switch-C(config-vlan-ipx-network)# exclude e9 to 12

FESX424 Switch-C(config-vlan-ipx-network)# vlan 4 name Purple_ALL-Protocols

FESX424 Switch-C(config-vlan-4)# untag e17 to 24

FESX424 Switch-C(config-vlan-4)# tag e25 to 26

FESX424 Switch-C(config-vlan-4)# spanning-tree

Configuring an IPv6 Protocol VLAN

You can configure a protocol-based VLAN as a broadcast domain for IPv6 traffic. When the Layer 3 Switch receives an IPv6 multicast packet (a packet with 06 in the version field and 0xFF as the beginning of the destination address), the Layer 3 Switch forwards the packet to all other ports in the VLAN.

11 - 26 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

NOTE: The Layer 3 Switch forwards all IPv6 multicast packets to all ports in the VLAN except the port that received the packet, and does not distinguish among sub-net directed multicasts.

You can add the VLAN ports as static ports or dynamic ports. A static port is always an active member of the

VLAN. Dynamic ports within any protocol VLAN age out after 10 minutes, if no member protocol traffic is received on a port within the VLAN. The aged out port, however, remains as a candidate dynamic port for that VLAN. The port becomes active in the VLAN again if member protocol traffic is received on that port.

Once a port is re-activated, the aging out period for the port is reset to 20 minutes. Each time a member protocol packet is received by a candidate dynamic port (aged out port) the port becomes active again and the aging out period is reset for 20 minutes.

To configure an IPv6 VLAN, enter commands such as the following:

FastIron SuperX Router(config)# vlan 2

FastIron SuperX Router(config-vlan-2)# untag ethernet 1/1 to 1/8

FastIron SuperX Router(config-vlan-2)# ipv6-proto name V6

FastIron SuperX Router(config-ipv6-subnet)# static ethernet 1/1 to 1/6

FastIron SuperX Router(config-ipv6-subnet)# dynamic

The first two commands configure a port-based VLAN and add ports 1/1 – 1/8 to the VLAN. The remaining commands configure an IPv6 VLAN within the port-based VLAN. The static command adds ports 1/1 – 1/6 as static ports, which do not age out. The dynamic command adds the remaining ports, 1/7 – 1/8, as dynamic ports.

These ports are subject to aging as described above.

Syntax: [no] ipv6-proto [name <string>]

Routing Between VLANs Using Virtual Routing Interfaces (Layer 3

Switches Only)

Foundry Layer 3 Switches offer the ability to create a virtual routing interface within a Layer 2 STP port-based

VLAN or within each Layer 3 protocol, IP sub-net, 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 sub-nets and

IPX networks for each backbone link.

You also need to create unique IP sub-nets 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 sub-net 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 NetIron-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 sub-nets and IPX networks will be fully routed and have use of all paths at all times during normal operation.

Figure 11.13 shows the configuration described above.

December 2005 © Foundry Networks, Inc.

11 - 27

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 11.13

Routing between protocol-based VLANs

Building 1

FESX-A

V5 IP/IPX V4 V5 IP/IPX V4 V5 IP/IPX

Vlan2 Vlan8 Vlan 3 Vlan 4

Building 2

FESX-B

Vlan2 Vlan8 Vlan 3 Vlan 4

V6 IP/IPX

FESX-C

V7 IP/IPX V4

Vlan2 Vlan8 Vlan 3 Vlan 4

Building 3

= STP Blocked VLAN

To configure the Layer 3 VLANs and virtual routing interfaces on the NetIron Layer 3 Switch in Figure 11.13, use the following procedure.

Configuring NetIron-A

Enter the following commands to configure FESX-A. The following commands enable OSPF or RIP routing.

FESX424 Router> en

No password has been assigned yet...

FESX424 Router# configure terminal

FESX424 Router(config)# hostname FESX-A

FESX424 Router-A(config)# router ospf

FESX424 Router-A(config-ospf-router)# area 0.0.0.0 normal

Please save configuration to flash and reboot.

FESX424 Router-A(config-ospf-router)#

The following commands create the port-based VLAN 2. In the previous example, an external FESX defined the router interfaces for VLAN 2. With ISR, routing for VLAN 2 is done locally within each FESX. Therefore, there are two ways you can solve this problem. One way is to create a unique IP sub-net and IPX network VLAN, each with its own virtual routing interface and unique IP or IPX address within VLAN 2 on each FESX. In this example, this is the configuration used for VLAN 3. The second way is to split VLAN 2 into two separate port-based 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.

FESX424 Router-A(config-ospf-router)# vlan 2 name IP-Subnet_1.1.2.0/24

FESX424 Router-A(config-vlan-2)# untag e 1 to 4

FESX424 Router-A(config-vlan-2)# no spanning-tree

FESX424 Router-A(config-vlan-2)# router-interface ve1

11 - 28 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

FESX424 Router-A(config-vlan-2)# other-proto name block_other_protocols

FESX424 Router-A(config-vlan-other-proto)# no dynamic

FESX424 Router-A(config-vlan-other-proto)# exclude e 1 to 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.

FESX424 Router-A(config-vlan-other-proto)# interface ve1

FESX424 Router-A(config-vif-1)# ip address 1.1.2.1/24

FESX424 Router-A(config-vif-1)# ip ospf area 0.0.0.0

Do the same thing for VLAN 8.

FESX424 Router-A(config-vif-1)# vlan 8 name IPX_Network2

FESX424 Router-A(config-vlan-8)# untag ethernet 5 to 8

FESX424 Router-A(config-vlan-8)# no spanning-tree

FESX424 Router-A(config-vlan-8)# router-interface ve 2

FESX424 Router-A(config-vlan-8)# other-proto name block-other-protocols

FESX424 Router-A(config-vlan-other-proto)# no dynamic

FESX424 Router-A(config-vlan-other-proto)# exclude ethernet 5 to 8

FESX424 Router-A(config-vlan-other-proto)# int ve2

FESX424 Router-A(config-vif-2)# ipx network 2 ethernet_802.3

FESX424 Router-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 sub-net and IPX network VLANs. Also there is no need to exclude ports from the IP sub-net and IPX network VLANs on the router.

FESX424 Router-A(config-vif-2)# vlan 3 name IP_Sub_&_IPX_Net_VLAN

FESX424 Router-A(config-vlan-3)# untag e 9 to 16

FESX424 Router-A(config-vlan-3)# no spanning-tree

FESX424 Router-A(config-vlan-3)# ip-subnet 1.1.1.0/24

FESX424 Router-A(config-vlan-ip-subnet)# static e 9 to 12

FESX424 Router-A(config-vlan-ip-subnet)# router-interface ve3

FESX424 Router-A(config-vlan-ip-subnet)# ipx-network 1 ethernet_802.3

FESX424 Router-A(config-vlan-ipx-network)# static e 13 to 16

FESX424 Router-A(config-vlan-ipx-network)# router-interface ve4

FESX424 Router-A(config-vlan-ipx-network)# other-proto name block-other-protocols

FESX424 Router-A(config-vlan-other-proto)# exclude e 9 to 16

FESX424 Router-A(config-vlan-other-proto)# no dynamic

FESX424 Router-A(config-vlan-other-proto)# interface ve 3

FESX424 Router-A(config-vif-3)# ip addr 1.1.1.1/24

FESX424 Router-A(config-vif-3)# ip ospf area 0.0.0.0

FESX424 Router-A(config-vif-3)# int ve4

FESX424 Router-A(config-vif-4)# ipx network 1 ethernet_802.3

FESX424 Router-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 FESX. In this example, FESX-A will provide the routing services for VLAN 4. You also want to configure the STP priority for VLAN 4 to make FESX-A the root bridge for this VLAN.

FESX424 Router-A(config-vif-4)# vlan 4 name Bridged_ALL_Protocols

FESX424 Router-A(config-vlan-4)# untag ethernet 17 to 24

FESX424 Router-A(config-vlan-4)# tag ethernet 25 to 26

FESX424 Router-A(config-vlan-4)# spanning-tree

FESX424 Router-A(config-vlan-4)# spanning-tree priority 500

FESX424 Router-A(config-vlan-4)# router-interface ve5

FESX424 Router-A(config-vlan-4)# int ve5

FESX424 Router-A(config-vif-5)# ip address 1.1.3.1/24

FESX424 Router-A(config-vif-5)# ip ospf area 0.0.0.0

FESX424 Router-A(config-vif-5)# ipx network 3 ethernet_802.3

December 2005 © Foundry Networks, Inc.

11 - 29

Foundry Configuration Guide for the FESX, FSX, and FWSX

FESX424 Router-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. This is the configuration used in the example in

“Configuring IP Sub-net, IPX Network and Protocol-Based VLANs” on page 11-21. 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.

FESX424 Router-A(config-vif-5)# vlan 5 name Rtr_BB_to_Bldg.2

FESX424 Router-A(config-vlan-5)# tag e 25

FESX424 Router-A(config-vlan-5)# no spanning-tree

FESX424 Router-A(config-vlan-5)# router-interface ve6

FESX424 Router-A(config-vlan-5)# vlan 6 name Rtr_BB_to_Bldg.3

FESX424 Router-A(config-vlan-6)# tag ethernet 26

FESX424 Router-A(config-vlan-6)# no spanning-tree

FESX424 Router-A(config-vlan-6)# router-interface ve7

FESX424 Router-A(config-vlan-6)# int ve6

FESX424 Router-A(config-vif-6)# ip addr 1.1.4.1/24

FESX424 Router-A(config-vif-6)# ip ospf area 0.0.0.0

FESX424 Router-A(config-vif-6)# ipx network 4 ethernet_802.3

FESX424 Router-A(config-vif-6)# int ve7

FESX424 Router-A(config-vif-7)# ip addr 1.1.5.1/24

FESX424 Router-A(config-vif-7)# ip ospf area 0.0.0.0

FESX424 Router-A(config-vif-7)# ipx network 5 ethernet_802.3

FESX424 Router-A(config-vif-7)#

This completes the configuration for FESX-A. The configuration for FESX-B and C is very similar except for a few issues.

• IP sub-nets and IPX networks configured on FESX-B and FESX-C must be unique across the entire network, except for the backbone port-based VLANs 5, 6, and 7 where the sub-net 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 FESX-B and FESX-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.

Configuration for FESX-B

Enter the following commands to configure FESX-B.

FESX424 Router> en

No password has been assigned yet...

FESX424 Router# config t

FESX424 Router(config)# hostname FESX-B

FESX424 Router-B(config)# router ospf

FESX424 Router-B(config-ospf-router)# area 0.0.0.0 normal

FESX424 Router-B(config-ospf-router)# router ipx

FESX424 Router-B(config-ospf-router)# vlan 2 name IP-Subnet_1.1.6.0/24

FESX424 Router-B(config-vlan-2)# untag e 1 to 4

FESX424 Router-B(config-vlan-2)# no spanning-tree

FESX424 Router-B(config-vlan-2)# router-interface ve1

FESX424 Router-B(config-vlan-2)# other-proto name block-other-protocols

FESX424 Router-B(config-vlan-other-proto)# no dynamic

FESX424 Router-B(config-vlan-other-proto)# exclude e 1 to 4

FESX424 Router-B(config-vlan-other-proto)# int ve1

FESX424 Router-B(config-vif-1)# ip addr 1.1.6.1/24

FESX424 Router-B(config-vif-1)# ip ospf area 0.0.0.0

11 - 30 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

FESX424 Router-B(config-vif-1)# vlan 8 name IPX_Network6

FESX424 Router-B(config-vlan-8)# untag e 5 to 8

FESX424 Router-B(config-vlan-8)# no span

FESX424 Router-B(config-vlan-8)# router-int ve2

FESX424 Router-B(config-vlan-8)# other-proto name block-other-protocols

FESX424 Router-B(config-vlan-other-proto)# no dynamic

FESX424 Router-B(config-vlan-other-proto)# exclude e 5 to 8

FESX424 Router-B(config-vlan-other-proto)# int ve2

FESX424 Router-B(config-vif-2)# ipx net 6 ethernet_802.3

FESX424 Router-B(config-vif-2)# vlan 3 name IP_Sub_&_IPX_Net_VLAN

FESX424 Router-B(config-vlan-3)# untag e 9 to 16

FESX424 Router-B(config-vlan-3)# no spanning-tree

FESX424 Router-B(config-vlan-3)# ip-subnet 1.1.7.0/24

FESX424 Router-B(config-vlan-ip-subnet)# static e 9 to 12

FESX424 Router-B(config-vlan-ip-subnet)# router-interface ve3

FESX424 Router-B(config-vlan-ip-subnet)# ipx-network 7 ethernet_802.3

FESX424 Router-B(config-vlan-ipx-network)# static e 13 to 16

FESX424 Router-B(config-vlan-ipx-network)# router-interface ve4

FESX424 Router-B(config-vlan-ipx-network)# other-proto name block-other-protocols

FESX424 Router-B(config-vlan-other-proto)# exclude e 9 to 16

FESX424 Router-B(config-vlan-other-proto)# no dynamic

FESX424 Router-B(config-vlan-other-proto)# interface ve 3

FESX424 Router-B(config-vif-3)# ip addr 1.1.7.1/24

FESX424 Router-B(config-vif-3)# ip ospf area 0.0.0.0

FESX424 Router-B(config-vif-3)# int ve4

FESX424 Router-B(config-vif-4)# ipx network 7 ethernet_802.3

FESX424 Router-B(config-vif-4)# vlan 4 name Bridged_ALL_Protocols

FESX424 Router-B(config-vlan-4)# untag ethernet 17 to 24

FESX424 Router-B(config-vlan-4)# tag ethernet 25 to 26

FESX424 Router-B(config-vlan-4)# spanning-tree

FESX424 Router-B(config-vlan-4)# vlan 5 name Rtr_BB_to_Bldg.1

FESX424 Router-B(config-vlan-5)# tag e 25

FESX424 Router-B(config-vlan-5)# no spanning-tree

FESX424 Router-B(config-vlan-5)# router-interface ve5

FESX424 Router-B(config-vlan-5)# vlan 7 name Rtr_BB_to_Bldg.3

FESX424 Router-B(config-vlan-7)# tag ethernet 26

FESX424 Router-B(config-vlan-7)# no spanning-tree

FESX424 Router-B(config-vlan-7)# router-interface ve6

FESX424 Router-B(config-vlan-7)# int ve5

FESX424 Router-B(config-vif-5)# ip addr 1.1.4.2/24

FESX424 Router-B(config-vif-5)# ip ospf area 0.0.0.0

FESX424 Router-B(config-vif-5)# ipx network 4 ethernet_802.3

FESX424 Router-B(config-vif-5)# int ve6

FESX424 Router-B(config-vif-6)# ip addr 1.1.8.1/24

FESX424 Router-B(config-vif-6)# ip ospf area 0.0.0.0

FESX424 Router-B(config-vif-6)# ipx network 8 ethernet_802.3

FESX424 Router-B(config-vif-6)#

Configuration for FESX-C

Enter the following commands to configure FESX-C.

FESX424 Router> en

No password has been assigned yet...

FESX424 Router# config t

FESX424 Router(config)# hostname FESX-C

FESX424 Router-C(config)# router ospf

FESX424 Router-C(config-ospf-router)# area 0.0.0.0 normal

FESX424 Router-C(config-ospf-router)# router ipx

FESX424 Router-C(config-ospf-router)# vlan 2 name IP-Subnet_1.1.9.0/24

December 2005 © Foundry Networks, Inc.

11 - 31

Foundry Configuration Guide for the FESX, FSX, and FWSX

FESX424 Router-C(config-vlan-2)# untag e 1 to 4

FESX424 Router-C(config-vlan-2)# no spanning-tree

FESX424 Router-C(config-vlan-2)# router-interface ve1

FESX424 Router-C(config-vlan-2)# other-proto name block-other-protocols

FESX424 Router-C(config-vlan-other-proto)# no dynamic

FESX424 Router-C(config-vlan-other-proto)# exclude e 1 to 4

FESX424 Router-C(config-vlan-other-proto)# int ve1

FESX424 Router-C(config-vif-1)# ip addr 1.1.9.1/24

FESX424 Router-C(config-vif-1)# ip ospf area 0.0.0.0

FESX424 Router-C(config-vif-1)# vlan 8 name IPX_Network9

FESX424 Router-C(config-vlan-8)# untag e 5 to 8

FESX424 Router-C(config-vlan-8)# no span

FESX424 Router-C(config-vlan-8)# router-int ve2

FESX424 Router-C(config-vlan-8)# other-proto name block-other-protocols

FESX424 Router-C(config-vlan-other-proto)# no dynamic

FESX424 Router-C(config-vlan-other-proto)# exclude e 5 to 8

FESX424 Router-C(config-vlan-other-proto)# int ve2

FESX424 Router-C(config-vif-2)# ipx net 9 ethernet_802.3

FESX424 Router-C(config-vif-2)# vlan 3 name IP_Sub_&_IPX_Net_VLAN

FESX424 Router-C(config-vlan-3)# untag e 9 to 16

FESX424 Router-C(config-vlan-3)# no spanning-tree

FESX424 Router-C(config-vlan-3)# ip-subnet 1.1.10.0/24

FESX424 Router-C(config-vlan-ip-subnet)# static e 9 to 12

FESX424 Router-C(config-vlan-ip-subnet)# router-interface ve3

FESX424 Router-C(config-vlan-ip-subnet)# ipx-network 10 ethernet_802.3

FESX424 Router-C(config-vlan-ipx-network)# static e 13 to 16

FESX424 Router-C(config-vlan-ipx-network)# router-interface ve4

FESX424 Router-C(config-vlan-ipx-network)# other-proto name block-other-protocols

FESX424 Router-C(config-vlan-other-proto)# exclude e 9 to 16

FESX424 Router-C(config-vlan-other-proto)# no dynamic

FESX424 Router-C(config-vlan-other-proto)# interface ve 3

FESX424 Router-C(config-vif-3)# ip addr 1.1.10.1/24

FESX424 Router-C(config-vif-3)# ip ospf area 0.0.0.0

FESX424 Router-C(config-vif-3)# int ve4

FESX424 Router-C(config-vif-4)# ipx network 10 ethernet_802.3

FESX424 Router-C(config-vif-4)# vlan 4 name Bridged_ALL_Protocols

FESX424 Router-C(config-vlan-4)# untag ethernet 17 to 24

FESX424 Router-C(config-vlan-4)# tag ethernet 25 to 26

FESX424 Router-C(config-vlan-4)# spanning-tree

FESX424 Router-C(config-vlan-4)# vlan 7 name Rtr_BB_to_Bldg.2

FESX424 Router-C(config-vlan-7)# tag e 25

FESX424 Router-C(config-vlan-7)# no spanning-tree

FESX424 Router-C(config-vlan-7)# router-interface ve5

FESX424 Router-C(config-vlan-7)# vlan 6 name Rtr_BB_to_Bldg.1

FESX424 Router-C(config-vlan-6)# tag ethernet 26

FESX424 Router-C(config-vlan-6)# no spanning-tree

FESX424 Router-C(config-vlan-6)# router-interface ve6

FESX424 Router-C(config-vlan-6)# int ve5

FESX424 Router-C(config-vif-5)# ip addr 1.1.8.2/24

FESX424 Router-C(config-vif-5)# ip ospf area 0.0.0.0

FESX424 Router-C(config-vif-5)# ipx network 8 ethernet_802.3

FESX424 Router-C(config-vif-5)# int ve6

FESX424 Router-C(config-vif-6)# ip addr 1.1.5.2/24

FESX424 Router-C(config-vif-6)# ip ospf area 0.0.0.0

11 - 32 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

FESX424 Router-C(config-vif-6)# ipx network 5 ethernet_802.3

FESX424 Router-C(config-vif-6)#

Configuring Protocol VLANs With Dynamic Ports

The configuration examples for protocol VLANs in the sections above show how to configure the VLANs using static ports. You also can configure the following types of protocol VLANs with dynamic ports:

• AppleTalk protocol

• IP protocol

• IPX protocol

• IP sub-net

• IPX network

NOTE: The software does not support dynamically adding ports to AppleTalk cable VLANs. Conceptually, an

AppleTalk cable VLAN consists of a single network cable, connected to a single port. Therefore, dynamic addition and removal of ports is not applicable.

NOTE: You cannot route to or from protocol VLANs with dynamically added ports.

Aging of Dynamic Ports

When you add the ports to the VLAN, the software automatically adds them all to the VLAN. However, dynamically added ports age out. If the age time for a dynamic port expires, the software removes the port from the VLAN. If that port receives traffic for the IP sub-net or IPX network, the software adds the port to the VLAN again and starts the aging timer over. Each time the port receives traffic for the VLAN's IP sub-net or IPX network, the aging timer starts over.

Dynamic ports within any protocol VLAN age out after 10 minutes, if no member protocol traffic is received on a port within the VLAN. The aged out port, however, remains as a candidate dynamic port for that VLAN. The port becomes active in the VLAN again if member protocol traffic is received on that port.

Once a port is re-activated, the aging out period for the port is reset to 20 minutes. Each time a member protocol packet is received by a candidate dynamic port (aged out port) the port becomes active again and the aging out period is reset for 20 minutes.

Configuration Guidelines

• You cannot dynamically add a port to a protocol VLAN if the port has any routing configuration parameters.

For example, the port cannot have a virtual routing interface, IP sub-net address, IPX network address, or

AppleTalk network address configured on it.

• Once you dynamically add a port to a protocol VLAN, you cannot configure routing parameters on the port.

• Dynamic VLAN ports are not required or supported on AppleTalk cable VLANs.

Configuring an IP, IPX, or AppleTalk Protocol VLAN with Dynamic Ports

To configure an IP, IPX, or AppleTalk protocol VLAN with dynamic ports, use the following method.

To configure port-based VLAN 10, then configure an IP protocol VLAN within the port-based VLAN with dynamic ports, enter the following commands such as the following:

FastIron SuperX Router(config)# vlan 10 by port

FastIron SuperX Router(config-vlan-10)# untag ethernet 1/1 to 1/6 added untagged port ethe 1/1 to 1/6 to port-vlan 30.

FastIron SuperX Router(config-vlan-10)# ip-proto name IP_Prot_VLAN

FastIron SuperX Router(config-vlan-10)# dynamic

December 2005 © Foundry Networks, Inc.

11 - 33

Foundry Configuration Guide for the FESX, FSX, and FWSX

FastIron SuperX Router(config)# write memory

Syntax: vlan <vlan-id> by port [name <string>]

Syntax: untagged ethernet [<slotnum>/]<portnum> to [<slotnum>/]<portnum>

Or

Syntax: untagged ethernet [<slotnum>/]<portnum> ethernet [<slotnum>/]<portnum>

NOTE: Use the first untagged command for adding a range of ports. Use the second command for adding separate ports (not in a range).

Syntax: ip-proto [name <string>]

Syntax: ipx-proto [name <string>]

Syntax: appletalk-cable-vlan <num> [name <string>]

Syntax: dynamic

The procedure is similar for IPX and AppleTalk protocol VLANs. Enter ipx-proto or atalk-proto instead of ip-proto .

Configuring an IP Sub-Net VLAN with Dynamic Ports

To configure port-based VLAN 10, then configure an IP sub-net VLAN within the port-based VLAN with dynamic ports, enter commands such as the following:

FastIron SuperX Router(config)# vlan 10 by port name IP_VLAN

FastIron SuperX Router(config-vlan-10)# untag ethernet 1/1 to 1/6 added untagged port ethe 1/1 to 1/6 to port-vlan 10.

FastIron SuperX Router(config-vlan-10)# ip-subnet 1.1.1.0/24 name Mktg-LAN

FastIron SuperX Router(config-vlan-10)# dynamic

FastIron SuperX Router(config)# write memory

These commands create a port-based VLAN on chassis ports 1/1 – 1/6 named “Mktg-LAN”, configure an IP subnet VLAN within the port-based VLAN, and then add ports from the port-based VLAN dynamically.

Syntax: vlan <vlan-id> by port [name <string>]

Syntax: untagged ethernet [<slotnum>/]<portnum> to [<slotnum>/]<portnum>

Or

Syntax: untagged ethernet [<slotnum>/]<portnum> ethernet [<slotnum>/]<portnum>

NOTE: Use the first untagged command for adding a range of ports. Use the second command for adding separate ports (not in a range).

Syntax: ip-subnet <ip-addr> <ip-mask> [name <string>]

Or

Syntax: ip-subnet <ip-addr>/<mask-bits> [name <string>]

Syntax: dynamic

Configuring an IPX Network VLAN with Dynamic Ports

To configure port-based VLAN 20, then configure an IPX network VLAN within the port-based VLAN with dynamic ports, enter commands such as the following:

FastIron SuperX Router(config)# vlan 20 by port name IPX_VLAN

FastIron SuperX Router(config-vlan-10)# untag ethernet 2/1 to 2/6 added untagged port ethe 2/1 to 2/6 to port-vlan 20.

FastIron SuperX Router(config-vlan-10)# ipx-network abcd ethernet_ii name Eng-LAN

11 - 34 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

FastIron SuperX Router(config-vlan-10)# dynamic

FastIron SuperX Router(config)# write memory

These commands create a port-based VLAN on chassis ports 2/1 – 2/6 named “Eng-LAN”, configure an IPX network VLAN within the port-based VLAN, and then add ports from the port-based VLAN dynamically.

Syntax: vlan <vlan-id> by port [name <string>]

Syntax: untagged ethernet [<slotnum>/]<portnum> to [<slotnum>/]<portnum>

Or

Syntax: untagged ethernet [<slotnum>/]<portnum> ethernet [<slotnum>/]<portnum>

NOTE: Use the first untagged command for adding a range of ports. Use the second command for adding separate ports (not in a range).

Syntax: ipx-network <network-addr> ethernet_ii | ethernet_802.2 | ethernet_802.3 | ethernet_snap

[name <string>]

Syntax: dynamic

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:

FastIron SuperX Router(config)# vlan 10 by port

FastIron SuperX Router(config-vlan-10)# untag ethernet 1/1 to 1/24

FastIron SuperX Router(config-vlan-10)# untag ethernet 2/1 to 2/2

FastIron SuperX Router(config-vlan-10)# uplink-switch ethernet 2/1 to 2/2

Syntax: [no] uplink-switch ethernet [<slotnum>/]<portnum> [to [<slotnum>/]<portnum> | ethernet [<slotnum>/

]<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.

Configuring the Same IP Sub-Net Address on Multiple Port-Based

VLANs

For a Foundry device to route between port-based VLANs, you must add a virtual routing interface to each VLAN.

Generally, you also configure a unique IP sub-net 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 sub-net address to each virtual routing interface. The IP address on each of the virtual routing interfaces must be in a separate sub-net. The Foundry device routes Layer 3 traffic between the sub-nets using the sub-net addresses.

NOTE: This feature applies only to Layer 3 Switches.

December 2005 © Foundry Networks, Inc.

11 - 35

Foundry Configuration Guide for the FESX, FSX, and FWSX

NOTE: Before using the method described in this section, see “Configuring VLAN Groups and Virtual Routing

Interface Groups” on page 11-40. You might be able to achieve the results you want using the methods in that section instead.

Figure 11.14 shows an example of this type of configuration.

Figure 11.14

Multiple port-based VLANs with separate protocol addresses

VLAN 2

VLAN 3

VLAN 4

FSX

Switching Router

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 sub-net address. If you need to conserve IP sub-net addresses, you can configure multiple VLANs with the same IP sub-net address, as shown in Figure 11.15.

11 - 36 © Foundry Networks, Inc.

December 2005

Figure 11.15

Multiple port-based VLANs with the same protocol address

VLAN 2

VLAN 3

VLAN 4

Configuring Virtual LANs (VLANs)

FSX

Switching Router

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 sub-net addresses, this feature allows containment of Layer 2 broadcasts to segments within an IP sub-net. For ISP environments where the same IP sub-net is allocated to different customers, placing each customer in a separate VLAN allows all customers to share the IP sub-net address, while at the same time isolating them from one another’s Layer 2 broadcasts.

NOTE: You can provide redundancy to an IP sub-net address that contains multiple VLANs using a pair of

Foundry Layer 3 Switches configured for Foundry’s VRRP (Virtual Router Redundancy Protocol).

The Foundry device 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 sub-net address. If the source and destination hosts are in the same VLAN, the Foundry device 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 sub-net address, the Foundry device performs a proxy ARP on behalf of the other host. The Foundry device then replies to the ARP by sending the virtual routing interface MAC address. The

Foundry device 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.

December 2005 © Foundry Networks, Inc.

11 - 37

Foundry Configuration Guide for the FESX, FSX, and FWSX

NOTE: If the Foundry device’s ARP table does not contain the requested host, the Foundry device 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 sub-net address.

• If the destination is in the same VLAN as the source, the Foundry device does not need to perform a proxy

ARP.

To configure multiple VLANs to use the same IP sub-net 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 sub-net address to more than one of the virtual routing interfaces.

• Configure the virtual routing interfaces that do not have the IP sub-net address to “follow” the virtual routing interface that does have the address.

To configure the VLANs shown in Figure 11.15, you could enter the following commands.

FastIron SuperX Router(config)# vlan 1 by port

FastIron SuperX Router(config-vlan-1)# untag ethernet 1/1

FastIron SuperX Router(config-vlan-1)# tag ethernet 1/8

FastIron SuperX Router(config-vlan-1)# router-interface ve 1

Syntax: ip follow ve <num>

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.

FastIron SuperX Router(config-vlan-1)# vlan 2 by port

FastIron SuperX Router(config-vlan-2)# untag ethernet 1/2

FastIron SuperX Router(config-vlan-2)# tag ethernet 1/8

FastIron SuperX Router(config-vlan-2)# router-interface ve 2

FastIron SuperX Router(config-vlan-2)# vlan 3 by port

FastIron SuperX Router(config-vlan-3)# untag ethernet 1/5 to 1/6

FastIron SuperX Router(config-vlan-3)# tag ethernet 1/8

FastIron SuperX Router(config-vlan-3)# router-interface ve 3

The following commands configure an IP sub-net address on virtual routing interface 1.

FastIron SuperX Router(config-vlan-3)# interface ve 1

FastIron SuperX Router(config-vif-1)# ip address 10.0.0.1/24

The following commands configure virtual routing interfaces 2 and 3 to “follow” the IP sub-net address configured on virtual routing interface 1.

FastIron SuperX Router(config-vif-1)# interface ve 2

FastIron SuperX Router(config-vif-2)# ip follow ve 1

FastIron SuperX Router(config-vif-2)# interface ve 3

FastIron SuperX Router(config-vif-3)# ip follow ve 1

NOTE: Since virtual routing interfaces 2 and 3 do not have their own IP sub-net addresses but instead are

“following” virtual routing interface a’s IP address, you still can configure an IPX or AppleTalk interface on virtual routing interfaces 2 and 3.

11 - 38 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

Using Separate ACLs on IP Follower Virtual Routing Interfaces

NOTE: This section applies to flow-based ACLs only.

The IP follower feature allows multiple virtual routing interfaces to share the same IP address. One virtual routing interface has the IP address and the other virtual routing interfaces are configured to follow the virtual routing interface that has the address.

By default, the follower interfaces are secured by the ACLs that are applied to the interface that has the address.

In fact, an ACL applied to a follower interface is ignored. For example, if you configure virtual routing interfaces 1,

2, and 3, and configure interfaces 2 and 3 to follow interface 1, then the ACLs applied to interface 1 also apply to interfaces 2 and 3. Any ACLs applied separately to interface 2 or 3 are ignored.

You can enable a follower virtual routing interface to use the ACLs you apply to it instead of using the ACLs applied to the interface that has the address. For example, you can enable virtual routing interface 2 to use its own ACLs instead of using interface 1’s ACLs.

To enable a virtual routing interface to use its own ACLs instead of the ACLs of the interface it is following, enter the following command at the configuration level for the interface:

FastIron SuperX Router(config-vif-2)# no ip follow acl

Syntax: [no] ip follow acl

The following commands show a complete IP follower configuration. Virtual routing interfaces 2 and 3 have been configured to share the IP address of virtual routing interface 1, but also have been configured to use their own

ACLs instead of virtual routing interface 1’s ACLs.

FastIron SuperX Router(config)# vlan 1 name primary_vlan

FastIron SuperX Router(config-vlan-1)# untag ethernet 1/1

FastIron SuperX Router(config-vlan-1)# tag ethernet 1/8

FastIron SuperX Router(config-vlan-1)# router-interface ve 1

FastIron SuperX Router(config-vlan-1)# exit

FastIron SuperX Router(config)# interface ve 1

FastIron SuperX Router(config-ve-1)# ip address 10.0.0.1/24

FastIron SuperX Router(config-ve-1)# ip access-group 1 in

FastIron SuperX Router(config-ve-1)# exit

FastIron SuperX Router(config)# vlan 2 name followerA

FastIron SuperX Router(config-vlan-2)# untag ethernet 1/2

FastIron SuperX Router(config-vlan-2)# tag ethernet 1/8

FastIron SuperX Router(config-vlan-2)# router-interface ve 2

FastIron SuperX Router(config-vlan-2)# exit

FastIron SuperX Router(config)# interface ve 2

FastIron SuperX Router(config-ve-2)# ip follow ve 1

FastIron SuperX Router(config-v2-2)# no ip follow acl

FastIron SuperX Router(config-ve-2)# ip access-group 2 in

FastIron SuperX Router(config-ve-2)# exit

FastIron SuperX Router(config)# vlan 3 name followerB

FastIron SuperX Router(config-vlan-3)# untag ethernet 1/5 to 1/6

FastIron SuperX Router(config-vlan-3)# tag ethernet 1/8

FastIron SuperX Router(config-vlan-3)# router-interface ve 3

FastIron SuperX Router(config-vlan-3)# exit

FastIron SuperX Router(config)# interface ve 3

FastIron SuperX Router(config-ve-3)# ip follow ve 1

FastIron SuperX Router(config-ve-3)# no ip follow acl

FastIron SuperX Router(config-ve-3)# ip access-group 3 out

FastIron SuperX Router(config-ve-3)# exit

December 2005 © Foundry Networks, Inc.

11 - 39

Foundry Configuration Guide for the FESX, FSX, and FWSX

Configuring VLAN Groups and Virtual Routing Interface Groups

To simplify configuration when you have many VLANs with the same configuration, you can configure VLAN groups and virtual routing interface groups.

NOTE: VLAN groups are supported on Layer 3 Switches and Layer 2 Switches. Virtual routing interface groups are supported only on Layer 3 Switches.

When you create a VLAN group, the VLAN parameters you configure for the group apply to all the VLANs within the group. Additionally, you can easily associate the same IP sub-net interface with all the VLANs in a group by configuring a virtual routing interface group with the same ID as the VLAN 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-config file on the device’s flash memory module. Normally, a startup-config 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-config file so that it fits on the flash memory module.

• The virtual routing interface group feature is useful when you want to configure the same IP sub-net address on all the port-based VLANs within a VLAN group. You can configure a virtual routing interface group only after you configure a VLAN group with the same ID. The virtual routing interface group automatically applies to the VLANs in the VLAN group that has the same ID and cannot be applied to other VLAN groups or to individual VLANs.

You can create up to 32 VLAN groups and 32 virtual routing interface groups. A virtual routing interface group always applies only to the VLANs in the VLAN group with the same ID.

NOTE: Depending on the size of the VLAN ID range you want to use for the VLAN group, you might need to allocate additional memory for VLANs. On Layer 3 Switches, if you allocate additional memory for VLANs, you also need to allocate the same amount of memory for virtual routing interfaces. This is true regardless of whether you use the virtual routing interface groups. To allocate additional memory, see “Allocating Memory for More

VLANs or Virtual Routing Interfaces” on page 11-42.

Configuring a VLAN Group

To configure a VLAN group, enter commands such as the following:

FastIron SuperX Router(config)# vlan-group 1 vlan 2 to 1000

FastIron SuperX Router(config-vlan-group-1)# tagged 1/1 to 1/2

The first command in this example begins configuration for VLAN group 1, and assigns VLANs 2 through 1000 to the group. The second command adds ports 1/1 and 1/2 as tagged ports. 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 [<slotnum>/]<portnum> [to [<slotnum>/]<portnum> | ethernet [<slotnum>/]<portnum>]

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 contiguous range (a range with no gaps) of individual 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.

11 - 40 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

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 must increase the memory allocation for VLANs to 2048 or higher. Additionally, on Layer 3 Switches, if you allocate additional memory for VLANs, you also need to allocate the same amount of memory for virtual routing interfaces, before you configure the VLAN groups. This is true regardless of whether you use the virtual routing interface groups. The memory allocation is required because the VLAN groups and virtual routing interface groups have a one-to-one mapping. See “Allocating Memory for More VLANs or Virtual Routing Interfaces” on page 11-42.

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.

You can add and remove individual VLANs or VLAN ranges from at the VLAN group configuration level. For example, if you want to add VLANs 1001 and 1002 to VLAN group 1 and remove VLANs 900 through 1000, enter the following commands:

FastIron SuperX Router(config-vlan-group-1)# add-vlan 1001 to 1002

FastIron SuperX Router(config-vlan-group-1)# remove-vlan 900 to 1000

Syntax: 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:

FastIron SuperX Router# 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

!

Syntax: show vlan-group [<group-id>]

This example shows configuration information for two VLAN groups, group 1 and group 2.

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.

Configuring a Virtual Routing Interface Group

A virtual routing interface group allows you to associate the same IP sub-net interface with multiple port-based

VLANs. For example, if you associate a virtual routing interface group with a VLAN group, all the VLANs in the group have the IP interface of the virtual routing interface group.

NOTE: When you configure a virtual routing interface group, all members of the group have the same IP sub-net address. This feature is useful in collocation environments where the device has many IP addresses and you want to conserve the IP address space.

To configure a virtual routing interface group, enter commands such as the following:

FastIron SuperX Router(config)# vlan-group 1

FastIron SuperX Router(config-vlan-group-1)# group-router-interface

FastIron SuperX Router(config-vlan-group-1)# exit

FastIron SuperX Router(config)# interface group-ve 1

FastIron SuperX Router(config-vif-group-1)# ip address 10.10.10.1/24

These commands enable VLAN group 1 to have a group virtual routing interface, then configure virtual routing interface group 1. The software always associates a virtual routing interface group only with the VLAN group that

December 2005 © Foundry Networks, Inc.

11 - 41

Foundry Configuration Guide for the FESX, FSX, and FWSX has the same ID. In this example, the VLAN group ID is 1, so the corresponding virtual routing interface group also must have ID 1.

Syntax: group-router-interface

Syntax: interface group-ve <num>

Syntax: [no] ip address <ip-addr> <ip-mask> [secondary] or

Syntax: [no] ip address <ip-addr>/<mask-bits> [secondary]

The router-interface-group command enables a VLAN group to use a virtual routing interface group. Enter this command at the configuration level for the VLAN group. This command configures the VLAN group to use the virtual routing interface group that has the same ID as the VLAN group. You can enter this command when you configure the VLAN group for the first time or later, after you have added tagged ports to the VLAN and so on.

The <num> parameter in the interface group-ve <num> command specifies the ID of the VLAN group with which you want to associate this virtual routing interface group. The VLAN group must already be configured and enabled to use a virtual routing interface group. The software automatically associates the virtual routing interface group with the VLAN group that has the same ID. You can associate a virtual routing interface group only with the

VLAN group that has the same ID.

The syntax and usage for the ip address command is the same as when you use the command at the interface level to add an IP interface.

Displaying the VLAN Group and Virtual Routing Interface Group Information

To verify configuration of VLAN groups and virtual routing interface groups, display the running-config file. If you have saved the configuration to the startup-config file, you also can verify the configuration by displaying the startup-config file. The following example shows the running-config information for the VLAN group and virtual routing interface group configured in the previous examples. The information appears in the same way in the startup-config file.

FastIron SuperX Router(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 lines not related to the virtual routing interface group omitted...

interface group-ve 1

ip address 10.10.10.1 255.255.255.0

NOTE: If you have enabled display of sub-net masks in CIDR notation, the IP address information is shown as follows: 10.10.10.1/24.

Allocating Memory for More VLANs or Virtual Routing Interfaces

Layer 3 Switches can support up to 4095 VLANs and 4095 virtual routing interfaces.

The number of VLANs and virtual routing interfaces supported on your product depends on the device and, for

Chassis devices, the amount of DRAM on the management module. Table 11.2 lists the default and configurable

11 - 42 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs) maximum numbers of VLANs and virtual routing interfaces for Layer 3 Switches and Layer 2 Switches. Unless otherwise noted, the values apply to both types of switches.

Table 11.2: VLAN and Virtual Routing Interface Support

VLANs

Default

Maximum

64

Configurable

Maximum

4094

Virtual Routing Interfaces

Default

Maximum

255

Configurable

Maximum

512

NOTE: If many of your VLANs will have an identical configuration, you might want to configure VLAN groups and virtual routing interface groups after you increase the system capacity for VLANs and virtual routing interfaces.

See “Configuring VLAN Groups and Virtual Routing Interface Groups” on page 11-40.

Increasing the Number of VLANs You Can Configure

NOTE: Although you can specify up to 4095 VLANs, you can configure only 4094 VLANs. VLAN ID 4094 is reserved for use by the Single Spanning Tree feature.

To increase the maximum number of VLANs you can configure, enter commands such as the following at the global CONFIG level of the CLI:

FESX424 Router(config)# system-max vlan 2048

FESX424 Router(config)# write memory

FESX424 Router(config)# end

FESX424 Router# reload

Syntax: system-max vlan <num>

The <num> parameter indicates the maximum number of VLANs. The range of valid values depends on the device you are configuring. See Table 11.2.

Increasing the Number of Virtual Routing Interfaces You Can Configure

To increase the maximum number of virtual routing interfaces you can configure, enter commands such as the following at the global CONFIG level of the CLI:

FESX424 Router(config)# system-max virtual-interface 4095

FESX424 Router(config)# write memory

FESX424 Router(config)# end

FESX424 Router# reload

Syntax: system-max virtual-interface <num>

The <num> parameter indicates the maximum number of virtual routing interfaces. The range of valid values depends on the device you are configuring. See Table 11.2.

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 sub-net 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

December 2005 © Foundry Networks, Inc.

11 - 43

Foundry Configuration Guide for the FESX, FSX, and FWSX 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 Foundry device 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.

Figure 11.16 shows a conceptual picture of the service that aggregated VLANs provide. Aggregated VLANs provide a path for multiple client channels. The channels do not receive traffic from other channels. Thus, each channel is a private link.

Figure 11.16

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 sub-net

192.168.1.0/24

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.

Figure 11.17 shows an example application that uses aggregated VLANs. This configuration includes the client connections shown in Figure 11.16.

11 - 44 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

Figure 11.17

Example Super Aggregated VLAN Application

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

209.157.2.12/24

Client 6

Port 1/1

VLAN 101 . . .

Client 8

Port 1/3

VLAN 103 . . .

Client 10

Port 1/5

VLAN 105

Device A

Tag Type 8100

Port 2/1

Tagged

Device B

Tag Type 8100

Port 2/1

Tagged

Port 3/1

Untagged

VLAN Aggregation

Enabled

Device C

Tag Type 9100

Port 3/2

Untagged

Port 4/1

Tagged

Port 4/1

Tagged

Device E

Tag Type 8100

VLAN Aggregation

Enabled

Port 3/1

Untagged

Port 2/1

Tagged

Device D

Tag Type 9100

Port 3/2

Untagged

Ports 1/1 - 1/5

Untagged

Port 2/1

Tagged

Device F

Tag Type 8100

Ports 1/1 - 1/5

Untagged

Ports 1/1 - 1/5

Untagged

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 sub-net and use network services that require connection to the same sub-net. 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.

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

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.

December 2005 © Foundry Networks, Inc.

11 - 45

Foundry Configuration Guide for the FESX, FSX, and FWSX

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

To configure the aggregated VLANs on device A in Figure 11.17 on page 11-45, enter the following commands:

FastIron SuperX Router(config)# vlan 101 by port

FastIron SuperX Router(config-vlan-101)# tagged ethernet 2/1

FastIron SuperX Router(config-vlan-101)# untagged ethernet 1/1

FastIron SuperX Router(config-vlan-101)# exit

FastIron SuperX Router(config)# vlan 102 by port

FastIron SuperX Router(config-vlan-102)# tagged ethernet 2/1

FastIron SuperX Router(config-vlan-102)# untagged ethernet 1/2

FastIron SuperX Router(config-vlan-102)# exit

FastIron SuperX Router(config)# vlan 103 by port

FastIron SuperX Router(config-vlan-103)# tagged ethernet 2/1

FastIron SuperX Router(config-vlan-103)# untagged ethernet 1/3

FastIron SuperX Router(config-vlan-103)# exit

FastIron SuperX Router(config)# vlan 104 by port

FastIron SuperX Router(config-vlan-104)# tagged ethernet 2/1

FastIron SuperX Router(config-vlan-104)# untagged ethernet 1/4

FastIron SuperX Router(config-vlan-104)# exit

FastIron SuperX Router(config)# vlan 105 by port

FastIron SuperX Router(config-vlan-105)# tagged ethernet 2/1

FastIron SuperX Router(config-vlan-105)# untagged ethernet 1/5

FastIron SuperX Router(config-vlan-105)# exit

FastIron SuperX Router(config)# write memory

Syntax: [no] vlan <vlan-id> [by port]

Syntax: [no] tagged ethernet [<slotnum>/]<portnum> [to [<slotnum>/]<portnum> | ethernet [<slotnum>/

]<portnum>]

Syntax: [no] untagged ethernet [<slotnum>/]<portnum> [to [<slotnum>/]<portnum> | ethernet [<slotnum>/

]<portnum>]

Use the tagged command to add the port that the device uses for the uplink to the core device. Use the untagged command to add the ports connected to the individual clients.

Configuring Aggregated VLANs on a Core Device

To configure the aggregated VLANs on device C in Figure 11.17 on page 11-45, enter the following commands:

FastIron SuperX Router(config)# tag-type 9100

FastIron SuperX Router(config)# aggregated-vlan

11 - 46 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

FastIron SuperX Router(config)# vlan 101 by port

FastIron SuperX Router(config-vlan-101)# tagged ethernet 4/1

FastIron SuperX Router(config-vlan-101)# untagged ethernet 3/1

FastIron SuperX Router(config-vlan-101)# exit

FastIron SuperX Router(config)# vlan 102 by port

FastIron SuperX Router(config-vlan-102)# tagged ethernet 4/1

FastIron SuperX Router(config-vlan-102)# untagged ethernet 3/2

FastIron SuperX Router(config-vlan-102)# exit

FastIron SuperX Router(config)# write memory

Syntax: [no] tag-type <num>

Syntax: [no] aggregated-vlan

The <num> parameter specifies the tag type can be a hexadecimal value from 0 – ffff. The default is 8100.

Verifying the Configuration

You can verify the VLAN, VLAN aggregation option, and tag configuration by viewing the running-config. To display the running-config, enter the show running-config command from any CLI prompt. After you save the configuration changes to the startup-config, you also can display the settings in that file by entering the show configuration command from any CLI prompt.

Complete CLI Examples

The following sections show all the Aggregated VLAN configuration commands on the devices in Figure 11.17 on page 11-45.

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 the other side. For simplicity, the example in Figure 11.17 on page 11-45 is symmetrical in terms of the port 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

FastIron SuperX RouterA(config)# vlan 101 by port

FastIron SuperX RouterA(config-vlan-101)# tagged ethernet 2/1

FastIron SuperX RouterA(config-vlan-101)# untagged ethernet 1/1

FastIron SuperX RouterA(config-vlan-101)# exit

FastIron SuperX RouterA(config)# vlan 102 by port

FastIron SuperX RouterA(config-vlan-102)# tagged ethernet 2/1

FastIron SuperX RouterA(config-vlan-102)# untagged ethernet 1/2

FastIron SuperX RouterA(config-vlan-102)# exit

FastIron SuperX RouterA(config)# vlan 103 by port

FastIron SuperX RouterA(config-vlan-103)# tagged ethernet 2/1

FastIron SuperX RouterA(config-vlan-103)# untagged ethernet 1/3

FastIron SuperX RouterA(config-vlan-103)# exit

FastIron SuperX RouterA(config)# vlan 104 by port

FastIron SuperX RouterA(config-vlan-104)# tagged ethernet 2/1

FastIron SuperX RouterA(config-vlan-104)# untagged ethernet 1/4

FastIron SuperX RouterA(config-vlan-104)# exit

FastIron SuperX RouterA(config)# vlan 105 by port

FastIron SuperX RouterA(config-vlan-105)# tagged ethernet 2/1

FastIron SuperX RouterA(config-vlan-105)# untagged ethernet 1/5

FastIron SuperX RouterA(config-vlan-105)# exit

FastIron SuperX RouterA(config)# write memory

December 2005 © Foundry Networks, Inc.

11 - 47

Foundry Configuration Guide for the FESX, FSX, and FWSX

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.

FastIron SuperX RouterB(config)# vlan 101 by port

FastIron SuperX RouterB(config-vlan-101)# tagged ethernet 2/1

FastIron SuperX RouterB(config-vlan-101)# untagged ethernet 1/1

FastIron SuperX RouterB(config-vlan-101)# exit

FastIron SuperX RouterB(config)# vlan 102 by port

FastIron SuperX RouterB(config-vlan-102)# tagged ethernet 2/1

FastIron SuperX RouterB(config-vlan-102)# untagged ethernet 1/2

FastIron SuperX RouterB(config-vlan-102)# exit

FastIron SuperX RouterB(config)# vlan 103 by port

FastIron SuperX RouterB(config-vlan-103)# tagged ethernet 2/1

FastIron SuperX RouterB(config-vlan-103)# untagged ethernet 1/3

FastIron SuperX RouterB(config-vlan-103)# exit

FastIron SuperX RouterB(config)# vlan 104 by port

FastIron SuperX RouterB(config-vlan-104)# tagged ethernet 2/1

FastIron SuperX RouterB(config-vlan-104)# untagged ethernet 1/4

FastIron SuperX RouterB(config-vlan-104)# exit

FastIron SuperX RouterB(config)# vlan 105 by port

FastIron SuperX RouterB(config-vlan-105)# tagged ethernet 2/1

FastIron SuperX RouterB(config-vlan-105)# untagged ethernet 1/5

FastIron SuperX RouterB(config-vlan-105)# exit

FastIron SuperX RouterB(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.

FastIron SuperX RouterC(config)# tag-type 9100

FastIron SuperX RouterC(config)# aggregated-vlan

FastIron SuperX RouterC(config)# vlan 101 by port

FastIron SuperX RouterC(config-vlan-101)# tagged ethernet 4/1

FastIron SuperX RouterC(config-vlan-101)# untagged ethernet 3/1

FastIron SuperX RouterC(config-vlan-101)# exit

FastIron SuperX RouterC(config)# vlan 102 by port

FastIron SuperX RouterC(config-vlan-102)# tagged ethernet 4/1

FastIron SuperX RouterC(config-vlan-102)# untagged ethernet 3/2

FastIron SuperX RouterC(config-vlan-102)# exit

FastIron SuperX RouterC(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.

FastIron SuperX RouterD(config)# tag-type 9100

FastIron SuperX RouterD(config)# aggregated-vlan

FastIron SuperX RouterD(config)# vlan 101 by port

FastIron SuperX RouterD(config-vlan-101)# tagged ethernet 4/1

FastIron SuperX RouterD(config-vlan-101)# untagged ethernet 3/1

FastIron SuperX RouterD(config-vlan-101)# exit

FastIron SuperX RouterD(config)# vlan 102 by port

FastIron SuperX RouterD(config-vlan-102)# tagged ethernet 4/1

FastIron SuperX RouterD(config-vlan-102)# untagged ethernet 3/2

FastIron SuperX RouterD(config-vlan-102)# exit

FastIron SuperX RouterD(config)# write memory

11 - 48 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

Commands for Device E

Since the configuration in Figure 11.17 on page 11-45 is symmetrical, the commands for configuring device E are identical to the commands for configuring device A.

FastIron SuperX RouterE(config)# vlan 101 by port

FastIron SuperX RouterE(config-vlan-101)# tagged ethernet 2/1

FastIron SuperX RouterE(config-vlan-101)# untagged ethernet 1/1

FastIron SuperX RouterE(config-vlan-101)# exit

FastIron SuperX RouterE(config)# vlan 102 by port

FastIron SuperX RouterE(config-vlan-102)# tagged ethernet 2/1

FastIron SuperX RouterE(config-vlan-102)# untagged ethernet 1/2

FastIron SuperX RouterE(config-vlan-102)# exit

FastIron SuperX RouterE(config)# vlan 103 by port

FastIron SuperX RouterE(config-vlan-103)# tagged ethernet 2/1

FastIron SuperX RouterE(config-vlan-103)# untagged ethernet 1/3

FastIron SuperX RouterE(config-vlan-103)# exit

FastIron SuperX RouterE(config)# vlan 104 by port

FastIron SuperX RouterE(config-vlan-104)# tagged ethernet 2/1

FastIron SuperX RouterE(config-vlan-104)# untagged ethernet 1/4

FastIron SuperX RouterE(config-vlan-104)# exit

FastIron SuperX RouterE(config)# vlan 105 by port

FastIron SuperX RouterE(config-vlan-105)# tagged ethernet 2/1

FastIron SuperX RouterE(config-vlan-105)# untagged ethernet 1/5

FastIron SuperX RouterE(config-vlan-105)# exit

FastIron SuperX RouterE(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, since the port numbers on each side of the configuration in Figure 11.17 on page 11-45 are symmetrical, the configuration of device F is also identical to the configuration of device A and device B.

FastIron SuperX RouterF(config)# vlan 101 by port

FastIron SuperX RouterF(config-vlan-101)# tagged ethernet 2/1

FastIron SuperX RouterF(config-vlan-101)# untagged ethernet 1/1

FastIron SuperX RouterF(config-vlan-101)# exit

FastIron SuperX RouterF(config)# vlan 102 by port

FastIron SuperX RouterF(config-vlan-102)# tagged ethernet 2/1

FastIron SuperX RouterF(config-vlan-102)# untagged ethernet 1/2

FastIron SuperX RouterF(config-vlan-102)# exit

FastIron SuperX RouterF(config)# vlan 103 by port

FastIron SuperX RouterF(config-vlan-103)# tagged ethernet 2/1

FastIron SuperX RouterF(config-vlan-103)# untagged ethernet 1/3

FastIron SuperX RouterF(config-vlan-103)# exit

FastIron SuperX RouterF(config)# vlan 104 by port

FastIron SuperX RouterF(config-vlan-104)# tagged ethernet 2/1

FastIron SuperX RouterF(config-vlan-104)# untagged ethernet 1/4

FastIron SuperX RouterF(config-vlan-104)# exit

FastIron SuperX RouterF(config)# vlan 105 by port

FastIron SuperX RouterF(config-vlan-105)# tagged ethernet 2/1

FastIron SuperX RouterF(config-vlan-105)# untagged ethernet 1/5

FastIron SuperX RouterF(config-vlan-105)# exit

FastIron SuperX RouterF(config)# write memory

Configuring 802.1Q-in-Q Tagging

802.1Q tagging is an IEEE standard that enables a networking device to add information to a Layer 2 packet in order to identify the VLAN membership of the packet. Foundry devices tag a packet by adding a four-byte tag to

December 2005 © Foundry Networks, Inc.

11 - 49

Foundry Configuration Guide for the FESX, FSX, and FWSX 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 was sent. The tag and VLAN ID keep traffic from each VLAN segregated and private.

• FESX releases prior to 01.1.00 enable you to configure a single 802.1Q tag type on all ports on the device.

The default 802.1Q tag on a Foundry device is 8100 (hexadecimal), compliant with the 802.1Q specification.

Figure 11.18 shows an 802.1Q configuration example with a single 802.1Q tag type.

Figure 11.18

802.1Q Configuration Example

To customer interface Uplink to provider cloud

Untagged

Provider Edge Switch

Tagged

DA SA 8100

Customer

VLAN

DA SA 9100

Provider

VLAN

8100

Customer

VLAN

As shown in Figure 11.18, the ports to customer interfaces are untagged, whereas the uplink ports to the provider cloud are tagged, because multiple client VLANs share the uplink to the provider cloud. In this example, the Foundry device 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 Foundry devices or devices 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.

• FESX releases 01.1.00 and later, and all FSX and FWSX releases, provide finer granularity for configuring

802.1Q tagging, enabling you to configure 802.1Q tag-types on a group of ports. This type of configuration is called 802.1Q-in-Q tagging . This feature enables 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 11.19 shows an example application with 802.1Q-in-Q tagging.

Figure 11.19

802.1Q-in-Q Configuration Example

To customer interface Uplink to provider cloud

Configured tag-type 9100 Default tag-type 8100

Untagged

Provider Edge Switch

Tagged

DA SA 8100

Customer

VLAN

DA SA 8100

Provider

VLAN

8100

Customer

VLAN

11 - 50

In Figure 11.19, the untagged ports (to customer interfaces) accept frames that have any 802.1Q tag other 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 Foundry device will switch the frames to the uplink device with an additional 8100 tag, thereby supporting devices that only support this method of VLAN tagging.

© Foundry Networks, Inc.

December 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. See “About Port Regions” on page 4-2 for a list of valid port regions.

• If you configure a port with an 802.1Q tag-type, the Foundry device automatically applies the 802.1Q tag-type to all ports within the same port region. Likewise, if you remove the 802.1Q tag-type from a port, the Foundry device automatically removes the 802.1Q tag-type from all ports within the same port region.

• X-Series devices support one 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 – 12, then later configure an 802.1Q tag of 5100 on port 15, the device automatically applies the 5100 tag to all ports in the same port region as port 15, and also changes the 802.1Q tag-type on ports 1 – 12 to 5100.

• 802.1Q-in-Q tagging and VSRP are not supported together on the same device.

Enabling 802.1Q-in-Q Tagging

To enable 802.1Q-in-Q tagging, configure an 802.1Q tag on the untagged edge links (the customer ports) to any value other than the 802.1Q tag for incoming traffic. For example, in Figure 11.20, the 802.1Q tag on the untagged edge links (ports 11 and 12) is 9100, whereas, the 802.1Q tag for incoming traffic is 8100.

To configure 802.1 Q-in-Q tagging as shown in Figure 11.20, enter commands such as the following on the untagged edge links of devices C and D:

FESX424 Switch(config)# tag-type 9100 e 11 to 12

FESX424 Switch(config)# aggregated-vlan

Note that since ports 11 and 12 belong to the port region 1 – 12, the 802.1Q tag actually applies to ports 1 – 12.

Syntax: [no] tag-type <num> [ethernet [<slotnum>/] <port number> [to <port number>]]

The <num> parameter specifies the tag-type number and can be a hexadecimal value from 0 - ffff. The default is

8100.

The <slotnum> parameter is required on chassis devices.

The ethernet <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 Foundry device automatically applies the 802.1Q tag to ports

1 – 12 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.

December 2005 © Foundry Networks, Inc.

11 - 51

Foundry Configuration Guide for the FESX, FSX, and FWSX

Example Configuration

Figure 11.20 shows an example 802.1Q-in-Q configuration.

Figure 11.20

Example 802.1Q-in-Q Configuration

Client 1

Port 1

VLAN 101

. . .

Client 3

Port 3

VLAN 103

. . .

Client 5

Port 5

VLAN 105

Client 1

192.168.1.69/24

Ports 1- 5

Untagged

Device A

Tag Type 8100

Port 6

Tagged

Client 5

209.157.2.12/24

9100 9100

Port 11

Untagged

Tag Type 9100 on ports 11 and 12

Device C

Port 17

Tagged

Client 6

Port 1

VLAN 101

. . .

Client 8

Port 3

VLAN 103

. . .

Client 10

Port 5

VLAN 105

Port 6

Tagged

Device B

Tag Type 8100

Port 12

Untagged

Ports 1- 5

Untagged

8100

8100

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.

Tag Type 9100 on ports 11 and 12

Device D

Port 11

Untagged

Port 17

Tagged

9100 9100

Port 6

Tagged

Port 12

Untagged

Port 6

Tagged

Ports 1- 5

Untagged

Tag Type 8100

Device E

Tag Type 8100

Device F

Ports 1 - 5

Untagged

192.168.1.129/24

Configuring Private VLANs

NOTE: Private VLANs are supported starting in software release 02.4.00. Releases 02.4.00 and later support private VLANs on untagged ports only. You cannot configure isolated, community, or primary VLANs on 802.1Q tagged ports.

A private VLAN is a VLAN that has the properties of standard Layer 2 port-based VLANs but also provides additional control over flooding packets on a VLAN. Figure 11.21 shows an example of an application using a private VLAN.

11 - 52 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

Figure 11.21

Private VLAN used to secure communication between a workstation and servers

A private VLAN secures traffic between a primary port and host ports.

Traffic between the hosts and the rest of the network must travel through the primary port.

Private VLAN

Port-based VLAN

Forwarding among private VLAN ports

VLAN 7 primary

VLAN 901, 903 community

VLAN 902 isolated

Firewall 3/2 3/5 3/6 3/9 3/10

This example uses a private VLAN to secure traffic between hosts and the rest of the network through a firewall.

Five ports in this example are members of a private VLAN. The first port (port 3/2) is attached to a firewall. The next four ports (ports 3/5, 3/6, 3/9, and 3/10) are attached to hosts that rely on the firewall to secure traffic between the hosts and the rest of the network. In this example, two of the hosts (on ports 3/5 and 3/6) are in a community private VLAN, and thus can communicate with one another as well as through the firewall. The other two hosts

(on ports 3/9 and 3/10), are in an isolated VLAN and thus can communicate only through the firewall. The two hosts are secured from communicating with one another even though they are in the same VLAN.

By default, the private VLAN does not forward broadcast or unknown-unicast packets from outside sources into the private VLAN. If needed, you can override this behavior for broadcast packets, unknown-unicast packets, or both. (See “Enabling Broadcast or Unknown Unicast Traffic to the Private VLAN” on page 11-55.)

You can configure a combination of the following types of private VLANs:

• Primary – The primary private VLAN ports are “promiscuous”. They can communicate with all the isolated private VLAN ports and community private VLAN ports in the isolated and community VLANs that are mapped to the promiscuous port.

• Isolated – Broadcasts and unknown unicasts received on isolated ports are sent only to the primary port.

They are not flooded to other ports in the isolated VLAN.

• Community – Broadcasts and unknown unicasts received on community ports are sent to the primary port and also are flooded to the other ports in the community VLAN.

Each private VLAN must have a primary VLAN. The primary VLAN is the interface between the secured ports and the rest of the network. The private VLAN can have any combination of community and isolated VLANs.

December 2005 © Foundry Networks, Inc.

11 - 53

Foundry Configuration Guide for the FESX, FSX, and FWSX

Table 11.3 list the differences between private VLANs and standard VLANs.

Table 11.3: Comparison of Private VLANs and Standard Port-Based VLANs

Forwarding Behavior Private VLANs

All ports within a VLAN constitute a common Layer broadcast domain

Broadcasts and unknown unicasts are forwarded to all the

VLAN’s ports by default

Known unicasts

No

No (isolated VLAN)

Yes (community VLAN)

Yes

Standard VLANs

Yes

Yes

Yes

Implementation Notes

• Private VLANs are supported starting in software release 02.4.00. Releases 02.4.00 and later support private VLANs on untagged ports only. You cannot configure isolated, community, or primary VLANs on

802.1Q tagged ports.

• The private VLAN implementation in the current release uses the CPU for forwarding packets on the primary

VLAN’s “promiscuous” port. Other forwarding is performed in the hardware. Support for the hardware forwarding in this feature sometimes results in multiple MAC address entries for the same MAC address in the device’s MAC address table. In this case, each of the entries is associated with a different VLAN. The multiple entries are a normal aspect of the implementation of this feature and do not indicate a software problem.

• By default, the primary VLAN does not forward broadcast or unknown unicast packets into the private VLAN.

You also can use MAC address filters to control traffic forwarded into and out of the private VLAN. If you are implementing the private VLAN on a Layer 2 Switch, you also can use ACLs to control the traffic into and out of the private VLAN.

Command Syntax

To configure a private VLAN, configure each of the component VLANs (isolated, community, and public) as a separate port-based VLAN.

• Use standard VLAN configuration commands to create the VLAN and add ports.

• Identify the private VLAN type (isolated, community, or public)

• For the primary VLAN, map the other private VLANs to the port(s) in the primary VLAN

Configuring an Isolated or Community Private VLAN

To configure a community private VLAN, enter commands such as the following:

FastIron SuperX Router(config)# vlan 901

FastIron SuperX Router(config-vlan-901)# untagged ethernet 3/5 to 3/6

FastIron SuperX Router(config-vlan-901)# pvlan type community

These commands create port-based VLAN 901, add ports 3/5 and 3/6 to the VLAN as untagged ports, then specify that the VLAN is a community private VLAN.

Syntax: untagged ethernet [<slotnum>/]<portnum> [to [<slotnum>/]<portnum> | ethernet [<slotnum>/]<portnum>]

Syntax: [no] pvlan type community | isolated | primary

The untagged command adds the ports to the VLAN.

The pvlan type command specifies that this port-based VLAN is a private VLAN.

• community – Broadcasts and unknown unicasts received on community ports are sent to the primary port

11 - 54 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs) and also are flooded to the other ports in the community VLAN.

• isolated – Broadcasts and unknown unicasts received on isolated ports are sent only to the primary port.

They are not flooded to other ports in the isolated VLAN.

• primary – The primary private VLAN ports are “promiscuous”. They can communicate with all the isolated private VLAN ports and community private VLAN ports in the isolated and community VLANs that are mapped to the promiscuous port.

Configuring the Primary VLAN

NOTE: The primary private VLAN has only one active port. If you configure the VLAN to have more than one port, the lowest-numbered port is the active one. The additional ports provide redundancy. If the active port becomes unavailable, the lowest-numbered available port becomes the active port for the VLAN.

To configure a primary private VLAN, enter commands such as the following:

FastIron SuperX Router(config)# vlan 7

FastIron SuperX Router(config-vlan-7)# untagged ethernet 3/2

FastIron SuperX Router(config-vlan-7)# pvlan type primary

FastIron SuperX Router(config-vlan-7)# pvlan mapping 901 ethernet 3/2

These commands create port-based VLAN 7, add port 3/2 as an untagged port, identify the VLAN as the primary

VLAN in a private VLAN, and map the other private VLANs to the port(s) in this VLAN.

Syntax: untagged ethernet [<slotnum>/]<portnum> [to [<slotnum>/]<portnum> | ethernet [<slotnum>/]<portnum>]

Syntax: [no] pvlan type community | isolated | primary

Syntax: [no] pvlan mapping <vlan-id> ethernet [<slotnum>/]<portnum>

The untagged command adds the port(s) to the VLAN.

The pvlan type command specifies that this port-based VLAN is a private VLAN. Specify primary as the type.

The pvlan mapping command identifies the other private VLANs for which this VLAN is the primary. The command also specifies the primary VLAN ports to which you are mapping the other private VLANs.

• The <vlan-id> parameter specifies another private VLAN. The other private VLAN you want to specify must already be configured.

• The ethernet <portnum> parameter specifies the primary VLAN port to which you are mapping all the ports in the other private VLAN (the one specified by <vlan-id>).

Enabling Broadcast or Unknown Unicast Traffic to the Private VLAN

To enhance private VLAN security, the primary private VLAN does not forward broadcast or unknown unicast packets to its community and isolated VLANs. For example, if port 3/2 in Figure 11.21 on page 11-53 receives a broadcast packet from the firewall, the port does not forward the packet to the other private VLAN ports (3/5, 3/6,

3/9, and 3/10).

This forwarding restriction does not apply to traffic from the private VLAN. The primary port does forward broadcast and unknown unicast packets that are received from the isolated and community VLANs. For example, if the host on port 3/9 sends an unknown unicast packet, port 3/2 forwards the packet to the firewall.

If you want to remove the forwarding restriction, you can enable the primary port to forward broadcast or unknown unicast traffic, if desired, using the following CLI method. You can enable or disable forwarding of broadcast or unknown unicast packets separately.

NOTE: On Layer 2 Switches and Layer 3 Switches, you also can use MAC address filters to control the traffic forwarded into and out of the private VLAN. In addition, if you are using a Layer 2 Switch, you also can use ACLs.

Command Syntax

To configure the ports in the primary VLAN to forward broadcast or unknown unicast traffic received from sources outside the private VLAN, enter the following commands at the global CONFIG level of the CLI:

December 2005 © Foundry Networks, Inc.

11 - 55

Foundry Configuration Guide for the FESX, FSX, and FWSX

FastIron SuperX Router(config)# pvlan-preference broadcast flood

FastIron SuperX Router(config)# pvlan-preference unknown-unicast flood

These commands enable forwarding of broadcast and unknown-unicast packets to ports within the private VLAN.

To again disable forwarding, enter a command such as the following:

FastIron SuperX Router(config)# no pvlan-preference broadcast flood

This command disables forwarding of broadcast packets within the private VLAN.

Syntax: [no] pvlan-preference broadcast | unknown-unicast flood

CLI Example for Figure 11.21

To configure the private VLANs shown in Figure 11.21 on page 11-53, enter the following commands:

FastIron SuperX Router(config)# vlan 901

FastIron SuperX Router(config-vlan-901)# untagged ethernet 3/5 to 3/6

FastIron SuperX Router(config-vlan-901)# pvlan type community

FastIron SuperX Router(config-vlan-901)# exit

FastIron SuperX Router(config)# vlan 902

FastIron SuperX Router(config-vlan-902)# untagged ethernet 3/9 to 3/10

FastIron SuperX Router(config-vlan-902)# pvlan type isolated

FastIron SuperX Router(config-vlan-902)# exit

FastIron SuperX Router(config)# vlan 903

FastIron SuperX Router(config-vlan-903)# untagged ethernet 3/5 to 3/6

FastIron SuperX Router(config-vlan-903)# pvlan type community

FastIron SuperX Router(config-vlan-903)# exit

FastIron SuperX Router(config)# vlan 7

FastIron SuperX Router(config-vlan-7)# untagged ethernet 3/2

FastIron SuperX Router(config-vlan-7)# pvlan type primary

FastIron SuperX Router(config-vlan-7)# pvlan mapping 901 ethernet 3/2

FastIron SuperX Router(config-vlan-7)# pvlan mapping 902 ethernet 3/2

FastIron SuperX Router(config-vlan-7)# pvlan mapping 903 ethernet 3/2

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).

For example, in Figure 11.22, port 2/11 is a dual-mode port belonging to VLAN 20. Traffic for VLAN 20, as well as traffic for the default VLAN, flows from a hub to this port. The dual-mode feature allows traffic for VLAN 20 and untagged traffic to go through the port at the same time.

11 - 56 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

Figure 11.22

Dual-mode VLAN port example

VLAN 20

Traffic

Hub

Port 2/11

Tagged, VLAN 20 dual-mode

Foundry Device

Port 2/9

Tagged, VLAN 20

Port 2/10

Untagged

Untagged

Traffic

VLAN 20

Traffic

Untagged

Traffic

To enable the dual-mode feature on port 2/11 in Figure 11.22:

FastIron SuperX Router(config)# vlan 20

FastIron SuperX Router(config-vlan-20)# tagged e 2/11

FastIron SuperX Router(config-vlan-20)# tagged e 2/9

FastIron SuperX Router(config-vlan-20)# int e 2/11

FastIron SuperX Router(config-if-e1000-2/11)# dual-mode

FastIron SuperX Router(config-if-e1000-2/11)# exit

Syntax: [no] dual-mode

You can configure a dual-mode port to transmit traffic for a specified VLAN (other than the DEFAULT-VLAN) as untagged, while transmitting traffic for other VLANs as tagged. Figure 11.23 illustrates this enhancement.

Figure 11.23

Specifying a default VLAN ID for a dual-mode port

VLAN 10

Untagged

Traffic

VLAN 10

Untagged

Traffic

Hub

Dual-mode Port 2/11

Default VLAN ID 10

Tagged, VLAN 20

Foundry Device

Port 2/10

Untagged, VLAN 10

Port 2/9

Tagged, VLAN 20

VLAN 20

Tagged

Traffic

VLAN 20

Tagged

Traffic

In Figure 11.23, tagged port 2/11 is a dual-mode port belonging to VLANs 10 and 20. The default VLAN assigned 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.

December 2005 © Foundry Networks, Inc.

11 - 57

Foundry Configuration Guide for the FESX, FSX, and FWSX

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.

The following commands configure VLANs 10 and 20 in Figure 11.23. Tagged port 2/11 is added to VLANs 10 and 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.

FastIron SuperX Router(config)# vlan 10 by port

FastIron SuperX Router(config-vlan-10)# untagged e 2/10

FastIron SuperX Router(config-vlan-10)# tagged e 2/11

FastIron SuperX Router(config-vlan-10)# exit

FastIron SuperX Router(config)# vlan 20 by port

FastIron SuperX Router(config-vlan-20)# tagged e 2/9

FastIron SuperX Router(config-vlan-20)# tagged e 2/11

FastIron SuperX Router(config-vlan-20)# exit

FastIron SuperX Router(config)# int e 2/11

FastIron SuperX Router(config-if-e1000-2/11)# dual-mode 10

FastIron SuperX Router(config-if-e1000-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.

The show vlan command displays a separate row for dual-mode ports on each VLAN. For example:

FastIron SuperX Router(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

11 - 58 © Foundry Networks, Inc.

December 2005

Configuring Virtual LANs (VLANs)

Displaying VLAN Information

After you configure the VLANs, you can verify the configuration using the following methods.

NOTE: If a VLAN name begins with “GVRP_VLAN_“, the VLAN was created by the GARP VLAN Registration

Protocol (GVRP). If a VLAN name begins with “STATIC_VLAN_“, the VLAN was created by GVRP and then was converted into a statically configured VLAN.

Displaying System-Wide VLAN Information

Use one of the following methods to display VLAN information for all the VLANs configured on the device.

Enter the following command at any CLI level. This example shows the display for the IP sub-net and IPX network

VLANs configured in the examples in “Configuring an IP Sub-Net VLAN with Dynamic Ports” on page 11-34 and

“Configuring an IPX Network VLAN with Dynamic Ports” on page 11-34.

FastIron SuperX Router(config)# show vlans

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

IP-subnet VLAN 1.1.1.0 255.255.255.0, Dynamic port enabled

Name: Mktg-LAN

Static ports: None

Exclude ports: None

Dynamic ports: (S1) 1 2 3 4 5 6

PORT-VLAN 20, Name IPX_VLAN, Priority level0, Spanning tree Off

Untagged Ports: (S2) 1 2 3 4 5 6

Tagged Ports: None

IPX-network VLAN 0000ABCD, frame type ethernet_ii, Dynamic port enabled

Name: Eng-LAN

Static ports: None

Exclude ports: None

Dynamic ports: (S2) 1 2 3 4 5 6

Syntax: show vlans [<vlan-id> | ethernet [<slotnum>/]<portnum>]

The <vlan-id> parameter specifies a VLAN for which you want to display the configuration information.

The <slotnum> parameter is required on chassis devices.

The <portnum> parameter specifies a port. If you use this parameter, the command lists all the VLAN memberships for the port.

December 2005 © Foundry Networks, Inc.

11 - 59

Foundry Configuration Guide for the FESX, FSX, and FWSX

Displaying VLAN Information for Specific Ports

Use one of the following methods to display 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:

FastIron SuperX Router(config)# show vlans 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, Dynamic port disabled

Static ports: (S7) 1 2

Exclude ports: None

Dynamic ports: None

Syntax: show vlans [<vlan-id> | ethernet [<slotnum>/]<portnum>

The <vlan-id> parameter specifies a VLAN for which you want to display the configuration information.

The <slotnum> parameter is required on chassis devices.

The <portnum> parameter specifies a port. If you use this parameter, the command lists all the VLAN memberships for the port.

11 - 60 © Foundry Networks, Inc.

December 2005

Chapter 12

Rule-Based IP Access Control Lists (ACLs)

FESX, FSX, and FWSX devices support rule-based ACLs (sometimes called hardware-based ACLs), where the decisions to permit or deny packets are processed in hardware and all permitted packets are switched or routed in hardware.

Rule-based ACLs program the ACL entries you assign to an interface into Content Addressable Memory (CAM) space allocated for the port(s). The ACLs are programmed into hardware at startup (or as new ACLs are entered and bound to ports). Devices that use rule-based ACLs program the ACLs into the CAM entries and use these entries to permit or deny packets in the hardware, without sending the packets to the CPU for processing.

Rule-based ACLs are supported on physical interfaces, trunk groups, and virtual routing interfaces.

NOTE: The FESX, FSX, and FWSX devices support hardware-based ACLs only. These devices do not support flow-based ACLs. In contrast, FES devices support flow-based ACLs only.

This chapter contains the following information:

Table 12.1: Chapter Contents

Description

ACL Overview

How hardware-based ACLs work

Configuration considerations

Configuring standard numbered ACLs

Configuring standard named ACLs

Configuring extended numbered ACLs

Configuring extended named ACLs

Adding a comment to an ACL entry

Enabling ACL filtering of fragmented packets

Enabling ACL filtering based on VLAN membership or VE port membership

See Page

12-2

12-3

12-4

12-4

12-6

12-8

12-13

12-18

12-20

12-20

December 2005 © Foundry Networks, Inc.

12 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX

Table 12.1: Chapter Contents

Description

Filtering on IP Precedence and ToS Values

QoS options for IP ACLs

Using ACLs to rate limit traffic

Using ACLs to count packets

Using ACLs to control multicast features

Displaying ACL information

Troubleshooting ACLs

See Page

12-22

12-23

12-24

12-25

12-25

12-25

12-25

ACL Overview

This section provides an overview of ACLs.

Types of IP ACLs

You can configure the following types of IP ACLs:

• Standard – Permits or denies packets based on source IP address. Valid standard ACL IDs are 1 – 99 or a character string.

• Extended – Permits or denies packets based on source and destination IP address and also based on IP protocol information. Valid extended ACL IDs are a number from 100 – 199 or a character string.

ACL IDs and Entries

ACLs consist of ACL IDs and ACL entries:

• ACL ID – An ACL ID is a number from 1 – 99 (for a standard ACL) or 100 – 199 (for an extended ACL) or a character string. The ACL ID identifies a collection of individual ACL entries. When you apply ACL entries to an interface, you do so by applying the ACL ID that contains the ACL entries to the interface, instead of applying the individual entries to the interface. This makes applying large groups of access filters (ACL entries) to interfaces simple. See also “Numbered and Named ACLs” on page 12-3.

NOTE: This is different from IP access policies. If you use IP access policies, you apply the individual policies to interfaces.

• ACL entry – Also called an ACL rule , a filter command associated with an ACL ID. The maximum number of

ACL rules you can configure is a system-wide parameter and depends on the device you are configuring. You can configure up to the maximum number of entries in any combination in different ACLs. The total number of entries in all ACLs cannot exceed the system maximum.

• One-Gigabit ports on the FESX support up to 1016 ACL rules. On the FSX, multiple ACL groups share

1016 ACL rules per port region. Each ACL group must contain one entry for the implicit deny all IP traffic clause. Also, each ACL group uses a multiple of 8 ACL entries. For example, if all ACL groups contain 5

ACL entries, you could add 127ACL groups (1016/8) in that port region. If all your ACL groups contain 8

ACL entries, you could add 63 ACL groups, since you must account for the implicit deny entry.

• 10-Gigabit ports on the FESX and FSX support up to 1024 ACL rules.

You configure ACLs on a global basis, then apply them to the incoming or outgoing traffic on specific ports. You can apply only one ACL to a port’s inbound traffic and only one ACL to a port’s outbound traffic. The software applies the entries within an ACL in the order they appear in the ACL’s configuration. As soon as a match is found,

12 - 2 © Foundry Networks, Inc.

December 2005

Rule-Based IP Access Control Lists (ACLs) the software takes the action specified in the ACL entry (permit or deny the packet) and stops further comparison for that packet.

Numbered and Named ACLs

When you configure an ACL, you can refer to the ACL by a numeric ID or by an alphanumeric name. The commands to configure numbered ACLs are different from the commands for named ACLs.

• Numbered ACL – If you refer to the ACL by a numeric ID, you can use 1 – 99 for a standard ACL or 100 –

199 for an extended ACL.

• Named ACL – If you refer to the ACL by a name, you specify whether the ACL is a standard ACL or an extended ACL, then specify the name.

You can configure up to 99 standard numbered IP ACLs and 99 extended numbered IP ACLs. You also can configure up to 99 standard named ACLs and 99 extended named ACLs by number. Regardless of how many

ACLs you have, the device can have a maximum of 1024 ACL entries, associated with the ACLs in any combination.

Default ACL Action

The default action when no ACLs are configured on a device is to permit all traffic. However, once you configure an ACL and apply it to a port, the default action for that port is to deny all traffic that is not explicitly permitted on the port.

• If you want to tightly control access, configure ACLs consisting of permit entries for the access you want to permit. The ACLs implicitly deny all other access.

• If you want to secure access in environments with many users, you might want to configure ACLs that consist of explicit deny entries, then add an entry to permit all access to the end of each ACL. The software permits packets that are not denied by the deny entries.

NOTE: Do not apply an empty ACL (an ACL ID without any corresponding entries) to an interface. If you accidentally do this, the software applies the default ACL action, deny all, to the interface and thus denies all traffic.

How Hardware-Based ACLs Work

When you bind an ACL to inbound traffic on an interface, the device programs the Layer 4 CAM with the ACL.

Permit and deny rules are programmed. Most ACL rules require one Layer 4 CAM entry. However, ACL rules that match on more than one TCP or UDP application port may require several CAM entries. The Layer 4 CAM entries for ACLs do not age out. They remain in the CAM until you remove the ACL.

• If a packet received on the interface matches an ACL rule in the Layer 4 CAM, the device permits or denies the packet according to the ACL.

• If a packet does not match an ACL rule, the packet is dropped, since the default action on an interface that has ACLs is to deny the packet.

How Fragmented Packets are Processed

The descriptions above apply to non-fragmented packets. The default processing of fragments by hardwarebased ACLs is as follows:

• The first fragment of a packet is permitted or denied using the ACLs. The first fragment is handled the same way as non-fragmented packets, since the first fragment contains the Layer 4 source and destination application port numbers. The device uses the Layer 4 CAM entry if one is programmed, or applies the interface's ACL entries to the packet and permits or denies the packet according to the first matching ACL.

• For other fragments of the same packet, they are subject to a rule only if there is no Layer 4 information in the rule or in any preceding rules.

December 2005 © Foundry Networks, Inc.

12 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

The fragments are forwarded even if the first fragment, which contains the Layer 4 information, was denied.

Generally, denying the first fragment of a packet is sufficient, since a transaction cannot be completed without the entire packet.

For tighter control, you can configure the port to drop all packet fragments. See “Enabling Strict Control of ACL

Filtering of Fragmented Packets” on page 12-20.

Hardware Aging of Layer 4 CAM Entries

Rule-based ACLs use Layer 4 CAM entries. The device permanently programs rule-based ACLs into the CAM.

The entries never age out.

Configuration Considerations

• Hardware-based ACLs are supported on all Ethernet ports and on 10 Gigabit Ethernet ports.

• Hardware-based ACLs are supported on physical interfaces, trunk groups, and virtual routing interfaces.

• Hardware-based ACLs are supported only for inbound traffic.

• ACLs on the FESX, FSX, and FWSX apply to all traffic, including management traffic.

• ACL logging is supported for packets that are sent to the CPU for processing. ACL logging is not supported for packets that are processed in hardware.

• Hardware-based ACLs support only one ACL per port. The ACL of course can contain multiple entries

(rules). For example, hardware-based ACLs do not support ACLs 101 and 102 on port 1, but hardwarebased ACLs do support ACL 101 containing multiple entries.

• One-Gigabit ports on all FESX and FWSX devices support up to 1016 ACL rules. 10-Gigabit ports on all

FESX and FWSX devices support up to 1024 ACL rules. ACLs on the FSX are affected by port regions.

Multiple ACL groups share 1016 ACL rules per port region. Each ACL group must contain one entry for the implicit deny all IP traffic clause. Also, each ACL group uses a multiple of 8 ACL entries. For example, if all

ACL groups contain 5 ACL entries, you could add 127ACL groups (1016/8) in that port region. If all your ACL groups contain 8 ACL entries, you could add 63 ACL groups, since you must account for the implicit deny entry.

• By default, the first fragment of a fragmented packet received by the Foundry device is permitted or denied using the ACLs, but subsequent fragments of the same packet are forwarded in hardware. Generally, denying the first fragment of a packet is sufficient, since a transaction cannot be completed without the entire packet.

• The following ACL features and options are not supported on the FESX and FSX:

• Applying an ACL on a device that has Super Aggregated VLANs (SAVs) enabled.

• Enabling CPU filtering of all fragmented packets on a port ( ip access-group frag inspect command)

• Configuring a port to drop all packet fragments ( ip access-group frag deny command)

• Flow-based ACLs

• ACL statistics

NOTE: You can apply an ACL to a port that has TCP SYN protection and/or ICMP smurf protection enabled.

Configuring Standard Numbered ACLs

This section describes how to configure standard numbered ACLs with numeric IDs and provides configuration examples.

Standard ACLs permit or deny packets based on source IP address. You can configure up to 99 standard numbered ACLs. There is no limit to the number of ACL entries an ACL can contain except for the system-wide limitation. For the number of ACL entries supported on a device, see “ACL IDs and Entries” on page 12-2.

12 - 4 © Foundry Networks, Inc.

December 2005

Rule-Based IP Access Control Lists (ACLs)

Standard Numbered ACL Syntax

Syntax: [no] access-list <acl-num> deny | permit <source-ip> | <hostname> <wildcard> [log] or

Syntax: [no] access-list <acl-num> deny | permit <source-ip>/<mask-bits> | <hostname> [log]

Syntax: [no] access-list <acl-num> deny | permit host <source-ip> | <hostname> [log]

Syntax: [no] access-list <acl-num> deny | permit any [log]

Syntax: [no] ip access-group <acl-num> in

The <acl-num> parameter is the access list number from 1 – 99.

The deny | permit parameter indicates whether packets that match a policy in the access list are denied

(dropped) or permitted (forwarded).

The <source-ip> parameter specifies the source IP address. Alternatively, you can specify the host name.

NOTE: To specify the host name instead of the IP address, the host name must be configured using the Foundry device’s DNS resolver. To configure the DNS resolver name, use the ip dns server-address… command at the global CONFIG level of the CLI.

The <wildcard> parameter specifies the mask value to compare against the host address specified by the

<source-ip> parameter. The <wildcard> is a four-part value in dotted-decimal notation (IP address format) consisting of ones and zeros. Zeros in the mask mean the packet’s source address must match the <source-ip>.

Ones mean any value matches. For example, the <source-ip> and <wildcard> values 209.157.22.26 0.0.0.255 mean that all hosts in the Class C subnet 209.157.22.x match the policy.

If you prefer to specify the wildcard (mask value) in CIDR format, you can enter a forward slash after the IP address, then enter the number of significant bits in the mask. For example, you can enter the CIDR equivalent of

“209.157.22.26 0.0.0.255” as “209.157.22.26/24”. The CLI automatically converts the CIDR number into the appropriate ACL mask (where zeros instead of ones are the significant bits) and changes the non-significant portion of the IP address into ones. For example, if you specify 209.157.22.26/24 or 209.157.22.26 0.0.0.255, then save the changes to the startup-config file, the value appears as 209.157.22.0/24 (if you have enabled display of subnet lengths) or 209.157.22.0 0.0.0.255 in the startup-config file.

If you enable the software to display IP subnet masks in CIDR format, the mask is saved in the file in

“/<mask-bits>” format. To enable the software to display the CIDR masks, enter the ip show-subnet-length command at the global CONFIG level of the CLI. You can use the CIDR format to configure the ACL entry regardless of whether the software is configured to display the masks in CIDR format.

NOTE: If you use the CIDR format, the ACL entries appear in this format in the running-config and startup-config files, but are shown with subnet mask in the display produced by the show ip access-list command.

The host <source-ip> | <hostname> parameter lets you specify a host IP address or name. When you use this parameter, you do not need to specify the mask. A mask of all zeros (0.0.0.0) is implied.

The any parameter configures the policy to match on all host addresses.

The log argument configures the device to generate Syslog entries and SNMP traps for packets that are permitted or denied by the access policy. If you use the log argument, the ACL entry is sent to the CPU for processing.

NOTE: You can enable logging on ACLs and filters that support logging even when the ACLs and filters are already in use. To do so, re-enter the ACL or filter command and add the log parameter to the end of the ACL or filter. The software replaces the ACL or filter command with the new one. The new ACL or filter, with logging enabled, takes effect immediately.

The in parameter applies the ACL to incoming traffic on the interface to which you apply the ACL. You can apply the ACL to an Ethernet port or virtual interface.

December 2005 © Foundry Networks, Inc.

12 - 5

Foundry Configuration Guide for the FESX, FSX, and FWSX

NOTE: If the ACL is for a virtual routing interface, you also can specify a subset of ports within the VLAN containing that interface when assigning an ACL to the interface.

Configuration Example for Standard Numbered ACLs

To configure a standard ACL and apply it to incoming traffic on port 1/1, enter the following commands.

FastIron SuperX Router(config)# access-list 1 deny host 209.157.22.26 log

FastIron SuperX Router(config)# access-list 1 deny 209.157.29.12 log

FastIron SuperX Router(config)# access-list 1 deny host IPHost1 log

FastIron SuperX Router(config)# access-list 1 permit any

FastIron SuperX Router(config)# int eth 1/1

FastIron SuperX Router(config-if-1/1)# ip access-group 1 in

FastIron SuperX Router(config)# write memory

The commands in this example configure an ACL to deny packets from three source IP addresses from being received on port 1/1. The last ACL entry in this ACL permits all packets that are not explicitly denied by the first three ACL entries.

Configuring Standard Named ACLs

This section describes how to configure standard named ACLs with alphanumeric IDs. This section also provides configuration examples.

Standard ACLs permit or deny packets based on source IP address. You can configure up to 99 standard named

ACLs. There is no limit to the number of ACL entries an ACL can contain except for the system-wide limitation.

For the number of ACL entries supported on a device, see “ACL IDs and Entries” on page 12-2.

The commands for configuring named ACL entries are different from the commands for configuring numbered

ACL entries. The command to configure a numbered ACL is access-list . The command for configuring a named

ACL is ip access-list . In addition, when you configure a numbered ACL entry, you specify all the command parameters on the same command. When you configure a named ACL, you specify the ACL type (standard or extended) and the ACL name with one command, which places you in the configuration level for that ACL. Once you enter the configuration level for the ACL, the command syntax is the same as the syntax for numbered ACLs.

Standard Named ACL Syntax

Syntax: [no] ip access-list standard <acl-name> | <acl-num>

Syntax: deny | permit <source-ip> | <hostname> <wildcard> [log] or

Syntax: deny | permit <source-ip>/<mask-bits> | <hostname> [log]

Syntax: deny | permit host <source-ip> | <hostname> [log]

Syntax: deny | permit any [log]

Syntax: [no] ip access-group <acl-name> in

The <acl-name> parameter is the access list name. You can specify a string of up to 256 alphanumeric characters. You can use blanks in the ACL name if you enclose the name in quotation marks (for example, “ACL for Net1”).

The <acl-num> parameter allows you to specify an ACL number if you prefer. If you specify a number, you can specify from 1 – 99 for standard ACLs.

NOTE: For convenience, the software allows you to configure numbered ACLs using the syntax for named ACLs.

The software also still supports the older syntax for numbered ACLs. Although the software allows both methods for configuring numbered ACLs, numbered ACLs are always formatted in the startup-config and running-config files in using the older syntax, as follows.

12 - 6 © Foundry Networks, Inc.

December 2005

Rule-Based IP Access Control Lists (ACLs) access-list 1 deny host 209.157.22.26 log access-list 1 deny 209.157.22.0 0.0.0.255 log access-list 1 permit any access-list 101 deny tcp any any eq http log

The deny | permit parameter indicates whether packets that match a policy in the access list are denied

(dropped) or permitted (forwarded).

The <source-ip> parameter specifies the source IP address. Alternatively, you can specify the host name.

NOTE: To specify the host name instead of the IP address, the host name must be configured using the Foundry device’s DNS resolver. To configure the DNS resolver name, use the ip dns server-address… command at the global CONFIG level of the CLI.

The <wildcard> parameter specifies the mask value to compare against the host address specified by the

<source-ip> parameter. The <wildcard> is a four-part value in dotted-decimal notation (IP address format) consisting of ones and zeros. Zeros in the mask mean the packet’s source address must match the <source-ip>.

Ones mean any value matches. For example, the <source-ip> and <wildcard> values 209.157.22.26 0.0.0.255 mean that all hosts in the Class C subnet 209.157.22.x match the policy.

If you prefer to specify the wildcard (mask value) in CIDR format, you can enter a forward slash after the IP address, then enter the number of significant bits in the mask. For example, you can enter the CIDR equivalent of

“209.157.22.26 0.0.0.255” as “209.157.22.26/24”. The CLI automatically converts the CIDR number into the appropriate ACL mask (where zeros instead of ones are the significant bits) and changes the non-significant portion of the IP address into ones. For example, if you specify 209.157.22.26/24 or 209.157.22.26 0.0.0.255, then save the changes to the startup-config file, the value appears as 209.157.22.0/24 (if you have enabled display of subnet lengths) or 209.157.22.0 0.0.0.255 in the startup-config file.

If you enable the software to display IP subnet masks in CIDR format, the mask is saved in the file in

“/<mask-bits>” format. To enable the software to display the CIDR masks, enter the ip show-subnet-length command at the global CONFIG level of the CLI. You can use the CIDR format to configure the ACL entry regardless of whether the software is configured to display the masks in CIDR format.

NOTE: If you use the CIDR format, the ACL entries appear in this format in the running-config and startup-config files, but are shown with subnet mask in the display produced by the show ip access-list command.

The host <source-ip> | <hostname> parameter lets you specify a host IP address or name. When you use this parameter, you do not need to specify the mask. A mask of all zeros (0.0.0.0) is implied.

The any parameter configures the policy to match on all host addresses.

The log argument configures the device to generate Syslog entries and SNMP traps for packets that are permitted or denied by the access policy. If you use the log argument, the ACL entry is sent to the CPU for processing.

NOTE: You can enable logging on ACLs and filters that support logging even when the ACLs and filters are already in use. To do so, re-enter the ACL or filter command and add the log parameter to the end of the ACL or filter. The software replaces the ACL or filter command with the new one. The new ACL or filter, with logging enabled, takes effect immediately.

The in parameter applies the ACL to incoming traffic on the interface to which you apply the ACL. You can apply the ACL to an Ethernet port or virtual interface.

NOTE: If the ACL is bound to a virtual routing interface, you also can specify a subset of ports within the VLAN containing that interface when assigning an ACL to the interface.

December 2005 © Foundry Networks, Inc.

12 - 7

Foundry Configuration Guide for the FESX, FSX, and FWSX

Configuration Example for Standard Named ACLs

To configure a standard named ACL, enter commands such as the following.

FESX424 Router(config)# ip access-list standard Net1

FESX424 Router(config-std-nacl)# deny host 209.157.22.26 log

FESX424 Router(config-std-nacl)# deny 209.157.29.12 log

FESX424 Router(config-std-nacl)# deny host IPHost1 log

FESX424 Router(config-std-nacl)# permit any

FESX424 Router(config-std-nacl)# exit

FESX424 Router(config)# int eth 1

FESX424 Router(config-if-e1000-1)# ip access-group Net1 in

The commands in this example configure a standard ACL named “Net1”. The entries in this ACL deny packets from three source IP addresses from being forwarded on port 1. Since the implicit action for an ACL is “deny”, the last ACL entry in this ACL permits all packets that are not explicitly denied by the first three ACL entries. For an example of how to configure the same entries in a numbered ACL, see “Configuring Standard Numbered ACLs” on page 12-4.

Notice that the command prompt changes after you enter the ACL type and name. The “std” in the command prompt indicates that you are configuring entries for a standard ACL. For an extended ACL, this part of the command prompt is “ext“. The “nacl” indicates that you are configuring a named ACL.

Configuring Extended Numbered ACLs

This section describes how to configure extended numbered ACLs.

Extended ACLs let you permit or deny packets based on the following information:

• IP protocol

• Source IP address or host name

• Destination IP address or host name

• Source TCP or UDP port (if the IP protocol is TCP or UDP)

• Destination TCP or UDP port (if the IP protocol is TCP or UDP)

The IP protocol can be one of the following well-known names or any IP protocol number from 0 – 255:

• Internet Control Message Protocol (ICMP)

• Internet Group Management Protocol (IGMP)

• Internet Gateway Routing Protocol (IGRP)

• Internet Protocol (IP)

• Open Shortest Path First (OSPF)

• Transmission Control Protocol (TCP)

• User Datagram Protocol (UDP)

For TCP and UDP, you also can specify a comparison operator and port name or number. For example, you can configure a policy to block web access to a specific website by denying all TCP port 80 (HTTP) packets from a specified source IP address to the website’s IP address.

Extended Numbered ACL Syntax

[no] access-list <acl-num> deny | permit <ip-protocol> <source-ip> | <hostname> <wildcard> [<operator>

<source-tcp/udp-port>] <destination-ip> | <hostname> [<icmp-num> | <icmp-type>] <wildcard> [<tcp/udp comparison operator> <destination-tcp/udp-port>] [dscp-cos-mapping ] [dscp-marking <0-63> [802.1p-priority-

12 - 8 © Foundry Networks, Inc.

December 2005

Rule-Based IP Access Control Lists (ACLs) marking <0 –7>... | dscp-cos-mapping]] [dscp-matching <0-63>] [log] [precedence <name> | <0 – 7>] [tos <0 –

63> | <name>] [traffic policy <name>]

[no] access-list <acl-num> deny | permit host <ip-protocol> any any

Syntax: [no] ip access-group <acl-num> in

The <acl-num> parameter is the extended access list number. Specify a number from 100 – 199.

The deny | permit parameter indicates whether packets that match the policy are dropped or forwarded.

The <ip-protocol> parameter indicates the type of IP packet you are filtering. You can specify a well-known name for any protocol whose number is less than 255. For other protocols, you must enter the number. Enter “?” instead of a protocol to list the well-known names recognized by the CLI.

The <source-ip> | <hostname> parameter specifies the source IP host for the policy. If you want the policy to match on all source addresses, enter any .

The <wildcard> parameter specifies the portion of the source IP host address to match against. The <wildcard> is a four-part value in dotted-decimal notation (IP address format) consisting of ones and zeros. Zeros in the mask mean the packet’s source address must match the <source-ip>. Ones mean any value matches. For example, the <source-ip> and <wildcard> values 209.157.22.26 0.0.0.255 mean that all hosts in the Class C subnet

209.157.22.x match the policy.

If you prefer to specify the wildcard (mask value) in Classless Interdomain Routing (CIDR) format, you can enter a forward slash after the IP address, then enter the number of significant bits in the mask. For example, you can enter the CIDR equivalent of “209.157.22.26 0.0.0.255” as “209.157.22.26/24”. The CLI automatically converts the CIDR number into the appropriate ACL mask (where zeros instead of ones are the significant bits) and changes the non-significant portion of the IP address into zeros. For example, if you specify 209.157.22.26/24 or

209.157.22.26 0.0.0.255, then save the changes to the startup-config file, the value appears as 209.157.22.0/24

(if you have enabled display of subnet lengths) or 209.157.22.0 0.0.0.255 in the startup-config file.

If you enable the software to display IP subnet masks in CIDR format, the mask is saved in the file in “/<maskbits>” format. To enable the software to display the CIDR masks, enter the ip show-subnet-length command at the global CONFIG level of the CLI. You can use the CIDR format to configure the ACL entry regardless of whether the software is configured to display the masks in CIDR format.

NOTE: If you use the CIDR format, the ACL entries appear in this format in the running-config and startup-config files, but are shown with subnet mask in the display produced by the show ip access-list command.

The <destination-ip> | <hostname> parameter specifies the destination IP host for the policy. If you want the policy to match on all destination addresses, enter any .

The <icmp-type> | <icmp-num> parameter specifies the ICMP protocol type.

• This parameter applies only if you specified icmp as the <ip-protocol> value.

• If you use this parameter, the ACL entry is sent to the CPU for processing.

• If you do not specify a message type, the ACL applies to all types of ICMP messages.

The <icmp-num> parameter can be a value from 0 – 255.

The <icmp-type> parameter can have one of the following values, depending on the software version the device is running:

• any-icmp-type

• echo

• echo-reply

• information-request

• log

• mask-reply

December 2005 © Foundry Networks, Inc.

12 - 9

Foundry Configuration Guide for the FESX, FSX, and FWSX

• mask-request

• parameter-problem

• redirect

• source-quench

• time-exceeded

• timestamp-reply

• timestamp-request

• traffic policy

• unreachable

• <num>

The <tcp/udp comparison operator> parameter specifies a comparison operator for the TCP or UDP port number.

This parameter applies only when you specify tcp or udp as the IP protocol. For example, if you are configuring an entry for HTTP, specify tcp eq http . You can enter one of the following operators:

• eq – The policy applies to the TCP or UDP port name or number you enter after eq .

• established – This operator applies only to TCP packets. If you use this operator, the policy applies to TCP packets that have the ACK (Acknowledgment) or RST (Reset) bits set on (set to “1”) in the Control Bits field of the TCP packet header. Thus, the policy applies only to established TCP sessions, not to new sessions. See

Section 3.1, “Header Format”, in RFC 793 for information about this field.

NOTE: This operator applies only to destination TCP ports, not source TCP ports.

• gt – The policy applies to TCP or UDP port numbers greater than the port number or the numeric equivalent of the port name you enter after gt .

• lt – The policy applies to TCP or UDP port numbers that are less than the port number or the numeric equivalent of the port name you enter after lt .

• neq – The policy applies to all TCP or UDP port numbers except the port number or port name you enter after neq .

• range – The policy applies to all TCP or UDP port numbers that are between the first TCP or UDP port name or number and the second one you enter following the range parameter. The range includes the port names or numbers you enter. For example, to apply the policy to all ports between and including 23 (Telnet) and 53

(DNS), enter the following: range 23 53 . The first port number in the range must be lower than the last number in the range.

The <tcp/udp-port> parameter specifies the TCP or UDP port number or well-known name. You can specify a well-known name for any application port whose number is less than 1024. For other application ports, you must enter the number. Enter “?” instead of a port to list the well-known names recognized by the CLI.

The in parameter specifies that the ACL applies to incoming traffic on the interface to which you apply the ACL.

You can apply the ACL to an Ethernet port or a virtual interface.

NOTE: If the ACL is for a virtual routing interface, you also can specify a subset of ports within the VLAN containing that interface when assigning an ACL to the interface. See “Configuring Standard Numbered ACLs” on page 12-4.

The precedence <name> | <num> parameter of the ip access-list command specifies the IP precedence. The precedence option for of an IP packet is set in a three-bit field following the four-bit header-length field of the packet’s header. You can specify one of the following:

• critical or 5 – The ACL matches packets that have the critical precedence. If you specify the option number instead of the name, specify number 5.

• flash or 3 – The ACL matches packets that have the flash precedence. If you specify the option number

12 - 10 © Foundry Networks, Inc.

December 2005

Rule-Based IP Access Control Lists (ACLs) instead of the name, specify number 3.

• flash-override or 4 – The ACL matches packets that have the flash override precedence. If you specify the option number instead of the name, specify number 4.

• immediate or 2 – The ACL matches packets that have the immediate precedence. If you specify the option number instead of the name, specify number 2.

• internet or 6 – The ACL matches packets that have the internetwork control precedence. If you specify the option number instead of the name, specify number 6.

• network or 7 – The ACL matches packets that have the network control precedence. If you specify the option number instead of the name, specify number 7.

• priority or 1 – The ACL matches packets that have the priority precedence. If you specify the option number instead of the name, specify number 1.

• routine or 0 – The ACL matches packets that have the routine precedence. If you specify the option number instead of the name, specify number 0.

The tos <name> | <num> parameter of the ip access-list command specifies the IP ToS. You can specify one of the following:

• max-reliability or 2 – The ACL matches packets that have the maximum reliability ToS. The decimal value for this option is 2.

• max-throughput or 4 – The ACL matches packets that have the maximum throughput ToS. The decimal value for this option is 4.

• min-delay or 8 – The ACL matches packets that have the minimum delay ToS. The decimal value for this option is 8.

• min-monetary-cost or 1 – The ACL matches packets that have the minimum monetary cost ToS. The decimal value for this option is 1.

NOTE: This value is not supported on 10 Gigabit Ethernet modules.

• normal or 0 – The ACL matches packets that have the normal ToS. The decimal value for this option is 0.

• <num> – A number from 0 – 15 that is the sum of the numeric values of the options you want. The ToS field is a four-bit field following the Precedence field in the IP header. You can specify one or more of the following.

To select more than one option, enter the decimal value that is equivalent to the sum of the numeric values of all the ToS options you want to select. For example, to select the max-reliability and min-delay options, enter number 10. To select all options, select 15.

The dscp-cos-mapping option maps the DSCP value in incoming packets to a hardware table that provides mapping of each of the 0 – 63 DSCP values, and distributes them among eight traffic classes (internal priorities) and eight 802.1p priorities.

NOTE: The dscp-cos-mapping option overrides port-based priority settings.

The dscp-marking option enables you to configure an ACL that marks matching packets with a specified DSCP value Enter a value from 0 – 63. See “Using an IP ACL to Mark DSCP Values (DSCP Marking)” on page 12-23.

The dscp-matching option matches on the packet’s DSCP value. Enter a value from 0 – 63. This option does not change the packet’s forwarding priority through the device or mark the packet. See “DSCP Matching” on page 12-

24.

The log parameter enables SNMP traps and Syslog messages for packets denied by the ACL.

You can enable logging on ACLs and filters that support logging even when the ACLs and filters are already in use.

To do so, re-enter the ACL or filter command and add the log parameter to the end of the ACL or filter. The software replaces the ACL or filter command with the new one. The new ACL or filter, with logging enabled, takes effect immediately.

December 2005 © Foundry Networks, Inc.

12 - 11

Foundry Configuration Guide for the FESX, FSX, and FWSX

The traffic-policy option enables the device to rate limit inbound traffic and to count the packets and bytes per packet to which ACL permit or deny clauses are applied. For configuration procedures and examples, see the chapter “Traffic Policies” on page 15-1.

Configuration Examples for Extended Numbered ACLs

To configure an extended access list that blocks all Telnet traffic received on port 1/1 from IP host 209.157.22.26, enter the following commands.

FESX424 Router(config)# access-list 101 deny tcp host 209.157.22.26 any eq telnet log

FESX424 Router(config)# access-list 101 permit ip any any

FESX424 Router(config)# int eth 1

FESX424 Router(config-if-e1000-1)# ip access-group 101 in

FESX424 Router(config)# write memory

Here is another example of commands for configuring an extended ACL and applying it to an interface. These examples show many of the syntax choices. Notice that some of the entries are configured to generate log entries while other entries are not thus configured.

FESX424 Router(config)# access-list 102 perm icmp 209.157.22.0/24 209.157.21.0/24

FESX424 Router(config)# access-list 102 deny igmp host rkwong 209.157.21.0/24 log

FESX424 Router(config)# access-list 102 deny igrp 209.157.21.0/24 host rkwong log

FESX424 Router(config)# access-list 102 deny ip host 209.157.21.100 host

209.157.22.1 log

FESX424 Router(config)# access-list 102 deny ospf any any log

FESX424 Router(config)# access-list 102 permit ip any any

The first entry permits ICMP traffic from hosts in the 209.157.22.

x network to hosts in the 209.157.21.

x network.

The second entry denies IGMP traffic from the host device named “rkwong” to the 209.157.21.

x network.

The third entry denies IGRP traffic from the 209.157.21.

x network to the host device named “rkwong”.

The fourth entry denies all IP traffic from host 209.157.21.100to host 209.157.22.1 and generates Syslog entries for packets that are denied by this entry.

The fifth entry denies all OSPF traffic and generates Syslog entries for denied traffic.

The sixth entry permits all packets that are not explicitly denied by the other entries. Without this entry, the ACL would deny all incoming or outgoing IP traffic on the ports to which you assign the ACL.

The following commands apply ACL 102 to the incoming traffic on port 1/2 and to the incoming traffic on port 4/3.

FastIron SuperX Router(config)# int eth 1/2

FastIron SuperX Router(config-if-1/2)# ip access-group 102 in

FastIron SuperX Router(config-if-1/2)# exit

FastIron SuperX Router(config)# int eth 4/3

FastIron SuperX Router(config-if-4/3)# ip access-group 102 in

FastIron SuperX Router(config)# write memory

12 - 12 © Foundry Networks, Inc.

December 2005

Rule-Based IP Access Control Lists (ACLs)

Here is another example of an extended ACL.

FastIron SuperX Router(config)# access-list 103 deny tcp 209.157.21.0/24

209.157.22.0/24

FastIron SuperX Router(config)# access-list 103 deny tcp 209.157.21.0/24 eq ftp

209.157.22.0/24

FastIron SuperX Router(config)# access-list 103 deny tcp 209.157.21.0/24

209.157.22.0/24 lt telnet neq 5

FastIron SuperX Router(config)# access-list 103 deny udp any range 5 6

209.157.22.0/24 range 7 8

FastIron SuperX Router(config)# access-list 103 permit ip any any

The first entry in this ACL denies TCP traffic from the 209.157.21.

x network to the 209.157.22.x network.

The second entry denies all FTP traffic from the 209.157.21.

x network to the 209.157.22.x network.

The third entry denies TCP traffic from the 209.157.21.

x network to the 209.157.22.

x network, if the TCP port number of the traffic is less than the well-known TCP port number for Telnet (23), and if the TCP port is not equal to 5. Thus, TCP packets whose TCP port numbers are 5 or are greater than 23 are allowed.

The fourth entry denies UDP packets from any source to the 209.157.22.

x network, if the UDP port number from the source network is 5 or 6 and the destination UDP port is 7 or 8.

The fifth entry permits all packets that are not explicitly denied by the other entries. Without this entry, the ACL would deny all incoming or outgoing IP traffic on the ports to which you assign the ACL.

The following commands apply ACL 103 to the incoming traffic on ports 2/1 and 2/2.

FastIron SuperX Router(config)# int eth 2/1

FastIron SuperX Router(config-if-2/1)# ip access-group 103 in

FastIron SuperX Router(config-if-2/1)# exit

FastIron SuperX Router(config)# int eth 2/2

FastIron SuperX Router(config-if-2/2)# ip access-group 103 in

FastIron SuperX Router(config)# write memory

Configuring Extended Named ACLs

The commands for configuring named ACL entries are different from the commands for configuring numbered

ACL entries. The command to configure a numbered ACL is access-list . The command for configuring a named

ACL is ip access-list . In addition, when you configure a numbered ACL entry, you specify all the command parameters on the same command. When you configure a named ACL, you specify the ACL type (standard or extended) and the ACL number with one command, which places you in the configuration level for that ACL. Once you enter the configuration level for the ACL, the command syntax is the same as the syntax for numbered ACLs.

Extended ACLs let you permit or deny packets based on the following information:

• IP protocol

• Source IP address or host name

• Destination IP address or host name

• Source TCP or UDP port (if the IP protocol is TCP or UDP)

• Destination TCP or UDP port (if the IP protocol is TCP or UDP)

The IP protocol can be one of the following well-known names or any IP protocol number from 0 – 255:

• Internet Control Message Protocol (ICMP)

• Internet Group Management Protocol (IGMP)

December 2005 © Foundry Networks, Inc.

12 - 13

Foundry Configuration Guide for the FESX, FSX, and FWSX

• Internet Gateway Routing Protocol (IGRP)

• Internet Protocol (IP)

• Open Shortest Path First (OSPF)

• Transmission Control Protocol (TCP)

• User Datagram Protocol (UDP)

For TCP and UDP, you also can specify a comparison operator and port name or number. For example, you can configure a policy to block web access to a specific website by denying all TCP port 80 (HTTP) packets from a specified source IP address to the website’s IP address.

12 - 14 © Foundry Networks, Inc.

December 2005

Rule-Based IP Access Control Lists (ACLs)

Extended Named ACL Syntax

Syntax: [no] ip access-list extended <acl-name> deny | permit <ip-protocol> <source-ip> | <hostname> <wildcard> [<operator> <source-tcp/udp-port>]

<destination-ip> | <hostname> [<icmp-num> | <icmp-type>] <wildcard> [<tcp/udp comparison operator>

<destination-tcp/udp-port>] [dscp-cos-mapping ] [dscp-marking <0-63> [802.1p-priority-marking <0 –7>... | dscpcos-mapping]] [dscp-matching <0-63>] [log] [precedence <name> | <0 – 7>] [tos <0 – 63> | <name>] [traffic policy

<name>]

Syntax: [no] access-list <num> deny | permit host <ip-protocol> any any

Syntax: [no] ip access-group <num> in

The <acl-name> parameter is the access list name. You can specify a string of up to 256 alphanumeric characters. You can use blanks in the ACL name if you enclose the name in quotation marks (for example, “ACL for Net1”).

The deny | permit parameter indicates whether packets that match the policy are dropped or forwarded.

The <ip-protocol> parameter indicates the type of IP packet you are filtering. You can specify a well-known name for any protocol whose number is less than 255. For other protocols, you must enter the number. Enter “?” instead of a protocol to list the well-known names recognized by the CLI.

The <source-ip> | <hostname> parameter specifies the source IP host for the policy. If you want the policy to match on all source addresses, enter any .

The <wildcard> parameter specifies the portion of the source IP host address to match against. The <wildcard> is a four-part value in dotted-decimal notation (IP address format) consisting of ones and zeros. Zeros in the mask mean the packet’s source address must match the <source-ip>. Ones mean any value matches. For example, the <source-ip> and <wildcard> values 209.157.22.26 0.0.0.255 mean that all hosts in the Class C subnet

209.157.22.x match the policy.

If you prefer to specify the wildcard (mask value) in Classless Interdomain Routing (CIDR) format, you can enter a forward slash after the IP address, then enter the number of significant bits in the mask. For example, you can enter the CIDR equivalent of “209.157.22.26 0.0.0.255” as “209.157.22.26/24”. The CLI automatically converts the CIDR number into the appropriate ACL mask (where zeros instead of ones are the significant bits) and changes the non-significant portion of the IP address into zeros. For example, if you specify 209.157.22.26/24 or

209.157.22.26 0.0.0.255, then save the changes to the startup-config file, the value appears as 209.157.22.0/24

(if you have enabled display of subnet lengths) or 209.157.22.0 0.0.0.255 in the startup-config file.

If you enable the software to display IP subnet masks in CIDR format, the mask is saved in the file in “/<maskbits>” format. To enable the software to display the CIDR masks, enter the ip show-subnet-length command at the global CONFIG level of the CLI. You can use the CIDR format to configure the ACL entry regardless of whether the software is configured to display the masks in CIDR format.

NOTE: If you use the CIDR format, the ACL entries appear in this format in the running-config and startup-config files, but are shown with subnet mask in the display produced by the show ip access-list command.

The <destination-ip> | <hostname> parameter specifies the destination IP host for the policy. If you want the policy to match on all destination addresses, enter any .

The <icmp-type> | <icmp-num> parameter specifies the ICMP protocol type.

• This parameter applies only if you specified icmp as the <ip-protocol> value.

• If you use this parameter, the ACL entry is sent to the CPU for processing.

• If you do not specify a message type, the ACL applies to all types of ICMP messages.

The <icmp-num> parameter can be a value from 0 – 255.

The <icmp-type> parameter can have one of the following values, depending on the software version the device is running:

• any-icmp-type

December 2005 © Foundry Networks, Inc.

12 - 15

Foundry Configuration Guide for the FESX, FSX, and FWSX

• echo

• echo-reply

• information-request

• log

• mask-reply

• mask-request

• parameter-problem

• redirect

• source-quench

• time-exceeded

• timestamp-reply

• timestamp-request

• traffic policy

• unreachable

• <num>

The <tcp/udp comparison operator> parameter specifies a comparison operator for the TCP or UDP port number.

This parameter applies only when you specify tcp or udp as the IP protocol. For example, if you are configuring an entry for HTTP, specify tcp eq http . You can enter one of the following operators:

• eq – The policy applies to the TCP or UDP port name or number you enter after eq .

• established – This operator applies only to TCP packets. If you use this operator, the policy applies to TCP packets that have the ACK (Acknowledgment) or RST (Reset) bits set on (set to “1”) in the Control Bits field of the TCP packet header. Thus, the policy applies only to established TCP sessions, not to new sessions. See

Section 3.1, “Header Format”, in RFC 793 for information about this field.

NOTE: This operator applies only to destination TCP ports, not source TCP ports.

• gt – The policy applies to TCP or UDP port numbers greater than the port number or the numeric equivalent of the port name you enter after gt .

• lt – The policy applies to TCP or UDP port numbers that are less than the port number or the numeric equivalent of the port name you enter after lt .

• neq – The policy applies to all TCP or UDP port numbers except the port number or port name you enter after neq .

• range – The policy applies to all TCP or UDP port numbers that are between the first TCP or UDP port name or number and the second one you enter following the range parameter. The range includes the port names or numbers you enter. For example, to apply the policy to all ports between and including 23 (Telnet) and 53

(DNS), enter the following: range 23 53 . The first port number in the range must be lower than the last number in the range.

The <tcp/udp-port> parameter specifies the TCP or UDP port number or well-known name. You can specify a well-known name for any application port whose number is less than 1024. For other application ports, you must enter the number. Enter “?” instead of a port to list the well-known names recognized by the CLI.

The in parameter specifies that the ACL applies to incoming traffic on the interface to which you apply the ACL.

You can apply the ACL to an Ethernet port or a virtual interface.

12 - 16 © Foundry Networks, Inc.

December 2005

Rule-Based IP Access Control Lists (ACLs)

NOTE: If the ACL is for a virtual routing interface, you also can specify a subset of ports within the VLAN containing that interface when assigning an ACL to the interface. See “Configuring Standard Numbered ACLs” on page 12-4.

The precedence <name> | <num> parameter of the ip access-list command specifies the IP precedence. The precedence option for of an IP packet is set in a three-bit field following the four-bit header-length field of the packet’s header. You can specify one of the following:

• critical or 5 – The ACL matches packets that have the critical precedence. If you specify the option number instead of the name, specify number 5.

• flash or 3 – The ACL matches packets that have the flash precedence. If you specify the option number instead of the name, specify number 3.

• flash-override or 4 – The ACL matches packets that have the flash override precedence. If you specify the option number instead of the name, specify number 4.

• immediate or 2 – The ACL matches packets that have the immediate precedence. If you specify the option number instead of the name, specify number 2.

• internet or 6 – The ACL matches packets that have the internetwork control precedence. If you specify the option number instead of the name, specify number 6.

• network or 7 – The ACL matches packets that have the network control precedence. If you specify the option number instead of the name, specify number 7.

• priority or 1 – The ACL matches packets that have the priority precedence. If you specify the option number instead of the name, specify number 1.

• routine or 0 – The ACL matches packets that have the routine precedence. If you specify the option number instead of the name, specify number 0.

The tos <name> | <num> parameter of the ip access-list command specifies the IP ToS. You can specify one of the following:

• max-reliability or 2 – The ACL matches packets that have the maximum reliability ToS. The decimal value for this option is 2.

• max-throughput or 4 – The ACL matches packets that have the maximum throughput ToS. The decimal value for this option is 4.

• min-delay or 8 – The ACL matches packets that have the minimum delay ToS. The decimal value for this option is 8.

• min-monetary-cost or 1 – The ACL matches packets that have the minimum monetary cost ToS. The decimal value for this option is 1.

NOTE: This value is not supported on 10 Gigabit Ethernet modules.

• normal or 0 – The ACL matches packets that have the normal ToS. The decimal value for this option is 0.

• <num> – A number from 0 – 15 that is the sum of the numeric values of the options you want. The ToS field is a four-bit field following the Precedence field in the IP header. You can specify one or more of the following.

To select more than one option, enter the decimal value that is equivalent to the sum of the numeric values of all the ToS options you want to select. For example, to select the max-reliability and min-delay options, enter number 10. To select all options, select 15.

The dscp-cos-mapping option maps the DSCP value in incoming packets to a hardware table that provides mapping of each of the 0 – 63 DSCP values, and distributes them among eight traffic classes (internal priorities) and eight 802.1p priorities.

NOTE: The dscp-cos-mapping option overrides port-based priority settings.

December 2005 © Foundry Networks, Inc.

12 - 17

Foundry Configuration Guide for the FESX, FSX, and FWSX

The dscp-marking option enables you to configure an ACL that marks matching packets with a specified DSCP value Enter a value from 0 – 63. See “Using an IP ACL to Mark DSCP Values (DSCP Marking)” on page 12-23.

The dscp-matching option matches on the packet’s DSCP value. Enter a value from 0 – 63. This option does not change the packet’s forwarding priority through the device or mark the packet. See “DSCP Matching” on page 12-

24.

The log parameter enables SNMP traps and Syslog messages for packets denied by the ACL.

You can enable logging on ACLs and filters that support logging even when the ACLs and filters are already in use.

To do so, re-enter the ACL or filter command and add the log parameter to the end of the ACL or filter. The software replaces the ACL or filter command with the new one. The new ACL or filter, with logging enabled, takes effect immediately.

The traffic-policy option enables the device to rate limit inbound traffic and to count the packets and bytes per packet to which ACL permit or deny clauses are applied. For configuration procedures and examples, see the chapter “Traffic Policies” on page 15-1.

Configuration Example for Extended Named ACLs

To configure an extended named ACL, enter commands such as the following.

FastIron SuperX Router(config)# ip access-list extended “block Telnet”

FastIron SuperX Router(config-ext-nacl)# deny tcp host 209.157.22.26 any eq telnet log

FastIron SuperX Router(config-ext-nacl)# permit ip any any

FastIron SuperX Router(config-ext-nacl)# exit

FastIron SuperX Router(config)# int eth 1/1

FastIron SuperX Router(config-if-1/1)# ip access-group “block Telnet” in

The options at the ACL configuration level and the syntax for the ip access-group command are the same for numbered and named ACLs and are described in “Configuring Extended Numbered ACLs” on page 12-8 and

“Configuring Extended Named ACLs” on page 12-13.

Adding a Comment to an ACL Entry

You can optionally add comment text to describe entries in an ACL. The comment text appears in the output of show commands that display ACL information.

For example, the following commands add comments to entries to a numbered ACL, ACL 100:

FESX424 Router(config)# access-list 100 remark The following line permits TCP packets

FESX424 Router(config)# access-list 100 permit tcp 192.168.4.40/24 2.2.2.2/24

FESX424 Router(config)# access-list 100 remark The following permits UDP packets

FESX424 Router(config)# access-list 100 permit udp 192.168.2.52/24 2.2.2.2/24

FESX424 Router(config)# access-list 100 deny ip any any

12 - 18 © Foundry Networks, Inc.

December 2005

Rule-Based IP Access Control Lists (ACLs)

If the ACL is a named ACL, (for example, you entered TCP/UDP instead of 100), enter the following commands:

FESX424 Router(config)# access-list TCP/UDP remark The following line permits TCP packets

FESX424 Router(config)# access-list TCP/UDP permit tcp 192.168.4.40/24 2.2.2.2/24

FESX424 Router(config)# access-list TCP/UDP remark The following permits UDP packets

FESX424 Router(config)# access-list TCP/UDP permit udp 192.168.2.52/24 2.2.2.2/24

FESX424 Router(config)# access-list TCP/UDP deny ip any any

Syntax: [no] access-list <acl-num> | <acl-name> remark <comment-text>

Enter the number of the ACL for <acl-num>. You can add a comment to a named ACL by entering the ACL’s name for <acl-name>.

The <comment-text> can be up to 128 characters in length. The comment must be entered separately from the actual ACL entry; that is, you cannot enter the ACL entry and the ACL comment with the same access-list command. Also, in order for the remark to be displayed correctly in the output of show commands, the comment must be entered immediately before the ACL entry it describes.

You can use the show running-config or show access-list commands to display the ACL and comments

The following shows an example of a numbered ACL with a comment text in a show running-config display:

FESX424 Router# show running-config

… access-list 100 remark The following line permits TCP packets access-list 100 permit tcp 192.168.4.40/24 2.2.2.2/24 access-list 100 remark The following line permits UDP packets access-list 100 permit udp 192.168.2.52/24 2.2.2.2/24 access-list 100 deny ip any any

The following shows the comment text for the ACL named TCP/UDP in a show running-config display:

FESX424 Router# show running-config ...

access-list TCP/UDP remark The following line permits TCP packets access-list TCP/UDP permit tcp 192.168.4.40/24 2.2.2.2/24 access-list TCP/UDP remark The following line permits UDP packets access-list TCP/UDP permit udp 192.168.2.52/24 2.2.2.2/24 access-list TCP/UDP deny ip any any

Syntax: show running-config

The following example show the comment text for a numbered ACL in a show access-list display:

FESX424 Router# show access-list 100

IP access list rate-limit 100 aaaa.bbbb.cccc

Extended IP access list 100 (Total flows: N/A, Total packets: N/A)

ACL Comments: The following line permits TCP packets

permit tcp 0.0.0.40 255.255.255.0 0.0.0.2 255.255.255.0 (Flows: N/A, Packets: N/A)

ACL Comments: The following line permits UDP packets

permit udp 0.0.0.52 255.255.255.0 0.0.0.2 255.255.255.0 (Flows: N/A, Packets: N/A)

deny ip any any (Flows: N/A, Packets: N/A)

December 2005 © Foundry Networks, Inc.

12 - 19

Foundry Configuration Guide for the FESX, FSX, and FWSX

The next example shows the comment text for a named ACL in a show access-list display:

FESX424 Router# show access-list TCP/UDP

IP access list rate-limit 100 aaaa.bbbb.cccc

Extended IP access list TCP/UDP (Total flows: N/A, Total packets: N/A)

ACL Comments: The following line permits TCP packets permit tcp 0.0.0.40 255.255.255.0 0.0.0.2 255.255.255.0 (Flows: N/A, Packets: N/A)

ACL Comments: The following line permits UDP packets permit udp 0.0.0.52 255.255.255.0 0.0.0.2 255.255.255.0 (Flows: N/A, Packets: N/A) deny ip any any (Flows: N/A, Packets: N/A)

Syntax: show access-list <acl-num> | <acl-name> | all

Enabling Strict Control of ACL Filtering of Fragmented Packets

The default processing of fragments by hardware-based ACLs is as follows:

• The first fragment of a packet is permitted or denied using the ACLs. The first fragment is handled the same way as non-fragmented packets, since the first fragment contains the Layer 4 source and destination application port numbers. The device uses the Layer 4 CAM entry if one is programmed, or applies the interface's ACL entries to the packet and permits or denies the packet according to the first matching ACL.

• For other fragments of the same packet, they are subject to a rule only if there is no Layer 4 information in the rule or in any preceding rules.

The fragments are forwarded even if the first fragment, which contains the Layer 4 information, was denied.

Generally, denying the first fragment of a packet is sufficient, since a transaction cannot be completed without the entire packet.

For tighter control, you can configure the port to drop all packet fragments. To do so, enter commands such as the following:

FastIron SuperX Router(config)# interface ethernet 1/1

FastIron SuperX Router(config-if-1/1)# ip access-group frag deny

This option begins dropping all fragments received by the port as soon as you enter the command. This option is especially useful if the port is receiving an unusually high rate of fragments, which can indicate a hacker attack.

Syntax: [no] ip access-group frag deny

Enabling ACL Filtering Based on VLAN Membership or

VE Port Membership

Starting with release 02.3.03, you can apply an inbound ACL to specific VLAN members on a port (Layer 2 devices only) or to specific ports on a virtual interface (VE) (Layer 3 Devices only).

By default, this feature support is disabled. To enable it, enter the following commands at the Global CONFIG level of the CLI:

FESX424 Switch (config)# enable acl-per-port-per-vlan

FESX424 Switch (config)# write memory

FESX424 Switch (config)# exit

FESX424 Switch# reload

After entering the above commands, you can:

• Apply an ACL to specific VLAN members on a port – see Page 12-21

• Apply an ACL to a subset of ports on a VE – see Page 12-21

12 - 20 © Foundry Networks, Inc.

December 2005

Rule-Based IP Access Control Lists (ACLs)

NOTE: You must save the configuration and reload the software to place the change into effect.

Syntax: [no] enable acl-per-port-per-vlan

Enter the no form of the command to disable this feature.

Applying an ACL to Specific VLAN Members on a Port (Layer 2 Devices Only)

When you bind an ACL to a port, the port filters all inbound traffic on the port. However, on a tagged port, there may be a need to treat packets for one VLAN differently from packets for another VLAN. Starting with release

02.3.03, you can configure a tagged port on a Layer 2 device to filter packets based on the packets’ VLAN membership.

NOTE: Before you can bind an ACL to specific VLAN members on a port, you must first enable support for this feature. If this feature is not already enabled on your device, enable it as instructed in the section “Enabling ACL

Filtering Based on VLAN Membership or VE Port Membership” on page 12-20.

To apply an ACL to a specific VLAN on a port, enter commands such as the following on a tagged port:

FESX424 Switch(config)# vlan 12 name vlan12

FESX424 Switch(config-vlan-12)# untag ethernet 5 to 8

FESX424 Switch(config-vlan-12)# tag ethernet 23 to 24

FESX424 Switch(config-vlan-12)#exit

FESX424 Switch(config)# access-list 10 deny host 209.157.22.26 log

FESX424 Switch(config)# access-list 10 deny 209.157.29.12 log

FESX424 Switch(config)# access-list 10 deny host IPHost1 log

FESX424 Switch(config)# access-list 10 permit

FESX424 Switch(config)# int e 23

FESX424 Switch(config-if-e1000-23))# per-vlan 12

FESX424 Switch(config-if-e1000-23-vlan-12))#ip access-group 10 in

The commands in this example configure port-based VLAN 12, and add ports e 5 – 8 as untagged ports and ports e 23 – 24 as tagged ports to the VLAN. The commands following the VLAN configuration commands configure

ACL 10. Finally, the last three commands apply ACL 10 on VLAN 12 for which port e 23 is a member.

Syntax: per-vlan <VLAN ID>

Syntax: [no] ip access-group <ACL ID>

The <VLAN ID> parameter specifies the VLAN name or number to which you will bind the ACL.

The <ACL ID> parameter is the access list name or number.

Applying an ACL to a Subset of Ports on a Virtual Interface (Layer 3 Devices

Only)

You can apply an ACL to a virtual routing interface. The virtual interface is used for routing between VLANs and contains all the ports within the VLAN. The ACL applies to all the ports on the virtual routing interface. Starting with release 02.3.03, you also can specify a subset of ports within the VLAN containing a specified virtual interface when assigning an ACL to that virtual interface.

Use this feature when you do not want the ACLs to apply to all the ports in the virtual interface’s VLAN or when you want to streamline ACL performance for the VLAN.

NOTE: Before you can bind an ACL to specific ports on a virtual interface, you must first enable support for this feature. If this feature is not already enabled on your device, enable it as instructed in the section “Enabling ACL

Filtering Based on VLAN Membership or VE Port Membership” on page 12-20.

To apply an ACL to a subset of ports within a virtual interface, enter commands such as the following:

FastIron SuperX Router(config)# vlan 10 name IP-subnet-vlan

FastIron SuperX Router(config-vlan-10)# untag ethernet 1/1 to 2/12

December 2005 © Foundry Networks, Inc.

12 - 21

Foundry Configuration Guide for the FESX, FSX, and FWSX

FastIron SuperX Router(config-vlan-10)# router-interface ve 1

FastIron SuperX Router(config-vlan-10)# exit

FastIron SuperX Router(config)# access-list 1 deny host 209.157.22.26 log

FastIron SuperX Router(config)# access-list 1 deny 209.157.29.12 log

FastIron SuperX Router(config)# access-list 1 deny host IPHost1 log

FastIron SuperX Router(config)# access-list 1 permit any

FastIron SuperX Router(config)# interface ve 1

FastIron SuperX Router(config-vif-1)# ip access-group 1 in ethernet 1/1 ethernet 1/

3 ethernet 2/1 to 2/4

The commands in this example configure port-based VLAN 10, add ports 1/1 – 2/12 to the VLAN, and add virtual routing interface 1 to the VLAN. The commands following the VLAN configuration commands configure ACL 1.

Finally, the last two commands apply ACL 1 to a subset of the ports associated with virtual interface 1.

Syntax: [no] ip access-group <ACL ID> in ethernet <slotnum>/<portnum> [to <slotnum>/<portnum>]

The <ACL ID> parameter is the access list name or number.

The <slotnum> parameter applies on chassis devices only. It does not apply on FESX devices.

Filtering on IP Precedence and ToS Values

To configure an extended IP ACL that matches based on IP precedence, enter commands such as the following:

FESX424 Router(config)# access-list 103 deny tcp 209.157.21.0/24 209.157.22.0/24 precedence internet

FESX424 Router(config)# access-list 103 deny tcp 209.157.21.0/24 eq ftp

209.157.22.0/24 precedence 6

FESX424 Router(config)# access-list 103 permit ip any any

The first entry in this ACL denies TCP traffic from the 209.157.21.

x network to the 209.157.22.x network, if the traffic has the IP precedence option “internet” (equivalent to “6”).

The second entry denies all FTP traffic from the 209.157.21.

x network to the 209.157.22.x network, if the traffic has the IP precedence value “6” (equivalent to “internet”).

The third entry permits all packets that are not explicitly denied by the other entries. Without this entry, the ACL would deny all incoming or outgoing IP traffic on the ports to which you assign the ACL.

To configure an IP ACL that matches based on ToS, enter commands such as the following:

FESX424 Router(config)# access-list 104 deny tcp 209.157.21.0/24 209.157.22.0/24 tos normal

FESX424 Router(config)# access-list 104 deny tcp 209.157.21.0/24 eq ftp 209.157.22.0/24 tos 13

FESX424 Router(config)# access-list 104 permit ip any any

The first entry in this IP ACL denies TCP traffic from the 209.157.21.

x network to the 209.157.22.x network, if the traffic has the IP ToS option “normal” (equivalent to “0”).

The second entry denies all FTP traffic from the 209.157.21.

x network to the 209.157.22.x network, if the traffic has the IP precedence value “13” (equivalent to “max-throughput”, “min-delay”, and “min-monetary-cost”).

The third entry permits all packets that are not explicitly denied by the other entries. Without this entry, the ACL would deny all incoming or outgoing IP traffic on the ports to which you assign the ACL.

12 - 22 © Foundry Networks, Inc.

December 2005

Rule-Based IP Access Control Lists (ACLs)

QoS Options for IP ACLs

Quality of Service (QoS) options enable you to perform QoS for packets that match the ACLs. Using an ACL to perform QoS is an alternative to directly setting the internal forwarding priority based on incoming port, VLAN membership, and so on. (This method is described in “Assigning QoS Priorities to Traffic” on page 13-7.)

The following QoS ACL options are supported:

• dscp-cos-mapping – This option is similar to the dscp-matching command (described below). This option maps the DSCP value in incoming packets to a hardware table that provides mapping of each of the 0 – 63

DSCP values, and distributes them among eight traffic classes (internal priorities) and eight 802.1p priorities.

By default, the Foundry device does the 802.1p to CoS mapping. If you want to change the priority mapping to DSCP to CoS mapping, you must enter the following ACL statement: permit ip any any dscp-cos-mapping

• dscp-marking – Marks the DSCP value in the outgoing packet with the value you specify.

• internal-priority-marking and 802.1p-priority-marking – Supported with the DSCP marking option, these commands assign traffic that matches the ACL to a hardware forwarding queue ( internal-prioritymarking ), and re-mark the packets that match the ACL with the 802.1p priority ( 802.1p-prioritymarking ).

• dscp-matching – Matches on the packet’s DSCP value. This option does not change the packet’s forwarding priority through the device or mark the packet.

Using an ACL to Map the DSCP Value (DSCP CoS Mapping)

The dscp-cos-mapping option on the FESX and FSX maps the DSCP value in incoming packets to a hardware table that provides mapping of each of the 0 – 63 DSCP values, and distributes them among eight traffic classes

(internal priorities) and eight 802.1p priorities.

NOTE: The dscp-cos-mapping option overrides port-based priority settings.

By default, the Foundry device does the 802.1p to CoS mapping. If you want to change the priority mapping to

DSCP to CoS mapping, you must enter the following ACL statement: permit ip any any dscp-cos-mapping

The complete CLI syntax for this feature is shown in “Configuring Extended Numbered ACLs” on page 12-8 and

“Configuring Extended Named ACLs” on page 12-13. The following shows the syntax specific to the DSCP Cos mapping feature.

Syntax: ... [dscp-marking <dscp-value> dscp-cos-mapping ]

OR

Syntax: ...[dscp-cos-mapping]

Using an IP ACL to Mark DSCP Values (DSCP Marking)

The dscp-marking option for extended ACLs allows you to configure an ACL that marks matching packets with a specified DSCP value. You also can use DSCP marking to assign traffic to a specific hardware forwarding queue

(see “Using an ACL to Change the Forwarding Queue” on page 12-24).

For example, the following commands configure an ACL that marks all IP packets with DSCP value 5. The ACL is then applied to incoming packets on interface 7. Consequently, all inbound packets on interface 7 are marked with the specified DSCP value.

FESX424 Router(config)# access-list 120 permit ip any any dscp-marking 5

FESX424 Router(config)# interface 7

FESX424 Router(config-if-e1000-7)# ip access-group 120 in

Syntax: ...

dscp-marking <dscp-value> 802.1p-priority-marking <0 – 7>

December 2005 © Foundry Networks, Inc.

12 - 23

Foundry Configuration Guide for the FESX, FSX, and FWSX

The dscp-marking <dscp-value> parameter maps a DSCP value to an internal forwarding priority. The DSCP value can be from 0 – 63.

Using an ACL to Change the Forwarding Queue

The 802.1p-priority-marking <0 – 7> parameter re-marks the packets of the 802.1Q traffic that match the ACL with this new 802.1p priority, or marks the packets of the non-802.1Q traffic that match the ACL with this 802.1p priority, later at the outgoing 802.1Q interface.

The 802.1p priority mapping is shown in Table 12.2.

The internal-priority-marking <0 – 7> parameter assigns traffic that matches the ACL to a specific hardware forwarding queue (qosp0 – qosp7>.

NOTE: The internal-priority-marking parameter overrides port-based priority settings.

In addition to changing the internal forwarding priority, if the outgoing interface is an 802.1Q interface, this parameter maps the specified priority to its equivalent 802.1p (CoS) priority and marks the packet with the new

802.1p priority. Table 12.2 lists the default mappings of hardware forwarding queues to 802.1p priorities on the

FESX and FSX.

Forwarding

Queue

802.1p

Table 12.2: Default Mapping of Forwarding Queues to 802.1p Priorities qosp0 qosp1 qosp2 qosp3 qosp4 qosp5 qosp6

0 1 2 3 4 5 6 qosp7

7

The complete CLI syntax for 802.1p priority marking and internal priority marking is shown in “Configuring

Extended Numbered ACLs” on page 12-8 and “Configuring Extended Named ACLs” on page 12-13. The following shows the syntax specific to these features.

Syntax: ... dscp-marking <0 – 63> 802.1p-priority-marking <0 – 7> internal-priority-marking <0 – 7>]

DSCP Matching

The dscp-matching option matches on the packet’s DSCP value. This option does not change the packet’s forwarding priority through the device or mark the packet.

To configure an ACL that matches on a packet with DSCP value 29, enter a command such as the following:

FESX424 Router(config)# access-list 112 permit ip 1.1.1.0 0.0.0.255 2.2.2.x

0.0.0.255 dscp-mapping 29

The complete CLI syntax for this feature is shown in “Configuring Extended Numbered ACLs” on page 12-8 and

“Configuring Extended Named ACLs” on page 12-13. The following shows the syntax specific to this feature.

Syntax: ...

dscp-matching <0 – 63>

NOTE: For complete syntax information, see “Extended Numbered ACL Syntax” on page 12-8.

ACL-Based Rate Limiting

Software releases 02.3.03 and later provide support for IP ACL-based rate limiting of inbound traffic. ACL-based rate limiting provides the facility to limit the rate for IP traffic that matches the permit conditions in extended IP

ACLs. This feature is available in the Layer 2 and Layer 3 code.

For more details, including configuration procedures, see the chapter “Traffic Policies” on page 15-1.

12 - 24 © Foundry Networks, Inc.

December 2005

Rule-Based IP Access Control Lists (ACLs)

ACL Counting

Software releases 02.3.03 and later support ACL counting , a mechanism for counting the number of packets and the number of bytes per packet to which ACL filters are applied.

Configuration procedures for ACL counting are in the chapter “Traffic Policies” on page 15-1.

Using ACLs to Control Multicast Features

You can use ACLs to control the following multicast features:

• Limit the number of multicast groups that are covered by a static rendezvous point (RP)

• Control which multicast groups for which candidate RPs sends advertisement messages to bootstrap routers

• Identify which multicast group packets will be forwarded or blocked on an interface

For configuration procedures, see the chapter “Configuring IP Multicast Protocols” on page 19-1

Displaying ACL Information

To display the number of Layer 4 CAM entries used by each ACL, enter the following command:

FESX424 Router(config)# show access-list all

Extended IP access list 100 (Total flows: N/A, Total packets: N/A, Total rule cam use: 3) permit udp host 192.168.2.169 any (Flows: N/A, Packets: N/A, Rule cam use: 1) permit icmp any any (Flows: N/A, Packets: N/A, Rule cam use: 1) deny ip any any (Flows: N/A, Packets: N/A, Rule cam use: 1)

Syntax: show access-list <acl-num> | <acl-name> | all

The Rule cam use field lists the number of CAM entries used by the ACL or entry. The number of CAM entries listed for the ACL itself is the total of the CAM entries used by the ACL’s entries.

For flow-based ACLs, the Total flows and Flows fields list the number of Layer 4 session table flows in use for the

ACL.

The Total packets and Packets fields apply only to flow-based ACLs.

Troubleshooting ACLs

Use the following methods to troubleshoot ACLs:

• To display the number of Layer 4 CAM entries being used by each ACL, enter the show access-list

<acl-num> | <acl-name> | all command. See “Displaying ACL Information” on page 12-25.

• To determine whether the issue is specific to fragmentation, remove the Layer 4 information (TCP or UDP application ports) from the ACL, then reapply the ACL.

If you are using another feature that requires ACLs, either use the same ACL entries for filtering and for the other feature, or change to flow-based ACLs.

December 2005 © Foundry Networks, Inc.

12 - 25

Foundry Configuration Guide for the FESX, FSX, and FWSX

12 - 26 © Foundry Networks, Inc.

December 2005

Chapter 13

Configuring Quality of Service

Quality of Service (QoS) features are used to prioritize the use of bandwidth in a switch. When QoS features are enabled, traffic is classified as it arrives at the switch, and processed through on the basis of configured priorities.

Traffic can be dropped, prioritized for guaranteed delivery, or subject to limited delivery options as configured by a number of different mechanisms.

This chapter describes how QoS is implemented and configured in the FESX, FSX, and FWSX devices. This chapter contains the topics listed in Table 13.1.

Table 13.1: Chapter Contents

Description

Classification – This section describes how the packets are classified and mapped into the forwarding queues by default.

See Page

13-1

QoS Queues – This section describes how to assign QoS priorities to traffic.

13-6

Marking – This process allows you to change the 802.1p and DSCP information In a packet.

Configuring DSCP-based QoS – This section describes how to specify a trust level and enable marking.

13-8

13-15

13-8 Configuring QoS Mappings – This section describes how to change the default priority mappings.

Scheduling – This process allows you to service the queues according to a mechanism

13-11

Viewing QoS Information

Viewing DSCP-based QoS Information

13-15

13-16

Classification

Classification is the process of selecting packets on which to perform QoS, reading the QoS information and assigning a priority to the packets. The classification process assigns a priority to packets as they enter the switch. These priorities can be determined on the basis of information contained within the packet or assigned to

December 22, 2005 © Foundry Networks, Inc.

13 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX the packet as it arrives at the switch.

Once a packet or traffic flow is classified, it is mapped to a forwarding priority queue.

Packets on the FESX, FSX, and FWSX are classified in up to eight traffic classes with values between 0 and 7.

Packets with higher priority classifications are given a precedence for forwarding.

Processing of Classified Traffic

The trust level in effect on an interface determines the type of QoS information the device uses for performing

QoS. The Foundry device establishes the trust level based on the configuration of various features and if the traffic is switched or routed. The trust level can be one of the following:

• Ingress port default priority

• Static MAC address

• Layer 2 Class of Service (CoS) value – This is the 802.1p priority value in the Ethernet frame. It can be a value from 0 – 7. The 802.1p priority is also called the Class of Service.

• Layer 3 Differentiated Service codepoint (DSCP) – This is the value in the six most significant bits of the IP packet header’s 8-bit DSCP field. It can be a value from 0 – 63. These values are described in RFCs 2472 and 2475. The DSCP value is sometimes called the DiffServ value. The device automatically maps a packet's DSCP value to a hardware forwarding queue. See “Viewing QoS Settings” on page 13-15".

• ACL keyword – An ACL can also prioritize traffic and mark it before sending it along to the next hop. This is described in the ACL chapter in the section “QoS Options for IP ACLs” on page 12-23.

Given the variety of different criteria, there are multiple possibilities for traffic classification within a stream of network traffic. For this reason, the priority of packets must be resolved based on which criteria takes precedence.

Precedence follows the scheme illustrated in Figure 13.1

Determining a Packet’s Trust Level

Figure 13.1 illustrates how the Foundry device determines a packet’s trust level.

13 - 2 © Foundry Networks, Inc.

December 22, 2005

Figure 13.1

Determining a Packet’s Trust Level

Packet received on ingress port

Does the packet match an

ACL that defines a priority?

Yes Trust the DSCP-

CoS-mapping or the DSCP-marking

No

Is the packet tagged?

Yes

Trust the 802.1p

CoS value

No

Does the

MAC address match a static entry?

No

Yes Trust the priority of the static

MAC entry

Does the port have a default priority?

No

Use the default priority of 0

Yes

Trust the port’s default priority

Configuring Quality of Service

December 2005 © Foundry Networks, Inc.

13 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

As shown in the figure, the first criteria considered is whether the packet matches on an ACL that defines a priority.

If this is not the case and the packet is tagged, the packet is classified with the 802.1p CoS value. If neither of these are true, the packet is next classified based on the static MAC address, ingress port default priority, or the default priority of zero (0).

Once a packet is classified by one of the procedures mentioned, it is mapped to an internal forwarding queue.

There are eight queues designated as 0 to 7. The internal forwarding priority maps to one of these eight queues as shown in Table 13.2 through Table 13.5. The mapping between the internal priority and the forwarding queue cannot be changed.

Table 13.2 through Table 13.5 show the default QoS mappings which are used if the trust level for CoS or DSCP is enabled.

13 - 4 © Foundry Networks, Inc.

December 22, 2005

Configuring Quality of Service

DSCP value

802.1p

(COS) Value

DSCP value

0

0

0

0 Internal

Forwarding

Priority

Forwarding

Queue

0

1

0

0

1

0

Table 13.2: Default QoS Mappings, Columns 0 to 15

2

0

3

0

4

0

5

0

6

0

7

0

8

1

9

1

10

1

11

1

12

1

12

1

14

1

15

1

2

0

0

3

0

0

4

0

0

5

0

0

6

0

0

7

0

0

8

1

1

9

1

1

10

1

1

11

1

1

12

1

1

12

1

1

14

1

1

15

1

1

DSCP value

Table 13.3: Default QoS Mappings, Columns 16 to 31

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 802.1p

(COS) Value

DSCP value

Internal

Forwarding

Priority

Forwarding

Queue

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3

2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3

Table 13.4: Default QoS Mappings, Columns 32 to 47

DSCP value

802.1p

(COS) Value

DSCP value

Internal

Forwarding

Priority

Forwarding

Queue

32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5

32

4

4

33

4

4

34

4

4

35

4

4

36

4

4

37

4

4

38

4

4

39

4

4

40

5

5

41

5

5

42

5

5

43

5

5

44

5

5

45

5

5

46

5

5

47

5

5

December 2005 © Foundry Networks, Inc.

13 - 5

Foundry Configuration Guide for the FESX, FSX, and FWSX

Table 13.5: Default QoS Mappings, Columns 48 to 63

DSCP value

802.1p

(COS) Value

DSCP value

Internal

Forwarding

Priority

Forwarding

Queue

48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63

6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7

48

6

6

49

6

6

50

6

6

51

6

6

52

6

6

53

6

6

54

6

6

55

6

6

56

7

7

57

7

7

58

7

7

59

7

7

60

7

7

61

7

7

62

7

7

63

7

7

Mapping between DSCP value and Forwarding Queue cannot be changed. However, mapping between DSCP values and the other properties can be changed as follows:

• DSCP to Internal Forwarding Priority Mapping – You can change the mapping between the DSCP value and the Internal Forwarding priority value from the default values shown in Table 13.2 through Table 13.5.

This mapping is used for COS marking and determining the internal priority when the trust level is DSCP. See

“Changing the DSCP –> Internal Forwarding Priority Mappings” on page 13-10.

• Internal Forwarding Priority to Forwarding Queue – You can reassign an internal forwarding priority to a different hardware forwarding queue. See “Changing the Internal Forwarding Priority –> Hardware

Forwarding Queue Mappings” on page 13-10.

QoS Queues

Foundry devices support the eight QoS queues (qosp0 – qosp7) listed in Table 13.6.

1

2

3

4

5

6

7

Table 13.6: QoS Queues

QoS Priority Level

0

QoS Queue qosp0 (lowest priority queue) qosp1 qosp2 qosp3 qosp4 qosp5 qosp6 qosp7 (highest priority queue)

The queue names listed above are the default names. If desired, you can rename the queues as instructed in

“Renaming the Queues” on page 13-12.

Packets are classified and assigned to specific queues based on the criteria shown in Figure 13.1.

13 - 6 © Foundry Networks, Inc.

December 22, 2005

Configuring Quality of Service

Assigning QoS Priorities to Traffic

By default, all traffic is in the best-effort queue (qosp0) and is honored on tagged ports on all FastIron family of switches. You can assign traffic to a higher queue based on the following:

• Incoming port (sometimes called the ingress port)

• Static MAC entry

The following sections describe how to change the priority for each of the items listed above.

Although it is possible for a packet to qualify for an adjusted QoS priority based on more than one of the criteria listed In the section above, the system always gives a packet the highest priority for which it qualifies. Thus, if a packet is entitled to the premium queue because of its IP source and destination addresses, but is entitled only to the high queue because of its incoming port, the system places the packet in the premium queue on the outgoing port.

When you apply a QoS priority to one of the items listed above, you specify a number from 0 – 7. The priority number specifies the IEEE 802.1 equivalent to one of the eight QoS queues on FESX, FSX, and FWSX devices.

The numbers correspond to the queues as shown in Table 13.2.

Changing a Port’s Priority

To change the QoS priority of port 1 to the premium queue (qosp7), enter the following commands:

FESX424 Router(config)# interface ethernet 1

FESX424 Router(config-if-e1000-1)# priority 7

The device will assign priority 7 to untagged switched traffic received on port 1.

Syntax: [no] priority <num>

The <num> parameter can be from 0 – 7 and specifies the IEEE 802.1 equivalent to one of eight QoS queues listed in Table 13.2.

Assigning Static MAC Entries to Priority Queues

By default, all MAC entries are in the best effort queue. When you configure a static MAC entry, you can assign the entry to a higher QoS level.

To configure a static MAC entry and assign the entry to the premium queue, enter commands such as the following:

FESX424 Router(config)# vlan 9

FESX424 Router(config-vlan-9)# static-mac-address 1145.1163.67FF ethernet 1/1 priority 7

FESX424 Router(config-vlan-9)# write memory

Syntax: [no] static-mac-address <mac-addr> ethernet [<slotnum>/]<portnum> [priority <num>]

[host-type | router-type | fixed-host]

The <slotnum>/ parameter applies to the FSX only.

The priority <num> parameter can be from 0 – 7 and specifies the IEEE 802.1 equivalent to one of the eight QoS queues.

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.

December 2005 © Foundry Networks, Inc.

13 - 7

Foundry Configuration Guide for the FESX, FSX, and FWSX

Marking

Marking is the process of changing the packet’s QoS information (the 802.1p and DSCP information in a packet) for the next hop. For example, for traffic coming from a device that does not support DiffServ, you can change the packet’s IP Precedence value into a DSCP value before forwarding the packet.

You can mark a packet’s Layer 2 CoS value, its Layer 3 DSCP value, or both values. The Layer 2 CoS or DSCP value the device marks in the packet is the same value that results from mapping the packet’s QoS value into a

Layer 2 CoS or DSCP value.

Marking is optional and is disabled by default. Marking is performed using ACLs. When marking is not used, the device still performs the mappings listed in “Classification” for scheduling the packet, but leaves the packet’s QoS values unchanged when the device forwards the packet.

For configuration syntax, rules, and examples of QoS marking, see “QoS Options for IP ACLs” on page 12-23.

Configuring DSCP-Based QoS

FastIron IronWare releases support basic DSCP-based QoS (also called Type of Service (ToS) based QoS) as described in this chapter. However, the FastIron family of switches do not support other advanced DSCP-based

QoS features as described in the Foundry Enterprise Configuration and Management Guide .

Foundry FastIron IronWare releases also support marking of the DSCP value. FastIron devices can read Layer 3

Quality of Service (QoS) information in an IP packet and select a forwarding queue for the packet based on the information. The software interprets the value in the six most significant bits of the IP packet header’s 8-bit ToS field as a Diffserv Control Point (DSCP) value, and maps that value to an internal forwarding priority.

The internal forwarding priorities are mapped to one of the eight forwarding queues (qosp0 – qosp7) on FESX,

FSX, and FWSX devices. During a forwarding cycle, the device gives more preference to the higher numbered queues, so that more packets are forwarded from these queues. So for example, queue qosp7 receives the highest preference while queue qosp0, the best-effort queue, receives the lowest preference.

Application Notes

• DSCP-based QoS is not automatically honored for routed and switched traffic. The default is 802.1p to CoS mapping. To honor DSCP-based QoS, you must change the priority mapping to DSCP to CoS mapping. See

“Using ACLs to Honor DSCP-based QoS” .

When DSCP marking is enabled on the FESX, FWSX, or FSX, the device changes the contents of the inbound packet’s ToS field to match the DSCP-based QoS value. This is different than on the BigIron, which marks the outbound packet’s ToS field.

Using ACLs to Honor DSCP-based QoS

FESX, FSX, and FWSX devices require the use of an ACL to honor DSCP-based QoS for routed traffic in the

Layer 3 image, or for switched traffic in the Layer 2 image. To enable DSCP-based QoS on these devices, apply an ACL entry such as the following:

FESX424 Router(config)# access-list 101 permit ip any any dscp-cos-map

Configuring the QoS Mappings

You can optionally change the following QoS mappings:

• DSCP –> internal forwarding priority

• Internal forwarding priority –> hardware forwarding queue

The mappings are globally configurable and apply to all interfaces.

13 - 8 © Foundry Networks, Inc.

December 22, 2005

Configuring Quality of Service

Default DSCP –> Internal Forwarding Priority Mappings

The DSCP values are described in RFCs 2474 and 2475. Table 13.7 list the default mappings of DSCP values to internal forwarding priority values.

Table 13.7: Default DSCP to Internal Forwarding Priority Mappings

4

5

2

3

Internal Forwarding

Priority

0 (lowest priority queue)

1

6

7 (highest priority queue)

DSCP Value

0 – 7

8 – 15

16 – 23

24 – 31

32 – 39

40 – 47

48 – 55

56 – 63

Notice that DSCP values range from 0 – 63, whereas the internal forwarding priority values range from 0 – 7. Any

DSCP value within a given range is mapped to the same internal forwarding priority value. For example, any

DSCP value from 8 – 15 maps to priority 1.

After performing this mapping, the device maps the internal forwarding priority value to one of the hardware forwarding queues.

Table 13.8 list the default mappings of internal forwarding priority values to the hardware forwarding queues.

Table 13.8: Default Mappings of Internal Forwarding Priority Values

Forwarding Queues

3

4

1

2

Internal Forwarding

Priority

0 (lowest priority queue)

5

6

7 (highest priority queue) qosp0 qosp1 qosp2 qosp3 qosp4 qosp5 qosp6 qosp7

December 2005 © Foundry Networks, Inc.

13 - 9

Foundry Configuration Guide for the FESX, FSX, and FWSX

You can change the DSCP -> internal forwarding mappings. You also can change the internal forwarding priority

-> hardware forwarding queue mappings.

Changing the DSCP –> Internal Forwarding Priority Mappings

To change the DSCP –> internal forwarding priority mappings for all the DSCP ranges, enter commands such as the following at the global CONFIG level of the CLI:

FESX424 Router(config)# qos-tos map dscp-priority 0 2 3 4 to 1

FESX424 Router(config)# qos-tos map dscp-priority 8 to 5

FESX424 Router(config)# qos-tos map dscp-priority 16 to 4

FESX424 Router(config)# qos-tos map dscp-priority 24 to 2

FESX424 Router(config)# qos-tos map dscp-priority 32 to 0

FESX424 Router(config)# qos-tos map dscp-priority 40 to 7

FESX424 Router(config)# qos-tos map dscp-priority 48 to 3

FESX424 Router(config)# qos-tos map dscp-priority 56 to 6

FESX424 Router(config)# ip rebind-acl all

These commands configure the mappings displayed in the DSCP to forwarding priority portion of the QoS information display. To read this part of the display, select the first part of the DSCP value from the d1 column and select the second part of the DSCP value from the d2 row. For example, to read the DSCP to forwarding priority mapping for DSCP value 24, select 2 from the d1 column and select 4 from the d2 row. The mappings that are changed by the command above are shown below in bold type.

FESX424 Router(config-if-e1000-1)# show qos-tos

...portions of table omitted for simplicity...

DSCP-Priority map: (dscp = d1d2) d2| 0 1 2 3 4 5 6 7 8 9

d1 |

-----+----------------------------------------

0 | 1 0 1 1 1 0 0 0 5 1

1 | 6 1 1 1 1 1 4 2 2 2

2 | 2 2 2 2 2 3 3 3 3 3

3 | 3 3 0 4 4 4 4 4 4 4

4 | 7 5 5 5 5 5 5 5 3 6

5 | 6 6 6 6 6 6 6 7 7 7

6 | 7 7 7 7

Syntax: [no] qos-tos map dscp-priority <dscp-value> [<dscp-value> ...] to <priority>

The <dscp-value> [<dscp-value> ...] parameter specifies the DSCP value ranges you are remapping. You can specify up to seven DSCP values in the same command, to map to the same forwarding priority. The first command in the example above maps priority 1 to DSCP values 0, 2, 3, and 4.

The <priority> parameter specifies the internal forwarding priority.

Changing the Internal Forwarding Priority –> Hardware Forwarding Queue Mappings

To reassign an internal forwarding priority to a different hardware forwarding queue, enter commands such as the following at the global CONFIG level of the CLI:

FESX424 Router(config)# qos tagged-priority 2 qosp0

Syntax: [no] qos tagged-priority <num> <queue>

The <num> parameter can be from 0 – 7 and specifies the internal forwarding priority.

13 - 10 © Foundry Networks, Inc.

December 22, 2005

Configuring Quality of Service

The <queue> parameter specifies the hardware forwarding queue to which you are reassigning the priority. The default queue names are as follows:

• qosp7

• qosp6

• qosp5

• qosp4

• qosp3

• qosp2

• qosp1

• qosp0

Scheduling

Scheduling is the process of mapping a packet to an internal forwarding queue based on its QoS information, and servicing the queues according to a mechanism.

This section describes the scheduling methods used on the FESX, FSX, and FWSX.

QoS Queuing Methods

The following QoS queuing methods are supported in all IronWare software releases for the FastIron FESX and

FSX.

• Weighted Round Robin (WRR) – WRR ensures that all queues are serviced during each cycle. A weighted fair queuing algorithm is used to rotate service among the eight queues on FESX, FSX, and FWSX devices.

The rotation is based on the weights you assign to each queue. This method rotates service among the queues, forwarding a specific number of packets in one queue before moving on to the next one.

WRR is the default queuing method and uses a default set of queue weights.

The number of packets serviced during each visit to a queue depends on the percentages you configure for the queues. The software automatically converts the percentages you specify into weights for the queues.

NOTE: Queue cycles on the FESX, FSX, and FWSX are based on bytes. These devices service a given number of bytes (based on the weight) in each queue cycle. FES and BI/FI queue cycles are based on packets.

The bytes-based scheme is more accurate compared to a packets-based scheme if packets vary greatly in size.

• Strict Priority(SP) – SP ensures service for high priority traffic. The software assigns the maximum weights to each queue, to cause the queuing mechanism to serve as many packets in one queue as possible before moving to a lower queue. This method biases the queuing mechanism to favor the higher queues over the lower queues.

For example, strict queuing processes as many packets as possible in qosp3 before processing any packets in qosp2, then processes as many packets as possible in qosp2 before processing any packets in qosp1, and so on.

Starting with software release 02.2.00, an additional configurable queueing mechanism combines both the strict priority and weighted round robin mechanisms. The combined method enables the Foundry device to give strict priority to delay-sensitive traffic such as VOIP traffic, and weighted round robin priority to other traffic types.

By default, when you select the combined SP and WRR queueing method, the Foundry device assigns strict priority to traffic in qosp7 and qosp6, and weighted round robin priority to traffic in qosp0 through qosp5. Thus, the

December 2005 © Foundry Networks, Inc.

13 - 11

Foundry Configuration Guide for the FESX, FSX, and FWSX

Foundry device schedules traffic in queue 7 and queue 6 first, based on the strict priority queueing method. When there is no traffic in queue 7 and queue 6, the device schedules the other queues in round-robin fashion from the highest priority queue to the lowest priority queue.

By default, when you specify the combined SP and WRR queuing method, the system balances the traffic among the queues as shown in Table 2. If desired, you can change the default bandwidth values as instructed in the section “Changing the Bandwidth Allocations” on page 13-14.

Table 2: Default Bandwidth for Combined SP and WRR Queueing Methods

Queue qosp7 qosp6 qosp5 qosp4 qosp3 qosp2 qosp1 qosp0

Default Bandwidth

Strict priority (highest priority)

Strict priority

25%

15%

15%

15%

15%

15% (lowest priority)

Selecting the QoS Queuing Method

FastIron devices use the weighted fair queuing method of packet prioritization by default. To change the method to strict priority or back to weighted fair queuing, enter the following command at the Global CONFIG level of the CLI:

FESX424 Router(config)# qos mechanism strict

To change the method back to weighted round robin, enter the following command:

FESX424 Router(config)# qos mechanism weighted

Syntax: [no] qos mechanism strict | weighted

NOTE: The following combined method is supported in releases 02.2.00 and later.

To change the queuing mechanism to the combined SP and WRR method, enter the following command at the

Global CONFIG level of the CLI:

FESX424 Switch(config)#qos mechanism mixed-sp-wrr

Syntax: mechanism mixed-sp-wrr

Configuring the QoS Queues

Each of the queues has the following configurable parameters:

• The queue name

• The minimum percentage of a port’s outbound bandwidth guaranteed to the queue

Renaming the Queues

The default queue names on FESX, FSX, and FWSX devices are qosp7, qosp6, qosp5, qosp4, qosp3, qosp2, qosp1, and qosp0. You can change one or more of the names if desired.

To rename queue qosp3 to “92-octane”, enter the following commands:

FESX424 Router(config)# qos name qosp3 92-octane

13 - 12 © Foundry Networks, Inc.

December 22, 2005

Configuring Quality of Service

Syntax: qos name <old-name> <new-name>

The <old-name> parameter specifies the name of the queue before the change.

The <new-name> parameter specifies the new name of the queue. You can specify an alphanumeric string up to

32 characters long.

Changing the Minimum Bandwidth Percentages of the Queues

If you are using the weighted round robin mechanism instead of the strict mechanism, you can change the weights for each queue by changing the minimum percentage of bandwidth you want each queue to guarantee for its traffic.

By default, the eight QoS queues on FESX , FSX, and FWSX devices receive the following minimum guaranteed percentages of a port’s total bandwidth

Table 13.9: Default Minimum Bandwidth Percentages on FESX, FSX, and FWSX Devices

Queue qosp7 qosp6 qosp5 qosp4 qosp3 qosp2 qosp1 qosp0

Default Minimum Percentage of

Bandwidth

3%

3%

3%

3%

3%

75%

7%

3%

When the queuing method is weighted round robin, the software internally translates the percentages into weights. The weight associated with each queue controls how many packets are processed for the queue at a given stage of a cycle through the weighted round robin algorithm.

NOTE: Queue cycles on the FESX, FSX, and FWSX are based on bytes. These devices service a given number of bytes (based on the weight) in each queue cycle. FES and BI/FI queue cycles are based on packets.

The bytes-based scheme is more accurate compared to a packets-based scheme if packets vary greatly in size.

The bandwidth allocated to each queue is based on the relative weights of the queues. You can change the bandwidth percentages allocated to the queues by changing the weights of the queues.

There is no minimum bandwidth requirement for a given queue. For example, queue qosp3 is not required to have at least 50% of the bandwidth.

December 2005 © Foundry Networks, Inc.

13 - 13

Foundry Configuration Guide for the FESX, FSX, and FWSX

Command Syntax

To change the bandwidth percentages for the queues, enter commands such as the following. Note that this example uses the default queue names.

FESX424 Switch(config)# qos profile qosp7 25 qosp6 15 qosp5 12 qosp4 12 qosp3 10 qosp2 10 qosp1 10 qosp0 6

Profile qosp7 : Priority7 bandwidth requested 25% calculated 25%

Profile qosp6 : Priority6 bandwidth requested 15% calculated 15%

Profile qosp5 : Priority5 bandwidth requested 12% calculated 12%

Profile qosp4 : Priority4 bandwidth requested 12% calculated 12%

Profile qosp3 : Priority3 bandwidth requested 10% calculated 10%

Profile qosp2 : Priority2 bandwidth requested 10% calculated 10%

Profile qosp1 : Priority1 bandwidth requested 10% calculated 10%

Profile qosp0 : Priority0 bandwidth requested 6% calculated 6%

Syntax: [no] qos profile <queue> <percentage> <queue> <percentage> <queue> <percentage>

<queue> <percentage> <queue> <percentage> <queue> <percentage> <queue> <percentage>

<queue> <percentage>

Each <queue> parameter specifies the name of a queue. You can specify the queues in any order on the command line, but you must specify each queue.

The <percentage> parameter specifies a number for the percentage of the device’s outbound bandwidth that is allocated to the queue. The FESX, FSX, and FWSX QoS queues require a minimum bandwidth percentage of 3% for each priority. When jumbo frames are enabled, the minimum bandwidth requirement is 8%. If these minimum values are not met, QoS may not be accurate.

Configuration Notes

• The total of the percentages you enter must equal 100.

• The FESX, FSX, and FWSX do not adjust the bandwidth percentages you enter. BigIron QoS does adjust the bandwidth percentages to ensure that each queue has at least its required minimum bandwidth percentage.

• When sFlow is enabled, the FESX, FSX, and FWSX support seven priorities instead of eight. When sFlow is enabled, Priority 1 is not used. Any values assigned to queue 1 will be directed to queue 0.

Changing the Bandwidth Allocations

NOTE: This feature is supported in releases 02.2.00 and later.

To change the default bandwidth percentages for the queues when the device is configured to use the combined

SP and WRR queuing mechanism, enter commands such as the following. Note that this example uses the default queue names.

FESX424 Switch(config)#qos profile qosp7 sp qosp6 sp qosp5 20 qosp4 16 qosp3 16 qosp2 16 qosp1 16 qosp0 16

Syntax: [no] qos profile <queue 7> sp <queue 6> sp | <percentage> <queue 5> <percentage> <queue 4>

<percentage> <queue 3> <percentage> <queue 2> <percentage> <queue 1> <percentage> <queue 0>

<percentage>]

Each <queue x > parameter specifies the name of a queue. You can specify the queues in any order on the command line, but you must specify each queue. Note that queue 7 supports strict priority only, queue 6 supports both strict priority and WRR queuing mechanisms, and queues 0 – 5 support the WRR queuing mechanism only.

The sp parameter configures strict priority as the queuing mechanism. Note that only queue 7 and queue 6 support this method.

The <percentage> parameter configures WRR as the queuing mechanism and specifies the percentage of the device’s outbound bandwidth allocated to the queue. The queues require a minimum bandwidth percentage of

13 - 14 © Foundry Networks, Inc.

December 22, 2005

Configuring Quality of Service

3% for each priority. When jumbo frames are enabled, the minimum bandwidth requirement is 8%. If these minimum values are not met, QoS may not be accurate.

NOTE: The total of the percentages must equal 100. The Foundry device does not adjust the bandwidth percentages you enter. In contrast, the BigIron QoS does adjust the bandwidth percentages to ensure that each queue has at least its required minimum bandwidth percentage.

NOTE: When sFlow is enabled, the Foundry device supports seven priorities instead of eight. When sFlow is enabled, Priority 1 is not used. Any values assigned to queue 1 will be directed to queue 0.

Viewing QoS Settings

To display the QoS settings for all the queues, enter the show qos-profiles command, as shown in the following examples.

The following shows an example display output on a FESX.

FESX424 Switch(config)# show qos-profiles all bandwidth scheduling mechanism: weighted priority

Profile qosp7 : Priority7 bandwidth requested 25% calculated 25%

Profile qosp6 : Priority6 bandwidth requested 15% calculated 15%

Profile qosp5 : Priority5 bandwidth requested 12% calculated 12%

Profile qosp4 : Priority4 bandwidth requested 12% calculated 12%

Profile qosp3 : Priority3 bandwidth requested 10% calculated 10%

Profile qosp2 : Priority2 bandwidth requested 10% calculated 10%

Profile qosp1 : Priority1 bandwidth requested 10% calculated 10%

Profile qosp0 : Priority0 bandwidth requested 6% calculated 6%

Syntax: show qos-profiles all | <name>

The all parameter displays the settings for all eight queues.

The <name> parameter displays the settings for the specified queue.

December 2005 © Foundry Networks, Inc.

13 - 15

Foundry Configuration Guide for the FESX, FSX, and FWSX

Viewing DSCP-based QoS Settings

To display configuration information for DSCP-based QoS, enter the following command at any level of the CLI:

FastIron SuperX Switch(config)#show qos-tos

DSCP-->Traffic-Class map: (DSCP = d1d2: 00, 01...63)

d2| 0 1 2 3 4 5 6 7 8 9

d1 |

-----+----------------------------------------

0 | 0 0 0 0 0 0 0 0 1 1

1 | 1 1 1 1 1 1 2 2 2 2

2 | 2 2 2 2 3 3 3 3 3 3

3 | 3 3 4 4 4 4 4 4 4 4

4 | 5 5 5 5 5 5 5 5 6 6

5 | 6 6 6 6 6 6 7 7 7 7

6 | 7 7 7 7

Traffic-Class-->802.1p-Priority map (use to derive DSCP--802.1p-Priority):

Traffic | 802.1p

Class | Priority

--------+---------

0 | 0

1 | 1

2 | 2

3 | 3

4 | 4

5 | 5

6 | 6

7 | 7

--------+---------

Syntax: show qos-tos

This command shows the following information.

This Field...

DSCP-Priority map d1 and d2

Table 13.10: DSCP-based QoS Configuration Information

Displays...

The DSCP to forwarding priority mappings that are currently in effect.

Note : The example above shows the default mappings. If you change the mappings, the command displays the changed mappings

13 - 16 © Foundry Networks, Inc.

December 22, 2005

Configuring Quality of Service

Table 13.10: DSCP-based QoS Configuration Information (Continued)

Displays...

This Field...

Traffic Class -> 802.1 Priority map

Traffic Class and 802.1p Priority The traffic class to 802.1p Priority mappings that are currently in effect.

Note : The example above shows the default mappings. If you change the mappings, the command displays the changed mappings.

December 2005 © Foundry Networks, Inc.

13 - 17

Foundry Configuration Guide for the FESX, FSX, and FWSX

13 - 18 © Foundry Networks, Inc.

December 22, 2005

Chapter 14

Configuring Rate Limiting

This chapter describes how to configure rate limiting on Foundry FastIron devices using the CLI.

This chapter contains the following information:

Table 14.1: Chapter Contents

Description

Overview

Configuring a Port-Based Rate Limiting Policy

Configuring an ACL-Based Rate Limiting Policy

Optimizing Rate Limiting

Displaying the Fixed Rate Limiting Configuration

See Page

14-1

14-3

14-3

14-3

14-4

Overview

Fixed Rate Limiting allows you to specify the maximum number of bytes a given port can send or receive. The port drops bytes that exceed the limit you specify. You can configure a Fixed Rate Limiting policy on a port’s inbound direction only. Fixed rate limiting applies to all traffic on the rate limited port.

When you specify the maximum number of bytes, you specify it in bits per second (bps). The Fixed Rate Limiting policy applies to one-second intervals and allows the port to send or receive the number of bytes you specify in the policy, but drops additional bytes. Unused bandwidth is not carried over from one interval to the next.

NOTE: Foundry recommends that you do not use Fixed Rate Limiting on ports that send or receive route control traffic or Spanning Tree Protocol (STP) control traffic. If the port drops control packets due to the Fixed Rate

Limiting policy, routing or STP can be disrupted.

Rate Limiting in Hardware

Each FastIron device supports line-rate rate limiting in hardware. The device creates entries in Content

Addressable Memory (CAM) for the rate limiting policies. The CAM entries enable the device to perform the rate limiting in hardware instead of sending the traffic to the CPU. The device sends the first packet in a given traffic

December 2005 © Foundry Networks, Inc.

14 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX flow to the CPU, which creates a CAM entry for the traffic flow. A CAM entry consists of the source and destination addresses of the traffic. The device uses the CAM entry for rate limiting all the traffic within the same flow. A rate limiting CAM entry remains in the CAM for two minutes before aging out.

How Fixed Rate Limiting Works

Fixed Rate Limiting counts the number of bytes that a port either sends or receives, in one second intervals. The direction that the software monitors depends on the direction you specify when you configure the rate limit on the port. If the number of bytes exceeds the maximum number you specify when you configure the rate, the port drops all further packets for the rate-limited direction, for the duration of the one-second interval.

Once the one-second interval is complete, the port clears the counter and re-enables traffic.

Figure 14.1 shows an example of how Fixed Rate Limiting works. In this example, a Fixed Rate Limiting policy is applied to a port to limit the inbound traffic to 500000 bits (62500 bytes) a second. During the first two one-second intervals, the port receives less than 500000 bits in each interval. However, the port receives more than 500000 bits during the third and fourth one-second intervals, and consequently drops the excess traffic.

Figure 14.1

Fixed Rate Limiting

The Fixed Rate Limiting policy allows up to 500000 bits

(62500 bytes) of inbound traffic during each one-second interval.

Once the maximum rate is reached, all additional traffic within the one-second interval is dropped.

One-second interval

One-second interval

One-second interval

One-second interval

500000 bps (62500 bytes)

Zero bps

Beginning of one-second interval

NOTE: The software counts the bytes by polling statistics counters for the port every 100 milliseconds, which provides 10 readings each second. Due to the polling interval, the Fixed Rate Limiting policy has an accuracy of within 10% of the port's line rate. It is therefore possible for the policy to sometimes allow more traffic than the limit you specify, but the extra traffic is never more than 10% of the port's line rate.

Configuration Notes

The following FastIron Ironware releases support fixed rate limiting for inbound traffic on individual ports (portbased rate limiting):

• FESX releases 01.1.00 and later

• All FWSX software releases

• All FSX software releases

14 - 2 © Foundry Networks, Inc.

December 2005

Configuring Rate Limiting

• Rate limiting is available only on inbound ports on FastIron devices.

• Fixed rate limiting is not supported on 10-Gigabit Ethernet ports.

Configuring a Port-Based Rate Limiting Policy

To configure rate limiting on a port, enter commands such as the following:

FESX424 Router(config)# interface ethernet 24

FESX424 Router(config-if-e1000-24)# rate input fixed 500000

These commands configure a fixed rate limiting policy that allows port 24 to receive a maximum of 500000 bits per second (62500 bytes per second). If the port receives additional bytes during a given one-second interval, the port drops all inbound packets on the port until the next one-second interval starts.

Syntax: [no] rate-limit input fixed <average-rate>

The <average-rate> parameter specifies the maximum number of bits per second (bps) the port can receive. The minimum rate that can be configured on FESX, FSX, and FWSX devices is 64,000 bps.

Configuring an ACL-Based Rate Limiting Policy

Software releases 02.3.03 and later provide support for IP ACL-based rate limiting of inbound traffic. ACL-based rate limiting provides the facility to limit the rate for IP traffic that matches the permit conditions in extended IP

ACLs. This feature is available in the Layer 2 and Layer 3 code.

To configure ACL-based rate limiting on an X-Series device, you create individual traffic policies , then reference the traffic policies in one or more ACL entries (also called clauses or statements). The traffic policies become effective on ports to which the ACLs are bound.

Configuration procedures for ACL-based rate limiting are in the chapter “Traffic Policies” on page 15-1.

Optimizing Rate Limiting

By default, rate limiting is optimized for packets that are 256 bytes in size. This packet size includes 14 bytes of

Layer 2 header (Ethernet II untagged) and 4 bytes of Layer 2 CRC.

To optimize rate limiting for all packet sizes, use the payload-only parameter. When this parameter is specified, the system excludes Layer 2 header and Layer 2 checksum (CRC) from the calculations, and the rate is accurate for all packet sizes and Layer 2 overhead (Layer 2 header + CRC). Layer 2 overhead for different encapsulations is as follows:

• Untagged Ethernet-II – 18 bytes

• Tagged Ethernet-II – 22 bytes

• LLC over Untagged Ethernet-II – 21 bytes

• LLC over Tagged Ethernet-II – 25 bytes

• LLC/SNAP over Untagged Ethernet-II – 26 bytes

• LLC/SNAP over Tagged Ethernet-II – 30 bytes

To optimize rate limiting, enter commands such as the following:

FESX424 Router(config)# interface ethernet 24

FESX424 Router(config-if-e1000-24)# rate input fixed 500000 payload-only

These commands configure a fixed rate limiting policy that allows port 24 to receive a maximum of 500000 bits per second. The payload-only parameter causes the device to exclude the Layer 2 header and Layer 2 checksum from the calculations.

December 2005 © Foundry Networks, Inc.

14 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

NOTE: When you enable the payload-only parameter on the FESX, FSX, and FWSX devices, the configuration applies to all the other ports in the same port region. For example, if you enable the payload-only option on port

12 on a FESX424, the configuration applies to ports 1 through 12 since these ports are in the same port region.

Syntax: [no] rate-limit input fixed <average-rate> [payload-only]

The <average-rate> parameter specifies the maximum number of bits per second (bps) the port can receive. The minimum rate that can be configured on FESX, FSX, and FWSX devices is 64,000 bps. By default, rate limiting is optimized for packets that are 256 bytes in size.

Displaying the Fixed Rate Limiting Configuration

To display the fixed rate limiting configuration on the device, enter the following command:

FESX424 Switch(config-if-e1000-21)#show rate-limit fixed

Total rate-limited interface count: 11.

Port Configured Input Rate Actual Input Rate Mode

1 1000000 1000000 Payload-Only

3 10000000 10005000 Default

7 10000000 10000000 Payload-Only

9 7500000 7502000 Payload-Only

11 8000000 7999000 Default

12 8000000 7999000 Default

13 8000000 7999000 Default

14 8000000 7999000 Default

15 8000000 7999000 Default

21 8000000 8000000 Payload-Only

25 7500000 7502000 Default

Syntax: show rate-limit fixed

The command lists the ports on which fixed rate limiting is configured, and provides the information listed in Table

14.2 for each of the ports.

Actual Input Rate

Table 14.2: CLI Display of Fixed Rate Limiting Information

This Field...

Total rate-limited interface count

Port

Configured Input Rate

Displays...

The total number of ports that are configured for Fixed Rate Limiting.

The port number.

The maximum rate requested for inbound traffic. The rate is measured in bits per second (bps).

The actual maximum rate provided by the hardware. The rate is measured in bps.

14 - 4 © Foundry Networks, Inc.

December 2005

Chapter 15

Traffic Policies

X-Series devices use traffic policies to:

• Rate limit inbound traffic

• Count the packets and bytes per packet to which ACL permit or deny clauses are applied

This chapter describes how traffic policies are implemented and configured in the FESX, FSX, and FWSX devices. This chapter contains the topics listed in Table 15.1.

Table 15.1: Chapter Contents

Description

Overview of traffic policies

Configuration notes and feature limitations

Viewing and configuring the maximum number of traffic policies supported on a device

Using traffic policies to rate limit traffic

Using traffic policies for ACL and rate limit counting

Viewing traffic policies

See Page

15-1

15-2

15-3

15-3

15-7

15-10

About Traffic Policies

Traffic policies consist of policy names and policy definitions.

• Traffic policy name – This is a string of up to 8 alphanumeric characters that identifies individual traffic policy definitions.

• Traffic policy definition ( TPD ) – This is the command filter associated with a traffic policy name. A TPD can define any one of the following:

• Rate limiting policy

• ACL counting policy

• Combined rate limiting and ACL counting policy

The maximum number of supported active TPDs is a system-wide parameter and depends on the device you

December 2005 © Foundry Networks, Inc.

15 1

Foundry Configuration Guide for the FESX, FSX, and FWSX are configuring. The total number of active TPDs cannot exceed the system maximum. See “Maximum

Number of Traffic Policies Supported on a Device” on page 15-3.

When you apply a traffic policy to an interface, you do so by adding a reference to the traffic policy in an ACL entry, instead of applying the individual traffic policy to the interface. The traffic policy becomes an active traffic policy or active TPD when you bind its associated ACL to an interface.

To configure traffic policies for ACL-based rate limiting, see “Configuring ACL-Based Fixed Rate Limiting” on page 15-4 and “Configuring ACL-Based Adaptive Rate Limiting” on page 15-5.

To configure traffic policies for ACL counting, see “Enabling ACL Counting” on page 15-8.

Configuration Notes and Feature Limitations

Note the following when configuring traffic policies:

• This feature is supported in the Layer 2 and Layer 3 code.

• This feature applies to IP ACLs only. X-Series devices do not support Layer 2 ACLs.

• Traffic policies are not supported on 10-Gigabit Ethernet interfaces.

• The maximum number of supported active TPDs is a system-wide parameter and depends on the device you are configuring. The total number of active TPDs cannot exceed the system maximum. See “Maximum

Number of Traffic Policies Supported on a Device” on page 15-3.

• You can reference the same traffic policy in more than one ACL entry within an access list. For example, two or more ACL statements in ACL 101 can reference a TPD named TPD1.

• You can reference the same traffic policy in more than one access list. For example, ACLs 101 and 102 could both reference a TPD named TPD1.

• To modify or delete an active traffic policy, you must first unbind the ACL that references the traffic policy.

• When you define a TPD (when you enter the CLI command traffic-policy ), explicit marking of CoS parameters, such as traffic class and 802.1p priority, are not available on the device. In the case of a TPD defining rate limiting, the device re-marks CoS parameters based on the DSCP value in the packet header and the determined conformance level of the rate limited traffic, as shown in Table 15.2.

If the packet’s Conformance

Level is...

0 (Green) or

1 (Yellow)

2 (Red)

Table 15.2: CoS Parameters for Packets that use Rate Limiting Traffic Policies and the packet’s DSCP Value is...

0 – 7

8 – 15

16 – 23

24 – 31

32 – 39

40 – 47

48 – 55

56 – 63

N/A the device sets the Traffic

Class and 802.1p Priority to...

0 (lowest priority queue)

1

2

3

4

5

6

7 (highest priority queue)

0 (lowest priority queue)

15 2 © Foundry Networks, Inc.

December 2005

Traffic Policies

Maximum Number of Traffic Policies Supported on a Device

The maximum number of supported active traffic policies is a system-wide parameter and depends on the device you are configuring, as follows:

• By default, up to 1024 active traffic policies are supported on Layer 2 switches. This value is fixed on Layer 2 switches and cannot be modified.

• The number of active traffic policies supported on Layer 3 switches varies depending on the configuration and the available system memory. The default value and also the maximum number of traffic policies supported on Layer 3 switches is 50.

Setting the Maximum Number of Traffic Policies Supported on a Layer 3 Device

If desired you can adjust the maximum number of active traffic policies that a Layer 3 device will support. To do so, enter commands such as the following at the Global CONFIG level of the CLI:

FESX424 Switch(config)# system-max hw-traffic-conditioner 25

FESX424 Switch(config)# write memory

FESX424 Switch(config)# reload

NOTE: You must save the configuration and reload the software to place the change into effect.

Syntax: [no] system-max hw-traffic-conditioner <num>

<num> is a value from 0 to n , where 0 disables hardware resources for traffic policies, and n is a number up to

1024. The maximum number you can configure depends on the configuration and available memory on your device. If the configuration you enter causes the device to exceed the available memory, the device will reject the configuration and display a warning message on the console.

NOTE: Foundry does not recommend setting the system-max for traffic policies to 0 (zero), since this renders traffic policies ineffective.

ACL-Based Rate Limiting via Traffic Policies

Software release 02.3.03 provides support for IP ACL-based rate limiting of inbound traffic. ACL-based rate limiting provides the facility to limit the rate for IP traffic that matches the permit conditions in extended IP ACLs.

This feature is available in the Layer 2 and Layer 3 code.

To configure ACL-based rate limiting on an X-Series device, you create individual traffic policies , then reference the traffic policies in one or more ACL entries (also called clauses or statements). The traffic policies become effective on ports to which the ACLs are bound. See “About Traffic Policies” on page 15-1.

When you configure a traffic policy for rate limiting, the device automatically enables rate limit counting , similar to the two-rate three-color marker (trTCM) mechanism described in RFC 2698 for adaptive rate limiting, and the single-rate three-color marker (srTCM) mechanism described in RFC 2697 for fixed rate limiting. This feature counts the number of bytes and trTCM or srTCM conformance level per packet to which rate limiting traffic policies are applied. See “ACL and Rate Limit Counting” on page 15-7.

You can configure ACL-based rate limiting on the following interface types:

• physical Ethernet interfaces

• virtual interfaces

• trunk ports

• specific VLAN members on a port (New in 02.3.03 – see “Applying an ACL to Specific VLAN Members on a

Port (Layer 2 Devices Only)” on page 12-21

• a subset of ports on a virtual interface (New in 02.3.03 – see “Applying an ACL to a Subset of Ports on a

Virtual Interface (Layer 3 Devices Only)” on page 12-21.)

December 2005 © Foundry Networks, Inc.

15 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

Support for Fixed Rate Limiting and Adaptive Rate Limiting

X-Series devices support the following types of ACL-based rate limiting:

• Fixed Rate Limiting – Enforces a strict bandwidth limit. The device forwards traffic that is within the limit but either drops all traffic that exceeds the limit, or forwards all traffic that exceeds the limit at the lowest priority level, according to the action specified in the traffic policy.

• Adaptive Rate Limiting – Enforces a flexible bandwidth limit that allows for bursts above the limit. You can configure Adaptive Rate Limiting to forward, modify the IP precedence of and forward, or drop traffic based on whether the traffic is within the limit or exceeds the limit.

Configuring ACL-Based Fixed Rate Limiting

Use the procedures in this section to configure ACL-based fixed rate limiting. Before configuring this feature, see what to consider in “Configuration Notes and Feature Limitations” on page 15-2.

Fixed rate limiting enforces a strict bandwidth limit. The port forwards traffic that is within the limit. If the port receives more than the specified number of fragments in a one-second interval, the device either drops or forwards subsequent fragments in hardware, depending on the action you specify.

To implement the ACL-based fixed rate limiting feature, first create a traffic policy, then reference the policy in an extended ACL statement. Lastly, bind the ACL to an interface. Follow the steps below.

1.

Create a traffic policy. Enter a command such as the following:

FESX424 Switch(config)# traffic-policy TPD1 rate-limit fixed 100 exceed-action drop

2.

Create an extended ACL entry or modify an existing extended ACL entry that references the traffic policy. For example:

FESX424 Switch(config)# access-list 101 permit ip host 210.10.12.2 any trafficpolicy TPD1

3.

Bind the ACL to an interface.

FESX424 Switch(config)# int e 5

FESX424 Switch(config-if-e5)# ip access-group 101 in

FESX424 Switch(config-if-e5)# exit

The above commands configure a fixed rate limiting policy that allows port e5 to receive a maximum traffic rate of

100 kbps. If the port receives additional bits during a given one-second interval, the port drops the additional inbound packets that are received within that one-second interval.

Syntax: [no] traffic-policy <TPD name> rate-limit fixed <cir value> exceed-action <action> [count]

Syntax: access-list <num> permit | deny.... traffic policy <TPD name>

Syntax: [no] ip access-group <num> in | out

NOTES:

For brevity, some parameters were omitted from the above access-list syntax. For the complete CLI syntax, see the Foundry Switch and Router Command Line Interface Reference .

The software allows you to add a reference to a non-existent TPD in an ACL statement and to bind that ACL to an interface. The software does not issue a warning or error message for non-existent TPDs.

Use the no form of the command to delete a traffic policy definition. Note that you cannot delete a traffic policy definition if it is currently in use on a port. To delete a traffic policy, first unbind the associated ACL.

<TPD name> is the name of the traffic policy definition. This value can be 8 or fewer alphanumeric characters.

rate-limit fixed specifies that the traffic policy will enforce a strict bandwidth.

15 4 © Foundry Networks, Inc.

December 2005

Traffic Policies

<cir value> is the committed information rate in kbps. This value can be from 64 – 1000000 Kbps.

exceed-action <action> specifies the action to be taken when packets exceed the configured cir value. See

“Specifying the Action to be Taken for Packets that are Over the Limit” .

The count parameter is optional and enables ACL counting. See “ACL and Rate Limit Counting” on page 15-7.

Configuring ACL-Based Adaptive Rate Limiting

Use the procedures in this section to configure ACL-based adaptive rate limiting. Before configuring this feature, see what to consider in “Configuration Notes and Feature Limitations” on page 15-2.

Table 1 lists the configurable parameters for ACL-based adaptive rate limiting:

Table 1: ACL-Based Adaptive Rate Limiting Parameters

Parameter Definition

Committed Information Rate (CIR) The guaranteed kilobit rate of inbound traffic that is allowed on a port.

Committed Burst Size (CBS)

Peak Information Rate (PIR)

Peak Burst Size (PBS)

The number of bytes per second allowed in a burst before some packets will exceed the committed information rate. Larger bursts are more likely to exceed the rate limit. The CBS must be a value greater than zero (0). Foundry recommends that this value be equal to or greater than the size of the largest possible IP packet in a stream.

The peak maximum kilobit rate for inbound traffic on a port. The PIR must be equal to or greater than the CIR.

The number of bytes per second allowed in a burst before all packets will exceed the peak information rate. The PBS must be a value greater than zero (0). Foundry recommends that this value be equal to or greater than the size of the largest possible IP packet in the stream.

If a port receives more than the configured bit or byte rate in a one-second interval, the port will either drop or forward subsequent data in hardware, depending on the action you specify.

To implement the ACL-based adaptive rate limiting feature, first create a traffic policy then reference the policy in an extended ACL statement. Lastly, bind the ACL to an interface. Follow the steps below.

1.

Create a traffic policy. Enter a command such as the following:

FESX424 Switch(config)# traffic-policy TPDAfour rate-limit adaptive cir 10000 cbs 1600 pir 20000 pbs 4000 exceed-action drop

2.

Create a new extended ACL entry or modify an existing extended ACL entry that references the traffic policy.

For example:

FESX424 Switch(config)# access-list 104 permit ip host 210.10.12.2 any trafficpolicy TPDAfour

3.

Bind the ACL to an interface.

FESX424 Switch(config)# int e 7

FESX424 Switch(config-if-e7)# ip access-group 104 in

FESX424 Switch(config-if-e7)# exit

The above commands configure an adaptive rate limiting policy that enforces a guaranteed committed rate of

10000 kbps on port e7 and allows bursts of up to 1600 bytes. It also enforces a peak rate of 20000 kbps and allows bursts of 4000 bytes above the PIR limit. If the port receives additional bits during a given one-second interval, the port drops all packets on the port until the next one-second interval starts.

December 2005 © Foundry Networks, Inc.

15 5

Foundry Configuration Guide for the FESX, FSX, and FWSX

Syntax: [no] traffic-policy <TPD name> rate-limit adaptive cir <cir value> cbs <cbs value> pir <pir value> pbs <pbs value> exceed-action <action> [count]

Syntax: access-list <num> permit | deny.... traffic policy <TPD name>

Syntax: [no] ip access-group <num> in | out

NOTES:

For brevity, some parameters were omitted from the above access-list syntax. For the complete CLI syntax, see the Foundry Switch and Router Command Line Interface Reference .

The software allows you to add a reference to a non-existent TPD in an ACL statement and to bind that ACL to an interface. The software does not issue a warning or error message for non-existent TPDs.

Use the no form of the command to delete a traffic policy definition. Note that you cannot delete a traffic policy definition if it is currently in use on a port. To delete a traffic policy, first unbind the associated ACL.

<TPD name> is the name of the traffic policy definition. This value can be 8 or fewer alphanumeric characters.

rate-limit adaptive specifies that the policy will enforce a flexible bandwidth limit that allows for bursts above the limit.

<cir value> is the committed information rate in kbps. See Table 1.

<cbs value> is the committed burst size in bytes. See Table 1.

<pir value> is the peak information rate in kbps. See Table 1.

<pbs value> is the peak burst size in bytes. See Table 1.

exceed-action <action> specifies the action to be taken when packets exceed the configured values. See

“Specifying the Action to be Taken for Packets that are Over the Limit” .

The count parameter is optional and enables ACL counting. See “ACL and Rate Limit Counting” on page 15-7.

Specifying the Action to be Taken for Packets that are Over the Limit

You can specify the action to be taken when packets exceed the configured cir value for fixed rate limiting, or the cir, cbs, pir, and pbs values for adaptive rate limiting. You can specify one of the following actions:

• drop packets that exceed the limit

• permit packets that exceed the limit and forward them at the lowest priority level

Dropping Packets that Exceed the Limit

This section shows some example configurations and provides the CLI syntax for configuring a port to drop packets that exceed the configured limit(s) for rate limiting.

EXAMPLE:

The following shows an example fixed rate limiting configuration.

FESX424 Switch(config)# traffic-policy TPD1 rate-limit fixed 10000 exceed-action drop

The above command sets the fragment threshold at 10,000 per second. If the port receives more than 10,000 packet fragments in a one-second interval, the device drops the excess fragments.

Syntax: traffic-policy <TPD name> rate-limit fixed <cir value> exceed-action drop

EXAMPLE:

The following shows an example adaptive rate limiting configuration.

FESX424 Switch(config)# traffic-policy TPDAfour rate-limit adaptive cir 10000 cbs

1600 pir 20000 pbs 4000 exceed-action drop

15 6 © Foundry Networks, Inc.

December 2005

Traffic Policies

The above commands configure an adaptive rate limiting policy that enforces a guaranteed committed rate of

10000 kbps on port e7 and allows bursts of up to 1600 bytes. It also enforces a peak rate of 20000 kbps and allows bursts of 4000 bytes above the PIR limit. If the port receives additional bits during a given one-second interval, the port drops all packets on the port until the next one-second interval starts.

Syntax: traffic-policy rate-limit adaptive cir <cir value> cbs <cbs value> pir <pir value> pbs <pbs value> exceedaction drop

Permitting Packets that Exceed the Limit

This section shows some example configurations and provides the CLI syntax for configuring a port to permit packets that exceed the configured limit for rate limiting.

EXAMPLE:

The following shows an example fixed rate limiting configuration.

FESX424 Switch(config)# traffic-policy TPD1 rate-limit fixed 10000 exceed-action permit-at-low-pri

The above command sets the fragment threshold at 10,000 per second. If the port receives more than 10,000 packet fragments in a one-second interval, the device takes the specified action. The action specified with this command is to permit excess fragments and forward them at the lowest priority level.

Syntax: [no] traffic-policy <TPD name> rate-limit fixed <cir value> exceed-action permit-at-low-pri

EXAMPLE:

The following shows an example adaptive rate limiting configuration.

FESX424 Switch(config)# traffic-policy TPDAfour rate-limit adaptive cir 10000 cbs

1600 pir 20000 pbs 4000 exceed-action permit-at-low-pri

The above commands configure an adaptive rate limiting policy that enforces a guaranteed committed rate of

10000 kbps on port e7 and allows bursts of up to 1600 bytes. It also enforces a peak rate of 20000 kbps and allows bursts of 4000 bytes above the PIR limit. If the port receives additional bits during a given one-second interval, the port permits all packets on the port and forwards the packets at the lowest priority level.

Syntax: traffic-policy rate-limit adaptive cir <cir value> cbs <cbs value> pir <pir value> pbs <pbs value> exceedaction permit-at-low-pri

ACL and Rate Limit Counting

Software release 02.3.03 provides support for ACL counting and rate limit counting .

• ACL counting enables the Foundry device to count the number of packets and the number of bytes per packet to which ACL filters are applied.

• Rate limit counting counts the number of bytes and conformance level per packet to which rate limiting traffic policies are applied. The device uses the counting method similar to the two-rate three-color marker (trTCM) mechanism described in RFC 2698 for adaptive rate limiting, and the single-rate three-color marker (srTCM) mechanism described in RFC 2697 for fixed rate limiting. Rate limit counting is automatically enabled when a traffic policy is enforced (active). You can view these counters using the show commands listed in “Viewing

Traffic Policies” on page 15-10.

For more information about traffic policies, see “About Traffic Policies” on page 15-1.

This section provides the following procedures for ACL counting and rate limit counting:

• “Enabling ACL Counting” on page 15-8

• “Viewing ACL And Rate Limit Counters” on page 15-9

• “Clearing ACL and Rate Limit Counters” on page 15-10

December 2005 © Foundry Networks, Inc.

15 7

Foundry Configuration Guide for the FESX, FSX, and FWSX

15 8

Enabling ACL Counting

Use the procedures in this section to configure ACL counting. Before configuring this feature, see what to consider in “Configuration Notes and Feature Limitations” on page 15-2.

To enable ACL counting on an X-Series device, first create a traffic policy , then reference the traffic policy in an extended ACL entry. Lastly, bind the ACL to an interface. The ACL counting policy becomes effective on ports to which the ACLs are bound.

You also can enable ACL counting when you create a traffic policy for rate limiting. See “Enabling ACL Counting with Rate Limiting Traffic Policies” on page 15-8.

To implement the ACL counting feature, perform the following steps:

1.

Create a traffic policy. Enter a command such as the following:

FESX424 Switch(config)# traffic-policy TPD5 count

2.

Create an extended ACL entry or modify an existing extended ACL entry that references the traffic policy definition. For example:

FESX424 Switch(config)# access-list 101 permit ip host 210.10.12.2 any trafficpolicy TPD5

3.

Bind the ACL to an interface.

FESX424 Switch(config)# int e 4

FESX424 Switch(config-if-e4)# ip access-group 101 in

FESX424 Switch(config-if-e4)# exit

The above commands configure an ACL counting policy and apply it to port e4. Port e4 counts the number of packets and the number of bytes on the port that were permitted or denied by ACL filters.

Syntax: [no] traffic-policy <TPD name> count

Syntax: access-list <num> permit | deny.... traffic policy <TPD name>

Syntax: [no] ip access-group <num> in | out

NOTES:

For brevity, some parameters were omitted from the above access-list syntax. For the complete CLI syntax, see the Foundry Switch and Router Command Line Interface Reference .

The software allows you to add a reference to a non-existent TPD in an ACL statement and to bind that ACL to an interface. The software does not issue a warning or error message for non-existent TPDs.

Use the no form of the command to delete a traffic policy definition. Note that you cannot delete a traffic policy definition if it is currently in use on a port. To delete a traffic policy, first unbind the associated ACL.

<TPD name> is the name of the traffic policy definition. This value can be 8 alphanumeric characters or less.

Enabling ACL Counting with Rate Limiting Traffic Policies

The configuration example in the section “Enabling ACL Counting” shows how to enable ACL counting without having to configure parameters for rate limiting. You also can enable ACL counting while defining a rate limiting traffic policy, as illustrated in the following configuration examples.

EXAMPLE:

To enable ACL counting while defining traffic policies for fixed rate limiting, enter commands such as the following at the Global CONFIG Level of the CLI:

FESX424 Switch(config)# traffic-policy TPD1 rate-limit fixed 1000 count exceedaction drop

FESX424 Switch(config)# traffic-policy TPD2 rate-limit fixed 10000 exceed-action drop count

© Foundry Networks, Inc.

December 2005

Traffic Policies

Syntax: [no] traffic-policy <TPD name> rate-limit fixed <cir value> exceed-action <action> count

EXAMPLE:

To enable ACL counting while defining traffic policies for adaptive rate limiting, enter commands such as the following at the Global CONFIG Level of the CLI: traffic-policy TPDA4 rate-limit adaptive cir 10000 cbs 1600 pir 20000 pbs 4000 count exceed-action drop traffic-policy TPDA5 rate-limit adaptive cir 10000 cbs 1600 pir 20000 pbs 4000 exceed-action permit-at-low-pri count

Syntax: traffic-policy rate-limit adaptive cir <cir value> cbs <cbs value> pir <pir value> pbs <pbs value> exceedaction <action> count

Viewing ACL And Rate Limit Counters

When ACL counting is enabled on the Foundry device, you can use show commands to display the total packet count and byte count of the traffic filtered by ACL statements. The output of the show commands also display the rate limiting traffic counters, which are automatically enabled for active rate limiting traffic policies.

Use either the show access-list accounting command or the show statistics traffic-policy command to display

ACL and traffic policy counters. The output of these commands are identical. The following shows an example output.

FESX424 Switch# show access-list accounting g_voip

Traffic Policy - g_voip:

General Counters:

Port Region# Byte Count Packet Count

------------------ -------------------- ----------------------

7 (4/1 - 4/12) 85367040 776064

All port regions 84367040 776064

Rate Limiting Counters:

Port Region# Green Conformance Yellow Conformance Red Conformance

------------------ ------------------ ------------------ ------------------

7 (4/1 - 4/12) 329114195612139520 37533986897781760 0

All port regions 329114195612139520 37533986897781760 0

Syntax: show access-list accounting traffic-policy [<TPD name>]

OR

Syntax: show statistics traffic-policy [<TPD name>]

Table 2 defines the output of the show access-list accounting and show statistics traffic-policy commands.

This Line...

Traffic Policy

General Counters:

Port Region #

Byte Count

Table 2: ACL and Rate Limit Counting Statistics

Displays...

The name of the traffic policy.

The port region to which the active traffic policy applies.

The number of bytes that were filtered (matched ACL clauses).

December 2005 © Foundry Networks, Inc.

15 9

Foundry Configuration Guide for the FESX, FSX, and FWSX

Table 2: ACL and Rate Limit Counting Statistics

This Line...

Packet Count

Displays...

The number of packets that were filtered (matched ACL clauses).

Rate Limiting Counters:

Port Region#

Green Conformance

Yellow Conformance

Red Conformance

The port region to which the active traffic policy applies.

The number of bytes that did not exceed the CIR packet rate.

The number of bytes that exceeded the CIR packet rate.

The number of bytes that exceeded the PIR packet rate.

Clearing ACL and Rate Limit Counters

The Foundry device keeps a running tally of the number of packets and the number of bytes per packet that are filtered by ACL statements and rate limiting traffic policies. You can clear these accumulated counters, essentially resetting them to zero. To do so, use either the clear access-list account traffic-policy or the clear statistics traffic-policy command.

To clear the counters for ACL counting and rate limit counting, enter commands such as the following:

FESX424 Switch(config)# clear access-list accounting traffic-policy CountOne

FESX424 Switch(config)# clear statistics traffic-policy CountTwo

Syntax: clear access-list accounting traffic-policy <TPD name>

OR

Syntax: clear statistics traffic-policy <TPD name> where <TPD name> is the name of the traffic policy definition for which you want to clear traffic policy counters.

Viewing Traffic Policies

To view traffic policies that are currently defined on the Foundry device, enter the show traffic-policy command.

An example display output is shown below. Table 3 defines the output.

FESX424 Switch# show traffic-policy t_voip

Traffic Policy - t_voip:

Metering Enabled, Parameters:

Mode: Adaptive Rate-Limiting

cir: 100 kbps, cbs: 2000 bytes, pir: 200 kbps, pbs: 4000 bytes

Counting Not Enabled

Number of References/Bindings:1

Syntax: show traffic-policy [<TPD name>]

To display all traffic policies, enter the show traffic-policy command without entering a TPD name.

15 10 © Foundry Networks, Inc.

December 2005

This Line...

Traffic Policy

Metering

Mode cir cbs pir pbs

Counting

Number of References/

Bindings

Table 3: Traffic Policy Information

Displays...

The name of the traffic policy.

Shows whether or not rate limiting was configured as part of the traffic policy.

• Enabled – The traffic policy includes a rate limiting configuration.

• Disabled – The traffic policy does not include a rate limiting configuration

If rate limiting is enabled, this field shows the type of metering enabled on the port:

• Fixed Rate-Limiting

• Adaptive Rate-Limiting

The committed information rate, in kbps, for the adaptive rate-limiting policy.

The committed burst size, in bytes per second, for the adaptive rate-limiting policy.

The peak information rate, in kbps, for the adaptive ratelimiting policy.

The peak burst size, in bytes per second, for the adaptive rate-limiting policy.

Shows whether or not ACL counting was configured as part of the traffic policy.

• Enabled – The traffic policy includes an ACL counting configuration.

• Disabled – The traffic policy does not include an ACL traffic counting configuration.

The number of times this traffic policy is referenced in an

ACL statement and the number of active bindings for this traffic policy.

Traffic Policies

December 2005 © Foundry Networks, Inc.

15 11

Foundry Configuration Guide for the FESX, FSX, and FWSX

15 12 © Foundry Networks, Inc.

December 2005

Chapter 16

Configuring IP

This chapter describes the Internet Protocol (IP) parameters on Foundry Layer 2 Switches and Layer 3 Switches and how to configure them.

NOTE: References to chassis-based Layer 3 Switches apply to the FastIron SuperX Switch.

This chapter contains the following information:

Table 16.1: Chapter Contents

Description

Basic configuration instructions for configuring a Layer 2 or Layer 3 switch

Overview of IP

Basic IP parameters and defaults for Layer 3 switches

Basic IP parameters and defaults for Layer 2 switches

Configuring IP parameters on Layer 3 switches

Configuring IP parameters on Layer 2 switches

Displaying IP configuration information and statistics

See Page

16-1

16-2

16-8

16-15

16-17

16-51

16-57

Basic Configuration

IP is enabled by default. Basic configuration consists of adding IP addresses and, for Layer 3 Switches, enabling a route exchange protocol, such as Routing Information Protocol (RIP).

• If you are configuring a Layer 3 Switch, see “Configuring IP Addresses” on page 16-17 to add IP addresses, then see one or more of the following to enable and configure the route exchange protocols:

• “Configuring RIP” on page 17-1

• “Configuring OSPF” on page 20-1

• “Configuring BGP4” on page 21-1

December 2005 © Foundry Networks, Inc.

16 - 1

Foundry Configuration Guide for the FESX, FSX, and FWSX

• If you are configuring a Layer 2 Switch, see “Configuring the Management IP Address and Specifying the

Default Gateway” on page 16-51 to add an IP address for management access through the network and to specify the default gateway.

The rest of this chapter describes IP and how to configure it in more detail. Use the information in this chapter if you need to change some of the IP parameters from their default values or you want to view configuration information or statistics.

Overview

Foundry Networks Layer 2 Switches and Layer 3 Switches support Internet Protocol (IP) version 4. IP support on

Foundry Layer 2 Switches consists of basic services to support management access and access to a default gateway. IP support on Foundry Layer 3 Switches includes all of the following, in addition to a highly configurable implementation of basic IP services including Address Resolution Protocol (ARP), ICMP Router Discovery

Protocol (IRDP), and Reverse ARP (RARP):

• Route exchange protocols

• Routing Information Protocol (RIP)

• Open Shortest Path First (OSPF)

• Border Gateway Protocol version 4 (BGP4)

• Multicast protocols

• Internet Group Membership Protocol (IGMP)

• Protocol Independent Multicast Dense (PIM-DM)

• Protocol Independent Multicast Sparse (PIM-SM)

• Distance Vector Multicast Routing Protocol (DVMRP)

• Router redundancy protocols

• Virtual Router Redundancy Protocol Extended (VRRPE)

• Virtual Router Redundancy Protocol (VRRP)

IP Interfaces

Foundry Layer 3 Switches and Layer 2 Switches allow you to configure IP addresses. On Layer 3 Switches, IP addresses are associated with individual interfaces. On Layer 2 Switches, a single IP address serves as the management access address for the entire device.

All Foundry Layer 3 Switches and Layer 2 Switches support configuration and display of IP address in classical sub-net format (example: 192.168.1.1 255.255.255.0) and Classless Interdomain Routing (CIDR) format

(example: 192.168.1.1/24). You can use either format when configuring IP address information. IP addresses are displayed in classical sub-net format by default but you can change the display format to CIDR. See “Changing the Network Mask Display to Prefix Format” on page 16-57.

Layer 3 Switches

Foundry Layer 3 Switches allow you to configure IP addresses on the following types of interfaces:

• Ethernet ports

• Virtual routing interfaces (used by VLANs to route among one another)

• Loopback interfaces

Each IP address on a Layer 3 Switch must be in a different sub-net. You can have only one interface that is in a given sub-net. For example, you can configure IP addresses 192.168.1.1/24 and 192.168.2.1/24 on the same

Layer 3 Switch, but you cannot configure 192.168.1.1/24 and 192.168.1.2/24 on the same Layer 3 Switch.

You can configure multiple IP addresses on the same interface.

16 - 2 © Foundry Networks, Inc.

December 2005

Configuring IP

The number of IP addresses you can configure on an individual interface depends on the Layer 3 Switch model.

To display the maximum number of IP addresses and other system parameters you can configure on a Layer 3

Switch, see the section “Displaying and Modifying System Parameter Default Settings” on page 4-8.

You can use any of the IP addresses you configure on the Layer 3 Switch for Telnet, Web management, or SNMP access.

Layer 2 Switches

You can configure an IP address on a Foundry Layer 2 Switch for management access to the Layer 2 Switch. An

IP address is required for Telnet access, Web management access, and SNMP access.

You also can specify the default gateway for forwarding traffic to other sub-nets.

IP Packet Flow Through a Layer 3 Switch

Figure 16.1 shows how an IP packet moves through a Foundry Layer 3 Switch.

Figure 16.1

IP Packet flow through aFoundry Layer 3 Switch

Load

Balancing

Algorithm

N

Y

Mult.

Equalcost

Paths

Lowest

Metric

Y

PBR or

IP acc policy

N

Incoming

Port

Session

Table

N

Y

Fwding

Cache

N

Y

Outgoing

Port

IP Route

Table

Lowest

Admin.

Distance

RIP

OSPF

BGP4

ARP

Cache

Static ARP

Table

December 2005 © Foundry Networks, Inc.

16 - 3

Foundry Configuration Guide for the FESX, FSX, and FWSX

Figure 16.1 shows the following packet flow:

1.

When the Layer 3 Switch receives an IP packet, the Layer 3 Switch checks for filters on the receiving interface.

1

If a deny filter on the interface denies the packet, the Layer 3 Switch discards the packet and performs no further processing, except generating a Syslog entry and SNMP message, if logging is enabled for the filter.

2.

If the packet is not denied at the incoming interface, the Layer 3 Switch looks in the session table for an entry that has the same source IP address and TCP or UDP port as the packet. If the session table contains a matching entry, the Layer 3 Switch immediately forwards the packet, by addressing it to the destination IP address and TCP or UDP port listed in the session table entry and sending the packet to a queue on the outgoing port(s) listed in the session table. The Layer 3 Switch selects the queue based on the Quality of

Service (QoS) level associated with the session table entry.

3.

If the session table does not contain an entry that matches the packet’s source address and TCP or UDP port, the Layer 3 Switch looks in the IP forwarding cache for an entry that matches the packet’s destination IP address. If the forwarding cache contains a matching entry, the Layer 3 Switch forwards the packet to the IP address in the entry. The Layer 3 Switch sends the packet to a queue on the outgoing port(s) listed in the forwarding cache. The Layer 3 Switch selects the queue based on the Quality of Service (QoS) level associated with the forwarding cache entry.

4.

If the IP forwarding cache does not have an entry for the packet, the Layer 3 Switch checks the IP route table for a route to the packet’s destination. If the IP route table has a route, the Layer 3 Switch makes an entry in the session table or the forwarding cache, and sends the route to a queue on the outgoing port(s).

• If the running-config contains an IP access policy for the packet, the software makes an entry in the session table. The Layer 3 Switch uses the new session table entry to forward subsequent packets from the same source to the same destination.

• If the running-config does not contain an IP access policy for the packet, the software creates a new entry in the forwarding cache. The Layer 3 Switch uses the new cache entry to forward subsequent packets to the same destination.

The following sections describe the IP tables and caches:

• ARP cache and static ARP table

• IP route table

• IP forwarding cache

• IP session table

The software enables you to display these tables. You also can change the capacity of the tables on an individual basis if needed by changing the memory allocation for the table.

ARP Cache and Static ARP Table

The ARP cache contains entries that map IP addresses to MAC addresses. Generally, the entries are for devices that are directly attached to the Layer 3 Switch.

An exception is an ARP entry for an interface-based static IP route that goes to a destination that is one or more router hops away. For this type of entry, the MAC address is either the destination device’s MAC address or the

MAC address of the router interface that answered an ARP request on behalf of the device, using proxy ARP.

ARP Cache

The ARP cache can contain dynamic (learned) entries and static (user-configured) entries. The software places a dynamic entry in the ARP cache when the Layer 3 Switch learns a device’s MAC address from an ARP request or

ARP reply from the device.

1.The filter can be an Access Control List (ACL) or an IP access policy.

16 - 4 © Foundry Networks, Inc.

December 2005

Configuring IP

The software can learn an entry when the Layer 2 Switch or Layer 3 Switch receives an ARP request from another

IP forwarding device or an ARP reply. Here is an example of a dynamic entry:

IP Address MAC Address Type Age Port

1 207.95.6.102 0800.5afc.ea21 Dynamic 0 6

Each entry contains the destination device’s IP address and MAC address.

Static ARP Table

In addition to the ARP cache, Layer 3 Switches have a static ARP table. Entries in the static ARP table are userconfigured. You can add entries to the static ARP table regardless of whether the device the entry is for is connected to the Layer 3 Switch.

NOTE: The Layer 3 Switches have a static ARP table but Layer 2 Switches do not.

The software places an entry from the static ARP table into the ARP cache when the entry’s interface comes up.

Here is an example of a static ARP entry:

Index IP Address MAC Address Port

1 207.95.6.111 0800.093b.d210 1/1

Each entry lists the information you specified when you created the entry.

To display ARP entries, see the following:

• “Displaying the ARP Cache” on page 16-64 – Layer 3 Switch

• “Displaying the Static ARP Table” on page 16-65 – Layer 3 Switch only

• “Displaying ARP Entries” on page 16-75 – Layer 2 Switch

To configure other ARP parameters, see the following:

• “Configuring ARP Parameters” on page 16-25 – Layer 3 Switch only

To increase the size of the ARP cache and static ARP table, see the following:

• For dynamic entries, see the section “Displaying and Modifying System Parameter Default Settings” on page 4-8. The ip-arp parameter controls the ARP cache size.

• Static entries, “Changing the Maximum Number of Entries the Static ARP Table Can Hold” on page 16-28 –

Layer 3 Switches only. The ip-static-arp parameter controls the static ARP table size.

IP Route Table

The IP route table contains paths to IP destinations.

NOTE: Layer 2 Switches do not have an IP route table. A Layer 2 Switch sends all packets addressed to another sub-net to the default gateway, which you specify when you configure the basic IP information on the Layer 2

Switch.

The IP route table can receive the paths from the following sources:

• A directly-connected destination, which means there are no router hops to the destination

• A static IP route, which is a user-configured route

• A route learned through RIP

• A route learned through OSPF

• A route learned through BGP4

The IP route table contains the best path to a destination.

• When the software receives paths from more than one of the sources listed above, the software compares the

December 2005 © Foundry Networks, Inc.

16 - 5

Foundry Configuration Guide for the FESX, FSX, and FWSX administrative distance of each path and selects the path with the lowest administrative distance. The administrative distance is a protocol-independent value from 1 – 255.

• When the software receives two or more best paths from the same source and the paths have the same metric (cost), the software can load share traffic among the paths based on destination host or network address (based on the configuration and the Layer 3 Switch model).

Here is an example of an entry in the IP route table:

Destination NetMask Gateway Port Cost Type

1.1.0.0 255.255.0.0 99.1.1.2 1/1 2 R

Each IP route table entry contains the destination’s IP address and sub-net mask and the IP address of the nexthop router interface to the destination. Each entry also indicates the port attached to the destination or the nexthop to the destination, the route’s IP metric (cost), and the type. The type indicates how the IP route table received the route.

To display the IP route table, see the following:

• “Displaying the IP Route Table” on page 16-68 – Layer 3 Switch only

To configure a static IP route, see the following:

• “Configuring Static Routes” on page 16-32 – Layer 3 Switch only

To clear a route from the IP route table, see the following:

• “Clearing IP Routes” on page 16-70 – Layer 3 Switch only

To increase the size of the IP route table for learned and static routes, see the section “Displaying and Modifying

System Parameter Default Settings” on page 4-8.

• For learned routes, modify the ip-route parameter.

• For static routes, modify the ip-static-route parameter.

IP Forwarding Cache

The IP forwarding cache provides a fast-path mechanism for forwarding IP packets. The cache contains entries for IP destinations. When a Foundry Layer 3 Switch has completed processing and addressing for a packet and is ready to forward the packet, the device checks the IP forwarding cache for an entry to the packet’s destination.

• If the cache contains an entry with the destination IP address, the device uses the information in the entry to forward the packet out the ports listed in the entry. The destination IP address is the address of the packet’s final destination. The port numbers are the ports through which the destination can be reached.

• If the cache does not contain an entry and the traffic does not qualify for an entry in the session table instead, the software can create an entry in the forwarding cache.

Each entry in the IP forwarding cache has an age timer. If the entry remains unused for ten minutes, the software removes the entry. The age timer is not configurable.

Here is an example of an entry in the IP forwarding cache:

IP Address Next Hop MAC Type Port Vlan Pri

1 192.168.1.11 DIRECT 0000.0000.0000 PU n/a 0

Each IP forwarding cache entry contains the IP address of the destination, and the IP address and MAC address of the next-hop router interface to the destination. If the destination is actually an interface configured on the Layer

3 Switch itself, as shown here, then next-hop information indicates this. The port through which the destination is reached is also listed, as well as the VLAN and Layer 4 QoS priority associated with the destination if applicable.

To display the IP forwarding cache, see “Displaying the Forwarding Cache” on page 16-66.

16 - 6 © Foundry Networks, Inc.

December 2005

Configuring IP

NOTE: You cannot add static entries to the IP forwarding cache, although you can increase the number of entries the cache can contain. See the section “Displaying and Modifying System Parameter Default Settings” on page 4-8.

To increase the size of the IP forwarding cache, see the section “Displaying and Modifying System Parameter

Default Settings” on page 4-8.

Layer 4 Session Table

The Layer 4 session provides a fast path for forwarding packets. A session is an entry that contains complete

Layer 3 and Layer 4 information for a flow of traffic. Layer 3 information includes the source and destination IP addresses. Layer 4 information includes the source and destination TCP and UDP ports. For comparison, the IP forwarding cache contains the Layer 3 destination address but does not contain the other source and destination address information of a Layer 4 session table entry.

The Layer 2 Switch or Layer 3 Switch selects the session table instead of the IP forwarding table for fast-path forwarding for the following features:

• Layer 4 Quality-of-Service (QoS) policies

• IP access policies

To increase the size of the session table, see the section “Displaying and Modifying System Parameter Default

Settings” on page 4-8. The ip-qos-session parameter controls the size of the session table.

IP Route Exchange Protocols

Foundry Layer 3 Switches support the following IP route exchange prot