Alcatel-Lucent 4504 Switch User Manual

Add to My manuals
86 Pages

advertisement

Alcatel-Lucent 4504 Switch User Manual | Manualzz

Release Notes

OmniSwitch 6800/6850/9000

Release 6.1.3.R01

These release notes accompany release 6.1.3.R01 software for the OmniSwitch 6800, 6850, and 9000 hardware. They provide important information on individual software features and hardware modules.

Since much of the information in these release notes is not included in the hardware and software user manuals, it is important that you read all sections of this document before installing new hardware or loading new software.

Contents

Related Documentation, see

page 2

.

System Requirements, see

page 4 .

Memory Requirements, see page 4 .

UBoot, FPGA, MiniBoot, BootROM, and Upgrade Requirements, see

page 4

.

New Hardware Supported, see

page 5 .

Supported Hardware/Software Combinations, see

page -9 .

New Software Features, see

page -11

.

Software Supported, see

page 13 .

Supported Traps, see

page 37 .

Unsupported Software Features, see page 42 .

Unsupported CLI Commands, see page 42

.

Unsupported MIBs, see

page 44 .

Open Problem Reports, and Feature Exceptions, see page 48

.

Switch Management, see

page 48 .

Layer 2, see

page 53 .

Layer 3, see page 65 .

Advanced Routing, see

page 69 .

Quality of Service, see

page 72 .

Security, see page 74 .

System, see

page 78

.

Technical Support, see page 86

.

Release Notes

Part Number 032067-10, Rev D

Copyright 2006 Alcatel Internetworking, Inc.

page 1

Related Documentation

Related Documentation

These release notes should be used in conjunction with the OmniSwitch 6800, 6850, and 9000. The following are the titles and descriptions of the user manuals that apply to the OmniSwitch 6800, 6850, and

9000.

Note. User manuals can be downloaded at http://www.alcatel.com/enterprise/en/resource_library/ user_manuals.html.

OmniSwitch 6800 Series Getting Started guide

Describes the hardware and software procedures for getting an OmniSwitch 6800 Series switch up and running.

OmniSwitch 6850 Series Getting Started Guide

Describes the hardware and software procedures for getting an OmniSwitch 6850 Series switch up and running.

OmniSwitch 9000 Series Getting Started Guide

Describes the hardware and software procedures for getting an OmniSwitch 9000 Series switch up and running.

OmniSwitch 6800 Series Hardware User Guide

Complete technical specifications and procedures for all OmniSwitch 6800 Series chassis, power supplies, and fans.

OmniSwitch 6850 Series Hardware User Guide

Complete technical specifications and procedures for all OmniSwitch 6850 Series chassis, power supplies, and fans.

OmniSwitch 9000 Series Hardware User Guide

Complete technical specifications and procedures for all OmniSwitch 9000 Series chassis, power supplies, and fans.

OmniSwitch CLI Reference Guide

Complete reference to all CLI commands supported on the OmniSwitch. Includes syntax definitions, default values, examples, usage guidelines, and CLI-to-MIB variable mappings.

OmniSwitch 6800/6850/9000 Network Configuration Guide

Includes network configuration procedures and descriptive information on all the major software features and protocols included in the base software package. Chapters cover Layer 2 information

(Ethernet and VLAN configuration), Layer 3 information (routing protocols), security options (Authenticated Switch Access (ASA)), Quality of Service (QoS), link aggregation.

OmniSwitch 6800/6850/9000 Series Switch Management Guide

Includes procedures for readying an individual switch for integration into a network. Topics include the software directory architecture, software rollback protections, authenticated switch access, managing switch files, system configuration, using SNMP, and using web management software (WebView).

page 2 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Related Documentation

OmniSwitch 6800/6850/9000 Series Advanced Routing Configuration Guide

Includes network configuration procedures and descriptive information on all the software features and protocols included in the advanced routing software package. Chapters cover multicast routing

(DVMRP and PIM), BGP, OSPF, and OSPFv3.

Upgrade Instructions for 6.1.3.R01

Provides instructions for upgrading the OmniSwitch 6800, 6850, 9000 to 6.1.3.R01.

Technical Tips, Field Notices

Contracted customers can visit our customer service website at: http://eservice.ind.alcatel.com.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 3

System Requirements

System Requirements

Memory Requirements

OmniSwitch 6800 Series Release 6.1.3.R01 requires 256 MB of SDRAM and 64MB of flash memory.

This is the standard configuration shipped.

OmniSwitch 6850 Series Release 6.1.3.R01 requires 256 MB of SDRAM and 64MB of flash memory.

This is the standard configuration shipped.

OmniSwitch 9000 Series Release 6.1.3.R01 requires 256 MB of SDRAM and 128MB of flash memory. This is the standard configuration shipped.

Configuration files and the compressed software images—including web management software

(WebView) images—are 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

Note. Field upgrade of existing OmniSwitch units is required prior to loading this release. See the Upgrad-

ing OmniSwitch 6800, 6850, and 9000 Series Switches to 6.1.3.R01 upgrade instructions for more information.

The software versions listed in this section are the minimum required, except where otherwise noted.

OmniSwitch 6800 Series

Miniboot: 6.1.2.49.R03 or later

BootROM: 6.1.2.49.R03 or later

OmniSwitch 6850 Series

UBoot: 6.1.3.601.R01 or later

Miniboot.uboot: 6.1.3.601.R01 or later

OmniSwitch 9000 Series

UBoot NI: 6.1.1.167.R02 or later

UBoot CMM: 6.1.1.167.R02 or later

Miniboot.uboot CMM: 6.1.1.167.R02 or later

FPGA CMM: Major Revision: 2 Minor Revision: 25 (displays as 0x19)

POE Firmware

5.01

page 4 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

New Hardware Supported

New Hardware Supported

The following new hardware is supported subject to the feature exceptions and problem reports described later in these release notes.

New Chassis

The following new OmniSwitch 6850 Series chassis are available in this release.

Note. The USB port on the OmniSwitch 6850 Series units is not supported in this release.

OS6850-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/1000Base-T or 1000 Base-X high speed connections.

OS6850-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 be 10/100/1000Base-T or 1000Base-X high speed connections.

OS6850-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/1000 Base-T PoE or 1000 Base-X high speed connections.

OS6850-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 be

10/100/1000 Base-T PoE or 1000 Base-X high speed connections.

OS6850-U24X

The OmniSwitch 6850-U24X is a stackable edge/workgroup switch offering 22 1000Base-X MiniGBIC

SFP ports, two (2) 10 Gigabit XFP slots, as well as two combo ports individually configurable to be

10/100/1000 Base-T ports.

Note. OmniSwitch 6850 units and OmniSwitch 6800 units should not be mixed in the same stack. See the

OmniSwitch 6850 Series Hardware Users Guide for more information on OmniSwitch 6850 hardware features.

The following new OmniSwitch 9000 Series chassis are available in this release:

OS9800

The OmniSwitch 9800 chassis supports a high-performance switch fabric and provides 16 slots for Ethernet, Gigabit Ethernet, and/or 10 Gigabit Ethernet Network Interface (NI) modules. An additional two slots are reserved for primary and redundant Chassis Management Modules (CMMs). The OmniSwitch 9800

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 5

New Hardware Supported supports a maximum of four power supplies and up to 384 10/100/1000 copper ports and/or 1000 Mbps fiber ports. It is suitable for wiring closet installations. It can also be equipped with up to 96 10 Gigabit

Ethernet ports for use as the core switch.

Note. OmniSwitch 9700 NI modules and OmniSwitch 7700 NI modules should not be mixed in the same chassis. See the OmniSwitch 9000 Series Hardware Users Guide for more information on OmniSwitch

9000 hardware features.

New Chassis Management Module (CMM)

The following CMM is available in this release:

OS9800-CMM

The Chassis Management Module (CMM) is the management unit for OmniSwitch 9000 switches. In its role as the management unit, the CMM provides key system services, including:

Console, USB, and Ethernet management port connections to the switch

Software and configuration management, including the Command Line Interface (CLI)

Web-based management (WebView)

SNMP management

Power distribution

Switch diagnostics

Important availability features, including redundancy (when used in conjunction with another CMM), software rollback, temperature management, and power management

The CMM also contains the switch fabric unit for the OmniSwitch 9000. Data passing from one NI module to another passes through the CMM fabric. When two CMMs are installed, both fabrics are normally active.

Note. The USB port on the front panel of the CMM is not supported in this release.

New Network Interface (NI) Modules

The following NI modules are available in this release:

OS9-GNI-P24

Provides 24 auto-sensing twisted-pair Power over Ethernet (PoE) ports, individually configurable as

10BaseT, 100BaseTX, or 1000BaseT.

OS9-XNI-U6

Provides six 10 Gigabit XFP slots.

page 6 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

New Hardware Supported

New Power over Ethernet Components/Enhancements

OmniSwitch 9000 OS-IP-SHELF PoE Power Shelf

The OS-IP-SHELF unit is the peripheral power shelf for the chassis that provides the electrical current used for PoE ports. Up to four 600W OS-IP-SHELF specific power supply modules are available. These are load sharing modules that can provide up to a maximum of 2400W PoE power source.

OmniSwitch 9600 Support for PS-510W AC/PS-360W AC

The 510W and 360W power supplies can be used as an alternate power source for PoE on the OmniSwitch

9600. A single 510W power supply allocates 380W for the PoE functionality; Similarly, a single 360W power supply allocates 230W for the PoE functionality. Only one power supply module can be installed per switch, not both. These power modules support load sharing across all the POE NIs in the OmniSwitch

9600 chassis.

Note that the 510W/360W power supplies are only supported on the OmniSwitch 9600 and not on the

OmniSwitch 9700 or OmniSwitch 9800.

New Ethernet Transceivers (SFPs)

The following Gigabit Ethernet, dual-speed Ethernet, and 100FX Ethernet transceivers are available in this release:

Gigabit Ethernet Transceiver (SFP MSA)

SFP-GIG-T - 1000Base-T Gigabit Ethernet Transceiver (SFP MSA) - Supports category 5, 5E, and 6 copper cabling up to 100m. SFP only works in 1000 Mbit/s speed and full-duplex mode.

Dual Speed Ethernet Transceivers

SFP-DUAL-MM - 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-DUAL-SM10 - 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.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 7

New Hardware Supported

100FX Ethernet Transceivers

SFP-100-BX20LT - 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.

SFP-100-BX20NU - 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.

SFP-100-LC-MM - 100Base-FX SFP transceiver. Supports multi mode fiber over 1310nm wavelength

(nominal) with an LC connector.

SFP-100-LC-SM15 - 100Base-FX SFP transceiver. Supports single mode fiber over 1310nm wavelength

(nominal) with an LC connector. Typical reach of 15 Km.

SFP-100-LC-SM40 - 100Base-FX SFP transceiver Supports single mode fiber over 1310nm wavelength

(nominal) with an LC connector. Typical reach of 40 Km.

Supported Configuration Matrix for New Ethernet Transceivers

The following table shows the Ethernet transceiver configurations supported with the 6.1.3.R01 release:

SFP

SFP-GIG-T - 1000Base-T Gigabit Ethernet Transceiver (SFP

MSA).

SFP-DUAL-MM - Dual Speed

100Base-FX or 1000Base-X Ethernet optical transceiver.

SFP-DUAL-SM10 - Dual Speed

100Base-FX or 1000Base-X Ethernet optical transceiver (SFP MSA)

SFP-100-BX20LT - 100Base-BX

SFP bi-directional transceiver.

SFP-100-BX20NU - 100Base-BX

SFP bidirectional transceiver.

SFP-100-LC-MM - 100Base-FX

SFP transceiver.

SFP-100-LC-SM15 - 100Base-FX

SFP transceiver.

SFP-100-LC-SM40 - 100Base-FX

SFP transceiver.

OS6800/OS6850

Combo Ports

supported

OS6800-U24

Non-Combo

Ports

supported unsupported unsupported unsupported unsupported unsupported unsupported unsupported unsupported unsupported unsupported unsupported unsupported unsupported unsupported

OS6850-U24X OS9-GNI-U24

supported supported supported supported supported supported supported supported supported supported supported unsupported unsupported unsupported unsupported unsupported page 8 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Supported Hardware/Software Combinations

Supported Hardware/Software Combinations

The following table shows the 6.1 software releases that support each of the listed OS9000, OS6850, and

OS6800 module types:

Module Type

OS96/9700 CMM, REV B

OS96/9700 CMM, REV C

OS9800 CMM

OS9-GNI-C24, ASIC A1

OS9-GNI-U24, ASIC A1

OS9-XNI-U2, ASIC A1

OS9-GNI-C24, ASIC B2

OS9-GNI-U24, ASIC B2

OS9-XNI-U2, ASIC B2

OS9-GNI-P24, ASIC B2

OS9-XNI-U6, ASIC B2

Part Number 6.1.1.R01

902369

902444

902492

902367

902370

902379

902394

902396

902397

902395

902398

6.1.1.R02

supported supported supported supported not supported not supported supported supported supported supported supported supported not supported supported not supported supported not supported supported not supported not supported not supported not supported

6.1.2.R03

n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a

6.1.3.R01

supported supported supported supported supported supported supported supported supported supported supported

OS6850-24

OS6850-48

OS6850-24X

OS6850-48X

OS6850-P24

OS6850-P48

OS6850-P24X

OS6850-P48X

OS6850-U24X

OS6850-24L

OS6850-48L

OS6850-P24L

OS6850-P48L

902457

902495

902458

902462

902459

902463

902460

902464

902418

902487

902489

902488

902490 n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a supported supported supported supported supported supported supported supported supported supported supported supported supported supported supported supported not supported supported not supported supported not supported supported not supported supported not supported supported

OS6800-24

OS6800-48

OS6800-24L

OS6800-48L

OS6800-U24

902349

902350

902377

902378

902351 n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a supported supported supported supported supported supported supported supported supported supported

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 9

Supported Hardware/Software Combinations

To determine the ASIC revision for a specific NI, use the show ni command. For example, the following

