ExtremeWare Software User Guide

Software Version 7.1.0

Extreme Networks, Inc. 3585 Monroe Street Santa Clara, California 95051 (888) 257-3000 http://www.extremenetworks.com
Published: October 17, 2003 Part number: 100049-00 Rev 09

2003 Extreme Networks, Inc. All rights reserved. Extreme Networks, ExtremeWare and BlackDiamond are registered trademarks of Extreme Networks, Inc. in the United States and certain other jurisdictions. ExtremeWare Vista, ExtremeWorks, ExtremeAssist, ExtremeAssist1, ExtremeAssist2, PartnerAssist, Extreme Standby Router Protocol, ESRP, SmartTraps, Alpine, Summit, Summit1, Summit4, Summit4/FX, Summit7i, Summit24, Summit48, Summit Virtual Chassis, SummitLink, SummitGbX, SummitRPS and the Extreme Networks logo are trademarks of Extreme Networks, Inc., which may be registered or pending registration in certain jurisdictions. The Extreme Turbodrive logo is a service mark of Extreme Networks, which may be registered or pending registration in certain jurisdictions. Specifications are subject to change without notice. NetWare and Novell are registered trademarks of Novell, Inc. Merit is a registered trademark of Merit Network, Inc. Solaris is a trademark of Sun Microsystems, Inc. F5, BIG/ip, and 3DNS are registered trademarks of F5 Networks, Inc. see/IT is a trademark of F5 Networks, Inc. Data Fellows, the triangle symbol, and Data Fellows product names and symbols/logos are trademarks of Data Fellows. F-Secure SSH is a registered trademark of Data Fellows.

All other registered trademarks, trademarks and service marks are property of their respective owners.

Authors: Hugh Bussell, Julie Laccabue, Megan Mahar, Richard Small Production: Hugh Bussell

Contents

Preface
Introduction Terminology Conventions Related Publications 25 26 26 26

Part 1
Chapter 1

Using ExtremeWare
ExtremeWare Overview
Summary of Features Virtual LANs (VLANs) Spanning Tree Protocol Quality of Service Unicast Routing IP Multicast Routing Load Sharing Software Licensing Router Licensing Security Licensing Software Factory Defaults 31 32 33 33 33 34 34 34 34 36 36

Chapter 2

Accessing the Switch

Understanding the Command Syntax Syntax Helper Command Shortcuts Modular Switch Numerical Ranges Stand-alone Switch Numerical Ranges Names Symbols 39 40 40 41 41 41 42

ExtremeWare 7.1.0 Software User Guide

Contents

Limits Line-Editing Keys Command History Common Commands Configuring Management Access User Account Administrator Account Default Accounts Creating a Management Account Domain Name Service Client Services Checking Basic Connectivity Ping Traceroute

42 42 43 43 45 45 46 46 47 48 48 49 49

Chapter 3

Managing the Switch

Overview Using the Console Interface Using the 10/100 Ethernet Management Port Using Telnet Connecting to Another Host Using Telnet Configuring Switch IP Parameters Disconnecting a Telnet Session Controlling Telnet Access Using Secure Shell 2 (SSH2) Using ExtremeWare Vista Controlling Web Access Setting Up Your Browser Accessing ExtremeWare Vista Navigating ExtremeWare Vista Saving Changes Filtering Information Do a GET When Configuring a VLAN Sending Screen Output to Extreme Networks Using SNMP Enabling and Disabling SNMPv1/v2c and SNMPv3 Accessing Switch Agents Supported MIBs Configuring SNMPv1/v2c Settings Displaying SNMP Settings SNMP Trap Groups SNMPv3 51 52 52 53 53 53 55 55 56 56 57 57 58 58 60 60 60 61 61 61 62 62 62 63 63 65

ExtremeWare 7.1.0 Software User Guide

Contents

SNMPv3 Overview Message Processing SNMPv3 Security MIB Access Control Notification Authenticating Users RADIUS Client TACACS+ Configuring RADIUS Client and TACACS+ Using Network Login Using the Simple Network Time Protocol Configuring and Using SNTP SNTP Example

66 66 67 69 70 72 72 73 73 73 73 73 77

Chapter 4

Configuring Slots and Ports on a Switch

Configuring a Slot on a Modular Switch Mode of Operation (Alpine 3802) Configuring Ports on a Switch Enabling and Disabling Switch Ports Configuring Switch Port Speed and Duplex Setting Configuring Link Detection Configuring Interpacket Gap for 10 Gigabit Ethernet Ports Jumbo Frames Enabling Jumbo Frames Path MTU Discovery IP Fragmentation with Jumbo Frames IP Fragmentation within a VLAN Load Sharing on the Switch Dynamic Versus Static Load Sharing Load-Sharing Algorithms Configuring Switch Load Sharing Load-Sharing Examples Verifying the Load-Sharing Configuration Performance Enhancements for Load Sharing Switch Port-Mirroring Modular Switch Port-Mirroring Example Stand-alone Switch Port-Mirroring Example Extreme Discovery Protocol Software-Controlled Redundant Port and Smart Redundancy Software-Controlled Redundant Load-Shared Port Groups Limitations of Software-Controlled Redundant Ports and Port Groups Configuring Software-Controlled Redundant Ports 79 80 81 81 81 83 83 84 84 84 85 85 86 86 86 87 89 90 90 90 91 91 91 92 94 94 94

ExtremeWare 7.1.0 Software User Guide

Contents

Configuring Software-Controlled Redundant Load-Shared Port Groups

95

Chapter 5

Virtual LANs (VLANs)

Overview of Virtual LANs Benefits Types of VLANs Port-Based VLANs Tagged VLANs Protocol-Based VLANs Precedence of Tagged Packets Over Protocol Filters VLAN Names Default VLAN Renaming a VLAN Configuring VLANs on the Switch VLAN Configuration Examples Displaying VLAN Settings Displaying VLAN Statistics Displaying VLAN Statistics Per Port Displaying Protocol Information VLAN Tunneling (VMANs) MAC-Based VLANs MAC-Based VLAN Guidelines MAC-Based VLAN Limitations MAC-Based VLAN Example Timed Configuration Download for MAC-Based VLANs VLAN Translation VLAN Translation Behavior VLAN Translation Limitations and Notes VLAN Translation Configuration Examples 97 97 98 98 100 103 105 106 106 106 107 107 108 109 109 110 110 112 112 113 113 113 115 116 116 117

Chapter 6

Forwarding Database (FDB)

Overview of the FDB FDB Contents How FDB Entries Get Added FDB Entry Types Disabling MAC Address Learning Associating QoS Profiles with an FDB Entry Scanning the FDB Enabling FDB Scanning Disabling FDB Scanning Configuring the FDB Scan Interval Displaying FDB Scan Statistics 123 123 123 124 125 126 126 127 127 127 128

ExtremeWare 7.1.0 Software User Guide

Contents

FDB Configuration Examples MAC-Based Security Displaying FDB Entries

128 129 130

Chapter 7

Quality of Service (QoS)

Overview of Policy-Based Quality of Service Applications and Types of QoS Voice Applications Video Applications Critical Database Applications Web Browsing Applications File Server Applications Configuring QoS QoS Profiles Traffic Groupings IP-Based Traffic Groupings MAC-Based Traffic Groupings Explicit Class of Service (802.1p and DiffServ) Traffic Groupings Configuring DiffServ Physical and Logical Groupings Configuring QoS Traffic Grouping Priorities Verifying and Resetting QoS Traffic Grouping Priorities Verifying Configuration and Performance QoS Monitor Displaying QoS Profile Information Modifying a QoS Configuration Bi-Directional Rate Shaping Configuring Bi-Directional Rate Shaping Bandwidth Settings Bi-Directional Rate Shaping Limitations Dynamic Link Context System DLCS Guidelines DLCS Limitations 132 132 133 133 133 133 134 134 135 136 136 137 138 140 143 144 145 145 145 146 146 146 147 147 149 149 149 150

Chapter 8

Network Address Translation (NAT)

Overview Internet IP Addressing Configuring VLANs for NAT NAT Modes Configuring NAT 151 152 152 153 154

ExtremeWare 7.1.0 Software User Guide

Contents

Creating NAT Rules Creating Static and Dynamic NAT Rules Creating Portmap NAT Rules Creating Auto-Constrain NAT Rules Advanced Rule Matching Configuring Time-outs Displaying NAT Settings Disabling NAT

154 154 155 155 156 156 156 157

Chapter 9

Server Load Balancing (SLB)

Overview SLB Components Nodes Pools Virtual Servers Node, Pool, and Virtual Server Relationships SLB Traffic Types Forwarding Modes Transparent Mode Translation Mode Port Translation Mode GoGo Mode Load-Balancing Methods Round-Robin Ratio Least Connections Priority Advanced SLB Application Example Using Persistence Persistence Methods Persistence Levels Persistence Types Using High Availability System Features Server Load Balancing with ESRP Active-Active Operation Health Checking Ping-Check TCP-Port-Check Service-Check 3DNS Health Checking Maintenance Mode Health Checking in GoGo Mode 159 160 160 161 161 162 163 164 164 166 167 168 169 169 169 170 170 170 173 173 174 175 176 176 178 181 182 182 182 183 183 183

ExtremeWare 7.1.0 Software User Guide

Contents

Flow Redirection Web Cache Redirection Policy-Based Routing

184 185 187

Chapter 10

Status Monitoring and Statistics

Status Monitoring Slot Diagnostics Runtime Diagnostics (BlackDiamond Switches) Packet Memory Scanning (BlackDiamond Switches) Port Statistics Port Errors Port Monitoring Display Keys System Temperature System Health Checking Checking the Integrity of the FDB Testing the Transceivers Setting the System Recovery Level Event Management System/Logging Sending Event Messages to Log Targets Filtering Events Sent to Targets Formatting Event Messages Displaying Real-Time Log Messages Displaying Events Logs Uploading Events Logs Displaying Counts of Event Occurrences Displaying Debug Information Compatibility with previous ExtremeWare commands Logging Configuration Changes Configuring and Monitoring Flow Statistics Flow Statistics Background Information Collection Port and Filtering Options Collection Architecture Scalability and Reliability Export Criteria RMON About RMON RMON Features of the Switch Configuring RMON Event Actions 189 190 190 191 192 193 194 194 195 196 197 200 200 200 201 208 208 209 209 210 210 211 212 212 213 215 215 216 221 221 221 222 223

Chapter 11

Security
Security Overview 225

ExtremeWare 7.1.0 Software User Guide

Contents

Network Access Security MAC-Based VLANs IP Access Lists (ACLs) Using IP Access Lists How IP Access Lists Work Precedence Numbers IP Access Rules The permit-established Keyword Adding and Deleting Access List Entries Verifying Access List Configurations IP Access List Examples MAC Address Security Limiting Dynamic MAC Addresses MAC Address Lock Down Network Login Web-Based and 802.1x Authentication Campus and ISP Modes Interoperability Requirements Multiple supplicant support Exclusions and Limitations Configuring Network Login Web-Based Authentication User Login Using Campus Mode DHCP Server on the Switch Displaying DHCP Information Displaying Network Login Settings Disabling Network Login Additional Configuration Details Switch Protection Routing Access Profiles Using Routing Access Profiles Creating an Access Profile Configuring an Access Profile Mode Adding an Access Profile Entry Deleting an Access Profile Entry Applying Access Profiles Routing Profiles for RIP Routing Access Profiles for IPX Routing Access Profiles for OSPF Routing Access Profiles for DVMRP Routing Access Profiles for PIM Routing Access Profiles for BGP Making Changes to a Routing Access Policy Removing a Routing Access Policy

225 226 226 226 226 227 227 228 229 229 229 233 233 235 236 236 238 239 239 240 240 242 243 244 244 244 244 245 245 245 246 246 246 249 249 249 250 251 252 253 254 254 255

10

ExtremeWare 7.1.0 Software User Guide

Contents

Route Maps Using Route Maps Creating a Route Map Add Entries to the Route Map Add Statements to the Route Map Entries Route Map Operation Changes to Route Maps Route Maps in BGP Denial of Service Protection Configuring Denial of Service Protection Enabling Denial of Service Protection Disabling Denial of Service Protection Displaying Denial of Service Settings How to Deploy DoS Protection Blocking SQL Slammer DoS Attacks Management Access Security Authenticating Users Using RADIUS or TACACS+ RADIUS Client Configuring TACACS+ Secure Shell 2 (SSH2) Enabling SSH2 for Inbound Switch Access Using SCP2 from an External SSH2 Client SSH2 Client Functions on the Switch

255 255 255 255 256 258 259 259 260 260 261 261 261 261 262 263 263 263 269 270 270 271 272

Part 2
Chapter 12

Using Switching and Routing Protocols

Ethernet Automatic Protection Switching
Overview of the EAPS Protocol EAPS Terms Fault Detection and Recovery Link Down Message Sent by a Transit Node Ring Port Down Event Sent by Hardware Layer Polling Restoration Operations Multiple EAPS Domains Per Switch Multiple EAPS Rings Sharing Common Links Configuring EAPS on a Switch Creating and Deleting an EAPS Domain Defining the EAPS Mode of the Switch Configuring EAPS Polling Timers Configuring the Primary and Secondary Ports 275 277 278 279 279 279 279 280 281 282 282 282 282 284

ExtremeWare 7.1.0 Software User Guide

11

Contents

Configuring the EAPS Control VLAN Configuring the EAPS Protected VLANs Enabling and Disabling an EAPS Domain Enabling and Disabling EAPS Unconfiguring an EAPS Ring Port Displaying EAPS Status Information Configuring EAPS Shared Ports Steady State Common Link Failures Creating and Deleting a Shared Port Defining the Mode of the Shared Port Configuring the Link ID of the Shared Port Unconfiguring an EAPS Shared Port Displaying EAPS Shared-Port Status Information EAPS Shared Port Configuration Rules EAPS Shared Port Configuration Examples Basic Configuration Basic Core Configuration Right Angle Configuration Combined Basic Core and Right Angle Configuration Large Core and Access Rings Configuration Advanced Configuration

284 285 285 285 286 286 289 290 290 291 291 292 292 292 293 293 293 294 294 295 295 296

Chapter 13

Spanning Tree Protocol (STP)

Overview of the Spanning Tree Protocol Spanning Tree Domains STPD Modes Port Modes STPD BPDU Tunneling Rapid Root Failover STP Configurations Basic STP Configuration Multiple STPDs on a Port VLAN Spanning Multiple STPDs EMISTP Deployment Constraints Per-VLAN Spanning Tree STPD VLAN Mapping Native VLAN Rapid Spanning Tree Protocol RSTP Terms RSTP Concepts RSTP Operation STP Rules and Restrictions 297 298 298 299 299 299 300 300 303 303 304 306 306 306 306 307 307 310 317

12

ExtremeWare 7.1.0 Software User Guide

Contents

Configuring STP on the Switch STP Configuration Examples Displaying STP Settings

317 318 321

Chapter 14

Extreme Standby Router Protocol

Overview of ESRP Reasons to Use ESRP ESRP Terms ESRP Concepts ESRP-Aware Switches Linking ESRP Switches Determining the ESRP Master Master Switch Behavior Pre-Master Switch Behavior Slave Switch Behavior Electing the Master Switch Failover Time ESRP Election Algorithms Advanced ESRP Features ESRP Tracking ESRP Port Restart ESRP and VLAN Aggregation ESRP Host Attach ESRP Dont Count ESRP Domains ESRP Groups Selective Forwarding Displaying ESRP Information Using ELRP with ESRP ELRP Terms Using ELRP with ESRP to Recover Loops Configuring ELRP Displaying ELRP Information ESRP Examples Single VLAN Using Layer 2 and Layer 3 Redundancy Multiple VLANs Using Layer 2 Redundancy ESRP Cautions Configuring ESRP and Multinetting ESRP and Spanning Tree 323 323 324 325 325 326 326 327 327 327 327 328 328 329 329 333 334 334 335 335 336 337 338 339 339 340 340 342 342 342 344 345 345 345

Chapter 15

Virtual Router Redundancy Protocol

Overview 347

ExtremeWare 7.1.0 Software User Guide

13

Contents

Determining the VRRP Master VRRP Tracking Electing the Master Router Additional VRRP Highlights VRRP Port Restart VRRP Operation Simple VRRP Network Configuration Fully-Redundant VRRP Network VRRP Configuration Parameters VRRP Examples Configuring the Simple VRRP Network Configuring the Fully-Redundant VRRP Network

348 348 351 351 352 352 352 353 354 356 356 357

Chapter 16

IP Unicast Routing
Overview of IP Unicast Routing Router Interfaces Populating the Routing Table Subnet-Directed Broadcast Forwarding Proxy ARP ARP-Incapable Devices Proxy ARP Between Subnets Relative Route Priorities Configuring IP Unicast Routing Verifying the IP Unicast Routing Configuration Routing Configuration Example IP Multinetting IP Multinetting Operation IP Multinetting Examples Configuring DHCP/BOOTP Relay Verifying the DHCP/BOOTP Relay Configuration UDP-Forwarding Configuring UDP-Forwarding UDP-Forwarding Example ICMP Packet Processing UDP Echo Server VLAN Aggregation VLAN Aggregation Properties VLAN Aggregation Limitations VLAN Aggregation SubVLAN Address Range Checking Isolation Option for Communication Between Sub-VLANs VLAN Aggregation Example 359 360 361 362 363 363 364 364 365 365 365 367 368 369 370 370 370 371 371 371 372 372 374 374 374 375 375

14

ExtremeWare 7.1.0 Software User Guide

Contents

Verifying the VLAN Aggregation Configuration

375

Chapter 17

Interior Gateway Protocols

Overview RIP Versus Either OSPF or IS-IS Overview of RIP Routing Table Split Horizon Poison Reverse Triggered Updates Route Advertisement of VLANs RIP Version 1 Versus RIP Version 2 Overview of OSPF Link-State Database Areas Point-to-Point Support Route Re-Distribution Configuring Route Re-Distribution OSPF Timers and Authentication RIP Configuration Example Configuring OSPF Configuring OSPF Wait Interval OSPF Configuration Example Configuration for ABR1 Configuration for IR1 Displaying OSPF Settings OSPF LSDB Display Overview of IS-IS Overview of Integrated IS-IS Implementing IS-IS Routing Authentication Summarizing Level 1 IP Routing Information Filtering Level 1 IP Routing Information External Route Redistribution Originating Default Route Overload Bit Metric Size Default Routes to Nearest Level 1/2 Switch for Level 1 Only Switches 378 378 379 379 379 379 379 380 380 380 380 382 385 385 386 388 388 390 390 391 392 392 393 393 394 394 395 396 397 397 397 397 397 398 398

Chapter 18

Exterior Gateway Routing Protocols

Overview 401

ExtremeWare 7.1.0 Software User Guide

15

Contents

BGP Attributes BGP Communities BGP Features Route Reflectors Route Confederations Route Aggregation IGP Synchronization Using the Loopback Interface BGP Peer Groups BGP Route Flap Dampening BGP Route Selection Stripping Out Private AS Numbers from Route Updates Route Re-Distribution Configuring Route Re-Distribution

402 402 402 403 403 406 407 407 407 408 411 411 411 412

Chapter 19

IP Multicast Routing
Overview DVMRP Overview PIM Overview IGMP Overview Multicast Tools Performance Enhancements for the BlackDiamond Switch Configuring IP Multicasting Routing Configuration Examples PIM-DM Configuration Example Configuration for IR1 Configuration for ABR1 413 414 414 415 416 417 418 419 419 420 421

Chapter 20

IPX Routing
Overview of IPX Router Interfaces IPX Routing Performance IPX Load Sharing IPX Encapsulation Types Tagged IPX VLANs Populating the Routing Table IPX/RIP Routing Routing SAP Advertisements Configuring IPX Verifying IPX Router Configuration Protocol-Based VLANs for IPX IPX Configuration Example 423 423 424 425 425 425 426 426 427 427 428 428 429

16

ExtremeWare 7.1.0 Software User Guide

Contents

Part 3
Chapter 21

Configuring Modules
Accounting and Routing Module (ARM)
Summary of Features ARM Module Limitations About IP Unicast Forwarding About Selective Longest Prefix Match About Destination-Sensitive Accounting Configuring the ARM Basic Accounting Configuration Information Basic SLPM Configuration Information Configuring Access Profiles Using Route Maps ARM Configuration Examples Configuring Destination-Sensitive Accounting Based on Destination IP Subnets Configuring Destination-Sensitive Accounting Based on BGP Community Strings Configuring Routing Using SLPM Retrieving Accounting Statistics Using the CLI to Retrieve Accounting Statistics Using SNMP to Retrieve Accounting Statistics Diagnostics Commands Layer 2 and Layer 3 Switching Attributes Debug Trace Commands 433 434 434 434 436 437 437 439 441 441 443 443 447 449 452 452 453 453 454 454 455

Chapter 22

Asynchronous Transfer Mode (ATM) Module

About the ATM Module Feature Summary Function Summary Configuring the ATM Module Basic ATM Module Configuration Information Configuring and Monitoring ATM Ports Configuring PVCs Deleting PVCs Displaying ATM Port Status Information Displaying PVC Status Information Configuring ATM Scrambling Configuring and Monitoring SONET SONET Parameters and Values Configuring SONET Framing Configuring SONET Clocking 457 458 458 460 460 465 465 465 466 467 467 468 468 469 469

ExtremeWare 7.1.0 Software User Guide

17

Contents

Configuring the Signal Fail Threshold Configuring the Signal Degrade Threshold Configuring the Section Trace Identifier Configuring the Path Trace Identifier Configuring the Signal Label Resetting SONET Configuration Parameter Values Displaying SONET Status Information on ATM ports SONET Events on ATM Ports Configuring VLAN-Related Attributes Configuring Tagged VLAN 802.1p and 802.1Q Functions Generic VLAN Registration Protocol Functions Configuring Forwarding Database Attributes Configuring Spanning Tree Attributes Configuring QoS Functions Configuring a QoS Profile Classification and Replacement Policies Configuring DiffServ Enhanced RED Support QoS Monitor Intra-Subnet QoS Limitations and Unsupported Features Configuring Port Attributes Jumbo Frame Support Configuring IGMP Attributes Configuring Layer 2 and 3 Switching Attributes Configuring Access List Attributes Changing Image and Configuration Attributes

469 470 470 471 471 472 472 473 474 475 477 477 477 477 478 479 480 482 488 488 489 489 489 490 490 490 490

Chapter 23

Packet Over SONET (PoS) Modules

About the PoS Modules Summary of Features Function Summary Service Provider Features Configuring the PoS Module Basic PoS Module Configuration Information Default PoS Module Configurations PoS Port Configuration and Default VLAN Assignments Default Configuration: Bridging Over PoS Ports Routing Over PoS Ports Automatic Protection Switching Configuring and Monitoring SONET Ports Configuring SONET Framing Configuring SONET Loopback (OC12) 491 492 493 494 496 497 497 497 498 499 501 504 504 504

18

ExtremeWare 7.1.0 Software User Guide

Contents

Configuring SONET Clocking Configuring the Signal Fail Threshold Configuring the Signal Degrade Threshold Configuring the Section Trace Identifier Configuring the Path Trace Identifier Configuring the Signal Label Resetting SONET Configuration Parameter Values Displaying SONET Port Status Information SONET Events Configuring and Monitoring PPP Functions PPP Overview Creating a PPP User Account Configuring the PoS Checksum Configuring PoS Scrambling Configuring Link Maintenance Configuring PPP Link Quality Monitoring Configuring PPP Authentication Configuring the Name and Password for the Port Creating an Authentication Database Entry Configuring the Network Control Protocol Configuring the MPLS Control Protocol Configuring the OSI Network Layer Control Protocol Configuring the Delayed-Down-Time Interval Displaying PPP Information Resetting PPP Configuration Parameter Values Configuring VLAN-Related Attributes Configuring Tagged VLAN 802.1p and 802.1Q Functions Generic VLAN Registration Protocol Functions Configuring Forwarding Database Attributes Configuring Spanning Tree Attributes Configuring QoS Functions Configuring a QoS Profile Classification and Replacement Policies Configuring DiffServ Enhanced RED Support QoS Monitor Intra-Subnet QoS Configuring and Monitoring Flow Statistics Flow Statistics Background Information Collection Port and Filtering Options Collection Architecture Scalability and Reliability Export Criteria MIB Support for Flow Statistics Configuring and Monitoring APS Functions

505 505 505 506 506 507 507 507 508 510 510 514 514 514 515 515 516 516 517 518 519 519 520 520 521 522 522 525 525 525 525 525 526 527 530 536 536 536 537 539 539 540 546 546

ExtremeWare 7.1.0 Software User Guide

19

Contents

APS Network Configuration Options Sample Line-Switching Scenario APS Benefits Enabling and Disabling APS Creating and Deleting an APS Group Adding a Port to an APS Group Deleting a Port from an APS Group Configuring APS Authentication Configuring Nonrevertive or Revertive Mode Configuring APS Timers Configuring APS Lockout Configuring Forced Switch Mode Configuring Manual Switch Mode Resetting APS Group Configuration Parameters Displaying APS Group Status Information MIB Support for APS Configuring Port Tunneling Configuring the PoS Port Tunnel Configuring the Ethernet Module Configuring the MPLS tls-Tunnel Limitations and Unsupported Commands Configuring General Switch Attributes PoS Module Limitations Configuring Port Attributes Jumbo Frame Support Configuring Access List Attributes Changing Image and Configuration Attributes

548 550 553 556 556 556 557 557 558 559 559 560 561 561 562 563 563 564 565 565 565 566 566 566 566 568 568

Chapter 24

T1, E1, and T3 WAN Modules

Overview Red, Blue, and Yellow Alarms Configuring WAN Physical Links Cable Length Clock Source Facility Data Link Framing Inband Loopback Detection Linecoding Receiver Gain SNMP Alerts Timeslots Yellow Alarms Monitoring WAN Physical Links Loopback 569 570 570 571 571 571 572 572 572 572 573 574 574 574 574

20

ExtremeWare 7.1.0 Software User Guide

Contents

Configuring PPP and MLPPP Multilink PPP and Multilink Groups Configuring a PPP/MLPPP Link WAN Multilink Configuration Examples Configuring a Bridged PPP/MLPPP Link Example Configuring a Routed PPP/MLPPP Link Example VLAN Tunneling (VMANs) VMAN Transport by WAN Links VMAN Termination at WAN ports

578 579 579 581 581 582 583 584 585

Chapter 25

MultiProtocol Label Switching (MPLS) Module

About MPLS Overview of MPLS MPLS Layer About MPLS Layer-2 VPNs About IP Unicast Forwarding About Destination-Sensitive Accounting About the MPLS Module Summary of Features Configuring the MPLS Module Configuring MPLS Interfaces Configuring the Propagation of IP TTL Configuring Penultimate Hop Popping Configuring QoS Mappings Resetting MPLS Configuration Parameter Values Displaying MPLS Configuration Information Configuring the Label Distribution Protocol (LDP) Overview of LDP Configuring LDP MPLS and IP Routing Routing Using LSPs LSPs and IBGP Next Hops Optimized Forwarding of Non-MPLS IP Traffic Configuration Example MPLS Configuration Constraints 587 588 592 595 596 596 597 597 598 598 599 599 600 601 601 603 604 604 608 608 611 611 612 614

Chapter 26

Configuring RSVP-TE
RSVP Elements Message Types Reservation Styles Bandwidth Reservation Traffic Engineering 616 616 618 618 620

ExtremeWare 7.1.0 Software User Guide

21

Contents

RSVP Tunneling RSVP Objects RSVP Features Route Recording Explicit Route Path LSPs Redundant LSPs Improving LSP Scaling Configuring RSVP-TE Configuring RSVP-TE on a VLAN Configuring RSVP-TE Protocol Parameters Configuring an RSVP-TE Path Configuring an Explicit Route Configuring an RSVP-TE Profile Configuring an Existing RSVP-TE Profile Configuring an RSVP-TE LSP Adding a Path to an RSVP-TE LSP Displaying RSVP-TE LSP Configuration Information Displaying the RSVP-TE Routed Path Displaying the RSVP-TE Path Profile Displaying the RSVP-TE LSP Configuration Example

620 620 621 621 622 622 623 624 624 624 625 626 627 628 628 629 629 630 630 630 630

Chapter 27

Configuring MPLS Layer-2 VPNs

Overview of MPLS Layer-2 VPNs Layer-2 VPN Services MPLS VC Tunnels Layer-2 VPN Domains MAC Learning Spanning Tree Protocols TLS VPN Characteristics Configuring MPLS Layer-2 VPNs Adding a TLS Tunnel Deleting a TLS Tunnel Displaying TLS Configuration Information TLS VPN Configuration Examples Basic MPLS TLS Configuration Example Full Mesh TLS Configuration Hub and Spoke TLS Configuration Configuration Example Using PPP Transparent Mode Using ESRP with MPLS TLS Tunnel Endpoint VLANs LSP Tracking Configuration Example 635 635 636 637 637 637 638 638 638 640 640 642 642 643 644 645 646 647 648 649

22

ExtremeWare 7.1.0 Software User Guide

Contents

Chapter 28

High Density Gigabit Ethernet Module

About the High Density Gigabit Ethernet Module Alpine High Density Gigabit Ethernet Modules BlackDiamond High Density Gigabit Ethernet Modules Summary of Features Summary of Functions Configuring the High Density Gigabit Ethernet Module Configuring Flow Control Configuring VLANs Configuring Ingress QoS Functions Configuring DiffServ Configuring Rate Limiting on Egress Ports Displaying Statistics Configuration Examples Configuring Ingress Rate Limiting Configuring Bandwidth Requirements for Multiple Types of Traffic 651 652 652 653 654 655 655 655 656 658 660 661 662 662 663

Part 4
Appendix A

Appendixes
Software Upgrade and Boot Options
Downloading a New Image Selecting a Primary or a Secondary Image Downloading Images to Slots and Modules Understanding the Image Version String Software Signatures Rebooting the Switch Rebooting a Module Saving Configuration Changes Returning to Factory Defaults Using TFTP to Upload the Configuration Using TFTP to Download the Configuration Downloading a Complete Configuration Downloading an Incremental Configuration Scheduled Incremental Configuration Download Remember to Save Synchronizing MSMs Upgrading and Accessing BootROM Upgrading BootROM Accessing the BootROM Menu 667 668 668 669 670 670 671 671 672 672 673 673 673 674 674 674 675 675 675

Appendix B

Troubleshooting

ExtremeWare 7.1.0 Software User Guide

23

Contents

LEDs Using the Command-Line Interface Port Configuration VLANs STP Debug Tracing/Debug Mode TOP Command System Health Check System Memory Dump System Odometer Memory Scanning and Memory Mapping Modes of Operation Memory Scanning and Memory Mapping Functions Using Memory Scanning to Screen I/O Modules Reboot Loop Protection Minimal Mode Contacting Extreme Technical Support

677 678 680 680 681 682 682 683 683 684 685 685 686 692 693 693 694

Appendix C

Supported Protocols, MIBs, and Standards Index

24

ExtremeWare 7.1.0 Software User Guide

Preface

This preface provides an overview of this guide, describes guide conventions, and lists other publications that might be useful.

Introduction
This guide provides the required information to configure ExtremeWare software running on either modular or stand-alone switches from Extreme Networks. This guide is intended for use by network administrators who are responsible for installing and setting up network equipment. It assumes a basic working knowledge of: Local area networks (LANs) Ethernet concepts Ethernet switching and bridging concepts Routing concepts Internet Protocol (IP) concepts Routing Information Protocol (RIP) and Open Shortest Path First (OSPF). Border Gateway Protocol (BGP-4) concepts IP Multicast concepts Distance Vector Multicast Routing Protocol (DVMRP) concepts Protocol Independent Multicast (PIM) concepts Internet Packet Exchange (IPX) concepts Server Load Balancing (SLB) concepts Simple Network Management Protocol (SNMP) NOTE If the information in the release notes shipped with your switch differs from the information in this guide, follow the release notes.

ExtremeWare 7.1.0 Software User Guide

25

Preface

Terminology
When features, functionality, or operation is specific to a modular or stand-alone switch family, the family name is used. Explanations about features and operations that are the same across all product families simply refer to the product as the switch.

Conventions
Table 1 and Table 2 list conventions that are used throughout this guide. Table 1: Notice Icons
Icon Notice Type Note Alerts you to... Important features or instructions.

Caution

Risk of personal injury, system damage, or loss of data.

Warning

Risk of severe personal injury.

Table 2: Text Conventions

Convention Screen displays The words enter and type [Key] names Description This typeface indicates command syntax, or represents information as it appears on the screen. When you see the word enter in this guide, you must type something, and then press the Return or Enter key. Do not press the Return or Enter key when an instruction simply says type. Key names are written with brackets, such as [Return] or [Esc]. If you must press two or more keys simultaneously, the key names are linked with a plus sign (+). Example: Press [Ctrl]+[Alt]+[Del]. Words in italicized type Italics emphasize a point or denote new terms at the place where they are defined in the text.

Related Publications
The publications related to this one are: ExtremeWare release notes ExtremeWare 7.1.0 Software Command Reference Guide ExtremeWare 7.1.0 Software Quick Reference Guide Extreme Networks Consolidated Hardware Guide

26

ExtremeWare 7.1.0 Software User Guide

Related Publications

Documentation for Extreme Networks products is available on the World Wide Web at the following location: http://www.extremenetworks.com/

ExtremeWare 7.1.0 Software User Guide

27

Preface

28

ExtremeWare 7.1.0 Software User Guide

Part 1

Using ExtremeWare

ExtremeWare Overview

This chapter covers the following topics: Summary of Features on page 31 Software Licensing on page 34 Software Factory Defaults on page 36 ExtremeWare is the full-featured software operating system that is designed to run on the Extreme Networks families of modular and stand-alone Gigabit Ethernet switches.

NOTE ExtremeWare 7.1.0 only supports Extreme Networks products that contain the i or t series chipset. This includes the BlackDiamond, Alpine, and Summit i series platforms, but does not include the Summit 24e3 and Summit 200 series platforms.

Summary of Features
The features of ExtremeWare include: Virtual local area networks (VLANs) including support for IEEE 802.1Q and IEEE 802.1p VLAN aggregation Spanning Tree Protocol (STP) (IEEE 802.1D) with multiple STP domains Policy-Based Quality of Service (PB-QoS) Wire-speed Internet Protocol (IP) routing IP Multinetting DHCP/BOOTP Relay Extreme Standby Router Protocol (ESRP) Virtual Router Redundancy Protocol (VRRP) Routing Information Protocol (RIP) version 1 and RIP version 2 Open Shortest Path First (OSPF) routing protocol Border Gateway Protocol (BGP) version 4

ExtremeWare 7.1.0 Software User Guide

31

ExtremeWare Overview

Wire-speed IP multicast routing support Diffserv support Access-policy support for routing protocols Access list support for packet filtering IGMP snooping to control IP multicast traffic Distance Vector Multicast Routing Protocol (DVMRP) Protocol Independent Multicast-Dense Mode (PIM-DM) Protocol Independent Multicast-Sparse Mode (PIM-SM) Wire-speed IPX, IPX/RIP, and IPX/SAP support Server Load Balancing (SLB) support Load sharing on multiple ports, across all blades (modular switches only) RADIUS client and per-command authentication support TACACS+ support Console command line interface (CLI) connection Telnet CLI connection SSH2 connection ExtremeWare Vista Web-based management interface Simple Network Management Protocol (SNMP) support Remote Monitoring (RMON) System Monitoring (SMON) Traffic mirroring Network Login support Accounting and Routing Module (ARM) support Asynchronous Transfer Mode Module (ATM) support Packet over SONET (PoS) Module support WAN Module support MultiProtocol Label Switching (MPLS) support Destination-Sensitive Accounting (DSA) support NOTE For more information on Extreme Networks switch components (the BlackDiamond 6800 family, the Alpine 3800 family, or the Summit switch family), see the Extreme Networks Consolidated Hardware Guide.

Virtual LANs (VLANs)

ExtremeWare has a VLAN feature that enables you to construct your broadcast domains without being restricted by physical connections. A VLAN is a group of location- and topology-independent devices that communicate as if they were on the same physical local area network (LAN). Implementing VLANs on your network has the following three advantages:

32

ExtremeWare 7.1.0 Software User Guide

Summary of Features

VLANs help to control broadcast traffic. If a device in VLAN Marketing transmits a broadcast frame, only VLAN Marketing devices receive the frame. VLANs provide extra security. Devices in VLAN Marketing can only communicate with devices on VLAN Sales using routing services. VLANs ease the change and movement of devices on networks. NOTE For more information on VLANs, see Chapter 5.

Spanning Tree Protocol

The switch supports the IEEE 802.1D Spanning Tree Protocol (STP), which is a bridge-based mechanism for providing fault tolerance on networks. STP enables you to implement parallel paths for network traffic, and ensure that: Redundant paths are disabled when the main paths are operational. Redundant paths are enabled if the main traffic paths fail. A single spanning tree can span multiple VLANs.

NOTE For more information on STP, see Chapter 13.

Quality of Service
ExtremeWare has Policy-Based Quality of Service (QoS) features that enable you to specify service levels for different traffic groups. By default, all traffic is assigned the normal QoS policy profile. If needed, you can create other QoS policies and apply them to different traffic types so that they have different guaranteed minimum bandwidth, maximum bandwidth, and priority. NOTE For more information on Quality of Service, see Chapter 7.

Unicast Routing
The switch can route IP or IPX traffic between the VLANs that are configured as virtual router interfaces. Both dynamic and static IP routes are maintained in the routing table. The following routing protocols are supported: RIP version 1 RIP version 2 OSPF version 2 IS-IS IPX/RIP BGP version 4

ExtremeWare 7.1.0 Software User Guide

33

ExtremeWare Overview

NOTE For more information on IP unicast routing, see Chapter 16. For more information on IPX/RIP, see Chapter 20.

IP Multicast Routing
The switch can use IP multicasting to allow a single IP host to transmit a packet to a group of IP hosts. ExtremeWare supports multicast routes that are learned by way of the Distance Vector Multicast Routing Protocol (DVMRP) or the Protocol Independent Multicast (dense mode or sparse mode). NOTE For more information on IP multicast routing, see Chapter 19.

Load Sharing
Load sharing allows you to increase bandwidth and resiliency by using a group of ports to carry traffic in parallel between systems. The load sharing algorithm allows the switch to use multiple ports as a single logical port. For example, VLANs see the load-sharing group as a single virtual port. The algorithm also guarantees packet sequencing between clients. NOTE For information on load sharing, see Chapter 4.

Software Licensing
Some Extreme Networks products have capabilities that are enabled by using a license key. Keys are typically unique to the switch, and are not transferable. Keys are stored in NVRAM and, once entered, persist through reboots, software upgrades, and reconfigurations. The following sections describe the features that are associated with license keys.

Router Licensing
Some switches support software licensing for different levels of router functionality. In ExtremeWare version 6.0 and above, routing protocol support is separated into two sets: Basic and Full L3. Basic is a subset of Full L3.

Basic Functionality
Basic functionality requires no license key. All Extreme switches have Basic layer 3 functionality, without the requirement of a license key. Basic functionality includes all switching functions, and also includes all available layer 3 QoS, access list, and ESRP functions. Layer 3 routing functions include support for: IP routing using RIP version 1 and/or RIP version 2 IP routing between directly attached VLANs IP routing using static routes

34

ExtremeWare 7.1.0 Software User Guide

Software Licensing

Network Login VRRP

Full L3 Functionality
On switches that support router licensing, the Full L3 license enables support of additional routing protocols and functions, including: IP routing using OSPF IP multicast routing using DVMRP IP multicast routing using PIM (Dense Mode or Sparse Mode) IP routing using BGP IPX routing (direct, static, and dynamic using IPX/RIP and IPX/SAP) Server load balancing Web cache redirection EAPS NAT IS-IS MPLS ARM PoS ATM

Product Support
The Summit1i switch and all BlackDiamond 6800 series switches ship with Full L3 functionality. All other Summit models and the Alpine 3800 series switches are available with either Basic or Full L3 functionality.

Verifying the Router License

To verify the router license, use the show switch command.

Obtaining a Router License

You can order the desired functionality from the factory, using the appropriate model of the desired product. If you order licensing from the factory, the switch arrives packaged with a certificate that contains the unique license key(s), and instructions for enabling the correct functionality on the switch. The certificate is typically packaged with the switch documentation. Once the license key is entered, it should not be necessary to enter the information again. However, we recommend keeping the certificate for your records. You can upgrade the router licensing of an existing product by purchasing a voucher for the desired product and functionality. Please contact your supplier to purchase a voucher. The voucher contains information and instructions on obtaining a license key for the switch using the Extreme Networks Support website at: http://www.extremenetworks.com/support/techsupport.asp

ExtremeWare 7.1.0 Software User Guide

35

ExtremeWare Overview

or by phoning Extreme Networks Technical Support at: (800) 998-2408 (408) 579-2826

Security Licensing
Certain additional ExtremeWare security features, such as the use of Secure Shell (SSH2) encryption, may be under United States export restriction control. Extreme Networks ships these security features in a disabled state. You can obtain information on enabling these features at no charge from Extreme Networks.

Obtaining a Security License

To obtain information on enabling features that require export restriction, access the Extreme Networks Support website at: http://www.extremenetworks.com/go/security.htm Fill out a contact form to indicate compliance or noncompliance with the export restrictions. If you are in compliance, you will be given information that will allow you to enable security features.

Security Features Under License Control

ExtremeWare version 6.0 and above supports the SSH2 protocol. SSH2 allows the encryption of Telnet session data between an SSH2 client and an Extreme Networks switch. ExtremeWare version 6.2.1 and later also enables the switch to function as an SSH2 client, sending encrypted data to an SSH2 server on a remote system. ExtremeWare 6.2.1 also supports the Secure Copy Protocol (SCP). The encryption methods used are under U.S. export restriction control.

Software Factory Defaults

Table 3 shows factory defaults for global ExtremeWare features. Table 3: ExtremeWare Global Factory Defaults
Item Serial or Telnet user account Web network management Telnet SSH2 SNMP SNMP read community string SNMP write community string RMON BOOTP QoS QoS monitoring 802.1p priority Default Setting admin with no password and user with no password Enabled Enabled Disabled Enabled public private Disabled Enabled on the default VLAN (default) All traffic is part of the default queue Automatic roving Recognition enabled

36

ExtremeWare 7.1.0 Software User Guide

Software Factory Defaults

Table 3: ExtremeWare Global Factory Defaults (continued)

Item 802.3x flow control Virtual LANs Default Setting Enabled on Gigabit Ethernet ports Three VLANs predefined. VLAN named default contains all ports and belongs to the STPD named s0. VLAN mgmt exists only on switches that have an Ethernet management port, and contains only that port. The Ethernet management port is DTE only, and is not capable of switching or routing. VLAN MacVLanDiscover is used only when using the MAC VLAN feature. All packets are untagged on the default VLAN (default). Disabled for the switch; enabled for each port in the STPD. 300 seconds (5 minutes) Disabled Disabled Disabled Disabled Enabled Enabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled

802.1Q tagging Spanning Tree Protocol Forwarding database aging period IP Routing RIP OSPF IP multicast routing IGMP IGMP snooping DVMRP GVRP PIM-DM IPX routing NTP DNS Port mirroring MPLS

NOTE For default settings of individual ExtremeWare features, see individual chapters in this guide.

ExtremeWare 7.1.0 Software User Guide

37

ExtremeWare Overview

38

ExtremeWare 7.1.0 Software User Guide

Accessing the Switch

This chapter covers the following topics: Understanding the Command Syntax on page 39 Line-Editing Keys on page 42 Command History on page 43 Common Commands on page 43 Configuring Management Access on page 45 Domain Name Service Client Services on page 48 Checking Basic Connectivity on page 48

Understanding the Command Syntax

This section describes the steps to take when entering a command. Refer to the sections that follow for detailed information on using the command line interface. ExtremeWare command syntax is described in detail in the ExtremeWare Software Command Reference Guide. Some commands are also described in this user guide, in order to describe how to use the features of the ExtremeWare software. However, only a subset of commands are described here, and in some cases only a subset of the options that a command supports. The ExtremeWare Software Command Reference Guide should be considered the definitive source for information on ExtremeWare commands. When entering a command at the prompt, ensure that you have the appropriate privilege level. Most configuration commands require you to have the administrator privilege level. To use the command line interface (CLI), follow these steps: 1 Enter the command name. If the command does not include a parameter or values, skip to step 3. If the command requires more information, continue to step 2. 2 If the command includes a parameter, enter the parameter name and values.

ExtremeWare 7.1.0 Software User Guide

39

Accessing the Switch

3 The value part of the command specifies how you want the parameter to be set. Values include numerics, strings, or addresses, depending on the parameter. 4 After entering the complete command, press [Return]. NOTE If an asterisk (*) appears in front of the command-line prompt, it indicates that you have outstanding configuration changes that have not been saved. For more information on saving configuration changes, see Appendix A.

Syntax Helper
The CLI has a built-in syntax helper. If you are unsure of the complete syntax for a particular command, enter as much of the command as possible and press [Tab]. The syntax helper provides a list of options for the remainder of the command, and places the cursor at the end of the command you have entered so far, ready for the next option. If the command is one where the next option is a named component, such as a VLAN, access profile, or route map, the syntax helper will also list any currently configured names that might be used as the next option. In situations where this list might be very long, the syntax helper will list only one line of names, followed by an ellipses to indicate that there are more names than can be displayed. The syntax helper also provides assistance if you have entered an incorrect command.

Abbreviated Syntax
Abbreviated syntax is the shortest unambiguous allowable abbreviation of a command or parameter. Typically, this is the first three letters of the command. If you do not enter enough letters to allow the switch to determine which command you mean, the syntax helper will provide a list of the options based on the portion of the command you have entered. NOTE When using abbreviated syntax, you must enter enough characters to make the command unambiguous and distinguishable to the switch.

Command Shortcuts
All named components of the switch configuration must have a unique name. Components are typically named using the create command. When you enter a command to configure a named component, you do not need to use the keyword of the component. For example, to create a VLAN, you must enter a unique VLAN name:
create vlan engineering

Once you have created the VLAN with a unique name, you can then eliminate the keyword vlan from all other commands that require the name to be entered. For example, instead of entering the modular switch command
configure vlan engineering delete port 1:3,4:6

you could enter the following shortcut:

configure engineering delete port 1:3,4:6

40

ExtremeWare 7.1.0 Software User Guide

Understanding the Command Syntax

Similarly, on the stand-alone switch, instead of entering the command

configure vlan engineering delete port 1-3,6

you could enter the following shortcut:

configure engineering delete port 1-3,6

Modular Switch Numerical Ranges

Commands that require you to enter one or more port numbers on a modular switch use the parameter <portlist> in the syntax. A <portlist> can be one port on a particular slot. For example,
port 3:1

A <portlist> can be a range of numbers. For example,

port 3:1-3:3

You can add additional slot and port numbers to the list, separated by a comma:
port 3:1,4:8,6:10

You can specify all ports on a particular slot. For example,

port 3:*

indicates all ports on slot 3. You can specify a range of slots and ports. For example,
port 2:3-4:5

indicates slot 2, port 3 through slot 4, port 5.

Stand-alone Switch Numerical Ranges

Commands that require you to enter one or more port numbers on a stand-alone switch use the parameter <portlist> in the syntax. A portlist can be a range of numbers, for example:
port 1-3

You can add additional port numbers to the list, separated by a comma:
port 1-3,6,8

Names
All named components of the switch configuration must have a unique name. Names must begin with an alphabetical character and are delimited by whitespace, unless enclosed in quotation marks. Names are not case-sensitive. Names cannot be tokens used on the switch.

ExtremeWare 7.1.0 Software User Guide

41

Accessing the Switch

Symbols
You may see a variety of symbols shown as part of the command syntax. These symbols explain how to enter the command, and you do not type them as part of the command itself. Table 4 summarizes command syntax symbols. Table 4: Command Syntax Symbols
Symbol angle brackets < > Description Enclose a variable or value. You must specify the variable or value. For example, in the syntax configure vlan <vlan name> ipaddress <ip_address> you must supply a VLAN name for <vlan name> and an address for <ip_address> when entering the command. Do not type the angle brackets. square brackets [ ] Enclose a required value or list of required arguments. One or more values or arguments can be specified. For example, in the syntax use image [primary | secondary] you must specify either the primary or secondary image when entering the command. Do not type the square brackets. vertical bar | Separates mutually exclusive items in a list, one of which must be entered. For example, in the syntax configure snmp community [read-only | read-write] <string> you must specify either the read or write community string in the command. Do not type the vertical bar. braces { } Enclose an optional value or a list of optional arguments. One or more values or arguments can be specified. For example, in the syntax reboot {<date> <time> | cancel} you can specify either a particular date and time combination, or the keyword cancel to cancel a previously scheduled reboot. If you do not specify an argument, the command will prompt, asking if you want to reboot the switch now. Do not type the braces.

Limits
The command line can process up to 200 characters, including spaces. If you enter more than 200 characters, the switch generates a stack overflow error and processes the first 200 characters.

Line-Editing Keys
Table 5 describes the line-editing keys available using the CLI. Table 5: Line-Editing Keys
Key(s) Backspace Delete or [Ctrl] + D [Ctrl] + K Insert Left Arrow Description Deletes character to left of cursor and shifts remainder of line to left. Deletes character under cursor and shifts remainder of line to left. Deletes characters from under cursor to end of line. Toggles on and off. When toggled on, inserts text and shifts previous text to right. Moves cursor to left.

42

ExtremeWare 7.1.0 Software User Guide

Command History

Table 5: Line-Editing Keys (continued)

Key(s) Right Arrow Home or [Ctrl] + A End or [Ctrl] + E [Ctrl] + L [Ctrl] + P or Up Arrow [Ctrl] + N or Down Arrow [Ctrl] + U [Ctrl] + W Description Moves cursor to right. Moves cursor to first character in line. Moves cursor to last character in line. Clears screen and movers cursor to beginning of line. Displays previous command in command history buffer and places cursor at end of command. Displays next command in command history buffer and places cursor at end of command. Clears all characters typed from cursor to beginning of line. Deletes previous word.

Command History
ExtremeWare remembers the last 49 commands you entered. You can display a list of these commands by using the following command:
history

Common Commands
Table 6 describes some of the common commands used to manage the switch. Commands specific to a particular feature may also be described in other chapters of this guide. For a detailed description of the commands and their options, see the ExtremeWare Software Command Reference Guide. Table 6: Common Commands
Command clear session <number> configure account <username> Description Terminates a Telnet session from the switch. Configures a user account password. The switch will interactively prompt for a new password, and for reentry of the password to verify it. Passwords must have a minimum of 1 character and can have a maximum of 30 characters. Passwords are case-sensitive; user names are not case sensitive. configure banner Configures the banner string. You can enter up to 24 rows of 79-column text that is displayed before the login prompt of each session. Press [Return] at the beginning of a line to terminate the command and apply the banner. To clear the banner, press [Return] at the beginning of the first line. Configures the network login banner string. You can enter up to 1024 characters to be displayed before the login prompt of each session.

configure banner netlogin

configure ports <portlist> auto off {speed [10 | 100 | Manually configures the port speed and duplex setting of 1000]} duplex [half | full] one or more ports on a switch. configure slot <slot number> module <module name> Configures a slot for a particular I/O module card.

ExtremeWare 7.1.0 Software User Guide

43

Accessing the Switch

Table 6: Common Commands (continued)

Command configure ssh2 key {pregenerated} configure sys-recovery-level [none | [all | critical] [msm-failover | reboot | shutdown | system-dump [maintenance-mode | msm-failover | reboot | shutdown]]] configure time <date> <time> Description Generates the SSH2 host key. Configures a recovery option for instances where an exception occurs in ExtremeWare. The msm-failover option is available on BlackDiamond switches only. If msm-failover is specified, a software exception triggers a slave MSM failover to master. Configures the system date and time. The format is as follows: mm/dd/yyyy hh:mm:ss The time uses a 24-hour clock format. You cannot set the year past 2036. configure timezone <gmt_offset> {autodst | noautodst} Configures the time zone information to the configured offset from GMT time. The format of gmt_offset is +/- minutes from GMT time. The autodst and noautodst options enable and disable automatic Daylight Saving Time change based on the North American standard. Additional options are described in the ExtremeWare Software Command Reference Guide. configure vlan <vlan name> ipaddress <ip_address> {<mask>} create account [admin | user] <username> {<password>} Configures an IP address and subnet mask for a VLAN. Creates a user account. This command is available to admin-level users and to users with RADIUS command authorization. The username is between 1 and 30 characters, the password is between 0 and 30 characters. Creates a VLAN. Deletes a user account. Deletes a VLAN. Disables BOOTP for one or more VLANs. Disables logging of CLI commands to the Syslog. Disables pausing of the screen display when a show command output reaches the end of the page. Disables the timer that disconnects all sessions. Once disabled, console sessions remain open until the switch is rebooted or you logoff. Telnet sessions remain open until you close the Telnet client. Disables a port on the switch. Disables SSH2 Telnet access to the switch. Disables Telnet access to the switch. Disables web access to the switch. Enables BOOTP for one or more VLANs. Enables the logging of CLI configuration commands to the Syslog for auditing purposes. The default setting is enabled. Enables pausing of the screen display when show command output reaches the end of the page. The default setting is enabled. Enables a timer that disconnects all sessions (both Telnet and console) after 20 minutes of inactivity. The default setting is disabled.

create vlan <vlan name> delete account <username> delete vlan <vlan name> disable bootp vlan [<vlan name> | all] disable cli-config-logging disable clipaging disable idletimeouts

disable ports [<portlist> | all] disable ssh2 disable telnet disable web enable bootp vlan [<vlan name> | all] enable cli-config-logging enable clipaging

enable idletimeouts

44

ExtremeWare 7.1.0 Software User Guide

Configuring Management Access

Table 6: Common Commands (continued)

Command enable license fullL3 <license_key> Description Enables a particular software feature license. Specify <license_key> as an integer. The command unconfigure switch all does not clear licensing information. This license cannot be disabled once it is enabled on the switch. enable ssh2 {access-profile [<access_profile> | none]} {port <tcp_port_number>} enable telnet {access-profile [<access_profile> | none]} {port <tcp_port_number>} Enables SSH2 sessions. By default, SSH2 is enabled with no access profile, and uses TCP port number 22. To cancel a previously configured access-profile, use the none option. Enables Telnet access to the switch. By default, Telnet is enabled with no access profile, and uses TCP port number 23. To cancel a previously configured access-profile, use the none option. Enables ExtremeWare Vista web access to the switch. By default, web access is enabled with no access profile, using TCP port number 80. Use the none option to cancel a previously configured access-profile. Displays the previous 49 commands entered on the switch. Displays the user-configured banner. Resets all switch parameters (with the exception of defined user accounts, and date and time information) to the factory defaults. If you specify the keyword all, the switch erases the currently selected configuration image in flash memory and reboots. As a result, all parameters are reset to default settings.

enable web {access-profile [<access_profile> | none]} {port <tcp_port_number>}

history show banner unconfigure switch {all}

Configuring Management Access

ExtremeWare supports the following two levels of management: User Administrator In addition to the management levels, you can optionally use an external RADIUS server to provide CLI command authorization checking for each command. For more information on RADIUS, see RADIUS Client in Chapter 3.

User Account
A user-level account has viewing access to all manageable parameters, with the exception of: User account database. SNMP community strings. A user-level account can use the ping command to test device reachability, and change the password assigned to the account name. If you have logged on with user capabilities, the command-line prompt ends with a (>) sign. For example:
Summit1:2>

ExtremeWare 7.1.0 Software User Guide

45

Accessing the Switch

Administrator Account
An administrator-level account can view and change all switch parameters. It can also add and delete users, and change the password associated with any account name. The administrator can disconnect a management session that has been established by way of a Telnet connection. If this happens, the user logged on by way of the Telnet connection is notified that the session has been terminated. If you have logged on with administrator capabilities, the command-line prompt ends with a (#) sign. For example:
Summit1:18#

Prompt Text
The prompt text is taken from the SNMP sysname setting. The number that follows the colon indicates the sequential line/command number. If an asterisk (*) appears in front of the command-line prompt, it indicates that you have outstanding configuration changes that have not been saved. For example:
*Summit1:19#

Default Accounts
By default, the switch is configured with two accounts, as shown in Table 7. Table 7: Default Accounts
Account Name admin user Access Level This user can access and change all manageable parameters. The admin account cannot be deleted. This user can view (but not change) all manageable parameters, with the following exceptions: This user cannot view the user account database. This user cannot view the SNMP community strings.

Changing the Default Password

Default accounts do not have passwords assigned to them. Passwords can have a minimum of zero characters and can have a maximum of 30 characters. NOTE Passwords are case-sensitive; user names are not case-sensitive. To add a password to the default admin account, follow these steps: 1 Log in to the switch using the name admin. 2 At the password prompt, press [Return]. 3 Add a default admin password by entering the following command:
configure account admin

4 Enter the new password at the prompt.

46

ExtremeWare 7.1.0 Software User Guide

Configuring Management Access

5 Re-enter the new password at the prompt. To add a password to the default user account, follow these steps: 1 Log in to the switch using the name admin. 2 At the password prompt, press [Return], or enter the password that you have configured for the admin account. 3 Add a default user password by entering the following command:
configure account user

4 Enter the new password at the prompt. 5 Re-enter the new password at the prompt. NOTE If you forget your password while logged out of the command line interface, contact your local technical support representative, who will advise on your next course of action.

Creating a Management Account

The switch can have a total of 16 management accounts. You can use the default names (admin and user), or you can create new names and passwords for the accounts. Passwords can have a minimum of 0 characters and can have a maximum of 30 characters. To create a new account, follow these steps: 1 Log in to the switch as admin. 2 At the password prompt, press [Return], or enter the password that you have configured for the admin account. 3 Add a new user by using the following command:
create account [admin | pppuser | user] <username>

4 Enter the password at the prompt. 5 Re-enter the password at the prompt.

Viewing Accounts
To view the accounts that have been created, you must have administrator privileges. Use the following command to see the accounts:
show accounts

ExtremeWare 7.1.0 Software User Guide

47

Accessing the Switch

Deleting an Account
To delete a account, you must have administrator privileges. To delete an account, use the following command:
delete account <username>

NOTE Do not delete the default administrator account. If you do, it is automatically restored, with no password, the next time you download a configuration. To ensure security, change the password on the default account, but do not delete it. The changed password will remain intact through configuration uploads and downloads. If you must delete the default account, first create another administrator-level account. Remember to manually delete the default account again every time you download a configuration.

Domain Name Service Client Services

The Domain Name Service (DNS) client in ExtremeWare augments the following commands to allow them to accept either IP addresses or host names: telnet download [bootrom | configuration | image] upload configuration ping traceroute In addition, the nslookup utility can be used to return the IP address of a hostname. You can specify up to eight DNS servers for use by the DNS client using the following command:
configure dns-client add <ipaddress>

You can specify a default domain for use when a host name is used without a domain. Use the following command:
configure dns-client default-domain <domain name>

For example, if you specify the domain xyz-inc.com as the default domain, then a command such as ping accounting1 will be taken as if it had been entered ping accounting1.xyz-inc.com.

Checking Basic Connectivity

The switch offers the following commands for checking basic connectivity: ping traceroute

48

ExtremeWare 7.1.0 Software User Guide

Checking Basic Connectivity

Ping
The ping command enables you to send Internet Control Message Protocol (ICMP) echo messages to a remote IP device. The ping command is available for both the user and administrator privilege level. The ping command syntax is:
ping {udp} {continuous} {size <start_size> {- <end_size>}} [<ip_address> | <hostname>] {from <src_address> | with record-route | from <src_ipaddress> with record-route}

Options for the ping command are described in Table 8. Table 8: Ping Command Parameters
Parameter udp continuous size Description Specifies that UDP messages should be sent instead of ICMP echo messages. When specified, from and with record-route options are not supported. Specifies ICMP echo messages to be sent continuously. This option can be interrupted by pressing any key. Specifies the size of the ICMP request. If both the start_size and end_size are specified, transmits ICMP requests using 1 byte increments, per packet. If no end_size is specified, packets of start_size are sent. Specifies the IP address of the host. Specifies the name of the host. To use the hostname, you must first configure DNS. Uses the specified source address in the ICMP packet. If not specified, the address of the transmitting interface is used. Decodes the list of recorded routes and displays them when the ICMP echo reply is received.

<ipaddress> <hostname> from with record-route

If a ping request fails, the switch continues to send ping messages until interrupted. Press any key to interrupt a ping request. The statistics are tabulated after the ping is interrupted.

Traceroute
The traceroute command enables you to trace the routed path between the switch and a destination endstation. The traceroute command syntax is:
traceroute [<ip_address> | <hostname>] {from <src_ipaddress>} {ttl <TTL>} {port <port>}

where: ip_address is the IP address of the destination endstation. hostname is the hostname of the destination endstation. To use the hostname, you must first configure DNS. from uses the specified source address in the ICMP packet. If not specified, the address of the transmitting interface is used. ttl configures the switch to trace the hops until the time-to-live has been exceeded for the switch. port uses the specified UDP port number.

ExtremeWare 7.1.0 Software User Guide

49

Accessing the Switch

50

ExtremeWare 7.1.0 Software User Guide

Managing the Switch

This chapter covers the following topics: Overview on page 51 Using the Console Interface on page 52 Using the 10/100 Ethernet Management Port on page 52 Using Telnet on page 53 Using Secure Shell 2 (SSH2) on page 56 Using ExtremeWare Vista on page 56 Using SNMP on page 61 Authenticating Users on page 72 Using Network Login on page 73 Using the Simple Network Time Protocol on page 73

Overview
Using ExtremeWare, you can manage the switch using the following methods: Access the CLI by connecting a terminal (or workstation with terminal-emulation software) to the console port. Access the switch remotely using TCP/IP through one of the switch ports or through the dedicated 10/100 unshielded twisted pair (UTP) Ethernet management port (on switches that are so equipped). Remote access includes: Telnet using the CLI interface. SSH2 using the CLI interface. ExtremeWare Vista web access using a standard web browser. SNMP access using EPICenter or another SNMP manager. Download software updates and upgrades. For more information, see Appendix B, Software Upgrade and Boot Options.

ExtremeWare 7.1.0 Software User Guide

51

Managing the Switch

The switch supports up to the following number of concurrent user sessions: One console session Two console sessions are available on a modular switch that has two management modules installed. Eight Telnet sessions Eight SSH2 sessions One web session

Using the Console Interface

The CLI built into the switch is accessible by way of the 9-pin, RS-232 port labeled console, located on the back of the stand-alone switch, or on the front of the modular switch management module. NOTE For more information on the console port pinouts, see the hardware installation guide that shipped with your switch. After the connection has been established, you will see the switch prompt and you can log in.

Using the 10/100 Ethernet Management Port

Some Extreme switch models provide a dedicated 10/100 Ethernet management port. This port provides dedicated remote access to the switch using TCP/IP. It supports the following management methods: Telnet using the CLI interface ExtremeWare Vista web access using a standard web browser SNMP access using EPICenter or another SNMP manager The management port is a DTE port, and is not capable of supporting switching or routing functions. The TCP/IP configuration for the management port is done using the same syntax as used for VLAN configuration. The VLAN mgmt comes pre configured with only the 10/100 UTP management port as a member. You can configure the IP address, subnet mask, and default router for the VLAN mgmt, using the following commands:
configure vlan mgmt ipaddress <ip_address>/<subnet_mask> configure iproute add default <gateway>

52

ExtremeWare 7.1.0 Software User Guide

Using Telnet

Using Telnet
Any workstation with a Telnet facility should be able to communicate with the switch over a TCP/IP network using VT-100 terminal emulation. Up to eight active Telnet sessions can access the switch concurrently. If idletimeouts are enabled, the Telnet connection will time out after 20 minutes of inactivity. If a connection to a Telnet session is lost inadvertently, the switch terminates the session within two hours. Before you can start a Telnet session, you must set up the IP parameters described in Configuring Switch IP Parameters later in this chapter. Telnet is enabled by default.

NOTE Maximize the Telnet screen so that automatically updating screens display correctly. To open the Telnet session, you must specify the IP address of the device that you want to manage. Check the user manual supplied with the Telnet facility if you are unsure of how to do this. After the connection is established, you will see the switch prompt and you may log in.

Connecting to Another Host Using Telnet

You can Telnet from the current CLI session to another host using the following command:
telnet [<ipaddress> | <hostname>] {<port_number>}

If the TCP port number is not specified, the Telnet session defaults to port 23. Only VT100 emulation is supported.

Configuring Switch IP Parameters

To manage the switch by way of a Telnet connection or by using an SNMP Network Manager, you must first configure the switch IP parameters.

Using a BOOTP Server

If you are using IP and you have a Bootstrap Protocol (BOOTP) server set up correctly on your network, you must provide the following information to the BOOTP server: Switch Media Access Control (MAC) address, found on the rear label of the switch IP address Subnet address mask (optional) After this is done, the IP address and subnet mask for the switch will be downloaded automatically. You can then start managing the switch using this addressing information without further configuration. You can enable BOOTP on a per-VLAN basis by using the following command:
enable bootp vlan [<vlan name> | all]

By default, BOOTP is enabled on the default VLAN.

ExtremeWare 7.1.0 Software User Guide

53

Managing the Switch

If you configure the switch to use BOOTP, the switch IP address is not retained through a power cycle, even if the configuration has been saved. To retain the IP address through a power cycle, you must configure the IP address of the VLAN using the command-line interface, Telnet, or web interface. All VLANs within a switch that are configured to use BOOTP to get their IP address use the same MAC address. Therefore, if you are using BOOTP relay through a router, the BOOTP server relays packets based on the gateway portion of the BOOTP packet.

NOTE For more information on DHCP/BOOTP relay, see Chapter 16.

Manually Configuring the IP Settings

If you are using IP without a BOOTP server, you must enter the IP parameters for the switch in order for the SNMP Network Manager, Telnet software, or web interface to communicate with the device. To assign IP parameters to the switch, you must perform the following tasks: Log in to the switch with administrator privileges using the console interface. Assign an IP address and subnet mask to a VLAN. The switch comes configured with a default VLAN named default. To use Telnet or an SNMP Network Manager, you must have at least one VLAN on the switch, and it must be assigned an IP address and subnet mask. IP addresses are always assigned to each VLAN. The switch can be assigned multiple IP addresses. NOTE For information on creating and configuring VLANs, see Chapter 5. To manually configure the IP settings, follow these steps: 1 Connect a terminal or workstation running terminal-emulation software to the console port, as detailed in Using the Console Interface on page 52. 2 At your terminal, press [Return] one or more times until you see the login prompt. 3 At the login prompt, enter your user name and password. Note that they are both case-sensitive. Ensure that you have entered a user name and password with administrator privileges. If you are logging in for the first time, use the default user name admin to log in with administrator privileges. For example:
login: admin

Administrator capabilities enable you to access all switch functions. The default user names have no passwords assigned. If you have been assigned a user name and password with administrator privileges, enter them at the login prompt. 4 At the password prompt, enter the password and press [Return]. When you have successfully logged in to the switch, the command-line prompt displays the name of the switch in its prompt. 5 Assign an IP address and subnetwork mask for the default VLAN by using the following command:
configure vlan <vlan name> ipaddress <ipaddress> {<subnet_mask>}

54

ExtremeWare 7.1.0 Software User Guide

Using Telnet

For example:
configure vlan default ipaddress 123.45.67.8 255.255.255.0

Your changes take effect immediately. NOTE As a general rule, when configuring any IP addresses for the switch, you can express a subnet mask by using dotted decimal notation, or by using classless inter-domain routing notation (CIDR). CIDR uses a forward slash plus the number of bits in the subnet mask. Using CIDR notation, the command identical to the one above would be:
configure vlan default ipaddress 123.45.67.8 / 24

6 Configure the default route for the switch using the following command:
configure iproute add default <gateway> {<metric>}

For example:
configure iproute add default 123.45.67.1

7 Save your configuration changes so that they will be in effect after the next switch reboot, by typing:
save

8 When you are finished using the facility, log out of the switch by typing:
logout or quit

Disconnecting a Telnet Session

An administrator-level account can disconnect a Telnet management session. If this happens, the user logged in by way of the Telnet connection is notified that the session has been terminated. To terminate a Telnet session, follow these steps: 1 Log in to the switch with administrator privileges. 2 Determine the session number of the session you want to terminate by using the following command:
show session

3 Terminate the session by using the following command:

clear session <session_number>

Controlling Telnet Access

By default, Telnet services are enabled on the switch. Telnet access can be restricted by the use of an access profile. An access profile permits or denies a named list of IP addresses and subnet masks. To configure Telnet to use an access profile, use the following command:
enable telnet {access-profile [<access_profile> | none]} {port <tcp_port_number>}

Use the none option to remove a previously configured access profile. To display the status of Telnet, use the following command:
show management

ExtremeWare 7.1.0 Software User Guide

55

Managing the Switch

You can choose to disable Telnet by using the following command:

disable telnet

To re-enable Telnet on the switch, at the console port use the following:
enable telnet

You must be logged in as an administrator to enable or disable Telnet.

NOTE For more information on Access Profiles, see Chapter 11.

Using Secure Shell 2 (SSH2)

Secure Shell 2 (SSH2) is a feature of ExtremeWare that allows you to encrypt Telnet session data between a network administrator using SSH2 client software and the switch, or to send encrypted data from the switch to an SSH2 client on a remote system. Image and configuration files may also be transferred to the switch using the Secure Copy Protocol 2 (SCP2). The ExtremeWare CLI provides a command that enable the switch to function as an SSH2 client, sending commands to a remote system via an SSH2 session. It also provides commands to copy image and configuration files to the switch using the SCP2. For detailed information about SSH2 and SCP2, see Chapter 11, Security.

Using ExtremeWare Vista

The ExtremeWare Vista device-management software that runs on the switch allows you to access the switch over a TCP/IP network using a standard web browser. Any properly configured standard web browser that supports frames and JavaScript (such as Netscape Navigator 3.0 or above, or Microsoft Internet Explorer 3.0 or above) can be used to manage the switch. ExtremeWare Vista provides a subset of the command-line interface (CLI) commands available for configuring and monitoring the switch. If a particular command is not available using ExtremeWare Vista, you must use the CLI to access the desired functionality. To use ExtremeWare Vista, at least one VLAN must be assigned an IP address.

NOTE For more information on assigning an IP address, see Configuring Switch IP Parameters on page 53. The default home page of the switch can be accessed using the following command: http://<ipaddress> When you access the home page of the switch, you are presented with the Logon screen.

56

ExtremeWare 7.1.0 Software User Guide

Using ExtremeWare Vista

Controlling Web Access

By default, web access is disabled on the switch. Use of ExtremeWare Vista web access can be restricted through the use of an access profile. An access profile permits or denies a named list of IP addresses and subnet masks. To configure Vista web access to use an access profile, use the following command:
enable web {access-profile <access-profile> | none} {port <tcp_port_number>}

Use the none option to remove a previously configured access profile. Apply an access profile only when ExtremeWare Vista is enabled. To display the status of web access, use the following command:
show management

To disable ExtremeWare Vista, use the following command:

disable web

To re-enable web access, use the enable web command. By default, web access uses TCP port 80. To specify a different port, use the port option in the enable
web command.

To configure the timeout for user to enter username/password in the pop-up window use the following command:
configure web login-timeout <seconds>

By default this timeout is set to 30 seconds. You will need to reboot the system in order for these changes to take effect.

NOTE For more information on rebooting, see Appendix A.

Setting Up Your Browser

In general, the default settings that come configured on your browser work well with ExtremeWare Vista. The following are recommended settings that you can use to improve the display features and functionality of ExtremeWare Vista: After downloading a newer version of the switch image, clear the browser disk and memory cache to see the updated menu screens. You must clear the cache while at the main ExtremeWare Vista Logon screen, so that all underlying .GIF files are updated. Check for newer versions of stored pages. Every visit to the page should be selected as a cache setting. If you are using Netscape Navigator, configure the cache option to check for changes Every Time you request a page. If you are using Microsoft Internet Explorer, configure the Temporary Internet Files setting to check for newer versions of stored pages by selecting Every visit to the page. Images must be auto-loaded. Use a high-resolution monitor to maximize the amount of information displayed in the content frame. The recommended resolution is 1024 x 768 pixels. You can also use 800 x 600 pixels.

ExtremeWare 7.1.0 Software User Guide

57

Managing the Switch

Turn off one or more of the browser toolbars to maximize the viewing space of the ExtremeWare Vista content screen. If you will be using ExtremeWare Vista to send an email to the Extreme Networks Technical Support department, configure the email settings in your browser. Configure the browser to use the following recommended fonts: Proportional fontTimes New Roman Fixed-width fontCourier New

Accessing ExtremeWare Vista

To access the default home page of the switch, enter the following URL in your browser: http://<ip_address> When you access the home page of the system, you are presented with the Login screen. Enter your user name and password in the appropriate fields, and click OK. If you have entered the name and password of an administrator-level account, you have access to all ExtremeWare Vista pages. If you have used a user-level account name and password, you only have access to the Statistics and Support information. If multiple people access the same switch using ExtremeWare Vista, you might see the following error message:
Web:server busy

To correct this situation, log out of the switch and log in again.

Navigating ExtremeWare Vista

After logging in to the switch, the ExtremeWare Vista home page is displayed. ExtremeWare Vista divides the browser screen into the following sections: Task frame Content frame Standalone buttons

Task Frame
The task frame has two sections: menu buttons and submenu links. The four task menu buttons are: Configuration Statistics Support Logout

58

ExtremeWare 7.1.0 Software User Guide

Using ExtremeWare Vista

Below the task buttons are options. Options are specific to the task button that you select. When you select an option, the information displayed in the content frame changes. However, when you select a new task button, the content frame does not change until you select a new option.

NOTE Submitting a configuration page with no change will result in an asterisk (*) appearing at the CLI prompt, even though actual configuration values have not changed.

Content Frame
The content frame contains the main body of information in ExtremeWare Vista. For example, if you select an option from the Configuration task button, enter configuration parameters in the content frame. If you select the Statistics task button, statistics are displayed in the content frame. Browser Controls. Browser controls include drop-down list boxes, check boxes, and multiselect list boxes. A multiselect list box has a scrollbar on the right side of the box. Using a multiselect list box, you can select a single item, all items, a set of contiguous items, or multiple noncontiguous items. Table 9 describes how to make selections from a multiselect list box. Table 9: Multiselect List Box Key Definitions
Selection Type Single item All items Contiguous items Selected noncontiguous items Key Sequence Click the item using the mouse. Click the first item, and drag to the last item. Click the first desired item, and drag to the last desired item. Hold down [Ctrl], click the first desired item, click the next desired item, and so on.

Status Messages
Status messages are displayed at the top of the content frame. The four types of status messages are: InformationDisplays information that is useful to know prior to, or as a result of, changing configuration options. WarningDisplays warnings about the switch configuration. ErrorDisplays errors caused by incorrectly configured settings. SuccessDisplays informational messages after you click Submit. The message displayed reads, Request was submitted successfully.

Standalone Buttons
At the bottom of some of the content frames is a section that contains standalone buttons. Standalone buttons are used to perform tasks that are not associated with a particular configuration option. An example of this is the Reboot Switch button.

ExtremeWare 7.1.0 Software User Guide

59

Managing the Switch

Saving Changes
You can save your changes to nonvolatile storage in either of two ways using ExtremeWare Vista: Select Save Configuration from the Configuration task button, Switch option. This field contains a drop-down list box that allows you to select either the primary or secondary configuration area. After you select the configuration area, click Submit to save the changes. Click the Logout button. If you attempt to log out without saving your changes, ExtremeWare Vista prompts you to save your changes. If you select Yes, the changes are saved to the selected configuration area. To change the selected configuration area, you must go to the Configuration task button, Switch option.

Filtering Information
Some pages have a Filter button. The Filter button is used to display a subset of information on a given page. For example, on the OSPF configuration page, you can configure authentication based on the VLAN, area identifier, or virtual link. Once you select a filtering option and click the Filter button, the form that provides the configuration options displays the available interfaces in the drop-down menu, based on your filtering selection. Similarly, in certain Configuration and Statistics pages, information is shown based on a particular slot. Because modular switches allow you to preconfigure modules without having them physically available in the chassis, the configuration pages offer a drop-down menu to select any module card that has been configured on the system, whether or not the module is physically available. By default, information for the first configured module that is found in the chassis is displayed on the page. You can configure available slots and ports by filtering on a selected module from the Sort by Slot drop-down menu. On the Statistics pages, you can only view information for cards that are configured and physically inserted into the chassis. On these pages, the Sort by Slot drop-down menu displays only these modules.

Do a GET When Configuring a VLAN

When configuring a VLAN using ExtremeWare Vista, prior to editing the VLAN configuration, you must first click the get button to ensure that subsequent edits are applied to the correct VLAN. If you do not click the get button and you submit the changes, the changes will be made to the VLAN that was previously displayed. If you configure a VLAN and then delete it, the default VLAN is shown in the VLAN name window, but the VLAN information contained in the lower portion of the page is not updated. Click the get button to update the display.

60

ExtremeWare 7.1.0 Software User Guide

Using SNMP

Sending Screen Output to Extreme Networks

If Extreme Networks requests that you email the output of a particular ExtremeWare Vista screen, follow these steps: 1 Click on the content frame of the screen that you must send. 2 From Netscape Navigator, select Save Frame As from the File menu, and enter a name for the file. From Microsoft Internet Explorer 3.0, select Save As File from the File menu, and enter a name for the file. From Microsoft Internet Explorer 4.0, right-click in the content frame, select View Source, and save the HTML text by copying it and pasting it into a text editor. 3 Attach the file to the email message that you are sending to Extreme Networks.

Using SNMP
Any Network Manager running the Simple Network Management Protocol (SNMP) can manage the switch, provided the Management Information Base (MIB) is installed correctly on the management station. Each Network Manager provides its own user interface to the management facilities. The following sections describe how to get started if you want to use an SNMP manager. It assumes you are already familiar with SNMP management. If not, refer to the following publication: The Simple Book by Marshall T. Rose ISBN 0-13-8121611-9 Published by Prentice Hall.

Enabling and Disabling SNMPv1/v2c and SNMPv3

ExtremeWare versions since 7.1.0 can concurrently support SNMPv1/v2c and SNMPv3. The default for the switch is to have both types of SNMP enabled. Network managers can access the device with either SNMPv1/v2c methods or SNMPv3. To enable concurrent support, use the following command:
enable snmp access

To prevent any type of SNMP access, use the following command:

disable snmp access

To prevent access using SNMPv1/v2c methods and allow access using SNMPv3 methods only, use the following commands:
enable snmp access disable snmp access snmp-v1v2c

There is no way to configure the switch to allow SNMPv1/v2c access and prevent SNMPv3 access. Most of the commands that support SNMPv1/v2c use the keyword snmp, most of the commands that support SNMPv3 use the keyword snmpv3.

ExtremeWare 7.1.0 Software User Guide

61

Managing the Switch

Accessing Switch Agents

To have access to the SNMP agent residing in the switch, at least one VLAN must have an IP address assigned to it. By default, SNMP access and SNMPv1/v2c traps are enabled. SNMP access and SNMP traps can be disabled and enabled independentlyyou can disable SNMP access but still allow SNMP traps to be sent, or vice versa.

Supported MIBs
In addition to private MIBs, the switch supports the standard MIBs listed in Appendix C.

Configuring SNMPv1/v2c Settings

The following SNMPv1/v2c parameters can be configured on the switch: Authorized trap receiversAn authorized trap receiver can be one or more network management stations on your network. The switch sends SNMPv1/v2c traps to all trap receivers. You can have a maximum of 16 trap receivers configured for each switch, and you can specify a community string and UDP port for individually for each trap receiver. All community strings must also be added to the switch using the configure snmp add community command. To configure a trap receiver on a switch, use the following command:
configure snmp add trapreceiver <ip address> {port <number>} community {hex} <community string> {from <source ip address>} {mode [enhanced | standard]} trap-group {auth-traps} ...

See the Command Reference for a listing of the available traps. You can delete a trap receiver using the configure snmp delete trapreceiver command. Entries in the trap receiver list can also be created, modified, and deleted using the RMON2 trapDestTable MIB variable, as described in RFC 2021. SNMP read accessThe ability to read SNMP information can be restricted through the use of an access profile. An access profile permits or denies a named list of IP addresses and subnet masks. To configure SNMPv1/v2c read access to use an access profile, use the following command:
configure snmp access-profile readonly [<access_profile> | none]

Use the none option to remove a previously configured access profile. SNMP read/write accessThe ability to read and write SNMP information can be restricted through the use of an access profile. An access profile permits or denies a named list of IP addresses and subnet masks. To configure SNMPv1/v2c read/write access to use an access profile, use the following command:
configure snmp access-profile readwrite [<access_profile> | none]

Use the none option to remove a previously configured access-profile. Community stringsThe community strings allow a simple method of authentication between the switch and the remote Network Manager. There are two types of community strings on the switch. Read community strings provide read-only access to the switch. The default read-only community string is public. Read-write community strings provide read and write access to the switch. The default read-write community string is private. System contact (optional)The system contact is a text field that enables you to enter the name of the person(s) responsible for managing the switch.

62

ExtremeWare 7.1.0 Software User Guide

Using SNMP

System nameThe system name is the name that you have assigned to this switch. The default name is the model name of the switch (for example, Summit1 switch). System location (optional)Using the system location field, you can enter an optional location for this switch. Enabling/disabling link up and link down traps (optional)By default, link up and link down traps (also called port-up-down traps) are enabled on the switch for all ports. You can disable or re-enable the sending of these traps on a per port basis, by using the following commands:
disable snmp traps port-up-down ports [all | mgmt | <portlist>] enable snmp traps port-up-down ports [all | mgmt | <portlist>]

The mgmt option will only appear on platforms having a management port. Enabling/disabling MAC-security traps (optional)MAC-security traps are sent on ports when limit-learning is configured and a new MAC address appears on the port after the port has already learned MAC addresses up to the configured limit. At such instants, a log message is generated in the syslog, a trap is sent out and the port is blackholed. By default, MAC-security traps are disabled on the switch. To enable or re-disable them, the following commands must be used:
enable snmp traps mac-security disable snmp traps mac-security

NOTE To configure learning limits on a set of ports, the command configure ports <portlist> limit-learning can be used.

Displaying SNMP Settings

To display the SNMP settings configured on the switch, use the following command:
show management

This command displays the following information: Enable/disable state for Telnet, SSH2, SNMP, and web access, along with access profile information SNMP community strings Authorized SNMP station list SNMP MAC-security traps Link up/ link down traps enabled on ports SNMP trap receiver list SNMP trap groups RMON polling configuration Login statistics Enable/disable status of link up and link down traps Enable/disable status of MAC-security traps.

SNMP Trap Groups

SNMP trap groups allow you to specify which SNMP traps to send to a particular trap receiver. This functionality was made possible by the underlying support for SNMPv3. Essentially, a number of

ExtremeWare 7.1.0 Software User Guide

63

Managing the Switch

predefined filters are associated with a trap receiver, so that only those traps are sent. If you have already been using SNMPv1/v2c trap receivers, trap groups are very easy to incorporate into your network. You cannot define your own trap groups. If you need to define more selectively which notifications to receive, you will need to use the notification filter capabilities available in SNMPv3. To configure trap groups, use the following command:
configure snmp add trapreceiver <ip address> {port <number>} community {hex} <community string> {from <source ip address>} {mode [enhanced | standard]} trap-group {auth-traps{,}} {bgp-traps{,}} {extreme-traps{,}} {link-up-down-traps{,}} {ospf-traps{,} {ping-traceroute-traps{,}} {rmon-traps{,}} {security-traps {,}} {smart-traps{,}} {stp-traps{,}} {system-traps{,}} {vrrp-traps{,}}

For example, to send system and link up/link down traps to the receiver at 10.20.30.44 port 9347 with the community string private, use the following command:
configure snmp add trapreceiver 10.20.30.44 port 9347 community private trap-group link-up-down-traps , system-traps

Table 10 lists the currently defined SNMP trap groups. From time to time, new trap groups may be added to this command.

Table 10: SNMP Trap Groups

Trap Group stp-traps bgp-traps Notifications newRoot topologyChange bgpEstablished bgpBackwardTransition extremeBgpPrefixReachedThreshold extremeBgpPrefixMaxExceeded ospfIfStateChange ospfVirtIfStateChange ospfNbrStateChange ospfVirtNbrStateChange ospfIfConfigError ospfVirtIfConfigError ospfIfAuthFailure ospfVirtIfAuthFailure ospfIfRxBadPacket ospfVirtIfRxBadPacket ospfTxRetransmit ospfVirtIfTxRetransmit ospfOriginateLsa ospfMaxAgeLsa ospfLsdbOverflow ospfLsdbApproachingOverflow MIB Subtree dot1dBridge, 1.3.6.1.2.1.17 bgpTraps, 1.3.6.1.2.1.15.7 extremeBgpTrapsPrefix, 1.3.6.1.4.1.1916.4.2.0 ospfTraps, 1.3.6.1.2.1.14.16.2

ospf-traps

ping-traceroute-traps pingTestFailed pingTestCompleted tracerouteTestFailed tracerouteTestCompleted vrrp-traps vrrpTrapNewMaster vrrpTrapAuthFailure

pingNotifications, 1.3.6.1.2.1.80.0 traceRouteNotifications, 1.3.6.1.2.1.81.0 vrrpNotifications, 1.3.6.1.2.1.68.0

64

ExtremeWare 7.1.0 Software User Guide

Using SNMP

Table 10: SNMP Trap Groups (continued)

Trap Group system-traps Notifications extremeOverheat extremeFanFailed extremeFanOK extremePowerSupplyFail extremePowerSupplyGood extremeModuleStateChange extremeHealthCheckFailed extremeCpuUtilizationRisingTrap extremeCpuUtilizationFallingTrap coldStart warmStart extremeEsrpStateChange extremeEdpNeighborAdded extremeEdpNeighborRemoved extremeSlbUnitAdded extremeSlbUnitRemoved extremeSmartTrap AuthenticationFailure extremeInvalidLoginAttempt linkDown linkUp risingAlarm fallingAlarm extremeMacLimitExceeded extremeUnauthorizedPortForMacDetected extremeMacDetectedOnLockedPort extremeNetloginUserLogin extremeNetloginUserLogout extremeNetloginAuthFailure MIB Subtree 1.3.6.1.4.1.1916.0.6 1.3.6.1.4.1.1916.0.7 1.3.6.1.4.1.1916.0.8 1.3.6.1.4.1.1916.0.10 1.3.6.1.4.1.1916.0.11 1.3.6.1.4.1.1916.0.15 1.3.6.1.4.1.1916.4.1.0.1 1.3.6.1.4.1.1916.4.1.0.2 1.3.6.1.4.1.1916.4.1.0.3 1.3.6.1.6.3.1.1.5.1 1.3.6.1.6.3.1.1.5.2 1.3.6.1.4.1.1916.0.17 1.3.6.1.4.1.1916.0.20 1.3.6.1.4.1.1916.0.21 1.3.6.1.4.1.1916.0.18 1.3.6.1.4.1.1916.0.19 1.3.6.1.4.1.1916.0.14 1.3.6.1.6.3.1.1.5.5 1.3.6.1.4.1.1916.0.9 1.3.6.1.6.3.1.1.5.3 1.3.6.1.6.3.1.1.5.4 rmon-traps, 1.3.6.1.2.1.16.0 1.3.6.1.4.1.1916.4.3.0.1 1.3.6.1.4.1.1916.4.3.0.2 1.3.6.1.4.1.1916.4.3.0.3 1.3.6.1.4.1.1916.4.3.0.4 1.3.6.1.4.1.1916.4.3.0.5 1.3.6.1.4.1.1916.4.3.0.6

extreme-traps

smart-traps auth-traps link-up-down-traps rmon-traps security-traps

SNMPv3
Beginning in ExtremeWare version 7.1.0, support was added for SNMPv3. SNMPv3 is an enhanced standard for SNMP that improves the security and privacy of SNMP access to managed devices, and provides sophisticated control of access to the device MIB. The prior standard versions of SNMP, SNMPv1 and SNMPv2c provided no privacy and little (or no) security. The following six RFCs provide the foundation for Extreme Networks implementation of SNMPv3: RFC 3410, Introduction to version 3 of the Internet-standard Network Management Framework, provides an overview of SNMPv3. RFC 3411, An Architecture for Describing SNMP Management Frameworks, talks about SNMP architecture, especially the architecture for security and administration. RFC 3412, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP), talks about the message processing models and dispatching that can be a part of an SNMP engine. RFC 3413, SNMPv3 Applications, talks about the different types of applications that can be associated with an SNMPv3 engine. RFC 3414, The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3), describes the User-Based Security Model (USM).

ExtremeWare 7.1.0 Software User Guide

65

Managing the Switch

RFC 3415, View-based Access Control Model (V ACM) for the Simple Network Management Protocol (SNMP), talks about VACM as a way to access the MIB.

SNMPv3 Overview
The SNMPv3 standards for network management were primarily driven the need for greater security and access control. The new standards use a modular design and model management information by cleanly defining a message processing subsystem, a security subsystem, and an access control subsystem. The message processing (MP) subsystem helps identify the MP model to be used when processing a received Protocol Data Unit (PDU), the packets used by SNMP for communication. This layer helps in implementing a multi-lingual agent, so that various versions of SNMP can coexist simultaneously in the same network. The security subsystem features the use of various authentication and privacy protocols with various timeliness checking and engine clock synchronization schemes. SNMPv3 is designed to be secure against: Modification of information, where an in-transit message is altered. Masquerades, where an unauthorized entity assumes the identity of an authorized entity. Message stream modification, where packets are delayed and/or replayed. Disclosure, where packet exchanges are sniffed (examined) and information is learned about the contents. The access control subsystem provides the ability to configure whether access to a managed object in a local MIB is allowed for a remote principal. The access control scheme allows you to define access policies based on MIB views, groups, and multiple security levels. In addition, the SNMPv3 target and notification MIBs provide a more procedural approach for the generation and filtering of notifications. SNMPv3 objects are stored in non-volatile memory unless specifically assigned to volatile storage. Objects defined as permanent cannot be deleted or modified.

NOTE In SNMPv3, many objects can be identified by a human-readable string or by a string of hex octets. In many commands, you can use either a character string, or a colon separated string of hex octets to specify objects. This is indicated by the keyword hex used in the command.

Message Processing
A particular network manager may require messages that conform to a particular version of SNMP. The choice of the SNMPv1, SNMPv2, or SNMPv3 message processing model can be configured for each network manager as its target address is configured. The selection of the message processing model is configured with the mp-model keyword in the following command: configure snmpv3 add target-params {hex} <param name> user {hex} <user name> mp-model [snmpv1 | snmpv2c | snmpv3] sec-model [snmpv1 | snmpv2c | usm] {sec-level [noauth | authnopriv | priv]} {volatile}

66

ExtremeWare 7.1.0 Software User Guide

Using SNMP

SNMPv3 Security
In SNMPv3 the User-Based Security Model (USM) for SNMP was introduced. USM deals with security related aspects like authentication, encryption of SNMP messages and defining users and their various access security levels. This standard also encompass protection against message delay and message replay.

USM Timeliness Mechanisms

There is one SNMPv3 engine on an Extreme switch, identified by its snmpEngineID. The first four octets are fixed to 80:00:07:7C, which represents the Extreme Networks Vendor ID. By default, the additional octets for the snmpEngineID are generated from the device MAC address. Every SNMPv3 engine necessarily maintains two objects: SNMPEngineBoots, which is the number of reboots the agent has experienced and SNMPEngineTime, which is the engine local time since reboot. It has a local copy of these objects and the latestReceivedEngineTime for every authoritative engine it wants to communicate with. Comparing these objects with the values received in messages and then applying certain rules to decide upon the message validity accomplish protection against message delay or message replay. In a chassis, the snmpEngineID will be generated using the MAC address of the MSM with which the switch boots first. For MSM hitless failover, the same snmpEngineID will be propagated to both of the MSMs. The snmpEngineID can be configured from the command line, but once the snmpEngineID is changed, default users will be reverted back to their original passwords/keys, while non-default users will be reset to the security level of no authorization, no privacy. Use the following command to set the snmpEngineID: configure snmpv3 engine-id <hex octet> SNMPEngineBoots can also be configured from the command line. SNMPEngineBoots can be set to any desired value but will latch on its maximum, 2147483647. Use the following command to set the SNMPEngineBoots: configure snmpv3 engine-boots <(1-2147483647)>

Users, Groups, and Security

SNMPv3 controls access and security using the concepts of users, groups, security models, and security levels. Users. Users are created by specifying a user name. Depending on whether the user will be using authentication and/or privacy, you would also specify an authentication protocol (MD5 or SHA) with password or key, and/or privacy (DES) password or key. To create a user, use the following command: configure snmpv3 add user {hex} <user name> {authentication [md5 | sha] [hex <hex octet> | <password>]} {privacy [hex <hex octet> | <password>]} {volatile} There are a number of default, permanent users initially available.The default user names are: admin, initial, initialmd5, initialsha, initialmd5Priv, initialshaPriv. The default password for admin is password. For the other default users, the default password is the user name. To display information about a user, or all users, use the following command: show snmpv3 user {{hex} <user name>}

ExtremeWare 7.1.0 Software User Guide

67

Managing the Switch

To delete a user, use the following command:

configure snmpv3 delete user [all-non-defaults | {hex} <user name>]

NOTE In the SNMPv3 specifications there is the concept of a security name. In the ExtremeWare implementation, the user name and security name are identical. In this manual we use both terms to refer to the same thing. Groups. Groups are used to manage access for the MIB. You use groups to define the security model, the security level, and the portion of the MIB that members of the group can read or write. To underscore the access function of groups, groups are defined using the following command: configure snmpv3 add access {hex} <group name> {sec-model [snmpv1 | snmpv2 | usm]} {sec-level [noauth | authnopriv | priv]} {read-view {hex} <view name>} { write-view {hex} <view name>} {notify-view {hex} <view name>} {volatile} The security model and security level are discussed in the section labeled Security Models and Levels. The view names associated with a group define a subset of the MIB (subtree) that can be accessed by members of the group. The read view defines the subtree that can be read, write view defines the subtree that can be written to, and notify view defines the subtree that notifications can originate from. MIB views are discussed in the section MIB Access Control. There are a number of default (permanent) groups already defined. These groups are: admin, initial, initialmd5, initialsha, initialmd5Priv, initialshaPriv, v1v2c_ro, v1v2c_rw. Use the following command to display information about the access configuration of a group or all groups: show snmpv3 access {{hex} <group name>} Users are associated with groups using the following command: configure snmpv3 add group {hex} <group name> user {hex} <user name> {sec-model [snmpv1| snmpv2 | usm]} {volatile} To show which users are associated with a group, use the following command: show snmpv3 group {{hex} <group name> {user {hex} <user name>}} To delete a group, use the following command: configure snmpv3 delete access [all-non-defaults | {{hex} <group name> {sec-model [snmpv1 | snmpv2c | usm] sec-level [noauth | authnopriv | priv]}}] When you delete a group, you do not remove the association between the group. To delete the association between a user and a group, use the following command: configure snmpv3 delete group {{hex} <group name>} user [all-non-defaults | {{hex} <user name> {sec-model [snmpv1|snmpv2c|usm]}}] Security Models and Levels. For compatibility, SNMPv3 supports three security models: SNMPv1no security SNMPv2ccommunity strings based security SNMPv3USM security

68

ExtremeWare 7.1.0 Software User Guide

Using SNMP

The default is User-Based Security Model (USM). You can select the security model based on the network manager in your network. The three security levels supported by USM are: noAuthnoPrivNo authentication, no privacy. This is the case with existing SNMPv1/v2c agents. AuthnoPrivAuthentication, no privacy. Messages are tested only for authentication. AuthPrivAuthentication, privacy. This represents the highest level of security and requires every message exchange to pass the authentication and encryption tests. When a user is created, an authentication method is selected, and the authentication and privacy passwords or keys are entered. When MD5 authentication is specified, HMAC-MD5-96 is used to achieve authentication with a 16-octet key, which generates an 128-bit authorization code. This code is inserted in msgAuthenticationParameters field of SNMPv3 PDUs when the security level is specified as either AuthnoPriv or AuthPriv. Specifying SHA authentication uses the HMAC-SHA protocol with a 20-octet key for authentication. For privacy, a 16-octet key is provided as input to DES-CBS encryption protocol, which generates an encrypted PDU to be transmitted. DES uses bytes 1-7 to make a 56 bit key. This key (encrypted itself) is placed in msgPrivacyParameters of SNMPv3 PDUs when the security level is specified as AuthPriv.

MIB Access Control

SNMPv3 provides a fine-grained mechanism for defining which parts of the MIB can be accessed. This is referred to as the View-Based Access Control Model (VACM). MIB views represent the basic building blocks of VACM. They are used to define a subset of the information in the MIB. Access to read, to write, and to generate notifications is based on the relationship between a MIB view and an access group. The users of the access group can then read, write, or receive notifications from the part of the MIB defined in the MIB view as configured in the access group. A view name, a MIB subtree/mask, and an inclusion or exclusion define every MIB view. For example, there is a System group defined under the MIB-2 tree. The Object Identifier (OID) for MIB-2 is 1.3.6.1.2, and the System group is defined as MIB-2.1.1, or directly as 1.3.6.1.2.1.1. To define a MIB view which includes only the System group, use the following subtree/mask combination:
1.3.6.1.2.1.1 / 1.1.1.1.1.1.1.0

The mask can also be expressed in hex notation (this is used for the ExtremeWare CLI):
1.3.6.1.2.1.1 / fe

To define a view that includes the entire MIB-2, use the following subtree/mask:
1.3.6.1.2.1.1 / 1.1.1.1.1.0.0.0

which, on the command line, is:

1.3.6.1.2.1.1 / f8

When you create the MIB view, you can choose to include the MIB subtree/mask, or to exclude the MIB subtree/mask. To create a MIB view, use the following command:

ExtremeWare 7.1.0 Software User Guide

69

Managing the Switch

configure snmpv3 add mib-view {hex} <view name> subtree <object identifier> {/<subtree mask>} {type [included | excluded]} {[volatile | non-volatile]}

Once the view is created, you can repeatedly use the configure snmpv3 add mib-view command to include and/or exclude MIB subtree/mask combinations to precisely define the items you wish to control access to. In addition to the user created MIB views, there are three default views. They are of storage type permanent and cannot be deleted, but they can be modified. The default views are: defaultUserView, defaultAdminView, and defaultNotifyView. To show MIB views, use the following command:
show snmpv3 mib-view {{hex} <view name> {subtree <object identifier>}}

To delete a MIB view, use the following command: configure snmpv3 delete mib-view [all-non-defaults | {{hex} <view name> {subtree <object identifier>}}] MIB views which are being used by security groups cannot be deleted.

Notification
SNMPv3 notification is an enhancement to the concept of SNMP traps. Notifications are messages sent from an agent to the network manager, typically in response to some state change on the agent system. With SNMPv3, you can define precisely which traps you want sent, to which receiver by defining filter profiles to use for the notification receivers. To configure notifications, you will configure a target address for the process that receives the notification, a target parameters name, and a list of notification tags. The target parameters specify the security and message processing models to use for the notifications to the target. The target parameters name also points to the filter profile used to filter the notifications. Finally, the notification tags are added to a notification table so that any target addresses using that tag will receive notifications.

Target Addresses
A target address is similar to the earlier concept of a trap receiver. To configure a target address, use the following command: configure snmpv3 add target-addr {hex} <addr name> param {hex} <param name> ipaddress <ip address> {transport-port <port>} {from <source IP address>} {tag-list {hex} <tag>, {hex} <tag>, ...} {volatile} In configuring the target address you will supply an address name that will be used to identify the target address, a parameters name that will indicate the message processing model and security for the messages sent to the target address, and the IP address and port for the receiver. The parameters name also is used to indicate the filter profile used for notifications. The target parameters will be discussed in the section Target Parameters. The from option sets the source IP address in the notification packets. The tag-list option allows you to associate a list of tags with the target address. The tag defaultNotify is set by default. Tags are discussed in the section Notification Tags. To display target addresses, use the following command: show snmpv3 target-addr {{hex} <addr name>

70

ExtremeWare 7.1.0 Software User Guide

Using SNMP

To delete a single target address or all target addresses, use the following command:
configure snmpv3 delete target-addr [{{hex} <addr name>} | all]

Target Parameters
Target parameters specify the message processing model, security model, security level, and user name (security name) used for messages sent to the target address. See the sections Message Processing and Users, Groups, and Security for more details on these topics. In addition, the target parameter name used for a target address points to a filter profile used to filter notifications. When you specify a filter profile, you will associate it with a parameter name, so you will need to create different target parameter names if you will use different filters for different target addresses. Use the following command to create a target parameter name, and set the message processing and security settings associated with it:
configure snmpv3 add target-params {hex} <param name> user {hex} <user name> mp-model [snmpv1 | snmpv2c | snmpv3] sec-model [snmpv1 | snmpv2c | usm] {sec-level [noauth | authnopriv | priv]} {volatile}

To display the options associated with a target parameters name, or all target parameters names, use the following command:
show snmpv3 target-params {{hex} <param name>}

To delete one or all the target parameters, use the following command: configure snmpv3 delete target-params [{{hex} <param name>} | all]

Filter Profiles and Filters

A filter profile is a collection of filters that specifies which notifications should be sent to a target address. A filter is defined by a MIB subtree and mask, and by whether that subtree and mask is included or excluded from notification. When you create a filter profile, you are only associating a filter profile name with a target parameter name. The filters that make up the profile are created and associated with the profile using a different command. To create a filter profile, use the following command:
configure snmpv3 add filter-profile {hex} <profile name> param {hex} <param name> {volatile}

Once the profile name is created, you can associate filters with it using the following command: configure snmpv3 add filter {hex} <profile name> {hex} subtree <object identifier> {/<subtree mask>} type [included | excluded] {volatile} The MIB subtree and mask are discussed in the section MIB Access Control, as filters are closely related to MIB views. You can add filters together, including and excluding different subtrees of the MIB until your filter meets your needs. To display the association between parameter names and filter profiles, use the following command: show snmpv3 filter-profile {{hex} <profile name>} {{hex} <param name>} To display the filters that belong a filter profile, use the following command: show snmpv3 filter {{hex} <profile name> {{subtree} <object identifier>} To delete a filter or all filters from a filter profile, use the following command:

ExtremeWare 7.1.0 Software User Guide

71

Managing the Switch

configure snmpv3 delete filter [all | [{hex} <profile name> {subtree <object identifier>}]] To remove the association of a filter profile or all filter profiles with a parameter name, use the following command: configure snmpv3 delete filter-profile [all |{hex}<profile name> {param {hex}<param name>}]

Notification Tags
When you create a target address, you associate a list of notification tags with the target, or by default, the defaultNotify tag is associated with the target. When notifications are generated, only targets associated with tags currently in an internal structure, called snmpNotifyTable, will be notified. To add an entry to the table, use the following command:
configure snmpv3 add notify {hex} <notify name> tag {hex} <tag> {volatile}

Any targets associated with tags in the snmpNotifyTable will be notified, based on the filter profile associated with the target. To display the notifications that are set, use the following command: show snmpv3 notify {{hex} <notify name>} To delete an entry from the snmpNotifyTable, use the following command: configure snmpv3 delete notify [{{hex} <notify name>} | all-non-defaults] You cannot delete the default entry from the table, so any targets configured with the defaultNotify tag will always receive notifications consistent with any filter profile specified.

Configuring Notifications
Since the target parameters name is used to point to a number of objects used for notifications, configure the target parameter name entry first. You can then configure the target address, filter profiles and filters, and any necessary notification tags.

Authenticating Users
ExtremeWare provides two methods to authenticate users who login to the switch: RADIUS client TACACS+ NOTE You cannot configure RADIUS and TACACS+ at the same time.

RADIUS Client
Remote Authentication Dial In User Service (RADIUS, RFC 2138) is a mechanism for authenticating and centrally administrating access to network nodes. The ExtremeWare RADIUS client implementation allows authentication for Telnet, Vista, or console access to the switch.

72

ExtremeWare 7.1.0 Software User Guide

Using Network Login

TACACS+
Terminal Access Controller Access Control System Plus (TACACS+) is a mechanism for providing authentication, authorization, and accounting on a centralized server, similar in function to the RADIUS client. The ExtremeWare version of TACACS+ is used to authenticate prospective users who are attempting to administer the switch. TACACS+ is used to communicate between the switch and an authentication database.

Configuring RADIUS Client and TACACS+

For detailed information about configuring a RADIUS client or TACACS+, see Chapter 11.

Using Network Login

Network login is a feature designed to control the admission of user packets into a network by giving addresses only to users that have been properly authenticated. Network login is controlled by an administrator on a per port, per VLAN basis and uses an integration of DHCP, user authentication over the web interface, and, sometimes, a RADIUS server to provide a user database or specific configuration details. When network login is enabled on a port in a VLAN, that port will not forward any packets until authentication takes place. For detailed information about using Network login, see Chapter 11.

Using the Simple Network Time Protocol

ExtremeWare supports the client portion of the Simple Network Time Protocol (SNTP) Version 3 based on RFC1769. SNTP can be used by the switch to update and synchronize its internal clock from a Network Time Protocol (NTP) server. When enabled, the switch sends out a periodic query to the indicated NTP server, or the switch listens to broadcast NTP updates. In addition, the switch supports the configured setting for Greenwich Mean time (GMT) offset and the use of Daylight Saving Time. These features have been tested for year 2000 compliance.

Configuring and Using SNTP

To use SNTP, follow these steps: 1 Identify the host(s) that are configured as NTP server(s). Additionally, identify the preferred method for obtaining NTP updates. The options are for the NTP server to send out broadcasts, or for switches using NTP to query the NTP server(s) directly. A combination of both methods is possible. You must identify the method that should be used for the switch being configured. 2 Configure the Greenwich Mean Time (GMT) offset and Daylight Saving Time preference. The command syntax to configure GMT offset and usage of Daylight Saving Time is as follows:
configure timezone {name <std_timezone_ID>} <GMT_offset> {autodst {name <dst_timezone_ID>} {<dst_offset>} {begins [every <floatingday> | on <absoluteday>] {at <time_of_day>} {ends [every <floatingday> | on <absoluteday>] {at <time_of_day>}}}

ExtremeWare 7.1.0 Software User Guide

73

Managing the Switch

By default, Daylight Saving Time is assumed to begin on the first Sunday in April at 2:00 AM, and end the last Sunday in October at 2:00 AM, and be offset from standard time by one hour. If this is the case in your timezone, you can set up automatic daylight savings adjustment with the command:
configure timezone <GMT_offset> autodst

If your timezone uses starting and ending dates and times that differ from the default, you can specify the starting and ending date and time in terms of a floating day, as follows:
configure timezone name MET 60 autodst name MDT begins every last sunday march at 1 ends every last sunday october at 1

You can also specify a specific date and time, as shown in the following command.
configure timezone name NZST 720 autodst name NZDT 60 begins every first sunday october at 2 ends on 3/16/2002 at 2

The optional timezone IDs are used to identify the timezone in display commands such as show switch. Table 11 describes the command options in detail: Table 11: Time Zone Configuration Command Options
GMT_offset std-timezone-ID autodst dst-timezone-ID dst_offset floating_day Specifies a Greenwich Mean Time (GMT) offset, in + or - minutes. Specifies an optional name for this timezone specification. May be up to six characters in length. The default is an empty string. Enables automatic Daylight Savings Time. Specifies an optional name for this DST specification. May be up to six characters in length. The default is an empty string. Specifies an offset from standard time, in minutes. Value is in the range of 1 to 60. Default is 60 minutes. Specifies the day, week, and month of the year to begin or end DST each year. Format is: <week><day><month> where: <week> is specified as [first | second | third | fourth | last] or 1-5 <day> is specified as [sunday | monday | tuesday | wednesday | thursday | friday | saturday] or 1-7 (where 1 is Sunday) <month> is specified as [january | february | march | april | may | june | july | august | september | october | november | december] or 1-12

Default for beginning is first sunday april; default for ending is last sunday october. absolute_day Specifies a specific day of a specific year on which to begin or end DST. Format is: <month>/<day>/<year> where: time_of_day noautodst <month> is specified as 1-12 <day> is specified as 1-31 <year> is specified as 1970 - 2035

The year must be the same for the begin and end dates. Specifies the time of day to begin or end Daylight Savings Time. May be specified as an hour (0-23) or as hour:minutes. Default is 2:00. Disables automatic Daylight Savings Time.

Automatic Daylight Savings Time (DST) changes can be enabled or disabled. The default setting is enabled. To disable automatic DST, use the command:
configure timezone {name <std_timezone_ID>} <GMT_offset> noautodst

74

ExtremeWare 7.1.0 Software User Guide

Using the Simple Network Time Protocol

3 Enable the SNTP client using the following command:

enable sntp-client

Once enabled, the switch sends out a periodic query to the NTP servers defined later (if configured) or listens to broadcast NTP updates from the network. The network time information is automatically saved into the on-board real-time clock. 4 If you would like this switch to use a directed query to the NTP server, configure the switch to use the NTP server(s). If the switch listens to NTP broadcasts, skip this step. To configure the switch to use a directed query, use the following command:
configure sntp-client [primary | secondary] server <host name/ip>

NTP queries are first sent to the primary server. If the primary server does not respond within 1 second, or if it is not synchronized, the switch queries the secondary server (if one is configured). If the switch cannot obtain the time, it restarts the query process. Otherwise, the switch waits for the sntp-client update interval before querying again. 5 Optionally, the interval for which the SNTP client updates the real-time clock of the switch can be changed using the following command:
configure sntp-client update-interval <seconds>

The default sntp-client update-interval value is 64 seconds. 6 You can verify the configuration using the following commands: show sntp-client This command provides configuration and statistics associated with SNTP and its connectivity to the NTP server. show switch This command indicates the GMT offset, the Daylight Savings Time configuration and status, and the current local time. NTP updates are distributed using GMT time. To properly display the local time in logs and other timestamp information, the switch should be configured with the appropriate offset to GMT based on geographical location. Table 12 describes GMT offsets.

Table 12: Greenwich Mean Time Offsets

GMT Offset in Hours +0:00 GMT Offset in Minutes Common Time Zone References +0 GMT - Greenwich Mean UT or UTC - Universal (Coordinated) WET - Western European -1:00 -2:00 -3:00 -4:00 -5:00 -6:00 -7:00 -60 -120 -180 -240 -300 -360 -420 AST - Atlantic Standard EST - Eastern Standard CST - Central Standard MST - Mountain Standard WAT - West Africa AT - Azores Brasilia, Brazil; Buenos Aires, Argentina; Georgetown, Guyana; Caracas; La Paz Bogota, Columbia; Lima, Peru; New York, NY, Trevor City, MI USA Mexico City, Mexico Saskatchewan, Canada Azores, Cape Verde Islands

Cities London, England; Dublin, Ireland; Edinburgh, Scotland; Lisbon, Portugal; Reykjavik, Iceland; Casablanca, Morocco

ExtremeWare 7.1.0 Software User Guide

75

Managing the Switch

Table 12: Greenwich Mean Time Offsets (continued)

GMT Offset in Hours -8:00 -9:00 -10:00 GMT Offset in Minutes Common Time Zone References -480 -540 -600 PST - Pacific Standard YST - Yukon Standard AHST - Alaska-Hawaii Standard CAT - Central Alaska HST - Hawaii Standard -11:00 -12:00 +1:00 -660 -720 +60 NT - Nome IDLW - International Date Line West CET - Central European FWT - French Winter MET - Middle European MEWT - Middle European Winter SWT - Swedish Winter +2:00 +120 EET - Eastern European, Russia Zone 1 Athens, Greece; Helsinki, Finland; Istanbul, Turkey; Jerusalem, Israel; Harare, Zimbabwe Kuwait; Nairobi, Kenya; Riyadh, Saudi Arabia; Moscow, Russia; Tehran, Iran Abu Dhabi, UAE; Muscat; Tblisi; Volgograd; Kabul New Delhi, Pune, Allahabad, India Paris, France; Berlin, Germany; Amsterdam, The Netherlands; Brussels, Belgium; Vienna, Austria; Madrid, Spain; Rome, Italy; Bern, Switzerland; Stockholm, Sweden; Oslo, Norway

Cities Los Angeles, CA, Cupertino, CA, Seattle, WA USA

+3:00 +4:00 +5:00 +5:30 +6:00 +7:00 +8:00 +9:00 +10:00

+180 +240 +300 +330 +360 +420 +480 +540 +600

BT - Baghdad, Russia Zone 2 ZP4 - Russia Zone 3 ZP5 - Russia Zone 4 IST India Standard Time ZP6 - Russia Zone 5 WAST - West Australian Standard CCT - China Coast, Russia Zone 7 JST - Japan Standard, Russia Zone 8 EAST - East Australian Standard GST - Guam Standard Russia Zone 9

+11:00 +12:00

+660 +720 IDLE - International Date Line East NZST - New Zealand Standard NZT - New Zealand Wellington, New Zealand; Fiji, Marshall Islands

76

ExtremeWare 7.1.0 Software User Guide

Using the Simple Network Time Protocol

SNTP Example
In this example, the switch queries a specific NTP server and a backup NTP server. The switch is located in Cupertino, CA, and an update occurs every 20 minutes. The commands to configure the switch are as follows:
configure timezone -480 autodst configure sntp-client update interval 1200 enable sntp-client configure sntp-client primary server 10.0.1.1 configure sntp-client secondary server 10.0.1.2

ExtremeWare 7.1.0 Software User Guide

77

Managing the Switch

78

ExtremeWare 7.1.0 Software User Guide

Configuring Slots and Ports on a Switch

This chapter covers the following topics: Configuring a Slot on a Modular Switch on page 79 Configuring Ports on a Switch on page 81 Jumbo Frames on page 84 Load Sharing on the Switch on page 86 Switch Port-Mirroring on page 90 Extreme Discovery Protocol on page 91 Software-Controlled Redundant Port and Smart Redundancy on page 92 Performance Enhancements for Load Sharing on page 90

Configuring a Slot on a Modular Switch

If a slot has not been configured for a particular type of module, then any type of module is accepted in that slot, and a default port and VLAN configuration is automatically generated. Once any port on the module is configured (for example, a VLAN association, a VLAN tag configuration, or port parameters), all the port information and the module type for that slot must be saved to non-volatile storage. Otherwise, if the modular switch is rebooted or the module is removed from the slot, the port, VLAN, and module configuration information is not saved.

NOTE For information on saving the configuration, see Appendix A. You can configure the modular switch with the type of I/O module that is installed in each slot. To do this, use the following command:
configure slot <slot number> module

You can also preconfigure the slot before inserting the module. This allows you to begin configuring the module and ports before installing the module in the chassis. If a slot is configured for one type of module, and a different type of module is inserted, the inserted module is put into a mismatch state, and is not brought online. To use the new module type in a slot,

ExtremeWare 7.1.0 Software User Guide

79

Configuring Slots and Ports on a Switch

the slot configuration must be cleared or configured for the new module type. To clear the slot of a previously assigned module type, use the following command:
clear slot <slot number>

All configuration information related to the slot and the ports on the module is erased. If a module is present when you issue this command, the module is reset to default settings. To display information about a particular slot, use the following command:
show slot {<slot number>}

Information displayed includes: Card type, serial number, part number. Current state (power down, operational, diagnostic, mismatch). Port information. If no slot is specified, information for all slots is displayed.

Mode of Operation (Alpine 3802)

The Alpine 3802 has three modes of switch operation that impact the type and number of modules supported in the chassis. To configure the mode of operation for the Alpine 3802, use the following command:
configure switch {auto | extended | standard}

The three modes of switch operation are: ExtendedIn extended mode, all slots (slots 1, 2, and 3) are enabled. Slot 1 supports all existing Alpine I/O modules: Alpine Ethernet I/O modules (modules with a green stripe on the front of the module) and Alpine Access I/O modules (modules with a silver stripe on the front of the module). Slots 2 and 3 support only Alpine Access I/O modules (silver stripe). StandardIn standard mode, only slots 1 and 2 are enabled. Slot 3 is disabled. Slots 1 and 2 support all existing Alpine I/O modules: Alpine Ethernet I/O modules (green stripe) and Alpine Access I/O modules (silver stripe). AutoIn auto mode, the switch determines if it is in standard or extended mode depending upon the type of modules installed in the chassis or the slot preconfigurations. If an Alpine I/O module with a green stripe (for example, an FM-32Ti module) is installed or preconfigured in slot 2, the switch operates in standard mode. If an Alpine I/O module with a silver stripe (for example, a WM-4Ti module) is installed or preconfigured in slots 2 or 3, the switch operates in extended mode. By default, the Alpine 3802 operates in auto mode. If you insert a module into the Alpine 3802 that is not allowed in a particular slot, the switch logs an error to the syslog. For example, if you insert a GM-WDMi module in slot 3, a module type not supported in slot 3, the switch logs an error.

80

ExtremeWare 7.1.0 Software User Guide

Configuring Ports on a Switch

Configuring Ports on a Switch

On a modular switch, the port number is a combination of the slot number and the port number. The nomenclature for the port number is as follows:
slot:port

For example, if a G4X I/O module (having a total of four ports) is installed in slot 2 of the BlackDiamond 6808 chassis, the following ports are valid: 2:1 2:2 2:3 2:4 You can also use wildcard combinations (*) to specify multiple modular slot and port combinations. The following wildcard combinations are allowed: slot:*Specifies all ports on a particular I/O module. slot:x-slot:ySpecifies a contiguous series of ports on a particular I/O module. slota:x-slotb:ySpecifies a contiguous series of ports that begin on one I/O module and end on another I/O module.

Enabling and Disabling Switch Ports

By default, all ports are enabled. To enable or disable one or more ports on a modular switch, use the following command:
[enable | disable] ports [all | mgmt | <portlist>]

To enable or disable one or more ports on a stand-alone switch, use the following command:
[enable | disable] ports [ all | <portlist>]

For example, to disable slot 7, ports 3, 5, and 12 through 15 on a modular switch, use the following command:
disable ports 7:3,7:5,7:12-7:15

For example, to disable ports 3, 5, and 12 through 15 on a stand-alone switch, use the following command:
disable ports 3,5,12-15

Even though a port is disabled, the link remains enabled for diagnostic purposes.

Configuring Switch Port Speed and Duplex Setting

By default, the switch is configured to use autonegotiation to determine the port speed and duplex setting for each port. You can manually configure the duplex setting and the speed of 10/100 Mbps ports, and you can manually configure the duplex setting of Gigabit Ethernet ports. 10BASE-T and 100BASE-TX ports can connect to either 10BASE-T or 100BASE-T networks. By default, the ports autonegotiate port speed. You can also configure each port for a particular speed (either 10 Mbps or 100 Mbps).

ExtremeWare 7.1.0 Software User Guide

81

Configuring Slots and Ports on a Switch

Gigabit Ethernet ports are statically set to 1 Gbps, and their speed cannot be modified. VDSL ports default to 10 Mbps, and their speed can be configured as 5 Mbps, 10 Mbps, or to support the European Telecommunications Standards Institute (ETSI) VDSL standard, ETSI Plan 997. To configure VDSL ports, use the following command:
configure ports <portlist> vdsl [5meg | 10meg | etsi]

All ports on a stand-alone switch can be configured for half-duplex or full-duplex operation. By default, the ports autonegotiate the duplex setting. To configure port speed and duplex setting, use the following command:
configure ports <portlist> auto off {speed [10 | 100 | 1000 | 10000]} duplex [half | full]

To configure the system to autonegotiate, use the following command:

configure ports <portlist> auto on

Flow control is fully supported only on Gigabit Ethernet ports. Gigabit ports both advertise support and respond to pause frames. 10/100 Mbps Ethernet ports also respond to pause frames, but do not advertise support. Neither 10/100 Mbps or Gigabit Ethernet ports initiate pause frames. Flow Control is enabled or disabled as part of autonegotiation. If autonegotiation is set to off, flow control is disabled. When autonegotiation is turned on, flow control is enabled.

Turning Off Autonegotiation for a Gigabit Ethernet Port

In certain interoperability situations, you may need to turn autonegotiation off on a Gigabit Ethernet port. Even though a Gigabit Ethernet port runs only at full duplex, you must specify the duplex setting.

NOTE 1000BASE-TX ports support only autonegotiation. The following example turns autonegotiation off for port 1 on a G4X or G6X module located in slot 1 of a modular switch:
configure ports 1:1 auto off duplex full

The following example turns autonegotiation off for port 4 (a Gigabit Ethernet port) on a stand-alone switch:
configure ports 4 auto off duplex full

Turning Off Autopolarity Detection for an Ethernet Port

The autopolarity feature on the Summit48si switch allows the system to detect and respond to the Ethernet cable type (straight-through vs. crossover cable) used to make the connection to the switch port. When the autopolarity feature is enabled, the system causes the Ethernet link to come up regardless of the cable type connected to the port. When the autopolarity feature is disabled, the link will come up only when a crossover cable is connected to the port. The autopolarity feature is supported only on the 10BASE-T and 100BASE-TX switch ports, and enabled by default.

82

ExtremeWare 7.1.0 Software User Guide

Configuring Ports on a Switch

To disable or enable autopolarity detection, use the following command:

configure ports [<portlist> | all] auto-polarity [off | on]

where the following is true: portlistSpecifies one or more ports on the switch allSpecifies all of the ports on the switch offDisables the autopolarity detection feature on the specified ports onEnables the autopolarity detection feature on the specified ports Under certain conditions, you might opt to turn autopolarity off on one or more 10BASE-T and 100BASE-TX ports. The following example turns autopolarity off for ports 3-5 on a Summit48si switch:
configure ports 3-5 auto-polarity off

NOTE If you attempt to invoke this command on a Gigabit Ethernet switch port, the system displays a message indicating that the specified port is not supported by this feature. When autopolarity is disabled on one or more Ethernet ports, you can verify that status by using the command:
show configuration

This command will list the ports for which the feature has been disabled. You can also verify the current autopolarity status by using the command:
show ports {<portlist> | all} info detail

Configuring Link Detection

ExtremeWare contains an interrupt service routine (ISR) that sends interrupts when links transition. If a link continuously transitions, causing the ISR to send continuous interrupts, the middle layer filter filters out the continuous interrupt messages. You can configure the interaction between these functions using the following command:
configure port <portlist> link-detection-level <link detection level>

Configuring Interpacket Gap for 10 Gigabit Ethernet Ports

You can configure the Interpacket Gap for 10 Gigabit Ethernet ports only. The Interpacket Gap, sometimes referred to as the Interframe Gap, is the transmit packet byte-time delay between successive data packets mandated by the IEEE for Ethernet networks. Byte-time is the amount of time it takes to transmit one byte on the link at the specified or negotiated link speed. The configured Interpacket Gap value has no effect on received packets. The default value is 16. The minimum and maximum allowed values range between 12 and 1023. The standard effective Interpacket Gap for 10 Gigabit Ethernet interfaces ranges between 12 and 1023. Some vendors' 10 Gigabit Ethernet interfaces drop packets when packets are transmitted using a value of 12. Thus, by increasing the Interpacket Gap, packet transmission is slowed and packet loss can be minimized or prevented. The Interpacket Gap value need not be modified when interconnecting

ExtremeWare 7.1.0 Software User Guide

83

Configuring Slots and Ports on a Switch

Extreme Networks switches over 10 Gigabit Ethernet links. Use the following command to modify the Interpacket Gap:
configure port <slot:port> interpacket-gap <byte_time>

Jumbo Frames
Jumbo frames are Ethernet frames that are larger than 1522 bytes, including four bytes used for the cyclic redundancy check (CRC). Extreme products support switching and routing of jumbo frames at wire-speed on all ports. Jumbo frames are used between endstations that support larger frame sizes for more efficient transfers of bulk data. Both endstations involved in the transfer must be capable of supporting jumbo frames. The switch only performs IP fragmentation, or participates in maximum transmission unit (MTU) negotiation on behalf of devices that support jumbo frames.

Enabling Jumbo Frames

To enable jumbo frame support, enable jumbo frames on the desired ports. To set the maximum jumbo frame size, use the following command:
configure jumbo-frame size <number>

The jumbo frame size range is 1523 to 9216. This value describes the maximum size of the frame in transit (on the wire), and includes 4 bytes of CRC plus another 4 bytes if 802.1Q tagging is being used. Set the MTU size for the VLAN, using the following command:
configure ip-mtu <size> vlan <vlan name>

The IP MTU default is 1500. The range is 1500-9194.

NOTE PoS or ATM must be rebooted if the IP-MTU configuration is changed. Next, enable support on the physical ports that will carry jumbo frames using the following command:
enable jumbo-frame ports [<portlist> | all]

NOTE Some network interface cards (NICs) have a configured maximum MTU size that does not include the additional 4 bytes of CRC. Ensure that the NIC maximum MTU size is at or below the maximum MTU size configured on the switch. Frames that are larger than the MTU size configured on the switch are dropped at the ingress port.

Path MTU Discovery

Using path MTU discovery, a source host assumes that the path MTU is the MTU of the first hop (which is known). The host sends all datagrams on that path with the dont fragment (DF) bit set, which restricts fragmentation. If any of the datagrams must be fragmented by an Extreme switch along

84

ExtremeWare 7.1.0 Software User Guide

Jumbo Frames

the path, the Extreme switch discards the datagrams and returns an ICMP Destination Unreachable message to the sending host, with a code meaning fragmentation needed and DF set. When the source host receives the message (sometimes called a Datagram Too Big message), the source host reduces its assumed path MTU and retransmits the datagrams. The path MTU discovery process ends when one of the following is true: The source host sets the path MTU low enough that its datagrams can be delivered without fragmentation. The source host does not set the DF bit in the datagram headers. If it is willing to have datagrams fragmented, a source host can choose not to set the DF bit in datagram headers. Normally, the host continues to set DF in all datagrams, so that if the route changes and the new path MTU is lower, the host can perform path MTU discovery again.

IP Fragmentation with Jumbo Frames

ExtremeWare supports the fragmenting of IP packets. If an IP packet originates in a local network that allows large packets and those packets traverse a network that limits packets to a smaller size, the packets are fragmented instead of discarded. This feature is designed to be used in conjunction with jumbo frames. Frames that are fragmented are not processed at wire-speed within the switch fabric.

NOTE Jumbo frame-to-jumbo frame fragmentation is not supported. Only jumbo frame-to-normal frame fragmentation is supported. To configure VLANs for IP fragmentation, follow these steps: 1 Enable jumbo frames on the incoming port. 2 Add the port to a VLAN. 3 Assign an IP address to the VLAN. 4 Enable ipforwarding on the VLAN. 5 Set the MTU size for the VLAN, using the following command:
configure ip-mtu <size> vlan <vlan name>

The ip-mtu value can be 1500 or 9194, with 1500 the default. NOTE To set the MTU size greater than 1500, all ports in the VLAN must have jumbo frames enabled.

IP Fragmentation within a VLAN

ExtremeWare supports IP fragmentation within a VLAN. This feature does not require you to configure the MTU size. To use IP fragmentation within a VLAN, follow these steps: 1 Enable jumbo frames on the incoming port. 2 Add the port to a VLAN.

ExtremeWare 7.1.0 Software User Guide

85

Configuring Slots and Ports on a Switch

3 Assign an IP address to the VLAN. 4 Enable ipforwarding on the VLAN. If you leave the MTU size configured to the default value, when you enable jumbo frame support on a port on the VLAN you will receive a warning that the ip-mtu size for the VLAN is not set at maximum jumbo frame size. You can ignore this warning if you want IP fragmentation within the VLAN, only. However, if you do not use jumbo frames, IP fragmentation can only be used for traffic that stays within the same VLAN. For traffic that is set to other VLANs, to use IP fragmentation, all ports in the VLAN must be configured for jumbo frame support.

Load Sharing on the Switch

Load sharing allows you to increase bandwidth and availability by using a group of ports to carry traffic in parallel between switches. Load sharing allows the switch to use multiple ports as a single logical port. For example, VLANs see the load-sharing group as a single logical port. Most load-sharing algorithms guarantee packet sequencing between clients. If a port in a load-sharing group fails, traffic is redistributed to the remaining ports in the load-sharing group. If the failed port becomes active again, traffic is redistributed to include that port.

NOTE Load sharing must be enabled on both ends of the link or a network loop may result. The load-sharing types (dynamic, static) must match, but the load-sharing algorithms do not need to be the same on both ends.

Dynamic Versus Static Load Sharing

The two broad categories of load sharing supported on Extreme Network switches are dynamic load sharing and static load sharing: Dynamic load sharingA grouping of ports that use IEEE 802.3ad load sharing to dynamically determine if load sharing is possible, and automatically configure load sharing when possible. Uses Link Aggregation Control Protocol (LACP), part of the IEEE 802.3ad standard, to allow the switch to dynamically reconfigure the sharing groups. The group is only enabled when LACP detects that the other side is also using LACP, and wants these ports to be in a group. Static load sharingA grouping of ports specifically configured to load share. The switch ports at each end must be configured as part of a load-sharing group. Additionally, you can choose the load-sharing algorithm used by the group. This feature is supported between Extreme Networks switches only, but may be compatible with third-party trunking or link-aggregation algorithms. Check with an Extreme Networks technical representative for more information.

Load-Sharing Algorithms
Load-sharing algorithms allow you to select the distribution technique used by the load-sharing group to determine the output port selection. Algorithm selection is not intended for use in predictive traffic engineering. You can only choose the algorithm used in static load sharing, as dynamic load sharing exclusively uses an address-based algorithm. You can configure one of three load-sharing algorithms on the switch, as follows:

86

ExtremeWare 7.1.0 Software User Guide

Load Sharing on the Switch

Port-basedUses the ingress port to determine which physical port in the load-sharing group is used to forward traffic out of the switch. Address-basedUses addressing information to determine which physical port in the load-sharing group to use for forwarding traffic out of the switch. Addressing information is based on the packet protocol, as follows: IP packetsUses the source and destination MAC and IP addresses, and the TCP port number. IPX packetsUses the source and destination MAC address, and IPX network identifiers. All other packetsUses the source and destination MAC address. Round-robinWhen the switch receives a stream of packets, it forwards one packet out of each physical port in the load-sharing group using a round-robin scheme. NOTE Using the round-robin algorithm, packet sequencing between clients is not guaranteed. If you do not explicitly select an algorithm, the port-based scheme is used. However, the address-based algorithm has a more even distribution and is the recommended choice, except when running MPLS, in which case port-based is recommended.

Configured IP Address-Based Load Sharing

When you configure load sharing, the switch examines a specific place in the packet to determine which egress port to use for forwarding traffic: For layer 2 load sharing, the switch uses the MAC source address and destination address. For layer 3 load sharing, the switch uses the IP source address and destination address. For layer 4 load sharing, the switch using the UDP or TCP well-known port number. You can control the field examined by the switch for IP address-based load sharing, using the following command:
configure sharing address-based <l2 | l2_l3 | l2_l3_l4>

where: l2Indicates that the switch should examine the MAC source and destination address. l3Indicates that the switch should examine the IP source and destination address. l4Indicates that the switch should examine the UDP or TCP well-known port number. This feature is available for the address-based load-sharing algorithm, only. To verify your configuration, use the following command:
show sharing address-based

Configuring Switch Load Sharing

To set up a switch to load share among ports, you must create a load-sharing group of ports. The first port in the load-sharing group is configured to be the master logical port. This is the reference port used in configuration commands. It can be thought of as the logical port representing the entire port group.

ExtremeWare 7.1.0 Software User Guide

87

Configuring Slots and Ports on a Switch

All the ports in a load-sharing group must have the same exact configuration, including auto negotiation, duplex setting, ESRP host attach or dont-count, and so on. All the ports in a load-sharing group must also be of the same bandwidth class. The following rules apply: One group can contain up to 8 ports. The ports in the group do not need to be contiguous. If dynamic load sharing is used (LACP), the ports in the group must be on the same I/O module. A load share group that spans multiple modules must use ports that are all of the same maximum bandwidth capability. On BlackDiamond 6804 and 6808 chassis, the following limitation applies: The chassis must use the MSM-3 if you are going to configure a load share group that spans multiple modules (cross-module trunking). On BlackDiamond 6816 chassis, the following limitation applies: The ports in the group must be on the same I/O module. To define a load-sharing group, you assign a group of ports to a single, logical port number. To enable or disable a load-sharing group, use the following commands:
enable sharing <port> grouping <portlist> {dynamic | algorithm {port-based | address-based | round-robin}} disable sharing <port>

NOTE Do not disable a port that is part of a load-sharing group. Disabling the port prevents it from forwarding traffic, but still allows the link to initialize. As a result, a partner switch does not receive a valid indication that the port is not in a forwarding state, and the partner switch will continue to forward packets.

NOTE BlackDiamond modules implement local switching; packets that ingress and egress on the same module are not passed to the chassis backplane but switched on the module from the ingress to the egress port. For this reason, packets arriving on a module that contains any of the configured cross-module load sharing ports will only be shared with the ports on that module, and not with the ports on any other modules.

Loopback Detection
Each port may enable loop detection. This optional feature detects that a port has been looped back to the local system. If a loopback is detected, the port is disabled. Note that loopbacks may exist between different ports. The feature will disable any port that both has the feature enabled, and receives an LACP message that was sent from the local system. To enable or disable loopback detection, use the following commands:
enable lbdetect port <portlist> [retry-timeout<seconds>]

88

ExtremeWare 7.1.0 Software User Guide

Load Sharing on the Switch

disable lbdetect port <portlist>

Load-Sharing Examples
This section provides examples of how to define load-sharing on modular and stand-alone switches.

Cross-Module Load Sharing on a Modular Switch

Cross-module load sharing is available on Alpine chassis, and on BlackDiamond 6804 and 6808 chassis that use the MSM-3. The following example defines a load-sharing group that contains ports 9 through 12 on slot 3, ports 7 through 10 on slot 5, and uses the first port in the slot 3 group as the master logical port 9:
enable sharing 3:9 grouping 3:9-3:12, 5:7-5:10

In this example, logical port 3:9 represents physical ports 3:9 through 3:12 and 5:7 through 5:10. When using load sharing, you should always reference the master logical port of the load-sharing group (port 3:9 in the previous example) when configuring or viewing VLANs. VLANs configured to use other ports in the load-sharing group will have those ports deleted from the VLAN when load sharing becomes enabled. For BlackDiamond chassis, packets are locally switched when possible, even with load sharing enabled. For example, in the configuration above, packets received on port 3:2 that are destined for the load-sharing group will only be shared with the ports 3:9-3:12 and not with ports 5:7-5:10. In contrast, packets received on port 2:2 that are destined for the load-sharing group will be shared with the all the ports in the load-sharing group (ports 3:9-3:12 and 5:7-5:10).

Single-Module Load Sharing on a Modular Switch

Single-module load sharing is supported on all modular switches. The BlackDiamond 6816 chassis, and the BlackDiamond 6804 and 6808 chassis without the MSM-3, support only single-module load sharing. The following example defines a load-sharing group that contains ports 9 through 12 on slot 3 and uses the first port as the master logical port 9:
enable sharing 3:9 grouping 3:9-3:12

In this example, logical port 3:9 represents physical ports 3:9 through 3:12. When using load sharing, you should always reference the master logical port of the load-sharing group (port 3:9 in the previous example) when configuring or viewing VLANs. VLANs configured to use other ports in the load-sharing group will have those ports deleted from the VLAN when load sharing becomes enabled.

Load Sharing on a Stand-Alone Switch

The following example defines a load-sharing group that contains ports 9 through 12, and uses the first port in the group as the master logical port 9:
enable sharing 9 grouping 9-12

In this example, logical port 9 represents physical ports 9 through 12.

ExtremeWare 7.1.0 Software User Guide

89

Configuring Slots and Ports on a Switch

When using load sharing, you should always reference the master logical port of the load-sharing group (port 9 in the previous example) when configuring or viewing VLANs. VLANs configured to use other ports in the load-sharing group will have those ports deleted from the VLAN when load sharing becomes enabled.

NOTE Do not disable a port that is part of a load-sharing group. Disabling the port prevents it from forwarding traffic, but still allows the link to initialize. As a result, a partner switch does not receive a valid indication that the port is not in a forwarding state, and the partner switch will continue to forward packets.

Verifying the Load-Sharing Configuration

The screen output resulting from the show ports sharing command lists the ports that are involved in load sharing and the master logical port identity.

Performance Enhancements for Load Sharing

You can modify the backplane load-sharing policy on BlackDiamond switches to enhance performance. The default backplane load-sharing policy is port-based. Selecting a policy for a particular situation will depend on the type of traffic and network topology, however, for many situations an address-based policy will enhance performance over other policies. You must save for changes to be saved across reboots. To configure the switch backplane load-sharing policy, use the following command:
configure backplane-ls-policy [address-based | port-based | round-robin]

and specify the following: address-basedaddress-based load-sharing algorithm port-basedport-based load-sharing algorithm round-robinround-robin load-sharing algorithm For more information about the load-sharing algorithms, see Load-Sharing Algorithms on page 86.

Switch Port-Mirroring
Port-mirroring configures the switch to copy all traffic associated with one or more ports. The monitor port can be connected to a network analyzer or RMON probe for packet analysis. The system uses a traffic filter that copies a group of traffic to the monitor port. The traffic filter can be defined based on one of the following criteria: Physical portAll data that traverses the port, regardless of VLAN configuration, is copied to the monitor port. VLANAll data to and from a particular VLAN, regardless of the physical port configuration, is copied to the monitor port. Virtual portAll data specific to a VLAN on a specific port is copied to the monitor port.

90

ExtremeWare 7.1.0 Software User Guide

Extreme Discovery Protocol

Up to eight mirroring filters and one monitor port can be configured. Once a port is specified as a monitor port, it cannot be used for any other function.

NOTE Frames that contain errors are not mirrored. The mirrored port transmits tagged or untagged frames. This allows you to mirror multiple ports or VLANs to a mirror port, while preserving the ability of a single protocol analyzer to track and differentiate traffic within a broadcast domain (VLAN) and across broadcast domains (for example, across VLANs when routing).

Modular Switch Port-Mirroring Example

The following example selects slot 7, port 3 as the mirror port, and sends all traffic coming into or out of a modular switch on slot 7, port 1 to the mirror port:
configure mirroring add port 7:1 enable mirroring to port 7:3

The following example sends all traffic coming into or out of the system on slot 8, port 1 and the VLAN default to the mirror port:
enable mirroring to port 8:4 configure mirroring add port 8:1 vlan default

Stand-alone Switch Port-Mirroring Example

The following example selects port 3 as the mirror port and sends all traffic coming into or out of the switch on port 1 to the mirror port:
enable mirroring to port 3 configure mirroring add port 1

The following example sends all traffic coming into or out of the switch on port 1 and the VLAN default to the mirror port:
configure mirroring add port 1 vlan default

Extreme Discovery Protocol

The Extreme Discovery Protocol (EDP) is used to gather information about neighbor Extreme Networks switches. EDP is used to by the switches to exchange topology information. EDP is also used by the Extreme Standby Router Protocol (ESRP), described in Chapter 14. Information communicated using EDP includes: Switch MAC address (switch ID). Switch software version information. Switch IP address. Switch VLAN-IP information. Switch port number.

ExtremeWare 7.1.0 Software User Guide

91

Configuring Slots and Ports on a Switch

EDP is enabled on all ports by default. To disable EDP on one or more ports, use the following command:
disable edp ports <portlist>

To enable EDP on specified ports, use the following command:

enable edp ports <portlist>

To view EDP port information on the switch, use the following command:
show edp

Software-Controlled Redundant Port and Smart Redundancy

Using the software-controlled redundant port feature you can back up a specified Ethernet port (primary) with a redundant, dedicated Ethernet port (backup). If the primary port fails, the switch will establish a link on the backup port and the backup port becomes active. Smart Redundancy is a feature that allows control over how the fail over from a backup port to the primary port is managed. If this feature is enabled, the switch will attempt to revert to the primary port as soon as it can be recovered. If the feature is disabled, the switch will only attempt to reset the primary port active if the backup port fails. Typical configurations of software-controlled redundant ports include dual-homing from a single switch to two different switches (shown in Figure 1) and redundant links between two switches (shown in Figure 2).

92

ExtremeWare 7.1.0 Software User Guide

Software-Controlled Redundant Port and Smart Redundancy

Figure 1: Dual-homed redundant link

10

11

12

13

14

15

16

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

Primary

Backup

17

4 5

20 21

EW_076

Figure 2: Redundant link between two switches

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

Primary

Backup

17

4 5

20 21

EW_075

Only one side of the link needs to be configured as redundant, since the redundant port link is held in standby state on both sides of the link.

ExtremeWare 7.1.0 Software User Guide

93

Configuring Slots and Ports on a Switch

Software-Controlled Redundant Load-Shared Port Groups

A load-shared group of Ethernet ports (primary group) can be backed up with a set of load-shared redundant Ethernet ports (backup group) similar to configuring individual redundant ports. If the primary load-shared group is active and any link in the group fails, the entire group fails over to the backup group. Smart Redundancy is not available for software-controlled redundant load-shared groups, so the switch will only attempt to revert to the primary group if a port in the backup group fails and the associated link in the primary group can be re-established.

Limitations of Software-Controlled Redundant Ports and Port Groups

Software-controlled redundant ports and port groups have the following limitations: Software-controlled redundant ports can only cover failures where both the TX and RX paths fail. For example, if only one optical fiber was damaged or disconnected, the software-controlled redundant port would not recognize this as a port failure, and no switch to the backup would occur. Auto-negotiation must be enabled on all ports that are associated with the redundant links. This includes the primary and backup ports or load-shared port groups, and the associated ports on the far-end switch(es). For 10 Gigabit Ethernet ports auto-negotiation is not supported, nor is it required for this feature to work. You cannot configure hardware redundant ports (such as ports 49 and 50 on a Summit48i) as software controlled redundant ports. The primary port configuration is not automatically applied to the backup port., so you must separately configure both the primary and backup ports. This includes items such as VLANs, QoS, and access control lists. The port speeds of software controlled redundant ports must be identical. You can configure only one redundant port for each primary port. You cannot load share two physical ports that are configured as software-controlled redundant ports. Members of the same load sharing trunk cannot be configured as software-controlled redundant ports. Dual-homing of load-shared, software-controlled redundant port groups is not supported.

Configuring Software-Controlled Redundant Ports

When provisioning software-controlled redundant ports, configure only one side of the link as redundant. In Figure 1 and Figure 2 only the ports on the lower switch would be configured as redundant. In order to enable the software-controlled redundant port feature the primary and backup ports must be set up identically. This will include VLAN configuration, QoS settings, and any Access Control List configurations. Finally, all ports (primary, secondary, and both of the associated far-end ports) must be configured to have auto-negotiation enabled. To configure a software-controlled redundant port, use the following command:
configure ports <portlist> redundant <portlist>

The first port specified is the primary port. The second port specified is the redundant port. To unconfigure a software-controlled redundant port, use the following command:
unconfigure port <portlist> redundant

94

ExtremeWare 7.1.0 Software User Guide

Software-Controlled Redundant Port and Smart Redundancy

To configure the switch for the Smart Redundancy feature, use the following command:
enable smartredundancy <portlist>

To disable the Smart Redundancy feature, use the following command:

disable smartredundancy <portlist>

Configuring Software-Controlled Redundant Load-Shared Port Groups

Configuring redundancy on load-shared port groups is similar to that for an individual port. Each port in the load-shared group must have a uniquely associated backup port. Each of these primary/backup port pairs must be provisioned identically. It is important to ensure that the configure command is entered for each port in the group. If a backup port is not specified for a port in a load-shared group, it will not fail over and you would end up with a split group. In the following example, a primary load-sharing group 1:1, consisting of ports 1:1-4, is backed up by a software-controlled redundant port backup group 2:1, consisting of ports 2:1-4:
enable sharing 1:1 group 1:1-1:4 enable sharing 2:1 group 2:1-2:4 config ports 1:1-1:4 redundant 2:1-2:4

The following example is identical to the previous one, but each redundant port is configured individually:
enable enable config config config config sharing 1:1 group 1:1-1:4 sharing 2:1 group 2:1-2:4 ports 1:1 redundant 2:1 ports 1:2 redundant 2:2 ports 1:3 redundant 2:3 ports 1:4 redundant 2:4

ExtremeWare 7.1.0 Software User Guide

95

Configuring Slots and Ports on a Switch

96

ExtremeWare 7.1.0 Software User Guide

Virtual LANs (VLANs)

This chapter covers the following topics: Overview of Virtual LANs on page 97 Types of VLANs on page 98 VLAN Names on page 106 Configuring VLANs on the Switch on page 107 Displaying VLAN Settings on page 108 VLAN Tunneling (VMANs) on page 110 MAC-Based VLANs on page 112 VLAN Translation on page 115 Setting up Virtual Local Area Networks (VLANs) on the switch eases many time-consuming tasks of network administration while increasing efficiency in network operations.

Overview of Virtual LANs

The term VLAN is used to refer to a collection of devices that communicate as if they were on the same physical LAN. Any set of ports (including all ports on the switch) is considered a VLAN. LAN segments are not restricted by the hardware that physically connects them. The segments are defined by flexible user groups you create with the command line interface.

Benefits
Implementing VLANs on your networks has the following advantages: VLANs help to control trafficWith traditional networks, congestion can be caused by broadcast traffic that is directed to all network devices, regardless of whether they require it. VLANs increase the efficiency of your network because each VLAN can be set up to contain only those devices that must communicate with each other. VLANs provide extra securityDevices within each VLAN can only communicate with member devices in the same VLAN. If a device in VLAN Marketing must communicate with devices in VLAN Sales, the traffic must cross a routing device.

ExtremeWare 7.1.0 Software User Guide

97

Virtual LANs (VLANs)

VLANs ease the change and movement of devicesWith traditional networks, network administrators spend much of their time dealing with moves and changes. If users move to a different subnetwork, the addresses of each endstation must be updated manually.

Types of VLANs
VLANs can be created according to the following criteria: Physical port 802.1Q tag Ethernet, LLC SAP, or LLC/SNAP Ethernet protocol type MAC address A combination of these criteria

Port-Based VLANs
In a port-based VLAN, a VLAN name is given to a group of one or more ports on the switch. All ports are members of the port-based VLAN default. Before you can add any port to another port-based VLAN, you must remove it from the default VLAN, unless the new VLAN uses a protocol other than the default protocol any. A port can be a member of only one port-based VLAN. On the Summit7i switch in Figure 3, ports 9 through 14 are part of VLAN Marketing; ports 25 through 29 are part of VLAN Sales; and ports 21 through 24 and 30 through 32 are in VLAN Finance. Figure 3: Example of a port-based VLAN on the Summit7i switch

Marketing

Finance

Sales

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

EW_027

For the members of the different IP VLANs to communicate, the traffic must be routed by the switch, even if they are physically part of the same I/O module. This means that each VLAN must be configured as a router interface with a unique IP address.

98

ExtremeWare 7.1.0 Software User Guide

Types of VLANs

Spanning Switches with Port-Based VLANs

To create a port-based VLAN that spans two switches, you must do two things: 1 Assign the port on each switch to the VLAN. 2 Cable the two switches together using one port on each switch per VLAN. Figure 4 illustrates a single VLAN that spans a BlackDiamond switch and a Summit7i switch. All ports on the BlackDiamond switch belong to VLAN Sales. Ports 1 through 29 on the Summit 7i switch also belong to VLAN Sales. The two switches are connected using slot 8, port 4 on system 1 (the BlackDiamond switch), and port 29 on system 2 (the Summit7i switch). Figure 4: Single port-based VLAN spanning two switches

Sales
System 1
1 2 3 4 A B 5 6 7 8

System 2

10

11

12

13

14

15

16

17
1

18

19

20

21

22

23

24

25
2

26

27

28

29

30

31

32

EW_028

To create multiple VLANs that span two switches in a port-based VLAN, a port on system 1 must be cabled to a port on system 2 for each VLAN you want to have span across the switches. At least one port on each switch must be a member of the corresponding VLANs, as well. Figure 5 illustrates two VLANs spanning two switches. On system 2, ports 25 through 29 are part of VLAN Accounting; ports 21 through 24 and ports 30 through 32 are part of VLAN Engineering. On system 1, all port on slot 1 are part of VLAN Accounting; all ports on slot 8 are part of VLAN Engineering.

ExtremeWare 7.1.0 Software User Guide

99

Virtual LANs (VLANs)

Figure 5: Two port-based VLANs spanning two switches

System 1
1 2 3 4 A B 5 6 7 8

50015

Accounting
System 2

Engineering

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

EW_030

VLAN Accounting spans system 1 and system 2 by way of a connection between system 2, port 29 and system 1, slot 1, port 6. VLAN Engineering spans system 1 and system 2 by way of a connection between system 2, port 32, and system 1, slot 8, port 6. Using this configuration, you can create multiple VLANs that span multiple switches, in a daisy-chained fashion. Each switch must have a dedicated port for each VLAN. Each dedicated port must be connected to a port that is a member of its VLAN on the next switch.

Tagged VLANs
Tagging is a process that inserts a marker (called a tag) into the Ethernet frame. The tag contains the identification number of a specific VLAN, called the VLANid. NOTE The use of 802.1Q tagged packets may lead to the appearance of packets slightly bigger than the current IEEE 802.3/Ethernet maximum of 1,518 bytes. This may affect packet error counters in other devices, and may also lead to connectivity problems if non-802.1Q bridges or routers are placed in the path.

100

ExtremeWare 7.1.0 Software User Guide

Types of VLANs

Uses of Tagged VLANs

Tagging is most commonly used to create VLANs that span switches. The switch-to-switch connections are typically called trunks. Using tags, multiple VLANs can span multiple switches using one or more trunks. In a port-based VLAN, each VLAN requires its own pair of trunk ports, as shown in Figure 5. Using tags, multiple VLANs can span two switches with a single trunk. Another benefit of tagged VLANs is the ability to have a port be a member of multiple VLANs. This is particularly useful if you have a device (such as a server) that must belong to multiple VLANs. The device must have a NIC that supports 802.1Q tagging. A single port can be a member of only one port-based VLAN. All additional VLAN membership for the port must be accompanied by tags. In addition to configuring the VLAN tag for the port, the server must have a Network Interface Card (NIC) that supports 802.1Q tagging.

Assigning a VLAN Tag

Each VLAN may be assigned an 802.1Q VLAN tag. As ports are added to a VLAN with an 802.1Q tag defined, you decide whether each port will use tagging for that VLAN. The default mode of the switch is to have all ports assigned to the VLAN named default with an 802.1Q VLAN tag (VLANid) of 1 assigned. Not all ports in the VLAN must be tagged. As traffic from a port is forwarded out of the switch, the switch determines (in real time) if each destination port should use tagged or untagged packet formats for that VLAN. The switch adds and strips tags, as required, by the port configuration for that VLAN.

NOTE Packets arriving tagged with a VLANid that is not configured on a port will be discarded. Figure 6 illustrates the physical view of a network that uses tagged and untagged traffic.

ExtremeWare 7.1.0 Software User Guide

101

Virtual LANs (VLANs)

Figure 6: Physical diagram of tagged and untagged traffic

M = Marketing S = Sales

System 1

= Tagged port Marketing & Sales

M S S

802.1Q Tagged server

50015

M M
1

M
2

S S

S
3

S
4

System 2

EW_029

Figure 7 is a logical diagram of the same network. Figure 7: Logical diagram of tagged and untagged traffic

Marketing
System 1 Ports 1-4 & 9-12 System 2 Slot 1, Port 2 Slot 2, Ports 1-8 & 17-24 System 1 Port 25 * Port 29 * System 2 Slot 1, Port 1 *

Sales
System 1 Ports 5-8, 13-16 & 32 System 2 Slot 1, Port 3 Slot 1, Port 4 Slot 2, Ports 9-16 & 25-32

*Tagged Ports

EW_025

In Figure 6 and Figure 7: The trunk port on each switch carries traffic for both VLAN Marketing and VLAN Sales. The trunk port on each switch is tagged.

102

ExtremeWare 7.1.0 Software User Guide

Types of VLANs

The server connected to port 25 on system 1 has a NIC that supports 802.1Q tagging. The server connected to port 25 on system 1 is a member of both VLAN Marketing and VLAN Sales. All other stations use untagged traffic. As data passes out of the switch, the switch determines if the destination port requires the frames to be tagged or untagged. All traffic coming from and going to the server is tagged. Traffic coming from and going to the trunk ports is tagged. The traffic that comes from and goes to the other stations on this network is not tagged.

Mixing Port-Based and Tagged VLANs

You can configure the switch using a combination of port-based and tagged VLANs. A given port can be a member of multiple VLANs, with the stipulation that only one of its VLANs uses untagged traffic. In other words, a port can simultaneously be a member of one port-based VLAN and multiple tag-based VLANs. NOTE For the purposes of VLAN classification, packets arriving on a port with an 802.1Q tag containing a VLANid of zero are treated as untagged.

Protocol-Based VLANs
Protocol-based VLANs enable you to define a packet filter that the switch uses as the matching criteria to determine if a particular packet belongs to a particular VLAN. Protocol-based VLANs are most often used in situations where network segments contain hosts running multiple protocols. For example, in Figure 8, the hosts are running both the IP and NetBIOS protocols. The IP traffic has been divided into two IP subnets, 192.207.35.0 and 192.207.36.0. The subnets are internally routed by the switch. The subnets are assigned different VLAN names, Finance and Personnel, respectively. The remainder of the traffic belongs to the VLAN named MyCompany. All ports are members of the VLAN MyCompany.

ExtremeWare 7.1.0 Software User Guide

103

Virtual LANs (VLANs)

Figure 8: Protocol-based VLANs

192.207.35.1

192.207.36.1

My Company 192.207.35.0 Finance 192.207.36.0 Personnel

= IP traffic = All other traffic

BD_007

Predefined Protocol Filters

The following protocol filters are predefined on the switch: IP IPX NetBIOS DECNet IPX_8022 IPX_SNAP AppleTalk

Defining Protocol Filters

If necessary, you can define a customized protocol filter based on EtherType, Logical Link Control (LLC), and/or Subnetwork Access Protocol (SNAP). Up to six protocols may be part of a protocol filter. To define a protocol filter, follow these steps: 1 Create a protocol using the following command:
create protocol <protocol_name>

For example:
create protocol fred

104

ExtremeWare 7.1.0 Software User Guide

Types of VLANs

The protocol name can have a maximum of 32 characters. 2 Configure the protocol using the following command:
configure protocol <protocol_name> add <protocol_type> <hex_value>

Supported protocol types include: etypeEtherType. The values for etype are four-digit hexadecimal numbers taken from a list maintained by the IEEE. This list can be found at the following URL:
http://standards.ieee.org/regauth/ethertype/index.html

llcLLC Service Advertising Protocol (SAP). The values for llc are four-digit hexadecimal numbers that are created by concatenating a two-digit LLC Destination SAP (DSAP) and a two-digit LLC Source SAP (SSAP). snapEthertype inside an IEEE SNAP packet encapsulation. The values for snap are the same as the values for etype, described previously. For example:
configure protocol fred add llc feff configure protocol fred add snap 9999

A maximum of 15 protocol filters, each containing a maximum of six protocols, can be defined. On products that use the Inferno chip set, all 15 protocol filters can be active and configured for use. On all other platforms, no more than seven protocols can be active and configured for use.

NOTE For more information on SNAP for Ethernet protocol types, see TR 11802-5:1997 (ISO/IEC) [ANSI/IEEE std. 802.1H, 1997 Edition].

Deleting a Protocol Filter

If a protocol filter is deleted from a VLAN, the VLAN is assigned a protocol filter of none. You can continue to configure the VLAN. However, no traffic is forwarded to the VLAN until a protocol is assigned to it.

Precedence of Tagged Packets Over Protocol Filters

If a VLAN is configured to accept tagged packets on a particular port, incoming packets that match the tag configuration take precedence over any protocol filters associated with the VLAN.

ExtremeWare 7.1.0 Software User Guide

105

Virtual LANs (VLANs)

VLAN Names
Each VLAN is given a name that can be up to 32 characters. VLAN names can use standard alphanumeric characters. The following characters are not permitted in a VLAN name: Space Comma Quotation mark VLAN names must begin with an alphabetical letter. Quotation marks can be used to enclose a VLAN name that includes special characters, including single quotation marks or commas. Spaces may not be included, even within quotation marks. For example, the names test, test1, and test_15 are acceptable VLAN names. The names test&5 and joes may be used if enclosed in quotation marks. Names such as 5test or test 5 are not permitted. VLAN names can be specified using the tab key for command completion. VLAN names are locally significant. That is, VLAN names used on one switch are only meaningful to that switch. If another switch is connected to it, the VLAN names have no significance to the other switch.

NOTE You should use VLAN names consistently across your entire network.

Default VLAN
The switch ships with one default VLAN that has the following properties: The VLAN name is default. It contains all the ports on a new or initialized switch. The default VLAN is untagged on all ports. It has an internal VLANid of 1.

Renaming a VLAN
To rename an existing VLAN, use the following command:
configure vlan <old_name> name <new_name>

The following rules apply to renaming VLANs: Once you change the name of the default VLAN, it cannot be changed back to default. You cannot create a new VLAN named default. You cannot change the VLAN name MacVlanDiscover. Although the switch accepts a name change, once it is rebooted, the original name is recreated.

106

ExtremeWare 7.1.0 Software User Guide

Configuring VLANs on the Switch

Configuring VLANs on the Switch

This section describes the commands associated with setting up VLANs on the switch. Configuring a VLAN involves the following steps: 1 Create and name the VLAN. 2 Assign an IP address and mask (if applicable) to the VLAN, if needed. NOTE Each IP address and mask assigned to a VLAN must represent a unique IP subnet. You cannot configure the same IP subnet on different VLANs.

NOTE If you plan to use this VLAN as a control VLAN for an EAPS domain, do NOT assign an IP address to the VLAN. 3 Assign a VLANid, if any ports in this VLAN will use a tag. 4 Assign one or more ports to the VLAN. As you add each port to the VLAN, decide if the port will use an 802.1Q tag.

VLAN Configuration Examples

The following modular switch example creates a port-based VLAN named accounting, assigns the IP address 132.15.121.1, and assigns slot 2, ports 1, 2, 3, and 6, and slot 4, ports 1 and 2 to it:
create vlan accounting configure accounting ipaddress 132.15.121.1 configure default delete port 2:1-2:3,2:6,4:1,4:2 configure accounting add port 2:1-2:3,2:6,4:1,4:2

NOTE Because VLAN names are unique, you do not need to enter the keyword vlan after you have created the unique VLAN name. You can use the VLAN name alone. The following stand-alone switch example creates a tag-based VLAN named video. It assigns the VLANid 1000. Ports 4 through 8 are added as tagged ports to the VLAN.
create vlan video configure video tag 1000 configure video add port 4-8 tagged

The following stand-alone switch example creates a VLAN named sales, with the VLANid 120. The VLAN uses both tagged and untagged ports. Ports 1 through 3 are tagged, and ports 4 and 7 are untagged. Note that when not explicitly specified, ports are added as untagged.
create vlan sales configure sales tag 120 configure sales add port 1-3 tagged

ExtremeWare 7.1.0 Software User Guide

107

Virtual LANs (VLANs)

configure default delete port 4,7 configure sales add port 4,7

The following modular switch example creates a protocol-based VLAN named ipsales. Slot 5, ports 6 through 8, and slot 6, ports 1, 3, and 4-6 are assigned to the VLAN. In this example, you can add untagged ports to a new VLAN without first deleting them from the default VLAN, because the new VLAN uses a protocol other than the default protocol.
create vlan ipsales configure ipsales protocol ip configure ipsales add port 5:6-5:8,6:1,6:3-6:6

The following modular switch example defines a protocol filter, myprotocol and applies it to the VLAN named myvlan. This is an example only, and has no real-world application.
create protocol myprotocol configure protocol myprotocol add etype 0xf0f0 configure protocol myprotocol add etype 0xffff create vlan myvlan configure myvlan protocol myprotocol

Displaying VLAN Settings

To display VLAN settings, use the following command:
show vlan {<vlan name> | detail}

The show command displays summary information about each VLAN, which includes: Name. VLANid. How the VLAN was created. IP address. IPX address (if configured). STPD information. Protocol information. QoS profile information. Ports assigned. Tagged/untagged status for each port. How the ports were added to the VLAN. Number of VLANs configured on the switch. Use the detail option to display the detailed format.

108

ExtremeWare 7.1.0 Software User Guide

Displaying VLAN Settings

Displaying VLAN Statistics

To display VLAN statistics, use the following command:
show vlan stats vlan <vlan name> ... <vlan name>

The information displayed includes: Transmitted and received unicast packets. Transmitted and received multicast packets. Transmitted and received broadcast packets. Transmitted and received bytes. You can display statistics for multiple VLANs by entering the name of each VLAN on the command line.

Displaying VLAN Statistics Per Port

In addition to displaying VLAN statistics on a per-VLAN basis, you can display VLAN statistics on a per-port basis, using the following command:
configure ports <portlist> monitor vlan <vlan name>

You can monitor up to four VLANs on the same port by issuing the command four times. For example, if you want to monitor VLAN dog1, dog2, dog3, and dog4 on port 1, use the following command configuration:
configure configure configure configure ports ports ports ports 1:* 1:* 1:* 1:* monitor monitor monitor monitor vlan vlan vlan vlan dog1 dog2 dog3 dog4

After you configure the port, you can use this command to display information for the configured port:
show ports <portlist> vlan statistics

After you have configured per-port monitoring, every time you issue the show ports command, the latest statistics are displayed directly from the hardware in real-time. This information is not logged. To remove the port mask, use the following command:
unconfigure ports <portlist> monitor vlan <vlan name>

You must issue the unconfigure command for each VLAN you have configured for the port. For example:
unconfigure unconfigure unconfigure unconfigure ports ports ports ports 1:* 1:* 1:* 1:* monitor monitor monitor monitor vlan vlan vlan vlan dog1 dog2 dog3 dog4

ExtremeWare 7.1.0 Software User Guide

109

Virtual LANs (VLANs)

Displaying Protocol Information

To display protocol information, use the following command:
show protocol {<protocol>}

This show command displays protocol information, which includes: Protocol name. List of protocol fields. VLANs that use the protocol.

VLAN Tunneling (VMANs)

You can tunnel any number of 802.1Q and/or Cisco ISL VLANs into a single VLAN that can be switched through an Extreme Ethernet infrastructure. A given tunnel is completely isolated from other tunnels or VLANs. This feature is useful in building transparent private networks (VMANs) that need point-to-point or point-to-multipoint connectivity across an Ethernet infrastructure. The VLAN tagging methods used within the VMAN tunnel are transparent to the tunnel. For the MAN provider, the tagging numbers and methods used by the customer are transparent to the provider. To configure a VMAN tunnel, follow these steps: 1 Modify the 802.1Q Ethertype the switch uses to recognize tagged frames. Extreme Networks recommends the use of IEEE registered ethertype 0x88a8 for deploying vMANs. 2 Configure the switch to accept larger MTU size frames (jumbo frames). 3 Create tunnels by creating VLANs and configuring member ports as tagged on switch-to-switch ports and untagged on the ingress/egress ports of the tunnel. Figure 9 illustrates a configuration with VMANs.

110

ExtremeWare 7.1.0 Software User Guide

VLAN Tunneling (VMANs)

Figure 9: VMAN example

Tunnel #1 ingress/egress Ports 1-4

Tunnel #1 ingress/egress Ports 1-4 1:2

1:1 31 32

vMAN core
31 32

31 32 Ports 5-8 Tunnel #2 ingress/egress

Ports 5-8 Tunnel #2 ingress/egress Ports 1-4 Tunnel #1 ingress/egress

Ports 5-8 Tunnel #2 ingress/egress

EW_059

Two tunnels are depicted that have ingress/egress ports on each Summit7i switch. The configuration for the Summit7i switches shown in Figure 9 is:
configure dot1q ethertype 88a8 enable jumbo-frame ports 31,32 configure jumbo-frame size 1530 create vlan Tunnel1 configure vlan Tunnel1 tag 50 configure vlan Tunnel1 add port 1-4 untag configure vlan Tunnel1 add port 31,32 tagged create vlan Tunnel2 configure vlan Tunnel2 tag 60 configure vlan Tunnel2 add port 5-8 untag create vlan Tunnel2 add port 31,32 tagged

On the BlackDiamond switch, the configuration is:

configure dot1q ethertype 88a8 enable jumbo-frame ports all configure jumbo-frame size 1530 create vlan tunnel1 configure vlan tunnel1 tag 50 configure vlan tunnel1 add port 1:1-1:2 tagged create vlan tunnel2 configure vlan tunnel2 tag 60 configure vlan tunnel2 add port 1:1-1:2 tagged

Specific to this configuration, a layer 1 or layer 2 redundancy method would also be employed, such as Spanning Tree or other methods ExtremeWare offers.

ExtremeWare 7.1.0 Software User Guide

111

Virtual LANs (VLANs)

MAC-Based VLANs
MAC-Based VLANs allow physical ports to be mapped to a VLAN based on the source MAC address learned in the FDB. This feature allows you to designate a set of ports that have their VLAN membership dynamically determined by the MAC address of the end station that plugs into the physical port. You can configure the source MAC address-to-VLAN mapping either offline or dynamically on the switch. For example, you could use this application for a roaming user who wants to connect to a network from a conference room. In each room, the user plugs into one of the designated ports on the switch and is mapped to the appropriate VLAN. Connectivity is maintained to the network with all of the benefits of the configured VLAN in terms of QoS, routing, and protocol support.

MAC-Based VLAN Guidelines

When using the MAC-to-VLAN mapping, consider the following guidelines: A port can only accept connections from an endstation/host and should not be connected to a layer-2 repeater device. Connecting to a layer-2 repeater device can cause certain addresses to not be mapped to their respective VLAN if they are not correctly configured in the MAC-VLAN configuration database. If a repeater device is connected to a MAC-Based VLAN port, and the configured MAC-to-VLAN mapped station enters on the repeater, any endstation that is attached to the repeater can be mapped to that VLAN while the configured endstation is active in that VLAN. Upon removal of the configured MAC-to-VLAN endstation, all other endstations lose connectivity. Groups are used as a security measure to allow a MAC address to enter into a VLAN only when the group mapping matches the port mapping. As an example, the following configuration allows MAC 00:00:00:00:00:aa to enter into the VLAN only on ports 10 and 11 because of membership in group 100:
* Summit48:50 # show mac Port Vlan 10 MacVlanDiscover 11 MacVlanDiscover 12 MacVlanDiscover 13 MacVlanDiscover 14 MacVlanDiscover Total Entries in Database:2 Mac Vlan 00:00:00:00:00:aa sales 00:00:00:00:00:01 sales 2 matching entries Group 100 100 any any any Group 100 any State Discover Discover Discover Discover Discover

The group any is equivalent to the group 0. Ports that are configured as any allow any MAC address to be assigned to a VLAN, regardless of group association. Partial configurations of the MAC to VLAN database can be downloaded to the switch using the timed download configuration feature.

112

ExtremeWare 7.1.0 Software User Guide

MAC-Based VLANs

MAC-Based VLAN Limitations

The following list contains the limitations of MAC-based VLANs: Ports participating in MAC VLANs must first be removed from any static VLANs. The MAC- to-VLAN mapping can only be associated with VLANs that exist on the switch. A MAC address cannot be configured to associate with more than 1 VLAN. If this is attempted, the MAC address is associated with the most recent VLAN entry in the MAC-to-VLAN database. The feature is intended to support one client per physical port. Once a client MAC address has successfully registered, the VLAN association remains until the port connection is dropped or the FDB entry ages out.

MAC-Based VLAN Example

In this following example, three VLANs are created: engineering, marketing, and sales. A single MAC address is associated with each VLAN. The MAC address 00:00:00:00:00:02 has a group number of any or 0 associated with it, allowing it to be plugged into any port that is in MacVlanDiscover mode (ports 10-15 in this case). The MAC address 00:00:00:00:00:01 has a group number of 10 associated with it, and can only be assigned to a VLAN if inserted into ports 16 or 17. The MAC address 00:00:00:00:00:03 has a group number of 200 associated with it and can only be inserted into ports 18 through 20.
enable mac-vlan mac-group any ports 10-15 enable mac-vlan mac-group 10 ports 16-17 enable mac-vlan mac-group 200 ports 18-20 configure mac-vlan add mac-address 00:00:00:00:00:01 mac-group 10 engineering configure mac-vlan add mac-address 00:00:00:00:00:02 mac-group any marketing configure mac-vlan add mac-address 00:00:00:00:00:03 mac-group 200 sales

Timed Configuration Download for MAC-Based VLANs

To allow centralized control of MAC-based VLANs over multiple switches, a timed TFTP configuration download allows you to download incremental configuration files from a primary or secondary server at specified time intervals. The timed downloads are configurable in 24 hour intervals. When a switch reboots, the configuration is automatically downloaded immediately after booting, per the configured primary and secondary servers. To configure the primary and/or secondary server and file name, use the following command:
configure download server [primary | secondary] [<host_name> | <ip_address>] <filename>

ExtremeWare 7.1.0 Software User Guide

113

Virtual LANs (VLANs)

To enable timed interval downloads, use the following command:

download configuration every <hour:minute>

To display timed download information, use the following command:

show switch

Example
In relation to MAC-based VLANs, the downloaded file is an ASCII file that consists of CLI commands used to configure the most recent MAC-to-VLAN database. This feature is different from the normal download configuration command in that it allows incremental configuration without the automatic rebooting of the switch. The following example shows an incremental configuration file for MAC-based VLAN information that updates the database and saves changes:
configure configure configure . . configure configure save mac-vlan add mac-address 00:00:00:00:00:01 mac-group any engineering mac-vlan add mac-address 00:00:00:00:ab:02 mac-group any engineering mac-vlan add mac-address 00:00:00:00:cd:04 mac-group any sales

mac-vlan add mac-address 00:00:00:00:ab:50 mac-group any sales mac-vlan add mac-address 00:00:00:00:cd:60 mac-group any sales

114

ExtremeWare 7.1.0 Software User Guide

VLAN Translation

VLAN Translation
VLAN translation provides the ability to translate the 802.1Q tags for several VLANs into a single VLAN tag. This allows you to aggregate layer 2 VLAN traffic from multiple clients into a single uplink VLAN, improving VLAN scaling. Figure 10: An Application of VLAN Translation

PC1
VLAN 101

PC4

IAD PH1
VLAN 201

VLAN 101 (data) VLAN 201 (voice)

PC2
VLAN 102

VLAN translation switch

VLAN 1 (data) VLAN 2 (voice)

IAD PH2
VLAN 202

VLAN 102 (data) VLAN 202 (voice)

MAN core router

PC3
VLAN 103 VLAN 103 (data) VLAN 203 (voice)

IAD PH3
VLAN 203
EW_105

In the figure, VLANs 101, 102, and 103 carry data traffic while VLANs 201, 202, and 203 carry voice traffic. The voice and data traffic are combined on Integrated Access Devices (IAD) that connect to the VLAN translation switch. Each of the three clusters of phones and PCs use two VLANs to separate the voice and data traffic. As the traffic is combined, the six VLANs are translated into two. This simplifies administration, and scales much better for large installations. Conceptually, this is very similar to the existing layer 3 VLAN Aggregation (super-VLANS and sub-VLANs) that currently exists in ExtremeWare. The primary differences between these two features are: VLAN translation is strictly a layer 2 feature. VLAN translation does not allow communications between the member VLANs. VLAN translation requires the translation VLAN (unlike a super-Vlan) to contain one or more ports.

ExtremeWare 7.1.0 Software User Guide

115

Virtual LANs (VLANs)

VLAN Translation Behavior

You should be aware of the behavior of both unicast, broadcast, and multicast traffic when using VLAN translation.

Unicast Traffic
Traffic on the member VLANs may be either tagged or untagged. Traffic is switched locally between client devices on the same member VLAN as normal. Traffic cannot be switched between clients on separate member VLANs. Traffic from any member VLAN destined to the translation VLAN is switched and the VLAN tag is translated appropriately. Traffic from the translation VLAN destined to any member VLAN is switched and the VLAN tag is translated.

Broadcast Behavior
Broadcast traffic generated on a member VLAN will be replicated in every other active port of that VLAN as normal. In addition, the member VLAN traffic will be replicated to every active port in the translation VLAN and the VLAN tag will be translated appropriately. Broadcast traffic generated on the translation VLAN will be replicated to every other active port in this VLAN as usual. The caveat in this scenario is that this traffic will also be replicated to every active port in every member VLAN, with VLAN tag translation. In effect, the broadcast traffic from the translation VLAN will leak onto all member VLANs.

Multicast Behavior
IGMP snooping may be enabled on member and translation VLANs so that multicast traffic can be monitored within the network. IGMP snooping software examines all IGMP control traffic that enters the switch. IGMP control traffic received on a VLAN translation port is forwarded by the CPU to all other ports in the translation group. Software VLAN translation is performed on the packets which cross the translation boundary between member and translation VLANs. The snooping software will detect ports joining and leaving multicast streams. When a VLAN translation port joins a multicast group, an FDB entry will be created using information from the IGMP message. The FDB entry will be added for the requested multicast address and will contain a multicast PTAG. When a VLAN translation port leaves a multicast group, the port will be removed from the multicast list. The last VLAN translation port to leave a multicast group will cause the multicast FDB entry to be removed.

VLAN Translation Limitations and Notes

VLAN translation is an layer 2 function only, therefore, a limited subset of protocol support can be provided. Listed below are the limitations for VLAN translation, and some notes on usage: Only i series hardware is supported MAC addresses much be unique for devices on all member VLANs connected to the same switch IP addresses may not be configured on member or translation VLANs Member VLANs cannot be configured as a translation VLAN on the same switch Translation VLANs cannot be configured as a member VLAN on the same switch Layer 3 VLAN aggregation cannot be enabled on member or translation VLANs 802.1x authentication cannot be enabled on ports that are included in a member or translation VLAN Network Login cannot be enabled on ports that are included in a member or translation VLAN

116

ExtremeWare 7.1.0 Software User Guide

VLAN Translation

DHCP cannot be enabled on ports that are included in a member or translation VLAN Member or translation VLANs cannot be used by TLS EDP may be enabled on ports that are included in member and translation VLANs ESRP cannot be enabled on member or translation VLANs ESRP BPDUs will be translated through the switch (BPDU tunneling) ESRP redundancy may be provided by adding a translation VLAN as a member of an ESRP domain STP redundancy may be provided by protecting ports that are included in member VLANs EAPS protected VLANs may not be either member or translation VLANs IGMP snooping may be enabled on member and translation VLANs VMAN encapsulated VLAN tags are not translated VLAN translation MACs are accounted for at each port during learning, thus these MACs are used in the calculations for sending MAC security traps.

Interfaces
Use the following information for selecting and configuring VLAN translation interfaces: Member and translation VLANs may only contain Ethernet ports, therefore POS, ATM, and WAN (T1, E1, T3) ports are not supported. A single physical port may be added to multiple member VLANs, using different VLAN tags. Member VLANs and translation VLANs may include both tagged and untagged ports.

VLAN Translation Configuration Examples

The following configuration examples show VLAN translation used in three scenarios: Basic VLAN Translation on page 117 VLAN Translation with ESRP Redundancy on page 118 VLAN Translation with STP Redundancy on page 120

Basic VLAN Translation

The following example, shown in Figure 11, configures a basic VLAN translation network. This network provides VLAN translation between four member VLANs and a single translation VLAN.

ExtremeWare 7.1.0 Software User Guide

117

Virtual LANs (VLANs)

Figure 11: VLAN Translation Configuration Example

VLAN 101 (1:1) VLAN 102 (1:1)

Extreme switch with VLAN translation

VLAN 1000 (2:1)

VLAN 103 (1:2) VLAN 104 (1:2)

The following configuration commands create the member VLANs:
create vlan v101 configure v101 tag configure v101 add create vlan v102 configure v102 tag configure v102 add create vlan v103 configure v103 tag configure v103 add create vlan v104 configure v104 tag configure v104 add 101 ports 1:1 tagged 102 ports 1:1 tagged 103 ports 1:2 tagged 104 ports 1:2 tagged

EW_106

The following configuration commands create the translation VLAN and enables VLAN translation:
create vlan v1000 configure v1000 tag configure v1000 add configure v1000 add configure v1000 add configure v1000 add configure v1000 add 1000 ports 2:1 tagged member-vlan v101 member-vlan v102 member-vlan v103 member-vlan v104

VLAN Translation with ESRP Redundancy

The following example, shown in Figure 12, configures a VLAN translation network with ESRP redundancy. The SW2 and SW3 VLAN translation switches are protected by an ESRP control VLAN. The master ESRP switch performs the translation and provides the connectivity to the backbone. When a failure occurs, the slave ESRP switch will take over and begin performing the translation.

118

ExtremeWare 7.1.0 Software User Guide

VLAN Translation

Figure 12: ESRP Redundancy Configuration Example

VLAN 1000 (2:1)

VLAN 101 (1:1) VLAN 102 (1:1)

Extreme switch with VLAN VLAN 101, 102, 103, 104 translation (SW2) (1:3)
(1:3)

Extreme switch (SW1)

EVLAN (2:2)
(1:4) (1:3) VLAN 1000 (2:1)

VLAN 103 (1:2) VLAN 104 (1:2)

VLAN 101, 102, 103, 104

Extreme switch with VLAN translation (SW3)

EW_107

The following configuration commands create the member VLANs on SW1:

create vlan v101 configure v101 tag configure v101 add configure v101 add configure v101 add create vlan v102 configure v102 tag configure v102 add configure v102 add configure v102 add create vlan v103 configure v103 tag configure v103 add configure v103 add configure v103 add create vlan v104 configure v104 tag configure v104 add configure v104 add configure v104 add 101 ports 1:1 tagged ports 1:3 tagged ports 1:4 tagged 102 ports 1:1 tagged ports 1:3 tagged ports 1:4 tagged 103 ports 1:2 tagged ports 1:3 tagged ports 1:4 tagged 104 ports 1:2 tagged ports 1:3 tagged ports 1:4 tagged

The configuration for SW2 and SW3 will be identical for this example. The following configuration commands create the member VLANs on SW2:
create vlan v101 configure v101 tag configure v101 add create vlan v102 configure v102 tag configure v102 add create vlan v103 configure v103 tag configure v103 add create vlan v104 configure v104 tag configure v104 add 101 ports 1:3 tagged 102 ports 1:3 tagged 103 ports 1:3 tagged 104 ports 1:3 tagged

ExtremeWare 7.1.0 Software User Guide

119

Virtual LANs (VLANs)

This set of configuration commands create the translation VLANs and enables VLAN translation on SW2:
create vlan v1000 configure v1000 tag configure v1000 add configure v1000 add configure v1000 add configure v1000 add configure v1000 add 1000 ports 2:1 tagged member-vlan v101 member-vlan v102 member-vlan v103 member-vlan v104

The last set of configuration commands create the ESRP control VLAN and enables ESRP protection on the translation VLAN for SW2:
create vlan evlan configure evlan add ports 2:2 enable esrp evlan configure evlan add domain-member v1000

VLAN Translation with STP Redundancy

The following example, shown in Figure 13, configures a VLAN translation network with redundant paths protected by STP. Parallel paths from the member VLAN portion of the network to the translation switch. STP ensures that the main path for this traffic is active and the secondary path is blocked. When a failure occurs in the main path, the secondary paths are enabled. Figure 13: STP Redundancy Configuration Example
VLAN 101 (1:1)

Extreme switch (SW1)

(1:3) (1:4) VLAN 102 (1:2)

VLAN 101, 102, 103, 104 (1:3) VLAN 1000 (2:1)

VLAN 101, 102, 103, 104 VLAN 103 (1:1) (1:4) (1:3) (1:4)

Extreme switch with VLAN translation (SW3)

Extreme switch (SW2)

VLAN 101, 102, 103, 104

VLAN 104 (1:2)

EW_108

The following configuration commands create the member VLANs and enables STP on SW1:
create vlan v101 configure v101 tag configure v101 add configure v101 add configure v101 add create vlan v102 configure v102 tag configure v102 add configure v102 add 101 ports 1:1 tagged ports 1:3 tagged ports 1:4 tagged 102 ports 1:2 tagged ports 1:3 tagged

120

ExtremeWare 7.1.0 Software User Guide

VLAN Translation

configure v102 add create vlan v103 configure v103 tag configure v103 add configure v103 add create vlan v104 configure v104 tag configure v104 add configure v104 add create stpd stp1 configure stp1 tag configure stp1 add configure stp1 add configure stp1 add configure stp1 add enable stpd stp1

ports 1:4 tagged 103 ports 1:3 tagged ports 1:4 tagged 104 ports 1:3 tagged ports 1:4 tagged 101 vlan vlan vlan vlan

v101 v102 v103 v104

These configuration commands create the member VLANs and enables STP on SW2:
create vlan v103 configure v103 tag configure v103 add configure v103 add configure v103 add create vlan v104 configure v104 tag configure v104 add configure v104 add configure v104 add create vlan v101 configure v101 tag configure v101 add configure v101 add create vlan v102 configure v102 tag configure v102 add configure v102 add create stpd stp1 configure stp1 tag configure stp1 add configure stp1 add configure stp1 add configure stp1 add enable stpd stp1 103 ports 1:1 tagged ports 1:3 tagged ports 1:4 tagged 104 ports 1:2 tagged ports 1:3 tagged ports 1:4 tagged 101 ports 1:3 tagged ports 1:4 tagged 102 ports 1:3 tagged ports 1:4 tagged 101 vlan vlan vlan vlan

v101 v102 v103 v104

This set of configuration commands create the member VLANs and enables STP on SW3:
create vlan v101 configure v101 tag configure v101 add configure v101 add create vlan v102 configure v102 tag configure v102 add configure v102 add create vlan v103 configure v103 tag 101 ports 1:3 tagged ports 1:4 tagged 102 ports 1:3 tagged ports 1:4 tagged 103

ExtremeWare 7.1.0 Software User Guide

121

Virtual LANs (VLANs)

configure v103 add configure v103 add create vlan v104 configure v104 tag configure v104 add configure v104 add create stpd stp1 configure stp1 tag configure stp1 add configure stp1 add configure stp1 add configure stp1 add enable stpd stp1

ports 1:3 tagged ports 1:4 tagged 104 ports 1:3 tagged ports 1:4 tagged 101 vlan vlan vlan vlan

v101 v102 v103 v104

The last set of configuration commands creates the translation VLAN and enables VLAN translation on SW3:
create vlan v1000 configure v1000 tag configure v1000 add configure v1000 add configure v1000 add configure v1000 add configure v1000 add 1000 ports 2:1 tagged member-vlan v101 member-vlan v102 member-vlan v103 member-vlan v104

122

ExtremeWare 7.1.0 Software User Guide

Forwarding Database (FDB)

This chapter describes the following topics: Overview of the FDB on page 123 Associating QoS Profiles with an FDB Entry on page 126 Scanning the FDB on page 126 FDB Configuration Examples on page 128 MAC-Based Security on page 129 Displaying FDB Entries on page 130

Overview of the FDB

The switch maintains a database of all media access control (MAC) addresses received on all of its ports. It uses the information in this database to decide whether a frame should be forwarded or filtered.

FDB Contents
Each FDB entry consists of the MAC address of the device, an identifier for the port and VLAN on which it was received, and the age of the entry. Frames destined for MAC addresses that are not in the FDB are flooded to all members of the VLAN.

How FDB Entries Get Added

Entries are added into the FDB in the following ways: The switch can learn entries by examining packets it receives. The system updates its FDB with the source MAC address from a packet, the VLAN, and the port identifier on which the source packet is received. The ability to learn MAC addresses can be enabled or disabled on a port-by-port basis. You can also limit the number of addresses that can be learned, or you can lock down the current entries and prevent additional MAC address learning. You can enter and update entries using the command line interface (CLI). Certain static entries are added by the system upon switch boot up.

ExtremeWare 7.1.0 Software User Guide

123

Forwarding Database (FDB)

FDB Entry Types

FDB entries may be dynamic or static, and may be permanent or non-permanent. The following describes the types of entries that can exist in the FDB: Dynamic entriesA dynamic entry is learned by the switch by examining packets to determine the source MAC address, VLAN, and port information. The switch then creates or updates an FDB entry for that MAC address. Initially, all entries in the database are dynamic, except for certain entries created by the switch at boot up. Dynamic entries are flushed and relearned (updated) when any of the following take place: A VLAN is deleted. A VLAN identifier (VLANid) is changed. A port mode is changed (tagged/untagged). A port is deleted from a VLAN. A port is disabled. A port enters blocking state. A port QoS setting is changed. A port goes down (link down). A non-permanent dynamic entry is initially created when the switch identifies a new source MAC address that does not yet have an entry in the FDB. The entry may then be updated as the switch continues to encounter the address in the packets it examines. These entries are identified by the d flag in show fdb output. A permanent dynamic entry is created by command through the CLI, but may then be updated as the switch encounters the MAC address in the packets that it examines. A permanent dynamic entry is typically used to associate QoS profiles with the FDB entry. Permanent dynamic entries are identified by the p and d flags in show fdb output. Both types of dynamic entries agea dynamic entry will be removed from the FDB (aged-out) if the device does not transmit for a specified period of time (the aging time). This prevents the database from becoming full with obsolete entries by ensuring that when a device is removed from the network, its entry is deleted from the database. The aging time is configurable. For more information about setting the aging time, see Configuring the FDB Aging Time on page 129 later in this chapter. Static entriesA static entry does not age, and does not get updated through the learning process. It is maintained exactly as it was created. Conditions that cause dynamic entries to be updated, such as VLAN or port configuration changes, do not affect static entries. If the same MAC address is detected on another virtual port that is not defined in the static FDB entry for the MAC address, it is handled as a blackhole entry. A permanent static entry is created through the command line interface, and can be used to associate QoS profiles with a non-aging FDB entry. Permanent static entries are identified by the s and p flags in show fdb output. A locked static entry is an entry that was originally learned dynamically, but has been made static (locked) using the MAC address lock-down feature. It is identified by the s and l flags in show fdb output. See MAC Address Lock Down on page 235 for more information about MAC address lock-down.

124

ExtremeWare 7.1.0 Software User Guide

Overview of the FDB

Non-permanent static entries are created by the switch software for various reasons, typically upon switch boot up. They are identified by the s flag in show fdb output. If the FDB entry aging time is set to zero, all entries in the database are considered static, non-aging entries. This means that they do not age, but they are still deleted if the switch is reset. Permanent entriesPermanent entries are retained in the database if the switch is reset or a power off/on cycle occurs. Permanent entries must be created by the system administrator through the command line interface. A permanent entry can either be a unicast or multicast MAC address. Permanent entries may be static, meaning they do not age or get updated, or they may be dynamic, meaning that they do age and can be updated via learning. Permanent entries can have QoS profiles associated with the MAC address. A different QoS profiles may be associated with the MAC address when it is a destination address (an egress QoS profile) than when it is a source address (ingress QoS profile). The stand-alone switches can support a maximum of 64 permanent entries, and the modular switches support a maximum of 254 permanent entries. Blackhole entriesA blackhole entry configures the switch to discard packets with a specified MAC address. Blackhole entries are useful as a security measure or in special circumstances where a specific source or destination address must be discarded. Blackhole entries may be created through the CLI, or they may be created by the switch when a ports learning limit has been exceeded. Blackhole entries are treated like permanent entries in the event of a switch reset or power off/on cycle. Blackhole entries are never aged out of the database.

Disabling MAC Address Learning

By default, MAC address learning is enabled on all ports. You can disable learning on specified ports using the following command:
disable learning ports <portlist>

If MAC address learning is disabled, only broadcast traffic, EDP traffic, and packets destined to a permanent MAC address matching that port number, are forwarded. Use this command in a secure environment where access is granted via permanent forwarding databases (FDBs) per port. If you disable MAC address learning, you can enable packet flooding on one or more ports. When flooding is enabled on a particular port, all frames and packets are passed on to other member ports that also have flooding enabled. This includes all broadcast, multicast, known and unknown unicast packets (including EPD). To make effective use of this feature you should have flooding enabled on more than one port. You can enable flooding on specified ports using the following command:
enable flooding ports <portlist>

You can disable flooding on specified ports using the following command:
disable flooding ports <portlist>

Learning and flooding are mutually exclusive. To enable flooding, learning must be disabled. When ports are configured for flooding, the FDB will be flushed for the entire system, which means all the entries in the dynamic FDB must be relearned.

ExtremeWare 7.1.0 Software User Guide

125

Forwarding Database (FDB)

Associating QoS Profiles with an FDB Entry

You can associate QoS profiles with a MAC address (and VLAN) of a device by creating a permanent FDB entry and specifying QoS profiles for ingress or egress, or both. The permanent FDB entry can be either dynamic (it is learned and can be aged out) or static. To associate a QoS profile with a dynamic FDB entry, use the following command:
create fdbentry [<mac_address> | any-mac] vlan <vlan name> dynamic [qosprofile <qosprofile> {ingress-qosprofile <iqosprofile>} | ingress-qosprofile <qosprofile> {qosprofile <qosprofile>}]

This command associates QoS profiles with packets received from or destined for the specified MAC address, while still allowing the FDB entry to be dynamically learned. If you specify only the ingress QoS profile, the egress QoS profile defaults to none, and vice-versa. If both profiles are specified, the source MAC address of an ingress packet and the destination MAC address of an egress packet are examined for QoS profile assignment. The FDB entry is not actually created until the MAC address is encountered as the source MAC address in a packet. Thus, initially the entry may not appear in the show fdb output. Once the entry has been learned, it is created as a permanent dynamic entry, designated by dpm in the flags field of the show fdb output. You can use the show fdb permanent command to display permanent FDB entries, including their QoS profile associations. To associate a QoS profile with a permanent FDB entry, use the following command:
create fdbentry <mac_address> vlan <vlan name> ports [<portlist | all] {qosprofile <qosprofile>} {ingress-qosprofile <iqosprofile>}

This entry will not be aged out, and no learning will occur. If the same MAC address is encountered through a virtual port not specified in the portlist, it will be handled as a blackhole entry. Using the any-mac keyword, you can enable traffic from a QoS VLAN to have higher priority than 802.1p traffic. Normally, an 802.1p packet has a higher priority over the VLAN classification. In order to use this feature, you must create a wildcard permanent FDB entry named any-mac and apply the QoS profile to the individual MAC entry.

NOTE For more information on QoS profiles, see Chapter 7.

Scanning the FDB

You can scan the FDB on a stand-alone switch or on a slot or backplane basis on a modular switch. This setting is independent of and in addition to the system health check configuration, and the following commands do not affect the system health check configurations. For more information about the system health checker and configuring the system health checker, see Chapter 10.

126

ExtremeWare 7.1.0 Software User Guide

Scanning the FDB

Enabling FDB Scanning

By default, FDB scanning is disabled. To enable FDB scanning on a stand-alone switch, use the following command:
enable fdb-scan

To enable FDB scanning on an Alpine switch, use the following command:

enable fdb-scan [all | slot {backplane}]

To enable FDB scanning on a BlackDiamond switch, use the following command:

enable fdb-scan [all | slot {<slot number> | msm-a | msm-b}]

where the following is true: allSpecifies all of the slots in the chassis. This is available on modular switches only. backplaneSpecifies the backplane of the Alpine chassis. This is available on Alpine switches only. slot numberSpecifies the slot number of the module to scan. This is available on BlackDiamond switches only. msm-aSpecifies the MSM installed in slot A. This is available on BlackDiamond switches only. msm-bSpecifies the MSM installed in slot B. This is available on BlackDiamond switches only.

Disabling FDB Scanning

To disable FDB scanning on a stand-alone switch, use the following command:
disable fdb-scan

To disable FDB scanning on an Alpine switch, use the following command:

disable fdb-scan [all | slot {backplane}]

To disable FDB scanning on a BlackDiamond switch, use the following command:

disable fdb-scan [all | slot {<slot number> | msm-a | msm-b}]

If you disable FDB scanning for a slot and the system health check is enabled, the slot is still scanned by the system health checker.

Configuring the FDB Scan Interval

You can configure the amount of time between FDB scans. To set the interval between FDB scans, use the following command:
configure fdb-scan period <period <1-60>>

The default is 30 seconds. The range is 1 - 60 seconds. If you configure a timer interval of less than 15 seconds, the following warning message is displayed and you are asked to confirm the change:
Setting period below (15) may starve other tasks. Do you wish to do this? (yes, no, cancel) 06/19/2003 10:29.28 <INFO:SYST> serial admin: configure fdb-scan period 1 n

ExtremeWare 7.1.0 Software User Guide

127

Forwarding Database (FDB)

NOTE Extreme Networks recommends an interval period of at least 15 seconds. To return the FDB scan interval to the factory default of 30 seconds, use the following command:
unconfigure fdb-scan period

If the switch detects too many failures within the specified scan period, the messages are either sent to the syslog or the configured system health check action is taken. To configure the action the switch takes when too many failures are detected, use the following command:
configure fdb-scan failure-action [log | sys-health-check]

where the following is true: logMessages are sent to the syslog. Only one instance of an error messages is logged at this level. This is the default configuration. sys-health-checkThe configured system health check action is taken. To return the switch to the factory default of sending messages to the syslog, use the following command:
unconfigure fdb-scan failure-action

Displaying FDB Scan Statistics

To display the FDB scan statistics, use the following command:
show diagnostics sys-health-check

The following is an example of the type of FDB scan statistics output displayed:
FDB Scan results: CardState NumFail BPLNE : Operational 0 NumScan 64 Entry LastFailTime

FDB Configuration Examples

The following example adds a permanent static entry to the FDB:
create fdbentry 00:E0:2B:12:34:56 vlan marketing port 3:4

The permanent entry has the following characteristics: MAC address is 00:E0:2B:12:34:56. VLAN name is marketing. Slot number for this device is 3. Port number for this device is 4.

128

ExtremeWare 7.1.0 Software User Guide

MAC-Based Security

If the MAC address 00:E0:2B:12:34:56 is encountered on any port/VLAN other than VLAN marketing, port 3:4, it will be handled as a blackhole entry, and packets from that source will be dropped. This example associates the QoS profile qp2 with a dynamic entry for the device at MAC address 00:A0:23:12:34:56 on VLAN net34 that will be learned by the FDB:
create fdbentry 00:A0:23:12:34:56 vlan net34 dynamic qosprofile qp2

This entry has the following characteristics: MAC address is 00:A0:23:12:34:56. VLAN name is net34. The entry will be learned dynamically. QoS profile qp2 will be applied as an egress QoS profile when the entry is learned.

Overriding 802.1p Priority

This example associates the QoS profile qp5 with the wildcard permanent FDB entry any-mac on VLAN v110:
create fdbentry any-mac vlan v110 dynamic ingress-qosprofile qp5

Configuring the FDB Aging Time

You can configure the again time for dynamic FDB entries using the following command:
configure fdb agingtime <seconds>

If the aging time is set to zero, all aging entries in the database are defined as static, nonaging entries. This means they will not age out, but non-permanent static entries can be deleted if the switch is reset.

MAC-Based Security
MAC-based security allows you to control the way the FDB is learned and populated. By managing entries in the FDB, you can block, assign priority (queues), and control packet flows on a per-address basis. MAC-based security allows you to limit the number of dynamically-learned MAC addresses allowed per virtual port. You can also lock the FDB entries for a virtual port, so that the current entries will not change, and no additional addresses can be learned on the port. You can also prioritize or stop packet flows based on the source MAC address of the ingress VLAN or the destination MAC address of the egress VLAN. For detailed information about MAC-based security, see Chapter 11.

ExtremeWare 7.1.0 Software User Guide

129

Forwarding Database (FDB)

Displaying FDB Entries

To display FDB entries, use the following command:
show fdb {<mac_address> | broadcast-mac | permanent | ports <portlist> | remap | vlan <vlan name>}

where the following is true: mac_addressDisplays the entry for a particular MAC address. broadcast-macSpecifies the broadcast MAC address. May be used as an alternate to the colon-separated byte form of the address ff:ff:ff:ff:ff:ff permanentDisplays all permanent entries, including the ingress and egress QoS profiles. ports <portlist>Displays the entries for a set of ports or slots and ports. remapDisplays the remapped FDB entries. vlan <vlan name>Displays the entries for a VLAN. With no options, the command displays all FDB entries. See the ExtremeWare Software Command Reference Guide for details of the commands related to the FDB.

130

ExtremeWare 7.1.0 Software User Guide

Quality of Service (QoS)

This chapter covers the following topics: Overview of Policy-Based Quality of Service on page 132 Applications and Types of QoS on page 132 Configuring QoS on page 134 QoS Profiles on page 135 Traffic Groupings on page 136 IP-Based Traffic Groupings on page 136 MAC-Based Traffic Groupings on page 137 Explicit Class of Service (802.1p and DiffServ) Traffic Groupings on page 138 Configuring DiffServ on page 140 Physical and Logical Groupings on page 143 Configuring QoS Traffic Grouping Priorities on page 144 Verifying Configuration and Performance on page 145 Modifying a QoS Configuration on page 146 Bi-Directional Rate Shaping on page 146 Dynamic Link Context System on page 149 Policy-based Quality of Service (QoS) is a feature of ExtremeWare and the Extreme switch architecture that allows you to specify different service levels for traffic traversing the switch. Policy-based QoS is an effective control mechanism for networks that have heterogeneous traffic patterns. Using Policy-based QoS, you can specify the service level that a particular traffic type receives. This chapter does not describe the additional ingress and egress QoS capabilities available on the High Density Gigabit Ethernet 3 series I/O modules. For more information and a full description of the High Density Gigabit Ethernet module, see Chapter 28.

ExtremeWare 7.1.0 Software User Guide

131

Quality of Service (QoS)

Overview of Policy-Based Quality of Service

Policy-based QoS allows you to protect bandwidth for important categories of applications or specifically limit the bandwidth associated with less critical traffic. For example, if voiceover-IP traffic requires a reserved amount of bandwidth to function properly, using policy-based QoS, you can reserve sufficient bandwidth critical to this type of application. Other applications deemed less critical can be limited so as to not consume excessive bandwidth. The switch contains separate hardware queues on every physical port. Each hardware queue is programmed by ExtremeWare with bandwidth management and prioritization parameters. The bandwidth management and prioritization parameters that modify the forwarding behavior of the switch affect how the switch transmits traffic for a given hardware queue on a physical port. The switch tracks and enforces the minimum and maximum percentage of bandwidth utilization transmitted on every hardware queue for every port. When two or more hardware queues on the same physical port are contending for transmission, the switch prioritizes bandwidth use so long as their respective bandwidth management parameters are satisfied. Up to eight physical queues per port are available.

NOTE Policy-based QoS has no impact on switch performance. Using even the most complex traffic groupings has no cost in terms of switch performance. Policy-based QoS can be configured to perform per-port Random Early Detection (RED). Using this capability, the switch detects when traffic is filling up in any of the eight hardware queues, and performs a random discard on subsequent packets, based on the configured RED drop-probability. Instead of dropping sessions during times when the queue depth is exceeded, RED causes the switch to lower session throughput. The destination node detects the dropped packet, and, using standard TCP windowing mechanisms, slows the transmission from the source node. RED drop-probability is configured on a system-wide basis, and has a valid range from 0% to 100%.

Applications and Types of QoS

Different applications have different QoS requirements. The following applications are ones that you will most commonly encounter and need to prioritize: Voice applications Video applications Critical database applications Web browsing applications File server applications

132

ExtremeWare 7.1.0 Software User Guide

Applications and Types of QoS

General guidelines for each traffic type are given below and summarized in Table 13. Consider them as general guidelines and not strict recommendations. Once QoS parameters are set, you can monitor the performance of the application to determine if the actual behavior of the applications matches your expectations. It is very important to understand the needs and behavior of the particular applications you wish to protect or limit. Behavioral aspects to consider include bandwidth needs, sensitivity to latency and jitter, and sensitivity and impact of packet loss.

Voice Applications
Voice applications typically demand small amounts of bandwidth. However, the bandwidth must be constant and predictable because voice applications are typically sensitive to latency (inter-packet delay) and jitter (variation in inter-packet delay). The most important QoS parameter to establish for voice applications is minimum bandwidth, followed by priority.

Video Applications
Video applications are similar in needs to voice applications, with the exception that bandwidth requirements are somewhat larger, depending on the encoding. It is important to understand the behavior of the video application being used. For example, in the playback of stored video streams, some applications can transmit large amounts of data for multiple streams in one spike, with the expectation that the end-stations will buffer significant amounts of video-stream data. This can present a problem to the network infrastructure, because it must be capable of buffering the transmitted spikes where there are speed differences (for example, going from Gigabit Ethernet to Fast Ethernet). Key QoS parameters for video applications include minimum bandwidth, priority, and possibly buffering (depending upon the behavior of the application).

Critical Database Applications

Database applications, such as those associated with ERP, typically do not demand significant bandwidth and are tolerant of delay. You can establish a minimum bandwidth using a priority less than that of delay-sensitive applications.

Web Browsing Applications

QoS needs for Web browsing applications cannot be generalized into a single category. For example, ERP applications that use a browser front-end may be more important than retrieving daily news information. Traffic groupings can typically be distinguished from each other by their server source and destinations. Most browser-based applications are distinguished by the dataflow being asymmetric (small dataflows from the browser client, large dataflows from the server to the browser client). An exception to this may be created by some Java -based applications. In addition, Web-based applications are generally tolerant of latency, jitter, and some packet loss, however small packet-loss may have a large impact on perceived performance due to the nature of TCP. The relevant parameter for protecting browser applications is minimum bandwidth. The relevant parameter for preventing non-critical browser applications from overwhelming the network is maximum bandwidth. In addition, RED can be used to reduce session loss if the queue that floods Web traffic becomes over-subscribed.

ExtremeWare 7.1.0 Software User Guide

133

Quality of Service (QoS)

File Server Applications

With some dependencies on the network operating system, file serving typically poses the greatest demand on bandwidth, although file server applications are very tolerant of latency, jitter, and some packet loss, depending on the network operating system and the use of TCP or UDP. NOTE Full-duplex links should be used when deploying policy-based QoS. Half-duplex operation on links can make delivery of guaranteed minimum bandwidth impossible. Table 13 summarizes QoS guidelines for the different types of network traffic. Table 13: Traffic Type and QoS Guidelines
Traffic Type Voice Video Database Web browsing File server Key QoS Parameters Minimum bandwidth, priority Minimum bandwidth, priority, buffering (varies) Minimum bandwidth Minimum bandwidth for critical applications, maximum bandwidth for non-critical applications, RED Minimum bandwidth

Configuring QoS
To configure QoS, you define how your switch responds to different categories of traffic by creating and configuring QoS profiles. You then group traffic into categories (according to application, as previously discussed) and assign each category to a QoS profile. Configuring QoS is a three-step process: 1 Configure the QoS profile. QoS profileA class of service that is defined through minimum and maximum bandwidth parameters, configuration of buffering and RED, and prioritization settings. The bandwidth and level of service that a particular type of traffic or traffic grouping receives is determined by assigning it to a QoS profile. 2 Create traffic groupings. Traffic groupingA classification or traffic type that has one or more attributes in common. These can range from a physical port to a VLAN to IP layer 4 port information. You assign traffic groupings to QoS profiles to modify switch forwarding behavior. Traffic groupings transmitting out the same port that are assigned to a particular QoS profile share the assigned bandwidth and prioritization characteristics, and hence share the class of service. 3 Monitor the performance of the application with the QoS monitor to determine whether the policies are meeting the desired results. The next sections describe each of these QoS components in detail.

134

ExtremeWare 7.1.0 Software User Guide

QoS Profiles

QoS Profiles
A QoS profile defines a class of service by specifying traffic behavior attributes, such as bandwidth. The parameters that make up a QoS profile include: Minimum bandwidthThe minimum percentage of total link bandwidth that is reserved for use by a hardware queue on a physical port. Bandwidth unused by the queue can be used by other queues. The minimum bandwidth for all queues should add up to less than 90%. The default value on all minimum bandwidth parameters is 0%. Maximum bandwidthThe maximum percentage of total link bandwidth that can be transmitted by a hardware queue on a physical port. The default value on all maximum bandwidth parameters is 100%. PriorityThe level of priority assigned to a hardware queue on a physical port. There are eight different available priority settings. By default, each of the default QoS profiles is assigned a unique priority. You would use prioritization when two or more hardware queues on the same physical port are contending for transmission on the same physical port, only after their respective bandwidth management parameters have been satisfied. If two hardware queues on the same physical port have the same priority, a round-robin algorithm is used for transmission, depending on the available link bandwidth. When configured to do so, the priority of a QoS profile can determine the 802.1p bits used in the priority field of a transmitted packet (described later). The priority of a QoS profile determines the DiffServ code point value used in an IP packet when the packet is transmitted (described later). BufferThis parameter reserves buffer memory for use exclusively by a QoS profile across all affected ports. The default value for buffer settings is 0%. The sum of all QoS profile buffer parameters should not exceed 100%. The maxbuf parameter allows you to set a maximum buffer size (in Kbytes or Mbytes) for each queue, so that a single queue will not consume all of the un-allocated buffer space. The default buffer size is 256K. You should not modify the buffer parameter unless specific situations and application behavior indicate. A QoS profile does not alter the behavior of the switch until it is assigned to a traffic grouping. Recall that QoS profiles are linked to hardware queues. There are multiple hardware queues per physical port. By default, a QoS profile links to the identical hardware queue across all the physical ports of the switch. The default QoS profiles cannot be deleted. Also by default, a QoS profile maps directly to a specific hardware queue across all physical ports. The settings for the default QoS parameters are summarized in Table 14.

Table 14: QoS Parameters

Profile Name Qp1 Qp2 Qp3 Qp4 Qp5 Qp6 Hardware Queue Priority Q0 Q1 Q2 Q3 Q4 Q5 Low Lowhi Normal Normalhi Medium Mediumhi Buffer 0 0 0 0 0 0 Minimum Bandwidth 0% 0% 0% 0% 0% 0% Maximum Bandwidth 100% 100% 100% 100% 100% 100%

ExtremeWare 7.1.0 Software User Guide

135

Quality of Service (QoS)

Table 14: QoS Parameters (continued)

Qp7 Qp8 Q6 Q7 High Highhi 0 0 0% 0% 100% 100%

Traffic Groupings
Once a QoS profile is modified for bandwidth and priority, you assign traffic a grouping to the profile. A traffic grouping is a classification of traffic that has one or more attributes in common. Traffic is typically grouped based on the applications discussed starting on page 132. Traffic groupings are separated into the following categories for discussion: IP-based information, such as IP source/destination and TCP/UDP port information Destination MAC (MAC QoS groupings) Explicit packet class of service information, such as 802.1p or DiffServ (IP TOS) Physical/logical configuration (physical source port or VLAN association) In the event that a given packet matches two or more grouping criteria, there is a predetermined precedence for which traffic grouping will apply. In general, the more specific traffic grouping takes precedence. By default, all traffic groupings are placed in the QoS profile Qp1. The supported traffic groupings are listed in Table 15. The groupings are listed in order of precedence (highest to lowest). The four types of traffic groupings are described in detail on the following pages.

Table 15: Traffic Groupings by Precedence

IP Information (Access Lists) Groupings Access list precedence determined by user configuration

Destination Address MAC-Based Groupings Permanent Dynamic Blackhole Broadcast/unknown rate limiting

Explicit Packet Class of Service Groupings DiffServ (IP TOS) 802.1P

Physical/Logical Groupings VLAN Source port

IP-Based Traffic Groupings

IP-based traffic groupings are based on any combination of the following items: IP source or destination address TCP/UDP or other layer 4 protocol TCP/UDP port information

136

ExtremeWare 7.1.0 Software User Guide

Traffic Groupings

IP-based traffic groupings are defined using access lists. Access lists are discussed in detail in Chapter 11. By supplying a named QoS profile at the end of the access list command syntax, you can prescribe the bandwidth management and priority handling for that traffic grouping. This level of packet filtering has no impact on performance.

MAC-Based Traffic Groupings

QoS profiles can be assigned to destination MAC addresses. MAC-based traffic groupings are configured using the following command:
create fdbentry <mac_address> vlan <vlan name> [blackhole | port <portlist> | dynamic] qosprofile <qosprofile>

The MAC address options, defined below, are as follows: Permanent Dynamic Blackhole Broadcast/unknown rate limiting

Permanent MAC addresses

Permanent MAC addresses can be assigned a QoS profile whenever traffic is destined to the MAC address. This can be done when you create a permanent FDB entry. For example:
create fdbentry 00:11:22:33:44:55 vlan default port 4:1 qosprofile qp2

Dynamic MAC Addresses

Dynamic MAC addresses can be assigned a QoS profile whenever traffic is destined to the MAC address. For any port on which the specified MAC address is learned in the specified VLAN, the port is assigned the specified QoS profile. For example:
create fdbentry 00:11:22:33:44:55 vlan default dynamic qosprofile qp3

The QoS profile is assigned when the MAC address is learned. If a clients location moves, the assigned QoS profile moves with the device. If the MAC address entry already exists in the FDB, you can clear the forwarding database so that the QoS profile can be applied when the entry is added again. Use the following command to clear the FDB:
clear fdb

Blackhole MAC Address

Using the blackhole option configures the switch to not forward any packets to the destination MAC address on any ports for the VLAN specified. The blackhole option is configured using the following command:
create fdbentry 00:11:22:33:44:55 vlan default blackhole

Broadcast/Unknown Rate Limiting MAC Address

It is possible to assign broadcast and unknown destination packets to a QoS profile that has the desired priority and bandwidth parameters. Broadcast/unknown rate limiting is an extension of the QoS feature used for destination MAC addresses.

ExtremeWare 7.1.0 Software User Guide

137

Quality of Service (QoS)

For example, if you want to limit broadcast and unknown traffic on the VLAN default to the bandwidth and priority defined in QoS profile qp3, the command is:
create fdbentry ff:ff:ff:ff:ff:ff vlan default dynamic qp3

NOTE IP multicast traffic is subject to broadcast and unknown rate limiting only when IGMP snooping is disabled.

Verifying MAC-Based QoS Settings

To verify any of the MAC-based QoS settings, use either the command
show fdb permanent

or the command
show qosprofile <qosprofile>

Explicit Class of Service (802.1p and DiffServ) Traffic Groupings

This category of traffic groupings describes what is sometimes referred to as explicit packet marking, and refers to information contained within a packet intended to explicitly determine a class of service. That information includes: IP DiffServ code points, formerly known as IP TOS bits Prioritization bits used in IEEE 802.1p packets An advantage of explicit packet marking is that the class of service information can be carried throughout the network infrastructure, without repeating what can be complex traffic grouping policies at each switch location. Another advantage is that end stations can perform their own packet marking on an application-specific basis. Extreme switch products have the capability of observing and manipulating packet marking information with no performance penalty. The documented capabilities for 802.1p priority markings or DiffServ capabilities (if supported) are not impacted by the switching or routing configuration of the switch. For example, 802.1p information can be preserved across a routed switch boundary and DiffServ code points can be observed or overwritten across a layer 2 switch boundary.

Configuring 802.1p Priority

Extreme switches support the standard 802.1p priority bits that are part of a tagged Ethernet packet. The 802.1p bits can be used to prioritize the packet, and assign it to a particular QoS profile. When a packet arrives at the switch, the switch examines the 802.1p priority field maps it to a specific hardware queue when subsequently transmitting the packet. The 802.1p priority field is located directly following the 802.1Q type field, and preceding the 802.1Q VLAN ID, as shown in Figure 14.

138

ExtremeWare 7.1.0 Software User Guide

Traffic Groupings

Figure 14: Ethernet packet encapsulation

802.1Q type 8100

802.1p priority

802.1Q VLAN ID

Destination address

Source address

IP packet

CRC
EW_024

Observing 802.1p Information

When ingress traffic that contains 802.1p prioritization information is detected by the switch, the traffic is mapped to various hardware queues on the egress port of the switch. Eight hardware queues are supported. The transmitting hardware queue determines the bandwidth management and priority characteristics used when transmitting packets. To control the mapping of 802.1p prioritization values to hardware queues, 802.1p prioritization values can be mapped to a QoS profile. The default mapping of each 802.1p priority value to QoS profile is shown in Table 16. Table 16: 802.1p Priority Value-to-QoS Profile Default Mapping
Priority Value 0 1 2 3 4 5 6 7 QoS Profile Qp1 Qp2 Qp3 Qp4 Qp5 Qp6 Qp7 Qp8

Changing the Default 802.1p Mapping

By default, a QoS profile is mapped to a hardware queue, and each QoS profile has configurable bandwidth parameters and priority. In this way, an 802.1p priority value seen on ingress can be mapped to a particular QoS profile and with specific bandwidth management and priority behavior. To change the default mappings of QoS profiles to 802.1p priority values, use the following command:
configure dot1p type <dot1p_priority> qosprofile <qosprofile>

Configuring 802.1p Priority For Slow Path Traffic

Some traffic can originate on the switch, for example Ping or Telnet packets. This traffic comes from the switch CPU and is referred to as slow path traffic. This traffic is internally tagged with an 802.1p

ExtremeWare 7.1.0 Software User Guide

139

Quality of Service (QoS)

priority of 7, by default, and egresses the VLAN through the highest queue. If you want to set a different tag (and priority) use the following command to set the priority to a number between 0 and 7:
configure vlan <vlan name> priority <number>

Other traffic transported across the switch and VLAN will not be changed, in other words, the 802.1p values will not be affected by the VLAN priority setting.

Replacing 802.1p Priority Information

By default, 802.1p priority information is not replaced or manipulated, and the information observed on ingress is preserved when transmitting the packet. This behavior is not affected by the switching or routing configuration of the switch. However, the switch is capable of inserting and/or overwriting 802.1p priority information when it transmits an 802.1Q tagged frame. If 802.1p replacement is enabled, the 802.1p priority information that is transmitted is determined by the hardware queue that is used when transmitting the packet. To replace 802.1p priority information, use the following command:
enable dot1p replacement ports [<portlist> | all]

802.1p priority information is replaced according to the hardware queue that is used when transmitting from the switch. The mapping is described in Table 17. This mapping cannot be changed. Table 17: Queue to 802.1p Priority Replacement Value
Hardware Queue Q0 Q1 Q2 Q3 Q4 Q5 Q6 Q7 802.1p Priority Replacement Value

0 1 2 3 4 5 6 7

Configuring DiffServ
Contained in the header of every IP packet is a field for IP Type of Service (TOS), now also called the DiffServ field. The TOS field is used by the switch to determine the type of service provided to the packet. Observing DiffServ code points as a traffic grouping mechanism for defining QoS policies and overwriting the Diffserv code point fields are supported. Figure 15 shows the encapsulation of an IP packet header.

140

ExtremeWare 7.1.0 Software User Guide

Traffic Groupings

Figure 15: IP packet header encapsulation

DiffServ code point 0 Version bits IHL Type-of-service Flags Protocol Source address Destination address Options (+ padding) Data (variable)
EW_023

31 Total length Fragment offset

Identification Time-to-live

Header checksum

Observing DiffServ Information

When a packet arrives at the switch on an ingress port, the switch examines the first six of eight TOS bits, called the code point. The switch can assign the QoS profile used to subsequently transmit the packet based on the code point. The QoS profile controls a hardware queue used when transmitting the packet out of the switch, and determines the forwarding characteristics of a particular code point. Viewing DiffServ information can be enabled or disabled; by default it is disabled. To view DiffServ information, use the following command:
enable diffserv examination ports [<portlist> | all]

Changing DiffServ Code point assignments in the Q0S Profile

Because the code point uses six bits, it has 64 possible values (26 = 64). Be default, the values are grouped and assigned to the default QoS profiles listed in Table 18. Table 18: Default Code Point-to-QoS Profile Mapping
Code Point 0-7 8-15 16-23 24-31 32-39 40-47 48-55 56-63 QoS Profile Qp1 Qp2 Qp3 Qp4 Qp5 Qp6 Qp7 Qp8

ExtremeWare 7.1.0 Software User Guide

141

Quality of Service (QoS)

You can change the QoS profile assignment for all 64 code points using the following command:
configure diffserv examination code-point <code_point> qosprofile <qosprofile> ports [<portlist> | all]

Once assigned, the rest of the switches in the network prioritize the packet using the characteristics specified by the QoS profile.

Replacing DiffServ Code Points

The switch can be configured to change the DiffServ code point in the packet prior to the packet being transmitted by the switch. This is done with no impact on switch performance. The DiffServ code point value used in overwriting a packet is determined by the 802.1p priority value. The 802.1p priority value is, in turn, determined by the hardware queue used when transmitting a packet, as described in Replacing 802.1p Priority Information on page 140. It is not necessary to receive or transmit 802.1Q tagged frames, only to understand that the egress hardware queue, which also determines the 802.1p priority value, can also be configured to determine the DiffServ code point value if you want to replace the DiffServ code points. To replace DiffServ code points you must enable both 802.1p replacement and DiffServ replacement using the following commands:
enable dot1p replacement ports [<portlist> | all] enable diffserv replacement ports [<portlist> | all]

The default 802.1p priority value to code point mapping is described in Table 19. Table 19: Default 802.1p Priority Value-to-Code Point Mapping
802.1p Priority Hardware Queue value Q0 Q1 Q2 Q3 Q4 Q5 Q6 Q7 0 1 2 3 4 5 6 7 Code Point 0 8 16 24 32 40 48 56

You then change the 802.1p priority to DiffServ code point mapping to any code point value using the following command:
configure diffserv replacement priority <vpri> code_point <code_point> ports [<portlist> | all]

By doing so, the hardware queue used to transmit a packet determines the DiffServ value replaced in the IP packet. To verify the DiffServ configuration, use the following command:
show ports <portlist> info {detail}

142

ExtremeWare 7.1.0 Software User Guide

Traffic Groupings

DiffServ Example
In this example, we use DiffServ to signal a class of service throughput and assign any traffic coming from network 10.1.2.x with a specific DiffServ code point. This allows all other network switches to send and observe the Diffserv code point instead of repeating the same QoS configuration on every network switch. To configure the switch that handles incoming traffic from network 10.1.2.x, follow these steps: 1 Configure parameters of the QoS profile QP3:
configure qp3 min 10 max 100

2 Assign a traffic grouping for traffic from network 10.1.2.x to qp3:

create access-list TenOneTwo configure TenOneTwo 10.1.2.0/24 permit qp3

3 To enable the switch to overwrite the DiffServ code point:

enable dot1p replacement enable diffserv replacement

4 Configure the switch so that other switches can signal class of service that this switch should observe:
enable diffserv examination

Table 14 indicates that qp3 is tied to hardware queue Q2. We also know that when replacement is enabled all traffic sent out Q2 will contain code point value 16 (according to Table 19). If this is the desired code point to use, all traffic from 10.1.2.x will be sent out QP3 (at 10% minimum and 100% maximum) with a code point value of 16.

Physical and Logical Groupings

Two traffic groupings exist in this category: Source port VLAN

Source port
A source port traffic grouping implies that any traffic sourced from this physical port uses the indicated QoS profile when the traffic is transmitted out to any other port. To configure a source port traffic grouping, use the following command:
configure ports <portlist> qosprofile <qosprofile>

In the following modular switch example, all traffic sourced from slot 5 port 7 uses the QoS profile named qp3 when being transmitted.
configure ports 5:7 qosprofile qp3

VLAN
A VLAN traffic grouping indicates that all intra-VLAN switched traffic and all routed traffic sourced from the named VLAN uses the indicated QoS profile. To configure a VLAN traffic grouping, use the following command:
configure vlan <vlan name> qosprofile <qosprofile>

ExtremeWare 7.1.0 Software User Guide

143

Quality of Service (QoS)

For example, all devices on VLAN servnet require use of the QoS profile qp4. The command to configure this example is as follows:
configure vlan servnet qosprofile qp4

Verifying Physical and Logical Groupings

To verify settings on ports or VLANs, use the following command:
show qosprofile <qosprofile>

The same information is also available for ports or VLANs using one of the following commands:
show ports <portlist> info {detail}

or
show vlan

Configuring QoS Traffic Grouping Priorities

Normally, there is a predetermined precedence for which traffic grouping applies to a given packet that matches two or more grouping criteria. In general, the more specific traffic grouping takes precedence. However, you can configure a new set of priorities using the following command:
configure qostype priority [source-mac | dest-mac | access-list | vlan | diffserv | dot1p] <priority>

The valid priority values are 0 - 15. The default values are shown in Table 20. Table 20: Traffic Grouping Priority Default Values
QoS Type source-mac dest-mac access-list vlan diffserv dot1p Default Value 7 8 11 1 3 2

QoS types with a greater value take higher precedence. For example, to force FDB source-mac QoS to take a higher precedence over FDB dest-mac QoS, use the commands:
configure qostype priority source-mac 9

where 9 is greater than the default value assigned to the dest-mac QoS type. Traffic groupings based on the source port always have the lowest priority, and all other traffic groupings take priority. You cannot change the priority for source port-based traffic groupings.

144

ExtremeWare 7.1.0 Software User Guide

Verifying Configuration and Performance

Verifying and Resetting QoS Traffic Grouping Priorities

To verify QoS traffic grouping priority settings, use the command:
show qostype priority

To reset priority settings to their default values, use the command:

unconfigure qostype priority

Verifying Configuration and Performance

Once you have created QoS policies that manage the traffic through the switch, you can use the QoS monitor to determine whether the application performance meets your expectations.

QoS Monitor
The QOS monitor is a utility that monitors the hardware queues associated with any port(s). The QOS monitor keeps track of the number of frames and the frames per second that a specific queue is responsible for transmitting on a physical port. Two options are available: a real-time display, and a separate option for retrieving information in the background and writing it to the log.

Real-Time Performance Monitoring

The real-time display scrolls through the given portlist to provide statistics. You can choose screens for packet count and packets per second. The specific port being monitored is indicated by an asterisk (*) appearing after the port number in the display. The view real-time switch per-port performance, use the following command:
show ports {<portlist>} qosmonitor

QoS monitor sampling is configured as follows: The port is monitored for 20 seconds before the switch moves on to the next port in the list. A port is sampled for five seconds before the packets per second (pps) value is displayed on the screen.

Background Performance Monitoring

Monitoring QoS in the background places transmit counter and any overflow information into the switch log. The log notification appears if one of the queues experiences an overflow condition since the last time it was sampled. An overflow entry indicates that a queue was over-subscribed at least temporarily, and is useful for determining correct QoS settings and potential over-subscription issues.

ExtremeWare 7.1.0 Software User Guide

145

Quality of Service (QoS)

Displaying QoS Profile Information

The QoS monitor can also be used to verify the QoS configuration and monitor the use of the QoS policies that are in place. To display QoS information on the switch, use the following command:
show qosprofile <qosprofile>

Displayed information includes: QoS profile name Minimum bandwidth Maximum bandwidth Priority A list of all traffic groups to which the QoS profile is applied Additionally, QoS information can be displayed from the traffic grouping perspective by using one or more of the following commands: show fdb permanentDisplays destination MAC entries and their QoS profiles. show switchDisplays information including PACE enable/disable information. show vlanDisplays the QoS profile assignments to the VLAN. show ports <portlist> info {detail}Displays information including QoS information for the port.

Modifying a QoS Configuration

If you make a change to the parameters of a QoS profile after implementing your configuration, the timing of the configuration change depends on the traffic grouping involved. The following rules apply: For destination MAC-based grouping (other than permanent), clear the MAC FDB using the command clear fdb. This command should also be issued after a configuration is implemented, as the configuration must be in place before an entry is made in the MAC FDB. For permanent destination MAC-based grouping, re-apply the QoS profile to the static FDB entry, as documented. You can also save and reboot the switch. For physical and logical groupings of a source port or VLAN, re-apply the QoS profile to the source port or VLAN, as documented. You can also save and reboot the switch.

Bi-Directional Rate Shaping

Bi-directional rate shaping allows you to manage bandwidth on layer 2 and layer 3 traffic flowing both to and from the switch. You can configure up to eight ingress queues per VLAN and up to eight egress queues per physical port. By defining minimum and maximum bandwidth for each queue, you define committed information rates for each queue. You can define different rates for ingress and egress queues. You can then provide traffic groupings (such as physical port, VLAN, .1P, DiffServ, IP address, or layer 4 flow) for the predefined QoS Profiles, thereby directing specific types of traffic to the desired queue.

146

ExtremeWare 7.1.0 Software User Guide

Bi-Directional Rate Shaping

Configuring Bi-Directional Rate Shaping

Each VLAN requires a loopback port; all traffic from rate-shaped ports is directed through the loopback port for that VLAN. To rate-shape ingress traffic, configure QoS normally on the loopback port for the VLAN. The maximum bandwidth and traffic grouping defined in the QoS profile for the loopback port defines the rate limit for ingress traffic on rate-shaped ports in that VLAN. Use the following guidelines for bi-directional rate shaping: You must configure a loopback port before adding rate-shaped ports. A loopback port cannot be used by an external device. You must configure the loopback port with a unique loopback VLAN tag ID. Ingress traffic on a port that is configured to use the loopback port will be rate-shaped. Ingress traffic on a port that is not configured to use the loopback port will not be rate-shaped. Unicast traffic from a non-rate-shaped port to a rate-shaped port within the VLAN will not be rate-shaped. The aggregate forwarding bandwidth of all rate-shaped ports in a VLAN is determined by the setting of the queue parameters of the loopback port. For 10/100 Mbps ports, you can configure the loopback port as a 10 Mbps port to achieve lower bandwidth values. To remove the rate-shaping parameters of the loopback port, configure the QoS profile without specifying the buffer or portlist parameters.

Bandwidth Settings
You apply bandwidth settings to QoS profiles as a percentage of bandwidth. QoS profile bandwidth settings are in turn applied to queues on physical ports. The impact of the bandwidth setting is determined by the port speed (10, 100, or 1000 Mbps).

Maximum Bandwidth Settings

The maximum bandwidth settings determine the port bandwidth available to each queue. Use Table 21 to determine the bandwidth associated with each bandwidth setting at different port speeds. Table 21: Maximum Bandwidth Settings
Bandwidth Setting (%) 2 3 5 7 8 10 11 15 20 25 Bandwidth at 10 Mbps 200 Kbps 310 Kbps 490 Kbps 690 Kbps 790 Kbps 960 Kbps 1.12 Mbps 1.5 Mbps 1.9 Mbps 2.5 Mbps Bandwidth at 100 Mbps 2 Mbps 31 Mbps 4.9 Mbps 6.9 Mbps 7.9 Mbps 9.6 Mbps 11.2 Mbps 15 Mbps 19 Mbps 25 Mbps Bandwidth at 1000 Mbps 20 Mbps 30 Mbps 50 Mbps 69 Mbps 79 Mbps 96 Mbps 112 Mbps 150 Mbps 190 Mbps 250 Mbps

ExtremeWare 7.1.0 Software User Guide

147

Quality of Service (QoS)

Table 21: Maximum Bandwidth Settings (continued)

Bandwidth Setting (%) 30 35 40 50 60 65 70 80 95 100 Bandwidth at 10 Mbps 3.3 Mbps 3.5 Mbps 4.2 Mbps 5 Mbps 5.7 Mbps 6.5 Mbps 7.3 Mbps 7.9 Mbps 9.5 Mbps 10 Mbps Bandwidth at 100 Mbps 33 Mbps 35 Mbps 42 Mbps 50 Mbps 57 Mbps 65 Mbps 73 Mbps 79 Mbps 95 Mbps 100 Mbps Bandwidth at 1000 Mbps 330 Mbps 350 Mbps 420 Mbps 500 Mbps 570 Mbps 650 Mbps 730 Mbps 790 Mbps 950 Mbps 1000 Mbps

If you choose a setting not listed in Table 21, the setting is rounded up to the next value.

Minimum Bandwidth Settings

The minimum bandwidth settings determine the port bandwidth reserved for each queue. Use Table 22 to determine the bandwidth associated with each setting. Table 22: Minimum Bandwidth Settings
Bandwidth Setting (%) 4 6 8 9 10 20 25 35 50 60 80 89 Bandwidth at 10 Mbps 420 Kbps 570 Kbps 750 Kbps 930 Kbps 1 Mbps 1.87 Mbps 2.63 Mbps 3.4 Mbps 4.9 Mbps 6.3 Mbps 7.9 Mbps 9.4 Mbps Bandwidth at 100 Mbps 4.2 Mbps 5.7 Mbps 7.5 Mbps 9.3 Mbps 10 Mbps 18.7 Mbps 26.3 Mbps 34 Mbps 49 Mbps 63 Mbps 79 Mbps 94 Mbps Bandwidth at 1000 Mbps 42 Mbps 57 Mbps 75 Mbps 93 Mbps 100 Mbps 187 Mbps 263 Mbps 340 Mbps 490 Mbps 630 Mbps 790 Mbps 940 Mbps

NOTE Keep the sum of the minimum bandwidth values for the applied QoS profiles less than 90%. If the sum exceeds 90%, a lower priority queue might be unable to transmit in a sustained over-subscription situation.

148

ExtremeWare 7.1.0 Software User Guide

Dynamic Link Context System

If you choose a setting not listed in Table 22, the setting is rounded up to the next value. If the actual bandwidth used is below the minimum bandwidth, the additional bandwidth is available for other queues on that physical port.

Bi-Directional Rate Shaping Limitations

Consider the following limitations when configuring bi-directional rate shaping: You must delete all rate-shaped ports before deleting the loopback port. If rate-shaped ports within a VLAN use different bandwidth parameters, set the priority of the QoS profiles on the loopback port and rate-shaped ports to low. Layer 2 rate-shaping only affects a single VLAN. On a BlackDiamond switch, the loopback port must be on the same I/O module as the rate-shaped ports. You must enable IP forwarding on the VLAN prior to adding the loopback port to a VLAN for layer 2 rate shaping. You cannot use tagged ports for rate shaping. You cannot use load-shared ports for rate-shaping. You cannot run VRRP on a VLAN that is configured for ingress rate shaping.

Dynamic Link Context System

The Dynamic Link Context System (DLCS) is a feature that snoops WINS NetBIOS packets and creates a mapping between a user name, the IP address or MAC address, and the switch/port. Based on the information in the packet, DLCS can detect when an end station boots up or a user logs in or out, and dynamically maps the end station name to the current IP address and switch/port. This information is available for use by ExtremeWare Enterprise Manager (EEM) version 2.1 or later or EPICenter in setting policies that can be applied to users and can dynamically follow a users location. DLCS provides you with valuable information on a user s location and associated network attributes. For DLCS to operate within ExtremeWare, the user or end station must allow for automatic DLCS updates. This feature is intended for use in conjunction with EPICenter Policy Manager. Refer to the EPICenter documentation for more information.

DLCS Guidelines
Follow these guidelines when using DLCS: Only one user is allowed on one workstation at a given time. A user can be logged into many workstations simultaneously. An IP-address can be learned on only one port in the network at a given time. Multiple IP-addresses can be learned on the same port. DLCS mapping is flushed when a user logs in or logs out, or when an end-station is shutdown.

ExtremeWare 7.1.0 Software User Guide

149

Quality of Service (QoS)

DLCS Limitations
Consider the following limitations concerning data received from WINS snooping: DLCS does not work for the WINS server. This is because the WINS server does not send NETBIOS packets on the network (these packets are address to itself). When the IP address of a host is changed, and the host is not immediately rebooted, the old host-to-IP address mapping is never deleted. You must delete the mapping of the host-to-IP address through the Policy Manager. When the host is moved from one port to another port on a switch, the old entry does not age out unless the host is rebooted or a user login operation is performed after the host is moved. DLCS information is dynamic, therefore, if the switch is rebooted, the information is lost. This information is still stored in the policy-server. To delete the information from the policy system, you must explicitly delete configuration parameters from the EEM or EPICenter Policy Applet user interface. As a workaround, you can delete the switch that was rebooted from the list of managed devices in the EEM or EPICenter Inventory Applet, and re-add the switch to the Inventory Manager. DLCS is not supported on hosts that have multiple NIC cards. IPQoS is not supported to a WINS server that is serving more than one VLAN. If you attempt to add a WINS server to serve more than one VLAN, and there are IPQoS rules defined for that server, the command to add the WINS server is rejected.

150

ExtremeWare 7.1.0 Software User Guide

Network Address Translation (NAT)

This chapter covers the following topics: Overview on page 151 Internet IP Addressing on page 152 Configuring VLANs for NAT on page 152 Configuring NAT on page 154 Creating NAT Rules on page 154 Displaying NAT Settings on page 156 Disabling NAT on page 157

Overview
NAT is a feature that allows one set of IP addresses, typically private IP addresses, to be converted to another set of IP addresses, typically public Internet IP addresses. This conversion is done transparently by having a NAT device (any Extreme Networks switch using the i chipset) rewrite the source IP address and Layer 4 port of the packets. Figure 16: NAT Overview

Inside

NAT switch

Outside

Private Network

Outgoing

Outgoing

Internet

Incoming

Incoming

EW_078

ExtremeWare 7.1.0 Software User Guide

151

Network Address Translation (NAT)

You can configure NAT to conserve IP address space by mapping a large number of inside (private) addresses to a much smaller number of outside (public) addresses. In implementing NAT, you must configure at least two separate VLANs involved. One VLAN is configured as inside, and corresponds to the private IP addresses you would like to translate into other IP addresses. The other type of VLAN is configured as outside, which corresponds to the public (probably Internet) IP addresses you want the inside addresses translated to. The mappings between inside and outside IP addresses are done via rules that specify the IP subnets involved and the algorithms used to translate the addresses.

NOTE The NAT modes in ExtremeWare support translating traffic that initiates only from inside addresses. NAT rules are associated with a single outside VLAN. Multiple rules per outside VLAN are allowed. The rules take effect in the order they are displayed using the show command. Any number of inside VLANs can use a single outside VLAN, assuming that you have created proper rules. Similarly, a single inside VLAN can use any number of different outside VLANs, assuming that the rules and routing are set up properly. Both TCP and UDP have layer 4 port numbers ranging from 1 to 65535. These layer 4 ports, in combination with the IP addresses, form a unique identifier which allows hosts (as well as the NAT switch) to distinguish between separate conversations. NAT operates by replacing the inside IP packets source IP and layer 4 port with an outside IP and layer 4 port. The NAT switch maintains a connection table to map the return packets on the outside VLAN back into their corresponding inside sessions.

Internet IP Addressing
When implementing NAT in an Internet environment, it is strongly recommended that you use one of the reserved private IP address ranges for your inside IP addresses. These ranges have been reserved specifically for networks not directly attached to the Internet. Using IP addresses within these ranges prevents addressing conflicts with public Internet sites to which you want to connect. The ranges are as follows: 10.0.0.0/8Reserved Class A private address space 172.16.0.0/12Reserved Class B private address space 192.168.0.0/16Reserved Class C private address space

Configuring VLANs for NAT

You must configure each VLAN participating in NAT as either an inside or outside VLAN. To configure a VLAN as an inside or outside VLAN, use the following command:
configure nat vlan <vlan name> [inside | outside | none]

When a VLAN is configured to be inside, traffic from that VLAN is translated only if it has a matching NAT rule. Any unmatched traffic will be routed normally and not be translated. Because all traffic runs through the central processing unit (CPU), it cannot run at line-rate.

152

ExtremeWare 7.1.0 Software User Guide

Configuring VLANs for NAT

When a VLAN is configured to be outside, it routes all traffic. Because all traffic runs through the CPU, it cannot run at line-rate. Normally, outside traffic will be able to initiate connections to the internal private IP addresses. If you want to prevent this, you can create IP and ICMP access-lists on the outside VLAN ports to deny traffic destined for the inside IP addresses. There is a NAT performance penalty when you do this. When a VLAN is configured to be none, all NAT functions are disabled and the VLAN operates normally. Below is a set of example ACL rules to deny outside traffic. These examples assume the inside network is 192.168.1.0/24 and the outside VLAN is on port 1.
create access-list deny_ip ip destination 192.168.1.0/24 source any deny ports 1 create access-list deny_icmp icmp destination 192.168.1.0/24 source any type any code any deny ports 1

NAT Modes
There are 4 different modes used to determine how the outside IP addresses and layer 4 ports are assigned. Static mapping Dynamic mapping Port-mapping Auto-constraining

Static Mapping
When static mapping is used, each inside IP address uses a single outside IP address. The layer 4 ports are not changed, only the IP address is rewritten. Because this mode requires a 1:1 mapping of internal to external addresses, it does not make efficient use of the external address space. However, it is useful when you have a small number of hosts that need to have their IP addresses rewritten without conflicting with other hosts. Because this mode does not rely on layer 4 ports, ICMP traffic is translated and allowed to pass.

Dynamic Mapping
Dynamic mapping is similar to static mapping in that the layer 4 ports are not rewritten during translation. Dynamic mapping is different in that the number of inside hosts can be greater than the number of outside hosts. The outside IP addresses are allocated on a first-come, first-serve basis to the inside IP addresses. When the last session for a specific inside IP address closes, that outside IP address can be used by other hosts. Since this mode does not rely on layer 4 ports, ICMP traffic is translated and allowed to pass.

Port-mapping
Port-mapping gives you the most efficient use of the external address space. As each new connection is initiated from the inside, the NAT device picks the next available source layer 4 port on the first available outside IP address. When all ports on a given IP address are in use, the NAT device uses ports off of the next outside IP address. Some systems reserve certain port ranges for specific types of traffic, so it is possible to map specific source layer 4 port ranges on the inside to specific outside source ranges. However, this may cause a small performance penalty. In this case, you would need to make several rules using the same inside and outside IP addresses, one for each layer 4 port range. ICMP

ExtremeWare 7.1.0 Software User Guide

153

Network Address Translation (NAT)

traffic is not translated in this mode. You must add a dynamic NAT rule for the same IP address range to allow for ICMP traffic.

Auto-constraining
The auto-constraining algorithm for port-mapping limits the number of outside layer 4 ports a single inside host can use simultaneously. The limitation is based on the ratio of inside to outside IP addresses. The outside IP address and layer 4 port space is evenly distributed to all possible inside hosts. This guarantees that no single inside host can prevent other traffic from flowing through the NAT device. Because of the large number of simultaneous requests that can be made from a web browser, it is not recommended that this mode be used when a large number of inside hosts are being translated to a small number of outside IP addresses. ICMP traffic is not translated in this mode. You must add a dynamic NAT rule for the same IP address range to allow for ICMP traffic.

Configuring NAT
The behavior of NAT is determined by the rules you create to translate the IP addresses. You must attach each rule to a specific VLAN. All rules are processed in order. The options specified on the NAT rule determine the algorithm used to translate the inside IP addresses to the outside IP addresses. For outgoing (inside to outside) packets, the first rule to match is processed. All following rules are ignored. All return packets must arrive on the same outside VLAN on which the session went out. For most configurations, make sure that the outside IP addresses specified in the rule are part of the outside VLANs subnet range, so that the switch can proxy the address resolution protocol (ARP) for those addresses. To enable NAT functionality, use the following command:
enable nat

Creating NAT Rules

This section describes how to configure the various types of NAT (static, dynamic, portmap, and auto-constrain). In the examples in this section, advanced port and destination matching options have been removed. For information on how to use some of the more advanced rule matching features, see Advanced Rule Matching on page 156.

Creating Static and Dynamic NAT Rules

To create static or dynamic NAT rules, use this command:
configure nat [add | delete] vlan <outside_vlan> map source [any | <ipaddress> [/<bits>| <netmask>]] to <ipaddress> [/<mask> | <netmask> | - <ipaddress>]

This is the simplest NAT rule. You specify the outside vlan name, and a subnet of inside IP addresses, which get translated to the outside IP address using the specified mode (static in this case). For the outside IP addresses, you can either specify an IP address and netmask or a starting and ending IP range to determine the IP addresses the switch will translate the inside IP addresses to. If the netmask for both the source and NAT addresses is /32, the switch will use static NAT translation. If the netmask for both the source and NAT addresses are not both /32, the switch will use dynamic NAT translation.

154

ExtremeWare 7.1.0 Software User Guide

Creating NAT Rules

Static NAT Rule Example

configure nat add out_vlan_1 map source 192.168.1.12/32 to 216.52.8.32/32

Dynamic NAT Rule Example

configure nat add out_vlan_1 map source 192.168.1.0/24 to 216.52.8.1 - 216.52.8.31

Creating Portmap NAT Rules

To configure portmap NAT rules, use this command:
configure nat [add | delete] vlan <outside_vlan> map source [any | <ipaddress> [/<bits>| <netmask>]] to <ip> [/<mask> | <netmask> | - <ipaddress>] {[tcp |udp | both] portmap {<min> - <max>}}

The addition of an L4 protocol name and the portmap keyword tells the switch to use portmap mode. Optionally, you may specify the range of L4 ports the switch chooses on the translated IP addresses, but there is a performance penalty for doing this. Remember that portmap mode will only translate TCP and/or UDP, so a dynamic NAT rule must be specified after the portmap rule in order to allow ICMP packets through without interfering with the portmapping.

Portmap NAT Rule Example

configure nat add out_vlan_2 map source 192.168.2.0/25 to 216.52.8.32 /28 both portmap

Portmap Min-Max Example

configure nat add out_vlan_2 map source 192.168.2.128/25 to 216.52.8.64/28 tcp portmap 1024 - 8192

Creating Auto-Constrain NAT Rules

To create auto-constrain NAT rules, use the following command:
configure nat [add | delete] vlan <outside_vlan> map source [any | <ipaddress> [/<bits>| <netmask>]] to <ip> [/<mask> | <netmask> | - <ipaddress>] {[tcp |udp | both] auto-constrain}

This rule uses auto-constrain NAT. Remember that each inside IP address will be restricted in the number of simultaneous connections. Most installations should use portmap mode.

Auto-Constrain Example
configure nat add out_vlan_3 map source 192.168.3.0/24 to 216.52.8.64/32 both auto-constrain

ExtremeWare 7.1.0 Software User Guide

155

Network Address Translation (NAT)

Advanced Rule Matching

By default, NAT rules only match connections based on the source IP address of the outgoing packets. Using the L4-port and destination keywords, you can further limit the scope of the NAT rule so that it only applied to specific TCP/UDP layer 4 port numbers, or specific outside destination IP addresses.

NOTE Once a single rule is matched, no other rules are processed.

Destination Specific NAT

configure nat [add | delete] vlan <outside_vlan> map source [any | <ipaddress> [/<bits>| <netmask>]] {destination <ipaddress/mask> } to <ipaddress> [/<mask> | <netmask> | - <ipaddress>]

The addition of the destination optional keyword after the source IP address and mask allows the NAT rule to be applied to only packets with a specific destination IP address.

L4-Port Specific NAT

The addition of the L4-port optional keyword after the source IP address and mask allows the NAT rule to be applied to only packets with a specific L4 source or destination port. If you use the L4-port command after the source IP/mask, the rule will only match if the port(s) specified are the source L4-ports. If you use the L4-port command after the destination IP/mask, the rule will only match if the port(s) specified are the destination L4-ports. Both options may be used together to further limit the rule.

Configuring Time-outs
When an inside host initiates a session, a session table entry is created. Depending on the type of traffic or the current TCP state, the table entries time out after the configured time-out expires.

Displaying NAT Settings

To display NAT rules, use the following command:
show nat rules {vlan <outside_vlan>}

This command displays the NAT rules for a specific VLAN. Rules are displayed in the order they are processed, starting with the first one. To display NAT traffic statistics, use the following command:
show nat stats

This command displays statistics for the NAT traffic, and includes: The number of rules The number of current connections The number of translated packets on the inside and outside VLANs Information on missed translations

156

ExtremeWare 7.1.0 Software User Guide

Disabling NAT

To display NAT connection information, use the following command:

show nat connections

This command displays the current NAT connection table, including source IP/layer 4 port mappings from inside to outside.

Disabling NAT
To disable NAT, use the following command:
disable nat

ExtremeWare 7.1.0 Software User Guide

157

Network Address Translation (NAT)

158

ExtremeWare 7.1.0 Software User Guide

Server Load Balancing (SLB)

This chapter describes the following topics: Overview on page 159 SLB Components on page 160 SLB Traffic Types on page 163 Forwarding Modes on page 164 Load-Balancing Methods on page 169 Advanced SLB Application Example on page 170 Using Persistence on page 173 Using High Availability System Features on page 176 Health Checking on page 181 Flow Redirection on page 184

Overview
Server load balancing (SLB) transparently distributes client requests among several servers. The main use for SLB is for web hosting (using redundant servers to increase the performance and reliability of busy websites). You can use SLB to manage and balance traffic for client equipment such as web servers, cache servers, routers, and proxy servers. SLB is especially useful for e-commerce sites, Internet service providers, and managers of large intranets. Server load balancing (SLB), longest prefix matching (LPM), and destination-sensitive accounting (DSA) are mutually exclusive functions. None of these functions can be simultaneously enabled.

ExtremeWare 7.1.0 Software User Guide

159

Server Load Balancing (SLB)

A basic SLB application is shown in Figure 17. Figure 17: Basic SLB application

Clients

Servers

EW_055

All content must be duplicated on all physical servers for server load balancing. To configure SLB, perform the following basic steps: 1 Create pools and configure the load balancing method for each pool. 2 Add nodes to the pools. 3 Create virtual servers and select the forwarding mode for each virtual server. 4 Assign an SLB traffic type to the server and client VLANs. 5 Enable IP forwarding on the server and client VLANs. 6 Enable SLB.

SLB Components
Three components comprise an SLB system: Nodes Pools Virtual servers All three components are required for every SLB configuration.

Nodes
A node is an individual service on a physical server, and consists of an IP address and a port number. All nodes must have identical content. Nodes cannot belong to the same VLAN as the virtual servers they access.

160

ExtremeWare 7.1.0 Software User Guide

SLB Components

Pools
A pool is a group of nodes that are mapped to a corresponding virtual server. You can use pools to easily scale large networks with many nodes. Each pool contains its own load-balancing method. A pool must be associated with a virtual server to be used for load balancing. You must create pools before associating them with virtual servers, and must delete virtual servers before deleting their associated pools. You cannot delete pools that are still associated with a virtual server.

Virtual Servers
Virtual servers are the backbone of the SLB configuration. A virtual server is a virtual IP address that points to a group of servers. The switch then load balances those groups of servers (or other network equipment). Before you configure virtual servers, you need the following: The forwarding mode The name of the pool The virtual IP address The virtual port number Virtual servers cannot belong to the same VLAN as the nodes in the pool they reference. Do not configure a virtual server with the same IP address as a VLAN.

Using Standard or Wildcard Virtual Servers

Each virtual server is associated with a single pool, which can be a group of content servers, routers, or cache servers. You can configure two different types of virtual servers: Standard virtual servers A standard virtual server represents a site (such as a web site or an FTP site), and provides load balancing for content. Configure the virtual server IP address to be the same IP address as that of the site that the virtual server represents. Wildcard virtual servers A wildcard virtual server load balances transparent network devices such as routers or cache servers. Wildcard virtual servers use a special wildcard IP address (0.0.0.0), and require Transparent mode. NOTE For cache server applications, see Web Cache Redirection on page 185.

ExtremeWare 7.1.0 Software User Guide

161

Server Load Balancing (SLB)

Network Advertisement
Three modes are available for controlling network connectivity to virtual servers. The switch will automatically select a method based on the virtual server s subnet. Proxy ARP If the virtual server is a member of an existing subnet to which the switch is directly attached, the switch will respond to ARP requests on behalf of the virtual server. This allows you to implement server load balancing on a layer 2 network. The VLAN containing the servers is in a different subnet than the client VLANs subnet. The virtual server will appear to be a member of the client subnet. Host-Route If the virtual server is not a member of an existing subnet to which the switch is directly attached, the switch will add a host-route entry to the routing table. In this situation, all clients require a routed path (to the virtual server) that points to the switchs IP address on the client VLAN. Subnet-Route If the virtual server is separated from the switch by a router, the switch propagates the subnet containing the virtual server. You must create a loopback VLAN with the virtual server as a member of the loopback VLANs subnet. When you enable the routing protocol to advertise the entire subnet to directly connected routers, a single entry is created in the routing table for each subnet advertised. For example, the following command enables RIP to advertise routes to all directly connected routers with a cost of 1:
enable rip export direct cost 1

When you enable the routing protocol to advertise specific virtual servers, an entry is created in the routing table for each virtual server you advertise. For example, the following command enables OSPF to advertise a specific virtual server with a cost of 1:
enable ospf export vip cost 1

This command exports the virtual servers to the entire network. Extreme Networks recommends this method to advertise virtual servers.

Node, Pool, and Virtual Server Relationships

Nodes, pools, and virtual servers have the following relationships: Nodes can belong to multiple pools Pools can contain multiple nodes Pools can be associated with multiple virtual servers Virtual servers can be associated with only a single pool

162

ExtremeWare 7.1.0 Software User Guide

SLB Traffic Types

Figure 18 illustrates the relationships of these basic components. Figure 18: Basic SLB components

Pool
load balancing method

Virtual Server
forwarding mode

Virtual Server
forwarding mode

Node Node Node Node Node Node Node Node

Pool
load balancing method

Node Node

Node

Node

Node Node Node Node Node Node Node Node

Virtual Server
forwarding mode
Node Node

Virtual Server
forwarding mode

Pool
load balancing method

EW_069

SLB Traffic Types

SLB traffic must cross a routing boundary for SLB to work. To ensure that traffic crosses a routing boundary, assign clients and servers to separate VLANs. You must specify an SLB traffic type for each VLAN. The four SLB traffic types are: NoneDisables SLB on the VLAN. This is the default setting. ClientSpecifies that the VLAN contains clients, and originates requests for virtual servers.

ExtremeWare 7.1.0 Software User Guide

163

Server Load Balancing (SLB)

ServerSpecifies that the VLAN contains nodes, and receives requests for virtual servers. BothSpecifies that the VLAN contains both clients and nodes. Clients in this VLAN can only access virtual servers whose nodes are outside this VLAN. NOTE You must enable IP forwarding on each VLAN involved in SLB. You can assign the same SLB traffic type to as many different VLANs as necessary, up to the number of VLANs supported by the switch.

Forwarding Modes
The forwarding mode is the method the switch uses to forward traffic to the virtual servers. The forwarding mode determines what happens to the packets as they travel through the switch. The switch supports the following forwarding modes: Transparent Translation Port Translation GoGo Table 23 summarizes the features supported by each forwarding mode. Table 23: Forwarding Mode Feature Summary
Transparent Performance Load sharing algorithms Persistence Health checking Translation Port Translation CPU-based in both directions Round-robin, Ratio, Priority, Least Connections IPSA + Mask, IP list Layer 3, 4, and 7 GoGo Hardware-based in both directions Round-robin (hash)

Hardware-based from CPU-based in both server-to-client directions Round-robin, Ratio, Priority, Least Connections IPSA + Mask, IP list Layer 3, 4, and 7 Round-robin, Ratio, Priority, Least Connections IPSA + Mask, IP list Layer 3, 4, and 7

IPSA Layer 3, 4, and 7

Transparent Mode
In transparent mode, the switch does not modify IP addresses before forwarding traffic to the servers. You must configure all physical servers with the virtual IP address associated with the virtual server. This virtual IP address is the address seen by clients. You must configure the physical servers with this address as a loopback address. Configure the loopback address with the most specific subnet mask that your operating system supports. In transparent mode, you can directly attach servers or have a layer 2 switch between the SLB switch and the servers. You cannot have a router between the SLB switch and the servers. Use transparent mode when you want a balance between features and performance. Figure 19 shows transparent mode.

164

ExtremeWare 7.1.0 Software User Guide

Forwarding Modes

Figure 19: Transparent mode

Clients

Servers

192.168.200.1 192.168.200.2

SLB switch Two virtual servers configured VIP addresses: 192.168.201.2 port 80 192.168.201.2 port 443 representing MyWeb.com representing MySSL.com points to pool WebVip points to pool SSLVip

EW_052

In Figure 19, the switch is configured to respond to requests for the virtual server by forwarding them to the load-balanced servers. The servers are configured as follows: The interface for server 1 is 192.168.200.1. The interface for server 2 is 192.168.200.2. The loopback address on the servers is 192.168.201.1 (virtual server). The service is configured to use the appropriate address and port, as specified in the switch configuration. Use the following commands to configure the VLANs and the switch IP addresses and subnets:
create vlan srvr create vlan clnt create vlan vips configure srvr ipaddress 192.168.200.10 /24 configure clnt ipaddress 10.1.1.1 /24 configure vips ipaddress 192.168.201.1 /24 configure srvr add port 29-32 configure client add port 1-4 enable ipforwarding

Use the following commands to create a round-robin pool (MyWeb) and add nodes to the new pool.
create slb pool MyWeb lb-method round configure slb pool MyWeb add 192.168.200.1:80 configure slb pool MyWeb add 192.168.200.2:80

Use the following command to create a transparent mode virtual server for the website and assign MyWeb to it:
create slb vip WebVip pool MyWeb mode transparent 192.168.201.2:80

ExtremeWare 7.1.0 Software User Guide

165

Server Load Balancing (SLB)

Use the following commands to create a round-robin pool, MySSL and add nodes to the new pool.
create slb pool MySSL lb-method round-robin configure slb pool MySSL add 192.168.200.1:443 configure slb pool MySSL add 192.168.200.2:443

Use the following command to create a transparent mode virtual server for the website and assign MySSL to it.
create slb vip SSLVip pool MySSL mode transparent 192.168.201.2:443

Use the following commands to enable SLB, configure the server VLAN to act as the server side, and configure the client VLAN to act as the client side:
enable slb configure vlan srvr slb-type server configure vlan clnt slb-type client

You must configure a loopback address for each IP address to which the server will respond.

Translation Mode
In translation mode, the switch translates the IP address to that of the server to be balanced. You do not need to configure a loopback address for translation mode. In translation mode, you can directly attach servers or have a layer 2 switch between the SLB switch and the servers. You cannot have a router between the SLB switch and the servers. Use translation mode when you cannot have a loopback address. Figure 20 shows translation mode. Figure 20: Translation Mode

Clients

Servers

192.168.200.1 192.168.200.2

SLB switch 2 virtual servers configured VIP addresses: 192.168.201.2 port 80 192.168.201.2 port 443 representing MyWeb.com representing MySSL.com points to pool WebVip points to pool SSLVip

EW_053

In Figure 20, the switch is configured to respond to requests for the virtual server by translating them and forwarding them to the load balanced servers. No additional server configuration is needed.

166

ExtremeWare 7.1.0 Software User Guide

Forwarding Modes

Use the following commands to configure the VLANs and the switch IP addresses and subnets:
create vlan srvr create vlan clnt create vlan vips configure srvr ipaddress 192.168.200.10 /24 configure clnt ipaddress 10.1.1.1 /24 configure vips ipaddress 192.168.201.1 /24 configure srvr add port 29-32 configure client add port 1-4 enable ipforwarding

Use the following commands to create a round-robin pool, MyWeb, and add nodes to the new pool:
create slb pool MyWeb lb-method round configure slb pool MyWeb add 192.168.200.1:80 configure slb pool MyWeb add 192.168.200.2:80

Use the following command to create a translation mode virtual server for the website and assign MyWeb to it:
create slb vip WebVip pool MyWeb mode translation 192.168.201.2:80

Use the following commands to create a round-robin pool, MySSL, and add nodes to the new pool:
create slb pool MySSL lb-method round configure slb pool MySSL add 192.168.200.1:443 configure slb pool MySSL add 192.168.200.2:443

Use the following command to create a translation mode virtual server for the website and assign MySSL to it:
create slb vip SSLVip pool MySSL mode translation 192.168.201.2:443

Use the following commands to enable SLB, configure the server VLAN to act as the server side, and configure the client VLAN to act as the client side:
enable slb configure vlan srvr slb-type server configure vlan clnt slb-type client

Port Translation Mode

Port translation mode is similar to translation mode, except that the layer 4 port on the virtual server can be different from the layer 4 port on the nodes. The switch translates the IP address and port address to that of the severs to be balanced. In port translation mode, you can directly attach servers or have a layer 2 switch between the SLB switch and the servers. You cannot have a router between the SLB switch and the servers. Use port translation mode when you must translate layer 4 port numbers in addition to translating IP addresses.

ExtremeWare 7.1.0 Software User Guide

167

Server Load Balancing (SLB)

GoGo Mode
GoGo mode is a line rate method of server load balancing that forwards traffic without changing packet content. You must directly attach servers to the SLB switch in GoGo mode. The optimal configuration is groups of 2, 4, or 8 servers. Because you must directly attach servers, you do not need to configure nodes, pools, or virtual servers. Instead, you configure all servers with the same MAC and IP addresses. Clients then see the group of servers as a single server, much like port-based load sharing. As in port-based load sharing, the first port in the GoGo mode group is designated the master logical port. Use this port to represent the entire GoGo mode group when configuring health checks or VLAN membership. In GoGo mode, the load balancing method is fixed, based on a hashing of the client IP address. GoGo mode persistence is based on source IP information: a given source address will map to one, and only one, physical server. Use GoGo mode when you require performance without any traffic management features. Figure 21 shows GoGo mode. Figure 21: GoGo mode

Server 1 192.168.200.2 MAC 00-00-00-CO-FF-EE

Clients
Server 4 192.168.200.2 MAC 00-00-00-CO-FF-EE Server 3 192.168.200.2 MAC 00-00-00-CO-FF-EE

Server 2 192.168.200.2 MAC 00-00-00-CO-FF-EE

EW_040

In Figure 21, the switch is configured to balance all traffic sent to the virtual server based on the client IP address. The servers are configured as follows: All servers have the same MAC address. All servers have the same IP address. All servers have the same content. To configure the switch as indicated in the example, use the following commands:
create vlan server create vlan client configure server ipaddress 192.168.200.2 /24 configure client ipaddress 1.1.1.1 /24 configure server add port 29-32

168

ExtremeWare 7.1.0 Software User Guide

Load-Balancing Methods

configure client add port 1-4 enable slb gogo 29 grouping 29-32 enable ipforwarding

In this example, port 29 is designated the master port. GoGo mode requires you to place clients and servers into separate VLANs.

Load-Balancing Methods
Load-balancing methods are algorithms that determine which node receives a connection hosted by a particular virtual server. The forwarding mode determines how the switch forwards traffic; the load-balancing method determines where the switch forwards traffic. Individual load-balancing methods take into account dynamic factors such as current connection count. Because each application of SLB is unique, node performance depends on a number of different factors. We recommend that you experiment with different load-balancing methods and choose the one that offers the best performance in your particular environment. The switch supports the following load balancing methods: Round-robin Ratio Least connections Priority

Round-Robin
Round robin passes each new connection request to the next server in line. Because round robin is simple and predictable, it is the default load-balancing method. Use round-robin if the equipment that you are load balancing is roughly equal in processing speed and memory.

Ratio
Ratio distributes connections among servers according to ratio weights that you set. The number of connections that each server receives is proportionate to the ratio weight you defined for each server. Use ratio if the equipment that you are load balancing varies significantly in processing speed and memory. For example, if you have one new, high-speed server and two older servers, you can set the ratio so that the high-speed server receives twice as many connections as either of the two older servers. A ratio of 2 results in twice as much traffic as a ratio of 1. If all nodes use the same weight, connections are distributed equally among the nodes. The default ratio is 1.

ExtremeWare 7.1.0 Software User Guide

169

Server Load Balancing (SLB)

Least Connections
Least connections method passes a new connection to the node having the least number of active sessions. The number of active sessions includes only those sessions occurring within the same virtual server. Use least connections when the equipment that you are load balancing has similar capabilities. Because least connections requires more processing, it works best with small pools (under 25 nodes) when you require intelligent distribution.

Priority
Priority is a variant of round-robin designed to provide redundant standby nodes within a pool. When you add a node to a pool, you can assign a priority level ranging from 1 - 65535, with a higher number indicating a higher priority. In priority, the switch uses round-robin to distribute traffic among the active nodes with the highest priority. If all nodes at that priority level become inactive or reach a session limit maximum, all new sessions are directed to the nodes at the next lowest priority. The switch monitors the status of the inactive nodes. As each node becomes active, the switch redistributes traffic according to the priorities. For example, in a pool with six nodes divided evenly into two priority levels (2 and 1), all sessions are evenly distributed to the priority 2 nodes. If one of the priority 2 nodes becomes inactive, all traffic is assigned to the remaining priority 2 nodes. If all of the priority 2 nodes become inactive, all sessions are directed to the priority 1 nodes. If one of the level 2 nodes becomes active, all new sessions are assigned to it. Use priority when you want a set of servers held in reserve, as a back-up pool.

Advanced SLB Application Example

The advanced features described in this section are: Persistence High availability 3DNS support Flow redirection Health checking The advanced SLB application example builds upon the basic SLB application example. The advanced concepts included in this example are: Multiple pools. Multiple virtual servers. Multiple balancing algorithms. Multiple types of health checking. Figure 22 is an example of an advanced SLB application.

170

ExtremeWare 7.1.0 Software User Guide

Advanced SLB Application Example

Figure 22: Advanced SLB configuration

"FTP1" Least Connections 192.168.201.2 port 20 (ftpD) 192.168.201.2 port 21 (ftpC) Layer 4 health checking

Clients
"Site1" Round Robin 192.168.201.1 port 80 (MyWeb) Layer 4 health checking 192.168.201.1 port 443 (MySSL) Server2 Server1 192.168.200.3 192.168.200.4

Server1 Server2 192.168.200.2 192.168.200.1

Server pools

"Site3" Round Robin 192.168.201.4 port 80 (MyWeb3) Layer 3 health checking 192.168.201.4 port 443 (MySSL3) Layer 3 health checking

"Site2" Round Robin 192.168.201.3 port 80 (MyWeb2) Layer 7 health checking 192.168.201.3 port 443 (MySSL2)

Server1 192.168.200.7

Server3 192.168.200.9

Server2 192.168.200.8 Server1 Server2 192.168.200.6 192.168.200.5 Server4 192.168.200.10 Server5 192.168.200.11
EW_051

To create the VLAN from which outside connections will come, use the following commands:
create vlan outside configure vlan outside ipaddress 172.16.0.1 /16 configure vlan outside add ports 1-8

To create is the virtual IP VLAN, use the following commands:

create vlan sites configure vlan sites ipaddress 192.168.201.254 /24

All virtual servers will use this subnet. There are no ports associated with this VLAN. Use the following commands to create the VLAN servers and enable IP forwarding:
create vlan servers configure vlan servers ipaddress 192.168.200.254 /24 configure vlan servers add ports 9-16 enable ipforwarding

ExtremeWare 7.1.0 Software User Guide

171

Server Load Balancing (SLB)

Use the following series of commands to create a web site. The site is defined as having two servers: 192.168.200.1 and 192.168.200.2, each with two services (HTTP and SSL). Two virtual servers point at the appropriate pools. The load-balancing method is round-robin. Both virtual servers use the same IP address; the difference is the port number. Finally, port checking is enabled to ensure fault tolerance on each of the servers.
create slb pool site1web configure slb site1 add 192.168.200.1:80 configure slb site1 add 192.168.200.2:80 create slb pool site1ssl configure slb site1 add 192.168.200.1:443 configure slb site1 add 192.168.200.2:443 create slb vip myweb pool site1web mode transparent 192.168.201.1:80 create slb vip myssl pool site1ssl mode transparent 192.168.201.1:443 enable slb node 192.168.200.1:80 tcp-port-check enable slb node 192.168.200.2:80 tcp-port-check enable slb node 192.168.200.1:443 tcp-port-check enable slb node 192.168.200.2:443 tcp-port-check

Use the following series of commands to create a second web site. This site is similar to the first site, except that content checking is enabled on this site.
create slb pool site2web configure slb site2web add 192.168.200.5:80 configure slb site2web add 192.168.200.6:80 create slb pool site2ssl configure slb site2ssl add 192.168.200.5:443 configure slb site2ssl add 192.168.200.6:443 create slb vip myweb2 pool site2web mode transparent 192.168.201.3:80 create slb vip myssl2 pool site2ssl mode transparent 192.168.201.3:443 enable slb vip myweb2 service-check configure slb vip myweb2 service-check http url /testpage.htm match-string test successful

Use the following series of commands to create a third web site. This example has one pool with a wildcard port. The wildcard port allows any port sent to it by the virtual server. All five servers respond to requests on both port 80 and port 443.
create slb pool site3web configure slb site3web add configure slb site3web add configure slb site3web add configure slb site3web add configure slb site3web add create slb vip myweb3 pool create slb vip myssl3 pool 192.168.200.7:0 192.168.200.8:0 192.168.200.9:0 192.168.200.10:0 192.168.200.11:0 site3web mode transparent 192.168.201.4:80 site3web mode transparent 192.168.201.4:443

172

ExtremeWare 7.1.0 Software User Guide

Using Persistence

Use the following series of commands to create an FTP site. The site has two servers: 192.168.200.3 and 192.168.200.4. The servers provide only FTP service. The two different virtual servers and port numbers refer to the control and data channels used by the FTP service. Two virtual servers point at the appropriate pools. The load-balancing method is round-robin. Layer 7 health checking is enabled for the ftpc virtual server.
create slb pool ftp1c configure slb ftp1c add 192.168.200.3:21 configure slb ftp1c add 192.168.200.4:21 create slb pool ftp1d configure slb ftp1d add 192.168.200.3:20 configure slb ftp1d add 192.168.200.4:20 create slb vip ftpc pool ftp1c mode transparent 192.168.201.2:21 create slb vip ftpd pool ftp1d mode transparent 192.168.201.2:20 enable slb vip ftpc service-check configure slb vip ftpc service-check ftp user test password testpass

Finally, enable SLB and configure the VLANs to be either client or server, using the following commands.
enable slb configure vlan outside slb-type client configure vlan servers slb-type server

Using Persistence
Persistence ensures that subsequent connections from the same client attach to the same server. To configure persistence, you select: persistence method persistence level persistence type Persistence is not affected by the load-balancing method unless you select GoGo mode, where the persistence is fixed, as described on page 168.

Persistence Methods
Persistence methods determine how the persistence table times-out entries. The persistence methods are: Per-session Per-packet

Per-Session Persistence
Per-session persistence creates a persistence entry when the first packet arrives from a client with the time-out value configured for the virtual server. The entry is removed after the time-out period. The entry is not refreshed. Per-session is the default persistence method. Use per-session persistence when you want the smallest impact on performance and you can accurately gauge your total connection time.

ExtremeWare 7.1.0 Software User Guide

173

Server Load Balancing (SLB)

Per-Packet Persistence
Per-packet persistence creates a persistence entry when the first packet arrives and refreshes that entry each time a new packet arrives. Thus, the entry remains as long as new packets continue to arrive. Use per-packet persistence when you want to sacrifice a small amount of performance in return for a time-out period based on connection idle time instead of total connection time.

Persistence Levels
Persistence levels determine how the persistence entries affect multiple virtual servers. Use persistence levels if you have servers that provide multiple services to a single client (such as, HTTP and SSL). To use persistence levels, your virtual servers must contain the same physical servers. The persistence levels are as follows: Same-VIP-same-port Same-VIP-any-port Any-VIP

Same-VIP-Same-Port Persistence
Same-VIP-same-port matches a new client request to a persistence entry only if the destination is the same virtual server and same port as the original client request. Same-VIP-same-port is the default persistence method. Use same-VIP-same-port persistence to ensure that connections from a client are only persistent on the specific virtual server that is connecting to that client.

Same-VIP-Any-Port Persistence
Same-VIP-any-port persistence directs client requests to the same virtual server even if the port is different. Use same-VIP-any-port persistence to ensure that connections from a client are persistent on the virtual server for all layer 4 services offered on that particular virtual server. For example, if you use HTTP (port 80) to build a shopping cart, then need to use SSL (port 443) for the credit card transaction at the end, use same-VIP-any-port persistence to preserve the client session. If you have virtual servers with the same IP address but a different port, you must configure associated pools with identical nodes that can service requests on either port.

Any-VIP Persistence
Any-VIP persistence directs all connections from a client to the same virtual server regardless of the destination. Use any-VIP persistence to ensure that connections from a client always go to the same server no matter what layer 4 service they connect to. When you use any-VIP persistence, you must ensure that all servers have the same content for all services.

174

ExtremeWare 7.1.0 Software User Guide

Using Persistence

Persistence Types
The switch supports the following types of persistence: Client persistence Proxy client persistence Sticky persistence

Client Persistence
Client persistence provides a persist mask feature. You can define a range of IP addresses that map to a persistent connection. Any client whose source IP address falls within the range is considered a match for the entry. Use client persistence to ensure that transactions, from your defined range of IP addresses, that span multiple TCP sessions are always connected to the same virtual servers. For example, if you assume that a single client uses multiple sessions to fill a shopping cart, you can force all traffic from the same range of IP addresses (which you assume to be the same client) to connect to the same virtual server.

Proxy Client Persistence

Some networks translate addresses internally with an array of proxy servers. Proxy client persistence allows the switch to maintain connections for clients in these types of networks. You can define ranges of IP addresses that map to a persistent connection. Any client whose source IP address falls within one of the ranges is considered a match for the entry. You must add every range of possible source IP addresses. Use proxy client persistence to provide persistence for users who are behind proxy servers that change the source IP address of client requests from session to session.

Sticky Persistence
Sticky persistence is available only on wildcard virtual servers and is especially useful for cache servers. Sticky persistence tracks destination IP addresses. When a client attempts to connect to a destination IP address, the switch directs the client to the same cache server previously used for that destination IP address. This helps you reduce the amount of duplicated content on cache servers in your network. Use sticky persistence to provide persistence based on destination IP address. Sticky persistence is especially useful when you load balance caching proxy servers. A caching proxy server intercepts web requests and returns a cached web page (if that page is available). You can improve the efficiency of cache proxy servers by sending similar requests to the same server. Sticky persistence can cache a given web page on one proxy server instead of on every proxy server. This saves the other servers from duplicating the content.

NOTE For additional cache server applications, see Web Cache Redirection on page 185.

ExtremeWare 7.1.0 Software User Guide

175

Server Load Balancing (SLB)

Using High Availability System Features

The switch supports several advanced redundant system features. Advanced redundant system features provide additional assurance that your content remains available if a switch experiences a problem. The advanced redundant system options include: SLB with ESRP Active-active operation

Server Load Balancing with ESRP

You can use ESRP to make SLB, along with the layer 2 and layer 3 services of the switch, redundant. SLB with ESRP allows single- or dual-attached servers to have redundant gateway services and very fast recovery from a fault. When you enable ESRP, all servers can be online simultaneously, and recovery from a switch failure occurs in less than 8 seconds. Figure 23 shows SLB enabled using ESRP and dual-attached servers. Figure 23: SLB using ESRP and dual-homed servers

OSPF VLAN inside

ESRP and SLB VLAN server

Clients

Switch 1 (unit 1) 1.10.0.2/16 VIP site1 1.10.1.1 (unit 1) VIP site2 1.10.1.2 (unit 2)

Switch 1 1.205.0.1/16

Single-attached host
testpool Associated VIPs 1.10.1.1 port 80 (site1) 1.10.1.2 port 80 (site2)

VLAN outside 1.201.0.1/16

1.10.0.1/16
Server1 1.205.1.1/16

Switch 1 (unit 1) 1.10.0.3/16 VIP site1 1.10.1.1 (unit 1) VIP site2 1.10.1.2 (unit 2)

Switch 2 1.206.0.1/16

Server2 1.205.1.2/16

Single-attached host
EW_058

176

ExtremeWare 7.1.0 Software User Guide

Using High Availability System Features

Configuring the Switches for SLB and ESRP

To create the VLANs, use the following commands:
create vlan inside create vlan server

To connect the gateway to the VLAN inside, use the following commands:
configure inside ipaddress 1.10.0.2 /16 configure inside add port 31

To configure the servers to connect to the VLAN server on ports 1-4, and configure port 32 to connect to the other ESRP switch, use the following commands:
configure server ipaddress 1.205.0.1 /16 configure server add port 1-4, 32

To enable IP forwarding, create a server pool called testpool, and add four servers to it using TCP port 80, use the following commands:
enable ipforwarding create slb pool testpool configure slb pool testpool configure slb pool testpool configure slb pool testpool configure slb pool testpool

add add add add

1.205.1.1:80 1.205.1.2:80 1.205.1.3:80 1.205.1.4:80

To create SLB virtual server addresses for the two websites (site1 and site2) and associate the server pool testpool with it, use the following commands:
create slb vip site1 pool testpool mode transparent 1.10.1.1:80 create slb vip site2 pool testpool mode transparent 1.10.1.2:80

To enable SLB and configure it for the appropriate VLANs (client connections enter from the VLAN inside), use the following commands:
enable slb configure inside slb client configure server slb server

To enable OSPF, use the following command:

enable ospf

To enable ESRP on the VLAN server and configure the ESRP direct-attached hosts mode to allow the proper failover of services, use the following commands:
enable esrp server configure esrp port-mode host ports 1-4, 32

the interconnection between the switches is also configured as a host port. To configure SLB to use ESRP, use the following command:
configure slb esrp server add unit 1

ExtremeWare 7.1.0 Software User Guide

177

Server Load Balancing (SLB)

Note the following about the configurations for the switches running SLB and ESRP: You must configure all switch ports connected directly to the servers as ESRP host ports. You must configure the link between the two switches as an ESRP host port. The configuration uses transparent mode and HTTP services, but can be configured to support any of the currently supported load-balancing protocols. Both switches are configured as unit 1. The SLB and ESRP port configurations are identical on both switches.

Web-Server Configuration
The services must match those configured on the switch; for example, HTTP services configured at TCP port 7080 on the switch require the servers to allow connections at port 7080. You must ensure that the SLB configuration is valid before trying to transfer the configuration to an ESRP/SLB configuration. The two types of ESRP hosts that you can connect to the switches are single-attached hosts and dual-attached hosts. Single-attached hosts provide no server link redundancy, but allow hosts to be connected to the same VLAN as the web servers. Dual-attached hosts allow for redundant NICs in the servers, as well as connections to the switch. When configured as dual-attached hosts, the servers are supported fully by the ESRP redundant gateway services.

NOTE For information on specific NIC card configurations, please contact your NIC vendor.

Active-Active Operation
Active-active operation is a redundant configuration of two switches. If one switch fails, the second switch takes over the SLB function. By preparing a redundant switch for the possibility of failover, you provide reliability and availability. To create an active-active configuration, configure redundant switches with identical SLB configurations, except for the failover parameters. Active-active operation uses a gateway ping-check to determine if the active SLB switch has network connectivity. If the specified IP address is unreachable for a specified duration, the gateway ping-check triggers a failover to the redundant switch. NOTE When you configure the gateway ping check, specify the IP address of a device other than the redundant SLB switch.

Configuring Active-Active Operation

Using active-active redundant SLB, you configure one switch as unit 1 and the other switch as unit 2. You then assign the virtual servers either to unit 1 or to unit 2 (unit 1 is the default). When both switches are active, each switch performs SLB only for the virtual servers assigned to it. If a switch fails, the remaining switch performs SLB for the virtual servers assigned to the failed switch.

178

ExtremeWare 7.1.0 Software User Guide

Using High Availability System Features

Use the following command to assign the unit number:

configure slb failover unit [1 | 2] remote-ip <ipaddress> local-ip <ipaddress>:<L4Port> {alive-frequency <seconds> timeout <seconds>} {dead-frequency <seconds>}

The remote-ip specifies the IP address of the redundant SLB switch. The local-ip specifies the IP address of the switch you are configuring. You must assign virtual servers with the same virtual IP address to the same unit.

Sample Active-Active Configuration

Figure 24 is an example of an active-active failover configuration. Figure 24: Active-active configuration
VLAN inside VLAN server
testpool Associated VIPs 1.10.1.1 port 80 (site1) 1.10.1.2 port 80 (site2) Switch 1 1.205.0.1/16 Server1 1.205.1.1/16 VLAN outside 1.201.0.1/16 Server2 1.205.1.2/16

Clients

Switch 1 (unit 1) 1.10.0.2/16 VIP site1 1.10.1.1 (unit 1) VIP site2 1.10.1.2 (unit 2)

1.10.0.1/16

Server pools
testpool Associated VIPs 1.10.1.1 port 80 (site1) 1.10.1.2 port 80 (site2)

Switch 2 (unit 2) 1.10.0.3/16 VIP site1 1.10.1.1 (unit 1) VIP site2 1.10.1.2 (unit 2)

Switch 2 1.206.0.1/16

Server1 1.206.1.1/16 Server2 1.206.1.2/16

EW_050

To configure this example on the first switch, use the following commands:
create vlan inside create vlan server configure vlan inside ipaddress 1.10.0.2 /16 configure vlan inside add port 31

ExtremeWare 7.1.0 Software User Guide

179

Server Load Balancing (SLB)

configure vlan server ipaddress 1.205.0.1 /16 configure vlan server add port 29-30 enable ipforwarding create slb pool testpool configure slb pool testpool add 1.205.1.1:80 configure slb pool testpool add 1.205.1.2:80 create slb vip site1 pool testpool mode transparent 1.10.1.1:80 create slb vip site2 pool testpool mode transparent 1.10.1.2:80 enable slb configure vlan inside slb-type client configure vlan server slb-type server configure slb failover unit 1 remote 1.10.0.3 local 1.10.0.2:1028 enable slb failover enable slb failover ping configure slb vip site1 unit 1 configure slb vip site2 unit 2 configure slb fail ping-check 1.10.0.1 freq 1

To configure this example on the second switch, use the following commands:
create vlan inside create vlan server configure vlan inside configure vlan inside configure vlan server configure vlan server enable ipforwarding create slb pool testpool configure slb pool testpool add 1.206.1.1:80 configure slb pool testpool add 1.206.1.2:80 create slb vip site1 pool testpool mode transparent 1.10.1.1:80 create slb vip site2 pool testpool mode transparent 1.10.1.2:80 enable slb configure vlan inside slb-type client configure vlan server slb-type server configure slb failover unit 2 remote 1.10.0.2 local 1.10.0.3:1028 enable slb failover enable slb fail ping configure slb vip site1 unit 1 configure slb vip site2 unit 2 configure slb fail ping-check 1.10.0.1 freq 1

ipaddress 1.10.0.3 /16 add port 31 ipaddress 1.206.0.1 /16 add port 29-30

180

ExtremeWare 7.1.0 Software User Guide

Health Checking

The differences between the configurations of these two switches are the IP addresses and the designation of the first switch as unit 1 of the active-active configuration. If you use this configuration with only one virtual server, you have an active switch and a standby switch, because only one switch is actively performing SLB. This configuration is called active-standby.

Active-Active Configuration Notes

Note the following about active-active configurations: In the design shown in Figure 24, only the servers directly connected to the switch that is actively servicing the virtual server are used in the load-balancing scheme. Without ESRP, you must have another switch interconnecting all the servers. One switch is designated as unit 1 and the other is unit 2. This designation determines which virtual servers are active on each switch in the failover pair. In this configuration, site1 is serviced by switch 1 and has two servers that respond to client requests. Site2 is be serviced by the remote switch (switch 2) and has two other servers that respond to client requests. If you enable ping-check, do not direct it at the remote switch. The ping-check works best when directed at a gateway to ensure that a path out of the network is available to the switch. The configuration uses transparent mode and HTTP services, but can be configured to support any of the currently supported load balancing protocols. The configurations for the switches are identical, with the exception of the failover command. The remote switch is set to unit 2, and the remote/local IP addresses are reversed to accurately describe the network.

Using Manual Fail-Back

With manual fail-back, fail-back occurs only when you enter the fail-back command. In an active-active configuration, fail-back occurs automatically. If the minor disruption of fail-back makes automatic fail-back undesirable, you can enable manual fail-back.

Health Checking
Health checking allows you to actively poll nodes to determine their health. The switch makes new connections only if the virtual server and node are both enabled and passing health checks. The switch considers a virtual server or node active unless a health check fails. If a health check fails, the switch considers the virtual server or node inactive. A virtual server or node is also considered inactive if it is disabled and has zero active connections. If it is inactive for this reason, the switch stops ping-checks and port-checks on the virtual server or node to conserve system resources. The switch resumes ping checks and port checks when you enable the virtual server or node. The switch does not establish new connections with an inactive node until that node passes all configured health checks. If a health check fails and you have enabled the ign-reset parameter on an associated virtual server, the switch closes all existing connections for the virtual server by sending a TCP reset to the client and node.

ExtremeWare 7.1.0 Software User Guide

181

Server Load Balancing (SLB)

The switch supports three types of health checking: Ping-check Port-check Service-check The switch also supports 3DNS health checking.

Ping-Check
Ping-check operates at layer 3 and is the default health check. The switch sends an ICMP ping to the configured server or next hop. The default ping frequency is 10 seconds and the default time-out is 30 seconds (three pings). If the node does not respond within 30 seconds, it is considered down. If a server is configured not to respond to ICMP echo requests, the server will be marked down after the first ping check interval. Ping check is the only health check that will accept a wildcard as the IP port.

TCP-Port-Check
TCP-port-check operates at layer 4 and tests the physical node. The default frequency is 30 seconds and the default time-out is 90 seconds. If the node does not respond within 90 seconds, it is considered down. You can use TCP-port-checking to determine if a TCP service, such as httpd, is available. If a TCP-port-check fails, the IP/port combination is considered unavailable.

Service-Check
Service-check operates at layer 7 and is an application-dependent check defined on a virtual server. The switch performs a service-check on each node in the pool. The default frequency is 60 seconds and the default time-out is 180 seconds. Table 24 describes the service-check parameters. Table 24: Service-Check Parameters
Service HTTP FTP Telnet SMTP NNTP POP3 Attribute URL Match-string Userid Password Userid Password Dns-domain Newsgroup Userid Password Global Default Value / Any-content anonymous anonymous anonymous anonymous Same as the switch DNS domain. If no DNS domain is configured for the switch, the value is . ebusiness anonymous anonymous

If you do not specify the service-check parameters, the switch uses the global default values. You can configure the global default values. For HTTP, you can specify both the URL to be retrieved, and a match-string, such as Welcome. If the switch finds the match-string in the first 1000 bytes of the retrieved URL, the service-check passes.

182

ExtremeWare 7.1.0 Software User Guide

Health Checking

A match-string specified as any-content matches any retrieved text. Extreme Networks recommends that you create a text file that contains a single word, such as ok. The FTP, Telnet, and POP3 service-checks establish a connection between the switch and the next hop. Service-check logs on and off using the specified userid and password. For SMTP, service-check identifies the switch by providing the DNS domain you configure. Extreme Networks recommends that you specify a DNS domain that is used only for identification. The NNTP service-check connects to the node, logs in, and attaches to the newsgroup specified. You configure service-checks for each virtual server, and nodes can be members of multiple virtual servers. Therefore, because each node can have multiple service-checks, some service-checks can fail while others pass. So to accept a new connection for a virtual server, a node must have passed the service-check configured for that virtual server. When showing detailed virtual server information, the status for individual nodes is shown with respect to that virtual server.

3DNS Health Checking

3DNS is a global load balancing and site redundancy tool. Additional information concerning individual server health and performance is gathered by 3DNS when using Transparent or Translational modes. When you enable SLB, the switch reports health status to 3DNS using the iQuery protocol from F5 Networks. The health status of the nodes within the server farm is based on layer 3, layer 4, layer 7, or external health check mechanisms. To enable 3DNS:
enable slb 3dns iquery-client

To see what 3DNS devices are currently communicating with the SLB enabled switch:
show slb 3dns members

To disable responses to 3DNS queries:

disable slb 3dns iquery-client

The switch responds to directed queries from 3DNS. To direct 3DNS queries to the switch, add a Big/IP device to the 3DNS configuration. Encrypted communications with 3DNS are currently not supported.

Maintenance Mode
You can put a node or virtual server into maintenance mode by disabling the node or virtual server. In maintenance mode, existing connections remain active, but no new connections are permitted. The existing connections are either closed by the client and server or are aged out if idle for more than 600 seconds.

Health Checking in GoGo Mode

GoGo mode does not use nodes, pools, or virtual servers. Therefore, to configure health checking when using GoGo mode, you must use the GoGo mode health checking commands.

ExtremeWare 7.1.0 Software User Guide

183

Server Load Balancing (SLB)

Flow Redirection
Flow redirection overrides routing decisions to transparently redirect client requests to a target device (or group of devices). Unlike SLB, you do not duplicate content on the target device(s). Flow redirection traffic must come from an i-series switch running ExtremeWare 6.1 (or later). The switch can only redirect traffic that crosses a VLAN boundary within the switch, because flow redirection operates at layer 3. If the clients and servers belong to the same subnet as the switch, use the proxy ARP feature with minimal configuration changes to clients or servers. Flow redirection automatically includes health checking. You can configure the type of health check, but you cannot disable flow redirection health checking. Flow redirection examines traffic and redirects it based on the following criteria, in order of priority: 1 Destination IP address and mask 2 Layer 4 port 3 Source IP address and mask Multiple flow redirection rules can overlap. In these cases, the most specific redirection rule that satisfies the criteria takes precedence. In general, the following rules apply: If a flow with a better matching mask on an IP address satisfies the content of a packet, that flow will be observed. If one flow redirection rule contains any as a layer 4 protocol and a second flow redirection rule contains explicit layer 4 port information, the second takes precedence if the packet contains matching layer 4 information. If one flow has a better match on source information and a second flow has better match on destination information then the rule with the match on the destination information is selected. For example, in the following 2 cases, the rule with the best match (using the above criteria) is selected. Table 25: Flow rule example A
Rule # A1 A2 Destination IP Address 192.0.0.0/8 192.168.0.0/16 Destination Port 80 ANY Source IP Address ANY ANY Priority Selection 1 2

In example A, rule A1 is the best match as it contains an explicit destination port, even though rule A2 has a more specific destination IP address mask.

Table 26: Flow rule example B

Rule # B1 B2 B3 B4 Destination IP Address 192.168.2.0/24 192.168.0.0/16 192.168.2.0/24 192.168.2.0/24 Destination Port 80 ANY ANY 80 Source IP Address ANY 10.10.10.0/24 10.10.0.0/16 10.10.0.0/16 Priority Selection 2 4 3 1

184

ExtremeWare 7.1.0 Software User Guide

Flow Redirection

In example B, rule B4 is the best match as it contains an explicit destination port and a better match on the source IP address mask than rule B1.

NOTE Extreme Networks recommends that you use flow redirection and SLB on separate switches; do not use flow redirection and SLB on the same switch. If you must use SLB and flow redirection on the same switch, ensure that no overlapping layer 4 IP ports exist in the configuration. You must prevent logical loops of redirected traffic. You can use flow redirection for the following: Web cache redirection Policy-based routing

Web Cache Redirection

Web cache redirection operates at line rate to redirect traffic from the requested server to a web cache server. If the web cache server has a copy of the requested content, it sends the content to the client. If the web cache server does not have the requested content, it queries the server for the data, stores it locally, and sends a copy to the client. When you have web cache redirection enabled, clients connect exclusively to your web cache servers; clients never connect to the requested server. The switch automatically load-balances your cache servers based on the destination IP address of the requested content. Thus, subsequent requests for a destination IP address are redirected to the same web cache server, because that web cache server is most likely to contain the requested content. This load-balancing reduces the amount of content duplication on your web cache servers.

NOTE Ensure that the FDB time-out on the switch is higher than the IPARP time-out.

Web Cache Redirection Example

Figure 25 uses flow redirection to redirect Web traffic to cache servers. In this example, the clients and the cache devices are located on different networks. This is done by creating a different VLAN for the clients and cache devices.

ExtremeWare 7.1.0 Software User Guide

185

Server Load Balancing (SLB)

Figure 25: Web cache redirection example

Cache servers
1.10.1.1 1.10.1.2 1.10.1.3 1.10.1.4 1.10.1.5 1.10.1.6 1.10.1.7 1.10.1.8

Gateway to clients
1.12.0.1/16

Internet

EW_064

To configure the switch in this example, use the following commands:

create vlan client configure vlan client add port 1 configure vlan client ipaddress 1.12.0.1/16 create vlan cache configure vlan cache add port 2 configure vlan cache ipaddress 1.10.1.1/24 create vlan internet configure vlan internet add port 3 configure vlan internet ipaddress 1.11.1.1/16 enable ipforwarding create flow-redirect flow1 tcp destination 1.11.1.0/24 ip-port 80 source any configure configure configure configure configure configure configure flow1 flow1 flow1 flow1 flow1 flow1 flow1 add add add add add add add next-hop next-hop next-hop next-hop next-hop next-hop next-hop 1.10.1.2 1.10.1.3 1.10.1.4 1.10.1.5 1.10.1.6 1.10.1.7 1.10.1.8

186

ExtremeWare 7.1.0 Software User Guide

Flow Redirection

Policy-Based Routing
Policy based routing is an application of flow redirection that allows you to control routed traffic regardless of the routing protocol configured. For example, you can use policy-based routing to force SNMP traffic to follow a less efficient but more secure path. As with web cache redirection, policy-based routing examines traffic and redirects it based on the following criteria (in order of priority): 1 Destination IP address and mask 2 Layer 4 port 3 Source IP address and mask If the next-hop address is unavailable, the switch routes the traffic normally. You can define several rules; the precedence of rules is determined by the best match of the rule to the packet. If no rule is satisfied, no redirection occurs. If you define multiple next-hop addresses, traffic satisfying the rule is load-shared across the next hop addresses based on destination IP address. If next hop addresses do not respond to ICMP pings, the switch resumes normal routing. Policy-based routing has no impact on switch performance unless you use policy-based routing and SLB on the same switch.

ExtremeWare 7.1.0 Software User Guide

187

Server Load Balancing (SLB)

188

ExtremeWare 7.1.0 Software User Guide

10 Status Monitoring and Statistics

This chapter describes the following topics: Status Monitoring on page 189 Slot Diagnostics on page 190 Port Statistics on page 192 Port Errors on page 193 Port Monitoring Display Keys on page 194 System Temperature on page 194 System Health Checking on page 195 Setting the System Recovery Level on page 200 Event Management System/Logging on page 200 Configuring and Monitoring Flow Statistics on page 212 RMON on page 221 Viewing statistics on a regular basis allows you to see how well your network is performing. If you keep simple daily records, you will see trends emerging and notice problems arising before they cause major network faults. In this way, statistics can help you get the best out of your network.

Status Monitoring
The status monitoring facility provides information about the switch. This information may be useful for your technical support representative if you have a problem. ExtremeWare includes many show commands that display information about different switch functions and facilities. NOTE For more information about show commands for a specific ExtremeWare feature, see the appropriate chapter in this guide.

ExtremeWare 7.1.0 Software User Guide

189

Status Monitoring and Statistics

Slot Diagnostics
The BlackDiamond switch provides a facility for running normal or extended diagnostics on an I/O module or a Management Switch Fabric Module (MSM) without affecting the operation of the rest of the system. If you select to run the diagnostic routine on an I/O module, that module is taken off-line while the diagnostic test is performed. Traffic to and from the ports on the module are temporarily unavailable. Once the diagnostic test is completed, the I/O module is reset and becomes operational again. You can run normal or extended diagnostics on the slave MSM. The normal diagnostic routing is a short series of tests that do not test all the internal Application-Specific Integrated Circuit (ASIC) functions. The extended diagnostic routine tests coverage of all MSM components including the internal ASIC functions. The slave MSM is taken off-line while the diagnostic test is performed. It is reset and operational once the test is completed. If you want the diagnostic routine to run on the master MSM every time the system boots, use the following command:
configure diagnostics on

To turn off the diagnostic routine, use the following command:

configure diagnostics off

If you want the diagnostic routine to run one time (rather than with each system boot), use the following command:
run diagnostics [normal | extended] [<slot> | msm-a | msm-b]

where the following is true: normalTakes the switch fabric and ports offline, and performs a simple ASIC and packet loopback test on all ports. The test is completed in 30 seconds. CPU and out-of-band management ports are not tested in this mode. As a result, console and Telnet access from the management port is available during this routine. extendedTakes the switch fabric and ports offline, and performs extensive ASIC, ASIC-memory, and packet loopback tests. Extended diagnostic tests take a maximum of 15 minutes. The CPU is not tested. Console access is available during extended diagnostics. <slot>Specifies the slot number of an I/O module. Once the diagnostics test is complete, the system attempts to bring the I/O module back online. This parameter is applicable to the BlackDiamond switch, only. msm-a | msm-bSpecifies the slot letter of an MSM64i. If the master MSM is specified, the diagnostic routine is performed when the system reboots. Both switch fabric and management ports are taken offline during diagnostics. This parameter is applicable to the BlackDiamond switch, only.

Runtime Diagnostics (BlackDiamond Switches)

BlackDiamond switch runtime diagnostics perform a single test on a single I/O module. All error messages are logged. To perform diagnostics on an I/O module, use the following command:
run diagnostics [extended | normal] slot [<slot number> | msm-a | msm-b]

190

ExtremeWare 7.1.0 Software User Guide

Slot Diagnostics

Use the normal option when you want a fast (30 60 seconds) hardware status check. Use the extended option when you want a more thorough test. The extended option requires significantly more time to complete, depending on the number of ports on the blade. You can also execute packet memory scanning for all packet memory associated with the specified I/O slot on a BlackDiamond 6804, 6808, or 6816 switches, using the following command:
run diagnostics packet-memory slot <slot number>

The packet memory diagnostic scans the specified blade to detect single bit-related memory defects and their associated buffer locations. If packet memory defects are detected, their locations are recorded in the blades EEPROM. Up to eight occurrences can be recorded. If a defect was found during the scan process, the card is reset, the defective buffer is mapped out from further use, and the I/O card is returned to the operational state. If more than eight defects are detected, or if the defects cannot be mapped out, the card is treated as a failed card and left offline. The card should then be returned through the RMA process with Extreme Networks Technical Support.

NOTE Only run extended or packet-memory diagnostics when the switch can be brought off-line. The tests conducted during these diagnostics are extensive and can affect traffic that must be processed by the system CPU. To view results of the normal or extended diagnostics test, use the following command:
show diagnostics

To view the results of a packet memory scan, use the following command:
show diagnostics packet-memory slot <slot number>

Packet Memory Scanning (BlackDiamond Switches)

You can scan and check the health of individual BlackDiamond modules rather than the overall system by configuring packet memory scanning on a per slot basis. If you have the system health check configured for auto-recovery, and you configure packet memory scanning on a slot, you can define that slots behavior if an error is discovered. By default, packet memory scanning is disabled. To configure packet memory scanning on a BlackDiamond module, use the following command:
configure packet-mem-scan-recovery-mode [offline | online] slot [msm-a | msm-b | <slot number>]

where the following is true: offlineSpecifies that a module is taken offline and kept offline if one of the following occurs: More than eight defects are detected. Three consecutive checksum error were detected by the health checker, but no new defects were found by the memory scanning and mapping process. After defects were detected and mapped out, the same checksum errors are again detected by the system health checker. onlineSpecifies that a faulty module is kept online, regardless of how many errors are detected. msm-aSpecifies the MSM module installed in slot A.

ExtremeWare 7.1.0 Software User Guide

191

Status Monitoring and Statistics

msm-bSpecifies the MSM module installed in slot B. slot numberSpecifies a module installed in a slot. This command overrides the system health check auto-recovery setting. If you have the system health check alarm level configured, the individual packet memory scanning configuration is ignored. See System Health Checking on page 195 for more information about the system health checker. To disable packet memory scanning and to return to the system health check configured behavior, use the following command:
unconfigure packet-mem-scan-recovery-mode slot [msm-a | msm-b | <slot number>]

To view the recovery mode configuration for slots that have packet memory scanning enabled, use the following command:
show packet-mem-scan-recovery-mode

Where the following information is displayed: Global settings for the system health check Auto-recovery settings for slots that have packet memory scanning enabled The following is sample output from this command:
Global sys-health-check online setting slot 3: AUTORECOVERY MODE is OFFLINE MSM-B: AUTORECOVERY MODE is ONLINE is ONLINE

# NOTE Global setting is always online for sys-health-check alarm-level configurations. It is only offline when "sys-health-check auto-recovery <#> offline" is configured.

Port Statistics
ExtremeWare provides a facility for viewing port statistic information. The summary information lists values for the current counter against each port on each operational module in the system, and it is refreshed approximately every 2 seconds. Values are displayed to nine digits of accuracy. To view port statistics, use the following command:
show ports <portlist> stats

The following port statistic information is collected by the switch: Link StatusThe current status of the link. Options are: Ready (the port is ready to accept a link). Active (the link is present at this port). Chassis (the link is connected to a Summit Virtual Chassis). Transmitted Packet Count (Tx Pkt Count)The number of packets that have been successfully transmitted by the port.

192

ExtremeWare 7.1.0 Software User Guide

Port Errors

Transmitted Byte Count (Tx Byte Count)The total number of data bytes successfully transmitted by the port. Received Packet Count (Rx Pkt Count)The total number of good packets that have been received by the port. Received Byte Count (RX Byte Count)The total number of bytes that were received by the port, including bad or lost frames. This number includes bytes contained in the Frame Check Sequence (FCS), but excludes bytes in the preamble. Received Broadcast (RX Bcast)The total number of frames received by the port that are addressed to a broadcast address. Received Multicast (RX Mcast)The total number of frames received by the port that are addressed to a multicast address.

Port Errors
The switch keeps track of errors for each port. To view port transmit errors, use the following command:
show ports <portlist> txerrors

The following port transmit error information is collected by the system: Port Number Link StatusThe current status of the link. Options are: Ready (the port is ready to accept a link). Active (the link is present at this port). Transmit Collisions (TX Coll)The total number of collisions seen by the port, regardless of whether a device connected to the port participated in any of the collisions. Transmit Late Collisions (TX Late Coll)The total number of collisions that have occurred after the ports transmit window has expired. Transmit Deferred Frames (TX Deferred)The total number of frames that were transmitted by the port after the first transmission attempt was deferred by other network traffic. Transmit Errored Frames (TX Error)The total number of frames that were not completely transmitted by the port because of network errors (such as late collisions or excessive collisions). Transmit Parity Frames (TX Parity)The bit summation has a parity mismatch. To view port receive errors, use the following command:
show ports <portlist> rxerrors

The following port receive error information is collected by the switch: Receive Bad CRC Frames (RX CRC)The total number of frames received by the port that were of the correct length, but contained a bad FCS value. Receive Oversize Frames (RX Over)The total number of good frames received by the port greater than the supported maximum length of 1,522 bytes. For products that use the i chipset, ports with jumbo frames enabled do not increment this counter. Receive Undersize Frames (RX Under)The total number of frames received by the port that were less than 64 bytes long.

ExtremeWare 7.1.0 Software User Guide

193

Status Monitoring and Statistics

Receive Fragmented Frames (RX Frag)The total number of frames received by the port were of incorrect length and contained a bad FCS value. Receive Jabber Frames (RX Jab)The total number of frames received by the port that was of greater than the support maximum length and had a Cyclic Redundancy Check (CRC) error. Receive Alignment Errors (RX Align)The total number of frames received by the port that occurs if a frame has a CRC error and does not contain an integral number of octets. Receive Frames Lost (RX Lost)The total number of frames received by the port that were lost because of buffer overflow in the switch.

Port Monitoring Display Keys

Table 27 describes the keys used to control the displays that appear when you issue any of the show
port commands.

Table 27: Port Monitoring Display Keys

Key(s) U D [Esc] or [Return] 0 [Space] Description Displays the previous page of ports. Displays the next page of ports. Exits from the screen. Clears all counters. Cycles through the following screens: Packets per second Bytes per second Percentage of bandwidth

Available using the show port utilization command only.

System Temperature
You can record the system temperature in celsius for the BlackDiamond and Alpine systems to the syslog. The temperature is recorded every hour. To record the temperature, use the following command:
enable temperature-logging

By default, the system temperature is not recorded to the syslog. After you enable the temperature logging feature, you can view the temperature of the system. To view the temperature, use the following command:
show log

The following is sample temperature output from the show log command:
06/12/2003 19:50:59.00 <Info:ELRP> Current temperature reading [197] is 49C. 06/12/2003 18:50:59.00 <Info:ELRP> Current temperature reading [196] is 48C.

194

ExtremeWare 7.1.0 Software User Guide

System Health Checking

06/12/2003 17:50:59.00 <Info:ELRP> Current temperature reading [195] is 48C.

To stop recording the temperature, use the following command:

disable temperature-logging

If you already enabled temperature logging, and you want to view the current temperature of the system, do the following: 1 Disable the temperature logging feature using the following command:
disable temperature-logging

2 Re-enable the temperature logging feature using the following command:

enable temperature-logging

3 Display the syslog using the following command:

show log

System Health Checking

The system health checker tests the backplane, the CPU, and I/O modules by periodically forwarding packets and checking for the validity of the forwarded packets. The system health checker can be configured to handle a failure as an error condition, logging the problem to the syslog, or it can attempt auto-recovery of the module that generated the errors. The alarm-level and auto-recovery options are mutually exclusive. To enable the system health checker, use the following command:
enable sys-health-check

To disable the system health checker, use the following command:

disable sys-health-check

To configure the switch to respond to a failed health check based on an alarm-level, use the following command:
configure sys-health-check alarm-level [card-down | default | log | system-down | traps]

This command provides the following options: card-downPosts a CRIT message to the log, sends a trap, and turns off the module. logPosts a CRIT message to the log. system-downPosts a CRIT message to the log, sends a trap, and turns off the system. trapsPosts a CRIT message to the log and sends a trap. The default option is log. To configure the switch for auto-recovery, use the following command:
configure sys-health-check auto-recovery <number of tries>

ExtremeWare 7.1.0 Software User Guide

195

Status Monitoring and Statistics

The auto-recovery option is used to configure the number of times the system health checker attempts to automatically reset a faulty module and bring it online. If the module continues to fail more than the configured number of attempts, the system health checker sets the module to card-down. When auto-recovery is configured, the occurrence of three consecutive checksum errors will cause a packet memory (PM) defect detection program to be run against the I/O module. Checksum errors can include internal and external MAC port parity errors, EDP checksum errors, and CPU packet or diagnostic packet checksum errors. If defects are detected, the card is taken offline, the memory defect information is recorded in the card EEPROM, the defective buffer is mapped out of further use, and the card is returned to operational state. A maximum of 8 defects can be stored in the EEPROM. After the PM defect detection and mapping process has been run, a card is considered failed and is taken offline in the following circumstances: More than eight defects are detected. Three consecutive checksum errors were detected by the health checker, but no new PM defects were found by the PM defect detection process. After defects were detected and mapped out, the same checksum errors are again detected by the system health checker. The auto-recovery repetition value is ignored in these cases. In any of these cases, please contact Extreme Technical Support. To view the status of the system health checker, use the following command:
show diagnostics

Checking the Integrity of the FDB

The system health checker also checks the integrity of the FDB. If you enable the system health checker, a section of the FDB memory on each modules switching fabric is non-intrusively compared to the software copy of the FDB. The switch takes one of the following actions if it detects a bad entry: If the entry is not in useremaps around the entry location If the entry is in use, but is safely removable (most MAC and IP-DA entries)removes the questionable entry, allows the table to be rebuilt naturally, and remaps around the entry location If the entry is in use and is not safely removable (MAC_NH, IPSA, IPMCDA, IPDP, IPSP, IPXSN)sends a warning message to the log If the switch detects more than eight questionable entries, it executes the configured failure action and stops remapping on the switch fabric. To see the questionable and remapped entries, use the show fdb command. The following information is displayed: Questionable entries are marked with a Q flag Remapped entries are marked with an R flag Total FDB count You can also display FDB scan statistics using the following commands:
show diagnostics sys-health-check

To clear the questionable and remapped entries, use the following command:
clear fdb remap

196

ExtremeWare 7.1.0 Software User Guide

System Health Checking

Testing the Transceivers

The transceiver test is a useful diagnostic tool that allows you to test the integrity of the transceivers used for communication between the ASICS and the CPU on an MSM or SMMi module. The transceiver test is available on modular switches only.

Enabling the Transceiver Test

By default, transceiver testing is disabled. To enable the transceiver test on an Alpine switch, use the following command:
enable transceiver-test [all | slot <slot number> {backplane}]

To enable the transceiver test on a BlackDiamond switch, use the following command:
enable transceiver-test [all | slot {<slot number> | msm-a | msm-b}]

where the following is true: allSpecifies all of the slots in the chassis. backplaneSpecifies the backplane of the Alpine chassis. This is available on Alpine switches only. slot numberSpecifies the slot number of the module to scan. msm-aSpecifies the MSM installed in slot A. This is available on BlackDiamond switches only. msm-bSpecifies the MSM installed in slot B. This is available on BlackDiamond switches only. To determine if you have the transceiver test enabled and the failure action the switch takes, use the show switch command. The following is sample transceiver test output:
Transceiver Diag: Enabled. Failure action: log only

Disabling the Transceiver Test

To disable the transceiver test on an Alpine switch, use the following command:
disable transceiver-test [all | slot <slot number> {backplane}]

To disable the transceiver test on a BlackDiamond switch, use the following command:
disable transceiver-test [all | slot <slot number> | msm-a | msm-b]

Configuring the Transceiver Test Parameters

You can configure the following test parameters: How often the test runs The amount of errors accepted The number of 20-second windows the switch uses to check for errors The action the switch takes if too many failures are detected NOTE Extreme Networks does not recommend changing the default transceiver test parameters. The default parameters are adequate for most networks.

ExtremeWare 7.1.0 Software User Guide

197

Status Monitoring and Statistics

Configuring the Test Period. To configure how often to run the transceiver test, use the following command:
configure transceiver-test period <period <1-60>>

where the: Default is 12 seconds Range is 1 - 60 seconds To return the transceiver test period to the factory default of 12 seconds, use the following command:
unconfigure transceiver-test period

Configuring the Test Threshold. To configure how many errors the switch accepts before an action is taken, use the following command:
configure transceiver-test threshold <1-8>

where the: Default is 3 errors Range is 1 - 8 errors To return the transceiver test threshold to the factory default of 3 errors, use the following command:
unconfigure transceiver-test threshold

Configuring the Test Window. To configure the number of 20-second windows within which the configured number of errors can occur, use the following command:
configure transceiver-test window <1-8>

where the: Default is 8 windows Range is 1 - 8 windows This configuration provides a sliding window. If you keep the window configuration at 8, the switch checks for errors within the last eight 20-second windows. To return the transceiver test window to the factory default of 8, use the following command:
unconfigure transceiver-test window

Configuring the Test Failure Action. If the switch detects too many failures within the specified window, the messages are either sent to the syslog or the configured system health check action is taken. To configure the action the switch takes when too many failures are detected, use the following command:
configure transceiver-test failure-action [log | sys-health-check]

198

ExtremeWare 7.1.0 Software User Guide

System Health Checking

where the following is true: logMessages are sent to the syslog. Only one instance of an error messages is logged at this level. This is the default. sys-health-checkThe configured system health check action is taken. To return the switch to the default mode of sending messages to the syslog, use the following command:
unconfigure transceiver-test failure-action

For more information about these and other transceiver test commands, see the Extreme Networks Command Reference Guide.

Displaying Transceiver Statistics

To view the transceiver statistics, use the following command:
show diagnostics

In addition to other switch diagnostics, you can view the following transceiver statistics: Slot number or backplane Cardtype (if no module is installed in the slot, the card type is unknown) Cardstate Test Pass Fail Time of the last failure The following is an example of the type of transceiver statistics output displayed:
Transceiver system health diag result Pass/Fail Counters Are in HEX Slot Cardtype Cardstate Test Pass Fail Time_last_fail ----------- ------------------- -------- -------------slot 1 Unknown slot 2 WM4T1 Operational MAC 7d456 0 slot 3 FM8V Operational MAC 7d456 0 slot 4 GM4X Operational MAC 7d456 0 BPLNE SMMI Operational UART 7d454 0 BPLNE SMMI Operational FLASH 7d454 0 BPLNE SMMI Operational SRAM 7d454 0 BPLNE SMMI Operational NVRAM 7d454 0 BPLNE SMMI Operational ENET 7d454 0 BPLNE Basbrd Operational QUAKE 7d454 0 BPLNE Basbrd Operational TWISTER 7d454 0

To clear the transceiver statistics, use the following command:

clear transceiver-test

ExtremeWare 7.1.0 Software User Guide

199

Status Monitoring and Statistics

Setting the System Recovery Level

You can configure the system to automatically reboot after a software task exception, using the following command:
configure sys-recovery-level [none | all | critical]

Where the following is true: noneConfigures the level to no recovery. allConfigures ExtremeWare to log an error into the syslog and automatically reboot the system after any task exception. criticalConfigures ExtremeWare to log an error into the syslog and automatically reboot the system after a critical task exception. The default setting is none.

Event Management System/Logging

Beginning in ExtremeWare 7.1.0, the system responsible for logging and debugging was updated and enhanced. We use the general term, event, for any type of occurrence on a switch which could generate a log message, or require an action. For example, a link going down, a user logging in, a command entered on the command line, or the software executing a debugging statement, are all events that might generate a log message. The new system for saving, displaying, and filtering events is called the Event Management System (EMS). With EMS, you have a lot more options about which events generate log messages, where the messages are sent, and how they are displayed. Using EMS you can: send event messages to a number of logging targets (for example, syslog host and NVRAM) filter events on a per-target basis by component, subcomponent, or specific condition (for example, BGP messages, IGMP.Snooping messages, or the IP.Forwarding.SlowPathDrop condition) by match expression (for example, any messages containing the string user5) by matching parameters (for example, only messages with source IP addresses in the 10.1.2.0/24 subnet) by severity level (for example, only messages of severity critical, error, or warning) change the format of event messages (for example, display the date as 12-May-2003 or 2003-05-12) display log messages in real-time, and filter the messages that are displayed, both on the console and from telnet sessions display stored log messages from the memory buffer or NVRAM upload event logs stored in memory to a TFTP server display counts of event occurrences, even those not included in filter display debug information, using a consistent configuration method

Sending Event Messages to Log Targets

There are five types of targets that can receive log messages:

200

ExtremeWare 7.1.0 Software User Guide

Event Management System/Logging

console display current session (telnet or console display) memory buffer (can contain 200-20,000 messages) NVRAM (messages remain after reboot) syslog host The first four types of targets exist by default, but before enabling any syslog host, the hosts information needs to be added to the switch using the configure syslog command. Extreme Networks EPICenter can be a syslog target. By default, the memory buffer and NVRAM targets are already enabled and receive messages. To start sending messages to the targets, use the following command:
enable log target [console-display | memory-buffer | nvram | session | syslog [<host name/ip> {:<udp-port>} [local0 ... local7]]]

Once enabled, the target receives the messages it is configured for. See the section Target Configuration for information on viewing the current configuration of a target. The memory buffer can only contain the configured number of messages, so the oldest message is lost when a new message arrives, and the buffer is full. Use the following command to stop sending messages to the target:
disable log target [console-display | memory-buffer | nvram | session | syslog [<host name/ip> {:<udp-port>} [local0 ... local7]]]

NOTE Refer to your UNIX documentation for more information about the syslog host facility.

Filtering Events Sent to Targets

Not all event messages are sent to every enabled target. Each target receives only the messages that it is configured for.

Target Configuration
To specify the messages to send to a enabled target, you will set a message severity level, a filter name, and a match expression. These items determine which messages are sent to the target. You can also configure the format of the messages in the targets. Each target has a default configuration that mimics the expected behavior of prior ExtremeWare releases. For example, the console display target is configured to get messages of severity info and greater, the NVRAM target gets messages of severity warning and greater, and the memory buffer target gets messages of severity debug-data and greater. All the targets are associated by default with a filter named DefaultFilter, that passes all events at or above the default severity threshold, like the behavior of earlier releases (the earlier releases had no filters). All the targets are also associated with a default match expression that matches any messages (the expression that matches any message is displayed as Match : (none) from the command line). And finally, each target has a format associated with it. To display the current log configuration of the targets, use the following command:
show log configuration target {console-display | memory-buffer | nvram | session | syslog <host name/ip> {: <udp-port>}[local0 ... local7]}

ExtremeWare 7.1.0 Software User Guide

201

Status Monitoring and Statistics

To configure a target, there are specific commands for filters, formats, and severity that are discussed in the following sections.

Severity
Messages are issued with one of the severity level specified by the standard BSD syslog values (RFC 3164), critical, error, warning, notice, and info, plus three severity levels for extended debugging, debug-summary, debug-verbose, and debug-data. Note that RFC 3164 syslog values emergency and alert are not needed since critical is the most severe event in the system. The three severity levels for extended debugging, debug-summary, debug-verbose, and debug-data, require that debug mode be enabled (which may cause a performance degradation). See the section Displaying Debug Information for more information about debugging. Table 28: Severity Levels Assigned by the Switch1
Level Critical Description A serious problem has been detected which is compromising the operation of the system and that the system can not function as expected unless the situation is remedied. The switch may need to be reset. A problem has been detected which is interfering with the normal operation of the system and that the system is not functioning as expected. An abnormal condition, not interfering with the normal operation of the system, has been detected which may indicate that the system or the network in general may not be functioning as expected. A normal but significant condition has been detected, which signals that the system is functioning as expected. A normal but potentially interesting condition has been detected, which signals that the system is functioning as expected and simply provides potentially detailed information or confirmation. A condition has been detected that may interest a developer determining the reason underlying some system behavior. A condition has been detected that may interest a developer analyzing some system behavior at a more verbose level than provided by the debug summary information. A condition has been detected that may interest a developer inspecting the data underlying some system behavior.

Error Warning

Notice Info (Informational)

Debug-Summary Debug-Verbose Debug-Data

1. In ExtremeWare version 7.1.0, the levels alert and emergency were deprecated. The equivalent level is critical.

To configure the severity level of the messages sent to a target, there is more than one command that you can use. The most direct way to set the severity level of all the sent messages is to use the following command: configure log target [console-display | memory-buffer | nvram | session | syslog [<host name/ip> {: <udp-port>} [local0 ... local7]]] {severity <severity> {only}} When you specify a severity level, messages of that severity and greater will be sent to the target. If you want only messages of the specified severity to be sent to the target, use the keyword only. For example, specifying severity warning will send warning, error, and critical messages, but specifying severity warning only will just send warning messages. Another command that can be used to configure severity levels is the command used to associate a filter with a target:

202

ExtremeWare 7.1.0 Software User Guide

Event Management System/Logging

configure log target [console-display | memory-buffer | nvram | session | syslog [<host name/ip> {: <udp-port>} [local0 ... local7]]] filter <filter name> {severity <severity> {only}} When you specify a severity level as you associate a filter with a target, you further restrict the messages reaching the target. The filter may only allow certain categories of messages to pass. Only the messages that pass the filter, and then pass the specified severity level will reach the target. Finally, you can specify the severity levels of messages that reach the target by associating a filter with a target. The filter can specify exactly which message it will pass. Constructing a filter is discussed in the section Filtering By Components and Conditions.

Components and Conditions

Beginning with the introduction of EMS in release 7.1.0, the event conditions detected by ExtremeWare were organized into components and subcomponents. This is somewhat similar to the fault log subsystems used in previous versions. Not all conditions have been placed in the component/subcomponent structure of EMS, but all the conditions will be moved over time into this structure. To get a listing of the components and subcomponents in your release of ExtremeWare, use the following command: show log components {<event component> | all} For example, to get a listing of the subcomponents that make up the STP component, use the following command:
show log components stp

The output produced by the command is similar to the following:

Component ------------------STP InBPDU OutBPDU System Title ---------------------------------------------Spanning-Tree Protocol (STP) STP In BPDU subcomponent STP Out BPDU subcomponent STP System subcomponent Severity Threshold ---------Error Warning Warning Error

In the display above is listed the component, the subcomponents that make up that component, and the default severity threshold assigned to that component. A period (.) is used to separate component, subcomponent, and condition names in EMS. For example, you can refer to the InBPDU subcomponent of the STP component as STP.InBPDU. On the CLI, you can abbreviate or TAB complete any of these. A component or subcomponent will often have several conditions associated with it. To see the conditions associated with a component, use the following command:
show log events {<event condition> | [all | <event component>] {severity <severity> {only}}} {detail}

For example, to see the conditions associated with the STP.InBPDU subcomponent, use the following command:
show log events stp.inbpdu

The output produced by the command is similar to the following:

Comp SubComp Condition Severity Parameters ------- ----------- ----------------------- ------------- ----------

ExtremeWare 7.1.0 Software User Guide

203

Status Monitoring and Statistics

STP

InBPDU Drop Dump Ign Trace Error Debug-Data Debug-Summary Info 3 3 2 2

In the display above is listed the four conditions contained in the STP.InBPDU component, the severity of the condition, and the number of parameters in the event message. In this example, the severities of the events in the STP.InBPDU subcomponent range from error to debug-summary. When you use the detail keyword you will see the message text associated with the conditions. For example, if you want to see the message text and the parameters for the event condition STP.InBPDU.Trace, use the following command:
show log events stp.inbpdu.trace detail

The output produced by the command is similar to the following:

Comp SubComp Condition Severity Parameters ------- ----------- ----------------------- ------------- ---------STP InBPDU Trace Info 2 Total 0 - ports 1 - string "Port=%0%: %1%"

The Comp heading shows the component name, the SubComp heading shows the subcomponent (if any), the Condition heading shows the event condition, the Severity heading shows the severity assigned to this condition, the Parameters heading shows the parameters for the condition, and the text string shows the message that the condition will generate. The parameters in the text string (for example, %0% and %1% above) will be replaced by the values of these parameters when the condition is encountered, and output as the event message. Filtering By Components and Conditions. You may want to send the messages that come from a specific component that makes up ExtremeWare, or send the message generated by a specific condition. For example, you might want to send only the messages that come from the STP component, or send the message that occurs when the IP.Forwarding.SlowPathDrop condition occurs. Or you may want to exclude messages from a particular component or event. To do this, you will construct a filter that passes only the items of interest, and associate that filter with a target. The first step is to create the filter using the create log filter command. You can create a filter from scratch, or copy another filter to use as a starting point. It may be easiest to copy an existing filter and modify it. Use the following command to create a filter:
create log filter <name> {copy <filter name>}

If you create a filter from scratch, it will initially block all events until you add events (either the events from a component or a specific event condition) to pass. You might create a filter from scratch if you wanted to pass a small set of events, and block most. If you want to exclude a small set of events, there is a default filter that passes events at or above the default severity threshold (unless the filter has been modified), named DefaultFilter, that you can copy to use as a starting point for your filter. Once you have created your filter, you can then configure filter items that include or exclude events from the filter. Included events are passed, excluded events are blocked. Use the following command to configure your filter:
configure log filter <filter name> [add | delete] {exclude} events [<event condition> | [all | <event component>] {severity <severity> {only}}]

204

ExtremeWare 7.1.0 Software User Guide

Event Management System/Logging

For example, if you create the filter myFilter from scratch, then issue the following command:
configure log filter myFilter add events stp

all STP events will pass myFilter of at least the default threshold severity (for the STP component, the default severity threshold is error). You can further modify this filter by specifying additional conditions. For example, assume that myFilter is configured as before, and assume that you want to exclude any events from the STP subcomponent, STP.OutBPDU. Use the following command to add that condition:
configure log filter myFilter add exclude events stp.outbpdu

You can continue to modify this filter by adding more filter items. The filters process events by comparing the event with the most recently configured filter item first. If the event matches this filter item, the incident is either included or excluded, depending on whether the exclude keyword was used. Subsequent filter items on the list are compared if necessary. If the list of filter items has been exhausted with no match, the event is excluded, and is blocked by the filter. To examine the configuration of a filter, use the following command:
show log configuration filter {<filter name>}

The output produced by the command (for the earlier filter) is similar to the following:
Log Filter I/ E Comp - ------E STP I STP Name : myFilter SubComp ----------OutBPDU * Condition ----------------------* * Severity CEWNISVD -------CEWNI+++ ********

Include/Exclude: (I) Include, (E) Exclude Severity Values: (C) Critical, (E) Error, (W) Warning, (N) Notice, (I) Info (*) Pre-assigned severities in effect for each subcomponent Debug Severity : (S) Debug-Summary, (V) Debug-Verbose, (D) Debug-Data (+) Debug Severity requested, but log debug-mode not enabled If Match parameters present: Parameter Flags: (S) Source, (D) Destination (as applicable) (I) Ingress, (E) Egress, (B) BGP Parameter Types: Port - Physical Port list, Slot - Physical Slot # MAC - MAC address, IP - IP Address/netmask, Mask - Netmask VID - Virtual LAN ID (tag), VLAN - Virtual LAN name L4 - Layer-4 Port #, Num - Number, Str - String Nbr - Neighbor, Rtr - Routerid, EAPS - EAPS Domain Strict Match : (Y) every match parameter entered must be present in the event (N) match parameters need not be present in the event

The show log configuration filter command shows each filter item, in the order that it will be applied and whether it will be included or excluded. The above output shows the two filter items, one excluding events from the STP.OutBPDU component, the next including the remaining events from the STP component. The severity value is shown as *, indicating that the components default severity threshold controls which messages are passed. The Parameter(s) heading is empty for this filter, since no match was configured for this filter. Matches are discussed in the section, Matching Expressions. Each time a filter item is added to or deleted from a given filter, the events specified are compared against the current configuration of the filter to try to logically simplify the configuration. Existing items

ExtremeWare 7.1.0 Software User Guide

205

Status Monitoring and Statistics

will be replaced by logically simpler items if the new item enables rewriting the filter. If the new item is already included or excluded from the currently configured filter, the new item is not added to the filter.

Matching Expressions
You can specify that messages that reach the target match a specified match expression. The message text is compared with the match expression to determine whether to pass the message on. To require that messages match a match expression, is to use the following command: configure log target [console-display | memory-buffer | nvram | session | syslog [<host name/ip> {: <udp-port>} [local0 ... local7]]] match [any |<match-expression>] The messages reaching the target will match the match-expression, a simple regular expression. The formatted text string that makes up the message is compared with the match expression, and is passed to the target if it matches. This command does not affect the filter in place for the target, so the match expression is only compared with the messages that have already passed the targets filter. For more information on controlling the format of the messages, see the section, Formatting Event Messages. Simple Regular Expressions. A simple regular expression is a string of single characters including the dot character (.), which are optionally combined with quantifiers and constraints. A dot matches any single character while other characters match only themselves (case is significant). Quantifiers include the star character (*) that matches zero or more occurrences of the immediately preceding token. Constraints include the caret character (^) that matches at the beginning of a message, and the currency character ($) that matches at the end of a message. Bracket expressions are not supported. There are a number of sources available on the Internet and in various language references describing the operation of regular expressions. Table 29 shows some examples of regular expressions.

Table 29: Simple Regular Expressions

Regular Expression port Matches port 2:3 import cars portable structure baar bazaar rebar port 2:3 in vlan test add ports to vlan port/vlan delete myvlan error in myvlan myvlan port 2:3 ports 2:4,3:4 myvlan link down Does not match poor por pot bar

..ar

port.*vlan

myvlan$

Matching Parameters
Rather than using a text match, ExtremeWares EMS allows you to filter more efficiently based on the message parameter values. In addition to event components and conditions and severity levels, each filter item can also use parameter values to further limit which messages are passed or blocked. The process of creating, configuring, and using filters has already been described in the section, Filtering By Components and Conditions, so this section will discuss matching parameters with a filter item. To configure a parameter match filter item, use the following command:

206

ExtremeWare 7.1.0 Software User Guide

Event Management System/Logging

configure log filter <filter name> [add | delete] {exclude} events [<event condition> | [all | <event component>] {severity <severity> {only}}] [match | strict-match] <type> <value> {and <type> <value> ...} Each event in ExtremeWare is defined with a message format and zero or more parameter types. The show log events detail command can be used to display event definitions (the event text and parameter types). Only those parameter types that are applicable given the events and severity specified are exposed on the CLI. The syntax for the parameter types (represented by <type> in the command syntax above) is:
[bgp [neighbor | routerid] <ip address> | eaps <eaps domain name> | {destination | source} [ipaddress <ip address> | L4-port <L4-port>| mac-address <mac-address>] | {egress | ingress} [slot <slot number> | ports <portlist>] | netmask <netmask> | number <number> | string <match expression> | vlan <vlan name> | vlan tag <vlan tag>]

The <value> depends on the parameter type specified. As an example, an event may contain a physical port number, a source MAC address, and a destination MAC address. To allow only those Bridging incidents, of severity notice and above, with a specific source MAC address, use the following command:
configure log filter myFilter add events bridge severity notice match source mac-address 00:01:30:23:C1:00

The string type is used to match a specific string value of an event parameter, such as a user name. A string can be specified as a simple regular expression. Use the and keyword to specify multiple parameter type/value pairs that must match those in the incident. For example, to allow only those events with specific source and destination MAC addresses, use the following command:
configure log filter myFilter add events bridge severity notice match source mac-address 00:01:30:23:C1:00 and destination mac-address 01:80:C2:00:00:02

Match Versus Strict-Match. The match and strict-match keywords control the filter behavior for incidents whose event definition does not contain all the parameters specified in a configure log filter events match command. This is best explained with an example. Suppose an event in the XYZ component, named XYZ.event5, contains a physical port number, a source MAC address, but no destination MAC address. If you configure a filter to match a source MAC address and a destination MAC address, XYZ.event5 will match the filter when the source MAC address matches regardless of the destination MAC address, since the event contains no destination MAC address. If you specify the strict-match keyword, then the filter will never match event XYZ.event5, since this event does not contain the destination MAC address. In other words, if the match keyword is specified, an incident will pass a filter so long as all parameter values in the incident match those in the match criteria, but all parameter types in the match criteria need not be present in the event definition.

ExtremeWare 7.1.0 Software User Guide

207

Status Monitoring and Statistics

Formatting Event Messages

Event messages are made up of a number of items. The individual items can be formatted, however, EMS does not allow you to vary the order of the items. To format the messages for a particular target, use the following command: configure log target [console-display | memory-buffer | nvram | session | syslog [<host name/ip> {:<udp-port>} [local0 ... local7]]] format [timestamp [seconds | hundredths | none] | date [dd-mm-yyyy | dd-Mmm-yyyy | mm-dd-yyyy | Mmm-dd | yyyy-mm-dd | none] | severity [on | off] | event-name [component | condition | none | subcomponent] | host-name [on | off] | priority [on | off] | tag-id [on | off] | tag-name [on | off] | sequence-number [on | off] | process-name [on | off] | process-id [on | off] | source-function [on | off] | source-line [on | off]] Using the default format for the session target, an example log message might appear as:
05/29/2003 12:15:25.00 <Warn:SNTP.RslvSrvrFail> The SNTP server parameter value (TheWrongServer.example.com) can not be resolved.

If you set the current session format using the following command:
configure log target session format date mm-dd-yyy timestamp seconds event-name component

The same example would appear as:

05/29/2003 12:16:36 <Warn:SNTP> The SNTP server parameter value (TheWrongServer.example.com) can not be resolved.

In order to provide some detailed information to technical support, you set the current session format using the following command:
configure log target session format date mmm-dd timestamp hundredths event-name condition source-line on process-name on

The same example would appear as:

May 29 12:17:20.11 SNTP: <Warn:SNTP.RslvSrvrFail> tSntpc: (sntpcLib.c:606) The SNTP server parameter value (TheWrongServer.example.com) can not be resolved.

Displaying Real-Time Log Messages

You can configure the system to maintain a running real-time display of log messages on the console display or on a (telnet) session. To turn on the log display on the console, use the following command:
enable log target console-display

This setting may be saved to the FLASH configuration and will be restored on boot up (to the console-display session). To turn on log display for the current session:

208

ExtremeWare 7.1.0 Software User Guide

Event Management System/Logging

enable log target session

This setting only affects the current session, and is lost when you log off the session. The messages that are displayed depend on the configuration and format of the target. See the section, Filtering Events Sent to Targets, for information on message filtering, and the section, Formatting Event Messages, for information on message formatting.

Displaying Events Logs

The log stored in the memory buffer and the NVRAM can be displayed on the current session (either the console display or telnet). Use the following command to display the log: show log {messages [memory-buffer | nvram]} {severity <severity> {only}} {starting [date <date> time <time> | date <date> | time <time>]} {ending [date <date> time <time> | date <date> | time <time>]} {match <match-expression>} {format <format>} {chronological} There are many options you can use to select the log entries of interest. You can select to display only those messages that conform to the specified: severity starting and ending date and time match expression The displayed messages can be formatted differently from the format configured for the targets, and you can choose to display the messages in order of newest to oldest, or in chronological order (oldest to newest).

Uploading Events Logs

The log stored in the memory buffer and the NVRAM can be uploaded to a TFTP server. Use the following command to upload the log: upload log <host name/ip> <filename> {messages [memory-buffer | nvram]} {severity <severity> {only}} {starting [date <date> time <time> | date <date> | time <time>]} {ending [date <date> time <time> | date <date> | time <time>]} {match <match-expression>} {format <format>} {chronological} You must specify the TFTP host and the filename to use in uploading the log. There are many options you can use to select the log entries of interest. You can select to upload only those messages that conform to the specified: severity starting and ending date and time match expression The uploaded messages can be formatted differently from the format configured for the targets, and you can choose to upload the messages in order of newest to oldest, or in chronological order (oldest to newest).

ExtremeWare 7.1.0 Software User Guide

209

Status Monitoring and Statistics

Displaying Counts of Event Occurrences

EMS adds the ability to count the number of occurrences of events. Even when an event is filtered from all log targets, the event is counted. (The exception to this is events of any of the debug severities, which are only counted when the log debug mode is enabled.) To display the event counters, use the following command:
show log counters {<event condition> | [all | <event component>] {[included | notified | occurred]}{severity <severity> {only}}}

Two counters are displayed. One counter displays the number of times an event has occurred, and the other displays the number of times that notification for the event was made to the system for further processing. Both counters reflect totals accumulated since reboot or since the counters were cleared using the clear log counters or clear counters command. This command also displays an included count (the column titled In in the output). The reference count is the number of enabled targets receiving notifications of this event without regard to matching parameters. The keywords included, notified, and occurred only display events with non-zero counter values for the corresponding counter. Output of the command:
show log counters stp.inbpdu severity debug-summary

will be similar to the following:

Comp SubComp Condition Severity Occurred In Notified ------- ----------- ----------------------- ------------- -------- -- -------STP InBPDU Drop Error 0 1 0 Ign Debug-Summary 0+ 0 0 Trace Info 0 0 0 Occurred : # of times this event has occurred since last clear or reboot Flags : (+) Debug events are not counted while log debug-mode is disabled In(cluded): # of enabled targets whose filter includes this event Notified : # of times this event has occurred when Included was non-zero

Output of the command:

show log counters stp.inbpdu.drop

will be similar to the following:

Comp SubComp Condition Severity Occurred ------- ----------- ----------------------- ------------- -------STP InBPDU Drop Error 0 In Notified -- -------1 0

Displaying Debug Information

By default, a switch will not generate events of severity Debug-Summary, Debug-Verbose, and Debug-Data unless the switch is in debug mode. Debug mode causes a performance penalty, so it should only be enabled for specific cases where it is needed. To place the switch in debug mode, use the following command:
enable log debug-mode

210

ExtremeWare 7.1.0 Software User Guide

Event Management System/Logging

Once debug mode is enabled, any filters configured for your targets will still affect which messages are passed on or blocked.

NOTE Previous versions of ExtremeWare used the debug-trace command to enable debugging. Not all systems in ExtremeWare were converted to use EMS in the initial release. As a result, some debug information still requires you to use the corresponding debug-trace command. The show log component command displays the systems in your image that are part of EMS. Any systems in EMS will not have debug-trace commands, and vice-versa

Compatibility with previous ExtremeWare commands

Since EMS provides much more functionality, there are a number of new commands introduced to support it. However, if you do not require the enhanced capabilities provided by EMS, you can continue to use many of the logging commands that existed in earlier versions of ExtremeWare. For consistency, the earlier commands are still supported. Listed below are earlier commands with their new command equivalents.

Enable / disable log display

The following commands related to the serial port console:
enable log display disable log display

are equivalent to:

enable log target console-display disable log target console-display

Note that the existing command enable log display applies only to the serial port console. Since the ability to display log messages on other sessions was added, the target name session was chosen. For clarity, the target name console-display was chosen to refer to the serial port console, previously referred to as simply display.

Configure log display

The following command related to the serial port console:
configure log display <severity>

is equivalent to:
configure log target console-display severity <severity>

Remote syslog commands

The following command related to remote syslog hosts:
configure syslog add <hostname/IP> {: <udp-port> } [local0 ... local7] <severity>

is equivalent to the following two commands:

ExtremeWare 7.1.0 Software User Guide

211

Status Monitoring and Statistics

configure syslog add <hostname/IP> {: <udp-port>} [local0 ... local7] configure log target syslog <hostname/IP> {: <udp-port>} [local0 ... local7] severity <severity>

NOTE Refer to your UNIX documentation for more information about the syslog host facility.

Logging Configuration Changes

ExtremeWare allows you to record all configuration changes and their sources that are made using the CLI by way of telnet or the local console. The changes cause events that are logged to the target logs. Each log entry includes the user account name that performed the change and the source IP address of the client (if telnet was used). Configuration logging applies only to commands that result in a configuration change. To enable configuration logging, use the following command:
enable cli-config-logging

To disable configuration logging, use the following command:

disable cli-config-logging

CLI configuration logging is enabled by default.

Configuring and Monitoring Flow Statistics

NOTE This section describes the process of configuring and monitoring flow statistics on Ethernet links. If you plan to configure and monitor flow statistics on PoS links, see the Packet Over SONET Installation and User Guide for more information. The broad growth in Internet and intranet usage has brought with it an increased demand for network bandwidth and performance that is based on predictable quality of service and security. This movement is paralleled by the related need for measurement technology that makes it possible to gather, analyze, and manipulate information about network and application use. NetFlow, originally developed by Cisco, provides a way for a switch to capture and export traffic classification or precedence information as data traverses, or flows, across portions of a network. A network flow is defined as a unidirectional sequence of packets between a particular source device and destination device that share the same protocol and transport-layer information. Flows are defined by the following fields: source IP address, destination IP address, source port, destination port, and protocol type. Per-flow statistics are useful for many management purposes, including: Accounting and billing Network capacity planning and trend analysis Network monitoring Workload characterization User profiling Data warehousing and mining

212

ExtremeWare 7.1.0 Software User Guide

Configuring and Monitoring Flow Statistics

Flow Statistics Background Information

Per-flow statistics are exported in the NetFlow Version 1 record format described in Table 30. NetFlow records are unidirectional in nature, which implies that two flow records are maintained for a typical TCP connection: one record for flow in the ingress direction; a second for the flow in the egress direction. Also, records are maintained only for TCP and UDP flows.

Table 30: NetFlow Version 1 Record Format

Field Name srcaddr dstaddr nexthop input output dPkts dOctets First Last srcport dstport pad prot tos tcp_flags pad Octets 4 4 4 2 2 4 4 4 4 2 2 2 1 1 1 7 Field Description Source IP address. Destination IP address. IP address of next-hop router; set to zero for per-flow statistics; set to xFFFF for filter-based aggregated statistics. (Not supported.) Input interface index. (Not supported.) Output interface index. Number of packets sent in this flow. (Not Supported.) Number of octets sent in this flow. (Not supported.) SysUptime when flow record was created. (Not supported.) SysUptime at most-recent, or last packet of flow. Source port number, valid only for TCP and UDP flows. Destination port number, valid only for TCP and UDP flows. Unused field. Number identifying the IP protocol; for example, 6=TCP and 17=UDP. (Not supported.) IP Type-of-Service (TOS) field value from initial packet that caused this flow record to be created. (Not supported.) Cumulative OR of TCP flags field, valid only when prot=6. Unused field.

Flow records are grouped together into UDP datagrams for export to a flow-collector device. A NetFlow Version 1 export datagram can contain up to 25 flow records. Figure 26 shows the format of the export datagram; Table 31 describes the export datagram header. Figure 26: Format of NetFlow export datagram

octets

16 Header

48 Flow record 1

48 Flow record 2 . . .

48 Flow record 25
EW_086

ExtremeWare 7.1.0 Software User Guide

213

Status Monitoring and Statistics

Table 31: Format of NetFlow Version 1 Export Datagram Header

Field Name version count SysUptime unix_secs unix_nsecs Octets 2 2 4 4 4 Field Description Header version=1. Number of flow records in datagram. Current time in milliseconds since the switch booted. (Not Supported.) Current count of seconds since 0000 UTC 1970. (Not Supported.) Current count of residual nanoseconds since 0000 UTV 1970.

The IP addresses (or host names) and UDP port numbers of the available flow collectors can be configured on a per-switch basis. The flow collection architecture example in Figure 27 illustrates how multiple BlackDiamond switches might export flow records to flow-collector devices that, in turn, feed records into a central collector-server. Other flow-collector architectures are also possible. For example, each switch port configured for flow switching might export statistics to a dedicated flow-collector device. Figure 27: NetFlow Collection Architecture Example

Accounting/ billing

Profiling

User-specific applications Network planning

Centralized collector-server
Summarized data

Flow-collector device
UDP NetFlow NetFlow

Flow-collector device
UDP NetFlow NetFlow

Black Diamond

Black Diamond

Black Diamond

Black Diamond

PoS_024

The ExtremeWare NetFlow implementation also enables a single port to distribute statistics across multiple groups of flow-collector devices. This NetFlow distribution feature enables a scalable collection architecture that is able to accommodate high volumes of exported data. The NetFlow distribution feature is enabled by configuring export distribution groups that contain the addresses of multiple flow-collector devices. The feature uses a distribution algorithm that ensures all of the records for a

214

ExtremeWare 7.1.0 Software User Guide

Configuring and Monitoring Flow Statistics

given flow are exported to the same collector. The algorithm also ensures that the flow records of the ingress direction of a TCP or UDP connection are exported to the same collector. (For Ethernet applications, only ingress traffic is monitored on Ethernet ports.) For example, multiple filters can be assigned to a set of ports for the same group. The flow records that match the filters are then sent to one of the flow collector devices in that group. You can also establish redundancy by configuring multiple flow collector devices per group so that data is still collected as long as there is one working flow collector device in that group. To implement flow-collector devices, you can choose from commercial software products and public-domain software packages.

Collection Port and Filtering Options

By default, each Ethernet port configured for flow switching maintains statistics for all the flows traversing the link in the ingress direction. Generalized filtering options exist that enable you to configure an Ethernet port to maintain statistics selectively for only those flows that match a specified filter. For example, to monitor aggregated flow records on Ethernet ports, you could configure an aggregation filter that specifies a range of IP addresses or ports. Up to eight filters are supported for each Ethernet port, with a total of 128 filters possible per each I/O module. The filters consist of a {value, mask} pair for each of the following flow components: destination IP address, source IP address, destination port, source port, and protocol. Conceptually, the filters work by logically ANDing the contents of each of these five components of a forwarded flow with the associated masks from the first filter. Statistics are maintained if the results of the AND operations match the configured filter values for all fields of the five flow components. If there is not a match on all fields of the five components, then the operation is repeated for the second filter, and so on. If there is no match for any of the filters, then statistics are not maintained for the flow.

Collection Architecture Scalability and Reliability

By supporting statistics distribution across groups of flow-collector devices, the NetFlow distribution function enables a scalable collection architecture that is able to accommodate high volumes of exported data. The function also includes a health-check feature that significantly improves the reliability of the collection architecture. The health-checker ensures that only responsive flow-collector devices are included in the effective export distribution lists. Up to 32 export distribution groups can be configured on a Black Diamond 6800 series switch. Each of these groups can contain the addresses of up to eight flow-collector devices. A particular export group can then be specified for each filter, which provides a high-degree of flexibility. A filter-based aggregation capability is also offered to further enhance scalability. Each filter can be configured to be either a per-flow filter or an aggregation filter. When a flow matches a filter that is configured as an aggregation, normal per-flow statistics are not maintained for the flow. Instead, a single set of statistics is maintained for all the flows that match the aggregation filter, which can substantially reduce the volume of exported data. Aggregated flow statistics are also exported in the NetFlow Version 1 format. The srcaddr, dstaddr, srcport, dstport, and prot fields of an aggregated flow record are set to the corresponding value components of the associated filter specification.

ExtremeWare 7.1.0 Software User Guide

215

Status Monitoring and Statistics

Export Criteria
For Ethernet ports, flow records are exported on an age basis. If the age of the flow is greater than a configurable time, the record is exported. An Ethernet port configured for flow switching transmits a NetFlow Export Datagram when 25 flow records are ready for export, or when at least one flow has been awaiting export for one second. An Ethernet port configured for capturing flows transmits NetFlow export datagrams when the configured time-out expires and exports the data collected by the flow filters configured on that port. As the NetFlow on Ethernet links is modeled as port-based, individual ports maintain their configured time-outs and export the flows collected by the configured flow filters on the expiry of flow export time-out.

Enabling and Disabling the Flow Statistics Feature on a Switch

To enable the flow statistics feature on a switch, use the following command:
enable flowstats

The flow statistics feature is disabled by default. To disable the flow statistics feature on a switch, use the following command:
disable flowstats

Enabling and Disabling Flow Statistics on a Port

To enable the flow statistics function on the specified port, use the following command:
enable flowstats ports <portlist>

The flow statistics function is disabled by default. To disable the flow statistics function on the specified port, use the following command:
disable flowstats ports <portlist>

Configuring the Export Destination

A single port can distribute statistics across multiple groups of flow-collector devices. This NetFlow distribution capability makes it possible to create a collection architecture that scales to accommodate high volumes of exported data. It also offers a health-checking function that improves the reliability of the collection architecture by ensuring that only responsive flow-collector devices are included in active export distribution lists. The distribution algorithm also ensures that all the ingress flow records for a given flow are exported to the same collector. NetFlow distribution is enabled by configuring export distribution groups that identify the addresses of multiple flow-collector devices. You can configure up to 32 export distribution groups on a BlackDiamond 6800 series switch, and each group can contain as many as eight flow-collector devices. To configure the export groups and flow-collector devices to which NetFlow datagrams are exported, use the following command:
configure flowstats export <group#> [add | delete] [<ipaddress> | <hostname>] <udp_port>

216

ExtremeWare 7.1.0 Software User Guide

Configuring and Monitoring Flow Statistics

The group# parameter is an integer in the range from 1 through 32 that identifies the specific group for which the destination is being configured. You can use the add and delete keywords to add or delete flow-collector destinations. To export NetFlow datagrams to a group, you must configure at least one flow-collector destination. By default, no flow-collector destinations are configured. To configure a flow-collector destination, use either an IP address and UDP port number pair or a hostname and UDP port number pair to identify the flow-collector device to which NetFlow export datagrams are to be transmitted. You can configure up to eight flow-collector destinations for each group. When multiple flow-collectors are configured as members of the same group, the exported NetFlow datagrams are distributed across the available destinations.

Configuring the Source IP Address

To configure the IP address that is to be used as the source IP address for NetFlow datagrams to be exported, use the following command:
configure flowstats source ipaddress <ipaddress>

By default, flow records are exported with the VLAN interface address that has a route to the configured flow-collector device. Depending on how it is configured, a flow-collector device can use the source IP address of received NetFlow datagrams to identify the switch that sent the information. The following command example specifies that the IP address 192.168.100.1 is to be used as the source IP address for exported NetFlow datagrams.
configure flowstats source ipaddress 192.168.100.1

Configuring Flow Record Time-out

Flow records are exported on an age basis. If the age of the flow record is greater than the configured time-out, the record is exported. To configure the time-out value for flow records on the specified port, use the following command:
configure flowstats timeout <minutes> ports [<portlist> | all]

The time-out value is the number of minutes to use in deciding when to export flow records. The default time-out is 5 minutes. The following command example specifies a 10-minute time-out for exported NetFlow datagrams on port 1 of the Ethernet module installed in slot 8 of the BlackDiamond switch.
configure flowstats timeout 10 ports 8:1

Configuring a Flow Record Filter

You can configure an Ethernet port to maintain statistics selectively for only those flows that match a specified filter. Each Ethernet port supports eight filters for ingress flows. To configure a flow record filter for the specified Ethernet port, use the following command:
configure flowstats filter <filter#> {aggregation} {export <group#>} ports <portlist> [ingress | egress] <filterspec>

ExtremeWare 7.1.0 Software User Guide

217

Status Monitoring and Statistics

where:
filter# <group#> The filter# parameter is an integer in the range from 1 to 8 that identifies the filter being defined. Specifies the group number that identifies the set of flow collector devices to which records for flows matching the filter are to be exported. If Group is not specified, then group # 1 will be used as default export group. To reduce the volume of exported data, use this optional keyword to maintain a single set of statistics for all the flows that match the specified filter. Specifies a set of five parameters (four are value/mask pairs) that define the criteria by which a flow is evaluated to determine if it should be exported. The parameters are: [{dest-ip <ipaddress_value/mask ipaddress_filtermask>} {source-ip <ipaddress_value/mask ipaddress_filtermask>} {dest-port <port_value/port_filtermask>} {source-port <port_value/port_filtermask>} {protocol <tcp/udp/ip/protocol_value/protocol_filtermask>} | match-all-flows |match-no-flows] All five specifications must be included in the order specified. The range for port/port_mask is calculated using the following formula: (minport = port, maxport = 2^(32-port_mask)-1). Conceptually, the filters work by ANDing the contents of each of the five components of a forwarded flow with the associated masks from the first defined filter (filter #1). Statistics are maintained if the results of the AND operations match the configured filter values for all fields of the sequence. If there is no match, then the operation is repeated for filter #2, and so on. If there is no match for any of the filters, then statistics are not maintained for the flow. Filters for any or all of the sequence components can be configured with a single command. match-all-flows match-no-flows egress ingress Specifies that the filter should match any flow. Specifies that the filter should discard all flow. This option is not valid for Ethernet blades. Specifies that the filter should capture only egress traffic. This option is not valid for Ethernet blades. Specifies that the filter should capture only ingress traffic.

aggregation filterspec

The following command example configures a filter to collect aggregate statistics for all traffic flowing through ports 1-8 from the 192.170.0.0/16 subnet to the 192.171.132.0/24 subnet:
configure flowstats filter 2 aggregation export 1 ports 1-8 ingress dest-ip 192.171.132.0/24 source-ip 192.170.0.0/16 dest-port 0/0 source-port 0/0 protocol ip

Likewise, the following command example configures a filter to collect aggregate statistics for all ingress traffic flowing from the 192.171.0.0/16 subnet to the 192.170.0.0/16 subnet and export the flows to group 3 for ports 6:1, 7:9, and 8:42
configure flowstats filter 2 aggregation export 3 ports 6:1,7:9,8:42 ingress dest-ip 192.170.0.0/16 source-ip 192.171.0.0/16 dest-port 0/0 source-port 0/0 protocol ip

Finally, the following command configures filter 3 to collect statistics on any flows for ports 4-32 that did not match the filters defined in the two previous commands:
configure flowstats filter 3 aggregation export 1 ports 4-32 ingress match-all-flows

218

ExtremeWare 7.1.0 Software User Guide

Configuring and Monitoring Flow Statistics

Enabling and Disabling a Flow Record Filter

To enable a specified flow record filter for the specified Ethernet port, use the following command:
enable flowstats filter <filter#> ports <portlist> {egress | ingress}

By default, all filters are enabled after they are configured. To disable a specified flow record filter for the specified Ethernet port, use the following command:
disable flowstats filter <filter#> ports <portlist> {egress | ingress}

where:
filter# The filter# parameter is an integer in the range from 1 to 8 that identifies the filter that is being enabled or disabled.

NOTE Ethernet blades can capture ingress traffic only. The following command example enables filter #2 on port 1 of the Ethernet module installed in slot 8 of the BlackDiamond switch.
enable flowstats filter 2 ports 8:1

The following command example disables filter #2 on port 1 of the Ethernet module installed in slot 8 of the BlackDiamond switch.
disable flowstats filter 2 ports 8:1

Enabling and Disabling Flow Statistics Ping-Check

To enable the flow statistics ping-check function for a specified group of collector devices, use the following command:
enable flowstats ping-check {<group#>}

The ping-check function is disabled by default. The group identifier is option. Not specifying a group identifier selects all groups. When the ping-check function is enabled, each of the flow collector devices is pinged periodically to check its network connectivity. If a flow collector device is repetitively unresponsive, it is temporarily removed from the export distribution list for that group. The flow collector device will be returned to the export distribution list automatically when subsequent ping checks are consistently successful. The following command example enables the ping-check function for export group 2.
enable flowstats ping-check 2

To disable the flow statistics ping-check function for a specified group of collector devices, use the following command:
disable flowstats ping-check {<group#> | all}

The following command example disables the ping-check function for export group 2.
disable flowstats ping-check 2

ExtremeWare 7.1.0 Software User Guide

219

Status Monitoring and Statistics

Unconfiguring Flow Statistics

To reset the flow statistics configuration parameters for a specified Ethernet port to their default values, use the following command:
unconfigure flowstats all]} {filter <filter#> ports <portlist>} | {ports [<portlist> |

NOTE This command does not affect the enabled or disabled status of flow statistics collection, nor does it affect the configured export destinations. The following command example resets the flow statistics configuration parameters for port 1 of the module installed in slot 8 of the BlackDiamond switch to their default values.
unconfigure flowstats ports 8:1

Displaying Flow Statistics Status Information

To display status information for the flow statistics function, use the following command:
show flowstats {<portlist> | export {<group#>} {detail}}

where:
detail group# portlist Use this optional keyword to display detailed NetFlow configuration information. Use this optional parameter with the group keyword to display status information for a specific export group. Use this optional parameter to specify one or more ports or slots and ports for which status information is to be displayed.

If you enter the show flowstats command with none of the optional keywords or parameters, the command displays a summary of status information for all ports. The summary status display for a port shows the values for all flow statistics configuration parameters for the port. The summary status display for an export group includes the following information: Values for all configuration parameters Status of each export destination device An example of show flowstats output is shown below:
# show flowstats Flowstats enabled Port Filter proto timeout group OverflowPkts flags -------------------------------------------------------------------------1:1 1 5 1 N/A EIA Dest/Src Info: match-all-flows Flags: E - Enable, D - Disable; I - Ingress, S - Egress; A - Aggregation

The detailed status display for an export group includes the summary information, plus the following management information:

220

ExtremeWare 7.1.0 Software User Guide

RMON

Counts of the number of times each flow collector destination has been taken out of service due to health-check (ping check) failures The source IP address configuration information

RMON
Using the Remote Monitoring (RMON) capabilities of the switch allows network administrators to improve system efficiency and reduce the load on the network. The following sections explain more about the RMON concept and the RMON features supported by the switch.

NOTE You can only use the RMON features of the system if you have an RMON management application, and have enabled RMON on the switch.

About RMON
RMON is the common abbreviation for the Remote Monitoring Management Information Base (MIB) system defined by the Internet Engineering Task Force (IETF) documents RFC 1271 and RFC 1757, which allows you to monitor LANs remotely. A typical RMON setup consists of the following two components: RMON probeAn intelligent, remotely controlled device or software agent that continually collects statistics about a LAN segment or VLAN. The probe transfers the information to a management workstation on request, or when a predefined threshold is crossed. Management workstationCommunicates with the RMON probe and collects the statistics from it. The workstation does not have to be on the same network as the probe, and can manage the probe by in-band or out-of-band connections.

RMON Features of the Switch

The IETF defines nine groups of Ethernet RMON statistics. The switch supports the following four of these groups: Statistics History Alarms Events This section describes these groups and discusses how they can be used.

Statistics
The RMON Ethernet Statistics group provides traffic and error statistics showing packets, bytes, broadcasts, multicasts, and errors on a LAN segment or VLAN.

ExtremeWare 7.1.0 Software User Guide

221

Status Monitoring and Statistics

Information from the Statistics group is used to detect changes in traffic and error patterns in critical areas of the network.

History
The History group provides historical views of network performance by taking periodic samples of the counters supplied by the Statistics group. The group features user-defined sample intervals and bucket counters for complete customization of trend analysis. The group is useful for analysis of traffic patterns and trends on a LAN segment or VLAN, and to establish baseline information indicating normal operating parameters.

Alarms
The Alarms group provides a versatile, general mechanism for setting threshold and sampling intervals to generate events on any RMON variable. Both rising and falling thresholds are supported, and thresholds can be on the absolute value of a variable or its delta value. In addition, alarm thresholds can be autocalibrated or set manually. Alarms inform you of a network performance problem and can trigger automated action responses through the Events group.

Events
The Events group creates entries in an event log and/or sends SNMP traps to the management workstation. An event is triggered by an RMON alarm. The action taken can be configured to ignore it, to log the event, to send an SNMP trap to the receivers listed in the trap receiver table, or to both log and send a trap. The RMON traps are defined in RFC 1757 for rising and falling thresholds. Effective use of the Events group saves you time. Rather than having to watch real-time graphs for important occurrences, you can depend on the Event group for notification. Through the SNMP traps, events can trigger other actions, which provides a mechanism for an automated response to certain occurrences.

Configuring RMON
RMON requires one probe per LAN segment, and standalone RMON probes traditionally have been expensive. Therefore, Extremes approach has been to build an inexpensive RMON probe into the agent of each system. This allows RMON to be widely deployed around the network without costing more than traditional network management. The switch accurately maintains RMON statistics at the maximum line rate of all of its ports. For example, statistics can be related to individual ports. Also, because a probe must be able to see all traffic, a stand-alone probe must be attached to a nonsecure port. Implementing RMON in the switch means that all ports can have security features enabled. To enable or disable the collection of RMON statistics on the switch, use the following command:
[enable | disable] rmon

By default, RMON is disabled. However, even in the disabled state, the switch responds to RMON queries and sets for alarms and events. By enabling RMON, the switch begins the processes necessary for collecting switch statistics.

222

ExtremeWare 7.1.0 Software User Guide

RMON

Event Actions
The actions that you can define for each alarm are shown in Table 32. Table 32: Event Actions
Action No action Notify only Notify and log Send trap to all trap receivers. Send trap; place entry in RMON log. High Threshold

To be notified of events using SNMP traps, you must configure one or more trap receivers, as described in Chapter 3.

ExtremeWare 7.1.0 Software User Guide

223

Status Monitoring and Statistics

224

ExtremeWare 7.1.0 Software User Guide

11 Security

This chapter describes the following topics: Security Overview on page 225 Network Access Security on page 225 MAC-Based VLANs on page 226 IP Access Lists (ACLs) on page 226 MAC Address Security on page 233 Network Login on page 236 Switch Protection on page 245 Routing Access Profiles on page 245 Route Maps on page 255 Denial of Service Protection on page 260 Management Access Security on page 263 Authenticating Users Using RADIUS or TACACS+ on page 263 Secure Shell 2 (SSH2) on page 270

Security Overview
Extreme Networks products incorporate a number of features designed to enhance the security of your network. No one feature can insure security, but by using a number of features in concert, you can substantially improve the security of your network. The features described in this chapter are part of an overall approach to network security

Network Access Security

Network access security features control devices accessing your network. In this category are the following features: MAC-Based VLANs IP Access Lists (ACLs)

ExtremeWare 7.1.0 Software User Guide

225

Security

MAC Address Security Network Login

MAC-Based VLANs
MAC-Based VLANs allow physical ports to be mapped to a VLAN based on the source MAC address learned in the FDB. This feature allows you to designate a set of ports that have their VLAN membership dynamically determined by the MAC address of the end station that plugs into the physical port. You can configure the source MAC address-to-VLAN mapping either offline or dynamically on the switch. For example, you could use this application for a roaming user who wants to connect to a network from a conference room. In each room, the user plugs into one of the designated ports on the switch and is mapped to the appropriate VLAN. Connectivity is maintained to the network with all of the benefits of the configured VLAN in terms of QoS, routing, and protocol support. Detailed information about configuring and using MAC-based VLANs can be found in Chapter 5.

IP Access Lists (ACLs)

IP access lists consist of IP access rules and are used to perform packet filtering and forwarding decisions on incoming traffic. Each packet arriving on an ingress port is compared to the access list in sequential order and is either forwarded to a specified QoS profile or dropped. Using access lists has no impact on switch performance. Access lists are typically applied to traffic that crosses layer 3 router boundaries, but it is possible to use access lists within a layer 2 VLAN. Access lists are often referred to as Access Control Lists (ACLs).

Using IP Access Lists

Each entry that makes up an IP access list contains a unique name. It can also contain an optional, unique precedence number. The rules of an IP access list consist of a combination of the following six components: IP source address and mask IP destination address and mask TCP or UDP source port range TCP or UDP destination port range Physical source port Precedence number (optional)

How IP Access Lists Work

When a packet arrives on an ingress port, the packet is compared with the access list rules to determine a match. When a match is found, the packet is processed. If the access list is of type deny, the packet is dropped. If the list is of type permit, the packet is forwarded. A permit access list can also apply a QoS profile to the packet.

226

ExtremeWare 7.1.0 Software User Guide

IP Access Lists (ACLs)

Precedence Numbers
The precedence number is optional, and determines the order in which each rule is examined by the switch. Access list entries that contain a precedence number are evaluated from highest to lowest. Precedence numbers range from 1 to 25,600, with the number 1 having the highest precedence. You can specify overlapping rules; however, if you are using precedence numbers, overlapping rules without precedence numbers are ignored. Therefore, the precedence numbers must be specified among all overlapping rules. If a new rule without a precedence number is entered, and this rule overlaps with already existing rules, the switch rejects the new rule and resolves the precedences among all remaining overlapping rules.

IP Access Rules
There are a number of different types of IP access rules and different limits apply to each type. This section describes the different types of IP access rules, what each rule is capable of supporting, and any limitations associated with each type of rule. The switch allows a maximum total of 5,120 rules to be stored in non-volatile configuration storage. This maximum is a sum of IP and ICMP access rule entries.

ICMP Access Rules

An access list for ICMP is only effective for traffic routed by the switch. ICMP traffic can either be forwarded (routed) by the switch or discarded, but can not contain options for assigning a QoS profile. Other configuration options for filtering ICMP include: IP source and destination address and mask. ICMP type code. Physical source port (optional). Numbered precedence (optional).

Flow Redirect Policies

IP traffic can either be forwarded (routed) by the switch or redirected to another next-hop MAC address. The switch will monitor the next-hop system using system health checks and will stop forwarding traffic to a device that is down. You can configure up to 64 flow redirect rules. Flow redirect rules are stored separately and therefore are not limited by other ACLs. These rules are identified by: IP source and destination address and mask Layer 4 source port Layer 4 destination port If a flow redirect rule is specified with an IP source address mask of less than /20, the system automatically enables the subnet mode. Flow redirect rules with mask lengths greater than /20 automatically enable enumeration mode. Use the show flow-redirect command to display whether the system is in subnet mode or enumeration mode.

Netflow Record Filters

Up to eight filters are supported for each Ethernet port, with a total of 128 filters for each switch. Netflow filters share the same space as ACLs. That means that the total number of ACLs allowed is

ExtremeWare 7.1.0 Software User Guide

227

Security

limited by the number of Netflow record filters configured. For example, if 128 filters are created, the numbers of ACLs allowed decreases by 128.

Specifying a Default Rule

To begin constructing an access list, you should specify a default rule. A default rule is a rule that contains wildcards for destination and source IP address, with no layer 4 information. A default rule determines if the behavior of the access list is an implicit deny or implicit accept. If no access list entry is satisfied, the default rule is used to determine whether the packet is forwarded or dropped. If no default rule is specified, the default implicit behavior is to forward the packet. The following example shows a default entry that is used to specify an explicit deny:
create access-list denyall ip dest 0.0.0.0/0 source 0.0.0.0/0 deny ports any

Once the default behavior of the access list is established, you can create additional entries using precedence numbers. The following access-list example performs packet filtering in the following sequence, as determined by the precedence number: Deny UDP port 32 and TCP port 23 traffic to the 10.2.XX network. All other TCP port 23 traffic destined for other 10.X.X.X networks is permitted using QoS profile Qp4. All remaining traffic to 10.2.0.0 uses QoS profile Qp3. With no default rule specified, all remaining traffic is allowed using the default QoS profile.
create access-list deny102_32 udp dest 10.2.0.0/16 ip-port 32 source any ip-port any deny ports any precedence 10 create access-list deny102_23 tcp dest 10.2.0.0/16 ip-port 23 source any ip-port any deny ports any precedence 20 create access-list allow10_23 tcp dest 10.0.0.0/8 ip-port 23 source any ip-port any permit qosprofile qp4 ports any precedence 30 create access-list allow102 ip dest 10.2.0.0/16 source 0.0.0.0/0 permit qosprofile qp3 ports any precedence 40

The permit-established Keyword

The permit-established keyword is used to directionally control attempts to open a TCP session. The permit-established keyword denies all traffic that matches the TCP source/destination, and has the SYN=1 and ACK=0 flags set. Thus, TCP session initiation can be explicitly blocked using this keyword. Traffic from TCP sessions that are already established continue to be permitted.

NOTE For an example of using the permit-established keyword, see Using the Permit-Established Keyword on page 230.

228

ExtremeWare 7.1.0 Software User Guide

IP Access Lists (ACLs)

Adding and Deleting Access List Entries

Entries can be added and deleted to the access list. To add an entry, you must supply a unique name and, optionally, a unique precedence number. To modify an existing entry, you must delete the entry and retype it, or create a new entry with a new unique name. To delete an access list entry, use the following command:
delete access-list <name>

Maximum Entries
A maximum of 255 entries with an assigned precedence can be used. In addition to the 255 entries, entries that do not use precedence can also be created, with the following restrictions: A source IP address must use wildcards or a completely specified mask. The layer 4 source and destination ports must use wildcards or be completely specified (no ranges). No physical source port can be specified. Access list rules that apply to all physical ports are implemented on all BlackDiamond I/O modules. On a BlackDiamond switch, the maximum number of access list entries is 255 entries per I/O module. One way to economize on the number of entries on a BlackDiamond switch is to provide a physical ingress port as a component of an access list rule. In this case, the rule is implemented only on the I/O modules that contain the specified ports. By restricting rules to specific I/O modules, you can extend the number of access list rules to 5120 (NVRAM limit). On BlackDiamond switches, there is a resource on each i series I/O module so that the total maximum number of ACL entries can be up to 4080 (255*16). Each ACL must specify an ingress physical port specific to a single I/O module to avoid using those resources on any other module. On Alpine switches, a maximum of 255 ACL entries are supported.

Verifying Access List Configurations

To verify access list settings, you can view the access list configuration and see real-time statistics on which access list entries are being accessed when processing traffic. To view the access list configuration and statistics screen, use the following command:
show access-list {<name> | port <portlist>}

To initiate and refresh a running display of access list statistics, use the following command:
show access-list-monitor

IP Access List Examples

This section presents two IP access list examples: Using the permit-establish keyword Filtering ICMP packets

ExtremeWare 7.1.0 Software User Guide

229

Security

Using the Permit-Established Keyword

This example uses an access list that permits TCP sessions (Telnet, FTP, and HTTP) to be established in one direction. The Summit7i, shown in Figure 28, is configured as follows: Two VLANs, NET10 VLAN and NET20 VLAN, are defined. The IP addresses for NET10 VLAN is 10.10.10.1/24. The IP address for NET20 VLAN is 10.10.20.1/24. The workstations are configured using addresses 10.10.10.100 and 10.10.20.100. IP Forwarding is enabled. Figure 28: Permit-established access list example topology

10.10.10.1 10.10.10.100

10.10.20.1 10.10.20.100

NET10 VLAN

NET20 VLAN
EW_033

The following sections describe the steps used to configure the example. Step 1 Deny IP Traffic. First, create an access-list that blocks all IP-related traffic. This includes any TCP- and UDP-based traffic. Although ICMP is used in conjunction with IP, it is technically not an IP data packet. Thus, ICMP data traffic, such as ping traffic, is not affected. The following command creates the access list:
create access-list denyall ip destination any source any deny ports any

Figure 29 illustrates the outcome of the access list.

230

ExtremeWare 7.1.0 Software User Guide

IP Access Lists (ACLs)

Figure 29: Access list denies all TCP and UDP traffic

10.10.10.1 10.10.10.100

10.10.20.1 10.10.20.100

NET10 VLAN

NET20 VLAN

TCP UDP ICMP

EW_034

Step 2 Allow TCP traffic. The next set of access list commands permits TCP-based traffic to flow. Because each session is bi-directional, an access list must be defined for each direction of the traffic flow. UDP traffic is still blocked. The following commands create the access list:
create access-list tcp1 tcp destination 10.10.20.100/32 ip any source 10.10.10.100/32 ip any permit qp1 ports any precedence 20 create access-list tcp2 tcp destination 10.10.10.100/32 ip any source 10.10.20.100/32 ip any permit qp1 ports any precedence 21

Figure 30 illustrates the outcome of this access list. Figure 30: Access list allows TCP traffic

TCP UDP ICMP 10.10.10.100 10.10.20.100

EW_035

Step 3 - Permit-Established Access List. When a TCP session begins, there is a three-way handshake that includes a sequence of a SYN, SYN/ACK, and ACK packets. Figure 31 shows an illustration of the handshake that occurs when host A initiates a TCP session to host B. After this sequence, actual data can be passed.

ExtremeWare 7.1.0 Software User Guide

231

Security

Figure 31: Host A initiates a TCP session to host B

SYN SYN / ACK ACK Host A Host B

EW_036

An access list that uses the permit-established keyword filters the SYN packet in one direction. Use the permit-established keyword to allow only host A to be able to establish a TCP session to host B and to prevent any TCP sessions from being initiated by host B, as illustrated in Figure 31. The syntax for this access list is as follows:
create access-list <name> tcp destination HostA ip-port 23 source HostB ip-port any permit-established ports any pre 8

NOTE This step may not be intuitive. Pay attention to the destination and source address, and the desired affect. The exact command line entry for this example is as follows:
create access-list telnet-allow tcp destination 10.10.10.100/32 ip-port 23 source any ip-port any permit-established ports any pre 8

NOTE This rule has a higher precedence than the rule tcp2. Figure 32 shows the final outcome of this access list. Figure 32: Permit-established access list filters out SYN packet to destination

SYN SYN 10.10.10.100 10.10.20.100

EW_037

Example 2: Filter ICMP Packets

This example creates an access list that filters out ping (ICMP echo) packets. ICMP echo packets are defined as type 8 code 0. The command line syntax to create this access list is as follows:
create access-list denyping icmp destination any source any type 8 code 0 deny ports any

232

ExtremeWare 7.1.0 Software User Guide

MAC Address Security

The output for this access list is shown in Figure 33. Figure 33: ICMP packets are filtered out

10.10.10.1 10.10.10.100

10.10.20.1 10.10.20.100

NET10 VLAN

NET20 VLAN

ICMP
EW_038

MAC Address Security

The switch maintains a database of all media access control (MAC) addresses received on all of its ports. It uses the information in this database to decide whether a frame should be forwarded or filtered. MAC address security allows you to control the way the Forwarding Database (FDB) is learned and populated. By managing entries in the FDB, you can block, assign priority (queues), and control packet flows on a per-address basis. MAC address security allows you to limit the number of dynamically-learned MAC addresses allowed per virtual port. You can also lock the FDB entries for a virtual port, so that the current entries will not change, and no additional addresses can be learned on the port.

NOTE You can either limit dynamic MAC FDB entries, or lock down the current MAC FDB entries, but not both. You can also prioritize or stop packet flows based on the source MAC address of the ingress VLAN or the destination MAC address of the egress VLAN.

Limiting Dynamic MAC Addresses

You can set a predefined limit on the number of dynamic MAC addresses that can participate in the network. After the FDB reaches the MAC limit, all new source MAC addresses are blackholed at both the ingress and egress points. These dynamic blackhole entries prevent the MAC addresses from learning and responding to Internet control message protocol (ICMP) and address resolution protocol (ARP) packets.

ExtremeWare 7.1.0 Software User Guide

233

Security

To limit the number of dynamic MAC addresses that can participate in the network, use the following command:
configure ports [<portlist> vlan <vlan name> | all] limit-learning <number>

This command specifies the number of dynamically-learned MAC entries allowed for these ports in this VLAN. The range is 0 to 500,000 addresses. When the learned limit is reached, all new source MAC addresses are blackholed at the ingress and egress points. This prevent these MAC addresses from learning and responding to Internet control message protocol (ICMP) and address resolution protocol (ARP) packets. Dynamically learned entries still get aged and can be cleared. If entries are cleared or aged out after the learning limit has been reached, new entries will then be able to be learned until the limit is reached again. Permanent static and permanent dynamic entries can still be added and deleted using the create fdbentry and delete fdbentry commands. These override any dynamically learned entries. For ports that have a learning limit in place, the following traffic will still flow to the port: Packets destined for permanent MAC addresses and other non-blackholed MAC addresses Broadcast traffic EDP traffic Traffic from the permanent MAC and any other non-blackholed MAC addresses will still flow from the virtual port. To remove the learning limit, use the following command:
configure ports [<portlist> vlan <vlan name> | all] unlimited-learning

To verify the configuration, use the following commands:

show vlan <vlan name> security

This command displays the MAC security information for the specified VLAN.
show ports <portlist> info detail

This command displays detailed information, including MAC security information, for the specified port.

SNMP Traps and Syslog Messages For MAC Address Limits

To generate a syslog message and an SNMP trap when the limit is reached and a new source MAC address attempts to participate in the network, use the following command:
enable snmp traps mac-security

The information generated should help detect unauthorized devices that attempt to access the network. Enabling the trap also enables the syslog; there is no separate command for that. The command is a global command; there is no per port or per VLAN control. To disable the generation of MAC address limit SNMP traps and syslog messages, use the following command:

234

ExtremeWare 7.1.0 Software User Guide

MAC Address Security

disable snmp traps mac-security

For more information about configuring SNMP and the MAC limit SNMP trap, see Using SNMP on page 61, in Chapter 3, Managing the Switch.

Limiting MAC Addresses with ESRP Enabled

If you configure a MAC address limit on VLANS that have ESRP enabled, you should add an additional back-to-back link (that has no MAC address limit on these ports) between the ESRP-enabled switches. Doing so prevents ESRP PDU from being dropped due to MAC address limit settings. Figure 34 is an example of configuring a MAC address limit on an ESRP-enabled VLAN. Figure 34: MAC address limits and ESRP-enabled VLANs

ESRP vlan S1

10.1.2.1

20.1.1.1

S2 S4
10.1.2.2

20.1.2.2 192.10.1.1

10.1.2.100

S3
10.1.2.1 30.1.1.1

30.1.1.2

192.10.1.100

EW_081

In Figure 34, S2 and S3 are ESRP-enabled switches, while S1 is an ESRP-aware (regular layer 2) switch. Configuring a MAC address limit on all S1 ports might prevent ESRP communication between S2 and S3. To resolve this, you should add a back-to-back link between S2 and S3. This link is not needed if MAC address limiting is configured only on S2 and S3, but not on S1.

MAC Address Lock Down

In contrast to limiting learning on virtual ports, you can lock down the existing dynamic FDB entries and prevent any additional learning using the following command:
configure ports [<portlist> vlan <vlan name> | all] lock-learning

This command causes all dynamic FDB entries associated with the specified VLAN and ports to be converted to locked static entries. It also sets the learning limit to zero, so that no new entries can be learned. All new source MAC addresses are blackholed. Locked entries do not get aged, but can be deleted like a regular permanent entry. For ports that have lock-down in effect, the following traffic will still flow to the port: Packets destined for the permanent MAC and other non-blackholed MAC addresses

ExtremeWare 7.1.0 Software User Guide

235

Security

Broadcast traffic EDP traffic Traffic from the permanent MAC will still flow from the virtual port. To remove MAC address lock down, use the following command:
configure ports [<portlist> vlan <vlan name> | all] unlock-learning

When you remove the lock down using the unlock-learning option, the learning-limit is reset to unlimited, and all associated entries in the FDB are flushed.

Network Login
Network Login is a feature designed to control the admission of user packets into a network by giving addresses only to users that have been properly authenticated. Network Login is controlled by an administrator on a per port, per VLAN basis. When Network Login is enabled on a port in a VLAN, that port will not forward any packets until authentication takes place. Once Network Login has been enabled on a switch port, that port is placed in a non-forwarding state until authentication takes place. To authenticate, a user (supplicant) must open a web browser and provide the appropriate credentials. These credentials are either approved, in which case the port is placed in forwarding mode, or not approved, and the port remains blocked. Three failed login attempts will disable the port for some configured length of time. The user logout can either initiated by FDB aging or by submitting a logout request. There are two choices for types of authentication to use with Network Login, web-based and 802.1x, and there are two different modes of operation, Campus mode and ISP mode. The authentication types and modes of operation can be used in any combination. The following sections describe these choices.

Web-Based and 802.1x Authentication

Authentication is handled either as a web-based process, or as described in the IEEE 802.1x specification. The initial release of Network Login by Extreme Networks supported only web-based authentication, but now supports both types of authentication. Although somewhat similar in design and purpose, web-based and 802.1x authentication of Network Login can be considered complementary, with Extreme Networks offering a smooth transition from web-based to 802.1x authentication. In fact, both web-based and 802.1x can be configured on the same switch port. 802.1x authentication currently requires software installed on the client workstation, making it less suitable for a user walk-up scenario, such as a cyber-caf or coffee shop. 802.1x authentication also requires an Extensible Authentication Protocol (EAP) capable Radius server. Web-based Network Login does not require any specific client software and can work with any HTTP compliant web browser. A workstation running Windows XP supports 802.1x natively, and does not require additional authentication software. The switch can play the role of the authentication server and authenticate based on its local database of username and password for web-based authentication, or a RADIUS server can be used as the authentication server for web-based and 802.1x authentication.

236

ExtremeWare 7.1.0 Software User Guide

Network Login

DHCP is needed for web-based network login because the underlying protocol used to carry authentication request-response is HTTP. The client needs an IP address to send and receive HTTP packets. However, before the client is authenticated, there is no connection to anywhere else except the authenticator itself. As a result, the authenticator must be furnished with a temporary DHCP server to distribute IP address. The DHCP allocation for Network Login has short time duration of 20 seconds. It is intended to perform web-based network login only. As soon as the client is authenticated, it is deprived of this address. Then it has to go to some other DHCP server in the network to obtain a permanent address, as is normally done. DHCP is not required for 802.1x, since 802.1x use only layer-2 frames (EAPOL). URL redirection (applicable to web-based mode only) is a mechanism to redirect any HTTP request to the base URL of the authenticator when the port is in unauthenticated mode. In other words when user is trying to login to the network using the browser, it will be first redirected to the Network Login page. Only after a successful login will the user be connected to the network.

Co-existence of Web-Based and 802.1x Authentication

ExtremeWare supports both web-based and 802.1x authentication. Authenticating with 802.1x does not require any additional commands besides those used for web-based mode. When a port is configured for Network Login, the port is put in unauthenticated state. It is ready to perform either type of authentication. Whether to perform web-based or 802.1x is dependent on the type of packets being received from the client. Web-based mode uses HTTP, while 802.1x uses EAPOL with an Ethertype of 0x888e. This implementation provides a smooth migration path from non-802.1x clients to 802.1x clients. The advantage of web-based mode is platform-independence. While 802.1x mode is currently supported natively only on Windows XP clients, any device with an Internet browser can perform web-based Network Login.

Comparison of Web-Based and 802.1x Authentication

Pros of 802.1x authentication: In cases where the 802.1x is natively supported, login and authentication happens transparently. Authentication happens at layer 2. Does not involve getting a temporary IP address and subsequent release of the address to a get a more permanent IP address. Allows for periodic, transparent, re-authorization of supplicants. Cons of 802.1x authentication: 802.1x native support available only on the newer operating systems like Windows XP. Needs an EAP capable RADIUS server TLS authentication method involves Public Key Infrastructure involves more administration. TTLS is still a Funk/Certicom IETF draft proposal, not a fully accepted standard but easy to deploy and administer. Pros of web-based authentication: Works with any operating system with a web browser. No need for any client side software.

ExtremeWare 7.1.0 Software User Guide

237

Security

Simpler administration based on username and password Cons of web-based authentication: Login process involves juggling with IP addresses and has to be done a outside the scope of a regular computer login, therefore it is not tied to Windows login. One has to specifically bring up a login page and initiate a login. Supplicants cannot be re-authenticated transparently. Can not be re-authenticated from the authenticator side. Does not support more secure methods of authentication

Authentication Methods
The authentication methods supported are a matter between the supplicant and the authentication server. The most commonly used methods are MD5-Challenge, Transport Layer Security (TLS) which uses Public Key Infrastructure (PKI), and strong mutual authentication and Tunneled TLS (TTLS) which is a Funk/Certicom proposal. So far, TLS represents the most secure protocol among all those mentioned. TTLS is advertised to be as strong as TLS. Both TLS and TTLS are certificate-based, which requires setting up a PKI that can issue, renew, and revoke certificates. TTLS is preferred from the ease of deployment point of view as it requires only server certificates and client can use MD5 mode of username/password authentication. You will need to refer to the documentation for your particular Radius server, and 802.1x client, if using 802.1x authentication, for information on setting up a PKI configuration.

Campus and ISP Modes

Network login has two modes of operation, Campus mode and ISP mode. Campus mode is meant for mobile users who tend to move from one port to another and connect at various locations in the network. ISP mode is meant for users who will connect through the same port and VLAN each time, as though the switch functions as an ISP. In Campus mode, the authenticated port is moved from a temporary VLAN to a permanent VLAN, which then has access to external network resources. Campus mode requires the use of a Radius server as part of the authentication process. In ISP mode, the port and VLAN remain constant. Before the supplicant is authenticated, the port is in an unauthenticated state. Once authenticated, the port will forward packets.

User Accounts
You can create two types of user accounts for authenticating Network Login users: netlogin-only enabled and netlogin-only disabled. A netlogin-only disabled user can log in using Network Login and can also access the switch using Telnet, SSH, or HTTP. A netlogin-only enabled user can only log in using Network Login and cannot access the switch using the same login. Add the following line to the RADIUS server dictionary file for netlogin-only disabled users:
Extreme:Extreme-Netlogin-Only = Disabled

Add the following line to the RADIUS server dictionary file for netlogin-only enabled users:

238

ExtremeWare 7.1.0 Software User Guide

Network Login

Extreme:Extreme-Netlogin-Only = Enabled

Interoperability Requirements
For Network Login to operate, the user (supplicant) software and the authentication server must support common authentication methods. Not all combinations will provide the appropriate functionality.

Supplicant side
On the client side, currently, the only platform that natively supports 802.1x is Windows XP, which performs MD5 and TLS. Other 802.1x clients are available that support other operating systems and support mixes of authentication methods. A Windows XP 802.1x supplicant can be authenticated as a computer or as a user. Computer authentication requires a certificate installed in the computer certificate store, and user authentication requires a certificate installed in the individual users certificate store. By default, the XP machine performs computer authentication as soon as the computer is powered on, or at link-up when no user is logged into the machine. User authentication is performed at link-up when the user is logged in. The XP machine can be configured to perform computer authentication at link-up even if user is logged in. Again, any client with a web browser can interoperate using web-based authentication.

Authentication Server side

The Radius server used for authentication has to be EAP-capable. Consider the following when choosing a Radius server: The types of authentication methods supported on Radius, as mentioned above. Need to support Vendor Specific Attributes (VSA). Some important parameters such as Extreme-Netlogin-Vlan (destination vlan for port movement after authentication) and Extreme-NetLogin-only (authorization for network login only) are brought back as VSAs. Need to support both EAP and traditional Username-Password authentication. These are used by Network Login and switch console login respectively.

Multiple supplicant support

An important enhancement over the IEEE 802.1x standard, is that ExtremeWare supports multiple clients (supplicants) to be individually authenticated on the same port. Thus it is possible for two client stations to be connected to the same port, with one being authenticated and the other not. A ports authentication state is the logical OR of the individual MAC's authentication states. In other words, a port is authenticated if any of its connected clients is authenticated. Multiple clients can be connected to a single port of authentication server through a hub or layer-2 switch. Multiple supplicants are supported in ISP mode for both web-based and 802.1x authentication. Multiple supplicants are not supported in Campus mode. Versions of ExtremeWare previous to version 7.1.0 did not support multiple supplicants.

ExtremeWare 7.1.0 Software User Guide

239

Security

The choice of web-based versus 802.1x authentication is again on a per-MAC basis. Among multiple clients on the same port, it is possible that some clients use web-based mode to authenticate, and some others use 802.1x. There are certain restrictions for multiple supplicant support: Web-based mode will not support Campus mode for multiple supplicant because once the first MAC gets authenticated, the port is moved to a different VLAN and therefore other unauthenticated clients (which are still in the original VLAN), cant have a layer 3 message transactions with the authentication server. Once the first MAC gets authenticated, the port is transitioned to the authenticated state and other unauthenticated MACs can listen to all data destined to first MAC. This could raise some security concerns as unauthenticated MACs can listen to all broadcast and multicast traffic directed to a Network Login-authenticated port.

Exclusions and Limitations

The following are limitations and exclusions for Network Login: All unauthenticated MACs will be seeing broadcasts and multicasts sent to the port if even a single MAC is authenticated on that port. Network Login must be disabled on a port before that port can be deleted from a VLAN. In Campus mode, once the port moves to the destination VLAN, the original VLAN for that port is not displayed. A Network Login VLAN port should be an untagged Ethernet port and should not be a part of following protocols: ESRP STP VLAN Aggregation VLAN Translation Network Login is not supported for T1, E1, T3, ATM, PoS and MPLS TLS interfaces. No Hitless Failover support has been added for Network Login. Rate-limiting is not supported on Network Login ports (both web-based and 802.1x). Network Login and MAC-limits cannot be used together on the same switch (see MAC Address Security on page 233). EAP-NAK cannot be used to negotiate 802.1x authentication types.

Configuring Network Login

In the following configuration example shows both the Extreme Networks switch configuration, and the Radius server entries needed to support the example. VLAN corp is assumed to be a corporate subnet which has connections to DNS, WINS servers etc. and network routers. VLAN temp is a temporary VLAN and is created to provide connections to unauthenticated Network Login clients. This kind of configuration provides better security as unauthenticated clients do not connect to the corporate subnet and will not be able to send or receive any data. They have to get authenticated in order to have access to the network.

240

ExtremeWare 7.1.0 Software User Guide

Network Login

ISP Mode: Network Login clients connected to ports 1:10 - 1:14, VLAN corp, will be logged into the network in ISP mode. This is controlled by the fact that the VLAN in which they reside in unauthenticated mode and the RADIUS server Vendor Specific Attributes (VSA), Extreme-Netlogin-Vlan, are the same, corp. So there will be no port movement. Also if this VSA is missing from RADIUS server, it is assumed to be ISP Mode. Campus Mode: On the other hand, clients connected to ports 4:1 - 4:4, VLAN temp, will be logged into the network in Campus mode, since the port will move to the VLAN corp after getting authenticated. A port moves back and forth from one VLAN to the other as its authentication state changes. Both ISP and Campus mode are not tied to ports but to a user profile. In other words if the VSA
Extreme:Extreme-Netlogin-Vlan represents a VLAN different from the one in which user currently

resides, then VLAN movement will occur after login and after logout. In following example, it is assumed that campus users are connected to ports 4:1-4:4, while ISP users are logged in through ports 1:10-1:14.

NOTE In the following sample configuration, any lines marked (Default) represent default settings and do not need to be explicitly configured.
create vlan "temp" create vlan "corp" # Configuration information for VLAN temp. # No VLAN-ID is associated with VLAN temp. configure vlan "temp" protocol "ANY" (Default) configure vlan "temp" qosprofile "QP1" (Default) configure vlan temp qosprofile ingress IQP1 (Default) configure vlan "temp" ipaddress 198.162.32.10 255.255.255.0 configure vlan "temp" add port 4:1 untagged configure vlan "temp" add port 4:2 untagged configure vlan "temp" add port 4:3 untagged configure vlan "temp" add port 4:4 untagged # Configuration information for VLAN corp. # No VLAN-ID is associated with VLAN corp. configure vlan "corp" protocol "ANY" (Default) configure vlan "corp" qosprofile "QP1" (Default) configure vlan corp qosprofile ingress IQP1 (Default) configure vlan "corp" ipaddress 10.203.0.224 255.255.255.0 configure vlan "corp" add port 1:10 untagged configure vlan "corp" add port 1:11 untagged configure vlan "corp" add port 1:12 untagged configure vlan "corp" add port 1:13 untagged configure vlan "corp" add port 1:14 untagged # Network Login Configuration configure vlan temp dhcp-address-range 198.162.32.20 - 198.162.32.80 configure vlan temp dhcp-options default-gateway 198.162.32.1 configure vlan temp dhcp-options dns-server 10.0.1.1 configure vlan temp dhcp-options wins-server 10.0.1.85 enable netlogin port 1:10 vlan corp enable netlogin port 1:11 vlan corp

ExtremeWare 7.1.0 Software User Guide

241

Security

enable netlogin port 1:12 vlan corp enable netlogin port 1:13 vlan corp enable netlogin port 1:14 vlan corp enable netlogin port 4:1 vlan temp enable netlogin port 4:2 vlan temp enable netlogin port 4:3 vlan temp enable netlogin port 4:4 vlan temp config netlogin base-url "network-access.net" (Default) config netlogin redirect-page http://www.extremenetworks.com (Default) enable netlogin logout-privilege (Default) disable netlogin Session-Refresh 3 (Default) # DNS Client Configuration configure dns-client add name-server 10.0.1.1 configure dns-client add name-server 10.0.1.85

The following is a sample of the settings for the Radius server:

#RADIUS server setting (VSAs)(optional) session-Timeout = 60 (timeout for web-based or 802.1x reauthentication) Extreme:Extreme-Netlogin-Only = Enabled (if no CLI authorization) Extreme:Extreme-Netlogin-Vlan = "corp" (destination vlan for CAMPUS mode network login)

Web-Based Authentication User Login Using Campus Mode

When web-based authentication is used in Campus mode, the user will follow these steps: 1 Set up the Windows IP configuration for DHCP. 2 Plug into the port that has network login enabled. 3 Log in to Windows. 4 Release any old IP settings and renew the DHCP lease. This is done differently depending on the version of Windows the user is running: Windows 9xuse the winipcfg tool. Choose the Ethernet adapter that is connected to the port on which network login is enabled. Use the buttons to release the IP configuration and renew the DHCP lease. Windows NT/2000use the ipconfig command line utility. Use the command ipconfig/release to release the IP configuration and ipconfig/renew to get the temporary IP address from the switch. If you have more than one Ethernet adapter, specify the adapter by using a number for the adapter following the ipconfig command. You can find the adapter number using the command ipconfig/all. At this point, the client will have its temporary IP address. In this example, the client should have obtained the an IP address in the range 198.162.32.20 - 198.162.32.80.

NOTE The idea of explicit release/renew is required to bring the network login client machine in the same subnet as the connected VLAN. In Campus Mode using web-based authentication, this requirement is mandatory after every logout and before login again as the port moves back and forth between the

242

ExtremeWare 7.1.0 Software User Guide

Network Login

temporary and permanent VLANs. On other hand in ISP Mode, release/renew of IP address is not required, as the network login client machine stays in the same subnet as the network login VLAN. In ISP mode, when the network login client connects for the first time, it has to make sure that the machine IP address is in the same subnet as the VLAN to which it is connected. 5 Bring up the browser and enter any URL as http://www.123.net or http://1.2.3.4 or switch IP address as http://<IP address>/login (where IP address could be either temporary or Permanent VLAN Interface for Campus Mode). URL redirection redirects any URL and IP address to the network login page This is significant where security matters most, as no knowledge of VLAN interfaces is required to be provided to network login users, as they can login using a URL or IP address. A page opens with a link for Network Login. 6 Click the Network Login link. A dialog box opens requesting a username and password. 7 Enter the username and password configured on the RADIUS server. After the user has successfully logged in, the user will be redirected to the URL configured on the RADIUS server. During the user login process, the following takes place: Authentication is done through the RADIUS server. After successful authentication, the connection information configured on the RADIUS server is returned to the switch: the permanent VLAN the URL to be redirected to (optional) the URL description (optional) The port is moved to the permanent VLAN. You can verify this using the show vlan command. For more information on the show vlan command, see Displaying VLAN Settings on page 108. After a successful login has been achieved, there are several ways that a port can return to a non-authenticated, non-forwarding state: The user successfully logs out using the logout web browser window. The link from the user to the switchs port is lost. There is no activity on the port for 20 minutes. An administrator changes the port state. NOTE Because network login is sensitive to state changes during the authentication process, Extreme Networks recommends that you do not log out until the login process is complete. The login process is complete when you receive a permanent address.

DHCP Server on the Switch

A DHCP server with limited configuration capabilities is included in the switch to provide IP addresses to clients.

ExtremeWare 7.1.0 Software User Guide

243

Security

DHCP is enabled on a per port, per VLAN basis. To enable or disable DHCP on a port in a VLAN, use one of the following commands:
enable dhcp ports <portlist> vlan <vlan name> disable dhcp ports <portlist> vlan <vlan name> configure vlan <vlan name> netlogin-lease-timer <seconds>

Displaying DHCP Information

To display the DHCP configuration, including the DHCP range, DHCP lease timer, network login lease timer, DHCP-enabled ports, IP address, MAC address, and time assigned to each end device, use the following command:
show vlan <vlan name> [dhcp-address-allocation | dhcp-config]

Displaying Network Login Settings

To display the network login settings, use the following command:
show netlogin {ports <portlist> vlan <vlan name>}

Disabling Network Login

Network login must be disabled on a port before you can delete a VLAN that contains that port. To disable network login, use the following command:
disable netlogin ports <portlist> vlan <vlan name>

Additional Configuration Details

This section discussed additional configuration like switch DNS name, default redirect page, session refresh and logout-privilege. URL redirection requires the switch to be assigned a DNS name. The default name is network-access.net. Any DNS query coming to the switch to resolve switch DNS name in unauthenticated mode is resolved by the DNS server on the switch in terms of the interface (to which the network login port is connected to) IP-address. To configure the network login base URL, use the following command:
configure netlogin base-url <url>

Where <url> is the DNS name of the switch. For example, configure netlogin base-url network-access.net makes the switch send DNS responses back to the netlogin clients when a DNS query is made for network-access.net. To configure the network login redirect page, use the following command:
configure netlogin redirect-page <url>

Where <url> defines the redirection information for the users once logged in. This redirection information is used only in case the redirection info is missing from RADIUS server. For example, configure netlogin base-url http://www.extremenetworks.com redirects all users to this URL after they get logged in. To enable or disable the network login session refresh, use the following command:
[enable | disable] netlogin session-refresh {<minutes>}

244

ExtremeWare 7.1.0 Software User Guide

Switch Protection

Where <minutes> ranges from 1 - 255. The default setting is 3 minutes. Enable netlogin session-refresh makes the logout window refresh itself at every configured time interval. Session -refresh is disabled by default. When you configure the Network Login session refresh for the logout window on a BlackDiamond, ensure that the FDB aging timer is greater than the Network Login session refresh timer. To enable or disable network login logout privilege, use the following command:
[enable | disable] netlogin logout-privilege

This command turns the privilege for netlogin users to logout by popping up (or not popping up) the logout window. Logout-privilege is enabled by default. To enable or disable network login, use the following command:
[enable | disable] netlogin [web-based | dot1x]

By default netlogin is enabled. To show all network login parameters, use the following command:
show netlogin

Switch Protection
Switch protection features enhance the robustness of switch performance. In this category are the following features: Routing Access Profiles Route Maps Denial of Service Protection

Routing Access Profiles

Routing access profiles are used to control the advertisement or recognition of routing protocols, such as RIP, OSPF, IS-IS, or BGP. Routing access profiles can be used to hide entire networks, or to trust only specific sources for routes or ranges of routes. The capabilities of routing access profiles are specific to the type of routing protocol involved, but are sometimes more efficient and easier to implement than access lists.

Using Routing Access Profiles

To use routing access profiles, you must perform the following steps: 1 Create an access profile. 2 Configure the access profile to be of type permit, deny, or none. 3 Add entries to the access profile. Entries can be one of the following types: IP addresses and subnet masks IPX node, IPX RIP, and IPX SAP

ExtremeWare 7.1.0 Software User Guide

245

Security

Autonomous system path expressions (as-paths) (BGP only) BGP communities (BGP only) VLAN 4 Apply the access profile.

Creating an Access Profile

The first thing to do when using routing access profiles is to create an access profile. An access profile has a unique name and contains one of the following entry types: A list of IP addresses and associated subnet masks A list of IPX NetIDs A list of IPX node addresses A list of IPX SAP advertisements One or more autonomous system path expressions (BGP only) One or more BGP community numbers (BGP only) A VLAN You must give the access profile a unique name (in the same manner as naming a VLAN, protocol filter, or Spanning Tree Domain). To create an access profile, use the following command:
create access-profile <access_profile> type [ipaddress | ipx-node | ipx-net | ipx-sap | as-path | bgp-community | vlan]

Configuring an Access Profile Mode

After the access profile is created, you must configure the access profile mode. The access profile mode determines whether the items in the list are to be permitted access or denied access. Three modes are available: PermitThe permit access profile mode permits the operation, as long as it matches any entry in the access profile. If the operation does not match any entries in the list, the operation is denied. DenyThe deny access profile mode denies the operation, as long as it matches any entry in the access profile. If it does not match all specified entries in the list, the operation is permitted. NoneUsing the none mode, the access profile can contain a combination of permit and deny entries. Each entry must have a permit or deny attribute. The operation is compared with each entry in the list. Once a match is found, the operation is either permitted or denied, depending on the configuration of the matched entry. If no match is found, the operation is implicitly denied. To configure the access profile mode, use the following command:
configure access-profile <access_profile> mode [permit | deny | none]

Adding an Access Profile Entry

Next, configure the access profile, using the following command:

246

ExtremeWare 7.1.0 Software User Guide

Using Routing Access Profiles

configure access-profile <access_profile> add {<seq_number>} {permit | deny} [ipaddress <ipaddress> <mask> {exact} | ipx-node <net_id> <ipx_netid_mask> <ipx_nodeid> ipx-net <ipx_netid> <ipx_netid_mask> | ipx-sap <ipx_sap_type> <ipx_name>| as-path <path-expression> | bgp-community [internet | no-export | no-advertise | no-export-subconfed | <as_no:number> | number <community>]]

The following sections describe the configure access-profile add command.

Specifying Subnet Masks

The subnet mask specified in the access profile command is interpreted as a reverse mask. A reverse mask indicates the bits that are significant in the IP address. In other words, a reverse mask specifies the part of the address that must match the IP address to which the profile is applied. If you configure an IP address that is an exact match that is specifically denied or permitted, use a mask of /32 (for example, 141.251.24.28/32). If the IP address represents all addresses in a subnet address that you want to deny or permit, then configure the mask to cover only the subnet portion (for example, 141.251.10.0/24). The keyword exact can be used when you wish to match only against the subnet address, and ignore all addresses within the subnet. If you are using off-byte boundary subnet masking, the same logic applies, but the configuration is more tricky. For example, the network address 141.251.24.128/27 represents any host from subnet 141.251.24.128.

Sequence Numbering
You can specify the sequence number for each access profile entry. If you do not specify a sequence number, entries are sequenced in the order they are added. Each entry is assigned a value of 5 more than the sequence number of the last entry.

Permit and Deny Entries

If you have configured the access profile mode to be none, you must specify each entry type as either permit or deny. If you do not specify the entry type, it is added as a permit entry. If you have configured the access profile mode to be permit or deny, it is not necessary to specify a type for each entry.

IPX Access Profiles

IPX routing access profiles consist of access rules and are used to perform packet filtering and forwarding decisions on incoming traffic. Each IPX RIP or SAP packet arriving on an ingress port is compared to each access profile rule in sequential order and is either forwarded or dropped.

Autonomous System Expressions

The AS-path keyword uses a regular expression string to match against the AS path. Regular expression notation can include any of the characters listed in Table 33. Table 33: Regular Expression Notation
Character N N1 - N2 Definition As number Range of AS numbers, where N1 and N2 are AS numbers and N1 < N2

ExtremeWare 7.1.0 Software User Guide

247

Security

Table 33: Regular Expression Notation (continued)

Character [Nx ... Ny] [^Nx ... Ny] . ^ $ * + ? { } ( ) Definition Group of AS numbers, where Nx and Ny are AS numbers or a range of AS numbers Any AS numbers other than the ones in the group Matches any number Matches the beginning of the AS path Matches the end of the AS path Matches the beginning or end, or a space Separates the beginning and end of a range of numbers Matches 0 or more instances Matches 1 or more instances Matches 0 or 1 instance Start of AS SET segment in the AS path End of AS SET segment in the AS path Start of a confederation segment in the AS path End of a confederation segment in the AS path

Autonomous System Expression Example

The following example uses combinations of the autonomous system expressions to create a complicated access profile:
create access-profile AS1 type as-path configure access-profile AS1 mode none

These commands create the access profile.

configure access-profile AS1 add 5 permit as-path ^65535$

This command configures the access profile to permit AS paths that contain only (begin and end with) AS number 65535.
configure access-profile AS1 add 10 permit as-path ^65535 14490$

This command configures the access profile to permit AS paths beginning with AS number 65535, ending with AS number 14490, and containing no other AS paths.
configure access-profile AS1 add 15 permit as-path ^1 2-8 [11 13 15]$

This command configures the access profile to permit AS paths beginning with AS number 1, followed by any AS number from 2 - 8, and ending with either AS number 11, 13, or 15.
configure access-profile AS1 add 20 deny as-path 111 [2-8]

This command configures the access profile to deny AS paths beginning with AS number 111 and ending with any AS number from 2 - 8.
configure access-profile AS1 add 25 permit as-path 111 .?

This command configures the access profile to permit AS paths beginning with AS number 111 and ending with any additional AS number, or beginning and ending with AS number 111.

248

ExtremeWare 7.1.0 Software User Guide

Using Routing Access Profiles

Deleting an Access Profile Entry

To delete an access profile entry, use the following command:
configure access-profile <access_profile> delete <seq_number>

Applying Access Profiles

Once the access profile is defined, apply it to one or more routing protocols or VLANs. When an access profile is applied to a protocol function (for example, the export of RIP routes) or a VLAN, this forms an access policy. A profile can be used by multiple routing protocol functions or VLANs, but a protocol function or VLAN can use only one access profile.

Routing Profiles for RIP

If you are using the RIP protocol, the switch can be configured to use an access profile to determine: Trusted NeighborUse an access profile to determine trusted RIP router neighbors for the VLAN on the switch running RIP. To configure a trusted neighbor policy, use the following command:
configure rip vlan [<vlan name> | all] trusted-gateway [<access_profile> | none]

Import FilterUse an access profile to determine which RIP routes are accepted as valid routes. This policy can be combined with the trusted neighbor policy to accept selected routes only from a set of trusted neighbors. To configure an import filter policy, use the following command:
configure rip vlan [<vlan name> | all] import-filter [<access_profile> | none]

Export FilterUse an access profile to determine which RIP routes are advertised into a particular VLAN, using the following command:
configure rip vlan [<vlan name> | all] export-filter [<access_profile> | none]

Examples
In the example shown in Figure 35, a switch is configured with two VLANs, Engsvrs and Backbone. The RIP protocol is used to communicate with other routers on the network. The administrator wants to allow all internal access to the VLANs on the switch, but no access to the router that connects to the Internet. The remote router that connects to the Internet has a local interface connected to the corporate backbone. The IP address of the local interface connected to the corporate backbone is 10.0.0.10/24.

ExtremeWare 7.1.0 Software User Guide

249

Security

Figure 35: RIP access policy example

Internet

Internet
10.0.0.10 / 24

Backbone (RIP)

10.0.0.11 / 24 Switch being configured

10.0.0.12 / 24

Engsvrs
10.1.1.1 / 24

Sales
10.2.1.1 / 24

Engsvrs

Sales
EW_001

Assuming the backbone VLAN interconnects all the routers in the company (and, therefore, the Internet router does not have the best routes for other local subnets), the commands to build the access policy for the switch would be:
create access-profile nointernet ipaddress configure access-profile nointernet mode deny configure access-profile nointernet add 10.0.0.10/32 configure rip vlan backbone trusted-gateway nointernet

In addition, if the administrator wants to restrict any user belonging to the VLAN Engsvrs from reaching the VLAN Sales (IP address 10.2.1.0/24), the additional access policy commands to build the access policy would be:
create access-profile nosales ipaddress configure access-profile nosales mode deny configure access-profile nosales add 10.2.1.0/24 configure rip vlan backbone import-filter nosales

This configuration results in the switch having no route back to the VLAN Sales.

Routing Access Profiles for IPX

If you are using the IPX protocol, the switch can be configured to use an access profile to determine: Import FilterUse an access profile to determine which IPX/RIP or IPX/SAP routes are accepted as valid routes. To configure an import filter policy, use the following command:
configure ipxrip vlan [<vlan name> | all] import-filter [<access_profile> | none]

250

ExtremeWare 7.1.0 Software User Guide

Using Routing Access Profiles

configure ipxsap vlan [<vlan name> | all] import-filter [<access_profile> | none]

Export FilterUse an access profile to determine which IPX/RIP and IPX/SAP routes are advertised into a particular VLAN, using the following command:
configure ipxrip vlan [<vlan name> | all] export-filter [<access_profile> | none] configure ipxsap vlan [<vlan name> | all] export-filter [<access_profile> | none]

Routing Access Profiles for OSPF

Because OSPF is a link-state protocol, the access profiles associated with OSPF are different in nature than those associated with RIP. Access profiles for OSPF are intended to extend the existing filtering and security capabilities of OSPF (for example, link authentication and the use of IP address ranges). If you are using the OSPF protocol, the switch can be configured to use an access profile to determine any of the following: Inter-area FilterFor switches configured to support multiple OSPF areas (an ABR function), an access profile can be applied to an OSPF area that filters a set of OSPF inter-area routes from being sourced from any other areas. To configure an inter-area filter policy, use the following command:
configure ospf area <area identifier> interarea-filter [<access_profile> | none]

External FilterFor switches configured to support multiple OSPF areas (an ABR function), an access profile can be applied to an OSPF area that filters a set of OSPF external routes from being advertised into that area. To configure an external filter policy, use the following command:
configure ospf area <area identifier> external-filter [<access_profile> | none]

NOTE If any of the external routes specified in the filter have already been advertised, those routes will remain until the associated LSAs in that area time-out. ASBR FilterFor switches configured to support RIP and static route re-distribution into OSPF, an access profile can be used to limit the routes that are advertised into OSPF for the switch as a whole. To configure an ASBR filter policy, use the following command:
configure ospf asbr-filter [<access_profile> | none]

Direct FilterFor switches configured to support direct route re-distribution into OSPF, an access profile can be used to limit the routes that are advertised into OSPF for the switch as a whole. To configure a direct filter policy, use the following command:
configure ospf direct-filter [<access_profile> | none]

ExtremeWare 7.1.0 Software User Guide

251

Security

Example
Figure 36 illustrates an OSPF network that is similar to the network used previously in the RIP example. In this example, access to the Internet is accomplished by using the ASBR function on the switch labeled Internet. As a result, all routes to the Internet will be done through external routes. Suppose the network administrator wishes to only allow access to certain internet addresses falling within the range 192.1.1.0/24 to the internal backbone. Figure 36: OSPF access policy example

Internet

Switch being configured

Internet
10.0.0.10 / 24

Backbone (OSPF) area 0.0.0.0

10.0.0.11 / 24

10.0.0.12 / 24

Engsvrs
10.1.1.1 / 24

Sales
10.2.1.1 / 24

Engsvrs area 0.0.0.1

Sales area 0.0.0.2

EW_002

To configure the switch labeled Internet, the commands would be as follows:

create access-profile okinternet ipaddress configure access-profile okinternet mode permit configure access-profile okinternet add 192.1.1.0/24 configure ospf asbr-filter okinternet

Routing Access Profiles for DVMRP

The access policy capabilities for DVMRP are very similar to those for RIP. If you are using the DVMRP protocol is used for routing IP multicast traffic, you can configure the switch to use an access profile to determine: Trusted NeighborUse an access profile to determine trusted DVMRP router neighbors for the VLAN on the switch running DVMRP. To configure a trusted neighbor policy, use the following command:
configure dvmrp vlan [<vlan name> | all] trusted-gateway [<access_profile> | none]

252

ExtremeWare 7.1.0 Software User Guide

Using Routing Access Profiles

Import FilterUse an access profile to determine which DVMRP routes are accepted as valid routes. To configure an import filter policy, use the following command:
configure dvmrp vlan [<vlan name> | all] import-filter [<access_profile> | none]

Export FilterUse an access profile to determine which DVMRP routes are advertised into a particular VLAN, using the following command:
configure dvmrp vlan [<vlan name> | all] export-filter [<access_profile> | none]

Example
In this example, the network used in the previous RIP example is configured to run DVMRP. The network administrator wants to disallow Internet access for multicast traffic to users on the VLAN Engsvrs. This is accomplished by preventing the learning of routes that originate from the switch labeled Internet by way of DVMRP on the switch labeled Engsvrs. To configure the switch labeled Engsvrs, use the following commands:
create access-profile nointernet ipaddress configure access-profile nointernet mode deny configure access-profile nointernet add 10.0.0.10/32 configure dvmrp vlan backbone trusted-gateway nointernet

In addition, suppose the administrator wants to preclude users on the VLAN Engsvrs from seeing any multicast streams that are generated by the VLAN Sales across the backbone. The additional configuration of the switch labeled Engsvrs is as follows:
create access-profile nosales ipaddress configure access-profile nosales mode deny configure access-profile nosales add 10.2.1.0/24 configure dvmrp vlan backbone import-filter nosales

Routing Access Profiles for PIM

Because PIM leverages the unicast routing capability that is already present in the switch, the access policy capabilities are, by nature, different. If you are using the PIM protocol for routing IP multicast traffic, you can configure the switch to use an access profile to determine: Trusted NeighborUse an access profile to determine trusted PIM router neighbors for the VLAN on the switch running PIM. To configure a trusted neighbor policy, use the following command:
configure pim vlan [<vlan name> | all] trusted-gateway [<access_profile> | none]

Example
Using PIM, the unicast access profiles can be used to restrict multicast traffic. In this example, a network similar to the example used in the previous RIP example is also running PIM. The network administrator wants to disallow Internet access for multicast traffic to users on the VLAN Engsvrs. This is accomplished by preventing the learning of routes that originate from the switch labeled Internet by way of PIM on the switch labeled Engsvrs.

ExtremeWare 7.1.0 Software User Guide

253

Security

To configure the switch labeled Engsvrs, the commands would be as follows:

create access-profile nointernet ipaddress configure access-profile nointernet mode deny configure access-profile nointernet add 10.0.0.10/32 configure pim vlan backbone trusted-gateway nointernet

Routing Access Profiles for BGP

If the BGP protocol is being used, the switch can be configured to use an access profile to determine: NLRI filterUse an access profile to determine the NLRI information that must be exchanged with a neighbor. To configure an NLRI filter policy, use the following command:
configure bgp neighbor [<ipaddress> | all] nlri-filter [in | out] [<access_profile> | none]

The NLRI filter access policy can be applied to the ingress or egress updates, using the in and out keywords, respectively. Autonomous system path filterUse an access profile to determine which NLRI information must be exchanged with a neighbor based on the AS path information present in the path attributes of the NLRI. To configure an autonomous system path filter policy, use the following command:
configure bgp neighbor [<ipaddress> | all] as-path-filter [in | out] [<access_profile> | none]

The autonomous system path filter can be applied to the ingress or egress updates, using the in and out keywords, respectively.

Making Changes to a Routing Access Policy

You can change the routing access policy by changing the associated access profile. However, the propagation of the change depends on the protocol and policy involved. Propagation of changes applied to RIP, DVMRP, and PIM access profiles depend on the respective protocol timers to age-out entries. In BGP, the change to the policy is immediately effective on the routing information exchanged after the policy changes. The changes can be applied on the routing information that had been exchanged before the policy changes by issuing a soft reset on the ingress or egress side, depending on the change. For soft resets to be applied on the ingress side, the changes must have been previously enabled on the neighbor.

NOTE Changes to profiles applied to OSPF typically require rebooting the switch, or disabling and re-enabling OSPF on the switch.

254

ExtremeWare 7.1.0 Software User Guide

Route Maps

Removing a Routing Access Policy

To remove a routing access policy, you must remove the access profile from the routing protocol or VLAN. All the commands that apply an access profile to form an access policy also have the option of choosing none as the access profile. Using the none option removes any access profile of that particular type from the protocol or VLAN, and, therefore, removes the access policy.

Route Maps
Route maps are used to modify or filter routes. They are also used to modify or filter routing information.

Using Route Maps

Route maps are a mechanism that can be used to conditionally control the redistribution of routes between two routing domains, and to modify the routing information that is redistributed. Route maps are used in conjunction with the match and set operations. A match operation specifies a criteria that must be matched. A set operation specifies a change that is made to the route when the match operation is successful. To create a route map, follow these steps: 1 Create a route map. 2 Add entries to the route map. 3 Add statements to the route map entries.

Creating a Route Map

To create a route map, use the following command:
create route-map <route-map>

Add Entries to the Route Map

To add entries to the route map, use the following command:
configure route-map <route-map> add <sequence number> [permit | deny] {match-one | match-all}

where the following is true: The sequence number uniquely identifies the entry, and determines the position of the entry in the route map. Route maps are evaluated sequentially. The permit keyword permits the route; the deny keyword denies the route and is applied only if the entry is successful. The match-one keyword is a logical or. The route map is successful as long as at least one of the matching statements is true.

ExtremeWare 7.1.0 Software User Guide

255

Security

The match-all keyword is a logical and. The route map is successful when all match statements are true. This is the default setting.

Add Statements to the Route Map Entries

To add statements to the route map entries, use one of the following four commands:
configure route-map <route-map> <sequence number> add match [nlri-list <access-profile> | as-path [access-profile <access-profile> | <as no>] | community [access-profile <access-profile> | <as no> : <number> | number <community> | no-advertise | no-export | no-export-subconfed] | next-hop <ip address> | med <number> | origin [igp | egp | incomplete] | tag <number> | origin [igp | egp | incomplete]] configure route-map <route-map> <sequence number> add set [as-path <as no> | community [[access-profile <access-profile> | <as no> : <number> | number <community> | no-advertise | no-export | no-export-subconfed] | remove | [add | delete] [access-profile <access-profile> | <as no> : <number> | number <community> | no-advertise | no-export | no-export-subconfed]] | next-hop <ip address> | med [internal | <number> | remove | [add | delete] <number> ] | local-preference <number> | weight <number> | origin [igp | egp | incomplete] | tag <number> | accounting index <number> value <number> | cost <number> | cost-type [ase-type-1 | ase-type-2 ]] configure route-map <route-map> <sequence number> add goto <route-map> configure route-map <route-map> <sequence number> [add | delete] set accounting-index 1 value <bin_number>

where the following is true: The route-map is the name of the route map. The sequence number identifies the entry in the route map to which this statement is being added. The match, set, and goto keywords specify the operations to be performed. Within a entry, the statements are sequenced in the order of their operation. The match statements are first, followed by set, and then goto. The nlri-list, as-path, community, next-hop, med, origin, and weight keywords specify the type of values that must be applied using the specified operation against the corresponding attributes as described in Table 34 and Table 35. The accounting-index keyword specifies the bin number assigned to a specific route map as discussed in Table 36. Table 34: Match Operation Keywords
Keyword nlri-list <access_profile> as-path [<access_profile> | <as-no>] Description Matches the NLRI against the specified access profile. Matches the AS path in the path attributes against the specified access profile or AS number.

community [access-profile Matches the communities in the path attribute against the specified BGP <access-profile> | <as no>: <number> community access profile or the community number. | number <community> | no-advertise | no-export | no-export-subconfed] next-hop <ipaddress> Matches the next hop in the path attribute against the specified IP address.

256

ExtremeWare 7.1.0 Software User Guide

Using Route Maps

Table 34: Match Operation Keywords (continued)

Keyword med <number> origin [igp | egp | incomplete] tag <number> Description Matches the MED in the path attribute against the specified MED number. Matches the origin in the path attribute against the specified origin. Matches the tag associated with the redistributed OSPF route.

Table 35: Set Operation Keywords

Keyword as-path <as no> Definition Prepends the specified AS number to the AS path in the path attribute.

community [[access-profile Adds the specified community to the existing community in the path <access-profile> | <as no>: <number> attribute. | number <community> | no-advertise | no-export | no-export-subconfed] | remove | [add | delete] [access-profile <access-profile> | <as no>: <number> | number <community> | no-advertise | no-export | no-export-subconfed]] next-hop <ipaddress> med [internal | <number> | remove | [add | delete] <number>] Sets the next hop in the path attribute to the specified IP address. Modifies the MED in the path attribute as specified: internalWhen used in the BGP neighbor output route map, the MED attribute is set to a value equal to the metric to reach the nexthop. <number>Sets the MED attribute to the specified value. removeRemoves the MED attribute, if present. [add | delete] <number>Adds or deletes the specified value to or from the MED that is received. The final result is bound by 0 and 2147483647.

local-preference <number> weight <number> origin [igp | egp | incomplete] tag <number> cost <number> cost-type <number> accounting index [ase-type-1 | ase-type-2]

Sets the local preference in the path attribute to the specified local preference number. Sets the weight associated with the NLRI to the specified number. Sets the origin in the path attributes to the specified origin. Sets the tag in the route to the specified number. Sets the cost of the route to the specified number Sets the type of the cost associated with the route. Sets the specified accounting index to the specified number.

Table 36: Set Operation Keywords

Command accounting-index <index> value <value> Description of Change Sets the accounting bin number for the route-mapped accounting index. The accounting index value is always set to 1 for Destination Sensitive Accounting.

ExtremeWare 7.1.0 Software User Guide

257

Security

Route Map Operation

The entries in the route map are processed in the ascending order of the sequence number. Within the entry, the match statements are processed first. When the match operation is successful, the set and goto statements within the entry are processed, and the action associated with the entry is either applied, or else the next entry is processed. If the end of the route map is reached, it is implicitly denied. When there are multiple match statement, the primitive match-one or match-all in the entry determines how many matches are required for success. When there are no match statements in an entry, the entry is considered a successful match.

Route Map Example

Figure 37 shows a topology in which route maps are used to filter or modify routing information that is exchanged between the neighbors RTA and RTB using BGP. Figure 37: Route maps

AS 1111 Internet RTA

10.0.0.1

10.0.0.2

RTB AS 2222
EW_048

The following points apply to this example: RTA is a member of in AS 1111 and peers with a router in the Internet to receive the entire Internet routing table. RTB is a member of AS 2222, and has an EBGP connection with RTA through which it receives the Internet routing table. AS 1111 is acting as a transit AS for all traffic between AS 2222 and the Internet. If the administrator of AS 1111 wants to filter out route information about network 221.1.1.0/24 and its subnets from being passed on to AS 2222, the administrator can configure a route-map on the egress side of RTAs EBGP connection with RTB and filter out the routes.

258

ExtremeWare 7.1.0 Software User Guide

Using Route Maps

To configure RTA, use the following commands:

create access-profile iplist type ipaddress configure iplist add ipaddress 221.1.1.0 / 24 create route-map bgp-out configure bgp-out add 10 deny configure bgp-out 10 add match nlri-list iplist configure bgp-out add 20 permit configure bgp neighbor 10.0.0.2 route-map-filter out bgp-out configure bgp neighbor 10.0.0.2 soft-reset out

If you wish to modify the routing information originated from AS 300 to include a MED value of 200, the sequence of commands would be:
create access-profile aslist type as-path configure aslist add as-path "^300" configure bgp-out add 15 permit configure bgp-out 15 add match as-path access-profile aslist configure bgp-out 15 add set med 200 configure bgp neighbor 10.0.0.2 soft-reset out

Changes to Route Maps

Changes to the route maps used to modify or filter NLRI information exchanged with neighbors is immediately effective on the routing information exchanged after the policy changes. The changes can be applied on the NLRI information that had been exchanged before the policy changes by issuing a soft reset on the ingress or egress side, depending on the changes. For soft resets to be applied on the ingress side, the changes must be previously enabled on the neighbor. Changes to the route maps associated with network aggregation or redistribution commands becomes effective after a maximum interval of 30 seconds. You can immediately apply them by using the soft reconfiguration command.

Route Maps in BGP

Route maps are used in BGP to modify/filter NLRI information exchanged with neighbors. They are also used NLRI information that originates by way of network command, aggregation, or redistribution.

ExtremeWare 7.1.0 Software User Guide

259

Security

Denial of Service Protection

A Denial-of-Service (DoS) attack occurs when a critical network or computing resource is overwhelmed and rendered inoperative in a way that legitimate requests for service cannot succeed. In its simplest form, a Denial of Service attack is indistinguishable from normal heavy traffic. Extreme Network switches are not vulnerable to this simple attack because they are all designed to process packets in hardware at wire speed. However, there are some operations in any switch or router that are more costly than others, and although normal traffic is not a problem, exception traffic must be handled by the switchs CPU in software. Some packets that the switch processes in the CPU software include: learning new traffic routing and control protocols including ICMP, BGP and OSPF switch management traffic (switch access by Telnet, SSH, HTTP, SNMP, etc...) other packets directed to the switch that must be discarded by the CPU If any one of these functions is overwhelmed, the CPU may be too busy to service other functions and switch performance will suffer. Even with very fast CPUs, there will always be ways to overwhelm the CPU by with packets requiring costly processing. DoS Protection is designed to help prevent this degraded performance by attempting to characterize the problem and filter out the offending traffic so that other functions can continue. When a flood of packets is received from the switch, DoS Protection will count these packets. When the packet count nears the alert threshold, packets headers will be saved. If the threshold is reached, then these headers are analyzed, and a hardware access control list (ACL) is created to limit the flow of these packets to the CPU. This ACL will remain in place to provide relief to the CPU. Periodically, the ACL will expire, and if the attack is still occurring, it will be re-enabled. With the ACL in place, the CPU will have the cycles to process legitimate traffic and continue other services.

Configuring Denial of Service Protection

To configure denial of service protection, use the following command:
configure cpu-dos-protect [alert-threshold <packets per second>] [notice-threshold <packets per second>] [timeout <seconds>] [messages [on | off]] [filter-precedence <number>] [filter-type-allowed {destination | source | destination source} {protocol}]

The default values for the parameters are as follows: alert-threshold4000 packets per second notice-threshold4000 packets per second timeout15 seconds messageson (messages are sent to syslog) filter-precedence10 filter-type-alloweddestination If you wish to set all the parameters back to their default values, use the following command:
unconfigure cpu-dos-protect

260

ExtremeWare 7.1.0 Software User Guide

Denial of Service Protection

NOTE If you set the filter-precedence to 0, the ACLs created by DoS protection will be overwritten by the default VLAN QoS profile.

Enabling Denial of Service Protection

Enable denial of service protection using the following command:
enable cpu-dos-protect

Once enabled, denial of service protection creates an access list for packets when the receive packet on a port is greater than the alert level. For example, if cpu-dos-protect is enabled on a Summit7i switch and the threshold alert level is set to 3000 packets per second, an access list is created if one of the ports on the switch receives 3000 or more packets per second. The precedence is set at 10 for the duration of the timeout. For example, if you set the timeout to 15 seconds, the ACL is created for 15 seconds. The switch continues to create access lists for the duration of the timeout until the packet rate declines to less than the configured threshold alert level.

Disabling Denial of Service Protection

To disable denial of service protection, use the following command:
disable cpu-dos-protect

Displaying Denial of Service Settings

To display denial of service settings and the status of the access list, use the following command:
show cpu-dos-protect

How to Deploy DoS Protection

The conservative way to deploy DoS Protection is to use the simulated mode first. In simulated mode, DoS Protection is enabled, but no ACLs are generated. To enable the simulated mode, use the command:
enable cpu-dos-protect simulated

Next, configure the notice threshold. This will help determine the actual traffic received by the CPU by logging when the traffic exceeds the threshold. This can help understand the types of traffic encountered, and evaluate whether legitimate traffic may be accidentally blocked. Some examples of heavy legitimate traffic to the cpu include: route lossduring this period, the switch may receive lots of routing updates that cause heavy traffic processing loads on the CPU. configuration or image upload/download To configure the notice threshold, use the following command:
configure cpu-dos-protect notice-threshold <packets per second>

ExtremeWare 7.1.0 Software User Guide

261

Security

Next, configure the alert threshold. If the alert threshold is reached, a simulated ACL is put in place. Although packets will not be dropped, this provides good information about the heavy traffic, which might be legitimate or might be an attack. The Ethernet address of the source and the type of traffic can be characterized by the type of ACL put in place. This is another way to judge if legitimate traffic would have been cut off. To configure the alert threshold, use the following command:
configure cpu-dos-protect alert-threshold <packets per second>

After normal traffic is characterized, steps should be taken to set: the appropriate notice level if some warning is desired the appropriate alert level at which an ACL is put in place trusted ports from which traffic wont be blocked In some cases, traffic from a switch port or group of ports will never cause an attack. These ports can be configured as trusted port and will never be considered for traffic that will generate an ACL. This can prevent innocent hosts from being blocked, or ensure that when an innocent host responds to an attack that the flood of response packets is not mistaken for the attack. To configure a trusted port, use the following command:
configure cpu-dos-protect trusted-ports add <port list>

The last step is to enable DoS Protection. At this point, only attack traffic should be blocked and legitimate traffic should pass through. To enable the creation of ACLs for DoS Protection, use the following command:
enable cpu-dos-protect

Blocking SQL Slammer DoS Attacks

You can block the SQL Slammer DoS attack. SQL Slammer causes high CPU utilization on the next-hop switch serving multicast requests as ICMP sender entries are quickly populated into the multicast sender list. This leads to a high number of multicast entries in the IGMP snooping entry table, and a message similar to the following in the system log:
<WARN:HW> tBGTask: Reached maximum otp ExtraMC index allocation

To block and clean up after this task: 1 Block the attack by creating an ACL to block port 1434 using the following command:
create access-list UDP dest any ip-port 1434 source any ip-port any

2 Remove affected SQL servers from the network You can simply disable the port connecting the server. 3 Clean up the existing IGMP snooping entries and IPMC cache using the following commands:
igmp snooping clear ipmc cache

4 Disable IGMP snooping on the affected switches. Disabling IGMP snooping affects routing protocols using multicast addresses and multicast traffic on that switch.

262

ExtremeWare 7.1.0 Software User Guide

Management Access Security

Management Access Security

Management access security features control access to the management functions available on the switch. These features help insure that any configuration changes to the switch can only be done by authorized users. In this category are the following features: Authenticating Users Using RADIUS or TACACS+ Secure Shell 2 (SSH2)

Authenticating Users Using RADIUS or TACACS+

ExtremeWare provides two methods to authenticate users who login to the switch: RADIUS client TACACS+

RADIUS Client
Remote Authentication Dial In User Service (RADIUS, RFC 2138) is a mechanism for authenticating and centrally administrating access to network nodes. The ExtremeWare RADIUS client implementation allows authentication for Telnet, Vista, or console access to the switch. NOTE You cannot configure RADIUS and TACACS+ at the same time. You can define a primary and secondary RADIUS server for the switch to contact. When a user attempts to login using Telnet, http, or the console, the request is relayed to the primary RADIUS server, and then to the secondary RADIUS server, if the primary does not respond. If the RADIUS client is enabled, but access to the RADIUS primary and secondary server fails, the switch uses its local database for authentication. The privileges assigned to the user (admin versus nonadmin) at the RADIUS server take precedence over the configuration in the local switch database. To configure the RADIUS servers, use the following command:
configure radius server [primary | secondary] <ipadress> <UDP_port> client-ip <ipaddress>

To configure the timeout if a server fails to respond, use the following command:
configure radius timeout <seconds>

Configuring the Shared Secret Password

In addition to specifying the RADIUS server IP information, RADIUS also contains a means to verify communication between network devices and the server. The shared secret is a password configured on the network device and RADIUS server, used by each to verify communication.

ExtremeWare 7.1.0 Software User Guide

263

Security

To configure the shared secret for RADIUS servers, use the following command:
configure radius [primary | secondary] shared-secret {encrypted} <string>

Enabling and Disabling RADIUS

After server information is entered, you can start and stop RADIUS authentication as many times as necessary without needing to reconfigure server information. To enable RADIUS authentication, use the following command:
enable radius

To disable RADIUS authentication, use the following command:

disable radius

Configuring RADIUS Accounting

Extreme switches are capable of sending RADIUS accounting information. As with RADIUS authentication, you can specify two servers for receipt of accounting information. You can configure RADIUS accounting servers to be the same as the authentication servers, but this is not required. To specify RADIUS accounting servers, use the following command:
configure radius-accounting [primary | secondary] server [<ipaddress> | <hostname>] {<udp_port>} client-ip <ipaddress>

To configure the timeout if a server fails to respond, use the following command:
configure radius-accounting timeout <seconds>

RADIUS accounting also makes use of the shared secret password mechanism to validate communication between network access devices and RADIUS accounting servers. To specify shared secret passwords for RADIUS accounting servers, use the following command:
configure radius [primary | secondary] shared-secret {encrypted} <string>

After you configure RADIUS accounting server information, you must enable accounting before the switch begins transmitting the information. You must enable RADIUS authentication for accounting information to be generated. You can enable and disable accounting without affecting the current state of RADIUS authentication. To enable RADIUS accounting, use the following command:
enable radius-accounting

To disable RADIUS accounting, use the following command:

disable radius-accounting

Per-Command Authentication Using RADIUS

The RADIUS implementation can be used to perform per-command authentication. Per-command authentication allows you to define several levels of user capabilities by controlling the permitted command sets based on the RADIUS username and password. You do not need to configure any additional switch parameters to take advantage of this capability. The RADIUS server implementation

264

ExtremeWare 7.1.0 Software User Guide

Authenticating Users Using RADIUS or TACACS+

automatically negotiates the per-command authentication capability with the switch. For examples on per-command RADIUS configurations, see the next section.

Configuring RADIUS Client

You can define primary and secondary server communication information, and for each RADIUS server, the RADIUS port number to use when talking to the RADIUS server. The default port value is 1645. The client IP address is the IP address used by the RADIUS server for communicating back to the switch.

RADIUS RFC 2138 Attributes

The RADIUS RFC 2138 optional attributes supported are as follows: User-Name User-Password Service-Type Login-IP-Host

Using RADIUS Servers with Extreme Switches

Extreme Networks switches have two levels of user privilege: Read-only Read-write Because there are no CLI commands available to modify the privilege level, access rights are determined when you log in. For a RADIUS server to identify the administrative privileges of a user, Extreme switches expect a RADIUS server to transmit the Service-Type attribute in the Access-Accept packet, after successfully authenticating the user. Extreme switches grant a RADIUS-authenticated user read-write privilege if a Service-Type value of 6 is transmitted as part of the Access-Accept message from the Radius server. Other Service-Type values, or no value, result in the switch granting read-only access to the user. Different implementations of RADIUS handle attribute transmission differently. You should consult the documentation for your specific implementation of RADIUS when you configure users for read-write access.

Cistron RADIUS
Cistron RADIUS is a popular server, distributed under GPL. Cistron RADIUS can be found at: http://www.miquels.cistron.nl/radius/ When you configure the Cistron server for use with Extreme switches, you must pay close attention to the users file setup. The Cistron RADIUS dictionary associates the word Administrative-User with Service-Type value 6, and expects the Service-Type entry to appear alone on one line with a leading tab character. The following is a user file example for read-write access: adminuser Auth-Type = System Service-Type = Administrative-User, Filter-Id = unlim

ExtremeWare 7.1.0 Software User Guide

265

Security

Livingston (Lucent) RADIUS

Livingston RADIUS is produced by Lucent Technologies primarily for use with their portmaster products. Version 2.1 is released under a BSD license agreement and can be found at ftp://ftp.livingston.com/pub/le/radius/radius21.tar.Z. As with Cistron RADIUS, the Livingston server default dictionary associates Administrative-User with Service-Type value 6. The administrative users file entry example for Cistron RADIUS also works with Livingston RADIUS.

RSA Ace
For users of their SecureID product, RSA offers RADIUS capability as part of their ACE server software. With some versions of ACE, the RADIUS shared-secret is incorrectly sent to the switch resulting in an inability to authenticate. As a work around, do not configure a shared-secret for RADIUS accounting and authentication servers on the switch.

Limiting Max-Concurrent Sessions with Funk Softwares Steel Belted Radius

For users who have Funk Softwares Steel Belted Radius (SBR) server, it is possible to limit the number of concurrent login sessions using the same user account. This feature allows the use of shared user accounts, but limits the number of simultaneous logins to a defined value. Using this feature requires Funk Software Steel-Belted-Radius for Radius Authentication & Accounting. Complete the following two steps to limit the maximum concurrent login sessions under the same user account: 1 Configure Radius and Radius-Accounting on the switch The Radius and Radius-Accounting servers used for this feature must reside on the same physical Radius server. Standard Radius and Radius-Accounting configuration is required as described earlier in this chapter. 2 Modify the Funk SBR vendor.ini file and user accounts To configure the Funk SBR server, the file vendor.ini must be modified to change the Extreme Networks configuration value of ignore-ports to yes as shown in the example below:
vendor-product dictionary ignore-ports port-number-usage help-id = = = = = Extreme Networks Extreme yes per-port-type 2000

After modifying the vendor.ini file, the desired user accounts must be configured for the Max-Concurrent connections. Using the SBR Administrator application, enable the check box for Max-Concurrent connections and fill in the desired number of maximum sessions.

Extreme RADIUS
Extreme Networks provides its users, free of charge, a radius server based on Merit RADIUS. Extreme RADIUS provides per-command authentication capabilities in addition to the standard set of radius features. Source code for Extreme RADIUS can be obtained from the Extreme Networks Technical Assistance Center and has been tested on Red Hat Linux and Solaris. When Extreme RADIUS is up and running, the two most commonly changed files will be users and profiles. The users file contains entries specifying login names and the profiles used for per-command authentication after they have logged in. Sending a HUP signal to the RADIUS process is sufficient to get changes in the users file to take place. Extreme RADIUS uses the file named profiles to specify

266

ExtremeWare 7.1.0 Software User Guide

Authenticating Users Using RADIUS or TACACS+

command lists that are either permitted or denied to a user based on their login identity. Changes to the profiles file require the RADIUS server to be shutdown and restarted. Sending a HUP signal to the RADIUS process is not enough to force changes to the profiles file to take effect. When you create command profiles, you can use an asterisk to indicate any possible ending to any particular command. The asterisk cannot be used as the beginning of a command. Reserved words for commands are matched exactly to those in the profiles file. Due to the exact match, it is not enough to simply enter sh for show in the profiles file, the complete word must be used. Commands can still be entered in the switch in partial format. When you use per-command authentication, you must ensure that communication between the switch(es) and radius server(s) is not lost. If the RADIUS server crashes while users are logged in, they will have full administrative access to the switch until they log out. Using two RADIUS servers and enabling idle timeouts on all switches will greatly reduce the chance of a user gaining elevated access due to RADIUS server problems.

RADIUS Server Configuration Example (Merit)

Many implementations of RADIUS server use the publicly available Merit AAA server application, available on the World Wide Web at: http://www.merit.edu/aaa Included below are excerpts from relevant portions of a sample Merit RADIUS server implementation. The example shows excerpts from the client and user configuration files. The client configuration file (ClientCfg.txt) defines the authorized source machine, source name, and access level. The user configuration file (users) defines username, password, and service type information.
ClientCfg.txt #Client Name #---------------#10.1.2.3:256 #pm1 #pm2 #merit.edu/homeless #homeless #xyz.merit.edu #anyoldthing:1234 10.202.1.3 10.203.1.41 10.203.1.42 10.0.52.14 users user Password Filter-Id = admin Password Filter-Id = eric = "" "unlim" = "", Service-Type = Administrative "unlim" Key [type] [version] --------------- -------------- --------test type = nas v2 %^$%#*(&!(*&)+ type=nas :-):-(;^):-}! type nas hmoemreilte.ses testing type proxy v1 moretesting type=Ascend:NAS v1 whoknows? type=NAS+RAD_RFC+ACCT_RFC andrew-linux type=nas eric type=nas eric type=nas samf type=nas [prefix] -------pfx pm1. pm2.

Password = "", Service-Type = Administrative Filter-Id = "unlim"

albert Password = "password", Service-Type = Administrative Filter-Id = "unlim"

ExtremeWare 7.1.0 Software User Guide

267

Security

samuel

Password = "password", Service-Type = Administrative Filter-Id = "unlim"

RADIUS Per-Command Configuration Example

Building on this example configuration, you can use RADIUS to perform per-command authentication to differentiate user capabilities. To do so, use the Extreme-modified RADIUS Merit software that is available from the Extreme Networks by contacting Extreme Networks technical support. The software is available in compiled format for Solaris or Linux operating systems, as well as in source code format. For all clients that use RADIUS per-command authentication, you must add the following type to the client file:
type:extreme:nas + RAD_RFC + ACCT_RFC

Within the users configuration file, additional keywords are available for Profile-Name and Extreme-CLI-Authorization. To use per-command authentication, enable the CLI authorization function and indicate a profile name for that user. If authorization is enabled without specifying a valid profile, the user is unable to perform any commands. Next, define the desired profiles in an ASCII configuration file called profiles. This file contains named profiles of exact or partial strings of CLI commands. A named profile is linked with a user through the users file. A profile with the permit on keywords allows use of only the listed commands. A profile with the deny keyword allows use of all commands except the listed commands. CLI commands can be defined easily in a hierarchal manner by using an asterisk (*) to indicate any possible subsequent entry. The parser performs exact string matches on other text to validate commands. Commands are separated by a comma (,) or newline. Looking at the following example content in profiles for the profile named PROFILE1, which uses the deny keyword, the following attributes are associated with the user of this profile: Cannot use any command starting with enable. Cannot issue the disable ipforwarding command. Cannot issue a show switch command. Can perform all other commands. We know from the users file that this applies to the users albert and lulu. We also know that eric is able to log in, but is unable to perform any commands, because he has no valid profile assigned. In PROFILE2, a user associated with this profile can use any enable command, the clear counter command and the show management command, but can perform no other functions on the switch. We also know from the users file that gerald has these capabilities. The following lists the contents of the file users with support for per-command authentication:
user Password = "" Filter-Id = "unlim" Password = "", Service-Type = Administrative Filter-Id = "unlim" Password = "", Service-Type = Administrative, Profile-Name = "" Filter-Id = "unlim" Extreme:Extreme-CLI-Authorization = Enabled

admin

eric

268

ExtremeWare 7.1.0 Software User Guide

Authenticating Users Using RADIUS or TACACS+

albert Password = "", Service-Type = Administrative, Profile-Name = "Profile1" Filter-Id = "unlim" Extreme:Extreme-CLI-Authorization = Enabled lulu Password = "", Service-Type = Administrative, Profile-Name = "Profile1" Filter-Id = "unlim" Extreme:Extreme-CLI-Authorization = Enabled gerald Password = "", Service-Type = Administrative, Profile-Name "Profile2" Filter-Id = "unlim" Extreme:Extreme-CLI-Authorization = Enabled

Contents of the file profiles:

PROFILE1 deny { enable *, disable ipforwarding show switch } PROFILE2 { enable *, clear counters show management } PROFILE3 deny { create vlan *, configure iproute *, disable *, show fdb delete *, configure rip add }

Configuring TACACS+
Terminal Access Controller Access Control System Plus (TACACS+) is a mechanism for providing authentication, authorization, and accounting on a centralized server, similar in function to the RADIUS client. The ExtremeWare version of TACACS+ is used to authenticate prospective users who are attempting to administer the switch. TACACS+ is used to communicate between the switch and an authentication database. NOTE You cannot use RADIUS and TACACS+ at the same time. You can configure two TACACS+ servers, specifying the primary server address, secondary server address, and UDP port number to be used for TACACS+ sessions.

ExtremeWare 7.1.0 Software User Guide

269

Security

Secure Shell 2 (SSH2)

Secure Shell 2 (SSH2) is a feature of ExtremeWare that allows you to encrypt Telnet session data between a network administrator using SSH2 client software and the switch, or to send encrypted data from the switch to an SSH2 client on a remote system. Image and configuration files may also be transferred to the switch using the Secure Copy Protocol 2 (SCP2). The ExtremeWare CLI provides a command that enable the switch to function as an SSH2 client, sending commands to a remote system via an SSH2 session. It also provides commands to copy image and configuration files to the switch using the SCP2. The ExtremeWare SSH2 switch application is based on the Data Fellows SSH2 server implementation. It is highly recommended that you use the F-Secure SSH client products from Data Fellows corporation. These applications are available for most operating systems. For more information, see the Data Fellows website at: http://www.datafellows.com. NOTE SSH2 is compatible with the Data Fellows SSH2 client version 2.0.12 or above. SSH2 is not compatible with SSH1. The ExtremeWare SSH2 switch application also works with SSH2 client and server (version 2.x or later) from SSH Communication Security, and the free SSH2 and SCP2 implementation (version 2.5 or later) from OpenSSH. The SFTP file transfer protocol is required for file transfer using SCP2.

Enabling SSH2 for Inbound Switch Access

Because SSH2 is currently under U.S. export restrictions, you must first obtain a security-enabled version of the ExtremeWare software from Extreme Networks before you can enable SSH2. The procedure for obtaining a security-enabled version of the ExtremeWare software is described in Chapter 1. You must enable SSH2 on the switch before you can connect to it using an external SSH2 client. Enabling SSH2 involves two steps: Enabling SSH2 access, which may include specifying a list of clients that can access the switch, and specifying a TCP port to be used for communication. By default, if you have a security license, SSH2 is enabled using TCP port 22, with no restrictions on client access. Generating or specifying an authentication key for the SSH2 session. To enable SSH2, use the following command:
enable ssh2 {access-profile [<access_profile> | none] {port <tcp_port_number>}}

You can specify a list of predefined clients that are allowed SSH2 access to the switch. To do this, you must create an access profile that contains a list of allowed IP addresses. You can also specify a TCP port number to be used for SSH2 communication. By default the TCP port number is 22. The supported ciphers are 3DES-CBC and Blowfish. The supported key exchange is DSA.

270

ExtremeWare 7.1.0 Software User Guide

Secure Shell 2 (SSH2)

An authentication key must be generated before the switch can accept incoming SSH2 sessions. This can be done automatically by the switch, or you can enter a previously generated key. To have the key generated by the switch, use the following command:
configure ssh2 key

You are prompted to enter information to be used in generating the key. The key generation process takes approximately ten minutes. Once the key has been generated, you should save your configuration to preserve the key. To use a key that has been previously created, use the following command:
configure ssh2 key pregenerated

You are prompted to enter the pregenerated key. The key generation process generates the SSH2 private host key. The SSH2 public host key is derived from the private host key, and is automatically transmitted to the SSH2 client at the beginning of an SSH2 session. Before you initiate a session from an SSH2 client, ensure that the client is configured for any nondefault access list or TCP port information that you have configured on the switch. Once these tasks are accomplished, you may establish an SSH2-encrypted session with the switch. Clients must have a valid user name and password on the switch in order to log into the switch after the SSH2 session has been established. For additional information on the SSH protocol refer to [FIPS-186] Federal Information Processing Standards Publication (FIPSPUB) 186, Digital Signature Standard, 18 May 1994. This can be download from: ftp://ftp.cs.hut.fi/pub/ssh. General technical information is also available from: http://www.ssh.fi

Using SCP2 from an External SSH2 Client

In ExtremeWare version 6.2.1 or later, the SCP2 protocol is supported for transferring image and configuration files to the switch from the SSH2 client, and for copying the switch configuration from the switch to an SSH2 client. CAUTION You can download a configuration to an Extreme Networks switch using SCP. If you do this, you cannot save this configuration. If you save this configuration and reboot the switch, the configuration will be corrupted. The user must have administrator-level access to the switch. The switch can be specified by its switch name or IP address. Configuration or image files stored on the system running the SSH2 client may be named as desired by the user. However, files on the switch have predefined names, as follows: configuration.cfgThe current configuration incremental.cfgThe current incremental configuration primary.imgThe primary ExtremeWare image secondary.imgThe secondary ExtremeWare image bootrom.imgThe BootROM image

ExtremeWare 7.1.0 Software User Guide

271

Security

For example, to copy an image file saved as image1.xtr to switch with IP address 10.10.0.5 as the primary image using SCP2, you would enter the following command within your SSH2 session:
scp image1.xtr [email protected]:primary.img

To copy the configuration from the switch and save it in file config1.save using SCP, you would enter the following command within your SSH2 session:
scp [email protected]:configuration.cfg config1.save

SSH2 Client Functions on the Switch

In ExtremeWare version 6.2.1 or later, an Extreme Networks switch can function as an SSH2 client. This means you can connect from the switch to a remote device running an SSH2 server, and send commands to that device. You can also use SCP2 to transfer files to and from the remote device. You do not need to enable SSH2 or generate an authentication key to use the SSH2 and SCP2 commands from the ExtremeWare CLI. To send commands to a remote system using SSH2, use the following command:
ssh2 {cipher [3des | blowfish]} {port <portnum>} {compression [on | off]} {user <username>} {debug <debug_level>} {<username>@} [<host> | <ipaddress>] <remote commands>

The remote commands can be any commands acceptable by the remote system. You can specify the login user name as a separate argument, or as part of the user@host specification. If the login user name for the remote system is the same as your user name on the switch, you can omit the username parameter entirely. To initiate a file copy from a remote system to the switch using SCP2, use the following command:
scp2 {cipher [3des | blowfish]} {port <portnum>} {debug <debug_level>} <user>@[<hostname> | <ipaddress>]:<remote_file> [configuration {incremental} | image [primary | secondary] | bootrom]

To initiate a file copy to a remote system from the switch using SCP2, use the following command:
scp2 {cipher [3des | blowfish]} {port <portnum>} {debug <debug_level>} configuration <user>@[<hostname> | <ipaddress>]:<remote_file>

272

ExtremeWare 7.1.0 Software User Guide

Part 2

Using Switching and Routing Protocols

12 Ethernet Automatic Protection Switching

This chapter describes the use of the Ethernet Automatic Protection Switching (EAPS) protocol, and includes information on the following topics: Overview of the EAPS Protocol on page 275 Fault Detection and Recovery on page 278 Multiple EAPS Domains Per Switch on page 280 Configuring EAPS on a Switch on page 282 Configuring EAPS Shared Ports on page 289 EAPS Shared Port Configuration Rules on page 293 EAPS Shared Port Configuration Examples on page 293

Overview of the EAPS Protocol

The EAPS protocol provides fast protection switching to layer 2 switches interconnected in an Ethernet ring topology, such as a Metropolitan Area Network (MAN) or large campuses (see Figure 38). EAPS protection switching is similar to what can be achieved with the Spanning Tree Protocol (STP), but offers the advantage of converging in less than a second when a link in the ring breaks. In order to use EAPS, you must enable EDP on the switch and EAPS ring ports. For more information on EDP, see Chapter 4. EAPS operates by declaring an EAPS domain on a single ring. Any VLAN that warrants fault protection is configured on all ring ports in the ring, and is then assigned to an EAPS domain. On that ring domain, one switch, or node, is designated the master node (see Figure 39), while all other nodes are designated as transit nodes.

ExtremeWare 7.1.0 Software User Guide

275

Ethernet Automatic Protection Switching

Figure 38: Gigabit Ethernet fiber EAPS MAN ring

Transit node Transit node

Gigabit Ethernet Fiber EAPS MAN ring Transit node

Transit node

Master node

EW_070

One port of the master node is designated the master nodes primary port (P) to the ring; another port is designated as the master nodes secondary port (S) to the ring. In normal operation, the master node blocks the secondary port for all non-control traffic belonging to this EAPS domain, thereby avoiding a loop in the ring, like STP. Layer 2 switching and learning mechanisms operate per existing standards on this ring.

NOTE Like the master node, each transit node is also configured with a primary port and a secondary port on the ring, but the primary/secondary port distinction is ignored as long as the node is configured as a transit node.

276

ExtremeWare 7.1.0 Software User Guide

Overview of the EAPS Protocol

Figure 39: EAPS operation

S4 S3 S5

S2 P S1
Direction of health-check message

S6 S
Secondary port is logically blocked Master node

EW_071

If the ring is complete, the master node logically blocks all data traffic in the transmit and receive directions on the secondary port to prevent a loop. If the master node detects a break in the ring, it unblocks its secondary port and allows data traffic to be transmitted and received through it.

EAPS Terms
Table 37 describes terms associated with EAPS. Table 37: EAPS Terms
Term EAPS domain Description A domain consists of a series of switches, or nodes, that comprise a single ring in a network. An EAPS domain consists of a master node, transit nodes, and on the master node, one primary port and one secondary port. EAPS operates by declaring an EAPS domain on a single ring. Extreme Discovery Protocol. A protocol used to gather information about neighbor Extreme switches. Extreme switches use EDP to exchange topology information. A switch, or node, that is designated the master in an EAPS domain ring. The master node blocks the secondary port for all non-control traffic belonging to this EAPS domain, thereby avoiding a loop in the ring. A switch, or node, that is not designated a master in an EAPS domain ring. A port on the master node that is designated the primary port to the ring. The transit node ignores the primary port distinction as long as the node is configured as a transit node. A port on the master node that is designated the secondary port to the ring. The transit node ignores the secondary port distinction as long as the node is configured as a transit node. A VLAN that sends and receives EAPS messages. You must configure one control VLAN for each EAPS domain.

EDP master node

transit node primary port

secondary port

control VLAN

ExtremeWare 7.1.0 Software User Guide

277

Ethernet Automatic Protection Switching

Table 37: EAPS Terms (continued)

Term protected VLAN common link controller partner Description A VLAN that carries data traffic through an EAPS domain. You must configure one or more protected VLANs for each EAPS domain. (Also known as data VLAN). The physical link between the controller and partner nodes in a network where multiple EAPS domains share a common link between them. The end of a common link responsible for blocking ports if the common link fails thereby preventing a superloop. The other end of a common link. This end does not participate in any form of blocking.

Fault Detection and Recovery

EAPS fault detection on a ring is based on a single control VLAN per EAPS domain. This EAPS domain provides protection to one or more data-carrying VLANs called protected VLANs. The control VLAN is used only to send and receive EAPS messages; the protected VLANs carry the actual data traffic. As long as the ring is complete, the EAPS master node blocks the protected VLANs from accessing its secondary port.

NOTE The control VLAN is not blocked. Messages sent on the control VLAN must be allowed into the switch for the master node to determine whether the ring is complete. To avoid loops in the network, the control VLAN must be NOT be configured with an IP address, and ONLY ring ports may be added to the VLAN. Figure 40: EAPS fault detection and protection switching

Break in ring

S4

S4 sends "link down" message to master node

S3
S3 sends "link down" message to master node

S5

S2 P S1 S

S6

Master node opens secondary port to allow traffic to pass Master node

EW_072

278

ExtremeWare 7.1.0 Software User Guide

Fault Detection and Recovery

A master node detects a ring fault in one of three ways: Link-down message sent by a transit node Ring port down event sent by hardware layers Polling response

Link Down Message Sent by a Transit Node

When any transit node detects a loss of link connectivity on any of its ring ports, it immediately sends a link down message on the control VLAN using its good link to the master node. When the master node receives the link down message (see Figure 40), it immediately declares a failed state and opens its logically blocked secondary port on all the protected VLANs. Now, traffic can flow through the master s secondary port. The master node also flushes its FDB and sends a message on the control VLAN to all of its associated transit nodes to flush their forwarding databases as well, so that all of the switches can learn the new paths to layer 2 end stations on the reconfigured ring topology.

Ring Port Down Event Sent by Hardware Layer

When a ring port goes down on a master node switch, it is notified by the lower hardware layer and immediately goes into a failed state. If the primary ring port goes down, the secondary port is opened. The normal operation of flushing its FDB and sending a link-down message to all transit nodes is performed.

Polling
The master node transmits a health-check packet on the control VLAN at a user-configurable interval (see Figure 39). If the ring is complete, the master node will receive the health-check packet on its secondary port (the control VLAN is not blocked on the secondary port). When the master node receives the health-check packet, it resets its failtimer and continues normal operation. If the master node does not receive the health-check packet before the failtimer interval expires, and the failtime expiry action is set to open-secondary-port, it declares a failed state and performs the same steps described above: it unblocks its secondary port for access by the protected VLANs, flushes its forwarding database (FDB), and sends a flush FDB message to its associated transit nodes.

Restoration Operations
The master node continues sending health-check packets out its primary port even when the master node is operating in the failed state. As long as there is a break in the ring, the fail-period timer of the master node will continue to expire and the master node will remain in the failed state. When the broken link is restored, the master will receive its health-check packet back on its secondary port, and will once again declare the ring to be complete. It will logically block the protected VLANs on