61440520E1-5B, Packetwave E510A/E520A Installation and Configuration Guide

PacketWave E510A/E520A Installation and Configuration Guide Document Number: 61440520E1-5B August 2007 PacketWave E510A/E520A Installation and Configuration Guide

Front Matter Trademarks Any brand names and product names included in this document are trademarks, registered trademarks, or trade names of their respective holders. FreeRADIUS is copyrighted by the FreeRADIUS Server Project. Steel-Belted Radius is a registered trademark of Juniper Networks, Inc. IPFirewall and FreeBSD are registered trademarks of The FreeBSD Foundation.

To the Holder of the Document The contents of this document are current as of the date of publication. ADTRAN® reserves the right to change the contents without prior notice. In no event will ADTRAN be liable for any special, incidental, or consequential damages or for commercial losses even if ADTRAN has been advised thereof as a result of issue of this document.

901 Explorer Boulevard P.O. Box 140000 Huntsville, AL 35814-4000 (256) 963-8000

ii 61440520E1-5B Revision History

Revision Date Description

A June 2007 Initial release

B August 2007 Revised environmental specifications.

Conventions The following typographical conventions are used in this document: This font indicates a cross-reference link. This font indicates screen menus, fields, and parameters.

THIS FONT indicates keyboard keys (ENTER, ESC, ALT). Keys that are to be pressed simultaneously are shown with a plus sign (ALT+X indicates that the ALT key and X key should be pressed at the same time). This font indicates references to other documentation and is also used for emphasis. This font indicates on-screen messages and prompts. This font indicates text to be typed exactly as shown. This font indicates silk-screen labels or other system label items. This font is used for strong emphasis.

NOTE Notes inform the user of additional, but essential, information or features.

CAUTION Cautions inform the user of potential damage, malfunction, or disruption to equipment, software, or environment.

WARNING Warnings inform the user of potential bodily pain, injury, or death.

61440520E1-5B iii PacketWave E510A/E520A Installation and Configuration Guide

Federal Communications Commission (FCC) Statement This equipment generates, uses, and can radiate radio frequency energy and if not installed and used in accordance with the instruction manual, may cause interference to radio communications. It has been tested and found to comply with limits for a Class A digital device pursuant to Subpart B of Part 15 of FCC Rules, which are designed to provide a reasonable protection against such interference when operated in a commercial environment. This equipment does not exceed Class A limits for radio emission for digital apparatus, set out in the Radio Interference Regulation of the Canadian Department of Communications.

Training ADTRAN offers training courses on our products. These courses include overviews on product features and functions while covering applications of ADTRAN product lines. ADTRAN provides a variety of training options, including customized training and courses taught at our facilities or at customer sites. For inquiries concerning training, contact ADTRAN: Training Phone: 800-615-1176, ext. 6996 Training Fax: 256-963-6217 Training E-mail: [email protected]

iv 61440520E1-5B Contents

About This Guide...... xv Audience ...... xv How To Use This Guide ...... xv Organization ...... xvi Release Notes...... xvi Reader Advisories ...... xvii Requesting Technical Support...... xvii

Chapter 1 Introduction ...... 1-1 Carrier-class Solutions for Multi-service MANs ...... 1-1 Features and Benefits ...... 1-1 Key Metro Applications...... 1-2 Private Line TDM Transport ...... 1-2 Metro Ethernet Transport ...... 1-2 Transparent LAN Services ...... 1-2 TLS with Traffic Engineering...... 1-2 Innovative PacketWave Architecture...... 1-3 E510A/E520A Delivers Flexibility to the Edge ...... 1-3 Complete System Management ...... 1-3 Resilient Packet Ring Leadership ...... 1-4

Chapter 2 System Overview ...... 2-1 Introduction ...... 2-1 Introducing the PacketWave E510A/E520A ...... 2-2 Architecture ...... 2-2 Features ...... 2-2 PacketWave E510A/E520A Models ...... 2-4 PacketWave E510A/E520A Components...... 2-4 Low-Speed Modules...... 2-5 High-Speed Module ...... 2-5

61440520E1-5B v PacketWave E510A/E520A Installation and Configuration Guide

Fan Tray ...... 2-5 Power Distribution System ...... 2-6 AC Power ...... 2-7 DC Power...... 2-8 Cooling Systems and Fan Tray ...... 2-9 RS-232 Port ...... 2-9 Common Components ...... 2-10 LEDs...... 2-10 MGMT Port ...... 2-10 Interoperability of T1/E1 Cards ...... 2-11 PacketWave Software Components ...... 2-11 CLI...... 2-11 ADTRAN LMS...... 2-12

Chapter 3 Site Installation Preparation ...... 3-1 Safety and Equipment Guidelines ...... 3-2 Safety Considerations...... 3-3 Lifting...... 3-3 Electricity...... 3-3 Materials, Tools and Equipment ...... 3-5 Recommended Materials ...... 3-5 Required Tools and Equipment...... 3-5 Site Requirements ...... 3-6 Equipment Dimensions and Site Layout for the PacketWave E510A/E520A ...... 3-6 Proper Air Flow...... 3-6 Power Connections ...... 3-7 100–240 VAC Supply ...... 3-7 –48 VDC Supply ...... 3-7 Site Wiring...... 3-8 Rack-mounting ...... 3-8 Preparing the Network Worksheet ...... 3-8 Network IP Addresses ...... 3-9 Discovery Node ...... 3-9 Other Nodes...... 3-9 SSH ...... 3-10 RADIUS ...... 3-10 Users ...... 3-10

Chapter 4 PacketWave E510A/E520A Installation ...... 4-1 Before Beginning Installation...... 4-2 Verifying Rack Dimensions ...... 4-2 Unpacking the PacketWave E510A/E520A ...... 4-2 Verifying Package Contents ...... 4-2

vi 61440520E1-5B Contents

Inspecting the E510A/E520A Platform Before Installation ...... 4-3 Installation ...... 4-4 Adjusting Rack Mounting Ears ...... 4-4 Lifting the PacketWave E510A/E520A into the Rack ...... 4-5 Installing the PacketWave E510A/E520A into Rack ...... 4-5 Installing Multiple PacketWave E510A/E520A Platforms into Rack ...... 4-6 Connecting Grounding ...... 4-6 Making Power Connections ...... 4-8 Replacing the PacketWave E510A/E520A Power Module ...... 4-9 Removing AC Power Tray ...... 4-10 Installing AC Power Tray ...... 4-10 Removing DC Power Tray ...... 4-10 Installing DC Power Tray ...... 4-11 Connecting to T1/E1, Ethernet, and RPR ...... 4-11

Chapter 5 System Startup and Configuration ...... 5-1 Network Overview ...... 5-2 Powering up the PacketWave E510A/E520A ...... 5-4 Configuring the PacketWave E510A/E520A ...... 5-6 Connecting to the Resilient Packet Ring...... 5-6 Cabling the Module Ports to the Network ...... 5-7 Cabling Considerations ...... 5-7 Fiber-Optic Interface Cables ...... 5-7 Laser Safety Information ...... 5-8 Connecting the PacketWave E510A/E520A to a Terminal Server or Serial RS-232 Port ...... 5-8 Configuring the Node ...... 5-8 Initial Login ...... 5-8 Configuring the NMS (MGMT Port) IP Address ...... 5-9 Configuring the Node IP Address ...... 5-9 Configuring Security ...... 5-10 Configuring Control Plane (CP) Routes ...... 5-10 Configuring the Discovery Node...... 5-11 Configuring the ADTRAN LMS ...... 5-11 Windows 2000/NT/XP Procedure...... 5-11 Solaris Procedure ...... 5-12 Connecting Nodes to the Management Network (TCP/IP) ...... 5-14 Configuring Services ...... 5-15 Configuring Ring Speed ...... 5-15 Suppressing Pluggable Alarms...... 5-15

Chapter 6 Configuring Security ...... 6-1 Introduction to SecureWave...... 6-2 Security Benefits ...... 6-2

61440520E1-5B vii PacketWave E510A/E520A Installation and Configuration Guide

Remote Access Control ...... 6-2 Authentication ...... 6-3 Authorization ...... 6-3 Accounting ...... 6-3 Architecture ...... 6-4 RADIUS...... 6-4 SSH...... 6-5 Security Database...... 6-5 Firewall ...... 6-5 Fully Configurable Firewall ...... 6-6 Logging Packets for Debugging ...... 6-6 Physical Security...... 6-6 PacketWave Configuration Procedures ...... 6-7 Configuring Telnet, NMS, and SSH ...... 6-7 Verify NMS Access...... 6-7 Verify Telnet Access...... 6-7 Enable SSH (optional) ...... 6-7 Configure Client Keys...... 6-8 Configure Host Keys...... 6-8 Enable SSH ...... 6-9 Run SSH...... 6-9 Configuring RADIUS ...... 6-10 RADIUS Client ...... 6-10 Setup Routes ...... 6-10 Set Logins...... 6-11 Set RADIUS IP Address, Code, and Port...... 6-11 RADIUS Server...... 6-11 FreeRADIUS Setup and Configuration ...... 6-12 Data Fill the RADIUS Dictionary...... 6-12 Setup Clients ...... 6-13 Add Users...... 6-13 Configuration ...... 6-14 Start RADIUS Daemon...... 6-15 Troubleshooting ...... 6-15 Steel-Belted Radius Setup and Configuration...... 6-15 Installing and Configuring Steel-Belted Radius ...... 6-16 Setting Up RAS Clients ...... 6-18 Setting Up Users ...... 6-20 Configuring User Access Rights ...... 6-22 Add Users ...... 6-23 Managing Users ...... 6-25 Displaying Users...... 6-25 Changing Passwords ...... 6-25 Removing Users ...... 6-25 User Access Rights and CLI Usage ...... 6-26 Displaying Access Rights for Commands...... 6-26

viii 61440520E1-5B Contents

Displaying Help...... 6-26 Suppressing Error Messages ...... 6-27 Enabling and Disabling Remote Access Services ...... 6-28 Change IP Address ...... 6-29 Enable SNMP ...... 6-29 Disable Services...... 6-30 Advanced Firewall Configuration ...... 6-31 References ...... 6-32

Appendix A Approvals and Compliance ...... A-1 Federal Communications Commission Regulatory Statement...... A-2 Safety ...... A-2 Electromagnetic Compatibility...... A-2 Reclamation of Hazardous Substances Compliance...... A-3

Appendix B Physical Chassis Specifications ...... B-1 PacketWave E510A/E520A Chassis Specifications ...... B-2 E510A/E520A Hardware Specifications...... B-4 LEDs ...... B-4 T1/E1 LED Behavior...... B-5 RPR I/O...... B-5

Appendix C Optical Power Budget ...... C-1 Optical Fiber Types ...... C-2 Optical Fiber Links and Optical Fiber Assemblies Requirements ...... C-2 Industry Standard Requirements for the Fiber Plant ...... C-3 Splice/Connector Loss and Reflection ...... C-3 Fiber Optic Plant Standard Requirements ...... C-4 Bellcore GR-1312-Core ...... C-4 Bellcore GR-1312-Core ...... C-5 EIA/TIA 568 B.3 Standards ...... C-5 Fiber Optic Plant Characterization Procedures ...... C-7 Optical Attenuation ...... C-7 Optical Return Loss (ORL) ...... C-7 Chromatic Dispersion (CD) ...... C-8 Polarization Mode Dispersion (PMD) ...... C-9 C and L Band Attenuation Profile ...... C-10 Distance Limitations ...... C-10 Power Budget ...... C-11 Approximating the Power Margin ...... C-12

61440520E1-5B ix PacketWave E510A/E520A Installation and Configuration Guide

Power Margin Example...... C-13 Using Statistics to Estimate the Power Budget...... C-13 Additional Power Budget and Attenuation References ...... C-13

Appendix D Connectors and Cabling ...... D-1 Connectors...... D-2 RS-232 Interface Port Connector ...... D-2 MGMT Port (NMS Port)...... D-2 10/100Base-T Connections...... D-3 10/100Base-T, Straight-Through Cabling ...... D-5 10/100Base-T, Crossover Cabling ...... D-6 Fiber-Optic Cables...... D-7 T1/E1 Patch Panel ...... D-8 24xT1/21xE1 Module SCSI-II Connector Pin Assignments ...... D-8

Appendix E Security...... E-1 IPFW howto Document V.0.2 ...... E-2 Basic IPFW(8) Rule Syntax...... E-2 Listing Rules ...... E-2 Basic Commands and Actions ...... E-2 Specifying Protocols ...... E-4 Specifying the Source and Destination Addresses...... E-4 Introduction to Bitmasks and Netmasks...... E-5 Specifying Ports and Port Ranges ...... E-5 Advanced IPFW(8) Rule Syntax ...... E-6 “Unreach” Action...... E-6 Interface and Flow Control ...... E-7 Matching Specific ICMP and TCP Packet Types ...... E-7 Icmptypes...... E-7 Tcpflags, Setup and Established ...... E-8 Ipoptions...... E-9 Logging ...... E-9 Logging Issues ...... E-9 Rule Logging Configuration ...... E-10 Introduction to Stateless and Stateful Filtering ...... E-11 Basic Stateful Configuration ...... E-11 Advanced Stateful Configuration ...... E-12 Anatomy of a Dynamic Rule ...... E-16 Licenses ...... E-18 OpenSSL...... E-18 Original SSLeay ...... E-18 OpenSSH ...... E-19 Radclient 0.3.1 ...... E-21

x 61440520E1-5B Contents

Appendix F Module Specifications...... F-1 Overview...... F-2 Modules ...... F-3 Inserting Modules ...... F-3 Switching Modules ...... F-3 CLI Procedure ...... F-3 ADTRAN LMS Procedure...... F-3 Hot Swapping Modules ...... F-5 Troubleshooting Modules ...... F-5 8-Port T1/E1 Module...... F-6 24-Port T1/21-Port E1 Module ...... F-6 Single Port Gigabit Ethernet Module...... F-7 Copper SFP ...... F-7 Dual Port Gigabit Ethernet Module ...... F-8

Appendix G Warranty ...... G-1 Warranty and Customer Service ...... G-1 ADTRAN Sales ...... G-1 ADTRAN Technical Support ...... G-1 ADTRAN Repair/CAPS...... G-1 Repair and Return Address...... G-1

Appendix H Glossary ...... H-1

61440520E1-5B xi PacketWave E510A/E520A Installation and Configuration Guide

Figures

Figure 2-1. Traffic Network Architecture of the PacketWave E510A/E520A ...... 2-2 Figure 2-2. PacketWave E510A Front View ...... 2-4 Figure 2-3. PacketWave E520A Front View ...... 2-5 Figure 2-4. PacketWave E510A/E520A Back View, AC Power Shown ...... 2-6 Figure 2-5. AC Power Distribution System (Standby) ...... 2-7 Figure 2-6. AC Power Distribution System (Non-standby) ...... 2-7 Figure 2-7. DC Power Distribution System (Non-standby) ...... 2-8 Figure 2-8. DC Power Distribution System (Standby) ...... 2-8 Figure 4-1. Positions for the Rack Mounting Ears ...... 4-4 Figure 4-2. Grounding Points (AC Power Shown) ...... 4-7 Figure 4-3. Grounding Points and DC Power Connections ...... 4-8 Figure 4-4. E520A Front Panel Connections ...... 4-11 Figure 5-1. Two-Ring Configuration ...... 5-2 Figure 5-2. Three-Ring Node Fiber Connections ...... 5-4 Figure 5-3. AC Power Switches ...... 5-5 Figure 5-4. DC Power Switches ...... 5-5 Figure 5-5. RPR Connections on E510A/E520A ...... 5-6 Figure 5-6. RS-232 Port on PacketWave E510A/E520A ...... 5-8 Figure 5-7. Management Port on E510A/E520A ...... 5-14 Figure 6-1. Security Architecture ...... 6-4 Figure 6-2. Steel-Belted Radius Administrator, Connection Established ...... 6-17 Figure 6-3. Steel-Belted Radius Administrator, RAS Clients ...... 6-18 Figure 6-4. Steel-Belted Radius, Add New RAS Client window ...... 6-18 Figure 6-5. Steel-Belted Radius Administrator, RAS Clients ...... 6-19 Figure 6-6. Steel-Belted Radius, Enter Shared Secret ...... 6-19 Figure 6-7. Steel-Belted Radius, Users Window ...... 6-20 Figure 6-8. Steel-Belted Radius, Add New User ...... 6-20 Figure 6-9. Steel-Belted Radius, New User Created ...... 6-21 Figure 6-10. Steel-Belted Radius, Enter User Password ...... 6-21 Figure 6-11. Add New Attribute Window for Setting User Rights ...... 6-22 Figure B-1. PacketWave E510A Front View ...... B-4 Figure B-2. PacketWave E520A Front View ...... B-4 Figure C-1. Example of Satisfactory Fiber ...... C-3 Figure C-2. Example of Non-Satisfactory Fiber ...... C-4 Figure D-1. RS-232 (DB-9) Pin Assignments ...... D-2 Figure D-2. MGMT Port Connector ...... D-2 Figure D-3. RJ-45 Connector, Cable, and Pinouts ...... D-3 Figure D-4. RJ-45 Connector, Cable, and Pinouts ...... D-3 Figure D-5. 10/100Base-T Straight-Through Pinouts ...... D-5 Figure D-6. 10/100Base-T Crossover Cable ...... D-6 Figure D-7. Multi-Mode Duplex LC Cable ...... D-7 Figure D-8. Single-Mode Simplex LC Cable ...... D-7 Figure F-1. Slot Type of Not Present in Tree View ...... F-3 Figure F-2. Selecting Slot Manager ...... F-4 Figure F-3. Slot Manager Window, Slot Type Auto ...... F-4

xii 61440520E1-5B Contents

Figure F-4. Slot Manager Window, Slot Type None ...... F-5 Figure F-5. 8-Port T1/E1 Module ...... F-6 Figure F-6. 24-Port T1/21-Port E1 Module ...... F-6 Figure F-7. Single Port Gigabit Ethernet Module ...... F-7 Figure F-8. Dual Port Gigabit Ethernet module ...... F-8

61440520E1-5B xiii PacketWave E510A/E520A Installation and Configuration Guide

Tables

Table 1-1. Physical Specifications ...... 1-3 Table 2-1. PacketWave E510A/E520A Features ...... 2-3 Table 2-2. T1/E1 Card Interoperability Summary ...... 2-11 Table 5-1. E510A/E520A Timing Options ...... 5-3 Table 6-1. Access Rights ...... 6-13 Table 6-2. Composite Rights ...... 6-14 Table 6-3. Access Rights ...... 6-23 Table 6-4. Example of Services Enabled and Disabled on Ring ...... 6-28 Table A-1. Names/Content of Toxic and Hazardous Substances or Elements (for Enclosures) A-3 Table A-2. Names/Content of Toxic and Hazardous Substances or Elements (for Enclosures), Chinese A-3 Table A-3. Names/Content of Toxic and Hazardous Substances or Elements (for Modules) A-4 Table A-4. Names/Content of Toxic and Hazardous Substances or Elements (for Modules), Chinese A-4 Table B-1. Physical Specifications ...... B-2 Table B-2. Chassis Configuration ...... B-2 Table B-3. Power Specifications ...... B-3 Table B-4. Regulatory Specifications ...... B-3 Table B-5. Environmental Characteristics ...... B-3 Table C-1. PMD Specifications ...... C-10 Table C-2. Example of Optical Characteristics for an Intermediate Reach, Single-Mode Fiber Transceiver C-10 Table C-3. Optical-Fiber Cable Factors of Attenuation and Dispersion Limits, Typical ...... C-11 Table C-4. Optical Power Parameters for Single-Mode Transmission, Worst Case ...... C-12 Table C-5. Contributing Factors to Link Loss and Estimated Link Loss Values ...... C-12 Table D-1. 10/100Base-T Ethernet Ports, RJ-45 Pinouts (MDI-X) ...... D-4 Table D-2. 10/100Base-T Straight-Through Cable Pin Assignments ...... D-5 Table D-3. 10/100Base-T Crossover Cable ...... D-6 Table D-4. SCSI-II Connector Pin Assignments ...... D-8 Table F-1. Module Slots ...... F-2

xiv 61440520E1-5B About This Guide

This guide provides the needed technical information to install and configure the ADTRAN PacketWave E510A and E520A. The PacketWave E510A/E520A is a compact solution for service providers to provide consolidated IP and TDM services over a packet infrastructure using Resilient Packet Transport™ (RPT) technology, a superset of the Resilient Packet Ring (RPR) protocol (IEEE 802.17). PacketWave platforms can be deployed over a broad spectrum of customers to aggregate traffic in metro and national POPs where individual users can be satisfied.

AUDIENCE The audience for this guide is field service personnel who are responsible for installing the PacketWave E510A/E520A and administrators who will be configuring the system. Field service personnel responsible for installing the PacketWave E510A/E520A must have experience with hardware component installation and an understanding of basic telecommunications and networking principles.

HOW TO USE THIS GUIDE This document contains detailed and procedural information describing the setup and configuration of the PacketWave E510A/E520A platform. Each of the procedures for setting up the PacketWave E510A/E520A are written in a task-oriented format consisting of numbered step- by-step instructions enabling you to perform a series of actions to accomplish a stated objective. In most cases, several different procedures are required to complete one overall task. Where applicable, navigation aids may also refer you to supplemental information such as figures, tables, and other procedures in this document or another document.

61440520E1-5B xv PacketWave E510A/E520A Installation and Configuration Guide

Organization This document is organized as follows: • “Chapter 1, Introduction” - Provides overview information on the PacketWave E510A/ E520A platform and its capabilities. • “Chapter 2, System Overview” - Provides information on the PacketWave E510A/E520A platform, including architectural overview and hardware/software descriptions. • “Chapter 3, Site Installation Preparation” - Describes safety considerations and tools required for installing the PacketWave E510A/E520A. • “Chapter 4, PacketWave E510A/E520A Installation” - Provides installation instructions for the PacketWave E510A/E520A. • “Chapter 5, System Startup and Configuration” - Provides instructions for connecting and configuring the PacketWave E510A/E520A equipment to your network prior to configuring the software. • “Chapter 6, Configuring Security” - Provides information on configuring SecureWave (a fully-integrated security solution for the PacketWave E510A/E520A), Secure SHell, and authentication using RADIUS. • “Appendix A, Approvals and Compliance” - Lists agency approvals, compliance, and related warnings to the PacketWave E510A/E520A. • “Appendix B, Physical Chassis Specifications” - Provides specifications related to the hardware and operation of the PacketWave E510A/E520A. • “Appendix C, Optical Power Budget” - Provides details on specific optical fiber types and specifications on optical power budget values related to operation of the PacketWave E510A/E520A. • “Appendix D, Connectors and Cabling” - Provides cabling information for connecting the PacketWave E510A/E520A to your network. • “Appendix E, Security” - Provides command syntax information on the IPFW application for configuring security on the PacketWave E510A/E520A. • “Appendix F, Module Specifications” - Provides a list of features and specifications for the modules that are supported in the PacketWave E510A/E520A. • “Appendix G, Warranty” - Provides information on ADTRAN’s warranty policy as well as contact information for Sales, Technical Support, and Return for Repairs/Upgrades. • “Appendix H, Glossary” - Provides a glossary of terms and acronyms used in this document.

Release Notes This document is revised only at major releases and, therefore, may not always contain the latest product information. If needed, release notes will be provided between major releases to describe any new information or document changes.

xvi 61440520E1-5B , -

READER ADVISORIES Reader advisories used in this guide are shown below.

NOTE Notes inform the user of additional but essential information or features.

CAUTION Cautions inform the user of potential damage, malfunction, or disruption to equipment, software, or environment.

WARNING Warnings inform the user of potential bodily pain, injury, or death.

REQUESTING TECHNICAL SUPPORT If you need technical support, call your distributor or the technical support expert within your organization first. Follow your organization’s procedures. Refer to “Appendix G, Warranty” for information about contacting ADTRAN Technical Support.

61440520E1-5B xvii PacketWave E510A/E520A Installation and Configuration Guide

This page is intentionally blank.

xviii 61440520E1-5B Chapter 1 Introduction

CARRIER-CLASS SOLUTIONS FOR MULTI-SERVICE MANS The PacketWave E510A/E520A provides full support for legacy voice and TDM circuit services while delivering new differentiated Ethernet and IP services in an efficient, cost-effective platform. The E510A/E520A delivers a new level of cost/performance to Metropolitan Area Network (MAN) service providers. The E510A/E520A features an expandable design, allowing scalable deployment for a mix of Time Division Multiplexing (TDM) and data services. Targeted for mid-sized enterprise customers, Multi-Tenant Units (MTUs), and campus networks, the PacketWave E510A/E520A can be deployed in Resilient Packet Ring (RPR) topologies, providing service restoration from network outages in less than 50 milliseconds.

FEATURES AND BENEFITS • Cost-effective solution, optimized for IP, Ethernet, and TDM transport • Flexible SLAs - three classes of service on a per port and sub-port basis • Support for both VLANs and TLS • 8-port 10/100 Ethernet fixed interfaces • Modular design with two expansion slots • T1/E1 modules for delivery of toll-quality voice services • Gigabit Ethernet modules (single port and dual port) for high-speed Ethernet • Ring protection in less than 50 milliseconds • Compact size (1.5 RU) increases deployment flexibility • High density logical ports • Stratum-quality timing distribution

61440520E1-5B 1-1 PacketWave E510A/E520A Installation and Configuration Guide

KEY METRO APPLICATIONS The following sections describe the key metro applications of the PacketWave E510A/E520A: • “Private Line TDM Transport” • “Metro Ethernet Transport” • “Transparent LAN Services” • “TLS with Traffic Engineering”

Private Line TDM Transport The PacketWave E510A/E520A provides support for toll-quality T1/E1 TDM services with complete Stratum synchronization (via a PacketWave M-Series or C-Series) and extremely low latency and jitter. Standard testing functions such as loop-back and BERT are provided along with on-demand service activation and performance monitoring. PacketWave M-Series or C- Series nodes can be used as aggregation points for an access ring of multiple E510A/E520A devices. ADTRAN uses Resilient Packet Transport (RPT) technology (a superset of RPR protocol IEEE 802.17) to deliver TDM services in a packet optimized network, making much more effective use of network bandwidth than traditional SONET/SDH.

Metro Ethernet Transport The PacketWave E510A/E520A is optimized for Ethernet transport and comes with eight fixed 10/100 Fast Ethernet ports, as well as a slot for a Gigabit Ethernet module. Each port supports a large number of sub-ports, each with its own Quality of Service (QoS) parameters, enabling high service densities on a single platform. Service flows are identified either by VLAN tags or MPLS labels which map to logical ports (or sub-ports). Each sub-port is assigned to one of three Classes of Service (CoS): Expedited Forwarding (EF), Assured Forwarding (AF), and Best Effort (BE). Integrated provisioning and bandwidth management are provided by the ADTRAN LMS network management system.

Transparent LAN Services ADTRAN’s Transparent LAN Service (TLS) provides a true LAN across the metro network: multiple points on separate nodes that are seamlessly connected, with full separation of customer traffic. TLS supports both unicast and broadcast traffic, with MAC address learning for efficient use of network bandwidth. Integrated bandwidth management and point-and- click provisioning are provided by the ADTRAN LMS network management system.

TLS with Traffic Engineering TLS-TE is a new service for providing L2 VPN connectivity. It is offered in addition to the existing TLS (multipoint-to-multipoint unresourced) service. TLS-TE is Transparent LAN Service with Traffic Engineering, which extends the existing TLS service by providing guaranteed traffic assurances and better control of bandwidth resources in the network. TLS- TE supports two classes of services: Assured Forwarding (AF) and Best Effort (BE). TLS-TE with AF provides a guaranteed assurance for the traffic within the L2 VPN. TLS-TE can also be used with BE to provide a better bandwidth provisioning model to conserve bandwidth and, as a result, support more services.

1-2 61440520E1-5B Chapter 1, Introduction - Innovative PacketWave Architecture

INNOVATIVE PACKETWAVE ARCHITECTURE The following sections describe the PacketWave architecture: • “E510A/E520A Delivers Flexibility to the Edge” • “Complete System Management” • “Resilient Packet Ring Leadership”

E510A/E520A Delivers Flexibility to the Edge The E510A features dual 1 Gbps RPT ring interfaces, while the E520A features dual RPT ring interfaces operating at 1 Gbps or 2.5 Gbps. The high-capacity switching fabric and packet- processing engine of the E510A/E520A ensures optimum performance with mixed speed traffic loads. The E510A/E520A supports redundant, field-replaceable power supplies and fans for enhanced reliability. In order to have Stratum-level timing for synchronizing TDM circuits on the PacketWave E510A, there must be at least one PacketWave M-Series, C-Series or E520A in the RPT ring configuration. For E510A and E520A, the timing options listed in Table 1-1 are available.

Table 1-1. Physical Specifications

Platform Timing source

E510A Line timing

E520A External Internal Line timing

Note: The timing comes in from the ring via a BITS port. T1/E1 port 1 can be configured as a BITS port.

The platform features eight 10/100Base-T Ethernet fixed user interface ports, one high-speed expansion slot, and one low-speed expansion slot for support of optional expansion modules. The high-speed slot supports all expansion modules including a 24-port T1/21-port E1 module or a single port or dual port Gigabit Ethernet module. The low-speed expansion slot supports a 24-port T1/21-port E1 module or a lower density 8-port T1/E1 module. These modules allow carriers to customize the configuration of E510A/E520A platforms based on end customer requirements for maximum flexibility.

Complete System Management PacketWave incorporates all the Fault, Configuration, Accounting, Performance, and Security (FCAPS) management capabilities demanded by public carriers. ADTRAN LMS is a scalable software suite for managing multi-service PacketWave networks. It features an intuitive graphical user interface that facilitates administrative tasks in a simple and efficient manner. Integrated management functions include monitoring, event notification, service provisioning, and system configuration for all PacketWave products.

61440520E1-5B 1-3 PacketWave E510A/E520A Installation and Configuration Guide

ADTRAN LMS can scale to the following: • Maximum number of nodes: 500 • Maximum number of rings: 50 contiguous; no limit if the nodes are not connected • Maximum number of nodes per ring: 254 • Maximum number of E-Series nodes on one subtending ring: 254

Resilient Packet Ring Leadership ADTRAN is a leader in the RPR IEEE 802.17 standards development, based on the company’s advanced technology and field deployment experience. ADTRAN’s Resilient Package Transport (RPT) technology is enhanced beyond other RPR implementations by supporting Stratum timing distribution and traffic engineering. RPT efficiently utilizes the entire ring topology in both directions (unlike SONET/SDH, which allocates half of the ring bandwidth for protection channels). Using RPT, carriers can increase revenue by avoiding the physical transport bandwidth limitations of SONET/SDH.

1-4 61440520E1-5B Chapter 2 System Overview

INTRODUCTION The ADTRAN PacketWave E510A/E520A is a cost-effective compact solution for offering consolidated IP and TDM services over RPT rings. PacketWave E510A/E520A shelves can be deployed in a variety of network topologies, including ring and linear. This chapter introduces the PacketWave E510A/E520A. It provides information on the following topics: • “Introducing the PacketWave E510A/E520A” on page 2-2 • “PacketWave E510A/E520A Models” on page 2-4 • “Interoperability of T1/E1 Cards” on page 2-11 • “PacketWave Software Components” on page 2-11

61440520E1-5B 2-1 PacketWave E510A/E520A Installation and Configuration Guide

INTRODUCING THE PACKETWAVE E510A/E520A The following sections provide an overview of the architecture on the PacketWave E510A/ E520A.

Architecture Figure 2-1 illustrates a top-level view of the traffic network in a PacketWave E510A/E520A model.

Figure 2-1. Traffic Network Architecture of the PacketWave E510A/E520A

Features The PacketWave E510A/E520A is a high-speed Gigabit IP over fiber optical access switch that can be used in conjunction with other products from the ADTRAN PacketWave family. Table 2-1 provides a features list for the PacketWave E510A/E520A.

2-2 61440520E1-5B Chapter 2, System Overview - Introducing the PacketWave E510A/E520A

Table 2-1. PacketWave E510A/E520A Features

Feature Description

Optimized for IP and Ethernet data Supports a fixed interface of 10/100 and optional modules services of T1 or E1 and Gigabit Ethernet.

Supports toll-quality voice and circuit Supports T1 or E1. The E510A/E520A can be provided with services Stratum quality timing from the RPT ring.

Enables new, differentiated services Sophisticated scheduling support for service classes ranging from circuit-emulated service to best effort data.

Sophisticated traffic and bandwidth Rate limiting on 10/100 ports for dynamic bandwidth management management. Congestion control algorithms ensure fairness.

Resilient packet ring with full Statistically multiplexes all services over ring capacity. Uses bandwidth utilization all available fiber bandwidth in both ring directions. Supports linear and mesh topologies.