show ni output display shows a B2 revision level for NI 1:

DC-Core ->> show ni 1

Module in slot 1

Model Name: OS9-GNI-C24,

Description: 10-1000 RJ45,

Part Number: 902394-40,

Hardware Revision: C13,

Serial Number: G1511279,

Manufacture Date: MAY 03 2006,

Firmware Version: ,

Admin Status: POWER ON,

Operational Status: UP,

Power Consumption: 51,

Power Control Checksum: 0x0,

MAC Address: 00:d0:95:e6:54:80,

ASIC - Physical 1: BCM56504_B2

CPLD - Physical 1: 0005/00

UBOOT Version : 6.1.1.167.R02

UBOOT-miniboot Version : No Miniboot

POE SW Version : n/a

To determine the CMM board revision, use the show cmm command. For example, the following show

cmm output display shows a C revision level for the CMM board:

DC-Core ->> show cmm

Module in slot CMM-A-1

Model Name: OS9700-CFM,

Description: FABRIC BOARD,

Part Number: 902444-10,

Hardware Revision: C11,

Serial Number: G1810128,

Manufacture Date: MAY 08 2006,

Firmware Version: 2,

Admin Status: POWER ON,

Operational Status: UP,

Power Consumption: 27,

Power Control Checksum: 0x0,

MAC Address: 00:d0:95:e0:6c:ac, page 10 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

New Software Features

New Software Features

The following software features and/or the platforms they are supported on are new with the 6.1.3.R01 release, subject to the feature exceptions and problem reports described later in these release notes:

Feature Summary

Feature Platform

802.1Q 2005 (MSTP)

802.1W (RSTP) Default

802.1x Device Classification

Access Control Lists (ACLs) for IPv6

ACL Manager (ACLMAN)

Authenticated Switch Access - TACACS+

all all

OS9000

OS6850/OS9000

OS9000 all

BGP Graceful Restart

DHCP Option-82

DHCP Snooping

Generic UDP Relay

all

OS9000

OS9000 all

IP DoS Enhancements

OS6850/OS9000

IP Multicast Switching (IPMS) - Proxying

all

IPv6 Multicast Switching (IPMS) - Proxying OS6850/OS9000

IP Route Map Redistribution

all

L2 DHCP Snooping

L2 Static Multicast Addresses

all all

L2 MAC Address Table Size Enhancement

OS9000

OSPFv3

OS6850/OS9000

PIM

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 Aggregate)

Secure Copy (SCP)

Server Load Balancing (SLB)

SSH Public Key Authentication

Syslog to Multiple Hosts

all

OS6850

OS9000

OS6850/OS9000

OS9000

OS6850

OS9000

OS6850/OS9000

OS9000 all base base base base

Software Package

base 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

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 11

New Software Features

Feature

VLAN Range Support

VLAN Stacking and Translation

VRRPv3

Platform

all

OS6850/OS9000

OS6850/OS9000

Software Package

base base base page 12 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Software Supported

Software Supported

In addition to the new software features introduced with the 6.1.3.R01 release, the following software features are also supported in 6.1.3.R01, subject to the feature exceptions and problem reports described later in these release notes:

Feature Summary

Feature

802.1Q

802.1d/1w Spanning Tree

802.1x Multiple Client Support

802.1x Device Classification

(Access Guardian)

Access Control Lists (ACLs)

ACL & Layer 3 Security

ACL Manager (ACLMAN)

Authenticated Switch Access

Authenticated VLANs

Automatic VLAN Containment (AVC)

Basic IPv4 Routing

Basic IPv6 Routing (static, RIPng)

BGP4

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 Multicast Switching (IPMS)

IPv6 Multicast Switching (MLD)

Platform

all all all all all all

OS6850/OS9000 all all all all all all all all all all

OS6800/OS9000 all all all all all all all all all all

OS6850/OS9000 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

Software Package

base base base base

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 13

Software Supported

Feature Platform

IPv6 (NPD)

IPX Routing

Learned Port Security (LPS)

Link Aggregation (static & 802.3ad)

Multicast Routing

Multinetting

NTP Client

OSPFv2

Partitioned Switch Management

Per-VLAN DHCP Relay

PIM-SM

PIM-SSM (Source-Specific Multicast)

Policy Server Management

all all all all

Policy Based Routing (Permanent Mode)

OS6850/OS9000

Port Mapping

all

Port Mirroring (1:24)

Port Monitoring

OS6800 all

Power over Ethernet (PoE)

Quality of Service (QoS)

Redirection Policies

(Port and Link Aggregate)

RMON

Router Discovery Protocol (RDP)

Routing Protocol Preference

Secure Copy (SCP)

Secure Shell (SSH)

all all all all all all all all

OS6850/OS9000 all

OS6850/OS9000 all all all all all

SSH Public Key Authentication sFlow

Smart Continuous Switching

Hot Swap

Management Module Failover

Power Monitoring

Redundancy

SNMP

Source Learning

Software Rollback

Spanning Tree

Switch Logging

all

OS6850/OS9000 all all all all all all page 14 base base base base base base base base base base base base base

Software Package

base base base base base base base base base base base base base base base base base base

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Software Supported

Feature

Text File Configuration

User Definable Loopback Interface

VLANs

VRRP

Web-Based Management (WebView)

Platform

all all all all all

Software Package

base base base base base

Feature Descriptions

802.1Q

Alcatel-Lucent’s 802.1Q is an IEEE standard for sending frames through the network tagged with VLAN identification. 802.1Q tagging is the IEEE version of VLANs. It is a method of segregating areas of a network into distinct VLANs. By attaching a label, or tag, to a packet, it 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.

802.1Q 2005 (MSTP)

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.

The 6.1.3.R01 release provides support for this feature on the OmniSwitch 6800 Series, OmniSwitch 6850

Series, and OmniSwitch 9000 Series.

802.1W (RSTP) Default

The Rapid Spanning Tree Protocol (RSTP) is now the default Spanning Tree protocol for the OmniSwitch

6800/6850/9000 regardless of which mode (flat or 1x1) is active.

802.1x Device Classification (Access Guardian)

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 nonsupplicant access to 802.1x ports.

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.

Device Classification is supported on the OmniSwitch 6800 Series and OmniSwitch 6850 Series. The

6.1.3.R01 release provides support for this feature on the OmniSwitch 9000 Series.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 15

Software Supported

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 ACLs—for filtering traffic at the MAC layer. Usually uses MAC addresses or MAC groups for filtering.

Layer 3/4 ACLs—for filtering traffic at the network layer. Typically uses IP addresses or IP ports for filtering; note that IPX filtering is not supported.

Multicast ACLs—for filtering IGMP traffic.

Access Control Lists (ACLs) for IPv6

The 6.1.3.R01 release provides support for IPv6 ACLs on the OmniSwitch 6850 Series and OmniSwitch

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

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.

ACL & Layer 3 Security

The following additional ACL features are available for improving network security and preventing malicious activity on the network:

ICMP drop rules—Allows 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.

page 16 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Software Supported

TCP connection rules—Allows 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 discard—ARP 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.

UserPorts—A 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 Profile—In 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.

DropServices—A 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.

ACL Manager

The 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 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 is supported on the OmniSwitch 6850 Series. The 6.1.3.R01 release provides support for this feature on the OmniSwitch 9000 Series.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 17

Software Supported

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.

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. Authenticationonly 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 Security’s SecurID product suite. RSA Security’s 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.

Authenticated VLANs

Authenticated VLANs control user access to network resources based on VLAN assignment and a user log-in 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 number of possible AVLAN users is 1048.

Layer 2 Authentication is different from Authenticated Switch Access, which is used to grant individual users access to manage the switch.

The Mac OS X 10.3.x is supported for AVLAN web authentication using JVM-v1.4.2.

Automatic VLAN Containment (AVC)

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.

page 18 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Software Supported

Basic IPv4 Routing

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)

User Datagram Protocol (UDP)

Bootstrap Protocol (BOOTP)/Dynamic Host Configuration Protocol (DHCP)

Simple Network Management Protocol (SNMP)

Telnet

File Transfer Protocol (FTP)

Address Resolution Protocol (ARP)

Internet Control Message Protocol (ICMP)

RIP I / RIP II

The base IP software allows one to configure an IP router interface, 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 an IP route, display Transmission Control Protocol (TCP) information, and display User Datagram Protocol (UDP) information.

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

BGP4

The Border Gateway Protocol (BGP) is an exterior routing protocol that guarantees the loop-free exchange of routing information between autonomous systems. There are three versions of the BGP protocol— versions 2, 3, and 4. 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 organization’s Internet Service Provider (ISP) link. Up to 65,000 route table entries and next hop routes can be supported by BGP.

BGP Graceful Restart

BGP Graceful Restart is now supported and is enabled by default. 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 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 6.1.3.R01 release provides support for this feature on the OmniSwitch 6800 Series, OmniSwitch 6850

Series, and OmniSwitch 9000 Series.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 19

Software Supported

BPDU Shutdown Ports

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.

Command Line Interface (CLI)

Alcatel-Lucent’s 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 CLI Reference guide. All command descriptions listed in the Reference Guide include command syntax definitions, defaults, usage guidelines, example screen output, and release history.

The CLI uses single-line text commands that are similar to other industry standard switch interfaces.

DHCP Relay

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.

DHCP Option-82 (Relay Agent Information Option)

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 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 and OmniSwitch 6850 Series. The

6.1.3.R01 release provides support for this feature on the OmniSwitch 9000 Series.

DHCP Snooping

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: page 20 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Software Supported

Traffic Suppression—Prevents 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 Filtering—Restricts 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 Limiting—Limits the number of DHCP packets on a port. This functionality is provided using the QoS application to configure ACLs for the port.

DHCP Snooping is supported on the OmniSwitch 6800 Series and OmniSwitch 6850 Series. The

6.1.3.R01 release provides support for this feature on the OmniSwitch 9000 Series.

DNS Client

A Domain Name System (DNS) resolver is an internet service that translates host names into IP addresses.

Every time you enter a host name, 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.

Dynamic VLAN Assignment (Mobility)

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.

DVMRP

Distance Vector Multicast Routing Protocol (DVMRP) is a dense-mode multicast routing protocol.

DVMRP—which is essentially a “broadcast and prune” routing protocol—is 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 source’s truncated broadcast tree.

End User Partitioning (EUPM)

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.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 21

Software Supported

Ethernet Interfaces

Ethernet and Gigabit Ethernet port software is responsible for a variety of functions that support Ethernet,

Gigabit, 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: autonegotiation (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).

Generic UDP Relay

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 6.1.3.R01 release provides support for this feature on the OmniSwitch 6800 Series, OmniSwitch 6850

Series, and OmniSwitch 9000 Series.

Health Statistics

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 switch’s resource utilization levels and thresholds, improving the 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

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.

HTTP/HTTPS Port Configuration

The default HTTP port and the default Secure HTTP (HTTPS) port can be configured for the embedded

Web server in the switch.

page 22 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Software Supported

Interswitch Protocol (AMAP)

Alcatel-Lucent Interswitch Protocols (AIP) are used to discover adjacent switches and retain mobile port information across switches. By default, AMAP is enabled.

Alcatel-Lucent Mapping Adjacency Protocol (AMAP) is used to discover the network topology of Alcatel-Lucent switches in a particular installation. Using this protocol, each switch determines which 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

IP DoS Enhancements

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 loopback source IP address - OS6850/OS9000

The 6.1.3.R01 release provides support for these enhancements on the OmniSwitch 6800 Series,

OmniSwitch 6850 Series, and OmniSwitch 9000 Series as noted above.

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, and

BOOTP). Unlike unicast, which sends one packet per destination, multicast sends one packet to all devices in any subnetwork that has at least one device requesting the multicast traffic. 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-Lucent’s implementation of IGMP snooping is called IP Multicast Switching (IPMS). IPMS allows OmniSwitch

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

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 23

Software Supported

IP Multicast Switching (IPMS) - Proxying

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 queriers. The unsolicited report interval refers to the time period in which to proxy any changed IGMP membership state.

The 6.1.3.R01 release provides support for this feature on the OmniSwitch 6800 Series, OmniSwitch 6850

Series, and OmniSwitch 9000 Series. IPv6 IPMS Proxying is not supported on the OmniSwitch 6800

Series.

IP Route Map Redistribution

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 userdefined 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 is applied to routes received from the source protocol.

The 6.1.3.R01 release provides support for this feature on the OmniSwitch 6800 Series, OmniSwitch 6850

Series, and OmniSwitch 9000 Series.

IPv6 (NPD)

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 Autoconfiguration

RIPng

Static Routes

Tunneling: Configured and 6-to-4 dynamic tunneling

Ping, traceroute

FTP and Telnet servers

DNS client using Authority records

OmniSwitch 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 page 24 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Software Supported

IPX Routing

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 Novell’s network server operating system.) This implementation of IPX routing is software based with limited performance.

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 IPX network number is assigned by the network administrator. The node number is the Media Access Control (MAC) address for a network interface in the end node.

L2 DHCP Snooping

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.

The 6.1.3.R01 release provides support for this feature on the OmniSwitch 6800 Series, OmniSwitch 6850

Series, and OmniSwitch 9000 Series.

L2 MAC Address Table Size Enhancement

There are now two source learning modes available for the OmniSwitch 9000 Series switches: synchronized and distributed. By default the switch runs in the synchronized mode, which allows a total MAC address tables size of 16K per chassis. Enabling the distributed mode for the switch increases the table size to 16K per module and up to 64K per OmniSwitch 9000 chassis.

The 6.1.3.R01 release provides support for this feature on the OmniSwitch 9000 Series; increasing the

MAC address table size is not supported on the OmniSwitch 6800 Series and OmniSwitch 6850 Series.

L2 Static Multicast Addresses

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.

The 6.1.3.R01 release provides support for this feature on the OmniSwitch 6800 Series, OmniSwitch 6850

Series, and OmniSwitch 9000 Series.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 25

Software Supported

Learned Port Security (LPS)

