Page 1
BitStorm™ 2400
User’s Guide
Document No. 2400-A2-GB20-10
December 2002
Page 2
Copyright © 2002 Paradyne Corporation.
Al l rig h t s res erve d.
Printed in U.S.A.
Notice
This publi cation is protected by feder al copyright law. No part of this publication may be copied or distributed,
transmitt ed, tr anscri bed, stor ed in a retrie v al syst em, or tr anslat ed into an y human or comput er langu age in any form or
by any mea ns, electronic, mechanical, magnetic, manual or ot herwise, or disclosed to th ird parties without the express
written permission of Paradyne Corporation, 8545 126th Ave. N., Largo, FL 33773.
Par adyne Corporation makes no representa ti on or warranties with respect to the cont ents hereof and specifically
disclaims any implied warranties of merc hantability or fitness for a particular purpose. Further, Paradyne Corporati on
reserves the right to revise this publicati on and to make changes from time to time in the contents hereof without
obligation of Paradyne Corporation to notify any person of such revision or changes.
Changes and enhancements to the product and to the information herein will be documented and issued as a new
release to this manual.
W arranty, Sales, Servi ce, and Training Information
Contact yo ur loc al sal es r eprese ntati v e, service r epresent ativ e , or dist ribut or di rectl y f or any h el p needed. F or addi tio nal
informati on concerning warranty , sales, service, repair, installation, documentation, training, distributor locations, or
Paradyne worldwide office locations, use one of the following methods:
!
Internet: Visit the Paradyne World Wide Web site at www.paradyne.com. (Be sure to register your warranty at
www.paradyne.com/warranty.)
!
Telephone: Call our automated system to receive current informatio n by fax or to speak with a company
representative.
— Within the U.S.A., call 1-800-870-2221
— Outside the U.S.A., call 1-727-530- 2340
Document Feedback
We welcome your comments and suggestions about this document. Please mail them to Technical Publications,
Par adyne Corporati on, 8545 126th Ave. N., Lar go, FL 33773, or send e-mail to userdoc@paradyne.com. Include the
number and title of this document in your correspondence. Please include your name and phone number if you are
willing to pro vide additional clarification.
Trademarks
ACCULINK, COMSPHERE, F rameSaver , Hot wir e, MVL, NextEDGE, OpenLane, and Performance Wizard are
registered trademarks of Paradyne Corporation. BitStorm, EtherLoop, GrandVIEW, ReachDSL, StormTracker,
Spectrum Manager, StormPort, and TruePut are trademarks of Par adyne Corporation. All other products and services
mentioned herei n are the trademarks, service marks, register ed trademarks, or registered service marks of their
resp ective own ers.
A
December 2002 2400-A2-GB20-10
Page 3
Contents
About This Guide
Document Purpose and Intended Audience . . . . . . . . . . . . . . . . . . . . v
!
Document Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
!
Product-Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
!
Reference Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
!
1 BitStorm 2400 Overview
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
!
Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
!
EtherLoop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
!
Data Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
!
Token Bucket. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Spectrum Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
!
Traffic Aggregation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
!
Layer 2 CoS Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
!
Priority Queuing Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
!
Switching Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Downstream Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Upstream Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
VLAN Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
!
Secure VLAN Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Multicast Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
!
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Multicast Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
!
Multicast Group Membership Management. . . . . . . . . . . . . . . . . . 1-10
Multicast Traffic Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
Multicast IP Address and MAC Address Mapping . . . . . . . . . . . . . . . . 1-10
!
IGMP Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
!
Join Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Membership Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Membership Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Leave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
2400-A2-GB20-10 December 2002
i
Page 4
Contents
IGMP Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
!
IGMP V1 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
IGMP V2 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
IGMP V1 an d V2 Co-existence . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Summary of IGMP V2 Message Formats . . . . . . . . . . . . . . . . . . . 1-13
Multicast Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
!
IGMP Report Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
IGMP Leave Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Group-to-Interface Table Processing. . . . . . . . . . . . . . . . . . . . . . . 1-15
MAC Layer Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
!
2 Terminology and Conventions
System Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
!
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
3 Using th e A s yn chronous Terminal I n terface
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
!
Navigating Menu Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
!
Logging In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
!
Main Menu Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
!
Switch Configuration Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
!
Port Statistics Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
!
Configuration File Upload/Download Screen . . . . . . . . . . . . . . . . . . . . 3-7
!
Image File Download Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
!
Serial Configuration Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
!
Change Password Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
!
Configure EtherLoop Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
!
4 Using the Web Interface
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
!
Web Interface Login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
!
Configuring the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
!
ii
December 2002 2400-A2-GB20-10
Page 5
Management Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
!
Switch Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Port Configuration/Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Serial Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Password Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Notifica tion (Traps). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
!
SNMP Targets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
SNMP Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
Spanning Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
!
Spanning Tree Bridge Parameters . . . . . . . . . . . . . . . . . . . . . . . . 4-18
Spanning Tree Port Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
VLANs/Multicast Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
!
Current VLAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
Static VLAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
VLAN/GVRP (GARP VLAN Registration Protocol) Port
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Current Multicast Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
Static Multicast Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
GARP/GMRP Port Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
Contents
A Monitoring and Troubleshooting
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
!
BSNMP Traps
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1
!
C MIB Support
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
!
SNMP Addressing Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2
!
MIB-II (RFC 1213) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2
!
SNMPv2-MIB (RFC 1907) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-3
!
System Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-3
sysDescr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-3
sysObjectID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-3
SNMP Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-4
2400-A2-GB20-10 December 2002
iii
Page 6
Contents
Bridge-MIB (RFC 1483) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-5
!
dot1dBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-5
dot1dBaseNumPorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-5
dot1dTp Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-6
RMON-MIB (RFC 1757). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-6
!
P-Bridge-MIB (RFC 2674) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-7
!
Q-Bridge-MIB (RFC 2674) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-7
!
EtherLike-MIB (RFC 2665). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-8
!
dot3StatsTable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-8
TMS-Common-MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-9
!
OEM-BCM-5600-MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-9
!
IF-MIB (RFC 2233). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-10
!
SNMP-Framework-MIB (RFC 2571) . . . . . . . . . . . . . . . . . . . . . . . . . . C -10
!
SNMP-MPD-MIB (RFC 2572) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-10
!
SNMP-Target-MIB (RFC 2573) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-11
!
SNMP-Notification-MIB (RFC 2573) . . . . . . . . . . . . . . . . . . . . . . . . . . C-11
!
SNMP-User-Based-SM-MIB (RFC 2574) . . . . . . . . . . . . . . . . . . . . . . . C-11
!
SNMP-View-Based-ACM-MIB (RFC 2575) . . . . . . . . . . . . . . . . . . . . . C-11
!
Index
iv
December 2002 2400-A2-GB20-10
Page 7
About This Guide
Document Purpose and Intended Audience
This guide contains information necessary for the use of the asynchronous
terminal interface and web interface, in addition to SNMP and MIB information, for
the BitStorm 2400 IP DSLAM, Model 2461.
This release of the User’s Guide adds clarifications to certain procedures.
The successful user of this manual has experience with the installation and
configuration of EtherLoop and DSL network devices, especially those used in
Multi-T enant Unit (MTU)/Multi-Dwelling (MDU) applications.
Document Summary
Section Description
Chapter 1, BitStorm 2400
Overview
Chapter 2, Terminology and
Conventions
Chapter 3, Using the
Asynchronous Terminal
Interface
Chapter 4, Using the Web
Interface
Appendix A,
Troubleshooting
Appendix B,
Appendix C,
Index
Monitoring and
SNMP Traps
MIB Support
Provides an introduction to the capabilities and
features of the BitStorm 2400.
Defines terms used in this manual and in the product’s
user interfaces.
Explains how to use the asynchronous terminal
interface.
Explains how to use the web interface.
Describes how to monitor the system and diagnose
problems.
Describes the SNMP Traps supported.
Describes the MIBs and objects suppor ted.
Lists key terms, concepts, and sect ions in alphabetical
order.
2400-A2-GB20-10 December 2002
v
Page 8
About This Guide
A master glossary of terms and acronyms used in Paradyne documents is
available online at www.paradyne.com. Selec t
Technical Glossary
Product-Related Documents
Complete documentation for this product is availa ble online at
www.paradyne.com. Select
Document Number Document Title
Support → Technical Ma nuals →
.
Support → Technical Manuals
.
2400-A2-GN20
1020-A2-GN70
EMS-A2-GB20
To order a paper copy of a Paradyne document:
Within the U.S.A., call 1-800-PAR ADYNE (1-800-727-2396)
!
Outside the U.S.A., call 1-727-530-8623
!
Reference Documents
Document Number Document Title
BitStorm 2400 Install ati on G uide
Describes how to install and configure the BitS torm 2400.
This guide is shipped with the unit.
StormPort DSL Modem Installation Sheet
Describes how to instal l the StormPort DSL Modem,
Models 620 and 1020. These instructions are included
with the modem.
StormTracker EMS 2.3 User’s Guide
Explains how t o use the St ormTrack e r EMS and descri bes
the options available. This guide is available online.
IEEE 802.3z 1000BaseX
RFC 2571 Arch SNMP
RFC 826 ARP
RFC 2597 Assured Forwardi ng PHB
RFC 1493 Bridge MIB
RFC 2475 DiffServ
RFC 2474 DiffServ Field
– EtherLoop MIB
IEEE 802.3 Ethernet
RFC 1643 Ethernet MIB
vi
December 2002 2400-A2-GB20-10
Page 9
Document Number Document Title
RFC 2068 HTTP
RFC 2236 IGMP v2
RFC 1122 Internet Hosts
RFC 791 IP
IEEE 802.3ad Link Aggregation
RFC 2668 MAUs
RFC 2572 Messages SNM P
RFC 1212 MIB
RFC 1213 MIB II
RFC 2233 MIB SMI v2
RFC 2674 MO for Bridges 802.1D/q
RFC 2665 MOs Ethernet-like
About This Guide
IEEE 802/1D/p Priority Queuing
RFC 1757 RMON (groups 1,2,3,9)
RFC 1889 RTP
– Small Form-f actor Pluggable (SFP) Transceiver MultiSource
Agreement (MSA)
RFC 2573 SNMP Apps
RFC 1157 SNMP v1
RFC 1907 SNMP v2
RFC 2574 SNMP v3
RFC 1902 SNMPv2 structure
RFC 1906 SNMPv2 transport mappings
RFC 793 TCP
RFC 1155 TCP/IP
RFC 854 Telnet
RFC 783 TFTP
RFC 768 UDP
RFC 2575 VACM SNMP
IEEE 802.1Q VLAN Tagging
2400-A2-GB20-10 December 2002 vii
Page 10
About This Guide
viii
December 2002 2400-A2-GB20-10
Page 11
BitStorm 2400 Overview
Overview
The BitStorm™ 2400 is an IP DSLAM contained in a 1RU rack-mountable
enclosure. It provides 24 channels of dedicated EtherLoop™ transport. Each
channel provides up to 10 Mbps of dedicated bandwidth depending on loop length.
The BitStorm 2400 IP DSLAM interfaces with a router or switch on the WAN side,
and StormPort™ CPE modems on the LAN side. Features available within the
BitStorm 2400 are accessible via SNMP software, such as StormTracker™ EMS.
The BitStorm 2400 IP DSLAM combines the following in one device:
1
Layer 2+ switching
!
Element management
!
Provisioning
!
Integrated Gigabit Ethernet switch links
!
EtherLoop DSL
!
Figure 1-1. BitStorm 2400 IP DSLAM
02-17144
2400-A2-GB20-10 December 2002
1-1
Page 12
1. BitStorm 2400 Overview
Features
Based on EtherLoop technology, the BitStorm 2400 IP DSLAM has the following
features:
Compact size (height = 1RU)
!
Shelf-mountable (up to eight units high) and rack-mountable
!
Low price per port
!
Up to 24 ports 10 Mbps EtherLoop
!
— Data Rate Limiting (downstream 64 kbps increments provided by CPE)
— Standby mode (CPE initiates training to prevent line noise)
Spectrum Management
!
Traffic Aggregation
!
Traffic Management
!
QoS Suppor t
!
Dual Gigabit Ethernet fiber and copper por ts for WAN uplinks or stacking
!
Robust Layer 2+ Ethernet switching capability
!
Line speed switching
!
Multicast controls and IGMP snooping
!
CoS and QoS
!
— 802.1D/p Priority Queuing
— 802.1D Transparent Bridging/Spanning Tree
— 802.1Q VLAN Tagging (256 VLANs)
— Secure VLAN mode
Full integrated management
!
— MIB-II, Ether-Like, RMON (4 Groups), BRIDGE, P-BRIDGE, Q-BRIDGE,
and Enterprise MIBs (SNMP v1/v2/v3)
— Fully supported by StormT racker EMS 2.3/2.4
— Web browser interface
— Terminal interface via the CRAFT port or Telnet
1-2
December 2002 2400-A2-GB20-10
Page 13
EtherLoop
EtherLoop, like Ethernet, is a “burst-mode” technology – it transmits only when
there is information to send. In contrast, conventional copper access technologies
maintain constant signal, regardless of whether or not there is information to send.
Because EtherLoop is not always transmitting, it has the opportunity to “listen” to
the loop. Each EtherLoop-based modem has built-in Spectrum Manager™. This
innovative feature measures the spect ral environment of the loop, analyzes the
results, and identifies potential interference. Becaus e EtherLo op is agile in
frequency, the modem can adjust its frequency away from the interference source.
Based on this unique patented capability, EtherLoop can be deployed without
restriction in accordance with ANSI T1.417 Spectrum Management standard.
Data Rate Limiting
Data Rate Limiting allows service providers to offer various levels of service to
subscribers. Each discreet level of service translates into an
upstream/downstream maximum data rate (MDR) and maximum burst (MB)
values. Service levels can be offered in units of 64 kbps steps of upstream or
downstream bandwidth.
1. BitStorm 2400 Overview
Token Bucket
Maximum upstream/downstream burst limits shall be provisioned as the maximum
number of bytes that may be transmitted in a burst of traffic before the rate limiting
will take ef fect. Maximum burst size sho uld typ i ca ll y b e some multiple of the
respective MDR value. Example: A user who has a downstream MDR of 512 kbps
could be allowed a maximum burst size of 192 kbps (MB = 3 * MDR/second). The
aggregate upstream and downstream MDRs should not exceed the actual
bandwidth available on the EtherLoop circuit. SNMP traps may be set to monitor
EtherLoop line rates that fall be low specified rate limit.
Data Rate Limiting is set up using SNMP software, such a s Storm Tracker EMS. It
is implemented by a Token Bucket mechanism on the transmit scheduler. The
Token Bucket will be a counter representing the number of “in policy” bytes of data
that may be transmitted. Tokens will be adde d to the bucket at the rate of MDR/8
per second .
The Token Bucket will have a maximum value (size) equal to the MB parameter.
Tokens will be added to the bucket until the point that the MB value has been
reached. Once the bucket is “full” the refresh tokens will overflow and not
accumulate in the bucket.
Frames will be a dmitted to the transmit queue only if there are enough tokens
available in the bucket based on the byte length of the frame to be transmitted.
Tokens will be removed from the buck et as frames are passed to the output queue.
“Out of P olicy” frames (frames for which there are insufficient tokens available)
arriving at the transmit process will be dropped.
2400-A2-GB20-10 December 2002 1-3
Page 14
1. BitStorm 2400 Overview
Spectrum Manager
Spectrum Manager operates within the StormTracker EMS software and makes
EtherLoop spectrally compatible with asymmetrical services such as ADSL and
G.Lite, detecting and protecting against interference within the same binder. In
addition, EtherLoop in its native state is spectrally compatible with sym m etrical
digital services such as T1, HDSL, HDSL2, or SDSL.
Although Spectrum Manager capabilities may seem like rate-limiting features, they
are simply spectral management functions. The primar y benef it of spectral
management is that the lower upstream frequency (imposed by protect modes)
causes little or no interference with downstre am frequency or other ser vic es in a
binder, thus reducing crosstalk.
Table 1-1, Spectrum Manager Modes, shows the various modes in which
Spectrum Manager operates.
Table 1-1. Spectrum Manager Modes
Mode Description
Native EtherLoop operates without the analysis of other service activity in th e
individual loops.
Monitor Spectrum Manager analyzes other services in the loop that may limit
Forced EtherLoop provides optimum spectrally compatible performance with
Auto-Protect EtherLoop operat es in an Asymmetric Mode if asymmetric interf erers
Video-Protect EtherLoop operat es in a forced Asymmetric Mode with guaranteed
Traffic Aggregati on
The integrated Layer 2+ BitStorm 2400 IP DSLAM aggregates the traffic to and
from the gigabit Ethernet interfaces. It operates as a multi-port Layer 2+ Ethernet
bridge per the IEEE 802.1D/802.1Q specifications. The BitStorm 2400 IP DSLAM
and EtherLoop lines suppor t the forwarding of IEEE 802.1 Q tagged VLANs and
selective IP multicast forwarding (via IGMP Snooping).
EtherLoop perf ormance.
asymmetric services in the ind ividual loop that may tempor arily affect
EtherLoop’s upstream capability. In this mode, EtherLoop is forced to
“mimic” asymmetric DSL.
are present. EtherLoop returns to normal upstream operations once
the interference is gone.
high downstream bandwi dth for the delivery of streaming video
applications.
1-4
December 2002 2400-A2-GB20-10
Page 15
Layer 2 CoS Support
Traffic management allows for the proactive management of bandwidth allocation.
By provisioning bandwidth management policies, classifying traffic, and applying
traffic shaping, users receive smooth and predictable service.
The integrated Layer 2+ has the ability to recognize flows based on Layer 2 packet
information including:
IEEE 802.1p prio rity information in tagged frames
!
Source MAC Address
!
Destination MAC Address
!
IEEE 802.1 Q VLAN id e nt ifiers
!
Additional traffic management features and IP QoS functions will be added in
future releases.
1. BitStorm 2400 Overview
Priority Queuing Support
The BitStorm 2400 and StormPort CPE modems are enabled to recognize and
respond to IEEE 802.1D priority classifications. This standard is also known as the
IEEE 802.1p, which is a subsection of th e IE EE 802.1D standard. The 802.1p
priority bits information is carried in a 3-bit field in the IEEE 802.1Q tag.
The CO and CPE modems inspect and classify packets based on the IEEE 802.1p
priority field value. IEEE 802.1p defines 8 levels of priority (0-lowest to 7-highest).
The CO and CPE modems map these priority levels to one of two output queues
(high and low). The Ethernet Ports map these priorities to one of four output
queues (lowest, low , high, highest). This mapping complies with the recommended
mapping in the IEEE 802.1D-1998 standard. The mapping is configurable and may
be set to meet specific implementation standards.
Once traffic has been allocated to the output queues of the CO and CPE modems,
they will be serviced according to strict priority (picked from high until empty). Note
that this process is observed for packets in the downstream direction from the CO
and the upstream direction for the CPE (EtherLoop is a point-to-point connection
that preserves packet order so priority output queuing processes do not have to be
re-run on the receiving device).
Switching Fabric
The Ethernet Switching fabric in the BitStorm 2400 recognizes and responds to
IEEE 802.1D priorit y classi fications. This standard is also known as the IEEE
802.1p which is a subsection of the 802.1D standard. The 802.1p is carried in a
3-bit fie ld in th e IEEE 8 02.1Q tag. The BitStorm 2400 classifies fra me s b as e d on
the presence and code points (values) of priority information in the IEEE 802.1Q
tag.
2400-A2-GB20-10 December 2002 1-5
Page 16
1. BitStorm 2400 Overview
Downs tre am Tra ffic
Upstream Traffic
In downst re am tra ffic, frames with IEEE 802.1D priority code points of 4 to 7 are
directed to the high priority queue. Frames without IEEE 802.1Q tags and tagged
frames with priority codepoints of 0 to 3 are directed to the low pr ior ity queue.
The output frame schedulers on the BitStorm 2400 picks frames from the high
priority queue ahead of any frames on the low priority queue. The low priority
queue may ove rflow due to lack of servicing by giving preference to the high
priority queue. This may result in frame loss in the event of a high volume of high
priority frames. The loss of frames will be reported to the management plat form.
In upstream traffic, the EtherLoop StormPort CPE modems define high and low
priority output queues. Frames with IEEE 802.1D priority codepoints of 4 to 7
should be directed to the high priority queue. Frames without IEEE 8 02.1Q tags
and tagged frames with priority codepoints of 0 to 3 should be directed to the low
priority queue.
The output frame scheduler on the StormPort CPE picks frames from the high
priority queue ahead of any frames on the low priority queue. The low priority
queue may ove rflow due to lack of servicing by giving preference to the high
priority queue. This may result in frame loss in the event of a high volume of high
priority frames. The loss of frames is reported to the management platform.
VLAN Support
Additionally, there is a setting in the VLAN/GVRP Port Configuration screen of the
web interface that allows you to set priority for untagged frames. The default is 0,
but can be changed if necessary.
VLAN was introduced to control traffic flows on a physical network. A VLAN
defines a group of systems connected into a logica l broadcast domain. This
reduces overall LAN traffic and improves security . A VLAN can be created to serve
any purpose. The BitStorm 2400 system will implement VLAN me chanism s that
support the IEEE 802.1Q spec ificat ion.
Virtual LANs (VLANs) have been widely accepted and implemented in Ethernet
networks as a means to control everything from broadcast storms to security
issues to quality of service parameters and many other creative uses.
In its simplest form, VLAN support is a way to partition a switch or multiport router
such that it creates two or more broadcast domains. Generally users and devices
within a broadcast domain or VLAN may communicate freely with each other.
Communication across VLANs is enabled and controlled via a router or layer 3
switch.
Historically , VLAN capabilities were developed by individual switch and router
manufacturers and served the needs of only a specific class of devices from that
manufacturer. In recent years, the IEEE has standardized VLAN implementations
to enable a more consistent approach to VLAN mechanisms and to enable
interoperability among various components and equipment from different
manufacturers.
1-6
December 2002 2400-A2-GB20-10
Page 17
1. BitStorm 2400 Overview
The VLAN standard IEEE 802.1Q deals with the creation and management of
VLANs on many types of devices. One of the main features of this standard is the
adoption of a new Ethernet frame format that includes a ‘tag’ to carry VLAN and
packet prioritization information. This tag adds 4 bytes to the standard Ethernet
frame. The tag itself is optional, i.e., it may or may not be present on any given
frame. A major implication of the new frame format is that the maximum valid
Ethernet frame size has been increased from 1518 bytes to 1522 bytes. The
increase in the maximum valid frame size is an issue of possible concern for older
(non-VLAN-aware) devices which may have had limits on the acceptable frame
sizes.
Dest MAC@ Source MAC@ L/Type Data FCS
Dest MAC@ Source MAC@ L/Type Data FCSVLAN T ag
TPID 0x'8100' TCI
Priority VIDC
02-17292
Figure 1- 2. Standard Ethernet Frame Format and Extended Format with I EEE
802.1Q Tagging
VLAN support involves:
VLAN Membership Management
!
Forwarding
!
VLAN membership can be based on the following:
EtherLoop Subscriber Interfaces
!
Ethernet or GigE Ports on the BitStorm 2400
!
Explicit tagging of traffic by end devices
!
VLAN support requires the implementation of the following operations:
VLAN Creation
!
VLAN Frame Forwarding
!
Ingress and Egress filtering & forwarding rules
!
Tagging and un-tagging frames as required
!
VLAN support is explicitly implemented at both the BitStorm 2400 and the
EtherLoop StormP ort modems. Each component operates as a VLAN enabled
multiport bridge.
2400-A2-GB20-10 December 2002 1-7
Page 18
1. BitStorm 2400 Overview
Secure VLAN Mode
The BitStorm 2400 also extends a secure VLAN mode in the web interface for
port-to-port security. In this mode, Etherloop ports can only communicate talk with
the WAN side of the net work .
When a VLAN is in secure mode, packets received on member ports are
redirected to the uplink port (25) and not switched to other members. Conversely,
when a VLAN is not in secure mode, the member ports share packets as in a
nor mal VLAN .
VLAN secure status can be toggled with an SNMP browser (or the web interface )
by setting the private->enterprises->wrs->t ms->id b->gar pMib->garpMIBO bjects ->
gDot1qVlanStaticSecureTable->gDot1qVlanStaticSecureEntry->gDot1qVlanStatic
SecureRowStatus object to active(1) (or the integer 1) or notInServ ice(2) (or the
integer 2). However, you must create and delete static VLA Ns through the
standard VLAN mibs. This can be set up through the VLAN setting instructions
documented in the
Multicast Overview
StormTracker EMS 2.3 User’s Gui d e
.
Multicast support is provided by the BitStorm 2400 to deal efficiently with IP
multicast packets received from sources from the GigE link or from a locally
connected source. The primary applica tion of IP multicast traffic is to deliver
content to one or more users with a single IP stream.
IP multicasts are used for many po pular applications including:
Stock Ticke r and news feeds (Pointcast)
!
Video and Audio streaming (broadcast like services over the IP network – Real
!
Media)
Some ‘Near’ Video on Demand servers (e.g., movies that start every
!
15 minutes)
Voice over IP (VoIP) conference calling features
!
Multipoint conference applications (Net Meeting, PictureTel)
!
True video on demand and point-to-point VoIP applications will typically use
unicast mechanisms (not multicast) for traffic delivery. These applications require a
server to communicate directly with a unique subscriber and send packets as
needed to each subscriber. Hybrid systems also exist where content is distributed
on a schedule via IP multicast and then play out on demand under local control.
As with any class of applications, there are many ways in which the services may
be provided. The features as described in this document for implementation in the
BitStorm 2400 will provide support for IP multicast application using IGMP V1
and/or IGMP V2 protocols. Some applications will combine IP streaming with
VLAN and CoS/QoS techniques to deliver unique services.
Care must be taken in designing large-scale implementations to properly
characterize the nature and behavior of the application, network and end stations.
1-8
December 2002 2400-A2-GB20-10
Page 19
Protocols
1. BitStorm 2400 Overview
Extensive protocols and support exist for the distribution of multicast traffic across
the Internet and private GigE links. These protocols include Multicast Open
Shortest Path First (MOSPF), Distance Vector Multicast Routing Protocol
(DVMRP), and Protocol Independent Mul ticast (PIM, PIM SM, PIM DM).
It is assumed that one these routing protocols will be us ed to deliver the IP
multicast streams to the BitStorm 2400 IP DSLAM for delivery to subscribers. The
BitStorm 2400 will not directly participate in the routing protocols. In most
circumstances, the BitStorm 2400 will communicate with a router or Layer 3 switch
that performs these routing functions.
IP multicast packets are forwarded to the last router hop and are then delivered on
the router interface as specially formatted layer two broadcasts. Multicast support
is required in the BitStorm 2400 system to efficiently handle the forwarding of
multicast packets at Layer 2.
In the absence of multicast support, all multicast packets delivered to the
BitStorm 2400 IP DSLAM would be flooded to all ports (EtherLoop and Ethernet)
on the system. The result of this flooding is that all users would receive the traffic
for all of the multicast s that any user of the BitStorm 2400 had requested. This
would quickly overwhelm the bandwid th and resources of the system and end
stations.
Multicast suppor t in the BitStorm 2400 system is based on the IETF Internet
Group Management Protocol (IGMP) standards Version 1 and Version 2.
Multiple versions of IGMP exist:
!
!
!
See
Multicast Support
Support for efficient IP multicasting is critical for streaming applications such as
digital video delivery . Simply replicating pack ets and sending them serially to users
will not scale. Multicast routing capability is currently available in most routers.
Multicast support for the BitStorm 2400 system will ensure that IP multicasts are
efficiently forwarded at Layer 2 to subscribers and blocked from non-subscribers.
The BitStorm 2400 system operates as an IP Multicast-aware Layer 2 Switch
(Layer 2+).
IP Multicast support involves:
IGMP v 1 – RFC 1112
IGMP v 2 – RFC 2236
IGMP v 3 – Draft
IGMP Protocols
on page 1-11 for more information on IGMP operations.
Multicast Group Membership Management
!
Multicast Traffic Forwarding (L ayer 2)
!
2400-A2-GB20-10 December 2002 1-9
Page 20
1. BitStorm 2400 Overview
Multicast Group Membership Management
Multicast group membership management operations include:
Joining a Multicast Group
!
Multicast Group Membership Query
!
Multicast Group Membership Report
!
Leaving a Multicast Group
!
Summarizing IGMP reports to minimize duplicate information being forwarded
!
to the router interface
Generating proxy Queries Messages in the event there is no local multicast
!
enabled router
Multicast Traffic Routing
To properly and efficiently implement multicast traffic routing in the access
network, the following situations are handled:
First Member Joining the Multicast Group
!
Multicast packet forwarding and replication at Layer 2 elements
!
Detecting the presence of IGMP Version 1 or IGMP Version 2 hosts on
!
subscriber segments.
Determining when the last active member leaves a multicast group
!
Multicast IP Address and MAC Address Mapping
IP Multicast addresses are 32-bits long with the fou r high order bits set to “1110,”
which leaves 28 bits for mul ticast groups. When IP Multicast traffic is routed across
a Layer 2 netwo rk, the lower 23 bits of the 28-bit Multicast Group Address are
mapped into the lower 24 bits of the corresponding MAC multicast address and the
most significant bit is set to 0. The higher 24 bits of the MAC multicast address are
fixed to 0 1 .0 0.5E.
Because only 23 bits of the 28 bits of the IP multicast address are mapped into the
MAC multicast address, this leaves 32 IP multicast addresses mapped into a
single MAC multicast address. The CO and the BitStorm 2400 both need to
inspect the IP header in the multicast frame to determine the actual IP multicast
group for forwarding traffic on the right port.
1-10
December 2002 2400-A2-GB20-10
Page 21
IGMP Protocols
1. BitStorm 2400 Overview
IGMP v2 is backward compatible with IGMP v1. IGMP V e rsion 2 extended the
IGMP Version 1 standard by adding support for an explicit group leave message
and a group specific query message. These new messages greatly improve the
efficiency of stopping the multicast flows once a subscriber no longer has interest
in the group (has shut down or changed the channel).
Most modern IP Multicast applications, routers, and end stations will support
IGMP V2 per RFC 2236. Support for the IGMP V1 messages and operation mode
is required by the IGMP standard for backward compatibility. IGMP v3 is still a draft
at this time and will be considered for future implementation.
IGMP protocol support requires the following operations:
Join Group
!
Membership Query
!
Membership Report
!
Leave Group
!
Join Group
Membership Query
Membership Report
When a host GigE joins a multicast group, i t transmits an unsolicited Mem bership
Report for that multicast group.
Membership Queries are sent by IP multicast routers to learn which multicast
groups have members on its neighboring interfaces. Two types of query are
defined:
General Query – sent by a multicast router and received by all hosts with
!
membership in a multicast group.
Group-Specific Quer y (IGMP V2 only) – sent by a multicast router and
!
received by only those hosts that belong to the specific multicast group.
Membership Reports are generated and sent by hosts in response to Membership
Query messages that they have received. Membership Reports can also be
generated unsolicited as in the case of a Join Group operation.
In response to a General Query, end stations will generate repor t mes sages for
each group in which they are interested in participating. IGMP V2 hosts will
receive and respond to Group-Specific Query messages only if they are in the
specified group.
2400-A2-GB20-10 December 2002 1-11
Page 22
1. BitStorm 2400 Overview
In an effort to reduce the number of broadcast messages being generated in
response to the Query or Group-Specific Query message, all hosts in the
broadcast domain will see the reports for other hosts in that group. Hosts that see
another’s report will simply rese t their timer on that group and will not generate a
duplicate of the Report Message.
IGMP-enabled devices (routers or snooping switches) w ill lea r n which interfaces
have at least one interested host for each group. They will not be able to determine
if more than one host is interested in the group on a sin gle interface.
For typical situations, IGM P report packets should be su ppress ed so that they are
not forwarded between the subscriber ports on StormPort CPE modems. If IGMP
reports are flooded to the other ports, the modem will not get an accurate view of
the ports that have interested hosts, i.e., the hosts on EtherLoop ports 2–6 will see
a report from a host on EtherLoop 1. Hosts on ports 2–6 therefore would not
generate reports for the groups. If port-to-port communication has been enabled
on the modem, then IGMP Repor t packets should be allowed to be forwarde d.
When a Membership Repor t is received, the router (or IGMP snooping switch)
does the following:
Adds the group being reported to the list of multicast group memberships on
!
the network on which it received the report.
!
!
Leave Group
When a host leaves a multicast group, it does one of the following:
!
!
IGMP O p eration
IGMP V1 Operation
In IGMP V1, routers (or IGMP Proxy function) will periodically (typically every
10 seconds) issue IGM P Ge neral Quer y mess ages. Ever y multicast-enabled end
station will receive the Query Message and prepare to generate IGMP report
messages for each of the multicast groups it wishes to participate in.
Set/Resets the interval timer for that grou p membership
Repeats Membership Query at regular intervals
Sends a Leave Group Message to the routers (224.0.0.2) IP group address.
This option is only available to IGMP V2 hosts.
Quietly leaves a multicast group by no longer generating IGMP Reports for
that group in response to Queries.
The IGMP router will keep track of the Report Mess ages rec eived for each group.
If the IGMP router completes three query/report cycles and does not detect a
report for a specific group, it will assume that there are no interested end stations
and will stop forwardi ng the multicast messages for this group on this interface. If
this was the last or only interface interested in a specific group, the router will
signal the other multicast routers to prune itself from the multicast forwarding tree.
1-12
December 2002 2400-A2-GB20-10
Page 23
IGMP V2 Operation
IGMP V2 enhances the IGMP V1 standard by adding explicit messages to allow a
host to signal that it is leaving a multicast group and a message for a router to
query for hosts interested in a specific group. IGM P V2 join operations operate as
they did in IGMP V1. When a host no longer has interest in a multicast group, the
host V2 host will issue an IGMP Leave Message for that group. The message is
addressed to the all-routers group (224.0.0.2).
Routers receiving a Leave Group message will typically issue a Group Specific
Query message to the interface on which it received the Leave Group message.
The purpose of this Query is to determine if there are any other hosts remaining
on this inter face tha t st ill have int er es t in t h is grou p.
IGMP V1 and V2 Co-existence
If a Router or IGMP Snooping switch detect a host on an interface using the IGMP
V1 report messages, the router must assume that there is at least one IGMP
V1-only host on that interface and revert to the IGMP V1 mode of operation on that
interface.
1. BitStorm 2400 Overview
Summary of IGMP V2 Message Formats
Table 1-2, Messages, summar izes the types of messag es that the IGMP Router,
proxy, or Snooping agent must listen for and respond to every 10 seconds.
See the IETF Standard documentation for complete packet layou t and formatting
rules.
Table 1-2. Messages
Message Source IP @ Destination IP @
Membership
Report
Leave Group Host IP @ All Routers
Gen e ral Query Querier’s IP @ All Hosts
Group Specific
Query
Host IP @ MC Group
being reported
224.0.0.2
224.0.0.1
Querier’s IP @ All Hosts
224.0.0.1
IP Header
Protocol
0x02 0x12 0 MC Group being
0x02 0x17 0 MC Group being
0x02 0x11 100 0
0x02 0x11 100 MC Group being
IGMP V2
Type
IGMP V2
Max Resp
IGMP V2
Group @
Reported
left
queried
2400-A2-GB20-10 December 2002 1-13
Page 24
1. BitStorm 2400 Overview
Multicast Implem entation
The BitStorm 2400 supports the efficient forwarding, traffic shaping and
accounting for multicast flows.
The BitStorm 2400 listens for IGMP V1 or IGMP V2 messages. Upon hearing a
solicited or unsolicited report message for group, the BitStorm 2400 must build or
update a group-to-interface table entry to record the IGMP Group fo r which the
report message was generated, the IGMP Version of the reporting host, the IP
DSLAM port on which the report was heard, and reset a timer value to indicate the
last report relative time.
Due to the Report Suppression techniques im plement ed by IGMP hosts, the
BitStorm 2400 will typically only see one or two report messages for a specific
group from each port regardless of the number of interested hosts there may be.
The BitStorm 2400 may attempt to map the IGMP Report originators MAC address
to a shared MAC address table to map the Report message to a port. The tables
must be updated such that they reflect a single row for each multicast group on
each interface. The table must also note if any IGMP V1 format reports have been
received from hosts in that group.
If the IGMP Report message was forwarded in a ta gged Ether net frame, the VLID
information for that report should be noted in the table. The BitStorm 2400 must
keep a table entry for each multicast group learned on each tagged VLAN for each
port. VLANs in this mode of operation will be used to sub-address one or more
ports on a specific chassis.
IGMP Report Messages
On receipt of IP multicast packets at th e BitStor m 2400, the group address is
extracted from the IP header information and compared to the values in the groupto-interface forwarding table. The multicast packets are scheduled and forwarded
only to those interfaces that have at least one interested host.
Multicast packets may need to be rep licated and forwarded to multiple interfaces
from the BitStorm 2400. One multicast packet must be sent to e ac h
BitStorm 2400: VLAN logical interface with at least one reporting host interested in
that group.
For each VLAN tagged interface, a copy of the packet must be created with a
VLAN tag inserted and the packet CRC recalculated. The tagged packet may then
be scheduled for forwarding. Reser ved Class D addresses, for example, al l-hosts
(224.0.0.1), all-routers (224.0.0.2), should be forwarded on a ll interfaces
regardless of the IGMP table entries.
1-14
December 2002 2400-A2-GB20-10
Page 25
IGMP Leave Messages
IGMP V2 Leave messages received from subscriber ports indicate that a host on a
subscriber por t has lost interest and no longer wishes to par ticipate in a multicast
group. The BitStorm 2400, upon receiving this message from a port, determines if
there are any remaining hosts interested in this group on the port or VLAN
interface.
The BitStorm 2400 extracts the IP group address from the message and looks it
up in the group-to-interface forwarding table. If the table indicates th at an IGM P
Version 1 host is active for this group on this interface, no further processing is
performed. If the table indicates that only IGMP V2 hosts are on this interface, the
BitStorm 2400 immedia tely issues a Group-Spec ific Quer y message on t hat
interface. If there are no report messages received for th at group in response to
the Query message, the group entry for that interface may be deleted or
invalidated from the interface table.
Configurable parameters are made available to specify an interval and retry count
to control the process of removing an entry after an IGMP Leave message is
received. The parameter sets a number of retries (default 3) and interval (100 ms)
that would be allowed to attempt to locate remaining hosts on the BitStorm 2400 or
VLAN interface before re moving the entr y from the forwarding table. Tuning this
parameter would be one of the tools for minimizing the effects of ‘channel surfing’
on the links.
1. BitStorm 2400 Overview
Group-to-Interface Table Processing
In the presence of an IGMP enabled router, IGM P General Query messages
should be received about every 10 seconds or less. The BitStorm 2400 notes the
relative time of the last Query message.
As General Query messages and reports are being processed and forwarded, the
group-to-interface table will be updated. At least every 10 seconds, the
BitStorm 2400 reviews the group-to-interface table entries, looking for rows that
have not seen a report message from a host on that interface in 3 Query cycles or
30 seconds.
If entries are found that have expired, they may be invalidated or deleted. If
General Query messages have not been received in 15 seconds, the data pump
generates its own IGMP General Query message.
2400-A2-GB20-10 December 2002 1-15
Page 26
1. BitStorm 2400 Overview
MAC Layer Filtering
MAC layer filtering provides network security in the absence of VLANs. The MAC
address-based privacy filter feature of the StormPort modem can provide strict
privacy to segregate each end user’s traffic, but does not provide an effective
means of forming work groups that can share traffic.
In the privacy filter system, each modem is programmed with a list of MAC
addresses that represent valid gateways for bac khaul. The BitStorm 2400 units will
only forward traffic downstream that has a source MAC address from this list. The
CPE modems will only forward traffic upstream that has a destination MAC
address from this list.
Because this system is MAC-address based, it is not practical to maintain a list of
end-user MAC addresses on the CPE modem side that are part of a work group
(allowed to communicate to end-user MAC a ddress es on the CPE modem side of
another port). This privacy prevents peer-to-peer communication, eliminating, for
example, Microsoft Network Neighborhood browsing.
Multiple gateways are p ossible and each modem contains its own privacy filter
table. This allows the access serv ice provider to provision each customer to a
choice of gateways. This is one method of providing a choice of ISP or ASP to
consumers on the same access network.
1-16
December 2002 2400-A2-GB20-10
Page 27
Terminology and Conventions
System Terminolo gy
The following terms are used in this manual and the BitStorm 2400 user interfaces.
Port
A port is one of the physical interfaces of a BitStorm 2400. These are:
MGMT (RJ45)
!
CRAFT (DB9)
!
2
Unit
Stack
GigE1 (Copper – RJ45):
!
GigE1 (Fiber – SFP):
!
GigE2 (Copper – RJ45)
!
GigE2 (Fiber – SFP)
!
EtherLoop Ports 1–24 (RJ21X)
!
A single BitStorm 2400 is referred to as a unit or chassis.
Up to eight units can be interconnected and supplied with a single uplink; this
arrangement is referred to as a stack. See Figure 2-1, BitStorm 2400 IP DSLAMs
Interconnected.
GigE1 takes priority over GigE2.
GigE1 fiber takes priority over GigE1 copper.
2400-A2-GB20-10 December 2002
2-1
Page 28
2. Terminology and Conventions
Network
WAN 2
GigE1 Ports
WAN 1
GigE2 Ports
24 Line
Filter 66-Block
02-17249
Figure 2-1. BitStorm 2400 IP DSLAMs Interconnected
In this figure, eight BitStorm 2400 units are daisy-chained using the GigE1 of the
top unit to connect to the network. The GigE2 port of the top unit is then connected
to the GigE1 port of the unit below. This sequence is repeated through the
subsequent units to complete the daisy-chaining links.
The bottom unit is also connected to the network using the GigE2 port and is used
for the Spanning Tree Protocol (STP) to prevent loops in the network.
NOTES:
— GigE fiber ports take priority over GigE copper ports.
— GigE1 ports t ake priority over GigE2 ports.
— Only one GigE port (GigE1 and/or GigE2) operates at a time.
2-2
December 2002 2400-A2-GB20-10
Page 29
Using the Asynchronous Terminal Interface
Overview
The asynchronous terminal interface is accessible using Telnet, an asynchronous
terminal, or a terminal emulation program running on a PC. You can use the
terminal interface to:
Change the operational characteristics of the device by setting configuration
!
values
Display system status
!
Perform Diagnostics
!
3
Navigating Menu Options
Use the T ab or the arrow keys to move between each field. To execute a command
or access a submenu, press Enter.
Each submenu displays all or some of the following commands:
MAIN MEN U : Returns you to the main men u at an y ti me.
!
PREV MENU: Takes you back one level.
!
APPLY: Applies all o f the modifications you have made to the current switch
!
configuration. These modifications will not be stored in NVRAM and will be lost
the next time you reset or power off the switch.
SAVE: Applies all of the modifications you have made to th e current switch
!
configuration and will save the information onto the ATA drive. The
configuration will be saved even when the switch is reset or powered off. Do
not turn the switch off before the saving process is complete.
2400-A2-GB20-10 December 2002
3-1
Page 30
3. Using the Asynchronous Terminal Interface
Logging In
Figure 3-1 shows the Login Screen. This is the initial screen displayed to the user.
The terminal interface supports a single login only, therefore no user name is
required. Type the password (up to 16 case-sensitive characters), then press Enter
to log in. The default password is password.
Figure 3-1. Login Screen
3-2
December 2002 2400-A2-GB20-10
Page 31
Main Menu Screen
The Main Menu screen is shown in Figure 3-2. Highlight a menu item and press
Enter to access it. LOGOUT returns you to the Login screen; however, if using a
Telnet session it terminates the connection.
3. Using the Asynchronous Terminal Interface
Figure 3-2. Main Menu Screen
2400-A2-GB20-10 December 2002 3-3
Page 32
3. Using the Asynchronous Terminal Interface
Switch Configuration Screen
The Switch Configuration screen is shown in Figure 3-3. This screen allows you to
modify key parameters of the BitS tor m 2400. Use the Tab or the arrow keys to
move from one field to another. After you modify a field, press Enter to validate it. If
the information in the field is not valid, the previous value will be displayed.
Figure 3-3. Switch Configuration Screen
You can modify the following infor mation:
Field Description
IP Address This is the IP address allocated to the default subnet and default
virtual local area network (VLAN). F actory def aul ts will ha v e all ports
on the defaul t VLAN; thus, thi s IP address will be associated with all
ports initially. This IP address is set wit h the asynchronous terminal
interface.
Subnet Mask This field lets you enter the subnet mask (netmask).
Default G ateway This field lets you enter the address of the gateway (i.e., next hop
router). This wi ll only tak e eff ect af ter the s witc h is reset. It can be lef t
as 0.0.0.0 if the switch will not be connected to the external Internet.
MAC Address This is the base Ethernet addr ess of the in-b and ports of the
BitStorm 2400.
Spanning Tree Toggle between Disable and Enable using the spacebar . Enabling
this fea ture starts the Spanning Tree algorithm.
BOOTP Boo tstrap Protocol. This protocol all ows the switch to discover it’s
own IP address, the IP address of a BOOTP server on the network,
and a file to be loaded into memory. This option is not yet
implemented.
3-4
December 2002 2400-A2-GB20-10
Page 33
3. Using the Asynchronous Terminal Interface
Field Description
DHCP Dynamic Host Configuration Pr otocol . This pro tocol assigns dyna mic
IP addresses to devices on a network. With dynamic addressing, a
device can have a different IP address every time it signs on to the
network. This option is not yet implemented.
Time/Date You can set the cur rent time and date in the specified format. This
information will be kept for a few days if the s w itch is powered off.
Reset By default, this option is no reset. Using the spa cebar you can toggle
to reset and reset factory defaults. When you select one of the reset
options, select APPLY or SAVE.
2400-A2-GB20-10 December 2002 3-5
Page 34
3. Using the Asynchronous Terminal Interface
Port Statistics Screen
The Port Statistics screen is shown in F igure 3-4. The Port and PHY settings are
displayed in this screen.
Figure 3-4. Port Statistics Screen
Select one of the fields by using the T ab or arrow keys . Scroll through the values
by pressing the spacebar. T he values displayed are automatically updated every
few seconds.
You can modify the following infor mation:
Field Description
Unit Select the unit i n case of multiple units. You can only select 1 in this
configuration.
Port Select the port number from 1 to 26.
State You can select the state for each port. States are Enable and Disable.
Set Speed You can leave the BitStorm 2400 to determine the speed automat ically
(autonegotiate) or select one of th e following:
Autonegoti ate: Th e port speed is select ed a ccordi ng to th e conn ected
!
device.
Half-10: 10 Mbps, half-duplex
!
Full-10: 10 Mbps, full-duplex
!
Half-100: 100 Mbps, half-duplex
!
Full-100: 100 Mbps , fu ll -duplex
!
Full-1000: 1000 Mbps , full-duplex
!
Select APPLY or SAVE when finished.
3-6
December 2002 2400-A2-GB20-10
Page 35
3. Using the Asynchronous Terminal Interface
Configuration File Upload/Download Screen
The Configuration File Upload/Download screen is shown in Figure 3-5. This
screen lets you conveniently upload o r download configuration files for the switch.
It lets you share saved configurations across multiple switches. For ex ample, if you
have a switch that contains a static route table with 100 entries and you want
another switch to have the same table of static routes, you can use this feature to
get the configuration information (which includes the static route table) from one
switch to the other. This keeps y ou from having to manually re-enter the 100 static
routes on the new switch.
Figure 3-5. Configuration File Upload/Download Screen
Use the Tab or arrow keys to move from one field to another. After you modify a
field, press Enter to validate it. If the information in the field is not valid, the
previous value w ill be dis p layed .
You can modify the following infor mation:
Field Description
Image Path Ente r the relative path to the image (“persist” or “durable”) from the path
setup in TFTP, including the name of the image file.
TFTP Server
IP Address
Direction <host-to-switch> indicates the configuration fil e wil l be transferred from
Enter the IP address of the host.
PC to switch, <switch-to-host> indicates from switch to PC.
After you modify the above information, use the T ab ke y to move to APPLY and
press Enter. This will begin the transfer.
The Load Status field will indicate what state the operation is in and the switch will
automatically reset when complete. Any errors will also b e reported in the Load
Status field.
2400-A2-GB20-10 December 2002 3-7
Page 36
3. Using the Asynchronous Terminal Interface
Image F il e D o w n load Screen
The Image File Download screen is shown in Figu re 3-6. This screen allows you to
download the switch firmware image to flash memory. In the fields provided, use
the spacebar to toggle selections and enter the location of the image, the Server
IP Address, and the Download Type. Select APPLY.
The filename (vxWorks or vxWorks.Z) is case-sensitive.
Figure 3-6. Image File Download Screen
NOTE:
You must manually reset the BitStorm 2400 after the download completes for
changes to take effect.
3-8
December 2002 2400-A2-GB20-10
Page 37
Serial C o n fig u ration Screen
The Serial Configuration screen is shown in Figure 3-7. This screen allows you to
modify the baud rate. Once you select APPLY or SAVE, the baud rate is modified
immediately , and you will ha ve to modify y our terminal or emulator to communicate
with the BitStorm 2400.
The default and recommended baud rate is 19200, which is the rate used by the
boot code. If you change the o perating system baud rate to a different va lue, you
may create a situation where only the initial boot messages are readable, or only
messages sent after the boot process is complete are readable.
This screen also displays read-only information about the serial interface.
3. Using the Asynchronous Terminal Interface
Figure 3-7. Serial Configuration Screen
2400-A2-GB20-10 December 2002 3-9
Page 38
3. Using the Asynchronous Terminal Interface
Change Password Screen
The Change Password screen is shown in Figure 3-8. This screen lets you change
your password. You can enter a new password of up to 16 ca se-sen sitive
characters.
Figure 3-8. Change Password Screen
Select APPLY to keep the new password until you power off the BitStorm 2400.
Select SAVE to save the new password permanently.
CAUTION:
If you forget your password, the onl y way to restore the BitStorm 2400 to
the original password is to erase the full NVRAM and to reinstall the
applications.
3-10
December 2002 2400-A2-GB20-10
Page 39
Configure EtherLoop Devices
The EtherLoop Main Menu screen, Figure 3-9, is used to set training for the
StormPort modems attached to your network. Highlight EtherLoop Device
Configuration/Monitoring, then press Enter to proceed.
3. Using the Asynchronous Terminal Interface
Figure 3-9. EtherLoop Main Menu
NOTE:
The Diagnostic Test i ng option is scheduled for a future release and is not yet
implemented.
2400-A2-GB20-10 December 2002 3-11
Page 40
3. Using the Asynchronous Terminal Interface
The second screen in the EtherLoop Configuration option is used to configure
modem training. Highlight this option, then press Enter to proceed to the Training
Mode Menu.
Figure 3-10. EtherLoop Configuration Menu
In the EtherLoop Training Mode screen, each of the 24 ports is enabled or
disabled for training. Ports (slots) 000–023 can be enabled or disabled collectively
or on an individual basis.
Enable allows the modem to “listen” for pulses from the CPE.
!
Disable initiates polling pulses to the CPE. The LED flashes for each por t
!
disabled.
Figure 3-11. EtherLoop Training Mode Menu
3-12
December 2002 2400-A2-GB20-10
Page 41
3. Using the Asynchronous Terminal Interface
Procedure
To set training for ports:
1. Use the spacebar to select Enable or Disable in the Ena ble/Disable Standby
Training For All Slots field. Or, to set individual ports, select the dashes (------).
2. If setting ports individually, use the arrow keys to navigate the fields, then use
the spacebar to select Enable or Disable.
3. Select SAVE when finished.
2400-A2-GB20-10 December 2002 3-13
Page 42
3. Using the Asynchronous Terminal Interface
3-14
December 2002 2400-A2-GB20-10
Page 43
Using the Web Interface
Overview
The BitStorm 2400 supports a web interface th at can be used to perform some
more elaborate configuration functions that the asynchronous terminal interface
does not address, such as:
Changing the operational characteristics of the device by setting configuration
!
values
Displaying system status
!
Perfor m ing diagnos tics
!
4
To access the web-based IP DSLAM configuration pages, you can connect to the
BitStorm 2400 IP DSLAM through its:
Out-of-band management por t , labeled MG MT, or
!
In-band ports, labeled GigE1 or GigE2.
!
Be aware that the GigE ports are not secure, therefore it recommended th at there
be a secure gateway or firewall in place before using these ports.
Web Interface Login
Using a web browser, access the main page by typing the following URL:
http://
terminal interface configuration. Once the URL is entered in the web browser, the
login page appears.
address
, where
address
is the IP address you previously defined in the
2400-A2-GB20-10 December 2002
4-1
Page 44
4. Using the Web Interface
.
Figure 4-1. Login Prompt
You must enter a user name and password to access the switch configuration. The
default user name is admin and the default password is password. Once you
enter a user name and password, the logo page appears.
Figure 4-2. Logo Page
4-2
December 2002 2400-A2-GB20-10
Page 45
Configuring the System
The logo page allows you to navigate the management web pages. In the left
frame of the browser, there is a navigation tree. Simply click on the + signs next to
each folder to expand.
The following options are used to manage and configure the BitStorm 2400:
Management Configuration
!
Notification (Traps)
!
Spanning T ree
!
VLANs/Multicast Groups
!
Each of these pages will display all or som e of the commands listed in Table 4-1.
Table 4-1. Web-based Configuration Commands
Command Description
4. Using the Web Interface
Apply This command will apply all the m odif ications t o the current c onfigu ration.
These modificat ions will not be stor ed in NVRAM and will be lost the ne xt
time you reset or power off the switch.
Save This command will apply all the modificatio ns to the current conf iguration
and will sav e all information. The configur ati on will be saved even when
the switc h is re set or powered off. Do not turn the switch off before Save
is completed.
Next This command will displ ay the next page of entries if the re ar e more
entries than space on the screen.
Refresh This command wi ll r efres h the i nf ormati on on the page . This is nec essary
if you want t o d isplay the latest information such as stati sti cs.
Delete This command will delete the specified information from the tables .
Management Configuration
Within Management Configuration, you can configure the following:
Switch
!
System
!
Port Configuration/Statistics
!
Serial
!
Password
!
2400-A2-GB20-10 December 2002 4-3
Page 46
4. Using the Web Interface
Switch Configuration
The Switch option is used to configure switch settings. This page allows you to
configure several ma jor features of the switch.
Figure 4-3. Switch Configuration
You ca n modify the following information:
Setting Description
IP Address This is the in -band managment IP address allocated to th e default
subnet and default VLAN. Factory defaults will have all ports on the
default VLAN; thus, this IP address will be associated wit h all ports
initially.
Default Gate way This field lets y ou enter the IP address of the gateway (i.e., next hop
router). This will only take effect after the switch is reset. It can be left
as 0.0.0.0 if the switch will not be connected to the ext ernal Internet.
Spanning Tree The Spanning-Tree Protocol (STP) is a link management protocol
that provides path redundancy while preventing undesirable loops in
the network. Fo r an Ethernet network to func ti on properly, only one
active path can exist between two devices. This field lets you choose
to Enable or Disable the Spanning Tree Algorithm.
BOOTP Bootstrap Protocol. This protocol allows the switch to discover it’s
own IP address, the IP address of a BOOTP server on the network,
and a file to be loaded into memory. This option is not yet
implemented.
GVRP GARP VLAN Registration Protocol. You can choose to Enable or
Disable this protocol.
IGMP Snooping Internet Group Management Protocol. IGMP Snooping allows the
switch to f orward IGMP packets based on their content. You can
choose to Enable or Disable this protocol.
4-4
December 2002 2400-A2-GB20-10
Page 47
4. Using the Web Interface
Setting Description
Routing Protocol This option allows you to select which routing protocol the switch will
use. There are three routing protocol options:
none: Specifies that neit her RIP or OSPF is to be used.
!
RIP (Routing Information Protocol): Selecting this option enab les
!
RIP.
OSPF (Open Shortest Path First): Selecting this option enables
!
OSPF.
NOTE: The process for changing the routing protocol for t he switch is
differ ent than changing other options. Once you select one of the
above three options you must click on the Save button. After cli cking
the Save button, you must reboot the switch. You can do this by
selecting Reset from the Reset field and clicking the Apply button.
Only after the switch has finished rebooting will the new routing
protocol take effect and the corresponding web pages be available.
Subnet Mask This field allo ws you to enter the subnet mask (net mask).
MAC Address This is the base Ethernet address of the in-band ports of the switch.
Traffic Classes The goal of traffic classes is to help support time critical (continuous
media) traffic through the use of priority assignment and efficient
multicasting. If enabled, traffic classes are in effect. If disabled, the
switch will operate with a single priority level for all traffic.
DHCP Dynamic Host Configuration Protocol. This protocol assigns dynamic
IP addresses to devices on a network. With dynamic addressing, a
device can have a different IP address every time it signs on to the
network. This option is not yet impl em ented.
GMRP GARP Multicast Registration Protocol. You can choose to Enable or
Disable this protocol.
Link Aggregation You can choose Enable or Disable to use the aggregation function.
Reset This allows you to r eset the switch. There are three opt ions:
no reset: This is the default option. It indicates that the switch is
!
not to reset when clic king on Apply .
reset: Selecting this option and clicking Apply reboots the switch,
!
and any configuration changes that ha ve been made to the switch
that have not been saved will be lost.
reset to fac tory defaults: Selecting this opt ion and clic king Apply
!
resets the s wit ch, and r est ores ori ginal f actory defaults. At the ti me
of this publication, this setting is configured for factory settings,
therefor e changes are acknowledged as factory changes.
Click on Apply or Save to activate your changes.
2400-A2-GB20-10 December 2002 4-5
Page 48
4. Using the Web Interface
System Configuration
The System option is used to access and modify system information.
Figure 4-4. System Configuration
The following information can be modified as needed:
System Name
!
System Location
!
System Contact
!
Product Name
!
This information does not affect the operation of the switch. After you hav e entered
the appropriate information, click on Apply or Save to activate your changes.
NOTE:
The Num Network Interfaces field lists 26 ports. Ports 1–24 represent the
actual lines; Ports 25 and 26 represent the GigE1 and GigE2 ports,
respectively.
4-6
December 2002 2400-A2-GB20-10
Page 49
Port Configuration/Statistics
The Port Statistics option is used to access and modify port statistics and PHY
settings (those settings associated with the physical properties of your network
equipment).
4. Using the Web Interface
Figure 4-5. Port Configuration/Statistics
2400-A2-GB20-10 December 2002 4-7
Page 50
4. Using the Web Interface
The following is a descr iption of each PHY setting:
Setting Description
Unit Select the unit in case of multiple units. Only one is used in this
configuration.
Port Selec t the port number from 1 t o 26. When you do thi s, the rest of t he fields
on the web page will update t o show the statistics and PHY settings of the
selec ted port.
State You can select the state for each port. Available states are Enable and
Disable.
Set Speed You can leave the s witch to determine the speed automatically
(autonegoti ate), or select one of the following:
Half-10: 10 Mbps , hal f-duplex
!
Full-10: 10 Mbps , full-duplex
!
Half-100: 100 Mbps , half-duplex
!
Full-100: 100 Mbps, full-duplex
!
Full-1000: 1000 Mb ps, full-duplex
!
STP State This field indicates the port’s state in the Spanning Tree Protocol. This st ate
controls what acti on a port takes on reception of a frame. If a port is
disabled, then this field will indicate the same thi ng, disabled. If the swit ch
determines that the port is malfunct ioning, it will place a value of broken in
this field. Otherwise, this value will be one of the following: blocking,
listening, learning, or forwarding, corresponding to the state of the port in
the STP.
Link This fie ld i ndicates the physical st ate of a CO modem link.
Actual
Speed
Type This field indicates the type of media (speed) connected to the port, i.e.,
This field indi cates the line speed of the port.
fastEther (100 bT).
The following describes the switch statisti cs fields:
Field Description
VLAN/L3 Counters
TX VLAN Tagged
Packets
TX L3 Sent OK
Packets
This is th e total number of tagged VLAN Packets that have been
transmitted by the switch.
This is the total number of l ayer 3 packets that were tr ansmitted
by the swit ch and were OK.
TX L3 Aborted Packets This is the total number of layer 3 packets that were not
transmitted for various reasons.
RX L3 Header Error
Packets
4-8
December 2002 2400-A2-GB20-10
This is the total number of packets received by the switch that
had corrupted header information.
Page 51
4. Using the Web Interface
Field Description
RMON (etherStats)
DropEvents This is the total number of events in which packets were
dropped. Note th at this number is not necessa rily the number of
packets dropped; it is just the number of t imes this condition has
been detected.
Octets This is the total number of octets of data received and
transmitted (includes both good and bad packets).
Pkts This is the total number of packets transmitted and received by
the switch.
BroadcastPkts This is the total number of good packets received and
transmitt ed that were directed to the broadcast address
(excluding multicast packe ts).
MulticastPkts This is the total number of good packets received and
transmitt ed that were directed to the multicast address
(excluding broadcast packets) .
CRCAlignErrors This is the total numb er of pack ets re ceiv ed and tran smitte d that
had a length of 64 to 1518 octets, but also had a bad Frame
Check Sequence (FCS).
UndersizePkts This is the total number of pack e ts recei ved and tr an smitte d that
were less than 64 octets.
OversizePk ts This is the total number of pack e ts recei ved and tr an smitte d that
were greater than 1518 octets.
Frag ments This is the total number of packe ts recei v ed and tran smitte d that
were less than 64 oct ets and had a bad F rame Chec k Seq uence
(FCS).
Jabbers This is the total number of packets re ceiv ed and tran smitte d that
were greater than 1518 octets and had a bad Frame Chec k
Sequence (FCS).
Collisions This is the total number of collisions that have occurred.
Pkts64Octets This is the total number of receiv ed or transmitted packets that
were 64 octets in length .
Pkts65to127Octet s This is the total nu mber of pack e ts recei ved and tr an smitte d that
were between 65 and 127 octets in length.
Pkts128to255Octet s This is the total number of packe ts recei v ed and tran smitte d that
were between 128 and 255 octe ts i n length.
Pkts256to511Octet s This is the total number of packe ts recei v ed and tran smitte d that
were between 256 and 511 octe ts i n length.
Pkts512to1023Octe ts This is the total number of packets re ceiv ed and tran smit ted that
were between 512 and 1023 octets in length.
Pkts1024to1518Oct ets This is the total number of pack e ts receiv ed and tr ansm itted that
were between 1024 and 1518 octets in length.
Click on Refresh to update the va lues displayed in each field.
2400-A2-GB20-10 December 2002 4-9
Page 52
4. Using the Web Interface
Serial Conf iguration
The Serial option allows you to modify the baud rate and view other serial port
settings.
Figure 4-6. Serial Configuration
Select a baud rate from the drop-down menu, then click on Apply. The default and
recommended baud rate is 19200, which is the rate used by the boot code. If you
change the operating system baud rate to a different value, you may crea te a
situation where only the initial boot messages are readable, or only messages sent
after the boot process is complete are readable.
The following information is read-only:
Character Size
!
Parity
!
Stop Bits
!
Flow Control
!
Click on Apply or Save to activate changes.
4-10
December 2002 2400-A2-GB20-10
Page 53
Password Modification
The Password option is used to modify the password.
4. Using the Web Interface
Figure 4-7. Password Modification
You ca n enter a new password up to 16 characters.
NOTE:
If you forget your password, please contact Paradyne Tec hnical Support at
1-800-870-2221 (U.S. or Can ada) or 1-727-530-2340 (world wide).
Notification (Traps)
Within Notification, you can configure the fo llowing:
Targets
!
Notifications
!
2400-A2-GB20-10 December 2002 4-11
Page 54
4. Using the Web Interface
SNMP Targets
The Targets option gives you access to SNMP targets.
Figure 4-8. SNMP Targets
This page allows you to view and modify SNMP Target Addresses and SNMP
Target Parameters. T he page is split into two separate tables: SNMP Target
Addresses and SNMP Target Parameters.
SNMP Targe t Addresses Table
This table allows you to set up the target address for the trap manager that should
receive SNMP notifications. Entries in this table can be thought of as “destinations”
to which SNMP notifications will be sent under certain conditions.
Procedure
To create a new entry in the SNMP Target Addresses Table:
1. Select New from the Entry pull-down box.
2. Fill in the new information in the following fields:
Field Description
Name Unique st rin g identifier.
Transport Domain Transport type of the address, f or example, a MIB OID.
4-12
December 2002 2400-A2-GB20-10
Page 55
4. Using the Web Interface
Field Description
Transport Address Transport address whose format is dependent upon domain.
This is the server IP addr ess.
Timeout This is the expected maximum round trip time for
communicating with the target transport address. The time
interval that an appl ication may wait could be longer than thi s
value if authentication is required. The default value is 1500.
Retry Count Number of retries to be attempted when no response is
received.
Tag List Contains a list of ta g values that the notification generator uses
to select this specific target address. The notification generator
scans this value looking for a match from the SNMP Notify
Table. If a match is found, then it sends the notification to this
target address .
Paramet ers Identifi es an entry in the SNMP Target Parameters Table (which
is the second table on this web page) to be used for this tar get.
The identified entry contains parameters to be used when
generating messages to be sent to this transport address. You
must enter the name of a SNMP Target Parameters row. For
example, in Figure 4-8, SNMP Targets, there are 3 rows in the
SNMP Target Parameters Table. To specify one of those rows
for this field, you simply enter the name of the desir ed SNMP
Parameters row , such as v1 params, v2 params, or
v3 params.
Storage Type The storage type for this row. The following options are
available:
other
!
volatile
!
nonVolatile
!
permanent
!
read-only
!
3. Click on Apply to add the new en tr y.
SNMP Target Parameters Table
This table allows you to set up parameters that a target address in the SNMP
Target Addresses Table needs to use in order to generate a notification. For each
entry in the SNMP Target Addresses Table, you can specify an entry to use in the
SNMP Target Parameters Table.
For exampl e, nms v1 in the SNMP Target Addresses Table (first entry) has a
value of v1 params in its parame ters field. Therefore, when the target address
nms v1 generates a notification, it will look for the entry in the SNMP Target
Parameters Table whose name is v1 params and use this entry’s information to
generate the correct notification.
2400-A2-GB20-10 December 2002 4-13
Page 56
4. Using the Web Interface
Procedure
To create a new entry in the SNMP Target Parameters Table:
1. Select New from the Entry pull-down box.
2. Fill in the new information in the following fields:
Field Description
Name U nique string identifier.
MP Model Specifies the message-processi ng model to be used when
generating SNMP messages. This field holds an integer
identifier tha t uniquely identifies a message-pr ocessing model
of the Message Processing Subsystem within the SNMP
Management Architect ure. The following opti ons are available:
0 – specifies the SNMP version 1 model
!
1 – specifies the SNMP version 2c model
!
2 – specifies the SNMP version 2u and version v2* models
!
3 – specifies the SNMP version 3 model
!
Security Model Specifies the security model to be used when generating
SNMP messages. This fiel d holds an integer identifier that
uniquely identifies a security model of the Security Subsystem
within the SNMP Management Architecture. The following
options are available:
0 – specifies that no spe cific security model is requested:
!
1 – specifies the SNMP version 1 security model
!
2 – specifies the SNMP v ersion 2c security model
!
3 – specifies “user-defined” securi ty m o del (USM )
!
Security Name Secur ity Name (community string) that identifies the Principal
when SNMP messages are sent.
Security Level Level of s ecurit y to be used when generat ing SNMP messages .
The follo wing options ar e available:
noAuthnoPriv
!
authNoPriv
!
authPriv
!
Storage Type Storage type for this row.
3. Click on Apply to add the new en tr y.
To remove entries from either table, select the desired row in the Entry pull-down
box of the corresponding table and click on Delete.
4-14
December 2002 2400-A2-GB20-10
Page 57
SNMP Notifications
4. Using the Web Interface
The Notifications option gives you access to the SNMP Notifications page.
Figure 4-9. SNMP Notifications
This page allows you to view and modify information in the SNMP Notify Table,
SNMP Notify Filter Profile Table, and the SNMP Notify Filter Table.
In the descriptions that follow, each of the three tables is explained briefly. Then,
examples of SNMP notification and filtering are explained in order to show how the
tables on this web page and the tables on the previous web page are interrelated.
After explaining the general process, instructions are given on how to modify each
of the three tables on this web page.
SNMP Notify Table
This table allows you to set up individual SNMP Notifications and specify the target
addresses from the SNMP Target Addresses Table that should receive the
notifications.
First, an application determines that a certain condition has been met that requires
an SNMP notification to be sent out. This condition has a name associated with it
and it is this name that is used to index into the SNMP Not ify Table.
Then, the tag value from this row in the SNMP Notify T ab le is used to determine all
entries in the SNMP Target Addresses Table, which have this tag value listed in
their tag list. Each match determines a target address that should receive the
notification.
2400-A2-GB20-10 December 2002 4-15
Page 58
4. Using the Web Interface
Procedure
To create a new entry in the SNMP Notify Table:
1. Select New from the Entry pull-down box.
2. Fill in the new information in the following fields:
Field Description
Name Unique string identifier.
Tag Tag value that is used to select entries in the SNMP Target
Addresses Table (see Figure 4-9). For a given val ue in this field, all
target addre sses in the SNMP Target Addresses Table in which the
tag list includes this v alue are selected.
T ype Determines the type of notification to be genera ted. The options are
Trap or Inform.
Storage Type Storage type for this row. The following types are displayed:
other – alternative SNMP storage method
!
volatile – storage los t over power cycle
!
nonVolatile – storage preserv ed to NVRAM ove r power cycle
!
permanent – storage preserved to the disk
!
read-only – no write-access
!
3. Click on Apply to add the new en tr y.
SNMP Notify Filter Table and SNMP Notify Filter Profile Table
These two tables allow you to set up filtering options for each entry in the SNMP
Target Parameters Table. The SNMP Notify Filter Profile Table links entries in the
SNMP Target Parameters Table to entries in the SNMP Notify Filter Table.
When a notification is to be generated and the target addresses that should
receive the notification have been identified, the notification generator then checks
parameters for the each target address in the SNMP Parameters Table.
For each entry that is in the SNMP Target Parameters Table, the notification
generator checks to see if there is an index in the SNMP Notify Filter Profile equal
to the name of the entry in the SNMP Target Parameters Table. If not, filtering is
not performed. If an entry does exist, that SNMP Notify Filter Profile Table entry is
used to index into the SNMP Notify Filter Table.
A row in the SNMP Notify Filter Table defines a family of MIB subtrees. It does this
by using the subtree, mask and type objects. A MIB object plus all objects that are
under it define a MIB subtree.
4-16
December 2002 2400-A2-GB20-10
Page 59
4. Using the Web Interface
Procedure
To create a new entry in the SNMP Notify Filter Profile Table:
1. Select New from the Entry pull-down box.
2. Fill in the new information in the following fields:
Field Description
Name Unique string identifier.
Storage Type Sto rage type for this row.
3. Click on Apply to add the new en tr y.
Procedure
To create a new entry in the SNMP Notify Filter Table:
1. Select New from the Entry pull-down box.
2. Fill in the new information in the following fields:
Field Description
Subtree The MIB subtree to be included/e xcluded from the filter profile.
Mask An octet string representing the bit mask used for
inclusion/exclusion.
Type Indicates whether the family of filter subtrees is included/excluded.
Storage Type Storage type for this row.
3. Click on Apply to add the new en tr y.
To remove entries from a particular table, select the desired row in the Entr y pulldown box of the corresponding table and click on Delete.
2400-A2-GB20-10 December 2002 4-17
Page 60
4. Using the Web Interface
Spanning Tree
The Spanning Tree Protocol is a link management protocol that provides path
redundancy and prevents unwanted loops. Several active paths between stations
in a network create loops in the network. In an Ethernet network, only one active
path can exist between two stations.
To establish path redundancy, the spanning tree protocol creates a tree that spans
all switches in an extended network. The protocol puts redundant data paths into a
standby (blocked) state.
Within Spanning Tree, you can configure the following:
Bridge
!
Ports
!
Spanning Tree Bridge Parameters
The Bridge option allows you to set Spanning Tree Bridge parameters.
Figure 4-10. Spanning Tree Bridge Par ameters
When you create fault-tolerant networks, you must have a loop-free path between
all nodes in the network. If a loop exists in the network, hosts might receive
duplicate messages resulting in an unstable network. The Spanning Tree Protocol
(STP) calculates the best loop-free path throughout a switched network. Switches
send and receive spanning tree frames at regular intervals. The switches do not
forward these frames, but use the frames to construct a loop-free path.
4-18
December 2002 2400-A2-GB20-10
Page 61
4. Using the Web Interface
STP defines a tree with a root switch and a loop-free path fr om the root to all
switches in the network. STP forces redundant data paths into a standby state. If a
network segment in the spanning tree fails and a redundant path exists, the
spanning tree algorithm activates the standby path and recalculates the topology.
This page allows you to configure the spanning tree bridge parameters. It consists
of the following fields:
Field Description
STP Designated
Root
Priority This is the bridge pr iority. It is a decimal number in the range
Hello Time This value determines the frequency with which the switch sends
Forward Delay This value determines the frequency with which a por t changes its
Max Age Specifies maximum age of spanning tr ee information used by all
Root Port This read- only field indicates the port number that offers the lowest
Root Cost This read-only field indicates the cost of the path fro m the switch to
Topology Changes This read-only field indicates the number of topology changes that
This read-onl y fi eld indicates the bridge identifier of the root of the
spanning tree as determined by STP.
0–65535 that determines which device becomes the root bridge.
The default value is 32768.
configur ati on Bri dge Protocol Data Units (BPDUs) when it is the
root of the spanning tree or trying to become so.
forwarding status when moving toward the forwarding stat e. The
value determines how long each port remains in the Lis tening and
Learning states, which precede the Forwarding state.
bridges when this bridge is acting as a root. When spanning tree
informati on is received that is older that this m aximum age, it is
discarded.
cost path from th e switch to the root.
the root.
hav e occurred since the switch has bee n running.
Aging Time The timeout period for aging out dynamically learned forwarding
information.
NOTE:
All time values, with the exception of Aging Time, are specified in hundredths
of a second. Aging Time is specified in seconds.
Click on Apply or Save to activate your ch anges.
2400-A2-GB20-10 December 2002 4-19
Page 62
4. Using the Web Interface
Spanning Tree Port Parameters
The Ports option allows you to set Spanning Tree Ports parameters.
Figure 4-11. Spanning Tree Port Parameters
This page allows you to configure the spanning tree port parameters. To change
parameters for a specific port, select the port number from the Port pull-down box.
The corresponding port information will then be displayed in the editable row of the
table. The following fields are displayed for each port:
Field Description
Enable This field allows you to Enable or Disable STP for this port.
Path Cost This read-only field indicates the path cost fr om the switch to the
root through this port.
Priority T his field specifies the priority for the port. The port with the lowest
priority value has the highest priority and forwards the spanning
tree frames. Priorities are in the range of 0–255 with a defa ult
priority of 128. If all ports have the same priority value, the l owest
port number forwards the spanning tree frames.
Fwd Transitions This read-only field indicates how many times the port has
transitioned to the Forwarding State.
State This field simply reflects the status of the port in the STP
application.
Click on Apply or Save to activate your changes.
4-20
December 2002 2400-A2-GB20-10
Page 63
VLANs/Multicast Groups
Within VLANs/Multicast Groups, you can configure the following:
Current VLAN s
!
Static VLANs
!
VLAN /GVRP Ports
!
Current Multicast Group
!
Static Multicast Groups
!
GARP/GMR P Ports
!
Current VLAN Configuration
The Current VLANs window displays the setup of a ctive VLANs configured in the
Static VLANs option.
–: Not included in VLAN
!
4. Using the Web Interface
M: Member of VLAN
!
F: Forbidden
!
U: Untagged
!
Figure 4-12. Current VLAN Configuration
2400-A2-GB20-10 December 2002 4-21
Page 64
4. Using the Web Interface
This page displays all currently active Vir tual Local Area Networ ks (VLANs)
configured for the switch. The following information is available for each VLAN:
Field Description
VID VLAN ID. This fiel d ind ic a te s the VLAN ID for this gro u p.
FID Filtering ID. This is the filtering databas e used by this VLAN.
Status This field displays the status of the VLAN.
Create Time This is a time stamp indicating when the last VLAN was created
since the last Bit Storm 2400 reb oot. Create time of “0” throughout
all fields means that the VLAN was created by to reboot.
Port Member Status The remaining portion of this row i ndicates the state of each port in
this VLAN. There is a string of twelve characters in this row with
each character representing one port on the switch. The fi rst
character represents port one while the second character
represents port two, etc. The character for a specific port
represents t he state it is in for this VLAN. The foll owing states are
defined:
–: Not included in VLAN
!
M: Member of VLAN (receiv e all designated packets)
!
F: Forbidden Access (will not receive all designated packets)
!
U: Untagged Member
!
Click on Next to view the next page of VLANs or click on Refresh to refresh the list.
Static VLAN Configuration
The Static VLANs option allows you to create and delete static VLANs.
Figure 4-13. Static VLAN Configuration
4-22
December 2002 2400-A2-GB20-10
Page 65
4. Using the Web Interface
You crea te a new static VLAN by filling in the following fields and then clicking on
Apply:
Field Description
Internal VlanId The Internal VLAN ID is used by the EtherLoop Management Agent to
communicate with the modems in the Bi tSt orm 2400. There is no need
to alter it , but it must not m atch any other VLAN IDs defined on the uni t.
VID VLAN ID. This field i ndicates the VLAN ID for this group. It is a decimal
number up to 4 digits long. Do not use the Internal VLAN ID.
Name This is the string name of this VLAN.
Secure This field allows you to put the VLAN int o secure mode. The secure
VLAN is a security mechanism is simil ar to a VLAN per subscriber port,
but is simple r to configur e and m anage because it does not need to be
configured on a per-port basis. When a VLAN is in secure mode,
packe ts receiv ed on mem ber ports are redire cted to the uplink port (26)
and not switched to other members. Conversely, when a VLAN is not in
secure mode, the mem ber ports share pac kets as in a normal VLAN. It
is also important to note that a VLAN’s secure status can be toggled
with an SNMP browser by setting the MIB
private.enterprises.wrs.tms.idb.garpMib.garpMIBObjects.
gDot1qVlanStaticSecureTable.gDot1qVlanStaticSecureEntry.
gDot1qVlanStatic Secur eRowStat us obj ect to act iv e(1) ( or the intege r 1)
or notInService(2) (or the integer 2). However, k eep in mind that y ou
must create and delete static VLANs through the standard VLAN MIBs.
Port Member
Status
The remaining portion of this row allows you to set the state of a
particular port for this VLAN. There is a string of twelve characters in
this field with each character representing one por t on the switch. The
first character represents por t one, the second character represents
port two, etc. The character for a specific port represents the state it is
in for this VLAN. By clic king on the charact er f or a speci fic port, you can
toggle the state for that port. The following sta tes are defined:
–: Not included in group
!
M: Member (receives tagged packets into specified VLAN)
!
F: Forbidden (prevents allocation of packets to specified VLAN)
!
U: Untagged (receives untagged packets and tags the packets with
!
specified VLAN information)
To delete a VLAN, select the group from the list box underneath the VID field.
When you do this, the appropriate information is immediately displayed above. To
confirm deletion of the selected VLAN, you must click on Delete.
2400-A2-GB20-10 December 2002 4-23
Page 66
4. Using the Web Interface
VLAN/GVRP (GARP VLAN Registration Protocol) Port Configuration
The VLAN/GVR P Ports optio n al lows you to mo d ify VLAN/GVRP setti n g s for each
port.
Figure 4-14. VLAN/GVRP Port Configuration
This page lets you modify the VLAN/GVRP configuration for each port. To change
the parameters for a sp ec ific port, select the port number from the Port pull-down
box. Information for that port will then be displayed in the editable row at the top of
the table. You can then modify the following fields:
Field Description
Priority This fie ld specifies the default ingress User Priorit y for this port.
This only has eff ect o n medi a, su ch a s Ethernet , tha t do no t support
native User Priority. This priority also applies to all untagged
frames.
PVID This field specifies the VLAN ID assigned to untagged frames or
Priority-Tagged frames on this port. The VLAN ID must refer to a
valid VLAN in the current VLAN configuration (decimal num ber).
Acceptable Frames This field describes acceptable frames. You can choose all or
tagged-only. When this field is set to tagged-only, the switch will
discard unt agged frames or Prio rity-Tagged frames rece iv ed on this
port. When all is selected , all fra mes will be acc epted and assi gned
to the PVID for this po rt.
4-24
December 2002 2400-A2-GB20-10
Page 67
Field Description
Ingress Filtering This field allows you to Enable or Disable ingress filtering on this
GVRP GARP VLAN Registration Protocol. This field all ows you to Enable
Click on Apply or Save to activate your changes.
Current Multicast Groups
The Current Multicast Groups option displays all active Layer 2+ multicast groups
configured for the BitStorm 2400.
4. Using the Web Interface
port. When this is e nab led, the Bi tStorm 2400 will discard incoming
frames for VLANs, which do not include this port in its member set.
When disabled, the port will accept all incoming frames.
or Disable GVRP operation on this port. If disabled, all GVRP
packets on this port will be silently discarded and no GVRP
registr ati ons will be propagated from other ports.
Figure 4-15. Current Multicast Groups
The following infor mation is available for each multicast group:
Field Description
VID VLAN ID. This field indicates the VLAN ID for this group.
Group MAC Address This field indicates the MAC Address for thi s group in
hexadecimal.
Port Member Status The remaining portion of this row indicates the state of eac h port
for thi s group. There is a string of twelve characters in this field
with each character representing one port on the switch. The first
character represents port one, the second character represents
port two, et c. The character for a specific port represents the
state it is in for this group. The f ollowing states are defined:
–: Not included in group
!
M: Member
!
F: Forbidden
!
Click on Next to view the next page of multicast groups or click on Refresh to
refresh the list.
2400-A2-GB20-10 December 2002 4-25
Page 68
4. Using the Web Interface
Static Multicast Conf igu rat ion
The Static Multicast option allows you to create or d elete static Layer 2 multicast
groups.
Figure 4-16. Static Multicast Con figuration
This page allows you to create and delete static multicast groups. You create a
new group by filling in the following fields and then clicking Apply:
Field Description
VID VLAN ID. This field indicates the VLAN ID for this group. It is a
decimal num ber up to four digit s long.
MAC Address This field indicates the six-byte MAC Address for thi s group in
hexad ecimal/colon format.
Port Member Status The remaining portion of this ro w allows you to set the state of a
particular port for thi s group. There is a string of tw elve characters
in this field with each character representing one port on the
switch. The first character represents port one, the sec ond
character repres ent s port two , et c. The char acter f or a spec ific port
represents the state it i s in for this group. By clicking on the
character for a specifi c port, you can toggle the state for that port.
The foll owing states are defined:
–: Not included in group
!
M: Member
!
F: Forbidden
!
To delete a group, select the group fro m the list box underneath the VID field.
When you do this, the appropriate information is immediately displayed above. To
confirm deletion of the selected group, you must click on Delete.
4-26
December 2002 2400-A2-GB20-10
Page 69
GARP/GMRP Port Conf iguration
GARP (Generic Attribute Registration Protocol) is a protocol that allows a bridge to
receive and propagate declarations from network devices for certain attributes. It
then creates a path between devices. GARP Multicast Registration Protocol
(GMRP) is a Generic Attribute Registration Protocol (GARP) application that
provides a constrained multicast flooding facility similar to IGMP snooping and
CGMP. For protocol operational information, refer to IE EE 802.1p.
GMRP can register and deregister multicast group addresses at the MAC layer
throughout the Layer 2-connected network. GMRP is Layer 3-protocol
independent, which allows it to support the multicast traffic of any La y er 3 protocol
(such as IP, IPX, and so forth).
GARP/GMRP Ports option allows you to modify GARP/GMRP parameters per
The
port.
4. Using the Web Interface
Figure 4-17. GARP/GMRP Port Conf iguration
This page displays information about each port’s GARP/GMRP configuration. To
modify a port’s GARP/GMRP parameters, select the desired port from the port
pull-down menu. That port’s info rmation will be displayed in the editable fields on
the web page. You can then modify the following parameters:
Field Description
Join Time Specifies the GARP join time for the port. Join Time should be
chosen s uch that at least two Join Time peri ods can occur wi thi n the
period of one Leav e Time. The valid range f or this field is 20–20000.
Leave Time Specifies the GARP leave time for the port. The vali d range for this
field is 60–20000.
Leave All Time Specifies the G ARP lea v e all ti me f or the port. Lea v e Al l Time should
be larger than Leave Time. The valid range for this field is 1–20000.
GMRP Allows you to Enable or Disable GMRP for the port.
All time values should be specified in hundredths of seconds. Click on App ly or
Save to activate your modifications.
2400-A2-GB20-10 December 2002 4-27
Page 70
4. Using the Web Interface
4-28
December 2002 2400-A2-GB20-10
Page 71
Monitoring and Troubleshooting
Overview
During operation of the BitStorm 2400, it is possible that errors may occur.
Symptoms and possible solutions are presented in this section to help
troubleshoot problems that may arise.
Table A-1 lists proble m s at startup.
Table A-1. Initial Startup Problems
Symptom Possible Problem Possible Solutions
A
Pow er Cord i s conne cted
to switch, bu t al l LED s,
including the POWER
LED, are of f
Table A-2. Problems after First Power Up
Symptom Possible Problem Possible Solutions
No link to a network
device (the LED for the
connecting port is off)
No power to switch Check that both ends of the power cord are securely
connected to the power source and power socket on the unit.
Verify power at the source using a voltage meter.
If power is being del ivered to the power soc ket but no LEDs
are lit, the unit may have a faulty power supply. Contact your
reseller.
Table A-2 lists problems after y o u fi rst turn the unit on.
A cable-related problem:
Cable is not c ompl iant
!
with specifications
Damaged cable
!
Improperly connected
!
cable
Per form the following ta sks in the following orde r:
Make sure the connectors at both ends of the cable are
!
securely seated.
Make sure the cable is not physically damaged. If it is
!
damaged, replace i t with a similar cable.
Make sure y ou are using the right type of cable
!
(Straight-through or crossover).
Check the cable specifications to make sure the cable you
!
are using compli es.
Improperly functi oning
network inter face card
(NIC) on PC or
workstation
2400-A2-GB20-10 December 2002
Run the diagnost ic su pplied b y the v end or on th e NIC to mak e
sure it is functioning properly. If it is not, replace it.
If the problem continues after these chec ks, call your reseller.
A-1
Page 72
A. Monitoring and Troubleshooting
Table A-3 lists problems when the BitStorm 2400 is running.
Table A-3. P roblems When the BitStorm 2400 is Running
Symptom Possible Problem Possible Solutions
Connection to a network
device is l ost (the LE D for
the connecting po rt is off)
The throughput of data
via the connecti on is les s
than what you expected
A cable-related problem:
Disconnected cable
!
Damaged cable
!
Improperly functi oning
network inter face card
(NIC) on PC or
workstation
The switch might be
connected to a device
which is running slower
than what you expected
Make sure the connectors at both ends of the cable are
securely seated in the desired ports.
Make sure the cable is not physically damaged. If it is
damaged, replace i t with a similar cable.
Run the diagnost ic supp lied b y the vendor on the NIC to make
sure it is functioning properly. If it is not, replace it.
If the problem continues after these chec ks, call your reseller.
Check the other device.
A-2
December 2002 2400-A2-GB20-10
Page 73
SNMP Traps
Overview
The following tables show supported traps for the BitS to rm 2400 and the
associated CO and CPE modems.
Table B-1. SNMP Traps – Shelf Events (1 of 2)
Event Trap Description (Object) MIB
B
Shelf Reset A request to set eloopShelfReset to
reset(2) has been r eceived on the shelf
unit.
Over
low-temperature
condition
Over
high-temperature
condition
Fan speed low Event to notify fan speed has dropped
Shelf power o ut of
voltage range
Event to notify shelf unit temperature is
above the low temperature threshold. It is
an indication/warning that the temperature
is rising for t he unit. Tem perature range is
0 to 50 degrees Celsius (32 to 122 degr ees
Fahrenheit).
Event to notify shelf unit temperature is
above the high temperature theshold. It
indicates th at te mp erature is very high for
the unit. Temperature range is 0 to 50
degrees Celsius (32 to 122 degrees
Fahrenheit).
below the theshol d for the specific fan on
the shelf unit. RPM threshold is 3,800.
Voltage has gone higher or lower t han the
required range. Power range is:
For AC model: 85 to 265 VAC
!
autoranging , 47 to 63 Hz
For DC model: –40.5 to –72 VDC
!
eloopShelfResetEvent
eloopShelfTempWarning
eloopShelfTempVeryHigh
eloopShelfFanSpeedLow
eloopShelfPowerRailOutOfSpec
Primary gigabit
ethernet link down
Alternate gigabit
ethernet link down
Download End Event to notify download operation ends for
2400-A2-GB20-10 December 2002
Event to notify primary gigabit ethernet link
(GigE1) lost for the shelf unit.
Event to notify alternate gigabi t ethernet
link (GigE2) lost for the shelf unit.
the shelf.
eloopShelfGigEWANLossOfSignal
eloopShelfGigEAltWANLossOfSignal
eloopShelfDownLoadEnds
B-1
Page 74
B. SNMP Traps
Table B-1. SNMP Traps – Shelf Events (2 of 2)
Event Trap Description (Object) MIB
Cold Start Warning External power cycle (hardw are reset) of
the device has occurred.
Warm Start Warning The system is resting due to a power
disruption of the reset command.
RFC 1907
RFC 1907
Table B-2. SNMP Traps – BitStorm 2400 Events
Event Trap Description MIB
Upstream rate
below threshold
Downstream rate
below threshold
Clear modem
stats
Modem reset A request to set eloopCOMdmDe viceReset
Modem
training/port
reset
Event to notify that the maximum upstream
rate has dropped bel ow the rate-limiting
threshold.
Event to notify that the maximum
downstream rate has dropped below the
rate-limiting threshold.
A reques t to se t
eloopCOModemIfClear Stats t o clear(2) has
been received.
to reset(2) has bee n recei ved.
A request to set eloopCOMdmIfResetTrng
to reset(2) has been received or a set on
the Spectrum Mgr mode caused a reset
port.
eloopCOMdmUpstreamSpeedLow
eloopCOMdmDownstreamSpeedLow
eloopCOModemIfClearStatsEvent
eloopCOModemIfResetEvent
eloopCOModemIfResetPortEvent
Table B-3. SNMP Traps – CPE Modems Events
Event Trap Description MIB
Modem down The CPE modem Ethernet interface is
down.
Modem up The CPE modem Ethernet interfac e is up. eloopCPEModemEnetLinkUp
Clear modem
stats
Reset modem A request to set eloopCPEModemReset to
A request to set
eloopCPEModemClearSt ats to clear(2) has
been received.
reset(2) has been r eceived.
eloopCPEModemEnetLinkDown
eloopCPEModemClearStatsEvent
eloopCPEModemResetEvent
B-2
December 2002 2400-A2-GB20-10
Page 75
MIB Support
Overview
C
This appendix shows the SNMP addressing scheme and OIDs (Object Identifiers)
and supporte d by the BitStorm 2400 and defined in the following MIBs:
MIB-II (RFC 1213)
!
SNMPv2-MIB (RFC 1907)
!
Bridge-MIB (RFC 1483)
!
RMON-MIB (RFC 1757)
!
P-Bridge-MIB (RFC 2674)
!
Q-Bridge-MIB (RFC 2674)
!
EtherLike-MIB (RFC 2665)
!
TMS-Common-MIB
!
OEM-BCM-5600-MIB
!
IF-MIB (RFC 2233)
!
SNMP-Framework-MIB (RFC 2571)
!
SNMP-MPD-MIB (RFC 2572)
!
SNMP-Target-MIB (RFC 2573)
!
SNMP-Notification-MIB (RFC 2573)
!
SNMP-User-Based-SM-MIB (RFC 2574)
!
on page C-2
on page C-3
on page C-5
on page C-6
on page C-7
on page C-7
on page C-8
on page C-9
on page C-9
on page C-10
on page C-10
on page C-11
on page C-10
on page C-11
on page C-11
SNMP-View-Based-ACM-MIB (RFC 2575)
!
2400-A2-GB20-10 December 2002
on page C-11
C-1
Page 76
C. MIB Support
SNMP Addressing Scheme
The example template below demonstrates the numbering scheme for the
BitStorm 2400.
Example template for the Index value: 0xELURSSPP
Where:
0x=hex, E=enterprise (0=WindRiver, 1=Paradyne), L=layer (1=CO Device,
2=CO Interface), U=stack unit #, R=reserved (zero), SS=slot#, PP=port#
— For CO MODEMS: Index = 0x11U0SS01
— For ETHERLOOP PORTS: Index = 0x12U0SSPP
MIB-II (RFC 1213)
MIB-II is defined in RFC 1213. It comprises the following groups.
Table C-1. MIB -II Groups Suppor ted
Group OID Supported
system mib-2 1 Yes, as in RFC 1907.
interfaces mib-2 2 Yes, as in RFC 2863.
at mib-2 3 No
ip mib-2 4 Yes, as in RFC 2011.
icmp mi b-2 5 Yes, as in RFC 2011.
tcp mib-2 6 Yes, as in RFC 2012.
udp mib-2 7 Yes, as in RFC 2013.
egp mib-2 8 No
cmot mib-2 9 No
transmission mib-2 10 No
snmp mib-2 11 Yes, as in RFC 1907.
C-2
December 2002 2400-A2-GB20-10
Page 77
C. MIB Support
SNMPv2-MIB (RFC 1907)
The MIB for SNMPv2 is defined in RFC 1907. The following groups are supported:
system (OID mib-2 1)
!
snmp (OID mib-2 11)
!
System Group
The system group is a collection of objects common to all managed systems.
Table C-2. System Group OIDs
Object OID Syntax Access Status Supported
sysDescr { system 1 } DisplayString read-only current Yes
sysObjectID { system 2 } OBJECT IDENTIFIER read-only current Yes
sysUpTime { system 3 } TimerTicks read-only current Yes
sysContact { system 4 } DisplayString read-write current Yes
sysName { system 5 } DisplayString read-write current Yes
sysLocation {system 6 } DisplayString read-write current Yes
sysServices { system 7 } Integer read-only current Yes
sysORLast Change { system 8 } TimeStamp read-only current No
sysORTable { system 9 } Sequence of sysOREntry no t-
accessible
current No
sysDescr
The sysDescr object provides the full name and version identification for the
systems hardware and software.
sysObjectID
The sysObjectID is the vendor’s identifier for a system component. The following is
the sysObjectID OID tree for the BitStorm family. 1.3.6.1.4.1.1795
.
OID
1.3.6.1.4.1.1795.1.14.17 BitStorm
is the enterprise
1.3.6.1.4.1.1795.1.14.17.1 Stack
1.3.6.1.4.1.1795.1.14.17.1.1 U nit
2400-A2-GB20-10 December 2002 C-3
Page 78
C. MIB Support
SNMP Group
The SNMP group provides instrumentation and control of an SNMP entity.
Table C-3. SNMP Group OIDs
Object OID Syntax Access Status Supported
snmpInPkts { snmp 1} Counter32 read-only current Yes
snmpOutPkts { snmp 2} Counter32 read-only obsolete No
snmpInBadVersions { snmp 3} Counter32 read-only current Yes
snmpInBadCommunity Nam es { snmp 4} Counter32 read-only current Yes
snmpInBadCommunityUses { snmp 5 } Counter32 read-only current Yes
snmpInASNParseErrs { snmp 6 } Counter32 r ead-only current Yes
snmpInTooBigs { snmp 8 } Counter read-only obsolete No
snmpInNoSuchNames { snmp 9 } Counter read-only obsolete No
snmpInBadValues { snmp 10 } Counter read-only obsolete No
snmpInReadOnlys { snmp 11 } Counter read-only obsolete No
snmpInGenErrs { snmp 12 } Counter read-only obsolete No
snmpInTotalReqVars { snmp 13 } Counter read-only obsolete No
snmpInTotalSetVars { snmp 14 } Counter read-only obsolete No
snmpInGetRequests { snmp 15 } Counter read-only obsolete No
snmpInGetNexts { snmp 16 } Counter read-only obsolete No
snmpInSetRequests { snmp 17 } Counter read-only obsolete No
snmpInGetResponses { snmp 18 } Counter read-only obsolete No
snmpInTraps { snmp 19 } Counter read-only obsolete No
snmpOutTooBigs { snmp 20 } Counter read-only obsolete No
snmpOutNoSuchNames { snmp 21 } Counter read-only obsolete No
snmpOutBadValues { snmp 22 } Counter read-only obsolete No
snmpOutGenErrs { snmp 24 } Counter read-only obsolete No
snmpOutGetRequests { snmp 25 } Counter read-only obsolete No
snmpOutGetNexts { snmp 26 } Counter read-only obsolete No
snmpOutSetRequests { snmp 27 } Counter read-only obsolete No
snmpOutGetResponses { snmp 28 } Counter read-only obsolete No
snmpOutTraps { snmp 29 } Counter read-only obsolete No
snnpEnableAuthenTraps { snmp 30 } Integer read-write current Yes
snmpSilentDrops { snmp 31 } Counter32 read-only current Yes
snmpProxyDrops { snmp 31 } Counter32 read-only current Yes
C-4
December 2002 2400-A2-GB20-10
Page 79
C. MIB Support
Bridge-MIB (RFC 1483)
The Bridge-MIB is defined in RFC 1483. It defines objects for managing MAC
bridges.
The following groups are supported:
dot1dBase (OID dot1dBridge 1)
!
dot1dTp (OID dot1dBridge 4)
!
dot1dBase
The dot1dBase group contains objects applicable to all types of bridges.
Table C-4. dot1dBase Group
Object OID Syntax Access Status Supported
dot1dBaseBridgeAddress { dot1dBase 1 } MacAddress read-only mandatory No
dot1dBaseNumPorts { dot1dBase 2 } Integer read-only mandatory Yes
dot1dBaseType { dot1dBase 3 } Integer read-only mandatory Yes
dot1dBaseP ortTable { dot1dBase 4 } Sequence of
dot1dBasePort Entry
not-accessible mandatory No
dot1dBaseNumPorts
Each chassis has the following bridge ports:
Port s: 1–24
!
Ethernet Management Port
!
Ethernet Downlink Por t
!
Ethernet Uplink Port
!
V. 35/ X.21 Port (if installed)
!
2400-A2-GB20-10 December 2002 C-5
Page 80
C. MIB Support
dot1dTp Group
The dot1dTp group describes an entity’s state with respect to transparent bridging.
Table C-5. dot1 dTp Group
Object OID Syntax Access Status Supported
dot1dTpLearnedEntity
Discards
dot1dTpAgingTime { dot1dTp 2 } Integer read-write mandatory Yes
dot1dTpFdbTable { dot1dTp 3 } Sequence of
dot1dTpPortTable { dot1dTp 4 } Sequence of
{ dot1dTp 1 } C ounter read-only mandatory No
dot1dTpFdbEntry
dot1dTpPortEntry
notaccessible
notaccessible
mandatory Yes
mandatory Yes
RMON-MIB (R F C 1757)
The RMON MIB is defined in RFC 1155, RFC 1212, RFC 1213, and RFC 1215. It
a remote monitoring MIB that provides interoperability between devices and
management stations running SNMP.
Table C-6. RMON-MIB
Object OID Syntax Access Status Supported
etherStatsTable Sequence of
EtherStatsEntry
etherStatsEntry Sequence of
EtherStatsEntry
notaccessible
notaccessible
mandatory
mandatory
etherStatsIndex { etherStatsEntry 1 } Integer read-only mandatory
etherStatsDataSource { etherStatsEntry 2 } Object Identifier read-write mandatory
etherStatsDropEvents { etherStatsEntry 3 } Counter read-only mandatory
etherStatsOctets { etherStatsEntry 4 } Counter read-only mandatory
etherStatsPkts { etherStatsEntry 5 } Counter read-only mandatory
etherStatsBroadcastPkts { etherStatsEntry 6 } Counter read-only m andatory
etherStatsMulticastPkts { etherStatsEntry 7 } Counter read-only mandatory
etherStatsCRCAlignErrors { etherStatsEntry 8 } Counter read-only mandatory
etherStatsUndersizePkts { etherStatsEntry 9 } Counter read-only mandatory
etherStatsOversizePkts { etherStatsEntry 10 } Counter read-only mandatory
etherStatsFragments { etherStatsEntry 11 } Counter read-only mandatory
etherStatsJ abbers { etherStatsEntry 12 } Counter read-only mandatory
etherStatsCollisions { etherSta tsEntry 13 } Counter read-only mandatory
etherStatsPkts64Octets { etherSta tsEntry 14 } Counter read-only mandatory
C-6
December 2002 2400-A2-GB20-10
Page 81
C. MIB Support
P-Bridge-MIB (RFC 2674)
The P-Bridge-MIB is the MIB Extension module for managing Priority and
Multicast Filtering, defined by IEEE 802.1D-1998.
Table C-7. P-Bridge-MIB
Object OID Syntax Access Status Supported
dot1dPortDefaultUser
Priority
dot1dPortNumTraffic
Classes
{ dot1dPortPriority
Entry 1 }
{ dot1dPortPriority
Entry 2 }
Integer read-write current
Integer read-write current
Q-Bridge-MIB (RFC 2674)
The Q-Bridge-MIB is the VLAN Bridge MIB modu le for managing Vir tual Br idged
Local Area Networks, as defined by IEEE 802.1Q-1998.
Table C-8. Q-Bridge-MIB
Object OID Syntax Access Status Supported
dot1qFdbId { dot1qFdbEntry 1 } Unsigned32 not-accessib le current
dot1qFdbDynamicCount { dot1qFdbEntry 2 } Counter read-only current
2400-A2-GB20-10 December 2002 C-7
Page 82
C. MIB Support
EtherLike-MIB (RFC 2665)
The Ethernet-Like MIB is defined in RFC 2665. It comprises the following objects.
Table C-9. EtherLike- MIB
Object O ID Syntax Access Status Supported
dot3StatsTable {dot3 2 } Sequence of dot3StatsEntry not-accessible current Yes
dot3CollTable { dot3 5 } Sequence of dot 3CollEntry not-accessible current No
dot3ControlTable { dot3 9 } Sequen ce of dot 3ControlEntry not-accessible current No
dot3Pau seTable { dot3 10 } Sequence of dot3PauseEntry not-acce ssible current Yes
dot3Tests { dot3 6 } N/A not-accessible current No
dot3Errors { dot3 7 } N/A not-accessible current No
dot3StatsTable
The dot3StatsTable contains statistics for a group of Ethernet devices.
Object OID Syntax Access Status Supported
dot3StatsIndex { dot3StatsEntry 1 } I nterfaceIndex read-only current Yes
dot3StatsAlignmentErrors { dot3StatsEntry 2 } Counter32 read-only current Yes
dot3StatsFCSErrors { dot3StatsEntry 3 } Counter32 read-only current Yes
dot3StatsSingleCollisionFrames { dot3StatsEntr y 4 } Counter32 read-only current Yes
dot3StatsMultipleCollisionsFrames { dot3StatsEntry 5 } Counter32 read-only current Yes
dot3StatsSQETestErrors { dot3StatsEntry 6 } Counter32 read-only current No
dot3StatsDeferredTransmissions { dot3StatsEntry 7 } Counter32 read-only current Yes
dot3StatsLateCollisions { dot3StatsEntry 8 } Counter32 read-only current Yes
dot3StatsExcessiveCollisions { dot3StatsEntry 9 } Counter32 read-only current Yes
dot3StatsInternalMacTransmitErrors { dot3StatsEntry 10 } Counter32 read-only current No
dot3StatsCarrierSenseErrors { dot3StatsEntry 11 } Counter32 r ead-only current No
dot3StatsFrameTooLongs { dot3StatsEntr y 13 } Counter32 read-only current Yes
dot3StatsInternalMacReceiveErrors { dot3StatsEntry 16 } Counter32 read-only current No
dot3StatsEtherChipSet { dot3StatsEntry 17 } Object
Identifier
read-only depreca
ted
No
dot3StatsSymbolErrors { dot3StatsEntry 18 } Counter32 r ead-only current No
dot3StatsDuplexStatus { dot3StatsEntry 19 } Integer read-only current Yes
C-8
December 2002 2400-A2-GB20-10
Page 83
C. MIB Support
TMS-Common-M IB
The TMS-Common-MIB comprises the f ollowing:
Table C-10. TMS-Common-MIB
Conformance Group Supported MIB Defined Comment
tmsCommonVerGroup yes mandatory retrieve MIB version information
tmsCommonIPGroup yes mandatory configure and retrieve IP connectivity
parameters
tmsCommonLoadGroup yes mandatory configure file download/upload parameters
tmsCommonMiscGroup yes mandatory configure and retrieve miscellaneous item s
tmsCommonCommToViewGroup yes mandatory configure/re trieve community-to-view SNMP info
tmsCommonIgmpSnoopGroup yes mandatory monitors IGMP Snooping info
9
OEM-BCM-5600-MIB
The OEM-BCM-5600-MIB comprises the following:
Table C-11. OEM-BCM-5600-MIB
Conformance Group Suppor ted MIB Defined Com m ent
oemArchIfaceGrou yes mandatory configure and retrieve interface info
oemChipGroup yes optional chipset specific groups – place holder only
2400-A2-GB20-10 December 2002 C-9
Page 84
C. MIB Support
IF-MIB (RFC 2233)
The IF-MIB is defined in RFC 2233. It comprises the following:
Table C-12. IF-MIB
Conformance Support MIB Defined Comment
ifGeneralGroup no deprecated —
ifFixedL engthGroup no mandatory character-oriented 20 Mbps
ifHCFixedL engthGroup no mandatory character-orient ed 20 M bps
ifPacketGroup yes mandatory for packet-oriented network interfaces 20 Mbps
ifHCPacketGroup yes m andatory for packet-oriented network interfaces > 20 Mbps
and 650 M bps
ifVHCPacketGroup yes mandatory for packet-oriented > 650 Mbps
ifRcvAddressG roup yes media-spec applicability is media specific
SNMP-Framework-MIB (RFC 2571)
The SNMP-Framework-MIB is defined in RFC 2571. It comprises the following:
Table C-13. SNMP-F ramework-MI B
Conformance Support MIB Defined Comment
SnmpEngineGroup yes mandatory configuration/timeliness values
SNMP-MPD-M IB (RF C 2572 )
The SNMP-MPD-MIB is defined in RFC 2572. It comprises the following:
Table C-14. SNMP-MPD-MIB
Conformance Support MIB Defined Comment
SnmpMPDGroup yes mandatory remote monitoring of SNMP MPD
C-10
December 2002 2400-A2-GB20-10
Page 85
C. MIB Support
SNMP-Target-MIB (RFC 2573)
The SNMP-Target-MIB is defined in RFC 2573. It comprises the following:
Table C-15. SNMP-Target-MIB
Conformance Support MIB Defined Comment
SnmpTargetBasicGroup yes optional basic remote configuration of management
targets
SnmpTargetResponseGroup yes optional remote response message expected
configuration
SnmpTargetCommandResponderGroup yes mandator y remote management targets configuration
SNMP-Notification-MI B (RFC 2573)
The SNMP-Notification-MIB is defined in RFC 2573. It comprises the following:
Table C-16. SNMP-Notification-MIB
Conformance Support MIB Defined Comment
snmpNotifyGroup yes mandatory defines notifications for each management target
snmpNotifyFilterGroup yes mandatory remote notification filters configuration
SNMP-User-Based-SM-MIB (RFC 2574)
The SNMP-User-Based-SM-MIB is defined in RFC 2574. It comprises the
following:
Table C-17. SNMP-User-Based-SM-MIB
Conformance Support MIB Defined Comment
usmMIBBasicGroup yes mandatory SNMP USM configuration
SNMP-View-Based-ACM-MIB (RFC 2575)
The SNMP-View-Based-ACM-MIB is defined in RFC 2575. It comprises the
following:
Table C-18. SNMP-View-Based-ACM-MIB
Conformance Support MIB Defined Comment
vacmBasicGroup yes mandatory remote SNMP VACM configuration
2400-A2-GB20-10 December 2002 C-11
Page 86
C. MIB Support
C-12
December 2002 2400-A2-GB20-10
Page 87
Index
A
Acceptable Frames, 4-24
asynchronous terminal interface, 3-1
B
baud rate, 3-9
Bridge-MIB, C-5
Burst size, 1- 3
C
Change Password screen, 3-10
Configuration File Upload/Download screen, 3-7
Craft interface, 3-1
Current Multicast Groups
Web Interface, 4-25
Current VLAN Configuration
Web Interface, 4-21
D
Dais y-chai ning, 2-2
Data Rate Limiting, 1-3
Downstream Traffic, 1-6
E
EtherLoop
configuration, 3-11
Conf i g u r a tion screen, 3-12
described, 1-3
Main Menu screen, 3-11
Training Mode scr een, 3-12
Ethernet-Like MIB, C-8
F
Features, 1-2
G
GARP (Generic Attribut e Registration Protocol), 4-27
GARP/GMRP Port Configuration
Web Interface, 4-27
GMRP (GARP Multicast Registration Protocol), 4-27
GVRP (GARP VLAN Registration Protocol), 4-25
I
IF-MIB, C-10
IGMP, 1-9
General Query message , 1-15
Group-to-Interface Table, 1-15
Leave Messages, 1-15
Report Messages, 1-14
V1, 1-12
V2, 1-13
Image File Download screen, 3-8
Ingress Filtering, 4-25
IP Multicast, 1-8–1-9
L
Layer 2 CoS Support, 1-5
Login screen, 3-2
Login, Web Interface, 4-1
M
MAC Address Mapping, 1-10
MAC Layer Filtering, 1-16
Main Menu screen, 3-3
Management Configurat ion
Web Interface, 4-3
Menu Options, 3-1
MIBs, B-1, C-1
Bridge, C-5
Ethernet-Like, C-8
IF, C-10
MIB-II, C-2
OEM-BCM-5600, C-9
P-Bridge, C-7
Q-Br idge, C-7
RMON , C-6
SNMP-Framework, C-10
SNMP-MPD, C-10
SNMP-Notification, C-11
SNMP-Target, C-11
SNMP-User-Based-SM, C-11
SNMPv2, C-3
SNMP-View-Based-ACM, C-11
TMS-Common, C-9
-
-
-
-
Page 88
Index
Multicast
Group Membershi p Managem ent, 1-10
Implementati on, 1-14
IP Address, 1-10
Support, 1-8–1-9
Traffic Routing, 1-10
N
Notification
Web Interface, 4-11
O
OEM-BCM-5600-MIB, C-9
P
Password
changing, 3-10
Web Interface, 4-11
P-Bridge-MIB, C-7
Point-to-point VoIP, 1-8
Port Configuration/Statistics
Web Interface, 4-7
Port Statistics screen, 3-6
Port, defined, 2-1
Priority Queuing, 1-5
Protocols, 1-9
PVID, 4-24
Q
Q-Bridge-MIB, C-7
R
Reference Documents, vi
RMON-MIB, C-6
S
Secure VLAN Mode, 1-8
Serial Configuration
Web Interface, 4-10
Serial Configuration screen, 3-9
SNMP Addressing Scheme , C-2
SNMP Group, C-4
SNMP Notifications
Web Interface, 4-15
SNMP Notify Filter Profile Table, 4-16
SNMP Notify Filter Table, 4-16
SNMP Notify Table, 4-15
SNMP Targets
Web Interface, 4-12
SNMP Traps, B-1
BitStorm 2400 Events, B-2
CPE Modems Events, B-2
SNMP -F ra mework- M IB , C-10
SNMP-MPD-MIB, C-10
SNMP-Notification-MIB, C-11
SNMP-Target-MIB, C-11
SNMP-User-Based-SM-MIB, C-11
SNMP-View-Based-ACM-MIB, C-11
Spanning Tree Bridge Param eters, 4-18
Spanning Tree Port Parameters, 4-20
Spanning Tree Protocol, 4-18
Spectrum Manager, 1-4
Stack, defined, 2-1
Static Multicast Configuration
Web Interface, 4-26
Static VLAN Configuration
Web Interface, 4-22
Switch Configuration
Web Interface, 4-4
Switch Configurati on screen, 3-4
Switching Fabric, 1-5
sysDescr, C-3
sysObjectID, C-3
System Configuration
Web Interface, 4-6
System Group, C-3
T
Terminal interface, 3-1
Terminology, 2-1
TMS-Common-MIB, C-9
Token Bucket, described, 1-3
Traffic
Dow nstream, 1-6
Upstream, 1-6
Traffic Aggregati on, 1-4
Troubleshooting, A-1
U
Unit, defined, 2-1
Upstream Traffi c, 1-6
V
Video on demand, 1-8
VLAN Support, 1-6
VLAN/GVRP Port Configuration
Web Interface, 4-24
VLANs/Multicast Groups, 4-21
-
-
-
-
Page 89
W
Web Interface, 4-1
Current Multicast Groups, 4-25
Current VLAN Configuration, 4-21
GARP/GMRP Port Configurati on, 4-27
Login, 4-1
Management Configuration, 4-3
Notification, 4-11
Password, 4-11
Port Configuration/Statistics, 4-7
Serial Configuration, 4-10
SNMP Notifications , 4-15
SNMP Targets, 4-12
Static Multica st Conf iguration, 4-26
Switch Configuration, 4-4
System Configura ti on, 4-6
VLAN/GVRP Port Configuration, 4-24
Index
-
Page 90
Index
-
-
-
-
Loading...