Scalability The ADTRAN LMS can support a maximum of 500 nodes and a maximum of 50 rings, with a maximum number of 254 nodes per ring.

Simple, powerful element Java-based ADTRAN LMS supports full FCAPS (Fault, management and service provisioning Configuration, Accounting, Provisioning, and Security). The Service Management Framework (SMF) part of ADTRAN LMS offers end-to-end service provisioning. ADTRAN LMS supports SNMPv2c. It provides automatic discovery of network topology and node configuration. The PacketWave also has Command Line Interface (CLI) management interfaces.

Full set of billing and SLA Collects statistics on a per-connection and per service-class management statistics basis. ADTRAN LMS can monitor SLAs and can aggregate these statistics on a network-wide basis for delivery to an upstream billing system or third-party SLA monitor.

61440520E1-5B 2-3 PacketWave E510A/E520A Installation and Configuration Guide

PACKETWAVE E510A/E520A MODELS The E510A/E520A models feature a variable configuration supporting both fixed and modular slot physical interfaces for the different types of services. The E510A and E520A are described in more detail in “PacketWave E510A/E520A Components” on page 2-4.

PacketWave E510A/E520A Components This section describes the components of the PacketWave E510A/E520A platforms. Infor- mation is included on the power, hardware, and cooling system. The front of the PacketWave E510A/E520A model is shown in Figure 2-2. It is 1.5 U high and supports both fixed and modular interfaces. The E510A contains 1 Gb/s RPT dual ring interfaces and eight 10/100Base-T ports in a fixed module. The E520A contains 1-2.5 Gb/s RPT dual ring interfaces and eight 10/100Base-T ports in a fixed module. A low-speed modular slot on either the E510A or the E520A supports either the 24-port T1/21-port E1 module or the 8-port T1/E1 module. A high-speed modular slot on the E510A/E520A supports either a single or dual port Gigabit Ethernet module or either of the T1/E1 modules. The RPT ring supports multiple interfaces, including 10 km (1310 nm) and 70 km (1550 nm). For more details on the ring interfaces, refer to “Appendix B, Physical Chassis Specifications”. Figure 2-2 shows an E510A with the 10/100 fixed module, the 24-port T1/21-port E1 module, and the single port Gigabit Ethernet module.

24-port T1/21-port E1 module

Single Port Gigabit Ethernet module 10/100 ports

Figure 2-2. PacketWave E510A Front View

Figure 2-3 shows an E520A with the 10/100 fixed module, the 8-port T1/E1 module, and the dual port Gigabit Ethernet module. Different modules are available as detailed.

2-4 61440520E1-5B Chapter 2, System Overview - PacketWave E510A/E520A Models

8-port T1/E1 module

Dual Port Gigabit Ethernet module 10/100 ports

Figure 2-3. PacketWave E520A Front View

Low-Speed Modules The following low-speed modules are available: • 24-port T1/21-port E1 •8-port T1/E1 The low-speed modular slot supports physical interfaces that run at an interface speed of less than or equal to 100 Mbps. For more information regarding the low-speed module, refer to “Appendix F, Module Specifications”. T1/E1 ports can be synchronized to a single Stratum clock; T1/E1 ports in asynchronous mode can be independently clocked.

High-Speed Module The following high-speed modules are available: • single port Gigabit Ethernet • dual port Gigabit Ethernet The high-speed modular slot supports physical interfaces that run at an interface speed of less than or equal to 1 Gbps. In addition, any low-speed module can use the high-speed slot. The two Gigabit Ethernet ports share 1 G of bandwidth. For more information regarding the high-speed module, refer to “Appendix F, Module Specifications”.

Fan Tray The back of the PacketWave E510A/E520A, as shown in Figure 2-4, contains fans that maintain the system’s operating temperature. Located in two power bays are either two AC or DC power trays (depending on your configuration) with built-in fans, or one power tray located in power bay A, and one fan tray located in power bay B.

61440520E1-5B 2-5 PacketWave E510A/E520A Installation and Configuration Guide

Power Bay A Power Bay B Grounding with built-in fan tray fan tray points

Figure 2-4. PacketWave E510A/E520A Back View, AC Power Shown

NOTE When using only one power tray to power the PacketWave E510A/ E520A, install the tray in power bay A.

CAUTION When a power tray fails, immediately replace the power tray with a replacement power tray or with a spare fan tray to ensure proper cooling and prevent damage to the PacketWave E510A/E520A. Spare AC power (P/N 1440530E1) or DC power (P/N 1440532E1) and fan trays (P/N 1440533E1) are available for purchase from ADTRAN Sales (refer to “Appendix G, Warranty”). For more information on replacing power and fan trays, refer to “Chapter 3, Routine Tasks” in the Maintenance & Troubleshooting Guide, P/N 61440101E1-44.

Power Distribution System The PacketWave E510A/E520A platform has one or two hot-swappable AC or DC power trays located on the back of the platform for standby power (referred to as the A and B power connections).

2-6 61440520E1-5B Chapter 2, System Overview - PacketWave E510A/E520A Models

AC Power Each 100–240 VAC power tray, as shown in the standby system in Figure 2-5 and in the non- standby system in Figure 2-6, has an IEC 320 inlet on the front face for AC input. The power supplies have built-in circuit protection and are auto-ranging. The IEC connection terminal has a locking mechanism (bail lock) to prevent accidental power cable disconnection. The power trays are hot pluggable. The PacketWave E510A/E520A will operate at 100–240 VAC, 50–60 Hz.

Power Bay A Power Bay B Grounding standby power tray points

Figure 2-5. AC Power Distribution System (Standby)

Power Bay A Power Bay B Grounding fan tray points

Figure 2-6. AC Power Distribution System (Non-standby)

For redundant power, each AC power supply must be plugged into a separate dedicated branch circuit. Only one AC power supply is required to support the PacketWave E510A/ E520A system; if redundant power is required, a second power supply can be used. In the event of a power failure, the second power supply feeds power to the PacketWave E510A/ E520A.

61440520E1-5B 2-7 PacketWave E510A/E520A Installation and Configuration Guide

The PacketWave E510A/E520A requires a connection to earth ground using the chassis ground point. If a power tray fails, before removing the power tray from the PacketWave E510A/E520A be sure to have a replacement power or fan tray ready to be installed immediately after removing the old power tray. If a spare power or fan tray is not available, do not remove the existing tray. For more information on removing and replacing the power tray in the PacketWave E510A/E520A, refer to the Maintenance & Troubleshooting Guide, P/N 61440101E1-44.

DC Power The non-standby DC power supply is shown in Figure 2-7, and the standby DC power supply is shown in Figure 2-8. The power trays are hot-pluggable. The PacketWave E510A/E520A operates at –48 VDC.

Terminal Block Power Bay A Power Bay B Grounding fan tray points

Figure 2-7. DC Power Distribution System (Non-standby)

Terminal Block Power Bay A Power Bay B Grounding standby power tray points Figure 2-8. DC Power Distribution System (Standby)

For redundant power, each DC power supply must be plugged into a separate dedicated branch circuit. Only one DC power supply is required to support the PacketWave E510A/ E520A system; if redundant power is required, a second power supply can be used that will share the load between the two, thereby lengthening their operating lives. In the event of a power failure, the second power supply feeds power to the PacketWave E510A/E520A.

2-8 61440520E1-5B Chapter 2, System Overview - PacketWave E510A/E520A Models

The PacketWave E510A/E520A requires a connection to earth ground using the chassis ground point. In addition, the DC power supplies can also be grounded by connecting a grounding cable to the terminal block. If a power tray fails, before removing the power tray from the PacketWave E510A/E520A be sure to have a replacement power or fan tray ready to be installed immediately after removing the old power tray. If a spare power or fan tray is not available, do not remove the existing tray. For more information on removing and replacing the power tray in the PacketWave E510A/E520A refer to “Chapter 4, PacketWave E510A/E520A Installation”.

Cooling Systems and Fan Tray There are four air intakes on the PacketWave E510A/E520A chassis. Green PWR A and PWR B LEDs on the front of the PacketWave E510A/E520A indicate that the power trays have power. A major alarm condition occurs if the exhaust air temperature exceeds the set threshold of 65°C. A major alarm condition occurs as a result of a failure of one fan. This causes the red MAJOR LED on the front of the chassis to illuminate, indicating that the fan tray needs to be replaced. If any fan in the PacketWave E510A/E520A fails, it must be replaced to properly cool the system.

NOTE The cooling system of the PacketWave E510A/E520A is designed to allow the platform to operate indefinitely at the maximum specified ambient operating temperature even with one failed fan tray.

A critical alarm condition occurs when two or more fans have failed. If a fan failure has occurred, the CRITICAL LED on the front of the chassis indicates that the appropriate fan tray must be replaced. Before removing the fan tray from the PacketWave E510A/E520A be sure to have a replacement fan tray ready to be installed immediately after removing the old fan tray. If a spare fan tray is not available, do not remove the existing tray. For more information on removing and replacing the fan tray in the PacketWave E510A/E520A refer to the Mainte- nance & Troubleshooting Guide, P/N 61440101E1-44.

RS-232 Port The RS-232 port is located on the front of the PacketWave E510A/E520A. This is a DB-9 connector to which a console or laptop can be connected for performing the initial setup. For DB-9 pinout details, see Figure D-1 on page D-2.

61440520E1-5B 2-9 PacketWave E510A/E520A Installation and Configuration Guide

Common Components The following sections detail the common components.

LEDs The power LEDs are continuously on indicating that the platform has power. There are also LEDs indicating the status of the E1 or T1, 10/100Base-T, Gigabit Ethernet, and Resilient Packet Ring (RPR) connections. The PacketWave E510A/E520A has the following LEDs: • two power monitoring LEDs: PWR A and PWR B • FAULT: SLOT 1, SLOT 2, and SLOT 3 LEDs • ALARM: CRITICAL, MAJOR, and MINOR LEDs • eight T1 or E1 FAULT and SYNC LEDs (located on the 8-port T1/E1 module) • Gigabit Ethernet TX-EN, LNK, and RX-SYNC (located on the high-speed module) • eight 10/100 ACT (activity) and 10/100 LNK (link) LEDs • EAST and WEST RX and TX LEDs The power LEDs on the front of the PacketWave E510A/E520A indicate whether the AC power sleds and onboard power converter are working properly. The ACT (Activity) LED on the 10/100 ports illuminates when there is Tx and/or Rx packet activity on the link, and it remains illuminated until there has been no packet activity for a minimum of 50 milliseconds. The LNK (Link) LED illuminates when the Ethernet port has successfully established a link to the other side of the Ethernet connection. For more information on LEDs and specific hardware components, refer to “Appendix B, Physical Chassis Specifications”.

NOTE If the FAULT LED remains on or periodically blinks, the PacketWave E510A/E520A has an internal hardware failure. Please contact TAC using the information provided in this guide.

MGMT Port The MGMT port is a 10/100Base-T Ethernet RJ-45 connection located on the front of the PacketWave E510A/E520A, and is used to execute network management system (NMS) functions.

2-10 61440520E1-5B Chapter 2, System Overview - Interoperability of T1/E1 Cards

INTEROPERABILITY OF T1/E1 CARDS T1/E1 cards are interoperable across the ADTRAN platforms: •M-Series •C-Series • E510A • E520A • ES520A. Table 2-2 provides a summary.

Table 2-2. T1/E1 Card Interoperability Summary

T1/E1 E510A, TDM-U TDM-U M-Series, T1/E1 E520A, M-Series, M-Series, M-Series, C-Series C-Series ES520A C-Series C-Series

Unmapped Mapped T1/E1 Mapped Channelized DS3 M13 T1/E1 (Equipped*) T1/E1 OC3/STM1

Unmapped Yes No No No No T1/E1

Mapped T1/E1 No Yes Yes Yes Yes (Equipped*)

* Signal label (V5 byte) provisioned on the mapped port.

PACKETWAVE SOFTWARE COMPONENTS The following sections describe the software used to configure and maintain the PacketWave E510A/E520A.

CLI The Command Line Interface (CLI) is used to configure the PacketWave platform, and port parameters. The PacketWave platform must be configured first before the ring can be configured and provisioned by the ADTRAN LMS. Field service engineers use the CLI to diagnose and debug platform problems as well as to configure the PacketWave chassis initially. There is password protection to control access to the CLI. For more information on CLI, refer to the Command Line Interface Reference Guide, P/N 61440101E1-35.

61440520E1-5B 2-11 PacketWave E510A/E520A Installation and Configuration Guide

ADTRAN LMS The ADTRAN LMS network management system is used to provision, manage and monitor a PacketWave operating on a ring. This is accomplished through a client-server architecture. The ADTRAN LMS server performs these functions: • Continuously collects the data from the network via the Simple Network Management Protocol (SNMP) • Stores data required for accounting, alarm and security information • Processes information for all the ADTRAN LMS applications • Manages access to shared resources in order to enable multiple simultaneous clients The ADTRAN LMS client is responsible for interacting with the user via a Graphical User Interface (GUI). The ADTRAN LMS software is written in Java, which is platform-independent. For more information on the ADTRAN LMS, refer to the ADTRAN LMS Network Management System Users Guide, P/N 61150LMSL10-31 and the Service Management Framework Users Guide, P/N 61150SMFL10-31.

2-12 61440520E1-5B Chapter 3 Site Installation Preparation

When preparing the site to install the PacketWave E510A/E520A, it is important to follow specific safety, lifting, and equipment guidelines. It is also important to gather all of the tools that are needed before beginning the installation process. At the end of this chapter, there is a worksheet for preparing the network. This chapter provides the steps that must be followed to prepare the site to install the PacketWave E510A/E520A. The following is a list of topics covered in this chapter: • “Safety and Equipment Guidelines” on page 3-2 • “Safety Considerations” on page 3-3 • “Materials, Tools and Equipment” on page 3-5 • “Site Requirements” on page 3-6

61440520E1-5B 3-1 PacketWave E510A/E520A Installation and Configuration Guide

SAFETY AND EQUIPMENT GUIDELINES There are certain safety and equipment guidelines that must be followed to avoid injury and to protect the safety of the equipment. • The PacketWave E510A/E520A should be located inside a locked room or network closet and should be accessible by trained personnel only. • The equipment should be installed by trained service personnel. • This unit is for installation only in restricted access locations (Dedicated equipment rooms, equipment closets, etc.) • Under any circumstances, never attempt to lift any object that might be too heavy for one person to lift. This could result in injury. • When working with the PacketWave E510A/E520A always disconnect the power source and unplug all of the power cables before working on the platform. • In the case of potentially hazardous conditions, if at all possible, do not work alone when installing or operating this equipment. • To prevent injury, keep all tools and platform components away from the walk areas. • It is important during and after installation to keep the work area clear and dust free. • When installing the PacketWave E510A/E520A do not wear any items that could get caught in the platform including loose clothing and jewelry (including rings and chains). Also make sure to fasten all garments (tie or scarf and sleeves) to guarantee that they do not get caught in the platform. • To make sure that the PacketWave E510A/E520A operates safely, when in use, operate it in accordance with its marked electrical ratings and product usage instructions. • The installation of the PacketWave E510A/E520A should be in compliance with the national and local electrical codes: in the United States, National Fire Protection Association (NFPA) 70, United States National Electrical Code; in Canada, Canadian Electrical Code, part I, CSA C22.1; in other countries, International Electrotechnical Commission (IEC) 364, part 1 through part 7. • The PacketWave E510A/E520A requires a permanent connection at the back earthing terminal when installed either in a rack or outside a rack enclosure. • Do an orderly shutdown of the PacketWave E510A/E520A before turning off the power. • Always wait 60 seconds after turning the PacketWave E510A/E520A power off to begin disconnecting the cables.

3-2 61440520E1-5B Chapter 3, Site Installation Preparation - Safety Considerations

SAFETY CONSIDERATIONS For safety purposes, before installing the PacketWave E510A/E520A, inspect the site to ensure that it is prepared for the installation to occur. Check all power sources and network connections. Once the PacketWave E510A/E520A is installed, it is not intended to be moved very often. The weight of the PacketWave E510A/E520A is 22 pounds. For proper installation of the PacketWave E510A/E520A there should be at least two people: One person should lift the PacketWave E510A/E520A into the rack while the other person attaches and secures the platform into the rack.

WARNING Use of controls or adjustments or performance of procedures other than those specified herein may result in hazardous radiation exposure.

Lifting The following precautions should be followed to prevent serious injury or damage to the PacketWave E510A/E520A: • Before lifting or moving the PacketWave E510A/E520A, disconnect all external cables. • Avoid lifting the PacketWave E510A/E520A alone. Have a second person there to help lift it. • When lifting, make sure to balance the weight of the PacketWave E510A/E520A with solid footing.

Electricity It is important to follow the listed guidelines to prevent an electrical hazard or cause damage to PacketWave E510A/E520A. • Connect the unit only to a properly rated supply circuit. • Reliable earthing (grounding) of rack-mounted equipment should be maintained. • A suitable disconnect device must be installed near the unit in accordance with the National Electrical Code so that it is accessible to the operator. • Before beginning installation, locate the emergency power-off switch in the room where the PacketWave E510A/E520A will be installed. • Examine the site area, for possible hazardous conditions, including power cables not being properly grounded, missing safety grounds and moist floors. • Do not execute any work that will cause the equipment to become unsafe or will create a safety hazard. • Always check to ensure that the power has been disconnected from all circuits before performing any operation. • If the equipment appears to be damaged, do not install it. Contact ADTRAN using the contact information provided in “Appendix G, Warranty”.

61440520E1-5B 3-3 PacketWave E510A/E520A Installation and Configuration Guide

• Before installing or removing a PacketWave E510A/E520A, disconnect all power and external cables. • The T1/E1 ports on the PacketWave are not to be connected to outside plant leads. The connections to these ports are intra-building and from a UL-listed Channel Service Unit.

WARNING If an electrical shock occurs, use caution and disconnect power to the PacketWave E510A/E520A. If it occurs to another employee, assess the condition, try to send another person to get medical aid, and then call for help.

WARNING Never install wiring during a lightening storm. Never install a jack in a wet location unless the jack is specifically designed for wet locations. Never touch uninsulated wires or terminals unless the line has been disconnected at the network interface.

3-4 61440520E1-5B Chapter 3, Site Installation Preparation - Materials, Tools and Equipment

MATERIALS, TOOLS AND EQUIPMENT It is recommended that the following materials and equipment be supplied to ensure proper installation and use of the PacketWave E510A/E520A.

Recommended Materials The following materials are recommended for the installation of the PacketWave E510A/ E520A: • 19-inch equipment rack • Power cord(s): use one or two AC power cords as appropriate for your configuration • For DC power, use two pairs of #14 AWG copper wire only

NOTE North American AC power cords are provided with the PacketWave E510A/E520A. If this is not the appropriate cord for your location, acquire the appropriate cord locally.

• One #4 AWG (6.6 mm) stranded ground cable • 2-hole ground lug Panduit for #4 AWG • One Ethernet cable for NMS (MGMT) port - 10/100Base-T: CAT 5, RJ-45 connector • Cables for RS-232 port: DB-9 pin connector/cable, null modem cable • CAT 5 with RJ-45 connectors for 10/100Base-T • CAT 5 cable with RJ-48C connectors for T1 ports • Labels to mark cables • Fiber optic cables with LC single-mode or multimode connectors for use with single port or dual port Gigabit Ethernet I/O modules • Single-mode only fiber cables with LC connectors for the RPR connection

Required Tools and Equipment The required tools that are needed to install the PacketWave E510A/E520A are as follows: • One Phillips screwdriver - #2 • One Phillips screwdriver - #1 • One pair of wire cutters • One pair of wire strippers • One crimping tool • Volt meter •Optical power meter • 7/16 nut driver or socket wrench

61440520E1-5B 3-5 PacketWave E510A/E520A Installation and Configuration Guide

SITE REQUIREMENTS To install the PacketWave E510A/E520A, it is important to consider the following site requirements in this section and the following sections. Please follow the listed guidelines to ensure proper installation. • Maximum operating ambient temperature of the PacketWave E510A/E520A is 40°C.

Equipment Dimensions and Site Layout for the PacketWave E510A/ E520A Please use the following listed guidelines to ensure proper installation: • When considering where the PacketWave E510A/E520A is going to be installed, it is important to establish where the network connections, grounding and AC or DC power sources will be located. • The datacom or Telco rack where the PacketWave E510A/E520A is installed should have at least 1.5 RU for installation and be compliant with the Electronics Industries Association (EIA) standard. • During installation, there must be adequate space to work around the rack. For installing, aligning or moving the platform, there must be 24 inches (61 cm) of space in front and behind the rack. • Once the platform is installed, to perform maintenance it is important to keep at least 24 inches (61 cm) of clearance in back of the platform. • Do not connect the cables in a manner that blocks movement in the front and back of the platform. • When mounting the PacketWave E510A/E520A into either the datacom or Telco rack, use all of the screws that have been provided to secure the platform to the rack posts. The minimum width between the rack mounting flanges required for the PacketWave E510A/ E520A is 17.5 inches (44.5 cm). • The PacketWave E510A/E520A requires a permanent connection at the back earthing terminal when installed either in a rack or outside a rack enclosure.

Proper Air Flow Cooling air for the PacketWave E510A/E520A enters at the back of the platform. The air is then pushed through the E510A/E520A and subsequently exhausted at the front of the platform. Never restrict the air flow through the devices, fans or vents.

NOTE It is important to keep the site as dust-free as possible. Blocking or restricting airflow at the intake may cause overheating of the Pack- etWave E510A/E520A. Do not block intake or exhaust area.

3-6 61440520E1-5B Chapter 3, Site Installation Preparation - Site Requirements

Power Connections The E510A/E520A uses either 100–240 VAC power supplies or –48 VDC power feeds; only one type of power is required to run the E510A/E520A. Power flows through two separate power trays on the back of the chassis. The power trays have a locking mechanism on the front panel of the module. If you are using AC power on the PacketWave E510A/E520A, refer to “100–240 VAC Supply” on page 3-7. If you are using DC power on the PacketWave E510A/E520A, refer to “–48 VDC Supply” on page 3-7.

100–240 VAC Supply Each 100–240 VAC power tray has an IEC 320 inlet on the front face for AC input. The power supplies have built-in circuit protection. The power supplies are auto-ranging between 100 VAC to 240 VAC for either 50 Hz or 60 Hz. The IEC connection terminal has a locking mechanism to prevent accidental power cable disconnection. Use ground studs on the PacketWave E510A/E520A chassis for earth ground connection.

NOTE For standby power, each AC power supply must be on separate dedicated branch circuit. Only one AC power supply is required to support the PacketWave E510A/E520A system. A second AC power supply would be a standby unit.

WARNING The attachment plug receptacles in the vicinity of the product or system must be of a grounding type, and the equipment grounding conductor serving these receptacles must be connected to the grounding points on the ADTRAN equipment.

–48 VDC Supply Each –48 VDC power tray has terminal blocks and circuit breakers with an internally-filtered power system. There also is mechanical protection for the terminal blocks and the power switches to prevent accidental contact. The DC power tray operates at –32 VDC to –72 VDC, 4 A @ –32 VDC. Output voltage is 3.3 VDC @ 23 A (max).

NOTE The maximum input noise peak to peak is –480 mV and wideband is –100 mVrms. The PacketWave E510A/E520A operates at –48 VDC ± 20%, up to 80 W. Input current is rated at 15 A DC and 7 A AC.

NOTE Each DC power supply must be on separate dedicated branch circuit for proper redundancy.

61440520E1-5B 3-7 PacketWave E510A/E520A Installation and Configuration Guide

NOTE If your power source is DC, only one DC power supply is required to support the PacketWave E510A/E520A system. A second DC power supply would be a redundant standby unit.

Site Wiring Proper site wiring is important for the proper operation of the PacketWave E510A/E520A. A suitable disconnect device must be installed near the unit in accordance with the National Electrical Code so that it is accessible to the operator. The DC sources used to supply power to this unit must comply with the requirements for SELV as specified in EN 60950 - 1 +A1 + A2 + A3 + A4. For more information, refer to “Site Requirements” on page 3-6.

Rack-mounting The PacketWave E510A/E520A can be mounted into a 19-inch two-post, or four-post compliant Electronics Industries Association (EIA) standard Telco-type (seismic) or datacom rack. The PacketWave E510A/E520A will operate in datacom racks that can either have fixed or open sides. The rack posts must have mounting flanges that are secured directly to the rack. There are several sets of mounting holes on the PacketWave E510A/E520A so that the mounting ears can be installed in either a flush-mounted, five-inches extended mount, or reverse flush-mounted position. The rack mounting ears come pre-installed on the PacketWave E510A/E520A in the flush-mount position. Depending upon your configuration, the mounting ears may need to be adjusted to one of the other mounting positions for better placement in the rack. When installing equipment into a rack, distribute the units evenly as hazardous conditions may be created by uneven weight distribution. Refer to “Adjusting Rack Mounting Ears” on page 4-4 for more information on installing or adjusting the mounting ears.

Preparing the Network Worksheet Before you begin installing the PacketWave E510A/E520A and any other required hardware or platforms, fill out the following worksheet to determine your initial network setup. A discovery node is a PacketWave device that has been configured for ADTRAN LMS access to that particular ring. The discovery node passes information both from ADTRAN LMS to all nodes on the ring, and from the nodes to ADTRAN LMS. For more information on configuring the discovery node, refer to “Chapter 5, System Startup and Configuration”. For multiple ring configurations, each ring should be on a separate subnet.

NOTE Do not use the subnet 192.168.1.x as this is already in use.

Review the areas in this worksheet, fill in each area, and then go to “Chapter 4, PacketWave E510A/E520A Installation”.

3-8 61440520E1-5B Chapter 3, Site Installation Preparation - Site Requirements

Network IP Addresses

Discovery Node Node name: ______IP address: _____._____._____._____ NMS (MGMT) port IP address: ____._____._____._____

Other Nodes NMS/MGMT port: _____._____._____._____ Ring card: _____._____._____._____ SRC: _____._____._____._____ SRC: _____._____._____._____

NMS/MGMT port: _____._____._____._____ Ring card: _____._____._____._____ SRC: _____._____._____._____ SRC: _____._____._____._____

61440520E1-5B 3-9 PacketWave E510A/E520A Installation and Configuration Guide

SSH If configuring SSH on the PacketWave E510A/E520A: Public keys FTP location: ______Telnet company policy: on / off SSH company policy: on / off

RADIUS If configuring RADIUS on the PacketWave E510A/E520A: RADIUS server IP address: _____._____._____._____ RADIUS secret: ______RADIUS port number: ______

Users User: ______Rights: ______User: ______Rights: ______User: ______Rights: ______User: ______Rights: ______

3-10 61440520E1-5B Chapter 4 PacketWave E510A/E520A Installation

The PacketWave E510A/E520A is 2.60 inches (6.60 cm) high (1.5 RU), 17.2 inches (43.68 cm) wide, 17.0 inches (43.18 cm) deep, and weighs 22 pounds (10 kg). The platform should be installed into a 19-inch equipment rack. The rack installation is achieved using movable mounting brackets that are located on each side of the platform. This chapter provides instructions to install the PacketWave E510A/E520A platform. In this chapter the following information is covered: • “Before Beginning Installation” on page 4-2 • “Installation” on page 4-4

61440520E1-5B 4-1 PacketWave E510A/E520A Installation and Configuration Guide

BEFORE BEGINNING INSTALLATION It is recommended that the following sections be followed to guarantee proper installation and use of the PacketWave E510A/E520A.

Verifying Rack Dimensions It is important to verify the rack dimensions to guarantee proper installation of the PacketWave E510A/E520A. The minimum Telco rack dimensions required for installation are as follows: • The PacketWave E510A/E520A can be installed in 19-inch racks. • A single platform may be installed in a small rack. The PacketWave E510A/E520A is 1.5 RU high; so as long as the rack can accommodate and allow for proper air space, the PacketWave E510A/E520A may be installed. • For a standard 7-foot, two-post, Telco rack that is 44 RU high, 22 PacketWave E510A/ E520A shelves may be installed. • For a seismic 7-foot, two-post, Telco rack that is 43 RU high, 21 PacketWave E510A/E520A shelves may be installed.

Unpacking the PacketWave E510A/E520A The PacketWave E510A/E520A has been shipped in a specially-made shipping container and sits in two foam cushions on the bottom of the container. To remove the packaging, complete the following steps: 1. On the top of the container, slit open the box. 2. Lift up the PacketWave E510A/E520A from the box. 3. Remove the protective side cushions. 4. Remove the AC power cord(s) from the box. 5. Remove the plastic bag from the PacketWave E510A/E520A.

Verifying Package Contents • One plastic bag contains the following: – documentation CD –software CD – software licensing agreement –warranty card • One PacketWave E510A/E520A platform • AC power cord(s)

4-2 61440520E1-5B Chapter 4, PacketWave E510A/E520A Installation - Before Beginning Installation

NOTE If any of these items are missing, please contact ADTRAN using the information provided in “Appendix G, Warranty”.

Before installing the PacketWave E510A/E520A into a rack, refer to “Inspecting the E510A/ E520A Platform Before Installation” on page 4-3, to verify no damage to the system has occurred during shipment.

Inspecting the E510A/E520A Platform Before Installation Once the PacketWave E510A/E520A has been removed from its packaging, it is important to inspect the front and back of the platform. To verify there is no damage to the system: 1. Check to see if there is any physical damage to the PacketWave E510A/E520A that may have occurred during shipment. 2. If any damage is found on the system, contact “ADTRAN Technical Support” using the contact information provided in “Appendix G, Warranty”. 3. If no damage is found on the system, proceed to “Installation” on page 4-4.

61440520E1-5B 4-3 PacketWave E510A/E520A Installation and Configuration Guide

INSTALLATION The PacketWave E510A/E520A can be mounted into a standard Electrical Input/Output (I/O) Assembly (EIA RS-310) Datacom rack or a Telco-style standard rack. There can be up to 22 PacketWave E510A/E520A shelves installed into a single 7-foot (44 RU) rack. The T1/E1 ports on the PacketWave E510A/E520A are not to be connected to outside plant leads. The connections to these ports are intra-building and from a UL Listed Channel Service Unit (CSU).

WARNING It is recommended that three people install the PacketWave E510A/E520A platform. Fully loaded, the platform weighs approxi- mately 22 pounds. Use proper lifting precautions when installing the PacketWave E510A/E520A platform.

Adjusting Rack Mounting Ears There are three different positions that the screw mounts located on each side of the PacketWave E510A/E520A platform can be used for mounting the mounting brackets, as shown in Figure 4-1. This allows the PacketWave E510A/E520A to be installed into the rack either flush mounted, 5 inches extended to the front, or reverse flush-mounted.

Figure 4-1. Positions for the Rack Mounting Ears

4-4 61440520E1-5B Chapter 4, PacketWave E510A/E520A Installation - Installation

The rack mounting ears on the PacketWave E510A/E520A come pre-installed in the flush mounted position. If you want to install the PacketWave E510A/E520A in any other position, follow the instructions given below. To adjust the rack mounting ears: 1. Unscrew the 10-32UNF flat-head screws holding the mounting ears on the chassis. 2. Position the mounting ears at the desired location according to Figure 4-1: flush- mounted, 5 inches extended to the front, or reverse mounted. 3. Install the mounting ears using the 10-32UNF flat-head screws provided with the chassis. 4. Proceed to “Lifting the PacketWave E510A/E520A into the Rack” on page 4-5.

Lifting the PacketWave E510A/E520A into the Rack There are proper methods for lifting the PacketWave E510A/E520A into the rack. For proper lifting ADTRAN recommends at least two people to lift the platform into the rack. One person should be on one side of the platform and another person should be on the other side of the platform to lift it from underneath and out of the container.

Installing the PacketWave E510A/E520A into Rack For proper lifting of the PacketWave E510A/E520A there should be at least two people: One person should lift the PacketWave E510A/E520A into the rack while the other person attaches and secures the platform into the rack. The PacketWave E510A/E520A has the ability to be mounted in the rack with either the front or back facing in the front of the rack. For the PacketWave E510A/E520A to be flush in a datacom rack or when using a Telco rack with only one set of posts, make sure to screw the rack mounting brackets in the first and second set of holes on the side and closest to the front or back of the platform.

CAUTION The PacketWave E510A/E520A must be grounded even if it is not installed in a rack. Packet loss may occur if the PacketWave E510A/E520A is not properly earth grounded.

The following steps describe how to mount the PacketWave E510A/E520A into the rack with two people. (Example is for front of platform in front of the rack. Same is true for back facing in the front of the rack.) 1. Verify that the rack assembly is set up to have the PacketWave E510A/E520A installed. 2. Verify that the mounting ears have been installed according to your configuration as detailed in “Adjusting Rack Mounting Ears” on page 4-4. 3. Install a temporary pair of screws on the rack just beneath the lower edge of the space that will be occupied by the PacketWave E510A/E520A. These screws can be used to rest the front of the PacketWave E510A/E520A during installation.