Learned Port Security (LPS) provides a mechanism for authorizing source learning of MAC addresses on

10/100/1000, Gigabit, and Gigabit Ethernet 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: Shutting down the port or only blocking traffic that violates LPS criteria.

LPS has the following limitations:

You cannot configure LPS on 10 Gigabit ports.

You cannot configure LPS on link aggregate ports.

Link Aggregation (static & 802.3ad)

Alcatel-Lucent’s 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. You can configure up to 32 link aggregation groups that can consist of 2, 4, or 8 Ethernetports.

Reliability. If one of the physical links in a link aggregate group goes down, the link aggregate group can still operate.

Ease of Migration. Link aggregation can ease the transition from a Gigabit Ethernet backbone to a 10

Gigabit Ethernet backbone.

Interoperability with Legacy Switches. Static link aggregation can interoperate with OmniChannel on legacy switches.

Alcatel’s link aggregation software allows you to configure the following two different types of link aggregation groups:

Static link aggregate groups

Dynamic (802.3ad) link aggregate groups

Multicast Routing

The OmniSwitch 9000 switches support multicast routing on IPv4 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.

page 26 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Software Supported

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.

PIM

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 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 PIM-SM, 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).

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.

NTP Client

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 half a second on LANs and WANs relative to a primary server synchronized to Universal

Coordinated Time (UTC) (via a Global Positioning Service receiver, for example).

OSPFv2/OSPFv3

Open Shortest Path First version 3 (OSPFv3) is now available with the 6.1.3.R01 release on the

OmniSwitch 6850 Series and OmniSwitch 9000 Series. 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.

The following features are also supported by both versions of OSPF:

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.

OSPF adjacencies over non broadcast links.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 27

Software Supported

Partitioned Switch Management

A user account includes a login name, password, and user privileges. The 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. The privileges are sometimes referred to as authorization; the designation of particular command families or domains for user access is sometimes referred to as parti-

tioned management.

Available command domains and families are listed in the following table:

Domain

domain-admin domain-system domain-physical domain-network domain-layer2 domain-service domain-policy domain-security

Corresponding Families

file telnet dshell debug system aip snmp rmon web config chassis module interface pmm health ip rip ospf vrrp ip-routing ipx ipmr ipms

802.1q vlan bridge stp linkagg ip-helper dns qos policy slb session avlan aaa

Per-VLAN DHCP Relay

The OmniSwitch 9000 allows you 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.

Policy Server Management

Policy servers use Lightweight Directory Access Protocol (LDAP) to store policies that are configured through Alcatel-Lucent’s 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, PolicyView is supported for policy management.

Policy Based Routing (Permanent Mode)

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.

Policy Based Routing is supported on the OmniSwitch 9000 Series. The 6.1.3.R01 release provides support for this feature on the OmniSwitch 6850 Series. page 28 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Software Supported

Port Mapping

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 is supported on the OmniSwitch 6800 Series and OmniSwitch 6850 Series. The 6.1.3.R01 release provides support for this feature on the OmniSwitch 9000 Series.

Port Mirroring

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.

Power over Ethernet (PoE)

The Power over Ethernet (PoE) software is supported on the OS6850-P24, OS6850-P24X, OS6850-P48, and OS6850-P48X stackable switches. The 6.1.3.R01 release provides support for this feature on the

OmniSwitch 9000 Series. PoE provides inline power directly from the switch’s 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 380 watts. A 360w power-supply (OS6850/OS9600) can provide approximately 230 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.

Quality of Service (QoS)

Alcatel-Lucent’s 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 remapping 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 9000 switches truly support 8 queues per port.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 29

Software Supported

QoS is implemented on the switch through the use of policies, created on the switch or stored in Policy-

View.

While policies may be used in many different types of network scenarios, there are several typical types:

Basic QoS—includes traffic prioritization and bandwidth shaping

802.1p/ToS/DSCP—includes policies for marking and mapping

Policy Based Routing (PBR)—includes policies for redirecting routed traffic

Access Control Lists (ACLs)—ACLs are a specific type of QoS policy used for Layer 2, Layer 3/4, and multicast filtering.

Note. NAT is not supported.

Redirect Policies (Port and Link Aggregate)

Two policy action commands are available for configuring QoS redirection policies: policy action redi-

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

Redirect policies are supported on the OmniSwitch 9000 Series. The 6.1.3.R01 release provides support for this feature on the OmniSwitch 6850 Series.

RMON

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 analyzing without negatively impacting network performance. RMON software is fully integrated in the 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.

Router Discovery Protocol (RDP)

The Router Discovery Protocol (RDP) is an extension of ICMP that allows end hosts to discover routers on their networks. The 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.

Routing Protocol Preference

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

page 30 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Software Supported

Secure Copy (SCP)

The scp CLI command is now 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.

Secure Shell (SSH)

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

When used as an SSH Server, the following SSH Software is supported on the indicated operating systems:

OpenSSH

SSH Software

F-Secure

SSH-Communication

PuTTY

MAC-SSH

Supported Operating Systems

Sun Solaris, Mac OSX, Linux Red Hat

Sun Solaris, Win 2000, Win XP

Sun Solaris, Win 2000, Win XP, Linux Red Hat

Win 2000, Win XP

Mac OSX

When used as an SSH Client, the following SSH Software is supported on the indicated operating systems:

OpenSSH

SSH Software

F-Secure

SSH-Communication

Supported Operating Systems

Sun Solaris, Linux Red Hat, AOS

Sun Solaris, Win 2000

Sun Solaris, Win 2000, Win XP, Linux Red Hat

Secure Shell (SSH) Public Key Authentication

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.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 31

Software Supported

Server Load Balancing (SLB)

Alcatel’s 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 or a

QoS policy condition. 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).

The 6.1.3.R01 release provides support for this feature on the OmniSwitch 6850 Series and OmniSwitch

9000 Series.

sFlow

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. It provides the ability to monitor the traffic flows. It requires an sFlow agent software process running as part of the switch software and an 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).

Smart Continuous Switching - OmniSwitch 6800/OmniSwitch 6850

In stacked configurations, one 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 stack’s 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 Network Interface (NI) modules in chassis-based switches.

The stack provides support for all idle switches during primary switch failover. 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 switch’s takeover process.

Smart Continuous Switching - OmniSwitch 9000

Each OS9000 CMM module contains hardware and software elements to provide management functions for the OS9000 system. The OS9000 CMM module also contains the switch fabric for the OS9000 system.

User data flowing from one NI module to another passes through the switch fabric.

The OS9700 will operate with one or two CMM modules installed. The OS9600 operates with one CMM.

If there are two CMM modules in an OS9700, one management processor is considered “primary” and is actively managing the system. The other management processor is considered “secondary” and remains ready to quickly take over management in the event of hardware or software failure on the primary. In the event of a failure, the two processors exchange roles and the secondary takes over as primary.

page 32 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Software Supported

The switch fabric on the CMM operates independently of the management processor. If there are two

CMM modules installed in an OS9700, both fabric modules are normally active. Two CMM modules must be installed in the OS9700 to provide full fabric capacity. However, note that only the one CMM module in the OS9600 provides full fabric capacity.

If there is one CMM module installed in an OS9700, then there is a single management feature and performance as a dual CMM system, but there is no “secondary” CMM. Hardware or software failures in the

CMM will result in a system reboot. The System fabric capacity on an OS9700 is one half of the fabric capacity of a dual CMM system.

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 solve network problems. SNMP provides an industry standard communications model used by network administrators to manage and monitor their network devices. OmniSwitch 9000 switches support SNMPv1, SNMPv2, and SNMPv3.

Source Learning

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.

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.

Software Rollback

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.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 33

Software Supported

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.

Spanning Tree

In addition to the Q2005 version of MSTP, the Alcatel Spanning Tree implementation also provides support for the 802.1w Rapid Spanning Tree Algorithm and Protocol (RSTP) and the 802.1D Spanning

Tree Algorithm and Protocol (STP). All three supported protocols ensure that there is always only one data path between any two switches for a given Spanning Tree instance to prevent network loops.

Q2005 (MSTP) is only available when the flat mode is active for the switch. 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.

802.1D STP and 802.1w RSTP are available in both the flat and 1x1 mode. However, when using 802.1D or 802.1w in the flat mode, the single spanning tree instance per switch algorithm applies. Note that

802.1w is now the default Spanning Tree protocol for the switch regardless of which mode is active. This default value will apply to future releases as well.

Syslog to Multiple Hosts

You can now send syslog files to multiple hosts, up to a maximum of four servers.

Switch Logging

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 Command Line Interface. All log records generated are copied to all configured output devices.

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.

Text File Configuration

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 switch’s 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 NotePad) on a workstation. The resulting configuration file is then uploaded to the switch.

You can invoke the switch’s CLI snapshot command to capture the switch’s current configuration into a text file.

You can use the switch’s text editor to create or make changes to a configuration file. page 34 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Software Supported

User Definable Loopback Interface

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.

VLAN Range Support

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

VLAN Stacking and Translation

VLAN Stacking provides a mechanism for tunneling multiple customer VLANs (CVLAN) through a service provider network over the Ethernet Metropolitan Area Network (EMAN). The service provider network uses one or more service provider VLANs (SVLAN) by appending an 802.1Q double tag or

VLAN Translation on a customer port that contains the customer’s assigned tunnel ID. This traffic is then encapsulated into the tunnel and transmitted through the service provider network. It is received on another Provider Edge (PE) that has the same tunnel ID. This feature enables service providers to provide their customers with 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.

VRRPv2/VRRPv3

The Virtual Router Redundancy Protocol version 3 (VRRPv3) is now available with the 6.1.3.R01 release.

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 router’s IP address. If the master router becomes unavailable, the highest priority backup router will transition to the master state.

Note. Authentication is not supported.

In addition, both versions support VRRP Tracking. A virtual router’s 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.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 35

Software Supported

Web-Based Management (WebView)

The switch can be monitored and configured using WebView, Alcatel-Lucent’s 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

Netscape 7.1 for Windows NT, 2000, XP

Netscape 7.0 for Solaris SunOS 5.8

WebView contains modules for configuring all software features in the switch. Configuration and monitoring pages include context-sensitive on-line help.

page 36 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Supported Traps

Supported Traps

The following traps are supported in 6.1.3.R01:

No. Trap Name

0 coldStart

1 warmStart

2 linkDown

3 linkUp

4 authenticationFailure

5 entConfigChange

6 aipAMAPStatusTrap

7

8 aipGMAPConflictTrap policyEventNotification

9 chassisTrapsStr

10 chassisTrapsAlert

11 chassisTrapsStateChange

12 chassisTrapsMacOverlap

13 vrrpTrapNewMaster

14 vrrpTrapAuthFailure

15 healthMonDeviceTrap

16 healthMonModuleTrap

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Platforms Description

all all all all all all all

— all all all all all all

— all all

The SNMP agent in the switch is reinitiating and its configuration may have been altered.

The SNMP agent in the switch is reinitiating itself and its configuration is unaltered.

The SNMP agent in the switch recognizes a failure in one of the communications links configured for the switch.

The SNMP agent in the switch recognizes that one of the communications links configured for the switch has come up.

The SNMP agent in the switch has received a protocol message that is not properly authenticated.

An entConfigChange notification is generated when a conceptual row is created, modified, or deleted in one of the entity tables.

The status of the changed.

Alcatel

Mapping

Adjacency Protocol (AMAP) port

This trap is not supported.

The switch notifies the NMS when a significant event happens that involves the policy manager.

A software trouble report (STR) was sent by an application encountering a problem during its execution.

A notification that some change has occurred in the chassis.

An NI status change was detected.

A MAC range overlap was found in the backplane eeprom.

The SNMP agent has transferred from the backup state to the master state.

This trap is not supported.

Indicates a device-level threshold was crossed.

Indicates a module-level threshold was crossed.

page 37

Supported Traps

No. Trap Name

17 healthMonPortTrap

18 bgpEstablished

19 bgpBackwardTransition

20 esmDrvTrapDropsLink

21 pimNeighborLoss

22 dvmrpNeighborLoss

23 dvmrpNeighborNotPruning

24 risingAlarm

25 fallingAlarm page 38

Platforms Description

all all all all all all all all all

Indicates a port-level threshold was crossed.

The BGP routing protocol has entered the established state.

This trap is generated when the BGP router port has moved from a more active to a less active state.

This trap is sent when the Ethernet code drops the link because of excessive errors.

Signifies the loss of adjacency with a neighbor device. This trap is generated when the neighbor time expires and the switch has no other neighbors on the same interface with a lower IP address than itself.

A 2-way adjacency relationship with a neighbor has been lost. This trap is generated when the neighbor state changes from “active” to “one-way,”

“ignoring” or “down.” The trap is sent only when the switch has no other neighbors on the same interface with a lower IP address than itself.

A non-pruning neighbor has been detected in an implementation-dependent manner. This trap is generated at most once per generation ID of the neighbor. For example, it should be generated at the time a neighbor is first heard from if the prune bit is not set. It should also be generated if the local system has the ability to tell that a neighbor which sets the prune bit is not pruning any branches over an extended period of time. The trap should be generated if the router has no other neighbors on the same interface with a lower IP address than itself.

An Ethernet statistical variable has exceeded its rising threshold. The variable’s rising threshold and whether it will issue an SNMP trap for this condition are configured by an

NMS station running RMON.

An Ethernet statistical variable has dipped below its falling threshold.

The variable’s falling threshold and whether it will issue an SNMP trap for this condition are configured by an

NMS station running RMON.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

No. Trap Name

26 stpNewRoot

27 stpRootPortChange

28 mirrorConfigError

29 mirrorUnlikeNi

30 slPCAMStatusTrap

31 unused

32 unused

33 slbTrapOperStatus

34 ifMauJabberTrap

35 sessionAuthenticationTrap

36 trapAbsorptionTrap

37 alaStackMgrDuplicateSlotTrap

38 alaStackMgrNeighborChangeTrap

39 alaStackMgrRoleChangeTrap

