ALCATEL-LUCENT Enterprise Sollutions Div.

IP Networking Portfolio I

IP Networking Solutions with OmniSwitch 6850 Product Family Boilerplate Document

Table of Contents
Disclaimer _____________________________________________________________________19 Trademark Text _________________________________________________________________19 Revision History ________________________________________________________________19 Alcatel-Lucent Company Background _______________________________________________20 About Boilerplate _______________________________________________________________21 About Alcatel-Lucent O/S (AOS) ___________________________________________________22 OmniSwitch 6850 Series / Marketing ________________________________________________23
Introduction _________________________________________________________________________ 23 The OmniSwitch 6850 Family __________________________________________________________ 24
Key Customer Benefits ________________________________________________________________________ 24 Power Supply Options _________________________________________________________________________ 32 Gigabit Ethernet at the Edge ____________________________________________________________________ 33 Intelligence at the Core ________________________________________________________________________ 33 Performance ________________________________________________________________________________ 33 10-Gigabit Ethernet Applications ________________________________________________________________ 33 Carrier-Class for the Enterprise __________________________________________________________________ 34 Secure Networking ___________________________________________________________________________ 34 Alcatel-Lucent Access Guardian and OmniVista 2770 Quarantine Manager _________________________ 35 High Availability _____________________________________________________________________________ 35 Advanced QoS_______________________________________________________________________________ 36 IPv6 Support ________________________________________________________________________________ 36 Compliancy _________________________________________________________________________________ 36 WebView ___________________________________________________________________________________ 36 CLI _______________________________________________________________________________________ 36 Simplified Manageability ______________________________________________________________________ 37 OneTouch Network Management ____________________________________________________________ 37

OmniSwitch 6850 Series / Technical ________________________________________________38

Network Positioning and Applications ___________________________________________________ 38
Gigabit to the Desktop Applications ______________________________________________________________ 39 Server Aggregation ___________________________________________________________________________ 40 L3 Aggregation/Distribution ____________________________________________________________________ 41 Enterprise Small Core Capacity _________________________________________________________________ 42 Residential / Metro Triple-play Ethernet Access _____________________________________________________ 43 Triple-Play Switching _________________________________________________________________________ 44 Combo Port Application Example ________________________________________________________________ 44

Hardware Overview __________________________________________________________________ 45

OmniSwitch 6850 Series _______________________________________________________________________ 45 OmniSwitch 6850-24 _______________________________________________________________________ 51 OmniSwitch 6850-24 Specifications __________________________________________________________ 52 OmniSwitch 6850-48 _______________________________________________________________________ 53 OmniSwitch 6850-48 Specifications __________________________________________________________ 54 OmniSwitch 6850-24X______________________________________________________________________ 55 OmniSwitch 6850-24X Specifications ________________________________________________________ 56 OmniSwitch 6850-48X______________________________________________________________________ 57 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 1 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-48X Specifications ________________________________________________________ 58 OmniSwitch 6850-P24 ______________________________________________________________________ 59 OmniSwitch 6850-P24 Specifications _________________________________________________________ 60 OmniSwitch 6850-P48 ______________________________________________________________________ 61 OmniSwitch 6850-P48 Specifications _________________________________________________________ 62 OmniSwitch 6850-P24X ____________________________________________________________________ 63 OmniSwitch 6850-P24X Specifications _______________________________________________________ 64 OmniSwitch 6850-P48X ____________________________________________________________________ 65 OmniSwitch 6850-P48X Specifications _______________________________________________________ 66 OmniSwitch 6850-U24X ____________________________________________________________________ 67 OmniSwitch 6850-U24X Specifications _______________________________________________________ 68 OmniSwitch 6850-24L ______________________________________________________________________ 69 OmniSwitch 6850-24L Specifications_________________________________________________________ 70 OmniSwitch 6850-P24L ____________________________________________________________________ 71 OmniSwitch 6850-P24L Specifications _______________________________________________________ 72 OmniSwitch 6850-48L ______________________________________________________________________ 73 OmniSwitch 6850-48L Specifications_________________________________________________________ 74 OmniSwitch 6850-P48L ____________________________________________________________________ 75 OmniSwitch 6850-P48L Specifications _______________________________________________________ 76 Rear Panel _______________________________________________________________________________ 77 Status LEDs ______________________________________________________________________________ 78 10/100/1000 LEDs________________________________________________________________________ 79 1000 SFP LEDs __________________________________________________________________________ 79 10000 XFP LEDs ________________________________________________________________________ 79 Chassis Rear Panel ___________________________________________________________________________ 79 Architecture _________________________________________________________________________________ 80 The OmniSwitch 6850-48 & P48 Internal Architecture ___________________________________________ 80 The OmniSwitch 6850-48X & P48X Internal Architecture ________________________________________ 81 The OmniSwitch 6850-24 & P24 Internal Architecture ___________________________________________ 82 The OmniSwitch 6850-24X & P24X Internal Architecture ________________________________________ 83 OmniSwitch 6850 -- Fiber Optics Transceivers Technical Specifications Overview _________________________ 84 Small Form Factor Pluggable (SFP M SA) _____________________________________________________ 86 Handling Fiber and Fiber Optic Connectors ___________________________________________________ 87 Coarse Wave Division Multiplexing (CWDM) __________________________________________________ 98 10Gbps Small Form Factor Pluggable (XFPs) _________________________________________________ 102 Eye Safety _____________________________________________________________________________ 102 XFP-10G Specifications __________________________________________________________________ 103 Pin-Outs ___________________________________________________________________________________ 105 RJ-45 Console Port Connector Pinouts _____________________________________________________ 105 RJ-45 Console Port Connector Pinouts _____________________________________________________ 105 10/100M bps Ethernet Port RJ-45 Pinouts (Non-PoE) ___________________________________________ 105 Pow er over Ethernet Port RJ-45 Pinouts (with PoE) ___________________________________________ 105 1 Gigabit Ethernet Port RJ-45 Pinouts (Non-PoE)______________________________________________ 105 10/100/1000Mbps Power over Ethernet Port -RJ-45 Pinouts _____________________________________ 106 Console Port / Serial Connection Default Settings ______________________________________________ 106 OS6850 DB-25 POWER CONNECTOR PIN-OUT _____________________________________________ 107 Availability Feature __________________________________________________________________________ 108 Software Rollback ________________________________________________________________________ 108 Backup Power Supplies ____________________________________________________________________ 108 Hot Swapping ____________________________________________________________________________ 108 Hardware Monitoring _____________________________________________________________________ 109 Automatic Monitoring ____________________________________________________________________ 109 LEDs _________________________________________________________________________________ 109 User-Driven Monitoring __________________________________________________________________ 109 Auto negotiation Guidelines ___________________________________________________________________ 109 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 2 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Valid Port Settings on OmniSwitch 6850 Series Switches ____________________________________________ 109 10/100/1000 Crossover Supported ______________________________________________________________ 109 10/100 Crossover Supported ___________________________________________________________________ 109 The OmniSwitch 6850 Series Power Supply System ________________________________________________ 110 Pow er Supply Shelf _______________________________________________________________________ 111 Pow er Supply Redundancy _________________________________________________________________ 111 Monitoring Chassis Pow er _________________________________________________________________ 111 Pow er Supply Specifications ________________________________________________________________ 112 Pow er Supply Shelf _______________________________________________________________________ 115 PS-510W-AC Power Supply ________________________________________________________________ 115 PS-360W-AC Power Supply ________________________________________________________________ 116 PS-126W-AC Power Supply ________________________________________________________________ 117 PS-120W-DC Power Supply ________________________________________________________________ 117 Managing OmniSwitch 6850 Series Stacks ________________________________________________________ 118 OmniSwitch 6850 Series Stack Overview _____________________________________________________ 118 Roles w ithin the Stack _____________________________________________________________________ 118 Primary and Secondary Management ________________________________________________________ 118 Primary Management Module Selection ______________________________________________________ 118 Using the Chassis MAC Address ___________________________________________________________ 119 Using Saved Slot Information ______________________________________________________________ 119 Using Switch Uptime ____________________________________________________________________ 119 Secondary Management Module Selection ____________________________________________________ 119 Using the Stacking Connection to the Primary Switch ___________________________________________ 119 Using Saved Slot Information ______________________________________________________________ 119 Idle Module Role _________________________________________________________________________ 120 Pass-Through Mode ______________________________________________________________________ 120 Stack Cabling ____________________________________________________________________________ 121 Redundant Stacking Cable Connection _______________________________________________________ 122 Slot Numbering __________________________________________________________________________ 122 Dynamic Slot Number Assignment __________________________________________________________ 122 Manual Slot Number Assignment ___________________________________________________________ 122 Hot-Swapping Modules in a Stack ___________________________________________________________ 123 Removing Switches from an Existing Stack ___________________________________________________ 123 Inserting Sw itches into an Existing Stack _____________________________________________________ 123 M erging Stacks __________________________________________________________________________ 123 Reloading Switches _______________________________________________________________________ 124 Reloading the Primary Management Module __________________________________________________ 124 Reloading the Secondary Management Module ________________________________________________ 124 Reloading Switches with Idle Roles _________________________________________________________ 124 Reloading Switches in Pass-Through Mode ___________________________________________________ 124 Reloading All Switches in a Stack___________________________________________________________ 124 Software Synchronization During a Full Reload ________________________________________________ 124 Effects of Saved Slot Number Information on the Reload Process __________________________________ 125 Avoiding Split Stacks _____________________________________________________________________ 125 Changing the Secondary Module to Primary __________________________________________________ 126 Synchronizing Switches in a Stack ___________________________________________________________ 126 Automatic Synchronization during a Full Reload ______________________________________________ 126 Monitoring the Stack______________________________________________________________________ 126 Visually Monitoring the Stack______________________________________________________________ 126 Managing Power over Ethernet (PoE) ____________________________________________________________ 127 Pow er over Ethernet Specifications __________________________________________________________ 127 Pow er over Ethernet Defaults ______________________________________________________________ 128 Port Priority Levels _______________________________________________________________________ 128 Capacitor Detection Method________________________________________________________________ 128 Understanding Priority Disconnect __________________________________________________________ 128 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 3 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Monitoring Power over Ethernet via CLI _____________________________________________________ 129 Pow er Cords _____________________________________________________________________________ 130 Specifications __________________________________________________________________________ 130 Redundant AC Circuit Recommendation _____________________________________________________ 130 Grounding the Chassis ____________________________________________________________________ 130 Temperature Management _____________________________________________________________________ 130

MTBF Calculation Standards and Requirements _________________________________________ 131 MTBF Calculation Standards and Requirements _________________________________________ 131 Regulatory Compliance and Safety Information __________________________________________ 148
Declaration of Conformity: CE Mark ____________________________________________________________ 148 Waste Electrical and Electronic Equipment (WEEE) Statement ________________________________________ 148 Standards Compliance ________________________________________________________________________ 148 Safety Standards _________________________________________________________________________ 148 EMC Standards __________________________________________________________________________ 149 Safety and Environmental Standards ________________________________________________________ 149 FCC Class A, Part 15 _____________________________________________________________________ 149 Canada Class A Statement _________________________________________________________________ 150 JATE ___________________________________________________________________________________ 150 CISPR22 Class A Warning _________________________________________________________________ 150 VCCI ___________________________________________________________________________________ 150 Class A Warning for Taiwan and Other Chinese M arkets _______________________________________ 150

Translated Safety Warnings ___________________________________________________________ 151

Important Warnings __________________________________________________________________________ 151 Blank Panels Warning ____________________________________________________________________ 151 Electrical Storm Warning __________________________________________________________________ 151 Installation Warning ______________________________________________________________________ 151 Invisible Laser Radiation Warning __________________________________________________________ 151 Lithium Battery Warning __________________________________________________________________ 151 Operating Voltage Warning ________________________________________________________________ 151 Pow er Disconnection Warning ______________________________________________________________ 151 Proper Earthing Requirement Warning ______________________________________________________ 151 Read Important Safety Information Warning _________________________________________________ 152 Restricted Access Location Warning _________________________________________________________ 152 Wrist Strap Warning _____________________________________________________________________ 152

OmniSwitch 6850 Series Hardware & Software Features Overview Table ___________________ 153 Alcatel-Lucent AOS Release Briefs _____________________________________________________ 218
OVERVIEW _______________________________________________________________________________ 218 Whats New? ____________________________________________________________________________ 219 New Software Features (AOSv6.1.3r01) __________________________________________________________ 219 Feature Summary ________________________________________________________________________ 219 New Software Features (AOSv6.1.5r01) __________________________________________________________ 220 Feature Summary ________________________________________________________________________ 220 New Software Features (AOSv6.2.1r01) __________________________________________________________ 220 Feature Summary ________________________________________________________________________ 220 New Software Features (AOSv6.3.1r01) __________________________________________________________ 221 Feature Summary ________________________________________________________________________ 222 Software Supported __________________________________________________________________________ 223 Feature Summary ________________________________________________________________________ 223

OmniSwitch 6850 Series IETF / IEEE Standards ________________________________________ 315 OmniSwitch 6850 Series Typical RFP Questions & Answers Table _________________________ 320
OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 4 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Alcatel-Lucent AOS Value Propositions_____________________________________________333

Value ______________________________________________________________________________ 333 High Availability ____________________________________________________________________ 335
The Spanning Tree Algorithm and Protocol (STP) __________________________________________________ 337 Spanning Tree Specifications _______________________________________________________________ 337 Spanning Tree Bridge Parameter Defaults ____________________________________________________ 337 Spanning Tree Port Parameter Defaults ______________________________________________________ 338 M ultiple Spanning Tree (MST) Region Defaults _______________________________________________ 338 Ring Rapid Spanning Tree (RRSTP) Defaults _________________________________________________ 338 Spanning Tree Overview __________________________________________________________________ 339 How the Spanning Tree Topology is calculated ________________________________________________ 339 Bridge Protocol Data Units (BPDU) _________________________________________________________ 341 Topology Examples _______________________________________________________________________ 342 Spanning Tree Operating Modes ____________________________________________________________ 344 Using Flat Spanning Tree Mode ____________________________________________________________ 344 Using 1x1 Spanning Tree Mode ____________________________________________________________ 345 Using 1x1 Spanning Tree Mode with PVST+ __________________________________________________ 346 OmniSwitch PVST+ Interoperability ________________________________________________________ 346 802.1q Tagged VLANs ___________________________________________________________________ 346 BPDU Processing in PVST+ Mode__________________________________________________________ 346 Recommendations and Requirements for PVST+ Configurations __________________________________ 346 Configuring STP Bridge Parameters _________________________________________________________ 347 Bridge Configuration Commands Overview ___________________________________________________ 348 Bridge Priority ___________________________________________________________________________ 348 Bridge Hello Time ________________________________________________________________________ 348 Bridge Max Age Time _____________________________________________________________________ 349 Bridge Forward Delay Time ________________________________________________________________ 349 Using Automatic VLAN Containment ________________________________________________________ 350 Configuring STP Port Parameters ___________________________________________________________ 351 Bridge Configuration Commands Overview ___________________________________________________ 351 Enabling/Disabling Spanning Tree on a Port __________________________________________________ 351 Spanning Tree on Link Aggregate Ports ______________________________________________________ 351 Configuring Port Priority__________________________________________________________________ 352 Port Priority on Link Aggregate Ports ________________________________________________________ 352 Configuring Port Path Cost ________________________________________________________________ 352 Path Cost for Link Aggregate Ports__________________________________________________________ 353 Configuring Port Mode ___________________________________________________________________ 354 Mode for Link Aggregate Ports_____________________________________________________________ 354 Configuring Port Connection Type __________________________________________________________ 354 Connection Type on Link Aggregate Ports ____________________________________________________ 355 Using RRSTP ____________________________________________________________________________ 355 Sample Spanning Tree Configuration ________________________________________________________ 356 IEEE 802.1s Multiple Spanning Tree ____________________________________________________________ 357 M ST Specifications _______________________________________________________________________ 357 Spanning Tree Bridge Parameter Defaults ____________________________________________________ 357 Spanning Tree Port Parameter Defaults ______________________________________________________ 358 M ST Region Defaults _____________________________________________________________________ 358 M ST General Overview ___________________________________________________________________ 358 How MSTP Works _______________________________________________________________________ 358 Comparing MSTP with STP and RSTP ______________________________________________________ 360 What is a Multiple Spanning Tree Instance (MSTI) ____________________________________________ 360 What is a Multiple Spanning Tree Region ____________________________________________________ 361 What is the Common Spanning Tree _________________________________________________________ 362 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 5 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

What is the Internal Spanning Tree (IST) Instance _____________________________________________ 362 What is the Common and Internal Spanning Tree Instance ______________________________________ 362 Understanding Spanning Tree Modes ________________________________________________________ 362 M ST Interoperability and Migration_________________________________________________________ 362 M igrating from Flat Mode STP/RSTP to Flat Mode MSTP ______________________________________ 363 M igrating from 1x1 Mode to Flat Mode M STP ________________________________________________ 363 MAC Retention _____________________________________________________________________________ 364 M AC Retention Defaults ___________________________________________________________________ 364 M AC Retention Overview__________________________________________________________________ 364 How MAC Retention Works _______________________________________________________________ 366 M AC Retention After M ultiple Take-Overs ___________________________________________________ 366 M AC Retention Applications _______________________________________________________________ 367 Link Failure _____________________________________________________________________________ 368 Static (OmniChannel) Link Aggregation__________________________________________________________ 369 Static Link Aggregation Specifications _______________________________________________________ 369 Static Link Aggregation Defaults ____________________________________________________________ 369 Static Link Aggregation Overview ___________________________________________________________ 369 Static Link Aggregation Operation __________________________________________________________ 370 Relationship to Other Features _____________________________________________________________ 370 Dynamic (IEEE 802.3ad) Link Aggregation _______________________________________________________ 371 Dynamic Link Aggregation Specifications ____________________________________________________ 371 Dynamic Link Aggregation Default Values____________________________________________________ 372 Dynamic Link Aggregation Overview ________________________________________________________ 372 Dynamic Link Aggregation Operation _______________________________________________________ 373 Relationship to Other Features _____________________________________________________________ 373

Embedded Security __________________________________________________________________ 374

Learned Port Security ________________________________________________________________________ 375 Learned port Security Specifications _________________________________________________________ 375 Learned port Security Defaults _____________________________________________________________ 375 Learned Port Security Overview ____________________________________________________________ 376 How LPS Authorizes Source M AC Addresses _________________________________________________ 376 Dynamic Configuration of Authorized MAC Addresses _________________________________________ 377 Static Configuration of Authorized M AC Addresses ____________________________________________ 377 Understanding the LPS Table ______________________________________________________________ 377 Selecting the Security Violation Mode ________________________________________________________ 377 IP-Directed Broadcasts _______________________________________________________________________ 378 Denial of Service (DoS) Filtering _______________________________________________________________ 378 Authenticated VLANs (A-VLANs)______________________________________________________________ 379 Authenticated Network Overview ___________________________________________________________ 379 Authentication Clients_____________________________________________________________________ 380 Telnet Authentication Client _______________________________________________________________ 380 Web Browser Authentication Client _________________________________________________________ 380 SSL for Web Browser Clients ______________________________________________________________ 380 The AV-Client __________________________________________________________________________ 381 The AV-Client & DHCP __________________________________________________________________ 381 Delay for IP Address Request ______________________________________________________________ 381 Releasing the IP Address__________________________________________________________________ 381 Port Binding and Authenticated VLANs ______________________________________________________ 382 The Server Authority Mode ________________________________________________________________ 382 Single Mode ___________________________________________________________________________ 382 Multiple Mode __________________________________________________________________________ 382 User Network Profile_____________________________________________________________________ 383 IEEE 802.1X _______________________________________________________________________________ 384 IEEE 802.1X Specifications ________________________________________________________________ 384 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 6 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

IEEE 802.1X Defaults _____________________________________________________________________ 384 802.1X Overview _________________________________________________________________________ 385 802.1X Port Behavior ____________________________________________________________________ 385 802.1X Ports and DHCP __________________________________________________________________ 386 Re-authentication________________________________________________________________________ 386 802.1X Accounting ______________________________________________________________________ 386 Compared to Authenticated VLANs _________________________________________________________ 386 Port-Based Network Access Control _________________________________________________________ 386 802.1X on the OmniSwitch 6850 ____________________________________________________________ 387 Device Classification Policies ______________________________________________________________ 387 Port Mapping (AKA Private VLAN) ____________________________________________________________ 388 Port Mapping Specifications________________________________________________________________ 388 Port Mapping Defaults ____________________________________________________________________ 388 Example Port Mapping Overview ___________________________________________________________ 389 Access Control Lists -- ACLs __________________________________________________________________ 390 ACL Specifications _______________________________________________________________________ 390 ACL Defaults ____________________________________________________________________________ 390 ACL Overview ___________________________________________________________________________ 391 Rule Precedence ________________________________________________________________________ 391 How Precedence is Determined_____________________________________________________________ 392 Interaction With Other Features ____________________________________________________________ 392 Valid Combinations______________________________________________________________________ 392 ACL Configuration Overview ______________________________________________________________ 392 Policy Conditions For ACLs _______________________________________________________________ 393 Policy Actions For ACLs _________________________________________________________________ 393 Layer 2 ACLs __________________________________________________________________________ 394 Layer 3/4 ACLs _________________________________________________________________________ 394 Multicast Filtering ACLs__________________________________________________________________ 395 Using ACL Security Features ______________________________________________________________ 396 ACL Manager (ACLMAN) ____________________________________________________________________ 397 ACLMAN Defaults _______________________________________________________________________ 397 ACLMAN Overview ______________________________________________________________________ 397 ACLMAN Configuration File_______________________________________________________________ 397 ACL Text Files ___________________________________________________________________________ 398 ACL Precedence _________________________________________________________________________ 398 Interaction With the Alcatel-Lucent CLI _____________________________________________________ 398 Using the ACLMAN Shell__________________________________________________________________ 398 ACLMAN Modes and Commands ___________________________________________________________ 399 Supported Protocols and Services ___________________________________________________________ 399 Network Security ____________________________________________________________________________ 401 Network Security Specifications _____________________________________________________________ 401 Network Security Defaults _________________________________________________________________ 401 Network Security Overview ________________________________________________________________ 402 Anomalies _____________________________________________________________________________ 402 Monitoring Group _______________________________________________________________________ 403 Anomaly parameters Description ___________________________________________________________ 403

Distributed Intelligence _______________________________________________________________ 404

VLANs ___________________________________________________________________________________ 406 VLAN Specifications ______________________________________________________________________ 406 VLAN Defaults __________________________________________________________________________ 406 VLAN Management Overview ______________________________________________________________ 407 Creating/Modifying VLANs ________________________________________________________________ 407 Enabling/Disabling Spanning Tree for a VLAN ________________________________________________ 408 VLAN Authentication _____________________________________________________________________ 408 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 7 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

VLAN Router Interfaces ___________________________________________________________________ 408 Single M AC Router Mode _________________________________________________________________ 408 Defining V LAN Port Assignments ______________________________________________________________ 409 Port Assignment Specifications _____________________________________________________________ 409 Port Assignment Defaults __________________________________________________________________ 409 Statically Assigning Ports to VLANs _________________________________________________________ 410 Dynamically Assigning Ports to VLANs ______________________________________________________ 410 How Dynamic Port Assignment Works _______________________________________________________ 410 VLAN Mobile Tag Classification ____________________________________________________________ 410 VLAN Rule Classif ication __________________________________________________________________ 411 Ignoring B ridge Protocol Data Units (BPDU) __________________________________________________ 411 Understanding M obile Port Properties _______________________________________________________ 412 What is a Configured Default VLAN?________________________________________________________ 412 What is a Secondary VLAN? _______________________________________________________________ 412 Mobile Port Properties ____________________________________________________________________ 412 Defining V LAN Rules ________________________________________________________________________ 413 VLAN Rules Specifications _________________________________________________________________ 413 VLAN Rules Defaults _____________________________________________________________________ 413 VLAN Rules Overview ____________________________________________________________________ 413 VLAN Rule Types ________________________________________________________________________ 414 DHCP Rules ___________________________________________________________________________ 414 Binding Rules __________________________________________________________________________ 415 MAC Address & MAC Address Range Rules__________________________________________________ 415 Network Address Rules ___________________________________________________________________ 415 Protocol Rules __________________________________________________________________________ 416 Port Rules _____________________________________________________________________________ 416 Understanding VLAN Rule Precedence ______________________________________________________ 416 IEEE 802.1Q _______________________________________________________________________________ 417 802.1Q Specifications _____________________________________________________________________ 417 802.1Q Defaults __________________________________________________________________________ 417 802.1Q Overview _________________________________________________________________________ 417 Forcing a Sw itch Internal Tag ______________________________________________________________ 417 GVRP ____________________________________________________________________________________ 418 GVRP Specifications ______________________________________________________________________ 418 GVRP Defaults __________________________________________________________________________ 418 GARP Overview _________________________________________________________________________ 419 VLAN Stacking _____________________________________________________________________________ 422 VLAN Stacking Specifications ______________________________________________________________ 422 Service-Based VLAN Stacking Defaults ______________________________________________________ 423 Port-Based VLAN Stacking Defaults _________________________________________________________ 423 VLAN Stacking Overview _________________________________________________________________ 424 How VLAN Stacking Works _______________________________________________________________ 426 VLAN Stacking Modes ____________________________________________________________________ 426 Service Mode___________________________________________________________________________ 426 Legacy Mode ___________________________________________________________________________ 427 Interaction With Other Features ____________________________________________________________ 427 GARP VLAN Registration Protocol (GVRP) __________________________________________________ 427 IP Multicast VLANs _____________________________________________________________________ 427 Link Aggregation________________________________________________________________________ 428 Quality of Service (QoS) __________________________________________________________________ 428 Ring Rapid Spanning Tree Protocol (RRSTP) _________________________________________________ 428 Spanning Tree __________________________________________________________________________ 428 VLAN Stacking Application Examples _______________________________________________________ 429 Ethernet OAM ______________________________________________________________________________ 430 Ethernet OAM Specifications _______________________________________________________________ 430 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 8 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Ethernet OAM Def aults ___________________________________________________________________ 430 Ethernet OAM Overview __________________________________________________________________ 431 Connectivity Fault Management ____________________________________________________________ 431 Internet Protocol (IP) _________________________________________________________________________ 433 IP Specifications _________________________________________________________________________ 433 IP Defaults ______________________________________________________________________________ 433 IP Overview _____________________________________________________________________________ 433 IP Protocols ____________________________________________________________________________ 433 Transport Protocols ______________________________________________________________________ 434 Application-Layer Protocols _______________________________________________________________ 434 Additional IP Protocols ___________________________________________________________________ 434 IP Forwarding ___________________________________________________________________________ 435 Static Route _____________________________________________________________________________ 435 Default Route ____________________________________________________________________________ 435 Address Resolution Protocol (ARP) __________________________________________________________ 436 The Time-to-Live (TTL) Value _____________________________________________________________ 436 Local Proxy ARP _________________________________________________________________________ 436 ARP Filtering ____________________________________________________________________________ 436 IP-Directed Broadcasts ____________________________________________________________________ 437 Denial of Service (DoS) Filtering ____________________________________________________________ 437 IP Services ______________________________________________________________________________ 438 Managing IP_____________________________________________________________________________ 438 Internet Control Message Protocol (ICMP)____________________________________________________ 438 The Minimum Packet Gap_________________________________________________________________ 439 ICMP Control Table _____________________________________________________________________ 439 ICMP Statistics Table ____________________________________________________________________ 439 The Ping Command______________________________________________________________________ 439 Tracing an IP Route______________________________________________________________________ 439 Displaying TCP Information _______________________________________________________________ 439 Displaying UDP Information_______________________________________________________________ 439 Tunneling _______________________________________________________________________________ 440 Generic Routing Encapsulation _____________________________________________________________ 440 IP Encapsulation within IP ________________________________________________________________ 440 Tunneling operation______________________________________________________________________ 440 IPv6 ______________________________________________________________________________________ 441 IPv6 Specifications________________________________________________________________________ 441 IPv6 Defaults ____________________________________________________________________________ 441 IPv6 Overview ___________________________________________________________________________ 442 IPv6 Addressing __________________________________________________________________________ 442 IPv6 Address Notation ____________________________________________________________________ 443 IPv6 Address Prefix Notation _______________________________________________________________ 443 Auto-configuration of IPv6 Addresses ________________________________________________________ 443 Tunneling IPv6 over IPv4 __________________________________________________________________ 444 6to4 Tunnels _____________________________________________________________________________ 444 6to4 Site to 6to4 Site over IPv4 Domain ______________________________________________________ 445 6to4 Site to IPv6 Site over IPv4/IPv6 Domains _________________________________________________ 446 Configured Tunnels _______________________________________________________________________ 446 IPX ______________________________________________________________________________________ 447 IPX Specifications ________________________________________________________________________ 447 IPX Defaults _____________________________________________________________________________ 447 IPX Overview ____________________________________________________________________________ 447 IPX Routing _____________________________________________________________________________ 448 IPX Router Port Configuration Options ______________________________________________________ 448 Static Routes ____________________________________________________________________________ 449 Type-20 Packet Forwarding ________________________________________________________________ 449 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 9 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Extended RIP and SAP Packets _____________________________________________________________ 449 RIP and SAP Timers ______________________________________________________________________ 449 Using the PING Command _________________________________________________________________ 449 IPX RIP/SAP Filtering ____________________________________________________________________ 450 RIP Filters _____________________________________________________________________________ 450 SAP Filters ____________________________________________________________________________ 450 GNS Filters ____________________________________________________________________________ 450 RIP_______________________________________________________________________________________ 451 RIP Specifications ________________________________________________________________________ 451 RIP Defaults _____________________________________________________________________________ 451 RIP Overview ____________________________________________________________________________ 452 RIP Version 2 __________________________________________________________________________ 452 RIP Routing ____________________________________________________________________________ 453 The RIP Interface Metric __________________________________________________________________ 453 The RIP Forced Hold-down Interval _________________________________________________________ 454 RIP Redistribution _______________________________________________________________________ 454 Redistribution Metric_____________________________________________________________________ 454 RIP Redistribution Filter __________________________________________________________________ 454 RIP Security ___________________________________________________________________________ 454 OSPFv2 / OSPFv3 ___________________________________________________________________________ 455 OSPFv2 Specifications ____________________________________________________________________ 455 OSPFv2 Defaults _________________________________________________________________________ 456 OSPFv3 Specifications ____________________________________________________________________ 457 OSPFv3 Defaults _________________________________________________________________________ 457 OSPF Overview __________________________________________________________________________ 458 OSPF Areas ____________________________________________________________________________ 459 Classification of Routers __________________________________________________________________ 460 Virtual Links ___________________________________________________________________________ 460 Stub Areas _____________________________________________________________________________ 461 Not-So-Stubby-Areas ____________________________________________________________________ 461 Totally Stubby Areas ______________________________________________________________________ 462 Equal Cost Multi-Path (ECMP) Routing _____________________________________________________ 463 Non Broadcast OSPF Routing ______________________________________________________________ 463 Graceful Restart on Sw itches w ith Redundant Management _____________________________________ 464 Interface Authentication ___________________________________________________________________ 464 IS-IS _____________________________________________________________________________________ 465 IS-IS Specifications _______________________________________________________________________ 465 IS-IS Defualts Table ______________________________________________________________________ 465 IS-IS Overview ___________________________________________________________________________ 467 IS-IS Packet Types _______________________________________________________________________ 468 IS-IS Areas ______________________________________________________________________________ 469 Graceful Restart on Stacks with Redundant Sw itches ___________________________________________ 470 IS-IS Application Example _________________________________________________________________ 471 BGP ______________________________________________________________________________________ 472 BGP Specifications _______________________________________________________________________ 472 BGP Overview ___________________________________________________________________________ 473 Autonomous Systems (ASs) ________________________________________________________________ 474 Internal vs. External BGP _________________________________________________________________ 475 Communities ____________________________________________________________________________ 476 Route Reflectors _________________________________________________________________________ 477 BGP Confederations ______________________________________________________________________ 478 Policies _________________________________________________________________________________ 479 Regular Expressions ______________________________________________________________________ 480 The Route Selection Process ________________________________________________________________ 480 Route Dampening ________________________________________________________________________ 481 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 10 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

CIDR Route Notation _____________________________________________________________________ 481 Synchronizing BGP and IGP Routes _________________________________________________________ 481 Controlling Route Flapping Through Route Dampening ________________________________________ 482 Example: Flapping Route Suppressed, then Unsuppressed ______________________________________ 482 Setting Up Route Reflection ________________________________________________________________ 483 Working with Communities ________________________________________________________________ 485 Routing Policies __________________________________________________________________________ 485 RDP ______________________________________________________________________________________ 486 RDP Specifications _______________________________________________________________________ 486 RDP Defaults ____________________________________________________________________________ 486 RDP Overview ___________________________________________________________________________ 487 RDP Interfaces__________________________________________________________________________ 488 Security Concerns _______________________________________________________________________ 488 Defining the Advertisement Interval _________________________________________________________ 488 DHCP Relay _______________________________________________________________________________ 489 DHCP Relay Specifications_________________________________________________________________ 489 DHCP Relay Defaults _____________________________________________________________________ 489 DHCP Relay Overview ____________________________________________________________________ 490 DHCP ________________________________________________________________________________ 490 DHCP and the OmniSwitch________________________________________________________________ 490 DHCP Relay and Authentication____________________________________________________________ 491 External DHCP Relay Application __________________________________________________________ 491 Internal DHCP Relay_____________________________________________________________________ 492 DHCP Relay Implementation ______________________________________________________________ 493 Per-VLAN DHCP _______________________________________________________________________ 493 Enabling BOOTP/DHCP Relay_____________________________________________________________ 493 Using Automatic IP Configuration __________________________________________________________ 493 UDP Port Relay __________________________________________________________________________ 494 Configuring DHCP Security Features ________________________________________________________ 494 Using the Relay Agent Information Option (Option-82)__________________________________________ 495 How the Relay Agent Processes DHCP Packets from the Client ___________________________________ 495 How the Relay Agent Processes DHCP Packets from the Server ___________________________________ 495 Using DHCP Snooping ___________________________________________________________________ 496 DHCP Snooping Configuration Guidelines____________________________________________________ 496 VRRP ____________________________________________________________________________________ 497 VRRP Specifications ______________________________________________________________________ 497 VRRP Defaults ___________________________________________________________________________ 497 VRRP Overview _________________________________________________________________________ 498 Why Use VRRP?________________________________________________________________________ 498 Definition of a Virtual Router ______________________________________________________________ 499 VRRP MAC Addresses ___________________________________________________________________ 499 ARP Requests __________________________________________________________________________ 499 ICMP Redirects _________________________________________________________________________ 499 VRRP Startup Delay _____________________________________________________________________ 500 VRRP Tracking _________________________________________________________________________ 500 Interaction With Other Features ____________________________________________________________ 500 Configuration Overview __________________________________________________________________ 500 Basic Virtual Router Configuration__________________________________________________________ 500 The Advertisement Interval ________________________________________________________________ 500 Virtual Router Priority____________________________________________________________________ 501 Preemption for Virtual Routers _____________________________________________________________ 501 VRRP Authentication ____________________________________________________________________ 501 VRRP Traps ___________________________________________________________________________ 502 VRRP Application Example _______________________________________________________________ 502 VRRP Tracking Example _________________________________________________________________ 503 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 11 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

VRRP3 Application Example ______________________________________________________________ 504 VRRP3 Tracking Example ________________________________________________________________ 505 Quality Of Service (QoS) _____________________________________________________________________ 506 QoS Specifications ________________________________________________________________________ 506 QoS General Overview ____________________________________________________________________ 507 QoS Policy Overview ____________________________________________________________________ 507 How Policies Are Used ___________________________________________________________________ 508 Valid Policies __________________________________________________________________________ 508 Interaction With Other Features ____________________________________________________________ 508 Condition Combinations ___________________________________________________________________ 509 Action Combinations ______________________________________________________________________ 510 Condition and Action Combinations _________________________________________________________ 510 QoS Defaults ____________________________________________________________________________ 511 Global QoS Defaults _____________________________________________________________________ 511 QoS Port Defaults _______________________________________________________________________ 511 Policy Rule Defaults _____________________________________________________________________ 512 Policy Action Defaults ___________________________________________________________________ 512 Default (Built-in) Policies _________________________________________________________________ 512 QoS Configuration Overview _______________________________________________________________ 513 Automatic QoS Prioritization _______________________________________________________________ 513 Automatic Prioritization for NMS Traffic ____________________________________________________ 513 Automatic Prioritization for IP Phone Traffic _________________________________________________ 513 Using Quarantine M anager and Remediation _________________________________________________ 514 Using the QoS Log ________________________________________________________________________ 515 Forwarding Log Events to PolicyView / Console _______________________________________________ 515 Classifying Bridged Traffic as Layer 3 _______________________________________________________ 515 The Statistics Interval _____________________________________________________________________ 515 QoS Ports and Queues_____________________________________________________________________ 516 Shared Queues ___________________________________________________________________________ 516 Prioritizing and Queue Mapping ____________________________________________________________ 516 Priority to Queue Mapping Table ___________________________________________________________ 516 Queuing Schemes _________________________________________________________________________ 517 Trusted and Untrusted Ports _______________________________________________________________ 518 Policies _________________________________________________________________________________ 519 ASCII-File-Only Syntax ___________________________________________________________________ 519 Policy Conditions _________________________________________________________________________ 519 Policy Actions ____________________________________________________________________________ 520 Rule Precedence __________________________________________________________________________ 520 How Precedence is Determined_____________________________________________________________ 520 Rules with Compatible Actions _____________________________________________________________ 520 Rules with Conflicting Actions ______________________________________________________________ 520 Testing Conditions ________________________________________________________________________ 521 Using Condition Groups in Policies __________________________________________________________ 521 Using Network Groups ____________________________________________________________________ 521 Using Services & Service Groups ____________________________________________________________ 521 Using MAC Groups _______________________________________________________________________ 522 Using Port Groups ________________________________________________________________________ 522 Port Groups and Maximum Bandwidth ______________________________________________________ 522 Source Port Group Example _______________________________________________________________ 523 Destination Port Group Examples ___________________________________________________________ 523 Using Map Groups _______________________________________________________________________ 524 How Map Groups Work __________________________________________________________________ 524 Policy Applications _______________________________________________________________________ 525 Basic QoS Policies ________________________________________________________________________ 526 Basic Commands ________________________________________________________________________ 526 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 12 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Traffic Prioritization Example______________________________________________________________ 526 Bandwidth Shaping Example ______________________________________________________________ 526 Redirection Policies _______________________________________________________________________ 527 ICM P Policy Example _____________________________________________________________________ 528 802.1p and ToS/DSCP Marking and Mapping _________________________________________________ 529 Policy B ased Routing______________________________________________________________________ 530 Server Load Balancing (SLB) _______________________________________________________________ 531 Server Load Balancing Specifications ________________________________________________________ 531 Server Load Balancing Defaults _____________________________________________________________ 532 Server Load Balancing Overview ___________________________________________________________ 532 Server Load Balancing VIPs/Condition ______________________________________________________ 532 Server Load Balancing Example ____________________________________________________________ 533 Server Health M onitoring __________________________________________________________________ 534 IP Multicast Switching _______________________________________________________________________ 535 IPMS Specifications_______________________________________________________________________ 535 IPv6MS Specifications_____________________________________________________________________ 535 IPMS Default Values ______________________________________________________________________ 536 IPv6MS Default Values ____________________________________________________________________ 536 IPMS Overview __________________________________________________________________________ 537 IPMS Example _________________________________________________________________________ 537 Reserved M ulticast Addresses ______________________________________________________________ 538 IP M ulticast Routing ______________________________________________________________________ 538 PIM __________________________________________________________________________________ 538 DVMRP_______________________________________________________________________________ 538 IPMS and Link Aggregation _______________________________________________________________ 539 IGMP Version 3 __________________________________________________________________________ 539 MLD ___________________________________________________________________________________ 539 IPMS Application Example ________________________________________________________________ 540 Multicast Address Boundaries __________________________________________________________________ 541 M ulticast Boundary Specifications __________________________________________________________ 541 M ulticast Address Boundaries Overview _____________________________________________________ 541 Multicast Addresses and the IANA __________________________________________________________ 541 Administratively Scoped Multicast Addresses _________________________________________________ 541 Source-Specific Multicast Addresses ________________________________________________________ 541 Multicast Address Boundaries______________________________________________________________ 542 Concurrent Multicast Addresses ____________________________________________________________ 542 DVMRP___________________________________________________________________________________ 543 DVMRP Specifications ____________________________________________________________________ 543 DVMRP Defaults _________________________________________________________________________ 543 DVMRP Overview ________________________________________________________________________ 544 Reverse Path Multicasting _________________________________________________________________ 544 Neighbor Discovery _______________________________________________________________________ 545 M ulticast Source Location, Route Report M essages, and M etrics _________________________________ 545 Dependent Dow nstream Routers and Poison Reverse ___________________________________________ 546 Pruning Multicast Traffic Delivery __________________________________________________________ 546 Grafting B ranches Back onto the Multicast Delivery Tree _______________________________________ 546 DVMRP Tunnels _________________________________________________________________________ 547 PIM ______________________________________________________________________________________ 548 PIM Specifications ________________________________________________________________________ 548 PIM Defaults ____________________________________________________________________________ 548 PIM Overview ___________________________________________________________________________ 549 Rendezvous Points (RPs)__________________________________________________________________ 549 Candidate Rendezvous Points (C-RPs) _______________________________________________________ 549 Bootstrap Routers (BSRs) _________________________________________________________________ 549 Candidate Bootstrap Routers (C-BSRs) ______________________________________________________ 550 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 13 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Designated Routers (DRs)_________________________________________________________________ 550 Shared (or RP) Trees _____________________________________________________________________ 550 Avoiding Register Encapsulation ___________________________________________________________ 551 RP Initiation of (S, G) Source-Specific Join Message____________________________________________ 552 SPT Switchover _________________________________________________________________________ 553 PIM-SSM Support ________________________________________________________________________ 555 Source-Specific Multicast Addresses ________________________________________________________ 555 PIM-SSM Specification___________________________________________________________________ 555 IP Multicast VLAN __________________________________________________________________________ 556 IP M ulticast VLAN Specifications ___________________________________________________________ 556 IP M ulticast VLAN Defaults _______________________________________________________________ 556 IP M ulticast VLAN Overview ______________________________________________________________ 557 VLAN Stacking Mode _____________________________________________________________________ 557 IPMVLAN Lookup Mode __________________________________________________________________ 557 Enterprise Mode _________________________________________________________________________ 558 IPMV Packet Flows _______________________________________________________________________ 558 VLAN Stacking Mode _____________________________________________________________________ 558 Enterprise Mode _________________________________________________________________________ 560 IPMVLAN Application Example ____________________________________________________________ 561

Simplified Manageability _____________________________________________________________ 562

Interswitch Protocols _________________________________________________________________________ 564 AIP Specifications ________________________________________________________________________ 564 AMAP Defaults __________________________________________________________________________ 564 AMAP Overview _________________________________________________________________________ 564 Discovery Transmission State ______________________________________________________________ 564 Common Transmission State_______________________________________________________________ 564 Passive Reception State ___________________________________________________________________ 565 Common Transmission and Remote Switches _________________________________________________ 565 IEEE 802.1AB ______________________________________________________________________________ 566 IEEE 802.1AB (LLDAP) Specifications ______________________________________________________ 566 IEEE 802.1AB (LLDP) Defaults _____________________________________________________________ 566 802.1AB Overview ________________________________________________________________________ 567 Managing Authentication Servers _______________________________________________________________ 569 Authentication Server Specifications _________________________________________________________ 569 Server Defaults __________________________________________________________________________ 569 RADIUS Authentication Servers____________________________________________________________ 569 LDAP Authentication Servers ______________________________________________________________ 569 Server Overview _________________________________________________________________________ 570 Backup Authentication Servers _____________________________________________________________ 570 Authenticated Sw itch Access _______________________________________________________________ 570 Authenticated VLANs _____________________________________________________________________ 571 Port-Based Network Access Control (802.1X) _________________________________________________ 571 ACE/Server _____________________________________________________________________________ 572 RADIUS Servers _________________________________________________________________________ 572 RADIUS Server Attributes ________________________________________________________________ 572 LDAP Servers ___________________________________________________________________________ 573 LDAP Server Details _____________________________________________________________________ 573 LDIF File Structure ______________________________________________________________________ 573 Directory Entries ________________________________________________________________________ 573 Directory Searches_______________________________________________________________________ 574 Retrieving Directory Search Results _________________________________________________________ 574 Directory Modifications __________________________________________________________________ 574 Directory Compare and Sort _______________________________________________________________ 575 The LDAP URL ________________________________________________________________________ 575 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 14 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Password Policies and Directory Servers _____________________________________________________ 575 Directory Server Schema for LDAP Authentication _____________________________________________ 575 LDAP Accounting Attributes ______________________________________________________________ 576 SSL for an LDAP Authentication Server _____________________________________________________ 576 Managing Policy Servers ______________________________________________________________________ 576 Policy Server Specifications ________________________________________________________________ 576 Policy Server Defaults _____________________________________________________________________ 576 Policy Server Overview ____________________________________________________________________ 577 Installing the LDAP Policy Server __________________________________________________________ 577 Secure Socket Layer for a Policy Server ______________________________________________________ 577 Interaction With CLI Policies ______________________________________________________________ 577 Diagnosing Switch Problems __________________________________________________________________ 578 UDLD ____________________________________________________________________________________ 578 UDLD Specifications ______________________________________________________________________ 578 UDLD Defaults __________________________________________________________________________ 578 UDLD Overview _________________________________________________________________________ 579 UDLD Operational Mode _________________________________________________________________ 579 Normal Mode __________________________________________________________________________ 579 Aggressive Mode________________________________________________________________________ 579 Mechanisms to Detect Unidirectional Links ___________________________________________________ 579 Neighbor database maintenance ____________________________________________________________ 579 Echo detection __________________________________________________________________________ 580 Port Mirroring ___________________________________________________________________________ 581 Port Mirroring Specifications ______________________________________________________________ 581 Port mirroring Defaults ___________________________________________________________________ 581 Using Port Mirroring with External RMON Probes _____________________________________________ 583 Remote Port M irroring ____________________________________________________________________ 584 Application Example _____________________________________________________________________ 584 Port Monitoring __________________________________________________________________________ 585 Port Monitoring Specifications _____________________________________________________________ 585 Port Monitoring Defaults__________________________________________________________________ 585 Remote Monitoring (RMON) _______________________________________________________________ 586 RMON Specifications ____________________________________________________________________ 586 RMON Probe Defaults ___________________________________________________________________ 586 Ethernet Statistics _______________________________________________________________________ 587 History (Control & Statistics) ______________________________________________________________ 587 Alarm_________________________________________________________________________________ 588 Event _________________________________________________________________________________ 588 Sw itch Health ____________________________________________________________________________ 589 Switch Health Specifications_______________________________________________________________ 589 Switch Health Defaults ___________________________________________________________________ 589 SFlow __________________________________________________________________________________ 591 Switch Logging _____________________________________________________________________________ 592 Sw itch Logging Specifications ______________________________________________________________ 592 Sw itch Logging Defaults ___________________________________________________________________ 592 Sw itch Logging Overview __________________________________________________________________ 593 Displaying Switch Logging Records _________________________________________________________ 594 Monitoring Memory _________________________________________________________________________ 595 M emory M onitoring Specifications __________________________________________________________ 595 M emory M onitoring Defaults _______________________________________________________________ 595 Debug Memory Commands Overview ________________________________________________________ 595 Logging into the Switch ______________________________________________________________________ 596 Logging Specifications_____________________________________________________________________ 596 Login Defaults ___________________________________________________________________________ 596 Overview of Switch Login Components ______________________________________________________ 597 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 15 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Management Interfaces____________________________________________________________________ 597 Logging Into the CLI_____________________________________________________________________ 597 Using the WebView Management Tool ______________________________________________________ 597 Using SNMP to Manage the Switch _________________________________________________________ 597 User Accounts __________________________________________________________________________ 597 Using Telnet _____________________________________________________________________________ 598 Using FTP_______________________________________________________________________________ 598 Using Secure Shell ________________________________________________________________________ 598 Secure Shell Components _________________________________________________________________ 598 Secure Shell Interface ____________________________________________________________________ 599 Secure Shell File Transfer Protocol __________________________________________________________ 599 Secure Shell Application Overview__________________________________________________________ 599 Secure Shell Authentication _______________________________________________________________ 599 Protocol Identification ____________________________________________________________________ 600 Algorithm and Key Exchange ______________________________________________________________ 600 The Login Banner ________________________________________________________________________ 600 The DNS Resolver ________________________________________________________________________ 600 Managing System Files _______________________________________________________________________ 601 File Management Specifications _____________________________________________________________ 601 Sw itch Administration Overview ____________________________________________________________ 601 File Transfer ____________________________________________________________________________ 601 Sw itch Directories ________________________________________________________________________ 602 File and Directory Management ____________________________________________________________ 602 Using Wildcards _________________________________________________________________________ 603 Directory Commands _____________________________________________________________________ 603 Loading Software onto the Switch ___________________________________________________________ 603 Using the Switch as an FTP Server __________________________________________________________ 603 Using the Switch as an FTP Client __________________________________________________________ 604 Using Zmodem _________________________________________________________________________ 604 Registering Software Image Files ____________________________________________________________ 605 Directories on the Switch __________________________________________________________________ 605 Available Image Files _____________________________________________________________________ 605 Setting the System Clock___________________________________________________________________ 606 Setting Date and Time _____________________________________________________________________ 606 Network Time Protocol (NTP) _________________________________________________________________ 607 NTP Specifications________________________________________________________________________ 607 NTP Defaults ____________________________________________________________________________ 607 NTP Overview ___________________________________________________________________________ 607 Stratum _________________________________________________________________________________ 608 Using NTP in a Network ___________________________________________________________________ 609 Authentication ___________________________________________________________________________ 610 Management Specifications ________________________________________________________________ 611 Management Files ________________________________________________________________________ 611 Management Software Directory Structure ___________________________________________________ 611 Where is the Switch Running From? _________________________________________________________ 612 Software Rollback Feature _________________________________________________________________ 612 Redundancy _____________________________________________________________________________ 612 Rebooting the Sw itch______________________________________________________________________ 613 Secondary Management unit Fail Over _______________________________________________________ 613 Other Stackable Units Behavior During Takeover _____________________________________________ 613 Copying the Running Configuration to the Working Directory ___________________________________ 614 Rebooting from the Working Directory ______________________________________________________ 615 Copying the Working Directory to the Certified Directory_______________________________________ 616 Using the CLI ______________________________________________________________________________ 617 CLI Specifications ________________________________________________________________________ 617 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 16 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

CLI Overview ___________________________________________________________________________ 617 Online Configuration _____________________________________________________________________ 617 Offline Configuration Using Configuration Files _______________________________________________ 617 Command Entry Rules and Syntax __________________________________________________________ 618 Text Conventions _________________________________________________________________________ 618 Using Show Commands _________________________________________________________________ 618 Using the No Form______________________________________________________________________ 618 Using Alias Commands __________________________________________________________________ 618 Partial Keyword Completion _______________________________________________________________ 619 Command Help __________________________________________________________________________ 619 CLI Services _____________________________________________________________________________ 620 Command Line Editing ____________________________________________________________________ 620 Syntax Checking _________________________________________________________________________ 620 Prefix Recognition ________________________________________________________________________ 620 Command History ________________________________________________________________________ 620 Logging CLI Commands and Entry Results ___________________________________________________ 620 Customizing the Screen Display _____________________________________________________________ 621 Changing the CLI Prompt _________________________________________________________________ 621 M ultiple User Sessions ____________________________________________________________________ 621 Working With Configuration Files ______________________________________________________________ 621 Configuration File Specifications ____________________________________________________________ 621 Configuration Files Overview_______________________________________________________________ 621 Applying Configuration Files to the Switch ___________________________________________________ 621 Managing Switch User Accounts _______________________________________________________________ 622 User Database Specif ications _______________________________________________________________ 622 User Accounts Defaults ____________________________________________________________________ 622 Overview of User Accounts_________________________________________________________________ 622 Startup Defaults __________________________________________________________________________ 623 Default User Settings ______________________________________________________________________ 623 SNMP Access for a User Account ___________________________________________________________ 624 End-User Profiles ________________________________________________________________________ 624 Managing Switch Security ____________________________________________________________________ 625 Sw itch Security Specifications ______________________________________________________________ 625 Sw itch Security Defaults ___________________________________________________________________ 625 Sw itch Security Overview __________________________________________________________________ 625 Authenticated Sw itch Access _______________________________________________________________ 625 AAA ServersRADIUS or LDAP ___________________________________________________________ 626 Authentication-onlyACE/Server __________________________________________________________ 626 Interaction With the User Database _________________________________________________________ 627 ASA and Authenticated VLANs _____________________________________________________________ 627 Configuring Authenticated Switch Access ____________________________________________________ 627 Accounting for ASA ______________________________________________________________________ 627 Using WebView ____________________________________________________________________________ 628 WebView CLI Defaults ____________________________________________________________________ 628 WebView Overview _______________________________________________________________________ 628 WebView Page Layout ___________________________________________________________________ 628 Banner ________________________________________________________________________________ 629 Toolbar _______________________________________________________________________________ 629 Feature Options _________________________________________________________________________ 629 View/Configuration Area _________________________________________________________________ 629 WebView Help _________________________________________________________________________ 629 Using SNMP _______________________________________________________________________________ 630 SNMP Specifications ______________________________________________________________________ 630 SNMP Defaults __________________________________________________________________________ 630 SNMP Overview _________________________________________________________________________ 631 OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 17 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

SNMP Operations ________________________________________________________________________ 631 Using SNM P for Switch Management ________________________________________________________ 631 Setting Up an SNMP Management Station ____________________________________________________ 632 SNMP Versions __________________________________________________________________________ 632 SNMPv1 ______________________________________________________________________________ 632 SNMPv2 ______________________________________________________________________________ 632 SNMPv3 ______________________________________________________________________________ 632 Using SNM P For Switch Security ___________________________________________________________ 633 Community Strings (SNMPv1 and SNMPv2)__________________________________________________ 633 Encryption and Authentication (SNMPv3) ____________________________________________________ 633 Working with SNMP Traps ________________________________________________________________ 633 Trap Filtering___________________________________________________________________________ 633 Filtering by Trap Families _________________________________________________________________ 633 Filtering By Individual Trap _______________________________________________________________ 634 Authentication Trap______________________________________________________________________ 634 Trap Management ________________________________________________________________________ 634 Replaying Traps_________________________________________________________________________ 634 Absorbing Traps ________________________________________________________________________ 634 Sending Traps to WebView________________________________________________________________ 634 SNMP MIB Inf ormation ___________________________________________________________________ 635 MIB Tables ____________________________________________________________________________ 635 MIB Table Description ___________________________________________________________________ 635

Appendix #1___________________________________________________________________636
SNMP Trap Tables __________________________________________________________________ 636

Appendix #2___________________________________________________________________656
SNMP MIB Tables___________________________________________________________________ 656

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 18 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Disclaimer
The information contained in this document represents the features of the listed Alcatel-Lucent Products. Alcatel-Lucent makes no claims regarding the accuracy of this published information and specifically disclaims all liability for loss or damages of any kind resulting from discussions made or actions taken by any party based on this information. Product inf ormation contained in this document is subject to change and frequent updates without prior notice. Contact your local Alcatel-Lucent representative for the most current information. Copyright 2004 Alcatel-Lucent Internetworking, Inc. All rights reserved. This document will not be reproduced in whole or in part without the express written permission of Alcatel-Lucent Internetworking.

Trademark Text
To protect the Alcatel-Lucent trademark, the following legal text must be inserted in the body of all RFPs, RFIs, and quotations. Alcatel-Lucent is a registered trademark of Alcatel-Lucent, a society anonym organized under the laws of the Republic of France. The first use of Alcatel-Lucent in any documents must include a "" registered trademark symbol.

Revision History
Rev. Preliminary Rev. 1.0 Rev. 2.0 Date: April 2006 June 2006 July 2006 Revision Description Preliminary draft. The OmniSwitch Boilerplate document version 1.0 was published in June 2006. Official Hardware & Software Release: AOSv6.1.2.r03 The OmniSwitch Boilerplate document version 2.0 was published in July 2006. Official Hardware & Software Release: AOSv6.1.2.r03 The OS6850-U24X definition and MTBF values were updated. The OmniSwitch Boilerplate document version 3.0 was published in Feb. 2007. Official Hardware & Software Release: AOSv6.1.3.r01 The OmniSwitch Boilerplate document version 4.0 was published in Nov. 2007. Official Hardware & Software Release: AOSv6.1.5.r01 The OmniSwitch Boilerplate document version 5.0 was published in Nov. 2007. Official Hardware & Software Release: AOSv6.2.1r01 The OmniSwitch Boilerplate document version 6.0 was published in Feb. 2008. Official Hardware & Software Release: AOSv6.3.1r01 The OmniSwitch Boilerplate document version 6.1 was published in Sept. 2008. Modifications to the raw capacily and throughput numbers made to allogh with the calculations for OS6400 Corrections for NEBS complience Removed all references to ASIC , CPU , transceivers vendors

Rev. 3.0 Rev. 4.0 Rev. 5.0 Rev. 6.0 Rev. 6.1

Feb. 2007 Nov. 2007 Nov. 2007 Feb. 2008 Sept. 2008

Rev. 6.1a Rev. 6.1b

Dec. 2008 Feb. 2009

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 19 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Alcatel-Lucent Company Background

About Alcatel-Lucent Alcatel-Lucent (Paris:ALU.PA - News) (NYSE:ALU - News) provides solutions that enable service providers, enterprises and governments worldwide, to deliver voice, data and video communication services to end-users. As a leader in fixed, mobile and converged broadband networking, IP technologies, applications, and services, Alcatel-Lucent offers the endto-end solutions that enable compelling communications services for people at home, at work and on the move. With operations in more than 130 countries, Alcatel-Lucent is a local partner with global reach. The company has the most experienced global services team in the industry, and one of the largest research, technology and innovation organizations in the telecommunications industry. Alcatel-Lucent achieved adjusted proforma revenues of Euro 18.3 billion in 2006 and is incorporated in France, with executive offices located in Paris. [All figures exclude impact of activities transferred to Thales]. For more information, visit Alcatel-Lucent on the Internet: http://www.Alcatel-Lucent.com Alcatel-Lucents vision is to enrich peoples lives by transforming the way the world communicates. Alcatel-Lucent provides solutions that enable service providers, enterprises and governments worldwide, to deliver voice, data and video communication services to end-users. As a leader in fixed, mobile and converged broadband access, carrier and enterprise IP technologies, applications, and services, Alcatel-Lucent offers the end-to-end solutions that enable compelling communications services for people at home, at work and on the move. With 79,000 employees (after the completion of the Thales transaction) and operations in more than 130 countries, Alcatel-Lucent is a local partner with global reach. The company has the most experienced global services team in the industry, and one of the largest Innovation and Technology organizations focused on communications. Alcatel-Lucent achieved combined sales of Euro 18.6 billion* in 2005, and is incorporated in France, with executive offices located in Paris. Organization With a strong focus on complete solutions maximizing value for customers, Alcatel-Lucent is organized around five business groups and four geographic regions. The Wireless, Wire-line, Convergence groups, which make up the Carrier Business Group, are dedicated to serving the needs of the world's service providers. The Enterprise Business Group focuses on meeting the needs of business customers. The Services Business Group designs, deploys, manages and maintains networks worldwide. The company's geographic regions are Europe and North, Europe and South, North America, and Asia-Pacific. Innovation & Technology Alcatel-Lucent today is one of the largest innovation powerhouses in the communications industry, boasting 23,000 research and development experts worldwide, representing a combined R&D investment of Euro 2.7 billion* in 2005, and a portfolio of over 25,000 active patents spanning virtually every technology area. At the core of this innovation is Alcatel-Lucents research, which includes the world-renowned Bell Labs and Research & Innovation groups, providing Alcatel-Lucent with an innovation engine of 1,500 researchers and scientists at the forefront of research into areas such as multimedia and convergent services and applications, new service delivery architectures and platforms, wireless and Wire-line, broadband access, packet and optical networking and transport, network security, enterprise networking and communication services and fundamental research in areas such as nanotechnology, algorithmic, and computer sciences. History Formed from the merger of Alcatel and Lucent Technologies, Alcatel-Lucent combines two entities that share a common lineage that can be traced back to 1986, when Alcatels parent company, CGE (la Compagnie Gnrale dElectricit), acquired ITTs European telecom business. Nearly 60 years earlier, ITT had purchased most of AT&Ts manufacturing operations outside the United States. AT&T was Lucents former parent company. By creating Alcatel-Lucent we are bringing our common lineages back together and starting an exciting new chapter of our history -- creating the worlds first truly global communications solutions provider, with the most complete end-to-end portfolio of solutions and services in the industry.

About Alcatel-Lucent Enterprise Networking Solutions

Alcatel-Lucent delivers standards-based IP communications solutions to a global customer base of over 500,000 small, medium and large enterprises, government agencies, healthcare facilities, and educational institutions. Alcatel-Lucent's award-winning Omni family of IP Communications solutions consists of an extensive portfolio of network switching infrastructure products and IP telephony products built to provide long-term value. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 20 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

About Boilerplate
It is highly recommended that this Boilerplate document be used along with other Related Documents to collectively gather the most up-to-date information required for responding to customers RFPs & RFIs proposals. This document will not contain detailed design/f unctional/configuration, and/or software/hardware architectural specifications. It will only provide an overview of such aforementioned specifications. Alcatel-Lucent Internetworking Boilerplate documents include the following series: AOS OmniSwitch 9000 Series AOS OmniSwitch 7000 Series AOS OmniSwitch 6850 Series AOS OmniSwitch 6800 Series AOS OmniSwitch 6600/6602 Series OmniStack LS 6200 Product Families OmniAccess Wireless LAN (WLAN) Product Families OmniVista Network Management System Alcatel-Lucent Internetworking Sw itching and Routing Product Families --MTBF Legacy Product Families: AOS OmniSw itch 8800 OmniStack 6024/6124/6148/8008 Product Families OmniStack 6300 Product Families XOS OmniAccess 512 Product Family OmniCore 5000 Series XOS Omni Switch/Router (OSR) XOS Product Family XOS OmniSw itch Product Family XOS OmniStack Product Family

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 21 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

About Alcatel-Lucent O/S (AOS)

Alcatel-Lucent solutions for enterprises are changing the way people work and communicate. As the worlds of voice and data come together, Alcatel-Lucent delivers highly-reliable and secure IP telephony and network infrastructure solutions, the industry's leading contact center applications, and a full range of next generation Unified Communications capabilities to a global client base of small, medium and large enterprises. Leading the charge to bring open IP communications to enterprises across any device, any application and any location, Alcatel-Lucent's solutions benefit businesses with smarter IT operations that bring voice and data together, while delivering unified employee communications and superior customer service experiences. Alcatel-Lucent AOS (Alcatel-Lucent Operating System) OmniSwitch product family encompasses the most advanced line of switching and routing platforms that support the same Operating System, the same software & feature set and the same Network Management. This product line meets the most stringent and mission critical networking requirements for the Access layer, the Distribution layer and the Core layer. The AOS OmniSwitch solution consists of the fixed chassis stackable OmniSwitch 6600 series, the fixed chassis stackable OmniSwitch 6800/6850 series, the modular chassis OmniSwitch 7000 Series, and the modular chassis OmniSwitch 9000 Series. This document attempts to provide an overview of the AOS OmniSwitch 9000 Series product family value propositions for the purposes of enabling the customer to build and operate a highly available, highly secure, highly intelligent, and highly manageable Campus Data Network. It is important to note that with the introduction of AOS Release 6.x.x.r0x, a whole new series of advanced software features, including IPv6, will be supported across a new series of advanced Layer-2--Layer-4 switches including with the OS6850 Series and the OS9000 series. Alcatel-Lucent Internetworking Division comprehensive AOS OmniSwitch product portfolio and solutions fit into all layers of an Enterprise network providing the following IP and Ethernet value propositions: Application Performance: Innovative & superior IP communication solution with simplified QoS o Expected application response time for mission-critical applications, voice, & video; simple QoS network configuration; prioritize and control traffic based on policies Network Mobility: Superior & exclusive offering o End-users move around the enterprise with secure network access based on business policies without network administrator intervention Network Security: Competitive without a cost premium o Secure end-user network access (authentication & authorization); control of traffic that enters and exits the network; secure element access; protection of network against attacks; prevent unauthorized use and access to the network elements; maintain audit trail Manageability: Competitive with real policy-based networking o Element management: same configuration capabilities via SNMP, CLI and Web page; multiple levels of admin access; multiple software images; statistics; reporting Centralized management: FCAPS; problem determination and resolution; ease of installation; bulk configuration; back up and restore Availability: Superior without a cost premium o Self-healing network: resilient switches; resilient L2 and L3 protocols to route around failures; resilient server load-balancing; link aggregation; fast recovery from configuration and software upgrade errors; enable convergence in the wiring closet Performance & Scalability: Highly competitive o Access: 10/100 edge (stackable & chassis) & GigE and/or triple speed 10/100/1000Mbps & GigE & 10-GigE with wire-speed L2 or L2/L3 switching in wiring closet; IEEE 802.3af / PoE inline power for voice o Distribution: 10/100 (chassis) & GigE and/or triple speed 10/100/1000Mbps with wire-speed L2 or L2/L3 switching; IEEE 802.3af / PoE inline power for voice o Core: scalable triple speed 10/100/1000Mbps and/or Gigabit Ethernet & 10-GigE (chassis & stackable) ready core with wire-speed L2/L3 switching; maximize use of physical bandwidth

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 22 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850 Series / Marketing

Introduction
OmniSwitch 6850 Series value propositions, to support the Enterprise new challenges include:

Value High Availability Embedded Security Distributed Intelligence Simplified Manageability

The OS6850 switch family is the most versatile line of fixed configuration L3 gigabit switches. It provides: flexible, stackable configurations, power-over-Ethernet, high availability, first-packet wire-speed performance, and dramatically improved network response time. The OmniSwitch 6850 (OS6850) switch family addresses the needs of modern enterprise and triple-play networking with flexible, stackable configurations; power-over-Ethernet, high availability, first-packet wire-speed performance, and dramatically improved network response time. Similar to the existing Alcatel OmniSwitch products, the OS6850 series uses the Alcatel Operating System (AOS), which ensures an easy and economical way to upgrade or deploy a new Ethernet network. The flexible configuration options offered by the OS6850 family make it suitable for a small/medium network in the core or at the edge of a large network. Also, the OS6850 protects your investment with native support of IPv4 and IPv6 switching. Today's enterprise networks require Gigabit Ethernet switches that are feature-rich, reliable, and capable of supporting converged applications at low cost of ownership. Alcatel has addressed these needs with the OS6850 family of switches, which is the most versatile line of fixed configuration L3 Gigabit Ethernet switches. The switches provide: Choice of PoE (Power-over-Ethernet) and non-PoE switches or models Triple-speed 10/100/1000 interfaces and 10Gig uplinks Fast Ethernet interfaces upgradeable to Gigabit via a software license key without any network reconfiguration Gigabit fiber interfaces (SFP) supporting 100BaseX, dual-speed and 1000BaseX optical transceivers Stacking capability for virtual chassis redundancy Power supply choice (AC, DC, PoE) for flexible deployment IPv4 and IPv6 layer-2 and layer-3 switching for future-proof investment Advanced quality of service (QoS) to support mission-critical and triple-play applications This family offers extensive security features for network access control, policy enforcement and attack containment enabling fully secure networks and OmniVista Network Management System (NMS) support for easier operations. The target applications for these versatile LAN switches are: Enterprise workgroups for edge deployments / LAN wiring closets L3 aggregation / distribution layer switches in three-tier networks Small enterprise core switching Ethernet access and aggregation for residential / metro triple-play applications Converged data / voice / video networks

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 23 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The OmniSwitch 6850 Family

Overview Todays enterprise networks require Gigabit Ethernet switches that are feature-rich, faster, and capable of supporting converged applications at a much lower price. Alcatel-Lucent has addressed these needs with the Alcatel-Lucent OmniSwitch 6850 (OS6850) family of switches, a series of fixed configuration switches that provide power over Ethernet (PoE) for easy remote use, quality of service (QoS) to support mission-critical applications, and security from the edge to the core for better availability, reliability and manageability. The Alcatel-Lucent OS6850 series is a feature rich, new line of L3 Gigabit Ethernet switches that are advanced stackable, fixed configuration, power-over-Ethernet capable, triple-speed and 10G uplink switches that provide wire-rate layer-2 switching and layer-3 routing supporting both IPv4 and IPv6. The OmniSwitch 6850s excel at the edge where they deliver line-rate gigabit switching and routing performance along with extensive network security features, enabling corporations to realize the full potential of secured networks. The Alcatel-Lucent OS6850 series of switches delivers extensive network security features that enable corporations to realize the full potential of secure networks. Customers long-term investments are protected by advanced QoS features with an affordable layer-3 price as well as network management that offer advanced security features.

Key Customer Benefits

The new OS6850 switch family addresses the needs of network administrators: flexible, stackable configuration; power over Ethernet, high availability, first-packet wire-speed performance, and dramatically improved network response time. Similar to the other Alcatel-Lucent OmniSwitch, the OS6850 series uses the Alcatel-Lucent Operating System (AOS). This ensures an easy and economical way to upgrade or deploy a new Ethernet network. The flexible configuration options offered by the OS6850 family make the OS6850s suitable for a small/medium network in the core or at the edge. The OS6850 also future proofs the network with support of IPv4 and IPv6. The OmniSwitch 6850 series protects customers' long-term capital interests by including advanced QoS features with an affordable layer-3 price, advanced security features, network management, and lifetime warranties. OS6850 price/performance leadership means that Alcatel-Lucent consistently delivers the performance and functionality that enterprise companies require today and in the future.

Key Technical Advantages

Customer Issue or Need Wide variety of features / Ports at an economical price How we address the issue The Omni product families offer many port / feature option combinations that can fulfill the majority of fixed config switch requirements. Options include: AC and/or DC powered switches - 24 & 48 ports with or without 10GigE uplinks Power-over-Ethernet - 24 or 48 port stackable standard and high P/S The Omni product families provide industry leading price/feature performance with wirespeed packet classification and processing of all packets in a data stream, including the first packet. Supports advanced services such as 10GigE, PoE, and IPv6. The Omni product families provide extensive security through: Network access control by flexible and powerful authentication mechanisms - 802.1x, MAC-based authentication, authenticated VLANs, PKI Best in class VLAN classification capabilities: MAC, IP subnet, protocol, DHCP based. Extensive L2-L4 Access Control Lists (ACL) Automatic containment and remediation support provided by full integration with Alcatel-Lucent OmniVista 2770 Quarantine manager. Benefits of our approach The number of models offered meets any customer configuration need. The flexibility provides a lower price by eliminating the functionality they dont need, yet provide them advanced routing protocols.

High performance, affordable, future proof networks for triple-play applications

There is a noticeable performance boost in triple-play networks from advanced services and at a great price allowing customers to buy tomorrows capabilities today.

Enhanced security that is adaptive to user mobility, is proactive and reactive at the edge, core, and throughout the network

Security domain VLAN classification helps to contain viruses and network attacks maintaining network uptime for critical operations. Security domains provide safe network connectivity for infected devices to be re-mediated. Reduces IT support requirements and man-hours by using network intelligence that automates otherwise manual intervention.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 24 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Simplified manageability

Always available, reliable critical network applications

IPv6 support, a requirement of various corporate and governments

The Omni product families use the same Alcatel-Lucent Operating System as the other OmniSwitch products, reducing or eliminating the need to train existing users. The Omni product families models are fully manageable by Alcatel-Lucent Network Manager OmniVista. Managing Alcatels entire suite of solutions and equipment is OmniVista. OmniVista eases the management burden in many ways: First, by centralizing the management activities of device discovery, topology / health maps, traps and health statistics, the LAN manager can quickly ascertain the networks condition at a glance. Next, through streamlining bulk operations, the IT staff has a mechanism to push configurations, QoS, security, VLAN memberships, and image files to the devices in the network or to schedule after hours back up of the configurations and image files. Finally, OmniVista utilizes self-contained applications - like the Automated Quarantine Manager - to deliver value added services like malicious behavior containment, or the OneTouch QoS to deliver end-to-end QoS policy enforcement. From this single application, the IT staff can access secure telnet and https GUI sessions with the Alcatel devices, and discover 3rd party equipment through their MIB identity. OmniVista is the platform, which provides the enterprise with the ease of management necessary to grow securely. The Omni product families provide a superior architecture with no single point of failure in its stacked configuration. They offer: Redundancy - Replaceable and redundant power supplies Virtual chassis - Fault tolerant loop stacking - Automatic election of primary and secondary manager - Single IP address for management - Image roll back to automatically reload previous configurations Resiliency - Network uptime is maximized by the wide support of open advanced routing redundancy protocols and mechanisms for fast reconfiguration of links between switches, servers, and other network devices. The Omni product families family provide: IPv6 support with hardware-based forwarding for wire-speed classification and tunneling. Flexibility choice of deploying IPv4, IPv6, or IPv4/IPv6 without compromising switch performance. Hardware-based classification (access control lists (ACLs) and quality of service (QoS)), forwarding and management for IPv6. A transition from an existing IPv4 network by support of tunneling

By offering the same operating system, existing users are familiar with the product from the first day, reducing the cost of ownership by eliminating the need for training.

By providing true redundancy, an enterprise can provide a reliable network for triple play applications.

Extend the IP support from v4 to v4/v6 without compromising performance.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 25 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Evolution / Migration

Interoperability

Alcatel-Lucent is strongly and fully committed to evolve its full array of comprehensive products and solutions to meet the emerging requirements for the next generation technological advancements. To remain highly competitive in the market place, the Omni family of innovative Products & Solutions Technology will continue to evolve and develop to incorporate the most advanced feature set that meets the new emerging networking requirements. As a matter of fact, to remain highly competitive in the market place, the Omni family of innovative Products & Solutions & Technologies has continued to evolve and develop to incorporate the most advanced feature set that meets the new emerging networking requirements in the enterprise LAN, MAN edge/access and WAN access. We can definitely today, compete very well with Cisco, Nortel and other vendors as applicable in this space. The new resilient, continuous switching, and standards-based architecture design of the Omni family of innovative Products & Solutions is highly interoperable not only within the existing Alcatel-Lucents family of enterprise network switching and routing products, but also within other vendors similar enterprise-networking switching and routing products in the market place.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 26 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Key Business Advantages

The business Philosophy & Mission Statement Alcatel-Lucent pursues business on a global scale and has significant business relationships with all US major landline and wireless telecom carriers and many Enterprise customers. The Alcatel-Lucent Vision, Mission and Values form the cornerstones of our new company. The statements set the tone for the way the new company will operate. Our Vision - Definition of future success To enrich peoples lives by transforming the way the world communicates. Our Mission - Purpose and path to realize the vision To use our unique capabilities to ensure that our customers thrive, our business grows and we enrich the personal communications experience for people around the world. Our Values - A system of shared beliefs that are at the heart of everything we do. Customers First: We exist to serve our customers. Our success will be determined by how well we perform for our customers. Innovation: We are intuitive, curious, inventive, practical and bold, which allows us to create new ideas for our customers, our business and employees. These ideas come from anywhere throughout our global operations. Teamwork: Success requires teamwork. We are collaborative and respect the contributions of each person to the teams success. Respect: We are a global company with many cultures. We respect and embrace people and perspectives from all over the world. Accountability: We do what we say we will do. We own a collective responsibility towards customers, colleagues, communities and shareholders. Our Value proposition: We believe that we must provide our customers with the industrys best value in highly available, secure and easy to manage network solutions. We recognize that the value of a network is greater to the enterprise when measured by its ability to be reliable, secure and easily managed. Providing the strong foundation that is necessary for any business to grow and prosper. To optimize switch management and network security, we have developed the Alcatel-Lucents Operating System - an O/S - common to our switches across the enterprise LAN infrastructure. This common O/S enables operation expense relief to our customers through the homogeneity of features and configurations, while supporting device and network based availability strategies. Our enterprise LAN product families that leverages a 10-year history of embedded security features, enabling synergies with existing 3rd party solutions Security solutions that provide assurance the network will be able to react to and contain attacks - promoting productivity and reliability. Alcatel-Lucent offers a comprehensive, system wide solution set allowing us to provide not only a World-class WLAN solution but also the wired network upon which it runs applications to enhance the WLANs ability to have a positive impact on our customers business. In addition to the WLAN we can provide voice services for wired sets, VoIP set and VoWLAN into a seamless enterprise wide communication system. Alcatel-Lucent can provide best in class wired transport for the wireless network with a greater value than our main competition, integrated WAN solutions and across the board security; all of this from one company. In addition we are leveraging our collaboration software to integrate into the WLAN to take the concept of presence to a whole new level. Alcatel-Lucent can take all aspects of a customers communication and security needs and provide a single, open solution set to our customers. We can also leverage our professional services and provide these solutions turn-key to our customers. Alcatel-Lucent (Paris:ALU.PA - News) (NYSE:ALU - News) provides solutions that enable service providers, enterprises and governments worldwide, to deliver voice, data and video communication services to end-users. As a leader in fixed, mobile and converged broadband networking, IP technologies, applications, and services, Alcatel-Lucent offers the end-to-end solutions that enable compelling communications services for people at home, at work and on the move. With operations in more than 130 countries, Alcatel-Lucent is a local partner with global reach. The company has the most experienced global services team in the industry, and one of the largest research, technology and innovation organizations in the telecommunications industry. Alcatel-Lucent is a leading provider of communication solutions for small, medium, and large enterprise networks worldwide. Alcatel-Lucent offers the industrys best value in IP networking solutions that are highly available, secure and easy to manage. Designed for convergence, these solutions are comprised of high-capacity switching platforms that are used in core, wiring closet, and edge implementations and can include an advanced wireless LAN solution. Built from the ground up for IP communications and convergence, they all feature an unparalleled manageability due to a common operating system AlcatelLucent Operating System, a superior availability for both chassis based and stackable solutions, and a best of breed, built-in security.

Value add with emphasis on the Wireless LAN & Wired LAN solutions

Vendors Proven Track Record

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 27 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Extensive Experience

Innovation & Technology & Engineering

Strong IP Infrastructure Solution Offerings

With 23,000 technology patents and a history of more than 100 years in the communications field, AlcatelLucent has proven experience. Alcatel-Lucent serves more than 500,000 customers, including many of the Fortune 500 and leading companies in most sectors. Alcatel-Lucents century of innovation and engineering has allowed us to provide the enterprise network with solutions that span the entire IP communications house. This house has at its top story the productivity enhancing applications, which run on Alcatel-Lucents award winning IP telephony communication servers. Supporting these products is the IP networking data products - the foundation of the IP communications house. As you well know, any house is only as strong as its foundation. We understand that an enterprise network must be able to rely on its infrastructure to deliver the communications and applications necessary to conduct business and take care of users. The first requirement is availability- we expect the phone and applications that expand the value of voice communications or integrate voice and data communications to be available. Our experience tells us that these networks must also be secure, and easily managed, otherwise valuable capital is diverted from the business goals of the company, lessening the opportunity to react to market changes and opportunities. Alcatel-Lucent also knows that the value to the enterprise can be measured in multiple ways - from the solutions purchased to the solutions enabled via partnerships and adherence to industry standards. As you learn more about us and our business philosophy, you will come to know that our greatest benefit to you and your company is not just the industry leading solutions we provide, but the synergies we create with the other products and solutions already deployed in your network. You see, we believe a strong foundation is not just to support the existing building, but to also support future growth. High Availability Your business users demand much, but assume one thing above all: availability. Using a strong hardwaresoftware mix, Alcatel-Lucent IP infrastructure solutions create a single-entity network that is resistant to configuration errors and doesn't need resetting after changes. Together with highly affordable, redundant network management and continuous switching capabilities, Alcatel-Lucents IP infrastructure solutions ensure fail-safe and cost effective business operations. High Security With Alcatel-Lucent IP infrastructure solutions, your information assets are really protected, from the core to the edge. The same security features are embedded in all Alcatel-Lucent IP infrastructure components: you dont need to go through a programming nightmare when deploying your network security policy or adding a new switch to the system. Security problems can be isolated and contained; specific security tasks can be addressed. In a nutshell, with an Alcatel-Lucent IP infrastructure, gaps in the communication protection system are eliminated, including at the PBX level. Simplified Management Alcatel-Lucent IP infrastructure solutions leverage common components and feature sets, running on a single operating system for centralized management. This simplifies both deployment and day-to-day operations, while minimizing down time. As a result, total network running costs decrease, and you can easily anticipate or react to evolving business needs. Last but not least, your IT people will appreciate the one-touch graphical approach of fully featured yet easy-to-use network management applications, helping them work more easily and quickly. Managing Alcatel-Lucents entire suite of solutions and equipment is OmniVista. OmniVista eases the management burden in many ways: First, by centralizing the management activities of device discovery, topology / health maps, traps and health statistics, the LAN manager can quickly ascertain the networks condition at a glance. Next, through streamlining bulk operations, the IT staff has a mechanism to push configurations, QoS, security, VLAN memberships, and image files to the devices in the network or to schedule after hours back up of the configurations and image files. Finally, OmniVista utilizes self-contained applications - like the Automated Quarantine Manager - to deliver value added services like malicious behavior containment, or the OneTouch QoS to deliver end-toend QoS policy enforcement. From this single application, the IT staff can access secure telnet and https GUI sessions with the AlcatelLucent devices, and discover 3rd party equipment through their MIB identity. OmniVista is the platform, which provides the enterprise with the ease of management necessary to grow securely.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 28 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Product Portfolio

Service & Support, Integration & Installation

Escalation

The Alcatel-Lucent Internetworking product portfolio consists of a full range of Ethernet based switches that address the Enterprises entire networking needs. The family of Alcatel-Lucent Ethernet switches range from entry-level L2+ switches where price is the main concern all the way up to advanced L3 modular or fixed configuration chassis providing state-of-theart and standard-based features that meet the stringent requirements for an highly available, highly secure and highly manageable networking infrastructure. The LAN switches, which support your business communications, come in two sets - entry level, fixed configuration and AOS advanced featured core to wiring closet. The entry level, fixed configuration solutions are provided for those customers who do not need to provide the advance services and security features our AOS switches provide. Typically small businesses, these solutions do provide great price/performance value for 10/100 and 10/100/1000. Our AOS advanced services switches deliver on our promise to deliver the industrys best value. Our core offerings of the OmniSwitch 9000 and 7000 family provide features which are important to the enterprise core - native server load balancing, link aggregation, high density gigabit and 10 gigabit, as well as support for routing protocols and multicast, classic IP addressing as well as IPv6, hot swappable modules and full management and power supply redundancy to promote high availability. Our advanced stackable line runs the same OS, and can be managed just like a chassis - one IP address, with management module redundancy for high availability. Supporting PoE, standard routing protocols and multicast, classic and IPv6 addressing as well as a host of other features, our AOS switch line is the easiest to manage in the industry, with a price to performance relationship unmatched in the industry. Expanding the IP communications foundation, Alcatel-Lucents OmniAccess WLAN family provides the enterprise with the industrys most complete WLAN security, availability, and mobility solutions. Further, the OmniAccess Service Gateways products perform at wire speed even with small packet sizes or network services enabled and include a wide array of WAN integrated capabilities - eliminating the need to purchase extra equipment to support additional WAN services. Alcatel-Lucents enterprise SNMP manager, OmniVista, can manage the entire portfolio. Alcatel-Lucent is fully committed to providing a comprehensive range of services and programs in support of its vast array of products. Alcatel-Lucents ecosystem of more than 1,500 partners helps ensure that solutions will be installed, integrated, fully supported and maintained according to Alcatel-Lucents high standards, following global best practices. Alcatel-Lucents Accreditation Program ensures that its partners are fully trained on the latest technologies and techniques to meet and support customer requirements. Technical Support An Alcatel service agreement brings your company the assurance of 7x24 no-excuses technical support. Youll also receive regular software updates to maintain and maximize your Alcatel products features and functionality and on-site hardware replacement through our global network of highly qualified service delivery partners. Additionally, with 24-hour-a-day access to Alcatels Service and Support web page, youll be able to view and update any case (open or closed) that you have reported to Alcatels technical support, open a new case or access helpful release notes, technical bulletins, and manuals. SUPPORTbasic 7 X 24 Technical Response Center (7x24 phone support) Includes e-service web access, software releases and repair and return of hardware to be completed in 10 business days from receipt for same version only. Excludes NMS & Authentication Services software. SUPPORTplus hardware support Includes 7X24 phone support, software releases for same version only, e-service web access, advance shipment for next business day arrival of replacement hardware. Excludes NMS & Authentication Services software. SUPPORTtotal hardware support Includes 7X24 phone support, software releases for same version only, e-service web access, same day 4-hour hardware replacement (labor & parts) 7 days a week 24 hours a day. Allow 30 days lead time from receipt of sales order. Excludes NMS & Authentication Services software. Upon opening a case, customers will receive a case number and may review, update, or escalate support cases on-line. Escalation process is based on the severity level of the issue per the definitions below. Severity 1: Production network is down resulting in critical impact on businessno workaround Severity 2: Segment or Ring is down or intermittent loss of connectivity across network. Severity 3: Network performances are slow or impairedno loss of connectivity or data. Severity 4: Information or assistance on product feature, functionality, configuration, or installation.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 29 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Customer support / Professional Services

Key Partners

Customer Training

Warranty Service & Support Programs & End Of Life Lifetime Support

Life Span

Customers can access customer support 24 x 7 x 365 via toll free number or Internet. Professional services can be contracted to perform a variety of functions, including customer network operations center management, network audits, security installation, network design, equipment staging, configuration and installation, resident engineering, proof of concept, solutions development and integration. Customers may take advantage of professional services with regard to customizing the network management system for optimal tuning in a multi-vendor environment. Professional Services also offers Customer Network Operations Center Service, which proactively monitors the customer network and responds to alarms and traps. Alcatel-Lucent has created a partnering program that enables it to work with a set of vendors in order to provide solutions that fall outside of its core competencies. Partnerships provide channels and customers a catalog of product solutions that are easy to find, evaluate, buy, install, and operate. Alcatel-Lucent offers instruction on its enterprise data products in a variety of modes instructor-led training (ILT), computer-based training (CBT), web-based training (WBT), and customized seminars/workshops/webinars. ILT is offered at several locations or on-site at customer locations. All instructors are Alcatel-Lucent Certified Switch Instructors (ACSIs). This means they have attended all of the courses, completed all of the certifications and attended the weeklong Train-the-Trainer program that includes a review of Alcatel-Lucent training policies, procedures, and practices to assure consistent delivery of information around the world. Standard Warranty Support All Alcatel-Lucent's products come with a standard one-year warranty on hardware and a three-month warranty on software. Hardware DOA Warranty If hardware fails within the first 30 days after delivery, call Alcatel-Lucent's Internetworking Division Customer Service by 2:00 p.m. (Pacific Standard Time) and they will send a replacement part overnight. One-year Hardware Warranty After the first 30 days, call Alcatel-Lucent's Internetworking Division Customer Service for a Return material Authorization (RMA) and ship the part back to them for factory repair. The repaired unit will be shipped back to you from our facility within 10 business days. Next day, advanced replacement is available for a small expedited fee. All-in-One Maintenance: All maintenance fix releases will be provided free of charge during the first 90 days. Service & Support Programs & End Of Life (EOL) In accordance with Alcatel-Lucents established Product Life Cycle policy, as well as its customer satisfaction policy, Alcatel-Lucent will honor its obligations to customers currently under warranty or with valid purchased service agreements relating to a product line for five (5) years (Software: three (3) years and Hardware: five (5) years) beyond the EOL (End Of Life) of a product line. Lifetime Support All versions of the stackaable product families come with a Limited Lifetime Hardware Warranty, limited to the original owner, and will be provided for up to five (5) years. Faulty parts will be replaced via a five (5) business days AVR (Advance Replacement) RMA. Limited Lifetime Warranty does not apply to SFPs. The Alcatel Product Life Span depends on many conditions in the market place and varies from platform to platform. Historically speaking, some platforms have been out in the market more than seven (7) years and still continue to exist on our product portfolio, while others may have experienced shorter life spans.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 30 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Key Financial Advantages

Value Alcatel-Lucents enterprise networking mission is to provide its customers with the industry's best value in highly available, secure and easy-to-manage network solutions. The industrys best value means having leading features for availability, security and manageability and simultaneously reducing the total cost of network ownership. In short, the best network at the best total cost. Alcatel-Lucent IP infrastructure solutions are not only priced right upfront. They also fit your business exactly, reducing both operating and upgrade costs. All solutions share common components and feature sets for deployment flexibility, easy maintenance and upgrading. Highly scalable and able to run on one operating system to simplify centralized management, they can be reused across your network as it changes and grows, thus yielding an even higher return on investment. Delivering the best value to the enterprise, Alcatel-Lucents Enterprise Product Portfolio delivers the best price/performance/features of any manufacturer in the industry. Faster fault isolation/restoration Enhanced engineering and local & remote configuration tools Alcatel-Lucent offers the best value in port / feature / price ratio of any manufacturer in the industry.

Cost Effectivness CAPEX savings

Lowering engineering and operational costs utilizing a common NMS (such as OmniVista & SAM management) Per port / feature / price ratio Pricing vs. the competition

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 31 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Alcatel-Lucent OmniSwitch 6850 Family The OS6850 family offers layer-3 PoE and non-PoE Gigabit Ethernet models as well as Fast Ethernet models upgradeable to Gigabit. All models in OmniSwitch family are stackable, fixed configuration chassis in a 1U form factor. They can be optionally equipped with pluggable SFP and XFP transceivers (depending on the model) that can support short, long and very long distances. The following chart indicates the differences in the OS6850 models.
Fixed-Chassis Types POE Ports Non-POE Ports 10 Gig. Stacking Ports 2 2 2 2 2 2 2 10 Gig. Uplinks 10/100/1000Mbps ,GigE, or 10/100Mbps Non-PoE Models N/A 20 10/100/1000 2 N/A 2 2 N/A N/A 20 10/100/1000 44 10/100/1000 48 10/100/1000 22 Gig SFP** 20 10/100*** 44 10/100*** Combo Ports* POE Power Budget Power Supplies supported

OS6850-24 /-24D OS6850-24X /-24XD OS6850-48 /-48D OS6850-48X /-48XD OS6850-U24X /-U24XD OS6850-24L /-24LD OS6850-48L /-48LD OS6850-P24 /-P24H OS6850-P24X /-P24XH OS6850-P48 /-P48H OS6850-P48X /-P48XH OS6850-P24L /-P24LH OS6850-P48L /-P48LH

N/A N/A N/A N/A N/A N/A N/A

24 24 48 48 24 24 48

4 4 4 N/A 2 4 4

N/A N/A N/A N/A N/A N/A N/A

126W AC-to-DC or 120W DC-to-DC 126W AC-to-DC or 120W DC-to-DC 126W AC-to-DC or 120W DC-to-DC 126W AC-to-DC or 120W DC-to-DC 126W AC-to-DC or 120W DC-to-DC 126W AC-to-DC or 120W DC-to-DC 126W AC-to-DC or 120W DC-to-DC Dual ext. 360W and/or 510W Dual ext. 360W and/or 510W Dual ext. 360W and/or 510W Dual ext. 360W and/or 510W Dual ext. 360W and/or 510W Dual ext. 360W and/or 510W

24 24 48 48 24 48

N/A N/A N/A N/A N/A N/A

2 2 2 2 2 2

PoE Models**** N/A 20 10/100/1000 2 N/A 2 N/A N/A 20 10/100/1000 44 10/100/1000 48 10/100/1000 20 10/100*** 44 10/100***

4 4 4 N/A 4 4

240W / 390W 240W / 390W 240W / 390W 240W / 390W 240W / 390W 240W / 390W

*Combo ports are ports individually configurable to be 10/100/1000BaseT or 1000BaseX that can support SFP transceivers for short, long and very long distances. Combo Ports on the PoE Models: The Combo 10/100/1000BaseTcopper RJ-45 ports support PoE. The Combo 1000Base-X fiber SFP ports do not support PoE. ** Gig fiber interfaces support Gig SFP, dual-speed SFP or 100BaseX SFP optical transceivers. *** The 10/100 RJ-45 ports can be upgraded to 10/100/1000 speed by purchasing the OS6850-24L-UPGD or OS6850-48L-UPGD software license for 24-port and 48-port models respectively. **** The PoE Power Budget is subject to an extra overhead which has to be taken into account (please refer to the P/S Sec.)

Power Supply Options

The OS6850 family offers customers a vast selection of switches and power options that will accommodate most needs. By providing both 24- and 48-port PoE and non-PoE models with multiple power supply options such as AC and DC options as well as backup power supplies, network administrators can prevent over or under provisioning power to their switches and save money by not having to purchase more than they need. The primary as well as the backup power supplies for the OS6850 models are external and connect to the rear of the unit. A power shelf provided with the unit, can slide into the rear of the chassis and is used to hold either two 360W PoE, 126W AC or 120W DC power supplies or one 510W PoE power supply. For dual 510W configurations, the backup power supply has to be remotely mounted. Any power supply can be remotely connected using a cable in which case, the same power shelf can be mounted in the rack using the mounting ears, provided with the unit. This feature allows OmniSwitch 6850 to be used in areas with reduced-depth (e.g., a wall-mounted cabinet). OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 32 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Gigabit Ethernet at the Edge

The OmniSwitch 6850 series of switches provide a migration path to Gigabit on the LAN edge where high speed and extensive features are needed. The OmniSwitch 6850s have the features necessary to provide intelligent, secure, and available networking for the most demanding applications and user requirements. The OS6850s are ideal for use at the edge because of their compact fixed form factor design suitable for closets. Their modular expandability, flexible configuration provides an easy path to scale any workgroup up to 384 10/100/1000 ports and 16 10GigE ports in a single stack to support campus wiring closet requirements. The OS6850s support of high power as well as standard powered PoE ports, copper non-PoE and fiber ports in any combination in a stack provides exceptional flexibility in customizing the closet/small core deployment to support applications ranging from just data to triple-play converged applications.

Intelligence at the Core

The new breed of smart router and switches are outfitted with intelligent ASICs that support enhanced IP routing, QoS, security services, run-time protocols and service provisioning. That means more deployment options, better network performance through enhanced packet prioritization, acceleration, load balancing, and, ultimately lowers costs. OmniSwitch 6850 perfectly meets these requirements and can be deployed as an intelligent network-core (small-tomedium Networks) router to assume the demanding network processing workload for an optimum network performance.

Performance
The OS6850 family supports real-time voice, data, and video applications. The switches provide first packet wire-speed classification and processing for all packets in the data steam giving a noticeable performance boost to triple-play (voice, data and video) enterprise networks and at a great price allowing customers to buy tomorrows capabilities today. The OS6850s support advanced services such as 10GigE, PoE and IPv6, future proofing todays investment to support the demands of tomorrow.

10-Gigabit Ethernet Applications

The 10-Gigabit Ethernet (compliant with IEEE 802.3ae standard) key drivers include: The 10-Gigabit Ethernet standard enables the 10-Gigabit Eth. LAN and the 10-Gigabit Eth. MAN applications: o Extending LAN Ethernet into MAN o Offering high speed LAN/MAN unification rate: at 10Gbps o The 10-Gigabit Ethernet LAN PHY supports the transmission of data on existing fiber for large Enterprises, private MANs or new Metro Service Providers leveraging Dark fiber. Leverages Fiber infrastructure: from 65m to 40km (with different Interface) Builds on Ethernet standards: simple, cost effective, familiar with large installed base IP-Storage Area Networks (IP-SANs) applications The 10-Gigabit Ethernet has become the dominant backbone technology over optical switches: The applications for video streaming and high-end graphics will continue to develop, and Gigabit Ethernet will become more popular for desktops & workstations. For this reason, IT managers will need to use 10 Gigabit Ethernet technologies to link aggregate multiple Gigabit Ethernet switches. The 10-Gigabit Ethernet will also be a good fit for unique markets such as film production houses, Hospitals, and research facilities, where extremely large files are moved around throughout an organization.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 33 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Carrier-Class for the Enterprise

The OmniSwitch 6850 is a powerful, intelligent multi-layer switch that provides the ultimate in performance and availability. It is the premier platform in Alcatel-Lucents next generation OmniSwitch Product Family. The OmniSwitch 6850 delivers carrier-class features and functionality with high port density and high throughput for IP communications, access & distribution implementations, and mission-critical environments. The OmniSwitch 6850 supports high port density, high switching capacity platforms in a stackable configuration. The OmniSwitch 6850 provides non-blocking 10-Gigabit Ethernet connectivity, carrier-class availability, distributed layered security, and intelligent switching and routing services all at wire-speed. As enterprises look towards high-speed LAN services and MAN connectivity, the OmniSwitch 6850 provides a wealth of features for providing high-speed switching and seamless connectivity between buildings, campuses, and POPs. The OmniSwitch 6850 can play a strong role in many environments: Enterprise workgroups / LAN wiring closets Edge deployments and branch offices L3 aggregation / distribution layer switches in three-tier networks Small to medium enterprise core switching Ethernet access for metro/triple-play applications

Supprim :

Secure Networking
OmniSwitch 6850 can support a distributed security approach, enhance emerging security technologies, and help secure the LAN edge using proactive and reactive strategies. One proactive solution is to perform a host integrity check, which essentially ensures attached devices are running administrator defined credentials such as; operating system patch level, local firewall is activated, and that the anti-virus version is up to date prior to allowing network entry. Host integrity check solution is significantly enhanced by the OS6850 group mobility feature because it can automatically move hosts that pass inspection dynamically into their proper VLAN based on the user, regardless where they are physically or move them into a protected environment where they could maintain limited access to network resources for remediation. Since all security threats cannot be anticipated the enterprise also needs a reactive security solution that can respond quickly and effectively. When group mobility is combined with Alcatel-Lucents Quarantine Engine and supported Intrusion Detection Systems (IDS), the network can automatically detect attacks and take protective action such as writing a rule that drops the devices traffic, turning off the devices connectivity to the network or quarantine it to a protected environment. OmniSwitch 6850 series switches support additional security feature set to secure the LAN edge. Access control lists (ACLs) can filter out undesirable communication between hosts and can be a first line of defense against network attacks. In an Alcatel-Lucent OmniSwitch network, the authenticated VLAN feature provides the ability to authenticate by user with username and password and then dynamically place the user into the proper VLAN regardless of where they request access from. Other supported policy-based VLANs can do the same dynamic classification based on layer-2 and layer-3 packet information. IEEE 802.1x, a standards-based approach to network access, is an effective way of challenging a user by requesting a username and password before allowing access the network. Learned port security is a security feature that allows only pre-authorized network devices to communicate with each other. This provides protection against rogue devices such as WLAN access points, as well as unsecured and potentially virus infected laptops or PCs. Administration of the switch is secured by encrypting remote management with secure shell (SSH) for Telnet, Secure Socket Layer (SSL) for web-based management and SNMPv3 for network wide management systems such as Alcatel-Lucents OmniVista enterprise network management platform. Additionally all administrators are centrally authenticated through a RADIUS, LDAP or ACE server. A local database is also provided on every switch for administrator authentication.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 34 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Alcatel-Lucent Access Guardian and OmniVista 2770 Quarantine Manager

Alcatel-Lucents Access Guardian and OmniVista 2770 Quarantine Manager are secure network components of AlcatelLucents security framework for all of Alcatel-Lucents enterprise networking devices. This framework offers proactive and reactive security solutions comprised of comprehensive switch-based security capabilities as well as integration with security applications and appliances from industry leaders. Alcatel-Lucents Access Guardian is a feature set that enables network-wide and user-based security by automatically detecting and authenticating the 802.1x and non-802.1x devices associated with a single port, in any combination. This provides users proactive security by preventing unauthorized network access or restricted access for remediation. In addition to improved network security, Alcatel-Lucents Access Guardian reduces to zero the time a network administrator spends for adding or moving users. In addition to proactive security provided by Alcatel-Lucents Access Guardian, the Alcatel-Lucent OmniVista 2770 Quarantine Manager provides reactive security by using alerts from third-party intrusion detection and prevention systems to identify malicious attacks and then swiftly handling them through automatic containment and remediation. Alcatel-Lucent CrystalSec is the security framework and architecture for Alcatel-Lucents enterprise networking devices. CrystalSec provides security that is extended to and deployed through a mixture of technologies, external appliances and security functions from the network core to the edge. CrystalSec offers the best-in-class VLAN classification capabilities (MAC, IP subnet, protocol, DHCP, ACLs) and provides plug-and-play security domains ensuring automatic containment and remediation support. CrystalSec framework consists of network device hardening for security by default, Access Guardian for proactive security, Alcatel-Lucent OmniVista 2770 Quarantine manager for reactive security, secure network services to ensure high availability, security certifications of third parties, and partnerships with leading security application providers such as Fortinet.

High Availability
The OmniSwitch 6850 stackable minimizes downtime, reduces operational complexity & cost and increases availability for mission-critical applications. The OmniSwitch 6850 supports the a wide range of availability features such as redundant management, redundant switching fabric/fault tolerant backplane, redundant power supplies, and link aggregation including 10Gigabit Ethernet that can be configured across physical switch boundaries. These attributes remove single points of failure. A very cost effective, highly available, scalable and re-configurable network can be achieved when the stackable-based chassis benefits of the OS6850 are deployed in conjunction with the OS9000 family. Additionally, standards-based features like per-VLAN spanning-tree 802.1s and rapid recovery spanning-tree 802.1w are used to provide added resiliency, fast fail-over to redundant links and layer-2 load sharing on otherwise unused network links (bandwidth capacity). Dynamic link aggregation 802.3ad provides inherent fail-over to remaining existing links in the aggregate should one or more links fail and automatically builds multi-gigabit capacity with other switches. By supporting the OS6850 backup power solution, customers have backup power for the OmniSwitch 6850s in case of any power supply failure. The OS6850s resiliency is provided through a superior architecture with no single point of failure in its stacked configuration. Resiliency is supported through physical and functional redundancy everywhere: Virtual chassis that provide management functionality and automatic election of primary and secondary managers Redundant subsystems in stacked configurations Redundant backup power supplies Fault tolerant loop stacking Virtual chassis that provides management functionality and automatic election of primary and secondary managers Hot swappable units and power supplies Image rollback to automatically re-load previous configurations and software versions Hitless loading of optional advanced routing software without re-booting

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 35 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Advanced QoS
Quality of service (QoS) addresses the need for mission critical applications to be always available by ensuring they receive expedited forwarding, reducing the chances of critical data flows getting interrupted or experiencing excessive delay. The OS6850 provides the necessary hardware queues, intelligence and granularity to properly identify (identification is based on layer-1 through layer-4 policy-based features), mark and prioritize data flows ensuring mission critical applications run smoothly.

IPv6 Support
Although there may not be an immediate need for IPv6 in an enterprise network, it should be included in upgrade plans to future proof the network and provide investment protection. Many leading industry analysts, such as Gartner Group and Burton, have indicated that it is not a matter of if, but when IPv6 will be a requirement for enterprise networks. By including it in current purchases, a network manager extends the life of existing equipment and prevents future expenses that would be required to upgrade to a switch that supports IPv6. The OS6850 family provides full IPv6 support with hardware-based forwarding for wire-rate speeds, classification and tunneling to address various corporate and U.S. federal government Department of Defense (DOD) requirements for IPv6. Flexibility is provided through a choice of deploying IPv4, IPv6, or IPv4/IPv6 without compromising switch performance. The OS6850s offer both native IPv6 routing and extensive support of IPv6 tunneling mechanisms, including configured, 6-in-4, and ISATAP tunneling.

Compliancy
1) RoHS-Alcatel's OmniSwitch 6850 family is among the first hardware to be in compliance with the new European Community's directive Restriction on Hazardous Substances in Electrical and Electronic Equipment (RoHS) 2) WEEE (Waste Electrical and Electronic Equipment) 3) NEBS Level 3 Certified All non-PoE models

WebView
Your IT person has long ago abandoned web management because it was too slow, inefficient and incapable. WebView updates happen instantly removing the biggest obstacle to simple fast management. Alcatel-Lucent WebView gives true real-world capabilities back to web browser element management and allows an IT staff of varying capabilities to quickly master and configure new features. The web interface provides point and click ease with quick access to help. WebView is full-featured and can configure and manage all switch features.

CLI
The AOS-based OS6850 uses an intuitive CLI that is common across the OmniSwitch line. A common and easy to use interface from the edge to the core can reduce total cost of ownership by reducing training costs, simplifying and speeding up deployment, and making troubleshooting efforts more routine.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 36 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Simplified Manageability
The group mobility feature inherent in the OS6850 also provides plug and play mobility for both wired and wireless users by removing physical limitations. The OS6850 can use device information, data traffic or user identity to automatically and dynamically keep the user connected to their resources seamlessly regardless of their location on the campus. Marketing, finance, operations and sales could all be in the same meeting at a common physical location, yet have secure and dynamic access to their respective network resources. Along with user benefits and greater user satisfaction, group mobility provides a kiosk hands-off operation to IT, reducing operational costs. Once initial rules for classification are defined further configuration or intervention is not necessary. The OS6850s design provides all the benefits of managing a truly chassis-based switch including: simple and quick software upgrades and switch configuration changes, single IP address for management, and a common look and feel with the rest of the OmniSwitch solutions. The AOS-based OS6850 uses an intuitive CLI that is common across the OmniSwitch line. A common and easy to use interface from the edge to the core can reduce total cost of ownership by reducing training costs, simplifying and speeding up deployment, and making troubleshooting efforts more routine. When the Alcatel-Lucent enterprise network management solution is used as the primary management tool, a very small IT staff can effectively and efficiently manage a large network of Alcatel-Lucent enterprise wired and wireless solutions, further reducing the man hours and support staff requirements. Because switches at the edge of the network are typically deployed in large numbers, it is essential that they are easy to install, configure, manage, and troubleshoot. The OmniSwitch 6850 uses an industry standard command line interface (CLI) to simplify configuration and reduce the total cost of ownership through reduced training costs. The OS6850 also includes a web based element manager with built-in help that provides point and click configuration for newer features reducing risk of misconfiguration and speeding up the introduction of new features. Every network connection begins at the physical layer where many network connectivity problems occur. Each 10/100/1000 switch port has the built-in capability, known as auto MDI/MDI-X, to determine if the cable attached is straight-thru or crossover and what network device (PC, switch, router) is on the other side of the cable to automatically create a link-up condition. Ports provide installation flexibility by supporting either copper or fiber link connectivity while reducing sparing costs by eliminating the need for separate Gigabit uplink modules.

OneTouch Network Management

The OmniSwitch 6850s are part of Alcatel-Lucents Omni family - which includes core, stackable / modular, and edge switches, that use the Alcatel-Lucent Operating System (AOS) and wireless LAN (WLAN) switches - and the Alcatel-Lucent OmniVista 2500 and 2700 Network Management System for simplified OneTouch manageability. By offering the same operating system and network management system (NMS) across all Alcatel-Lucent platforms, an existing user is familiar with the products management from the very first day, reducing the cost of ownership by eliminating the time needed for training on a different operating system or management solution. OmniSwitch users have the flexibility to select a preferred method of management from three types of easy to use interfaces that include a command line interface (CLI), Alcatel-Lucent WebView for web-based management or Alcatel-Lucent OmniVista 2500 and 2700 network management applications that offer one touch point-and-click technology. Regardless of the interface selected, it will have a common look and feel for every device, eliminating time that might have been spent on learning a new devices unique management method or commands. When the Alcatel-Lucent enterprise network management solution OmniVista is used as the primary management tool, a very small IT staff can effectively and efficiently manage a large network of Alcatel-Lucent enterprise wired and wireless solutions, further reducing the man hours and support staff requirements. OmniVista Benefits include: PolicyView with OneTouch QoS centralizes and simplifies QoS configuration network wide. Resource Manager automates and centralizes management of switch software network wide o Bulk Operations o Backup and restore SecureView simplifies and centralizes control of switch administration policies. Provides a high degree of granularity in access privileges. Quarantine Manager: with Alcatel-Lucents Quarantine Engine and supported Intrusion Detection Systems (IDS), the network can automatically detect attacks and take protective action such as writing a rule that drops the devices traffic, turning off the devices connectivity to the network or quarantine it to a protected environment. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 37 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850 Series / Technical

Network Positioning and Applications
The new OmniSwitch 6850 product family provides the network administrators with the necessary state-of-the-art hardware and state-of-the-art software features to build and operate a highly available, highly secure, highly intelligent, and highly manageable Campus Data Network. The OmniSwitch 6850s meets the stringent requirements for high-performance, high-density GigE & 10GigE, and todays fast network response time. The OmniSwitch 6850 platforms future proofs the network with their native and full support of IPv4/IPv6, addressing the requirements for migration (from IPv4 to IPv6) and Greenfield IPv6 deployments. o The new OmniSwitch 6850 product family provides future proofing and investment protection by providing full support of IPv6 on every module. The OmniSwitch 6850 series of switches provide a migration path to Gigabit on the LAN edge where high-speed and extensive features are needed. The OmniSwitch 6850 has the features necessary to provide intelligent, secure, and available networking for the most demanding applications and user satisfaction requirements. The highly scaleable design of the OmniSwitch 6850 makes it suitable for tiered network designs. The OmniSwitch 6850 platforms are mainly designed for use in the enterprise aggregation layer, and/or deployment at the enterprise edge where customers demand a solution to ensure high availability and high throughput at the edge. o The new OmniSwitch 6850 product family addresses the converged, high-end, edge market and their requirements. AOS (Alcatel-Lucent Operating System) users benefit from key user-oriented features such as user authentication / quarantine capabilities, flexible VLAN configuration, and power over Ethernet (PoE). The highly scaleable design of the stackable OmniSwitch 6850 series is highly interoperable with that of the OmniSwitch 9000 series as illustrated in the following figure.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 38 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Gigabit to the Desktop Applications

The OmniSwitch 6850 series of switches provide a migration path to Gigabit on the LAN edge where high speed and extensive features are needed. The OmniSwitch 6850s have the features necessary to provide intelligent, secure, and available networking for the most demanding applications and user requirements. The OS6850s are ideal for use at the edge because they can be powered with AC, DC or with power over Ethernet providing flexibility in their placement. Their compact fixed, form factor design makes them ideal for closets and their modular expandability, flexible configuration provides an easy path to scale any work group up to 384 10/100/1000 ports and 16 10GigE ports in a single stack to easily support campus wiring closet requirements. The OS6850s support of high power as well as standard power PoE ports, copper non-PoE and fiber ports in any combination in a stack provides a great deal of flexibility in customizing the closet deployment to support applications ranging from just data to triple-play, converged applications. The Gigabit to the desktop migration provides the following further benefits: Advanced Services and Performance o Supports mobile user wired or wireless o Differentiated services for mission critical o High-performance workgroup Future proofing and Gig migration o Triple speed for legacy o 10GigE for growth o Fiber or copper Gig uplinks

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 39 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Server Aggregation
The OmniSwitch 6850s small form factor, high performance and rich features set make it a great server aggregation switch, especially for space-constrained data centers where the switch can be installed in the same rack as the servers. Small Form Factor & High Performance fits well as rack mounted server aggregation (space constrained) o 10GigE connectivity-Server & redundant to Core o High-speed resilient stack ring o Multi-Channel Gig o Wire speed with full services implemented

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 40 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

L3 Aggregation/Distribution
The OmniSwitch 6850 placed in the distribution layer of three-tier networks provides high capacity wire speed L2 switching, L3 routing and intelligent services near the edge of the network. In addition, some models of the OmniSwitch 6850 family have four combo ports that are individually configurable to provide users the choice of copper or fiber. High Speed Distributed Processing Brings advanced services closer to edge

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 41 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Enterprise Small Core Capacity

Even though the OmniSwitch 6850 only stands 1.75 inches tall (1RU), its high switching capacity rivals some of todays conventional modular core chassis solutions. Combined with full L3 routing protocols, advanced network services and wire speed 10-Gigabit capability, the OS6850 makes a very capable and cost-effective enterprise small core capacity switch. Virtual chassis edge connected to virtual chassis core offers exceptional redundancy and load balancing capabilities Complete core capabilities in the OS6850 High-port density Wire rate at first packet 10GigE performance providing high throughput for backbone connections Full support of IPv4/IPv6 Wire-rate multicast for media and backup applications 16 10GigE ports per full stacked chassis Extensive QoS classification marking queuing and queue service capabilities

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 42 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Residential / Metro Triple-play Ethernet Access

The OmniSwitch 6850s are well suited for residential or metro Ethernet triple-play access networks, which demand userdifferentiated, high-speed Internet, voice and video services support. In addition to OmniSwitch 6850 resiliency and high performance, the Alcatel Operating System (AOS) offers a number of features to provide secure access and traffic control for residential deployments. All products illustrated here are from Alcatel-Lucent: OS6200: Alcatel-Lucent OmniStack LS 6200 OS6850: Alcatel-Lucent OmniSwitch 6850 OS7450: Alcatel-Lucent 7450 Ethernet Service Switch OS7750SR: Alcatel-Lucent 7750 Service Router

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 43 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Triple-Play Switching
The OmniSwitch 6850s are well suited for supporting, in real time, the triple-play applications of data, voice and video because of their resiliency and high performance. Other features that support triple play include: Wire-speed performance including the first packet giving a noticeable performance boost to triple play networks. Eight hardware-based quality of service (QoS) queues ensuring wire-speed packet classification and processing for all packets in a data steam

Combo Port Application Example

The figure below shows a sample application example for using OmniSwitch 6850 Series combo ports. Workstations A and B are connected with 100 Mbps links to copper combo ports 1/45 and 1/46, respectively. (MiniGBIC SFP combo ports 1/45 and 1/46 are unused.) Server A has a primary 1 Gbps fiber connection to combo MiniGBIC SFP port 1/47 and a backup 100 Mbps connection to copper combo port 1/47. And the OmniSwitch 7700 has a primary 1 Gbps connection to combo MiniGBIC SFP port 1/48 and a backup 100 Mbps connection to copper combo port 1/48.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 44 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Hardware Overview OmniSwitch 6850 Series

OmniSwitch 6850 Series switches are available in thirteen stackable chassis configurations as shown in the table below: OmniSwitch 6850-24L (OS6850-24L): 24-port 10/100 OmniSwitch 6850-48L (OS6850-48L): 48-port 10/100 OmniSwitch 6850-P24L (OS6850-P24L): 24-port 10/100 Power over Ethernet (PoE) OmniSwitch 6850-P48L (OS6850-P48L): 48-port 10/100 Power over Ethernet (PoE) OmniSwitch 6850-U24X (OS6850-U24X): 24-port Gigabit SFP with 10 Gigabit uplinks OmniSwitch 6850-24 (OS6850-24): 24-port 10/100/1000 OmniSwitch 6850-48 (OS6850-48): 48-port 10/100/1000 OmniSwitch 6850-24X (OS6850-24X): 24-port with 10 Gigabit uplinks OmniSwitch 6850-48X (OS6850-48X): 48-port with 10 Gigabit uplinks OmniSwitch 6850-P24 (OS6850-P24): 24-port 10/100/1000 Power over Ethernet (PoE) OmniSwitch 6850-P48 (OS6850-P48): 48-port 10/100/1000 Power over Ethernet (PoE) OmniSwitch 6850-P24X (OS6850-P24X): 24-port PoE with 10 Gigabit uplinks OmniSwitch 6850-P48X (OS6850-P48X): 48-port PoE with 10 Gigabit uplinks

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 45 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850 Series

This section contains the information required to order the OmniSwitch 6850 Gigabit Ethernet chassis, stacking cables, backup power supplies and optional advanced routing software. All of the OmniSwitch chassis bundles include power shelf, DB25M-DB25F cable for remote mounting of the power supply, user manuals access card, rack mounts, and RJ-45 to DB-9 adapter. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. The product family model names have the format: OS6850-xxxx. Suffix letters in the model name indicate different functionality: * Power supply: - "P" means bundle comes with Standard PoE power supply (360w), - "P and H" means bundle comes with High-PoE power supply (510w) - "D" means bundle comes with DC power supply, - No P, H or D means bundle comes with standard AC power supply package * 10 Gigabit ports module: - "X" means bundle comes with two 10 Gigabit ports built-in module supporting XFP optical transceiver, - No X means bundle does not include the two 10 Gigabit ports built-in module. * L model - 10/100 upgradeable to Gigabit: - "L" means OS6850 chassis comes with 10/100 RJ45 ports that can operate also at Gigabit speed by purchasing a specific upgrade software license. All members of the OS6850 series employ a reduced depth main chassis. Power supply could be directly plugged in the rear of the chassis or remotely mounted in the rack. Chassis Bundles ship with two rack mounts for the power shelf, and one chassis connection cable for remote mounting of the power supply. OS6850 supports power supply redundancy. Only the OS6850-U24X SFP ports support 100BASE-FX single speed optical transceivers. All versions of the OS6850 family come with hardware Limited Lifetime Warranty. Limited Lifetime Warranty is limited to the original owner, and will be provided for up to five (5) years after product End of Sales (EoS) announcement. Faulty parts will be replaced via a five (5) business days AVR (Advance Replacement) RMA. Limited Lifetime Warranty does not apply to transceivers. Model Number Description OmniSwitch 6850 PoE Chassis Bundles OS6850-P24 PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992]. L3 Gigabit Ethernet chassis in a 1U form factor OS6850-P24 with 20 RJ-45 PoE ports individually configurable to 10/100/1000BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports, either copper or fiber can be used on a one for one basis. The bundle includes a 360W AC PoE power supply with Power shelf, country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P24H PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor OS6850-P24H with 20 RJ-45 PoE ports individually configurable to 10/100/1000BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports, either copper or fiber can be used on a one for one basis. The bundle includes a 510W AC PoE power supply with Power shelf, country specific power cord, and user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P24X PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor OS6850-P24X with 20 RJ-45 PoE ports individually configurable to 10/100/1000BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, two 10 Gigabit ports, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 360W AC PoE power supply with Power shelf, and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P24XH PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor OS6850-P24XH with 20 RJ-45 PoE ports individually configurable to 10/100/1000BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, two 10 Gigabit ports, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 510W AC PoE power supply with Power shelf and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P48 PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor OS6850-P48 with 44 RJ-45 PoE ports individually configurable to 10/100/1000BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 360W AC PoE power supply with Power shelf and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P48H PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor OS6850-P48H with 44 RJ-45 PoE ports individually configurable to 10/100/1000BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 510W AC PoE power supply with Power shelf and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P48X PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor OS6850-P48X with 48 RJ-45 PoE ports individually configurable to 10/100/1000BaseT, two 10 Gigabit ports, and two dedicated stacking ports. The bundle includes a 360W AC PoE power supply with Power shelf and country specific power cord, user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. The 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 46 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850-P48XH

OS6850-24

OS6850-24D

OS6850-24X

OS6850-24XD

OS6850-48

OS6850-48D

OS6850-48X

OS6850-48XD

OS6850-U24X

OS6850-U24XD

OS6850-P48XH PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 48 RJ-45 PoE ports individually configurable to 10/100/1000BaseT, two 10 Gigabit ports, and two dedicated stacking ports. The bundle includes a 510W AC PoE power supply with Power shelf and country specific power cord, user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. The 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OmniSwitch 6850 non-PoE Chassis Bundles OS6850-24 chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 20 RJ-45 ports individually configurable to 10/100/1000BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 126W AC power supply with Power shelf and country specific power cord; user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies are can be ordered separately. OS6850-24D chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 20 RJ-45 ports individually configurable to 10/100/1000BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 120W DC power supply with Power shelf; user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-24X chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 20 RJ-45 ports individually configurable to 10/100/1000BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, two 10 Gigabit ports, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 126W AC power supply with Power shelf and country specific power cord; user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-24XD chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 20 RJ-45 ports individually configurable to 10/100/1000BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, two 10 Gigabit ports, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 120W DC power supply with Power shelf, user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-48 chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 44 RJ-45 ports individually configurable to 10/100/1000BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 126W AC power supply with Power shelf and country specific power cord, user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-48D chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 44 RJ-45 ports individually configurable to 10/100/1000BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 120W DC power supply with Power shelf, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-48X chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 48 RJ-45 ports individually configurable to 10/100/1000BaseT, two 10 Gigabit ports, and two dedicated stacking ports. The bundle includes a 126W AC power supply with Power shelf and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-48XD chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 48 RJ-45 ports individually configurable to 10/100/1000BaseT, two 10 Gigabit ports, and two dedicated stacking ports. The bundle includes a 120W DC power supply with Power shelf, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-U24X chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 22 1000 Base-X SFP ports, 2 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, two 10 Gigabit ports, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 126W AC power supply with Power shelf and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-U24XD chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 22 1000 Base-X ports, 2 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, two 10 Gigabit ports, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 120W DC power supply with Power shelf, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 47 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850-P24L

OS6850-P24LH

OS6850-P48L

OS6850-P48LH

OS6850-24L

OS6850-24LD

OS6850-48L

OS6850-48LD

OmniSwitch 6850L PoE Chassis Bundles OS6850-P24L PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992]. L3 Ethernet chassis in a 1U form factor with 20 RJ-45 PoE ports individually configurable to 10/100BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. The 20 10/100 PoE RJ-45 ports can also operate at Gigabit speed by purchasing the OS6850-24L-UPGD software license. On the combo ports, either copper or fiber can be used on a one for one basis. The bundle includes a 360W AC PoE power supply with Power shelf, country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P24LH PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Ethernet chassis in a 1U form factor with 20 RJ-45 PoE ports individually configurable to 10/100BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. The 20 10/100 PoE RJ-45 ports can also operate at Gigabit speed by purchasing the OS6850-24L-UPGD software license. On the combo ports, either copper or fiber can be used on a one for one basis. The bundle includes a 510W AC PoE power supply with Power shelf, country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P48L PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Ethernet chassis in a 1U form factor with 44 RJ-45 PoE ports individually configurable to 10/100BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. The 44 10/100 PoE RJ-45 ports can also operate at Gigabit speed by purchasing the OS6850-48L-UPGD software license. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 360W AC PoE power supply with Power shelf and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P48LH PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Ethernet chassis in a 1U form factor with 44 RJ-45 PoE ports individually configurable to 10/100BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. The 44 10/100 PoE RJ-45 ports can also operate at Gigabit speed by purchasing the OS6850-48L-UPGD software license. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 510W AC PoE power supply with Power shelf and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OmniSwitch 6850L non-PoE Chassis Bundles OS6850-24L chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Ethernet chassis in a 1U form factor with 20 RJ-45 ports individually configurable to 10/100BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. The 20 10/100 RJ-45 ports can also operate at Gigabit speed by purchasing the OS685024L-UPGD software license. On the combo ports, either copper or fiber can be used on a one for one basis. The bundle includes a 126W AC power supply with Power shelf and country specific power cord, user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-24LD chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Ethernet chassis in a 1U form factor with 20 RJ-45 ports individually configurable to 10/100BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. The 20 10/100 RJ-45 ports can also operate at Gigabit speed by purchasing the OS685024L-UPGD software license. On the combo ports, either copper or fiber can be used on a one for one basis. The bundle includes a 120W DC power supply with Power shelf, user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-48L chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Ethernet chassis in a 1U form factor with 44 RJ-45 ports individually configurable to 10/100BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. The 44 10/100 RJ-45 ports can also operate at Gigabit speed by purchasing the OS6850-48L-UPGD software license. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 126W AC power supply with Power shelf and country specific power cord; user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-48LD chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Ethernet chassis in a 1U form factor with 44 RJ-45 ports individually configurable to 10/100BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. The 44 10/100 RJ-45 ports can also operate at Gigabit speed by purchasing the OS685048L-UPGD software license. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 120W DC power supply with Power shelf, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 48 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850-BP OS6850-BP-D OS6850-BP-P OS6850-BP-PH

OS6850-SW-AR

OS-SW-SBR-N

OS-SW-SBR-S

OS6850-24L-UPGD OS6850-48L-UPGD

XFP-10G-ER40 XFP-10G-LR

XFP-10G-SR

XFP-10G-ZR80

SFP-GIG-47CWD60 SFP-GIG-49CWD60 SFP-GIG-51CWD60 SFP-GIG-53CWD60 SFP-GIG-55CWD60 SFP-GIG-57CWD60 SFP-GIG-59CWD60 SFP-GIG-61CWD60 SFP-GIG-BX-D SFP-GIG-BX-U SFP-GIG-EXTND

Backup Power Supplies OS6850-BP modular 126W AC backup power supply. Provides backup power to one non- PoE switch. Ships with chassis connection cable, country specific power cord, power shelf and connecting ears. OS6850-BP-D modular 120W DC backup power supply. Provides backup power to one non-PoE switch. Ships with chassis connection cable, power shelf and connecting ears. OS6850-BP-P modular 360W AC backup power supply. Provides backup power to one PoE switch. Ships with chassis connection cable, country specific power cord, power shelf and connecting ears. OS6850-BP-PH modular 510W AC backup power supply. Provides backup power to one PoE switch. Ships with chassis connection cable, country specific power cord, power shelf and connecting ears. Optional Advanced Routing Software OS6850 Advanced Routing software. Includes support for OSPFv2, BGPv4, PIM-SM/DM and DVMRP. Includes support for IPv6 Routing protocol OSPFv3. Optional Authenticated Services Software [ECCN 5D992] Authentication bundle for Windows w/MD5, RC4, MD4, DES. This bundle provides Funk Software's SteelBelted Radius Enterprise Edition for Microsoft Windows and includes a one-year maintenance contract (maintenance releases, 7X24 phone support and e-service web access). [ECCN 5D992] Authentication Bundle for Solaris w/MD5, RC4, MD4, DES. This bundle provides Funk Software's SteelBelted Radius Enterprise Edition for Sun Solaris and includes a one-year maintenance contract (maintenance releases, 7X24 phone support and e-service web access). Upgrade Software Software license that allows 10/100 RJ45 ports of OS6850-24L and OS6850-P24L chassis to operate also at Gigabit speed. Software license that allows 10/100 RJ45 ports of OS6850-48L and OS6850-P48L chassis to operate also at Gigabit speed. Transceivers 10-Gigabit Ethernet Transceivers (XFP MSA) 10 Gigabit Ethernet optical transceiver (XFP MSA). Supports single mode fiber over 1550nm wavelength (nominal) with an LC connector. Typical reach of 40 Km on 9/125 m SMF. 10 Gigabit Ethernet optical transceiver (XFP MSA). Supports single mode fiber over 1310nm wavelength (nominal) with an LC connector. Typical reach of 10 Km on 9/125 m SMF. [Formerly known as 10G-XFP-LR] 10 Gigabit Ethernet optical transceiver (XFP MSA). Supports multimode fiber over 850nm wavelength (nominal) with an LC connector. Typical reach of 300m on 50/125 m MMF. [Formerly known as 10G-XFP-SR] 10 Gigabit Ethernet optical transceiver (XFP MSA). Supports single mode fiber over 1550nm wavelength (nominal) with an LC connector. Typical reach of 80 Km on 9/125 m SMF. Gigabit Ethernet Transceivers (SFP MSA) CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ gray latch. Supports single mode fiber over 1470 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ violet latch. Supports single mode fiber over 1490 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ blue latch. Supports single mode fiber over 1510 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ green latch. Supports single mode fiber over 1530 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ yellow latch. Supports single mode fiber over 1550 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ orange latch. Supports single mode fiber over 1570 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ red latch. Supports single mode fiber over 1590 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ red latch. Supports single mode fiber over 1590 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. 1000Base-BX SFP transceiver with an LC type of interface. This bi-directional transceiver is designed for use over single mode fiber optic on a single strand link up to 10 km. Transmits 1490 nm and receives 1310 nm optical signal. 1000Base-BX SFP transceiver with an LC type of interface. This bi-directional transceiver is designed for use over single mode fiber optic on a single strand link up to 10 km. Transmits 1310 nm and receives 1490 nm optical signal. Extended 1000Base-SX Gigabit Ethernet optical transceiver (SFP MSA). Supports multimode fiber over 850nm wavelength (nominal) with an LC connector. Reach of up to 2 km (based on grade and condition of fiber) on 62.5/125 m MMF or 550m on 62.5/125 m MMF. Requires SFP-GIG-EXTND or GBIC-GIG-EXTND at the remote termination. [Formerly known as GE-EXTND-SFP]

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 49 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

SFP-GIG-LH40 SFP-GIG-LH70

SFP-GIG-LX

SFP-GIG-SX

SFP-GIG-T

SFP-DUAL-MM

SFP-DUAL-SM10

SFP-100-BX20LT

SFP-100-BX20NU

SFP-100-LC-MM SFP-100-LC-SM15 SFP-100-LC-SM40

OS6850-CBL-150 OS6850-CBL-30 OS6850-CBL-60 OS6850-MNT

1000Base-LH Gigabit Ethernet optical transceiver (SFP MSA). Supports single mode fiber over 1310 nm wavelength (nominal) with an LC connector. Typical reach of 40Km on 9/125 m SMF. 1000Base-LH Gigabit Ethernet optical transceiver (SFP MSA). Supports single mode fiber over 1550nm wavelength (nominal) with an LC connector. Typical reach of 70 Km on 9/125 m SMF. [Formerly known as MINIGBIC-LH-70] 1000Base-LX Gigabit Ethernet optical transceiver (SFP MSA). Supports single mode fiber over 1310nm wavelength (nominal) with an LC connector. Typical reach of 10 Km on 9/125 m SMF. [Formerly known as MINIGBIC-LX] 1000Base-SX Gigabit Ethernet optical transceiver (SFP MSA). Supports multimode fiber over 850nm wavelength (nominal) with an LC connector. Typical reach of 300m on 62.5/125 m MMF or 550m on 50/125 m MMF. [Formerly known as MINIGBIC-SX] 1000Base-T Gigabit Ethernet Transceiver (SFP MSA) - Supports category 5, 5E, and 6 copper cabling up to 100m. SFP only works in 1000 Mbps speed and full-duplex mode Dual Speed Ethernet Transceivers (SFP MSA) Dual Speed 100Base-FX or 1000Base-X Ethernet optical transceiver (SFP MSA). Supports multimode fiber over 1310nm wavelength (nominal) with an LC connector. Typical reach of 550m at Gigabit speed and 2km at 100Mbit speed. Note: - At 100Mbit speed, this SFP can interoperate with SFP-100-LC-MM or similar transceiver on the other end, - At Gigabit speed, this SFP cannot interoperate with SFP-GIG-SX or similar transceiver on the other end running over 850nm wavelength. - SFP supported on OS9-GNI-U24 Gigabit Ethernet Module and OS6850-U24X SFP ports (non combo) Dual Speed 100Base-FX or 1000Base-X Ethernet optical transceiver (SFP MSA). Supports single mode fiber over 1310nm wavelength (nominal) with an LC connector. Typical reach of 10km at Gigabit speed and 100Mbit speed. Note: - At 100Mbit speed, this SFP can interoperate with SFP-100-LC-SM15 or similar transceiver, - At Gigabit speed, this SFP can interoperate with SFP-GIG-LX or similar transceiver. - SFP supported on OS9-GNI-U24 Gigabit Ethernet Module and OS6850-U24X SFP ports (non combo) 100BASE-FX Ethernet Transceivers 100Base-BX SFP transceiver with an SC type interface. This bi-directional transceiver is designed for use over single mode fiber optic on a single strand link up to 20KM point-to-point. This transceiver is normally used in the central office (OLT) transmits 1550nm and receives 1310nm optical signal 100Base-BX SFP transceiver with an SC type interface. This bi-directional transceiver is designed for use over single mode fiber optic on a single strand link up to 20KM point-to-point. This transceiver is normally used in the client (ONU) transmits 1310nm and receives 1550nm optical signal 100Base-FX SFP transceiver with an LC type interface. This transceiver is designed for use over multimode fiber optic cable. 100Base-FX SFP transceiver with an LC type interface. This transceiver is designed for use over single mode fiber optic cable up to 15KM. 100Base-FX SFP transceiver with an LC type interface. This transceiver is designed for use over single mode fiber optic cable up to 40KM. Accessories OS6850 150 centimeters long stacking cable. OS6850 30 centimeters long stacking cable. OS6850 60 centimeters long stacking cable. Base/wall mounting kit for OS6850 models. Includes 4 brackets and screws.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 50 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-24
The OmniSwitch 6850-24 is a stackable edge/workgroup switch offering 20 unshared 10/100/1000Base-T ports, as well as four combo ports individually configurable to be 10/100/1000Base-T or 1000Base-X high speed connections. The front panel of the OS6850-24 chassis contains the following major components: System status and slot indicator LEDs (20) unshared 10/100/1000Base-T ports (4) shared combo 10/100/1000Base-T ports (4) Combo SFP slots for 1000Base-X connections Console port (RJ-45) USB port (USB 2.0) (Future Release)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 51 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-24 Specifications

Total unshared 10/100/1000BASE-T ports per switch (ports 1-20) Total shared 10/100/1000BASE-T combo ports per switch (ports 21-24) Total shared 1000BASE-X combo ports per switch (ports 21-24) Total 10/100/1000BASE-T ports per stack Total combo SFP slots per stack Power Supply Flash Memory size RAM Memory size Overall Width (rack-mount flanges included) Chassis Width (rack-mount flanges not included) Height Height (rack units) Chassis Depth Weight Humidity Operating Temperature Storage Temperature Altitude 20 4 4 192 (stack of eight switches) 32 (stack of eight switches) AC-to-DC 126W output P/S or DC-to-DC 120W output P/S 64MB 256MB SDRAM 19 inches, approx. 17.5 inches 1.5 inch 1 RU 10.5 inches without power supplies installed 16.75 inches with power supplies installed. 14 lbs. (6.24 kg) without the power supply 5% to 90% Relative Humidity (Operating) 0% to 95% Relative Humidity (Storage) 0 to 45 degrees Celsius -20 to 70 degrees, Celsius Operating altitude: sea level at 40 degrees, Celsius and 10000 feet at 0 degrees, Celsius Storage altitude: sea level to 40000 feet 802.3z, 802.3ab, 1000BASE-T, IEEE 802.3u 10 or 100Mbps (full or half duplex) 1 Gigabit per second (full duplex) 1 Gigabit per second (full duplex) 9,216 bytes 10/100/1000BASE-T and 1000BASE-X 10BaseT: unshielded twisted-pair (UTP) 100BaseTX: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm 1000BaseT: unshielded twisted-pair (UTP), Category 5e 100 meters

Standards supported Data rate (RJ-45 Ports) Data rate (SFP ports) Maximum frame size Connections supported Cables supported

Maximum cable distance

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 52 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-48
The OmniSwitch 6850-48 is a stackable edge/workgroup switch offering 44 unshared 10/100/1000Base-T ports, as well as four combo ports individually configurable to be 10/100/1000Base-T or 1000Base-X high speed connections. The front panel of the OS6850-48 chassis contains the following major components: System status and slot indicator LEDs (44) unshared 10/100/1000Base-T ports (4) shared combo 10/100/1000Base-T ports (4) Combo SFP slots for 1000Base-X connections Console port (RJ-45) USB port (USB 2.0) (Future Release)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 53 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-48 Specifications

Total unshared 10/100/1000BASE-T ports per switch (ports 5-48) Total shared 10/100/1000BASE-T combo ports per switch (ports 1-4) Total shared 1000BASE-X combo ports per switch (ports 1-4) Total 10/100/1000BASE-T ports per stack Total combo SFP slots per stack Power Supply Flash Memory size RAM Memory size Overall Width (rack-mount flanges included) Chassis Width (rack-mount flanges not included) Height Height (rack units) Chassis Depth Weight Humidity Operating Temperature Storage Temperature Altitude 44 4 4 384 (stack of eight switches) 32 (stack of eight switches) AC-to-DC 126W output P/S or DC-to-DC 120W output P/S 64MB 256MB SDRAM 19 inches, approx. 17.5 inches 1.5 inch 1 RU 10.5 inches without power supplies installed 16.75 inches with power supplies installed. 14 lbs. (6.24 kg) without the power supply 5% to 90% Relative Humidity (Operating) 0% to 95% Relative Humidity (Storage) 0 to 45 degrees Celsius -20 to 70 degrees, Celsius Operating altitude: sea level at 40 degrees, Celsius and 10000 feet at 0 degrees, Celsius Storage altitude: sea level to 40000 feet 802.3z, 803.2ab, 1000BASE-T, IEEE 802.3u 10 or 100Mbps (full or half duplex) 1 Gigabit per second (full duplex) 1 Gigabit per second (full duplex) 9,216 bytes 10/100/1000BASE-T and 1000BASE-X 10BaseT: unshielded twisted-pair (UTP) 100BaseTX: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm 1000BaseT: unshielded twisted-pair (UTP), Category 5e 100 meters

Standards supported Data rate (RJ-45 Ports) Data rate (SFP ports) Maximum frame size Connections supported Cables supported

Maximum cable distance

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 54 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-24X
The OmniSwitch 6850-24X is a stackable edge/workgroup switch offering 20 unshared 10/100/1000Base-T Power over ports, two (2) 10 Gigabit XFP slots, as well as four combo ports individually configurable to be 10/100/1000Base-T or 1000Base-X high speed connections. The front panel of the OS6850-24X chassis contains the following major components: System status and slot indicator LEDs (20) unshared 10/100/1000Base-T ports (4) shared combo 10/100/1000Base-T ports (4) Combo SFP slots for 1000Base-X connections (2) 10 Gigabit XFP slots Console port (RJ-45) USB port (USB 2.0) (Future Release)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 55 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-24X Specifications

Total unshared 10/100/1000BASE-T ports per switch (ports 1-20) Total shared 10/100/1000BASE-T combo ports per switch (ports 21-24) Total shared 1000BASE-X combo ports per switch (ports 21-24) Total XFP Slots (ports 25-26) Total 10/100/1000BASE-T ports per stack Total combo SFP slots per stack Power Supply Flash Memory size RAM Memory size Overall Width (rack-mount flanges included) Chassis Width (rack-mount flanges not included) Height Height (rack units) Chassis Depth Weight Humidity Operating Temperature Storage Temperature Altitude 20 4 4 2 192 (stack of eight switches) 32 (stack of eight switches) AC-to-DC 126W output P/S or DC-to-DC 120W output P/S 64MB 256MB SDRAM 19 inches, approx. 17.5 inches 1.5 inch 1 RU 10.5 inches without power supplies installed 16.75 inches with power supplies installed. 14 lbs. (6.24 kg) without the power supply 5% to 90% Relative Humidity (Operating) 0% to 95% Relative Humidity (Storage) 0 to 45 degrees Celsius -20 to 70 degrees, Celsius Operating altitude: sea level at 40 degrees, Celsius and 10000 feet at 0 degrees, Celsius Storage altitude: sea level to 40000 feet 802.3z, 803.2ab, 1000BASE-T, IEEE 802.3u 10 or 100Mbps (full or half duplex) 1 Gigabit per second (full duplex) 1 Gigabit per second (full duplex) 10 Gigabit per second (full duplex) 9,216 bytes 10/100/1000BASE-T, 1000BASE-X, and 10GBASE-X 10BaseT: unshielded twisted-pair (UTP) 100BaseTX: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm 1000BaseT: unshielded twisted-pair (UTP), Category 5e 100 meters

Standards supported Data rate (RJ-45 Ports) Data rate (SFP ports) Data rate (XFP Ports) Maximum frame size Connections supported Cables supported

Maximum cable distance

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 56 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-48X
The OmniSwitch 6850-48X is a stackable edge/workgroup switch offering 48 unshared 10/100/1000Base-T ports and two (2) 10 Gigabit XFP slots. The front panel of the OS6850-48X chassis contains the following major components: System status and slot indicator LEDs (48) unshared 10/100/1000Base-T ports (2) 10 Gigabit XFP slots Console port (RJ-45) USB port (USB 2.0) (Future Release)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 57 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-48X Specifications

Total unshared 10/100/1000BASE-T ports per switch (ports 1-48) Total XFP Slots (Ports 49-50) Total 10/100/1000BASE-T ports per stack Power Supply Flash Memory size RAM Memory size Overall Width (rack-mount flanges included) Chassis Width (rack-mount flanges not included) Height Height (rack units) Chassis Depth Weight Humidity Operating Temperature Storage Temperature Altitude 48 2 384 (stack of eight switches) AC-to-DC 126W output P/S or DC-to-DC 120W output P/S 64MB 256MB SDRAM 19 inches, approx. 17.5 inches 1.5 inch 1 RU 10.5 inches without power supplies installed 16.75 inches with power supplies installed. 14 lbs. (6.24 kg) without the power supply 5% to 90% Relative Humidity (Operating) 0% to 95% Relative Humidity (Storage) 0 to 45 degrees Celsius -20 to 70 degrees, Celsius Operating altitude: sea level at 40 degrees, Celsius and 10000 feet at 0 degrees, Celsius Storage altitude: sea level to 40000 feet 802.3z, 802.3ab, 1000BASE-T, IEEE 802.3u 10 or 100Mbps (full or half duplex) 1 Gigabit per second (full duplex) 10 Gigabits per second (full duplex0 9,216 bytes 10/100/1000BASE-T, 1000BASE-X, and 1000GBASE-X 10BaseT: unshielded twisted-pair (UTP) 100BaseTX: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm 1000BaseT: unshielded twisted-pair (UTP), Category 5e 100 meters

Standards supported Data rate (RJ-45 Ports) Data rate (XFP Ports) Maximum frame size Connections supported Cables supported

Maximum cable distance

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 58 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-P24
The OmniSwitch 6850-P24 is a stackable edge/workgroup switch offering 20 unshared 10/100/1000Base-T Power over Ethernet (PoE) ports, as well as four combo ports individually configurable to be 10/100/1000 Base-T PoE or 1000 Base-X high speed connections. The front panel of the OS6850-P24 chassis contains the following major components: System status and slot indicator LEDs (20) unshared 10/100/1000Base-T PoE ports (4) shared combo 10/100/1000Base-T PoE ports (4) Combo SFP slots for 1000Base-X connections Console port (RJ-45) USB port (USB 2.0) (Future Release)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 59 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-P24 Specifications

Total unshared 10/100/1000BASE-T PoE ports per switch (ports 1-20) Total shared 10/100/1000BASE-T PoE combo ports per switch (ports 21-24) Total shared 1000BASE-X combo ports per switch (ports 21-24) Total 10/100/1000BASE-T ports per stack Total combo SFP slots per stack Power Supply Flash Memory size RAM Memory size Overall Width (rack-mount flanges included) Chassis Width (rack-mount flanges not included) Height Height (rack units) Chassis Depth Weight Humidity Operating Temperature Storage Temperature Altitude 20 4 4 192 (stack of eight switches) 32 (stack of eight switches) AC-to-DC 510W output P/S or AC-to-DC 360W output P/S 64MB 256MB SDRAM 19 inches, approx. 17.5 inches 1.5 inch 1 RU 10.5 inches without power supplies installed 16.75 inches with power supplies installed. 14 lbs. (6.24 kg) without the power supply 5% to 90% Relative Humidity (Operating) 0% to 95% Relative Humidity (Storage) 0 to 45 degrees Celsius -20 to 70 degrees, Celsius Operating altitude: sea level at 40 degrees, Celsius and 10000 feet at 0 degrees, Celsius Storage altitude: sea level to 40000 feet 802.3z, 802.3ab, 1000BASE-T, IEEE 802.3u, IEEE 802.3af (DTE Power via MDI MIB); IAB RFCs 826 , 894 10 or 100Mbps (full or half duplex) 1 Gigabit per second (full duplex) 1 Gigabit per second (full duplex) 9,216 bytes 10/100/1000BASE-T and 1000BASE-X IP- phones, Bluetooth Access Points, Internet cameras, and other devices requiring power over Ethernet 10BaseT: unshielded twisted-pair (UTP) 100BaseTX: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm 1000BaseT: unshielded twisted-pair (UTP), Category 5e Default 15.4watts per port Configurable from 3watts to 15.4watts per port Using the 360watts P/S, the maximum available PoE power is 240 watts (less 1watt per port of overhead) per unit. Using the 510watts P/S, the maximum available PoE power is 390watts (less 1watt per port of overhead) per unit. Please refer to the Power Supply Specification Section for more details. 100 meters

Standards supported Data rate (RJ-45 Ports) Data rate (SFP ports) Maximum frame size Connections supported

Cables supported

PoE Power supplied to port

Maximum cable distance (RJ-45 ports)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 60 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-P48
The OmniSwitch 6850-P48 is a stackable edge/workgroup switch offering 44 unshared 10/100/1000Base-T Power over Ethernet (PoE) ports, as well as four combo ports individually configurable to be10/100/1000Base-T PoE or 1000Base-X high speed connections. The front panel of the OS6850-P48 chassis contains the following major components: System status and slot indicator LEDs (44) unshared 10/100/1000Base-T PoE ports (4) shared combo 10/100/1000Base-T PoE ports (4) Combo SFP slots for 1000Base-X connections Console port (RJ-45) USB port (USB 2.0) (Future Release)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 61 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-P48 Specifications

Total unshared 10/100/1000BASE-T PoE ports per switch (ports 5 48) Total shared 10/100/1000BASE-T PoE combo ports per switch (ports 1-4) Total shared 1000BASE-X combo ports per switch (ports 45-48) Total 10/100/1000BASE-T ports per stack Total combo SFP slots per stack Power Supply Flash Memory size RAM Memory size Overall Width (rack-mount flanges included) Chassis Width (rack-mount flanges not included) Height Height (rack units) Chassis Depth Weight Humidity Operating Temperature Storage Temperature Altitude 44 4 4 384 (stack of eight switches) 32 (stack of eight switches) AC-to-DC 510W output P/S or AC-to-DC 360W output P/S 64MB 256MB SDRAM 19 inches, approx. 17.5 inches 1.5 inch 1 RU 10.5 inches without power supplies installed 16.75 inches with power supplies installed. 14 lbs. (6.24 kg) without the power supply 5% to 90% Relative Humidity (Operating) 0% to 95% Relative Humidity (Storage) 0 to 45 degrees Celsius -20 to 70 degrees, Celsius Operating altitude: sea level at 40 degrees, Celsius and 10000 feet at 0 degrees, Celsius Storage altitude: sea level to 40000 feet 802.3z, 802.3ab, 1000BASE-T, IEEE 802.3u, IEEE 802.3af (DTE Power via MDI MIB); IAB RFCs 826, 894 10 or 100Mbps (full or half duplex) 1 Gigabit per second (full duplex) 1 Gigabit per second (full duplex) 9,216 bytes 10/100/1000BASE-T and 1000BASE-X IP- phones, Bluetooth Access Points, Internet cameras, and other devices requiring power over Ethernet 10BaseT: unshielded twisted-pair (UTP) 100BaseTX: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm 1000BaseT: unshielded twisted-pair (UTP), Category 5e Default 15.4watts per port Configurable from 3watts to 15.4watts per port Using the 360watts P/S, the maximum available PoE power is 240 watts (less 1watt per port of overhead) per unit. Using the 510watts P/S, the maximum available PoE power is 390watts (less 1watt per port of overhead) per unit. Please refer to the Power Supply Specification Section for more details. 100 meters

Standards supported Data rate (RJ-45 Ports) Data rate (SFP ports) Maximum frame size Connections supported

Cables supported

PoE Power supplied to port

Maximum cable distance (RJ-45 ports)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 62 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-P24X
The OmniSwitch 6850-P24X is a stackable edge/workgroup switch offering 20 unshared 10/100/1000Base-T Power over Ethernet (PoE) ports, two (2) 10 Gigabit XFP slots, as well as four combo ports individually configurable to be 10/100/1000Base-T PoE or 1000Base-X high-speed connections. The front panel of the OS6850-P24X chassis contains the following major components: System status and slot indicator LEDs (20) unshared 10/100/1000Base-T PoE ports (4) shared combo 10/100/1000Base-T PoE ports (4) Combo SFP slots for 1000Base-X connections (2) 10 Gigabit XFP slots Console port (RJ-45) USB port (USB 2.0) (Future Release)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 63 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-P24X Specifications

Total unshared 10/100/1000BASE-T PoE ports per switch (Ports 1-20) Total shared 10/100/1000BASE-T PoE combo ports per switch (Ports 21-24) Total shared 1000BASE-X combo ports per switch (ports 21-24) Total XFP Slots (Ports 25-26) Total 10/100/1000BASE-T ports per stack Total combo SFP slots per stack Power Supply Flash Memory size RAM Memory size Overall Width (rack-mount flanges included) Chassis Width (rack-mount flanges not included) Height Height (rack units) Chassis Depth Weight Humidity Operating Temperature Storage Temperature Altitude 20 4 4 2 192 (stack of eight switches) 32 (stack of eight switches) AC-to-DC 510W output P/S or AC-to-DC 360W output P/S 64MB 256MB SDRAM 19 inches, approx. 17.5 inches 1.5 inch 1 RU 10.5 inches without power supplies installed 16.75 inches with power supplies installed. 14 lbs. (6.24 kg) without the power supply 5% to 90% Relative Humidity (Operating) 0% to 95% Relative Humidity (Storage) 0 to 45 degrees Celsius -20 to 70 degrees, Celsius Operating altitude: sea level at 40 degrees, Celsius and 10000 feet at 0 degrees, Celsius Storage altitude: sea level to 40000 feet 802.3z, 802.3ab, 1000BASE-T, IEEE 802.3u, IEEE 802.3af (DTE Power via MDI MIB); IAB RFCs 826, 894 10 or 100Mbps (full or half duplex) 1 Gigabit per second (full duplex) 1 Gigabit per second (full duplex) 10Gigabit per second (full duplex) 9,216 bytes 10/100/1000BASE-T and 1000BASE-X IP- phones, Bluetooth Access Points, Internet cameras, and other devices requiring power over Ethernet 10BaseT: unshielded twisted-pair (UTP) 100BaseTX: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm 1000BaseT: unshielded twisted-pair (UTP), Category 5e Default 15.4watts per port Configurable from 3watts to 15.4watts per port Using the 360watts P/S, the maximum available PoE power is 240 watts (less 1watt per port of overhead) per unit. Using the 510watts P/S, the maximum available PoE power is 390watts (less 1watt per port of overhead) per unit. Please refer to the Power Supply Specification Section for more details. 100 meters Alcatel-Lucent-ESD Calabasas/CA./USA

Standards supported Data rate (RJ-45 Ports) Data rate (SFP ports) Data rate (XFP Ports) Maximum frame size Connections supported

Cables supported

PoE Power supplied to port

Maximum cable distance (RJ-45 ports)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 64 Software & Hardware Release: AOSv6.3.1r01

OmniSwitch 6850-P48X
The OmniSwitch 6850-P48X is a stackable edge/workgroup switch offering 48 unshared 10/100/1000Base-T Power over Ethernet (PoE) ports and two (2) 10 Gigabit XFP slots. The front panel of the OS6850-P48X chassis contains the following major components: System status and slot indicator LEDs (48) unshared 10/100/1000Base-T PoE ports (2) 10 Gigabit XFP slots Console port (RJ-45) USB port (USB 2.0) (Future Release)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 65 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-P48X Specifications

Total unshared 10/100/1000BASE-T PoE ports per switch (Ports 1-48) Total XFP Slots (Ports 49-50) Total 10/100/1000BASE-T ports per stack Power Supply Flash Memory size RAM Memory size Overall Width (rack-mount flanges included) Chassis Width (rack-mount flanges not included) Height Height (rack units) Chassis Depth Weight Humidity Operating Temperature Storage Temperature Altitude 48 2 384 (stack of eight switches) AC-to-DC 510W output P/S or AC-to-DC 360W output P/S 64MB 256MB SDRAM 19 inches, approx. 17.5 inches 1.5 inch 1 RU 10.5 inches without power supplies installed 16.75 inches with power supplies installed. 14 lbs. (6.24 kg) without the power supply 5% to 90% Relative Humidity (Operating) 0% to 95% Relative Humidity (Storage) 0 to 45 degrees Celsius -20 to 70 degrees, Celsius Operating altitude: sea level at 40 degrees, Celsius and 10000 feet at 0 degrees, Celsius Storage altitude: sea level to 40000 feet 802.3z, 802.3ab, 1000BASE-T, IEEE 802.3u, IEEE 802.3af (DTE Power via MDI MIB); IAB RFCs 826, 894 10 or 100Mbps (full or half duplex) 1 Gigabit per second (full duplex) 10 Gigabit per second (full duplex) 9,216 bytes 10/100/1000BASE-T IP- phones, Bluetooth Access Points, Internet cameras, and other devices requiring power over Ethernet 10BaseT: unshielded twisted-pair (UTP) 100BaseTX: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm 1000BaseT: unshielded twisted-pair (UTP), Category 5e Default 15.4watts per port Configurable from 3watts to 15.4watts per port Using the 360watts P/S, the maximum available PoE power is 240 watts (less 1watt per port of overhead) per unit. Using the 510watts P/S, the maximum available PoE power is 390watts (less 1watt per port of overhead) per unit. Please refer to the Power Supply Specification Section for more details. 100 meters

Standards supported Data rate (RJ-45 Ports) Data rate (XFP ports) Maximum frame size Connections supported

Cables supported

PoE Power supplied to port

Maximum cable distance (RJ-45 ports)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 66 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-U24X
The OmniSwitch 6850-U24X is an edge/workgroup switch offering 24 1000Base-X MiniGBIC SFP ports, two (2) 10 Gigabit XFP slots, as well as four combo ports individually configurable to 10/100/1000 Base-T ports. The front panel of the OS6850-U24X chassis contains the following major components: System status and slot indicator LEDs (22) unshared 1000Base-X MiniGBIC SFP ports (2) Shared combo 1000Base-X MiniGBIC SFP ports (2) Combo RJ-45 10/100/1000Base-T ports (2) 10 Gigabit XFP slots Console port (RJ-45) USB port (USB 2.0) Note. USB 2.0 is not supported in this release.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 67 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-U24X Specifications

Total unshared 1000Base-X MiniGBIC SFP ports per switch (ports 1-22) Total shared 1000Base-X MiniGBIC SFP ports per switch (ports 23-24) Total combo10/100/1000Base-T ports per switch (ports 23-24) Total XFP Slots (ports 25-26) Total 1000Base-X MiniGBIC SFP ports per stack Total combo 10/100/1000Base-T ports per stack Power Flash memory size RAM memory size Overall Width (rack-mount flanges included) Chassis Width (rack-mount flanges not included) Height Height (rack units) Chassis Depth Weight Humidity Operating Temperature Storage Temperature Altitude 22 2 2 2 192 (stack of eight switches) 16 (stack of eight switches) 126/120W (AC/DC) power supply 64 MB 256 MB SDRAM 19 inches, approx. 17.5 inches 1.5 inches 1 RU 10.5 inches without power supplies installed; 16.75 inches with power supplies installed 14 lbs. (6.24 Kg) without power supply 5% to 90% Relative Humidity (Operating) 0% to 95% Relative Humidity (Storage) 0 to 45 degrees, Celsius -20 to 70 degrees, Celsius Operating altitude: sea level at 40 degrees, Celsius and 10000 feet at 0 degrees, Celsius Storage altitude: sea level to 40000 feet 10/100/1000Base-T and 1000Base-X 10 or 100 Mbps (full or half duplex) 1 Gigabit per second (full duplex) 1 Gigabit per second (full duplex) 10 Gigabits per second (full duplex) 9216 Bytes 10/100/1000base-T, 1000Base-X, 10GBASE-X 10BaseT: unshielded twisted-pair (UTP) 100BaseTX: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm 1000BaseT: unshielded twisted-pair (UTP), Category 5e 100 meters

Standards supported Data rate (RJ-45 ports) Data rate (SFP Ports) Data rate (XFP Ports) Maximum frame size Connections supported Cable supported (RJ-45 ports)

Maximum cable distance (RJ-45 ports)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 68 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-24L
The OmniSwitch 6850-24L is a stackable edge/workgroup switch offering 20 unshared 10/100Base-T ports, as well as four combo ports individually configurable to be 10/100/1000 Base-T or 1000 Base-X high speed connections. The front panel of the OS6850-24L chassis contains the following major components: System status and slot indicator LEDs (20) unshared 10/100Base-T ports (4) shared combo 10/100/1000Base-T ports (4) Combo SFP slots for 1000Base-X connections Console port (RJ-45) USB port (USB 2.0) Note. USB 2.0 will be supported in a future release. Note. The 20 (non combo ports) 10/100Base-T ports on the OmniSwitch 6850-24L can be upgraded to 10/100/1000Base-T ports.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 69 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-24L Specifications

Total unshared 10/100Base-T ports per switch (Ports 120) Total shared 10/100/1000Base-T combo ports per switch (Ports 2124) Total combo 1000Base-X combo SFP slots per switch (Ports 2124) Total 10/100Base-T ports per stack Total combo SFP slots per stack Power Flash memory size RAM memory size Overall Width (rack-mount flanges included) Chassis Width (rack-mount flanges not included) Height Height (rack units) Chassis Depth Weight Humidity Operating Temperature Storage Temperature Altitude 20 4 4 160 (stack of eight switches) 32 (stack of eight switches) 126/120W (AC/DC) power supply

64 MB 256 MB SDRAM
19 inches, approx. 17.5 inches 1.5 inches 1 RU 10.5 inches without power supplies installed; 16.75 inches with power supplies installed 14 lbs. (6.24 Kg) without power supply 5% to 90% Relative Humidity (Operating) 0% to 95% Relative Humidity (Storage) 0 to 45 degrees, Celsius -20 to 70 degrees, Celsius Operating altitude: sea level at 40 degrees, Celsius and 10000 feet at 0 degrees, Celsius Storage altitude: sea level to 40000 feet 802.3z, 802.3ab, 1000Base-T, IEEE 802.3u 10 or 100 Mbps (full or half duplex) 1 Gigabit per second (full duplex) 1 Gigabit per second (full duplex) 9216 bytes 10/100/1000Base-T and 1000Base-X 10BaseT: unshielded twisted-pair (UTP) 100BaseTX: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm 1000BaseT: unshielded twisted-pair (UTP), Category 5e 100 meters

Standards supported Data rate (RJ-45 Ports) Data rate (SFP Ports) Maximum frame size Connections supported Cable supported (RJ-45 ports)

Maximum cable distance (RJ-45 ports)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 70 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-P24L
The OmniSwitch 6850-P24L is a stackable edge/workgroup switch offering 20 unshared 10/100Base-T Power over Ethernet (PoE) ports, as well as four combo ports individually configurable to be 10/100/1000Base-T PoE or 1000 Base-X high speed connections. The front panel of the OS6850-P24L chassis contains the following major components: System status and slot indicator LEDs (20) unshared 10/100Base-T PoE ports (4) shared combo 10/100/1000Base-T PoE ports (4) Combo SFP slots for 1000Base-X connections Console port (RJ-45) USB port (USB 2.0) Note. USB 2.0 will be supported in a future release. Note. The 20 (non-combo ports) 10/100Base-T PoE ports on the OmniSwitch 6850-P24L can be upgraded to 10/100/1000Base-T PoE ports.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 71 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-P24L Specifications

Total unshared 10/100Base-T ports per switch (Ports 120) Total shared 10/100/1000Base-T combo ports per switch (Ports 2124) Total combo 1000Base-X combo SFP slots per switch (Ports 2124) Total 10/100Base-T ports per stack Total combo SFP slots per stack Power Flash memory size RAM memory size Overall Width (rack-mount flanges included) Chassis Width (rack-mount flanges not included) Height Height (rack units) Chassis Depth Weight Humidity Operating Temperature Storage Temperature Altitude 20 4 4 160 (stack of eight switches) 32 (stack of eight switches) 510/360W (AC/DC) power supply

64 MB 256 MB SDRAM
19 inches, approx. 17.5 inches 1.5 inches 1 RU 10.5 inches without power supplies installed; 16.75 inches with power supplies installed 14 lbs. (6.24 Kg) without power supply 5% to 90% Relative Humidity (Operating) 0% to 95% Relative Humidity (Storage) 0 to 45 degrees, Celsius -20 to 70 degrees, Celsius Operating altitude: sea level at 40 degrees, Celsius and 10000 feet at 0 degrees, Celsius Storage altitude: sea level to 40000 feet 802.3z, 802.3ab, 1000Base-T, IEEE 802.3u, IEEE 802.3af (DTE Power Via MDI MIB) ; IAB RFCs 826, 894 10 or 100 Mbps (full or half duplex) 1 Gigabit per second (full duplex) 1 Gigabit per second (full duplex) 9216 bytes IP phones, Bluetooth Access Points, Internet Cameras, and other devices requiring power over Ethernet 10BaseT: unshielded twisted-pair (UTP) 100BaseTX: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm 1000BaseT: unshielded twisted-pair (UTP), Category 5e Default 15.4watts per port Configurable from 3watts to 15.4watts per port Using the 360watts P/S, the maximum available PoE power is 240 watts (less 1watt per port of overhead) per unit. Using the 510watts P/S, the maximum available PoE power is 390watts (less 1watt per port of overhead) per unit. Please refer to the Power Supply Specification Section for more details. 100 meters

Standards supported Data rate (RJ-45 Ports) Data rate (SFP Ports) Maximum frame size Connections supported Cable supported (RJ-45 ports)

PoE Power supplied to port

Maximum cable distance (RJ-45 ports)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 72 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-48L
The OmniSwitch 6850-48L is a stackable edge/workgroup switch offering 44 unshared 10/100Base-T ports, as well as four combo ports individually configurable to 10/100/1000Base-T or 1000Base-X high speed connections. The front panel of the OS6850-48L chassis contains the following major components: System status and slot indicator LEDs (44) unshared 10/100Base-T ports (4) shared combo 10/100/1000Base-T ports (4) Combo SFP slots for 1000Base-X connections Console port (RJ-45) USB port (USB 2.0) Note. USB 2.0 will be supported in a future release. Note. The 44 (non combo ports) 10/100Base-T ports on the OmniSwitch 6850-48L can be upgraded to 10/100/1000Base-T ports.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 73 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-48L Specifications

Total unshared 10/100Base-T ports per switch (Ports 144) Total shared 10/100/1000Base-T combo ports per switch (Ports 45-48) Total combo 1000Base-X combo SFP slots per switch Total 10/100Base-T ports per stack Total combo SFP slots per stack Power Flash memory size RAM memory size Overall Width (rack-mount flanges included) Chassis Width (rack-mount flanges not included) Height Height (rack units) Chassis Depth Weight Humidity Operating Temperature Storage Temperature Altitude 44 4 4 352 (stack of eight switches) 32 (stack of eight switches) 126/120W (AC/DC) power supply

64 MB 256 MB SDRAM
19 inches, approx. 17.5 inches 1.5 inches 1 RU 10.5 inches without power supplies installed; 16.75 inches with power supplies installed 14 lbs. (6.24 Kg) without power supply 5% to 90% Relative Humidity (Operating) 0% to 95% Relative Humidity (Storage) 0 to 45 degrees, Celsius -20 to 70 degrees, Celsius Operating altitude: sea level at 40 degrees, Celsius and 10000 feet at 0 degrees, Celsius Storage altitude: sea level to 40000 feet 802.3z, 802.3ab, 1000Base-T, IEEE 802.3u 10 or 100 Mbps (full or half duplex) 1 Gigabit per second (full duplex) 1 Gigabit per second (full duplex) 9216 bytes 10/100/1000Base-T and 1000Base-X 10BaseT: unshielded twisted-pair (UTP) 100BaseTX: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm 1000BaseT: unshielded twisted-pair (UTP), Category 5e 100 meters

Standards supported Data rate (RJ-45 Ports) Data rate (SFP Ports) Maximum frame size Connections supported Cable supported (RJ-45 ports)

Maximum cable distance (RJ-45 ports)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 74 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-P48L
The OmniSwitch 6850-P48L is a stackable edge/workgroup switch offering 44 unshared 10/100Base-T Power over Ethernet (PoE) ports, as well as four combo ports individually configurable to 10/100/1000Base-T PoE or 1000Base-X high speed connections. The front panel of the OS6850-P48L chassis contains the following major components: System status and slot indicator LEDs (44) unshared 10/100Base-T PoE ports (4) shared combo 10/100/1000Base-T PoE ports (4) Combo SFP slots for 1000Base-X connections Console port (RJ-45) USB port (USB 2.0) Note. USB 2.0 will be supported in a future release. Note. The 44 (non-combo ports) 10/100Base-T PoE ports on the OmniSwitch 6850-P48L can be upgraded to 10/100/1000Base-T PoE ports. Please contact your Alcatel representative for more information.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 75 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850-P48L Specifications

Total unshared 10/100Base-T ports per switch (Ports 120) Total shared 10/100/1000Base-T combo ports per switch (Ports 2124) Total combo 1000Base-X combo SFP slots per switch (Ports 2124) Total 10/100Base-T ports per stack Total combo SFP slots per stack Power Flash memory size RAM memory size Overall Width (rack-mount flanges included) Chassis Width (rack-mount flanges not included) Height Height (rack units) Chassis Depth Weight Humidity Operating Temperature Storage Temperature Altitude 44 4 4 352 (stack of eight switches) 32 (stack of eight switches) 510/360W (AC/DC) power supply

64 MB 256 MB SDRAM
19 inches, approx. 17.5 inches 1.5 inches 1 RU 10.5 inches without power supplies installed; 16.75 inches with power supplies installed 14 lbs. (6.24 Kg) without power supply 5% to 90% Relative Humidity (Operating) 0% to 95% Relative Humidity (Storage) 0 to 45 degrees, Celsius -20 to 70 degrees, Celsius Operating altitude: sea level at 40 degrees, Celsius and 10000 feet at 0 degrees, Celsius Storage altitude: sea level to 40000 feet 802.3z, 802.3ab, 1000Base-T, IEEE 802.3u, IEEE 802.3af (DTE Power Via MDI MIB) ; IAB RFCs 826, 894 10 or 100 Mbps (full or half duplex) 1 Gigabit per second (full duplex) 1 Gigabit per second (full duplex) 9216 bytes IP phones, Bluetooth Access Points, Internet Cameras, and other devices requiring power over Ethernet 10BaseT: unshielded twisted-pair (UTP) 100BaseTX: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm 1000BaseT: unshielded twisted-pair (UTP), Category 5e Default 15.4watts per port Configurable from 3watts to 15.4watts per port Using the 360watts P/S, the maximum available PoE power is 240 watts (less 1watt per port of overhead) per unit. Using the 510watts P/S, the maximum available PoE power is 390watts (less 1watt per port of overhead) per unit. Please refer to the Power Supply Specification Section for more details. 100 meters

Standards supported Data rate (RJ-45 Ports) Data rate (SFP Ports) Maximum frame size Connections supported Cable supported (RJ-45 ports)

PoE Power supplied to port

Maximum cable distance (RJ-45 ports)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 76 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Rear Panel
The rear panel of OmniSwitch 6850 Series switches contains the following major components: Two DB-25 connectors for the primary power supply, which can be used for a single 510 Watt supply or two 360, 126, Or 120 Watt power supplies One DB-25 connector for an optional redundant power supply. Two stacking ports (A and B) Grounding block for type LCD8-10A-L grounding lug Note. The figure shows a pre-production version of the chassis without product, safety, and compliance information labels. All production versions of the chassis have these labels. Note: please refer to the Pin-Outs section for the DB-25 pins arrangements.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 77 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Status LEDs
LEDs provide visual status information. These status lights are used to indicate conditions, such as hardware and software status, primary role status (stacked configurations), power supply status, primary and secondary status (stacked configurations), fan and temperature errors, 10 Gigabit uplink status (when applicable), slot number information, data speed, link integrity, and activity. Refer to the diagram below for detailed information on LED states.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 78 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

10/100/1000 LEDs
There is a single LED for each corresponding 10/100/1000 Mbps ports. Displays solid green for a valid link; displays blinking green when transmitting or receiving packets in a link up state for non-PoE. Displays solid amber for a valid link; displays blinking amber when transmitting or receiving packets in a link up state for PoE.

1000 SFP LEDs

There is a single LED for 1000 Mbps SFP ports. Displays solid green for a valid link; displays blinking green when transmitting or receiving packets in a link up state; off when no link is detected.

10000 XFP LEDs

This LED corresponds to XFP1 port 25 on OS6850-P24X switches and port 49 on OS6850-P48X switches. It displays solid green when the port is up and blinking green when the port is transmitting or receiving packets in a link up state. This LED is off when no link is detected. This LED corresponds to XFP2 port 26 on OS6850-P24X switches and port 50 on OS6850-P48X switches. It displays solid green when the port is up and blinking green when the port is transmitting or receiving packets in a link up state. This LED is off when no link is detected.

Chassis Rear Panel

The rear panel of OmniSwitch 6850 Series switches contains the following major components: Two DB-25 connectors for the primary power supply, which can be used for a single 510 Watt supply or two 360, 126, or 120 Watt power supplies. One DB-25 connector for an optional redundant power supply Two stacking ports (A and B) Grounding block for type LCD8-10A-L grounding lug

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 79 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Architecture
The OmniSwitch 6850-48 & P48 Internal Architecture

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 80 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The OmniSwitch 6850-48X & P48X Internal Architecture

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 81 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The OmniSwitch 6850-24 & P24 Internal Architecture

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 82 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The OmniSwitch 6850-24X & P24X Internal Architecture

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 83 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850 -- Fiber Optics Transceivers Technical Specifications Overview

XFP-10G-ER40 XFP-10G-LR Transceivers 10-Gigabit Ethernet Transceivers (XFP MSA) 10 Gigabit Ethernet optical transceiver (XFP MSA). Supports single mode fiber over 1550nm wavelength (nominal) with an LC connector. Typical reach of 40 Km on 9/125 m SMF. 10 Gigabit Ethernet optical transceiver (XFP MSA). Supports single mode fiber over 1310nm wavelength (nominal) with an LC connector. Typical reach of 10 Km on 9/125 m SMF. [Formerly known as 10G-XFP-LR] 10 Gigabit Ethernet optical transceiver (XFP MSA). Supports multimode fiber over 850nm wavelength (nominal) with an LC connector. Typical reach of 300m on 50/125 m MMF. [Formerly known as 10G-XFP-SR] 10 Gigabit Ethernet optical transceiver (XFP MSA). Supports single mode fiber over 1550nm wavelength (nominal) with an LC connector. Typical reach of 80 Km on 9/125 m SMF. Gigabit Ethernet Transceivers (SFP MSA) CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ gray latch. Supports single mode fiber over 1470 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ violet latch. Supports single mode fiber over 1490 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ blue latch. Supports single mode fiber over 1510 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ green latch. Supports single mode fiber over 1530 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ yellow latch. Supports single mode fiber over 1550 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ orange latch. Supports single mode fiber over 1570 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ red latch. Supports single mode fiber over 1590 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ red latch. Supports single mode fiber over 1610 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. 1000Base-BX SFP transceiver with an LC type of interface. This bi-directional transceiver is designed for use over single mode fiber optic on a single strand link up to 10 km. Transmits 1490 nm and receives 1310 nm optical signal. 1000Base-BX SFP transceiver with an LC type of interface. This bi-directional transceiver is designed for use over single mode fiber optic on a single strand link up to 10 km. Transmits 1310 nm and receives 1490 nm optical signal. Extended 1000Base-SX Gigabit Ethernet optical transceiver (SFP MSA). Supports multimode fiber over 850nm wavelength (nominal) with an LC connector. Reach of up to 2 km (based on grade and condition of fiber) on 62.5/125 m MMF or 550m on 50/125 m MMF. Requires SFP-GIG-EXTND or GBIC-GIG-EXTND at the remote termination. [Formerly known as GE-EXTND-SFP] 1000Base-LH Gigabit Ethernet optical transceiver (SFP MSA). Supports single mode fiber over 1310 nm wavelength (nominal) with an LC connector. Typical reach of 40Km on 9/125 m SMF. 1000Base-LH Gigabit Ethernet optical transceiver (SFP MSA). Supports single mode fiber over 1550nm wavelength (nominal) with an LC connector. Typical reach of 70 Km on 9/125 m SMF. [Formerly known as MINIGBIC-LH-70] 1000Base-LX Gigabit Ethernet optical transceiver (SFP MSA). Supports single mode fiber over 1310nm wavelength (nominal) with an LC connector. Typical reach of 10 Km on 9/125 m SMF. [Formerly known as MINIGBIC-LX] 1000Base-SX Gigabit Ethernet optical transceiver (SFP MSA). Supports multimode fiber over 850nm wavelength (nominal) with an LC connector. Typical reach of 300m on 62.5/125 m MMF or 550m on 50/125 m MMF. [Formerly known as MINIGBIC-SX] 1000Base-T Gigabit Ethernet Transceiver (SFP MSA) - Supports category 5, 5E, and 6 copper cabling up to 100m. SFP only works in 1000 Mbps speed and full-duplex mode

XFP-10G-SR

XFP-10G-ZR80

SFP-GIG-47CWD60 SFP-GIG-49CWD60 SFP-GIG-51CWD60 SFP-GIG-53CWD60 SFP-GIG-55CWD60 SFP-GIG-57CWD60 SFP-GIG-59CWD60 SFP-GIG-61CWD60 SFP-GIG-BX-D SFP-GIG-BX-U SFP-GIG-EXTND

SFP-GIG-LH40 SFP-GIG-LH70

SFP-GIG-LX

SFP-GIG-SX

SFP-GIG-T

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 84 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

SFP-DUAL-MM

SFP-DUAL-SM10

Dual Speed Ethernet Transceivers (SFP MSA) Dual Speed 100Base-FX or 1000Base-X Ethernet optical transceiver (SFP MSA). Supports multimode fiber over 1310nm wavelength (nominal) with an LC connector. Typical reach of 550m at Gigabit speed and 2km at 100Mbps speed. Note: - At 100Mbit speed, this SFP can interoperate with SFP-100-LC-MM or similar transceiver on the other end, - At Gigabit speed, this SFP cannot interoperate with SFP-GIG-SX or similar transceiver on the other end running over 850nm wavelength. - SFP supported on OS9-GNI-U24 Gigabit Ethernet Module and OS6850-U24X SFP ports (non combo) Dual Speed 100Base-FX or 1000Base-X Ethernet optical transceiver (SFP MSA). Supports single mode fiber over 1310nm wavelength (nominal) with an LC connector. Typical reach of 10km at Gigabit speed and 100Mbps speed. Note: - At 100Mbit speed, this SFP can interoperate with SFP-100-LC-SM15 or similar transceiver, - At Gigabit speed, this SFP can interoperate with SFP-GIG-LX or similar transceiver. - SFP supported on OS9-GNI-U24 Gigabit Ethernet Module and OS6850-U24X SFP ports (non combo)

SFP-100-BX20LT

SFP-100-BX20NU

SFP-100-LC-MM SFP-100-LC-SM15 SFP-100-LC-SM40

100BASE-FX Ethernet Transceivers 100Base-BX SFP trans. with an SC type interface. This bi-directional trans. is designed for use over single mode fiber optic on a single strand link up to 20KM point-to-point. This transceiver is normally used in the central office (OLT) transmits 1550nm and receives 1310nm optical signal 100Base-BX SFP trans. with an SC type interface. This bi-directional trans. is designed for use over single mode fiber optic on a single strand link up to 20KM point-to-point. This transceiver is normally used in the client (ONU) transmits 1310nm and receives 1550nm optical signal 100Base-FX SFP trans. with an LC type interface. This trans. is designed for use over multimode fiber optic cable. 100Base-FX SFP trans. with an LC type interface. This trans. is designed for use over single mode fiber optic cable up to 15KM. 100Base-FX SFP trans. with an LC type interface. This trans. is designed for use over single mode fiber optic cable up to 40KM.

Supported Configuration Matrix for New Ethernet Transceivers in Release 6.1.5r01 OS6800/OS6850 OS6800-U24 OS6850-U24X Combo Ports Non-Combo Ports SFP-GIG-T - 1000Base-T Gigabit Supported Supported Supported Ethernet Transceiver (SFP MSA). SFP-DUAL-MM - Dual Speed OS6800: Un-supported Un-supported Supported 100Base-FX or 1000Base-X Ethernet optical OS6850: Supported. transceiver. Release 6.3.1 provides support for this SFP on OS6850 combo ports. SFP-DUAL-SM10 - Dual Speed OS6800: Un-supported Un-supported Supported 100Base-FX or 1000Base-X Ethernet optical OS6850: Supported. transceiver (SFP MSA) Release 6.3.1 provides support for this SFP on OS6850 combo ports. SFP-100-BX20LT - 100Base-BX Un-supported Un-supported Supported SFP bi-directional transceiver. SFP-100-BX20NU - 100Base-BX Un-supported Un-supported Supported SFP bi-directional transceiver SFP-100-LC-MM - 100Base-FX Un-supported Un-supported Supported SFP transceiver. SFP-100-LC-SM15 - 100Base-FX Un-supported Un-supported Supported SFP transceiver. SFP-100-LC-SM40 - 100Base-FX Un-supported Un-supported Supported SFP transceiver. SFP

OS9-GNI-U24 Supported Supported

Supported

Un-supported Un-supported Un-supported Un-supported Un-supported

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 85 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Small Form Factor Pluggable (SFP MSA)

OmniSwitch 6850 Series switches use both copper-based and fiber-based optical Small Form Factor Pluggable (SFP) transceivers. SFPs are fully hot-swappable and are available for both short-reach and long-reach applications. Copper-based and fiber-based optical SFPs can be mixed on the same module.
Note: The information discussed in this section is not exhaustive and the original manufacturers fiber optics references must be consulted to obtain further information for proper design guidelines.

The maximum distance supported with fiber optics transceivers will be influenced by the following factors: o Specified fiber plants standards for cable wiring such as ISO/IEC-11801, TIA 568, IEEE 802.3u, o IEEE 802.3z/1000BASE-SX/LX/LHetc. o Modal Bandwidth (measured in MHZ*km: such as 200 MHZ*km, or 160 MHZ*kmetc) o Fiber quality o Attenuation or dB of loss per km (Attenuation is a measure of the loss of signal strength or light power that occurs as light pulses propagate through a run of multimode or single-mode fiber. Measurements are typically defined in terms of decibels or dB/km.). This loss could result from patch panels, splicing, optical connectors, optical jointsetc. o The Optical Power Budget (OPB) in dB allowance o The Optical Power Budget (in dB) provides the necessary optical signal range to establish a working fiber-optic link. The OPB is allocated for the fiber-optic cable. The OPB is the available optical power for a fiber optic link to accommodate fiber cable losses plus losses due to in-line connectors, splices, optical switches, and to provide margin for link aging and unplanned losses due to cable plant reconfiguration or repair. o The worst-case Optical Power Budget in dB for a fiber optic link is determined by: The difference between the minimum transmitters output optical power and the lowest receiver sensitivity. o The best way to determine the distance being supported is to take an OTDR (Optical Time Domain Reflecto-meter) measurement on the fiber cable plant. (These measurements must be made using the same wavelength of light as the transceiver that will be installed.) This will indicate the amount of loss per intended distance. If the loss is within the transceivers allowed power budget, the connection will work. Minimum distance requirements must be carefully considered. Alcatel-Lucent supports several alternate sources of fiber optics transceiver manufacturers for its switching and routing line of products. Alcatel-Lucent strongly recommends compliance with the original manufactures fiber optics specifications, and fiber optics design guidelines. Therefore, as a general rule, Alcatel-Lucent stays within the boundaries of the original manufacturers specifications. Any deviations from the norm require further evaluations and testing. The insertion loss parameter value for the MiniGBICs requires a very specific testing which is normally performed by the original manufacturer, but usually is not stated in their specification documents and the value may vary from one manufacturer to another. Here at Alcatel-Lucent, our engineering normally does not carry out such testing and therefore we rely on our approved manufacturer specifications data. Essentially, the original manufacturer upon request must supply this specific parameter value. It is not anywhere in their specification sheets. Here is what our Engineering suggests to do: Instead of relying on the manufacture's data for the insertion loss value, which also varies from one manufacturer to another, we suggest looking into the IEEE Standard Document. No matter what, all manufacturers must comply with the IEEE Standard. All of our MiniGBICs comply with the IEEE 802.3z. You can easily look up the insertion loss parameter and its value for our MiniGBICs in this document.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 86 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Handling Fiber and Fiber Optic Connectors

Using fiber is extremely simple, but several important standards should always be practiced. For best results, you should: Use premium grade jumper cables with duplex LC connectors Keep your fiber optic connectors clean Keep the transceiver interface clean Attenuate properly Use Premium Grade Jumper Cables with Duplex LC Connectors There are many brands of fiber optic jumper cables, with a wide range of quality between each manufacturer. Premium cables do three things well: They provide a good polish on the fiber optic connector end-face (where the light exits the cable). End-face geometries must be exceptionally precise and aligned to extremely tight tolerances. The better the endface geometry, the lower the loss and more consistent the connection. Poor connector interfaces will reflect light back into the laser, causing an increase in laser noise. They mate well with other connector interfaces. Chances are the manufacturer of the jumper cable will not be the same as the manufacturer of the transceiver connector interface. Premium jumper cables mechanically align themselves well into most transceiver interfaces. This provides both better performance as well as better repeatability. You will always see a variance in transceiver power due to connector alignment, often as much as 0.3 to 0.7 dB. Good jumper cables help reduce this variance. They continue to mate well after many insertions and removals. Premium grade jumper use premium connectors that maintain their mechanical integrity up to and beyond 2000 insertion cycles For better repeatability, always use duplex (two connectors fused together and terminated to two cables) LC connectors on your jumper cables when connecting to a fiber-optic transceiver. Two simplex connectors inserted into a transceiver interface will often have up to 3 dB greater variations in repeatability compared to duplex connectors. Never bend the fiber optic cable beyond its recommended minimum bend radius. This introduces bend losses and reflections that will degrade the performance of your system. It can also damage the fiber, although fiber is much tougher than most would assume. Still, it is highly recommended to buy only jumper cables with 3mm Kevlar jacketing, which offer superior protection and longer life. Keep Your Fiber Optic Connectors Clean Unlike electrical connectors, fiber-optic connectors must be extremely clean in order to ensure optimum system performance. Microscopic particles such as dust on the connector end-face (i.e., where the light exits the connector) can degrade the performance of your system, often to the point of failure. If you have low-power output from a fiber-optic transceiver or a fault signal from your equipment, begin the troubleshooting process by cleaning your fiber-optic connectors per manufacturer recommendations. Keep the Transceiver Interface Clean If you have cleaned your connectors, but still experience low-power output from a fiber-optic transceiver or a fault signal from your equipment, you should clean the transceiver interface by blowing inert dusting gas inside the transceiver interface. This removes dust and other small particles that may block the optical path between the optics of the transceiver and the connectors end-face. Attenuate Properly Often, equipment using laser-based transceivers need to have the optical path attenuated when performing loop-back testing or testing between two pieces of equipment. Too much optical power launched into the receiver will cause saturation and result in system failure. If you are using single mode fiber and you do not know the power output of the laser, it is always best to use a 10 dB attenuator when testing. Using the wrong type of attenuator will introduce problems, most notably reflection of light back into the laser, often resulting in excess noise and causing system failure. Inline attenuators eliminate the need for additional jumper cables and thus reduce the number of connection interfaces. This increases the integrity of the optical path resulting in a more accurate test. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 87 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

SFP MSA Specifications SFP-MSA Connector: The SFP connector consists of a 20-pin receptacle and a SFP housing cage. The 20-pin connector provides the interface for the hot Pluggable SFP module. Each SFP module contains a serial interface to provide identification information that describes the SFP capabilities, standard interfaces, manufacturer and other information. LC Connector: The LC connector is a fiber-optic cable connector that uses one-half the size of current industry standards. It increases panel density and provides duplex connection in 50% less space with duplex fits of RJ-45 footprint. It is available in SM, MM versions with Super, Ultra and Angle (APC) polishing. It provides a user-friendly audible latch to indicate proper mating and supports pull proof.

Notes:

*The worst-case Optical Power Budget in dB for a fiber optic link is determined by: The difference between the minimum transmitters output optical power and the lowest receiver sensitivity. Alcatel-Lucent switching & routing platforms support alternate sources of fiber-optics vendors, which are subject to change from time to time. Please be sure to contact Alcatel-Lucent Internetworking Product Marketing for a complete list of approved vendors. The following fiber optics transceivers specifications have been taken from Alcatel-Lucent IP Networking approved vendors original Specification Sheets. SFP-GIG-SX Technical Specifications Features Dual data-rate of 1.25Gbps/1.0625Gbps operation 850nm VCSEL laser and PIN photo detector 550m transmission with 50/125m MMF 275m transmission with 62.5/125m MMF Standard serial ID information Compatible with SFP MSA SFP MSA package with duplex LC connector With Spring-Latch for high density application Very low EMI and excellent ESD protection +3.3V single power supply Operating case temperature: 0 to +70C Connector Type The transceiver support LC connectors and are hot swappable Supports the ability to mix and match SFPs on the same unit Supports operation for layer-2, and layer-3 forwarding Standards supported IEEE 802.3z, and 1000BASE-SX (The IEEE 802.3z standard describes the specifications for the 1000BASE-X fiber optic GigE) Compatible with SFP MSA Compatible with IEEE 802.3z Compatible with ANSI specifications for Fiber Channel Compatible with FCC 47 CFR Part 15,Class B Connections supported 1000BASE-SX connections to backbone or server Fiber optic cable supported Multimode (MMF) with 62.5/125 m & 50/125 m Wavelength 850nm (typical) Transmitter Average Output Optical Power Min: -9.5 dBm and Max: -4 dBm Receiver Sensitivity Min: 0 dBm and Max: -17 dBm Power Budget* 7.5 dBm (17 9.5 = 7.5 dBm) Cable distances Supports 62.5/125 m MMF up to a maximum distance of 220 m to 300m or 50.0/125 m up to a maximum distance of 550m.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 88 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Features

Connector Type

Standards supported

Connections supported Fiber optic cable supported

Wavelength Transmitter Average Output Optical Power Receiver Sensitivity Power Budget* Cable distances

SFP-GIG-LX Technical Specifications Dual data-rate of 1.25Gbps/1.0625Gbps operation 1310nm FP laser and PIN photo detector 550m transmission with MMF 10km ~ 20km transmission with SMF Standard serial ID information compatible with SFP MSA SFP MSA package with duplex LC connector With Spring-Latch for high density application Very low EMI and excellent ESD protection +3.3V single power supply Operating case temperature: Standard: 0 to +70C Industrial: -40 to +85C The transceiver support LC connectors and are hot swappable Supports the ability to mix and match SFPs on the same unit Supports operation for layer-2, and layer-3 forwarding IEEE 802.3z, 1000BASE-LX (The IEEE 802.3z standard describes the specifications for the 1000BASE-X fiber optic Gig Eth.) Compatible with SFP MSA Compatible with IEEE 802.3z Compatible with ANSI specifications for Fiber Channel Compatible with FCC 47 CFR Part 15, Class B Compatible with FDA 21 CFR 1040.10 and 1040.11, Class I Compatible with Telcordia GR-468-CORE RoHS compliance 1000BASE-LX connections to backbone or server Single mode (SMF) with 9/125 m Note: This transceiver also supports 50/125 m & 62.5/125 m Multimode (MMF) with a maximum distance of up to 700m (typical 550m). This special mode of operation will require single-mode fiber offset-launch mode-conditioning patch cord and be sure to review the IEEE 802.3 2002 clauses 38.11.1 through 38.11.4. The third party fiber optics distance extender devices will provide the capabilities of supporting much further distances than the typical 550m. 1310nm (typical) Min: -9.5 dBm and Max: -3 dBm Min: 0 dBm and Max: -20 dBm 10.5dBm (20 9.5 = 10.5 dBm) 10km on SMF and 700m (typical 550m) on MMF

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 89 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Features

Connector Type

Standards supported

Connections supported Fiber optic cable supported Wavelength Transmitter Output Optical Power Receiver Sensitivity Power Budget* Cable distances

SFP-GIG-LH70 Technical Specifications Up to 1.25Gbps bi-directional data links 80km transmission distance with SMF 1550nm DFB laser transmitter SFP MSA package with LC optical receptacle With lever latch for high density application Single +3.3V power supply Hot-pluggable capability Low power dissipation Very low EMI and excellent ESD protection Class I laser product Monitoring interface compliant with SFF-8472 Operation case temperature: 0 to +70C The transceiver support LC connectors and are hot swappable Supports the ability to mix and match SFPs on the same unit Supports operation for layer-2, and layer-3 forwarding. IEEE 802.3z, 1000BASE-LH70 (The IEEE 802.3z standard describes the specifications for the 1000BASE-X fiber optic Gigabit Eth.) Compliant with SFP MSA Compliant with SFF 8472 Compliant with IEEE 802.3z Compliant with ANSI INCITS Fiber Channel FC-PI Rev13 Compliant with FCC 47 CFR Part 15, Class B Compliant with FDA 21 CFR 1040.10 and 1040.11, Class I 1000BASE-LH70 connections to backbone or server Single mode (SMF) with 9/125 m 1550nm (typical) Min: 0 dBm and Max: 5 dBm Min: 0 dBm and Max: -22 dBm 22 dBm (22 0 = 22 dBm) Long reach SMF 70km

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 90 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Features

Connector Type

Standards supported

Connections supported Fiber optic cable supported Wavelength Transmitter Average Output Optical Power Receiver Sensitivity Power Budget* Cable distances

SFP-GIG-LH40 Technical Specifications Dual data-rate of 1.25Gbps/1.0625Gbps 40km transmission distance with 9/125 m SMF 1310nm uncooled DFB laser PIN photodiode receiver Class I laser product Digital diagnostic monitor interface Compatible with SFF-8472 SFP MSA package with duplex LC receptacle With lever latch for high density application Very low EMI and excellent ESD protection Single 3.3V power supply Operating case temperature: 0 to +70C The transceiver support LC connectors and are hot swappable Supports the ability to mix and match SFPs on the same unit Supports operation for layer-2, and layer-3 forwarding IEEE 802.3z, 1000BASE-LH40 Compatible with SFP MSA Compatible with SFF-8472 Compatible with IEEE 802.3z Compatible with IEEE 802.3ah Compatible with ANSI INCITS Fiber Channel FC-PI Rev13 Compatible with FCC 47 CFR Part 15, Class B Compatible with FDA 21 CFR 1040.10 and 1040.11, Class I RoHS compliant 1000BASE-LH40 connections to backbone or server Single mode (SMF) 1310nm (typical) Min: -2 dBm and Max: 3 dBm Min: 0 dBm and Max: -22 dBm 20 dBm ( 22 2 = 20 dBm) Long reach SMF 40km

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 91 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Overview

Features

Function Connector Type Standards supported Connections supported Fiber optic cable supported Wavelength Transmitter Output Optical Power Receiver Sensitivity Power Budget* Cable distances

SFP-GIG-EXTND Technical Specifications The Fiber Driver SFP Multimode Extender increases the reach of Gigabit Ethernet and Fiber Channel data links to distances that far exceed the defined standard. This technology allows multimode (MM) fiber previously used for FDDI, Fast Ethernet and other legacy protocols to now be used for creating high-speed communication backbones. Since first appearing in the Fiber Driver Gigabit Multimode Extender module, the performance and reliability of the Multimode Extender (MMX) technology has been proven in installations throughout the world. Typically, Gigabit Ethernet and Fiber Channel transmissions distances over MM fiber are limited to 550 meters or less, far shorter than the 2-kilometer standard for when multimode fiber is used to transmit FDDI or Fast Ethernet. This fact has left IT managers needing to implement gigabit-speed protocols with little choice but to abandon their existing multimode fiber plant and install new single mode fiber. Extended 1000Base-SX Gigabit Ethernet optical transceiver (SFP MSA). Supports multimode fiber over 850nm wavelength (nominal) with an LC connector. Reach of up to 2 km (based on grade and condition of fiber) on 62.5/125 m MMF or 550m on 50.0/125 m MMF. Requires SFP-GIG-EXTND or GBIC-GIG-EXTND at the remote termination. Supply Voltage: 3.3V Transmits Gigabit Ethernet (IEEE 802.3) or Fiber Channel (ANSI X3.230-1994) up to 4 km (2 km guaranteed. Maximum range depends upon grade and condition of fiber plant used) over 62.5m and 50m dual fiber multimode links SFP MSA SFF-8074i compliant Bellcore GR-468 compliant Multimode DSC adapter Plug-n-play, hot swappable functionality Low EMI metal enclosure Operating temperature: 0 to +70C SFP Extended Multimode 7 SFP Extended Multimode with ROHS Compliance LC IEEE 802.3z 1000BASE-SX connections to backbone or server Multimode (MMF) 850nm (typical) Min: N/A and Max: N/A Min: N/A and Max: N/A N/A 2km on 62.5/125 m MMF or 550m on 50.0/125 m MMF

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 92 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Features

Connector Type Standards supported Connections supported Copper Cables supported Cable distances Features

Connector Type

Standards supported

Connections supported Fiber optic cable supported Wavelength Transmitter Average Output Optical Power Receiver Sensitivity Power Budget* Transmitter Average Output Optical Power Receiver Sensitivity Power Budget* Cable distances SFP compatibility notes

SFP-GIG-T Technical Specifications Up to 1.25Gb/s bi-directional data links Hot-pluggable SFP footprint Extended case temperature range (0C to +85C ) Fully metallic enclosure for low EMI Low power dissipation (1.2 W typical) Compact RJ-45 connector assembly Access to physical layer IC via 2-wire serial bus 10/100/1000 BASE-T operation in host systems with SGMII interface RJ-45 IEEE 802.3z, and 1000BASE-T 1000BASE-T connections to backbone or server CAT5, CAT5e, and CAT6 100m at 1000Mbps and full-duplex mode SFP-DUAL-MM Technical Specifications Build-in PHY supporting SGMII Interface Dual data-rate of 100BASE-FX/1000BASE-LX operation 1310nm FP laser and PIN photo-detector 0.5m~2km transmission with MMF at 125Mbps 0.5m~550m transmission with MMF at 1.25Gbps Standard serial ID information compliable with SFP MSA SFP MSA package with duplex LC connector With Spring-Latch for high density application Very low EMI and excellent ESD protection +3.3V single power supply Operating case temperature: 0 to +70C The transceiver support LC connectors and are hot swappable Supports the ability to mix and match SFPs on the same unit Supports operation for layer-2, and layer-3 forwarding 802.3z, and 100BASE-FX Compliable with SFP MSA Compliable with IEEE 802.3-2002 Compliable with IEEE 802.3ah-2004 Compliable with FCC 47 CFR Part 15, Class B Compliable with FDA 21 CFR 1040.10 and 1040.11, Class I Compliable with Telcordia GR-468-CORE RoHS compliance 1000BASE-LX or 100BASE-FX connections to backbone or server Multimode (MMF) 1310nm (typical) 1000BASE-LX Min: -11.5 dBm and Max: -3 dBm Min: 0 and Max: -22 dBm 10.5 dBm ( 22 11.5 = 10.5 dBm) 100BASE-FX Min: -20.0 dBm and Max: -14.0 dBm Min: 0 and Max: -28 dBm 8 dBm ( 28 20 = 8 dBm) 550m at 1000Mbps and 2km at 100Mbps This SFP is not supported on OmniSwitch 6850 combo ports with the exception of the OmniSwitch 6850-U24X combo ports.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 93 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Features

Connector Type

Standards supported

Connections supported Fiber optic cable supported Wavelength Transmitter Average Output Optical Power Receiver Sensitivity Power Budget* Transmitter Average Output Optical Power Receiver Sensitivity Power Budget* Cable distances SFP compatibility notes

SFP-DUAL-SM10 Technical Specifications Build-in PHY supporting SGMII Interface Dual data-rate of 100BASE-LX/1000BASE-LX operation 1310nm FP laser and PIN photo-detector 0.5m~10km transmission with SMF Standard serial ID information compliable with SFP MSA SFP MSA package with duplex LC connector With Spring-Latch for high density application Very low EMI and excellent ESD protection +3.3V single power supply Operating case temperature: 0 to +70C The transceiver support LC connectors and are hot swappable Supports the ability to mix and match SFPs on the same unit Supports operation for layer-2, and layer-3 forwarding IEEE 802.3z, 100BASE-FX, and 1000BASE-X Compliable with SFP MSA Compliable with IEEE 802.3-2002 Compliable with IEEE 802.3ah-2004 Compliable with FCC 47 CFR Part 15, Class B Compliable with FDA 21 CFR 1040.10 and 1040.11, Class I Compliable with Telcordia GR-468-CORE RoHS compliance 100BASE-LX or 1000BASE-X connections to backbone or server Single mode (SMF) 1310nm (typical) 1000BASE-LX Min: -9.5 dBm and Max: -3 dBm Min: 0 and Max: -22 dBm 12.5 dBm ( 22 9.5 = 12.5 dBm) 100BASE-LX Min: -15 dBm and Max: -8 dBm Min: 0 and Max: -28 dBm 13 dBm ( 28 15 = 13 dBm) 0.5m ~ 10km transmission with SMF This SFP is not supported on OmniSwitch 6850 combo ports with the exception of the OmniSwitch 6850-U24X combo ports.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 94 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Features

Connector Type

Standards supported

Connections supported Fiber optic cable supported Wavelength Transmitter Output Optical Power Receiver Sensitivity Power Budget* Cable distances SFP compatibility notes

Features

Connector Type

Standards supported

Connections supported Fiber optic cable supported Wavelength Transmitter Average Output Optical Power Receiver Sensitivity Power Budget* Cable distances SFP compatibility notes

SFP-100-BX20LT Technical Specifications 1310nm/1550nm single fiber bi-directional transmission technology SFP Multi-Source package with SC receptacle 100~155.520Mbps data links Very low EMI and certified ESD Protection Class I laser product Single +3.3V power supply Hot-pluggable capability Low power dissipation Industrial operating temperature -40C to +85C The transceiver support SC connectors and are hot swappable Supports the ability to mix and match SFPs on the same unit Supports bi-directional operation for layer-2, and layer-3 forwarding 802.3z, and 1000BASE-BX Compliant With Industrial Standard SFP MSA Compliant With ITU-T G.985 Compliant With FCC 47 CFR Part 15, Class B Compliant With FDA 21 CFR 1040.10 and 1040.11, Class I 1000BASE-BX connections to backbone or server Single Mode (SMF) 1310/1550nm (typical) Min: -14 dBm and Max: -8 dBm Min: 0 and Max: -32 dBm 18 dBm ( 32 14 = 18 dBm) 20km This SFP is not supported on OmniSwitch 6850 combo ports with the exception of the OmniSwitch 6850-U24X combo ports. SFP-100-BX20NU Technical Specifications 100~155Mbps data links 20km point-point transmission 1310nm FP Tx/1550nm 1550nm FP Tx/1310nm Class I laser product Low EMI and excellent ESD protection SFP MSA package with SC receptacle Operation case temperature:-40 to +85C The transceiver support SC connectors and are hot swappable Supports the ability to mix and match SFPs on the same unit Supports bi-directional operation for layer-2, and layer-3 forwarding IEEE 802.3z, and 1000BASE-BX Compatible with SFP MSA Compatible with ITU-T G.983 Compatible with IEEE 802.3ah Compliant with RoHS 1000BASE-BX connections to backbone or server Single mode (SMF) 1310nm/1550nm (typical) Min: -14 dBm and Max: -8 dBm Min: 0 and Max: -32 dBm 18 dBm ( 32 14 = 18 dBm) 20km This SFP is not supported on OmniSwitch 6850 combo ports with the exception of the OmniSwitch 6850-U24X combo ports.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 95 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Features

Connector Type

Standards supported Connections supported Fiber optic cable supported Wavelength Transmitter Output Optical Power for 62.5/125m Transmitter Output Optical Power for 50/125m Receiver Input Optical Power Power Budgets* Cable distances SFP compatibility notes

SFP-100-LC-MM Technical Specifications Full compliance with ATM Forum UNI SONET OC-3 multimode fiber physical layer specification Full compliance with the optical performance requirements of the FDDI PMD Standard Full compliance with the optical performance requirements of 100Base-FX version of IEEE802.3u Industry standard Small Form Pluggable (SFP) package LC duplex connector optical interface Operates with 62.5/125m and 50/125m multimode fiber Single +3.3 V power supply +3.3 V TTL LOS output Manufactured in an ISO 9001 certified facility Temperature range: 0 C to +70 C Bail de-latch option The transceiver support LC connectors and are hot swappable Supports the ability to mix and match SFPs on the same unit Supports operation for layer-2, and layer-3 forwarding IEEE 802.3z, and 100BASE-FX 100BASE-FX connections to backbone or server Multimode (MMF) 1310nm (typical) Min: -20 dBm and Max: -14 dBm Min: -23.5 dBm and Max: -14 dBm Min: -14 and Max: -31 dBm 11 dBm ( 31 20 = 11 dBm) for 62.5/125m 7.5 dBm ( 31 23.5 = 7.5 dBm for 50/125m 2km This SFP is not supported on OmniSwitch 6850 combo ports with the exception of the OmniSwitch 6850-U24X combo ports.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 96 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Features

Connector Type

Standards supported

Connections supported Fiber optic cable supported Wavelength Transmitter Average Output Optical Power Receiver Sensitivity Power Budget* Cable distances SFP compatibility notes

SFP-100-LC-SM15 Technical Specifications 100~155.52Mbps bi-directional data links 1310nm FP laser transmitter Multi-source package with LC optical interface Optional spring latch for high density application Class 1 laser product Very low jitter 15km transmission distance with SMF Low EMI and excellent ESD protection Single +3.3V power supply Hot-pluggable capability Temperature range: 0 C to +70 C The transceiver support LC connectors and are hot swappable Supports the ability to mix and match SFPs on the same unit Supports operation for layer-2, and layer-3 forwarding IEEE 802.3z, and 100BASE-FX Compliant with SFP MSA Compliant with FCC 47 CFR Part 15, Class B Compliant with FDA 21 CFR 1040.10 and 1040.11, Class I Compliant with ITU-T G.957 and G.958 Compliant with Telcordia GR-253-CORE 100BASE-FX connections to backbone or server Single mode (SMF) 1310nm (typical) Min: -15 dBm and Max: -8 dBm Min: 0 and Max: -36 dBm 21 dBm ( 36 15 = 21 dBm) 15km This SFP is not supported on OmniSwitch 6850 combo ports with the exception of the OmniSwitch 6850-U24X combo ports. SFP-100-LC-SM40 Technical Specifications 100~155.52Mbps bi-directional data links 1310nm FP laser transmitter Multi-source package with LC optical interface Optional spring latch for high density application Class 1 laser product Very low jitter 40km transmission distance with SMF Low EMI and excellent ESD protection Single +3.3V power supply Hot-pluggable capability Temperature range: 0 C to +70 C The transceiver support LC connectors and are hot swappable Supports the ability to mix and match SFPs on the same unit Supports operation for layer-2, and layer-3 forwarding IEEE 802.3z, and 100BASE-FX Compliant with SFP MSA Compliant with FCC 47 CFR Part 15, Class B Compliant with FDA 21 CFR 1040.10 and 1040.11, Class I Compliant with ITU-T G.957 and G.958 Compliant with Telcordia GR-253-CORE 100BASE-FX connections to backbone or server Single mode (SMF) 1310nm (typical) Min: -5 dBm and Max: 0 dBm Min: 0 and Max: -36 dBm 31 dBm ( 36 5 = 31 dBm) 40km This SFP is not supported on OmniSwitch 6850 combo ports with the exception of the OmniSwitch 6850-U24X combo ports.

Features

Connector Type

Standards supported

Connections supported Fiber optic cable supported Wavelength Transmitter Average Output Optical Power Receiver Sensitivity Power Budget* Cable distances SFP compatibility notes

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 97 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Coarse Wave Division Multiplexing (CWDM)

Coarse Wave Division Multiplexing (CWDM) is an optical transceiver supporting single-mode fiber over 1470nm to 1590 nm (typical) wavelengths for use with OmniSwitch 6850 Series switches. It supports IEEE 802.3z and 1000Base-LX standards. It also supports 1000Base-CWDM connection to backbone or server. CWDMs are hot-pluggable and are available for long-reach applications; the single-mode fiber cable can reach up to 62 km.
Latch Color Gray Violet Blue Green Yellow Orange Red Brown Features Nominal Wavelength Optical Link Power Budget Distance 1471nm 22dBm min. Up to 62km 1491nm 22dBm min. Up to 62km 1511nm 22dBm min. Up to 62km 1531nm 22dBm min. Up to 62km 1551nm 22dBm min. Up to 62km 1571nm 22dBm min. Up to 62km 1591nm 22dBm min. Up to 62km 1611nm 22dBm min. Up to 62km SFP-GIG-47CWD60 Technical Specifications Eight (8) Wavelength CWDM Transceivers Compliant with SFP MSA Compatible with IEEE 802.3z Gigabit Ethernet 1000BASE-LX PMD Specifications Compatible with 1.062GBd Fiber Channel 100-SM-LC-L FC-PI Standards Minimum Optical Link Power Budgets of 22dB and 24dB to support 62km and 70km Eye Safe (Class I Laser Safety per FDA/CDRH & Class 1M per IEC-825) Duplex LC Optical Interface Loss of Signal Output & TX Disable Input Hot-pluggable Single +3.3V Power Supply CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ gray latch. Supports single mode fiber over 1471nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. The transceiver support LC connectors and are hot swappable Supports the ability to mix and match CWDMs on the same unit Supports operation for layer-2, and layer-3 forwarding IEEE 802.3z, and 1000BASE-LX 1000BASE-CWDM connections to backbone or server Single mode (SMF) & 9/125 m 1471nm (nominal) Min: -2 dBm and Max: +3 dBm Min: -24 and Max: -3 dBm 22 dBm ( 24 2 = 22 dBm) Long reach single mode (SMF) 62km SFP-GIG-49CWD60 Technical Specifications Eight (8) Wavelength CWDM Transceivers Compliant with SFP MSA Compatible with IEEE 802.3z Gigabit Ethernet 1000BASE-LX PMD Specifications Compatible with 1.062GBd Fiber Channel 100-SM-LC-L FC-PI Standards Minimum Optical Link Power Budgets of 22dB and 24dB to support 62km and 70km Eye Safe (Class I Laser Safety per FDA/CDRH & Class 1M per IEC-825) Duplex LC Optical Interface Loss of Signal Output & TX Disable Input Hot-pluggable Single +3.3V Power Supply CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ violet latch. Supports single mode fiber over 1491nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. The transceiver support LC connectors and are hot swappable Supports the ability to mix and match CWDMs on the same unit Supports operation for layer-2, and layer-3 forwarding IEEE 802.3z, and 1000BASE-LX 1000BASE-CWDM connections to backbone or server Single mode (SMF) & 9/125 m 1491nm (nominal) Min: -2 dBm and Max: +3 dBm Min: -24 and Max: -3 dBm 22 dBm ( 24 2 = 22 dBm) Long reach single mode (SMF) 62km

Connector Type

Standards supported Connections supported Fiber optic cable supported Wavelength Transmitter Output Optical Power Input Optical Power Power Budget* Cable distances Features

Connector Type

Standards supported Connections supported Fiber optic cable supported Wavelength Transmitter Output Optical Power Input Optical Power Power Budget* Cable distances

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 98 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Features

Connector Type

Standards supported Connections supported Fiber optic cable supported Wavelength Transmitter Output Optical Power Input Optical Power Power Budget* Cable distances Features

Connector Type

Standards supported Connections supported Fiber optic cable supported Wavelength Transmitter Output Optical Power Input Optical Power Power Budget* Cable distances

SFP-GIG-51CWD60 Technical Specifications Eight (8) Wavelength CWDM Transceivers Compliant with SFP MSA Compatible with IEEE 802.3z Gigabit Ethernet 1000BASE-LX PMD Specifications Compatible with 1.062GBd Fiber Channel 100-SM-LC-L FC-PI Standards Minimum Optical Link Power Budgets of 22dB and 24dB to support 62km and 70km Eye Safe (Class I Laser Safety per FDA/CDRH & Class 1M per IEC-825) Duplex LC Optical Interface Loss of Signal Output & TX Disable Input Hot-pluggable Single +3.3V Power Supply CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ blue latch. Supports single mode fiber over 1511nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. The transceiver support LC connectors and are hot swappable Supports the ability to mix and match CWDMs on the same unit Supports operation for layer-2, and layer-3 forwarding IEEE 802.3z, and 1000BASE-LX 1000BASE-CWDM connections to backbone or server Single mode (SMF) & 9/125 m 1511nm (nominal) Min: -2 dBm and Max: +3 dBm Min: -24 and Max: -3 dBm 22 dBm ( 24 2 = 22 dBm) Long reach single mode (SMF) 62km SFP-GIG-53CWD60 Technical Specifications Eight (8) Wavelength CWDM Transceivers Compliant with SFP MSA Compatible with IEEE 802.3z Gigabit Ethernet 1000BASE-LX PMD Specifications Compatible with 1.062GBd Fiber Channel 100-SM-LC-L FC-PI Standards Minimum Optical Link Power Budgets of 22dB and 24dB to support 62km and 70km Eye Safe (Class I Laser Safety per FDA/CDRH & Class 1M per IEC-825) Duplex LC Optical Interface Loss of Signal Output & TX Disable Input Hot-pluggable Single +3.3V Power Supply CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ green latch. Supports single mode fiber over 1531nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. The transceiver support LC connectors and are hot swappable Supports the ability to mix and match CWDMs on the same unit Supports operation for layer-2, and layer-3 forwarding IEEE 802.3z, and 1000BASE-LX 1000BASE-CWDM connections to backbone or server Single mode (SMF) & 9/125 m 1531nm (nominal) Min: -2 dBm and Max: +3 dBm Min: -24 and Max: -3 dBm 22 dBm ( 24 2 = 22 dBm) Long reach single mode (SMF) 62km

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 99 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Features

Connector Type

Standards supported Connections supported Fiber optic cable supported Wavelength Transmitter Output Optical Power Input Optical Power Power Budget* Cable distances Features

Connector Type

Standards supported Connections supported Fiber optic cable supported Wavelength Transmitter Output Optical Power Input Optical Power Power Budget* Cable distances

SFP-GIG-55CWD60 Technical Specifications Eight (8) Wavelength CWDM Transceivers Compliant with SFP MSA Compatible with IEEE 802.3z Gigabit Ethernet 1000BASE-LX PMD Specifications Compatible with 1.062GBd Fiber Channel 100-SM-LC-L FC-PI Standards Minimum Optical Link Power Budgets of 22dB and 24dB to support 62km and 70km Eye Safe (Class I Laser Safety per FDA/CDRH & Class 1M per IEC-825) Duplex LC Optical Interface Loss of Signal Output & TX Disable Input Hot-pluggable Single +3.3V Power Supply CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ yellow latch. Supports single mode fiber over 1551nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. The transceiver support LC connectors and are hot swappable Supports the ability to mix and match CWDMs on the same unit Supports operation for layer-2, and layer-3 forwarding IEEE 802.3z, and 1000BASE-LX 1000BASE-CWDM connections to backbone or server Single mode (SMF) & 9/125 m 1551nm (nominal) Min: -2 dBm and Max: +3 dBm Min: -24 and Max: -3 dBm 22 dBm ( 24 2 = 22 dBm) Long reach single mode (SMF) 62km SFP-GIG-57CWD60 Technical Specifications Eight (8) Wavelength CWDM Transceivers Compliant with SFP MSA Compatible with IEEE 802.3z Gigabit Ethernet 1000BASE-LX PMD Specifications Compatible with 1.062GBd Fiber Channel 100-SM-LC-L FC-PI Standards Minimum Optical Link Power Budgets of 22dB and 24dB to support 62km and 70km Eye Safe (Class I Laser Safety per FDA/CDRH & Class 1M per IEC-825) Duplex LC Optical Interface Loss of Signal Output & TX Disable Input Hot-pluggable Single +3.3V Power Supply CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ orange latch. Supports single mode fiber over 1571nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. The transceiver support LC connectors and are hot swappable Supports the ability to mix and match CWDMs on the same unit Supports operation for layer-2, and layer-3 forwarding IEEE 802.3z, and 1000BASE-LX 1000BASE-CWDM connections to backbone or server Single mode (SMF) & 9/125 m 1571nm (nominal) Min: -2 dBm and Max: +3 dBm Min: -24 and Max: -3 dBm 22 dBm ( 24 2 = 22 dBm) Long reach single mode (SMF) 62km

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 100 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Features

Connector Type

Standards supported Connections supported Fiber optic cable supported Wavelength Transmitter Output Optical Power Input Optical Power Power Budget* Cable distances Features

Connector Type

Standards supported Connections supported Fiber optic cable supported Wavelength Transmitter Output Optical Power Input Optical Power Power Budget* Cable distances

SFP-GIG-59CWD60 Technical Specifications Eight (8) Wavelength CWDM Transceivers Compliant with SFP MSA Compatible with IEEE 802.3z Gigabit Ethernet 1000BASE-LX PMD Specifications Compatible with 1.062GBd Fiber Channel 100-SM-LC-L FC-PI Standards Minimum Optical Link Power Budgets of 22dB and 24dB to support 62km and 70km Eye Safe (Class I Laser Safety per FDA/CDRH & Class 1M per IEC-825) Duplex LC Optical Interface Loss of Signal Output & TX Disable Input Hot-pluggable Single +3.3V Power Supply CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ red latch. Supports single mode fiber over 1591nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. The transceiver support LC connectors and are hot swappable Supports the ability to mix and match CWDMs on the same unit Supports operation for layer-2, and layer-3 forwarding IEEE 802.3z, and 1000BASE-LX 1000BASE-CWDM connections to backbone or server Single mode (SMF) & 9/125 m 1591nm (nominal) Min: -2 dBm and Max: +3 dBm Min: -24 and Max: -3 dBm 22 dBm ( 24 2 = 22 dBm) Long reach single mode (SMF) 62km SFP-GIG-61CWD60 Technical Specifications Eight (8) Wavelength CWDM Transceivers Compliant with SFP MSA Compatible with IEEE 802.3z Gigabit Ethernet 1000BASE-LX PMD Specifications Compatible with 1.062GBd Fiber Channel 100-SM-LC-L FC-PI Standards Minimum Optical Link Power Budgets of 22dB and 24dB to support 62km and 70km Eye Safe (Class I Laser Safety per FDA/CDRH & Class 1M per IEC-825) Duplex LC Optical Interface Loss of Signal Output & TX Disable Input Hot-pluggable Single +3.3V Power Supply CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ brown latch. Supports single mode fiber over 1611nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125 m SMF. The transceiver support LC connectors and are hot swappable Supports the ability to mix and match CWDMs on the same unit Supports operation for layer-2, and layer-3 forwarding IEEE 802.3z, and 1000BASE-LX 1000BASE-CWDM connections to backbone or server Single mode (SMF) & 9/125 m 1611nm (nominal) Min: -2 dBm and Max: +3 dBm Min: -24 and Max: -3 dBm 22 dBm ( 24 2 = 22 dBm) Long reach single mode (SMF) 62km

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 101 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

10Gbps Small Form Factor Pluggable (XFPs)

10Gbps Small Form Factor Pluggable (XFPs) are fiber-based optical transceivers. XFPs are fully hot-swappable and are available for both short-reach and long-reach applications. The following XFP types are available: The XFP-10G-LR is a long-reach 10-gigabit optical transceiver that supports single mode fiber over 1310 nm wavelengths. It also supports 10 micron fiber up to a maximum distance of 10km. The XFP-10G-SR is a short-reach 10-gigabit optical transceiver that supports multimode fiber over 850 nm wavelengths. It also supports 50/62.5 micron fiber up to a max distance of 300m (depending on the grade of fiber used). The XFP-10G-ER40 is a long-reach 10-gigabit optical transceiver that supports single-mode fiber over 1550 nm wavelengths. It also supports 10 micron fiber up to a max distance of 40km. The XFP-10G-ZR80 is a long-reach 10-gigabit optical transceiver that supports single-mode fiber over 1550 nm wavelengths. It also supports 10 micron fiber up to a max distance of 80km (depending on the grade of fiber used).

Eye Safety
XFP transceivers are international Class 1 laser products and are eye-safe devices when operated within the limits of manufacturers specifications. Operating XFP transceivers in a manner inconsistent with intended usage and specification might result in hazardous radiation exposure.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 102 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

XFP-10G Specifications
XFP-10G-LR Technical Specifications Compact form factor according to 10 Gigabit Small Form Factor Pluggable (XFP) Multi Source Agreement, Release 3.1 Multiple rate and multiple protocol support SMF: 10GE / 10GFC / SONET / SDH MMF: 10GE / 10GFC XFP MSA compliant management and diagnostic interface Z-Axis hot-plug capability XFI serial data Interface via 30-Pin, XFP connector Support link spans up to 10km with single mode fiber and 300m with multimode fiber IEEE 802.3ae 2002 compliant 10GBASE-LR and 10GBASE-SR 10GFC draft 3.0 compliant 1200-SM-LL-L and 1200-MX-SN-I OC-192 SR-1/STM I64.1 Standards Supported IEEE 802.3ae & 10GBASE-LR Connector Type The transceiver support LC connectors and are hot swappable Supports the ability to mix and match XFPs on the same unit Supports operation for layer-2, and layer-3 forwarding Cable Supported Single mode; Full Duplex only Source Type Supports 10 m & 1310nm with a serial transceiver Cable Distances up to 10km Power Consumption 2.5watts Operating Temperature -5 to 70C Transmitter Average Output (launch) optical power Min: -5.2dBm & Max: 0.5dBm Receiver Sensitivity Min: -12.6dBm & Max: 0dBm Power Budget* 7.4dBm (12.6 5.2 = 7.4dBm) XFP-10G-SR Technical Specifications Features Compact form factor according to 10 Gigabit Small Form Factor Pluggable (XFP) Multi Source Agreement, Release 3.1 Multiple rate and multiple protocol support SMF: 10GE / 10GFC / SONET / SDH MMF: 10GE / 10GFC XFP MSA compliant management and diagnostic interface Z-Axis hot-plug capability XFI serial data Interface via 30-Pin, XFP connector Support link spans up to 10km with single mode fiber and 300m with multimode fiber IEEE 802.3ae 2002 compliant 10GBASE-LR and 10GBASE-SR 10GFC draft 3.0 compliant 1200-SM-LL-L and 1200-MX-SN-I OC-192 SR-1/STM I64.1 Standards Supported IEEE 802.3ae & 10GBASE-SR Connector Type The transceiver support LC connectors and are hot swappable Supports the ability to mix and match XFPs on the same unit Supports operation for layer-2, and layer-3 forwarding Cable Supported Multi mode; Full Duplex only Source Type Supports 50/125 m & 62.5/125 m & 850nm with a serial transceiver Cable Distances up to 300m (based on 50/125 m MMF and a Modal bandwidth of 2000MHz*km) Power Consumption 2.5watts Operating Temperature -5 to 70C Transmitter Average Output (launch) optical power Min: -7.3dBm & Max: -1.0dBm Receiver Sensitivity Min: 0dBm & Max: -11.1dBm Power Budget* 3.8dBm (11.1 7.3 = 3.8dBm) Features

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 103 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

XFP-10G-ER40 Technical Specifications Supports 9.95Gb/s to 10.7Gb/s bit rates Hot-pluggable XFP footprint Maximum link length of 40km Temperature-stabilized EML transmitter Duplex LC connector Power dissipation <3.5W Built-in digital diagnostic functions Temperature range: -5C to 70C Standards Supported IEEE 802.3ae & 10GBASE-ER Connector Type The transceiver support LC connectors and are hot swappable Supports the ability to mix and match XFPs on the same unit Supports operation for layer-2, and layer-3 forwarding Cable Supported Single mode; Full Duplex only Source Type supports 10 m & 1550nm Cable Distances up to 40km Power Consumption 3.5watts Operating Temperature -5 to 70C Transmitter Average Output (launch) optical power Min: -1.0dBm& Max: +2.0dBm Receiver Sensitivity @9.95Gbps to 11.1Gbps Min: 0dBm & Max: -16dBm Power Budget* 15dBm (16 1.0 = 15dBm) XFP-10G-ZR80 Technical Specifications Features Supports 9.95Gb/s to 10.7Gb/s bit rates Hot-pluggable XFP footprint Maximum link length of 80km Temperature-stabilized EML transmitter Duplex LC connector Power dissipation <3.5W Built-in digital diagnostic functions Temperature range: -5C to 70C Standards Supported IEEE 802.3ae & 10GBASE-ZR Connector Type The transceiver support LC connectors and are hot swappable Supports the ability to mix and match XFPs on the same unit Supports operation for layer-2, and layer-3 forwarding Cable Supported Single Mode; Full Duplex only Source Type Supports 10 m & 1550nm Cable Distances up to 80km Power Consumption 3.5 watts Operating Temperature -5 to 70C Transmitter Average Output (launch) optical power Min: 0dBm & Max: +4.0dBm Receiver Sensitivity @9.95Gbps Min: 0dBm & Max: -24dBm Power Budget* 24dBm (24 0 = 24dBm) Features

Notes: *The worst-case Optical Power Budget in dB for a fiber optic link is determined by: The difference between the minimum transmitters output optical power and the lowest receiver sensitivity.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 104 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Pin-Outs
RJ-45 Console Port Connector Pinouts
Pin Number 1 2 3 4 5 6 7 8 Shell Description (Signals as DCE Console Port) CTS NC RXD Ground Ground TXD NC RTS (Request to Send) Chassis Ground

RJ-45 Console Port Connector Pinouts

Pin Number 1 2 3 4 5 6 7&8 Shell Description (Signals as DTE Console Port) NC NC RXD Ground Ground TXD NC Chassis Ground

10/100Mbps Ethernet Port RJ-45 Pinouts (Non-PoE)

Pin Number 1 2 3 4 5 6 7&8 Description RX+ RXTX+ Not used Not used TXNot used

Power over Ethernet Port RJ-45 Pinouts (with PoE)

Pin Number 1 2 3 4&5 6 7&8 Description RX+ (-VDC) RX- (-VDC) TX+ (+VDC) ----TX- (+VDC) -----

1 Gigabit Ethernet Port RJ-45 Pinouts (Non-PoE)

Pin Number 1 2 3 4 5 6 7 8 Description BI_DB+ BI_DBBI_DA+ BI_DD+ BI_DDBI_DABI_DC+ BI_DC-

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 105 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

10/100/1000Mbps Power over Ethernet Port -RJ-45 Pinouts

Pin Number 1 2 3 4 5 6 7 8 Description RX+ (-VDC) RX- (-VDC) TX+ (+VDC) N/C N/C TX- (+VDC) N/C N/C

Console Port / Serial Connection Default Settings

The console port, located on the chassis front panel, provides a console connection to the switch and is required when logging into the switch for the first time. By default, this RJ-45 connector provides a DTE console connection. The factory default settings for the serial connections are as follows: Baud rate Parity Data bits (word size) Stop bits Flow Control 9600 None 8 1 None

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 106 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 DB-25 POWER CONNECTOR PIN-OUT

PIN 1 PIN 13

PIN 14
Pin Number Description OS6850 PoE Models 1 -50V 2 -50V 3 -50VRTN 4 -50VRTN 5 N/C 6 +12V 7 +12V 8 +12V 9 GND 10 GND 11 PS_ALTER 12 PS_GOOD 13 PS_PRESENT 14 -50V 15 -50V 16 -50VRTN 17 -50VRTN 18 N/C 19 +12V 20 +12V 21 GND 22 GND 23 GND 24 PS_TYPE0 25 PS_TYPE1

PIN 25
Pin Number Description OS6850 Non-PoE Models 1 N/C 2 N/C 3 N/C 4 N/C 5 N/C 6 +12V 7 +12V 8 +12V 9 GND 10 GND 11 PS_ALTER 12 PS_GOOD 13 PS_PRESENT 14 N/C 15 N/C 16 N/C 17 N/C 18 N/C 19 +12V 20 +12V 21 GND 22 GND 23 GND 24 PS_TYPE0 25 PS_TYPE1

Note: This the pin-outs for the external power supplies DB-25 connectors as located on the rear panel of OmniSwitch 6850 platforms (as applicable). There are three DB-25 connectors. These connectors are used for connecting the appropriate power supply (s) to the OmniSwitch 6850 unit.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 107 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Availability Feature
The switch provides a broad variety of availability features. Availability features are hardware- and software-based safeguards that help to prevent the loss of data flow in the unlikely event of a subsystem failure. In addition, some availability features allow users to maintain or replace hardware components without powering off the switch or interrupting switch operations. Combined, these features provide added resiliency and help to ensure that the switch or virtual chassis is consistently available for day-to-day network operations. Hardware-related availability features include: Software Rollback Backup Power Supplies Hot Swapping Hardware Monitoring

Software Rollback
Software rollback (also referred to as image rollback) essentially allows the OmniSwitch 6850 Series switches to return to a prior last known good version of software in the event of a system software problem. The switch controls software rollback through its resilient directory structure design (i.e., /flash/ working and /flash/certified).

Backup Power Supplies

The OmniSwitch 6850 Series switches support an optional backup power supply. This power supply is connected to the rear of the unit. There is a power shelf provided with the unit that slides into the rear of the chassis and is used to hold the power supplies. It can hold 510W or 360W power supplies (for PoE Models) and 120W or 126W power supplies (Non-PoE Models). This provides redundant chassis power on a 1:1 basis. Backup power supplies operate in standby mode. If the primary power supply fails unexpectedly, the backup power supply automatically takes up the full power load without disrupting the switch.

Hot Swapping
Hot swapping refers to the action of adding, removing, or replacing components without powering off switches or disrupting other components. This feature facilitates hardware upgrades and maintenance and allows users to easily replace components in the unlikely event of hardware failure. The following hardware components can be hot swapped: Backup power supply Backup power supply connector cables SFPs

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 108 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Hardware Monitoring
Automatic Monitoring
Automatic monitoring refers to the switchs built-in sensors that automatically monitor operations. If an error is detected (e.g., over-threshold temperature), the switch immediately sends a trap to the user. The trap is displayed on the console in the form of a text error message. (In the case of an over-threshold temperature condition, the chassis displays an amber TMP LED in addition to sending a trap.)

LEDs
LEDs, which provide visual status information, are provided on the chassis front panel. LEDs are used to indicate conditions such as hardware and software status, temperature errors, link integrity, data flow, etc.

User-Driven Monitoring
User-driven hardware monitoring refers to CLI commands that are entered by the user in order to access the current status of hardware components. The user enters show commands that output information to the console.

Auto negotiation Guidelines

Please note a link will not be established on any copper Ethernet port if any one of the following is true: The local port advertises 100 Mbps full duplex and the remote link partner is forced to 100 Mbps full duplex. The local port advertises 100 Mbps full duplex and the remote link partner is forced to 100 Mbps half duplex. The local port advertises 10 Mbps full duplex and the remote link partner is forced to 10 Mbps full duplex. The local port advertises 10 Mbps full duplex and the remote link partner is forced to 10 half duplex. This is due to the fact that when the local device is set to auto negotiating 10/100 full duplex it senses the remote device is not auto negotiating. Therefore it resolves to Parallel Detect with Highest Common Denominator (HCD), which is 10/100 Half according to IEEE 802.3 Clause 28.2.3.1. However, since the local device is set to auto negotiating at 10/100 full duplex it cannot form a 10/100Mbps half duplex link in any of the above mentioned cases. One solution is to configure the local device to auto negotiation, 10/100 Mbps, with auto or half duplex.

Valid Port Settings on OmniSwitch 6850 Series Switches

Port Number / Type User-Specified Port Speed (Mbps) Supported Auto/10/100/1000 1000 User-Specified Duplex Supported Auto/full/half Full Auto Negotiation Supported? Yes Yes

Copper twisted pair (RJ-45) LC ports

10/100/1000 Crossover Supported

By default, automatic crossover between MDI/MDIX (Media Dependent Interface/Media Dependent Inter-face with Crossover) media is supported on OmniSwitch 6850 Series 10/100/1000Mbps (10BASE-T/100BASE-TX/1000BASE-T) ports. Therefore, either straight through or crossover cable can be used between two OmniSwitch 6850 Series switches as long as auto negotiation is configured on both sides of the link.

10/100 Crossover Supported

By default, automatic crossover between MDI/MDIX (Media Dependent Interface/Media Dependent Inter-face with Crossover) media is supported on OmniSwitch 6850 Series 10/100Mbps (10BASE-T/100BASE-TX) ports. Therefore, either straight through or crossover cable can be used between two OmniSwitch 6850 Series switches as long as auto negotiation is configured on both sides of the link. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 109 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

The OmniSwitch 6850 Series Power Supply System

OmniSwitch 6850 Series switches support the following power supplies: PS-510W power supply PS-360W power supply PS-126W power supply PS-120W-DC power supply Approximately 120W is dedicated to system power needed for the chassis and the rest of the power is utilized for Power over Ethernet (PoE). The power supplies connect to the rear of the unit. There is a power shelf provided with the unit that slides into the rear of the chassis and is used to hold the power supplies. It can hold either one 510W power supply or two 360W power supplies or in case of non-PoE product switches two 120W or two 126W power supplies. See the table below for valid configurations.
Model OS6850-P48L, OS6850-P48, OS6850-P48X,OS6850-P24L, OS6850-P24, OS6850-P24X OS6850-P48L, OS6850-P48, OS6850-P48X, OS6850-P24L, OS6850-P24, OS6850-P24X OS6850-P48L, OS6850-P48, OS6850-P48X, OS6850-P24L, OS6850-P24, OS6850-P24X OS6850-P48L, OS6850-P48, OS6850-P48X, OS6850-P24L, OS6850-P24, OS6850-P24X OS6850-P48L, OS6850-P48, OS6850-P48X, OS6850-P24L, OS6850-P24,OS6850-P24X OS6850-P48L, OS6850-P48, OS6850-P48X, OS6850-P24L, OS6850-P24, OS6850-P24X OS6850-P48L, OS6850-P48, OS6850-P48X, OS6850-P24L, OS6850-P24, OS6850-P24X OS6850-P48L, OS6850-P48, OS6850-P48X, OS6850-P24L, OS6850-P24, OS6850-P24X OS6850-P48L, OS6850-P48, OS6850-P48X, OS6850-P24L, OS6850-P24, OS6850-P24X, OS6850-P48L, OS6850-P48, OS6850-P48X, OS6850-P24L, OS6850-P24, OS6850-P24X OS6850-48, OS6850-48X, OS6850-24, OS6850-24X, OS6850-U24X, OS6850-24L, OS6850-48L OS6850-48, OS6850-48X, OS6850-24, OS6850-24X, OS6850-U24X, OS6850-24L, OS6850-48L OS6850-48, OS6850-48X, OS6850-24, OS6850-24X OS6850-U24X, OS6850-24L, OS6850-48L OS6850-48, OS6850-48X, OS6850-24, OS6850-24X, OS6850-U24X, OS6850-24L, OS6850-48L Primary Power 510W Backup Power Supply 510W Valid Configurations? Valid

360W

360W

Valid

360W

510W

Not valid

510W

360W

Not valid

510W

126W

Not valid

510W

120W

Not valid

360W

126W

Not valid

360W

120W

Not valid

126W (AC)

None

Not valid

120W (DC)

None

Not valid

126W (AC)

126W (AC)

Valid

120W (DC)

120W (DC)

Valid

126W (AC)

120W (DC)

Valid

120W (DC)

126W (AC)

Valid

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 110 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850-48, OS6850-48X, OS6850-24, OS6850-24X, OS6850-U24X, OS6850-24L, OS6850-48L OS6850-48, OS6850-48X, OS6850-24, OS6850-24X, OS6850-U24X, OS6850-24L, OS6850-48L OS6850-48, OS6850-48X, OS6850-24, OS6850-24X, OS6850-U24X, OS6850-24L, OS6850-48L OS6850-48, OS6850-48X, OS6850-24, OS6850-24X, OS6850-U24X, OS6850-24L, OS6850-48L

126W (AC)

510W

Not valid

120W (DC)

360W

Not valid

510W

None

Not valid

360W

None

Not valid

The power supplies can also be connected using a cable, in case there is a need for a less deep chassis. In this case, the same power shelf can be mounted in the rack using the mounting ears (removable in case the power supply needs to be plugged into the rear of the chassis).

Power Supply Shelf

Alcatel-Lucent requires the use of power supply shelf when the power supply is used in a 1U (i.e., 1.5 inches/3.8cm) configuration. In a 2U (i.e., 3 inches/7.6 cm) configuration, if you have a 510W power supply you can either use the power supply shelf or you can mount the 510W power supply directly to a rack.

Power Supply Redundancy

OS6850-BP OS6850-BP-D OS6850-BP-P OS6850-BP-PH Backup Power Supplies OS6850-BP modular 126W AC backup power supply. Provides backup power to one non- PoE switch. Ships with chassis connection cable, country specific power cord, power shelf and connecting ears. OS6850-BP-D modular 120W DC backup power supply. Provides backup power to one non-PoE switch. Ships with chassis connection cable, power shelf and connecting ears. OS6850-BP-P modular 360W AC backup power supply. Provides backup power to one PoE switch. Ships with chassis connection cable, country specific power cord, power shelf and connecting ears. OS6850-BP-PH modular 510W AC backup power supply. Provides backup power to one PoE switch. Ships with chassis connection cable, country specific power cord, power shelf and connecting ears.

Monitoring Chassis Power

OmniSwitch 6850 Series switches can be monitored and managed via the console port using Command Line Interface (CLI) commands. The switches can also be monitored and managed via the Ethernet ports using CLI commands, WebView, SNMP, and OmniVista.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 111 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Power Supply Specifications

Pow er Supply Requirements
Power Supply Requirements Directly Pluggable in the back of the chassis (chassis depth +P/S depth is then 440mm or 16.73 inches) Remotely connected to the chassis through a cable (chassis depth is then 270mm or 10.63 inches) There are 4 different power supplies for the family: OS6850 Series Primary Power Supplies include: The 126W AC-to-DC Non-PoE P/S The 126W AC-to-DC Power Supply is used on the following Models: OS6850-24 & OS6850-24L & OS6850-24X & OS6850-48 & OS6850-48L & OS6850-48X & OS6850-U24X The 120W DC-to-DC Non-PoE P/S The 120W DC-to-DC Power Supply is used on the following Models: OS6850-24D & OS6850-24LD & OS6850-24XD & OS6850-48D & OS6850-48LD & OS6850-48XD & OS6850-U24XD The 360W AC-to-DC Standard PoE P/S The 360W AC-to-DC Power Supply is used on the following Models: OS6850-P24 & OS6850-P24L & OS6850-P24X & OS6850-P48 & OS6850-P48L & OS6850-P48X The 510W AC-to-DC High PoE P/S The 510W AC-to-DC Power Supply is used on the following Models: OS6850-P24H & OS6850-P24LH & OS6850-P24XH & OS6850-P48H & OS6850-P48LH & OS6850-P48XH OS6850 Series Backup Power Supplies include: OS6850-BP-P: OS6850-BP-P modular Standard PoE 360W AC-to-DC backup P/S OS6850-BP-PH: OS6850-BP-PH modular High PoE 510W AC-to-DC backup P/S OS6850-BP: OS6850-BP modular 126W AC-to-DC backup P/S OS6850-BP-D: OS6850-BP-D modular 120W DC-to-DC backup P/S Notes: The main power supply is EXTERNAL to the box A power shelf is used to hold either one 510 PS or two of the smaller PS. Directly Pluggable in the back of the unit total unit + PS depth is then 44.6 cm/17.56in) OR Attached with a cable for 2U configuration Both primary and backup power supplies fit into the power shelf for 120W, 126W and 360W PS. Directly Pluggable in the back of the unit next to the primary or placed on top of the unit The backup High PoE power supply (510W) cannot be adjacent to the primary PS on the same shelf. It has to have its own power supply shelf A shelf and a remote cable is provided within the shipping box to rack a power supply on top of the unit Remotely connected power supply allows for smaller depth space requirement. The OS6800 product family Backup Power Supplies cannot be used for the OS6850 product family and vice-versa. The chassis P/S fail-over to the backup P/S is transparent to the users and without a reboot of the switch. The fail-over time is negligible.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 112 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Power Supply Input & Output Electrical Parameters

Power Supply Specifications Main and backup power supplies are external Connect to the rear of the unit Can be connected by cable Supports redundant dual hot swappable P/S Power shelf provided with unit holds one 510W or two 360W, 126W or 120W power supplies OmniSwitch 6850-24, -24X, -48, -48X, -U24X Support 126W (AC) and 120W (DC) power supplies Do not support PoE OmniSwitch 6850-P24, -P24X, -P48, and -P48X Dual externally mounted 360W and/or 510W P/S 130W dedicated to chassis power Remainder used for PoE OS6850 Series Primary Power Supplies include: The 126W AC-to-DC Non-PoE P/S The 126W AC-to-DC Power Supply is used on the following Models: OS6850-24 & OS6850-24L & OS6850-24X & OS6850-48 & OS6850-48L & OS6850-48X & OS6850-U24X The 126W P/S Input & Output Parameters for the chassis main Power: The 126W AC/DC power supply provides +12V @ 10.5A. Input Power: 157.5 watts AC (based on an efficiency of 80%) Maximum continuous output power will be 126W. Peak power for 50msec will be 156W. Input Voltage range: 85 to 269VAC (Universal input voltage) Input Voltage range: 100 to 240VAC (Nominal Input Voltage or Agency approved unit) Nominal input is expected to be 115VAC(rms) at 60Hz or 230VAC(rms) at 50Hz. Input current: 1.37 Amps AC@115VAC or 0.684 Amps AC@230VAC Input current will be less than 1.8A (rms) at 115Vac (rms) and 60Hz. Input current will be less than 0.9A (ms) at 230Vac (rms) and 50Hz. Input Frequency: 47 to 63 Hz (3%) The power supply efficiency will be greater than 75%. The input fuse value shall be less than or equal to 4 Amps AC Output Power: 126watts DC rated Output voltage: 12VDC rated Output current: 10.5Amps DC rated The 120W DC-to-DC Non-PoE P/S The 120W DC-to-DC Power Supply is used on the following Models: OS6850-24D & OS6850-24LD & OS6850-24XD & OS6850-48D & OS6850-48LD & OS6850-48XD & OS6850-U24XD The 120W P/S Input & Output Parameters for the chassis main Power: The 120W DC/DC power supply provides +12V @ 10A. The P/S operates from 3675VDC. Input Power: 150 watts DC (based on an efficiency of 80%) Input Voltage range: 36 to 75VDC (Universal input voltage) Input Voltage: 48VDC (Nominal Input Voltage or Agency approved unit) Input current: 3.125 Amps DC@48 VDC Input current will be less than 3.2A at 48VDC. The power supply efficiency will be greater than 75%. Output Power: 120watts DC rated Output voltage: 12VDC rated Output current: 10Amps DC rated The 360W AC-to-DC Standard PoE P/S The 360W AC-to-DC Power Supply is used on the following Models: OS6850-P24 & OS6850-P24L & OS6850-P24X & OS6850-P48 & OS6850-P48L & OS6850-P48X This specification covers the 360W switching power supply requirements for Ethernet switches with 240W (-50V @ 4.8A) for PoE power and 120W (12V @ 10.0A) for system power operation. The 360W P/S provides the following outputs: The power supply provides dual outputs, -50V and +12V. P/S Input Parameters: Input Power: 450 watts AC (based on an efficiency of 80%) Input Voltage range: 90 to 264VAC (Universal input voltage) Input Voltage range: 100 to 240VAC (Nominal Input Voltage or Agency approved unit) Nominal input is expected to be 115VAC (rms) at 60Hz or 230VAC (rms) at 50Hz. Input current: 3.91 Amps AC@115VAC or 1.95 Amps AC@230VAC Input current: 5.0 Amps AC@90VAC Input current will be less than 4.5A (rms) at 115VAC (rms) and 60Hz. Input current will be less than 2.3A (rms) at 230VAC (rms) and 50Hz. Input Frequency: 47 to 63 Hz (3%) The power supply efficiency will be greater than 75%. The input fuse value shall be less than 8 Amps AC The power supply shall provide the following required output voltages & output currents for the main chassis and the PoE. Maximum continuous output power will be 360W. The Main Chassis P/S Output Parameters: Output Power: 120 watts DC rated Output voltage: 12 VDC rated Output current: 10.0 Amps DC maximum rated The PoE P/S Output Parameters: The estimated available PoE power budget is 240watts: Output Power: 240 watts DC maximum rated

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 113 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

PoE Power availability

Output voltage: -50 VDC maximum rated Output current: 4.8 Amps DC maximum rated The 510WAC-to-DC High PoE P/S The 510W AC-to-DC Power Supply is used on the following Models: OS6850-P24H & OS6850-P24LH & OS6850-P24XH & OS6850-P48H & OS6850-P48LH & OS6850-P48XH This specification covers the 510W switching power supply requirements for Ethernet switches with 390W (50V @ 7.8W/port) for PoE power and 120W (12V @ 10.0A) for system power operation. The 510W P/S provides the following outputs: The power supply provides dual outputs; -50V and +12V. P/S Input Parameters: Input Power: 637.5 watts AC (based on an efficiency of 80%) Input Voltage range: 85 to 264VAC (Universal input voltage) Input Voltage range: 100 to 240VAC (Nominal Input Voltage or Agency approved unit) Nominal input is expected to be 115VAC (rms) at 60Hz or 230VAC (rms) at 50Hz. Input current: 5.54 Amps AC@115VAC or 2.77 Amps AC@230VAC Input current: 7.08 Amps AC@90VAC Input current will be less than 10A (rms) at 115VAC (rms) and 60Hz. Input current will be less than 5A (rms) at 230VAC (rms) and 50Hz. Input Frequency: 47 to 63 Hz (3%) The power supply efficiency will be greater than 75%. The input fuse value shall be less than 12 Amps AC The power supply shall provide the following required output voltages & output currents for the main chassis and the PoE. Maximum continuous output power will be 510W. The Main Chassis P/S Output Parameters: Output Power: 120 watts DC rated Output voltage: 12 VDC rated Output current: 10.0 Amps DC maximum rated The PoE P/S Output Parameters: The estimated available P/S PoE power budget is 390watts: Output Power: 390 watts DC maximum rated Output voltage: -50 VDC maximum rated Output current: 7.8 Amps DC maximum rated Note: Switching DC/DC or linear regulators on the PCB further breaks down the +12VDC to generate the required 5V, 3.3V, 2.5V, 1.8V, 1.25V, 1.2V and 2V. The 360W AC-to-DC Power Supply is used on the following PoE Models: OS6850-P24 & OS6850-P24L & OS6850-P24X & OS6850-P48 & OS6850-P48L & OS6850-P48X: The 360W power supply provides: 240W (-50V @ 4.8A) for in-line power and 120W (12V @ 10.0A) for system power operation. PoE Power Budget for the 24-port Models: 216watts [240watts (PoE power) 24watts (the overhead (power consumed by the PoE daughter card which is 1watt per port))]. PoE Power Budget for the 48-port Models: 192watts [240watts (PoE power) 48watts (the overhead (power consumed by the PoE daughter card which is 1watt per port))]. The 510W AC-to-DC Power Supply is used on the following PoE Models: OS6850-P24H & OS6850-P24LH & OS6850-P24XH & OS6850-P48H & OS6850-P48LH & OS6850-P48XH: The 510W power supply provides: 390W (50V @ 7.8W/port) for in-line power and 120W (12V @ 10.0A) for system power operation. The available PoE Power Budget for the 24-port Models: 366watts [390watts (PoE power) 24watts (the overhead (power consumed by the PoE daughter card which is 1watt per port))]. The available PoE Power Budget for the 48-port Models: 342watts [390watts (PoE power) 48watts (the overhead (power consumed by the PoE daughter card which is 1watt per port))]. Note: Power for all POE ports is defaulted to 15.4 watts per port and each port is configurable between 3watts to 15.4watts (Port setting is in Milliwatts (3000 to 15400)). Please note that the available PoE power budget must not be exceeded.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 114 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Power Supply Shelf

Alcatel requires the use of power supply shelf when the power supply is used in a 1U (i.e., 1.5 inches/3.8cm) configuration. In a 2U (i.e., 3 inches/7.6 cm) configuration, if you have a 510W power supply you can either use the power supply shelf or you can mount the 510W power supply directly to a rack.

PS-510W-AC Power Supply

The PS-510W-AC power supply (shown below) supports full switch and Power over Ethernet (PoE) functionality for The OmniSwitch 6850 Series switches. A single 510W power supply allocates 390W for the POE functionality. It can be installed as either the primary or backup power supply. For redundancy purposes, when two (2) (one primary and one backup) power supplies are installed, the backup power supply acts as an active stand-by power supply. There is no loadsharing between the primary and the backup power supplies.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 115 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

PS-360W-AC Power Supply

The PS-360W-AC power supply (shown below) supports full switch and Power over Ethernet (PoE) functionality for The OmniSwitch 6850 Series switches. A single 360W allocates 240W for the POE functionality. In addition, the 360W power supply can be installed as a primary or backup power supply. For redundancy purposes, when two (2) (one primary and one backup) power supplies are installed, the backup power supply acts as an active stand-by power supply. There is no loadsharing between the primary and the backup power supplies.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 116 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

PS-126W-AC Power Supply

The PS-126W-AC power supply supports switch functionality for non-PoE OmniSwitch 6850 Series switches. In addition, the 126W power supply can be installed as one of the two primary supplies or as a backup power supply. For redundancy purposes, when two (2) (one primary and one backup) power supplies are installed, the backup power supply acts as an active stand-by power supply. There is no loadsharing between the primary and the backup power supplies. Note. The PS-126W-AC power supply has the same physical dimensions and interfaces as the PS-360WAC power supply.

PS-120W-DC Power Supply

The PS-120W-DC power supply (shown below) supports switch functionality for non-PoE OmniSwitch 6850 Series switches. In addition, the 120W power supply can be installed as one of the two primary supplies or as a backup power supply. For redundancy purposes, when two (2) (one primary and one backup) power supplies are installed, the backup power supply acts as an active stand-by power supply. There is no loadsharing between the primary and the backup power supplies. Note. The PS-120W-DC power supply has the same physical dimensions and interfaces as the PS-360WAC power supply.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 117 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Managing OmniSwitch 6850 Series Stacks

In addition to their working as individual stand-alone switches, OmniSwitch 6850 Series switches can also be linked together to work as a single virtual chassis known as a stack. With stacks, users can easily expand their switching capacity simply by adding additional switches to the stack. In addition, stacks provide enhanced resiliency and redundancy features. Note. You can also manage and monitor OmniSwitch 6850 Series stacks through WebView, Alcatel-Lucents embedded web-based device management application. WebView is an interactive and easy-to-use GUI that can be launched from OmniVista or a web browser.

OmniSwitch 6850 Series Stack Overview

Users can configure up to eight OmniSwitch 6850 Series switches, in any combination of OS6850-24 and OS6850-48 chassis types, into a single virtual chassis known as a stack. With stacks, simply adding additional switches to the stack can easily expand switching capacity. For example, a user can start with a stack composed of two switches and add up to six additional switches to that stack as network demands increase over time. Stacks also provide enhanced resiliency and redundancy features. If a switch in a stack goes down or is taken offline, the other elements in the stack will continue to operate without disruption. In addition, when a switch auto-synchronizes at boot-up, or if the user manually synchronizes the switches operating software and configuration parameters are backed up on all switches in the stack. As a result, the original operating software and configuration parameters can be easily recovered if corrupted or otherwise lost.

Roles within the Stack

In order to operate as a virtual chassis, switches within an OmniSwitch 6850 Series stack are assigned specific roles. These roles include primary and secondary management roles, idle status, and pass-through.

Primary and Secondary Management

When OmniSwitch 6850 Series switches operate in a stack, one switch in the stack always assumes the primary management role. This primary element is responsible for functions, such as software and configuration management, web-based management (i.e., WebView), SNMP management, switch diagnostics, and software rollback. One additional switch in the stack operates in a secondary management role. This switch serves as a backup, and is always ready to assume the primary management role in the stack if the switch with the primary role fails or is taken offline for any reason. Since the secondary module quickly and automatically assumes management responsibilities, switches operating in idle mode elsewhere in the stack continue to pass traffic without disruption. This redundancy provides effective safeguards for mission-critical network traffic and is one of the stacks most important failover features.

Primary Management Module Selection

For a stack of OmniSwitch 6850 Series switches to operate as a virtual chassis, there must be a mechanism for dynamically selecting the switch within the stack that will assume the primary management role. OmniSwitch 6850 Series switches use three different methods for selecting the primary switch. These methods are: Chassis MAC address Saved slot number Chassis uptime

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 118 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using the Chassis MAC Address

By default, the primary management role will be given to the switch with the lowest chassis MAC address. However, for this to occur, all switches in the stack must be booted within 15 seconds of each other. In addition, switches in the stack must have no preconfigured slot information. Because of these two conditions, the MAC address method for selecting the primary module usually occurs with new out of the box switches, or switches from which any preconfigured slot information has been cleared.

Using Saved Slot Information

The saved slot number is the slot number the switch will assume following a reboot. This information is stored in a switchs boot.slot.cfg file; the switch reads its slot number assignment from this file at boot up and assumes the specified slot number within the stack. If switches in a stacked configuration have no preconfigured slot assignments, the system software dynamically assigns the slot number for each switch. The user can also manually assign slot numbers. When a stack with preconfigured slot information is booted, it is not the lowest MAC address that determines the primary management module. Instead, the slot information stored in each switchs boot.slot.cfg is read by the system software and used in determining the primary. The switch with the lowest saved slot number becomes the primary management module. Note. Although, for ease-of-management purposes, it is recommended that slot numbers are assigned beginning with slot number 1, it is not a requirement. In other words, a stack of four switches can have slot assignments 3, 4, 5, and 6. However, it is important that each element in a stack is assigned a unique slot number. Do not assign duplicate slot numbers to elements in a stack. Otherwise, one or more switches will be forced into pass-through mode.

Using Switch Uptime

A user can override both the MAC address and saved slot methods for determining a stacks primary management module. Controlling the uptime of switches in the stack does this. If all elements of a stack are powered off, the user can force a particular switch to become primary by powering on that switch and waiting a minimum of 15 seconds before powering on any other switches. This can be useful if the user wants a switch placed in a specific location, e.g., the top-most switch in a stack, to become the primary. As with the lowest MAC address method, the primary management module is dynamically assigned slot number 1 when the stack is booted.

Secondary Management Module Selection

In order to provide effective management module redundancy, all OmniSwitch 6850 Series stacked configurations dynamically assign a backup, or secondary, management module during the boot process. OmniSwitch 6850 Series stacks use two different methods for selecting the secondary switch. These methods are: Stacking connection to the primary switch Saved slot number

Using the Stacking Connection to the Primary Switch

By default, the switch that is connected to the primary switchs stacking port A is automatically assigned the secondary management role. This applies to stacks on which there is no pre-assigned slot information i.e., there is no boot.slot.cfg file present in any switch.

Using Saved Slot Information

If a stack with pre-assigned slot information for each switch is booted, the switch with the second lowest slot value is assigned the secondary management role. For example, if a stack of four switches is booted and the pre-assigned slot values for each switch are 1, 2, 3, and 4, the switch with the slot value of 2 is assigned the secondary role. Meanwhile, the switch with the slot value of 1 is assigned the primary management role.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 119 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Idle Module Role

Switches that are not assigned either the primary or secondary role in a stack are, by default, assigned the role of idle modules. These idle modules operate similarly to Network Interface (NI) modules in a chassis-based switch such as the OmniSwitch 7700/7800. It is the job of idle modules to send and receive 10/100/1000 Ethernet traffic on their ports. In the event of a management module failure within the stack, the idle module with the next lowest slot number in the stack will automatically assume the secondary management role. In other words, if the primary module in a stack goes down for any reason and the secondary takes over the primary management role, the switch must now assign a new secondary module. The idle element with the next lowest slot number assumes this new responsibility until the situation is corrected and all elements in the stack are reloaded. Note. Primary and secondary management modules also send and receive 10/100/1000 traffic on their Ethernet ports. The primary management module is like an NI module with the added task of overall stack management; the secondary management module is like an NI with the added responsibility of backing up the primary module in the event of a primary module failure. In other words, all modules in the virtual chassis can send and receive user data, regardless of their roles.

Pass-Through Mode
The pass-through mode is a state in which a switch has attempted to join a stack but has been denied primary, secondary, and idle status. When a switch is in the pass-through mode, its Ethernet ports are brought down (i.e., they cannot pass traffic). Its stacking cable connections remain fully functional and can pass traffic through to other switches in the stack. In this way, the pass-through mode provides a mechanism to prevent the stack ring from being broken. However, note that when a switch comes up in Pass-through mode, it should not be left unresolved. Pass-through mode is essentially an error state that should be corrected immediately by the user. Conditions that can trigger a switch to enter pass-through mode include: Duplicate slot numbers have been assigned within the stack The user has manually forced the switch into pass-through mode Note. If a switch is forced into pass-through mode, the rest of the stack will not be disrupted. Any elements in the stack not operating in pass-through mode continue to operate normally. The most common reason for one or more switches to enter pass-through is duplicate slot number assignments within the stack. So, in order to avoid pass-through mode, it is useful to keep track of the current saved slot numbers on all elements in the stack. Slot number assignments are stored in the boot.slot.cfg file in the /flash directory of each switch. If the stack is booted and the same slot number is discovered on two or more switches, the switch with the lowest MAC address is allowed to come up and operate normally. Meanwhile, switches with the duplicate slot number and a higher MAC address come up in pass-through mode.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 120 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Stack Cabling
Switches in a stack are connected to each other by stacking cables. The valid cable lengths are 1.5m (4.9 feet), 60cm (23.6 inches), and 30cm (11.8 inches). These stacking cables provide high-speed, dual-redundant links between switches in a stack. Stacking cables for OmniSwitch 6850 Series switches can be connected in any pattern. In other words, the cable connected to stacking port A of one switch can be connected to either stacking port A or stacking port B of the adjacent switch. However, it is strongly recommended that the cabling pattern remains consistent across the stack. In addition, for a stack to have effective redundancy a redundant stacking cable must be installed between the upper-most and bottom-most switch at all times. This provides effective failover in the event of a stacking link or module failure within the stack. Note. When planning the stack-cabling configuration, keep in mind that the switch connected to stacking port A of the primary switch will be assigned the secondary management role by default.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 121 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Redundant Stacking Cable Connection

OmniSwitch 6850 Series switches allow redundant stacking cable connections between the top-most and bottom-most switches in a stack. Important. For a stacked configuration to have effective redundancy a redundant stacking cable must be installed between the upper-most and bottom-most switch in the chassis at all times. Redundant stacking cables provide a form of dual redundancy. As shown in the figure above, the redundant cable allows traffic to flow in the event of a stacking link failure. The redundant cable also provides failover if a switch goes down within the stack. Traffic continues to flow between the modules that remain operational.

Slot Numbering
For a stack of OmniSwitch 6850 Series switches to operate as a virtual chassis, each module in the stack must be assigned a unique slot number. To view the current slot assignments for a stack, use the show Ni or show module commands. The LED located on the left side of the chassis also displays the slot number on the front panel of each switch. There are two ways stacking modules are assigned slot numbers: Dynamic slot number assignment by the system software Manual slot number assignment by the user

Dynamic Slot Number Assignment

Dynamic slot number assignment occurs when there are no boot.slot.cfg files present in the switches/flash directories. This is the case for new, out of the box, switches that have not been previously booted. When a brand new stack (or stack with no boot.slot.cfg files) is booted, the system software automatically detects the module with the lowest MAC address. This module is assigned the primary management role and, by default, is given the slot number 1. The module connected to the primarys stacking port A is automatically assigned the secondary management role and given the slot number 2. As the other modules in the stack become operational, they are assigned idle roles and are automatically assigned unique slot numbers (38, depending on the number of switches in the stack). The slot numbering for idle modules is determined by each modules physical location in the stack. Note. As the slot numbers are dynamically assigned, boot.slot.cfg files are auto-generated in the /flash directory of each switch. When modules are subsequently booted, each switch reads its slot number assignment from this file and comes up accordingly.

Manual Slot Number Assignment

To manually assign slot numbers to one or more modules in a stack, use the stack set slot command. This command writes slot information to the boot.slot.cfg file located in a switchs /flash directory. It is this saved slot information that the switch will assume following a reboot. Manually assigning slot numbers can be useful in reordering existing slot numbers in order to create a sequential numbering scheme from the top of the stack to the bottom (or vice-versa).

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 122 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Hot-Swapping Modules in a Stack

As with chassis-based switches, such as the OmniSwitch 7700/7800/8800 or OmniSwitch 9000, NI modules within an OmniSwitch 6850 Series virtual chassis are hot swappable. NI modules are essentially those modules operating in the stack in idle mode. These modules can be removed from, or added to, an existing stack without disrupting other modules in the stack.

Removing Switches from an Existing Stack

When removing switches from an existing stack, observe the following important guidelines: Do not attempt to hot-swap modules operating in primary or secondary management roles Be sure the stacking cables and stacking cable redundancy are not disrupted Hot swapping is intended for switches in idle and, if applicable, pass-through status only. Removing primary or secondary management modules from a stack will trigger a failover sequence, i.e., one or more additional modules within the stack must reload in order to reassign the management roles. Whenever possible, avoid removing a switch that is operating as a primary or secondary management module. Also, removing a switch from a stacked configuration can disrupt stack cabling at the rear of the stack. When removing a module, be sure that stacking link integrity, including important stacking cable redundancy, is maintained between all remaining modules.

Inserting Switches into an Existing Stack

When inserting switches into an existing stack, observe the following important guidelines: Avoid duplicate saved slot numbers Never attempt to operate more than eight switches in a single stack Make sure all switches are running the same software version. Note. Other stackable Alcatel-Lucent products, cannot be added to an OmniSwitch 6850 Series virtual chassis. To avoid duplicate slot numbers, simply make sure that any modules being added to an existing stack have been cleared of preassigned slot information. In other words, verify that there is no boot.slot.cfg file present in the /flash directory of any switch being added. When the switch is connected to the existing stack and booted, the system software automatically assigns it a unique slot number. No duplicate slot errors occur. Note. If it is preferable to add a switch with an existing boot.slot.cfg file to a stack, be sure that the saved slot number of the incoming switch is not already assigned to a switch operating in the stack.

Merging Stacks
Merging stacks involves connecting two or more operational stacks and attempting to reboot them as a single virtual chassis. In most cases, errors will result. To merge stacks without causing errors, select one stack that is to remain up and running and then add modules from the other stack(s) by following the steps below: 1 Make sure all switches are running the same software version. 2 Clear the saved slot information from all incoming modules. This will ensure that they are each assigned unique slot numbers when they join the stack. 3 After clearing the saved slot information, power off all incoming modules. 4 Connect the stacking cables for all incoming modules to the existing, operational stack as required. Be sure to provide stacking cable redundancy. 5 Power on all incoming modules. Note. No more than eight switches can operate in a single stacked configuration at any time.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 123 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Reloading Switches
Reloading is essentially a soft boot of a switch. Users can reload stacked modules operating in any role i.e., primary, secondary, idle, and pass-through. Refer to the sections below for more information.

Reloading the Primary Management Module

If the switch with the primary management role is reloaded, the switch with the secondary role automatically takes over primary management functions. In other words, the switch with the secondary role assumes the primary role as soon as the reload is initiated. Meanwhile, the idle switch with the next lowest slot number automatically assumes the secondary role. When the reloaded switch (the former primary module) comes back up, it assumes an idle role within the stack. Note. A primary management module reload can also be scheduled for a later time or date.

Reloading the Secondary Management Module

If the switch with secondary management role is reloaded, the idle switch with the lowest slot number will automatically assume the secondary role. The reloaded switch (the former secondary) will assume an idle role when it comes back up. Meanwhile, the switch with the primary management role, as well as any other idle modules in the stack, continue operations without interruption. Note. A secondary management module reload can also be scheduled for a later time or date.

Reloading Switches with Idle Roles

Similar to reloading Network Interface (NI) modules on chassis-based switches such as the OmniSwitch 7700/7800 and OmniSwitch 8800, modules operating in idle status within a stack can be reloaded via the CLI. Note. Any traffic being passed on the modules Ethernet ports will be interrupted during the reboot. Other modules within the stack will continue to operate without interruption. After reloading a switch operating in an idle role, the switch resumes idle status when it comes back up, despite its saved slot number. In other words, if an idle switch with a saved slot number of 1 is reloaded, it resumes its previous idle role. Although it has the lowest possible saved slot number, it does not take over the primary management role. In order for this switch to take over the primary role, all switches in the stack must be reloaded.

Reloading Switches in Pass-Through Mode

Pass-through mode is a state in which a switch has attempted to join a stack but has been denied primary, secondary, and idle status. Because this is essentially an error state, the pass-through condition must be resolved and any modules operating in pass-through mode must be reloaded.

Reloading All Switches in a Stack

Reloading all switches in the stack is essentially a full reboot of the virtual chassis. This can be useful in restoring a stacks previously configured topologyi.e., the stacks saved slot numbers and management roles. Note, however, that all data flow on the stack is interrupted whenever a full reboot is issued.

Software Synchronization During a Full Reload

If the checksum value on the stacks non-primary switches differs in any way from the checksum value on the primary switch, the primary switch automatically distributes its system and configuration software to all other switches in the stack whenever a full reload is executed. During this automatic software synchronization, system and configuration software on the secondary and idle switches is overwritten. Because the primary switchs last known good software is propagated to all switches, the synchronization process helps ensure effective redundancy across the stack.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 124 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Effects of Saved Slot Number Information on the Reload Process

Depending on the status of saved slot information across the stack, there are different slot numbering and management role scenarios that can occur following a full reboot. For this reason, checking the current stack topology before issuing a full reboot is strongly recommended. To check the current stack topology, use the show stack topology command. Possible saved slot number conditions include: All switches have unique saved slot information No switches in the stack have saved slot information Some switches have saved slot information, others do not Two or more switches have duplicate slot information All Switches Have Unique Saved Slot Information If a full reload is issued and all switches have unique slot numbers saved to their boot.slot.cfg files, the slot numbers will be assigned according to the saved slot information. The primary management role will be given to the switch with the lowest saved slot number. The secondary management role will be given to the switch with the second-lowest saved slot number. All other switches will be assigned to idle roles. No Switches In the Stack Have Saved Slot Information If a full reload is issued and no switches in the stack have unique slot numbers, slot numbers will be assigned beginning with the switch with the lowest MAC address. (This can occur if the boot.slot.cfg file has been deleted from each switchs /flash directorye.g., by issuing the stack clear slot command for all modules in the stack.) The switch with the lowest MAC address is assigned slot number 1 and given the primary management role. The switch connected to stacking port A of the primary switch is automatically assigned slot number 2 and given the secondary management role. Stack cabling is then used to determine the dynamic slot numbering of the remaining modules in the stack. The switch immediately adjacent to slot 2 is assigned slot number 3 and given an idle role, etc. Some Switches Have Saved Slot Information, Others Do Not If only some switches in the stack have boot.slot.cfg files in their /flash directories, the system software will first read the contents of these files and then dynamically assigns unique slot numbers to any switches that do not have saved slot information. The primary management role will be given to the switch with the lowest saved slot number. The secondary management role will be given to the switch with the second lowest saved slot number. All other switches will be assigned to idle roles. When the system software dynamically assigns unique slot numbers, a boot.slot.cfg file is automatically generated with the new slot information. Because all switches now have unique saved slot information, any subsequent reload all commands issued will cause the stack to come up. Two or More Switches Have Duplicate Slot Information If a full stack reboot is issued and the same slot number is found in the boot.slot.cfg file of two or more switches, the switch with the lowest MAC address is allowed to come up and operate normally. Meanwhile, any other switches with the duplicate slot number come up in pass-through mode. The pass-through mode is essentially an error state in which a switch has been denied primary, secondary, and idle roles within the stack. When a switch is in pass-through mode, its Ethernet ports are brought down and cannot pass traffic. It is for this reason that users should always check the current saved slot number for each switch before issuing the reload all command. To check the current saved slot information across the stack, use the show stack topology command.

Avoiding Split Stacks

The term splitting a stack refers to the creation of isolated modules within the virtual chassis. A split stack can result from the following conditions: Two or more non-adjacent switches are reloaded simultaneously The stack is reloaded without a redundant stacking cable connection The sections below offer simple guidelines for avoiding splitting the stack during the reload process. Do Not Reload Non-Adjacent Switches Simultaneously If non-adjacent switches in the stackfor example, the top switches in the stack and the third-from-top switch in the stackare reloaded simultaneously, a problem will occur. The switch between the two nonadjacent switches will become isolated and the virtual chassis will be effectively split. To avoid splitting the stack, do not reload the two non-adjacent switches simultaneously. Instead, simply reload the top switch first, and then reload the third-from-top switch, or vice-versa.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 125 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Be Sure a Redundant Stacking Cable is installed at All Times Another important guideline for avoiding split stacks involves the redundant stacking cable. In order to avoid isolated modules within the virtual chassis, simply make sure that a redundant stacking cable connection exists between the topmost and bottom-most switches at all times.

Changing the Secondary Module to Primary

OmniSwitch 6850 Series stacks allow users to manually force the secondary switch to assume the primary management role. This is referred to as takeover. The behavior of a takeover is similar to that of reloading the primary management module. Whenever a takeover is initiated, the switch with the secondary role automatically takes over primary management functions. The primary switch is automatically reloaded and any traffic being passed on the primary switchs Ethernet ports is interrupted. Meanwhile, the idle switch with the next-lowest slot number automatically assumes the secondary role. When the former primary module comes back up, it assumes an idle role within the stack. Note. Before using the takeover command, verify that the switches in the stack are synchronized. Otherwise, data flow and switch management functions may be interrupted due to incorrect or outdated software when a switch takes over the primary management role.

Synchronizing Switches in a Stack

Management module synchronization refers to the process of copying all files in the /flash/working and /flash/certified directories of the primary management module to the /flash/working and /flash/certified directories of all the other switches in the stack. The system and configuration software on the non-primary switchesi.e., the secondary management module and any modules operating in idleis overwritten. The synchronization process ensures that the contents of these directories match exactly for all switches across the stack. This can be especially useful after new software has been loaded to the primary management module. Further, synchronization prevents any switch from assuming a management role within the stack with incorrect or outdated software or configuration files. Because the primary switchs last known good software is propagated to all switches, the synchronization process helps ensure effective redundancy across the stack. In order to maintain effective management module redundancy, switches in the stack must be synchronized at all times. When the synchronization process is initiated, modules within the stack continue to operate without interruption and data flow across the stack is unaffected.

Automatic Synchronization during a Full Reload

If the checksum value on the stacks non-primary switches differs in any way from the checksum value on the primary switch, the primary switch automatically distributes its system and configuration software to all other switches in the stack whenever a full reload is executed.

Monitoring the Stack

As shown in the previous sections, monitoring the current status and operation of all elements in a stack can help users avoid unexpected stack conditions. The show CLI commands are useful in monitoring stack conditions.

Visually Monitoring the Stack

Users can also monitor many stack operations by viewing the front panel LEDs on all elements in the stack.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 126 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Managing Power over Ethernet (PoE)

Power over Ethernet (PoE) is supported on OmniSwitch 6850 Series switches and provides inline power directly from the switchs Ethernet ports. Powered Devices (PDs) such as IP phones, wireless LAN stations, Ethernet hubs, and other access points can be plugged directly into the Ethernet ports. From these RJ-45 ports the devices receive both electrical power and data flow. As the feature reduces devices dependence on conventional power sources, PoE eliminates many restrictions that traditional electrical considerations have imposed on networks. In a PoE configuration, Power Source Equipment (PSE) detects the presence of a PD and provides an electrical current that is conducted along the data cable. The PD operates using the power received via the Ethernet data cable; no connection to an additional power source (e.g., an AC wall socket) is required. Note on Terminology. There are several general terms used to describe the feature, PoE. The terms Power over Ethernet (PoE), Power over LAN (PoL), Power on LAN (PoL), and Inline Power are synonymous terms used to describe the powering of attached devices via Ethernet ports. Additional terms, such as Powered Device (PD) and Power Source Equipment (PSE) are not synonymous with PoE, but are directly related to the feature: PD refers to any attached device that uses a PoE data cable as its only source of power. Examples include access points, such as IP telephones, Ethernet hubs, wireless LAN stations, etc. PSE refers to power sourcing equipment, which provides power to a single link section. PSE main functions include searching the PD, optionally classifying the PD, supplying power to the link section only if the PD is detected, monitoring the power on the link section, and scaling power back to detect level when power is no longer requested or required. As the OmniSwitch 6850 Series switches fully support 10/100/1000 Ethernet connectivity, you may also attach non-PD equipment, such as computer workstations, printers, servers, etc. to the PoE ports. Important. Alcatel-Lucent recommends that PoE-enabled switches with attached IP telephones should have operational power supply redundancy at all times for 911 emergency requirements. In addition, both the switch and the power supply should be plugged into an Uninterruptible Power Source (UPS). Note. You can also monitor all chassis components and manage many chassis features, including Power over Ethernet, with WebView; Alcatel-Lucents embedded web-based device management application. WebView is an interactive and easy-to-use GUI that can be launched from the OmniVista or a web browser.

Power over Ethernet Specifications

IEEE Standards supported Default PoE administrative status Default PoE operational status OmniSwitch 6850 Series platforms supporting PoE Cable distances supported Total number of PoE-capable ports per switch Default amount of inline power allocated for each port Range of inline power allowed for each port PoE Current draw PoE Power supplied to port IEEE 802.3af DTE Power via MDI Enabled Disabled (PoE must be activated on a switch-by-switch basis via the lanpower start command) OmniSwitch 6850 Models designated with the letter P 100 meters Up to 48 15400 Milliwatts 3000-15400 Milliwatts Approximately 4.3 amps Default 15.4watts per port Configurable from 3watts to 15.4watts per port Using the 360watts P/S, the maximum available PoE power is 240 watts (less 1watt per port of overhead) per unit. Using the 510watts P/S, the maximum available PoE power is 390watts (less 1watt per port of overhead) per unit. Please refer to the Power Supply Specification Section for more details.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 127 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Power over Ethernet Defaults

PoE operational status Total power allocated to a port PoE Power supplied to port Disabled 15.4watts Default 15.4watts per port Configurable from 3watts to 15.4watts per port Using the 360watts P/S, the maximum available PoE power is 240 watts (less 1watt per port of overhead) per unit. Using the 510watts P/S, the maximum available PoE power is 390watts (less 1watt per port of overhead) per unit. Please refer to the Power Supply Specification Section for more details. Low Disabled Enabled

Power Priority level for a port The capacitor detection method Priority discount status

Port Priority Levels

As not all Powered Devices (PDs) connected to the switch have the same priority within a customer network setting, the OmniSwitch 6850 Series switches allow the user to specify priority levels on a port-by-port basis. Priority levels include low, high, and critical. The default priority level for a port is low. Low. This default value is used for port(s) that have low-priority devices attached. In the event of a power management issue, inline power to low-priority ports is interrupted first (i.e., before critical and high-priority ports). High. This value is used for port(s) that have important, but not mission-critical, devices attached. If other ports in the chassis have been configured as critical, inline power to high-priority ports is given second priority. Critical. This value is used for port(s) that have mission-critical devices attached, and therefore require top (i.e., critical) priority. In the event of a power management issue, inline power to critical ports is maintained as long as possible.

Capacitor Detection Method

By default, the PowerDsine capacitor detection method is disabled on an OmniSwitch 6850 Series switch. To enable it, use the lanpower capacitor-detection command by entering lanpower capacitor-detection followed by the slot number of the OmniSwitch 6850 Series and enable. Note. The capacitive detection method should only be enabled to support legacy IP phones. This feature is not compatible with IEEE specification 802.3af. Please contact your Alcatel-Lucent sales engineer or Customer Support representative to find out which Alcatel-Lucent IP phones models need capacitive detection enabled.

Understanding Priority Disconnect

The priority disconnect function differs from the port priority function in that it applies only to the addition of powered devices (PDs) in tight power budget conditions. Priority disconnect is used by the system software in determining whether an incoming PD will be granted or denied power when there are too few watts remaining in the PoE power budget for an additional device. For example, if there are only 2 watts available in the current PoE power budget and a user plugs a 3.5W powered device into a PoE port, the system software must determine whether the device will be powered on. Based on priority disconnect rules, in some cases one or more existing devices may be powered down in order to accommodate the incoming device. In other cases, the incoming device will be denied power. Priority disconnect rules involve the port priority status of an incoming device (i.e., low, high, and critical), as well as the ports physical port number (i.e., 124). Understanding priority disconnect rules is especially helpful in avoiding power budget deficits and the unintentional shutdown of mission-critical devices when PDs are being added in tight power budget conditions. Reminder. Priority disconnect applies only when there is inadequate power remaining in the power budget for an incoming device. By default, priority disconnect is enabled in the switchs system software. When priority disconnect is disabled and there is inadequate power in the budget for an additional device, power will be denied to any incoming PD, regardless of its port priority status (i.e., low, high, and critical) or physical port number (i.e., 124).

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 128 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Priority Disconnect is enabled; same Priority Level on All PD Ports Reminder. Priority disconnect examples are applicable only when there is inadequate power remaining to power an incoming device. When a PD is being connected to a port with the same priority level as all other ports in the slot, the physical port number is used to determine whether the incoming PD will be granted or denied power. Lower numbered ports receive higher priority than higher-numbered ports. In other words, a PD connected to Port 1 will have a higher power priority than a PD connected to Port 2; a PD connected to Port 23 will have a higher power priority than a PD connected to Port 24. In order to avoid a power budget deficit, another port in the slot is disconnected. In determining which port to power off, the system software disconnects the port with the highest physical port number. Priority Disconnect is enabled; Incoming PD Port has Highest Priority Level Reminder. Priority disconnect examples are applicable only when there is inadequate power remaining to power an incoming device. When a PD is being connected to a port with a higher priority level than all other ports in the slot, the incoming PD will automatically be granted power over the other devices, regardless of its physical port number. In order to avoid a power budget deficit, another port in the slot is disconnected. In determining which port to power off, the system software first selects the port with the lowest configured priority level. For example, if a critical priority device is being added to a slot in which five existing devices are attached to high priority ports and one device is attached to a low priority port, the low priority port is automatically disconnected, regardless of its physical port number. If all existing devices are attached to ports with the same lower priority level, the system software disconnects the port with both the lowest priority level and the highest physical port number. For example, if a critical priority device is being added to a slot in which six existing devices are attached to high priority ports, the high priority port with the highest physical port number is automatically disconnected. Priority Disconnect is enabled; Incoming PD Port has Lowest Priority Level Reminder. Priority disconnect examples are applicable only when there is inadequate power remaining to power an incoming device. When a PD is being connected to a port with a lower priority level than all other ports in the slot, the incoming PD will be denied power, regardless of its physical port number. Devices connected to other higher-priority ports will continue operating without interruption. Priority Disconnect is disabled Reminder. Priority disconnect examples are applicable only when there is inadequate power remaining to power an incoming device. When priority disconnect is disabled, power will be denied to any incoming PD, regardless of its port priority status (i.e., low, high, and critical) or physical port number (i.e., 124).

Monitoring Power over Ethernet via CLI

To monitor current PoE statistics and settings, use the show lanpower command. The command output displays a list of all current PoE-capable ports, along with the following information for each port: Maximum power allocated to the port, in Milliwatts Actual power used by the port Current port status Power priority status Power on/off status Aggregate slot and chassis management information is also displayed. This information includes: Maximum watts allocated to the corresponding slot Amount of power budget remaining that can be allocated for PoE modules Total amount of power remaining that can be allocated for additional switch functions

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 129 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Power Cords
Because the power cord is the power supplys main disconnect device, it should be plugged into an easily accessible outlet. In the event that your power cord is lost or damaged, refer to the specifications below.

Specifications
The power cord to be used with 115-Volt configuration is a minimum type SJT (SVT) 18/3, rated at 250Volts AC, 10 Amps with a maximum length of 15 feet. One end terminates in an IEC 320 attachment plug and the other end terminates in a NEMA 5-15P plugs. The power cord to be used with 230-Volt configuration is minimum type SJT (SVT) 18/3, rated 250 Volts AC, 10 Amps with a maximum length of 15 feet. One end terminates in an IEC 320 attachment plug and the other end terminates as required by the country where it will be installed. European cords must be Harmonized (HAR) type. DC-to-DC Power Cords For DC-to-DC connections please refer to the Hardware Users Manuals for additional guidelines and information. Refer to the information below for power plug types by region: Power Cord Types NEMA 5-15-P (US), C22.2, No. 42 (Canada) BS 1,363 CEE 7/7 JIS 8,303 AS 3,112 BS 546 CIE 2,316 SEV 1011 SRAF 1,962 / D816 / 87 AR1-10P

North America United Kingdom / Ireland Europe Japan Australia India Italy Switzerland / Liechtenstein Denmark / Greenland Argentina

Redundant AC Circuit Recommendation

If possible, it is recommended that each AC outlet reside on a separate circuit. With redundant AC, if a single circuit fails, the switchs remaining power supplies (on separate circuits) will likely be unaffected and can therefore continue operating. Note. The switch must have power supply redundancy for the redundant AC circuit to be effective.

Grounding the Chassis

The switch has two threaded holes for grounding screws located on the back of the chassis. These holes use 10-32 screws and are approximately one inch apart. These holes are surrounded by a small paint-free rectangular area, which provides metal-to-metal contact for a ground connection. Use this connector to supplement the ground provided by the AC power cord. To do so, install a Panduit Grounding Lug (type LCD8-10A-L) using 8AWG copper conductors to the paint-free rectangular area. Be sure to use a crimping tool.

Temperature Management
The operating temperature of your switch is an important factor in its overall operability. In order to avoid a temperaturerelated system failure, your switch must always run at an operating temperature between 0 and 45 C (32 to 113 F). To avoid chassis over-temperature conditions, follow these important guidelines: Be sure that your switch is installed in a well-ventilated environment. To ensure adequate airflow, allow at least six inches of clearance at the front and back of the chassis. In addition, leave at least two inches of clearance at the left and right sides. Be sure that blank cover panels are installed at empty slot positions at all times. Blank cover panels help regulate airflow and thus regulate the overall operating temperature in the switch. To check the switchs current temperature status, use the show temperature command.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 130 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

MTBF Calculation Standards and Requirements

MTBF Notes: One MTBF-Yr. = 8,760 MTBF-Hrs. MTBF Prediction was based on Bellcore Handbook Technical Reference TR-332, Issue 6, Method I, and Case 3. M.S.R. 5: Mission Success Rate (%) for 5 years (43,800 Hours) without failure. M.S.R. 1: Mission Success Rate (%) for 1 year (8,760 Hours) without failure. All MTBF calculations are performed at 25C Ground Benign 1. PURPOSE The purpose of this section is to specify the basic standards and requirements for the MTBF calculations of all the products of Alcatels Network Infrastructure Business Unit (NIBU). 2. RELIABILITY PREDICTION A reliability prediction is simply the analysis of parts and components in an effort to predict and calculate the rate at which an item will fail. Reliability predictions provide a quantitative basic for evaluating product reliability. A reliability prediction is one of the most common forms of reliability analyses for calculating failure rate and MTBF. 3. MTBF DEFINITION There are many forms of the MTBF definition. In general, MTBF (Mean Time Between Failures) is the mean value of the lengths of time between consecutive failures, under stated conditions, for a stated period in the life of a functional unit. A more simplified MTBF definition for reliability predictions can be stated as the average time (usually expressed in hours) that a component works without failure. 3.1 Limitations of Reliability Prediction Like all engineering models, the failure rate models that used for MTBF calculations, are approximations to reality. Thus, one should not treat a reliability prediction number for a product as an absolute prediction of its field failure rate. In general, higher MTBF correlates with fewer component failures, but an MTBF claim is not a guarantee of product reliability and does not represent a condition of warranty. It is generally agreed that these predictions can be very good when used for relative comparisons, such as comparing design alternatives, or comparing products. Note also that reliability predictions do not account for substandard quality control for purchased parts, bad workmanship, poor product level quality control, overstressed field operation, etc. 4. MTBF CALCULATION STANDARDS The two most popular MTBF calculation standards are Telcordia (Bellcore) and MIL-HDBK-217. The MTBF calculations of all the NIBU products, even for the industrial and military specifications products, are based on the Telcordia standard document number SR-332, Issue 1 (which is an update of the Bellcore Handbook Technical Reference TR-332, Issue 6), since the Telcordia models are specifically designed and oriented to focus on the telecommunications products. Furthermore, the Telcordia models are also widely accepted in the telecom market; they seem to give much more realistic results; they are much more up to date; they can handle larger gate count ICs much better; they are quicker and easier to use, since the Telcordia models require many less part parameters than the MIL-HDBK-217 models.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 131 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

5. MTBF CALCULATION REQUIREMENTS 5.1 Bill of Materials The Bill of Materials (BOMs) is normally used to calculate the MTBFs of all the NIBU products. 5.2 MTBF Calculations MTBF is a basic measure of reliability for repairable items. It can be described as the number of hours that pass before a component, assembly, or system fails. It is a commonly-used variable in reliability and maintainability analyses. MTBF can be calculated as the inverse of the failure rate for constant failure rate systems. For Example: If a component has a failure rate of 2 failures per million hours, the MTBF would be the inverse of that failure rate: MTBF = (1,000,000 hours) / (2 failures/million hours) = 500,000 hours Thus, for an assembly with multiple components, the MTBF is calculated as the inverse of all the failure rates, as follows: MTBF = 1 / (sum of all the part failure rates); or: MTBF = 1 / (FR1 + FR2 + FR3 + ............ FRn) Note: FR = Failure Rate For a combination of multiple assemblies in Serial M ode: MTBF (Combined) = 1 (1/MTBF1 + 1/MTBF2 + 1/MTBF3 + ..+1/MTBFn) To ease the complexity of the MTBF calculations, a reliability prediction program called RelCalc for Windows, Version 5.0BELL7 (Release 2004.1), produced by T-Cubed Systems, Inc. (http://www.t-cubed.com/), is used to calculate the MTBFs of all the NIBU products, with Telcordia SR-332, Issue 1, Method I (Parts Count), Case 3, Environment GB (Ground Benign), Correction Factor 1, 100% Duty Cycle, components Quality Level II and under an ambient temperature of 25C. 5.3 Minimum MTBF Expectation The minimum MTBF value for all NIBU products, including any module, unit or system is expected to be 43,800 hours (5 years). Thus: The minimum Mission Success Rate for 1 year (M.S.R. 1) = exp (-8760/43800) = 81.87% The minimum Mission Success Rate for 5 years (M.S.R. 5) = exp (-43800/43800) = 36.79% 5.4 MTBF Calculation Results A so called MTBF table is used to summarize the MTBF calculation results of all products. The MTBF table is periodically updated to include the additional MTBF calculation results of new products. After each update, it will be sent out to interested parties such as Engineering, Quality Assurance, Marketing and Sales departments. Beside the MTBF calculation results of each product, the MTBF table also displays other results such as backplanes, fans, power supplies, PCBAs, fiber optic transceivers, products with and without power supplies, products with and without fiber optic transceivers. 6. Additional Information 6.1 The History of the MTBF Standards For electronic components, the two most popular and widely accepted reliability prediction handbooks are MIL-HDBK-217 and Telcordia (Bellcore). These handbooks offer procedures for predicting electronic product reliability, providing a standard basis for comparing reliability numbers. 6.2 MIL-HDBK-217 The original reliability prediction handbook was MIL-HDBK-217, the Military Handbook for Reliability Prediction of Electronic Equipment. MIL-HDBK-217 (commonly referred to as 217) is published by the Department of Defense, based on work done by the Reliability Analysis Center and Rome Laboratory at Griffiss AFB, NY. The 217 handbook contains failure rate models for the various part types used in electronic systems, such as ICs, transistors, diodes, resistors, capacitors, relays, switches and connectors. These failure rate models are based on the best field data that could be obtained for a wide variety of parts and systems; this data is then analyzed and massaged, with many simplifying assumptions thrown in, to create usable models. The latest version of 217 is MIL-HDBK-217F, Notice 2 (217F2). A copy of MIL-HDBK-217F-2 can be obtained from any source that provides Mil Specs, Mil Standards, Mil Handbooks, etc.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 132 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

6.3 Telcordia (Bellcore) Bellcore was purchased by SAIC in 1997. The purchase agreement required Bellcore to change its name: Bellcore became Telcordia Technologies in 1999. However, people still continue to use the Bellcore name in their documentation. Note that Bellcore (Bell Communications Research, a spin-off of AT&T Bell Labs) was the research arm of the Bell Operating Companies. Bellcore previously used MIL-HDBK-217 for their reliability predictions, but found that 217 gave pessimistic numbers for its commercial quality products. A few years ago, Bellcore used 217 as a starting point, modified (and simplified) the models to better reflect their field experience, and developed the Bellcore reliability prediction procedure, which is applicable to commercial electronic products. A copy of the Telcordia document Reliability Prediction Procedure for Electronic Equipment (document number SR-332, Issue 1) can be obtained directly from Telcordia Customer Service in New Jersey. Many commercial electronic product companies, making products such as computers, telecommunications systems, medical systems, and power supplies, are now choosing to use the Bellcore handbook for their reliability predictions. 6.4 Failure Rate Unit Conversions Failure rate numbers can be expressed in many different units as shown in the following conversion equations. Note that the FITs (Failures In Time) unit is failures per billion hours, and that the MTBF is in hours. (Failures/million hours) = (1,000,000) / (MTBF) (Failures/million hours) = (0.001) * (FITs) (Failures/million hours) = (1000) * (failures/1000 hours) (Failures/million hours) = (10) * (%failures/1000 hours) (Failures/million hours) = (114.2) * (failures/year) (Failures/million hours) = (1.142) * (%failures/year) (FITs) = (1,000,000,000) / (MTBF) (FITs) = (1000) * (failures/million hours) (FITs) = (1,000,000) * (failures/1000 hours) (FITs) = (10,000) * (%failures/1000 hours) (FITs) = (114,200) * (failures/year) (FITs) = (1142) * (%failures/year) (MTBF) = (1,000,000) / (failures/million hours) (MTBF) = (1,000,000,000) / (FITs) 6.5 MTBF Mission Success Rate The Mission Success Rate (M.S.R.) is the probability that the circuit, including redundancy, will operate without failure for the mission time. For example, if the Mission Success Rate = 0.999405, then the circuit has a probability of 99.94% of working without a failure for the mission time duration. Assuming that failures occur randomly during the useful life of a product, they can be described as an exponential distribution. So the probability that a product will work for some time T without failure is given by: R (T) = exp (-T/MTBF) Thus, for a product with an MTBF of 250,000 hours, and an operating time of interest of 5 years (43,800 hours): R = exp (-43800/250000) = 0.839289 = 83.93% (Mission Success Rate for 5 years = 83.93%) This means that there is an 83.93% probability that the product will operate for the 5 years without a failure, or that 83.93% of the units in the field will still be working at the 5 year point. 6.6 Serial and Parallel Mode MTBF Calculations The following two typical model types are used to calculate the MTBFs of all the NIBU products: Serial Mode MTBF Calculation Parallel Mode MTBF Calculation

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 133 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

6.6.1 Serial Mode MTBF Calculation The MTBF calculation under serial mode requires all of the parts in the circuit to function for success. In other words, the whole assembly will be considered failed if only one single component failed. Under serial mode MTBF calculation, the MTBF calculation result usually goes lower with additional components. The serial mode is normally used to calculate the MTBFs of all the modules and systems, except redundancy configurations, with the following formula: MTBF (Combined) = 1 (1/MTBF1 + 1/MTBF2 + 1/MTBF3 ++ 1/MTBFn) 6.6.2 Parallel Mode MTBF Calculation The MTBF calculation under parallel mode requires only 1 of the parts in the circuit to function for success. The parallel mode is usually used to calculate the MTBFs of the units in redundancy mode, such as redundant power supplies or redundant chassis management modules (CMMs). Under parallel mode MTBF calculation, the MTBF calculation result usually goes higher with additional redundant units. There is no simple formula to calculate the MTBFs of the redundant modules or systems under parallel mode. A reliability prediction program such as RelCalc for Windows is used instead to perform the MTBF calculations under parallel mode. 6.7 MTBF and Other Related Terms 6.7.1 MTTF MTTF (Mean Time to Failures) is a basic measure of reliability for non-repairable systems items (such as fans). It is the mean time expected until the first failure of a piece of equipment. MTTF is a statistical value and is meant to be the mean over a long period of time and a large number of units. For constant failure rate systems, MTTF is the inverse of the failure rate. If the failure rate is in failures/millions of failure hours, MTTF = 1,000,000/Failure Rate for components with exponential distributions. Technically, MTBF should be used only in reference to repairable items, while MTTF should be used for non-repairable items. However, MTBF is commonly used for both repairable and non-repairable items. The MTBF figures can be used for this purpose. MTTF = 1 / (sum of all the part failure rates); or: MTTF = 1 / (FR1 + FR2 + FR3 + ............ FRn) Note: FR = Failure Rate MTTF = (1,000,000) / (failures/million hours) 6.7.2 MTTR (Mean Time to Repairs) for our systems depends on the failure. Our systems are designed to recover from simple failures, but our systems engineers can help our customers develop a fault tolerant network that would use a combination of local spares, distributed inventories and advanced replacements to optimize the availability rating.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 134 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

6.7.3 Availability Calculations Availability (Ai) is the probability that the system will be available when required, or the proportion of total time that the system is available for use. If the repair time is very small compared to the MTBF time, then the availability of the system can approach to 100%. Availability is typically specified in nines notation. For example: 3-nines availability corresponds to 99.9% availability. 5-nines availability corresponds to 99.999% availability. The following table shows the relationship of the availability and the corresponding percentage and downtime: Availability 1-nine 2-nines 3-nines 4-nines 5-nines 6-nines Availability Percentage 90% 99% 99.9% 99.99% 99.999% 99.9999% Down Time per Year 36.5 days/year 3.65 days/year 8.76 hours/year 52.56 minutes/year 5.26 minutes/year 31.54 seconds/year

The Availability can be calculated as: Ai = MTBF / (MTBF + MTTR) MTTR = Mean Time To Repair (average service or repair time in hours) Example: With MTBF = 100,000 hours and MTTR = 4 hours Ai = 100000 / (100000 + 4) = 0.999960001 99.99% (4-nines availability) With MTBF = 500,000 hours and MTTR = 4 hours Ai = 500000 / (500000 + 4) = 0.999992 99.999% (5-nines availability) Availability is calculated as: MTTF / (MTTF + MTTR) or MTBF / (MTBF + MTTR) Comment on 4 x 9s availability or 99.99% uptime carrier grade availability (Availability in % (ex: 100.00%)): To achieve the highest levels of availability there must be cooperative efforts between Alcatel-Lucent and the customer, this requires that in addition to device and network level capabilities, operational processes must also be in place across the many facets of the network hardware, software, applications, security, networking, backup systems, local spares and server farms. Network management must be designed to maintain availability with automated features to prevent and resolve problems, and incorporate security with ease of use to reduce human error and the associated downtime. 6.7.4 Spare Units Calculations The Mission Success Rate (M.S.R.) calculation should be used to determine the spare units that a customer should acquire: M.S.R (T) = exp (-T/MTBF) Example: With 100 units that had an MTBF = 100,000 hours M.S.R. for 1 year (8,760 hours) = exp (-8760/100000) = 91.61% 92% M.S.R. for 5 years (43,800 hours) = exp (-43800/100000) = 64.53% 65% This means that at the end of the first year, there is a probability that 92 units are still running with 8 units failed. Thus, the customer needs to acquire about 8 spare units for the first year. At the end of the 5th year, there is a probability that 65 units are still running with 35 units failed. Thus, the customer needs to get about 35 units for their replacement. However, some people prefer to use the following simpler method to calculate the spare units as an estimation figure: Spare units in a period = (number of units) * (period in hours) / (MTBF in hours) Example: With 100 units that had an MTBF = 100,000 hours Spare units in 1 year (8760 hours) = (100 units) * (8760 hours) / 100000 hours = 8.76 units 9 units Spare units in 5 years (43,800 hours) = (100 units) * (43800 hours) / 100000 hours = 43.80 units 44 units OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 135 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Family
OS6850-24 OS6850-24D OS6850-24L OS6850-24LD

Module Name
OS6850-24-Fans PS-126W-AC (126W AC Pwr Supply) PS-120W-DC (120W DC Pwr Supply) OS6850-24-LED-USB-PCBA OS6850-24-4SFP-PCBA OS6850-24-Main-PCBA OS6850-24 (No PS. No MiniGBIC) OS6850-24+PS-126W-AC (No MiniGBIC) OS6850-24+2(PS-126W-AC)(No MiniGBIC) OS6850-24+PS-120W-DC (No MiniGBIC) OS6850-24+2(PS-120W-DC)(No MiniGBIC) OS6850-24+PS-126W-AC +PS-120W-DC (No MiniGBIC) MiniGBIC-SX (Multimode Trans.) MiniGBIC-LX (Single mode Trans.) MiniGBIC-LH-70 (Long Reach Trans.) OS6850-24+PS-126W-AC+4(MiniGBIC-SX) OS6850-24+PS-126W-AC+4(MiniGBIC-LX) OS6850-24+PS-126W-AC+4(MiniGBIC-LH-70) OS6850-24+2(PS-126W-AC)+4(MiniGBIC-SX) OS6850-24+2(PS-126W-AC)+4(MiniGBIC-LX) OS6850-24+2(PS-126W-AC)+4(MiniGBIC-LH-70) OS6850-24+PS-120W-DC+4(MiniGBIC-SX) OS6850-24+PS-120W-DC+4(MiniGBIC-LX) OS6850-24+PS-120W-DC+4(MiniGBIC-LH-70) OS6850-24+2(PS-120W-DC)+4(MiniGBIC-SX) OS6850-24+2(PS-120W-DC)+4(MiniGBIC-LX) OS6850-24+2(PS-120W-DC)+4(MiniGBIC-LH-70) OS6850-24+PS-126W-AC+ PS-120W-DC +4(MiniGBIC-SX) OS6850-24+PS-126W-AC+ PS-120W-DC +4(MiniGBIC-LX) OS6850-24+PS-126W-AC+ PS-120W-DC +4(MiniGBIC-LH-70)

MTBF-Hr.
603,696 1,259,604 1,501,224 36,813,836 39,939,134 402,101 238,345 200,421 227,923 205,688 230,468 229,285 5,780,347 6,578,947 2,857,143 176,010 178,651 156,507 197,584 200,836 173,799 180,059 182,825 159,700 199,338 202,668 175,050 198,525 201,819 174,472

MTBF-Yr.
68.92 143.79 171.37 4,202.49 4,559.26 45.90 27.21 22.88 26.02 23.48 26.31 26.17 659.86 751.02 326.16 20.09 20.39 17.87 22.56 22.93 19.84 20.55 20.87 18.23 22.76 23.14 19.98 22.66 23.04 19.92

M.S.R.5

M.S.R.1

FFB0412VHN-F00 (Delta) YM-1131DA (3Y Pwr Tec) D48S1210-3 A (Delta)

80% 83% 81% 83% 83%

96% 96% 96% 96% 96%

FTRJ-8519-7D (Finisar) FTRJ-1319-7D (Finisar) A10P-8063-STA-H (Avrio) 78% 95% 78% 95% 76% 95% 81% 96% 81% 96% 78% 95% 78% 95% 79% 95% 76% 95% 81% 96% 81% 96% 78% 95% 81% 96% 81% 78% 96% 95%

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 136 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Family
OS6850-24X OS6850-24XD

Module Name
OS6850-24X-Fans PS-126W-AC (126W AC Pwr Supply) PS-120W-DC (120W DC Pwr Supply) OS6850-24X-LED-USB-PCBA OS6850-24X-4SFP-PCBA OS6850-24X-Main-PCBA OS6850-24X (No PS. No MiniGBIC) OS6850-24X+PS-126W-AC (No MiniGBIC) OS6850-24X+2(PS-126W-AC)(No MiniGBIC) OS6850-24X+PS-120W-DC (No MiniGBIC) OS6850-24X+2(PS-120W-DC)(No MiniGBIC) OS6850-24X+PS-126W-AC +PS-120W-DC (No MiniGBIC) MiniGBIC-SX (Multimode Trans.) MiniGBIC-LX (Single mode Trans.) MiniGBIC-LH-70 (Long Reach Trans.) 10G-XFP-SR (Multimode XFP Trans.) 10G-XFP-LR (Single mode XFP Trans.) OS6850-24X+PS-126W-AC+4(MiniGBIC-SX) +2(10G-XFP-SR) OS6850-24X+PS-126W-AC+4(MiniGBIC-LX) +2(10G-XFP-SR) OS6850-24X+PS-126W-AC+4(MiniGBIC-LH-70) +2(10G-XFP-SR) OS6850-24X+PS-126W-AC+4(MiniGBIC-SX) +2(10G-XFP-LR) OS6850-24X+PS-126W-AC+4(MiniGBIC-LX) +2(10G-XFP-LR) OS6850-24X+PS-126W-AC+4(MiniGBIC-LH-70) +2(10G-XFP-LR) OS6850-24X+2(PS-126W-AC)+4(MiniGBIC-SX) +2(10G-XFP-SR) OS6850-24X+2(PS-126W-AC)+4(MiniGBIC-LX) +2(10G-XFP-SR) OS6850-24X+2(PS-126W-AC) +4(MiniGBIC-LH-70) +2(10G-XFP-SR) OS6850-24X+2(PS-126W-AC)+4(MiniGBIC-SX) +2(10G-XFP-LR) OS6850-24X+2(PS-126W-AC)+4(MiniGBIC-LX) +2(10G-XFP-LR) OS6850-24X+2(PS-126W-AC) +4(MiniGBIC-LH-70) +2(10G-XFP-LR) OS6850-24X+PS-120W-DC+4(MiniGBIC-SX) +2(10G-XFP-SR) OS6850-24X+PS-120W-DC+4(MiniGBIC-LX) +2(10G-XFP-SR) OS6850-24X+PS-120W-DC+4(MiniGBIC-LH-70) +2(10G-XFP-SR) OS6850-24X+PS-120W-DC+4(MiniGBIC-SX) +2(10G-XFP-LR) OS6850-24X+PS-120W-DC+4(MiniGBIC-LX) +2(10G-XFP-LR) OS6850-24X+PS-120W-DC+4(MiniGBIC-LH-70) +2(10G-XFP-LR) OS6850-24X+2(PS-120W-DC)+4(MiniGBIC-SX) +2(10G-XFP-SR) OS6850-24X+2(PS-120W-DC)+4(MiniGBIC-LX) +2(10G-XFP-SR)

MTBF-Hr.
603,696 1,259,604 1,501,224 36,813,836 38,764,649 368,556 226,105 191,695 217,007 196,509 219,248 218,209 5,780,347 6,578,947 2,857,143 6,427,590 4,944,180 160,778 162,979 144,347 158,400 160,536 142,427 178,972 181,646 159,184

MTBF-Yr.
68.92 143.79 171.37 4,202.49 4,425.19 42.07 25.81 21.88 24.77 22.43 25.03 24.91 659.86 751.02 326.16 733.74 564.40 18.35 18.60 16.48 18.08 18.33 16.26 20.43 20.74 18.17

M.S.R.5

M.S.R.1

FFB0412VHN-F00 (Delta) YM-1131DA (3Y Pwr Tec) D48S1210-3 A (Delta)

80% 82% 80% 82% 82%

96% 96% 96% 96% 96%

FTRJ-8519-7D (Finisar) FTRJ-1319-7D (Finisar) A10P-8063-STA-H (Avrio) TXN181070850X17 (Intel) TXN181072013X58 (Intel) 76% 95% 76% 74% 76% 76% 74% 79% 79% 76% 95% 94% 95% 95% 94% 95% 95% 95%

176,090 178,679 156,892

20.10 20.40 17.91

78% 79% 76%

95% 95% 95%

164,150 166,445 147,059 161,672 163,898 145,067 180,325 183,053

18.74 19.00 16.79 18.46 18.71 16.56 20.59 20.90

77% 77% 74% 76% 77% 74% 79% 79%

95% 95% 94% 95% 95% 94% 95% 95%

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 137 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850-24X+2(PS-120W-DC) +4(MiniGBIC-LH-70) +2(10G-XFP-SR) OS6850-24X+2(PS-120W-DC)+4(MiniGBIC-SX) +2(10G-XFP-LR) OS6850-24X+2(PS-120W-DC)+4(MiniGBIC-LX) +2(10G-XFP-LR) OS6850-24X+2(PS-120W-DC) +4(MiniGBIC-LH-70) +2(10G-XFP-LR) OS6850-24X+PS-126W-AC+ PS-120W-DC +4(MiniGBIC-SX) +2(10G-XFP-SR) OS6850-24X+PS-126W-AC+ PS-120W-DC +4(MiniGBIC-LX) +2(10G-XFP-SR) OS6850-24X+PS-126W-AC+ PS-120W-DC +4(MiniGBIC-LH-70) +2(10G-XFP-SR) OS6850-24X+PS-126W-AC+ PS-120W-DC +4(MiniGBIC-SX) +2(10G-XFP-LR) OS6850-24X+PS-126W-AC+ PS-120W-DC +4(MiniGBIC-LX) +2(10G-XFP-LR) OS6850-24X+PS-126W-AC+ PS-120W-DC +4(MiniGBIC-LH-70) +2(10G-XFP-LR)

160,175

18.28

76%

95%

177,387 180,027 157,846

20.25 20.55 18.02

78% 79% 76%

95% 95% 95%

179,699

20.51

79%

95%

182,401

20.82

79%

95%

159,715

18.23

76%

95%

176,786

20.18

78%

95%

179,403

20.48

79%

95%

157,404

17.97

76%

95%

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 138 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Family
OS6850-P24 OS6850-P24H OS6850-P24L OS6850-P24LH

Module Name
OS6850-P24-Fans PS-510W-AC (510W AC Pwr Supply) PS-360W-AC (360W AC Pwr Supply) OS6850-P24-LED-USB-PCBA OS6850-P24-4SFP-PCBA OS6850-P24-POE-PCBA OS6850-P24-Main-PCBA OS6850-P24 (No PS. No MiniGBIC) OS6850-P24+PS-510W-AC (No MiniGBIC) OS6850-P24+2(PS-510W-AC)(No MiniGBIC) OS6850-P24+PS-360W-AC (No MiniGBIC) OS6850-P24+2(PS-360W-AC)(No MiniGBIC) MiniGBIC-SX (Multimode Trans.) MiniGBIC-LX (Single mode Trans.) MiniGBIC-LH-70 (Long Reach Trans.) OS6850-P24+PS-510W-AC+4(MiniGBIC-SX) OS6850-P24+PS-510W-AC+4(MiniGBIC-LX) OS6850-P24+PS-510W-AC+4(MiniGBIC-LH-70) OS6850-P24+2(PS-510W-AC)+4(MiniGBIC-SX) OS6850-P24+2(PS-510W-AC)+4(MiniGBIC-LX) OS6850-P24+2(PS-510W-AC)+ 4(MiniGBIC-LH-70) OS6850-P24+PS-360W-AC+4(MiniGBIC-SX) OS6850-P24+PS-360W-AC+4(MiniGBIC-LX) OS6850-P24+PS-360W-AC+4(MiniGBIC-LH-70) OS6850-P24+2(PS-360W-AC)+4(MiniGBIC-SX) OS6850-P24+2(PS-360W-AC)+4(MiniGBIC-LX) OS6850-P24+2(PS-360W-AC)+ 4(MiniGBIC-LH-70)

MTBF-Hr.
603,696 406,835 504,490 36,813,836 39,939,134 2,967,641 402,101 220,625 143,050 180,201 153,497 189,262 5,780,347 6,578,947 2,857,143 130,165 131,604 119,181 161,673 163,725 146,154 138,758 140,395 126,346 168,661 170,929 151,630

MTBF-Yr.
68.92 46.44 57.59 4,202.49 4,559.26 338.77 45.90 25.19 16.33 20.57 17.52 21.61 659.86 751.02 326.16 14.86 15.02 13.61 18.46 18.69 16.68 15.84 16.03 14.42 19.25 19.51 17.31

M.S.R.5

M.S.R.1

FFB0412VHN-F00 (Delta) YM-2511BA (3Y Pwr Tec) YM-2361BA (3Y Pwr Tec)

74% 94% 81% 96% 75% 94% 81% 96% FTRJ-8519-7D (Finisar) FTRJ-1319-7D (Finisar) A10P-8063-STA-H (Avrio) 71% 93% 72% 94% 69% 93% 79% 95% 79% 96% 76% 95% 73% 73% 71% 79% 79% 77% 94% 94% 93% 95% 96% 95%

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 139 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Family
OS6850-P24X OS6850-P24XH

Module Name
OS6850-P24X-Fans PS-510W-AC (510W AC Pwr Supply) PS-360W-AC (360W AC Pwr Supply) OS6850-P24X-LED-USB-PCBA OS6850-P24X-4SFP-PCBA OS6850-P24X-POE-PCBA OS6850-P24X-Main-PCBA OS6850-P24X (No PS. No MiniGBIC) OS6850-P24X+PS-510W-AC (No MiniGBIC) OS6850-P24X+2(PS-510W-AC)(No MiniGBIC) OS6850-P24X+PS-360W-AC (No MiniGBIC) OS6850-P24X+2(PS-360W-AC)(No MiniGBIC) MiniGBIC-SX (Multimode Trans.) MiniGBIC-LX (Single mode Trans.) MiniGBIC-LH-70 (Long Reach Trans.) 10G-XFP-SR (Multimode XFP Trans.) 10G-XFP-LR (Single mode XFP Trans.) OS6850-P24X+PS-510W-AC+4(MiniGBIC-SX) +2(10G-XFP-SR) OS6850-P24X+PS-510W-AC+4(MiniGBIC-LX) +2(10G-XFP-SR) OS6850-P24X+PS-510W-AC+4(MiniGBIC-LH-70) +2(10G-XFP-SR) OS6850-P24X+PS-510W-AC+4(MiniGBIC-SX) +2(10G-XFP-LR) OS6850-P24X+PS-510W-AC+4(MiniGBIC-LX) +2(10G-XFP-LR) OS6850-P24X+PS-510W-AC+4(MiniGBIC-LH-70) +2(10G-XFP-LR) OS6850-P24X+2(PS-510W-AC)+4(MiniGBIC-SX) +2(10G-XFP-SR) OS6850-P24X+2(PS-510W-AC)+4(MiniGBIC-LX) +2(10G-XFP-SR) OS6850-P24X+2(PS-510W-AC)+ 4(MiniGBIC-LH-70) +2(10G-XFP-SR) OS6850-P24X+2(PS-510W-AC)+4(MiniGBIC-SX) +2(10G-XFP-LR) OS6850-P24X+2(PS-510W-AC)+4(MiniGBIC-LX) +2(10G-XFP-LR) OS6850-P24X+2(PS-510W-AC)+ 4(MiniGBIC-LH-70) +2(10G-XFP-LR) OS6850-P24X+PS-360W-AC+4(MiniGBIC-SX) +2(10G-XFP-SR) OS6850-P24X+PS-360W-AC+4(MiniGBIC-LX) +2(10G-XFP-SR) OS6850-P24X+PS-360W-AC+4(MiniGBIC-LH-70) +2(10G-XFP-SR) OS6850-P24X+PS-360W-AC+4(MiniGBIC-SX) +2(10G-XFP-LR) OS6850-P24X+PS-360W-AC+4(MiniGBIC-LX) +2(10G-XFP-LR) OS6850-P24X+PS-360W-AC+4(MiniGBIC-LH-70) +2(10G-XFP-LR)

MTBF-Hr.
603,696 406,835 504,490 36,813,836 38,764,649 3,228,883 368,556 211,308 139,074 174,448 148,929 182,834 5,780,347 6,578,947 2,857,143 6,427,590 4,944,180 122,047 123,311 112,340 120,672 121,908 111,174 150,178 151,958 136,624

MTBF-Yr.
68.92 46.44 57.59 4,202.49 4,425.19 368.59 42.07 24.12 15.88 19.91 17.00 20.87 659.86 751.02 326.16 733.74 564.40 13.93 14.08 12.82 13.78 13.92 12.69 17.14 17.35 15.60

M.S.R.5

M.S.R.1

FFB0412VHN-F00 (Delta) YM-2511BA (3Y Pwr Tec) YM-2361BA (3Y Pwr Tec)

73% 94% 80% 96% 75% 94% 81% 96% FTRJ-8519-7D (Finisar) FTRJ-1319-7D (Finisar) A10P-8063-STA-H (Avrio) TXN181070850X17 (Intel) TXN181072013X58 (Intel) 70% 93% 70% 68% 70% 70% 67% 77% 77% 75% 93% 92% 93% 93% 92% 95% 95% 94%

148,245 149,982 135,010

16.92 17.12 15.41

77% 77% 74%

95% 95% 94%

129,571 130,997 118,683 128,022 129,414 117,383

14.79 14.95 13.55 14.61 14.77 13.40

71% 72% 69% 71% 71% 69%

93% 94% 93% 93% 93% 93%

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 140 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850-P24X+2(PS-360W-AC)+4(MiniGBIC-SX) +2(10G-XFP-SR) OS6850-P24X+2(PS-360W-AC)+4(MiniGBIC-LX) +2(10G-XFP-SR) OS6850-P24X+2(PS-360W-AC)+ 4(MiniGBIC-LH-70) +2(10G-XFP-SR) OS6850-P24X+2(PS-360W-AC)+4(MiniGBIC-SX) +2(10G-XFP-LR) OS6850-P24X+2(PS-360W-AC)+4(MiniGBIC-LX) +2(10G-XFP-LR) OS6850-P24X+2(PS-360W-AC)+ 4(MiniGBIC-LH-70) +2(10G-XFP-LR)

156,026 157,976 141,270

17.81 18.03 16.13

77% 78% 75%

95% 95% 94%

153,913 155,812 139,523

17.57 17.79 15.93

77% 77% 75%

95% 95% 94%

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 141 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Family
OS6850-48 OS6850-48D OS6850-48L OS6850-48LD

Module Name
OS6850-48-Fans PS-126W-AC (126W AC Pwr Supply) PS-120W-DC (120W DC Pwr Supply) OS6850-48-LED-USB-PCBA OS6850-48-4SFP-PCBA OS6850-48-Main-PCBA OS6850-48 (No PS. No MiniGBIC) OS6850-48+PS-126W-AC (No MiniGBIC) OS6850-48+2(PS-126W-AC)(No MiniGBIC) OS6850-48+PS-120W-DC (No MiniGBIC) OS6850-48+2(PS-120W-DC)(No MiniGBIC) OS6850-48+PS-126W-AC +PS-120W-DC (No MiniGBIC) MiniGBIC-SX (Multimode Trans.) MiniGBIC-LX (Single mode Trans.) MiniGBIC-LH-70 (Long Reach Trans.) OS6850-48+PS-126W-AC+4(MiniGBIC-SX) OS6850-48+PS-126W-AC+4(MiniGBIC-LX) OS6850-48+PS-126W-AC+4(MiniGBIC-LH-70) OS6850-48+2(PS-126W-AC)+4(MiniGBIC-SX) OS6850-48+2(PS-126W-AC)+4(MiniGBIC-LX) OS6850-48+2(PS-126W-AC)+4(MiniGBIC-LH-70) OS6850-48+PS-120W-DC+4(MiniGBIC-SX) OS6850-48+PS-120W-DC+4(MiniGBIC-LX) OS6850-48+PS-120W-DC+4(MiniGBIC-LH-70) OS6850-48+2(PS-120W-DC)+4(MiniGBIC-SX) OS6850-48+2(PS-120W-DC)+4(MiniGBIC-LX) OS6850-48+2(PS-120W-DC)+4(MiniGBIC-LH-70) OS6850-48+PS-126W-AC+ PS-120W-DC +4(MiniGBIC-SX) OS6850-48+PS-126W-AC+ PS-120W-DC +4(MiniGBIC-LX) OS6850-48+PS-126W-AC+ PS-120W-DC +4(MiniGBIC-LH-70)

MTBF-Hr.
603,696 1,259,604 1,501,224 17,928,344 39,939,134 275,125 187,022 162,844 181,482 166,304 182,886 182,236 5,780,347 6,578,947 2,857,143 146,352 148,173 132,611 161,582 163,765 145,238 149,141 151,033 134,897 162,614 164,834 146,016 162,137 164,340 145,656

MTBF-Yr.
68.92 143.79 171.37 2,046.61 4,559.26 31.41 21.35 18.59 20.72 18.98 20.88 20.80 659.86 751.02 326.16 16.71 16.91 15.14 18.45 18.69 16.58 17.03 17.24 15.40 18.56 18.82 16.67 18.51 18.76 16.63

M.S.R.5

M.S.R.1

FFB0412VHN-F00 (Delta) YM-1131DA (3Y Pwr Tec) D48S1210-3 A (Delta)

76% 79% 77% 79% 79%

95% 95% 95% 95% 95%

FTRJ-8519-7D (Finisar) FTRJ-1319-7D (Finisar) A10P-8063-STA-H (Avrio) 74% 94% 74% 94% 72% 94% 77% 95% 77% 95% 74% 94% 75% 94% 75% 94% 72% 94% 77% 95% 77% 95% 74% 94% 77% 95% 77% 74% 95% 94%

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 142 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Family
OS6850-48X OS6850-48XD

Module Name
OS6850-48X-Fans PS-126W-AC (126W AC Pwr Supply) PS-120W-DC (120W DC Pwr Supply) OS6850-48X-LED-USB-PCBA OS6850-48X-Main-PCBA OS6850-48X (No PS. No XFP) OS6850-48X+PS-126W-AC (No XFP) OS6850-48X+2(PS-126W-AC)(No XFP) OS6850-48X+PS-120W-DC (No XFP) OS6850-48X+2(PS-120W-DC)(No XFP) OS6850-48X+PS-126W-AC +PS-120W-DC (No XFP) 10G-XFP-SR (Multimode XFP Trans.) 10G-XFP-LR (Single mode XFP Trans.) OS6850-48X+PS-126W-AC+2(10G-XFP-SR) OS6850-48X+PS-126W-AC+2(10G-XFP-LR) OS6850-48X+2(PS-126W-AC)+ 2(10G-XFP-SR) OS6850-48X+2(PS-126W-AC)+ 2(10G-XFP-LR) OS6850-48X+PS-120W-DC+2(10G-XFP-SR) OS6850-48X+PS-120W-DC+2(10G-XFP-LR) OS6850-48X+2(PS-120W-DC)+ 2(10G-XFP-SR) OS6850-48X+2(PS-120W-DC)+ 2(10G-XFP-LR) OS6850-48X+PS-126W-AC+ PS-120W-DC +2(10G-XFP-SR) OS6850-48X+PS-126W-AC+ PS-120W-DC +2(10G-XFP-LR)

MTBF-Hr.
603,696 1,259,604 1,501,224 36,813,836 237,720 169,772 149,608 165,487 152,523 166,585 166,078 6,427,590 4,944,180 142,953 141,070 157,519 155,275 145,613 143,660 158,483 156,203 158,036 155,772

MTBF-Yr.
68.92 143.79 171.37 4,202.49 27.14 19.38 17.08 18.89 17.41 19.02 18.96 733.74 564.40 16.32 16.10 17.98 17.73 16.62 16.40 18.09 17.83 18.04 17.78

M.S.R.5

M.S.R.1

FFB0412VHN-F00 (Delta) YM-1131DA (3Y Pwr Tec) D48S1210-3 A (Delta)

75% 77% 75% 77% 77%

94% 95% 94% 95% 95%

TXN181070850X17 (Intel) TXN181072013X58 (Intel) 74% 94% 73% 94% 76% 95% 76% 95% 74% 94% 74% 94% 76% 95% 76% 95% 76% 95% 76% 95%

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 143 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Family
OS6850-P48 OS6850-P48H OS6850-P48L OS6850-P48LH

Module Name
OS6850-P48-Fans PS-510W-AC (510W AC Pwr Supply) PS-360W-AC (360W AC Pwr Supply) OS6850-P48-LED-USB-PCBA OS6850-P48-POE-PCBA OS6850-P48-Main-PCBA OS6850-P48 (No PS. No MiniGBIC) OS6850-P48+PS-510W-AC (No MiniGBIC) OS6850-P48+2(PS-510W-AC)(No MiniGBIC) OS6850-P48+PS-360W-AC (No MiniGBIC) OS6850-P48+2(PS-360W-AC)(No MiniGBIC) MiniGBIC-SX (Multimode Trans.) MiniGBIC-LX (Single mode Trans.) MiniGBIC-LH-70 (Long Reach Trans.) OS6850-P48+PS-510W-AC+4(MiniGBIC-SX) OS6850-P48+PS-510W-AC+4(MiniGBIC-LX) OS6850-P48+PS-510W-AC+4(MiniGBIC-LH-70) OS6850-P48+2(PS-510W-AC)+4(MiniGBIC-SX) OS6850-P48+2(PS-510W-AC)+4(MiniGBIC-LX) OS6850-P48+2(PS-510W-AC)+ 4(MiniGBIC-LH-70) OS6850-P48+PS-360W-AC+4(MiniGBIC-SX) OS6850-P48+PS-360W-AC+4(MiniGBIC-LX) OS6850-P48+PS-360W-AC+4(MiniGBIC-LH-70) OS6850-P48+2(PS-360W-AC)+4(MiniGBIC-SX) OS6850-P48+2(PS-360W-AC)+4(MiniGBIC-LX) OS6850-P48+2(PS-360W-AC)+ 4(MiniGBIC-LH-70)

MTBF-Hr.
603,696 406,835 504,490 17,928,344 2,175,812 275,125 172,219 120,999 148,704 128,390 154,414 5,780,347 6,578,947 2,857,143 111,650 112,707 103,471 135,669 137,133 124,433 117,914 119,094 108,829 140,236 141,822 128,127

MTBF-Yr.
68.92 46.44 57.59 2,046.61 248.38 31.41 19.66 13.81 16.98 14.66 17.63 659.86 751.02 326.16 12.75 12.87 11.81 15.49 15.65 14.20 13.46 13.60 12.42 16.01 16.19 14.63

M.S.R.5

M.S.R.1

FFB0412VHN-F00 (Delta) YM-2511BA (3Y Pwr Tec) YM-2361BA (3Y Pwr Tec)

70% 93% 77% 95% 71% 93% 77% 95% FTRJ-8519-7D (Finisar) FTRJ-1319-7D (Finisar) A10P-8063-STA-H (Avrio) 68% 92% 68% 93% 65% 92% 74% 94% 75% 94% 72% 94% 69% 69% 67% 75% 75% 72% 93% 93% 92% 94% 95% 94%

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 144 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Family
OS6850-P48X OS6850-P48XH

Module Name
OS6850-P48X-Fans PS-510W-AC (510W AC Pwr Supply) PS-360W-AC (360W AC Pwr Supply) OS6850-P48X-LED-USB-PCBA OS6850-P48X-POE-PCBA OS6850-P48X-Main-PCBA OS6850-P48X (No PS. No XFP) OS6850-P48X+PS-510W-AC (No XFP) OS6850-P48X+2(PS-510W-AC)(No XFP) OS6850-P48X+PS-360W-AC (No XFP) OS6850-P48X+2(PS-360W-AC)(No XFP) 10G-XFP-SR (Multimode XFP Trans.) 10G-XFP-LR (Single mode XFP Trans.) OS6850-P48X+PS-510W-AC+2(10G-XFP-SR) OS6850-P48X+PS-510W-AC+2(10G-XFP-LR) OS6850-P48X+2(PS-510W-AC)+ 2(10G-XFP-SR) OS6850-P48X+2(PS-510W-AC)+ 2(10G-XFP-LR) OS6850-P48X+PS-360W-AC+2(10G-XFP-SR) OS6850-P48X+PS-360W-AC+2(10G-XFP-LR) OS6850-P48X+2(PS-360W-AC)+ 2(10G-XFP-SR) OS6850-P48X+2(PS-360W-AC)+ 2(10G-XFP-LR)

MTBF-Hr.
603,696 406,835 504,490 36,813,836 2,090,730 237,720 157,021 113,294 137,947 119,750 142,704 6,427,590 4,944,180 109,437 108,330 132,612 131,088 115,448 114,217 136,932 135,287

MTBF-Yr.
68.92 46.44 57.59 4,202.49 238.67 27.14 17.92 12.93 15.75 13.67 16.29 733.74 564.40 12.49 12.37 15.14 14.96 13.18 13.04 15.63 15.44

M.S.R.5

M.S.R.1

FFB0412VHN-F00 (Delta) YM-2511BA (3Y Pwr Tec) YM-2361BA (3Y Pwr Tec)

68% 93% 75% 95% 69% 93% 75% 95% TXN181070850X17 (Intel) TXN181072013X58 (Intel) 67% 92% 67% 92% 74% 94% 74% 94% 68% 93% 68% 93% 74% 94% 74% 94%

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 145 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Family
OS6850-U24X OS6850-U24XD

Module Name
OS6850-U24X-Fans PS-126W-AC (126W AC Pwr Supply) PS-120W-DC (120W DC Pwr Supply) OS6850-U24X-Daughter-PCBA OS6850-U24X-Main-PCBA OS6850-U24X (No Power Supply, No MiniGBIC, No XFP) OS6850-U24X+PS-126W-AC (No MiniGBIC, No XFP) OS6850-U24X+2(PS-126W-AC) (No MiniGBIC, No XFP) OS6850-U24X+PS-120W-DC (No MiniGBIC, No XFP) OS6850-U24X+2 (PS-120W-DC (No MiniGBIC, No XFP) OS6850-U24X+PS-126W-AC +PS-120W-DC (No MiniGBIC, No XFP) MiniGBIC-SX (Multimode Trans.) MiniGBIC-LX (Single mode Trans.) MiniGBIC-LH-70 (Long Reach Trans.) 10G-XFP-SR (Multimode XFP Trans.) 10G-XFP-LR (Single mode XFP Trans.) OS6850-U24X+PS-126W-AC+24(MiniGBIC-SX) (No XFP) OS6850-U24X+PS-126W-AC+24(MiniGBIC-LX) (No XFP) OS6850-U24X+PS-126W-AC+ 24(MiniGBIC-LH-70) (No XFP) OS6850-U24X+PS-126W-AC+24(MiniGBIC-SX) +2(10G-XFP-SR) OS6850-U24X+PS-126W-AC+24(MiniGBIC-SX) +2(10G-XFP-LR) OS6850-U24X+PS-126W-AC+24(MiniGBIC-LX) +2(10G-XFP-SR) OS6850-U24X+PS-126W-AC+24(MiniGBIC-LX) +2(10G-XFP-LR) OS6850-U24X+PS-126W-AC+ 24(MiniGBIC-LH-70) +2(10G-XFP-SR) OS6850-U24X+PS-126W-AC+ 24(MiniGBIC-LH-70) +2(10G-XFP-LR) OS6850-U24X+2(PS-126W-AC)+ 24(MiniGBIC-SX) (No XFP) OS6850-U24X+2(PS-126W-AC)+ 24(MiniGBIC-LX) (No XFP) OS6850-U24X+2(PS-126W-AC)+ 24(MiniGBIC-LH-70) (No XFP) OS6850-U24X+2(PS-126W-AC)+ 24(MiniGBIC-SX)+2(10G-XFP-SR) OS6850-U24X+2(PS-126W-AC)+ 24(MiniGBIC-SX)+2(10G-XFP-LR) OS6850-U24X+2(PS-126W-AC)+ 24(MiniGBIC-LX)+2(10G-XFP-SR) OS6850-U24X+2(PS-126W-AC)+ 24(MiniGBIC-LX)+2(10G-XFP-LR) OS6850-U24X+2(PS-126W-AC)+ 24(MiniGBIC-LH-70)+2(10G-XFP-SR)

MTBF-Hr.
603,696 1,259,604 1,501,224 30,986,420 426,686 247,993 207,199 236,457 212,834 239,255 237,953 5,780,347 6,578,947 2,857,143 6,427,590 4,944,180 111,380 118,004 75,607 107,649 106,578 113,825 112,628 73,869 73,363 120,426 128,109 79,889 116,123 114,890 123,255 121,869 77,962

MTBF-Yr.
68.92 143.79 171.37 3,537.26 48.71 28.31 23.65 26.99 24.3 27.31 27.16 659.86 751.02 326.16 733.74 564.40 12.71 13.47 8.63 12.29 12.17 12.99 12.86 8.43 8.37 13.75 14.62 9.12 13.26 13.12 14.07 13.91 8.90

M.S.R.5

M.S.R.1

FFB0412VHN-F00 (Delta) YM-1131DA (3Y Pwr Tec) D48S1210-3 A (Delta)

FTRJ-8519-7D (Finisar) FTRJ-1319-7D (Finisar) A10P-8063-STA-H (Avrio) TXN181070850X17 (Intel) TXN181072013X58 (Intel) 67% 92% 69% 56% 675% 66% 68% 68% 55% 55% 70% 71% 58% 69% 69% 70% 70% 57% 93% 89% 92% 92% 93% 93% 89% 89% 93% 93% 90% 93% 93% 93% 93% 89%

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 146 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850-U24X+2(PS-126W-AC)+24(MiniGBIC-LH-70)+ 2(10G-XFP-LR) OS6850-U24X+PS-120W-DC+24(MiniGBIC-SX)(No XFP) OS6850-U24X+PS-120W-DC+24(MiniGBIC-LX)(No XFP) OS6850-U24X+PS-120W-DC+24(MiniGBIC-LH-70)(No XFP) OS6850-U24X+PS-120W-DC+24(MiniGBIC-SX)+ 2(10G-XFP-SR) OS6850-U24X+PS-120W-DC+24(MiniGBIC-SX)+ 2(10G-XFP-LR) OS6850-U24X+PS-120W-DC+24(MiniGBIC-LX)+ 2(10G-XFP-SR) OS6850-U24X+PS-120W-DC+24(MiniGBIC-LX)+ 2(10G-XFP-LR) OS6850-U24X+PS-120W-DC+24(MiniGBIC-LH-70)+ 2(10G-XFP-SR) OS6850-U24X+PS-120W-DC+24(MiniGBIC-LH-70)+ 2(10G-XFP-LR) OS6850-U24X+2(PS-120W-DC)+24(MiniGBIC-SX) (No XFP) OS6850-U24X+2(PS-120W-DC)+24(MiniGBIC-LX) (No XFP) OS6850-U24X+2(PS-120W-DC)+24(MiniGBIC-LH-70) (No XFP) OS6850-U24X+2(PS-120W-DC)+24(MiniGBIC-SX) + 2(10G-XFP-SR) OS6850-U24X+2(PS-120W-DC)+24(MiniGBIC-SX) + 2(10G-XFP-LR) OS6850-U24X+2(PS-120W-DC)+24(MiniGBIC-LX) + 2(10G-XFP-SR) OS6850-U24X+2(PS-120W-DC)+24(MiniGBIC-LX) + 2(10G-XFP-LR) OS6850-U24X+2(PS-120W-DC)+24(MiniGBIC-LH-70) + 2(10G-XFP-SR) OS6850-U24X+2(PS-120W-DC)+24(MiniGBIC-LH-70) + 2(10G-XFP-LR) OS6850-U24X+PS-126W-AC+ PS-120W-DC+ 24(MiniGBIC-SX) (No XFP) OS6850-U24X+PS-126W-AC+ PS-120W-DC+ 24(MiniGBIC-LX) (No XFP) OS6850-U24X+PS-126W-AC+ PS-120W-DC+ 24(MiniGBIC-LH-70) (No XFP) OS6850-U24X+PS-126W-AC+ PS-120W-DC+ 24(MiniGBIC-SX) +2(10G-XFP-SR) OS6850-U24X+PS-126W-AC+ PS-120W-DC+ 24(MiniGBIC-SX) +2(10G-XFP-LR) OS6850-U24X+PS-126W-AC+ PS-120W-DC+ 24(MiniGBIC-LX) +2(10G-XFP-SR) OS6850-U24X+PS-126W-AC+ PS-120W-DC+ 24(MiniGBIC-LX) +2(10G-XFP-LR) OS6850-U24X+PS-126W-AC+ PS-120W-DC+ 24(MiniGBIC-LH-70) +2(10G-XFP-SR) OS6850-U24X+PS-126W-AC+ PS-120W-DC+ 24(MiniGBIC-LH-70) +2(10G-XFP-LR)

77,401 112,988 119,811 76,345 109,151 108,049 115,505 114,272 74,573 74,058 120,895 128,664 80,040 116,548 115,303 123,755 122,354 78,103 77,540 120,679 128,408 79,970 116,352 115,113 123,525 122,131 78,038 77,476

8.84 12.90 13.68 8.72 12.46 12.33 13.19 13.04 8.51 8.45 13.80 14.69 9.14 13.30 13.16 14.13 13.97 8.92 8.85 13.78 14.66 9.13 13.28 13.14 14.10 13.94 8.91 8.84

57% 68% 69% 56% 67% 67% 68% 68% 56% 55% 70% 71% 58% 69% 69% 70% 70% 57% 57% 70% 71% 58% 69% 69% 70% 70% 57% 57%

89% 93% 93% 89% 92% 92% 93% 93% 89% 89% 935 93% 90% 93% 93% 93% 93% 89% 89% 93% 93% 90% 93% 93% 93% 93% 89% 89%

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 147 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Regulatory Compliance and Safety Information

This section provides information on regulatory agency compliance and safety for the OmniSwitch 6850 Series.

Declaration of Conformity: CE Mark

This equipment is in compliance with the essential requirements and other provisions of Directive 73/23/EEC and 89/336/EEC as amended by Directive 93/68/EEC.

Waste Electrical and Electronic Equipment (WEEE) Statement

The product at end of life is subject to separate collection and treatment in the EU Member States, Norway and Switzerland. Treatment applied at end of life of the product in these countries shall comply with the applicable national laws implementing directive 2002/96EC on waste electrical and electronic equipment (WEEE).

Standards Compliance
The product bears the CE mark. In addition it is in compliance with the following other safety and EMC standards. Note: EN = European Norm, IEC = International Electro-technical Commission All hardware-switching platforms comply with Class A standards for digital devices per AS/NZS 3548, CISPR 22, EN55022, the FCC Part 15, ICES-003, and VCCI standards..

Safety Standards
Australia: c-Tick for Australia AS/NZS TS-001 and 60950; 2000, Australia Canada: CAN/CSA-C22.2 No. 60950-00 CB Certification PBR IEC 950 CB Certification (per IEC 60950) CB per EN 60825-1 & EN 60825-2 (Safety Laser Evaluation) CDRH for UL (Safety Laser Evaluation) China: China CCC C-Tick for Australia EN60950-1; 2001; all national deviations EN60950-1; 2001; all deviations EN60825-1 Laser EN60825-2 Laser Germany: TUV, UL-GS Mark for Germany IEC 60950-1; 2001; all national deviations NOM-019 SCFI, Mexico TS 001 UL-AR (Argentina) US: UL 60950

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 148 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

EMC Standards
AS/NZS 3548 Class A BSMI Class A CCC (China) Class A CE marking for European countries Class A CISPR 22 Class A EN 55022 Class A EN 55024: 1998 (Immunity Standard) EN 50082-1 EN 61000-3-2: 2000 EN 61000-3-3:1995 EN 61000-4-2: 1995 EN 61000-4-3: 1995 EN 61000-4-4: 1995 EN 61000-4-5: 1995 (Surge Level 4) EN 61000-4-6: 1996 EN 61000-4-8: 1993 ENC 1000-4-11: 1994 FCC Part 15 Class A ICES-003 Class A IEEE 802.3: Hi-Pot Test (1,500V or 2,250VDC on all Ethernet ports) VCCI Class A

Safety and Environmental Standards

ETS 300 019 Storage Class 1.1 ETS 300 019 Transportation Class 2.3 ETS 300 019 Stationary Use Class 3.1 OmniSwitch 6850 switches comply with Class-A standards for digital devices per the FCC Part 15, ICES-003, EN 55022, CISPR 22, AS/NZS 3548, and VCCI standards. Modules with copper connectors meet Class-A requirements using unshielded (UTP) cables.

FCC Class A, Part 15

This equipment has been tested and found to comply with the limits for Class A digital device pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instructions in this guide, may cause interference to radio communications. Operation of this equipment in a residential area is likely to cause interference, in which case the user will be required to correct the interference at the owners expense. The user is cautioned that changes and modifications made to the equipment without approval of the manufacturer could void the users authority to operate this equipment. It is suggested that the user use only shielded and grounded cables to ensure compliance with FCC Rules. If this equipment does cause interference to radio or television reception, the user is encouraged to try to correct the interference by one or more of the following measures: Reorient the receiving antenna. Relocate the equipment with respect to the receiver. Move the equipment away from the receiver. Plug the equipment into a different outlet so that equipment and receiver are on different branch circuits. If necessary, the user should consult the dealer or an experienced radio/television technician for additional suggestions.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 149 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Canada Class A Statement

This equipment does not exceed Class A limits per radio noise emissions for digital apparatus, set out in the Radio Interference Regulation of the Canadian Department of Communications.

JATE
This equipment meets the requirements of the Japan Approvals Institute of Telecommunications Equipment (JATE).

CISPR22 Class A Warning

This is a Class A product. In a domestic environment, this product may cause radio interference. Under such circumstances, the user may be requested to take appropriate countermeasures.

VCCI
This is a Class A product based on the standard of the Voluntary Control Council for Interference by Information Technology Equipment (VCCI). If this equipment is used in a domestic environment, radio disturbance may arise. When such trouble occurs, the user may be required to take corrective actions.

Class A Warning for Taiwan and Other Chinese Markets

This is a Class A Information Product. When used in a residential environment, it may cause radio frequency interference. Under such circumstances, the user may be requested to take appropriate counter-measure.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 150 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Translated Safety Warnings Important Warnings

Blank Panels Warning
Because they regulate airflow and help protect internal chassis components, blank cover plates should remain installed at empty module slots and power supply bays at all times.

Electrical Storm Warning

To avoid a shock hazard, do not connect or disconnect any cables or perform installation, maintenance, or reconfiguration of this product during an electrical storm.

Installation Warning
Only personnel knowledgeable in basic electrical and mechanical procedures should install or maintain this equipment.

Invisible Laser Radiation Warning

Lasers emit invisible radiation from the aperture opening when no fiber-optic cable is connected. When removing cables do not stare into the open apertures. In addition, install protective aperture covers to fiber ports with no cable connected.

Lithium Battery Warning

There is a danger of explosion if the Lithium battery in your chassis is incorrectly replaced. Replace the battery only with the same or equivalent type of battery recommended by the manufacturer. Dispose of used batteries according to the manufacturers instructions. The manufacturers instructions are as follows: Return the module with the Lithium battery to Alcatel-Lucent. The Lithium battery will be replaced at Alcatel-Lucents factory.

Operating Voltage Warning

To reduce the risk of electrical shock, keep your hands and fingers out of power supply bays and do not touch the backplane while the switch is operating.

Power Disconnection Warning

Your switch is equipped with multiple power supplies. To reduce the risk of electrical shock, be sure to disconnect all power connections before servicing or moving the unit.

Proper Earthing Requirement Warning

To avoid shock hazard: The power cord must be connected to a properly wired and earth receptacle Any equipment to which this product will attach must also be connected to properly wired receptacles

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 151 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Read Important Safety Information Warning

The Getting Started Guide and the Users Manual contain important safety information about which you should be aware when working with hardware components in this system. You should read this guide before installing, using, or servicing this equipment.

Restricted Access Location Warning

This equipment should be installed in a location that restricts access. A restricted access location is one where access is secure and limited to service personnel who have a special key, or other means of security.

Wrist Strap Warning

Because electrostatic discharge (ESD) can damage switch components, you must ground yourself properly before continuing with the hardware installation. For this purpose, Alcatel-Lucent provides a grounding wrist strap and a grounding lug. For the grounding wrist strap to be effective in eliminating ESD, the power supplies must be installed and plugged into grounded AC outlets.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 152 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850 Series Hardware & Software Features Overview Table

Chasssiiis Techniicall Speciiffiicatiionss C ha s ss T echn c a Spec cat ons T c e a n
Note: 1 inch = 2.54 centimeters & One Rack Unit = 1.75" & 1 kg = 2.2046 lbs & 1 watt 3.41214 BTU/hr. Indicators /LEDs LED per port: 10/100/1000: PoE, link/activity SFP: link/activity XFP: link/activity PoE ports; speed, link/activity/PoE applied System LEDs: Switch ID (indicates the stack ID of the unit in the stack: 1 to 7) System (OK) (chassis HW/SW status) PWR (primary power supply status) PRI (virtual chassis primary) BPS (backup power status) XFP 1 and 2 (10 Gig link status) Rack Mountable OmniSwitch-6850 is rack mountable in 19 (W) racks (19" Rack-Mountable) Physical Dimensions (W x D x H) Chassis size without P/S or P/S shelf 17.32 x 10.63 x 1.73 in (44.0 x 27.0 x 4.4 cm) Total size including P/S shelf and mounting ears The OS6850 Series chassis are 1U 19.00 x 17.56 x 1.73 in (48.2 x 44.6 x 4.4 cm) (One Rack Unit) Chassis size with mounting ears, without P/S or P/S shelf 19.00 x 10.63 x 1.73 in (48.2 x 27 x 4.4 cm) Weights PoE Models without the P/S: OS6850-P24/-P24H/-P24L/-P24LH: 3.91kg OS6850-P24X/-P24XH: 4.02 kg OS6850-P48/-P48H/-P48L/-P48LH: 4.26 kg OS6850-P48X/-P48XH: 4.35 kg Non-PoE Models without the P/S: OS6850-24/-24D/-24L/-24LD: 3.79 kg OS6850-24X/-24XD: 3.91kg OS6850-48/-48D/-48L/-48LD: 4.06 kg OS6850-48X/-48XD: 4.14 kg OS6850-U24X/-U24XD: 3.91kg ************************* Power Supplies: 510W AC-to-DC: 2.59 kg 360W AC-to-DC: 1.46 kg 126W AC-to-DC: 1.11 kg 120W DC-to-DC: 0.95 kg Power Supply Tray: 0.57 kg

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 153 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Maximum Power Consumption The OmniSwitch 6850 Series

Heat Dissipation The OmniSwitch 6850 Series

Notes -- PoE Models: The power consumption measurements were obtained under fully loaded conditions. In case of the PoE Models with a 360W power supply, the maximum PoE power budget is 240watts and therefore the PoE load cannot exceed 240watts. In case of the PoE Models with a 510W power supply the maximum PoE power budget is 390watts and therefore the PoE load cannot exceed 390watts. Power consumption calculations are based on total power drawn from the AC line, in other words, the Input Power = Output Power / Power Supply efficiency. Chassis Pwr Consumption = Chassis Pwr / PS efficiency + Available PoE Pwr / PoE PS efficiency The AC 110V power transfer efficiency is determined to be @88.9%. or 89% Maximum Power Consumption for the PoE Models with 360W P/S: OS6850-P24 & OS6850-P24L: 48.66watts / 89% + 240watts / 89% 324W OS6850-P24X: 51.36watts / 89% + 240watts / 89% 327W OS6850-P48 & OS6850-P48L: 86.73watts / 89% + 240watts / 89% 367W OS6850-P48X: 104.33watts / 89% + 240watts / 89% 387W Maximum Power Consumption for the PoE Models with 510W P/S: OS6850-P24H & OS6850-P24LH: 48.66watts / 89% + 390watts / 89% 493W OS6850-P24XH: 51.36watts / 89% + 390watts / 89% 496W OS6850-P48H & OS6850-P48LH: 86.73watts / 89% + 390watts / 89% 536W OS6850-P48XH: 104.33watts / 89% + 390watts / 89% 555W Notes Non-PoE Models: The power consumption measurements were obtained under fully loaded conditions. Power consumption calculations are based on total power drawn from the AC line, in other words, the Input Power = Output Power / Power Supply efficiency. Chassis Pwr Consumption = Chassis Pwr / PS efficiency The AC 110V power transfer efficiency is determined to be @88.9%. or 89% Maximum Power Consumption for the Non-POE Models: OS6850-24 & OS6850-24L & OS6850-24D & OS6850-24LD: 48.66watts / 89% 55W OS6850-24X & OS6850-24XD: 51.36watts / 89% 58W OS6850-48 & OS6850-48L & OS6850-48D & OS6850-48LD: 86.73watts / 89% 97W OS6850-48X & OS6850-48XD: 104.33watts / 89% 117W OS6850-U24X & OS6850-U24XD: 106watts / 89% 119W Power Consumption for the 1000BASE-X SFP MiniGBICs: SFP-GIG-SX transceiver = 0.75W SFP-GIG-LX transceiver = 0.9W SFP-GIG-LH transceiver = 1.0W 1-watt 3.41214 BTU/hr. Note: To calculate the heat dissipation for the PoE Models the following formula has been used: Heat Dissipation = (Chassis Power Consumption / PS efficiency + Estimated power required to power the PoE daughter card / PS efficiency) x 3.41214BTU/hr. The reason that the PoE power budget has not been fully taken into account here, is that the heat is dissipated on the PoE devices and not on the OmniSwitch 6850 chassis. Therefore, we only account for the heat dissipated on the OmniSwitch 6850 chassis plus the heat dissipated on the PoE daughter card inside the chassis including the P/S efficiency. Maximum Heat Dissipation for the PoE Models with 360W P/S or 510W P/S: OS6850-P24 & OS6850-P24L & OS6850-P24H & OS6850-P24LH: (48.66watts / 89% + 24watts / 89%) x 3.41214 279 BTU/hr. OS6850-P24X & OS6850-P24XH: (51.36watts / 89% + 24watts / 89%) x 3.41214 289 BTU/hr. OS6850-P48 & OS6850-P48L & OS6850-P48H & OS6850-P48LH: (86.73watts / 89% + 48watts / 89%) x 3.41214 517 BTU/hr. OS6850-P48X & OS6850-P48XH: (104.33watts / 89% + 48watts / 89%) x 3.41214 584 BTU/hr. Note: To calculate the heat dissipation for the non-PoE Models the following formula has been used: Heat Dissipation = Chassis Power Consumption x 3.41214BTU/hr. Maximum Heat Dissipation for the Non-POE Models: OS6850-24 & OS6850-24L & OS6850-24D & OS6850-24LD: 55watts x 3.41214 188 BTU/hr. OS6850-24X & OS6850-24XD: 58watts x 3.41214 198 BTU/hr. OS6850-48 & OS6850-48L & OS6850-48D & OS6850-48LD: 97watts x 3.41214 331 BTU/hr. OS6850-48X & OS6850-48XD: 117watts x 3.41214 399 BTU/hr. OS6850-U24X & OS6850-U24XD: 119watts x 3.41214 406 BTU/hr.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 154 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Pow er Supply Requirements

Power Supply Requirements Directly Pluggable in the back of the chassis (chassis depth +P/S depth is then 440mm or 16.73 inches) Remotely connected to the chassis through a cable (chassis depth is then 270mm or 10.63 inches) There are 4 different power supplies for the family: OS6850 Series Primary Power Supplies include: The 126W AC-to-DC Non-PoE P/S The 126W AC-to-DC Power Supply is used on the following Models: OS6850-24 & OS6850-24L & OS6850-24X & OS6850-48 & OS6850-48L & OS6850-48X & OS6850-U24X The 120W DC-to-DC Non-PoE P/S The 120W DC-to-DC Power Supply is used on the following Models: OS6850-24D & OS6850-24LD & OS6850-24XD & OS6850-48D & OS6850-48LD & OS6850-48XD & OS6850-U24XD The 360WAC-to-DC Standard PoE P/S The 360W AC-to-DC Power Supply is used on the following Models: OS6850-P24 & OS6850-P24L & OS6850-P24X & OS6850-P48 & OS6850-P48L & OS6850-P48X The 510W AC-to-DC High PoE P/S The 510W AC-to-DC Power Supply is used on the following Models: OS6850-P24H & OS6850-P24LH & OS6850-P24XH & OS6850-P48H & OS6850-P48LH & OS6850-P48XH OS6850 Series Backup Power Supplies include: OS6850-BP-P: OS6850-BP-P modular Standard PoE 360W AC-to-DC backup P/S OS6850-BP-PH: OS6850-BP-PH modular High PoE 510W AC-to-DC backup P/S OS6850-BP: OS6850-BP modular 126W AC-to-DC backup P/S OS6850-BP-D: OS6850-BP-D modular 120W DC-to-DC backup P/S Notes: The main power supply is EXTERNAL to the box A power shelf is used to hold either one 510 PS or two of the smaller PS. Directly Pluggable in the back of the unit total unit + PS depth is then 44.6 cm/17.56in) OR Attached with a cable for 2U configuration Both primary and backup power supplies fit into the power shelf for 120W, 126W and 360W PS. Directly Pluggable in the back of the unit next to the primary or placed on top of the unit The backup High PoE power supply (510W) cannot be adjacent to the primary PS on the same shelf. It has to have its own power supply shelf A shelf and a remote cable is provided within the shipping box to rack a power supply on top of the unit Remotely connected power supply allows for smaller depth space requirement. The OS6800 product family Backup Power Supplies cannot be used for the OS6850 product family and vice-versa. The chassis P/S fail-over to the backup P/S is transparent to the users and without a reboot of the switch. The fail-over time is negligible.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 155 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Power Supply Input & Output Electrical Parameters

Power Supply Specifications OS6850 Series Primary Power Supplies include: Main and backup power supplies are external Connect to the rear of the unit Can be connected by cable Supports redundant dual hot swappable P/S Power shelf provided with unit holds one 510W or two 360W, 126W or 120W power supplies OmniSwitch 6850-24, -24X, -48, -48X, -U24X Support 126W (AC) and 120W (DC) power supplies Do not support PoE OmniSwitch 6850-P24, -P24X, -P48, and -P48X Dual externally mounted 360W and/or 510W P/S 130W dedicated to chassis power Remainder used for PoE The 126W AC-to-DC Non-PoE P/S The 126W AC-to-DC Power Supply is used on the following Models: OS6850-24 & OS6850-24L & OS6850-24X & OS6850-48 & OS6850-48L & OS6850-48X & OS6850-U24X The 126W P/S Input & Output Parameters for the chassis main Power: The 126W AC/DC power supply provides +12V @ 10.5A. Input Power: 157.5 watts AC (based on an efficiency of 80%) Maximum continuous output power will be 126W. Peak power for 50msec will be 156W. Input Voltage range: 85 to 269VAC (Universal input voltage) Input Voltage range: 100 to 240VAC (Nominal Input Voltage or Agency approved unit) Nominal input is expected to be 115VAC(rms) at 60Hz or 230VAC(rms) at 50Hz. Input current: 1.37 Amps AC@115VAC or 0.684 Amps AC@230VAC Input current will be less than 1.8A (rms) at 115Vac (rms) and 60Hz. Input current will be less than 0.9A (ms) at 230Vac (rms) and 50Hz. Input Frequency: 47 to 63 Hz (3%) The power supply efficiency will be greater than 75%. The input fuse value shall be less than or equal to 4 Amps AC Output Power: 126watts DC rated Output voltage: 12VDC rated Output current: 10.5Amps DC rated The 120W DC-to-DC Non-PoE P/S The 120W DC-to-DC Power Supply is used on the following Models: OS6850-24D & OS6850-24LD & OS6850-24XD & OS6850-48D & OS6850-48LD& OS685048XD & OS6850-U24XD The 120W P/S Input & Output Parameters for the chassis main Power: The 120W DC/DC power supply provides +12V @ 10A. The P/S operates from 3675VDC. Input Power: 150 watts DC (based on an efficiency of 80%) Input Voltage range: 36 to 75VDC (Universal input voltage) Input Voltage: 48VDC (Nominal Input Voltage or Agency approved unit) Input current: 3.125 Amps DC@48 VDC Input current will be less than 3.2A at 48VDC. The power supply efficiency will be greater than 75%. Output Power: 120watts DC rated Output voltage: 12VDC rated Output current: 10Amps DC rated The 360W AC-to-DC Standard PoE P/S The 360W AC-to-DC Power Supply is used on the following Models: OS6850-P24 & OS6850-P24L & OS6850-P24X & OS6850-P48 & OS6850-P48L & OS6850-P48X This specification covers the 360W switching power supply requirements for Ethernet switches with 240W (-50V @ 4.8A) for PoE power and 120W (12V @ 10.0A) for system power operation. The 360W P/S provides the following outputs: dual outputs, -50V and +12V. P/S Input Parameters: Input Power: 450 watts AC (based on an efficiency of 80%) Input Voltage range: 90 to 264VAC (Universal input voltage) Input Voltage range: 100 to 240VAC (Nominal Input Voltage or Agency approved unit) Nominal input is expected to be 115VAC (rms) at 60Hz or 230VAC (rms) at 50Hz. Input current: 3.91 Amps AC@115VAC or 1.95 Amps AC@230VAC Input current: 5.0 Amps AC@90VAC Input current will be less than 4.5A (rms) at 115VAC (rms) and 60Hz. Input current will be less than 2.3A (rms) at 230VAC (rms) and 50Hz. Input Frequency: 47 to 63 Hz (3%) The power supply efficiency will be greater than 75%. The input fuse value shall be less than 8 Amps AC The power supply shall provide the following required output voltages & output currents for the main chassis and the PoE. Maximum continuous output power will be 360W. The Main Chassis P/S Output Parameters: Output Power: 120 watts DC rated Output voltage: 12 VDC rated Output current: 10.0 Amps DC maximum rated The PoE P/S Output Parameters: The estimated available PoE power budget is 240watts: Output Power: 240 watts DC maximum rated Output voltage: -50 VDC maximum rated Output current: 4.8 Amps DC maximum rated

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 156 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

PoE Power availability

The 510W AC-to-DC High PoE P/S The 510W AC-to-DC Power Supply is used on the following Models: OS6850-P24H & OS6850-P24LH & OS6850-P24XH & OS6850-P48H & OS6850-P48LH & OS6850-P48XH This specification covers the 510W switching power supply requirements for Ethernet switches with 390W (50V @ 7.8W/port) for PoE power and 120W (12V @ 10.0A) for system power operation. The 510W P/S provides the following outputs: dual outputs; -50V and +12V. P/S Input Parameters: Input Power: 637.5 watts AC (based on an efficiency of 80%) Input Voltage range: 85 to 264VAC (Universal input voltage) Input Voltage range: 100 to 240VAC (Nominal Input Voltage or Agency approved unit) Nominal input is expected to be 115VAC (rms) at 60Hz or 230VAC (rms) at 50Hz. Input current: 5.54 Amps AC@115VAC or 2.77 Amps AC@230VAC Input current: 7.08 Amps AC@90VAC Input current will be less than 10A (rms) at 115VAC (rms) and 60Hz. Input current will be less than 5A (rms) at 230VAC (rms) and 50Hz. Input Frequency: 47 to 63 Hz (3%) The power supply efficiency will be greater than 75%. The input fuse value shall be less than 12 Amps AC The power supply shall provide the following required output voltages & output currents for the main chassis and the PoE. Maximum continuous output power will be 510W. The Main Chassis P/S Output Parameters: Output Power: 120 watts DC rated Output voltage: 12 VDC rated Output current: 10.0 Amps DC maximum rated The PoE P/S Output Parameters: The estimated available P/S PoE power budget is 390watts: Output Power: 390 watts DC maximum rated Output voltage: -50 VDC maximum rated Output current: 7.8 Amps DC maximum rated Note: Switching DC/DC or linear regulators on the PCB further breaks down the +12VDC to generate the required 5V, 3.3V, 2.5V, 1.8V, 1.25V, 1.2V and 2V. The 360W AC-to-DC Power Supply is used on the following PoE Models: OS6850-P24 & OS6850-P24L & OS6850-P24X & OS6850-P48 & OS6850-P48L & OS6850-P48X: The 360W power supply provides: 240W (-50V @ 4.8A) for in-line power and 120W (12V @ 10.0A) for system power operation. PoE Power Budget for the 24-port Models: 216watts [240watts (PoE power) 24watts (the overhead (power consumed by the PoE daughter card which is 1watt per port))]. PoE Power Budget for the 48-port Models: 192watts [240watts (PoE power) 48watts (the overhead (power consumed by the PoE daughter card which is 1watt per port))]. The 510W AC-to-DC Power Supply is used on the following PoE Models: OS6850-P24H & OS6850-P24LH & OS6850-P24XH & OS6850-P48H & OS6850-P48LH & OS6850-P48XH: The 510W power supply provides: 390W (50V @ 7.8W/port) for in-line power and 120W (12V @ 10.0A) for system power operation. The available PoE Power Budget for the 24-port Models: 366watts [390watts (PoE power) 24watts (the overhead (power consumed by the PoE daughter card which is 1watt per port))]. The available PoE Power Budget for the 48-port Models: 342watts [390watts (PoE power) 48watts (the overhead (power consumed by the PoE daughter card which is 1watt per port))]. Note: Power for all POE ports is defaulted to 15.4 watts per port and each port is configurable between 3watts to 15.4watts (Port setting is in Milliwatts (3000 to 15400)). Please note that the available PoE power budget must not be exceeded.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 157 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Fans Chassis Air-Flow

Power plug type

Electrical Requirements

Name Plates

Acoustic Noise level

Fans: 3 fans for the chassis. Additional fans built in the power supplies. Redundant fans support (1:N redundancy) Chassis Airflow: The fans pull air from the air intake vent located on the left-hand side of the chassis. The air is directed horizontally through the chassis and past the circuit board. Airflow is then exhausted through the fan vents at the right-hand side of the chassis. Important. Maintain a clearance of at least two inches at the left and right sides. Otherwise, airflow can become restricted. Restricted airflow can cause your switch to overheat; overheating can lead to switch failure. North America: NEMA 5-15-P (US), C22.2, No. 42 (Canada) United Kingdom / Ireland: BS 1,363, Europe: CEE 7/7 Japan: JIS 8,303, Australia: AS 3,112, India: BS 546, Italy: CIE 2,316 Switzerland / Liechtenstein: SEV 1011 Denmark / Greenland: SRAF 1,962 / D816 / 87, Argentina: AR1-10P OmniSwitch 6850 switches have the following general electrical requirements: Each switch requires one grounded electrical outlet for each power supply installed in the. OmniSwitch 6850 switches offer both AC and DC power supply support. Refer to the Hardware Users Guide for more information. For switches using AC power connections, each supplied AC power cord is 2 meters (approximately 6. 5 feet) long. Do not use extension cords. Redundant AC Power: If possible, it is recommended that each AC outlet reside on a separate circuit. With redundant AC, if a single circuit fails, the switchs remaining power supplies (on separate circuits) will likely be unaffected and can therefore continue operating. For switches using DC power, the user must assemble the DC power cord. Refer to the Hardware Users Guide for more information. A nameplate in the front of the chassis will identify the product model name & number and the vendor (in this case Alcatel-Lucent). A nameplate in the back will clearly identify the following: Model #, Assembly # with BAR CODE, and FCC statements Electric Ratings and U.S. Patent information along with their respective symbols. PoE Models: OS6850-P24/-P24L & OS6850-P24H/-P24LH: under 44dBa OS6850-P24X & OS6850-P24XH: under 44dBa OS6850-P48/-P48L & OS6850-P48H/-P48LH: under 48dBa OS6850-P48X & OS6850-P48XH: under 48dBa Non-POE Models: OS6850-24/-24D & OS6850-24L/-24LD: under 44dBa OS6850-24X & OS6850-24XD: under 44dBa OS6850-48/-48D & OS6850-48L/-48LD: under 48dBa OS6850-48X & OS6850-48X: under 48dBa OS6850-U24X & OS6850-U24XD: under 44dBa

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 158 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Emissions (EMC) & Immunity Compliance

Safety Compliance All hardware-switching platforms comply with Class A standards for digital devices per AS/NZS 3548, CISPR 22, EN 55022, the FCC Part 15, ICES-003, and VCCI standards. Modules with copper connectors meet Class A requirements using unshielded (UTP) cables.

AS/NZS 3548 (Class A limits. Note: Class A with UTP cables) / EN55022 (Australia Emissions) Class A; CE Marking per EMC Directive; CE Markings for European countries (Class A. Note: Class A with UTP cables) CISPR22: 1997 Class A (International Emissions); CNS 13438:1997 Class A (Taiwan Emissions); FCC CFR Title 47, Subpart B, (Class A limits. Note: Class A with UTP cables) 89/336/EEC EMC Directive (European Requirements); EN50082-1; EN55022: 1998 w/A1 & A2 Emissions Standards including the European Emissions; EN55024: 1998 +A1 :2001+A2 :2003 ;includes EN61000-4-2, 3, 4, 5, 6, 7, 11 (European Immunity); EN60555-2; EN61000-3-2 (European Harmonics & Flicker); 2000 EN61000-3-3 (European Harmonics & Flicker); 1995+A1:2001 EN61000-4-2; 1995 + A1: 1998 EN61000-4-3; 1996 + A1: 1998 EN61000-4-4; 1995 EN61000-4-5; 1995 EN61000-4-6; 1996 EN61000-4-8; 1994 EN61000-4-11; 1994 ICES-003 Class A; IEC 1000-3-2; IEC 60950-1; 2001;all national deviations MIC Mark (Korean Emissions & Immunity Approval); NOM/NYCE (Mexican Product Safety & EMC Authorities) NOM-019-SCFI 1994 & NOM-019-SCFI-1998, Mexico; VCCI Class A (Japan Emissions); VCCI-V3/97.04, Class A limits. Note: Class A with UTP cables) IEEE 802.3:Hi-Pot Test (2250 VDC on all Ethernet ports) EN = European Norm, IEC = International Electro-technical Commission AS/NZS 3260 /TS-001and 60950-2000 (Australia Safety Standard); CAN/CSA-C22.2 No. 60950-1-03; CB Report and Cert. (International safety of ITE) with all national deviations (IEC 950); CE Marking per Low Voltage Directive (LVD) (European Safety Directive); CDRH Letter of Approval (US FDA Approval); 21 CFR 1040 (part of Laser Certification per EN 60825-1 & EN 60825-2); China CCC EN60825-1 (Laser Evaluation) &EN60825-2 (Laser Evaluation): 1994, A11: 1996 (European Safety of Lasers Products); IEC 60950-1; 2001; all national deviations EN60950-1: 2001 a11deviations + Deviations (European Safety of ITE); ETS 300 019 Storage Class 1.1/ Transportation Class 2.3/Stationary Use Class 3.1 FCC 21 CFR Subpart J (US Safety of Laser Products); GOST (Russian Federation Certificate) NOM-019 SCFI, Mexico TS 001; UL-GS Mark / TUV GS Mark (German Notified Body) EN 60950; UL-AR: Argentina Certification & S Mark (Argentina Safety Approval); UL 60950

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 159 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Metro Ethernet Forum (MEF) 9 and 14 certification

Alcatel-Lucent is pleased to announce that both the Alcatel-Lucent OmniSwitch 6850 Stackable LAN switch and the Alcatel-Lucent OmniSwitch 9000 Chassis LAN switch are now Metro Ethernet Forum (MEF) 9 and 14 certified. MEF benefits for Alcatel-Lucent MEF certification strengthens LAN product positioning in Metro Access deployments for residential and business Ethernet services where the OmniSwitch 6850 and OmniSwitch 9000 switches are used as customer premises equipment (CPE) in single or multi-tenant unit (STU/MTU) installations. With this certification, Alcatel-Lucent now offers a fully MEF compliant end-to-end solution for Ethernet services based on LAN OmniSwitch switches and MPLS Service Routers (7710, 7750, 7450). What is MEF and what does it mean to be MEF certified? The Metro Ethernet Forum (MEF) is a global industry alliance comprising more than 120 organizations whose mission is to accelerate the worldwide adoption of carrier-class Ethernet networks and services. The alliance members develop technical specifications and implementation agreements to promote interoperability and deployment of carrier Ethernet worldwide. Test certifications obtained while running on the Alcatel-Lucent Operating System (AOS) version 6.3.1.R01 were: 1. MEF 9 for equipment vendors Ethernet services at the user network interface (UNI) 2. MEF 14 for equipment vendors focused on traffic management, service performance, and quality of service (QoS) Certifications tests indicate that the OmniSwitch 6850 and 9000 meet the carrier-class standard for Ethernet Private Line (EPL), Ethernet Virtual Private Line (EVPL), and Ethernet LAN (E-LAN) services at the UNI. Service providers benefit from this certification because it: Provides immediate assurance that the vendors equipment complies with MEF specifications Saves money and time on complex testing between vendors, especially on global accounts Establishes a solid foundation for carrier Ethernet ubiquity and interoperability This equipment meets the requirements of the Japan Approvals Institute of Telecommunications Equipment (JATE). The OmniSwitch 6850 Series has been rigorously tested for: Temperature Humidity Vibrations Acoustic Noise Altitude Drop Shock Bench Handling Please contact Alcatel-Lucent Internetworking Product Marketing and/or other Alcatel-Lucent authorized representatives to obtain further data and/or a full test report. 1) RoHS-Alcatel's OmniSwitch 6850 family is among the first hardware to be in compliance with the new European Community's directive Restriction on Hazardous Substances in Electrical and Electronic Equipment (RoHS) 2) WEEE (Waste Electrical and Electronic Equipment) 3) NEBS Level 3 Certified All of the non-PoE models

JATE Reliability Tests

Compliancy

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 160 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

RoHS Requirements

RoHS Restriction on Hazardous Substances

EU Council Decision 87/95/EEC WEEE

NEBS-Level-3 Electrical Compliance Electrostatic Discharge (ESD) ISO-9001:2000 DNV Certification Capability Maturity Model (CMM) Mean Time Between Failure (MTBF) Standard

It is Alcatel-Lucent's position to be in compliance with the European R.O.H.S Directive 2002/95/EC by the end of 2005. In doing so, all component selection decisions shall be influenced by offerings that are a) ROHS compliant today or b) have planned date of cutover to ROHS compliance without impacting the design (i.e. causing a redesign). It is Alcatel-Lucent's intention to choose environmentally friendly component finishes that are today solder-able with SN63/Pb37 solders (through late 2005), but can move to SnAgCu chemistries in Jan2006. Compliance with Environmental procedure 020499-00, primarily focused on Restriction of Hazardous Substances (ROHS Directive 2002/95/EC) and Waste Electrical and Electronic Equipment (WEEE Directive 2002/96/EC). Thus, all assemblies built after Dec. 31, 2005 shall be compliant with hazardous materials requirements as defined in 020499-00. Upon request, documentation shall be provided certifying compliance. First Green switch in the Market RoHS compliancy With the OmniSwitch 6850 family, Alcatel-Lucent will be the first switch manufacturer to be in compliance with the new European Communitys directive Restriction on Hazardous Substances in Electrical and Electronics Equipment (RoHS) which requires electric equipment to be free of six hazardous substances by July 2006. Although, only required for European Union countries, the rest of the World will benefit from these green switches by lessening the amount of hazardous substances that find its way into the environment. Compliance with regulation given in: http://europa.eu.int/ISPO/infosoc/legreg/docs/8795eec.html The product at end of life is subject to separate collection and treatment in the EU Member States, Norway and Switzerland. Treatment applied at end of life of the product in these countries shall comply with the applicable national laws implementing directive 2002/96EC on waste electrical and electronic equipment (WEEE). NEBS Level-3 Certified All of the non-PoE models of OmniSwitch 6850 family supports NEBS Level-3. The Electrical Compliance requirements are met through the EMC Compliance Standards and the Safety Compliance Standards as indicated above. The chassis has been thoroughly tested to withstand ESD test voltage conditions at any point on the enclosure using the test setups and conditions in accordance with IEC 61000-4-2 (EN61000-4-2). The OmniSwitch 6850 is compliant with the ISO-9001: 2000 DNV Alcatel-Lucent's Software Engineering Institute (SEI) Capability Maturity Model (CMM) rating for software processes meets the Level-2 (CMM-level-2) requirements. All AOS OmniSwitches support a commercial equivalent of MIL-HDBK-217F-2: MTBF Predictions are based on Telcordia (Bellcore Handbook Technical Reference) SR-332, Issue 1.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 161 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

MTBF Please note, that MTBF values are Configuration-specific and different configurations shall yield different MTBF values.

Please refer to the MTBF Section for other configuration details. PoE Models: OS6850-P24/-P24L: 170,929 MTBF-Hrs [OS6850-P24/-P24L + 2 (PS-360W-AC) + 4 (SFP-GIG-LX)] OS6850-P24H/-P24LH: 131,604 MTBF-Hrs [OS6850-P24H/-P24LH + PS-510W-AC + 4 (SFP-GIG-LX)] OS6850-P24X: 157,976 MTBF-Hrs [OS6850-P24X + 2 (PS-360W-AC) + 4 (SFP-GIG-LX) + 2 (10G-XFP-SR)] OS6850-P24XH: 151,958 MTBF-Hrs [OS6850-P24XH + 2 (PS-510W-AC) + 4 (SFP-GIG-LX) + 2 (10G-XFP-SR)]

OS6850-P48/-P48L: 141,822 MTBF-Hrs [OS6850-P48/-P48L + 2 (PS-360W-AC) + 4 (SFP-GIG-LX)] OS6850-P48H/-P48LH: 137,133 MTBF-Hrs [OS6850-P48H/-P48LH + 2 (PS-510W-AC) + 4 (SFP-GIG-LX)]

OS6850-P48X: 136,932 MTBF-Hrs [OS6850-P48X + 2 (PS-360W-AC) + 2 (10G-XFP-SR)] OS6850-P48XH: 132,612 MTBF-Hrs [OS6850-P48XH + 2 (PS-510W-AC) + 2 (10G-XFP-SR)] Non-PoE Models: OS6850-24/-24L: 200,836 MTBF-Hrs [OS6850-24/-24L+ 2 (PS-126W-AC) + 4 (SFP-GIG--LX)] OS6850-24D/-24LD: 202,668 MTBF-Hrs [OS6850-24D/-24LD + 2 (PS-120W-DC) + 4 (SFP-GIG--LX)] OS6850-24X: 181,646 MTBF-Hrs [OS6850-24X+2 (PS-126W-AC) + 4 (SFP-GIG-LX) + 2 (10G-XFP-SR)] OS6850-24XD: 166,445 MTBF-Hrs [OS6850-24XD + 2 (PS-120W-DC) + 4 (SFP-GIG-LX) + 2 (10G-XFP-SR)] OS6850-48/-48L: 163,765 MTBF-Hrs [OS6850-48/-48L + 2 (PS-126W-AC) + 4 (SFP-GIG-LX)] OS6850-48D/-48LD: 164,834 MTBF-Hrs [OS6850-48D/-48LD + 2 (PS-120W-DC) + 4 (SFP-GIG-LX)] OS6850-48X: 157,519 MTBF-Hrs [OS6850-48X + 2 (PS-126W-AC) + 2 (10G-XFP-SR)] OS6850-48XD: 158,483 MTBF-Hrs [OS6850-48XD + 2 (PS-120W-DC) + 2 (10G-XFP-SR)]

OS6850-U24X: 121,869 MTBF-Hrs [OS6850-U24X + 2 (PS-126W-AC) + 24 (SFP-GIG-LX) + 2 (10G-XFP-LR)] OS6850-U24XD: 122,354 MTBF-Hrs [OS6850-U24XD + 2 (PS-120W-DC) + 24 (SFP-GIG-LX) + 2 (10G-XFP-LR)]

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 162 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Quality Assurance and Customer Satisfaction

It is the policy of Alcatel-Lucent USA to satisfy the Quality expectations of our customers both internal and external. Total Quality performance means understanding who the customer is, what the customer expectations are, and meeting those expectations without error, on time, every time. Total Quality is doing the right things right today and better tomorrow. As part of Alcatels overall Quality Assurance process Alcatels Cross-functional team continuously evaluates Cost, Time to Market, Communication, Customer satisfaction and Process improvements. Necessary and appropriate actions are subsequently taken as required. Alcatel-Lucent's Enterprise Solutions Division adheres to the ISO 9001 certification program. It measures Customer Satisfaction and Key Process Indicators that are reviewed on regular intervals with the Executive Management Team.

OS6850 chassis Temperature Requirements Note: the switch must be operated normally at Operating temperature: 0 C to 45 C

Temperature Sensors Brownout/Blackout Tolerance or P/S Holt-up Time

HVAC (Heating, Ventilation, Air Conditioning) Humidity Altitude Shock

The installation site must maintain a temperature between 0 and 45 C (32 and 113 F) and not exceed 95 percent maximum humidity (non-condensing) at any time. Standard ambient (outside environment or outside the chassis) operating temperature: 0 C to 45 C Storage Temperature: 14 F to 158 F (-10C to 70C) The Show Temperature command displays the current operating chassis ambient temperature, as well as current temperature threshold settings for each of the modules in the stack. In over-threshold temperature situations, the switch immediately sends a trap to the user. Temperature errors LED is also provided in the front panel. Temperature Sensor National Semi-Conductor LM77 The so-called brownout/blackout tolerance is what we call Power Supply Holdup Time: The Holdup time across all switching and routing platforms power supplies is guaranteed to be: 20ms per each P/S at 100% load. Depending on the load and the input voltage, the holdup time can be as high as 120ms to 280ms. For RFP purposes please provide the Heat Dissipation (BTUs), Temperature, Fans and Chassis Air Flow information as described elsewhere in this table. Operating: 5% to 90% Relative Humidity (Non-condensing) Storage: 0% to 95% Relative Humidity (Non-condensing) Operating altitude: sea level at 40 degrees Celsius and 10000 feet at 0 degrees Celsius Storage altitude: sea level at 40000 feet Packed drop test: per MIL-STD-810 method 516.3 procedure IV from height of 30", one drop on each side, no drop test at 4 corners is required; Unpacked: 30G, 1/2 Sine, 11ms, 3 shocks in each direction along the 3 mutually perpendicular axes (18 shocks total); Unpacked bench handling: per MIL-STD-810 method 516.3 IV. Using one edge as pivot, lift the opposite edge until one of the following occurs: a) Chassis forms 45 angle with horizontal bench top. b) Lifted edge is raised 4" above horizontal bench top. c) Lifted edge is just below point of perfect balance. Let chassis drop freely. Repeat using other practical edges of same horizontal face as pivot points for a total of 4 drops. Repeat on other faces for a total of 4 times on each face, which the chassis could be placed on practically during servicing.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 163 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Vibration: operating Vibration: non-operating

0.25G, Sine, 5-500-5 Hz, maximum displacement of 0.060 inches, 1 octave/minute in its 3 mutually perpendicular axes. Testing shall be repeated 4 times for each axis. Packed: 1.6G, Sine, 5-500-5 Hz, maximum displacement of 0.060 inches, 1 octave/minute in its 3 mutually perpendicular axes. Testing shall be repeated 4 times for each axis; Packed random: per Mil-Std-810, Category 1, Basic Transportation, 60 min. duration with vibration level based on Fig. 514.3-1 through Fig. 514.3-3 in its 3 mutually perpendicular axes.

Service & Support

Default Warranty Limited Lifetime Warranty One year on Hardware, and 90-days on Software. Additional, optional support is available. Contact your local Alcatel-Lucent representative for more information. All versions of the OS6850 family come with a Limited Lifetime Hardware Warranty, limited to the original owner, and will be provided for up to five (5) years. Faulty parts will be replaced via a five (5) business days AVR (Advance Replacement) RMA. Limited Lifetime Warranty does not apply to transceivers. One year 7x24 phone. Includes e-service Web access, software releases, repair and return of hardware to be completed in 10 business days from receipt. One year - 7x24 phone. Includes e-service Web access, software releases and advanced shipment for next business day arrival of replacement hardware. One year - 7x24 phone. Includes eService Web access, software releases, and same day 4-hour on site hardware replacement (labor and parts) 7 days a week, 24 hours a day. Excludes NMS and Authentication Services software.

SupportBasic SupportPlus SupportTotal (available only in N. America)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 164 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850 Series (OS6850) Hardware Technical Specifications

OmniSwitch 6850 (OS6850) family switches are advanced 10/100/1000Mbps copper and fiber based stackable workgroup switches that provide wire rate L2+, L3 routing and advanced services with high availability for IPv4 and IPv6 communications and mission-critical environments. The new OmniSwitch 6850 family of switches provides feature-rich, yet value-priced, solution for delivering power over Ethernet (PoE) as well as 10 Gigabit uplinks. The OS6850s high availability design makes them a great choice for: Enterprise workgroups/LAN wiring closets Edge deployments and branch offices Aggregation/distribution layer switches in three-tier networks Small enterprise core switching Data center server cluster Converged voice and data environments Quality of service (QoS) for mission critical applications IEEE 802.3af Power over Ethernet (PoE) 10/100/1000Base-T or 1000Base-FX to the desktop All members of the OS6850 series have a new space-saving design that provides the maximum flexibility in installation. Through use of a reduced depth main chassis, the OS6850 can be installed in space-constrained cabinets. The power options available for the OS6850s also provide great flexibility and include externally Pluggable or remote mounting power supplies as well as standard or high-power PoE. This allows you to deploy PoE on every user port with only the amount of power needed generating a cost savings. Additionally, for non-PoE switches, AC, DC or a mix of power supplies can be attached in primary or backup roles. When a power supply is attached, an OS6850 maintains the same depth as the existing OS6800 series of switches, enabling an easy upgrade to a PoE switch. The OS6850 also offers on some models two built-in 10 Gigabit Ethernet (10GigE) XFP ports on the front of the switch, providing the most cost-effective and accessible way to deploy 10GigE connectivity. The OS6850 offers greater capacity for security and quality of service rules with increased speed for stacking links to 10Gbps FD per stacking port. The OmniSwitch 6850 along with OS9000 series are the first switches from the OmniSwitch family that meet European green standards. The OmniSwitch 6850 Series benefits from a distributed switch architecture that provides redundancy of critical hardware and software elements for a continuous traffic processing in any network conditions without a single point of failure. Om niSwitch 6850 Series Switch Processing Scheme; Non-blocking, and store-and-forward The product family model names have the format: OS6850-xxxx. Suffix letters in the model name Chassis Options Notes indicate different functionality: * Power supply: - "P" means bundle comes with Standard PoE power supply (360w), - "P and H" means bundle comes with High-PoE power supply (510w) - "D" means bundle comes with DC power supply, - No P, H or D means bundle comes with standard AC power supply package * 10 Gigabit ports module: - "X" means bundle comes with two 10 Gigabit ports built-in module supporting XFP optical transceiver, - No X means bundle does not include the two 10 Gigabit ports built-in module. * L model - 10/100 upgradeable to Gigabit: - "L" means OS6850 chassis comes with 10/100 RJ45 ports that can operate also at Gigabit speed by purchasing a specific upgrade software license. All members of the OS6850 series employ a reduced depth main chassis. Power supply could be directly plugged in the rear of the chassis or remotely mounted in the rack. Chassis Bundles ship with two rack mounts for the power shelf, and one chassis connection cable for remote mounting of the power supply. OS6850 supports power supply redundancy. Only the OS6850-U24X SFP ports support 100FX single speed optical transceivers. All versions of the OS6850 family come with hardware Limited Lifetime Warranty. Limited Lifetime Warranty is limited to the original owner, and will be provided for up to five (5) years after product End of Sales (EoS) announcement. Faulty parts will be replaced via a five (5) Business days AVR (Advance Replacement) RMA. Limited Lifetime Warranty does not apply to transceivers. System Requirements Memory Requirements: OmniSwitch 6850 Series Release 6.3.1.R01 requires 256 MB of SDRAM and 64MB of flash memory. This is the standard configuration shipped. Configuration files and the compressed software imagesincluding web management software (WebView) imagesare stored in the flash memory. Use the show hardware info command to determine your SDRAM and flash memory. Uboot, FPGA, MiniBoot, BootROM, and Upgrade Requirements: OmniSwitch 6850 Series Uboot: 6.1.3.601.R01 or later MiniBoot. Uboot: 6.1.3.601.R01 or later POE Firmware 5.01

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 165 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850-24 24 RJ-45 10/100/1000BASE-T 4 combo ports (ports 21 - 24) 2 Stacking ports

OS6850-24D

OS6850-24X 24 RJ-45 10/100/1000Base-T 2 build-in 10 Gig ports 4 combo ports (ports 21-24) 2 stacking ports

OS6850-24XD

OS6850-P24 24 PoE ports 4 combo ports (ports 21 - 24) 2 Stacking ports

OS6850-P24H

OS6850-P24X 24 PoE ports 2 build-in 10 Gig ports 4 combo ports (ports 21 - 24) 2 stacking ports

OS6850-P24XH

OS6850-24 chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 20 RJ-45 ports individually configurable to 10/100/1000 BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 126W AC power supply with Power shelf and country specific power cord, user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies are can be ordered separately. OS6850-24D chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 20 RJ-45 ports individually configurable to 10/100/1000 BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 120W DC power supply with Power shelf; user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-24X chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 20 RJ-45 ports individually configurable to 10/100/1000 BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, two 10 Gigabit ports, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 126W AC power supply with Power shelf and country specific power cord; user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-24XD chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 20 RJ-45 ports individually configurable to 10/100/1000 BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, two 10 Gigabit ports, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 120W DC power supply with Power shelf; user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P24 PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992]. L3 Gigabit Ethernet chassis in a 1U form factor with 20 RJ-45 PoE ports individually configurable to 10/100/1000 BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports, either copper or fiber can be used on a one for one basis. The bundle includes a 360W AC PoE power supply with Power shelf, country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P24H PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 20 RJ-45 PoE ports individually configurable to 10/100/1000 BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports, either copper or fiber can be used on a one for one basis. The bundle includes a 510W AC PoE power supply with Power shelf, country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P24X PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 20 RJ-45 PoE ports individually configurable to 10/100/1000 BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, two 10 Gigabit ports, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 360W AC PoE power supply with Power shelf, and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P24XH PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 20 RJ-45 PoE ports individually configurable to 10/100/1000 BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, two 10 Gigabit ports, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 510W AC PoE power supply with Power shelf and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 166 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850-48 48 RJ-45 10/100/1000Base-T 2 stacking ports 4 combo ports (ports 1 4)

OS6850-48D

OS6850-48X 48 RJ-45 10/100/1000Base-T 2 build-in 10 Gig ports 2 stacking ports No combo ports

OS6850-48 chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 44 RJ-45 ports individually configurable to 10/100/1000 BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 126W AC power supply with Power shelf and country specific power cord; user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-48D chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 44 RJ-45 ports individually configurable to 10/100/1000 BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 120W DC power supply with Power shelf; user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-48X chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 48 RJ-45 ports individually configurable to 10/100/1000BaseT, two 10 Gigabit ports, and two dedicated stacking ports. The bundle includes a 126W AC power supply with Power shelf and country specific power cord; user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-48XD chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 48 RJ-45 ports individually configurable to 10/100/1000BaseT, two 10 Gigabit ports, and two dedicated stacking ports. The bundle includes a 120W DC power supply with Power shelf; user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P48 PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 44 RJ-45 PoE ports individually configurable to 10/100/1000 BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 360W AC PoE power supply with Power shelf and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P48H PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 44 RJ-45 PoE ports individually configurable to 10/100/1000 BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 510W AC PoE power supply with Power shelf and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P48X PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 48 RJ-45 PoE ports individually configurable to 10/100/1000 BaseT, two 10 Gigabit ports, and two dedicated stacking ports. The bundle includes a 360W AC PoE power supply with Power shelf and country specific power cord, user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. The 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P48XH PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 48 RJ-45 PoE ports individually configurable to 10/100/1000BaseT, two 10 Gigabit ports, and two dedicated stacking ports. The bundle includes a 510W AC PoE power supply with Power shelf and country specific power cord, user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. The 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately.

OS6850-48XD

OS6850-P48 48 PoE ports 4 combo ports (ports 1 4) 2 stacking ports

OS6850-P48H

OS6850-P48X 48 PoE ports 2 build-in 10 Gig ports 2 stacking ports No combo ports

OS6850-P48XH

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 167 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850-U24X

OS6850-U24XD

OS6850-P24L

OS6850-P24LH

OS6850-P48L

OS6850-P48LH

OS6850-U24X chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 22 1000 Base-X SFP ports, 2 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, two 10 Gigabit ports, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 126W AC power supply with Power shelf and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-U24XD chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Gigabit Ethernet chassis in a 1U form factor with 22 1000 Base-X ports, 2 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, two 10 Gigabit ports, and two dedicated stacking ports. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 120W DC power supply with Power shelf; user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), 10 Gigabit optical transceivers (XFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P24L PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992]. L3 Ethernet chassis in a 1U form factor with 20 RJ-45 PoE ports individually configurable to 10/100BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. The 20 10/100 PoE RJ-45 ports can also operate at Gigabit speed by purchasing the OS6850-24L-UPGD software license. On the combo ports, either copper or fiber can be used on a one for one basis. The bundle includes a 360W AC PoE power supply with Power shelf, country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P24LH PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Ethernet chassis in a 1U form factor with 20 RJ-45 PoE ports individually configurable to 10/100 BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, and two dedicated stacking ports. The 20 10/100 PoE RJ-45 ports can also operate at Gigabit speed by purchasing the OS6850-24L-UPGD software license. On the combo ports, either copper or fiber can be used on a one for one basis. The bundle includes a 510W AC PoE power supply with Power shelf, country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P48L PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Ethernet chassis in a 1U form factor with 44 RJ-45 PoE ports individually configurable to 10/100BaseT, 4 combo ports configurable to be 10/100/1000BaseT or 1000BaseX, and two dedicated stacking ports. The 44 10/100 PoE RJ-45 ports can also operate at Gigabit speed by purchasing the OS6850-48L-UPGD software license. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 360W AC PoE power supply with Power shelf and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-P48LH PoE chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Ethernet chassis in a 1U form factor with 44 RJ-45 PoE ports individually configurable to 10/100 BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, and two dedicated stacking ports. The 44 10/100 PoE RJ-45 ports can also operate at Gigabit speed by purchasing the OS6850-48L-UPGD software license. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 510W AC PoE power supply with Power shelf and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 168 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850-24L

OS6850-24LD

OS6850-48L

OS6850-48LD

OS6850-BP-P OS6850-BP-PH OS6850-BP OS6850-BP-D

OS6850-CBL-30 OS6850-CBL-60 OS6850-CBL-150 OS6850-MNT OS6850-SW-AR

OS-SW-SBR-N

OS-SW-SBR-S

OS6850-24L-UPGD OS6850-48L-UPGD

OS6850-24L chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Ethernet chassis in a 1U form factor with 20 RJ-45 ports individually configurable to 10/100BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, and two dedicated stacking ports. The 20 10/100 RJ-45 ports can also operate at Gigabit speed by purchasing the OS6850-24L-UPGD software license. On the combo ports, either copper or fiber can be used on a one for one basis. The bundle includes a 126W AC power supply with Power shelf and country specific power cord; user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-24LD chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Ethernet chassis in a 1U form factor with 20 RJ-45 ports individually configurable to 10/100BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, and two dedicated stacking ports. The 20 10/100 RJ-45 ports can also operate at Gigabit speed by purchasing the OS6850-24L-UPGD software license. On the combo ports, either copper or fiber can be used on a one for one basis. The bundle includes a 120W DC power supply with Power shelf; user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-48L chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Ethernet chassis in a 1U form factor with 44 RJ-45 ports individually configurable to 10/100BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, and two dedicated stacking ports. The 44 10/100 RJ-45 ports can also operate at Gigabit speed by purchasing the OS6850-48L-UPGD software license. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 126W AC power supply with Power shelf and country specific power cord; user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. OS6850-48LD chassis w/SSL (DES, 3DES, RC2, RC4) [ECCN 5A992] L3 Ethernet chassis in a 1U form factor with 44 RJ-45 ports individually configurable to 10/100BaseT, 4 combo ports configurable to be 10/100/1000 BaseT or 1000BaseX, and two dedicated stacking ports. The 44 10/100 RJ-45 ports can also operate at Gigabit speed by purchasing the OS6850-48L-UPGD software license. On the combo ports either copper or fiber can be used on a one for one basis. The bundle includes a 120W DC power supply with Power shelf, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. Ethernet optical transceivers (SFP), stacking cable, advanced routing software, and backup power supplies can be ordered separately. Backup Power Supplies OS6850-BP-P modular 360W AC backup power supply. Provides backup power to one PoE switch. Ships with chassis connection cable, country specific power cord, power shelf and connecting ears. OS6850-BP-PH modular 510W AC backup power supply. Provides backup power to one PoE switch. Ships with chassis connection cable, country specific power cord, power shelf and connecting ears. OS6850-BP modular 126W AC backup power supply. Provides backup power to one non-PoE switch. Ships with chassis connection cable, country specific power cord, power shelf and connecting ears. OS6850-BP-D modular 120W DC backup power supply. Provides backup power to one non-PoE switch. Ships with chassis connection cable, power shelf and connecting ears. Accessories OS6850 30 centimeters long stacking cable OS6850 60 centimeters long stacking cable OS6850 150 centimeters long stacking cable Base/wall mounting kit for OS6850 models. Includes 4 brackets and screws. Advanced Routing Software OS6850 Advanced Routing software. Includes support for IPv4 Routing protocols OSPFv2, BGPv4, PIM-SM/DM and DVMRP. Includes support for IPv6 Routing protocol OSPFv3. Authenticated Services Software [ECCN 5D992] Authentication bundle for Windows w/MD5, RC4, MD4, DES. This bundle provides Funk Software's Steel-Belted Radius Enterprise Edition for Microsoft Windows and includes an oneyear maintenance contract (maintenance releases, 7X24 phone support and e-service web access). [ECCN 5D992] Authentication Bundle for Solaris w/MD5, RC4, MD4, DES. This bundle provides Funk Software's Steel-Belted Radius Enterprise Edition for Sun Solaris and includes a one-year maintenance contract (maintenance releases, 7X24 phone support and e-service web access). Upgrade Software Software license that allows 10/100 RJ45 ports of OS6850-24L and OS6850-P24L chassis to operate also at Gigabit speed. Software license that allows 10/100 RJ45 ports of OS6850-48L and OS6850-P48L chassis to operate also at Gigabit speed.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 169 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

2 x 10-Gigabit Ethernet XFP

XFP-10G-ER40

XFP-10G-LR

XFP-10G-SR

XFP-10G-ZR80

SFP-GIG-47CWD60 SFP-GIG-49CWD60 SFP-GIG-51CWD60 SFP-GIG-53CWD60 SFP-GIG-55CWD60 SFP-GIG-57CWD60 SFP-GIG-59CWD60 SFP-GIG-61CWD60 SFP-GIG-BX-D

SFP-GIG-BX-U

SFP-GIG-EXTND

SFP-GIG-LH40 SFP-GIG-LH70

SFP-GIG-LX

Transceivers 10 Gigabit Ethernet Transceivers (XFP MSA) 2 x XFP 10-GigEth ports Each 10 GigEth port supports industry standard XFP based 10GigE SMF 10GBASE-LR, MMF 10GBASE-SR, SMF 10GBASE-ER, and SMF 10GBASE-ZR optical transceivers. The applicable models provide 2 XFP slots. These slots support the following XFP types: XFP-10G-ER4010GBASE-ER Single mode fiber, supports distances up to 40km; uses LC connectors. XFP-10G-LR10GBASE-LR Single mode fiber, supports distances up to 10km; uses LC connectors. XFP-10G-SR10GBASE-SR Multimode fiber, supports distances up to 300m; uses LC connectors. XFP-10G-ZR8010GBASE-ZR Single mode fiber, supports distances up to 80km; uses LC connectors. The two-port XFP 10 Gigabit slots can mix and match different 10-Gigabit XFP transceiver types and is supported on applicable models with an X designation. Note. Compatibility with the OmniSwitch 6800 & OmniSwitch 9000 10-Gigabit Ethernet is supported. 10 Gigabit Ethernet optical transceiver (XFP MSA): Supports single mode fiber over 1550nm wavelength (nominal) with an LC connector. Typical reach of 40 Km on 9/125 m SMF. 10 Gigabit Ethernet optical transceiver (XFP MSA): Supports single mode fiber over 1310nm wavelength (nominal) with an LC connector. Typical reach of 10 Km on 9/125m SMF. [Formerly known as 10G-XFP-LR] 10 Gigabit Ethernet optical transceiver (XFP MSA): Supports multimode fiber over 850nm wavelength (nominal) with an LC connector. Typical reach of 300m on 50/125m MMF. [Formerly known as 10G-XFP-SR] 10 Gigabit Ethernet optical transceiver (XFP MSA): Supports single mode fiber over 1550nm wavelength (nominal) with an LC connector. Typical reach of 80 Km on 9/125m SMF. Gigabit Ethernet Transceivers (SFP MSA) CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ gray latch. Supports single mode fiber over 1470 nm wavelength (nominal) with an LC connector. Typical reach of 62Km on 9/125m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ violet latch. Supports single mode fiber over 1490 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ blue latch. Supports single mode fiber over 1510 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ green latch. Supports single mode fiber over 1530 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ yellow latch. Supports single mode fiber over 1550 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ orange latch. Supports single mode fiber over 1570 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ red latch. Supports single mode fiber over 1590 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125m SMF. CWDM Gigabit Ethernet optical transceiver (SFP MSA) w/ red latch. Supports single mode fiber over 1590 nm wavelength (nominal) with an LC connector. Typical reach of 62 Km on 9/125m SMF. 1000Base-BX SFP transceiver with an LC type of interface. This bi-directional transceiver is designed for use over single mode fiber optic on a single strand link up to 10 km. Transmits 1490 nm and receives 1310 nm optical signal. 1000Base-BX SFP transceiver with an LC type of interface. This bi-directional transceiver is designed for use over single mode fiber optic on a single strand link up to 10 km. Transmits 1310 nm and receives 1490 nm optical signal. Extended 1000Base-SX Gigabit Ethernet optical transceiver (SFP MSA): Supports multimode fiber over 850nm wavelength (nominal) with an LC connector. Reach of up to 2 km on 62.5/125m MMF and 50/125m MMF. Requires SFP-GIG-EXTND or GBIC-GIG-EXTND at the remote termination. [Formerly known as GE-EXTND-SFP] 1000Base-LH Gigabit Ethernet optical transceiver (SFP MSA). Supports single mode fiber over 1310 nm wavelength (nominal) with an LC connector. Typical reach of 40Km on 9/125m SMF. 1000Base-LH Gigabit Ethernet optical transceiver (SFP MSA). Supports single mode fiber over 1550nm wavelength (nominal) with an LC connector. Typical reach of 70 Km on 9/125m SMF. [Formerly known as MINIGBIC-LH-70] 1000Base-LX Gigabit Ethernet optical transceiver (SFP MSA). Supports single mode fiber over 1310nm wavelength (nominal) with an LC connector. Typical reach of 10 Km on 9/125m SMF. [Formerly known as MINIGBIC-LX]

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 170 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

SFP-GIG-SX

SFP-GIG-T

SFP-DUAL-MM

SFP-DUAL-SM10

SFP-100-BX20LT

SFP-100-BX20NU

SFP-100-LC-MM SFP-100-LC-SM15 SFP-100-LC-SM40

1000Base-SX Gigabit Ethernet optical transceiver (SFP MSA): Supports multimode fiber over 850nm wavelength (nominal) with an LC connector. Typical reach of 300m on 62.5/125m MMF or 550m on 50/125m MMF. [Formerly known as MINIGBIC-SX] 1000Base-T Gigabit Ethernet Transceiver (SFP MSA) - Supports category 5, 5E, and 6 copper cabling up to 100m. SFP only works in 1000 Mbps speed and full-duplex mode. Dual Speed Ethernet Transceivers (SFP MSA) Dual Speed 100Base-FX or 1000Base-X Ethernet optical transceiver (SFP MSA). Supports multimode fiber over 1310nm wavelength (nominal) with an LC connector. Typical reach of 550m at Gigabit speed and 2km at 100Mbit speed. - At 100Mbit speed, this SFP can interoperate with SFP-100-LC-MM or similar transceiver on the other end - At Gigabit speed, this SFP cannot interoperate with SFP-GIG-SX or similar transceiver on the other end running over 850nm wavelength. - SFP supported on OS9-GNI-U24 Gigabit Ethernet Module and OS6850-U24X SFP ports (non combo) Dual Speed 100Base-FX or 1000Base-X Ethernet optical transceiver (SFP MSA). Supports single mode fiber over 1310nm wavelength (nominal) with an LC connector. Typical reach of 10km at Gigabit speed and 100Mbit speed. - At 100Mbit speed, this SFP can interoperate with SFP-100-LC-SM15 or similar transceiver - At Gigabit speed, this SFP can interoperate with SFP-GIG-LX or similar transceiver. - SFP supported on OS9-GNI-U24 Gigabit Ethernet Module and OS6850-U24X SFP ports (non combo) 100BASE-FX Ethernet Transceivers 100Base-BX SFP transceiver with an SC type interface. This bi-directional transceiver is designed for use over single mode fiber optic on a single strand link up to 20km point-to-point. This transceiver is normally used in the central office (OLT) transmits 1550nm and receives 1310nm optical signal 100Base-BX SFP transceiver with an SC type interface. This bi-directional transceiver is designed for use over single mode fiber optic on a single strand link up to 20km point-to-point. This transceiver is normally used in the client (ONU) transmits 1310nm and receives 1550nm optical signal 100Base-FX SFP transceiver with an LC type interface. This transceiver is designed for use over multimode fiber optic cable. 100Base-FX SFP transceiver with an LC type interface. This transceiver is designed for use over single mode fiber optic cable up to 15km. 100Base-FX SFP transceiver with an LC type interface. This transceiver is designed for use over single mode fiber optic cable up to 40km.

Supported Configuration Matrix for New Ethernet Transceivers in Release 6.1.5r01 OS6800/OS6850 Combo OS6800-U24 OS6850-U24X Ports Non-Combo Ports SFP-GIG-T - 1000Base-T Gigabit Supported Supported Supported Ethernet Transceiver (SFP MSA). SFP-DUAL-MM - Dual Speed OS6800: Un-supported Un-supported Supported 100Base-FX or 1000Base-X Ethernet optical OS6850: Supported. transceiver. Release 6.3.1 provides support for this SFP on OS6850 combo ports. SFP-DUAL-SM10 - Dual Speed OS6800: Un-supported Un-supported Supported 100Base-FX or 1000Base-X Ethernet optical OS6850: Supported. transceiver (SFP MSA) Release 6.3.1 provides support for this SFP on OS6850 combo ports. SFP-100-BX20LT - 100Base-BX Un-supported Un-supported Supported SFP bi-directional transceiver. SFP-100-BX20NU - 100Base-BX Un-supported Un-supported Supported SFP bi-directional transceiver. SFP-100-LC-MM - 100Base-FX Un-supported Un-supported Supported SFP transceiver. SFP-100-LC-SM15 - 100Base-FX Un-supported Un-supported Supported SFP transceiver. SFP-100-LC-SM40 - 100Base-FX Un-supported Un-supported Supported SFP transceiver. SFP

OS9-GNI-U24 Supported Supported

Supported

Un-supported Un-supported Un-supported Un-supported Un-supported

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 171 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

MAC Address Table (L2 Unicast MAC addresses) Learned Port Security What is the maximum number of MAC addresses a port can learn? IP Address Table Routes (RIB) L3 IPv4 Host Entries (FIB) L3 IPv4 LPM Routes (FIB) L3 IPv6 Host Entries (FIB) L3 IPv6 LPM Routes (FIB) Hardware Tunnels/Trunks Flows/ACLs Meters Counters Packet Buffer Size per system

Hardware Architecture Up to 16 K (16,384) MAC Addresses is supported per system. For the OmniSwitch 6850 family, the learned port security feature of the Alcatel-Lucent Operating System allows up to 100 MAC addresses per port to be learned and acted upon, with up to 8,192 per switch. The maximum number of MAC addresses the switch can learn for Layer 2 forwarding is 16,384 simultaneous MAC addresses. 48K routing table 8K 12K 4K 6K 128 2K 2K 2K 2MB of buffering available per system Each port type regardless of port speed is assigned a minimum and a maximum threshold buffer space. Buffering is supported per port and there is a shared pool of up to 2MB available per system that is based on an optimization algorithm that monitors buffer allocation per port. The buffering algorithm could be optimized to allocate the unused buffering space for the inactive ports to the active ports. In other words, inactive ports buffer space can be used by those ports that are active and require more buffering space if need be. * 2,097,152 bytes of buffering available per system. * Two buffer allocation thresholds: LwmCosSetLimit and DynCellLimit. There is one of each type of threshold per queue. Each queue is defined by a {port, COS} combination. There are 8 COS in our system, the highest COS is reserved for internal traffic while the user can assign the other 7. * LwmCosSetLimit is the Low Water Mark for buffer allocation per queue. Beyond this mark a queue will tap into a dynamically shared buffer pool. * DynCellLimit is the stop threshold for a queue to acquire more buffer from the pool. Both of the above thresholds have been pre-determined and calculated for optimal performance under our benchmark. The default will automatically tap into shared buffer resources whenever the situation demands it. If the users wish to customize the buffer sizes, we are usually able to accommodate the request by analyzing their traffic pattern. Free-scale MPC8248 processor (400MHZ) Hi-Gig (Hi-Gig+ capable) & 32-bit 66MHZ PCI BUS & I2C BUS 256MB of SDRAM SO-DIMM is default (upgradeable to 512MB) Boot Flash: default 8MB upgradeable to 32MB File System Flash: default 64MB of Compact FLASH for O/S storage Philips ISP1761 USB2.0 port on the front panel OS6850-48 & P48: BCM56504 XGS Switch & BCM56502 XGS Switch OS6850-48X & P48X: BCM56504 XGS Switch & BCM56504 XGS Switch OS6850-24 & P24: BCM56502 XGS Switch OS6850-24X & P24X: BCM56504 XGS Switch 10-Gigabit Ethernet XAUI interface (as applicable) : BCM8704 5464SR & 5464R XFP, SFP, and RJ45 connectors Supports up to 8 unit stacking topology Two built-in stacking ports to provide fault tolerant looped stacking configuration 10 Gbps full-duplex bandwidth per stacking port RS-232 Console Port (RJ-45 connector). The console-protecting chip SEMTEC LCDA15C-6 is used along with the RJ45 connector. OS6850-24, -24X, -P24, -P24X, - 48, -P48: four Gigabit Ethernet SFP combo ports OS6850-24L, -P24L, - 48L, -P48L: four Gigabit Ethernet SFP combo ports OS6850-U24X: two Gigabit Ethernet SFP combo ports OS6850-24X, -P24X, -48X, -P48X and -U24X Two built-in XFP ports that support industry standard XFP-based 10GigE optical transceivers

CPU BUS Memory Flash USB Port (Future Release) Main Switching Fabric ASIC

10-Gigabit Ethernet Interface PHY Connectors Stacking

Console Port Combo Ports

10GigE Uplinks

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 172 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

POE /(Power over Ethernet) In-line Power EEPROM Front Panel LED Temperature Sensor Thermal detection & Shutdown Clock Power Supply

Fans LEDS

The OmniSwitch 6850 Series platforms are 1U (Rack Unit) high 19" Rack-Mountable The OmniSwitch 6850 Series platforms are No more than 16.73 deep (including the power supplies) Dynamic and automatic module ID selection All models conform to Alcatel-Lucent coloring and labeling scheme Switch Faade for Alcatel-Lucent label 100BASE-FX 1000BASE-T SFP 1000BASE-SX SFP 1000BASE-LX SFP 1000BASE-LH (70Km) SFP 1000BASE-CWDM (CWDM Wavelength grid)) SFP 10GBASE-SR in XFP MSA form factor 10GBASE-LR in XFP MSA form factor 10GBASE-ER40 in XFP MSA form factor 10GBASE-ZR80 in XFP MSA form factor Grounding lugs Mounting holes on the side, near the front and back of the chassis RS-232 connector for console connection on the front pane USB port on the front panel (Version 2.0 full speed min.) 7 segment LED stack# display on the front panel Port LED Standard OK1 & OK2 LEDs Port Numbering scheme with first port in the upper left hand corner Power Supply Failure LED

Support POE with full compliance of IEEE 802.3af Board ID EEPROM Atmel 24C02 (on based-board) Front Panel 7-segment LED display for stack ID Temperature Sensor National Semi-Conductor LM77 is supported Thermal detection and shutdown is supported. Real Time Clock chip M41T11 Main and backup power supplies are external either directly connected to the rear of the unit or remotely mounted. Supports redundant dual hot swappable power supplies (Redundant Power Supply (RPS) AC-to-DC and DC-to-DC N+1 redundant P/Ss are supported) Power shelf that holds one 510W AC or two 360W AC, 126W AC or 120W DC power supplies (Out of box SPS with selection for Mono 510W or dual 360W and RUP is supported) 3 fans for the chassis with FAN failure detection. Additional fans built in the power supplies. Per port Link/Activity/PoE monitoring LED support System Power, BPS, and Diagnostic LED support LEDS: LED Status on Front Panel o OK (Diag/OK/Fan fail/Temp fail) o PRI (Primary/Secondary) o PWR (Main Power Supply Status) o RPS (Redundant Power Supply Status) Single LED with dual color is used for each Gig Ethernet Port (link/activity/POE) Single LED is used for each 10Gig Ethernet Port Single LED is used for the fiber SFP ports. Hardware Device Level features supported Supported. Supported. Supported. Supported Supported Supported The 100BASE-FX will be supported on the OS6850-U24X & OS6850-U24XD only on 20 fiber ports, and not on 4 combo ports Supported. Supported Supported Supported 1000BASE-CWDM (CWDM Wavelength grid)) SFP is supported. Supported Supported Supported. Supported. Supported Supported Supported Supported (Future Release) Supported Supported Supported Supported Indicating which PS has failed: Supported

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 173 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Temperature Threshold Exceeded LED FAN failure LED Primary unit LED (designate the master unit in a stack configuration) Secondary unit LED (designate the master unit in a stack configuration) LED for BPS status AC and DC power supplies AC Power Supply: power source 115-200 V AC, 50-60 Hz DC power supply: 36 72 V DC (input) 360W AC-to-DC Power Supply 510W AC-to-DC Power Supply 126W AC-to-DC Power Supply 120W DC-to-DC Power Supply Single main power supply to provide power for chassis and POE POE back up power POE interface compatible with PowerDsine Ron chip Low POE power (24 ports) 10watts/port Low POE power (48 ports) 5watts/port High POE power (24 ports)-16.25watts/port High POE power (48 ports) 8.125watts/port Redundant dual hot swappable Power Supplies. Integrated in OS6850 Series units. Power supplies are able to attach to the rear of the unit Insertion or removal of redundant power supply Remote mounting of both primary and backup power supplies Single BPS for chassis and POE Modular 510W BPS for POE that fits in the OS6850 BPS shelf. BPS Power Supply bundle (2.5U power shelf for BPS, power cord, BPS, chassis connection cable) Circuit breaker protected OS6850 units Redundant Fans support Noise level Operating Temperature Storage Temperature Operating Humidity Storage Humidity Loop protection against loop back Cisco-like Proprietary UDLD Support Cat 5, 5e, 6, and 6e Capability to disable transmit function (or reset) of each PHY individually Capability to control the transmit function of the SFP and XFP ports Compatible stacking connectors and cables with OS6800 Series platforms (30 cm, 60 cm and 1m)

Supported Supported Supported Supported Supported Supported Supported Supported Supported for: OS6850-P24 & OS6850-P24L & OS6850-P24X & OS6850-P48 & OS6850-P48L & OS6850-P48X Supported for: OS6850-P24H & OS6850-P24LH & OS6850-P24XH & OS6850-P48H & OS6850-P48LH & OS6850-P48XH Supported for: OS6850-24 & OS6850-24L & OS6850-24X & OS6850-48 & OS6850-48L & OS6850-48X & OS6850-U24X Supported for: OS6850-24D & OS6850-24LD & OS6850-24XD & OS6850-48D & OS6850-48LD & OS6850-48XD & OS6850-U24XD Supported Supported Supported Supported Supported Supported Supported 360W BPS is attached to the rear of the chassis. 510W RPS is external in 2U configuration Supported Insertion or removal of redundant power supply does not cause any power or service disruption to the switch Supported Supported Supported Power supply bundle is 1U 360W or 510W + shelf_cable+19 Rack mounts ears .BPS can be either connected at the back of the unit (360W) or on top of the unit (510W). Supported 1:N redundancy All OmniSwitch 6850 platforms: < 50dBa 0 C to 45 C (32 to 112 F) 10 C to 70 C (14 to 158 F) 5% to 95% (non-condensing) 5% to 95% (non-condensing) Supported UDLD is supported. support for monitoring the physical configuration of cables and detect unidirectional links Supported Supported Supported Supported

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 174 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Stacking (Virtual Chassis Architecture)

Stacking feature Virtual chassis, single IP for management o Stack is managed through a single IP address - Virtual Chassis concept is supported Two built-in stacking ports o 10 Gbps full-duplex bandwidth per stacking port Fault tolerant looped stacking configuration Dedicated 2 x 10Gigabit stacking links on each model Stacking of OS6850 platforms is supported up to a maximum of 8 units per stack. o Up to 8 chassis in a stack 384 Gigabit ports 16 10 Gig ports PoE and non-PoE can be mixed No need of tokens as in OS6800 OS6850-U24X / -U24XD are stackable Primary, secondary, idle and pass-through elements in the stack Stack module IDs are set using CLI and displayed on the panel Each module in the stack is capable to act as Primary 1. Only support 8 stacks in a stacking configuration. 2. The redundant stacking cable must be in place to support the full virtual Chassis. 3. Auto Configuration of the stacks 4. OmniSwitch 6850 units and OmniSwitch 6800 units should not be mixed in the same stack. If the switches connected in a stack is having duplicate slot numbers one of the units will go into the pass through mode. When a switch is in pass-through mode, its Ethernet ports are brought down but stacking cable connections remain fully functional and can pass traffic through to other switches in the stack. To avoid duplicate slot numbers, make sure that any modules being added to an existing stack have been cleared of pre-assigned slot information. When inserting switches into an existing stack, observe the following guidelines: Make sure the stack is fully certified/synchronized Avoid duplicate saved slot numbers Make sure that the system is powered up and initialized completely. Never attempt to operate more than eight switches in a single stack Insert one unit at time with one stacking uplink only. Repeat with other unit if needed Once all units have been fully inserted, then close the stacking loop Time measured for Synchronization of the stack on OS6850 (stack of 8): 7-8 min. The new images are downloaded to the primary working directory. The reload working no rollback which updates all the NIs working directories will take an activating time up to 5 minutes (i.e. size of the configuration file does not impact the time). After system is up and "copy working certified flash-synchro which synchronizes the whole stack will take about 2 to 2.5 minutes (i.e. size of the configuration file does not impact the time) As a remainder, the following features are impacted on takeover -Spanning Tree may reconvergence after takeover, since base-Mac of the chassis will change (that Mac change may cause a root bridge change) -IPv4 routing: the router Mac change on takeover will cause the router to rediscover the new router Mac -Same for IPV6 (link local address changes on takeover) -LACP protocol need to restart causing LACP ports to go down

Stacking Guidelines

Stacking Redundancy

Unit Self Management

Automatic Over-Temp Shutdown Provide user configuration to disable/override temperature shutdown Temperature Threshold Exceeded FAN Failure Trap (sent every 5-min) Inventory Support Supported Supported Supported Trap (Sent every 5-min.) Supported Supported

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 175 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Data Plane
IEEE 802.3z & 802.3ab & 802.3u & 802.3 Auto-Detect on both Copper and Fiber Simultaneous detection configuration priority Media failure failover capability 802.3af on POE Models Hot Swappable Auto-negotiation/Auto sensing 10/100/1000 Auto-Detect the insertion and removal of the SFP Hardware to operate at HiGig and HiGig+ speeds UNH (or equivalent) operation standards Connectors/ Cabling Supported Supported Supported Supported Supported: Power over Ethernet is supported on 10/100/1000BASE-T ports only SFP and XFP optical transceivers are hot swappable Supported Supported Supported (currently the HiGig operation is implemented, but the hardware is HiGig+ capable) Supported

Ethernet Specifications
Management: 1 RJ-45 console interface configured as DCE/DTE for operation, diagnostics, status, and configuration information. Ship kit includes RJ-45 to DB-9 connector adaptor AC power connector 10/1000/1000BASE-T copper ports: RJ-45 10/100/1000BASE-T copper ports with PoE: RJ-45 1000BASE-X SFP ports: LC with Removable/Pluggable transceiver SFP-MSA 10GBASE-X XFP ports: LC with Removable/Pluggable XFP-MSA transceiver 24 & 48 x 10/1000/1000BASE-T copper ports: RJ-45 24 & 48 x 10/100/1000BASE-T copper ports with PoE: RJ-45 24 & 48 x 1000BASE-X SFP ports: LC with Removable/Pluggable transceiver SFP-MSA 10GBASE-X XFP ports: LC with Removable/Pluggable XFP-MSA transceiver 10BASE-T hub or device; 100BASE-TX hub or device; 1000BASE-T hub or device 1000BASE-X hub or device, and 10GBASE-X hub or device 10BASE-T: unshielded twisted-pair (UTP) 100BASE-TX: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm 1000BASE-T: unshielded twisted-pair (UTP), Category 5, EIA/TIA 568 or shielded twisted-pair (STP), Category 5, 100 ohm Note: Category 6 cabling is also supported on the 10/100/1000BASE-T connections. On 10/100/1000Mbps triple speed ports: 10Mbps speed: 100 meters on copper 100Mbps speed: 100 meters on copper 1000Mbps speed: 100 meters on copper On GigE. Fiber: SFP-GIG-LH70: up to 70km SFP-GIG-LX: up to 10km SFP-GIG-SX: up to 550m CWDM: up to 62km On 10GigE. Fiber: XFP-10G-ZR80 10 Gigabit Ethernet optical transceiver (XFP MSA): Supports single mode fiber over 1550nm wavelength (nominal) with an LC connector. Typical reach of 80 Km on 9/125m SMF. XFP-10G-ER40 10 Gigabit Ethernet optical transceiver (XFP MSA): Supports single mode fiber over 1550nm wavelength (nominal) with an LC connector. Typical reach of 40 Km on 9/125 m SMF. XFP-10G-SR: 300 m (high modal bandwidth fiber is required to reach 300 meters) 10 Gigabit Ethernet optical transceiver (XFP MSA): Supports multimode fiber over 850nm wavelength (nominal) with an LC connector. Typical reach of 300m on 50/125m MMF. XFP-10G-LR: 10 km 10 Gigabit Ethernet optical transceiver (XFP MSA): Supports single mode fiber over 1310nm wavelength (nominal) with an LC connector. Typical reach of 10 Km on 9/125m SMF.

Connector type

Connectivity

Connections supported Cable supported

Maximum cable distance

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 176 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IEEE Standards Supported Data rates

Ports Supported

Switching/Routing Support Backbone Support Port Mirroring Support 802.1Q Hardware Tagging Maximum Transfer Unit -- MTU

Inter-Frame Gap

Interface Alias (Port Alias)

Peak Flood Rate Configuration

802.3 Carrier Sense Multiple Access with Collision Detection (CSMA/CD) 10/100/1000Mbps triple speed o 10Mbps o 100Mbps o 1000Mbps (Gigabit Ethernet) Gigabit Ethernet 10000Mbps (10-Gigabit Ethernet) Triple Speed ports is supported and includes: o Ethernet (10 Mbps) o Fast Ethernet (100 Mbps) o 1000Mbps Ethernet (Gigabit Ethernet) Gigabit Ethernet 10-Gigabit Ethernet Layer 2 Switching/Layer 3 Routing 10/100/1000Mbps, Gigabit Ethernet ports, and 10-Gigabit Ethernet ports 10/100/1000Mbps, Gigabit Ethernet ports, and 10-Gigabit Ethernet ports 10/100/1000Mbps, Gigabit Ethernet ports, and 10-Gigabit Ethernet ports MTU parameter for Routers is not configurable. The ASIC does not include the notion of an MTU that applies to an IP interface. Instead, it uses the physical long-frame-size of the egress port as the MTU. When the ASIC attempts to forward a packet, it tests the size of the packet against the physical long-frame-size of the egress port, if the packet is too large, it forwards the packet to the CPU for fragmentation (or ICMP processing in the case of a packet with Don't Fragment set). 10/100 ports are set with a long-frame-size of 1553 bytes. GigE/10GigE ports are set with a long-frame-size of 9216 bytes (jumbo frames). Packets larger than the long-frame-size are dropped at ingress. The above (& default) values are the maximum configurable values. Packets that are forwarded from a 10/100 to a 10/100 port cannot ever be reported as too big via ICMP because anything larger than 1553 would not be accepted. The same holds true for packets forwarded between two GigE/10GigE ports and from a 10/100 port to a GigE/10GigE. Layer-2 Ethernet Frame Size: Untagged: 1,518 Bytes without IEEE 802.1Q tags Tagged: 1,522 Bytes with IEEE 802.1Q tags Long Frame Size (enabled by default): 1553 Bytes (IEEE 8021.Q tagged or untagged) Frame Type: Type2, LLC, SNAP, RAW 802.3 The maximum frame size on the Gigabit Ethernet interfaces range from 1,518 to 9,216 Bytes Jumbo frames up to 9K Bytes (9,216 Bytes) are supported on GigE/10GigE interfaces. Untagged (without IEEE 802.1Q tags) Ethernet Packets: 1,518 Bytes Tagged (with IEEE 802.1Q tags) Ethernet Packets: 1,522 Bytes 12 Bytes (by default) Inter-frame gap is a measure of the minimum idle time between the end of one frame transmission and the beginning of another. By default, the inter-frame gap is 12 bytes. Through the use of this feature, the inter-frame gap value (in bytes) on a specific port, a range of ports, or all ports on a switch (slot) can be configured. Values for this command range from 9 to 12 bytes. Note. This command is only valid on Gigabit ports. Supported (none configured by default): Through the use of this feature an alias (i.e., description) for a single port can be configured. (You cannot configure an entire switch or a range of ports.) The text description can be up to 40 characters long. By default: 42Mbps (Fast Ethernet) 496Mbps (Gigabit Ethernet) 997Mbps (10-Gigabit Ethernet) By default, the flood rate is 42 Mbps on 10/100/1000 ports and 496 Mbps on Gigabit ports. Through the use of this feature, the peak ingress flood rate value on a specific port, a range of ports, or all ports on a switch (slot) in megabits per second can be configured. Note. The user can configure a flood rate equal to the line rate, but it is not recommended. AlcatelLucent recommends that you always configure the flood rate to be less than the line speed.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 177 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Flow Control

Trap Port Link Messages

Per port rate limiting Per-port L2/L3 multicast & broadcast flood limit is supported. Re-settable Statistics Counters Duplex Mode support

Auto-negotiation Crossover

Verifying Ethernet Port Configurations

Diagnostics

The flow command can be used to enable (the default) or disable flow control on a specific port, a range of ports, or all ports on an entire switch (slot). When the buffers on a receiving device are full, flow control transmits pause frames to the remote link partner to delay transmission. IEEE 802.3x (programmable threshold) flow control. Note: the switch does not support honoring the incoming (RX) IEEE 802.3x pause frames, but it does support generating outgoing (TX) IEEE 802.3x pause frames Supported (disabled by default) This feature can be enabled or disabled (the default) on a specific port, a range of ports, or all ports on a switch (slot). When enabled, a trap message will be displayed on a Network Management Station (NMS) whenever the port state has changed. Per-port multicast / broadcast / flood limit is supported. The ASIC provides a per port configuration on the incoming and/or outgoing port basis that allows broadcast and/or multicast storm control. The CPU can program a threshold value per port that indicates the number of broadcast and/or multicast packets/bytes that are allowed in a given time interval. Supported The duplex mode feature is supported on a specific port, a range of ports, or all ports on a switch (slot). It can be set to full (full duplex mode, which is the default on fiber ports), half (half duplex mode), and auto (auto-negotiation, which is the default on copper ports). The Auto option causes the switch to advertise all available duplex modes (half/full/both) for the port during auto-negotiation. In full duplex mode, the interface transmits and receives data simultaneously. In half duplex mode, the interface can only transmit or receive data at a given time. Auto-negotiation is supported (enabled by default). It can be enabled or disabled on a single port, a range of ports, or an entire slot. Crossover can be configured on a single port, a range of ports, or an entire slot. If auto negotiation is disabled, auto MDIX, flow control, auto speed, and auto duplex are not accepted. Setting the crossover configuration to auto will configure the interface or interfaces to automatically detect crossover settings. Setting crossover configuration to mdix will configure the interface or interfaces for MDIX (Media Dependent Interface with Crossover), which is the standard for hubs and switches. Setting crossover to mdi will configure the interface or interfaces for MDI (Media Dependent Interface), which is the standard for end stations. And setting the crossover configuration to disable will disable crossover configuration on an interface or interfaces. To display information about Ethernet port configuration settings, use the show commands. These commands can be quite useful in troubleshooting and resolving potential configuration issues or problems on your switch. For more information about the resulting displays from these commands, see the OmniSwitch CLI Reference Guide. Off-line Diagnostics for manufacturing OmniSwitch 6850 Series supports the capability to reboot to support Diagnostics Mode for Customers for hardware only troubleshooting Not to require external PCs or test equipment for running diagnostics

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 178 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Perfformance Pe rf ormanc e r
Raw Fabric Capacity OS6850-48/-48D/-48L/-48LD: 96Gbps Full Duplex or 192Gbps aggregate OS6850-48X/-48XD: 120Gbps Full Duplex or 240Gbps aggregate OS6850-P48/-P48H/-P48L/-P48LH: 96Gbps Full Duplex or 192Gbps aggregate OS6850-P48X/-P48XH: 120Gbps Full Duplex or 240Gbps aggregate OS6850-24/-24D/-24L/-24LD: 48Gbps Full Duplex or 96Gbps aggregate OS6850-24X/-24XD: 72Gbps Full Duplex or 144Gbps aggregate OS6850-P24/-P24H/-P24L/-P24LH: 48Gbps Full Duplex or 96Gbps aggregate OS6850-P24X/-P24XH: 72Gbps Full Duplex or 144Gbps aggregate OS6850-U24X/U24XD: 72Gbps Full Duplex or 144Gbps aggregate Raw Capacity: 24Gbps FD (12Gbps FD Stack-A and 12Gbps FD Stack-B) Throughput: The Stacking (Stack A & Stack B run at 10G) supports 2 x 10-Gigabit Eth ports at wire-speed: 2 * 14,880,952.3 pps = 29,761,904.6pps (approx: 29.8Mpps) Theoretical packet per second (pps) rates for Ethernet packets is normally calculated by adding 20 bytes to each packet size to account for the 0.096 microseconds inter frame gap (equivalent to 12 bytes) and the preamble (eight bytes). Thus, the theoretical 10 Mbps, 100 Mbps, Gigabit and 10-Gigabit Ethernet packet rate in packets per second (pps) for a packet of X bytes is defined by the following formulas. Throughput calculations assume 64 byte packets and the throughput rate is calculated per-port. (10 Gbps) / ((8 bits/ byte) * (X+20)) = 14,880,952.3 pps (1 Gbps) / ((8 bits/ byte) * (X+20)) = 1,488,095.23 pps (100 Mbps) / ((8 bits/ byte) * (X+20)) = 148,809.52 pps (10 Mbps) / ((8 bits/ byte) * (X+20)) = 14,880.95 pps Since the primary benefit of any switch is speed, the most appropriate performance metric is throughput, which is typically expressed in millions of packets per second (Mpps). Throughput measures the number of packets per second (measured in millions) that a switch can process for outbound (egress direction only) transmission to another device. Throughput (at Layer-2 or Layer-3) = wire-speed Eth. ports * throughput rate per port Note: The following assumes that all traffic is forwarded through the Main Switch Fabric ASIC. The Stacking (Stack A & Stack B) supports 2 x 10-Gigabit Eth ports at wire-speed: 2 * 14,880,952.3 pps = 29,761,904.6pps (approx: 29.8Mpps) The 2-port 10-Gigabit Eth uplink supports 2 x 10-Gigabit Eth ports at wire-speed: 2 * 14,880,952.3 pps = 29,761,904.6pps (approx: 29.8Mpps) The 24 Gigabit Eth ports throughput at wire-speeds: 24 * 1,488,095.23 pps = 35,714,285.52pps (approx: 35.7Mpps) The 48 Gigabit Eth ports throughput at wire-speeds: 48 * 1,488,095.23 pps = 71,428,571.04pps (approx: 71.4Mpps) The 20 x 10/100Mbps Eth ports throughput at wire-speeds: 20 * 148,809.52 pps = 2,976,190.4pps (approx: 2.97Mpps) The 44 x 10/100Mbps Eth ports throughput at wire-speeds: 44 * 148,809.52 pps = 6,547,618.88pps (approx: 6.54Mpps) The 4 Gigabit Eth ports throughput at wire-speeds: 4 * 1,488,095.23 pps = 5,952,380.92pps (approx: 5.95Mpps) Throughput numbers per models ( in stacked configuration): OS6850-48/-48D/-P48/-P48H (48 GE ports + 2 10G stacking): 101.2Mpps OS6850-48X/-48XD/-P48X/-P48XH (48 GE ports + 2 10G uplinks + 2 10G stacking): 131Mpps OS6850-24/-24D/-P24/-P24H (24 GE ports + 2 10G stacking): 65.5Mpps OS6850-24X/-24XD/-P24X/-P24XH (24 GE ports + 2 10G uplinks + 2 10G stacking): 95.3Mpps OS6850-U24X/-U24XD (24 GE ports + 2 10G uplinks + 2 10G stacking): = 95.3Mpps OS6850-24L/-24LD/-P24L/-P24LH ( 20 10/100Mbps ports + 4 GE combo ports + 2 10G stacking): 38.72Mpps OS6850-48L/-48LD/-P48L/-P48LH (44 10/100Mbps ports + 4 GE combo ports + 210G stacking): 42.29Mpps Note: the following throughput calculations assumes that the L Series have been upgraded with the OS6850-24L-UPGD* and OS6850-48L-UPGD* Software Packages in other words the throughput calculations are based on 10/100/1000Mbps forwarding rates:

Stacking Capacity & Throughput

Throughput Performance Or Forwarding Rate Per Stacked Switch

@64Byte Packets
Assuming: All traffic is forwarded through The Switch Fabric ASIC And where applicable: o Including the 2-port 10GigE uplink module throughput

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 179 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850-48L/-48LD/-P48L/-P48LH (48 GE ports + 2 10G stacking) : 101.2Mpps OS6850-24L/-24LD/-P24L/-P24LH (24 GE ports + 2 10G stacking): 65.5Mpps Notes: For stand-alone configuration throughput numbers on all models please subtract 29.8Mpps Throughput Performance Or Forwarding Rate Per Stacked Switch Theoretical packet per second (pps) rates for Ethernet packets is normally calculated by adding 20 bytes to each packet size to account for the 0.096 microseconds inter frame gap (equivalent to 12 bytes) and the preamble (eight bytes). Thus, the theoretical 10 Mbps, 100 Mbps, Gigabit and 10-Gigabit Ethernet packet rate in packets per second (pps) for a packet of X bytes is defined by the following formulas. Throughput calculations assume 1518 byte packets and the throughput rate is calculated per-port. (10Gbps) / ((8 bits/ byte) * (X+20)) = 812,743.82 pps (1Gbps) / ((8 bits/ byte) * (X+20)) = 81,274.38 pps (100 Mbps) / ((8 bits/ byte) * (X+20)) = 8,127.43 pps (10 Mbps) / ((8 bits/ byte) * (X+20)) = 812.74 pps Since the primary benefit of any switch is speed, the most appropriate performance metric is throughput, which is typically expressed in millions of packets per second (Mpps). Throughput measures the number of packets per second (measured in millions) that a switch can process for outbound (egress direction only) transmission to another device. Throughput (at Layer-2 or Layer-3) = wire-speed Eth. ports * throughput rate per port Note: The following assumes that all traffic is forwarded through the Main Switch Fabric ASIC. The Stacking (Stack A & Stack B) supports 2 x 10-Gigabit Eth ports at wire-speed: 2 * 812,743.82 pps = 1,625,487.64pps (approx: 1.62Mpps) The 2-port 10-Gigabit Eth uplink supports 2 x 10-Gigabit Eth ports at wire-speed: 2 * 812,743.82 pps = 1,625,487.64pps (approx: 1.62Mpps) The 24 Gigabit Eth ports throughput at wire-speeds: 24 * 81,274.38 pps = 1,950,585.12pps (approx: 1.95Mpps) The 48 Gigabit Eth ports throughput at wire-speeds: 48 * 81,274.38 pps = 3,901,170.24pps (approx: 3.9Mpps) The 20 x 10/100Mbps Eth ports throughput at wire-speeds: 20 * 8,127.43 pps = 162,548.6pps (approx: 162.5Kpps) The 44 x 10/100Mbps Eth ports throughput at wire-speeds: 44 * 8,127.43 pps = 357,606.92pps (approx: 357.6Kpps) The 4 Gigabit Eth ports throughput at wire-speeds: 4 * 81,274.38 pps = 325,097.52pps (approx: 325.09Kpps) OS6850-48/-48D/-P48/-P48H (48 GE ports + 2 10G stacking): 5.52Mpps OS6850-48X/-48XD/-P48X/-P48XH (48 GE ports + 2 10G uplinks + 2 10G stacking): 7.14Mpps OS6850-24/-24D/-P24/-P24H (24 GE ports + 2 10G stacking): 3.57Mpps OS6850-24X/-24XD/-P24X/-P24XH (24 GE ports + 2 10G uplinks + 2 10G stacking): 5.19Mpps OS6850-U24X/-U24XD (24 GE ports + 2 10G uplinks + 2 10G stacking): = 5.19Mpps OS6850-24L/-24LD/-P24L/-P24LH ( 20 10/100Mbps ports + 4 GE combo ports + 2 10G stacking): 2.18Mpps OS6850-48L/-48LD/-P48L/-P48LH (44 10/100Mbps ports + 4 GE combo ports + 210G stacking): 2.3Mpps Note: the following throughput calculations assumes that the L Series have been upgraded with the OS6850-24L-UPGD* and OS6850-48L-UPGD* Software Packages in other words the throughput calculations are based on 10/100/1000Mbps forwarding rates: The OS6850-48L/-48LD/-P48L/-P48LH supports up to 48 GigE ports at wire-speeds: 5.52Mpps The OS6850-24L/-24LD/-P24L/-P24LH supports up to 24 GigE ports at wire-speeds: 3.57Mpps Notes: For stand-alone configuration throughput numbers on all models please subtract 1.62Mpps Layer-2 & Layer-3 Forwarding Rate Per port Wire-speed on 10Mbps port 14,880 pps with 64 Byte packets Wire-speed on 100Mbps port 148,809 pps with 64 Byte packets Wire-speed on Gigabit Ethernet port 1,488,095 pps with 64 Byte packets Wire-speed on 10-Gigabit Ethernet port 14,880,952 pps with 64 Byte packets The 2-port 10-Gigabit Ethernet uplink supports 2 x 10-Gigabit Eth. ports at wire-speed. The Stacking (Stack A & Stack B) supports 2 x 10-Gigabit Eth ports at wire-speed.

@1518Byte Packets
Assuming: All traffic is forwarded through The Switch Fabric ASIC And where applicable: o Including the 2-port 10GigE uplink module throughput o Stacking (Stack A & Stack B) throughput

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 180 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Latency

Notes for latency: Latency test results generated by IXIA Device Version 3.65.284 SW Version: AOSv6.1.1r01 GA Release RFC 2544 Latency Test Latency Measurement Type: First bit In to First bit Out ----- FIFO Protocol: the Layer-2 & Layer-3 Frame Rate: 100%

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 181 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The OmniSwitch 6850 Layer-2 & Layer-3 Latencies / Throughput

Port Speed: 10-Gigabit Latency Throughput 64 Byte Packets Estimated around 11.2 s Wire-speed: 10000Mbps Full Duplex Port: 14,880,952pps 64 Byte Packets Estimated around 11.6 s Wire-speed: 1000Mbps Full Duplex Port: 1,488,096pps 64 Byte Packets Estimated around 68.4 s Wire-speed: 100Mbps Full Duplex Port: 148,810pps 64 Byte Packets Estimated around TBD s Wire-speed: 10Mbps Full Duplex Port: 14,881pps 1518 Byte Packets Estimated around 12.5 s Wire-speed: 10000Mbps Full Duplex Port:812,744pps 1518 Byte Packets Estimated around 23.2 s Wire-speed: 1000Mbps Full Duplex Port: 81,275pps 1518 Byte Packets Estimated around 184.6 s Wire-speed: 100Mbps Full Duplex Port: 8,128pps 1518 Byte Packets Estimated around TBD s Wire-speed: 10Mbps Full Duplex Port: 813pps

Port Speed: Gigabit Latency Throughput

Port Speed: 100Mbps Latency Throughput

Port Speed: 10Mbps Latency Throughput

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 182 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

System
Boot time Cold boot time in a stand-alone configuration when the switch can join the network and start passing traffic: approximately 115 sec. Cold boot time in a stackable configuration of up to 8 units when the switch(s) can join the network and start passing traffic: approximately 115 sec. Warm re-boot time in a stand-alone configuration when the switch can join the network and start passing traffic: approximately 115 sec. Warm re-boot time in a stackable configuration of up to 8 units when the switch(s) can join the network and start passing traffic: approximately 115 sec. The Fail-over time (Primary switch to Secondary switch in a stacked configuration) is: Layer-2: 20 seconds maximum Layer-3: 30 seconds maximum Trap is sent (to the management station for the failure of the primary management) and log event is logged upon primary management failure and after the redundant management unit takes over. Approximately 65 sec Alcatel-Lucent OmniSwitch 6850 switches are designed in such a way that is highly reliable under extreme stress conditions. The OmniSwitch 6850 switches are rigorously tested to ensure that the system is able to sustain heavy loads and allow for continued availability of all system resources. The typical test setups involve: Running in normal operational mode where system is running under the specified CPU threshold values. Running above the CPU threshold values all the time.

Management fail-over

Image download time System Resiliency Verification

Interfaces
Power over Ethernet Stacking ports IEEE 802.3af (supported on all POE type chassis) Two built-in stacking ports 10 Gbps full-duplex bandwidth per stacking port Fault tolerant looped stacking configuration OS6850-24/-24D/-24X/-24XD/-48/-48D/-24L/-24LD/-48L/-48LD/-P24/-P24H/-P24X/-P24XH/-P48/ -P48H/-P24L/-P24LH/-P48L/-P48LH = 4 x Combo ports which can be individually configured to be 10/100/1000BaseT or 1000BaseX and that can support SFP transceivers. OS6850-48X/-48XD/-P48X/-P48XH = N/A (no combo ports) OS6850-U24X/-U24XD = 2 x Combo ports which can be individually configured to be 10/100/1000BaseT or 1000BaseX and that can support SFP transceivers. Notes: The Combo 10/100/1000BaseTcopper RJ-45 ports support PoE. The Combo 1000Base-X fiber SFP ports do not support PoE OS6850-24X, -24XD, -P24X, -P24XH, -U24X, -U24XD, -48X, -48XD, -P48X, -P48XH Built-in two-port 10 GigE ports Supports industry standard XFP-based 10GigE optical transceivers 64 Bytes 1000Mbps (GigE) and 10,000Mbps (10GigE); 9,216 Bytes (Jumbo frames) 10/100Mbps Eth IP packet max transmission unit; 1553 Bytes You can rate limit the flooding traffic. Flood control is done on ingress and the rate is shared for all interfaces on that switch. By default flood control only applies for flooding with broadcast (ff:ff:ff:ff:ff:ff) and unknown destination Mac address. You can enable flood control for multicast Mac as well. Default settings: Flood multicast disable Flood rate set to 997 Mbps on 10Gig port Flood rate set to 496 Mbps on 1G port Flood rate set to 49Mbps on 100M ports Flood rate set to 4Mbps on 10M ports Note: The above rates are met with packet size of 512 bytes. Different packet size will give different flood rate. The theoretical flood rate (the maximum TX rate at a given packet size you can send before you reach the flood control rate limiting) is obtained with: Theoretical Flood Rate = Interface Flood Rate * (Packet Size + 20) / 512 Flood rate limiting does not give a steady rate at the theoretical flood rate. It gives a sporadic/bursty profile where the average rate is the theoretical flood rate.

Combo ports

10GigE uplinks

Ethernet minimum size packet Ethernet IP packet maximum transmission _ MTU Flood Control

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 183 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Configuration Limitations The maximum number of units possible in the stackable system is 8. The stack may contain any combination of OS6850 Series platforms. Please see the table below: Fixed-Chassis POE Non-POE 10 Gig. 10 Gig. 10/100/1000Mbps Types Ports Ports Stacking Uplinks ,GigE, or Ports 10/100Mbps Non-PoE Models OS6850-24 N/A 24 2 N/A 20 10/100/1000 /-24D OS6850-24X N/A 24 2 2 20 10/100/1000 /-24XD OS6850-48 N/A 48 2 N/A 44 10/100/1000 /-48D OS6850-48X N/A 48 2 2 48 10/100/1000 /-48XD OS6850-U24X N/A 24 2 2 22 Gig SFP** /-U24XD OS6850-24L N/A 24 2 N/A 20 10/100*** /-24LD OS6850-48L N/A 48 2 N/A 44 10/100*** /-48LD PoE Models**** OS6850-P24 24 N/A 2 N/A 20 10/100/1000 /-P24H OS6850-P24X 24 N/A 2 2 20 10/100/1000 /-P24XH OS6850-P48 48 N/A 2 N/A 44 10/100/1000 /-P48H OS6850-P48X 48 N/A 2 2 48 10/100/1000 /-P48XH OS6850-P24L 24 N/A 2 N/A 20 10/100*** /-P24LH OS6850-P48L 48 N/A 2 N/A 44 10/100*** /-P48LH

Combo Ports*

POE Power Budget

Power Supplies supported

4 4 4 N/A 2 4 4

N/A N/A N/A N/A N/A N/A N/A

126W AC-to-DC or 120W DC-to-DC 126W AC-to-DC or 120W DC-to-DC 126W AC-to-DC or 120W DC-to-DC 126W AC-to-DC or 120W DC-to-DC 126W AC-to-DC or 120W DC-to-DC 126W AC-to-DC or 120W DC-to-DC 126W AC-to-DC or 120W DC-to-DC Dual ext. 360W and/or 510W Dual ext. 360W and/or 510W Dual ext. 360W and/or 510W Dual ext. 360W and/or 510W Dual ext. 360W and/or 510W Dual ext. 360W and/or 510W

4 4 4 N/A 4 4

240W / 390W 240W / 390W 240W / 390W 240W / 390W 240W / 390W 240W / 390W

*Combo ports are ports individually configurable to be 10/100/1000BaseT or 1000BaseX that can support SFP transceivers for short, long and very long distances. Combo Ports on the PoE Models: The Combo 10/100/1000BaseTcopper RJ-45 ports support PoE. The Combo 1000Base-X fiber SFP ports do not support PoE. ** Gig fiber interfaces support Gig SFP, dual-speed SFP or 100BaseX SFP optical transceivers. *** The 10/100 RJ-45 ports can be upgraded to 10/100/1000 speed by purchasing the OS6850-24L-UPGD or OS6850-48L-UPGD software license for 24-port and 48-port models respectively. **** The PoE Power Budget is subject to an extra overhead which has to be taken into account (please refer to the P/S Sec.)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 184 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Layer-2/Layer-3 Switching
Root bridge priority / path cost: Default spanning tree mode is RSTP (IEEE 802.1w) The bridge priority can be any value between 0 and 65535 for STP and RSTP protocol in the 16-bit mode. By default spanning tree follows the 16-bit path cost. The bridge priority can only be in multiples of 4096 in the 32-bit mode or in MSTP mode. MSTP can only operate in 32-bit mode. Port MAC MAC range Mobile-Tag Protocol IP IPX DHCP port DHCP MAC DHCP MAC Range DHCP Generic Port-Protocol Binding rule MAC-Port Binding rule MAC-IP-Port Binding rule Mobile Tag DHCP Mac DHCP Mac Range DHCP Port DHCP Generic Mac-Port-IP Binding Mac-Port Binding Port-Protocol Binding Mac Mac Range Network Rule Protocol 253 supported per system VLAN Range Support Up to 4094 VLANs for Flat Spanning Tree mode/MSTP and 253 VLANs for 1x1 Spanning Tree mode are supported. In addition, it is now possible on the OmniSwitch 6800/6850/9000 to specify a range of VLAN IDs when creating or deleting VLANs and/or configuring VLAN parameters, such as Spanning Tree bridge values. Note: Although, up to 4094 VLANs has been configured and tested, we still recommend configuring up to 1K (1,024) in a flat STP mode. Is the native (untagged) VLAN required to be a specific VLAN? Alcatel-Lucent Response: No. Note: Alcatel-Lucent AOS OmniSwitch product family software refers to a native VLAN (a Cisco term) as a default VLAN. Therefore, our default VLAN functionality is similar to that of native VLAN as discussed here. Is the management VLAN required to be a specific VLAN? Alcatel-Lucent Response: No. Can the management VLAN be tagged or untagged? Alcatel-Lucent Response: YES. Can the Native VLAN be excluded from an 802.1Q link (i.e., the ability to send only tagged traffic over an 802.1Q link)? Alcatel-Lucent Response: YES. How many VLAN IDs does this device support? Alcatel-Lucent Response: Comply with up to 4093. Maximum Number of Tagged VLANs per Port: 4093

Group mobility Rules supported:

Binding rules supported

Rule Precedence:

Max. number of 1x1 STP instances Maximum VLANs

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 185 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VLAN Stacking & Translation

Maximum number of BPDUs the switch can handle MAC Address Table IP Address Table Routes Layer-2 Table Hashing

RSTP Performance Sub-second performance

Max number of configured VLANs per port A-VLAN

Supported rules for AVLAN

Max number of configured VLANs per system

Max number of system wide Rules

Maximum frame size With the insertion of a 4-byte svlan tag by VLAN Stacking, the maximum frame size that can be accommodated is jumbo frame size less 4 bytes = 9216 4 = 9212 bytes. Maximum number of SVLANs: For port level VLAN Stacking: 4093 (VLAN 2 through 4094). For port / vlan level VLAN Stacking: 768 (can use any number from 2 through 4094 inclusive). Approximately 800 BPDUs per second Up to 16 K (16,384) MAC Addresses is supported per system. 1K (authenticated / mobile users) per module 48K routing table 12K forwarding LPM entries, 8K hosts entries per module The L2 Table size is 16K entries. This is organized as 2K buckets with each bucket having 8 entries. The search key for the L2 Table is the 60 bit (i.e. 48-bit DA MAC address + 12 bit VLAN-ID) in the Ethernet MAC header in the incoming flow. The key is hashed into a 11-bit value used to select the bucket in the table using a CRC32 lower 11-bits algorithm. Each entry in the selected bucket is compared with the key. The match must be an exact match since if it does, it must be a host MAC address entry. If the key matches an entry in the bucket, then the information in the entry is used in the ingress logic for the destination port Link Fail-over: 459ms Link Fail-over Reverse: 240ms Port Fail-over: 220ms Port Fail-over Reverse: 140ms AGG Links Fail-over: 958ms AGG Links Fail-over Reverse: 260ms AGG Fail-over: 219ms AGG Fail-over Reverse: 280ms 1 K (1,024) with support of full 4K IEEE 802.1Q VLAN Spectrum. Port based (w / IEEE 802.1Q) VLANs. Maximum number of Avlan authenticated user per system: 1024. The system supports up to 1024 authenticated/mobile Mac-addresses AVLAN supports RADIUS or LDAP as authentication servers. By configuring multiple servers, user can gain server failover in case of server outage. Supported rules for AVLAN. MAC-Port Binding rule MAC-IP-Port Binding rule MAC range (used for IP phone OUI Mac-addresses for instance) MAC-Port Binding rule MAC-IP-Port Binding rule MAC range (used for IP phone OUI Mac-addresses for instance) 4K (4,094) The switch has indeed been tested with up to 4,094 active VLANs, but this is really based on switch configuration and available resources. Note: since configuring 4K VLANs consumes a lot of resources, the more practical, or more realistic and/or recommended figure is the 1,024 active VLANs. In the STP flat Mode: 4K VLANs are supported over 802.1Q or over a trunk. In the STP 1x1 Mode: 253 VLANs are supported over 802.1Q or over a trunk. In the STP Multiple Mode (IEEE 802.1s): 4K VLANs amongst 16 Multiple STP Instances (MSTPI). 8 K (8,192)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 186 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Maximum number of rules per chassis:

Max number of MAC Rules

Max number of Subnet Rules Max number of Protocol Rules System

Max Types of Protocols Rules supported Max number of DHCP rules per system Max number of Binding Rules

Max number of 802.1Q tags per port Max number of Authenticated Users

Max number of 802.1x Users

Max number of STP instances per system Max number of 802.1s STP instances per system Max number of Link Aggregate

The following limitations are imposed by the NI hardware table sizes. Since the tables are always synchronized between NI, the following numbers are the chassis limitations: 1024 VLAN-MAC rules: A vlan Mac rule consists in MAC, MAC range, MAC-Port-IP binding, MAC-Port binding, MAC-PortProtocol binding, MAC-IP binding and IPX Network rules. Since hardware does not support IPX network rules, the system internally uses a vlan Mac rule to map the Mac address matching the given IPX network to that vlan. The VLAN-MAC table is also shared with authenticated Mac-addresses (AVLAN, 802.1x) 256 VLAN-SUBNET rules A vlan subnet rule consists in IP network and Port-IP binding rules 16 VLAN-PROTOCOL rules A vlan protocol rule consists in Protocol and Port-Protocol binding rules. For IP protocol (ip-e2 or ip-snap), 2 rules are needed: 1 for ip packets and 1 for arp packets. Notes: Dual protocols Mac-address is supported. The same Mac with both IP protocol (ip-e2) and IPX protocol (ipx-e2) can be classified into 2 different VLANs. Duplicate Mac on different mobile vlan is only supported for IP network rules or protocol rules. For rules falling into the VLAN MAC table, only one Mac/vlan is supported. For instance, the same Mac with 2 IPX networks 0x111 and 0x222 cannot be classified into 2 VLANs. Tagged packets on mobile ports are first classified by their VLAN-ID. If you do not have mobile-tag enabled for that vlan or a mobile rule to classify that packet to that vlan, the packet is dropped. 1 K (1,024) Note: Maximum number of MAC rules, Authenticated VLAN Users, Binding Rules, and 802.1x Users all share the 1,024 MAC Rules 256 (Maximum of 256 IP Subnet rules are supported.) 16 + 1 per port Maximum of 16 rules of combining Protocol & Port-Protocol rules are supported (If IP-E2 is used, total of 14 rules are supported) 6 (Note: Support for IP, IPX, DECNet, AppleTalk, SNAP, and Ethertype) 64 1 K (1,024) Note: Maximum number of MAC rules, Authenticated VLAN Users, Binding Rules, and 802.1x Users all share the 1,024 MAC Rules Maximum of 1024 rules of combining MAC-Port-IP binding, MAC-Port binging, MAC, MAC Range, and IPX Network rules (The available MAC rule pool is also shared by AVLAN and 802.1x) 4K 1 K (1,024) Note: Maximum number of MAC rules, Authenticated VLAN Users, Binding Rules, and 802.1x Users all share the 1,024 MAC Rules Maximum number of 802.1x authenticated user per system: 1 K (1,024) Maximum number of 802.1x authenticated user per port: 253 The system supports up to 1024 authenticated/mobile mac-addresses. Note: Maximum number of MAC rules, Authenticated VLAN Users, Binding Rules, and 802.1x Users all share the 1,024 Mac Rules 253 253 32 aggregates of up to 8 ports each, per stand-alone switch and/or across units Support for static aggregate (aka OmniChannel) Support for dynamic aggregate (IEEE 802.3ad) LOAD BALANCE ALGORITHM The load balance is the same for static and LACP link aggregation. The load balance takes the 3 last bits of the source address and the 3 last bits of the destination address and does an XOR. That gives a number between 0 and 7 Note that Link1 is the lowest port number, then Link2 is next port number On the 6850's, the multiple ports must be on the same "Stack" of 6850's. They can be on separate 6850's but those 6850's must be cabled together with a Stacking cable and it must be functioning as a stack.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 187 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Static ARP with multicast Mac

The UDP Relay Services

Auto-negotiation Traffic Control

Spanning Tree

Maximum Number of STP Instances: Per Stack and/or Per Chassis

When you want to flood a routed unicast packet to ALL ports of the egress vlan, which can be achieved by creating a static ARP with a multicast Mac address. The flooding is done in hardware (wire speed). Using a policy rule, you can rate limit the flooding to a specific rate. That feature is not supported on 10Gig (Ingress). However, flooding on egress 10Gig is supported. The UDP Relay will verify that the forward delay (elapsed boot time specified by the user) has been met before Relaying the UDP packet. If the relay is configured with multiple Next Hop addresses, then the packet will be sent to all next-hop destinations. The UDP Relay shall also verify that the maximum hop count (also set by the user) has not been exceeded. If either of these conditions is not meet, the UDP Relay will discard the BOOTP/DHCP packet. In Release 6.1.3.r01 the NBNS/NBDD and generic service has been added to the UDP port relay. As indicated in the table for NBNS and NBDD user can specify which vlan the packets are forwarded to. User can not specify the next hop IP address or the next hop address type. For all other generic services, user is able to configure which vlan (up to 10 VLANs) the UDP packet is to be forwarded to. User cannot specify the next hop IP address or the next hop IP address type. Service UDP Port Number Configurable Options BOOTP/DHCP 67/68 (Request / 1. Next Hop Address (Bootstrap Protocol/ Response) 2. Forward delay Dynamic Host 3. Maximum hops Configuration Protocol) NBNS/NBDD 137/138 1. VLANs to forward to Generic services Any number 1. VLANs to forward to Speed (10, 100, 1000Mbps) and duplex mode (half or full) IEEE 802.3x Note: the switch does not support honoring the incoming (RX) IEEE 802.3x pause frames, but it does support generating outgoing (TX) IEEE 802.3x pause frames IEEE 802.1D Standard Spanning Tree Algorithm and Protocol (STP) IEEE 802.1w Rapid Spanning Tree Algorithm and Protocol (RSTP) IEEE 802.1s / IEEE 802.1Q 2005 Multiple Spanning Tree Protocol (MSTP) Ring Rapid Spanning Tree Protocol (RRSTP) PVST+ Support of single and multiple instances for STP & RSTP BPDU Watch Guard How many Multiple Spanning Tree Groups are supported? 253 Is one Spanning Tree per Group supported? Yes only in a STP 1x1 mode Is one Spanning Tree per port supported? Yes Is Single Instance Spanning Tree supported? Yes only in a STP flat mode Does this device support any spanning tree enhancements (e.g., Root Guard, BPDU Guard, BPDU Filtering, PortFast, etc.)? Alcatel-Lucent Response: YES. Note: Alcatel-Lucent AOS OmniSwitch product family software refers to Root Guard as Restricted Role which is supported. Note: Alcatel-Lucent AOS OmniSwitch product family software refers to BPDU Guard as BPDU Shutdown Ports which is supported. BPDU Filtering is supported. Note: Alcatel-Lucent AOS OmniSwitch product family software refers to PortFast as EdgePort which is supported. Does this device support an instance of spanning tree per 802.1Q VLAN (commonly referred to as PVST+)? Alcatel-Lucent Response: Comply. a) Flat Mode: STP 1 Instance RSTP 1 Instance MSTP 1 CIST and 16 MST Instances b) 1x1 Mode: STP 253 Instances RSTP 253 Instances

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 188 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Spanning Tree Root bridge priority / path cost

a) Default spanning tree mode is RSTP (IEEE 802.1w) b) The bridge priority can be any value between 0 and 65535 for STP and RSTP protocol in the 16 bit mode. By default, spanning tree follows the 16 bit path cost. c) The bridge priority can only be in multiples of 4096 in the 32 bit mode or in MSTP mode. d) MSTP can support 32 bit mode per standard. e) Changing STP protocol to MSTP will reset all priority and path cost of a bridge to default The default port path costs are: (IEEE Std 802.1D-1998- 16 Bit) Port Speed Path cost 10M 100 100M 19 1000 M 4 10000 M 3 The default port path costs are: ( IEEE Std. 802.1Q-2005 32 Bit) Port Speed Path cost 10M 2000000 100M 200000 1000 M 20000 10000 M 2000 The default link aggregation path costs are (16 Bit): Linkagg speed Linkagg size Path cost 2 60 10M 4 40 8 30 2 12 100M 4 9 8 7 1000M N/A 3 10000M N/A 2 The default link aggregation path costs are (32 Bit): LinkAgg speed LinkAgg size Path cost 2 1200000 10M 4 800000 8 600000 2 120000 100M 4 80000 8 60000 1000M 2 12000 4 8 10000M 2 4 8 8000 6000 1200 800 600

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 189 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Port Monitoring

Max number of Port Mirroring sessions

Port Mapping

STP convergence time (flat, 1x1, 802.1s) 802.1w rapid reconfiguration Learned MAC addresses per port Learned MAC addresses per system Layer-2 forwarding on Ethernet ports Layer-2 forwarding GigE, known MAC Broadcast per Ingress port Loopback Interface

User Definable Loopback Interface

Sever Load Balancing (SLB)

The same unit cannot support both mirroring and monitoring configuration i.e. a user cannot have a port monitoring and a port mirroring session on the same unit. Only one monitoring session at a time across the entire system Only the first 64 bytes of the packet can be monitored. Due to the port monitoring file size, the system can only store the first 2K packets (i.e. 140K/64 = 2187) The port monitoring is not supported on the linkagg ports. Enabling the monitoring function affects the performance. Consequently, Port Monitoring performance is not at wire-rate. The N-to-1 port mirroring allows the user to specify multiple numbers of ports, range of ports as mirrored source in a single command. Maximum number of mirror source ports could be set to 128. Aggregate ports are allowed to be mirrored on the physical ports. Mirroring on the logical LinkAgg port ID is not supported. Mirroring Sessions Supported: One session supported per standalone switch Port mapping feature is supported on OS6800/6850/9000. Following are the limitations for the feature. 8 sessions supported per standalone switch and stack An aggregable port of a link aggregation group cannot be a mapped port and vice versa A mirrored port cannot be a mapped port and vice versa A mobile port cannot be configured as a network port of a mapping session 30 sec Less than 1 sec Up to 16 K (16,384) MAC Addresses is supported Up to 16 K (16,384) MAC Addresses is supported Wire-speed (64 Bytes packets) Wire-speed (64 Bytes packets) Programmable The loop-back interface allows you to uniquely identify a router in the network with one IP address. The advantage of the loop-back interface is to be independent of the physical ip interfaces. In a redundant routing network, the loop-back interface is always accessible when routing topology changes or ip interfaces go down. The main advantage of Loop-back interface is a more reliable Network Management path through OmniVista or an NMS station. Also, you can use the loop-back interface to uniquely identify the router within OSPF and BGP if you set the router-id to the same as the loop-back address. The loop-back can also be used for the RP (Rendezvous Point) in PIM-SM. The loop-back address is also used for the sFlow Agent IP address. The Loopback address is used for source IP of RADIUS authentication. Loopback0 is the name assigned to an IP interface to identify a consistent address for network management purposes. The Loopback0 interface is not bound to any VLAN; therefore it always remains operationally active. This differs from other IP interfaces, such that if there are no active ports in the VLAN, all IP interfaces associated with that VLAN are not active. In addition, the Loopback0 interface provides a unique IP address for the switch that is easily identifiable to network management applications. There are 2 kind of server clusters: -Server Farm: The traffic is truly destined to the Server Farm and the destination IP is the Virtual IP of the Server Farm. Each server is also configured with a Loopback Interface for the Virtual IP -Firewall Cluster: the traffic is not destined to the server, the server simply inspects the packet and sends it back if accepted by the Firewall policies Current limit of servers (on a per cluster basis) is 16. Current limit of cluster (on a per switch basis) is 16. 20 Probes Sever Load Balancing (SLB) Health monitoring is performed by the CPU of the Primary Management. LOAD BALANCING HASHING In both VIP and Condition SLB, the traffic is balanced among the servers using an hash algorithm based on IPSA and IPDA. Internally, each active server is seen as a host ECMP route to reach the cluster. Therefore, the load balancing is the same than the ECMP load balancing.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 190 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

SERVER AVAILABILITY / PROBE

A server is detached from the cluster when: -Disconnected, server goes to Link Down state -Fails to respond to the probe, server goes to No Answer state The default probe is a simple ping with 3 configurable parameters: -period (sec) -retry -timeout (ms) The switch sends a ping/probe to a server every period sec. If the server does not respond within timeout for retry time, the server goes No Answer With the default values (period =60 retry=3 timeout=3000), the switch can take up to 60+3*3=69 seconds to detect of server out of service SLB Probes In addition to Ping , the following probes are available: -FTP: the probe checks the server runs a ftp server -IMAP: the probe checks the server runs a mail server imap -IMAPS: the probe checks the server runs a ssl mail server imap -POP: the probe checks the server runs a mail server pop3 -POPS: the probe checks the server runs a ssl mail server pop3 -SMTP: the probe checks the server runs a smtp server -NNTP: the probe checks the server runs a network news server -HTTP: the probe checks the server runs a http server -HTTPS: the probe checks the server runs a ssl http server -UDP: the probe checks the server responds to a given udp port application -TCP: the probe checks the server responds to a given tcp port application COMMON PROBE PARAMETERS Like ping, a probe is configured with a period, a retry and a timeout. If the server does not respond to the probe, the server is detached from the cluster. According to the period/retry/timeout, the switch will probe each server to make sure the server is still running the appropriate application. For instance, with ftp probe, the switch verifies the server is able to accept a ftp session. PROBE PORT NUMBER A tcp/udp port number is mandatory for TCP and UDP probes. It specifies on which port the server must be listening for opening sessions. For other probes, the port is optional (default port number is 0); the probes uses the well known TCP/UDP ports: -FTP: port 21 -IMAP: port 143 -IMAPS: port 993 -POP: port 110 -POPS: port 995 -SMTP: port 25 -NNTP: port 119 -HTTP: port 80 -HTTPS: port 443 TCP/UDP PROBES These probes check the server can open a udp/tcp sessions on the given port Optional parameters can be given: -SSL : to use a secure socket layer application instead of basis tcp/ip layer -Send/Expect : to verify the server response (expect) upon a given message (send) HTTP/HTTPS PROBES These probes try to load a page from the server. The mandatory parameters are: -url : the page the probe is trying to load -status: the status of the page expected to be received (200 for OK, 400 for url not found ..). Default is 200. Optional parameters can be given: -expect: a string expected to be seen in the content of the page -username/password: the username/password to use when the web server requires an http authentication

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 191 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Layer-3 Routing Unicast (IPv4)

Layer-3 Routing Protocols (IPv4) IP Routing Static routing RIP v1 & v2 OSPF v2 BGP v4 ISIS (Future Release) Multicast IGMP v1, v2 & v3 snooping PIM-SM PIM-DM DVMRP Network Protocol TCP/IP stack ARP DHCP relay Generic UDP relay per VLAN Resilience VRRPv2 IP Routing Static routing RIP/SAP DHCP Option 82 relay agent information Q-in-Q (Vlan stacking) Ethernet OAM compliant with 802.1ag version 7.0 Hardware: Maximum number of active flows in the hardware: 12K One active flow is usually one remote-subnet flow (not a per destination ip flow based) Now with the ARP table enhancement, one active flow can also be a host routed flow The table is shared for - IPV4 active flow (remote ipv4 network): 1 entry - IPV6 active flow (remote ipv6 network): 2 entries - Host active flow (ARP entry): 1 entry Maximum number of active ARP entries flows: 12K Maximum number of ECMP Next-hops that can be stored: 512 Software: Maximum number of IPv4 routes that can be held in the software routing table: 96K Maximum number of IPv6 routes that can be held in the software routing table: 5K Maximum number of ARP entries that can be held in software ARP table: 16K Up to 48K routing table is supported. 12K forwarding LPM entries, 8K hosts entries per module. 1 K (1,024) Up to 48K 1 K (1,024) routes Maximum number of IP Routes: 48K Maximum number of RIPv2 interfaces per router: 10 Maximum number of RIPv2 peers per router, one per interface: 10 Maximum number of RIPv2 routes with no redistribution from OSPFv2 RIB on a OS6850 router: 6.5K (6.575K truncated to 6.5K)

Layer-3 Routing (IPX)

Residential Metro Triple-play Ethernet Access Large L3 table support

Maximum number of IP route entries (Layer-3 Routing Table Size) (Maximum Routing Information Base RIB) Max number of IP Router interfaces per system Single mode Max number of IP routes Max number of IP static routes RIPv1&v2

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 192 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OSPFv2 Specifications

ECMP

BGP Routing Limitations

ARP Table: Max number of ARP entries per system Layer-3 forwarding, known IP@64 bytes pkt Layer-3 forwarding, known IP@1518 bytes pkt Layer-3 forwarding, known IP@ Jumbo pkt Trunking 2 VLANs, 64 Bytes pkt Trunking 2 VLANs, 1518 Bytes pkt RIP Learning Rate OSPF Learning Rate

The following values are the maximum limits enforced by the code. Maximum number of Areas (per router): 32 Maximum number of Interfaces (per area): 100 Maximum number of Interfaces (per router): 32 x 100 (Limited only by max. num of IPv4 interfaces = 4096) Maximum number of Link State Database entries (per router): 96K Maximum number of neighbors/adjacencies (per router): 254 Maximum number of neighbors/adjacencies (per area): 128 Maximum number of routes (per router): 96K Maximum number of OSPFv2- ECMP gateways (per destination): 4 Max number of OSPFv2 Sessions: 1 The following values are the tested limits with functionally verified (stress test). On OS6850 ABR routers: Max number of IP Routes on OS6850 router: 12K Max number of OSPFv2 Routes on OS6850 router: 12K Max number of OSPFv2 Interfaces on OS6850 ABR: 48 Max number of OSPFv2 Areas on OS6850 ABR: 6 Max number of OSPFv2 Adjacencies on OS6850 ABR: 48 Max number of LSAs on OS6850 ABR: 12K Tested number of OSPFv2- ECMP gateways (per destination): 4 Max number of OSPFv2 Sessions: 1 On OS6850 non-ABR routers: Max number of IP Routes on OS6850 router: 96K Max number of OSPFv2 Routes on OS6850 router: 96K Max number of OSPFv2 Interfaces on OS6850 non-ABR: 27 Max number of OSPFv2 Areas on OS6850 non-ABR: 6 Max number of OSPFv2 Adjacencies on OS6850 non-ABR: 27 Max number of LSAs on OS6850 non-ABR: 24K Tested number of OSPFv2- ECMP gateways (per destination): 4 Max number of OSPFv2 Sessions: 1 Notes: Please note that, the above OSPFv2 specifications may vary depending on the available system resources, and/or customer specific networking requirements & configurations. Please also note that, depending on the number of Areas, Interfaces, Adjacencies, and Neighbors configured, the maximum number of routes may vary. Please contact our customer Service & Support team, should your required specifications fall between "the limits as enforced by the code" and "the limits as functionally tested". Only 512 networks can be programmed in the ECMP table, so that the flows can be load balanced among the different paths. When having more than 512 ECMP routes on the show ip route, only the last (highest) 512 routes are programmed in the ECMP table. Only 512 networks can be load balanced over ECMP links The other ECMP networks will always be routed on the same link. Maximum BGP Peers per Router: 8 Maximum number of routes supported: 30,000 Range for AS Numbers 1 to 65535 Range of Local Preference Values 0 to 4294967295 Range for Confederation IDs 0 to 65535 Range for MED Attribute 0 to 4294967295 Up to 8K (8,192) L3 ARP entries are supported. Wire-speed Wire-speed Wire-speed Wire-speed Wire-speed 500 / sec 500 / sec

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 193 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Route Convergence for OSPF IP redistribution

Unicast Routing Protocol Performance

1.2 sec Supported platform: OS6800, OS6850, and OS9000 IPv4 Redistribution instances use route-maps to redistribute routes from a source protocol RIB to a destination protocol RIB. The source protocol can be BGP, RIP, OSPF, Local or Static. The destination protocol can be BGP, RIP or OSPF. Maximum number of route-maps that can be created on router: 200 Maximum number of route-map sequences that can be created on router: 400 Maximum number of IPv4 access-lists that can be configured on router: 200 Maximum number of OSPFv2 routes that can be redistributed into RIPv2: 6.5K Maximum number of RIPv2 routes that can be redistributed into OSPFv2: 6.5K Below table is high light of routing limitation in 6.1.3.R01 release. OS6850 OSPFv2 ABR LSA#/Routes# OSPFV2 non-ABR LSA#/Routes# RIPv2 IPv4 Redistribution RIPv2 into OSPFv2 IPv4 Redistribution OSPFv2 into RIPv2 OSPFv3 ABR LSA#/Routes# OSPFv3 non-ABR LSA#/Routes# RIPng IPv6 Redistribution RIPng into OSPFv3 IPv6 Redistribution OSPFv3 into RIPng OS9000

12K/12K 24K/96K 6.5K

32K/32K 24K/96K (4 ECMP) 8.5K

6.5K

8K

6.5K 1.25K/1.25K 1.25K/1.25K 6.5K

8.5K 1.25K/1.25K 1.25K/5K (4 ECMP) 8.5K

1K

1K

1K

1K

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 194 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Multicast & Network Protocols & Resilience

Multicast Performance Q: Does this device support IPv4 hardware-based Multicast Routing? A: Hardware-based native IPv4 & IPv6 Unicast & Multicast Routing is supported. The Alcatel OmniSwitch 9000s are designed to anticipate future network needs with wire-rate processing for IPv4/IPv6 and support for unicast and multicast applications such as voice-over-IP and video collaboration. The switches support edge requirements as Gigabit Ethernet to the desktop becomes commonplace and demand for power-over-Ethernet (PoE) capability increases. Q: How many IPv4 Multicast Routes are supported? A: We support as many IPv4 Multicast Routes as memory will allow. The more limiting factors are that we support 1,021IP Multicast flows (where a flow is classified as source-group pair). Q: How many IPv4 multicast packets does this device route per second at 64-bytes? A: Wire rate. Q: How many IPv4 multicast packets does this device route per second at 1518-bytes? A: Wire rate. Q: Does this device support IPv6 hardware-based Multicast Routing? A: Hardware-based native IPv4 & IPv6 Unicast & Multicast Routing is supported. The Alcatel OmniSwitch 6850/9000s is designed to anticipate future network needs with wire-rate processing for IPv4/IPv6 and support for unicast and multicast applications such as voice-over-IP and video collaboration. The switches support edge requirements as Gigabit Ethernet to the desktop becomes commonplace and demand for power-over-Ethernet (PoE) capability increases. Note: The OmniSwitch 6850/9000 supports IPv6 hardware-based Multicast Switching (forwarding between ports on the same VLAN) and IPv6 hardware-based Multicast Routing. Q: How many IPv6 Multicast Routes are supported? A: We support as many IPv6 Multicast Routes as memory will allow. The more limiting factors are that we support 1,021 IP Multicast flows (where a flow is classified by a source-group pair). Q: How many IPv6 multicast packets does this device route per second at 64-bytes? A: Wire rate. Q: How many IPv6 multicast packets does this device route per second at 1518-bytes? A: Wire rate. Maximum Multicast Flows per switch: 1,021 (with hardware routing) Up to 1,021 simultaneous multicast flows are supported. There is no hard limit on the number of static multicast groups that can be configured, but if you try to send traffic to the entire group at the same time the limit is still 1,021 hardware flows. A flow is defined as a source-group pair. In the case all hardware entries are exhausted, the IPMS will not perform software forwarding. IP multicast tunneling is performed in software. IGMPv1&v2&v3 Snooping MLD Snooping DVMRP PIM-SM PIM-DM 1021 entries per system 2048 entries per system 128 256 1 per interface 128 PIM-DM is a multicast routing protocol that defines a multicast routing algorithm for multicast groups that are densely distributed across a network. It uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers with no group membership information. It employs the same packet formats as sparse mode PIM (PIM-SM). PIM-DM assumes that when a multicast source starts sending, all downstream systems want to receive multicast datagrams. Initially, multicast datagrams are flooded to all areas of the network. PIM-DM uses RPF (Reverse Path Forwarding) to prevent looping of multicast datagrams while flooding. If some areas of the network do not have group members, PIM-DM will prune off the forwarding branch by instantiating prune state. PIM-DM differs from PIM-SM in two essential ways: 1. There are no periodic joins transmitted, only explicitly triggered prunes and grafts. 2. There is no Rendezvous Point (RP). This is particularly important in networks that cannot tolerate a single point of failure.

Multicast Flows A flow is defined as a source-group pair.

Multicast support

Flow Table VLAN Replication Max number of DVMRP Interfaces Max number of DVMRP Neighbors Max number of DVMRP Tunnels Max number of PIM-SM Interfaces PIM-DM (IPv4)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 195 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IGMP learning performance

Zapping

L2 static multicast Multicast without 8021.Q on 10/100Mbps interfaces Multicast without 8021.Q on 1000Mbps interfaces Multicast with 8021.Q, 0 copies, 1518Bytes pkt on 10/100/1000Mbps ports and/or GigE ports Multicast with 8021.Q, 1 copies, 1518Bytes pkt on 10/100/1000Mbps ports and/or GigE ports Multicast with 8021.Q, 2 copies, 1518Bytes pkt on 10/100/1000Mbps ports and/or GigE ports Network Protocols

The system can process 1000 IGMP per second. However, the performance can drop to 128 when IGMP are received too fast. Burst of 1000 IGMP reports at 1000 packet/sec: all 1000 groups are learnt Burst of 1000 IGMP reports at 1Gbps: only 128 groups are learnt You can configure ip multicast zapping to optimize channel surfing. That will instantly stop forwarding multicast to a client when that client sent an IGMP Leave. The zapping time can be measured by the leave message received by the switch and the last packet received by the client. This is usually in milliseconds. The feature is well suited for Multicast Switching and zapping only works well when ip multicast querying is disabled. 1022 static multicast MACs are supported on OS6850 and OS9000. The L2 Multicast table can have 1024 entries but 2 are reserved for other applications. Wire-speed Wire-speed Wire-speed Wire-speed Wire-speed DHCP Relay (including generic UDP Relay) TCP/IP Stack NDP ARP

Resilience
VRRPv3 Virtual Router Redundancy Protocol, VRRPv3, is designed to eliminate the single point of failure existing in a static default routed IPv6 environment. The loss of the default router isolates all systems not able to detect an alternate path. VRRPv3 provides the capability for assigning the responsibility of a virtual router to one of the IPv6 VRRPv3 routers on a LAN. A total of 255 VRRP3 instances can be configured if only IPv6 instances are configured. The total of 255 instances on a box is the maximum number of VRRP instances (VRRP2 + VRRP3) that can be configured on a box.. As an example if a user configures 200 VRRP2 instances, then only 55 VRRP3 instances can be configured. If a user configures 255 VRRP2 instances then no VRRP3 instances can be configured and vice versa.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 196 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Layer-3 Routing Unicast (IPv6)

Layer-3 Routing Protocols (IPv6) IP Routing Static routing RIPng OSPF v3 Multicast MLD snooping PIM-SM (Future Release) PIM-DM (Future Release) Network protocol TCP/IP stack DHCP relay (including generic UDP relay) ARP Resilience VRRPv3 (Future Release) Hardware: Maximum number of active flows in the hardware: 12K One active flow is usually one remote-subnet flow (not a per destination ip flow based) Now with the ARP table enhancement, one active flow can also be a host routed flow The table is shared for - IPV4 active flow (remote ipv4 network): 1 entry - IPV6 active flow (remote ipv6 network): 2 entries - Host active flow (ARP entry): 1 entry Maximum number of active ARP entries flows: 12K Maximum number of ECMP Next-hops that can be stored: 512 Software: Maximum number of IPv4 routes that can be held in the software routing table: 96K Maximum number of IPv6 routes that can be held in the software routing table: 5K Maximum number of ARP entries that can be held in software ARP table: 16K Up to 16K routing table is supported. 6K forwarding LPM entries, 4K hosts entries per module. Latency: <10 sec 1,000 The total number of IPv6 routes supported in hardware (with no IPv4 routes) is 6000 1,000 routes The recommended number of IPv6 interfaces is 100 The recommended number of IPv6 prefixes per interface is 50 The recommended number of IPv6 global unicast addresses per interface is 50 A 6to4 tunnel explicitly uses an ingress tunnel for each IPv4 interface configured on the system. The limit is 100 ingress tunnels The 10GIG routing performance over an IPv6 tunnel (6to4 and configured tunnel) has been determined to be 10,775,862 96 byte packets per second. The 10GIG routing performance NI-NI or Single NI has been determined to be 14,880,812 - 64 byte packets per second. The following values are the maximum limits enforced by the code. The total number of RIPng interfaces is 100. The maximum number of RIPng neighbors is 20 Maximum number of RIPng routes: 5K routes (Depending on the number of RIPng interfaces, and neighbors configured the maximum number of routes may vary.) The following values are the tested limits functionally verified. The following configuration is used as a stress test: (a) Maximum number of RIPng interfaces per router: 10 (b) Maximum number of RIPng peers per OS6850 router: 10 (c) Maximum number of RIPng routes with no redistribution from OSPFv3 RIB: 1000 Up to 8K (8,192) L3 ARP entries are supported.

Large L3 table support

Maximum number of IP route entries (Layer-3 Routing Table Size) (Maximum Routing Information Base RIB) Max number of IP Router interfaces per system Single mode IPv6 routes Max number of IPv6 static routes IPv6 interfaces IPv6 prefixes per interface IPv6 global unicast addresses per interface A 6to4 tunnel

RIPng

ARP Table: Max number of ARP entries per system

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 197 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OSPFv3 Specifications

IPv6 REDISTRIBUTION

Layer-3 forwarding, known IP@64 bytes pkt Layer-3 forwarding, known IP@1518 bytes pkt Layer-3 forwarding, known IP@ Jumbo pkt Trunking 2 VLANs, 64 Bytes pkt Trunking 2 VLANs, 1518 Bytes pkt RIP Learning Rate OSPF Learning Rate Route Convergence for OSPF

The following values are the maximum limits enforced by the code. Maximum number of Areas (per router): 32 Maximum number of Interfaces (per router): Unlimited (Limited only by max. num of IPv4 interfaces = 4096) Maximum number of Interfaces (per area): 100 Maximum number of Link State Database entries (per router): Unlimited Maximum number of adjacencies (per router): adjacency is no different from neighbor, below. Maximum number of OSPF- ECMP gateways (per destination): 4 Maximum number of neighbors (per router); 254 Maximum number of neighbors (per area); 64 Maximum number of routes (per router): Unlimited (Future Release) (Depending on the number of Areas, Interfaces, Adjacencies, and Neighbors configured, the maximum number of routes may vary.) Max number of OSPF Sessions: 1 The following values are the tested limits functionally verified. The following configuration is used as a stress test: On an OS6850 non-ABR Routers: (a) Min. usable Hello Interval with 20 Interfaces in 5 Areas with 4 Interfaces in each Area: 5 sec (b) Min. usable Router Dead Interval with 20 Neighbors, 4 each in 1 Area for a total of 5 Areas: 20 sec (c) Max. usable number of LSAs that the OS6850 router can stably hold: 5K (d) Max. usable number of Ospfv3 Routes that the OS6850 router can stably hold in this scenario: 5K (e) Max. number of usable Ospfv3 Interfaces between any two OS6850 or OS6850/OS9000 routers: 4 (f) Max number of IP Routes on OS6850 router: 5K (g) Max number of OSPFv3 Routes on OS6850 router: 5K On an OS6850 ABR: (a) Min. usable Hello Interval with 20 Interfaces in 5 Areas with 4 Interfaces in each Area: 5 sec (b) Min. usable Router Dead Interval with 20 Neighbors, 4 each in 1 Area for a total of 5 Areas: 20 sec (c) Max. usable number of LSAs that the OS6850 router can stably hold: 5K (d) Max. usable number of Ospfv3 Routes that the OS6850 router can stably hold in this scenario: 5K (e) Max. number of usable Ospfv3 Interfaces in 5 areas with 5K LSAs: 20 (f) Max. number of usable Ospfv3 Neighbors in 5 areas with 5K LSAs: 20 (g) Max. number of usable Ospfv3 Interfaces between any two OS6850 routers: 4 (l) Max. number of usable Ospfv3 Areas on an OS6850 ABR: 5 Notes: Please note that, the above OSPFv3 specifications may vary depending on the available system resources, and/or customer specific networking requirements & configurations. Please also note that, depending on the number of Areas, Interfaces, Adjacencies, and Neighbors configured, the maximum number of routes may vary. Please contact our customer Service & Support team, should your required specifications fall between "the limits as enforced by the code" and "the limits as functionally tested". (a) Maximum number of route-maps that can be created on an OS6850 router: 200 (b) Maximum number of route-map sequences that can be created on an OS6850 router: 400 (c) Maximum number of IPv6 access-lists that can be configured on an OS6850 router: 200 (d) Maximum number of OSPFv3 routes that can be redistributed into RIPng: 1K (e) Maximum number of RIPng routes that can be redistributed into OSPFv3: 1K Wire-speed Wire-speed Wire-speed Wire-speed Wire-speed 500 / sec 500 / sec 1.2 sec

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 198 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Multinetting
Multinetting This feature allows IP traffic from multiple subnets to coexist on the same VLAN. A network is said to be multinetted when multiple IP subnets are brought together within a single broadcast domain (VLAN). It is possible to assign up to eight different IP interfaces per VLAN. Each interface is configured with a different subnet. A network is said to be multinetted when multiple IP subnets are brought together within a single VLAN. For example, one may configure the subnet 192.168.1.0/24 and 194.2.10.0/24 to run on the same switch interface. In other words, traffic from the 192.168.1.0 subnet and traffic from the 194.2.10.0 subnet would coexist on the same physical VLAN. Within a Layer 2 environment, the traffic is broadcast between all subnets configured in the same VLAN. Layer-3 traffic is routed between the configured subnets in the same VLAN. Possible uses for Multinetting: Subnet renumbering used during transition from one addressing scheme to another to maintain connectivity. Ability to support more hosts on one physical link used to add more hosts to a broadcast domain than the addressing scheme allows. Supporting multiple subnets on one interface where configurations do not allow complete separation of subnet traffic. For example, a college campus may have departments where users are connected to a switch via hubs. Connected to each of the hubs are users configured to be in different subnets. The hubs are connected to the switches using portbased vlan configuration. Network administrators use Multinetting so they do not have to worry about re-cabling or reconfiguring ports for users in different subnets. Up to 8 subnets per VLAN All existing dynamic routing protocols, routing between each of the multinetted subnets in one VLAN and routing between each of the multinetted subnets and other VLANs VRRP DHCP is only supported on the primary interface of the multinetted vlan. All devices are assigned to the same scope (the one for the primary interface) With VRRP and Multinetting, you can still configure multiple instances to load balance the master role among the sub-netted interfaces. Routing protocols (RIP, OSPF, BGP) are supported in a multinetted environment. The routing interfaces are now based on ip interfaces, instead of the VLANs. Therefore, routing protocols are totally independent of VLANs and their data structures are maintained as part of an array indexed by ip interface only. There is no difference between running a routing protocol on an interface part of a multinetted vlan or a regular interface. Each subnet (interface) on the multinetted vlan can run its own routing protocol. The multicast routing protocols will be supported on one interface per VLAN. One interface designated the primary interface, will be used for the multicast routing protocols. The multicast routing protocols will not allow configuration on any non-primary interfaces. By default the first interface is the primary interface. DVMRP and PIM-SM will only allow configuration on the primary interface of a VLAN. This is to ensure consistency between the multicast routing protocols (DVMRP, PIM-SM, IPMRM), IPMS and IGMP.

Supported features:

Routing In Multinetting

Multicast Routing In Multinetting

Layer-3 Routing (IPX)

Routes IPX Routing 1K Routes 1K Host entries 64 IPX interfaces Static routing (256 routes) RIP/SAP, 1K routes 5000 RIP and SAP entries each are supported. IPX routing is limited to 1900 packets per second per NI. Each NI can independently route up to 1900 p/s.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 199 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Policy/QoS
QoS / ACLs Features summary: 802.1p classification TOS/DSCP classification Ethertype classification IP protocol classification ICMP type and code classification TCP Flag classification and established for implicit reflexive tcp flows qos apply will not impact existing flows Port disable rules to shutdown a port when incoming packets matches a rule Rule logging Port redirect action to force a packet to be sent out on a given port User port profiles to filter and shutdown ports for BPDUs, IP spoofing and routing protocols (rip, ospf, bgp) DropServices to drop tcp/udp ports IGMP ACLs L2/L3/L4 QoS fully supports IP multicast traffic (priority, bandwidth shaping..) 8 hardware queues per port Traffic prioritization: Flow-based QoS with internal and external (a.k.a., remarking) prioritization Bandwidth management: flow based bandwidth management, ingress policing/egress shaping and port based egress shaping Queue management: Random Early Detect/Discard (RED), configurable de-queuing algorithm; Strict Priority, Weighted and Deficit Round Robin. Power-over-Ethernet: IEEE 802.3af maximum total power of 380W for PoE The following types of conditions are available: L1 conditions: source port, destination port, source port group, destination port group L2 conditions: source mac, source mac group, destination mac, destination mac group, 802.1p, ethertype, and source vlan (Destination vlan is not supported). L3 conditions: ip protocol, source ip, source network group, destination ip, destination network group, TOS, DSCP, ICMP type, ICMP code. L4 conditions: source TCP/UDP port, source TCP/UDP port range, destination TCP/UDP port, destination TCP/UDP port range, service, service group, tcp flags IP multicast condition: An ip multicast condition is used for IGMP ACLs. The multicast ip is actually the multicast group address used in the IGMP report packet. IP multicast can be combined with destination port, destination vlan, destination Mac, destination ip, that are the port/vlan/mac/ip of the device that sent the IGMP report The following actions are available: ACL (disposition drop/accept default is accept) Priority 802.1p/TOS/DSCP Stamping 802.1p/TOS/DSCP Mapping Maximum bandwidth Redirect Port Note: Condition combinations and Action combinations are also supported. Eight hardware based queues per port Flow based QoS Internal & External (aka remarking) prioritization Flow Based bandwidth management, 64kbps granularity Port based egress shaping, 1Mbps granularity Configurable de-queuing algorithm Strict Priority Weighted Round Robin DRR (Deficit Round Robin). This mode is quite similar as WRR In the Strict Priority mode, a port has 8 strict priority queues (SPQ) and all the queues on the port are serviced strictly by priority. In the WRR or DRR, queues are serviced on a round robin based on their weight. The higher the queue weight, the higher is the throughput for that queue. Any queue can be configured with a weight of 0 to make that queue strict priority. The weight ordering does not need to follow the queue order.

Convergence / Triple Play

QoS Conditions & Actions supported

Priority Queues Traffic Prioritization Bandwidth Management Queue Management

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 200 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Queuing Scheme and Servicing Mode

Queue Mapping Table

Power over Ethernet Max number of Rules Max number of Actions Max number of Conditions Max number of Policy Services Max number of Policy Groups Max number of Queues Filtering or ACL Throughput Configurable policies

OS6850 has 8 queues per egress port OS6850 has 3 Queuing schemes per egress port: Strict-Priority (default mode) WRR (Weighted Round Robin) DRR (Deficit Round Robin). This mode is quite similar as WRR In the Strict Priority mode, a port has 8 strict priority queues (SPQ) and all the queues on the port are serviced strictly by priority. In the WRR or DRR, queues are serviced on a round robin based on their weight. The higher the queue weight, the higher is the throughput for that queue. Any queue can be configured with a weight of 0 to make that queue strict priority. The weight ordering does not need to follow the queue order. Queue Mapping Table 802.1p TOS / DSCP Priority Rule Egress Queue 0 0 / 0-7 0 0 1 1 / 8-15 1 1 2 2 / 16-23 2 2 3 3 / 24-31 3 3 4 4 / 32-39 4 4 5 5 / 40-47 5 5 6 6 / 48-55 6 6 7 7 / 56-63 7 7 (*) SPQ Strict Priority Queue or Weighted Fair Queue if configured with a weight > 0 IEEE 802.3af (requires OS9-GNI-P24 & IP-Shelf) 128 per port; 2048 policy rules per chassis OS6850: 2048 rules per slice (2048 on a OS6850-24 chassis and 2*2048 on a OS6850-48 chassis) 128 per port; 2048 policy actions per chassis 128 per port; 2048 policy Conditions per chassis 256 1024 512 entries per policy group 8 / port Wire-speed OS6850-24 Models port unit (1 TCAM) Max available HW rules per slot: 1664 Max available tcp/udp port ranges per slot: 16 Max available bandwidth shaping rules per slot: 832 OS6850-48 Models port unit (2 TCAMs) Max available HW rules per slot: 3328 Max available tcp/udp port ranges per slot: 32 Max available bandwidth shaping rules per slot: 1664 OS6850 can log the packets matching a policy rule. The most common use of that feature is to log packet matching an ACL drop policy. To enable logging configure the policy rule with log [log interval x] The log interval is optional and the default interval is 30 sec. You can configure a log interval between 1 and 3600 sec. Depending on the configured log interval, the system periodically set the hardware to send copy of the packet matching the rule to CPU. As soon as the CPU receives a packet matching the rule, the system reset the hardware to no longer send copy to CPU until the next interval, to keep CPU low. The first packet is always logged. If one packet matching the rule is seen during the log interval time, it will be logged. Limitation: More than one packet can be logged depending on the rate of the traffic (because of time required by the CPU to stop the sampling). Log interval less than 5 seconds will be accepted by CLI , but logging will be done every 5 sec Logging does not lot all matching packets (not an IDS) Note: CPU stays low with rule logging enable. We tested a logging drop rule with 10 Gbps of incoming traffic and CPU stays low.

Servicing (*) SPQ or WFQ SPQ or WFQ SPQ or WFQ SPQ or WFQ SPQ or WFQ SPQ or WFQ SPQ or WFQ SPQ or WFQ

Rule logging

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 201 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Egress Bandwidth Shaping

Ingress Max Bandwidth Policing

Untrusted Ports and Packet Priority

Trusted Ports and Packet Priority

Port shaping Shaping limits the bandwidth on the egress port. Shaping implies that the shaping function controls the rate at which the egress port sends the packets, regardless of egress queues. The granularity is 64Kbps. Queue shaping You can also configure maximum and minimum bandwidth on a per egress queue basis. Configuring an egress queue max bandwidth will shape priority traffic mapped to that queue. Configuring an egress queue min bandwidth will guarantee that bandwidth for priority traffic mapped to that queue. When a queue has a minimum bandwidth configured, traffic within that bandwidth has the HIGHEST priority, regardless the servicing mode or the priority of that queue. Limitation: The egress bandwidth shaping is only on a per port basis; the system cannot do a per flow basis egress bandwidth shaping. Using policy rule with maximum bandwidth action, you can limit the bandwidth on the ingress. Policing implies dropping the traffic when the programmed rate is exceeded. Policing is on a per flow basis. The granularity is 64kpbs. You can do the following: Ingress port rate limiting by configure a policy using a source port Ingress flow based rate limiting by configure a policy defining that flow Mixed of ingress and flow based rate limiting Limitations: Ingress rate limiting is done at the ingress NI. Policies spread out on multiple NIs will make the total egressing rate to be higher than the configured value (up to the N time the limit where N is the number of NI being spread) Show active policy rule will count the packets that exceed the rate limiting, not the packets that matches the rule On untrusted ports the priority/queue of the incoming packet is based on the port default 802.1p value. By default, the port default 802.1p value is 0 making traffic to be mapped to Q0 (best effort). Also, regardless or bridging or routing: 802.1p within the packets is set to the port default 802.1p DSCP within the packets is set to the port default dscp Changing the port default 802.1p will: Change the priority of all traffic from that port. That is like a port priority Set the 802.1p value in the packet to that port default 802.1p Changing the port default DSCP will: NOT change the internal priority Set the DSCP value in the packet to that of the port default DSCP Notes: On untrusted port, the default 802.1p defines the default internal priority for all packets. Untagged packets on untrusted ports get an 802.1p value from the port default 802.1p (if going out on tagged interface). Limitation: On untrusted ports, if the packet matches a policy rule, the DSCP in the packet is unchanged; it is not set to the port default dscp On trusted ports the priority/queue of the incoming packet is based on the ingress packet 802.1p or ToS/DSCP value. Non IP packets are prioritized based on the packet 802.1p value IP packets are prioritized based on the packet TOS/DSCP value Port default 802.1p or DSCP has no effect on trusted ports. Notes: On IP packets, the 802.1p is set to match the packet ToS value. Untagged non-IP packets always get an 802.1p of 0 and priority 0 (if going out on tagged interface). The port default 802.1p is not applied.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 202 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

802.1p/TOS/DSCP Stamping/Mapping policies

Policy Based Routing

Policy Based Routing (Permanent Mode)

Policy Rules with Multiple Actions

QoS Precedence with Multiple Policy Rules

Regardless the condition or classification, the following stamping/mapping actions are allowed Stamp 802.1p Stamp TOS (precedence) Stamp DSCP Stamp 802.1p and TOS/DSCP Map 802.1p to 802.1p Map 802.1p to TOS Map 802.1p to DSCP Map ToS to 802.1p Map ToS to TOS Map ToS to DSCP Map DSCP to 802.1p Map DSCP to TOS Map DSCP to DSCP Stamping/mapping policies change the internal priority of the packets: Internal Priority is always based on the new 802.1p or TOS/DSCP being stamped/mapped Stamp/map TOS/DSCP also gives internal priority for non IP packets matching the rule Mapping rules takes one TCAM rule entry for each entry in the map group If both 802.1p and TOS/DSCP are stamped in a policy rule, priority is based on the stamped 802.1p value Notes: On trusted ports, stamping/mapping a tos/dscp also change the 802.1p value in the packet to the packet ToS value. If the policy rule has both a 802.1p stamp/map action and a priority action, the packet priority comes from the stamped/mapped 802.1p value, not the priority action. Policy Based Routing (PBR) allows a network administrator to define QoS policies that will override the normal routing mechanism for traffic matching the policy condition. Note. When a PBR QoS rule is applied to the configuration, it is applied to the entire switch, unless you specify a built-in port group in the policy condition. Policy Based Routing may be used to redirect traffic to a particular gateway based on source or destination IP address, source or destination network group, source or destination TCP/UDP port, a service or service group, IP protocol, or built-in source port group. Traffic may be redirected to a particular gateway regardless of what routes are listed in the routing table. Note that the gateway address does not have to be on a directly connected VLAN; the address may be on any network that is learned by the switch. Note. If the routing table has a default route of 0.0.0.0, traffic matching a PBR policy will be redirected to the route specified in the policy. Policy Based Routing may be used to redirect untrusted traffic to a firewall. In this case, note that reply packets will be not be allowed back through the firewall. Policy Based Routing may be used to redirect traffic to a particular gateway based on source or destination IP address, source or destination network group, source or destination TCP/UDP port, a service or service group, IP protocol, or built-in source port group. Traffic may be redirected to a particular gateway regardless of what routes are listed in the routing table. Note that the gateway address does not have to be on a directly connected VLAN; the address may be on any network that is learned by the switch. Multiple policy actions can be combined together within a single rule. The policy actions that can be combined in the same rule are: Priority Stamping/mapping Max BW Redirect Port A flow can match multiple rules but ONLY the action for the highest precedence-matching rule is then enforced. When rule are configured without precedence (default precedence is 0), the first created rule has the highest precedence.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 203 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IPv6 Classification & Combinations

IPv6 Actions

User-port shutdown profile

Port Disable

Policy Based Routing

Classification & Combinations The following classification criteria are available (in Release 6.1.3.r01) for ipv6 packets source ipv6 address destination ipv6 address Next header. Policies specifying the NH parameter, classify based on the first NH value present in the V6 header of the IPV6 packet Flow label TCP Flags/Established. Policies specifying established or tcpflags, expect the first NH value present in the V6 header to be 6 ToS/DSCP source vlan 802.1p source Mac destination Mac source port destination port (only for bridged traffic) Multicast ipv6 for MLD report filtering (similar to IGMP filtering) Actions All actions are available for Ipv6 policies ACL (disposition drop/accept default is accept) Priority 802.1p/TOS/DSCP Stamping 802.1p/TOS/DSCP Mapping Maximum bandwidth/depth Redirect Port / Link aggregation Instead of filtering packets, you can configure a user-port profile to administratively disable an interface upon reception of spoof/bpdu/rip/ospf/bgp packets. To make the interface operational again, the port must be unplugged/plugged back or disabled/enabled using interfaces s/p admin down and interfaces s/p admin up. Also, a SNMP trap will be sent when an interface goes down because of the user-port shutdown profile. You can configure a Port Disable rule to administratively disable an interface when matching a policy rule. To make the interface operational again, the port must be unplugged/plugged back or disabled/enabled using interfaces s/p admin down and interfaces s/p admin up. Also, a SNMP trap will be sent when an interface goes down when matching a port disable rule This feature is supported on OS6850/9000 in 6.1.3.R01. Policy routing allows the user to specify gateways to be used for routed data flows based on various criteria. IP Protocol (i.e. ICMP, TCP, ICMP) Source IP address (or network group) Destination IP address (or network group) Source TCP/UDP port Destination TCP/UDP port Souce TCP/UDP service Destination TCP/UDP service Source TCP/UDP service group Destination TCP/UDP service group TOS, DSCP Source vlan Source slot/port Source slot/port group The action that can be specified is a gateway to be used overriding the routing database. Permanent gateway is supported in 6.1.1.R02, alternate gateway is not supported. Permanent gateway can be set to local next hop IP or remote hop IP. PBR is done in hardware. Note regarding bridged data flows PBR is also supported on bridged packets if a static ARP is configured for the permanent gateway. That way you can force bridged packets to be routed to that permanent gateway.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 204 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

High Availability
High Availability The switch provides a broad variety of availability features. Availability features are hardware- and software-based safeguards that help to prevent the loss of data flow in the unlikely event of a subsystem failure. In addition, some availability features allow users to maintain or replace hardware components without powering off the switch or interrupting switch operations. Combined, these features provide added resiliency and help to ensure that the switch or virtual chassis is consistently available for day-to-day network operations. Smart Continuous Switching: Hot Swap, Management Module Fail-over, Power Monitoring, Redundant subsystems in stacked configurations, and Stackability Virtual chassis design that provide management functionality and automatic election of primary and secondary managers Redundant Management & Switch Fabric (stacking configuration) o Virtual chassis that provides management functionality and automatic election of primary and secondary managers Fault tolerant loop stacking (Redundant Stacking link) Hot swappable components & hot insertable support: switch modules, SFPs/XFPs o Hot swappable switch units and power supplies Redundant (Backup) Power Supplies (Redundant 1:1 power provided by the OS6850-BPS) Redundant 1: 1 PoE power provided by the PoE Power Supplies Spanning Tree robustness (Single or Multiple STP options): IEEE 802.1D (STP) (802.1D spanning tree for loop free topology and link redundancy) and IEEE 802.1w-Rapid Reconfiguration of Spanning Tree (allows sub-second failover to redundant link) o Ring Rapid Spanning Tree optimized for ring topology to provide less than 100ms convergence time o IEEE 802.1s multiple spanning tree and Alcatel per-VLAN spanning tree (1x1) o PVST+ Fast forwarding mode on user ports to bypass 30-second delay for spanning tree Prevents unauthorized spanning-tree enabled attached bridges from operating. BPDU blocking automatically shuts down switch ports being used as user ports if a spanning tree BPDU packet is seen. Prevents unauthorized spanning-tree enabled attached bridges from operating. Priority queues: eight hardware-based queues per port VRRP (Virtual Router Redundancy Protocol), and OSPF ECMP (Equal Cost Multipath Protocol) Dynamic link aggregation IEEE 802.3ad (that supports automatic configuration of link aggregates with other switches) with resilient uplink capabilities Static link aggregation with OmniChannel (that supports automatic configuration of link aggregates with other switches) IEEE 802.1s: MISTP (802.1s) is an IEEE standard which allows several VLANs to be mapped to a reduced number of spanning-tree instances. This is possible since most networks do not need more than a few logical topologies. Each instance handles multiple VLANs that have the same Layer 2 topology. Software Resiliency: The AOS OmniSwitch product family provides fully redundant and resilient system components to insure continuous, non-stop operation. This includes redundant subsystems, hot swappable modules, load-sharing components, hitless software loading, downloadable bootstrap, and image rollback which allows the system to automatically re-load previous configurations and software versions. o Software image and configuration recovery (Software Rollback) Image rollback to automatically re-load previous configurations and software versions o Image and configuration synchronization for Management Modules o Hitless loading of optional advanced routing software without re-booting Broadcast storm control Downloadable bootstrap Chassis thermal protection/shutdown Hardware monitoring, temperature monitoring, and power monitoring & management Short cold and warm boot times Built-in security and device hardening Network and Link Resiliency: Network and link resiliency are important parts of network availability, and the AOS OmniSwitch product family supports advanced routing, load sharing, and mechanisms for fast reconfiguration of links between switches, servers, and other network devices. These include: o VRRP (Virtual Router Redundancy Protocol), and OSPF Equal Cost Multipath Protocol Topological Network Redundancy: In order to provide the highest levels of availability throughout an enterprise, it is important to build redundancy and resiliency into the topology at the network level to insure that links have backups and traffic is always flowing. This includes: o Physical redundancy o Layer 2 and layer 3 redundancies

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 205 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Security
Advanced Security The following is only a highlight of the advanced security features supported: Partitioned Management PM: Protected multiple user access control (i.e. the switch provides a full suite of commands that allow the user to create and modify User IDs and Passwords (multiple administrative profiles) for access to switch management). The PM feature utilizes an on-board database, or RADIUS, LDAP authentication servers (user profiles are stored within these servers). Authenticated Switch Access (ASA): the ASA feature (user access control or device access control) with Secure Access Logging (AAA service) utilizes an on-board database, RADIUS, LDAP, or ACE authentication servers Automatic Log-out based on a pre-configured timer Denial of Service Attack Defense (DOS protection) IEEE 802.1x industry standard port based authentication challenges users with a password before allowing network access o IEEE 802.1x multi-client, multi-VLAN support for per-client authentication and VLAN assignment IEEE 802.1x with group mobility IEEE 802.1x with MAC based authentication, group mobility or guest VLAN support MAC-based authentication for non-802.1x host Alcatel-Lucent Access Guardian support Port Mapping (Private VLANs) Port Binding Authenticated VLAN that challenges users with username and password and supports dynamic VLAN access based on user Support for host integrity check and remediation VLAN Security through the implementation of OmniVista Quarantine Manager (OV2770-QM) and quarantine VLAN, with OneTouch Security automation PKI authentication for SSH access Learned Port Security or MAC address lockdown allows only known devices to have network access preventing unauthorized network device access RADIUS and LDAP admin authentication prevents unauthorized switch management TACACS+ client allows for authentication-authorization and accounting with a remote TACACS+ server Secure Shell (SSH), Secure Socket Layer (SSL) for HTTPS and SNMPv3 for encrypted remote management communication Access Control Lists (ACLs) to filter out unwanted traffic including denial of service attacks; Access control lists (ACLs) are per port, MAC SA/DA, IP SA/DA, TCP/ UDP port; Flow based filtering in hardware (L1-L4) Support for Access Control List Manager (ACLMAN) Supports Microsoft Network Access Policy (NAP) protocol Switch protocol security o MD5 for RIPv2, OSPFv2 and SNMPv3 o SSHv2 for secure CLI session with PKI support o SSLv3 for secure HTTP session DHCP Snooping, DHCP-option 82, and DHCP IP Spoof protection

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 206 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Switch accessibility under DoS Attack

IP security enhancement

802.1X/Device Authentication

The following type of packets are processed in software and will increase the CPU usage: Unresolved L3 packet: unknown destination IP on a local subnet Broadcast L2 packet (including ARP requests): IP multicast packet on range 224.0.0.0-224.0.0.255: that includes routing protocol packets such as OSPF, RIPv2 and VRRP packets All IP packets going to a switch ip interfaces: ping, telnet, http Under normal conditions, the protocol packets are always prioritized in order to maintain the network topology. The following protocol packets are by default prioritized: BPDUs OSPF, RIPv2 VRRP IP multicast protocol (IGMP...) ARP (both request and reply) ARP To prevent an ARP attack, the system limits at 500 pps the number of arp packets sent to CPU (flooding of arp on the network is not limited). Also, there is an early arp discard mechanism to prevent the CPU from processing arp request not destined to a switch ip address. However, under attacks towards the switch, the CPU usage could rise dramatically and makes the switch unreachable for management (WebView, OmniVista or Telnet). In order to keep the switch reachable under attacks, some policies can be created to protect the management access. Supported platform: OS6800, OS6850, and OS9000 Detect ARP Flood Detect packets received with invalid Source IP addresses Detect packets received with invalid Destination IP addresses Detect multicast packets with a source MAC that is multicast Detect multicast packets with mismatching destination IP and MAC address Detect multicast packets with a Unicast destination IP and Multicast destination MAC address Detect ping overload Detect packets with Loopback source IP address Supported platform: OS6800, OS6850, and OS9000 There are 4 levels of 802.1x/device classification: -Basic 802.1x port. Only successful authenticated 802.1x devices are allowed in the network -Basic 802.1x port + fail authentication policies. Only 802.1x capable devices are allowed in the network. These policies allow the failed authenticated 802.1x devices to access non-secured (or non authenticated) VLANs -802.1x + non supplicant policies without Mac authentication. Non 802.1x devices are allowed on nonsecured VLANs according to the non-supplicant policies. -802.1x + non supplicant policies with Mac authentication. In this mode, the non 802.1x devices will follow either the non-supplicant authentication pass policies when the Mac authentication is successful or the non-supplicant authentication fail policies when the Mac authentication failed The open-unique and open-global options are no longer applicable. Device Authentication: Maximum number of supplicants / non-supplicant users per system: 1024 Maximum number of non-supplicant users per port: 1024 Maximum number of supplicant users per port: 253 Maximum combined number of supplicant and non-supplicant users per port: 1024 The system supports up to 1024 authenticated/mobile Mac-addresses. Supported/non-supported mobile rule on device authentication: 1. Support rule per tagged/untagged packet type. Mac rule apply on UNTAGGED packet IP subnet rule apply on UNTAGGED packet Protocol rule apply on UNTAGGED packet Port-protocol binding rule apply on UNTAGGED packet Mac-port binding rule apply on UNTAGGED packet Mac-IP-port binding rule apply on UNTAGGED packet Mobile-tag apply on TAGGED packet * Mobile tag only apply on tagged packets, all other rules apply on untagged packet. 2. DHCP related mobile rules are not supported with device authentication (i.e. supplicant/nonsupplicant cases) DHCP generic rule DHCP port rule DHCP Mac / Mac range rule Device authentication with Alcatel-Lucent IP phone:

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 207 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

ACLMAN

DHCP Snooping Traffic Filtering User Authentication

Switch protocol security Switch management User-port shutdown profile

Port Disable

Alcatel-Lucent Dynamic IP phone has 3 modes: 1.Untagged dynamic Packet is always untagged. 2.Tagged dynamic Packet is always tagged based on administrator config on phone. 3.Alcatel-Lucent dynamic First packet is untagged, second packet onward is tagged. ACLMAN is a function of the QoS subsystem in AOS. ACLMAN allows a network administrator to manage ACLs using default industry standard syntax on Alcatel-Lucent switches. To enforce the ACLs, ACLMAN translates default industry standard syntax into Alcatel-Lucent QoS filtering policies in a manner transparent to the ACLMAN user. ACLMAN provides the following: The ability to import text files from flash containing default industry standard ACL syntax An interactive shell emulating the default industry standard CLI ACL command syntax ACLMAN supports the following default industry standard ACL types: Standard ACLs Extended ACLs Numbered ACLs Named ACLs These are the limitations for the 6.1.2.R03 release. - Only supported on the OS6850 Series - No stacking support - ACLMAN is restricted by the same number of rule limitations that QoS supports - ACL names are limited to 16 characters Number of DHCP Bindings per ASIC: 126 Number of DHCP Bindings per port: 126 Flow based filtering in hardware (L1-L4) IEEE 802.1x, with Group Mobility & Guest VLAN support MAC based Authentication for non-802.1x host Authenticated VLAN (web & telnet based authentication) MD5 for RIPv2, OSPFv2 and SNMPv3 SSH for secure CLI session and SSL for secure HTTP session Local authentication database Remote authentication RADIUS, LDAP & ACE servers Instead of filtering packets, you can configure a user-port profile to administratively disable an interface upon reception of spoof/BPDUs/rip/ospf/bgp packets. To make the interface operational again, the port must be unplugged/plugged back or disabled/enabled using interfaces s/p admin down and interfaces s/p admin up. Also, a SNMP trap will be sent when an interface goes down because of the user-port shutdown profile. You can configure a Port Disable rule to administratively disable an interface when matching a policy rule. To make the interface operational again, the port must be unplugged/plugged back or disabled/enabled using interfaces s/p admin down and interfaces s/p admin up. Also, a SNMP trap will be sent when an interface goes down when matching a port disable rule

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 208 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Denial of Services (DOS) attacks

The system sustained Denial of Services attacks from Nessus and no switch anomalies (crash or service interruptions) were observed while running the attacks. Nessus has reported the following vulnerabilities: alya.cgi (Backdoors) AnalogX denial of service (Denial of Service) cisco http DoS (Denial of Service) AnalogX denial of service by long CGI name (Denial of Service) Jigsaw webserver MS/DOS device DoS (Denial of Service) Trend Micro OfficeScan Denial of service (Denial of Service) BadBlue invalid GET DoS (Denial of Service) DCShop exposes sensitive files (General) OpenSSH < 3.0.1 (Gain a shell remotely) Quicktime/Darwin Remote Admin Exploit (Gain a shell remotely) OpenSSL overflow via invalid certificate passing (Gain a shell remotely) TESO in.telnetd buffer overflow (Gain root remotely) OpenSSH AFS/Kerberos ticket/token passing (Gain root remotely) OpenSSH <= 3.3 (Gain root remotely) OpenSSH < 3.7.1 (Gain root remotely) Oracle Application Server Overflow (Gain Root Remotely) AliBaba path climbing (Remote file access) Note: The Nessus suite was tested under the following platform. The following are the versions of Nessus and the Linux platform used. Nessus version: 2.2.0 Linux OS: Fedora Core Release 1 The reported failures are not a threat but a check against the switch which the test Nessus suite reported as vulnerable. For example, when running port scan Nessus will report failures against ports that should not respond or be open but are internal ports leveraged by the subsystem. As the report stated there is no anomalies detected or crashes from the scan.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 209 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Management
Simplified Manageability The following is only a highlight of the advanced network and switch management features supported by the OmniSwitch 6850 Series: OmniVista NMS: Alcatel-Lucents Single voice, data and services network management including OneTouch QoS and SecureView. Carrier-Class Dynamic Mobility Through the application of a comprehensive QoS feature set, the AOS OmniSwitch product family is capable of supporting converged applications such as the VoIP Diagnosing Switch problems: o Port Mirroring; Port based, port mirroring for troubleshooting, supports one session with multiple sources-to-one destination configuration o Port monitoring feature that allows capture of Ethernet packets to a file, or for on-screen display to assist in troubleshooting o SFlow v5 support to monitor and effectively control and manage the network usage o RMON: Supports RFC 2819 RMON group (1-Statistics, 2-History, 3-Alarm, and 9-Events) o Switch Health o Monitoring Memory Tools & Switch Configuration o Switch Logging Local (on the flash) and remote logging (Syslog) Logging into the Switch through Telnet, FTP, HTTP, SSH, SSL, and SNMPv1&v2&v3 o Remote telnet management or secure shell access using SSH o Secured file upload using SFTP, or SCP o SNMPv1/v2/v3 Authentication or AAA Servers Policy Servers; Authentication Servers such as RADIUS, LDAP, and ACE servers Policy-Based Management with LDAP Directory Services System File Management Dual image and dual configuration file storage provides backup Intuitive Alcatel-Lucent CLI for familiar interface and reduced training costs WebView Element Mgmt: Easy to use point & click web based element manager with built-in help for easy configuration of new technology features Remote telnet management or secure shell Secured file upload using SFTP, or SCP Port based, port mirroring for troubleshooting, supports four sessions with four source to one destination configuration. Human readable ASCII based config files for offline editing and bulk configuration Managing Switch Users Accounts & Partitioned Management feature Managing Switch Security IGMPv1/v2/v3 snooping to optimize multicast traffic BootP/DHCP client allows auto-config of switch IP information to simplify deployment Auto-negotiating 10/100/1000 ports automatically configure port speed and duplex setting Auto MDI/MDIX automatically configures transmit and receive signals to support straight thru and crossover cabling DHCP relay to forward client requests to a DHCP server DHCP Option-82 & DHCP Snooping Integration with SNMP manager OmniVista for network wide management System event log Network Time Protocol (NTP) for network wide time synchronization Alcatel-Lucent Interswitch Protocols (AIP) o AMAP: Alcatel-Lucent Mapping Adjacency Protocol (AMAP) for building topology maps within OmniVista o 802.1AB with MED Extensions / LLDP-MED GVRP for 802.1Q-compliant VLAN pruning and dynamic VLAN creation Command Line Interface (CLI), Telnet/SSH for remote CLI access, Web-based (HTTP/HTTPS) and SNMPv1/v2c/v3 for complete NMS integration Serial Console port for local & remote (modem dial up) access (RJ45) Console Port / Serial Connection: The console port, located on the chassis front panel, provides a console connection to the switch and is required when logging into the switch for the first time. By default, this RJ-45 connector provides a DTE console connection. In-band Ethernet access

Configuration Mode Management Access types Seriral & In-band

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 210 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

System Maintenance

System file Transfer Max number of users in local database Max number of users in LDAP/RADIUS/ACE Server database (depends on server capabilities) Max number of SNMP users (login) Max number of simultaneous SNMPv3 requests Max number of simultaneous HTTP sessions Max number of simultaneous Telnet sessions Max number of simultaneous FTP sessions Max number of simultaneous Syslog servers Max number of simultaneous SSH Telnet / FTP sessions Max number of simultaneous User Login sessions Max number of simultaneous Authentications sessions (A-VLAN, A-ACL with RADIUS) Max number of authenticated ports Port Disable

Port Mirroring (one-to-one, many-to-one) RMON (Remote Monitoring): Statistics, History, Alarm & Events, and sFlow Local & Remote logging (Syslog) Detailed Statistics / Alarm / Debug information per process L3 OAM (ICMP Ping and Traceroute) NTP (Network Time Protocol) Internal flash (Compact Flash) to feature: Working Directory Certified Directory XModem and FTP (File Transfer Protocol) / SFTP (Secure FTP) / SCP 65 Greater than 1000 50 50 4 4 4 4 concurrent sessions Syslog to Multiple Hosts: You can send Syslog files to multiple hosts, up to a maximum of 4 servers. 8 13 30 48 You can configure a Port Disable rule to administratively disable an interface when matching a policy rule. To make the interface operational again, the port must be unplugged/plugged back or disabled/enabled using interfaces s/p admin down and interfaces s/p admin up. Also, a SNMP trap will be sent when an interface goes down when matching a port disable rule. A pktDrop SNMP trap will be sent out to the SNMP station when a port goes down because of a user-port shutdown profile or a port disable rule. The same unit cannot support both mirroring and monitoring configuration i.e. a user cannot have a port monitoring and a port mirroring session on the same unit Only one monitoring session at a time across the entire system Only the first 64 bytes of the packet can be monitored. Due to the port monitoring file size, the system can only store the first 2K packets (i.e. 140K/64 = 2187) Enabling the monitoring function affects the performance. As every single monitored packet is enqueued to the CPU, the Q-Dispatcher has to de-queue and look at each and every packet to determine if the destination is PMM (port monitoring module). The performance will be limited by the efficiency of Q-Dispatcher de-queuing speed and also the speed at which PMM can get the packets from Q-Dispatcher through IPC. Due to the performance limitations, monitoring wire rate traffic is not possible at this time. The packets coming to CPU are always tagged and undergo the same FFP modifications as mirroring Port Monitoring not supported on Link Aggregation The N-to-1 port mirroring allows the user to specify multiple numbers of ports, range of ports as mirrored source in a single command. However the maximum number of mirror source ports could be set to 128 for the current release. A user can mirror multiple 10GigE towards 1 port GigE. Of course if more than 1 GigE of traffic we don't expect one to mirror more that the port can deliver Aggregate ports are allowed to be mirrored on the physical ports. Mirroring on the logical link aggregated port ID is not supported. In mirroring, the packet coming out of mirroring port may be different from the ingress packet, based on the type of switching. For all types of mirroring, the mirrored packet carries the FFP (Fast Filtering Processor) modification, mirrored packet may get modified. To mirror port 1/1 to port 1/4, you can choose the following options: In-port Out-port Bi-directional

SNMP Traps Port Monitoring

Port Mirroring

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 211 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Port Mapping (AKA Private VLAN) Allows traffic segregation at L2 User ports in the same session cannot talk to each other Note: this feature is part of Residential bridging features

SCP (Secure Copy)

SFLOW

Port Mapping is a security feature that controls peer users from communicating with each other. A Port Mapping session comprises a session ID and a set of user ports and/or a set of network ports. User ports within a session cannot communicate with each other and can only communicate via network ports. In a Port Mapping session with user port set A and network port set B, ports in set A can only communicate with ports in set B. If set B is empty, ports in set A can communicate with rest of the ports in the system. A port mapping session can be configured in unidirectional or bidirectional mode. In the unidirectional mode, the network ports can communicate with each other within the same session. In the bidirectional mode, the network ports cannot communicate with each other. Network ports of a unidirectional port mapping session can be shared with other unidirectional sessions, but cannot be shared with any sessions configured in bidirectional mode. Network Ports of different sessions can communicate with each other. Port Mapping Specifications: Ports Supported: Ethernet (10 Mbps)/Fast Ethernet (100 Mbps)/Gigabit Ethernet (1 Gb/1000 Mbps) /10 Gigabit Ethernet (10 Gb/10000 Mbps). Mapping Sessions: Eight sessions supported per standalone switch and stack. Port Mapping Defaults: Mapping Session: Creation: No mapping sessions Mapping Status configuration: Disabled Port Mapping Direction: Bi-directional SCP command can be used to get/put the file from/to the server. The scp CLI command is available for copying files in a secure manner between hosts on the network. The scp utility performs encrypted data transfers using the Secure Shell (SSH) protocol. In addition, scp uses available SSH authentication and security features, such as prompting for a password if one is required. Since OS6800/OS6850 does not have any SCP-daemon running on the switch, therefore this feature only works when OS6800/OS6850 works as a client instead of the server. This feature has been validated with SSH 4.0 on Solaris and Linux platforms. Since SSH 4.0 contains SCP, SFTP and SSH features, therefore the system allows the network administrator to create the local user database to specify all domain or family of features (i.e. the family of feature that a user can have access). When a user is being created, all allowed access need to be defined. SFlow is a network monitoring technology that gives visibility to the activity of the network, by providing network usage information. It provides the data required to effectively control and manage the network usage. SFlow is a sampling technology that meets the requirements for a network traffic monitoring solution. SFlow is a sampling technology embedded within switches/routers defined in RFC 3176. It provides the ability to monitor the traffic flows. It requires an sFlow Agent running in the Switch/Router and a sFlow collector which receives and analyses the monitored data. SFlow agent running on the OS6850, combines interface counters and traffic flow (packet) samples on all the configured interfaces into sFlow Datagrams that are sent across the network to an sFlow collector (3rd Party software). Packet sampling is done in hardware and is non-CPU intensive. Current release (6.1.3r01) will not support IPv6 as Collector. The switch sends the first 128 bytes of the sampled packet from which the entire layer 2/3/4 information can be extracted by the receiver. This could include: - Source/Destination Mac address - Source IP/ Destination IP - Source/Destination TCP/UDP/ICMP port - Source/Destination Physical port (Gigabit Port) - IPv4/IPv6 - RIP/OSPF/BGP/PIM-SM/DM (OK, but if this info. falls within the first 128Bytes of the packet) - VLAN - QoS 802.1Q, ToS and DiffServ (DSCP) - Data Payload (OK, but if this information falls within the first 128 Bytes of the packet) - Others (If this information falls within the first 128 Bytes of the packet) Given an IP Address the SFLOW sampling information can be sent to a Collector such as the InMon and/or the Crannog.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 212 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

SFLOW Back-off Algorithm

Since the CPU of switch is involved in the datagram processing, there is a built in back-off algorithm which will automatically adjust the sampling rate in the case of CPU congestion on switch. This back-off mechanism is not user-configurable in Release 6.1.3r01. If CPU is congested it automatically continues to double the sampling rate, and will continue to do so up to a very low rate of 1 sample in 2147483647 (2exp31)-1. For a 1Gig interface, the bit rate is 1,000,000,000 bits per second. The back-off algorithm is designed to take effect when the sample rate exceeds 10 samples per second on any interface. Since each sample is configured by default for 128bytes this is 10x128x8 or 10 samples/sec x 1024 bits/sample or 10x1024 bps 1Gbps / 10x1024 bps = 97656 sampling rate. Sampling with all available slot/ports at 10G wire-rates on OS9000 and all ports at 1G on the OS6850 keep backing-off up to 2,147,483,647 and stay fixed at this value until the traffic generation is halted or reduced. That is even running only one 1G interface at wire rate on the OS6850 will back-off to 2147483647 and stay at this (maximum, safe) sampling rate. Recommended sampling rates for various speeds at various load: Sampling Rates Medium Heavy Light Load Load Load 256 512 1024 512 1024 2048 8192* 65536* Max*

Link Speed 10Mb/s 100Mb/s 1Gb/s

TACACS+

10Gb/s 2048 4096 Max* *8192 is the empirical value found in the lab for 10Mbs, 65536 for 100 Mbps *Max: because the OS6850 always backs-off to a max sampling rate of 2147483647 for wire rate at these rates. All other values are those recommended by Inmon. Whatever the configured sampling rate, the back-off mechanism will set the meanskipcount higher or lower depending on what is the unaffecting sampling rate for the CPU. Supported platform: OS6800, OS6850, and OS9000 Release 6.1.3.R01 is the first release to support TACACS+ AAA. AOS implementation is based on the Tacacs+ Protocol: draft-grant-tacacs-02.txt, January 1997. Overview: ASA or Authenticated Switch Access to AOS OmniSwitch running 6.1.3.R01 can be configured to add servers and forward AAA requests to TACACS+. TACACS+ servers are configured similar to RADIUS or LDAP servers; however, (MD5) encryption key is optional. AAA authentication and accounting services must be configured to point to the desired TACACS+ server. It is possible to set authentication and authorization to one TACACS+ server and accounting requests to a different server. The number of configurable servers and fail over to second server is uniform across all AAA server types: Up to 4 servers can be configured and all queries will be sent to the 1st server only. If 1st server is online and user exists on 2nd server, the result will be failed authentication. If the 1st server is down, authentication and authorization requests will only be sent to next available server. If all servers are down, all logins will fail. Different AAA services can be configured to query different authentication servers. All services may use a common authentication protocol or mix of supported protocols: Telnet service may be configured to query RADIUS while http/ftp may be configured to query TACACS+. Or all may query RADIUS. Or all may query TACACS+. In all cases accounting server protocol must match authentication/authorization server protocol. AOS TACACS+ does not support authentication for network or windows domain access. Only AOS switch access with Partition Management type domain family attribute/value pairs is supported. This to say different users or groups of users may be assigned various levels of AOS switch management privileges. The TACACS+ servers run as an external server on Unix or Windows. We have tested with CISCO TACACS+ freeware for Unix and Ciscos Secure ACSv4.0 TACACS+ uses TCP instead of UDP. Each login and supported command is queried back to the server for authorization. TACACS+ configuration is fully supported with AOS WebView. Notes: Tacacs+ supports Authenticated Switch Access and cannot be used for user authentication. Authentication and Authorization operations are combined together and cannot be performed independently. This implies that when Tacacs+ authentication is enabled, Tacacs+ authorization is also enabled. Disabling Tacacs+ authentication automatically disables authorization. A maximum of 50 simultaneous Tacacs+ sessions can be supported, when no other authentication mechanism is activated. This is a limit enforced by the AAA application.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 213 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Power over Ethernet

The Standard in brief In IEEE 802.3af standard, POE transmits power over the same pair as the data. This method is called the resistive detection method. In non-802.3af or pre-802.3af standard, POE transmits power over a spare pair (not the same pair as the data). This method is called the capacitor detection method. Max power per port The max power per port is 16 watts (15.4watts by default) for OS6850 P Series. Using 350 milliamps in the standard to calculate max power, this is based on loose tolerances (3) for OS6850 POE power supply (Vmain) at 49 volts. Max power per unit OS6850 P Series can support either a 510W or 360W power supply that can be used for either a 24-port or a 48-port chassis. A 510W power supply provides 390W max per P/S for lanpower and 360W power supply gives 240W max per P/S for lanpower. IF another power supply is inserted for redundancy purposes, do not mix unlike power supply. If unlike power supplies are mixed or if an unsupported power supply (such as a 120W power supply) is used, undefined operation will result. Note that a DB25 female-male power cable is needed in order to connect between the chassis and the power supply. Note, that due to some overhead, there will less PoE power available for the end-use. Please see the P/S Specification section for more details. Lanpower Priority For port-priority, the OS6850 is set to low by default in all the ports. Therefore the lowered-numbered ports always have a higher-precedence of retaining lanpower when there is insufficient power for all the ports. In order for higher-numbered ports to have a higher priority, use the CLI command to set the port priority higher lanpower <slot/port> priority <low/high/critical>.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 214 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Source Learning
Source Learning Transparent bridging relies on a process referred to as source learning to handle traffic flow. Network devices communicate by sending and receiving data packets that each contains a source MAC address and a destination MAC address. When packets are received on switch network interface (NI) module ports, source learning examines each packet and compares the source MAC address to entries in a MAC address database table. If the table does not contain an entry for the source address, then a new record is created associating the address with the port it was learned on. If an entry for the source address already exists in the table, a new one is not created. Packets are also filtered to determine if the source and destination address are on the same LAN segment. If the destination address is not found in the MAC address table, then the packet is forwarded to all other switches that are connected to the same LAN. If the MAC address table does contain a matching entry for the destination address, then there is no need to forward the packet to the rest of the network. Source learning builds and maintains the MAC address table on each switch. New MAC address table entries are created in one of two ways: they are dynamically learned or statically assigned. Dynamically learned MAC addresses are those that are obtained by the switch when source learning examines data packets and records the source address and the port and VLAN it was learned on. Static MAC addresses are user-defined addresses that are statically assigned to a port and VLAN. Accessing MAC Address Table entries is useful for managing traffic flow and troubleshooting network device connectivity problems. For example, if a workstation connected to the switch is unable to communicate with another workstation connected to the same switch, the MAC address table might show that one of these devices was learned on a port that belonged to a different VLAN or the source MAC address of one of the devices may not appear at all in the address table. The ASIC is capable of Hardware Learning where the unknown source address of a packet could be learned by the ASIC without software intervention. The advantage of Hardware Learning is to eliminate excessive flooding problem due to the slow learning rate of Software Learning. OS6850 supports both hardware and software source learning modes. Default Chassis source learning mode is Hardware Learning. Default Chassis source learning mode is Hardware Learning. New CLI commands are available to allow user a choice of switching back to Software Learning mode. Mode will also change when the user configures to be mobile, authentication, and/or LPS port.

Hardware Learning

Source Learning Specifications

Source Learning RFCs supported Source Learning IEEE Standards supported MAC Address Table entries 2674 - Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions 802.1Q - Virtual Bridged Local Area Networks 802.1D - Media Access Control Bridges Source learning builds and maintains the MAC address table on each switch. New MAC address table entries are created in one of two ways: they are dynamically learned or statically assigned. Dynamically learned MAC addresses are those that are obtained by the switch when source learning examines data packets and records the source address and the port and VLAN it was learned on. Static MAC addresses are user-defined addresses that are statically assigned to a port and VLAN. In addition, Source Learning also tracks MAC address age and removes addresses from the MAC address table that have aged beyond the configurable aging timer value. Accessing MAC Address Table entries is useful for managing traffic flow and troubleshooting network device connectivity problems. For example, if a workstation connected to the switch is unable to communicate with another workstation connected to the same switch, the MAC address table might show that one of these devices was learned on a port that belonged to a different VLAN or the source MAC address of one of the devices may not appear at all in the address table. There are two types of source learning modes currently available: software and hardware. The software mode performs all source learning using switch software. The hardware mode takes advantage of hardware resources that are now available to perform source learning tasks. At the present time, it is possible to select the mode that is active for the chassis and/or a given set of ports. By default, hardware source learning mode is active for the switch. The exception to this is that hardware source learning is not supported on mobile or Learned Port Security (LPS) ports. As a result, only software source learning is performed on these types of ports. 16K 8K

Maximum number of learned MAC addresses per switch (distributed MAC mode disabled) Maximum number of learned MAC addresses total for a stack of up to 8 switches

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 215 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using Static MAC Addresses

MAC address aging timer 300 seconds by default

Selecting the Source Learning Mode

Using Static Multicast MAC Addresses (L2 Static Multicast)

Static MAC addresses are configured using the Mac-address-table command. These addresses direct network traffic to a specific port and VLAN. They are particularly useful when dealing with silent network devices. These types of devices do not send packets, so their source MAC address is never learned and recorded in the MAC address table. Assigning a MAC address to the silent devices port creates a record in the MAC address table and ensures that packets destined for the silent device are forwarded out that port. When defining a static MAC address for a particular slot/port and VLAN, consider the following: Configuring static MAC addresses is only supported on non-mobile ports. The specified slot/port must already belong to the specified VLAN. Use the vlan port default command to assign a port to a VLAN before you configure the static MAC address. Only traffic from other ports associated with the same VLAN is directed to the static MAC address slot/port. Static MAC addresses are permanent addresses. This means that a static MAC address remains in use even if the MAC ages out or the switch is rebooted. There are two types of static MAC address behavior supported: bridging (default) or filtering. Enter filtering to set up a denial of service to block potential hostile attacks. Traffic sent to or from a filtered MAC addr. is dropped. Enter bridging for regular traffic flow to or from the MAC addr. If a packet received on a port associated with the same VLAN contains a source address that matches a static MAC address, the packet is discarded. The same source address on different ports within the same VLAN is not supported. If a static MAC address is configured on a port link that is down or disabled, an asterisk appears to the right of the MAC address in the show Mac-address-table command display. The asterisk indicates that this is an invalid MAC address. When the port link comes up, however, the MAC address is then considered valid and the asterisk no longer appears next to the address in the display. Source learning also tracks MAC address age and removes addresses from the MAC address table that have aged beyond the aging timer value. When a device stops sending packets, source learning keeps track of how much time has passed since the last packet was received on the devices switch port. When this amount of time exceeds the aging time value, the MAC is aged out of the MAC address table. Source learning always starts tracking MAC address age from the time since the last packet was received. By default, the aging time is set to 300 seconds (5 min) and is configured on a global basis. Note. The MAC address table aging time is also used as the timeout value for the Address Resolution Protocol (ARP) table. This timeout value determines how long the switch retains dynamically learned ARP table entries. There are two types of source learning modes currently available: software and hardware. The software mode performs all source learning using switch software. The hardware mode takes advantage of hardware resources that are now available to perform source-learning tasks. At the present time, it is possible to select which mode is active for the chassis and/or a given set of ports. By default, hardware source learning mode is active for the switch. The exception to this is that hardware source learning is not supported on mobile or Learned Port Security (LPS) ports. As a result, only software source learning is performed on these types of ports. Using static multicast MAC addresses allows you to send traffic intended for a single destination multicast MAC address to selected switch ports within a given VLAN. To specify which ports will receive the multicast traffic, a static multicast address is assigned to each selected port for a given VLAN. The ports associated with the multicast address are then identified as egress ports. When traffic received on ports within the same VLAN is destined for the multicast address, the traffic is forwarded only on the egress ports that are associated with the multicast address. When defining a static multicast MAC address for a particular port and VLAN, consider the following: A MAC address is considered a multicast MAC address if the least significant bit of the most significant octet of the address is enabled. For example, MAC addresses with a prefix of 01, 03, 05, 13, etc., are multicast MAC addresses. If a multicast prefix value is not present, then the address is treated as a regular MAC address and not allowed when using the Mac-address-table static-multicast command. Multicast addresses within the following ranges are not supported: 01:00:5E:00:00:00 to 01:00:5E:7F:FF:FF & 01:80:C2:XX.XX.XX & 33:33:XX:XX:XX:XX Configuring static multicast addresses is only supported on non-mobile ports. In addition to configuring the same static multicast address for multiple ports within a given VLAN, it is also possible to use the same multicast address across multiple VLANs. The specified port or link aggregate ID must already belong to the specified VLAN. Use the vlan port default command to assign a port or link aggregate to a VLAN before you configure the static multicast address.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 216 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Software
Third Party Licenses and Notices The licenses and notices related only to such third party software are set forth below: Booting and Debugging Non-Proprietary Software The OpenLDAP Public License: Version 2.4, 8 December 2000 Linux GNU GENERAL PUBLIC LICENSE: Version 2, June 1991 University of California Carnegie-Mellon University Random.c Apptitude, Inc. Agranat RSA Security Inc. Sun Microsystems, Inc. Wind River Systems, Inc. Network Time Protocol Version 4 Alcatel-Lucent's Software Engineering Institute (SEI) Capability Maturity Model (CMM) rating for software processes meets the Level-2 (CMM-level-2) requirements. The Ethernet software is responsible for a variety of functions that support the Ethernet, Gigabit Ethernet and 10Gigabit Ethernet ports on OmniSwitch 6850 Series switches. These functions include diagnostics, software loading, initialization, and configuration of line parameters, gathering statistics, and responding to administrative requests from SNMP or CLI.

Capability Maturity Model (CMM) The Ethernet software

Operating Systems
Wind Rivers VxWorks multi-tasking O/S version 5.4 with a Kernel version 2.5. Alcatel-Lucent O/S AOS (Alcatel-Lucents Operating Systems). O/S: AOS (Alcatel-Lucent Operating Systems) based common to OS9000, OS8800, OS7000, OS6800 The AOS is uploaded onto the Flash memory. The advantage of this switch running the AOS is that it is managed using the same interface as with the rest of the Alcatel-Lucent AOS switching & routing platforms. The AOS on the OS6850 platforms provides support for the majority of the features of the larger modular platforms including layer-3 unicast routing using RIPv1&v2, VRRP, or OSPFv2. Group mobility and authenticated VLANs as well as QoS and ACL functionality are supported making the OS6850 a highly functional solution for the core of the network. The O/S supports the ability to detect operating system or other software errors, and report them to an EMS, independently of CPU hardware failures. The operating system is set to detect software exceptions, software trouble reports, and monitor registered software tasks. Depending on the severity of the problem detected the system may reboot; otherwise it just reports the problem and takes corrective action as necessary. In either case, it does communicate the problem, to the NMS in the form of an SNMP trap. Software Each OmniSwitch 6850 Chassis is shipped with base software. All advanced features (with the exception of Advanced Routing Software) are also included in the base software. Authenticated Services Software "[ECCN 5D992] Authentication bundle for Windows w/MD5, RC4, MD4, DES. This bundle provides Funk Software's Steel-Belted OS-SW-SBR-N Radius Enterprise Edition for Microsoft Windows and includes an one-year maintenance contract (maintenance releases, 7X24 phone support and e-service web access)." "[ECCN 5D992] Authentication Bundle for Solaris w/MD5, RC4, MD4, DES. This bundle provides Funk Software's Steel-Belted OS-SW-SBR-S Radius Enterprise Edition for Sun Solaris and includes an one-year maintenance contract (maintenance releases, 7X24 phone support and e-service web access)." Advanced Routing Software OS6850 Advanced Routing software. Includes support for OSPF, BGP, PIM-SM and DVMRP. OS6850-SW-AR

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 217 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Alcatel-Lucent AOS Release Briefs OVERVIEW

Alcatel-Lucent AOS provides NEW software features that are being added to the Alcatel-Lucent OmniSwitch 6850 product lines. These NEW features allow Alcatel-Lucent to compete exceptionally well within enterprise networks by enhancing the portfolio feature set in support of our value propositions of Availability, Security and Manageability. Note: Please be sure to review the Alcatel-Lucent ESD NIBU Official Release Notes Document for further information.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 218 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Whats New?
New AOS Release 6.1.2r03 sof tware features for the OS6850 Series:
Alcatel-Lucent Access Guardian/Device Authentication support (set of enhanced security features for IEEE 802.1X) Residential bridging features (DHCP Option-82, DHCP Snooping, and Port Mapping) ACLMAN (OS6850 only) IPv6 Multicast support Hardware based IPv6 (OS6850 only) SFLOW PoE SCP to server for secure upload/download SSH w ith PKI Single entry ACL and ACL extensions VLAN range in CLI and WebView f or easier configuration QoS feature enhancements f or the OS6850s BGPv4 New Transceivers o SFP Gig LH-40km, CWDM, XFP 10Gig ER 40km , XFP 10Gig ZR 80km

New Software Features (AOSv6.1.3r01)

The following software features are supported with the Release AOSv6.1.3.r01 subject to the terms & conditions as described in the AOSv6.1.3.r01 Official Release Notes.

Feature Summary
Platforms Feature
802.1Q 2005 (MSTP) 802.1W (RSTP) Spanning Tree (Default) 802.1x Device Classification (Access Guardian) Access Control Lists (ACLs) for IPv6 ACL Manager (ACLMAN) Authenticated Switch Access TACACS+ BGP Graceful Restart DHCP Option-82 DHCP Snooping Generic UDP Relay IP DOS Enhancements IP Multicast Switching (IPMS) - Proxying IPv6 Multicast Switching (IPMS) - Proxying IP Route Map Redistribution L2 DHCP Snooping L2 Static Multicast Addresses L2 MAC Address Table Size Enhancements OSPFv3 PIM and PIM-SSM (Source-Specific Multicast) Policy-Based Routing (Permanent Mode) Port Mapping Port Mirroring (1:128) Power over Ethernet (PoE) Redirection Policies (Port and Link Aggregation) Secure Copy (SCP) Server Load Balancing (SLB) SSH Public Key Authentication Syslog to Multiple Hosts VLAN Range Support VLAN Stacking and Translation VRRPv3 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS9000 OS6850/OS9000 OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS9000 OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6850 OS9000 OS6850/OS9000 OS9000 OS6850 OS9000 OS6850/OS9000 OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6850/OS9000

Software Package
Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Advanced Routing/Base Advanced Routing/Base Base Base Base Base Base Base Base Base Base Base Base Base

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 219 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

New Software Features (AOSv6.1.5r01)

The following software features are supported with the Release AOSv6.1.5.r01 subject to the terms & conditions as described in the AOSv6.1.5.r01 Official Release Notes.

Feature Summary
Platforms Feature
Increased Number of Authenticated Users IPv6 Extensions for BGP L2 DHCP Snooping Enhancements Learned Port Security Enhancements RIP Timer Configuration Server Load Balancing (SLB) Extended Conditions and Statistics OS6800/OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 Base Base Base Base Base Base

Software Package

New Software Features (AOSv6.2.1r01)

The following software features are supported with the Release AOSv6.2.1.r01 subject to the terms & conditions as described in the AOSv6.2.1.r01 Official Release Notes.

Feature Summary
Platforms Feature
Ethernet OAM GVRP IP Multicast VLAN IS-IS MAC Retention Ring Rapid Spanning Tree Protocol (RRSTP) OS6850 OS6850 OS6850 OS6850 OS6850 OS6850

Software Package
Base Base Base Advanced Routing Software Base Base

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 220 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

New Software Features (AOSv6.3.1r01)

Alcatel-Lucent Operating System (AOS) software release 6.3.1.R01 for the OmniSwitch product families is now available. This new software release is supported on OmniSwitch 6850, 6800 and 9000 product families and combines all of the features from 6.1.5.R01 and 6.2.1.R01 Alcatel-Lucent Operating System (AOS) 6.3.1 is a significant release for the OmniSwitch LAN switches with more than 50 new features. AOS 6.3.1 strengthens our security, manageability and availability value propositions. With these new features our data switch products are even better positioned to address the Ethernet access market which includes tripleplay and city network applications. Some of the new capabilities and features include: Security Traffic anomaly detection - to discover worms and prevent DoS/D-DoS propagation by automatic containment User account and password policy - Allows complex password and account policies to be enforced ARP poisoning detection Manageability Provides standards-based topology protocol LLDP- 802.1AB for third party vendor interoperability Support of MED extensions for 802.1AB for additional information on connected devices Auto-QoS traffic management making the switch accessible under all network conditions. Auto-QoS for Alcatel-Lucent IP phone traffic to simplify configuration of converged networks Availability/ performance Enriched troubleshooting capability with remote port-mirroring and policy-based mirroring Simplified migration of Ciscos locked account (L2) with support of PVST+ UDLD support for monitoring the physical configuration of cables and detect unidirectional links GRE and IP/IP tunnels ARP defense mechanism which eliminates the impact on the CPU while the ARP resolution is performed. IPv6 suite enhancements IPv6 multicast routing protocol (PIM-SM/DM) IPV6 management: ftp, telnet/ssh client, http/https, SNMP, DNS L4 ACL over IPv6 Metro Ethernet access services User and IP address management control with DHCP snooping, configurable DHCP option82 Reduced network resources required for video services with multicast TV VLAN Simplified service monitoring and troubleshooting with Ethernet OAM (802.1ag) version 7.0 Metro Ethernet Forum compliancy with service based VLAN stacking (MEF 9), service based QoS (MEF 14)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 221 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The following software features are supported with the Release AOSv6.3.1.r01 subject to the terms & conditions as described in the AOSv6.3.1.r01 Official Release Notes.

Feature Summary
Platforms Feature
31-bit Network Mask Support 802.1ab Account & Password Policies Quarantine Manager and Remediation ARP Defense Optimization ARP Poisoning Detect Auto-Qos Prioritization of IP Phone Traffic Auto-Qos Prioritization of NMS Traffic AVLAN support for IE7/Windows Vista DHCP Snooping Option-82 Data Insertion Format DSCP Range Condition ECMP RIP Support Ethernet OAM Generic Routing Encapsulation GVRP IP-IP Tunneling IP MC VLAN Support for multiple sender ports IPv6 Client and/or Server Support IPv6 Multicast Routing IS-IS Learned MAC Address Notification L4 ACLs over IPv6 Mac Authentication for Supplicant/non- Supplicant MAC Retention Traffic Anomaly Detection (Network Security) Policy Based Mirroring Port-based Ingress Limiting PVST+ Remote Port Mirroring RRSTP UDLD User Network Profiles VRRP Global Commands VLAN Stacking Eservices WebView/SNMP support for BGP IPv6 Extensions Windows Vista for WebView OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6800/OS6850 OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6850 OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000

Software Package
Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base OS6850: Advanced Routing OS9000: Base OS6850: Advanced Routing OS9000: Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base OS6800/OS6850: Advanced Routing OS9000: Base Base

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 222 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Software Supported
In addition to the new software features introduced with the AOSv6.3.1.r01 release, the following software features are also supported, subject to the terms & conditions as described in the AOSv6.3.1.r01 Official Release Notes.

Feature Summary
Platforms Feature
802.1Q 802.1Q 2005 (MSTP) 802.1D/1W Spanning Tree 802.1s Multiple Spanning tree 802.1x with Multiple Client Support 802.1x Device Classification (Access Guardian) Access Control Lists (ACLs) Access Control Lists (ACLs) for IPv6 ACL & Layer-3 Security ACL Manager (ACLMAN) Authenticated Switch Access Authenticated VLANs Automatic VLAN Containment (AVC) Basic IPv4 Routing Basic IPv6 Routing (static, RIPng) IP DoS Filtering BGPv4 BGP Graceful Restart BPDU Shutdown Ports Command Line Interface (CLI) DHCP Relay DHCP Option-82 DHCP Snooping DNS Client Dynamic VLAN Assignment (Mobility) DVMRP End User Partitioning Ethernet Interfaces Flood/Storm Control Health Statistics HTTP/HTTPS Port Configuration Interswitch Protocols (AMAP) IP DOS Filtering IPv4 Multicast Switching (IPMS) & Routing (IPMR) IPv6 Routing IPv6 Multicast Switching (MLD) IPv4 Multicast Switching (Proxying) IPv6 Multicast Switching (Proxying) IPv6 (NDP) IPv4 & IPX Routing Learned Port Security (LPS) Link Aggregation (static & 802.3ad) MAC Address Mode Local Proxy ARP Multicast Routing IP Multinetting IP Route Map Redistribution L2 DHCP Snooping L2 Static Multicast Address NTP Client OSPFv2 OSPFv3 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000

Software Package
Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Advanced Routing on the OS6800/OS6850 & Base Advanced Routing on the OS6800/OS6850 & Base Base Base Base Base Base Base Base Advanced Routing on the OS6800/OS6850 & Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Advanced Routing on the OS6800/OS6850 & Base Advanced Routing on the OS6850 & Base

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 223 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Partitioned Switch Management Per-VLAN DHCP Relay PIM & PIM-SSM (Source-Specific Multicast) Policy Server Management Policy-Based Routing (Permanent Mode) Port Mapping Port Mirroring (1:24) Port Mirroring (1:128) Port Monitoring Power over Ethernet (PoE) Quality of Service (QoS) / ACL & Layer-3 Security Enhancements Quality of Service (QoS) Redirection Policies (port and Link Aggregates) RIPv1 & RIPv2 RIPng RMON-I Router Discovery Protocol (RDP) Routing Protocol Preference Secure Copy (SCP) Secure Shell (SSHv2) SSH Public Key Authentication Server Load Balancing SFlow Smart Continuous Switching: Hot Swap Management Module Fail over Power Monitoring Redundancy SNMP Source Learning Software Rollback Spanning Tree Syslog to Multiple Hosts Switch Diagnostics Switch Logging Text File Configuration User Definable Loop-back Interface UDP Relay VLANs VLAN Stacking and Translation VRRPv2 VRRPv3 Web-Based Management (WebView)

OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6800 OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000

Base Base Advanced Routing on the OS6800/OS6850 & Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base

OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000 OS6850/OS9000 OS6800/OS6850/OS9000

Base Base Base Base Base Base Base Base Base Base Base Base Base Base Base

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 224 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Alcatel-Lucent Value Propositions: Value High Availability Embedded Security Distributed Intelligence Simplified Manageability Alcatel-Lucents fixed & stackable configuration switches (including the OmniSwitch 6850 Series) are part of the larger Alcatel-Lucent LAN enterprise switching & routing portfolio that includes the modular-based OmniSwitch 7700, 7800, 8800, and 9000 series of switches. Together, this portfolio offers a complete core solution with high availability, intelligent performance, and enhanced security in an easy to manage, flexible and scalable package.

Vallue Va ue V
Alcatel-Lucents enterprise networking mission is to provide its customers with the industry's best value in highly available, secure and easy-to-manage network solutions. The industrys best value means having leading features for availability, security and manageability and simultaneously reducing the total cost of network ownership. In short, the best network at the best total cost. With up to 384Gbps FD switching capacity, the OS6850 can be a very cost-effective distribution layer, server aggregation, or core switch. The OS6850 value offers the enterprise the opportunity to invest in the future at prices they can afford today. Key Customers: specific names of key customers will be provided upon a successful bid and/or NDA. Alcatel-Lucent provides communications solutions to telecommunication carriers, Internet service providers and enterprises for delivery of voice, data and video applications to their customers or to their employees. Alcatel-Lucent leverages its leading position in fixed and mobile broadband networks, applications and services to bring value to its customers in the framework of a broadband world. As the largest supplier of telecommunications equipment to carriers in the world, Alcatel-Lucent possesses vast experience in providing carrier class Internet routing and fiber optic solutions, including SONET multiplexing, IP and ATM switching, and wave division multiplexing equipment. For example, our 7750 routing platform is extensively used by carriers and by municipalities as a high-end routing platform with integral MPLS and VPN services. Similarly, we provide a significant portion of the electronics that ties together both the terrestrial and the undersea fiber optic infrastructure throughout the world. With sales of EURO 12.5 billion in 2003, Alcatel-Lucent operates in more than 130 countries. For more information, visit Alcatel-Lucent on the Internet: http://www.Alcatel-Lucent.com About Alcatel-Lucent Enterprise Networking Solutions Alcatel-Lucent delivers standards-based IP communications solutions to a global customer base of over 500,000 small, medium and large enterprises, government agencies, healthcare facilities, and educational institutions. Alcatel-Lucent's award-winning Omni family of IP Communications solutions consists of an extensive portfolio of network switching infrastructure products and IP telephony products built to provide long-term value. Key Partners: A longer list of Alcatel-Lucents Partners with specific Marketing relationships will be provided upon a successful bid and/or NDA. Alcatel-Lucent has created a partnering program that enables it to work with a limited set of vendors in order to provide solutions that fall outside of its core competencies. Partnerships provide channels and customers a catalog of product solutions that are easy to find, evaluate, buy, install, and operate. Some of the security partnerships Alcatel-Lucent has established include: Fortinet Security Technology Vendor: Resale, Service & Support Sygate Security Technology Vendor: Resale, Service & Support TruSecure: Professional Services Aruba Corporation (Wireless LAN products): Resale, Service & Support Funk Software Corporation: RADIUS InterLink Networks RAD: RADIUS RSA: SSL implementation and ACE Server Open SSH: SSH RSA, VASCO, ActivCard, CRYPTO Card, Secure Computing: Security Token StoneSoft: High-Availability VLANs

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 225 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

High Availability
The Alcatel-Lucent AOS OmniSwitch product family has been designed from its inception to provide carrier-class availability to meet the needs of missioncritical, IP Communications, and converged network environments. With the increasing importance of networks carrying voice and real-time applications, there is an increased need for availability that reaches across the network links and end user devices. Additionally, there is also the need for high availability in the areas of security and manageability, with intelligence and performance as integral parts of the network infrastructure to enable enterprises to achieve their availability goals. A very cost effective, highly available, highly scalable and highly re-configurable network will be achieved when the OS6850 is deployed in your LAN enterprise network. The following is only a highlight of the availability features supported by the OmniSwitch 6850 Series: Smart Continuous Switching: Hot Swap, Management Module Fail-over, Power Monitoring, Redundancy, and Stack ability Redundant Management & Switch Fabric (stacking configuration) Redundant Stacking link Hot swappable components & hot insertable support: switch modules, SFPs/XFPs Redundant Power Supplies (Redundant 1:1 power provided by the OS6850-BPS) Redundant 1: 1 PoE power provided by the PoE Power Supplies Spanning Tree robustness (Single or Multiple STP options): IEEE 802.1D (STP) (802.1D spanning tree for loop free topology and link redundancy) and IEEE 802.1w-Rapid Reconfiguration of Spanning Tree (allows sub-second failover to redundant link) o Ring Rapid Spanning Tree optimized for ring topology to provide less than 100ms convergence time o IEEE 802.1s multiple spanning tree and Alcatel per-VLAN spanning tree (1x1) o PVST+ Fast forwarding mode on user ports to bypass 30-second delay for spanning tree Prevents unauthorized spanning-tree enabled attached bridges from operating. BPDU blocking automatically shuts down switch ports being used as user ports if a spanning tree BPDU packet is seen. Prevents unauthorized spanning-tree enabled attached bridges from operating. Priority queues: eight hardware-based queues per port VRRP (Virtual Router Redundancy Protocol), and OSPF ECMP (Equal Cost Multipath Protocol) Dynamic link aggregation IEEE 802.3ad (that supports automatic configuration of link aggregates with other switches) with resilient uplink capabilities Static link aggregation with OmniChannel (that supports automatic configuration of link aggregates with other switches) IEEE 802.1s: MISTP (802.1s) is an IEEE standard which allows several VLANs to be mapped to a reduced number of spanning-tree instances. This is possible since most networks do not need more than a few logical topologies. Each instance handles multiple VLANs that have the same Layer 2 topology. Software Resiliency: The AOS OmniSwitch product family provides fully redundant and resilient system components to insure continuous, non-stop operation. This includes redundant subsystems, hot swappable modules, load-sharing components, hitless software loading, downloadable bootstrap, and image rollback which allows the system to automatically re-load previous configurations and software versions. o Software image and configuration recovery o Image and configuration synchronization for Management Modules Broadcast storm control Downloadable bootstrap Chassis thermal protection/shutdown Hardware monitoring, temperature monitoring, and power monitoring & management Short cold and warm boot times Built-in security and device hardening Network and Link Resiliency: Network and link resiliency are important parts of network availability, and the AOS OmniSwitch product family supports advanced routing, load sharing, and mechanisms for fast reconfiguration of links between switches, servers, and other network devices. These include: o VRRP (Virtual Router Redundancy Protocol), and OSPF Equal Cost Multipath Protocol Topological Network Redundancy: In order to provide the highest levels of availability throughout an enterprise, it is important to build redundancy and resiliency into the topology at the network level to insure that links have backups and traffic is always flowing. This includes: o Physical redundancy o Layer 2 and layer 3 redundancies

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 226 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The Spanning Tree Algorithm and Protocol (STP)

The Spanning Tree Algorithm and Protocol (STP) is a self-configuring algorithm that maintains a loop-free topology while providing data path redundancy and network scalability. Based on the IEEE 802.1D standard, the Alcatel.Lucent STP implementation distributes the Spanning Tree load between the primary management switch in the stack and the other switches in the stack. This ensures a Spanning Tree that continues to respond to STP Bridge Protocol Data Units (BPDU) received on switch ports and port link up and down states in the event of a management fail over to a backup management switch. In addition, the Alcatel.Lucent distributed implementation incorporates the following Spanning Tree features: Configures a physical topology into a single STP to ensure that there is only one data path between any two switches. Supports fault tolerance within the network topology. The Spanning Tree is reconfigured in the event of a data path or bridge failure or when a new switch is added to the topology. Supports two Spanning Tree operating modes; flat (single STP instance per switch) and 1x1 (single STP instance per VLAN). 1x1 mode can be configured to interoperate with Ciscos proprietary Per VLAN Spanning Tree instance (PVST+). Supports four Spanning Tree Algorithms; 802.1D (STP), 802.1w (RSTP), 802.1Q 2005 (MSTP), and RRSTP. Allows 802.1Q tagged ports and link aggregate logical ports to participate in the calculation of the STP topology. The Distributed Spanning Tree software is active on all switches by default. As a result, a loop-free network topology is automatically calculated based on default Spanning Tree switch, VLAN, and port parameter values. It is only necessary to configure Spanning Tree parameters to change how the topology is calculated and maintained. Spanning Tree Overview Alcatel-Lucent switches support the use of the 802.1D Spanning Tree Algorithm and Protocol (STP), the 802.1w Rapid Spanning Tree Algorithm and Protocol (RSTP), the 802.1Q 2005 Multiple Spanning Tree Protocol (MSTP), and the Ring Rapid Spanning Tree Protocol (RRSTP). RSTP expedites topology changes by allowing blocked ports to transition directly into a forwarding state, bypassing listening and learning states. This provides rapid reconfiguration of the Spanning Tree in the event of a network path or device failure. The 802.1w standard is an amendment to the 802.1D document, thus RSTP is based on STP. Regardless of which one of these two protocols a switch or VLAN is running, it can successfully interoperate with other switches or VLANs. 802.1Q 2005 is a new version of MSTP that combines the 802.1D 2004 and 802.1S protocols. This implementation of 802.1Q 2005 also includes improvements to edge port configuration and provides administrative control to restrict port role assignment and the propagation of topology change information through bridge ports. MSTP is an enhancement to the 802.1Q Common Spanning Tree (CST), which is provided when an Alcatel-Lucent switch is running in the flat Spanning Tree operating mode. The flat mode applies a single spanning tree instance across all VLAN port connections on a switch. MSTP allows the configuration of Multiple Spanning Tree Instances (MSTIs) in addition to the CST instance. Each MSTI is mapped to a set of VLANs. As a result, flat mode can now support the forwarding of VLAN traffic over separate data paths. RRSTP is faster than MSTP. It is used in a ring topology where bridges are connected in a point to point manner. This protocol identifies the bridge hosting the alternate (ALT) port in lesser convergence time. This ALT port is changed to the forwarding state immediately without altering the MSTP state to enable the data path. The RRSTP frame travels from the point of failure to the bridge hosting the ALT port in both the directions. The MAC addresses matching the ports in the ring are flushed to make the data path convergence much faster than normal MSTP.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 227 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Spanning Tree Specifications & Defualts Maximum number of Spanning Tree instances per stand-alone or per stack: 252

IEEE Standards supported 802.1DMedia Access Control (MAC) Bridges 802.1wRapid Reconfiguration (802.1D Amendment 2) 802.1Q 2005Virtual Bridged Local Area Networks 802.1Q 2005Multiple Spanning Trees (MSTP) Spanning Tree Operating Modes supported: Flat mode - one spanning tree instance per switch 1x1 mode - one spanning tree instance per VLAN Spanning Tree Protocols supported: 802.1D Standard Spanning Tree Algorithm and Protocol (STP) 802.1w Rapid Spanning Tree Algorithm and Protocol (RSTP) 802.1Q 2005 Multiple Spanning Tree Protocol (MSTP) Ring Rapid Spanning Tree Protocol (RRSTP) Spanning Tree port eligibility: Fixed ports (non-mobile) 802.1Q tagged ports Link aggregate of ports Number of 1x1 Spanning Tree instances: 252 Number of Multiple Spanning Tree Instances (MSTI) supported: 16 MSTI, in addition to the Common and Internal Spanning Tree instance (also referred to as MSTI 0). Number of Ring Rapid Spanning Tree rings (RRSTP) supported: 128 CLI Command Prefix Recognition: All Spanning Tree commands support prefix recognition. Spanning Tree Bridge Parameter Defaults Spanning Tree operating mode: 1x1 (a separate Spanning Tree instance for each VLAN) Spanning Tree protocol: RSTP (802.1w) BPDU switching status: Disabled Spanning Tree priority level for the bridge (VLAN): 32768 Hello time interval between each BPDU transmission.: 2 seconds Maximum aging time allowed for Spanning Tree information learned from the network: 20 seconds Spanning Tree port state transition time: 15 seconds Automatic VLAN Containment: Disabled Capability of 1X1 mode to interoperate with Ciscos PVST+ mode: Disabled Spanning Tree Port Parameter Defaults Spanning Tree port administrative state: Enabled Spanning Tree port priority value:7 Spanning Tree port path cost: 0 (cost is based on port speed) Path cost mode: Auto (16-bit in 1x1 mode and STP or RSTP flat mode, 32-bit in MSTP flat mode) Port state management mode: Dynamic (Spanning Tree Algorithm determines port state) Type of port connection: auto point to point Type of BPDU to be used on a port when the 1X1 mode is configured to interoperate with Ciscos PVST+ mode: Auto Multiple Spanning Tree (MST) Region Defaults The MST Region Name: Blank The revision level for the MST region: 0 The maximum number of hops authorized for the region: 20 The number of Multiple Spanning Tree Instances (MSTI): 1 (flat mode instance) The VLAN to MSTI mapping: All VLANs are mapped to the Common Internal Spanning Tree (CIST) instance Ring Rapid Spanning Tree (RRSTP) Defaults The following parameter value is specific to RRSTP and is only configurable when the flat mode is active on the switch. Ring status: Disabled

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 228 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IEEE 802.1W (RSTP) Default IEEE 802.1s Multiple Spanning Tree Protocol (MSTP)

The Rapid Spanning Tree Protocol (RSTP) is the default Spanning Tree protocol for the OmniSwitch 6800/6850/9000 regardless of which mode (flat or 1x1) is active. The Alcatel-Lucent Multiple Spanning Tree (MST) implementation provides support for the IEEE 802.1s Multiple Spanning Tree Protocol (MSTP). In addition to the 802.1D Spanning Tree Algorithm and Protocol (STP) and the 802.1w Rapid Spanning Tree Algorithm and Protocol (RSTP), MSTP also ensures that there is always only one data path between any two switches for a given Spanning Tree instance to prevent network loops. MSTP is an enhancement to the 802.1Q Common Spanning Tree (CST), which is provided when an Alcatel-Lucent switch is running in the flat Spanning Tree operating mode. The flat mode applies a single spanning tree instance across all VLAN port connections on a switch. MSTP allows the configuration of Multiple Spanning Tree Instances (MSTIs) in addition to the CST instance. Each MSTI is mapped to a set of VLANs. As a result, flat mode can support the forwarding of VLAN traffic over separate data paths. In addition to 802.1s MSTP support, the 802.1D STP and 802.1w RSTP are still available in either the flat or 1x1 mode. However, if using 802.1D or 802.1w in the flat mode, the single spanning tree instance per switch algorithm applies. MST Specifications: IEEE Standards supported: 802.1DMedia Access Control (MAC) Bridges 802.1wRapid Reconfiguration (802.1D Amendment 2) 802.1QVirtual Bridged Local Area Networks 802.1sMultiple Spanning Trees (802.1Q Amendment 3) Spanning Tree Operating Modes supported: Flat mode - one spanning tree instance per switch 1x1 mode - one spanning tree instance per VLAN Spanning Tree Protocols supported: 802.1D Standard Spanning Tree Algorithm and Protocol (STP) 802.1w Rapid Spanning Tree Algorithm and Protocol (RSTP) 802.1s Multiple Spanning Tree Algorithm and Protocol (MSTP) Ring Rapid Spanning Tree Protocol (RRSTP) Spanning Tree Port Eligibility: Fixed ports (non-mobile) 802.1Q tagged ports Link aggregate of ports Number of 1x1 Spanning Tree instances supported: 253 Number of Multiple Spanning Tree Instances (MSTI) supported: 16 MSTI in addition to the Common and Internal Spanning Tree instance (also referred to as MSTI 0). CLI Command Prefix Recognition: All Spanning Tree commands support prefix recognition.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 229 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

RRSTP Alcatel-Lucent switches support the use of the 802.1D Spanning Tree Algorithm and Protocol (STP), the 802.1w Rapid Spanning Tree Algorithm and Protocol (RSTP), the 802.1Q 2005 Multiple Spanning Tree Protocol (MSTP), and the Ring Rapid Spanning Tree Protocol (RRSTP). RRSTP is faster than MSTP. It is used in a ring topology where bridges are connected in a point to point manner. This protocol identifies the bridge hosting the alternate (ALT) port in lesser convergence time. This ALT port is changed to the forwarding state immediately without altering the MSTP state to enable the data path. The RRSTP frame travels from the point of failure to the bridge hosting the ALT port in both the directions. The MAC addresses matching the ports in the ring are flushed to make the data path convergence much faster than normal MSTP. The max number of nodes in a ring running RRSTP is 40.

PVST+ Interoperability

Ring Rapid Spanning Tree Protocol (RRSTP) is complimentary to the Multiple Spanning Tree Protocol (MSTP) but is designed to provide a faster convergence time than MSTP. Note that RRSTP is supported only in a ring topology where switches are connected point to point. In addition, there can be no alternate connections for the same instance between any two switches within a ring topology. RRSTP reduces convergence time by finding the bridge that hosts the alternate (ALT) port and immediately changing the ALT port state to forwarding without altering the MSTP port state. This process quickly enables the data path. The RRSTP frame travels from the point of failure to the ALT port in both directions. The MAC addresses corresponding to the ports in the ring are flushed to make the data path convergence time much faster than the normal MSTP. While RRSTP is already reacting to the loss of connectivity, the standard MSTP BPDU carrying the information about the link failure is processed in normal fashion at each hop. When this MSTP BPDU reaches the bridge whose ALT port is now in the "ALT FWD" state, due to RRSTP frame processing, it updates the MSTP state of the two ports in the ring as per the MSTP standard. RRSTP is only supported when the switch is configured in Flat mode (RRSTP or MSTP). Release 6.3.1 adds support for the OS9000 and VLAN Stacking. Ring Rapid Spanning Tree Defaults The following parameter value is specific to RRSTP and is only configurable when the flat mode is active on the switch. Ring status: Disabled by default The following limitations should be noted when using RRSTP: A port on a bridge can only be part of one RRSTP ring at any given instance. All bridges, which need to be made part of a ring, can be configured only statically. Fast convergence will not occur if an RRSTP frame is lost. However, MSTP convergence will still take place at a later time because there is no way of knowing about the RRSTP frame loss. RRSTP convergence may not happen when changes in configuration result in an unstable topology. If either of the two ports of the RRSTP ring on a bridge goes down or if one of the bridges in the ring goes down, the RRSTP convergence may not happen. However, MSTP convergence will continue without interruption. Maximum of 128 rings can participate on a switch. The current Alcatel-Lucent 1x1 Spanning Tree mode has been extended to allow all user ports on an OmniSwitch to transmit and receive either the standard IEEE BPDUs or proprietary PVST+ BPDUs. An OmniSwitch can have ports running in either 1x1 mode when connecting to another OmniSwitch, or PVST+ mode simultaneously. It is mandatory that all the Cisco switches have the Mac Reduction Mode feature enabled. Priority values can only be assigned in multiples of 4096 to be compatible with the Cisco MAC Reduction mode. In a mixed OmniSwitch and Cisco environment, it is highly recommended to enable PVST+ mode on all OmniSwitches in order to maintain the same root bridge for the topology. Alcatel-Lucents PVST+ interoperability mode is not compatible with a switch running in PVST mode. The same default path cost mode, long or short, must be configured the same way on all switches.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 230 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Static (OmniChannel) Link Aggregation

Alcatel-Lucents link aggregation software allows you to configure the following two different types of link aggregation groups: Static (OmniChannel) link aggregate groups IEEE 802.3ad Dynamic link aggregate groups Static Link aggregation allows you to combine 2, 4, or 8, physical connections into large virtual connections known as link aggregation groups. You can create up to 32 link aggregation groups on a standalone switch. You can create Virtual LANs (VLANs), configure Quality of Service (QoS) conditions, 802.1Q framing, and other networking features on link aggregation groups because the switchs software treats these Virtual links just like physical links. Load balancing for Layer 2 non-IP packets is on a MAC address basis and for IP packets the balancing algorithm uses IP address as well. Ports must be the same speed within the same link aggregate group. Using link aggregation can provide the following benefits: Scalability: You can configure up to 32 link aggregation groups that can consist of 2, 4, or 8 10Mbps, 100Mbps, 1Gbps, or 10Gbps Ethernet links in the switch. Reliability: If one of the physical links in a link aggregate group goes down (unless it is the last one) the link aggregate group can still operate. Ease of Migration: Link aggregation can ease the transition from a 100 Mbps Ethernet backbones to Gigabit Ethernet backbones. Interoperability with Legacy Switches. Static link aggregation can interoperate with OmniChannel on legacy switches. Static Link Aggregation Specifications: Maximum number of link aggregation groups per switch: 32 Number of Links per group supported: 2,4, or 8 Range for optional group name: 1 to 225 characters Note: Link aggregation traps include one that will send a trap when a single link in the aggregate group is down or cannot join the aggregate group. On the 6850's, the multiple ports must be on the same "Stack" of 6850's. They can be on separate 6850's but those 6850's must be cabled together with a Stacking cable and it must be functioning as a stack.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 231 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Dynamic (IEEE 802.3ad) Link Aggregation

Automatic Monitoring

Monitoring the Chassis

Using LEDs to Visually Monitor the Chassis

User-Driven Monitoring

Alcatel-Lucents link aggregation software allows you to configure two different types of link aggregation groups: Static link aggregate (OmniChannel) groups Dynamic link aggregate groups Dynamic Link aggregation allows you to combine 2, 4, or 8 physical connections into large virtual connections known as link aggregation groups. You can create up to 32 link aggregation groups on a standalone switch. You can create Virtual LANs (VLANs), configure Quality of Service (QoS) conditions, 802.1Q framing, and other networking features on link aggregation groups because switch software treats these virtual links just like physical links. Link aggregation groups are identified by unique MAC addresses, which are created by the switch but can be modified by the user at any time. Load balancing for Layer 2 non-IP packets is on a MAC address basis and for IP packets the balancing algorithm uses IP address as well. Ports must be the same speed within the same aggregate group. Using link aggregation can provide the following benefits: Scalability: On OmniSwitch 6850 switches, you can configure up to 32 link-aggregation groups that can consist of 2, 4, or 8 10-Mbps, 100-Mbps, 1-Gbps, or 10-Gbps Ethernet links. Reliability: If one of the physical links in a link aggregate group goes down (unless it is the last one) the link aggregate group can still operate. Ease of Migration: Link aggregation can ease the transition from a 100 Mbps Ethernet backbones to Gigabit Ethernet backbones. Dynamic (IEEE 802.3ad) Link Aggregation Specifications: IEEE Specification supported: IEEE 802.3ad Aggregation of Multiple Link Segments Maximum number of link aggregation groups per stand-alone OmniSwitch 6850 Series switches: 32 Number of Links per group supported: 2,4, or 8 Range for optional group name: 1 to 225 characters Group actor admin key: 0 to 65535 Group actor system priority: 0 to 65535 Group partner system priority: 0 to 65535 Group partner admin key: 0 to 65535 Port actor admin key: 0 to 65535 Port actor system priority: 0 to 255 Port partner admin key: 0 to 65535 Port partner admin system priority: 0 to 255 Port actor port: 0 to 65535 Port actor priority: 0 to 255 Port partner admin port: 0 to 65535 Port partner admin port priority: 0 to 255 CLI Command Prefix Recognition: All dynamic link aggregation configuration commands support prefix recognition. Note: Link aggregation traps include one that will send a trap when a single link in the aggregate group is down or cannot join the aggregate group. On the 6850's, the multiple ports must be on the same "Stack" of 6850's. They can be on separate 6850's but those 6850's must be cabled together with a Stacking cable and it must be functioning as a stack. Automatic monitoring refers to the switchs built-in sensors that automatically monitor operations. If an error is detected (e.g., over-threshold temperature), the switch immediately sends a trap to the user. The trap is displayed on the console in the form of a text error message. (In the case of an overthreshold temperature condition, the chassis displays an amber TEMP LED in addition to sending a trap.) OmniSwitch 6850 Series switches can be monitored and managed via the console port using Command Line Interface (CLI) commands. The switches can also be monitored and managed via the Ethernet ports using CLI commands, WebView (Alcatel-Lucent AOS web-based Element Manager), SNMPv3, and Alcatel-Lucent OmniVista NMS. The front panel of OS6850 switches and NI Modules provides status LEDs that are useful in visually monitoring the status of NI modules. Front panel LEDs include: Ethernet Port LEDs, and Slot Indicator LED System Status LEDs User-driven hardware monitoring refers to CLI commands that are entered by the user in order to access the current status of hardware components. The user enters show commands that output information to the console. Monitoring information for chassis components such as the optional back up power supply, chassis temperature sensor, chassis fansetc.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 232 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Software Rollback The directory structure inherent in the Management software allows for a switch to return to a previous, more reliable version of image or configuration files.

MAC Retention

The directory structure inherent in an OmniSwitch switch allows for a switch to return to a previous, more reliable version of image or configuration files. Changes made to the configuration file may alter switch functionality. These changes are not saved unless explicitly done so by the user. If the switch reboots before the configuration file is saved, changes made to the configuration file prior to the reboot are lost. Likewise, new image files should be placed in the working (non-certified) directory first. New image or configuration files can be tested to decide whether they are reliable. Should the configuration or images files prove to be less reliable than their older counterparts in the certified directory, then the switch can be rebooted from the certified directory, and rolled back to an earlier version. Once the contents of the working directory are established as good files, then these files can be saved to the certified directory and used as the most reliable software to which the switch can be rolled back to in an emergency situation. The MAC Retention functionality is implemented to support Smart Continuous Switching (SCS) for stackable products by retaining the base MAC address during takeover. As a result, both L2 and L3 traffic as well as the associated control protocols (e.g. routing protocols, spanning tree) shall no longer be affected during takeover. Release 6.3.1 added enhancements for avoiding duplicate MAC scenarios. If the primary element is not returned to the stack after a preset time, a trap will be generated indicating the possibility of a duplicate MAC. A duplicate MAC scenario would occur if the primary element was put back into the network since the stack has retained the primary elements MAC address. MAC Retention allows a system of stackable switches to retain the MAC address of the primary switch for a fixed or indefinite time, even after multiple takeovers. This minimizes the recalculation of protocols, such as Spanning Tree and Link Aggregation. It also minimizes the updation of tables, such as the Address Resolution Protocol (ARP) table for IPv4 routing and the Neighbor Discovery table for IPv6 routing. MAC Retention Defaults The following lists the defaults for MAC Retention configuration: MAC Address Retention status: Disabled Status of duplicate MAC Address trap: Disabled MAC Retention Overview A stack element or simply element is a switch that has designated stacking ports. The switches are operatively interconnected via these ports to form a virtual chassis referred to as a stack. Each element in a stack can be elected as the primary or the secondary element. The primary element is elected based on the highest uptime or the lowest slot number or the lowest base MAC address. The secondary element is elected based on the lowest slot number or the lowest base MAC address of the remaining elements in the stack.The system of stackable switches is generally coupled in a series and the topology of the system is generally characterized by a closed loop called a ring. A stackable switch is adapted to perform switching between its own data ports and between the data ports of other stackable switches by transmitting packets via the stacking ports. Each stack element has a unique base MAC address. Generally, the stack address is the MAC address of the current primary element. When a primary element fails, a secondary element starts functioning as the new primary element. This is known as takeover. During takeover, the stack address is also accordingly changed to reflect the base MAC address of the new primary element. Whenever a takeover occurs, it impacts not only the stack, but also the devices that communicate with that stack.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 233 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Stacking
Stackability support Users can configure up to eight (8) OmniSwitch 6850 Series switches, in any combination of OS6850-24 and OS6850-48 chassis types, into a single virtual chassis known as a stack. With stacks, simply adding additional switches to the stack can easily expand switching capacity. For example, a user can start with a stack composed of two switches and add up to six additional switches to that stack as network demands increase over time. Stacks also provide enhanced resiliency and redundancy features. If a switch in a stack goes down or is taken offline, the other elements in the stack will continue to operate without disruption. In addition, when a switch auto-synchronizes at boot-up, or if the user manually synchronizes the switches operating software and configuration parameters are backed up on all switches in the stack. As a result, the original operating software and configuration parameters can be easily recovered if corrupted or otherwise lost. In order to operate as a virtual chassis, switches within an OmniSwitch 6850 Series stack are assigned specific roles. These roles include primary and secondary management roles, idle status, and pass-through. When OmniSwitch 6850 Series switches operate in a stack, one switch in the stack always assumes the primary management role. This primary element is responsible for functions, such as software and configuration management, web-based management (i.e., WebView), SNMP management, switch diagnostics, and software rollback. One additional switch in the stack operates in a secondary management role. This switch serves as a backup, and is always ready to assume the primary management role in the stack if the switch with the primary role fails or is taken offline for any reason. Since the secondary module quickly and automatically assumes management responsibilities, switches operating in idle mode elsewhere in the stack continue to pass traffic without disruption. This redundancy provides effective safeguards for mission-critical network traffic and is one of the stacks most important failover features. In stacked configurations, one OmniSwitch 6850 switch is designated as the primary management module for the stack. Because the stack can be thought of as a virtual chassis, the role of this primary management switch is to monitor and manage the functions of the entire stack. Similar to chassis-based switches, the stack also includes a secondary, or backup, management module. A stacks secondary switch immediately takes over management functions in the event of a primary switch failure. All switches in the stack besides the primary and secondary switch are considered idle or in pass-through. Idle switches act like Ethernet Network Interface (ENI) modules chassis-based switches in that they provide mainly Ethernet connectivity for 10/100/1000 traffic. The stack provides support for all idle switches during primary switch fail-over. In other words, if the primary switch in the stack fails or goes offline for any reason; all idle switches will continue data transmission during the secondary switchs takeover process. This availability feature is referred to as Smart Continuous Switching. Complete hot stand-by (not load sharing), hot-swappable and redundant Management. In a stacking configuration, one switch is elected to provide the primary management functions while another switch is elected to provide redundancy in case of management failure. When OmniSwitch 6850 Series switches operate in a stack, one switch in the stack always assumes the primary management role. This primary element is responsible for functions such as software and configuration management, web-based management (i.e., WebView), SNMP management, switch diagnostics, and software rollback. One additional switch in the stack operates in a secondary management role. This switch serves as a backup, and is always ready to assume the primary management role in the stack if the switch with the primary role fails or is taken offline for any reason. Because the secondary module quickly and automatically assumes management responsibilities, switches operating in idle mode elsewhere in the stack continue to pass traffic without disruption. This redundancy provides effective safeguards for mission-critical network traffic and is one of the stacks most important fail-over features. Switches in a stack are connected to each other by stacking cables. The valid cable lengths are 1.5m (4.9 feet), 60cm (23.6 inches), and 30cm (11.8 inches). These stacking cables provide high-speed, dual-redundant links between switches in a stack. Stacking cables for OmniSwitch 6850 Series switches can be connected in any pattern. In other words, the cable connected to stacking port A of one switch can be connected to either stacking port A or stacking port B of the adjacent switch. However, it is strongly recommended that the cabling pattern remains consistent across the stack. In addition, for a stack to have effective redundancy a redundant stacking cable must be installed between the upper-most and bottom-most switch at all times. This provides effective failover in the event of a stacking link or module failure within the stack.

Roles Within the Stack

Primary and Secondary Management

Smart Continuous Switching Hot Swap Management Module Fail-over Power Monitoring Redundancy

Fault-tolerant Management

Primary Management to Secondary (Backup) Management Fail-over feature

Stack Cabling is supported

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 234 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Redundant Stacking Cable is supported

Hot-Swapping Modules In a Stack is supported Removing Switches from an Existing Stack is supported

Inserting switches into an existing stack is supported

Reloading of all Switches is supported Takeover

Synchronizing Switches in a Stack

Monitoring the Stack

OmniSwitch 6850 Series switches allow redundant stacking cable connections between the top-most and bottom-most switches in a stack. Important. For a stacked configuration to have effective redundancy a redundant stacking cable must be installed between the upper-most and bottom-most switch in the chassis at all times. Redundant stacking cables provide a form of dual redundancy. The redundant cable allows traffic to flow in the event of a stacking link failure. The redundant cable also provides failover if a switch goes down within the stack. Traffic continues to flow between the modules that remain operational. Units within an OmniSwitch 6850 Series virtual chassis are hot swappable. Units are essentially those modules operating in the stack in idle mode. These units can be removed from, or added to, an existing stack without disrupting other modules in the stack. When removing switches from an existing stack, observe the following important guidelines: Do not attempt to hot-swap modules operating in primary or secondary management roles Be sure the stacking cables and stacking cable redundancy are not disrupted Hot swapping is intended for switches in idle and, if applicable, pass-through status only. Removing primary or secondary management modules from a stack will trigger a failover sequence, i.e., one or more additional modules within the stack must reload in order to reassign the management roles. Whenever possible, avoid removing a switch that is operating as a primary or secondary management module. Also, removing a switch from a stacked configuration can disrupt stack cabling at the rear of the stack. When removing a module, be sure that stacking link integrity, including important stacking cable redundancy, is maintained between all remaining modules. When inserting switches into an existing stack, observe the following important guidelines: Avoid duplicate saved slot numbers Never attempt to operate more than eight switches in a single stack Make sure all switches are running the same software version. Reloading is essentially a soft boot of a switch. Users can reload stacked modules operating in any role i.e., primary, secondary, idle, and pass-through. OmniSwitch 6850 Series stacks allow users to manually force the secondary switch to assume the primary management role. This is referred to as takeover. The behavior of a takeover is similar to that of reloading the primary management module. Whenever a takeover is initiated, the switch with the secondary role automatically takes over primary management functions. The primary switch is automatically reloaded and any traffic being passed on the primary switchs Ethernet ports is interrupted. Meanwhile, the idle switch with the next-lowest slot number automatically assumes the secondary role. When the former primary module comes back up, it assumes an idle role within the stack. Management module synchronization refers to the process of copying all files in the /flash/working and /flash/certified directories of the primary management module to the /flash/working and /flash/certified directories of all the other switches in the stack. The system and configuration software on the non-primary switchesi.e., the secondary management module and any modules operating in idleis overwritten. The synchronization process ensures that the contents of these directories match exactly for all switches across the stack. This can be especially useful after new software has been loaded to the primary management module. Monitoring the current status and operation of all elements in a stack can help users avoid unexpected stack conditions. The show CLI commands are useful in monitoring stack conditions. Visually Monitoring the Stack: Users can also monitor many stack operations by viewing the front panel LEDs on all elements in the stack.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 235 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

PoE Feature
Power over Ethernet (PoE) support The Power over Ethernet (PoE) software is supported on the OS6850-P24, OS6850-P24X, OS6850-P48, and OS6850-P48X stackable switches and the OS9-GNI-P24 module. PoE provides inline power directly from the switchs Ethernet ports. From these RJ-45 ports the devices receive both electrical power and data flow. PoE detects power based on PSE devices and not on class. PoE supports both IEEE 802.3af and non-IEEE 802.3af standards. The default inline power allotted for each port is 15400 Milliwatts. The minimum inline power allotted for a port is 3000 Milliwatts and the maximum is 16000 Milliwatts (OS6850) and 18000 Milliwatts (OS9000). The maximum PoE power that a 510w power-supply (OS6850/OS9600) can provide is approximately 390 watts. A 360w power-supply (OS6850/OS9600) can provide approximately 240 watts of PoE power. The OS-IP-Shelf power supplies (OS9000) can provide approximately 600 watts of PoE power. The OS-IP- Shelf supports up to four power supplies, so a total of approximately 2400 watts is possible. The redundant power supply for PoE is only for backup. If the primary power supply fails, then PoE can switch over seamlessly to the backup power supply. Power over Ethernet (PoE) is supported on OmniSwitch 6850 Series switches and provides inline power directly from the switchs Ethernet ports. Powered Devices (PDs) such as IP phones, wireless LAN stations, Ethernet hubs, and other access points can be plugged directly into the Ethernet ports. From these RJ-45 ports the devices receive both electrical power and data flow. As the feature reduces devices dependence on conventional power sources, PoE eliminates many restrictions that traditional electrical considerations have imposed on networks. In a PoE configuration, Power Source Equipment (PSE) detects the presence of a PD and provides an electrical current that is conducted along the data cable. The PD operates using the power received via the Ethernet data cable; no connection to an additional power source (e.g., an AC wall socket) is required. As the OmniSwitch 6850 Series switches fully support 10/100/1000 Ethernet connectivity, you may also attach non-PD equipment, such as computer workstations, printers, servers, etc. to the PoE ports. Important. Alcatel-Lucent recommends that PoE-enabled switches with attached IP telephones should have operational power supply redundancy at all times for 911 emergency requirements. In addition, both the switch and the power supply should be plugged into an Uninterruptible Power Source (UPS). Note. You can also monitor all chassis components and manage many chassis features, including Power over Ethernet, with WebView; Alcatel-Lucents embedded web-based device management application. WebView is an interactive and easy-to-use GUI that can be launched from the OmniVista or a web browser. The Power over Ethernet (PoE) software is supported on the OS6850 P Series of stackable switches. PoE provides inline power directly from the switchs Ethernet ports. From these RJ-45 ports the devices receive both electrical power and data flow. PoE detects power based on PSE devices and not on class. PoE supports both IEEE 802.3af and non-IEEE 802.3af standards. The default inline power allotted for each port is 15400 Milliwatts. The minimum inline power allotted for a port is 3000 Milliwatts and the maximum is 15400 Milliwatts (OS6850). The maximum PoE power that a 510w power-supply can provide is approximately 390 watts. A 360w power-supply can provide approximately 240 watts of PoE power. The redundant power supply for PoE is only for backup. If the primary power supply fails, then PoE can switch over seamlessly to the backup power supply. Note: Please note that due to some overhead, there would be less PoE power available to the end-user. Please refer to the Power Supply Specification section for more details.

Power over Ethernet (PoE)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 236 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IEEE Standards supported Default PoE administrative status Default PoE operational status OmniSwitch 6850 Series platforms supporting PoE Cable distances supported Total number of PoE-capable ports per switch Default amount of inline power allocated for each port Range of inline power allowed for each port PoE Power availability

PoE operational status Total power allocated to a port Power Priority level for a port The capacitor detection method Priority discount status Port Priority Levels

Capacitor Detection Method is supported

PoE Specifications IEEE 802.3af DTE Power via MDI Enabled Disabled (PoE must be activated on a switch-by-switch basis). OmniSwitch 6850 Models designated with the letter P 100 meters Up to 48 15,400 Milliwatts 3,000-15,400 Milliwatts The 360W AC-to-DC Power Supply is used on the following PoE Models: OS6850-P24 & OS6850-P24L & OS6850-P24X & OS6850-P48 & OS6850-P48L & OS6850-P48X: The 360W power supply provides: 240W (-50V @ 4.8A) for in-line power and 120W (12V @ 10.0A) for system power. PoE Power Budget for the 24-port Models: 216watts [240watts (PoE power) 24watts (the overhead (power consumed by the PoE daughter card which is 1watt per port))]. PoE Power Budget for the 48-port Models: 192watts [240watts (PoE power) 48watts (the overhead (power consumed by the PoE daughter card which is 1watt per port))]. The 510W AC-to-DC Power Supply is used on the following PoE Models: OS6850-P24H & OS6850-P24LH & OS6850-P24XH & OS6850-P48H & OS6850-P48LH & OS6850-P48XH: The 510W power supply provides: 390W (50V@7.8W/port) for PoE power and 120W (12V@10.0A) for system power. The available PoE Power Budget for the 24-port Models: 366watts [390watts (PoE power) 24watts (the overhead (power consumed by the PoE daughter card which is 1watt per port))]. The available PoE Power Budget for the 48-port Models: 342watts [390watts (PoE power) 48watts (the overhead (power consumed by the PoE daughter card which is 1watt per port))]. Note: Power for all POE ports is defaulted to 15.4 watts per port and each port is configurable between 3watts to 15.4watts (Port setting is in Milliwatts (3000 to 15400)). Please note that the available PoE power budget must not be exceeded. PoE Defaults Disabled 15.4watts Low Disabled Enabled As not all Powered Devices (PDs) connected to the switch have the same priority within a customer network setting, the OmniSwitch 6850 Series switches allow the user to specify priority levels on a port-by-port basis. Priority levels include low, high, and critical. The default priority level for a port is low. Low. This default value is used for port(s) that have low-priority devices attached. In the event of a power management issue, inline power to low-priority ports is interrupted first (i.e., before critical and high-priority ports). High. This value is used for port(s) that have important, but not mission-critical, devices attached. If other ports in the chassis have been configured as critical, inline power to high-priority ports is given second priority. Critical. This value is used for port(s) that have mission-critical devices attached, and therefore require top (i.e., critical) priority. In the event of a power management issue, inline power to critical ports is maintained as long as possible. The capacitive detection method should only be enabled to support legacy IP phones. This feature is not compatible with IEEE specification 802.3af. Please contact your Alcatel-Lucent sales engineer or Customer Support representative to find out which Alcatel-Lucent IP phones models need capacitive detection enabled.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 237 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Priority Disconnect

Monitoring Power over Ethernet via CLI

The priority disconnect function differs from the port priority function in that it applies only to the addition of powered devices (PDs) in tight power budget conditions. Priority disconnect is used by the system software in determining whether an incoming PD will be granted or denied power when there are too few watts remaining in the PoE power budget for an additional device To monitor current PoE statistics and settings, use the show lanpower command. The command output displays a list of all current PoE-capable ports, along with the following information for each port: Maximum power allocated to the port, in Milliwatts Actual power used by the port Current port status Power priority status Power on/off status Aggregate slot and chassis management information is also displayed. This information includes: Maximum watts allocated to the corresponding slot Amount of power budget remaining that can be allocated for PoE modules Total amount of power remaining that can be allocated for additional switch functions

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 238 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Embedded Securiitty Embedde d Se cu r ty u y

Alcatel-Lucents AOS OmniSwitch product family provides organizations with easy, robust and optimal ways to control access to individual infrastructure components and to the individual resources resident on the network both internally and externally. Hence, information security for Internet, Intranet and Extranet applications will be supported through the incorporation of an advanced security feature set. The OmniSwitch 6850 supports a distributed security approach, enhanced emerging security technologies, and helps secure the LAN edge using proactive and reactive strategies. The following is only a highlight of the advanced security features supported by the OmniSwitch 6850 Series: Partitioned Management PM: Protected multiple user access control (i.e. the switch provides a full suite of commands that allow the user to create and modify User IDs and Passwords (multiple administrative profiles) for access to switch management). The PM feature utilizes an on-board database, or RADIUS, LDAP authentication servers (user profiles are stored within these servers). Authenticated Switch Access (ASA): the ASA feature (user access control or device access control) with Secure Access Logging (AAA service) utilizes an on-board database, RADIUS, LDAP, or ACE authentication servers Automatic Log-out based on a pre-configured timer Denial of Service Attack Defense (DOS protection) IEEE 802.1x industry standard port based authentication challenges users with a password before allowing network access o IEEE 802.1x multi-client, multi-VLAN support for per-client authentication and VLAN assignment IEEE 802.1x with group mobility IEEE 802.1x with MAC based authentication, group mobility or guest VLAN support MAC-based authentication for non-802.1x host Alcatel-Lucent Access Guardian support Port Mapping (Private VLANs) Port Binding Authenticated VLAN that challenges users with username and password and supports dynamic VLAN access based on user Support for host integrity check and remediation VLAN Security through the implementation of OmniVista Quarantine Manager (OV2770-QM) and quarantine VLAN, with OneTouch Security automation PKI authentication for SSH access Learned Port Security or MAC address lockdown allows only known devices to have network access preventing unauthorized network device access RADIUS and LDAP admin authentication prevents unauthorized switch management TACACS+ client allows for authentication-authorization and accounting with a remote TACACS+ server Secure Shell (SSH), Secure Socket Layer (SSL) for HTTPS and SNMPv3 for encrypted remote management communication Access Control Lists (ACLs) to filter out unwanted traffic including denial of service attacks; Access control lists (ACLs) are per port, MAC SA/DA, IP SA/DA, TCP/ UDP port; Flow based filtering in hardware (L1-L4) Support for Access Control List Manager (ACLMAN) Supports Microsoft Network Access Policy (NAP) protocol Switch protocol security o MD5 for RIPv2, OSPFv2 and SNMPv3 o SSHv2 for secure CLI session with PKI support o SSLv3 for secure HTTP session DHCP Snooping, DHCP option-82, and DHCP IP Spoof protection Detect ARP poisoning Traffic Anomaly Detection (TAD) (aka Etherbreaker or Network Security) User Network Profiles

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 239 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

User Network Profiles This feature provides the capability to have "Roles" assigned to users during authentication. The 6.3.1 release allows for a VLAN to be associated to a role, users matching the role will automatically be assigned to that VLAN. The role should be configured to match the Filter-ID attribute being returned by the RADIUS server.

Security Servers supported Learned Port Security (LPS) LPS has the following limitations: You cannot configure LPS on 10 Gigabit ports. You cannot configure LPS on link aggregate ports.

IP directed broadcast

The User Network Profile feature provides the capability to have users assigned to user roles during authentication. It works only with a RADIUS authentication server. The user role is returned from the RADIUS server through the Filter-ID attributes. A mapping table is provided to look up the VLAN ID based on the user role returned from the authentication server. AAA uses the Filter-ID attribute value returned by the RADIUS server to lookup the corresponding profile name and assigns the user to the associated VLAN. The role name is a case-sensitive ASCII string. If both a VLAN ID and a role name are returned by the RADIUS server, the VLAN associated with the role name takes precedence. Multiple names can be mapped to the same VLAN. The user network profile table can have a maximum of 4096 entries and contains the following two elements: Name VLAN ID LDAP, RADIUS, and ACE Server Learned Port Security (LPS) provides a mechanism for authorizing source learning of MAC addresses on 10/100/1000 and Gigabit Ethernet ports. The only types of Ethernet ports that LPS does not support are link aggregate and tagged (trunked) link aggregate ports. Using LPS to control source MAC address learning provides the following benefits: A configurable source learning time limit that applies to all LPS ports. A configurable limit on the number of MAC addresses allowed on an LPS port. Dynamic configuration of a list of authorized source MAC addresses. Static configuration of a list of authorized source MAC addresses. Two methods for handling unauthorized traffic: stopping all traffic on the port or only blocking traffic that violates LPS criteria. A configurable limit to the number of filtered MAC addresses allowed on an LPS port. Conversion of dynamically learned MAC addresses to static MAC address entries. Support for all authentication methods and LPS on the same switch port. Configurable LPS parameters allow the user to restrict the source learning of host MAC addresses to: A specific amount of time in which the switch allows source learning to occur on all LPS ports A maximum number of learned MAC addresses allowed on the port. A list of configured authorized source MAC addresses allowed on the port. Additional LPS functionality allows the user to specify how the LPS port handles unauthorized traffic. The following two options are available for this purpose: Block only traffic that violates LPS port restrictions; authorized traffic is forwarded on the port. Disable the LPS port when unauthorized traffic is received; all traffic is stopped and a port reset is required to return the port to normal operation. LPS functionality is supported on the following 10/100/1000 and Gigabit Ethernet port types: Fixed (non-mobile) Mobile 802.1Q tagged Authenticated LPS has the following limitations: You cannot configure 802.1x and LPS on the same ports. You cannot configure LPS on 10 Gigabit ports. You cannot configure LPS on link aggregate and 802.1Q tagged ports. Learned Port Security Specifications: Ports eligible for LPS: 10/100 and Gigabit Ethernet ports (fixed, mobile, 802.1Q tagged, and authenticated ports) Ports not eligible for LPS: Link aggregated ports and 802.1Q (trunked) link aggregated ports Minimum number of learned MAC addresses allowed per port: 1 Maximum number of learned MAC addresses allowed per port: 100 Maximum number of configurable MAC address ranges per LPS port: 1 Max number of learned MAC addresses per OS6850 switch (applies to all ports on the switch): 8K An IP directed broadcast is an IP datagram that has all zeroes or all 1s in the host portion of the destination IP address. The packet is sent to the broadcast address of a subnet to which the sender is not directly attached. Directed broadcasts are used in denial-of-service smurf attacks. In a smurf attack, a continuous stream of ping requests is sent from a falsified source address to a directed broadcast address, resulting in a large stream of replies, which can overload the host of the source address. By default, the switch drops directed broadcasts. Typically, directed broadcasts should not be enabled.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 240 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Denial of Service (DOS) Attacks

IP DoS Filtering Enhancements

By default, the switch filters denial of service (DoS) attacks, which are security attacks aimed at devices that are available on a private network or the Internet. Some of these attacks aim at system bugs or vulnerability (for example, teardrop attacks), while other types of these types of attacks involve generating large volumes of traffic so that network service will be denied to legitimate network users (such as Pepsi attacks). These attacks include the following: ICMP Ping of DeathPing packets that exceed the largest IP datagram size (65535 bytes) are sent to a host and hang or crash the system. SYN AttackFloods a system with a series of TCP SYN packets, resulting in the host issuing SYN-ACK responses. The half open TCP connections can exhaust TCP resources, such that no other TCP connections are accepted. Land AttackSpoofed packets are sent with the SYN flag set to a host on any open port that is listening. The machine may hang or reboot in an attempt to respond. Teardrop/Bonk/Boink attacksBonk / Boink / teardrop attacks generate IP fragments in a special way to exploit IP stack vulnerabilities. If the fragments overlap the way those attacks generate packets, an attack is recorded. Since teardrop, bonk and Boink all use the same IP fragmentation mechanism to attack, these are no distinction between detection of these attacks. The old IP fragments in the fragmentation queue are also reaped once the reassemble queue goes above certain size. Pepsi AttackThe most common form of UDP flooding directed at harming networks. A Pepsi attack is an attack consisting of a large number of spoofed UDP packets aimed at diagnostic ports on network devices. This can cause network devices to use up a large amount of CPU time responding to these packets. The switch can be set to detect various types of port scans by monitoring for TCP or UDP packets sent to open or closed ports. Monitoring is done in the following manner: Packet penalty values set: TCP and UDP packets destined for open or closed ports are assigned a penalty value. Each time a packet of this type is received, its assigned penalty value is added to a running total. This total is cumulative and includes all TCP and UDP packets destined for open or closed ports. Port scan penalty value threshold: The switch is given a port scan penalty value threshold. This number is the maximum value the running penalty total can achieve before triggering an SNMP trap. Decay value: A decay value is set. The running penalty total is divided by the decay value every minute. Trap generation: If the total penalty value exceeds the set port scan penalty value threshold, a trap is generated to alert the administrator that a port scan may be in progress. By default, the switch filters the following denial of service (DoS) attacks, which are security attacks aimed at devices that are available on a private network or the Internet: ARP Flood Attack - OS6800/OS6850/OS9000 Invalid IP Attack - OS6850/OS9000 Multicast IP and MAC Address Mismatch - OS6850/OS9000 Ping Overload - OS6850/OS9000 Packets with loop back source IP address - OS6850/OS9000

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 241 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Traffic Anomaly Detection (TAD) (aka Etherbreaker or Network Security) Network Security Overview Network Security detects the anomalies in the network traffic by monitoring the difference in the rate of ingress and egress packets on a port, matching a specific traffic pattern. The Network Security software monitors these packets at configured intervals, counts the packets matching certain patterns, and applies anomaly detection rules. If anomalies are detected, then it is reported through a Syslog and/or an SNMP trap and/or the anomalous port is shut down.

The Traffic Anomaly Detection (TAD) feature, also referred to as Network Security, is used to detect anomalies through statistical analysis of network traffic. It can be used to detect network attacks by observing the patterns of a port through ingress and egress packets. Anomalies occur in network traffic when the traffic patterns in a network do not meet the expectations. Such anomalies are detected in real time network traffic and can be logged, generate SNMP traps, or result in disabling the anomalous port automatically. Network Security provides the following capabilities: Real time network traffic monitoring. Dynamic anomaly detection. Dynamic anomalous port quarantining. Network Security (also known as Alcatel-Lucents Traffic Anomaly Detection (TAD) feature or Etherbreaker) is a network monitoring feature that aims to detect the anomalies in the network by analyzing the patterns of ingress and egress packets on a port. These anomalies occur when the traffic patterns of a port do not meet the expectations. The detection of anomalies results in logging, SNMP trap generation, and shutting down of the anomalous port. This feature is mainly used in the Layer2 domain. Note. The Network Security feature is supported only on OmniSwitch 6850 and 9000 Series switches in Release 6.3.1. Network Security Specifications RFCs supported: Not applicable at this time. IEEE Standards supported: Not applicable at this time. Maximum number of monitoring- groups: 32 Time duration to observe traffic pattern: 5 to 3600 in seconds Minimum traffic to activate anomaly detection: 1 to 100,000 Anomaly sensitivity to deviation: 1 to 100 Network Security Defaults Status of anomaly detection: Disabled Log status: Disabled Trap status : Disabled Quarantine status: Disabled Time duration to observe traffic pattern: 30 seconds Anomaly sensitivity to deviation: 50 Anomalies A network traffic anomaly refers to deviations in the rates of a user-ports ingress and egress packets from expectations. The anomalies are monitored in the network by observing the networks traffic for a configurable time period. During this period, the Network Security counts relevant packets on a port. Anomalies may occur in scenarios, such as the following: When a high number of TCP SYN packets are not expected from a user-port in a short period. When more than one ARP response is received for every ARP request. When a high number of TCP RST packets are not expected in a network in a short period. The above listed scenarios occur in a network due to malicious systems in the network, or when a network is attacked or mis-configured. Network Security detects the following anomalies: Anomaly Description ARP Address Scan Occurs when a host sends a burst of ARP requests for multiple IP addresses. ARP Flood Occurs when a host receives a burst of ARP request packets. ARP Failure Occurs when ARP queries do not elicit ARP responses. ICMP Address Scan Occurs when multiple hosts receive ICMP echo request packets at the same time. ICMP Flood Occurs when a host receives a burst of ICMP echo request packets. ICMP Unreachable Occurs when a host receives a flood of ICMP Unreachable packets. TCP Port Scan Occurs when a host receives a burst of TCP SYN packets for multiple TCP ports. TCP Address Scan Occurs when multiple hosts receive TCP SYN packets at the same time. SYN Flood Occurs when a host receives a burst of TCP SYN packets on the same TCP port. SYN Failure Occurs when a host receives fewer SYNACKs than SYNs it sent out. SYN-ACK Scan Occurs when a host receives more SYNACKs than SYNs it sent out. Fin Scan Occurs when a host receives a burst of FIN packets. Fin-Ack Diff Occurs when a host sees more or fewer FINACK packets than it sent. Rst Count Occurs when a host receives a flood of RST packets.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 242 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Security through the implementation of OmniVista Quarantine Manager (OV2770-QM) With OneTouch Security automation

Quarantine Manager and Remediation (QMR)

Automatic log-out

The CrystalSec Security Framework has been expanded with the addition of two solutions - Host Integrity Check and Attack Containment - and two partnerships - Sygate and Fortinet. The Quarantine Manager Application enables the Network Administrator to quarantine devices to protect the network from attacks. When blocking any network traffic such as in Denial Of Service (DOS) attacks, the application works with an external Intrusion Prevention System (IPS) such as Fortinet, to send Syslog messages to the Quarantine Manager, and/or Alcatel-Lucent AOS switches to send SNMP traps to the Quarantine Manager. The information includes the address that was blocked. Quarantine Manager then sends this information to the rest of the network by placing the address into to a "Quarantined" VLAN. Depending on the rule that is written for the event, the address can be immediately quarantined or placed into a Candidate List that can be reviewed by the Network Administrator. Quarantine Manager and Remediation (QMR) is a switch-based application that interacts with the OmniVista Quarantine Manager (OVQM) application to restrict the network access of quarantined clients and provide a remediation path for such clients to regain their network access. This functionality is driven by OVQM, but the following QMR components are configured through QoS CLI commands: Quarantined MAC address group. This is a reserved QoS MAC address group that contains the MAC addresses of clients that OVQM has quarantined and that are candidates for remediation. Remediation server and exception subnet group. This is a reserved QoS network group, called alaExceptionSubnet, that is configured with the IP address of a remediation server and any subnets to which a quarantined client is allowed access. The quarantined client is redirected to the remediation server to obtain updates and correct its quarantined state. Remediation server URL. This is the URL for the remediation server. Note that this done in addition to specifying the server IP address in the alaExceptionSubnet network group. Quarantined Page. When a client is quarantined and a remediation server URL is not configured, QMR can send a Quarantine Page to notify the client of its quarantined state. HTTP proxy port group. This is a known QoS service group, called alaHTTPProxy, that specifies the HTTP port to which quarantined client traffic is redirected for remediation. The default HTTP port used is TCP 80 and TCP 8080. Note that configuring QMR and QoS inner VLAN or inner 802.1p policies is mutually exclusive. QMR overlays the inner VLAN tag, thus creating a conflict with related QoS policies. This is also true with QMR and VLAN Stacking services. QMR is activated when OVQM populates the MAC address group on the LDAP server with quarantined MAC addresses. If VLAN Stacking services or QoS inner VLAN/802.1p policies are configured on the switch, QMR will not activate. NOTE: This feature is designed to work in conjunction with OmniVistas Quarantine Manager application. Refer to the OmniVista documentation for a detailed overview of the Quarantine Manager application. Within OmniVistas Quarantine Manager application, if a MAC is added or removed from the quarantined group, or when an IP address is added or removed from the IP DA remediation, OmniVista will trigger the configured switches to perform a recache action. The switches will then query OmniVistas LDAP database and pull the addresses from the database, these addresses will then be added or removed from the switchs quarantined or remediation group. Automatic log-out based on a pre-configured timer is supported: The switch supports the capability of configuring the inactivity timer for a CLI, HTTP (including WebView), or FTP interface. When the switch detects no user activity for this period of time, the user is logged off the switch.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 243 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Authenticated VLANs A-VLANs

Authenticated VLANs control user access to network resources based on VLAN assignment and a user login process; the process is sometimes called user authentication or Layer 2 Authentication. (Another type of security is device authentication, which is set up through the use of port-binding VLAN policies or static port assignment. The total number of possible AVLAN users is 2K per system, not to exceed 1K per module or stackable unit. This number is a total number of users that applies to all authenticated clients, such as AVLAN and 802.1X supplicants or non-supplicants. The Omniswitch supports the use of all authentication methods and Learned Port Security (LPS) on the same port. The terms authenticated VLANs (A-VLANs) and Layer 2 Authentication is synonymous. Layer 2 Authentication is different from another feature in the switch called Authenticated Switch Access, which is used to grant individual users access to manage the switch. An authenticated network requires several components: Authentication serversA RADIUS or LDAP server must be configured in the network. The server contains a database of user information that the switch checks whenever a user tries to authenticate through the switch. (Note that the local user database on the switch may not be used for Layer 2 authentication.). Backup servers may be configured for the authentication server. RADIUS or LDAP server: Follow the manufacturers instructions for your particular server. The external server may also be used for Authenticated Switch Access. RADIUS or LDAP client in the switch: The switch must be set up to communicate with the RADIUS or LDAP server. Authentication clientsAuthentication clients login through the switch to get access to A-VLANs. There are three types of clients: AV-Client. This is an Alcatel-Lucent-proprietary authentication client. The AV-Client does not require an IP address prior to authentication. The client software must be installed on the users end station. Telnet client: Any standard Telnet client can be used. An IP address is required prior to authentication. Web browser client: Any standard Web browser can be used (Netscape or Internet Explorer). An IP address is required prior to authentication. Authenticated VLANsAt least one authenticated VLAN must be configured. Authentication portAt least one mobile port must be configured on the switch as an authentication port. This is the physical port through which authentication clients are attached to the switch. DHCP ServerA DHCP server can provide IP addresses to clients prior to authentication. After authentication, any client can obtain an IP address in an authenticated VLAN to which the client is allowed access. A relay to the server must be set up on the switch. Authentication agent in the switchAuthentication is enabled when the server(s) and the server authority mode is specified on the switch. Note: AVLAN Web Authentication: The Mac OS X 10.3.x is supported for AVLAN web authentication using JVM-v1.4.2. The maximum number of possible A-VLAN users support is 2,048. Release 6.3.1 added AVLAN support for IE7 and Windows Vista. An Alcatel-Lucent certificate is required to provide this support. Please contact your customer support representative to obtain this certificate.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 244 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IEEE 802.1X Note: there is no switch based local database for IEEE 802.1x authentication. Here are the limits: Maximum number of supplicants / non-supplicant users per system: 1024 Maximum number of non-supplicant users per port: 1024 Maximum number of supplicant users per port: 253 Maximum combined number of supplicant and non-supplicant users per port: 1024 The system supports up to 1024 authenticated/mobile mac-addresses. The system can roughly processes ~200 mac per seconds.

802.1X enhancements on the OmniSwitch 6850 (Synonymous with the feature titled Alcatel.Lucent Access Guardian support)

Physical devices attached to a LAN port on the switch through a point-to-point LAN connection may be authenticated through the switch through port-based network access control. This control is available through the IEEE 802.1X standard implemented on the switch. In addition, Interoperability between Alcatel-Lucent 802.1x and Sygate Management Server (SMS) and Sygate Enforcer is also supported. The identity field in Alcatel-Lucent 802.1x authentication works with all applications that send more than 32 bytes (e.g., Sygate). IEEE 802.1X Specifications: RFCs Supported: RFC 2284PPP Extensible Authentication Protocol (EAP) RFC 2865Remote Authentication Dial In User Service (RADIUS) RFC 2866RADIUS Accounting RFC 2867RADIUS Accounting Modifications for Tunnel Protocol Support RFC 2868RADIUS Attributes for Tunnel Protocol Sup-port RFC 2869RADIUS Extensions IEEE Standards Supported: IEEE 802.1X-2001Standard for Port-based Network Access Control 802.1X RADIUS Usage Guidelines The 802.1X standard defines port-based network access controls, and provides the structure for authenticating physical devices attached to a LAN. It uses the Extensible Authentication Protocol over LAN (EAPOL). There are three components for 802.1X: The SupplicantThis is the device connected to the switch. The device may be connected directly to the switch or via a point-to-point LAN segment. Typically the supplicant is a PC. The Authenticator Port Access Entity (PAE)This entity requires authentication from the supplicant. The authenticator is connected to the supplicant directly or via a point-to-point LAN segment. The OmniSwitch acts as the authenticator. The Authentication ServerThis component provides the authentication service and verifies the credentials (username, password, challenge, etc.) of the supplicant. On the OmniSwitch, only RADIUS servers are currently supported for 802.1X authentication. Note: IEEE 802.1x Multi-client and Multi-VLAN feature provides the capability to force every user behind a given port to authenticate and be placed into their own applicable VLAN and allows multiple VLANs to be properly established on a single port. In other words, multiple supplicants can be authenticated on a given 802.1x port Note: the implementation of 802.1x on the OmniSwitch 6850 as described below is also synonymous with the feature titled Alcatel.Lucent Access Guardian support: In addition to the authentication and VLAN classification of 802.1x clients (supplicants), this implementation of 802.1x secure port access extends this type of functionality to non-802.1x clients (non-supplicants). To this end device classification policies are introduced to handle both supplicant and non-supplicant access to 802.1x ports. Supplicant policies use 802.1 x authentications via a remote RADIUS server and provide alternative methods for classifying supplicants if the authentication process either fails or does not return a VLAN ID. Non-supplicant policies use MAC authentication via a remote RADIUS server or can bypass authentication and only allow strict assignment to specific VLANs. MAC authentication verifies the source MAC address of a non-supplicant device via a remote RADIUS server. Similar to 802.1 x authentications, the switch sends RADIUS frames to the server with the source MAC address embedded in the username and password attributes. The 6.3.1 release increases the number of possible 802.1X users to 2K per system, not to exceed 1K per module or stackable unit. This number is a total number of users that applies to all authenticated clients, such as AVLAN and 802.1X supplicants or non-supplicants. In addition, the 6.3.1 release also supports the use of all authentication methods and Learned Port Security (LPS) on the same port. Release 6.3.1 added the capability to classify both supplicant and non-supplicant devices using nonsupplicant device classification policies. As a result, MAC authentication is now applicable to both supplicant and non-supplicant devices. By default non-supplicant devices are automatically blocked on 802.1x-enabled ports. In some cases, however, it is desirable to allow non-supplicant access on these ports. For example, using device policies a non-supplicant may gain access to a pre-determined VLAN. Such a VLAN might serve as a guest VLAN for such devices requiring restricted access to the switch. Supplicant devices are initially processed using 802.1 x authentications via a remote RADIUS server. If authentication is successful and returns a VLAN ID, the supplicant is assigned to that VLAN. If not, then any configured device classification policies for the port are applied to determine VLAN assignment for the supplicant. If there are no policies, then the default port behavior for 802.1x ports is in affect. The following types of device classification policies are available: 1. 802.1 x authenticationsperform 802.1 x authentications via a remote RADIUS server. 2. MAC authenticationsperforms MAC based authentication via a remote RADIUS server. 3. Group Mobility rulesuses GM rules to determine the VLAN assignment for a device 4. Strict Group Mobility rulesuses Group Mobility rules to determine the VLAN assignment for a device; does not allow assignment to authenticated VLANs.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 245 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Alcatel-Lucent Access Guardian support

Port Mapping (AKA Private VLAN) Allows traffic segregation at L2 User ports in the same session cannot talk to each other Note: this feature is part of Residential bridging features

VLAN IDassigns the device to the specified VLAN. Strict VLAN IDassigns the device to the specified VLAN; does not allow assignment to authenticated VLANs. 7. Default VLANassigns a device to the default VLAN for the 802.1x port. 8. Strict Default VLANassigns a device to the default VLAN for the 802.1x port; does not allow assignment to authenticated VLANs. 9. Blockblocks a device from accessing the 802.1x port. Alcatel-Lucent Access Guardian Support entails a set of security features that provide: o Automatic detection of 802.1x and non-802.1x devices o Flexible per port configuration of securities policies o 802.1x is used for user authentication, MAC-based authentication can be used for non-802.1x clients o Supported policies: Group Mobility rules Guest VLANs Default VLAN Block o Centralized location for user/device authentication-using RADIUS o Separate security policies can be configured for supplicants and non-supplicants Benefits: o Allows for flexible networks configuration which strengthens the security o Centralized management of users and devices reduces the administration cost All known users and devices are authenticated using RADIUS Change in one place only, takes effect everywhere in the network A mobile user will authenticate the same way a "wired" user o Guest users are placed in guest VLAN Applications: o Educational sector Port Mapping is a security feature, which controls communication between peer users. Each session comprises a session ID, a set of user ports, and/or a set of network ports. The user ports within a session cannot communicate with each other and can only communicate via network ports. In a port mapping session with user port set A and network port set B, the ports in set A can only communicate with the ports in set B. If set B is empty, the ports in set A can communicate with rest of the ports in the system. A port mapping session can be configured in the unidirectional or bi-directional mode. In the unidirectional mode, the network ports can communicate with each other within the session. In the bi-directional mode, the network ports cannot communicate with each other. Network ports of a unidirectional port mapping session can be shared with other unidirectional sessions, but cannot be shared with any sessions configured in the bi-directional mode. Network ports of different sessions can communicate with each other. Port Mapping Specifications: Ports Supported: Ethernet (10 Mbps)/Fast Ethernet (100 Mbps)/Gigabit Ethernet (1 Gb/1000 Mbps) /10 Gigabit Ethernet (10 Gb/10000 Mbps). Mapping Sessions: Eight sessions supported per standalone switch and stack. Port Mapping Defaults: Mapping Session: Creation: No mapping sessions Mapping Status configuration: Disabled Port Mapping Direction: Bi-directional

5. 6.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 246 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Access Control Lists (ACLs) Performance: Wire-speed ACLs are sometimes referred to as filtering lists.

Access Control Lists are Quality of Service policies used to control whether or not packets are allowed or denied at the switch or router interface. ACLs are distinguished by the kind of traffic they filter. In a QoS policy rule, the type of traffic is specified in the policy condition. The policy action determines whether the traffic is allowed or denied. In general, the types of ACLs include: Layer 2 ACLsfor filtering traffic at the MAC layer. Usually uses MAC addresses or MAC groups for filtering. Layer 2 filtering filters traffic at the MAC layer. Layer 2 filtering may be done for both bridged and routed packets. As MAC addresses are learned on the switch, QoS classifies the traffic based on: MAC address or MAC group Source VLAN Physical slot/port or port group The switch classifies the MAC address as both source and destination. Layer 3/4 ACLsfor filtering traffic at the network layer. Typically uses IP addresses or IP ports for filtering. The QoS software in the switch filters routed and bridged traffic at Layer 3. For Layer 3/4 filtering, the QoS software in the switch classifies traffic based on: Source IP address or source network group Destination IP address or destination network group IP protocol (note IPX filtering is not supported.) Source TCP/UDP port Destination TCP/UDP port or service or service group Destination slot/port or destination port group Multicast ACLsfor filtering IGMP traffic Multicast filtering may be set up to filter clients requesting group membership via the Internet Group Management Protocol (IGMP). IGMP is used to track multicast group membership. The IP Multicast Switching (IPMS) function in the switch optimizes the delivery of IP multicast traffic by sending packets only to those stations that request it. Potential multicast group members may be filtered out so that IPMS does not send multicast packets to those stations. Multicast traffic has its own global disposition. By default, the global disposition is accept. For multicast filtering, the switch classifies traffic based on the multicast IP address or multicast network group and any destination parameters. ACL Specifications: Maximum number of policy rules: 1024 Maximum number of policy rules per Ethernet port: 101 Maximum number of policy rules per 10-Gigabit Ethernet port: 997 Maximum number of policy conditions: 2048 Maximum number of policy actions: 2048 Maximum number of policy services: 256 Maximum number of groups (Network, MAC, service, port): 1024 Maximum number of group entries: 512 per group The following additional ACL features are available for improving network security and preventing malicious activity on the network: UserPortsA port group that identifies its members as user ports to prevent spoofed IP traffic. When a port is configured as a member of this group, packets received on the port are dropped if they Contain a source IP network address that does not match the IP subnet for the port. DropServicesA service group that improves the performance of ACLs that are intended to deny packets destined for specific TCP/UDP ports. Using the DropServices group for this function minimizes processing overhead, which otherwise could lead to a DoS condition for other applications trying to use the switch. ICMP drop rulesAllows condition combinations in policies that will prevent user pings, Thus reducing DoS exposure from pings. Two condition parameters are also available to provide more granular filtering of ICMP packets: icmptype and icmpcode. See Configuring ICMP Drop Rules in the network configuration Guide. BPDUShutdownPorts (Close user ports upon receipt of BPDU)A port group that identifies its members as ports that should not receive BPDUs. If a BPDU is received on one of these ports, The port is administratively disabled. In other words, this allows network administrators to prevent the connection of devices that can support bridging functionality to ports designated as user ports. TCP connection rulesAllows the determination of an established TCP connection by examining TCP flags found in the TCP header of the packet. Two condition parameters are available for defining a TCP connection ACL: established and tcpflags. Early ARP discardARP packets destined for other hosts are discarded to reduce processing overhead and exposure to ARP DoS attacks. No configuration is required to use this feature; It is always available and active on the switch. Note that ARPs intended for use by a local subnet, AVLAN, VRRP, and Local Proxy ARP are not discarded.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 247 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

BPDU Shutdown Ports BPDUShutdownPortsA port group that identifies its members as ports that should not receive BPDUs. If a BPDU is received on one of these ports, the port is administratively disabled.

Access Control Lists (ACLs) for IPv6

ACL & Layer 3 Security

The BPDUShutdownPorts group is a special QoS port group that identifies its members as ports that should not receive BPDUs. If a BPDU is received on one of these ports, the port is administratively disabled. Note that the BPDUShutdownPorts group is not supported on the OmniSwitch 6850 Series or the OmniSwitch 9000 Series. On these switches, it is possible to configure a global UserPorts profile, as described in ACL & Layer 3 Security, to monitor BPDU on user ports. Such a profile also determines whether user ports will filter BPDU or will administratively shutdown when BPDU are received on the port. Note that this functionality only applies to ports that are designated as members of the UserPorts port group. A port configured to administratively shutdown when BPDU are detected will generate an inferior BPDU every 5 seconds. This will prevent loops in the network if two BPDU shutdown ports are accidentally bridged together either through an external loop or through a hub, since both ports would be receiving inferior BPDUs. Support for IPv6 ACLs on the OmniSwitch 6850 Series and OmniSwitch 9000 Series is available. The following QoS policy conditions are now available for configuring ACLs to filter IPv6 traffic: source ipv6 destination ipv6 ipv6 nh (next header) flow-label source tcp port destination tcp port source udp port destination udp port Note the following when using IPv6 ACLs: Trusted/untrusted behavior is the same for IPv6 traffic as it is for IPv4 traffic. IPv6 policies do not support the use of network groups, service groups, map groups, or MAC groups. IPv6 multicast policies are not supported. Anti-spoofing and other UserPorts profiles/filters do not support IPv6. The default (built-in) network group, Switch, only applies to IPv4 interfaces. There is no such group for IPv6 interfaces. Note. IPv6 ACLs are not supported on A1 NI modules. Use the show ni command to verify the version of the NI module. Contact your Alcatel-Lucent support representative if you are using A1 boards. The following additional ACL features are available for improving network security and preventing malicious activity on the network: ICMP drop rulesAllows condition combinations in policies that will prevent user pings, thus reducing DoS exposure from pings. Two condition parameters are also available to provide more granular filtering of ICMP packets: icmptype and icmpcode. TCP connection rulesAllows the determination of an established TCP connection by examining TCP flags found in the TCP header of the packet. Two condition parameters are available for defining a TCP connection ACL: established and tcpflags. Early ARP discardARP packets destined for other hosts are discarded to reduce processing overhead and exposure to ARP DoS attacks. No configuration is required to use this feature, it is always available and active on the switch. Note that ARPs intended for use by a local subnet, AVLAN, and VRRP are not discarded. UserPortsA port group that identifies its members as user ports to prevent spoofed IP traffic. When a port is configured as a member of this group, packets received on the port are dropped if they contain a source IP network address that does not match the IP subnet for the port. UserPorts ProfileIn addition to spoofed traffic, it is also possible to configure a global UserPorts profile to specify additional types of traffic, such as BPDU, RIP, OSPF, and/or BGP, to monitor on user ports. The UserPorts profile also determines whether user ports will filter the unwanted traffic or will administratively shutdown when the traffic is received. Note that this profile only applies to those ports that are designated as members of the UserPorts port group. DropServicesA service group that improves the performance of ACLs that are intended to deny packets destined for specific TCP/UDP ports. This group only applies to ports that are members of the UserPorts group. Using the DropServices group for this function minimizes processing overhead, which otherwise could lead to a DoS condition for other applications trying to use the switch.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 248 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Access Control List Manager (ACLMAN)

Access Control List Manager (ACLMAN) is a function of the Quality of Service (QoS) application that provides an interactive shell for using common industry syntax to create ACLs. Commands entered using the ACLMAN shell are interpreted and converted to Alcatel-Lucent CLI syntax that is used for creating QoS filtering policies. This implementation of ACLMAN also provides the following features: Importing of text files that contain common industry ACL syntax Support for both standard and extended ACLs Creating ACLs on a single command line The ability to assign a name, instead of a number, to an ACL or a group of ACL entries Sequence numbers for named ACL statements Modifying specific ACL entries without having to enter the entire ACL each time to make a change The ability to add and display ACL comments ACL logging extensions to display Layer 2 through 4 packet information associated with an ACL ACLMAN Overview: ACLMAN is a function of the Alcatel-Lucent QoS system that allows network administrators to configure and manage ACLs using common industry syntax. ACLs configured using ACLMAN are transparently converted into Alcatel-Lucent QoS filtering policies and applied to the switch. An ACLMAN interactive shell provides an ACL command line interface that is similar to command interfaces that are available on other industry platforms. This shell serves as a configuration tool for creating ACLs using common industry syntax commands and/or importing industry syntax from text files. The following industry ACL types and features are supported with this implementation of ACLMAN: Standard ACL. This type of ACL compares the source address of a packet to the source address specified in the ACL. Extended ACL. This type of ACL compares the source and destination address of a packet to the source and destination address specified in the ACL. Also provides additional criteria for filtering packets. Numbered ACL. This type of ACL refers to standard or extended ACLs that are assigned a number for identification. Named ACL. This type of ACL refers to standard or extended ACLs that are assigned a name for identification. The following industry ACL types are currently not supported: Reflexive ACLs Context-Based Access Control Authentication Proxy Lock and Key (Dynamic ACLs) ACMAN Defaults: ACLMAN Defaults: ACL Disposition: Deny Logging rate time interval: 30 seconds

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 249 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Network Admission (Access) Control (aka NAC): Security Outline: - Of the switch - To the switch - Through the switch (NAC) - Proactive (Access Guardian) - Authentication - Client integrity - ACL and firewall policies - Reactive (Quarantine Manager) - Monitoring - Intrusion detection - Quarantining

Protecting the enterprise network takes more than just focusing on specific threats and adding specialized appliances. To defend against todays threats, the focus has changed from securing the perimeter to a pervasive layered, network-wide strategy where security functions are now embedded in the switches, providing a proactive, network defense. To meet this challenge Alcatel-Lucent has identified and implemented security services at every switch port making the network infrastructure an integral part of the security solution. With Alcatel-Lucents Network Access Control (NAC) technology, every port is capable of immediately detecting and neutralizing network attacks without sacrificing manageability, mobility, availability, or performance. Alcatel-Lucents LAN switches have embedded security features that not only respond to AlcatelLucent security applications, but also interoperate with standards-based security systems from the industries leading security software and security appliance vendors. Alcatel-Lucents NAC solution combines several services including: port control (Alcatel-Lucent Access Guardian), user policy violations (Alcatel-Lucent OmniVista 2770 Quarantine Manager) and the ability to monitor user end points (Client Integrity Checking) Alcatel-Lucent has three main approaches to security: securing the infrastructure itself, securing the access to the infrastructure, and securing the access provided by the infrastructure. Securing access provided by the switch, also knows as Network Access Control (NAC) relies on the combination of various security features embedded in our switches and enabled by partnerships with leading security software and security appliance vendors. These features utilize proactive processes that identify and authenticate the users, provide means of enforcing device policies and determine what resources the end user may access. These methods together are known as Alcatel-Lucent Access Guardian. To identify and authenticate users and devices, Alcatel-Lucent has implemented a powerful and flexible authentication mechanism that combines well-known authentication methods such as 802.1x and MAC authentication with unique classification methods. The network automatically senses the authentication method a device uses and adapts to provide the appropriate access to the resources a user needs. As part of this process, Alcatel-Lucent's network also interoperates with client-based security software to verify the compliance of a device. In addition to proactive methods, the Alcatel-Lucent Quarantine Manager makes use of reactive methods to monitor, detect intrusions, and quarantine end user devices. It interoperates with a wide range of security appliances to provide comprehensive enforcement of quarantining policies at the very edge of the network.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 250 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Distributed Intelligence
The AOS OmniSwitch product family has been designed to bring intelligence to an Enterprise network by implementing a host of intelligent features and services. Carrier-class intelligence insures that users and applications receive the priority and performance they need with ease-of-use management that extends across the entire enterprise. The OS6850 provides the necessary hardware queues, intelligence and granularity to properly identify, mark and prioritize data flows ensuring mission critical applications running smoothly. The following is only a highlight of the state-of-the-art intelligent features supported by the OmniSwitch 6850 Series: VLAN Support: o Up to 4,094 VLANs (1024 VLANs recommended), and 4,094 VLAN tags value support o Per port, 802.1Q and policy based VLAN including authentication VLAN (A-VLAN) Residential bridging features: DHCP option-82, DHCP-Snooping and Port Mapping Triple Play features: Rapid Spanning Tree, IP Multicast VLANs, Mac Retention, Eth. Operations Admin. & Maintenance (OAM), IS-IS and GVRP Quality of Service o IEEE 802.1p, ToS, DSCP marking o QoS mapping: 802.1p to 802.1p & ToS & DSCP, ToS to ToS & 802.1p & DSCP, DSCP to DSCP & 802.1p & ToS o Classification per port, 802.1p (CoS) value, MAC SA/DA, TOS precedence, DSCP value, IP SA/DA, TCP/UDP port range o 8 egress queues per port to support strict and hybrid queuing (strict + weighted round robin queuing algorithm). o Ingress bandwidth rate limiting per port/flow in 64k increments o Egress bandwidth rate limiting per port in 1Mbps increments Routing Protocols: IPv4 & IPv6, RIPv1/v2 & OSPF & OSPF-ECMP & BGP & VRRP & PIM-SMv2 & & PIM-SSM & DVMRPv3 VLANs One of the main benefits of using VLANs to segment network traffic, is that VLAN configuration and port assignment is handled through switch software. This eliminates the need to physically change a network device connection or location when adding or removing devices from the VLAN broadcast domain. The VLAN management software handles the following VLAN configuration tasks: Creating or modifying VLANs. Assigning or changing default VLAN port associations (VPAs). Enabling or disabling VLAN participation in the current Spanning Tree algorithm. Enabling or disabling classification of mobile port traffic by 802.1Q tagged VLAN ID. Enabling or disabling VLAN authentication. Defining VLAN IPX router interfaces to enable routing of VLAN IPX traffic. Enabling or disabling unique MAC address assignments for each router VLAN defined. Displaying VLAN configuration information. Up to 4094 VLANs for Flat Spanning Tree mode and 252 VLANs for 1x1 Spanning Tree mode are supported. In addition, it is also possible to specify a range of VLAN IDs when creating or deleting VLANs and/or configuring VLAN parameters, such as Spanning Tree bridge values. In a flat-bridged network, a broadcast domain is confined to a single LAN segment or even a specific physical location, such as a department or building floor. In a switch-based network, such as one comprised of Alcatel-Lucent switching systems, a broadcast domainor VLAN can span multiple physical switches and can include ports from a variety of media types. For example, a single VLAN could span three different switches located in different buildings and include 10/100 Ethernet, Gigabit Ethernet, 802.1q tagged ports and/or a link aggregate of ports. Initially all switch ports are non-mobile and are assigned to VLAN 1. When additional VLANs are created on the switch, ports are assigned to the VLANs so that traffic from devices connected to these ports is bridged within the VLAN domain. Switch ports are either statically or dynamically assigned to VLANs. Static port assignment applies to both mobile and non-mobile (fixed) ports. Fixed ports are also statically assigned to secondary VLANs by defining 802.1Q tagged VLANs for the port. In addition, ports can belong to a link aggregate of ports. Dynamic assignment applies only to mobile ports and requires the additional configuration of VLAN rules. When traffic is received on a mobile port, the packets are examined to determine if their content matches any VLAN rules configured on the switch. Rules are defined by specifying a port, MAC address, protocol, network address, binding, or DHCP criteria to capture certain types of network device traffic. It is also possible to define multiple rules for the same VLAN. A mobile port is assigned to a VLAN if its traffic matches any one VLAN rule. VLAN Specifications: RFCs supported: 2674 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions. IEEE Standards supported: 802.1Q and 802.1D Maximum VLANs: 1024 (including VLAN#1) Maximum VLAN port associations: 32,768 Maximum IP router port VLANs: 1024 Maximum IPX router port VLANs: 1024 Maximum Spanning Tree VLANs: 253 Maximum Authenticated VLANs: 128 Maximum Router Mode Supported: Single The following provides a list of various types of VLAN rules supported. Rule Types: DHCP

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 251 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Rule Precedence

Default VLAN Secondary VLANs

Dynamic VLAN Assignment (Mobility)

Automatic VLAN Containment (AVC)

VLAN Range Support

o DHCP MAC & DHCP MAC Range o DHCP Port o DHCP Generic Binding o MAC + IP+ Port o MAC + Port o Port + Protocol MAC o MAC address & MAC Address Range Mobile Tag Network address o IP (IP Subnet) & IPX (IPX Network) Protocol [including IP, IPv6, ARP, RARP, IPX (0x8137, 0xFFFF, 0xE0E0), AppleTalk (0x809b, 0x80F3) and DECNet] Port DHCP Mac & DHCP Mac Range DHCP Port DHCP Generic Mac-Port-IP Binding Mac-Port Binding Port-Protocol Binding Mac & Mac Range IP Subnet IPX Network Protocol (Group Mobility classifies IPv6 frames) Every switch port, mobile or non-mobile, has a configured default VLAN. Initially, this is VLAN 1 for all ports, but is configurable using the vlan port default command. All mobile ports start out with a configured default VLAN assignment. When mobile port traffic matches VLAN criteria, the port is assigned to that VLAN. Secondary VLANs are any VLAN a port is subsequently assigned to that is not the configured default VLAN for that port. A mobile port can obtain more than one secondary VLAN assignment under the following conditions: Mobile port receives untagged frames that contain information that matches rules on more than one VLAN. For example, if a mobile port receives IP and IPX frames and their is an IP protocol rule on VLAN 10 and an IPX protocol rule on VLAN 20, the mobile port is dynamically assigned to both VLANs. VLANs 10 and 20 become secondary VLAN assignments for the mobile port. Mobile port receives 802.1Q tagged frames that contain a VLAN ID that matches a VLAN that has VLAN mobile tagging enabled. For example, if a mobile port receives frames tagged for VLAN 10, 20 and 30 and these VLANs have mobile tagging enabled, the mobile port is dynamically assigned to all three VLANs. VLANs 10, 20, and 30 become secondary VLAN assignments for the mobile port. Dynamic assignment applies only to mobile ports and requires the additional configuration of VLAN rules. When traffic is received on a mobile port, the packets are examined to determine if their content matches any VLAN rules configured on the switch. Rules are defined by specifying a port, MAC address, protocol, network address, binding, or DHCP criteria to capture certain types of network device traffic. It is also possible to define multiple rules for the same VLAN. A mobile port is assigned to a VLAN if its traffic matches any one VLAN rule. When enabled, AVC prevents a port that has no VLANs mapped to an 802.1S Multiple Spanning Tree Instance (MSTI) from becoming the root port for that instance. Such ports are automatically assigned an infinite path cost value to make them an inferior choice for root port. In an 802.1s Multiple Spanning Tree (MST) configuration, it is possible for a port that belongs to a VLAN, which is not a member of an instance, to become the root port for that instance. This can cause a topology change that could lead to a loss of connectivity between VLANs/switches. Enabling Automatic VLAN Containment (AVC) helps to prevent this from happening by making such a port an undesirable choice for the root. When AVC is enabled, it identifies undesirable ports and automatically configures them with an infinite path cost value. Balancing VLANs across links according to their Multiple Spanning Tree Instance (MSTI) grouping is highly recommended to ensure that there is not a loss of connectivity during any possible topology changes. Enabling AVC on the switch is another way to prevent undesirable ports from becoming the root for an MSTI. Up to 4094 VLANs for Flat Spanning Tree mode and 252 VLANs for 1x1 Spanning Tree mode are supported. In addition, it is now possible to specify a range of VLAN IDs when creating or deleting VLANs and/or configuring VLAN parameters, such as Spanning Tree bridge values.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 252 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IP Virtual Router Port

MAC Router Mode Single MAC Router Mode ONLY

IEEE 802.1Q

802.1Q 2005 (MSTP)

A VLAN is available for routing traffic when a virtual router port is defined for that VLAN and at least one active port has joined the VLAN. If a VLAN does not have a router defined, its ports are in essence fire walled from other VLANs. Each VLAN supports one IP virtual router port and a maximum of 1024 IP router port VLANs are allowed per switch. The OmniSwitch 6850 operates only in single MAC router mode. In this mode, each router port VLAN is assigned the same MAC address, which is the base chassis MAC address for the switch. As a result, up to 1024 IP router port VLANs are supported per single switch. This also eliminates the need to allocate additional MAC addresses if more than 32 router port VLANs are defined. Alcatel-Lucents 802.1Q is an IEEE standard for sending frames through the network tagged with VLAN identification. 802.1Q tagging can be configured and monitored on a single port in a switch or a link aggregation group in a switch. 802.1Q tagging is the IEEE version of VLANs. It is a method for segregating areas of a network into distinct VLANs. By attaching a label, or tag, to a packet, the packet can be identified as being from a specific area or identified as being destined for a specific area. When a port is enabled to accept tagged traffic, by default both 802.1Q tagged and untagged traffic is automatically accepted on the port. Configuring the port to accept only tagged traffic is also supported. When enabling a tagged port, you will also need to specify whether only 802.1Q tagged traffic is allowed on the port, or whether the port accepts both tagged and untagged traffic. Tagged refers to four bytes of reserved space in the header of the packet. The four bytes of tagging are broken down as follows: the first two bytes indicate whether the packet is an 802.1Q packet, and the next two bytes carry the VLAN identification (VID) and priority. On the ingress side, packets are classified in a VLAN. After classifying a packet, the switch adds an 802.1Q header to the packet. Egress processing of packets is done by the switch hardware. Packets have an 802.1Q tag, which may be stripped off based on 802.1Q tagging/stripping rules. If a port is configured to be a tagged port, then all the untagged traffic (including priority tagged, or VLAN 0 traffic) received on the port will be dropped. You do not need to reboot the switch after changing the configuration parameters. Priority tagged traffic, or traffic from VLAN 0, is used for Quality of Service (QoS) functionality. 802.1Q views priority tagged traffic as untagged traffic. Mobile ports can be configured to accept 802.1Q traffic by enabling the VLAN mobile tagging feature. The port can be assigned to as many 802.1Q VLANs as necessary, up to 4093 per port or 32768 VLAN port associations. For the purposes of Quality of Service (QoS), 802.1Q ports are always considered to be trusted ports. 802.1Q tagging is done at wire speed, providing high-performance throughput of tagged frames. IEEE 802.1Q Specifications: IEEE Specification: Draft Standard P802.1Q/D11 IEEE Standards for Local And Metropolitan Area Network: Virtual Bridged Local Area Networks, July 30, 1998 Maximum Number of Tagged VLANs per Port: 4093 Maximum Number of Untagged VLANs per Port: one untagged VLAN per port Maximum Number of VLAN Port Associations: 32768 What type of frames accepted: Both tagged and untagged frames are accepted IEEE 802.1Q 2005 (Q2005) is a new version of Multiple Spanning Tree Protocol (MSTP) that is a combination of the 802.1D 2004 and 802.1S protocols. This implementation of Q2005 also includes improvements to edge port configuration and provides administrative control to restrict port role assignment and the propagation of topology change information through bridge ports.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 253 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VLAN Stacking and Translation

VLAN Stacking provides a mechanism to tunnel multiple customer VLANs (CVLAN) through a service provider network using one or more service provider VLANs (SVLAN) by way of 802.1Q double-tagging or VLAN Translation. This feature enables service providers to offer their customers Transparent LAN Services (TLS). This service is multipoint in nature so as to support multiple customer sites or networks distributed over the edges of a service provider network. The VLAN Stacking application operates in one of two modes: legacy and service. The two modes basically differ in how VLAN Stacking is configured, with the service mode offering the following additional enhancements that are not available in the legacy mode: Ethernet service-based approach that is similar to configuring a virtual private LAN service (VPLS). Ingress bandwidth sharing across User Network Interface (UNI) ports. Ingress bandwidth rate limiting on a per UNI port, per CVLAN, or CVLAN per UNI port basis. CVLAN (inner) tag 802.1p-bit mapping to SVLAN (outer) tag 802.1p bit. CVLAN (inner) tag DSCP mapping to SVLAN (outer) tag 802.1p bit. Profiles for saving and applying traffic engineering parameter values. Configuring VLAN Stacking in the legacy mode consists of using a port or port-VLAN level approach to tunneling customer traffic. Configuring VLAN Stacking in the service mode consists of using an approach based on defining an Ethernet service to tunnel customer traffic. Both modes are exclusive in that the switch can only operate in one mode or the other. In addition, each mode has its own unique CLI command syntax. Throughout this section, the term port-based VLAN Stacking refers to functionality available in the legacy mode and the term service-based VLAN Stacking refers to functionality available in the service mode. Note. You can also configure and monitor VLAN Stacking with WebView; Alcatel.Lucents embedded web based device management application. WebView is an interactive and easy-to-use GUI that can be launched from OmniVista or a web browser. VLAN Stacking Specifications IEEE Standards Supported: IEEE 802.1Q, 2003 Edition, IEEE Standards for Local and metropolitan area networksVirtual Bridged Local Area Networks P802.1ad/D6.0 (C/LM) Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 4: Provider Bridges Maximum number of SVLANs for port-based VLAN Stacking: Port level VLAN Stacking-4093 (VLAN 2 through 4094) port/VLAN level VLAN Stacking: 768 (VLAN 2 through 4094 inclusive) Maximum number of SVLANs for service-based VLAN Stacking: 4093 (VLAN 2 through 4094) Features not supported on VLAN Stacking ports : Group Mobility, Authentication and L3 Routing Service-Based VLAN Stacking Defaults VLAN Stacking mode: legacy VLAN Stacking (vstk) SVLAN administrative and Spanning Tree status: Enabled IPMVLAN administrative and Spanning Tree status: Enabled Vendor TPID and legacy BPDU support for STP or GVRP on a VLAN Stacking network port: Legacy STP BPDU = dropped. Legacy GVRP BPDU = dropped. Acceptable frame types on a VLAN Stacking user port: None Traffic engineering profile attributes for a VLAN Stacking Service Access Point (SAP): ingress bandwidth = shared ingress bandwidth bps = 0 CVLAN tag is preserved. SVLAN priority mapping = 0 Treatment of customer STP and GVRP frames ingressing on a VLAN Stacking user port: STP frames are tunneled. GVRP frames are tunneled. Port-Based VLAN Stacking Defaults VLAN Stacking mode: legacy VLAN Stacking (vstk) Carries customer or provider traffic: Customer Traffic SVLAN administrative Status: Enabled Internal prioritization value and egress shaping for the SVLAN: 0 Vlan Stacking port type: User-customer-port Vendor TPID for VLAN Stacking network port: 0x88a8 Treatment of customer STP and GVRP frames ingressing on VLAN Stacking user-customer and userprovider ports: Flooded Acceptable frame types on user-customer and user-provider ports:Tagged and untagged Treatment of tagged packets upon an SVLAN lookup miss: Drop Legacy BPDU support for STP or GVRP on VLAN Stacking network ports Binding mode of VLAN Stacking port to an SVLAN: Double-tag

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 254 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VLAN Stacking Overview

VLAN Stacking provides a mechanism for defining a transparent bridging configuration through a service provider network. This type of configuration is achieved using one of two methods: servicebased VLAN Stacking or port-based VLAN Stacking. The service-based approach provides the ability to configure Ethernet services to provide VLAN Stacking functionality. The port-based approach requires configuring VLAN Stacking functionality on a port level or port-VLAN level. See VLAN Stacking Modes on page 7-8 for more information. The major components of VLAN Stacking that provide this type of functionality are described as follows: Provider Edge (PE) BridgeAn Ethernet switch that resides on the edge of the service provider network. The PE Bridge interconnects customer network space with service provider network space. A switch is considered a PE bridge if it transports packets between a customer-facing port and a network port or between two customer-facing ports. Transit BridgeAn Ethernet switch that resides inside the service provider network and provides a connection between multiple provider networks. It employs the same SVLAN on two or more network ports. This SVLAN does not terminate on the switch itself; traffic ingressing on a network port is switched to other network ports. It is also possible for the same switch to function as a both a PE Bridge and a Transit Bridge. Tunnel (SVLAN)A tunnel, also referred to as an SVLAN, is a logical entity that connects customer networks by transparently bridging customer traffic through a service provider network. The tunnel is defined by an SVLAN tag that is appended to all customer traffic. This implementation provides the following three types of SVLANs, which are both defined by the type of traffic that they carry: an SVLAN that carries customer traffic an SVLAN that carries provider management traffic an IP Multicast VLAN (IPMVLAN) that distributes multicast traffic Note that port-based VLAN Stacking does not support two or more customers sharing the same tunnel Network Network Interface (NNI)An NNI is a port that resides on either a PE Bridge or a Transit Bridge and connects to a service provider network. Traffic ingressing on a network port is considered SVLAN traffic and is switched to a customer-facing port or to another network port. User Network Interface (UNI)A UNI is a port that resides on a PE bridge that connects to a customer network and carries customer traffic. The UNI may consist of a single port or an aggregate of ports and can accept tagged or untagged traffic. Note that port-based VLAN Stacking provides two types of UNI ports: user-customer port and userprovider port. A user-customer port connects to a customer network and carries customer traffic; a user-provider port carries provider management traffic.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 255 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IPv4 Routing

IPv6 Routing

IP Route Map Redistribution

Internet Protocol (IP) is a network-layer (Layer 3) protocol that contains addressing and control information that allow packets to be forwarded on a network. IP is the primary network-layer protocol in the Internet protocol suite. Along with the Transmission Control Protocol (TCP), IP represents the heart of the Internet protocols. IP is associated with several Layer 3 and Layer 4 protocols. These protocols are built into the base code loaded on the switch and they include: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) Bootstrap Protocol (BOOTP)/Dynamic Host Configuration Protocol (DHCP) Simple Network Management Protocol (SNMP) Telnet and File Transfer Protocol (FTP) Address Resolution Protocol (ARP) Internet Control Message Protocol (ICMP) RIPv1 & RIPv2 and Static Routes The base IP software allows one to configure an IP router port, static routes, a default route, the Address Resolution Protocol (ARP), the router primary address, the router ID, the Time-to-Live (TTL) Value, IP-directed broadcasts, and the Internet Control Message Protocol (ICMP). In addition, this software allows one to trace IP route, display Transmission Control Protocol (TCP) information, and display User Data-gram Protocol (UDP) information. OmniSwitch 6850/OS9000 supports hardware routing/flooding to static arp with multicast MAC address. Note. The switch operates only in single MAC router mode. In this mode, each router VLAN is assigned the same MAC address, which is the base chassis MAC address for the switch. IPv6 (documented in RFC 2460) is designed as a successor to IPv4 and is supported on the OmniSwitch 6850 and 9000. The changes from IPv4 to IPv6 fall primarily into the following categories: Address size increased from 32 bits (IPv4) to 128 bits (IPv6) Dual Stack IPv4/IPv6 ICMPv6 Neighbor Discovery Stateless Auto-configuration OSPFv3 RIPng Static Routes Tunneling: Configured and 6-to-4 dynamic tunneling Ping, trace-route DNS client using Authority records Telnetv6 - Client and server File Transfer Protocol (FTPv6) Client and server SSHv6 Client and Server OmniSwitch 6850 and 9000 switches support hardware-based IPv6 routing. Note. The switch operates only in single MAC router mode. In this mode, each router VLAN is assigned the same MAC address, which is the base chassis MAC address for the switch Route map redistribution provides the ability to control which routes from a source protocol are learned and distributed into the network of a destination protocol. A route map consists of one or more user-defined statements that can determine which routes are allowed or denied access to the network. In addition, a route map may also contain statements that modify route parameters before they are redistributed. Redistribution is configured by specifying a source and destination protocol and the name of an existing route map. Criteria specified in the route map are applied to routes received from the source protocol.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 256 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Tunneling

Generic Routing Encapsulation (GRE)

IP Encapsulation within IP (aka IPIP or IP-IP or IP/IP Tunneling)

Routing Protocols

Tunneling is a mechanism that can encapsulate a wide variety of protocol packet types and route them through the configured tunnels. Tunneling is used to create a virtual point-to-point link between routers at remote points in a network. This feature supports the creation, administration, and deletion of IP interfaces whose underlying virtual device is a tunnel. The Alcatel-Lucent implementation provides support for two tunneling protocols: Generic Routing Encapsulation (GRE) and IP encapsulation within IP (IPIP). Note. The tunneling feature is supported by OmniSwitch 6850 and OmniSwitch 9000. Generic Routing Encapsulation (GRE) is a tunneling protocol that can encapsulate a wide variety of protocol packet types inside IP tunnels. GRE is used to create a virtual point-to-point link between routers at remote points in a network. This feature supports the creation, administration, and deletion of IP interfaces whose underlying virtual device is a GRE tunnel. Generic Routing Encapsulation overview GRE encapsulates a packet that needs to be carried over the GRE tunnel with a GRE header. The resulting packet is then encapsulated with an outer header by the delivery protocol and forwarded to the other end of the GRE tunnel. The destination IP address field in the outer header of the GRE packet contains the IP address of the router at the remote end of the tunnel. The router at the receiving end of the GRE tunnel extracts the original payload and routes it to the destination address specified in the payloads IP header. Consider the following when configuring the GRE tunnel interfaces: A switch can support up to 8 GRE tunnel interfaces. The features such as Multinetting, Egress ACL, NAT, QoS, and VRRP are not supported on the GRE tunnel interfaces. IPIP tunneling is a method by which an IP packet is encapsulated within another IP packet. The Source Address and Destination Address of the outer IP header identifies the endpoints of tunnel. Whereas Source Address and Destination Address of the inner IP header identifies the original sender and recipient of the packet, respectively. The IP/IP tunneling feature allows IP traffic to be tunneled through an IP network. This feature can be used to establish connectivity between remote IP networks using an intermediate IP network such as the Internet. Consider the following when configuring the IPIP tunnel interfaces: A switch can support up to 127 IPIP tunnel interfaces. IPIP tunnel interfaces are included in the maximum number of IP interfaces that are supported on the switch. IP is a network-layer (Layer 3) protocol that contains addressing information and some control information that enables packets to be forwarded. IP is documented in RFC 791 and is the primary network-layer protocol in the Internet protocol suite. Along with the Transmission Control Protocol (TCP), IP represents the heart of the Internet protocols. IP is enabled on the switch by default. Static IP Routing is supported. Dynamic IP Routing support: VRRPv2&v3, RIPv1, RIPv2, and OSPFv2&v3 Router Discover Protocol (RDP): The Router Discovery Protocol (RDP) is an extension of ICMP that allows end hosts to discover routers on their networks. This implementation of RDP supports the router requirements as defined in RFC 1256. L3 Routing Protocols (IPv4) IP Routing Static routing RIP v1 & v2 OSPF v2 BGP v4 Multicast IGMP v1, v2 & v3 snooping PIM-SM PIM-DM DVMRP Network Protocol TCP/IP stack ARP DHCP relay Generic UDP relay per VLAN Resilience VRRP v2 L3 Routing Protocols (IPv6) IP Routing Static routing RIPng OSPF v3 Multicast MLD snooping

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 257 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Routed Protocols Routing Protocol Preference

Internet Protocol (IP) support

31-Bit Network Mask Support

PIM-SM PIM-DM Network Protocol TCP/IP stack DHCP relay (including generic UDP relay) ARP Resilience VRRPv3 Layer-3 Routing (IPX) IPX Routing Static routing RIP/SAP Examples of Routed protocols which is supported in OmniSwitch-6850: TCP/UDP, Telnet, and FTP OmniSwitch 6850 switches support provide configurable weight for each routing protocol (including static routes) to control which entry to prefer when two entries exist from different sources. By default, local routes always have precedence. In the CLI use the ip route-pref command to configure the routing preference. Internet Protocol (IP) is primarily a network-layer (Layer 3) protocol that contains addressing and control information that enables packets to be forwarded. Along with Transmission Control Protocol (TCP), IP represents the heart of the Internet protocols. IP has two primary responsibilities: providing connection-less, best-effort delivery of Datagrams through an Internetwork; and providing fragmentation and reassembly of Datagrams to support data links with different Maximum Transmission Unit (MTU) sizes. IP is enabled on the switch by default and there are few options that can, or need to be, configured. Note. IP routing (Layer 3) can be accomplished by using static routes or by using one of the IP routing protocols such as Routing Information Protocol (RIP), or Open Shortest Path First (OSPFv2). There are two versions of Internet Protocol supported, IPv4 and IPv6. IP Specifications: RFCs Supported RFC 791Internet Protocol RFC 792Internet Control Message Protocol RFC 826An Ethernet Address Resolution Protocol 2784Generic Routing Encapsulation (GRE) 2890Key and Sequence Number Extensions to GRE (extensions defined are not supported) 1701Generic Routing Encapsulation (GRE) 1702Generic Routing Encapsulation over IPV4 Networks 2003-IP Encapsulation within IP. Maximum VLANs per switch: 4094 (including default VLAN 1) Maximum router VLANs per switch: 4094 IP and 256 IPX (single MAC router mode) Maximum IP interfaces per VLAN: 8 Maximum number of GRE tunnel interfaces:8 Maximum IP interfaces per switch: 4096 Maximum number of IPIP tunnel interfaces: 127 Routing protocols supported over the tunnel Interfaces: RIP, OSPF, and BGP Maximum ARP filters per switch :200 IP Forwarding: IP is enabled by default. Using IP, devices connected to ports on the same VLAN are able to communicate. However, to forward packets to a different VLAN, you must create a router port on each VLAN. Adds support for a 31-bit net mask to allow for a point-to-point Ethernet network between two routers.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 258 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Internet Protocol (IPv6) support

Internet Protocol version 6 (IPv6) is the next generation of Internet Protocol version 4 (IPv4). Both versions are supported along with the ability to tunnel IPv6 traffic over IPv4. Implementing IPv6 solves the limited address problem currently facing IPv4, which provides a 32-bit address space. IPv6 increases the address space available to 128 bits. IPv6 Overview: IPv6 provides the basic functionality that is offered with IPv4 but includes the following enhancements and features not available with IPv4: Increased IP address sizeIPv6 uses a 128-bit address, a substantial increase over the 32-bit IPv4 address size. Providing a larger address size also significantly increases the address space available, thus eliminating the concern over running out of IP addresses. Auto-configuration of addressesWhen an IPv6 interface is created or a device is connected to the switch, an IPv6 link-local address is automatically assigned for the interface and/or device. Anycast addressesA new type of address. Packets sent to an Anycast address are delivered to one member of the Anycast group. Simplified header formatA simpler IPv6 header format is used to keep the processing and bandwidth cost of IPv6 packets as low as possible. As a result, the IPv6 header is only twice the size of the IPv4 header despite the significant increase in address size. Improved support for header optionsImproved header option encoding allows more efficient forwarding, fewer restrictions on the length of options, and greater flexibility to introduce new options. Security improvementsExtension definitions provide support for authentication, data integrity, and confidentiality. Neighbor Discovery protocolA protocol defined for IPv6 that detects neighboring devices on the same link and the availability of those devices. Additional information that is useful for facilitating the interaction between devices on the same link is also detected (e.g., neighboring address prefixes, address resolution, duplicate address detection, link MTU, and hop limit values, etc.). This implementation of IPv6 also provides the following mechanisms to maintain compatibility between IPv4 and IPv6: Dual-stack support for both IPv4 and IPv6 on the same switch Configuration of IPv6 and IPv4 interfaces on the same VLAN. Tunneling of IPv6 traffic over an IPv4 network infrastructure Embedded IPv4 addresses in the four lower-order bits of the IPv6 address. The remainder of this section provides a brief overview of the new IPv6 address notation, autoconfiguration of addresses, and tunneling of IPv6 over IPv4.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 259 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IPv6 Specifications Note: RFC 2893 has been obsoleted by RFC4213. RFC4213 is now supported, but it does not include Automatic tunnels. Therefore, the main difference is that the new RFC4213 does not contain an automatic tunneling capability.

IPv6 Neighbor Discover Protocol (NDP)

RFCs Supported: 2460Internet Protocol, Version 6 (IPv6) Specification 2461Neighbor Discovery for IP Version 6 (IPv6) 2462IPv6 Stateless Address Auto-configuration 2463Internet Control Message Protocol (ICMPv6) for the IPv6 Specification 2464Transmission of IPv6 Packets Over Ethernet Networks 2893Transition Mechanisms for IPv6 Hosts and Routers 3513Internet Protocol Version 6 (IPv6) Addressing Architecture 3056Connection of IPv6 Domains via IPv4 Clouds Maximum VLANs per switch: 4094 (including default VLAN 1) Maximum IPv6 router VLANs per switch: 4094 IP and 256 IPX (single MAC router mode) Maximum IPv4 router VLANs per switch: 4094 IP and 256 IPX (single MAC router mode) Maximum IPv4interfcase per VLAN: 1 Maximum ARP entries per system: 4K Maximum IPv6 interfaces per tunnel: 1 Maximum IPv6 static routes: 1,000 routes Maximum RIPng routes: 5K Maximum RIPng interfaces: 100 Maximum OSPFv3 routes: 10K Maximum OSPFv3 interfaces: 10 Maximum OSPFv3 adjacencies: 10 Maximum OSPFv3 areas: 5 Maximum OSPFv3 sessions: 1 OSPF ECMP Gateways per destination: 4 Maximum BGP routes: None Maximum IP route entries (RIB): 10K Maximum route entries per FIB: None Maximum BGP peers per system: None OSPF LSDB size: 2000 Maximum IPv6 router interfaces per system -multiple router MAC mode: 256 Maximum 6to4 tunnels per switch: 1 Maximum configured tunnels per switch: 255 IPv6 (documented in RFC 2460) is designed as a successor to IPv4. The changes from IPv4 to IPv6 fall primarily into the following categories: Address size increased from 32 bits (IPv4) to 128 bits (IPv6) Dual Stack IPv4/IPv6 ICMPv6 Neighbor Discovery Stateless Auto configuration RIPng Static Routes Tunneling: Configured and 6-to-4 dynamic tunneling Ping, trace-route FTP and Telnet servers DNS client using Authority records OmniSwitch 6850 & 9000 switches support hardware-based IPv6 routing. Note. The switch operates only in single MAC router mode. In this mode, each router VLAN is assigned the same MAC address, which is the base chassis MAC address for the switch

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 260 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The Internet Packet Exchange (IPX) protocol (IPX Routing)

Transport Protocols support

Application-layer protocols support

Additional IP-related protocols support

The Internet Packet Exchange (IPX) protocol, developed by Novell for NetWare, is a Layer 3 protocol used to route packets through IPX networks. (NetWare is Novells network server operating system.). IPX specifies a connectionless datagram similar to the IP packet of TCP/IP networks. An IPX network address consists of two parts: a network number and a node number. The network administrator assigns the IPX network number. The node number is the Media Access Control (MAC) address for a network interface in the end node. Note. IPX routing is software-based only on OmniSwitch 6850 Series switches. This feature supports IPX routing, and fine-tuning IPX using optional IPX configuration parameters (e.g., IPX packet extension, type-20 propagation). It also supports IPX filtering, which is used to control the operation of the IPX RIP/SAP protocols. IPX Specifications: IPX RIP and Service Advertising Protocol (SAP) router specification; version 1.30; May 23, 1996 Part No. 107-000029-001 IPX is associated with additional protocols built into the switch software. The switch supports the following IPX protocols: IPX RIPLayer 3 protocol used by NetWare routers to exchange IPX routing information. IPX RIP and IP RIP functions are similar. IPX RIP uses two metrics to calculate the best route: hop count and ticks. An IPX router periodically transmits packets containing the information currently in its own routing table to neighboring IPX RIP routers to advertise the best route to an IPX destination. SAPLayer 3 protocol used by NetWare routers to exchange IPX routing information. SAP is similar in concept to IPX RIP. Just as RIP enables NetWare routers to exchange information about routes, SAP enables NetWare devices to exchange information about available network services. NetWare workstations use SAP to obtain the network addresses of NetWare servers. IPX routers use SAP to gather service information and then share it with other IPX routers. Sequenced Packet Exchange (SPX)Transport-layer protocol that provides a reliable end-to-end communications link by managing packet sequencing and delivery. SPX does not play a direct role in IPX routing; it simply guarantees the delivery of routed packets. IP is both connectionless (it forwards each datagram separately) and unreliable (it does not guarantee delivery of Datagrams). This means that a datagram may be damaged in transit, or thrown away by a busy switch, or simply never make it to its destination. The resolution of these transit problems is to use a Layer 4 transport protocol, such as: TCPA major data transport mechanism that provides reliable, connection-oriented, full-duplex data streams. While the role of TCP is to add reliability to IP, TCP relies upon IP to do the actual delivering of Datagrams. UDPA secondary transport-layer protocol that uses IP for delivery. UDP is not connection-oriented and does not provide reliable end-to-end delivery of Datagrams. But some applications can safely use UDP to send Datagrams that do not require the extra overhead added by TCP. Application-layer protocols are used for switch configuration and management: Bootstrap Protocol (BOOTP)/Dynamic Host Configuration Protocol (DHCP)May be used by an end station to obtain an IP address. The switch provides a DHCP Relay that allows BOOTP requests/replies to cross-different networks. Simple Network Management Protocol (SNMP)Allows communication between SNMP managers and SNMP agents on an IP network. Network administrators use SNMP to monitor network performance and manage network resources. TelnetUsed for remote connections to a device. You can telnet to a switch and configure the switch and the network using the CLI. File Transfer Protocol (FTP)Enables the transfer of files between hosts. This protocol is used to load new images onto the switch. There are several additional IP-related protocols that may be used with IP forwarding. These protocols are included as part of the base code. Address Resolution Protocol (ARP)Used to match the IP address of a device with its physical (MAC) address. Internet Control Message Protocol (ICMP)Specifies the generation of error messages, test packets, and informational messages related to IP. ICMP supports the ping command used to determine if hosts are online. Router Discovery Protocol (RDP)Used to advertise and discover routers on the LAN. Multicast ServicesIncludes IP multicast switching (IPMS)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 261 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Static routes support

Default route Address Resolution Protocol (ARP)

ARP Defense Optimization Detect ARP poisoning

The TTL value

IP Services

ICMP support

Routing Information Protocol (RIP) RIPv1&2 is supported Maximum number of IP Routes: 48K Maximum number of RIPv2 Interfaces per Router: 6 Maximum number of RIPv2 Peers per Router, one per interface: 6 Maximum number of RIPv2 routes: 8K

RIPng

RIP Timer Configuration

Static routes are user-defined routes that allow you to define, or customize, an explicit path to an IP network segment, which is then added to the IP Forwarding table. Static routes can be created between VLANs to enable devices on these VLANs to communicate. When you create a static route, the default metric value of 1 is used. However, you can change the priority of the route by increasing its metric value. The lower the metric value, the higher the priority. This metric is added to the metric cost of the route. The metric range is 1 to 15. Static routes do not age out of the IP Forwarding table; you must delete them from the table. Note. A static route is not active unless the gateway it is using is active. A default route can be configured for packets destined for networks that are unknown to the switch. To send packets on a locally connected network, the switch uses ARP to match the IP address of a device with its physical (MAC) address. To send a data packet to a device with which it has not previously communicated, the switch first broadcasts an ARP request packet. The ARP request packet requests the Ethernet hardware address corresponding to an Internet address. All hosts on the receiving Ethernet receive the ARP request, but only the host with the specified IP address responds. If present and functioning, the host with the specified IP address responds with an ARP reply packet containing its hardware address. The switch receives the ARP reply packet, stores the hardware address in its ARP cache for future use, and begins exchanging packets with the receiving device. Note: Local Proxy ARP is also supported. This feature enhances how the OmniSwitch can respond to an ARP DoS attack by not adding entries to the forwarding table until the net hop ARP entry can be resolved. This feature detects the presence of an ARP-Poisoning host on the network using configured restricted IP addresses for which the switch, on sending an ARP request, should not get back an ARP response. If an ARP response is received, the event is logged and the user is alerted using an SNMP trap. By default ARP requests are not added to the ARP cache. Only router solicited ARP requests will be added to the cache. The TTL value is the default value inserted into the TTL field of the IP header of Datagrams originating from the switch whenever a TTL value is not supplied by the transport layer protocol. The value is measured in hops. The default hop count is 64. The valid range is 1 to 255. When a switch initially boots up, all supported TCP/UDP well-known service ports are enabled (open). Although these ports provide access for essential switch management services, such as telnet, ftp, snmp, etc., they also are vulnerable to DoS attacks. It is possible to scan open service ports and launch such attacks based on well-known port information. The ip service command allows you to selectively disable (close) TCP/UDP well-known service ports and enable them when necessary. This command only operates on TCP/UDP ports that are opened by default. It has no affect on ports that are opened by loading applications, such as RIP etc. In addition, the ip service command allows you to designate which port to enable or disable by specifying the name of a service or the well-known port number associated with that service. ICMP is a network layer protocol within the IP protocol suite that provides message packets to report errors and other IP packet processing information back to the source. ICMP generates several kinds of useful messages, including Destination Unreachable, Echo Request and Reply, Redirect, Time Exceeded, and Router Advertisement and Solicitation. Routing Information Protocol (RIP) is a widely used Interior Gateway Protocol (IGP) that uses hop count as its routing metric. RIP-enabled routers update neighboring routers by transmitting a copy of their own routing table. The RIP routing table uses the most efficient route to a destination that is, the route with the fewest hops and longest matching prefix. The switch supports RIP version 1 (RIPv1), RIP version 2 (RIPv2), and RIPv2 that is compatible with RIPv1. It also supports text key and MD5 authentication, on an interface basis, for RIPv2. Release 6.3.1 added ECMP capability for up to 4 paths. RIP Specifications: RFC 1058RIP v1 RFC 2453RIP v2 RFC 1722RIP v2 Protocol Applicability Statement RFC 1724RIP v2 MIB Extension The OmniSwitch 6850/9000 switches support Routing Information Protocol next generation (RIPng) for IPv6 networks. RIPng is based on RIPv1/RIPv2 and is an Interior Gateway Protocol (IGP) best suited for moderate sized networks. The 6.1.5 release provides the ability to configure the following key RIP timer values: Update The time interval between advertisement intervals. InvalidThe amount of time before an active route expires and transitions to the garbage state. GarbageThe amount of time an expired route remains in the garbage state before it is removed from the RIB. HolddownThe amount of time during which a route remains in the hold-down state.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 262 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OSPFv2 Specifications

The following values are the maximum limits enforced by the code. Maximum number of Areas (per router): 32 Maximum number of Interfaces (per area): 100 Maximum number of Interfaces (per router): 32 x 100 (Limited only by max. num of IPv4 interfaces = 4096) Maximum number of Link State Database entries (per router): 96K Maximum number of neighbors/adjacencies (per router): 254 Maximum number of neighbors/adjacencies (per area): 128 Maximum number of routes (per router): 96K Maximum number of OSPFv2- ECMP gateways (per destination): 4 Max number of OSPFv2 Sessions: 1 The following values are the tested limits with functionally verified (stress test). On OS6850 ABR routers: Max number of IP Routes on OS6850 router: 12K Max number of OSPFv2 Routes on OS6850 router: 12K Max number of OSPFv2 Interfaces on OS6850 ABR: 48 Max number of OSPFv2 Areas on OS6850 ABR: 6 Max number of OSPFv2 Adjacencies on OS6850 ABR: 48 Max number of LSAs on OS6850 ABR: 12K Tested number of OSPFv2- ECMP gateways (per destination): 4 Max number of OSPFv2 Sessions: 1 On OS6850 non-ABR routers: Max number of IP Routes on OS6850 router: 96K Max number of OSPFv2 Routes on OS6850 router: 96K Max number of OSPFv2 Interfaces on OS6850 non-ABR: 27 Max number of OSPFv2 Areas on OS6850 non-ABR: 6 Max number of OSPFv2 Adjacencies on OS6850 non-ABR: 27 Max number of LSAs on OS6850 non-ABR: 24K Tested number of OSPFv2- ECMP gateways (per destination): 4 Max number of OSPFv2 Sessions: 1 Notes: Please note that, the above OSPFv2 specifications may vary depending on the available system resources, and/or customer specific networking requirements & configurations. Please also note that, depending on the number of Areas, Interfaces, Adjacencies, and Neighbors configured, the maximum number of routes may vary. Please contact our customer Service & Support team, should your required specifications fall between "the limits as enforced by the code" and "the limits as functionally tested".

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 263 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Open Shortest Path First routing (OSPF) support OSPFv2 & OSPFv3 are supported Open Shortest Path First version 3 (OSPFv3) is available. OSPFv3 is an extension of OSPF version 2 (OSPFv2) that provides support for networks using the IPv6 protocol. OSPFv2 is for IPv4 networks. Both versions of OSPF are shortest path first (SPF), or link-state, protocols for IP networks. Also considered interior gateway protocols (IGP), both versions distribute routing information between routers in a single Autonomous System (AS). OSPF chooses the least-cost path as the best path. OSPF is suitable for complex networks with a large number of routers by providing faster convergence, loop free routing, and equal-cost multi-path routing where packets to a single destination can be sent to more than one interface simultaneously. OSPF adjacencies over non-broadcast links are also supported. In addition, OSPFv2 supports graceful (hitless) support during failover, which is the time period between the restart and the reestablishment of adjacencies after a planned (e.g., the users performs the takeover) or unplanned (e.g., the primary management module unexpectedly fails) failover. Note that OSPFv3 does not support graceful restart.

Open Shortest Path First routing (OSPF) is a shortest path first (SPF), or link state, protocol. OSPF is an interior gateway protocol (IGP) that distributes routing information between routers in a single Autonomous System (AS). OSPF chooses the least-cost path as the best path. OSPF is suitable for complex networks with large numbers of routers since it provides faster convergence where multiple flows to a single destination can be forwarded on one or more interfaces simultaneously. The following features are also supported: Graceful (Hitless) Support During Fail-over, which is the time period between the restart and the reestablishment of adjacencies after a planned (e.g., the users performs the takeover) or unplanned (e.g., the primary management module unexpectedly fails) fail-over. OSPF adjacencies over non-broadcast links. Continuous forwarding during a graceful restart depends on several factors. If the secondary module has a different router MAC than the primary module, or if one or more ports of a VLAN belonged to the primary module, spanning tree re-convergence might disrupt the forwarding state, even though OSPF performs a graceful restart. OSPFv2 Specifications: RFCs Supported: 1370Applicability Statement for OSPF 1850OSPF Version 2 Management Information Base 2328OSPF Version 2 2370The OSPF Opaque LSA Option 3101The OSPF Not-So-Stubby Area (NSSA) Option 3623Graceful OSPF Restart The following values are the maximum limits enforced by the code. Maximum number of Areas (per router): 32 Maximum number of Interfaces (per area): 100 Maximum number of Interfaces (per router): 32 x 100 (Limited only by max. num of IPv4 interfaces = 4096) Maximum number of Link State Database entries (per router): 96K Maximum number of neighbors/adjacencies (per router): 254 Maximum number of neighbors/adjacencies (per area): 128 Maximum number of routes (per router): 96K Maximum number of OSPFv2- ECMP gateways (per destination): 4 Max number of OSPFv2 Sessions: 1 The following values are the tested limits with functionally verified (stress test). On OS6850 ABR routers: Max number of IP Routes on OS6850 router: 12K Max number of OSPFv2 Routes on OS6850 router: 12K Max number of OSPFv2 Interfaces on OS6850 ABR: 48 Max number of OSPFv2 Areas on OS6850 ABR: 6 Max number of OSPFv2 Adjacencies on OS6850 ABR: 48 Max number of LSAs on OS6850 ABR: 12K Tested number of OSPFv2- ECMP gateways (per destination): 4 Max number of OSPFv2 Sessions: 1 On OS6850 non-ABR routers: Max number of IP Routes on OS6850 router: 96K Max number of OSPFv2 Routes on OS6850 router: 96K Max number of OSPFv2 Interfaces on OS6850 non-ABR: 27 Max number of OSPFv2 Areas on OS6850 non-ABR: 6 Max number of OSPFv2 Adjacencies on OS6850 non-ABR: 27 Max number of LSAs on OS6850 non-ABR: 24K Tested number of OSPFv2- ECMP gateways (per destination): 4 Max number of OSPFv2 Sessions: 1 OSPFv3 Specifications: RFCs supported: 2740 -OSPF for IPv6 1826 - IP Authentication Header 1827 - IP Encapsulating Security Payload 2553 - Basic Socket Interface Extensions for IPv6 2373 - IPv6 Addressing Architecture 2374 - An IPv6 Aggregatable Global Unicast Address Format 2460 - IPv6 base specification Internet Drafts Supported: draft-ietf-ospf-ospfv3-graceful-restart-xx.txtOSPFv3 Graceful Restart draft-ietf-ospf-ospfv3-mibxx.txtManagement Information Base for OSPFv3 draft-ietf-ospf-ospfv3-update-00.txtOSPF for IPv6 draft-ietf-ospf-ospfv3-auth-05.txtAuthentication/ Confidentiality for OSPFv3

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 264 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OSPF ECMP (Equal Cost Multi-Path) Routing support OSPF Security

Route Redistribution

IS-IS

draft-ietf-ospf-ospfv3-mib-08.txtMIB Maximum number of Areas (per router): TBS Maximum number of Interfaces (per router): TBS Maximum number of Link State Database entries (per router): TBS Maximum number of adjacencies (per router): TBS Maximum number of ECMP gateways (per destination): TBS Maximum number of neighbors (per router); TBS Maximum number of routes (per router): TBS Notes: Please note that, the above OSPF specifications may vary depending on the available system resources, and/or customer specific networking requirements & configurations. Please also note that, depending on the number of Areas, Interfaces, Adjacencies, and Neighbors configured, the maximum number of routes may vary. Please contact our customer Service & Support team, should your required specifications fall between "the limits as enforced by the code" and "the limits as functionally tested". Using information from its continuously updated databases, OSPF calculates the shortest path to a given destination. Shortest path is determined from metric values at each hop along a path. At times, two or more paths to the same destination will have the same metric cost. OSPF allows for the use of authentication on configured interfaces. When authentication is enabled, only neighbors using the same type of authentication and the matching passwords or keys can communicate. There are two types of authentication: simple and MD5. Simple authentication requires only a text string as a password, while MD5 is a form of encrypted authentication that requires a key and a password. Both types of authentication require the use of more than one command. Redistribution provides a way to exchange routing information between RIP networks and OSPF networks; and also redistributes local and static routes. For example, redistribution makes a non-RIP route look like a RIP route. Route redistribution between RIPv1/v2, and OSPF is supported. It also has filtering capabilities. Intermediate System-to-Intermediate System (IS-IS) is an International Organization for Standardization (ISO) dynamic routing specification. IS-IS is a shortest path first (SPF), or link state protocol. It is an interior gateway protocol (IGP) that distributes routing information between routers in a single Autonomous System (AS) in IP as well as in OSI environments. IS-IS chooses the least-cost path as the best path. IS-IS is suitable for complex networks with large number of routers since it provides faster convergence where multiple flows to a single destination can be forwarded through one or more interfaces simultaneously. IS-IS is also an ISO Connectionless Network Protocol (CLNP). It communicates with its peers using the Connectionless Mode Network Service (CLNS) PDU packets, which means that even in an IP-only environment the IS-IS router must have an ISO address. ISO network-layer addressing is done through Network Service Access Point (NSAP) addresses that identify any system in the OSI network. IS-IS Specifications: RFCs Supported: 1142-OSI IS-IS Intra-domain Routing Protocol 1195OSI IS-IS for Routing in TCP/IP and Dual Environments Maximum number of areas (per router): 3 Maximum number of L1 adjacencies per interface (per router): 70 Maximum number of L2 adjacencies per interface (per router): 70 Maximum number of IS-IS interfaces (per router): 70 Maximum number of Link State Packet entries (per adjacency): 255 Maximum number of IS-IS routes: 24000 Maximum number of IS-IS L1 routes: 12000 Maximum number of IS-IS L2 routes: 12000 Release 6.3.1 adds support for the OS-9000 as well as simple and MD5 authentication.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 265 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The Border Gateway Protocol (BGPv4)

BGP IPv6 Extensions

BGP Graceful Restart

The Router Discovery Protocol (RDP)

The Border Gateway Protocol (BGP) is an exterior routing protocol that guarantees the loop-free exchange of routing information between autonomous systems. The Alcatel-Lucent implementation supports BGP version 4 as defined in RFC 1771. The Alcatel-Lucent implementation of BGP is designed for enterprise networks, specifically for border routers handling a public network connection, such as the organizations Internet Service Provider (ISP) link. Up to 65,000 route table entries and next hop routes can be supported by BGP. On OmniSwitch devices in a redundant stacking configuration, during a management takeover/failover, interdomain routing is disrupted. Alcatel.Lucent Operating System BGP needs to retain forwarding information, also help a peering router performing a BGP restart to support continuous forwarding for inter-domain traffic flows by following the BGP graceful restart mechanism. BGPv4 Specifications: RFCs Supported: 1771A Border Gateway Protocol 4 (BGP-4) 2385Protection of BGP Sessions via the TCP MD5 Signature Option 2439BGP Route Flap Damping 2842Capabilities Advertisement with BGP-4 2042Registering New BGP Attribute Types 1997BGP Communities Attribute 1998An Application of the BGP Community Attribute in Multi-Home Routing 1966BGP Route Reflection: An Alternative to Full Mesh IBGP 1965Autonomous System Confederations for BGP 1773Experience with BGP-4 Protocol 1774BGP-4 Protocol Analysis 1657Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) Using SMIv2 BGP Attributes Supported: Origin, AS Path, Next Hop, MED, Local Preference, Atomic Aggregate, Aggregator, Community, Originator ID, Cluster List Maximum BGP Peers per Router: 8 Maximum number of routes supported: 30,000 Range for AS Numbers: 1 to 65535 Range of Local Preference Values: 0 to 4294967295 Range for Confederation Ids: 0 to 65535 Range for MED Attribute: 0 to 4294967295 The OmniSwitch provides IPv6 support for BGP using Multiprotocol Extensions. The same procedures used for IPv4 prefixes can be applied for IPv6 prefixes as well and the exchange of IPv4 prefixes will not be affected by this new feature. However, there are some attributes that are specific to IPv4, such as AGGREGATOR, NEXT_HOP and NLRI. Multiprotocol Extensions for BGP also supports backward compatibility for the routers that do not support this feature. This implementation supports Multiprotocol BGP as defined in the following RFCs: 4271, 2439, 3392, 2385, 1997, 4456, 3065, 4273, 4760, and 2545. Note that IPv6 extensions for BGP are only supported on the OmniSwitch 6850 and 9000. Release 6.3.1 adds WebView and SNMP support. BGP Graceful Restart is supported and is enabled by default. On OmniSwitch devices in a redundant stacking configuration, during a management takeover/failover, interdomain routing is disrupted. Alcatel-Lucent Operating System BGP needs to retain forwarding information and also help a peering router performing a BGP restart to support continuous forwarding for inter-domain traffic flows by following the BGP graceful restart mechanism. The Router Discovery Protocol (RDP) is an extension of ICMP that allows end hosts to discover routers on their networks. This implementation of RDP supports the router requirements as defined in RFC 1256. Using RDP, hosts attached to multicast or broadcast networks send solicitation messages when they start up. Routers respond to solicitation messages with an advertisement message that contains the router IP addresses. In addition, routers send advertisement messages when their RDP interface becomes active and then subsequently at random intervals. RDP Specifications: RFCs Supported: RFC 1256ICMP Router Discovery Messages Router advertisements: Supported Host solicitations: Only responses to solicitations supported in this release. Max no of RDP interfaces per switch: One for each available IP interface configured on the switch. Advertisement destination addresses: 224.0.0.1 (all systems multicast), 255.255.255.255 (broadcast)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 266 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The User Datagram Protocol (UDP)

Generic UDP Relay

The DHCP Relay service

DHCP Relay

Per-VLAN DHCP Servers

Per-VLAN DHCP Relay

The User Datagram Protocol (UDP) is a connectionless transport protocol that runs on top of IP networks. UDP is used for applications that do not require the establishment of a session and end-toend error checking. Email and file transfer are two applications that could use UDP. UDP offers a direct way to send and receive data-grams over an IP network and is primarily used for broadcasting messages. The UDP Relay feature allows UDP broadcast packets to be forwarded across groups and VLANs that have IP routing enabled. UDP Relay ensures that the DHCP mechanism is operational and it allows you to use non-routable protocols in a routing environment. UDP Relay is configured using the ip helper set of commands. The DHCP Relay allows you to use non-routable protocols (such as UDP) in a routing environment. In addition to BOOTP/DHCP relay, generic UDP relay is available. Using generic UDP relay, traffic destined for well-known service ports (e.g., NBNS/NBDD, DNS, TFTP, and TACACS) or destined for a user-defined service port can be forwarded to a maximum of 256 VLANs on the switch. The DHCP Relay service, its corresponding port numbers, and configurable options are as follows: DHCP Relay Service: BOOTP/DHCP UDP Port Numbers 67/68 for Request/Response Configurable options: DHCP server IP address, Forward Delay, Maximum Hops, Forwarding Option, automatic switch IP configuration. DHCP Relay Specifications: RFCs Supported: 0951Bootstrap Protocol 1534Interoperation Between DHCP and BOOTP 1541Dynamic Host Configuration Protocol 1542Clarifications and Extensions for the Bootstrap Protocol 2132DHCP Options and BOOTP Vendor Extensions 3046-DHCP Relay Agent Information Option, 2001 DHCP Relay Implementation: Global DHCP Per-VLAN DHCP AVLAN DHCP DHCP Relay Service: BOOTP/DHCP (Bootstrap Protocol/Dynamic Host Configuration Protocol) UDP Port Numbers: 67 for Request, 68 for Response IP address allocation mechanisms: AutomaticDHCP assigns a permanent IP address to a host. DynamicDHCP assigns an IP address to a host for a limited period of time (or until the host explicitly relinquishes the address). ManualThe network administrator assigns a hosts IP address and the DHCP conveys the address assigned by the host. IP addresses supported for each Relay Service: Maximum of 256 IP addresses for each Relay Service. IP addresses supported for the Per-VLAN service: Maximum of 8 IP addresses for each VLAN relay service. Maximum of 256 VLAN relay services. Maximum number of UDP relay services allowed per switch: 3 Maximum number of VLANs to which forwarded UDP service port traffic is allowed: 256 Maximum number of DHCP Snooping VLANs: 64 DHCP Relay allows you to forward DHCP broadcast requests to configurable DHCP server IP address in a routing environment. DHCP Relay is configured using the IP helper set of commands. Pre-boot Execution Environment (PXE) support was enabled by default in previous releases. Note that in release 6.3.1r01, it is disabled by default and is now a user-configurable option using the ip helper pxe-support command. The OmniSwitch allows you to configure the UDP Relay feature based on the VLAN ID of the DHCP request. For the Per-VLAN service, you identify the number of the VLAN that makes the relay request. You may identify one or more server IP addresses to which DHCP packets will be sent from the specified VLAN. Both standard and per VLAN modes are supported. It is possible to configure multiple DHCP relay (ip helper) addresses on a per-vlan basis. For the Per-VLAN service, identify the number of the VLAN that makes the relay request. You may identify one or more server IP addresses to which DHCP packets will be sent from the specified VLAN. Both standard and per VLAN modes are supported.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 267 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

DHCP Security Features: DHCP Option-82 o Relay agent (switch) includes information about itself when forwarding client-originated DHCP packets to a DHCP server DHCP Snooping o Per Port/Per VLAN o Disabled by default o Binding database build: slot/port/MAC/IP IP spoof protection o Based on the information in the binding database ACL created Note: the DHCP Option-82 and DHCP Snooping are part of Residential bridging features DHCP Option-82 (Relay Agent Information Option)

There are two DHCP security features available: DHCP relay agent information option (Option-82) and DHCP Snooping. The DHCP Option-82 feature enables the relay agent to insert identifying information into client-originated DHCP packets before the packets are forwarded to the DHCP server. The DHCP Snooping feature filters DHCP packets between untrusted sources and a trusted DHCP server and builds a binding database to log DHCP client information. Although DHCP Option-82 is a subcomponent of DHCP Snooping, these two features are mutually exclusive. If the DHCP Option-82 feature is enabled for the switch, then DHCP Snooping is not available. The reverse is also true; if DHCP Snooping is enabled, then DHCP Option-82 is not available. In addition, the following differences exist between these two features: DHCP Snooping does require and use the Option-82 data insertion capability, but does not implement any other behaviors defined in RFC 3046. DHCP Snooping will automatically drop client DHCP packets that already have Option-82 information present. The DHCP Option-82 feature provides configurable options for dealing with such packets. DHCP Snooping is configurable at the switch level and on a per-VLAN basis, but DHCP Option-82 is only configurable at the switch level.

DHCP Snooping

The DHCP Option-82 feature enables the relay agent to insert identifying information into clientoriginated DHCP packets before the packets are forwarded to the DHCP server. The implementation of this feature is based on the functionality defined in RFC 3046. When DHCP Option-82 is enabled, communications between a DHCP client and a DHCP server are authenticated by the relay agent. To accomplish this task, the agent adds Option-82 data to the end of the options field in DHCP packets sent from a client to a DHCP server. If the relay agent receives a DHCP packet from a client that already contains Option-82 data, the packet is dropped by default. However, it is possible to configure a DHCP Option-82 policy that directs the relay agent to drop, keep, or replace the existing Option-82 data and then forward the packet to the server. DHCP Option-82 is supported on the OmniSwitch 6800 Series, OmniSwitch 6850 Series, and on the OmniSwitch 9000 Series. DHCP Snooping improves network security by filtering DHCP packets received from devices outside the network and building and maintaining a binding table (database) to log DHCP client access information. There are two levels of operation available for the DHCP Snooping feature: switch level or VLAN level. To identify DHCP traffic that originates from outside the network, DHCP Snooping categorizes ports as either trusted or untrusted. A port is trusted if it is connected to a device inside the network, such as a DHCP server. A port is untrusted if it is connected to a device outside the network, such as a customer switch or workstation. The port trust mode is also configurable through the CLI. Additional DHCP Snooping functionality includes the following: Layer 2 DHCP SnoopingApplies DHCP Snooping functionality to bridged DHCP client/server broadcasts without using the relay agent or requiring an IP interface on the client/server VLAN. Traffic SuppressionPrevents the flooding of DHCP packets on the default VLAN for a DHCP Snooping port. Note that enabling traffic suppression on a port will prevent DHCP traffic between a DHCP server and client that belong to the same VLAN domain. IP Source FilteringRestricts DHCP Snooping port traffic to only packets that contain the client source MAC address and IP address obtained from the DHCP lease information. The DHCP Snooping binding table is used to verify the client lease information for the port that is enabled for IP source filtering. Rate LimitingLimits the number of DHCP packets on a port. This functionality is provided using the QoS application to configure ACLs for the port. User-configurable Option 82 Sub-option FormatAllows the user to specify the type of information (switch base MAC address, system name, or user-defined string) that is inserted into the Circuit ID and Remote ID sub-options of the Option-82 field. This functionality only applies when DHCP Snooping Option-82 Data Insertion is enabled.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 268 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

L2 DHCP Snooping

GVRP

By default, DHCP broadcasts are flooded on the default VLAN for the client/server port. If the DHCP client and server are both members of the same VLAN domain, the broadcast packets from these sources are bridged as Layer 2 traffic and not processed by the relay agent. As a result, any active relay agent features (e.g., information Option-82, DHCP Snooping) are not applied to this type of DHCP traffic. The DHCP Relay application has a traffic suppression feature that suppresses the broadcast of DHCP packets and forwards these packets to the relay agent for processing. Enhancements to DHCP Snooping provided with the 6.1.5 release allow application of DHCP Snooping functionality to bridged DHCP client/server broadcasts without using the relay agent or requiring an IP interface on the client/server VLAN. When DHCP Snooping is enabled at the switch level or for an individual VLAN, DHCP Snooping functionality is automatically applied to Layer 2 traffic. When DHCP Snooping is disabled at the switch level or disabled on the last VLAN to have snooping enabled on the switch, DHCP Snooping functionality is no longer applied to Layer 2 or Layer 3 traffic. The GARP VLAN Registration Protocol (GVRP), a protocol compliant with 802.1Q, dynamically learns and further propagates VLAN membership information across a bridged network. GVRP dynamically maintains and updates the registration and de-registration of VLANs and prunes unnecessary broadcast and unicast traffic. Through propagation of GVRP information, a device is continuously able to update its knowledge of the set of VLANs that currently have active members and of the ports through which those members can be reached. With GVRP, a single switch is manually configured with all the desired VLANs for the network, and all other switches on the network dynamically learn those VLANs. An end station can be plugged into any switch and can be connected to its desired VLAN. However, for end stations to make use of GVRP, they need Network Interface Cards (NIC) aware of GVRP. Release 6.3.1 added the following: OS9000 Support Generate a trap if the number of dynamic VLANs exceeds the maximum threshold configured for GVRP. The GARP VLAN Registration Protocol (GVRP) facilitates in controlling virtual local area networks (VLANs) in a large network. It is an application of Generic Attribute Registration Protocol (GARP) and provides VLAN registration service. GVRP enables devices to dynamically learn their VLAN memberships. GVRP is compliant with 802.1Q standard. It dynamically learns and propagates VLAN membership information across a bridged network. GVRP dynamically maintains and updates the registration and de-registration of VLANs and prunes unnecessary broadcast and unicast traffic. Through the propagation of GVRP information, a device is continuously able to update its knowledge on the set of VLANs that currently have active nodes and on the ports through which those nodes can be reached. GVRP Specifications Below lists specifications for Alcatel-Lucents GVRP: IEEE Standards Supported: IEEE Std. 802.1D - 2004, Media Access Control (MAC) Bridges IEEE Draft Std. P802.1Q-REV/D5.0 Maximum GVRP VLANs: 4094

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 269 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Triple Play

The Alcatel-Lucent Omni Prodcut Families are advanced, L2-L3 switches that extend intelligence to the metro access edge of a triple-play service delivery architecture network. With a range of Fast Ethernet, Gigabit Ethernet, 10Gigabit Ethernet, DC power, and fiber configurations, the Omni Prodcut Families are suitable for use as a metro access switch for enterprise networks as well as in small , medium, and large-sized business markets.The Omni Prodcut Families are well suited for supporting Ethernet access services within the Alcatel-Lucent real-time triple-play service delivery architecture of data, voice and video. By offering Triple Play features that focus on strengthening the availability, manageability and performance of these devices for service provider networks that have higher network availability requirements, the Omni Products will be able to compete very well with the competion. The Omni Prodcut Families Triple Play offerings are extremely cost effective and highly manageable which together with the following unique standards-based features sets them apart from the competition: Omni Prodcut Families Convergence / Triple Play features in support of Residential Metro Triple-play Ethernet Access: o The Omni Prodcut families are designed for resiliency and exceptional network performance to support real-time triple-play applications such as voice-over-IP (VoIP), data, and video applications supported by: o High-port density o High-capacity switching and traffic aggregation for business network cores o Highly-available switching fabric with a unique load sharing capability By providing true redundancy, an enterprise can provide a reliable network for triple play applications. o Multi-layer security o Simplaified but yet powerful unified management o Extremly Cost effective Triple Play offerings from Alcatel_lucent o Wire-speed performance including the first packet giving a noticeable performance boost to triple play networks. o Wire speed packet classification o Traffic prioritization: Flow-based QoS with internal and external (a.k.a., remarking) prioritization o Eight hardware-based quality of service (QoS) queues ensuring wire-speed packet classification and processing for all packets in a data steam o Bandwidth management: flow based bandwidth management, ingress policing/egress shaping and port based egress shaping o Queue management: Random Early Detect/Discard (RED), configurable dequeuing algorithm; Strict Priority, Weighted and Deficit Round Robin. o Power-over-Ethernet: IEEE 802.3af for PoE o Residential bridging features: DHCP option-82 relay agent information, DHCP-Snooping and Port Mapping Support for CWDM fiber optics Q-in-Q (Vlan Stacking) / 802.1ad: VLAN Stacking provides a mechanism for tunneling multiple customers VLANs (CVLAN) through a service provider network over the Ethernet Metropolitan Area Network (EMAN). The following features are supported for the OS6850 Series in AOS Release 6.2 and will be supported for the OmniSwitch 9000 Series in AOS Release 6.3. Ethernet Operations Administration and Maintenance (OAM) support: The acceptance of Ethernet as a metropolitan and wide-area networking technology has accelerated the need for a new set of OAM protocols. Service provider networks are large and complex with a wide user base, and they often involve different operators that must work together to provide end-to-end services to enterprise customers. By adding a support for Ethernet OAM, as defined in IEEE 802.1ag (version 7.0), the OS6850s are capable of generating and sending OAM messages that are used by the network administrators and operation staff to detect, verify and isolate problems in the network. Rapid Ring Spanning Tree: A ring topology offers built-in redundancy and is often the most economical in terms of interconnection costs. The Rapid Ring STP implementation available in AOS 6.2.1 was built upon the Rapid Spanning Tree Protocol (RSTP) standard and is enhanced in two ways: o Improves the fault recovery time performance o Improved performance for large ring network topologies In certain configurations RRSTP provides fault recovery times of 10 times faster than the current implementation. In addition to that we have maintained compatibility with standard RSTP for interoperability with the rest of the switches.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 270 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The Virtual Router Redundancy Protocol (VRRPv2/VRRP3)

Global VRRP Configuration (VRRP Global Commands)

IP Multicast VLANs: Many providers need to have a way of separating users using VLANs while still being able to distribute broadcast media via IP multicast across these VLANs without a router being present in the distribution L2 switch. With the AOS 6.2.1, implementation of IP Multicast VLANs, the OmniSwitch 6850 can be used as a distributor of multicast traffic from a multicast server to the attached subscribers, reducing the packet duplication across the network. Multicast traffic will only flow from the distribution VLAN to the customer and not vise-versa. MAC retention: With the support of this feature in release 6.2.1, the OmniSwitch 6850 is made even more resilient to failures of the current primary element in the stack, which translates into smart continuous switching for stack-based products. When enabled, the MAC retention feature allows a system of stackable switches to retain the MAC address of the primary switch for a fixed or indefinite time, even after takeover, which avoids the disruption of L2 or L3 services. Intermediate System-to-Intermediate System (IS-IS) Routing Protocol: In recent years, the IS-IS routing protocol has become increasingly popular, with widespread use among service providers. It is a link state protocol, which enables very fast convergence, supports much larger networks, reduces the control traffic, and provides greater flexibility when extending the network. GVRP: Generic Attribute Registration Protocol (GARP) VLAN Registration Protocol (GVRP) is an application defined in the IEEE 802.1Q standard that allows for dynamic control of VLANs, which offers easier configuration in larger networks with automatic optimization of data flows. GVRP is an industry-standard protocol designed to propagate VLAN information from device to device. With GVRP, a single switch is manually configured with all the desired VLANs for the network, and all other switches on the network learn those VLANs dynamically. The Virtual Router Redundancy Protocol (VRRPv2/VRRP3) is a standard router redundancy protocol supported in IPv4/IPv6. It is based on RFC 3768 and RFC 2787 and provides redundancy by eliminating the single point of failure inherent in a default route environment. The VRRP/VRRP3 router, which controls the IP/IPv6 address associated with a virtual router is called the master router, and it forwards the packets to that IP/IPv6 address. If the master router becomes unavailable, the highest priority backup router will transition to the master state. Note. RFC 3768, which obsoletes RFC 2338, does not include support for authentication types. As a result, configuring VRRP authentication is no longer supported in this release. In addition, VRRP Tracking is also supported. A virtual routers priority may be conditionally modified to prevent another router from taking over as master. Tracking policies are used to conditionally modify the priority setting whenever a VLAN, slot/port, and/or IP address associated with a virtual router goes down. VRRP Specifications: RFCs Supported: RFC 2787Definitions of Managed Objects for the Virtual Router Redundancy Protocol RFC 3768Virtual Router Redundancy Protocol Compatible with HSRP: No Maximum number of virtual router instances: 255 (A virtual router is defined by a virtual router identifier (VRID) and a set of associated IP addresses on the LAN) Maximum number of IP addresses: 1 for the IP address owner; more than 1 address may be configured if the router is a backup for a master router that supports multiple addresses Release 6.3.1 added the following capabilities for VRRP2 only: Globally enable or disable all or a range of VRRP instances. View or configure default values such as priority, preempt, or advertising interval on all or a group or VRRP instances.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 271 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VRRPv3

This implementation is based on the latest Internet-Draft for VRRP for IPv6. VRRP version 2 (VRRPv2) is based on RFC 2338. Similar to VRRPv2, VRRPv3 is a standard router redundancy protocol that provides redundancy by eliminating the single point of failure inherent in a default route environment. The VRRPv3 router, Which controls the IPv6 address associated with a virtual router is called the master router, and is responsible for forwarding virtual router advertisements. If the master router becomes unavailable, the highest priority backup router will transition to the master state. Both versions of VRRP allow routers on a LAN to back up a static default route with a virtual router. VRRP dynamically assigns responsibility for a virtual router to a physical router (VRRP router) on the LAN. The virtual router is associated with an IP address (or set of IP addresses) on the LAN. A virtual router master is elected to forward packets for the virtual routers IP address. If the master router becomes unavailable, the highest priority backup router will transition to the master state. Authentication is not supported. In addition, both versions support VRRP Tracking. A virtual routers priority may be conditionally Modified to prevent another router from taking over as master. Tracking policies are used to Conditionally modify the priority setting whenever an ip interface, slot/port, and/or IP address associated with a virtual router goes down. Note that VRRPv3 is not available on the OmniSwitch 6800 Series. VRRPv2 is available on all supported OmniSwitch platforms.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 272 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Quality of Service (QoS)

Quality of Service (QoS) Alcatel.Lucents QoS software provides a way to manipulate flows coming through the switch based on user-configured policies. The flow manipulation (generally referred to as Quality of Service or QoS) may be as simple as allowing/denying traffic, or as complicated as re-mapping 802.1p bits from a Layer-2 network to ToS values in a Layer-3 network. QoS can support up to 2048 policies and it is hardware-based on the first packet. OmniSwitch 6850/9000 switches truly support 8 queues per port. QoS is implemented on the switch through the use of policies, created on the switch or stored on an attached LDAP server. While policies may be used in many different types of network scenarios, there are several typical types worth mentioning: Basic QoSincludes traffic prioritization and bandwidth shaping ICMP policiesincludes filtering, prioritizing, and/or rate limiting ICMP traffic for security 802.1p/ToS/DSCPincludes policies for marking and mapping (Release 6.3.1 added support for DSCP Ranges) Policy Based Routing (PBR)includes policies for redirecting routed traffic. Policy Based Mirroringincludes mirror-to-port (MTP) policies for mirroring ingress, egress, or both ingress and egress traffic. Access Control Lists (ACLs)ACLs are a specific type of QoS policy used for Layer 2, Layer 3, Layer4, and multicast filtering. Note. Policies may also be configured through the PolicyView NMS application and stored on an attached LDAP server. LDAP policies are downloaded to the switch and managed via the Policy Manager feature in the switch. NAT is not supported. QoS Specifications: Maximum number of configurable policy rules per switch: 2048 Maximum number of policy rules per Ethernet port: 101(OmniSwitch 6800 only) Maximum number of policy rules per 10GB port: 997 (OmniSwitch 6800 only) Maximum number of policy conditions : 2048 Maximum number of policy actions: 2048 Maximum number of policy services : 256 Maximum number of groups (network, MAC, service, port) per stand-alone: 1024 Maximum number of group entries: 1024 per group Maximum number of rules per slot : 1664 (OmniSwitch 6850 and 9000 only) Maximum number of bandwidth shaping rules per slot: 832 (OmniSwitch 6850 and 9000 CMM only) Maximum number of priority queues per port: 8 (Note that two of the eight queues on OmniSwitch 6800 QoS ports are reserved for internal use only, so they are not available.) CLI Command Prefix Recognition: Some QoS commands support prefix recognition. QoS enabled or disabled: Enabled Global default queuing scheme for ports: Strict priority queuing Whether ports are globally trusted or untrusted: 802.1Q-tagged ports and mobile ports are always trusted; any other port is untrusted Statistics interval: 60 seconds Global bridged disposition: Accept Global routed disposition: Accept Global multicast disposition: Accept Level of log detail: 6 Number of lines in QoS log: 256 Whether log messages are sent to the console: No Whether log messages are available to OmniVista applications: No Whether IP anti-spoofing is enabled on UserPorts. (Not supported on OmniSwitch 6800.): Yes Whether a UserPorts port is administratively disabled when unwanted traffic is received. (Not supported on OmniSwitch 6800.): No Automatic NMS traffic prioritization. (Not supported on OmniSwitch 6800.): Enabled Priority for IP Phone connections. (Not supported on OmniSwitch 6800.): Trusted Type of messages logged: Information The default 802.1p value inserted into packets received on untrusted ports: 0 The default DSCP value inserted into packets received on untrusted ports: 0 Whether the port uses strict priority or weighted fair queuing: Strict priority queuing The default minimum/maximum bandwidth for each of the eight CoS queues per port. (Not supported on the OmniSwitch 6800.): minimum = best effort and maximum = port bandwidth Whether the port is trusted or untrusted: 802.1Q and mobile ports are always trusted; other ports are untrusted Maximum egress bandwidth: Port bandwidth Maximum ingress bandwidth: Port bandwidth

Global QoS Defaults

QoS Port Defaults

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 273 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Policy Rule Defaults

Policy Action Defaults Automatic QoS Prioritization

Automatic Prioritization for NMS Traffic

Automatic Prioritization on IP Phones

Policy rule enabled or disabled: Enabled Determines the order (precedence) in which rules are searched: 0 Whether the rule is saved to flash immediately: Save option is enabled Whether messages about flows that match the rule are logged: No How often to check for matching flow messages: 60 seconds Whether to count bytes or packets that match the rule. (Only packets are counted on the OmniSwitch 6800.): packets are counted Whether to send a trap for the rule: enabled (trap sent only on port disable action or User-Port shutdown operation). Whether the flow matching the rule should be accepted or denied: Accept Automatic QoS prioritization refers to prioritizing certain subsets of switch traffic without having to configure a specific QoS policy to do the same for each type of traffic. This functionality is currently available for Network Management System (NMS) traffic and IP phone traffic. Note that automatic prioritization is not supported on the OmniSwitch 6800. The status of automatic NMS and IP phone prioritization for the switch is displayed through the show qos config command. This feature can be used to enable the automatic prioritization of NMS traffic that is destined for the switch. Prioritization maximizes access for NMS traffic and helps to reduce the potential for DoS attacks. Prioritizing NMS traffic destined for the switch helps to maximize NMS access to the switch and reduce the risk of DoS attacks. The following types of traffic are considered NMS traffic: SSH (TCP Port 22) Telnet (TCP Port 23) WebView (HTTP Port 80) SNMP (UDP port 161) Note: When automatic NMS prioritization is enabled, QoS policies that specify priority are not applied to the NMS traffic. Other QoS policies, however, are applied to this type of traffic as usual. If a policy specifies rate limiting, then the policy with the lowest rate limiting value is applied. This feature is used to automatically enable the prioritization of IP phone traffic. The traffic can be assigned a priority value or, if set to trusted mode, the IP phone packet is used to determine the priority. IP phone traffic is identified by examining the source MAC address of the packet received on the port. If the source MAC falls within one of the Alcatel-Lucent ranges below, the Auto-QoS feature automatically sets the priority. The switch automatically trusts the priority of IP phone traffic by default. This means that the priority value contained in packets originating from IP phones is used for the ingress priority. The default priority value configured for the QoS port receiving such traffic is used for the egress priority of the packet. IP phone traffic is detected by examining the source MAC address of the packet to determine if the address falls within the following ranges of IP phone MAC addresses: 00-80-9F-54-xx-xx to 00-80-9F-64-xx-xx 00-80-9F-66-xx-xx to 00-80-9F-6F-xx-xx Third-party devices can be added to this group as well. In addition to prioritizing IP phone traffic, it is also possible to automatically prioritize non-IP phone traffic. This is done by adding up to four MAC addresses or four ranges of MAC addresses to the predefined QoS alaPhone MAC address group. Note that when automatic prioritization of IP phone traffic is enabled, QoS policies that specify priority are not applied to the IP phone traffic. Other QoS policies, however, are applied to this type of traffic as usual. If a policy specifies rate limiting, then the policy with the lowest rate limiting value is applied. A policy (or a policy rule) is made up of a condition and an action. The condition specifies parameters that the switch will examine in incoming flows, such as destination address or Type of Service (ToS) bits. The action specifies what the switch will do with a flow that matches the condition; for example, it may queue the flow with a higher priority, or reset the ToS bits. Policies may be created directly on the switch through the CLI or WebView. Or policies may be created on an external LDAP server via the PolicyView application. The switch makes a distinction between policies created on the switch and policies created on an LDAP server. Note. Polices may be only be modified using the same source used to create them. Policies configured through PolicyView may only be edited through PolicyView. Policies created directly on the switch through the CLI or WebView may only be edited on the switch. Policies may be created through the CLI or WebView, however, to override policies created in PolicyView and vice versa.

QoS Policy All Policies are directly enforced in hardware at wire-rate without performance degradation or performance penalty.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 274 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

QoS Policy implementation

Queues QoS Ports and Queues

Shared Queues

Prioritizing and Queue Mapping

When a flow comes into the switch, the QoS software in the switch checks to see if there are any policies with conditions that match the flow. If there are no policies that match the flow, the flow is accepted or denied based on the global disposition set for the switch. By default, the disposition is accept. If the flow is accepted, it is placed in a default queue on the output port. If there is more than one policy that matches the flow, each policy is applied to the flow as long as there are no conflicts between the policies. If there is a conflict, then the policy with the highest precedence is applied to the flow. Flows must also match all parameters configured in a policy condition. A policy condition must have at least one classification parameter. Once the flow is classified and matched to a policy, the switch enforces the policy by mapping each packet of the flow to the appropriate queue and scheduling it on the output port. There are a total of eight queues per port (two are reserved for internal use only). Traffic is mapped to a queue based on policies, the ToS/ 802.1p value of the packet, and whether the port is trusted or untrusted. There are a total of eight queues per port. Queue parameters may be modified on a port basis. When a flow coming into the switch matches a policy, it is queued based on: Parameters given in the policy action (specified by the policy action command) with either of the following keywords: priority, minimum bandwidth, or maximum bandwidth. Port settings configured through the qos port command. Eight priority queues are available at startup for each port. Flows always share queues; however, when a shared action is specified in policies, the policies will use the same values to implement maximum and minimum bandwidth. Note that the OmniSwitch 6800 also has eight priority queues per port but that two of these queues are reserved for internal use and are not available. QoS prioritizes packets by placing them in a higher priority egress queue. As previously mentioned, there are eight egress queues available for each port. In addition, there are different queuing algorithms available for egressing packets of different priorities. The algorithm used is determined by which servicing mode is active for the egress port. The egress priority of a packet is determined using one of the following methods: 1. If a packet matches a QoS policy rule that sets a priority value, the egress priority for the packet is set using the value specified in the rule. 2. If a packet ingressing on a trusted port does not match any QoS policy rule that sets the priority, then the egress priority for the packet is set using the existing DSCP value (IP packets), the existing 802.1p value (non-IP packets), or the default classification priority value for the port. See Configuring Trusted Ports on page 30-28 for more information. 3. The egress priority for a packet ingressing on a VLAN Stacking port (a trusted port) is set using the existing 802.1p value or configured through an associated VLAN Stacking service. 4. If a packet ingressing on an untrusted port does not match any QoS rule that sets the priority, then the egress priority for the packet is set using the default 802.1p value configured for the port on which the packet was received. See Trusted and Untrusted Ports on page 30-27 for more information. 5. Note that the 802.1p bit for tagged packets ingressing on untrusted ports is set with the default 802.1p value, which is configured using the qos port default 802.1p command. If the packet is untagged, however, then the DSCP bit is set with the default DSCP value, which is configured using the qos port default dscp command. Use the following table to see how packets are directed to the appropriate queues: Priority to Queue Mapping Table: 802.1p/ToS/DSCP/Rule (action)/OS6850&OS9000 Queue/OS6800Queue 0 000xxx 0 0 0 1 001xxx 1 1 0 2 010xxx 2 2 2 3 011xxx 3 3 3 4 100xxx 4 4 4 5 101xxx 5 5 5 6 110xxx 6 6 6 7 111xxx 7 7 7

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 275 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Interaction with other features

Classification

Classifier Engine

Congestion avoidance

QoS Policy Conditions Mixing of Layer-2 & Layer-3 & Layer-4 parameters is supported

QoS policies may be an integral part of configuring other switch features, such as Link Aggregation. In addition, QoS settings may affect other features in the switch; or QoS settings may require that other switch features be configured in a particular way. A summary of related features is given here: Dynamic Link AggregatesPolicies may be used to prioritize dynamic link aggregation groups. 802.1QTagged ports are always trusted, regardless of QoS settings. Mobile PortsMobile ports are always trusted, regardless of QoS settings. LDAP Policy ManagementPolicies may also be configured through the PolicyView application and stored on an attached LDAP server. LDAP policies may only be modified through PolicyView. VLAN Stacking ServiceVLAN Stacking ports are always trusted and default classification is set to 802.1p. QoS policy conditions to match the inner VLAN tag and inner 802.1p tag are available for classifying customer information contained in VLAN Stacking frames. Quarantine Manager and Remediation (QMR)Configuring QMR and QoS inner VLAN or inner 802.1p policies is mutually exclusive. QMR overlays the inner VLAN tag, thus creating a conflict with related QoS policies. This is also true with QMR and VLAN Stacking services. 802.1p classification TOS classification DSCP classification Ethertype classification IP protocol classification ICMP type and code classification The classifier engine responsible for providing QoS is called FFP (Fast Filtering Processing). The FFP is part of the ASIC responsible for functionality of QoS and filtering on the OS6850/OS9000 platforms. There is an FFP per port. Each FFP has 128 entries. The FFP consists of two parts, a FFP mask table and a FFP rule table. There are 16 masks in the mask table. There are 128 rule entries in the rule table. The FFP mask is ANDed with the packet, and the resulting value is compared with the FFP rule value. If the values match, then rule has matched and the appropriate actions are taken on the packet. Total FFP masks: 16 per port Total FFP rules: 128 per port Total number of entries in a group: 128 The congestion avoidance mechanism that is currently supported is built-in the hardware ASIC and managed through our configurable queuing (through the implementation of a threshold-based mechanism per queue ) & de-queuing schemes. There are many options for configuring a condition. But, it all depends on how the user wants the switch to classify traffic for a given policy. The following conditions are supported and may be combined with other conditions and/or actions: IP MulticastAn IP multicast condition is used in IGMP ACLs. The multicast IP is the multicast group address used in the IGMP report packet. Layer-4: o Source TCP port & Destination TCP port o Source UDP port & Destination UDP port o Service & Service group o TCP flags (ECN and CWR are only supported on the OmniSwitch 6800) Layer-3: o IP protocol o Source IP Address & Destination IP Address o Source network group o Destination network group o TOS & DSCP o ICMP Type & ICMP Code o Source IPv6 & Destination IPv6 o Multicast IP & multicast network group o IPv6 traffic o IPv6 next header (NH), IPv6 flow label (FL) Layer-2: o 802.1p and inner 802.1p o Source MAC Address & Destination MAC Address o Source MAC group & Destination MAC group o Source VLAN & inner source VLAN o Ethertype o Destination VLAN (multicast policies only) Layer-1: o Source port & Source port group o Destination port & Destination port group

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 276 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

QoS Policy Condition Combinations

QoS Policy Actions

QoS Policy Actions Combinations

Condition and Action Combinations Rule Precedence

Note. The group options refer to groups of addresses, services, or ports that you configure separately through policy group commands. Rather than creating a separate condition for each address, service, or port, use groups and attach the group to a single condition. More than one condition parameter may be specified. Some condition parameters though are mutually exclusive. Note the following: The 802.1p and source VLAN conditions are the only Layer 2 conditions allowed in combination with Layer 4 conditions. Source and destination parameters can be combined in Layer 2, Layer 3, and Layer 4 conditions. In a given rule, ToS or DSCP may be specified for a condition with priority specified for the action. The Layer 1 destination port condition only applies to bridged traffic, not routed traffic. This restriction does not apply to the OmniSwitch 6800. The IP multicast condition works in combination with Layer 1, Layer 2, and Layer 3 destination conditions only if these conditions specify the device that sends the IGMP report packet. All IPv6 conditions are not supported on OmniSwitch 6800. For more information about IPv6 policies Individual items and their corresponding groups cannot be combined in the same condition. For example, a source IP address cannot be included in a condition with a source IP network group. Layer 2 and Layer 3 rules are always effected on bridged and routed traffic. As a result, combining source or destination TCP/UDP port and IP protocol in a condition is allowed. The Quarantine Manager and Remediation (QMR) application and inner VLAN or inner 802.1p conditions are mutually exclusive. If one of these is active, the other one is not available. Use the policy condition combinations table as specified in the QoS when configuring policy conditions. *IP multicast traffic (not IGMP) is treated as regular traffic; QoS functionality works the same way with this type of traffic, with the exception that the destination port condition does not apply. The CLI prevents you from configuring invalid condition combinations that are never allowed; however, it does allow you to create combinations that are supported in some scenario. For example, you might configure source ip and a destination ip for the same condition. This is a valid combination, but will only be used to classify bridged traffic. A policy action should specify the way traffic should be treated. For example, it might specify a priority for the flow, a source address to rewrite in the IP header, or it may specify that the flow may simply be dropped. More than one action parameter may be specified. Some parameters may be mutually exclusive. In addition, some action parameters are only supported with particular condition parameters. The following actions are supported and may be combined with other actions: ACL (disposition drop) Priority 802.1p ToS/DCSP Stamping and Mapping Maximum Bandwidth Port Redirection (not supported on the OmniSwitch 6800) Link Aggregate Redirection (not supported on the OmniSwitch 6800 and 6850) Port Disable (not supported on the OmniSwitch 6800) Permanent Gateway IP (not supported on the OmniSwitch 6800 and 6850) Mirror (not supported on the OmniSwitch 6800) Use the policy action combinations table as specified in the QoS section when creating policy rules. Note. If you combine priority with 802.1p, dscp, tos, or map, in an action, the priority value is used to prioritize the flow. The CLI prevents you from configuring invalid action combinations that are never allowed; however, it does allow you to create combinations that are supported in some scenario. For example, an action specifying maximum bandwidth may be combined with an action specifying priority. Conditions and actions are combined in policy rules. The CLI prevents you from configuring invalid condition/action combinations that are never allowed. All rules that match a flow will be applied to the flow, unless one of the following rule conflicts occur: Actions specified by one or more rules are in conflict with each other. Conditions specified in one or more contiguous rules are the same. If any of the above items are true, then rule precedence is used to determine which rule to apply to the flow. Precedence is particularly important for Access Control Lists (ACLs).

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 277 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Redirect Policies (Port and Link Aggregate) Two policy action commands are available for configuring QoS redirection policies: policy action redirect port and policy action redirect linkagg. A redirection policy sends traffic that matches the policy to a specific port or link aggregate instead of the originally intended destination. This type of policy may use any condition; the policy action determines which port or link aggregate to which the traffic is sent.

QoS Built-in (default) Policies

QoS Logging

Classifying Bridged Traffic as Layer-3

A redirection policy sends traffic that matches the policy to a specific port or link aggregate instead of the originally intended destination. This type of policy may use any condition; the policy action determines which port or link aggregate to which the traffic is sent. The following policy action commands are used for port and link aggregate redirection: policy action redirect port policy action redirect linkagg Note the following regarding the use and configuration of redirection policies: Redirection policies apply to both bridged and routed traffic. When redirecting routed traffic from VLAN A to VLAN B, the redirect port or link aggregate ID must belong to VLAN B (tagged or default VLAN). Routed packets (from VLAN A to VLAN B) are not modified after they are redirected; the source and MAC address remain the same. In addition, if the redirect port or link aggregate ID is tagged, the redirected packets will have a tag from the ingress VLAN A. If a route exists for the redirected flow, then redirected packets are the final post-routing packets. If a route does not exist for the redirected flow, the flow is not redirected to the specified port or link aggregate ID and is blackholed. As soon as a route is available, the flow is then redirected as specified in the policy. In most cases, a redirected flow will not trigger an update to the routing and ARP tables. When the ARP table is cleared or timed out, port/link aggregate redirection will cease until the ARP table is refreshed. If necessary, create a static route for the flow or assign the redirect port or link aggregate ID to the ingress VLAN (VLAN A) to send packets to the redirect port until a route is available. When redirecting bridged traffic on VLAN A, the redirect port or link aggregate ID must belong to VLAN A (tagged or default VLAN). In the following example, flows destined for UDP port 80 is redirected to switch port 3/2: -> policy condition L4PORTCOND destination udp port 80 -> policy action REDIRECTPORT redirect port 3/2 -> policy rule L4PORTRULE condition L4PORTCOND action REDIRECTPORT In the following example, flows destined for IP address 40.2.70.200 are redirected to link aggregate 10: -> policy condition L4LACOND destination IP 40.2.70.200 -> policy action REDIRECTLA redirect linkagg 10 -> policy rule L4LARULE condition L4LACOND action REDIRECTLA Note that in both examples above, the rules are not active on the switch until the qos apply command is entered on the command line. The switch includes some built-in policies, or default policies, for particular traffic types or situations where traffic does not match any policies. In all cases, the switch accepts the traffic and places it into default queues. Other trafficAny traffic that does not match a policy is accepted or denied based on the global disposition setting on the switch. The global disposition is by default accept. The switch network groupThe switch has a default network group, called switch, that includes all IP addresses configured for the switch itself. This default network group may be used in policies. Policy Port GroupsThe switch supports built-in policy port groups. The groups are called Slot01, Slot02, etc. The QoS software in the switch creates its own log for QoS-specific events. You may modify the number of lines in the log or change the level of detail given in the log. The PolicyView application, which is used to create QoS policies stored on an LDAP server, may query the switch for log events; or log events can be immediately available to the PolicyView application via a CLI command. Log events may also be forwarded to the console in real time. By default, only the most basic QoS information is logged. The type of information that may be logged includes rules, Layer 2 and Layer 3 information, etc. By default the QoS log displays a maximum of 256 lines. In some network configurations you may want to force the switch to classify bridged traffic as routed (Layer 3) traffic. Typically this option is used for QoS filtering. The Layer 3 classification of bridged traffic is no different from the classification of normal Layer 3 routed traffic. Note; that this implementation of QoS always performs Layer 3 classification of bridged traffic; it is not an option. As a result, Layer 3 ACLs are always effected on bridged traffic. The switch may bridge and route traffic to the same destination. Bridged IP packets are prioritized based on ToS, not 802.1p. Note that Layer 3 ACLs are affected on bridged IP traffic and Layer 2 ACLs are affected on routed traffic.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 278 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using Quarantine Manager and Remediation (this features is only supported on the OS6850/9000)

QoS Queuing Schemes MIB Objects: alaQoSConfig alaQoSConfigServicingMode alaQoSConfigLowPriorityWeight alaQoSConfigMediumPriorityWeight alaQoSConfigHighPriorityWeight alaQoSConfigUrgentPriorityWeight

Quarantine Manager and Remediation (QMR) is a switch-based application that interacts with the OmniVista Quarantine Manager (OVQM) application to restrict the network access of quarantined clients and provide a remediation path for such clients to regain their network access. This functionality is driven by OVQM, but the following QMR components are configured through QoS CLI commands: Quarantined MAC address group. This is a reserved QoS MAC address group that contains the MAC addresses of clients that OVQM has quarantined and that are candidates for remediation. The default name of this group is Quarantined, but the user can specify a different name using the qos quarantine Mac-group command. Remediation server and exception subnet group. This is a reserved QoS network group, called alaExceptionSubnet, that is configured with the IP address of a remediation server and any subnets to which a quarantined client is allowed access. The quarantined client is redirected to the remediation server to obtain updates and correct its quarantined state. IP addresses are added to this group using the policy network group command. Remediation server URL. The qos quarantine path command is used to specify a URL for the remediation server. Note that this done in addition to specifying the server IP address in the alaException-Subnet network group. Quarantined Page. When a client is quarantined and a remediation server URL is not configured, QMR can send a Quarantine Page to notify the client of its quarantined state. To enable or disable the sending of a Quarantine Page, use the qos quarantine page command. HTTP proxy port group. This is a known QoS service group, called alaHTTPProxy, that specifies the HTTP port to which quarantined client traffic is redirected for remediation. The default HTTP port used is TCP 80 and TCP 8080. To specify a different HTTP port, use the policy service group command. There are four queuing schemes available for each switch port: one strict priority scheme and three weighted fair queuing (WFQ) schemes. By default the strict priority scheme is used and consists of eight priority queues (SPQ). All eight queues on the port are serviced strictly by priority. Lower priority traffic is dropped in the presence of higher priority traffic. The following WFQ schemes are available: WRRAll queues participate in a weighted round robin scheme. Traffic is serviced from each queue based on the weight of the queue. Note that the WRR scheme is not supported on the OmniSwitch6800, 9700, or 9800. Priority-WRRA type of WRR scheme that combines Strict-Priority queues (zero weight) and WRR queues (non-zero weight). Note that Priority-WRR is the only WFQ scheme supported on the OS6800. DRRAll queues participate in a deficit round robin scheme. Traffic is serviced from each queue based on the weight of the queue. The weight of each of the WRR/DRR queues is a configurable value. Note the following when configuring WRR/DRR queue weights: Weights are configured with a value between 0 and 15. The default weight for each WRR/DRR queue is set to one. Each queue can have a different weight value, and configuring these values in ascending or descending order is not required. When a queue is given a weight of 0, it is configured as a Strict-Priority queue. The CLI requires the user to enter eight queue weights on the OmniSwitch 6800, even though there are only six queues per port available on this switch. The last two weight values entered are ignored. A Priority-WRR scheme is configured by assigning a weight of zero to one or more WRR queues to make them Strict-Priority queues and a non-zero weight to the other WRR queues. Note that a PriorityWRR scheme is the only WFQ scheme that is supported on the OmniSwitch 6800. If there are multiple SPQs configured, the SPQs are scheduled according to their CoS queue number before any WFQs are scheduled. The weight assigned to a WRR queue designates the number of packets the queue sends out before the scheduler moves on to the next queue. For example, a queue weight of 10 sends out 10 packets at each interval. The weight assigned to a DRR queue determines the number of bytes that the queue will service. Each weight value is associated with the following number of bytes: 1=10K, 2=20K, 3=40K, 4=80K, 5=160K, 6=320K, 7=640K, 8=1280K, 9=2560K, 10=5120K, 11=10M, 12=20M, 13=40M, 14=80M, and 15=160M. For example, if the configured DRR queue weights are 1 1 2 2 3 3 4 4, queues 1/2 will service up to 10K each, queues 3/4 will service up to 20K each, queues 5/6 will service up to 40K each, and queues 7/8 will service up to 80K. The higher the queue weight assigned to a DRR queue, the higher the percentage of traffic that is serviced by that queue. For example, a queue with a weight of three will send four times as much traffic as a queue with a weight of one. The queuing scheme selected is the scheme that is used to shape traffic on destination (egress) ports and is referred to as the QoS servicing mode for the port. It is possible to configure a default servicing mode that will apply to all switch ports or configure the servicing mode on an individual port basis. Note that the QoS servicing mode only applies to destination ports because it is at this point where traffic shaping is effected on the flows. In addition, different ports can use different servicing modes.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 279 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Trusted and Untrusted Ports

Untrusted Ports and Packet Priority

Trusted Ports and Packet Priority

Port Groups and Maximum Bandwidth

By default, all ports (except 802.1Q-tagged ports and mobile ports) are untrusted. The trust setting may be configured globally on the switch, or on a per-port basis. By default switch ports are not trusted; that is, they do not recognize 802.1p or ToS/DSCP settings in packets of incoming traffic. If a port is not trusted, the switch sets any 802.1p or ToS/DSCP contained in an incoming packet to the default 802.1p and DSCP values configured for the port. Fixed (non-mobile) ports that are configured for 802.1Q are always trusted, regardless of QoS settings. They cannot be configured as untrusted. Mobile ports are also always trusted; however, mobile ports may or may not accept Q-tagged traffic. Note: Mobile ports cannot be Q-tagged like fixed ports; however, a mobile port will join a tagged VLAN if tagged traffic for that VLAN comes in on the mobile port and the vlan mobile-tag command is enabled for that VLAN. Ports must be both trusted and configured for 802.1Q traffic in order to accept 802.1p traffic. The following applies to ports that are trusted (for 802.1p traffic, the ports must also be able to accept 802.1Q packets): The 802.1p or ToS/DSCP value is preserved. If the incoming 802.1p or ToS/DSCP flow does not match a policy, the switch places the flow into a default queue and prioritizes the flow based on the 802.1p or ToS/DSCP value in the flow. If the incoming 802.1p or ToS/DSCP flow matches a policy, the switch queues the flow based on the policy action. The switch may be set globally so that all ports are trusted. Individual ports may be configured to override the global setting. Whether or not the port is trusted is important if you want to classify traffic with 802.1p bits. If the policy condition specifies 802.1p, the switch must be able to recognize 802.1p bits. Note that the trusted port must also be 802.1Q-tagged. On untrusted ports the priority/queue of the incoming packet is based on the port default 802.1p or TOS/DSCP value. On an untrusted port, by default, all 802.1p, TOS/DSCP values map to queue 0 (if the default 802.1p or TOS/DSCP is 0) to give best effort for the incoming packet. Also, 802.1p and TOS within the packets are set to the port default 802.1p/TOS. Qos port default 802.1p or TOS/DSCP can be changed using CLI command: qos port <slot/port> default [802.1p | DSCP] num Changing the port default 802.1p or ToS/DSCP will impact the port priority: QoS port default 802.1p determines priority for non IP packets QoS port default TOS/DSCP determines priority for IP packets On trusted ports the priority/queue of the incoming packet is based on the ingress packet 802.1p or TOS/DSCP value. Non IP packets are prioritized based on the packet 802.1p value IP packets are prioritized based on the packet TOS/DSCP value Port default 802.1p or ToS/DSCP has no effect on trusted ports. However, an untagged packet will always get the port default 802.1p Maximum bandwidth policies are applied to source (ingress) ports and/or flows. If a port group condition is used in the policy, the bandwidth value specified is shared across all ports in the group. This also applies to flows that involve more than one port. For example, if a policy specifies a maximum bandwidth value of 10M for a port group containing 4 ports, the total bandwidth limit enforced is 10M for all 4 ports. Note the following when configuring ingress maximum bandwidth policies: On an OmniSwitch 6800 switch, bandwidth shaping is done on a per port basis and is not shared across multiple ports. If a policy condition applies to ports that are located on different slots, the maximum bandwidth limit specified is multiplied by the number of slots involved. For example, if a rule is configured to apply a maximum bandwidth limit of 10M to ports 1/1, 3/10, and 4/5, then the actual bandwidth limit enforced for all three ports is 30M. The maximum traffic received by a destination port is also dependant on how many slots are sending traffic to the destination port. However, each slot is restricted to sending only 10k. If a policy condition applies to ports that are all on the same slot, then the maximum bandwidth value specified in the rule is not increased. Ingress bandwidth limiting is done using a granularity of 64K bps. The show active policy rule command displays the number of packets that were dropped because they exceeded the ingress bandwidth limit applied by a maximum bandwidth policy. Although bandwidth policies are applied to ingress ports, it is possible to specify a destination port or destination port group in a bandwidth policy as well. Doing so will effect egress rate limiting/egress policing on the ingress port itself. The limitation of bridged port traffic only on destination ports applies in this case as well on the OmniSwitch 6850 and 9700. The following subsections provide examples of ingress maximum bandwidth policies using both source and destination port groups. Source Port Group Example

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 280 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

QoS Traffic prioritization and bandwidth shaping

Ingress and Egress Bandwidth Shaping

Egress Bandwidth Shaping Egress bandwidth rate limiting per port in 1Mbps increments

The Egress Queue Minimum/Maximum Bandwidth

In the following example, a port group (pgroup) is created with two ports and attached to a policy condition (Ports). A policy action with maximum bandwidth is created (MaxBw). The policy condition and policy action are combined in a policy rule called PortRule. -> Policy port group pgroup 1/1-2 -> Policy condition Ports source port group pgroup -> Policy action MaxBw maximum bandwidth 10k -> Policy rule Port Rule condition Ports action MaxBw In this example, if both ports 1 and 2 are active ports, the 10000 bps maximum bandwidth is shared by both ports. In other words, maximum bandwidth policies for port groups define a maximum bandwidth value that is a total bandwidth amount for all ports, not an amount for each port. Destination Port Group Example In the following example, a port group (pgroup2) is created with several ports and attached to a policy condition (Ports2). A policy action with maximum bandwidth is created (MaxBw). The policy condition and policy action are combined in a policy rule called PortRule2. -> Policy port group pgroup2 1/1 1/25 2/1 -> Policy condition Ports2 destination port group pgroup2 -> Policy action MaxBw maximum bandwidth 10k -> Policy rule PortRule2 condition Ports2 action MaxBw In this example, the specified ports for pgroup2 span across two slots. As a result, the maximum bandwidth limit specified by the policy action is increased to 20K for all of the ports. The bandwidth limit is increased by multiplying the number of slots by the specified bandwidth value. Traffic prioritization and bandwidth shaping are the most common types of QoS policies. For these policies, any condition may be created; the policy action indicates how the traffic should be prioritized or how the bandwidth should be shaped. QoS Traffic Prioritization Example: -> Policy condition ip_traffic source ip 10.10.4.0 mask 255.255.255.0 -> Policy action high priority 7 -> Policy rule rule1 condition ip_traffic action high The rule is not active on the switch until the qos apply command is entered on the command line. When the rule is activated, any flows coming into the switch from 10.10.4.0 will be given the highest priority. QoS Traffic Shaping Example: -> Policy condition ip_traffic2 source ip 10.10.5.3 -> Policy action flowShape maximum bandwidth 1k -> Policy rule rule2 condition traffic2 action flowShape Note that the bandwidth may be specified in abbreviated units, in this case, 1k. The rule is not active on the switch until the qos apply command is entered. When the rule is activated, any flows coming into the switch from source IP address 10.10.5.3 will be queued with no more than 1k of bandwidth. Bandwidth shaping is configured on a per port basis by specifying a maximum bandwidth value for ingress and egress ports. However, on the OmniSwitch 6850 and 9000 switches, configuring maximum egress bandwidth is supported on a per COS queue basis for each port. Also note that configuring the maximum bandwidth for ingress ports is not supported on the OmniSwitch 6800. Shaping limits the bandwidth on the egress. Shaping implies that the shaping function slows down the rate at which the egress port sends the packets. Egress shaping is on a per egress port basis, the granularity is 1Mbps. Egress Max Bandwidth is achieved by the CLI command: qos port <slot/port> Max bandwidth <num><num [num]><K (kilo)|M (mega)|G (giga)|T (tera)> This restricts the maximum bandwidth of the port at the egress. Limitation: The egress bandwidth shaping is only on a per port basis; the system cannot do a per flow basis egress bandwidth shaping. Configuring a minimum and maximum bandwidth value for each of the eight egress port queues is allowed on the OmniSwitch 6850 and 9000 but is not supported on the OmniSwitch 6800. By default the bandwidth values are set to zero, which means best effort for the minimum bandwidth and port speed for the maximum bandwidth. To configure the bandwidth values use the qos port q minbw maxbw command. For example, the following command sets the minimum and maximum bandwidth for queue 8 on port 2/10 to 2k and 10k: -> qos port 2/10 q8 minbw 2k q8 maxbw 10k Note that specifying both the minimum and maximum bandwidth value is allowed on the same command line. Configuring the bandwidth values for different queues requires a separate command for each queue.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 281 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Bandwidth Shaping

Ingress Max Bandwidth Policing Ingress bandwidth rate limiting per port/flow in 64k increments

Bandwidth shaping is configured on a per port basis. Bandwidth policing is applied using QoS policies. QoS supports configuring maximum bandwidth on ingress and egress ports. However, on the OmniSwitch 6850 and 9000 switches, configuring minimum and maximum egress bandwidth is supported on a per COS queue basis for each port. To limit the ingress or egress bandwidth for a QoS port, use the qos port maximum egress-bandwidth or qos port maximum ingress-bandwidth commands. For example, -> qos port 1/1 maximum egress-bandwidth 10M -> qos port 1/1 maximum ingress-bandwidth 5M Note the following when configuring the ingress or egress bandwidth limit for a port: Maximum bandwidth limiting is done using a granularity of 64K bps. Any value specified that is not a multiple of 64K is rounded up to the next highest multiple of 64K. The maximum bandwidth value cannot exceed the maximum bandwidth of the interface type associated with the port. Modifying the maximum bandwidth is most useful for low-bandwidth links. The bandwidth limit configured using the qos port maximum egress-bandwidth command takes precedence over an egress queue limit configured on the same port. Configuring the maximum ingress bandwidth value is not supported on an OmniSwitch 6800. Policing limits the bandwidth on the ingress. Policing implies dropping the traffic when the programmed rate is exceeded. Policing is on a per flow basis. The flow specification can specify a destination port, but the policing is done on a per ingress port basis. The granularity is 64kpbs. Ingress maximum bandwidth is achieved via policies specifying maximum bandwidth. The maximum bandwidth is on a per ingress port basis. Example: Ingress port rate limiting Policy condition c1 source port 1/1 Policy action a1 maximum bandwidth 10M Policy rule r1 condition c1 action a1 All traffic originating on port 1/1 are shaped to 10M A mirroring policy sends a copy of ingress, egress, or both ingress and egress packets that match the policy condition to a specific port. This type of policy may use any condition; the mirror policy action determines the type of traffic to mirror and the port on which the mirrored traffic is received. The policy action mirror command is used to configure mirror-to-port (MTP) action for the policy. For example, the following policy mirrors ingress packets to port 1/10: -> policy condition c1 source ip 192.168.20.1 -> policy action a1 mirror ingress 1/10 -> policy rule r1 condition c1 action a1 -> qos apply When the above rule is activated, any flows coming into the switch from source IP address 192.168.20.1 are mirrored to port 1/10. It is also possible to combine the MTP action with other actions. For example: -> policy condition c1 source ip 192.168.20.1 -> policy action a1 mirror ingress 1/10 disposition drop -> policy rule r1 condition c1 action a1 -> qos apply This policy rule example combines the MTP action with the drop action. As a result, this rule drops ingress traffic with a source IP of 192.168.20.1, but the mirrored traffic from this source is not dropped and is forwarded to port 1/10. Note the following regarding the use and configuration of mirroring policies: Only one policy-based MTP session is supported at any given time. As a result, all mirroring policies should specify the same destination port. In addition to one policy-based MTP session, the switch can support one port-based mirroring session, one remote port mirroring session, and one port monitoring session all running at the same time. Policy based mirroring and the port-based mirroring feature can run simultaneously on the same port. However, policy based mirroring is not supported on the OmniSwitch 6800. Rule precedence is applied to all mirroring policies that are configured for the same switch ASIC. If traffic matches a mirror rule on one ASIC with a lower precedence than a non-mirroring rule on a different ASIC, the traffic is mirrored in addition to the actions specified by the higher precedence rule.

Policy Based Mirroring (this features is only supported on the OS6850/9000)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 282 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

QoS ICMP Policy support

QoS Mapping Support QoS mapping: 802.1p to 802.1p & ToS & DSCP, ToS to ToS & 802.1p & DSCP, DSCP to DSCP & 802.1p & ToS

802.1p and ToS/DSCP Marking and Mapping support

802.1p/TOS/DSCP Stamping/Mapping policies QoS mapping: 802.1p to 802.1p & ToS & DSCP, ToS to ToS & 802.1p & DSCP, DSCP to DSCP & 802.1p & ToS

Policies may be configured for ICMP on a global basis on the switch. ICMP policies may be used for security (for example, to drop traffic from the ICMP blaster virus). In the following example, a condition called icmpCondition is created with no other condition parameters: -> Policy condition icmpCondition ip protocol 1 -> Policy action icmpAction disposition deny -> Policy rule icmpRule condition icmpCondition action icmpAction This policy (icmpRule) drops all ICMP traffic. To limit the dropped traffic to ICMP echo requests (pings) and/or replies, use the policy condition icmptype to specify the appropriate condition. For example: -> Policy condition echo icmptype 8 -> Policy condition reply icmptype 0 Map groups are used to map 802.1p, ToS, or DSCP values to different values. The following mapping scenarios are supported: 802.1p to 802.1p, based on Layer 2, Layer 3, and Layer 4 parameters and source/destination slot/port. In addition, 802.1p classification can trigger this action. ToS or DSCP to 802.1p based on Layer 3 and Layer 4 parameters and source/destination slot/port. In addition ToS or DSCP classification can trigger this action. Note. Map groups are associated with a policy action. 802.1p values may be mapped to different 802.lp values on an individual basis or by using a map group. In addition, ToS or DSCP values may be mapped to 802.1p on a case-by-case basis or via a map group. (Note that any other mapping combination is not supported.) Note the following: Priority for the flow is based on the policy action. The value specified for 802.1p, ToS, DSCP, or the map group would determine how the flow is queued. The port on which the flow arrives (the ingress port) must be a trusted port. In this example, a policy rule (marking) is set up to mark flows from 10.10.3.0 with an 802.1p value of 5: -> Policy condition my_condition source ip 10.10.3.0 mask 255.255.255.0 -> Policy action my_action 802.1p 5 -> Policy rule marking condition my_condition action my_action In the next example, the policy map group command specifies a group of values that should be mapped; the policy action map command specifies what should be mapped (802.1p to 802.1p, ToS/DSCP to 802.1p) and the mapping group that should be used. Here, traffic from two different subnets must be mapped to 802.1p values in a network called Network C. A map group (tosGroup) is created with mapping values. -> Policy map group tos_group 1-4:4 5-7:7 -> Policy condition SubnetA source ip 10.10.5.0 mask 255.255.255.0 -> Policy condition SubnetB source ip 12.12.2.0 mask 255.255.255.0 -> Policy action map_action map tos to 802.1p using tos_group The map_action specifies that ToS values will be mapped to 802.1p with the values specified in tos_group. With these conditions and action set up, two policy rules can be configured for mapping Subnet A and Subnet B to the ToS network: -> Policy rule RuleA condition SubnetA action map_action -> Policy rule RuleB condition SubnetB action map_action Regardless of the condition or classification, the following stamping/mapping actions are allowed Stamp 802.1p Stamp TOS (precedence) Stamp DSCP Stamp 802.1p and TOS/DSCP Map 802.1p to 802.1p Map 802.1p to TOS Map 802.1p to DSCP Map ToS to 802.1p Map ToS to TOS Map ToS to DSCP Map DSCP to 802.1p Map DSCP to TOS Map DSCP to DSCP Stamping/mapping policies change the internal priority of the packets: Priority is always based on the new 802.1p or TOS/DSCP stamped/mapped value Stamp/map TOS/DSCP also gives priority for non IP packets matching the rule Mapping rules takes one FFP entry for each entry in the map group If both 802.1p and TOS/DSCP are stamped in a policy rule, priority is based on the stamped TOS/DSCP value

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 283 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Policy Based Routing

Policy Based Routing (Permanent Mode)

Deploying VoIP in a converged Alcatel.Lucent Network

VoIP treatment

QoS & VoIP support

Policy Based Routing (PBR) allows a network administrator to define QoS policies that will override the normal routing mechanism for traffic matching the policy condition. Note. When a PBR QoS rule is applied to the configuration, it is applied to the entire switch, unless you specify a built-in port group in the policy condition. Policy Based Routing may be used to redirect traffic to a particular gateway based on source or destination IP address, source or destination network group, source or destination TCP/UDP port, a service or service group, IP protocol, or built-in source port group. Traffic may be redirected to a particular gateway regardless of what routes are listed in the routing table. Note that the gateway address does not have to be on a directly connected VLAN; the address may be on any network that is learned by the switch. Note. If the routing table has a default route of 0.0.0.0, traffic matching a PBR policy will be redirected to the route specified in the policy. Policy Based Routing may be used to redirect untrusted traffic to a firewall. In this case, note that reply packets will be not be allowed back through the firewall. Policy Based Routing may be used to redirect traffic to a particular gateway based on source or destination IP address, source or destination network group, source or destination TCP/UDP port, a service or service group, IP protocol, or built-in source port group. Traffic may be redirected to a particular gateway regardless of what routes are listed in the routing table. Note that the gateway address does not have to be on a directly connected VLAN; the address may be on any network that is learned by the switch. Today's business needs depend on network communications that allow the expansion of business options and facilities in the future. The groundbreaking OmniSwitch 9000 family and Alcatel.Lucent Enterprise OmniPCX & IP-Phone products target this future networking and business solution. Alcatel.Lucent recognized that the evolution of networking was at a turning point and focused on the concept of mission critical networking that could support the convergence technology emerging in its voice solutions to become, essentially, the central nervous system of your business. The OmniSwitch 9000 family is a new range of data infrastructure switches that spans the core, edge and desktop of networking. The design combines Alcatel.Lucent's experience and expertise building carrier and enterprise network equipment with all of the company's cutting-edge convergence technologies. It relates to Alcatel.Lucent's vision of future e-Business solutions: (1) availability, (2) security, (3) intelligence and (4) manageability. These values are both essential to successful modern business and fundamental to appropriate new technology. The OmniSwitch 9000 offers carrier-class availability throughout the network to deliver the infrastructure mandatory for IP telephony and mission-critical applications. A multi-layered approach to security is offered, securing traffic to, through and between switch nodes, ensuring violation of your business traffic and privacy is near impossible. Intelligence mandates that all switching decisions are distributed and performed at wire-rate. Alcatel.Lucent's implementation is wire-rate into, through the backplane, and out all network interfaces without performance bottlenecks. Manageability involves both networking features and management system features, thus features such as OneTouch mean that complex QoS policies are implemented consistently with a simple point-and-click interface. Using QoS, a network administrator can gain more control over networks where different types of traffic (or flows) are in use or where network congestion is high. Preferential treatment may be given to individual flows as required. Voice over IP (VoIP) traffic or mission-critical data may be marked as priority traffic and/or given more bandwidth on the link. QoS can also prevent large flows, such as a video stream, from consuming all the links bandwidth. Using QoS, a network administrator can decide which traffic needs preferential treatment, and which traffic can be adequately served with best effort. QoS is implemented on the switch through the use of user-defined policies. The proposed Alcatel.Lucent infrastructure can support standard-based IP-Phones and IP-telephony applications. The OS9000 platforms support 802.1Q/p. In a dedicated VLAN scenario VOIP traffic is separated from data traffic on the switch. However, traffic will need to be prioritized on trunk links. This can be accomplished by prioritizing traffic by source / destination mac address, source / destination IP, or protocol types. In a shared environment, traffic can be prioritized through the switch and through the network via TOS or DiffServ.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 284 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Server Load Balancing

Typical RFP questions

Alcatel-Lucents Server Load Balancing (SLB) software provides a method to logically manage a group of physical servers sharing the same content (known as a server farm) as one large virtual server (known as an SLB cluster). SLB clusters are identified and accessed at Layer 3 by the use of Virtual IP (VIP) addresses. OmniSwitch 6850/9000 switches operate at wire speed to process client requests addressed to the VIP of an SLB cluster and send them to the physical servers within the cluster. Using SLB clusters can provide cost savings (costly hardware upgrades can be delayed or avoided), scalability (as the demands on your server farm grow you can add additional physical servers), reliability (if one physical server goes down the remaining servers can handle the remaining workload), and flexibility (you can tailor workload requirements individually to servers within a cluster). Notes. SLB is supported on OmniSwitch 6850 and 9000 switches (Release 6.1.3r01) but not on OmniSwitch 6800 Series switches. You can also configure and monitor Server Load Balancing with WebView, AlcatelLucents embedded web-based device management application. WebView is an interactive and easy-to-use GUI that can be launched from OmniVista or a web browser. Server Load Balancing Specifications: Maximum number of clusters: 16 Maximum number of physical servers: 75 Layer-3 classification: Source IP address/Destination IP address pairs Server health checking: Ping, link checks High availability support: Hardware-based failover, VRRP, Chassis Management Module (CMM) redundancy Networking protocols supported: Virtual IP (VIP) addresses Ping period range: 0 to 3600 seconds Ping timeout range: 0 to 1000 times the value of the ping period Ping retries: 0 to 255 Maximum number of probes on a switch: 20 Probe timeout range: 1 to 3600000seconds Probe period range: 0 to 3600 Probe port range: 0 to 65535 Probe retry range: 0 to 255 Probe status range: 0 to 4294967295 Question: Can Server load balancing work across multiple switches; i.e., define a cluster so that it exists across multiple switches? Answer: 1) Can the servers be bridged across switches on the local vlan? The servers must be on a local vlan of the switch. This would mean that the packets can be bridged to other switches. Whatever the vlan encompasses. 2) The second question is more complicated: Can the cluster be configured on multiple switches and service the same servers in the same way? Theoretically, if all switches are configured the same in an SLB way (same clusters, servers, etc.), the hash for distributing the servers should be the same. Since the hashing algorithm is based on the addresses contained in the packet, they should map to the same servers. This would mean if packets for a flow arrive on different switches (i.e. ECMP connection) they would be forwarded to the same server. This configuration has not been verified, though, it seems like it would work.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 285 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IP Multicast Switching (IPMS)

IP Multicast Switching is a one-to-many communication technique employed by emerging applications such as video distribution, news feeds, conferencing, netcasting, and resource discovery (OSPF, RIP2, BOOTP). Unlike unicast, which sends one packet per destination, multicast sends one packet to all devices in any sub-network that has at least one device requesting the multicast traffic. Multicast switching also requires much less bandwidth than unicast techniques and broadcast techniques since the source hosts only send one data stream to the ports on which destination hosts that request it are attached. Destination hosts signal their intent to receive a specific multicast stream by sending a request to do so to a nearby switch using Internet Group Management Protocol (IGMP). The switch then learns on which ports multicast group subscribers are attached and can intelligently deliver traffic only to the respective ports. This mechanism is often referred to as IGMP snooping (or IGMP gleaning). Alcatel-Lucents implementation of IGMP snooping is called IP Multicast Switching (IPMS). IPMS allow OmniSwitch 6850 Series switches to efficiently deliver multicast traffic in hardware at wire speed. Both IGMP version 3 (IGMPv3), which handles forwarding by source IP address and IP multicast destination, and IGMP version 2 (IGMPv2), which handles forwarding by IP multicast destination address only, are supported. IPMS is supported on IPv4 and IPv6 (MLD) on the OmniSwitch 6850 Series and OmniSwitch 9000 Series. The OmniSwitch 6800 Series only supports IPMS for IPv4. Note. You can also configure and monitor IPMS with WebView, Alcatel-Lucents embedded webbased device management application. WebView is an interactive and easy-to-use GUI that can be launched from OmniVista or a web browser. Both IGMP version 3 (IGMPv3), which handles forwarding by source IP address and IP multicast destination, and IGMP version 2 (IGMPv2), which handles forwarding by IP multicast destination address only, are supported. IPMS Specifications: RFCs Supported: RFC 1112 Host Extensions for IP Multicasting RFC 2236 Internet Group Management Protocol, Version 2 RFC 2933 Internet Group Management Protocol MIB RFC 3376 Internet Group Management Protocol, Version 3 IETF Internet-Drafts Supported: Draft-ietf-magma-snoop Considerations for IGMP and MLD Snooping Switches IGMP Query Interval: 1 to 65535 seconds IGMP Router Timeout: 1 to 65535 seconds IGMP Source Timeout: 1 to 65535 seconds IGMP Query Response Interval: 1 to 65535 in tenths of seconds IGMP Last Member Query Interval: 1 to 65535 in tenths of seconds IPv6MS Specifications: RFCs Supported: RFC 2710 Multicast Listener Discovery for IPv6 RFC 3810 Multicast Listener Discovery Version 2 for IPv6 RFC 3019 IPv6 MIB for Multicast Listener Discovery Protocol IETF Internet-Drafts Supported: Draft-ietf-magma-snoop Considerations for IGMP and MLD Snooping Switches MLD Query Interval: 1 to 65535 seconds MLD Router Timeout: 1 to 65535 seconds MLD Source Timeout: 1 to 65535 seconds MLD Query Response Interval: 1 to 65535 in milliseconds MLD Last Member Query Interval: 1 to 65535 in milliseconds IP multicast Proxying and configuring the IGMP and MLD unsolicited report interval are now available with this implementation of IPMS. Proxying enables the aggregation of IGMP and MLD group membership information and the reduction in reporting queries. The unsolicited report interval refers to the time period in which to proxy any changed IGMP membership state. Static multicast MAC addresses are used to send traffic intended for a single destination multicast MAC address to multiple switch ports within a given VLAN. A static multicast address is assigned to one or more switch ports for a given VLAN. The ports associated with the multicast address are then identified as egress ports. When traffic received on ports within the same VLAN is destined for the multicast address, the traffic is forwarded on the egress ports that are associated with the multicast address. One of the benefits of using static multicast addresses is that multicast traffic is switched in hardware and no longer subject to flood limits on broadcast traffic.

IP Multicast Switching (IPMS) - Proxying

L2 Static Multicast Addresses

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 286 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

MLD

IGMP

IP Multicast Switching and Routing (IPMSR)

Multicast Address Boundaries

IP Multicast VLAN

MLD is used by IPv6 systems (hosts and routers) to report their IPv6 multicast group memberships to any neighboring multicast routers. MLD Version 1 (MLDv1) handles forwarding by IPv6 multicast destination addresses only. MLD Version 2 (MLDv2) handles forwarding by source IPv6 addresses and IPv6 multicast destination addresses. The OmniSwitch 6850 switch supports MLDv1 and MLDv2. MLDv2 uses source filtering and reports multicast memberships to neighboring routers by sending membership reports. MLDv2 also supports Source Specific Multicast (SSM) by allowing hosts to report interest in receiving packets only from specific source addresses or from all but specific source addresses. IGMP is used by IPv4 systems (hosts and routers) to report their IP multicast group memberships to any neighboring multicast routers. IGMP version 2 (IGMPv2) handles forwarding by IP multicast destination address only. IGMP version 3 (IGMPv3) handles forwarding by source IP address and IP multicast destination address. OmniSwitch 6850 Series switches support IGMPv2 and IGMPv3. In IGMPv2, each membership report contains only one multicast group. In IGMPv3, membership reports contain many multicast groups up to the Maximum Transmission Unit (MTU) size of the interface. IGMPv3 uses source filtering and reports multicast memberships to neighboring routers by sending membership reports. IGMPv3 also supports Source Specific Multicast (SSM) by allowing hosts to report interest in receiving packets only from specific source addresses or from all but specific source addresses. Note. It should be noted that in the current release SSM packet forwarding is not done between ports in the same VLAN. However, SSM forwarding between different VLANs (routing) is supported. In addition, the current implementation of IGMPv3 and SSM only forwards packets to a list of included sources for a given multicast destination. Exclude list forwarding is not supported, as it is not a requirement for SSM, and specifically Protocol Independent MulticastSource Specific Multicast (PIM-SSM). IP multicast routing can be used for IP Multicast Switching and Routing (IPMSR). IP multicast routing is a way of controlling multicast traffic across networks. The IP multicast router discovers which networks want to receive multicast traffic by sending out Internet Group Management Protocol (IGMP) queries and receiving IGMP reports from attached networks. The IGMP reports signal that users want to join a multicast group. The IPv6 multicast router discovers multicast listeners by sending out Multicast Listener Discovery (MLD) Protocol queries and receiving MLD reports from attached networks. The MLD reports signal that users want to join a IPv6 multicast group. If there is more than one IP multicast router in the network, the router with the lowest IP address is elected as the querier router, which is responsible for querying the sub-network for group members. The IP multicast routing package provides the following two separate protocols: Protocol Independent Multicast Sparse Mode (PIM-SM) and Dense Mode (PIM-DM) Distance Vector Multicast Routing Protocol (DVMRP) The multicast routing protocols build and maintain a multicast routing database. The multicast routing protocols forward multicast traffic to networks that have requested group membership to a specific multicast group. IPMS uses decisions made by the routing protocols and forwards multicast traffic to ports that request group membership. Multicast boundaries confine scoped multicast addresses to a particular domain. Confining scoped addresses helps to ensure that multicast traffic passed within a multicast domain does not conflict with multicast users outside the domain. Multicast Boundary Specifications: RFCs Supported: 2365Administratively Scoped IP Multicast 2932IPv4 Multicast Routing MIB Maximum Multicast Flows per switch: 1,021 (with hardware routing; see note below) Up to 1,021 simultaneous multicast flows are supported. There is no hard limit on the number of static multicast groups that can be configured, but if you try to send traffic to the entire group at the same time the limit is still 1,021 hardware flows. A flow is defined as a source-group pair. In the case all hardware entries are exhausted, the IPMS will not perform software forwarding. IP multicast tunneling is performed in software. Valid Scoped Address Range: 239.0.0.0 to 239.255.255.255 IP Multicast VLAN involves the creation of separate, dedicated VLANs constructed specifically for multicast traffic distribution. These distribution VLANs connect to the nearest multicast router and support multicast traffic only. The IP Multicast feature works in both the enterprise environment and the VLAN Stacking environment. The ports are separately classified as VLAN stacking ports or as legacy ports (Fixed ports/Tagged Ports). To ascertain that data flow is limited to either the VLAN Stacking domain or the enterprise domain, VLAN Stacking ports must be members of only the VLAN Stacking VLANs, while the normal legacy ports must be members of only enterprise mode VLANs. Release 6.3.1 adds support for multiple sender ports.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 287 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IP Multicast VLAN Overview

Multicast Routing

DVMRP is a dense-mode multicast routing protocol DVMRPv3.255 is supported The DVMRP implementation is performed in Hardware. The DVMRP implementation over 802.1Q tagging link is supported and it is also performed in Hardware.

The IP Multicast VLAN (IPMV) feature helps service providers to create separate dedicated VLANs to distribute multicast traffic. Service providers have to separate users using these VLANs. This should be done along with the distribution of broadcast media through IP Multicast across these VLANs without a router in the distribution L2 switch. To achieve this, the distribution L2 switch needs to perform IGMP snooping (i.e., allow the switch to "listen in" on the IGMP conversation between hosts and routers) as well as distribute multicast traffic from one multicast distribution VLAN to many customer ports. A distribution multicast VLAN that switches into customer ports is invisible to the customer to avoid packet duplication across the trunk. Furthermore, some service providers use QinQ on the provider ports to tag the multicast distribution VLAN with a distinct outer VLAN tag. The customer ports can either be tagged or untagged. However, the multicast traffic always needs to be tagged. This process requires one or more separate multicast distribution VLANs. These distribution VLANs connect to the nearest multicast router and are used for multicast traffic only. The multicast traffic will only flow from the distribution VLAN to the customer VLAN. Customer-generated multicast traffic will flow only through the customer VLANs so that the multicast router can control the distribution of such traffic. The IPMV feature works in both the Enterprise and the VLAN Stacking environment. The ports are classified as VLAN Stacking ports and Legacy ports (fixed ports/tagged ports). To ascertain that data flow is limited to either the VLAN Stacking domain or the Enterprise domain, VLAN Stacking ports must be members of VLAN Stacking VLANs only, while the normal Legacy ports must be members of VLANs configured in the Enterprise mode only. It is not possible to change an IPMVLAN from one mode to another. An IPMVLAN configured in a specific mode must first be deleted, then re-created in the other mode. The following table lists IPMVLAN specifications. IEEE Standards Supported: 802.1ad/D6.0 Standard for Local and Metropolitan Area Networks Virtual Bridged Local Area Networks - Amendment 4: Provider Bridges Maximum Number of IP Multicast VLAN IDs: 256 (The valid range is 2 through 4094) VLAN Stacking Functionality Modes: VLAN Stacking mode Enterprise mode The following table lists IPMVLAN default values. Administrative Status: Enabled The OmniSwitch 6850 Series supports multicast routing and includes configuration options for multicast address boundaries, the Distance Vector Multicast Routing Protocol (DVMRP), and Protocol-Independent Multicast (PIM). Multicast traffic consists of a data stream that originates from a single source and is sent to hosts that have subscribed to that stream. Live video broadcasts; video conferencing, corporate communications, distance learning, and distribution of software, stock quotes, and news services are examples of multicast traffic. Multicast traffic is distinguished from unicast traffic and broadcast traffic. Multicast boundaries confine scoped multicast addresses to a particular domain. Confining scoped addresses helps to ensure that multicast traffic passed within a multicast domain does not conflict with multicast users outside the domain. Distance Vector Multicast Routing Protocol (DVMRP) is a dense-mode multicast routing protocol designed to assist routers in propagating IP multicast traffic through a network. DVMRP works by building per-source broadcast trees based on routing exchanges, then dynamically creating per-source, group multicast delivery trees by pruning the sources truncated broadcast tree. Distance Vector Multicast Routing Protocol (DVMRP) is a dense-mode multicast routing protocol. DVMRPwhich is essentially a broadcast and prune routing protocolis designed to assist routers in propagating IP multicast traffic through a network. DVMRP works by building per-source broadcast trees based on routing exchanges, then dynamically creating per-source, group multicast delivery trees by pruning the sources truncated broadcast tree. DVMRP Specifications: RFCs Supported: 2667IP Tunnel MIB IETF Internet-Drafts Supported: Distance-Vector Multicast Routing Protocol MIB draft-ietf-idmrdvmrp-v3-11.txt DVMRP Version Supported: DVMRPv3.255 DVMRP Attributes Supported: Reverse Path Multicasting, Neighbor Discovery, Multicast Source Location, Route Report Messages, Distance metrics, Dependent Downstream Routers, Poison Reverse, Pruning, Grafting, DVMRP Tunnels DVMRP Timers Supported: Flash update interval, Graft retransmissions, Neighbor probe interval, Neighbor timeout, Prune lifetime, Prune retransmission, Route report interval, Route holddown, Route expiration timeout Range for Interface Distance Metrics: 1 to 31 Range for Tunnel TTL Value: 0 to 255 Multicast Protocols per Interface: 1 (e.g., you cannot enable both PIM-SM and DVMRP on the same IP interface)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 288 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Protocol-Independent Multicast (PIM) PIM-SMv2 and PIM-DM are supported The PIM-SM implementation is performed in Hardware. The PIM-SM implementation over 802.1Q tagging link is supported and it is also performed in Hardware. The PIM-DM support

Protocol-Independent Multicast (PIM) is an IP multicast routing protocol that uses routing information provided by unicast routing protocols, such as RIP and OSPF. Sparse Mode PIM (PIM-SM) contrasts with flood-and-prune dense mode multicast protocols, such as DVMRP and PIM Dense Mode (PIMDM), in that multicast forwarding in PIM-SM is initiated only via specific requests. Downstream routers must explicitly join PIM-SM distribution trees in order to receive multicast streams on behalf of directly connected receivers or other downstream PIM-SM routers. This paradigm of receiverinitiated forwarding makes PIM-SM ideal for network environments where receiver groups are thinly populated and bandwidth conservation is a concern, such as in Wide Area Networks (WANs). PIMDM packets are transmitted on the same socket as PIM-SM packets as both use the same protocol and message format. Unlike PIM-SM, in PIM-DM there are no periodic joins transmitted; only explicitly triggered prunes and grafts. In PIM-DM, unlike PIM-SM, there is no Rendezvous Point (RP). PIM-SM Specifications: RFCs Supported: 2362Protocol Independent Multicast-Sparse Mode (PIM-SM) Protocol Specification 2934Protocol Independent Multicast MIB for Ipv4 2932Ipv4 Multicast Routing MIB 3973Protocol Independent Multicast-Dense Mode (PIM-DM) 3376Internet Group Management Protocol Internet Drafts Supported: Draft-ietf-pim-sm-v2-new-05.txtProtocol Independent Multicast Sparse Mode PIM-SM Draft-ietf-pim-mib-v2-00.txtProtocol Independent Multicast MIB Draft-ietf-pim-sm-bsr-02.txtBootstrap Router (BSR) Mechanism for PIM Sparse Mode PIM-SM Version Supported: PIM-SMv2 PIM-SM Attributes Supported: Shared trees (also referred to as RP trees), Designated Routers (DRs), Bootstrap Routers (BSRs), Candidate Bootstrap Routers (C-BSRs), Rendezvous Points (RPs), Candidate Rendezvous Points (C-RPs) PIM-SM Timers Supported: C-RP expiry, C-RP holdtime, C-RP advertisement, Join/Prune, Probe, Register suppression, Hello, Expiry, Assert, Neighbor liveness Maximum Rendezvous Point (RP) routers allowed in a PIM-SM domain: 100 (default value is 32) Maximum Bootstrap Routers (BSRs) allowed in a PIM-SM domain: 1 Multicast Protocols per Interface: 1 (e.g., you cannot enable both PIM-SM and DVMRP on the same IP interface)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 289 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Protocol Independent Multicast (PIM) Source-Specific Multicast (PIM-SSM) Support

PIM PIM-SSM & PIM-DM

Protocol Independent Multicast Source-Specific Multicast (PIM-SSM) is a highly efficient extension of PIM. SSM, using an explicit channel subscription model, allows receivers to receive multicast traffic directly from the source; an RP tree model is not used. In other words, a Shortest Path Tree (SPT) between the receiver and the source is created without the use of a Rendezvous Point (RP). By default, PIM-SM software supports Source-Specific Multicast. No additional user configuration is required. PIM-SSM is automatically enabled and operational as long as PIM-SM is loaded and IGMPv3 source-specific joins are received within the SSM address range. PIM-SSM Specifications: RFCs Supported: 3569An Overview of Source-Specific Multicast (SSM) Internet Drafts Supported: Draft-ietf-pim-sm-v2-new-05.txtProtocol Independent Multicast Sparse Mode (PIM-SM) Draft-ietf-ssm-arch-04.txtAn Overview of Source-Specific Multicast (SSM) Valid SSM Address Range: 232.0.0.0 to 232.255.255.255 PIM-SSM Protocol-Independent Multicast (PIM) is an IP multicast routing protocol that uses routing information provided by unicast routing protocols, such as RIP and OSPF. PIM is protocol-independent because it does not rely on any particular unicast routing protocol. Sparse mode PIM (PIM-SM) contrasts with flood-and-prune dense mode multicast protocols, such as DVMRP and PIM Dense Mode (PIM-DM) in that multicast forwarding in PIM-SM is initiated only via specific requests, referred to as Join messages. PIM-DM PIM-DM for IPv4 is now supported with the 6.1.3.R01 release. PIM-DM packets are transmitted on the same socket as PIM-SM packets, as both use the same protocol and message format. Unlike PIMSM, in PIM-DM there are no periodic joins transmitted; only explicitly triggered prunes and grafts. In addition, there is no Rendezvous Point (RP) in PIM-DM. Protocol Independent Multicast Source-Specific Multicast (PIM-SSM) is a highly-efficient extension of PIM. SSM, using an explicit channel subscription model, allows receivers to receive multicast traffic directly from the source; an RP tree model is not used. In other words, a Shortest Path Tree (SPT) between the receiver and the source is created without the use of a Rendezvous Point (RP). Note: Release 6.3.1 adds support for IPv6 via a new set of CLI commands and SNMP MIBs. Existing PIM configurations will be converted to the new CLI commands when a switch is upgraded to 6.3.1.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 290 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Simplified Manageability
Recognizing a great demand in the marketplace and customers expectation for a level of synergism in the network management, Alcatel-Lucent has developed a comprehensive, unified, and simplified network and switch management solutions for its full array of networking products including the AOS OmniSwitch product family. The OS6850 switch and network management industry proven features offers the network administrators ease-of-use and ease of management. The following is only a highlight of the advanced network and switch management features supported by the OmniSwitch 6850 Series: OmniVista NMS: Alcatel-Lucents Single voice, data and services network management including OneTouch QoS and SecureView. Carrier-Class Dynamic Mobility Through the application of a comprehensive QoS feature set, the AOS OmniSwitch product family is capable of supporting converged applications such as the VoIP Diagnosing Switch problems: o Port Mirroring; Port based, port mirroring for troubleshooting, supports four sessions with multiple sources-to-one destination configuration o Port monitoring feature that allows capture of Ethernet packets to a file, or for on-screen display to assist in troubleshooting o SFlow v5 support to monitor and effectively control and manage the network usage o RMON: Supports RFC 2819 RMON group (1-Statistics, 2-History, 3-Alarm, and 9-Events) o Switch Health o UDLD: support for monitoring the physical configuration of cables and detect unidirectional links o Monitoring Memory Tools & Switch Configuration o Switch Logging Local (on the flash) and remote logging (Syslog) Logging into the Switch through Telnet/STelnet, FTP/SFTP, HTTP/HTTPS, SSH, SSL, and SNMPv1&v2&v3 o Remote telnet management or secure shell access using SSH o Secured file upload using SFTP, or SCP o SNMPv1/v2/v3 Authentication or AAA Servers Policy Servers; Authentication Servers such as RADIUS, LDAP, and ACE servers Policy-Based Management with LDAP Directory Services System File Management Dual image and dual configuration file storage provides backup Intuitive Alcatel-Lucent CLI for familiar interface and reduced training costs WebView Element Mgmt: Easy to use point & click web based element manager with built-in help for easy configuration of new technology features Remote telnet management or secure shell Secured file upload using SFTP, or SCP Port based mirroring for troubleshooting supports 128 sources to one destination configuration. o Policy-based Mirroring & Remote-based Mirroring Human readable ASCII based config files for offline editing and bulk configuration Managing Switch Users Accounts & Partitioned Management feature Managing Switch Security IGMPv1/v2/v3 snooping to optimize multicast traffic BootP/DHCP client allows auto-config of switch IP information to simplify deployment Auto-negotiating 10/100/1000 ports automatically configure port speed and duplex setting Auto MDI/MDIX automatically configures transmit and receive signals to support straight thru and crossover cabling Etherbreaker DHCP relay to forward client requests to a DHCP server DHCP Option-82 & DHCP Snooping Integration with SNMP manager OmniVista for network wide management System event log Network Time Protocol (NTP) for network wide time synchronization Alcatel-Lucent Interswitch Protocols (AIP) o AMAP: Alcatel-Lucent Mapping Adjacency Protocol (AMAP) for building topology maps within OmniVista o IEEE 802.1AB with MED Extensions / LLDP-MED GVRP for 802.1Q-compliant VLAN pruning and dynamic VLAN creation Ethernet OAM

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 291 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Alcatel-Lucent Interswitch Protocols (AIP)

Interswitch Protocol (AMAP)

IEEE 802.1AB with MED Extensions (LLDP)

Alcatel-Lucent Interswitch Protocols (AIP) is used to discover adjacent switches and retain mobile port information across switches. The following protocol is supported: Alcatel-Lucent Mapping Adjacency Protocol (AMAP), which is used to discover the topology of OmniSwitches. Alcatel-Lucent Interswitch Protocols (AIP) is used to discover adjacent switches and retain mobile port information across switches. By default, AMAP is not enabled. The Alcatel-Lucent Mapping Adjacency Protocol (AMAP) is used to discover the network topology of OmniSwitch (s) in a particular installation. Using this protocol, each switch determines which OmniSwitch; Omni S/R and/or OmniAccess switches are adjacent to it by sending and responding to Hello update packets. For the purposes of AMAP, adjacent switches are those that: Have a Spanning Tree path between them Do not have any switch between them on the Spanning Tree path that has AMAP enabled Link Layer Discovery Protocol (LLDP) is an emerging standard to provide a solution for the configuration issues caused by expanding networks. LLDP supports the network management software used for complete network management. LLDP is implemented as per the IEEE 802.1AB standard. LLDP specifically defines a standard method for Ethernet network devices to exchange information with its neighboring devices and maintain a database of the information. The exchanged information, passed as LLDPDU, is in TLV (Type, Length, and Value) format. The information available to the network management software must be as new as possible; hence, remote device information is periodically updated. IEEE 802.1AB (2005) is the latest version for the standards based connectivity discovery protocol. The purpose of the IEEE standard 802.1AB for Link Layer Discovery Protocol (LLDP), is to provide support for network management software dealing with topology discovery such as OmniVista. Switches that are compliant with 802.1AB exchange information with neighboring devices and maintain a database of the information exchanged. 802.1ab uses TLV (Time, Length, and Value) frames to exchange information with neighboring devices. The Link Layer Discovery Protocol-Media Endpoint Discover or LLDP-MED is designed to extend IEEE 802.1AB functionality to exchange information such as VLANs and power capabilities. 802.1AB Overview LLDP is a Layer 2 protocol for detecting adjacent devices in a network. Each device in a network sends and receives LLDPDUs through all its ports, when the protocol is enabled. If the protocol is disabled on a port or on a device, then LLDPDUs received on that port or device are dropped. The LLDPDUs are transmitted at a certain interval that can be configured. When an LLDPDU is received from a neighboring device, the LLDPDU software validates the frame and stores the information in its remote device Management Information Base (MIB). This information is aged periodically, if an LLDPDU is not received from the same device within the time mentioned in the TTL TLV of the LLDPDU. By exchanging information with all the neighbors, each device will know its neighbor on each port. The information within the LLDPDU is transmitted in TLV (Type, Length, Value) format and falls under two categories: Mandatory Optional Each LLDPDU contains all the four mandatory TLVs and optional TLVs. IEEE 802.1AB (LLDAP) Specifications IEEE Specification: IEEE 802.1AB-2005 Station and Media Access Control Connectivity Discovery Transmit time interval for LLDPDUs : 5 to 32768 in seconds Transmit hold multiplier value : 2 to 10 Transmit delay : 1 to 8192 in seconds Reinit delay : 1 to 10 in seconds Notification interval : 5 to 3600 in seconds IEEE 802.1AB (LLDP) Defaults The following table shows the default settings of the configurable 802.1AB parameters. Parameter Description Default Transmit time interval for LLDPDUs 30 seconds Transmit hold multiplier value 4 Transmit delay 2 seconds Reinit delay 2 seconds Notification interval 5 seconds LLDPDUs transmission Transmission and Reception Per port notification Disable Management TLV Disable 802.1 TLV Disable 802.3 TLV Disable LLDP Media Endpoint Device Disable

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 292 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Account & Password Policies

Authentication Servers or AAA servers (authentication, authorization, and accounting)

Authentication Servers

This feature allows a switch administrator to configure password policies for password creation and management. The administrators can configure how often a password must be changed, lockout settings for failed attempts, password complexity, history, and age as well as other account management settings. Authentication servers are sometimes referred to as AAA servers (authentication, authorization, and accounting). These servers are used for storing information about users who want to manage the switch (Authenticated Switch Access) and users who need access to a particular VLAN(s) (Authenticated VLANs). RADIUS or LDAP servers may be used for Authenticated Switch Access and/or Authenticated VLANs. Another type of server, SecurIDs ACE/Server, may be used for authenticated switch access only; the ACE/Server is an authentication-only server (no authorization or accounting). Only RADIUS servers are supported for 802.1X Port-Based Network Access Control. Authentication Servers Specifications: RADIUS RFCs Supported: RFC 2865Remote Authentication Dial In User Service (RADIUS) RFC 2866RADIUS Accounting RFC 2867RADIUS Accounting Modifications for Tunnel Protocol Support RFC 2868RADIUS Attributes for Tunnel Protocol Support RFC 2809Implementation of L2TP Compulsory Tunneling via RADIUS RFC 2869RADIUS Extensions RFC 2548Microsoft Vendor-specific RADIUS Attributes RFC 2882Network Access Servers Requirements: Extended RADIUS Practices LDAP RFCs Supported: RFC 1789Connectionless Lightweight X.5000 Directory Access Protocol RFC 2247Using Domains in LDAP/X.500 Distinguished Names RFC 2251Lightweight Directory Access Protocol (v3) RFC 2252Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions RFC 2253Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names RFC 2254The String Representation of LDAP Search Filters RFC 2256A Summary of the X.500 (96) User Schema for Use with LDAPv3 Other RFCs: RFC 2574User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) RFC 2924Accounting Attributes and Record Formats RFC 2975Introduction to Accounting Management RFC 2989Criteria for Evaluating AAA Protocols for Network Access Maximum number of authentication servers in single authority mode: 4 (not including any backup servers) Maximum number of authentication servers in multiple authority mode: 4 per VLAN (not including any backup servers) Maximum number of servers per Authenticated Switch Access type: 4 (not including any backup servers) CLI Command Prefix Recognition: The aaa radius-server and aaa ldap-server commands support prefix recognition.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 293 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

ACE/Server

RADIUS Servers

Lightweight Directory Access Protocol (LDAP)

Policy Servers (Policy Server Management)

Syslog to Multiple Hosts

An external ACE/Server may be used for authenticated switch access. It cannot be used for Layer 2 authentication or for policy management. Attributes are not supported on ACE/Servers. These values must be configured on the switch through the user commands. Since an ACE/Server does not store or send user privilege information to the switch, the switch determines user privileges for Secur/ID logins. When a user attempts to log into the switch, the user ID and password is sent to the ACE/Server. The server determines whether the login is valid. If the login is valid, the user privileges must be determined. The switch checks its user database for the users privileges. If the user is not in the database, the switch uses the default privilege, which is determined by the default user account. There are no server-specific parameters that must be configured for the switch to communicate with an attached ACE/Server; however, you must FTP the sdconf.rec file from the server to the switchs/network directory. This file is required so that the switch will know the IP address of the ACE/Server. The ACE client in the switch is version 4.1; it does not support the replicating and locking feature of ACE 5.0, but it may be used with an ACE 5.0 server if a legacy configuration file is loaded on the server. The legacy configuration must specify authentication to two specific servers (master and slave). The ACE/Server generates secrets that it sends to clients for authentication. While you cannot configure the secret on the switch, you can clear it. The secret may need to be cleared because the server and the switch get out of synch. RADIUS is a standard authentication and accounting protocol defined in RFC 2865 and RFC 2866. A built-in RADIUS client is available in the switch. A RADIUS server that supports Vendor Specific Attributes (VSAs) is required. The Alcatel-Lucent attributes may include VLAN information, time-ofday, or slot/port restrictions. RADIUS Server Attributes: RADIUS servers and RADIUS accounting servers are configured with particular attributes defined in RFC 2138 and RFC 2139, respectively. These attributes carry specific authentication, authorization, and configuration details about RADIUS requests to and replies from the server. For a complete list of attributes (standard, and vendor-specific) and how to configure them on the server, please refer to the Users Manual. Lightweight Directory Access Protocol (LDAP) is a standard directory server protocol. The LDAP client in the switch is based on several RFCs: 1798, 2247, 2251, 2252, 2253, 2254, 2255, and 2256. The protocol was developed as a way to use directory services over TCP/IP and to simplify the directory access protocol (DAP) defined as part of the Open Systems Interconnection (OSI) effort. Originally it was a front-end for X.500 DAP. The protocol synchronizes and governs the communications between the LDAP client and the LDAP server. The protocol also dictates how its databases of information, which are normally stored in hierarchical form, are searched, from the root directory down to distinct entries. In addition, LDAP has its own format that permits LDAP-enabled Web browsers to perform directory searches over TCP/IP. For a complete list of attributes (vendor-specific) and how to configure them on the server, please refer to the Users Manual. Quality of Service (QoS) policies that are configured through Alcatel-Lucents PolicyView network management application are stored on a Lightweight Directory Access Protocol (LDAP) server. PolicyView is an OmniVista application that runs on an attached workstation. Policy Server Specifications: LDAP Policy Servers RFCs Supported: RFC 2251Lightweight Directory Access Protocol (v3) RFC 3060Policy Core Information ModelVersion 1 Specification Maximum number of policy servers (supported on the switch): 4 Maximum number of policy servers (supported by PolicyView): 1 Policy servers use the Lightweight Directory Access Protocol (LDAP) to store policies that are configured through Alcatel-Lucents PolicyView network management application. PolicyView is an OmniVista application that runs on an attached workstation. The Lightweight Directory Access Protocol (LDAP) is a standard directory server protocol. The LDAP policy server client in the switch is based on RFC 2251. Currently, only LDAP servers are supported for policy management. The switch communicates with the LDAP server to download and manage LDAP policies. When the policy server is connected to the switch, the switch is automatically configured to communicate with the server to download and manage policies created by the PolicyView application. There is no required user configuration. (Note that the LDAP policy server is automatically installed when the Policy-View application is installed.) Note. The switch has separate mechanisms for managing QoS policies stored on an LDAP server and QoS policies configured directly on the switch. Sending Syslog files to multiple hosts is allowed. It is possible to specify up to a maximum of four servers.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 294 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Diagnosing Sw itch Problems

Several tools are available for diagnosing problems that may occur with the switch. These tools include: Port Mirroring (port-based, policy-based), and Remote port Mirroring Port Monitoring & Port Mapping Remote Monitoring (RMON) probes Switch Health Monitoring UDLD: support for monitoring the physical configuration of cables and detect unidirectional links SFlow Monitoring Memory tools Switch Logging Ethernet OAM Port mirroring copies all incoming and outgoing traffic from a single mirrored Ethernet port to a second mirroring Ethernet port, where it can be monitored with a Remote Network Monitoring (RMON) probe or network analysis device without disrupting traffic flow on the mirrored port. Switch Health monitoring software checks previously configured threshold levels for the switchs consumable resources, and notifies the Network Monitoring Station (NMS) if those limits are violated. Port Mapping Port Mapping is a security feature that controls peer users from communicating with each other. A Port (AKA Private VLAN) Mapping session comprises a session ID and a set of user ports and/or a set of network ports. User ports within a session cannot communicate with each other and can only communicate via network Allows traffic segregation at L2 ports. In a Port Mapping session with user port set A and network port set B, ports in set A can only User ports in the same session cannot talk communicate with ports in set B. If set B is empty, ports in set A can communicate with rest of the to each other ports in the system. A port mapping session can be configured in unidirectional or bidirectional mode. In the unidirectional mode, the network ports can communicate with each other within the same Note: this feature is part of session. In the bidirectional mode, the network ports cannot communicate with each other. Network Residential bridging features ports of a unidirectional port mapping session can be shared with other unidirectional sessions, but cannot be shared with any sessions configured in bidirectional mode. Network Ports of different sessions can communicate with each other. Port Mapping Specifications: Ports Supported: Ethernet (10 Mbps)/Fast Ethernet (100 Mbps)/Gigabit Ethernet (1 Gb/1000 Mbps) /10 Gigabit Ethernet (10 Gb/10000 Mbps). Mapping Sessions: Eight sessions supported per standalone switch and stack. Port Mapping Defaults: Mapping Session: Creation: No mapping sessions Mapping Status configuration: Disabled Port Mapping Direction: Bi-directional Port Mirroring Port mirroring copies all incoming and outgoing traffic from a single mirrored Ethernet port to a second mirroring Ethernet port, where it can be monitored with a Remote Network Monitoring (RMON) probe or network analysis device without disrupting traffic flow on the mirrored port. Switch Health monitoring software checks previously configured threshold levels for the switchs consumable resources, and notifies the Network Monitoring Station (NMS) if those limits are violated. Port Mirroring Specifications Ports Supported: Eth. (10Mbps)/Fast Eth. (100Mbps)/Gigabit Eth. and 10-Gigabit Eth. Mirroring Sessions Supported: One session supported per standalone switch. One (1) port mirroring session is supported per standalone switch chassis, or in the case of OmniSwitch 6800 and 6850 switches, in a stack consisting of two or more switches. Port Capacity Requirements: Mirrored (monitored) and mirroring (monitoring) ports must be of identical capacity (both ports support identical Mbps rates) or the Mirroring port must be of higher capacity than the mirrored port. (Example: A mirrored Fast Ethernet port supports 100 Mbps, while a Mirroring Gigabit Ethernet port supports 1000 Mbps). N-to-1 Mirroring Supported: The switch supports N-to-1 port mirroring; where up to 24 (OS6800) or 128 (OS6850/OS9000) source ports can be mirrored to a single destination port. Range of Unblocked VLAN IDs: 1 to 4094. Port mirroring Defaults The following table shows port mirroring default values. Mirroring Session Creation: No Mirroring Sessions Configured Protection from Spanning Tree (Spanning Tree Disable): Spanning Tree Enabled Mirroring Status Configuration: Enabled Mirroring Session Configuration: Enabled Mirroring Session Deletion: No Mirroring Sessions Configured On OmniSwitch 9000 switches, you can set up port mirroring between Ethernet ports within the same switch chassis, while on OmniSwitch 6800 and 6850 switches, you can set up port mirroring across switches within a stack. Ethernet ports supporting port mirroring include 10BaseT/100BaseTX/1000BaseT (RJ-45), 1000BaseSX/LX/LH, and 10GBaseS/L (LC) connectors. When port mirroring is enabled, the active mirrored port transmits and receives network traffic normally, and the mirroring port receives a copy of all transmit and receive traffic to the active port. You can connect an RMON probe or network analysis device to the mirroring port to see an exact

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 295 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Port Mirroring Enhancements

Policy Based Mirroring

duplication of traffic on the mirrored port without disrupting network traffic to and from the mirrored port. Port mirroring runs in the Chassis Management software and is supported for Ethernet (10 Mbps), Fast Ethernet (100 Mbps), Gigabit Ethernet (1000 Mbps), and 10 Gigabit Ethernet (10000 Mbps) ports. In addition, the switch supports N-to-1 port mirroring, where up to 24 (OS6800) or 128 (OS6850/OS9000) source ports can be mirrored to a single destination port. Note the following restriction when configuring a port mirroring session: One (1) port mirroring session is supported per standalone switch chassis, or in the case of OmniSwitch 6800 and 6850 switches, in a stack consisting of two or more switches. You cannot configure a port mirroring and a port monitoring session on the same NI module in an OmniSwitch 9000. You cannot configure port mirroring and monitoring on the same switching ASIC on OmniSwitch 6850 Series switches. Each switching ASIC controls 24 ports (e.g., ports 124, 2548, etc.). For example, if a port mirroring session is configured for ports 1/12 and 1/22, then configuring a port monitoring session for any of the ports between 1 and 24 is not allowed. You cannot configure port mirroring and monitoring on the same switching ASIC on OmniSwitch 6800 Series switches. Each switching ASIC controls 12 ports (e.g., ports 112, 1324, etc.). For example, if a port mirroring session is configured for ports 1/6 and 1/10, then configuring a port monitoring session for any of the ports between 1 and 12 is not allowed. If a port mirroring session is configured across two switching ASICs, then configuring a monitoring session is not allowed on any of the ports controlled by each of the ASICs involved. For example, if a port mirroring session is configured for ports 1/8 and 1/30 on a 48-port switch, then configuring a port monitoring session involving any of the ports between 1 and 48 is not allowed. By default, port-mirroring sessions are bi-directional. What Ports Can Be Mirrored? OmniSwitch 6800/6850/9000 Series switches support mirroring (where applicable) between any 10/100/1000 port to any other 10/100/1000 port and between any fiber MiniGBIC SFP to any other fiber MiniGBIC SFP port. When Port Mirroring is enabled, the active mirrored port transmits and receives network traffic normally, and the mirroring port receives a copy of all transmit and receive traffic to the active port. You can connect an RMON probe or network analysis device to the mirroring port to see an exact duplication of traffic on the mirrored port without disrupting network traffic to and from the mirrored port. Only one Port Mirroring session is supported. That session can be configured to a N-to-1 session where N can be a number from 1 to 24 (OS6800) or 1 to 128 (OS6850/OS9000) anywhere on the stack. In other words, you can configure up to 24 or 128 source ports for a single destination port in a session on a stack. You cannot configure port mirroring and port monitoring on the same NI module. This feature enhances the current port mirroring functionality on the OmniSwitch. It allows policies to be configured to determine when traffic should be mirrored based on policies rather than being restricted to a specified port. The following policies can be configured: Traffic between 2 ports Traffic from a source address Traffic to a destination address Traffic to/from an address Traffic between 2 addresses Traffic with a classification criterion based on packet contents other than addresses (for example , based on protocol, priority). VLAN-based mirroring - mirroring of packets entering a VLAN. Limitations The policy mirror action must specify the same analyzer port for all policies in which the action is used One policy-based mirroring session supported per switch. One port-based mirroring session supported per switch. Note that policy-based and port-base mirroring are both allowed on the same port at the same time. One remote port-based mirroring session supported per switch. One port-monitoring session supported per switch.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 296 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Remote Port Mirroring (802.1Q based) Remote port mirroring is supported only on OS6850 and OS9000 switches. This feature provides a remote port mirroring capability where traffic from a local port can be carried across the network to an egress port where a sniffer can be attached. This features makes use of an 802.1q tag to send the mirrored traffic over the network using tagged VLANs.

Remote Port Mirroring Overview: Remote Port Mirroring expands the port mirroring functionality by allowing mirrored traffic to be carried over the network to a remote switch. With Remote Port Mirroring the traffic is carried over the network using a dedicated Remote Port Mirroring VLAN, no other traffic is allowed on this VLAN. The mirrored traffic from the source switch is tagged with the VLAN ID of the Remote Port Mirroring VLAN and forwarded over the intermediate switch ports to the destination switch where an analyzer is attached. Note. Remote Port Mirroring is supported only on OS6850 and OS9000 Series switches. Since Remote Port Mirroring requires traffic to be carried over the network, the following exceptions to regular port mirroring exist: Spanning Tree must be disabled for the Remote Port Mirroring VLAN on all switches. There must not be any physical loop present in the Remote Port Mirroring VLAN. On the intermediate and destination switches, source learning must be disabled or overridden on the ports belonging to the Remote Port Mirroring VLAN. The QoS redirect feature can be used to override source learning on an OmniSwitch. BPDU mirroring will be disabled by default on all OS6850s. BPDU mirroring will be disabled by default on all OS9000s with B2 revision ASICs. (Contact Service and Support to enable) BPDU mirroring will be enabled by default on all OS9000s with A0/A1 revision ASICs. Source learning must be disabled or overridden on the ports belonging to the remote port mirroring VLAN on the intermediate and destination switches. On OS9000 and OS6850 switches the QoS redirect feature can be used to override source learning. The following types of traffic will not be mirrored: Link Aggregation Control Packets (LACP) 802.1AB (LLDP) 802.1x port authentication 802.3ag (OAM) Layer 3 control packets Generic Attribute Registration Protocol (GARP) BPDUs will not be mirrored on OS6850s but will be mirrored on OS9000s.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 297 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Port Monitoring

The Port Monitoring feature allows you to examine packets to and from a specific Ethernet port (either ingress or egress). You can select to dump captured data to a file, which can be up to 140K. Once a file is captured, you can FTP it to a Protocol Analyzer or PC for viewing. The OmniSwitch 9000 supports one session per switch. By default, the switch will create a data file called pmonitor.enc in flash memory. When the 140K limit is reached the switch will begin overwriting the data starting with the oldest captured data. However, you can configure the switch so it will not overwrite the data file. In addition, you can configure additional port monitoring files as long as you have enough room in flash memory. You cannot configure port mirroring and port monitoring on the same NI module. Port monitoring provides the ability to capture a packet trace locally for real time display or for replay later through a packet analyzer to determine network issues. It works like port mirroring but instead of sending the captured packets to another port, it stores these packets to a local file for later retrieval or display. Port Monitoring Specifications: Ports Supported: Ethernet (10 Mbps) / Fast Ethernet (100 Mbps) / Gigabit Ethernet Monitoring Sessions Supported: one per switch File Type Supported: ENC file format (Network General Sniffer Network Analyzer Format) By default, a port monitoring session will never be disabled. The length of time before a port monitoring session is disabled is from 0 (the default, where the session is permanent) to 2147483647 seconds. By default, a file called pmonitor.enc is created in the /flash directory when you configure and enable a port monitoring session. By default, port-monitoring sessions are bi-directional. The port-monitoring feature allows you to examine packets to and from a specific Ethernet port. Port monitoring has the following features: Software commands to enable and display captured port data. Captures data in Network General file format. Files called pmonitor.enc is created in /flash memory when you configure and enable a port monitoring session. Data packets time stamped. One port monitored at a time. RAM-based file system. Statistics gathering and display The port-monitoring feature also has the following restrictions: Estimated packet capture rate is around 500 packets/second The maximum number of monitoring session is limited one per chassis Link Aggregation ports can not be monitored If both mirroring and monitoring are enabled then packets will be either mirrored or monitored (i.e., sent to CPU), whichever comes first. You can select to dump real-time packets to a file. Once a file is captured, you can FTP it to a Sniffer or PC for viewing.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 298 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Remote Monitoring (RMON)

UDLD - Fiber and Copper

Remote Network Monitoring (RMON) is an SNMP protocol used to manage networks remotely. RMON probes can be used to collect, interpret, and forward statistical data about network traffic from designated active ports in a LAN segment to an NMS (Network Management System) application for monitoring and analysis without negatively impacting network performance. RMON software is fully integrated in the Chassis Management software and works with the Ethernet software to acquire statistical information. This feature supports basic RMON 4 group implementation in compliance with RFC 2819, including the Ethernet Statistics, History (Control & Statistics), Alarms and Events groups RMON Specifications; RFCs Supported: 2819 - Remote Network Monitoring Management Information Base RMON Functionality Supported: o Basic RMON 4 group implementation Ethernet Statistics group History (Control and Statistics) group Alarms group Events group RMON Functionality Not Supported: o RMON 10 group* o RMON2* o Host group o HostTopN group o Matrix group o Filter group o Packet Capture group o (*An external RMON probe that includes o RMON 10 group and RMON2 may be used where full RMON probe functionality is required.) Flavor (Probe Type): Ethernet/History/Alarm Status: Active/Creating/Inactive History Control Interval (seconds): 1 to 3600 History Sample Index Range: 1 to 65535 Alarm Interval (seconds): 1 to 2147483647 Alarm Startup Alarm: Rising Alarm/Falling Alarm/RisingOrFalling Alarm Alarm Sample Type: Delta Value/Absolute RMON Traps Supported: o RisingAlarm/FallingAlarm o These traps are generated whenever an Alarm entry crosses either its Rising Threshold or its Falling Threshold and generates an event con-figured for sending SNMP traps. The unidirectional link detection protocol is a protocol that can be used to detect and disable malfunctioning unidirectional Ethernet fiber or copper links. Errors due to improper installation of fiber strands, interface malfunctions, media converter faults, etc can be detected and the link can be disabled. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms. UDLD Uni Directional Link Detection (UDLD) is a protocol for detecting and disabling unidirectional Ethernet fiber or copper links caused by mis-wiring of fiber strands, interface malfunctions, media converter faults, etc. The UDLD operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms. UDLD is a lightweight protocol that can be used to detect and disable one-way connections before they create dangerous situations such as Spanning Tree loops or other protocol malfunctions. The protocol is mainly used to advertise the identities of all the UDLD-capable devices attached to the same LAN segment and to collect the information received on the ports of each device to determine whether the Layer 2 communication is functioning properly. All connected devices must support UDLD for the protocol to successfully identify and disable unidirectional links. When UDLD detects a unidirectional link, the protocol administratively shuts down the affected port and generates a trap to alert the user. UDLD Overview UDLD is a Layer 2 protocol used to examine the physical configuration connected through fiber-optic or twisted-pair Ethernet cables. UDLD detects and administratively shuts down the affected port, and alerts the user when a unidirectional link exists. Unidirectional links can create hazardous situations such as Spanning-Tree topology loops caused, for instance, by unwiring of fiber strands, interface malfunctions, media converters faults, etc. The UDLD feature is supported on the following port types: Copper ports Fiber ports

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 299 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Switch Health Monitoring (Health Statistics)

UDLD Specifications RFCs supported : Not applicable at this time IEEE Standards supported: Not applicable at this time Probe-message advertisement timer:7 to 90 in seconds Echo-based detection timer : 4 to 15 in seconds Maximum neighbors per UDLD port : 32 Maximum number of UDLD ports per system : 128 UDLD Defaults Description Default UDLD administrative state Disabled UDLD status of a port Disabled UDLD operational mode Normal Probe-message advertisement time 15 Seconds Echo-based detection timer 8 Seconds To monitor resource availability, the NMS (Network Management System) needs to collect significant amounts of data from each switch. As the number of ports per switch (and the number of switches) increases, the volume of data can become overwhelming. The Health Monitoring feature can identify and monitor a switchs resource utilization levels and thresholds, improving efficiency in data collection. Health Monitoring provides the following data to the NMS: Switch-level Input/Output, Memory and CPU Utilization Levels Module-level and Port-level Input/Output Utilization Levels Health monitoring software monitors threshold levels for the switchs consumable resources bandwidth, RAM memory, and CPU capacityas well as the ambient chassis temperature. When a threshold is exceeded, the Health Monitoring feature sends a trap to the Network Management Station (NMS). A trap is an alarm alerting the user to specific network events and, in the case of Health-related traps, indicates specifically which threshold has been crossed. Note. When a resource falls back below the configured threshold, an addition trap is sent to the user. This indicates that the resource is no longer operating beyond its configured threshold limit. For each monitored resource, the following variables are defined: Most recent utilization level (percentage) Average utilization level over the last minute (percentage) Average utilization level over the last hour (percentage) Maximum utilization level over the last hour (percentage) Threshold level Additionally, Health Monitoring provides the capacity to specify thresholds for the resource utilization levels it monitors, and generates traps based on the specified threshold criteria. Switch Health Specifications: Health Functionality Supported: o Switch level CPU Utilization Statistics (percentage); o Switch/module/port level Input Utilization o Statistics (percentage); o Switch/module/port level Input/Output o Utilization Statistics (percentage); o Switch level Memory Utilization Statistics (percentage); o Device level o Temperature Statistics (Celsius). Monitored Resource Utilization Levels: o Most recent utilization level; o Average utilization level during last minute; o Average utilization level during last hour; o Maximum utilization level during last hour. Resource Utilization Raw Sample Values: Saved for previous 60 seconds. Resource Utilization Current Sample Values: Stored. Resource Utilization Maximum Utilization Value: Calculated for previous 60 seconds and stored. Utilization Value = 0: Indicates that none of the resource was measured for the period. Utilization Value = 1: Indicates that a non-zero amount of the resource (less than 2%) was measured for the period. Percentage Utilization Values: Calculated based on Resource Measured During Period/Total Capacity. Resource Threshold Levels: Apply automatically across all levels of switch (switch/module/port). Rising Threshold Crossing: A Resource Threshold was exceeded by its corresponding utilization value in the current cycle. Falling Threshold Crossing: A Resource Threshold was exceeded by its corresponding utilization value in the previous cycle, but is not exceeded in the current cycle. Threshold Crossing Traps Supported: Device, module, port-level threshold crossings.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 300 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Monitoring Memory

SFlow Based on RFC 3176 sFlow SFlow is a sampling technology embedded within switches/routers defined in RFC 3176. It provides the ability to monitor the traffic flows. It requires an sFlow Agent running in the Switch/Router and a sFlow collector which receives and analyses the monitored data. The sFlow collector makes use of SNMP to communicate with an SFlow agent in order to configure sFlow monitoring on the device (switch). SFlow agent running on the OS6850, combines interface counters and traffic flow (packet) samples on all the configured interfaces into sFlow Datagrams which are sent across the network to an sFlow collector (3rd Party software). Packet sampling is done in Hardware and is non-CPU intensive.

Debug memory monitor commands can monitor memory allocation and free memory (such as detection of invalid free addresses and maintenance of size statistics). These commands are useful for monitoring logging of events, leak detection, classification of memory allocations, detection of invalid free addresses, and maintenance of size statistics. Notes. System Debug (kTrace and sysTrace) commands is intended for use by qualified Alcatel-Lucent Customer Support personnel to assist customers in diagnosing or debugging system performance. For information about these commands, see the chapter titled, Memory Monitoring Commands in the OmniSwitch CLI Reference Guide. It is strongly recommended that you contact an Alcatel-Lucent Customer Service representative for assistance. The Switch Logging feature is a high-level event logging mechanism that can also be useful in maintaining and servicing the switch. The configuration snapshot command can be used to capture and save all kTrace, sysTrace, Memory Monitor, and Switch Logging configuration settings in a snapshot text file that can be viewed, edited, and used as a configuration file. Monitoring Memory Specifications: Functionality Supported: o Fence Post/ o Bad Address Detection/ o Leak Monitoring/ o Memory Classification/ o Global Statistical Gathering/ o Task Statistical Gathering/ o Size Statistical Gathering. Functionality Not Supported: Ownership Violations. Show Command Output Devices Supported: o Standard Out (console)/ o Switch Logging/ o sysTrace Buffer. SFlow is a network monitoring technology that gives visibility in to the activity of the network, by providing network usage information. It provides the data required to effectively control and manage the network usage. SFlow is a sampling technology that meets the requirements for a network traffic monitoring solution. SFlow provides a network-wide view of usage and active routes. It is used for measuring network traffic, collecting, storing, and analyzing the traffic data. As it is scalable, that doesnt add significant network load. sFlow is an industry standard with many vendors delivering products with this support. Some of the applications of the sFlow data include: Detecting, diagnosing, and fixing network problems Real-time congestion management Detecting unauthorized network activity Usage accounting and billing Understanding application mix Route profiling and peer optimization Capacity planning SFlow is a sampling technology embedded within switches/routers. It provides the ability to monitor the traffic flows. It requires a sFlow Agent software process running as part of the switch software and a sFlow collector which receives and analyses the monitored data. sFlow collector makes use of SNMP to communicate with a sFlow agent in order to configure sFlow monitoring on the device (switch). sFlow agent running on the switch/router, combines interface counters and traffic flow (packet) samples preferably on all the interfaces into sFlow Datagrams that are sent across the network to a sFlow collector. Packet sampling on the switch/router is typically performed by the switching/routing ASICs, providing wire-speed performance. In this case, sFlow agent does very little processing, by packaging data into sFlow Datagrams that are immediately sent on network. This minimizes the memory and CPU utilization by sFlow agent. MIB information for the sFlow commands is as follows: Filename: Alcatel-LucentIND1PortMirMon.MIB Module: Alcatel-Lucent-IND1-PORT-MIRRORING-MONITORING-MIB Filename: SFLOW_RFC3176.MIB Module: SFLOW-MIB

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 301 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Switch logging

Logging into the switch

The Switch Logging feature is designed to provide a high-level event logging mechanism that can be useful in maintaining and servicing the switch. Switch Logging uses a formatted string mechanism to process log requests from applications. When a log request is received, Switch Logging verifies whether the Severity Level included with the request is less than or equal to the Severity Level stored for the appropriate Application ID. If it is, a log message is generated using the formatting specified by the log request and placed on the Switch Log Queue, and Switch Logging returns control back to the calling application. Otherwise, the request is discarded. The default output device is the log file located in the Flash File System. Other output devices can be configured via the Command Line Interface. All log records generated are copied to all configured output devices for the switch. The Command Line Interface can be used to display and configure Switch Logging information. Log information can be helpful in resolving configuration or authentication issues, as well as general errors. Log records can be sent to a text file and written into the flash file system. The log records can also be scrolled to the switchs console or to a remote IP address. Switch logging information can be customized and configured through Command Line Interface (CLI) commands, WebView and SNMP. Log information can be helpful in resolving configuration or authentication issues, as well as general switch errors. Notes. Switch logging commands are not intended for use with low-level hardware and software debugging. It is strongly recommended that you contact an Alcatel-Lucent Customer Service representative for assistance with debugging functions. Switch Logging Specifications: Functionality Supported: High-level event logging mechanism that forwards requests from applications to enabled logging devices. Functionality Not Supported: Not intended for debugging individual hardware applications Logging Devices: Flash Memory/Console/IP Address Application ID Levels Supported: o IDLE (255), DIAG (0), IPC-DIAG (1), o QDRIVER (2), QDISPATCHER (3), IPC-LINK o (4), NI-SUPERVISION (5), INTERFACE (6), o 802.1Q (7), VLAN (8), GM (9), BRIDGE (10), o STP (11), LINKAGG (12), QOS (13), RSVP o (14), IP (15), IPMS (17), AMAP (18), GMAP o (19), AAA (20), IPC-MON (21), IP-HELPER o (22), PMM (23), MODULE (24), EIPC (26), o CHASSIS (64), PORT-MGR (65), CONFIG o (66), CLI (67), SNMP (68), WEB (69), MIPGW o (70), SESSION (71), TRAP (72), POLICY (73), o DRC (74), SYSTEM (75), HEALTH (76), o NAN-DRIVER (78), RMON (79), TELENET o (80), PSM (81), FTP (82), SNMI (83), DIS-TRIB o (84), EPIL0GUE (85), LDAP (86), NOS-NMP o (87), SSL (88), DBGGW (89), o LANPOWER (108) Severity Levels/Types Supported: o 2 (Alarm - highest severity), 3 (Error), o 4 (Alert), 5 (Warning) 6 (Info - default), o 7 (Debug 1), 8 (Debug 2), 9 (Debug 3 lowest severity) Logging into the switch may be done locally or remotely. Management tools include: the Command Line Interface (CLI), which may be accessed locally via the console port, or remotely via Telnet; WebView, which requires an HTTP client (browser) on a remote workstation; and SNMP, which requires an SNMP manager (such as Alcatel-Lucents OmniVista) on the remote workstation. Secure sessions are available using the Secure Shell interface. File transfers can be done via FTP or Secure Shell FTP. Login Specifications: Telnet clients supported: Any standard Telnet client. FTP clients supported: Any standard FTP client. HTTP (WebView) clients supported: Internet Explorer for Windows NT, Windows XP, and Windows 2000, version 6.0 Netscape for Windows NT, Windows XP, and Windows 2000, version 7.1 Netscape for Sun OS 2.8, version 4.79 Netscape for HP-UX 11.0, version 4.79. Secure Shell clients supported: Any standard Secure Shell client (Secure Shell Version 2). SNMP clients supported: Any standard SNMP manager.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 302 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

End User Partitioning (EUPM)

Ethernet Interfaces

Ethernet OAM Complies with the IEEE 802.1ag draft 7.0 standards.

EUPM is used for customer login accounts that are configured with end-user profiles (rather than Functional privileges specified by partitioned management). Profiles specify command areas as well as VLAN and/or port ranges to which the user has access. These profiles are typically used for end users rather than network administrators. Ethernet and Gigabit Ethernet port software is responsible for a variety of functions that support Ethernet, Gigabit Ethernet and 10-Gigabit Ethernet ports. These functions include initialization of ports, notifying other software modules when a port goes down, configuration of basic line parameters, gathering of statistics for Ethernet and Gigabit Ethernet ports, and responding to administrative enable/disable requests. Configurable parameters include: auto negotiation (copper ports 10/100/1000), trap port link messages, flood control, line speed, duplex mode, inter-frame gap, resetting statistics counters, and maximum and peak flood rates. Flood control is configurable on ingress interfaces (flood rate and including/excluding multicast). Ethernet OAM (Operation, Administration, and Maintenance) provides service assurance over a converged Ethernet network. Ethernet OAM focuses on two main areas that are most in need by service providers and are rapidly evolving in the standards bodies: Service OAM and Link OAM. These two OAM protocols have unique objectives but are complementary to each other. Service OAM provides monitoring and troubleshooting of end-to-end Ethernet service instances, while Link OAM allows a provider to monitor and troubleshoot an individual Ethernet link. The end-to-end service management capability is the most important aspect of Ethernet OAM for service providers. This implementation of Service OAM: Complies with the IEEE 802.1ag draft 7.0 standards. Is only supported on a standalone OmniSwitch 6850. Support for this feature in a stacked environment (or multi-NI architecture) is planned for a future release. Does not support the optional MIP CCM database. As per section 19.4.4 of the IEEE 802.1ag 7.0 draft standard, LTM is forwarded on the basis of the source learning filtering database. Because the MIP CCM database is not supported in this release, MIPs will not forward LTM on blocked egress ports. Does not support Alarm Indication Signal (AIS) messages. Release 6.3.1 includes support for the IEEE 802.1ag draft 7.0 standards.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 303 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Ethernet OAM Overview

Logging into CLI

Using the Telnet S-Telnet is supported.

Using the FTP S-FTP is supported.

The rise in the number of Ethernet service instances has resulted in service providers requiring a powerful and robust set of management tools to maintain Ethernet service networks. Service provider networks are large and intricate, often comprising of different operators that work together to provide the customers with end-to-end services. The challenge for the service providers is to provide a highly available convergent network to its customer base. Ethernet OAM (Operations, Administration, and Maintenance) provides the detection, resiliency, and monitoring capability for end-to-end service guarantee in an Ethernet network. Note. Ethernet OAM is only supported in Release 6.2.1 for the OmniSwitch 6850 Series. The following table shows Ethernet OAM specifications. Ethernet OAM IEEE Standards Supported: IEEE 802.1agConnectivity Fault Management IEEE 802.3ahCSMA/CD Access Method and Physical Layer Specifications Note: IEEE 802.3ah will be supported in a Future Release. IEEE 802.1DMedia Access Control (MAC) Bridges IEEE 802.1QVirtual Bridged Local Area Networks Maximum Maintenance Domains (MD) per Bridge: 8 Maximum Maintenance Associations (MA) per Bridge: 128 Maximum Maintenance End Points (MEP) per Bridge: 25 The following table shows Ethernet OAM default values. Continuity Check Message interval: intervalnone MHF value assigned to a default Ethernet OAM Maintenance Domain: None The priority value for CCMs and LTMs transmitted by the MEP: 7 Number of Loopback messages to be transmitted: 1 Data Type Length Value: 64 VLAN priority: 0 Whether or not Drop Enable bit is configured (true or false): True Hop count: 64 Etherrnet OAM Overview Ethernet OAM provides service assurance over a converged Ethernet network. It helps service providers to manage network operations efficiently and smoothly. Ethernet OAM provides effective monitoring capabilities by increasing visibility in the network. It detects failure and degradation by raising warnings and alarms; also provides diagnostic and troubleshooting tools to resolve problems. Ethernet OAM focuses on two main protocols that the service providers require the most and are rapidly evolving in the standards bodies: Service OAM and Link OAM. These OAM protocols are unique and complementary to each other. Service OAMfor monitoring and troubleshooting end-to-end Ethernet service instances Link OAMfor monitoring and troubleshooting an individual Ethernet link Ethernet OAM is not supported on mobile, mirrored, and aggregable ports (the physical port members of an aggregate). It is also not supported on dynamically learned VLANs. But, it can be implemented on any full-duplex point-to-point or emulated point-to-point Ethernet link. It need not be implemented systemwide. Management systems are important for configuring Ethernet OAM across the network. They also help to automate network monitoring and troubleshooting. Ethernet OAM can be configured in two phases, Network Configuration phase and Service Activation phase. The Network Configuration phase enables Connectivity Fault Management (CFM) on the switches. CFM allows service providers to manage customer service instances individually. This phase also helps set up the Maintenance Intermediate Points (MIP) and Maintenance End Points (MEP). Any port of a bridge is referred to as a Maintenance Point (MP). An MP can be either a MEP or MIP. A MEP resides at the edge of a Maintenance Domain (MD), while a MIP is located within a Maintenance Domain. A Maintenance Domain is an administrative domain for managing and administering a network. In the Service Activation phase, a new end point created on a VLAN needs to be configured as a MEP. This enables the configuration of continuity-check and cross-check functionalities. Console portA direct connection to the switch through the console port: The console port is always enabled for the default user account. TelnetAny standard Telnet client may be used for remote login to the switch. This method is not secure. FTPAny standard FTP client may be used for remote login to the switch. This method is not secure. Secure ShellAny standard Secure Shell client may be used for remote login to the switch. Telnet may be used to log into the switch from a remote station. All of the standard Telnet commands are supported by software in the switch. When Telnet is used to log in, the switch is acting as a Telnet server. A Telnet session may also be initiated from the switch itself during a login session. In this case, the switch is acting as a Telnet client. Note. A Telnet connection is not secure. Secure Shell is recommended instead of Telnet or FTP as a secure method of accessing the switch.. The OmniSwitch can function as an FTP server. Any standard FTP client may be used. Note. An FTP connection is not secure. Secure Shell is recommended instead of FTP or Telnet as a secure method of accessing the switch. Note. You must use the binary mode (bin) to transfer image files via FTP.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 304 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Secured file upload/download using SCP

Secure Socket Layer (SSL) with encryption

Secure Shell (SSHv2) SSHv2 for secure CLI session with PKI is also supported

Secure Shell (SSH) Public Key Authentication

Using the WebView HTTP/HTTPS Port Configuration Using the SNMP

SCP to server for secure upload/download is supported. Copies an existing file in a secure manner. The SCP command will prompt you to enter the admin password, and the names and the path of the files being copied will be displayed. A file may be copied to a new location; you are not required to copy a file to the same directory that contains the original. Be sure to separate path directories and file names with a slash (/). Refer to the examples below. Up to 255 characters may be used for a fully qualified path. A path can contain up to a maximum of seven (7) directories including /flash. As with files names, up to thirty-two (32) characters may be used for a directory name. File and directory names can include only the following character types: a-z, A-Z, 0-9, dashes (-), dots (.), and underscores (_). SSL is a protocol that establishes and maintains secure communication between SSL-enabled servers and clients across the Internet. It secures communications to or from the switch for WebView or LDAP (LDAP-Netscape). Alcatel-Lucents SSL implementation is based on RSAs BSAFE SSL-C product, version 2.0.1. The OmniSwitch 6850 Series supports the SSL client / server implementation with the following types of encryptions: DES, 3DES, RC2, and RC4. The OmniSwitch Secure Shell feature provides a secure mechanism that allows you to log in to a remote switch, to execute commands on a remote device, and to move files from one device to another. Secure Shell provides secure, encrypted communications even when your transmission is between two untrusted hosts or over an un-secure network. The OmniSwitch includes both client and server components of the Secure Shell interface and the Secure Shell FTP file transfer protocol. SFTP is a subsystem of the Secure Shell protocol. All Secure Shell FTP data are encrypted through a Secure Shell channel. Secure Shell protects against a variety of security risks including the following: IP spoofing IP source routing DNS spoofing Interception of clear-text passwords and other data by intermediate hosts Manipulation of data by users on intermediate hosts Note. The OmniSwitch supports Secure Shell Version 2 only. Algorithm and key Exchange: One or several host-specific DSA keys identify the OmniSwitch Secure Shell server. Both the client and server process the key exchange to choose a common algorithm for encryption, signature, and compression. This key exchange is included in the Secure Shell transport layer protocol. It uses a key agreement to produce a shared secret that cannot be determined by either the client or the server alone. The key exchange is combined with a signature and the host key to provide host authentication. Once the exchange is completed, the client and the server turn encryption on using the selected algorithm and key. The following elements are supported: Host key Type: DSA Cipher Algorithms; AES, Blowfish, Cast, 3DES, Arcfour, and Rijndael Signature Algorithms: MD5, and SHA1 Compression Algorithms: None-supported Key Exchange Algorithms: Diffie-hellman-group-exchange-shal Diffie-hellman-group1-shal When used as an SSH Server, the following SSH Software is supported: OpenSSH: Sun Solaris, Win NT + Cygwin, Mac OSX, Linux Red Hat F-Secure: Sun Solaris, Win 2000, Win NT, Win XP, Mac OS9 SSH-Communication: Sun Solaris, Win 2000, Win NT, Win XP, Linux Red Hat PuTTY: Win 2000, Win NT, Win XP, Mac OS9 MAC-SSH: Mac OS9, Mac OSX When used as an SSH Client, the following SSH Software is supported: OpenSSH: Sun Solaris, Win NT + Cygwin, Linux Red Hat, AOS F-Secure: Sun Solaris, Win 2000, Win NT SSH-Communication: Sun Solaris, Win 2000, Win NT, Win XP, Linux Red Hat DSA public key authentication is supported when using PuTTY SSH software to generate the private and public key for the client and to access the switch. It is now possible to enforce the use of public key authentication only on the switch. By default, both password and public key authentication are allowed. HTTPThe switch has a Web browser management interface for users logging in via HTTP. This management tool is called WebView. The default HTTP port and the default Secure HTTP (HTTPS) port can be configured for the embedded Web server in the switch. SNMPAny standard SNMP browser may be used for logging into the switch. SNMPv1&v2&v3 is supported.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 305 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

User Accounts

The Login Banner

The DNS Resolver (DNS Client)

Managing System Files

File and Directory Management

Loading Software onto the Switch

User accounts may be configured and stored directly on the switch, and user accounts may also be configured and stored on an external authentication server or servers. The accounts include a username and password. In addition, they also specify the users privileges or end-user profile, depending on the type of user account. In either case, the user is given read-only or read-write access to particular commands. Local User Database The user command creates accounts directly on the switch. External Authentication Servers The switch may be set up to communicate with external authentication servers that contain user information. The user information includes usernames and passwords; it may also include privilege information or reference an end-user profile name. The Login Banner feature allows you to change the banner that displays whenever someone logs into the switch. This feature can be used to display messages about user authorization and security. You can display the same banner for all login sessions or you can implement different banners for different login sessions. You can display a different banner for logins initiated by FTP sessions than for logins initiated by a direct console or a Telnet connection. The switch supports a default login message. A Domain Name System (DNS) resolver is an optional Internet service that translates host names into IP addresses. Every time you enter a host name when logging into the switch, a DNS service must look up the name on a server and resolve the name to an IP address. You can configure up to three domain name servers that will be queried in turn to resolve the host name. If all servers are queried and none can resolve the host name to an IP address, the DNS fails. If the DNS fails, you must either enter an IP address in place of the host name or specify the necessary lookup tables on one of the specified servers. Note. You do not need to enable the DNS resolver service unless you want to communicate with the switch by using a host name. If you use an IP address rather than a host name, the DNS resolver service is not needed. File Management Specifications: File Transfer Methods: FTP, Zmodem Switch Software Utility: OmniSwitch as an FTP Client Configuration Recovery: The /flash/certified directory holds configurations that are certified as the default start-up files for the switch. They will be used in the event of a non-specified reload. Switch /flash Directory: 64 MB flash memory available for switch files and directories Contains the /certified and /working directories File/Directory Name Metrics: 32 characters maximum for directory and file names 255 character maximum for a fully qualified path File/Directory Name Characters: Character types are limited to a-z, A-Z, 0-9, dashes (-), dots (.), and underlines (_) Maximum Number of Files/Directories: Maximum of 244 files and/or directories allowed in the root (flash) directory. Sub-Directories: Up to seven sub-directories allowed including /flash. Text Editing: Vi standard UNIX editor. The Ed standard UNIX editor is available in the debug mode. System Clock: Set local date, time and time zone, Universal Time Coordinate (UTC), Daylight Savings (DST or summertime). System Date Default Value: THU JAN 01 1970 (Thursday, January 1, 1970) A number of CLI commands allow you to manage files on your switch by grouping them into subdirectories within the switchs flash directory. These commands perform the same functions as file management software applications (such as Microsofts Explorer) perform on a workstation. For documentation purposes, we have categorized the commands into three groups. Directory commands allow you to create, copy, move, remove, rename, and display directories. File commands allow you copy, edit, rename, remove, change, and display file attributes. Utility commands display memory and system diagnostic information. There are three common methods for loading software to and from your switch. The method you use depends on your workstation software, your hardware configuration, and the location and condition of your switch. FTP ServerYou can use the switch as an FTP server. If you have FTP client software on your workstation, you can transfer a file to the switch via FTP. This is normally done to load or upgrade the switchs software or configurations. FTP ClientYou can use the switch as an FTP client by connecting a terminal to the switchs console port and using standard FTP commands. This feature is useful in cases where you do not have access to a workstation with an FTP client. ZmodemYou can load software directly through the serial port with any terminal emulator that supports the Zmodem protocol. Note that a Zmodem transfer of large files may take several minutes to complete.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 306 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Directories on the Switch

Available Image Files

Setting the System Clock

Setting Date and Time

The Network Time Protocol (NTP) (NTP Client implementation only)

The Network Time Protocol (NTP) Authentication

When you log into the switch, your current directory is the flash directory. For a factory default switch, the flash directory contains three sub-directories and several files. It is important to understand the relationship of these directories before you load software or edit any of the files. The three directories are described here: Certified directoryThis directory contains configuration files that are certified as the default startup files for the switch. These are the trusted configuration and binary image files. They will be used in the event of a non-specified reload. Do not attempt to edit these files. The path to this directory is /flash/certified. Working directoryThe working directory is a repository for configuration files that you are working on. If you are working on configuration files to develop a custom switch application, you may want to test them before certifying them as the switchs default. To do this, you can boot from the files in the working directory while preserving the files in the certified directory. When the files in the working directory are tested and working properly, you may certify them as the switchs default files. The files are then copied into the certified directory to replace the old ones. The path to this directory is /flash/working. Network directoryThis directory holds files that may be required by servers used for authentication. Other files can be put into this directory if desired. The path to this directory is /flash/network. Kadvrout.img: Optional Advanced Routing (Advanced Routing) Kbase.img: Base Software (Base Software) K2diag.img: Base Software (Diagnostics) Keni.img: Base Software (Ethernet Images) K2os.img: Base Software (Operating System) Ksecu.img: Optional Security (Security A-VLANs) Krelease.img: Base Software (Release Archive) The switch clock displays time using a 24-hour clock format. It can also be set for use in any time zone. Daylight Savings Time (DST) is supported for a number of standard time zones. DST parameters can be programmed to support non-standard time zones and time offset applications. All switch files and directories listed in the flash directory bear a time stamp. This feature is useful for file management purposes. You can set the local date, time zone, and time for the switch or you can also set the switch to run on Universal Time Coordinate (UTC or GMT). If applicable, you can also configure Daylight Savings Time (DST or Summertime) parameters. The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver. It provides client time accuracies within a millisecond on LANs, and up to a few tens of milliseconds on WANs relative to a primary server synchronized to Universal Coordinated Time (UTC) (via a Global Positioning Service receiver, for example). NTP Specifications: RFCs supported: 1305-Netwok Time Protocol Maximum number of NTP severs per client: 3 Note. The Alcatel-Lucent OmniSwitch 6600, 6800, 6850, 7700, 7800, 8800 and 9000 switches can only be NTP clients in an NTP network. They cannot act as NTP servers. Note. Alcatel-Lucents current implementation of NTP only allows the OmniSwitch to act as a passive client, not as a server. A passive client only receives NTP information and adjusts its time accordingly. NTP is designed to use MD5 encryption authentication to prevent outside influence upon NTP timestamp information. Using a key file does this. The key file is loaded into the switch memory, and consists of a text file that lists key identifiers that correspond to particular NTP entities. If authentication is enabled on an NTP switch, any NTP message sent to the switch must contain the correct key ID in the message packet to use in decryption. Likewise, any message sent from the authentication-enabled switch will not be readable unless the receiving NTP entity possesses the correct key ID. The key file is a text (.txt) file that contains a list of keys that are used to authenticate NTP servers. It should be located in the /networking directory of the switch. Key files are created by a system administrator independent of the NTP protocol, and then placed in the switch memory when the switch boots.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 307 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Management software

The Management Files

The Management Software Directory Structure

Software Rollback feature The directory structure inherent in the Management software allows for a switch to return to a previous, more reliable version of image or configuration files.

Management Software Redundancy

Chassis Management software runs the OmniSwitch Series. The directory structure of the software is designed to prevent corrupting or losing switch files. It also allows you to retrieve a previous version of the switch software. An OmniSwitch 6850 Series can provide redundancy; in a stacking configuration one switch is designated as the primary, and one is designated as the secondary. Specifications: Size of Flash Memory: 64MB Size of RAM Memory: 256MB Maximum Length of File Names: 32 Characters Maximum Length of Directory Names: 32 Characters Default Boot Directory: Certified Three types of files control the management of a single switch: Image files, which are proprietary code developed by Alcatel-Lucent to run the hardware. These files are not configurable by the user, but may be upgraded from one release to the next. These files are also known as archive files, as they are really the repositories of several smaller files grouped together under a common heading. A configuration file, named boot.cfg, which is an ASCII-based text file that sets and controls the configurable functions inherent in the image files provided with the switch. The user can modify this file. When the switch boots, it looks for the file called boot.cfg. It uses this file to set various switch parameters defined by the image files. A boot file, named boot.slot.cfg, which is an ASCII-based text file that numbers the NI Modules. Modifications to the switch parameters affect or change the configuration file. The image files are static for the purposes of running the switch (though they can be updated and revised with future releases or enhancements). Image and configuration files are stored in the Flash memory (which is equivalent to a hard drive memory) in specified directories. When the switch is running, it loads the image and configuration files from the Flash into the RAM. When changes are made to the configuration file, the changes are first stored in RAM. The directory structure that stores the image and configuration files is divided into two parts: The certified directory contains files that have been certified by an authorized user as the default files for the switch. Should the switch reboot; it would reload the files in the certified directory to reactivate its functionality. The working directory contains files that may or may not be altered from the certified directory. The working directory is a holding place for new files. Files in the working directory must be tested before committing them to the certified directory. You can save configuration changes to the working directory. You can reboot the switch from the working directory using the reload working commands. The running configuration is the current operating parameters of the switch, obtained from information from the image and configuration files. The running configuration is in the RAM memory. Initially, when normally booting the switch, the software is loaded from the certified directory. This is the repository for the most reliable software. When the switch is booted, the certified directory is loaded into the running configuration and used to manage switch functionality. The directory structure inherent in OmniSwitch 6850 Series switch management software allows for a switch to return to a previous, more reliable version of image or configuration files. Changes made to the configuration file may alter switch functionality. These changes are not saved unless explicitly done so by the user. If the switch reboots before the configuration file is saved, then the certified directory is re-loaded and changes made to the configuration file prior to the reboot are lost. Likewise, new image files should be placed in the working (non-certified) directory first. New image or configuration files can be tested to decide whether they are reliable. Should the configuration or images files prove to be less reliable than their older counterparts in the certified directory, then the switch can be rebooted from the certified directory, and rolled back to an earlier version. Once the contents of the working directory are established as good files, then these files can be saved to the certified directory and used as the most reliable software to which the switch can be rolled back to in an emergency situation. Note. It is not necessary to reboot an entire OS6850 switch for synchronization of the configuration. Software redundancy is one of the switchs most important fail over features. For software redundancy, at least two fully operational OmniSwitch 6850 Series switches must exist. In addition, the management software must be synchronized. When two switches are running in a stacked configuration, one unit has the primary role and the second unit has the secondary role at any given time. The primary unit manages the current switch operations while the secondary unit provides backup (also referred to as fail over).

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 308 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Alcatel-Lucents Command line interface (CLI)

ASCII-based Configuration Text Files

Text File Configuration

Alcatel-Lucents Command line interface (CLI) is a text-based configuration interface that allows you to configure switch applications and to view switch statistics. The CLI uses single-line text commands that are similar to other industry standard switch interfaces. However, the Alcatel-Lucent CLI is different from industry standard interfaces in that the AlcatelLucent uses a single level command hierarchy. Unlike other switch interfaces, the Alcatel-Lucent CLI has no concept of command modes. Other CLIs require you to step your way down a tree-type hierarchy to access commands. Once you enter a command mode, you must step your way back to the top of the hierarchy before you can enter a command in a different mode. The Alcatel-Lucent switch will answer any CLI command at any time because there is no hierarchy. CLI Specifications: Configuration Methods: Online configuration via real-time sessions using CLI commands. Offline configuration using text file holding CLI commands. Command Capture Feature: Snapshot feature captures switch configurations in a text file. User Service Features: Command Line Editing Command Prefix Recognition CLI Prompt Option Command Help Keyword Completion Command History (up to 30 commands) Command Logging (up to 100 commands; detailed information) Syntax Error Display Alias Command Option More Command Commands and settings needed for the OmniSwitch 6850 can be contained in an ASCII-based configuration text file. Configuration files can be created in several ways and are useful in network environments where multiple switches must be managed and monitored. Instead of using CLI commands entered at a workstation, you can configure the switch using an ASCII-based text file. You may type CLI commands directly into a text document to create a configuration file that will reside in your switchs /flash directory. Configuration files are created in the following ways: You may create, edit and view a file using a standard text editor (such as MS WordPad or Notepad) on a workstation. The file can then be uploaded to the switchs /flash file directory. You can invoke the switchs CLI configuration snapshot command to capture the switchs current configuration into a text file. This causes a configuration file to be created in the switchs /flash directory. You can use the switchs text editor to create or edit a configuration file located in the switchs /flash file directory. Once you have a configuration file located in the switchs file system you must load the file into running memory to make it run on the switch. You do this by using configuration apply command. You may apply configuration files to the switch immediately, or you can specify a timer session. In a timer session, you schedule a file to be applied in the future at a specific date and time or after a specific period of time has passed (like a countdown). Timer sessions are very useful for certain management tasks, especially synchronized batch updates. Configuration File Specifications: Creation Methods for Configuration Files: Create a text file on a word processor and upload it to the switch. Invoke the switchs snapshot feature to create a text file. Create a text file using one of the switchs text editors. Timer Functions: Files can be applied immediately or by setting a timer on the switch. Command Capture Feature: Snapshot feature captures switch configurations in a text file. Error Reporting: Snapshot feature includes error reporting in the text file. Text Editing on the Switch: Vi standard UNIX editor. The text file configuration feature allows you to configure the switch using an ASCII-based text file. You may type CLI commands directly into a text document to create a configuration file. This file resides in the switchs file system. You can create configuration files in the following ways. You may create, edit and view a file using a standard text editor (such as Microsoft Note Pad) on a workstation. The resulting configuration file is then uploaded to the switch. You can invoke the switchs CLI snapshot command to capture the switchs current configuration into a text file. You can use the switchs text editor to create or make changes to a configuration file.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 309 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Switch User Accounts

Partitioned Switch Management

Switch user accounts may be set up locally on the switch for users to log into and manage the switch. The accounts specify login information (combinations of usernames and passwords) and privilege or profile information depending on the type of user. The switch has several interfaces (console, Telnet, HTTP, FTP, Secure Shell, and SNMP) through which users may access the switch. The switch may be set up to allow or deny access through any of these interfaces. User information may also be configured on external servers in addition to, or instead of, user accounts configured locally on the switch (except end-user profiles, which may only be configured on the switch). User database Specifications: Maximum number of alphanumeric characters in a username: 31 Maximum number of alphanumeric characters in a user password: 47 Maximum number of alphanumeric characters in an end-user profile name: 32 Maximum number of user accounts: 64 Maximum number of end-user profiles: 128 A user account includes a login name, password, and user privileges. The account also includes privilege or profile information, depending on the type of user account. There are two types of accounts: network administrator accounts, and end-user or customer login accounts. Network administrator accounts are configured with user (sometimes called functional) privileges. These privileges determine whether the user has read or write access to the switch and which command domains and command families the user is authorized to execute on the switch. Customer login accounts are configured with end-user profiles rather than functional privileges. Profiles are configured separately and then attached to the user account. A profile specifies command areas to which a user has access as well as VLAN and/or port ranges to which the user has access. The designation of particular command families/domains or command families for user access is sometimes referred to as partitioned management. AAA servers are able to provide authorization for switch management users as well as authentication. (They also may be used for accounting.) User login information and user privileges may be stored on the servers. The following AAA servers are supported on the switch: Remote Authentication Dial-In User Service (RADIUS). Authentication using this type of server was certified with Funk/Juniper Steel Belted RADIUS server (any industry standard RADIUS server should work). Lightweight Directory Access Protocol (LDAP). Terminal Access Controller Access Control System (TACACS+). Authentication-only servers are able to authenticate users for switch management access, but authorization (or what privileges the user has after authenticating) is determined by the switch. Authentication- only servers cannot return user privileges to the switch. The authentication-only server supported by the switch is ACE/Server, which is a part of RSA Securitys SecurID product suite. RSA Securitys ACE/ Agent is embedded in the switch. By default, switch management users may be authenticated through the console port via the local user database. If external servers are configured for other management interfaces but the servers become unavailable, the switch will poll the local user database for login information if the switch is configured for local checking of the user database. The database includes information about whether or not a user is able to log into the switch and what kinds of privileges or rights the user has for managing the switch. The privileges and profiles are sometimes referred to as authorization. Users typically log into the switch through one of the following methods: Console portA direct connection to the switch through the console port. TelnetAny standard Telnet client may be used for logging into the switch. FTPAny standard FTP client may be used for logging into the switch. HTTPThe switch has a Web browser management interface for users logging in via HTTP. This management tool is called WebView. Secure ShellAny standard Secure Shell client may be used for logging into the switch. SNMPAny standard SNMP browser may be used for logging into the switch Available command domains and families are listed below: Domain-admin: file telnet dshell debug Domain-system: system aip snmp rmon web config Domain-physical: chassis module interface pmm health Domain-network: ip rip ospf vrrp ip-routing ipx ipmr ipms Domain-layer-2: 802.1q, vlan bridge stp, linkagg ip-helper Domain-service: dns Domain-policy: qos policy slb Domain-security: session avlan aaa

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 310 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

SNMP Access for a User Account

End-user profiles

Managing Switch Security

Authenticated Switch Access (ASA)

By default, users can access the switch based on the SNMP setting specified for the default user account. The user command, however, may be used to configure SNMP access for a particular user. SNMP access may be configured without authentication and encryption required (supported by SNMPv1, SNMPv2, or SNMPv3). Or it may be configured with authentication or authentication/encryption required (SNMPv3 only). SNMP authentication specifies the algorithm that should be used for computing the SNMP authentication key. It may also specify DES encryption. The following options may be configured for a users SNMP access with authentication or authentication/encryption: SHAThe SHA authentication algorithm is used for authenticating SNMP PDU for the user. MD5The MD5 authentication algorithm is used for authenticating SNMP PDU for the user. SHA and DESThe SHA authentication algorithm and DES encryption standard is used for authenticating and encrypting SNMP PDU for the user. MD5 and DESThe MD5 authentication algorithm and the DES encryption standard is used for authenticating and encrypting SNMP PDU for the user. End-user profiles are designed for user accounts in the carrier market. With end-user profiles, a network administrator can configure customer login accounts that restrict users to particular command areas over particular ports and/or VLANs. End-user profiles are only managed and stored on the switch; profiles are not stored on external servers. Note. End-user profiles cannot be used in conjunction with user-partitioned management; the features are mutually exclusive. Switch security is provided on the switch for all available management interfaces (console, Telnet, HTTP, FTP, Secure Shell, and SNMP). The switch may be set up to allow or deny access through any of these interfaces. (Note that users attempting to access the switch must have a valid username and password.) A user login procedure requires that users be authenticated for switch access via an external authentication server or the local user database. Access to managing the switch is always available for the admin user through the console port, even if management access to the console port is disabled for other users. Switch Security Overview Switch security features increase the security of the basic switch login process by allowing management only through particular interfaces for users with particular privileges. Login information and privileges may be stored on the switch and/or an external server, depending on the type of external server you are using and how you configure switch access. An external RADIUS or LDAP server can supply both user login and authorization information. ACE/Server can provide login information; user authorization information is available through the switchs local user database. External servers may also be used for accounting, which includes logging statistics about user sessions. If an external server is not available or is not configured, user login information and user authorization may be provided through the local user database on the switch. Logging may also be accomplished directly on the switch. Switch Security Specifications: Telnet sessions allowed: 4 concurrent sessions FTP sessions allowed: 4 concurrent sessions HTTP (Web browser) sessions allowed: 4 concurrent sessions Secure Shell session (including SFTP) allowed: 8 concurrent sessions Total sessions (Telnet, FTP, HTTP, console): 13 concurrent sessions SNMP sessions allowed: 50 concurrent sessions Authenticated Switch Access (ASA) is a way of authenticating users who want to manage the switch. With authenticated access, all switch login attempts using the console or modem port, Telnet, FTP, SNMP, or HTTP require authentication via the local user database or via a third-party server. The type of server may be an authentication-only mechanism or an authentication, authorization, and accounting (AAA) mechanism. AAA servers are able to provide authorization for switch management users as well as authentication. (They also may be used for accounting.) User login information and user privileges may be stored on the servers. In addition to the Remote Authentication Dial-In User Service (RADIUS) and Lightweight Directory Access Protocol (LDAP) servers, using a Terminal Access Controller Access Control System (TACACS+) server is now supported with the 6.1.3.R01 release. Authentication-only servers are able to authenticate users for switch management access, but authorization (or what privileges the user has after authenticating) are determined by the switch. Authentication-only servers cannot return user privileges to the switch. The authentication-only server supported by the switch is ACE/Server, which is a part of RSA Securitys SecurID product suite. RSA Securitys ACE/Agent is embedded in the switch. By default, switch management users may be authenticated through the console port via the local user database. If external servers are configured for other management interfaces but the servers become unavailable, the switch will poll the local user database for login information if the switch is configured for local checking of the user database. The database includes information about whether or not a user is able to log into the switch and what kinds of privileges or rights the user has for managing the switch.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 311 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

AAA Servers ----- RADIUS or LDAP

Authentication-only -----ACE/Servers

Management Access Methods

Alcatel-Lucents OmniVista

WebView Web-Based Management (WebView)

AAA servers are able to provide authorization for switch management users as well as authentication (they also may be used for accounting). The AAA servers supported on the switch are Remote Authentication Dial-In User Service (RADIUS) or Lightweight Directory Access Protocol (LDAP) servers. User login information and user privileges may be stored on the servers. Privileges are used for network administrator accounts. Instead of user privileges an end-user profile may be associated with a user for customer login accounts. User information configured on an external server may include a profile name attribute. The switch will attempt to match the profile name to a profile stored locally on the switch. Authentication-only servers are able to authenticate users for switch management access, but authorization (or what privileges the user has after authenticating) are determined by the switch. Authentication-only servers cannot return user privileges or end-user profiles to the switch. The authentication-only server supported by the switch is ACE/Server, which is a part of RSA Securitys SecurID product suite. RSA Securitys ACE/Agent is embedded in the switch. RADIUS: Telnet, FTP, HTTP, Secure Shell LDAP: Telnet, FTP, HTTP, Secure Shell, SNMP ACE/Server: Telnet, FTP, HTTP, Secure Shell Local: Console, FTP, HTTP, Secure Shell, SNMP OmniVista provides a single interface for voice and data. The Alcatel-Lucent OmniVista Network Management System provides network management layer functions across all Alcatel-Lucent enterprise switch products including OmniSwitch 6850 Series. OmniVista is a multi-user environment that is able to discover all Alcatel-Lucent enterprise switches in the network. It also allows multiple users to monitor network-wide activities while providing access to each switch. Please refer to the OmniVista Release 2.3 boilerplate document for a comprehensive coverage of the OmniVista features. The switch can be monitored and configured using WebView, Alcatel-Lucents web-based device management tool. The WebView application is embedded in the switch and is accessible via the following web browsers: Internet Explorer 6.0 and later for Windows NT, 2000, XP, 2003 Firefox 2.0 for Windows and Solaris SunOS 5.10 Windows Vista WebView contains modules for configuring all software features in the switch. Configuration and monitoring pages include context-sensitive on-line help. WebView CLI Defaults: Web Management Command Line Interface (CLI) commands allow you to enable/disable WebView, enable/disable Secure Socket Layer (SSL), and view basic WebView parameters. These configuration options are also available in WebView. Defaults for WebView Configuration through the http command: WebView Status: Enabled Force SSL: Disabled HTTPS port: 443 HTTP pot: 80 HTTP default port configuration This feature provides the user with the ability to specify an HTTP port number that is different than the default port 80 for web based authenticated VLAN feature.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 312 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The Simple Network Management Protocol (SNMP) Network administrators use SNMP to monitor network performance and to manage network resources.

SNMPv1&v2&v3 is supported

SNMPv3

Using SNMPv1&v2 for Switch Security

Using SNMPv3 for Switch Security Encryption & Authentication

The Simple Network Management Protocol (SNMP) is an application-layer protocol that allows communication between SNMP managers and SNMP agents on an IP network. Network administrators use SNMP to monitor network performance and to solve network problems. SNMP provides an industry standard communications model used by network administrators to manage and monitor their network devices. OmniSwitch 6850 Series switches support SNMPv1, SNMPv2, and SNMPv3. SNMP Specifications: RFCs Supported for SNMPv2: o 1902 through 1907 - SNMPv2c Management Framework o 1908 - Coexistence and transitions relating to SNMPv1 and SNMPv2c RFCs Supported for SNMPv3: o 2570 Version 3 of the Internet Standard Network Management Framework o 2571 Architecture for Describing SNMP Management Frameworks o 2572 Message Processing and Dispatching for SNMP o 2573 SNMPv3 Applications o 2574 User-based Security Model (USM) for version 3 SNMP o 2575 View-based Access Control Model (VACM) for SNMP o 2576 Coexistence between SNMP versions SNMPv1, SNMPv2, SNMPv3: The SNMPv3 protocol is ascending compatible with SNMPv1 and v2 and supports all the SNMPv1 and SNMPv2 PDUs SNMPv1 and SNMPv2 Authentication: Community Strings SNMPv1, SNMPv2 Encryption: None SNMPv1 and SNMPv2 Security requests accepted by the switch: Sets and Gets SNMPv3 Authentication: SHA, MD5 SNMPv3 Encryption: DES SNMPv3 Security requests accepted by the switch: Non-authenticated Sets, Nonauthenticated Gets and Get-Nexts, Authenticated Sets, Authenticated Gets and Get-Nexts, Encrypted Sets, Encrypted Gets and Get-Nexts SNMP traps: For a list and description of traps, refer to the SNMP Traps Table in Appendix #1. SNMP MIBs: For a list and description of system MIBs, refer to Industry Standard MIBs and Enterprise (Proprietary) MIBs in Appendix #2. The SNMP agent in the OS6850 switch can communicate with multiple managers. You can configure the switch to communicate with different management stations using different versions of SNMP. The switch supports SNMPv1&v2&v3. SNMPv3 supports the View-Based Access Control Model (VACM) and User-Based Security Model (USM) security models along with these added security features: Message integrityEnsuring that a packet has not been tampered with in transit Time Frame ProtectionLimiting requests to specified time frames. The user can specify a time frame so that any PDU bearing an out of date timestamp will be ignored. EncryptionScrambling the contents of a packet to prevent it from being learned by an unauthorized source AuthenticationDetermining that the message is from a valid source holding the correct privileges. The switch supports the SNMPv1 and SNMPv2c community strings security standard. When a community string is carried over an incoming SNMP request, that community string must match up with a user account name as listed in the community string database on the switch. Otherwise, the SNMP agent in the switch will not process the SNMP request. Note. A community string inherits the security privileges of the user account that creates it. Two important processes are used to verify that the message contents have not been altered and that the source of the message is authentic. These processes are encryption and authentication. The switch uses the Data Encryption Standard (DES) encryption scheme in its SNMPv3 implementation. For DES, the data are encrypted in 64-bit blocks using a 56-bit key. The algorithm transforms 64-bit input into a 64-bit output. The same steps with the same key are used to reverse the encryption. The authentication process ensures that the switch receives accurate messages from authorized sources. Authentication is accomplished between the switch and the SNMP management station through the use of a username and password identified via the snmp station CLI syntax. The username & password are used by the SNMP management station along with an authentication algorithm (SHA or MD5) to compute a hash that is transmitted in the PDU. The switch receives the PDU and computes the hash to verify that the management station knows the password. The switch will also verify the checksum contained in the PDU. Authentication and encryption are combined when the PDU is first authenticated by either the SHA or MD5 method. Then the message is encrypted using the DES encryption scheme. The encryption key is derived from the authentication key, which is used to decrypt the PDU on the switchs side.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 313 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

SNMP Traps

SNMP MIBs

The SNMP agent in the switch has the ability to send traps to the management station. It is not required that the management station request them. Traps are messages alerting the SNMP manager to a condition on the network. A trap message is sent via a PDU issued from the switchs network management agent. It is sent to alert the management station to some event or condition on the switch. Traps can indicate improper user authentication, restarts, the loss of a connection, or other significant events. You can configure the switch so that traps are forwarded to or suppressed from transmission to the management station under different circumstances. SNMP traps: For a list and description of traps, refer to the SNMP Traps Table in Appendix #1. You can display MIB tables and their corresponding command families by using the show snmp mib family command. The MIB table identifies the MIP identification number, the MIB table name and the command family. If a command family is not valid for the entire MIB table, the command family will be displayed on a per-object basis. For a list and description of system MIBs, refer to Industry Standard MIBs and Enterprise (Proprietary) MIBs in Appendix #2. For a list and description of traps, refer to the SNMP Traps Table in Appendix #1.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 314 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850 Series IETF / IEEE Standards

The OmniSwitch 6850 Series is fully compliant with the relevant industry standards to include the following: For further references on these Standards, refer to: www.IEEE.com For further references on these Standards, refer to: www.IETF.org IEEE
Ethernet OAM IEEE Standards Supported: IEEE 802.1agConnectivity Fault Management IEEE 802.3ahCSMA/CD Access Method and Physical Layer Specifications (Future Release) IEEE 802.1DMedia Access Control (MAC) Bridges IEEE 802.1QVirtual Bridged Local Area Networks IEEE Standards Supported: 802.1ad/D6.0 Standard for Local and Metropolitan Area Networks Virtual Bridged Local Area Networks - Amendment 4: Provider Bridges Connectivity Fault Management STP - Bridging (Media Access Control Bridges) IEEE Std. 802.1D - 2004, Media Access Control (MAC) Bridges IEEE Draft Std. P802.1Q-REV/D5.0 CoS/QoS VLANs - Virtual Bridged local Area Networks Draft Standard P802.1Q/D11 IEEE Standards for Local And Metropolitan Area Network: Virtual Bridged Local Area Networks, July 30, 1998 VLAN Stacking MSTP - Multiple VLAN Spanning Tree Security - Port-based Network Access (supplement to 802.1D) Authenticated VLAN (multiple MAC, multiple VLANs per port) IEEE 802.1x MIB Port Access is supported. Protocol VLANs RSTP - Rapid reconfiguration Carrier Sense Multiple Access with Collision Detection (CSMA/CD) 10BASE-T The IEEE 802.3ab standard describes the specifications for the 1000BASE-T twisted-pair GigEth. VLAN tagging Link Aggregation (Dynamic) 10-Gigabit Ethernet Power over Ethernet (PoE) Ethernet flow control Note: the switch does not support honoring the incoming (RX) IEEE 802.3x pause frames, but it does support generating outgoing (TX) IEEE 802.3x pause frames The IEEE 802.3u standard describes the specification 100BASE-TX, & 100BASE-FX Ethernet The IEEE 802.3z standard describes the specifications for the 1000BASE-X fiber optic Gigabit Eth.

IEEE 802.1ad/D6.0 (VLAN Stacking) IEEE 802.1ag IEEE 802.1D-1998 IEEE 802.1D for the GVRP support IEEE 802.1p IEEE 802.1Q

IEEE 802.1QinQ IEEE 802.1s IEEE 802.1x Extended 802.1x IEEE 802.1x MIB Port Access IEEE 802.1v IEEE 802.1w IEEE 802.3 IEEE 802.3i IEEE 802.3ab IEEE 802.3ac IEEE 802.3ad IEEE 802.3ae IEEE 802.3af IEEE 802.3x

IEEE 802.3u IEEE 802.3z

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 315 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IETF -- RFCs
RFC 768 RFC 791 / 894 / 1024 /1349 RFC 792 RFC 793 / 1156 RFC 826 / 903 RFC 854 / RFC 855 RFC 855 RFC 894 RFC 896 RFC 903 RFC 919 / 922 RFC 922 RFC 925 / 1027 RFC 950 RFC 951 RFC 959 / 2640 RFC 1027 RFC 1058 RFC 1024 RFC 1075 RFC 1112 RFC 1122 RFC 1142 RFC 1151 RFC 1155 / 2578-2580 RFC 1156 RFC 1157 / 2271 RFC 1191 RFC 1195 RFC 1212 / 2737 RFC 1213 / 2011-2013 RFC 1215 RFC 1253 / 1850 / 2328 RFC 1256 RFC 1269 / 1657 RFC 1305 / 2030 RFC 1321 RFC 1349 RFC 1370 RFC 1403 / 1745 RFC 1493 RFC 1518 / 1519 RFC 1519 RFC 1534 RFC 1541 / 1542 / 2131 / 3396 / 3442 RFC 1542 RFC 1573 / RFC 2233 / RFC 2863 RFC 1587 / 3101 RFC 1643 / RFC 2665 RFC 1657 RFC 1701 & 1702 RFC 1722 / 1723 / 2453 / 1724 RFC 1724 RFC 1745 RFC 1757 / 2819 RFC 1765 RFC 1771-1774 / 2842 / 2918 / 3392 UDP IP & IP / Ethernet ICMP TCP / IP & MIB ARP & Reverse ARP Telnet & Telnet options Telnet & Telnet options IP & IP / Ethernet Congestion Control ARP & Reverse ARP Broadcasting Internet Datagram Broadcasting Internet Datagram Multi-LAN ARP / Proxy ARP; Statically configured ARP entries Subnetting Bootstrap Protocol (BootP) FTP Multi-LAN ARP / Proxy ARP; Statically configured ARP entries RIPv1 IP & IP / Ethernet DVMRPv2 IGMPv1 Internet Hosts OSI IS-IS Intra-domain Routing Protocol RDP SMIv1 & SMIv2 TCP / IP & MIB SNMPv1 Path MTU Discovery Use of OSI IS-IS for routing in TCP/IP & dual environments MIB & MIB-II SNMPv2 MIB Convention for SNMP Traps OSPFv2 & MIB ICMP Router Discovery Messages BGPv3&v4 MIB NTPv3 & Simple NTP MD5 IP & IP / Ethernet Applicability Statement for OSPF BGP / OSPF Interaction Bridge MIB CIDR CIDR Interoperation Between DHCP and BOOTP Dynamic Host Configuration Protocol (DHCP) Clarifications and Extensions for the Bootstrap Protocol Private Interface MIB OSPF NSSA Option Ethernet MIB BGPv3&v4 MIB 1701Generic Routing Encapsulation (GRE) 1702Generic Routing Encapsulation over IPV4 Networks RIPv2 Protocol Applicability Statement & MIB RIPv2 MIB Extension BGP / OSPF Interaction RMON & MIB OSPF Database Overflow is not currently supported. BGPv4

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 316 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

RFC 1789 RFC 1798 RFC 1812 / 2644 RFC 1850 RFC 1886 RFC 1901, 1902, 1903, 1904, 1905, 1906, 1907 RFC 1908 RFC 1965 RFC 1966 RFC 1997/1998 RFC 2003 RFC 2011 RFC 2012 RFC 2013 RFC 2030 RFC 2042 RFC 2080 RFC 2096 RFC 2104 RFC 2131 / 3046 RFC 2132 RFC 2138 / 2865 / 2868 / 3575 / 2618 RFC 2139 / 2866 / 2867 / 2620

Connectionless Lightweight X.5000 Directory Access Protocol IPv4 Router Requirements OSPF Version 2 MIB DNS for IPv6 -SNMPv2c Management Framework -Coexistence and transitions relating to SNMPv1 and SNMPv2c BGP AS Confederations BGP Route Reflection BGP Communities Attributes -IP Encapsulation within IP. SNMPv2 MIB SNMPv2 MIB SNMPv2 MIB NTPv3 & Simple NTP BGP New Attribute RIPng IP MIB HMAC Message Authentication Dynamic Host Configuration Control (relay) DHCP / BootP Relay DHCP Options and BOOTP Vendor Extensions RADIUS Authentication & Client MIB RADIUS Note on RFC 2620: We support this RFC 2620 through our own Proprietary Private MIB. Although, the mapping between the RFC 2620 and our own Private MIB is not one-to-one, we do support many common objects between the standard version and that of our own Private MIB. OSPF MD5 Signature SFTP Private Interface MIB IGMPv2 (Snooping for layer-2 multicast switching) & MIB Using Domains in LDAP/X.500 Distinguished Names Lightweight Directory Access Protocol (v3) Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names The String Representation of LDAP Search Filters A Summary of the X.500 (96) User Schema for Use with LDAPv3 SNMPv1 PPP Extensible Authentication Protocol (EAP) IPv6 OSPFv2 Virtual Router Redundancy Protocol (VRRP) & MIB PIM-SM Protocol Specifications Administratively Scoped IP Multicast The OSPF Opaque LSA Option BGP MD5 Signature BGP Route Flap Damping IPv6 TCP/UDP MIB RIPv2 NDP ICMPv6 & MIB IPv6 Note: RFC 2893 has been obsoleted by RFC4213. RFC4213 is now supported, but it does not include Automatic tunnels. Therefore, the main difference is that the new RFC4213 does not contain an automatic tunneling capability. DiffServ DiffServ Microsoft Vendor-specific RADIUS Attributes

RFC 2154 RFC 2228 RFC 2233 RFC 2236 / 2933 RFC 2247 RFC 2251 RFC 2252 RFC 2253 RFC 2254 RFC 2255 RFC 2256 RFC 2271 RFC 2284 RFC 2292 / 2373 / 2374 / 2460 / 2462 RFC 2328 RFC 2338 / 3768 / 2787 RFC 2362 RFC 2365 RFC 2370 / 3630 RFC 2385 RFC 2439 RFC 2452 / RFC 2454 RFC 2453 RFC 2461 RFC 2463 / 2466 RFC 2464 / 2553 / 2893 / 3493 / 3513

RFC 2474 / 2475 / 2597 / 3168 / 3246 RFC 2475 RFC 2548

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 317 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

RFC 2570 RFC 2571 RFC 2572 RFC 2573 RFC 2574 RFC 2575 RFC 2576 RFC 2578, RFC 2579, and RFC 2580 RFC 2597 RFC 2616 / RFC 2854 RFC 2618

RFC 2620

RFC 2640 RFC 2644 RFC 2665 RFC 2667 RFC 2668 / RFC 3636 RFC 2674 RFC 2715 / 2932 RFC 2727 RFC 2737 RFC 2740 RFC 2763 RFC 2784 RFC 2787 RFC 2796 RFC 2809 RFC 2819 RFC 2842 RFC 2863 RFC 2865 RFC 2866 RFC 2867 RFC 2868 RFC 2869/2869bits RFC 2882 RFC 2890 RFC 2893

Version 3 of the Internet Standard Network Management Framework Architecture for Describing SNMP Management Frameworks Message Processing and Dispatching for SNMP SNMPv3 Applications User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) View-based Access Control Model (VACM) for SNMP Coexistence between SNMP versions SMIv1 & SMIv2 DiffServ HTTP & HTML RADIUS Authentication & Client MIB Note: We support this RFC 2618 through our own Proprietary Private MIB. Although, the mapping between the RFC 2618 and our own Private MIB is not one-to-one, we do support many common objects between the standard version and that of our own Private MIB. RADIUS Accounting & Client MIB Note: We support this RFC 2620 through our own Proprietary Private MIB. Although, the mapping between the RFC 2620 and our own Private MIB is not one-to-one, we do support many common objects between the standard version and that of our own Private MIB. FTP Changing the Default for Directed Broadcast in Routers (complements IP router requirements) Ethernet MIB IP Tunnel MIB IEEE 802.3 MAU MIB Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions / VLAN MIB Multicast Routing MIB MIB & MIB-II OSPFv3 for IPv6 Dynamic Hostname Exchange for IS-IS Generic Routing Encapsulation (GRE) Definitions of Managed Objects for the Virtual Router Redundancy Protocol BGP Route Reflection Implementation of L2TP Compulsory Tunneling via RADIUS Remote Network Monitoring Management Information Base BGPv4 Private Interface MIB Remote Authentication Dial In User Service (RADIUS) RADIUS Accounting & Client MIB RADIUS Accounting Modifications for Tunnel Protocol Support / Accounting & Client MIB RADIUS Attributes for Tunnel Protocol Support RADIUS Extensions Network Access Servers Requirements: Extended RADIUS Practices Key and Sequence Number Extensions to GRE (extensions defined are not supported) IPv6/IPv4 Dual Stacks Note: RFC 2893 has been obsoleted by RFC4213. RFC4213 is now supported, but it does not include Automatic tunnels. Therefore, the main difference is that the new RFC4213 does not contain an automatic tunneling capability. BGPv4 Accounting Attributes and Record Formats IPv4 Multicast Routing MIB IGMP MIB PIM MIB for IPv4 Introduction to Accounting Management Criteria for Evaluating AAA Protocols for Network Access Dynamic Host Configuration Control (relay) DHCP / BootP Relay IPv6 Tunneling Policy Core

RFC 2918 RFC 2924 RFC 2932 RFC 2933 RFC 2934 RFC 2975 RFC 2989 RFC 3046 RFC 3056 RFC 3060

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 318 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

RFC 3065 RFC 3101 RFC 3168 RFC 3176 RFC 3246 RFC 3289 RFC 3376 (IGMPv3) RFC 3392 RFC 3396 RFC 3411 RFC 3412 RFC 3413 RFC 3414 RFC 3415 RFC 3416, RFC 3417, and RFC 3418 RFC 3442 RFC 3542 / RFC 3587 RFC 3569 RFC 3575 RFC 3623 RFC 3635 RFC 3636 RFC 3768

BGP AS Confederations The OSPF Not-So-Stubby Area (NSSA) Option DiffServ RFC 3176 is for sFlow support DiffServ The RFC 3289 (DiffServ-MIB) IS NOT SUPPORTED. Snooping for layer-2 multicast switching BGPv4 Dynamic Host Configuration Protocol (DHCP) SNMPv3 SNMPv3 SNMPv3 SNMPv3 SNMPv3 SNMPv2c Dynamic Host Configuration Protocol (DHCP) IPv6 An Overview of Source-Specific Multicast (SSM) RADIUS Authentication & Client MIB Graceful OSPF Restart Pause Control IEEE 802.3 MAU MIB Virtual Router Redundancy Protocol (VRRP) & MIB

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 319 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OmniSwitch 6850 Series Typical RFP Questions & Answers Table

OmniiiSwiitch 6850 Veriiffiiied RFP Q & A Omn S w tc h 685 0 V er f e d RF P Q & A O nS 6 r e F &
The OmniSwitch 6850 Series is a powerful layer-2& layer-3 device with wire speed switching, routing and QoS coupled with unique redundancy features that set it apart from other layer-2 & layer-3 switches on the market. The OS6850 Series runs the AOS software making it completely compatible with the OS6600 Series, OS6800 Series, OS7000 Series, OS8000, and OS9000 switches. When placed in the proper environment, the OS6850 Series is a very powerful and effective edge/aggregation switch. The OmniSwitch 6850 Series benefits from a distributed switch architecture that provides redundancy of critical hardware and software elements for a continuous traffic processing in any network conditions without a single point of failure. Om niSwitch 6850 Series Switch Processing Scheme; Non-blocking, and store-and-forward

Typiicall RFP Quessttiions Typ c a R FP Ques o ns y

Layer-2 & Layer-3 Switch? Store-and-Forward-Architecture? Redundant Power Supply with Load-Sharing? Non-blocking Architecture? Forwarding Rate/Throughput? Filtering (ACLs) speed @layer-2&layer-3? Turning-off Rapid Spanning Tree Protocol per interface and also in general? Layer-2 (MAC-Address) Table Size? Layer-3 (IP-Address) Table Size? Automatically recognizing 10/100/1000Mbps on copper interfaces and turning them off? Automatically recognizing full/half-duplex on copper interfaces, and turning them off? Administration through serial interface, SSH, HTTPS, unsecured protocols could be turned-off? Are there any security back doors left open for intrusion? Authentication support for a minimum of two redundant RADIUS-Servers? Configuration could be stored in text document and down loadable through TFTP? SNMPV3 - (RFC 2570-2574) with encoded authentication? SNMP (RCC 1067 and RFC 1157)? SNMP Version 2 (RFC 1905)? DHCP incl. forwarding (RFC 2131), minimum 8 different recognized Server? RADIUS (RFC 2138)? RMON (RFC 2819)? SMON (RFC 2613) OSPF (RFC 2328) with encoded Authentication? VRRP (RFC 2338) with encoded Authentication? CIDR (RFC 1519)? Rapid Spanning Tree (IEEE 802.1w)? Fast Ethernet (IEEE 802.3u)? Gigabit Ethernet (IEEE 802.3z, 802.3x, 802.3ab)?

Allcattelll-Lucentt Veriifiied Ressponses A c at e --Luc ent V er f e d Re ponses L n r e

Comply Comply Comply Comply. Up to 101Mpps on 48-port Models including the 10GigE throughput. Wire-speed. Comply 16K 48K routing table Comply Comply Comply The switch supports many state-of-the-art security features and to the best of our knowledge, there are NO security back doors left open for intrusion. Comply Comply, but instead of TFTP, our switch supports FTP and Secure FTP (sFTP). Comply. SNMPv1, SNMPv2, and SNMPv3 are supported. SNMPv3 RFCs 2570-2576 is also supported. Comply. SNMPv1, SNMPv2, and SNMPv3 are supported. SNMP RFCs 1067 & 1157 are also supported. Comply. SNMPv1, SNMPv2, and SNMPv3 are supported. SNMPv2 RFCs 1902 through 1908 are also supported. Comply. Comply. Comply. Non-Comply. Comply. Comply. Comply. Comply. Comply. Comply. Note on the 802.3x support: the switch does not support honoring the incoming (RX) IEEE 802.3x pause frames, but it does support generating outgoing (TX) IEEE 802.3x pause frames Comply. Comply. YES. NO. NO. Comply.

Link Aggregation (IEEE 802.3ad) support and across switches? VLAN (IEEE 802.1Q) Software-Update without shutdown? Reboot necessary after update? Reboot necessary after changing the configuration? Port Mirroring support?

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 320 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Ability to deactivate a port based on a configurable number of error packets over time (as in, errors per minute)? Ability to deactivate a port based on a configurable number of broadcast packets over time (as in, broadcasts per second)? Link Aggregation? Is Link aggregation supported across stack? Does the switch support the ability to turn off SNMPTraps per port?

NOT automatically. It can be done manually.

YES. The switch can be configured to limit broadcast on a per port basis and it is capable of automatically shutting down the port, if the limit is exceeded. The switch supports up to 32 link aggregation groups and up to 8 physical ports per link aggregation group. The Link aggregation is supported across stack. NO. The switch has the ability though to optionally enable and/or disable SNMP trap(s) and optionally sending them to designated destinations. But, there is no ability to control them at the switch and/or port level. Note: the port(s) optionally, but manually can be configured to be administratively "down" or "up" as required. Comply. NO. RMON-I RFC 2819 (with 4-groups) is supported only. NO. SNMPv1, SNMPv2, and SNMPv3 are supported. SNMPv3 RFCs 2570-2576 is supported only. The switch will support a maximum of 256 IP addresses for each Relay Service. Initially, the switch will support a maximum of 8 IP addresses for each VLAN Relay Service and a maximum of 256 VLAN Relay Services. YES. NO. SNMP can be used to restrict access and/or cut-off access to the switch, but it cannot be used to power-down the switch. NO. SNMP can be used to restrict access and/or cut-off access to the switch with time-delay, but it cannot be used to power-down the switch. Comply. Comply. Comply.

SNMP-authentication over RADIUS-Server? RMON (RFC 2021)? SNMPv3 (RFC 3411 to RFC 3418 (STD 0062)? DHCP-Forwarded/Relay Service capabilities? VLAN & DHCP-Forwarded/Relay Service capabilities? Is the data traffic on the backplane measurable? Could the switch be turned-off via SNMP? Could the switch be turned-off via SNMP with time-delay? Does the switch support the capability to turn-off all protocols except IP? IPv6? IGMPv1 (RFC 1112)? IGMPv2 (RFC 2236)? IGMPv3 (RFC 3376)? 802.1AB MAC address duplication what is the behavior of the network if duplicate MACs are discovered?

RADIUS interaction At what point is a RADIUS stop message sent to the RADIUS server? How does switch behave / handle a user's PC shutting down/unplugged from the port?

Comply. In a bridged environment? In a bridged environment (same VLAN), when an Alcatel-Lucent switch sees a local MAC address advertised via any port other than the port it was originally learned, the switch will flush that MAC from its table and begin forwarding traffic to that MAC via the port it was just advertised on. If the original MAC begins transmitting again, the switch will advertise that it now owns the MAC and the other switch will flush the MAC from its table. This will cause flapping for the traffic destined for the legitimate MAC address. One solution to this problem is to utilize IEEE 802.1x authentication for IEEE 802.1x devices, and MAC address port binding for network devices that dont support IEEE 802.1x. In a RADIUS environment - with MAC authentication and IEEE 802.1x: If a MAC address is found on another port, the initial MAC is logged off. If both devices continue to send, both will be disconnected from the network and the RADIUS server will see repeated logon attempts, which can be disabled (multiple logon restrictions). NOTE: In the event that a duplicate MAC is discovered on the network in the same VLAN, the switch CPU is not in danger of being subject to what would be a denial of service attack. Alcatel-Lucent would welcome a product enhancement request (PER) for the Alcatel-Lucent Operating System to handle this scenario without a RADIUS server. Possible solutions could include: shutdown the MACs after x flaps, hold the initial MAC address after a move, or send notifications to the network management software. In a routed environment? In a routed environment (separate VLAN), there will be no action taken by the Alcatel-Lucent switch since the MAC address is not appearing in the same broadcast domain. RADIUS stop/start - for both 802.1x and MAC Authentication a RADIUS start message is sent after authentication is completed. A RADIUS stop message is sent on a "logoff action", which include: Logoff of the client Port down (loss of link, unplugging of device) When the switch receives a stop message all traffic from that MAC will be disassociated from its authenticated VLAN. If the MAC begins transmitting again, the Alcatel-Lucent switch will begin the authentication / authorization process anew.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 321 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

What operations require the switch to reboot?

How long after reboot before the switch can join the network and pass traffic?

Configuration via Web browser? DHCP auto-configuration of multiple switches via boot server? Auto-sensing on each 10/100 port Auto-negotiating on all ports- half- or full-duplex transmission mode Dynamic Trunking Protocol (DTP) across all switch ports Port Aggregation Protocol (PAgP) or like technology Link Aggregation Control Protocol (LACP) that conforms to IEEE 802.3ad DHCP Server DHCP Relay 802.3ab-1000BASE-SX, 1000BASE-LX, 1000BASE- BX10, SFP/GBIC 802.3u- 100BASE-FX, 100BASE-BX, and 100BASE-SX Default configuration stored in flash memory Automatic interface crossover (Auto-MDIX) Time-domain Reflectometry (TDR) to diagnose and resolve cabling problems on copper ports IEEE 802.1w Rapid Spanning Tree Protocol Per-VLAN Rapid Spanning Tree allows rapid spanning-tree re-convergence on a per-VLAN spanning-tree basis Command-switch redundancy Unidirectional Link Detection Protocol (UDLD) or like technology Switch port auto-recovery Redundant Power System Per-port broadcast, multicast, and uni-cast storm control IEEE 802.1 d Spanning Tree Protocol

Alcatel-Lucent switches will reboot for catastrophic Hardware & Software failures, which we call "Exceptions". Examples of Exceptions include: Unexpected Hardware failure such as: o Unexpected Memory failure o Unexpected Flash failure Unexpected Software corruption Generally speaking any "unexpected" catastrophic event will cause both chassis-based Models and/or stackable switch Models to reboot. Note: that in a stackable switch Model configuration, only the "failed" switch unit will reboot, while the traffic through the other switch units will be uninterrupted. Alcatel-Lucent switches do not need to reboot after software upgrades or configuration changes, including 802.1D, 802.1s, or 802.1w (Spanning Tree protocol standard, rapid, and per VLAN, respectively). OmniSwitch 9000 Series: OmniSwitch 9700 / 9600 30 to 45 seconds, depending on Network Interface modules and configuration. OmniSwitch 6850 Series: Stand-alone: Depending on the configuration, a switch can reload and begin passing traffic in as little as 30 seconds, to as long as 115 seconds. OmniSwitch 6850 stack of two to eight: 90 to 115 seconds Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant through Bootp/DHCP Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant through the implementation of GVRP which is a standards-based Protocol. Alcatel-Lucent Response: Compliant through the implementation of Static and Dynamic (IEEE 802.3ad) Link Aggregation Protocols. Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Non-Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Future Compliant (TDR will be supported in a Future Release) Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant

Alcatel-Lucent Response: Compliant through the implementation of VRRP which is a standards-based Protocol. Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Partial-Compliant Switch Port recovery from a disabled condition will require Manual Admin. Intervention. Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 322 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IEEE 802.1s Multiple Spanning Tree Protocol allows a spanning-tree instance per VLAN, enabling Layer 2 load sharing on redundant links IEEE 802.1Q VLAN Trunking Egress committed rate (ECR) Local Proxy Address Resolution Protocol (ARP) Internet Group Management Protocol (IGMP) version 3 snooping IGMP filtering Multicast VLAN registration (MVR) Standard 802.1 p CoS and DSCP field classification QoS ACLs on all ports Four egress queues per port Smoothed Round Robin (SRR) scheduling

Alcatel-Lucent Response: Compliant

Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant through the implementation of Egress Rate Shaping. Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Partial-Compliant through the implementation of: There are three queuing schemes available for each switch port: one strict priority scheme and two weighted fair queuing (WFQ) schemes. By default the strict priority scheme is used and consists of eight priority queues (SPQ). All eight queues on the port are serviced strictly by priority. Lower priority traffic is dropped in the presence of higher priority traffic. The following WFQ schemes are available: WRRAll queues participate in a weighted round robin scheme. Traffic is serviced from each queue based on the weight of the queue. DRRAll queues participate in a dynamic round robin scheme. Traffic is serviced from each queue based on the weight of the queue. Alcatel-Lucent Response: Compliant through the implementation of a threshold-based mechanism per queue. Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant

Weighted tail drop (WTD) for congestion avoidance Strict priority queuing guarantees Rate limiting based on source and destination IP address, source and destination MAC address, Layer 4 TCP and UDP information, or any combination of these fields, using QoS ACLs (IP ACLs or MAC ACLs), class maps, and policy maps Asynchronous data flow shaping Up to 64 aggregate or individual polices per port IEEE 802.1x port-based security and user authentication IEEE 802.1x with dynamic VLAN assignment IEEE 802.1x port IEEE 802.1x for Guest VLAN Port-based ACLs Uni-cast MAC filtering Unknown uni-cast and multicast port blocking SNMPv3 RADIUS and or TACACs authentication MAC address notification DHCP snooping DHCP Interface tracker MAC address aging Multilevel security on console access User-selectable address learning BPDU support Spanning-Tree Root Guard (STRG) support IGMP filtering

Alcatel-Lucent Response: If this is referring to ATM, then the answer is NO (Non-Compliant). Otherwise, single and/or multiple data-flow based shaping are supported (Compliant). Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant

Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response:

Compliant Compliant Compliant Compliant Compliant Compliant Compliant Compliant through the implementation of DHCP Option-82. Compliant

Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 323 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Dynamic VLAN assignment Support for ACES

VLAN trunks on any port (802.1 Q tagging) Up to 255 VLANs per switch Up to Four thousand VLAN IDs supported Remote SPAN (RSPAN) monitoring Embedded Remote Monitoring (RMON) software agent Layer-2 trace route Domain Name System (DNS)

Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Partial-Compliant. L1-L4 ACLs is supported. L1-L4 Access Control Lists (ACLs) to filter out unwanted traffic including denial of service attacks are supported; Access control lists (ACLs) are per port, MAC SA/DA, IP SA/DA, TCP/ UDP port; Flow based filtering in hardware (L1-L4). Support for Access Control List Manager (ACLMAN): ACLMAN is a function of the QoS subsystem in AOS. ACLMAN allows a network administrator to manage ACLs using default industry standard syntax on Alcatel-Lucent switches. To enforce the ACLs, ACLMAN translates default industry standard syntax into Alcatel-Lucent QoS filtering policies in a manner transparent to the ACLMAN user. Alcatel-Lucent Response: Compliant

Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant through the implementation of a layer-2 link trace capability as provided by the IEEE 802.1ag support. Alcatel-Lucent Response: Compliant through the implementation of a DNS Resolver feature: A Domain Name System (DNS) resolver is an optional Internet service that translates host names into IP addresses. Every time you enter a host name when logging into the switch, a DNS service must look up the name on a server and resolve the name to an IP address. You can configure up to three domain name servers that will be queried in turn to resolve the host name. If all servers are queried and none can resolve the host name to an IP address, the DNS fails. If the DNS fails, you must either enter an IP address in place of the host name or specify the necessary lookup tables on one of the specified servers. Note. You do not need to enable the DNS resolver service unless you want to communicate with the switch by using a host name. If you use an IP address rather than a host name, the DNS resolver service is not needed. Alcatel-Lucent Response: Partial-Compliant through the implementation of FTP which is supported. Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Non-Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant

Trivial File Transfer Protocol (TFTP) Network Timing Protocol (NTP) Multifunction LEDs per port for port status SNMPv1, v2c, and v3 and Telnet interface Power over Ethernet 802.3af, with port selectable capability Internal-Power-Supply Connector Internal auto-ranging power supply Support for input voltages between 100 and 240VAC Supplied AC power cord to connect the AC power connector to an AC power outlet Options for redundant power support Power over Ethernet support IEEE 802.3af (port switch selectable) 100BASE-TX ports: RJ-45 connectors, 2-pair Category 5,5e UTP cabling 1000BASE-T ports: RJ-45 connectors, 4-pair Category 5,5e,6 UTP cabling 1000BASE-T SFP-based ports: RJ-45 connectors, 4-pair Category 5, 5e, 6 UTP cabling 10GBASE-T ports: RJ-45 connectors, 4-pair Category 5, 5e, 6 UTP cabling 100BASE-SX, -BX, -FX: (single/multimode fiber) 1000BASE-SX, -LX,-BX (single/multimode fiber) 10GBASE-LR Dark fiber SMF/1310 nm 10 km 10GBASE-ER Dark fiber SMF/1550 nm 40 km 10GBASE-SR Dark fiber MMF/850 nm 65 meters 10/100/1000BASE-T copper SFP 10GBASE-R (64B/66B encoding) The device must switch and apply ACLs to IPv4 and IPv6 packets in hardware. IPv6 ACLs IPv4/IPv6 dual mode IP stack

Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant

Alcatel-Lucent Response: Partial-Compliant through the implementation of 10GBASE-CX4 Alcatel-Lucent Response: Compliant

Alcatel-Lucent Response: Non-Compliant (we currently comply with the 1000BASE-T copper SFP. To comply with the 10/100/1000BASE-T copper SFP will require further evaluation and testing. Alcatel-Lucent Response: Non-Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 324 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

RIPng RIP Next Generation, IPv6 enabled Multicast Listener Discovery (MLD) for IPv6 Path MTU Discovery for IPv6 IPv6 to IPv4 Translation IPv6 Tunnels ICMPv6 messaging, trace route, ping and SSHv2 Must support a minimum of 1000 centralized ACLs Dot1p IP Redundant Ring Capability using RFC 3619 Ethernet Automation Protection Switching (EAPS) and EAPSv2. IEEE 802.1ad Virtual MANs (vMANs) RFC 2474 DiffServ Precedence, including 8 queues/port RFC 2598 DiffServ Expedited Forwarding (EF) RFC 2597 DiffServ Assured Forwarding (AF) RFC 2475 DiffServ Core and Edge Router Functions PVST+, Per VLAN STP (802.1Q interoperable) 2K centralized ACL rules per switch and 4K VLANs (Port, Protocol, IEEE 802.1Q) Trivial File Transfer Protocol (TFTP) remote firmware upgrades Recovery Configurations Hot Lock ACLs L2 & L3 ACL on the same interface ACLs

Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Non-Compliant Alternative solution: Our own version of RRSTP with less than 50msec re-convergnece time. Alcatel-Lucent Response: Compliant (this is Q-in-Q or VLAN Stacking) Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Compliant Compliant Compliant Compliant Compliant

Alcatel-Lucent Response: Compliant with FTP and Secure FTP only. Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Non-Compliant Note: L2-L4 ACLs are supported. Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Note: L2-L4 ACLs are supported. Per switch: 2000 Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Non-Compliant Alcatel-Lucent Response: Partial-Compliant (software upgrades will require a brief re-boot) Alcatel-Lucent Response: Compliant: Non-stop, carrier class availability Alcatel-Lucent Response: Compliant: As required to support data links with different Maximum Transmission Unit (MTU) sizes. Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: N/A Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant with wire-rate. There are no oversubscriptions. Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Compliant Alcatel-Lucent Response: Non-Compliant Alcatel-Lucent Response: Non-Compliant Alcatel-Lucent Response: Compliant. Raw Fabric Capacity: Depending on the Model up to 224Gbps aggregate Throughput with 64Byte packets: Depending on the Model up to 101.2Mpps in a stand-alone config. Alcatel-Lucent Response: Compliant. Raw Fabric Capacity: Depending on the Model up to 224Gbps aggregate Throughput with 64Byte packets: Depending on the Model up to 101.2Mpps in a stand-alone config. Alcatel-Lucent Response: Compliant. Raw Fabric Capacity: Depending on the Model up to 224Gbps aggregate Throughput with 64Byte packets: Depending on the Model up to 101.2Mpps in a stand-alone config.

L2 Hitless Forwarding L3 Hitless Forwarding Integrated Cable Management Hitless Software Upgrades Track Record SAR OSPF/BGP Graceful Restart Hardware 19" mountable 240 V AC power input Modular switch type Stackable switch type Redundant power supply possible Redundant CPU Redundant Switching Engine 10 Gbps uplinks possible Upgradable to 4 x 1 Gbps uplink Oversubscritpion max. 4:1 Non-blocking PoE (802.3af) ports >= 500 Gbps L2 switching capacity >= 350 Mpps L3 switching capacity >= 90 Gbps L2 switching capacity

>= 90 Mpps L3 switching capacity

>= 60 Gbps L2 switching capacity

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 325 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

>= 48 Mpps L3 switching capacity

>= 30 Gbps L2 switching capacity

Modular uplinks (GBICs or SFPs) Temperature range (Celsius) Dimensions (HxLxD)

Weight (kg)

Thermal rating (BTU/h) Bridging/Switching Ethernet 802.3 802.3ab (1000 Base-T) 802.3ae (10 Gbps) 802.3u (100Mbps) 802.3x (full duplex)

Alcatel-Lucent Response: Compliant. Raw Fabric Capacity: Depending on the Model up to 224Gbps aggregate Throughput with 64Byte packets: Depending on the Model up to 101.2Mpps in a stand-alone config. Alcatel-Lucent Response: Compliant. Raw Fabric Capacity: Depending on the Model up to 224Gbps aggregate Throughput with 64Byte packets: Depending on the Model up to 101.2Mpps in a stand-alone config. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. 0 to 45C Chassis size without P/S or P/S shelf 17.32 x 10.63 x 1.73 in (44.0 x 27.0 x 4.4 cm) Total size including P/S shelf and mounting ears 19.00 x 17.56 x 1.73 in (48.2 x 44.6 x 4.4 cm) Chassis size with mounting ears, without P/S or P/S shelf 19.00 x 10.63 x 1.73 in (48.2 x 27 x 4.4 cm) "PoE Models without the P/S: OS6850-P24/-P24H/-P24L/-P24LH: 3.91kg OS6850-P24X/-P24XH: 4.02 kg OS6850-P48/-P48H/-P48L/-P48LH: 4.26 kg OS6850-P48X/-P48XH: 4.35 kg Non-PoE Models without the P/S: OS6850-24/-24D/-24L/-24LD: 3.79 kg OS6850-24X/-24XD: 3.91kg OS6850-48/-48D/-48L/-48LD: 4.06 kg OS6850-48X/-48XD: 4.14 kg OS6850-U24X/-U24XD: 3.91kg Depending on the Model: From 198 to 584 BTU/hr. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant with eception: Note: the switch does not support honoring the incoming (RX) IEEE 802.3x pause frames, but it does support generating outgoing (TX) IEEE 802.3x pause frames Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Non-Compliant. Alcatel-Lucent Response: Compliant.

802.3z (1000Base-X) jumbo frames up to 9000 bytes VLANs more than 250 VLANs per switch and network at least 4000 VLAN ID's statically (manual) assigned VLAN on a port Dynamic VLANs based on - MAC address - Authentication (802.1x) - Private VLAN More than one Default Gateway per VLAN (Secondary addresses) Voice VLAN

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 326 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Automatically detect IP-phone 802.1q 802.1q, 250 VLANs on trunk 802.1q, Q-in-Q Trunking auto negotiation GVRP Spanning tree MISTP, 802.1s RSTP, 802.1w STP, 802.1d STP parameters configurable Link Aggregation Control Protocol LACP, 802.3ad possible for 10 Mb/s, 100Mb/s, 1Gb/s, 10 Gb/s Bundled links on different modules possible Max. number of bundled links per switch balancing based source and/or destination MAC-, IPaddress and port numbers possible Power over Ethernet 802.3af 50% of the ports can be fully powered automatically monitors power budget configurable per port Auto negotiation Speed Duplex Auto-MDXI automatic crossover on all Ethernet interfaces Layer 1 failure detection auto detect miswired links Traffic storm multicast/broadcast storm control configurable broadcast level Link Layer Discovery Protocol LLDP, 802.1ab can be enabled and disabled per interface System time can be set manually can be set automatically via NTP Bridging between VLANs Fail safe stacking Automatic configuration Automatic new unit configuration Support of Microsoft Load Balancing Protocol

Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. 32 aggregates of up to 8 ports each, per stand-alone switch and/or across units Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucents Server Load Balancing (SLB) is supported instead.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 327 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Security Authentication Login to device via password when logging in via - console port - telnet - SSH User group support one time authentication Security server. Which one? (Radius, Kerberos,..) - Accounting - Possible to record executed commands on the remote server - Redundancy possible TCP SYN flooding prevention Access Control Lists (ACL) Layer 3 Filter based on - Source address/network and/or - Destination address/network - Type of packet - TOS value - Upper layer protocol (at least Layer 4) - Any combination of these items ACL per interface possible inbound/outbound time range for access lists possible on any interface (physical and virtual) Logging possible Dynamic access lists Reflexive ACLs (automatically allow return traffic) ACLs have no impact on switching performance Layer 2 filter possible - Source MAC-address - Destination MAC-address - EtherType ACLs are possible for bridged traffic also Stateful packet inspection Intrusion detection Endpoint port security (Network access control) Devices fulfil all requirements for implementing Endpoint port security Denial of service (DoS) Rate limit traffic to processor in hardware 802.1x Redundant RADIUS servers possible Connection to Active Directory possible EAP authentication mechanisms - EAP-Message Digest 5 (MD5) - EAP-Transport Layer Security (TLS) - EAP-Tunnelled TLS (TTLS) - Protected Extensible Authentication Protocol (PEAPv0/EAP-MSCHAPv2) Static and dynamic VLAN assignment based on 802.1x authentication If authentication fails, there are the following configurable possibilities - port stays closed - port is assigned to a VLAN which can be configured on per port basis. - If authentication fails because backend server (RADIUS) is not available there should be the option to open the port anyway.

Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response:

Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Non-Compliant. Compliant. Compliant. Compliant. Non-Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Non-Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant.

Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 328 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Guest VLAN possible 802.1x behind telephone Multi Host Single Authentication Port security Limit port to definable MAC addresses Send notification when there is a violation Automatically convert MAC addresses into secure addresses DHCP snooping DHCP snooping configurable per port Routing and IP (L3 devices only) Loopback interface Loopback or virtual management interface configurable Classless routing CIDR supported ARP Proxy ARP Possible to turn proxy ARP on and off Configure ARP entries manually ARP inspection IP services ICMP Protocol Unreachable Messages (RFC792, RFC1122) ICMP Mask Reply Messages (RFC792, RFC1122) Set maximum MTU Packet Size per IP interface ICMP Redirect Messages (RFC792, RFC1122) Path MTU Discovery (RFC1191) IP Source Routing (RFC 791) ICMP Internet Router Discovery Protocol (IRDP) IRDP (RFC 1256) must be supported TCP parameter Setting the TCP Connection Attempt Time Enabling TCP Time Stamp (RFC 1323) Setting the TCP Outgoing Queue Size Enabling TCP Selective Acknowledgment (RFC2018) Setting the TCP Window Size Broadcast handling Forward broadcast via Layer 3 borders Routing redistribution Redistribution of routes between routing protocols possible Configurable metric/cost Filtering routes possible Configure sequence of routing protocols as routing information source Routing Information Protocol (RIP, RFC 1058) RIP v1 and RIP v2 supported Configurable metric/cost per route Possible to adjust RIP timers Summarization possible RIP v2 authentication Split horizon Open Shortest Path First (OSPF). OSPF supported Definition of areas Definition of stub areas Configurable routing interface parameters Not-so-stubby-areas (NSSAs) per RFC 1587 Plain text and MD5 authentication Virtual links ABR, ABSR possible More than one OSPF process Associate networks with OSPF process

Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response:

Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant.

Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Compliant. Compliant. Compliant. Compliant.

Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 329 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Summarization possible Generate Default Route Prevent routing information and hello per interface Configurable OSPF timers Network address translation (NAT) NAT (RFC1631) supported Bidirectional translation Statical address mapping Dynamic address translation Port Address Translation (PAT) Address translation in application layer DHCP Server DHCP server functionality supported DHCP Relay Agent DHCP relay supported DNS Name resolution supported Mobile IP RFC 2002, IP Mobility Support RFC 2005, Applicability Statement for Mobile IP RFC 2003, IP Encapsulation within IP RFC 2006, The Definitions of Managed Objects for IP Mobility Support IP multicast PIM dense and sparse mode or DVMRP IGMP v1 (RFC 1112) IGMP v2 (RFC 2236) IGMP snooping (layer 2 devices) Multicast Source Discovery Protocol (MSDP, RFC 3618) Virtual Router Redundancy Protocol (VRRP, RFC 3768) VRRP is supported VRRP groups per VLAN VRRP priority configurable VRRP MD5 authentication IPv6 IPv6 in hardware Multiprotocol BGP for IPv6 VRRP in IPv6 Mobile IPv6 IPv6 Multicast IP Flow monitoring for IPv6 Policy-Based Routing for IPv6 RIP for IPv6 Traffic Filters and Firewalls for IPv6 Security DHCP for IPv6 IPSec in IPv6 IPv6 over MPLS NAT for IPv6 OSPF for IPv6 QoS for IPv6 Static Routes for IPv6 Tunneling for IPv6 Policy based routing Policy based routing supported

Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response:

Compliant. Compliant. Compliant. Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Compliant. Compliant. Non-Compliant. Compliant. DNS Resolver is supported. Non-Compliant. Non-Compliant. Non-Compliant. Compliant. Non-Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Non-Compliant.

Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Compliant. Compliant. 255 Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Non-Compliant. Compliant. Non-Compliant. Compliant. This feature will be supported in a Future Release. Compliant. Compliant. Non-Compliant. Compliant. This feature will be supported in a Future Release. Compliant. This feature will be supported in a Future Release. Non-Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 330 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Routing criteria based on ACLs Multiprotocol Label Switching (MPLS) MPLS LSR and LER supported Layer 3 VPNs Layer 2 VPNs Multiprotocol Label Switching Quality of Service Multiprotocol Label Switching Traffic Engineering Quality of Service QoS configuration on virtual and physical interfaces Classification Classification of traffic based on: - IP ToS/DSCP and IEEE 802.1p CoS values - IP ACLs - MAC ACLs ToS to CoS rewrite possible QoS marking based on classification Policing and shaping Configurable ingress and egress queues Configurable queuing mechanism (please indicate which one) Priorization mechanism for real time traffic (e.g. voice) Mechanisms for congestion avoidance. (please indicate which one) Management Address assignment Address assignment statically Address assignment dynamically via DHCP Switch Cluster Up to 8 devices with one management address Backup possible Command Line Interface (CLI) CLI via console port CLI remotely via telnet and SSH up to 4 simultanous sessions Command history Help system Command logging Identical CLI as all other device types Graphical User Interface (GUI) GUI via http GUI via https (SSL) up to 4 simultaneous sessions Password protected access Restricted access via filter SNMP SNMPv1 (RFC 1157) SNMPv2C (RFCs 1901 to 1907) SNMPv3 (RFCs 2273 to 2275) SNMP traps configurable More than one trap receiver configurable Macros Macros (set of CLI commands) supported Port mirroring Port mirroring possible Multiple source ports to one destination port possible Multiple mirroring sessions at the same time Configuration via CLI and SNMP Remote Mirroring (Source and Destination ports are on different switches) possible

Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response:

Compliant. This feature will be supported in a Future Release. Compliant. This feature will be supported in a Future Release. Compliant. This feature will be supported in a Future Release. Compliant. This feature will be supported in a Future Release. Compliant. This feature will be supported in a Future Release. Compliant. This feature will be supported in a Future Release. Compliant. This feature will be supported in a Future Release.

Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Strict Priority, WRR, and DRR Alcatel-Lucent Response: Compliant. Alcatel-Lucent Response: Compliant. Congestion avoidance strategies and technologies are supported through the implementation of a threshold-based mechanism per queue. Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 331 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Remote Monitoring (RMON) RMON (RFC 1757) supported Statistics, History, Alarms and Events supported Syslog System messages can be logged locally (CLI) System messages can be logged on a syslog server (RFC 3164) Severity level of messages configurable More than one syslog servers configurable Messages can be time stamped Integrated Service Level Monitoring Integrated Service Level Monitoring supported It is possible to measure: - Delay (both round-trip and one-way) - Jitter (directional) - Packet loss (directional) - Packet sequencing (packet ordering) - Path (per hop) - Connectivity (directional) - Server or website download time - Voice quality scores Data accessible via SNMP Send notifications based on configurable thresholds Diagnostics Online diagnostics Diagnostics on demand via CLI Health monitoring Configurable health threshold with notification Troubleshooting Ping Traceroute Image and Configuration file Image and Configuration file are up- and downloadable via TFTP or FTP Configuration file is in text format Debugging Debugging for all features possible Debugging can be turned on and off per feature Debugging output via console or remote terminal

Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: FTP only. Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response: Alcatel-Lucent Response:

Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Non-Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant. Compliant.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 332 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Alcatel-Lucent AOS Value Propositions

1. 2. 3. 4. 5. Value High Availability Embedded Security Distributed Intelligence Simplified Management

Value
Alcatel-Lucents enterprise networking mission is to provide its customers with the industry's best value in highly available, secure and easy-to-manage network solutions. The industrys best value means having leading features for availability, security and manageability and simultaneously reducing the total cost of network ownership. In short, the best network at the best total cost. Alcatel-Lucent provides high availability solutions from the edge to the core of the IP network. Availability requires resiliency and smart use of redundancy. Alcatel-Lucent wired and wireless LAN products lead the industry in features that deliver high availability and have a price advantage in redundant configurations. Alcatel-Lucents CrystalSec security strategy provides in-depth defense. For the OmniSwitch, for example, this translates to embedded security capabilities on every port in the LAN network, which harden the switch, control user access, control network traffic, and monitor and automate the network response to anomalies. Alcatel-Lucents approach allows enterprise to deploy new services at reduced cost by providing easyto-manage and operate solutions. OmniVista NMS policy-based management tools and automation save time and improve accuracy. Alcatel-Lucent leads the industry with OneTouch tools that provide network-wide, policy-based management for QoS, SecureAccess, and VLAN management. Alcatel-Lucent saves you time by automating operations for recurring tasks, including configuration backup, software image distribution, and scripting. And Alcatel-Lucent offers the industrys strongest web interface and a clean, simple CLI. Vendor Experience and Vision: Evaluation of the vendor's experience in building intelligent network infrastructures and implementing Internet technologies. Alcatel-Lucent has a rich history providing intelligent network infrastructures in higher education. This success is due in large measure for our ability to provide convergence ready networks without limitations. We accomplish this by creating a strong IP/Ethernet foundation, where high availability, edge to core QoS, and support for wire-speed multicast applications and virus attack quarantine create a secure infrastructure which allows the university to confidently reach their vision for education. Our list of higher education customers include those who are utilizing our network equipment to run Voice over IP, IP TV, Video on Demand and Internet 2. In addition, many of our customers have leveraged our standards based capabilities to integrate our switches with other vendors equipment - providing a smooth transition to the latest Alcatel-Lucent technology, while extending the useful life of the existing network. Alcatel-Lucent's technology leadership does not stop at the enterprise. We are the #2 market share provider of high-end Internet routing products for carriers and ISPs. We have held the top worldwide DSL market share position for the past 6 years, as well as provide over 80% of the intercontinental submarine fiber optic network, which connects the Internet to the world. We once claimed that we are the architects of the Internet, but I believe that we are the engineers of the future.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 333 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Leading Edge Technology: The ability to incorporate future requirements and technological advances. The ability to incorporate future requirements and technological advances will be driven by the specific need. For requirements or advances that encompass bandwidth, our core offering to you is based on a chassis design. The OmniSwitch 9700 product family has a 960 Gbps backplane capacity, so as new bandwidth needs arise, this platform will be more than able to handle it with the addition of network line cards. At the edge of the network, there are several options for your review. Each of them has strengths for a specific direction that the college intends to head. One platform has the ability to connect to a 10 Gbps backbone. Both platforms can connect multiple GE uplinks via 802.3ad to create a multiple Gigabit backbone. What is more important than bandwidth? Intelligent use of the bandwidth This is where Alcatel-Lucent has a decided advantage in the marketplace. Leveraging our network management software package, we can provision edge to core QoS with one mouse click. We can integrate with third party IDS/IDP devices and quarantine misbehaving computers based upon the IDS/IDP communications. We can provide server load balancing at no extra cost - allowing the university to expand server performance without spending extra. We accomplish this through our high-end OmniSwitch operating system, which is identical from the core to the edge. This consistency allows the network management team to increase their productivity - since both OS are the same; there is no need to learn how to manage the core versus the edge. As previously mentioned, Alcatel-Lucent doggedly adheres to standards therefore, with this common code base, whenever there is a new IEEE specification, we support it in the code. When you update the OS you gain the new feature. This is how 802.1S, sFlow and multiple MAC 802.1x authentications became available to our customers. Performance and features help us deliver to our customers the best value in the industry.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 334 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

High Availability
There are many aspects to high availability and ways to define what it means in data networking environments. While most implementations focus on the device hardware only, Alcatel-Lucent has designed the AOS OmniSwitch products on the basis that availability also needs to be extended throughout the enterprise at both the device and network levels. This means that the traditional components of reliability, resiliency, and redundancy need to be designed into the network as well as the devices to ensure the continuous flow of information to users and resources. The Alcatel-Lucent AOS OmniSwitch product family has been designed from its inception to provide carrier-class availability to meet the needs of mission-critical, IP Communications, and converged network environments. With the increasing importance of networks carrying voice and real-time applications, there is an increased need for availability that reaches across the network links and end user devices. Additionally, there is also the need for high availability in the areas of security and manageability, with intelligence and performance as integral parts of the network infrastructure to enable enterprises to achieve their availability goals. An Overview of the Alcatel-Lucent AOS OmniSwitch 6850 Series High Availability feature: Redundant Management & Switch Fabric (stacking configuration) Redundant Stacking link Hot swappable components Redundant Power Supplies (Redundant 1:1 power provided by the OS6850-BPS) Spanning Tree robustness (Single or Multiple STP options): IEEE 802.1D (STP) (802.1D spanning tree for loop free topology and link redundancy) and IEEE 802.1w-Rapid Reconfiguration of Spanning Tree (allows subsecond failover to redundant link) o Ring Rapid Spanning Tree optimized for ring topology to provide less than 50ms convergence time o Alcatel.Lucent per-VLAN spanning tree (1x1) Fast forwarding mode on user ports to bypass 30-second delay for spanning tree BPDU blocking automatically shuts down switch ports being used as user ports if a spanning tree BPDU packet is seen. Prevents unauthorized spanning-tree enabled attached bridges from operating. Priority queues: eight hardware-based queues per port VRRP (Virtual Router Redundancy Protocol), and OSPF ECMP (Equal Cost Multipath Protocol) Dynamic link aggregation IEEE 802.3ad (that supports automatic configuration of link aggregates with other switches) with resilient uplink capabilities Static link aggregation with OmniChannel (that supports automatic configuration of link aggregates with other switches) IEEE 802.1s: MISTP (802.1s) is an IEEE standard which allows several VLANs to be mapped to a reduced number of spanning-tree instances. This is possible since most networks do not need more than a few logical topologies. Each instance handles multiple VLANs that have the same Layer 2 topology. Software Resiliency: The AOS OmniSwitch product family provides fully redundant and resilient system components to insure continuous, non-stop operation. This includes redundant subsystems, hot swappable modules, load-sharing components, hitless software loading, downloadable bootstrap, and image rollback which allows the system to automatically re-load previous configurations and software versions. o Software image and configuration recovery o Image and configuration synchronization for Management Modules Broadcast storm control Downloadable bootstrap Chassis thermal protection/shutdown Hardware monitoring, temperature monitoring, and power monitoring & management Short cold and warm boot times Built-in security and device hardening Network and Link Resiliency: Network and link resiliency are important parts of network availability, and the AOS OmniSwitch product family supports advanced routing, load sharing, and mechanisms for fast reconfiguration of links between switches, servers, and other network devices. These include: o VRRP (Virtual Router Redundancy Protocol), and OSPF Equal Cost Multipath Protocol Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 335 Software & Hardware Release: AOSv6.3.1r01

Topological Network Redundancy: In order to provide the highest levels of availability throughout an enterprise, it is important to build redundancy and resiliency into the topology at the network level to insure that links have backups and traffic is always flowing. This includes: o Physical redundancy o Layer 2 and layer 3 redundancies A host of other advanced featuresetc.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 336 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The Spanning Tree Algorithm and Protocol (STP)

The Spanning Tree Algorithm and Protocol (STP) is a self-configuring algorithm that maintains a loop-free topology while providing data path redundancy and network scalability. Based on the IEEE 802.1D standard, the Alcatel.Lucent STP implementation distributes the Spanning Tree load between the primary management switch in the stack and the other switches in the stack. This ensures a Spanning Tree that continues to respond to STP Bridge Protocol Data Units (BPDU) received on switch ports and port link up and down states in the event of a management fail over to a backup management switch. In addition, the Alcatel.Lucent distributed implementation incorporates the following Spanning Tree features: Configures a physical topology into a single STP to ensure that there is only one data path between any two switches. Supports fault tolerance within the network topology. The Spanning Tree is reconfigured in the event of a data path or bridge failure or when a new switch is added to the topology. Supports two Spanning Tree operating modes; flat (single STP instance per switch) and 1x1 (single STP instance per VLAN). 1x1 mode can be configured to interoperate with Ciscos proprietary Per VLAN Spanning Tree instance (PVST+). Supports four Spanning Tree Algorithms; 802.1D (STP), 802.1w (RSTP), 802.1Q 2005 (MSTP), and RRSTP. Allows 802.1Q tagged ports and link aggregate logical ports to participate in the calculation of the STP topology. The Distributed Spanning Tree software is active on all switches by default. As a result, a loop-free network topology is automatically calculated based on default Spanning Tree switch, VLAN, and port parameter values. It is only necessary to configure Spanning Tree parameters to change how the topology is calculated and maintained.

Spanning Tree Specifications

IEEE Standards supported 802.1DMedia Access Control (MAC) Bridges 802.1wRapid Reconfiguration (802.1D Amendment 2) 802.1Q 2005Virtual Bridged Local Area Networks 802.1Q 2005Multiple Spanning Trees (MSTP) Flat mode - one spanning tree instance per switch 1x1 mode - one spanning tree instance per VLAN 802.1D Standard Spanning Tree Algorithm and Protocol (STP) 802.1w Rapid Spanning Tree Algorithm and Protocol (RSTP) 802.1Q 2005 Multiple Spanning Tree Protocol (MSTP) Ring Rapid Spanning Tree Protocol (RRSTP) Fixed ports (non-mobile) 802.1Q tagged ports Link aggregate of ports 252 16 MSTI, in addition to the Common and Internal Spanning Tree instance (also referred to as MSTI 0). 128 All Spanning Tree commands support prefix recognition.

Spanning Tree Operating Modes supported Spanning Tree Protocols supported

Spanning Tree port eligibility

Number of 1x1 Spanning Tree instances Number of Multiple Spanning Tree Instances (MSTI) supported Number of Ring Rapid Spanning Tree rings (RRSTP) supported CLI Command Prefix Recognition

Spanning Tree Bridge Parameter Defaults

Parameter Description Spanning Tree operating mode Spanning Tree protocol BPDU switching status. Spanning Tree priority level for the bridge (VLAN) Hello time interval between each BPDU transmission. Maximum aging time allowed for Spanning Tree information learned from the network. Spanning Tree port state transition time. Automatic VLAN Containment Capability of 1X1 mode to interoperate with Ciscos PVST+ mode. Default 1x1 (a separate Spanning Tree instance for each VLAN) RSTP (802.1w) Disabled 32768 2 seconds 20 seconds 15 seconds Disabled Disabled

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 337 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Spanning Tree Port Parameter Defaults

Parameter Description Spanning Tree port administrative state Spanning Tree port priority value Spanning Tree port path cost Path cost mode Port state management mode Type of port connection Type of BPDU to be used on a port when the 1X1 mode is configured to interoperate with Ciscos PVST+ mode. Default Enabled 7 0 (cost is based on port speed) Auto (16-bit in 1x1 mode and STP or RSTP flat mode, 32bit in MSTP flat mode) Dynamic (Spanning Tree Algorithm determines port state) auto point to point Auto

Multiple Spanning Tree (MST) Region Defaults

Parameter Description The MST Region Name The revision level for the MST region The maximum number of hops authorized for the region The number of Multiple Spanning Tree Instances (MSTI) The VLAN to MSTI mapping Default Blank 0 20 1 (flat mode instance) All VLANs are mapped to the Common Internal Spanning Tree (CIST) instance

Ring Rapid Spanning Tree (RRSTP) Defaults

The following parameter value is specific to RRSTP and is only configurable when the flat mode is active on the switch.
Parameter Description Ring status Disabled Default

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 338 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Spanning Tree Overview

Alcatel-Lucent switches support the use of the 802.1D Spanning Tree Algorithm and Protocol (STP), the 802.1w Rapid Spanning Tree Algorithm and Protocol (RSTP), the 802.1Q 2005 Multiple Spanning Tree Protocol (MSTP), and the Ring Rapid Spanning Tree Protocol (RRSTP). RSTP expedites topology changes by allowing blocked ports to transition directly into a forwarding state, bypassing listening and learning states. This provides rapid reconfiguration of the Spanning Tree in the event of a network path or device failure. The 802.1w standard is an amendment to the 802.1D document, thus RSTP is based on STP. Regardless of which one of these two protocols a switch or VLAN is running, it can successfully interoperate with other switches or VLANs. 802.1Q 2005 is a new version of MSTP that combines the 802.1D 2004 and 802.1S protocols. This implementation of 802.1Q 2005 also includes improvements to edge port configuration and provides administrative control to restrict port role assignment and the propagation of topology change information through bridge ports. MSTP is an enhancement to the 802.1Q Common Spanning Tree (CST), which is provided when an Alcatel-Lucent switch is running in the flat Spanning Tree operating mode. The flat mode applies a single spanning tree instance across all VLAN port connections on a switch. MSTP allows the configuration of Multiple Spanning Tree Instances (MSTIs) in addition to the CST instance. Each MSTI is mapped to a set of VLANs. As a result, flat mode can now support the forwarding of VLAN traffic over separate data paths. RRSTP is faster than MSTP. It is used in a ring topology where bridges are connected in a point to point manner. This protocol identifies the bridge hosting the alternate (ALT) port in lesser convergence time. This ALT port is changed to the forwarding state immediately without altering the MSTP state to enable the data path. The RRSTP frame travels from the point of failure to the bridge hosting the ALT port in both the directions. The MAC addresses matching the ports in the ring are flushed to make the data path convergence much faster than normal MSTP.

How the Spanning Tree Topology is calculated

The tree consists of links and bridges that provide a single data path that spans the bridged network. At the base of the tree is a root bridge. One bridge is elected by all the bridges participating in the network to serve as the root of the tree. After the root bridge is identified, STP calculates the best path that leads from each bridge back to the root and blocks any connections that would cause a network loop. To determine the best path to the root, STP uses the path cost value, which is associated with every port on each bridge in the network. This value is a configurable weighted measure that indicates the contribution of the port connection to the entire path leading from the bridge to the root. The IEEE 802.1D standard recommends using the following path cost values based on link speed: Link Speed 4Mbps 10Mbps 16Mbps 100Mbps 1Gbps 10Gbps Recommended Value 250 100 62 19 4 2 Recommended Range 100-1000 50-600 40-400 10-60 3-10 1-5 Range 1-65535 1-65535 1-65535 1-65535 1-65535 1-65535

In addition, a root path cost value is associated with every bridge. This value is the sum of the path costs for the port that receives frames on the best path to the root (this value is zero for the root bridge). The bridge with the lowest root path cost becomes the designated bridge for the LAN, as it provides the shortest path to the root for all bridges connected to the LAN.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 339 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

During the process of calculating the Spanning Tree topology, each port on every bridge is assigned a port role based on how the port and/or its bridge will participate in the active Spanning Tree topology. The following table provides a list of port role types and the port and/or bridge properties that the Spanning Tree Algorithm examines to determine which role to assign to the port. Role Root Port Designated Port Backup Port Port/Bridge Properties Port connection that provides the shortest path (lowest path cost value) to the root. The root bridge does not have a root port. The designated bridge provides the LAN with the shortest path to the root. The designated port connects the LAN to this bridge. Any operational port on the designated bridges that is not a root or designated port. Provides a backup connection for the designated port. A backup port can only exist when there are redundant designated port connections to the LAN. Any operational port that is not the root port for its bridge and its bridge is not the designated bridge for the LAN. An alternate port offers an alternate path to the root bridge if the root port on its own bridge goes down. Port is not operational. If an active connection does come up on the port, it is assigned an appropriate role.

Alternate Port Disabled Port Note. The distinction between a backup port and an alternate port was introduced with the IEEE 802.1w standard to help define rapid transition of an alternate port to a root port. The role a port plays or may potentially play in the active Spanning Tree topology determines the ports operating state; discarding, learning or forwarding. The port state is also configurable in that it is possible to enable or disable a ports administrative status and/or specify forwarding or blocking state that is only changed through user intervention.

The Spanning Tree Algorithm only includes ports in its calculations that are operational (link is up) and have an enabled administrative status. The following table compares and defines 802.1D and 802.1w port states and their associated port roles: STP Port State Disabled Blocking RSTP Port State Discarding Discarding Port State Definition Port is down or administratively disabled and is not included in the topology. Frames are dropped; nothing is learned or forwarded on the port. Port is temporarily excluded from topology. Port is preparing to transmit data and is included in the active topology. Port is learning MAC addresses that are seen on the port and adding them to the bridge forwarding table, but not transmitting any data. Port is included in the active topology. Port is transmitting and receiving data and is included in the active topology. Port Role Disabled Alternate, Backup

Listening Learning

Discarding Learning

Root, Designated Root, Designated

Forwarding

Forwarding

Root, Designated

Once the Spanning Tree is calculated, there is only one root bridge, one designated bridge for each LAN, and one root port on each bridge (except for the root bridge). Data travels back and forth between bridges over forwarding port connections that form the best, non-redundant path to the root. The active topology ensures that network loops do not exist.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 340 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Bridge Protocol Data Units (BPDU)

Switches send layer 2 frames, referred to as Configuration Bridge Protocol Data Units (BPDU), to relay information to other switches. The information in these BPDU is used to calculate and reconfigure the Spanning Tree topology. A Configuration BPDU contains the following information that pertains to the bridge transmitting the BPDU: Root ID Root Path Cost The Bridge ID for the bridge that this bridge believes is the root. The sum of the Path Costs that lead from the root bridge to this bridge port. The Path Cost is a configurable parameter value. The IEEE 802.1D standard specifies a default value that is based on port speed. An eight-byte hex value that identifies this bridge within the Spanning Tree. The first two bytes contain a configurable priority value and the remaining six bytes contain a bridge MAC address. Each switch chassis is assigned a dedicated base MAC address. This is the MAC address that is combined with the priority value to provide a unique Bridge ID for the switch. A 16-bit hex value that identifies the bridge port that transmitted this BPDU. The first 4 bits contain a configurable priority value and the remaining 12 bits contain the physical switch port number.

Bridge ID

Port ID

The sending and receiving of Configuration BPDU between switches participating in the bridged network is how the root bridge is elected and the best path to the root is determined and then advertised to the rest of the network. BPDU provide enough information for the STP software running on each switch to deter-mine the following: Which bridge will serve as the root bridge The shortest path between each bridge and the root bridge Which bridge will serve as the designated bridge for the LAN Which port on each bridge will serve as the root port The port state (forwarding or discarding) for each bridge port based on the role the port will play in the active Spanning Tree topology The following events trigger the transmitting and/or processing of BPDU in order to discover and maintain the Spanning Tree topology. When a bridge first comes up, it assumes it is the root and starts transmitting Configuration BPDU on all its active ports advertising its own bridge ID as the root bridge ID. When a bridge receives BPDU on its root port that contains more attractive information (higher priority parameters and/or lower path costs), it forwards this information on to other LANs to which it is connected for consideration. When a bridge receives BPDU on its designated port that contains information that is less attractive (lower priority values and/or higher path costs), it forwards its own information to other LANs to which it is connected for consideration. STP evaluates BPDU parameter values to select the best BPDU based on the following order of precedence: 1. The lowest root bridge ID (lowest priority value, then lowest MAC address). 2. The best root path cost. 3. If root path costs are equal, the bridge ID of the bridge sending the BPDU. 4. If the previous three values tie, then the port ID (lowest priority value, then lowest port number) When a topology change occurs, such as when a link goes down or a switch is added to the network, the affected bridge sends Topology Change Notification (TCN) BPDU to the designated bridge for its LAN. The designated bridge will then forward the TCN to the root bridge. The root then sends out a Configuration BPDU and sets a Topology Change (TC) flag within the BPDU to notify other bridges that there is a change in the configuration information. Once this change is propagated throughout the Spanning Tree network, the root stops sending BPDU with the TC flag set and the Spanning Tree returns to an active, stable topology.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 341 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Topology Examples
The following diagram shows an example of a physical network topology that incorporates data path redundancy to ensure fault tolerance. These redundant paths, however, create loops in the network configuration. If a device connected to Switch A sends broadcast packets, Switch A will flood the packets out all of its active ports. The switches connected to Switch A will in turn flood the broadcast packets out their active ports, and Switch A will eventually receive the same packets back and the cycle will start over again. This causes severe congestion on the network, often referred to as a broadcast storm.

The Spanning Tree Algorithm prevents network loops by ensuring that there is always only one active link between any two switches. This is done by transitioning one of the redundant links into a blocking state, leaving only one link actively forwarding traffic. If the active link goes down, then Spanning Tree will transition one of the blocked links to the forwarding state to take over for the downed link. If a new switch is added to the network, the Spanning Tree topology is automatically recalculated to include the monitoring of links to the new switch.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 342 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The following diagram shows the logical connectivity of the same physical topology as determined by the Spanning Tree Algorithm:

In the above active Spanning Tree topology example, the following configuration decisions were made as a result of calculations performed by the Spanning Tree Algorithm: Switch D is the root bridge because its bridge ID has a priority value of 10 (the lower the priority value, the higher the priority the bridge has in the Spanning Tree). If all four switches had the same priority, then the switch with the lowest MAC address in its bridge ID would become the root. Switch A is the designated bridge for Switch B, because it provides the best path for Switch B to the root bridge. Port 2/9 on Switch A is a designated port, because it connects the LAN from Switch B to Switch A. All ports on Switch D are designated ports, because Switch D is the root and each port connects to a LAN. Ports 2/10, 3/1, and 3/8 are the root ports for Switches A, B, and C, respectively, because they offer the shortest path towards the root bridge. The port 3/9 connection on Switch C to port 2/2 on Switch D is in a discarding (blocking) state, as the connection these ports provides is redundant (backup) and has a higher path cost value than the 2/3 to 3/8 connection between the same two switches. As a result, a network loop is avoided. The port 3/2 connection on Switch B to port 3/10 on Switch C is also in a discarding (blocking) state, as the connection these ports provides has a higher path cost to root Switch D than the path between Switch B and Switch A. As a result, a network loop is avoided.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 343 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Spanning Tree Operating Modes

The switch can operate in one of two Spanning Tree modes: flat and 1x1. Both modes apply to the entire switch and determine whether a single Spanning Tree instance is applied across multiple VLANs (flat mode) or a single instance is applied to each VLAN (1x1 mode). By default, a switch is running in the 1x1 mode when it is first turned on. Use the bridge mode command to select the flat or 1x1 Spanning Tree mode. The switch operates in one mode or the other; however, it is not necessary to reboot the switch when changing modes.

Using Flat Spanning Tree Mode

Before selecting the flat Spanning Tree mode, consider the following: If STP (802.1D) is the active protocol, then there is one Spanning Tree instance for the entire switch; port states are determined across VLANs. If MSTP (802.1s) is the active protocol, then multiple instances up to a total of 17 are allowed. Port states, however, are still determined across VLANs. Multiple connections between switches are considered redundant paths even if they are associated with different VLANs. Spanning Tree parameters are configured for the single flat mode instance. For example, if Spanning Tree is disabled on VLAN 1, then it is disabled for all VLANs. Disabling STP on any other VLAN, however, only exclude ports associated with that VLAN from the Spanning Tree Algorithm. Fixed (untagged) and 802.1Q tagged ports are supported in each VLAN. BPDU, however, are always untagged. When the Spanning Tree mode is changed from 1x1 to flat, ports still retain their VLAN associations but are now part of a single Spanning Tree instance that spans across all VLANs. As a result, a path that was forwarding traffic in the 1x1 mode may transition to a blocking state after the mode is changed to flat.

In the above example, if port 8/3 connects to another switch and port 10/5 connects to that same switch; the Spanning Tree Algorithm would detect a redundant path and transition one of the ports into a blocking state. The same holds true for the tagged ports.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 344 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using 1x1 Spanning Tree Mode

Before selecting the 1x1 Spanning Tree operating mode, consider the following: A single Spanning Tree instance is enabled for each VLAN configured on the switch. For example, if there are five VLANs configured on the switch, then there are five separate Spanning Tree instances, each with its own root VLAN. In essence, a VLAN is a virtual bridge in that it will have its own bridge ID and configurable STP parameters, such as protocol, priority, hello time, max age, and forward delay. Port state is determined on a per VLAN basis. For example, port connections in VLAN 10 are only examined for redundancy within VLAN 10 across all switches. If a port in VLAN 10 and a port in VLAN 20 both connect to the same switch within their respective VLANs, they are not considered redundant data paths and STP will not block one of them. However, if two ports within VLAN 10 both connect to the same switch, then STP will transition one of these ports to a blocking state. Fixed (untagged) ports participate in the single Spanning Tree instance that applies to their configured default VLAN. 802.1Q tagged ports participate in an 802.1Q Spanning Tree instance that allows the Spanning Tree to extend across tagged VLANs. As a result, a tagged port may participate in more than one Spanning Tree instance; one for each VLAN that the port carries. If a VLAN contains both fixed and tagged ports, then a hybrid of the two Spanning Tree instances (single and 802.1Q) is applied. If a VLAN appears as a tag on a port, then the BPDU for that VLAN are also tagged. However, if a VLAN appears as the configured default VLAN for the port, then BPDU are not tagged and the single Spanning Tree instance applies.

In the above example, STP2 is a single Spanning Tree instance since VLAN 5 contains only fixed ports. STP 3 and STP 4 are a combination of single and 802.1Q Spanning Tree instances because VLAN 2 contains both fixed and tagged ports. On ports where VLAN 2 is the default VLAN, BPDU are not tagged. On ports where VLAN 2 is a tagged VLAN, BPDU are also tagged.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 345 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using 1x1 Spanning Tree Mode with PVST+

In order to interoperate with Cisco's proprietary Per Vlan Spanning Tree (PVST+) mode, the current Alcatel-Lucent 1x1 Spanning Tree mode has been extended to allow all user ports on an OmniSwitch to transmit and receive either the standard IEEE BPDUs or Cisco's proprietary PVST+ BPDUs. When PVST+ mode is enabled, a user port operates in 1x1 mode initially by default, until it detects a PVST+ BPDU which will enable that port to operate in the Cisco PVST+ compatible mode automatically. Thus, an OmniSwitch can have ports running in 1x1 mode when connecting to another OmniSwitch, or ports running in Cisco PVST+ mode when connecting to a Cisco switch. So both the Alcatel-Lucent 1x1 and Cisco PVST+ modes can co-exist on the same OmniSwitch and yet interoperate correctly with a Cisco switch using the standard Spanning Tree protocols (802.1d or 802.1w). Note that in the flat Spanning Tree mode, both the OmniSwitch and Cisco switches can interoperate seamlessly using the standard MSTP protocol. Note. This feature is supported only on OmniSwitch 6850 and 9000.

OmniSwitch PVST+ Interoperability

Native VLAN and OmniSwitch Default VLAN Cisco uses the standard IEEE BPDU format for the native VLAN (i.e., VLAN 1 by default) over a 802.1Q trunk. Thus, by default the Common Spanning Tree (CST) instance of the native VLAN 1 for all Cisco switches and the STP instance for a port's default VLAN on an OmniSwitch will interoperate and successfully create a loop-free topology.

802.1q Tagged VLANs

For 802.1q tagged VLANs, Cisco uses a proprietary frame format which differs from the standard IEEE BPDU format used by Alcatel-Lucent 1X1 mode, thus preventing Spanning Tree topologies for tagged VLANs from interoperating over the 802.1Q trunk. In order to interoperate with Cisco PVST+ mode, the current Alcatel-Lucent 1x1 mode has an option to recognize Cisco's proprietary PVST+ BPDUs and allow any user port on an OmniSwitch to send and receive PVST+ BPDUs, so that loop-free topologies for the tagged VLANs can be created between OmniSwitch and Cisco switches.

BPDU Processing in PVST+ Mode

A port on an OmniSwitch operating in PVST+ mode will process BPDUs as follows: If the default VLAN of a port is VLAN 1 then: Send and receive IEEE untagged BPDUs for VLAN 1 Don't send and receive PVST+ tagged BPDUs for VLAN 1 Send and receive tagged PVST+ BPDUs for other tagged VLANs. If the default VLAN of a port is not VLAN 1 then: Send and receive IEEE untagged BPDUs for VLAN 1 Don't send and receive PVST+ tagged BPDUs for VLAN 1 Send and receive untagged PVST+ BPDUs for the port's default VLAN Send and receive tagged PVST+ BPDUs for other tagged VLANs

Recommendations and Requirements for PVST+ Configurations

It is mandatory that all the Cisco switches have the Mac Reduction Mode feature enabled in order to interoperate with an OmniSwitch in PVST+ mode. This will avoid any unexpected election of a root bridge. You can assign the priority value only in the multiples of 4096 to be compatible with the Cisco MAC Reduction mode; any other values will result in an error message. Also, the existing 1x1 priority values will be restored when changing from PVST+ mode back to 1x1 mode. In a mixed OmniSwitch and Cisco environment, it is highly recommended to enable PVST+ mode on all OmniSwitches in order to maintain the same root bridge for the topology. It is possible that the new root bridge might be elected as a result of inconsistencies of MAC reduction mode when connecting an OmniSwitch that does not support Cisco PVST+ mode to an OmniSwitch with the PVST+ mode enabled. In this case, the root bridge priority must be changed manually to maintain the same root bridge. A Cisco switch running in PVST mode (another Cisco proprietary mode prior to 802.1q standard) is not compatible with an OmniSwitch running in 1X1 PVST+ mode. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 346 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

 Both Cisco and an OmniSwitch support two default path cost modes; long or short. It is recommended that the same default path cost mode be configured in the same way on all switches so that the path costs for similar interface types will be consistent when connecting ports between OmniSwitch and Cisco Switches. Dynamic aggregate link (LACP) functions properly between OmniSwitch and Cisco switches. The Cisco switches send the BPDUs only on one physical link of the aggregate, similar to the OmniSwitch Primary port functionality. The path cost assigned to the aggregate link is not the same between OmniSwitch and Cisco switches since vendor-specific formulas are used to derive the path cost. Manual configuration is recommended to match the Cisco path cost assignment for an aggregate link. The table below shows the default Spanning Tree values. Parameters OmniSwitch Cisco Disabled MAC Reduction Mode Enabled Bridge Priority 32768 32768 128 32 (cat OS)/128 (IOS) Port priority Port Path Cost IEEE port Speed Table IEEE port Speed Table Proprietary Table Avg. Path Cost/Num Ports Aggregate Path Cost Default Path Cost Short (16-bit) Short (16-bit) 20 20 Max Age Hello Time 2 2 15 15 Forward Delay Time Default Protocol RSTP (1w) Per VLAN PVST+ (1d) Per Switch

Configuring STP Bridge Parameters

The Spanning Tree software is active on all switches by default and uses default bridge and port parameter values to calculate a loop free topology. It is only necessary to configure these parameter values if it is necessary to change how the topology is calculated and maintained. Note the following when configuring Spanning Tree bridge parameters: When a switch is running in the 1x1 Spanning Tree mode, each VLAN is in essence a virtual bridge with its own Spanning Tree instance and configurable bridge parameters. When the switch is running in the flat mode and STP (802.1D) or RSTP (802.1w) is the active protocol, bridge parameter values are only configured for the flat mode instance. If MSTP (802.1s) is the active protocol, then the priority value is configurable for each Multiple Spanning Tree Instance (MSTI). All other parameters, however, are still only configured for the flat mode instance and are applied across all MSTIs. Bridge parameter values for a VLAN instance are not active unless Spanning Tree is enabled on the VLAN and at least one active port is assigned to the VLAN. Use the vlan stp command to enable or disable a VLAN Spanning Tree instance. If Spanning Tree is disabled on a VLAN, active ports associated with that VLAN are excluded from Spanning Tree calculations and will remain in a forwarding state. Note that when a switch is running in the flat mode, disabling Spanning Tree on VLAN 1 disables the instance for all VLANs and all active ports are then excluded from any Spanning Tree calculations and will remain in a forwarding state.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 347 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Bridge Configuration Commands Overview

Spanning Tree bridge commands are available in an implicit form and an explicit form. Implicit commands resemble commands that were previously released with this feature. The type of instance configured with these commands is determined by the Spanning Tree operating mode that is active at the time the command is used. For example, if the 1x1 mode is active, the instance number specified with the command implies a VLAN ID. If the flat mode is active, the single flat mode instance is implied and thus configured by the command. Explicit commands introduce three new keywords: cist, 1x1, and msti. Each of these keywords when used with a bridge command explicitly identify the type of instance that the command will configure. As a result, explicit commands only configure the type of instance identified by the explicit keyword, regardless of which mode (1x1 or flat) is active. The cist keyword specifies the Common and Internal Spanning Tree (CIST) instance. The CIST is the single Spanning Tree flat mode instance that is available on all switches. When using STP or RSTP, the CIST is also known as instance 1 or bridge 1. When using MSTP (802.1s), the CIST is also known as instance 0. In either case, an instance number is not required with cist commands, as there is only one CIST instance. The 1x1 keyword indicates that the instance number specified with the command is a VLAN ID. The msti keyword indicates that the instance number specified with the command is an 802.1s Multiple Spanning Tree Instance (MSTI). Note that explicit commands using the cist and msti keywords are required to define an MSTP (802.1s) configuration. Implicit commands are only allowed for defining STP or RSTP configurations. The switch supports four Spanning Tree protocols: STP, RSTP, MSTP, and RRSTP. RSTP is the default active protocol on the OmniSwitch 6800, 6850, and 9000 switches.

Bridge Priority
A bridge is identified within the Spanning Tree by its bridge ID (an eight byte hex number). The first two bytes of the bridge ID contain a priority value and the remaining six bytes contain a bridge MAC address. The bridge priority is used to determine which bridge will serve as the root of the Spanning Tree. The lower the priority value, the higher the priority. If more than one bridge have the same priority, then the bridge with the lowest MAC address becomes the root. Note. Configuring a Spanning Tree bridge instance with a priority value that will cause the instance to become the root is recommended, instead of relying on the comparison of switch base MAC addresses to determine the root. If the switch is running in the 1x1 Spanning Tree mode, then a priority value is assigned to each VLAN instance. If the switch is running in the flat Spanning Tree mode, the priority is assigned to the flat mode instance or a 802.1s Multiple Spanning Tree Instance (MSTI). In both cases, the default priority value assigned is 32768. Note that priority values for an MSTI must be multiples of 4096.

Bridge Hello Time

The bridge hello time interval is the number of seconds a bridge will wait between transmissions of Configuration BPDU. When a bridge is attempting to become the root or if it has become the root or a designated bridge, it sends Configuration BPDU out all forwarding ports once every hello time value. The hello time propagated in a root bridge Configuration BPDU is the value used by all other bridges in the tree for their own hello time. Therefore, if this value is changed for the root bridge, all other bridges associated with the same STP instance will adopt this value as well. Note that lowering the hello time interval improves the robustness of the Spanning Tree algorithm. Increasing the hello time interval lowers the overhead of Spanning Tree processing. If the switch is running in the 1x1 Spanning Tree mode, then a hello time value is defined for each VLAN instance. If the switch is running in the flat Spanning Tree mode, then a hello time value is defined for the single flat mode instance. In both cases, the default hello time value used is 2 seconds.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 348 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Bridge Max Age Time

The bridge max age time specifies how long, in seconds, the bridge retains Spanning Tree information it receives from Configuration BPDU. When a bridge receives a BPDU, it updates its configuration information and the max age timer is reset. If the max age timer expires before the next BPDU is received, the bridge will attempt to become the root, designated bridge, or change its root port. The max age time propagated in a root bridge Configuration BPDU is the value used by all other bridges in the tree for their own max age time. Therefore, if this value is changed for the root bridge, all other VLANs associated with the same instance will adopt this value as well. If the switch is running in the 1x1 Spanning Tree modes, then a max age time value is defined for each VLAN instance. If the switch is running in the flat Spanning Tree mode, then the max age value is defined for the flat mode instance. In both cases, the default max age time used is 20 seconds. Note that configuring a low max age time may cause Spanning Tree to reconfigure the topology more often.

Bridge Forward Delay Time

The bridge forward delay time specifies how long, in seconds, a port remains in the learning state while it is transitioning to a forwarding state. In addition, when a topology change occurs, the forward delay time value is used to age out all dynamically learned addresses in the MAC address-forwarding table. The forward delay time propagated in a root bridge Configuration BPDU is the value used by all other bridges in the tree for their own forward delay time. Therefore, if this value is changed for the root bridge, all other bridges associated with the same instance will adopt this value as well. If the switch is running in the 1x1 Spanning Tree mode, then a forward delay time value is defined for each VLAN instance. If the switch is running in the flat Spanning Tree mode, then the forward delay time value is defined for the flat mode instance. In both cases, the default forward delay time used is 15 seconds. Note that specifying a low forward delay time may cause temporary network loops, because packets may get forwarded before Spanning Tree configuration or change notices have reached all nodes in the network.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 349 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using Automatic VLAN Containment

In a Multiple Spanning Tree (MST) configuration, it is possible for a port that belongs to a VLAN that is not a member of an instance to become the root port for that instance. This can cause a topology change that could lead to a loss of connectivity between VLANs/switches. Enabling Automatic VLAN Containment (AVC) helps to prevent this from happening by making such a port an undesirable choice for the root. When AVC is enabled, it identifies undesirable ports and automatically configures them with an infinite path cost value. For example, in the following diagram a link exists between VLAN 2 on two different switches. The ports that provide this link belong to default VLAN 1 but are tagged with VLAN 2. In addition, VLAN 2 is mapped to MSTI 1 on both switches.

In the above diagram, port 4/2 is the Root port and port 5/1 is a designated port for MSTI 1. AVC is not enabled. If another link with the same speed and lower port numbers is added to default VLAN 1 on both switches, the new link becomes the root for MSTI 1 and the tagged link between VLAN 2 is blocked, as shown below:

If AVC was enabled in the above example, AVC would have assigned the new link an infinite path cost value that would make this link undesirable as the root for MSTI 1. Balancing VLANs across links according to their Multiple Spanning Tree Instance (MSTI) grouping is highly recommended to ensure that there is not a loss of connectivity during any possible topology changes. Enabling AVC on the switch is another way to prevent undesirable ports from becoming the root for an MSTI. By default AVC is disabled on the switch. Use the bridge auto-vlan-containment command to globally enable this feature for all MSTIs. Once AVC is globally enabled, then it is possible to disable AVC for individual MSTIs using the same command.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 350 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Configuring STP Port Parameters

The following sections provide information and procedures for using CLI commands to configure STP port parameters. These parameters determine the behavior of a port for a specific Spanning Tree instance. When a switch is running in the 1x1 STP mode, each VLAN is in essence a virtual STP bridge with its own STP instance and configurable parameters. To change STP port parameters while running in this mode, a VLAN ID is specified to identify the VLAN STP instance associated with the specified port. When a switch is running in the flat Spanning Tree mode, VLAN 1 is specified for the VLAN ID. Only bridged ports participate in the Spanning Tree Algorithm. A port is considered bridged if it meets all the following criteria: Port is either a fixed (non-mobile) port, an 802.1Q tagged port, or a link aggregate logical port. Spanning tree is enabled on the port. Port is assigned to a VLAN that has Spanning Tree enabled. Port state (forwarding or blocking) is dynamically determined by the Spanning Tree Algorithm, not manually set.

Bridge Configuration Commands Overview

Spanning Tree port commands are available in an implicit form and an explicit form. Implicit commands resemble commands that were previously released with this feature. The type of instance configured with these commands is determined by the Spanning Tree operating mode that is active at the time the command is used. For example, if the 1x1 mode is active, the instance number specified with the command implies a VLAN ID. If the flat mode is active, the single flat mode instance is implied and thus configured by the command. Explicit commands introduce three new keywords: cist, 1x1, and msti. Each of these keywords when used with a port command explicitly identify the type of instance that the command will configure. As a result, explicit commands only configure the type of instance identified by the explicit keyword regardless of which mode (1x1 or flat) is active. The cist keyword specifies the Common and Internal Spanning Tree (CIST) instance. The CIST is the single Spanning Tree flat mode instance that is available on all switches. When using STP or RSTP, the CIST is also known as instance 1 or bridge 1. When using MSTP, the CIST is also known as instance 0. In either case, an instance number is not required with cist commands, as there is only one CIST instance. The 1x1 keyword indicates that the instance number specified with the command is a VLAN ID. The msti keyword indicates that the instance number specified with the command is a Multiple Spanning Tree Instance (MSTI). Note that explicit commands using the cist and msti keywords are required to define an MSTP configuration. Implicit commands are only allowed for defining STP or RSTP configurations.

Enabling/Disabling Spanning Tree on a Port

By default, Spanning Tree is enabled on all ports. When Spanning Tree is disabled on a port, the port is put in a forwarding state for the specified instance. For example, if a port is associated with both VLAN 10 and VLAN 20 and Spanning Tree is disabled on the port for VLAN 20, the port state is set to forwarding for VLAN 20. However, the VLAN 10 instance still controls the ports state as it relates to VLAN 10. This example assumes the switch is running in the 1x1 Spanning Tree mode. If the switch is running in the flat Spanning Tree mode, then disabling the port Spanning Tree status applies across all VLANs associated with the port. The flat mode instance is specified as the ports instance, even if the port is associated with multiple VLANs.

Spanning Tree on Link Aggregate Ports

Physical ports that belong to a link aggregate do not participate in the Spanning Tree Algorithm. Instead, the algorithm is applied to the aggregate logical link (virtual port) that represents a collection of physical ports.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 351 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Configuring Port Priority

A bridge port is identified within the Spanning Tree by its Port ID (a 16-bit or 32-bit hex number). The first 4 bits of the Port ID contain a priority value and the remaining 12 bits contain the physical switch port number. The port priority is used to determine which port offers the best path to the root when multiple paths have the same path cost. The port with the highest priority (lowest numerical priority value) is selected and the others are put into a blocking state. If the priority values are the same for all ports in the path, then the port with the lowest physical switch port number is selected. By default, Spanning Tree is enabled on a port and the port priority value is set to 7. If the switch is running in the 1x1 Spanning Tree mode, then the port priority applies to the specified VLAN instance associated with the port. If the switch is running in the flat Spanning Tree mode, then the port priority applies across all VLANs associated with the port. The flat mode instance is specified as the ports instance, even if the port is associated with multiple VLANs.

Port Priority on Link Aggregate Ports

Physical ports that belong to a link aggregate do not participate in the Spanning Tree Algorithm. Instead, the algorithm is applied to the aggregate logical link (virtual port) that represents a collection of physical ports.

Configuring Port Path Cost

The path cost value specifies the contribution of a port to the path cost towards the root bridge that includes the port. The root path cost is the sum of all path costs along this same path and is the value advertised in Configuration BPDU transmitted from active Spanning Tree ports. The lower the cost value, the closer the switch is to the root. Note that type of path cost value used depends on which path cost mode is active (automatic or 32-bit). If the path cost mode is set to automatic, a 16-bit value is used when STP or RSTP is the active protocol and a 32-bit value is used when MSTP is the active protocol. If the mode is set to 32-bit, then a 32-bit path cost value is used regardless of which protocol is active. If a 32-bit path cost value is in use and the path cost is set to zero, the following IEEE 802.1Q 2005 recommended default path cost values based on link speed are used: Link Speed 10MB 100MB 1GB 10Gbps IEEE 802.1D Recommended Value 2,000,000 200,000 20,000 2,000

Is a 16-bit path cost value is in use and the path cost is set to zero, the following IEEE 802.1D recommended default path cost values based on link speed are used: Link Speed IEEE 802.1D Recommended Value 250 4Mbps 100 10Mbps 62 16Mbps 19 100Mbps 4 1Gbps 2 10Gbps By default, Spanning Tree is enabled on a port and the path cost is set to zero. If the switch is running in the 1x1 Spanning Tree mode, then the port path cost applies to the specified VLAN instance associated with the port. If the switch is running in the flat Spanning Tree mode, then the port path cost applies across all VLANs associated with the port. The flat mode instance is specified as the ports instance, even if the port is associated with other VLANs.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 352 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Path Cost for Link Aggregate Ports

Physical ports that belong to a link aggregate do not participate in the Spanning Tree Algorithm. Instead, the algorithm is applied to the aggregate logical link (virtual port) that represents a collection of physical ports. By default, Spanning Tree is enabled on the aggregate logical link and the path cost value is set to zero. If a 32-bit path cost value is in use and the path cost for a link aggregate is set to zero, the following default values based on link speed and link aggregate size are used: Link Speed Aggregate Size Default Path (Number of links) (Cost Value) 2 1,200,000 10MB 4 800,000 8 600,000 2 120,000 100MB 4 80,000 8 60,000 2 12,000 1GB 4 8,000 8 6,000 2 1,200 10GB 4 800 8 600 If a 16-bit path cost value is in use and the path cost for a link aggregate is set to zero, the following default values based on link speed and link aggregate size are used. Note that for Gigabit ports the aggregate size is not applicable in this case: Link Speed 10MB Aggregate Size (Number of links) 2 4 8 2 4 8 N/A N/A Default Path (Cost Value) 60 40 30 12 9 7 3 1

100MB

1GB 10GB

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 353 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Configuring Port Mode

There are two port modes supported: manual and dynamic. Manual mode indicates that the port was set by the user to forwarding or blocking state. The port will operate in the state selected until the state is manually changed again or the port mode is changed to dynamic. Ports operating in a manual mode state do not participate in the Spanning Tree Algorithm. Dynamic mode indicates that the active Spanning Tree Algorithm will determine port state. By default, Spanning Tree is enabled on the port and the port operates in the dynamic mode. If the switch is running in the 1x1 Spanning Tree mode, then the port mode applies to the specified VLAN instance associated with the port. If the switch is running in the flat Spanning Tree mode, then the port mode applies across all VLANs associated with the port. The flat mode instance is specified as the ports instance, even if the port is associated with other VLANs.

Mode for Link Aggregate Ports

Physical ports that belong to a link aggregate do not participate in the Spanning Tree Algorithm. Instead, the algorithm is applied to the aggregate logical link (virtual port) that represents a collection of physical ports. To change the port mode for a link aggregate, use the bridge slot/port mode commands described above, but specify a link aggregate control number instead of a slot and port.

Configuring Port Connection Type

Specifying a port connection type is done when using the Rapid Spanning Tree Algorithm and Protocol (RSTP), as defined in the IEEE 802.1w standard. RSTP transitions a port from a blocking state directly to forwarding, bypassing the listening and learning states, to provide a rapid reconfiguration of the Spanning Tree in the event of a path or root bridge failure. Rapid transition of a port state depends on the ports configurable connection type. These types are defined as follows: Point-to-point LAN segment (port connects directly to another switch). No point-to-point shared media LAN segment (port connects to multiple switches). Edge port (port is at the edge of a bridged LAN, does not receive BPDU and has only one MAC address learned). Edge ports, however, will operationally revert to a point to point or a no point to point connection type if a BPDU is received on the port. A port is considered connected to a point-to-point LAN segment if the port belongs to a link aggregate of ports, or if auto negotiation determines if the port should run in full duplex mode, or if full duplex mode was administratively set. Otherwise, that port is considered connected to a no point-to-point LAN segment. Rapid transition of a designated port to forwarding can only occur if the ports connection type is defined as a point to point or an edge port. Defining a ports connection type as a point to point or as an edge port makes the port eligible for rapid transition, regardless of what actually connects to the port. However, an alternate port transition to the role of root port is always allowed regardless of the alternate ports connection type. Note. Configure ports that will connect to a host (PC, workstation, server, etc.) as edge ports so that these ports will transition directly to a forwarding state and not trigger an unwanted topology change when a device is connected to the port. If a port is configured as a point to point or no point to point connection type, the switch will assume a topology change when this port goes active and will flush and relearn all learned MAC addresses for the ports assigned VLAN. By default, Spanning Tree is enabled on the port and the connection type is set to auto point to point. The auto point to point setting determines the connection type based on the operational status of the port. If the switch is running in the 1x1 Spanning Tree mode, then the connection type applies to the specified VLAN instance associated with the port. If the switch is running in the flat Spanning Tree mode, then the connection type applies across all VLANs associated with the port. The flat mode instance is referenced as the ports instance, even if the port is associated with other VLANs.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 354 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Connection Type on Link Aggregate Ports

Physical ports that belong to a link aggregate do not participate in the Spanning Tree Algorithm. Instead, the algorithm is applied to the aggregate logical link (virtual port) that represents a collection of physical ports. To change the port connection type for a link aggregate, use the bridge slot/port connection commands described above, but specify a link aggregate control number instead of a slot and port.

Using RRSTP
The Ring Rapid Spanning Tree Protocol (RRSTP) is complimentary to both the Spanning Tree Protocol (STP) as well as the Multiple Spanning Tree Protocol (MSTP). It is designed to provide faster convergence time when switches are connected point to point in a ring topology. RRSTP can only be configured on an OmniSwitch running in flat mode. RRSTP reduces convergence time by finding the bridge that hosts the alternate (ALT) port and immediately changing the ALT port state to forwarding without altering the MSTP port state. This process quickly enables the data path. The RRSTP frame travels from the point of failure to the ALT port in both directions. The MAC addresses corresponding to the ports in the ring are flushed to make the data path convergence time much faster than the normal MSTP. While RRSTP is already reacting to the loss of connectivity, the standard MSTP BPDU carrying the link down information is processed in normal fashion at each hop. When this MSTP BPDU reaches the bridge whose ALT port is now in the "ALT FWD" state, due to RRSTP frame processing, it updates the MSTP state of the two ports in the ring as per the MSTP standard. The following limitations should be noted when using RRSTP: A port on a bridge can only be part of one RRSTP ring at any given instance. All bridges, which need to be made part of a ring, can be configured only statically. Fast convergence will not occur if an RRSTP frame is lost. However, MSTP convergence will still take place at a later time because there is no way of knowing about the RRSTP frame loss. RRSTP convergence may not happen when changes in configuration result in an unstable topology. If either of the two ports of the RRSTP ring on a bridge goes down or if one of the bridges in the ring goes down, the RRSTP convergence may not happen. However, MSTP convergence will continue without interruption. Maximum of 128 rings can participate on a switch.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 355 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Sample Spanning Tree Configuration

This section provides an example network configuration in which the Spanning Tree Algorithm and Protocol has calculated a loopfree topology. In addition, a tutorial is also included that provides steps on how to configure the example network topology using the Command Line Interface (CLI). Note that the following example network configuration illustrates using switches operating in the 1x1 Spanning Tree mode and using RSTP (802.1w) to calculate a single data path between VLANs.

In the above example topology: Each switch is operating in the 1x1 Spanning Tree mode by default. Each switch configuration has a VLAN 255 defined. The Spanning Tree administrative status for this VLAN was enabled by default when the VLAN was created. VLAN 255 on each switch is configured to use the 802.1w (rapid reconfiguration) Spanning Tree Algorithm and Protocol. Ports 2/1-3, 2/8-10, 3/1-3, and 3/8-10 provide connections to other switches and are all assigned to VLAN 255 on their respective switches. The Spanning Tree administrative status for each port is enabled by default. The path cost for each port connection defaults to a value based on the link speed. For example, the connection between Switch B and Switch C is a 100 Mbps link, which defaults to a path cost of 19. VLAN 255 on Switch D is configured with a Bridge ID priority value of 10, which is less than the same value for VLAN 255 configured on the other switches. As a result, VLAN 255 was elected the Spanning Tree root bridge for the VLAN 255 broadcast domain. A root port is identified for VLAN 255 on each switch, except the root VLAN 255 switch. The root port identifies the port that provides the best path to the root VLAN. VLAN 255 on Switch A was elected the designated bridge because it offers the best path cost for Switch B to the root VLAN 255 on Switch D. Port 2/9 on Switch A is the designated port for the Switch A to Switch B connection because Switch A is the designated bridge for Switch B. Redundant connections exist between Switch D and Switch C. Ports 2/2 and 3/9 are in a discarding (blocking) state because this connection has a higher path cost than the connection provided through ports 2/3 and 3/8. As a result, a network loop condition is avoided. Redundant connections also exist between Switch A and Switch B. Although the path cost value for both of these connections is the same, ports 2/8 and 3/3 are in a discarding state because their port priority values (not shown) are higher than the same values for ports 2/10 and 3/1. The ports that provide the connection between Switch B and Switch C are in a discarding (blocking) state, because this connection has a higher path cost than the other connections leading to the root VLAN 255 on Switch D. As a result, a network loop is avoided. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 356 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

IEEE 802.1s Multiple Spanning Tree

The Alcatel-Lucent Multiple Spanning Tree (MST) implementation provides support for the IEEE 802.1s Multiple Spanning Tree Protocol (MSTP). In addition to the 802.1D Spanning Tree Algorithm and Protocol (STP) and the 802.1w Rapid Spanning Tree Algorithm and Protocol (RSTP), MSTP also ensures that there is always only one data path between any two switches for a given Spanning Tree instance to prevent network loops. MSTP is an enhancement to the 802.1Q Common Spanning Tree (CST), which is provided when an Alcatel-Lucent switch is running in the flat Spanning Tree operating mode. The flat mode applies a single spanning tree instance across all VLAN port connections on a switch. MSTP allows the configuration of Multiple Spanning Tree Instances (MSTIs) in addition to the CST instance. Each MSTI is mapped to a set of VLANs. As a result, flat mode can support the forwarding of VLAN traffic over separate data paths. In addition to 802.1s MSTP support, the 802.1D STP and 802.1w RSTP are still available in either the flat or 1x1 mode. However, if using 802.1D or 802.1w in the flat mode, the single spanning tree instance per switch algorithm applies.

MST Specifications
IEEE Standards supported 802.1DMedia Access Control (MAC) Bridges 802.1wRapid Reconfiguration (802.1D Amendment 2) 802.1QVirtual Bridged Local Area Networks 802.1sMultiple Spanning Trees (802.1Q Amendment 3) Flat mode - one spanning tree instance per switch 1x1 mode - one spanning tree instance per VLAN 802.1D Standard Spanning Tree Algorithm and Protocol (STP) 802.1w Rapid Spanning Tree Algorithm and Protocol (RSTP) 802.1s Multiple Spanning Tree Algorithm and Protocol (MSTP) Fixed ports (non-mobile) 802.1Q tagged ports Link aggregate of ports 253 16 MSTI in addition to the Common and Internal Spanning Tree instance (also referred to as MSTI 0). All Spanning Tree commands support prefix recognition.

Spanning Tree Operating Modes supported Spanning Tree Protocols supported

Spanning Tree port eligibility

Number of 1x1 Spanning Tree instances Number of Multiple Spanning Tree Instances (MSTI) supported CLI Command Prefix Recognition

Spanning Tree Bridge Parameter Defaults

Parameter Description Spanning Tree operating mode Spanning Tree protocol BPDU switching status. Priority value for the Spanning Tree instance. Hello time interval between each BPDU transmission. Maximum aging time allowed for Spanning Tree information learned from the network. Spanning Tree port state transition time. Default 1x1 (a separate Spanning Tree instance for each VLAN) STP (802.1D) Disabled 32768 2 seconds 20 seconds 15 seconds

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 357 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Spanning Tree Port Parameter Defaults

Parameter Description Spanning Tree Port administrative state Spanning Tree Port priority value Spanning Tree Port path cost Path cost mode Port State Management mode Type of Port connection Default Enabled 7 0 (cost is based on port speed) AUTO (16-bit in 1x1 mode, 32-bit in flat mode Dynamic (Spanning tree Algorithm determines port state Auto point to point

MST Region Defaults

Although the following parameter values are specific to the MSTP (802.1s), they are configurable regardless of which mode (flat or 1x1) or protocol is active on the switch. Parameter Description Default The MST region name Blank The revision level for the MST region 0 The maximum number of hops authorized for the region 20 The number of Multiple Spanning Tree Instances (MSTI) 1 (flat mode instance) The VLAN to MSTI mapping All VLANs are mapped to the flat mode instance

MST General Overview

The Multiple Spanning Tree (MST) feature allows for the mapping of one or more VLANs to a single Spanning Tree instance, referred to as a Multiple Spanning Tree Instance (MSTI), when the switch is running in the flat Spanning Tree mode. MST uses the Multiple Spanning Tree Algorithm and Protocol (MSTP) to define the Spanning Tree path for each MSTI. In addition, MSTP provides the ability to group switches into MST Regions. An MST Region appears as a single, flat Spanning Tree instance to switches outside the region.

How MSTP Works

MSTP, as defined in the IEEE 802.1s standard, is an enhancement to the IEEE 802.1Q Common Spanning Tree (CST). The CST is a single spanning tree that uses 802.1D (STP) or 802.1w (RSTP) to provide a loop-free network topology. The Alcatel-Lucent flat spanning tree mode applies a single CST instance on a per switch basis. The 1x1 mode is an Alcatel-Lucent proprietary implementation that applies a single spanning tree instance on a per VLAN basis. MSTP is only supported in the flat mode and allows for the configuration of additional spanning tree instances instead of just the one CST. On Alcatel-Lucent 802.1s flat mode switches, the CST is represented by the Common and Internal Spanning Tree (CIST) instance 0 and exists on all switches. Up to 17 instances, including the CIST, are supported. Each additional instance created is referred to as a Multiple Spanning Tree Instance (MSTI). An MSTI represents a configurable association between a single Spanning Tree instance and a set of VLANs. Note that although MSTP provides the ability to define MSTIs while running in the flat mode, the CST algorithm still automatically calculates port state and role computations across all MSTIs. However, it is possible to configure the priority and/or path cost of a port for a particular MSTI so that a port remains in a forwarding state for an MSTI instance, even if it is blocked as a result of automatic CST computations for other instances. The following diagrams help to further explain how MSTP works by comparing how port states are determined on 1x1 STP/RSTP mode, flat mode STP/RSTP, and flat mode MSTP switches.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 358 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

In the above 1x1 mode example: Both switches are running in the 1x1 mode (one Spanning Tree instance per VLAN). VLAN 100 and VLAN 200 are each associated with their own Spanning Tree instance. The connection between 3/1 and 2/1 is left in a forwarding state because it is part of the VLAN 100 Spanning Tree instance and is the only connection for that instance. Note that if additional switches containing a VLAN 100 were attached to the switches in this diagram, the 3/1 to 2/1 connection could also go into blocking if the VLAN 100 Spanning Tree instance determines it is necessary to avoid a network loop. The connections between 4/8 and 5/2 and 4/2 and 5/1 are seen as redundant because they are both controlled by the VLAN 200 Spanning Tree instance and connect to the same switches. The VLAN 200 Spanning Tree instance determines which connection provides the best data path and transitions the other connection to a blocking state.

In the above flat mode STP/RSTP example: Both switches are running in the flat mode. As a result, a single flat mode Spanning Tree instance applies to the entire switch and compares port connections across VLANs to determine which connection provides the best data path. The connection between 3/1 and 2/1 is left forwarding because the flat mode instance determined that this connection provides the best data path between the two switches. The 4/8 to 5/2 connection and the 4/2 to 5/1 connection are considered redundant connections so they are both blocked in favor of the 3/1 to 2/1 connection.

In the above flat mode MSTP example: Both switches are running in the flat mode and using MSTP. VLANs 100 and 150 are not associated with an MSTI. By default they are controlled by the CIST instance 0, which exists on every switch. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 359 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

VLANs 200 and 250 are associated with MSTI 2 so their traffic can traverse a path different from that determined by the CIST. Ports are blocked the same way they were blocked in the flat mode STP/RSTP example; all port connections are compared to each other across VLANs to determine which connection provides the best path. However, because VLANs 200 and 250 are associated to MSTI 2, it is possible to change the port path cost for ports 2/12, 3/6, 4/8 and/or 5/2 so that they provide the best path for MSTI 2 VLANs, but do not carry CIST VLAN traffic or cause CIST ports to transition to a blocking state. Another alternative is to assign all VLANs to an MSTI, leaving no VLANs controlled by the CIST. As a result, the CIST BPDU will only contain MSTI information.

Comparing MSTP with STP and RSTP

Using MSTP (802.1s) has the following items in common with STP (802.1D) and RSTP (802.1w) protocols: Each protocol ensures one data path between any two switches within the network topology. This prevents network loops from occurring while at the same time allowing for redundant path configuration. Each protocol provides automatic reconfiguration of the network Spanning Tree topology in the event of a connection failure and/or when a switch is added to or removed from the network. All three protocols are supported in the flat Spanning Tree operating mode. The flat mode CST instance automatically determines port states and roles across VLAN port and MSTI associations. This is because the CST instance is active on all ports and only one BPDU is used to forward information for all MSTIs. MSTP is based on RSTP Using MSTP differs from STP and RSTP as follows: MSTP is only supported when the switch is running in the flat Spanning Tree mode. STP and RSTP are supported in both the 1x1 and flat modes. MSTP allows for the configuration of up to 16 Multiple Spanning Tree Instances (MSTI) in addition to the CST instance. Flat mode STP and RSTP protocols only use the single CST instance for the entire switch. MSTP applies a single Spanning Tree instance to an MSTI ID number that represents a set of VLANs; a one to many association. STP and RSTP in the flat mode apply one Spanning Tree instance to all VLANs; a one to all association. STP and RSTP in the 1x1 mode apply a single Spanning Tree instance to each existing VLAN; a one to one association. The port priority and path cost parameters are configurable for an individual MSTI that represents the VLAN associated with the port. The flat mode 802.1D or 802.1w CST is identified as instance 1. When using MSTP, the CST is identified as CIST (Common and Internal Spanning Tree) instance 0. MSTP allows the segmentation of switches within the network into MST regions. Each region is seen as a single virtual bridge to the rest of the network, even though multiple switches may belong to the one region. MSTP has lower overhead than a 1x1 configuration. In 1x1 mode, because each VLAN is assigned a separate Spanning Tree instance, BPDUs are forwarded on the network for each VLAN. MSTP only forwards one BPDU for the CST that contains information for all configured MSTI on the switch.

What is a Multiple Spanning Tree Instance (MSTI)

An MSTI is a single Spanning Tree instance that represents a group of VLANs. Alcatel-Lucent switches support up to 16 MSTIs on one switch. This number is in addition to the Common and Internal Spanning Tree (CIST) instance 0, which is also known as MSTI 0. The CIST instance exists on every switch. By default, all VLANs not mapped to an MSTI are associated with the CIST instance.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 360 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

What is a Multiple Spanning Tree Region

A Multiple Spanning Tree region represents a group of 802.1s switches. An MST region appears as a single, flat mode instance to switches outside the region. A switch can belong to only one region at a time. The region a switch belongs to is identified by the following configurable attributes, as defined by the IEEE 802.1s standard: Region name An alphanumeric string up to 32 characters Region revision level A numerical value between 0 and 65535 VLAN to MSTI table Generated when VLANs are associated with MSTIs. Identifies the VLAN to MSTI mapping for the switch Switches that share the same values for the configuration attributes described above belong to the same region. For example, in the diagram below: Switches A, B, and C all belong to the same region because they all are configured with the same region name, revision level, and have the same VLANs mapped to the same MSTI. The CST for the entire network sees Switches A, B, and C as one virtual bridge that is running a single Spanning Tree instance. As a result, CST blocks the path between Switch C and Switch E instead of blocking a path between the MST region switches to avoid a network loop. The paths between Switch A and Switch C and the redundant path between Switch B and Switch C were blocked as a result of the Internal Spanning Tree (IST) computations for the MST Region.

In addition to the attributes described above, the MST maximum hops parameter defines the number of bridges authorized to propagate MST BPDU information. In essence this value defines the size of the region in that, once the maximum number of hops is reached, the BPDU is discarded. The maximum number of hops for the region is not one of the attributes that define membership in the region.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 361 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

What is the Common Spanning Tree

The Common Spanning Tree (CST) is the overall network Spanning Tree topology resulting from STP, RSTP, and/or MSTP calculations to provide a single data path through the network. CST provides connectivity between MST regions and other MST regions and/or Single Spanning Tree (SST) switches. For example, in the above diagram, CST calculations detected a network loop created by the connections between Switch D, Switch E, and the MST Region. As a result, one of the paths was blocked.

What is the Internal Spanning Tree (IST) Instance

The IST instance determines and maintains the CST topology between MST switches that belong to the same MST region. In other words, the IST is simply a CST that only applies to MST Region switches while at the same time representing the region as a single Spanning Tree bridge to the network CST. As shown in the above diagram, the redundant path between Switch B and Switch C is blocked and the path between Switch A and Switch C is blocked. These blocking decisions were based on IST computations within the MST region. IST sends and receives BPDU to/from the network CST. MSTI within the region do not communicate with the network CST. As a result, the CST only sees the IST BPDU and treats the MST region as a single Spanning Tree bridge.

What is the Common and Internal Spanning Tree Instance

The Common and Internal Spanning Tree (CIST) instance is the Spanning Tree calculated by the MST region IST and the network CST. The CIST is represented by the single Spanning Tree flat mode instance that is available on all switches. By default, all VLANs are associated to the CIST until they are mapped to an MSTI. When using STP (802.1D) or RSTP (802.1w), the CIST is also known as instance 1 or bridge 1. When using MSTP (802.1s), the CIST is also known as instance 0 or MSTI 0. Note that when MSTP (802.1s) is the active flat mode protocol, explicit Spanning Tree bridge commands are required to configure parameter values. Implicit commands are for configuring parameters when the STP or RSTP protocols are in use.

Understanding Spanning Tree Modes

The switch can operate in one of two Spanning Tree modes: flat and 1x1. The flat mode provides a Common Spanning Tree (CST) instance that applies across all VLANs by default. This mode supports the use of the STP (802.1D), RSTP (802.1w), and MSTP (802.1s) protocols. MSTP allows the mapping of one or more VLANs to a single Spanning Tree instance. The 1x1 mode is an Alcatel-Lucent proprietary implementation that automatically calculates a separate Spanning Tree instance for each VLAN configured on the switch. This mode only supports the use of the STP and RSTP protocols. Although MSTP is not supported in the 1x1 mode, it is possible to define an MSTP configuration in this mode using explicit Spanning Tree commands. By default, a switch is running in the 1x1 mode and using the 802.1D protocol when it is first turned on.

MST Interoperability and Migration

Connecting an MSTP (802.1s) switch to a non-MSTP flat mode switch is supported. Since the Common and Internal Spanning Tree (CIST) controls the flat mode instance on both switches, STP or RSTP can remain active on the non-MSTP switch within the network topology. An MSTP switch is part of a Multiple Spanning Tree (MST) Region, which appears as a single, flat mode instance to the nonMSTP switch. The port that connects the MSTP switch to the non-MSTP switch is referred to as a boundary port. When a boundary port detects an STP (802.1D) or RSTP (802.1w) BPDU, it responds with the appropriate protocol BPDU to provide interoperability between the two switches. This interoperability also serves to indicate the edge of the MST region. Interoperability between 802.1s MSTP switches and 1x1 mode switches is not recommended. The 1x1 mode is a proprietary implementation that creates a separate Spanning Tree instance for each VLAN configured on the switch. The 802.1s MSTP implementation is in compliance with the IEEE standard and is only supported on flat mode switches. Tagged BPDU transmitted from a 1x1 switch are ignored by a flat mode switch, which can cause a network loop to go undetected. Although it is not recommended, it may be necessary to temporarily connect a 1x1 switch to a flat mode switch until migration to MSTP is complete. If this is the case, then only configure a fixed, untagged connection between VLAN 1 on both switches. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 362 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Migrating from Flat Mode STP/RSTP to Flat Mode MSTP

Migrating an STP/RSTP flat mode switch to MSTP is relatively transparent. When STP or RSTP is the active protocol, the Common and Internal Spanning Tree (CIST) controls the flat mode instance. If on the same switch the protocol is changed to MSTP, the CIST still controls the flat mode instance. Note the following when converting a flat mode STP/RSTP switch to MSTP: Making a backup copy of the switch boot.cfg file before changing the protocol to MSTP is highly recommended. Having a backup copy will make it easier to revert to the non-MSTP configuration if necessary. Once MSTP is active, commands are written in their explicit form and not compatible with previous releases of Spanning Tree. When converting multiple switches, change the protocol to MSTP first on every switch before starting to configure Multiple Spanning Tree Instances (MSTI). Once the protocol is changed, MSTP features are available for configuration. Multiple Spanning Tree Instances (MSTI) are now configurable for defining data paths for VLAN traffic. Using explicit Spanning Tree commands to define the MSTP configuration is required. Implicit commands are for configuring STP and RSTP. STP and RSTP use a 16-bit port path cost (PPC) and MSTP uses a 32-bit PPC. When the protocol is changed to MSTP, the bridge priority and PPC values for the flat mode CIST instance are reset to their default values. It is possible to configure the switch to use 32-bit PPC value for all protocols (see the bridge path cost mode command page for more information). If this is the case, then the PPC for the CIST is not reset when the protocol is changed to/from MSTP. This implementation of MSTP is compliant with the IEEE 802.1s standard and thus provides interconnectivity with 802.1s compliant systems.

Migrating from 1x1 Mode to Flat Mode MSTP

As previously described, the 1x1 mode is an Alcatel-Lucent proprietary implementation that applies one Spanning Tree instance to each VLAN. For example, if five VLANs exist on the switch, then there are five Spanning Tree instances active on the switch, unless Spanning Tree is disabled on one of the VLANs. Note the following when converting a 1x1 mode STP/RSTP switch to flat mode MSTP: Making a backup copy of the switch boot.cfg file before changing the protocol to MSTP is highly recommended. Having a backup copy will make it easier to revert to the non-MSTP configuration if necessary. Once MSTP is active, commands are written in their explicit form and not compatible with previous releases of Spanning Tree. If the need arises Using MSTP requires changing the switch mode from 1x1 to flat. When the mode is changed from 1x1 to flat, ports still retain their VLAN associations but are now part of a single, flat mode Spanning Tree instance that spans across all VLANs. As a result, a path that was forwarding traffic in the 1x1 mode may transition to a blocking state after the mode is changed to flat. Once the protocol is changed, MSTP features are available for configuration. Multiple Spanning Tree Instances (MSTI) are now configurable for defining data paths for VLAN traffic. Note that STP/RSTP use a 16-bit port path cost (PPC) and MSTP uses a 32-bit PPC. When the protocol is changed to MSTP, the bridge priority and PPC values for the flat mode CIST instance are reset to their default values. It is possible to configure the switch to use 32-bit PPC value for all protocols (see the bridge path cost mode command page for more information). If this is the case, then the PPC for the CIST is not reset when the protocol is changed to/from MSTP. This implementation of MSTP is compliant with the IEEE 802.1s standard and thus provides interconnectivity with 802.1s compliant systems.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 363 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

MAC Retention
MAC Retention allows a system of stackable switches to retain the MAC address of the primary switch for a fixed or indefinite time, even after multiple takeovers. This minimizes the recalculation of protocols, such as Spanning Tree and Link Aggregation. It also minimizes the updation of tables, such as the Address Resolution Protocol (ARP) table for IPv4 routing and the Neighbor Discovery table for IPv6 routing.

MAC Retention Defaults

The following table lists the defaults for MAC Retention configuration: Parameter Description MAC Address Retention status Status of duplicate MAC Address trap Default Disabled Disabled

MAC Retention Overview

A stack element or simply element is a switch that has designated stacking ports. The switches are operatively interconnected via these ports to form a virtual chassis referred to as a stack. Each element in a stack can be elected as the primary or the secondary element. The primary element is elected based on the highest uptime or the lowest slot number or the lowest base MAC address. The secondary element is elected based on the lowest slot number or the lowest base MAC address of the remaining elements in the stack.The system of stackable switches is generally coupled in a series and the topology of the system is generally characterized by a closed loop called a ring. A stackable switch is adapted to perform switching between its own data ports and between the data ports of other stackable switches by transmitting packets via the stacking ports. Each stack element has a unique base MAC address. Generally, the stack address is the MAC address of the current primary element. When a primary element fails, a secondary element starts functioning as the new primary element. This is known as takeover. During takeover, the stack address is also accordingly changed to reflect the base MAC address of the new primary element. Whenever a takeover occurs, it impacts not only the stack, but also the devices that communicate with that stack.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 364 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The following diagram shows a stack connected to a stand-alone switch:

In the above diagram, Stack 1 has the stack address M1. When a takeover occurs, the secondary element starts functioning as the new primary element and the stack address is also changed, for example, to M2, the new primary elements MAC address. Stack 1 advertises its new stack address M2. Switch 1, which had previously associated Stack 1 with the stack address M1, now has to change its ARP tables to associate Stack 1 with the new stack address M2. Similarly, in IPv6 routing, Switch 1 has to change its Neighbor Discovery tables to associate Stack 1 with the new stack address M2. Another aspect that may be impacted is the recalculation of the Spanning Tree in accordance with the Spanning Tree Protocol (STP). If the stack address is changed due to the election of a new primary element, a new Spanning Tree has to be recalculated to account for this change. This becomes even more difficult when the newly elected primary element becomes the new root bridge. Link Aggregation Control Protocol (LACP) is another application that is influenced by the takeover. This application uses the base MAC address of the switch as the system ID while exchanging the LACP PDUs in the network. After takeover, the aggregate ports will administratively go down and then come up again due to the change in the system ID. Therefore, to avoid these recalculations, when a primary element fails in a stack, the secondary element, which takes over as the new primary element uses the MAC address of the former primary element.This feature of retaining the base MAC address of the former primary element for a fixed or indefinite period of time is called MAC Address Retention. In this way, recalculation of protocols, such as Spanning Tree and Link Aggregation and updation of tables, such as the Address Resolution Protocol (ARP) table for IPv4 routing and the Neighbor Discovery table for IPv6 routing is minimized. Note. The MAC Retention feature is only supported on the switch that operates in the single MAC mode.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 365 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

How MAC Retention Works

During a full system startup, all the elements in the stack receive the base MAC address read from the EEPROM of the primary element. When the primary element of the stack fails, the secondary element takes over as the new primary element. This new primary element and all the idle elements of the stack retain this base MAC address. Therefore, this address is called the retained base MAC address. The ability of the elements to retain this address can be configured, i.e., the MAC Retention feature can be enabled or disabled on the stack. By default, it is disabled. After a takeover, if the element still uses a retained base MAC address, you can disable the retention process manually. Thereafter, the element will start using the base MAC address from the EEPROM of the currently active primary element. When the element retains the base MAC address during a takeover, it continues to use this base MAC address irrespective of the return of the former primary element to the stack. This can lead to the duplication of the MAC address. The duplication of MAC addresses may arise in the following scenarios: Failure of non-adjacent elements Failure of non-adjacent primary and secondary elements Failure of non-adjacent primary and idle elements Failure of non-adjacent secondary and idle elements If the primary element does not return to the stack after the elapse of the specified time interval, a trap is generated, which notifies the administrator of a possible MAC address duplication. The trap and Syslog provide details about the slot number and the base MAC address of the removed former primary element.

MAC Retention After Multiple Take-Overs

After multiple takeovers, if the new primary element still uses the MAC address of the former primary element, you can release the MAC address or disable MAC Retention. In such a case, the stack will obtain a new stack address from the EEPROM of the current primary element. If you enable the MAC Retention feature again, the old MAC address released earlier will not be retained. Thereafter, the stack will retain the MAC address of the current primary element during future takeovers.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 366 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

MAC Retention Applications

This section illustrates the MAC Retention feature using two different scenarios: Software Failure Link Failure Software Failure In the following diagram, if the primary element faces a fatal software exception, the MAC Retention feature will remain enabled and the base MAC address will be retained during takeover.

In the above diagram, when the primary element in Stack 1 fails, the secondary element becomes the new primary element and shares the MAC address of the former primary element of the stack. In this scenario, the decision to retain the base MAC address is acceptable. This feature also works well during the following failures: Power failure of the primary element Hardware failure of the primary element

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 367 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Link Failure
In the following diagram, even if both stack links "a" and "b" of the primary element of Stack 1 go down almost at the same time (removed by the user or actual link failures), the MAC Retention feature will remain enabled and the base MAC address will be retained during takeover.

In the above diagram, if the links between the primary and the secondary element and the primary and the idle element fail, the entire stack will split into two separate stacks. The primary element will become an independent stack, and the new primary element (after takeover) and the new secondary element will form another separate stack. Both the stacks will share the same base MAC address.This will lead to the duplication of MAC address because the software running on the elements will not be able to distinguish between a crash or two link failures. In the above scenario, although the duplication of MAC address cannot be prevented, the element can be configured to generate an SNMP trap. If an SNMP trap is generated, the administrator can release the base MAC address from the stack consisting of the new primary and secondary elements. This stack will use the base MAC address from the EEPROM of the new primary element of the stack.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 368 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Static (OmniChannel) Link Aggregation

Alcatel-Lucents static link aggregation software, also known as OmniChannel, allows you to combine several physical links into one large virtual link known as a link aggregation group. Using link aggregation can provide the following benefits: Scalability: On OmniSwitch 6850 switches, you can configure up to 32 link-aggregation groups that can consist of 2, 4, or 8 10-Mbps, 100-Mbps, 1-Gbps, or 10-Gbps Ethernet links. Reliability: If one of the physical links in a link aggregate group goes down (unless it is the last one) the link aggregate group can still operate. Ease of Migration: Link aggregation can ease the transition from a 100 Mbps Ethernet backbones to Gigabit Ethernet backbones. Note. You can also configure and monitor static link aggregation with WebView, Alcatel-Lucents embedded web-based device management application. WebView is an interactive and easy-to-use GUI that can be launched from OmniVista or a web browser.

Static Link Aggregation Specifications

Maximum number of link aggregation groups per OmniSwitch 6850 Series switch Number of links per group supported Range for optional group name CLI Command Prefix Recognition 32 2, 4, or 8 1 to 255 characters All static link aggregation configuration commands support prefix recognition. (Static link aggregation shows commands do not support prefix recognition.)

Static Link Aggregation Defaults

Parameter Description Administrative State Group Name Default Enabled No name configured

Static Link Aggregation Overview

Link aggregation allows you to combine 2, 4, or 8, physical connections into large virtual connections known as link aggregation groups. On OmniSwitch 6800 switches, you can configure up to 32 link aggregation groups that can consist of 2, 4, or 8 links in a single standalone switch, or a stack consisting of up to eight OmniSwitch 6850 switches. On OmniSwitch 6850 switches, you can configure up to 32 link-aggregation groups that can consist of 2, 4, or 8, 10-Mbps, 100-Mbps, 1-Gbps, or 10-Gbps Ethernet links. You can create Virtual LANs (VLANs), 802.1Q framing, configure Quality of Service (QoS) conditions, and other networking features on link aggregation groups because the switchs software treats these virtual links just like physical links. Load balancing for Layer 2 non-IP packets is on a MAC address basis and for IP packets the balancing algorithm uses IP address as well. Ports must be of the same speed within the same link aggregate group. Alcatel-Lucents link aggregation software allows you to configure the following two different types of link aggregation groups: Static link aggregate groups Dynamic link aggregate groups

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 369 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Static Link Aggregation Operation

Static link aggregate groups are virtual links between two nodes consisting of 2, 4, or 8, physical links. On OmniSwitch 6850 switches, you can configure up to 32 link-aggregation groups that can consist of 2, 4, or 8, 10-Mbps, 100-Mbps, 1-Gbps, or 10-Gbps Ethernet links. Static aggregate groups can be created between: Two OmniSwitch 6850/9000 switches An OmniSwitch 6850/9000 switch and an OmniSwitch 7700/7800 or OmniSwitch 8800 switch or OmniSwitch 6600 Family switch An OmniSwitch 6850/9000 switch and an early-generation Alcatel-Lucent switch, such as an Omni Switch/Router However, static aggregate groups cannot be created between OmniSwitch 6850/9000 switches and switches from other vendors. The figure below shows a static aggregate group that has been configured between Switch A and Switch B. The static aggregate group links four ports on a single OS9-GNI-C24 on Switch A to two ports on one OS9-GNI-C24 and two ports on another OS9-GNI-C24 on Switch B. The network administrator has created a separate VLAN for this group so users can use this high-speed link.

Relationship to Other Features

Other switch software features support link aggregation groups. The following features have CLI commands or command parameters that support link aggregation: VLANs 802.1Q Spanning Tree

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 370 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Dynamic (IEEE 802.3ad) Link Aggregation

Alcatel-Lucents dynamic link aggregation software allows you to combine several physical links into one large virtual link known as a link aggregation group. Using link aggregation can provide the following benefits: Scalability: On OmniSwitch 6850 switches, you can configure up to 32 link-aggregation groups that can consist of 2, 4, or 8, 10-Mbps, 100-Mbps, 1-Gbps, or 10-Gbps Ethernet links. Reliability: If one of the physical links in a link aggregate group goes down (unless it is the last one) the link aggregate group can still operate. Ease of Migration: Link aggregation can ease the transition from a 100 Mbps Ethernet backbones to Gigabit Ethernet backbones. Note. You can also configure and monitor dynamic link aggregation with WebView, Alcatel-Lucents embedded webbased device management application. WebView is an interactive and easy-to-use GUI that can be launched from OmniVista or a web browser.

Dynamic Link Aggregation Specifications

The table below lists specifications for dynamic aggregation groups and ports:
IEEE Specifications Supported Maximum number of link aggregation groups per switch Range for optional group name Number of links per group supported Group actor admin key Group actor system priority Group partner system priority Group partner admin key Port actor admin key Port actor system priority Port partner admin key Port partner admin system priority Port actor port Port actor port priority Port partner admin port Port partner admin port priority CLI Command Prefix Recognition 802.3ad Aggregation of Multiple Link Segments 32 1 to 255 characters 2, 4, or 8 0 to 65535 0 to 65535 0 to 65535 0 to 65535 0 to 65535 0 to 255 0 to 65535 0 to 255 0 to 65535 0 to 255 0 to 65535 0 to 255 All dynamic link aggregation configuration commands support prefix recognition.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 371 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Dynamic Link Aggregation Default Values

The table below lists default values for dynamic aggregate groups.
Parameter Description Group Administrative State Group Name Group Actor Administrative Key Group Actor System Priority Group Actor System ID Group Partner System ID Group Partner System Priority Group Partner Administrative Key Actor Port Administrative State Actor Port System ID Partner Port System Administrative State Partner Port Admin System ID Partner Port Administrative Key Partner Port Admin System Priority Actor Port Priority Partner Port Administrative Port Partner Port Priority Default Value Enabled No name configured 0 0 00:00:00:00:00:00 00:00:00:00:00:00 0 0 Active timeout aggregate 00:00:00:00:00:00 Active timeout aggregate 00:00:00:00:00:00 0 0 0 0 0

Dynamic Link Aggregation Overview

Link aggregation allows you to combine 2, 4, or 8 physical connections into large virtual connections known as link aggregation groups. On OmniSwitch 6850 switches, you can configure up to 32 link aggregation group that can consist of 2, 4, or 8, 10-Mbps, 100-Mbps, 1-Gbps, or 10-Gbps Ethernet links. You can create Virtual LANs (VLANs), 802.1Q framing, configure Quality of Service (QoS) conditions, and other networking features on link aggregation groups because switch software treats these virtual links just like physical links. Link aggregation groups are identified by unique MAC addresses, which are created by the switch but can be modified by the user at any time. Load balancing for Layer 2 non-IP packets is on a MAC address basis and for IP packets the balancing algorithm uses IP address as well. Ports must be of the same speed within the same aggregate group. Alcatel-Lucents link aggregation software allows you to configure the following two different types of link aggregation groups: Static link aggregate groups Dynamic link aggregate groups

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 372 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Dynamic Link Aggregation Operation

Dynamic aggregate groups are virtual links between two nodes consisting of 2, 4, or 8, 10-Mbps, 100-Mbps, 1Gbps or 10-Gbps fixed physical links. Note that you can configure 16 links on OmniSwitch 6850 switches only. Dynamic aggregate groups use the standard IEEE 802.3ad Link Aggregation Control Protocol (LACP) to dynamically establish the best possible configuration for the group. This task is accomplished by special Link Aggregation Control Protocol Data Unit (LACPDU) frames that are sent and received by switches on both sides of the link to monitor and maintain the dynamic aggregate group. The figure on the following page shows a dynamic aggregate group that has been configured between Switch A and Switch B. The dynamic aggregate group links four ports on Switch A to four ports on Switch B.

Dynamic aggregate groups can be created between: Two OmniSwitch 6850/9000 switches An OmniSwitch 6850/9000 switch and an OmniSwitch 7700/7800 or OmniSwitch 8800 switch An OmniSwitch 6850/9000 switch and an OmniSwitch 6600 Family switch An OmniSwitch 6850/9000 switch and another vendors switch, if that vendor supports IEEE 802.3ad LACP

Relationship to Other Features

Other switch software features support link aggregation groups. For example, you can configure 802.1Q tagging on link aggregation groups in addition to configuring it on individual ports. The following features have CLI commands or command parameters that support link aggregation: VLANs 802.1Q Spanning Tree OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 373 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Embedded Security
The long-term success of world-class organizations is tied to how well they gather and utilize information. Though difficult to measure, an organizations information is arguably its most valuable asset and protecting it has become essential. Their prosperity depends on safeguarding the critical business information, identifying the proper users, providing the proper access and defending against hostile intrusion. Alcatel-Lucents AOS OmniSwitch product family provides organizations with easy, robust and optimal ways to control access to individual infrastructure components and to the individual resources resident on the network both internally and externally. Hence, information security for Internet, Intranet and Extranet applications will be supported through the incorporation of an advanced security feature set. An Overview of the Alcatel-Lucent AOS OmniSwitch 6850 Series Embedded Security features: The following is only a highlight of the advanced security features supported by the OmniSwitch 6850 Series: Partitioned Management PM: Protected multiple user access control (i.e. the switch provides a full suite of commands that allow the user to create and modify User IDs and Passwords (multiple administrative profiles) for access to switch management). The PM feature utilizes an on-board database, or RADIUS, LDAP authentication servers (user profiles are stored within these servers). Authenticated Switch Access (ASA): the ASA feature (user access control or device access control) with Secure Access Logging (AAA service) utilizes an on-board database, RADIUS, LDAP, or ACE authentication servers Automatic Log-out based on a pre-configured timer Denial of Service Attack Defense (DOS protection) IEEE 802.1x industry standard port based authentication challenges users with a password before allowing network access IEEE 802.1x multi-client, multi-VLAN support for per-client authentication and VLAN assignment o IEEE 802.1x with group mobility o IEEE 802.1x with MAC based authentication, group mobility or guest VLAN support o MAC-based authentication for non-802.1x host o Alcatel-Lucent Access Guardian support Port Mapping (Private VLANs) Port Binding Authenticated VLAN that challenges users with username and password and supports dynamic VLAN access based on user Support for host integrity check and remediation VLAN Security through the implementation of OmniVista Quarantine Manager (OV2770-QM) and quarantine VLAN, with OneTouch Security automation PKI authentication for SSH access Learned Port Security or MAC address lockdown allows only known devices to have network access preventing unauthorized network device access RADIUS and LDAP admin authentication prevents unauthorized switch management TACACS+ client allows for authentication-authorization and accounting with a remote TACACS+ server Secure Shell (SSHv2), Secure Socket Layer (SSLv3) for HTTPS and SNMPv3 for encrypted remote management communication Access Control Lists (ACLs) to filter out unwanted traffic including denial of service attacks; Access control lists (ACLs) are per port, MAC SA/DA, IP SA/DA, TCP/ UDP port; Flow based filtering in hardware (L1-L4) Support for Access Control List Manager (ACLMAN) Supports Microsoft Network Access Policy (NAP) protocol Switch protocol security o MD5 for RIPv2, OSPFv2 and SNMPv3 o SSHv2 for secure CLI session with PKI support o SSLv3 for secure HTTP session DHCP Snooping, DHCP IP Spoof protection

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 374 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Learned Port Security

Learned Port Security (LPS) provides a mechanism for authorizing source learning of MAC addresses on 10/100 and Gigabit Ethernet ports. The only types of Ethernet ports that LPS does not support are link aggregate and tagged (trunked) link aggregate ports. Using LPS to control source MAC address learning provides the following benefits: A configurable source learning time limit that applies to all LPS ports. A configurable limit on the number of MAC addresses allowed on an LPS port Dynamic configuration of a list of authorized source MAC addresses. Static configuration of a list of authorized source MAC addresses. Two methods for handling unauthorized traffic: o Stopping all traffic on the port o Or only blocking traffic that violates LPS criteria

Learned port Security Specifications

RFCs supported IEEE Standards supported Ports eligible for Learned Port Security Ports not eligible for Learned Port Security Minimum number of learned MAC addresses allowed per port Maximum number of learned MAC addresses allowed per port Maximum number of configurable MAC address ranges per LPS port. Maximum number of learned MAC addresses per OmniSwitch 6850 (applies to all ports on the switch). Not applicable at this time. Not applicable at this time. 10/100 and gigabit Ethernet ports (fixed, mobile, 802.1Q tagged, and authenticated ports). Link aggregate ports. 802.1Q (trunked) link aggregate ports. 1 100 1 8K

Learned port Security Defaults

Parameter Description LPS status for a port Number of learned MAC addresses allowed on an LPS port Source learning time limit Configured MAC addresses per LPS port MAC address range per LPS port LPS port violation mode Default Disabled 1 Disabled None 00: 00: 00: 00: 00: 00 ff: ff: ff: ff: ff: ff Restrict

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 375 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Learned Port Security Overview

Learned Port Security (LPS) provides a mechanism for controlling network device access on one or more switch ports. Configurable LPS parameters allow the user to restrict the source learning of host MAC addresses to: A specific amount of time in which the switch allows source learning to occur on all LPS ports A maximum number of learned MAC addresses allowed on the port. A list of configured authorized source MAC addresses allowed on the port. Additional LPS functionality allows the user to specify how the LPS port handles unauthorized traffic. The following two options are available for this purpose: Block only traffic that violates LPS port restrictions; authorized traffic is forwarded on the port. Disable the LPS port when unauthorized traffic is received; all traffic is stopped and a port reset is required to return the port to normal operation. LPS functionality is supported on the following 10/100 and Gigabit Ethernet port types: Fixed (non-mobile) Mobile 802.1Q tagged Authenticated The following port types are not supported: Link aggregate Tagged (trunked) link aggregate 802.1X

How LPS Authorizes Source MAC Addresses

When a packet is received on a port that has LPS enabled, switch software checks the following criteria to determine if the source MAC address contained in the packet is allowed on the port: Is the source learning time window open? Is the number of MAC addresses learned on the port below the maximum number allowed? Is there a configured authorized MAC address entry for the LPS port that matches the packets source MAC address? Using the above criteria, the following table shows the conditions under which a MAC address is learned or blocked on an LPS port: Time Limit Max Number Configured MAC Result Below No entry No LPS violation; MAC learned Open Below No entry LPS violation; MAC blocked Closed Open Above No entry LPS violation; MAC blocked Below Yes; entry matches No LPS violation; MAC learned Open Below Yes; entry matches No LPS violation; MAC learned Closed Above Yes; entry matches LPS violation; MAC blocked Open Below Yes; entry does not match No LPS violation; MAC learned Open Below Yes; entry does not match LPS violation; MAC blocked Closed Above Yes; entry does not match LPS violation; MAC blocked Open When a source MAC address violates any of the LPS conditions, the address is considered unauthorized. The LPS violation mode determines if the unauthorized MAC address is simply blocked on the port or if the entire port is disabled. Regardless of which mode is selected, notice is sent to the Switch Logging task to indicate that a violation has occurred.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 376 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Dynamic Configuration of Authorized MAC Addresses

Once LPS authorizes the learning of a source MAC address, an entry containing the address and the port it was learned on is made in an LPS database table. This entry is then used as criteria for authorizing future traffic from this source MAC on that same port. In other words, learned authorized MAC addresses become configured criteria for an LPS port. For example, if the source MAC address 00:da:95:00:59:0c is received on port 2/10 and meets the LPS restrictions defined for that port, then this address and its port are recorded in the LPS table. All traffic that is received on port 2/10 is compared to the 00:da:95:00:59:0c entry. If any traffic received on this port consists of packets that do not contain a matching source address, the packets are then subject to the LPS source learning time limit window and the maximum number of addresses allowed criteria. When a dynamically configured MAC address is added to the LPS table, it does not become a configured MAC address entry in the LPS table until the switch configuration file is saved and the switch is rebooted. If a reboot occurs before this is done, all dynamically learned MAC addresses in the LPS table are cleared.

Static Configuration of Authorized MAC Addresses

It is also possible to statically configure authorized source MAC address entries into the LPS table. This type of entry behaves the same way as dynamically configured entries in that it authorizes port access to traffic that contains a matching source MAC address. Static source MAC address entries, however, take precedence over dynamically learned entries. For example, if there are 2 static MAC address entries configured for port 2/1 and the maximum number allowed on port 2/1 is 10, then only 8 dynamically learned MAC addresses are allowed on this port. Note that source learning of configured authorized MAC addresses is still allowed after the LPS time limit has expired. However, all learning is stopped if the number of MAC addresses learned meets or exceeds the maximum number of addresses allowed, even if the LPS time limit has not expired. There are two ways to define a static source MAC address entry in the LPS table; specify an individual MAC address or a range of MAC addresses.

Understanding the LPS Table

The LPS database table is separate from the source learning MAC address table. However, when a MAC is authorized for learning on an LPS port, an entry is made in the MAC address table in the same manner as if it was learned on a non-LPS port. In addition to dynamic and configured source MAC address entries, the LPS table also provides the following information for each eligible LPS port: The LPS status for the port; enabled or disabled The maximum number of MAC addresses allowed on the port The violation mode selected for the port; restrict or shutdown Statically configured MAC addresses and MAC address ranges All MAC addresses learned on the port The management status for the MAC address entry; configured or dynamic Note that dynamic MAC address entries become configured entries after the switch configuration is saved and the switch is rebooted. However, any dynamic MAC address entries that are not saved to the switch configuration are cleared if the switch reboots before the next save. If the LPS port is shut down or the network device is disconnected from the port, the LPS table entries for this port are retained, but the source learning MAC address table entries for the same port are automatically cleared. In addition, if an LPS table entry is intentionally cleared from the table, the MAC address for this entry is automatically cleared from the source-learning table at the same time.

Selecting the Security Violation Mode

By default, the security violation mode for an LPS port is set to restrict. In this mode, when an unauthorized MAC address is received on an LPS port, the packet containing the address is blocked. However, all other packets that contain an authorized source MAC address are allowed to forward on the port. Note that unauthorized source MAC addresses are not learned in the LPS table but are still recorded in the source learning MAC address table with a filtered operational status. This allows the user to view MAC addresses that were attempting unauthorized access to the LPS port. The other violation mode option is shutdown. In this mode, the LPS port is disabled when an unauthorized MAC address is received; all traffic is prevented from forwarding on the port. After a shutdown occurs, a manual reset is required to return the port back to normal operation. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 377 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

IP-Directed Broadcasts
An IP directed broadcast is an IP datagram that has all zeroes or all 1s in the host portion of the destination IP address. The packet is sent to the broadcast address of a subnet to which the sender is not directly attached. Directed broadcasts are used in denial-of-service smurf attacks. In a smurf attack, a continuous stream of ping requests is sent from a falsified source address to a directed broadcast address, resulting in a large stream of replies, which can overload the host of the source address. By default, the switch drops directed broadcasts. Typically, directed broadcasts should not be enabled.

Denial of Service (DoS) Filtering

By default, the switch filters denial of service (DoS) attacks, which are security attacks aimed at devices that are available on a private network or the Internet. Some of these attacks aim at system bugs or vulnerability (for example, teardrop attacks), while other types of these types of attacks involve generating large volumes of traffic so that network service will be denied to legitimate network users (such as Pepsi attacks). These attacks include the following: ICMP Ping of DeathPing packets that exceed the largest IP datagram size (65535 bytes) are sent to a host and hang or crash the system. SYN AttackFloods a system with a series of TCP SYN packets, resulting in the host issuing SYN-ACK responses. The half open TCP connections can exhaust TCP resources, such that no other TCP connections are accepted. Land AttackSpoofed packets are sent with the SYN flag set to a host on any open port that is listening. The machine may hang or reboot in an attempt to respond. Teardrop/Bonk/Boink attacksBonk / Boink / teardrop attacks generate IP fragments in a special way to exploit IP stack vulnerabilities. If the fragments overlap the way those attacks generate packets, an attack is recorded. Since teardrop, bonk and Boink all use the same IP fragmentation mechanism to attack, these are no distinction between detection of these attacks. The old IP fragments in the fragmentation queue are also reaped once the reassemble queue goes above certain size. Pepsi AttackThe most common form of UDP flooding directed at harming networks. A Pepsi attack is an attack consisting of a large number of spoofed UDP packets aimed at diagnostic ports on network devices. This can cause network devices to use up a large amount of CPU time responding to these packets. The switch can be set to detect various types of port scans by monitoring for TCP or UDP packets sent to open or closed ports. Monitoring is done in the following manner: Packet penalty values set: TCP and UDP packets destined for open or closed ports are assigned a penalty value. Each time a packet of this type is received, its assigned penalty value is added to a running total. This total is cumulative and includes all TCP and UDP packets destined for open or closed ports. Port scan penalty value threshold: The switch is given a port scan penalty value threshold. This number is the maximum value the running penalty total can achieve before triggering an SNMP trap. Decay value: A decay value is set. The running penalty total is divided by the decay value every minute. Trap generation: If the total penalty value exceeds the set port scan penalty value threshold, a trap is generated to alert the administrator that a port scan may be in progress.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 378 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Authenticated VLANs (A-VLANs)

Authenticated VLANs control user access to network resources based on VLAN assignment and a user login process; the process is sometimes called user authentication or Layer 2 Authentication. (Another type of security is device authentication, which is set up through the use of port-binding VLAN policies or static port assignment. The terms authenticated VLANs (A-VLANs) and Layer 2 Authentication is synonymous. Layer 2 Authentication is different from another feature in the switch called Authenticated Switch Access, which is used to grant individual users access to manage the switch.

Authenticated Network Overview

An authenticated network involves several components as shown in this illustration.

Authentication serversA RADIUS or LDAP server must be configured in the network. The server contains a database of user information that the switch checks whenever a user tries to authenticate through the switch. (Note that the local user database on the switch may not be used for Layer 2 authentication.) Backup servers may be configured for the authentication server. RADIUS or LDAP server: Follow the manufacturers instructions for your particular server. The external server may also be used for Authenticated Switch Access. RADIUS or LDAP client in the switch: The switch must be set up to communicate with the RADIUS or LDAP server. Authentication clientsAuthentication clients login through the switch to get access to authenticated VLANs. There are three types of clients: AV-Client. This is an Alcatel-Lucent-proprietary authentication client. The AV-Client does not require an IP address prior to authentication. The client software must be installed on the users end station. Telnet client: Any standard Telnet client may be used. An IP address is required prior to authentication. Web browser client: Any standard Web browser may be used (Netscape or Internet Explorer). An IP address is required prior to authentication. Authenticated VLANsAt least one authenticated VLAN must be configured. Authentication portAt least one mobile port must be configured on the switch as an authentication port. This is the physical port through which authentication clients are attached to the switch. DHCP ServerA DHCP server can provide IP addresses to clients prior to authentication. After authentication, any client can obtain an IP address in an authenticated VLAN to which the client is allowed access. A relay to the server must be set up on the switch. Authentication agent in the switchAuthentication is enabled when the server(s) and the server authority mode is specified on the switch.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 379 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Authentication Clients
The following describes the Telnet authentication client, Web browser authentication client, and Alcatel-Lucents proprietary AV-Client. An overview of authentication clients is given in the following table:
Type of Client AV-Client Telnet Secure No No Single Sign-on Yes No IP Address Required No Yes IP Release/ Renew Automatic Manual Platforms Supported Windows only (except ME) Windows Linux Mac OS 9.x (no Telnet by default) Mac OS X.1 Windows (IE version 4.72 and later; Netscape version 4.7 and later) Linux (Netscape version 4.75 and later) Mac OS 9.x (IE versions 5.5 and later, Including 5.0 and 5.14) Mac OS X.1 (IE versions between 5.0 And 5.5, except 5.0, 5.5, and 5.14)

Web Browser (HTTP)

Yes (SSL)

No

Yes

Automatic

Telnet Authentication Client

Telnet clients authenticate through a Telnet session. Make sure a Telnet client is available on the client station. No specialized authentication client software is required on Telnet client workstations. Provide an IP address for the client. Telnet clients require an address prior to authentication. The address may be statically assigned if the authentication network is set up in single authority mode with one authenticated VLAN. The address may be assigned dynamically if a DHCP server is located in the network. DHCP is required in networks with multiple authenticated VLANs. Configure a DHCP server. Telnet clients may get IP addresses via a DHCP server prior to authenticating or after authentication in order to move into a different VLAN. When multiple authenticated VLANs are configured, after the client authenticates the client must issue a DHCP release/renew request in order to be moved into the correct VLAN. Typically Telnet clients cannot automatically do a release/renew and must be manually configured.

Web Browser Authentication Client

Web browser clients authenticate through the switch via any standard Web browser software (Netscape Navigator or Internet Explorer). Make sure a standard browser is available on the client station. No specialized client software is required. Provide an IP address for the client. Web browser clients require an address prior to authentication. The address may be statically assigned if the authentication network is set up in single authority mode with one authenticated VLAN. The address may be assigned dynamically if a DHCP server is located in the network. DHCP is required in networks with multiple authenticated VLANs. Configure a DHCP server. Web browser clients may get IP addresses via a DHCP server prior to authenticating or after authentication in order to move into a different VLAN. When multiple authenticated VLANs are configured, after the client authenticates the client must issue a DHCP release/renew request in order to be moved into the correct VLAN. Web browser clients automatically issue DHCP release/renew requests after authentication. Configure a DNS name on the switch. A DNS name must be configured so that users may enter a URL rather than an IP address in the browser command line.

SSL for Web Browser Clients

A Secure Socket Layer (SSL) is used to authenticate Web browser clients. A certificate from a Certification Authority (CA) or a self-signed (private) certificate must be installed on the switch. A self-signed certificate is provided by AlcatelLucent (wv-cert.pem). If you are using a well-known certificate or some other self-signed certificate, you should replace the wv-cert.pem file with the relevant file. Web browser clients will automatically recognize well-known SSL certificates, but if a self-signed certificate (such as the wv-cert.pem file) is used, the client will not automatically recognize the certificate. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 380 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Windows, Linux, and Mac OS 9 Clients If you are using the wv-cert.pem file or another self-signed certificate, the client will not recognize the certificate, and a warning message will display on the client; however, the client will be allowed to authenticate.

The AV-Client
The AV-Client is a proprietary Windows-based application that is installed on client end stations. The AV-Client does not require an IP address in order to authenticate; the client relies on the DLC protocol (rather than IP) to communicate with the authentication agent in the switch. After authentication, the client may issue a DHCP release/renew request to get an IP address; a utility in the client software may be used to configure this automatic request. The AV-Client software requires three main installation steps as listed here. These steps are slightly different depending on the version of Windows you are using. Load the Microsoft DLC protocol stack. Load the AV-Client software. Set the AV-Client as primary network login (Windows 95 and 98). Configure the AV-Client for DHCP (optional). The Microsoft DLC Protocol Stack and the AV-Client Software are supported on: Windows 2000 and Windows NT Windows 98 Windows 95

The AV-Client & DHCP

For an AV-Client, DHCP configuration is not required. AV-Clients do not require an IP address to authenticate, but they may want an IP address for IP communication in an authenticated VLAN. At startup, an AV-Client user PC workstation will issue a Windows DHCP request if the AV-Clients DHCP release/renew feature is enabled. This feature is disabled by default. The AV-Client is capable of obtaining an address from the default client VLAN or whatever VLAN it authenticates into if a DHCP server is located in the VLAN. The DHCP tab of the configuration utility gives you several options for managing DHCP when it is enabled. You also have the option of disabling DHCP operations.

Delay for IP Address Request

You can specify a delay between the moment the client workstation moves into an authentication VLAN and the moment a DHCP request is issued for an IP address. You can specify a delay between the moment the client workstation moves into the default VLAN and the moment a DHCP request is issued for an IP address.

Releasing the IP Address

You can specify a delay between the moments the client workstation logs off the network and the DHCP releases the IP address assigned to the client. You can configure the utility so that DHCP releases the IP address before the client workstation leaves the default VLAN. Note. A delay between DHCP release and client logoff is recommended because the DHCP servers MAC address may be timed out in the AV-Clients ARP table. If that is the case, the client must send an ARP packet to discover the DHCP servers MAC address before it can send the release packet. If the logoff packet is sent to the switch before the release packet gets sent, then the IP address will never be released. Increasing the value of the delay parameter can prevent this from happening.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 381 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Port Binding and Authenticated VLANs

By default, authenticated VLANs do not support port-binding rules. These rules are used for assigning devices to authenticated VLANs when device traffic coming in on an authenticated port matches criteria specified in the rule. You can globally enable the switch so that port-binding rules may be enabled on any authenticated VLAN on the switch. The port binding rule types that are allowed on authenticated VLANs are as follows: MAC-Port-IP address MAC-Port The MAC-port-protocol, MAC-IP address, port-IP address, and Port-Protocol binding rules are not supported on authenticated VLANs. In addition to the above binding rule types, however, a MAC range rule may also be applied to authenticated ports.

The Server Authority Mode

Authentication servers for Layer 2 authentication are configured in one of two modes: single authority or multiple authorities. Single authority mode uses a single list of servers (one primary server and up to three backups) to poll with authentication requests. Multiple authority modes use multiple lists of servers and backups, one list for each authenticated VLAN. Note. Only one mode is valid on the switch at one time. At least one server must be configured in either mode. Up to three backup servers total may be specified. Note. Each RADIUS and LDAP server may each have an additional backup host of the same type configured.

Single Mode
This mode should be used when all authenticated VLANs on the switch are using a single authentication server (with optional backups) configured with VLAN information. When this mode is configured, a client is authenticated into a particular VLAN or VLANs. (For the client to be authenticated into multiple VLANs, each VLAN must be configured for a different protocol.) When a client first makes a connection to the switch, the agent in the switch polls the authentication server for a match with a clients user name and password. If the authentication server is down, the first backup server is polled. The switch uses the first available server to attempt to authenticate the user. (If a match is not found on that server, the authentication attempt fails. The switch does not try the next server in the list.) If a match is found on the first available server, the authentication server sends a message to the agent in the switch that includes the VLAN IDs to which the client is allowed access. The agent then moves the MAC address of the client out of the default VLAN and into the appropriate authenticated VLAN(s).

Multiple Mode
Multiple authority modes associate different servers with particular VLANs. This mode is typically used when one party is providing the network and another is providing the server. When this mode is configured, a client is first prompted to select a VLAN. After the VLAN is selected, the client then enters a user name and password. The server configured for that particular authenticated VLAN is polled for a match. (If the server is unavailable, the switch polls the first backup server, if one is configured.) If a match is not found on the first available server, the authentication attempt fails. If a match is found, the clients MAC address is moved into that VLAN. A server in multiple authority modes does not have to be configured with VLAN information. If the same server services more than one VLAN, the same user ID and password may be used to authenticate into one of several VLANs, depending on which VLAN the user selects at authentication. Clients are only able to authenticate into one VLAN at a time. (In single authority mode, clients can authenticate into more than one VLAN at a time if each VLAN is configured for a different protocol.)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 382 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

User Network Profile

The User Network Profile feature provides the capability to have users assigned to user roles during authentication. It works only with a RADIUS authentication server. The user role is returned from the RADIUS server through the Filter-ID attribute. A mapping table is provided to look up the VLAN ID based on the user role returned from the authentication server. AAA uses the Filter-ID attribute value returned by the RADIUS server to lookup the corresponding profile name and assigns the user to the associated VLAN. The role name is a case-sensitive ASCII string. If both a VLAN ID and a role name are returned by the RADIUS server, the VLAN associated with the role name takes precedence. Multiple names can be mapped to the same VLAN. The user network profile table can have a maximum of 4096 entries and contains the following two elements: Name VLAN ID

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 383 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IEEE 802.1X
Physical devices attached to a LAN port on the switch through a point-to-point LAN connection may be authenticated through the switch through port-based network access control. This control is available through the IEEE 802.1X standard implemented on the switch.

IEEE 802.1X Specifications

RFCs Supported RFC 2284PPP Extensible Authentication Protocol (EAP) RFC 2865Remote Authentication Dial In User Service (RADIUS) RFC 2866RADIUS Accounting RFC 2867RADIUS Accounting Modifications for Tunnel Protocol Support RFC 2868RADIUS Attributes for Tunnel Protocol Sup-port RFC 2869RADIUS Extensions IEEE 802.1X-2001Standard for Port-based Network Access Control 802.1X RADIUS Usage Guidelines

IEEE Standards Supported

IEEE 802.1X Defaults

The following table lists the defaults for 802.1X port configuration through the 802.1x command and the relevant command keywords:
Description Port control in both directions and incoming only. Port control authorized on the port. The time during which the port will not accept an 802.1X authentication attempt. The time before an EAPOL Request Identity will be re-transmitted. Number of seconds before the switch will time out an 802.1X user who is attempting to authenticate. Maximum number of times the switch will retransmit an authentication request before it times out. Amount of time that must expire before a re authentication attempt is made. Whether or not the port is re-authenticated. Default Both Auto 60 seconds 30 seconds 30 seconds 2 3600 seconds No re-authentication

The following table shows the default for authenticating 802.1X ports through the aaa authentication 802.1x command:
Description Whether any traffic will be allowed or restricted after authenticating the 802.1X port Default Open-unique

Note. By default, accounting is disabled for 802.1X authentication sessions.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 384 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

802.1X Overview
The 802.1X standard defines port-based network access controls, and provides the structure for authenticating physical devices attached to a LAN. It uses the Extensible Authentication Protocol over LAN (EAPOL). There are three components for 802.1X: The SupplicantThis is the device connected to the switch. The device may be connected directly to the switch or via a point-to-point LAN segment. Typically the supplicant is a PC or laptop. The Authenticator Port Access Entity (PAE)This entity requires authentication from the supplicant. The authenticator is connected to the supplicant directly or via a point-to-point LAN segment. The OmniSwitch acts as the authenticator. The Authentication ServerThis component provides the authentication service and verifies the credentials (username, password, challenge, etc.) of the supplicant. On the OmniSwitch, only RADIUS servers are currently supported for 802.1X authentication. Note: there is no switch-based local database support for 802.1x authentication. On the OmniSwitch 6850, configurable device classification policies are available to handle access of non-supplicant devices on 802.1x ports.

Note. The OmniSwitch itself cannot be an 802.1X supplicant.

802.1X Port Behavior

Before any device is authenticated through an 802.1X port, the port will only process 802.1X frames (EAPoL frames) from an unknown source. When an EAPoL frame or an unknown source data frame is received from a supplicant, the switch sends an EAP packet to request the supplicants identity. The supplicant then sends the information (an EAP response), which is validated on an authentication server set up for authenticating 802.1X ports. The server determines whether additional information (a challenge, or secret) is required from the supplicant. After the supplicant is successfully authenticated, the MAC address of the supplicant is learned in the appropriate VLAN depending on the following conditions: If the authentication server returned a VLAN ID, then the supplicant is assigned to that VLAN. All subsequent traffic from the supplicant is then forwarded on that VLAN. If the authentication server does not return a VLAN ID, then the supplicant is classified by Group Mobility and dynamically assigned to a VLAN or carried on the default VLAN for the 802.1X port. Note: multiple supplicants can be authenticated on a given 802.1X port Each supplicant MAC address received on the port is authenticated and learned separately. Only those that authenticate successfully are allowed on the port, as described above. Those that fail authentication are blocked on the 802.1X port. The global configuration of this feature is controlled by the aaa authentication 802.1x command. This command enables 802.1X for the switch and identifies the primary and backup authentication servers. Using the 802.1x command, an administrator may force an 802.1X port to always accept any frames on the port (therefore not requiring a device to first authenticate on the port); or an administrator may force the port to never accept any frames on the port.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 385 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

802.1X Ports and DHCP

DHCP requests on an 802.1X port are treated as any other traffic on the 802.1X port. When the port is in an unauthorized state (which means no device has authenticated on the port), the port is blocked from receiving any traffic except 802.1X packets. This means that DHCP requests will be blocked as well. When the port is in a forced unauthorized state (the port is manually set to unauthorized), the port is blocked from receiving all traffic, including 802.1X packets and DHCP requests. If the port is in a forced authorized state (manually set to authorized), any traffic, including DHCP, is allowed on the port. If the port is in an authorized state because a device has authenticated on the port, only traffic with an authenticated MAC address is allowed on the port. DHCP requests from the authenticated MAC address are allowed; any others are blocked.

Re-authentication
After a supplicant has successfully authenticated through an 802.1X port, the switch may be configured to periodically reauthenticate the supplicant (re-authentication is disabled by default). In addition, the supplicant may be manually re-authenticated. The re-authentication process is transparent to a user connected to the authorized port. The process is used for security and allows the authenticator (the OmniSwitch) to maintain the 802.1X connection. Note. If the MAC address of the supplicant has aged out during the authentication session, the 802.1X software in the switch will alert the source learning software in the switch to re-learn the address. 802.1X ports may also be initialized if there is a problem on the port. Initializing a port drops connectivity to the port and requires the port to be re-authenticated.

802.1X Accounting
802.1X authentication sessions may be logged if servers are set up for 802.1X accounting. Accounting may also be done through the local Switch Logging feature.

Compared to Authenticated VLANs

A given port cannot be both a VLAN-authenticated port and an 802.1X port. An 802.1X user, however, may be authenticated and moved into an authenticated VLAN if the RADIUS authentication server specifies a VLAN for that user and the authenticated VLAN is set up on the switch through the vlan authentication command. Both 802.1X and authenticated VLANs may use the same RADIUS authentication server.

Port-Based Network Access Control

For port-based network access control, the switch must know which servers to use for authenticating 802.1X supplicants and how to treat traffic coming in on 802.1X ports. These are global parameters. In addition, 802.1X must be enabled on each port that is connected to an 802.1X supplicant (or device). Optional parameters may be set for each 802.1X port.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 386 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

802.1X on the OmniSwitch 6850

In addition to the authentication and VLAN classification of 802.1x clients (supplicants), the OmniSwitch 6850 implementation of 802.1x secure port access extends this type of functionality to non-802.1x clients (non-supplicants). To this end device classification policies are introduced to handle both supplicant and non-supplicant access to 802.1x ports. By default non-supplicant devices are automatically blocked on 802.1x-enabled ports. In some cases, however, it is desirable to allow non-supplicant access on these ports. For example, using device policies a non-supplicant may gain access to a pre-determined VLAN. Such a VLAN might serve as a guest VLAN for such devices requiring restricted access to the switch. Supplicant devices are initially processed using 802.1x authentication via a remote RADIUS server. If authentication is successful and returns a VLAN ID, the supplicant is assigned to that VLAN. If not, then any configured device classification policies for the port are applied to determine VLAN assignment for the supplicant. If there are no policies, then the default port behavior for 802.1x ports is in affect.

Device Classification Policies

There are two types of policies: supplicant and non-supplicant. Supplicant policies use 802.1x authentication via a remote RADIUS server and provide alternative methods for classifying supplicants if the authentication process either fails or does not return a VLAN ID. Non-supplicant policies use MAC authentication via a remote RADIUS server or can bypass authentication and only allow strict assignment to specific VLANs. MAC authentication verifies the source MAC address of a non-supplicant device via a remote RADIUS server. Similar to 802.1x authentication, the switch sends RADIUS frames to the server with the source MAC address embedded in the username and password attributes. One supplicant and one non-supplicant policy is allowed for each 802.1x port. Configuring a new supplicant or non-supplicant policy overwrites any policies that may already exist for the port. The following types of device classification policies are available: 1 802.1x authenticationperforms 802.1x authentication via a remote RADIUS server. 2 MAC authenticationsperforms MAC based authentication via a remote RADIUS server. 3 Group Mobility rulesuses Group Mobility rules to determine the VLAN assignment for a device 4 Strict Group Mobility rulesuses Group Mobility rules to determine the VLAN assignment for a device; does not allow assignment to authenticated VLANs. 5 VLAN IDassigns the device to the specified VLAN. 6 Strict VLAN IDassigns the device to the specified VLAN; does not allow assignment to authenticated VLANs. 7 Default VLANassigns a device to the default VLAN for the 802.1x port. 8 Strict Default VLANassigns a device to the default VLAN for the 802.1x port; does not allow assignment to authenticated VLANs. 9 Blockblocks a device from accessing the 802.1x port. The first policy applies only to supplicants; policy seven and eight apply only to non-supplicants. The remaining policies apply to both supplicants and non-supplicants. Policies three through eight are combined with policy one or two to provide alternative methods for classifying devices when successful authentication does not return a VLAN ID. In addition, policies four and six are configurable without using one or two, as they prevent assignment to authenticated VLANs while still allowing restricted access for the device. When multiple policies are specified when configuring a device classification policy, they form a compound policy. Compound policies that use 802.1x authentication are supplicant policies; all others are non-supplicant policies. The order in which policies are applied to client traffic is determined by the order in which the policy was configured. For example, if a compound non-supplicant policy is configured by specifying MAC authentication, Group Mobility rules, and default VLAN, then the policies are applied in the following sequence: 1 MAC authentication is performed. 2 If authentication was successful and provided a VLAN ID, the client is assigned to that VLAN and no further policies are applied. 3 If a VLAN ID was not provided or authentication failed, then Group Mobility rules are applied. 4 If there are no Group Mobility rules that match the client traffic, then the device is learned in the default VLAN for the port.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 387 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Port Mapping (AKA Private VLAN)

Port Mapping is a security feature, which controls communication between peer users. Each session comprises a session ID, a set of user ports, and/or a set of network ports. The user ports within a session cannot communicate with each other and can only communicate via network ports. In a port mapping session with user port set A and network port set B, the ports in set A can only communicate with the ports in set B. If set B is empty, the ports in set A can communicate with rest of the ports in the system. A port mapping session can be configured in the unidirectional or bi-directional mode. In the unidirectional mode, the network ports can communicate with each other within the session. In the bi-directional mode, the network ports cannot communicate with each other. Network ports of a unidirectional port mapping session can be shared with other unidirectional sessions, but cannot be shared with any sessions configured in the bi-directional mode. Network ports of different sessions can communicate with each other.

Port Mapping Specifications

Ports Supported Mapping Sessions Ethernet (10 Mbps)/Fast Ethernet (100 Mbps)/Gigabit Ethernet (1 Gb/1000 Mbps) /10 Gigabit Ethernet (10 Gb/10000 Mbps). Eight sessions supported per standalone switch and stack.

Port Mapping Defaults

Parameter Description Mapping Session Creation Mapping Status configuration Port Mapping Direction Default Value/Comments No mapping sessions Disabled Bi-directional

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 388 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Example Port Mapping Overview

The following diagram shows a four-switch network configuration with active port mapping sessions. In the network diagram, the Switch A is configured as follows: Port-mapping session 1 is created with user ports 2/1, 2/2 and network ports 1/1, 1/2 and is configured in the unidirectional mode Port-mapping session 2 is created with user ports 3/1, 3/2, and 3/3 and network port 1/3 Creating a port mapping session 1 with user ports 2/1, 2/2 and network ports 1/1 configures the Switch D

In the above example topology: Ports 2/1 and 2/2 on Switch A do not interact with each other and do not interact with the ports on Switch B. Ports 2/1, 2/2, and 3/1 on Switch B interact with all the ports of the network except with ports 2/1 and 2/2 on Switch A Ports 2/1 and 2/2 on Switch D do not interact with each other but they interact with all the user ports on Switch A except 3/1, 3/2, and 3/3. They also interact with all the ports on Switch B and Switch C. Ports 3/1, 3/2, and 2/1 on Switch C can interact with all the user ports on the network except 3/1, 3/2, 3/3 on Switch A

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 389 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Access Control Lists -- ACLs

Access Control Lists (ACLs) are Quality of Service (QoS) policies used to control whether or not packets are allowed or denied at the switch or router interface. ACLs are sometimes referred to as filtering lists. ACLs are distinguished by the kind of traffic they filter. In a QoS policy rule, the type of traffic is specified in the policy condition. The policy action determines whether the traffic is allowed or denied. In general, the types of ACLs include: Layer 2 ACLsfor filtering traffic at the MAC layer. Usually uses MAC addresses or MAC groups for filtering. Layer 3/4 ACLsfor filtering traffic at the network layer. Typically uses IP addresses or IP ports for filtering; Multicast ACLsfor filtering IGMP traffic

ACL Specifications
These specifications are the same as those for QoS in general: Maximum number of policy rules Maximum number of policy rules per Ethernet port Maximum number of policy rules per 10Gigabit port Maximum number of policy conditions Maximum number of policy actions Maximum number of policy services Maximum number of groups (Network, MAC, service, port) Maximum number of group entries 1024 101 997 2048 2048 256 1024 512 per group

ACL Defaults
Parameter Default Accept Global bridged disposition Accept Global routed disposition Accept Global multicast disposition Accept Policy rule disposition 0 (lowest) Policy rule precedence Note that in the current software release, the deny and drop options produce the same effect; that is, that traffic is silently dropped.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 390 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

ACL Overview
ACLs provide moderate security between networks. The following illustration shows how ACLs may be used to filter subnetwork traffic through a private network, functioning like an internal firewall for LANs.

When traffic arrives on the switch, the switch checks its policy database to attempt to match Layer-2 or Layer3/4 information in the protocol header to a filtering policy rule. If a match is found, it applies the relevant disposition to the flow. Disposition determines whether a flow is allowed or denied. There is a global disposition (the default is accept), and individual rules may be set up with their own dispositions. Note. In some network situations, it is recommended that the global disposition be set to deny, and that rules be created to allow certain types of traffic through the switch. When multiple policy rules exist for a particular flow, each policy is applied to the flow as long as there are no conflicts between the policies. If there is a conflict, then the policy with the highest precedence is applied to the flow. Note. QoS policy rules may also be used for traffic prioritization and other network scenarios.

Rule Precedence
All rules that match a flow will be applied to the flow, unless one of the following rule conflicts occur: Actions specified by one or more rules are in conflict with each other. Conditions specified in one or more contiguous rules are the same. If any of the above items are true, then rule precedence is used to determine which rule to apply to the flow. (This functionality is different from the OmniSwitch 7700/7800/8800, which will always apply the rule with the highest precedence.) Rules With Compatible Actions: More than one rule may have the same condition. For example, two rules may have the same IP address condition but different actions. If the actions are compatible, both rules will be applied to the flow, regard-less of the precedence settings. Rules With Conflicting Actions: If the actions are in conflict, however, the switch will apply only the rule with the highest precedence.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 391 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

How Precedence is Determined

When there is a conflict between rules, precedence is determined using one of the following methods: Precedence valueEach policy has a precedence value. The value may be user-configured through the policy rule command in the range from 0 (lowest) to 65535 (highest). (The range 30000 to 65535 is typically reserved for PolicyView.) By default, a policy rule has a precedence of 0. Configured rule orderIf a flow matches more than one rule and both rules have the same precedence value, the rule that was configured first in the list will take precedence. Note. Minimum bandwidth rules have the highest precedence over all other rules in the system. They are enforced internally and cannot be overridden by user-configured settings. In addition, specifying a minimum bandwidth value implies a maximum bandwidth of the same value.

Interaction With Other Features

Routing ProtocolsLayer 3 filtering is compatible with routing protocols on the switch, including RIP and OSPF. If VRRP is also running, all VRRP routers on the LAN must be configured with the same filtering rules; otherwise, the security of the network will be compromised. BridgingLayer 2 and Layer 3 ACLs are supported for bridged and routed traffic.

Valid Combinations
There are limitations to the types of conditions that may be combined in a single rule. A brief overview of these limitations is listed here: Source and destination parameters can be combined in Layer 2, Layer 3, and Layer 4 conditions. Individual items and their corresponding groups cannot be combined in the same condition. For example, a source IP address cannot be included in a condition with a source IP network group.

ACL Configuration Overview

The QoS CLI commands are used specifically to configure ACLs. ACLs are basically a type of QoS policy, and the commands used to configure ACLs are a subset of the switchs QoS commands. To configure an ACL, the following general steps are required: 1. Set the global disposition 2. Create a condition for the traffic to be filtered 3. Create an action to accept or deny the traffic 4. Create a policy rule that combines the condition and the action The basic commands for configuring ACL rules are the same as those for configuring policy rules: Policy condition Policy action Policy rule: A policy rule is made up of a condition and an action.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 392 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Policy Conditions For ACLs

A policy condition for IP filtering may include a particular source IP address, destination IP address, source IP port, or destination IP port. Or, the condition may simply refer to the network group, MAC group, port group, or service group. Typically ACLs use group keywords in policy conditions. A single rule, therefore, filters traffic for multiple addresses or ports. For example: -> Policy port group pgroup1 3/1-2 4/3 5/4 -> Policy condition c2 source port group pgroup1 In this example, a Layer 2 condition (c2) specifies that traffic matches the ports included of the pgroup1 port group. The condition also specifies that the port group is a source group. Any traffic coming in on ports 1 or 2 on slot 3, port 3 on slot 4, or port 4 on slot 5 will match condition c2. The following table lists the keywords for the policy condition command that are typically used for the different types of ACLs: Layer 2 ACL Condition Layer 3/4 ACL Condition Multicast ACL Condition Keywords Keywords Keywords Source mac Source ip Multicast ip Source network group Multicast network group Source mac group Destination ip Destination ip Destination mac Destination network group Destination port Destination mac group Source ip port Destination port group Source vlan Destination ip port Destination mac Source port Service Destination mac group Source port group Destination port Service group Destination port group Ip protocol Ethertype Destination port Destination port group Icmptype Icmpcode Note that the individual address, service, or port cannot be used in conjunction with the same type of condition group. For example, you cannot specify in the same rule both a source MAC address and a source MAC group.

Policy Actions For ACLs

A policy action for IP filtering specifies a disposition, that is, whether the flow is accepted or denied on the switch. To create a policy action, use the policy action command. Use the disposition keyword to define whether the flow is accepted (accept) or denied (deny). For example: -> Policy action a1 disposition accept If you do not specify a disposition for the policy action, the default (accept) will be used.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 393 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Layer 2 ACLs
Layer 2 filtering filters traffic at the MAC layer. Layer 2 filtering may be done for both bridged and routed packets. As MAC addresses are learned on the switch, QoS classifies the traffic based on: MAC address or MAC group Source VLAN Physical slot/port or port group The switch classifies the MAC address as both source and destination. The following policy condition keywords are used for Layer 2 ACLs: Layer 2 ACL Condition Keywords Source mac Destination mac Source mac group Destination mac group Source vlan Destination port Source port Destination port group Source port group Ethertype A group and an individual item cannot be specified in the same condition. For example, a source MAC address and a source MAC group cannot be specified in the same condition. Note that combining Layer 2 and Layer 3 conditions in the same policy is supported.

Layer 3/4 ACLs

The QoS software in the switch filters routed and bridged traffic at Layer 3. For Layer 3/4 filtering, the QoS software in the switch classifies traffic based on: Source IP address or source network group Destination IP address or destination network group IP protocol Source TCP/UDP port Destination TCP/UDP port or service or service group Destination slot/port or destination port group The following policy condition keywords are used for Layer 3 ACLs: Layer 3/4 ACL Condition Keywords: Source ip Source network group Destination ip Destination network group Source ip port Destination ip port Service Service group Ip protocol Destination port Destination port group Icmptype Icmpcode Note that combining Layer 2 and Layer 3 conditions in the same policy is supported.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 394 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Multicast Filtering ACLs

Multicast filtering may be set up to filter clients requesting group membership via the Internet Group Management Protocol (IGMP). IGMP is used to track multicast group membership. The IP Multicast Switching (IPMS) function in the switch optimizes the delivery of IP multicast traffic by sending packets only to those stations that request it. Potential multicast group members may be filtered out so that IPMS does not send multicast packets to those stations. Multicast traffic has its own global disposition. By default, the global disposition is accept. For multicast filtering, the switch classifies traffic based on the multicast IP address or multicast network group and any destination parameters. Note that the destination parameters are used for the client from which the switch will receive the IGMP request. Multicast ACL Keywords Destination ip Destination port Destination port group Destination mac Destination mac group The multicast ip or multicast network group keyword is required in the condition configured for a multicast ACL. If a destination group is specified, the corresponding single value keyword cannot be combined in the same condition. For example, if a destination port is specified, a destination port group cannot be specified in the same condition. To filter multicast clients, specify the multicast IP address, which is the address of the multicast group or stream, and specify the client IP address, VLAN, MAC address, or slot/port. For example: -> Qos default multicast disposition deny -> Policy condition Mclient1 multicast ip 224.0.1.2 destination vlan 5 -> Policy action ok disposition accept -> Policy rule Mrule condition Mclient1 action ok In this example, any traffic coming in on VLAN 5 requesting membership to the 224.0.1.2 multicast group will be allowed.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 395 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using ACL Security Features

The following additional ACL features are available for improving network security and preventing malicious activity on the network: UserPortsA port group that identifies its members as user ports to prevent spoofed IP traffic. When a port is configured as a member of this group, packets received on the port are dropped if they contain a source IP network address that does not match the IP subnet for the port. DropServicesA service group that improves the performance of ACLs that are intended to deny packets destined for specific TCP/UDP ports. Using the DropServices group for this function minimizes processing overhead, which otherwise could lead to a DoS condition for other applications trying to use the switch. ICMP drop rulesAllows condition combinations in policies that will prevent user pings, thus reducing DoS exposure from pings. Two condition parameters are also available to provide more granular filtering of ICMP packets: icmptype and icmpcode. BPDUShutdownPortsA port group that identifies its members as ports that should not receive BPDUs. If a BPDU is received on one of these ports, the port is administratively disabled. TCP connection rulesAllows the determination of an established TCP connection by examining TCP flags found in the TCP header of the packet. Two condition parameters are available for defining a TCP connection ACL: established and tcpflags. Early ARP discardARP packets destined for other hosts are discarded to reduce processing overhead and exposure to ARP DoS attacks. No configuration is required to use this feature; it is always available and active on the switch. Note that ARPs intended for use by a local subnet, AVLAN, VRRP, and Local Proxy ARP are not discarded.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 396 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

ACL Manager (ACLMAN)

Access Control List Manager (ACLMAN) is a function of the Quality of Service (QoS) application that provides an interactive shell for using common industry syntax to create ACLs. Commands entered using the ACLMAN shell are interpreted and converted to Alcatel-Lucent CLI syntax that is used for creating QoS filtering policies. This implementation of ACLMAN also provides the following features: Importing of text files that contain common industry ACL syntax Support for both standard and extended ACLs Creating ACLs on a single command line The ability to assign a name, instead of a number, to an ACL or a group of ACL entries Sequence numbers for named ACL statements Modifying specific ACL entries without having to enter the entire ACL each time to make a change The ability to add and display ACL comments ACL logging extensions to display Layer 2 through 4-packet information associated with an ACL

ACLMAN Defaults
Parameter ACL disposition Logging rate time interval Default Deny 30 seconds

ACLMAN Overview
ACLMAN is a function of the Alcatel-Lucent QoS system that allows network administrators to configure and manage ACLs using common industry syntax. ACLs configured using ACLMAN are transparently converted into Alcatel-Lucent QoS filtering policies and applied to the switch. An ACLMAN interactive shell provides an ACL command line interface that is similar to command interfaces that are available on other industry platforms. This shell serves as a configuration tool for creating ACLs using common industry syntax commands and/or importing industry syntax from text files. The following industry ACL types and features are supported with this implementation of ACLMAN: Standard ACL. This type of ACL compares the source address of a packet to the source address specified in the ACL. Extended ACL. This type of ACL compares the source and destination address of a packet to the source and destination address specified in the ACL. Also provides additional criteria for filtering packets. Numbered ACL. This type of ACL refers to standard or extended ACLs that are assigned a number for identification. Named ACL. This type of ACL refers to standard or extended ACLs that are assigned a name for identification. The following industry ACL types are currently not supported: Reflexive ACLs Context-Based Access Control Authentication Proxy Lock and Key (Dynamic ACLs)

ACLMAN Configuration File

ACLMAN maintains a running configuration and a startup configuration. The running configuration resides in memory and is modified through the interactive shell. The startup configuration is saved in the aclman.cfg file on the switch. ACLMAN looks for this file to obtain its initial configuration when the switch is rebooted or the ACLMAN configure replace command is used to load a new configuration. The ACLMAN write memory command is used to save the running configuration to the aclman.cfg file. If the aclman.cfg file does not exist when the ACLMAN shell is initialized, ACLMAN creates the file with the first write memory command issued to save the running configuration. Note. Issuing a write memory command is required to preserve the ACLMAN running configuration across switch reboots. Editing the aclman.cfg file is possible using a text editor and also provides an additional method for loading ACL statements into the ACLMAN running configuration.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 397 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

ACL Text Files

ACLMAN supports the importing of common industry ACL statements created and saved to a file using a text editor. The import command in the Privileged Exec Mode of the ACLMAN shell triggers ACLMAN to read the specified text file and load the ACL statements into the running configuration. These same statements also become part of the ACLMAN startup configuration when a write memory command is performed. Note that the write memory command triggers ACLMAN to save the running configuration to the aclman.cfg file. It is not possible to direct ACLMAN to write to any other file. Other text files are only read by ACLMAN and are never used to export information from the ACLMAN configuration. ACL statements imported from a text file are treated the same way as statements entered directly through the ACLMAN interactive shell.

ACL Precedence
ACLMAN allows a user to apply common industry ACLs to an Alcatel-Lucent switch. When these ACLs are created using ACLMAN configuration tools, they are automatically assigned an Alcatel-Lucent QoS internal priority of 101. Alcatel-Lucent CLI/SNMP policies are assigned a priority of one by default. As a result, ACLMAN policies will take precedence over Alcatel-Lucent CLI/SNMP policies unless the Alcatel-Lucent policies are configured with a precedence value higher than 101. QoS policies configured through LDAP are given a value in the range 30000 to 65535. Therefore LDAP policies take precedence over ACLMAN policies.

Interaction With the Alcatel-Lucent CLI

ACLMAN is invoked using the aclman CLI command. Once the ACLMAN interactive shell interface is active, no other AlcatelLucent CLI commands are accepted. All ACLMAN configurations is performed using commands specific to the shell interface. QOS policies configured through ACLMAN are visible through the AOS CLI using the show policy commands. Note that ACLMAN policies that are not applied to a switch interface are not yet active on the switch and will not appear in a CLI show command output display. The ACLMAN show commands only display ACLMAN configuration information. There is no ACLMAN command at this time that displays Alcatel-Lucent CLI policy configurations. When the Alcatel-Lucent CLI configuration snapshot command is used to save the switch configuration to an ASCII text file, ACLMAN configured policies are not included. It is possible, however, to create text files containing supported ACL syntax and import the contents of the file into the ACLMAN running configuration.

Using the ACLMAN Shell

The aclman command activates the ACLMAN interactive shell. When the shell is active, the following command prompt appears: Aclman# Once the shell is active, then only supported ACLMAN syntax is allowed. Only one shell can be active at a time on a given switch. The Alcatel-Lucent CLI is not available. There is no predetermined or configurable timeout value that triggers an exit from the ACLMAN shell. The exit command is used to return to the Alcatel-Lucent CLI. However, if the configured timeout value for a CLI or telnet session is reached, the entire session including the ACLMAN shell is dropped. The Alcatel-Lucent CLI command, kill, is available to terminate a session that is frozen. The ACLMAN interactive shell supports partial command recognition. To use this optional feature, enter enough of the command keyword to make it unique and then press the Tab key. ACLMAN fills out the rest of the keyword. For example: Aclman#confi Aclman#configure ter Aclman#configure terminal Aclman (config)# Entering a question mark (?) after a partial command provides a list of potential commands that match the partial entry. For example: Aclman#(config) i? Interface ip Aclman#(config) i OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 398 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Help is an available menu item in each of the shell command modes. In addition, help is also available by Entering a question mark (?) at the command prompt or after entering a command parameter. For example: Aclman (config)#? Access-list Add an access list entry End Return to privileged exec mode Exit Exit from configure mode Help Description of the interactive help system Interface Select an interface to configure Ip Global IP configuration subcommands No Negate a command or set its defaults Time-range Define time range entries Aclman (config)#access-list? <1-99> IP standard access list <100-199> IP extended access list <1300-1999> IP standard access list (expanded range) <2000-2699> IP extended access list (expanded range) Aclman (config) #access-list

ACLMAN Modes and Commands

The ACLMAN interactive shell supports a limited subset of common industry ACL syntax necessary to create Alcatel-Lucent ACLs. In line with industry command line interfaces, the ACLMAN shell provides the following command modes: Privileged Exec Mode Global Configuration Mode Interface Configuration Mode Access List Configuration Mode Time Range Configuration Mode

Supported Protocols and Services

When creating extended IP ACLs, enter one of the following supported protocol types for the required protocol parameter value. Supported Protocol Parameters Ahp Ipinip Igrp Nos Esp Ospf Gre Pcp Icmp Pim Igmp Tcp Ip Udp When creating extended TCP ACLs, enter one of the following supported TCP service types for the required port parameter value. Note that using the port number to specify the service instead of the service name is also allowed.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 399 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Supported TCP Service Parameters Bgp (179) Gopher (70) Pop3 (110) Chargen (19) Hostname (101) Smtp (25) Cmd (rcmd, 514) Ident (113) Sunrpc (111) Daytime (13) Irc (194) Syslog (514) Discard (9) Klogin (543) Tacacs (49) Domain (53) Kshell (544) Talk (517) Echo (7) Login (rlogin, 513) Telnet (23) Exec (rsh, 512) Lpd (515) Time (37) Finger (79) Nntp (119) Uucp (540) Ftp (21) Pim-auto-rp(496) Whois (43) Ftp-data (20) Pop2 (109) Www (HTTP, 80) When creating extended UDP ACLs, enter one of the following supported UDP service types for the required port parameter value. Note that using the port number to specify the service instead of the service name is also allowed. Supported UDP Service Parameters Biff (512) Nameserver (obsolete, 42) Snmptrap (162) Bootpc (BOOTP) client (68) netbios-dgm (138) Sunrpc (111) Bootps (BOOTP) server (67) Netbios-ns (137) Syslog (514) Discard (9) Netbios-ss (139) Tacacs (49) Dnsix (195) Non500-isakmp (4500) Talk (517) Domain (DNS, 53) Ntp (123) Tftp (69) Echo (7) Pim-auto-rp (496) Time (37) Isakmp (500) Rip (router, in.routed, 520) Who (rwho, 513) Mobile-ip (434) Snmp (161) Xdmcp (177)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 400 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Network Security
Network Security (also known as Alcatel-Lucents Traffic Anomaly Detection (TAD) feature or Etherbreaker) is a network monitoring feature that aims to detect the anomalies in the network by analyzing the patterns of ingress and egress packets on a port. These anomalies occur when the traffic patterns of a port do not meet the expectations. The detection of anomalies results in logging, SNMP trap generation, and shutting down of the anomalous port. This feature is mainly used in the Layer2 domain. Note. The Network Security feature is supported only on OmniSwitch 6850 and 9000 Series switches in Release 6.3.1.

Network Security Specifications

RFCs supported IEEE Standards supported Maximum number of monitoring- groups Time duration to observe traffic pattern Minimum traffic to activate anomaly detection Anomaly sensitivity to deviation Not applicable at this time. Not applicable at this time. 32 5 to 3600 in seconds 1 to 100,000 1 to 100

Network Security Defaults

Parameter Status of anomaly detection Log status Trap status Quarantine status Time duration to observe traffic pattern Anomaly sensitivity to deviation Default Disabled Disabled Disabled Disabled 30 seconds 50

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 401 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Network Security Overview

Network Security detects the anomalies in the network traffic by monitoring the difference in the rate of ingress and egress packets on a port, matching a specific traffic pattern. The Network Security software monitors these packets at configured intervals, counts the packets matching certain patterns, and applies anomaly detection rules. If anomalies are detected, then it is reported through a Syslog and/or an SNMP trap and/or the anomalous port is shut down. The Network Security features include the following: Real-time network traffic monitoring Dynamic anomaly detection Dynamic anomalous port quarantining

Anomalies
A network traffic anomaly refers to deviations in the rates of a user-ports ingress and egress packets from expectations. The anomalies are monitored in the network by observing the networks traffic for a configurable time period. During this period, the Network Security counts relevant packets on a port. Anomalies may occur in scenarios, such as the following: When a high number of TCP SYN packets are not expected from a user-port in a short period. When more than one ARP response is received for every ARP request. When a high number of TCP RST packets are not expected in a network in a short period. The above listed scenarios occur in a network due to malicious systems in the network, or when a network is attacked or mis-configured. Network Security detects the following anomalies: Anomaly Description
ARP Address Scan ARP Flood ARP Failure ICMP Address Scan ICMP Flood ICMP Unreachable TCP Port Scan TCP Address Scan SYN Flood SYN Failure SYN-ACK Scan Fin Scan Fin-Ack Diff Rst Count Occurs when a host sends a burst of ARP requests for multiple IP addresses. Occurs when a host receives a burst of ARP request packets. Occurs when ARP queries do not elicit ARP responses. Occurs when multiple hosts receive ICMP echo request packets at the same time. Occurs when a host receives a burst of ICMP echo request packets. Occurs when a host receives a flood of ICMP Unreachable packets. Occurs when a host receives a burst of TCP SYN packets for multiple TCP ports. Occurs when multiple hosts receive TCP SYN packets at the same time. Occurs when a host receives a burst of TCP SYN packets on the same TCP port. Occurs when a host receives fewer SYNACKs than SYNs it sent out. Occurs when a host receives more SYNACKs than SYNs it sent out. Occurs when a host receives a burst of FIN packets. Occurs when a host sees more or fewer FINACK packets than it sent. Occurs when a host receives a flood of RST packets.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 402 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Monitoring Group
A monitoring-group is used by Network Security to configure the anomaly detection on sets of ports. A monitoring-group is identified by a name and has a set of ports as its members. A monitoring-group is created by adding a set of ports to the group or by configuring an anomaly parameter for the group. A monitoring-group exists as long as it has a member port or has at least one of its anomaly parameters configured. The network security configurations are applied according to the monitoring-groups. The anomaly detection parameters of monitoring-groups can be configured by the user. Also, the user can add or remove a port in the monitoring-group. A port can be moved from one monitoring-group to another, but it cannot exist in more than one monitoring-group at a time. Network security is disabled on a port that is not a member of a monitoring-group. Network Security changes an anomaly parameter configuration across all monitoring-groups in the following ways: Group-name all, overwrites the configuration for all the monitoring-groups. Anomaly all, overwrites the configuration for all the anomalies. Network Security has a predefined monitoring-group default, and allows a maximum of 32 monitoring groups including "default" at a time. Network Security applies the rules to match the specific packets when a port is in a monitoring-group. These rules exist as long as the port is a member of any monitoring group. The statistics for the packets are maintained on a per-port basis and are available when a port is a member of the monitoringgroup. When a port is removed from the monitoring-group, the statistics for the packets are cleared. If a monitoring port is moved from one monitoring-group to another, the statistics of the port do not get cleared. A port's anomaly statistics are tracked when that anomaly is configured to be monitored on that port, and are cleared when monitoring is stopped for that anomaly.

Anomaly parameters Description

State: Specifies the status of anomaly detection. Trap: Sends a trap when an anomaly is detected. Log: Logs detected anomalies. Quarantine: Quarantines the port on which an anomaly is detected. If an anomaly is detected, then the source port will be quarantined. The show interfaces port command displays the quarantined ports and use interfaces clear-violation-all command to clear the port violation. Count: The number of packets that must be seen during the period to trigger anomaly detection. Period: The time duration to observe traffic pattern, in seconds. Sensitivity: Sensitivity of anomaly detection to deviation from the expected traffic pattern.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 403 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Distributed Intelligence
The AOS OmniSwitch product family has been designed to bring intelligence to an Enterprise network by implementing a host of intelligent features and services. Carrier-class intelligence insures that users and applications receive the priority and performance they need with ease-of-use management that extends across the entire enterprise. The AOS OmniSwitch product family features state-of-art ASIC-based technology, which includes intelligent layer-2/layer-3 switching & routing, extensive and robust QoS, ACLs, and a host of other advanced features. An Overview of the Alcatel-Lucent AOS Distributed Intelligence features: Distributed architecture with high performing switching fabric capacity State-of-the-art intelligent architecture support for flow-based, policy-based, rule-based layer-2/layer-3/layer-4 wire-speed QoS and traffic management features such as: o Traffic prioritization and layer-2/layer-3/layer-4 classification o Bandwidth management including rate limiting o QoS mapping, re-mapping, marking, re-marking o Advanced Buffering/Queue Algorithms The Quality of Service & Filtering Manager is responsible for managing traffic through user-configured policies. Traffic policies fall into the following categories: o Access Control Lists (or Filtering) o IPMS multicast filtering o Traffic Prioritization & Traffic Shaping o Trusted & Untrusted ports Wire-speed layer-2/layer-3 switching including IPv4 & IPv6 routing Static Routing support: Static routes are user-defined; they carry a higher priority than routes created by dynamic routing protocols. Dynamic Routing support: IP routing [RIPv1&v2, OSPFv2, OSPF-ECMP (including Static ECMP), BGPv4, and VRRP] RDP: Router Discovery Protocol IP Multicast switching with IGMPv1&v2&v3 and IP Multicast routing with DVMRPv3 & PIM-SMv2 IP Multicast Switching (IPMS) is a one-to-many communication technique employed by emerging applications such as video distribution, news feeds, conferencing, netcasting, and resource discovery (OSPF, RIP2, and BOOTP). Unlike unicast, which sends one packet per destination, multicast sends one packet to all devices in any sub-network that has at least one device requesting the multicast traffic. Alcatel-Lucents IPMS feature support is compatible with the following RFCs: o RFC 2236 Internet Group Management Protocol, Version 2 o RFC 2933 Internet Group Management Protocol MIB o RFC 3376 Internet Group Management Protocol, Version 3 IP multicast routing can be used for IP Multicast Switching and Routing (IPMSR). IP multicast routing is a way of controlling multicast traffic across networks. The multicast router discovers which networks want to receive multicast traffic by sending out Internet Group Management Protocol (IGMP) queries and receiving IGMP reports from attached networks. The IGMP reports signal that users want to join a multicast group. If there is more than one multicast router in the network, the router with the lowest IP address is elected the querier router, which is responsible for querying the sub-network for group members. o The IP multicast routing package offers the following two separate protocols (The AOS OmniSwitch 6850 platforms support DVMRPv3 (draft version 10), and PIM-SMv2): o Protocol Independent Multicast Sparse Mode (PIM-SM) RFCs Supported: 2362Protocol Independent Multicast-Sparse Mode (PIM-SM) Protocol Specification 2934Protocol Independent Multicast MIB for IPv4 2932IPv4 Multicast Routing MIB o Distance Vector Multicast Routing Protocol (DVMRP) RFCs Supported 2667IP Tunnel MIB IETF Internet-Drafts Supported: Distance-Vector Multicast Routing Protocol MIB Draft-ietf-idmr-dvmrp-v3-10.txt Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 404 Software & Hardware Release: AOSv6.3.1r01

Draft-ietf-idmr-dvmrp-mib-11.tx Policy based VLANs including IEEE 802.1Q VLAN Trunking: o A set of hosts defined by a set of ports o A set of MAC addresses o Sub-net based: Network address rule o Protocol policies o DHCP (MAC address and port DHCP rules) o Binding VLANs (based on port, MAC, IP and combinations) o IEEE 802.1Q VLANs o DHCP High port density NI modules, high speed (10/100/1000Mbps (triple speed), GigEth, and 10-GigEth) and flexible connectivity with copper and fiber (MiniGBICs) IEEE 802.3x Flow Control on all Network Interfaces Note: the switch does not support honoring the incoming (RX) IEEE 802.3x pause frames, but it does support generating outgoing (TX) IEEE 802.3x pause frames Per port Multicast and Broadcast flood limiting Layer-2/Layer-3 Jumbo frame support Alcatel-Lucent understands that enterprise networking traffic volume is increasing and ultra high-speed Gigabit Ethernet technology has emerged, conventional Ethernet's packaging of data into mini-chunks is inhibiting the ability of servers and applications to take full advantage of next-generation networks. The speed and capacity of today's Ethernets are pushing the processor limits of most installed servers, and more data is being transferred between servers. For these reasons, extending Ethernet's frame size to reduce server overhead and increase throughput has become an attractive and logical option. The use of Jumbo Frames can deliver an increase in throughput with a simultaneous decrease in CPU utilization. Applications optimized for large frame sizes can easily be integrated with existing Ethernet LANs without causing interoperability problems. The AOS OmniSwitch 6850 platforms support layer-2/layer-3 9K Byte (9216 Byte) jumbo frames on Gigabit Eth. ports. IP fragmentation for Gigabit Ethernet routed ports with per flow MTU is also supported Maximum Transfer Units (MTU): o Layer-2 Ethernet Frame Size: o Untagged: 1518 Bytes without IEEE 802.1Q tags o Tagged: 1522 Bytes with IEEE 802.1Q tags o Long Frame Size (enabled by default): 1553 Bytes (IEEE 8021.Q tagged or untagged) o Frame Type: Type2, LLC, SNAP, RAW 802.3 The maximum frame size on the Gigabit Ethernet interfaces are (range: 1518 to 9216 Bytes): o Gigabit Ethernet Packets: 9216 Bytes o Untagged (without IEEE 802.1Q tags) Ethernet Packets: 1518 Bytes o Tagged (with IEEE 802.1Q tags) Ethernet Packets: 1522 Bytes

A host of other advanced layer-2/layer-3/layer-4 featuresetc.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 405 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VLANs
In a flat-bridged network, a broadcast domain is confined to a single LAN segment or even a specific physical location, such as a department or building floor. In a switch-based network, such as one comprised of Alcatel-Lucent switching systems, a broadcast domainor VLAN can span multiple physical switches and can include ports from a variety of media types. For example, a single VLAN could span three different switches located in different buildings and include 10/100 Ethernet, Gigabit Ethernet, 802.1q tagged ports and/or a link aggregate of ports.

VLAN Specifications
RFCs Supported 2674 - Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions 802.1Q - Virtual Bridged Local Area Networks 802.1D - Media Access Control Bridges 1024 (including the default VLAN#1) 32,768 1024 (single router MAC mode) 256 (single router MAC mode) 8 253 128 Single

IEEE Standards Supported Maximum VLANs per switch Maximum VLAN port associations per switch Maximum IP router port VLANs per switch Maximum IPX router port VLANs per switch Maximum IP router interfaces per VLAN Maximum Spanning Tree VLANs per switch Maximum authenticated VLANs per switch MAC Router Mode Supported

VLAN Defaults
Parameter Description VLAN identifier (VLAN ID) VLAN administrative state VLAN description VLAN Spanning Tree state VLAN mobile tag status VLAN IP router interfaces VLAN IPX router interface Switch MAC router mode VLAN authentication status VLAN port associations Default VLAN 1 predefined on each switch. Enabled VLAN identifier (VLAN ID) Enabled (Disabled if VLAN count exceeds 254) Disabled VLAN 1 router interface No router interface defined Single MAC router mode Disabled All ports initially associated with default VLAN 1.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 406 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VLAN Management Overview

One of the main benefits of using VLANs to segment network traffic, is that VLAN configuration and port assignment is handled through switch software. This eliminates the need to physically change a network device connection or location when adding or removing devices from the VLAN broadcast domain. The VLAN management software handles the following VLAN configuration tasks performed on an Alcatel-Lucent switch: Creating or modifying VLANs Assigning or changing default VLAN port associations (VPAs) Enabling or disabling VLAN participation in the current Spanning Tree algorithm Enabling or disabling classification of mobile port traffic by 802.1Q tagged VLAN ID Enabling or disabling VLAN authentication Defining VLAN IPX router interfaces to enable routing of VLAN IPX traffic Enabling or disabling unique MAC address assignments for each router VLAN defined Displaying VLAN configuration information In addition to the above tasks, VLAN management software tracks and reports the following information to other switch software features: VLAN configuration changes, such as adding or deleting VLANs, modifying the status of VLAN properties (e.g., administrative, Spanning Tree, and authentication status), changing the VLAN description, or configuring VLAN router ports. VLAN port associations triggered by VLAN management and other switch software applications, such as 802.1Q VLAN tagging and dynamic mobile port assignment. The VLAN operational state, which is inactive until at least one active switch port is associated with the VLAN.

Creating/Modifying VLANs
The initial configuration for all Alcatel-Lucent switches consists of a default VLAN 1 and all switch ports are initially assigned to this VLAN. When a switching module is added to the switch, the modules physical ports are also assigned to VLAN 1. If additional VLANs are not configured on the switch, then the entire switch is treated as one large broadcast domain. All ports will receive all traffic from all other ports. Up to 1024 VLANs are supported per switch, including default VLAN 1. In compliance with the IEEE 802.1Q standard, each VLAN is identified by a unique number, referred to as the VLAN ID. The user specifies a VLAN ID to create, modify or remove a VLAN and to assign switch ports to a VLAN. When a packet is received on a port, the ports VLAN ID is inserted into the packet. The packet is then bridged to other ports that are assigned to the same VLAN ID. In essence, the VLAN broadcast domain is defined by a collection of ports and packets assigned to its VLAN ID. The operational status of a VLAN remains inactive until at least one active switch port is assigned to the VLAN. This means that VLAN properties, such as Spanning Tree or router interfaces, also remain inactive. Ports are considered active if they are connected to an active network device. Non-active port assignments are allowed, but do not change the VLANs operational state. Ports are either statically or dynamically assigned to VLANs. When a port is assigned to a VLAN, a VLAN port association (VPA) is created and tracked by VLAN management switch software.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 407 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Enabling/Disabling Spanning Tree for a VLAN

When a VLAN is created, an 802.1D standard Spanning Tree Algorithm and Protocol (STP) instance is enabled for the VLAN by default. On the OmniSwitch 6800 and 6850 switches the 802.1w Rapid Spanning Tree Algorithm and Protocol (RSTP) is the default protocol enabled for a VLAN. The spanning tree operating mode set for the stack determines how VLAN ports are evaluated to identify redundant data paths. If the Spanning Tree switch-operating mode is set to flat, then VLAN port connections are checked against other VLAN port connections for redundant data paths. Note that the single flat mode STP instance is referred to as instance 1 or the CIST (Common and Internal Spanning Tree) instance, depending on which STP protocol is active. In the flat mode, if STP instance 1 or the CIST instance is disabled, then it is disabled for all configured VLANs. However, disabling STP on an individual VLAN will exclude only that VLANs ports from the flat STP algorithm. If the Spanning Tree operating mode is set to 1x1, there is a single Spanning Tree instance for each VLAN broadcast domain. Enabling or disabling STP on a VLAN in this mode will include or exclude the VLAN from the 1x1 STP algorithm. Note the following when using the vlan stp command. If the VLAN ID specified with this command is that of a VLAN that does not exist, the VLAN is automatically created. This command configures the VLAN STP status for both the 1x1 and flat Spanning Tree modes. Using the 1x1 or flat parameter with this command, configures the STP status only for the mode specified by the parameter. Up to 253 Spanning Tree instances per switch are supported in the 1x1 Spanning Tree mode. Since each VLAN with Spanning Tree enabled uses one of these instances, only 253 VLANs can have an active Spanning Tree instance at any given time. To create more than 253 VLANs on a switch running in the 1x1 Spanning Tree mode, use the vlan stp disable, vlan 1x1 stp disable, or vlan flat stp disable form of this command to create a VLAN with Spanning Tree disabled. STP does not become operationally active on a VLAN unless the VLAN is operationally active, which occurs when at least one active port is assigned to the VLAN. Also, STP is enabled/disabled on individual ports. So even if STP is enabled for the VLAN, a port assigned to that VLAN must also have STP enabled.

VLAN Authentication
Layer-2 authentication uses VLAN membership to grant access to network resources. Authenticated VLANs control membership through a login process; this is sometimes called user authentication. A VLAN must have authentication enabled before it can participate in the Layer 2 authentication process. Once authentication is enabled on a VLAN, then only authenticated mobile port devices can join the VLAN after completing the appropriate login process.

VLAN Router Interfaces

Network device traffic is bridged (switched) at the Layer 2 level between ports that are assigned to the same VLAN. However, if a device needs to communicate with another device that belongs to a different VLAN, then Layer 3 routing is necessary to transmit traffic between the VLANs. Bridging makes the decision on where to forward packets based on the packets destination MAC address; routing makes the decision on where to forward packets based on the packets IP or IPX network address (e.g., IP -21.0.0.10, IPX - 210A). Alcatel-Lucent switches support routing of IP and IPX traffic. A VLAN is available for routing when at least one router interface is defined for that VLAN and at least one active port is associated with the VLAN. Up to eight IP interfaces and one IPX interface can be configured for each VLAN. The maximum number of IP interfaces allowed for the entire switch is 1024. If a VLAN does not have a router interface, the ports associated with that VLAN are in essence firewalled from other VLANs. The number of VLANs that can have routing configured depends on the MAC router mode in the switch (single mode). If the switch is running in single MAC router mode, a maximum of 4094 VLANs can have IP interfaces defined and a maximum of 256 VLANs can have IPX interfaces defined.

Single MAC Router Mode

The OmniSwitch 6850 operates only in single MAC router mode. In this mode, each router port VLAN is assigned the same MAC address, which is the base chassis MAC address for the switch. As a result, up to 1024 IP router port VLANs are supported per single switch. This also eliminates the need to allocate additional MAC addresses if more than 32 router port VLANs are defined. To determine the total number of VLANs configured on the switch, and the number of VLANs with IP router ports defined, use the show vlan router mac status command. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 408 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Defining VLAN Port Assignments

Initially all switch ports are non-mobile (fixed) and are assigned to VLAN 1, which is also their configured default VLAN. When additional VLANs are created on the switch, ports are assigned to the VLANs so that traffic from devices connected to these ports is bridged within the VLAN domain. Switch ports are either statically or dynamically assigned to VLANs. Alcatel-Lucent switches support static and dynamic assignment of physical switch ports to a VLAN. Regardless of how a port is assigned to a VLAN, once the assignment occurs, a VLAN port association (VPA) is created and tracked by VLAN management software on each switch. Methods for statically assigning ports to VLANs include the following: Using the vlan port default command to define a new configured default VLAN for both non-mobile (fixed) and mobile ports. Using the vlan 802.1q command to define tagged VLANs for non-mobile ports. This method allows the switch to bridge traffic for multiple VLANs over one physical port connection. Configuring ports as members of a link aggregate that is assigned to a configured default VLAN. Dynamic assignment applies only to mobile ports. When traffic is received on a mobile port, the packets are classified using one of the following methods to automatically determine VLAN assignment: Packet is tagged with a VLAN ID that matches the ID of another VLAN that has mobile tagging enabled. Packet contents match criteria defined in a VLAN rule.

Port Assignment Specifications

IEEE Standards Supported Maximum VLANs per stand-alone Maximum VLAN port associations Switch Ports eligible for Port Mobility Switch ports eligible for dynamic VLAN assignment Switch Port eligible for static VLAN assignment 802.1Q - Virtual Bridged Local Area Networks 802.1D - Media Access Control Bridges 1024 (including the default VLAN#1) 32,768 Untagged 10/100 Ethernet and Gigabit ports that are not members of a link aggregate Mobile Ports Non-mobile (fixed) ports Mobile Ports Uplink Ports 10Gbps Ethernet Ports Link Aggregate of ports

Port Assignment Defaults

Parameters Description Configured default VLAN Port mobility Bridge mobile port traffic that doesnt match any VLAN rules on the configured default VLAN Drop mobile port dynamic VLAN assignments when learned mobile port traffic that triggered the assignment ages out Enable Layer 2 authentication on the mobile port Enable 802.1x port-based access control on a mobile port Default All ports initially associated with default VLAN 1. Disabled Disabled Enabled Disabled Disabled

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 409 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Statically Assigning Ports to VLANs

The vlan port default command is used to statically assign both mobile and non-mobile ports to another VLAN. When the assignment is made, the port drops the previous VLAN assignment. Additional methods for statically assigning ports to VLANs include the following: Using the vlan 802.1q command to define tagged VLANs for non-mobile ports. This method allows the switch to bridge traffic for multiple VLANs over one physical port connection. Configuring ports as members of a link aggregate that is assigned to a configured default VLAN. When a port is statically assigned to a VLAN, a VLAN port association (VPA) is created and tracked by VLAN management software on each switch.

Dynamically Assigning Ports to VLANs

Mobile ports are the only types of ports that are eligible for dynamic VLAN assignment. When traffic received on a mobile port matches pre-defined VLAN criteria, the port and the matching traffic are assigned to the VLAN without user intervention. By default, all switch ports are non-mobile (fixed) ports that are statically assigned to a specific VLAN and can only belong to one default VLAN at a time. The vlan port mobile command is used to enable mobility on a port. Once enabled, switch software classifies mobile port traffic to determine the appropriate VLAN assignment. Depending on the type of traffic classification used (VLAN rules or VLAN ID tag), mobile ports can also associate with more than one VLAN. VLANs do not have a mobile or non-mobile distinction and there is no overall switch setting to invoke the mobile port feature. Instead, mobility is enabled on individual switch ports and rules are defined for individual VLANs to classify mobile port traffic. When a port is dynamically assigned to a VLAN, a VLAN port association (VPA) is created and tracked by VLAN management software on each switch.

How Dynamic Port Assignment Works

Traffic received on mobile ports is classified using one of the following methods: Packet is tagged with a VLAN ID that matches the ID of another VLAN that has mobile tagging enabled. Packet contents match criteria defined in a VLAN rule. Classification triggers dynamic assignment of the mobile port and qualifying traffic to the VLAN with the matching criteria.

VLAN Mobile Tag Classification

VLAN mobile tag classification provides a dynamic 802.1Q tagging capability. This feature allows mobile ports to receive and process 802.1Q tagged packets destined for a VLAN that has mobile tagging enabled. Consider the following when using VLAN mobile tag classification: Using mobile tagging allows the dynamic assignment of mobile ports to one or more VLANs at the same time. If a mobile port receives a tagged packet with a VLAN ID of a VLAN that does not have mobile tagging enabled or the VLAN does not exist, the packet is dropped. VLAN mobile tag classification takes precedence over VLAN rule classification. If a mobile port receives traffic that matches a VLAN rule and also has an 802.1Q VLAN ID tag for a VLAN with mobile tagging enabled, the port is dynamically assigned to the mobile tag VLAN and not the matching rule VLAN. If the administrative status of a mobile tag VLAN is disabled, dynamic mobile port assignments are retained but traffic on these ports is filtered for the disabled VLAN. However, the VLAN mobile tag attribute remains active and continues to classify mobile port traffic for VLAN membership.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 410 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VLAN Rule Classification

VLAN rule classification triggers dynamic VLAN port assignment when traffic received on a mobile port matches the criteria defined in a VLAN rule. Different rule types are available for classifying different types of network device traffic Note the following items when using VLAN rule classification: IP network address rules are applied to traffic received on both mobile and fixed ports. If traffic contains a source IP address that is included in the subnet specified by the rule, the traffic is dropped. This does not occur, however, if the IP network address rule is configured on the default VLAN for the fixed port. If the contents of a mobile port frame matches the values specified in both an IP network address rule and a portprotocol binding rule, the IP network address rule takes precedence. However, if the content of such frame violates the port-protocol binding rule, the frame is dropped. When an active device is disconnected from a mobile port and connected to a fixed port, the source MAC address of that device is not learned on the fixed port until the MAC address has aged out and no longer appears on the mobile port. If a VLAN is administratively disabled, dynamic mobile port assignments are retained but traffic on these ports is filtered for the disabled VLAN. However, VLAN rules remain active and continue to classify mobile port traffic for VLAN membership. When a VLAN is deleted from the switch configuration, all rules defined for that VLAN are automatically removed and any static or dynamic port assignments are dropped.

Ignoring Bridge Protocol Data Units (BPDU)

By default, ports that send or receive Spanning Tree Bridge Protocol Data Units (BPDU) are not eligible for dynamic VLAN assignment. If the switch sees BPDU on a port, it does not attempt to classify the ports traffic. The vlan port mobile command, however, provides an optional BPDU ignore parameter. If this parameter is enabled when mobility is enabled on the port, the switch does not look for BPDU to determine if the port is eligible for dynamic assignment. When BPDU ignore is disabled and the mobile port receives a BPDU, mobility is shut off on the port and the following occurs: The Switch Logging feature is notified of the ports change in mobile status The port becomes a fixed (non-mobile) port that is associated only with its configured default VLAN. The port is included in the Spanning Tree algorithm. Mobility remains off on the port even if the ports link is disabled or disconnected. Rebooting the switch, however, will restore the ports original mobile status. When BPDU ignore is enabled and the mobile port receives a BPDU, the following occurs: The port retains its mobile status and remains eligible for dynamic VLAN assignment. The port is not included in the Spanning Tree algorithm. Note. Enabling BPDU ignore is not recommended. In specific cases where it is required, such as connecting legacy networks to mobile port networks, make sure that ignoring BPDU on a mobile port will not cause network loops to go undetected. Connectivity problems could also result if a mobile BPDU port dynamically moves out of its configured default VLAN where it provides traffic flow to/from the network. Enabling mobility on an active port that sends or receives BPDU (e.g. ports that connect two switches and Spanning Tree is enabled on both the ports and their assigned VLANs) is not allowed. If mobility is required on this type of port, enable mobility and the BPDU ignore parameter when the port is not active.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 411 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Understanding Mobile Port Properties

Dynamic assignment of mobile ports occurs without user intervention when mobile port traffic matches VLAN criteria. When ports are dynamically assigned, however, the following configurable mobile port properties affect how a port uses its configured default VLAN and how long it retains a VLAN port association (VPA): Mobile Port property If enabled If disabled Port traffic that does not match any VLAN Port traffic that does not match any VLAN Default VLAN rules configured on the switch is flooded on rules is discarded. the ports configured default VLAN. Port does not retain a dynamic VPA when the Port retains a dynamic VPA when the Restore default VLAN traffic that triggered the assignment ages out qualifying traffic ages out of the switch MAC of the switch MAC address table (forwarding address table. database).

What is a Configured Default VLAN?

Every switch port, mobile or non-mobile, has a configured default VLAN. Initially, this is VLAN 1 for all ports, but is configurable using the vlan port default command.

What is a Secondary VLAN?

All mobile ports start out with a configured default VLAN assignment. When mobile port traffic matches VLAN criteria, the port is assigned to that VLAN. Secondary VLANs are any VLAN a port is subsequently assigned to that is not the configured default VLAN for that port. A mobile port can obtain more than one secondary VLAN assignment under the following conditions: Mobile port receives untagged frames that contain information that matches rules on more than one VLAN. For example, if a mobile port receives IP and IPX frames and there is an IP protocol rule on VLAN 10 and an IPX protocol rule on VLAN 20, the mobile port is dynamically assigned to both VLANs. VLANs 10 and 20 become secondary VLAN assignments for the mobile port. Mobile port receives 802.1Q tagged frames that contain a VLAN ID that matches a VLAN that has VLAN mobile tagging enabled. For example, if a mobile port receives frames tagged for VLAN 10, 20 and 30 and these VLANs have mobile tagging enabled, the mobile port is dynamically assigned to all three VLANs. VLANs 10, 20, and 30 become secondary VLAN assignments for the mobile port. VLAN Management software on each switch tracks VPAs. When a mobile port link is disabled and then enabled, all secondary VLAN assignments for that port are automatically dropped and the ports original configured default VLAN assignment is restored. Switch ports are disabled when a device is disconnected from the port, a configuration change is made to disable the port, or switch power is turned off.

Mobile Port Properties

Mobile port properties indicate mobile port status and affect port behavior when the port is dynamically assigned to one or more VLANs. For example, mobile port properties determine the following: Should the configured default VLAN forward or discard port traffic that does not match any VLAN rule criteria. Should the port retain or drop a dynamic VPA when traffic that triggered the assignment stops and the source MAC address learned on the port for that VLAN is aged out. Will the mobile port participate in Layer 2 authentication that provides a login process at the VLAN and/or port level

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 412 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Defining VLAN Rules

VLAN rules are used to classify mobile port traffic for dynamic VLAN port assignment. Rules are defined by specifying a port, MAC address, protocol, network address, binding, or DHCP criteria to capture certain types of network device traffic. It is also possible to define multiple rules for the same VLAN. A mobile port is assigned to a VLAN if its traffic matches any one VLAN rule. There is an additional method for dynamically assigning mobile ports to VLANs that involves enabling VLAN mobile tagging. This method is similar to defining rules in that the feature is enabled on the VLAN that is going to receive the mobile port tagged traffic. The difference, however, is that tagged packets received on mobile ports are classified by their 802.1Q VLAN ID tag and not by whether or not their source MAC, network address, or protocol type matches VLAN rule criteria.

VLAN Rules Specifications

IEEE Standards Supported 802.1Q - Virtual Bridged Local Area Networks 802.1v VLAN Classification by Protocol and Port 802.1D - Media Access Control Bridges 1024 (including the default VLAN#1) Unlimited 8129 of each rule type, except for a DHCP generic rule because only one is allowed per switch. Mobile 10/100 Ethernet and Gigabit Ethernet ports Non-mobile (fixed) ports 10Gbps ports 802.1Q tagged fixed ports Link aggregated ports All VLAN management commands support prefix recognition.

Maximum VLANs Maximum number of rules per VLAN Maximum number of rules per switch Switch ports eligible for VLAN rule classification (dynamic VLAN assignment) Switch ports not eligible for VLAN rule classification

CLI Command Prefix Recognition

VLAN Rules Defaults

Parameter Description IP network address rule subnet mask IPX network address rule encapsulation Default The IP address class range; Class Am B, or C Ethernet-II

VLAN Rules Overview

The mobile port feature available on the switch allows dynamic VLAN port assignment based on VLAN rules that are applied to mobile port traffic. When a port is defined as a mobile port, switch software compares traffic coming in on that port with configured VLAN rules. If any of the mobile port traffic matches any of the VLAN rules, the port and the matching traffic become a member of that VLAN. VLANs do not have a mobile or non-mobile distinction and there is no overall switch setting to invoke the mobile port feature. Instead, mobility is enabled on individual switch ports and rules are defined for individual VLANs to capture mobile port traffic. It is possible to define multiple rules for one VLAN and rules for multiple VLANs. However, only IP and IPX protocol rules support the dynamic assignment of one mobile port to multiple VLANs. All other rule types classify a mobile port into one VLAN, even if the port receives traffic that matches other rules.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 413 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VLAN Rule Types

There are several types of configurable VLAN rules available for classifying different types of network device traffic. There is no limit to the number of rules allowed per VLAN and up to 8,129 of each rule type is allowed per switch. The type of rule defined determines the type of traffic that will trigger a dynamic port assignment to the VLAN and the type of traffic the VLAN will forward within its domain. Refer to the following sections (listed in the order of rule precedence) for a description of each type of VLAN rule: Rule Types DHCP o DHCP MAC, and DHCP MAC Range o DHCP Port o DHCP Generic Binding o MAC + IP+ Port o MAC + Port o Port + Protocol MAC o MAC address, and MAC Address Range Network address o IP, and IPX Protocol Port

DHCP Rules
Dynamic Host Configuration Protocol (DHCP) frames are sent from client workstations to request an IP address from a DHCP server. The server responds with the same type of frames, which contain an IP address for the client. If clients are connected to mobile ports, DHCP rules are used to classify this type of traffic for the purposes of transmitting and receiving DHCP frames to and from the server. When a mobile port receives a DHCP frame that matches a DHCP rule, the port is temporarily assigned to the VLAN long enough to forward the DHCP requests within the VLAN broadcast domain. The source MAC address of the DHCP frame, however, is not learned for that VLAN port association. As a result, the show mac-address-table command output will not contain an entry for the DHCP source MAC address. The show vlan port command output, however, will contain an entry for the temporary VLAN port association that occurs during this process. Once a device connected to a mobile port receives an IP address from the DHCP server, the VLAN port assignment triggered by the devices DHCP frames matching a VLAN DHCP rule is dropped unless regular port traffic matches another rule on that same VLAN. If this match occurs, or the traffic matches a rule on another VLAN, then the source MAC address of the mobile ports frames is learned for that VLAN port association. DHCP rules are most often used in combination with IP network address rules. A DHCP client has an IP address of all zeros (0.0.0.0) until it receives an IP address from a DHCP server, so initially it would not match any IP network address rules. Binding rules, MAC address rules, and protocol rules also capture DHCP client traffic. The exception to this is binding rules that specify an IP address as part of the rule, similar to IP network address rule definitions. The following DHCP rule types are available: DHCP MAC Address: DHCP MAC address rules capture DHCP frames that contain a source MAC address that matches the MAC address specified in the rule. DHCP MAC Range: A DHCP MAC range rule is similar to a DHCP MAC address rule, but allows the user to specify a range of MAC addresses. This is useful when it is necessary to define rules for a large number of sequential MAC addresses. One DHCP MAC range rule could serve the same purpose as 10 or 20 DHCP MAC address rules, requiring less work to configure. DHCP frames that contain a source MAC address that matches the low or high end MAC or that falls within the range specified by the low and high end MAC trigger dynamic port assignment to the rules VLAN. DHCP Port: DHCP port rules capture DHCP frames that are received on a mobile port that matches the port specified in the rule. DHCP Generic: DHCP generic rules capture all DHCP traffic that does not match an existing DHCP MAC or DHCP port rule. If none of these other rules exist, then all DHCP frames are captured regardless of the port they came in on or the frames source MAC address. Only one rule of this type is allowed per switch. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 414 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Binding Rules
Binding rules restrict VLAN assignment to specific devices by requiring that device traffic match all criteria specified in the rule. As a result, a separate binding rule is required for each device. An unlimited number of such rules, however, is allowed per VLAN and up to 8129 of each rule type is allowed per switch. Although DHCP traffic is examined and processed first by switch software, binding rules take precedence over all other rules. The following binding rule types are available. The rule type name indicates the criteria the rule uses to determine if device traffic qualifies for VLAN assignment. For example, the MAC-Port-IP address-binding rule requires a matching source MAC and IP address in frames received from a device connected to the port specified in the rule. Binding rules require mobile port traffic to match all rule criteria. The criteria consists of one of three combinations, each of which is a specific binding rule type: MAC-Port-IP Address: The device must attach to a specific switch port and use a specific MAC address and use a specific IP network address (MAC-port-IP address binding rule). MAC-Port: The device must use a specific port and a specific source MAC address (MAC-port binding rule). Port-Protocol: The device must attach to a specific switch port and use a specific protocol (port-protocol binding rule). Note that MAC-port-IP and, MAC-port binding rules are also supported on Authenticated VLANs (A-VLANs).

MAC Address & MAC Address Range Rules

MAC address rules determine VLAN assignment based on a devices source MAC address. This is the simplest type of rule and provides the maximum degree of control and security. Members of the VLAN will consist of devices with specific MAC addresses. In addition, once a device joins a MAC address rule VLAN, it is not eligible to join multiple VLANs even if device traffic matches other VLAN rules. MAC address rules also capture DHCP traffic, if no other DHCP rule exists that would classify the DHCP traffic into another VLAN. Therefore, it is not necessary to combine DHCP rules with MAC address rules for the same VLAN. MAC address rules capture frames that contain a source MAC address that matches the MAC address specified in the rule. The mobile port that receives the matching traffic is dynamically assigned to the rules VLAN. Using MAC address rules, however, limits dynamic port assignment to a single VLAN. A mobile port can only belong to one MAC address rule VLAN, even if it sends traffic that matches rules defined for other VLANs. For example, if VLAN 10 has a MAC address rule defined for 00:00:2a: 59:0c:f1 and VLAN 20 has an IP protocol rule defined, mobile port 4/2 sending IP traffic with a source MAC address of 00:00:2a: 59:0c:f1is only assigned to VLAN 10. All mobile port 4/2 traffic is forwarded on VLAN 10, even though its traffic also matches the VLAN 20 IP protocol rule. A MAC range rule is similar to a MAC address rule, but allows the user to specify a range of MAC addresses. This is useful when it is necessary to define rules for a large number of sequential MAC addresses. One MAC range rule could serve the same purpose as 10 or 20 MAC address rules, requiring less work to configure. Frames that contain a source MAC address that matches the low or high end MAC or that falls within the range specified by the low and high end MAC trigger dynamic port assignment to the rules VLAN. As is the case with MAC address rules, dynamic port assignment is limited to a single VLAN. A mobile port can only belong to one MAC range rule VLAN, even if it sends traffic that matches rules defined for other VLANs.

Network Address Rules

There are two types of network address rules: IP and IPX. An IP network address rule determines VLAN mobile port assignment based on a devices source IP address. An IPX network address rule determines VLAN mobile port assignment based on a devices IPX network and encapsulation. IP network address rules capture frames that contain a source IP subnet address that matches the IP subnet address specified in the rule. If DHCP is used to provide client workstations with an IP address, consider using one of the DHCP rules in combination with an IP network address rule. Note. IP network address rules are applied to traffic received on both mobile and fixed (non-mobile) ports. As a result, fixed port traffic that contains an IP address that is included in the IP subnet specified by the rule is dropped. However, if the IP network address rule VLAN is also the default VLAN for the fixed port, then the fixed port traffic is forwarded and not dropped. IPX network address rules capture frames that contain an IPX network address and encapsulation that matches the IPX network and encapsulation specified in the rule. This rule only applies to devices that already have an IPX network address assigned. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 415 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Protocol Rules
Protocol rules determine VLAN assignment based on the protocol a device uses to communicate. When defining this type of rule, there are several generic protocol values to select from: IP, IPX, AppleTalk, or DECNet. If none of these are sufficient, it is possible to specify an Ethernet type, Destination and Source Service Access Protocol (DSAP/SSAP) header values, or a Sub-network Access Protocol (SNAP) type. Note that specifying a SNAP protocol type restricts classification of mobile port traffic to the ethertype value found in the IEEE 802.2 SNAP LLC frame header. IP protocol rules also capture DHCP traffic, if no other DHCP rule exists that would classify the DHCP traffic into another VLAN. Therefore, it is not necessary to combine DHCP rules with IP protocol rules for the same VLAN. Protocol rules capture frames that contain a protocol type that matches the protocol value specified in the rule. There are several generic protocol parameter values to select from; IP Ethernet-II, IP SNAP, IPX Ethernet II, IPX Novell (802.3), IPX LLC (802.2), IPX SNAP, DECNet, and Appletalk. If none of these are sufficient to capture the desired type of traffic, use the Ethertype, DSAP/SSAP, or SNAP parameters to define a more specific protocol type value.

Port Rules
Port rules are fundamentally different from all other supported rule types, in that traffic is not required to trigger dynamic assignment of the mobile port to a VLAN. As soon as this type of rule is created, the specified port is assigned to the VLAN only for the purpose of forwarding broadcast types of VLAN traffic to a device connected to that same port. Port rules are mostly used for silent devices, such as printers, that require VLAN membership to receive traffic forwarded from the VLAN. These devices usually dont send traffic, so they do not trigger dynamic assignment of their mobile ports to a VLAN. It is also possible to specify the same port in more than one port rule defined for different VLANs. The advantage to this is that traffic from multiple VLANs is forwarded out the one mobile port to the silent device. For example, if port 3 on slot 2 is specified in a port rule defined for VLANs 255, 355, and 755, then outgoing traffic from all three of these VLANs is forwarded on port 2/3. Port rules only apply to outgoing mobile port traffic and do not classify incoming traffic. If a mobile port is specified in a port rule, its incoming traffic is still classified for VLAN assignment in the same manner as all other mobile port traffic. VLAN assignments that are defined using port rules are exempt from the ports default VLAN restore status. Port rules do not require mobile port traffic to trigger dynamic assignment. When this type of rule is defined, the specified mobile port is immediately assigned to the specified VLAN. As a result, port rules are often used for silent network devices, which do not trigger dynamic assignment because they do not send traffic. Port rules only apply to outgoing mobile port broadcast types of traffic and do not classify incoming traffic. In addition, multiple VLANs can have the same port rule defined. The advantage to this is that broadcast traffic from multiple VLANs is forwarded out one physical mobile port. When a mobile port is specified in a port rule, however, its incoming traffic is still classified for VLAN assignment in the same manner as all other mobile port traffic.

Understanding VLAN Rule Precedence

In addition to configurable VLAN rule types, there are two internal rule types for processing mobile port frames. One is referred to as frame type and is used to identify Dynamic Host Configuration Protocol (DHCP) frames. The second internal rule is referred to as default and identifies frames that do not match any VLAN rules. Note. Another type of mobile traffic classification, referred to as VLAN mobile tagging, takes precedence over all VLAN rules. If a mobile port receives an 802.1Q packet that contains a VLAN ID tag that matches a VLAN that has mobile tagging enabled, the port and its traffic are assigned to this VLAN, even if the traffic matches a rule defined on any other VLAN. The VLAN rule precedence table provides a list of all VLAN rules, including the two internal rules mentioned above, in the order of precedence that switch software applies to classify mobile port frames. The first column lists the rule type names, the second and third columns describe how the switch handles frames that match or dont match rule criteria. The higher the rule is in the list, the higher its level of precedence. When a frame is received on a mobile port, switch software starts with rule one in the rule precedence table and progresses down the list until there is a successful match between rule criteria and frame contents. The exception to this is if there is a binding rule violation. In this case, the frame is blocked and its source port is not assigned to the rules VLAN.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 416 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IEEE 802.1Q
802.1Q is the IEEE standard for segmenting networks into VLANs. Adding a specific tag to a packet performs 802.1Q segmentation.

802.1Q Specifications
IEEE Specification Draft Standard P802.1Q/D11 IEEE Standards for Local And Metropolitan Area Network: Virtual Bridged Local Area Networks, July 30, 1998 Maximum Number of Tagged VLANs per Port 4093 Maximum Number of Untagged VLANs per Port One untagged VLAN per port. Maximum Number of VLAN Port Associations 32768 Note. Up to 4093 VLANs can be assigned to a tagged port or link aggregation group. However, each assignment counts as a single VLAN port association. Once the maximum number of VLAN port associations is reached, no more VLANs can be assigned to ports.

802.1Q Defaults
Parameter Description What type of frames accepted Which tag is enforced Default Both tagged and untagged frames are accepted On (OmniSwitch 6850)

802.1Q Overview
Alcatel-Lucents 802.1Q is an IEEE standard for sending frames through the network tagged with VLAN identification. 802.1Q tagging can be configured and monitored on a single port in a switch or a link aggregation group in a switch. 802.1Q tagging is the IEEE version of VLANs. It is a method for segregating areas of a network into distinct VLANs. By attaching a label, or tag, to a packet, the packet can be identified as being from a specific area or identified as being destined for a specific area. When enabling a tagged port, you will also need to specify whether only 802.1Q tagged traffic is allowed on the port, or whether the port accepts both tagged and untagged traffic. Tagged refers to four bytes of reserved space in the header of the packet. The four bytes of tagging are broken down as follows: the first two bytes indicate whether the packet is an 802.1Q packet, and the next two bytes carry the VLAN identification (VID) and priority. On the ingress side, packets are classified in a VLAN. After classifying a packet, the switch adds an 802.1Q header to the packet. Egress processing of packets is done by the switch hardware. Packets have an 802.1Q tag, which may be stripped off based on 802.1Q tagging/stripping rules. If a port is configured to be a tagged port, then all the untagged traffic (including priority tagged, or VLAN 0 traffic) received on the port will be dropped. You do not need to reboot the switch after changing the configuration parameters. Note. Priority tagged traffic, or traffic from VLAN 0, is used for Quality of Service (QoS) functionality. 802.1Q views priority tagged traffic as untagged traffic. Mobile ports can be configured to accept 802.1Q traffic by enabling the VLAN mobile tagging feature. The port can be assigned to as many 802.1Q VLANs as necessary, up to 4093 per port or 32768 VLAN port associations. For the purposes of Quality of Service (QoS), 802.1Q ports are always considered to be trusted ports. Alcatel-Lucents 802.1Q tagging is done at wire speed, providing high-performance throughput of tagged frames. Note. 802.1Q on the OmniSwitch 6850 supports the force tag internal feature.

Forcing a Switch Internal Tag

If a tagged packet comes in on an untagged or mobile port (i.e., the vlan 802.1q command has not been used), then it can be classified in a VLAN other than the VLAN to which it currently belongs. If this classified VLAN (i.e., different than the packet tag) is now tagged on the egress side, then there are two possible options. One option is to carry the original tag of the packet. The other option is to replace the original tag with the classified VLAN. If force tag internal is on, then the tag is replaced with the classified VLAN. If force tag internal is off, then the tag is not replaced with the classified VLAN as the tag. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 417 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

GVRP
The GARP VLAN Registration Protocol (GVRP) facilitates in controlling virtual local area networks (VLANs) in a large network. It is an application of Generic Attribute Registration Protocol (GARP) and provides VLAN registration service. GVRP enables devices to dynamically learn their VLAN memberships. GVRP is compliant with 802.1Q standard. It dynamically learns and propagates VLAN membership information across a bridged network. GVRP dynamically maintains and updates the registration and de-registration of VLANs and prunes unnecessary broadcast and unicast traffic. Through the propagation of GVRP information, a device is continuously able to update its knowledge on the set of VLANs that currently have active nodes and on the ports through which those nodes can be reached. Note. GVRP is only supported in Release 6.2.1 for the OmniSwitch 6850 Series.

GVRP Specifications
The table below lists specifications for Alcatel-Lucents GVRP: IEEE Standards Supported IEEE Std. 802.1D - 2004, Media Access Control (MAC) Bridges IEEE Draft Std. P802.1Q-REV/D5.0 4094

Maximum GVRP VLANs

GVRP Defaults
Parameter Description Global status of GVRP Status of GVRP on specified port Transparent switching Maximum number of VLANs Registration mode of the port Applicant mode of the port Timer value for Join timer, Leave timer, or LeaveAll timer Restrict dynamic VLAN registration Restrict VLAN advertisement Restrict static VLAN registration Maximum VLANs learned through GVRP Default Disabled Disabled Disabled 1024 Normal Participant Join timer value: 200 ms Leave timer value: 600 ms LeaveAll timer value: 10000 ms not restricted not restricted not restricted 256

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 418 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

GARP Overview
GARP was introduced to avoid manual configuration of devices and applications in a large network. It enables dynamic configuration of devices and applications in a network. It also provides a generic framework whereby devices in a bridged LAN can register and de-register attribute values, such as VLAN identifiers, with each other. These attributes are propagated through devices in the bridged LAN. GARP consists of: GARP Information Declaration (GID)The part of GARP that generates data from the switch. GARP Information Propagation (GIP)The part of GARP that distributes data to different switches. A GARP applicant may or may not choose to actively participate in declaring and registering an attribute value. By declaring an attribute, a GARP applicant indicates to other applicants that it is either associated with the attribute or it is interested to know about the other applicants associated with that attribute. A GARP applicant that declares attributes is referred to as an active member. A passive member is an applicant interested in an attribute but will not initiate GARP PDUs when it is aware that other applicants have also registered the attribute. The following messages are used in GARP: JoinIn and JoinEmptyUsed by an applicant (including itself) associated with an attribute. Receiving JoinIn messages from other applicants or transmitting JoinEmpty messages enables an applicant to register the attribute. LeaveIn and LeaveEmptyUsed by an applicant to withdraw its declaration when it is no more associated with an attribute. LeaveAllUsed for periodic declarations and registration maintenance. An applicant periodically sends LeaveAll messages, which enable other applicants to indicate their attributes registered states. These messages indicate the current state of the sender applicant device to other GARP applicant devices. With this information, these GARP applicant devices can modify their behavior associated with the attribute (declare and withdraw). GVRP, an application of GARP, is designed to propagate VLAN information from device to device. With GVRP, a single switch is manually configured with all the desired VLANs for the network, and all the other switches on the network learn those VLANs dynamically. An end station can be plugged into a switch and be connected to its desired VLAN. However, end stations need GVRP-aware Network Interface Cards (NIC) to make use of GVRP. GVRP sends information encapsulated in an Ethernet frame to a specific MAC address (01:80:C2:00:00:21). Based on the received registration information (Join message of GARP), VLAN information is learned on a system. GVRP enables new dynamic VLANs on a device or dynamically registers a port to an existing VLAN. In effect, based on the received registration information of a VLAN, the port becomes associated with that VLAN. Similarly, whenever de-registration information is received for a VLAN (Leave message of GARP) on a particular port, the association of that VLAN with the port may get deleted. A GVRP-enabled port sends GVRP PDUs advertising the VLAN. Other GVRP-aware ports receiving advertisements over a link can dynamically join the advertised VLAN. All ports of a dynamic VLAN operate as tagged ports for that VLAN. Also, a GVRP-enabled port can forward an advertisement for a VLAN it learned about from other ports on the same switch. However, that forwarding port does not join that VLAN until an advertisement for that VLAN is received on that port.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 419 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The following illustration shows dynamic VLAN advertisements:

Switch A has 3 VLANs configured as static VLANs (10, 20, and 30). Other switches on the same network will learn these 3 VLANs as dynamic VLANs. Also, the end station connected on port 5 is statically configured for VLAN 50. Port 1 on Switch A is manually configured for VLANs 10, 20, and 30. Hence, as the diagram above shows, 1: Port 1 on Switch A advertises VLAN IDs (VIDs) 10, 20, and 30. 2: Port 2 on Switch B receives the advertisements. VLANs 10, 20, and 30 are created as dynamic VLANs on this switch and Port 2 becomes a member of VLANs 10, 20, and 30. 3: Port 3 on Switch B is triggered to advertise VLANs 10, 20, and 30, but does not become a member of these VLANs. 4: Port 4 on Switch C receives the advertisements. VLANs 10, 20, and 30 are created as dynamic VLANs on this switch and Port 4 becomes a member of VLANs 10, 20, and 30. 5: Port 5 advertises VLANs 10, 20, and 30, but this port is not a member of these VLANs. Note. Default VLAN (VLAN 1) exists on all switches, but it is not considered here. The above sequence of advertisements and registration of VLANs results in the following configuration:

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 420 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Here, the end station advertises itself as a member of VLAN 50. As the above diagram shows, 1: Port 5 receives the advertisement and Switch C creates VLAN 50 as a dynamic VLAN. Port 5 of Switch C becomes a member of VLAN 50. 2: Port 4 advertises VLAN 50, but is not a member of VLAN 50. 3: Port 3 of Switch B receives the advertisement, Switch B creates the dynamic VLAN 50, and Port 3 becomes a member of VLAN 50. 4: Port 2 advertises VLAN 50, but is not a member of this VLAN. 5: Port 1 on Switch A receives the advertisement, creates dynamic VLAN 50. Port 1 becomes a member of VLAN 50. The resulting configuration is depicted below:

Note. Every port on a switch is not a member of all the VLANs. Only those ports that receive the advertisement become members of the VLAN being advertised.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 421 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VLAN Stacking
VLAN Stacking provides a mechanism to tunnel multiple customer VLANs (CVLAN) through a service provider network using one or more service provider VLANs (SVLAN) by way of 802.1Q double-tagging or VLAN Translation. This feature enables service providers to offer their customers Transparent LAN Services (TLS). This service is multipoint in nature so as to support multiple customer sites or networks distributed over the edges of a service provider network. The VLAN Stacking application operates in one of two modes: legacy and service. The two modes basically differ in how VLAN Stacking is configured, with the service mode offering the following additional enhancements that are not available in the legacy mode: Ethernet service-based approach that is similar to configuring a virtual private LAN service (VPLS). Ingress bandwidth sharing across User Network Interface (UNI) ports. Ingress bandwidth rate limiting on a per UNI port, per CVLAN, or CVLAN per UNI port basis. CVLAN (inner) tag 802.1p-bit mapping to SVLAN (outer) tag 802.1p bit. CVLAN (inner) tag DSCP mapping to SVLAN (outer) tag 802.1p bit. Profiles for saving and applying traffic engineering parameter values. Configuring VLAN Stacking in the legacy mode consists of using a port or port-VLAN level approach to tunneling customer traffic. Configuring VLAN Stacking in the service mode consists of using an approach based on defining an Ethernet service to tunnel customer traffic. Both modes are exclusive in that the switch can only operate in one mode or the other. In addition, each mode has its own unique CLI command syntax. Throughout this section, the term port-based VLAN Stacking refers to functionality available in the legacy mode and the term service-based VLAN Stacking refers to functionality available in the service mode. Note. You can also configure and monitor VLAN Stacking with WebView; Alcatel.Lucents embedded web based device management application. WebView is an interactive and easy-to-use GUI that can be launched from OmniVista or a web browser.

VLAN Stacking Specifications

The table below lists specifications for Alcatel.Lucents VLAN Stacking software IEEE Standards Supported IEEE 802.1Q, 2003 Edition, IEEE Standards for Local and metropolitan area networksVirtual Bridged Local Area Networks P802.1ad/D6.0 (C/LM) Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 4: Provider Bridges Port level VLAN Stacking: 4093 (VLAN 2 through 4094) port/VLAN level VLAN Stacking: 768 (VLAN 2 through 4094 inclusive) 4093 (VLAN 2 through 4094) Group Mobility, Authentication and L3 Routing

Maximum number of SVLANs for port-based VLAN Stacking

Maximum number of SVLANs for service-based VLAN Stacking Features not supported on VLAN Stacking ports

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 422 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Service-Based VLAN Stacking Defaults

Parameter Description VLAN Stacking mode SVLAN administrative and Spanning Tree status. IPMVLAN administrative and Spanning Tree status. Vendor TPID and legacy BPDU support for STP or GVRP on a VLAN Stacking network port. Acceptable frame types on a VLAN Stacking user port. Traffic engineering profile attributes for a VLAN Stacking Service Access Point (SAP). Default legacy VLAN Stacking (vstk) Enabled Enabled TPID = 0x8100 Legacy STP BPDU = dropped. Legacy GVRP BPDU = dropped. None ingress bandwidth = shared ingress bandwidth bps = 0 CVLAN tag is preserved. SVLAN priority mapping = 0 STP frames are tunneled. GVRP frames are tunneled.

Treatment of customer STP and GVRP frames ingressing on a VLAN Stacking user port.

Port-Based VLAN Stacking Defaults

Parameter Description VLAN Stacking mode Carries customer or provider traffic SVLAN administrative Status Internal prioritization value and egress shaping for the SVLAN Vlan Stacking port type Vendor TPID for VLAN Stacking network port Treatment of customer STP and GVRP frames ingressing on VLAN Stacking user-customer and user-provider ports Acceptable frame types on user-customer and userprovider ports Treatment of tagged packets upon an SVLAN lookup miss Legacy BPDU support for STP or GVRP on VLAN Stacking network ports Binding mode of VLAN Stacking port to an SVLAN Default legacy VLAN Stacking (vstk) Customer Traffic Enabled 0 User-customer-port 0x88a8 Flooded Tagged and untagged Drop Disabled Double-tag

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 423 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VLAN Stacking Overview

VLAN Stacking provides a mechanism for defining a transparent bridging configuration through a service provider network. This type of configuration is achieved using one of two methods: service-based VLAN Stacking or port-based VLAN Stacking. The service-based approach provides the ability to configure Ethernet services to provide VLAN Stacking functionality. The port-based approach requires configuring VLAN Stacking functionality on a port level or port-VLAN level. See VLAN Stacking Modes on page 7-8 for more information. The major components of VLAN Stacking that provide this type of functionality are described as follows: Provider Edge (PE) BridgeAn Ethernet switch that resides on the edge of the service provider network. The PE Bridge interconnects customer network space with service provider network space. A switch is considered a PE bridge if it transports packets between a customer-facing port and a network port or between two customer-facing ports. Transit BridgeAn Ethernet switch that resides inside the service provider network and provides a connection between multiple provider networks. It employs the same SVLAN on two or more network ports. This SVLAN does not terminate on the switch itself; traffic ingressing on a network port is switched to other network ports. It is also possible for the same switch to function as a both a PE Bridge and a Transit Bridge. Tunnel (SVLAN)A tunnel, also referred to as an SVLAN, is a logical entity that connects customer networks by transparently bridging customer traffic through a service provider network. The tunnel is defined by an SVLAN tag that is appended to all customer traffic. This implementation provides the following three types of SVLANs, which are both defined by the type of traffic that they carry: an SVLAN that carries customer traffic an SVLAN that carries provider management traffic an IP Multicast VLAN (IPMVLAN) that distributes multicast traffic Note that port-based VLAN Stacking does not support two or more customers sharing the same tunnel Network Network Interface (NNI)An NNI is a port that resides on either a PE Bridge or a Transit Bridge and connects to a service provider network. Traffic ingressing on a network port is considered SVLAN traffic and is switched to a customer-facing port or to another network port. User Network Interface (UNI)A UNI is a port that resides on a PE bridge that connects to a customer network and carries customer traffic. The UNI may consist of a single port or an aggregate of ports and can accept tagged or untagged traffic. Note that port-based VLAN Stacking provides two types of UNI ports: user-customer port and user-provider port. A user-customer port connects to a customer network and carries customer traffic; a user-provider port carries provider management traffic. The following illustration shows how VLAN Stacking uses the above components to tunnel customer traffic through a service provider network:

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 424 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 425 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

How VLAN Stacking Works

On the Provider Edge Bridge (PE), a unique tunnel (SVLAN) ID is assigned to each customer. The tunnel ID corresponds to a VLAN ID, which is created on the switch when the tunnel is configured. For example, when tunnel 100 is created, VLAN Stacking software interacts with VLAN Manager Software to configure a VLAN 100 on the switch. VLAN 100 is the provider bridge VLAN that will tunnel customer VLAN traffic associated with tunnel 100. So, there is a one to one correspondence between a tunnel and its provider bridge VLAN ID. In fact, tunnel and VLAN are interchangeable terms when referring to the provider bridge configuration. VLAN Stacking refers to the tunnel encapsulation process of appending to customer packets an 802.1Q tag that contains the tunnel ID associated to that customers provider bridge port and/or VLANs. The encapsulated traffic is then transmitted through the Ethernet metro area network (EMAN) cloud and received on another PE bridge that contains the same tunnel ID, where the packet is then stripped of the tunnel tag and forwarded to the traffic destination. The following provides an example of how a packet ingressing on a VLAN Stacking UNI port that is tagged with the customer VLAN (CVLAN) ID transitions through the VLAN Stacking encapsulation process:

VLAN Stacking Modes

The VLAN Stacking application operates in one of two modes: legacy and service. Both modes are exclusive in that the switch can only operate in one mode or the other. In addition, each mode has its own unique CLI command syntax. Note. Changing the VLAN Stacking mode is not allowed if there is an existing VLAN Stacking or IP Multicast VLAN configuration on the switch. Remove any existing configuration of these two features before attempting to change the mode.

Service Mode
Configuring VLAN Stacking in the service mode consists of using an Ethernet service based approach for tunneling customer traffic through a provider network. Service-based VLAN Stacking involves configuring the following components to define a tunneling service: VLAN Stacking Servicea service name that is associated with an SVLAN, NNI ports, and one or more VLAN Stacking service access points. The service identifies the customer traffic that the SVLAN will carry through the provider traffic. Service Access Point (SAP)A SAP is associated with a VLAN Stacking service name and a SAP profile. The SAP binds UNI ports and customer traffic received on those ports to the service. The profile specifies traffic engineering attribute values that are applied to the customer traffic received on the SAP UNI ports. Service Access Point (SAP) ProfileA SAP profile is associated with a SAP ID. Profile attributes define values for ingress bandwidth sharing, rate limiting, CVLAN tag processing (translate or preserve), and priority mapping (inner to outer tag or fixed value). UNI Port Profile this type of profile is associated with each UNI port and configures how Spanning Tree and GVRP control packets are processed on the UNI port. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 426 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Legacy Mode
Configuring VLAN Stacking in the legacy mode consists of using a port-based approach for tunneling customer traffic through a provider network. Port-based VLAN Stacking provides the following two methods for defining a VLAN Stacking configuration. Port level configurationAll traffic ingressing on a user port is assigned an SVLAN reserved for that port. Customer traffic (customer VLAN) is not used to classify which SVLAN to be assigned to the traffic. There is one and only one SVLAN per user port. Several user ports belonging to a customer may share an SVLAN. Port-VLAN level configurationAll traffic ingressing on a user port is assigned an SVLAN based on both the user port and the customer VLAN. Each customer VLAN may be assigned a unique SVLAN. Note that port-VLAN level is a super set of port level VLAN Stacking. Port level is basically portVLAN level with all customer VLANs associated to a single SVLAN.

Interaction With Other Features

This section contains important information about VLAN Stacking interaction with other OmniSwitch features. Refer to the specific chapter for each feature to get more detailed information about how to configure and use the feature.

GARP VLAN Registration Protocol (GVRP)

GVRP control frames are tunneled by default; processing of GVRP frames similar to processing of Spanning Tree frames . The VLAN Stacking provider edge (PE) switch will not tunnel GVRP frames unless the GVRP feature and/or GVRP transparent switching functionality is enabled on the PE switch. This is true even if GVRP processing is enabled for the VLAN Stacking port.

IP Multicast VLANs
The IP Multicast VLANs (IPMV) application has the following interactions with service-based VLAN Stacking functionality and commands: Changing between VLAN Stacking legacy and VLAN Stacking service modes requires removal of any IPMV configuration before the mode is changed. IPMV operates in one of two modes: enterprise or VLAN Stacking. When the enterprise mode is active, IPMV uses sender and receiver ports for IP multicast traffic. When the IPMV VLAN Stacking mode is active, IPMV maps sender and receiver ports to VLAN Stacking NNI and UNI ports. If IPMV is operating in the enterprise mode, there are no CLI usage changes. If IPMV is operating in the VLAN Stacking mode, the following VLAN Stacking CLI commands are used to configure interoperability with IPMV depending on which VLAN Stacking mode is active (legacy or service):

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 427 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Link Aggregation
Both static and dynamic link aggregation are supported with service-based and port-based VLAN Stacking. The exception to this is that port-VLAN level VLAN Stacking on a static link aggregate of UNI ports is not supported. Note that in both VLAN Stacking modes, a link aggregate must consist of all UNI or all NNI ports. VLAN Stacking functionality is not supported on link aggregates that consist of a mixture of VLAN Stacking ports and conventional switch ports.

Quality of Service (QoS)

The QoS application has the following interactions with service-based VLAN Stacking: QoS allocates switch resources for VLAN Stacking Service attributes, even though such attributes are not configurable via the QoS CLI. VLAN Stacking ports are trusted and use 802.1p classification by default. If there is a conflict between VLAN Stacking Service attributes and the QoS configuration, the VLAN Stacking attributes are given precedence over QoS policies. Quarantine Manager and Remediation (QMR) is not available if VLAN Stacking services or QoS VLAN Stacking inner VLAN and 802.1p policies are configured on the switch.

Ring Rapid Spanning Tree Protocol (RRSTP)

RRSTP is only supported on VLAN Stacking NNI ports; UNI ports are not supported. An RRSTP ring must consist of either all VLAN Stacking NNI ports or all standard switch ports; a mixture of the two port types in the same ring is not supported. If an RRSTP ring contains NNI ports, the VLAN tag configured for the ring must match the SVLAN tag that VLAN Stacking appends to packets before they are received or forwarded on NNI ports.

Spanning Tree
Spanning Tree is enabled by default for VLAN Stacking SVLANs. The Spanning Tree status for an SVLAN is configurable in both the service-based and port-based VLAN Stacking modes. Note that the SVLAN Spanning Tree status applies only to the service provider network topology. BPDU frames are tunneled by default. A back door link configuration is not supported. This occurs when there is a link between two customer sites that are both connected to a VLAN Stacking provider edge switch. A dual home configuration is not supported. This type of configuration consists of a single customer site connected to two different VLAN Stacking switches or two switches at a customer site connect to two different VLAN Stacking switches.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 428 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VLAN Stacking Application Examples

The VLAN Stacking feature provides the ability to transparently connect multiple customer sites over a single shared service provider network. This section demonstrates this ability by providing a sample VLAN Stacking configuration that tunnels customer VLANs (CVLAN) inside a service provider VLAN (SVLAN} so that customer traffic is transparently bridged through a Metropolitan Area Network (MAN). The illustration below shows the sample VLAN Stacking configuration described in this section. In this configuration, the provider edge bridges will encapsulate Customer A traffic (all CVLANs) into SVLAN 100 and Customer B traffic (CVLAN 10 only) into SVLAN 200. In addition, the CVLAN 10 inner tag priority bit value is mapped to the SVLAN out tag priority value. The customer traffic is then transparently bridged across the MAN network and sent out to the destined customer site. Double-tagging is the encapsulation method used in this application example, This method consists of appending the SVLAN tag to customer packets ingressing on provider edge UNI ports so that the traffic is bridged though the provider network SVLAN. The SVLAN tag is then stripped off of customer packets egressing on provider edge UNI ports before the packets are delivered to their destination customer site. Tutorials are also included in this section to show how to configure this application example using service-based VLAN Stacking.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 429 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Ethernet OAM
The rise in the number of Ethernet service instances has resulted in service providers requiring a powerful and robust set of management tools to maintain Ethernet service networks. Service provider networks are large and intricate, often comprising of different operators that work together to provide the customers with end-to-end services. The challenge for the service providers is to provide a highly available convergent network to its customer base. Ethernet OAM (Operations, Administration, and Maintenance) provides the detection, resiliency, and monitoring capability for end-to-end service guarantee in an Ethernet network.

Ethernet OAM Specifications

The following table shows Ethernet OAM specifications. Ethernet OAM IEEE Standards Supported IEEE 802.1agConnectivity Fault Management IEEE 802.3ahCSMA/CD Access Method and Physical Layer Specifications Note: IEEE 802.3ah will be supported in a Future Release. IEEE 802.1DMedia Access Control (MAC) Bridges IEEE 802.1QVirtual Bridged Local Area Networks 8 128 25

Maximum Maintenance Domains (MD) per Bridge Maximum Maintenance Associations (MA) per Bridge Maximum Maintenance End Points (MEP) per Bridge

Ethernet OAM Defaults

The following table shows Ethernet OAM default values. Parameter Description Continuity Check Message interval MHF value assigned to a default Ethernet OAM Maintenance Domain The priority value for CCMs and LTMs transmitted by the MEP Number of Loopback messages to be transmitted Data Type Length Value VLAN priority Whether or not Drop Enable bit is configured (true or false) Hop count Default intervalnone None 7 1 64 0 True 64

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 430 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Ethernet OAM Overview

Ethernet OAM provides service assurance over a converged Ethernet network. It helps service providers to manage network operations efficiently and smoothly. Ethernet OAM provides effective monitoring capabilities by increasing visibility in the network. It detects failure and degradation by raising warnings and alarms; also provides diagnostic and troubleshooting tools to resolve problems. Ethernet OAM focuses on two main protocols that the service providers require the most and are rapidly evolving in the standards bodies: Service OAM and Link OAM. These OAM protocols are unique and complementary to each other. Service OAMfor monitoring and troubleshooting end-to-end Ethernet service instances Link OAMfor monitoring and troubleshooting an individual Ethernet link Ethernet OAM is not supported on mobile, mirrored, and aggregable ports (the physical port members of an aggregate). It is also not supported on dynamically learned VLANs. But, it can be implemented on any full-duplex point-to-point or emulated point-to-point Ethernet link. It need not be implemented systemwide. Management systems are important for configuring Ethernet OAM across the network. They also help to automate network monitoring and troubleshooting. Ethernet OAM can be configured in two phases, Network Configuration phase and Service Activation phase. The Network Configuration phase enables Connectivity Fault Management (CFM) on the switches. CFM allows service providers to manage customer service instances individually. This phase also helps set up the Maintenance Intermediate Points (MIP) and Maintenance End Points (MEP). Any port of a bridge is referred to as a Maintenance Point (MP). An MP can be either a MEP or MIP. A MEP resides at the edge of a Maintenance Domain (MD), while a MIP is located within a Maintenance Domain. A Maintenance Domain is an administrative domain for managing and administering a network. In the Service Activation phase, a new end point created on a VLAN needs to be configured as a MEP. This enables the configuration of continuity-check and cross-check functionalities.

Connectivity Fault Management

Connectivity Fault Management (CFM) permits service providers to manage customer service instances individually. A customer service instance or Ethernet Virtual Connection (EVC) is the service that is sold to a customer and is designated by a VLAN tag on the User-to-Network Interface (UNI). CFM consists of hierarchical Maintenance Domains (MD). Each MD comprises of MEPs and MIPs. The network administrator segregates these maintenance points. MDs provide different management scopes for different organizations. Different organizations are involved in a Metro Ethernet Service, such as Customers, Service Providers, and Operators. Customers avail Ethernet service from service providers. Service providers may use their own networks, or other operators networks to provide the Ethernet connectivity for the requested service. Each organization can have its own Maintenance Domain.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 431 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

CFM Monitoring Domains Ethernet OAM Connectivity Fault Management consists of four types of messages that help in monitoring and debugging Ethernet networks. These messages are described below: Continuity Check Messages (CCMs)these are multicast messages exchanged periodically between MEPs. They allow MEPs to detect loss of service connectivity amongst themselves and discover other MEPs within a domain. These messages also enable MIPs to discover MEPs. Linktrace Messages LTMs) these messages are transmitted by a MEP to trace the path to a destination MEP. They are requested by an administrator. Loopback Messages (LBMs) these messages are transmitted by a MEP to a specified MIP or MEP. They are requested by an administrator. Alarm Indication Signal (AIS) Messages these messages send alerts to other devices in the network to notify a fault in the network. Note. AIS messages are not supported in this release. MIP CCM Database Support Per section 19.4 of the IEEE 802.1ag 7.0 draft standard, an MHF may optionally maintain a MIP CCM database as it is not required for conformance to this standard. A MIP CCM database, if present, maintains the information received from the MEPs in the MD and can be used by the Linktrace Protocol. This implementation of Ethernet OAM does not support the optional MIP CCM database. As per section 19.4.4 of the IEEE 802.1ag 7.0 draft standard, LTM is forwarded on the basis of the source learning filtering database. Because the MIP CCM database is not supported in this release, MIPs will not forward LTM on blocked egress ports.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 432 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Internet Protocol (IP)

Internet Protocol (IP) is primarily a network-layer (Layer 3) protocol that contains addressing and control information that enables packets to be forwarded. Along with Transmission Control Protocol (TCP), IP represents the heart of the Internet protocols. IP has two primary responsibilities: providing connection-less, best-effort delivery of Datagrams through an Internetwork; and providing fragmentation and reassembly of Datagrams to support data links with different Maximum Transmission Unit (MTU) sizes. Note. IP routing (Layer 3) can be accomplished by using static routes or by using one of the IP routing protocols such as Routing Information Protocol (RIP), or Open Shortest Path First (OSPF). There are two versions of Internet Protocol supported, IPv4 and IPv6.

IP Specifications
RFCs Supported RFC 791Internet Protocol RFC 792Internet Control Message Protocol RFC 826An Ethernet Address Resolution Protocol 2784Generic Routing Encapsulation (GRE) 2890Key and Sequence Number Extensions to GRE (extensions defined are not supported) 1701Generic Routing Encapsulation (GRE) 1702Generic Routing Encapsulation over IPV4 Networks 2003-IP Encapsulation within IP. 4094 (including default VLAN 1) 4094 IP and 256 IPX (single MAC router mode) 8 8 4096 127 RIP, OSPF, and BGP 200

Maximum VLANs per switch Maximum router VLANs per switch Maximum IP interfaces per VLAN Maximum number of GRE tunnel interfaces Maximum IP interfaces per switch Maximum number of IPIP tunnel interfaces Routing protocols supported over the tunnel interfaces Maximum ARP filters per switch

IP Defaults
Description IP-Directed Broadcasts Time-to-Live Value IP interfaces ARP filters Default Off 64 Hops VLAN 1 interface 0

IP Overview
IP is a network-layer (Layer 3) protocol that contains addressing and control information that enables packets to be forwarded on a network. IP is the primary network-layer protocol in the Internet protocol suite. Along with TCP, IP represents the heart of the Internet protocols. IP is enabled on the switch by default and there are few options that can, or need to be, configured.

IP Protocols
IP is associated with several Layer 3 and Layer 4 protocols. These protocols are built into the base code loaded on the switch. A brief overview of supported IP protocols is included below.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 433 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Transport Protocols
IP is both connectionless (it forwards each datagram separately) and unreliable (it does not guarantee delivery of Datagrams). This means that a datagram may be damaged in transit, or thrown away by a busy switch, or simply never make it to its destination. The resolution of these transit problems is to use a Layer 4 transport protocol, such as: TCPA major data transport mechanism that provides reliable, connection-oriented, full-duplex data streams. While the role of TCP is to add reliability to IP, TCP relies upon IP to do the actual delivering of Datagrams. UDPA secondary transport-layer protocol that uses IP for delivery. UDP is not connection-oriented and does not provide reliable end-to-end delivery of Datagrams. But some applications can safely use UDP to send Datagrams that do not require the extra overhead added by TCP.

Application-Layer Protocols
Application-layer protocols are used for switch configuration and management: Bootstrap Protocol (BOOTP)/Dynamic Host Configuration Protocol (DHCP)May be used by an end station to obtain an IP address. The switch provides a DHCP Relay that allows BOOTP requests/replies to cross-different networks. Simple Network Management Protocol (SNMP)Allows communication between SNMP managers and SNMP agents on an IP network. Network administrators use SNMP to monitor network performance and manage network resources. TelnetUsed for remote connections to a device. You can telnet to a switch and configure the switch and the network using the CLI. File Transfer Protocol (FTP)Enables the transfer of files between hosts. This protocol is used to load new images onto the switch.

Additional IP Protocols
There are several additional IP-related protocols that may be used with IP forwarding. These protocols are included as part of the base code. Address Resolution Protocol (ARP)Used to match the IP address of a device with its physical (MAC) address. Virtual Router Redundancy Protocol (VRRP)Used to back up routers. Internet Control Message Protocol (ICMP)Specifies the generation of error messages, test packets, and informational messages related to IP. ICMP supports the ping command used to determine if hosts are online. Router Discovery Protocol (RDP)Used to advertise and discover routers on the LAN. Multicast ServicesIncludes IP multicast switching (IPMS)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 434 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IP Forwarding
Network device traffic is bridged (switched) at the Layer 2 level between ports that are assigned to the same VLAN. However, if a device needs to communicate with another device that belongs to a different VLAN, then Layer 3 routing is necessary to transmit traffic between the VLANs. Bridging makes the decision on where to forward packets based on the packets destination MAC address; routing makes the decision on where to forward packets based on the packets IP network address (e.g., IP - 21.0.0.10). Alcatel-Lucent switches support routing of IP traffic. A VLAN is available for routing when at least one router interface is defined for that VLAN and at least one active port is associated with the VLAN. If a VLAN does not have a router interface, the ports associated with that VLAN are in essence firewalled from other VLANs. IP Multinetting is also supported. A network is said to be multinetted when multiple IP subnets are brought together within a single broadcast domain. It is now possible to configure up to eight IP interfaces per VLAN and a maximum of 4096 interfaces per switch. Each interface is configured with a different subnet. As a result, traffic from each configured subnet can coexist on the same VLAN. In the illustration below, an IP router interface has been configured on each VLAN. Therefore, workstations connected to ports on VLAN 1 on Switch 1 can communicate with VLAN 2; and workstations connected to ports on VLAN 3 on Switch 2 can communicate with VLAN 2. Also, ports from both switches have been assigned to VLAN 2, and a physical connection has been made between the switches. Therefore, workstations connected to VLAN 1 on Switch 1 can communicate with workstations connected to VLAN 3 on Switch 2.

If the switch is running in single MAC router mode, a maximum of 4094 VLANs can have IP interfaces defined and a maximum of 256 VLANs can have IPX interfaces defined. In this mode, each router VLAN is assigned the same MAC address, which is the base chassis MAC address for the switch.

Static Route
Static routes are user-defined routes that allow you to define, or customize, an explicit path to an IP network segment, which is then added to the IP Forwarding table. Static routes can be created between VLANs to enable devices on these VLANs to communicate. When you create a static route, the default metric value of 1 is used. However, you can change the priority of the route by increasing its metric value. The lower the metric value, the higher the priority. This metric is added to the metric cost of the route. The metric range is 1 to 15. Static routes do not age out of the IP Forwarding table; you must delete them from the table. Note. A static route is not active unless the gateway it is using is active.

Default Route
A default route can be configured for packets destined for networks that are unknown to the switch. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 435 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Address Resolution Protocol (ARP)

To send packets on a locally connected network, the switch uses ARP to match the IP address of a device with its physical (MAC) address. To send a data packet to a device with which it has not previously communicated, the switch first broadcasts an ARP request packet. The ARP request packet requests the Ethernet hardware address corresponding to an Internet address. All hosts on the receiving Ethernet receive the ARP request, but only the host with the specified IP address responds. If present and functioning, the host with the specified IP address responds with an ARP reply packet containing its hardware address. The switch receives the ARP reply packet, stores the hardware address in its ARP cache for future use, and begins exchanging packets with the receiving device. The switch stores the hardware address in its ARP cache (ARP table). The table contains a listing of IP addresses and their corresponding translations to MAC addresses. Entries in the table are used to translate 32-bit IP addresses into 48-bit Ethernet or IEEE 802.3 hardware addresses. Dynamic addresses remain in the table until they time out. You can set this timeout value and you can also manually add or delete permanent addresses to/from the table. As described above, dynamic entries remain in the ARP table for a specified time period before they are automatically removed. However, you can create a permanent entry in the table. Alias. Use the alias keyword to specify that the switch will act as an alias (proxy) for this IP address. When the alias option is used, the switch responds to all ARP requests for the specified IP address with its own MAC address. Note that this option is not related to Proxy ARP as defined in RFC 925. Permanent entries do not age out of the ARP table. Note. Dynamic entries remain in the ARP table until they time out. If the switch does not receive data from a host for this user-specified time, the entry is removed from the table. If another packet is received from this host, the switch goes through the discovery process again to add the entry to the table. The switch uses the MAC Address table timeout value as the ARP timeout value.

The Time-to-Live (TTL) Value

The TTL value is the default value inserted into the TTL field of the IP header of Datagrams originating from the switch whenever a TTL value is not supplied by the transport layer protocol. The value is measured in hops. The default hop count is 64. The valid range is 1 to 255.

Local Proxy ARP

The Local Proxy ARP feature is an extension of the Proxy ARP feature, but is enabled on an IP interface and applies to the VLAN bound to that interface. When Local Proxy ARP is enabled, all ARP requests received on VLAN member ports are answered with the MAC address of the IP interface that has Local Proxy ARP enabled. In essence, all VLAN traffic is now routed within the VLAN instead of bridged and all ARP requests are blocked between ports in the same VLAN. This feature is intended for use with port mapping applications where VLANs are one-port connections. This allows hosts on the port-mapping device to communicate via the router. ARP packets are still bridged across multiple ports. Note that Local Proxy ARP takes precedence over any switch-wide Proxy ARP or ARP function. In addition, it is not necessary to configure Proxy ARP in order to use Local Proxy ARP. The two features are independent of each other. By default, Local Proxy ARP is disabled when an IP interface is created. Note that when Local Proxy ARP is enabled for any one IP router interface associated with a VLAN, the feature is applied to the entire VLAN. It is not necessary to enable it for each interface. However, if the IP interface that has this feature enabled is moved to another VLAN, Local Proxy ARP is enabled for the new VLAN and must be enabled on another interface for the old VLAN.

ARP Filtering
ARP filtering is used to determine whether or not the switch responds to ARP requests that contain a specific IP address. This feature is generally used in conjunction with the Local Proxy ARP application; however, ARP filtering is available for use on its own and/or with other applications. By default, no ARP filters exist in the switch configuration. When there are no filters present, all ARP packets are processed, unless they are blocked or redirected by some other feature.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 436 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IP-Directed Broadcasts
An IP directed broadcast is an IP datagram that has all zeroes or all 1 in the host portion of the destination IP address. The packet is sent to the broadcast address of a subnet to which the sender is not directly attached. Directed broadcasts are used in denial-of-service smurf attacks. In a smurf attack, a continuous stream of ping requests is sent from a falsified source address to a directed broadcast address, resulting in a large stream of replies, which can overload the host of the source address. By default, the switch drops directed broadcasts. Typically, directed broadcasts should not be enabled.

Denial of Service (DoS) Filtering

By default, the switch filters denial of service (DoS) attacks, which are security attacks aimed at devices that are available on a private network or the Internet. Some of these attacks aim at system bugs or vulnerability (for example, teardrop attacks), while other types of attacks involve generating large volumes of traffic so that network service will be denied to legitimate network users (such as Pepsi attacks). These attacks include the following: ICMP Ping of DeathPing packets that exceed the largest IP datagram size (65535 bytes) are sent to a host and hang or crash the system. SYN AttackFloods a system with a series of TCP SYN packets, resulting in the host issuing SYNACK responses. The half open TCP connections can exhaust TCP resources, such that no other TCP connections are accepted. Land AttackSpoofed packets are sent with the SYN flag set to a host on any open port that is listening. The machine may hang or reboot in an attempt to respond. Teardrop/Bonk/Boink attacksBonk/Boink/teardrop attacks generate IP fragments in a special way to exploit IP stack vulnerabilities. If the fragments overlap the way those attacks generate packets, an attack is recorded. Since teardrop, bonk, and Boink all use the same IP fragmentation mechanism to attack, these is no distinction between detection of these attacks. The old IP fragments in the fragmentation queue are also reaped once the reassemble queue goes above certain size. Pepsi AttackThe most common form of UDP flooding directed at harming networks. A Pepsi attack is an attack consisting of a large number of spoofed UDP packets aimed at diagnostic ports on network devices. This can cause network devices to use up a large amount of CPU time responding to these packets. The switch can be set to detect various types of port scans by monitoring for TCP or UDP packets sent to open or closed ports. Monitoring is done in the following manner: Packet penalty values set. TCP and UDP packets destined for open or closed ports are assigned a penalty value. Each time a packet of this type is received, its assigned penalty value is added to a running total. This total is cumulative and includes all TCP and UDP packets destined for open or closed ports. Port scan penalty value threshold. The switch is given a port scan penalty value threshold. This number is the maximum value the running penalty total can achieve before triggering an SNMP trap. Decay value; A decay value is set. The running penalty total is divided by the decay value every minute. Trap generation; If the total penalty value exceeds the set port scan penalty value threshold, a trap is generated to alert the administrator that a port scan may be in progress.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 437 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IP Services
When a switch initially boots up, all supported TCP/UDP well-known service ports are enabled (open). Although these ports provide access for essential switch management services, such as telnet, ftp, snmp, etc., they also are vulnerable to DoS attacks. It is possible to scan open service ports and launch such attacks based on well-known port information. The ip service command allows you to selectively disable (close) TCP/UDP well-known service ports and enable them when necessary. This command only operates on TCP/UDP ports that are opened by default. It has no affect on ports that are opened by loading applications, such as RIP, etc. In addition, the ip service command allows you to designate which port to enable or disable by specifying the name of a service or the well-known port number associated with that service. The following table lists ip service command options for specifying TCP/UDP services and also includes the well-known port number associated with each service: Service Port 21 FTP 22 SSH 23 Telnet HTTP 80 443 Secure-HTTP A-VLAN-HTTP 260 261 AVLAN-Secure-HTTP A-VLAN-Telnet 259 67 UDP-Relay Network-Time 123 161 SNMP Proprietary 1024 1025 Proprietary

Managing IP
The following sections describe IP commands that can be used to monitor and troubleshoot IP forwarding on the switch.

Internet Control Message Protocol (ICMP)

ICMP is a network layer protocol within the IP protocol suite that provides message packets to report errors and other IP packet processing information back to the source. ICMP generates several kinds of useful messages, including Destination Unreachable, Echo Request and Reply, Redirect, Time Exceeded, and Router Advertisement and Solicitation. If an ICMP message cannot be delivered, a second one is not generated. This prevents an endless flood of ICMP messages. When a switch sends an ICMP destination-unreachable message, it means that the switch is unable to send the package to its final destination. The switch then discards the original packet. There are two reasons why a destination might be unreachable. Most commonly, the source host has specified a non-existent address. Less frequently, the switch does not have a route to the destination. Destination-unreachable messages include four basic types: Network-Unreachable MessageUsually means that a failure has occurred in the route lookup of the destination IP in the packet. Host-Unreachable MessageUsually indicates delivery failure, such as a unresolved client's hardware address or an incorrect subnet mask. Protocol-Unreachable MessageUsually means that the destination does not support the upper-layer protocol specified in the packet. Port-Unreachable MessageImplies that the TCP/UDP socket or port is not available.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 438 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Additional ICMP messages include: Echo-Request MessageGenerated by the ping command, the message is sent by any host to test node reach ability across an Internetwork. The ICMP echo-reply message indicates that the node can be successfully reached. Redirect MessageSent by the switch to the source host to stimulate more efficient routing. The switch still forwards the original packet to the destination. ICMP redirect messages allow host routing tables to remain small because it is necessary to know the address of only one switch, even if that switch does not provide the best path. Even after receiving an ICMP redirect message, some devices might continue using the less-efficient route. Time-Exceeded MessageSent by the switch if an IP packets TTL field reaches zero. The TTL field prevents packets from continuously circulating the Internetwork if the Internetwork contains a routing loop. Once a packets TTL field reaches 0, the switch discards the packet.

The Minimum Packet Gap

The minimum packet gap is the time required between sending messages of a like type. For instance, if the minimum packet gap for Address Mask request messages is 40 microseconds, and an Address Mask message is sent, at least 40 microseconds must pass before another one could be sent.

ICMP Control Table

The ICMP Control Table displays ICMP control messages, whether they are enabled or disabled, and the minimum packet gap times.

ICMP Statistics Table

The ICMP Statistics Table displays ICMP statistics and errors. This data can be used to monitor and troubleshoot IP on the switch.

The Ping Command

The ping command is used to test whether an IP destination can be reached from the local switch. This command sends an ICMP echo request to a destination and then waits for a reply. To ping a destination, enter the ping command and enter either the destinations IP address or host name. The switch will ping the destination using the default frame count, packet size, interval, and timeout parameters (6 frames, 64 bytes, 1 second, and 5 seconds respectively). When you ping a device, the device IP address or host name are required. Optionally, you may also specify: Count. Use the count keyword to set the number of frames to be transmitted. Size. Use the size keyword to set the size, in bytes, of the data portion of the packet sent for this ping. You can specify a size or a range of sizes up to 60,000. Interval. Use the interval keyword to set the frequency, in seconds that the switch will poll the host. Timeout. Use the timeout keyword to set the number of seconds the program will wait for a response before timing out.

Tracing an IP Route
The traceroute command is used to find the path taken by an IP packet from the local switch to a specified destination. This command displays the individual hops to the destination as well as some timing information. When using this command, you must enter the name of the destination as part of the command line (either the IP address or host name). Use the optional max-hop parameter to set a maximum hop count to the destination. If the trace reaches this maximum hop count without reaching the destination, the trace stops.

Displaying TCP Information

Use the show tcp statistics command to display TCP statistics. Use the show tcp ports command to display TCP port information.

Displaying UDP Information

UDP is a secondary transport-layer protocol that uses IP for delivery. UDP is not connection-oriented and does not provide reliable end-to-end delivery of Datagrams. But some applications can safely use UDP to send Datagrams that do not require the extra overhead added by TCP. Use the show udp statistics command to display UDP statistics. Use the show udp ports command to display UDP port information. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 439 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Tunneling
Tunneling is a mechanism that can encapsulate a wide variety of protocol packet types and route them through the configured tunnels. Tunneling is used to create a virtual point-to-point link between routers at remote points in a network. This feature supports the creation, administration, and deletion of IP interfaces whose underlying virtual device is a tunnel. The Alcatel-Lucent implementation provides support for two tunneling protocols: Generic Routing Encapsulation (GRE) and IP encapsulation within IP (IPIP). Note. The tunneling feature is supported by OmniSwitch 6850 and OmniSwitch 9000.

Generic Routing Encapsulation

GRE encapsulates a packet that needs to be carried over the GRE tunnel with a GRE header. The resulting packet is then encapsulated with an outer header by the delivery protocol and forwarded to the other end of the GRE tunnel. The destination IP address field in the outer header of the GRE packet contains the IP address of the router at the remote end of the tunnel. The router at the receiving end of the GRE tunnel extracts the original payload and routes it to the destination address specified in the payloads IP header. Consider the following when configuring the GRE tunnel interfaces: A switch can support up to 8 GRE tunnel interfaces. The features such as Multinetting, Egress ACL, NAT, QoS, and VRRP are not supported on the GRE tunnel interfaces.

IP Encapsulation within IP
IPIP tunneling is a method by which an IP packet is encapsulated within another IP packet. The Source Address and Destination Address of the outer IP header identifies the endpoints of tunnel. Whereas Source Address and Destination Address of the inner IP header identifies the original sender and recipient of the packet, respectively. Consider the following when configuring the IPIP tunnel interfaces: A switch can support up to 127 IPIP tunnel interfaces. IPIP tunnel interfaces are included in the maximum number of IP interfaces that are supported on the switch.

Tunneling operation
The diagram below illustrates how packets are forwarded over the tunnel. In the above diagram, IP packets flowing from the private IP network 50.0.0.0 to the private IP network 40.0.0.0 are encapsulated by the tunneling protocol at switch A and forwarded to switch B. Intermediate switches route the packets using addresses in the delivery protocol header. Switch B extracts the original payload and routes it to the appropriate destination in the 40.0.0.0 network. The tunnel interface is identified as being up when all of the following are satisfied: Both source and destination addresses are assigned. The source address of the tunnel is one of the switch's IP interface addresses that is either a VLAN or loopback0 interface. A route is available to reach the destination IP address. A route whose egress interface is a VLANbased interface is available for its destination IP address.The switch supports assigning an IP address as well as routes to a tunnel interface.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 440 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IPv6
Internet Protocol version 6 (IPv6) is the next generation of Internet Protocol version 4 (IPv4). Both versions are supported along with the ability to tunnel IPv6 traffic over IPv4. Implementing IPv6 solves the limited address problem currently facing IPv4, which provides a 32-bit address space. IPv6 increases the address space available to 128 bits.

IPv6 Specifications
RFCs Supported
Note: RFC 2893 has been obsoleted by RFC4213. RFC4213 is now supported, but it does not include Automatic tunnels. Therefore, the main difference is that the new RFC4213 does not contain an automatic tunneling capability.

Maximum VLANs per switch Maximum IPv6 router VLANs per switch Maximum IPv4 router VLANs per switch Maximum IPv4interfcase per VLAN Maximum ARP entries per system Maximum IPv6 interfaces per tunnel Maximum IPv6 static routes Maximum RIPng routes Maximum RIPng interfaces Maximum OSPFv3 routes Maximum OSPFv3 interfaces Maximum OSPFv3 adjacencies Maximum OSPFv3 areas Maximum OSPFv3 sessions OSPF ECMP Gateways per destination Maximum BGP routes Maximum IP route entries (RIB) Maximum route entries per FIB Maximum BGP peers per system OSPF LSDB size Maximum IPv6 router interfaces per system -multiple router MAC mode Maximum 6to4 tunnels per switch Maximum configured tunnels per switch

2460Internet Protocol, Version 6 (IPv6) Specification 2461Neighbor Discovery for IP Version 6 (IPv6) 2462IPv6 Stateless Address Auto-configuration 2463Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification 2464Transmission of IPv6 Packets Over Ethernet Networks 2893Transition Mechanisms for IPv6 Hosts and Routers 3513Internet Protocol Version 6 (IPv6) Addressing Architecture 3056Connection of IPv6 Domains via IPv4 Clouds 4094 (including default VLAN 1) 4094 IP and 256 IPX (single MAC router mode) 4094 IP and 256 IPX (single MAC router mode) 1 4K 1 1,000 5K 100 10K 10 10 5 1 4 None 10K None None 2000 256 1 255

IPv6 Defaults
Description Global status of IPv6 on the switch IPv6 interfaces Default Enabled None

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 441 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IPv6 Overview
IPv6 provides the basic functionality that is offered with IPv4 but includes the following enhancements and features not available with IPv4: Increased IP address sizeIPv6 uses a 128-bit address, a substantial increase over the 32-bit IPv4 address size. Providing a larger address size also significantly increases the address space available, thus eliminating the concern over running out of IP addresses. Auto-configuration of addressesWhen an IPv6 interface is created or a device is connected to the switch, an IPv6 linklocal address is automatically assigned for the interface and/or device. Anycast addressesA new type of address. Packets sent to an Anycast address are delivered to one member of the Anycast group. Simplified header formatA simpler IPv6 header format is used to keep the processing and bandwidth cost of IPv6 packets as low as possible. As a result, the IPv6 header is only twice the size of the IPv4 header despite the significant increase in address size. Improved support for header optionsImproved header option encoding allows more efficient forwarding, fewer restrictions on the length of options, and greater flexibility to introduce new options. Security improvementsExtension definitions provide support for authentication, data integrity, and confidentiality. Neighbor Discovery protocolA protocol defined for IPv6 that detects neighboring devices on the same link and the availability of those devices. Additional information that is useful for facilitating the interaction between devices on the same link is also detected (e.g., neighboring address prefixes, address resolution, duplicate address detection, link MTU, and hop limit values, etc.). This implementation of IPv6 also provides the following mechanisms to maintain compatibility between IPv4 and IPv6: Dual-stack support for both IPv4 and IPv6 on the same switch Configuration of IPv6 and IPv4 interfaces on the same VLAN. Tunneling of IPv6 traffic over an IPv4 network infrastructure Embedded IPv4 addresses in the four lower-order bits of the IPv6 address. The remainder of this section provides a brief overview of the new IPv6 address notation, auto-configuration of addresses, and tunneling of IPv6 over IPv4.

IPv6 Addressing
One of the main differences between IPv6 and IPv4 is that the address size has increased from 32 bits to 128 bits. Going to a 128-bit address also increases the size of the address space to the point where running out of IPv6 addresses is not a concern. The following types of IPv6 addresses are supported: UnicastStandard unicast addresses, similar to IPv4. MulticastAddresses that represent a group of devices. Traffic sent to a multicast address is delivered to all members of the multicast group. AnycastTraffic that is sent to this type of address is delivered to one member of the Anycast group. The device that receives the traffic is usually the one that is easiest to reach as determined by the active routing protocol. Note. IPv6 does not support the use of broadcast addresses. This functionality is replaced using improved multicast addressing capabilities. IPv6 address types are identified by the high-order bits of the address, as shown in the following table: Address Type Unspecified Loop back Multicast Link-local unicast Site-local unicast Global unicast Binary Prefix 000 (128 bits) 001 (128 bits) 11111111 1111111010 1111111011 Everything else IPv6 Notation ::/128 ::1/128 FF00::/8 FE90::/10 FEC0::/10

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 442 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IPv6 Address Notation

IPv4 addresses are expressed using dotted decimal notation and consist of four eight-bit octets. If this same method was used for IPv6 addresses, the address would contain 16 such octets, thus making it difficult to manage. IPv6 addresses are expressed using colon hexadecimal notation and consist of eight 16-bit words, as shown in the following example: 1234:000F:531F:4567:0000:0000:BCD2:F34A Note that any field may contain all zeros or all ones. In addition, it is possible to shorten IPv6 addresses by suppressing leading zeros. For example: 1234:F:531F:4567:0:0:BCD2:F34A Another method for shortening IPv6 addresses is known as zero compression. When an address contains contiguous words that consist of all zeros, a double colon (::) is used to identify these words. For example, using zero compression the address 0:0:0:0:1234:531F:BCD2:F34A is expressed as follows: ::1234:531F:BCD2:F34A Because the last four words of the above address are uncompressed values, the double colon indicates that the first four words of the address all contain zeros. Note that using the double colon is only allowed once within a single address. So if the address was1234:531F:0:0:BCD2:F34A:0:0, a double colon could not replace both sets of zeros. For example, the first two versions of this address shown below are valid; the last version is not valid: 1 1234:531F::BCD2:F34A:0:0 2 1234:531F:0:0:BCD2:F34A:: 3 1234:531F::BCD2:F34A:: (not valid) With IPv6 addresses that have long strings of zeros, the benefit of zero compression is more dramatic. For example, address FF00:0:0:0:0:0:4501:32 becomes FF00::4501:32. Note that hexadecimal notation used for IPv6 addresses resembles that, which is used for MAC addresses. However, it is important to remember that IPv6 addresses still identify a device at the Layer 3 level and MAC addresses identify a device at the Layer 2 level. Another supported IPv6 address notation includes embedding an IPv4 address as the four lower-order bits of the IPv6 address. This is especially useful when dealing with a mixed IPv4/IPv6 network. For example: 0:0:0:0:0:0:212.100.13.6

IPv6 Address Prefix Notation

The Classless Inter-Domain Routing (CIDR) notation is used to express IPv6 address prefixes. This notation consists of the 128-bit IPv6 address followed by a slash (/) and a number representing the prefix length (IPv6-address/prefix-length). For example, the following IPv6 address has a prefix length of 64 bits: FE80::2D0:95FF:FE12:FAB2/64

Auto-configuration of IPv6 Addresses

This implementation of IPv6 supports the stateless auto-configuration of link-local addresses for IPv6 VLAN and tunnel interfaces and for devices when they are connected to the switch. Stateless refers to the fact that little or no configuration is required to generate such addresses and there is no dependency on an address configuration server, such as a DHCP server, to provide the addresses. A link-local address is a private unicast address that identifies an interface or device on the local network. This type of address allows communication with devices and/or neighboring nodes that are attached to the same physical link. Routing between link-local addresses is not available, link-local addresses are not known or advertised to the general network. When an IPv6 VLAN or a tunnel interface is created, or a device is connected to the switch, a link-local address is automatically generated for the interface or device. This type of address consists of the well-known IPv6 prefix FE80::/64 combined with an interface ID. The interface ID is derived from the router MAC address associated with the IPv6 interface or the source MAC address if the address is for a device. The resulting link-local address resembles the following example: FE80::2d0:95ff:fe6b:5ccd/64 Note that when this example address was created, the MAC address was modified by complementing the second bit of the leftmost byte and by inserting the hex values 0xFF and 0xFE between the third and fourth octets of the address. These modifications were done because IPv6 requires an interface ID that is derived using Modified EUI-64 format. Stateless auto-configuration is not available for assigning a global unicast or Anycast address to an IPv6 interface. In other words, manual configuration is required to assign a non-link-local address to an interface.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 443 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Both stateless and Stateful auto-configuration is supported for devices, such as a workstation, when they are connected to the switch. When the stateless method is used in this instance, the device listens for router advertisements in order to obtain a subnet prefix. Combining the subnet prefix with the interface ID for that device then forms the unicast address for the device. Stateful auto-configuration refers to the use of an independent server, such as a DHCP server, to obtain an IPv6 unicast address and other related information. Of course, manual configuration of an IPv6 address is always available for devices as well. Regardless of how an IPv6 address is obtained, duplicate address detection (DAD) is performed before the address is assigned to an interface or device. If a duplicate is found, the address is not assigned. Note that DAD is not performed for Anycast addresses. Please refer to RFCs 2462, 2464, and 3513 for more technical information about auto-configuration and IPv6 address notation.

Tunneling IPv6 over IPv4

It is likely that IPv6 and IPv4 network infrastructures will coexist for some time, if not indefinitely. Tunneling provides a mechanism for transitioning an IPv4 network to IPv6 and/or maintaining interoperability between IPv4 and IPv6 networks. This implementation of IPv6 supports tunneling of IPv6 traffic over IPv4. There are two types of tunnels supported: 6to4 and configured. Note. RIPng is not supported over 6to4 tunnels. However, it is possible to create a RIPng interface for a configured tunnel.

6to4 Tunnels
6to4 tunneling provides a mechanism for transporting IPv6 host traffic over an IPv4 network infrastructure to other IPv6 hosts and/or domains without having to configure explicit tunnel endpoints. Instead, an IPv6 6to4 tunnel interface is created at points in the network where IPv6 packets are encapsulated (IPv4 header added) prior to transmission over the IPv4 network or decapsulates (IPv4 header stripped) for transmission to an IPv6 destination. An IPv6 6to4 tunnel interface is identified by its assigned address, which is derived by combining a 6to4 well-known prefix (2002) with a globally unique IPv4 address and embedded as the first 48 bits of an IPv6 address. For example, 2002:d467:8a89::137/64, where D467:8A89 is the hex equivalent of the IPv4 address 212.103.138.137. 6to4 tunnel interfaces are configured on routers and identify a 6to4 site. Because 6to4 tunnels are point-to-multi-point in nature, any one 6to4 router can communicate with one or more other 6to4 routers across the IPv4 cloud. Two common scenarios for using 6to4 tunnels are described below.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 444 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

6to4 Site to 6to4 Site over IPv4 Domain

In this scenario, isolated IPv6 sites have connectivity over an IPv4 network through 6to4 border routers. An IPv6 6to4 tunnel interface is configured on each border router and assigned an IPv6 address with the 6to4 well known prefix, as described above. IPv6 hosts serviced by the 6to4 border router have at least one IPv6 router interface configured with a 6to4 address. Note that additional IPv6 interfaces or external IPv6 routing protocols are not required on the 6to4 border router. The following diagram illustrates the basic traffic flow between IPv6 hosts communicating over an IPv4 domain:

In the above diagram: 1 The 6to4 hosts receive 6to4 prefix from Router Advertisement. 2 The 6to4 host sends IPv6 packets to 6to4 border router. 3 The 6to4 border router encapsulates IPv6 packets with IPv4 headers and sends to the destination 6to4 border router over the IPv4 domain. 4 The destination 6to4 border router strips IPv4 header and forwards to 6to4 destination host.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 445 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

6to4 Site to IPv6 Site over IPv4/IPv6 Domains

In this scenario, 6to4 sites have connectivity to native IPv6 domains through a relay router, which is connected to both the IPv4 and IPv6 domains. The 6to4 border routers are still used by 6to4 sites for encapsulating/de-capsulating host traffic and providing connectivity across the IPv4 domain. In addition, each border router has a default IPv6 route pointing to the relay router. In essence, a relay router is a 6to4 border router on which a 6to4 tunnel interface is configured. However, a native IPv6 router interface is also required on the relay router to transmit 6to4 traffic to/from IPv6 hosts connected to an IPv6 domain. Therefore, the relay router participates in both the IPv4 and IPv6 routing domains. The following diagram illustrates the basic traffic flow between native IPv6 hosts and 6to4 sites:

In the above diagram: 1 The 6to4 relay router advertises a route to 2002::/16 on its IPv6 router interface. 2 The IPv6 host traffic received by the relay router that has a next hop address that matches 2002::/16 is routed to the 6to4 tunnel interface configured on the relay router. 3 The traffic routed to the 6to4 tunnel interface is then encapsulated into IPv4 headers and sent to the destination 6to4 router over the IPv4 domain. 4 The destination 6to4 router strips the IPv4 header and forwards it to the IPv6 destination host.

Configured Tunnels
A configured tunnel is where the endpoint addresses are manually configured to create a point-to-point tunnel. This type of tunnel is similar to the 6to4 tunnel on which IPv6 packets are encapsulated in IPv4 headers to facilitate communication over an IPv4 network. The difference between the two types of tunnels is that configured tunnel endpoints require manual configuration, whereas 6to4 tunneling relies on an embedded IPv4 destination address to identify tunnel endpoints. Note that RFC 2893 also discusses automatic tunnels, which are not supported with this implementation of IPv6. Note: RFC 2893 has been obsoleted by RFC4213. RFC4213 is now supported, but it does not include automatic tunnels. Therefore, the main difference is that the new RFC4213 does not contain an automatic tunneling capability. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 446 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

IPX
The Internet Packet Exchange (IPX) protocol, developed by Novell for NetWare, is a Layer 3 protocol used to route packets through IPX networks. (NetWare is Novells network server operating system.). This feature supports IPX routing, and fine-tuning IPX using optional IPX configuration parameters (e.g., IPX packet extension, type-20 propagation). It also supports IPX filtering, which is used to control the operation of the IPX RIP/SAP protocols.

IPX Specifications
Specifications Supported IPX RIP and Service Advertising Protocol (SAP) router specification; version 1.30; May 23, 1996 Part No. 107-000029-001

IPX Defaults
Description IPX Defaults Type-20 Packet Forwarding Extended RIP/SAP Packets RIP/SAP Timers Default Enabled Disabled Disabled 60 (seconds)

IPX Overview
IPX specifies a connectionless datagram similar to the IP packet of TCP/IP networks. An IPX network address consists of two parts: a network number and a node number. The network administrator assigns the IPX network number. The node number is the Media Access Control (MAC) address for a network interface in the end node. IPX exchanges information using its own version of RIP, which sends updates every 60 seconds. NetWare also supports SAP to allow network resources, including file and print servers, to advertise their network addresses and the services they provide. The user can also define routes. These routes, called static routes, have higher priority than routes learned through RIP. When IPX is enabled, devices connected to ports on the same VLAN are able to communicate. However, to route packets between VLANs, you must create an IPX router port on each VLAN. In the illustration below, a router port has been configured on each VLAN. Therefore, workstations connected to ports on VLAN 1 on Switch 1 can communicate with VLAN 2; and workstations connected to ports on VLAN 3 on Switch 2 can communicate with VLAN 2. Also, ports from both switches have been assigned to VLAN 2, and a physical connection has been made between the switches. Therefore, workstations connected to VLAN 1 on Switch 1 can communicate with workstations connected to VLAN 3 on Switch 2.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 447 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

In IPX routing, the switch builds routing tables to keep track of optimal destinations for traffic it receives that is destined for remote IPX networks. The switch sends and receives routing messages, or advertisements, to/from other switches in the network. When the switch receives an IPX packet, it looks up the destination network number in its routing table. If the network is directly connected to the switch, the switch also checks the destination node address. IPX is associated with additional protocols built into the switch software. The switch supports the following IPX protocols: IPX RIPLayer 3 protocol used by NetWare routers to exchange IPX routing information. IPX RIP and IP RIP functions are similar. IPX RIP uses two metrics to calculate the best route: hop count and ticks. An IPX router periodically transmits packets containing the information currently in its own routing table to neighboring IPX RIP routers to advertise the best route to an IPX destination. SAPLayer 3 protocol used by NetWare routers to exchange IPX routing information. SAP is similar in concept to IPX RIP. Just as RIP enables NetWare routers to exchange information about routes, SAP enables NetWare devices to exchange information about available network services. NetWare workstations use SAP to obtain the network addresses of NetWare servers. IPX routers use SAP to gather service information and then share it with other IPX routers. Sequenced Packet Exchange (SPX)Transport-layer protocol that provides a reliable end-to-end communications link by managing packet sequencing and delivery. SPX does not play a direct role in IPX routing; it simply guarantees the delivery of routed packets.

IPX Routing
When IPX is enabled, devices connected to ports on the same VLAN are able to communicate. However, to route packets to a device on a different VLAN, you must create an IPX router port on each VLAN. IPX is enabled by default. You must configure an IPX router port on a VLAN for devices on that VLAN to communicate with devices on other VLANs. You can only create one IPX router port per VLAN. VLAN router ports are not active until at least one active physical port is assigned to the VLAN. Up to 256 router ports are supported (including IP and IPX). You can configure an IP and IPX router port on the same VLAN. Both types of router ports will share the same MAC address for that VLAN. Note. Router port IPX addresses must be unique. You cannot have two router ports with the same IPX address.

IPX Router Port Configuration Options

When you create an IPX router port using the vlan router IPX command, RIP routing is enabled using the default parameters listed below. However, you can use the full command to change the default parameters. Routing Type By default both RIP and SAP packets are processed (active). However, additional configurations can be used: Active. RIP and SAP updates are processed (default) RIP. RIP updates are processed (SAP is disabled) Inactive. RIP and SAP updates are not processed, but the router port remains active. Encapsulation Type Ethernet 2 encapsulation is the default encapsulation type. However, other types can be configured: E2. Ethernet 2 encapsulation (default) Novell. Novell Raw (802.3) encapsulation LLC. LLC (802.2) encapsulation Snap. SNAP encapsulation. Delay To configure the IPX delay, enter the syntax time-ticks and specify the number of ticks for IPX delay time. A tick is approximately 1/18th of a second. The valid range is 065535. The default is 0.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 448 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Static Routes
A static route enables you to send traffic to a switch other than those learned through routing protocols. Static routes are user-defined and carry a higher priority than routes created by dynamic routing protocols. That is, if two routes have the same metric value, the static route has the higher priority. Static routes allow you to define, or customize, an explicit path to an IP network segment, which is then added to the IP forwarding table. Static routes can be created between VLANs to enable devices on these VLANs to communicate. Static routes do not age out of the routing tables; however, they can be deleted.

Type-20 Packet Forwarding

Type 20 is an IPX packet type that refers to any propagated packet. Novell has defined the use of these packets to support certain protocol implementations, such as NetBIOS. Because these packets are broadcast and propagated across networks, the addresses of those networks (up to 8) are stored in the packets data area. If Type 20 packet forwarding is enabled, the switch receives and propagates Type 20 packets through all its interfaces. If Type 20 packet forwarding is disabled, the switch discards, rather than propagates, any Type 20 packet it receives. Type 20 packet forwarding is disabled by default. This is because these packets can cause problems in highly redundant IPX networks by creating what appears to be a broadcast storm. This problem is aggravated whenever misconfigured PCs are added to a network.

Extended RIP and SAP Packets

Larger RIP and SAP packets can be transmitted to reduce network congestion. Other switches and routers in the network must support larger packet sizes if this feature is configured on the switch. RIP packets can contain up to 68 network entries. SAP packets can contain up to 8 network entries. Extended RIP and SAP packets are disabled by default.

RIP and SAP Timers

By default, RIP and SAP packets are broadcast every 60 seconds, even if no change has occurred anywhere in a route or service. This default may be modified to alleviate network congestion or facilitate the discovery of network resources.

Using the PING Command

The ping command is used to test the reach-ability of certain types of IPX nodes. The software supports two different types of IPX pings: NovellUsed to test the reach-ability of NetWare servers currently running the NetWare Loadable Module called IPXRTR.NLM. This type cannot be used to reach NetWare workstations running IPXODI. Novell uses a unique type of ping for this purpose (implemented by their IPXPNG.EXE program). The switch software does not currently support this type of ping. Other vendors switches may respond to this type of ping. Alcatel-LucentUsed to test the reach-ability of Alcatel-Lucent switches on which IPX routing is enabled. Network devices that do not recognize the specific type of IPX ping request sent from the switch will not respond at all. This lack of a response does not necessarily mean that a specific network device is inactive or missing. Therefore, you might want to try using both types before concluding that the network device is unreachable. When you ping a device, the device IPX address and node are required. Optionally, you may also specify: Count. Use the count keyword to set the number of packets to be transmitted. Size. Use the size keyword to set the size, in bytes, of the data portion of the packet sent for this ping. The valid range is 1 to 8192. Timeout. Use the timeout keyword to set the number of seconds the program will wait for a response before timing out. Type. Use the type keyword to specify the packet type you want to send (Novell or Alcatel-Lucent). Use the Novell packet type to test the reach-ability of NetWare servers running the NetWare Loadable Module (IPXRTR.NLM). This type cannot be used to reach NetWare workstations running IPXODI. You can use the Alcatel-Lucent packet type to test the reach-ability of Alcatel-Lucent switches on which IPX routing is enabled. However, Alcatel-Lucent switches will respond to either type. Note. If you change the default values they will only apply to the current ping. The next time you use the ping command, the default values will be used unless you again enter different values. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 449 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

IPX RIP/SAP Filtering

The IPX RIP/SAP Filtering feature gives you a means of controlling the operation of the IPX RIP/SAP protocols. By using IPX RIP/SAP filters, you can minimize the number of entries put in the IPX RIP Routing and SAP Bindery Tables; improve overall network performance by eliminating unnecessary traffic, and control users access to NetWare services. For example: RIP Input and Output filters can be used to isolate entire network segments (and/or switches) to make the network appear differently to the different segments. RIP Input and Output filters can be used to reduce the amount of traffic needed to advertise routes that should not be used by a particular network segment. SAP Input and Output filters can be used to improve performance by limiting the amount of SAP traffic. For example, because printing is generally a local operation, theres no need to advertise print servers to remote networks. A SAP filter can be used in this case to restrict Print Server Advertisement SAPs. Five types of IPX RIP/SAP filters are available: RIP Input Filters: Control which networks are allowed into the routing table when IPX RIP updates are received. RIP Output Filters: Control the list of networks included in routing updates sent by the switch. These filters control which networks the switch advertises in its IPX RIP updates. SAP Input Filters: Control the SAP updates received by the switch prior to a switch accepting information about a service. The switch will filter all incoming service advertisements received before accepting information about a service. SAP Output Filters: Control which services are included in SAP updates sent by the switch. The switch applies the SAP output filters prior to sending SAP packets. GNS Output Filters: Control which servers are included in the GNS responses sent by the switch. All types of IPX Filters can be configured either to allow or to block traffic. The default setting for all filters is to allow traffic. Therefore, you will typically only have to define a filter to block traffic. However, defining a filter to allow certain traffic may be useful in situations where a more generic filter has been defined to block the majority of the traffic. For example, you could use a filter to allow traffic from a specific host on a network where all other traffic has been blocked. A discussion of the precedence of allow filters appears later in this section. Keep in mind that precedence applies only to allow filters, not to block filters. Note. You can apply filters to all router interfaces by defining a global filter, or you can limit the filter to specific interfaces.

RIP Filters
IPX RIP filters allow you to minimize the number of entries put in the IPX RIP routing table. RIP input filters control which networks are allowed into the routing table when IPX RIP updates are received. RIP output filters control, which networks the switch, advertises in its IPX RIP updates. Note. RIP filters work only on switches running the RIP protocol. They do not work for switches running the NLSP protocol. Use RIP filters with care because they can partition a physical network into two or more segments.

SAP Filters
IPX SAP filters allow you to minimize the number of entries put in the SAP Bindery Table. SAP input filters control the SAP updates received by the switch prior to a switch accepting information about a service. The switch will filter all incoming service advertisements received before accepting information about a service. SAP output filters control which services are included in SAP updates sent by the switch.

GNS Filters
GNS output filters control which servers are included in the GNS responses sent by the switch. GNS supports output filters only.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 450 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

RIP
Routing Information Protocol (RIP) is a widely used Interior Gateway Protocol (IGP) that uses hop count as its routing metric. RIP-enabled routers update neighboring routers by transmitting a copy of their own routing table. The RIP routing table uses the most efficient route to a destination that is, the route with the fewest hops and longest matching prefix. The switch supports RIP version 1 (RIPv1), RIP version 2 (RIPv2), and RIPv2 that is compatible with RIPv1. It also supports text key and MD5 authentication, on an interface basis, for RIPv2.

RIP Specifications
RFCs supported RFC 1058RIP v1 RFC 2453RIP v2 RFC 1722RIP v2 Protocol Applicability Statement RFC 1724RIP v2 MIB Extension Maximum number of IP Routes: 48K Maximum number of RIPv2 interfaces per router: 6 Maximum number of RIPv2 peers per router, one per interface: 6 Maximum number of RIPv2 routes: 8K

RIP Defaults
Description RIP Status RIP Forced Hold-down Interval RIP Interface Metric RIP Interface Send Version RIP Interface Receive Version RIP Host Route RIP Route Tag Redistribution Status Redistribution Metric Redistribution Filter Effect Redistribution Filter Metric Redistribution Filter Control Redistribution Filter Route Tag RIP Interface Authentication Defaults Disable 0 1 V2 Both Enable 0 Disable 0 Permit 0 All-subnets 0 None

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 451 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

RIP Overview
In switching, traffic may be transmitted from one media type to another within the same VLAN. Switching happens at Layer 2, the link layer; routing happens at Layer 3, the network layer. In IP routing, traffic can be transmitted across VLANs. When IP routing is enabled, the switch uses routing protocols to build routing tables that keep track of stations in the network and decide the best path for forwarding data. When the switch receives a packet to be routed, it strips off the MAC header and examines the IP header. It looks up the source/destination address in the routing table, and then adds the appropriate MAC address to the packet. Calculating routing tables and stripping/adding MAC headers to packets is performed by switch software. IP is associated with several Layer 3 routing protocols. RIP is built into the base code loaded onto the switch. Others are part of Alcatel-Lucents optional Advanced Routing Software. IP supports the following IP routing protocols: RIP: An IGP that defines how routers exchange information. RIP makes routing decisions using a least-cost path method. RIPv1 and RIPv2 services allow the switch to learn routing information from neighboring RIP routers. Open Shortest Path First (OSPF): An IGP that provides a routing function similar to RIP but uses different techniques to determine the best route for a datagram. OSPF is part of Alcatel-Lucents optional Advanced Routing Software. When RIP is initially enabled on a switch, it issues a request for routing information, and listens for responses to the request. If a switch configured to supply RIP hears the request, it responds with a response packet based on information in its routing database. The response packet contains destination network addresses and the routing metric for each destination. When a RIP response packet is received, RIP takes the information and rebuilds the switchs routing database, adding new routes and better (lower metric) routes to destinations already listed in the database. RIP uses a hop count metric to measure the distance to a destination. In the RIP metric, a switch advertises directly connected networks at a metric of 1. Networks that are reachable through one other gateway are 2 hops; networks that are reachable through two gateways are 3 hops, etc. Thus, the number of hops (or hop count) along a path from a given source to a given destination refers to the number of networks that are traversed by a datagram along that path. When a switch receives a routing update that contains a new or changed destination network entry, the switch adds one to the metric value indicated in the update and enters the network in the routing table. After updating its routing table, the switch immediately begins transmitting routing updates to inform other network switches of the change. These updates are sent independently of the regularly scheduled updates. By default, RIP packets are broadcast every 30 seconds, even if no change has occurred anywhere in a route or service. RIP deletes routes from the database if the next switch to that destination says the route contains more than 15 hops. In addition, all routes through a gateway are deleted by RIP if no updates are received from that gateway for a specified time period. If a gateway is not heard from for 180 seconds, all routes from that gateway are placed in a hold-down state. If the hold-down timer value is exceeded, the routes are deleted from the routing database. These intervals also apply to deletion of specific routes.

RIP Version 2
RIP version 2 (RIPv2) adds additional capabilities to RIP. Not all RIPv2 enhancements are compatible with RIPv1. To avoid supplying information to RIPv1 routes that could be misinterpreted, RIPv2 can only use non-compatible features when its packets are multicast. RIPv1 does not support multicast. On inter-faces that are not compatible with IP multicast, the RIPv1compatible packets used do not contain potentially confusing information. RIPv2 enhancements are listed below. Next HopRIPv2 can advertise a next hop other than the switch supplying the routing update. This capability is useful when advertising a static route to a silent switch not using RIP, since packets passing through the silent switch do not have to cross the network twice. Network MaskRIPv1 assumes that all sub-networks of a given network have the same network mask. It uses this assumption to calculate the network masks for all routes received. This assumption prevents subnets with different net-masks from being included in RIP packets. RIPv2 adds the ability to specify the network mask with each network in a packet. Because RIPv1 switches ignore the network mask in RIPv2 packets, their calculation of the network mask could possibly be wrong. For this reason, RIPv1-compatible RIPv2 packets cannot contain networks that would be misinterpreted by RIPv1. These networks must only be provided in native RIPv2 packets that are multicast. AuthenticationRIPv2 packets can contain an authentication key that may be used to verify the validity of the supplied routing data. Authentication may be used in RIPv1-compatible RIPv2 packets, but RIPv1 switches will ignore authentication information. The authentication is a simple password in which an authentication key of up to 16 characters is included in the packet. If this key does not match the configured authentication key, the packet is discarded.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 452 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

 IP MulticastIP Multicast Switching (IPMS) is a one-to-many communication technique employed by emerging applications such as video distribution, news feeds, netcasting, and resource discovery. Unlike unicast, which sends one packet per destination, multicast sends one packet to all devices in any sub-network that has at least one device requesting the multicast traffic.

RIP Routing
IP routing requires IP router ports to be configured on VLANs and a routing protocol to be enabled and configured on the switch. RIP also requires a RIP interface to be created and enabled on the routing port. In the illustration below, a router port and RIP interface have been configured on each VLAN. Therefore, workstations connected to ports on VLAN 1 on Switch 1 can communicate with VLAN 2; and workstations connected to ports on VLAN 3 on Switch 2 can communicate with VLAN 2. Also, ports from both switches have been assigned to VLAN 2, and a physical connection has been made between the switches. Therefore, workstations connected to VLAN 1 on Switch 1 can communicate with workstations connected to VLAN 3 on Switch 2.

Note. In simple networks where only IP forwarding is required, you may not want to use RIP. If you are not using RIP, it is best not to load it to save switch resources. Note. You can create a RIP interface even if an IP router port has not been configured. However, RIP will not function unless a RIP interface is created and enabled on an IP router port.

The RIP Interface Metric

You can set priorities for routes generated by a switch by assigning a metric value to routes generated by that switchs RIP interface. For example, routes generated by a neighboring switch may have a hop count of 1. However, you can lower the priority of routes generated by that switch by increasing the metric value for routes generated by the RIP interface. Note. When you configure a metric for a RIP interface, this metric cost is added to the metric of the incoming route.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 453 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The RIP Forced Hold-down Interval

The RIP forced holddown timer value defines an amount of time, in seconds, during which routing information regarding better paths is suppressed. A route enters into a forced hold down state when an update packet is received that indicates the route is unreachable and when this timer is set to a non-zero value. After this timer has expired and if the value is less that 120 second, the route enters a holddown state for the rest of the period until the remainder of the 120 seconds has also expired. During this time the switch will accept any advertisements for better paths that are received. Note that the forced holddown timer is not the same as the RIP holddown timer. The RIP holddown timer is fixed at 120 seconds and is not configurable. The forced holddown timer defines a separate interval that overlaps the holddown state. During the forced holddown timer interval, the switch will not accept better routes from other gateways.

RIP Redistribution
Redistribution provides a way to exchange routing information between RIP networks and OSPF and BGP networks; and also redistributes local and static routes into RIP. Basically, redistribution makes a non-RIP route look like a RIP route. Configuring RIP redistribution consists of the following tasks: Enabling RIP Redistribution Configuring a RIP Redistribution Policy Configuring a RIP Redistribution Filter o Creating a Filter o Configuring a Redistribution Filter Action (optional) o Configuring a Redistribution Metric (optional)

Redistribution Metric
When redistributing routes into RIP, the metric for the redistributed route is calculated as a summation of the routes metric and the corresponding metric in the redistribution policy. This is the case when the matching filter metric is 0 (the default). However, if the matching redistribution filter metric is set to a non-zero value, the redistributed routes metric is set to the filter metric. This gives better control of the metric when redistributing non-RIP routes into RIP. Note that if the metric calculated for the redistributed route, as described above, is greater than 15 (RIP_UNREACHABLE) or greater than the metric of an existing pure RIP route, the new route is not redistributed.

RIP Redistribution Filter

After configuring a redistribution policy (e.g., OSPF), you must specify what routes will be redistributed by configuring a redistribution filter. Only routes matching the policy and destination specified in the filter will be redistributed into RIP. Creating a RIP redistribution filter consists of the following steps: Creating a Redistribution Filter Configuring the Redistribution Filter Action (optional) Configuring the Redistribution Filter Metric (optional) Configuring the Redistribution Filter Route Control Action (optional) Configuring a Redistribution Filter Route Tag (optional)

RIP Security
By default, there is no authentication used for a RIP. However, you can configure a password for a RIP interface. To configure a password, you must first select the authentication type (simple or MD5), and then configure a password. If simple or MD5 password authentication is used, both switches on either end of a link must share the same password. If you configure simple or MD5 authentication you must configure a text string that will be used as the password for the RIP interface. If a password is used, all switches that are intended to communicate with each other must share the same password.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 454 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OSPFv2 / OSPFv3
Open Shortest Path First routing (OSPF) is a shortest path first (SPF), or link state, protocol. OSPF is an interior gateway protocol (IGP) that distributes routing information between routers in a single Autonomous System (AS). OSPF chooses the least-cost path as the best path. OSPF is suitable for complex networks with large numbers of routers since it provides faster convergence where multiple flows to a single destination can be forwarded on one or more interfaces simultaneously. On OmniSwitch 6850 switches only, OSPF version 3 for IPv6 is supported.

OSPFv2 Specifications
RFCs Supported 1370Applicability Statement for OSPF 1850OSPF Version 2 Management Information Base 2328OSPF Version 2 2370The OSPF Opaque LSA Option 3101The OSPF Not-So-Stubby Area (NSSA) Option 3623Graceful OSPF Restart The following values are the maximum limits enforced by the code. Maximum number of Areas (per router): 32 Maximum number of Interfaces (per area): 100 Maximum number of Interfaces (per router): 32 x 100 (Limited only by max. num of IPv4 interfaces = 4096) Maximum number of Link State Database entries (per router): 96K Maximum number of neighbors/adjacencies (per router): 254 Maximum number of neighbors/adjacencies (per area): 128 Maximum number of routes (per router): 96K Maximum number of OSPFv2- ECMP gateways (per destination): 4 Max number of OSPFv2 Sessions: 1 The following values are the tested limits with functionally verified (stress test). On OS6850 ABR routers: Max number of IP Routes on OS6850 router: 12K Max number of OSPFv2 Routes on OS6850 router: 12K Max number of OSPFv2 Interfaces on OS6850 ABR: 48 Max number of OSPFv2 Areas on OS6850 ABR: 6 Max number of OSPFv2 Adjacencies on OS6850 ABR: 48 Max number of LSAs on OS6850 ABR: 12K Tested number of OSPFv2- ECMP gateways (per destination): 4 Max number of OSPFv2 Sessions: 1 On OS6850 non-ABR routers: Max number of IP Routes on OS6850 router: 96K Max number of OSPFv2 Routes on OS6850 router: 96K Max number of OSPFv2 Interfaces on OS6850 non-ABR: 27 Max number of OSPFv2 Areas on OS6850 non-ABR: 6 Max number of OSPFv2 Adjacencies on OS6850 non-ABR: 27 Max number of LSAs on OS6850 non-ABR: 24K Tested number of OSPFv2- ECMP gateways (per destination): 4 Max number of OSPFv2 Sessions: 1 Notes: Please note that, the above OSPFv2 specifications may vary depending on the available system resources, and/or customer specific networking requirements & configurations. Please also note that, depending on the number of Areas, Interfaces, Adjacencies, and Neighbors configured, the maximum number of routes may vary. Please contact our customer Service & Support team, should your required specifications fall between "the limits as enforced by the code" and "the limits as functionally tested".

OSPFv2 Specifications

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 455 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OSPFv2 Defaults
Parameter Description Enables OSPF. Enables an area. Enables an interface. Enables OSPF redistribution. Sets the overflow interval value. Assigns a limit to the number of External Link-State Database (LSDB) entries. Configures timers for Shortest Path First (SPF) calculation. Creates or deletes an area default metric. Default Value/Comments Disabled Disabled Disabled Disabled 0 -1 Delay: 5 Hold: 10 ToS: 0 Type: OSPF Cost: 1 40 seconds (broadcast and point-to-point) 120 seconds (NBMA and point-to-multipoint) 10 seconds (broadcast and point-to-point) 30 seconds (NBMA and point-to-multipoint) 1 120 seconds 1 5 seconds 1 second Broadcast Disabled

Configures OSPF interface dead interval. Configures OSPF interface hello interval. Configures the OSPF interface cost. Configures the OSPF poll interval. Configures the OSPF interface priority. Configures OSPF interface retransmit interval. Configures the OSPF interface transit delay. Configures the OSPF interface type. Configures graceful restart on switches

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 456 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OSPFv3 Specifications
RFCs Supported 2740 -OSPF for IPv6 1826 - IP Authentication Header 1827 - IP Encapsulating Security Payload 2553 - Basic Socket Interface Extensions for IPv6 2373 - IPv6 Addressing Architecture 2374 - An IPv6 Aggregatable Global Unicast Address Format 2460 - IPv6 base specification draft-ietf-ospf-ospfv3-graceful-restart-xx.txt OSPFv3 Graceful Restart draft-ietf-ospf-ospfv3-mibxx.txtManagement Information Base for OSPFv3 draft-ietf-ospf-ospfv3-update-00.txtOSPF for IPv6 draft-ietf-ospf-ospfv3-auth-05.txtAuthentication/ Confidentiality for OSPFv3 draft-ietf-ospf-ospfv3-mib-08.txtMIB TBS TBS TBS TBS TBS TBS TBS

Internet Drafts Supported

Maximum number of Areas (per router) Maximum number of Interfaces (per router) Maximum number of Link State Database entries (per router) Maximum number of adjacencies (per router) Maximum number of ECMP gateways (per destination) Maximum number of neighbors (per router) Maximum number of routes (per router) Notes: Please note that, the above OSPFv3 specifications may vary depending on the available system resources, and/or customer specific networking requirements & configurations. Please also note that, depending on the number of Areas, Interfaces, Adjacencies, and Neighbors configured, the maximum number of routes may vary. Please contact our customer Service & Support team, should your required specifications fall between "the limits as enforced by the code" and "the limits as functionally tested".

OSPFv3 Defaults
Parameter Description Enables OSPFv3 Configures timers for Shortest Path First (SPF) calculation. Creates or deletes an area default metric. Configures OSPF interface dead interval. Configures OSPF interface hello interval. Configures the OSPF interface cost. Configures the OSPF poll interval. Configures the OSPF interface priority. Configures OSPF interface retransmit interval. Configures the OSPF interface transit delay. Configures the OSPF interface type. Configures graceful restart on switches Default Value/Comments Enabled Delay: 5 Hold: 10 Enabled and type of area is normal TBS TBS TBS TBS TBS TBS TBS TBS Interval 120 Helper: enabled Helper-strict-lsa-checking: Enabled 0 Metric: 0

Controls the route-tag used for ASE routes Creates an OSPF routes for directly connected hosts

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 457 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OSPF Overview
Open Shortest Path First routing (OSPF) is a shortest path first (SPF), or link-state, protocol. OSPF is an interior gateway protocol (IGP) that distributes routing information between routers in a Single Autonomous System (AS). OSPF chooses the least-cost path as the best path. Each participating router distributes its local state (i.e., the routers usable interfaces, local networks, and reachable neighbors) throughout the AS by flooding. In a link-state protocol, each router maintains a database describing the entire topology. This database is built from the collected link state advertisements of all routers. Each multi-access network that has at least two attached routers has a designated router and a backup designated router. The designated router floods a link state advertisement for the multi-access network. When a router starts, it uses the OSPF Hello Protocol to discover neighbors. The router sends Hello packets to its neighbors, and in turn receives their Hello packets. On broadcast and point-to-point networks, the router dynamically detects its neighboring routers by sending Hello packets to a multicast address. On non-broadcast and point-to-multipoint networks, some configuration information is necessary in order to configure neighbors. On all networks (broadcast or nonbroadcast), the Hello Protocol also elects a designated router for the network.

The router will attempt to form full adjacencies with all of its newly acquired neighbors. Only some pairs, however, will be successful in forming full adjacencies. Topological databases are synchronized between pairs of fully adjacent routers. Adjacencies control the distribution of routing protocol packets. Routing protocol packets are sent and received only on adjacencies. In particular, distribution of topological database updates proceeds along adjacencies. Link state is also advertised when a routers state changes. A routers adjacencies are reflected in the contents of its link state advertisements. This relationship between adjacencies and link state allows the protocol to detect downed routers in a timely fashion. Link state advertisements are flooded throughout the AS. The flooding algorithm ensures that all routers have exactly the same topological database. This database consists of the collection of link state advertisements received from each router belonging to the area. From this database each router calculates a shortest-path tree, with itself as root. This shortest-path tree in turn yields a routing table for the protocol.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 458 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OSPF Areas
OSPF allows collections of contiguous networks and hosts to be grouped together as an area. Each area runs a separate copy of the basic link-state routing algorithm (usually called SPF). This means that each area has its own topological database.

An areas topology is visible only to the members of the area. Conversely, routers internal to a given area know nothing of the detailed topology external to the area. This isolation of knowledge enables the protocol to reduce routing traffic by concentrating on small areas of an AS, as compared to treating the entire AS as a single link-state domain. Areas cause routers to maintain a separate topological database for each area to which they are connected. (Routers connected to multiple areas are called area border routers). Two routers belonging to the same area have identical area topological databases. Different areas communicate with each other through a backbone. The backbone consists of routers with contacts between multiple areas. A backbone must be contiguous (i.e., it must be linked to all areas). The backbone is responsible for distributing routing information between areas. The backbone itself has all of the properties of an area. The topology of the backbone is invisible to each of the areas, while the backbone itself knows nothing of the topology of the areas. All routers in an area must agree on that areas parameters. Since a separate copy of the link-state algorithm is run in each area, most configuration parameters are defined on a per-router basis. All routers belonging to an area must agree on that areas configuration. Misconfiguration will keep neighbors from forming adjacencies between themselves, and OSPF will not function.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 459 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Classification of Routers
When an AS is split into OSPF areas, the routers are further divided according to function into the following four overlapping categories: Internal routers: A router with all directly connected networks belonging to the same area. These routers run a single copy of the SPF algorithm. Area border routers: A router that attaches to multiple areas. Area border routers run multiple copies of the SPF algorithm, one copy for each attached area. Area border routers condense the topological information of their attached areas for flooding to other areas. Backbone routers: A router that has an interface to the backbone. This includes all routers that inter-face to more than one area (i.e., area border routers). However, backbone routers do not have to be area border routers. Routers with all interfaces connected to the backbone are considered to be internal routers. AS boundary routers: A router that exchanges routing information with routers belonging to other Autonomous Systems. Such a router has AS external routes that are advertised throughout the Autonomous System. Every router in the AS knows the path to each AS boundary router. This classification is completely independent of the previous classifications (i.e., internal, area border, and backbone routers). AS boundary routers may be internal or area border routers, and may or may not participate in the backbone.

Virtual Links
It is possible to define areas in such a way that the backbone is no longer contiguous. (This is not an ideal OSPF configuration, and maximum effort should be made to avoid this situation.) In this case the system administrator must restore backbone connectivity by configuring virtual links. Virtual links can be configured between any two-backbone routers that have a connection to a common non-backbone area. The protocol treats two routers joined by a virtual link as if an unnumbered point-to-point network connected them. The routing protocol traffic that flows along the virtual link uses intra-area routing only. The physical connection between the two routers is not managed by the network administrator (i.e., there is no dedicated connection between the routers as there is with the OSPF backbone).

In the above diagram, Router A and Router B are connected via a virtual link in Area 1, which is known as a transit area.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 460 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Stub Areas
OSPF allows certain areas to be configured as stub areas. A stub area is an area with routers that have no AS external Link State Advertisements (LSAs). In order to take advantage of the OSPF stub area support, default routing must be used in the stub area. This is accomplished by configuring only one of the stub areas border routers to advertise a default route into the stub area. The default routes will match any destination that is not explicitly reachable by an intra-area or inter-area path (i.e., AS external destinations).

Area 1 and Area 3 could be configured as stub areas. The OSPF protocol ensures that all routers belonging to an area agree on whether the area has been configured as a stub. This guarantees that no confusion will arise in the flooding of AS external advertisements. Two restrictions on the use of stub areas are: Virtual links cannot be configured through stub areas. AS boundary routers cannot be placed internal to stub areas.

Not-So-Stubby-Areas
NSSA, or not-so-stubby area, is an extension to the base OSPF specification and is defined in RFC 1587. An NSSA is similar to a stub area in many ways: AS-external LSAs are not flooded into an NSSA and virtual links are not allowed in an NSSA. The primary difference is that selected external routing information can be imported into an NSSA and then redistributed into the rest of the OSPF routing domain. These routes are imported into the NSSA using a new LSA type: Type-7 LSA. Type-7 LSAs are flooded within the NSSA and are translated at the NSSA boundary into ASexternal LSAs so as to convey the external routing information to other areas. NSSAs enable routers with limited resources to participate in OSPF routing while also allowing the import of a selected number of external routes into the area. For example, an area, which connects to a small external routing domain running RIP, may be configured as an NSSA. This will allow the import of RIP routes into this area and the rest of the OSPF routing domain and at the same time, prevent the flooding of other external routing information (learned, for example, through RIP) into this area. All routers in an NSSA must have their OSPF area defined as an NSSA. To configure otherwise will ensure that the router will be unsuccessful in establishing an adjacent in the OSPF domain.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 461 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Totally Stubby Areas

In Totally Stubby Areas the ABR advertises a default route to the routers in the totally stubby area but does not advertise any inter-area or external LSAs. As a result, routers in a totally stubby area know only the routes for destination networks in the stub area and have a default route for any other destination outside the stub. Note. Virtual links cannot be configured through totally stubby areas. The router memory is saved when using stub area networks by filtering Type 4 and 5 LSAs. This concept has been extended with Totally Stubby Areas by filtering Type 3 LSAs (Network Summary LSA) in addition to Type 4 and 5 with the exception of one single Type 3 LSA used to advertise a default route within the area. The following is an example of a simple totally stubby configuration with Router B being an ABR between the backbone area 0 and the stub area 1. Router A is in area 1.1.1.1, totally stubby area:

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 462 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Equal Cost Multi-Path (ECMP) Routing

Using information from its continuously updated databases, OSPF calculates the shortest path to a given destination. Shortest path is determined from metric values at each hop along a path. At times, two or more paths to the same destination will have the same metric cost. In the network illustration below, there are two paths from Source router A to Destination router B. One path traverses two hops at routers X and Y and the second path traverses two hops at M and N. If the total cost through X and Y to B is the same as the cost via M and N to B, then these two paths have equal cost. In this version of OSPF both paths will be stored and used to transmit data.

Delivery of packets along equal paths is based on flows rather than a round-robin scheme. Equal cost is determined based on standard routing metrics. However, other variables, such as line speed, are not considered. So it is possible for OSPF to decide two paths have an equal cost even though one may contain faster links than another.

Non Broadcast OSPF Routing

OSPF can operate in two modes on non-broadcast networks: NBMA and point-to-multipoint. The interface type for the corresponding network segment should be set to non-broadcast or point-to-multipoint, respectively. For non-broadcast networks neighbors should be statically configured. For NBMA neighbors the eligibility option must be enabled for the neighboring router to participate in Designated Router (DR) election. For the correct working of an OSPF NBMA network, a fully meshed network is mandatory. Also, the neighbor eligibility configuration for a router on every other router should match the routers interface priority configuration.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 463 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Graceful Restart on Switches with Redundant Management

OmniSwitch 6850 chassis with two units in a stacking configuration can support redundancy where if the primary management unit fails or goes offline for any reason, the secondary management unit is instantly notified. The secondary management unit automatically assumes the primary role. This switch between the primary and secondary management units is known as takeover. When a takeover occurs, which can be planned (e.g., the users performs the takeover) or unplanned (e.g., the primary management unit unexpectedly fails), an OSPF router must reestablish full adjacencies with all its previously fully adjacent neighbors. This time period between the restart and the reestablishment of adjacencies is termed graceful restart. In the network illustration below, a helper router, Router Y, monitors the network for topology changes. As long as there are none, it continues to advertise its LSAs as if the restarting router, Router X, had remained in continuous OSPF operation (i.e., Router Ys LSAs continue to list an adjacency to Router X over network segment S, regardless of the adjacencys current synchronization state.)

If the restarting router, Router X, was the Designated Router (DR) on network segment S when the helping relationship began, the helper neighbor, Router Y, maintains Router X as the DR until the helping relationship is terminated. If there are multiple adjacencies with the restarting Router X, Router Y will act as a helper on all other adjacencies. Note. OSPFv3 will implement OSPFv3 graceful restart both as a restarting system and as a helper.

Interface Authentication
OSPF allows for the use of authentication on configured interfaces. When authentication is enabled, only neighbors using the same type of authentication and the matching passwords or keys can communicate. There are two types of authentication: simple and MD5. Simple authentication requires only a text string as a password, while MD5 is a form of encrypted authentication that requires a key and a password. Both types of authentication require the use of more than one command.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 464 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IS-IS
Intermediate System-to-Intermediate System (IS-IS) is an International Organization for Standardization (ISO) dynamic routing specification. IS-IS is a shortest path first (SPF), or link state protocol. It is an interior gateway protocol (IGP) that distributes routing information between routers in a single Autonomous System (AS) in IP as well as in OSI environments. IS-IS chooses the least-cost path as the best path. IS-IS is suitable for complex networks with large number of routers since it provides faster convergence where multiple flows to a single destination can be forwarded through one or more interfaces simultaneously. IS-IS is also an ISO Connectionless Network Protocol (CLNP). It communicates with its peers using the Connectionless Mode Network Service (CLNS) PDU packets, which means that even in an IP-only environment the IS-IS router must have an ISO address. ISO network-layer addressing is done through Network Service Access Point (NSAP) addresses that identify any system in the OSI network.

IS-IS Specifications
RFCs Supported 1142-OSI IS-IS Intra-domain Routing Protocol 1195OSI IS-IS for Routing in TCP/IP and Dual Environments 3 70 70 70 255 24000 12000 12000

Maximum number of areas (per router) Maximum number of L1 adjacencies per interface (per router) Maximum number of L2 adjacencies per interface (per router) Maximum number of IS-IS interfaces (per router) Maximum number of Link State Packet entries (per adjacency) Maximum number of IS-IS routes Maximum number of IS-IS L1 routes Maximum number of IS-IS L2 routes

IS-IS Defualts Table

The following table shows the default settings of the configurable IS-IS parameters.
Parameter Description Administrative status of IS-IS Global level of IS-IS IS-IS authentication type Global CSNP authentication Global Hello authentication Global PSNP authentication Link State Packet (LSP) timer LSP wait interval Default Value/Comments Disabled Level-1/2 None Enabled Enabled Enabled 1200 seconds 5 seconds (max-wait) 0 (initial-wait) 1 (second-wait) 10 seconds (max-wait) 1000 milliseconds (initial-wait) 1000 milliseconds (secondwait) disabled (Overload state) infinity (timeout interval) disabled (Overload state after bootup) infinity (timeout interval) disabled enabled 60 seconds Disabled None Enabled

SPF time interval

IS-IS Overload state IS-IS Overload state after bootup IS-IS graceful restart IS-IS graceful restart helper mode IS-IS system wait-time IS-IS adjacency check configuration Authentication type (per IS-IS level) Hello authentication (per IS-IS level)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 465 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

CSNP authentication (per IS-IS level) PSNP authentication (per IS-IS level) Wide metrics (per IS-IS level) IS-IS interface status IS-IS interface type Hello authentication (per interface) CSNP time interval (per interface) IS-IS level (per interface) LSP time interval (per interface) IS-IS passive interface Retransmission time of LSP on a point-to-point interface Hello authentication for the specified IS-IS level of an interface Hello time interval for the specified IS-IS level of an interface Number of missing Hello PDUs from a neighbor Metric value of the specified IS-IS level of the interface IS-IS passive interface (per IS-IS level) Interface level priority

Enabled Enabled Disabled Disabled Broadcast None 10 seconds (broadcast) 5 seconds (point-to-point) Level-1/2 100 milliseconds Disabled 5 Seconds None designated routers: 3 seconds non-designated routers: 9 seconds 3 10 Disabled 64

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 466 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IS-IS Overview
IS-IS is an SPF or link state protocol. IS-IS is also an IGP that distributes routing information between routers in a single AS. It supports pure IP and OSI environments, as well as dual environments (both IP and OSI). However, it is deployed extensively in IP-only environments. IS-IS uses a two-level hierarchy to support large routing domains. A large routing domain may be administratively divided into areas, with each router residing in exactly one area. Routing within an area is referred to as Level-1 routing. A Level-1 Intermediate System (IS) keeps track of routing within its own area. Routing between areas is referred to as Level-2 routing. A Level-2 IS keeps track of paths to destination areas. IS-IS identifies a device in the network by the NSAP address. NSAP address is a logical point between network and transport layers. It consists of the following three fields: NSEL fieldThe N-Selector (NSEL) field is the last byte and it must be specified as a single byte with two hex digits preceded by a period (.). Normally, the NSEL value is set to 00.The NSAP address with its NSEL set to 00 is called Network Entity Title (NET). A NET implies the network layer address of IS-IS. System ID This ID occupies the 6 bytes preceeding the NSEL field. It is customary to use either a MAC address from the router (for Integrated IS-IS) or an IP address (for example, the IP address of a loopback interface) as part of the system ID. Area IDThe area ID occupies the rest of NSAP address. When a router starts, it uses the IS-IS Hello protocol to discover neighbors and establish adjacencies. The router sends Hello packets through all IS-IS-enabled interfaces to its neighbors, and in turn receives Hello packets. In a broadcast network, the Hello protocol elects a Designated Intermediate System (DIS) for the network.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 467 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Separate DISs are elected for Level-1 and Level-2 routing. Election of the DIS is based on the highest interface priority, the default value of which is 64. Priority can also be manually configured, the range being 1127. In case of a tie, the router with the highest Subnetwork Point Of Attachment (SNPA) address (usually the MAC address) for that interface is elected as the DIS. Routers that share common data links will become IS-IS neighbors if their Hello packets contain data that meet the requirements for forming an adjacency. The requirements may differ slightly depending on the type of media being used, which is either pointto-point or broadcast. The primary criteria for forming adjacencies are authentication match, IS-type, and MTU size. Adjacencies control the distribution of routing protocol packets. Routing protocol packets are sent and received only on adjacencies. In particular, distribution of topological database updates proceeds along adjacencies. After establishing adjacencies, routers will build a link-state packet (LSP) based upon their local interfaces that are configured for IS-IS and prefixes learned from other adjacent routers. Routers flood LSPs to all adjacent neighbors except the neighbor from which they received the same LSP. Routers construct their link-state database from these packets. The link state is also advertised when a routers state changes. A routers adjacencies are reflected in the contents of its link state packets. This relationship between adjacencies and link state allows the protocol to detect downed routers in a timely fashion. Link state packets are flooded throughout the AS. The flooding algorithm ensures that all routers have exactly the same topological database. This database consists of a collection of link state packets received from each router belonging to the area. From this database, each router calculates the shortest-path tree, with itself as the root. This shortest-path tree, in turn, yields a routing table for the protocol.

IS-IS Packet Types

IS-IS transmits data in little chunks known as packets. There are four packet types in IS-IS. They are: Intermediate System-to-Intermediate System Hello (IIH)Used by routers to detect neighbors and form adjacencies. Link State Packet (LSP)Contains all the information about adjacencies, connected IP prefixes, OSI end system, area address, etc. There are four types of LSPs: Level-1 pseudo node, Level-1 non-pseudo node, Level-2 pseudo node, and Level-2 non-pseudo node. Complete Sequence Number PDU (CSNP)Contains a list of all the LSPs from the current database. CSNPs are used to inform other routers about LSPs that may be outdated or missing from their own database. This ensures that all routers have the same information and are synchronized. Partial Sequence Number PDU (PSNP)Used to request an LSP(s) and acknowledge receipt of an LSP(s).

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 468 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IS-IS Areas
IS-IS allows collections of contiguous networks and hosts to be grouped together as an area. Each area runs a separate copy of the basic link state routing algorithm (usually called SPF). This means that each area has its own topological database as explained in the previous section.

An areas topology is visible only to the members of that area. Routers inside a given area do not know the detailed topology outside the area. This isolation of knowledge enables the protocol to reduce routing traffic by concentrating on small areas of an AS, as compared to treating the entire AS as a single link state domain. In IS-IS, the router belongs entirely to a single area. When an AS is split into IS-IS areas, the routers are classified into the following three categories: Level-1 routersThese are Intra-area routers and form relationship with other Level-1 or Level-1/2 routers within the same area. Level-1/2 routersThese routers form relationship with other Level-1, Level-2, or Level-1/2 routers. They are used to connect Inter-area routers with Intra-area routers. Level-2 routersThese are Inter-area routers and form relationship with other Level-2 or Level-1/2 routers These Level capabilities can be defined globally on a router or on specific interfaces. Since a separate copy of the link state algorithm is run in each area, most configuration parameters are defined on a perrouter basis. All routers belonging to an area must agree on that areas configuration. Misconfiguration will keep neighbors from forming adjacencies between themselves, and IS-IS will not function. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 469 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Graceful Restart on Stacks with Redundant Switches

OmniSwitch 6850 stacks with two or more switches support redundancy, where if the primary switch fails or goes offline, the secondary switch is instantly notified. The secondary switch automatically assumes the primary role. This transition from secondary to primary is known as takeover. When the router is in the graceful restart mode, it informs its neighbors of the restart. The IS-IS Hello (IIH) messages are modified to signal a graceful restart request. The neighbors respond by sending back their own IIHs with an acknowledgement of the restart, along with a "Remaining Time" value to indicate how long they will wait for a restart. The neighbors also continue to send out LSPs with the restarting router still listed as an adjacency, thus avoiding SPF calculations and enabling traffic to flow to the router from neighbors. The restarting router continues to forward LSPs using its pre-restart forwarding tables. When graceful restart is enabled, the router can either be a helper or a restarting router, or both. In the current release, only the helper mode is supported. If a helper is enabled on a neighbor, it begins the Link State Database synchronization process. They send their Complete Sequence Number PDUs (CSNPs) to the restarting router. The restarting router can then determine the LSPs it needs and request them. After it receives all requested LSPs, the database is synchronized. Note. When graceful restart is enabled on the router, the helper mode is automatically enabled by default. When the graceful restart timer expires, the restarting router runs the SPF calculation to re-compute IS-IS routes. Only then does it flood LSPs to neighbors and comes back to normal protocol behavior. In the network illustration below, a helper router, Router Y, monitors the network for topology changes. As long as there are none, it continues to advertise its LSPs as if the restarting router, Router X, had remained in continuous IS-IS operation (i.e., Router Ys LSPs continue to list an adjacency to Router X over network segment S, regardless of the adjacencys current synchronization state).

If the restarting router, Router X, is identified as the Designated Router (DIS) on the network segment S at the beginning of the helping relationship, the helper neighbor, Router Y, will maintain Router X as the DIS until the helping relationship is terminated. If there are multiple adjacencies with the restarting Router X, Router Y will act as a helper on all other adjacencies.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 470 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IS-IS Application Example

The following diagram is a simple IS-IS network. It uses two routers, each with an area. Each router is a L1-L2 capable router and can communicate with different areas.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 471 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

BGP
The Border Gateway Protocol (BGP) is an exterior routing protocol that guarantees the loop-free exchange of routing information between autonomous systems. The Alcatel-Lucent implementation supports BGP version 4 as defined in RFC 1771. The Alcatel-Lucent implementation of BGP is designed for enterprise networks, specifically for border routers handling a public network connection, such as the organizations Internet Service Provider (ISP) link. Up to 65,000 route table entries and next hop routes can be supported by BGP. Note: The BGP terms peer and neighbor is used interchangeably. On OmniSwitch devices in a redundant CMM configuration, during a CMM takeover/failover, interdomain routing is disrupted. Alcatel-Lucent Operating System BGP needs to retain forwarding information, also help a peering router performing a BGP restart to support continuous forwarding for inter-domain traffic flows by following the BGP graceful restart mechanism. By default, BGP graceful restart is enabled.

BGP Specifications
RFCs Supported 1771A Border Gateway Protocol 4 (BGP-4) 2385Protection of BGP Sessions via the TCP MD5 Signature Option 2439BGP Route Flap Damping 2842Capabilities Advertisement with BGP-4 2042Registering New BGP Attribute Types 1997BGP Communities Attribute 1998An Application of the BGP Community Attribute in Multi-Home Routing 1966BGP Route Reflection: An Alternative to Full Mesh IBGP 1965Autonomous System Confederations for BGP 1773Experience with BGP-4 Protocol 1774BGP-4 Protocol Analysis 1657Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) Using SMIv2 Origin, AS Path, Next Hop, MED, Local Preference, Atomic Aggregate, Aggregator, Community, Originator ID, Cluster List 8 30,000 1 to 65535 0 to 4294967295 0 to 65535 0 to 4294967295

BGP Attributes Supported

Maximum BGP Peers per Router Maximum number of routes supported Range for AS Numbers Range of Local Preference Values Range for Confederation IDs Range for MED Attribute

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 472 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

BGP Overview
BGP (Border Gateway Protocol) is a protocol for exchanging routing information between gateway hosts in a network of autonomous systems. BGP is the most common protocol used between gateway hosts on the Internet. The routing table exchanged between hosts contains a list of known routers, the addresses they can reach, and attributes associated with the path. The OmniSwitch implementation supports BGP-4, the latest version of BGP, as defined in RFC 1771. BGP is a distance vector protocol, like the Routing Information Protocol (RIP). It does not require periodic refresh of its entire routing table, but messages are sent between BGP peers to ensure a connection is active. A BGP speaker must retain the current routing table of its peers during the life of a connection. Hosts using BGP communicate using the Transmission Control Protocol (TCP) on port 179. On connection start, BGP peers exchange complete copies of their routing tables, which can be quite large. However, only changes are exchanged after startup, which makes long running BGP sessions more efficient than shorter ones. BGP-4 lets administrators configure cost metrics based on policy statements. BGP communicates with other BGP routers in the local AS using Internal BGP (IBGP). BGP-4 makes it easy to use Classless Inter-Domain Routing (CIDR), which is a way to increase addresses within the network beyond the current Internet Protocol address assignment scheme. BGPs basic unit of routing information is the BGP path, which is a route to a certain set of CIDR prefixes. Paths are tagged with various path attributes, of which the most important are AS_PATH and NEXT_HOP. One of BGP-4s most important functions is loop detection at the autonomous system level, using the AS_PATH attribute. The AS_PATH attribute is a list of ASs being used for data transport. The syntax of this attribute is made more complex by its need to support path aggregation, when multiple paths are collapsed into one to simplify further route advertisements. A simplified view of AS_PATH is that it is the list of Autonomous Systems that a route goes through to reach its destination. Loops are detected and avoided by checking for your own AS number in AS_Paths received from neighboring Autonomous Systems. An OmniSwitch using BGP could be placed at the edge of an enterprise network to handle downstream Internet traffic. However, a router using BGP should not be placed on the public Internet to handle upstream traffic. The BGP implementation in an OmniSwitch can handle up to 32 peers, but ideally should be configured with 2 peers. An example of such a configuration would be two (2) paths to the Internet, or a dual-homed network.

BGP is intended for use in networks with multiple autonomous systems. It is not intended to be used as a LAN routing protocol, such as RIP or Open Shortest Path First (OSPF). In addition, when BGP is used as an internal routing protocol, it is best used in autonomous systems with multiple exit points as it includes features that help routers decide among multiple exit paths. BGP uses TCP as its transport protocol, eliminating the need for it to implement mechanisms for updating fragmentation, retransmission, acknowledgment, and sequencing information.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 473 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Autonomous Systems (ASs)

Exterior routing protocols were created to control the expansion of routing tables and to provide a more structured view of the Internet by segregating routing domains into separate administrations, called Autonomous Systems (ASs). Each AS has its own routing policies and unique Interior Gateway Protocols (IGP). More specifically, an AS is a set of routers that has a single routing policy, runs under a single technical administration, and that commonly utilizes a single IGP (though there could be several different IGPs intermeshed to provide internal routing). To the rest of the networking world, an AS appears as a single entity. The diagram below demonstrates the relationship of BGP and ASs:

Each AS has a number assigned to it by an Internet Registry, much like an IP address. BGP is the standard Exterior Gateway Protocol (EGP) used for exchanging information between ASs. The main difference between routing within an AS (IGP) and routing outside of an AS (EGP) is that IGP polices tend to be set due to traffic concerns and technical demands, while EGP polices are set more on business relationships between corporate entities.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 474 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Internal vs. External BGP

Although BGP is an exterior gateway protocol, it can still be used inside an AS as a pipe to exchange BGP updates. BGP connections inside an AS are referred to as Internal BGP (IBGP), while BGP connections between routers in separate ASs are referred to as External BGP (EBGP). ASs with more than one connection to the outside world is called multi-homed transit ASs, and can be used to transit traffic by other ASs. Routers running IBGP are called transit routers when they carry the transit traffic through an AS. For example, the following diagram illustrates the use of IBGP in a multi-homed AS:

In the above diagram, AS 100 and AS 200 can send and receive traffic via AS 300. AS 300 has become a transit AS using IBGP between Router B and Router C. Not all routers in an AS need to run BGP; in most cases, the internal routers use an IGP (such as RIP or OSPF) to manage internal AS routing. This alleviates the number of routes the internal non-transit routers must carry. In the above diagram, AS 100 and AS 200 can send and receive traffic via AS 300. AS 300 has become a transit AS using IBGP between Router B and Router C. Not all routers in an AS need to run BGP; in most cases, the internal routers use an IGP (such as RIP or OSPF) to manage internal AS routing. This alleviates the number of routes the internal non-transit routers must carry.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 475 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Communities
A community is a group of destinations that share some common property. A community is not restricted to one network or one autonomous system. Communities are used to simplify routing policies by identifying routes based on a logical property rather than an IP prefix or an AS number. A BGP speaker can use this attribute in conjunction with other attributes to control which routes to accept, prefer, and pass on to other BGP neighbors. Communities are not limited by physical boundaries, and routers in a community can belong to different ASs. For example, a community attribute of no export could be added to a route, preventing it from being exported, as shown:

In the above example, Route A is not propagated to AS 100 because it belongs to a community that is not to be exported by a speaker that learns it. A route can have more than community attribute. A BGP speaker that sees multiple community attributes in a route can act on one, several, or all of the attributes. Community attributes can be added or modified by a speaker before being passed on to other peers.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 476 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Route Reflectors
Route reflectors are useful if the internal BGP mesh becomes very large. A route reflector is a concentration router for other BGP peers in the local network, acting as a focal point for internal BGP sessions. Multiple client BGP routers peer with the central route server (the reflector). The router reflectors then peer with each other. Although BGP rules state that routes learned via one IBGP speaker cannot be advertised to another IBGP speaker, route reflection allows the router reflector servers to reflect routes, thereby relaxing the IBGP standards. Since the router clients in this scenario only peer with the router reflector, the session load per router is significantly reduced. The following picture demonstrates this concept:

In the diagram above, Clients 1, 2, and 3 peer with Reflector 1, and Clients 4, 5, and 6 peer with Reflector 2. Reflector 1 and 2 peer with each other. This allows each BGP speaker to maintain only one BGP session, rather than a possible seven sessions, as demonstrated below:

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 477 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

BGP Confederations
Confederations are another way of dealing with large networks with many BGP speakers. Like route reflectors, confederations are recommended when speakers are forced to handle large numbers of BGP sessions at the same time. Confederations are sub ASs within a larger AS. Inside each sub AS, all the rules of IBGP apply. Since each sub AS has its own AS number, EBGP must be used to communicate between sub ASs. The following example demonstrates a simple confederation set up:

AS 100 is now a confederation consisting of AS 1001 and AS 1002. Even though EBGP is used to communicate between AS 1001 and 1002, the entire confederation behaves as though it were using IBGP. When crossing the sub AS boundaries, the sub AS attributes are preserved.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 478 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Policies
Routing policies enable route classification for importing and exporting routes. The goal of routing policies is to control traffic flow. Policies can be applied to egress and ingress traffic. Policies act as filters to either permit or deny specified routes that are being learned or advertised from a peer. The following diagram demonstrates this concept:

AS 100 is learning routes from AS 200 and AS 300. However, there is an incoming AS Path policy at the edge of AS 100 that prevents routes that originate in AS 300 from being propagated throughout AS 100. There are four main policy types: AS Path: This policy filters routes based on AS path lists. An AS path list notes all of the ASs the route travels to reach its destination. Community Lists: Community list policies filter routes based on the community to which a route belongs. Communities can affect route behavior based on the definition of the community. Prefix Lists: Prefix list policies filter routes based on a specific network address, or a range of network addresses. Route Maps: Route map policies filter routes by amalgamating other policies into one policy. It is a way of combining many different filter options into one policy.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 479 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Regular Expressions
Regular expressions are used to identify AS paths for purposes of making routing decisions. In this context, an AS path is a list of one or more unsigned 16-bit AS numbers, in the range 1 through 65535. An ordinary pattern match string looks like: 100 200 Which matches any AS path containing the Autonomous System number 100 followed immediately by 200, anywhere within the AS path list. It would not match an AS path which was missing either number, or where the numbers did not occur in the correct order, or where the numbers were not adjacent to one another. Special pattern matching characters (sometimes called meta-characters) add the ability to specify that part of the pattern must match the beginning or end of the AS path list, or that some arbitrary number of AS numbers should match, etc. The following table defines the meta-characters used in the BGP implementation.
^ 123 . ? + * ( | ) [ ] $ ,Matches the beginning of the AS path list. Matches the AS number 123. Matches any single AS number. Matches zero or one occurrence of the previous token, which must be an AS number, a dot, an alternation, or a range. Matches one or more occurrences of the previous token, which must be an AS number, a dot, an alternation, or a range. Matches zero or more occurrences of the previous token, which must be an AS number, a dot, an alternation, or a range. Begins an alternation sequence of AS numbers. It matches any AS number listed in the alternation sequence. Separates AS numbers in an alternation sequence. Ends an alternation sequence of AS numbers. Begin a range pair consisting of two AS numbers separated by a dash. It matches any AS number within that inclusive range. Separates the endpoints of a range. Ends a range pair. Matches the end of the AS path list. Commas, underscores (_), and spaces are ignored.

The regular expressions configured in the router are compared against an incoming AS path list one at a time until a match is found, or until all patterns have been unsuccessfully matched. Unlike some implementations, which use a characterbased pattern matching logic, the BGP implementation treats AS numbers as single tokens, providing two benefits: It makes writing (and reading) policies much easier. It enables the router to begin using the policies more quickly after startup.

The Route Selection Process

Several metrics are used to make BGP routing decisions. These metrics include the routes local preference, the AS Path, and the Multi-Exit Discriminator (MED). These metrics are organized into a hierarchy such that if a tie results, the next important criteria is used to break the tie until a decision is made for the route path. BGP selects the best path to an autonomous system from all known paths and propagates the selected path to its neighbors. BGP uses the following criteria, in order, to select the best path. If routes are equal at a given point in the selection process, then the next criterion is applied to break the tie. 1 The route with the highest local preference. 2 The route with the fewest autonomous systems listed in its AS Path. 3 The AS path origin. A route with an AS path origin of IGP (internal to the AS) is preferred. Next in preference is a route with an AS path origin of EGP (external to the AS). Least preferred is an AS path that is incomplete. In summary, the path origin preference is as follows: IGP < EGP < Incomplete. 4 The route with the lowest Multi-Exit Discriminator (MED). MEDs are by default compared between routes that are received within the same AS. However, you can configure BGP to consider MED values from external peers. This test is only applied if the local AS has two or more connections, or exits, to a neighbor AS. 5 The route with a closer next hop (with respect to the internal routing distance). 6 The source of the route. A strictly interior route is preferred, next in preference is a strictly exterior route, and third in preference is an exterior route learned from an interior session. In summary, the route source preference is as follows: IGP < EBGP < IBGP. 7 Lowest BGP Router ID: The route whose next hop IP address is numerically lowest.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 480 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Route Dampening
Route dampening is a mechanism for controlling route instability. If a route is enabled and disabled frequently, it can cause an abundance of UPDATE and WITHDRAWN messages to expend speaker resources. Route dampening categorizes a route as either behaved or ill behaved. A well-behaved route shows a high degree of stability over an extended period of time, while an ill behaved route shows a high degree of instability over a short period of time. This instability is also known as flapping. Route dampening can suppress (not advertise) an ill behaved route until it has achieved a certain degree of stability. Route suppression is based on the number of times a route flaps over a period of time. The following diagram illustrates this concept:

Routes 1, 2, and 3 are entering AS 100, but Route 2 (because it is flapping) has exceeded the dampening threshold. It is therefore not propagated into the AS. The dampening threshold and suppression time of a route is determined by various factors.

CIDR Route Notation

Although the router supports CIDR, CIDR route notation is not supported on the CLI command line. For example, in order to enter the route 198.16.10.0/24 you must input 198.16.10.0 255.255.255.0. Some show commands, such as ip bgp policy prefix-list, do use CIDR notation to indicate route prefixes.

Synchronizing BGP and IGP Routes

The default behavior of BGP requires that it must be synchronized with the IGP before BGP may advertise transit routes to external ASs. It is important that your network is consistent about the routes it advertises otherwise traffic can be lost. The BGP rule is that a BGP router should not advertise to external neighbors destinations learned from IBGP neighbors unless those destinations are also known via an IGP. This is known as synchronization. If a router knows about a destination via an IGP, it is assumed that the route has already been propagated inside the AS and internal reach ability is ensured. The consequence of injecting BGP routes inside an IGP is costly. Redistributing routes from BGP into the IGP results in major overhead on the internal routers, and IGPs are really not designed to handle that many routes. The ip bgp synchronization command enables or disables BGP internal synchronization. Enabling this command will force all routers (BGP and non-BGP) in an AS to learn all routes learned over external BGP. Learning the external routes forces the routing tables for all routers in an AS to be synchronized and ensure that all routes advertised within an AS are known to all routers (BGP and non-BGP). However, since routes learned over external BGP can be numerous, enabling synchronization can place an extra burden on non-BGP routers.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 481 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Controlling Route Flapping Through Route Dampening

Route dampening minimizes the effect of flapping routes in a BGP network. Route flapping occurs when route information is updated erratically, such as when a route is announced and withdrawn at a rapid rate. Route flapping can cause problems in networks connected to the Internet, where route flapping will involve the propagation of many routes. Route dampening suppresses flapping routes and designates them as unreachable until they flap at a lower rate. You can configure route dampening to adapt to the frequency and duration of a particular route that is flapping. The more a route flaps during a period of time, the longer it will be suppressed. Each time a route flaps (i.e., withdrawn from the routing table), its instability metric is increased by 1. Once a routes instability metric reaches the suppress value, it is suppressed and no longer advertised. The instability metric may continue to increase even after the route is suppressed. A routes instability metric may be reduced. It is reduced once the route stops flapping for a given period of time. This period of time is referred to as the half-life duration. If a suppressed route does not flap for a given half-life duration, then its instability metric will be cut in half. As long as the route continues to be stable, its instability metric will be reduced until it reaches the reuse value. Once below the reuse value, a route will be re-advertised.

Example: Flapping Route Suppressed, then Unsuppressed

Consider, for example, a route that has started to flap. Once this route starts exhibiting erratic behavior, BGP begins tracking the instability metric for the route. This particular route flaps more than 300 times, surpassing the cutoff value of 300. BGP stops advertising the route; the route is now suppressed. The route continues to flap and its instability metric reaches 1600. Now the route stops flapping. In fact, it does not flap for 5 minutes, which is also the half-life duration defined for BGP routes. The instability metric is reduced to 800. The route remains stable for another 5 minutes and the instability metric is reduced to 400. After another 5 minutes of stability, the routes instability metric is reduced to 200, which is also the defined reuse value. Since the instability metric for the route has dropped below the reuse value, BGP will begin readvertising it again. The following chart illustrates what happens to the described route in the above scenario:

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 482 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Setting Up Route Reflection

BGP requires that all speakers in an autonomous system be fully meshed (i.e., each speaker must have a peer connection to every other speaker in the AS) so that external routing information can be distributed to all BGP speakers in an AS. However, fully meshed configurations are difficult to scale in large networks. For this reason, BGP supports route reflection, a configuration in which one or more speakersroute reflectorshandle intra-AS communication among all BGP speakers. In a fully meshed BGP configuration, a BGP speaker that receives an external route must re-advertise the route to all internal peers. In the illustration below, BGP speaker A receives a route from an external BGP speaker and advertises it to both Speakers B and C in its autonomous system. Speakers B and C do not re-advertise the route to each other so as to prevent routing information loop.

In the above example, Speakers B and C do not re-advertise the external route they each received from Speaker A. However, this fundamental routing rule is relaxed for BGP speakers that are route reflectors.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 483 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

This same configuration using a route reflector would not require that all BGP speakers be fully meshed. One of the speakers is configured to be a route reflector for the group. In this case, the route reflector is Speaker C. When the route reflector (Speaker C) receives route information from Speaker A it advertises the information to Speaker B. This set up eliminates the peer connection between Speakers A and B:

The internal peers of a route reflector are divided into two groups: client peers and non-client peers. The route reflector sits between these two groups and reflects routes between them. The route reflector, its clients, and non-clients are all in the same autonomous system. The route reflector and its clients form a cluster. The client peers do not need to be fully meshed (and therefore take full advantage of route reflection), but the non-client peers must be fully meshed. The following illustration shows a route reflector, its clients within a cluster, and its non-client speakers outside the cluster.

Note that the non-client BGP speakers are fully meshed with each other and that the client speakers in the cluster do not communicate with the non-client speakers.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 484 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

When a route reflector receives a route it, selects the best path based on its policy decision criteria. The internal peers to which the route reflector advertises depends on the source of the route. The table below shows the rules the reflector follows when advertising path information: Route received From Route Advertised To All Clients and Non-Clients External BGP Router All Clients Non-Client Peer All Clients and Non-Clients Client Peer

Working with Communities

Distribution of routing information in BGP is typically based on IP address and AS number. To simplify the control of routing information, autonomous systems can be grouped into communities and routing decisions can be applied based on these communities. Peers are usually grouped in communities when they share attributes other than an IP subset or AS number. For example, certain routers within each AS may always be configured with a particular set of policies. These routers do not share an IP subnet or belong to the same AS but they are functionally similar within their AS. It can be efficient to group such routers into a community so that policies and other parameters can be configured as a group. In this sense a group of ASs, when grouped into a community, can appear to be a single AS to BGP. Separated by a colon (for example, 200:500) communities are identified by using the numbering convention of the AS and the community number, There are a few well known communities defined (in RFC 1997) that do not require the numbering convention. Their community numbers are reserved and thus can be identified by name only. These are listed below: No-export. Routes in this community are advertised within the AS but not beyond the local AS. No-advertise. Routes in this community are not advertised to any peer. No-export-subconfed. Routes in this community are not advertised to any external BGP peer.

Routing Policies
BGP selects routes for subsequent advertisement by applying policies available in a pre-configured local Policy Information database. This support of policy-based routing provides flexibility by applying policies based on the path (i.e. AS path list), community attributes (i.e. community lists), specific destinations (i.e. prefix lists), etc. You could also configure route maps to include all of the above in a single policy. For BGP to do policy-based routing, each BGP peer needs to be tied to inbound and/or outbound policies (direction based on whether routes are being learned or advertised). Each one of the above policies can be assigned as an in-bound or outbound policy for a peer. First, you must create policies that match one of the specified criteria: AS Paths: An AS path list notes the entire ASs the route travels to reach its destination. Community List: Communities can affect route behavior based on the definition of the community. Prefix List: Prefix list policies filter routes based on a specific network address, or a range of network addresses. Route Map: Route map policies filter routes by amalgamating other policies into one policy. Then you must assign these policies to a peer. Policies can be assigned to affect routes learned from the peer, routes being advertised to the peer, or both.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 485 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

RDP
The Router Discovery Protocol (RDP) is an extension of ICMP that allows end hosts to discover routers on their networks. This implementation of RDP supports the router requirements as defined in RFC 1256.

RDP Specifications
RFCs Supported Router advertisements Host solicitations Maximum number of RDP interfaces per switch Advertisement destination addresses RFC 1256ICMP Router Discovery Messages Supported Only responses to solicitations supported in this release. One for each available IP interface configured on the switch. 224.0.0.1 (all systems multicast) 255.255.255.255 (broadcast)

RDP Defaults
Parameter Description RDP status for the switch RDP status for switch interfaces (router VLAN IP addresses) Advertisement destination address for an active RDP interface. Maximum time between advertisements sent from an active RDP inter-face Minimum time between advertisements sent from an active RDP inter-face Maximum time IP addresses contained in an advertisement packet are considered valid Preference level for IP addresses contained in an advertisement packet Default Value/Comments Disabled Disabled All systems multicast (224.0.0.1) 600 seconds 450 seconds (0.75 * maximum advertisement interval) 1800 seconds (3 * maximum advertisement interval) 0

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 486 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

RDP Overview
End hosts (clients) sending traffic to other networks need to forward their traffic to a router. In order to do this, hosts need to find out if one or more routers exist on their LAN and learn their IP addresses. One way to discover neighboring routers is to manually configure a list of router IP addresses that the host reads at startup. Another method available involves listening to routing protocol traffic to gather a list of router IP addresses. RDP provides an alternative method for hosts to discover routers on their network that involves the use of ICMP advertisement and solicitation messages. Using RDP, hosts attached to multicast or broadcast networks send solicitation messages when they start up. Routers respond to solicitation messages with an advertisement message that contains the router IP addresses. In addition, routers send advertisement messages when their RDP interface becomes active and then subsequently at random intervals. When a host receives a router advertisement message, it adds the IP addresses contained in the message to its list of default router gateways in the order of preference. As a result, the list of router IP addresses is dynamically created and maintained, eliminating the need for manual configuration of such a list. In addition, hosts do not have to recognize many different routing protocols to discover router IP addresses. The following diagram illustrates an example of using RDP in a typical network configuration:

When interfaces 2/3 and 2/4 on hosts H-1 and H-2, respectively, become active, they transmit router solicitation ICMP messages on Network 17.0.0.0. RDP enabled routers RS-1 and RS-2 pick up these packets on their RDP interfaces 1/1 and 1/2 and respond with router advertisement ICMP messages. RS-1 and RS-2 also periodically send out router advertisements on their RDP interfaces.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 487 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

RDP Interfaces
Enabling RDP on a VLAN router IP address creates an RDP interface. Once enabled, the RDP inter-face becomes active and joins the all-routers IP multicast group (224.0.0.2). The interface then transmits 3 initial router advertisement messages at random intervals that are no greater than 16 seconds apart. This process occurs upon activation to increase the likelihood that end hosts will quickly discover this router. After an RDP interface becomes active and transmits its initial advertisements, subsequent advertisements are transmitted at random intervals that fall between configurable ranges of time. This range of time is defined by specifying a maximum and minimum advertisement interval value. Because advertisements are transmitted at random intervals, the risk of system overload is reduced, as advertisements from other routers on the same link are not likely to transmit at the same time. It is important to note that advertisements are only transmitted on RDP interfaces if the following conditions are met: The RDP global status is enabled on the switch An IP interface exists and is in the enabled state An RDP interface exists and is in the enabled state Either VRRP is disabled or if VRRP is enabled, there is one or more Master IP addresses for the VLAN. If VRRP is enabled and if there are no Masters IP addresses, router advertisements are not sent on the VLAN. The router advertisement is a multicast packet sent to the all-systems IP multicast group (224.0.0.1) or the broadcast address. If VRRP is enabled, the message should be filled with IP addresses obtained from VRRP Master IP address list; otherwise the IP address of this VLAN is used. Note that RDP is not recommended for detecting neighboring router failures, referred to as black holes, in the network. However, it is possible to use RDP as a supplement for black hole detection by setting RDP interface advertisement interval and lifetime values to values lower than the default values for these parameters.

Security Concerns
ICMP RDP packets are not authenticated, which makes them vulnerable to the following attacks: Passive monitoringAttackers can use RDP to re-route traffic from vulnerable systems through the attackers system. This allows the attacker to monitor or record one side of the conversation. However, the attacker must reside on the same network as the victim for this scenario to work. Man in the middleAttacker modifies any of the outgoing traffic or plays man in the middle, acting as a proxy between the router and the end host. In this case, the victim thinks that it is communicating with an end host, not an attacker system. The end host thinks that is it communicating with a router because the attacker system is passing information through to the host from the router. If the victim is a secure web server that uses SSL, the attacker sitting in between the server and an end host could intercept unencrypted traffic. As is the case with passive monitoring, the attacker must reside on the same network as the victim for this scenario to work. Denial of service (DoS)Remote attackers can spoof these ICMP packets and remotely add bad default-route entries into a victims routing table. This would cause the victim to forward frames to the wrong address, thus making it impossible for the victims traffic to reach other networks. Because of the large number of vulnerable systems and the fact that this attack will penetrate firewalls that do not stop incoming ICMP packets, this DoS attack can become quite severe. Note. Security concerns associated with using RDP are generic to the feature as defined in RFC 1256 and not specific to this implementation.

Defining the Advertisement Interval

The advertisement interval represents a range of time, in seconds, in which RDP will transmit advertisement packets at random intervals. Configuring a maximum amount of time that RDP will not exceed before the next transmission, and configuring a minimum amount of time that RDP will observe before sending the next transmission define this range. Both of these values are referred to as the maximum advertisement interval and the minimum advertisement interval. Note that when an RDP interface becomes active, it transmits 3 advertisement packets at intervals no greater than 16 seconds. This facilitates a quick discovery of this router on the network. After these initial transmissions, advertisements occur at random times within the advertisement interval value or in response to solicitation messages received from network hosts.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 488 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

DHCP Relay
The User Datagram Protocol (UDP) is a connectionless transport protocol that runs on top of IP networks. The DHCP Relay allows you to use non-routable protocols (such as UDP) in a routing environment. UDP is used for applications that do not require the establishment of a session and end-to-end error checking. Email and file transfer are two applications that could use UDP. UDP offers a direct way to send and receive Datagrams over an IP network and is primarily used for broadcasting messages. This section describes the DHCP Relay feature. This feature allows UDP broadcast packets to be forwarded across VLANs that have IP routing enabled.

DHCP Relay Specifications

RFCs Supported 0951Bootstrap Protocol 1534Interoperation Between DHCP and BOOTP 1541Dynamic Host Configuration Protocol 1542Clarifications and Extensions for the Bootstrap Protocol 2132DHCP Options and BOOTP Vendor Extensions 3046-DHCP Relay Agent Information Option, 2001 Global DHCP Per-VLAN DHCP AVLAN DHCP BOOTP/DHCP (Bootstrap Protocol/Dynamic Host Configuration Protocol) 67 for Request 68 for Response AutomaticDHCP assigns a permanent IP address to a host. DynamicDHCP assigns an IP address to a host for a limited period of time (or until the host explicitly relinquishes the address). ManualThe network administrator assigns a hosts IP address and the DHCP conveys the address assigned by the host. Maximum of 256 IP addresses for each Relay Service. Maximum of 8 IP addresses for each VLAN relay service. Maximum of 256 VLAN relay services. 3

DHCP Relay Implementation

DHCP Relay Service UDP Port Numbers IP address allocation mechanisms

IP addresses supported for each Relay Service. IP addresses supported for the Per-VLAN service Maximum number of UDP relay services allowed per switch Maximum number of VLANs to which forwarded UDP service port traffic is allowed Maximum number of DHCP Snooping VLANs

256

64

DHCP Relay Defaults

Parameter Description Default UDP service Forward delay time value for DHCP Relay Maximum number of hops Packet forwarding option Automatic switch IP configuration for default VLAN 1. Automatic switch IP configuration packet type (BootP or DHCP) Relay Agent Information Option Switch-level DHCP Snooping VLAN-level DHCP Snooping Default Value/Comments BOOTP/DHCP 3 seconds 4 hops Standard Disabled BootP Disabled Disabled Disabled

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 489 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

DHCP Relay Overview

The DHCP Relay service, its corresponding port numbers, and configurable options are as follows: DHCP Relay Service: BOOTP/DHCP UDP Port Numbers 67/68 for Request/Response Configurable options: DHCP server IP address, Forward Delay, Maximum Hops, Forwarding Option, automatic switch IP configuration The port numbers indicate the destination port numbers in the UDP header. The DHCP Relay will verify that the forward delay time (specified by the user) has elapsed before sending the packet down to UDP with the destination IP address replaced by the address (also specified by the user). If the relay is configured with multiple IP addresses, then the packet will be sent to all IP address destinations. The DHCP Relay also verifies that the maximum hop count has not been exceeded. If either the forward delay time is met or the maximum hop count is exceeded, the BOOTP/DHCP packet will be discarded by the DHCP Relay. The forwarding option allows you to specify if the relay should operate in the standard, per-VLAN only, or AVLAN-only mode. The standard mode forwards all DHCP packets on a global relay service. The per-VLAN only mode forwards DHCP packets that originate from a specific VLAN. The AVLAN-only mode only forwards packets received on authenticated ports from non-authenticated clients. An additional function provided by the DHCP Relay service enables automatic IP address configuration for default VLAN 1 when an un-configured switch boots up. If this function is enabled, the switch broadcasts a BootP or a DHCP request packet at boot time. When the switch receives an IP address from a BootP/DHCP server, the address is assigned to default VLAN 1. Alternately an external router connected to the switch may provide the relay function; in this case, the relay would be configured on the external router.

DHCP
DHCP (Dynamic Host Configuration Protocol) provides a framework for passing configuration information to Internet hosts on a TCP/IP network. It is based on the Bootstrap Protocol (BOOTP), adding the ability to automatically allocate reusable network addresses and additional configuration options. DHCP consists of the following two components: A protocol for delivering host-specific configuration parameters from a DHCP server to a host. A mechanism for allocating network addresses to hosts. DHCP is built on a client-server model in which a designated DHCP server allocates network addresses and delivers configuration parameters to dynamically configured hosts. It supports the following three mechanisms for IP address allocation. AutomaticDHCP assigns a permanent IP address to a host. DynamicDHCP assigns an IP address to a host for a limited period of time (or until the host explicitly relinquishes the address). ManualThe network administrator assigns a hosts IP address and DHCP simply conveys the assigned address to the host.

DHCP and the OmniSwitch

The unique characteristics of the DHCP protocol require a good plan before setting up the switch in a DHCP environment. Since DHCP clients initially have no IP address, placement of these clients in a VLAN is hard to determine. In simple networks (e.g., one VLAN) rules do not need to be deployed to support the BOOTP/DHCP relay functionality. In multiple VLAN network configurations, VLAN rules can be deployed to strategically support the processing and relay of DHCP packets. The most commonly used rules for this function are IP protocol rules, IP network address rules, and DHCP rules. All of these classify packets received on mobile ports based on the packet protocol type, source IP address, or if the packet is a DHCP request.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 490 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

DHCP Relay and Authentication

Authentication clients may use DHCP to get an IP address. For Telnet authentication clients, an IP address is required for authentication. The DHCP server may be located in the default VLAN, an authenticated VLAN, or both. If authentication clients will be getting an IP address from a DHCP server located in an authenticated VLAN, DHCP relay can handle DHCP requests/responses for these clients as well. There is three relay forwarding options: standard, AVLAN only, and per-VLAN. All three support DHCP traffic to/from authenticated clients. However, the AVLAN only option specifies that only DHCP packets received on authenticated ports be processed. Using DHCP Relay with authenticated VLANs and clients also requires relay configuration of the router port address of the authenticated VLAN.

External DHCP Relay Application

The DHCP Relay may be configured on a router that is external to the switch. In this application example the switched network has a single VLAN configured with multiple segments. All of the network hosts are DHCP-ready, meaning they obtain their network address from the DHCP server. The DHCP server resides behind an external network router, which supports the DHCP Relay functionality. One requirement for routing DHCP frames is that the router must support DHCP Relay functionality to be able to forward DHCP frames. In this example, DHCP Relay is supported within an external router, which forwards request frames from the incoming router port to the outgoing router port attached to the OmniSwitch.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 491 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The external router inserts the subnet address of the first hop segment into the DHCP request frames from the DHCP clients. This subnet address allows the DHCP server to locate the segment on which the requesting client resides. In this example, all clients attached to the OmniSwitch are DHCP-ready and will have the same subnet address (130.0.0.0) inserted into each of the requests by the routers DHCP Relay function. The DHCP server will assign a different IP address to each of the clients. The switch does not need an IP address assigned and all DHCP clients will be members of either a default VLAN or an IP protocol VLAN.

Internal DHCP Relay

The internal DHCP Relay is configured using the UDP forwarding feature in the switch, available through the ip helper address command. This application example shows a network with two VLANs, each with multiple segments. All network clients are DHCPready and the DHCP server resides on just one of the VLANs. This example is much like the first application example, except that the DHCP Relay function is configured inside the switch.

During initialization, each network client forwards a DHCP request frame to the DHCP server using the local broadcast address. For those locally attached stations, the frame will simply be switched. In this case, the DHCP server and clients must be members of the same VLAN (they could also all be members of the default VLAN). One way to accomplish this is to use DHCP rules in combination with IP protocol rules to place all IP frames in the same VLAN. Because the clients in the application example are not members of the same VLAN as the DHCP server, they must request an IP address via the DHCP Relay routing entity in the switch. When a DHCP request frame is received by the DHCP Relay entity, it will be forwarded from VLAN 3 to VLAN 2. All the DHCP-ready clients in VLAN 3 must be members of the same VLAN, and the switch must have the DHCP Relay function configured.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 492 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

DHCP Relay Implementation

The OmniSwitch allows you to configure the DHCP Relay feature in one of two ways. You can set up a global DHCP request or you can set up the DHCP Relay based on the VLAN of the DHCP request. Both of these choices provide the same configuration options and capabilities. However, they are mutually exclusive. The following matrix summarizes the options.
Per-VLAN DHCP Relay Disabled Disabled Enabled Enabled Global DHCP Relay Disabled Enabled Disabled Enabled Effect DHCP Request is flooded within its VLAN DHCP Request is relayed to the Global Relay DHCP Request is relayed to the Per-VLAN Relay N/A

For the global DHCP service, you must identify an IP address for the DHCP server. The DHCP Relay forwards BOOTP/DHCP broadcasts to and from the specified address. If multiple DHCP servers are used, one IP address must be configured for each server. You can configure up to 256 addresses for each relay service.

Per-VLAN DHCP
For the Per-VLAN DHCP service, you must identify the number of the VLAN that makes the relay request. You may enter one or more server IP addresses to which packets will be sent from a specified VLAN.

Enabling BOOTP/DHCP Relay

Once the IP address of the DHCP server(s) is defined and the DHCP Relay is configured for either Global DHCP request or Per-VLAN DHCP request, you can set the following optional parameter values to configure BOOTP relay. The IP address to the DHCP server The forward delay time The hop count The relay forwarding option The only parameter that is required for BOOTP relay is the IP address to the DHCP server or to the next hop to the DHCP server. The default values can be accepted for forward delay, hop count, and relay forwarding option. Alternately an external router connected to the switch may provide the relay function; in this case, the relay would be configured on the external router.

Using Automatic IP Configuration

An additional function of the DHCP Relay feature enables a switch to broadcast a BootP or DHCP request packet at boot time to obtain an IP address for default VLAN 1. This function is separate from the previously described functions (such as Global DHCP, per-VLAN DHCP and related configurable options) in that enabling or disabling automatic IP configuration does not exclude or prevent other DHCP Relay functionality. Note. Automatic IP address configuration only supports the assignment of a permanent IP address to the switch. Make sure that the DHCP server is configured with such an address before using this feature. Using automatic IP configuration also allows the switch to specify the type of request packet to send; BootP (the default) or DHCP. When the BootP/DHCP server receives the request packet from the switch, it processes the request and sends an appropriate reply packet. When the switch receives a reply packet from the BootP/DHCP server, one or more of the following occurs: The router port for VLAN 1 is assigned the IP address provided by the server. If the reply packet contains a subnet mask for the IP address, the mask is applied to the VLAN 1 router port address. Otherwise, a default mask is determined based upon the class of the IP address. For example, if the IP address is a Class A, B, or C address, then 255.0.0.0, 255.255.0.0, or 255.255.255.0 is used for the subnet mask. If the reply packet from the server contains a gateway IP address, then a static route entry of 0.0.0.0 is created on the switch with the gateway address provided by the server. Note. If the VLAN 1 router port is already configured with an IP address, the switch does not broadcast a request packet at boot time even if automatic IP configuration is enabled. To verify IP router port configuration for VLAN 1, use the show ip interface and show ip route commands.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 493 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

UDP Port Relay

In addition to configuring a relay operation for BOOTP/DHCP traffic on the switch, it is also possible to configure relay for generic UDP service ports (i.e., NBNS/NBDD, other well-known UDP service ports, and service ports that are not well-known). This is done using UDP Port Relay commands to enable relay on these types of ports and to specify up to 256 VLANs that can forward traffic destined for these ports. The UDP Port Relay function is separate from the previously described functions (such as global DHCP, per-VLAN DHCP, and automatic IP configuration) in that using UDP Port Relay does not exclude or prevent other DHCP Relay functionality. However, the following information is important to remember when configuring BOOTP/DHCP relay and UDP port relay: UDP port relay supports up to three UDP relay services at any one time and in any combination. Note. If the relay service for BOOTP/DHCP is disabled when the switch reboots, the service is automatically enabled when the switch comes back up. If there were three non-BOOTP/DHCP relay services already enabled before the reboot, the most recent service enabled is disabled and replaced with the BOOTP/DHCP relay service. The ip helper commands are used to configure BOOTP/DHCP relay and the ip udp port commands are used to configure UDP port relay. The ip udp relay command, however, is also used to enable or disable relay for BOOTP/DHCP well known ports 67 and 68. If the BOOTP/DHCP relay service is disabled, the ip helper configuration is not retained and all dependant functionality (i.e., automatic IP configuration for VLAN 1, Telnet and HTTP client authentication, etc.) is disrupted. Relaying BOOTP/DHCP traffic is available on a global and per-VLAN basis. Using this function on a per-VLAN basis requires setting the DHCP relay forwarding mode to per-vlan only. UDP port relay for generic services is only available on a per-VLAN basis, but does not require enabling the per-vlan only forwarding option. Configuring UDP Port Relay for generic UDP services is a two-step process. The first step involves enabling UDP Port Relay on the generic service port. The second step involves specifying a VLAN that relay will forward traffic destined for the generic service port.

Configuring DHCP Security Features

There are two DHCP security features available: DHCP relay agent information option (Option-82) and DHCP Snooping. The DHCP Option-82 feature enables the relay agent to insert identifying information into client-originated DHCP packets before the packets are forwarded to the DHCP server. The DHCP Snooping feature filters DHCP packets between untrusted sources and a trusted DHCP server and builds a binding database to log DHCP client information. Although DHCP Option-82 is a subcomponent of DHCP Snooping, these two features are mutually exclusive. If the DHCP Option-82 feature is enabled for the switch, then DHCP Snooping is not available. The reverse is also true; if DHCP Snooping is enabled, then DHCP Option-82 is not available. In addition, the following differences exist between these two features: DHCP Snooping does require and use the Option-82 data insertion capability, but does not implement any other behaviors defined in RFC 3046. DHCP Snooping will automatically drop client DHCP packets that already have Option-82 information present. The DHCP Option-82 feature provides configurable options for dealing with such packets. DHCP Snooping is configurable at the switch level and on a per-VLAN basis, but DHCP Option-82 is only configurable at the switch level.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 494 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using the Relay Agent Information Option (Option-82)

This implementation of the DHCP relay agent information option (Option-82) feature is based on the functionality defined in RFC 3046. By default DHCP Option-82 functionality is disabled. The ip helper agent-information command is used to enable this feature at the switch level. When this feature is enabled, the relay agent authenticates communications between a DHCP client and a DHCP server. To accomplish this task, the agent adds Option-82 data to the end of the options field in DHCP packets sent from a client to a DHCP server. Option-82 consists of two sub-options: Circuit ID and Remote ID. The agent fills in the following information for each of these sub-options: Circuit IDthe VLAN ID and slot/port from where the DHCP packet originated Remote IDthe MAC address of the router interface associated with the VLAN ID specified in the Circuit ID sub-option. The DHCP Option-82 feature is only applicable when DHCP relay is used to forward DHCP packets between clients and servers associated with different VLANs. In addition, a secure IP network must exist between the relay agent and the DHCP server.

How the Relay Agent Processes DHCP Packets from the Client
The following table describes how the relay agent processes DHCP packets received from clients when the Option-82 feature is enabled for the switch: If the DHCP packet from the client ... The relay agent ... Inserts Option-82 with unique information to identify Contains a zero gateway IP address (0.0.0.0) and no Option-82 data. the client source. Drops the packet, keeps the Option-82 data and forwards Contains a zero gateway IP address (0.0.0.0) and Option-82 data. the packet, or replaces the Option-82 data with its own Option-82 data and forwards the packet. The action performed by the relay agent in this case is determined by the agent information policy that is configured through the ip helper agent-information policy command. By default, this type of DHCP packet is dropped by the agent. Forwards the packet without inserting Option-82 data. Contains a non-zero gateway IP address and no Option-82 data. Drops the packet if the gateway IP address matches a Contains a non-zero gateway IP address and Option-82 data. local subnet, otherwise the packet is forwarded without inserting Option-82 data.

How the Relay Agent Processes DHCP Packets from the Server
Note that if a DHCP server does not support Option-82, the server strips the option from the packet. If the server does support this option, the server will retain the Option-82 data received and send it back in a reply packet. When the relay agent receives a DHCP packet from the DHCP server and the Option-82 feature is enabled, the agent will: 1 Extract the VLAN ID from the Circuit ID sub-option field in the packet and compare the MAC address of the IP router interface for that VLAN to the MAC address contained in the Remote ID sub-option field in the same packet. 2 If the IP router interface MAC address and the Remote ID MAC address are not the same, then the agent will drop the packet. 3 If the two MAC addresses match, then a check is made to see if the slot/port value in the Circuit ID sub-option field in the packet matches a port that is associated with the VLAN also identified in the Circuit ID sub-option field. 4 If the slot/port information does not identify an actual port associated with the Circuit ID VLAN, then the agent will drop the packet. 5 If the slot/port information does identify an actual port associated with the Circuit ID VLAN, then the agent strips the Option-82 data from the packet and forwards the packet to the port identified in the Circuit ID sub-option.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 495 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using DHCP Snooping

Using DHCP Snooping improves network security by filtering DHCP messages received from devices outside the network and building and maintaining a binding table (database) to track access information for such devices. In order to identify DHCP traffic that originates from outside the network, DHCP Snooping categorizes ports as either trusted or untrusted. A port is trusted if it is connected to a device inside the network, such as a DHCP server. A port is untrusted if it is connected to a device outside the network, such as a customer switch or workstation. When DHCP Snooping is first enabled, all ports are considered untrusted. It is important to then configure ports connected to a DHCP server inside the network as a trusted port. If a DHCP packet is received on an untrusted port, then it is considered an untrusted packet. If a DHCP packet is received on a trusted port, then it is considered a trusted packet. DHCP Snooping only filters untrusted packets and will drop such packets if one or more of the following conditions are true: The packet received is a DHCP server packet, such as a DHCPOFFER, DHCPACK, or DHCPNAK packet. When a server packet is received on an untrusted port, DHCP Snooping knows that it is not from a trusted server and discards the packet. The source MAC address of the packet and the DHCP client hardware address contained in the packet are not the same address. The packet is a DHCPRELEASE or DHCPDECLINE broadcast message that contains a source MAC address found in the DHCP Snooping binding table, but the interface information in the binding table does not match the interface on which the message was received. The packet includes a relay agent IP address that is a non-zero value. The packet already contains Option-82 data in the options field. If none of the above are true, then the relay agent accepts and forwards the packet. When the relay agent receives a DHCPACK packet from a server, the agent extracts the following information to create an entry in the DHCP Snooping binding table: MAC address of the DHCP client. IP address for the client that was assigned by the DHCP server. The port from where the DHCP packet originated. The VLAN associated with the port from where the DHCP packet originated. The lease time for the assigned IP address. The binding entry type; dynamic or static (user-configured). After extracting the above information and populating the binding table, the agent then forwards the packet to the port from where the packet originated. Basically, the DHCP Snooping features prevent the normal flooding of DHCP traffic. Instead, packets are delivered only to the appropriate client and server ports. Note: that DHCP Snooping only applies to traffic that is relayed between VLANs. If a DHCP server and client reside within the same VLAN domain, then DHCP Snooping is not applied to communications between these devices.

DHCP Snooping Configuration Guidelines

Consider the following when configuring the DHCP Snooping feature: DHCP Snooping requires the use of the relay agent to process DHCP packets. As a result, DHCP clients and servers must reside in different VLANs so that the relay agent is engaged to forward packets between the VLAN domains. Configure ports connected to DHCP servers within the network as trusted ports. Make sure that Option-82 data insertion is always enabled at the switch or VLAN level. The DHCP severs must support the Option-82 feature or at a minimum retain and echo back the Option-82 data field. There are two levels of operation available for the DHCP Snooping feature: switch level or VLAN level. These two levels are exclusive of each other in that they both cannot operate on the switch at the same time. In addition, if the global DHCP relay agent information option (Option-82) is enabled for the switch, then DHCP Snooping at any level is not available. Note. DHCP Snooping drops server packets received on untrusted ports (ports that connect to devices outside the network or firewall). It is important to configure ports connected to DHCP servers as trusted ports so that traffic to/from the server is not dropped.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 496 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VRRP
The Virtual Router Redundancy Protocol (VRRP/VRRP3) is a standard router redundancy protocol supported in IPv4/IPv6. It is based on RFC 3768 and RFC 2787 and provides redundancy by eliminating the single point of failure inherent in a default route environment. The VRRP/VRRP3 router, which controls the IP/IPv6 address associated with a virtual router is called the master router, and it forwards the packets to that IP/IPv6 address. If the master router becomes unavailable, the highest priority backup router will transition to the master state. Note. RFC 3768, which obsoletes RFC 2338, does not include support for authentication types. As a result, configuring VRRP authentication is no longer supported in this release.

VRRP Specifications
RFCs Supported RFC 2338Virtual Router Redundancy Protocol RFC 2787Definitions of Managed Objects for the Virtual Router Redundancy Protocol No 255 (A virtual router is defined by a virtual router identifier (VRID) and a set of associated IP addresses on the LAN) 1 for the IP address owner; more than 1 address may be configured if the router is a backup for a master router that supports multiple addresses

Compatible with HSRP? Maximum number of virtual router instances Maximum number of IP addresses

VRRP Defaults
Description Virtual router enabled or disabled Priority Preempt mode Advertising interval VRRP authentication VRRP traps VRRP tracking VRRP delay Default Virtual routers are disabled (off). 100 Preempt mode is enabled. 1 second Authentication is not enabled. Disabled Enabled 45 seconds

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 497 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VRRP Overview
VRRP allows routers on a LAN to back up a default route. VRRP dynamically assigns responsibility for a virtual router to a physical router (VRRP router) on the LAN. The virtual router is associated with an IP address (or set of IP addresses) on the LAN. A virtual router master is elected to forward packets for the virtual routers IP address. If the master router becomes unavailable, the highest priority backup router will transition to the master state. Note. The IP address that is backed up may be the IP address of a physical router, or it may be a virtual IP address. The example provided here is intended for understanding VRRP and does not show a configuration that would be used in an actual network.

In this example, each physical router is configured with a virtual router, VRID 1, which is associated with IP address A. OmniSwitch A is the master router because it contains the physical interface to which IP address A is assigned. OmniSwitch B is the backup router. The client is configured with a gateway address of IP A. When VRRP is configured on these switches, and both switches are available, OmniSwitch A will respond to ARP requests for IP address A using the virtual routers MAC address (00:00:5E:00:01:01) instead of the physical MAC address assigned to the interface. OmniSwitch A will accept packets sent to the virtual MAC address and forward them as appropriate; it will also accept packets addressed to IP address A (such as ICMP ping requests). OmniSwitch B will respond to ARP requests for IP address B using the interfaces physical MAC address. It will not respond to ARP requests for IP address A or to the virtual router MAC address. If OmniSwitch A becomes unavailable, OmniSwitch B becomes the master router. OmniSwitch B will then respond to ARP requests for IP address A using the virtual routers MAC address (00:00:5E:00:01:01). It will also forward packets for IP address B and respond to ARP requests for IP address B using the OmniSwitch physical MAC address. OmniSwitch B, however, cannot accept packets addressed to IP address A (such as ICMP ping requests). OmniSwitch B uses IP address B to access the LAN, but IP address B is not backed up. If OmniSwitch B becomes unavailable, IP address B is unavailable.

Why Use VRRP?

An end host may use dynamic routing or router discovery protocols to determine its first hop toward a particular IP destination. With dynamic routing, large timer values are required and may cause significant delay in the detection of a dead neighbor. If an end host uses a static route to its default gateway, this creates a single point of failure if the route becomes unavailable. End hosts will not be able to detect alternate paths. In either case, VRRP ensures that an alternate path is always available.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 498 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Definition of a Virtual Router

To back up an IP address or addresses using VRRP, a virtual router must be configured on VRRP routers on a common LAN. A VRRP router is a physical router running VRRP. A Virtual router is defined by a virtual router identifier (VRID) and a set of associated IP addresses on the LAN. (On the OmniSwitch only one IP address is assigned to an interface, but other VRRP routers may have multiple IP addresses per interface. In addition, the VRID must be unique.) Note. A limitation of the OmniSwitch is that a single VRID may only be associated with one VLAN. Each VRRP router may back up one or more virtual routers. The VRRP router that contains the physical interfaces to which the virtual router IP addresses are assigned is called the IP address owner. If it is avail-able, the IP address owner will function as the master router. The master router assumes the responsibility of forwarding packets sent to the IP addresses associated with the virtual router and answering ARP requests for these addresses. To minimize network traffic, only the master router sends VRRP advertisements on the LAN. The IP address assigned to the physical interface on the current master router is used as the source address in VRRP advertisements. The advertisements communicate to all VRRP routers the priority and state of the master router associated with the VRID. The advertisements are IP multicast Datagrams sent to the VRRP multicast address 224.0.0.18 (as determined by the Internet Assigned Numbers Authority). If a master router becomes unavailable, it stops sending VRRP advertisements on the LAN. The backup routers know the master is unavailable based on the following algorithm: Master Down Interval = (3 * Advertisement Interval) + Skew Time Where Advertisement Interval is the time interval between VRRP advertisements, and Skew Time is calculated based on the VRRP routers priority value as follows: Skew Time = (256 - Priority) / 256 If backup routers are configured with priority values that are close in value, there may be a timing conflict, and the first backup to take over may not be the one with the highest priority; a backup with a higher priority will then preempt the new master. The virtual router may be configured to prohibit any preemption attempts, except by the IP address owner. An IP address owner, if it is available, will always become master of any virtual router associated with its IP addresses. Note. Duplicate IP address/MAC address messages may display when a backup takes over for a master, depending on the timing of the takeover and the configured advertisement interval. This is particularly true if more than one backup is configured.

VRRP MAC Addresses

Each virtual router has a single well-known MAC address, which is used as the source in all periodic VRRP advertisements sent by the master router, any other packets originating from the master router, and as the MAC address in ARP replies (instead of a VRRP routers physical MAC address). The address has the following format: 00-00-5E-00-01-[virtual router ID] This mapping provides for up to eight virtual routers on an OmniSwitch.

ARP Requests
Each virtual router has a single well-known MAC address, which is used as the MAC address in ARP replies instead of a VRRP router's physical MAC address. When an end host sends an ARP request to the master routers IP address, the master router responds to the ARP request using the virtual router MAC address. If a backup router takes over for the master, and an end host sends an ARP request, the backup will reply to the request using the virtual router MAC address. Gratuitous ARP requests for the virtual router IP address or MAC address are broadcast when the OmniSwitch becomes the master router. For VRRP interfaces, gratuitous ARP requests/responses are delayed at system boot until both the IP address and the virtual router MAC address are configured. If a virtual router shares an interface IP address, the routing mechanism does not send a gratuitous ARP for the IP address (since the virtual router will send a gratuitous ARP). This prevents traffic from being forwarded to the router before its routing tables are stable.

ICMP Redirects
ICMP redirects are not sent out over VRRP interfaces.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 499 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VRRP Startup Delay

When a virtual router reboots and becomes master, it may become master before its routing tables are populated. This could result in loss of connectivity to the router. To prevent the loss in connectivity, a delay is used to prevent the router from becoming master before the routing tables are stabilized; the default delay value is 45 seconds. The startup delay may be modified to allow more or less time for the router to stabilize its routing tables. In addition to the startup delay, the switch has an ARP delay (which is not configurable).

VRRP Tracking
A virtual routers priority may be conditionally modified to prevent another router from taking over as master. Tracking policies are used to conditionally modify the priority setting whenever a VLAN, slot/port, and or IP address associated with a virtual router goes down. A tracking policy consists of a tracking ID, the value amount used to decrease the priority value, and the VLAN ID, slot/port number, or IP address to be monitored by the policy. The policy is then associated with one or more virtual routers.

Interaction With Other Features

IP routingIP routing must be enabled for the VRRP configuration to take effect. Router Discovery Protocol (RDP)If RDP is enabled on the switch, and VRRP is enabled, RDP will advertise VLAN IP addresses of virtual routers depending on whether there are virtual routers active on the LAN, and whether those routers are backups or masters. When there are no virtual routers active on the VLAN (either acting as master or backup), RDP will advertise all VLAN IP addresses. However, if virtual routers are active, RDP will advertise IP addresses for any master routers; RDP will not advertise IP addresses for backup routers.

Configuration Overview
VRRP is part of the base software. At startup, VRRP is loaded onto the switch and is enabled. Virtual routers must first be configured and enabled as described in the sections. Since VRRP is implemented on multiple switches in the network, some VRRP parameters must be identical across switches: VRRP and ACLs If QoS filtering rules (Access Control Lists) are configured for Layer 3 traffic on a VRRP router, all of the VRRP routers on the LAN must be configured with the same filtering rules; otherwise the security of the network will be compromised. Conflicting VRRP Parameters Across Switches All virtual routers with the same VRID on the LAN should be configured with the same advertisement interval, IP addresses, and authentication password. If the virtual routers are configured differently, it may result in more than one virtual router acting as the master router. This in turn would result in duplicate IP and MAC address messages as well as multiple routers forwarding duplicate packets to the virtual router MAC address. Use the show vrrp statistics command to check for conflicting parameters.

Basic Virtual Router Configuration

At least two virtual routers must be configured on the LANa master router and a backup router. The virtual router is identified by a number called the Virtual Router ID (VRID), the VLAN on which the virtual router is configured, and the IP address or addresses associated with the router. Multiple virtual routers may be configured on a single physical VRRP router.

The Advertisement Interval

The advertisement interval is configurable, but all virtual routers with the same VRID should be configured with the same value. Mismatched values will create network problems. If you change the advertisement interval on the master router when VRRP is already running or if the advertisement interval is set differently for a master router and a backup router, VRRP packets may be dropped because the newly configured interval does not match the interval indicated in the packet. The backup router will then take over and send a gratuitous ARP, which includes the virtual router IP address and the virtual router MAC address. In addition to creating duplicate IP/MAC address messages, both routers will begin forwarding packets sent to the virtual router MAC address. This will result in forwarding duplicate packets. To avoid duplicate addresses and packets, make sure the advertisement interval is configured the same on both the master and the backup router. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 500 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Virtual Router Priority

VRRP functions with one master virtual router and at least one backup virtual router. A priority value determines how backup routers will be selected to take over for the master router if it becomes unavailable. Priority values range from 1 to 254. A value of 255 indicates that the virtual router owns the IP address; that is, the router contains the real physical interface to which the IP address is assigned. The default priority value is 100; however the switch sets this value to 255 if it detects that this router is the IP address owner. The value cannot be set to 255 if the router is not the IP address owner. The IP address owner will always be the master router if it is available. If more than one backup router is configured, their priority values may be configured with different values, so that the backup with the higher value will take over for the master. The priority parameter may be used to control the order in which backup routers will take over for the master. If priority values are the same, any backup will take over for master. Note that the switch sets the priority value to zero in the last VRRP advertisement packet before a master router is disabled. Also, if a router is the IP address owner and the priority value is not set to 255, the switch will set its priority to 255 when the router is enabled.

Preemption for Virtual Routers

When a master virtual router becomes unavailable (goes down for whatever reason), a backup router will take over. There may be more than one backup router, and if the backup routers have similar priority values, the backup with the highest priority value may not be the one to take over for the master because of network traffic loads. If thats the case, the backup with the higher priority will then preempt the first backup router. By default virtual routers are allowed to preempt each other; that is, if the virtual router with the highest priority will take over if the master router becomes unavailable. The preempt mode may be disabled so that any backup router that takes over when the master is unavailable will not then be preempted by a backup with a higher priority. Note. The virtual router that owns the IP address(s) associated with the physical router always becomes the master router if is available, regardless of the preempt mode setting and the priority values of the backup routers.

VRRP Authentication
VRRP is designed for a range of internetworking environments that may employ different security policies. The protocol includes two authentication methods (simple clear text password and IP authentication with MD5 HMAC). In the current release, IP authentication with MD5 HMAC is not supported. By default, VRRP authentication is not enabled. VRRP includes a mechanism, however, independent of whether or not authentication is configured, that denies VRRP packets from remote networks. Whenever a VRRP router receives a packet, it sets the Time To Live (TTL) to 255. This prevents the local VRRP network from accepting VRRP packets from remote networks. When a VRRP interface receives a VRRP packet, it verifies that the TTL is 255, the VRRP version is correct, the checksum is correct, and the packet length is greater than or equal to the VRRP header. If the virtual router is configured for authentication, it will also authenticate the packet. (The authentication process is transparent to the user.) Note. The only scenario where authentication is not recommended is an environment with minimal security risk and little chance for configuration error (such as two VRRP routers on a LAN). Typically, simple text password authentication should be configured for VRRP. Simple text password authentication is similar to simple text authentication for the Open Shortest Path First (OSPF) routing protocol. Simple text authentication is recommended because it protects against accidental misconfiguration of routers on a LAN and inadvertently backing up another router. If authentication is used, all virtual routers on the LAN must be configured with the same password and the password must not be the same as any significant security password. This type of authentication is recommended when there is minimal risk of nodes on a LAN actively disrupting VRRP operation. If this type of authentication is used, the user should be aware that the clear text password is sent out frequently. It is possible for the password to be learned by a node snooping VRRP packets on the LAN; however, the simple text authentication combined with VRRP built-in TTL check make it difficult for a VRRP packet to be sent from a remote network to disrupt VRRP operation. Note. All VRRP routers on the same LAN should be configured with the same authentication setting. If authentication is enabled, all routers must have the same password.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 501 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VRRP Traps
A VRRP router has the capability to generate VRRP SNMP traps for events defined in the VRRP SNMP MIB. By default traps are enabled. In order for VRRP traps to be generated correctly, traps in general must be enabled on the switch through the SNMP CLI.

VRRP Application Example

In addition to providing redundancy, VRRP can assist in load balancing outgoing traffic. The figure below shows two virtual routers with their hosts splitting traffic between them. Half of the hosts are configured with a default route to virtual router 1s IP address (10.10.2.250), and the other half are configured with a default route to virtual router 2s IP address (10.10.2.245).

Note. The same VRRP configuration must be set up on the OmniSwitch 6850. The VRRP router that contains, or owns, the IP address will automatically become the master for that virtual router. If the IP address is a virtual address, the virtual router with the highest priority will become the master router. In this scenario, the master of VRID 1 will respond to ARP requests for IP address A using the virtual router MAC address for VRID 1 (00:00:5E:00:01:01). OmniSwitch 1 is the master for VRID 1 since it contains the physical interface to which 10.10.2.3 is assigned. If OmniSwitch A should become unavailable, OmniSwitch B will become master for VRID 1. In the same way, the master of VRID 2 will respond to ARP requests for IP address B using the virtual router MAC address for VRID 2 (00:00:5E:00:01:02). OmniSwitch B is the master for VRID 2 since it contains the physical interface to which 10.10.2.245 is assigned. If OmniSwitch B should become unavailable, OmniSwitch A will become master for 10.10.2.245. This configuration provides uninterrupted service for the end hosts.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 502 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VRRP Tracking Example

The figure below shows two VRRP routers with two virtual routers backing up one IP address on each VRRP router respectively. Virtual router 1 serves as the default gateway on OmniSwitch A for clients 1 and 2 through IP address 10.10.2.250. For example, if the port that provides access to the Internet on OmniSwitch A fails, virtual router 1 will continue to be the default router for clients 1 and 2 but clients 1 and 2 will not be able to access the Internet.

If port 3/1 on VRRP router A goes down, the master for virtual router A is still functioning but workstation clients 1 and 2 will not be able to get to the Internet. With this tracking policy enabled, however, master router 1s priority will be temporarily decremented to 50, allowing backup router 1 to take over and provide connectivity for those workstations. When port 3/1 on VRRP router A comes back up, master 1 will take over again.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 503 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VRRP3 Application Example

In addition to providing redundancy, VRRP3 can assist in load balancing outgoing traffic. The figure below shows two virtual routers with their hosts splitting traffic between them. Half of the hosts are configured with a default route to virtual router 1s IPv6 address (213:100:1::56), and the other half are configured with a default route to virtual router 2s IPv6 address (213:100:1::57).

Note. The same VRRP3 configuration must be set up on each switch. The VRRP3 router that contains, or owns, the IPv6 address will automatically become the master for that virtual router. If the IPv6 address is a virtual address, the virtual router with the highest priority will become the master router. In this scenario, the master of VRID 1 will respond to ARP requests for IPv6 address A using the virtual router MAC address for VRID 1 (00:00:5E:00:01:01). OmniSwitch 1 is the master for VRID 1 since it contains the physical interface to which 213:100:1::56s assigned. If OmniSwitch A should become unavailable, OmniSwitch B will become master for VRID 1. In the same way, the master of VRID 2 will respond to ARP requests for IP address B using the virtual router MAC address for VRID 2 (00:00:5E:00:01:02). OmniSwitch B is the master for VRID 2 since it contains the physical interface to which 213:100:1::57 is assigned. If OmniSwitch B should become unavailable, OmniSwitch A will become master for 213:100:1::57. This configuration provides uninterrupted service for the end hosts.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 504 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

VRRP3 Tracking Example

The figure below shows two VRRP3 routers with two virtual routers backing up one IPv6 address on each VRRP3 router respectively. Virtual router 1 serves as the default gateway on OmniSwitch A for clients 1 and 2 through IPv6 address 213:100:1::56. For example, if the port that provides access to the Internet on OmniSwitch A fails, virtual router 1 will continue to be the default router for clients 1 and 2 but clients 1 and 2 will not be able to access the Internet.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 505 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Quality Of Service (QoS)

Alcatel-Lucents QoS software provides a way to manipulate flows coming through the switch based on user-configured policies. The flow manipulation (generally referred to as Quality of Service or QoS) may be as simple as allowing/denying traffic, or as complicated as re-mapping 802.1p bits from a Layer-2 network to ToS values in a Layer-3 network. While policies may be used in many different types of network scenarios, there are several typical types worth mentioning: Basic QoSincludes traffic prioritization and bandwidth shaping ICMP policiesincludes filtering, prioritizing, and/or rate limiting ICMP traffic for security 802.1p/ToS/DSCPincludes policies for marking and mapping Policy Based Routing (PBR)includes policies for redirecting routed traffic. Policy Based Mirroringincludes mirror-to-port (MTP) policies for mirroring ingress, egress, or both ingress and egress traffic. Access Control Lists (ACLs)ACLs are a specific type of QoS policy used for Layer 2 and Layer 3/4 filtering. Note. Policies may also be configured through the PolicyView NMS application and stored on an attached LDAP server. LDAP policies are downloaded to the switch and managed via the Policy Manager feature in the switch.
QoS/ACL & Layer 3 Security Enhancements

The following additional ACL features are available for improving network security and preventing malicious activity on the network: ICMP drop rulesAllows condition combinations in policies that will prevent user pings, thus reducing DoS exposure from pings. Two condition parameters are also available to provide more granular filtering of ICMP packets: icmptype and icmpcode. BPDUShutdownPortsA port group that identifies its members as ports that should not receive BPDUs. If a BPDU is received on one of these ports, the port is administratively disabled. TCP connection rulesAllows the determination of an established TCP connection by examining TCP flags found in the TCP header of the packet. Two condition parameters are available for defining a TCP connection ACL: established and tcpflags. Early ARP discardARP packets destined for other hosts are discarded to reduce processing overhead and exposure to ARP DoS attacks. No configuration is required to use this feature; it is always available and active on the switch. Note that ARPs intended for use by a local subnet, AVLAN, and VRRP are not discarded.

QoS Specifications
Maximum number of configurable policy rules per switch Maximum number of policy rules per Ethernet port Maximum number of policy rules per 10GB port Maximum number of policy conditions Maximum number of policy actions Maximum number of policy services Maximum number of groups (network, MAC, service, port) per stand-alone Maximum number of group entries Maximum number of rules per slot Maximum number of bandwidth shaping rules per slot Maximum number of priority queues per port 2048 101(OmniSwitch 6800 only) 997 (OmniSwitch 6800 only) 2048 2048 256 1024 1024 per group 1664 (OmniSwitch 6850 and 9000 only) 832 (OmniSwitch 6850 and 9000 CMM only) 8 (Note that two of the eight queues on OmniSwitch 6800 QoS ports are reserved for internal use only, so they are not available.) Some QoS commands support prefix recognition.

CLI Command Prefix Recognition

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 506 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

QoS General Overview

Quality of Service (QoS) refers to transmission quality and available service that is measured and sometimes guaranteed in advance for a particular type of traffic in a network. QoS lends itself to circuit-switched networks like ATM, which bundle traffic into cells of the same length and transmit the traffic over predefined virtual paths. In contrast, IP and other packet- switched networks operate on the concept of shared resources and best effort routing, using bandwidth as needed and reassembling packets at their destinations. Applying QoS to packet-switched networks requires different mechanisms than those used in circuit-switched networks. QoS is often defined as a way to manage bandwidth. Another way to handle different types of flows and increased bandwidth requirements is to add more bandwidth. But bandwidth can be expensive, particularly at the WAN connection. If LAN links that connect to the WAN are not given more bandwidth, bottlenecks may still occur. Also, adding enough bandwidth to compensate for peak load periods will mean that at times some bandwidth will be unused. In addition, adding bandwidth does not guarantee any kind of control over network resources. Using QoS, a network administrator can gain more control over networks where different types of traffic (or flows) are in use or where network congestion is high. Preferential treatment may be given to individual flows as required. Voice over IP (VoIP) traffic or mission-critical data may be marked as priority traffic and/or given more bandwidth on the link. QoS can also prevent large flows, such as a video stream, from consuming all the links bandwidth. Using QoS, a network administrator can decide which traffic needs preferential treatment, and which traffic can be adequately served with best effort. QoS is implemented on the switch through the use of user-defined policies. The following simplified illustration shows how video traffic may receive priority over email traffic.

QoS Policy Overview

A policy (or a policy rule) is made up of a condition and an action. The condition specifies parameters that the switch will examine in incoming flows, such as destination address or Type of Service (ToS) bits. The action specifies what the switch will do with a flow that matches the condition; for example, it may queue the flow with a higher priority, or reset the ToS bits. Policies may be created directly on the switch through the CLI or WebView. Or policies may be created on an external LDAP server via the PolicyView application. The switch makes a distinction between policies created on the switch and policies created on an LDAP server. Note. Polices may be only be modified using the same source used to create them. Policies configured through PolicyView may only be edited through PolicyView. Policies created directly on the switch through the CLI or WebView may only be edited on the switch. Policies may be created through the CLI or WebView, however, to override policies created in PolicyView and vice versa.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 507 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

How Policies Are Used

When a flow comes into the switch, the QoS software in the switch checks to see if there are any policies with conditions that match the flow. If there are no policies that match the flow, the flow is accepted or denied based on the global disposition set for the switch. By default, the disposition is accept. If the flow is accepted, it is placed in a default queue on the output port. If there is more than one policy that matches the flow, each policy is applied to the flow as long as there are no conflicts between the policies. If there is a conflict, then the policy with the highest precedence is applied to the flow. Flows must also match all parameters configured in a policy condition. A policy condition must have at least one classification parameter. Once the flow is classified and matched to a policy, the switch enforces the policy by mapping each packet of the flow to the appropriate queue and scheduling it on the output port. There are a total of eight queues per port (two are reserved for internal use only). Traffic is mapped to a queue based on policies, the ToS/ 802.1p value of the packet, and whether the port is trusted or untrusted.

Valid Policies
The switch does not allow you to create invalid condition/action combinations; if you enter an invalid combination, an error message will display. It is possible to configure a valid QoS rule that is active on the switch, however the switch is not able to enforce the rule because some other switch function (for example, routing) is disabled.

Interaction With Other Features

QoS policies may be an integral part of configuring other switch features, such as Link Aggregation. In addition, QoS settings may affect other features in the switch; or QoS settings may require that other switch features be configured in a particular way. A summary of related features is given here: Dynamic Link AggregatesPolicies may be used to prioritize dynamic link aggregation groups. 802.1QTagged ports are always trusted, regardless of QoS settings. Mobile PortsMobile ports are always trusted, regardless of QoS settings. LDAP Policy ManagementPolicies may also be configured through the PolicyView application and stored on an attached LDAP server. LDAP policies may only be modified through PolicyView. VLAN Stacking ServiceVLAN Stacking ports are always trusted and default classification is set to 802.1p. QoS policy conditions to match the inner VLAN tag and inner 802.1p tag are available for classifying customer information contained in VLAN Stacking frames. Quarantine Manager and Remediation (QMR)Configuring QMR and QoS inner VLAN or inner 802.1p policies is mutually exclusive. QMR overlays the inner VLAN tag, thus creating a conflict with related QoS policies. This is also true with QMR and VLAN Stacking services.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 508 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Condition Combinations
The CLI prevents you from configuring invalid condition combinations that are never allowed; however, it does allow you to create combinations that are supported in some scenario. For example, you might configure source ip and a destination ip for the same condition. This is a valid combination, but will only be used to classify bridged traffic. The following conditions are supported and may be combined with other conditions and/or actions: Layer-1source port, source port group, destination port, destination port group Layer-2source MAC, source MAC group, destination MAC, destination MAC group, 802.1p, inner 802.1p, ether-type, source VLAN, inner source VLAN, destination VLAN (multicast policies only). Layer 3IP protocol, source IP, source IPv6, multicast IP, destination IP, destination IPv6, source network group, destination network group, multicast network group, IPv6 traffic, IPv6 next header (NH), IPv6 flow label (FL), ToS, DSCP, ICMP type, ICMP code. Layer-4source TCP/UDP port, destination TCP/UDP port, service, service group, TCP flags (ECN and CWR are only supported on the OmniSwitch 6800) IP MulticastAn IP multicast condition is used in IGMP ACLs. The multicast IP is the multicast group address used in the IGMP report packet. Note the following: The 802.1p and source VLAN conditions are the only Layer 2 conditions allowed in combination with Layer 4 conditions. Source and destination parameters can be combined in Layer 2, Layer 3, and Layer 4 conditions. In a given rule, ToS or DSCP may be specified for a condition with priority specified for the action. The Layer 1 destination port condition only applies to bridged traffic, not routed traffic. This restriction does not apply to the OmniSwitch 6800. The IP multicast condition works in combination with Layer 1, Layer 2, and Layer 3 destination conditions only if these conditions specify the device that sends the IGMP report packet. All IPv6 conditions are not supported on OmniSwitch 6800. For more information about IPv6 policies Individual items and their corresponding groups cannot be combined in the same condition. For example, a source IP address cannot be included in a condition with a source IP network group. Layer 2 and Layer 3 rules are always effected on bridged and routed traffic. As a result, combining source or destination TCP/UDP port and IP protocol in a condition is allowed. The Quarantine Manager and Remediation (QMR) application and inner VLAN or inner 802.1p conditions are mutually exclusive. If one of these is active, the other one is not available. Use the following policy condition combinations table as a guide when configuring policy conditions. *IP multicast traffic (not IGMP) is treated as regular traffic; QoS functionality works the same way with this type of traffic, with the exception that the destination port condition does not apply. Layer-1 Layer-2 Layer-3* Layer-4* IP Multicast (IGMP) All All All All Destination Layer-1 only All All All Source vlan Destination Layer-2 and 802.1p only only All All All All Destination Layer-3* only All Source All All None Layer-4* vlan and 802.1p only Destination Destination Destination None N/A IP Multicast only only only (IGMP)

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 509 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Action Combinations
The CLI prevents you from configuring invalid action combinations that are never allowed; however, it does allow you to create combinations that are supported in some scenarios. For example, an action specifying maximum bandwidth may be combined with an action specifying priority. The following actions are supported and may be combined with other actions: ACL (disposition drop) Priority 802.1p ToS/DCSP Stamping and Mapping Maximum Bandwidth Port Redirection (not supported on the OmniSwitch 6800) Link Aggregate Redirection (not supported on the OmniSwitch 6800 and 6850) Port Disable (not supported on the OmniSwitch 6800) Permanent Gateway IP (not supported on the OmniSwitch 6800 and 6850) Mirror (not supported on the OmniSwitch 6800) Use the following policy action combinations table as a guide when creating policy rules. Drop Priority Stamp/Map Max Redirect Redirect Port Permanent Mirror BW Port Linkagg Disable gateway IP N/A No No No No No No No Yes Drop No N/A Yes Yes Yes Yes No Yes Yes Priority Yes N/A Yes Yes Yes No Yes Yes Stamp/Map No No Yes Yes N/A Yes Yes No Yes Yes Max BW No Yes Yes Yes N/A No No Yes Yes Redirect Port No Yes Yes Yes No N/A No Yes Yes Redirect Linkagg No No No No No No N/A No No Port Disable Yes Yes Yes Yes Yes No N/A Yes Permanent No Gateway IP Yes Yes Yes Yes Yes Yes No Yes N/A Mirroring Note that the minimum bandwidth action is not included in the list of actions because it is no longer supported on the OmniSwitch 6800 and is not supported on the OmniSwitch 6850 or 9000.

Condition and Action Combinations

Conditions and actions are combined in policy rules. The CLI prevents you from configuring invalid condition/action combinations that are never allowed; however, the following table provides a quick reference for determining which condition/action combinations are not valid. Each row represents a policy condition or conditions combined with the policy action or actions in the same row. Conditions Actions Supported When? all actions never, except with disposition action multicast IP address or network group all actions never, except with disposition and multicast IPv6 address mirror actions all policy never, except with disposition action destination VLAN actions in a multicast rule (a rule that uses the multicast keyword and only applies to IGMP traffic) bridging only on OS6850/OS9000 destination slot/port or port group all actions

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 510 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

QoS Defaults
The following tables list the defaults for global QoS parameters, individual port settings, policy rules, and default policy rules. By default QoS is enabled on the switch. If QoS policies are configured and applied, the switch will attempt to classify traffic and apply relevant policy actions. By default, bridged, routed, and multicast flows that do not match any policies are accepted on the switch. To change the global default disposition (which determines whether the switch will accept, deny, or drop the flow), use the desired disposition setting.

Global QoS Defaults

Description QoS enabled or disabled Global default queuing scheme for ports Whether ports are globally trusted or untrusted Statistics interval Global bridged disposition Global routed disposition Global multicast disposition Level of log detail Number of lines in QoS log Whether log messages are sent to the console Whether log messages are available to OmniVista applications Whether IP anti-spoofing is enabled on UserPorts. (Not supported on OmniSwitch 6800.) Whether a UserPorts port is administratively disabled when unwanted traffic is received. (Not supported on OmniSwitch 6800.) Automatic NMS traffic prioritization. (Not supported on OmniSwitch 6800.) Priority for IP Phone connections. (Not supported on OmniSwitch 6800.) Type of messages logged Default Enabled Strict priority queuing 802.1Q-tagged ports and mobile ports are always trusted; any other port is untrusted 60 seconds Accept Accept Accept 6 256 No No Yes No

Enabled Trusted Information

QoS Port Defaults

Description The default 802.1p value inserted into packets received on untrusted ports. The default DSCP value inserted into packets received on untrusted ports. Whether the port uses strict priority or weighted fair queuing. The default minimum/maximum bandwidth for each of the eight CoS queues per port. (Not supported on the OmniSwitch 6800.) Whether the port is trusted or untrusted Maximum egress bandwidth Maximum ingress bandwidth Default 0 0 Strict priority queuing minimum = best effort maximum = port bandwidth

802.1Q and mobile ports are always trusted; other ports are untrusted Port bandwidth Port bandwidth

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 511 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Policy Rule Defaults

Description Policy rule enabled or disabled Determines the order (precedence) in which rules are searched Whether the rule is saved to flash immediately Whether messages about flows that match the rule are logged. How often to check for matching flow messages. Whether to count bytes or packets that match the rule. (Only packets are counted on the OmniSwitch 6800.) Whether to send a trap for the rule. Default Enabled 0 Save option is enabled No 60 seconds packets are counted

enabled (trap sent only on port disable action or UserPort shutdown operation).

Note: policy rules configured with source and destination conditions and actions with disposition, priority, or 802.1P configured are automatically bi-directional.

Policy Action Defaults

Description Whether the flow matching the rule should be accepted or denied Default Accept

Note that in the current software release the deny and drop options produce the same effect that is, the traffic is silently dropped. Note. There are no defaults for the policy condition.

Default (Built-in) Policies

The switch includes some built-in policies, or default policies, for particular traffic types or situations where traffic does not match any policies. In all cases, the switch accepts the traffic and places it into default queues. Other trafficAny traffic that does not match a policy is accepted or denied based on the global disposition setting on the switch. The global disposition is by default accept. The switch network groupThe switch has a default network group, called switch, that includes all IP addresses configured for the switch itself. This default network group may be used in policies. Policy Port GroupsThe switch supports built-in policy port groups. The groups are called Slot01, Slot02, etc.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 512 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

QoS Configuration Overview

QoS configuration involves the following general steps: 1. Configuring Global Parameters. In addition to enabling/disabling QoS, global configuration includes settings such as global port parameters, default disposition for flows, and various timeouts. The type of parameters you might want to configure globally will depend on the types of policies you will be configuring. For example, if you want to set up policies for 802.1p or ToS/DSCP traffic, you may want to configure all ports as trusted ports. Typically, you will not need to change any of the global defaults. 2. Configuring QoS Port Parameters. This configuration includes setting up QoS parameters on a per port basis. Typically you will not need to change the port defaults. 3. Setting Up Policies. Most QoS configuration involves setting up policies. 4. Applying the Configuration. All policy rule configuration and some global parameters must be specifically applied through the qos apply command before they are active on the switch.

Automatic QoS Prioritization

Automatic QoS prioritization refers to prioritizing certain subsets of switch traffic without having to configure a specific QoS policy to do the same for each type of traffic. This functionality is currently available for Network Management System (NMS) traffic and IP phone traffic. Note that automatic prioritization is not supported on the OmniSwitch 6800. The status of automatic NMS and IP phone prioritization for the switch is displayed through the show qos config command.

Automatic Prioritization for NMS Traffic

Prioritizing NMS traffic destined for the switch helps to maximize NMS access to the switch and reduce the risk of DoS attacks. The following types of traffic are considered NMS traffic: SSH (TCP Port 22) Telnet (TCP Port 23) WebView (HTTP Port 80) SNMP (UDP port 161)

Automatic Prioritization for IP Phone Traffic

The switch automatically trusts the priority of IP phone traffic by default. This means that the priority value contained in packets originating from IP phones is used for the ingress priority. The default priority value configured for the QoS port receiving such traffic is used for the egress priority of the packet. IP phone traffic is detected by examining the source MAC address of the packet to determine if the address falls within the following ranges of IP phone MAC addresses: 00-80-9F-54-xx-xx to 00-80-9F-64-xx-xx 00-80-9F-66-xx-xx to 00-80-9F-6F-xx-xx In addition to prioritizing IP phone traffic, it is also possible to automatically prioritize non-IP phone traffic. This is done by adding up to four MAC addresses or four ranges of MAC addresses to the predefined QoS alaPhone MAC address group. Note that when automatic prioritization of IP phone traffic is enabled, QoS policies that specify priority are not applied to the IP phone traffic. Other QoS policies, however, are applied to this type of traffic as usual. If a policy specifies rate limiting, then the policy with the lowest rate limiting value is applied.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 513 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using Quarantine Manager and Remediation

Quarantine Manager and Remediation (QMR) is a switch-based application that interacts with the OmniVista Quarantine Manager (OVQM) application to restrict the network access of quarantined clients and provide a remediation path for such clients to regain their network access. This functionality is driven by OVQM, but the following QMR components are configured through QoS CLI commands: Quarantined MAC address group. This is a reserved QoS MAC address group that contains the MAC addresses of clients that OVQM has quarantined and that are candidates for remediation. The default name of this group is Quarantined, but the user can specify a different name using the qos quarantine Mac-group command. Remediation server and exception subnet group. This is a reserved QoS network group, called alaExceptionSubnet, that is configured with the IP address of a remediation server and any subnets to which a quarantined client is allowed access. The quarantined client is redirected to the remediation server to obtain updates and correct its quarantined state. IP addresses are added to this group using the policy network group command. Remediation server URL. The qos quarantine path command is used to specify a URL for the remediation server. Note that this done in addition to specifying the server IP address in the alaException-Subnet network group. Quarantined Page. When a client is quarantined and a remediation server URL is not configured, QMR can send a Quarantine Page to notify the client of its quarantined state. To enable or disable the sending of a Quarantine Page, use the qos quarantine page command. HTTP proxy port group. This is a known QoS service group, called alaHTTPProxy, that specifies the HTTP port to which quarantined client traffic is redirected for remediation. The default HTTP port used is TCP 80 and TCP 8080. To specify a different HTTP port, use the policy service group command.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 514 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using the QoS Log

The QoS software in the switch creates its own log for QoS-specific events. You may modify the number of lines in the log or change the level of detail given in the log. The PolicyView application, which is used to create QoS policies stored on an LDAP server, may query the switch for log events; or log events can be immediately available to the PolicyView application via a CLI command. Log events may also be forwarded to the console in real time. By default, only the most basic QoS information is logged. The type of information that may be logged includes rules, Layer 2 and Layer 3 information, etc. By default the QoS log displays a maximum of 256 lines.

Forwarding Log Events to PolicyView / Console

In addition to managing policies created directly on the switch, the switch manages policies downloaded from an external LDAP server. These policies are created externally through the PolicyView NMS application. PolicyView may query the switch for logged QoS events. Use the qos forward log command to make QoS log events available to PolicyView in real time. QoS log messages may also be sent to a console attached directly to the switch. By default, QoS log messages are not sent to the console though. The QoS log can get large if invalid rules are configured on the switch, or if a lot of QoS events have taken place. Clearing the log makes the file easier to manage.

Classifying Bridged Traffic as Layer 3

In some network configurations you may want to force the switch to classify bridged traffic as routed (Layer 3) traffic. Typically this option is used for QoS filtering. The Layer 3 classification of bridged traffic is no different from the classification of normal Layer 3 routed traffic. Note; that this implementation of QoS always performs Layer 3 classification of bridged traffic; it is not an option. As a result, Layer 3 ACLs are always effected on bridged traffic. The switch may bridge and route traffic to the same destination. Bridged IP packets are prioritized based on ToS, not 802.1p. Note that Layer 3 ACLs are affected on bridged IP traffic and Layer 2 ACLs are affected on routed traffic.

The Statistics Interval

The switch polls the network interfaces for QoS statistics and the polling frequency can always be changed. The default is 60 seconds.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 515 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

QoS Ports and Queues

Queue parameters may be modified on a port basis. When a flow coming into the switch matches a policy, it is queued based on: Parameters given in the policy action (specified by the policy action command) with either of the following keywords: priority, minimum bandwidth, or maximum bandwidth. Port settings configured through the qos port command.

Shared Queues
Eight priority queues are available at startup for each port. Flows always share queues; however, when a shared action is specified in policies, the policies will use the same values to implement maximum and minimum bandwidth. Note that the OmniSwitch 6800 also has eight priority queues per port but that two of these queues are reserved for internal use and are not available.

Prioritizing and Queue Mapping

QoS prioritizes packets by placing them in a higher priority egress queue. As previously mentioned, there are eight egress queues available for each port. In addition, there are different queuing algorithms available for egressing packets of different priorities. The algorithm used is determined by which servicing mode is active for the egress port. The egress priority of a packet is determined using one of the following methods: 1. If a packet matches a QoS policy rule that sets a priority value, the egress priority for the packet is set using the value specified in the rule. 2. If a packet ingressing on a trusted port does not match any QoS policy rule that sets the priority, then the egress priority for the packet is set using the existing DSCP value (IP packets), the existing 802.1p value (non-IP packets), or the default classification priority value for the port. See Configuring Trusted Ports on page 30-28 for more information. 3. The egress priority for a packet ingressing on a VLAN Stacking port (a trusted port) is set using the existing 802.1p value or configured through an associated VLAN Stacking service. 4. If a packet ingressing on an untrusted port does not match any QoS rule that sets the priority, then the egress priority for the packet is set using the default 802.1p value configured for the port on which the packet was received. See Trusted and Untrusted Ports on page 30-27 for more information. 5. Note that the 802.1p bit for tagged packets ingressing on untrusted ports is set with the default 802.1p value, which is configured using the qos port default 802.1p command. If the packet is untagged, however, then the DSCP bit is set with the default DSCP value, which is configured using the qos port default dscp command. Use the following table to see how packets are directed to the appropriate queues:

Priority to Queue Mapping Table

802.1p 0 1 2 3 4 5 6 7 ToS/DSCP 000xxx 001xxx 010xxx 011xxx 100xxx 101xxx 110xxx 111xxx Rule (action) Priority 0 1 2 3 4 5 6 7 OS6850/9000 Queue 0 1 2 3 4 5 6 7 OS6800 Queue 0 0 2 3 4 5 6 7

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 516 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Queuing Schemes
There are four queuing schemes available for each switch port: one strict priority scheme and three weighted fair queuing (WFQ) schemes. By default the strict priority scheme is used and consists of eight priority queues (SPQ). All eight queues on the port are serviced strictly by priority. Lower priority traffic is dropped in the presence of higher priority traffic. The following WFQ schemes are available: WRRAll queues participate in a weighted round robin scheme. Traffic is serviced from each queue based on the weight of the queue. Note that the WRR scheme is not supported on the OmniSwitch6800, 9700, or 9800. Priority-WRRA type of WRR scheme that combines Strict-Priority queues (zero weight) and WRR queues (non-zero weight). Note that Priority-WRR is the only WFQ scheme supported on the OmniSwitch 6800. DRRAll queues participate in a deficit round robin scheme. Traffic is serviced from each queue based on the weight of the queue. The weight of each of the WRR/DRR queues is a configurable value. Note the following when configuring WRR/DRR queue weights: Weights are configured with a value between 0 and 15. The default weight for each WRR/DRR queue is set to one. Each queue can have a different weight value, and configuring these values in ascending or descending order is not required. When a queue is given a weight of 0, it is configured as a Strict-Priority queue. The CLI requires the user to enter eight queue weights on the OmniSwitch 6800, even though there are only six queues per port available on this switch. The last two weight values entered are ignored. A Priority-WRR scheme is configured by assigning a weight of zero to one or more WRR queues to make them StrictPriority queues and a non-zero weight to the other WRR queues. Note that a Priority-WRR scheme is the only WFQ scheme that is supported on the OmniSwitch 6800. If there are multiple SPQs configured, the SPQs are scheduled according to their CoS queue number before any WFQs are scheduled. The weight assigned to a WRR queue designates the number of packets the queue sends out before the scheduler moves on to the next queue. For example, a queue weight of 10 sends out 10 packets at each interval. The weight assigned to a DRR queue determines the number of bytes that the queue will service. Each weight value is associated with the following number of bytes: 1=10K, 2=20K, 3=40K, 4=80K, 5=160K, 6=320K, 7=640K, 8=1280K, 9=2560K, 10=5120K, 11=10M, 12=20M, 13=40M, 14=80M, and 15=160M. For example, if the configured DRR queue weights are 1 1 2 2 3 3 4 4, queues 1/2 will service up to 10K each, queues 3/4 will service up to 20K each, queues 5/6 will service up to 40K each, and queues 7/8 will service up to 80K. The higher the queue weight assigned to a DRR queue, the higher the percentage of traffic that is serviced by that queue. For example, a queue with a weight of three will send four times as much traffic as a queue with a weight of one. The queuing scheme selected is the scheme that is used to shape traffic on destination (egress) ports and is referred to as the QoS servicing mode for the port. It is possible to configure a default servicing mode that will apply to all switch ports or configure the servicing mode on an individual port basis. Note that the QoS servicing mode only applies to destination ports because it is at this point where traffic shaping is effected on the flows. In addition, different ports can use different servicing modes.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 517 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Trusted and Untrusted Ports

By default switch ports are not trusted; that is, they do not recognize 802.1p or ToS/DSCP settings in packets of incoming traffic. When a port is not trusted, the switch sets the 802.1p or ToS/DSCP bits in incoming packets to the default 802.1p or DSCP values configured for that port. The qos port default 802.1p and qos port default dscp commands are used to specify the default 802.1p and ToS/DSCP values. If no default is specified, then these values are set to zero. Note that on the OmniSwitch 6800 Series switch, the 802.1p bit for tagged packets received on untrusted ports is set with the default 802.1p value. If the packet is untagged, however, then the DSCP bit is set with the default DSCP value. Fixed (non-mobile) ports that are configured for 802.1Q are always trusted, regardless of QoS settings. They cannot be configured as untrusted. Mobile ports are also always trusted; however, mobile ports may or may not accept Q-tagged traffic. Note: Mobile ports cannot be Q-tagged like fixed ports; however, a mobile port will join a tagged VLAN if tagged traffic for that VLAN comes in on the mobile port and the vlan mobile-tag command is enabled for that VLAN. Ports must be both trusted and configured for 802.1Q traffic in order to accept 802.1p traffic. The following applies to ports that are trusted (for 802.1p traffic, the ports must also be able to accept 802.1Q packets): The 802.1p or ToS/DSCP value is preserved. If the incoming 802.1p or ToS/DSCP flow does not match a policy, the switch places the flow into a default queue and prioritizes the flow based on the 802.1p or ToS/DSCP value in the flow. If the incoming 802.1p or ToS/DSCP flow matches a policy, the switch queues the flow based on the policy action. The switch may be set globally so that all ports are trusted. Individual ports may be configured to override the global setting. Whether or not the port is trusted is important if you want to classify traffic with 802.1p bits. If the policy condition specifies 802.1p, the switch must be able to recognize 802.1p bits. Note that the trusted port must also be 802.1Q-tagged.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 518 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Policies
Basic commands for creating policies are as follows: Policy condition Policy action Policy rule Note. A policy rule may include a policy condition or a policy action that was created through PolicyView rather than the CLI. But a policy rule, policy action, or policy condition may only be modified through the source that created it. For example, if an action was created in PolicyView, it may be included in a policy rule configured through the CLI, but it cannot be modified through the CLI.

ASCII-File-Only Syntax
When the policy rule, policy condition, and policy action commands as well as any of the condition group commands are configured and saved in an ASCII file (typically through the snapshot command), the commands included in the file will include syntax indicating the commands origin. The origin specifies where the rule, condition, condition group, or action was created, either an LDAP server or the CLI (from ldap or from CLI).

Policy Conditions
There are many options for configuring a condition. But, it all depends on how the user wants the switch to classify traffic for a given policy. The following conditions are supported and may be combined with other conditions and/or actions: Layer-1source port, source port group, destination port, destination port group Layer-2source MAC, source MAC group, destination MAC, destination MAC group, 802.1p, inner 802.1p, ether-type, source VLAN, inner source VLAN, destination VLAN (multicast policies only). Layer 3IP protocol, source IP, source IPv6, multicast IP, destination IP, destination IPv6, source network group, destination network group, multicast network group, IPv6 traffic, IPv6 next header (NH), IPv6 flow label (FL), ToS, DSCP, ICMP type, ICMP code. Layer-4source TCP/UDP port, destination TCP/UDP port, service, service group, TCP flags (ECN and CWR are only supported on the OmniSwitch 6800) IP MulticastAn IP multicast condition is used in IGMP ACLs. The multicast IP is the multicast group address used in the IGMP report packet. Note. The group options refer to groups of addresses, services, or ports that you configure separately through policy group commands. Rather than creating a separate condition for each address, service, or port, use groups and attach the group to a single condition. More than one condition parameter may be specified. Some condition parameters though are mutually exclusive.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 519 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Policy Actions
A policy action should specify the way traffic should be treated. For example, it might specify a priority for the flow, a source address to rewrite in the IP header, or it may specify that the flow may simply be dropped. More than one action parameter may be specified. Some parameters may be mutually exclusive. In addition, some action parameters are only supported with particular condition parameters. Policy Actions that are supported: ACL (Disposition drop) Priority Maximum bandwidth 802.1p, ToS/DSCP Stamping and Mapping Port-disable (not supported on the OS6800) Redirect port (not supported on the OS6800) Redirect linkagg (not supported on the OS6800 & OS6850) Permanent Gateway IP (not supported on the OS6800 & OS6850) Mirror (not supported on the OS6800) Note. If you combine priority with 802.1p, dscp, tos, or map, in an action, the priority value is used to prioritize the flow.

Rule Precedence
The switch attempts to classify flows coming into the switch according to policy precedence. Only the rule with the highest precedence will be applied to the flow. This is true even if the flow matches more than one rule. Precedence is particularly important for Access Control Lists (ACLs).

How Precedence is Determined

When there is a conflict between rules, precedence is determined using one of the following methods: Precedence valueEach policy has a precedence value. The value may be user-configured through the policy rule command in the range from 0 (lowest) to 65535 (highest). (The range 30000 to 65535 is typically reserved for PolicyView.) By default, a policy rule has a precedence of 0. Configured rule orderIf a flow matches more than one rule and both rules have the same precedence value, the rule that was configured first in the list will take precedence.

Rules with Compatible Actions

More than one rule may have the same condition. For example, two Layer 3 rules may have the same IP address condition but different actions. If the actions are compatible, both rules will be applied to the flow, regardless of the precedence settings. In this example, the rules are created with the default precedence (0) value.

Rules with Conflicting Actions

If the actions are in conflict, however, the switch will apply only the rule with the highest precedence.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 520 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Testing Conditions
Before applying policies to the configuration through the qos apply command, you may want to see how the policies will be used to classify traffic. Or you may want to see how theoretical traffic would be classified by policies that are already applied on the switch. You can use the show policy classify commands to see how the switch will classify certain condition parameters. This command is used to examine the set of pending policies only. Use the applied keyword with the command to examine the applied set of policies only. The command includes a keyword (l2, l3, multicast) to indicate whether the Layer-2, Layer-3, or multicast classifier should be used to classify the traffic. The keywords used with these commands are similar to the keywords used for the policy condition command. The keyword should be relevant to the type of traffic as listed in the table here:
show policy classify l2 Source port Destination port Source mac Destination mac Source vlan show policy classify l3 Source port Destination port Source ip Destination ip Source & Destination IPv6 IP Protocol IPv6 Nh Flow-label Source ip port Destination ip port Tos Dscp Destination port Destination mac Destination vlan (multicast only) Destination ip

To test a theoretical condition against the set of pending policies, enter the command and the relevant keyword and value. The switch will display information about the potential traffic and attempt to match it to a policy (pending policies only).

Using Condition Groups in Policies

Condition groups are made up of multiple IPv4 addresses, MAC addresses, services, or ports to which you want to apply the same action or policy rule. Instead of creating a separate condition for each address, etc., create a condition group and associate the group with a condition. Groups are especially useful when configuring filters, or Access Control Lists (ACLs); they reduce the number of conditions and rules that must be entered. Access Control Lists (ACLs) typically use condition groups in policy conditions to reduce the number of rules required to filter particular types of traffic.

Using Network Groups

Use network policy groups for policies based on IPv4 source or destination address. The policy condition will specify whether the network group is a source network group, destination network group, or multicast network group. Default switch groupNote that by default the switch contains a network group called switch that includes all IP addresses configured for the switch itself. This network group may also be used in policy conditions. ACLsTypically network groups are used for Access Control Lists. A network policy group can be created by the use of the policy network group command. You can specify the name of the group and the IP address(s) to be included in the group. Each IP address should be separated by a space. A mask may also be specified for an address. If a mask is not specified, the address is assumed to be a host address.

Using Services & Service Groups

Policy services are made up of TCP or UDP ports or port ranges. They include source or destination ports, or both, but the ports must be the same type (TCP or UDP). Mixed port types cannot be included in the same service. Policy services may be associated with policy service groups, which are then associated with policy conditions; or they may be directly associated with policy conditions. An IP protocol (TCP or UDP), source IP port and/or destination IP port (or port range) must be associated with a service. IP port numbers are well-known port numbers defined by the IANA. For example, port numbers for FTP are 20 and 21; Telnet is 23. Service groups are made up of policy services. You can first configure the policy service, and then create the service group, which includes the policy service(s). OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 521 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Note. The policy service group can include only services with all source ports, all destination ports, or all source and destination ports. For example, the group cannot include a service that specifies a source port and another service that specifies a destination port.

Using MAC Groups

MAC groups are made up of multiple MAC addresses that you want to attach to a condition. The MAC group may be associated with a condition through the policy condition command. Note that the policy condition usually specifies whether the group should be used for source or destination.

Using Port Groups

Port groups are made up of slot and port number combinations. Note that there are many built-in port groups, one for each slot on the switch. Built-in port groups are subdivided by slice. The built in groups are named by slot (Slot01, Slot02, etc.). To view the built-in groups, use the show policy port group command. Note: slot is the term applicable to an NI module.

Port Groups and Maximum Bandwidth

Maximum bandwidth policies are applied to source (ingress) ports and/or flows. If a port group condition is used in the policy, the bandwidth value specified is shared across all ports in the group. This also applies to flows that involve more than one port. For example, if a policy specifies a maximum bandwidth value of 10M for a port group containing 4 ports, the total bandwidth limit enforced is 10M for all 4 ports. Note the following when configuring ingress maximum bandwidth policies: On an OmniSwitch 6800 switch, bandwidth shaping is done on a per port basis and is not shared across multiple ports. If a policy condition applies to ports that are located on different slots, the maximum bandwidth limit specified is multiplied by the number of slots involved. For example, if a rule is configured to apply a maximum bandwidth limit of 10M to ports 1/1, 3/10, and 4/5, then the actual bandwidth limit enforced for all three ports is 30M. The maximum traffic received by a destination port is also dependant on how many slots are sending traffic to the destination port. However, each slot is restricted to sending only 10k. If a policy condition applies to ports that are all on the same slot, then the maximum bandwidth value specified in the rule is not increased. Ingress bandwidth limiting is done using a granularity of 64K bps. The show active policy rule command displays the number of packets that were dropped because they exceeded the ingress bandwidth limit applied by a maximum bandwidth policy. Although bandwidth policies are applied to ingress ports, it is possible to specify a destination port or destination port group in a bandwidth policy as well. Doing so will effect egress rate limiting/egress policing on the ingress port itself. The limitation of bridged port traffic only on destination ports applies in this case as well on the OmniSwitch 6850 and 9700. The following subsections provide examples of ingress maximum bandwidth policies using both source and destination port groups.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 522 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Source Port Group Example

In the following example, a port group (pgroup) is created with two ports and attached to a policy condition (Ports). A policy action with maximum bandwidth is created (MaxBw). The policy condition and policy action are combined in a policy rule called PortRule. -> Policy port group pgroup 1/1-2 -> Policy condition Ports source port group pgroup -> Policy action MaxBw maximum bandwidth 10k -> Policy rule Port Rule condition Ports action MaxBw In this example, if both ports 1 and 2 are active ports, the 10000 bps maximum bandwidth is shared by both ports. In other words, maximum bandwidth policies for port groups define a maximum bandwidth value that is a total bandwidth amount for all ports, not an amount for each port.

Destination Port Group Examples

In the following example, a port group (pgroup2) is created with several ports and attached to a policy condition (Ports2). A policy action with maximum bandwidth is created (MaxBw). The policy condition and policy action are combined in a policy rule called PortRule2. -> Policy port group pgroup2 1/1 1/25 2/1 -> Policy condition Ports2 destination port group pgroup2 -> Policy action MaxBw maximum bandwidth 10k -> Policy rule PortRule2 condition Ports2 action MaxBw In this example, the specified ports for pgroup2 span across two slots. As a result, the maximum bandwidth limit specified by the policy action is increased to 20K for all of the ports. The bandwidth limit is increased by multiplying the number of slots by the specified bandwidth value.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 523 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using Map Groups

Map groups are used to map 802.1p, ToS, or DSCP values to different values. The following mapping scenarios are supported: QoS mapping: 802.1p to 802.1p & ToS & DSCP, ToS to ToS & 802.1p & DSCP, DSCP to DSCP & 802.1p & ToS 802.1p to 802.1p, based on Layer 2, Layer 3, and Layer 4 parameters and source/destination slot/port. In addition, 802.1p classification can trigger this action. ToS or DSCP to 802.1p based on Layer 3 and Layer 4 parameters and source/destination slot/port. In addition ToS or DSCP classification can trigger this action. Note. Map groups are associated with a policy action.

How Map Groups Work

When mapping from 802.1p to 802.1p, the action will result in re-mapping the specified values. Any values that are not specified in the map group are preserved. In this example, a map group is created for 802.1p bits. -> Policy map group Group2 1-2:5 4:5 5-6:7 -> Policy action Map1 map 802.1p to 802.1p using Group2 The to and from values are separated by a colon (:). If traffic with 802.1p bits comes into the switch and matches a policy that specifies the Map1 action, the bits will be remapped according to Group2. If the incoming 802.1p value is 1 or 2, the value will be mapped to 5. If the incoming 802.1p value is 3, the outgoing value will be 3 (the map group does not specify any mapping for a value of 3). If the incoming 802.1p value is 4, the value will be mapped to 5. If the incoming 802.1p value is 5 or 6, the value will be mapped to 7. When mapping to a different type of value, however (ToS/DSCP to 802.1p), any values in the incoming flow that matches the rule but that are not included in the map group will be zeroed out. For example, the following action specifies the same map group but instead specifies mapping 802.1p to ToS: -> Policy action Map2 map tos to 802.1p using Group2 In this case, if ToS traffic comes into the switch and matches a policy that specifies the Map2 action, the ToS value will be mapped according to Group2 if the value is specified in Group2. If the incoming ToS value is 2, the value will be mapped to 5; however, if the incoming value is 3, the switch will map the value to zero because there is no mapping in Group2 for a value of 3. Note. Ports on which the flow is mapped must be a trusted port; otherwise the flow will be dropped.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 524 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Policy Applications
Policies are used to classify incoming flows and treat the relevant outgoing flows. There are many ways to classify the traffic and many ways to apply QoS parameters to the traffic. Classifying traffic may be as simple as identifying a Layer 2 or Layer 3 address of an incoming flow. Treating the traffic might involve prioritizing the traffic or rewriting an IP address. How the traffic is treated (the action in the policy rule) typically defines the type of policy: Type of Policy Description Action Parameters Used Basic QoS policies Prioritizes particular Maximum bandwidth flows, and/ or shapes the Priority bandwidth for the flow Redirects flows to a redirect port Redirection policies specific port redirect linkagg or link aggregate ID. Policy Based Mirroring Mirrors ingress and egress ingress mirror packets egress mirror to a specific port. ingress egress mirror Filters, prioritizes, and/or Disposition ICMP policies rate limits ICMP traffic Priority Maximum bandwidth Sets or resets the egress 802.1p 802.1p, ToS, and DSCP 802.1p, ToS, or DSCP TOS tagging or mapping policies values DSCP Map group Redirects routed traffic. permanent ip Policy Based Routing Note that PBR is not (PBR) supported on the OmniSwitch 6800 and 6850. Access Control Lists Groups of policies rules Disposition used for filtering traffic (ACLs) (allow/deny) Policies used for Layer 2 and Layer 3/4 filters, are commonly referred to as Access Control Lists (ACLs). Policies may also be used for prioritizing traffic in dynamic link aggregation groups.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 525 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Basic QoS Policies

Traffic prioritization and bandwidth shaping may be the most common types of QoS policies. For these policies, any condition may be created; the policy action indicates how the traffic should be prioritized or how the bandwidth should be shaped.

Note. If multiple addresses, services, or ports should be given the same priority, use a policy condition group to specify the group and associate the group with the condition. Note that some condition parameters may be used in combination only under particular circumstances; also, there are restrictions on condition/action parameter combinations.

Basic Commands
The following policy action commands are used for traffic prioritization or shaping: Policy action priority Policy action maximum bandwidth

Traffic Prioritization Example

In this example, IP traffic is routed from the 10.10.4.0 network through the OmniSwitch.

To create a policy rule to prioritize the traffic from Network 1, first create a condition for the traffic that you want to prioritize. In this example, the condition is called ip_traffic. Then create an action to prioritize the traffic as highest priority. In this example, the action is called high. Combine the condition and the action into a policy rule called rule1. -> Policy condition ip_traffic source ip 10.10.4.0 mask 255.255.255.0 -> Policy action high priority 7 -> Policy rule rule1 condition ip_traffic action high The rule is not active on the switch until the qos apply command is entered on the command line. When the rule is activated, any flows coming into the switch from 10.10.4.0 will be given the highest priority.

Bandwidth Shaping Example

In this example, a specific flow from a source IP address is sent to a queue that will support its maximum bandwidth requirement. First, create a condition for the traffic. In this example, the condition is called ip_traffic2. A policy action (flowShape) is then created to enforce a maximum bandwidth requirement for the flow. -> Policy condition ip_traffic2 source ip 10.10.5.3 -> Policy action flowShape maximum bandwidth 1k -> Policy rule rule2 condition traffic2 action flowShape Note that the bandwidth may be specified in abbreviated units, in this case, 1k. The rule is not active on the switch until the qos apply command is entered. When the rule is activated, any flows coming into the switch from source IP address 10.10.5.3 will be queued with no more than 1k of bandwidth. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 526 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Redirection Policies
A redirection policy sends traffic that matches the policy to a specific port or link aggregate instead of the originally intended destination. This type of policy may use any condition; the policy action determines which port or link aggregate to which the traffic is sent. The following policy action commands are used for port and link aggregate redirection: policy action redirect port policy action redirect linkagg Note the following regarding the use and configuration of redirection policies: Redirection policies apply to both bridged and routed traffic. When redirecting routed traffic from VLAN A to VLAN B, the redirect port or link aggregate ID must belong to VLAN B (tagged or default VLAN). Routed packets (from VLAN A to VLAN B) are not modified after they are redirected; the source and MAC address remain the same. In addition, if the redirect port or link aggregate ID is tagged, the redirected packets will have a tag from the ingress VLAN A. If a route exists for the redirected flow, then redirected packets are the final post-routing packets. If a route does not exist for the redirected flow, the flow is not redirected to the specified port or link aggregate ID and is blackholed. As soon as a route is available, the flow is then redirected as specified in the policy. In most cases, a redirected flow will not trigger an update to the routing and ARP tables. When the ARP table is cleared or timed out, port/link aggregate redirection will cease until the ARP table is refreshed. If necessary, create a static route for the flow or assign the redirect port or link aggregate ID to the ingress VLAN (VLAN A) to send packets to the redirect port until a route is available. When redirecting bridged traffic on VLAN A, the redirect port or link aggregate ID must belong to VLAN A (tagged or default VLAN). In the following example, flows destined for UDP port 80 is redirected to switch port 3/2: -> policy condition L4PORTCOND destination udp port 80 -> policy action REDIRECTPORT redirect port 3/2 -> policy rule L4PORTRULE condition L4PORTCOND action REDIRECTPORT In the following example, flows destined for IP address 40.2.70.200 are redirected to link aggregate 10: -> policy condition L4LACOND destination IP 40.2.70.200 -> policy action REDIRECTLA redirect linkagg 10 -> policy rule L4LARULE condition L4LACOND action REDIRECTLA Note that in both examples above, the rules are not active on the switch until the qos apply command is entered on the command line.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 527 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Policy Based Mirroring

A mirroring policy sends a copy of ingress, egress, or both ingress and egress packets that match the policy condition to a specific port. This type of policy may use any condition; the mirror policy action determines the type of traffic to mirror and the port on which the mirrored traffic is received. The policy action mirror command is used to configure mirror-to-port (MTP) action for the policy. For example, the following policy mirrors ingress packets to port 1/10: -> policy condition c1 source ip 192.168.20.1 -> policy action a1 mirror ingress 1/10 -> policy rule r1 condition c1 action a1 -> qos apply When the above rule is activated, any flows coming into the switch from source IP address 192.168.20.1 are mirrored to port 1/10. It is also possible to combine the MTP action with other actions. For example: -> policy condition c1 source ip 192.168.20.1 -> policy action a1 mirror ingress 1/10 disposition drop -> policy rule r1 condition c1 action a1 -> qos apply This policy rule example combines the MTP action with the drop action. As a result, this rule drops ingress traffic with a source IP of 192.168.20.1, but the mirrored traffic from this source is not dropped and is forwarded to port 1/10. Note the following regarding the use and configuration of mirroring policies: Only one policy-based MTP session is supported at any given time. As a result, all mirroring policies should specify the same destination port. In addition to one policy-based MTP session, the switch can support one port-based mirroring session, one remote port mirroring session, and one port monitoring session all running at the same time. Policy based mirroring and the port-based mirroring feature can run simultaneously on the same port. However, policy based mirroring is not supported on the OmniSwitch 6800. Rule precedence is applied to all mirroring policies that are configured for the same switch ASIC. If traffic matches a mirror rule on one ASIC with a lower precedence than a non-mirroring rule on a different ASIC, the traffic is mirrored in addition to the actions specified by the higher precedence rule.

ICMP Policy Example

Policies may be configured for ICMP on a global basis on the switch. ICMP policies may be used for security (for example, to drop traffic from the ICMP blaster virus). In the following example, a condition called icmpCondition is created with no other condition parameters: -> Policy condition icmpCondition ip protocol 1 -> Policy action icmpAction disposition deny -> Policy rule icmpRule condition icmpCondition action icmpAction This policy (icmpRule) drops all ICMP traffic. To limit the dropped traffic to ICMP echo requests (pings) and/or replies, use the policy condition icmptype to specify the appropriate condition. For example: -> Policy condition echo icmptype 8 -> Policy condition reply icmptype 0

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 528 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

802.1p and ToS/DSCP Marking and Mapping

802.1p values may be mapped to different 802.lp values on an individual basis or by using a map group. In addition, ToS or DSCP values may be mapped to 802.1p on a case-by-case basis or via a map group. (Note that any other mapping combination is not supported.) Marking is accomplished with the following commands: Policy action 802.1p Policy action tos Policy action dscp Mapping is accomplished through the following commands: Policy map group Policy action map Note the following: Priority for the flow is based on the policy action. The value specified for 802.1p, ToS, DSCP, or the map group would determine how the flow is queued. The port on which the flow arrives (the ingress port) must be a trusted port. In this example, a policy rule (marking) is set up to mark flows from 10.10.3.0 with an 802.1p value of 5: -> Policy condition my_condition source ip 10.10.3.0 mask 255.255.255.0 -> Policy action my_action 802.1p 5 -> Policy rule marking condition my_condition action my_action In the next example, the policy map group command specifies a group of values that should be mapped; the policy action map command specifies what should be mapped (802.1p to 802.1p, ToS/DSCP to 802.1p) and the mapping group that should be used. Here, traffic from two different subnets must be mapped to 802.1p values in a network called Network C. A map group (tosGroup) is created with mapping values. -> Policy map group tos_group 1-4:4 5-7:7 -> Policy condition SubnetA source ip 10.10.5.0 mask 255.255.255.0 -> Policy condition SubnetB source ip 12.12.2.0 mask 255.255.255.0 -> Policy action map_action map tos to 802.1p using tos_group The map_action specifies that ToS values will be mapped to 802.1p with the values specified in tos_group. With these conditions and action set up, two policy rules can be configured for mapping Subnet A and Subnet B to the ToS network: -> Policy rule RuleA condition SubnetA action map_action -> Policy rule RuleB condition SubnetB action map_action

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 529 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Policy Based Routing

Policy Based Routing (PBR) allows a network administrator to define QoS policies that will override the normal routing mechanism for traffic matching the policy condition. This feature is only supported on the OmniSwitch 6850/9000 Series; it is not available on the OmniSwitch 6800. Note. When a PBR QoS rule is applied to the configuration, it is applied to the entire switch, unless you specify a built-in port group in the policy condition. Policy Based Routing may be used to redirect traffic to a particular gateway based on source or destination IP address, source or destination network group, source or destination TCP/UDP port, a service or service group, IP protocol, or built-in source port group. Traffic may be redirected to a particular gateway regardless of what routes are listed in the routing table. Note that the gateway address does not have to be on a directly connected VLAN; the address may be on any network that is learned by the switch. Note. If the routing table has a default route of 0.0.0.0, traffic matching a PBR policy will be redirected to the route specified in the policy. Policy Based Routing may be used to redirect untrusted traffic to a firewall. In this case, note that reply packets will be not be allowed back through the firewall.

In this example, all traffic originating in the 10.3 network is routed through the firewall, regardless of whether or not a route exists. Note that the functionality of the firewall is important. In the example, the firewall is sending the traffic to be routed remotely. If you instead set up a firewall to send the traffic back to the switch to be routed, you should set up the policy condition with a built-in source port group so that traffic coming back from the firewall will not get looped and sent back out to the firewall.

In this scenario, traffic from the firewall is sent back to the switch to be re-routed. But because the traffic re-enters the switch through a port that is not in the Slot01 port group, the traffic does not match the Redirect. All policy and is routed normally through the switch. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 530 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Server Load Balancing (SLB)

Alcatel-Lucents Server Load Balancing (SLB) software provides a method to logically manage a group of physical servers sharing the same content (known as a server farm) as one large virtual server (known as an SLB cluster). SLB clusters are identified and accessed at Layer 3 by the use of Virtual IP (VIP) addresses. OmniSwitch 6850/9000 switches operate at wire speed to process client requests addressed to the VIP of an SLB cluster and send them to the physical servers within the cluster. Using SLB clusters can provide cost savings (costly hardware upgrades can be delayed or avoided), scalability (as the demands on your server farm grow you can add additional physical servers), reliability (if one physical server goes down the remaining servers can handle the remaining workload), and flexibility (you can tailor workload requirements individually to servers within a cluster). Notes. SLB is supported on OmniSwitch 6850 and 9000 switches but not on OmniSwitch 6800 Series switches. You can also configure and monitor Server Load Balancing with WebView, Alcatel-Lucents embedded webbased device management application. WebView is an interactive and easy-to-use GUI that can be launched from OmniVista or a web browser.

Server Load Balancing Specifications

The table below lists specifications for Alcatel-Lucents SLB software.
Maximum number of clusters Maximum number of physical servers Layer-3 classification Server health checking High availability support Networking protocols supported Ping period range Ping Timeout range Ping retries Maximum number of probes on a switch Probe timeout range Probe period range Probe port range Probe retry range Probe status range 16 75 Source IP address/Destination IP address pairs Ping, link checks Hardware-based failover, VRRP, Chassis Management Module (CMM) redundancy Virtual IP (VIP) addresses 0 to 3600 seconds 0 to 1000 times the value of the ping period 0 to 255 20 1 to 3600000 seconds 0 to 3600 0 to 65535 0 to 255 0 to 4294967295

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 531 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Server Load Balancing Defaults

The table below lists defaults for Alcatel-Lucents SLB software.
Global SLB administrative status Ping period Ping timeout Ping retries Administrative status of an SLB cluster Administrative status of physical servers in an SLB cluster SLB probes configured SLB probe timeout SLB probe period SLB probe port number SLB probe retries SLB probe user name SLB probe password SLB probe URL SLB probe expected status SLB probe send string SLB probe expect string Disabled 60 seconds 3000 milliseconds 3 Enabled Enabled None configured 3000 seconds 60 seconds 0 3 None configured None configured None configured 200 None configured None configured

Server Load Balancing Overview

In the current release, you can add up to 75 physical servers on an OmniSwitch 6850/9000. In addition, you can configure up to 16 Server Load Balancing (SLB) clusters on an OmniSwitch 6850/9000. Note. Alcatel-Lucent also offers link aggregation, which combines multiple Ethernet links into one virtual channel.

Server Load Balancing VIPs/Condition

Server load balancing uses a Virtual IP (VIP) address or a policy condition name to treat a group of physical servers, each with a unique IP address or a condition name, as one large virtual server. The switch will process requests by clients addressed to the VIP or condition of the SLB cluster and send them to the physical servers. This process is totally transparent to the client.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 532 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Server Load Balancing Example

In the figure on the following page, an SLB cluster consisting of four (4) physical servers has been configured with a VIP of 128.241.130.204 and an SLB cluster name of World Wide Web. The switch processes requests sent by clients to the VIP of 128.241.130.204 and sends to the appropriate physical server, depending on configuration and the operational states of the physical servers. The switch then transmits the requested data from the physical server back to the client.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 533 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Server Health Monitoring

Alcatel-Lucents Server Load Balancing (SLB) software on the switch performs checks on the links from the switch to the servers. In addition, the SLB software also sends ICMP echo requests (i.e., ping packets) to the physical servers to determine their availability. The SLB software to determine the operational states of servers uses these health checks performed by the switch. The possible operational states are described in the table below:
Disabled No Answer Link Down Discovery In Service Retrying The server has been administratively disabled by the user The server has not responded to ping requests from the switch. There is a bad connection to the server. The switch is pinging a physical server. The server can be used for client connections. The switch is making another attempt to bring up the server.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 534 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IP Multicast Switching
IP Multicast Switching is a one-to-many communication technique employed by emerging applications such as video distribution, news feeds, conferencing, netcasting, and resource discovery (OSPF, RIP2, BOOTP). Unlike unicast, which sends one packet per destination, multicast sends one packet to all devices in any sub-network that has at least one device requesting the multicast traffic. Multicast switching also requires much less bandwidth than unicast techniques and broadcast techniques since the source hosts only send one data stream to the ports on which destination hosts that request it are attached. Destination hosts signal their intent to receive a specific multicast stream by sending a request to do so to a nearby switch using Internet Group Management Protocol (IGMP). The switch then learns on which ports multicast group subscribers are attached and can intelligently deliver traffic only to the respective ports. This mechanism is often referred to as IGMP snooping (or IGMP gleaning). Alcatel-Lucents implementation of IGMP snooping is called IP Multicast Switching (IPMS). IPMS allow OmniSwitch 6850 Series switches to efficiently deliver multicast traffic in hardware at wire speed. Note. You can also configure and monitor IPMS with WebView, Alcatel-Lucents embedded web-based device management application. WebView is an interactive and easy-to-use GUI that can be launched from OmniVista or a web browser.

IPMS Specifications
The table below lists specifications for Alcatel-Lucents IPMS software.
RFCs Supported RFC 1112 Host Extensions for IP Multicasting RFC 2236 Internet Group Management Protocol, Version 2 RFC 2933 Internet Group Management Protocol MIB RFC 3376 Internet Group Management Protocol, Version 3 Draft-ietf-magma-snoop Considerations for IGMP and MLD Snooping Switches 1 to 65535 seconds 1 to 65535 seconds 1 to 65535 seconds 1 to 65535 in tenths of seconds 1 to 65535 in tenths of seconds

IETF Internet-Drafts Supported IGMP Query Interval IGMP Router Timeout IGMP Source Timeout IGMP Query Response Interval IGMP Last Member Query Interval

IPv6MS Specifications
The table below lists specifications for Alcatel-Lucents IPv6MS software.
RFCs Supported RFC 2710 Multicast Listener Discovery for IPv6 RFC 3810 Multicast Listener Discovery Version 2 for IPv6 RFC 3019 IPv6 MIB for Multicast Listener Discovery Protocol Draft-ietf-magma-snoop Considerations for IGMP and MLD Snooping Switches 1 to 65535 seconds 1 to 65535 seconds 1 to 65535 seconds 1 to 65535 in milliseconds 1 to 65535 in milliseconds

IETF Internet-Drafts Supported MLD Query Interval MLD Router Timeout MLD Source Timeout MLD Query Response Interval MLD Last Member Query Interval

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 535 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IPMS Default Values

The table below lists default values for Alcatel-Lucents IPMS software.
Parameter Description Administrative Status IGMP Version IGMP Query Interval IGMP Last Member Query Interval IGMP Query Response Interval IGMP Router Timeout Source Timeout IGMP Querying IGMP Robustness IGMP Spoofing IGMP Zapping Default Value/Comments Disabled Version 2 125 seconds 10 tenth-of-seconds 10 tenth-of-seconds 90 30 seconds Disabled 2 Disabled Disabled

IPv6MS Default Values

The table below lists default values for Alcatel-Lucents IPv6MS software.
Parameter Description Administrative Status MLD Version MLD Query Interval MLD Last Member Query Interval MLD Query Response Interval MLD Router Timeout Source Timeout MLD Querying MLD Robustness MLD Spoofing MLD Zapping Default Value/Comments Disabled Versions 1 & 2 125 seconds 1000 milliseconds 10000 milliseconds 90 30 seconds Disabled 2 Disabled Disabled

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 536 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IPMS Overview
A multicast group is defined by a multicast group address, which is a Class D IP address in the range 224.0.0.0 to 239.255.255.255. (Addresses in the range 239.0.0.0 to 239.255.255.255 are reserved for boundaries.) The multicast group address is indicated in the destination address field of the IP header. IPMS track the source VLAN on which the Internet Group Management Protocol (IGMP) requests are received. The network interfaces verify that a multicast packet is received by the switch on the source (or expected) port. Note. Jumbo multicast packets are not supported. The maximum MTU size supported by Alcatel-Lucents IPMS software is 1500.

IPMS Example
The following figure shows an IPMS network where video content can be provided to clients that request it. A server is attached to the switch that provides the source (i.e., multicast) IP addresses. Clients from two different attached networks send IGMP reports to the switch to receive the video content.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 537 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Reserved Multicast Addresses

The Internet Assigned Numbers Authority (IANA) created the range for multicast addresses, which is 224.0.0.0 to 239.255.255.255. However, as the table below shows, certain addresses are reserved and cannot be used.
Address or Address Range 224.0.0.0 through 224.0.0.255 224.0.1.0 through 224.0.1.255 224.0.2.0 through 224.0.255.0 224.1.0.0 through 224.1.255.255 224.2.0.0 through 224.2.255.255 224.252.000.000 through 224.255.255.255 225.000.000.000 through 231.255.255.255 232.000.000.000 through 232.255.255.255 233.000.000.000 through 233.255.255.255 234.000.000.000 through 238.255.255.255 239.000.000.000 through 239.255.255.255 Description Routing protocols (e.g., OSPF, RIP2) Internetwork Control Block (e.g., RSVP, DHCP, commercial servers) AD-HOC Block (e.g., commercial servers) ST Multicast Groups SDP/SAP Block DIS Transient Groups Reserved Source Specific Multicast GLOP Block Reserved Administratively Scoped

IP Multicast Routing
IP multicast routing can be used for IP Multicast Switching and Routing (IPMSR). IP multicast routing is a way of controlling multicast traffic across networks. The IP multicast router discovers which networks want to receive multicast traffic by sending out Internet Group Management Protocol (IGMP) queries and receiving IGMP reports from attached networks. The IGMP reports signal that users want to join a multicast group. The IPv6 multicast router discovers multicast listeners by sending out Multicast Listener Discovery (MLD) Protocol queries and receiving MLD reports from attached networks. The MLD reports signal that users want to join a IPv6 multicast group. If there is more than one IP multicast router in the network, the router with the lowest IP address is elected as the querier router, which is responsible for querying the sub-network for group members. The IP multicast routing package provides the following two separate protocols: Protocol Independent Multicast Sparse Mode (PIM-SM) and Dense Mode (PIM-DM) Distance Vector Multicast Routing Protocol (DVMRP) The multicast routing protocols build and maintain a multicast routing database. The multicast routing protocols forward multicast traffic to networks that have requested group membership to a specific multicast group. IPMS uses decisions made by the routing protocols and forwards multicast traffic to ports that request group membership.

PIM
Protocol-Independent Multicast (PIM) is an IP multicast routing protocol that uses routing information provided by unicast routing protocols, such as RIP and OSPF. Sparse Mode PIM (PIM-SM) contrasts with flood-and-prune dense mode multicast protocols, such as DVMRP and PIM Dense Mode (PIM-DM), in that multicast forwarding in PIM-SM is initiated only via specific requests. Downstream routers must explicitly join PIM-SM distribution trees in order to receive multicast streams on behalf of directly connected receivers or other downstream PIM-SM routers. This paradigm of receiver-initiated forwarding makes PIM-SM ideal for network environments where receiver groups are thinly populated and bandwidth conservation is a concern, such as in Wide Area Networks (WANs). PIM-DM packets are transmitted on the same socket as PIM-SM packets as both use the same protocol and message format. Unlike PIM-SM, in PIM-DM there are no periodic joins transmitted; only explicitly triggered prunes and grafts. In PIM-DM, unlike PIM-SM, there is no Rendezvous Point (RP).

DVMRP
Distance Vector Multicast Routing Protocol (DVMRP) is a distributed multicast routing protocol that dynamically generates per-source delivery trees based upon routing exchanges. When a multicast source begins to transmit, the multicast data is flooded down the delivery tree to all points in the network. DVMRP then prunes (i.e., removes branches from) the delivery tree where the traffic is unwanted. This is in contrast to PIM-SM, which uses receiver-initiated (i.e., forward path) multicasting.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 538 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IPMS and Link Aggregation

When configuring IPMS and link aggregation on the same switch the following conditions should be kept in mind: When a port moves to a link aggregation group all IPMS configurations on the port will be lost. When the last port in a link aggregation group moves out of the group all IPMS configuration on the link aggregation group will be lost.

IGMP Version 3
IGMP is used by IPv4 systems (hosts and routers) to report their IP multicast group memberships to any neighboring multicast routers. IGMP version 2 (IGMPv2) handles forwarding by IP multicast destination address only. IGMP version 3 (IGMPv3) handles forwarding by source IP address and IP multicast destination address. OmniSwitch 6850 Series switches support IGMPv2 and IGMPv3. In IGMPv2, each membership report contains only one multicast group. In IGMPv3, membership reports contain many multicast groups up to the Maximum Transmission Unit (MTU) size of the interface. IGMPv3 uses source filtering and reports multicast memberships to neighboring routers by sending membership reports. IGMPv3 also supports Source Specific Multicast (SSM) by allowing hosts to report interest in receiving packets only from specific source addresses or from all but specific source addresses. Note. It should be noted that in the current release SSM packet forwarding is not done between ports in the same VLAN. However, SSM forwarding between different VLANs (routing) is supported. In addition, the current implementation of IGMPv3 and SSM only forwards packets to a list of included sources for a given multicast destination. Exclude list forwarding is not supported, as it is not a requirement for SSM, and specifically Protocol Independent MulticastSource Specific Multicast (PIM-SSM).

MLD
MLD is used by IPv6 systems (hosts and routers) to report their IPv6 multicast group memberships to any neighboring multicast routers. MLD Version 1 (MLDv1) handles forwarding by IPv6 multicast destination addresses only. MLD Version 2 (MLDv2) handles forwarding by source IPv6 addresses and IPv6 multicast destination addresses. The OmniSwitch 6850 switch supports MLDv1 and MLDv2. MLDv2 uses source filtering and reports multicast memberships to neighboring routers by sending membership reports. MLDv2 also supports Source Specific Multicast (SSM) by allowing hosts to report interest in receiving packets only from specific source addresses or from all but specific source addresses.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 539 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IPMS Application Example

The figure below shows a sample network with the switch sending multicast video. A client attached to Port 5 needs to be configured as a static neighbor and another client attached to Port 2 needs to be configured as a static querier. The network administrator has determined that due to slow responses from workstations that membership timeout needs to be 6 minutes (i.e., 3600 seconds) and the leave timeout needs to be two minutes (i.e., 120 seconds).

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 540 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Multicast Address Boundaries

Multicast boundaries confine scoped multicast addresses to a particular domain. Confining scoped addresses helps to ensure that multicast traffic passed within a multicast domain does not conflict with multicast users outside the domain.

Multicast Boundary Specifications

RFCs Supported Maximum Multicast Flows per switch Valid Scoped Address Range 2365Administratively Scoped IP Multicast 2932IPv4 Multicast Routing MIB 1,021 (with hardware routing; see note below) 239.0.0.0 to 239.255.255.255

Note. If software routing is used, the number of total flows supported is variable, depending on the number of flows and the number of routes per flow.

Multicast Address Boundaries Overview

Multicast Addresses and the IANA
The Internet Assigned Numbers Authority (IANA) regulates unique parameters for different types of network protocols. For example, the IANA regulates addresses for IP, DVMRP, PIM-SM, PIM-SSM, etc., and also provides a range of administratively scoped multicast addresses.

Administratively Scoped Multicast Addresses

Multicast addresses 239.0.0.0 through 239.255.255.255 have been reserved by the IANA as administratively scoped addresses for use in private multicast domains. These addresses cannot be used for any other protocol or network function. Because they are regulated by the IANA, network administrators can theoretically use these addresses without conflicting with networks outside of their multicast domains. However, to ensure that the addresses used in a private multicast domain do not conflict with other domains (e.g., within the company network or out on the Internet), multicast address boundaries must be configured.

Source-Specific Multicast Addresses

The Internet Assigned Numbers Authority (IANA) has reserved multicast addresses 232.0.0.0 through 232.255.255.255 as source-specific multicast (SSM) destination addresses. Addresses within this range are reserved for use by source-specific applications and protocols (e.g., PIM-SSM) and cannot be used for any other functions or protocols.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 541 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Multicast Address Boundaries

Without multicast address boundaries, multicast traffic conflicts can occur between domains. For example, a multicast packet addressed to 239.140.120.10 from a device in one domain could leak into another domain. If the other domain contains a device attempting to send a separate multicast packet with the same address, a conflict may occur. A boundary is used to eliminate these conflicts by confining multicast traffic on an interface (i.e., a VLAN router port). When a boundary is set, multicast packets with a destination address within the specified boundary will not be forwarded on the interface. The figure below provides an example of a multicast address boundary configured on an interface.

A router port is configured on VLAN 2, with the IP address 172.22.2.44. The router port is also referred to as the router interface; the IP address serves as the identifier for the interface. In this example, the multicast address boundary has been defined as 239.140.120.0. The mask value of 255.255.255.0 is shown in Classless Inter-Domain Routing (CIDR) prefix format as /24. This specifies that no multicast traffic addressed to multicast addresses 239.140.120.0 through 239.140.120.255 will be forwarded on interface 172.22.2.44.

Concurrent Multicast Addresses

Because multicast boundaries confine scoped multicast addresses to a particular domain, multicast addresses can be used concurrently in more than one region in the network. In other words, scoped multicast addresses can be reused throughout the network. This allows network administrators to conserve limited multicast address space. The figure below shows, multicast addresses 239.140.120.0 through 239.140.120.255 being used by both Multicast Domain 1 and Multicast Domain 2.

Although the same block of multicast addresses239.140.120.0 through 239.140.120.255is being used in two different domains at once, multicast traffic from one domain cannot conflict with multicast traffic in the other domain because they are effectively confined by boundaries on their corresponding interfaces. In this case, the boundary 239.140.120.0/24 has been configured on interfaces 172.22.2.120 and 178.14.1.43.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 542 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

DVMRP
This section includes descriptions for Distance Vector Multicast Routing Protocol (DVMRP). DVMRP is a dense-mode multicast routing protocol. DVMRPwhich is essentially a broadcast and prune routing protocolis designed to assist routers in propagating IP multicast traffic through a network.

DVMRP Specifications
RFCs Supported IETF Internet-Drafts Supported DVMRP Version Supported DVMRP Attributes Supported 2667IP Tunnel MIB Distance-Vector Multicast Routing Protocol MIB draft-ietf-idmr-dvmrp-v3-11.txt DVMRPv3.255 Reverse Path Multicasting, Neighbor Discovery, Multicast Source Location, Route Report Messages, Distance metrics, Dependent Downstream Routers, Poison Reverse, Pruning, Grafting, DVMRP Tunnels Flash update interval, Graft retransmissions, Neighbor probe interval, Neighbor timeout, Prune lifetime, Prune retransmission, Route report interval, Route holddown, Route expiration timeout 1 to 31 0 to 255 1 (e.g., you cannot enable both PIM-SM and DVMRP on the same IP interface)

DVMRP Timers Supported

Range for Interface Distance Metrics Range for Tunnel TTL Value Multicast Protocols per Interface

DVMRP Defaults
Parameter Description DVMRP load status DVMRP status DVMRP interface status Flash update interval Graft retransmission timeout Neighbor probe interval time Neighbor timeout Prune lifetime Prune retransmission timeout Route report interval Route holddown time Route expiration timeout Interface distance metric DVMRP tunnel status DVMRP tunnel TTL value Subordinate neighbor status Default Value/Comments Unloaded Disabled Disabled 5 seconds 5 seconds 10 seconds 35 seconds 7200 seconds 30 seconds 60 seconds 120 seconds 140 seconds 1 Disabled 255 True

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 543 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

DVMRP Overview
Distance Vector Multicast Routing Protocol (DVMRP) Version 3 is a multicast routing protocol that enables routers to efficiently propagate IP multicast traffic through a network. Multicast traffic consists of a data stream that originates from a single source and is sent to hosts that have subscribed to that stream. Live video broadcasts; video conferencing, corporate communications, distance learning, and distribution of software, stock quotes, and news services are examples of multicast traffic. Multicast traffic is distinguished from unicast traffic and broadcast traffic as follows: Unicast traffic is addressed to a single host. Broadcast traffic is transmitted to all hosts. Multicast traffic is transmitted to a subset of hosts (the hosts that have subscribed to the multicast data stream). DVMRP is a distributed multicast routing protocol that dynamically generates per-source delivery trees based upon routing exchanges, using a technique called Reverse Path Multicasting. When a multicast source begins to transmit, the multicast data is flooded down the delivery tree to all points in the network. DVMRP then prunes (i.e., removes branches from) the delivery tree where the traffic is unwanted. Pruning continues to occur as group membership changes or routers determine that no group members are present. This restricts the delivery trees to the minimum branches necessary to reach all group members, thus optimizing router performance. New branches can also be added to the delivery trees dynamically as new members join the multicast group. The addition of new branches is referred to as grafting.

Reverse Path Multicasting

DVMRP uses Internet Group Management Protocol (IGMP) messages to exchange the routing information needed to build per-source multicast delivery trees. Once built, packets follow a multicast delivery tree from the source to all members of the multicast group. Packets are replicated only at necessary branches in the delivery tree. The trees are calculated and updated dynamically to track the membership of individual groups. When a packet arrives on an interface, the reverse path back to the source of the packet is determined by examining a DVMRP routing table of known source networks. If the packet arrived on an upstream inter-face that would be used to transmit packets back to the source, it is forwarded to the appropriate list of downstream interfaces. Otherwise, it is not on the optimal delivery tree and is discarded. In this way duplicate packets can be filtered when loops exist in the network topology.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 544 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Neighbor Discovery
DVMRP routers must maintain a database of DVMRP adjacencies with other DVMRP routers. A DVMRP router must be aware of its DVMRP neighbors on each interface. To gather this information, DVMRP routers use a neighbor discovery mechanism and periodically multicast DVMRP Probe messages to the All-DVMRP-Routers group address (224.0.0.4). Each Probe message includes Neighbor List of DVMRP routers known to the transmitting router. When a DVMRP router (lets call it router B) receives a Probe (lets say from router A), it adds the IP address of router A to its own internal list of DVMRP neighbors on that interface. It then sends a Probe of its own with the IP address of router A included in the Probes Neighbor List. When a DVMRP router receives a Probe with its own IP address included in the Neighbor List, the router knows that a two-way adjacency has been successfully formed between itself and the neighbor that sent the Probe. Probes effectively serve three main purposes: Probes provide a mechanism for DVMRP routers to locate each other as described above. Probes provide a way for DVMRP routers to determine each others capabilities. This is deduced from the major and minor version numbers in the Probe packet and directly from the capability flags in the Probe packet. Probes provide a keep-alive function in order to quickly detect neighbor loss. A DVMRP router sends periodic Route Report messages to its DVMRP neighbors (by default, every 60 seconds). A Route Report message contains the senders current routing table, which contains entries that advertise a source network (with a mask) and a hop-count that is used as the routing metric. This routing information is used to build source distribution trees and to perform multicast forwarding. The DVMRP neighbor that advertises the route with the lowest metric will be used for forwarding. (In case of a tie, the DVMRP neighbor with the lowest IP address will be used.) In DVMRPv3, a router will not accept a Route Report from another DVMRP router until it has established adjacency with that neighboring router. Note. Older versions of DVMRP use Route Report messages to perform neighbor discovery rather than the Probe messages used in DVMRP Version 3.

Multicast Source Location, Route Report Messages, and Metrics

When an IP multicast packet is received by a router running DVMRP it first looks up the source network in the DVMRP routing table. The interface that provides the best route back to the source of the packet is called the upstream interface. If the packet arrived on that upstream interface, then it is a candidate for forwarding to one or more downstream interfaces. If the packet did not arrive on that anticipated upstream interface, then it is discarded. This check is known as a reverse path forwarding check and is performed by all DVMRP routers. Note. Under normal, stable DVMRP operation, packets would not arrive on the wrong interface because the upstream router would not forward the packet unless the downstream router poison-reversed the route in the first place (as explained below). However, there are casessuch as immediately after a network topology changewhen DVMRP routing has not yet converged across all routers where this can occur. It can also occur when loops exist in the network topology. In order to ensure that all DVMRP routers have a consistent view of the path back to a source, all DVMRP routers in Route Report messages propagate routing tables. Each router transmits a Route Report message at specified intervals. The Route Report message advertises the network numbers and masks of those interfaces to which the router is directly connected. It also relays the routes received from neighboring routers. DVMRP requires an interface metric (i.e., a hop count) to be configured on all physical and tunnel inter-faces. When a route is received from a neighboring router via a Route Report message, the metric of the interface over which the packet was received is added to the metric of the route being advertised. This adjusted metric is used when comparing metrics to determine the most efficient upstream interface.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 545 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Dependent Downstream Routers and Poison Reverse

In addition to providing a consistent view of source networks, the exchange of routes in DVMRP Route Report messages provides one other important feature. DVMRP uses the route exchange as a mechanism for upstream routers to determine if any downstream routers depend on them for forwarding packets from particular source networks. DVMRP accomplishes this by using a technique called poison reverse. If a downstream router selects an upstream router as the best next hop to a particular source network, it indicates this by echoing back the route on the upstream interface with a metric equal to the original metric plus infinity. (DVMRP uses a metric of 32 as infinity.) When the upstream router receives the report and sees a metric that lies between infinity and twice infinity (that is, between 32 and 64), it adds the downstream router from which it received the report to a list of dependent routers for this source network. The list of dependent routers per source network built by the poison reverse technique provides the foundation necessary to determine when it is appropriate to prune back the IP source-specific multicast trees. Note. Poison reverse is used differently in DVMRP than in most unicast distance vector routing protocols (such as RIP), which use poison reverse to advertise that a particular route is unreachable.

Pruning Multicast Traffic Delivery

Initially, all interfaces with downstream-dependent neighbors are included in the downstream interface list and multicast traffic is flooded down the truncated broadcast tree to all possible receivers. This allows the downstream routers to be aware of traffic destined for a particular Source, Group (S, G) pair. The down-stream routers then have the option to send prunes (and subsequent grafts) for this (S, G) pair as requirements change. A DVMRP router will remove an interface from its forwarding list that has no group members associated with an IP multicast packet. If a router removes all of its downstream interfaces, it notifies the upstream router that it no longer wants traffic destined for that particular (S, G) pair. This is accomplished by sending a DVMRP Prune message upstream to the router expected to forward packets from that particular source. A downstream router will inform an upstream router that it depends on the upstream router to receive packets from particular source networks by using the poison reverse technique during the exchange of Route Report messages. This method allows the upstream router to build a list of downstream routers on each interface that are dependent upon it for packets from a particular source. If the upstream router receives Prune messages from each one of the dependent downstream routers on an interface, then the upstream router can in turn remove this interface from its downstream interface list. If the upstream router is able to remove all of its downstream interfaces in this manner, it can then send a DVMRP Prune message to its upstream router. This continues until all unneeded branches are removed.

Grafting Branches Back onto the Multicast Delivery Tree

A pruned branch will be automatically reattached to the multicast delivery tree when the prune times out. However, the graft mechanism provides a quicker method to reattach a pruned branch than waiting for the prune to time out. Without the graft mechanism, the join latency for new hosts in the group might be unacceptably great, because the prunes in the upstream routers would have to time out before multicast traffic could again begin to flow to the pruned branches. Depending on the number of routers along the pruned branch and the timeout values in use, several minutes might elapse before the host could begin to receive multicast traffic. By using a graft mechanism, DVMRP reduces the join latency to a few milliseconds. The graft mechanism is made reliable through the use of Graft-Ack (Graft Acknowledgment) messages. The upstream router in response to a Graft message returns a Graft-Ack message. If the Graft-Ack message is not received, the downstream router will resend the Graft message. This prevents the loss of a Graft message due to congestion. The ip dvmrp graft-timeout command enables you to set the Graft message retransmission value. This value defines the duration of time that the router will wait before retransmitting a Graft message if it has not received a Graft-Ack message.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 546 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

DVMRP Tunnels
Because not all IP routers support native multicast routing, DVMRP includes direct support for tunneling IP multicast packets through routers. Tunnel interfaces are used when routers incapable of supporting multicast traffic exist between DVMRP neighbors. In tunnel interfaces, IP multicast packets are encapsulated in unicast IP packets and addressed directly to the routers that do not support native multicast routing. DVMRP protocol messages (such as Route Reports, Probes for neighbor discovery, etc.) and multicast traffic are sent between tunnel endpoints using unicast, rather than multicast, packets. Multicast data is encapsulated using a standard IP-IP encapsulation method. The unicast IP addresses of the tunnel endpoints are used as the source and destination IP addresses in the outer IP header. The inner IP header remains unchanged from the original multicast packet.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 547 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

PIM
Protocol-Independent Multicast (PIM) is an IP multicast routing protocol that uses routing information provided by unicast routing protocols such as RIP and OSPF. PIM is protocol-independent because it does not rely on any particular unicast routing protocol. Sparse mode PIM (PIM-SM) contrasts with flood and-prune dense mode multicast protocols, such as DVMRP and PIM Dense Mode (PIM-DM) in that multicast forwarding in PIM-SM is initiated only via specific requests, referred to as Join messages. PIMDM packets are transmitted on the same socket as PIM-SM packets, as both use the same protocol and message format. Unlike PIM-SM, in PIM-DM there are no periodic joins transmitted; only explicitly triggered prunes and grafts. Unlike PIM-SM, there is no Rendezvous Point (RP) in PIM-DM. Source-Specific Multicast (PIM-SSM). The current implementation of PIM includes support for Source- Specific Multicast (PIM-SSM).

PIM Specifications
RFCs Supported 2362Protocol Independent Multicast-Sparse Mode (PIM-SM) Protocol Specification 2934Protocol Independent Multicast MIB for Ipv4 2932Ipv4 Multicast Routing MIB 3973Protocol Independent Multicast-Dense Mode (PIM-DM) 3376Internet Group Management Protocol Draft-ietf-pim-sm-v2-new-05.txtProtocol Independent Multicast Sparse Mode PIM-SM Draft-ietf-pim-mib-v2-00.txtProtocol Independent Multicast MIB includes support for PIM-DM Draft-ietf-pim-sm-bsr-02.txtBootstrap Router (BSR) Mechanism for PIM Sparse Mode PIM-SMv2 Shared trees (also referred to as RP trees), Designated Routers (DRs), Bootstrap Routers (BSRs), Candidate Bootstrap Routers (C-BSRs), Rendezvous Points (RPs) (applicable only for PIM-SM), Candidate Rendezvous Points (C-RPs)) C-RP expiry, C-RP holdtime, C-RP advertisement, Join/Prune, Probe, Register suppression, Hello, Expiry, Assert, Neighbor liveness 100 (default value is 32) 1 1 (e.g., you cannot enable both PIM-SM and DVMRP on the same IP interface)

Internet Drafts Supported

PIM-SM Version Supported PIM Attributes Supported

PIM Timers Supported Maximum Rendezvous Point (RP) routers allowed in a PIM-SM domain Maximum Bootstrap Routers (BSRs) allowed in a PIM domain Multicast Protocols per Interface

PIM Defaults
Parameter Description PIM status PIM load status sparse mode PIM load status dense mode C-BSR mask length Static RP configuration RP threshold C-RP expiry time C-RP holdtime C-RP advertisement interval C-RP priority Source, group data timeout Global Join/Prune interval Maximum RP routers allowed Probe timer Register checksum value Register suppression timer Switchover to Shortest Path Tree (SPT) PIM interface status Interface graft retry interval Interface max graft retries Interface sr ttl threshold Interface Hello message interval Default Value/Comments Disabled Disabled Disabled 30 bits Disabled 65536 300 seconds 150 seconds 60 seconds 0 210 seconds 60 seconds 32 5 seconds Header 60 seconds Enabled Disabled on all interfaces 3 seconds 2 0 30 seconds

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 548 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Interface Join/Prune interval Interface C-BSR preference Interface DR priority Interface LAN prune-delay status Interface LAN prune-delay Interface override interval Interface triggered hello time Interface hello hold time Interface generation ID status Interface Join/Prune hold time Source lifetime Successive state refresh interval State refresh message limit State refresh ttl

60 seconds; this value automatically matches the configured global Join/Prune interval. 0 1 Disabled 500 milliseconds 2500 milliseconds 5 seconds 105 seconds Enabled 210 seconds 210 seconds 60 seconds 0 16

PIM Overview
Protocol-Independent Multicast (PIM) is an IP multicast routing protocol that uses routing information provided by unicast routing protocols such as RIP and OSPF. Note that PIM is not dependent on any particular unicast routing protocol. Sparse mode PIM (PIM-SM) contrasts with flood-and-prune dense mode multicast protocols such as DVMRP in that multicast forwarding in PIM-SM is initiated only via specific requests, referred to as join messages. Downstream routers must explicitly join PIM-SM distribution trees in order to receive multicast streams on behalf of receivers or other downstream PIM-SM routers. This paradigm of receiver-initiated forwarding makes PIM-SM ideal for network environments where receiver groups are thinly populated and bandwidth conservation is a concern, such as in wide area networks (WANs). PIM-DM differs from PIM-SM in two essential ways: There are no periodic joins transmitted, only explicitly triggered prunes and grafts. There is no Rendezvous Point (RP). This is particularly important in networks that cannot tolerate a single point of failure. Note. OmniSwitch 6850 switches support PIM-DM, PIM-SMv2 and are not compatible with PIMSMv1. These components include: Rendezvous Points (RPs) and Candidate Rendezvous Points (C-RPs) Bootstrap Routers (BSRs) and Candidate Bootstrap Routers (C-BSRs) Designated Routers (DRs) Shared Trees, also referred to as Rendezvous Point Trees (RPTs) Avoiding Register Encapsulation

Rendezvous Points (RPs)

In PIM-SM, shared distribution trees are rooted at a common forwarding router termed a Rendezvous Point (RP). The RP un-encapsulates Register messages and forwards multicast packets natively down-established distribution trees to receivers. The resulting topology is referred to as the RP Tree (RPT).

Candidate Rendezvous Points (C-RPs)

A Candidate Rendezvous Point (C-RP) is a PIM-enabled router that sends periodic C-RP advertisements to the Bootstrap Router (BSR). When a BSR receives a C-RP advertisement, it may include the C-RP in its RP-set.

Bootstrap Routers (BSRs)

The role of a Bootstrap Router (BSR) is to keep routers in the network up to date on reachable C-RPs. The BSRs list of reachable C-RPs is also referred to as an RP set. There is only one BSR per PIM domain. This allows all PIM routers in the PIM domain to view the same RP set. A C-RP periodically sends out messages, known as C-RP advertisements. When a BSR receives one of these advertisements, the associated C-RP is considered reachable (if it has a valid route). The BSR then periodically sends its RP set to neighboring routers in the form of a Bootstrap message. BSRs are elected from the Candidate Bootstrap Routers (C-BSRs) in the PIM domain.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 549 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Candidate Bootstrap Routers (C-BSRs)

A Candidate Bootstrap Router (C-BSR) is a PIM-enabled router that is eligible for BSR status. To become a BSR, a CBSR must become elected. A C-BSR sends Bootstrap messages to all neighboring routers. The messages include its IP addresswhich is used as an identifierand its priority level. The C-BSR with the highest priority level is elected as the BSR by its neighboring routers. If two or more C-BSRs have the same priority value, the C-BSR with the highest IP address is elected as the BSR.

Designated Routers (DRs)

There is only one Designated Router (DR) used per LAN. When a DR receives multicast data from the source, it encapsulates the data packets into the Register messages, which are in turn sent to the RP. Downstream PIM routers express interest in receiving multicast streams on behalf of a host via explicit Join/Prune messages originating from the DR and directed to the RP. An election process selects the DR for a LAN. This election process takes into account the DR priority of each PIM neighbor on the LAN. If multiple neighbors share the same DR priority, the neighbor with the highest IP address is elected. The ip pim interface dr-priority command is used to specify the DR priority on a specific PIM-enabled interface. Note that the DR priority is taken into account only if all of the PIM neighbors on the LAN are using the DR priority option in their Hello packets.

Shared (or RP) Trees

Shared distribution trees are also referred to as RP trees (or RPTs) because the routers in the distribution tree share a common Rendezvous Point (RP). The following diagrams illustrate a simple RP tree in a PIM-SM domain. In this example, a multicast receiver (Receiver 1) uses IGMP to express interest in receiving multicast traffic destined for a particular multicast group. After getting the IGMP Join request, the receivers Designated Router (DR) then passes on the request, in the form of a PIM Join message, to the RP. Note. The Join message is known as a (*, G) join because it joins group G for all sources to that group.

Note. Depending on the network configuration, multiple routers may exist between the receivers DR and the RP router. In this case, the (*, G) Join message travels hop-by-hop toward the RP. In each router along the way, the multicast tree state for group G is instantiated. These Join messages converge on the RP to form a distribution tree for group G that is rooted at the RP. Sender 1 sends multicast data to its Designated Router (DR). The source DR then unicast-encapsulates the data into PIM-SM Register messages and sends it on to the RP.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 550 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Once the distribution tree for group G is learned at the RP, the encapsulated data being sent from the source DR is now un-encapsulated at the RP and forwarded natively to the Receiver.

Avoiding Register Encapsulation

Switching to a Shortest Path Tree (SPT) topology allows PIM routers to avoid Register encapsulation of data packets that occurs in an RPT. Register encapsulation is inefficient for the following reasons: The encapsulation and un-encapsulation of Register messages taxes router resources. Hardware routing does not support encapsulation and un-encapsulation. Register encapsulation may require that data travel unnecessarily over long distances. For example, data may have to travel out of its way to the RP before turning back down the shared tree in order to reach a receiver. For some applications, this increased latency is undesirable. There are two methods for avoiding register encapsulation: RP initiation of (S, G) source-specific Join messages, and switchover to a Shortest Path Tree (SPT).

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 551 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

RP Initiation of (S, G) Source-Specific Join Message

When the data rate at the Rendezvous Point (RP) exceeds the configured RP threshold value, the RP will initiate a (S, G) source-specific Join message toward the source.

When the Senders DR receives the (S,G) Join, it sends data natively as well. When these data packets arrive natively at the RP, the RP will be receiving two copies of each of these packetsone natively and one encapsulated. The RP drops the register-encapsulated packets and forwards only the native packets.

A register-stop packet is sent back to the senders DR to prevent the DR from unnecessarily encapsulating the packets. Once the register-encapsulated packets are discontinued, the packets are flowing natively from the sender to the RP along the source-specific tree to the RP and, from there, along the shared tree to all receivers.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 552 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Because packets are still forwarded along the shared tree from the RP to all of the receivers, this does not constitute a true Shortest Path Tree (SPT). For many receivers, the route via the RP may involve a significant detour when compared with the shortest path from the source to the receivers.

SPT Switchover
It is the last hop Designated Router (DR) that initiates the switchover to a true Shortest Path Tree (SPT) once it receives the first multicast data packet. This method does not use any preconfigured thresholds, such as RP threshold (as described above). Instead, the switchover is initiated automatically, as long as the SPT status is enabled on the switch. Important. SPT status must be enabled for SPT switchover to occur. SPT status is enabled by default. If the SPT status is disabled, the SPT switchover will not occur. The SPT status is configured via the ip pimsm spt status command. To view the current SPT status, use the show ip pimsm command Upon receiving the first multicast data packet, the last hop DR issues a (S, G) source-specific Join message toward the source.

Once the Senders DR receives the (S,G) Join message, it sends the multicast packets natively along the Shortest Path Tree. At this point, Router X (the router shown between the Senders DR and the Receivers DR) will be receiving two copies of the multicast dataone from the SPT, and one from the RPT. This router drops the packets arriving via the RP tree and forwards only those packets arriving via the SPT.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 553 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

An (S, G, RPT) Prune message is sent toward the RP. As a result, traffic destined for this group from this particular source will no longer be forwarded along the RPT. The RP will still receive traffic from the Source. If there are no other routers wishing to receive data from the source, the RP will send an (S, G) Prune message toward the source to stop this unrequested traffic.

The Receiver is now receiving multicast traffic along the Shortest Path Tree between the Receiver and the Source.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 554 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

PIM-SSM Support
Protocol Independent Multicast Source-Specific Multicast (PIM-SSM) is a highly efficient extension of PIM. SSM, using an explicit channel subscription model, allows receivers to receive multicast traffic directly from the source; an RP tree model is not used. In other words, a Shortest Path Tree (SPT) between the receiver and the source is created without the use of a Rendezvous Point (RP). By default, PIM-SM software supports Source-Specific Multicast. No additional user configuration is required. PIM-SSM is automatically enabled and operational as long as PIM-SM is loaded and IGMPv3 source-specific joins are received within the SSM address range. For detailed information on PIM-SSM and Source-Specific Multicast, refer to the IETF Internet Drafts draft-ietf-pim-sm-v2-new-05.txt and draft-ietf-ssm-arch-04.txt, as well as RFC 3569, An Overview of Source-Specific Multicast (SSM). Note. For networks using IGMP proxy, be sure that the IGMP proxy version is set to Version 3. Otherwise, PIM-SSM will not function.

Source-Specific Multicast Addresses

The Internet Assigned Numbers Authority (IANA) has reserved multicast addresses 232.0.0.0 through 232.255.255.255 as Source-Specific Multicast (SSM) destination addresses. Addresses within this range are reserved for use by sourcespecific applications and protocols (e.g., PIM-SSM) and cannot be used for any other functions or protocols.

PIM-SSM Specification
RFCs Supported Internet Drafts Supported Valid SSM Address Range 3569An Overview of Source-Specific Multicast (SSM) Draft-ietf-pim-sm-v2-new-05.txtProtocol Independent Multicast Sparse Mode (PIM-SM) Draft-ietf-ssm-arch-04.txtAn Overview of Source-Specific Multicast (SSM) 232.0.0.0 to 232.255.255.255

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 555 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IP Multicast VLAN
Multicasting is a one-to-many transmission mode. It is similar to broadcasting, except that multicasting means sending to specific groups, whereas broadcasting implies sending to all. When sending voluminous data, multicast saves considerable bandwidth as the bulk of the data is transmitted only once from its source through major backbones and are distributed out at switching points closer to end users. IP Multicast VLAN (IPMV) is an innovative feature for service providers delivering residential voice and video services. It involves the creation of separate dedicated VLANs built specifically for multicast traffic distribution. These distribution VLANs connect to the nearest multicast router and support multicast traffic only. Note. IP Multicast VLAN is only supported in Release 6.2.1 for the OmniSwitch 6850 Series. Note. You can also configure and monitor IPMV through WebView, Alcatels embedded web-based device management application. WebView is an interactive and easy-to-use GUI that can be launched from OmniVista or a web browser. Please refer to WebViews online documentation for more information on configuring and monitoring IPMV through WebView.

IP Multicast VLAN Specifications

The following table lists IPMVLAN specifications.
IEEE Standards Supported Maximum Number of IP Multicast VLAN IDs VLAN Stacking Functionality Modes 802.1ad/D6.0 Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 4: Provider Bridges 256 (The valid range is 2 through 4094) VLAN Stacking mode Enterprise mode

IP Multicast VLAN Defaults

The following table lists IPMVLAN default values.
Parameter Description Administrative Status Default Value/Comments Enabled

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 556 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IP Multicast VLAN Overview

The IP Multicast VLAN (IPMV) feature helps service providers to create separate dedicated VLANs to distribute multicast traffic. Service providers have to separate users using these VLANs. This should be done along with the distribution of broadcast media through IP Multicast across these VLANs without a router in the distribution L2 switch. To achieve this, the distribution L2 switch needs to perform IGMP snooping (i.e., allow the switch to "listen in" on the IGMP conversation between hosts and routers) as well as distribute multicast traffic from one multicast distribution VLAN to many customer ports. A distribution multicast VLAN that switches into customer ports is invisible to the customer to avoid packet duplication across the trunk. Furthermore, some service providers use QinQ on the provider ports to tag the multicast distribution VLAN with a distinct outer VLAN tag. The customer ports can either be tagged or untagged. However, the multicast traffic always needs to be tagged. This process requires one or more separate multicast distribution VLANs. These distribution VLANs connect to the nearest multicast router and are used for multicast traffic only. The multicast traffic will only flow from the distribution VLAN to the customer VLAN. Customer-generated multicast traffic will flow only through the customer VLANs so that the multicast router can control the distribution of such traffic. The IPMV feature works in both the Enterprise and the VLAN Stacking environment. The ports are classified as VLAN Stacking ports and Legacy ports (fixed ports/tagged ports). To ascertain that data flow is limited to either the VLAN Stacking domain or the Enterprise domain, VLAN Stacking ports must be members of VLAN Stacking VLANs only, while the normal Legacy ports must be members of VLANs configured in the Enterprise mode only. It is not possible to change an IPMVLAN from one mode to another. An IPMVLAN configured in a specific mode must first be deleted, then re-created in the other mode.

VLAN Stacking Mode

IP Multicast VLANs in the VLAN Stacking mode contain VLAN Stacking ports as their member ports. In an IPMVLAN, the VLAN Stacking network port corresponds to the sender port, which also receives multicast data for the configured multicast group. Only one sender port can be assigned to an IPMVLAN. The VLAN Stacking user-customer-port/user-provider-port corresponds to the receiver port of the IPMVLAN. An IPMVLAN can include multiple receiver ports as its members.

IPM VLAN Lookup Mode

In the VLAN Stacking double-tagged mode, single-tagged IGMP reports are double-tagged and sent to the CPU of the Ethernet switch. The IP Multicast Switching (IPMS) module can use any one of the following methods to bind IPMVLANs to a single receiver port: IP address, or CVLAN-tag, received as part of the IGMP report Note. It is recommended to use any one of the methods on the receiver port and not both. Note. CVLAN-tag translation rule applies only in the VLAN Stacking mode. You can use the vlan ipmvlan ctag command to define the translation rule for replacing the outer s-tag with an IPMVLAN ID, the inner being the customer tag (c-tag). Note. No checks will be performed on c-tags as they are simple translation rules. VLAN addition or deletion rules do not affect them.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 557 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The following limitations should be noted in the c-tag translation mode: The translation rule applies only to double-tagged frames. IP address translation rule applies to untagged IGMP reports received from customer. The translation rule applies only to the VLAN Stacking IPMVLANs.

Enterprise Mode
IP Multicast VLANs in the Enterprise mode contain normal user ports (fixed/tagged) as their member ports.

IPM V Packet Flows

This section describes the tagged and untagged packet flows in both the Enterprise and VLAN Stacking modes. In addition, it also describes the packet flow from the ingress point to the egress point.

VLAN Stacking Mode

The following illustration shows customers A, B, and C formed as a multicast group G1.Three types of control packets ingress on the receiver port.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 558 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

The paths taken by the packets are described in the following subsections: Untagged Control Packets Ingressing on the Receiver Port The following steps describe the path taken by untagged control packets ingressing on the receiver port: 1: Untagged IPMS join reports for the multicast group G1 are sent to the receiver port. 2: The IPMS reports sent to the CPU of the Ethernet switch are single-tagged with the default SVLAN tag (s-tag). 3: IPMS overwrites the SVLAN tag with the IPMV tag after IPMV table lookup. 4: A single IPMS report, single-tagged with IPMV, is sent to the multicast server for group G1. 5: The single multicast data packet, single-tagged with IPMV, is generated by the multicast server for group G1. 6: The generated multicast data packets are flooded on the receiver port. These data packets are untagged. C-Tag Translation Rule in the VLAN Stacking Mode The following steps describe how the c-tag translation rule works in the VLAN Stacking mode: 1: The IPMS join reports for multicast group G1, which are single-tagged with the CVLAN tag (c-tag) are sent to the receiver port. 2: SVLAN tags are attached before the CVLAN tags in all the IPMS reports going to the CPU of the Ethernet switch. 3: IPMS overwrites the SVLAN tags with the IPMV tags after IPMV table lookup for the inner c-tag. 4: A single IPMS double-tagged report with an IPMV outer tag and a CVLAN inner tag is sent to the multicast server for group G1. 5: The single multicast double-tagged data packets with an IPMV outer tag and a CVLAN inner tag are generated by the multicast server for group G1. 6: The VLAN Stacking egress logic removes the IPMV outer tag. The generated multicast data packets flooded on the receiver port are single-tagged with CVLAN. Single-Tagged Control Packets (with CVLAN) Ingressing on the Receiver Port in the VLAN Stacking Double-Tag Mode The following steps describe the path taken by single-tagged control packets ingressing on the receiver port in the VLAN Stacking double-tag mode: 1: The IPMS join reports for multicast group G1, single-tagged with the CVLAN tag (c-tag), are sent to the receiver. 2: SVLAN tags are attached after the CVLAN tags in all the IPMS reports going to the CPU of the Ethernet switch. 3: IPMS overwrites the SVLAN tags with the IPMV tags after IPMV table lookup for the inner c-tag. 4: A single IPMS double-tagged report with an IPMV outer tag and a CVLAN inner tag is sent to the multicast server for group G1.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 559 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

5: The single multicast double-tagged data packets with an IPMV outer tag and a CVLAN inner tag are generated by the multicast server for group G1. 6: The VLAN Stacking egress logic removes the IPMV outer tag. The generated multicast data packets flooded on the receiver port are single-tagged with CVLAN. Note. All the IPMS control traffic specified for a single multicast service should be tagged with the same CVLAN. Single-Tagged Control Packets (with CVLAN) Ingressing on the Receiver Port in the VLAN Stacking Translation Mode The following steps describe the path taken by single-tagged control packets ingressing on the receiver port in the VLAN Stacking translation mode: 1: The IPMS join reports for multicast group G1, which are single-tagged with the CVLAN tag (c-tag) are sent to the receiver port. 2: CVLAN tags are replaced by the SVLAN tags in all the IPMS reports going to the CPU of the Ethernet switch. 3: IPMS overwrites the SVLAN tags with the IPMV tags after IPMV table lookup. 4: A single IPMV-tagged IPMS report is sent to the multicast server for Group G1. 5: The single multicast packets single-tagged with IPMV are generated by the multicast server for group G1. 6: The VLAN Stacking egress logic replaces the IPMV tag with the CVLAN tag. The multicast data packets flooded on the receiver port are single-tagged with CVLAN. Note. All the IPMS control traffic specified for a single multicast service should be tagged with the same CVLAN.

Enterprise Mode
In the Enterprise mode, two types of control packets ingress on the receiver ports. The paths taken by the packets (as shown in the diagram on page 33-5) are described in the following subsections. Untagged Control Packets Ingressing on the Receiver Port The following steps describe the path taken by untagged control packets ingressing on the receiver port: 1: Untagged IPMS join reports for the multicast group G1 are sent to the receiver port. 2: The IPMS reports sent to the CPU of the Ethernet switch are single-tagged with the default VLAN. 3: IPMS overwrites the tag with the IPMV tag after IPMV table lookup. 4: A single IPMS report, single-tagged with IPMV, is sent to the multicast server for group G1. 5: The single multicast data packet, single-tagged with IPMV, is generated by the multicast server for group G1. 6: The generated multicast data packets are flooded on the receiver port. These data packets are untagged.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 560 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Tagged Control Packets Ingressing on the Receiver Port The following steps describe the path taken by tagged control packets ingressing on the receiver port: 1: The single-tagged IPMS join reports for the multicast group G1 are sent to the receiver port. 2: The IPMS reports are sent to the CPU of the Ethernet switch. 3: IPMS overwrites the tag with the IPMV tag after IPMV table lookup. 4: A single IPMS report, single-tagged with IPMV, is sent to the multicast server for group G1. 5: The single multicast data packet, single-tagged with IPMV, is generated by the multicast server for group G1. 6: The generated multicast data packets are flooded on the receiver port. These data packets are untagged.

IPM VLAN Application Example

The figure below shows a sample IPMVLAN network with three customers A, B, and C, respectively.The customers are connected to the Ethernet switch requesting multicast data.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 561 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Simplified Manageability
Recognizing a great demand in the marketplace and customers expectation for a level of synergism in the network management, Alcatel-Lucent has developed comprehensive and unified NMS solutions for its full array of networking products. Alcatel-Lucents OmniVista is the voice and data network management platform that features OneTouch Manageability, which allows network managers to quickly configure and manage the switches in the network. OneTouch QoS is a feature of the Alcatel-Lucent policy management software that allows network managers to quickly assign QoS priorities to network traffic based on the characteristics of different applications. OneTouch SecureView is a feature of the AlcatelLucent policy management software that allows network managers to quickly assign security policies to network traffic based on the characteristics of different applications. The AOS OmniSwitch product family offers service-level and policy based-configurations with support for LDAP directory services to enable flexible integration with existing platforms. AOS OmniSwitch product family further supports ease-of-use configuration choices for network administrators proactive network management using SNMPv3, four-groups of RMON-I (statistics, history, alarms, and events), and port mirroring to aid in troubleshooting the network. In addition, switch configuration and management can occur through the following mechanisms: SNMP, Telnet, FTP, Java-based GUI/WebView (standard Web-based Element Manager supporting HTTP/S-HTTP) with OmniVista management, a Command Line Interface (CLI), and fully editable ASCIIText-Based Configuration File. All switch management is completely tied to SNMPv3 since the switch uses public and private MIBs for management. An Overview of the Alcatel-Lucent AOS ease-of-Management features: Carrier-Class Dynamic Mobility This concept which allows user mobility with Voice-over-IP and data roaming across the global enterprise has evolved as an important product-differentiating feature. Users are becoming increasingly mobile, and this can create challenges for network administrators. The AOS OmniSwitch product family features Dynamic Mobility, which simplifies the task of managing remote and mobile users. This allows users to move anywhere in the network without reconfiguration hassle. Users can change locations, connect to a new network switch port, and have access to all their resources without the network administrator intervention. Dynamic mobility can be fully integrated with authentication and policy-based VLANs to provide secure mobility across an entire enterprise network. OmniVista NMS: Alcatel-Lucents Single voice, data and services network management including OneTouch QoS and SecureView. This NMS application encompasses the entire Alcatel-Lucent product family and switching and routing products including the standard-based Wireless LAN solution. o Integration with SNMP manager OmniVista for network wide management WebView Element Manager: Alcatel-Lucents AOS OmniSwitch product family Web-Based Element Manager o Easy to use, point-and-click web based element manager (WebView) with built-in help for easy configuration of new technology features IGMPv1/v2/v3 snooping to optimize multicast traffic BootP/DHCP client allows auto-config of switch IP information to simplify deployment o DHCP relay to forward client requests to a DHCP server Alcatel-Lucent Mapping Adjacency Protocol (AMAP) o Alcatel Mapping Adjacency Protocol (AMAP) for building topology maps within OmniVista Policy-Based Management with LDAP Directory Services, Authentication Servers such as RADIUS, LDAP, and ACE servers Monitoring Tools: Port Mirroring, Port Monitoring, Switch Health, sFlow, and RMON-I o Supports RFC 2819 RMON group (1-Statistics, 2-History, 3-Alarm & 9-Events) o SFlow v5 support to monitor and effectively control and manage the network usage o Port based, port mirroring for troubleshooting and lawful interception, supports four sessions with multiple sources-to-one destination configuration o Port monitoring feature that allows capture of Ethernet packets to a file, or for on-screen display to assist in troubleshooting Through the application of a comprehensive QoS feature set, the AOS OmniSwitch product family is capable of supporting converged applications such as the VoIP Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 562 Software & Hardware Release: AOSv6.3.1r01

Switch Logging, Memory Monitoring, and Switch Configuration Local (on the flash) and remote logging (Syslog) Logging into the Switch through Telnet, FTP, HTTP, SSH, SSL, and SNMPv1&v2&v3 o Remote telnet management or secure shell access using SSH o Secured file upload using SFTP, or SCP o SNMPv1/v2/v3 System File Management o Dual image and dual configuration file storage provides backup Intuitive Alcatel CLI with familiar interface reducing training costs Human readable ASCII based config files for offline editing and bulk configuration Managing Switch Users Accounts & Partitioned Management feature Managing Switch Security Auto-negotiating 10/100/1000 ports automatically configure port speed and duplex setting Auto MDI/MDIX automatically configures transmit and receive signals to support straight through and crossover cabling Network Time Protocol (NTP) for network wide time synchronization GVRP for 802.1Q-compliant VLAN pruning and dynamic VLAN creation

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 563 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Interswitch Protocols
Alcatel-Lucent Interswitch Protocols (AIP) is used to discover adjacent switches and retain mobile port information across switches. The following protocols are supported: Alcatel-Lucent Mapping Adjacency Protocol (AMAP), which is used to discover the topology of OmniSwitches.

AIP Specifications
Standards Maximum number of IP addresses propagated by AMAP Not applicable at this time. AMAP is an Alcatel-Lucent proprietary protocol. 255

AMAP Defaults
Parameter Description AMAP Status Discovery Time Interval Common Time Interval Default Enabled 30 seconds 300 seconds

AMAP Overview
The Alcatel-Lucent Mapping Adjacency Protocol (AMAP) is used to discover the topology of OmniSwitches or Omni S/R(s) in a particular installation. Using this protocol, each switch determines which OmniSwitches or Omni S/R(s) is adjacent to it by sending and responding to Hello update packets. For the purposes of AMAP, adjacent switches are those that: Have a Spanning Tree path between them Do not have any switch between them on the Spanning Tree path that has AMAP enabled AMAP switch ports are either in the discovery transmission state, common transmission state, or passive reception state. Ports transition to these states depending on whether or not they receive Hello responses from adjacent switches. Note. All Hello packet transmissions are sent to a well-known MAC address (0020da:007004).

Discovery Transmission State

When AMAP is active, at startup all active switch ports are in the discovery transmission state. In this state, ports send out Hello packets and wait for Hello responses. Ports send out Hello packets at a configurable interval called the discovery timeout interval. This interval is 30 seconds by default. The ports send out Hello packets up to three timeouts of this interval trying to discover adjacent switches. Any switch ports that receive Hello packets send a Hello response and transition to the common transmission state. Any switch ports that do not receive a Hello response before three discovery timeout intervals have expired are placed in the passive reception state.

Common Transmission State

In the common transmission state, ports detect adjacent switch failures or disconnects by sending Hello packets and waiting for Hello responses. Ports send out Hello packets at a configurable interval called the common timeout interval. This interval is 300 seconds by default. To avoid synchronization with adjacent switches, the common timeout interval is jittered randomly by plus or minus ten percent. Ports wait for a Hello response using the discovery timeout interval. If a Hello response is detected within one discovery timeout interval, the port remains in the common transmission state. If a Hello response is not detected within one discovery timeout interval, the port reverts to the discovery transmission state.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 564 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Passive Reception State

In the passive reception state, switch ports are in receive-only mode. Hello packets are not sent out from ports in this state and there is no timer on waiting for Hello responses. If the port receives a Hello packet at any time, it enters the common transmission state and transmits a Hello packet in reply. If a port transitions to the passive reception state, any remote switch entries for that port are deleted.

Common Transmission and Remote Switches

If an AMAP switch is connected to multiple AMAP switches via a hub, the switch sends and receives Hello traffic to and from the remote switches through the same port. If one of the remote switches stops sending Hello packets and other remote switches continue to send Hello packets, the ports in the common transmission state will remain in the common transmission state. The inactive switch will eventually be aged out of the switchs AMAP database because each remote switch entry has a last seen field that is updated when Hello packets are received. The switch checks the last seen field at least once every common timeout interval. Switch ports that are no longer seen may still retain an entry for up to three common timeout intervals. The slow aging out prevents the port from sending Hello packets right away to the inactive switch and creating additional unnecessary traffic.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 565 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

IEEE 802.1AB
Link Layer Discovery Protocol (LLDP) is an emerging standard to provide a solution for the configuration issues caused by expanding networks. LLDP supports the network management software used for complete network management. LLDP is implemented as per the IEEE 802.1AB standard. LLDP specifically defines a standard method for Ethernet network devices to exchange information with its neighboring devices and maintain a database of the information. The exchanged information, passed as LLDPDU, is in TLV (Type, Length, and Value) format. The information available to the network management software must be as new as possible; hence, remote device information is periodically updated.

IEEE 802.1AB (LLDAP) Specifications

IEEE Specification Transmit time interval for LLDPDUs Transmit hold multiplier value Transmit delay Reinit delay Notification interval IEEE 802.1AB-2005 Station and Media Access Control Connectivity Discovery 5 to 32768 in seconds 2 to 10 1 to 8192 in seconds 1 to 10 in seconds 5 to 3600 in seconds

IEEE 802.1AB (LLDP) Defaults

The following table shows the default settings of the configurable 802.1AB parameters. Parameter Description Transmit time interval for LLDPDUs Transmit hold multiplier value Transmit delay Reinit delay Notification interval LLDPDUs transmission Per port notification Management TLV 802.1 TLV 802.3 TLV LLDP Media Endpoint Device Default 30 seconds 4 2 seconds 2 seconds 5 seconds Transmission and Reception Disable Disable Disable Disable Disable

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 566 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

802.1AB Overview
LLDP is a Layer 2 protocol for detecting adjacent devices in a network. Each device in a network sends and receives LLDPDUs through all its ports, when the protocol is enabled. If the protocol is disabled on a port or on a device, then LLDPDUs received on that port or device are dropped. The LLDPDUs are transmitted at a certain interval that can be configured. When an LLDPDU is received from a neighboring device, the LLDPDU software validates the frame and stores the information in its remote device Management Information Base (MIB). This information is aged periodically, if an LLDPDU is not received from the same device within the time mentioned in the TTL TLV of the LLDPDU. By exchanging information with all the neighbors, each device will know its neighbor on each port. The information within the LLDPDU is transmitted in TLV (Type, Length, Value) format and falls under two categories: Mandatory Optional Each LLDPDU contains all the four mandatory TLVs and optional TLVs. Mandatory TLVs The mandatory TLV's information contains the LAN device's MAC service access point (MSAP) identifier and the time period for the validity of the LAN device's associated information. The mandatory TLVs contained in a LLDPDU are listed below: Chassis ID TLV Port ID TLV Time to live TLV End of LLDPDU TLV Optional TLVs The optional TLVs defined as part of LLDP are grouped into the following sets listed below: Basic management TLV set Port Description TLV System Name TLV System Description TLV System capabilities TLV Management address TLV Note. This optional TLV set is required for all LLDP implementation. IEEE 802.1 organizationally specific TLV set Port VLAN ID TLV Port and Protocol VLAN ID TLV VLAN name TLV Protocol identity TLV Note. If one TLV from this set is included in the LLDPDU, then all TLVs need to be included. IEEE 802.3 organizationally specific TLV set MAC/PHY configuration/status TLV Power Via MDI TLV (In network connectivity TLV set, Extended Power-Via-MDI TLV is supported.) Link Aggregation TLV Maximum frame size TLV ANSI-TIA LLDP-MED TLV sets Network connectivity TLV set LLDP-MED capabilities TLV Network Policy TLV Location Identification TLV Extended Power-via-MDI TLV When an 802.1AB supporting system receives an LLDPDU containing MED capability TLV, then the remote device is identified as an edge device (IP phone, IP PBX, etc.). In such a case the Alcatel device will stop sending LLDPDU and start sending MED LLDPDU on the port connected to the edge device. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 567 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

LLDP Agent Operation A network device that implements LLDP supports an LLDP agent. An LLDP agent operates in any one of the following three modes: Transmit-only mode: The agent can only transmit the information about the capabilities and the current status of the local system at regular intervals. Receive-only mode: The agent can only receive information about the capabilities and the current status of the remote systems. Transmit and receive mode: The agent can transmit the capabilities and status information of the local system and receive the capabilities and the status information of the remote system. LLDPDU Transmission and Reception LLDP operates in a one-way direction, so that the information in the LLDPDUs flows from one device to another. LLDPDUs are not exchanged as an information request by one device and a response sent by another device. The other devices do not acknowledge LLDP information received from a device. The transmission of LLDPDU is based on two factors: Transmit countdown timing counter. For example, whenever the counter expires, it will go through the entire database of ports that have links and send the LLDPDU if the current time has surpassed the retransmission time interval. If there is change in status of any of the ports. For example, a new port is attached or a new link has come up. Reception of LLDPDU is a two phase process: LLDPDU and TLV error handling as per the 802.1AB standard. LLDP remote system MIB update. Aging Time The remote system's LLDP specific information is stored in the LLDP MIB. The TTL TLV carries a positive value in seconds, and tells the other device as how long this information is valid. Once a remote device is learned on a local port, if the receiving device doesn't receive an LLDPDU from the same remote device and on the same local port within the TTL mentioned in the previous LLDPDU, then the local device discards that entry from its database. This is called the aging time and can be set by the user.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 568 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Managing Authentication Servers

This section describes authentication servers and how they are used with the switch. The types of servers described include Remote Authentication Dial-In User Service (RADIUS), Lightweight Directory Access Protocol (LDAP), and SecurIDs ACE/Server.

Authentication Server Specifications

RADIUS RFCs Supported RFC 2865Remote Authentication Dial In User Service (RADIUS) RFC 2866RADIUS Accounting RFC 2867RADIUS Accounting Modifications for Tunnel Protocol Support RFC 2868RADIUS Attributes for Tunnel Protocol Support RFC 2809Implementation of L2TP Compulsory Tunneling via RADIUS RFC 2869RADIUS Extensions RFC 2548Microsoft Vendor-specific RADIUS Attributes RFC 2882Network Access Servers Requirements: Extended RADIUS Practices RFC 1789Connectionless Lightweight X.5000 Directory Access Protocol RFC 2247Using Domains in LDAP/X.500 Distinguished Names RFC 2251Lightweight Directory Access Protocol (v3) RFC 2252Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions RFC 2253Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names RFC 2254The String Representation of LDAP Search Filters RFC 2256A Summary of the X.500 (96) User Schema for Use with LDAPv3 RFC 2574User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) RFC 2924Accounting Attributes and Record Formats RFC 2975Introduction to Accounting Management RFC 2989Criteria for Evaluating AAA Protocols for Network Access 4 (not including any backup servers) 4 per VLAN (not including any backup servers) 4 (not including any backup servers) The aaa radius-server and aaa ldap-server commands support prefix recognition.

LDAP RFCs Supported

Other RFCs

Maximum number of authentication servers in single authority mode Maximum number of authentication servers in multiple authority mode Maximum number of servers per Authenticated Switch Access type CLI Command Prefix Recognition

Server Defaults
RADIUS Authentication Servers
Defaults for the aaa radius-server command are as follows:
Description Number of retries on the server before the switch tries a backup server Timeout for server replies to authentication requests UDP destination port for authentication UDP destination port for accounting Default 3 2 1645* 1646*

* The port defaults are based on the older RADIUS standards; some servers are set up with port numbers based on the newer standards (ports 1812 and 1813 respectively).

LDAP Authentication Servers

Defaults for the aaa ldap-server command are as follows:
Description The port number for the server Number of retries on the server before the switch tries a backup server Timeout for server replies to authentication requests Whether a Secure Socket Layer is configured for the server Default 389 (SSL disabled) & 636 (SSL enabled) 3 2 No SSL

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 569 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Server Overview
Authentication servers are sometimes referred to as AAA servers (authentication, authorization, and accounting). These servers are used for storing information about users who want to manage the switch (Authenticated Switch Access) and users who need access to a particular VLAN or VLANs (Authenticated VLANs). RADIUS or LDAP servers may be used for Authenticated Switch Access and/or Authenticated VLANs. Another type of server, SecurIDs ACE/Server, may be used for authenticated switch access only; the ACE/Server is an authentication-only server (no authorization or accounting). Only RADIUS servers are supported for 802.1X Port-Based Network Access Control. The following table describes how each type of server may be used with the switch:
Server Type ACE/Server RADIUS LDAP Authenticated Switch Access Yes (except SNMP) Yes (except SNMP) Yes (including SNMP) Authenticated VLANs No Yes Yes 802.1X Port-Based Network Access Control No Yes No

Backup Authentication Servers

Each RADIUS and LDAP server may have one backup host (of the same type) configured through the aaa radius-server and aaa ldap-server commands respectively. In addition, each authentication method (Authenticated Switch Access, Authenticated VLANs, or 802.1X) may specify a list of backup authentication servers that includes servers of different types (if supported on the feature). The switch uses the first available authentication server to attempt to authenticate users. If user information is not found on the first available server, the authentication attempts fails.

Authenticated Switch Access

When RADIUS and/or LDAP servers are set up for Authenticated Switch Access, the switch polls the server for user login information. The switch also polls the server for privilege information (authorization) if it has been configured on the server; otherwise, the local user database is polled for the privileges. For RADIUS and LDAP, additional servers may be configured as backups. A RADIUS server supporting the challenge and response mechanism as defined in RADIUS RFC 2865 may access an ACE/Server for authentication purposes. The ACE/Server is then used for user authentication, and the RADIUS server is used for user authorization.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 570 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Authenticated VLANs
For authenticated VLANs, authentication servers contain a database of user names and passwords, challenges/ responses, and other authentication criteria such as time-of-day access. The Authenticated VLAN attribute is required on servers set up in multiple authority modes. Servers may be configured using one of two different modes, single authority mode or multiple authority modes. The mode specifies how the servers are set up for authentication: single authority mode uses a single list (an authentication server and any backups) to poll with authentication requests. Multiple authority modes use multiple lists, one list for each authenticated VLAN.

Port-Based Network Access Control (802.1X)

For devices authenticating on an 802.1X port on the switch, only RADIUS authentication servers are supported. The RADIUS server contains a database of user names and passwords, and may also contain challenges/responses and other authentication criteria.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 571 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

ACE/Server
An external ACE/Server may be used for authenticated switch access. It cannot be used for Layer 2 authentication or for policy management. Attributes are not supported on ACE/Servers. These values must be configured on the switch through the user commands. Since an ACE/Server does not store or send user privilege information to the switch, the switch determines user privileges for Secur/ID logins. When a user attempts to log into the switch, the user ID and password is sent to the ACE/Server. The server determines whether the login is valid. If the login is valid, the user privileges must be determined. The switch checks its user database for the users privileges. If the user is not in the database, the switch uses the default privilege, which is determined by the default user account. There are no server-specific parameters that must be configured for the switch to communicate with an attached ACE/Server; however, you must FTP the sdconf.rec file from the server to the switchs/network directory. This file is required so that the switch will know the IP address of the ACE/Server. The ACE client in the switch is version 4.1; it does not support the replicating and locking feature of ACE 5.0, but it may be used with an ACE 5.0 server if a legacy configuration file is loaded on the server. The legacy configuration must specify authentication to two specific servers (master and slave). To display information about any servers configured for authentication, use the show aaa server command. Also, you may need to clear the ACE/Server secret occasionally because of misconfiguration or required changes in configuration. The ACE/Server generates secrets that it sends to clients for authentication. While you cannot configure the secret on the switch, you can clear it. The secret may need to be cleared because the server and the switch get out of synch.

RADIUS Servers
RADIUS is a standard authentication and accounting protocol defined in RFC 2865 and RFC 2866. A built-in RADIUS client is available in the switch. A RADIUS server that supports Vendor Specific Attributes (VSAs) is required. The Alcatel-Lucent attributes may include VLAN information, time-of-day, or slot/port restrictions.

RADIUS Server Attributes

RADIUS servers and RADIUS accounting servers are configured with particular attributes defined in RFC 2138 and RFC 2139, respectively. These attributes carry specific authentication, authorization, and configuration details about RADIUS requests to and replies from the server. For a complete list of attributes (standard, and vendor-specific) and how to configure them on the server, please refer to the Users Manual.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 572 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

LDAP Servers
Lightweight Directory Access Protocol (LDAP) is a standard directory server protocol. The LDAP client in the switch is based on several RFCs: 1798, 2247, 2251, 2252, 2253, 2254, 2255, and 2256. The protocol was developed as a way to use directory services over TCP/IP and to simplify the directory access protocol (DAP) defined as part of the Open Systems Interconnection (OSI) effort. Originally it was a front-end for X.500 DAP. The protocol synchronizes and governs the communications between the LDAP client and the LDAP server. The protocol also dictates how its databases of information, which are normally stored in hierarchical form, are searched, from the root directory down to distinct entries. In addition, LDAP has its own format that permits LDAP-enabled Web browsers to perform directory searches over TCP/IP.

LDAP Server Details

LDAP servers must be configured with the properly defined LDAP schema and correct database suffix, including well- populated data. LDAP schema is extensible, permitting entry of user-defined schema as needed. LDAP servers are also able to import and export directory databases using LDIF (LDAP Data Interchange Format).

LDIF File Structure

LDIF is used to transfer data to LDAP servers in order to build directories or modify LDAP databases. LDIF files specify multiple directory entries or changes to multiple entries, but not both. The file is in simple text format and can be created or modified in any text editor. In addition, LDIF files import and export binary data encoded according to the base 64 conventions used with MIME (Multipurpose Internet Mail Extensions) to send various media file types, such as JPEG graphics, through electronic mail.

Directory Entries
Directory entries are used to store data in directory servers. LDAPenabled directory entries contain information about an object (person, place, or thing) in the form of a Distinguished Name (DN) that should be created in compliance with the LDAP protocol naming conventions. Distinguished names are constructed from Relative Distinguished Names (RDNs), related entries that share no more than one attribute value with a DN. RDNs are the components of DNs, and DNs are string representations of entry names in directory servers. Distinguished names typically consist of descriptive information about the entries they name, and frequently include the full names of individuals in a network, their email addresses, TCP/IP addresses, with related attributes such as a department name, used to further distinguish the DN. Entries include one or more object classes, and often a number of attributes that are defined by values. Object classes define all required and optional attributes (a set of object classes is referred to as a schema). As a minimum, every entry must include the DN and one defined object class, like the name of an organization. Attributes required by a particular object class must also be defined. Some commonly used attributes that comprise a DN include the following: Country (c), State or Province (st), Locality (l), Organization (o), Organization Unit (ou), and Common Name (cn) Although each attribute would necessarily have its own values, the attribute syntax determines what kind of values are allowed for a particular attribute, e.g., (c=US), where country is the attribute and US is the value. Extra consideration for attribute language codes will be necessary if entries are made in more than one language. Entries are usually based on physical locations and established policies in a Directory Information Tree (DIT); the DN locates an entry in the hierarchy of the tree. Alias entries pointing to other entries can also be used to circumvent the hierarchy during searches for entries. Once a directory is set up, DN attributes should thereafter be specified in the same order to keep the directory paths consistent. Commas as shown in this example separate DN attributes: cn=your name, ou=your function, o= your company, c=US As there are other conventions used, please refer to the appropriate RFC specification for further details.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 573 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

In addition to managing attributes in directory entries, LDAP makes the descriptive information stored in the entries accessible to other applications. The general structure of entries in a directory tree is shown in the following illustration. It also includes example entries at various branches in the tree.

Directory Searches
DNs are always the starting point for searches unless indicated otherwise in the directory schema. Searches involve the use of various criteria including scopes and filters, which must be predefined, and utility routines, such as Sort. Searches should be limited in scope to specific durations and areas of the directory. Some other parameters used to control LDAP searches include the size of the search and whether to include attributes associated with name searches. Base objects and scopes are specified in the searches, and indicate where to search in the directory. Filters are used to specify entries to select in a given scope. The filters are used to test the existence of object class attributes, and enable LDAP to emulate a read of entry listings during the searches. All search preferences are implemented by means of a filter in the search. Filtered searches are based on some component of the DN.

Retrieving Directory Search Results

Results of directory searches are individually delivered to the LDAP client. LDAP referrals to other servers are not returned to the LDAP client, only results or errors. If referrals are issued, the server is responsible for them, although the LDAP client will retrieve results of asynchronous operations.

Directory Modifications
Modifications to directory entries contain changes to DN entry attribute values, and are submitted to the server by an LDAP client application. The LDAP-enabled directory server uses the DNs to find the entries to either add or modify their attribute values. Attributes are automatically created for requests to add values if the attributes are not already contained in the entries. All attributes are automatically deleted when requests to delete the last value of an attribute are submitted. Attributes can also be deleted by specifying delete value operations without attaching any values. Modified attribute values are replaced with other given values by submitting replace requests to the server, which then translates and performs the requests.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 574 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Directory Compare and Sort

LDAP will compare directory entries with given attribute values to find the information it needs. The Compare function in LDAP uses a DN as the identity of an entry, and searches the directory with the type and value of an attribute. Compare is similar to the Search function, but simpler. LDAP will also sort entries by their types and attributes. For the Sort function, there are essentially two methods of sorting through directory entries. One is to sort by entries where the DN (Distinguished Name) is the sort key. The other is to sort by attributes with multiple values.

The LDAP URL

LDAP URLs are used to send search requests to directory servers over TCP/IP on the Internet, using the protocol prefix: ldap://. (Searches over SSL would use the same prefix with an s at the end, i.e., ldaps://.) LDAP URLs are entered in the command line of any web browser, just as HTTP or FTP URLs are entered. When LDAP searches are initiated LDAP checks the validity of the LDAP URLs, parsing the various components contained within the URLs to process the searches. LDAP URLs can specify and implement complex or simple searches of a directory depending on what is submitted in the URLs. Searches performed directly with LDAP URLs are affected by the LDAP session parameters described above. In the case of multiple directory servers, LDAP URLS are also used for referrals to other directory servers when a particular directory server does not contain any portion of requested IP address information. Search requests generated through LDAP URLs are not authenticated. Searches are based on entries for attribute data pairs. The syntax for TCP/IP LDAP URLs is as follows: Ldap://<hostname>: <port>/<base_dn>? Attributes>? <Scope>? <Filter> An example might be: Ldap://ldap.company name.xxx/o=company name%inc./,c=US> (base search including all attributes/object classes in scope). LDAP URLs use the percent symbol to represent commas in the DN.

Password Policies and Directory Servers

Password policies applied to user accounts vary slightly from one directory server to another. Normally, only the password changing policies can be set by users through the directory server graphical user inter-face (GUI). Other policies accessible only to Network Administrators through the directory server GUI may include one or more of the following operational parameters. Log-in Restrictions Change Password Check Password Syntax Password Minimum Length Send Expiration Warnings Password History Account Lockout Reset Password Failure Count LDAP Error Messages (e.g., Invalid Username/Password, Server Data Error, etc.) For instructions on installing LDAP-enabled directory servers, refer to the vendor-specific instructions in the Users Manuals.

Directory Server Schema for LDAP Authentication

Object classes and attributes will need to be modified accordingly to include LDAP authentication in the network (object classes and attributes are used specifically here to map user account information contained in the directory servers). All LDAP-enabled directory servers require entry of an auxiliary objectClass: passwordObject for user password policy information. Another auxiliary objectClass: password policy is used by the directory server to apply the password policy for the entire server. There is only one entry of this object for the database server.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 575 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

LDAP Accounting Attributes

Logging and accounting features include Account Start, Stop and Fail Times, and Dynamic Log. Typically, the Login and Logout logs can be accessed from the directory server software. Additional third-party software is required to retrieve and reset the log information to the directory servers for billing purposes.

SSL for an LDAP Authentication Server

A Secure Socket Layer (SSL) may be set up on the server for additional security. When SSL is enabled, the servers identity will be authenticated. The authentication requires a certificate from a Certification Authority (CA). If the CA providing the certificate is well known, the certificate is automatically extracted from the Kbase.img file on the switch (certs.pem). If the CA is not well known, the CAs certificate must be transferred to the switch via FTP to the /flash/certified or /flash/working directory and should be named optcerts.pem. The switch merges either or both of these files into a file called ldapcerts.pem. The switch automatically sets the port number to 636 when SSL is enabled. The 636-port number is typically used on LDAP servers for SSL. The port number on the switch must match the port number configured on the server.

Managing Policy Servers

Quality of Service (QoS) policies that are configured through Alcatel-Lucents PolicyView network management application are stored on a Lightweight Directory Access Protocol (LDAP) server. PolicyView is an OmniVista application that runs on an attached workstation.

Policy Server Specifications

The following tables lists important information about LDAP policy servers:
LDAP Policy Servers RFCs Supported Maximum number of policy servers (supported on the switch) Maximum number of policy servers (supported by PolicyView) RFC 2251Lightweight Directory Access Protocol (v3) RFC 3060Policy Core Information ModelVersion 1 Specification 4 1

Policy Server Defaults

Description The port number for the server Priority value assigned to a server, used to determine search order Whether a Secure Socket Layer is configured for the server Default 389 (SSL disabled) 636 (SSL enabled) 0 (lowest) No SSL

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 576 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Policy Server Overview

The Lightweight Directory Access Protocol (LDAP) is a standard directory server protocol. The LDAP policy server client in the switch is based on RFC 2251. Currently, only LDAP servers are supported for policy management. When the policy server is connected to the switch, the switch is automatically configured to communicate with the server to download and manage policies created by the PolicyView application. There is no required user configuration. (Note that the LDAP policy server is automatically installed when the Policy-View application is installed.) Note. The switch has separate mechanisms for managing QoS policies stored on an LDAP server and QoS policies configured directly on the switch. Information about installing the LDAP policy server is included in the Users Manual. Consult the server manufacturers documentation for detailed information about configuring the server.

Installing the LDAP Policy Server

Currently Netscape Directory Server 4.15 is supported. The server software is bundled with the Policy-View NMS application. Install the directory server software on the server. Install the Java Runtime Environment on the server.

Secure Socket Layer for a Policy Server

A Secure Socket Layer (SSL) may be configured between the policy server and the switch. If SSL is enabled, the PolicyView application can no longer write policies to the LDAP directory server. By default, SSL is disabled.

Interaction With CLI Policies

Policies configured via PolicyView can only be modified through PolicyView. They cannot be modified through the CLI. Any policy management done through the CLI only affects policies configured through the CLI. Note. If polices are applied from PolicyView or vice versa, it will activate all current configuration.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 577 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Diagnosing Switch Problems

Several tools are available for diagnosing problems that may occur with the switch. These tools include: Port Mirroring Port Monitoring Remote Monitoring (RMON) probes Switch Health Monitoring UDLD: support for monitoring the physical configuration of cables and detect unidirectional links SFlow

UDLD
Uni Directional Link Detection (UDLD) is a protocol for detecting and disabling unidirectional Ethernet fiber or copper links caused by mis-wiring of fiber strands, interface malfunctions, media converter faults, etc. The UDLD operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms. UDLD is a lightweight protocol that can be used to detect and disable one-way connections before they create dangerous situations such as Spanning Tree loops or other protocol malfunctions. The protocol is mainly used to advertise the identities of all the UDLD-capable devices attached to the same LAN segment and to collect the information received on the ports of each device to determine whether the Layer 2 communication is functioning properly. All connected devices must support UDLD for the protocol to successfully identify and disable unidirectional links. When UDLD detects a unidirectional link, the protocol administratively shuts down the affected port and generates a trap to alert the user.

UDLD Specifications
The following table lists important information about UDLD Specifications:

RFCs supported IEEE Standards supported Probe-message advertisement timer Echo-based detection timer Maximum neighbors per UDLD port Maximum number of UDLD ports per system

Not applicable at this time Not applicable at this time 7 to 90 in seconds 4 to 15 in seconds 32 128

UDLD Defaults
Description UDLD administrative state UDLD status of a port UDLD operational mode Probe-message advertisement timer Echo-based detection timer Default Disabled Disabled Normal 15 Seconds 8 Seconds

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 578 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

UDLD Overview
UDLD is a Layer 2 protocol used to examine the physical configuration connected through fiber-optic or twisted-pair Ethernet cables. UDLD detects and administratively shuts down the affected port, and alerts the user when a unidirectional link exists. Unidirectional links can create hazardous situations such as Spanning-Tree topology loops caused, for instance, by unwiring of fiber strands, interface malfunctions, media converters faults, etc. The UDLD feature is supported on the following port types: Copper ports Fiber ports

UDLD Operational Mode

UDLD supports two modes of operation: normal and aggressive modes. UDLD works with the Layer 1 mechanisms to determine the physical status of a link. A unidirectional link occurs whenever the traffic sent by a local device is received by its neighbor; but the traffic from the neighbor is not received by the local device.

Normal Mode
In this mode, the protocol depends on explicit information instead of implicit information. If the protocol is unable to retrieve any explicit information, the port is not put in the shutdown state; instead, it is marked as Undetermined. The port is put in the shutdown state only when it is explicitly determined that the link is defective when it is determined on the basis of UDLD-PDU processing that link has become unidirectional. In any such state transition, a trap is raised.

Aggressive Mode
In this mode, UDLD checks whether the connections are correct and the traffic is flowing bidirectionally between the respective neighbors. The loss of communication with the neighbor is considered an event to put the port in shutdown state. Thus, if the UDLD PDUs are not received before the expiry of a timer, the port is put in the UDLD-shutdown state. Since the lack of information is not always due to a defective link, this mode is optional and is recommended only for point-to-point links. UDLD shuts down the affected interface when one of these problems occurs: On fiber-optic or twisted-pair links, one of the interfaces cannot send or receive traffic. On fiber-optic or twisted-pair links, one of the interfaces is down while the other is up. One of the fiber strands in the cable is disconnected.

Mechanisms to Detect Unidirectional Links

The UDLD protocol is implemented to correct certain assumptions made by other protocols, and to help the Spanning Tree Protocol to function properly to avoid the creation of dangerous Layer 2 loops. UDLD uses two basic mechanisms: It advertises the identity of a port and learns about its neighbors. This information about the neighbors is maintained in a cache table. It sends continuous echo messages in certain circumstances that require fast notifications or fast resynchronization of the cached information.

Neighbor database maintenance

UDLD learns about other UDLD neighbors by periodically sending a Hello packet (also called an advertisement or probe) on every active interface to inform each device about its neighbors. When the switch receives a Hello message, the switch caches the information until the age time expires. If the switch receives a new Hello message before the aging of an older cache entry, the switch replaces the older entry with the new one. Whenever an interface is disabled and UDLD is running, or UDLD is disabled on an interface, or the switch is reset, UDLD clears all the existing cache entries for the interfaces that are affected by the configuration change. UDLD sends a message to the neighbors to flush the part of their caches affected by the status change. The message is intended to synchronize the caches. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 579 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Echo detection
UDLD depends on an echo-detection mechanism. UDLD restarts the detection window on its side of the connection and sends echo messages in response to the request, whenever a UDLD device learns about a new neighbor or receives a resynchronization request from an out-of-sync neighbor. This behavior is the same on all UDLD neighbors because the sender of the echoes expects to receive an echo as a response. If the detection window ends and no valid response is received, the link will be shut down, depending on the UDLD mode. When UDLD is in normal mode, the link is considered to be undetermined and will not be shut down. When UDLD is in aggressive mode, the link is considered to be unidirectional, and the interface is shut down. In normal mode, if UDLD is in the advertisement or in the detection phase and all the neighbor cache entries are aged out, UDLD restarts the link-up sequence to re-synchronize with potentially out-of-sync neighbors. In aggressive mode, if UDLD is in the advertisement or in the detection phase and all the neighbors of a port are aged out, UDLD restarts the link-up sequence to re-synchronize with potentially out-of-sync neighbors. UDLD shuts down the port, after the continuous messages, if the link state is undetermined.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 580 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Port Mirroring
Port mirroring copies all incoming and outgoing traffic from a single mirrored Ethernet port to a second mirroring Ethernet port, where it can be monitored with a Remote Network Monitoring (RMON) probe or network analysis device without disrupting traffic flow on the mirrored port. Switch Health monitoring software checks previously configured threshold levels for the switchs consumable resources, and notifies the Network Monitoring Station (NMS) if those limits are violated.

Port Mirroring Specifications

Ports Supported Mirroring Sessions Supported Ethernet (10Mbps)/Fast Ethernet (100Mbps)/Gigabit Ethernet and 10-Gigabit Ethernet One session supported per standalone switch. One (1) port mirroring session is supported per standalone switch chassis, or in the case of OmniSwitch 6800 and 6850 switches, in a stack consisting of two or more switches. Mirrored (monitored) and mirroring (monitoring) ports must be of identical capacity (both ports support identical Mbps rates) or the Mirroring port must be of higher capacity than the mirrored port. (Example: A mirrored Fast Ethernet port supports 100 Mbps, while a Mirroring Gigabit Ethernet port supports 1000 Mbps). The switch supports N-to-1 port mirroring; where up to 24 (OS6800) or 128 (OS6850/OS9000) source ports can be mirrored to a single destination port. 1 to 4094.

Port Capacity Requirements

N-to-1 Mirroring Supported Range of Unblocked VLAN IDs

Port mirroring Defaults

The following table shows port mirroring default values.
Parameter Description Mirroring Session Creation Protection from Spanning Tree (Spanning Tree Disable) Mirroring Status Configuration Mirroring Session Configuration Mirroring Session Deletion Default Value/Comments No Mirroring Sessions Configured Spanning Tree Enabled Enabled Enabled No Mirroring Sessions Configured

On OmniSwitch 9000 switches, you can set up port mirroring between Ethernet ports within the same switch chassis, while on OmniSwitch 6800 and 6850 switches, you can set up port mirroring across switches within a stack. Ethernet ports supporting port mirroring include 10BaseT/100BaseTX/1000BaseT (RJ-45), 1000BaseSX/LX/LH, and 10GBaseS/L (LC) connectors. When port mirroring is enabled, the active mirrored port transmits and receives network traffic normally, and the mirroring port receives a copy of all transmit and receive traffic to the active port. You can connect an RMON probe or network analysis device to the mirroring port to see an exact duplication of traffic on the mirrored port without disrupting network traffic to and from the mirrored port. Port mirroring runs in the Chassis Management software and is supported for Ethernet (10 Mbps), Fast Ethernet (100 Mbps), Gigabit Ethernet (1000 Mbps), and 10 Gigabit Ethernet (10000 Mbps) ports. In addition, the switch supports N-to-1 port mirroring, where up to 24 (OS6800) or 128 (OS6850/OS9000) source ports can be mirrored to a single destination port. Note the following restriction when configuring a port mirroring session: One (1) port mirroring session is supported per standalone switch chassis, or in the case of OmniSwitch 6800 and 6850 switches, in a stack consisting of two or more switches. You cannot configure a port mirroring and a port monitoring session on the same NI module in an OmniSwitch 9000. You cannot configure port mirroring and monitoring on the same switching ASIC on OmniSwitch 6850 Series switches. Each switching ASIC controls 24 ports (e.g., ports 124, 2548, etc.). For example, if a port mirroring session is configured for ports 1/12 and 1/22, then configuring a port monitoring session for any of the ports between 1 and 24 is not allowed. You cannot configure port mirroring and monitoring on the same switching ASIC on OmniSwitch 6800 Series switches. Each switching ASIC controls 12 ports (e.g., ports 112, 1324, etc.). For example, if a port mirroring session is configured for ports 1/6 and 1/10, then configuring a port monitoring session for any of the ports between 1 and 12 is not allowed. If a port mirroring session is configured across two switching ASICs, then configuring a monitoring session is not allowed on any of the ports controlled by each of the ASICs involved. For example, if a port mirroring session is configured for ports 1/8 and 1/30 on a 48-port switch, then configuring a port monitoring session involving any of the ports between 1 and 48 is not allowed. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 581 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

By default, port-mirroring sessions are bi-directional. What Ports Can Be Mirrored? OmniSwitch 6800/6850/9000 Series switches support mirroring (where applicable) between any 10/100/1000 port to any other 10/100/1000 port and between any fiber MiniGBIC SFP to any other fiber MiniGBIC SFP port. How Port Mirroring Works When a frame is received on a mirrored port, it is copied and sent to the mirroring port. The received frame is actually transmitted twice across the switch backplaneonce for normal bridging and then again to the mirroring port. When the mirrored port transmits a frame, a copy of the frame is made, tagged with the mirroring port as the destination, and sent back over the switch backplane to the mirroring port. The diagram below illustrates the data flow between the mirrored and mirroring ports. Note that when port mirroring is enabled, performance may be affected, since all frames received and transmitted by the mirrored port need to be copied and sent to the mirroring port.

What Happens to the Mirroring Port When you set up port mirroring and attach cables to the mirrored and mirroring ports, the mirroring port remains enabled and part of the Bridging Spanning Tree until you protect it from Spanning Tree updates by specifying an unblocked VLAN as part of the configuration command line. The mirroring port does not transmit or receive any traffic on its own. Mirroring on Multiple Ports If mirroring is enabled on multiple ports and the same traffic is passing through these ports, then only one copy of each packet is sent to the mirroring destination. When the packet is mirrored first time, the switching ASIC flags the packet as already mirrored If the packet goes through one more port where mirroring is enabled, that packet will not be mirrored again. If both mirroring and monitoring are enabled then the packet will be either mirrored or monitored (i.e., sent to CPU), whichever comes first. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 582 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Creating a Mirroring Session Before port mirroring can be used, it is necessary to create a port mirroring session. The port mirroring source destination CLI command can be used to create a mirroring session between a mirrored (active) port and a mirroring port. One (1) port mirroring session is supported in a standalone switch or in a stack consisting of two or more switches. In addition, N-to-1 port mirroring is supported; where up to 24 (OS6800) or 128 (OS6850/OS9000) source ports can be mirrored to a single destination port. Note. To prevent the mirroring (destination) port from being blocked due to Spanning Tree changes, be sure to specify the VLAN ID number (from 1 to 4094) for the port that will remain unblocked (protected from these changes while port mirroring is active). This parameter is optional; if it is not specified, changes resulting from Spanning Tree could cause the port to become blocked (default).

Using Port Mirroring with External RMON Probes

Port mirroring is a helpful monitoring tool when used in conjunction with an external RMON probe. Once you set up port mirroring, the probe can collect all relevant RMON statistics for traffic on the mirrored port. You can also move the mirrored port so that the mirroring port receives data from different ports. In this way, you can roam the switch and monitor traffic at various ports. Note. If the mirroring port will monitor mirrored traffic on an RMON probe belonging to a different VLAN than the mirrored port, it should be protected from blocking due to Spanning Tree updates. The following diagram illustrates how port mirroring can be used with an external RMON probe, to copy RMON probe frames and Management frames to and from the mirroring and mirrored ports. Frames received from an RMON probe attached to the mirroring port can be seen as being received by the mirrored port. These frames from the mirroring port are marked as if they are received on the mirrored port before being sent over the switch backplane to an NMS station. Therefore, management frames destined for the RMON probe are first forwarded out the mirrored port. After being received on the mirrored port, copies of the frames are mirrored out the mirroring portthe probe attached to the mirroring port receives the management frames.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 583 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Remote Port Mirroring

Remote Port Mirroring expands the port mirroring functionality by allowing mirrored traffic to be carried over the network to a remote switch. With Remote Port Mirroring the traffic is carried over the network using a dedicated Remote Port Mirroring VLAN, no other traffic is allowed on this VLAN. The mirrored traffic from the source switch is tagged with the VLAN ID of the Remote Port Mirroring VLAN and forwarded over the intermediate switch ports to the destination switch where an analyzer is attached. Note. Remote Port Mirroring is supported only on OS6850 and OS9000 Series switches. Since Remote Port Mirroring requires traffic to be carried over the network, the following exceptions to regular port mirroring exist: Spanning Tree must be disabled for the Remote Port Mirroring VLAN on all switches. There must not be any physical loop present in the Remote Port Mirroring VLAN. On the intermediate and destination switches, source learning must be disabled or overridden on the ports belonging to the Remote Port Mirroring VLAN. The QoS redirect feature can be used to override source learning on an OmniSwitch. The following types of traffic will not be mirrored: Link Aggregation Control Packets (LACP) 802.1AB (LLDP) 802.1x port authentication 802.3ag (OAM) Layer 3 control packets Generic Attribute Registration Protocol (GARP) BPDUs will not be mirrored on OS6850s but will be mirrored on OS9000s.

Application Example
The following diagram shows an example of a Remote Port Mirroring Configuration.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 584 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Port Monitoring
Port Monitoring Specifications
Ports Supported Monitoring Sessions Supported File Type Supported Ethernet (10 Mbps)/Fast Ethernet (100 Mbps)/Gigabit Ethernet (1 Gb/1000 Mbps) /10 Gigabit Ethernet (10 Gb/10000 Mbps) One per switch. ENC file format (Network General Sniffer Network Analyzer Format)

Port Monitoring Defaults

The following table shows port mirroring default values. Global Port Monitoring Defaults
Parameter Description Monitoring Session Creation Monitoring Status Monitoring Session Configuration Port Monitoring Direction Data File Creation Data File Size File Overwriting Time before session is deleted Default Value/Comments No Monitoring Sessions Configured Disabled Disabled Bi-directional Enabled 16384 Bytes Enabled 0 seconds

An essential tool of the network engineer is a network packet capture device. A packet capture device is usually a PC-based computer, such as the Sniffer, that provides a means for understanding and measuring data traffic of a network. Understanding data flow in a VLAN-based switch presents unique challenges primarily because traffic takes place inside the switch, especially on dedicated devices. By default, a port monitoring session will never be disabled. The length of time before a port monitoring session is disabled is from 0 (the default, where the session is permanent) to 2147483647 seconds. By default, a file called pmonitor.enc is created in the /flash directory when you configure and enable a port monitoring session. By default, port-monitoring sessions are bi-directional. The port-monitoring feature allows you to examine packets to and from a specific Ethernet port. Port monitoring has the following features: Software commands to enable and display captured port data. Captures data in Network General file format. A file called pmonitor.enc is created in /flash memory when you configure and enable a port monitoring session. Data packets time stamped. One port monitored at a time. RAM-based file system. Statistics gathering and display The port-monitoring feature also has the following restrictions: Estimated packet capture rate is around 500 packets/second. The maximum number of monitoring session is limited one per switch Link Aggregation ports can not be monitored If both mirroring and monitoring are enabled then packets will be either mirrored or monitored (i.e., sent to CPU), whichever comes first. You can select to dump real-time packets to a file. Once a file is captured, you can FTP it to a Sniffer or PC for viewing. Note. Port monitoring requires Release 6.1.1.R01 or later.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 585 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Remote Monitoring (RMON)

RMON Specifications
RFCs Supported RMON Functionality Supported 2819 - Remote Network Monitoring Management Information Base Basic RMON 4 group implementation Ethernet Statistics group History (Control and Statistics) group Alarms group Events group RMON 10 group* RMON2* Host group HostTopN group Matrix group Filter group Packet Capture group (*An external RMON probe that includes RMON 10 group and RMON2 may be used where full RMON probe functionality is required.) Ethernet/History/Alarm Active/Creating/Inactive 1 to 3600 1 to 65535 1 to 2147483647 Rising Alarm/Falling Alarm/RisingOrFalling Alarm Delta Value/Absolute RisingAlarm/FallingAlarm These traps are generated whenever an Alarm entry crosses either its Rising Threshold or its Falling Threshold and generates an event con-figured for sending SNMP traps.

RMON Functionality Not Supported

Flavor (Probe Type) Status History Control Interval (seconds) History Sample Index Range Alarm Interval (seconds) Alarm Startup Alarm Alarm Sample Type RMON Traps Supported

RMON Probe Defaults

The following table shows Remote Network Monitoring default values. Global RMON Probe Defaults
Parameter Description RMON Probe Configuration Default Value/Comments No RMON probes configured.

Remote Network Monitoring (RMON) is an SNMP protocol used to manage networks remotely. RMON probes can be used to collect, interpret, and forward statistical data about network traffic from designated active ports in a LAN segment to an NMS (Network Management System) application for monitoring and analysis without negatively impacting network performance. RMON software is fully integrated in the Chassis Management software and works with the Ethernet software to acquire statistical information. The following diagram illustrates how an External RMON probe can be used with port mirroring to copy RMON probe frames and Management frames to and from the mirroring and mirrored ports. Frames received from an RMON probe attached to the mirroring port can be seen as being received by the mirrored port. These frames from the mirroring port are marked as if they are received on the mirrored port before being sent over the switch backplane to an NMS station. Therefore, management frames that are destined for the RMON probe are first forwarded out of the mirrored port. After being received on the mirrored port, copies of the frames are mirrored out of the mirroring portthe probe attached to the mirroring port receives the management frames.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 586 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

RMON probes can be enabled or disabled via CLI commands. Configuration of Alarm threshold values for RMON traps is a function reserved for RMON-monitoring NMS stations. This feature supports basic RMON 4 group implementation in compliance with RFC 2819, including the Ethernet Statistics, History (Control & Statistics), Alarms and Events groups (described below). Note. RMON 10 group and RMON2 are not implemented in the current release. An external RMON probe that includes RMON 10 group and RMON2 may be used where full RMON probe functionality is required.

Ethernet Statistics
Ethernet statistics probes are created whenever new ports are inserted and activated in the chassis. When a port is removed from the chassis or deactivated, the Ethernet statistics group entry associated with the physical port is invalidated and the probe is deleted. The Ethernet statistics group includes port utilization and error statistics measured by the RMON probe for each monitored Ethernet interface on the switch. Examples of these statistics include CRC (Cyclic Redundancy Check)/alignment, undersized/oversized packets, fragments, broadcast/multicast/unicast, and bandwidth utilization statistics.

History (Control & Statistics)

The History (Control & Statistics) group controls, and stores periodic statistical samplings of data from various types of networks. Examples include Utilization, Error Count and Frame Count statistics.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 587 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Alarm
The Alarm group collects periodic statistical samples from variables in the probe and compares them to previously configured thresholds. If a sample crosses a previously configured threshold value, an Event is generated. Examples include Absolute or Relative Values, Rising or Falling Thresholds on the Utilization Frame Count and CRC Errors.

Event
The Event group controls generation and notification of events from the switch to NMS stations. For example, customized reports based on the type of Alarm can be generated, printed and/or logged. Notes. The following RMON groups are not implemented: Host, HostTopN, Matrix, Filter and Packet Capture. Network activity on sub-networks attached to an RMON probe can be monitored by Network Management Software (NMS) applications.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 588 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Switch Health
Switch Health Specifications
Health Functionality Supported Switch level CPU Utilization Statistics (percentage); Switch/module/port level Input Utilization Statistics (percentage); Switch/module/port level Input/Output Utilization Statistics (percentage); Switch level Memory Utilization Statistics (percentage); Device level Temperature Statistics (Celsius). Most recent utilization level; Average utilization level during last minute; Average utilization level during last hour; Maximum utilization level during last hour. Saved for previous 60 seconds. Stored. Calculated for previous 60 seconds and stored. Indicates that none of the resource was measured for the period. Indicates that a non-zero amount of the resource (less than 2%) was measured for the period. Calculated based on Resource Measured During Period/Total Capacity. Apply automatically across all levels of switch (switch/module/port). A Resource Threshold was exceeded by its corresponding utilization value in the current cycle. A Resource Threshold was exceeded by its corresponding utilization value in the previous cycle, but is not exceeded in the current cycle. Device, module, port-level threshold crossings.

Monitored Resource Utilization Levels

Resource Utilization Raw Sample Values Resource Utilization Current Sample Values Resource Utilization Maximum Utilization Value Utilization Value = 0 Utilization Value = 1 Percentage Utilization Values Resource Threshold Levels Rising Threshold Crossing Falling Threshold Crossing Threshold Crossing Traps Supported

Switch Health Defaults

Parameter Description Resource Threshold Limit Configuration Sampling Interval Configuration Switch Temperature Default Value/Comments 80 percent 5 seconds 60 degrees Celsius

To monitor resource availability, the NMS (Network Management System) needs to collect significant amounts of data from each switch. As the number of ports per switch (and the number of switches) increases, the volume of data can become overwhelming. The Health Monitoring feature can identify and monitor a switchs resource utilization levels and thresholds, improving efficiency in data collection.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 589 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Health Monitoring provides the following data to the NMS: Switch-level Input/Output, Memory and CPU Utilization Levels Module-level and Port-level Input/Output Utilization Levels Health monitoring software monitors threshold levels for the switchs consumable resourcesbandwidth, RAM memory, and CPU capacityas well as the ambient chassis temperature. When a threshold is exceeded, the Health Monitoring feature sends a trap to the Network Management Station (NMS). A trap is an alarm alerting the user to specific network events and, in the case of Health-related traps, indicates specifically which threshold has been crossed. Note. When a resource falls back below the configured threshold, an addition trap is sent to the user. This indicates that the resource is no longer operating beyond its configured threshold limit. For each monitored resource, the following variables are defined: Most recent utilization level (percentage) Average utilization level over the last minute (percentage) Average utilization level over the last hour (percentage) Maximum utilization level over the last hour (percentage) Threshold level Additionally, Health Monitoring provides the capacity to specify thresholds for the resource utilization levels it monitors, and generates traps based on the specified threshold criteria. The CLI commands that can be used to configure resource parameters and monitor or reset statistics for switch resources include: Health thresholdConfigures threshold limits for input traffic (RX), output/input traffic (TX/RX), memory usage, CPU usage, and chassis temperature. Show health thresholdDisplays current health threshold settings. Health intervalConfigures sampling interval between health statistics checks. Show health intervalDisplays current health sampling interval, measured in seconds. Show health Displays health statistics for the switch, as percentages of total resource capacity. Health statistics resetResets health statistics for the switch.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 590 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

SFlow
SFlow is a network monitoring technology that gives visibility in to the activity of the network, by providing network usage information. It provides the data required to effectively control and manage the network usage. SFlow is a sampling technology that meets the requirements for a network traffic monitoring solution. SFlow provides a network-wide view of usage and active routes. It is used for measuring network traffic, collecting, storing, and analyzing the traffic data. As it is scalable, that doesnt add significant network load. SFlow is an industry standard with many vendors delivering products with this support. Some of the applications of the sFlow data include: Detecting, diagnosing, and fixing network problems Real-time congestion management Detecting unauthorized network activity Usage accounting and billing Understanding application mix Route profiling and peer optimization Capacity planning SFlow is a sampling technology embedded within switches/routers. It provides the ability to monitor the traffic flows. It requires a sFlow Agent software process running as part of the switch software and a sFlow collector which receives and analyses the monitored data. sFlow collector makes use of SNMP to communicate with a sFlow agent in order to configure sFlow monitoring on the device (switch). SFlow agent running on the switch/router, combines interface counters and traffic flow (packet) samples preferably on all the interfaces into sFlow Datagrams that are sent across the network to a sFlow collector. Packet sampling on the switch/router is typically performed by the switching/routing ASICs, providing wire-speed performance. In this case, sFlow agent does very little processing, by packaging data into sFlow Datagrams that are immediately sent on network. This minimizes the memory and CPU utilization by sFlow agent. MIB information for the sFlow commands is as follows: Filename: Alcatel-LucentIND1PortMirMon.MIB Module: Alcatel-Lucent-IND1-PORT-MIRRORING-MONITORING-MIB Filename: SFLOW_RFC3176.MIB Module: SFLOW-MIB

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 591 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Switch Logging
Switch logging is an event logging utility that is useful in maintaining and servicing the switch. Switch logging uses a formatted string mechanism to either record or discard event data from switch applications. The log records are copied to the output devices configured for the switch. Log records can be sent to a text file and written into the flash file system. The log records can also be scrolled to the switchs console or to a remote IP address. Switch logging information can be customized and configured through Command Line Interface (CLI) commands, WebView and SNMP. Log information can be helpful in resolving configuration or authentication issues, as well as general switch errors. Notes. Switch logging commands are not intended for use with low-level hardware and software debugging. It is strongly recommended that you contact an Alcatel-Lucent Customer Service representative for assistance with debugging functions.

Switch Logging Specifications

Functionality Supported Functionality Not Supported Logging Devices Application ID Levels Supported High-level event logging mechanism that forwards requests from applications to enabled logging devices. Not intended for debugging individual hardware applications Flash Memory/Console/IP Address IDLE (255), DIAG (0), IPC-DIAG (1), QDRIVER (2), QDISPATCHER (3), IPC-LINK (4), NI-SUPERVISION (5), INTERFACE (6), 802.1Q (7), VLAN (8), GM (9), BRIDGE (10), STP (11), LINKAGG (12), QOS (13), RSVP (14), IP (15), IPMS (17), AMAP (18), GMAP (19), AAA (20), IPC-MON (21), IP-HELPER (22), PMM (23), MODULE (24), EIPC (26), CHASSIS (64), PORT-MGR (65), CONFIG (66), CLI (67), SNMP (68), WEB (69), MIPGW (70), SESSION (71), TRAP (72), POLICY (73), DRC (74), SYSTEM (75), HEALTH (76), NAN-DRIVER (78), RMON (79), TELENET (80), PSM (81), FTP (82), SNMI (83), DIS-TRIB (84), EPIL0GUE (85), LDAP (86), NOS-NMP (87), SSL (88), DBGGW (89), LANPOWER (108) 2 (Alarm - highest severity), 3 (Error), 4 (Alert), 5 (Warning) 6 (Info - default), 7 (Debug 1), 8 (Debug 2), 9 (Debug 3 lowest severity)

Severity Levels/Types Supported

Switch Logging Defaults

The following table shows switch logging default values. Global Switch Logging Defaults
Parameter Description Enabling/Disabling switch logging Switch logging severity level Enabling/Disabling switch logging Output Switch logging file size Default Value/Comments Enabled Default severity level is info. The numeric equivalent for info is 6 Flash Memory and Console 128000 bytes

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 592 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Switch Logging Overview

Switch logging uses a formatted string mechanism to process log requests from switch applications. When a log request is received, switch logging compares the severity level included with the request to the severity level stored for the application ID. If there is a match, a log message is generated using the format specified by the log request and placed on the switch log queue. Switch logging then returns control back to the calling application. You can specify the path to where the log file will be printed in the switchs flash file system. You can also send the log file to other output devices, such as the console or remote IP address. In this case, the log records generated are copied to all configured output devices. The swlog output command allows you to send the switch logging information to your console, to the switchs flash memory, or to a specified IP address. Switch logging information can be displayed and configured through CLI commands, WebView and SNMP. The information generated by switch logging can be helpful in resolving configuration or authentication issues, as well as general errors. By default, the size of the switch-logging file is 128000 bytes. Notes. Although switch logging provides complementary functionality to switch debugging facilities, the switch logging commands are not intended for use with low-level hardware and software debugging functions. The configuration snapshot command can be used to capture and save all switch logging configuration settings in a text file that can be viewed, edited, and used as a configuration file. The switch-logging feature can log all switch error-type events for a particular switch application. You can also assign severity levels to the switch applications that will cause some of the events to be filtered out of your display. The swlog appid level command is used to assign the severity levels to the applications. The syntax for the swlog appid level command requires that you identify a switch application and assign it a severity level. The severity level controls the kinds of error-type events that will be recorded by the switch logging function. If an application experiences an event equal to or greater than the severity level assigned to the application, the event will be recorded and forwarded to the configured output devices. You can specify the application either by the application ID CLI keyword or by its numeric equivalent.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 593 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Displaying Switch Logging Records

The show log swlog command can produce a display showing all switch logging information or you can display information according to session, timestamp, application Id or severity level. The following sample screen output shows a display of all switch logging information. Note. Switch logging frequently records a very large volume of data. It can take several minutes for all switch logging information to scroll to the console screen.

The fields in the above example are defined as follows: The FILE ID field specifies the File name (e.g., swlog1.log), endPtr Global Sequence ID reference number (e.g., 9968), Configuration Size (e.g., 10000), Current Size (e.g., 10000), and Mode (e.g., 2). The Timestamp field indicates when the swlog entry occurred (e.g., THU, NOV 12, 02:06:52 2001). The Application field specifies the application ID for which the stored swlog information is displayed (e.g., SYSTEM). The Level field specifies the severity level for which the stored information is displayed (e.g., Warning). The Log Message field specifies the condition recorded by the switch-logging feature. The information in this field usually wraps around to the next line of the screen display as shown in this example.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 594 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Monitoring Memory
Debug memory monitor commands can monitor memory allocation and free memory (such as detection of invalid free addresses and maintenance of size statistics). These commands are useful for monitoring logging of events, leak detection, classification of memory allocations, detection of invalid free addresses, and maintenance of size statistics. Notes. System Debug (kTrace and sysTrace) commands is intended for use by qualified Alcatel-Lucent Customer Support personnel to assist customers in diagnosing or debugging system performance. For information about these commands, see the chapter titled, Memory Monitoring Commands in the OmniSwitch CLI Reference Guide. It is strongly recommended that you contact an Alcatel-Lucent Customer Service representative for assistance. The Switch Logging feature is a high-level event logging mechanism that can also be useful in maintaining and servicing the switch. The configuration snapshot command can be used to capture and save all kTrace, sysTrace, Memory Monitor, and Switch Logging configuration settings in a snapshot text file that can be viewed, edited, and used as a configuration file.

Memory Monitoring Specifications

The following table shows Memory Monitoring specifications:
Functionality Supported Fence Post/ Bad Address Detection/ Leak Monitoring/ Memory Classification/ Global Statistical Gathering/ Task Statistical Gathering/ Size Statistical Gathering. Ownership Violations. Standard Out (console)/ Switch Logging/ sysTrace Buffer.

Functionality Not Supported Show Command Output Devices Supported

Memory Monitoring Defaults

The following table shows Memory Monitoring default values:
Parameter Description Memory Monitoring Default Value/Comments Disabled

Debug Memory Commands Overview

The Debug Memory Commands provide monitoring of memory allocation and free memory. By providing a method to enable/disable memory monitoring and display memory usage reports, these commands can be used to monitor logging of events, leak detection, classification of memory allocations, detection of invalid free addresses, and maintenance of size statistics. Additionally, the following automatic outputs will occur under specific conditions: If there is an attempt to free an invalid address, the monitor will create a switch log message, cause a Post Mortem Dump (PMD) of the memory monitor variables and log, and suspend the task. For information about using the show log pmd command to view the contents of a stored PMD file, see the chapter titled, Memory Monitoring Commands in the OmniSwitch CLI Reference Guide. If a memory leak of unclassified memory is detected, the service will generate a sysTrace (System Trace) message. The system trace facility provides a consistent, high-level mechanism for capturing event records in a history buffer. Captured sysTrace information can be referenced for system debugging. For information about using the sysTrace utility to enable, disable or view sysTrace log information, see the chapter titled, Memory Monitoring Commands in the OmniSwitch CLI Reference Guide.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 595 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Logging into the Switch

Logging into the switch may be done locally or remotely. Management tools include: the Command Line Interface (CLI), which may be accessed locally via the console port, or remotely via Telnet; WebView, which requires an HTTP client (browser) on a remote workstation; and SNMP, which requires an SNMP manager (such as Alcatel-Lucents OmniVista) on the remote workstation. Secure sessions are available using the Secure Shell interface. File transfers can be done via FTP or Secure Shell FTP.

Logging Specifications
Telnet clients supported FTP clients supported HTTP (WebView) clients supported Any standard Telnet client. Any standard FTP client. Internet Explorer for Windows NT, Windows XP, and Windows 2000, version 6.0 Netscape for Windows NT, Windows XP, and Windows 2000, version 7.1 Netscape for Sun OS 2.8, version 4.79 Netscape for HP-UX 11.0, version 4.79. Any standard Secure Shell client (Secure Shell Version 2). Any standard SNMP manager.

Secure Shell clients supported SNMP clients supported

Login Defaults
Parameter Description Session login attempts allowed before the TCP connection is closed. Timeout period allowed for session login before the TCP connection is closed. Inactivity timeout period. The length of time the switch can remain idle during a login session before the switch will close the session. Default 3 attempts 55 seconds 4 minutes

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 596 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Overview of Switch Login Components

Switch access components include access methods (or interfaces) and user accounts stored on the local user database in the switch and/or on external authentication servers. Each access method, except the console port, must be enabled or unlocked on the switch before users can access the switch through that interface.

Management Interfaces
Logging into the switch may be done locally or remotely. Remote connections may be secure or insecure, depending on the method. Management interfaces are enabled using the aaa authentication command. This command also requires specifying the external servers and/or local user database that will be used to authenticate users. The process of authenticating users to manage the switch is called Authenticated Switch Access (ASA).

Logging Into the CLI

Console portA direct connection to the switch through the console port: The console port is always enabled for the default user account. TelnetAny standard Telnet client may be used for remote login to the switch. This method is not secure. FTPAny standard FTP client may be used for remote login to the switch. This method is not secure. Secure ShellAny standard Secure Shell client may be used for remote login to the switch.

Using the WebView Management Tool

HTTPThe switch has a Web browser management interface for users logging in via HTTP. This management tool is called WebView.

Using SNMP to Manage the Switch

SNMPAny standard SNMP browser may be used for logging into the switch.

User Accounts
User accounts may be configured and stored directly on the switch, and user accounts may also be configured and stored on an external authentication server or servers. The accounts include a username and password. In addition, they also specify the users privileges or end-user profile, depending on the type of user account. In either case, the user is given read-only or read-write access to particular commands. Local User Database The user command creates accounts directly on the switch. External Authentication Servers The switch may be set up to communicate with external authentication servers that contain user information. The user information includes usernames and passwords; it may also include privilege information or reference an end-user profile name. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 597 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Using Telnet
Telnet may be used to log into the switch from a remote station. All of the standard Telnet commands are supported by software in the switch. When Telnet is used to log in, the switch is acting as a Telnet server. A Telnet session may also be initiated from the switch itself during a login session. In this case, the switch is acting as a Telnet client. Logging Into the Switch Via Telnet Before you can log into the OmniSwitch using a Telnet interface, the telnet option of the aaa authentication command must be enabled. Once enabled, any standard Telnet client may be used to log into the switch. To log into the switch, open your Telnet application and enter the switchs IP address (the IP address will typically be the same as the one configured for the EMP). The switchs welcome banner and login prompt display. Note. A Telnet connection is not secure. Secure Shell is recommended instead of Telnet or FTP as a secure method of accessing the switch.

Using FTP
The OmniSwitch can function as an FTP server. Any standard FTP client may be used. Note. An FTP connection is not secure. Secure Shell is recommended instead of FTP or Telnet as a secure method of accessing the switch. Using FTP to Log Into the Switch You can access the OmniSwitch with a standard FTP application. To login to the switch, start your FTP client. Where the FTP client asks for Name, enter the IP address of your switch. Where the FTP client tasks for User ID, enter the username of your login account on the switch. Where the FTP client asks for Password, enter your switch password. Note. If you are using Authenticated Switch Access (ASA), the port interface must be authenticated for FTP use and the username profile must have permission to use FTP. Otherwise the switch will not accept an FTP login. Note. You must use the binary mode (bin) to transfer image files via FTP.

Using Secure Shell

The OmniSwitch Secure Shell feature provides a secure mechanism that allows you to log in to a remote switch, to execute commands on a remote device, and to move files from one device to another. Secure Shell provides secure, encrypted communications even when your transmission is between two untrusted hosts or over an un-secure network. Secure Shell protects against a variety of security risks including the following: IP spoofing IP source routing DNS spoofing Interception of clear-text passwords and other data by intermediate hosts Manipulation of data by users on intermediate hosts Note. The OmniSwitch supports Secure Shell Version 2 only.

Secure Shell Components

The OmniSwitch includes both client and server components of the Secure Shell interface and the Secure Shell FTP file transfer protocol. SFTP is a subsystem of the Secure Shell protocol. All Secure Shell FTP data are encrypted through a Secure Shell channel. Since Secure Shell provides a secure session, the Secure Shell interface and SFTP are recommended instead of the Telnet program or the FTP protocol for communications over TCP/IP for sending file transfers. Both Telnet and FTP are available on the OmniSwitch but they do not support encrypted passwords. Note. Secure Shell may only be used to log into the switch to manage the switch. It cannot be used for Layer 2 authentication through the switch.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 598 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Secure Shell Interface

The Secure Shell interface is invoked when you enter the ssh command. After the authentication process between the client and the server is complete, the remote Secure Shell interface runs in the same way as Telnet.

Secure Shell File Transfer Protocol

Secure Shell FTP is the standard file transfer protocol used with Secure Shell version 2. Secure Shell FTP is an interactive file transfer program (similar to the industry standard FTP), which performs all file transfer operations over a Secure Shell connection. You invoke the Secure Shell FTP protocol by using the sftp command. Once the authentication phase is completed, the Secure Shell FTP subsystem runs. Secure Shell FTP connects and logs into the specified host, then enters an interactive command mode.

Secure Shell Application Overview

Secure Shell is an access protocol used to establish secured access to your OmniSwitch. The Secure Shell protocol can be used to manage an OmniSwitch directly or it can provide a secure mechanism for managing network servers through the OmniSwitch. The drawing below illustrates the Secure Shell being used as an access protocol replacing Telnet to manage the OmniSwitch. Here, the user terminal is connected through the network to the switch.

The drawing below shows a slightly different application. Here, a terminal connected to a single OmniSwitch acting as a Secure Shell client as an entry point into the network. In this scenario, the client portion of the Secure Shell software is used on the connecting OmniSwitch and the server portion of Secure Shell is used on the switches or servers being managed.

Secure Shell Authentication

Secure Shell authentication is accomplished in several phases using industry standard algorithms and exchange mechanisms. The authentication phase is identical for Secure Shell and Secure Shell SFTP.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 599 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Protocol Identification
When the Secure Shell client in the OmniSwitch connects to a Secure Shell server, the server accepts the connection and responds by sending back an identification string. The client will parse the servers identification string and send an identification string of its own. The purpose of the identification strings is to validate that the attempted connection was made to the correct port number. The strings also declare the protocol and software version numbers. This information is needed on both the client and server sides for debugging purposes. At this point, the protocol identification strings are in human-readable form. Later in the authentication process, the client and the server switch to a packet-based binary protocol, which is machine-readable only.

Algorithm and Key Exchange

One or several host-specific DSA keys identify the OmniSwitch Secure Shell server. Both the client and server process the key exchange to choose a common algorithm for encryption, signature, and compression. This key exchange is included in the Secure Shell transport layer protocol. It uses a key agreement to produce a shared secret that cannot be determined by either the client or the server alone. The key exchange is combined with a signature and the host key to provide host authentication. Once the exchange is completed, the client and the server turn encryption on using the selected algorithm and key. The following elements are supported:
Host Key Type Cipher Algorithms Signature Algorithms Compression Algorithms Key Exchange Algorithms DSA AES, Blowfish, Cast, 3DES, Arcfour, Rijndael MD5, SHA1 None Supported Diffie-hellman-group-exchange-sha1 Diffie-hellman-group1-sha1

Note. The OmniSwitch generates a 512-bit DSA host key at initial startup. The DSA key on the switch is made up of two files contained in the /flash/network directory; the public key is called ssh_host_dsa_key.pub, and the private key is called ssh_host_dsa_key. To generate a different DSA key, use the Secure Shell tools available on your Unix or Windows system and copy the files to the /flash/network directory on your switch. The new DSA key will take effect after the OmniSwitch is rebooted. Authentication Phase When the client tries to authenticate, the server determines the process used by telling the client which authentication methods can be used. The client has the freedom to attempt several methods listed by the server. The server will disconnect itself from the client if a certain number of failed authentications are attempted or if a timeout period expires. Authentication is performed independent of whether the Secure Shell interface or the SFTP file transfer protocol will be implemented. Connection Phase After successful authentication, both the client and the server process the Secure Shell connection protocol. The OS6850 supports one channel for each Secure Shell connection. This channel can be used for a Secure Shell session or a Secure Shell FTP session.

The Login Banner

The Login Banner feature allows you to change the banner that displays whenever someone logs into the switch. This feature can be used to display messages about user authorization and security. You can display the same banner for all login sessions or you can implement different banners for different login sessions. You can display a different banner for logins initiated by FTP sessions than for logins initiated by a direct console or a Telnet connection. The switch supports a default login message.

The DNS Resolver

A Domain Name System (DNS) resolver is an optional Internet service that translates host names into IP addresses. Every time you enter a host name when logging into the switch, a DNS service must look up the name on a server and resolve the name to an IP address. You can configure up to three domain name servers that will be queried in turn to resolve the host name. If all servers are queried and none can resolve the host name to an IP address, the DNS fails. If the DNS fails, you must either enter an IP address in place of the host name or specify the necessary lookup tables on one of the specified servers. Note. You do not need to enable the DNS resolver service unless you want to communicate with the switch by using a host name. If you use an IP address rather than a host name, the DNS resolver service is not needed. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 600 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Managing System Files

File Management Specifications
File Transfer Methods Switch Software Utility Configuration Recovery Switch /flash Directory File/Directory Name Metrics File/Directory Name Characters Maximum Number of Files/Directories Sub-Directories Text Editing System Clock System Date Default Value FTP, Zmodem OmniSwitch as an FTP Client The /flash/certified directory holds configurations that are certified as the default start-up files for the switch. They will be used in the event of a non-specified reload. 64 MB flash memory available for switch files and directories Contains the /certified and /working directories 128 characters maximum for directory and file names 255 character maximum for a fully qualified path Character types are limited to a-z, A-Z, 0-9, dashes (-), dots (.), and underlines (_) Maximum of 244 files and/or directories allowed in the root (flash) directory. Up to seven sub-directories allowed including /flash. Vi standard UNIX editor. The Ed standard UNIX editor is available in the debug mode. Set local date, time and time zone, Universal Time Coordinate (UTC), Daylight Savings (DST or summertime). THU JAN 01 1970 (Thursday, January 1, 1970)

Switch Administration Overview

The OmniSwitch has a variety of software features designed for different networking environments and applications. Over the life of the switch, it is very likely that your configuration and feature set will change because the needs of your network are likely to expand. Also, software updates become available from Alcatel-Lucent. If you change your configuration to upgrade your network, you must understand how to install switch files and to manage switch directories. The OmniSwitch 6850 switch has 64 MB of usable flash memory. You can use this memory to store files, including executable files (used to operate switch features and applications), configuration files, and log files. You need to understand the various methods of loading files onto the switch for software upgrades and new features. Once the files are on the switch, the CLI has commands that allow you to load, copy, and delete these files. The CLI also has commands for displaying, creating, and editing ASCII files directly on the switch. You may also want to establish a file directory structure to help organize your files on the switch. All of the files and directories on the switch bear a time stamp. This is useful for switch administration because the time stamp allows you to tell at a glance which files are the most recent. You can set the system clock that controls these time stamps as well as other time based switch functions.

File Transfer
The switch can receive and send files using industry standard local and remote transfer methods. Because file transfers can involve logging onto the switch from a remote host, security factors, such as DNS resolver and Authenticated Switch Access requirements should be considered. It is not enough to simply transfer a file onto the switch. Once files are on the switch, they must be registered in order to become functional. The OmniSwitch has a directory structure that allows you to install new software while maintaining a backup copy of your old configuration.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 601 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Switch Directories
You can create your own directories in the switch flash directory. This allows you to organize your configuration and text files on the switch. You can also use the vi command to create files.

File and Directory Management

A number of CLI commands allow you to manage files on your switch by grouping them into sub-directories within the switchs flash directory. These commands perform the same functions as file management software applications (such as Microsofts Explorer) perform on a workstation. For documentation purposes, we have categorized the commands into three groups. Directory commands allow you to create, copy, move, remove, rename, and display directories. File commands allow you copy, edit, rename, remove, change, and display file attributes. Utility commands display memory and system diagnostic information. The following illustration represents a sample flash directory that contains three directories and six files at the top level. The sample working directory and the certified directory both hold five files. The sample network directory holds one file. Note. Your switch may show files and directories different from the ones shown in this example. The following represents the OmniSwitch 6800 File & Directory Management, which is very similar to that of the OmniSwitch 6850 Series.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 602 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using Wildcards
Wildcards allow you to substitute symbols (* or ?) for text patterns while using file and directory commands. The asterisk (*) takes the place of multiple characters and the question mark character (?) takes the place of single characters. More than one wildcard can be used within a single text string.

Directory Commands
The directory commands are applied to the switch file system and to files contained within the file system. When you first enter the flash directory, your login is located at the top of the directory tree. You may navigate within this directory by using the pwd and cd commands. The location of your login within the directory structure is called your current directory. You need to observe your login location because when you issue a command, that command applies only to directories and files in your current directory unless another path is specified. Note: Although, the following illustrates the OmniSwitch 6800 logical representation of the file directory, the OmniSwitch 6850 logical representation of the file directory is also very similar.

Loading Software onto the Switch

There are three common methods for loading software to and from your switch. The method you use depends on your workstation software, your hardware configuration, and the location and condition of your switch. FTP ServerYou can use the switch as an FTP server. If you have FTP client software on your workstation, you can transfer a file to the switch via FTP. This is normally done to load or upgrade the switchs software or configurations. FTP ClientYou can use the switch as an FTP client by connecting a terminal to the switchs console port and using standard FTP commands. This feature is useful in cases where you do not have access to a workstation with an FTP client. ZmodemYou can load software directly through the serial port with any terminal emulator that supports the Zmodem protocol. Note that a Zmodem transfer of large files may take several minutes to complete.

Using the Switch as an FTP Server

The switch can act as an FTP server for receiving files transferred from your workstation. You can transfer software files to the switch using standard FTP client software located on a host workstation. This is normally done to load or upgrade the switch software.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 603 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using the Switch as an FTP Client

Using the switch as an FTP client is useful in cases where you do not have access to a workstation with an FTP client. You can establish an FTP session locally by connecting a terminal to the switch console port. You can also establish an FTP session to a remote switch by using a Telnet session. Once you are logged into the switch as an FTP client, you can use standard FTP commands.

Using Zmodem
A Zmodem application is included in the switch software so that new programs and archives can be uploaded through the switchs serial console port. There are generally two situations that would require you to use the switchs console serial port to load software-using Zmodem. Your system is having problems and the FTP transfer method does not work. The switchs Ethernet Management port is either not functioning or not configured. To use Zmodem, you must have a terminal emulator that supports the Zmodem protocol. There are many Zmodem products available that operate differently.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 604 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Registering Software Image Files

New software transferred to the switch must go through a registration process before the switch can use it. The registration process includes two tasks. Transfer the new software file(s) to the switchs /flash/working directory via remote connection. Register the software by executing the install command. Note. Switch software must be located in the switchs /flash/working directory before the install command is executed. Note. All registration processes take place within the working directory of the switch. New files are never directly written to the certified directory. It is possible to perform registration procedures in the working directory even if the switch is running off the files in the working directory. If the switch is booted using files in the certified directory, no immediate effect from the registration will be realized until the system is restarted from the working directory. If the system was booted from the working directory, the new software will be immediately available for use by the system following the successful completion of the registration process.

Directories on the Switch

When you log into the switch, your current directory is the flash directory. For a factory default switch, the flash directory contains three sub-directories and several files. It is important to understand the relationship of these directories before you load software or edit any of the files. The three directories are described here: Certified directoryThis directory contains configuration files that are certified as the default start-up files for the switch. These are the trusted configuration and binary image files. They will be used in the event of a non-specified reload. Do not attempt to edit these files. The path to this directory is /flash/certified. Working directoryThe working directory is a repository for configuration files that you are working on. If you are working on configuration files to develop a custom switch application, you may want to test them before certifying them as the switchs default. To do this, you can boot from the files in the working directory while preserving the files in the certified directory. When the files in the working directory are tested and working properly, you may certify them as the switchs default files. The files are then copied into the certified directory to replace the old ones. The path to this directory is /flash/working. Network directoryThis directory holds files that may be required by servers used for authentication. Other files can be put into this directory if desired. The path to this directory is /flash/network.

Available Image Files

The following table is a list of image files available for the OmniSwitch 6850 Series. Most of the files listed here are part of the base switch configuration. Files that support an optional switch feature are noted in the table.
Archive File Name Kadvrout.img Kbase.img K2diag.img Keni.img K2os.img Ksecu.img Krelease.img Boot.cfg Bootrom2.bin Miniboot.backup Miniboot2.default Software.lsm Base or Optional Software Optional Advanced Routing Base Software Base Software Base Software Base Software Optional Security Base Software Base Software Base Software Base Software Base Software Base Software Description Advanced Routing Base Software Diagnostics Ethernet Images Operating System Security (AVLANS) Release Archive Boot file BootROM MiniBoot Default MiniBoot LSM Software

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 605 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Setting the System Clock

The switch clock displays time using a 24-hour clock format. It can also be set for use in any time zone. Daylight Savings Time (DST) is supported for a number of standard time zones. DST parameters can be programmed to support non-standard time zones and time offset applications. All switch files and directories listed in the flash directory bear a time stamp. This feature is useful for file management purposes.

Setting Date and Time

You can set the local date, time zone, and time for your switch or you can also set the switch to run on Universal Time Coordinate (UTC or GMT). If applicable, you can also configure Daylight Savings Time (DST or Summertime) parameters.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 606 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Network Time Protocol (NTP)

The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver. It provides client time accuracies within a millisecond on LANs, and up to a few tens of milliseconds on WANs relative to a primary server synchronized to Universal Coordinated Time (UTC) (via a Global Positioning Service receiver, for example).

NTP Specifications
RFCs supported Maximum number of NTP servers per client 1305Network Time Protocol 3

NTP Defaults
Parameter Description Specifies an NTP server from which this switch will receive updates. Default Value/Comments Version: 4 Minpoll: 6 Prefer: no Key: 0 Disabled Disabled 4000 microseconds

Used to activate client Used to activate NTP client broad-cast mode Used to set the advertised broadcast delay, in microseconds.

NTP Overview
The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver. It provides client time accuracies within a millisecond on LANs, and up to a few tens of milliseconds on WANs relative to a primary server synchronized to Universal Coordinated Time (UTC) (via a Global Positioning Service receiver, for example). Typical NTP configurations utilize multiple redundant servers and diverse network paths in order to achieve high accuracy and reliability. Some configurations include cryptographic authentication to prevent accidental or malicious protocol attacks. It is important for networks to maintain accurate time synchronization between network nodes. The standard timescale used by most nations of the world is based on a combination of UTC (representing the Earths rotation about its axis), and the Gregorian Calendar (representing the Earths rotation about the Sun). The UTC timescale is disciplined with respect to International Atomic Time (TAI) by inserting leap seconds at intervals of about 18 months. UTC time is disseminated by various means, including radio and satellite navigation systems, telephone modems, and portable clocks. Special purpose receivers are available for many time-dissemination services, including the Global Position System (GPS) and other services operated by various national governments. For reasons of cost and convenience, it is not possible to equip every computer with one of these receivers. However, it is possible to equip some computers with these clocks, which then act as primary timeservers to synchronize a much larger number of secondary servers and clients connected by a common network. In order to do this, a distributed network clock synchronization protocol is required which can read a server clock, transmit the reading to one or more clients, and adjust each client clock as required. Protocols that do this include NTP. Note. The Alcatel-Lucent OmniSwitch 6600, 6800, 6850, 7700, 7800, 8800, and 9000 switches can only be NTP clients in an NTP network. They cannot act as NTP servers.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 607 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Stratum
Stratum is the term used to define the relative proximity of a node in a network to a time source (such as a radio clock). Stratum 1 is the server connected to the time source itself. (In most cases the time source and the stratum 1 server are in the same physical location.) An NTP client or server connected to a stratum 1 source would be stratum 2. A client or server connected to a stratum 2 machine would be stratum 3, and so on, as demonstrated in the diagram below.

The farther away from stratum 1 a device is, the more likely there will be discrepancies or errors in the time adjustments done by NTP. A list of stratum 1 and 2 sources available to the public can be found on the Internet. Note. It is not required that NTP be connected to an officially recognized time source (for example, a radio clock). NTP can use any time source to synchronize time in the network.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 608 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using NTP in a Network

NTP operates on the premise that there is one true standard time (defined by UTC), and that if several servers claiming synchronization to the standard time are in disagreement, then one or more of them must be out of synchronization or not functioning correctly. The stratum gradation is used to qualify the accuracy of a time source along with other factors such as advertised precision and the length of the network path between connections. NTP operates with a basic distrust of time information sent from other network entities, and is most effective when multiple NTP time sources are integrated together for checks and crosschecks. To achieve this end, there are several modes of operation that an NTP entity can use when synchronizing time in a network. These modes help predict how the entity behaves when requesting or sending time information, listed below: A switch can be a client of an NTP server (usually of a lower stratum), receiving time information from the server but not passing it on to other switches. A switch can be a client of an NTP server, and in turn be a server to another switch or switches. A switch (regardless of its status as either a client or server) must be peered with another switch. Peering allows NTP entities in the network of the same stratum to regard each other as reliable sources of time and exchange time information. Examples of these are shown in the simple network diagram below:

Servers 1a & 1b receive time information from, or synchronize with, a UTC time source such as a radio clock. (In most cases, these servers would not be connected to the same UTC source, though it is shown this way for simplicity.). Servers 1a and 1b become stratum 1 NTP servers and are peered with each other, allowing them to check UTC time information against each other. These machines support machines 2a and 2b as clients, and these clients are synchronized to the higher stratum Servers 1a & 1b. Clients 2a and 2b are also peered with each other for time checks, and become stratum 2 NTP servers for more clients (3a and 3b, which are also peered). In this hierarchy, the stratum 1 servers synchronize to the most accurate time source available, and then check the time information with peers at the same stratum. The stratum 2 machines synchronize to the stratum 1 servers, but do not send time information to the stratum 1 machines. Machines 2a and 2b in turn provide time information to the stratum 3 machines. It is important to consider the issue of robustness when selecting sources for time synchronization.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 609 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

It is suggested that at least three sources should be available, and at least one should be close to you in terms of network topology. It is also suggested that each NTP client is peered with at least three other same stratum clients, so that time information crosschecking will be performed. Note. Alcatel-Lucents current implementation of NTP only allows the OmniSwitch to act as a passive client, not as a server. A passive client only receives NTP information and adjusts its time accordingly. In the above example, an OmniSwitch could be either Server 3a or 3b. An OmniSwitch as Server 3a or 3b would also not be able to peer with other servers on the same stratum. When planning your network, it is helpful to use the following general rules: It is usually not a good idea to synchronize a local time server with a peer (in other words, a server at the same stratum), unless the latter is receiving time updates from a source that has a lower stratum than from where the former is receiving time updates. This minimizes common points of failure. Peer associations should only be configured between servers at the same stratum level. Higher Strata should configure lower Strata, not the reverse. It is inadvisable to configure time-servers in a domain to a single time source. Doing so invites common points of failure. Note. NTP does not support year date values greater than 2035 (the reasons are documented in RFC 1305 in the data format section). This should not be a problem (until the year 2035) as setting the date this far in advance runs counter to the administrative intention of running NTP.

Authentication
NTP is designed to use MD5 encryption authentication to prevent outside influence upon NTP timestamp information. Using a key file does this. The key file is loaded into the switch memory, and consists of a text file that lists key identifiers that correspond to particular NTP entities. If authentication is enabled on an NTP switch, any NTP message sent to the switch must contain the correct key ID in the message packet to use in decryption. Likewise, any message sent from the authentication-enabled switch will not be readable unless the receiving NTP entity possesses the correct key ID. The key file is a text (.txt) file that contains a list of keys that are used to authenticate NTP servers. It should be located in the /networking directory of the switch. Key files are created by a system administrator independent of the NTP protocol, and then placed in the switch memory when the switch boots. An example of a key file is show below:
2 14 M M RIrop8KPPvQvYotM Sundial # md5 key as an ASCII random string md5 key as an ASCII string

In a key file, the first token is the key number ID, the second is the key format, and the third is the key itself. (The text following a # is not counted as part of the key, and is used merely for description.) The key format indicates an MD5 key written as a 1 to 31 character ASCII string with each character standing for a key octet. The key file (with identical MD5 keys) must be located on both the local NTP client and the clients server.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 610 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Managing Management Directory Content

The Management software runs the OmniSwitch 6850 switches. Each OmniSwitch 6805 stackable configuration can run with two Management units to provide redundancy; one Management unit is designated as the primary Management unit, and the other is designated as the secondary Management. One or the other runs the switch, but never at the same time. The directory structure of the Management software is designed to prevent corrupting or losing switch files. It also allows you to retrieve a previous version of the switch software.

Management Specifications
Size of Flash Memory Size of RAM Memory Maximum Length of File Names Maximum Length of Directory Names Default Boot Directory 64 MB 256 MB 32 Characters 32 Characters Certified

Management Files
Three types of files control the management of a single switch: Image files, which are proprietary code developed by Alcatel-Lucent to run the hardware. These files are not configurable by the user, but may be upgraded from one release to the next. These files are also known as archive files, as they are really the repositories of several smaller files grouped together under a common heading. A configuration file, named boot.cfg, which is an ASCII-based text file that sets and controls the configurable functions inherent in the image files provided with the switch. The user can modify this file. When the switch boots, it looks for the file called boot.cfg. It uses this file to set various switch parameters defined by the image files. A boot file in OmniSwitch 6850, is an ASCII-based text file that controls the console ports baud rate and displays directory loading information and is located in the Flash memory of the switch. Modifications to the switch parameters affect or change the configuration file. The image files are static for the purposes of running the switch (though they can be updated and revised with future releases or enhancements). Image and configuration files are stored in the Flash memory (which is equivalent to a hard drive memory) in specified directories. When the switch is running, it loads the image and configuration files from the Flash memory into the RAM. When changes are made to the configuration file, the changes are first stored in RAM.

Management Software Directory Structure

The directory structure that stores the image and configuration files is divided into two parts: The certified directory contains files that have been certified by an authorized user as the default files for the switch. Should the switch reboot; it would reload the files in the certified directory to reactivate its functionality. The working directory contains files that may or may not be altered from the certified directory. The working directory is a holding place for new files. Files in the working directory must be tested before committing them to the certified directory. You can save configuration changes to the working directory. You can reboot the switch from the working directory using the reload working commands. The running configuration is the current operating parameters of the switch, obtained from information from the image and configuration files. The running configuration is in the RAM memory.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 611 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Where is the Switch Running From?

When a switch has booted and is running, the software used will come either from the certified directory or the working directory. In most instances, the switch boots from the certified directory. (A switch can be specifically booted from the working directory by using the reload working config commands. Once the switch is booted and functioning, the switch is said to be running from a particular directory, either the working or certified directory. Where the switch is running from is determined at the time of the switchs boot-up. At the time of a normal boot (by turning the switch power on or using the reload command), a comparison is made between the working directory and the certified directory. If the directories are completely synchronized (i.e., all files are the same in both directories) the switch will be running from the working directory. If there is any discrepancy between the two directories (even as small as a different file size or file date), the switch will be running from the certified directory. If a switch is running from the certified directory, you will not be able to save any changes made in the running configuration. If the switch reboots, the changes made to switch parameters will be lost. In order to save running configuration changes, the switch must be running from the working directory. You can determine where the switch is running from by using the show running directory commands.

Software Rollback Feature

The directory structure inherent in the Management software allows for a switch to return to a previous, more reliable version of image or configuration files. Initially, when normally booting the switch, the software is loaded from the certified directory. This is the repository for the most reliable software. When the switch is booted, the certified directory is loaded into the running configuration and used to manage switch functionality. Changes made to the configuration file in the running configuration will alter switch functionality. These changes are not saved unless explicitly done so by the user using the copy running-config working command. If the switch reboots before the configuration file in the running configuration is saved, then the certified directory is re-loaded to the running configuration and changes made to the configuration file in the running configuration prior to the reboot are lost. Changes to the configuration file must be initially saved to the working directory using the copy running-config working or the write-memory commands. Once the configuration file is saved to the working directory, the switch can be rebooted from the working directory using the reload working command. Likewise, new image files are always placed in the working directory first. The switch can then be rebooted from the working directory. When this is done, the contents of the working directory are loaded and used to set up the running configuration, which is used to control switch functionality. New image or configuration files can now be tested for a time to decide whether they are reliable. Should the configuration or images files prove to be less reliable than their older counterparts in the certified directory, and then the switch can be rebooted from the certified directory, and rolled back to an earlier version. Once the contents of the working directory are established as good files, then these files can be saved to the certified directory and used as the most reliable software to which the switch can be rolled back to in an emergency situation.

Redundancy
Management software redundancy is one of the switchs most important fail over features. In OmniSwitch 68500 stackable configuration, two fully operational Management units must be present at all times. In addition, the Management software must be synchronized. When two Management units are running in an OmniSwitch 6850 stack, one Management unit has the primary role and the other has the secondary role at any given time. The primary Management unit manages the current switch operations while the secondary Management unit provides backup (also referred to as fail over).

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 612 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Rebooting the Switch

When booting the switch, the software in the certified directory is loaded into the RAM memory of the switch and used as a running configuration, as shown:

The certified directory software should be the best, most reliable versions of both the image files and the boot.cfg file (configuration file). The switch will run from the certified directory after boot if the working and certified directories are not exactly the same. If they are the same, then the switch will run from the working directory, allowing changes made to the running configuration to be saved. If the switch is running from the certified directory, you cannot save any changes to the running configuration, or copy files between the directories. Note: It is possible to cause a reboot of the primary or secondary Management unit at a future time.

Secondary Management unit Fail Over

While rebooting the switch during normal operation, a secondary Management unit is installed; the switches will failover to the secondary Management unit. Fail over means the secondary Management unit takes the place of the primary Management unit. This prevents the switch from ceasing functionality during the boot process. In OmniSwitch 6850 switches, the versions of the software on the primary and secondary Management unit must be synchronized at all times. Synchronizing the Primary and Secondary Management unit: If you have a secondary Management unit in your stack, it will be necessary to synchronize the software between the primary and secondary Management unit. If the primary Management unit goes down (for example, during a reboot), then the switch fails over to the secondary Management unit. If the software in the secondary Management unit is not synchronized with the software in the primary Management unit, the switch will not function as configured by the administrator.

Other Stackable Units Behavior During Takeover

In OmniSwitch 6850 stackable configuration of switches, if there are no unsaved configuration changes and the flash directories on both the primary and secondary management units have been synchronized via the copy flashsynchro command, no other stackable units will be reloaded if a management module takeover occurs. As a result, data flow is not interrupted on the other stackable units during the takeover. If a configuration change is made to one or more stackable units (e.g., a VLAN is configured on several different interfaces), and the changes are not saved via the write memory command, the corresponding stackable unit(s) will automatically reload if a management takeover occurs. Data flow on the affected stackable unit(s) will be interrupted until the reload is complete. Note that the other stackable units will reload whether or not the flash synchronization status shows SYNCHRONIZED. This is because the unsaved changes have occurred in the running configuration (i.e., RAM), and have not been written to the flash directorys configuration file. In this case, a list of only the affected stackable units displays in the table output (e.g., 1 6). If the flash directories on the primary and secondary management are not synchronized (e.g., a copy flash-synchro command has not been issued recently), all other stackable units will be reloaded automatically if a management takeover occurs. Data flow will be interrupted on all stackable units until the reload is complete. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 613 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Copying the Running Configuration to the Working Directory

Once the switch has booted and is running, a user can modify various parameters of switch functionality. These changes are stored temporarily in the running configuration in RAM memory of the switch. In order to save these changes, the running configuration must be saved to the working directory as shown:

In this diagram: 1. The switch boots from the certified directory, and the software is loaded to the RAM memory to create a running configuration. 2. Changes are made in the running configuration and are saved to the working directory. Now the boot.cfg file in the running configuration and the boot.cfg file in the working directory are identical. Should the switch go down or reboot, the configuration changes made can be restored. Note. If the switch is rebooted at this point in the process, since the certified and working directory boot.cfg files are not the same, the switch will boot and run from the certified directory. The modifications made to the functionality of the switch are recorded in the running configuration, in RAM. These changes in RAM memory are only valid until the switch is rebooted. At that time, the switch reboots from the certified directory. If the running configuration is not saved to the working directory before a reboot, then the changes made in the running configuration are lost. To save these changes it is necessary to save the contents of the running configuration to the working directory.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 614 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Rebooting from the Working Directory

Besides a regular boot of the switch (from the certified directory), you can also force the switch to boot from the working directory. This is useful for checking whether a new configuration or image file will boot the switch correctly, before committing it to the certified directory. The following picture illustrates the case of a switch being rebooted from the working directory:

In the above diagram: 1. The certified directory is used to initially boot the switch. 2. Changes are made to the configuration file and are saved to the configuration file in the working directory using the copy running-config working command. 3. The switch is rebooted from the working directory using the reload working command. When a reload working command is entered, the switch prohibits a takeover from the secondary Management Unit. Switch functions will be suspended until the boot process is complete. If you decide against using the new software booted from the working directory, the switch can revert to the software stored in the certified directory by using the copy certified working command, or by using the reload command.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 615 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Copying the Working Directory to the Certified Directory

When the running configuration is saved to the working directory, the switchs working and certified directories are now different. This difference, if the Management Unit reboots, causes the switch to boot and run from the certified directory. When the switch is booted and run from the certified directory, changes made to switch functionality cannot be saved and files cannot be moved between directories. The boot.cfg file saved on the working directory needs to be saved to the certified directory, as shown:

In this diagram: 1. The switch boots from the certified directory and changes are made to the running configuration. 2. The changes are saved to the working directory as the boot.cfg file. 3. The contents of the working directory are saved to the certified directory. Once the working directory is copied to the certified directory, and the switch reboots, it will reboot from the certified directory but run from the working directory. When the switch runs in this fashion, changes made to the running configuration can be saved to the working directory. Note. Only software that has been thoroughly validated, as viable and reliant software should be copied to the certified directory. Once you copy software to the certified directory, you will not be able to recover a previous version of the image or configuration files. When the software on the working directory of a switch has proven to be effective and reliable, eventually the contents of the working directory should be copied into the certified directory. Note: It is also possible to copy the contents of the certified directory to the working directory.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 616 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using the CLI

Alcatel-Lucents Command line interface (CLI) is a text-based configuration interface that allows you to configure switch applications and to view switch statistics. Each CLI command applicable to the switch is defined in the OmniSwitch CLI Reference Guide. All command descriptions listed in the Reference Guide include command syntax definitions, defaults, usage guidelines, and example screen output and release history.

CLI Specifications
Configuration Methods Command Capture Feature User Service Features Online configuration via real-time sessions using CLI commands. Offline configuration using text file holding CLI commands. Snapshot feature captures switch configurations in a text file. Command Line Editing Command Prefix Recognition CLI Prompt Option Command Help Keyword Completion Command History (up to 30 commands) Command Logging (up to 100 commands; detailed information) Syntax Error Display Alias Command Option More Command

CLI Overview
The CLI uses single-line text commands that are similar to other industry standard switch interfaces. However, the Alcatel-Lucent CLI is different from industry standard interfaces in that the Alcatel-Lucent uses a single level command hierarchy. Unlike other switch interfaces, the Alcatel-Lucent CLI has no concept of command modes. Other CLIs require you to step your way down a tree-type hierarchy to access commands. Once you enter a command mode, you must step your way back to the top of the hierarchy before you can enter a command in a different mode. The Alcatel-Lucent switch will answer any CLI command at any time because there is no hierarchy.

Online Configuration
To configure parameters and view statistics you must connect the switch to a terminal, such as a PC or UNIX workstation, using terminal emulation software. This connection can be made directly to the switchs serial port, through a modem, or over a network via Telnet. Once you are logged in to the switch, you may configure the switch directly using CLI commands. Commands executed in this manner normally take effect immediately. The majority of CLI commands are independent, single-line commands and therefore can be entered in any order. However, some functions may require you to configure specific network information before other commands can be entered. For example, before you can assign a port to a VLAN, you must first create the VLAN.

Offline Configuration Using Configuration Files

CLI configuration commands can be typed into a generic text file. When the text file is placed in the switch /flash/working directory, its commands are applied to the switch when the configuration apply command is issued. Files used in this manner are called configuration files. A configuration file can be viewed or edited offline using a standard text editor. It can then be uploaded and applied to additional switches in the network. This allows you to easily clone switch configurations. This ability to store comprehensive network information in a single text file facilitates troubleshooting, testing, and overall network reliability.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 617 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Command Entry Rules and Syntax

When you start a session on the switch, you can execute CLI commands as soon as you are logged in. The following rules apply: Enter only one command per line. No command may be extended across multiple lines. Passwords are case sensitive. Commands are not case sensitive. The switch accepts commands entered in upper case, lower case or a combination of both. Press Enter to complete each command line entry. To use spaces within a user-defined text string, you must enclose the entry in quotation marks ( ). If you receive a syntax error (i.e., ERROR: Invalid entry:), double-check your command as written and re-enter it exactly as described in the OmniSwitch CLI Reference Guide. Be sure to include all syntax option parameters. To exit the CLI, type exit and press Enter.

Text Conventions
The following table contains text conventions and usage guidelines for CLI commands.
bold text (Quotation Marks) Indicates basic command and keyword syntax. Example: show snmp station Used to enclose text strings that contain spaces Example: vlan 2 name new test vlan

Using Show Commands

The CLI contains show commands that allow you to view configuration and switch status on your console screen. The show syntax is used with other command keywords to display information pertaining to those keywords. For example, the show vlan command displays a table of all VLANs currently configured, along with pertinent information about each VLAN. Different forms of the show vlan command can be used to display different subsets of VLAN information. For example the show vlan rules command displays all rules defined for a VLAN.

Using the No Form

The OmniSwitch CLI Reference Guide defines all CLI commands and explains their syntax. Whenever a command has a no form, it is described on the same page as the original command. The no form of a command will mean one of the following: It can remove the configuration created by a command. For example, you create a VLAN with the vlan command, and you delete a VLAN with the no vlan command. It can reset a configuration value to its default. For example, you configure the time interval that the switch will use to remove a multicast stream from a port with the ip multicast leave-timeout command. You set the interval back to its default value with the ip multicast no leave-timeout command.

Using Alias Commands

You may define substitute text for the switchs CLI commands by using the alias command. There are two main reasons for defining aliases. You can eliminate excess typing by reducing the number of characters required for a command. You can change unfamiliar command words into familiar words or patterns. After an alias has been defined, both the alias and the original CLI term will be supported as valid CLI terms. To display aliases, use the show alias command. To set all alias values back to their factory defaults, use the user profile reset command.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 618 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Partial Keyword Completion

The CLI has a partial keyword recognition feature that allows the switch to recognize partial keywords to CLI command syntax. Instead of typing the entire keyword, you may type only as many characters as is necessary to uniquely identify the keyword, then press the Tab key. The CLI will complete the keyword and place the cursor at the end of the keyword. When you press Tab to complete a command keyword, one of four things can happen: You enter enough characters (prior to Tab) to uniquely identify the command keyword. In this case, pressing Tab will cause the CLI to complete the keyword and place a space followed by the cursor at the end of the completed keyword. You do not enter enough characters (prior to Tab) to uniquely identify the command keyword. In this case pressing Tab will have no effect. You enter characters that do not belong to a keyword that can be used in this instance. In this case, pressing Tab will remove the characters and place the cursor back to its previous position. You enter enough characters (prior to Tab) to uniquely identify a group of keywords such that all keywords in the group share a common prefix. In this case, pressing Tab will cause the CLI to complete the common prefix and place the cursor at the end of the prefix. Note that in this case, no space is placed at the end of the keyword Note. The keyword completion feature will accept wildcards.

Command Help
The CLI has an internal help feature you can invoke by using the question mark (?) character as a command. The CLI help feature provides progressive information on how to build your command syntax, one keyword at a time. If you do not know the first keyword of the command you need, you can use a question mark character at the CLI system prompt. The CLI responds by listing command keywords divided into command sets. You can find the first keyword for the command you need by referring to the list on your screen. The following is a partial display: ->? WHOAMI WHO VIEW VI USER TTY TELNET SYSTEM SWLOG SSH SHOW SFTP SESSION RZ RMDIR RM RENAME PWD PROMPT NTP NSLOOKUP NO NEWFS MV MOVE MORE MODIFY MKDIR LS KILL IP INSTALL HISTORY FTP FSCK FREESPACE EXIT DSHELL DIR DELETE DEBUG CP COMMAND-LOG CHMOD CD ATTRIB ALIAS (System Service & File Mgmt Command Set) (Additional output not shown) Note that the command keywords are shown in all capital letters. The name of the command set is listed parenthetically below the keywords in initial caps. The following table contains the first-level commands and their set names as they are listed on the display screen when you enter a single question mark and press Enter.
Command Set Name System Service & File Management Commands WHOAMI, WHO, VIEW, VI, VERBOSE, USER, UPDATE, TTY, TELNET, SYSTEM, SWLOG, SSH, SHOW, SFTP, SESSION, RZ, RMDIR, RM, RENAME, PWD, PROMPT, NTP, NSLOOKUP, NO, NEWFS, MV, MOVE, MORE, MODIFY, MKDIR, LS, KILL, IP, INSTALL, HISTORY, FTP, FSCK, FREESPACE, EXIT, DSHELL, DIR, DELETE, DEBUG, CP, COMMAND-LOG, CHMOD, CD, AUTO, ATTRIB, AL COPY, WRITE, POWER, TEMP-THRESHOLD, TAKEOVER, SYSTEM, SHOW, RRM, RPUT, RLS, RGET, RELOAD, RDF, RCP, NO, DEBUG, CONFIGURE SOURCE-LEARNING, SHOW, PORT-SECURITY, NO, MACADDRESS-TABLE, DEBUG SHOW, BRIDGE VLAN, SHOW, NO, MAC-ADDRESS-TABLE, DEBUG STATIC, SHOW, NO, LINKAGG, LACP HTTP, TRACEROUTE, SNMP, SHOW, RMON, PORT, POLICY, PING, NO, MACRANGE, MAC, LANPOWER, IP, IPV6, ICMP, HTTPS, HRE, HEALTH, GMAP, DEBUG, CLEAR, ARP, AMAP, 802.1X USER, SHOW, PASSWORD, NO, END-USER, DEBUG, CONFIGURATION, AVLAN, AAA TRAP, SHOW, NO, INTERFACES, FLOW, DEBUG, 10GIG DEBUG, VRRP3, VRRP, TRACEROUTE6, SHOW, PING6, NO, IPV6, IP, CLEAR SHOW, QOS, POLICY, NO, DEBUG UPDATE, SHOW, NO, DEBUG

Chassis Supervision Source Learning Spanning Tree VLAN Link Aggregation Miscellaneous

AAA & Configuration Manager Interface IP Routing & Multicast QoS Debug

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 619 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

CLI Services
There are several services built into the CLI that help you use the interface. The Command Line Editing service makes it easy for you to enter and edit repetitive commands. Other CLI services, such as syntax checking, command help, prefix prompt, and history assist you in selecting and using the correct command syntax for the task you are performing.

Command Line Editing

CLI commands are entered from your keyboard and are executed when you press Enter. The CLI also has several editing features that make it easier for you to enter the correct commands, either by allowing you to correct entry mistakes or by helping you enter the correct command.

Syntax Checking
If you make a mistake while entering command syntax, the CLI gives you clues about how to correct your error. Whenever you enter an invalid command, two indicators are displayed. The Error message tells you what the error is. The caret (^) character tells you where the error is in your syntax.

Prefix Recognition
Prefix Recognition is a CLI feature that reduces redundant command line entry by storing prefix information for certain network commands. When you configure network services, you may have to enter the same command prefix multiple times. Entering the same prefix again and again can be cumbersome and prone to error. The prefix recognition feature addresses the problem of redundant command entry by allowing the CLI to store commonly used prefix information. This prefix information stored by the switch then becomes part of the next CLI command entered. The following command families support the prefix recognition feature. AAA Interface Link Aggregation QOS Spanning Tree VLAN Management When certain commands are entered from one of these families, the CLI will retain the prefix information in a memory buffer. Then, if a valid related command is entered next, the CLI will assume the stored prefix is part of the next command. In this case, you are only required to enter the suffix information for the next command.

Command History
The history command allows you to view commands you have recently issued to the switch. The switch has a history buffer that stores up to 30 of the most recently executed commands. Note. The command history feature differs from the command-logging feature in that command logging stores up to 100 of the most recent commands to a separate command.log file. Also, the command-logging feature includes additional information, such as full command syntax, login user name, entry date and time, session IP address, and entry results.

Logging CLI Commands and Entry Results

OmniSwitch 6850 switches provide command logging via the command-log command. This feature allows users to record up to 100 of the most recent commands entered via Telnet, Secure Shell, and console sessions. In addition to a list of commands entered, the results of each command entry are recorded. Results include information such as whether a command was executed successfully, or whether a syntax or configuration error occurred. Note. The command history feature differs from the command-logging feature in that command history buffers up to 30 of the most recent commands. The command information is not written to a separate log file. Also, the command history feature includes only general keyword syntax (i.e., it does not record full syntax, date and time, session IP address, and entry results). OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 620 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Customizing the Screen Display

The CLI has several commands that allow you to customize the way switch information is displayed to your screen. You can make the screen display smaller or larger. You can also adjust the size of the table displays and the number of lines shown on the screen.

Changing the CLI Prompt

You can change the system prompt that displays on the screen when you are logged into the switch. The default prompt consists of a dash, greater-than (->) text string.

Multiple User Sessions

Several CLI commands give you information about user sessions that are currently operating on the OmniSwitch, including your own session. These commands allow you to list the number and types of sessions that are currently running on the switch. You can also terminate another session, provided you have administrative privileges.

Working With Configuration Files

Commands and settings needed for the OmniSwitch 6850 can be contained in an ASCII-based configuration text file. Configuration files can be created in several ways and are useful in network environments where multiple switches must be managed and monitored.

Configuration File Specifications

Creation Methods for Configuration Files Timer Functions Command Capture Feature Error Reporting Text Editing on the Switch Create a text file on a word processor and upload it to the switch. Invoke the switchs snapshot feature to create a text file. Create a text file using one of the switchs text editors. Files can be applied immediately or by setting a timer on the switch. Snapshot feature captures switch configurations in a text file. Snapshot feature includes error reporting in the text file. Vi standard UNIX editor. The Ed standard UNIX editor is available in the debug mode.

Configuration Files Overview

Instead of using CLI commands entered at a workstation, you can configure the switch using an ASCII-based text file. You may type CLI commands directly into a text document to create a configuration file that will reside in your switchs /flash directory. Configuration files are created in the following ways: You may create, edit and view a file using a standard text editor (such as MS WordPad or Notepad) on a workstation. The file can then be uploaded to the switchs /flash file directory. You can invoke the switchs CLI configuration snapshot command to capture the switchs current configuration into a text file. This causes a configuration file to be created in the switchs /flash directory. You can use the switchs text editor to create or edit a configuration file located in the switchs /flash file directory.

Applying Configuration Files to the Switch

Once you have a configuration file located in the switchs file system you must load the file into running memory to make it run on the switch. You do this by using configuration apply command. You may apply configuration files to the switch immediately, or you can specify a timer session. In a timer session, you schedule a file to be applied in the future at a specific date and time or after a specific period of time has passed (like a countdown). Timer sessions are very useful for certain management tasks, especially synchronized batch updates.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 621 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Managing Switch User Accounts

Switch user accounts may be set up locally on the switch for users to log into and manage the switch. The accounts specify login information (combinations of usernames and passwords) and privilege or profile information depending on the type of user. The switch has several interfaces (console, Telnet, HTTP, FTP, Secure Shell, and SNMP) through which users may access the switch. The switch may be set up to allow or deny access through any of these interfaces. User information may also be configured on external servers in addition to, or instead of, user accounts configured locally on the switch (except end-user profiles, which may only be configured on the switch).

User Database Specifications

Maximum number of alphanumeric characters in a username Maximum number of alphanumeric characters in a user password Maximum number of alphanumeric characters in an end-user profile name Maximum number of user accounts Maximum number of end-user profiles 31 47 32 64 128

User Accounts Defaults

Two user accounts are available on the switch by default: admin and default. New users inherit the privileges of the default user if specific privileges for the user are not configured; the default user is modifiable. Password defaults are as follows:
Parameter Description Minimum password length Default password expiration for any user Password expiration for particular user Default 8 characters Disabled None

Overview of User Accounts

A user account includes a login name, password, and user privileges. The account also includes privilege or profile information, depending on the type of user account. There are two types of accounts: network administrator accounts, and end-user or customer login accounts. Network administrator accounts are configured with user (sometimes called functional) privileges. These privileges determine whether the user has read or write access to the switch and which command domains and command families the user is authorized to execute on the switch. Customer login accounts are configured with end-user profiles rather than functional privileges. Profiles are configured separately and then attached to the user account. A profile specifies command areas to which a user has access as well as VLAN and/or port ranges to which the user has access. The designation of particular command families/domains or command families for user access is sometimes referred to as partitioned management. The privileges and profiles are sometimes referred to as authorization. Note. End-user command areas are different from the command domains/families used for network administrator accounts. In general, command areas are much more restricted groups of commands. Functional privileges (network administration) and end-user profiles (customer login) are mutually exclusive. Both types of users may exist on the switch, but any given user account can only be one type, network administrator or customer login. The CLI in the switch prevents you from configuring both privileges and a profile for the same user. End-user profiles also cannot be configured on an authentication server; however, users configured on an external authentication server may have profile attributes, which the switch will attempt to match to profiles configured locally. Note that if user information is configured on an external server (rather than locally on the switch through the CLI) with both functional privilege attributes and profile attributes, the user is seen by the switch as an end-user and will attempt to match the profile name to a profile name configured on the switch. If there is no match, the user will not be able to log into the switch.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 622 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Users typically log into the switch through one of the following methods: Console portA direct connection to the switch through the console port. TelnetAny standard Telnet client may be used for logging into the switch. FTPAny standard FTP client may be used for logging into the switch. HTTPThe switch has a Web browser management interface for users logging in via HTTP. This management tool is called WebView. Secure ShellAny standard Secure Shell client may be used for logging into the switch. SNMPAny standard SNMP browser may be used for logging into the switch.

Startup Defaults
By default, a single user management account is available at the first boot up of the switch. This account has the following user name and password: User nameadmin Passwordswitch Initially, the admin user can only be authorized on the switch through the console port. Management access through any other interface is disabled. The Authenticated Switch Access commands may be used to enable access through other interfaces/services (Telnet, HTTP, etc.); however, SNMP access is not allowed for the admin user. Also, the admin user cannot be modified, except for the password. Password expiration for the admin user is disabled by default. In addition, another account, default, is available on the switch for default settings only; this account cannot be used to log into the switch. It is used to store and modify default settings for new users. Note. Up to 64 users may be configured in the local switch database. To set up a user account, use the user command, which specifies the following: PasswordThe password is required for new users or when modifying a users SNMP access. The password will not appear in an ASCII configuration file created via the snapshot command. PrivilegesThe users read and write access to command domains and families. SNMP accessWhether or not the user is permitted to manage the switch via SNMP. End-User ProfileThe users read and write access to command areas, port ranges, and VLAN ranges; used for customer login accounts. Typically, options for the user (privileges or end-user profile; SNMP access) are configured at the same time the user is created.

Default User Settings

The default user account on the switch is used for storing new user defaults for privileges and profile information. This account does not include a password and cannot be used to log into the switch. At the first switch startup, the default user account is configured for: No read or write access No SNMP access No end-user profile Any new users created on the switch will inherit the privileges or the end-user profile of the default user unless the user is configured with specific privileges or a profile. The default user settings may be modified. Note that the default user may only store default functional privileges or a default end-user profile. The default user cannot be configured with both privileges and a profile. The privilege default is particularly important for users who are authenticated via an ACE/Server, which only supplies username and password information; or for users who are authenticated via a RADIUS or LDAP server on which privileges are not configured.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 623 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

SNMP Access for a User Account

By default, users can access the switch based on the SNMP setting specified for the default user account. The user command, however, may be used to configure SNMP access for a particular user. SNMP access may be configured without authentication and encryption required (supported by SNMPv1, SNMPv2, or SNMPv3). Or it may be configured with authentication or authentication/encryption required (SNMPv3 only). SNMP authentication specifies the algorithm that should be used for computing the SNMP authentication key. It may also specify DES encryption. The following options may be configured for a users SNMP access with authentication or authentication/encryption: SHAThe SHA authentication algorithm is used for authenticating SNMP PDU for the user. MD5The MD5 authentication algorithm is used for authenticating SNMP PDU for the user. SHA and DESThe SHA authentication algorithm and DES encryption standard is used for authenticating and encrypting SNMP PDU for the user. MD5 and DESThe MD5 authentication algorithm and the DES encryption standard is used for authenticating and encrypting SNMP PDU for the user. The users level of SNMP authentication is superseded by the SNMP version allowed globally on the switch. By default, the switch allows all SNMP requests. Note. At least one user with SHA/MD5 authentication and/or DES encryption must be configured on the switch for SNMPv3 communication with OmniVista. The community string carried in the SNMP PDU identifies the request as an SNMPv1 or SNMPv2 request. The way the community string is handled on the switch is determined by the setting of the snmp community map mode command. If the community map mode is enabled, the community string is checked against the community strings database (populated by the snmp community map command). If the community map mode is disabled, then the community string value is checked against the user database. In either case, if the check fails, the request is dropped.

End-User Profiles
End-user profiles are designed for user accounts in the carrier market. With end-user profiles, a network administrator can configure customer login accounts that restrict users to particular command areas over particular ports and/or VLANs. End-user profiles are only managed and stored on the switch; profiles are not stored on external servers. Note. End-user profiles cannot be used in conjunction with user-partitioned management; the features are mutually exclusive.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 624 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Managing Switch Security

Switch security is provided on the switch for all available management interfaces (console, Telnet, HTTP, FTP, Secure Shell, and SNMP). The switch may be set up to allow or deny access through any of these interfaces. (Note that users attempting to access the switch must have a valid username and password.) A user login procedure requires that users be authenticated for switch access via an external authentication server or the local user database.

Switch Security Specifications

Telnet sessions allowed FTP sessions allowed HTTP (Web browser) sessions allowed Secure Shell session (including SFTP) allowed Total sessions (Telnet, FTP, HTTP, console) SNMP sessions allowed 4 concurrent sessions 4 concurrent sessions 4 concurrent sessions 8 concurrent sessions 13 concurrent sessions 50 concurrent sessions

Switch Security Defaults

Access to managing the switch is always available for the admin user through the console port, even if management access to the console port is disabled for other users.

Switch Security Overview

Switch security features increase the security of the basic switch login process by allowing management only through particular interfaces for users with particular privileges. Login information and privileges may be stored on the switch and/or an external server, depending on the type of external server you are using and how you configure switch access. The illustration here shows the components of switch security:

An external RADIUS or LDAP server can supply both user login and authorization information. ACE/Server can provide login information; user authorization information is available through the switchs local user database. External servers may also be used for accounting, which includes logging statistics about user sessions. If an external server is not available or is not configured, user login information and user authorization may be provided through the local user database on the switch. Logging may also be accomplished directly on the switch.

Authenticated Switch Access

Authenticated Switch Access (ASA) is a way of authenticating users who want to manage the switch. With authenticated access, all switch login attempts using the console or modem port, Telnet, FTP, SNMP, or HTTP require authentication via the local user database or via a third-party server. The type of server may be an authentication-only mechanism or an authentication, authorization, and accounting (AAA) mechanism. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 625 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

AAA ServersRADIUS or LDAP

AAA servers are able to provide authorization for switch management users as well as authentication (they also may be used for accounting). The AAA servers supported on the switch are Remote Authentication Dial-In User Service (RADIUS) or Lightweight Directory Access Protocol (LDAP) servers. User login information and user privileges may be stored on the servers. Privileges are used for network administrator accounts. Instead of user privileges an end-user profile may be associated with a user for customer login accounts. User information configured on an external server may include a profile name attribute. The switch will attempt to match the profile name to a profile stored locally on the switch. The following illustration shows the two different user types attempting to authenticate with a AAA server:

Authentication-onlyACE/Server
Authentication-only servers are able to authenticate users for switch management access, but authorization (or what privileges the user has after authenticating) are determined by the switch. Authentication-only servers cannot return user privileges or end-user profiles to the switch. The authentication-only server supported by the switch is ACE/Server, which is a part of RSA Securitys SecurID product suite. RSA Securitys ACE/Agent is embedded in the switch. The following illustration shows the two different user types attempting to authenticate with an ACE/Server:

Note. A RADIUS server supporting the challenge and response mechanism as defined in RADIUS RFC 2865 may access an ACE/Server for authentication purposes. The ACE/Server is then used for user authentication, and the RADIUS server is used for user authorization.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 626 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Interaction With the User Database

By default, switch management users may be authenticated through the console port via the local user database. If external servers are configured for other management interfaces (such as Telnet, or HTTP) but the servers become unavailable, the switch will poll the local user database for login information. Access to the console port provides secure fail-over in case of misconfiguration or if external authentication servers become unavailable. The admin user is always authorized through the console port via the local database (provided the correct password is supplied), even if access to the console port is disabled. The database includes information about whether or not a user is able to log into the switch and which kinds of privileges or rights the user has for managing the switch. The admin user or any user may set up the database with write privileges to the AAA commands.

ASA and Authenticated VLANs

Layer 2 Authentication uses Authenticated VLANs to authenticate users through the switch out to a subnet. Authenticated Switch Access authenticates users into the switch to manage it. The features are independent of each other; however, user databases for each feature may be located on the same authentication server.

Configuring Authenticated Switch Access

Setting up Authenticated Switch Access involves the following general steps: 1. Set Up the Authentication Servers. 2. Set Up the Local User Database. Set up user information on the switch if user login or privilege information will be pulled from the switch. 3. Set Up the Management Interfaces. 4. Set Up Accounting. This step is optional. Additional configuration is required in order to set up the switch to communicate with external authentication servers. If you are using the local switch database to authenticate users, user accounts must be set up on the switch. Note that by default: Authenticated switch access is available only through the console port. Users are authenticated through the console port via the local user database on the switch. These defaults provide out-of-the-box security at initial startup. Other management interfaces (Telnet, HTTP, etc.) must be specifically enabled before they can access the switch. By default, authenticated access is available through the console port. Access through other management interfaces is disabled. Other management interfaces include Telnet, FTP, HTTP, Secure Shell, and SNMP. Note. RADIUS or LDAP servers used for authenticated switch access may also be used with authenticated VLANs. The order of the specified servers is important. The switch uses only one server for authenticationthe first available server in the list. All authentication attempts will be tried on that server. Other servers are not tried, even if they are available. If local is specified, it must be last in the list since the local user database is always available when the switch is up. Servers may also be used for accounting, or logging, of authenticated sessions. The following table describes the management access interfaces or methods and the types of authentication servers that may be used with them:
Server Type RADIUS LDAP ACE/Server Local Management Access Method Telnet, FTP, HTTP, Secure Shell Telnet, FTP, HTTP, Secure Shell, SNMP Telnet, FTP, HTTP, Secure Shell Console, FTP, HTTP, Secure Shell, SNMP

Accounting for ASA

Accounting servers track network resources such as time, packets, bytes, etc., and user activity (when a user logs in and out, how many login attempts were made, session length, etc.). The accounting servers may be located anywhere in the network. Up to 4 servers may be configured The servers may be different types ACE cannot be used as an accounting server The keyword local must be specified if you want accounting to be performed via the Switch Logging feature in the switch. If local is specified, it must be the last server in the list. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 627 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Using WebView
The switch can be monitored and configured using WebView, Alcatel-Lucents web-based device management tool. The WebView application is embedded in the switch and is accessible via the following web browsers: Internet Explorer 6.0 and later for Windows NT, 2000, XP, 2003 Firefox 2.0 for Windows and Solaris SunOS 5.10 Windows Vista

WebView CLI Defaults

Web Management Command Line Interface (CLI) commands allow you to enable/disable WebView, enable/disable Secure Socket Layer (SSL), and view basic WebView parameters. These configuration options are also available in WebView. The following table lists the defaults for WebView configuration through the http and https commands. Description Default WebView Status Enabled Force SSL Disabled HTTPS port 443 HTTP port 80

WebView Overview
The following section provides an overview of WebView page layouts.

WebView Page Layout

As shown below, each WebView page is divided into four areas: Banner is used to access global options (e.g., global help, telnet, log out). An icon is also displayed in this area to indicate the current directory (Certified or Working).

Toolbar is used to access WebView features. Feature Options is used to access specific configuration options for each feature (displayed in drop-down menus at the top of the page). View/Configuration Area is used to view/configure a feature.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 628 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Banner
The following features are available in the WebView Banner: OptionsBrings up the User Options Page, which is used to change the user login password. Save ConfigBrings up the Save Configuration Screen. Click Apply to save the switchs running configuration for the next startup. HelpBrings up general WebView Help. Specific help pages are also available on each configuration page. WebView Help: A general help page for using WebView is available from the banner at the top of the page. In addition, on-line help is available on every WebView page. Each help page provides a description of the page and specific instructions for each configurable field. AboutProvides basic WebView product information TelnetBrings up a Telnet session window, through which you can access the switch for CLI configuration. Log OutLogs the user out of the switch and ends the user session. After logout, the login screen appears. The user can log back into the switch or just close the login screen.

Toolbar
Switch configuration is divided into configuration groups in the toolbar (for example, Physical, Layer 2, etc.). Under each configuration group are switch features, identified by a name and an icon.

Feature Options
Feature configuration options are displayed as drop-down menus at the top of each feature page.

View/Configuration Area
The View/Configuration area is where switch configuration information is displayed and where configuration pages appear. After logging into WebView, a real-time graphical representation of the switch displays all of the switchs current components. The feature configuration options on this page are used to configure the switch.

WebView Help
A general help page for using WebView is available from the banner at the top of the page. In addition, on-line help is available on every WebView page. Each help page provides a description of the page and specific instructions for each configurable field.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 629 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using SNMP
The Simple Network Management Protocol (SNMP) is an application-layer protocol that allows communication between SNMP managers and SNMP agents on an IP network. Network administrators use SNMP to monitor network performance and to manage network resources.

SNMP Specifications
RFCs Supported for SNMPv2 RFCs Supported for SNMPv3 1902 through 1907 - SNMPv2c Management Framework 1908 - Coexistence and transitions relating to SNMPv1 and SNMPv2c 2570 Version 3 of the Internet Standard Network Management Framework 2571 Architecture for Describing SNMP Management Frameworks 2572 Message Processing and Dispatching for SNMP 2573 SNMPv3 Applications 2574 User-based Security Model (USM) for version 3 SNMP 2575 View-based Access Control Model (VACM) for SNMP 2576 Coexistence between SNMP versions The SNMPv3 protocol is ascending compatible with SNMPv1 and v2 and supports all the SNMPv1 and SNMPv2 PDUs Community Strings None Sets and Gets SHA, MD5 DES Non-authenticated Sets, Non-authenticated Gets and Get-Nexts, Authenticated Sets, Authenticated Gets and Get-Nexts, Encrypted Sets, Encrypted Gets and Get-Nexts For a list and description of traps, refer to the SNMP Traps Table in Appendix #1. For a list and description of system MIBs, refer to Industry Standard MIBs and Enterprise (Proprietary) MIBs in Appendix #2.

SNMPv1, SNMPv2, SNMPv3 SNMPv1 and SNMPv2 Authentication SNMPv1, SNMPv2 Encryption SNMPv1 and SNMPv2 Security requests accepted by the switch SNMPv3 Authentication SNMPv3 Encryption SNMPv3 Security requests accepted by the switch SNMP traps SNMP MIBs

SNMP Defaults
Parameter Description SNMP Management Station Community Strings SNMP Security setting Trap filtering Trap Absorption Enables the forwarding of traps to WebView Enables or disables SNMP authentication failure trap forwarding Default Value/Comments UDP port 162, SNMPv3, Enabled Enabled Privacy all (highest) security Disabled Enabled Enabled Disabled

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 630 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

SNMP Overview
SNMP provides an industry standard communications model used by network administrators to manage and monitor their network devices. The SNMP model defines two components: the SNMP Manager and the SNMP Agent.

The SNMP Manager resides on a workstation hosting the management application. It can query agents using SNMP operations. An SNMP manager is commonly called a Network Management System (NMS). NMS refers to a system made up of a network device (such as a workstation) and the NMS software. It provides an interface that allows users to request data or see alarms resulting from traps or informs. It can also store data that can be used for network analysis. The SNMP Agent is the software entity that resides within the switch on the network. It maintains the management data about a particular network device and reports these data, as needed, to the managing systems. The agent also responds to requests for data from the SNMP Manager. Along with the SNMP agent, the switch also contains Management Information Bases (MIBs). MIBs are databases of managed objects, written in the SNMP module language that can be monitored by the NMS. The SNMP agent contains MIB variables, which have values the NMS can request or change using Get, GetNext, GetBulk, or Set operations. The agent can also send unsolicited messages (traps or informs) to the NMS to notify the manager of network conditions.

SNMP Operations
Devices on the network are managed through transactions between the NMS and the SNMP agent residing on the network device (i.e., switch). SNMP provides two kinds of management transactions: manager-request/agent-response and unsolicited notifications (traps or informs) from the agent to the manager. In a manager-request/agent-response transaction, the SNMP manager sends a request packet, referred to as a Protocol Data Unit (PDU), to the SNMP agent in the switch. The SNMP agent complies with the request and sends a response PDU to the manager. The types of management requests are Get, GetNext, and GetBulk requests. These transactions are used to request information from the switch (Get, GetNext, or GetBulk) or to change the value of an object instance on the switch (Set). In an unsolicited notification, the SNMP agent in the switch sends a trap PDU to the SNMP manager to inform it that an event has occurred. The SNMP manager normally does not send confirmation to the agent acknowledging receipt of a trap.

Using SNMP for Switch Management

The Alcatel-Lucent switch can be configured using the Command Line Interface (CLI), SNMP or the WebView device management tool. When configuring the switch using SNMP, an NMS application (such as Alcatel-Lucents OmniVista) is used. Although MIB browsers vary depending on which software package is used, they all have a few things in common. The browser must compile the Alcatel-Lucent switch MIBs before it can be used to manage the switch by issuing requests and reading statistics. Each MIB must be checked for dependencies and the MIBs must be compiled in the proper order. Once the browser is properly installed and the MIBs are compiled, the browser software can be used to manage the switch. The MIB browser you use depends on the design and management requirements of your network. Detailed information on working with MIB browsers is beyond the scope of this document. However, you must know the configuration requirements of your MIB browser or other NMS installation before you can define the system to the switch as an SNMP station. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 631 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Setting Up an SNMP Management Station

An SNMP management station is a workstation configured to receive SNMP traps from the switch. You must identify this station to the switch by using the snmp station CLI command. The following information is needed to define an SNMP management station. The IP address of the SNMP management station device The UDP destination port number on the management station. This identifies the port to which the switch will send traps. The SNMP version used by the switch to send traps. A user account name that the management station will recognize

SNMP Versions
The SNMP agent in the switch can communicate with multiple managers. You can configure the switch to communicate with different management stations using different versions of SNMP. The switch supports three versions of SNMPv1&v2&v3.

SNMPv1
SNMPv1 is the original implementation of the SNMP protocol and network management model. It is characterized by the Get, Set, GetNext, and Trap protocol operations. SNMPv1 uses a rudimentary security system where each PDU contains information called a community string. The community string acts like a combination username and password. When you configure a device for SNMP management you normally specify one community string that provides read-write access to objects within the device and another community string that limits access to read-only. If the community string in a data unit matches one of these strings, the request is granted. If not, the request is denied. The community string security standard offers minimal security and is generally insufficient for networks where need for security is high. Although SNMPv1 lacks bulk message retrieval capabilities and security features, it is widely used and is a de facto standard in the Internet environment.

SNMPv2
SNMPv2 is a later version of the SNMP protocol. It uses the same Get, Set, GetNext, and Trap operations as SNMPv1 and supports the same community-based security standard. SNMPv1 is incompatible with SNMPv2 in certain applications due to the following enhancements. Management Information Structure SNMPv2 includes new macros for defining object groups, traps compliance characteristics, and capability characteristics. Protocol Operations SNMPv2 has two new PDUs not supported by SNMPv1. The GetBulkRequest PDU enables the manager to retrieve large blocks of data efficiently. In particular, it is well suited to retrieving multiple rows in a table. The InformRequest PDU enables one manager to send trap information to another manager.

SNMPv3
SNMPv3 supports the View-Based Access Control Model (VACM) and User-Based Security Model (USM) security models along with these added security features: Message integrityEnsuring that a packet has not been tampered with in transit Time Frame ProtectionLimiting requests to specified time frames. The user can specify a time frame so that any PDU bearing an out of date timestamp will be ignored. EncryptionScrambling the contents of a packet to prevent it from being learned by an unauthorized source AuthenticationDetermining that the message is from a valid source holding the correct privileges.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 632 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Using SNMP For Switch Security

Community Strings (SNMPv1 and SNMPv2)
The switch supports the SNMPv1 and SNMPv2c community strings security standard. When a community string is carried over an incoming SNMP request, that community string must match up with a user account name as listed in the community string database on the switch. Otherwise, the SNMP agent in the switch will not process the SNMP request. Note. A community string inherits the security privileges of the user account that creates it.

Encryption and Authentication (SNMPv3)

Two important processes are used to verify that the message contents have not been altered and that the source of the message is authentic. These processes are encryption and authentication. A typical data encryption process requires an encryption algorithm on both ends of the transmission and a secret key (like a code or a password). The sending device encrypts or scrambles the message by running it through an encryption algorithm along with the key. The message is then transmitted over the network in its encrypted state. The receiving device then takes the transmitted message and un-scrambles it by running it through a decryption algorithm. The receiving device cannot un-scramble the coded message without the key. The switch uses the Data Encryption Standard (DES) encryption scheme in its SNMPv3 implementation. For DES, the data are encrypted in 64-bit blocks using a 56-bit key. The algorithm transforms 64-bit input into a 64-bit output. The same steps with the same key are used to reverse the encryption. The authentication process ensures that the switch receives accurate messages from authorized sources. Authentication is accomplished between the switch and the SNMP management station through the use of a username and password identified via the snmp station CLI syntax. The username and password along with an authentication algorithm (SHA or MD5) are used by the SNMP management station to compute a hash that is transmitted in the PDU. The switch receives the PDU and computes the hash to verify that the management station knows the password. The switch will also verify the checksum contained in the PDU. Authentication and encryption are combined when the PDU is first authenticated by either the SHA or MD5 method. Then the message is encrypted using the DES encryption scheme. The encryption key is derived from the authentication key, which is used to decrypt the PDU on the switchs side.

Working with SNMP Traps

The SNMP agent in the switch has the ability to send traps to the management station. It is not required that the management station request them. Traps are messages alerting the SNMP manager to a condition on the network. A trap message is sent via a PDU issued from the switchs network management agent. It is sent to alert the management station to some event or condition on the switch. Traps can indicate improper user authentication, restarts, the loss of a connection, or other significant events. You can configure the switch so that traps are forwarded to or suppressed from transmission to the management station under different circumstances.

Trap Filtering
You can filter SNMP traps in at least two ways. You can filter traps by limiting user access to trap families or you can filter according to individual traps.

Filtering by Trap Families

Withholding access privileges for user accounts to certain command families or domains can restrict access to SNMP traps. (Designation of particular command families for user access is sometimes referred to as partition management.) SNMP traps are divided into functional families. These families correspond to switch CLI command families. When read-only privileges for a user account are restricted for a command family, that user account is also restricted from reading traps associated with that family.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 633 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Filtering By Individual Trap

You can configure the switch to filter out individual traps by using the snmp trap filter command. This command allows you to suppress specified traps from the management station. The following information is needed to suppress specific traps: The IP address of the SNMP management station that will receive the traps The ID number of the individual traps to be suppressed

Authentication Trap
The authentication trap is sent when an SNMP authentication failure is detected. This trap is a signal to the management station that the switch received a message from an unauthorized protocol entity. This normally means that a network entity attempted an operation on the switch for which it had insufficient authorization. When the SNMP authentication trap is enabled, the switch will forward a trap to the management station. The trap will be suppressed if the SNMP authentication trap is disabled.

Trap Management
Several CLI commands allow you to control trap forwarding from the agent in the switch to the SNMP management station.

Replaying Traps
The switch normally stores all traps that have been sent out to the SNMP management stations. You can list the last stored traps by using the show snmp trap replay command. This command lists the traps along with their sequence number. The sequence number is a record of the order in which the traps were previously sent out. You may want to replay traps that have been stored on the switch for testing or troubleshooting purposes. This is useful in the event that any traps are lost in the network. To replay stored traps, use the snmp trap replay command followed by the IP address for an SNMP management station. This command replays (or re-sends) all stored traps from the switch to the specified management station on demand. If you do not want to replay all of the stored traps, you can specify the sequence number from which the trap replay will start. The switch will start the replay with a trap sequence number greater than or equal to the sequence number given in the CLI command. The number of traps replayed depends on the number of traps stored for this station.

Absorbing Traps
The switch may send the same traps to the management station many, many times. You can suppress the transmission of identical repetitive traps by issuing the snmp trap absorption command. When trap absorption is enabled, traps that are identical to traps previously sent will be suppressed and therefore not forwarded to the SNMP management station.

Sending Traps to WebView

When WebView forwarding is enabled, all traps sent by switch applications are also forwarded to WebView.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 634 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

SNMP MIB Information

MIB Tables
You can display MIB tables and their corresponding command families by using the show snmp mib family command. The MIB table identifies the MIP identification number, the MIB table name and the command family. If a command family is not valid for the entire MIB table, the command family will be displayed on a per-object basis. For a list and description of system MIBs, refer to Industry Standard MIBs and Enterprise (Proprietary) MIBs in Appendix #2. For a list and description of traps, refer to the SNMP Traps Table in Appendix #1. The following is a partial display. -> Show snmp mib family MIP ID MIB TABLE NAME FAMILY -------+----------------------------------------+--------------------6145 esmConfTrap NO SNMP ACCESS 6146 alcetherStatsTable interface 6147 dot3ControlTable interface 6148 dot3PauseTable interface 6149 dot3StatsTable interface 6150 esmConfTable interface ... ... 77828 healthModuleTable rmon 77829 healthPortTable rmon 77830 healthThreshInfo rmon 78849 vrrpAssoIpAddrTable vrrp 78850 vrrpOperTable vrrp 78851 vrrpOperations vrrp 78852 vrrpRouterStatsTable vrrp ... ... 87042 vacmContextTable snmp 87043 vacmSecurityToGroupTable snmp 87044 vacmAccessTable snmp 87045 vacmViewTreeFamilyTable snmp

MIB Table Description

If the user account has no restrictions, the display shown by the show snmp mib family command can be very long. For documentation purposes, a partial list is shown above and three entry examples are defined. The first entry in the MIB Table shows a MIP identification number of 6145. The MIB table name is esmConfTrap. This table is found in the Alcatel-LucentIND1Port MIB, which defines managed objects for the ESM Driver subsystem. For MIP Id number 77828, the MIB table name is healthModuleTable. This table is found in the AlcatelLucentIND1Health MIB, which defines, managed objects for the health monitoring subsystem. For MIB Id number 87042, the MIB table name is vacmContextTable. This table is found in the SNMP-VIEW-BASED-ACM MIB, which serves as the view-based access control model (VACM) for the SNMP.

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 635 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Appendix #1
SNMP Trap Tables

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 636 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 637 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 638 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 639 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 640 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 641 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 642 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 643 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 644 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 645 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 646 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 647 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 648 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 649 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 650 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 651 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 652 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 653 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 654 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

Note: all refers to OS6800/OS6850/OS9000 platforms. OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 655 Software & Hardware Release: AOSv6.3.1r01 Alcatel-Lucent-ESD Calabasas/CA./USA

Appendix #2
SNMP MIB Tables

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 656 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 657 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 658 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 659 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 660 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 661 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 662 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 663 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 664 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA

OS6850 Series Boilerplate Doc. Rev.6.0 / Feb. 2008 Page 665 Software & Hardware Release: AOSv6.3.1r01

Alcatel-Lucent-ESD Calabasas/CA./USA