61440520E1-5B 4-5 PacketWave E510A/E520A Installation and Configuration Guide

4. If there are two people installing the PacketWave E510A/E520A lift the PacketWave E510A/E520A to the desired rack space. 5. Place the front of the PacketWave E510A/E520A on the screws by resting the bottom edge of the rack mounting brackets on top of the screws. 6. While one person holds the platform (from underneath) in place, the other person can install the mounting screws on each side of the rack using two mounting holes in the rack mounting brackets. 7. Secure the PacketWave E510A/E520A to the rack with the bottom screws first using the 10-32UNF or 12-24UNC screws provided with the chassis. Screw in the remainder of the screws. It is important that you use all of the screws provided. Two sizes of screws are provided depending on the type of rack used. 8. If installing more PacketWave E510A/E520A platforms, proceed to “Installing Multiple PacketWave E510A/E520A Platforms into Rack” on page 4-6; otherwise, proceed to “Connecting Grounding” on page 4-6.

Installing Multiple PacketWave E510A/E520A Platforms into Rack A PacketWave E510A/E520A needs only 1.5 RU of contiguous space for installation. Multiple PacketWave E510A/E520A platforms can be installed in one rack as long as the rack can accommodate the platform and allow for proper air space as described in “Site Require- ments” on page 3-6. Up to 22 PacketWave E510A/E520A platforms can be installed in one standard 7-foot, two-post, Telco rack that is 44 RU high or up to 21 PacketWave E510A/ E520A platforms can be installed in a seismic 7-foot, two-post, Telco rack that is 43 RU high. To install multiple PacketWave E510A/E520A platforms in a rack, repeat the procedure in “Installing the PacketWave E510A/E520A into Rack” on page 4-5.

Connecting Grounding For safety purposes, the PacketWave E510A/E520A requires an earth grounding terminal connection. This connection consists of two studs that protrude out of the platform and allows the equipment to be grounded.

CAUTION The PacketWave E510A/E520A must be grounded even if it is not installed in a rack. Packet loss may occur if the PacketWave E510A/E520A is not properly earth grounded, even when powered by AC power supplies.

The two-stud configuration allows the user to attach the ground cable vertically. Two 1/4-20 UNC KEP nuts are used to attach the studs. 4-AWG cabling is attached to the studs via a two- hole Long Barrel terminal grounding lug. Always connect the equipment to reliable earth ground from the chassis ground points as shown in Figure 4-2.

4-6 61440520E1-5B Chapter 4, PacketWave E510A/E520A Installation - Installation

CAUTION The attachment plug receptacles in the vicinity of the product or system must be of a grounding type, and the equipment grounding conductor serving these receptacles must be connected to the grounding points on the ADTRAN equipment.

Locking Locking Power Bay A screw Power Bay B screw Grounding standby power tray points

Figure 4-2. Grounding Points (AC Power Shown)

NOTE The lug is not supplied by ADTRAN. This lug is available from commercial hardware vendors. The PacketWave E510A/E520A requires a permanent connection at the back earthing terminal when installed either in a rack or outside a rack enclosure.

To connect the grounding lug to the earth ground: 1. Remove the two 1/4-20 UNC KEP nuts from the chassis ground points, as shown in Figure 4-2, on the back of the PacketWave E510A/E520A. 2. Connect the grounding cable to the two studs. 3. Attach the grounding cable to the chassis ground points using the 1/4-20 UNC KEP nuts.

61440520E1-5B 4-7 PacketWave E510A/E520A Installation and Configuration Guide

Making Power Connections

CAUTION Before attaching the AC or DC power lines, make sure the power switch or switches are in the OFF (O) position. If the power switch or switches are in the ON (I) position, it could cause the platform to become non-operational.

The PacketWave E510A/E520A uses AC-input power that is rated at 240 VAC maximum or DC-input power rated at –48 VDC maximum. There are independent A and B power supplies that allow standby power.

NOTE When using only one power tray to power the PacketWave E510A/ E520A install the tray in the Power bay A location.

Terminal Block Locking Terminal Block Locking Grounding screw screw points Power Bay A Power Bay B standby power tray Figure 4-3. Grounding Points and DC Power Connections

To connect to AC power, complete the following steps: 1. Connect the AC power cable, as shown in Figure 4-2, to an AC outlet. 2. Move the bail lock and attach the power cord to the power tray. 3. Secure the bail lock. 4. Turn the power tray switch ON.

NOTE For redundant power, each power cable must be plugged into a separate branch circuit.

4-8 61440520E1-5B Chapter 4, PacketWave E510A/E520A Installation - Installation

To connect to DC power, complete the following steps: 1. Connect the three #14 AWG power cables to the terminal block as shown in Figure 4-3. (Since the chassis is already connected to the grounding points, it is not required to connect a grounding cable to the terminal block.) 2. Enable power to the tray at the appropriate location. 3. Turn the power tray switch ON.

NOTE For redundant power, each power cable must be plugged into a separate branch circuit.

Replacing the PacketWave E510A/E520A Power Module The PacketWave E510A/E520A enclosure is designed to run using a single AC or DC sled- style power tray. The chassis has two power bays, one for main power source and the other for an optional redundant power source. When using only one power source, a fan tray is required, for cooling purposes, and must occupy the spare power slot (power bay B). For safety, the PacketWave E510A/E520Ahas grounding points located on the back of the chassis.

WARNING The attachment plug receptacles in the vicinity of the product or system must be of a grounding type and the equipment grounding conductor serving these receptacles must be connected to the grounding terminals on the ADTRAN equipment.

To check a PacketWave E510A/E520A power module, complete these steps: 1. Confirm the unit is connected to a properly rated supply circuit. 2. Confirm the rack-mounted equipment is reliably grounded. 3. Examine the site area for possible hazardous conditions, including: – Power cables not being properly grounded – Missing safety grounds – Moist floors

61440520E1-5B 4-9 PacketWave E510A/E520A Installation and Configuration Guide

Spare AC power or DC power and fan trays are available for purchase through ADTRAN. In the event that a redundant power tray no longer operates, you can replace it with another power or fan tray. To replace a power tray, complete these steps:

Removing AC Power Tray 1. Turn OFF the defective tray’s power switch. 2. Move the bail lock and remove the power cord. 3. Using a screwdriver, turn the locking screw 90 degrees. 4. Remove the defective power tray.

Installing AC Power Tray 1. Verify the power switch on the replacement power supply is turned OFF. 2. Insert the replacement power tray. 3. Secure the power tray by turning the locking screw 90 degrees. 4. Move the bail lock and attach the power cord. 5. Secure the bail lock. 6. Turn the power tray switch ON.

NOTE For redundancy, each power supply must be on separate dedicated branch circuit.

Removing DC Power Tray 1. Turn OFF the defective tray’s power switch.

CAUTION Even though power is turned off at the power tray, the cables connected to the terminal block still contain live current. In order to prevent sparking or a potential fire, be sure to disable power to the tray at the appropriate location (rack circuit breaker, for example) before removing the cables.

NOTE Turning off rack power may power off all devices in the rack.

2. Disconnect the cables from the terminal block. 3. Using a screwdriver, turn the locking screw 90 degrees. 4. Remove the defective power tray.

4-10 61440520E1-5B Chapter 4, PacketWave E510A/E520A Installation - Installation

Installing DC Power Tray 1. Verify the power switch on the replacement power supply is turned OFF. 2. Insert the replacement power tray. 3. Secure the power tray by turning the locking screw 90 degrees. 4. Reconnect the cables to the terminal block. 5. Enable power to the tray at the appropriate location. 6. Turn the power tray switch ON.

NOTE For redundancy, each power supply must be on separate dedicated branch circuit.

Connecting to T1/E1, Ethernet, and RPR The T1/E1, 10/100, Gigabit Ethernet, and RPR connections in the PacketWave E510A/E520A have different types of connections, as shown in Figure 4-4.

RS-232 T1/E1 Connections MGMT Port RPR Connections Gigabit Ethernet Connections 10/100 Connections

Figure 4-4. E520A Front Panel Connections

The 24-port T1/21-port E1 module has a high density 50-pin front panel connector. There is one connector for 12 ports. The cable requires a patch panel. The 10/100Base-T connection has RJ-45 connectors. The RPR connection is an SFP. The cable is an LC duplex connector. The Gigabit Ethernet connection is also an SFP. Its cable is also an LC duplex connector. For details on connectors and cabling, refer to “Appendix D, Connectors and Cabling”. Observe the following caution when installing to avoid injuring yourself or damaging the equipment.

61440520E1-5B 4-11 PacketWave E510A/E520A Installation and Configuration Guide

CAUTION If not in use, always put protective covers on the optical connectors on the modules. Damage of the optical connectors may occur from dirt and dust.

WARNING When cabling a module with fiber-optic cable, be aware that laser radiation is present when the system is on and the fiber-optic cable is disconnected. Do not stare into the laser beam.

4-12 61440520E1-5B Chapter 5 System Startup and Configuration

Proper system startup and configuration for the PacketWave E510A/E520A is important in the overall long-term operation of the platform. It is important to ensure that all initial hardware connections have been properly made before beginning to use the Command Line Interface (CLI) or the ADTRAN LMS software. This chapter describes how to bootup and configure the PacketWave E510A/E520A. It provides information on configuring the PacketWave E510A/E520A and using the CLI, including the following: • “Network Overview” on page 5-2 • “Configuring the PacketWave E510A/E520A” on page 5-6

61440520E1-5B 5-1 PacketWave E510A/E520A Installation and Configuration Guide

NETWORK OVERVIEW Figure 5-1 illustrates a generic three-node configuration. This configuration consists of three different PacketWave nodes connected in a ring by bi-directional single-mode fiber connections.

All nodes in a single ring must be in the same subnet. Each ring must be on a separate subnet. Router

Layer 2/3 (RIPv2) NMS Gateway: Requires NMS (MGMT) port IP Address

A B A B

10 /100X8 10 /100X8 10/100X 8 10 /100X8 10/100X8 10 SW /100X8 ITCH 20G2 SWITCH 20G2 SYSCON E 2 SYSCON E 2 T1/E1X8 T1/E1X8 T1/E1X8 A B T1/E1X8 A B T1/E1X8 T1/E1X8 1 0/100X8 UTILI 1 0/100X8 10/100X 8 1 0/100X8 10 /100X8 1 SW 0/100X8 ITCH 20G2 SWITCH 20G2 SYSCON E 2 SYSCON E 2 T1/E1X8 T1/E1X8 T1/E1X8 T1/E1X8 T1/E1X8 T1/E1X8 UTILI

Node A Node G 10.1.16.25 10.1.25.42

1 V

- 2

I E

b C

P L S

I Y

I E 2 D N 00

A E T

10 C

Y t

3 V

3 o

I E A D

D C

R 12

P D S A B A

8 Y B

4 V

1X I E D 10/ T 100 U FAN X N POWER 8

A 10 A /100X O 8 F

A T 1

T1 P 0/1 S 00X 8 1 0/100X8 10/100X Node F 8 S Node B 1 W 0/100X8 ITCH 20G2 S 5 FAN FAULT SWITCH W 20G2 SYSCON H E 2 SYSCON C E I 2 T1/ IT E1X8 T1/E T W 1X8 S T1/E1X Y 8

E T

B T1 R

T /E S

S S 1X S

V 8

C L

I E 6 D E

A T A 1/E1X T 8 U

C T 1 A /E H A 1X8

X O

T X X RING 1 UTILI

T P

R F POWER A RING 2 A 7

B H

C Node D

R IT POWER B

I Y

E T

IV E

E 8 E

A C A

E 10.0.25.41 W 10.1.16.26

O X

T X

T P Node D R

T S R Y B

N B

R M T

S 2 R

R O

O O

O M

E - 3

9 U

N A

PW N G T

I C A I L A

-2 W

A S

M R T S

M O M

R O C

SY P N A 2 10.0.25.43 10.1.16.28

R 1 T

E - 2

TIV

b C

P L S

I Y

E N 2 D

T E 0/100X

1 C

Y t

3 o

I E A D

D C

R 12

P D S

4 V

1X E

U FAN N POWER

T P

S 5 FAN FAULT W

I C

T W

E T

C L

E 6 D E

E W

A H A O X

T X

T P

R F POWER A A 7

B H

R ITC POWER B

I Y

E T

IV E

E 8 E

A C A

W E

O X

T X

T P

T S R Y B

N B

R M T

S 2 R

R O

O M

E - 3

9 U

N A

PW G T 2 T

IN C A I L A

- W

M R T S

YSCO

M O M

R O C

S P N A 2 Node E Node C 10.0.25.40 10.1.16.27

Figure 5-1. Two-Ring Configuration

A discovery node is used as a seed (starting point) for the automatic discovery of all nodes on multiple, interconnected rings. When you provide a single IP address (for any PacketWave node in the network), ADTRAN LMS will automatically discover all the interconnected nodes and rings. Each node is capable of independently exchanging information with the ADTRAN LMS server: once NMS routing is enabled on the nodes interfacing with the client or server, any node can connect to the ADTRAN LMS server.

NOTE When NMS routing is set to “ON,” the RIPV2 protocol is activated. If one does not want to see PIpV2 messages on the customer network, one should set the NMS routing to “OFF” and add an appropriate static IP on the NMS server.

5-2 61440520E1-5B Chapter 5, System Startup and Configuration - Network Overview

Access is accomplished by assigning an IP address to the NMS (MGMT) port. The discovery node passes information both from ADTRAN LMS to all nodes on the ring, and from the nodes to ADTRAN LMS. A discovery node is configured with the NMS port IP address during initial setup using the RS-232 and MGMT ports. For more information on configuring the discovery node, refer to “Configuring the NMS (MGMT Port) IP Address” on page 5-9 and “Configuring the Node IP Address” on page 5-9. In order to have a timing source for the PacketWave E510A T1/E1 ports, there must be at least one PacketWave M-Series, C-Series, or E520A in the RPT ring configuration. For E510A and E520A, the following timing options are available:

Table 5-1. E510A/E520A Timing Options

Platform Timing source

E510A Line timing

E520A External Internal Line timing

Note: The timing comes in from the ring via a BITS port. T1/E1 port 1 can be configured as a BITS port.

For more information on specific network and ADTRAN LMS configurations, see “Appendix A, ADTRAN LMS Configurations” in the ADTRAN LMS Network Management System Users Guide, P/N 61150LMSL10-31. Figure 5-2 illustrates connectivity in a three-node ring using PacketWave nodes. Note that the East side Tx connects into the West side Rx of the corresponding neighbor and that the West side Tx connects into the East side Rx of the corresponding neighbor.

61440520E1-5B 5-3 PacketWave E510A/E520A Installation and Configuration Guide

Node A (PacketWave M-Series) RPT I/O

RX RX

TX TX

10 9 8 7 Transmit (Tx) of an The west side East West RPT I/O Card or of a node RPR connection connects directly connects to Receive (Rx) to the east side or its neighbor node. of its neighbor node.

RPT I/O RPR Connections 5 TX RX West 6 Node C TX RX (PacketWave Exxx) Node B TX RX 7 (PacketWave C-Series) East West East 8 TX RX

Figure 5-2. Three-Ring Node Fiber Connections

When performing the startup sequence or basic configuration of the PacketWave E510A/ E520A it’s important to follow the instructions using the sequence in which they’re presented in this chapter.

Powering up the PacketWave E510A/E520A Once all of the proper connections have been made as detailed in “Making Power Connections” on page 4-8, turn on the power and test the installation: 1. Turn on the power switch(es) located on the back of the platform, as shown in Figure 5-3 and Figure 5-4, by switching the power switch(es) to the ON position. If you’re using two AC or DC outlets, turn on power bay A first followed by power bay B.

5-4 61440520E1-5B Chapter 5, System Startup and Configuration - Network Overview

Power Power Power Bay B switch Power Bay A switch standby power tray Figure 5-3. AC Power Switches

Power Power Power Bay B switch Power Bay A switch standby power tray

Figure 5-4. DC Power Switches

2. Verify that the following LED sequence occurs on the PacketWave E510A/E520A: •The FAULT LEDs remain illuminated on initial power up. All other LEDs except PWR A and PWR B illuminate as part of the power-on self test (post). •The PWR A and PWR B LEDs illuminate (green) to indicate the voltage output of the power bay is operational. • After initialization, the active LEDs on all Ethernet connections illuminate and are ready to handle traffic. If an Ethernet link connection fails, the LNK LED will not be illuminate. • If there is a system level fault, which may include an Ethernet port failure not related to the link, the FAULT LED will come on. • The active RPR connection illuminates the TX and RX LEDs when it starts transmitting and receiving. 3. If the POWER LED lights, the system has been correctly installed and is powered on. If the LED fails to go on and remains off, contact an ADTRAN “Warranty and Customer Service” representative to report the faulty equipment and obtain further instructions.

61440520E1-5B 5-5 PacketWave E510A/E520A Installation and Configuration Guide

CONFIGURING THE PACKETWAVE E510A/E520A The PacketWave E510A/E520A comes set to default values for the system commands in the CLI. To configure the system level commands in the CLI, refer to the Command Line Interface Reference Guide, P/N 61440101E1-35.

Connecting to the Resilient Packet Ring There is a duplex LC connector port located on each of the RPR connections on the front of the PacketWave E510A/E520A. This is where the fiber is connected to the platform from the network. See to Figure 5-5. To make the proper RPR connections, use the following instructions. Use the concepts in Figure 5-2 as a guide for configuring your network.

NOTE It’s important to connect the transmit and receive ports on the RPR connections to the correct fibers.

1. Connect the fibers on the RPR connections from the West Tx (transmit) of Node A to the East Rx (receive) of Node B. 2. Connect the West Rx fibers of Node A to the East Tx fibers of Node B. 3. Connect the West Tx fibers of Node B to the East Rx fibers of Node C. 4. Connect the West Rx fibers of Node B to the East Tx fibers of Node C. 5. Connect the West Tx fibers of Node C to the East Rx fibers of Node A. 6. Connect the West Rx fibers of Node C to the East Tx fibers of Node A.

Duplex LC Connector Ports for RPR Connection

Figure 5-5. RPR Connections on E510A/E520A

5-6 61440520E1-5B Chapter 5, System Startup and Configuration - Configuring the PacketWave E510A/E520A

Cabling the Module Ports to the Network This section provides instructions for connecting the network to the PacketWave E510A/ E520A using fiber-optic cable.

Cabling Considerations When making a connection, remember the following: • Read the ADTRAN documentation for information on choosing the appropriate fiber-optic cable types and lengths. Refer to “Fiber-Optic Cables” on page D-7 for more information on fiber-optic cable types and lengths. • Avoid stretching or bending fiber-optic cable excessively. • Avoid trip hazards by routing the fiber-optic cable away from the aisles and other areas where people walk. If such routes cannot be avoided, use covers or similar material to secure and protect the fiber-optic cable. • Ensure fiber-optic cables connected to the module are supported so that the fiber-optic cable connectors are not excessively strained. • Observe all cautionary notes when cabling a module with fiber-optic cable.

CAUTION Laser radiation is present when the system is on and the fiber-optic cable is disconnected. Do not stare into the laser beam.

Fiber-Optic Interface Cables Use a single-mode optical fiber interface cable to connect to the RPR of the PacketWave E510A/E520A to a network or to connect two PacketWave E510A/E520A units back-to-back. Refer to “Fiber-Optic Cables” on page D-7 to determine the correct interface cable type. To connect the cables, perform the following steps: 1. Using the cabling chart provided by the network administrator as a guide, connect either two simplex fiber cables or one duplex fiber cable between the RPR of PacketWave E510A/ E520A and your network. 2. Label each end of the cable so it’s easy to find the device if you have to troubleshoot a network problem. Suggested information for this label includes: • Unique cable identification number • IP address of the connected device • System “name” of connected device

61440520E1-5B 5-7 PacketWave E510A/E520A Installation and Configuration Guide

Laser Safety Information This section contains important information about working safely with optical equipment. The RPR connections are Class I lasers. Refer to “Appendix C, Optical Power Budget” for more information.

CAUTION Invisible laser radiation may be emitted from the RPR ports when no fiber cable is connected. Avoid exposure and do not stare into open apertures or cover them when no cable is connected.

CAUTION Un-terminated optical receptacles may emit laser radiation. Do not view with optical instruments.

Connecting the PacketWave E510A/E520A to a Terminal Server or Serial RS-232 Port An external RS-232 port (DB-9 connector) located on the front of the PacketWave E510A/ E520A (as shown in Figure 5-6) is used to connect to the PacketWave E510A/E520A to a terminal server or serial RS-232 port. This external port is used to perform service and initial startup procedures.

RS-232 Port Figure 5-6. RS-232 Port on PacketWave E510A/E520A

Configuring the Node The following sections detail configuration procedures for the nodes on the network.

Initial Login When your system is first set up, you must login as userid apollo. You will be prompted to enter an initial password, which will become your permanent password for apollo. Enter a password of your choice to start the initial login. After entering the password, the CLI prompt appears.

5-8 61440520E1-5B Chapter 5, System Startup and Configuration - Configuring the PacketWave E510A/E520A

Refer to “PacketWave Configuration Procedures” on page 6-7 for more information. For more information on the CLI, refer to the Command Line Interface Reference Guide, P/N 61440101E1-35.

NOTE The PacketWave E510A/E520A has the alarms enabled by default.

Configuring the NMS (MGMT Port) IP Address The following procedure sets the IP address for the MGMT port located on the front of the PacketWave E510A/E520A. The procedure describes using a HyperTerminal session, but other types of communication may be used, such as a VT100 terminal with the following settings: • baud rate: 9600 •data bits: 8 •parity: none • stop bits: 1 • flow control: none 1. Connect a DB-9 null modem cable between the RS-232 port on the front of the Packet- Wave E510A/E520A and the communications serial port on a computer or laptop. 2. Initiate a HyperTerminal session or other type of communication from the computer or laptop with the port settings as described above. 3. Set the MGT IP address by executing the set port ip add command from the CLI. set port ip add set port ip add mgt-1/1 193.168.55.1 255.255.255.240 MGT Port set successfully to 193.168.55.1 <255.255.255.240> 4. Verify the changes by executing the show routes command from the CLI. show routes

ROUTE NET TABLE destination/mask gateway flags Refcnt Use Slot Port ------10.0.0.0/8 10.0.25.62 UC 0 0 ring - 193.168.55.0/24 193.168.55.1 UC 0 0 nms ------ROUTE HOST TABLE destination/mask gateway flags Refcnt Use Slot Port ------127.0.0.1/32 127.0.0.1 UH 1 0 loopback ------

Configuring the Node IP Address Setting the IP address is optional. A default node IP (or shelf IP) address is assigned and will be used if the platform IP address is not set.

61440520E1-5B 5-9 PacketWave E510A/E520A Installation and Configuration Guide

NOTE IP Addresses are not restricted to RFC 1918. Any address space can be configured.

NOTE This step must be performed on every node on the ring, ensuring that each node has a unique subnet address.

1. To set the node IP address, enter the set shelf ip command: set shelf ip-address (Reboots shelf after execution!) set shelf ip 10.0.25.62 255.255.255.0 2. Confirm that the IP address assignment does not conflict with other pre-existing IP assignments. 3. At this time, the PacketWave E510A/E520A will require rebooting. To confirm reboot, enter Yes.

Configuring Security After the platform is rebooted, you can log back in as apollo. For information on configuring security and users, refer to “Chapter 6, Configuring Security”.

Configuring Control Plane (CP) Routes If you do not want to use dynamic routes, use the following procedure. 1. From the CLI, add the following route, where: • IP address is the address of the computer where the ADTRAN LMS server is running. • gateway is the IP address of the discovery node. set shelf cp-route add set shelf cp-route add 172.16.200.100 255.255.255.255 10.0.25.72 CP Route set successfully show routes

5-10 61440520E1-5B Chapter 5, System Startup and Configuration - Configuring the PacketWave E510A/E520A

Configuring the Discovery Node On the PacketWave that will serve as the discovery node, NMS must be enabled. • Establish routing on the NMS port using the set shelf routing command: set shelf routing set shelf routing nms on

Configuring the ADTRAN LMS The ADTRAN network management system is called the ADTRAN LMS. Installation and configuration of the ADTRAN LMS is discussed in greater detail in the following sections and in the ADTRAN LMS Network Management System Users Guide, P/N 61150LMSL10-31. For more information on specific network configurations, refer to “Appendix A, ADTRAN LMS Configurations,” in the ADTRAN LMS Network Management System Users Guide, P/N 61150LMSL10-31.

NOTE IP Addresses are not restricted to RFC 1918. Any address space can be configured.

NOTE The ADTRAN LMS is a two-tier architecture, also known as client/ server architecture. You can have only one server and one client on a given machine. A single server can have multiple clients so long as the clients are on different machines.

If you are configuring the ADTRAN LMS on a Windows 2000 or NT machine, refer to “Windows 2000/NT/XP Procedure” on page 5-11; if you are configuring the ADTRAN LMS on a Solaris 7 machine, refer to “Solaris Procedure” on page 5-12. More detailed information on installing the ADTRAN LMS on either a NT or Solaris client can be found in “Chapter 2, Installation,” in the ADTRAN LMS Network Management System Users Guide, P/N 61150LMSL10-31.

Windows 2000/NT/XP Procedure The following procedure is for Windows 2000, WinNT, or XP and for nodes: 1. Add static routes on the computer and nodes. 2. On the computer, add the following route at the DOS prompt using the syntax shown below where the gateway is the IP address of the NMS port: route add mask route add -p 10.0.0.0 mask 255.0.0.0 3. Verify the route has been added on the computer or laptop from the DOS prompt: C:\> route print

61440520E1-5B 5-11 PacketWave E510A/E520A Installation and Configuration Guide

4. Verify that you can Telnet to the ring address of other nodes from the computer or laptop and manage the platform using the CLI. Telnet can only be performed after the Control Plane (CP) routes are set successfully. 5. Verify connectivity between computer or laptop and the nodes by performing pings: C:\> ping 10.xx.xx.xx For example: C:\> ping 10.0.25.72 The routes should now be added successfully on the computer or laptop. The CP routes should be persistent in the database and configured back after rebooting the PacketWave E510A/E520A. The pings from the computer or laptop to the ring addresses should now be operating. You should be able to Telnet into the ring address and login as a CLI user. 6. Using the NT installation instructions provided in Chapter 2, “Installation,” in the ADTRAN LMS Network Management System Users Guide, P/N 61150LMSL10-31, install the ADTRAN LMS software on an ADTRAN LMS workstation running Windows NT 4.0 (English version) or Windows 2000 from the CD-ROM provided. 7. Launch ADTRAN LMS. To Launch ADTRAN LMS, start the ADTRAN LMS server by selecting the Start -> Programs -> Adtran LMS -> Adtran LMS Server. 8. Once the ADTRAN LMS server is running, start the ADTRAN LMS client application. The static routes have now been successfully added on the computer or laptop and nodes, ADTRAN LMS has launched successfully, and all other nodes on the ring should be operational.

Solaris Procedure The following procedure is for Solaris 7: 1. On the workstation in which the ADTRAN LMS server has been installed, obtain a prompt and enter: >route add host destination [gateway] For example, >route add 127.117.42.17 22.22.22.xx (where xx is the gateway) Route is a command used to manually manipulate the network routing tables that are normally maintained by the system routing daemon, by routed (1M), or through default routes and redirect messages from routers. The command syntax for route is as follows: route [ -fnvq ] command [ [ modifiers ] args ]

route [ -fnvq ] add | change | delete | get [host | net] destination [ gateway [ args ] ]

route [ -n ] monitor

route [ -n ] flush 2. Verify that the route has been added by entering at the prompt: >netstat -r

5-12 61440520E1-5B Chapter 5, System Startup and Configuration - Configuring the PacketWave E510A/E520A

Netstat displays the contents of network-related data structures in different formats depending upon the options selected. A screen similar to the one shown below will be displayed. netstat -r Routing Table: Destination Gateway Flags Ref Use Interface ------297.117.2.0 127.19.239.28 UG 0 0 22.22.22.0 127.19.2.253 UG 0 0 22.22.22.128 127.19.2.254 UG 0 0 297.117.42.0 127.19.239.26 UG 0 0 297.117.13.0 127.19.239.46 UG 0 0 297.117.4.0 127.19.239.39 UG 0 0 297.117.62.0 127.19.239.26 UG 0 0 127.19.0.0 smith U 3 3364 gel 127.19.0.0 jones_router UG 0 0 base-address.mcast.net smith U 3 0 gel default router UG 0 251 default firewall UG 0 243 localhost localhost UH 0 204 lo0 3. If you are running pre-5.0 release nodes or if you do not want to use dynamic routes, use the CLI to add the following route, where: • IP address is the address of the computer or laptop where the ADTRAN LMS server is running. • gateway is the in-band communication IP address of the CO node. set shelf cp-route add set shelf cp-route add 172.16.200.100 255.255.255.255 10.0.25.72 CP Route set successfully show routes

ROUTE NET TABLE destination/mask gateway flags Refcnt Use Slot Port ------10.0.0.0/8 10.0.25.62 UC 0 0 ring - 193.168.55.0/24 193.168.55.1 UC 0 0 nms ------

ROUTE HOST TABLE destination/mask gateway flags Refcnt Use Slot Port ------127.0.0.1/32 127.0.0.1 UH 1 0 loopback - *172.16.200.100/32 10.0.25.72 UGHM 0 0 ring ------* indicates control plane routes

4. Verify that you can Telnet to the ring address of other nodes from the computer or laptop and manage the platform using the CLI. Telnet can only be done after the CP routes are set successfully. 5. Verify connectivity between the computer or laptop and the nodes by performing pings: >ping 10.xx.xx.xx For example, C:\> ping 10.0.25.72

61440520E1-5B 5-13 PacketWave E510A/E520A Installation and Configuration Guide

The routes should now be added successfully on the computer or laptop. The CP routes should be added successfully. The CP routes should be persistent in the database and configured back after rebooting the PacketWave E510A/E520A. The pings from the computer or laptop to the ring addresses should now be operating. You should be able to Telnet into the ring address and login as a CLI user. 6. Using the Solaris 7 installation instructions provided in “Chapter 2, Installation,” in the ADTRAN LMS Network Management System Users Guide, P/N 61150LMSL10-31, install the ADTRAN LMS software on an ADTRAN LMS workstation running Solaris 7. 7. Right-click on the desktop. A menu is displayed. Select Windows -> Update Workspace Menu. 8. Right-click on the desktop again. From the Applications menu, select Adtran LMS -> Start_Server. The ADTRAN LMS Server splash screen is displayed. 9. Once the ADTRAN LMS server is running, start the ADTRAN LMS client application. The static routes are now successfully on the computer or laptop and nodes, ADTRAN LMS has launched successfully, and all other nodes on the ring should be operational.

Connecting Nodes to the Management Network (TCP/IP) The final configuration step is to connect to the network management service (MGMT) port on the front of the PacketWave E510A/E520A. This port, as shown in Figure 5-7, accepts an RJ-45 connector. The MGMT port provides an Ethernet connection from an external management network to the PacketWave shelves that are attached to that platform via RPR connections. The ADTRAN LMS communicates with the nodes in a PacketWave network through this connection.

MGMT port Figure 5-7. Management Port on E510A/E520A

Depending upon the configuration, the NMS (MGMT) port can be connected by using one of the following methods: • If connecting directly to a workstation, use a cross-over cable to connect one end of the cable to the NMS port and the other end of the cable to the workstation. • If connecting to a switch or a hub, use a straight-through cable to connect one end of the cable to the NMS port and the other end of the cable to the switch or hub. For more information on straight-through or cross-over cabling, refer to “Appendix D, Connectors and Cabling”.

5-14 61440520E1-5B Chapter 5, System Startup and Configuration - Configuring the PacketWave E510A/E520A

Configuring Services All provisioning of services is done using the Service Management Framework in ADTRAN LMS. For more information on configuring services, refer to the Service Management Framework Users Guide, P/N 61150SMFL10-31.

Configuring Ring Speed The E520A can be configured to different ring speeds: 1 G or 2.5 G. The default ring speed is 2.5 G. The ring speed can only be set using the set port ring speed command in the CLI. On a ring, the speeds must all be the same; different spans on the ring cannot have different speeds. To set the ring speed on an E520A (for example, to 1 G), use the following: set port ring speed <1G | 2.5G | OC3 | OC12 | OC48 | STM1 | STM4 | STM16> set port ring speed ring-1/1 1G

NOTE After you configure the ring speed, the shelf reboots automatically.