40 lpsViolationTrap

41 alaDoSTrap

42 gmBindRuleViolation

43 unused

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Supported Traps

Platforms Description

all all all all all

Sent by a bridge that became the new root of the spanning tree.

A root port has changed for a spanning tree bridge. The root port is the port that offers the lowest cost path from this bridge to the root bridge.

The mirroring configuration failed on an NI. This trap is sent when any NI fails to configure mirroring. Due to this error, port mirroring session will be terminated.

The mirroring configuration is deleted due to the swapping of different NI board type. The Port Mirroring session which was active on a slot cannot continue with the insertion of different NI type in the same slot.

The trap status of the Layer 2 pesudo-

CAM for this NI.

all all all

— all all all

A change occurred in the operational status of the server load balancing entity.

This trap is sent whenever a managed interface MAU enters the jabber state.

An authentication failure trap is sent each time a user authentication is refused.

The absorption trap is sent when a trap has been absorbed at least once.

Two or more slots claim to have the same slot number.

Indicates whether or not the stack is in loop.

Indicates that a new primary or secondary stack is elected.

A Learned Port Security (LPS) violation has occurred.

Indicates that the sending agent has received a Denial of Service (DoS) attack.

Occurs whenever a binding rule which has been configured gets violated.

— page 39

Supported Traps

No. Trap Name

44 unused

45 unused

46 unused

47 pethPsePortOnOff

48 pethPsePortPowerMaintenanceStatus

49 pethMainPowerUsageOn

50 pethMainPowerUsageOff

51 ospfNbrStateChange

52 ospfVirtNbrStateChange

53 httpServerDoSAttackTrap

54 alaStackMgrDuplicateRoleTrap

55 alaStackMgrClearedSlotTrap

56 alaStackMgrOutOfSlotsTrap

57 alaStackMgrOutOfTokensTrap

58 alaStackMgrOutOfPassThruSlotsTrap page 40

Platforms Description

— all all all

Indicates if power inline port is or is not delivering power to the a power inline device.

Indicates the status of the power maintenance signature for inline power.

Indicates that the power inline usage is above the threshold.

Indicates that the power inline usage is below the threshold.

Indicates a state change of the neighbor relationship.

Indicates a state change of the virtual neighbor relationship.

This trap is sent to management station(s) when the HTTP server is under

Denial of Service attack. The HTTP and HTTPS connections are sampled at a 15 second interval. This trap is sent every 1 minute while the HTTP server detects it is under attack.

The element identified by alaStack-

MgrSlotNINumber detected the presence of two elements with the same primary or secondary role as specified by alaStackMgrChasRole on the stack.

The element identified by alaStack-

MgrSlotNINumber will enter the pass through mode because its operational slot was cleared with immediate effect.

One element of the stack will enter the pass through mode because there are no slot numbers available to be assigned to this element.

The element identified by alaStack-

MgrSlotNINumber will enter the pass through mode because there are no tokens available to be assigned to this element.

There are no pass through slots available to be assigned to an element that is supposed to enter the pass through mode.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Supported Traps

No. Trap Name

59 gmHwVlanRuleTableOverloadAlert

60 lnkaggAggUp

61 lnkaggAggDown

62 lnkaggPortJoin

63 lnkaggPortLeave

64 lnkaggPortRemove

65 pktDrop

66 monitorFileWritten

67 alaVrrp3TrapProtoError

68 alaVrrp3TrapNewMaster

69 gmHwMixModeSubnetRuleTableOverloadAlert

70 pethPwrSupplyConflict

Platforms Description

all all all all all all all all all all

An overload trap occurs whenever a new entry to the hardware VLAN rule table gets dropped due to the overload of the table.

Indicates the link aggregate is active.

This trap is sent when any one port of the link aggregate group goes into the attached state.

Indicates the link aggregate is not active. This trap is sent when all ports of the link aggregate group are no longer in the attached state.

This trap is sent when any given port of the link aggregate group goes to the attached state.

This trap is sent when any given port detaches from the link aggregate group.

This trap is sent when any given port of the link aggregate group is removed due to an invalid configuration.

The pktDrop trap indicates that the sending agent has dropped certain packets (to blocked IP ports, from spoofed addresses, etc.).

A File Written Trap is sent when the amount of data requested by the user has been written by the port monitoring instance.

Indicates that a TTL, checksum, or version error was encountered upon receipt of a VRRP advertisement.

The SNMP agent has transferred from the backup state to the master state.

This trap is not supported in the current release.

This trap is not supported in the current release.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 41

Unsupported Software Features

Unsupported Software Features

CLI commands and Web Management options maybe available in the switch software for the following features. These features are not supported:

Feature

OSPF Database Overflow (RFC 1765)

Flow Control 802.3x

Platform

all all

Software Package

base base

Unsupported CLI Commands

The following CLI commands are not supported in this release of the software:

Software Feature Unsupported CLI Commands

BGP

Chassis Mac Server ip bgp redist-filter status ip bgp redist-filter ip bgp redist-filter community ip bgp redist-filter local-preference ip bgp redist-filter metric ip bgp redist-filter effect ip bgp redist-filter subnets mac-range local mac-range duplicate-eeprom mac-range allocate-local-only show mac-range status

Command Line Interface (CLI) 10 gig slot [slot] phy-a|phy-b

Flow Control flow flow wait time interfaces flow

Ethernet Interfaces

Hot Swap interfaces long interfaces runt interfaces runtsize reload ni [slot] #

[no] power ni all

NTP

OSPF no ntp server all ip ospf redist status ip ospf redist ip ospf redist metric ip ospf redist metric-type ip ospf redist-filter ip ospf redist-filter effect ip ospf redist-filter metric ip ospf redist-filter route-tag ip ospf redist-filter redist-control classify qos flow timeout show policy classify destination interface type show policy classify source interface type

page 42 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Unsupported CLI Commands

RIP

Software Feature

VLANs

Chassis Supervision

Unsupported CLI Commands ip rip redist status ip rip redist ip rip redist metric ip rip redist-filter ip rip redist-filter effect ip rip redist-filter metric ip rip redist-filter route-tag ip rip redist-filter redist-control vlan router mac multiple enable|disable vlan binding mac-port-protocol vlan binding mac-ip vlan binding ip-port show fabric

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 43

Unsupported MIBs

Unsupported MIBs

The following MIBs are not supported in this release of the software:

MIB

Feature

Quality of Service (QoS)

Flow Control

IETF_P_BRIDGE

Alcatel

IND1Port

Unsupported MIB Variables

MIB Name

Alcatel

IND1AAA

Alcatel

IND1Bgp

Alcatel

IND1Dot1Q

Alcatel

IND1GroupMobility

Alcatel

IND1Health

Alcatel

IND1Ipms

Alcatel

IND1LAG

Alcatel

IND1Pcam

Alcatel

IND1Port

Unsupported MIB variables

aaauProfile alaBgpGlobal alaBgpPeerTable alaBgpAggrTable alaBgpNetworkTable alaBgpRedistRouteTable alaBgpRouteTable alaBgpPathTable alaBgpDampTable alaBgpRouteMapTable alaBgpAspathMatchListTable alaBgpAspathPriMatchListTable alaBgpPrefixMatchListTable alaBgpCommunityMatchListTable alaBgpCommunityPriMatchListTable alaBgpDebugTable qPortVlanForceTagInternal vPortIpBRuleTable vMacIpBRuleTable vMacPortProtoBRuleTable vCustomRuleTable healthDeviceTemperatureCmmCpuLatest healthDeviceTemperatureCmmCpu1MinAvg healthDeviceTemperatureCmmCpu1HrAvg healthDeviceTemperatureCmmCpu1HrMax alaIpmsForwardSrcIpAddr alaIpmsForwardSrcIfIndex alclnkaggAggEniActivate alclnkaggSlotTable alcatelIND1PCAMMIBObjects alaCoroL3HrePerModeTable alaCoroL3HrePerCoronadoStats

Table alaCoroL3HreChangeTable esmPortCfgLongEnable esmPortCfgRuntEnable esmPortCfgRuntSize esmPortPauseSlotTime esmPortCfgFLow alcether10GigTable page 44 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

MIB Name

Alcatel

IND1QoS

Alcatel

IND1Slb

Alcatel

IND1StackManager

Alcatel

IND1SystemService

Unsupported MIBs

Unsupported MIB variables

alaQoSPortPdiTable alaQoSSlotPcamTable alaQoSPortProtocolTable alaQoSSlotProtocolTable alaQoSSlotDscpTable alaQoSRuleReflexive alaQoSAppliedRuleReflexive alaQoSActionSourceRewriteIpAddr alaQoSActionSourceRewriteIpAddrStatus alaQoSActionSourceRewriteIpMask alaQoSActionTable alaQoSActionSourceRewriteNetworkGroup alaQoSActionTable alaQoSActionSourceRewriteNetworkGroupStatus alaQoSActionTable alaQoSActionDestinationRewriteIpAddr alaQoSActionTable alaQoSActionDestinationRewriteIpAddrStatus alaQoSActionTable alaQoSActionDestinationRewriteIpMask alaQoSActionTable alaQoSActionDestinationRewriteNetworkGroup alaQoSActionTable alaQoSActionDestinationRewriteNetworkGroupStatus alaQoSActionTable alaQoSActionLoadBalanceGroup alaQoSActionTable alaQoSActionLoadBalanceGroupStatus alaQoSActionTable alaQoSActionPermanentGatewayIpAddr alaQoSActionTable alaQoSActionPermanentGatewayIpAddrStatus alaQoSActionTable alaQoSActionAlternateGatewayIpAddr alaQoSActionAlternateGatewayIpAddrStatus alaQoSAppliedActionSourceRewriteIpAddr alaQoSAppliedActionSourceRewriteIpAddrStatus alaQoSAppliedActionSourceRewriteIpMask alaQoSAppliedActionSourceRewriteNetworkGroup alaQoSAppliedActionSourceRewriteNetworkGroupStatus alaQoSAppliedActionDestinationRewriteIpAddr alaQoSAppliedActionDestinationRewriteIpAddrStatus alaQoSAppliedActionDestinationRewriteIpMask alaQoSAppliedActionDestinationRewriteNetworkGroup alaQoSAppliedActionDestinationRewriteNetworkGroupStatus alaQoSAppliedActionLoadBalanceGroup alaQoSAppliedActionLoadBalanceGroupStatus alaQoSAppliedActionPermanentGatewayIpAddr alaQoSAppliedActionPermanentGatewayIpAddrStatus alaQoSAppliedActionAlternateGatewayIpAddr alaQoSAppliedActionAlternateGatewayIpAddrStatus alaQoSPortDefaultQueues alaQoSPortAppliedDefaultQueues alaQoSConfigNatTimeout alaQoSConfigAppliedNatTimeout alaQoSConfigReflexiveTimeout alaQoSConfigAppliedReflfexiveTimeout alaQoSConfigFragmentTimeout alaQoSConfigAppliedFragmentTimeout alaQoSConfigClassifyFragments alaQoSConfigAppliedClassifyFragments slbFeature slbClusterTable slbServerTableg alaStackMgrStatsTable systemUpdateStatusTable

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 45

Unsupported MIBs

MIB Name

Alcatel

IND1VlanManager

Alcatel

IND1WebMgt

IEEE_802_1X

IETF_BGP4

IETF_BRIDGE

IETF_ENTITY

IETF_ETHERLIKE

IETF_IF

IETF_IP_FORWARD_MIB

IETF_IPMROUTE_STD

IETF_MAU (RFC 2668)

IETF_OSPF (RFC 1850)

IETF_OSPF_TRAP

IETF-PIM

Unsupported MIB variables

vlanIpxNet vlanIpxEncap vlanIpxRipSapMode vlanIpxDelayTicks vlanSetMultiRtrMacStatus alaIND1WebMgtRFSConfigTable alaIND1WebMgtHttpPort alaIND1WebMgtHttpsPort vlanIpxStatus vlanSetIpxRouterCount dot1xAuthDiagTable dot1xAuthSessionStatsTable dot1xSuppConfigTable dot1xSuppStatsTable bgpRcvdPathAttrTable bgp bgpPeerTable bgp4PathAttrTabl dot1dTpPortTable dot1dStaticTable entLogicalTable entLPMappingTable entAliasMappingTable dot3CollTable dot3StatsSQETestErrors dot3StatsInternalMacTransmitErrors dot3StatsCarrierSenseErrors dot3StatsInternalMacReceiveErrors dot3StatsEtherChipSet dot3StatsSymbolErrors dot3ControlInUnknownOpcodes ifRcvAddressTable ifTestTable ipForwardTable ipMrouteScopeNameTable rpMauTable rpJackTable broadMauBasicTable ifMauFalseCarriers ifMauTypeList ifMauAutoNegCapability ifMauAutoNegCapAdvertised ifMauAutoNegCapReceived ospfAreaRangeTable ospfTrapControl pimRPTable page 46 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

MIB Name Unsupported MIB variables

IETF_P_BRIDGE

IETF_Q_BRIDGE (RFC 2674)

IETF_RIPv2

IETF_RMON

dot1dExtBase dot1dPortCapabilitiesTable dot1dPortPriorityTable dot1dUserPriorityRegenTable dot1dTrafficClassTable dot1dPortOutboundAccessPriorityTable dot1dPortGarpTable dot1dPortGmrpTable dot1dTpHCPortTable dot1dTpPortOverflowTable dot1qTpGroupTable dot1qForwardAllTable dot1qForwardUnregisteredTable dot1qStaticMulticastTable dot1qPortVlanStatisticsTable dot1qPortVlanHCStatisticsTable dot1qLearningConstraintsTable rip2IfConfDomain hostControlTable hostTable hostTimeTable hostTopNControlTable hostTopNTable matrixControlTable matrixSDTable matrixDSTable filterTable channelTable bufferControlTable captureBufferTable

IETF_RS_232 (RFC 1659)

IETF_SNMPv2

all synchronous and sdlc objects and tables rs232SyncPortTable sysORTable snmpTrap sysORLastChange snmpTargetAddrExtTable