Suppressing Pluggable Alarms There are two pluggable alarms. The PLUGGAGE_UNIDENTIFIED alarm is raised when the SFP or GBIC identification PROM is not readable. The PLUGGABLE_NOT_APPROVED alarm is raised for an SFP running at the 2.5xRPR speed that has not been approved by the system vendor at the time of the software release. As of Release 7.5, the PLUGGABLE_NOT_APPROVED alarm is not raised for an SFP running at the 1xRPR or Gigabit Ethernet (GE) rate. This change does not imply that all GE and SONET SFPs and GBICs are approved for use with the system. Customers should use devices approved by the system vendor. This change does allow the roll out and approval of new GE and SONET pluggable devices without requiring a software change to remove the minor alarm. You can suppress these two pluggable alarms using the service port-alarm command in the CLI: service port-alarm [on | off] For example, the following command reports the current setting: service> port-name rpt-7/1 pluggable-not-approved Alarm pluggable-not-approved is not suppressed. For example, the following command disables the PLUGGABLE_NOT_APPROVED alarm: service> port-name rpt-7/1 pluggable-not-approved off For example, the following command reports the new setting: service> port-name rpt-7/1 pluggable-not-approved Alarm pluggable-not-approved is suppressed. If the PLUGGAGE_UNIDENTIFIED or PLUGGABLE_NOT_APPROVED alarms are raised, replace the SFP with a part recommended by a system vendor.

61440520E1-5B 5-15 PacketWave E510A/E520A Installation and Configuration Guide

This page is intentionally blank.

5-16 61440520E1-5B Chapter 6 Configuring Security

The products described in this chapter are third-party licensed products. The licenses and other information related to these third-party products are included in “Appendix E, Security”. This chapter contains the following sections on configuring security: • “Introduction to SecureWave” on page 6-2 • “Security Benefits” on page 6-2 • “Architecture” on page 6-4 • “PacketWave Configuration Procedures” on page 6-7 • “Configuring RADIUS” on page 6-10 • “Configuring User Access Rights” on page 6-22

61440520E1-5B 6-1 PacketWave E510A/E520A Installation and Configuration Guide

INTRODUCTION TO SECUREWAVE SecureWave is a security solution fully integrated with the entire ADTRAN PacketWave product family. Security is not just a matter of introducing password protection or various security protocols, such as Secure SHell (SSH). Nor is security just a technology. It is a process. Technology alone will not protect a system against poor security procedures. SecureWave encourages the implementation of correct security process protocols. A secure system must also have full protection. For example, implementing SSH will have limited effectiveness if SNMP communications are not encrypted. For this reason, SecureWave offers a full suite of security features. This provides a carrier-class product that offers the strongest security available using open standards. SecureWave uses a combination of industry-standard products: SSH and RADIUS (Remote Authentication Dial-In User Service). These standards provide a full set of security features. Firewall software is also employed to control the ports and services that are enabled. SecureWave keeps all security-related information and configuration in encrypted entries within the system database to provide protection from unauthorized access. The key itself is randomly generated during installation and is never disclosed.

SECURITY BENEFITS Security benefits provided by SecureWave include: • Remote Access Control • Authentication •Authorization • Accounting These features will be discussed in greater detail in the following sections.

Remote Access Control Every access service can be selectively enabled or disabled. By default, Telnet and ring services are enabled and the RS-232 port is functional. This conservative approach is consistent with security “best practices” as well as with industry practices. Unsecure services, such as SNMPv2, are disabled by default. An SSH security suite provides secure Telnet-like access (interactive terminal). SSH is a set of standards and an associated network protocol that allows establishing a secure channel between a local and a remote computer.

CAUTION You may want to turn off Telnet access; however, before disabling Telnet, configure and enable SSH.

6-2 61440520E1-5B Chapter 6, Configuring Security - Security Benefits

Authentication The following authentication services are supported: • RADIUS, using FreeRADIUS and Steel-Belted Radius • public key, for SSH access SecureWave implements an industry standard “key pair” authentication. Each party involved in a two-party communication generates a key pair. One key is a “public key”; the other key is a “private key.” Public keys are exchanged ahead of time unencrypted. Anyone with a public key for Party A may encrypt a message with that key and send it to Party A, with confidence that only Party A can decrypt the message as long as Party A never reveals the private key to others. Public key authentication uses the following process: 1. The client and server both generate key pairs. 2. The client hands its public key to the server and retrieves the server’s public key. 3. The client generates a message with its identity and a random string, encrypts the message with the server’s public key, and sends the message to the server. 4. The server decrypts the message with its private key, finds the client’s public key, then sends the message back along with the TDES (Triple DES) key and the random string that was received, all encrypted with client’s public key. 5. The client decrypts the message using its private key.

NOTE Local accounts on the RS-232 port may be used if the platform cannot contact the server.

Authorization Access to various CLI commands can be limited to a pre-defined set of user access rights. When an user is created, user rights are specified that enable or disable access to various sections of the CLI. This determines which commands a given user can view and execute. All user rights are administered in the CLI. User records can be added, viewed, modified, and deleted by issuing various system users commands.

Accounting Every action taken on the platform must be logged to maintain an audit of system activity. Syslog is available to provide this audit trail.

61440520E1-5B 6-3 PacketWave E510A/E520A Installation and Configuration Guide

ARCHITECTURE Figure 6-1 illustrates how SecureWave fits within the PacketWave product structure.

Figure 6-1. Security Architecture

RADIUS The RADIUS server is among the most widely used industry standards for distributed authentication and accounting. Although its primary purpose is to provide authentication for ISP services such as remote access and PPP, it is also widely used to authenticate access to network equipment. RADIUS provides three basic services: • Authentication •Authorization • Accounting (such as activity logging) RADIUS uses the MD5 encryption protocol to provide a cryptographically secure signature. It also uses a private key scheme for encrypting passwords.

6-4 61440520E1-5B Chapter 6, Configuring Security - Architecture

RADIUS by itself provides only authentication—not encryption—of data since only encrypted passwords are exchanged. It also does not cover remote access itself, so SecureWave also uses SSH if the administrator requires encrypted access to network equipment. RADIUS components include the following: • A RADIUS server that contains a list of authorized administrators and privilege level definitions. The server is located in a physically secure location. • A RADIUS client that runs on both the management station and the network equipment. The client forwards authentication requests (such as a user login and password) to the RADIUS server. Both client and server share a common private key, the “secret” used to encrypt communication.

SSH SSH provides host and user authentication and encryption so that both ends of the client/ server connection can be absolutely sure of each other’s identity. A public/private “key pair” is used to implement authentication. SecureWave uses an open source version of SSH called OpenSSH. This version supports the SSH-1 protocol. OpenSSH uses a variety of protocols for authentication, signing, and encryption, including the following: •RSA •MD5 •TDES

Security Database A separate security database maintains all security information, including the following: • SSH public keys •RADIUS configuration • Users and passwords for local access • Security configuration information (such as a list of enabled services) A separate security database allows all other information (such as logs, statistics, and provisioning) to be freely transferred without compromising security information. The security database is digitally signed with HMAC-RIPEMD160, a tamper-proof architecture. Private keys are kept encrypted with a cryptographically strong cipher (TDES).

Firewall The firewall is an integral part of remote access control. SecureWave implements an industry standard version of the IPFirewall (or IPFW), a FreeBSD IP packet filter and traffic accounting facility. The firewall comes with a predefined set of default rules. Some of these rules are for certain features, such as enabling and disabling services. Other rules are used for controlling access to the control plane and aspects of the architecture.

61440520E1-5B 6-5 PacketWave E510A/E520A Installation and Configuration Guide

In addition, a set of CLI commands provides administrative users the capability to allow or disallow certain services on a given node for the NMS interface, ring interface, or both the NMS and ring interfaces. Example services include the following: •SNMP • SSH •Telnet If a given node does not have a need to carry these services, the services can be disabled, thereby eliminating a potential security problem. PacketWave automatically generates firewall rules based on information administrators provide using the CLI. These rules are transparent to the user, and no special firewall configuration knowledge or skills are required to allow or disallow the services. For more information on configuring firewall commands, refer to the Command Line Interface Reference Guide, P/N 61440101E1-35. For more information on IPFW, refer to “Appendix E, Security”.

Fully Configurable Firewall The CLI contains several commands that allow the administrator to configure the firewall, add firewall rules, and delete firewall rules. You only need to add rules if you have a specific need. These rules follow the standard IPFW syntax, where the user can allow or disallow access to and from specific IP addresses or protocols.

CAUTION It is essential that the administrator have in-depth knowledge and experience in configuring an IPFW firewall prior to using any firewall configuration or firewall rule commands.

For more information on configuring PacketWave firewall commands, refer to the Command Line Interface Reference Guide, P/N 61440101E1-35.

Logging Packets for Debugging As a method of debugging, packets that are coming into the system from the MGMT port and any 10/100 or Gigabit Ethernet port in routing mode can be logged. Use the following CLI command to show all the options available for packet logging: set security firewall pktlog Refer to the Maintenance & Troubleshooting Guide, P/N 61440101E1-44, for more information on packet logging.

Physical Security Every security component in the architecture must be in a physically secure location, such as a network closet. It is difficult, if not impossible, to provide architecture security without ensuring physical security.

6-6 61440520E1-5B Chapter 6, Configuring Security - PacketWave Configuration Procedures

PACKETWAVE CONFIGURATION PROCEDURES To facilitate initial configuration of the PacketWave platform, procedures in this section are presented in the order in which they should be performed during initial installation. Individual procedures may be performed independently at a later time, as required.

Configuring Telnet, NMS, and SSH Perform the following procedures to configure Telnet, the NMS port, and SSH on the PacketWave platform.

Verify NMS Access By default, the NMS (MGMT) port is disabled. Use the following procedure to verify that the NMS port is enabled or to enable the port if it is disabled. 1. Issue the show routing config command. If the output shows interface dc0 in the list, NMS routing is enabled. 2. If the NMS port is disabled, enable it using the following command: set shelf routing For example: set shelf routing nms on

Verify Telnet Access By default, Telnet, routing and ring services are enabled, but all other services are disabled. Use the following procedure to verify that Telnet is enabled. 1. Log in as apollo. 2. Set up the platform. For assistance, refer to “Chapter 5, System Startup and Configuration”. 3. Verify Telnet access is enabled on the NMS and ring ports by using the following command: show security remote Service Status Interface Telnet Enabled NMS, Ring SNMP Disabled Ssh Disabled Ring Forwarding Enabled 4. If you want to enable SSH, do not log out of the CLI at this time, and execute the procedures provided in “Enable SSH (optional)” on page 6-7. If you do not want to enable SSH, logoff.

Enable SSH (optional) Since SSH configuration requires access to the platform from a remote client, SSH remote access should be enabled if you plan to use it. To enable SSH: 1. Use the set security remote command to enable SSH on both the NMS and the ring ports. set security remote SSH both SSH1

61440520E1-5B 6-7 PacketWave E510A/E520A Installation and Configuration Guide

2. Logoff. The next step in this procedure requires CLI access from a remote client. 3. From the remote client, login as apollo.

Configure Client Keys 1. Generate a client key pair. On UNIX-based client systems, use the command ssh-keygen to generate the users key pair. This utility is supplied with the open source OpenSSH SSH client package. On Windows systems, use an SSH client such as F-Secure SSH to generate the key pair. A filename, pass phrase, key size [512–4096 bits], and comment can be specified.

NOTE ADTRAN strongly recommends the key size not exceed 1024 bits. Keys exceeding this size can take a very long time to generate.

In the process of generating a client key pair, two files will be generated. The name for one file will be specified by the administrator (form example, ). A second file will be given the specified filename plus a “pub” extension (for example, .pub). The .pub file contains the public key. 2. A humanly-readable identifier known as a “fingerprint” for the key will be generated when the key is created. Make a record of this fingerprint for future validation. 3. FTP to the PacketWave equipment the .pub file containing the public key. 4. Install the public key from the FTP’d file (): set security ssh import 5. Verify the installed key: show security keys public RSA1 One of the keys listed should show the same fingerprint the administrator recorded after key creation.

Configure Host Keys 1. SSH will not operate until host keys have been generated. Use the CLI command to generate a host key: set security ssh host-generate RSA1 [size] 2. View this key: show security keys host RSA1 Be sure to write down the fingerprint displayed. It will be needed later to verify the transfer was secure.

6-8 61440520E1-5B Chapter 6, Configuring Security - PacketWave Configuration Procedures

NOTE The private key is never displayed.

NOTE It is not necessary to FTP back the public key since this will occur automatically the first time SSH is used.

NOTE Host keys generated while in SSH will be applied the next time a connection is made.

NOTE If host keys are changed in this way, the local ‘known-hosts’ file must be erased first, forcing SSH to retrieve the host key again on the next connection. If this is not performed, SSH will detect a key/host mismatch, which is a security breach.

Enable SSH 1. Add a route/gateway so that the client can be reached by the PacketWave equipment: set security remote ssh [both | none | SSH1 | SSH2] where: • both specifies protection for the ring network and the NMS network; • only SSH1 is currently supported. Firewall rules will be created automatically that enable SSH access to the NMS port.

Run SSH Prior to running SSH, ensure client capabilities are installed on the client machine. 1. Open an SSH client session. For example, on UNIX: ssh 2. If a pass phrase was specified when the public key was created, a prompt will request a pass phrase. 3. If this is the first time accessing the server using this client, an option to receive the public key from the host will be provided. 4. The login should now be displayed. To exit after logging in, enter logout.

61440520E1-5B 6-9 PacketWave E510A/E520A Installation and Configuration Guide

CONFIGURING RADIUS User authentication can be performed in two ways: • Locally managed users can be managed directly by the CLI. • Remotely managed users can be managed by RADIUS, supported by the RADIUS client. This setup procedure is designed for the interface of a Free RADIUS or Steel-Belted Radius server. RADIUS must be set up on both the PacketWave and the RADIUS Server. Read the following sections to configure RADIUS.

RADIUS Client The RADIUS client forwards authentication requests, such as a user login and password, to the RADIUS server. You will need to configure the PacketWave equipment as a RADIUS client to identify the server in which the user information is stored. There are three steps to the PacketWave setup, which will be described in greater detail in the following sections: 1. Set up routes and verify connectivity to the RADIUS server. 2. Determine how logins will be made. The choices are local, remote or both. Local will not use RADIUS; it uses the PacketWave only. Remote will use RADIUS only. 3. Identify the RADIUS server IP address, the secret code, and the port (socket).

Setup Routes 1. Set up routes on each PacketWave to have access to the network where the RADIUS server resides: > show routes

show routes ROUTE NET TABLE destination/mask gateway flags Refcnt Use Slot Port ------10.0.0.0/8 10.0.81.26 UC 0 0 ring - 127.0.0.0/8 127.0.0.1 U 0 0 loopback - 172.21.0.0/16 172.21.0.40 UC 0 0 nms ------

ROUTE HOST TABLE destination/mask gateway flags Refcnt Use Slot Port ------127.0.0.1/32 127.0.0.1 UH 1 10444 loopback ------

2. Verify the PacketWave has access to the RADIUS server: > ping 172.21.0.27

6-10 61440520E1-5B Chapter 6, Configuring Security - Configuring RADIUS

Set Logins 1. Set the logins to both. This instructs the PacketWave to authenticate the login using either the RADIUS or the PacketWave databases. To log in using the PacketWave database when both is enabled, an @ (at) sign is required in front of the login username. > show sec > show security help commands: community : Display the SNMP community strings firewall : Display firewall configuration logins : Display login authorization configuration radius : Display radius server configuration remote : Display current remote access service status keys : Change to SSH Keys level Example: > set sec logins both > show security logins RADIUS Enabled Local Enabled

Set RADIUS IP Address, Code, and Port 1. Set the RADIUS IP address, secret code and port using the following commands: > set sec radius help commands: add : Configure the RADIUS server remove : Remove the RADIUS server

> set sec radius add help usage: add [server IP port] where: • server IP address is the IP address of the RADIUS server • secret is the string that allows access to the RADIUS server • server IP port is the port on which the RADIUS server is “listening” > set sec radius add 172.21.254.27 testing123 1645 > show security radius RADIUS Server IP Address: 172.21.254.27 Port: 1645

RADIUS Server The RADIUS server contains a list of authorized administrators and privilege level definitions. To configure the RADIUS server for users, refer to the RADIUS documentation. In addition, the RADIUS server needs to be configured to use the PacketWave dictionary to support the extended attributes that ADTRAN requires, such as user access rights. ADTRAN does not make any recommendation as to the type of RADIUS server used or the installation. Only the configuration of FreeRADIUS and Steel-Belted Radius will be addressed in the following sections.

61440520E1-5B 6-11 PacketWave E510A/E520A Installation and Configuration Guide

FreeRADIUS Setup and Configuration There are three steps to the FreeRADIUS setup: 1. Data fill the RADIUS dictionary to support the PacketWave attributes. 2. Identify valid clients (PacketWave nodes) 3. Create valid users. These steps are described in detail in the following subsections.

Data Fill the RADIUS Dictionary Data fill the dictionary: 1. The dictionary is located in the raddb directory and is titled dictionary or may be titled dictionary.PacketWave. 2. You can set up a vendor-specific dictionary on the RADIUS server. In the dictionary you can enter vendor-specific information. A number of vendor attributes are configurable, although at present, there is only one. The attribute is user access rights. 3. When you configure a user, you need to enter the ADTRAN access rights, in addition to information such as userid and password. The following shows a sample dictionary. vi dictionary.PacketWave # freeradius dictionary file for PacketWave vendor # #

VENDOR PacketWave 4614

# # PacketWave attributes # # NOTE: The current release only supports PacketWave-Access-Rights attribute; # other attributes are reserved for use in future versions. # # ATTRIBUTE PacketWave-Access-Rights 220 string PacketWave ATTRIBUTE PacketWave-Max-Access-Rights 221 string PacketWave ATTRIBUTE PacketWave-Ports-Domain 222 string PacketWave # # PacketWave-Access-Rights is a colon separated list of access rights # attributes. Each access right gives permission to execute a separate # set of CLI commands. # # The following access rights are defined: # Right Meaning # ------# “none” “no rights” # “cfg” “show configuration” # “cfg-set” “set configuration” # “password-set” “allow changing password” # “shelf-set” “set shelf config” # “sys” “system settings” # “security” “show security info” # “security-set” “set security info”

6-12 61440520E1-5B Chapter 6, Configuring Security - Configuring RADIUS

# “user-show” “show users” # “user-create” “create users” # “user-delete” “delete users” # # The following are “composite access rights”, i.e., sets # of the above primitive rights. # # “oper-rights “--> “cfg” # “admin-rights “--> “cfg,password-set,security,cfg-set,shelf-set,sys” # “root rights “--> “all rights” :wq

Setup Clients To setup the clients as the PacketWave nodes: 1. Open the clients.conf file located in the raddb directory: vi clients.conf client 172.21.0.40 { secret = testing123 shortname = PacketWave1 } :wq 2. Enter the IP address, secret code, and a shortname as shown above. 3. Repeat step 2 for each of the PacketWaves in the network.

Add Users Add the users. The users file is located in the raddb directory and is titled users. A # (pound or hash mark) symbol in the file indicates a remark. Every user needs to have PacketWave access rights set up. PacketWave access rights are a list of access rights attributes. Each access right gives permission to execute a separate set of CLI commands. The following access rights are defined as shown in Table 6-1.

Table 6-1. Access Rights

Right Meaning

none no rights

cfg show configuration

cfg-set set configuration

password-set allow changing password

shelf-set set shelf config

sys system settings

security show security info

security-set set security info

user-show show users

61440520E1-5B 6-13 PacketWave E510A/E520A Installation and Configuration Guide

Table 6-1. Access Rights (Continued)

Right Meaning

user-create create users

user-delete delete users

service service menu access

Table 6-2 defines the composite access rights — that is, sets of the above user access rights.

Table 6-2. Composite Rights

Right Meaning

oper-rights cfg

admin-rights cfg, password-set, security, cfg-set, shelf-set, sys

root-rights all rights

vi users # apollo Auth-Type := Local, Password == “pktwave1000” Reply-Message = “Welcome to the PacketWave Network”, PacketWave-Access-Rights = “root-rights”, PacketWave-Max-Access-Rights = “none” # # user1 Auth-Type := Local, Password == “aaa” # Reply-Message = “root group”, # PacketWave-Access-Rights = “root-rights”, # PacketWave-Max-Access-Rights = “none” # PacketWave-Ports-Domain = “card1,card2,card3:4,card3:9” # # user2 Auth-Type := Local, Password == “aaa” # Reply-Message = “root group + shell escape”, # PacketWave-Access-Rights = “root-rights,shell-exec”, # PacketWave-Max-Access-Rights = “shell-exec” # # admin Auth-Type := Local, Password == “aaa” # Reply-Message = “admin group”, # PacketWave-Access-Rights = “admin-rights”,

Configuration Prior to starting the daemon, perform the following steps: 1. Ensure ports have been assigned for RADIUS: vi /etc/services radius 1645/udp radius radacct 1646/udp :wq! 2. Setup the dictionary:

6-14 61440520E1-5B Chapter 6, Configuring Security - Configuring RADIUS

a. Ensure #$INCLUDE dictionary.compat#compatibility is not remarked out by removing the first # as shown below. b. Ensure $INCLUDE dictionary.tunnel is remarked out by inserting a # as shown below. c. Add the pointer to the PacketWave.dictionary to the rest of the dictionary pointers as shown below. This dictionary is the one you built in “Data Fill the RADIUS Dictionary” on page 6-12. vi dictionary #$INCLUDE dictionary.compat #compatibility $INCLUDE dictionary.compat #compatibility

$INCLUDE dictionary.tunnel #$INCLUDE dictionary.tunnel

$INCLUDE dictionary.PacketWave :wq 3. To setup the port, ensure the port is set to 1645 in raddb/radiusd.conf: vi radiusd.conf port = 1645 :wq

Start RADIUS Daemon Start the RADIUS daemon by entering the following command: ./sbin/radiusd -x (-x optional and used to monitor authentication)

Troubleshooting In the event you are unable to login because of an error in the RADIUS configuration, use the @ sign (such as, @apollo). The @ sign in front of a user name allows a login to a PacketWave without a RADIUS authentication. RADIUS logs are located in v0.3/var/log/radius: • radius.log - records all daemon activity • radwatch.log - records when RADIUS fails and is restarted

NOTE This is not the root/var, but rather a radius/var.

Steel-Belted Radius Setup and Configuration There are three steps to the Steel-Belted Radius setup: 1. Install and configure Steel-Belted Radius. 2. Set up RAS clients. 3. Set up users.

61440520E1-5B 6-15 PacketWave E510A/E520A Installation and Configuration Guide

If you experience any problems during the install of Steel-Belted Radius, consult the Steel- Belted Radius Help or user documentation. If you experience any problems during the configuration or use of Steel-Belted Radius, contact “ADTRAN Technical Support” using the contact information provided in “Appendix G, Warranty”.

Installing and Configuring Steel-Belted Radius 1. Install Steel-Belted Radius according to the installation instructions. 2. Create a PacketWave dictionary file by opening Notepad or comparable plain text editor in Microsoft Windows and entering the following: @radius.dct

ATTRIBUTE LN-Access-Rights 26 [vid=1963 type1=220 len1=+2 data=string] R

# # PacketWave-Access-Rights is a colon separated list of access rights # attributes. Each access right gives permission to execute a separate # set of CLI commands. # # The following access rights are defined: # Right Meaning # ------# “none” “no rights” # “cfg” “show configuration” # “cfg-set” “set configuration” # “password-set” “allow changing password” # “shelf-set” “set shelf config” # “sys” “system settings” # “security” “show security info” # “security-set” “set security info” # “user-show” “show users” # “user-create” “create users” # “user-delete” “delete users” # # The following are “composite access rights”, i.e., sets # of the above primitive rights. # # “oper-rights” --> “cfg” # “admin-rights” --> “cfg:password-set:security:cfg-set:shelf-set:sys” # “root-rights” --> “all rights” # 3. Save the dictionary file as PacketWave.dct. 4. Edit the vendor.ini file located in the Service directory where Steel-Belted Radius is installed. Add the following text to the bottom of the vendor.ini file and save the file: vendor-product = PacketWave dictionary = PacketWave ignore-ports = no help-id = 2000 Send-Class-Attribute = no

5. Edit the dictiona.dcm file located in the Service directory where Steel-Belted Radius is installed.

6-16 61440520E1-5B Chapter 6, Configuring Security - Configuring RADIUS

In the file, between @lrs.dct and @marc.dct, add @packetwave.dct and save the file.

NOTE Entries in the dictiona.dcm file are listed alphabetically. Insert @packetwave.dct in the correct alphabetical location if @lrs.dct and @marc.dct are not present.

6. Restart the Steel-Belted Radius daemon using one of the following two options: • Restart the PC from the Windows Start menu. Once you have logged in, start the Steel- Belted Radius Administrator. or • Restart the Steel-Belted Radius daemon by right-clicking on My Computer and then selecting Manage -> Services & Applications -> Services. In Services, scroll down and highlight Steel-Belted Radius. Click the Restart Services icon ( ). 7. In the Steel-Belted Radius Administrator window, click Connect. You should receive the date and time the server was started in the Status window as shown in Figure 6-2.

Figure 6-2. Steel-Belted Radius Administrator, Connection Established

61440520E1-5B 6-17 PacketWave E510A/E520A Installation and Configuration Guide

Setting Up RAS Clients 1. In the Steel-Belted Radius Administrator window, select the RAS Clients radio button in the left column and click Add. See Figure 6-3 for the RAS Clients window.

Figure 6-3. Steel-Belted Radius Administrator, RAS Clients

2. In the Client Name field, enter the client name and click OK. This can be any name used to refer to the PacketWave platform. See Figure 6-4 for an example of the Add New RAS Client window.

PacketWave San Francisco

Figure 6-4. Steel-Belted Radius, Add New RAS Client window

3. Enter one of the following for the IP address: • If the PacketWave platform is to communicate with the RADIUS server via the ring interface, in the IP address field, enter the IP address of the PacketWave platform. or • If the PacketWave platform is to communicate with the RADIUS server through the NMS port interface, in the IP address field, enter the NMS port IP address of the PacketWave platform.

6-18 61440520E1-5B Chapter 6, Configuring Security - Configuring RADIUS

4. Enter the Make/model (as shown in Figure 6-5) by scrolling and selecting PacketWave from the drop-down list. See Figure 6-5 for an example of the RAS Clients window with the IP address and Make/ model filled in.

PACKETWAVE SAN FRANCISCO

ADTRAN

Figure 6-5. Steel-Belted Radius Administrator, RAS Clients

5. Click the Edit authentication shared secret… button. Enter the shared secret that will be used by the PacketWave platform to connect via RADIUS and click Set. See Figure 6-6 for an example of the Enter shared secret window.

Figure 6-6. Steel-Belted Radius, Enter Shared Secret

NOTE The shared secret can differ from node to node, but for each node, the secret has to be defined in the Steel-Belted Radius Server and configured on the PacketWave platform as the same secret.

6. In the RAS Clients window, click Save. (See Figure 6-3 for the RAS Clients window.)

61440520E1-5B 6-19 PacketWave E510A/E520A Installation and Configuration Guide

Setting Up Users 1. In the Steel-Belted Radius Administrator window, select the Users radio button in the left column and click Add. See Figure 6-7 for the Users window.

Figure 6-7. Steel-Belted Radius, Users Window

2. In the Enter user name field, enter the username of the person who will be accessing the PacketWave platform via RADIUS. See Figure 6-8 for an example of the Add New User window.

Figure 6-8. Steel-Belted Radius, Add New User

6-20 61440520E1-5B Chapter 6, Configuring Security - Configuring RADIUS

3. Click the Set password… button as shown in the example in Figure 6-9.

Figure 6-9. Steel-Belted Radius, New User Created

4. Enter the password in the Enter User Password window and click Set, as shown in Figure 6-10.

Figure 6-10. Steel-Belted Radius, Enter User Password

5. Select the Return list attributes tab and click Ins. 6. In the Available attributes tab, select LN-Access-Rights. Set the user access rights, as shown in Figure 6-11, according to the commands and values in the PacketWave dictionary file (packetwave.dct), or see Table 6-1, Table 6-2, and Table 6-3 for definitions of access rights. When adding multiple access rights, separate each right with a colon. Click Add and Close when finished.

61440520E1-5B 6-21 PacketWave E510A/E520A Installation and Configuration Guide

Figure 6-11. Add New Attribute Window for Setting User Rights

7. Click Save in the Users window to save all configuration information. Configuration of Steel-Belted Radius is now complete.

CONFIGURING USER ACCESS RIGHTS Prior to the PacketWave arriving at the installation site, we recommend one individual be identified who is in charge of managing users. This individual will have access to all user profiles. The User Manager should be the only person who performs the procedures in this section. This will help ensure security for user access. To simplify creating access rights, develop a list of users who require CLI access. For each user, determine the types of tasks they need to perform, such as configuring the platform, or configuring the system. The CLI provides a default login called apollo. When the CLI starts for the first time, the user is prompted to enter a password. After the password has been entered, the CLI prompt appears. CLI commands accessible at this point are based on the user login. Access rights for all commands are implemented on the CLI. If a user does not have access rights to execute a specific command, the command is not displayed. The following CLI commands are used to manage user access rights: • system users> add • system users> list • system users> remove • system users> password • system users> rights Since these commands require interactive input, they cannot be administered using a batch file. For more detail on these commands and their parameters, refer to the Command Line Interface Reference Guide, P/N 61440101E1-35.

6-22 61440520E1-5B Chapter 6, Configuring Security - Configuring User Access Rights

Add Users 1. Determine access right requirements for users. The following table defines the type of access rights available on the PacketWave. Think about the types of tasks users must perform on the system. Refer to the following table (Table 6-3) to determine the rights that each user should be assigned.

Table 6-3. Access Rights

Value Access rights

0x00000000 No access.

0x00000001 Configuration display access. Includes show commands.

0x00000002 Configuration modification. Includes set commands.

0x00000004 Password change access. Provides ability to change system user passwords.

0x00000008 Shelf configuration modification access. Includes set shelf commands.

0x00000010 System configuration modification access. Includes system commands.

0x00000020 Security display access. Includes show security commands.

0x00000040 Security modification access. Includes set security commands.

0x00000080 User display access.

0x00000100 User creation access.

0x00000200 User deletion access.

0x00000400 Service menu access. Includes service commands. For troubleshooting only.

NOTE To view access rights currently available on the system, use the system users rights command.

2. Calculate the hex value to assign the user. Each access right is identified by a unique hex value. To calculate the hex value for a given user, add up the values for each service for which the user is to have access. In this step, we will calculate the hex values for three separate users: • Dave Smith. Dave will have configuration display access and configuration modification access. • Jan Brown. Jan will have access to all areas except user creation and user deletion. • Rob Thomas. Rob will have the same user access rights as Jan Brown. To create a user record for Dave Smith, use the following equation: configuration display access (0x00000001) + configuration modification access (0x00000002) = 0x00000003

61440520E1-5B 6-23 PacketWave E510A/E520A Installation and Configuration Guide

To create a user record for Jan Brown, use the following equation: configuration display access (0x00000001) + configuration modification access (0x00000002) + password change access (0x00000004) + shelf configuration modification access (0x00000008) + system configuration modification access (0x00000010) + Security display access (0x00000020) + security modification access (0x00000040) + user display access (0x00000080) + service menu access (0x00000400) = 0x000004ff

NOTE These hex values can be determined using a calculator capable of hexadecimal conversion.

3. Once the hex values have been calculated, add and set up the users using the system users> add command:

system users> add Please enter the user name: dave smith Please enter the new password: ############ Please reenter the new password: ############ Please enter the access rights for this user (in hex): 0x00000003

system users> add Please enter the user name: jan brown Please enter the new password: ############ Please reenter the new password: ############ Please enter the access rights for this user (in hex): 0x000004ff

system users> add Please enter the user name: rob thomas Please enter the new password: ############ Please reenter the new password: ############ Please enter the access rights for this user (in hex): 0x000004ff In this example, Dave Smith, Jan Brown, and Rob Thomas have been added to the system. After this step is complete, users can access the CLI by entering the name and password entered here. 4. Repeat the above step for each individual who requires CLI access.

NOTE Up 10 local user IDs are available; however, one user ID is pre- assigned for apollo, only nine (9) userids can be locally defined.

6-24 61440520E1-5B Chapter 6, Configuring Security - Configuring User Access Rights

Managing Users The following sections describe different methods of managing users.

NOTE Entering a question mark (?) at the end of a non-interactive command generates a “help” list for that command (example: system users list ?).

Displaying Users Use the system users> list command to display a list of users currently on the system. An asterisk (*) is used to list information for all users. For example: system users> list * detailed apollo 0x000007ff dave smith 0x00000003 jan brown 0x000004ff rob thomas 0x000004ff

Changing Passwords Use the system users> password command to change a user's password. For example:. system users> password Please enter the current password: ############# Please enter the new password: ############ Please reenter the new password: ############

Removing Users Use the system users> remove command to delete a local user from a node. For example: system users> remove Please enter the user name: jan brown Remove user jan brown. Are you sure? [Yes/No] yes

system users> list * detailed apollo 0x000007ff dave smith 0x00000003 rob thomas 0x000004ff Jan Brown has now been removed as one of the users.

61440520E1-5B 6-25 PacketWave E510A/E520A Installation and Configuration Guide

User Access Rights and CLI Usage This section describes the impact user access rights has on CLI usage. The tree command displays all commands at all levels below the current level. Commands displayed are based on the user’s access rights, the current level, and the optional rights parameter. For example, assume Dave Smith logs in to the PacketWave. He has configuration display and modification access, or 0x0000003. When Dave issues the tree command from the base level, only the global commands and the commands at the show and set levels are displayed. Note that the initial and maximum rights are displayed in hex value as local user rights = x/x: login: dave smith password: ########## local user dave smith logged on local user rights = 3/3

Displaying Access Rights for Commands When the rights parameter is used, access rights for the command are displayed along with the command. This provides users the ability to identify the access rights that are required for the commands. To display access rights for commands, issue the tree rights command to view access rights available from where the command is executed. For example, if a user with 0x00000001 rights issues the tree rights command from the show shelf level, the following is displayed: > show shelf show shelf> tree rights

boot-time : 0x00000001 config : 0x00000001 cp-routes : 0x00000001 cpu-usage : 0x00000001 detailed : 0x00000001 lamp-test : 0x00000001 memory : 0x00000001 ntp-server : 0x00000001 syslog : 0x000000011

Displaying Help When a user executes the help command, only commands that the user has access rights to are displayed. If the user attempts to execute a command not included in the access rights, an access error message is displayed. For example, assume two technicians are using the system: Theresa Thomas and Jim Hanks. Theresa has 0x5f3 access rights. Jim has 0x1 access rights. Theresa can access almost everything in the CLI but cannot change her password, modify the platform configuration, delete users, or access the service shell. Jim can only issue show and global commands. When Theresa and Jim attempt to access help in the CLI, they will only be able to see the commands available to them given their different access rights. When Theresa logs in, the base, set, system, and system users levels are available; however, commands for which Theresa does not have access rights to are not displayed. An error

6-26 61440520E1-5B Chapter 6, Configuring Security - Configuring User Access Rights message is displayed if Theresa attempts to execute a command she does not have access rights to use, such as in the following example: set shelf: > set shelf Command shelf cannot be executed. User lacks sufficient access rights. > 15:46:18 tShell: SECURITY: ERROR: authorization denied: insufficient access rights to execute 'shelf'

Suppressing Error Messages The error message displayed when a user attempts to issue a command that is outside of their access rights can be suppressed using the system messages none command. This example illustrates the display when the error message is suppressed:

Local user dave smith logged in at FRI MAY 10 15:56:29 2002 UTC User rights are 3/3

> help commands : base : Return to top command level help : Show commands or help on commands history : Display command history logout : Log out of the CLI quit : Move up one command level tree : Display command tree whoami : Display currently logged in user console : Connect to another node ping : Ping a host the specified number of times traceroute : Trace the route packets follow to a host set : Change to Set level show : Change to Show level

NOTE In order to suppress the error message, the user must have user display access rights, 0x00000080.

NOTE If security is disabled, the message “[NOSEC] >” is prepended to the CLI prompt that informs the user security is not active:

61440520E1-5B 6-27 PacketWave E510A/E520A Installation and Configuration Guide

Enabling and Disabling Remote Access Services The CLI contains two types of commands that impact firewall operations. The set security remote commands require no special firewall configuration knowledge or skills. These are considered “basic” firewall configuration commands. In most cases, these commands will meet whatever firewall configuration requirements there are for a given ring. Services that can be controlled include: •SNMP • SSH •Telnet Unless there is a specific requirement to use one of services listed, we recommend all of these services be disabled on all nodes. Prior to performing the following procedure, determine the services that are required for each node in the network. To facilitate CLI configuration usage, create a spreadsheet that lists these requirements. An example is provided below. In this case, all initial administrative configuration work has been performed, so there is no need to keep SNMP and Telnet services enabled on every node. However, the sample ring uses static routing on the ring interface, so it is enabled. SNMP on the NMS interface is also required, so these services are also enabled (as shown in Table 6-4).

Table 6-4. Example of Services Enabled and Disabled on Ring

Node Routing SNMP SSH Telnet

Read Enabled, NMS Write Disabled, NMS Disabled, NMS Disabled, NMS 1 Enabled Read Disabled, Ring Enabled, Ring Disabled, Ring Write Disabled, Ring

Read Enabled, NMS Write Disabled, NMS Disabled, NMS Disabled, NMS 2 Enabled Read Disabled, Ring Enabled, Ring Disabled, Ring Write Disabled, Ring

Read Enabled, NMS Write Disabled, NMS Disabled, NMS Disabled, NMS 3 Enabled Read Disabled, Ring Enabled, Ring Disabled, Ring Write Disabled, Ring

Below is a list of possible conditions that could require services to be enabled. This is provided only as a guideline; the administrator should check with the network engineer to determine which services should be enabled or disabled. The following services should be enabled: • Telnet services provided to subscribers on the ring • SNMP services to communicate alarming conditions to an OAM&P system

6-28 61440520E1-5B Chapter 6, Configuring Security - Configuring User Access Rights

NOTE For the ADTRAN LMS to operate properly, SNMP services must be enabled.

Change IP Address Check the NMS port address. If it is enabled, if you are using pre-5.0 release nodes, or if you do not want to run dynamic routing, add cp routes on the nodes to the NMS port IP address.

Enable SNMP Telnet and ring services are enabled by default. SNMP must be enabled in order for the ADTRAN LMS or other OAM&P device that collects alarm and state information to work properly. On the discovery node, SNMP must be enabled on both the NMS interface and the ring interface. On the other nodes, SNMP must be enabled on the ring interface. To enable SNMP and any other protocols, use the set security remote command. The syntax for each service varies slightly. Refer to the Command Line Interface Reference Guide, P/N 61440101E1-35 to view syntax details for other services. 1. Login to the CLI.

NOTE The administrator logging in must possess security modification access rights (0x00000040).

2. Enable the SNMP service. (Turn on SNMP read-only or read-write access on both the NMS and the ring interfaces.) For example: set security remote> snmp usage: snmp [read | write] where: • both means SNMP is enabled on both the ring and the NMS (MGMT) port interfaces • ring means SNMP is enabled on the ring interface • nms means SNMP is enabled on the NMS (MGMT) port • none means SNMP access is disabled on all interfaces • read means SNMP read access is enabled on the specified interface(s) • write means SNMP read/write access are enabled on the specified interface(s)

NOTE If the SNMP access type is not specified, and the interface is not none, SNMP read access is enabled on the specified interface(s).

61440520E1-5B 6-29 PacketWave E510A/E520A Installation and Configuration Guide

NOTE Enabling SNMP to the NMS interface means that SNMP requests can be sent to the NMS interface IP address and received on the NMS port. Enabling SNMP to the ring interface means that SNMP requests can be sent to the ring interface IP address and received on the ring port.

The actual command is as follows: set security remote> snmp both read 3. Verify that ring forwarding is enabled. To turn ring forwarding on, use the following command: set security remote> ring on 4. Verify the changes. For example: set security remote> show security remote Service Status Interface Telnet Enabled NMS, Ring SNMP Read Only NMS, Ring Ssh Disabled Ring Forwarding Enabled

Disable Services After all configuration work is complete on the ring, services that are not required as a part of normal ring and NMS network operations should be disabled. This is done to enhance security. The syntax for each service varies slightly. The procedure below describes how to disable a single service. Refer to the Command Line Interface Reference Guide, P/N 61440101E1-35 to view syntax details for other services. 1. Login to the CLI.

NOTE The administrator logging in must possess security modification access rights (0x00000040).

2. Disable the service. Assume SNMP read and write services should be disabled on the ring and NMS interfaces. The command uses this syntax: set security remote snmp [read | write]> The actual command in this case is as follows: set security remote> snmp none

6-30 61440520E1-5B Chapter 6, Configuring Security - Configuring User Access Rights

3. Verify the changes as shown below. Note that SNMP now shows as Disabled. set security remote> show security remote Service Status Interface Telnet Enabled NMS SNMP Disabled Ssh Disabled Ring Forwarding Enabled

Advanced Firewall Configuration In addition to the basic commands, the CLI contains several commands that allow the administrator to configure the firewall, add firewall rules, and delete firewall rules: set security firewall add set security firewall remove These rules follow the standard IPFW syntax, where the administrator can allow or disallow access to and from specific IP addresses or protocols. For example, a given firewall rule can control the parameters listed below. The general syntax is as follows: Actions include: • allow, permit, accept, pass, deny, drop, reject, unreach code, reset, count, skipto num, logamount count Protocols include: • IP, TCP, UDP, ICMP, number The firewall rules that you create must be numbered in the range 30000 to 39000. By default, access to user ports will be denied by the firewall. (User ports are those ports that are located and are used to forward user data.) If you want to enable access to a specific user port, you have to add one or more firewall custom rules. For syntax details, refer to the Command Line Interface Reference Guide, P/N 61440101E1-35.

CAUTION Since the firewall acts as a powerful filter for IP traffic, there is the potential to stop all traffic from flowing through the system if the firewall is configured improperly. There is also the potential that an improperly defined rule may weaken security. It is essential that the administrator have in-depth knowledge and experience configuring an IPFW firewall prior to using the firewall configuration or firewall add/remove commands.

61440520E1-5B 6-31 PacketWave E510A/E520A Installation and Configuration Guide

References For more information on various topics, refer to the following references: • For more information on security, refer to the following: Stallings, William. Cryptography & Network Security: Principals & Practice. 2nd. Ed. N.p.: Prentice Hall, 1999. • For more information on how to configure Secure Shell (SSH), refer to the following: • Barrett, Daniel J., and Richard Silverman. SSH, The Secure Shell: The Definitive Guide. 1st. Ed. N.p.: O’Reilly & Associates, 2001. • For more information on SSH2 Protocols, enter a “draft-ietf-secsh” keyword search at http://search.ietf.org/search/brokers/internet-drafts/query.html. • For more information on the IPFW firewall, refer to “Appendix E, Security”, which details the IPFW features that are supported by ADTRAN.

6-32 61440520E1-5B Appendix A Approvals and Compliance

This appendix describes approvals and compliance information for the PacketWave E510A/ E520A products. This appendix contains the following sections: • “Federal Communications Commission Regulatory Statement” on page A-2 • “Reclamation of Hazardous Substances Compliance” on page A-3

61440520E1-5B A-1 PacketWave E510A/E520A Installation and Configuration Guide

FEDERAL COMMUNICATIONS COMMISSION REGULATORY STATEMENT This equipment has been tested and found to comply with the limits of a Class A digital device, pursuant to part 15 of the Federal Communications Commission (FCC) Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference in which case the user will be required to correct the interference at his own expense.

Safety UL/cUL 60950, EN 60950 (TUV), EN 60825-1 and EN 60825-2

Electromagnetic Compatibility FCC Part 15 Class A, EN 55022 Class B, VCCI Class B, EN 300 386 (other than Telecommuni- cations Centre Applications)

A-2 61440520E1-5B Appendix A, Approvals and Compliance - Reclamation of Hazardous Substances Compliance

RECLAMATION OF HAZARDOUS SUBSTANCES COMPLIANCE The following tables (in both English and Chinese) represent the required RoHS compliance information for enclosures (chassis) and modules (cards).

Table A-1. Names/Content of Toxic and Hazardous Substances or Elements (for Enclosures)

Hexavalent Polybrominated Polybrominated Lead Mercury Cadmium Chromium Biphenyls Diphenyl Ethers Part Name (Pb) (Hg) (Cd) (Cr-VI) (PBB) (PBDE)

Housing OOOO O O

Primary Card XOOOO O

Secondary Card(s) XOOO O O

Power Supply XOOO O O

O: Indicates that this toxic or hazardous substance contained in all of the homogeneous materials for this part is below the limit requirement in SJ/T11363-2006. X: Indicates that this toxic or hazardous substance contained in at least one of the homogeneous materials used for this part is above the limit requirement in SJ/T11363-2006. (Enterprises may further provide in this box technical explanation for marking “X” based on their actual conditions.)

Table A-2. Names/Content of Toxic and Hazardous Substances or Elements (for Enclosures), Chinese

(Pb) (Hg) (Cd) (Cr-VI) (PBB) (PBDE)

໪໇ OOOO O O

Џव XOOOOO

ࡃव˄㢹ᑆᓴ˅ XOOO O O

⬉⑤ X O OO O O

O˖㸼⼎䆹᳝↦᳝ᆇ⠽䋼೼䆹䚼ӊ᠔᳝ഛ䋼ᴤ᭭Ёⱘ৿䞣ഛ೼ SJ/T11363-2006 ᷛޚ㾘ᅮⱘ䰤䞣㽕∖ҹϟ X˖㸼⼎䆹᳝↦᳝ᆇ⠽䋼㟇ᇥ೼䆹䚼ӊⱘᶤϔഛ䋼ᴤ᭭Ёⱘ৿䞣䍙ߎSJ/T11363-2006 ᷛޚ㾘ᅮⱘ䰤䞣㽕∖ ˄ӕϮৃ೼ℸ໘ˈḍ᥂ᅲ䰙ᚙމᇍϞ㸼Ёᠧ“”X ⱘᡔᴃॳ಴䖯㸠䖯ϔℹ䇈ᯢ˅

61440520E1-5B A-3 PacketWave E510A/E520A Installation and Configuration Guide

Table A-3. Names/Content of Toxic and Hazardous Substances or Elements (for Modules)

Hexavalent Polybrominated Polybrominated Lead Mercury Cadmium Chromium Biphenyls Diphenyl Ethers Part Name (Pb) (Hg) (Cd) (Cr-VI) (PBB) (PBDE)

Primary Card XOOO O O

Front End Assembly OOOOO O

Table A-4. Names/Content of Toxic and Hazardous Substances or Elements (for Modules), Chinese

(Pb) (Hg) (Cd) (Cr-VI) (PBB) (PBDE)

Џव XOOO O O

ࠡッ㒘ӊ OOOOO O

A-4 61440520E1-5B Appendix B Physical Chassis Specifications

This appendix describes the specifications for the PacketWave E510A/E520A. It contains the following sections: • “PacketWave E510A/E520A Chassis Specifications” on page B-2 • “E510A/E520A Hardware Specifications” on page B-4

61440520E1-5B B-1 PacketWave E510A/E520A Installation and Configuration Guide

PACKETWAVE E510A/E520A CHASSIS SPECIFICATIONS See Table B-1 for the physical specifications of the PacketWave E510A/E520A.

Table B-1. Physical Specifications

Specification Value

Dimensions (Height x Width x Depth) 2.60 in. x 17.00 in. x 17.00 in. (6.60 cm x 43.69 cm x 43.18 cm)

Weight 22 lb, fully configured (10 kg)

Rack Required 19-in. rack mountable or optional wall mount

Input Power 140 W Universal AC input power or 144 W Universal DC input power

See Table B-2 for the PacketWave E510A/E520A chassis configuration.

Table B-2. Chassis Configuration

Specification Value

Fixed interface ports Eight 10/100Base-T ports

E510A: Dual 1 Gbps RPT ring interface E520A: Dual 1–2.5 Gbps RPT ring interface

Ethernet interface expansion module single port or dual port Gigabit Ethernet, with SFP optics option

TDM interface expansion module 24 T1 ports/21 E1 ports or 8 T1 ports/8 E1 ports

External Interfaces RS-232 console port (DB-9 connector)

NMS/MGMT Ethernet port (RJ-45 connector)

Power (nominal) 100—240 VAC autoranging power supply or –48 VDC power supply

See Table B-3 for the PacketWave E510A/E520A power specifications.

B-2 61440520E1-5B Appendix B, Physical Chassis Specifications - PacketWave E510A/E520A Chassis Specifications

Table B-3. Power Specifications

Specification Value

Input voltage range 100–240 VAC or –48 VDC (–38.4 VDC to –57.6 VDC)

Input frequency range 50/60 Hz (AC)

Input current 1.4 amps @ 100 VAC or 3.75 amps @ –38.4 VDC

See Table B-4 for the PacketWave E510A/E520A regulatory compliance.

Table B-4. Regulatory Specifications

Specification Value

Safety UL/cUL 60950, EN 60950 (TUV), EN 60825-1 and EN 60825-2

Electromagnetic Compatibility FCC Part 15 Class A, EN 55022 Class B, VCCI Class B, EN 300 386 (other than Telecommunications Centre Applications)

See Table B-5 for the PacketWave E510A/E520A environmental characteristics.

Table B-5. Environmental Characteristics

Specification Tested Value

Temperature, operating –40°C to 70°C (–40°F to 158°F)

Temperature, storage: –40°C to 65°C (–40°F to 149°F)

Relative humidity, operating: 5% to 95% non-condensing

Relative humidity, storage: 5% to 95% non-condensing

Operating altitude: from 60 meters (197 feet) below sea level to 4000 meters (13,123 feet) above sea level

61440520E1-5B B-3 PacketWave E510A/E520A Installation and Configuration Guide

E510A/E520A HARDWARE SPECIFICATIONS Refer to Figure B-1 and Figure B-2 for a graphical representation of the PacketWave E510A and E520A.

Figure B-1. PacketWave E510A Front View

Figure B-2. PacketWave E520A Front View

There are two modular interface expansion slots. Figure B-1 shows the single port Gigabit Ethernet SFP in the high-speed module expansion slot and a 24-port T1/21-port E1 in the low-speed module expansion slot.

LEDs The front of the PacketWave E510A/E520A has the following LEDs: • FAULT: SLOT 1, SLOT 2 and SLOT 3 - Red (SLOT 1 is the base unit; SLOT 2 is for the high-speed module; SLOT 3 is for the low-speed module) • ALARM: CRITICAL - Red; MAJOR - Red; and MINOR - Yellow • PWR A - Green • PWR B - Green • eight 10/100 ACT (activity) LEDs- Yellow • eight 10/100 LNK (link) LEDs - Green • EAST, TX and RX - Green • WEST, TX and RX - Green

B-4 61440520E1-5B Appendix B, Physical Chassis Specifications - E510A/E520A Hardware Specifications

NOTE If a FAULT LED remains on or periodically blinks, the PacketWave E510A/E520A has an internal hardware failure. Please contact ADTRAN Technical Support using the information provided in this guide.

T1/E1 LED Behavior On the PacketWave E510A/E520A 8-port T1/E1 module, there is a single LED for each T1/E1 port. The following describes the behavior of these LEDs: • If there is no alarm condition, the LED illuminates green to indicate synchronization activity (SYNC). • If there is an alarm condition and alarms are turned on, the LED illuminates red to indicate a FAULT has been detected on that port. • If there is an alarm condition and alarms are turned off, the LED is off.

RPR I/O There are two identical paths for data for the East and West rings on the PacketWave E510A/ E520A. The E510A has a dual 1 Gbps RPT ring. The E520A has a dual 1–2.5 Gbps RPT ring. Small Form-factor Pluggable (SFP) optics are used in the RPT interface.

NOTE Distances are indicative only.

CAUTION Always use an optical power meter to ensure your receive power is within the tolerance. For more information on optical power values, refer to “Appendix C, Optical Power Budget”.

61440520E1-5B B-5 PacketWave E510A/E520A Installation and Configuration Guide

This page is intentionally blank.

B-6 61440520E1-5B Appendix C Optical Power Budget

This appendix describes the optical power budget for the PacketWave family of products. It contains the following sections: • “Optical Fiber Types” on page C-2 • “Optical Fiber Links and Optical Fiber Assemblies Requirements” on page C-2 • “Industry Standard Requirements for the Fiber Plant” on page C-3 • “Fiber Optic Plant Characterization Procedures” on page C-7 • “Distance Limitations” on page C-10 • “Power Budget” on page C-11 • “Approximating the Power Margin” on page C-12 • “Additional Power Budget and Attenuation References” on page C-13

61440520E1-5B C-1 PacketWave E510A/E520A Installation and Configuration Guide

OPTICAL FIBER TYPES The specification for optical-fiber transmission defines two types of fiber: single-mode and multimode. Modes can be thought of as bundles of light rays entering the fiber at a particular angle. Single-mode fiber allows only one mode of light to propagate through the fiber, while multimode fiber allows multiple modes of light to propagate through the fiber.

OPTICAL FIBER LINKS AND OPTICAL FIBER ASSEMBLIES REQUIREMENTS Quality characteristics of the optical fiber as well as the optical fiber assemblies (such as jumpers, connectors, and patch panels), become more critical with longer fiber spans and higher signal bandwidth. Optical power generated by Optical Transmitter (TX) will be partially lost during the propagation through the fiber due to the scattering within the fiber optic material. At the same time, if a received signal is too high it might temporarily blind or even destroy an Optical Receiver (RX). For more information, refer to “Power Budget” on page C-11. The loss characteristics of optical fiber can be the most critical factor that determines the distance that an optical signal can propagate. At the same time, chromatic and polarization mode dispersion spread the optical pulse out, which results in increased bit errors. The dispersion effects can be compensated for with the insertion of Dispersion Compensation Modules (DCMs). Unfortunately, the negative effects of optical power loss and dispersion are not the only concerns for long distance optical transmissions. Thus inherent back-reflections of power in fiber can disturb TXs. Components such as optical connectors can greatly contribute to this cumulative effect. Individual optical components can be located and measured with the use of Optical Time Domain Reflectometer (OTDR). Total returned power can be can be measured with the use of Optical Return Loss (ORL) Meter. The equipment allows identification of poor connector mating, dirty connectors, micro-bends, and poor splices so that they can be repaired prior to an installation. For these reasons, it is highly recommended that the measured characteristics on the fiber plant be evaluated against a strict set of specifications such as Telcordia and Electronic Industries Association/Telecommunications Industry Association (EIA/TIA) Standards before installing new equipment into a network. The specifications are designed to ensure optimum, reliable network operation when using high-performance equipment. In summary, it is recommended that the following parameters for the fiber plane are tested and characterized: • Splice/connector loss and reflection • Optical Attenuation • Optical Return Loss (ORL) • Chromatic Dispersion (CD) • Polarization Mode Dispersion (PMD) • C and L Band attenuation profile Usually, in addition to performing the measurements mentioned, fault location and corrective actions are performed in order to bring non-compliant fiber components up to the industry

C-2 61440520E1-5B Appendix C, Optical Power Budget - Industry Standard Requirements for the Fiber Plant standards. Also a comprehensive report detailing how a customer’s network measures up to these standards is produced, and recommendations for improvements and optimization, if required, are made. A number of vendors offer Fiber Characterization Services to assist a service provider prior to the optical network implementation.

INDUSTRY STANDARD REQUIREMENTS FOR THE FIBER PLANT

Splice/Connector Loss and Reflection The Optical Time Domain Reflectometer (OTDR) provides a trace that plots signal level versus distance, displaying information such as connector and splice loss and reflectance levels, and any other discontinuities that can occur along the length of fiber. Excessive bends in the fiber, poor splices, as well as dirty, defective, or even unexpected connectors can be easily identified through the OTDR traces. At the same time, the OTDR traces will give an accurate measurement of the fiber length and possible cable cuts (refer to Figure C-1 and Figure C-2). In cases where there is concern for environmental consequences (such as vibrations from railroad installations or large temperature changes during the day), OTDR testing on critical fibers should be performed over a long period of time (for example, 24 hours) to account for the variations.

Figure C-1. Example of Satisfactory Fiber1

1. All parameters are within the required standards measured with EXFO FTB-7000B/FTB-70000C OTDR Module Series,

61440520E1-5B C-3 PacketWave E510A/E520A Installation and Configuration Guide

Figure C-2. Example of Non-Satisfactory Fiber1

Items that are not within specifications can adversely affect the performance of the network. Also, the problems will interfere with other fiber plant characterization tests. These issues need to be corrected before the Power budget (or Attenuation), Optical Reflection Loss (ORL), Chromatic Dispersion (CD), or Polarization Mode Dispersion (PMD) tests can be run. (Dispersion measurements are more critical for DWDM networks.) Therefore, the OTDR test is the most critical test and has to be done before any of the other tests. All events detected by OTDR for the particular fiber span are often stored at the corresponding node in the “event table” file for easy reference.

Fiber Optic Plant Standard Requirements

Bellcore GR-1312-Core Section 5. General Criteria. Physical Design Criteria Section 5.2.3. Optical Connectors • R5-54 [143] Any single-mode optical connector shall meet the criteria in GR-326-CORE. • R5-55 [144] Built-in connector receptacles shall comply with the requirements in GR-326-CORE

1. Slightly high connector reflection at point (4) and high splice loss at point (5) measured with EXFO FTB-7000B/FTB-70000C OTDR Module Series.

C-4 61440520E1-5B Appendix C, Optical Power Budget - Industry Standard Requirements for the Fiber Plant

Section 7. Performance Criteria All parameters are assumed to be worst-case and end-of-life values. They are valid under all operational conditions for the lifetime of the system. Section 7.9. Reflection Criteria Section 7.9.3. Discrete Reflection • R7-79 [361] The discrete reflectance seen from any Optical Networking Element (ONE) optical port shall be less than –27dB. • O7-80 [362] The discrete reflectance seen from any ONE optical port should be less than –40dB. Rationale: This requirement is necessary to minimize multiple reflection noise (MRN) effects that degrade system performance.

Bellcore GR-1312-Core Generic requirements for Single-mode Optical Connectors and Jumper Assemblies Connector Loss Requirements Requirement for the connector loss • Maximum loss seen in a connector population: 0.5 dB. • Mean loss seen in a connector population: 0.3 dB. Objective for the connector loss • Maximum loss seen in a connector population: 0.3 dB. • Mean loss seen in a connector population: 0.2 dB. Connector Reflectance1 Requirements Requirement for the reflectance seen at a connector • Maximum reflectance seen at a connector: –40 dB. Conditional Requirement for the reflectance seen at a connector • Maximum reflectance seen at a connector: –55 dB (analog video applications) Conditional Objective the reflectance seen at a connector • Maximum reflectance seen at a connector: –60 dB (analog video applications)

EIA/TIA 568 B.3 Standards EIA/TIA 568 B.3 (Electronic Industries Association and Telecommunications Industry Associ- ation) standards

1. Optical reflectance definition: The ratio of the reflected power, Prefl, to the incident power, Pin, at an optical interface or from a component, which can be expressed as a ratio or in dB:

R (ratio) = Prefl/Pin or

R (dB) = 10 log10 (Prefl/Pin) NOTE: The last term will be in negative dBs, in the absence of gain in the reflection path.

61440520E1-5B C-5 PacketWave E510A/E520A Installation and Configuration Guide

Optical Fiber Splice Requirements Requirement for the fiber splice attenuation • Optical fiber splices, fusion or mechanical, shall not exceed a maximum attenuation of 0.3 dB.

NOTE The EXFO Help Line strongly recommends “0.2 dB splice quality criteria” and they are aware that this is what most of the reliable optical networking equipment vendors are requesting from their customers. EXFO (a recognized test and measurement expert in the global telecommunications industry) knows that EIA/TIA 568 B3 standard has 0.3 dB max requirement; however, as a splice is usually located outside of the Central Office in non-controlled environment with substantial temperature variations, the splice loss value might change substantially. In some cases over 100% loss versus temperature variations is observed due to the air gap or “bubble” inside of the splice.

Requirement for the fiber splice Optical Return Loss1 (ORL) • Optical fiber splices for multimode fiber, fusion or mechanical, shall have a minimum ORL of 20 dB. • Optical fiber splices for single-mode fiber, fusion or mechanical, shall have a minimum ORL of 26 dB for general applications. • Optical fiber splices for single-mode fiber, fusion or mechanical, shall have a minimum ORL of 55 dB for broadband analog video (CATV) applications.

1. Optical Return Loss (ORL) Definition: The ratio of the reflected power, Prefl, to the incident power, Pin, from a fiber optic system, which can be expressed as a ratio: ORL = –10 log10(Prefl/Pin) NOTE: This will be in positive dBs, in the absence of gain in the reflection path.

C-6 61440520E1-5B Appendix C, Optical Power Budget - Fiber Optic Plant Characterization Procedures

FIBER OPTIC PLANT CHARACTERIZATION PROCEDURES Optical Attenuation Attenuation or fiber loss over a fiber span becomes more critical as customers increasingly push the limits of un-amplified distance between ONEs (Optical Network Elements). If power levels drop too low, optical equipment cannot process the input signals causing network degradation. It they are too high, attenuators may be needed to prevent receiver damage. Optical attenuation is measured with a light source placed at one end of the fiber span and a power meter at the other end to measure how much of the source power reached the far end. The optical power loss of the fiber span is measured between end points. This test should be performed in both directions. The results should be evaluated against the following requirements: Attenuation for the fiber: • TIA/EIA-455-61 0.25 dB/km at 1550 nm • EIA/TIA-455-78 0.25 dB/km at 1660 nm Also one should add 0.5 dB for each connector in the span.

Optical Return Loss (ORL) As a signal travels down an optical fiber, a proportion of its power is reflected back towards the source of transmission. The power that is reflected is primary due to changes in the index of refraction. Optical Fiber Plant components such as connectors, mechanical splices, attenuators, patch-cords, and fiber/air terminations all can create a change in index of refraction and contribute to poor system ORL. Even fiber optics cable itself creates backscatter as light propagates through it. The amount of reflected power due to the backscatter can not be elimi- nated, although its magnitude is smaller than the reflected power from discrete reflections. A discrete reflection is the ratio of reflected power to incident power from a single component:

Rdiscrete= Pdiscrete refl/Pdiscrete in ORL is the sum of the reflectance of each discrete component in the system and fiber backscatter at the system interface (transmitter and receiver). High system ORL can cause data corruption and increased noise at the transmitter by providing unwanted feedback to the laser cavity. This unwanted feedback can affect the Relative Intensity Noise (RIN)1, laser line width, and optical frequency variation of the laser leading to laser instability. The end result is an increase in bit error rates due to reflections. It is due to the following: • the statistical nature of the carrier-recombination and the photon-generation process within the laser source gain medium (RINlaser)

• the conversion of laser phase noise into intensity noise from multiple reflections (RINrefl)

1. Relative Intensity Noise (RIN) Definition: RIN is the intrinsic fluctuations in signal intensity: RIN= ΔI2/I2, where RIN is relative intensity noise, ΔI2 is the mean-square intensity fluctuation of the signal, and I is the average signal light intensity.

61440520E1-5B C-7 PacketWave E510A/E520A Installation and Configuration Guide

To measure ORL of a fiber span, an Optical Continuous Wave Reflectometer (OCWR) is used. The OCWR is the instrument designed to specifically measure the entire system and component ORL reflectance. The OCWR launches a stable, continuous wave signal into the optical fiber and measures the strength of the time-integrated return signal. As an example, EXFO’s BRT-320A optical loss test set can measure the system’s ORL and give an accurate reading in dB of the power returned to the source by the network. The results should be evaluated against the following requirements: IEEE 802.3: maximum ORL >= 26 dB for single mode fiber. Telcordia GR-765-CORE/GR-1312-CORE recommends ORL >= 40 dB for single mode fiber.

NOTE The Telcordia objective of –40 dB assumes that all system components are newly installed products that conform to the latest Tel- cordia requirements. Testing has shown that ORL can normally be expected in the –30 dB to –35 dB range, so technicians are urged to initiate corrective action (inspection and cleaning of connectors) when ORL becomes worse than –30 dB. Suspected components can be isolated by careful analysis of the OTDR event table.

At the same time, sticking to the strict Telcordia’s criteria provides the equipment with a wider window of tolerance to any future condition that may introduce more reflection into the system, thus avoiding possible degradations or outages.

Chromatic Dispersion (CD) Chromatic dispersion (CD) results from a difference in the index of refraction experienced by different wavelengths, causing them to have different propagation delays along a length of fiber. CD arises from the fact that a laser TX does not put out exactly one “color” of light. The spectral width of a laser may be a few nanometer to a tenth of nanometer. This type of dispersion can impair high-capacity transport systems through pulse spreading that may cause Inter-Symbol Interference (ISI), hence reducing overall performance through higher error bit rates. Chromatic dispersion (CD) of a given fiber is described in picoseconds of delay per nanometer of spectral width of the source per kilometer (ps/nm-km). CD measurements allow the fiber type to be identified so that the appropriate Dispersion Compensation Modules (DCMs) can be introduced into the system design to reverse this effect. The current CD measurement procedure is based on sending pulses from multiple wavelengths (1310 nm, 1480 nm, 150 nm, and 1650 nm.) Based on the reflection principle, pulse spreading of round-trip returning pulses determines chromatic dispersion across the length of the fiber. The results should be evaluated against the following requirements: Chromatic Dispersion: TIA/EIA-455-175 0.1 to 6.0 ps/nm-km @ 1530 to 1565 nm (C-band) 4.0 to 8.6 ps/nm-km @ 1565 to 1620 nm (L-band)