IETF_SNMP_

COMMUNITY (RFC 2576)

IETF_SNMP_

NOTIFICATION (RFC 2576)

snmpNotifyTable snmpNotifyFilterProfileTable snmpNotifyFilterTable

IETF_SNMP_PROXY (RFC 2573)

snmpProxyTable

IETF_SNMP_TARGET (RFC 2573)

snmpTargetAddrTable snmpTargetParamsTable snmpTargetSpinLock usmUser

IETF_SNMP_USER_BASED_SM

(RFC 2574)

IETF_SNMP_VIEW_BASED_ACM

(RFC 2575)

vasmMIBViews

Unsupported MIBs

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 47

Open Problem Reports and Feature Exceptions

Open Problem Reports and Feature Exceptions

The problems listed here include problems known at the time of the product’s release. Any problems not discussed in this section should be brought to the attention of the Alcatel Technical Support organization as soon as possible. Please contact customer support for updates on problem reports (PRs) where no known workaround was available at the time of release.

Switch Management

Command Line Interface (CLI)

Problem Reports

PR 94134

Display of mobile ports by using the CLI “port range” command shows only the information about the first port in the range on an OS9000.

Workaround: The current CLI output for mobile ports is line based, which does not allow for a practical output of the port range. CLI command to display the mobile port should not use port range in the command.

PR 95896

On an OS9000, when user permissions are changed, they do not have an immediate effect.

Workaround: The Session Manager polls the servers (through AAA) every 5 minutes for changes in permissions. For an immediate impact, the administrator may remove the user from the switch to deprive the user from certain permissions. This way the new permissions are current when the user logs on again.

By the same token, whenever an administrator decides to remove a user from the switch, he/she should close all of the sessions to which the user is logged on.

PR 104635

Applying the non-hybrid version of the "interfaces" command to combo ports may result in an incorrect configuration on an OS6850.

Workaround: Use the hybrid command for combo ports and use the regular (non-hybrid) command for regular (non-combo) ports. For example, to set speed, use:

"interfaces <slot/port> hybrid fiber speed 100" for combo port.

"interfaces <slot/port> speed 100" for non-combo port.

PR 105168

When using the CLI "show ni" command, the display of XFP and SFP Model name and Description displays the manufacturer's name. These fields should display the Model Name and device description.

Workaround: There is no known workaround at this time.

page 48 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

PR 106811

Show interface slot/port "SFP/XFP" field output for a port having SFP plugged in cannot differentiate between 100Fx and Bidirectional SFP & between Gig and CWDM SFP on an OS6850.

Workaround: There is no known workaround at this time.

RMON

Problem Reports

PR 87683

On an OS6800/OS9000, the RMON object etherStatsPkts65to127Octs and other similar objects from RFC

1757 contain TX and RX packet counts.

Workaround: There is no known workaround at this time.

PR 106919

On an OS6850, it is not possible to disable all RMON probes with a single SNMP command.

Workaround: When using SNMP, disable each probe individually.

sFlow

Problem Reports

PR 100009

On an OS6850, sFlowCpTable and sFlowFsTable return data of zero when an existing NI is removed or powered down.

Workaround: There is no known workaround at this time.

PR 106130

The syntax for sflowReceiver and sFlowAgent returned by an OS9000 are not octets, but strings.

Workaround: There is no known workaround at this time.

PR 106878

When replacing an NI with a different type of NI, the sFlow configuration is not deleted correctly for the ports which do not exist anymore.

Workaround: Delete the sFlow configuration before swapping different NI types.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 49

Open Problem Reports and Feature Exceptions

PR 107462

Sflow Datagrams do not use the EMP port on a OS9000 for IPV4 packets.

Workaround: Use the ports on the slots.

SNMP

Problem Reports

PR 82635

On an OS9000, there is no display of the number or the status of fan modules on an OmniSwitch via

SNMP or WebView.

Workaround: The number and status of fans can be displayed via the CLI show fan command only.

PR 105290

SNMP and the WebView DVMRP --> Routes page does not display Route Flags.

Workaround: Use the CLI show ip dvmrp route command to display Route Flags.

PR 107059

WebView and SNMP queries may show more ports than those displayed by the CLI command "show tcp ports". The ports shown by the CLI command are valid.

Workaround: There is no known workaround at this time.

Web-Based Management (WebView)

Feature Exceptions

WebView uses signed applets for the automatic IP reconfiguration. Those applets are signed using

VeriSign Certificates that expire every year. The certificate used for Internet Explorer and Netscape expires every August. WebView users have to validate a warning indicating that the certificate used by the applet has expired.

Problem Reports

PR 85135

In WebView > Health > LED page, the XFP1 and XFP2 LEDS are not displayed.

Workaround: XFP1 and XFP2 LEDs are for realtime packet traffic activity indications. For precise reflection of the Rx/Tx activity, please refer to the corresponding Rx/Tx statistics all through the

WebView > Health pages.

page 50 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

PR 89084

For Partition Management, giving a user routing protocols permission, but no IP permission results in some table data not being displayed in the routing pages.

Workaround: Make sure a user gets permission for IP if the user is allowed to view any sort of IP routing protocol pages.

PR 96146

When viewing XOS adjacencies with multiple (2 or more) XoS devices connected to an OS9800 using

AOS WebView, will return unknown devices with build 4.4.4.188.B or greater which is correct behavior.

With earlier builds, the XOS adjacencies could be returned as an AOS device.

Workaround: There is no known workaround at this time.

PR 96274

On an OS9000, in WebView, Networking > IP Multicast > IPv4 > Switching > Configuration and

Networking > IP Multicast > IPv6 > Switching > Configuration pages show the actual configuration only, but not the effective configuration of the system in parenthesis of the Status, Querying, Spoofing, and

Zapping.

Workaround: Use CLI to view the effective configuration.

PR 99581

The “scp” command is not supported in WebView.

Workaround: There is no known workaround at this time.

PR 101446

WebView > Physical > Adjacencies home page may show an "Applet Not Found" error when the Java

Virtual Machine SDK version is less than 1.2.

Workaround: Upgrade the Java Virtual Machine browser plug-in to a more recent version.

PR 105205

Reloading the switch using in and at times fails in WebView.

Workaround: Use the CLI for timed reloads.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 51

Open Problem Reports and Feature Exceptions

PR 100607

Accessing WebView > Security > Servers using Netscape, a window may appear asking for user name selection on an OS6850 when adding a new server.

Workaround: Close the window and ignore. This window shown is not a WebView pop-up window but a

Netscape Form Manager window -- perhaps triggered by the "Server Name" label in the server add windows and being treated as if it was a regular form asking for a user name.

PR 106670

On an OS9000, the ipxServTable returns the name of the IPX SAP. This is a variable length name. The

SNMP standard specifies that variable length strings should be preceded by a length byte. Some SNMP applications could have problems with this.

Workaround: There is no known workaround at this time.

PR 106869

In WebView > Layer 2 > VLAN Mgmt > VLANs Add page, on an OS9000, an error message appears whenever user enters VLAN ranges to be created that include more than 63 VLANs at once.

Workaround: Break desired VLAN range to create into smaller ranges (63 or less). (Note: This configuration setting limit occurs all throughout WebView.)

PR 106914

In WebView System > System Mgmt > Install page, on an OS9000, the file transfer fails in a dual NIC

(Network Interface Card) environment.

Workaround: Momentarily disable the network of the NIC not in use for the transfer and re-enable after the transfer.

PR 107228

In WebView Physical > Health > Port Statistics page after clearing statistics, the last port of the slot may display values other than zeroes on an OS9000.

Workaround: Please ignore non-zero values. (Any non-zero values are still being cleared when the page is served.)

PR 107283

On an OS6850, when the supplicant fails the authentication with the external authentication server and if user configured a "failed" vlan on the device classification policy, then AOS is going to locally authenticate the supplicant. In CLI, the "show" command will show as authenticated-L to indicate that the supplicant failed by the external authentication server but is locally authenticated to be authorized into the user defined vlan. WebView is not showing this information and will only see as authenticated.

Workaround: Look at which vlan the supplicant is authorized and that can tell if the supplicant learned on the user defined "failed" VLAN.

page 52 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

PR 107284

Supplicant and non-supplicant are not displayed together on the same front page for 802.1x on an OS6850.

Workaround: View the non-supplicants on a different page - 802.1x non supplicant page. Display Issue

Only.

PR 107315

A duplicate slot in a stack of switches will not display the switch picture in the WebView > Chassis Mgmt

> Chassis homepage.

Workaround: Remove the duplicate slot.

PR 107529

WebView Networking > IP > BGP > Policy Route Maps Modify help "local Preference Value" hyperlink is broken.

Workaround: There is no known workaround at this time.

PR 107530

When using the Netscape browser to access the WebView > Policy > Policy > Ports page after clicking on either "Previous" or "Next" buttons and then clicking on the "Refresh" button, a "method not allowed" error is displayed.

Workaround: Click on the "Ports" menu to refresh.

Layer 2

Autonegotiation

Problem Reports

PR 86826

On an OS6800/OS9000, when autonegotiation is disabled and speed is forced to 10 Mbps, copper ports may confuse with a forced 100Mbps link partner and can detect a false link UP. Traffic may not pass in this condition.

Workaround: Enable autonegotiation for this copper port and configure desired speed and duplex settings.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 53

Open Problem Reports and Feature Exceptions

Bridging

Problem Reports

PR 86261

On an OS6800, Ethernet SNAP packets with non-zero Organizationally Unique Identifiers (OUI) will not be classified using port-protocol rule.

Workaround: If applicable, other rules should be used to classify such packets.

PR 94269

The OmniSwitch 9000 counts all error packets as unicast packets in the packets received and error counters, regardless of whether the packet is a unicast packet or a multicast packet. An oversized packet is defined as a packet longer than 9216 bytes. This causes the following behavior in the switch:

1) Received packets longer than 9216 bytes are counted as unicast packets AND as error packets even if the packet is a broadcast or multicast packet.

2) For ports operating at speeds of 10 Mbps or 100 Mbps, a packet is not counted as an error packet unless it is longer than 9216 bytes.

Workaround: There is no known workaround at this time.

PR 94866

Invalid Packets with SA or DA set to all 0's continue to get bridged by the system.

Workaround: There is no known workaround at this time.

PR 99331

On an OS6800, when protocol or subnet based mobility rules are deleted and created after a VLAN delete, the traffic coming in after this is not classified correctly.

Workaround: Delete the rule first before deleting the VLAN.

PR 99899

On an OS6800/OS6850, binding rules that require a port number to be specified as part of the rule can no longer be deleted if the port is not set to be mobile.

Workaround: Make the port mobile before deleting the rule.

page 54 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

Ethernet Interfaces

Problem Reports

PR 93114

It is not possible to broadcast or multicast oversized ingress packets. Therefore, ingressing oversized layer

2 multicast packets are treated as unicast packets.

Workaround: There is no known workaround at this time.

PR 94866

Invalid packets with SA or DA set to all 0s continue to be bridged by system.

Workaround: There is no known workaround at this time.

PR 95125

On an OS9000, the throughput on a 1 Gbps or 10 Gbps port might be 99.998%. This is due to a variance in the oscillator; the clocking can differ by a few PPM. This variance is accepted by the IEEE standard.

Workaround: There is no known workaround at this time.

PR 95526

On an OS9000, if the admin status of the physical interface is toggled while sending high rates of traffic on the 10G interface, some CRC errors are reported on the host connected to the interface.

Workaround: There is no known workaround at this time.

PR 105079

On OS6850 combo copper ports, the link will toggle once when the SFP is plugged in the corresponding fiber cage.

Workaround: There is no known workaround at this time.

PR 105080

If a Gig Copper SFP is plugged into a combo port on an OS6850, then those combo ports can be used in forced mode only. To use a copper combo port, then set the mode to Forced-Copper. To use the Gig copper SFP in the corresponding copper port, then set the mode of the port to Forced-Fiber.

Workaround: There is no known workaround at this time.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 55

Open Problem Reports and Feature Exceptions

PR 105789

The ifMauTable returns object with out of range values for 10 Gig ports on an OS9000. A get call to

IETF_MAU MIB ifMauAutoNegSupported object returns a value of 0 (zero) for 10 Gig ports. Value 0

(zero) is out of range because only two values 1 (Autoneg supported) and 2 (Autoneg not supported) are part of this object.

Workaround: There is no known workaround at this time.

PR 105847

On OS6850-U24x board combo ports with default media preference (i.e. Preferred-Fiber) and with 100M

Fiber SFP (Avago HFBR-57E0PZ), the link on fiber combo ports doesn't come up if copper cable is plugged in the corresponding copper ports and the copper link is UP.

Workaround: On OS6850-U24x board combo ports, 100M Fiber SFP (Avago HFBR-57E0PZ) can get a link with fiber cable in Forced-Fiber mode only.

PR 106041

On OS6850-U24x combo ports, if two OS6850-U24x boxes are connected back to back in Preferred-Fiber mode with copper cable on copper combo ports and no cable on corresponding fiber ports then if the mode of those ports is changed to Force-Fiber mode then LEDs of copper ports stay ON even though the link on those copper ports go down. The LED's on copper media are turned off once the fiber side has a link.

Workaround: Once the fiber media gets a link, the copper media LED is turned off.

PR 106783

If fiber combo ports containing dual speed SFPs of two OS6850-U24X units are connected back to back in

Preferred-Fiber mode with no connection on corresponding copper ports, and if you change the modes of these ports in a sequence to Preferred-Copper first and then to Forced-Copper, the LEDs on those Fiber ports stay ON even though the link goes down.

Workaround: There is no known workaround at this time.

PR 108631

MIB Walk of HybridPort fails on OS6850 Lite 48port having combo ports (both upgraded and nonupgraded version).

Workaround: There is no known workaround at this time.

page 56 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

Group Mobility

Problem Reports

PR 98417

When a MAC is learned on an OS6850 as "Filtered" for one port due to a Group Mobility rule violation, and if the MAC reappears on another port, it will not be updated. The MAC will not be shown as filtered for the new port, but will continue to show filtered in the old port.

Workaround: There is no known workaround at this time.

PR 98661

When using MAC based group mobility rules for VLAN classification on an OS6800/OS9000, some entries are not inserted into the MAC VLAN table. This results in the frame not being classified.

Workaround: If this condition occurs on the mobile port, admin down and up the mobile port.

PR 107326

When the admin state of VLAN 1 is toggled between disable/enable on an OS6850, it is possible to have mobile ports stuck in a blocking state.

Workaround: If this condition occurs on the mobile port, admin down and up the mobile port.

IP Multicast Switching (IPMS)

Problem Reports

PR 95057

On an OS6850/9000, the IPv6 Multicast Switching Spoofing feature is not replacing the clients' MLD packets' source IPv6 address with the switch's IPv6 address. The Spoofing feature is replacing the clients'

MLD packets' source MAC address with the switch's MAC address.

Workaround: There is no known workaround at this time.

PR 98869

On an OS6800, egressing IP Multicast traffic onto a mobile VLAN from a 6800's mobile port will not remove the 802.1Q frame.

Workaround: There is no known workaround at this time.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 57

Open Problem Reports and Feature Exceptions

PR 99269

An IGMPv3 or MLDv2 membership report with an exclude filter containing 0.0.0.0 or :: in the source list will potentially disrupt IP Multicast Switching and Routing for the particular group membership being reported.

Workaround: Neither 0.0.0.0 or :: are valid source addresses. They should not be used in source filters.

PR 105039

When Proxying in IPMS is enabled on an OS9000, IGMPv3 and MLDv2 reports generated by the system on behalf of clients are not aggregated; rather IGMPv3 and MLDv2 reports are generated containing a single record.

Workaround: There is no known workaround at this time.

Link Aggregation

Problem Reports

PR 90656

The same actor admin key assigned for two different dynamic link aggregates could cause ports to join wrong aggregates.

Workaround: Assign unique actor parameters for each configured dynamic link aggregate.

PR 100537

If the link aggregation state is changed on an OS6850, the config sync status shows incorrectly as synchronised. This will result in the NI's going down on takeover.

Workaround: Issue the copy working certified flash-synchro command and then do a takeover.

Port Mirroring/Monitoring

Problem Reports

PR 86338

An OS6800/OS9000 preserves the INGRESS tag format of the packet for EGRESS mirroring, which makes the mirror packet go out tagged though the real egress packet is not tagged.

Workaround: There is no known workaround at this time.

page 58 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

Source Learning

Problem Reports

PR 83087

On an OS6800/OS9000, the MAC aging time can take up to twice the configured value.

Workaround: There is no known workaround at this time.

PR 94127

On an OS9000, in the Hardware learning mode, the source MACs from control packets (BPDUs) are learned.

Workaround: There is no known workaround at this time.

PR 94180

On an OS9000, in the default learning mode, a MAC address will still be learned as a “bridging” entry instead of the “filtering” entry when it matches the QoS Drop rules. However, the actual packet is being discarded so the operation is functional.

Workaround: The switch could be configured to use “software” learning mode.

PR 94181

On an OS9000, if a QoS rule is set on a port to drop all traffic and if LPS is configured on the same port, no MACs are learned as part of LPS, as all the traffic is dropped.

Workaround: There is no known workaround at this time.

PR 94515

On an OS9000, on the port which has learned port security enabled, the first packet is not forwarded. Once this packet is validated, subsequent packets are forwarded without any problem.

Workaround: There is no known workaround at this time.

PR 94646

On an OS9000, the MAC address of an untagged packet does not get learned in the default VLAN with

"filtering" and with "accept only" tagged frames.

Workaround: There is no known workaround at this time.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 59

Open Problem Reports and Feature Exceptions

PR 95322

On an OS9000, duplicate MAC is not learned as the "filtered" mode, if the entry has already been configured as a permanent entry on a different port. The side effect is that the packet with this MAC from a different port would still be forwarded or flooded.

Workaround: There is no known workaround at this time.

PR 96264

On an OS9000, in dynamic link aggregation, even when the link aggregation is in admin state “disable”, the individual ports of the link aggregation exchange LACP packets. Therefore, the MACs from these packets are learned due to hardware learning.

Workaround: There is no known workaround at this time.

PR 97310

On an OS6850, some MAC addresses get flushed from the CMM when the primary port of a link aggregate moves from one NI to another. The total count on the NI is correct.

Workaround: Set the source learning aging time value to a small value.

PR 97670

When the source learning mode is changed on an OS6850, sometimes the number of MACs learned may not be displayed accurately although all the MACs are actually learned.

Workaround: The display count should catch up after one aging time has elapsed.

PR 98053

In an OS6800 Learned Port Security trap, only the IP address of the EMP port of the switch is provided (if the switch has an EMP port) and not the IP address of the offending entity.

Workaround: There is no known workaround at this time.

PR 100761

On an OS9000, disabling a linkAggr port while traffic is running might leave some MAC addresses learned on the primary member port of the linkAggr.

Workaround: Administratively down all ports that transmit across the linkAggr or link down/up the primary port after disabling the link aggregate.

page 60 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

PR 100932

Removing the last member port of a linkAggr while traffic is running can result in MAC addresses learned on that port in the default VLAN of the linkAggr.

Workaround: Administratively down all ports that transmit across the linkAgg or link down/up the port after removing it from the linkAggr.

PR 105399

When the OS9000 chassis is operating under the distributed mode of source learning and the traffic from slots egressing link aggregation on different slots and the ingress and egress traffic are asymmetric, traffic is flooded instead of unicast bridged.

Workaround: Configure the source MAC as static or use link aggregation on the same slot.

PR 106194

On OS6800 and OS6850 stacking platforms, a takeover reboots both the old primary CMM and NI. If traffic is coming on this NI, a 'port-security <slot/port> maximum x' command taking affect when it comes back up could result in different MACs being filtered. The effect is the new secondary has the new MACs filtered but the new primary has both the old and new set of MACs filtered. This is why the need to flush out that particular port before the rule takes effect again.

Workaround: If this occurs, then explicitly configure which MACs should be allowed via the

port-security <slot/port> mac command.

PR 106462

When an OS9000 switch has less than 16K MAC address learned and 2 more slots receive data with MAC addresses simultaneously that lead to more than 16K mac on the switch, the CMM displays all the MAC's learned on each NI.

Workaround: There is no known workaround at this time.

PR 106533

On OS9000, when STP converges, MACs may not be flushed on ports that go to blocking. This will result in traffic disruption until MAC ages out.

Workaround: Wait until MAC ages or perform a manual MAC flush.

PR 106781

On OS9000, sometimes max 16k macs do not learn across linkagg in chassis-distributed.

Workaround: Do not use chassis-distributed mode with linkagg and many MACs.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 61

Open Problem Reports and Feature Exceptions

PR 107231

A stack of 3 OS6850's (slots 1 & 2 are 48 ports and slot 3 is 24 ports) with a mobile port of 1/35 (Second

Asic on Slot 1) and a binding mobile rule. A MAC violating is programmed as filtered. Now, this filtered

MAC is programmed on all slots. However, since there is only one ASIC on Slot 3, there is an error and the address is not programmed as filtered on slot 3.

Workaround: There is no known workaround at this time.

Spanning Tree

Problem Reports

PR 89316

A BPDU packet with the Root BridgeID of 0xffff...is sent out with every link-up to elicit a BPDU reply from the adjacent switch in the current Auto-Edge Detection mechanism.

Workaround: There is no known workaround at this time.

PR 90297

On an OS6800/OS9000, CST Root convergence in 802.1s may be slow due to the circulation of old ‘good’ spanning tree vectors in the network when a root switch is powered off.

Workaround: 1) Use single MSTP region as much as possible. 2) Tune the performance parameters maxAge and hop count to optimal values for the network.

PR 95308

Temporary traffic loops could happen under the following scenarios:

1. Reloading of a non-root bridge.

This happens when the bridge is going down and is due to the sequential bringing down of NIs during a reload process. It is purely temporary in nature and stops when all the NIs eventually get powered off.

2. NI power down

When an NI power down command is executed for an NI and if that NI has the Root port and other NIs have Alternate ports, it is possible to see some traffic looping back from the newly elected Root port. The traffic loop back is temporary and will stop once the NI gets powered off.

3. New Root bridge selection

Temporary loops could occur during the process of electing a new Root bridge, if this election process is triggered by the assignment a worse priority for the existing root bridge or a root bridge failure. This happens due to the inconsistent spanning tree topology during the convergence and stops entirely once the network converges.

page 62 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

Workaround: For items 1 and 2 above, there is no known workaround at this time. For item 3, the following workarounds could be applied:

1. Tune the max age (and or max hops in the case of MSTP) parameter to a lower value that is optimal for the network. This will reduce the convergence time and thereby the duration of temporary loops.

2. To select a new root bridge, consider assigning better priority for that bridge instead of assigning worse priority for the existing root bridge.

PR 96358

On an OS9000, during a Spanning Tree reconvergence triggered by link up/down or board power up/ down, the DVMRP subsystem may print the following error message: "dvmrpRecvProbe, Looping back our probes".

This happens only if the Spanning Tree protocol selected is RSTP and is caused by rapid transitions of port states. It has been verified that the problem does not happen for switched VLAN traffic. So there is no chance of a real loop in the network. Packets handled in software might experience the problem due to larger transit delays, but does not cause any malfunction.

Workaround: There is no known workaround at this time.

PR 100356

During boot-up, a Link aggregate port can momentarily become forwarding before blocking, causing

BPDU and dynamic MACs to be learned on that port. The dynamic MACs could potentially remain learned on the Link aggregate port for some time, resulting in traffic disruption.

Workaround: Manually flush the MACs learned on the blocked port or admin down/up the blocked port.

PR 101214

Toggling the edge port of an OS9000 the very first time after boot-up may cause a TCN to occur in the

STP (1d) network.

Workaround: Configure the port as an edge port instead of an autoEdge port or configure the switch to run in RSTP (1w) protocol.

PR 105493

Enabling Spanning Tree on an OS9000 in flat mode after disabling does not work when VLAN 1 is disabled.

Workaround: Enable VLAN 1, enable STP and disable VLAN 1.

Step1: disable Spanning Tree -> vlan 1 stp disable

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 63

Open Problem Reports and Feature Exceptions

PR 105788

Some STP entries in the 802.1D standard mib may return out of range or undefined values on an OS9000.

This is because we are returning the true values of a newer version of STP (802.1Q 2005), not 802.1D

1998 that the MIB is based on. When a new standard MIB is defined, we can obsolete the old version.

Workaround: There is no known workaround at this time.

PR 106106

STP may return a hello time of 0 on SNMP queries on disabled instances after an OS9000 has been running for some time.

Workaround: There is no known workaround at this time.

PR 106513

On an OS9000, STP can display the wrong port as the next best port. The next best port is not actually used in topology calculation and has no effect on the network.

Workaround: There is no known workaround at this time.

VLAN Stacking

Problem Reports

PR 102958

On an OS9000, setting SVLAN priority using "vlan svlan priority" command may not work properly.

Workaround: Use the QoS command to trust all VLAN Stacking ports, and use QoS policy to configure

SVLAN priority.

PR 106514

Deleting a large range of SVLANs will sometimes result in an STP error message about the SVLAN status on an OS9000.

Workaround: Delete the SVLANs in a smaller range of VLANs.

PR 107054

An error message is received on an OS6850 console after assigning a range of tagged vlans to an aggregate from CLI.

Workaround: This message can be ignored since it does not affect the actual assignment of the VLANs in the range.

page 64 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

Layer 3

Basic IP Routing

Problem Reports

PR 94621

In most cases, routed packets needing fragmentation due to a smaller IP MTU on the egress network will not be fragmented and will be forwarded as-is.

Workaround: There is no known workaround at this time.

PR 106913

On OS6800 and OS6850, exceeding 20K routes in the FIB can cause system instability, especially if they are all on the same VLAN.

Workaround: Reconfigure the switch such that the number of routes in the FIB do not exceed 20K.

PR 106931

Some objects in alaIpNetToMediaTable return wrong data type (counter, instead of integer).

Workaround: There is no known workaround at this time.

DHCP Snooping

Problem Reports

PR 100435

On an OS6850, a mobile port with incoming DHCP traffic is able to have a DHCP binding created for it but it is not shown in the Binding Port Table.

Workaround: There is no known workaround at this time.

PR 106730

After DHCP Snooping is enabled against the VLAN on OS6850, adding the q-tag port to the VLAN, the newly added q-tag port is not shown in the DHCP Snooping port list.

Workaround: Added the q-tag port to the VLAN first, then enable DHCP Snooping against the VLAN.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 65

Open Problem Reports and Feature Exceptions

PR 106814

When DHCP Snooping is enabled against mobile port, sometimes the mobile port's VLAN ownership is not reflected in the DHCP Snooping port table.

Workaround: There is no known workaround at this time.

PR 106977

When DHCP Snooping is enabled, binding entry is not created against the new root port when STP topology is changed.

Workaround: There is no known workaround at this time.

PR 107186

For DHCP Snooping feature, the CLI should not allow user to configure ip-source-filtering on a trusted port. However, if the port is a member of a link aggregate, the CLI does not display an error and allows the configuration.

Workaround: Make sure the port is not a member of a link aggregate before configuring the ip-sourcefiltering.

IPv6

Problem Reports

PR 86669

On an OS6850/OS9000, IPv6 Router Advertisement decrementing timers are not supported for prefix valid lifetimes or prefix preferred lifetimes.

Workaround: Use IPv6 Router Advertisement fixed timers.

PR 91228

An OS6850 does not detect IPv6 port scanning or other IPv6 denial of service attacks.

Workaround: There is no known workaround at this time.

PR 94546