C-8 61440520E1-5B Appendix C, Optical Power Budget - Fiber Optic Plant Characterization Procedures

Polarization Mode Dispersion (PMD) Polarization Mode Dispersion (PMD) is a fundamental property of Single Mode Fiber (SMF) and components. It is a result of different polarization states of an optical signal traveling at slightly different speeds in the fiber. High PMD usually comes from irregular fiber core geometry, which was rather common in older fiber manufactured with older technologies. Also it might come from physical stresses in the cable that range from stretching and bending during improper installation to the less obvious effects brought by vibration and temperature changes. PMD results in optical signal pulses spreading out in time, increasing the bit error rate. Some types of fiber (such as aerial and submarine cables) are more prone to this phenomenon. The adverse effect of high PMD on the transmission over long distances includes increased power penalty of the link budget.

NOTE With respect to pulse spreading, the effects of PMD are similar to those of CD. The important difference is that the CD is relatively stable, predictable phenomenon. The total CD of the optical fiber plant can be calculated and compensated by DCMs. In contrast, PMD of an SMF at any given wavelength is not stable or predictable. This is forcing system designers to make statistical predic- tions of the effects of PMD.

The PMD measurement procedure is based on measuring mean differential Group Delay (DGD) and the PMD coefficient in the 1550 nm window using equipment that is based on the interferometric method. A broadband LED polarized light source in 150 nm window is connected to one end of the tested fiber. For example, EXPO’s FLS-110P or M2100P light sources can be used as a test signal and the FTB-5500 PMD Analyzer module can be used as a receiver. The PMD analyzer module is used at the RX connected with patch cords of several meter in length. The test needs to be performed only in one direction. Given the statistical nature of the measurement, it is recommended that at least two different PMD measurements be performed for each fiber section. In cases where there is concern for environmental consequences (such as vibrations from railroad installations, large temperature changes during the day, and aerial installations), PMD testing on critical fibers should be performed over a long period of time (24 hours, for example) to account for the variations. The results should be evaluated against the following requirements: Polarization Mode Dispersion Coefficient:

TIA/EIA-455-113 1st order coefficient: 0.5 ps/km½ @ 1550 nm TIA/EIA-455-122/124 2nd order coefficient: 0.2 ps/km½ @ 1550 nm Since PMD affects the bandwidth capacity of the fiber (smaller pulse width will tolerate less spreading), it is recommended that the specifications in Table C-1 be met.

61440520E1-5B C-9 PacketWave E510A/E520A Installation and Configuration Guide

Table C-1. PMD Specifications

Bit Rate (Gb/s) Max PMD (ps) PMD Coefficient (ps/km½)

2.5 40 <2.0

10 10 (no FEC) <0.5

40 2.5 <0.125

C and L Band Attenuation Profile When the distance between ONEs in an optical system exceeds certain limits, the use of optical amplifiers becomes necessary. The amplifiers have to be adjusted in the way that all frequencies are retransmitted at the same power level. Due to the inherent variation in signal loss among frequencies in the optical spectrum, as well as different loss profiles among different fiber types, power levels across the frequency range must be measured by sending a broadband light source through the fiber and measuring received signal with an Optical Spectrum Analyzer.

DISTANCE LIMITATIONS Multiple modes of light propagating through the fiber travel different distances depending on the entry angles, which causes them to arrive at the destination at different times (a phenomenon called modal dispersion); therefore, single-mode fiber is capable of higher bandwidth and greater cable run distances than multimode fiber. Table C-2 shows an example of optical characteristics for an intermediate reach, single-mode fiber transceiver.

Table C-2. Example of Optical Characteristics for an Intermediate Reach, Single-Mode Fiber Transceiver

Specification Value

Transceiver Type Single-Mode (1)

Power Budget 8 dB

Transmit Power –11 dBm to –3 dBm (0.08 to 0.5 mW), at 1270–1355 nm

Receive Power –19 dBm

Maximum Distance Between Stations (2) Up to 9 miles (16 kilometers)

1. Complies with IEEE 802.3z Gigabit Ethernet PMD 1000Base-LX Specification. 2. Gives typical results. You should use the power budget calculations to determine the actual distances.

NOTE If the distance between two connected nodes is greater than the maximum distances listed, significant signal loss can result, making transmission unreliable.

C-10 61440520E1-5B Appendix C, Optical Power Budget - Power Budget

POWER BUDGET To design an efficient optical data link, you should evaluate the power budget. The power budget is the amount of light available to overcome attenuation in the optical link and to exceed the minimum power that the receiver requires to operate within its specifications. Proper operation of an optical data link depends on modulated light reaching the receiver with enough power to be correctly demodulated. Attenuation, caused by the passive media components (cables, cable splices, and connectors), is common to both multimode and single-mode transmission. The following variables reduce the power of the signal (light) transmitted to the receiver in multimode transmission: • Chromatic dispersion (spreading of the signal in time because of the different speeds of light wavelengths) • Modal dispersion (spreading of the signal in time because of the different propagation modes in the fiber) Attenuation is significantly lower for optical fiber than for other media. For multimode transmission, chromatic and modal dispersion reduce the available power of the system by the combined dispersion penalty (dB). The power lost over the data link is the sum of the component, dispersion, and modal losses. The following table (Table C-3) lists the factors of attenuation and dispersion limits for typical optical-fiber cable.

Table C-3. Optical-Fiber Cable Factors of Attenuation and Dispersion Limits, Typical

Limits Single Mode Multimode (1)

Attenuation 0.5 dB 1.0 dB/km

Dispersion no limit 500 MHz (km) (2)

1. Multimode is included for completeness only and may or may not be part of the current product offering. 2. The product of bandwidth and distance must be less than 500 MHz (km).

61440520E1-5B C-11 PacketWave E510A/E520A Installation and Configuration Guide

APPROXIMATING THE POWER MARGIN A worst case estimate of power margin (PM) for transmissions using single-mode fiber assumes minimum transmitter power (PT), maximum link loss (LL), and minimum receiver sensitivity (PR). The worst case analysis provides a margin of error, although not all of the parts of an actual system will operate at the worst case levels. An example of the worst case optical power parameters for single-mode transmission is listed in Table C-4.

Table C-4. Optical Power Parameters for Single-Mode Transmission, Worst Case

Power Parameters Single-Mode

PT –11 dBm

PR –19 dBm

PM 8 dB

The power budget (PB) is the maximum possible amount of power transmitted. The following equation shows the calculation of the power budget for this case, worst case: • PB = PT – PR • PB = –11 – (–19) • PB = 8 dB The PM calculation is derived from the power budget minus the LL, as follows: • PM = PB – LL If the power margin is positive, as a rule, the link will work. Table C-5 lists the factors that contribute to link loss and the estimate of the link loss value attributable to those factors.

Table C-5. Contributing Factors to Link Loss and Estimated Link Loss Values

Link Loss Factor Estimate of Link Loss Value

Modal and chromatic dispersion Dependent on fiber and wavelength used

Connector 0.5 dB

Splice 0.5 dB

Fiber attenuation (approximate) 0.25 dB/km at 1550 nm single-mode fiber

After calculating the power budget minus the data link loss, the result should be greater than zero; this is the power margin. Results less than zero may have insufficient power to operate the receiver.

C-12 61440520E1-5B Appendix C, Optical Power Budget - Additional Power Budget and Attenuation References

Power Margin Example The following is an example of a PM calculation based on the following variables: • Length of link with single-mode fiber = 10 kilometers (km), with a loss of 0.25 dB per km • 2 connectors, each with a loss of 0.5 dB • 3 splices, each with a loss of 0.5 dB Estimate the power margin as follows: • PM = PB – LL • PM = 8.0 dB – 10 km (0.25 dB/km) – 2 (0.5 dB) – 3 (0.5 dB) • PM = 8.0 dB – 2.5 dB – 1.0 dB – 1.5 dB • PM = 3.0 dB The positive value 3.0 dB indicates that this link would have sufficient power for the transmission.

Using Statistics to Estimate the Power Budget Statistical models more accurately determine the power budget than the worst case method. Determining the link loss with statistical methods requires accurate knowledge of variations in the data link components. Statistical power budget analysis is beyond the scope of this document. For further information, refer to ITU-T standards and your equipment specifications.

ADDITIONAL POWER BUDGET AND ATTENUATION REFERENCES The following publication contains information on determining attenuation and power budget: • T1E1.2/92-020R2 ANSI, the Draft American National Standard for Telecommunications entitled “Broadband ISDN Customer Installation Interfaces: Physical Layer Specification.”

61440520E1-5B C-13 PacketWave E510A/E520A Installation and Configuration Guide

This page is intentionally blank.

C-14 61440520E1-5B Appendix D Connectors and Cabling

This appendix provides information on cabling various connections to the PacketWave E510A/E520A. It contains the following sections: • “RS-232 Interface Port Connector” on page D-2 • “MGMT Port (NMS Port)” on page D-2 • “10/100Base-T Connections” on page D-3 • “Fiber-Optic Cables” on page D-7 • “T1/E1 Patch Panel” on page D-8

61440520E1-5B D-1 PacketWave E510A/E520A Installation and Configuration Guide

CONNECTORS

RS-232 Interface Port Connector The PacketWave E510A/E520A provides a DB-9 connector on the front panel that supplies an RS-232 interface for connection to a controlling terminal. The pinout of the DB-9 is illustrated in Figure D-1. Use an appropriate cable to connect to the controlling terminal.

Pin 5 - Signal Ground (SGN) Pin 3 - Receive Data (RXD) Pin 2 - Transmit Data (TXD)

Figure D-1. RS-232 (DB-9) Pin Assignments

MGMT Port (NMS Port) The MGMT port (an RJ-45 connector) on thePacketWave E510A/E520A, as shown in Figure D-2, is used for network management system (NMS) functions with standard 10/100 connections. The cable and connector for the MGMT port is shown in Figure D-3.

NOTE Since the MGMT port is configured and operates as MDI, it does not function as a standard 10/100 connection with non-MDI-X devices.

Figure D-2. MGMT Port Connector

The MGMT port is provided to allow connectivity to the ADTRAN LMS via an Ethernet network for NMS sessions. The MGMT port also allows telnet connectivity to the node for debugging purposes. If properly configured with an IP address, the MGMT port interface will automatically connect to the ADTRAN LMS.

D-2 61440520E1-5B Appendix D, Connectors and Cabling - Connectors

Figure D-3. RJ-45 Connector, Cable, and Pinouts

10/100Base-T Connections An RJ-45 connector, as shown in Figure D-4, is used for the 10/100Base-T connections. The 10/100Base-T ports are MDI-X.

Figure D-4. RJ-45 Connector, Cable, and Pinouts

STP (shielded twisted pair) cables for Ethernet are not required. If STP cables are used, they can be grounded on both ends if both the PacketWave system frame and the Ethernet cable frame are grounded to the same earth connection. ADTRAN recommends UTP CAT 5 cables. Table D-1 shows the 10/100Base-T RJ-45 pinouts.

61440520E1-5B D-3 PacketWave E510A/E520A Installation and Configuration Guide

WARNING For releases prior to 7.2, ADTRAN recommends using STP cables for the 10/100Base-T interface in order to maintain European EMC compliance.

Table D-1. 10/100Base-T Ethernet Ports, RJ-45 Pinouts (MDI-X)

Pin Number Signal on 10/100 Connector

1 RX+

2 RX-

3 TX+

4 Internally terminated

5 Internally terminated

6 TX-

7 Internally terminated

8 Internally terminated

NOTE In releases prior to R7.2, automatic MDI/MDI-X may be randomly enabled or disabled on the 10/100Base-T ports. This can cause link problems with auto-negotiation disabled. This can also allow the incorrect cable to work. Automatic MDI/MDI-X is explicitly disabled in release 7.2 and only the correct cable will work. Verify that you have the correct Ethernet cable.

D-4 61440520E1-5B Appendix D, Connectors and Cabling - Connectors

10/100Base-T, Straight-Through Cabling Use the following diagram in Figure D-5 to set up the straight-through cabling connections from the PacketWave E510A/E520A 10/100Base-T connectors to the MDI device.

Figure D-5. 10/100Base-T Straight-Through Pinouts

Table D-2 shows the 10/100Base-T straight-through cable pins and signals.

Table D-2. 10/100Base-T Straight-Through Cable Pin Assignments

Customer Device 10/100Base-T Pin Number Pin Number Connector Signal Connector Signal

1 TX+ 1 RX+

2 TX- 2 RX-

3 RX+ 3 TX+

4 - 4 -

5 - 5 -

6 RX- 6 TX-

7 - 7 -

8 - 8 -

61440520E1-5B D-5 PacketWave E510A/E520A Installation and Configuration Guide

10/100Base-T, Crossover Cabling Use the following diagram in Figure D-6 to set up the crossover cabling connections from the PacketWave E510A/E520A 10/100 to the MDI-X.

Figure D-6. 10/100Base-T Crossover Cable

Table D-3 shows the 10/100Base-T crossover cable pins and signals.

Table D-3. 10/100Base-T Crossover Cable

Pin Number Customer Device Pin Number 10/100Base-T Connector Signal Connector Signal

1 RX+ 3 TX+

2 RX- 6 TX-

3 TX+ 1 RX+

6 TX- 2 RX-

5 - 5 -

7 - 7 -

8 - 8 -

D-6 61440520E1-5B Appendix D, Connectors and Cabling - Fiber-Optic Cables

FIBER-OPTIC CABLES Single-mode optical-fiber cables for PacketWave E510A/E520A are not available from ADTRAN, but are available from commercial cable vendors. Cables can be obtained from the following cable vendors: • AT&T •Siemens •Red-Hawk •Anixter •AMP For single-mode or multimode optical-fiber connections, use one duplex LC-type cable (Figure D-7) or two simplex LC-type cables (Figure D-8). The PacketWave E510A/E520A uses LC connectors and cables.

Figure D-7. Multi-Mode Duplex LC Cable

Figure D-8. Single-Mode Simplex LC Cable

61440520E1-5B D-7 PacketWave E510A/E520A Installation and Configuration Guide

T1/E1 PATCH PANEL The T1/E1 low-speed module has a parallel cable connector on its front panel and requires the use of a patch panel to provide RJ-45 for T1/E1 balanced or DIN 1.6/5.6 75 ohm for E1 unbalanced port connectors.

24xT1/21xE1 Module SCSI-II Connector Pin Assignments Table D-4 shows the SCSI-II connector pin assignments for the 24xT1/21xE1 module.

Table D-4. SCSI-II Connector Pin Assignments

Port SCSI-II Port SCSI-II

1 1 Tx Tx 26 26 1 13 2 2 Rx Rx 27 27

3 3 Tx Tx 28 28 2 14 4 4 Rx Rx 29 29

5 5 Tx Tx 30 30 3 15 6 6 Rx Rx 31 31

7 7 Tx Tx 32 32 4 16 8 8 Rx Rx 33 33

9 9 Tx Tx 34 34 5 17 10 10 Rx Rx 35 35

11 11 Tx Tx 36 36 6 18 12 12 Rx Rx 37 37

D-8 61440520E1-5B Appendix D, Connectors and Cabling - T1/E1 Patch Panel

Table D-4. SCSI-II Connector Pin Assignments (Continued)

Port SCSI-II Port SCSI-II

13 13 Tx Tx 38 38 7 19 14 14 Rx Rx 39 39

15 15 Tx Tx 40 40 8 20 16 16 Rx Rx 41 41

17 17 Tx Tx 42 42 9 21 18 18 Rx Rx 43 43

19 19 Tx Tx 44 44 10 22* 20 20 Rx Rx 45 45

21 21 Tx Tx 46 46 11 23* 22 22 Rx Rx 47 47

23 23 Tx Tx 48 48 12 24* 24 24 Rx Rx 49 49

N/C 25 N/C 25

N/C 50 N/C 50

* No Connection (N/C) when the module is configured as a 21-port E1.

61440520E1-5B D-9 PacketWave E510A/E520A Installation and Configuration Guide

This page is intentionally blank.

D-10 61440520E1-5B Appendix E Security

This appendix provides information on third-party security features of the PacketWave platform. It contains the following: • “IPFW howto Document V.0.2” on page E-2 • “Licenses” on page E-18

61440520E1-5B E-1 PacketWave E510A/E520A Installation and Configuration Guide

IPFW HOWTO DOCUMENT V.0.2 The following information on IPFW (a FreeBSD™ IP packet filter and traffic accounting facility) is from an online article by Walter M. Shandruk ([email protected]), and has been repro- duced here with the author’s permission. The complete article (accessed for this usage March 27, 2007) may be found at http://www.freebsd-howto.com/HOWTO/Ipfw-HOWTO.

Basic IPFW(8) Rule Syntax The rule syntax for IPFW(8) is pretty simple. Any rule can be enabled from the console with the IPFW(8) command. Before we delve into the rule syntax, however, we will quickly overview how to list the ipfirewall(4) rules that have been activated.

Listing Rules In its simplest form, we can list the rules with: ipfw list This will list all of the rules ordered by their rule number. To also list the timestamp of the last moment a packet was matched on a specific rule, use the following command: ipfw -t list Finally, if we wish to list the packet count for matched rules along with the rules themselves, issue the following: ipfw -a list or ipfw show Both commands will display the same information in the same way. The first column is the rule number, followed by the number of outgoing matched packets, followed by the number of incoming matched packets, and finally followed by the rule itself.

Basic Commands and Actions We will now gradually go through the various options available for the construction of a stateless filtering ruleset. In our examples we will only state the rule not including the firewall control utility (/sbin/ipfw) which must precede each one if we're manually setting these rules from the command prompt; otherwise, if we're construction a rule file to be passed to IPFW(8) we can use the sample lines as-is. add 1000 allow all from any to any This is the most benign example of a rule.

NOTE The pass parameter used in that rule, as written in rc.firewall, is a synonym for allow and permit — they are interchangeable. In this rule, all packets from any source to any destination are allowed to pass.

E-2 61440520E1-5B Appendix E, Security - IPFW howto Document V.0.2

With ipfirewall(4), under most circumstances, the moment a rule matches a particular packet, then ruleset examination halts there. As we see, the simplest syntax for IPFW(4) is as follows: [] from to The important commands are add and delete. They are self-explanatory. Rule numbers start count at 0 and end at 65535. The last rule number is always defined by the default firewall policy in the kernel. Even if you have an open policy defined in rc.conf, the last rule will always reflect the kernel policy. This is fine because ruleset search halts at the first matching rule (usually), so if the penultimate (second to last) rule is number 65000 and defined by rc.firewall to allow all packets, all packets will be allowed by default even if the last rule (65535) defines a closed kernel firewall policy, because the last rule will never be reached. An “action” can be one of a number of things: • allow | pass | permit - Any packets matching a rule with this action are allowed to pass through the firewall, and search of ruleset terminates. • deny | drop - Any packets matching a rule with this action are silently blocked by the firewall and search of ruleset terminates. add 1100 deny all from any to any This would deny all packets from anywhere to anywhere. • reset - Any packets matching a rule with this action are blocked and the ipfirewall(4) attempts to send a TCP reset (RST) notice to the source. The ruleset search is terminated. Naturally, because this only applies for TCP packets, the protocol must be tcp, which matches only TCP packets, and not all, which matches all IP packets. This action is sometimes useful for fooling network scanners that would otherwise be able to detect a service behind a filtered port. On the other hand, it can become a liability if one is flooded at a particular IP and port for which ipfirewall(4) is set to reply with a RST packet, thus doubling the usage of your bandwidth. add 1200 reset tcp from any to any This would deny all TCP packets from any to anywhere, and send a TCP RST response packet to the source for each. • count - Any packets matching a rule with this action will prompt ipfirewall(4) to increment its packet counter. Search through the ruleset continues. add 1300 count all from any to any This would increment the packet counter for this rule, which matches all packets coming from anywhere and going anywhere. • skipto - Any packets matching a rule with this action will prompt ipfirewall(4) to continue its search through the ruleset starting with the rule number equal to or greater than that which is indicated by. add 1400 skipto 1800 all from any to any This would skip ruleset search to rule 1800 for any packets that matched this rule in the first place.

61440520E1-5B E-3 PacketWave E510A/E520A Installation and Configuration Guide

Specifying Protocols The proto is the protocol that is desired to be matched. The keywords ip or all are catch-alls that match all protocols. The commonly matched packet protocols are ICMP, UDP, and TCP, although, that is by no means an exhaustive list. For the complete list of possible protocols one can match, more /etc/protocols.

Specifying the Source and Destination Addresses

NOTE PacketWave only supports IP addresses, not hostnames.

The source and destination both take on the same format. They can be a name, as defined in /etc/hosts or through DNS, an IP address, a network address with bitmask (or netmask), and can be optionally followed by one or more ports numbers if the protocol is UDP or TCP. Using names or IPs is straightforward, for instance: add 1000 allow all from myhost to hishost add 1100 deny all from 10.0.0.5 to any The first rule will allow all traffic from myhost to hishost, and the second rule will deny all traffic from 10.0.0.5 to any host. Once a packet matches one of these, ruleset examination for that packet ceases, and it is either passed or dropped, according to the action specified in the rule it matched. This is a simple example of host-based filtering; that is, of filtering according to which hosts a packet is destined for, or arriving from. Network-based filtering works similarly, and the network notation there utilizes either bitmasks or netmasks, for instance: add 2000 allow all from 192.168.0.0/16 to any add 2100 deny all from any to 10.0.0.0:255.0.0.0 The first rule allows all traffic from the network whose IP range is 192.168.0.0 to 192.168.255.255. It uses a bitmask to indicate this. A bitmask specifies how many bits from the network address (192.168.0.0) should remain the same for matching packets. In this instance, the first 16 bits out of the 32-bit address will remain the same, and as the first 16 bits happen to be the first two octets—192.168—all addresses whose source addresses have the first two octets as 192.168 will be matched by this rule. The second rule accomplishes a similar thing using netmasks. The netmask indicate how many bits from the indicated network address should be used for rule matching. In the above example, for rule two, the netmask is 255.0.0.0. Its first octet is set with high bits; in other words, the first eight bits are set high. This indicates to IPFW(8) that only packets with the first eight bits of the network address (10.0.0.0) should be matched. As the first eight bits of the network address equal 10, then all packets whose destination address have a 10 for the first octet (all addresses between 10.0.0.0 and 10.255.255.255) will be matched by this rule, and then dropped, as indicated by the action. Rule matches can also be inverted with the not keyword. For instance, in the following IPFW(8) commands, all packets not from 192.168.0.3 are dropped: add 1000 deny all from not 192.168.0.3

E-4 61440520E1-5B Appendix E, Security - IPFW howto Document V.0.2

Introduction to Bitmasks and Netmasks The principle behind bitmasks and netmasks is simple but often confusing to new users as it requires knowledge of binary numbers. It makes far more sense if one worked with IP addresses in their binary form, however, the confounding of decimal and binary concepts easily throws newcomers off. For a quick reference, the following table illustrates what network ranges are indicated by the corresponding bitmasks/netmasks up to a default class C netmask and a couple of quick examples of additional bitmask/netmask entries for larger networks: Bitmask Netmask Total IPs / Usable IPs 32 255.255.255.255 1 1 31 255.255.255.254 2 1 30 255.255.255.252 4 2 29 255.255.255.248 8 6 28 255.255.255.240 16 14 27 255.255.255.224 32 30 26 255.255.255.192 64 62 25 255.255.255.128 128 126 24 255.255.255.0 256 254 ... 22 255.255.192.0 16320 16318 20 255.255.128.0 32768 32766 16 255.255.0.0 65536 65534 12 255.128.0.0 8.388608+e6 8.388606+e6 8 255.0.0.0 256^3 (256^3)-2 0 0.0.0.0 (all IPs) 256^4 (256^4)-2 As you can see, there is a definite pattern. The number of total IPs always doubles, and the number of usable IPs is always equal to the total minus 2. This is because for every IP network/subnet there are two IPs reserved for the network and broadcast addresses. The netmask's last octet starts at 255 and constantly decreases by multiples of 2, while the bitmask decreases by multiples of 1, because in binary, each shift over to the left halves the number, not divides by ten, like in the decimal number system. This same pattern goes for all possible netmasks and bitmasks. For a quick example in using the above table/pattern, let us figure out the IP range for the subnet indicated by the following: 172.16.100.32/28 First we notice that the network address is 172.16.100.32, so we know that the subnet begins with this address. Second, we notice that the bitmask of 28 indicates that the last four bits (32–28) are set low and 28 bits set high. Because there are far less bits set low, it'll be easier to compute this using them. Because each bit has two possible values, 2^4 indicates how many hosts are referenced by this bitmask. In this case, 16. 172.16.100.32 + 16 = 172.16.100.48, so the IP range is 172.16.100.32 – 172.16.100.48. Looking at the table, we see that 16 IPs correspond to a bitmask of 28, so we could have used that to add to our network address and avoided the other math, but it's much better to know how to do it all on your own—learn once and use always.

Specifying Ports and Port Ranges One can also do port-based filtering along with host and network-based filtering. Ports can be simply specified following the address of either a source of destination. Port ranges can be specified with a dash, be comma-separated, or use a bitmask to specify a range. Most impor-

61440520E1-5B E-5 PacketWave E510A/E520A Installation and Configuration Guide tantly, one can not use the all protocol when specifying ports because not all protocols are port-sensitive. add 1000 allow tcp from any to 172.16.0.5 25 add 1100 allow tcp from any to 172.16.0.5 1021-1023 add 1200 allow tcp from any to 172.16.0.5 21,22,23 add 1300 deny udp from any to 192.168.0.5 1024:8 In the first rule, all TCP packets that are destined for port 25 on 172.16.0.5 are matched. In the second rule, all TCP packets that are destined for ports 1021 through 1023, inclusive, on host 172.16.0.5 are matched. In the third rule, all TCP packets that are destined for ports 21, 22 or 23 on host 172.15.0.5 are matched. Finally, in the fourth rule, all UDP packets that are destined for ports 1024 through 1028 on host 172.16.0.5 are matched. The last rule can be tricky as it uses a bitmask on the port to make matches. The port 1024 contains 10 bits. The bitmask indicates that all hosts matching the last eight bits on that port, destined for host 192.168.0.5, are matched. 10–8 gives one 2 bits which can be anything. 2^2 = 4, so we have four port numbers, starting with 1024, that can be the destination ports for packets aiming for that host, and will result in a match. Bitmasks for ports are rarely used and are even trickier than bitmasks or netmasks for IP addresses, because the number of bits in a port varies depending on the port specified before the mask. As such, it is recommended that one stick to specifying port ranges with a dash (-) or separate the list of ports with commas.

Advanced IPFW(8) Rule Syntax Although the above overview of IPFW(8) rule creation will cover many of the simple scenarios, it sorely falls short for many more complex situations, such as when a system has more than one network interface, one wishes to make special responses to certain matches, or one wants more control over the direction of traffic flow. We will first expand the template for the IPFW(8) syntax to the follow: [] [log [logamount]] from to [] [] Everything in brackets comprises new functionality we will discuss in this section. We will also cover an additional “action” that was not covered earlier. The syntax may seem daunting, but we will take it slowly and add each part as we go along, so as not to overwhelm you.

“Unreach” Action First, we will introduce a new action: unreach - Any packet which matches a rule with this action will reply with an ICMP unreach code, after which time the ruleset search will terminate. The possible unreach codes can be indicated by number or name. The following is a list of ICMP unreach codes and corresponding names. If you don't know what these are used for, you won't have a reason to use them: net 0 isolated 8 host 1 net-prohib 9 protocol 2 host-prohib 10 port 3 tosnet 11 needfrag 4 toshost 12 srcfail 5 filter-prohib 13 net-unknown 6 host-precedence 14 host-unknown 7 precedence-cutoff 15

E-6 61440520E1-5B Appendix E, Security - IPFW howto Document V.0.2

Interface and Flow Control One important functionality missing from the basic description of IPFW(8) syntax was interface and flow control; that is, the ability to match packets according to which interface (if you have a multihomed system) packets are moving through, and in which direction they're moving. Up until now, direction was only loosely gauged by using the source and destination addresses, but using just them to “guesstimate” whether a packet is really coming or going when it moves through the firewall is unreliable. If you wish to match packets only coming in or going out, the keywords in and out can be used. Both correspond to the “interface-spec” area of the syntax template given earlier, and therefore, are placed near the end of every rule, prior to any possible options. For instance, if we wish to match all packets coming in from anywhere and going anywhere, we could have: add 1000 allow all from any to any in To match packets going through a particular interface, use the via option followed by the interface name. For instance, if you are using a PCI 3Com 3c59x, then your interface device will be xl0. To match all packets coming in through that interface specifically, sourced from anywhere and destined anywhere, the following would suffice: add 1100 allow all from any to any in via xl0 Or, perhaps, if one has a multihomed system and wishes to match any packets coming from anywhere and going to anywhere at least moving outside through some interface, he can do the following: add 1200 allow all from any to any out via any One will notice, when listing firewall rules, that when using either in or out in combination with via the rule as it actually looks does not contain a via but either recv or xmit, depending on whether an in or out was specified, respectively. For instance: (root@nu)~># ipfw add 7000 allow all from any to any out via xl0 (root@nu)~># ipfw list | grep 7000 07000 allow ip from any to any out xmit xl0 (root@nu)~># Indeed, one can use either recv or xmit in place of via when using in or out, however, doing so is not required, and can add to some confusion for the newcomer. In all, these options allow a lot more control over network traffic on a multihomed system and any system in general, by allowing one to filter packets specifically coming into the firewall, exiting it, and moving through a specified interface.

Matching Specific ICMP and TCP Packet Types ICMP, TCP, and IP packets come in various types. These types are defined by the various flags that each of those packets sets. We can match each of those types by using one of the following IPFW(8) options at the end of our rules.

Icmptypes icmptypes - This will match the specified ICMP packet, and conversely, if a ! (exclamation point) is put before the flag then all ICMP packets that are not of this type are matched. There are currently 15 different ICMP packet types that can be matched; each is specified by the correct number. Ranges can be specified with dashes or be comma-separated.

61440520E1-5B E-7 PacketWave E510A/E520A Installation and Configuration Guide

The 15 possible ICMP types are as follows: • 0 - Echo Reply • 3 - Destination Unreachable • 4 - Source Quench • 5 - Redirect • 8 - Echo Request • 9 - Router Advertisement • 10 - Router Solicitation • 11 - Time-to-Live Exceeded • 12 - IP header bad • 13 - Timestamp Request • 14 - Timestamp Reply • 15 - Information Request • 16 - Information Reply • 17 - Address Mask Request • 18 - Address Mask Reply If one is curious how these ICMP types (specifically type 3) correspond with the Unreach codes that can be generated with the unreach action, then simply type 3 matches any of those Unreach codes. Filtering ICMP packet types can be very useful for controlling ping; specifically, for allowing internal hosts to ping out while blocking outside hosts from pinging the gateway or any other host. The following three rules can accomplish this easily: 1000 allow icmp from any to any out icmptypes 8 1100 allow icmp from any to any in icmptypes 0 1200 deny icmp from any to any in icmptypes 8 The first rule allows all ICMP packets of type 8 (echo request) to go out. The second rule allows all ICMP packets of type 0 (echo reply) in, and the final rule blocks all ICMP packets of type 8 from entering. In short, it allows echo requests to go out and echo replies to come in, but blocks echo requests from coming in. As such, hosts behind the firewall can ping anyone on the outside, while hosts on the outside can't ping anyone behind the firewall. Naturally, this option can only be specified when the indicated protocol is icmp.

Tcpflags, Setup and Established The command tcpflags will match any TCP packet whose header contains one of the following flags, or conversely, if ! is presented before the action, match all TCP packets that do not have the set: fin - Request for connexion termination syn - Request for connexion initiation rst - Reset Connexion psh - Push Flag ack - Acknowledgement urg - Indicate Urgent OOB data

E-8 61440520E1-5B Appendix E, Security - IPFW howto Document V.0.2

The SYN flag is of most interest as it is sent for initiation of TCP concessions. Because it is so important, there is a separate IPFW(8) option dedicated specifically for matching TCP packets with the SYN flag set. This is called setup. Naturally, this option can only be specified when the indicated protocol is tcp. setup - Any rule containing this option will match any TCP packet with the SYN flag set. For instance, if we wished to deny all incoming TCP SYN packets, we could issue the following: add deny tcp from any to any in tcpflags syn or add deny tcp from any to any in setup On either count, the same action is performed: all TCP SYN packets from any destined to any will be matched, and denied. As stated above for tcpflags, this option can only be used for rules when the indicated protocol is tcp. Just as there is a special option for indicating the request for TCP connection initiation (setup), established is used for matching an already established TCP connection. Because it is of paramount importance to easily control TCP connections, established and setup are available for quick rule formation. Given these options (or their corresponding tcpflags incar- nations) we can have some simplistic control of TCP connection activity. This is the very base of stateful firewall functionality, which shall be dealt with in more detail later.