An OS9000 does not make use of the MTU interface configured via the IPv6 interface command and only supports the port MTU. Therefore, even if the configured IPv6 interface MTU is smaller, packets will still be forwarded instead of being dropped and “a packet too big” message returned to the sender. This can cause problems with path MTU discovery.

Workaround: There is no known workaround at this time.

page 66 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

PR 96061

On an OS6850/OS9000, the IPv6 implementation does not follow ICMPv6 RFC 2463 section 2.2 Message

Source Address Determination in regard to anycast addresses. Instead IPv6 uses any unicast address configured on the switch.

Workaround: A node that sends an ICMPv6 message has to determine both the source and destination

IPv6 addresses in the IPv6 header before calculating the checksum. If the node has more than one unicast address, it must choose the source address of the message as follows:

"If the message is a response to a message sent to a multicast or anycast group in which the node is a member, the source address of the reply must be a unicast address belonging to the interface on which the multicast or anycast packet was received.

PR 99374

On an OS6850, the SNMP alaIPv6NeighborState MIB object has been deprecated. It is replaced by alaIPv6NeighborReachability.

Workaround: All SNMP management previously done using the alaIPv6NeighborState object should switch to the new alaIPv6NeighborReachability object.

PR 105893

A ping6 initiated on an OS9000 to one of its own addresses will succeed, even if the interface on which the address is configured is disabled or inactive.

Workaround: There is no known workaround at this time.

PR 106826

In certain circumstances, on an OS9000, the RIPng routing table (as shown by the "show ipv6 rip routes"

CLI command) may display an inactive gateway for redistributed routes (i.e. routes redistributed "into"

RIPng).

In the RIPng routing table, the gateway shown is the gateway which was active when the route was originally redistributed into RIPng. If the original gateway becomes inactive at a time when other active gateways for the route exist, the RIPng routing table will not be updated to display the new gateway. As a result, the RIPng routing table may display a gateway which is not currently active even though the route is still active via other gateways.

Workaround: The active gateway for all routes (redistributed and otherwise) is available in the IP routemanager routing table. Use the show ipv6 router database CLI command to display the IP route-manager routing table.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 67

Open Problem Reports and Feature Exceptions

PR 106213

When using "configuration apply" to apply routing configuration to an OS6850 system that has completed its boot up, parts of the configuration may fail with a "system busy" error.

Workaround: 1) Ensure that the protocol is manually loaded prior to applying the configuration file. For example,

> ipv6 load ospf

> configuration apply ospf3.asc.1

2) (Optional) After configuring the protocol, use a "write memory" to commit the changes to the boot up configuration file.

Server Load Balancing (SLB)

Problem Reports

PR 105700

For SLB clusters on OS9000, there are no statistics or flow distribution metrics on a server basis. The only server statistic is the number of packets passed to a cluster.

Workaround: There is no known workaround at this time.

PR 107490

When executing a “show ip slb cluster <clustername>” CLI command on a non-existing SLB cluster name more than 23 characters long, an “slbCtrl” STR is generated. However, no adverse conditions are seen with the switch.

Workaround: There is no known workaround at this time.

UDP Relay

Problem Reports

PR 97666

TCP does not send an RST after receiving an unacceptable ACK in SYN-RCVD state on OS6800 and

OS6850.

Workaround: There is no known workaround at this time.

page 68 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

PR 106942

On OS9000, statistic display of ip-helper (DHCP) and Generic UDP relay are mixed together, but complete statistical information is present.

Workaround: There is no known workaround at this time.

PR 107204

If the user defines a UDP service and does not assign a VLAN to that service, the service does not show up on the Webview display but does appear when using the CLI to display services.

Workaround: There is no known workaround at this time.

VRRP

Problem Reports

PR 106943

Due to a coding incompatibility, standard SNMP managers will not be able to perform Get, GetNext, Test, or Set Operations on objects in the alaVrrp3AssoIpAddrTable found in the proprietary

AlcatelIND1VRRP3.mib.

Workaround: For VRRPv2, the parameters controlled through these objects can be managed through the vrrpAssoIpAddrTable in the IETF_VRRP.mib (RFC 2787), as well as through WebView and the CLI. For

VRRPv3 the parameters controlled through these objects can be managed via WebView and the CLI.

Advanced Routing

BGP4

Problem Reports

PR 103524

If there are more than 185 BGP redistribution filters configured in a boot.cfg file from an earlier release on an OS6850 or OS9000, they are not consistently translated into IPRM route-maps that handle the redistribution.

Workaround: Do not attempt to restore more than 185 redistribution filters from a boot.cfg file generated from an earlier release.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 69

Open Problem Reports and Feature Exceptions

DVMRP

Problem Reports

PR 100130

On an OS6800, when interfaces from two different routers that are physically attached to the same network are changed from native DVMRP interfaces to DVMRP tunnel interface on-the-fly or vice versa, the multicast traffic will stop being routed across this path.

Workaround: Disable DVMRP before making the change, and then re-enable it again.

OSPF

Problem Reports

PR 106790

On OS9000, the forwarding address of AS-External LSA (corresponding to gateway of redistributed route) is not updated when there is a change in the OSPF route to the forwarding address, due to deleting OSPF interface configuration.

Workaround: 1) Disable and Enable OSPF admin status after deleting OSPF interface configuration, if redistributed route's gateway was reachable on that OSPF subnet. 2) Disable and Enable IPRM route-map that redistributes routes into OSPF, after deletion of OSPF interface configuration.

OSPFv3

Problem Reports

PR 104078

The route table in OSPFv3 cannot be retrieved via SNMP on an OS9000. There is no support for retrieving the OSPFv3 route table in the official IETF draft MIB for OSPFv3. Displaying the OSPFv3 border router table is also not supported in the IETF draft MIB. This affects all hardware platforms that support

OSPFv3.

Workaround: The CLI can display the routing table (show ipv6 ospf routes) and border router table

(show ipv6 ospf border-routers) for OSPFv3.

page 70 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

PR 105491

Existing inter-area-prefix and inter-area-router LSAs are not originated into areas that are created after initial convergence of the network on an OS9000. For example, the router is running and it originates a set of inter-area-prefix or inter-area-router LSAs into all known areas. Later, another area is added, the new area will not have any of the inter-area-prefix or inter-area-router LSAs that exist in the other areas prior to the creation of the new area.

Workaround: When adding an area to OSPFv3 after it has been running for a while, it should be globally disabled and then re-enabled using the "ipv6 ospf status disable/enable" command.

PR 105770

Point-to-point interfaces are not supported in OSPFv3 at this time; therefore, 6to4 tunnels cannot be used with OSPFv3.

Workaround: There is no known workaround at this time.

PR 107353

OSPFv3 will leak memory in either of the following two cases on an OS9000: 1) During SPF runs. 2)

During adjacency formation.

Workaround: There is no workaround that will eliminate this leak. However, it's effect can be somewhat mitigated by trying to minimize the causal events (namely SPF calculations and new adjacency formations) between reboots.

PIM

Problem Reports

PR 102501

Currently, there is no support for an "ip unload" command. This can be a problem for customers who have loaded a DRC loadable module and executed a "write memory" command to update the boot.cfg file. Then decided that they wanted the module permanently removed.

Workaround: To permanently disable a module, execute the module's "disable" command followed by another "write memory" command and a reboot. To also free up any memory possibly used by the disabled module, edit the boot.cfg file using the "vi" command to delete the "ip load <module>" command along with any non-default configuration lines associated with the module.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 71

Open Problem Reports and Feature Exceptions

PR 106343

High multicast traffic rate on an OS6850 running PIM-SM where the RP is on a remote switch may cause high CPU utilization. This is due to the packets being PIM register-encapsulated which are software routed. The high data rate is causing the Register Stop packets to be dropped. Once the Register Stop packets are received, the register-encapsulation will stop and native forwarding will take over.

Workaround: Avoid register-encapsulation by configuring the RP to be on the same switch as the source.

Quality of Service (includes ACLs)

General

Problem Reports

PR 105380

If there is no arp entry for the destination, routed traffic matching a drop policy gets dropped in software by the CPU instead of being dropped by the OS6800.

Workaround: There is no known workaround at this time.

PR 105496

Rules that match multicast traffic do not get logged properly on an OS9000.

Workaround: There is no known workaround at this time.

PR 105764

Due to the method QoS handles condition groups (network, services, etc.), the flushing of conditions corrupts the linkages between the condition and the groups. The condition remain attached to the SLB cluster. However, the group pointers in the condition are invalid. Because of this, the group parameters are restricted.

Workaround: There is no known workaround at this time.

PR 107091

On OS9000, QoS currently will not accept names of 23 character from SLB.

Workaround: Use names of 22 characters or less.

PR 107190

SLB will return an error if the configured ping period is out of range on an OS9000. However, the ping period will still be updated.

Workaround: Change the ping period to a correct value.

page 72 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

PR 107232

On OS9000, if a condition is associated with an SLB cluster and a policy rule, it can be deleted in a flush.

Workaround: Create separate conditions for SLB and policy rules.

Policy Manager

Problem Reports

PR 94083

Policies, which specify a destination slot/port or destination port group will not be applied to traffic which is routed by the switch, these policies will match only bridged traffic.

Workaround: There is no known workaround at this time.

PR 94125

The OS9000 and OS6850 does not support QoS or ACL rules containing destination port, destination

VLAN, or destination MAC on traffic that is routed by the OS9000 or OS6850.

Workaround: There is no known workaround at this time.

PR 95249

On an OS9000, the 802.1p value of IP packets is set to 0. On trusted ports, the 802.1p is not altered for non-ip packets. For IP packets, the prioritization is per the TOS value. The 802.1p is also restamped to reflect the ingress TOS precedence value. If the TOS value is 0, the 802.1p is set to 0.

Workaround: Use QoS 802.1p stamping policies, which match on ingress the 802.1p value, to retain the ingress 802.1p. For example: policy condition c 802.1p 1 policy action a 802.1p 1 policy rule r condition c action a qos apply

PR 99336

On an OS6800, QoS policies which specify ethertype do not match SNAP or 802.3 Raw packets. QoS policies only support Ethernet-II packet format.

Workaround: The policy will match traffic which matches the policy criteria even if the packet is not

Ethernet-II if the policy specifies only one of the following: source slot/port, destination slot/port, source

MAC or destination MAC.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 73

Open Problem Reports and Feature Exceptions

PR 99931

When tagging a link aggregate on an OS6850, QoS does not trust the individual ports of the link aggregate.

Workaround: Manually set the trust bit of the underlying ports through QoS (qos port <slot/port> trusted), or set the port default to trusted (qos trust ports).

PR 99983

The OS6850 switch cannot boot up properly with a boot.cfg that exceeds the QoS limitation. It is not recommended to manually edit the boot.cfg to configure your QoS. Booting up with a boot.cfg obtained from a "write memory" is fine.

The hardware allocation checking is not done during boot up causing QoS configurations to be out of sync with the hardware capability.

Workaround: To prevent the boot.cfg from going beyond the QoS limitations on a large QoS configuration, proceed as follows: edit a text file with your desired qos configuration, apply the configuration using

"configuration apply text_file", and save the boot.cfg using "write memory".

PR 101223

On an OS6800, if a policy rule specifies the keyword "log" or "log interval", then the policy is rejected.

Workaround: Logging is not supported by the OS6800. The keyword "log" and "log interval" has to be removed from the policy rule definition.

Security

General

Problem Reports

PR 89262

NESSUS reports bogus “Vulnerabilities”. Basically, NESSUS collects all those known attacks/vulnerabilities into their test suites.

For example, NESSUS sends: http://<switch-address>/cgi/bin/guestbook.cgi

WebView/HTTP-Server’s response: Prompts user for the default switch login page (which is the normal operation for our embedded server).

Since our HTTP server replies with some form of an HTTP response, NESSUS mistakenly concludes that the HTTP server is vulnerable to this attack.

Workaround: There is no known workaround at this time.

page 74 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

PR 91681

On an OS9000, the following is noted when running a test called "alya.cgi (Backdoors)" in the NESSUS test suite:

Security Note: Web mirroring - http (80/tcp)

The following CGI have been discovered:

Syntax: cginame (arguments [default value])

/web/content/login.html (userName [] password [] B1 [Login])

Workaround: This is the expected behavior for the login pages for WebView and Web-AVLAN authentication. NESSUS is known to provide those bogus reports.

PR 95642

On an OS9000, the Denial of Service testing tool (NESSUS) generates bogus reports.

Workaround: There is no known workaround at this time.

PR 107176

OS6800 may incorrectly show the router-mac address as the source of a DoS attack.

Workaround: There is no known workaround at this time.

802.1x

Problem Reports

PR 98375

On an OS6850, DHCP rules are not being used to classify traffic on a regular group mobility port. For this reason, with a matching DHCP rule, Device Classification policy will not consider matching a DHCP rule as having a matching GM rule when the policy is applied.

Workaround: There is no known workaround at this time.

PR 99658

On an OS6850, not all MAC addresses will be learned when testing with a traffic generator to simulate traffic with incremental MAC addresses.

Workaround: There is no known workaround at this time.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 75

Open Problem Reports and Feature Exceptions

PR 100189

On an OS6850, when the MAC address table is full, source learning will not learn MAC addresses dynamically and the non-supplicant table will show more entries because the tables are not synchronized.

Workaround: There is no known workaround at this time.

PR 100614

On an OS6850, when a device is moved from one 802.1x port to another 802.1x port, the device is not classified according to the device classification policy that applies to the new port but is learned on the default VLAN for the new port.

Workaround: Reconfigure the new port by disabling and enabling 802.1x on the port. May also have to reconfigure the device classification policy for the new port as well.

PR 106463

The CLI command “802.1x initialize <slot>/<port>” only applies to the supplicants on the specified port.

All the supplicants are forced to authenticate again. Non-supplicants on the same port are not affected; no re-classification for non-supplicants is required when this CLI command is used.

Workaround: There is no known workaround at this time.

Authenticated Switch Access

Problem Reports

PR 91812

On an OS9000, the server information displayed with the show configuration snapshot aaa command or saved with the configuration snapshot aaa <file_name> command contains hashed (encrypted) password/key information. In order for a file created with the latter command to be used for configuring servers, password/key information needs to be edited. AAA expects this information encrypted only at boot-up time while at run time the information should be in plain text. In this particular case, the servers created with configuration apply command could not be used because password/key information is wrong.

Workaround:

Always edit password/key information before applying a snapshot file.

PR 106557

SNMP MIB walk on aaaAcctCmdTable returns empty even when the table is set.

Workaround: There is no known workaround at this time.

PR 107085

Accounting log for scp-sftp displays user IP address as 0.0.0.0 on an OS6850.

Workaround: There is no known workaround at this time.

page 76 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

Authenticated VLANs

Problem Reports

PR 87642

On an OS6800, the CLI command to specifically disable 802.1x or AVLAN authentication on a port will disable either of the authentication options configured on the port.

Workaround: There is no known workaround at this time.

PR 98369

DHCP is not supported with port-binding AVLANs on OS6800/OS6850. When DHCP packets are used to trigger the port binding rules, none of the rules work.

Workaround: There is no known workaround at this time.

PR 106976

When DHCP Snooping's IP Source Filtering is enabled on the Authenticated VLAN port of an OS6850, the authentication (via Telnet or HTTP) will fail.

Workaround: Cannot enable IP Source Filtering on AVLAN ports, since IP Source Filtering (work as expected) is blocking the IP traffic.

Policy Server Management

Problem Reports

PR 103324

An OS6850 will not change the IP address automatically even if the supplicant client is running that can automatically do the ipconfigure release and renew when dynamically changing classification policy when an IP net rule is configured. Depending on what traffic is running, some packets may satisfy the IP net rule and the supplicant will be classified according to the IP net rule.

Workaround: User has to be aware that when the IP net rule is configured and when dynamically changing the classification policy that as group mobility as one of the classification option, traffic from supplicant may still have the old IP address on the vlan that the supplicant was classified before the policy is changed. The IP net rule will cause the client to be learned on the vlan that it was previously learned on.

E.g. supplicant is learned on vlan x and has an IP address with vlan x's subnet. There is also an IP net rule for vlan x's IP to be classified on vlan x. When user dynamically changes the classification policy, the supplicant may still be learned on vlan x because the PC has traffic coming out with VLAN x's subnet and thus device classification task will classify the supplicant on VLAN x again.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 77

Open Problem Reports and Feature Exceptions

PR 107086

User with readwrite-scp-sftp privileges is initially queried for authentication and authorization on an

OS6850. After login to the scp/sftp shell, only accounting requests are sent to TACACS+ server (if enabled), commands are not queried for authorization.

Workaround: There is no known workaround at this time.

PR 107278

SNMP variable policyStatsQueryCount always show as zero.

Workaround: See policyStatsAccessCount instead.

PR 107543

If Loopback0 is defined by the user and there is not a physical route for that IP subnet, a RADIUS client will not be able to communicate with a RADIUS server. As a result, RADIUS authentication will fail as the server is unreachable.

Workaround: There is no known workaround at this time.

System

General

Problem Reports

PR 86853

A stack of 9 or greater is not supported on an OS6800 or OS6850.

Workaround: The maximum stack elements is 8.

PR 93114

If an ingress packet is oversized, it is not for broadcast or multicast anymore. As a result, ingressing oversized layer 2 multicast packets are counted as unicast packets.

Workaround: There is no known workaround at this time.

PR 97213

On an OS9000, in all CPU exceptions, a Trace Buffer dump is offered at the beginning of the exception.

Workaround: There is no known workaround at this time.

page 78 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

PR 99862

When an over stressed test caused 100% CPU usage on an OS6850, the "Unable to send running checksum" message was displayed, and the switch was rebooted.

Workaround: Avoid 100% CPU usage.

PR 100127

By default, an OS6850 switch is configured to run in strict-priority. If over-subscription is done on priorities 6 & 7, it will bring down the switch.

Workaround: Over-subscription on priorities 6 & 7 is not yet supported on the switch. Do not configure the over subscription with priority 6 or 7.

PR 105381

The flash file system on an OS6850 shows no space but allows copy anyway.

Workaround: Remove any unneeded files before performing copy.

PR 105646

The entPhysicalModelName MIB variable returns vendor name of SFP instead of model name for an

SNMP get/getNext call to this object on an OS6850.

Workaround: There is no known workaround at this time.

PR 106559

Output to STDOUT is re-directed to the PMD file on an OS9000. A printf is occurring that causes the

“show log” command to fail.

Workaround: The contents of the pmd file can still be viewed with vim, gvim, etc. as most of the contents are ascii strings.

PR 106812

The "update default miniboot" is still supported on OS6850 even though there is no default or backup miniboot.

Workaround: This command will still cause the miniboot to be updated properly.

PR 106649

The “update miniboot” command is not working on OS-9000.

Workaround: Use the “update uboot-miniboot” command to update the miniboot.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 79

Open Problem Reports and Feature Exceptions

PR 107139

In a stacked system on an OS6850, if the redundant cable is absent, the primary module could be one of the elements with a higher slot ID on a reboot of the system.

Workaround: Use the stacking cables and provide complete redundancy.

PR 107276

Swlog does not allow the user to select the TCP destination port. By default, the fixed port of 514 is selected on both OmniVista and the AOS switch. On some setups, the OmniVista port needs to be changed and the switch can not send to this new port.

Workaround: Use the default TCP port setting of OmniVista or set a third party syslog server to port 514.

PR 107033

When port 1/1 on the system has software learning enabled...either by the port being mobile or authenticated and if there is a linkagg configured on the switch, the internal mac 0x0020da999999 is seen in the output of show mac-address table learned as being learnt on port 1/1.

Workaround: There is no known workaround at this time.

Chassis Supervision

Problem Reports

PR 94404

Mixing OS7000 and OS9000 CMMs in any chassis is not supported.

Workaround: There is no known workaround at this time.

PR 95320

On an OS9000, the Unix mv command does not update a file's time stamp. Therefore, the check sum will not detect the change.

Workaround: Use the cp command instead.

PR 96225

On an OS9000, the "+++ i2cReadRemoteCMM: Error writing starting address!" error message is seen on the secondary after the primary crashes and a takeover is in progress. However, the system functions normally and takeover still occurs.

Workaround: There is no known workaround at this time.

page 80 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

PR 96327

Extra display character in the swlog. No effect on the switch.

Workaround: There is no known workaround at this time.

PR 96584

On an OS9000, during a reload, when the fabric LED is turned off and on, there is no effect on the switch.

Workaround: There is no known workaround at this time.

PR 98768

If hardware configuration changes are introduced to an OS6800/6850 stack without first ensuring that the

Primary software configuration is certified, it is possible to create an endless synchronization cycle.

Workaround: Before making any hardware configuration changes ensure that the Primary is certified.

Run the copy working certified flash-syncro command before making hardware configuration changes.

PR 98956

An OS6850 supports only single point of failure. Removing multiple stacking cables will introduce multiple points of failure from which the system may not recover.

Workaround: Do not remove multiple stacking cables at the same time.

PR 100244

Installing 6.1.3.R01 images on an OmniSwitch 6800 that is running 5.3.1.R02 code returns an error.

Workaround: The code base has changed significantly from 5.3.1 to 6.1.2. This is especially true of

Jos.img. So the install from 5.3.1 will not be able to support them. Reboot the 6.1.2 images and then do the install.

PR 100825

On an OS9000, if both CMMs are removed from the chassis, Layer 2 local (local to the NI) traffic with learned MACs is switched.

Workaround: Insert at least one CMM into the switch to reset the NIs.

PR 103625

Pulling all the cable simultaneously on a stack of 8 OS6850's causes problem.

Workaround: When pulling the cable, the system will start its topology change. Pull the cable one by one during the topology change will lose the topology information. Try to pull the cable slowly to avoid this problem.

OmniSwitch 6800/6850/9000—Release 6.1.3.R01

page 81

Open Problem Reports and Feature Exceptions

PR 104874

If CPU is at 100% on an OS6800, then the commands "copy working certified" or "copy working certified flash-synchro" can make the system timeout and the primary will crash with pmd. The timeouts are printed on the screen. So, the user can know when it timeouts. User has to be aware of the copy from working to certified process.

Workaround: Prevent doing a copy working certified or copy working certified flash-synchro if high

CPU or remove CPU load.

PR 106941

Processing for CMM MIB variable chasTempRange not correct for non-primary slots on OS6800.

Workaround: There is no known workaround at this time.

PR 106975

If a WINTEK compact flash is installed on an OS6850, WINTEK is not displayed when you use the show hardware info command.

Workaround: There is no known workaround at this time.

PR 107619

NI 1 becomes non-primary in a OS6850 stack after “reload stack” if NI 1 is an OS6850 Lite.

Workaround: There is no known workaround at this time.

Power Over Ethernet

Problem Reports

PR 99583

OS6850 POE units support either 510 or 360 Watt power supplies. If unlike power supplies are mixed, or if an unsupported power supply, such as a 120-Watt power supply are used, a console message and a trap are generated.

Workaround: There is no known workaround at this time.

page 82 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

PR 106065

During the execution of the "update lanpower all" command, it is possible that the update of an individual port on the OS9800 may fail with a message similar to the following example for slot 14:

FRI OCT 06 11:51:55 : LANPOWER (108) info message:

+++ Shutting down daughter module in slot 14!

call failed: RPC: Success

PD63000 Programming Failed Slot #14!!!.

Workaround: Execute a lanpower update for the specific slot which failed.

PR 106121

Currently the test portion of the OS9000 lanpower start command checks available power before any attempt is made to activate.

Workaround: There is no known workaround at this time.

PR 106791

The non-default value of 230 watts is not saved for the 510 watt power supply when performing "write memory" or "configuration snapshot..." on an OS6850.

Workaround: Manually modify resulting configuration file.

PR 106906

Users may over allocate power from the available power supply in Power Shelf powered applications on

OS9000. PoE Power Shelf and PoE

Port Guidelines clearly state the user procedures for calculation of appropriate steps for calculation of blade power requirements based on port power requirements, and total power requirements for the system.

Redundancy and power supply calculation is also provided.

Workaround: There is no known workaround at this time.

PR 106978

Currently PoE configurations are not deleted after a P24 blade is removed from OS9000 chassis.

Workaround: If a P24 blade is to be permanently removed from a chassis, then no action is necessary. If a P24 blade is removed, a different blade is substituted and then at some later time a P24 blade is again placed in the same slot position, either the original configurations for the P24 blade must be changed or deleted (this is the preferred method) or the configuration file may be edited (this should only be performed by an individual extremely familiar with configuration files and PoE configuration as the

ENTIRE unit configuration may be changed, or damaged).

page 83 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

PR 107287

During "update lanpower all" on a stack of 8 OS6850-P24/48, you might see the following error message:

THU OCT 12 14:06:27 : LANPOWER (108) error message:

+++ Unable to Read S19 Response!

Reset Daughter Module!

Done

THU OCT 12 14:48:59 : LANPOWER (108) error message:

+++ Unable to Read BOOT_SECTION_RESPONSE Response!

+++ General Programming Error!

Workaround: Do a "lanpower start" on the NI which failed the firmware update. Once lanpower failed to start which is expected, you then try to "update lanpower <slot>" again on that specific NI.

Redundancy / Hot Swap

Hot Swap Time Limitations for OmniSwitch 9000

All removals of NI modules must have a 30 second interval before initiating another hot swap activity.

All insertions of NI modules must have a 3 minute interval before initiating another hot swap activity.

All hot swaps of CMM modules must have a 10 minute interval before initiating another hot swap, reload or takeover activity.

All takeovers must have a 10 minute interval before following with another hot swap, reload or takeover activity.Problem Reports

Problem Reports

PR 91287

After takeover, the new primary CMM does not keep the DOS statistics held by the previous primary

CMM.

Workaround: There is no known workaround at this time.

PR 95840

The whole chassis will reload if more than half of NIs are hot swapped in and out of the chassis at roughly the same time.

Workaround: If hot swap of NIs is required, a user may have to wait until a previous NI has been booted first, and then hot swap the next NI.

page 84 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Open Problem Reports and Feature Exceptions

PR 96011

On an OS9000, NIs will not reset on an unsynchronized takeover if those NIs are manually reset between configuration change and takeover.

Workaround: There is no known workaround at this time.

PR 98992

The copy working certified flash-synchro command display takes a long time on an OS6800 switch.

OS6800 does not support tffs (true flash file system) but

OS6850

does. So an OS6800 switch takes much longer whenever there is an operation related to file operation.

Workaround: There is no known workaround at this time.

PR 106872

Upon unsynchronized takeover in Fuji 16 slot chassis, some NIs don't come up gracefully after resetting.

Workaround: Power cycle the NIs that are not UP and ready.

page 85 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

Technical Support

Technical Support

Alcatel technical support is committed to resolving our customer’s technical issues in a timely manner.

Customers with inquiries should contact us at:

Region

North America

Latin America

Europe

Asia Pacific

Other International

Phone Number

800-995-2696

877-919-9526

+33-388-55-69-04

+65-6586-1555

818-878-4507

Email: [email protected]

Internet: Customers with Alcatel service agreements may open cases 24 hours a day via Alcatel’s support web page at: http://eservice.ind.alcatel.com.

Upon opening a case, customers will receive a case number and may review, update, or escalate support cases on-line. Please specify the severity level of the issue per the definitions below. For fastest resolution, please have telnet or dial-in access, hardware configuration—module type and revision by slot, software revision, and configuration file available for each switch.

Severity 1 Production network is down resulting in critical impact on business—no workaround available.

Severity 2 Segment or Ring is down or intermittent loss of connectivity across network.

Severity 3 Network performance is slow or impaired—no loss of connectivity or data.

Severity 4 Information or assistance on product feature, functionality, configuration, or installation.

page 86 OmniSwitch 6800/6850/9000—Release 6.1.3.R01

advertisement

Related manuals

advertisement