Ipoptions The command ipoptions can match for some specific IP packet flags, namely, for SSRR (Strict Source Route), LSRR (Loose Source Route), RR (Record Packet Route), and TS (Timestamp) flags. If you do not know what these IP options do, then you will not need to match for them specifically.

Logging

Logging Issues The virtues of logging are obvious. The ability to go back and see what connections had been dropped, what addresses they came from, where they were going, whether they were composed of many fragmented packets (indicative of many Denial of Service (DoS) attacks), and so on gives you a significant edge in both knowing where connections are being made, by whom, and when. Especially in the case of tracking down crackers and the like, firewall logs may give one the all-important edge. Logging also has a down-side. If you're not careful, you can both lose yourself in the abundant data (for lack of proper log analyzing strategies) and lose your hard disk space to growing log files. DoS attacks that fill up hard disks are one of the oldest attacks around, and still just as dangerous to the imprudent administrator. Although they more often strike the poorly configure e-mail server, they are just as much a threat to any system keeping extensive log data. It is important that you have sufficient hard disk space and rotate logs prudently, so the logs do not grow indefinitely. On the other hand, what many newcomers experience that once they enable ipfirewall(4) logging, their terminal is overwhelmed with messages concerning packet activity. This is the result of any combination of the following:

61440520E1-5B E-9 PacketWave E510A/E520A Installation and Configuration Guide

• logging too many often-matched rules • not disabling logging to console and root terminals (bad idea!) • not controlling logging with the IPFIREWALL_VERBOSE_LIMIT

Rule Logging Configuration Once the system is fully configured to handle the ipfirewall(4) logging, we can begin specifying which rules, when matched, should be logged. There are two simple parameters to be used in conjunction with rule formation to enable logging for the given rule; they are: The log parameter logs every time the rule containing this keyword is matched by a packet. The keyword, if present, must follow the “action.” Make sure you do not put this in wide sweeping rules such as: add 0500 allow log all from any to any Unless there is some extensive filtering occurring prior to this rule, most traffic will be matched to it and one's log files will grow very large very fast. On the other hand, it could well be safe to enable logging on a sweeping deny rule such as: add 65000 deny log all from any to any This rule is much safer because it is both near the end (rule # 65000 versus 500) and in rulesets that fulfill a closed firewall policy there are generally many rules prior to the last deny rule that allow through important traffic, which should comprise much of the total traffic experienced, except in unusual circumstances - although it can still be risky. Take careful consideration into which rules should be logged and which shouldn't. The logamount parameter, following the log parameter, specifies the maximum number of matches that a rule can experience before logging halts. This gives the administrator some extra control over logging. If, for instance, he enables 10000 matches for a given rule, and then resets the counter once a day, he can alleviate potentially large logs if someone tries to flood the server and is blocked by the given rule. After 10000 matches, the logging for that rule will stop, and the flooder's attack will not swell the log file. Alternatively, one may wish to log everything and not use this parameter. In FreeBSD 4.x, 3.4+, and 2.2.x this is allowed; however, in earlier versions of FreeBSD 3.x, if this keyword is not used, a default logamount is set to 10. When rules are logged, the following information will be saved: •Date and Time •Rule number •Action • Source and Destination IP addresses • Source and Destination Port numbers • Direction flow • Device over which this occurred For instance, a firewall log line may look like this: Jun 12 13:55:59 mybox1 /kernel: ipfw: 65000 Deny TCP 172.16.0.1:62307 192.168.0.1:23 in via xl0

E-10 61440520E1-5B Appendix E, Security - IPFW howto Document V.0.2

Introduction to Stateless and Stateful Filtering Stateful and stateless filtering are two terms often encountered in debates between propo- nents of ipfilter and ipfirewall(4). Stateless filtering treats each packet going through it as an individual that has no association with the other traffic going through the given interface. This type of filtering is easier to implement and can be used effectively to: • filter corrupt (fragmented) packets • filter particular protocol packets (ICMP, UDP, IGMP, etc) • do host-based filtering (filtering according to where a packet is destined, or where it came from) Stateful filtering is more complex to implement. It treats traffic not as an aggregate of individual, independent packets, but as composed of connections. All communication via any of the protocols uses sequence numbers to indicate in which order packets should be read on a socket(2). A stateful firewall would be aware of these sequence numbers. Connection oriented protocols such as TCP also have special packets which indicate connection initiation (SYN) and termination (FIN), and a stateful firewall would also be aware of these. In short, it would: • know what state a connection is in, and • be able to determine if a connection is following valid procedure, or is breaking the rules, and would be able to filter the packets in these connections accordingly. Stateful firewalls create dynamic rules for live connections, and clear out these rules when the connections time out. All of this allows for a more intelligent awareness of the higher level activity of network traffic by the firewall. On the downside, stateful firewalls are unable to treat each packet individually, because special dynamic rules are built to allow entire connections through, precluding the examination of packets in those rules except in the context of whether they are behaving properly in the overall connection. As such, it is wise to mix and match stateful and stateless rules in any firewall configuration, so one is able to benefit from both. Almost all of the example rules that have been given so far have been stateless. The only exceptions are the rules concerning the option tcpflags, setup, and established which allow one to check the state of a TCP connection. Indeed a combination of these will be used in the first stateful ruleset examples shortly. Using these options to make primitive stateful rulesets has been functionality that has been available in ipfirewall(4) for a long time, however, because of its very limited stateful capabilities, ipfirewall(4) has long been regarded as a stateless firewall, with IPFilter the stateful alternative. Starting with FreeBSD 4.0, ipfirewall(4) has been enabled with more extensive stateful functionality, with more promised to come.

Basic Stateful Configuration For our first example, we will use the older, more basic, stateful capabilities of ipfirewall(4). Many people, following after the example in ~rc.firewall, where all of the pre-defined rulesets use this most basic of stateful functionality, make heavy use of the setup and established keywords for controlling TCP connections. Indeed, this can only be used to control TCP connections in a stateful manner, showing its limiting nature on at least one count. In our example, we will create a simple stateful firewall ruleset that only allows SSH connections through: add 1000 allow tcp from any to any established add 2000 allow tcp from any to any 22 in setup

61440520E1-5B E-11 PacketWave E510A/E520A Installation and Configuration Guide

Presuming a closed firewall policy (firewall_type is not OPEN and kernel does not have IPFIREWALL_DEFAULT_TO_ACCEPT set) the above two lines will first allow all established TCP connections to pass through. Specifically, any packets part of an established TCP connection will match rule 1000 and then ruleset searching will cease for those packets. If, on the other hand, any packet is not part of an established TCP connection, rule 1000 will not match it, and ruleset analysis will move to rule 2000, where, if the packet is a SYN TCP packet destined for port 22 (port for SSH), the rule will match it and let pass. Subsequent packets for that connection will be passed with rule 1000. In this manner, the above rules are stateful as they are aware of the existence of a TCP connection at large and not just individual packets. One could have easily accomplished the same with stateless rules; for instance: add 1000 allow tcp from any to any out add 2000 allow tcp from any to any 22 in In this example, all packets moving out from any to anywhere are allowed to pass through the firewall, and all packets moving to port 22 of anywhere from anywhere in, are passed through. In this case, the rules are not aware of the TCP connections—they do not test for initiation and established TCP connections, but instead, let all TCP packets move out, no matter what they are, and let all TCP packets in to port 22, no matter what they are. This is the essence of stateful behavior in ipfirewall(4) using the setup and established flags: pass through TCP setup requests to specified addresses:ports and then let these established connections through. Let us look at a more involved example that handles SSH, e-mail, FTP, and DNS queries for network 172.16.0.0/27: add 1000 allow tcp from any to any established add 2000 allow tcp from any to 172.16.0.0/27 21,22,25 setup add 3000 allow udp from 172.16.0.0/27 to any 53 add 3100 allow udp from any 53 to 172.16.0.0/27 In this example, setup of TCP connections is allowed for ports 21, 22, 25 (FTP, SSH, and e- mail respectively) when packets are destined for the 172.16.0.0 network. Afterwards, all established TCP connections are allowed to pass. Rules 3000 and 3100 pass UDP packets to port 53 on other hosts and allow UDP packets from port 53 on other hosts to pass in through the firewall. Both of these rules are stateless. Port 53 is the port on which DNS servers run. Rule 1000 must have from any to any because TCP packets for established connections must be allowed to both originate from anywhere and to arrive at anywhere. If one was to write a similar ruleset which was completely stateless, one would have to keep most TCP ports between 1024 and 65000 open for FTP connections. FTP is definitely a wild protocol as it randomly binds to non-reserved ports across a wide range. Allowing active FTP through a firewall is always difficult; only stateful firewalls offer a really clean approach to it, without opening massive ranges of ports. Most notably, the shortcoming of opening the ports with a stateless firewall is that anyone can attempt to connect to any port within that range. With our setup, only TCP connections that had been initiated through rule 2000 can be let through with the established option in rule 1000, effectively limiting random and uncon- trolled connections to the wide range of ports needed for clean active FTP operation.

Advanced Stateful Configuration As has been stated before, stateful firewall configuration with just the setup and established options is very limiting. Aside from only allowing stateful control over TCP connections, this stateful control is simplistic at best. Starting with FreeBSD 4.0 the stateful capabilities of

E-12 61440520E1-5B Appendix E, Security - IPFW howto Document V.0.2 ipfirewall(4) have been greatly augmented. Now, ipfirewall(4) can be configured for stateful handling of TCP, UDP, ICMP and other packets types with use of dynamic rules. Dynamic rules are another new addition to ipfirewall(4) in FreeBSD 4.0. Dynamic rules, as the name suggests, are dynamically generated for individual connections. Each dynamic rule, after lack of use past a period of time, times out. The specific timeout period for TCP connections can be controlled by several (8) sysctl variables. This allows control of not only connection initiation, but connection termination; this means, in a manner of speaking, a ruleset can be designed which is aware of the beginning and ending of a particular connection and which adjusts itself accordingly. One option and one command are used to control this advanced stateful behavior: •Any rule with set-state option initiates a dynamic rule whenever it is matched by a packet. •The check-state command allows the firewall search to first check the dynamic rules. If a rule with this command is missing from all of the rules in a ruleset, then dynamic rules are checked at the first instance of the set-state option. If a rule with this command is a match, then the search stops; otherwise, the search continues. Let us return to our earlier example of a ruleset designed to only allow SSH connections through, only this time using the advanced stateful ipfirewall(4) facilities: add 1000 check-state add 2000 allow tcp from any to any 22 in setup keep-state Remember, these rules presume that your firewall policy is a closed one (the default rule is to deny everything). In the above rules, the first rule prompts ipfirewall(4) to check the dynamic rules. If the immediate packets passing through the firewall do not belong to any already established connections (that is, they do not match any of the dynamic rules) then the search continues to rule 2000, where if the packet is a TCP SYN, then keep-state prompts the creation of a dynamic rule. Subsequent packets through that connection will be passed through the dynamic rule, which is checked for with rule 1000. All other packets would be rejected by the default deny rule. Even though we have already demonstrated how to do this with the older stateful approach and also a stateless approach, this new approach using the set-state option and check-state command has a distinct advantage above the other approaches. In the older stateful approach, the option established matched any TCP packets from an established TCP connection, even if they were spoofed and not from any current legitimate TCP connection. This new approach precludes such an occurrence. Each dynamic rule is for a specific connection between two hosts and their respective ports. Spoofed TCP packets will be able to spoof the source and destination IP addresses, but not the correct ports (unless they're very lucky) on which a legitimate TCP connection is being maintained; and thus, rule 1000 with the check-state command would fail, after which rule 2000 would fail unless the spoofed packet was a TCP SYN packet—then the packet would fall to the final deny rule. In summary, the criteria with which packets are tested against when trying to match a dynamic rule for them are: •Protocol • Source IP and Port • Destination IP and Port • Whether the rule has timed out

61440520E1-5B E-13 PacketWave E510A/E520A Installation and Configuration Guide

As noted before, the dynamic rules time out after lack of use over a particular period of time. Depending on how a dynamic rule is used, the rule's lifetime is given a particular period. The timeout values for the different types of rule uses can be viewed by printing the correct sysctl variables; moreover, one can modify these values. Here is the list of sysctl variables and their default values: (root@nu)~># sysctl -a | grep 'dyn.*lifetime' net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_fin_lifetime: 20 net.inet.ip.fw.dyn_rst_lifetime: 5 net.inet.ip.fw.dyn_short_lifetime: 5 (root@nu)~># The first sysctl variable indicates that the default lifetime value to which a dynamic rule used by a TCP ACK packet is immediately set to upon use is 300 seconds. The second variable indicates that the lifetime value to which a dynamic rule used by a TCP SYN packet is immediately set to upon use is 20 seconds. The third variable indicates that 20 seconds is also the value to which the lifetime of a dynamic rule used by a TCP FIN packet is set to. Dynamic rules used both by TCP RST packets and any other packets (UDP, ICMP, etc) are set with a 5- second lifetime, as indicated by the last two sysctl variables. Let's use an example to clarify how all of this works in action: 1. A legitimate TCP connection request from host 172.16.0.1 on port 1234 is sent to port 22 on a server 192.168.0.1 behind the firewall. This connection request consists of a TCP synchronization packet (TCP SYN). 2. Rule 1000 on the firewall has the firewall check the dynamic rules and finds none that correspond to any sort of TCP packets coming from 172.15.0.1:1234 and destined for 192.168.0.1:22. 3. Rule 2000 is checked is a match. The keep-state has a dynamic rule created for a TCP connection from 172.16.0.1:1234 to 192.168.0.1:22 with the lifetime of 20 seconds (default for TCP SYN packets). 4. Within one second a TCP ACK packet is sent to 192.168.0.1:22 in response to the TCP ACK sent from the server to the client, confirming the TCP connection request. 5. As the packet encounters the firewall, rule 1000 once again has the dynamic rules checked. This time a dynamic rule still within its lifetime exists which matches the protocol source IP:port and destination IP:port, so it is let through the dynamic rule, and the packet passes through the firewall safely. 6. A spoofed TCP ACK packet from an attacker enters the firewall which under normal circumstances could knock out the networking capability of certain unpatched Windows machines behind the firewall. 7. Rule 1000 checks the dynamic rules and finds that the spoofed packet has a destination IP:port that is an IP:port of an existing dynamic rule, its return IP:port does not match that of any rule (because it was randomly generated by the attacker). So, rule 1000 fails and checking moves to rule 2000. 8. Rule 2000 finds the packet not to be a TCP SYN, so the check-state option is not run as the rule is not matched. 9. Consequently, the packet falls to the default deny rule and is lost.

E-14 61440520E1-5B Appendix E, Security - IPFW howto Document V.0.2

Were this had been a stateful ruleset by the older method, the spoofed TCP packet would have been accepted with the first rule containing the “established” option because in our original example the rule accepted all TCP packets destined for a particular network behind the firewall that had at least the ACK flag set, and the spoofed packet indeed fulfilled these criteria. This is a first—but powerful—reason for why the advanced stateful operations of ipfirewall(4) are extremely useful, and what advantages IPFilter has in this regard also. In our above illustration, it would have gone differently had the spoofed packet been a TCP SYN packet, but before we describe why, let's examine a popular use of spoofed TCP SYN packets in computer attacks (also known as SYN floods). Spoofed TCP SYN packets are often used in network attacks. The most common of such attack consists of sending a flood of TCP SYN packets (SYN floods) to a host so that the entire connection queue in the prey's kernel is saturated with open connection attempts, thus denying the activation of new legitimate connections. Even though, the FreeBSD TCP/IP stack is designed to randomly drop TCP connection attempts from its queue past a particular threshold of maximum tolerated TCP connection attempts, this type of attack can be devas- tating. If the TCP SYN packets come fast enough they will initiate fake connections faster than they can be dropped low enough to free sufficient room for all legitimate connections. The primary variables are speed of the attack and speed of the box in its ability to process packets moving through its TCP/IP stack. Fortunately, FreeBSD's TCP/IP stack is faster than that of Linux and many other systems; however, it's not always fast enough. Just as in our previous illustration of spoofed TCP ACK packet handling with the advanced stateful functionality, randomly spoofed TCP packets of any sort (SYN or ACK) would be unsuccessful because each new packet with a random source IP:port would be unable to find a dynamic rule to pass through. However, if the original TCP SYN and all subsequently spoofed TCP packets maintain the same source IP:port, then the stream could open and maintain a TCP connection based on invalid source:port information. Also, one must be very careful about too many dynamic rules being opened by spoofed TCP SYN packets. Although, the TCP/IP stack wouldn't be overwhelmed by too many connection attempts, the firewall dynamic rule queue could be saturated. One way to try to avoid this is to shorten the lifetime of dynamic rules started by TCP SYN packets with the appropriate sysctl mentioned earlier and extending the maximum number of dynamic rules, which is done via another sysctl: net.inet.ip.fw.dyn_max: 1000 (default) To get a quick count of how many dynamic rules exist, one should print the value of the sysctl variable: net.inet.ip.fw.dyn_count One sure way to avoid the possibility of spoofed packets from using up all of your dynamic rules is to disallow external hosts from initiating TCP connections. This can be done easily with the following rules, presuming that 192.168.0.0/27 is the net behind the firewall: add 1000 check-state add 2000 allow tcp from 192.168.0.0/27 to any out setup \ keep-state When TCP SYN packets reach rule 2000, they fail to match and are dropped by the default deny because only TCP SYN packets moving out and with the source address from the protected net (192.168.0.0/27) will match the rule. Incidentally, this is the same type of protection that NAT, and transparent proxies in general, affords for internal hosts. Until now, most of the discussion has revolved around stateful handling of TCP connections. However, using the advanced stateful functionality one can, as has been stated, control other

61440520E1-5B E-15 PacketWave E510A/E520A Installation and Configuration Guide packet types in a stateful manner. For instance, during our discussion of the option icmptypes, we presented an example of how one could use them to allow internal hosts to ping external hosts, and deny it the other way around. This can be easily done with the check-state command and set-state option as well: add 1000 check-state add 2000 allow icmp from any to any out icmptypes 8 keep-state This works simply by creating a dynamic rule for every ICMP echo request sent out. When the reply comes, it uses the dynamic rule and is passed through. However, if someone tries to send in an ICMP echo, it is denied unless they happen to send it during the moment our dynamic rule is alive. ICMPs use the net.inet.ip.fw.dyn_short_lifetime sysctl variable which is by default set to 5 seconds. If the ICMP echo reply takes longer than 5 seconds to reply, the dynamic rule's life will timeout and it won't be able to pass through. If long ping replies are suspected to be a possibility, then that sysctl's value should be raised. Most network lag is under one second, however. Incidentally, rule 2000 could also be written with the source address being a network address if there were more than one network behind the firewall and one wanted to specify which network these rules should apply to. Likewise, one could limit the rule to a single host address. We used this format because it was closest to what our first ping controlling rules used.

Anatomy of a Dynamic Rule Let us take a look at what it may exactly look like when one lists their stateful firewall rules: 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 01000 check-state 02000 allow tcp from any to any keep-state 65535 deny ip from any to any ## Dynamic rules: 02000 9 1255 (T 54, # 0) ty 0 tcp, 192.168.0.1 2007 <-> 204.71.200.245 80 We are already familiar with the static rules; however, this is the first time we're showing an example of a dynamic rule. Let us examine it closely: The first part of the dynamic rule is the rule # of the static rule that started it, in this case, rule 2000, which has a keep-state option. The second part is the count of bytes that have been sent out through that dynamic rule, and the third part is the count of bytes that have been received through that rule. In the parentheses, the T value is the timeout value (the rule lifetime) in seconds. In this case, 54 seconds are life for the rule. The hash mark (#) indicates the rule number, in this case being rule 0. The ty 0 portion indicates what type of dynamic rule this is. The rule type corresponds to the flow of the rule—whether it allows traffic only from source to destination, the other way around, or both (bidirectional). Currently, only the rule type bidirectional is available, and it is the default. This is visually indicated by the <-> symbol between the source and destination IP:port. After the type, we see the protocol that the dynamic rule passes through, followed by the source IP:port, a bidirectional indicator <-> as mentioned above, and finally the destination IP:port. Even after dynamic rules timeout, you will still see them listed with ipfw list, although with a 0 (zero) T value. Once a rule times out, it will no longer accept packets as it would have normally unless it is revived with the same static rule with a keep-state. Also, once they timeout they can be replaced by newly activated dynamic rules. Unless all of the dynamic

E-16 61440520E1-5B Appendix E, Security - IPFW howto Document V.0.2 rules are alive, they will be continuously replaced with new ones, especially so as the number of dynamic rules approaches the maximum. Once many dynamic rules are created, it may become somewhat of a nuisance to list the rules with ipfw list as all of the dynamic rules will stream off the terminal. To only list the static rules, one can do something like: ipfw list | grep -v '[<->#]' Or, if one wishes to page down all of the rules, both static and dynamic, one can: ipfw list | more

61440520E1-5B E-17 PacketWave E510A/E520A Installation and Configuration Guide

LICENSES The following sections detail the third-party licenses in use by ADTRAN for use in its software.

OpenSSL Copyright (c) 1998-2001 The OpenSSL Project. All rights reserved. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/). THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT “AS IS” AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Original SSLeay SSLeay is a free implementation of Netscape's Secure Socket Layer - the software encryption protocol behind the Netscape Secure Server and the Netscape Navigator Browser. Copyright (C) 1995-1998 Eric Young ([email protected]) All rights reserved. This product includes cryptographic software written by Eric Young ([email protected]) THIS SOFTWARE IS PROVIDED BY ERIC YOUNG “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

E-18 61440520E1-5B Appendix E, Security - Licenses

OpenSSH The licenses which components of this software fall under are as follows. First, we will summarize and say that all components are under a BSD license, or a license more free than that. OpenSSH contains no GPL code. 1) Copyright (c) 1995 Tatu Ylonen, [email protected], Espoo, Finland All rights reserved As far as I am concerned, the code I have written for this software can be used freely for any purpose. Any derived versions of this software must be clearly marked as such, and if the derived work is incompatible with the protocol description in the RFC file, it must be called by a name other than “ssh” or “Secure Shell”. However, I am not implying to give any licenses to any patents or copyrights held by third parties, and the software includes parts that are not under my direct control. As far as I know, all included source code is used in accordance with the relevant license agreements and can be used freely for any purpose (the GNU license being the most restrictive); see below for details. [However, none of that term is relevant at this point in time. All of these restrictively licensed software components which one talks about have been removed from OpenSSH, for example:] • RSA is no longer included, found in the OpenSSL library • IDEA is no longer included, its use is deprecated • DES is now external, in the OpenSSL library • GMP is no longer used, and instead we call BN code from OpenSSL • Zlib is now external, in a library • The make-ssh-known-hosts script is no longer included • TSS has been removed • MD5 is now external, in the OpenSSL library • RC4 support has been replaced with ARC4 support from OpenSSL • Blowfish is now external, in the OpenSSL library [The license continues] Note that any information and cryptographic algorithms used in this software are publicly available on the Internet and at any major bookstore, scientific library, and patent office worldwide. More information can be found e.g. at http://www.cs.hut.fi/crypto. The legal status of this program is some combination of all these permissions and restrictions. Use only at your own responsibility You will be responsible for any legal consequences yourself; I am not making any claims whether possessing or using this is legal or not in your country, and I am not taking any responsibility on your behalf. NO WARRANTY BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES

61440520E1-5B E-19 PacketWave E510A/E520A Installation and Configuration Guide

PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDIS- TRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 2) The 32-bit CRC implementation in crc32.c is due to Gary S. Brown. Comments in the file indicate it may be used for any purpose without restrictions: COPYRIGHT (C) 1986 Gary S. Brown. You may use this program, or code or tables extracted from it, as desired without restriction. 3) The 32-bit CRC compensation attack detector in deattack.c was contributed by CORE SDI S.A. under a BSD-style license. See http://www.core-sdi.com/english/ssh/ for details. Cryptographic attack detector for ssh - source code Copyright (c) 1998 CORE SDI S.A., Buenos Aires, Argentina. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that this copyright notice is retained. THIS SOFTWARE IS PROVIDED “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES ARE DISCLAIMED. IN NO EVENT SHALL CORE SDI S.A. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES RESULTING FROM THE USE OR MISUSE OF THIS SOFTWARE. Ariel Futoransky, [email protected] http://www.core-sdi.com 4) Remaining components of the software are provided under a standard 2-term BSD license with the following names as copyright holders: • Markus Friedl •Theo de Raadt • Niels Provos • Dug Song • Aaron Campbell Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

E-20 61440520E1-5B Appendix E, Security - Licenses

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE AUTHOR “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLI- GENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Radclient 0.3.1 Radclient is a radius client program included as part of FreeRADIUS. It can send arbitrary radius packets to a radius server, and then shows the reply. It can be used to test changes made in the configuration of the radius server, or it can be used to monitor if a radius server is up. Copyright (C) 1995,1996,1997,1998 Lars Fenneberg, [email protected] Copyright 1992 Livingston Enterprises, Inc. Livingston Enterprises, Inc. 6920 Koll Center Parkway Pleasanton, CA 94566 Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All rights reserved. License to copy and use this software is granted provided that it is identified as the “RSA Data Security, Inc. MD5 Message-Digest Algorithm” in all material mentioning or referencing this software or this function. License is also granted to make and use derivative works provided that such works are identified as “derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm” in all material mentioning or referencing the derived work. RSA Data Security, Inc. makes no representations concerning either the merchantability of this software or the suitability of this software for any particular purpose. It is provided “as is” without express or implied warranty of any kind. These notices must be retained in any copies of any part of this documentation and/or software.

61440520E1-5B E-21 PacketWave E510A/E520A Installation and Configuration Guide

This page is intentionally blank.

E-22 61440520E1-5B Appendix F Module Specifications

This appendix covers the modules that are available in the PacketWave E510A/E520A platform. This appendix includes the following sections: • “Overview” on page F-2 • “Modules” on page F-3

61440520E1-5B F-1 PacketWave E510A/E520A Installation and Configuration Guide

OVERVIEW The PacketWave E510A/E520A offers the following modules in two available front slots: • 8-port T1/8-port E1 • 24-port T1/21-port E1 • single port Gigabit Ethernet • dual port Gigabit Ethernet The low-speed modular slot (SLOT 3) supports physical interfaces that run at an interface speed of less than or equal to 100 Mbps. The low-speed module is hot swappable. T1/E1 ports can be synchronized to a single Stratum clock; T1/E1 ports in asynchronous mode can be independently clocked. The high-speed modular slot (SLOT 2) supports physical interfaces that run at an interface speed of less than or equal to 1 Gbps. The high-speed module is hot swappable. In addition, any low-speed module can use the high-speed slot with the same functionality.

Table F-1 describes the two front slots and the available modules for each.

Table F-1. Module Slots

Slot Front Module

Single port Gigabit Ethernet

Dual port Gigabit Ethernet 2 (high-speed) 24-port T1/21-port E1

8-port T1/8-port E1

24-port T1/21-port E1 3 (low-speed) 8-port T1/8-port E1

T1/E1 port 1 can be configured as a BITS port to provide timing from the ring on the E520A and ES520A platforms.

F-2 61440520E1-5B Appendix F, Module Specifications - Modules

MODULES The following sections detail the available modules, their features and handling.

Inserting Modules Insert modules until they are flush with the front of the platform. Tighten the screws.

Switching Modules To switch a module in a slot, complete the following procedure in either CLI or ADTRAN LMS, for all module types. Before starting the procedure, remove all service provisioning from the module and, if the slot provides a clock source, delete it.

CLI Procedure 1. Remove the module from the platform. 2. Set the slot type to auto, for example: set slot type set slot type 3 auto 3. Set the slot type to none, for example: set slot type set slot type 3 none 4. Check that the slot type of the target slot is set to none. The output of the show slot brief command will show a slot type of none and an Oper State of Not Present, for example:

ADTRAN LMS Procedure 1. Remove the module from the platform. 2. In the ADTRAN LMS tree view, the slot type will show Not Present as shown in Figure F-1.

Figure F-1. Slot Type of Not Present in Tree View

61440520E1-5B F-3 PacketWave E510A/E520A Installation and Configuration Guide

3. In the tree view, right-click on the slot and select Slot Manager as shown in Figure F-2.

Figure F-2. Selecting Slot Manager

4. The Slot Manager window is displayed as shown in Figure F-3.

Figure F-3. Slot Manager Window, Slot Type Auto

5. From the Type field, select none as shown in Figure F-4.

F-4 61440520E1-5B Appendix F, Module Specifications - Modules

Figure F-4. Slot Manager Window, Slot Type None

6. Click OK. The old module will no longer be visible in the tree view. 7. Insert the new module into the platform. If the new module isn’t available in the tree view, switch to a different filter (for example, Ethernet) or do a refresh.

Hot Swapping Modules All T1/E1 and Ethernet modules referred to in document are hot swappable, which allows the modules to be added or removed from the E510A/E520A without powering down the platform, allowing for maximum uptime.

Troubleshooting Modules If there is a slot type mismatch alarm, use the procedure described in “Switching Modules” on page F-3. If a module doesn’t come up, there will be a card failed alarm. Check that the module is inserted flush with the platform and that the screws are tightened. In the CLI, check the Oper State of the module using the show slot brief command. If the Oper State is Down, you can reset the module, as follows: set slot state set slot state 3 reset In ADTRAN LMS, right-click on the module in the tree view and select Status from the card menu. Check the CardOperState and click Cancel. If the CardOperState was not active, right-click on the module in the tree view and select Action -> Reset Card from the card menu.

61440520E1-5B F-5 PacketWave E510A/E520A Installation and Configuration Guide

8-Port T1/E1 Module The low-speed slot (SLOT 3) or high-speed slot (SLOT 2) can support one 8-port T1/E1 module. Figure F-5 shows the 8-port T1/E1 module. The module features one LED for each of the T1/E1 ports. The following describes the behavior of these LEDs: • If there is no alarm condition, the LED illuminates green to indicate synchronization activity (SYNC). • If there is an alarm condition and alarms are turned on, the LED illuminates red to indicate a FAULT has been detected on that port. • If there is an alarm condition and alarms are turned off, the LED is off.

Figure F-5. 8-Port T1/E1 Module

24-Port T1/21-Port E1 Module The low-speed slot (SLOT 3) or high-speed slot (SLOT 2) can support one 24-port T1/21-port E1 module. Figure F-6 shows the module.

Figure F-6. 24-Port T1/21-Port E1 Module

F-6 61440520E1-5B Appendix F, Module Specifications - Modules

Single Port Gigabit Ethernet Module The high-speed slot (SLOT 2) supports a single port Gigabit Ethernet module. Figure F-7 shows the module, which contains the following LEDs: • TX EN - Green • LINK - Green • RX SYNC - Green

Figure F-7. Single Port Gigabit Ethernet Module

WARNING Laser radiation is present when the system is on and the fiber-optic cable is disconnected. Do not stare into the laser beam.

Copper SFP A copper Small Form-factor Pluggable (SFP) is available for the single port Gigabit Ethernet module and the dual port Gigabit Ethernet module on the E510A/E520A. If using the copper SFP (instead of the optical SFP), refer to the following notes: • Turn on autonegotiation (using the CLI command set port options). • When inserting the SFP, put the SFP bail in the upper position (toward the label). • The SFP will not raise a PLUGGABLE_NOT_APPROVED minor alarm in Release 7.4 and up. • The SFP will work in releases prior to Release 7.4, but you must turn off the PLUGGABLE_NOT_APPROVED minor alarm (using the CLI command service port-alarm).

61440520E1-5B F-7 PacketWave E510A/E520A Installation and Configuration Guide

Dual Port Gigabit Ethernet Module The high-speed slot (SLOT 2) supports a dual port Gigabit Ethernet module. The two ports share 1 G of bandwidth. This module supports wire speed for all services (including TLS-TE) and wire mode physical port rate limiting provisioning. One of the main applications for this module is IP-DSLAM backhaul. Figure F-8 shows the module, which contains the following LEDs for each port: • TX EN - Green • LINK - Green • RX SYNC - Green

Figure F-8. Dual Port Gigabit Ethernet module

WARNING Laser radiation is present when the system is on and the fiber-optic cable is disconnected. Do not stare into the laser beam.

F-8 61440520E1-5B Appendix G Warranty

WARRANTY AND CUSTOMER SERVICE ADTRAN will replace or repair this product within the warranty period if it does not meet its published specifications or fails while in service. Warranty information can be found at www.adtran.com/warranty. Refer to the following subsections for sales, support, Customer and Product Service (CAPS) requests, or further information.

ADTRAN Sales Pricing/Availability: 800-827-0807

ADTRAN Technical Support Pre-Sales Applications/Post-Sales Technical Assistance: 800-726-8663 Standard hours: Monday - Friday, 7 a.m. – 7 p.m. CST Emergency hours: 7 days/week, 24 hours/day

ADTRAN Repair/CAPS Return for Repair/Upgrade: (256) 963-8722

Repair and Return Address Contact Customer and Product Service prior to returning equipment to ADTRAN. ADTRAN, Inc. CAPS Department 901 Explorer Boulevard Huntsville, Alabama 35806-2807

61440520E1-5B G-1 PacketWave E510A/E520A Installation and Configuration Guide

This page is intentionally blank.

G-2 61440520E1-5B Appendix H Glossary

AC Electrical AC (Alternating Current) occurs when charge carriers in a conductor or semiconductor periodically reverse their direction of movement. access network Public network transmission and switching plant that connects a customer premises to the core of the public network.

ACL Access Control List

Address Resolution Protocol (ARP) The Internet protocol used to dynamically map Internet addresses to physical (hardware) addresses on local area networks.

ADTRAN LMS ADTRAN software solution for element and network management that provides comprehensive Fault, Configuration, Accounting, Performance and Security (FCAPS) management. It enables trouble-free supervision and instantaneous service provisioning using the Service Management Framework. ADTRAN LMS features an intuitive graphic user interface. alternating current (AC) See AC.

ARP See Address Resolution Protocol (ARP).

Asynchronous Transfer Mode (ATM) High bandwidth, low-delay, connection-oriented, cell switching and multiplexing technique requiring fixed byte sized cells.

ATM See Asynchronous Transfer Mode (ATM). backbone The primary connectivity mechanism of a hierarchical distributed system. All systems that have connectivity to an intermediate system on the backbone are assured of connectivity to each other.

61440520E1-5B H-1 PacketWave E510A/E520A Installation and Configuration Guide

backplane A backplane is an electronic circuit board containing circuitry and sockets into which additional electronic devices on other circuit boards or cards can be plugged.

BALUN Balanced/Unbalanced bandwidth The difference between the highest and lowest frequencies of a band that can be passed by a transmission medium. Also used to describe the digital bit rate or throughput. baseband Characteristic of any network technology that uses a single carrier frequency and requires all stations attached to the network to participate in every transmission.

BER See Bit Error Ratio (BER)

BGP See Border Gateway Protocol (BGP).

Bit Error Ratio (BER) The percentage of bits that have errors relative to the total number of bits received in a transmission.

Border Gateway Protocol (BGP) BGP is a protocol for exchanging routing information between gateway hosts in a network of autonomous systems. BGP is often the protocol used between gateway hosts on the Internet. The routing table contains a list of known routers, the addresses they can reach, and a cost metric associated with the path to each router so that the best available route is chosen. bridge A bridge is a product that connects a LAN to another local area network. Bridging networks work at layer 2 and generally interconnect local area networks since broadcasting every message to all possible destinations would flood a larger network with unnecessary traffic. broadband Characteristics of any network that multiplexes multiple, independent network carriers onto a single cable. Broadband technology allows several networks to co-exist on one single cable. Traffic from one network does not interfere with traffic from another. broadcast A packet delivery system where a copy of a given packet is given to all hosts attached to the network.

H-2 61440520E1-5B buffer A buffer is a data area shared by hardware devices or program processes that operate at different speeds or with different sets of priorities. carrier-class Use to describe specification requirements for equipment installed in a Tier 1 central office. Requirements include: Shelf hardware redundancy, Network topology protection, NEBS3 certified, high availability software architecture, support five-nines reliability, 48 V DC powering.

CDR See Clock and Data Recovery (CDR).

Central Office (CO) A CO is an office in a locality to which subscriber home and business lines are connected on what is called a local loop. The central office has switching equipment that can switch calls locally or to long-distance carrier phone offices.

Channel Service Unit/Data Service Unit (CSU/DSU) A CSU/DSU is a hardware device that converts digital data frames from the communications technology used on a LAN into frames appropriate to a WAN and vice versa.

CIDR See Classless Inter-Domain Routing (CIDR). circuit switch Circuit-switched is a type of network in which a physical path is obtained for and dedicated to a single connection between two end-points in the network for the duration of the connection. Ordinary voice phone service is circuit-switched. The telephone company reserves a specific physical path to the number you are calling for the duration of your call.

Class of Service (CoS) Indication of how an upper-layer protocol requires a lower-layer protocol to treat its messages.

Classless Inter-Domain Routing (CIDR) CIDR is a way to allocate and specify the Internet addresses used in inter- domain routing more flexibly than with the original system of IP address classes. As a result, the number of available Internet addresses has been greatly increased. CIDR is now the routing system used by virtually all gateway hosts on the Internet's backbone network.

CLEC See Competitive Local Exchange Carrier (CLEC).

CLI See Command Line Interface (CLI).

61440520E1-5B H-3 PacketWave E510A/E520A Installation and Configuration Guide

Clock and Data Recovery (CDR) Bellcore specifications require certain performance characteristics for products interfacing with the public SONET network in terms of jitter transfer, jitter tolerance, jitter peaking, and clock stability. When designing systems that will interface on these networks, it is important to specify CDR parts which meet all of the Bellcore specifications. Since performance trade-offs exist between these specifications, a part which claims to meet the jitter transfer characteristics for example may not meet other characteristics such as jitter peaking. In addition, there may be other attributes which are required in a particular system which are not specified by the Bellcore specifications. An example of this is acquisition time. Most manufacturers require that the CDR part acquire the signal in one frame of data, or 125 uS at 155.52 MHz. A first order PLL can meet the specified Bellcore jitter transfer characteristics, but only at the expense of an extraordinarily long acquisition time. Although not explicitly specified by Bellcore, the real system may well require a faster acquisition time than the simple PLL can provide. As will be seen, enhancements can be made to PLL- based CDR parts to enhance performance in certain areas however.

CO See Central Office (CO).

Command Line Interface (CLI) Interface that allows the user to interact with the operating system by entering commands and optional arguments.

Common Object Request Broker Architecture (CORBA) CORBA is a communication pathway between disparate network management systems. CORBA is an architecture and specification for creating, distributing, and managing distributed program objects in a network. It allows programs at different locations and developed by different vendors to communicate in a network through an “interface broker.”

Competitive Local Exchange Carrier (CLEC) CLEC is a company that competes with the already established local telephone business by providing its own network and switching. The term distinguishes new or potential competitors from established local exchange carriers (LECs) and arises from the Telecommunications Act of 1996, which was intended to promote competition among long-distance and local phone service providers.

Concatenated Synchronous Transport Signal level N (STS-Nc) A signal in which the Envelope Capacities from the N STS-1s have been combined to carry an STS-Nc Synchronous Payload Envelope (SPE). An STS-Nc may be transported as an OC-N or STS-N electrical signal, or it may be a module that is multiplexed into a higher rate signal (in which case it is referred to as an STS-Mc). In either case, it must be transported as a single entity, not as N (or M) separate signals.1 See also Synchronous Payload Envelope (SPE).

1. GR-253-CORE. SONET Transport Systems: Common Criteria. Issue 2, December 1995.

H-4 61440520E1-5B connectionless The model of interconnection in which communication takes place without first establishing a connection. connection-oriented The model of interconnection in which communication proceeds through three well-defined phases: connection establishment, data transfer, and connection release. control plane route A route between the LAN IP address to the NMS (gateway) port.

CORBA See Common Object Request Broker Architecture (CORBA).

COS See Class of Service (CoS).

CPE See Customer Premise Equipment (CPE). cp-route See control plane route. cross connect An electronic switching system, found in telephone central offices, that switches groups of signals from one route to another, without the need to demultiplex them.

CSU/DSU See Channel Service Unit/Data Service Unit (CSU/DSU).

Customer Premise Equipment (CPE) CPE is service provider equipment that is located on the customer's premises (physical location) rather than on or in between the provider's premises. dark fiber Dark fiber is optical fiber infrastructure (cabling and repeaters) that is currently in place but is not being used.

DC Direct current (DC) is the unidirectional flow or movement of electric charge carriers, usually electrons. The intensity of the current can vary with time, but the general direction of movement stays the same at all times.

Direct Current See DC.

Digital Subscriber Line (DSL) DSL is a technology for bringing up to 8.0 Mb/s of bandwidth to homes and small businesses over ordinary copper telephone lines. xDSL refers to different variations of DSL, such as ADSL, HDSL, and RADSL.

61440520E1-5B H-5 PacketWave E510A/E520A Installation and Configuration Guide

Digital Subscriber Line Access Multiplexer (DSLAM) A DSLAM is a network device, usually at a telephone company central office, that receives signals from multiple customer Digital Subscriber Line (DSL) connections and puts the signals on a high-speed backbone line using multiplexing techniques.

DSL See Digital Subscriber Line (DSL).

DSLAM See Digital Subscriber Line Access Multiplexer (DSLAM).

EIA See Electronic Industries Association (EIA).

Electrical Carrier level 1 (EC-1) One designation for the electrical interface signal that is the counterpart to the basic module in SONET, the STS-1.1 See also Electrical Carrier level N (EC-N).

Electrical Carrier level N (EC-N) One designation for the electrical interface signal that is the counterpart to an STS-N.1 See also Electrical Carrier level 1 (EC-1).

Electronic Industries Association (EIA) Group that specifies electrical transmission standards.

EPL See Ethernet Private Line (EPL).

Ethernet Ethernet is the most widely-installed local area network technology. An Ethernet LAN typically uses coaxial cable or special grades of twisted pair wires. The most commonly installed Ethernet systems are called 10 Base-T and provide transmission speeds up to 10 Mb/s. See also fast Ethernet.

Ethernet Private Line (EPL) EPL is a cross connection (wire model service) between two ports. Local and remote cross connections can be created. Ethernet provisioning can be extended using Extended Virtual Leased Lines (EVLL) across multiple rings connected using Gigabit Ethernet ports. fast Ethernet Fast Ethernet is a local area network (LAN) transmission standard that provides a data rate of 100 megabits per second (referred to as “100Base-T”). See also Ethernet. fault-management, configuration, accounting, performance, and security (FCAPS) See FCAPS.

FCAPS FCAPS (fault-management, configuration, accounting, performance, and security) is an acronym for the levels of network management. There are five

H-6 61440520E1-5B levels: fault-management (F), configuration (C), accounting (A), performance (P), and security (S). At the fault-management level, network problems are found and corrected, potential future problems are identified, and steps are taken to prevent their occurrence. At the configuration level, network operation is monitored and controlled through the coordination of hardware and programming changes, such as new programs or equipment, existing program modification, and a regular inventory of equipment and programs. The accounting level (also known as the allocation level) distributes resources optimally and fairly among network subscribers and bills users appropriately. The performance level is involved with managing the overall performance of the network by maximizing throughput and avoiding bottlenecks and other potential problems. At the security level, the network is protected against hackers, unauthorized users, and physical or electronic sabotage.

FDDI FDDI is a standard for data transmission on fiber optic rings in a local area network that can extend in range up to 200 km (124 miles).

Fibre Channel Fibre Channel is a technology for connecting computer servers to shared storage devices and for interconnecting storage controllers and drives. flow End-to-end data connection defined by a source and destination address pair at any single layer. frame relay Frame relay is a telecommunication service designed for data transmission for intermittent traffic between LANs and between end-points in a WAN. Frame relay puts data in a variable-size unit called a frame and leaves any necessary error correction (retransmission of data) up to the end-points, which speeds up overall data transmission. gateway A gateway is a network point that acts as an entrance to another network.

GBIC Gigabit Interface Converter

Gigabit Ethernet (GigE) Gigabit Ethernet is a LAN transmission standard that provides a data rate of 1 billion bits per second. Gigabit Ethernet is defined in the IEEE 802.3z standard. Gigabit Ethernet is carried primarily on optical fiber.

GigE See Gigabit Ethernet (GigE).

HA See High Availability (HA).

61440520E1-5B H-7 PacketWave E510A/E520A Installation and Configuration Guide

High Availability (HA) There are two kinds of High Availability (HA) or redundancy. 1+1 redundancy is available for Syscon, switch, and SRC cards. This kind of HA provides an active card, a standby card, and the ability to switch over from one to the other. N+1 redundancy is available for T1/E1 cards. This kind of HA provides an active card and a standby card that acts as the standby for multiple cards.

Internet Control Message Protocol (ICMP) The protocol used to handle errors and control messages at the IP layer. ICMP is part of the Internet protocol.

IDL See Interface Definition Language (IDL).

IIOP See Internet Inter-ORB Protocol (IIOP).

Incumbent Local Exchange Carrier (ILEC) An incumbent local exchange carrier is a telephone company in the U.S. that was providing local service when the Telecommunications Act of 1996 was enacted. ILECs include the Bell operating companies, which were grouped into holding companies known collectively as the regional Bell operating companies (RBOCs).

ILEC See Incumbent Local Exchange Carrier (ILEC).

Interface Definition Language (IDL) A language used to define the interface between an Application Programming Interface (API) and an external client.

Internet Inter-ORB Protocol (IIOP) Internet Inter-ORB protocol is an Internet Inter-Object Request Broker Protocol. It is a protocol for communication between an Application Programming Interface (API) and an external client.

Internet Protocol (IP) Internet Protocol is a network layer protocol that offers connectionless internetwork service between computers. IP (defined in RFC 791) provides features for addressing, type-of-service specification, fragmentation and reassembly, and security.

Internet Service Provider (ISP) An Internet service provider is a company that provides individuals and enterprises access to the Internet and other related services such as Web site building and hosting. An ISP has the equipment and the line access required to have points-of-presence for the geographic area served.

I/O card Rear card that can be insert into a rear card slot.

H-8 61440520E1-5B IP See Internet Protocol (IP).

IPFW IPFIREWALL (IPFW) is a FreeBSD sponsored firewall software application authored and maintained by FreeBSD volunteer staff members. It uses the legacy stateless rules and a legacy rule coding technique to achieve what is referred to as Simple Stateful logic.

ISP See Internet Service Provider (ISP).

ITU-grid Each different wavelength in a wavelength-division multiplexed system will be separated by a multiple of 0.8 nm. This is sometimes referred to as “100 GHz spacing,” which is the frequency separation, or as the “ITU-Grid.” ITU-Grid is named after the standards body that set the figure.

LAN See Local Area Network (LAN).

LANE See LAN emulation (LANE)

LAN emulation (LANE) Technology that allows an ATM network to function as a LAN backbone. latency In a network, latency, a synonym for delay, is an expression of how much time it takes for a packet of data to get from one designated point to another. legacy Legacy applications and data are those that have been inherited from languages, platforms, and techniques earlier than current technology. line card Module interfaces from external traffic sources into a node. A card that can be inserted into a M-Series or C-Series chassis front slot. line interface Module interfaces from external traffic sources into a node.

Local Area Network (LAN) A LAN is a network of interconnected workstations sharing the resources within a relatively small geographic area. Typically, this might be within the area of a small office building. local loop In telephony, a local loop is the wired connection from a telephone company's central office in a locality to its customers' telephones at homes and businesses. This connection is usually on a pair of copper wires called twisted pair.

61440520E1-5B H-9 PacketWave E510A/E520A Installation and Configuration Guide

MAC See Medium Access Control (MAC).

MAN See Metropolitan Area Network (MAN).

Management Information Base (MIB) SNMP collects management information from devices on the network records the information in a management information base. The MIB information includes device features, data throughput statistics, traffic overloads, and errors.

MD5 MD5 (Message-Digest algorithm 5) is a widely-used cryptographic hash function with a 128-bit hash value. As an Internet standard (RFC 1321), MD5 has been employed in a wide variety of security applications, and is also commonly used to check the integrity of files.

MDI Medium Dependent Interface. An Ethernet port connection that allows network hubs or switches to connect to other hubs or switches without a null-modem, or crossover, cable.

MDI-X Medium Dependent Interface-Crossover (the “X” representing “crossover”). An Ethernet port connection that allows networked end stations (i.e., PCs or workstations) to connect to each other using a null-modem, or crossover, cable.

Medium Access Control (MAC) The layer in the OSI model above the physical layer. It defines Media Access Control methods and parameters for access to the physical media.

Metropolitan Area Network (MAN) Metropolitan area network connects the LAN and WAN. Generally, a MAN spans a larger geographic area than a LAN, but a smaller geographic area than a WAN.

MIB See Management Information Base (MIB). module System hardware card.

MPLS See Multi-Protocol Label Switching (MPLS). multicast A form of broadcast where copies of the packet are delivered to only a subset of all possible destinations. multiplexing Multiplexing the sending of multiple signals or streams of information on a carrier at the same time in the form of a single, complex signal and then recovering the separate signals at the receiving end. Digital signals are

H-10 61440520E1-5B commonly multiplexed using TDM, in which the multiple signals are carried over the same channel in alternating time slots.

Multi-Protocol Label Switching (MPLS) Multi-Protocol Label Switching is a standards-approved technology for speeding up network traffic flow and making it easier to manage. MPLS involves setting up a specific path for a given sequence of packets, identified by a label put in each packet, thus saving the time needed for a router to look up the address to the next node to forward the packet to. MPLS is called multiprotocol because it works with the IP, ATM, and frame relay network protocols. In addition to moving traffic faster overall, MPLS makes it easy to manage a network for QoS.

Network Equipment Building Systems (NEBS) NEBS is the Bellcore requirement for equipment deployed in a central office environment. NEBS covers spatial, hardware, thermal, fire resistance, handling and transportation, earthquake and vibration, airborne contaminants, grounding, acoustical noise, illumination requirements.

NEBS See Network Equipment Building Systems (NEBS).

Network Operations Center (NOC) Group responsible for maintaining a network.

NMS Network Management System

NOC See Network Operations Center (NOC). node Logical entity equivalent to a full operational equipment shelf.

OCx (Optical Carrier level) Includes a set of signal rate multiples for transmitting digital signals on optical fiber. The base rate (OC1) is 51.84 Mb/s. OC2 runs at twice the base rate, OC3 at three times the base rate (155.52 Mb/s), OC12 (622.08 Mb/s), and OC48 (2.488 Gb/s). See also Optical Carrier level 1 (OC-1) and Optical Carrier level N (OC-N).

Open Shortest Path First (OSPF) OSPF is a routing protocol used within larger autonomous networks. OSPF is designated by the Internet Engineering Task Force (IETF) as one of several Interior Gateway Protocols (IGPs). Using OSPF, a host that obtains a change to a routing table or detects a change in the network immediately multicasts the information to all other hosts in the network so that all will have the same routing table information.

OPL See Optical Private Line (OPL).

61440520E1-5B H-11 PacketWave E510A/E520A Installation and Configuration Guide

Optical Access Switch Carrier-class packet switch that processes traffic onto a metropolitan optical fiber network. Optical access switches scale to multi-gigabit levels, support both ring and mesh network topologies, support end-to-end IP QoS to manage classes of service, support fast fail-over upon fiber span failures, and support legacy circuit voice.

Optical Carrier level 1 (OC-1) The optical interface signal that is the counterpart to the basic module in SONET, the STS-1.1

Optical Carrier level N (OC-N) The optical interface signal that is the counterpart to an STS-N.1

Optical Private Line (OPL) OPL is a service used for configuring Dense Wave Division Multiplexing (DWDM) cards. DWDM allows for the transmission of 17 wavelengths (lambdas) on a single optical fiber.

Packet-Over-SONET (POS) A high-speed method of transporting IP traffic between two points. This technology combines the Point-to-Point Protocol (PPP) with SONET and Synchronous Digital Hierarchy (SDH) interfaces. packet-switched Packet-switched describes the type of network in which relatively small units of data called packets are routed through a network based on the destination address contained within each packet. Breaking communication down into packets allows the same data path to be shared among many users in the network. Most traffic over the Internet uses packet switching and the Internet is basically a connectionless network.

PacketWave Family of optical access switches produced by ADTRAN. PacketWave enables service providers to build a scalable, multi-gigabit optical infrastructure supporting circuit voice and IP-based services. The carrier class family provides all popular access interfaces, including 10/100Base-T Ethernet, Gigabit Ethernet, T1/E1, OC-3/STM-1 at the highest reliability. PacketWave also allows established carriers derive the maximum performance and revenue potential from their existing SONET/SDH infrastructure as they migrate to next- generation packet services. The PacketWave family includes the M-Series, C- Series, E510A, E520A and ES520A. See also PacketWave M-Series, PacketWave C-Series, and PacketWave E510A, E520A and ES520A.

PacketWave C-Series The PacketWave C-Series is a packet-optimized optical transport platform that supports the full spectrum of IP data, and toll-quality voice services, enabling service providers to deploy very high-capacity, multi-service networks. The C-Series is a compact, carrier-class member of the family of products. Offering fully redundant AC/DC power, fan trays, and switch fabric, the C-Series offers toll quality TDM interfaces (including T1/E1 and channelized OC-3/STM-

H-12 61440520E1-5B 1) and data interfaces (10/100 and Gigabit Ethernet) carried over RPR or a SONET/SDH network.

PacketWave E510A, E520A and ES520A The PacketWave E510A, E520A and ES520A are cost-effective compact solutions that offer consolidated IP and TDM services over Resilient Packet Rings (RPR). The ES520A offers SONET/SDH services. It is a cost-effective compact solution that delivers the benefits of Resilient Packet Ring technology to legacy SONET networks.

PacketWave M-Series The ADTRAN PacketWave M-Series is a carrier-class optical access switch. The M-Series is a packet-optimized optical transport platform that supports the full spectrum of IP data and toll-quality voice services, enabling service providers to deploy very high-capacity, multi-service networks. The M-Series is a carrier-class optical access switch.The M-Series offers toll quality TDM interfaces (including T1/E1 and channelized OC-3/STM-1) and data interfaces (10/100 and Gigabit Ethernet) carried over RPR or a SONET/ SDH network. path End-to-end data connection defined by a source and destination address pair at any single layer.

Path Overhead (POH) Overhead assigned to and transported with the payload until the payload is demultiplexed. It is used for functions that are necessary to transport the payload.1

PBX See Private Branch Exchange (PBX).

Point of Presence (POP) A physical location where an interexchange carrier or ISP install equipment to interconnect with an LEC (local exchange carrier).

POP See Point of Presence (POP).

POS See Packet-Over-SONET (POS).

Private Branch Exchange (PBX) Digital or analog telephone switch located on the customer premises used to connect private and public telephone networks.

Quality of Service (QoS) Quality of Service is the concept that transmission rates, error rates, and other characteristics can be measured, improved, and to some extent, guaranteed in advance.

61440520E1-5B H-13 PacketWave E510A/E520A Installation and Configuration Guide

QoS See Quality of Service (QoS).

RADIUS See Remote Authentication Dial-In User Service (RADIUS).

Remote Authentication Dial-In User Service (RADIUS) RADIUS is a client/server protocol and software that enables remote access servers to communicate with a central server to authenticate dial-in users and authorize their access to the requested system or service.

Resilient Packet Ring Resilient Packet Ring (RPR) is a technological specification intended to optimize Ethernet-based metropolitan ring networks for packet transport with resiliency matching or exceeding that of SONET rings. RPR can carry voice and other TDM traffic with the QoS and resiliency of SONET and ATM combined, while supporting LAN traffic with the efficiency of Ethernet. The standard is defined by IEEE 802.17. See also Resilient Packet Transport.

Resilient Packet Transport Resilient Packet Transport (RPT) is ADTRAN’s version and a superset of the IEEE 802.17 Resilient Packet Ring (RPR) protocol standard. RPT includes support for Stratum-level synchronization over an asynchronous packet network, providing the efficiencies of packet networking while ensuring TDM and SONET/SDH synchronization, reliability, and quality of service. See also Resilient Packet Ring. ring Nodes linked in a ring topology and communicating between themselves. router On the Internet, a router is a device or, in some cases, software in a computer, that determines the next network point to which a packet should be forwarded toward its destination. The router is connected to at least two networks and decides which way to send each information packet based on the router’s current understanding of the state of the networks it is connected to. A router creates or maintains a table of the available routes and their conditions and uses this information along with distance and cost algorithms to determine the best route for a given packet.

RPR See Resilient Packet Ring.

RPT See Resilient Packet Transport.

RU Rack Unit. Unit of vertical space in an equipment rack. One rack unit is equal to 1.75 inches (4.45 cm).

SAN See Storage Area Network (SAN).

H-14 61440520E1-5B scalability It is the ability of a computer application or product to continue to function well as it is changed in size or volume in order to meet user needs.

SC Subscriber Connector – a general purpose push/pull style connector developed by NTT. The connector is square and keyed with push-pull mating, 2.5mm ferrule and molded housing for protection.

SDH Synchronous Digital Hierarchy. SDH (or STM-1) frames are made up of 270 bytes of 8 bits each by 9 rows. Each frame is transmitted in 125 μs.

Service Level Agreement (SLA) A SLA is a contract between a network service provider and a customer that specifies, usually in measurable terms, what services the network service provider will furnish.

Service Management Framework (SMF) The part of ADTRAN LMS that provides provisioning of services.

SFP Small Form-factor Pluggable shelf All equipment within a single chassis.

Simple Network Management Protocol (SNMP) SNMP is the protocol governing network management and the monitoring of network devices and their functions.

SLA See Service Level Agreement (SLA). slot A slot is the position of a physical front and back card in shelf. An M-Series has 19 slots; a C-Series has 9 slots. An E510A, E520A, or ES520A is considered to have 3 slots, although the slots refer to modules, not cards. slot type A parameter associated with a slot that defines the front and back (I/O) card combinations that the slot can host.

SMF See Service Management Framework (SMF).

SNMP See Simple Network Management Protocol (SNMP).

SONET Synchronous Optical Network. SONET refers to the rates and formats of the standard.1

61440520E1-5B H-15 PacketWave E510A/E520A Installation and Configuration Guide

SRC See Subtend Ring Card.

Storage Area Network (SAN) A SAN is a high-speed special-purpose network that interconnects different kinds of data storage devices with associated data servers on behalf of a larger network of users.

Subtend Ring Card A subtend ring card (SRC) connects a main ring to a subtending ring. switch In data telecommunications, a switch is a network device that selects a path or circuit for sending a unit of data to its next destination. Switches provide a unique network segment on each port, thereby separating collision domains. In general, a switch is a simpler and faster mechanism than a router, which requires knowledge about the network and how to determine the route.

SONET SONET is the U.S. (ANSI) standard for synchronous data transmission on optical media. The international equivalent of SONET is synchronous digital hierarchy (SDH). Together, they ensure standards so that digital networks can interconnect internationally and that existing conventional transmission systems can take advantage of optical media through tributary attachments. SONET defines a base rate of 51.84 Mb/s and a set of multiples of the base rate known as “Optical Carrier levels.” span Connection between two nodes on a ring.

SPE See Synchronous Payload Envelope (SPE). sub-port A “logical” port based on a physical port. Used for provisioning services on the PacketWave platforms.

Synchronous Optical Network (SONET) See SONET.

Synchronous Payload Envelope (SPE) Used by both SONET and SDH to carry the data in the signal. In SONET, it is a 500-μ s frame structure carried by the VT and composed of VT path overhead and bandwidth for payload. The envelope is contained within and can have any alignment with respect to the VT envelope capacity.1

Synchronous Transport Signal level 1 (STS-1) The basic (functional) module used to build SONET signals. An STS-1 has a bit rate of 51.84 Mb/s and may be converted to an OC-1 or STS-1 electrical interface signal, multiplexed with other modules to form a higher rate (STS-N) signal, or combined with other STS-1s to form an STS-Nc.1 See also Synchronous Transport Signal level N (STS-N).

H-16 61440520E1-5B Synchronous Transport Signal level N (STS-N) A (functional) module used to build SONET signals. An STS-N has a bit rate of Nx51.84 Mb/s and may be converted to an OC-N or STS-N electrical interface signal, or multiplexed with other modules to form a higher rate signal (in which case it is referred to as an STS-M).1 See also Synchronous Transport Signal level 1 (STS-1).

Syscon Acronym for System Controller card. system All equipment deployed at a node that is viewed by the network management system (NMS) as a single network element (NE). A system may be comprised of multiple shelves.

TCP See Transmission Control Protocol (TCP).

TDES Acronym for Triples DES. Triple DES is a block cipher formed from the Data Encryption Standard (DES) cipher by using it three times. Also known as TDEA (Triple Data Encryption Algorithm).

TDM See Time Division Multiplexing (TDM); see also TDM Private Line (TPL).

TDM Private Line (TPL) TPL is a cross connection (wire model service) between two ports. Local and remote cross connections can be created. TDM provisioning can be extended using TDM over Ethernet across multiple rings connected using Gigabit Ethernet ports.

TE See Traffic Engineering (TE).

Time Division Multiplexing (TDM) Technique where data from multiple channels may be allocated bandwidth on a single wire pair base on a time slot assignment.

TLS See Transparent LAN Services (TLS).

TLS-TE TLS-TE is a new service for providing L2 VPN connectivity. It is offered in addition to the existing TLS service (multipoint-to-multipoint unresourced service). TLS-TE is TLS with Traffic Engineering, which extends the existing TLS service by providing guaranteed traffic assurances and better control of bandwidth resources in the network. TLS-TE supports two classes of services, Assured Forwarding (AF) and Best Effort (BE). TLS-TE with AF provides a guaranteed assurance for the traffic within the L2 VPN. TLS-TE can also be used with BE to provide a better bandwidth provisioning model to conserve bandwidth and as a result support more services.

61440520E1-5B H-17 PacketWave E510A/E520A Installation and Configuration Guide

token ring A token ring network is a local area network in which all computers are connected in a ring or star topology and a bit- or token-passing scheme is used in order to prevent the collision of data between two computers that want to send messages at the same time.

TPL See TDM Private Line (TPL).

Traffic Engineering (TE) TE is the process of specifying paths that match certain criteria. The path need not follow the hop-by-hop routed path.

Transmission Control Protocol (TCP) TCP is a method used along with the IP to send data in the form of message units between computers over the Internet. While IP takes care of handling the actual delivery of the data, TCP takes care of keeping track of the individual units of data (called packets) that a message is divided into for efficient routing through the Internet.

Transparent LAN Services (TLS) TLS is a Layer 2 service providing LAN connectivity between various local and remote sites over the RPT ring. tributary interface Module interfaces from external traffic sources into a node. trunk Shared interface that up links aggregated traffic to upstream equipment. unavailable node In ADTRAN LMS, a node can be either unavailable or unmediated. If a node is unavailable, the node is in the topology and ADTRAN LMS has information about it, but currently cannot talk to it. See also unmediated node.

Unidirectional Path Switched Ring (UPSR) SONET protection ring topology that automatically protects against cable cuts, signal failure, or signal degrades. Traffic flows in one direction of the ring and is diverted to a backup ring in event of signal degradation.

UDP See User Datagram Protocol (UDP). unmediated node In ADTRAN LMS, a node can be either unavailable or unmediated. If a node is unmediated, the node is in the topology, but ADTRAN LMS does not have any information about it. See also unavailable node.

UPSR See Unidirectional Path Switched Ring (UPSR).

H-18 61440520E1-5B upstream bandwidth Upstream bandwidth is the bandwidth allocated to traffic flowing from the customer to the CO, POP, or WAN. The customer injects this traffic into the network.

User Datagram Protocol (UDP) A transport protocol in the Internet set of protocols. UDP, like TCP, uses IP for delivery. However, unlike TCP, UDP provides for exchange of datagrams without acknowledgements for guaranteed delivery.

Virtual Circuit A virtual circuit is a circuit or path between points in a network that appears to be a discrete, physical path but is actually a managed pool of circuit resources from which specific circuits are allocated as needed to meet traffic requirements.

Virtual LAN (VLAN) Group of devices on one or more LANs that are configured so that they can communicate as if they were attached to the same physical wire, when in fact they are located on a number of different LAN segments. VLANs are based on logical instead of physical connections.

Virtual Leased Line (VLL) An Ethernet Private Line (EPL) connection.

Virtual Private Network (VPN) VPN enables IP traffic to travel securely over a public TCP/IP network by encrypting all traffic from one network to another. A VPN uses “tunneling” to encrypt all information at the IP level.

Virtual Tributary (VT) A structure designed for transport and switching of sub-STS-1 payloads. There are currently four sizes of VT.

VLAN See Virtual LAN (VLAN).

VLL See Virtual Leased Line (VLL).

Voice over IP (VoIP) Method of carrying telephony-style voice traffic over an IP network.

VoIP See Voice over IP (VoIP).

VPN See Virtual Private Network (VPN).

VT See Virtual Tributary (VT).

61440520E1-5B H-19 PacketWave E510A/E520A Installation and Configuration Guide

WAN See Wide Area Network (WAN). See also Local Area Network (LAN).

Wide Area Network (WAN) A data communications network that serves users across a wide-ranging geographic area and often uses transmission devices provided by common carriers. Frame Relay, SMDS, and X.25 are examples of WANs. See also Local Area Network (LAN).

H-20 61440520E1-5B This page is intentionally blank.

61440520E1-5B H-21 ®

Carrier Networks Division 901 Explorer Blvd. Huntsville, AL 35806