830-00990-13 Configuration Guide for Software Version 1.14.1

MALC Configuration GuideMALC 723, MALC 719, and MALC 319

For software version 1.14.1November 2007Document Part Number: 830-00990-13

2 MALC Configuration Guide

Zhone Technologies@Zhone Way7001 Oakport StreetOakland, CA [email protected]

COPYRIGHT ©2000-2007 Zhone Technologies, Inc. and its licensors. All rights reserved.

This publication is protected by copyright law. No part of this publication may be copied or distributed, transmitted, transcribed, stored in a retrieval system, or translated into any human or computer language in any form or by any means, electronic, mechanical, magnetic, manual or otherwise, or disclosed to third parties without the express written permission from Zhone Technologies, Inc.

BAN, GigaMux, MALC, Raptor, SLMS, Z-Edge, Zhone, ZMS, and the Zhone logo are trademarks of Zhone Technologies, Inc.

Zhone Technologies makes no representation or warranties with respect to the contents hereof and specifically disclaims any implied warranties of merchantability, noninfringement, or fitness for a particular purpose. Further, Zhone Technologies reserves the right to revise this publication and to make changes from time to time in the contents hereof without obligation of Zhone Technologies to notify any person of such revision or changes.

http://www.zhone.com

mailto:[email protected]

MALC Configuration Guide 3

CONTENTS

About This Guide .............................................................................................................................11

Style and notation conventions............................................................................11Typographical conventions.....................................................................................11

Related documentation ...........................................................................................12Acronyms....................................................................................................................12Contacting Global Service and Support.............................................................13

Technical support....................................................................................................14Service requirements...............................................................................................14

Chapter 1 Basic Configuration..............................................................................................15

Configuration overview...........................................................................................15MALC default configuration ..................................................................................16Zhone SLMS Web Interface Tool features.............................................................17

Managing the MALC using Zhone Web User Interface ..................................19Logging into the serial (craft) port .......................................................................20Configuring a management interface..................................................................22

VLAN management interface .................................................................................22Uplink card 10/100 BaseT Ethernet interface.........................................................22ATM management connection................................................................................24Managing the MALC with ZMS.............................................................................25

Chapter 2 Configuring IP .........................................................................................................27

IP Overview ................................................................................................................27DNS.........................................................................................................................28DHCP......................................................................................................................29RIP ..........................................................................................................................29IP TOS support ......................................................................................................29

Fields in IP header............................................................................................30Source address based routing..................................................................................30

Applications ...............................................................................................................31Routing....................................................................................................................31

Host-based and network-based routing ............................................................32Host-based routing with DSL bridges.....................................................................34Host-based routing with DSL routers .....................................................................34

Contents


Network-based routing with DSL bridges ..............................................................35Network-based routing with DSL routers...............................................................36IP filtering ..............................................................................................................37Unnumbered IP interfaces.......................................................................................38

IP provisioning procedures ...................................................................................39Configuring a management IP interface .................................................................39Configuring host-based routing ..............................................................................41Configuring network-based routing........................................................................46Configuring RIP .....................................................................................................49Configuring static routes.........................................................................................50

Adding routes ...................................................................................................50Configuring the device as a DHCP server ..............................................................51

DHCP server profiles and scope ......................................................................51Setting DHCP server options ...........................................................................52Creating DHCP server subnet options..............................................................54Enabling a DHCP server ..................................................................................56

DHCP relay.............................................................................................................57TOS/COS processing ..............................................................................................59

802.1p priority queues......................................................................................60Fields in IP header............................................................................................60Fields in the VLAN header ..............................................................................60TOS/COS parameters .......................................................................................61

Advanced IP provisioning procedures ....................................................................62Advanced DHCP applications..........................................................................62Configuring DNS resolver................................................................................64Configuring IP filters........................................................................................66IP Service Level Agreement (IPSLA)..............................................................69

IP fallback route......................................................................................................78Configuring the MALC for IP video......................................................................82IP administrative procedures ................................................................................86

Modifying profiles created by host/interface add commands.................................87Displaying hosts......................................................................................................89Displaying interfaces ..............................................................................................90Displaying routing information...............................................................................90

Displaying the routing table .............................................................................90Displaying RIP information .............................................................................90

Deleting hosts..........................................................................................................91Deleting interfaces ..................................................................................................91Deleting routes ........................................................................................................91DHCP logging.........................................................................................................92

Understanding DHCP server log messages......................................................92IP statistics commands............................................................................................94

Chapter 3 Configuring Bridging ...........................................................................................95

Overview .....................................................................................................................95Bridge default settings for asymmetric bridges ..............................................99


Bridge default settings for symmetric bridges...............................................100Bridge enhancements to flood unknowns and multicasts .........................101

FloodUnknown parameter ....................................................................................101FloodMulticast parameter .....................................................................................102

Broadcasts and bridging ......................................................................................103TLS Bridging behavior for untagged, tagged, and s-tagged ......................103VLANs ........................................................................................................................105Q-in-Q.........................................................................................................................110

Configuring Q-in-Q using the Interface command...............................................111Configuring Q-in-Q using the Bridge command ..................................................112

Bridge path enhancements..............................................................................114Untagged bridging..................................................................................................114Ethernet RPR ...........................................................................................................116

Overview...............................................................................................................116RPR ring topology..........................................................................................117RPR ring topology with redundant GigE cards..............................................119RPR ring topology with redundant GigE cards and subtended MALCs........121

RPR configuration ................................................................................................123Linear GigaBit Ethernet ........................................................................................132

GigE-2 Uplink card redundant configuration in linear topology..........................134GigE-2 card bridging ............................................................................................135

PPPoA - PPPoE Conversion ................................................................................137PPPoE Intermediate Agent...................................................................................140Advanced bridging configurations ....................................................................142

Packet-rule records (Option 82, Forbid OUI, DHCP relay, PPPoE vendor tag) .143Tagged bridge—VLANs.......................................................................................145Broadcast suppression...........................................................................................146Bridge with DHCP relay.......................................................................................147

Administrative commands ...................................................................................149Bridge delete command ........................................................................................149Bridge show/showall commands ..........................................................................149Bridge stats............................................................................................................150

COS in bridges ........................................................................................................150Bridge profile ........................................................................................................150Video bridging ......................................................................................................152

Verifying bridge settings ................................................................................154

Chapter 4 Configuring ATM..................................................................................................157

Configuration overview.........................................................................................157Overview ...................................................................................................................158VPI/VCI ranges.........................................................................................................158

Changing VPI/VCI ranges ....................................................................................158Configuration overview ........................................................................................159

Contents


Configuring PCR and SCR values......................................................................160Creating traffic descriptors..................................................................................163Creating VCLs and VPLs ......................................................................................166

Creating cross connects.........................................................................................170Subtending ............................................................................................................172

Chapter 5 Configuring GR-303 or V5.2 Interface Groups ........................................177

Configuring a GR-303 interface .........................................................................177Modifying a GR-303 interface group ...................................................................182Displaying GR303 interface group status .............................................................183

Configuring a V5.2 interface ................................................................................183Creating a V5.2 interface group............................................................................187Finding the line group identifiers of the physical connection...............................188Provisioning V5.2 links ........................................................................................189Adding C-channels within links............................................................................190Provisioning C-paths.............................................................................................192Activating the V5.2 IG..........................................................................................194Modifying the v52-interface-group profile...........................................................194Displaying V5.2 interface group status.................................................................195

Chapter 6 Configuring Voice ...............................................................................................197

Overview ...................................................................................................................197Updating system settings ....................................................................................198

Setting a-law or mu-law and DSP settings ...........................................................198Checking bandwidth before accepting a voice call (AAL2).................................199

Creating voice connections .................................................................................200DS1 voice gateway connections ...........................................................................200Voice over IP (VoIP) connections ........................................................................203

SIP server configuration ................................................................................206MGCP configuration ......................................................................................209Additional VoIP features................................................................................215

AAL2 connections ................................................................................................228DS1 to POTS connections ....................................................................................230

Configuring CES connections ............................................................................233Creating CES connections ....................................................................................234

CES signaling .................................................................................................234CES clocking..................................................................................................235

CES configuration.................................................................................................236Additional voice features......................................................................................249

Setting ring cadence and call progress parameters ...............................................252Call progress tones for Canada .............................................................................255

Emergency StandAlone (ESA) SIP and TDM support .................................256Configuring VoIP ESA clusters............................................................................258Configuring ESA for 911 calls .............................................................................260


Verifying ESA ......................................................................................................261Configuring TDM ESA.........................................................................................261

T.38 fax ......................................................................................................................263T.38 fax using SIP.................................................................................................263T.38 fax using SIP PLAR to PSTN ......................................................................265T.38 using SIP PLAR to POTS fax ......................................................................266

Chapter 7 Configuring the Voice Gateway.....................................................................269

Overview ...................................................................................................................269Configuring voice gateway connections .........................................................270

VoIP to voice gateway connections......................................................................272Overview ........................................................................................................272Deleting voice gateway host and voice connection........................................277Deleting voice connection ..............................................................................277

Subtended MALC POTS VoIP voice gateway connections.................................277Overview ........................................................................................................278Deleting subtended voice connection ............................................................279

AAL2 voice gateway connections ........................................................................280Overview ........................................................................................................280

Deleting voice connection ....................................................................................289Subtended MALC ISDN or POTS voice gateway connections............................290

Configuring subtended AAL2 voice connection ...........................................291POTS cards running POTS to VoIP in same chassis as voicegateway card

293Voicegateway configuration .................................................................................293POTS to VOIP connections ..................................................................................296

Configuring SIP-PRI media gateway .................................................................297About the VoIP Endpoint......................................................................................299ISDN Signaling profile .........................................................................................300SIP trunks..............................................................................................................300Hardware requirements ........................................................................................300

Chapter 8 Configuring GPON Data,Voice, and Video ...............................................307

GPON configuration...............................................................................................307

Chapter 9 Diagnostics and Administration ...................................................................309

Logging .....................................................................................................................309Overview...............................................................................................................309Enabling/disabling logging ...................................................................................310Log message format..............................................................................................310Modifying logging levels......................................................................................312Using the log cache...............................................................................................313

Examples ........................................................................................................313Viewing the persistent logs...................................................................................314

Contents


Sending messages to a syslog server ....................................................................314Specifying different log formats for system and syslog messages .......................316Example log messages ..........................................................................................318

DSL line down message .................................................................................318Slot card up message ......................................................................................318

Log filter command...............................................................................................318SNMP..........................................................................................................................319

Creating SNMP community names and access lists .............................................320Creating a community profile.........................................................................320Creating community access lists ....................................................................320

Configuring traps ..................................................................................................321Statistics and alarms .............................................................................................322

Bulk statistics ........................................................................................................322Bulk statistics file format ...............................................................................323IF-Name in bulk stats (32 character limit) .....................................................326

Alarm manager......................................................................................................327Supported alarms............................................................................................328

ADSL low power alarm........................................................................................335Alarm suppression ................................................................................................336

System maintenance .............................................................................................337MALC file system.................................................................................................338

Accessing the flash card .................................................................................338Using the ata command ..................................................................................339Using the image command .............................................................................339

Changing the serial craft port settings ..................................................................339Deleting card profiles............................................................................................340Manually binding interfaces .................................................................................341Renaming interfaces..............................................................................................342Saving and restoring configurations .....................................................................343

SNTP ..............................................................................................................344User accounts ........................................................................................................344

Adding users...................................................................................................344Changing default user passwords ...................................................................345Deleting users .................................................................................................345Deleting the admin user account ....................................................................346Resetting passwords .......................................................................................346

Radius support ......................................................................................................347Viewing chassis and slot information ...................................................................350Controlling Telnet access......................................................................................352TFTP server support .............................................................................................353

Testing .......................................................................................................................353Activating or deactivating interfaces ....................................................................353BER tests...............................................................................................................354IMA test pattern procedure ...................................................................................356Loopbacks .............................................................................................................360

T1 loopbacks ..................................................................................................360SONET loopbacks..........................................................................................362DS3 loopbacks................................................................................................363


ISDN loopbacks .............................................................................................365Viewing IMA group status....................................................................................366

Appendix 10MALC ATM Overview .........................................................................................369

ATM overview ..........................................................................................................369ATM data ...................................................................................................................370ATM voice .................................................................................................................370ATM Video ................................................................................................................371Cross connects .......................................................................................................371Early packet discard (EPD) and partial packet discard (PPD)....................372Usage parameter control (UPC)..........................................................................372ATM validation.........................................................................................................372VPI and VCI ranges ................................................................................................373Virtual channel and virtual path links ...............................................................374Service categories..................................................................................................375

Constant bit rate (CBR) ........................................................................................375Non-real-time variable bit rate (nrt-VBR) ............................................................375Real-time variable bit rate (rt-VBR) .....................................................................376Unspecified bit rate (UBR) ...................................................................................376

Traffic descriptors ..................................................................................................376Configuring PCR and SCR ...................................................................................376Traffic descriptor parameters................................................................................377Traffic descriptor configuration rules ...................................................................379

Connection admission control (CAC) ...............................................................379CAC oversubscription...........................................................................................380Bandwidth allocation for ATM cards ...................................................................380Example CAC calculation.....................................................................................382

ATM traffic policing................................................................................................382Enforcing SCR and MBS......................................................................................382Enforcing PCR and CDVT ...................................................................................383General policing rules ...........................................................................................383

Traffic shaping ........................................................................................................383Shaping for non-ADSL2+ cards with GigE uplinks .............................................386Traffic shaping for 1.13.x and higher mixed IP and ATM networks ...................387

ATM statistics ..........................................................................................................387

Index ....................................................................................................................................................389

Contents



ABOUT THIS GUIDE

This guide is intended for use by technicians, system administrators, network administrators. It explains how to configure the MALC software features. For information on installing the MALC chassis and cards, refer to the MALC Hardware Instlallation Guide.

Style and notation conventionsThe following conventions are used in this document to alert users to information that is instructional, warns of potential damage to system equipment or data, and warns of potential injury or death. Carefully read and follow the instructions included in this document.

Caution: A caution alerts users to conditions or actions that could damage equipment or data.

Note: A note provides important supplemental or amplified information.

Tip: A tip provides additional information that enables users to more readily complete their tasks.

WARNING! A warning alerts users to conditions or actions that could lead to injury or death.

WARNING! A warning with this icon alerts users to conditions or actions that could lead to injury caused by a laser.

Typographical conventions

The following typographical styles are used in this guide to represent specific types of information.

About This Guide


Related documentationRefer to the following publication for additional information:

MALC Hardware Installation Guide—explains how to install the chassis and cards, and configure hardware interfaces.

Zhone CLI Reference Guide—explains how to use the Zhone command line interface (CLI) and describes the system commands and parameters.

Refer to the release notes for software installation information and for changes in features and functionality of the product (if any).

AcronymsThe following acronyms are related to Zhone products and may appear throughout this manual:

Bold Used for names of buttons, dialog boxes, icons, menus, profiles when placed in body text, and property pages (or sheets). Also used for commands, options, parameters in body text, and user input in body text.

Fixed Used in code examples for computer output, file names, path names, and the contents of online files or directories.

Fixed Bold Used in code examples for text typed by users.

Fixed Bold Italic

Used in code examples for variable text typed by users.

Italic Used for book titles, chapter titles, file path names, notes in body text requiring special attention, section titles, emphasized terms, and variables.

PLAIN UPPER CASE

Used for environment variables.

Command Syntax Brackets [ ] indicate optional syntax.Vertical bar | indicates the OR symbol.

Table 1: Acronyms and their descriptions

Acronym Description

ADSL Asymmetrical digital subscriber line

ARP Address resolution protocol

ATM Asynchronous Transfer Mode

BAN Broadband Access Node

Contacting Global Service and Support


Contacting Global Service and SupportContact Global Service and Support (GSS) if you have any questions about this or other Zhone products. Before contacting GSS, make sure you have the following information:

• Zhone product you are using

• System configuration

• Software version running on the system

• Description of the issue

CID Channel identifier

DSL Digital subscriber line

EFM Ethernet in the First Mile

SHDSL Symmetric high-bit-rate digital subscriber line

IAD Integrated access device

MALC Multi-access line concentrator

MIB Management information bases

MTAC Metallic Test Access Card

MTAC-FC Metallic Test Access Card with fan controller

PBX Private branch exchange

POTS Plain old telephone service

RIP Routing Information Protocol

SDSL Symmetric digital subscriber line

SHDSL Symmetric high-bit-rate digital subscriber line

SLMS Single Line Multi-Service

SNMP Simple Network Management Protocol

TFTP Trivial File Transfer Protocol

VCI Virtual channel identifier

VCL Virtual channel link

VPI Virtual path identifier

ZMS Zhone Management System

Table 1: Acronyms and their descriptions

Acronym Description

About This Guide


Technical support

If you require assistance with the installation or operation of your product, or if you want to return a product for repair under warranty, contact GSS. The contact information is as follows:

If you purchased the product from an authorized dealer, distributor, Value Added Reseller (VAR), or third party, contact that supplier for technical assistance and warranty support.

Service requirements

If the product malfunctions, all repairs must be performed by the manufacturer or a Zhone-authorized agent. It is the responsibility of users requiring service to report the need for service to GSS.

E-mail [email protected]

Telephone (North America) 877-ZHONE20

Telephone (International) 510-777-7133

Internet www.zhone.com/support

mailto:[email protected]

http://www.zhone.com/support


BASIC CONFIGURATION

This chapter describes how to perform the basic configuration of the MALC, including how to modify the default settings for the Uplink cards and how to enable slot cards. It includes the following sections:

• Configuration overview, page 15

• Logging into the serial (craft) port, page 20

• Configuring a management interface, page 22

Configuration overview

Note: For redundant systems, you must configure the physical interfaces on both the active and standby cards. In addition, you must manually keep the configuration of the physical interfaces on the active and standby cards in sync.

The following table describes where to find the information you need to configure the MALC.

Feature See

ADSL The MALC Hardware Installation Guide.

ATM cross connects Creating cross connects on page 170.

ATM data MALC ATM Overview on page 369 and Configuring ATM on page 157

ATM traffic descriptors Creating traffic descriptors on page 163.

ATM VCLs and VPLs Creating VCLs and VPLs on page 166.

Bridging Configuring IP on page 27

Clocking The MALC Hardware Installation Guide.

DS3/E3 Uplink card The MALC Hardware Installation Guide.

Ethernet interface The MALC Hardware Installation Guide.

GigaBit Ethernet The MALC Hardware Installation Guide.

GR-303 Configuring GR-303 or V5.2 Interface Groups on page 177

Basic Configuration


MALC default configuration

This default configuration of the MALC is as follows:

• Administrative user name is admin, password is zhone.

• Slot cards (except the Uplink card) must be enabled in a card-profile before they will boot up.

• A single record for the Ethernet interface on the Uplink card exists. No other profiles to configure physical interfaces exist.

• A default system profile 0 exists with the following configuration:

– Authentication traps are not enabled

– ZMS communication is not configured

IMA groups The MALC Hardware Installation Guide.

IP Configuring IP on page 27.

IP video Configuring the MALC for IP video on page 82.

Linear GigaBit Ethernet

Linear GigaBit Ethernet on page 132

Management interface Configuring a management interface on page 22.

MTAC/Ring card The MALC Hardware Installation Guide.

OC-3c/STM1 The MALC Hardware Installation Guide.

PON The MALC Hardware Installation Guide.

POTS The MALC Hardware Installation Guide.

RPR Ethernet RPR on page 116.

SHDSL card The MALC Hardware Installation Guide.

Slot cards The MALC Hardware Installation Guide.

SNMP SNMP on page 319.

Subtending Subtending on page 172.

T1/E1 CES Configuring CES connections on page 233.

T1/E1 IMA and TDM Uplink cards

The MALC Hardware Installation Guide.

V5.2 interface groups Configuring a V5.2 interface on page 183.

VDSL The MALC Hardware Installation Guide.

VLANs VLANs on page 105.

Voice Configuring Voice on page 197.

Feature See



– Alarm notification and output is enabled for all severity levels

Zhone SLMS Web Interface Tool features

The MALC enables Web-based configuration using the Zhone SLMS Web Interface Tool. The Zhone SLMS Web Interface Tool supports Malc723, Malc719, Malc319 configuration and management using the following cards for 1.13.2 and earlier features:

MALC uplink cards:

• MALC-UPLINK-2-GE cards

• MALC-UPLINK-2-FE/GE cards

MALC downlink cards:

• ADSL cards

MALC-ADSL-32A (single-slot AC6 ADSL)

MALC-ADSL-48B (single slot ADSL Annex B)

MALC-ADSL-48A (single slot ADSL Annex A)

MALC-ADSL+POTS-TDM-48A-2S (two slot ADSL Annex A with TDM POTS)

MALC-ADSL+POTS-TDM/PKT-48A-2S (two slot ADSL Annex A with TDM POTS and packet voice support)

MALC-ADSL-48A/M

MALC-ADSL+POTS-TDM-48A/M-2S (two slot ADSL Annex A with TDM POTS)

MALC-ADSL+POTS-PKT-48A/M-2S (two slot ADSL Annex A with TDM POTS and packet voice support)

MALC-ADSL+POTS-TDM-48-2S (two slot ADSL with TDM POTS)

MALC-ADSL+SPLTR-48A/M-2S (two slot ADSL Annex A/M with splitter)

• DS3/E3 cards

MALC-DS3/E3-4 * No port provisioning

• GPON cards

MALC-GPON-SC1

• G.SHDLS cards

MALC-G.SHDSL-4W-12

MALC-G.SHDSL-24

MALC-SHDSL-48

• ISDN cards

Basic Configuration


MALC-ISDN2B1Q-24 * No port provisioning

• MTAC cards

MALC-MTAC/RING-ENH

MALC-MTAC/RING-FC (MALC 319 only)

MALC-MTAC/RING

• POTS cards

MALC-POTS-GBL-TDM/PKT-24

MALC-POTS-TDM/PKT-48(single slot with POTS TDM and packet voice support)

MALC-POTS-TDM-48(single slot with POTS TDM voice support)

• POTS cards

MALC-POTS-GBL-TDM/PKT-24

MALC-POTS-TDM/PKT-48(single slot with POTS TDM and packet voice support)

MALC-POTS-TDM-48(single slot with POTS TDM voice support)

• T1/E1 cards

MALC-T1/E1-ATM-32

MALC-T1/E1-CES-12 * No Add card or provisioning

MALC-EFM-T1/E1-24 * No Add card or provisioning

• Voicegateway cards

MALC-VG-T1/E1-32-2S

MALC-VG-T1/E1-8-2S

Features not currently supported in the Web Interface Tool:

• Voice connection through uplink RPR ports.

• GR303 voice connection through uplink RPR ports. Only GR303-VG allowed.

• V5.2 interface, voice provisioning, and connection table support.

• VoIP to V5.2 provisioning.

• ISDN port provisioning.

• ISDN voice provisioning and connection table.

• ATM T1 IMA provisioning.



• AAL2 support.

Managing the MALC using Zhone Web User InterfaceTo manage the MALC using the Zhone Web User Interface:

• Add an IP address to the interface to be used for management.

On the MALC-UPLINK-2-GE uplink or MALC-UPLINK-2-FE/FE uplink cards, the interface on the 10/100 Ethernet port or GigE ports can be used. Ensure that the IP address is in the same subnet as the client devices and is reachable through Telnet. This example adds an IP interface for 172.24.94.103 to the 10/100 Ethernet port using VLAN 94.

zSH> interface add 1-1-1-0/ethernetcsamcd vlan 94 172.24.94.103/24Created ip-interface-record ethernet1-94/ip

• Configure a default route to the IP interface.

The default route enables connectivity to the IP interface.

zSH> route add default 94 172.24.94.103 metric 1

Note: A cross-over cable is required to manage the MALC from the 10/100 or GigE port.

To launch the Zhone Web User Interface, in a browser URL address space on a PC with connectivity to the MALC, enter the IP address configured on the MALC.

The Zhone Web User Interface launches and displays the Login window for the MALC.

Basic Configuration


Figure 1: Zhone Web User Interface Login Screen

On the Login page, enter the user name and password. The default user name is admin and the default password is zhone.

Click the desired menu to display the management options. For online help,

click the Help icon or product title in any window.

Note: The del command can be used to delete all of the Zhone Web User Interface files if needed.

Logging into the serial (craft) port

Note: Do not use the serial craft port of a standby card to modify its configuration.

The MALC unit provides an out-of-band RS232 D serial (craft) interface for managing the unit. To access the serial port, configure your terminal interface software with the following settings:

• 9600bps

Logging into the serial (craft) port


• 8 data bits

• No parity

• 1 stop bit

• No flow control

Tip: The serial (craft) port settings can be changed by modifying the rs232-profile.

You must perform the initial configuration of the system using the serial (craft) interface. After you have completed the initial configuration, you can manage the MALC unit over the network through a telnet session over the Ethernet interface or over the management Permanent Virtual Circuit (PVC).

Note: The MALC supports 6 concurrent management sessions, 5 telnet sessions and a single local session through the serial (craft) port.

Logging in and out of the systemLog into the system (the default user name is admin, the default password is zhone):

login:adminpassword: zSH>

To log out of the system, enter the logout command:zSh> logout

Tip: The system automatically logs you out after a period of inactivity. The default logout time is 10 minutes, but can be changed with the timeout command. Refer to Zhone CLI Reference Guide for information on the timeout command.

Enabling and disabling loggingBy default logging is enabled on the serial craft port and disabled over telnet sessions. To enable or disable logging for the session, using the following command:zSh> log session on | off

The log session command only applies to the current session. You can also enable or disable logging for all serial craft port sessions using the following command:zSh> log serial on | off

This command setting persists across system reboots.

Basic Configuration


Configuring a management interfaceThis section describes how to configure the following interfaces to remotely manage the MALC:

• VLAN management interface on page 22

• Uplink card 10/100 BaseT Ethernet interface on page 22

• ATM management connection on page 24

• Managing the MALC with ZMS on page 25

Note: Ethernet interfaces can be addressed as either eth or ethernetcsmacd. The eth abbreviation is used in command output.

VLAN management interface

To create a management interface over the first GigE port, use the interface add command and specify a VLAN:

zSH> interface add 1-1-2-0/ethernetcsmacd vlan 99 10.10.10.1/24Created ip-interface-record ethernet1-99/ip

Uplink card 10/100 BaseT Ethernet interface

The MALC has a 10/100 BaseT Ethernet interface on the Uplink card. The ip-interface-record for the Uplink card is named ethernet1. This interface is shared between the two Ethernet ports on redundant Uplink cards (if they exist). The system can be reached using the address configured in the ethernet1 ip-interface-record, no matter which card is active.

Caution: The Uplink card Ethernet interface must be configured before any other interfaces on the system, even if you do not intend to manage the unit over the Ethernet.

Configuring the Ethernet IP interfaceThe following example configures the IP address for the system:

zSH> interface add 1-1-1-0/ethernetcsmacd static 192.168.8.21 255.255.255.0Created ip-interface-record ethernet1/ip

Note: If you have problems with IP interfaces not automatically binding, refer to for more information.

Verifying the interfaceUse the interface show command to verify that the Ethernet interface was configured correctly:

Configuring a management interface


zSH> interface showInterface Status Rd/Address Media/Dest Address IfName---------------------------------------------------------------------------1/1/1/0/ip UP 1 192.168.8.21/24 00:01:47:65:02:f2 1-1-1-0

Creating a default routeThe following example creates a default route using the gateway 192.168.8.1 with a cost of 1 (one):route add default 192.168.8.1 1

Verifying the routeUse the route show command to verify that the routes were added:

zSH> route showDest Nexthop Cost Owner------------------------------------------------------------0.0.0.0/0 192.168.8.1 1 STATICLOW192.168.8.0/24 1/1/1/0/ip 1 LOCAL

Use the ping command to verify connectivity to the default gateway:zSH> ping 192.168.8.1PING 192.168.8.1: 64 data bytes!!!!!----192.168.8.1 PING Statistics----5 packets transmitted, 5 packets receivedround-trip (ms) min/avg/max = 0/0/0

To stop the ping, press CTRL+C.

Adding a route to the remote LANAfter creating the IP interface, you might need to create a route to the remote device’s LAN interface using the route add command. The command uses the following syntax:

route add destination mask next-hop cost

For example, in the following configuration, add a route to the 192.168.10.0 network using the MALC Uplink interface as the gateway.

Basic Configuration


Figure 2: Adding a remote route to LAN

route add 192.168.10.0 255.255.255.0 192.168.8.1 1

ATM management connection

The MALC can terminate an ATM PVC and route it over an Ethernet interface for management traffic.

The following table summarizes the configuration tasks for creating an ATM management connection.

Creating the ATM traffic descriptorCreate a new atm-traf-descr profile and specify a unique index:

zSH> new atm-traf-descr 200Please provide the following: [q]uit.td_type: ------------- {atmNoClpNoScr}: enter traffic descriptor typetd_param1: ----------- {0}: enter PCR td_param2: ----------- {0}: enter PCR (for CLP=0 traffic) or SCRtd_param3: ----------- {0}: enter MBS td_param4: ----------- {0}: enter CDVTtd_param5: ----------- {0}:cac-divider: -------------> {1}:td_service_category: - {ubr}: rtvbr | nrtvbr | ubr | cbrtd_frame_discard: --------> {false}:usage-parameter-control: -> {true}:

ATM

192.168.8.21 192.168.8.1192.168.10.0

Task Command

Create a traffic descriptor. See Creating the ATM traffic descriptor on page 24.

new atm-traf-descr index

Multiple connections can use the same traffic descriptors and a single VCL must use the same traffic descriptor for both transmit and receive.

Create the VCL. See Creating the ATM management VCL on page 25.

interface add interface/atm vc vpi/vci td td_index static IpAddress Netmask

This command creates the ATM VCL and the IP interface for the management PVC.

Add a route to the Ethernet interface. See Adding a default route to the ATM network on page 25.

route add destination netmask nexthop cost

This enables the MALC to route from the IP management interface to the Ethernet interface

Configuring a management interface


....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Creating the ATM management VCLThe following example configures an ATM connection with a VPI/VCI of 0/35 that uses the atm-traf-descr profile you just configured (with an index of 200). The VCL uses the Uplink interface:

zSH> interface add uplink1/atm vc 0/35 td 200 static 192.168.1.1 255.255.255.0Created ip-interface-record uplink1-0-35/ip

This command creates the ip-interface-record and the associated VCL:

zSH> list ip-interface-recordip-interface-record ethernet1/ipip-interface-record uplink1-0-35/ip2 entries found.

zSH> list atm-vclatm-vcl uplink1/atm/0/351 entry found.

Adding a default route to the ATM networkAfter adding the IP interface for management, create a default route to the ATM network:

route add default 192.168.1.254 1

Verifying the interfaceUse the interface show command to verify that the interfaces are active:

zSH> interface showInterface Status Rd/Address Media/Dest Address IfName---------------------------------------------------------------------------------1/1/1/0/ip UP 1 192.168.8.21/24 08:00:3e:03:02:01 1-1-1-0 1/1/2/0/ip UP 1 192.168.1.1/24 0/35 uplink1-0-35---------------------------------------------------------------------------------2 interfaces

Managing the MALC with ZMS

Note: For details on using ZMS, refer to the ZMS Administrator's Guide and the NetHorizhon User's Guide.

The system profile contains parameters that configure the system contact information for the MALC and connection information for the ZMS. This profile does not need to be modified in order to manage the MALC with ZMS.

Basic Configuration


CLI provisioning and ZMSMaking a change to the device configuration

CLI configuration of a device being managed by the ZMS is disabled by default. Attempting to configure the device results in an error:

If you plan to use a script to provision the device from the CLI while it is being managed by the ZMS:

1 Update the system profile to disable partial config syncs to ZMS:

zSH> update system 0Please provide the following: [q]uit.syscontact: ----------> {Zhone Global Services and Support 7001 Oakport Road Oakland Ca. (877) Zhone20 (946-6320) Fax (510)777-7113 [email protected]}:sysname: -------------> {Zhone MALC}:syslocation: ---------> {Oakland}:enableauthtraps: -----> {disabled}: setserialno: ---------> {0}:zmsexists: -----------> {true}: falsezmsconnectionstatus: -> {inactive}:zmsipaddress: --------> {192.168.210.28}:configsyncexists: ----> {false}:configsyncoverflow: --> {false}:configsyncpriority: --> {high}:configsyncaction: ----> {noaction}:configsyncfilename: --> {192.168.8.21_4_1014067321329}:configsyncstatus: ----> {synccomplete}:configsyncuser: ------> {cfgsync}:configsyncpasswd: ----> {}: ** private ** numshelves: ----------> {1}:shelvesarray: --------> {}:numcards: ------------> {3}:ipaddress: -----------> {192.168.8.21}: alternateipaddress: --> {0.0.0.0}:countryregion: -------> {us}:primaryclocksource: --> {0/0/0/0/0}:ringsource: ----------> {internalringsourcelabel}:revertiveclocksource: -> {true}voicebandwidthcheck: --> {false} ....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

2 After the provisioning is complete, perform a full config sync from ZMS.


CONFIGURING IP

This chapter explains IP services on the MALC. It includes the following sections:

• IP Overview, page 27

• Applications, page 31

• IP provisioning procedures, page 39

• Advanced IP provisioning procedures, page 62

• Configuring the MALC for IP video, page 82

• IP administrative procedures, page 86

IP OverviewThe MALC provides the following IP services:

• IP forwarding and routing—incoming packets from an interface are forwarded to the appropriate output interface using the routing table rules.

• DHCP servers to simplify user IP address configuration.

• IP filtering. IP filtering is typically performed to enhance network security by limiting access between two networks.

• Numbered or unnumbered (floating) interfaces

• Telnet client

• IP TOS

• Source address based routing

• IP redundancy

The following MALC interfaces support IP traffic:

• One Ethernet interface on the Uplink card for management traffic or subscriber traffic.

• The ATM/IP Uplink cards are required for IP services on MALC. The ATM/IP Uplink card terminates the IP traffic.

• DSL interfaces. IP on DSL runs over ATM PVCs using RFC 1483 encapsulation.

Configuring IP


Note: IP features may not be supported on your device. Contact GSS about enabling IP features.

The Internet protocol (IP) allows devices to communicate over interconnected networks. IP is a layer 3 protocol in the seven-layer Open Systems Interconnection (OSI) model. Layer 3, or network layer, handles the delivery of data packets from source to destination. Any device connected to a network is considered a host or a node on that network. Zhone devices with IP capability can act as routers to accept network traffic and forward it on to host destinations based on IP addressing. To get from source to destination, the IP packet passes through many nodes, or hops, along the way. All routers maintain routing tables of the sequence of hops taken from source to destination. The routing table is used by the router to direct datagrams most efficiently. The routing table information is also shared with other routers on the same network.

Figure 3: IP stacking on Zhone devices

The following IP protocols are supported on the MALC.

DNS

Domain Name System (DNS) maps domain names to IP addresses, enabling the system to reach destinations when it knows only the domain name of the destination.

IP

IP

Layer 3

ETHERNET RFC1 483 ATM CC ETHERNETLayer 2

TWISTED PAIR

DSL CATEGORY 5 CABLE

Layer 1

SAR SAR

IP Overview


DHCP

The Dynamic Host Control Protocol (DHCP) provides a mechanism through which client computers using TCP/IP can obtain configuration parameters (such as the default router and the DNS server, subnet mask, gateway address, and lease time) from a DHCP server. The most important configuration parameter carried by DHCP is the IP address.

As a DHCP server, MALC can assign temporary (leased) IP addresses to client PCs. Each DHCP client PC sends a request to the MALC for an IP address lease. The MALC then assigns an IP address and lease time to the client PC. The MALC keeps track of a range of assignable IP addresses from a subnetwork.

Some customers prefer to have the same IP address every time their DHCP lease renews. This is known as sticky IP addresses. By default, the MALC attempts to assign the same IP address to the same client on DHCP lease renewal.

With shared DHCP pools (or subnet groups), DHCP servers are not linked to physical interfaces. Customers can easily configure an arbitrary number of DHCP pools. Zhone devices can assign blocks of IP addresses specifically for certain customers.

RIP

Routing Information Protocol (RIP), an interior gateway protocol (IGP), is widely used for routing traffic on the Internet. RIP performs routing within a single autonomous system. It is based on distance-vector algorithms that measure the shortest path between two points on a network. The shortest path is determined by the number of hops between those points. RIP routers maintain only the best route (the route with the lowest metric value) to a destination. After updating its routing table, the router immediately begins transmitting routing updates to inform other network routers of the shortest route.

Routing Information Protocol version 2 (RIPv2) is the latest enhancement to RIP. RIPv2 allows more information to be included in RIP packets and provides an authentication mechanism.

IP TOS support

The MALC now supports IP QOS. This service enables you to assign a service level or type of service (TOS) to an IP interface. The configured TOS level specifies the packet priority and queueing methods used to transport the packet through the IP network.

The MALC originates and preserves the TOS settings to ensure these settings are passed to other IP devices in the network.

Configuring IP


Fields in IP headerIP packets have a TOS byte in their headers that contains information about relative priority. The TOS byte is divided into two fields called IP Precedence and TOS. The IP Precedence field contains a 3-bit priority designation. Most normal traffic has an IP Precedence value of zero. Higher values in this field indicate that traffic is more important and that it requires special treatment. IP Precedence values greater than 5 are reserved for network functions.

The TOS field indicates the queueing priority or Class of Service (COS) value based on eight (0-7) levels of service. This field contains information about how the traffic should be forwarded. The MALC supports basic TOS marking without queue servicing options in the ip-interface-record profile. Packets marked based on a configurable profile to let the system know which bits use which queue.

Note: TOS bits are not altered for VoIP Real Time Transport Protocol (RTP) packets, which have their own TOS bit settings set in the voip-server-entry profile regardless of the TOS setting on the outgoing interface.

Table 2 specifies the IP TOS settings used in the voip-server-entry profile based on IP Precedence bits.

Source address based routing

Source Address Based Routing (SABR) adds flexibility to route planning for network administrators and allows the MALC to forward outbound VoIP SIP traffic based on a specific source IP address of a data packet instead of the destination IP address.With SABR routing, the source IP address or subnet address of a data packet is examined before packet forwarding. If the device finds a matching source route in the source routing table, the packet is forwarded according to the matched source route. If the device does not find a

Table 2: IP TOS settings and IP Precedence bits

Precedence Bits TOS value

0 (Routine) 0

1 (Priority) 32

2 (Immediate) 64

3 (Flash) 96

4 (Flash override) 128

5 (CRITIC/ECP.) 160

6 (Internetwork control) 192

7 (Network control) 224

Applications


matching source route, destination routing is performed based on the destination routing table and if necessary the configured default route.

Note the following about SABR support on the MALC:

• SABR routing is only supported on AAL5 Virtual Channel Links (VCLs) using Logical Link Connections (LLC) encapsulation

• The ping and traceroute commands support SABR

• SABR is only supported for VoIP SIP

• The route commands use the source keyword to indicate that a source route is used.

Note: For existing configurations with static routes, users must either:

• use the dump and restore commands to backup and restore the configuration after upgrading to this release.

• delete all the existing static routes after upgrading to this release, but before rebooting the system. After rebooting the system, static routes must be manually provisioned.

ApplicationsThe following IP applications are supported on the MALC:

• Routing on page 31

• Host-based routing with DSL bridges on page 34

• Host-based routing with DSL routers on page 34

• Network-based routing with DSL bridges on page 35

• Network-based routing with DSL routers on page 36

• IP filtering on page 37

• Unnumbered IP interfaces on page 38

Routing

Routing is the process of selecting a next hop for forwarding data traffic. The routing information base (RIB) contains all the information about the routes in the system, including the preference values and interface states. The forwarding information base (FIB) is derived from the RIB and only contains the best route to a given destination.

IP routing through the system makes use of the following types of routes:

• Interface routes—These routes are defined by the addresses and netmasks that are provisioned on the IP interfaces.

Configuring IP


• Static routes—These routes are manually configured as either destination based or source address based routes (SABR). Destination routes define paths to destinations in terms of an interface identifier or the IP address of a next-hop router on a directly attached network. SABR enables the forwarding of outbound VoIP SIP traffic based on a specific source IP address of a data packet instead of the destination IP address.With SABR routing, the source IP address or subnet address of a data packet is examined before packet forwarding. If the device finds a matching source route in the source routing table, the packet is forwarded according to the matched source route. If the device does not find a matching source route, destination routing is performed based on the destination routing table and if necessary the configured default route.

There are two kinds of static routes:

– Low preference—These routes are only used to define default routes (that is, routes of last resort) and are less preferable to most other routes.

– Normal preference—All other static routes are considered more preferable than other types of routes (with the exception of interface routes).

• Dynamic routes—These routes are learned by running routing protocols, such as RIP, and have varying preferences, depending on how they were learned.

The following table describes the default routing preferences on the device. These preferences cannot be overridden. Higher numbers indicate more preferred route types:

Host-based and network-based routingThe MALC supports both host-based routing and network-based (subnet) routing.

Host-based routing uses a unnumbered interface and adds a single IP address to the routing table for each route. This type of routing allows a granular allocation of addresses based on the host floating (unnumbered) IP address and the available subnetwork addresses. Routes are configured individually using the host add command. For each configured route, an IP address is added to the routing table. For example, an unnumbered host address of 10.10.10.1/24, adds one entry in the routing table for the address 10.10.10.1

Type of route Default preference

Local 10

Static 9

RIP 4

Static low(used for default routes)

4

Applications


and makes available a subnet of 254 addresses for individual route configuration. When each host route is added, a new routing table entry is created. The host add command can also assign VLAN, SLAN, and COS values to the host interface. In the host add, host modify and host delete commands, <slot> and <port> may be replaced with brackets containing numbers in series and/or (dash-separated) ranges; <port> may be replaced with wildcard '*' for all ports on the card.

The host modify command enables you to change individually configured routes for a host-based routing environment by altering values in the existing routing table entry. Refer to the CLI Reference Guide for a complete description of the command options and syntax.

Note: In the host modify command, <slot> and <port> may be replaced with brackets containing numbers in series and/or (dash-separated) ranges; <port> may be replaced with wildcard ‘*’ for all ports on the card.

Examples: 1-[10-13]-[1,3-5,21]-0/ds3 specifies DS3 ports 1,3,4,5,21 on cards 10,11,12, and 13.1-[6,7,9]-*-0/adsl specifies all ADSL ports on cards 6, 7, and 9

Network-based (subnet) routing uses a numbered interface and adds IP network addresses with variable length subnet masks to the routing table. This type of routing allows a single routing table entry to represent many numbered host addresses. However, it does not allow for granular IP address allocation. For example, an interface configured with 10.10.10.1/24 adds just one entry to the routing table for 10.10.10.1/24. All 254 addresses in this subnet are assigned to this interface, regardless of how many addresses in this subnet are actually used.

The command used to create the IP interface depends on the application, IP assignment, type of address allocation and interface type. Commands to add an IP interface on page 33 shows the commands to add an IP interface and the requirements.

Table 3: Commands to add an IP interface

Command Application IP Assignment Address Allocation

Encapsulation Interface Type

Host add Host-based routing with DSL bridge or router

Static/Dynamic Single per host add command

For bridge: otherFor router: LLC

Unnumbered

Interface add Network-based routing with DSL bridge or router

Static Multiple based on subnet mask length

For bridge: otherFor router: LLC

Numbered

Configuring IP


Host-based routing with DSL bridges

Host-based routing takes advantage of IP unnumbered interfaces and shared DHCP pools to conserve IP addresses. In the host-based routing with DSL bridges application, subscribers connected to the MALC are on the same subnet as the MALC unnumbered interface.

Figure 4: Host-based routing with DSL bridges

Host-based routing with DSL routers

In the host-based routing with DSL routers application, remote IADs (or routers) are on the same subnet as the MALC unnumbered interface. The IADs connect private networks to the MALC.

Bridge

Bridge

IP

subscriber A

subscriber B

x.x.y.2

PC

x.x.y.3

PC

x.x.y.1

Applications


Figure 5: Host-based routing with DSL routers

Network-based routing with DSL bridges

Network-based routing is ideal for adding large numbers of IP addresses. Unlike host-based routing, network based-routing requires numbered IP interfaces on the MALC. In network-based routing with DSL bridges application, each bridge is in the same network as one of the MALC numbered interfaces.

NAT router

NAT router

IP

Private network

Private network

x.x.a.1

x.x.y.1

Public subnet

x.x.a.2

x.x.b.1

x.x.b.2

x.x.y.2

x.x.y.3

Configuring IP


Figure 6: Network-based routing with bridges

Network-based routing with DSL routers

Network-based routing with DSL routers allows multiple statically assigned addresses per customer. In this application, each remote router is on a subnet with a numbered interface on the MALC.

Bridge

Bridge

IP

x.x.y.2

x.x.z.1/24

x.x.y.1/24

x.x.y.3

x.x.z.2

x.x.z.3

Applications


Figure 7: Network-based routing with routers

IP filtering

IP filtering is typically performed to enhance network security by limiting access between two networks. IP filtering is based on the recognition and selective transmission or blocking of individual IP packets. Packets meeting some criterion are forwarded, and those that fail are dropped. IP filtering is used to block inbound traffic to the management network.

NAT router

NAT router

IP

Private network

Private network

a.b.c.1

x.x.z.1

Public subnet

a.b.c.2

d.e.f.1

d.e.f.2

x.x.y.1

d.e.f.0/30

a.b.c.0/30

Configuring IP


Figure 8: IP filtering

IP filtering allows or denies IP packets based on:

• source IP address

• destination IP address

IP filtering can be provisioned from the CLI by using the filter command and modifying the ip-interface-record where you wish to apply the filter.

Unnumbered IP interfaces

Unnumbered IP interfaces reduce the number of IP addresses used by a device. Unnumbered interfaces are just like other point-to-point connections, except a “floating” or virtual IP interface is used as the local IP address in the ip-interface-record.

Management network Internet

Subscribers

Filter

IP provisioning procedures


Figure 9: Unnumbered IP interfaces

IP provisioning proceduresThis section includes the following procedures:

• Configuring a management IP interface on page 39

• Configuring host-based routing on page 41

• Configuring network-based routing on page 46

• Configuring RIP on page 49

• Configuring static routes on page 50

• Configuring the device as a DHCP server on page 51

• TOS/COS processing on page 59

• IP fallback route on page 78


Configuring a management IP interface

Caution: The Uplink card Ethernet interface must be configured before any other interfaces on the system, even if you do not intend to manage the unit over the Ethernet.

Configuring an Ethernet connection 1 Enter the interface add command with the following options. Refer to

the CLI Reference Guide for a complete description of the command options and syntax.

zSH> interface add 1-1-1-0/ethernetcsmacd 10.10.10.10 255.255.255.0Created ip-interface-record ethernet1/ip

Point to point connection

Shared or “floating”IP address

Unnumbered IP interface

Configuring IP


This example:

– creates an ip-interface-record on ethernet1/ip

– adds host 10.10.10.10.

– sets netmask as 255.255.255.0.

2 Verify that the Ethernet connection is active.

zSH> interface showInterface Status Rd/Address Media/Dest Address IfName--------------------------------------------------------------------------------1/1/1/0/ip UP 1 10.10.10.10/24 00:01:47:bb:d5:f1 ethernet1--------------------------------------------------------------------------------1 interface

or ping the host

zSH> ping 10.10.10.10PING 10.10.10.10: 64 data bytes!!!!!

Note: If necessary, you can modify the ip-interface-record on the Uplink card to change the settings created by the interface add command.

Creating a default routeThe following example creates a default route using the gateway 192.168.8.1 with a cost of 1 (one):route add default 192.168.8.1 1

Verifying the route1 Use the route show command to verify that the routes were added:

zSH> route showDest Nexthop Cost Owner------------------------------------------------------------0.0.0.0/0 192.168.8.1 1 STATICLOW192.168.8.0/24 1/1/1/0/ip 1 LOCAL

Use the ping command to verify connectivity to the default gateway:

zSH> ping 192.168.8.1PING 192.168.8.1: 64 data bytes!!!!----172.24.200.254 PING Statistics----4 packets transmitted, 4 packets receivedround-trip (ms) min/avg/max = 0/0/0

The ping command stops after 5 transmits.



2 Use the route list command to display all configured static routes.

zSH> route listDomain Dest Mask Nexthop IfNum Cost Enable---------------------------------------------------------------------------------1 0.0.0.0 0.0.0.0 172.24.94.254 0 1 enabled1 172.24.64.0 255.255.255.0 172.25.64.64 0 1 enabled1 172.24.64.0 255.255.255.0 172.25.64.129 0 2 enabled1 10.212.0.0 255.255.0.0 10.2.1.254 0 1 enabled

Configuring host-based routing

Host-based routing interoperates with DSL bridges and routers. The type of AAL5 encapsulation determines interoperability with DSL routers or DSL bridges. LLC encapsulation is used with DSL routers; RFC 1483 encapsulation is used with DSL bridges. Specify LLC encapsulation (llc) in the command line for host-based routing to DSL routers. If no encapsulation type is specified in the command line, RFC 1483 encapsulation (other) is the default.

The following table summarizes the configuration tasks for configuring host-based routing:

Configuring host-based routing with DSL routers1 Create an atm-traf-descr for unnumbered interfaces:

zSH> new atm-traf-descr 100Please provide the following: [q]uit.td_type: -----------------> {atmNoClpNoScr}:td_param1: ---------------> {0}: 106133td_param2: ---------------> {0}: 38td_param3: ---------------> {0}:

Task Command

Create an atm-traf-descr. new atm-traf-descr index

Where index is a user-defined value.

Create the IP interface record for the specified unnumbered (floating) interface.

interface add float interfacename IPaddr netmask

Where interfacename is the name assigned to the IP record and IPaddr and netmask are the IP address and network mask assigned to the interface.

Create subnet groups. dhcp-relay add index


Configure a connection to a host. host add index/type vc vpi/vci td tdvalue other | llc static x.x.x.x | dynamic subnetgroup count

This command creates the VCL and IP interface for the host route.

Verify provisioning host show index/type vc vpi/vci td tdvalue dynamic subnetgroup count

Configuring IP


td_param4: ---------------> {0}:td_param5: ---------------> {0}:cac-divider: -------------> {1}: td_service_category: -----> {ubr}:td_frame_discard: --------> {false}:usage-parameter-control: -> {true}:....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

2 Create an floating (unnumbered) IP interface with the desired IP interface record for the IP address that is to be shared for all devices in the host-based routing subnet. The example uses ptm1 as the interface name and 10.0.0.1 as the IP address and 255.0.0.0 as the subnet mask.

zSH> interface add float ptm1 10.0.0.1 255.0.0.0Created ip-interface-record Zhone1/ip

Note: This is a virtual interface that will share its IP address; binding the IP interface is not necessary.

3 Create a DHCP relay for each customer, use the dhcp-relay command to create a relay agent. The subnet address/mask will be derived from the system's floating IP address, if present, or may be specified NULL for use only with bridged interfaces. If multiple floating IP records are present, the desired <name>/<type> may be specified.

The range (or pool) of assignable addresses which that customer can be assigned can be specified in the dhcp-server-subnet profile.

zSH> dhcp-relay add 255.0.0.0 172.16.80.20 Created DHCP Relay Agent number 99.

zSH> update dhcp-server-subnet 99Please provide the following: [q]uit.network: ---------------> {0.0.0.0}: 10.0.0.0netmask: ---------------> {0.0.0.0}: 255.0.0.0domain: ----------------> {0}: 1range1-start: ----------> {0.0.0.0}: 10.0.0.10range1-end: ------------> {0.0.0.0}: 10.0.0.20range2-start: ----------> {0.0.0.0}:range2-end: ------------> {0.0.0.0}:range3-start: ----------> {0.0.0.0}:range3-end: ------------> {0.0.0.0}:range4-start: ----------> {0.0.0.0}:range4-end: ------------> {0.0.0.0}:default-lease-time: ----> {-1}:min-lease-time: --------> {-1}:max-lease-time: --------> {-1}:boot-server: -----------> {0.0.0.0}:bootfile: --------------> {}:default-router: --------> {0.0.0.0}: 10.0.0.1primary-name-server: ---> {0.0.0.0}:



secondary-name-server: -> {0.0.0.0}:domain-name: -----------> {}:subnetgroup: -----------> {0}: 1 This number does not have to match the subnet indexstickyaddr: ------------> {enable}:....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

4 Issue the host add command to create the IP interface, ATM VCL, and IP address for individual subscribers. Also assigns VLAN and SLAN settings. The host add and host delete commands, <slot> and <port> may be replaced with brackets containing numbers in series and/or (dash-separated) ranges; <port> may be replaced with wildcard '*' for all ports on the card.

The following example adds dynamically assigned hosts:

zSH> host add 1-11-1-0/adsl vc 0/35 txtd 100 rxtd 1 tpid 0x8200 vlan 100 slan 10 cos 2 scos 3 llc dynamic 1 3

This example:

– creates an ip-interface-record on 1-11-1-0/adsl

– creates an atm-vcl with VPI/VCI=0/35 and LLC encapsulation of AAL5 data, which accommodates DSL routers

– creates an ATM cross connect from the virtual interface on the Uplink card to the designated slot card

– specifies the TAG protocol identifier (TPID) to identify the type of VLAN used.

– assigns VLAN ID 100.

– assigns SLAN ID 10.

– assigns COS value of 2 to VLAN 100.

– assigns COS value of 3 to SLAN 2.

– uses atm-traf-descr 100 for the transmit and atm-traf-descr 1 for the receive sides of the connection since ADSL is an asymmetrical connection

– adds 3 host entries that will have their addresses assigned dynamically as defined by subnetgroup 1.

Note: Hosts that already have DHCP-assigned addresses will need to renew those leases after the DHCP change. This is done by rebooting the host.

The following example adds a statically assigned host:

zSH> host add 1-11-2-0/adsl vc 0/35 td 1 llc static 10.10.10.1

This example:

Configuring IP



– creates an atm-vcl with VPI/VCI=0/35 and LLC encapsulation of AAL5 data


– uses atm-traf-descr 1 for the connection

– adds 1 host entry IP address 10.0.0.1.

5 Verify that hosts have been added:

zSH> host showRd/Address Interface Group T Host Address--------------------------------------------------------------------------------1 10.0.0.1 1-11-1-0-adsl-0-35 0/32 1 D <unassigned> D <unassigned> D <unassigned>

6 To find the other end of the ATM cross connect:

zSH> find-matching-data ATM 1-11-1-0-adsl/atm 0 35VCL 1-11-1-0-adsl/atm 0 35 is used in atm-cc 1The far end of this cross connect is 1-1-1-0-propvirtual/atm 0 32

7 To see the ATM virtual interfaces created by the host add command:

zSH> list atm-vcl atm-vcl 1-11-1-0-adsl/atm/0/35atm-vcl 1-1-1-0-propvirtual/atm/0/322 entries found.

8 To see the ATM cross connect created:

zSH> get atm-cc 1cc-index: ------> {1}low-if-index: --> {1-1-1-0-propvirtual/atm} virtual interface on the Uplink cardlow-vpi: -------> {0}low-vci: -------> {32}high-if-index: -> {1-11-1-0-adsl/atm} the slot cardhigh-vpi: ------> {0}high-vci: ------> {35}admin-status: --> {up}handle-id: -----> {handle_1}:

Configuring host-based routing with DSL bridges1 Create an atm-traf-descr for unnumbered interfaces:

zSH> new atm-traf-descr 100Please provide the following: [q]uit.td_type: -----------------> {atmNoClpNoScr}:td_param1: ---------------> {0}: 106133td_param2: ---------------> {0}: 38



td_param3: ---------------> {0}:td_param4: ---------------> {0}:td_param5: ---------------> {0}:cac-divider: -------------> {1}: td_service_category: -----> {ubr}:td_frame_discard: --------> {false}:usage-parameter-control: -> {true}:....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

2 Create an floating (unnumbered) IP interface the desired IP interface record for the IP address that is to be shared for all devices in the host-based routing subnet. The example uses ptm1 as the interface name and 10.0.0.1 as the IP address and 255.0.0.0 as the subnet mask.

zSH> interface add float ptm1 10.0.0.1 255.0.0.0Created ip-interface-record Zhone1/ip


3 Create a DHCP relay for each customer, use the dhcp-relay command to create a relay agent. The subnet address/mask will be derived from the system's floating IP address, if present, or may be specified NULL for use only with bridged interfaces. If multiple floating IP records are present, the desired <name>/<type> may be specified.

The range (or pool) of assignable addresses which that customer can be assigned can be specified in the dhcp-server-subnet profile.

zSH> dhcp-relay add Operation completed successfully.

For advanced DHCP setting changes, edit the dhcp-server-subnet profile.

zSH> update dhcp-server-subnet 99Please provide the following: [q]uit.network: ---------------> {0.0.0.0}: 10.0.0.0netmask: ---------------> {0.0.0.0}: 255.0.0.0domain: ----------------> {0}: 1range1-start: ----------> {0.0.0.0}: 10.0.0.10range1-end: ------------> {0.0.0.0}: 10.0.0.20range2-start: ----------> {0.0.0.0}:range2-end: ------------> {0.0.0.0}:range3-start: ----------> {0.0.0.0}:range3-end: ------------> {0.0.0.0}:range4-start: ----------> {0.0.0.0}:range4-end: ------------> {0.0.0.0}:default-lease-time: ----> {-1}:min-lease-time: --------> {-1}:max-lease-time: --------> {-1}:boot-server: -----------> {0.0.0.0}:

Configuring IP


bootfile: --------------> {}:default-router: --------> {0.0.0.0}: 10.0.0.1primary-name-server: ---> {0.0.0.0}:secondary-name-server: -> {0.0.0.0}:domain-name: -----------> {}:subnetgroup: -----------> {0}: 1 This number does not have to match the subnet indexstickyaddr: ------------> {enable}:....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

4 Issue the host add command to create the IP interface, ATM VCL, and IP address for individual subscribers. The host add,and host delete commands, <slot> and <port> may be replaced with brackets containing numbers in series and/or (dash-separated) ranges; <port> may be replaced with wildcard '*' for all ports on the card.

The following example adds dynamically assigned hosts:

zSH> host add 1-11-1-0/adsl vc 0/35 txtd 100 rxtd 1 dynamic 1 3

This example:


– creates an atm-vcl with VPI/VCI=0/35 and RFC 1483 encapsulation of AAL5 data, which accommodates DSL bridges


– uses atm-traf-descr 100 for the transmit and atm-traf-descr 1 for the receive sides of the connection since ADSL is an asymmetrical connection

– adds 3 host entries that will have their addresses assigned dynamically as defined by subnetgroup 1.

Note: Hosts that already have DHCP-assigned addresses will need to renew those leases after the DHCP change. This is done by rebooting the host.

Configuring network-based routing

Similar to host-based routing, network-based routing interoperates with DSL bridges and routers. The type of AAL5 encapsulation determines interoperability with DSL routers or DSL bridges. LLC encapsulation is used with DSL routers; RFC 1483 encapsulation is used with DSL bridges. Specify bridge in the command line to connect to DSL bridges. If no encapsulation type is specified in the command line, LLC encapsulation (llc) is the default. Refer to the CLI Reference Guide for a complete description of the command options and syntax.



The following table summarizes the configuration tasks for adding network-based routes.

Configuring network-based routing with DSL routers1 Create an atm-traf-descr for unnumbered interfaces:

zSH> new atm-traf-descr 100Please provide the following: [q]uit.td_type: -----------------> {atmNoClpNoScr}:td_param1: ---------------> {0}: 106133td_param2: ---------------> {0}: 38td_param3: ---------------> {0}:td_param4: ---------------> {0}:td_param5: ---------------> {0}:cac-divider: -------------> {1}: td_service_category: -----> {ubr}:td_frame_discard: --------> {false}:usage-parameter-control: -> {true}:....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

2 Issue the interface add command to create the IP interface, ATM VCL, and IP address allocation:

zSH> interface add 1-5-1-0/adsl vc 0/35 td 1 10.10.10.10 255.255.255.0Created ip-interface-record 1-5-1-0-adsl-0-35/ip

This example:


– creates an atm-vcl with VPI/VCI=0/35 and LLC encapsulation of AAL5 data, which accommodates DSL routers

– uses atm-traf-descr 1 for transmit and receive sides of the connection


– adds IP address 10.0.0.1 with a subnetwork defined by the netmask.

3 Verify that interfaces have been added:

Task Command

Create an atm-traf-descr. new atm-traf-descr index


Configure a connection to routed subnets.

interface add index/type vc vpi/vci td tdvalue | txtd tdvalue rxtd tdvalue llc | other IPaddress

This command creates the VCL and IP interface for the host route.

Verify provisioning interface show

Configuring IP


zSH> interface showInterface Status Rd/Address Media/Dest Address IfName--------------------------------------------------------------------------------1/1/1/0/ip DOWN 1 10.10.10.10/24 0/36 1-5-1-0-adsl-0-35--------------------------------------------------------------------------------



5 To see the ATM virtual interfaces created by the interface add command:



zSH> get atm-cc 5cc-index: ------> {5}low-if-index: --> {1-1-1-0-propvirtual/atm} virtual interface on the Uplink cardlow-vpi: -------> {0}low-vci: -------> {36}high-if-index: -> {1-5-1-0-adsl/atm} the slot cardhigh-vpi: ------> {0}high-vci: ------> {39}admin-status: --> {up}handle-id: -----> {handle_5}

Configuring network-based routing with DSL bridges1 Create an atm-traf-descr for unnumbered interfaces:

zSH> new atm-traf-descr 100Please provide the following: [q]uit.td_type: -----------------> {atmNoClpNoScr}:td_param1: ---------------> {0}: 106133td_param2: ---------------> {0}: 38td_param3: ---------------> {0}:td_param4: ---------------> {0}:td_param5: ---------------> {0}:cac-divider: -------------> {1}: td_service_category: -----> {ubr}:td_frame_discard: --------> {false}:usage-parameter-control: -> {true}:....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

2 Issue the interface add command to create the IP interface, ATM VCL, and IP address allocation:



zSH> interface add 1-5-1-0/adsl vc 0/35 td 1 other 10.10.10.10 255.255.255.0 Created ip-interface-record 1-5-1-0-adsl-0-35/ip

This example:


– creates an atm-vcl with VPI/VCI=0/35 and RFC 1483 encapsulation of AAL5 data, which accommodates DSL bridges

– uses atm-traf-descr 1 for transmit and receive sides of the connection


– adds IP address 10.0.0.1 with a subnetwork defined by the netmask.

3 Verify that interfaces have been added:

zSH> interface showInterface Status Rd/Address Media/Dest Address IfName--------------------------------------------------------------------------------1/1/1/0/ip UP 1 10.10.10.10/24 0/35 multipoint 1-5-1-0-adsl-0-35--------------------------------------------------------------------------------



5 To see the ATM virtual interfaces created by the interface add command:



zSH> get atm-cc 5cc-index: ------> {5}low-if-index: --> {1-1-1-0-propvirtual/atm} virtual interface on the Uplink cardlow-vpi: -------> {0}low-vci: -------> {36}high-if-index: -> {1-5-1-0-adsl/atm} the slot cardhigh-vpi: ------> {0}high-vci: ------> {39}admin-status: --> {up}handle-id: -----> {handle_5}

Configuring RIP

RIP behavior for the system as a whole is configured in the rip-global-config profile. Each IP interface is then configured for RIP using the rip command.

Configuring IP


Currently, the MALC supports RIP v1 and v2. Note that the only routing domain currently supported is domain 1.

Configuring RIP global defaultsThe following example configures RIP global behavior on the MALC:

1 Enable RIP for the system as a whole:

zSH> rip enable

2 To enable receipt of RIP version 1 or version 2 advertisements on an interface, use the rip command and specify the interface and the type of advertisements to receive:zSH> rip interface 172.16.92.191 listen v1v2

3 To enable transmission of RIP advertisements on an interface:a zSH> rip interface 172.16.92.191 talk v2

orb zSH> rip interface 172.16.92.191 talk v1compat

Configuring static routes

Use the route command to add or delete static routes. The MALC supports both destination and Source Address Based Routing (SABR).

SABR adds flexibility to route planning for network administrators and allows the MALC to forward outbound VoIP SIP traffic based on a specific source IP address of a data packet instead of the destination IP address.With SABR routing, the source IP address or subnet address of a data packet is examined before packet forwarding. If the device finds a matching source route in the source routing table, the packet is forwarded according to the matched source route. If the device does not find a matching source route, destination routing is performed based on the destination routing table and if necessary the configured default route.

Note the following about SABR support on the MALC:

• SABR routing is only supported on AAL5 VCLs using LLC encapsulation.

• The route, ping and traceroute commands support SABR.

• SABR is only supported for VoIP SIP.

Adding routesTo add static routes, use the route add command. The command uses the following syntax:

route [source] add destination mask next-hop cost



Note: The word default can be substituted for a 0.0.0.0 destination and mask.

The following example creates a network route to 192.178.21.0 using the gateway 192.172.16.1:route add 192.178.21.0 255.255.255.0 192.178.16.1 1

The following example creates a default route using the gateway 192.172.16.1:route add default 192.178.16.1 1

The following example creates a SABR route to 198.168.1.1 on the interface 198.168.1.101. The interface is the name of the outbound (egress) interface for this route (minus the /ip suffix).zSH> route add source 198.168.1.1 255.255.255.255 198.168.1.101 1 uplink1-0-36

Configuring the device as a DHCP server

The MALC DHCP supports the following types of DHCP configurations:

• Dynamic address allocation, where the server chooses and allocates an IP address with a finite lease. By default, the MALC will attempt to assign the same address (if available) to a device on lease renewal. This default can be changed to force a new address to be assigned.

• Static address allocation, where the server allocates the same IP address every time a device connects to the network.

DHCP server profiles and scopeUse the following profiles to configure the devices as a DHCP server:

• dhcp-server-options—Configures a default profile that is used to generate default configurations for networks that are not explicitly configured. See Setting DHCP server options on page 52 for more information.

• dhcp-server-subnet—Defines options for a specific network that is being managed by the DHCP server. Settings in the dhcp-server-subnet record override the default address pool set up by the dhcp-server-options record. See Creating DHCP server subnet options on page 54 for more information.

• dhcp-server-group—Defines options for a set of clients in a given domain. Inclusion of a given client into the group is based on a substring match of either the client’s DHCP vendor class identifier, its DHCP client identifier values, or both. The scope of a group object always overrides those of a subnet object for any DHCP client lease. See Advanced DHCP applications on page 62 for more information.

Configuring IP


• dhcp-server-host—Defines options for a specific host within a given domain. See Advanced DHCP applications on page 62 for more information.

• ip-interface-record—enables DHCP on the interface. The IP address defined in the ip-interface-record is used to determine the DHCP address pool for the attached network. See Enabling a DHCP server on page 56 for more information.

The DHCP server looks for configuration settings in order from the most specific record (the dhcp-server-host) to the most general (the dhcp-server-options record). It uses parameter settings in the following order:

1. dhcp-server-host

2. dhcp-server-group

3. dhcp-server-subnet

4. dhcp-server-options

If a parameter is set in multiple profiles (for example, lease times or default routers), the MALC uses the settings that are in the most specific record. This means that the DHCP server could use parameter settings in multiple records (if, for example, all client lease times were set in the dhcp-server-options record, and address ranges were set in the dhcp-server-subnet records.)

If only the dhcp-server-options record exists, the MALC uses those settings as the default for all DHCP server interfaces. For information about logging DHCP requests, see DHCP logging on page 92.

Setting DHCP server optionsAt startup, the MALC creates a default dhcp-server-options record. This profile defines global options for the MALC DHCP server.

The following example shows the dhcp-server-options profile with its default values:zSH> get dhcp-server-options 0Please provide the following: [q]uit.lease-time: -----> {43200}:min-lease-time: -> {0}:max-lease-time: -> {86400}:reserve-start: --> {5}: reserve-end: ----> {5}: restart: --------> {no}:



The dhcp-server-options profile supports the following parameters (all others should be left at their default values):

The following example changes the dhcp-server-options record to specify that each DHCP server reserve the first 10 addresses and the last 10 addresses in a network and does not include them in the DHCP server address pool.

zSH> update dhcp-server-options 0Please provide the following: [q]uit.lease-time: -----> {43200}:min-lease-time: -> {0}:

Parameter Description

lease-time The global default time in seconds that will be assigned to a DHCP lease if the client requesting the lease does not request a specific expiration time.

min-lease-time The minimum expiration time in seconds that will be assigned to a DHCP lease by the server, regardless of the value specified by a client. Values: -1 to 2147483647-1 indicates the parameter should be ignored.Default: 0

max-lease-time The maximum time in seconds that will be assigned to a lease regardless of the value specified by a client. Values: -1 to 2147483647. -1 indicates the parameter should be ignored.Default: 86400

reserve-start The default number of IP addresses, at the beginning of the MALC subnet IP address space, that are reserved by the DHCP server. To override this default, create a specific subnet rule for each subnet that needs to be handled differently.

reserve-end The default number of IP addresses at the end of the MALC ‘s subnet IP address space that are reserved by the DHCP server. To override this default, create a specific subnet rule for each subnet that needs to be handled differently.

Configuring IP


max-lease-time: -> {86400}:reserve-start: --> {5}: 10reserve-end: ----> {5}: 10restart: --------> {no}: ....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

In this example, if a DHCP server on the 192.168.9.0 network reserved the first 10 addresses and last 10 addresses, it would assign addresses from 192.168.9.11 to 192.168.9.244.

Creating DHCP server subnet optionsThe dhcp-relay command enables you to create, modify, delete and show DHCP relay agents. The subnet address/mask will be derived from the system's floating IP address, if present, or may be specified NULL for use only with bridged interfaces. If multiple floating IP records are present, the desired <name>/<type> may be specified.

The dhcp-server-subnet profile allows you to edit the options for a specific network that is being managed by the DHCP server. All subnets within a routing domain must be unique, so a given subnet object will provide options for exactly one connected network.

The dhcp-server-subnet profile supports the following parameters (all others should be left at their default values):


network The IP network address of this subnet.

netmask The subnet mask associated with the IP interface. The value of the mask is an IP address with all the network bits set to 1 and all the hosts bits set to 0.

domain The routing domain to which this subnet, group, or host parameter applies.

range1-start, range2-start, range3-start, range4-start

The starting IP address of an address pool in this subnet. If either the start or end range has a value of 0 then the entire address pool is ignored.

range1-end, range2-end, range3-end, range4-end

The ending IP address of an address pool in this subnet. If either the start or end range has a value of 0, then the entire address pool is ignored.

default-lease-time The default time, in seconds assigned to a lease if the client requesting the lease does not request a specific expiration time.

min-lease-time See description in dhcp-server-options profile.

max-lease-time See description in dhcp-server-options profile.



The following example defines a DHCP server subnet profile that is set up as follows:

• Defines a single DHCP address pool with 11 addresses.

• Defines a default router.

• Defines a boot server and a boot filename.

• Defines a domain name.

• Defines two DNS servers.

• Uses the minimum, maximum, and default lease time (by accepting the default settings for the default-lease-time, min-lease-time, and max-lease-time).

zSH> new dhcp-server-subnet 12Please provide the following: [q]uit.network: ---------------> {0.0.0.0}: 192.168.1.0netmask: ---------------> {0.0.0.0}: 255.255.255.0domain: ----------------> {0}: 1range1-start: ----------> {0.0.0.0}: 192.168.1.10

boot-server The IP address of the server from which the initial boot file (specified in the bootfile parameter) is to be loaded.

bootfile The name of the initial boot file loaded by the client. The filename should be recognizable to the file transfer protocol that the client will be using to load the file.

default-router The IP address of the client default gateway.

primary-name-server The IP address of the primary domain name server that the client should use for DNS resolution.

secondary-name-server The IP address of the secondary domain name server that the client should use for DNS resolution.

domain-name The name of the DNS domain.

subnetgroup A number which indicates which DHCP subnet group this pool is a member of. A value of 0 (default) indicates that the subnet is not a member of any group.

stickyaddr The DHCP server attempts to assign the same IP address to the same host, if possible, based on hardware address. Values: disableenableDefault: enable


Configuring IP


range1-end: ------------> {0.0.0.0}: 192.168.1.20range2-start: ----------> {0.0.0.0}:range2-end: ------------> {0.0.0.0}:range3-start: ----------> {0.0.0.0}:range3-end: ------------> {0.0.0.0}:range4-start: ----------> {0.0.0.0}:range4-end: ------------> {0.0.0.0}:default-lease-time: ----> {-1}:min-lease-time: --------> {-1}:max-lease-time: --------> {-1}:boot-server: -----------> {0.0.0.0}: 192.168.1.55bootfile: --------------> {}: filename.bindefault-router: --------> {0.0.0.0}: 192.168.1.1 primary-name-server: ---> {0.0.0.0}: 192.168.8.21secondary-name-server: -> {0.0.0.0}: 201.23.20.2domain-name: -----------> {}: zhone.comsubnetgroup: -----------> {0}:stickyaddr: ------------> {enable}:....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Enabling a DHCP serverModify the following parameters in the ip-interface-record to enable DHCP server (all others should be left at their default values):

The following example enables the DHCP server on an IP-enabled interface in MALC shelf 1, slot 1, port 2, and subport 0.

zSH> update ip-interface-record 1/1/2/0/ipPlease provide the following: [q]uit.vpi: ---------------> {0}:vci: ---------------> {0}:rdindex: -----------> {1}:dhcp: --------------> {none}: ** read-only **addr: --------------> {172.24.200.162}:netmask: -----------> {255.255.255.0}:


dhcp Indicates whether this interface is a DHCP client, a DHCP server, both, or neither. Values: noneclientserverbothDefault: none

address The IP address of LAN port.



bcastaddr: ---------> {172.24.200.255}:destaddr: ----------> {0.0.0.0}:farendaddr: --------> {0.0.0.0}:mru: ---------------> {1500}:reasmmaxsize: ------> {0}:ingressfiltername: -> {}:egressfiltername: --> {}:pointtopoint: ------> {no}:mcastenabled: ------> {yes}:ipfwdenabled: ------> {yes}:mcastfwdenabled: ---> {yes}:natenabled: --------> {no}:bcastenabled: ------> {yes}:ingressfilterid: ---> {0}:egressfilterid: ----> {0}:ipaddrdynamic: -----> {static}:dhcpserverenable: --> {false}: truesubnetgroup: -------> {0}:unnumberedindex: ---> {0}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

DHCP relay

The MALC supports DHCP relay. DHCP broadcast messages do not, by default, cross the router interfaces. To solve the problem of DHCP broadcast messages on multiple-subnet, the MALC can be configured as a DHCP relay agent that communicates with a DHCP server and acts as a proxy for DHCP broadcast messages that need to be routed to remote segments.

In DHCP relay scenarios, the MALC serves as a DHCP relay agent that forwards broadcast DHCP discover and DHCP request packets to an external DHCP server. It then forwards the unicast DHCP offer and DHCP ack/nak replies to the requesting DHCP host.

Configuring IP


Figure 10: DHCP relay

Note the following requirements for DHCP relay:

• The external DHCP server must be configured to assign addresses on the same subnet as the floating IP address used by the remote device.

• The external DHCP server must be configured with a static route for the remote device’s subnet back to the MALC on which the relay agent is running. (The DHCP server will send DHCP unicast packets to the relay agent’s address, which is the first one in the subnet.)

• A separate DHCP server can be specified per subnet.

Specifying an external DHCP serverUse the dhcp-relay command to configure, modify, delete and show the DHCP relay. The subnet address/mask will be derived from the system's floating IP address, if present, or may be specified NULL for use only with bridged interfaces. If multiple floating IP records are present, the desired <name>/<type> may be specified.

The dhcp-server-subnet profile is available for advanced DHCP configuration changes. The following parameter has been added to this profile:

To specify an external DHCP server:

DHCP server

DHCP relay agent

DHCP client


external-server Enable an external subnet server in order to support DHCP relay agent.Default: 0.0.0.0



1 Create a dhcp-server-subnet profile and specify the IP address of the external server:

zSH> new dhcp-server-subnet 1Please provide the following: [q]uit.network: ---------------> {172.24.41.0}:netmask: ---------------> {255.255.255.0}:domain: ----------------> {1}:range1-start: ----------> {172.24.41.11}:range1-end: ------------> {172.24.41.100}:range2-start: ----------> {0.0.0.0}:range2-end: ------------> {0.0.0.0}:range3-start: ----------> {0.0.0.0}:range3-end: ------------> {0.0.0.0}:range4-start: ----------> {0.0.0.0}:range4-end: ------------> {0.0.0.0}:default-lease-time: ----> {-1}:min-lease-time: --------> {-1}:max-lease-time: --------> {-1}:boot-server: -----------> {172.24.38.102}:bootfile: --------------> {i3micro/etherboot-I3M-i.img}:default-router: --------> {172.24.41.254}:primary-name-server: ---> {172.24.38.102}:secondary-name-server: -> {0.0.0.0}:domain-name: -----------> {nat.myrio.net}:subnetgroup: -----------> {1}:stickyaddr: ------------> {enable}:external-server: -------> {0.0.0.0}: 172.16.88.71....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

2 Create a host route and specify the subnet group. For example:

zSH> host add 1-1-1-0/adsl vc 0/36 td 200 dynamic 1 1

This specifies that the host route over the specified ATM interface uses dynamic addressing and subnet group number 1.

TOS/COS processing

The MALC supports the marking and remarking of TOS values in IP packets and COS values in Ethernet VLAN headers as defined by IETF RFC1349 and IEEE 802.1p respectively. The configured TOS and COS levels specify the packet priority and queueing methods used to transport the packet through the IP and Ethernet networks. The MALC sets and transports the TOS/COS values, while the switches and routers connected to the MALC perform the queuing services and packet QOS processing.

Configuring IP



This service enables you to:

• Add IP packet TOS values and VLAN header COS values to packets originating from the MALC.

• Overwrite existing IP packet TOS values and VLAN header COS values that are transported through the MALC.

• Leave existing IP packet TOS values and VLAN header COS values unchanged in all packets.

802.1p priority queuesMulti-media Traffic Management (MTM), is a rules-based policy enforcement mechanism for SLMS systems. The MALC MTM is used to mark packet priorities and service queues. The MALC will support 4 (four) strict priority queues (served until emptied) as part of the MALC's implementation of the MTM feature set for QoS.

New line cards supporting 802.1p priority queues are: MALC-ACTIVE-ETH-10, MALC-GPON-SC1, MALC-VDSL2-24 DMT, MALC-EFM-SHDSL-24, and MALC-EFM-T1/E1-24.

Existing line cards supporting 802.1p priority queues are:

MALC-ADSL-48B, MALC-ADSL-48A, MALC-ADSL+POTS-TDM-48A-2S,MALC-ADSL+POTS-TDM/PKT-48A-2S, MALC-ADSL-48A/M, MALC-ADSL+POTS-TDM-48A/M-2S, MALC-ADSL+POTS-PKT-48A/M-2S, MALC-ADSL+POTS-TDM-48-2S

Fields in IP headerIP packets have a TOS byte in their headers that contains information about relative priority. The TOS byte is divided into two fields called IP Precedence and TOS. The IP Precedence field contains a 3-bit priority designation. Most normal traffic has an IP Precedence value of zero. Higher values in this field indicate that traffic is more important and that it requires special treatment. IP Precedence values greater than 5 are reserved for network functions.

Fields in the VLAN headerThe VLAN header in Ethernet packets contains a COS field for queueing priority or Class of Service (COS) values based on eight (0-7) levels of service. This field contains information about how the traffic should be



forwarded. The MALC supports basic COS marking and remarking without any queue servicing options. Packets marked or remarked based on a configurable profile to let the system know which bits use which queue.

TOS/COS parametersThe following parameters in the IP interface record are used for TOS and COS support.

To display the TOS/COS settings in the ip-interface-record profile, enter the show ip-interface-record command.

zSH> show ip-interface-record vpi:---------------> {0}vci:---------------> {0}rdindex:-----------> {0 - 2147483647}dhcp:--------------> none client server bothaddr:--------------> {0 - -1}netmask:-----------> {0 - -1}bcastaddr:---------> {0 - -1}destaddr:----------> {0 - -1}farendaddr:--------> {0 - -1}mru:---------------> {0 - 2147483647}reasmmaxsize:------> {0 - 65535}ingressfiltername:-> {33}


tosOption Specifies how to handle the IP TOS precedence and VLAN header COS bits.Values: Disable Leave any existing TOS and COS values unchanged. The default setting.Originate Replace the current TOS and COS values in all packets originating from the current device. TOS and COS values in packets that are transported through (not originating on) this MALC are not affected. The TOS value is specified in the tosCos field. The COS value is specified in the vlanCOS field. All Replace the current TOS and COS values in all packets originating and transported through this device. The TOS value is specified in the tosCos field. The COS value is specified in the vlanCOS field.This setting has no affect on VoIP RTP packets originated from this interface.

tosCOS Specifies the value loaded into the TOS precedence bits in the IP header for packets originating and transported through the current device. Value range is 0 to 7. Default is 0.

vlanCOS Specifies the value loaded into the COS field of the VLAN header for packets originating and transported through the current device. Value range is 0 to 7. Default is 0.

Configuring IP


egressfiltername:--> {33}pointtopoint:------> no yesmcastenabled:------> no yes ipfwdenabled:------> no yes mcastfwdenabled:---> no yes natenabled:--------> no yes bcastenabled:------> no yes ingressfilterid:---> {0 - 2147483647}egressfilterid:----> {0 - 2147483647}ipaddrdynamic:-----> static ppp dhcpclient unnumbered dhcpserverenable:--> true falsesubnetgroup:-------> {0 - 2147483647}unnumberedindex:---> {0 - 2147483647}mcastcontrollist:--> {264}vlanid:------------> {0 - 4095}maxVideoStreams:---> {0 - 210}tosOption:---------> disable originate all tosCOS:------------> {0 - 7vlanCOS:-----------> {0 - 7}


Advanced IP provisioning procedures

The following advanced IP procedures are supported on the MALC:

• Advanced DHCP applications on page 62

• Configuring DNS resolver on page 64

• Configuring IP filters on page 66

• IP Service Level Agreement (IPSLA) on page 69

Advanced DHCP applicationsThis section explains how to configure more advanced DHCP applications. It includes the following sections:

• Creating dhcp-server-group profile on page 62

• Creating dhcp-server-host profile on page 63

Creating dhcp-server-group profileThe dhcp-server-group defines options for a set of clients in a given domain. Inclusion of a given client into the group is based on a substring match of either the client’s DHCP vendor class identifier, its DHCP client identifier



values, or both. The scope of a group object always overrides those of a subnet object for any DHCP client lease.

Modify the following parameters to create a new dhcp-server-group profile:

zSH> new dhcp-server-group 1Please provide the following: [q]uit.name: ------------------> {}: group1domain: ----------------> {0}:vendor-match-string: ---> {}: 'oakland' this is converted to an octet stringvendor-match-offset: ---> {0}:vendor-match-length: ---> {-1}:client-match-string: ---> {}: 'oakland'this is converted to an octet stringclient-match-offset: ---> {0}:client-match-length: ---> {-1}:default-lease-time: ----> {-1}:min-lease-time: --------> {-1}:max-lease-time: --------> {-1}:boot-server: -----------> {0.0.0.0}:bootfile: --------------> {}:default-router: --------> {0.0.0.0}:primary-name-server: ---> {0.0.0.0}:secondary-name-server: -> {0.0.0.0}:domain-name: -----------> {}:....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

Creating dhcp-server-host profileThe dhcp-server-host defines options for a specific host within a given domain.

Set the following parameters in the dhcp-server-host profile:


name The DHCP server group name.

vendor-match-string The vendor class identifier match string that determines which clients should be placed in the group.

client-match-string Client identifier match string that determines which clients should be placed in this group.

Configuring IP


zSH> new dhcp-server-host 1Please provide the following: [q]uit.name: ------------------> {}: host1domain: ----------------> {0}:hardware-address: ------> {}: 09:00:07:A9:B2:EBclient-identifier: -----> {}: ‘clientgroup1’ipaddr1: ---------------> {0.0.0.0}:ipaddr2: ---------------> {0.0.0.0}:ipaddr3: ---------------> {0.0.0.0}:ipaddr4: ---------------> {0.0.0.0}:default-lease-time: ----> {-1}:min-lease-time: --------> {-1}:max-lease-time: --------> {-1}:boot-server: -----------> {0.0.0.0}:bootfile: --------------> {}:default-router: --------> {0.0.0.0}:primary-name-server: ---> {0.0.0.0}:secondary-name-server: -> {0.0.0.0}:domain-name: -----------> {}:....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

Configuring DNS resolverDomain Name System (DNS) maps domain names to IP addresses, enabling the system to reach destinations when it knows only the domain name of the destination. DNS configuration uses the following profiles:

• resolver—Configures the global DNS resolver, including the DNS search order, default domain name, and list of nameserver addresses. The DNS settings in this record can be used for local applications by administrators on the system, such as traceroute or ping.

• host-name—A replacement for the Unix local hosts table. Up to four host aliases can be defined for each host entry. Settings in the resolver record determine whether the hosts table is searched.


name The DHCP host name for the client

hwaddr The MAC address of the network interface that was used to acquire the lease.

clientId The DHCP client identifier



The resolver profile supports the following parameters (all others should be left at their default values):

The following example creates a resolver record for a routing domain:

zSH> new resolver 1Please provide the following: [q]uit.query-order: -------> {hosts-first}: domain: ------------> {}: zhone.comfirst-nameserver: --> {0.0.0.0}: 192.168.8.21second-nameserver: -> {0.0.0.0}: 201.23.20.2third-nameserver: --> {0.0.0.0}:....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.


query-order The kind of resolver query for this routing domain.Values: hosts-first searches the local hosts table first then the list of nameservers.dns-first searches the list of nameservers first then the local hosts table.dns-only searches only the list of nameservers.Default: hosts-first

domain The routing domain to which this host parameter applies. The default is an empty string.The only routing domain supported is domain 1.

first-nameserver The IP address of the first or primary nameserver for this routing domain. The default value is 0.0.0.0.

second-nameserver The IP address of the second or secondary nameserver for this routing domain. This nameserver is queried if the first nameserver cannot resolve the query. The default value is 0.0.0.0.

third-nameserver The IP address of the third or tertiary nameserver for this routing domain. This nameserver is queried if the first nameserver cannot resolve the query. The default value is 0.0.0.0.

Configuring IP


Optionally, you can create a hosts profile after the resolver profile has been created. The syntax is new host-name routingdomain/ipoctet1/ipoctet2/ipoctet3/ipoctet4.

The host-name profile supports the following parameters (all others should be left at their default values):

zSH> new host-name 1/192/168/8/32Please provide the following: [q]uit.hostname: ---> {}: www.zhone.comipaddress: --> {0.0.0.0}: 192.168.8.32hostalias1: -> {}: engineering.zhone.comhostalias2: -> {}: marketing.zhone.comhostalias3: -> {}: sales.zhone.comhostalias4: -> {}: gss.zhone.com....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

Configuring IP filtersThe following table summarizes the configuration tasks for configuring IP filters.


hostname Client host name (if any) that the client used to acquire its address. The default is an empty string.

hostalias1 Host name alias for the specified host. The default value is an empty string.

hostalias2 Secondary host name alias for the specified host. The default value is an empty string.

hostalias3 Tertiary host name alias for the specified host. The default value is an empty string.

hostalias4 Quaternary host name alias for the specified host. The default value is an empty string.

Task Command

Create a new filter. filter new

Specify what to filter. filter add rule [from | to] [IP address] [permit | deny]

Save the filter. filter save

Apply the filter to an IP interface. update ip-interface-record interface



Configuring IP filters Follow these steps to set up IP filtering:

1 Use the filter new command to create a new filter. The filter will be given an index value which you can use to specify the filter. The example below creates a filter with an index value of 5.

zSH> filter newfilter: 5 successfully created and loaded for editing

2 After creating the filter, rules must be applied to it. To do this, use the filter add command. The syntax is:

filter add rule [from | to] [IP address] [permit | deny]

The rule is a user-defined value for the filtering rules to be applied.

The example below permits traffic from 192.168.1.15, but denies traffic from all others:

zSH> filter add from 192.168.1.15 permit5/101 from 192.168.1.15 permitzSH> filter add deny5/110 deny

You can also specify a range of IP addresses on which to filter:

zSH> filter add 102 from 10.0.0.1-10.0.0.254 permit5/102 from 10.0.0.1-10.0.0.254 permitzSH> filter add 192.168.1.15 permit5/120 deny

You can also specify both source and destination addresses in the same rule:

zSH> filter add 103 from 10.0.0.1-10.0.0.254 to 192.168.0.0-192.168.0.254 permit5/103 from 10.0.0.1-10.0.0.254 to 192.168.0.0-192.168.0.254 permitzSH> filter add 130 deny5/130 deny

3 Once you have added rules to a filter, you must save it with the filter save command:

zSH> filter saveSave loaded filter: 5 (it has been modified) yes/no [yes]? yesfilter: 5 has been saved

Show filters created. filter show index

Edit existing filters. filter load index

filter delete index

Task Command

Configuring IP


4 After you have saved your filter, you will need to apply it to an IP interface. Update the ip-interface record where you wish to apply the filter. Insert the filter index value in the ingressfilterid or egressfilterid parameter:

zSH> update ip-interface-record 1/1/1/0/ipPlease provide the following: [q]uit.vpi: ---------------> {0}:vci: ---------------> {0}:rdindex: -----------> {1}:dhcp: --------------> {none}:addr: --------------> {172.16.160.11}:netmask: -----------> {255.255.255.0}:bcastaddr: ---------> {172.16.160.255}:destaddr: ----------> {0.0.0.0}:farendaddr: --------> {0.0.0.0}:mru: ---------------> {1500}:reasmmaxsize: ------> {0}:ingressfiltername: -> {}:egressfiltername: --> {}:pointtopoint: ------> {no}:mcastenabled: ------> {yes}:ipfwdenabled: ------> {yes}:mcastfwdenabled: ---> {yes}:natenabled: --------> {no}:bcastenabled: ------> {yes}:ingressfilterid: ---> {0}: 5 the number of the filteregressfilterid: ----> {0}: 5 the number of the filteripaddrdynamic: -----> {static}dhcpserverenable: --> {false}subnetgroup: -------> {0}unnumberedindex: ---> {0} ....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated

5 Use the filter show command (with the filter index) to view created filters:

zSH> filter show 5Filter: 5 Line Rule ---- ----101 from 192.168.1.15 permit 102 from 10.0.0.1-10.0.0.254 permit103 from 10.0.0.1-10.0.0.254 to 192.168.0.0-192.168.0.254 permit150 from 192.168.120.1-192.168.123.254 to 192.168.120.16 permit

6 If you wish to edit a filter, use the filter load filterID command to load the filter for editing. Then use the filter delete RuleNum command to delete rules from the filter.

zSH> filter load 5filter: 5 successfully loaded for editing



zSH> filter delete 1015/101 from 192.168.1.15 permitDelete rule: 5/101 yes/no [yes]? yesrule: 5/101 deleted

Use the rule add command to add new rules, and the rule save command to save filter rules. See Step 2 and Step 3.

Note: Refer to the Zhone CLI Reference Guide for full explanations of the filter command options and variables.

IP Service Level Agreement (IPSLA)The IP Service Level Agreement (IPSLA) feature assists service providers and network operators with enforcing and monitoring access network connections and performance. IPSLA uses ICMP Ping messages over configured IPSLA paths to track Round Trip Times (RTTs) and EHCOREQs/RSPs between initiator and responder devices to determine network performance and delays. Typically, one initiator device is used to monitor other responder devices in the network. A maximum of 32 IPSLA paths can be configured per MALC and 4 IPSLA paths per IP device.

Initiator devices must be running IPSLA to request data for a responder device. Responder devices must be accessible through the ping command in the IP network , but do not need to run IPSLA. Responder devices not running IPSLA display limited statistical data and functionality.

Note: Networks must support CoS queues and DSCP to provide valid per CoS statistics. Otherwise, all statistics are sent to the default CoS queue.

Default CoS-actions are assigned to each CoS queue so threshold crossing alarms can be configured to generate system alarms when thresholds are crossed for uptime, latency, jitter, and packet size.

Data based on received/sent packets and train rates is collected and displayed as real-time statistics for the current 15 minute interval as well as over 96 15-minute intervals for 24 hour historical statistics.

By default, IPSLA is disabled on all EtherXtend, MALC card ports and other SLMS devices.

Configuring IP


Figure 11: IPSLA

Configuring IPSLAIPSLA requires the following configuration steps:

• Set ipsla-global settings to enable device state and optionally set polling interval

• Create ICMP path between devices

• Optionally, modify COS actions for the desired COS queues

• Optionally modify COS map for Diff Server Control Point (DSCP) mappings

To configure IPSLA:

1 Display the global IPSLA settings and update the state and polling interval. The polling interval (60 to 3600 seconds) is used for real-time and historical statistics.

zSH> ipsla show globalstate: -------> {disabled}pollSeconds: -> {60}

Using the IPSLA command, enable IPSLA and set the polling interval to 120 seconds.

zSH> ipsla modify global state enabled pollseconds 120

2 Create a ICMP path between devices. The device on which this command is entered becomes the initiator device, while the device for which an IP address is entered becomes the responder device. Typically, one initiator device can be used to monitor other responder devices in the network over a maximum of 32 MALC and 4 EtherXtend IPSLA paths per device.

zSH> ipsla add path 172.16.78.11

zSH> ipsla show path

MALC as IPSLA Initiator

EtherXtend as IPSLA Responder

IPSLA Path for ICMP Pings

MALC as IPSLA ResponderIP Network


EtherXtend as IPSLA Responder




Path configuration for ipAddress: 172.16.78.11forwarding: -> {disabled}state: ------> {enabled}

Modify the path using the IPSLA modify path command. This example disables the static path on device 192.168.254.17.

zSH> ipsla modify path ipaddress 192.168.254.17 state disabled

Delete a path using the IPSLA delete command.

zSH> ipsla delete path ipaddress 192.168.254.17

Note: Disabling or deleting the path or globally disabling the IPSLA feature will reset historical data.

3 Modify the default CoS actions to specify the response and threshold behavior for each CoS Action Index (1-8). These CoS actions map respectively to the CoS queues (0-7). The following CoS actions are defined by default.

Each COS action contains the following parameters:

Default Name CoS Action Index CoS Queue

Default 1 0

AFClass 1 2 1

AFClass 2 3 2

AFClass 3 4 3

AFClass4 5 4

Cos-5 6 5

ExpFwd 7 6

NetwCtrl 8 7

Parameter Description Default

Name Name of the IPSLA CoS action, up to 9 characters in length. (1) Default, (2) AFClass1,(3) AFClass2, (4) AFClass3, (5) AFClass4, (6) Cos-5, (7) ExpFwd, (8) NetwCtrl.

Traps Specifies whether a trap is issued when any SLA performance error threshold within this CoS is crossed.

Disabled

Timeouts Specifies the number of consecutive missed IP SLA responses within this CoS before a zhoneIpSLATimeoutTrap is issued.

3 timeouts

Configuring IP


Display the settings for an individual CoS action.

zSH> ipsla show cos-action cosactionindex 1Cos Action Configuration for cosActionIndex: 1:name: -------> {Default}traps: ------> {disabled}timeOuts: ---> {3} latency: ----> {10000} jitter: -----> {10000} packetSize: -> {64}

Display the settings for all CoS actions (1-8).

zSH> ipsla show cos-actionCos Action Configuration for cosActionIndex: 1:name: -------> {Default}traps: ------> {disabled}timeOuts: ---> {3}latency: ----> {10000}jitter: -----> {10000}packetSize: -> {64}

Cos Action Configuration for cosActionIndex: 2:name: -------> {AFClass1}traps: ------> {disabled}timeOuts: ---> {3}latency: ----> {10000}

Timeout Clear

Specifies the number of consecutive IPSLA responses within this CoS which must be received before the timeout error condition is cleared.

1 sample

Latency Specifies the 15 sample average roundtrip latency value which must be exceeded within this CoS before a zhoneIpSLALatencyTrap is issued.

10000 milliseconds

Latency Clear

Specifies the number of consecutive IPSLA latency samples for which the 15 sample average roundtrip latency must be below the configured SLA latency error threshold within this CoS before the latency error condition is cleared.

1 sample

Jitter Specifies the 15 sample roundtrip jitter value which must be exceeded within this CoS before a zhoneIpSLAJitterTrap is issued.

10000 milliseconds

Jitter Clear Specifies the number of consecutive IPSLA RTT samples for which the 15 sample roundtrip jitter must be below the configured SLA jitter error threshold within this CoS before the jitter error condition is cleared.

1 sample

Packetsize Specifies the minimum IPSLA Ping packet size in bytes. The range is 64 thru 2048 if the target IP device is running IPSLA, 64 thru 512 otherwise.

64 bytes

Parameter Description Default



jitter: -----> {10000}packetSize: -> {64}

Cos Action Configuration for cosActionIndex: 3:name: -------> {AFClass2}traps: ------> {disabled}timeOuts: ---> {3}latency: ----> {10000}jitter: -----> {10000}packetSize: -> {64}



Cos Action Configuration for cosActionIndex: 6:name: -------> {Cos-5}traps: ------> {disabled}timeOuts: ---> {3}latency: ----> {10000}jitter: -----> {10000}packetSize: -> {64}

Cos Action Configuration for cosActionIndex: 7:name: -------> {ExpFwd}traps: ------> {disabled}timeOuts: ---> {3}latency: ----> {10000}jitter: -----> {10000}packetSize: -> {64}

Cos Action Configuration for cosActionIndex: 8:name: -------> {NetwCtrl}traps: ------> {disabled}timeOuts: ---> {3}latency: ----> {10000}jitter: -----> {10000}packetSize: -> {64}

To modify a cos-action, specify the desired parameters to change in the command line. This example enables traps for cosActionIndex 1.

Configuring IP


zSH> ipsla modify cos-action cosactionIndex 1 traps enabled

4 Configured the desired COS maps to modify the default DSCP to COS Action Index mappings. By default, DSCP are mapped to COS Action Index entries based of RFC 2599. The following tables shows the default mappings. A COS Action Index of 0 indicates that the DSCP is not used.

Display the CoS map for an individual CoS action or for all CoS actions.

zSH> ipsla show cos-mapdscpIndex: 1 cosActionIndex: 1dscpIndex: 2 cosActionIndex: 0dscpIndex: 3 cosActionIndex: 0dscpIndex: 4 cosActionIndex: 0dscpIndex: 5 cosActionIndex: 0dscpIndex: 6 cosActionIndex: 0dscpIndex: 7 cosActionIndex: 0dscpIndex: 8 cosActionIndex: 0dscpIndex: 9 cosActionIndex: 0dscpIndex: 10 cosActionIndex: 0dscpIndex: 11 cosActionIndex: 2dscpIndex: 12 cosActionIndex: 0dscpIndex: 13 cosActionIndex: 2dscpIndex: 14 cosActionIndex: 0dscpIndex: 15 cosActionIndex: 2dscpIndex: 16 cosActionIndex: 0dscpIndex: 17 cosActionIndex: 0dscpIndex: 18 cosActionIndex: 0dscpIndex: 19 cosActionIndex: 3Type A<CR> to print all, <CR> to continue, Q<CR> to stop:

DSCP COS Action Index

1 8

11, 13, 15 7

19, 21, 23, 6

27, 29, 31 5

35, 37, 39 4

41 3

47 2

49, 57 1

2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 14, 16, 17, 18, 20, 22, 24, 25, 26, 28, 30, 32, 33, 34, 36, 38, 40, 42, 43, 44, 45, 46 ,48, 50, 51, 52, 53, 54, 55, 56, 58, 59, 60, 61, 62, 63, 64

0



Specify the desired index values in the command line to change the mapping of the DSCP index 1 to COS queue 7. This example changes the mapping of DSCP index 1 to COS queue 7.

zSH> ipsla modify cos-map dscpindex 1 cosactionindex 7

To clear a CoS map, specify the desired index values in the IPSLA command to delete the mapping of the DSCP index for the COS queue. This example clears the mapping of DSCP index 1 and resets it to the COS queue 0.

zSH> ipsla modify cos-map dscpindex 1 cosactionindex 0

5 Display real-time statistics for path or COS queue. Real-time statistics represent minimum, maximum, average, and current values over the current 15 minute polling period based on data collected for each polling intervals. For example, if the polling interval is configured for 60 seconds, the real-time statistics display the data compiled from the latest 15 60-second polling intervals contained in the current polling period.

Note: RTT values of 0 (zero) indicate a lack of data, while sub-millisecond RTTs are reported as 1.

These statistics can be displayed individually or collectively for a specified IP address or for all configured paths.

Note: When a card swact occurs, historical data does not failover and data for the15-minute interval during which the swact occurred may be lost. Current and historical statistics on redundant uplinks are not supported. On switchovers, these statistics are reset to 0.

zSH> ipsla stats path ipaddress 192.168.254.15

zSH> ipsla stats path

The table below explains the statistics for the configured paths.

Path Statistic Description

Target IP Address IP Address of the device which is at the other end of the path.

Target Name Name of the remote device.

Target Type Type of the remote device.

ACT Availability status of the remote device.

Source IP IP Address of the discovery source device.

CNX Type of path either static or dynamic.

Configuring IP


Display real-time CoS statistics individually or collectively by CoS action index, IP address or all CoS actions.

zSH> ipsla stats cos cosactionindex 1

zSH> ipsla stats cos ipaddress 10.2.1.254

zSH> ipsla stats cos

The table below explains the CoS Action Index statistics.

Display historical statistics individually or collectively based on IP address, CoS action index, and index value of a 15 minute interval. Historical statistics are displayed for the latest 24 hour period or a specified 15 minute interval within the latest 24 hour period.

For historical statistics, IPSLA averages values for the most recent 96 15-minute intervals and displays the minimum, maximum, average and current values in a table for a 24 hour summary.

zSH> ipsla stats history cosactionindex 1Up to 96 intervals....

UpTime (secs) Amount of time in seconds that elapsed since the last transition from Inactive to Active.

I/R Role played by the local device in collection of latency and availability statistics.Initiator - Device that initiates the IPSLA ping packet used for statistics collection;Responder - Device that returns the IPSLA ping packet sent by the Initiator.

CoS Mismatch Number of IPSLA ping packets received which indicate a mismatch between the Class Of Service (CoS) definitions at the remote unit and those of the source unit.

Path Statistic Description

COS Action Index Statistic

Description

CoS Index Index number of the CoS Action Index.

Target IP Address IP Address of the device which is at the other end of the path.

Last RTT RTT reported in the most recent successful ping attempt.

Min RTT Smallest RTT since this statistic was last cleared to a zero value.

Avg RTT Average RTT since this statistic was last cleared to a zero value. Calculated as (RTT1 + RTT2 + RTT3 + …….+RTTn)/n where n equals the number of successful ping attempts since this statistic was last cleared to a zero value.

Max RTT Largest RTT since this statistic was last cleared to a zero value.

Drop Resp Number of failed pings since this statistic was last cleared to a zero value.



zSH> ipsla stats history ipaddress 10.2.1.254

zSH> ipsla stats history index 1

zSH> ipsla stats historyUp to 96 intervals....

Each bulk statistic relies on a bulk-statistics profile to define the OID, instance and other MIB information used to collect and display the data. When a IPSLA path is modified or deleted during the process of data collection, the related bulk-statistics profiles may lose their association and become dangling profiles. The following console message is generated whenever a bulk-statistics profile becomes dangling.

The bulkstats audit command enables users to check for and delete dangling bulk-statistics profiles. The bulkstats audit command provides an interactive and repair option. The interactive option lists all dangling profiles with the option to modify or delete the profile. The repair option prompts for profile deletion.

bulkstats audit -interactive | repair

To display and repair dangling bulk-statistics profiles, enter the bulkstats audit command.

zSH> bulkstats audit -interactive Checking validity............ 3 dangling profiles found. bulk-statistic 5 enabled: ----------> {true} oid: --------------> {zhoneIpSLAPathStatByCOSAvgRTT} instance: ---------> {6.1.11.1.15.253} include-children: -> {false}

[d]elete, [m]odify, [n]ext, [p]revious, [h]elp, [q]uit ? d bulk-statistic 55 enabled: ----------> {true} oid: --------------> {zhoneIpSLAPathStatByCOSAvgRTT} instance: ---------> {2.1.173.24.95.2} include-children: -> {false} [d]elete, [m]odify, [n]ext, [p]revious, [h]elp, [q]uit ? d

bulk-statistic 555 enabled: ----------> {true} oid: --------------> {zhoneIpSLAPathStatByCOSAvgRTT}

Configuring IP


instance: ---------> {2.1.173.24.72.103} include-children: -> {false} [d]elete, [m]odify, [n]ext, [p]revious, [h]elp, [q]uit d

zSH> bulkstats audit -repair Checking validity............ 1 dangling profile found. Delete profile? { [y]es or [n]o } y

IP fallback route

The MALC supports IP redundancy or fallback IP routes. A fallback route is a second static route with the same destination and netmask of an existing route but with a different nexthop destination. The redundant or fallback route is used when the original nexthop destination is unavailable. The fallback route continues to be used until the revertive period expires. At that time, traffic switches back to the primary route.

A ping interval and ping retry count are use to determine route availability. The MALC pings the active nexthop router once during each ping interval. The ping-interval is specified in milliseconds and has a minimum value of 500 milliseconds or 1/2 second. If the number of ping failures to the current nexthop destination exceed the ping-fail-max setting, the current nexthop destination is replaced in the routing table with the fallback nexthop destination.The system begins pinging the new nexthop router and monitoring the number of ping failures. The revertive period is set by the system based on a multiple of the ping interval and retry count.

Note: The cost (metric) of the fallback route is automatically calculated to be one more than the cost of the first active route.

Configuring IP redundancyTo configure IP redundancy:

1 Add a route with the IP addresses of the nexthop router and fallback router.

zSH> route add default 192.168.34.254 1 fallback 192.168.34.201 2000 3

zSH> route add 10.10.1.0 255.255.255.0 192.168.34.254 1 fallback 192.168.34.201 3000 5

2 Display the configured IP routes.

zSH> show route ... Source Routing Table



Dest Nexthop Cost Owner Interface ---------------------------------------------------------------------------

Destination Routing Table

Dest Nexthop Cost Owner Fallback ---------------------------------------------------------------------------0.0.0.0/0 192.168.34.254 1 STATICLOW 10.10.1.0/24 192.168.34.254 1 STATIC 192.168.34.201 192.168.34.0/24 1/1/1/0/ip 1 LOCAL

3 To delete the primary and fallback routes:

zSH> route delete 10.10.1.0 255.255.255.0 192.168.34.254 fallback 192.168.34.201

route command updates

Administers the routing information base (RIB). The route add and route delete commands take a keyword called source which indicates that a source route is used and must to added or removed from the source routing table. The user must also specify the IP interfaces of the next hop.The route show command now accepts an optional keyword of either source or destination which specifies the type of routing table is to be displayed. If the keyword is not used, both source and destination routing tables are displayed.

Syntax The following command displays the forwarding information base.

route [domain domain-spec] show [source|destination]

domain domain-specSpecifies the routing domain. Only domain 1 is supported.

showDisplays the routes in the route domain for source and destination routing.

Syntax The following command adds a high-preference static route for the destination IP address with the specified network mask (dotted decimal format) to the specified next hop with the specified routing cost. The word ‘default’ may be substituted for a 0.0.0.0 destination and mask. If a ‘fallback’ route is also specified, a second next hop, ping interval (in milliseconds), and ping maximum failure count must be specified.

Fallback routes have the same destination and mask as the original route, but use a different next hop. After a route and fallback route are configured, the current next hop is pinged once every ping interval. If the number of ping maximum failures is exceeded, the fallback next hop becomes the current next hop. The next hop validation continues once every ping interval.

route [ domain domain-spec ] add [source] destination-address netmask nexthop-address

Configuring IP


nexthop-interface metric [fallback nexthop2 ping-interval ping-fail-max]


sourceIndicates that a source address based route is being added. The interface is the name of the outbound (egress) interface for this route (minus the /ip suffix).

destination-address netmaskAdds a static route with the specified destination and network mask.

nexthop-addressIP address of the next hop.

nexthop-interfaceInterface for the next hop. This is valid only when the next-hop address is 0.0.0.0. Otherwise, this should be 0 (zero). This option is currently unsupported.

metricA numeric value specifying the metric for the route. Lower metrics indicate more preferred routes.

nexthop2IP address of the fallback or redundant next hop.

ping-intervalThe ping interval with a minimum value of 500 milliseconds.

maxretryThe max retry (fail) count for the pings. When this limit is reached, the fallback nexthop is used.

Syntax The following command deletes a static route from the system routing table. The word ‘default’ may be substituted for a 0.0.0.0 destination and mask. The fallback and nexthop2 options must be specified to delete routes configured with fallback routes.

route [ domain domain-spec ] delete [source] destination-address netmask nexthop-address nexthop-interface [fallback nexthop2 ping-interval ping-fail-max]


source Specifies that a source address based route is being removed. The interface is the name of the outbound (egress) interface for this route (without the /ip suffix).

destination-address netmaskDeletes the destination address and netmask from the routing table.



nexthop-addressIP address of the next hop address.

nexthop-interfaceInterface for the next hop. This is valid only when the next-hop address is 0.0.0.0. Otherwise, this should be 0 (zero). This option is currently unsupported.

nexthop2IP address of the fallback or redundant next hop.

ping-intervalThe ping interval with a minimum value of 500 milliseconds.

maxretryThe max retry (fail) count for the pings. When this limit is reached, the fallback nexthop is used.

Example

zSH> route showSource Routing TableDest Nexthop Cost Owner Interface------------------------------------------------------------------------------10.10.201.2/32 10.10.201.1 1 STATIC 1/1/1/0/ip10.10.204.2/32 10.10.204.1 1 STATIC 1/1/1/0/ipDestination Routing TableDest Nexthop Cost Owner-------------------------------------------------------------0.0.0.0/0 172.24.94.254 1 STATICLOW10.10.201.2/32 1/1/1/0/ip 1 LOCAL10.10.204.0/30 1/1/1/0/ip 1 LOCAL172.24.94.0/24 1/1/1/0/ip 1 LOCAL172.16.80.0/24 172.24.94.254 1 STATIC

zSH> route show sourceSource Routing TableDest Nexthop Cost Owner Interface------------------------------------------------------------------------------10.10.201.2/32 10.10.201.1 1 STATIC 1/1/1/0/ip10.10.204.2/32 10.10.204.1 1 STATIC 1/1/1/0/ip

zSH> route show destinationDestination Routing TableDest Nexthop Cost Owner-------------------------------------------------------------0.0.0.0/0 172.24.94.254 1 STATICLOW10.10.201.2/32 1/1/1/0/ip 1 LOCAL10.10.204.0/30 1/1/1/0/ip 1 LOCAL172.24.94.0/24 1/1/1/0/ip 1 LOCAL172.16.80.0/24 172.24.94.254 1 STATICzSH>

zSH> route add source 198.168.1.1 255.255.255.255 198.168.1.101 1 uplink1-0-36

Configuring IP


zSH> route add default 192.168.34.254 1 fallback 192.168.34.201 2000 3

zSH> route add 10.10.1.0 255.255.255.0 192.168.34.254 1 fallback 192.168.34.201 3000 5

zSH> show route ... Source Routing Table

Dest Nexthop Cost Owner Interface ---------------------------------------------------------------------------

Destination Routing Table

Dest Nexthop Cost Owner Fallback ---------------------------------------------------------------------------0.0.0.0/0 192.168.34.254 1 STATICLOW 10.10.1.0/24 192.168.34.254 1 STATIC 192.168.34.201 192.168.34.0/24 1/1/1/0/ip 1 LOCAL

zSH> route delete source 198.168.1.1 255.255.255.255 198.168.1.101 uplink1-0-36zSH>

zSH> route delete 10.10.1.0 255.255.255.0 192.168.34.254 fallback 192.168.34.201

Access Level admin

Products BAN, MALC, Raptor 100, Raptor 319, Raptor 719, Raptor 723, Sechtor 100A, Z-Edge 64

See Also rip

Configuring the MALC for IP videoWhen configuring an interface for IP video, you should dedicate a VCL to deliver the IP video to the subscriber. transmitting other types of traffic over the same VCL as video could affect the quality of the video. This section provides an example of how to create a video connection on the MALC. For details on video bridging, see Video bridging, page 152.


Configuring a video connection between the MALC and the ZRGThe following example configures an IP video connection between the MALC and the ZRG over an ADSL interface. The video is delivered over a bridged connection and the IP video server is reached via a GigaBit Ethernet

Configuring the MALC for IP video


Uplink card. This example uses the ZRG default configuration. Most of these procedures are done on the MALC.

1 (Perform this step on the ZRG) Update the video-system-profile to specify the IP address of the IP video server and associated services. In this example, the IP address of the IP video server is 192.168.3.200:

zSH> update video-system-profile 1Please provide the following: [q]uit.ntp-server-address: -----------------> {0.0.0.0}: 192.168.72.1 epg-server-address: -----------------> {192.168.34.165}: 192.168.72.1settop-box-head-end-server-address: -> {0.0.0.0}: default-channel: --------------------> {0.0.0.0}: 224.10.10.1 no-channel-available: ---------------> {0.0.0.0}: 224.10.10.1 epgType: ----------------------------> {myrio}:epgPort: ----------------------------> {8500}: epgFtpAddress: ----------------------> {192.168.34.165}: 192.168.72.1....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

2 Create an IP interface on the MALC GigaBit Ethernet port with VLAN ID 999 for the IP video:

zSH> interface add 1-1-2-0/ethernetcsmacd vlan 999 192.168.1.14/24Created ip-interface-record ethernet2-999/ip

3 Create a mapping between the video connection and the multicast address space. The video profile specifies the interface the MALC uses to reach the IP video server. (The following example uses the Uplink interface to reach the IP video server). Multisource multicast enables IGMP join/leaves to the video headend for each configured video-source profile. One video-source profile is assigned to each GigE uplink interface.

Use the videosource command to configure the mapping between the video connection and the multicast address space.

zSH> videosource add 224.1.1.1 1-1-2-0/ip Added video-source profile

zSH> videosource showDomain: 0 multicastAddr: 224.1.1.1 IfName: 1-1-2-0/ip

zSH> get video-source 1Please provide the following: [q]uit.routing-domain: ----> {1}: multicast-address: -> {224.1.1.1}: ifIndex: -----------> {ethernet2-999/ip}: vpi: ---------------> {0}:vci: ---------------> {0}:....................

Use the videosource delete command to remove a video source:

zSH> videosource delete 224.1.1.1 1-1-2-0/ip

Configuring IP


Deleted video-source profile

Note: You only need to enter the first multicast address in the group.

4 Create a traffic descriptor for IP video (this example is for ADSL2+):

zSH> new atm-traf-descr 2 index can be any valuePlease provide the following: [q]uit.td_type: -----------------> {atmNoClpNoScr}:td_param1: ---------------> {0}: 44080td_param2: ---------------> {0}:td_param3: ---------------> {0}:td_param4: ---------------> {0}:td_param5: ---------------> {0}:cac-divider: -------------> {1}: td_service_category: -----> {ubr}: cbrtd_frame_discard: --------> {false}:usage-parameter-control: -> {true}: ....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

5 Create an floating (unnumbered) IP interface the desired IP interface record for the IP address that video set top boxes will use for their far end address.

The example uses the default interface name (interface name not specified) and 192.168.49.1 as the IP address and 255.0.0.0 as the subnet mask. The default name is used.

zSH> interface add float 192.168.49.1 255.0.0.0Created ip-interface-record Zhone1/ip


Note: The MALC may display a message that there is nothing to bind to. This message is informational. Continue with this procedure.

6 To create a DHCP server address pool for the far end video set top device, use the dhcp-relay command to create a relay agent. The subnet address/mask will be derived from the system's floating IP address, if present, or may be specified NULL for use only with bridged interfaces. If multiple floating IP records are present, the desired <name>/<type> may be specified.The range (or pool) of assignable addresses which that customer can be assigned can be specified in the dhcp-server-subnet profile..

zSH> dhcp-relay add Operation completed successfully.

Configuring the MALC for IP video


This network must specify the network for the IP video server. This example configures the MALC for DHCP relay on subnet 2 using Myrio server (192.168.88.73) at domain nat.myrio.net. The unnumbered IP address of the default router is 192.168.49.1.

To make advanced modifications to the DHCP settings, edit the dhcp-server-subnet profile.

zSH> update dhcp-server-subnet 2Please provide the following: [q]uit.network: ---------------> {0.0.0.0}: 192.168.49.0netmask: ---------------> {0.0.0.0}: 255.255.255.0domain: ----------------> {0}:range1-start: ----------> {0.0.0.0}: 192.168.49.5range1-end: ------------> {0.0.0.0}: 192.168.49.10range2-start: ----------> {0.0.0.0}:range2-end: ------------> {0.0.0.0}:range3-start: ----------> {0.0.0.0}:range3-end: ------------> {0.0.0.0}:range4-start: ----------> {0.0.0.0}:range4-end: ------------> {0.0.0.0}:default-lease-time: ----> {-1}:min-lease-time: --------> {-1}:max-lease-time: --------> {-1}:boot-server: -----------> {0.0.0.0}: 192.168.88.73bootfile: --------------> {}: default-router: --------> {0.0.0.0}: 192.168.49.1 ip-unnumbered interfaceprimary-name-server: ---> {0.0.0.0}:boot-server: -----------> {0.0.0.0}: 192.168.88.73secondary-name-server: -> {0.0.0.0}:domain-name: -----------> {}: nat.myrio.netsubnetgroup: -----------> {0}: 2stickyaddr: ------------> {enable}:external-server: -------> {0.0.0.0}: 192.168.88.73 external DHCP server address.................... Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

7 Create a multicast control list, which defines which multicast addresses the remote end video can access. By default, the multicast control list entry enables subscriptions up to the number of maximum video streams on the interface without control list checking. Video streams can be configured on 10/100, GigE, and other interfaces.

The following example adds three entries to multicast list 1:

zSH> new mcast-control-entry 1/1Please provide the following: [q]uit.ip-address: -> {0.0.0.0}: 224.1.1.1type: -------> {normal}:....................Save new record? [s]ave, [c]hange or [q]uit: s

Configuring IP


New record saved.

zSH> new mcast-control-entry 1/2Please provide the following: [q]uit.ip-address: -> {0.0.0.0}: 224.1.1.2type: -------> {perodic}:....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

zSH> new mcast-control-entry 1/3Please provide the following: [q]uit.ip-address: -> {0.0.0.0}: 224.1.1.3type: -------> {always-on}:....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Continue adding as many multicast entries as necessary.

To view the multicast control group, use the mcast show command:

zSH> mcast show mcl 1MCAST CONTROL LIST : 1 224.1.1.1 224.1.1.2 224.1.1.3 224.1.1.4 224.1.1.5 224.1.1.6 224.1.1.7 224.1.1.8 224.10.10.10 224.10.10.11 224.10.10.12 224.10.10.13

Note: The ip igmpstat command displays the ports receiving multicast traffic and the joined multicast group(s).

8 Add a host route for the video interface.

zSH> host add 1-5-1-0/adsl vc 0/36 td 2 dynamic 1 4 video 1/4

These examples assume 1 is the multicast control list index and 4 is the maximum number of IP video streams (from the IP interface record). By default, the multicast control list entry enables subscriptions up to the number of maximum video streams on the interface without control list checking.

IP administrative proceduresThe following IP administrative procedures are supported on the MALC:

• Modifying profiles created by host/interface add commands on page 87

• Displaying hosts on page 89

• Displaying interfaces on page 90

• Displaying routing information on page 90

• Deleting hosts on page 91

IP administrative procedures


• Deleting interfaces on page 91

• Deleting routes on page 91

• DHCP logging on page 92

• IP statistics commands on page 94

Modifying profiles created by host/interface add commands

After profiles have been created by the host add and interface add commands there are two methods of modifying the profiles:

• You can perform a host delete or interface delete, which deletes all associated profiles, then re-create those profiles with another host add or interface add command, specifying changes in the command line.

• You can modify the individual profiles which have been created by host add and interface add commands.

For example, the command:

zSH> host add 1-8-1-0/adsl vc 0/35 td 1 dynamic 1 3

Creates the following profiles:

ip-interface-record 1-8-1-0-adsl-0-35/ipip-interface-record 1-8-1-0-adsl-0-35-1/ipip-interface-record 1-8-1-0-adsl-0-35-2/ipip-interface-record 1-8-1-0-adsl-0-35-3/ip atm-vcl 1-8-1-0-adsl/atm/0/35atm-vcl 1-1-1-0-propvirtual/atm/0/32 atm-cc 1

Note: You must disable the cross-connect and the ATM-VCL before changing the AAL5 encapsulation type in active cross-connects.

The host add, and host delete commands, <slot> and <port> may be replaced with brackets containing numbers in series and/or (dash-separated) ranges; <port> may be replaced with wildcard '*' for all ports on the card. Refer to the CLI Reference Guide for a complete description of the command options and syntax.

Modifying individual profiles created by host/interface add1 Before modifying ATM-VCLs, the cross-connect in which they are used,

must be disabled:

zSH> update atm-cc 1Please provide the following: [q]uit.cc-index: ------> {1}: ** read-only **low-if-index: --> {1-1-1-0-propvirtual/atm}: ** read-only **low-vpi: -------> {0}: ** read-only **low-vci: -------> {32}: ** read-only **

Configuring IP


high-if-index: -> {1-8-1-0-adsl/atm}: ** read-only **high-vpi: ------> {0}: ** read-only **high-vci: ------> {35}: ** read-only **admin-status: --> {up}: downhandle-id: -----> {handle_1}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

2 Active VCLs must be disabled before making any modifications to them:

zSH> update atm-vcl 1-8-1-0-adsl/atm/0/35Please provide the following: [q]uit.vpi: -----------------------------> {0}: ** read-only **vci: -----------------------------> {35}: ** read-only **admin_status: --------------------> {up}: downreceive_traffic_descr_index: -----> {1}:transmit_traffic_descr_index: ----> {1}:vcc_aal_type: --------------------> {other}: ** read-only **vcc_aal5_cpcs_transmit_sdu_size: -> {9188}:vcc_aal5_cpcs_receive_sdu_size: --> {9188}:vcc_aal5_encaps_type: ------------> {other}:vcl_cast_type: -------------------> {p2p}:vcl_conn_kind: -------------------> {pvc}:fault-detection-type: ------------> {disabled}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

3 Make changes to the VCL:

zSH> update atm-vcl 1-8-1-0-adsl/atm/0/35Please provide the following: [q]uit.vpi: -----------------------------> {0}: ** read-only **vci: -----------------------------> {35}: ** read-only **admin_status: --------------------> {down}: receive_traffic_descr_index: -----> {1}:transmit_traffic_descr_index: ----> {1}:vcc_aal_type: --------------------> {other}: ** read-only **vcc_aal5_cpcs_transmit_sdu_size: -> {9188}:vcc_aal5_cpcs_receive_sdu_size: --> {9188}:vcc_aal5_encaps_type: ------------> {other}: llcencapsulationvcl_cast_type: -------------------> {p2p}:vcl_conn_kind: -------------------> {pvc}:fault-detection-type: ------------> {disabled}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

4 Re-enable the VCL:

zSH> update atm-vcl 1-8-1-0-adsl/atm/0/35Please provide the following: [q]uit.vpi: -----------------------------> {0}: ** read-only **



vci: -----------------------------> {35}: ** read-only **admin_status: --------------------> {down}: upreceive_traffic_descr_index: -----> {1}:transmit_traffic_descr_index: ----> {1}:vcc_aal_type: --------------------> {other}: ** read-only **vcc_aal5_cpcs_transmit_sdu_size: -> {9188}:vcc_aal5_cpcs_receive_sdu_size: --> {9188}:vcc_aal5_encaps_type: ------------> {llcencapsulation}: vcl_cast_type: -------------------> {p2p}:vcl_conn_kind: -------------------> {pvc}:fault-detection-type: ------------> {disabled}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

5 Re-enable the cross-connect after changes have been made:

zSH> update atm-cc 1Please provide the following: [q]uit.cc-index: ------> {1}: ** read-only **low-if-index: --> {1-1-1-0-propvirtual/atm}: ** read-only **low-vpi: -------> {0}: ** read-only **low-vci: -------> {32}: ** read-only **high-if-index: -> {1-8-1-0-adsl/atm}: ** read-only **high-vpi: ------> {0}: ** read-only **high-vci: ------> {35}: ** read-only **admin-status: --> {down}: uphandle-id: -----> {handle_1}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Displaying hosts

Issue the host show command to display hosts, which displays the IP address of the unnumbered interface used in the host route, interface of the host route, VPI/VCI of the internal VCL used to create the host, the subnet group to which the host belongs, whether the host is dynamically or statically assigned, and if the host has been assigned an IP address.

zSH> host showRd/Address Interface Group T Host Address--------------------------------------------------------------------------------1 10.0.0.1 1-11-1-0-adsl-0-35 0/32 1 D <unassigned> D <unassigned> D <unassigned> S 192.168.11.51 192.168.11.1 1-8-6-0-adsl-0-35 0/33 0 S 192.168.11.61 192.168.11.1 1-8-2-0-adsl-0-35 0/35 0 S 192.168.11.55

Configuring IP


Displaying interfaces

Issue the interface show command to display interfaces:

zSH> interface showInterface Status Rd/Address Media/Dest Address IfName--------------------------------------------------------------------------------1/1/1/0/ip UP 1 [10.0.0.1] 0/35 multipoint 1-5-1-0-adsl-0-35--------------------------------------------------------------------------------

Brackets around IP addresses in the output of the interface show command indicate unnumbered interfaces.

Displaying routing information

The following commands display routing information:

• route show

• rip show

Displaying the routing tableTo display the routing table, use the route show command:

zSH> route showDest Nexthop Cost Owner------------------------------------------------------------0.0.0.0/0 172.24.200.254 1 STATICLOW172.24.200.162/32 1 LOCAL172.24.200.0/24 1/1/1/0/ip 1 LOCAL

Displaying RIP informationTo display Routing Information Protocol (RIP) information, use the rip show command:

zSH> rip showRIP Globals----------------------------------------------------------Route Route Route Admin UpdateDomain Changes Queries State Time----------------------------------------------------------1 0 0 disabled 30----------------------------------------------------------RIP Interface Statistics------------------------------------------------------ Recv Bad Recv Bad UpdatesIfName Packets Routes Sent To------------------------------------------------------1-1-1-0 0 0 0uplink1 0 0 01-8-1-0-adsl-0-35 0 0 0



1-8-6-0-adsl-0-35 0 0 01-8-8-0-adsl-0-35 0 0 01-8-3-0-adsl-0-35 0 0 0RIP Interface Configuration-------------------------------------------------------------------------------- Auth Auth Default SrcIfName Type Key Talk Listen Metric Address Static Poison--------------------------------------------------------------------------------1-1-1-0 none (write-only) disabled disabled 0 172.24.200.162 none disableduplink1 none (write-only) disabled disabled 0 219.200.162.2 none disabled1-8-1-0-adsl-0-35 none (write-only) disabled disabled 0 192.168.11.1 none disabled1-8-6-0-adsl-0-35 none (write-only) disabled disabled 0 0.0.0.0 none disabled1-8-8-0-adsl-0-35 none (write-only) disabled disabled 0 0.0.0.0 none disabled1-8-3-0-adsl-0-35 none (write-only) disabled disabled 0 0.0.0.0 none disabledRIP Peers--------------------------------------------------------------------------------Route IP Last Recv Bad Recv BadDomain Address Update Version Packets Routes--------------------------------------------------------------------------------

Deleting hosts

Issue the host delete command to delete hosts. The host add, and host delete commands, <slot> and <port> may be replaced with brackets containing numbers in series and/or (dash-separated) ranges; <port> may be replaced with wildcard '*' for all ports on the card.

zSH> host delete 1-11-1-0/adsl vc 0/35 all

Deleting interfaces

Issue the interface delete command to delete interfaces:

zSH> interface delete 1-5-1-0/adsl vc 0/35Delete complete

Deleting routes

To delete static routes, use the route delete command. The command uses the following syntax:

zSH> route delete destination mask next-hop

The following example deletes the network route to 192.178.21.0 using the gateway 192.172.16.1:

Configuring IP


zSH> route delete 192.178.21.0 255.255.255.0 192.178.16.1

DHCP logging

The MALC provides a logging facility to monitor the DHCP packets it sends and receives. By default, DHCP messages are not displayed.

Enabling DHCP logging1 Enable the DHCP server log messages:

zSH> log level dhcpserver infoModule: dhcpserver at level: info

2 Enable logging for the session:

zSH> log session onLogging enabled.

As DHCP server messages are sent and received, they are displayed on the console.

Note: This setting does not persist across system reboots. You must re-enable DHCP logging after a MALC reboot.

3 These messages can be captured to a file using your terminal’s capture facility, or sent to a syslog server. For example:

zSH> new syslog-destination 1Please provide the following: [q]uit.address: --> {0.0.0.0}: 192.200.42.5 syslog server IP address port: -----> {514}: facility: -> {local0}:severity: -> {debug}:info....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Understanding DHCP server log messagesWhen a device sends a DHCP server request to the MALC, a message similar to the following is logged:

AUG 13 12:20:48: info : 1/1/1084: dhcpserver: DhcpServerTask: DHCPREQUEST for 155.57.1.21 from 00:b0:d0:98:92:3d via if496

This message indicates that a request for the address 155.57.1.21 was received by the device with the MAC address 00:b0:d0:98:92:3d. The request came in over the interface number 496.

To find what physical interface this corresponds to, use the ifxlate command:



zSH> ifxlate 496ifIndex: ----------> {496}shelf: ------------> {1}slot: -------------> {10}port: -------------> {48}subport: ----------> {0}type: -------------> {hdsl2}adminstatus: ------> {up}physical-flag: ----> {true}iftype-extension: -> {none}ifName: -----------> {1-10-48-0}

The MALC sends the following message when it acknowledges the DHCP request packet.

AUG 13 12:20:48: info : 1/1/1084: dhcpserver: DhcpServerTask: DHCPACK on 155.5 7.1.21 to 00:b0:d0:98:92:3d via if496

Viewing client leasesWhen the MALC issues a DHCP client lease, it creates a dhcp-server-lease. You can view these records to see the status of the lease:

1 List the current leases:

zSH> list dhcp-server-leasedhcp-server-lease 0/155/57/1/10dhcp-server-lease 0/155/57/1/11dhcp-server-lease 0/155/57/1/12dhcp-server-lease 0/155/57/1/13dhcp-server-lease 0/155/57/1/14dhcp-server-lease 0/155/57/1/15dhcp-server-lease 0/155/57/1/17dhcp-server-lease 0/155/57/1/18dhcp-server-lease 0/155/57/1/19dhcp-server-lease 0/155/57/1/16dhcp-server-lease 0/155/57/1/20dhcp-server-lease 0/155/57/1/21dhcp-server-lease 0/155/57/1/22dhcp-server-lease 0/155/57/1/2314 entries found.

2 To view an individual record:

zSH> get dhcp-server-lease 0/155/57/1/10starts: ------------> {1060700857}ends: --------------> {1060700917}flags: -------------> {0}hardware-address: --> {00:00:c5:90:3b:08}client-identifier: -> {}client-hostname: ---> {}hostname: ----------> {}dns-fwd-name: ------> {}dns-rev-name: ------> {}

Configuring IP


Note that 0/155/57/1/10 represents routing domain 0, and the IP address 155.57.1.10.

IP statistics commands

The following IP commands are available to users with administrative privileges.

• ip icmpstat

Displays ICMP statistics.

• ip ifstat

Displays interface statistics.

• ip ifsum

Displays a summarized list of known interfaces.

• ip inetstat

Displays the active TCP/UDP/RAW endpoints terminating on the card.

• ip ipstat

Displays IP statistics.

• ip tcpstat

Displays TCP statistics.

• ip udpstat

Displays UDP statistics.

• ip arpdelete

Deletes an entry from the ARP table.

• ip arpflush

Flushes the ARP table of all entries.

• ip arpshow

Displays the ARP table.


CONFIGURING BRIDGING

This chapter explains how to configure bridging on the MALC. It includes the following sections:

• Overview, page 95

• Broadcasts and bridging, page 103

• VLANs, page 105

• Q-in-Q, page 110

• Untagged bridging, page 114

• Ethernet RPR, page 116

• Linear GigaBit Ethernet, page 132

• Advanced bridging configurations, page 142

• PPPoA - PPPoE Conversion, page 137

• PPPoE Intermediate Agent, page 140

• Administrative commands, page 149

• COS in bridges, page 150

• Video bridging, page 152

OverviewBridges are configured using the bridge add command and the desired bridge type (upl for uplink, dwn for downlink, int for intralink, tls for TLS, hub for hub, and no type for transparent. This command assigns the bridge-interface-record profile to the specified interface.To facilitate bridge setup, the MALC sets the default values for this profile based on the usage of the downlink and uplink command parameters. For VLAN bridges, use the downlink and uplink parameters to create bridges on the interfaces with the default downlink and uplink bridge settings.

Refer to the CLI Reference Guide for a complete description of the command options and syntax.

Configuring Bridging


Note: The MALC ports can support both IP termination or bridging on different virtual circuits. However, each virtual circuit must be configured for either IP termination or bridging and cannot support both at the same time.

Note: When routed and bridged traffic is configured for the same uplink interface, VLAN tags must be used between both downlink ports and the uplink interface for traffic differentiation. For routed traffic, use the ip-interface-record profile to specify the VLAN ID.

Bridging involves configuring the MALC to direct traffic based on Ethernet MAC addresses. The MALC supports a variety of asymmetrical and symmetrical bridge types which enable different methods to learn, forward, and manipulate traffic.

• Asymmetrical bridge types are uplink, downlink, and intralink.

– Uplink bridges

An uplink bridge uses one bridge interface in a VLAN as a default, and traffic from all other interfaces exits the system from this interface. As the default interface, packets entering the system on this interface do not have their source MAC addresses learned and associated with this interface. Traffic coming into this uplink interface is sent to the interface where the address has been learned. If the frame is a broadcast, it is filtered, unless it is an ARP or DHCP message that meets some special criteria. Unicasts received on an uplink port are forwarded to the downlink where the MAC address was learned.

Uplink bridge interfaces require an additional bridge-path configuration to set a default path for either a specific VLAN or globally for the system onto the uplink bridge. If an uplink is missing this configuration, traffic will not flow across the asymmetric VLAN.

– Down link bridges

A downlink bridge is used in conjunction with an uplink bridge. where the uplink bridge is the path upstream to the network, and the downlink bridge is the learning interface facing subscribers. Traffic coming into this interface is forwarded to the uplink regardless of the destination MAC address. Broadcasts and unicasts (known and unknown) will be sent out the default interface, which is the uplink bridge for the VLAN.

Packets entering the system on this interface have their source MAC addresses learned and associated with this interface. Because this interface is not a default, it is required to learn MAC addresses, so that frames from the network that come in on the uplink bridge can be

Overview


sent to the correct downlink bridge. Broadcasts received on a downlink are sent to the uplink (default) without filtering. Broadcasts will not flow to other downlinks as long as forwardtodefault parameter is set to true. Downlink ports learn MAC addresses.

– Intralink bridges

An intralink bridge is used in conjunction with an uplink bridge, where the uplink bridge is the path upstream to the network, and the intralink forwards traffic with unknown MAC addresses or multicasts to the configured bridge interface without attempting to learn the addresses of the attached devices or network.. Traffic coming into this interface is forwarded to the uplink regardless of the destination MAC address. Broadcasts, multicasts, and unicasts (known and unknown) will be sent out the default interface, which is the uplink bridge for the VLAN.

Packets entering the system on this interface will not have their source MAC addresses learned since this interface is not used when a MAC is known.

Intralink bridge interfaces require an additional configuration to take effect, which is a bridge-path. The bridge-path sets a default intralink path for either a specific VLAN or a global intralink for the system onto the intralink bridge. If an intralink is missing this configuration, traffic will not flow across the asymmetric VLAN.

• Symmetrical bridge types are transparent, transparent LAN service (TLS), and hub.

– Transparent bridge

Transparent or untagged bridges which forward traffic based on MAC addresses but do not provide segregation of traffic. Traffic is broadcast over the Ethernet port and is either accepted or rejected based on the destination MAC address. There is no VLAN tagging; all ports are learning and forwarding without restriction and without broadcast suppression. Forwarding to a default port is not allowed.

– Transparent LAN service

A TLS bridge is used with only other TLS bridges. This should not be used with any asymmetrical bridges. TLS bridges learn MAC addresses and forward packets to learned destinations. Broadcasts and unknown unicasts are flooded out all interfaces except the ingress interface.

Packets entering the system on TLS interface have their source MAC addresses learned and associated with the interface so that frames from the network that come in on other TLS bridges in the VLAN can be sent to the correct interface.

– Hub bridge



A hub bridge is used with only other hub bridges. Hub bridges do not learn MAC addresses, but flood packets of all types to every other bridge interface in the VLAN, where all ports receive every frame received on the hub interface.

Packets entering the system on this interface do not have their source MAC addresses learned so that frames from the network that come in on other hub bridges in the VLAN can be sent to the correct interface.

Bridges also utilize VLAN tagging for tagged and untagged traffic segregation.

• Tagged bridging

Tagged or Virtual LANs (VLANs) bridging, which forwards traffic based on MAC addresses and allows the segregation of a single Ethernet network into multiple virtual network segments by mapping ATM VCLS to VLAN IDs.

• Untagged bridging

Untagged or transparent bridging which forwards traffic based on MAC addresses but does not provide segregation of traffic. Traffic is broadcast over the Ethernet port and is either accepted or rejected based on the destination MAC address. There is no VLAN tagging; all ports are learning and forwarding without restriction without broadcast suppression. Forwarding to a default port is not allowed.

Bridges are configured using the bridge add command and the desired bridge type (upl for uplink, dwn for downlink, int for intralink, tls for TLS, hub for hub, and no type for transparent. This command assigns the bridge-interface-record profile to the specified interface.To facilitate bridge setup, the MALC sets the default values for this profile based on the usage of the downlink and uplink command parameters. For VLAN bridges, use the downlink and uplink parameters to create bridges on the interfaces with the default downlink and uplink bridge settings.

For transparent bridges, the type parameter is omitted to create bridges on the interfaces with default transparent bridge settings. In the bridge add, bridge delete commands, <slot> and <port> may be replaced with brackets containing numbers in series and/or (dash-separated) ranges; <port> may be replaced with wildcard '*' for all ports on the card.


Note: The MALC ports can support both IP termination or bridging on different virtual circuits. However, each virtual circuit must be configured for either IP termination or bridging and cannot support both at the same time.

Bridge default settings for asymmetric bridges


Note: When routed and bridged traffic is configured for the same uplink interface, VLAN tags must be used between both downlink ports and the uplink interface for traffic differentiation. For routed traffic, use the ip-interface-record profile to specify the VLAN ID.

Bridge default settings for asymmetric bridgesTable 4 lists the default bridge-interface-record settings for the supported asymmetric bridge options.

Table 4: Default values for asymmetric bridge-interface-record

Parameter Uplink Downlink Downlink Tagged Intralink

vpi 0 for Ethernet interfaces.As specified for other interfaces.

0 for Ethernet interfaces.As specified for other interfaces.



vci 0 for Ethernet interfaces.As specified for other interfaces.




vlanId 0 As specified As specified 0

stripAndInsert False True False False

customARP True False False False

filterBroadcast True False False False

learnIP False True True False

learnUnicast False True True False

maxUnicast 0 5 5 0

learnMulticast False True True False

forwardToUnicast True False False False

forwardToMulticast True False False False

forwardToDefault False True True True

floodUnknown False False False False

floodMulticast False False False False

valndIdCOS 0 0 0 0

outgoingCOSOption Disable Disable Disable Disable

outgoingCOSValue 0 0 0 0

s-tagTPID 0x8100 0x8100 0x8100 0x8100



Bridge default settings for symmetric bridgesTable 5 lists the default bridge-interface-record settings for the supported symmetric bridge options.

s-tagId 0 0 0 0

s-tagStripAndInsert False False False False

s-tagOutgoingCOSOption s-tagdisable s-tagdisable s-tagdisable s-tagdisable

s-tagIdCOS 0 0 0 0

s-tagOutgoingCOSValue 0 0 0 0

Table 4: Default values for asymmetric bridge-interface-record

Parameter Uplink Downlink Downlink Tagged Intralink

Table 5: Default values for symmetric bridge-interface-record

Parameter Tranparent TLS Hub

vpi 0 for Ethernet interfaces.As specified for other interfaces.



vci 0 for Ethernet interfaces.As specified for other interfaces.



vlanId 0 As specied As specified

stripAndInsert True True True

customARP False False False

filterBroadcast False False False

learnIP False False True

learnUnicast Truee True False

maxUnicast 5 100 0

learnMulticast False False False

forwardToUnicast True True False

forwardToMulticast False False False

forwardToDefault False False True

floodUnknown False True True

floodMulticast False True True

Bridge enhancements to flood unknowns and multicasts


The bridge show command displays the bridge type.

zSH> bridge showTyp VLAN Bridge State Table Data------------------------------------------------------------------------------------upl Tagged ethernet1/bridge UP S Global default [U: 3600 sec, M: 150 sec, I: 0 sec]

0 1-8-5-0-adsl-0-32/bridge PENDING0 1-8-4-0-adsl-0-32/bridge PENDING

dwn 0 1-8-10-0-adsl-0-35/bridge PENDINGdwn 0 1-8-11-0-adsl-0-35/bridge PENDINGdwn 0 1-12-1-0-shdsl-0-35/bridge PENDINGdwn 0 1-12-2-0-shdsl-0-35/bridge PENDINGdwn 0 1-9-1-0-adsl-0-35/bridge DOWN

Bridge enhancements to flood unknowns and multicastsBridges are now enhanced to enable VPN-like services using the floodUnknowns and floodMulticast parameters. These parameters enable the MALC to forward unknown traffic to all bridge interfaces within the VLAN.

FloodUnknown parameter

The FloodUknown parameter provides the ability to toggle the flooding of unknown unicast destination frames. When this parameter is set to true, the MALC always forwards frames with an unknown unicast MAC if the bridge is set for forward to unicast. When this parameter is set to false, the MALC always discards frames with an unknown unicast MAC if the bridge is set for

bridgeIfCustomDHCP False False False

bridgeIfConfigGroupIndex 0 0 0

valndIdCOS 0 0 0

outgoingCOSOption Disable Disable Disable

outgoingCOSValue 0 0 0

s-tagTPID 0x8100 0x8100 0x8100

s-tagId 0 0 0

s-tagStripAndInsert False False False

s-tagOutgoingCOSOption s-tagdisable s-tagdisable s-tagdisable

s-tagIdCOS 0 0 0

s-tagOutgoingCOSValue 0 0 0

Table 5: Default values for symmetric bridge-interface-record

Parameter Tranparent TLS Hub



forward to unicast. Any frame that does not find a match in the forwarding table will be discarded.

For transparent bridges, the default setting for this parameter is true. For uplink bridges, the default setting for this parameter is false.

FloodMulticast parameter

The FloodMulticast parameter allows the MALC to flood all multicast traffic received on a bridge out to all other ports in the VLAN. This is useful for architectures where the MALC is acting as an aggregation point with no user interfaces. By default, this parameter is set to false for all bridge types.

When set to true, this parameter causes all multicast frames to be forwarded out all of the bridge interfaces within the VLAN, except the interface where the multicast was received.

zSH> update bridge-interface-record 1-8-1-0-ethernetcsmacd/bridgePlease provide the following: [q]uit.vpi: ----------------------> {0}:vci: ----------------------> {0}:vlanId: -------------------> {500}:stripAndInsert: -----------> {false}:customARP: ----------------> {false}:filterBroadcast: ----------> {false}:learnIp: ------------------> {true}:learnUnicast: -------------> {true}:maxUnicast: ---------------> {10000}:learnMulticast: -----------> {true}:forwardToUnicast: ---------> {false}:forwardToMulticast: -------> {false}:forwardToDefault: ---------> {true}:bridgeIfCustomDHCP: -------> {false}:bridgeIfConfigGroupIndex: -> {0}:vlanIdCOS: ----------------> {0}:outgoingCOSOption: --------> {disable}:outgoingCOSValue: ---------> {0}:s-tagTPID: ----------------> {0x8100}:s-tagId: ------------------> {0}:s-tagStripAndInsert: ------> {false}:s-tagOutgoingCOSOption: ---> {s-tagdisable}:s-tagIdCOS: ---------------> {0}:s-tagOutgoingCOSValue: ----> {0}:mcastControlList: ---------> {}:maxVideoStreams: ----------> {0}:isPPPoA: ------------------> {false}:floodUnknown: -------------> {false}:floodMulticast: -----------> {false}:....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

Broadcasts and bridging


Broadcasts and bridgingThe MALC supports a modified form of broadcast suppression when configured for bridge mode. The MALC configures ports as the entered bridge type.

In general, broadcasts sent from a downlink will traverse the uplink, but will not be sent down other downlinks, even within the same VLAN. This prevents subscribers from maliciously or unintentionally sending or receiving broadcasts between ports on the same system.

Ports configured as uplinks will send broadcasts upstream, but by default will not propagate broadcasts sent from the upstream down to the MALC. The filterBroadcast parameter in the bridge-interface-record profile enables this filtering. This mechanism provides security benefits, as well as reducing unnecessary traffic on low bandwidth interfaces.

One exception to the operational mode described above is ARP broadcast support. When a MALC receives a broadcast frame, it is checked to determine if it is an ARP protocol packet or not. If it is not, it is treated as above. If it is, then the MALC compares and filters the requested IP address with the current forwarding table. If a match is found, the ARP broadcast is forwarded out the interface that has the appropriate host. This host will then reply to the ARP with a standard response. If a match is not found, then the ARP is filtered and it gets dropped as if it were a non-ARP broadcast. This setting is controlled by the customARP parameter.

Another exception to this broadcast filtering is DHCP broadcast support. When a MALC receives a broadcast DHCP OFFER message from a remote DHCP server, if customDHCP is set to true, the broadcast messages are forwarded to the source MAC address. Otherwise, the broadcast DHCP messages are filtered.


TLS Bridging behavior for untagged, tagged, and s-taggedBridges also utilize VLAN and SLAN tagging for tagged, s-tagged, and untagged traffic segregation.

• Tagged bridging

Tagged or Virtual LANs (VLANs) bridging, accepts single-tagged packets based on MAC addresses and allows the segregation of a single Ethernet network into multiple virtual network segments by mapping packets based on the VLAN ID. If a non-zero VLAN ID is configured, the interface accepts only tagged packets matching this VLAN ID. If a VLAN of 0 (zero) is configured, the interface accepts all VLAN tagged packets not matching any configured VLANs on the same interface.



A conifgured SLAN tag is inserted into outgoing packets whe bridge forwarding selects a double-tagged egress interface. Only non-zero SLAN values are recommended for tagged bridges.

• s-tagged

Double-tagged or Service LANs (SLANs) bridging, accepts and sends double-tagged traffic based on MAC addresses and allows the segregation of a single Ethernet network into multiple virtual network segments by mapping packets based on VLAN ID and SLAN ID. If non-zero VLAN ID and SLAN ID are configured, the interface accepts and sends only tagged packets matching both VLAN ID and SLAN ID. If a VLAN of 0 (zero) is configured with a non-zero SLAN ID, the interface accepts and sends only double-tagged packets matching the SLAN and any VLAN tagged packets not destined to another client on the same interface.

When both the VLAN and SLAN tags are zero (0), the bridge accepts all single or double tagged packets not destined to another client on the same interface.

• Untagged bridging

Untagged or transparent bridging accepts and sends traffic based on MAC addresses but does not provide traffic segregation. Traffic is broadcast over the Ethernet port and is either accepted or rejected based on the destination MAC address. There is no VLAN tagging; all ports are learning and forwarding without restriction, without broadcast suppression. Forwarding to a default port is not allowed. If bridge forwarding selects a single or double-tagged egress interface, the configured VLAN and SLAN tags will be inserted in to packets destined for this interface. Only non-zero values are recommended for VLAN and SLAN settings of untagged bridges.

For VLAN tagged (single tagged) bridges, the bridge interface name includes the VLAN ID, even the default VLAN ID of 0. Other examples of a single tagged bridge also show a tagged bridge with VLAN 4000 and a tagged bridge with VLAN 1000 and SLAN 17.

zSH> bridge add 1-3-5-0/eth taggedzSH> bridge add 1-3-5-0/eth vlan 4000 taggedzSH> bridge add 1-3-5-0/eth vlan 1000 slan 17 tagged

zSH> bridge showTyp VLAN Bridge State Table Data------------------------------------------------------------------------------ Tagged 1-3-5-0-eth-0/bridge PENDING

Tagged 4000 1-3-5-0-eth-4000/bridge PENDING Tg 1000/17 1-3-5-0-eth-1000/bridge PENDING

For VLAN and SLAN tagged (double tagged) bridges, the bridge interface name includes the VLAN ID and SLAN ID, even the default VLAN ID of 0 and the default SLAN of 0. Other examples of doubled tagged bridges also

VLANs


show a bridge with VLAN 4094 and SLAN 4094, a bridge with VLAN 0 and SLAN 17, and a bridge with VLAN 500 and default SLAN.

zSH> bridge add 1-3-5-0/eth vlan 4094 slan 4094 s-taggedzSH> bridge add 1-3-5-0/eth vlan 0 slan 17 s-taggedzSH> bridge add 1-3-5-0/eth s-taggedzSH> bridge add 1-3-5-0/eth vlan 500 s-tagged

zSH> bridge showTyp VLAN Bridge State Table Data------------------------------------------------------------------------------ ST 4094/4094 1-3-5-0-eth-4094-4094/bridge PENDING ST 0/17 1-3-5-0-eth-0-17/bridge PENDING s-tagged 1-3-5-0-eth-0-0/bridge PENDING Tagged 500 1-3-5-0-eth-500-0/bridge PENDING

Bridges can be deleted by specified VLAN ID, SLAN ID, type of tagging, and all option. Specifying a VLAN ID all single and double tagged bridges configured for that VLAN.

To delete a bride by a specific SLAN tag:

zSH> bridge delete 1-3-5-0/eth slan 17

To delete a bridge by a specific VLAN tag or tag type:

zSH> bridge delete 1-3-5-0/eth vlan 500

zSH> bridge delete 1-3-5-0/eth tagged

To delete all s-tagged bridges on a port:

zSH> bridge delete 1-3-5-0/eth s-tagged all

To delete all VLAN 0 bridges on a port:

zSH> bridge delete 1-3-5-0/eth vlan 0 all

VLANsFigure 12 shows a typical VLAN configuration. On the access (subscriber) side, VLANs 1 and 2 are separate DSL networks connected to the MALC via Z-Edge devices. On the uplink side, VLANs 1 and 2 are on the same physical Ethernet interface, but the traffic is separated based on the VLAN IDs.

The side of the connection closest to the subscriber is called the downlink interface. The upstream egress is called the uplink interface. When the MALC is in VLAN mode, it adds (tags) the VLAN ID to the Ethernet frame on the uplink interface and strips (untags) the ID out on the downlink interface. Although VLAN IDs are not typically required on downlink interfaces, you



can configure downlink interface as tagged. Tagged downlink interfaces can be used for subtended MALCs or subscribers expecting tagged traffic with Transparent LAN Server (TLS) service.

Note: The MALC supports VLAN IDs from 1 to 4096. Multiple VLAN interfaces can be added to the same physical port and VC.

Figure 12: Example VLAN network

You can configure static VLAN bridge paths, which requires that you enter a MAC address for every bridge on the Ethernet. Or, you can set up the MALC Ethernet interface to learn the VLAN IDs when it receives a packet from a downlink device.

Note that if the MALC receives a packet from an uplink interface before it has learned the VLAN ID or MAC address, it will not deliver the packet.

VLANs


Figure 13: Learning a VLAN ID

Configuring a VLAN bridgeTo configure a VLAN bridge:

1 Use the bridge add command to add a bridge for the downstream connection. Multiple VLAN interfaces can be added to the same physical port and VC.

zSH> bridge add 1-8-1-0/adsl vc 0/35 td 1 downlink vlan 555zSH> bridge add 1-8-1-0/adsl vc 0/36 td 1 downlink vlan 777

This example adds downlink VLAN interfaces to the ADSL modem in shelf 1, slot 8, port 1 with VLAN IDs of 555 and 777. It uses the VCLs 0/35 and 0/36, traffic descriptor 1 as a transport, sets the parameters to the downlink settings, and assigns port VLAN ID 555 and 777.

The following bridge-interface-record is created with the downlink default settings and shows the internal VPI/VCI cross connects. It is recommended not to change the default settings unless advanced bridge configuration is required.

zSH> get bridge-interface-record 1-8-1-0-adsl-0-35-555/bridgevpi: ----------------------> {0}vci: ----------------------> {35}vlanId: -------------------> {555}stripAndInsert: -----------> {true}customARP: ----------------> {false}filterBroadcast: ----------> {false}learnIp: ------------------> {true}learnUnicast: -------------> {true}maxUnicast: ---------------> {5}learnMulticast: -----------> {true}forwardToUnicast: ---------> {false}forwardToMulticast: -------> {false}



forwardToDefault: ---------> {true}bridgeIfCustomDHCP: -------> {false}bridgeIfConfigGroupIndex: -> {0} vlanIdCOS: ----------------> {0}outgoingCOSOption: --------> {disable}outgoingCOSValue: ---------> {0}s-tagTPID: ----------------> {0x8100}s-tagId: ------------------> {0}s-tagStripAndInsert: ------> {false}s-tagOutgoingCOSOption: ---> {s-tagdisable}s-tagIdCOS: ---------------> {0}s-tagOutgoingCOSValue: ----> {0}mcastControlList: ---------> {0}maxVideoStreams: ----------> {0}isPPPoA: ------------------> {false}floodUnknown: -------------> {false}floodMulticast: -----------> {false}

zSH> get bridge-interface-record 1-8-1-0-adsl-0-35-777/bridgevpi: ----------------------> {0}vci: ----------------------> {35}vlanId: -------------------> {777}stripAndInsert: -----------> {true}customARP: ----------------> {false}filterBroadcast: ----------> {false}learnIp: ------------------> {true}learnUnicast: -------------> {true}maxUnicast: ---------------> {5}learnMulticast: -----------> {true}forwardToUnicast: ---------> {false}forwardToMulticast: -------> {false}forwardToDefault: ---------> {true}bridgeIfCustomDHCP: -------> {false}bridgeIfConfigGroupIndex: -> {0} vlanIdCOS: ----------------> {0}outgoingCOSOption: --------> {disable}outgoingCOSValue: ---------> {0}s-tagTPID: ----------------> {0x8100}s-tagId: ------------------> {0}s-tagStripAndInsert: ------> {false}s-tagOutgoingCOSOption: ---> {s-tagdisable}s-tagIdCOS: ---------------> {0}s-tagOutgoingCOSValue: ----> {0}mcastControlList: ---------> {0}maxVideoStreams: ----------> {0}isPPPoA: ------------------> {false}floodUnknown: -------------> {false}floodMulticast: -----------> {false}

2 Use the bridge add command to add a VLAN interface to the upstream Ethernet interface:zSH> bridge add 1-1-1-0/ethernetcsmacd uplink

VLANs


This command adds a learning bridge that accepts VLAN traffic and enables VLAN trunking on the MALC unit’s egress Ethernet port.

3 Configure the uplink interface to learn the VLAN IDs of all ingress Ethernet devices or a specific VLAN ID: zSH> bridge-path add ethernet1/bridge global

The global setting specifies that the MALC should send all VLAN traffic to this port. A VLAN ID can also be used when the MALC should send only traffic from a specific VLAN ID to this port. (The ethernet1 interface is the first Ethernet interface on the MALC.) It is recommended not to change the default settings unless advanced bridge configuration is required.

zSH> get bridge-interface-record ethernet1/bridgevpi: ----------------------> {0}vci: ----------------------> {0}vlanId: -------------------> {0}stripAndInsert: -----------> {false}customARP: ----------------> {true}filterBroadcast: ----------> {true}learnIp: ------------------> {false}learnUnicast: -------------> {false}maxUnicast: ---------------> {0}learnMulticast: -----------> {false}forwardToUnicast: ---------> {true}forwardToMulticast: -------> {true}forwardToDefault: ---------> {false}bridgeIfCustomDHCP: -------> {false}bridgeIfConfigGroupIndex: -> {0} vlanIdCOS: ----------------> {0}outgoingCOSOption: --------> {disable}outgoingCOSValue: ---------> {0}s-tagTPID: ----------------> {0x8100}s-tagId: ------------------> {0}s-tagStripAndInsert: ------> {false}s-tagOutgoingCOSOption: ---> {s-tagdisable}s-tagIdCOS: ---------------> {0}s-tagOutgoingCOSValue: ----> {0}mcastControlList: ---------> {}maxVideoStreams: ----------> {0}isPPPoA: ------------------> {false}floodUnknown: -------------> {false}floodMulticast: -----------> {false}

4 Verify connectivity by pinging a far end device on the VLAN.

Note: To delete a downlink bridge with a VLAN, the VLAN ID must be specified in the bridge delete command.



Q-in-QThe IEEE 802.1Q-in-Q VLAN tagging expands the VLAN space in the Ethernet frame to support the tagging of previously tagged packets. This second tag (SLAN) creates a "double-tagged" Ethernet frame. The double-tagged Ethernet frame enables service providers to offer additional services, such as Internet access on specific SLANs for specific customers, while still providing single-tagged VLAN services.

The MALC also supports setting COS values in the Ethernet SLAN headers for bridged packets. This service enables you to assign a service level or class of service (COS) to an Ethernet SLAN that is transported across a uplink, intralink, or downlinked s-tagged bridge. The configured COS level specifies the packet priority and queueing methods used to transport the packet through the Ethernet network. The MALC sets and preserves the COS settings to ensure these settings are passed to other Ethernet devices in the network for QOS processing.


Figure 14 illustrates a network of MALC devices configured to support separate SLANs per MALC while also providing individual VLANs per customer port.

Q-in-Q


Figure 14: Q-in-Q Bridging

Configuring Q-in-Q using the Interface command

For Q-in-Q VLAN tagging, the interface profile supports the following parameters:

• s-tagTPID

Identifies the type of VLAN ID used. Typically set to 8100.

• s-tagID

Specifies the SLAN ID assigned to an Ethernet frame.

• s-tagIDCOS

Specifies the COS ID associated with the SLAN ID



The interface command supports adding s-tagIDs from the command line. This example adds interface ethernet1 with VLAN 100, SLAN 200, COS value of 7 and sCOS value of 8.

interface add ethernet1/ip vc 0/35 td 20000 other vlan 100 slan 200 cos 7 scos 8 172.16.88.46 255.255.255.0

zSH> get ip-interface-record ethernet1/ipvpi: ---------------> {0}vci: ---------------> {0}rdindex: -----------> {1}dhcp: --------------> {none}addr: --------------> {172.16.88.46}netmask: -----------> {255.255.255.0}bcastaddr: ---------> {172.16.88.255}destaddr: ----------> {0.0.0.0}farendaddr: --------> {0.0.0.0}mru: ---------------> {1500}reasmmaxsize: ------> {0}ingressfiltername: -> {}egressfiltername: --> {}pointtopoint: ------> {no}mcastenabled: ------> {yes}ipfwdenabled: ------> {yes}mcastfwdenabled: ---> {yes}natenabled: --------> {no}bcastenabled: ------> {yes}ingressfilterid: ---> {0}egressfilterid: ----> {0}ipaddrdynamic: -----> {static}dhcpserverenable: --> {false}subnetgroup: -------> {0}unnumberedindex: ---> {0}mcastcontrollist: --> {}vlanid: ------------> {100}maxVideoStreams: ---> {0}tosOption: ---------> {disable}tosCOS: ------------> {7}vlanCOS: -----------> {0}s-tagTPID: ---------> {0x8100}s-tagId: -----------> {200}s-tagIdCOS: --------> {8}

Configuring Q-in-Q using the Bridge command

For Q-in-Q VLAN tagging, the bridge profile supports the following parameters:

• s-tagTPID

Identifies the type of VLAN ID used. Typically set to 8100.

Q-in-Q


• s-tagID

Specifies the SLAN ID assigned to an Ethernet frame.

• s-tagStripAndInsert

Specifies whether to strip and insert s-tag values in Ethernet frames received and transmitted on the bridge interface.

• s-tagOutgoingCOSOption

Specifies whether to insert COS value bits on outgoing s-tag packets.

• s-tagIDCOS

Specifies the COS ID associated with the SLAN ID

• s-tagOutgoingCOSValue

Specifies the value used to overwrite any existing COS value in outgoing s-tag packets.

Syntax bridge add

The bridge command supports adding s-tagIDs from the command line. This example adds interface 1-8-22-0/adsl with VLAN 100, SLAN 101, COS value of 7 and sCOS value of 8.

bridge add 1-8-22-0/adsl vc 0/35 td 20000 downlink vlan 100 slan 200 tagged COS 7 scos 8

To display the bridge-record profile, enter the show bridge-interface-record or bridge show command.

zSH> show bridge-interface-record 1-8-22-0-adsl-0-35/bridgevpi: ----------------------> {0}vci: ----------------------> {32}vlanId: -------------------> {100}stripAndInsert: -----------> {true}customARP: ----------------> {false}filterBroadcast: ----------> {false}learnIp: ------------------> {true}learnUnicast: -------------> {true}maxUnicast: ---------------> {5}learnMulticast: -----------> {false}forwardToUnicast: ---------> {false}forwardToMulticast: -------> {false}forwardToDefault: ---------> {true}bridgeIfCustomDHCP: -------> {false}bridgeIfConfigGroupIndex: -> {0}vlanIdCOS: ----------------> {7}outgoingCOSOption: --------> {disable}outgoingCOSValue: ---------> {0}s-tagTPID: ----------------> {0x8100}s-tagId: ------------------> {200}s-tagStripAndInsert: ------> {true}s-tagOutgoingCOSOption: ---> {s-tagdisable}s-tagIdCOS: ---------------> {8}



s-tagOutgoingCOSValue: ----> {0}mcastControlList: ---------> {0}maxVideoStreams: ----------> {0}isPPPoA: ------------------> {false}floodUnknown: -------------> {false}floodMulticast: -----------> {false}

zSH> bridge showTyp VLAN Bridge State Table Data-----------------------------------------------------------------

100/200 ethernet1/bridge UP D 00:50:04:df:c0:7aUpl Tagged uplink1-0-101/bridge UP S VLAN 100 default [3600 sec]

Bridge path enhancementsFor Q-in-Q VLAN tagging, the bridge path profile supports the s-tagID parameter to specifies the SLAN ID assigned to an Ethernet frame in static bridge configurations.

The bridge-path command supports adding s-tagIDs from the command line. This example creates a static bridge between an interface and a specific IP address and VLAN 300. It also adds an SLAN of 400

zSH> bridge-path add 1-1-4-0/ds3 vlan 300 slan 400 ip 192.16.80.1

To display bridge-path interface records with vlan and slan values, use the bridge-path show command.

zSH> bridge-path showTyp VLAN/SLAN Bridge Address--------------------------------------------------------------------Upl 300/400 uplink1-0-101/bridge Default

Untagged bridgingConfiguring untagged or transparent bridging enables you to forward traffic from a downlink interface through the MALC uplink interface based on the destination MAC address without tagging or modification to the frame. Refer to the CLI Reference Guide for a complete description of the command options and syntax.


Configuring an untagged bridgeTo add an untagged bridge:

1 Add an untagged bridge to the downstream DSL interface:

zSH> bridge add 1-8-2-0/adsl vc 0/101 td 1

Untagged bridging


Created bridge-interface-record 1-8-2-0-adsl-0-101/bridge

This example adds a default transparent bridge interface to the ADSL modem in shelf 1, slot 8, port 2. It uses the VCL 0/101 and traffic descriptor 1 as a transport and sets the parameters to the default transparent bridge interface settings.

The following examples shows the default bridge-interface-record settings with the internal vpi/vci cross connects. It is recommended not to change the default settings unless advanced bridge configuration is required.

zSH> get bridge-interface-record 1-8-2-0-adsl-0-101/bridgevpi: ----------------------> {0}vci: ----------------------> {101}vlanId: -------------------> {0}stripAndInsert: -----------> {true}customARP: ----------------> {false}filterBroadcast: ----------> {true}learnIp: ------------------> {true}learnUnicast: -------------> {true}maxUnicast: ---------------> {5}learnMulticast: -----------> {true}forwardToUnicast: ---------> {false}forwardToMulticast: -------> {false}forwardToDefault: ---------> {true}bridgeIfCustomDHCP: -------> {false}bridgeIfConfigGroupIndex: -> {0}

2 Add a transparent bridge to the upstream Ethernet interface:

zSH> bridge add 1-1-1-0/ethernetcsmacd Created bridge-interface-record 1-1-1-0-ethernetcsmacd/bridge

This command adds a bridge that accepts transparent/untagged traffic on the MALC units’s egress Ethernet port.

The following shows the default transparent bridge-interface-record settings for the uplink. It is recommended not to change the default settings unless advanced bridge configuration is required.

zSH> get bridge-interface-record ethernet1/bridgevpi: ----------------------> {0}vci: ----------------------> {0}vlanId: -------------------> {0}stripAndInsert: -----------> {false}customARP: ----------------> {true}filterBroadcast: ----------> {true}learnIp: ------------------> {false}learnUnicast: -------------> {false}maxUnicast: ---------------> {0}learnMulticast: -----------> {false}forwardToUnicast: ---------> {true}forwardToMulticast: -------> {true}forwardToDefault: ---------> {false}



bridgeIfCustomDHCP: -------> {false}bridgeIfConfigGroupIndex: -> {0}

3 Verify that both sides of the bridge are present:

zSH> bridge showTyp VLAN Bridge State Table Data-----------------------------------------------------------------dwn 0 1-8-2-0-adsl-0-101/bridge UP upl 0 1-1-1-0-ethernetcsmacd/bridge UP

4 Test the bridge by pinging a device on the far end network and verifying e that the bridge table is updated:

zSH> bridge show Typ VLAN Bridge State Table Data-----------------------------------------------------------------dwn 0 1-8-2-0-adsl-0-101/bridge UP D 00:01:47:cf:ae:04upl 0 1-1-1-0-ethernetcsmacd/bridge UP D 00:01:02:70:03:a2

Ethernet RPREthernet Resilient Packet Ring (RPR) provides redundant Ethernet links between MALC RPR nodes and an IP or outside network. Following the IEEE 802.17 standard, Ethernet packets are inserted, stripped, and forwarded between the RPR Uplink and ring nodes to create a resilient architecture with high bandwidth utilization and less than 50ms protection switching.

Overview

An RPR configuration consists of an MALC RPR Uplink node that serves as a gateway between the RPR ring and the Internet or outside network, and a number of RPR ring nodes that process traffic between themselves and the Uplink node. A dual counter-rotating ring is used so traffic can be transmitted and received in both ring directions.

The RPR Uplink node must have two 2-port GigE Uplink cards connected with a redundant RPR cable. Each ring node requires one 2-port GigE card with an optional GigE card added for redundancy.

Note: See the MALC Hardware Installation Guide for more details about adding redundant GigE-2 cards to the MALC.

The 2-port GigE card utilizes Small Form-factor Pluggable (SFPs) for flexible deployment over fiber or copper media for data-only or integrated voice, video, and data connections. SFP modules with the following Gigabit Interface Convertors (GBICs) are available for a variety of transmission choices:

• SX for 850nm with multimode fiber (MMF)

Ethernet RPR


• LX for 1310nm with singlemode fiber (SMF)

• ZX for 1550nm with singlemode fiber (SMF)

• 1000B-T for copper cable

See the MALC Hardware Installation Guide for more details about the supported SFPs.

RPR can be deployed in a variety of topologies including ring, collapsed ring, star, linear and redundant card configurations. This section uses a basic 3-node ring topology as an example topology to demonstrate node functionality and port connections.

RPR ring topologyIn RPR ring topologies, two physical ports on the GigE cards are used as the single logical RPR ring port. For redundant GigE cards, including as the two GigE cards used in the RPR uplink node, the physical ports labeled port 1 on the redundant cards form the single logical RPR port. For non-redundant GigE cards, the ports labeled port 1 and port 2 on the single GigE card form the single logical RPR port.

Note: The recommended maximum number of nodes in an RPR ring is 16.

In RPR configurations, the following logical interfaces are used:

• interface 1-1-1-0 /ethernetcsmacd uses the first physical port labeled 10/100 for the 10/100 Ethernet physical interface.

• interface 1-1-1-0/rpr uses the two physical ports assigned to the logical RPR port.

In redundant GigE card configurations, the physical ports labeled port 1 on the redundant cards form the single logical RPR port. In non-redundant GigE card configurations, the physical ports labeled port 1 and port 2 on the same card from the single logical RPR port.

• interface 1-1-3-0 is assigned to physical port 2 in redundant GigE card configurations for upstream or subtended GigE connections.



Figure 15: RPR logical ports

Physical ports are connected around the ring in the east direction so that port 1 on the active RPR Uplink node connects to the port 2 on the adjacent ring node. On the redundant RPR Uplink node card, port 1 connects in the west direction to the port 1 on the adjacent ring node.

Traffic to the IP or outside network goes through the interface 1-1-3-0 assigned to physical port 2 on the RPR Uplink node’s active and standby cards. A redundant cable connects the physical RDNT ports between the RPR Uplink node’s active and redundant GigE cards.

Neighbor RPR ring nodes with single GigE cards connect in the east direction through physical port 1 to facial port 2.

Figure 16 illustrates a 3 node RPR configuration and physical port connections.

��

��

��

��

��

��

��

��

��

��

��

��

��

Ethernet RPR


Note: Because the MALC RPR ring uses dual counter-rotating rings, each connecting line in this figure represents two actual fibers. Each fiber transports send and receive traffic in a different direction around the ring.

Figure 16: RPR configuration

RPR ring topology with redundant GigE cardsRedundant GigE cards can also be used at each ring node to add an additional level of equipment protection. As with the RPR uplink node, redundant cables connect RDNT ports between the RPR ring nodes. Also in the RPR ring nodes, the physical ports labeled port 1 on the active and standy cards form the single logical RPR port interface 1-1-1-0/rpr. Physical port 2 on the active and standby cards in the ring nodes can be unconnected or connected to subtended nodes.

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��!

��



For the physical connections in this configuration, connect the physical ports so that on the RPR Uplink node the active card port 1 connects in the west direction to the adjacent RPR ring node port 1. On the redundant card in the Uplink node, port 1 connects in the east direction to the adjacent RPR ring node port 1.The neighbor RPR ring nodes connect through the physical ports labeled port 1. Physical ports labeled port 2 are not connected or may be used for GigE connections to subtended devices.

Traffic to the IP or upstream network goes through the primary RPR Uplink node on active and standby card’s physical port 2.

Figure 17 illustrates a basic RPR configuration with redundant cards on the ring nodes.


Interface 1-1-1-0/ethernetcsmacd is assigned to the 10/100 Ethernet physical interface.

Ethernet RPR


Figure 17: RPR configuration with redundant ring nodes

RPR ring topology with redundant GigE cards and subtended MALCsIn this configuration, redundant cables also connect RDNT ports between the RPR ring nodes. Also in the RPR ring nodes, the physical ports labeled port 1 on the active and standy cards form the single logical RPR port interface 1-1-1-0/rpr.

For the physical connections in this configuration, connect the physical ports so that on the RPR Uplink node the active card port 1 connects in the west direction to the adjacent RPR ring node port 1. On the redundant card in the Uplink node, port 1 connects in the east direction to the adjacent RPR ring node port 1.The neighbor RPR ring nodes connect through the physical ports labeled port 1.

��

��

��

"�� # ��$��

�� %��

��

&��

��

��

��

��

��

��

��

��

��!



Physical ports labeled 2 on the active and standby cards function as the subtended GigE connection and use interface 1-1-3-0/ethernetcsmacd.

Traffic to the IP or upstream network goes through the RPR Uplink node on active and standby card’s physical port 2 using interface 1-1-3-0/ethernetcsmacd.

Figure 18 illustrates a basic RPR configuration with redundant cards on the ring nodes and subtended MALCs.


Interface 1-1-1-0/ethernetcsmacd is assigned to the 10/100 Ethernet physical interface.

Ethernet RPR


Figure 18: RPR configuration with redundant ring nodes and subtended MALC

RPR configuration

RPR basic configuration involves configuring the primary Uplink node with 2 GigE Uplink cards and then configuring each RPR ring node with a single GigE Uplink card. Redundant GigE Uplink cards can also be added to RPR ring nodes for additional card protection.

This section contains the following procedures:

• Configuring RPR protection switching on page 124

• Displaying RPR configuration on page 125

��

��

��

"�� # ��$��

�� %��

��

! ��

�'��!

&��

��

��

��

��

��

��

��

��

��

��

( �� '�� ( �� '��

��

��

��

��!



• Displaying RPR topology on page 126

• Displaying RPR status on page 128

• Displaying RPR statistics on page 129

Configuring RPR protection switchingMALC RPR configurations support less than 50ms protection switching for fiber breaks or ring failures in the RPR ring.

RPR nodes support a Wrap protection strategy. This protection strategy determines the timing and type of protection that is used when a span fault occurs. When Wrap is configured as false (the default setting) and a ring protection event occurs, the RPR node does not send traffic in the direction of the ring failure. Instead, traffic is steered or redirected to the destination in the opposite direction of the ring failure.

When Wrap is configured as true, the RPR node sends traffic out to the destination even if it is in the direction of a ring failure. When the failure is encountered, traffic wraps or returns in the other direction back through the sending node to the destination.

The Wrap false setting offers lower packet latency as packets do not have to travel to the ring failure and then traverse the ring in the opposite direction to get to the destination. However, with this setting more packet loss may occur as packets sent in the direction of a ring failure may be lost. The Wrap true setting helps prevent packet loss, but increases packet latency as packets sent in the direction of a ring failure are rerouted back to the destination in the opposite direction.

Other protection switching options include:

• reversion mode

The reversion mode determines if traffic resumes processing in the normal direction after a protection event is cleared.

• wait-to-restore (wtr) time

The wtr time determines how long the node waits after a protection event is cleared before traffic processing reverts back to the normal direction.

• fast timer

This timer indicates how often in milliseconds the node sends out ‘fast’ status messages when a protection event occurs.

• slow timer

This timer indicates how often the node sends out ‘slow’ status messages when a protection event occurs. This value is in 50 millisecond (ms) intervals. For example, a value of 100 equals 5 seconds.

To change the protection switching options, update the rpr-config profile.

zSH> update rpr-config 1-1-1-0/rprPlease provide the following: [q]uit.

Ethernet RPR


reversion-mode: --------> {true}:protection-wtr: --------> {10}: 20protection-fast-timer: -> {10}:protection-slow-timer: -> {100}:wrap-config: -----------> {false}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Displaying RPR configuration The MALC rpr show config command displays information about the current RPR node configuration.

zSH> rpr show configsysObject= 0x66bc578, systemId= 0, pParent= 0x7de9ba0, ethDrvNum= 0rprStarted= 1, bridgeExists= 1npRprContext= 0x100 (BrgExst,Steer,)rprCtrlSema4= 0x492a740, taskIdSema4= 0x0, lastTaskIdSema4= 0x66b06e8rprStationSema4= 0x4b43fd0, taskIdStationSema4= 0x0, lastTaskIdStationSema4= 0x66b06e8NpGigePacketWrap= 4/5, unitPhy= 0/1, outMacPort= 1/0Encoding= 0xf810/0xf811, rxRegistered= 1/1txSlowTimeout= 100ms, txFastTimeout= 10ms, ticksPer100ms= 10atdTimerTimeout= 1000ms, lastAtdSentTime= 2687770topoChanged= 0, protectChanged= 0containmentActive= 0, containmentStart= 1055191, containmentDuration= 60ms

containmentCnt= 6, containmentTotal= 13310msnewNeighbor= 0/0, revertive= 1, tossWrongRingletIDs= 0lrttActive= 1, lrttComplete= 1, lrttContextId= 7lrttTime= 1055197, lrttDuration= 210ms, lrttIncompletionTimeout= 1000mstvState= tvValid, tvTopoCheck= 3, stabilityTime= 1055192, instabilityTime= 1055191stabilityTO= 40ms, instabilityTO= 10000mstopologyValid= 1, topologyStable= 1, topologyUnstableTime= 1055191, topologyUnstableDuration= 60msadminReqProtection= ???/???, spanProtAdmin= IDL/IDLspanOperStatus= IDL/IDL, linkErrCode= UPneedSecondaryMacValidation= 1, cleavePt= 1/1notifyCleavePtChange= 0/0, notifyTopoChange= 0/0WTR[0]: time= 10541840, timeout= 10000ms, enabled= 1WTR[1]: time= 237920, timeout= 10000ms, enabled= 1tcState= tcReturn, puState= puReturn, ptpState= ptpReturnDefect: miscabling= 0/0, Start= 0/0, Duration= 0ms/0ms

protMisconfig= 0, Start= 0, Duration= 0mstopoEntryInvalid= 0, Start= 1054951, Duration= 60msmaxStations= 0, Start= 0, Duration= 0mstopoInconsist= 0, Start= 1042700, Duration= 340mstopoInstab= 0, Start= 0, Duration= 0ms

nextLogId= 209, totalLogEntrys= 209current time = 2687864 ticks (26878640ms)



Displaying RPR topologyMALC RPR topology displays information about an RPR ring for ring diagnostics and management. From an RPR node’s perspective, other nodes to in the west direction or left of the current node are on ringlet 0. Nodes in the east direction or right of the current node are on ringlet 1. The number of hops between nodes is determined by counting the number of nodes in a specified ringlet or direction. The current node is always at hop 0.

This illustration shows an example 3-node topology.

Using ring node B as the current node, ringlet 0 (zero) is in the west direction or left. From node B, traffic on ringlet 0 travels to node A, to node C and back to node B. In ringlet 0, node A is one hop from node B, while node C is two hops away.

Ringlet 1 is in east direction or right. From node B, traffic on ringlet 1 travels to node C, to node A and back to node B. In ringlet 1, node C is one hop from node B, while node A is two hops away.

�

��

)!��

��!��

��

��

��

��

��

�� *

��

��

��

��

��

��

��

��

��!

��

Ethernet RPR


Use the rpr show topo command to display topology, statistics, configuration, and status information.

zSH> rpr show topototal number of ring nodes= 3 (ringlet 0= 2, ringlet 1= 2)ring protection= STEERING, ring topology= CLOSED ringcontainment= NOT active, topology valid= truelink status: west(PSW)= Signal OK (IDL), east(PSE)= Signal OK (IDL)R=reachable; WE=west/east edge state; PSW/PSE=west/east protect statering hop R WE PSW PSE -------MAC------- ------IP------- 0 3 t ff IDL IDL 00:01:47:5a:aa:2a 192.168.50.142 0 2 t ff IDL IDL 00:01:47:5a:aa:22 192.168.50.146 0 1 t ff IDL IDL 00:01:47:5a:aa:1a 192.168.50.144**** 0 t ff IDL IDL 00:01:47:5a:aa:2a 192.168.50.142 1 1 t ff IDL IDL 00:01:47:5a:aa:22 192.168.50.146 1 2 t ff IDL IDL 00:01:47:5a:aa:1a 192.168.50.144 1 3 t ff IDL IDL 00:01:47:5a:aa:2a 192.168.50.142

This example topology uses node B as the current node. There are a total of 3 nodes in the ring, the current node and 2 nodes in each ringlet. Ring protection is set to Steering (Wrap=false). There are no protection events so the ring is closed and containment is not active. Containment causes data packets that are not strictly ordered to be discarded when a topology change or protection event occurs. The current topology is valid. Causes of invalid topology include miscabling, malfunctioning links, and other connectivity issues.

For each node in the ring, the topology displays the following data:

Field Description

ring 0 indicates ringlet 0 and the east direction around ring. 1 indicates ringlet 1 and the west direction around ring.**** indicates the current node.

hop Number of hops upstream and downstream from the current node. The current node is always displayed with a hop count of 0. To validate the passing of traffic through the complete ring and back to the current node, the current node also appears at the last hop in both ringlets.

R Reachable. t indicates the connection to the node is valid and reachable. f indicates the connection to the node is not valid and is unreachable.

WE West and east span fault status. An edge indicates a span fault occurred. t indicates an edge exists and the edge status is true. f indicates an edge does not exist and the edge status is false.



Displaying RPR statusThe MALC rpr show status command displays status information about the RPR ring for ring diagnostics and management.

zSH> rpr show statussysObject= 0x66bc578, systemId= 0, pParent= 0x7de9ba0, ethDrvNum= 0rprStarted= 1, bridgeExists= 1npRprContext= 0x100 (BrgExst,Steer,)rprCtrlSema4= 0x492a740, taskIdSema4= 0x0, lastTaskIdSema4= 0x4984b60rprStationSema4= 0x4b43fd0, taskIdStationSema4= 0x0, lastTaskIdStationSema4= 0x66b06e8NpGigePacketWrap= 4/5, unitPhy= 0/1, outMacPort= 1/0Encoding= 0xf810/0xf811, rxRegistered= 1/1txSlowTimeout= 100ms, txFastTimeout= 10ms, ticksPer100ms= 10atdTimerTimeout= 1000ms, lastAtdSentTime= 2752070topoChanged= 0, protectChanged= 0containmentActive= 0, containmentStart= 1055191, containmentDuration= 60mscontainmentCnt= 6, containmentTotal= 13310msnewNeighbor= 0/0, revertive= 1, tossWrongRingletIDs= 0lrttActive= 1, lrttComplete= 1, lrttContextId= 7lrttTime= 1055197, lrttDuration= 210ms, lrttIncompletionTimeout= 1000mstvState= tvValid, tvTopoCheck= 3, stabilityTime= 1055192, instabilityTime= 1055191stabilityTO= 40ms, instabilityTO= 10000mstopologyValid= 1, topologyStable= 1, topologyUnstableTime= 1055191, topologyUnstableDuration= 60msadminReqProtection= ???/???, spanProtAdmin= IDL/IDLspanOperStatus= IDL/IDL, linkErrCode= UPneedSecondaryMacValidation= 1, cleavePt= 1/1notifyCleavePtChange= 0/0, notifyTopoChange= 0/0WTR[0]: time= 10541840, timeout= 10000ms, enabled= 1

PSW/PSE The protection state on the west (PSW) and east (PSE) span. Values:IDL: Protection status is idle, signal OK. Link is up with neighbor.WTR: Wait-to-restore. The span has recovered from a fault but it’s been configured to wait a period of time before restoring the card’s connection. The wait-to-restore time is configured in the protection-wtr parameter in the rpr-config profile. MS: User has requested the span to deactivate. Not supported. SD: Signal degraded. Not supported. SF: Signal failure. Link is down with neighbor.FS: User has forced span to deactivate. Not supported.

MAC The MAC address of the node.

IP IP address of the node. If the node has multiple IP interfaces on the RPR port, the interface associated with the lowest VLAN ID is displayed.

Field Description

Ethernet RPR


WTR[1]: time= 237920, timeout= 10000ms, enabled= 1tcState= tcReturn, puState= puReturn, ptpState= ptpReturnDefect: miscabling= 0/0, Start= 0/0, Duration= 0ms/0ms

protMisconfig= 0, Start= 0, Duration= 0mstopoEntryInvalid= 0, Start= 1054951, Duration= 60msmaxStations= 0, Start= 0, Duration= 0mstopoInconsist= 0, Start= 1042700, Duration= 340mstopoInstab= 0, Start= 0, Duration= 0ms

nextLogId= 209, totalLogEntrys= 209current time = 2752107 ticks (27521070ms)

Displaying RPR statisticsThe MALC rpr show stats command displays both RPR transmit and receive statistics about the RPR ring performance for ring diagnostics and management.

The rpr show stats optional argument clear will clear the statistics. The noclr argument (the default) preserves the current statistics.

rpr-node2-zSH> rpr show stats

TX: Requests= 3604, Ok= 3604, BadSrcMac= 0, Switch2Bridge= 8 Data: ip= 3596, ucst= 2963, bcst= 633, bridge= 8, ec_so= 0 DstUnreachable= 0, Data_containment= 0 CtLrttReq: ok= 270, fail= 0 CtLrttRsp: ok= 200, fail= 0 CtTC: ok= 3312442, fast= 718, fail= 0, triggers= 290 CtTP: ok= 3312625, fast= 901, fail= 0, triggers= 192 CtATD: ok= 331153, fail= 0, nodata= 30 Idle: ok= 0, fail= 0 Fairness: ok= 0, fail= 0RX: Data: total= 1306065, bf= 1574, ef= 1304491, containment= 0, ec_so= 1304491 Idle= 0, Fairness= 0 Ct= 17571585, Ct_badType= 0, Ct_badVersion= 0 CtTP: total= 11741085, ignore= 0, ignoreOthers= 0, suspect= 0 CtTP_redundant[ hop=1 ]: 1689268, 3311135 CtTP_redundant[ hop=2 ]: 1684453, 1686970 CtTP_redundant[ hop=3 ]: 1684482, 1684478 CtTC: total= 4997664, bad= 0 CtLrttReq: total= 214, ignore= 14

CtATD: total= 832407, ignore= 0, dup= 0, badType= 0, badLen= 0

ZhOrg= 0, badZhType= 0, badZhLen= 0

CtLrttRsp: total= 215, ignore= 0, exceed= 0, bad= 0lrtt_starts= 108, lrtt_fails= 0, lrtt_stops= 107, lrtt_multiple= 0contextChgs= 218, cleavePtChgs= 7/51, topoChgs= 79/57linkChgs= 52/4, linkChgNotifies= 56CDT: Add= 29, Add2= 54, Del= 26, Del2=104



Switches= 54, SwitchTreeHops1/2/3= 1/78/0 MacChgs= 0, Unexp1/2/3/4/5/6= 0/0/0/0/0/0

Adding bridges to RPR ringBridges can be configured in a RPR ring so bridged subscriber traffic can be transported across the ring and connected to the destination IP or outside network.

The illustration below shows the bridge configurations in a 3-node RPR ring:

• Uplink node

The RPR Uplink node contains a bridge uplink and global bridge-path on the redundant GigE active and standy card ports labelled port 2 (1-1-3-0/ethernetcsmacd) to direct all bridged traffic to the outside or IP network. The RPR Uplink node also contains a global-intralink on the GigE active and standby card ‘s logical RPR ports (1-1-1-0/rpr) so unknown traffic is sent to the ring, even though address learning is not enabled.

• Ring node 1

This RPR ring node contains a bridge uplink on the redundant GigE card’s logical RPR port (1-1-1-0/rpr) to direct all outgoing bridged traffic to the RPR Uplink node. This node also contains a bridge downlink on the ADSL card 1-1-5-0 so VLAN tags can be stripped and inserted for subscriber VLAN participation.

• Ring node 2

This RPR ring node contains a bridge uplink on the redundant GigE card’s logical RPR port (1-1-1-0/rpr) to direct all outgoing bridged traffic to the RPR Uplink node. This node also contains a bridge intralink on port 2 (1-3-1-0/ethernetcsmacd) to a subtended MALC. A bridge intralink is used in place of a bridge downlink so unknown packets are forwarded to subscribers without the need to learn all downlink subscriber MAC addresses.

Note: If a subtended device is configured to request DHCP services from a DHCP server through the IP or outside network, ensure that the CustomDHCP setting is set to true in the bridge-interface-records on the RPR Uplink and ring nodes.

Ethernet RPR


To configure bridges in an RPR ring:

1 On the Uplink node

a Add a bridge interface to the second GigE port (this is the port connected to the external network):

zSH> bridge add 1-1-3-0/ethernetcsmacd uplink

b Add a default bridge path for the ring over the second GigE port:zSH> bridge-path add ethernet3/bridge global

All bridge traffic will be forwarded over this interface.

c Add an bridge intralink on the logical RPR port:zSH> bridge add 1-1-1-0/rpr intralink



zSH> bridge-path add rpr1/bridge global-intralink

Unlearned traffic received on this interface is forwarded to the external network.

d Add a global bridge intralink path:zSH> bridge-path add rpr1/bridge global-intralink

This interface is the global intralink for the ring.

2 On the RPR ring node to which subscribers are connected:

a Add an uplink bridged interface on the logical RPR port:zSH> bridge add 1-1-1-0/rpr uplink

b Add a default bridge path that points to the Uplink node:zSH> bridge-path add rpr1/bridge global

c Add a downlink to the remote subscriber:zSH> bridge add 1-5-1-0/adsl vc 0/37 td 4000 downlink vlan 100

3 On the other RPR ring node to which a subtended MALC is connected:



c Add an intralink to the subtended MALC:zSH> bridge add 1-1-3-0/ethernetcsmacd intralink

zSH> bridge-path add ethernet3/bridge global-intralink

4 On the RPR ring node to which subscribers are connected from the subtended MALC:



c Add a downlink to the remote subscriber:zSH> bridge add 1-7-1-0/adsl vc 0/37 td 4000 downlink vlan 200

Linear GigaBit EthernetThe MALC GigE-2 Uplink card also supports a linear topology in which several MALC devices are daisy-chained together to pass traffic and provide subscriber access. The card type in the card profile is used to differentiate linear configuration from RPR ring configuration. In linear configurations, all



ports are ethernetcsmacd ports as described below. Single card or redundant card configurations can be used.

Figure 19 illustrates the GigE-2 card linear configuration using single GigE-2 Uplink cards. Additional MALC nodes can be added to the daisy-chained linear topology by repeating this pattern of connections.

Note: Interface 1-1-1-0 is assigned to the 10/100 Ethernet physical interface. Interface 1-1-2-0 is assigned to physical port 1. Interface 1-1-3-0 is assigned to physical port 2.

Figure 19: GigE linear configuration with single card

Redundant GigE-2 cards can also be used to provide card-level redundancy. Figure 20 illustrates the GigE-2 Uplink card linear configuration using redundant cards.



Figure 20: GigE linear configuration with redundant cards

GigE-2 Uplink card redundant configuration in linear topology

This section describes the optional configuration procedures for the GigE-2 Uplink redundant card configuration in a linear topology. These procedures should be done before provisioning the system.

See the MALC Hardware Installation Guide for more details about adding redundant GigE-2 cards to the MALC.

Configuring GigE-2 card redundancyThe GigE-2 card can be configured for redundancy so the GigE uplink card switches to a standby GigE card when the active Ethernet link goes down.

Options for this card switchover include:

• switching timeout

The amount of time the active card waits when a failure occurs before switching to the standby card.

• reversion mode



The reversion mode determines if traffic reverts back to the initial active card after a protection event is cleared.

• restore timeout

After a switchover occurs, the amount of time the active card waits after the protection event is cleared before reverting back to the other card.

1 To configure card redundancy, use the line-red command on the active card.

zSH> line-red set ethernet1/ip timeout 30 revertive timeout 600

This command sets card redundancy between the currently active GigE-2 card and the standby GigE-2 card. The switch timeout is set to 30 seconds with the revertive option set to occur after a 600 second timeout.

The standby card must be in a running state for a switchover to occur.

2 Display the redundancy setting.

zSH> line-red show ethernet1/ipredundacy status for ethernet1/ip: REBOOT timeout 30 REVERTIVE revert timeout 600

GigE-2 card bridging

Within the linear topology, bridging can be configured to forward traffic based on MAC address and VLAN ID to an IP or outside network. The node connected to the network contains a bridge uplink and global bridge-path on the GigE-2 card’s first port (1-1-2-0) to direct all bridged traffic to the outside or IP network. This card also contains a global-intralink on the GigE-2 card’s second port (1-1-3-0) so unknown traffic is sent to the downstream, even though address learning is not enabled.

The second node in the daisy-chained linear topology contains a bridge uplink on the GigE-2 card’s first port (1-1-2-0) to direct all outgoing bridged traffic to the upstream node. This node also contains a bridge intralink on the second port (1-1-3-0) so unknown traffic is sent to the downstream to another network or subtended Ethernet device, even though address learning is not enabled.

Additional MALC nodes can be added to the daisy-chained linear topology by repeating this pattern of connections and bridging.

Note: The GigE card on the MALC should be configured with a card-line-type of ds1 for T1, e1 for E1, or t1cas for T1 channel bank support.

Figure 21 illustrates the GigE-2 card linear configuration using redundant cards.



Figure 21: GigE linear configuration with single card and bridging

Configuring GigE-2 card bridging1 On the node connected to the Ethernet or IP network

a Add a bridge interface to the first GigE-2 port (this is the port connected to the external network):

zSH> bridge add 1-1-2-0/ethernetcsmacd uplink

b Add a default bridge path over the first GigE-2 port:zSH> bridge-path add ethernet2/bridge global

All bridge traffic will be forwarded over this interface.

c Add an bridge intralink on the second GigE-2 port:zSH> bridge add 1-1-3-0/ethernetcsmacd intralink



This interface is the global intralink for the node.

d Add a downlink to the remote subscriber:zSH> bridge add 1-5-1-0/adsl vc 0/37 td 4000 downlink vlan 100

2 On the next node in the linear daisy-chain configuration:

PPPoA - PPPoE Conversion


a Add an uplink bridged interface:zSH> bridge add 1-1-2-0/ethernetcsmacd uplink

b Add a default bridge path that points to the Uplink node:zSH> bridge-path add ethernet2/bridge global

c Add an bridge intralink on the second GigE-2 port:zSH> bridge add 1-1-3-0/ethernetcsmacd intralink



This interface is the global intralink for the node.

d Add a downlink to the remote subscriber:zSH> bridge add 1-8-1-0/adsl vc 0/39 td 3000 downlink vlan 200

3 Continue this configuration for all the nodes in the daisy-chain connection.

PPPoA - PPPoE ConversionThe MALC supports PPPoA to PPPoE internetworking for connections to a Broadband Remote Access Server (BRAS) using a PPP tunnel. Upon detecting PPPoA traffic, the MALC initiates a PPPoE session with the Broadband Remote Access Server (BRAS). PPP traffic between the CPE and the BRAS is tunneled over this PPPoE session. The MALC autosenses the type of PPPoA encapsulation as either VCMUX or LLC.

An inactivity timeout occurs when a lack of activity is detected on the PPPoA connection for 30-80 seconds, while upstream PPPoE packets are received. When this occurs, the PPPoE session is terminated.



Figure 22: PPPoA to PPPoE Internetworking

Enabling PPPoA to PPPoE Internetworking1 Add a downlink bridge using the bridge configuration record with the

PPPoA parameter.

The bridge command supports enabling PPPoA internet working from the command line. This example adds interface 1-5-24-0/adsl with VLAN 500, and PPPoA to PPPoE internet working enabled.

zSH> bridge add 1-5-24-0/adsl vc 0/35 td 20000 downlink vlan 500 pppoa

This automatically updates the bridge-interface record

Note: The following message may appear if the CPE device is not properly configured for PPPoA connections. FEB 01 15:59:22: error : 1/1/9 : bridge: _afsmChkRcvEncaps(): l=1811: tNetTask: AFSM-6313: port 1-7-2-0-adsl-0-35 misconfigured for PPPoA

zSH> get bridge-interface-record 1-5-24-0-adsl-0-35/bridgePlease provide the following: [q]uit.vpi: ----------------------> {0}:vci: ----------------------> {35}:vlanId: -------------------> {500}:stripAndInsert: -----------> {true}:customARP: ----------------> {false}:filterBroadcast: ----------> {false}:learnIp: ------------------> {false}:learnUnicast: -------------> {false}:maxUnicast: ---------------> {5}:learnMulticast: -----------> {false}:forwardToUnicast: ---------> {false}:

Radius server

PC MALC BRAS

IP

PPPoA PPPoE

PPPoA - PPPoE Conversion


forwardToMulticast: -------> {false}:forwardToDefault: ---------> {true}:bridgeIfCustomDHCP: -------> {false}:bridgeIfConfigGroupIndex: -> {0}: vlanIdCOS: ----------------> {0}:outgoingCOSOption: --------> {disable}:outgoingCOSValue: ---------> {0}:s-tagTPID: ----------------> {0x8100}:s-tagId: ------------------> {0}:s-tagStripAndInsert: ------> {false}:s-tagOutgoingCOSOption: ---> {s-tagdisable}:s-tagIdCOS: ---------------> {0}:s-tagOutgoingCOSValue: ----> {0}:mcastControlList: ---------> {}:maxVideoStreams: ----------> {0}:isPPPoA: ------------------> {true}: (enables the PPPoA session)

2 Display the bridge data. PPPoA port states are INITIAL (INI), PENDING (PND), DOWN (DWN), READY (RDY), DISCRVY (DSC), and UP. The new states available for PPPoA internet working are:

– READY (RDY)

Waiting for PPPoA packet to initiate PPPoE discovery.

– DISCVRY (DSC)

PPPoE discovery initiated. Waiting for session ID to be obtained.

The A indicates that the port is a PPPoA port. When the PPPoA port status is UP, the BRAS MAC address and PPPoE session ID are also displayed.

zSH> bridge showVLAN Bridge State Table Data---------------------------------------------------------------------Tagged ethernet2/bridge UP S Global default [U: 3600 sec, M: 120 sec, I: 60 sec] 500 1-7-48-0-adsl-0-35/bridge UP A 00:19:aa:3b:83:24 51758 500 1-7-1-0-adsl-0-35/bridge PND 500 1-7-2-0-adsl-0-35/bridge RDY A 500 1-7-3-0-adsl-0-35/bridge UP A 00:19:aa:3b:83:24 51768 500 1-7-4-0-adsl-0-35/bridge UP A 00:19:aa:3b:83:24 51788 500 1-7-5-0-adsl-0-35/bridge UP A 00:19:aa:3b:83:24 51756 500 1-7-6-0-adsl-0-35/bridge UP A 00:19:aa:3b:83:24 51796 500 1-7-7-0-adsl-0-35/bridge UP A 00:19:aa:3b:83:24 51759 500 1-7-8-0-adsl-0-35/bridge UP A 00:19:aa:3b:83:24 51754 500 1-7-9-0-adsl-0-35/bridge UP A 00:19:aa:3b:83:24 51789 500 1-7-10-0-adsl-0-35/bridge UP A 00:19:aa:3b:83:24 51755 500 1-7-11-0-adsl-0-35/bridge UP A 00:19:aa:3b:83:24 51774

The bridgeshow ports command displays the following new fields:

– isPPPoA

Indicates if interface is PPPoA or not.



– aHdl

For PPPoA interfaces, displays the handle address to PPPoA. Otherwise, 0x0 is displayed.

– encapLLC

Shows ‘Yes’ if PPPoA encapsulation is LLC or ‘No’ for VCMU encapsulation.

zSH> bridgeshow portsisPPPoA Yes, aHdl 0x6e6ac90, encapLLC NoifIndex 6351externalVpi 0 - externalVci 35shelf 1 - slot 7 - port 40 - subport 0isUp Up - ifUnit 0 - ifType 159 - lineRRReg Line UpportGroupIndex 0 - index 45 - *pBridgeCookie 0x31E64D4flags 5 Attached ValidAAL5notReady 0, xmitError 0 - xmitOK 0pktRcvd 1 localPktRcvd 0 mcastPktRcvd 0 bcastPktRcvd 0ucastPktSent 0 mcastPktSent 0 bcastPktSent 0pppoeTransitAddFail 0macLen 6 - macAddr[6] 00.01.47.b1.19.a0drvName[8] bridgeaal5Data vpi 0 vci 273 aal5Port 0 extVpi 0 - extVci 0 netSvcType 2453 - encapType 1 - port 40 - pcr 0 txTraffDescrIndex 0 - ifType 0 - endPtLineStatus 1 drvHandle 0x6ada2c0, cmd 3, appHandle: 0x4055f68bindSet 1 - ifaceSet 1 - xlateSet 1bridgeRec vpi 0 - vci 35 - vlan/SlanId 500/0 - stripAndInsert Yes customARP No - filterBroadcast No learnIp No learnUnicast No maxUnicast 5 learnMcast No forwardToUnicast No forwardToMcast No forwardToDefault Yes vlanIdCOS 0 outgoingCOSOption disable outgoingCOSValue 0isTkDrv Yes - ifIndexToBindTo 33pDevice[256] - unit 0 - physIfType 125 - seqNumber 0x000000000s_vlanInfoSent T, s/vlanIdSent 0/0, outCosValue 0x0circuitId = 172.24.94.224:1-7-40-0-adsl-0-35IGMP: initInjectCnt 3, lastInitQueryTick 0, lastQueryTick 0 lastIgmpJoinTick 0, lastIgmpLeaveTick 0

PPPoE Intermediate AgentThe MALC supports inserting port information into PPPoE packets that transit a MALC bridge interface. When the MALC receives a PPPoE Active Discovery Initiation (PADI) packet or a PPPoE Active Discovery Request (PADR) packet, the MALC can be configured to insert a customized string along with default port/slot identification into the vendor-specific portion of the PPPoE packet. The customized identification string can be 0 to 48 characters. The inserted information is TR-101 compliant and formatted as:

<customstring> eth slot/port[[:stagID]:vlan-tag]

PPPoE Intermediate Agent


The slot/port values identify the ingress slot/port on the MALC where the packet was received. If the packet is tagged with a VLAN tag, the VLAN tag is also added to the packet on ingress. If the packet is tagged with a SLAN tag, the SLAN tag is also added to the packet on ingress.

• Untagged packet no customized string from slot 5 port 2: eth 5/2

• VLAN 500 tagged packet no customized string from slot 5 port 2: eth 5/2 :500

• VLAN 500 tagged, SLAN 4 tagged packet no customized string from slot 5 port 2: eth 5/2 :4 :500

• VLAN 500 tagged, SLAN 4 tagged packet with customized string of “172.42.10.5” from slot 5 port 2: 172.42.10.4 eth 5/2 :4 :500

Note: For configurations with bridge intralinks or subtended MALC/Raptor devices, ensure that the PPPoE intermediate agent feature is enabled on only the subtended devices.

Configuring bridge configuration recordsThe MALC supports bridge configuration groups and records so an open-ended number of filter settings can be configured for a bridge interface. The same filter settings can also be easily applied to multiple bridge interfaces.

Bridge configuration records for the intermediate agent options are assigned to bridge configuration groups on downlink bridge interfaces. Each bridge configuration record contains settings for type and value. The bridgeConfigType parameter specifies the bridgeinsertpppoevendortag option to enable the intermediate agent feature. The bridgeConfigValue parameter specifies the 0 to 48 character customized string to insert into PADI and PADR packets.

Create bridge configuration records using the bridge-config-record profile. Specify group/instance index numbers to assign group and instance identification.

1 Configure a new bridge-config-record for group1/instance1 and specifies the option to insert a PPPoE vendor tag with a customized prefix of ‘Malc123’.

zSH> new bridge-config-record 1/1Please provide the following: [q]uit.bridgeConfigType: --> {bridgeinsertoption82}: bridgeinsertpppoevendortagbridgeConfigValue: -> {}: Malc123....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.



2 Use the config parameter of the bridge add command to create a bridge with the assigned bridge-config-record of group 1 instance 1.

zSH>bridge add 1-4-1-0/adsl vc 0/35 td 1 config 1/1

Displaying port informationThe bridgeshow ports command displays a new field for pppoeTransitAddFail to help track the data insertion failures.

To display port data, use the bridgeshow ports command.

zSH>bridgeshow portsisPPPoA Yes, aHdl 0x6e6ac90, encapLLC NoifIndex 6351externalVpi 0 - externalVci 35shelf 1 - slot 7 - port 40 - subport 0isUp Up - ifUnit 0 - ifType 159 - lineRRReg Line UpportGroupIndex 0 - index 45 - *pBridgeCookie 0x31E64D4flags 5 Attached ValidAAL5notReady 0, xmitError 0 - xmitOK 0pktRcvd 1 localPktRcvd 0 mcastPktRcvd 0 bcastPktRcvd 0ucastPktSent 0 mcastPktSent 0 bcastPktSent 0pppoeTransitAddFail 0macLen 6 - macAddr[6] 00.01.47.b1.19.a0drvName[8] bridgeaal5Data vpi 0 vci 273 aal5Port 0 extVpi 0 - extVci 0 netSvcType 2453 - encapType 1 - port 40 - pcr 0 txTraffDescrIndex 0 - ifType 0 - endPtLineStatus 1 drvHandle 0x6ada2c0, cmd 3, appHandle: 0x4055f68bindSet 1 - ifaceSet 1 - xlateSet 1bridgeRec vpi 0 - vci 35 - vlan/SlanId 500/0 - stripAndInsert Yes customARP No - filterBroadcast No learnIp No learnUnicast No maxUnicast 5 learnMcast No forwardToUnicast No forwardToMcast No forwardToDefault Yes vlanIdCOS 0 outgoingCOSOption disable outgoingCOSValue 0isTkDrv Yes - ifIndexToBindTo 33pDevice[256] - unit 0 - physIfType 125 - seqNumber 0x000000000s_vlanInfoSent T, s/vlanIdSent 0/0, outCosValue 0x0circuitId = 172.24.94.224:1-7-40-0-adsl-0-35IGMP: initInjectCnt 3, lastInitQueryTick 0, lastQueryTick 0 lastIgmpJoinTick 0, lastIgmpLeaveTick 0

Advanced bridging configurationsThe default settings for bridge interfaces are created based on the usage of the downlink and uplink parameters of the bridge add command. It is recommended not to change the default settings unless advanced bridge configuration is required. Examples of advanced bridge configurations include:

• Packet-rule records (Option 82, Forbid OUI, DHCP relay, PPPoE vendor tag) on page 143

Advanced bridging configurations


• Tagged bridge—VLANs on page 145

• Broadcast suppression on page 146

• Bridge with DHCP relay on page 147


Packet-rule records (Option 82, Forbid OUI, DHCP relay, PPPoE vendor tag)

The MALC now supports packet-rule records so an open-ended number of filter settings can be configured for a bridge interface. The same filter settings can also be easily applied to multiple bridge interfaces.

Packet-rule-records are typically assigned to bridge configuration groups on downlink bridge interfaces. Each bridge configuration record contains settings for type and value. The packetRuleValue parameter specifies the variety of filter to be applied to the interface.

• bridgeinsertoption82:

packetRuleValue contains an identification text used with Insert option 82 to identify the DHCP host. When this option is specified, option82 information is displayed in standard text format.

• bridgeddhcprelay

packetRuleValue contains the DHCP subnet group ID. If only the DHCP relay option is used, option82 information is displayed in hex format as slot port shelf vlan.

• bridgeinsertpppoevendortag

packetRuleValue contains optional identification string that is converted to TR101 compliant data.

• bridgeforbidoui

packetRuleValue contains a 3-byte hexadecimal vendor code used with the Forbid OUI to forbid access on the interface.

zSH> show packet-rule-recordpacketRuleType:---> bridgeinsertoption82 bridgedhcprelay bridgeinsertpppoevendortag bridgeforbidoui packetRuleValue:--> {260}packetRuleValue2:-> {260}packetRuleValue3:-> {260}packetRuleValue4:-> {260}packetRuleValue5:-> {260}

The bridge-interface-record profile contains new fields to support the packet-rule-record.



zSH> show bridge-interface-recordbridgeIfIngressPacketRuleGroupIndex:-> {0 - 2147483647}bridgeIfEgressPacketRuleGroupIndex:--> {0 - 2147483647}

Note: Bridge configuration record settings supersede the global filter settings set using the bridge-path add filter command.

Configuring packet rule recordsCreate bridge configuration records using the packet-rule-record profile. Specify group/instance index numbers to assign group and instance identification.

Configure a new packet-rule-record for group1/instance2 and specify the desired type and value settings:

zSH> new packet-rule-record 1/2Please provide the following: [q]uit.packetRuleType:---> {}:bridgeforbidoui packetRuleValue:--> {}:00:02:02....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Configuring bridge interface recordConfigure the bridge-interface-record to assign all instances of a given bridge configuration group to a specified interface. Bridge configuration groups are assigned to the interface records by setting the bridgeIfConfigGroupIndex parameter.

To configure a bridge configuration group:

zSH> update bridge-interface-record 1-3-1-0-adsl-0-35/bridgePlease provide the following: [q]uit.vpi: ----------------------> {0}:vci: ----------------------> {39}:vlanId: -------------------> {46}:stripAndInsert: -----------> {true}:customARP: ----------------> {false}:filterBroadcast: ----------> {false}:learnIp: ------------------> {true}:learnUnicast: -------------> {true}:maxUnicast: ---------------> {5}:learnMulticast: -----------> {true}:forwardToUnicast: ---------> {false}:forwardToMulticast: -------> {false}:forwardToDefault: ---------> {true}:bridgeIfCustomDHCP: -------> {false}:bridgeIfConfigGroupIndex: -> {0}: 1....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.



Enabling option 82 using bridge-path commandThe option82 option is available in the bridge-path command to enable the insertion of the option 82 information into the global DHCP offer requests.

To enable option 82 information:

1 Add two bridges, one connecting the remote host, the other connecting to a remote bridge. For example:

zSH> bridge add 1-4-1-0/shdsl vc 0/35 td 1 remote devicezSH> bridge add 1-1-1-0/ethernetcsmacd uplink

2 View the bridges:

zSH> bridge showVLAN Bridge State Table Data----------------------------------------------------------------- 0 1-4-1-0-shdsl-0-35/bridge UP S Global default [3600 sec] 0 1-1-1-0-ethernetcsmacd/bridge UP

3 Then, create the bridge path with option82 specified:

zSH> bridge-path add 1-4-1-0-shdsl-0-35/bridge option82

4 View the bridge path:

zSH> bridge-path showVLAN Bridge Address-----------------------------------------------------------------Global 1-1-1-0-ethernetcsmacd/bridge Default

Tagged bridge—VLANs

In most configurations, VLAN IDs should be stripped for traffic destined to downlink interfaces and inserted for traffic destined for upstream interfaces. Downlink interfaces typically do not need to know the VLAN ID since they are on a single Ethernet. You can, however, specify that a downlink interface be tagged, or an uplink interface be untagged. You might want to do this if you are subtending MALC devices and aggregating Ethernet traffic.

Configuring stripAndInsertConfigure the bridge-interface-record to change the stripping and insert of VLAN tags for a specified interface.

To change the stripAndInsert option:

zSH> update bridge-interface-record 1-3-1-0-adsl-0-35/bridgePlease provide the following: [q]uit.vpi: ----------------------> {0}:vci: ----------------------> {39}:vlanId: -------------------> {46}:stripAndInsert: -----------> {true}: falsecustomARP: ----------------> {false}:



filterBroadcast: ----------> {false}:learnIp: ------------------> {true}:learnUnicast: -------------> {true}:maxUnicast: ---------------> {5}:learnMulticast: -----------> {true}:forwardToUnicast: ---------> {false}:forwardToMulticast: -------> {false}:forwardToDefault: ---------> {true}:bridgeIfCustomDHCP: -------> {false}:bridgeIfConfigGroupIndex: -> {0}: ....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Broadcast suppression

Broadcast suppression enables DHCP information to be relayed between DHCP client and host while broadcast filtering is enabled.

CustomDHCP settingThe customDHCP setting enables bridge interfaces to pass DHCP information independent of the filterBroadcast setting. Setting customDHCP to TRUE will cause that bridge interface to pass DHCP OFFER and ACK packets even though the filterBroadcast is set to TRUE.

To enable CustomDHCP:

For an existing bridge, update the bridge-interface-record.

zSH> update bridge-interface-record 1-3-1-0-adsl-0-35/bridgePlease provide the following: [q]uit.vpi: ----------------------> {0}:vci: ----------------------> {39}:vlanId: -------------------> {46}:stripAndInsert: -----------> {true}:customARP: ----------------> {false}:filterBroadcast: ----------> {false}:learnIp: ------------------> {true}:learnUnicast: -------------> {true}:maxUnicast: ---------------> {5}:learnMulticast: -----------> {true}:forwardToUnicast: ---------> {false}:forwardToMulticast: -------> {false}:forwardToDefault: ---------> {true}:bridgeIfCustomDHCP: -------> {false}: truebridgeIfConfigGroupIndex: -> {0}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.



Bridge with DHCP relay

The MALC enables bridges to be configured as DHCP relay agents. All DCHP messages on the bridge will have Option 82 information inserted and be passed up through an IP interface to a external DHCP server.

Figure 23 illustrates the traffic flow when the MALC is configured with a bridge to support DHCP relay.

Figure 23: Bridge supported DHCP relay

Configuring bridges to support DHCP relayThis procedure describes how to configure bridges on the MALC to support DHCP relay. This procedure assumes the following configuration has already been performed on the MALC.

• Downlink bridge to the host

• Uplink bridge to network

• IP interface on the MALC with a route available to the DHCP server

To configure bridge support for DHCP relay:

1 Create a bridge-config-record with the bridgeConfigType set to bridgedhcprelay. This setting causes DHCP relay traffic to be removed from the bridge, inserts Option 82 data, and forwards the DHCP relay traffic out the IP interface to the configured DHCP server. This example uses bridge configuration group 2.

zSH> new bridge-config-record 2/1 Please provide the following: [q]uit.

External DHCP Server

MALC downlink bridge HostMALC uplink bridge

DHCP unicast

MALC as DHCP relay agent



bridgeConfigType: --> {bridgeinsertoption82}bridgedhcprelaybridgeConfigValue: -> {1}............Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

2 Verify that the bridge-interface-record contains correct bridge IfConfigGroupIndex value. This value represents the bridge configuration group index specified for the bridge-config-record.

zSH> get bridge-interface-record 1-12-1-0-adsl-0-35/bridgevpi: ----------------------> {0}vci: ----------------------> {35}vlanId: -------------------> {0}stripAndInsert: -----------> {true}customARP: ----------------> {false}filterBroadcast: ----------> {false}learnIp: ------------------> {true}learnUnicast: -------------> {true}maxUnicast: ---------------> {5}learnMulticast: -----------> {true}forwardToUnicast: ---------> {false}forwardToMulticast: -------> {false}forwardToDefault: ---------> {true}bridgeIfCustomDHCP: -------> {false}bridgeIfConfigGroupIndex: -> {2} bridge-config-record 2/1, 2/2, etc.vlanIdCOS: ----------------> {0}outgoingCOSOption: --------> {disable}outgoingCOSValue: ---------> {0}s-tagTPID: ----------------> {0x8100}s-tagId: ------------------> {0}s-tagStripAndInsert: ------> {false}s-tagOutgoingCOSOption: ---> {s-tagdisable}s-tagIdCOS: ---------------> {0}s-tagOutgoingCOSValue: ----> {0}

Verify the dhcp-server-subnet with subnetgroup index matching thebridgeConfigValue is configured to forward DHCP requests to the desiredexternal DHCP server. In this example, the bridgeConfigValue of 1 in the bridge-config-record matches the subnetgroup value specified in the dhcp-server-subnet profile. These values tell the DHCP relay agent to send the DHCP packets to the specified DHCP external server at 172.16.88.73.

zSH> get dhcp-server-subnet 1network: ---------------> {10.11.1.0}netmask: ---------------> {255.255.255.0}domain: ----------------> {0}range1-start: ----------> {10.11.1.10}range1-end: ------------> {10.11.1.250}range2-start: ----------> {0.0.0.0}range2-end: ------------> {0.0.0.0}range3-start: ----------> {0.0.0.0}

Administrative commands


range3-end: ------------> {0.0.0.0}range4-start: ----------> {0.0.0.0}range4-end: ------------> {0.0.0.0}default-lease-time: ----> {-1}min-lease-time: --------> {-1}max-lease-time: --------> {-1}boot-server: -----------> {0.0.0.0}bootfile: --------------> {}default-router: --------> {10.11.1.1}primary-name-server: ---> {0.0.0.0}secondary-name-server: -> {0.0.0.0}domain-name: -----------> {}subnetgroup: -----------> {1} matches bridgeConfigValue of 1 in the bridge-config-recordstickyaddr: ------------> {enable}external-server: -------> {172.16.88.73}

Administrative commandsThe MALC provides the following administrative commands:

• bridge delete

• bridge show

• bridge showall

• bridge-path add

• bridge-path show

• bridge-path delete

• bridge stats

• bridge flush

Refer to the MALC CLI Reference Guide for a detailed explanation of the available bridge commands.

Bridge delete command

The bridge delete command deletes a specific bridge entry from the system.

Bridge show/showall commands

The bridge show and bridge showall commands display either a single bridge path entry or the entire bridge table.



Bridge stats

The bridge stats command displays and clear bridge interface statistics for all bridges, bridges associated with a specified VLAN ID, and a specified bridge interface.

zSH> bridge statsInterface Received Packets Transmitted PacketsName UCast MCast BCast UCast MCast Bcast Error1-16-8-0-shdsl-0-35-835 0 0 1 0 0 0 0 1-16-8-0-shdsl-0-35-635 0 0 0 0 0 0 0 1-16-24-0-shdsl-0-35-835 0 0 0 0 0 0 1

zSH> bridge stats vlan 835Interface Received Packets Transmitted PacketsName UCast MCast BCast UCast MCast Bcast Error1-16-8-0-shdsl-0-35-835 0 0 1 0 0 0 0 1-16-24-0-shdsl-0-35-835 0 0 0 0 0 0 1

COS in bridgesThe MALC supports setting COS values in Ethernet VLAN headers for bridged packets. This service enables you to assign a service level or class of service (COS) to an Ethernet VLAN interface that is transported across a uplink, intralink, or downlinked tagged bridge. The configured COS level specifies the packet priority and queueing methods used to transport the packet through the Ethernet network. The MALC sets and preserves the COS settings to ensure these settings are passed to other Ethernet devices in the network for QOS processing.

Bridge profile

The following parameters in the bridge interface record are used for Ethernet COS support.

COS in bridges


To display the bridge-record profile, enter the show bridge-interface-record command.

rpr-uplink-zSH> show bridge-interface-record vpi:----------------------> {0}vci:----------------------> {0}vlanId:-------------------> {0 - 2147483647}stripAndInsert:-----------> false true customARP:----------------> false true filterBroadcast:----------> false true learnIp:------------------> false true learnUnicast:-------------> false true maxUnicast:---------------> {0 - 2147483647}learnMulticast:-----------> false true forwardToUnicast:---------> false trueforwardToMulticast:-------> false true forwardToDefault:---------> false true bridgeIfCustomDHCP:-------> false true bridgeIfConfigGroupIndex:-> {0 - 2147483647}vlanIdCOS:----------------> {0 - 7}outgoingCOSOption:--------> disable all outgoingCOSValue:---------> {0 - 7}

Adding an interfaceThis example adds interface 1-1-1-0/adsl with a COS value of 7.

interface add 1-1-1-0/adsl other vlan 1 cos 7 23.23.23.23 255.255.255.0

This example adds interface 1-1-1-0/adsl with a COS value of 1 and specifies to add this value to all packets originating from this interface.


vlanIdCOS Specifies the value loaded into the COS field of the VLAN header when an untagged packet received on this interface is tagged (VLAN ID inserted) for bridging. Value range is 0 to 7. Default is 0.

outgoingCOSOption Specifies whether to insert the VLAN COS bits on packets bridged through this interface. Values: Disable Leave any existing COS values unchanged. This is the default value. All Replace the current COS values in all VLAN headers in tagged and untagged packets originating and transported through this device.

outgoingCOSValue For outgoing tagged packets, specifies the value used to overwrite any existing COS value in the VLAN header. Value range is 0 to 7. Default is 0.



interface add 1-1-1-0/adsl other vlan 1 cos 1 tosOrig 1 23.23.23.23 255.255.255.0

This example adds interface 1-1-1-0/adsl with a COS value of 5 and specifies to add the value to all outgoing packets on this interface.

interface add 1-1-1-0/adsl other tos all cos 5 23.23.23.23 255.255.255.0

This example adds interface 1-1-1-0/adsl and disables the TOS feature.

interface add 1-1-1-0/adsl other tosDisable 23.23.23.23 255.255.255.0

Adding a bridgeThis example adds interface 1-1-1-0/adsl with a vlanIDCOS value of 7. This value is inserted into the priority field of the VLAN header when an untagged packet received on this interface is tagged (VLAN ID inserted) for bridging.

bridge add 1-1-1-0/adsl downlink vlan 100 tagged COS 7

This example adds interface 1-1-1-0/adsl with a vlanIDCOS value of 7 and enables the overwriting of the VLAN ID in all outgoing packets with the value of 7.

bridge add 1-1-1-0/adsl downlink vlan 100 tagged COS 7 outCOS all 7

Video bridging

Video bridging on the MALC provides the ability to integrate video streams for multiple sources into one conduit. Video bridging enables video packets to be forwarded over a Layer 2 bridge from a host to a subscriber. As a result, the video travels from its source, or head-end device, and passes through the MALC in a passive manner with only one video stream across the backplane, reducing bandwidth required for video packets to traverse a MALC.

Video bridging requires you to configure both an uplink bridge and a downlink bridge. On the uplink bridge, the forwardToMulticast function is associated with a location that contains video content and allows the MALC to receive video groups from the network. An interface with this value set to true should only transmit multicast traffic for which a JOIN request has been received. Any bridge interface with the forwardToMulticast parameter set to false discards multicast IP traffic. By default, the forwardToMulticast parameter is set to true on uplink bridges.

On the downlink bridge, the learnMulticast function is associated with interfaces that have hosts connected to them and allows the MALC to send video groups from downlink interfaces to the network. By default, the learnMulticast parameter is set to true on downlink bridges.

Note that JOIN operations enter on a learnMulticast interface associated with a downlink bridge and pass through on a forwardToMulticast interface associated with an uplink bridge.

COS in bridges


The following table details various video bridge behaviors associated with different combinations of settings for the bridge parameters.

The following video bridge example creates a video bridge on a MALC-Uplink-2-GE uplink card using the first GigE interface as the uplink bridge. It also creates a bridge path on that interface. The downlink bridge uses ADSL interface in shelf 1, slot 3, port 1 and assigns VCI/VPI 0/37 with traffic descriptor 1 and VLAN 800 to the downlink interface.

For the uplink bridge:

zSH> bridge add 1-1-2-0/ethernetcsmacd uplink Adding bridge on 1-1-2-0/ethernetcsmacdCreated bridge-interface-record 1-1-2-0-ethernet2/bridge

For the uplink bridge path, add a bridge path and a multicast aging period and IGMP query interval.

zSH> bridge-path add ethernet2/bridge global mcastage 90 igmpqueryinterval 30

For the downlink bridge, add a downlink bridge and specify a maximum number of video streams and multicast control list. Members of the multicast control list must be defined to receive the video signal.

Table 6: learnMulticast-forwardToMulticast Combinations and Behavior

learnMulticast forwardToMulticast

Behavior

False False The interface discards all incoming multicast packets and does not forward any of the packets.

True False The interface forwards both default multicast signaling packets an control multicast packets.

True False The interface discards incoming multicast content groups and forwards requested content groups.

False True The interface forwards control packets received on this interface to all other interfaces that have the learnMulticast field set to true.

False True The interface forwards content groups only to interfaces that have sent JOIN messages for a group.

True True Treat the same as an interface with the learnMulticast field set to false and the forwardToMulticast field set to true.



zSH> bridge add 1-3-1-0/adsl vc 0/37 td 1 downlink vlan 800 video maxvideostreams 2 mcastctrl 1Adding bridge on 1-3-1-0/adslCreated bridge-interface-record 1-3-1-0-adsl-0-37

Verifying bridge settingsTo verify bridge settings, use the get bridge-interface-record command for each bridge. This command displays the bridge settings, including the learnMulticast and forwardToMulticast.

For the uplink bridge, note that the forwardToMulticast setting is true and the learnMulticast setting is false.

zSH> get bridge-interface-record ethernet2/bridgevpi: ----------------------> {0}vci: ----------------------> {0}vlanId: -------------------> {0}stripAndInsert: -----------> {false}customARP: ----------------> {true}filterBroadcast: ----------> {true}learnIp: ------------------> {false}learnUnicast: -------------> {false}maxUnicast: ---------------> {0}learnMulticast: -----------> {false}forwardToUnicast: ---------> {true}forwardToMulticast: -------> {true}forwardToDefault: ---------> {false}bridgeIfCustomDHCP: -------> {true}bridgeIfConfigGroupIndex: -> {0}vlanIdCOS: ----------------> {0}outgoingCOSOption: --------> {disable}outgoingCOSValue: ---------> {0}s-tagTPID: ----------------> {0x8100}s-tagId: ------------------> {0}s-tagStripAndInsert: ------> {false}s-tagOutgoingCOSOption: ---> {s-tagdisable}s-tagIdCOS: ---------------> {0}

s-tagOutgoingCOSValue: ----> {0}

For the downlink bridge, note that the forwardToMulticast setting is false and the learnMulticast setting is true.

zSH> get bridge-interface-record 1-3-1-0-adsl-0-37/bridgevpi: ----------------------> {0}vci: ----------------------> {37}vlanId: -------------------> {800}stripAndInsert: -----------> {true}customARP: ----------------> {false}filterBroadcast: ----------> {false}learnIp: ------------------> {true}learnUnicast: -------------> {true}maxUnicast: ---------------> {5}learnMulticast: -----------> {true}

COS in bridges


forwardToUnicast: ---------> {false}forwardToMulticast: -------> {false}forwardToDefault: ---------> {true}bridgeIfCustomDHCP: -------> {false}bridgeIfConfigGroupIndex: -> {0}vlanIdCOS: ----------------> {0}outgoingCOSOption: --------> {disable}outgoingCOSValue: ---------> {0}s-tagTPID: ----------------> {0x8100}s-tagId: ------------------> {0}s-tagStripAndInsert: ------> {false}s-tagIdCOS: ---------------> {0}s-tagOutgoingCOSValue: ----> {0}maxvideostreams: ----------> {0}mcasctrl: -----------------> {0}

In addition, you can run a bridge igmp command to determine whether IGMP is running on the system.

zSH> bridge igmpVlanID MAC Address MCAST IP Ifndx Host MAC Last Join---------------------------------------------------------------------------- 999 01:00:5e:02:7f:fe 224.2.127.254 921 00:02:02:0b:4a:a0 2 999 01:00:5e:02:7f:fe 224.2.127.254 922 00:02:02:0a:bb:6d 106 999 01:00:5e:02:7f:fe 224.2.127.254 923 00:02:02:0a:c0:b7 87 999 01:00:5e:02:7f:fe 224.2.127.254 924 00:02:02:0b:4e:c5 172 999 01:00:5e:02:7f:fe 224.2.127.254 925 00:02:02:0b:4c:7e 65 999 01:00:5e:02:7f:fe 224.2.127.254 926 00:02:02:0b:4f:08 46 999 01:00:5e:02:7f:fe 224.2.127.254 927 00:02:02:09:c1:7d 90 999 01:00:5e:02:7f:fe 224.2.127.254 928 00:02:02:0b:44:cd 71 999 01:00:5e:02:7f:fe 224.2.127.254 929 00:02:02:0b:4c:ca 61 999 01:00:5e:02:7f:fe 224.2.127.254 930 00:02:02:0b:47:bd 7 999 01:00:5e:02:7f:fe 224.2.127.254 931 00:02:02:0b:47:c7 177 999 01:00:5e:02:7f:fe 224.2.127.254 932 00:02:02:0b:4d:35 181 999 01:00:5e:02:7f:fe 224.2.127.254 933 00:02:02:0b:4d:5b 144 999 01:00:5e:02:7f:fe 224.2.127.254 934 00:02:02:0b:4a:a5 59 999 01:00:5e:02:7f:fe 224.2.127.254 935 00:02:02:0b:4c:9e 3 999 01:00:5e:02:7f:fe 224.2.127.254 936 00:02:02:09:c1:78 6 999 01:00:5e:02:7f:fe 224.2.127.254 937 00:02:02:0a:c0:ca 131


CONFIGURING ATM

This chapter explains how to configure ATM cross connects on the MALC. It includes the following sections:

• Configuration overview, page 157


• VPI/VCI ranges, page 158

• Configuring PCR and SCR values, page 160

• Creating traffic descriptors, page 163

• Creating VCLs and VPLs, page 166

• Creating cross connects, page 170

• Subtending, page 172

Tip: For information about configuring ATM management connections, see ATM management connection on page 24.

For important background information about ATM on the MALC, see MALC ATM Overview on page 369.

Configuration overviewThis section provides an overview of how to configure MALC ATM data connections references to where to find detailed information.

1. Modify the VPI/VCI ranges of the slot card, if necessary. See VPI/VCI ranges on page 158.

2. Modify the allowable PCR and SCR values, if necessary. See Configuring PCR and SCR values on page 160.

3. Create traffic descriptors. See Creating traffic descriptors on page 163.

4. Create VCLs or VPLs, as required.

– See Creating VCLs (VC switching) on page 168.

– See Creating VPLs (VP switching) on page 169

5. Create cross connects. See Creating cross connects on page 171.

Configuring ATM


OverviewFigure 24 shows an overview of ATM on the MALC.

Figure 24: ATM cell relay on the MALC

VPI/VCI rangesThe MALC supports configurable VPI/VCI ranges for all ATM-capable cards. VPI/VCI ranges are configured in atm-vpi records.

Note the following about VPI/VCIs ranges:

• After creating or modifying atm-vpi records, the card must be rebooted.

• A maximum of 256 VPIs can be created on a port.

• As atm-vpi records are created, the system allocates connections from the available pool of connections. Each VP-switched VP uses one connection and each VC-switched VP uses one connection per allowable VC.

Changing VPI/VCI ranges

Note that although you can create switched VCs without modifying the VPI/VCI ranges, if you create the first atm-vpi (to change the VPI/VCI ranges on a card or to create a VP switched connection), the system automatically creates an atm-vpi profile for each VPI used in existing cross connects.

IP

ATM

Layer 3

IP ATM VCL/VPL ATM CC ATM VCL/VPLLayer 2

IP DSL ATM UNILayer 1

SAR

ATM

ATM VCL/VPL

Local ExchangeSwitch

TDM

Voice Gateway

VPI/VCI ranges


The system determines how many VCIs are assigned to each VPI, then populates the zhoneAtmVpiMaxVci parameter in an atm-vpi record with the value (in the form 2n) closest to that number. For example, if the system has cross connects configured with the following VPI/VCI pairs:

After the atm-vpi records have been created, you can update them to change the default VCI values, if desired.


The following table summarizes the configuration tasks for changing the VPI/VCI ranges.

Changing VPI/VCI ranges1 Create an atm-vpi record for the VP:

– If the VP is going to be switched, leave zhoneAtmVpiMaxVci at 0.

– If the VC is going to be switched, change zhoneAtmVpiMaxVci to the number of VCs for that VP. Note that the value must be a power of 2 greater than 31. For example, 32, 64, 128, 256, 512, 1028, or 2048.

The following example creates VPI 10 on an OC3-c/STM1 card, with 1024 allowable VCs:

VPI/VCI atm-vpi profile created Comment

VPI 0 VCI 100VPI 0 VCI 101VPI 0 VCI 102

atm-vpi interface-name/atm/0zhoneAtmVpiMaxVci: ---> {128}

zhoneAtmVpiSwitched: -> {vc}

zhoneAtmVpiMaxVci = 128 because 128 is the smallest power of 2 that is greater than the highest VCI (102) created using that VPI.

VPI 1 VCI 1001VPI 1 VCI 1001VPI 1 VCI 1002VPI 1 VCI 1003VPI 1 VCI 1004

atm-vpi interface-name/atm/1zhoneAtmVpiMaxVci: ---> {1024}

zhoneAtmVpiSwitched: -> {vc}

zhoneAtmVpiMaxVci = 1024 because 1024 is the smallest power of 2 that is greater than the highest VCIs (1004) created using that VPI.

Task Command

Create an atm-vpi record. This specifies the maximum number of switched VCs on that connection (or 0 for VP switching) as well as whether the connection is VP or VC switched.

new atm-vpi index/atm/vpi

Up to 256 VPIs can be created on a port.

Update the atm-vpi records if you want to change the default atm-vpi records the system creates.

update atm-vpi index/atm/vpi

Reboot the card. slotreboot slot

Configuring ATM


zSH> new atm-vpi 1-1-1-0-sonet/atm/10 interface-index/atm/VPIPlease provide the following: [q]uit.zhoneAtmVpiMaxVci: ---> {0}: 1024zhoneAtmVpiSwitched: -> {vc}: zhoneAtmMaxVciPerVp: -> {0}:....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Note: For VP-switched connections, change the zhoneAtmVpiSwitched parameter to vp.

After the first atm-vpi record is saved, the system will automatically create atm-vpi records for all VPIs used in existing cross connects. If you need to modify the atm-vpi records the system has automatically created, update the records as in the following example:

zSH> update atm-vpi 1-1-2-0-sonet/atm/11 interface-index/atm/VPIPlease provide the following: [q]uit.zhoneAtmVpiMaxVci: ---> {1024}: 2048zhoneAtmVpiSwitched: -> {vc}: zhoneAtmMaxVciPerVp: -> {0}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

2 After the system has finished creating the atm-vpi records and you have finished updating them (if desired), reboot the slot card:zSH> slotreboot 1

Configuring PCR and SCR valuesThe atm-vcl-param profile defines the allowable values for the PCR and SCR for certain traffic types. The values in this profile are used as follows:

• The SCR for rt-VBR traffic descriptors must use one of the first 16 rates.

• The PCR for CBR traffic descriptors can use any of the 32 rates.

• For a UBR traffic descriptor, if usage-parameter-control in an ATM traffic descriptor is set to false, or if PCR is greater than modem trained rate, then the UBR traffic is shaped to one of the 32 rates. The shaper will pick a rate that is equal to or less than the modem trained rate. If there are multiple rates less than the modem trained rate, the one closest to the trained rate will be selected.

Configuring PCR and SCR values


Note: If your device is being managed by ZMS, changes to the atm-vcl-param profile should be made using ZMS. If you use the CLI to change the profile, perform a full config sync update after making the change.

Note the following about the values in this profile:

• Rates are in cells per second (CPS)

• Duplicate rates are not permitted

• Rates must be in ascending order within the first 16 rates and also within the second 16 rates.

To view the default values for the atm-vcl-param profile use the get command:

zSH> get atm-vcl-param 0vcl-rate-param1: -------> {38}vcl-rate-param2: -------> {76}vcl-rate-param3: -------> {151}vcl-rate-param4: -------> {189}vcl-rate-parma5: -------> {302}vcl-rate-param6: -------> {378}vcl-rate-param7: -------> {604}vcl-rate-param8: -------> {755}vcl-rate-param9: -------> {1208}vcl-rate-param10: ------> {1510}vcl-rate-param11: ------> {3661}vcl-rate-param12: ------> {4825}vcl-rate-param13: ------> {28302}vcl-rate-param14: ------> {37736}vcl-rate-param15: ------> {106133}vcl-rate-param16: ------> {365567}vcl-rate-grp2-param1: --> {2264}vcl-rate-grp2-param2: --> {3019}vcl-rate-grp2-param3: --> {4151}vcl-rate-grp2-param4: --> {7075}vcl-rate-grp2-param5: --> {9434}vcl-rate-grp2-param6: --> {11792}vcl-rate-grp2-param7: --> {14151}vcl-rate-grp2-param8: --> {16509}vcl-rate-grp2-param9: --> {18868}vcl-rate-grp2-param10: -> {23585}vcl-rate-grp2-param11: -> {33019}vcl-rate-grp2-param12: -> {56604}vcl-rate-grp2-param13: -> {75472}vcl-rate-grp2-param14: -> {150943}vcl-rate-grp2-param15: -> {226415}vcl-rate-grp2-param16: -> {301887}

Table 7 explains the atm-vcl-param default settings.

Configuring ATM


Changing the atm-vcl-param profile values

Caution: Changing the values in the atm-vcl-param profile requires a system reboot.

To update the atm-vcl-param profile with new values:

zSH> update atm-vcl-param 0Please provide the following: [q]uit.vcl-rate-param1: --> {38}:vcl-rate-param2: --> {76}:

Table 7: atm-vcl-param settings

Setting Application Cells per second

38 1 to 2 DS0s at 5:1 to 10:1 oversubscription

38 CPS


76 CPS


151 CPS

189 1 DS0no oversubscription

189 CPS


302 CPS


378 CPS


604 CPS


755 CPS


1208 CPS


1510 CPS

3661 Full T1 3661 CPS

4825 Full E1 4825 CPS

28302 8 T1s 28,303 CPS

37736 8 E1s 37,736 CPS

106133 DS3 106,133 CPS

365567 O-C3c/STM1 365,567 CPS

Creating traffic descriptors


vcl-rate-param3: --> {151}: 164vcl-rate-param4: --> {189}: 196vcl-rate-parma5: --> {302}:vcl-rate-param6: --> {378}:vcl-rate-param7: --> {604}:vcl-rate-param8: --> {755}:vcl-rate-param9: --> {1208}:vcl-rate-param10: -> {1510}:vcl-rate-param11: -> {3661}:vcl-rate-param12: -> {4825}:vcl-rate-param13: -> {28302}:vcl-rate-param14: -> {37736}:vcl-rate-param15: -> {106133}:vcl-rate-param16: -> {365567}:vcl-rate-grp2-param1: --> {2264}vcl-rate-grp2-param2: --> {3019}vcl-rate-grp2-param3: --> {4151}vcl-rate-grp2-param4: --> {7075}vcl-rate-grp2-param5: --> {9434}vcl-rate-grp2-param6: --> {11792}vcl-rate-grp2-param7: --> {14151}vcl-rate-grp2-param8: --> {16509}vcl-rate-grp2-param9: --> {18868}vcl-rate-grp2-param10: -> {23585}vcl-rate-grp2-param11: -> {33019}vcl-rate-grp2-param12: -> {56604}vcl-rate-grp2-param13: -> {75472}vcl-rate-grp2-param14: -> {150943}vcl-rate-grp2-param15: -> {226415}vcl-rate-grp2-param16: -> {301887}....................Save changes? [s]ave, [c]hange or [q]uit: sChanging atm-vcl-param 0 will result in a system reboot. Continue? [y]es or [n]o: y Atm configuration changed system is rebooting ...Record updated.

Creating traffic descriptorsWhen you create a traffic descriptor, specify an index which is used to associate a traffic descriptor with an ATM virtual channel links (VCLs) in an atm-vcl record.

Configuring ATM


The following parameters of the default atm-traf-descr profile should be modified to match your network:


td_type Traffic descriptor type. Values: atmNoClpNoScr(OID 1.3.6.1.2.1.37.1.1.2) No CLP and no sustained cell rate.atmClpTaggingNoScr (OID 1.3.6.1.2.1.37.1.1.4) CLP with tagging and no sustained cell rate. atmClpNoTaggingScr (OID 1.3.6.1.2.1.37.1.1.6) CLP with no tagging and sustained cell rate.atmClpTaggingScr (OID 1.3.6.1.2.1.37.1.1.7) CLP with tagging and sustained cell rate.atmClpTransparentNoScr(OID 1.3.6.1.2.1.37.1.1.9) CLP transparent with no sustained cell rate. atmClpTransparentScr(OID 1.3.6.1.2.1.37.1.1.10) CLP transparent with sustained cell rate. atmNoClpNoScrCdvt(OID 1.3.6.1.2.1.37.1.1.12) No CLP, no sustained cell rate, and cell delay variation tolerance.atmClpNoTaggingScrCdvt (OID 1.3.6.1.2.1.37.1.1.14) CLP with no tagging, sustained cell rate and cell delay variation tolerance.atmClpTaggingScrCdvt (OID 1.3.6.1.2.1.37.1.1.15) CLP with tagging, sustained cell rate, and cell delay variation tolerance.

td_param1 Peak Cell Rate (PCR), measured in cells per second. For CBR traffic, must match a value configured in the atm-vcl-param profile.

td_param2 Sustainable cell rate (SCR), measured in cells per second. For rt-VBR traffic, must match a value configured in the atm-vcl-param profile.PCR for atmClpTaggingNoScr traffic.CDVT for atmClpTransparentNoScr and atmNoClpNoScrCdvt traffic.

td_param3 Maximum burst size (MBS), measured in number of cells.

td_param4 Cell delay variation tolerance (CDVT), measured in 10ths of microseconds.

Creating traffic descriptors


Creating a traffic descriptor1 List the atm-traf-descr records to see what is currently configured on the

system:

zSH> list atm-traf-descr

cac-divider Enables oversubscription for an ATM VCL. During CAC calculations, the system divides the PCR (for CBR VCLs) or SCR (for nrt-VBR or rt-VBR VCLs) bandwidth by the value specified in the cac-divider. It then uses that value to determine if the VCL can be created. For example, to configure a 4:1 oversubscription, set cac-divider to 4.Default: 1

td_service_category The ATM service category.Values: cbr Constant bit rateubr - unspecified bit rate rtvbr - Real time variable bit ratenrtvbr Non-real time variable bit rateDefault: ubr

td_frame_discard Enables and disable early-packet-discard (EPD) and partial-packet-discard (PPD). This allows selective discarding of all cells in a frame if one cell is lost or discarded.Values: true Indicates that the network is requested to treat data for this connection, in the given direction, as frames (that is, AAL5 CPCS PDUs) rather than as individual cells. While the precise implementation is network-specific, this treatment may involve discarding entire frames during congestion, rather than a few cells from many frames. false This is the recommended setting for voice connections.Default: false

usage-parameter-control Enables or disables policing on the traffic descriptor. Note that this must be set to true if the ATM service category is CBR.Values: truefalseDefault: true


Configuring ATM


0 entries found.

2 Create a traffic descriptor by specifying a traffic descriptor type and the traffic parameters. For example:

zSH> new atm-traf-descr 100Please provide the following: [q]uit.td_type: ------------- {atmNoClpNoScr}: enter traffic descriptor td_param1: ----------- {0}: enter PCR td_param2: ----------- {0}: enter PCR (for CLP=0 traffic) or SCRtd_param3: ----------- {0}: enter MBS td_param4: ----------- {0}: enter CDVTtd_param5: ----------- {0}:cac-divider: -------------> {1} td_service_category: - {ubr}: rtvbr | nrtvbr | ubr | cbrtd_frame_discard: --------> {false}usage-parameter-control: -> {true}....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Note: Set the PCR to match the lowest speed in the cross connect.

Creating VCLs and VPLsVCLs are used for VC switching. VPLs are used for VP switching.

The following table describes the supported parameters in the atm-vcl profile:


vpi The VPI for this VCL. This must match the remote end of the connection.

vci The VCI for this VCL. This must match the remote end of the connection.

admin_status Administrative status of the link. Values: updownDefault: down

receive_traffic_descr_index The index of the atm-traf-descr profile used for this VCL.

transmit_traffic_descr_index The index of the atm-traf-descr profile used for this VCL.

Creating VCLs and VPLs


vcc_aal_type ATM adaption layer type. Values: aal5 for dataother For cell relay connections.aal2 for voiceDefault: aal5

vcc_aal5_encaps_type The type of data encapsulation used over the AAL5 Service Specific Convergence Sublayer (SSCS) layer. The definitions reference RFC 1483 Multiprotocol Encapsulation over ATM AAL5 and the ATM Forum LAN Emulation specification.Values: llcencapsulation Used for an LLC-encapsulated connection. other Used for a bridged connection.

fault-detection-type Used to determine faults on the VCL. Values: disabled Fault detection is disabled.oamF5Loopback On POTS-based AAL2 connections, the unit sends an OAM F5 loopback if the CAS does not refresh after 10 seconds. If there is no response to the F5 loopback, the VCL is blocked and a trap is generated.On ISDN-based AAL2 connections, there is no CAS refresh; the unit sends an F5 loopback every 5 seconds. If there is no response to the F5 loopback, the VCL is blocked and a trap is generated.F5 loopbacks on AAL5 connections are not supported.Default: disabled


Configuring ATM


The following table describes the supported parameters in the atm-vpl profile:

Creating VCLs (VC switching)Create two VCLs for each cross connection. Each atm-vcl record defines an endpoint for an ATM virtual cross connection (VCC).

Note: For a cell relay connection, set the vcl_aal_type to other, which treats the connection endpoints as cell relay. The MALC will not perform any segmentation or reassembly (SAR) on the data stream.

1 The following example creates a VCL for a subscriber-side ADSL interface in shelf 1, slot 12, port 1, with a VPI of 0 and a VCI of 35:

zSH> new atm-vcl 1-12-1-0-adsl/atm/0/35 Please provide the following: [q]uit.


atmVplAdminStatus Administrative status of the VPL.Values: updownDefault: down

atmVplReceiveTrafficDescrIndex Specifies the ATM traffic descriptor which applies to the receive direction of this VPL. Currently this value must be set equal to the value used for the atmVplTransmitTrafficDescrIndex.Values: The index value of an existing atm-traf-descr.

atmVplTransmitTrafficDescrIndex Specifies the ATM traffic descriptor which applies to the transmit direction of this VPL. Currently this value must be set equal to the value used for the atmVplReceiveTrafficDescrIndex. Values: The index value of an existing atm-traf-descr.

atmVplCastType Type of connection.Values: p2p Point-to-point.

atmVplConnKind The use of call control. Values: pvc



vpi: -----------------------------> {0}:vci: -----------------------------> {0}:35admin_status: --------------------> {up}:upreceive_traffic_descr_index: -----> {0}:100 transmit_traffic_descr_index: ----> {0}:100vcc_aal_type: --------------------> {aal5}:other vcc_aal5_cpcs_transmit_sdu_size: -> {9188}:vcc_aal5_cpcs_receive_sdu_size: --> {9188}:vcc_aal5_encaps_type: ------------> {llcencapsulation}:vcl_cast_type: -------------------> {p2p}:vcl_conn_kind: -------------------> {pvc}:fault-detection-type: ------------> {disabled} traffic-container-index: ---------> {0}: ....................Save changes? [s]ave, [c]hange or [q]uit: sRecord saved.

2 The following example creates a VCL for the Uplink card interface in shelf 1, slot 1, port 1, with a VPI of 0 and a VCI of 101:

zSH> new atm-vcl uplink1/atm/0/101Please provide the following: [q]uit.vpi: -----------------------------> {0}:vci: -----------------------------> {0}:101admin_status: --------------------> {down}:upreceive_traffic_descr_index: -----> {0}:100transmit_traffic_descr_index: ----> {0}:100vcc_aal_type: --------------------> {aal5}:othervcc_aal5_cpcs_transmit_sdu_size: -> {9188}:vcc_aal5_cpcs_receive_sdu_size: --> {9188}:vcc_aal5_encaps_type: ------------> {llcencapsulation}:vcl_cast_type: -------------------> {p2p}:vcl_conn_kind: -------------------> {pvc}:fault-detection-type: ------------> {disabled} traffic-container-index: ---------> {0}: ....................Save changes? [s]ave, [c]hange or [q]uit: sRecord saved.

Creating VPLs (VP switching)Before creating VPLs, verify that an atm-vpi record exists for the VP you want to switch. For details, see VPI/VCI ranges on page 158.

Create two VPLs for each cross connection. Each atm-vpl record defines an endpoint for an ATM virtual cross connection (VCC).

Note: For a cell relay connection, set the vcl_aal_type to other, which treats the connection endpoints as cell relay. The MALC will not perform any segmentation or reassembly (SAR) on the data stream.

Configuring ATM


1 Create a VPL for the other end of the cross connect (in this example, an ADSL port in slot 3, using VPI 2):

zSH> new atm-vpl 1-3-1-0-adsl/atm/2 interface-index/atm/VPIPlease provide the following: [q]uit.atmVplAdminStatus: ---------------> {down}: upatmVplReceiveTrafficDescrIndex: --> {0}: 1atmVplTransmitTrafficDescrIndex: -> {0}: 1atmVplCastType: ------------------> {p2p}: atmVplConnKind: ------------------> {pvc}: atmVplPonTrafficContainerIndex: --> {0}:.................... Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

2 Create a VPL for one end of the cross connect (in this example, an Uplink card using VPI 3)

zSH> new atm-vpl uplink1/atm/3 interface-index/atm/VPIPlease provide the following: [q]uit.atmVplAdminStatus: ---------------> {down}: upatmVplReceiveTrafficDescrIndex: --> {0}: 1atmVplTransmitTrafficDescrIndex: -> {0}: 1atmVplCastType: ------------------> {p2p}: atmVplConnKind: ------------------> {pvc}: atmVplPonTrafficContainerIndex: --> {0}:.................... Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

3 Next, create the cross connect.

Creating cross connects

To connect the two endpoints create a new atm-cc profile and specify an index value (The cc-index is any number you choose.) The atm-cc record uses the low-if-index and high-if-index values for VPI and VCI to bind VCC endpoints.

The following parameters of the default atm-cc profile should be modified to match your network:


cc-index A unique value to identify this cross connect.

low-if-index The index (in the form shelf-slot-port-subport-interface/atm or a user-defined string) of the ATM interface for this cross connect. The low-if-index is arbitrary, but by convention it indicates the ATM interface with a numerically lower ifIndex value than the other ATM interface identified in the same cross connect. The low-if-index and the high-if-index cannot be equal.



Creating cross connectsTo create a VC-switched crossconnect, use the crossconnect command. This command uses the following syntax:crossconnect add interface1/type1 [vc] vpi1/vci1 interface2/type2 [vc] vpi2/vci2 td_val | txtd txtd_value rxtd rxtd_val

The following example creates a VC switched cross connect between a DSL port and an OC-3c/STM1 port (the VCL were created above):

zSH> crossconnect add 1-3-1-0-adsl/atm vc 1/35 uplink2/atm vc 1/101 100

The following example creates a VP switched cross connect between a DSL port and the Uplink port:

zSH> new atm-cc 1Please provide the following: [q]uit.cc-index: ------> {0}: 1low-if-index: --> {0/0/0/0/0}: 1-3-1-0-adsl/atm low-vpi: -------> {0}: 2low-vci: -------> {0}: leave at 0 for VP switchinghigh-if-index: -> {0/0/0/0/0}: uplink2/atm high-vpi: ------> {0}: 3high-vci: ------> {0}: leave at 0 for VP switching

low-vpi The VPI value associated with the interface specified in the low-if-index.

low-vci The VCI value associated with the interface specified in the low-if-index. For VP switched connections, specify 0.

high-if-index The index (in the form shelf-slot-port-subport-interface/atm or a user-defined string) of the ATM interface for this cross connect. The high-if-index is arbitrary, but by convention it indicates the ATM interface with a numerically higher ifIndex value than the other ATM interface identified in the same cross connect.The low-if-index and the high-if-index cannot be equal.

high-vpi The VPI value associated with the interface specified in the high-if-index

high-vci The VCI value associated with the interface specified in the high-if-index. For VP switched connections, specify 0.

admin-status The desired administrative status of the cross connect.Values: updownDefault: down


Configuring ATM


admin-status: --> {down}: up....................Save new record? [s]ave, [c]hange or [q]uit: sRecord saved.

Note: A VCL or VPL can be used in only one cross connect.

Subtending

Subtending allows you aggregate traffic from multiple MALC devices to single MALC device’s ATM upstream interface.

In a typical subtended configuration, VPLs from downstream devices are VP-switched to an upstream ATM device over a high-speed interface such as OC-3c/STM1.

Figure 25: Example subtending configuration

Subtending exampleThis example creates a subtended configuration from two downstream MALC devices to a single MALC. The downstream devices are connected to MALC T1/E1 ports and the traffic is VP switched to the Uplink interface (and then to the upstream ATM network).

1 Create a traffic descriptors for the downstream and upstream interfaces:

Downstream: (this example uses a UBR connection with a PCR of 3661 CPS (T1 line speed)):

1 ATM

VPL 1-3-1-0-ds1/atm/1

VPL uplink1/atm/1

Device A

Device B

Device C

T1/E1 32 card

VPL 1-3-2-0-ds1/atm/2

VPL uplink1/atm/2



zSH> new atm-traf-descr 100Please provide the following: [q]uit.td_type: -----------------> {atmNoClpNoScr}:td_param1: ---------------> {0}: 3661td_param2: ---------------> {0}:td_param3: ---------------> {0}:td_param4: ---------------> {0}:td_param5: ---------------> {0}:cac-divider: -------------> {1}:td_service_category: -----> {ubr}:td_frame_discard: --------> {false}:usage-parameter-control: -> {true}: ....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Upstream: (this example uses a UBR connection with a PCR of 28,303 CPS (line speed of 8 T1s)):zSH> new atm-traf-descr 200Please provide the following: [q]uit.td_type: -----------------> {atmNoClpNoScr}:td_param1: ---------------> {0}: 28303td_param2: ---------------> {0}:td_param3: ---------------> {0}:td_param4: ---------------> {0}:td_param5: ---------------> {0}:cac-divider: -------------> {1}:td_service_category: -----> {ubr}:td_frame_discard: --------> {false}:usage-parameter-control: -> {true}: ....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

2 Create VPI profiles for each VPI you want to switch. These specify that the MALC should VPI switch all traffic using this VPI:

a For the Uplink interface:

zSH> new atm-vpi uplink1/atm/1 interface-index/atm/VPIPlease provide the following: [q]uit.zhoneAtmVpiMaxVci: ---> {0}: zhoneAtmVpiSwitched: -> {vc}: vp....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

zSH> new atm-vpi uplink1/atm/2 interface-index/atm/VPIPlease provide the following: [q]uit.zhoneAtmVpiMaxVci: ---> {0}: zhoneAtmVpiSwitched: -> {vc}: vp....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Configuring ATM


After the first atm-vpi record is saved, the system will automatically create atm-vpi records for all VPIs used in existing cross connects, if any.

b For the T1/E1 port connected to device A:

zSH> new atm-vpi 1-3-1-0-ds1/atm/1 interface-index/atm/VPIPlease provide the following: [q]uit.zhoneAtmVpiMaxVci: ---> {0}: zhoneAtmVpiSwitched: -> {vc}: vp....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

c For the T1/E1 port connected to device B:

zSH> new atm-vpi 1-3-2-0-ds1/atm/2 interface-index/atm/VPIPlease provide the following: [q]uit.zhoneAtmVpiMaxVci: ---> {0}: zhoneAtmVpiSwitched: -> {vc}: vp....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

d After the system has finished creating the atm-vpi records, reboot the card:

Note: Rebooting the active Uplink card causes the system to reboot (for a non-redundant system), or switchover to the standby Uplink card (for a redundant system).

Uplink card:zSH> slotreboot 1

T1/E1 32 card:zSH> slotreboot 3

e If your system is redundant, configure a VPI profile on the second Uplink card.

3 Create VPLs to each downstream MALC:

Device A:zSH> new atm-vpl 1-3-1-0-ds1/atm/1 interface-index/atm/VPIPlease provide the following: [q]uit.atmVplAdminStatus: ---------------> {down}: upatmVplReceiveTrafficDescrIndex: --> {0}: 100atmVplTransmitTrafficDescrIndex: -> {0}: 100atmVplCastType: ------------------> {p2p}: atmVplConnKind: ------------------> {pvc}: atmVplPonTrafficContainerIndex:--> {0} ....................



Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Device B:zSH> new atm-vpl 1-3-2-0-ds1/atm/2 interface-index/atm/VPIPlease provide the following: [q]uit.atmVplAdminStatus: ---------------> {down}: upatmVplReceiveTrafficDescrIndex: --> {0}: 100atmVplTransmitTrafficDescrIndex: -> {0}: 100atmVplCastType: ------------------> {p2p}: atmVplConnKind: ------------------> {pvc}: atmVplPonTrafficContainerIndex:--> {0} .................... Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

4 Create the VPLs for device C’s Uplink interface:

For VPI 1 (device A):zSH> new atm-vpl uplink1/atm/1 interface-index/atm/VPIPlease provide the following: [q]uit.atmVplAdminStatus: ---------------> {down}: upatmVplReceiveTrafficDescrIndex: --> {0}: 200atmVplTransmitTrafficDescrIndex: -> {0}: 200atmVplCastType: ------------------> {p2p}: atmVplConnKind: ------------------> {pvc}: atmVplPonTrafficContainerIndex:--> {0}: .................... Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

For VPI 2 (device B):zSH> new atm-vpl uplink1/atm/2 interface-index/atm/VPIPlease provide the following: [q]uit.atmVplAdminStatus: ---------------> {down}: upatmVplReceiveTrafficDescrIndex: --> {0}: 200atmVplTransmitTrafficDescrIndex: -> {0}: 200atmVplCastType: ------------------> {p2p}: atmVplConnKind: ------------------> {pvc}: atmVplPonTrafficContainerIndex:--> {0}: .................... Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

5 Create cross connects between the two downstream interfaces and the Uplink interface:

From Device A to the Uplink VPL:zSH> new atm-cc 1Please provide the following: [q]uit.cc-index: ------> {0}: 1low-if-index: --> {0/0/0/0/0}: atm-vcl 1-3-1-0/atm

Configuring ATM


low-vpi: -------> {0}: 1low-vci: -------> {0}: leave at 0 for VP switchinghigh-if-index: -> {0/0/0/0/0}: uplink1/atm high-vpi: ------> {0}: 1high-vci: ------> {0}: leave at 0 for VP switchingadmin-status: --> {down}: up....................Save new record? [s]ave, [c]hange or [q]uit: sRecord saved.

From Device B to the Uplink VPL:zSH> new atm-cc 2Please provide the following: [q]uit.cc-index: ------> {0}: 2low-if-index: --> {0/0/0/0/0}: atm-vcl 1-3-2-0/atmlow-vpi: -------> {0}: 2low-vci: -------> {0}: leave at 0 for VP switchinghigh-if-index: -> {0/0/0/0/0}: uplink1/atm high-vpi: ------> {0}: 2high-vci: ------> {0}: leave at 0 for VP switchingadmin-status: --> {down}: up....................Save new record? [s]ave, [c]hange or [q]uit: sRecord saved.


CONFIGURING GR-303 OR V5.2 INTERFACE GROUPS

This section explains how to configure GR-303 and V5.2 interface groups on the MALC and how to configure system settings for voice. It includes the following information:

• Configuring a GR-303 interface, page 177

• Modifying a GR-303 interface group, page 182

• Configuring a V5.2 interface, page 183

• Modifying the v52-interface-group profile, page 194

After configuring the GR-303 or V5.2 interface, proceed to adding subscribers, as explained in Configuring the Voice Gateway on page 269 or Configuring Voice on page 197.

Note: The TDM/ATM Uplink card or the Voice Gateway card is required for GR-303 and V5.2 support on the MALC.

Note: This chapter assumes you have configured the TDM/ATM Uplink and the Voice Gateway card as explained in the MALC Hardware Installation Guide.

The TDM/ATM Uplink card has 16 T1/E1 ports. The first eight ports are ATM T1/E1 ports; the second eight are TDM T1/E1 ports.

Configuring a GR-303 interface The following steps are necessary to configure GR-303 interface groups on the MALC. Each step is explained in more detail in the sections that follow:

1. Update the system profile to specify the country the unit is operating in and to enable voice bandwidth check. See Updating system settings on page 198.

2. Find the line group identifier of the communication path (the DS1 interface on the TDM/ATM Uplink card).

3. Create the GR-303 Interface Group (IG). See Creating a GR-303 interface group on page 179.

Configuring GR-303 or V5.2 Interface Groups


4. Activate the GR-303 IG.

The following table summarizes the configuration tasks for creating a GR-303 interface.

Note: The sapi-1-n-200 and sapi-1-max-outstanding-frames parameters automatically take the same values as the sapi-0-n-200 and sapi-0-max-outstanding-frames parameters.

The gr303-interface-group profile supports the following parameters.

Configuration Task Profile

Creating a GR-303 interface group on page 179. new gr303-interface-group GR303Index

Use the same GR303Index for the gr303-interface-group and the CRVs in the gr303-ig-crv profile.

Modifying a GR-303 interface group on page 182 update gr303-interface-group GR303Index

Displaying GR303 interface group status on page 183

voice status ig gr303 groupname

Parameter Description and options

name-id A name assigned by the installer. It must be unique to the system. This value is a string. This is a required field.

switch-type The name of the switch supplying the GR-303 circuits. This is a required field.Values: lucent5EssnortelDms100

adminStatus The administrative status of the IG. This must be set to inservice for the IG to function.Values: inserviceoutofservice

working-mode Indicates whether the selected switch can configure the RDT using common management information service (CMIS) over the Embedded Operations Channel (EOC) channel. Values: active the selected switch can configure the RDT for Call Reference Values (CRVs) over the EOC channel. Normally used for 5ESS switches. passive CRVs can only be configured locally. Normally used for DMS switch.

CrtlChannel: The IG control channel array.

Configuring a GR-303 interface


Creating a GR-303 interface groupTo create a GR-303 interface group:

1 List the ds1-profiles

zSH> list ds1-profileif-translate 1-1-9-0/ds1if-translate 1-1-10-0/ds1if-translate 1-1-11-0/ds1if-translate 1-1-12-0/ds1if-translate 1-1-13-0/ds1if-translate 1-1-14-0/ds1if-translate 1-1-15-0/ds1if-translate 1-1-16-0/ds1...

ds1LM:array[1..28]: The array for T1/DS1 circuits. The maximum number of DS1 trunks allowed per IG is 28. This array includes the dsn-lg-id, channel-number, and role parameters.

dsn-lg-id The DS1 line group ID number. This must match the line group ID of the physical interface on which you are provisioning GR-303 IGs.

channel-number Identifies the DS1 for the channelized DS3.Values: 1 to 28

role The role this channel plays in the array. Must be set to primary for the first DS1. One other DS1 must have the role parameter set to secondary. All other DS1s have their role set to payload.Values: payloadsecondaryprimaryDefault: payload

logical-id Identifies each physical DS1 within an Interface Group between RDT and IDT. The value 1 is reserved for the primary DS1 and cannot be used by any other DS1s. This field is mandatory.Values: 1 to 28

ds1-valid-flag Whether this DS1 is valid or invalid. Must be set to valid to enable calls over provisioned DS1s.Values: validinvalid

Parameter Description and options



Then enter the lineGroup command to find the line group identifiers for the TDM T1/E1 ports. Make a note of the lineGroupIds of the TDM T1/E1 ports; they will be used later.

zSH> linegroup 1-1-9-0/ds1lineGroupId: 13








2 Create a new GR-303 interface group. For example:

zSH> new gr303-interface-group 1 1 is a user-defined Index for this IGPlease provide the following: [q]uit.name-id: -----------------------> {}: zhoneswitch-type: -------------------> {lucent5ess}: lucent5ess | norteldms100adminStatus: -------------------> {outofservice}: inserviceworking-mode: ------------------> {passive}: active | passivectrlChannel: control-channel-t303: ----------> {700}: control-channel-t396: ----------> {14700}: sapi-0-max-outstanding-frames: -> {7}: sapi-0-n-200: ------------------> {3}: sapi-0-t-200: ------------------> {150}: sapi-0-t-203: ------------------> {30}: sapi-0-pps-mode: ---------------> {notinhibited}: sapi-1-max-outstanding-frames: -> {7}: sapi-1-n-200: ------------------> {3}: sapi-1-t-200: ------------------> {150}: sapi-1-t-203: ------------------> {30}: sapi-1-pps-mode: ---------------> {notinhibited}:ds1LM has 28 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? sEnter the array element to start: 1ds1LM[1]: dsn-lg-id: ---------------------> {1}: 13 linegroup ID of the first port on the TDM/ATM Uplink channel-number: ----------------> {1}:

Configuring a GR-303 interface


role: --------------------------> {payload}: primary logical-id: --------------------> {28}: 1 1 is reserved for primary channels. Use numbers 2

to 28 for other types of channels. ds1-valid-flag: ----------------> {invalid}: validds1LM[3]: dsn-lg-id: ---------------------> {1}: 15 linegroup ID of the second port on the TDM/ATM Uplink channel-number: ----------------> {1}: role: --------------------------> {payload}: secondary logical-id: --------------------> {28}: 2 ds1-valid-flag: ----------------> {invalid}: validds1LM[4]: dsn-lg-id: ---------------------> {1}: 17 linegroup ID of the third port on the TDM/ATM Uplink channel-number: ----------------> {1}: role: --------------------------> {payload}: logical-id: --------------------> {28}: 3 ds1-valid-flag: ----------------> {invalid}: validds1LM[5]: dsn-lg-id: ---------------------> {1}: q ....................Save record? [s]ave, [c]hange or [q]uit: sNew record saved.

3 Activate the GR-303 interface group (IG):

zSH> update gr303-interface-group 1Please provide the following: [q]uit.name-id: -----------------------> {zhone}: switch-type: -------------------> {lucent5ess}: adminStatus: -------------------> {outofservce}: inserviceworking-mode: ------------------> {passive}: ctrlChannel: control-channel-t303: ----------> {700}: control-channel-t396: ----------> {14700}: sapi-0-max-outstanding-frames: -> {7}: sapi-0-n-200: ------------------> {3}: sapi-0-t-200: ------------------> {150}: sapi-0-t-203: ------------------> {30}: sapi-0-pps-mode: ---------------> {notinhibited}: sapi-1-max-outstanding-frames: -> {7}: sapi-1-n-200: ------------------> {3}: sapi-1-t-200: ------------------> {150}: sapi-1-t-203: ------------------> {30}: sapi-1-pps-mode: ---------------> {notinhibited}:ds1LM has 28 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? nUsing default values for elements 1-28....................Save record? [s]ave, [c]hange or [q]uit: sRecord updated.

After the GR-303 IG is activated, proceed to configuring GR-303 subscribers. For information, see Configuring Voice on page 197.



Modifying a GR-303 interface group

Caution: Removing an IG from service will cause all active calls to be dropped.

To remove service from the IG:

zSH> update gr303-interface-group 1Please provide the following: [q]uit.name-id: -----------------------> {zhone}: switch-type: -------------------> {lucent5ess}: adminStatus: -------------------> {inservice}: outofserviceworking-mode: ------------------> {passive}: ctrlChannel: control-channel-t303: ----------> {700}: control-channel-t396: ----------> {14700}: sapi-0-max-outstanding-frames: -> {7}: sapi-0-n-200: ------------------> {3}: sapi-0-t-200: ------------------> {150}: sapi-0-t-203: ------------------> {30}: sapi-0-pps-mode: ---------------> {notinhibited}: sapi-1-max-outstanding-frames: -> {7}: sapi-1-n-200: ------------------> {3}: sapi-1-t-200: ------------------> {150}: sapi-1-t-203: ------------------> {30}: sapi-1-pps-mode: ---------------> {notinhibited}:ds1LM has 28 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? nUsing default values for elements 1-28....................Save record? [s]ave, [c]hange or [q]uit: sRecord updated.

To restore service to the IG:

zSH> update gr303-interface-group 1Please provide the following: [q]uit.name-id: -----------------------> {zhone}: switch-type: -------------------> {lucent5ess}: adminStatus: -------------------> {outofservce}: inserviceworking-mode: ------------------> {passive}: ctrlChannel: control-channel-t303: ----------> {700}: control-channel-t396: ----------> {14700}: sapi-0-max-outstanding-frames: -> {7}: sapi-0-n-200: ------------------> {3}: sapi-0-t-200: ------------------> {150}: sapi-0-t-203: ------------------> {30}: sapi-0-pps-mode: ---------------> {notinhibited}: sapi-1-max-outstanding-frames: -> {7}: sapi-1-n-200: ------------------> {3}: sapi-1-t-200: ------------------> {150}: sapi-1-t-203: ------------------> {30}: sapi-1-pps-mode: ---------------> {notinhibited}:

Configuring a V5.2 interface


ds1LM has 28 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? nUsing default values for elements 1-28....................Save record? [s]ave, [c]hange or [q]uit: sRecord updated.

Displaying GR303 interface group status

The voice status command can be used to display GR303 IG status.

zSH> voice status ig gr303 test Status for gr303 interface group test:Admin status = in serviceOper status = inoperableActive calls = 0Switch type = norteldms100TMC primary state = out of serviceTMC secondary state = out of serviceEOC primary state = out of serviceEOC secondary state = out of service

Configuring a V5.2 interfaceThe following steps are necessary to configure V5.2 interface groups on the MALC. Each step is explained in more detail in the sections that follow:

1. Update the system profile to specify the country the unit is operating in and to enable voice bandwidth check. See Updating system settings on page 198.

2. Find the line group identifier of the communication path (the E1 interface on the TDM/ATM Uplink card).

3. Create the V5.2 IG. See Creating a V5.2 interface group on page 187.

4. Provision the V5.2 links. See Provisioning V5.2 links on page 189.

5. Add C-channels within links. See Adding C-channels within links on page 190.

6. Provision C-paths. See Provisioning C-paths on page 192.

7. Activate the V5.2 IG. See Activating the V5.2 IG on page 194.

The following table summarizes the tasks for configuring the V5.2 interface.

Configuration task Commands

Creating a V5.2 interface group on page 187 new v52-interface-group v52IgIndex



The following sections describe in further detail each step necessary in the configuration process.

Note: Although the v52-link, v52-c-channel and v52-c-path arrays can be provisioned at the same time the v52-interface-group is created, the steps are separated for clarity.

The following table describes the supported V5.2 parameters in the v52-interface-group. The V5.2 interface group (IG) is configured using one profile.

Finding the line group identifiers of the physical connection on page 188

update v52-interface-group v52IgIndex

Provisioning V5.2 links on page 189

Adding C-channels within links on page 190

Provisioning C-paths on page 192

Activating the V5.2 IG on page 194

Displaying V5.2 interface group status on page 195

voice status ig v52 groupname

Configuration task Commands

Parameter Options

name-id The name of the IG. Must be unique in the system. Use the same name for the voice-v52-interface-name parameter in the subscriber-voice-v52 profile. This value is a string.

local-interface-id The interface ID of the IG. Must be unique across the system. This value must match the value on the switch.Values: 0 to 16777215

local-prov-variant The prov(isioning) variant describes a type of provisioning. This value must match the value on the switch.Values: 0 to 127

admin-status The administrative status of the profile. Values: inserviceoutofservicedeferredoutofservicerestart



pstn-layer-3-start-address The start address for PSTN users. When PSTN users are added, they must have an address greater or equal to this one. This value must match the value on the switch.Values: 0 to 65535

isdn-env-func-start-address The start address for ISDN users. When ISDN users are added, they must have an address greater or equal to this one. This value must match the value on the switch.Values: 0 to 8175

national-pstn-region Country setting. Sets up PSTN values for the specific country.

switch-vendor The switch vendor for the IG. Values: lucent, nortel, alcatel, ericsson, nokia, siemens, samsung.

protocol-spec Specifies which variation of the V5.2 protocol is to be used by this interface group. This value must match the value on the switch.Values: edition1edition2

v52-ig-lapv An array of V5.2 Lapv timer parameters. These configure retries and other functions over the management links. This value must match the value on the switch.

v52-link[1..16] This array is used to provision the E1circuits between the LE and the MALC unit. There can be up to sixteen links. Each E1 link has 32 channels.

dsn-lg-id Describes the line group ID associated with the E1 link. Use the lineGroup command to find the line group ID.Values: 1 to 16

id The V5.2 link identifier.Assigned by the Local Exchange (LE).

v52-c-channel: array [1..3] This array describes up to three control channels per link (E1). There can be up to 3 of them on each of the16 links for a maximum of 48. C-channels are used to pass management information between then LE and the MALC system.

time-slot-index The channel that the C-channel is running over. This value must match the value on the switch.Values: 151631

Parameter Options



logical-channel-id C-channels carry a group of one or more C-paths, excluding the C-paths used for the protection protocol. A V5.2 interface may contain up to 44 logical C-channels. Each logical C-channel on an interface is uniquely identified with a 16 bit logical C-channel identifier. This value must match the value on the switch.Values: 0 to 65535

protection-group The protection protocol ensures that other protocols can continue to operate in case of equipment failure. This value must match the value on the switch.Values: nonegroup1onetoonegroup2mtongroup2

role The C-channel role. This value must match the value on the switch.Values: activestandbyswitchtostandbyDefault: active

link-valid-flag Activates the E1 circuit.Values: validinvalid

v52-c-path: array [1..48] This array describes communications paths. C-paths are used to specify the type of information running between the MALC system and the LE. C-paths run inside C-channels. There can be up to 48 C-paths inside each C-channel.Values: Use the logical-channel-id numbers created for the C-channels.

id The ID number of the communications path. Values: 0 to 255

type The type of communications path. This tells the system how the management information is communicated.Values: unknownpstn POTSctrl control protocolbcc bearer channel connectionlctl link control protocolisdnds BRI voice data

Parameter Options



Creating a V5.2 interface group

Note: While provisioning is being performed on the V5.2 interface, the IG should be kept out of service.

The following example shows how to create a V5.2 IG named zhone.

zSH> new v52-interface-group 1Please provide the following: [q]uit.name-id: ---------------------> {}: zhonelocal-interface-id: ----------> {0}: 1local-prov-variant: ----------> {0}: 1prov-variant-request: --------> {norequest}:admin-status: ----------------> {outofservice}:pstn-layer-3-start-address: --> {0}: 1isdn-env-func-start-address: -> {0}: 1port-alignment-request: ------> {norequest}:national-pstn-region: --------> {etsi}: germany match the country in the system profileswitch-vendor: ---------------> {ericsson}: siemens match switchprotocol-spec: ---------------> {edition2}:startup-check-link-id: -------> {false}:startup-unblock-user-ports: --> {false}:link-oos-timer: --------------> {2500}:link-is-timer: ---------------> {200}:v52-ig-lapv: max-outstanding-frames: ------> {7}: ** read-only ** n200: ------------------------> {3}: ** read-only ** n201: ------------------------> {260}: ** read-only ** t200: ------------------------> {1000}: ** read-only ** t203: ------------------------> {10}: ** read-only **v52-link has 16 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? nUsing default values for elements 1-16v52-c-path has 48 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? nUsing default values for elements 1-48....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

logical-channel-id The logical C-channel ID that the C-path is using. This number must match the logical-channel-id value of the C-channel that the C-path is running over.Values: 0 to 65535

c-path-valid-flag When this parameter is set to valid, the C-path is active.Values: validinvalid

Parameter Options



Note: After creating the IG, certain parameters in the v52-interface-group can only be modified with the v52config command. For details, see Modifying the v52-interface-group profile on page 194.

Finding the line group identifiers of the physical connection

List the ds1-profiles:

zSH> list ds1-profileif-translate 1-1-9-0/ds1if-translate 1-1-10-0/ds1if-translate 1-1-11-0/ds1if-translate 1-1-12-0/ds1if-translate 1-1-13-0/ds1if-translate 1-1-14-0/ds1if-translate 1-1-15-0/ds1if-translate 1-1-16-0/ds1...

Then enter the lineGroup command to find the line group identifiers for the TDM T1/E1 ports. Make a note of the lineGroupIds of the TDM T1/E1 ports; they will be used later.









Make a note of the lineGroupIds of the TDM T1/E1 ports; they will be used later.



Provisioning V5.2 links

This section explains how to provision individual E1 circuits or V5.2 links.

• To create V5.2 links, enter s for subset at the v52-link has 16 elements Modify [a]ll, [n]one, a [s]ubset, or [q]uit? prompt

• For each E1 circuit, enter a unique dsn-lg-id number. Refer to Finding the line group identifiers of the physical connection on page 188.

• Enter a link id number.

• Enter valid at the link-valid-flag prompt to turn the link up.

This example configures three links:

zSH> update v52-interface-group 1 the IG created earlierPlease provide the following: [q]uit.name-id: ---------------------> {zhone}: ** read-only **local-interface-id: ----------> {1}:local-prov-variant: ----------> {1}:prov-variant-request: --------> {norequest}:admin-status: ----------------> {outofservice}:pstn-layer-3-start-address: --> {1}:isdn-env-func-start-address: -> {1}:port-alignment-request: ------> {norequest}:national-pstn-region: --------> {germany}:switch-vendor: ---------------> {siemens}:protocol-spec: ---------------> {edition2}:startup-check-link-id: -------> {false}:startup-unblock-user-ports: --> {false}:link-oos-timer: --------------> {2500}:link-is-timer: ---------------> {200}:v52-ig-lapv: max-outstanding-frames: ------> {7}: ** read-only ** n200: ------------------------> {3}: ** read-only ** n201: ------------------------> {260}: ** read-only ** t200: ------------------------> {1000}: ** read-only ** t203: ------------------------> {10}: ** read-only **v52-link has 16 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit?Modify [a]ll, [n]one, a [s]ubset, or [q]uit? s to modfy the V5.2 linksEnter the array element to start: 1v52-link[1]: dsn-lg-id: -------------------> {1}: 13 linegroup ID of the first port on the TDM/ATM Uplink ds1-channel-number: ----------> {1}: id: --------------------------> {0}: 1 identifier for first link, must match switch check-id: --------------------> {notactivated}: block: -----------------------> {unblocked}:v52-c-channel has 3 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? nUsing current values for elements 1-3 link-valid-flag: -------------> {invalid}: validv52-link[2]: dsn-lg-id: -------------------> {1}: 15 linegroup ID of the second port on the TDM/ATM Uplink



ds1-channel-number: ----------> {1}: id: --------------------------> {0}: 2 identifier for second link, must match switch check-id: --------------------> {notactivated}: block: -----------------------> {unblocked}:v52-c-channel has 3 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? nUsing current values for elements 1-3 link-valid-flag: -------------> {invalid}: validv52-link[3]: dsn-lg-id: -------------------> {1}: 17 linegroup ID of the third port on the TDM/ATM Uplink ds1-channel-number: ----------> {1}: id: --------------------------> {0}: 3 identifier for third link, must match switch check-id: --------------------> {notactivated}: block: -----------------------> {unblocked}:v52-c-channel has 3 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? nUsing current values for elements 1-3 link-valid-flag: -------------> {invalid}: validv52-link[4]: dsn-lg-id: -------------------> {1}: qUsing current values for elements 4-16v52-c-path has 48 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? nUsing current values for elements 1-48....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Adding C-channels within links

This example shows how to configure control channels for links you created in Provisioning V5.2 links on page 189. Control channels (C-channels) to pass management information between the switch and the MALC. There can be up to three C-channels per E1 link, on channel numbers 15, 16 and 31.

• Enter 15, 16 or 31 for the time-slot-index option.

• Enter the logical-channel-id. Each C-channel must have a unique numerical identifier.

• Enter a protection-group name (optional).

• Specify the role.

• Set the c-channel-valid-flag to valid.

The following example shows one C-channel provisioned in v52-link number one, one in link number two, and two C-channels provisioned in link number three.

zSH> update v52-interface-group 1 Please provide the following: [q]uit.name-id: ---------------------> {zhone}: ** read-only **local-interface-id: ----------> {1}:local-prov-variant: ----------> {1}:prov-variant-request: --------> {norequest}:admin-status: ----------------> {outofservice}:



pstn-layer-3-start-address: --> {1}:isdn-env-func-start-address: -> {1}:port-alignment-request: ------> {norequest}:national-pstn-region: --------> {germany}:switch-vendor: ---------------> {siemens}:protocol-spec: ---------------> {edition2}:startup-check-link-id: -------> {false}:startup-unblock-user-ports: --> {false}:link-oos-timer: --------------> {2500}:link-is-timer: ---------------> {200}:v52-ig-lapv: max-outstanding-frames: ------> {7}: ** read-only ** n200: ------------------------> {3}: ** read-only ** n201: ------------------------> {260}: ** read-only ** t200: ------------------------> {1000}: ** read-only ** t203: ------------------------> {10}: ** read-only **v52-link has 16 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? sEnter the array element to start: 1v52-link[1]: dsn-lg-id: -------------------> {2}: ds1-channel-number: ----------> {1}: id: --------------------------> {1}: check-id: --------------------> {notactivated}: block: -----------------------> {unblocked}:v52-c-channel has 3 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? sEnter the array element to start: 1v52-c-channel[1]: time-slot-index: -------------> {16}: logical-channel-id: ----------> {0}: 1 protection-group: ------------> {none}: group1 role: ------------------------> {active}: c-channel-valid-flag: --------> {invalid}: validv52-c-channel[2]: time-slot-index: -------------> {16}: qUsing current values for elements 2-3 link-valid-flag: -------------> {valid}:v52-link[2]: dsn-lg-id: -------------------> {4}: ds1-channel-number: ----------> {1}: id: --------------------------> {2}: check-id: --------------------> {notactivated}: block: -----------------------> {unblocked}:v52-c-channel has 3 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? sEnter the array element to start: 1v52-c-channel[1]: time-slot-index: -------------> {16}: logical-channel-id: ----------> {0}: 2 protection-group: ------------> {none}: group1 role: ------------------------> {active}: standby c-channel-valid-flag: --------> {invalid}: validv52-c-channel[2]: time-slot-index: -------------> {16}: qUsing current values for elements 2-3 link-valid-flag: -------------> {valid}:



v52-link[3]: dsn-lg-id: -------------------> {6}: ds1-channel-number: ----------> {1}: id: --------------------------> {3}: check-id: --------------------> {notactivated}: block: -----------------------> {unblocked}:v52-c-channel has 3 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? sEnter the array element to start: 1v52-c-channel[1]: time-slot-index: -------------> {16}: logical-channel-id: ----------> {0}: 3 protection-group: ------------> {none}: role: ------------------------> {active}: c-channel-valid-flag: --------> {invalid}: validv52-c-channel[2]: time-slot-index: -------------> {16}: qUsing current values for elements 2-3 link-valid-flag: -------------> {valid}: qUsing current values for elements 4-16v52-c-path has 48 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? nUsing current values for elements 1-48....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Provisioning C-paths

You can set how the management information in the C-channel is communicated by provisioning the communication path (C-path). The C-path array is provisioned within the C-channel array. The C-path logical-channel-id number must match the logical-channel-id value you assigned for the C-channel in the Adding C-channels within links on page 190. For each C-path, follow these steps:

• Assign a unique id number for each C-path.

• Enter a type value. To communicate ISDN BRI management data for voice calls, use the isdnds option.

• Assign the logical-channel-id number for the C-channel that the C-path is running over.

• Each c-path-valid-flag must be set to valid to activate the C-path.

This example shows how to configure seven communications paths. The first four are in C-channel number one, the fifth and sixth are created in channel three, and the seventh is created in channel four.

zSH> update v52-interface-group 1 Please provide the following: [q]uit.name-id: ---------------------> {zhone}: ** read-only **local-interface-id: ----------> {1}:local-prov-variant: ----------> {1}:prov-variant-request: --------> {norequest}:



admin-status: ----------------> {outofservice}:pstn-layer-3-start-address: --> {1}:isdn-env-func-start-address: -> {1}:port-alignment-request: ------> {norequest}:national-pstn-region: --------> {germany}:switch-vendor: ---------------> {siemens}:protocol-spec: ---------------> {edition2}:startup-check-link-id: -------> {false}:startup-unblock-user-ports: --> {false}:link-oos-timer: --------------> {2500}:link-is-timer: ---------------> {200}:v52-ig-lapv: max-outstanding-frames: ------> {7}: ** read-only ** n200: ------------------------> {3}: ** read-only ** n201: ------------------------> {260}: ** read-only ** t200: ------------------------> {1000}: ** read-only ** t203: ------------------------> {10}: ** read-only **v52-link has 16 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? nUsing current values for elements 1-16v52-c-path has 48 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? sEnter the array element to start: 1v52-c-path[1]: id: --------------------------> {1}: type: ------------------------> {unknown}: bcc bear channel connection logical-channel-id: ----------> {0}: 1 c-path-valid-flag: -----------> {invalid}: validv52-c-path[2]: id: --------------------------> {1}: 2 type: ------------------------> {unknown}: ctrl control protocol logical-channel-id: ----------> {0}: 1 c-path-valid-flag: -----------> {invalid}: validv52-c-path[3]: id: --------------------------> {1}: 3 type: ------------------------> {unknown}: lctl link control protocol logical-channel-id: ----------> {0}: 1 c-path-valid-flag: -----------> {invalid}: validv52-c-path[4]: id: --------------------------> {1}: 4 type: ------------------------> {unknown}: pstn POTS signalling logical-channel-id: ----------> {0}: 1 c-path-valid-flag: -----------> {invalid}: validv52-c-path[5]: id: --------------------------> {1}: 5 type: ------------------------> {unknown}: isdnds ISDN data signaling logical-channel-id: ----------> {0}: 1 c-path-valid-flag: -----------> {invalid}: validv52-c-path[6]: id: --------------------------> {1}: qUsing current values for elements 6-48....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated



Activating the V5.2 IG

Activate the interface after provisioning is finished.

The example activates an IG number 1:

zSH> update v52-interface-group 1 V5.2 interface group numberPlease provide the following: [q]uit.name-id: ---------------------> {zhone}: ** read-only **local-interface-id: ----------> {1}:local-prov-variant: ----------> {1}:prov-variant-request: --------> {norequest}:admin-status: ----------------> {outofservice}: inservicepstn-layer-3-start-address: --> {1}:isdn-env-func-start-address: -> {1}:port-alignment-request: ------> {norequest}:national-pstn-region: --------> {germany}:switch-vendor: ---------------> {siemens}:protocol-spec: ---------------> {edition2}:startup-check-link-id: -------> {false}:startup-unblock-user-ports: --> {false}:link-oos-timer: --------------> {2500}:link-is-timer: ---------------> {200}:v52-ig-lapv: max-outstanding-frames: ------> {7}: ** read-only ** n200: ------------------------> {3}: ** read-only ** n201: ------------------------> {260}: ** read-only ** t200: ------------------------> {1000}: ** read-only ** t203: ------------------------> {10}: ** read-only **v52-link has 16 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? nUsing current values for elements 1-16v52-c-path has 48 elements. Modify [a]ll, [n]one, a [s]ubset, or [q]uit? nUsing current values for elements 1-48....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

After the V5.2 IG is activated, proceed to configuring V5.2 subscribers. For information, see Configuring Voice on page 197.

Modifying the v52-interface-group profile

If you need to modify the following parameters in the v52-interface-group profile, it can only be done using the v52config command:

• prov-variant-request

• admin-status (to set to restart only)

• port-alignment-request

• cchannelrole (to set to switchtostandby only)

The syntax of the command is as follows



v52config checklinkid/switchchan/restart/variant/block/unblock INTERFACE_ID linkid/cchan/aligntype

The following table describes the arguments for the v52config command:

For example, to restart the interface (local-interface-id) named 100:zSH> v52config restart 100

To run a check link id on the interface named 100, with a linkid of 4:zSH> v52config checklinkid 100 4

Displaying V5.2 interface group status

The voice status command can be used to display V5.2 IG status.

zSH> voice status ig v52 oneStatus for v52 interface group one:Admin status = in serviceOper status = inoperableOper status cause = local disableActive calls = 0Switch vendor = ericsson LinkId 0 TS 15 Channel status failed LinkId 0 TS 16 Channel status failed LinkId 1 TS 15 Channel status failed LinkId 1 TS 16 Channel status failed CPath 1 Oper status down CPath 2 Oper status down CPath 3 Oper status down CPath 4 Oper status down CPath 5 Oper status downzSH>

Argument Description

INTERFACE_ID The local interface ID number. This is the value of the name-id parameter in the v52-interface-group profile.

linkid Used with the checklinkid argument.

cchan Used with the switchchan argument.

aligntype Used with the block and unblock arguments. Can be isdn, pstn or all.


CONFIGURING VOICE

This chapter explains how to configure voice connections between subscriber endpoints and remote gateways and how to customize the voice parameters when required. It includes the following sections:


• Updating system settings, page 198

• Creating voice connections, page 200

• Additional VoIP features, page 215

• Configuring CES connections, page 233

• Additional voice features, page 249

• Emergency StandAlone (ESA) SIP and TDM support, page 256

• Configuring T.38 fax service, page 263

OverviewThe following types of voice connections between subscriber and remote endpoints are supported:

Note: The voice gateway card requires MALC software version 1.11.1 or higher on the Uplink cards.

Subscriber endpoints

Gateway endpoints

MALC Uplinks

POTS AAL2 All

DS1 TDM, Gigabit Ethernet

GR303 TDM, Gigabit Ethernet

VoIP All

V5.2 TDM, Gigabit Ethernet

ISDN AAL2 All

V5.2 TDM, Gigabit Ethernet

Configuring Voice


Note: This chapter assumes you have configured the required TDM/ATM Uplink, POTS, and ISDN physical interfaces as explained in the MALC Hardware Installation Guide.

Updating system settingsPrior to configuring a voice connection, ensure the system settings are configured to support desired type of voice connection.

The system profile contains settings that configure country-specific settings for voice calls and determines whether the system will reject incoming calls if there isn’t enough bandwidth available.

Setting a-law or mu-law and DSP settings

Note: The MALC supports A-Law or Mu-Law encoding, but they cannot both be used simultaneously in a single chassis.

Modifying the countryregion parameter of the system profile ensures that the ring frequency and voice encoding (A-law/Mu-law) are correctly set.

The A-law and Mu-law settings can also be set using the optional alaw and mulaw parameters in the voice add command. See Creating voice connections on page 200.

The show system command displays the available system profile settings.

The voice add command does not allow the alaw/mulaw argument with POTS voice connections. If it is entered for a POTS voice connection, it is ignored. However, the alaw/mulaw argument can be used for the AAL2 remote end of a voice connection.

For VoIP calls, if codec argument is not specified, the country code settings determines the default preferred-codec as g711mu or g711a.

VoIP GR303 All TDM IP (voice gateway card required)

V5.2 All TDM IP (voice gateway card required)

AAL2 GR303 All TDM ATM (voice gateway card required)

V5.2 All TDM ATM (voice gateway card required)

AAL2 ELCP

V5.2 All TDM ATM (voice gateway card required)

Subscriber endpoints

Gateway endpoints

MALC Uplinks

Updating system settings


Checking bandwidth before accepting a voice call (AAL2)

In voice over ATM (VoATM) networks, the MALC is capable of oversubscribing on AAL2 connections. If voice bandwidth checking is enabled, the system will reject a call if there is not enough bandwidth. If a call is rejected, the MALC sends a fast busy to the caller over the POTS line. Bandwidth checking is recommended for voice connections.

Note: Bandwidth calculations are enabled or disabled for the entire system.

The bandwidth check is based on the configuration of the transmit and receive ATM traffic descriptors for the ATM VC used by the call. The system uses the following parameters to calculate the required bandwidth:

• rt-VBR traffic: SCR

• CBR traffic: PCR

• All other traffic types: calls are always accepted, there are no voice-quality guarantees.

The system will reject calls if:

[Receive or transmit cell rate - (180*number of active calls on the VC)] < 180

(The bandwidth calculations assume that approximately 180 AAL2 cells per second are used for each voice call.)

Updating the system profileTo update the system profile:

zSH> update system 0Please provide the following: [q]uit.syscontact: ----------> {Zhone Global Services and Support 7001 Oakport Road Oakland Ca. (877) Zhone20 (946-6320) Fax (510)777-7113 [email protected]}:sysname: -------------> {Zhone Malc}:syslocation: ---------> {Oakland}:enableauthtraps: -----> {disabled}:setserialno: ---------> {0}:zmsexists: -----------> {false}:zmsconnectionstatus: -> {inactive}:zmsipaddress: --------> {0.0.0.0}:configsyncexists: ----> {false}:configsyncoverflow: --> {false}:configsyncpriority: --> {high}:configsyncaction: ----> {noaction}:configsyncfilename: --> {}:configsyncstatus: ----> {syncinitializing}:configsyncuser: ------> {}:configsyncpasswd: ----> {}:numshelves: ----------> {1}:shelvesarray: --------> {}:

Configuring Voice


numcards: ------------> {3}:ipaddress: -----------> {0.0.0.0}:alternateipaddress: --> {0.0.0.0}:countryregion: -------> {us}: enter the country, if different from the defaultprimaryclocksource: --> {0/0/0/0/0}:ringsource: ----------> {internalringsourcelabel}: revertiveclocksource: -> {true}voicebandwidthcheck: --> {false} true if bandwidth checking is desired....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Creating voice connectionsVoice connections provide voice signaling connections between subscriber endpoints and voice gateway endpoints.

The voice command can be used to add, delete, and show voice connection settings. When a voice connection is added or deleted, the voice command creates or deletes the related profiles for both the subscriber and remote endpoints. Refer to the CLI Reference Guide for a complete description of the command options and syntax.

The voice command uses the following syntaxvoice add subscriber-info remote-info [sub descr] [enable]

This command automatically creates all the subscriber and ATM profiles required by the voice connection. For POTS and AAL2 voice connections, this command also optionally sets the PCM-encoding parameter to the specified encoding method and enables the voice connection.

Note that in some cases the profiles with voice configuration parameters may have to be updated to customize the voice configuration.

The voice show command can be used to display voice connection status for all calls or only voice connection data for a specific endpoint.

This section describes the procedures for configuring the following types of gateway voice connections:

• DS1 voice gateway connections on page 200

• Voice over IP (VoIP) connections on page 203

• AAL2 connections on page 228

• DS1 to POTS connections on page 230

DS1 voice gateway connections

DS1 voice connections use a direct channel map between the subscriber signals and the voice uplink.

Creating voice connections


Note: DS1 voice connections are only supported with line type D4.

This section explains how to configure the following types of connections:

• Configuring POTS to GR303 connections on page 202

• ISDN to V5.2 connections on page 201

• Configuring POTS to V.52 connections on page 203

ISDN to V5.2 connectionsFor ISDN-to-V5.2 configurations, the MALC interconnects ISDN terminal equipment directly to V.52 switches. The V5.2 IG must already exist before the voice connection can be configured.

The elcp-trap parameter is available in the aal2-vcl profile. This parameter allows operators to turn ELCP traps on/off for particular AAL2 VCLs. All users on the provisioned AAL2 VCL will have their ELCP trap alerts turned either on or off.

1 Use the voice command to add the ISDN to V5.2 connection. This example uses the 1-3-1-0/isdnu physical interface and sets the required fields in the atm-vcl, aal2-vcl-profile, and the aal2-cid-profile.

zSH> voice add isdn 1-3-1-0/isdnu v52 1/1 cpath 5 enableCreated subscriber-voice 1/13/25Created subscriber-voice-isdn 49Created v52-user-port 1/1/3Created subscriber-voice-v52 50Created subscriber-voice 1/13/26Created subscriber-voice-isdn 51Created subscriber-voice-v52 52Created subscriber-voice 1/13/27Created subscriber-voice-isdn 53Created subscriber-voice-v52 54

2 View the voice connection.

zSH> voice show 1-3-1-0/isdnuSubscriber end-point Remote end-point Voice Prof Id STA--------------------------- --------------------------- -------------- ---1-3-1-0/isdnu V52 1/1 3/32/13011 ENA1-3-1-0/isdnu V52 1/1 3/32/13012 ENA1-3-1-0/isdnu V52 1/1 3/32/13013 ENA

Configuring POTS to DS1 connections POTS to DS1 voice connections.

1 Use the voice command to add the POTS to DS1 connection.

Configuring Voice


The voice ring command can be used to verify a POTS voice connection without placing a call. The voice status command can be used to display runtime voice port status and to verify the phone’s ring status if the ringing cannot be heard.

zSH> voice add pots 1-5-24-0/voicefxs ds1 1-1-9-0/ds1 ds0 24Created subscriber-voice 1/21/25Created subscriber-voice-pots 83Created subscriber-voice-ds1 84

2 View the voice connections:

zSH> voice showSubscriber end-point Remote end-point Voice Prof Id STA------------------------------ ------------------------------ -------------- ---1-5-24-0/voicefxs 1-1-9-0/ds1 DS0 24 1/21/25 ENA

Configuring POTS to GR303 connections For GR303 voice connections, the GR303 interface with IG must already exist. For POTS-to-GR303 configurations, the MALC interconnects POTS equipment directly to GR-303 switches.

This example creates a POTS to GR303 subscriber profile with IG 1 and CRV 2. It also sets the administrative status interface to up.

The voice ring command can be used to verify a POTS voice connection without placing a call. The voice status command can be used to display runtime voice port status, verify the phone’s ring status if the ringing cannot be heard, and display interface group status.

The voice add command supports an gnd option for POTS endpoints to set the groundstart option for voice connections using the POTS ULCS card with pots subtype. If the farend of the voice connection is GR303, this option also sets the groundstart setting in the gr303-ig-crv profile. If the farend of the voice connection is AAL2, this option also sets the groundstart setting in the aal2-vcl profile.

When the gnd option is not used for the Global POTS or ULCS cards with pots subtype, the groundstart setting in the analog-fxs-cfg-profile is used. The default is loopstart.

1 Use the voice command to add the POTS to GR303 connection.

zSH> voice add pots 1-8-1-0/voicefxs gr303 1/2 enableCreated subscriber 1/13Created subscriber-voice 1/13/1Created subscriber-voice-pots 20Created gr303-ig-crv 1/2Created subscriber-voice-gr303 21

zSH> voice add pots 1-5-2-0/voicefxs gr303 1/4 Created subscriber-voice 1/13/21Created subscriber-voice-pots 41Created gr303-ig-crv 1/4



Created subscriber-voice-gr303 42

zSH> voice add pots 1-5-3-0/voicefxs gnd aal2 uplinkima3/atm vc 0/36 td 1/1 cid 16Created subscriber-voice 1/34/2Created subscriber-voice-pots 45Created atm-vcl uplinkima3/atm/0/36Created aal2-cid-profile 43/0/36/16Created subscriber-voice-aal2 46

2 View the voice connection:

zSH> voice show 1-8-1-0/voicefxs

Subscriber end-point Remote end-point Voice Prof Id STA------------------------------ ------------------------------ -------------- ---1-8-1-0/voicefxs GR303 Zhone/2 1/13/1 ENATotal number of voice connections : 1

Configuring POTS to V.52 connections The MALC interconnects POTS equipment directly to V5.2 switches. For POTS subscriber to V5.2 voice gateway connections, the V5.2 IG must exist before the voice connection can be configured.

The voice ring command can be used to verify a POTS voice connection without placing a call. The voice status command can be used to display runtime voice port status, verify the phone’s ring status if the ringing cannot be heard, and display interface group status.

1 Use the voice command to add the POTS to V5.2 connection.

zSH> voice add pots 1-8-1-0/voicefxs v52 1/28 type potsCreated subscriber 1/13Created subscriber-voice 1/13/1Created subscriber-voice-pots 10013Created v52-user-port 1/28/2Created subscriber-voice-v52 10014


zSH> voice showSubscriber end-point Remote end-point Voice Prof Id STA------------------------------ ------------------------------ -------------- ---1-8-1-0/voicefxs V52 1/28 1/13/1 ENATotal number of voice connections : 1

Voice over IP (VoIP) connections

The following procedures describe how to configure POTS to VoIP subscriber voice connections. POTS subscribers can be connected to VoIP remote endpoints.

Configuring Voice


For VoIP voice connections, several optional arguments such as codec are supported in the remote information of the voice add command. Supported codecs are:

• g711mu (the default setting)

• g711a

• g726

• g729a

• g723

The MALC G.729A VoIP compression provides an optional fallback mode to G.711. The parameter for the fallback mode is g711-fallback and is set in the subscriber-voice-voip profile.The default settings for the subscriber-voice-voip profile are:

• preferred-codec: g711mu

• g711-fallback: true

• frames-per-packet: 4

• g726-byte-order: bigendian

• voip-password: password

The following VoIP remote information is available:

voip IpIfname dn dir-num [name username] [pw password] [plar dest-ipaddr] [reg serverId] [codec pref-codec]

Note: For MGCP and Megaco calls, the MALC ignores the preferred-codec setting and selects the codec from a list provided by the MGCP server or media gateway controller.

Before creating VoIP connections, ensure that the IP interface, VoIP system, and VoIP server settings are configured properly.


• Configuring VoIP interface on page 205

• Configuring SIP and SIP PLAR servers on page 206

• Configuring MGCP on page 209

• Configuring MEGACO (H.248) on page 211

• Creating POTS to VoIP connections on page 215

Note: Communication with SIP phones is only possible over one interface of the MALC. Communication with SIP phones that are in the same network as other interfaces on the MALC is not supported.



Configuring VoIP interface 1 Configure an IP interface for VoIP. For example:

zSH> new ip-interface-record 1-1-1-0/ipPlease provide the following: [q]uit.vpi: ---------------> {0}:vci: ---------------> {0}:rdindex: -----------> {1}:dhcp: --------------> {none}: ** read-only **addr: --------------> {0.0.0.0}: 192.168.87.2netmask: -----------> {0.0.0.0}: 255.255.255.0bcastaddr: ---------> {0.0.0.0}: 192.168.87.255destaddr: ----------> {0.0.0.0}:farendaddr: --------> {0.0.0.0}:mru: ---------------> {1500}:reasmmaxsize: ------> {0}:ingressfiltername: -> {}:egressfiltername: --> {}:pointtopoint: ------> {no}:mcastenabled: ------> {yes}:ipfwdenabled: ------> {yes}:mcastfwdenabled: ---> {yes}:natenabled: --------> {no}:bcastenabled: ------> {yes}:ingressfilterid: ---> {0}:egressfilterid: ----> {0}:ipaddrdynamic: -----> {static}:dhcpserverenable: --> {false}:subnetgroup: -------> {0}:unnumberedindex: ---> {0}:mcastcontrollist: --> {}:vlanid: ------------> {0}:maxVideoStreams: ---> {0}:....................Save new record? [s]ave, [c]hange or [q]uit: sRecord updated.

2 Configure a system IP address:

zSH> update system 0Please provide the following: [q]uit.syscontact: -----------> {Zhone Technologies 7001 Oakport Street Oakland CA 94621}:sysname: --------------> {Zhone Malc}}:syslocation: ----------> {}:enableauthtraps: ------> {disabled}:setserialno: ----------> {0}:zmsexists: ------------> {false}:zmsconnectionstatus: --> {inactive}:zmsipaddress: ---------> {0.0.0.0}:configsyncexists: -----> {false}:configsyncoverflow: ---> {false}:configsyncpriority: ---> {high}:configsyncaction: -----> {noaction}:

Configuring Voice


configsyncfilename: ---> {}:configsyncstatus: -----> {syncinitializing}:configsyncuser: -------> {}:configsyncpasswd: -----> {** private **}: ** read-only **numshelves: -----------> {1}:shelvesarray: ---------> {}:numcards: -------------> {1}:ipaddress: ------------> {0.0.0.0}: 192.168.7.45alternateipaddress: ---> {0.0.0.0}:countryregion: --------> {us}:primaryclocksource: ---> {0/0/0/0/0}:ringsource: -----------> {internalringsourcelabel}:revertiveclocksource: -> {true}:voicebandwidthcheck: --> {false}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

SIP server configuration

Configuring SIP and SIP PLAR serversThe VOIP protocol setting can be configured as either Media Gateway Control Protocol (MGCP) or Session Initiation Protocol (SIP) signaling. By default, the MALC uses SIP signaling.

Note: Redundant SIP server support is implemented through DNS lookups for only BroadSoft software configurations.

SIP signalling identifies callers and callees by SIP addresses and allows signals to be redirected to proxy servers.

The MALC supports single softswitch configurations.

Note: If all SIP calls do not register after a system reboot, increase the server-max-timer value in the voice-system profile to a higher value, for example 180 seconds. The default value is 20 seconds.

To configure SIP:

1 Create the voip-server-entry profiles to specify the VOIP server groups and IDs.

The voip-server-entry profiles is specified with server group and server ID numbers. This example configures a SIP server in server group 1 with server ID 1.

zSH> new voip-server-entry 1/1zhoneVoipServerAddrType: ----------> {ipv4}:zhoneVoipServerAddr: --------------> {0.0.0.0}:zhoneVoipServerUdpPortNumber: -----> {5060}:zhoneVoipServerId: ----------------> {generic}:



protocol: -------------------------> {sip}:sendCallProceedingTone: -----------> {false}:rtcpEnabled: ----------------------> {false}:rtcpPacketInterval: ---------------> {5000}:interdigitTimeOut: ----------------> {10}:ipTos: ----------------------------> {0}:systemDomainName: -----------------> {}:expires-invite-value: -------------> {3600}:expires-register-value: -----------> {3600}:expires-header-method: ------------> {register}:session-timer: --------------------> {off}:session-expiration: ---------------> {180}:session-min-session-expiration: ---> {180}:session-caller-request-timer: -----> {no}:session-callee-request-timer: -----> {no}:session-caller-specify-refresher: -> {omit}:session-callee-specify-refresher: -> {uac}:dtmf-mode: ------------------------> {rfc2833}:....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

SIP PLAR voice connections require the entry of the profile voip-server-entry 255/255. This entry serves as the default server entry. The zhoneVoipServerAddr must be 0.0.0.0.

zSH> new voip-server-entry 255/255zhoneVoipServerAddrType: ----------> {ipv4}:zhoneVoipServerAddr: --------------> {0.0.0.0}:zhoneVoipServerUdpPortNumber: -----> {5060}:zhoneVoipServerId: ----------------> {generic}:protocol: -------------------------> {sip}:sendCallProceedingTone: -----------> {false}:rtcpEnabled: ----------------------> {false}:rtcpPacketInterval: ---------------> {5000}:interdigitTimeOut: ----------------> {10}:ipTos: ----------------------------> {0}:systemDomainName: -----------------> {}:expires-invite-value: -------------> {3600}:expires-register-value: -----------> {3600}:expires-header-method: ------------> {register}:session-timer: --------------------> {off}:session-expiration: ---------------> {180}:session-min-session-expiration: ---> {180}:session-caller-request-timer: -----> {no}:session-callee-request-timer: -----> {no}:session-caller-specify-refresher: -> {omit}:session-callee-specify-refresher: -> {uac}:dtmf-mode: ------------------------> {rfc2833}:....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

Configuring Voice


Note: The voip-system profile is no longer used.

2 Verify that the voip-server-entry profile configuration:

zSH> get voip-server-entry 255/255Please provide the following: [q]uit.zhoneVoipServerAddrType: ----------> {ipv4}:zhoneVoipServerAddr: --------------> {0.0.0.0}: zhoneVoipServerUdpPortNumber: -----> {5060}: zhoneVoipServerId: ----------------> {generic}: protocol: -------------------------> {sip}: sendCallProceedingTone: -----------> {false}:rtcpEnabled: ----------------------> {false}:rtcpPacketInterval: ---------------> {5000}:interdigitTimeOut: ----------------> {10}:ipTos: ----------------------------> {0}:systemDomainName: -----------------> {}:expires-invite-value: -------------> {3600}:expires-register-value: -----------> {3600}:expires-header-method: ------------> {register}:session-timer: --------------------> {off}:session-expiration: ---------------> {180}:session-min-session-expiration: ---> {180}:session-caller-request-timer: -----> {no}:session-callee-request-timer: -----> {no}:session-caller-specify-refresher: -> {omit}:session-callee-specify-refresher: -> {uac}:dtmf-mode: ------------------------> {rfc2833}:zSH>

Table 8 specifies the IP TOS settings used in the voip-server-entry profile based on IP Precedence bits. For IP TOS details, see IP TOS support on page 29.

Table 8: IP TOS settings and IP Precedence bits

Precedence Bits TOS value

0 (Routine) 0

1 (Priority) 32

2 (Immediate) 64

3 (Flash) 96

4 (Flash override) 128

5 (CRITIC/ECP.) 160

6 (Internetwork control) 192

7 (Network control) 224



3 Create a SIP dialplan for the SIP server.

In each dialplan, specify the desired call parameters and use the voip-server-entry parameter to identify the server group for which the dialplan is used. This example references server group 1.

zSH> new sip-dialplan 1Please provide the following: [q]uit.match-string: ----------------> {}: xTsip-ip-address: --------------> {0.0.0.0}: 192.16.88.199destination-name: ------------> {}: number-of-digits: ------------> {0}: 31prefix-strip: ----------------> {0}: prefix-add: ------------------> {}: dialplan-type: ---------------> {normal}:voip-server-entry-index: -----> {0}: 1override-interdigit-timeout:--> {0}: 3....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

MGCP configuration

Configuring MGCP The protocol setting can be configured as either Media Gateway Control Protocol (MGCP), Megaco (H.248), or Session Initiation Protocol (SIP) signaling. By default, the MALC uses SIP signaling. For H.248 procedures, see Configuring MEGACO (H.248) on page 211.

MGCP signalling establishes call control elements or call agents to handle call control. MGCP devices execute the commands sent by the call agents. The MALC supports the voice message waiting indicator (VMWI) for MGCP connections.

The MALC supports two MGCP servers per VoIP system. In order to support multiple MGCP servers, the servers must be configured as redundant MGCP servers with redundant peer support enabled.

During the MALC system boot up, the MALC determines which redundant MGCP server to use. Then, during operations the MALC sends data to both the primary and the standy MGCP servers so that both MGCP servers are properly configured should a switch-over occur.

To support multiple MGCP servers, create a voip-server-entry profile with a server group and server ID for each MGCP server.The first number in the ifIndex is for server group id and the second number is for the server ID. For example, 1/2 means server group 1 and server ID 2. The voip-server-entry profiles must use the same server group.

Configuring Voice


Note: Redundant MGCP softswitch configuration for Metaswitch ESA is configured by creating voip-server-entry profiles for each softswitch

This example creates voip-server-entry profiles for two MGCP servers using server group 1 and server IDs 1 and 2.

Note: The MGCP max call limiter is set at 288 calls. When the maximum number of allowable active calls is reach, the outgoing caller hears a congestion tone. For the incoming call, the phone does not ring.

To change the setting to MGCP:

1 Create the voip-server-entry profiles to enable MGCP:

zSH> new voip-server-entry 1/1Please provide the following: [q]uit.zhoneVoipServerAddrType: ----------> {ipv4}:zhoneVoipServerAddr: --------------> {}: 172.16.60.1zhoneVoipServerUdpPortNumber: -----> {5060}: 2727zhoneVoipServerId: ----------------> {generic}: metaswitchprotocol: -------------------------> {sip}: mgcpsendCallProceedingTone: -----------> {false}:rtcpEnabled: ----------------------> {false}:rtcpPacketInterval: ---------------> {5000}:interdigitTimeOut: ----------------> {10}:ipTos: ----------------------------> {0}:systemDomainName: -----------------> {}:expires-invite-value: -------------> {3600}expires-register-value: -----------> {3600}expires-header-method: ------------> {register}session-expiration: ---------------> {80}session-min-SE: -------------------> {180}session-caller-request-timer: -----> {no}session-callee-request-timer: -----> {no}session-caller-specify-refresher: -> {omit}session-callee-specify-refresher: -> {uac}dtmf-mode:------------------------> (rfc2833)....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

zSH> new voip-server-entry 1/2Please provide the following: [q]uit.zhoneVoipServerAddrType: --------> {ipv4}:zhoneVoipServerAddr: ------------> {}: 172.16.60.3zhoneVoipServerUdpPortNumber: ---> {5060}: 2727zhoneVoipServerId: --------------> {generic}: metaswitchprotocol: -------------------------> {sip}: mgcpsendCallProceedingTone: -----------> {false}:rtcpEnabled: ----------------------> {false}:rtcpPacketInterval: ---------------> {5000}:



interdigitTimeOut: ----------------> {10}:ipTos: ----------------------------> {0}:systemDomainName: -----------------> {}:expires-invite-value: -------------> {3600}expires-register-value: -----------> {3600}expires-header-method: ------------> {register}session-expiration: ---------------> {80}session-min-SE: -------------------> {180}session-caller-request-timer: -----> {no}session-callee-request-timer: -----> {no}session-caller-specify-refresher: -> {omit}session-callee-specify-refresher: -> {uac}dtmf-mode:------------------------> (rfc2833)....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

2 The system will automatically reboot if the voice protocol is changed. After the reboot, verify that the voip-server-entry profile is configured for MGCP:

zSH> get voip-server-entry 1/1Please provide the following: [q]uit.zhoneVoipServerAddrType: ----------> {ipv4}:zhoneVoipServerAddr: --------------> {172.16.60.1}: zhoneVoipServerUdpPortNumber: -----> {2472}: zhoneVoipServerId: ----------------> {tekelec-t6000}: protocol: -------------------------> {mgcp}: sendCallProceedingTone: -----------> {false}:rtcpEnabled: ----------------------> {false}:rtcpPacketInterval: ---------------> {5000}:interdigitTimeOut: ----------------> {10}:ipTos: ----------------------------> {0}:systemDomainName: -----------------> {}:expires-invite-value: -------------> {3600}expires-register-value: -----------> {3600}expires-header-method: ------------> {register}session-expiration: ---------------> {0}session-min-SE: -------------------> {-606348325}session-caller-request-timer: -----> {no}session-callee-request-timer: -----> {no}session-caller-specify-refresher: -> {omit}session-callee-specify-refresher: -> {uac}omitsession-callee-specify-refresher:-> (uac)dtmf-mode:------------------------> (inband)

Configuring MEGACO (H.248)The protocol setting can be configured as either Media Gateway Control Protocol (MGCP), MEGACO (H2.48), or Session Initiation Protocol (SIP) signaling. By default, the MALC uses SIP signaling.

The MEGACO protocol is used between elements of a physically decomposed multimedia gateway. The distributed multimedia gateway

Configuring Voice


sub-components create a general framework used for gateways, multipoint control units and interactive voice response units (IVRs). Redundant Megaco servers are supported.

The MALC supports two VoIP servers per VoIP system. In order to support multiple VoIP servers, the servers must be configured as redundant VoIP servers with redundant peer support enabled.

During the MALC system boot up, the MALC determines which redundant VoIP server to use. Then, during operations the MALC sends data to both the primary and the standy VoIP servers so that both servers are properly configured should a switch-over occur.

To support multiple VoIP servers, create a voip-server-entry profile with a server group and server ID for each server.The first number in the ifIndex is for server group id and the second number is for the server ID. For example, 1/2 means server group 1 and server ID 2. The voip-server-entry profiles must use the same server group.

This example creates voip-server-entry profiles for two VoIP servers using server group 1 and server IDs 1 and 2.

To change the setting to MEGACO:

1 Create the voip-server-entry profiles to enable Megaco:

zSH> new voip-server-entry 1/1Please provide the following: [q]uit.zhoneVoipServerAddrType: ----------> {ipv4}:zhoneVoipServerAddr: --------------> {}: 172.16.60.1zhoneVoipServerUdpPortNumber: -----> {5060}: 2944zhoneVoipServerId: ----------------> {generic}: protocol: -------------------------> {sip}: megacosendCallProceedingTone: -----------> {false}:rtcpEnabled: ----------------------> {false}:rtcpPacketInterval: ---------------> {5000}:interdigitTimeOut: ----------------> {10}:ipTos: ----------------------------> {0}:systemDomainName: -----------------> {}:expires-invite-value: -------------> {3600}expires-register-value: -----------> {3600}expires-header-method: ------------> {register}session-expiration: ---------------> {0} 180session-min-SE: -------------------> {-606348325} 180session-caller-request-timer: -----> {no}session-callee-request-timer: -----> {no}session-caller-specify-refresher: -> {omit}session-callee-specify-refresher: -> {uac}omitsession-callee-specify-refresher:-> (uac)dtmf-mode:------------------------> (inband) rfc2833....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

zSH> new voip-server-entry 1/2



Please provide the following: [q]uit.zhoneVoipServerAddrType: --------> {ipv4}:zhoneVoipServerAddr: ------------> {}: 172.16.60.3zhoneVoipServerUdpPortNumber: ---> {5060}: 2944zhoneVoipServerId: --------------> {generic}: protocol: -------------------------> {sip}: megacosendCallProceedingTone: -----------> {false}:rtcpEnabled: ----------------------> {false}:rtcpPacketInterval: ---------------> {5000}:interdigitTimeOut: ----------------> {10}:ipTos: ----------------------------> {0}:systemDomainName: -----------------> {}:expires-invite-value: -------------> {3600}expires-register-value: -----------> {3600}expires-header-method: ------------> {register}session-expiration: ---------------> {0} 180 session-min-SE: -------------------> {-606348325} 180session-caller-request-timer: -----> {no}session-callee-request-timer: -----> {no}session-caller-specify-refresher: -> {omit}session-callee-specify-refresher: -> {uac}omitsession-callee-specify-refresher:-> (uac)dtmf-mode:------------------------> (inband) rfc2833....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

2 The system will automatically reboot if the voice protocol is changed. After the reboot, verify that the voip-server-entry profile is configured for MEGACO:

zSH> get voip-server-entry 1/1Please provide the following: [q]uit.zhoneVoipServerAddrType: ----------> {ipv4}:zhoneVoipServerAddr: --------------> {172.16.60.1}: zhoneVoipServerUdpPortNumber: -----> {2944}: zhoneVoipServerId: ----------------> {generic}: protocol: -------------------------> {megaco}: sendCallProceedingTone: -----------> {false}:rtcpEnabled: ----------------------> {false}:rtcpPacketInterval: ---------------> {5000}:interdigitTimeOut: ----------------> {10}:ipTos: ----------------------------> {0}:systemDomainName: -----------------> {}:expires-invite-value: -------------> {3600}expires-register-value: -----------> {3600}expires-header-method: ------------> {register}session-expiration: ---------------> {180}session-min-SE: -------------------> {180}session-caller-request-timer: -----> {no}session-callee-request-timer: -----> {no}session-caller-specify-refresher: -> {omit}session-callee-specify-refresher: -> {uac}omitsession-callee-specify-refresher:-> (uac)

Configuring Voice


dtmf-mode:------------------------> (rfc2833)

3 Set the keep alive timer for VoIP servers in the voice-system profile. The server-max-timer specifies the period between ServiceChange request messages. The keep alive timer specifies how often the MALC expects keep alive messages from the Gateway Controller.

If the MALC does not receive a keep alive message from the Gateway Controller in this interval, it sends an empty NTFY message to the controller. This should cause the controller to send a response.

If the MALC still does not receive a response to the NTFY message in a period equal to 4 times the keep-alive-timer, it will send a ServiceChange message to the Gateway Controller at an interval equal to the keep-alive-timer.

zSh> update voice-system 0Please provide the following: [q]uit.hookflash-min-timer: -------> {100}:hookflash-max-timer: -------> {1550}:partial-dial-timeout: ------> {16}:critical-dial-timeout: -----> {4}:busy-tone-timeout: ---------> {30}:dial-tone-timeout: ---------> {16}:msg-wait-tone-timeout: -----> {16}:offhook-warn-tone-timeout: -> {0}:ringing-timeout: -----------> {180}:ringback-timeout: ----------> {180}:reorder-tone-timeout: ------> {30}:stutter-tone-timeout: ------> {16}:server-max-timer: ----------> {20}:config-max1: ---------------> {5}:config-max2: ---------------> {7}:max1-enable: ---------------> {true}:max2-enable: ---------------> {true}:max-waiting-delay: ---------> {600}:disconnection-wait-timer: --> {15}:disconnection-min-timer: ---> {15}:disconnection-max-timer: ---> {600}:max-retransmit-timer: ------> {4}:init-retransmit-timer: -----> {200}:keep-alive-timer: ----------> {60}:no-response-timer: ---------> {30}:call-wait-max-repeat: ------> {2}:call-wait-delay: -----------> {10}:pulse-inter-digit-timer: ---> {100}:min-make-pulse-width: ------> {25}:max-make-pulse-width: ------> {55}:min-break-pulse-width: -----> {45}:max-break-pulse-width: -----> {75}:server-max-timer: ----------> {20} keep-alive-timer: ----------> {60} 90....................Save changes? [s]ave, [c]hange or [q]uit: s



Record updated.

Creating POTS to VoIP connections This example creates a POTS to VoIP subscriber.

1 Use the voice command to add the POTS to VoIP connection. This examples creates a connection with a directory number 510-522-0401 and the name smith. The VoIP endpoint user name is case sensitive and must match the voice switch requirements, for example AAL/1 for MGCP with the Tekelec T6000 or TP/0001 for Megaco with Nortel CS2K.


zSH> voice add pots 1-3-1-0/voicefxs voip ethernet3-100/ip DN 5105220401 name smithCreated subscriber-voice 1/2/1Created subscriber-voice-pots 1004Created subscriber-voice-voip 1005


zSH> voice showSubscriber end-point Remote end-point Voice Prof Id STA------------------------------ ------------------------------ ----------- ---1-3-1-0/voicefxs ethernet3-100/ip DN 5105220401 1/2/1 ENATotal number of voice connections : 1

Caution: Avoid changes or deletions to the ip-interface-record profile after creating a voice connection on that interface.

Additional VoIP featuresThis section describes the configurable VoIP features for VoIP-enabled services.

• Setting VoIP features on page 216

• Changing the hookflash timer values on page 216

• Configuring always offhook on page 217

• Configuring huntgroups on page 219

• SIP dialing plans on page 223

• Malicious caller on page 225

• Call conferencing on page 225

Configuring Voice


Setting VoIP featuresTo configure VoIP features:

zSH> update subscriber-voice 1/2/1Please provide the following: [q]uit.voice-connection-type: --------> {voiptopots}: ** read-only **voice-endpoint1-addr-index: ---> {1}: ** read-only **voice-endpoint2-addr-index: ---> {1001}: ** read-only **voice-connection-description: -> {}:voice-admin-status: -----------> {enabled}:huntgroup: --------------------> {false}: ** read-only **features: ---------------------> {hookflash+onhooksignaling}: hookflash.Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Changing the hookflash timer valuesThe hookflash timer values can be configured to a specified range between minimum and maximum values. If hookflash is enabled on a VoIP subscriber, a hookflash is considered only if the onhook time is between the minimum and maximum timer values. Any time less than the minimum time setting is ignored and any time more than the maximum time setting is considered to be onhook.

Modify the following parameters in the subscriber-voice profile to change hookflash timer settings.

To change the hookflash timer values:

zSH> update voice-system 0Please provide the following: [q]uit.hookflash-max-timer: -> {1550}: 2000hookflash-min-timer: -> {100}: 500partial-dial-timeout: ------> {16}:


hookFlashTimerMin Specifies the minimum hookflash timer value in milliseconds.Values: 0 to 2147483647 Default: 100 milliseconds

hookFlashTimerMax Specifies the maximum hookflash timer value in milliseconds.Values: 0 to 2147483647 Default: 1550 milliseconds



critical-dial-timeout: -----> {4}:busy-tone-timeout: ---------> {30}:dial-tone-timeout: ---------> {16}:msg-wait-tone-timeout: -----> {16}:offhook-warn-tone-timeout: -> {0}:ringing-timeout: -----------> {180}:ringback-timeout: ----------> {180}:reorder-tone-timeout: ------> {30}:stutter-tone-timeout: ------> {16}:server-max-timer: ----------> {20}:config-max1: ---------------> {5}:config-max2: ---------------> {7}:max1-enable: ---------------> {true}:max2-enable: ---------------> {true}:max-waiting-delay: ---------> {600}:disconnection-wait-timer: --> {15}:disconnection-min-timer: ---> {15}:disconnection-max-timer: ---> {600}:max-retransmit-timer: ------> {4}:init-retransmit-timer: -----> {200}:keep-alive-timer: ----------> {60}:no-response-timer: ---------> {30}:call-wait-max-repeat: ------> {2}:call-wait-delay: -----------> {10}:pulse-inter-digit-timer: ---> {100}:min-make-pulse-width: ------> {25}:max-make-pulse-width: ------> {55}:min-break-pulse-width: -----> {45}:max-break-pulse-width: -----> {75}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Configuring always offhookSome subscribers require circuits to remain permanently offhook to enable VoIP services such as two-way radio. Provision always offhook for MALC E&M TO subscribers to enable receiving two-way radio calls. Any incoming calls to this subscriber will be established right away.

Note: After setting always offhook, users cannot make outgoing calls.

Configuring Voice


Modify the following parameter to configure always offhook:

1 Disable the subscriber and set always offhook:

zSH> update subscriber-voice 1/2/1Please provide the following: [q]uit.voice-connection-type: --------> {voiptopots}: ** read-only **voice-endpoint1-addr-index: ---> {1}: ** read-only **voice-endpoint2-addr-index: ---> {1001}: ** read-only **voice-connection-description: -> {}:voice-admin-status: -----------> {enabled}: disabledhuntgroup: --------------------> {false}: ** read-only **features: ---------------------> {hookflash+onhooksignaling}: hookflash+onhooksignaling+alwaysoffhook....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

2 Re-enable the subscriber

zSH> update subscriber-voice 1/2/1Please provide the following: [q]uit.voice-connection-type: --------> {voiptopots}: ** read-only **voice-endpoint1-addr-index: ---> {1}: ** read-only **voice-endpoint2-addr-index: ---> {1001}: ** read-only **voice-connection-description: -> {}:voice-admin-status: -----------> {disabled}: enabledhuntgroup: --------------------> {false}: ** read-only **features: ---------------------> {hookflash+onhooksignaling+alwaysoffhook}:....................Save new record? [s]ave, [c]hange or [q]uit: sRecord updated.


features Shows the set of VoIP features that are enabled for the subscriber.Hookflash is supported only on VoIP SIP POTS subscribers. Onhook is supported on all VoIP subscribers. Always offhook is supported on FXS and E&M (Z-Edge 6200) subscribers. Values: hookflash hookflash detection.onhooksignaling onhook signaling.alwaysoffhook call is established as soon as incoming call initiation is made.Default: hookflash+onhooksignalingOptions: + This parameter allows multiple settings by using the + option.



Configuring huntgroupsHuntgroups are used to specify a group of people to receive incoming calls and determine which phone within that group will ring when a call comes in. For example, a company’s technical support phone number is 555-8000 and there are three members of the technical support team. Each one of the technical support members has a separate phone number, which is not 555-8000. With huntgroups, incoming calls to 555-8000 are directed to one of the technical support team.

When a call comes in on 555-8000, calls will be placed on E&M ports 1, 2, or 3 in a round-robin fashion: The first time a call comes in, the phone on port 1 will ring; the second time a call comes in, the phone on port 2 will ring; the third time a call comes in, the phone on port 3 will ring, and fourth time a call comes in, the phone on port 1 will ring again. Each subscriber can belong to three huntgroups.

Modify the huntgroup parameter in the subscriber-voice profile to enable huntgroups:

Modify the following parameters in the subscriber-voice-pots profile to enable huntgroups:


huntgroup Can be set to true only if the voice-connection-type is siptopots or siptods1. If it is set to true only subscriber-voice-endpt1 gets automatically created, but not subscriber-voice-endpt2.Values: truefalseDefault: false


hunt-group-index-1 The subscriber is part of this huntgroup. The hunt group endpoint index is derived from the voice-endpoint2-addr-index of the subscriber-voice connection which has huntgroup set to true.

Configuring Voice


Modify the following parameters in the subscriber-voice-voip profile to enable huntgroups:

Creating huntgroups on already existing subscribers built with no huntgroupsTo enable huntgroups on already-existing subscribers that do not have huntgroups:

1 Create a subscriber-voice profile which can support huntgroups:

zSH> new subscriber-voice 1/132/1 subId/lineGroupId/subVoiceIdPlease provide the following: (q=quit)voice-connection-type: ---------->[NONE(0)]: siptopotsvoice-endpoint1-addr-index: ----->[0]: 1 index for the subscriber-voice-voip profilevoice-endpoint2-addr-index: ----->[0]: 99 index for the huntgroup voice-connection-description: --->[]: voice-admin-status: ------------->[disabled]: huntgroup:--------------------> [false]: true.......................Save new record? (s=save/c=change/q=quit): sNew record saved.




sip-uri A uniform resource identifier (URI) which acts as a unique SIP identity for the subscriber.

directory-number1 The phone number assigned to this endpoint.

ip-interface-index Index of the interface through which the SIP signalling and real time protocol (RTP) traffic will flow.




After creating the subscriber-voice-profile with the huntgroup parameter set to true, the system automatically creates the associated subscriber-voice-voip profile.

2 Update the SIP voice endpoint:

zSH> update subscriber-voice-voip 1Please provide the following: [q]uit.sip-uri: ------------> {}: supportdirectory-number: ---> {}: 5558000ip-interface-index: -> {0/0/0/0/0}: 1/1/1/0/ippreferred-code: -----> {g711mu}: g711-fallback: ------> {true}: frames-per-packet: --> {4}: g726-byte-order: ----> {bigendian}: sip-password: -------> {}: ....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

3 Update one of the pre-existing subscriber-voice-pots profiles:

zSH> update subscriber-voice-pots 2 Please provide the following: [q]uit.voice-pots-line-group-id: -> {2}hunt-group-index-1: -------> {} 99 matches the voice-endpoint2-addr-index from subscriber-voice profilehunt-group-index-2: -------> {0}hunt-group-index-3: -------> {0}....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Creating subscribers built with pre-existing huntgroupsTo enable huntgroups on already-existing subscribers that already have huntgroups created in the subscriber-voice-pots profile:

1 Find the huntgroup index from the pre-existing subscriber-voice-pots profile.

After creating the subscriber-voice-profile with the huntgroup parameter is set to true, the system automatically creates the associated subscriber-voice-voip profile.


zSH> update subscriber-voice-voip 2Please provide the following: [q]uit.sip-uri: ------------> {}: supportdirectory-number: ---> {}: 5558000ip-interface-index: -> {0/0/0/0/0}: 1/1/1/0/ippreferred-code: -----> {g711mu}: g711-fallback: ------> {true}: frames-per-packet: --> {4}: g726-byte-order: ----> {bigendian}:

Configuring Voice


sip-password: -------> {}: ....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Creating new subscribers with huntgroups enabledTo create new subscribers with huntgroups enabled:

Create a subscriber-voice profile which can support huntgroups:

After creating the subscriber-voice-profile with the huntgroup parameter set to true, the system automatically creates the associated subscriber-voice-voip profile.


zSH> update subscriber-voice-voip 3Please provide the following: [q]uit.sip-uri: ------------> {}: support3directory-number: ---> {}: 5559000ip-interface-index: -> {0/0/0/0/0}: 1/1/1/0/ippreferred-code: -----> {g711mu}: g711-fallback: ------> {true}: frames-per-packet: --> {4}: g726-byte-order: ----> {bigendian}: sip-password: -------> {}: ....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

2 Create a subscriber-voice profile without huntgroups:

zSH> new subscriber-voice 1/132/99Please provide the following: (q=quit)voice-connection-type: ---------->{aal2togr303}: siptopotsvoice-endpoint1-addr-index: ----->{0}: 8 index for the subscriber-voice-voip profilevoice-endpoint2-addr-index: ----->{0}: 9 index for the subscriber-voice-pots profilevoice-connection-description: --->{}: voice-admin-status: ------------->{disabled}: huntgroup:--------------------> {false}:.......................Save new record? (s=save/c=change/q=quit): sNew record saved.

3 Update the subscriber-voice-voip profile:

zSH> update subscriber-voice-voip 9Please provide the following: [q]uit.sip-uri: ------------> {}: johnsmithdirectory-number: ---> {}: 5559999ip-interface-index: -> {0/0/0/0/0}: 1/1/1/0/ippreferred-code: -----> {g711mu}: g711-fallback: ------> {true}: frames-per-packet: --> {4}:



g726-byte-order: ----> {bigendian}: sip-password: -------> {}: ....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

4 Update the subscriber-voice-pots profile to match the huntgroup created:

zSH> update subscriber-voice-pots 9 Please provide the following: [q]uit.voice-pots-line-group-id: -> {9}hunt-group-index-1: -------> {} 88 matches the voice-endpoint2-addr-index from subscriber-voice profilehunt-group-index-2: -------> {0}hunt-group-index-3: -------> {0}....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

SIP dialing plansA dialing plan for POTS-to-SIP outgoing calls consists of a series of acceptable dial strings and the corresponding IP addresses to which SIP control messages are sent to initiate the call.

Each dial string is represented as digits, wildcards, and regular-expression-like patterns according to the following rules:

• Digits 0 to 9 are allowed as well as * and #.

• A wildcard ? represents any digit 0 to 9

• The character x to indicate a wildcard for 0 or more digits between 0-9.

• A dial-string character T can be used in the override-interdigit-timeout parameter value in the SIP dialplan.

Examples:

– 0T for the number zero and nothing else.

– 011T for numbers 011 then any number of digits before the interdigit time out.

– 9T for the number 9 and any number of digits before the interdigit time out.

– #T anything followed by a # and an interdigit time out.

• A digit range can be specified using brackets [ ], as follows:[135] means digits 1, 3, or 5.[1-4] means digits 1, 2, 3, or 4.

Configuring Voice


Create a sip-dialplan profile for outgoing VoIP calls by modifying the following parameters:

zSH> new sip-dialplan 1Please provide the following: [q]uit.match-string: ----------------> {}: 510555101[1-9]sip-ip-address: --------------> {0.0.0.0}: 192.16.88.199destination-name: ------------> {}: callernumber-of-digits: ------------> {0}: 10prefix-strip: ----------------> {0}: 1prefix-add: ------------------> {}: 0dialplan-type: ---------------> {normal}:voip-server-entry-index: -----> {0}: 1override-interdigit-timeout:--> {0}: 22....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.


match-string A dial string against which collected digits are matched.

sip-ip-address Upon detecting a match between the collected digits and the dial string, this IP address is used for SIP negotiations to initiate the call.

destination -name User-specified name of the destination for the dial string.

number-of-digits Number of digits to wait for before initiating the call.

prefix-strip Number of prefix digits to strip from dialled digits.

prefix-add String to be added to the beginning of the dialled digits before call initiation.

dialplan-type Type of the dial plan. Dialplan types are:

• Normal

• Call Park

voip-server-entry-index An index to associated voip-server-entry for this sip-dialplan. This index references the registration server specified in the voip-server-entry profile.

override-interdigit-timeout Override the partial-dial-timeout value in voice-system profile.

Call conferencing


Malicious callerThe malicious caller feature enables you to configure caller uniform resource identifiers (URIs) so that incoming calls with the configured URIs will be rejected.

The URI can be configured as either a telephone number (RFC 2806) or an alphanumeric identification (RFC 2806). URI entries are case sensitive, should not contain visual separations and must be the exact length as they appear in incoming session notification’s (SIP INVITE) calling user’s address-of-record (AOR).

Specifying a malicious caller Configure malicious caller URIs in the malicious-caller profile. The following parameters are supported in this profile:

To specify a malicious caller:

Create a new malicious-caller profile to reject a particular caller:

zSH> new malicious-caller 1Please provide the following: [q]uit.malicious-caller-uri: -> {}: [email protected]: -------> {true}:Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Call conferencingThe MALC call conferencing feature enables three-way conference calls during which three parties can use one calling session to communicate. The MALC POTS-TDM-/PKT-48 card and the ADSL+POTS TDM/PKT-48A-2S combination cards support call conferencing. These cards work with any VOIP-enabled uplink card installed in the MALC.


malicious-caller-uri The URI for which incoming calls will be rejected. The network operator is responsible for provisioning the URI exactly as per appearance in the incoming session notification (SIP INVITE) the calling user's address-of-record (AOR) formatted as a SIP URI.

reject-enabled Enables and disables the rejection of calls matching the configured malicious caller URI.Default: true

Configuring Voice


The MALC call conferencing feature deploys an efficient end-mixing conference call technology, avoiding the overhead of the centralized conference server.

Three-way call conferencing follows the Telcordia (Bellcore) three-way calling standard called Telcordia - TR - TSY - 000577, Three-Way Calling.

Configuring call conferencing on the MALC. The call conference feature is enabled through the features parameter in the subscriber-voice profile for callers using the specified port on a MALC POTS-TDM-/PKT-48 card or ADSL+POTS TDM/PKT-48A-2S card. By default, this feature is disabled.

To enable conferencing, use the voice show command to identify voice ID for the desired voice subscriber. Then, update the subscriber-voice profile for the desired subscriber with support for hookflash and conference. Additional features such as onhooksignaling and call waiting can also be added.

The following example configures call conferencing along with onhooksignaling and call waiting for the voice subscriber 1/3/1.

zSH> voice show Subscriber end-point Remote end-point Voice Prof Id STA---------------------------- ------------------------------ -------------- ---1-10-1-0/voicefxs ethernet1-2/ip DN 2408881694 1/3/1 ENA

……………………

zSH> update subscriber-voice 1/3/1Please provide the following: [q]uit.voice-connection-type: --------> {voiptopots}: ** read-only **voice-endpoint1-addr-index: ---> {2}: ** read-only **voice-endpoint2-addr-index: ---> {1}: ** read-only **voice-connection-description: -> {}:voice-admin-status: -----------> {enabled}:huntgroup: --------------------> {false}: ** read-only **features: ---------------------> {hookflash+onhooksignaling+callwait}: hookflash+onhooksignaling+callwait+conference....................Save changes? [s]ave, [c]hange or [q]uit: s

Connecting three-way conference calls. The process of connecting a three-way conference call involves the following steps:

• Caller dials the phone number of the first conference participate.

This establishes a two-way speech path between the caller and the first participate.

• After establishing the call, the caller presses the Flash button or provides hookflash.

This place the first participate on hold and sends a hookflash signal to the MALC for a second dial tone.

Call conferencing


• Caller dials the phone number of the second conference participate.

This establishes a two-way speech path between the caller and the second participate.

• After establishing the second call, the caller presses the Flash button or provides hookflash.

This establishes the three-way conference call.

Note: If the call conference features is not enabled on the MALC and a caller issues a hookflash signal while on an established call, the MALC places the current call on hold and provides a dial-tone for a second call. Subsequent hookflash signals, toggle between the two established calls.

If a hookflash signal is issued during a three-way conference call, the last conference participate is dropped and the call becomes a two-way call.

To disconnect from a three-way conference call:

• The originating caller hangs up, all members of the conference call are disconnected.

• A caller other than the originating caller hangs up, a two-way call between the originating caller and the other caller remains in progress.

Current call conferencing limitations. The following are current limitations to the call conferencing feature:

• Only SIP is supported for conferencing.

• For resource utilization, three-party call conferencing divides the available 48 port resources in to 8 groups of 6 sequential port resources based on physical port number (1-6, 7-12, ... ,43-48). Within a port resource group, any idle port resource may be used for a call, including conference sessions. For a two-way call, one port resource is used. For a three-way conference call, two port resources are used.

If an idle port resource is unavailable because of an on-going conference call within a port resource group, any new two-way call attempts receive a fast-busy tone and any three-way conference call attempts will not succeed. Three-way conference call attempts are restricted to toggling between the established two-way calls.

To minimize call blockage, configure ports in sequence leaving three ports idle in each port resource group. For example:

– Activate ports: 1,2,3,7,8,9,13,14,15,19,20,21,25,26,27,31,32,33,37,38,39,43,44,45,

Configuring Voice


– Idle ports: 4,5,6,10,11,12,16,17,18,22,23,24,28,29,30,34,35,36,40,41,42,46,47,48

As more ports are required, add an additional port from each sequential port resource group until all necessary ports are configured.

AAL2 connections

This section explains the following:

• Creating an ATM traffic descriptor on page 228

• Configuring ISDN to AAL2 connections on page 228

• Configuring POTS to AAL2 connections on page 229

Creating an ATM traffic descriptorBefore configuring ISDN or POTS subscriber voice connections that utilize remote ATM connections to an AAL2 voice gateway, the ATM traffic descriptor must exist.

Note: See Configuring ATM on page 157 for more information on ATM traffic descriptors and parameters.

Create a new atm-traf-descr with a unique index for a voice connection.

zSH> new atm-traf-descr 1 index can be any valuePlease provide the following: [q]uit.td_type: -----------------> {atmNoClpNoScr}: atmClpNoTaggingScrCdvttd_param1: ---------------> {0}: 4826 PCR . td_param2: ---------------> {0}: 4825 SCR td_param3: ---------------> {0}: 20 MBStd_param4: ---------------> {0}: 15000 CDVTtd_param5: ---------------> {0}:cac-divider: -------------> {1}: 10td_service_category: -----> {ubr}: rtvbr for voicetd_frame_discard: --------> {false}:usage-parameter-control: -> {true}:....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Configuring ISDN to AAL2 connectionsThis type of voice connection requires a ULC card.

For ISDN-to-AAL2 configurations, either a voice gateway (such as the MALC Voice Gateway card) or a TDM/ATM Uplink card converts AAL2-derived voice into TDM signaling. For AAL2 connections, the ATM traffic descriptor is required before the voice connection can be configured.

Call conferencing


The voice add command automatically creates the required VPI/VCI, CID, and uplink VCL and sets the following ISDN parameters:

• atm-vcl profile: vcc aal5 cpcs transmit and receive sdu sizes

• aal2-vcl-profile: timer-cu, frame-mode-data, cas, trunk-type, pcm-encoding, and ras-timer, elcp trap

• aal2-cid-profile: frame-mode-data, cas, and pcm-encoding

This voice add command example uses the ISDN interface 1-3-1-0/isdnu, sets the VPI/VCI to 0/38, sets the CID to 127.

1 To configure a ISDN to AAL2 voice connection:

zSH> voice add isdn 1-3-1-0/isdnu aal2 uplink1/atm vc 0/38 cid 127 enableCreated subscriber-voice 1/5/4Created subscriber-voice-isdn 65Created aal2-cid-profile 38/0/38/127Created subscriber-voice-aal2 66Created subscriber-voice 1/5/5Created subscriber-voice-isdn 67Created subscriber-voice-aal2 68Created subscriber-voice 1/5/6Created subscriber-voice-isdn 69Created subscriber-voice-aal2 70

2 View the voice connection

zSH> voice showSubscriber end-point Remote end-point Voice Prof Id STA------------------------------ ------------------------------ -------------- ---1-3-1-0/isdnu 1-1-1-0/ds1 VC 0/38 CID 127 1/5/4 ENA1-3-1-0/isdnu 1-1-1-0/ds1 VC 0/38 CID 158 1/5/5 ENA1-3-1-0/isdnu 1-1-1-0/ds1 VC 0/38 CID 159 1/5/6 ENATotal number of voice connections : 3

Configuring POTS to AAL2 connections For POTS-to-AAL2 configurations, either a voice gateway (such as the MALC Voice Gateway card) or a TDM/ATM Uplink card can be used to convert AAL2-derived voice into TDM signaling. For AAL2 connections, the ATM traffic descriptor is required before the voice connection can be configured. The voice add command automatically creates the required VPI/VCI, CID, and uplink VCL.

This example adds a POTS to AAL2 connection over an ATM VCL with a VPI/VCI of 0/38 and a CID of 16: The PCM-encoding is set to Alaw and the the interface 1-5-24-0/voicefxs is enabled.

The voice ring command can be used to verify a POTS voice connection without placing a call. The voice status command can be used to display runtime voice port status and to verify the phone’s ring status if the ringing cannot be heard.

1 Use the voice command to add the POTS to AAL2 connection.

Configuring Voice


zSH> voice add pots 1-5-24-0/voicefxs alaw aal2 uplink1/atm vc 0/39 td 11/11 cid 16 enableCreated subscriber-voice 1/32/2Created subscriber-voice-pots 10017Created atm-vcl uplink1/atm/0/39Created aal2-cid-profile 38/0/39/16Created subscriber-voice-aal2 10018


zSH> voice showSubscriber end-point Remote end-point Voice Prof Id STA------------------------------ ------------------------------ -------------- ---1-5-24-0/voicefxs 1-2-1-0/atmima VC 0/39 CID 16 1/32/2 ENATotal number of voice connections : 1

DS1 to POTS connections

The MALC can act as a channel bank, interconnecting POTS channels to DS0s on the TDM T1/E1 card or the T1/E1 interface on the OC12-c/STM4 Uplink card. Note that T1 CAS, GR-303, and V5.2 signaling cannot be active on a card at the same time.

Adding a POTS to DS1 connectionTo enable a POTS to DS1 connection, you must reset the line type on the T1/E1 TDM card or OC12-c/STM4 Uplink card.

Caution: Changing the line type for the Uplink card requires a system reboot and deletes the system configuration.

Back up your configuration using the dump command before changing the line type.

1 Change the line type on the T1/E1 TDM card or OC12-c/STM4 Uplink card.

Note: If there is a redundant Uplink card in the system, change that line type for the redundant card before changing it for the active card.

For the T1/E1 TDM card:

a Verify you are at the root of the flash card:

zSH> cd /card1zSH> pwd/card1/

b Back up the current configuration file to the flash card and store it in the onreboot directory:

zSH> mkdir onreboot

Call conferencing


zSH> cd onrebootzSH> dump file restore

This file will be used to restore the system configuration or revert to a previous release, if desired.

c If desired, save the configuration file to a host on the network. For example:zSH> dump network 192.168.8.21 malc.cfg

d Change directories to the root of the flash card:


e Delete the Uplink card-profile:

zSH> delete card-profile 1/1/5114 shelf/slot/type

f Create a new Uplink card-profile and change the card-line-type:

zSH> card add 1/1/5114 linetype t1-uni-t1cas

or

zSH> new card-profile 1/1/5114Please provide the following: [q]uit.sw-file-name: ---------> {}: malcT1E1Tdmf.bin admin-status: ---------> {operational}:upgrade-sw-file-name: -> {}:upgrade-vers: ---------> {}:admin-status-enable: --> {operational}:sw-upgrade-admin: -----> {reloadcurrrev}:sw-enable: ------------> {false}: truesw-upgrade-enable: ----> {false}:card-group-id: --------> {1}: hold-active: ----------> {false}:weight: ---------------> {nopreference}: card-line-type: -------> {unknowntype}: t1-uni-t1cascard-atm-configuration: -> {notapplicable} ....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

After saving the Uplink card-profile, the card will reboot and restore the configuration saved to the onreboot directory. If this is a redundant system, the standby card will take over. You must also change the line type on the redundant card.

For the OC12-c/STM4 Uplink card:

a Verify you are at the root of the flash card:

zSH> cd /card1zSH> pwd

Configuring Voice


/card1/

b Back up the current configuration file to the flash card and store it in the onreboot directory:

zSH> mkdir onrebootzSH> cd onrebootzSH> dump file restore

This file will be used to restore the system configuration or revert to a previous release, if desired.

c If desired, save the configuration file to a host on the network. For example:zSH> dump network 192.168.8.21 malc.cfg

d Change directories to the root of the flash card:


e Delete the Uplink card-profile:

zSH> delete card-profile 1/1/5029 shelf/slot/type

f Create a new Uplink card-profile and change the card-line-type:

zSH> card add 1/1/5114 linetype t1-uni-t1cas

or

zSH> new card-profile 1/1/5029 Please provide the following: [q]uit.sw-file-name: ---------> {}: malcoc12.bin admin-status: ---------> {operational}:upgrade-sw-file-name: -> {}:upgrade-vers: ---------> {}:admin-status-enable: --> {operational}:sw-upgrade-admin: -----> {reloadcurrrev}:sw-enable: ------------> {false}: truesw-upgrade-enable: ----> {false}:card-group-id: --------> {1}: hold-active: ----------> {false}:weight: ---------------> {nopreference}: card-line-type: -------> {unknowntype}: t1-uni-t1cascard-atm-configuration: -> {notapplicable} ....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

After saving the Uplink card-profile, the card will reboot and restore the configuration saved to the onreboot directory. If this is a redundant system, the standby card will take over. You must also change the line type on the redundant card.

Configuring CES connections


2 After the system has finished booting, create the voice connection. The following example maps POTS port 24 to DS0 24 on the T1/E1 TDM card:

zSH> voice add pots 1-5-24-0/voicefxs ds1 1-1-9-0/ds1 ds0 24Created subscriber-voice 1/21/25Created subscriber-voice-pots 83Created subscriber-voice-ds1 84

3 View the voice connection:

zSH> voice show

Subscriber end-point Remote end-point Voice Prof Id STA------------------------------ ------------------------------ -------------- ---1-5-24-0/voicefxs 1-1-9-0/ds1 DS0 24 1/21/25 ENATotal number of voice connections : 1

Configuring CES connectionsCircuit Emulation Service (CES) circuit configuration involves:

• Creating IP interface and unnumbered IP interface on page 233

• Creating CES connections on page 234

• Deleting cross connections and CES over ATM circuits on page 248

Creating IP interface and unnumbered IP interface If using CES over IP, an IP interface and unnumbered IP interface record are required before the CES over IP connection can be created:

Note: CES over IP is only supported on RPR GigE uplinks.

1 Create the IP interface record.

zSH> new ip-interface-record ces/ipPlease provide the following: [q]uit.vpi: ---------------> {0}:vci: ---------------> {0}:rdindex: -----------> {1}:dhcp: --------------> {none}: ** read-only **addr: --------------> {0.0.0.0}: 192.168.100.1netmask: -----------> {0.0.0.0}: 255.255.255.0bcastaddr: ---------> {0.0.0.0}: 192.168.100.255destaddr: ----------> {0.0.0.0}:farendaddr: --------> {0.0.0.0}:mru: ---------------> {1500}:reasmmaxsize: ------> {0}:ingressfiltername: -> {}:egressfiltername: --> {}:

Configuring Voice


pointtopoint: ------> {no}:mcastenabled: ------> {yes}:ipfwdenabled: ------> {yes}:mcastfwdenabled: ---> {yes}:natenabled: --------> {no}:bcastenabled: ------> {yes}:ingressfilterid: ---> {0}:egressfilterid: ----> {0}:ipaddrdynamic: -----> {static}:dhcpserverenable: --> {false}:subnetgroup: -------> {0}:unnumberedindex: ---> {0}:mcastcontrollist: --> {}:vlanid: ------------> {0}:maxVideoStreams: ---> {0}:....................Save new record? [s]ave, [c]hange or [q]uit: sCould not find an appropropriate interface on which to bind the IP record.Could not automatically bind this IP InterfaceNew record saved.

2 Create IP unnumbered record.

zSH> new ip-unnumbered-record 1Please provide the following: [q]uit.ipUnnumberedInterfaceName: -> { }: ces/ip....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Creating CES connections

The CES add command specifies the parameters for one side of the CES over IP connection. Generally, each CES over IP endpoint resides on a different MALC system and must be configured and deleted separately for each side for the circuit.

The cross connect command specifies the parameters for one side of the CES connection over an ATM circuit.The traffic descriptor is used for internal ATM processing. Generally, each CES connection endpoint resides on a different MALC system and must be configured and deleted separately for each side for the circuit.

CES signalingCES connections support both Channel Associated Signaling (CAS) and Common Channel Signaling (CCS) depending on the connection mode and type.

For structured T1 circuits, the CES card supports CAS (robbedbit signaling) for in-band signaling. CAS uses one bit out of every channel in the sixth T1 frame in order to transmit signaling messages. Unstructured T1 circuits



support CCS for out-of-band signaling that uses an entire channel of each T1 frame to transmit signaling.

For structured E1 circuits, CAS can be used to extract signaling information from timeslot 16 and then reinsert signaling data at the other end of the connection. Unstructured E1 circuits transmit all 32 timeslots transparently.

Signal mode is set in the ds1-profile.

zSH> update ds1-profile 1-4-1-0/ds1Please provide the following: [q]uit.line-type: ----------------------> {esf}:line-code: ----------------------> {b8zs}:send-code: ----------------------> {sendnocode}:circuit-id: ---------------------> {ds1}:loopback-config: ----------------> {noloop}:signal-mode: --------------------> {robbedbit}: bitorientedfdl: ----------------------------> {fdlnone}:dsx-line-length: ----------------> {dsx0}:line-status_change-trap-enable: -> {enabled}:channelization: -----------------> {enabledds0}:ds1-mode: -----------------------> {csu}:csu-line-length: ----------------> {csu00}:clock-source-eligible: ----------> {eligible}:transmit-clock-source: ----------> {looptiming}: cell-scramble: ------------------> {true}:coset-polynomial: ---------------> {true}:protocol-emulation: -------------> {network}:signal-type: --------------------> {loopstart}:ds1-group-number: ---------------> {0}:line-power: ---------------------> {disabled}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

CES clockingThe CES card supports two timing modes:

• Loop timing

• Through timing

Loop timing indicates that the timing source is coming from the line. Through timing indicates that the timing sources is from the backplane. The backplane can be set to receive its clocking signal from a port on an uplink card or ports on a line card. When through timing is used, the other side of the CES circuit should be set to loop timing.

If loop timing is used and the card loses its received clock signal, clocking switches to the clock on the board.

Clock mode is set in the DS1-profile. Refer to the MALC Hardware Installation Guide for the procedures on how configure MALC timing.

zSH> update ds1-profile 1-4-1-0/ds1

Configuring Voice


Please provide the following: [q]uit.line-type: ----------------------> {esf}:line-code: ----------------------> {b8zs}:send-code: ----------------------> {sendnocode}:circuit-id: ---------------------> {ds1}:loopback-config: ----------------> {noloop}:signal-mode: --------------------> {robbedbit}:fdl: ----------------------------> {fdlnone}:dsx-line-length: ----------------> {dsx0}:line-status_change-trap-enable: -> {enabled}:channelization: -----------------> {enabledds0}:ds1-mode: -----------------------> {csu}:csu-line-length: ----------------> {csu00}:clock-source-eligible: ----------> {eligible}:transmit-clock-source: ----------> {looptiming}: throughtimingcell-scramble: ------------------> {true}:coset-polynomial: ---------------> {true}:protocol-emulation: -------------> {network}:signal-type: --------------------> {loopstart}:ds1-group-number: ---------------> {0}:line-power: ---------------------> {disabled}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

CES configuration

This section shows configuration examples for the following CES procedures:

• Adding an unstructured T1/E1 CES over IP circuit on page 237

• Adding a structured T1/E1 CES over IP circuit with ds1esfcas signaling on page 240

• Adding unstructured T1 CES circuits on page 242

• Adding a structured T1 CES circuit with ds1esfcas signaling on page 243

• Adding a second DS0 bundle to a structured T1 CES circuit with ds1esfcas signaling on page 244

• Adding unstructured E1 CES circuits on page 245

• Adding a structured E1 CES circuit with e1cas signaling on page 246

• Adding a second cross connect to a structured E1 CES circuit with e1cas signaling on page 247

• Deleting cross connections and CES over ATM circuits on page 248

The CES circuit signaling type is specified in the cross connect command used to create the connection. After cross connect configuration, the signaling type can be modified by updating the ces-config profile.



Note: When required, CES virtual circuits (VCs) are auto-generated from the cross connect command.

The default virtual circuit ranges are VPI 0-3 and VCI 32-127.

After the cross connect command is issued, the system automatically creates the required ces-config profile with the specified signaling type and other settings. The default signaling type basic is required for unstructured, single channel signaling and is used if a signalling type is not specified in the cross connect command. Table 9 on page 237 lists the supported signaling types.

Note: Structured DS0 bundles in cross connects are specified by start and length values and therefore contain contiguous DS0s. To use non-contiguous DS0s, modify the DS0-bundle parameter in the ces-config profile.

For the first DS0 bundle in a structured DS1 circuit, the frame type specified in the cross connect command is written to the DS1 profile and becomes the default frame type for that DS1 circuit. Subsequent DS0 bundles in the same DS1 circuit use the default frame type regardless of the line type specified in the cross connect command. If line type is not specified in the cross connect command, the line type in the DS1 profile is used.

Note: A maximum of 4 structured DS0 bundles can be configured per CES port.

Adding an unstructured T1/E1 CES over IP circuit

Note: This procedure assumes that the T1E1CES12 card is installed and running on the current device, a valid traffic descriptor has been configured, and the unnumbered IP interface record has been created.

To add a CES connection for an unstructured T1/E1 CES over IP circuit, repeat these configuration steps for each endpoint of the circuit.

Table 9: Supported CES signaling types

Signaling Type Description

basic No CAS bits with a single 125 usec frame. Default. Required for unstructured channels.

e1cas CAS bits used in E1 multiframe structure.

ds1esfcas CAS bits used in DS1 ESF multiframe structure.

ds1sfcas CAS bits used in DS1 SF multiframe structure.

Configuring Voice


1 Specify ces add command with the desired settings for each side for the CES circuit. This example specifies an unstructured T1 circuit (single channel). No signaling type or line type are specified. Unstructured channels required basic signaling so the basic signaling type is used. The line type in the DS1-profile is set to ds1unframed. Because no line type is specified in this command, the line type from the DS1-profile is used. The traffic descriptor 102 is autocreated and used for internal processing. Using slot 8, port 2 on the CES card, the static IP addressing is source IP address 10.2.2.82. and destination IP address is 10.2.3.83. The source UDP port number is 48001. The destination UDP port number is 48201.

Note: Ensure the IP routes between the source and destination subnetworks have been configured and are available. UPD port numbers must be between 48000 and 48300.

zSH> ces add 1-8-2-0-ds1/atm ds0 1/24 unstr td 102 llc static 10.2.2.82 10.2.3.83 48001 48002zSH> ces add 1-8-3-0-ds1/atm ds0 1/24 unstr td 102 llc static 10.2.3.83 10.2.2.82 48002 48001

2 Change the administrative status of the ports to up.

zSH> update if-translate 1-8-2-0/ds1Please provide the following: [q]uit.ifIndex: -----------> {200}:shelf: -------------> {1}:slot: --------------> {7}:port: --------------> {1}:subport: -----------> {0}:type: --------------> {ds1}:adminstatus: -------> {down}: upphysical-flag: -----> {true}:iftype-extension: --> {none}:ifName: ------------> {1-7-1-0}:redundancy-param1: -> {0}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.zSH>

zSH> update if-translate 1-8-3-0/ds1Please provide the following: [q]uit.ifIndex: -----------> {200}:shelf: -------------> {1}:slot: --------------> {7}:port: --------------> {1}:subport: -----------> {0}:type: --------------> {ds1}:adminstatus: -------> {down}: upphysical-flag: -----> {true}:iftype-extension: --> {none}:ifName: ------------> {1-7-1-0}:redundancy-param1: -> {0}:....................



Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.zSH>

3 Display the configured cross connection.

zSH> cc show CES

CONNECTION CC CONNECTION--------------------------------------------------------------------------- 1-1-1-0-aal5proxy/atm 0/33 Up 2 Up 1-8-2-0/ds1 1/24 Up 1-1-1-0-aal5proxy/atm 0/34 Up 3 Up 1-8-3-0/ds1 1/24 Up

4 Display the DS1 profile for the configured T1/E1 CES unstructured circuit over IP.

zSH> get ds1-profile 1-8-2-0/ds1line-type: ----------------------> {ds1unframed}line-code: ----------------------> {b8zs}send-code: ----------------------> {sendnocode}circuit-id: ---------------------> {ds1}loopback-config: ----------------> {noloop}signal-mode: --------------------> {none}fdl: ----------------------------> {fdlnone}dsx-line-length: ----------------> {dsx0}line-status_change-trap-enable: -> {enabled}channelization: -----------------> {disabled}ds1-mode: -----------------------> {csu}csu-line-length: ----------------> {csu00}clock-source-eligible: ----------> {eligible}transmit-clock-source: ----------> {throughtiming}cell-scramble: ------------------> {true}coset-polynomial: ---------------> {true}protocol-emulation: -------------> {network}signal-type: --------------------> {loopstart}ds1-group-number: ---------------> {0}line-power: ---------------------> {disabled}

5 Display the ces-config profile for the configured T1/E1 CES unstructured circuit.

Note: The default number of UDP ports available for the source-port and destination-port in ces-config profile are 48000 - 48300. The number of available ports does not impact the CES behavior or provisioning.

zSH> get ces-config 1-8-2-0-ds1-1/ds0bundlevpi: --------------------------> {1}vci: --------------------------> {33}cas: --------------------------> {basic}partial-fill: -----------------> {0}buf-max-size: -----------------> {128}cell-loss-integration-period: -> {2500}ds0-bundle: ------------------->

Configuring Voice


{1+2+3+4+5+6+7+8+9+10+11+12+13+14+15+16+17+18+19+20+21+22+23+24}source-ip-address: ------------> {10.2.4.82}destination-ip-address: -------> {10.2.4.83}source-port: ------------------> {48001}destination-port: -------------> {48002}

Adding a structured T1/E1 CES over IP circuit with ds1esfcas signalingTo add a CES cross connection for a structured T1/E1 CES circuit with esfcas signaling, repeat these configuration steps for each endpoint of the circuit.

1 Specify cross connect command with the desired settings for each side of the CES circuit. This example command creates a structured T1 circuit using 6 DS0s starting at DS0 1 with ds1esfcas signaling. No line type is specified so the default esf line type from the DS1-profile is used. Traffic descriptor 1 is used. Using slot 7, port 1 on the CES card, the source IP address is 192.168.11.101. The destination IP address is 192.168.12.102. The source UDP port number is 48002. The destination UDP port number is 48202.

Note: Ensure the IP routes between the source and destination subnetworks have been configured and are available. UPD port numbers must be between 48000 and 48300.

zSH> ces add 1-7-1-0-ds1/atm ds0 1/6 struct ds1esfcas td 1 llc static 192.168.11.101 192.168.100.12 48003 48004zSH> ces add 1-7-2-0-ds1/atm ds0 1/6 struct ds1esfcas td 1 llc static 192.168.12.102 192.168.11.101 48004 48003

2 Change the admin status of the ports to up:

zSH> update if-translate 1-7-1-0/ds1Please provide the following: [q]uit.ifIndex: -----------> {200}:shelf: -------------> {1}:slot: --------------> {7}:port: --------------> {1}:subport: -----------> {0}:type: --------------> {ds1}:adminstatus: -------> {down}: upphysical-flag: -----> {true}:iftype-extension: --> {none}:ifName: ------------> {1-7-1-0}:redundancy-param1: -> {0}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

zSH> update if-translate 1-7-2-0/ds1Please provide the following: [q]uit.ifIndex: -----------> {200}:



shelf: -------------> {1}:slot: --------------> {7}:port: --------------> {1}:subport: -----------> {0}:type: --------------> {ds1}:adminstatus: -------> {down}: upphysical-flag: -----> {true}:iftype-extension: --> {none}:ifName: ------------> {1-7-1-0}:redundancy-param1: -> {0}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.zSH>

3 Display the configured cross connections.

zSH> cc show CESCONNECTION CC CONNECTION--------------------------------------------------------------------------- 1-1-1-0-aal5proxy/atm 0/35 Up 1 Up 1-7-1-0/ds1 1/6 Up 1-1-1-0-aal5proxy/atm 0/36 Up 2 Up 1-7-2-0/ds1 1/6 Up

4 Display the DS1 profile for the configured structured CES circuit over IP.

zSH> get ds1-profile 1-7-1-0/ds1line-type: ----------------------> {esf}line-code: ----------------------> {b8zs}send-code: ----------------------> {sendnocode}circuit-id: ---------------------> {ds1}loopback-config: ----------------> {noloop}signal-mode: --------------------> {robbedbit}fdl: ----------------------------> {fdlnone}dsx-line-length: ----------------> {dsx0}line-status_change-trap-enable: -> {enabled}channelization: -----------------> {disabled}ds1-mode: -----------------------> {csu}csu-line-length: ----------------> {csu00}clock-source-eligible: ----------> {eligible}transmit-clock-source: ----------> {throughtiming}cell-scramble: ------------------> {true}coset-polynomial: ---------------> {true}protocol-emulation: -------------> {network}signal-type: --------------------> {loopstart}ds1-group-number: ---------------> {0}line-power: ---------------------> {disabled}

5 Display the ces-config profile for the configured structured CES circuit over IP.

Note: The default number of UDP ports available for the source-port and destination-port in ces-config profile are 48000 - 48300. The number of available ports does not impact the CES behavior or provisioning.

Configuring Voice


zSH> get ces-config 1-7-1-0-ds1-1/ds0bundlevpi: --------------------------> {1}vci: --------------------------> {35}cas: --------------------------> {ds1esfcas}partial-fill: -----------------> {0}buf-max-size: -----------------> {128}cell-loss-integration-period: -> {2500}ds0-bundle: -------------------> {1+2+3+4+5+6}source-ip-address: ------------> {10.2.4.82}source-port: ------------------> {140}destination-ip-address: -------> {10.2.4.83}destination-port: -------------> {48004}

Adding unstructured T1 CES circuitsTo add a CES cross connection for an unstructured T1 CES circuit, repeat these configuration steps for each endpoint of the circuit.

1 Specify cross connect command with the desired settings. This example specifies an unstructured circuit (single channel). No signaling type or line type are specified. Unstructured single channels require basic signaling so the basic signaling type is used. The ds1unframed line type from the DS1-profile is used.

zSH> cc add uplink2/atm 0/53 1-12-3-0/ds1 vc 1/33 ds0 1/24 unstr td 1


zSH> cc show CES ATM VCL CC ATM VCL--------------------------------------------------------------------------

uplink2/atm 0/53 Up 1 Up 1-12-3-0-ds1/atm 1/33 Up

3 Display the DS1 profile for the configured T1 CES unstructured circuit.

zSH> get ds1-profile 1-12-3-0/ds1line-type: ----------------------> {ds1unframed}line-code: ----------------------> {b8zs}send-code: ----------------------> {sendnocode}circuit-id: ---------------------> {ds1}loopback-config: ----------------> {noloop}signal-mode: --------------------> {none}fdl: ----------------------------> {fdlnone}dsx-line-length: ----------------> {dsx0}line-status_change-trap-enable: -> {enabled}channelization: -----------------> {disabled}ds1-mode: -----------------------> {csu}csu-line-length: ----------------> {csu00}clock-source-eligible: ----------> {eligible}transmit-clock-source: ----------> {throughtiming}cell-scramble: ------------------> {true}coset-polynomial: ---------------> {true}protocol-emulation: -------------> {network}signal-type: --------------------> {loopstart}



ds1-group-number: ---------------> {0}line-power: ---------------------> {disabled}

4 Display the ces-config profile for the configured T1 CES unstructured circuit.

zSH> get ces-config 1-12-3-0-ds1-1/ds0bundlevpi: --------------------------> {1}vci: --------------------------> {33}cas: --------------------------> {basic}partial-fill: -----------------> {0}buf-max-size: -----------------> {128}cell-loss-integration-period: -> {2500}ds0-bundle: ------------------->{1+2+3+4+5+6+7+8+9+10+11+12+13+14+15+16+17+18+19+20+21+22+23+24}

Adding a structured T1 CES circuit with ds1esfcas signalingTo add a CES cross connection for a structured T1 CES circuit with esfcas signaling, repeat these configuration steps for each endpoint of the circuit.

1 Specify cross connect command with the desired settings. This example command creates a structured circuit using 6 DS0s starting at DS0 1 with ds1esfcas signaling. No line type is specified so the esf line type from the DS1-profile is used.

zSH> cc add uplink2/atm 0/54 1-12-4-0/ds1 vc 1/34 ds0 1/6 str ds1esfcas td 1


zSH> cc show CESATM VCL CC ATM VCL--------------------------------------------------------------------------

uplink2/atm 0/53 Up 1 Up 1-12-3-0-ds1/atm 1/33 Up uplink2/atm 0/54 Up 3 Up 1-12-4-0-ds1/atm 1/34 Up

3 Display the DS1 profile for the configured structured CES circuit.

zSH> get ds1-profile 1-12-4-0/ds1line-type: ----------------------> {esf}line-code: ----------------------> {b8zs}send-code: ----------------------> {sendnocode}circuit-id: ---------------------> {ds1}loopback-config: ----------------> {noloop}signal-mode: --------------------> {robbedbit}fdl: ----------------------------> {fdlnone}dsx-line-length: ----------------> {dsx0}line-status_change-trap-enable: -> {enabled}channelization: -----------------> {disabled}ds1-mode: -----------------------> {csu}csu-line-length: ----------------> {csu00}clock-source-eligible: ----------> {eligible}transmit-clock-source: ----------> {throughtiming}cell-scramble: ------------------> {true}

Configuring Voice


coset-polynomial: ---------------> {true}protocol-emulation: -------------> {network}signal-type: --------------------> {loopstart}ds1-group-number: ---------------> {0}line-power: ---------------------> {disabled}

4 Display the ces-config profile for the configured CES circuit.

zSH> get ces-config 1-12-4-0-ds1-1/ds0bundlevpi: --------------------------> {1}vci: --------------------------> {34}cas: --------------------------> {ds1esfcas}partial-fill: -----------------> {0}buf-max-size: -----------------> {128}cell-loss-integration-period: -> {2500}ds0-bundle: -------------------> {1+2+3+4+5+6}

Adding a second DS0 bundle to a structured T1 CES circuit with ds1esfcas signalingTo add a second DS0 bundle to a CES cross connection for a structured T1 CES circuit with ds1esfcas signaling, repeat these configuration steps for each endpoint of the circuit.

1 Specify cross connect command with the desired settings. This example command specifies 6 DS0s starting at DS0 7 in a structured circuit using ds1esfcas signaling type. The line type for secondary DS0 bundles must match the line type of the first bundle or be left unspecified so the esf line type from the DS1-profile is used.

zSH> cc add uplink2/atm 0/55 1-12-5-0/ds1 vc 1/35 ds0 7/6 str ds1esfcas td 1



uplink2/atm 0/53 Up 1 Up 1-12-3-0-ds1/atm 1/33 Up uplink2/atm 0/54 Up 2 Up 1-12-4-0-ds1/atm 1/34 Upuplink2/atm 0/55 Up 3 Up 1-12-5-0-ds1/atm 1/35 Up


zSH> get ds1-profile 1-12-5-0/ds1line-type: ----------------------> {esf}line-code: ----------------------> {b8zs}send-code: ----------------------> {sendnocode}circuit-id: ---------------------> {ds1}loopback-config: ----------------> {noloop}signal-mode: --------------------> {robbedbit}fdl: ----------------------------> {fdlnone}dsx-line-length: ----------------> {dsx0}line-status_change-trap-enable: -> {enabled}channelization: -----------------> {disabled}



ds1-mode: -----------------------> {csu}csu-line-length: ----------------> {csu00}clock-source-eligible: ----------> {eligible}transmit-clock-source: ----------> {throughtiming}cell-scramble: ------------------> {true}coset-polynomial: ---------------> {true}protocol-emulation: -------------> {network}signal-type: --------------------> {loopstart}ds1-group-number: ---------------> {0}line-power: ---------------------> {disabled}


zSH> get ces-config 1-12-5-0-ds1-2/ds0bundlevpi: --------------------------> {1}vci: --------------------------> {35}cas: --------------------------> {ds1esfcas}partial-fill: -----------------> {0}buf-max-size: -----------------> {128}cell-loss-integration-period: -> {2500}ds0-bundle: -------------------> {7+8+9+10+11+12}

Adding unstructured E1 CES circuitsTo add a CES cross connection for an unstructured E1 CES circuit, repeat these configuration steps for each endpoint of the circuit.

1 Specify cross connect command with the desired settings. This command specifies an unstructured channel. Unstructured channels require the basis signaling type. No line type is specified so the e1unframed line type from the DS1-profile is used.

zSH> cc add uplink1/atm 0/61 1-6-1-0/ds1 vc 1/32 ds0 0/32 unstr td 1





zSH> get ds1-profile 1-6-1-0/ds1line-type: ----------------------> {e1unframed}line-code: ----------------------> {hdb3}send-code: ----------------------> {sendnocode}circuit-id: ---------------------> {e1}loopback-config: ----------------> {noloop}signal-mode: --------------------> {none}fdl: ----------------------------> {fdlnone}dsx-line-length: ----------------> {dsx0}line-status_change-trap-enable: -> {enabled}channelization: -----------------> {disabled}ds1-mode: -----------------------> {other}

Configuring Voice


csu-line-length: ----------------> {csu00}clock-source-eligible: ----------> {eligible}transmit-clock-source: ----------> {throughtiming}cell-scramble: ------------------> {true}coset-polynomial: ---------------> {true}protocol-emulation: -------------> {network}signal-type: --------------------> {loopstart}ds1-group-number: ---------------> {0}line-power: ---------------------> {disabled}


zSH> get ces-config 1-6-1-0-ds1-1/ds0bundlevpi: --------------------------> {1}vci: --------------------------> {32}cas: --------------------------> {basic}partial-fill: -----------------> {0}buf-max-size: -----------------> {128}cell-loss-integration-period: -> {2500}ds0-bundle: ------------------->{0+1+2+3+4+5+6+7+8+9+10+11+12+13+14+15+16+17+18+19+20+21+22+23+24+25+26+27+28+29+30+31}

Adding a structured E1 CES circuit with e1cas signalingTo add a CES cross connection for a structured E1 CES circuit with e1cas signaling, repeat these configuration steps for each endpoint of the circuit.

1 Specify cross connect command with the desired settings. This example specifies 6 DS0s starting at DS0 1 in a structured circuit with e1case signaling type e1cas. The line type is unspecified so the e1 line type from the DS1-profile is used.

zSH> cc add uplink1/atm 0/62 1-6-2-0/ds1 vc 1/33 ds0 1/6 str e1cas td 1





zSH> get ds1-profile 1-6-2-0/ds1line-type: ----------------------> {e1}line-code: ----------------------> {hdb3}send-code: ----------------------> {sendnocode}circuit-id: ---------------------> {e1}loopback-config: ----------------> {noloop}signal-mode: --------------------> {bitoriented}fdl: ----------------------------> {fdlnone}dsx-line-length: ----------------> {dsx0}line-status_change-trap-enable: -> {enabled}channelization: -----------------> {disabled}



ds1-mode: -----------------------> {other}csu-line-length: ----------------> {csu00}clock-source-eligible: ----------> {eligible}transmit-clock-source: ----------> {throughtiming}cell-scramble: ------------------> {true}coset-polynomial: ---------------> {true}protocol-emulation: -------------> {network}signal-type: --------------------> {loopstart}ds1-group-number: ---------------> {0}line-power: ---------------------> {disabled}


zSH> get ces-config 1-6-2-0-ds1-1/ds0bundlevpi: --------------------------> {1}vci: --------------------------> {33}cas: --------------------------> {e1cas}partial-fill: -----------------> {0}buf-max-size: -----------------> {128}cell-loss-integration-period: -> {2500}ds0-bundle: -------------------> {1+2+3+4+5+6}

Adding a second cross connect to a structured E1 CES circuit with e1cas signalingTo add a second CES cross connection for a structured E1 CES circuit with e1cas signaling, repeat these configuration steps for each endpoint of the circuit.

1 Specify cross connect command with the desired settings. This example specifies 6 DS0s starting at DS0 7 in a structured circuit using e1cas signaling type. The line type for secondary DS0 bundles must match the line type of the first bundle or be left unspecified so the e1 line type from the DS1-profile is used.

zSH> cc add uplink2/atm 0/63 1-6-3-0/ds1 vc 1/34 ds0 7/6 str e1cas td 1



uplink2/atm 0/61 Up 1 Up 1-6-1-0-ds1/atm 1/32 Up uplink2/atm 0/62 Up 2 Up 1-6-2-0-ds1/atm 1/33 Upuplink2/atm 0/63 Up 3 Up 1-6-3-0-ds1/atm 1/34 Up


zSH> get ds1-profile 1-6-3-0/ds1line-type: ----------------------> {e1}line-code: ----------------------> {hdb3}send-code: ----------------------> {sendnocode}circuit-id: ---------------------> {e1}loopback-config: ----------------> {noloop}

Configuring Voice


signal-mode: --------------------> {bitoriented}fdl: ----------------------------> {fdlnone}dsx-line-length: ----------------> {dsx0}line-status_change-trap-enable: -> {enabled}channelization: -----------------> {disabled}ds1-mode: -----------------------> {other}csu-line-length: ----------------> {csu00}clock-source-eligible: ----------> {eligible}transmit-clock-source: ----------> {throughtiming}cell-scramble: ------------------> {true}coset-polynomial: ---------------> {true}protocol-emulation: -------------> {network}signal-type: --------------------> {loopstart}ds1-group-number: ---------------> {0}line-power: ---------------------> {disabled}


zSH> get ces-config 1-6-3-0-ds1-2/ds0bundlevpi: --------------------------> {1}vci: --------------------------> {34}cas: --------------------------> {e1cas}partial-fill: -----------------> {0}buf-max-size: -----------------> {128}cell-loss-integration-period: -> {2500}ds0-bundle: -------------------> {7+8+9+10+11+12}

Deleting CES over IP circuitsTo delete a configured CES over IP circuit, repeat this command on each circuit endpoint.

This command deletes only one endpoint of a CES over IP circuit. Repeat this command on each endpoint to remove the entire circuit.

ZSH>ces delete 1-7-1-0-ds1/atm ds0 1/6 static 192.168.100.101

Deleting cross connections and CES over ATM circuitsTo delete a configured CES over ATM cross connection, specify the delete cross connect command.

This command uses either both sides of the cross connect or the cross connect number to remove the entire cross connection. Repeat this command on each circuit endpoint.

zSH> cc delete uplink2/atm 0/61 1-6-1-0-ds1/atm 1/32 Delete complete

zSH> cc delete cc 1Delete complete

Additional voice features


Additional voice featuresThis section describes additional voice settings you might need to configure, depending on your network.

Changing the jitter bufferThe type and size of the jitter buffer in the MALC can be configured. The jitter buffer accommodates the AAL2 packets received, so that the inter-arrival jitter of the packets received does not degrade the voice quality. Without a jitter buffer, some inter-arrival jitter changes would be late, which would have the same effect as lost packets. The jitter buffer also reorders the out-of-order packets received.

Configuring Voice


Modify the following parameters in the voice-dsp-default-profile to change jitter buffer:

Note: Any changes made to jitter buffer size and jitter buffer type take effect in the next call.

To change the type and size of the jitter buffer:

zSH> update voice-dsp-default-profile 0Please provide the following: [q]uit.redundancy-over-subscription-type: -> {high}:jitter-buffer-type: ----------------> {dynamic}: staticjitter-buffer-size:----------------> {10}: 22inter-arriv-jit-threshold: ---------> {80}:pkts-lost-threshold: ---------------> {600}:echo-cancellation-type: ------------> {g165echotl16}:silence-supression-type: -----------> {silsupoff}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.


jitter-buffer-type There are two types of jitter algorithms: static and dynamic. Values: static A static jitter buffer does not change to compensate for inter-arrival jitter changes. Default jitter buffer type is static for VoATM applications.dynamic Allows the jitter buffer to grow and shrink as inter-arrival jitter changes. Default jitter buffer type is dynamic for VoIP applications.

jitter-buffer-size Specifies the size of the jitter buffer. Values: 1 to 160 Note that changes to the jitter buffer are based on 5 ms frame sizes. For example:1 to 5 = 5 ms6 to 10 = 10 ms11 to 15 = 15 ms16 to 20 = 20 ms...146 to 150 = 150 ms151 to 155 = 155 ms156 to 160 = 160 msDefault: 10



Setting country-specific dialing features for VoIPCertain features on the POTS card are designed for use in telephone systems located outside of North America. These features are available on the MALC-POTS-TDM/PKT-48, MALC-POTS-GLB-TDM/PKT, and MALC-ADSL+POTS-PKT cards. For more information about this card, contact your Zhone Technologies sales representative.

Caution: Changing the countryregion setting for the Global POTS card requires a system reboot.

When you specify another country, such as South Africa, in the system profile, you have the option of modifying the following dialing parameters in the voice-system profile:

– hookflash-min-timer

– hookflash-max-timer

– pulse-inter-digit-timer

– min-make-pulse-width

– min-break-pulse-width

– max-break-pulse-width

These options are read only after they have been set.

To specify another country, such as South Africa, in the system profile:

zSH> update system 0Please provide the following: [q]uit.syscontact: -----------> {Zhone Global Services and Support 7001 Oakport Street Oakland Ca. (877) Zhone20 (946-6320) Fax (510)777-7113 [email protected]}:sysname: --------------> {malc-201}:syslocation: ----------> {Oakland}:enableauthtraps: ------> {disabled}:setserialno: ----------> {0}:zmsexists: ------------> {true}:zmsconnectionstatus: --> {inactive}:zmsipaddress: ---------> {192.168.89.12}:configsyncexists: -----> {false}:configsyncoverflow: ---> {false}:configsyncpriority: ---> {high}:configsyncaction: -----> {noaction}:configsyncfilename: ---> {192.168.175.201_4_1115314335218}:configsyncstatus: -----> {synccomplete}:configsyncuser: -------> {zmsftp}:configsyncpasswd: -----> {** private **}: ** read-only **numshelves: -----------> {1}:shelvesarray: ---------> {}:numcards: -------------> {3}:ipaddress: ------------> {192.168.175.201}:alternateipaddress: ---> {0.0.0.0}:countryregion: --------> {us}: southafrica

Configuring Voice


primaryclocksource: ---> {0/0/0/0/0}:ringsource: -----------> {internalringsourcelabel}:revertiveclocksource: -> {true}:voicebandwidthcheck: --> {false}:....................countryregion changed to southafricaLoad country's pulse dialing parameters in voice-system profile ? [y]es or [n]o: yvoice-system profile updated with pulse dialing parameters for southafrica sysMinBreakPulseWidth... 35 ms, sysMaxBreakPulseWidth... 75 ms sysMinMakePulseWidth.... 100 ms, sysPulseInterDigitTimer. 25 ms minHookFlash............ 80 ms, maxHookFlash............ 230 mssouthafrica uses a different PCM encoding type (ALAW) from us (MULAW). Please reboot the system for this change to take effect. Record updated.

Setting ring cadence and call progress parameters

The MALC enables the ring cadence and other call progress parameters to be set for customized signal timing for VoIP MGCP and SIP calls.

By default, ring cadences are set to standard United States settings. For Japan, other ring cadences are used that are not user-configurable. For other country-specific ring cadences, manually configure the ring cadences R0-R7 based on the country’s requirements.

Table 10 lists the parameters that can be set. The following types of alert signal are used for on-hook signaling to wake up the caller ID device:

• During Ringing

The first ring is the alert signal, meaning the caller ID device is woken up to receive CLID data, when MALC provides the first ring.

• Prior Ring with Dual Tone (DT) Wake Up (WU)

A particular dual tone (2130Hz+2750Hz for 100ms) wakes up the caller ID CPE device for caller ID transmission. The tone and the caller ID signal are sent to prior to ringing.

• Prior Ring with Ring Pulse (RP) Wake Up (WU)

A short ring pulse (between 200ms and 300ms) wakes up the caller ID CPE device. Then, the caller ID signal transmission follows.

• Prior Ring with Line Reversal (LR) Wake Up (WU)

A line reversal (polarity change in DC voltage of the line, wakes up the caller ID device. Then, the caller ID signal transmission follows.

• No Ring with Dual Tone (DT) Wake Up (WU)

A particular dual tone (2130Hz+2750Hz for 100ms) wakes up the caller ID CPE device for caller ID transmission. Not associated with ringing.

• No Ring with Ring Pules (RP) Wake Up (WU)



A short ring pulse (between 200ms and 300ms) wakes up the caller ID CPE device. Not associated with ringing.

• No Ring with Line Reversal (LR) Wake Up (WU)

A line reversal (polarity change in DC voltage of the line, wakes up the caller ID device. Not associated with ringing.

Table 10: Ring cadence and call progress parameters


callerid-dig-protocol Identifies the subscriber line protocol used for signaling on-hook caller id information.Different countries define different caller id signaling protocols to support caller identification. Supported protocols are Frequency Shift Keying (FSK) and Dual-Tone Multi-Frequency (DTMF).

r0-ring-cadence to r7-ring-cadence

Customized ring cadences. Ring cadence is required for the L line package.

ring cadence Normal ring cadence

ring-splash-cadence

power-ring frequency the frequency at which the sinusoidal voltage must travel down the twisted pair to make terminal equipment ring. Different countries define different electrical characteristics to make terminal equipment ring. The f##Hz setting corresponds to a power ring frequency of ## Hertz. For example, the f25Hz setting corresponds to a power ring frequency of 25 Hertz. The f33Point33Hz setting corresponds to a power ring frequency of 33.33 Hertz.

clid-mode The method of caller ID for on-hook caller ID. The Frequency Shift Keying (FSK) containing the Caller ID information is sent between the first and second ring pattern. For the dtas, rpas, and lr methods, the FSK containing the Caller ID information is sent before the first ring pattern. For the dtas method, the FSK is sent after the Dual Tone Alert Signal. For the rpas method, the FSK is sent after a Ring Pulse. For the lr method, the Line Reversal occurs first, then the Dual Tone Alert Signal, and finally the FSK is sent.

delay-before-clid-after-ring

The delay between the first ringing pattern and the start of the transmission of the FSK containing the Caller ID information. It is only used when CIDMode is duringRingingETS. The default value is 550 ms.

delay-before-clid-after-dtas

The delay between the end of the Dual Tone Alert Signal (DT-AS) and the start of the transmission of the FSK containing the Caller ID information. It is only used when CIDMode is dtas or lr. The default value is 50 ms.

Configuring Voice


Customizing ring cadence and changing call progress parameters

To customize ring cadence or change call progress parameters for SIP and MGCP VoIP calls. For MGCP systems, The MGCP switch determines which ring cadence to use. For SIP systems, normal ring cadence or ring splash are used. For SIP PLAR systems, the class 5 switch determines the ring cadences, directly for GR303 and indirectly for V5.2 calls.

zSH> update voice-call-progress-config 0Please provide the following: [q]uit.callerid-sig-protocol: -----------> {fsk}: dtmfr0-ring-cadence: -----------------> {r-2000:on-4000:off}:r1-ring-cadence: -----------------> {r-2000:on-4000:off}:r2-ring-cadence: -----------------> {r-800:on-400:off-800:on-4000:off}:r3-ring-cadence: -----------------> {r-400:on-200:off-400:on-200:off-800:on-4000:off}:r4-ring-cadence: -----------------> {r-300:on-200:off-1000:on-200:off-300:on-4000:off}:r5-ring-cadence: -----------------> {nr-500:on}:r6-ring-cadence: -----------------> {r-2000:on-4000:off}:r7-ring-cadence: -----------------> {r-2000:on-4000:off}:ring-cadence: --------------------> {r-2000:on-4000:off}:ring-splash-cadence: -------------> {nr-500:on}:

delay-before-clid-after-rpas

The delay between the end of the Ring Pulse Alert Signal (RP-AS) and the start of the transmission of the FSK containing the Caller ID information. It is only used when CIDMode is rpas. The default value is 650 ms.

delay-after-clid-before-ring

The delay between the end of the complete transmission of the FSK containing the Caller ID information and the start of the first ring pattern. It is only used when CIDMode is dtas, rpas or lr. The default value is 250 ms.

delay-before-dtas-after-lr

The delay between the end of the Line Reversal and the start of the Dual Tone Alert Signal (DT-AS). It is only used when CIDMode is lr. The default value is 250 ms.

delay-before-vmwi-after-dtas

The delay between the end of the Dual Tone Alert Signal (DT-AS) and the start of the transmission of the FSK containing the VMWI information. It is only used when VmwiMode is dtas or lr. The default is 50 ms.

delay-before-vmwi-after-rpas

The delay between the end of the Ring Pulse Alert Signal (RP-AS) and the start of the transmission of the FSK containing the VMWI information. It is only used when VmwiMode is rpas. The default is 650 ms.

vmwi-delay-before-dtas-after-lr

The delay between the end of the Line Reversal and the start of the Dual Tone Alert Signal (DT-AS) for VMWI information. It is only used when VmwiMode is lr. The default is 250 ms.

Table 10: Ring cadence and call progress parameters




power-ring-frequency: ------------> {f20hz}:clid-mode: -----------------------> {duringringingets}:delay-before-clid-after-ring: ----> {550}:delay-before-clid-after-dtas: ----> {50}:delay-before-clid-after-rpas: ----> {650}:delay-after-clid-before-ring: ----> {250}:delay-before-dtas-after-lr: ------> {250}:vmwi-mode: -----------------------> {dtasets}:delay-before-vmwi-after-dtas: ----> {50}:delay-before-Vmwi-after-rpas: ----> {650}:vmwi-delay-before-dtas-after-lr: -> {250}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Call progress tones for Canada

The MALC now includes support for call progress tones and ring frequencies for Canada as specified in ITU E.180 Supp.2. Common call progress tones are dial tone, busy tone, call waiting tone, ring tone, and special information tone.

To change the call progress tones to Canada:

zSH> update system 0Please provide the following: [q]uit.syscontact: -----------> {}:sysname: --------------> {MALC}:syslocation: ----------> {Oakland}:enableauthtraps: ------> {disabled}:setserialno: ----------> {0}:zmsexists: ------------> {false}:zmsconnectionstatus: --> {inactive}:zmsipaddress: ---------> {172.24.84.80}:configsyncexists: -----> {false}:configsyncoverflow: ---> {false}:configsyncpriority: ---> {high}:configsyncaction: -----> {noaction}:configsyncfilename: ---> {172.24.200.191_4_1129917707613}:configsyncstatus: -----> {synccomplete}:configsyncuser: -------> {cfgsync}:configsyncpasswd: -----> {** private **}: ** read-only **numshelves: -----------> {1}:shelvesarray: ---------> {}:numcards: -------------> {3}:ipaddress: ------------> {172.24.200.191}:alternateipaddress: ---> {0.0.0.0}:countryregion: --------> {us}: canadaprimaryclocksource: ---> {0/0/0/0/0}:ringsource: -----------> {internalringsourcelabel}:revertiveclocksource: -> {true}:voicebandwidthcheck: --> {false}:

Configuring Voice


....................Save changes? [s]ave, [c]hange or [q]uit: sNew record saved.

Emergency StandAlone (ESA) SIP and TDM support For VoIP SIP or SIP PLAR and POTS to GR303 voice connections, the MALC provides emergency calling services during network or equipment failures that cause a loss of connection to the configured TDM switch or SIP server.

For VoIP SIP or SIP PLAR connections, the ESA feature enables numbers configured within ESA dialplans to communicate with any residences or businesses specified as the destination of the dialplans in an ESA cluster of MALC devices. For POTS to GR303 connections, the ESA feature enables numbers configured within the same dialplan using the same MALC device to communicate with any residences or businesses sharing that dialplan. Incoming calls from outside the ESA group and outgoing calls to numbers outside the SIP dialplan receive a fast-busy signal.

When ESA is activated, call features, such as call waiting, are not supported.

Note: After a loss of connection to the SIP server, there may be a delay up to 5 minutes before ESA notification is received and ESA features are accessible.

There maybe a similar delay before resuming normal calling after the outage is restored.

Figure 26 illustrates ESA support for VoIP SIP or SIP PLAR connections.

Emergency StandAlone (ESA) SIP and TDM support


Figure 26: ESA for VoIP SIP or SIP PLAR connections

Figure 27 illustrates ESA support for POTS to GR303 or V5.2 connections.

IP PacketTransport

Configuring Voice


Figure 27: ESA for POTS to GR303 connections

Configuring VoIP ESA clusters

To configure ESA clusters for VoIP connections, configure a VoIP server and create a dialplan for the VOIP server. Also, create an ESA dialplan for each of the MALC devices participating in the ESA cluster. For each ESA dialplan, enter the IP addresses of the desired MALC in the sip-ip-address field and change the dialplan-type to esa. Also, if desired, change the destination-name to the target MALC.

When in ESA mode, the MALC sequentially checks the configured dialplans for a matching string starting with the lowest number to the highest number dialplan. If a match is found, the call connection process is initiated immediately. If a match is not found, the next sequential dialplan is checked until all configured dialplans have been checked. Calls with unmatched strings are then terminated. It is recommended to configure lower number dialplans for more frequently called nodes and higher number dialplans for less frequently called nodes.

ESA



This example creates VoIP server 1/1 and creates SIP dialplan O for the VoIP server. SIP dialplan 1 is used on MALC 1 with IP address 172.24.94.219; SIP dialplan 2 is used on MALC 2 with IP address 172.24.94.222. SIP dialplan 3 is used on MALC 3 with IP address 172.24.94.223.It also sets the match-string to ‘x’ to accept all numbers, the number of digits to 7, and the dialplan type to ESA. This dialplan enables ESA calls to connect to other subscribers within the same MALC. Additional dialplans are created for each of the neighboring MALC nodes.

Note: A SIP dialplan of type normal should be configured and connected to a VoIP SIP server for non-ESA calls.

zSH> new voip-server-entry 1/1Please provide the following: [q]uit.zhoneVoipServerAddrType: ----------> {ipv4}:zhoneVoipServerAddr: --------------> {}: 172.16.60.1zhoneVoipServerUdpPortNumber: -----> {5060}: zhoneVoipServerId: ----------------> {generic}: protocol: -------------------------> {sip}: sendCallProceedingTone: -----------> {false}:rtcpEnabled: ----------------------> {false}:rtcpPacketInterval: ---------------> {5000}:interdigitTimeOut: ----------------> {10}:ipTos: ----------------------------> {0}:systemDomainName: -----------------> {}:expires-invite-value: -------------> {3600}expires-register-value: -----------> {3600}expires-header-method: ------------> {register}session-expiration: ---------------> {0}session-min-SE: -------------------> {-606348325}session-caller-request-timer: -----> {no}session-callee-request-timer: -----> {no}session-caller-specify-refresher: -> {omit}session-callee-specify-refresher: -> {uac}omitsession-callee-specify-refresher:-> (uac)dtmf-mode:------------------------> (inband)....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

zSH> new sip-dialplan 0match-string: ----------------> {x}sip-ip-address: --------------> {0} 172.16.60.1destination-name: ------------> {}VoIP Servernumber-of-digits: ------------> {0}7prefix-strip: ----------------> {0}prefix-add: ------------------> {}dialplan-type: ---------------> {normal} voip-server-entry-index: -----> {0} 1override-interdigit-timeout: -> {0}

zSH> new sip-dialplan 1match-string: ----------------> {x}

Configuring Voice


sip-ip-address: --------------> {0} 172.24.94.219destination-name: ------------> {}MALC#1number-of-digits: ------------> {0}7prefix-strip: ----------------> {0}prefix-add: ------------------> {}dialplan-type: ---------------> {normal}esa voip-server-entry-index: -----> {0}override-interdigit-timeout: -> {0}

Create additional SIP dialplans for so ESA calls can connect to subscribers on other MALC devices. This dialplan allows ESA calls to connect to subscribers on MALC 2.

zSH> new sip-dialplan 2match-string: ----------------> {x}sip-ip-address: --------------> {0} 172.24.94.222destination-name: ------------> {} MALC#2number-of-digits: ------------> {0}7prefix-strip: ----------------> {0}prefix-add: ------------------> {}dialplan-type: ---------------> {normal}esa voip-server-entry-index: -----> {0}override-interdigit-timeout: -> {0}

This dialplan allows ESA calls to connect to subscribers on MALC 3.

zSH> new sip-dialplan 3match-string: ----------------> {x}sip-ip-address: --------------> {0} 172.24.94.223destination-name: ------------> {} MALC#3number-of-digits: ------------> {0}7prefix-strip: ----------------> {0}prefix-add: ------------------> {}dialplan-type: ---------------> {normal}esa voip-server-entry-index: -----> {0}override-interdigit-timeout: -> {0}

Configuring ESA for 911 calls

To configure ESA for VoIP connections for 911 calls, create an ESA dialplan with a match-string of 911 and the IP address of the MALC shelf in the sip-ip-address field. Also, change the number of digits and prefix-strip to 3. The prefix-strip setting deletes the dialed 911 numbers. Enter the desired phone number to be called in the prefix-add field. This number must be a valid voicefxs line in the same MALC shelf. Change the dial-plan type to esa.

This example creates a SIP dialplan called 911on the MALC with IP address 172.24.94.219. It replaces the dialed 911 number with the phone number 7281001 and changes the dialplan type to ESA.

zSH> new sip-dialplan 911match-string: ----------------> {}911sip-ip-address: --------------> {0} 172.24.94.219



destination-name: ------------> {}number-of-digits: ------------> {0}3prefix-strip: ----------------> {0}3prefix-add: ------------------> {}7280004dialplan-type: ---------------> {normal}esa voip-server-entry-index: -----> {0}override-interdigit-timeout: -> {0}

Verifying ESA

To verify whether ESA support is in-use, enter the voice status command. This command lists the voice port, destination, call state, and ESA state along with other status information.

zSH> voice statusport term state destination call state hook ring ESA---- ---------- ----------- ---------- ---- ---- ---1-6-1-0/voicefxs UP VoIP:69:VoIP EndPtIdx-152 No call ON NoRing ON1-6-2-0/voicefxs UP VoIP:69:VoIP EndPtIdx-154 No call ON NoRing ON1-6-3-0/voicefxs UP GR303:IG-one:CRV-3 No call ON NoRing N/A

Configuring TDM ESA

Voice add command for TDM ESA

The voice add command allows the configuration of a Emergency Stand Alone (ESA) endpoint for POTS to GR303 voice connections.

For these POTS voice connections, the MALC enables a VoIP endpoint for emergency calling services during network or equipment failures that cause a loss of connection to a configured GR-303 interface.

The ESA feature enables numbers configured within the same ESA dialplan using the same MALC shelf to communicate with any residences or businesses sharing that dialplan. Incoming calls from outside the ESA group and outgoing calls to numbers outside the SIP dialplan receive a fast-busy signal.

Syntax Voice add pots subscriberinterface gr303|v52 remoteinterface voip [ESAinterface]

Example 1

zSH> voice add pots 1-4-4-0/voicefxs gr303 1/4 esa ethernet1/ip dn 7821004Created subscriber-voice 1/378/5Created subscriber-voice-pots 88Created gr303-ig-crv 1/4Created subscriber-voice-gr303 89Created subscriber-voice 1/3/15Created subscriber-voice-voip 90zSH>

zSH> voice show

Configuring Voice


Subscriber end-point Remote end-point Voice Prof Id STA----------------------------- ----------------------------- -------------- ---1-4-4-0/voicefxs GR303 one/4 1/378/5 ENA1-4-4-0/voicefxs ethernet1/ip DN 7281004 1 1/3/15 ENATotal number of voice connections : 2

zSH> voice delete pots 1-4-4-0/voicefxs Deleted gr303-ig-crv 1/4Deleted subscriber-voice 1/378/5 and its subscriber-voice-xxx profilesDeleted subscriber-voice 1/3/15 and its subscriber-voice-xxx profiles

zSH> voice showTotal number of voice connections: 0zSH>

Example 2

zSH> voice show esa ethernet1/ip DN 7281005INPUT:

profile type: subscriber-voice-voiplogical address: LGId: 69 EndPtIdx: 103profile address: 103subscriber-voice INFO: voice-connection-type = VoIPTOPOTSvoice-endpoint1-addr-index = 103voice-endpoint2-addr-index = 101voice-admin-status = Enabledsubscriber-voice addr: subId: 1 LGId: 3 subVoiceId: 19

MATCHING: profile type: subscriber-voice-potslogical address: LGId: 195 PotsNumber: 1profile address: 101

Notes The voice show and voice delete commands display and remove the ESA endpoint along with the primary voice connections.

T.38 fax


T.38 faxT.38 fax service enables fax messages to be transported across VoIP networks between G3 fax terminals. When configured for SIP or SIP PLAR and T.38, MALC provides a T.38 fax relay service between two devices configured for the same VoIP protocol. If one side of the T.38 connection is not configured for T.38 support, the fax call reverts to g.711 pass through when this option is configured. Otherwise, the fax may not go through.

By default, T.38 fax service is disabled.

This section contains the following procedures;

• T.38 fax using SIP

• T.38 fax using SIP PLAR to PSTN

• T.38 using SIP PLAR to POTS fax

Note: The T.38 fax service can also be configured on VoIP connections using the voicegateway card.

T.38 fax using SIP

The MALC supports T.38 fax streams across a VoIP network. The MALC can be connected to another MALC or a VoIP IAD device.

Figure 28 illustrates the T.38 fax streams using SIP between MALC devices, and between a MALC and aVoIP IAD configured for T.38.

Figure 28: SIP T.38 between MALC devices or VoIP IAD

Configuring T.38 fax serviceThe MALC supports T.38 service options for either t38udptl or t38none. The t38udptl options enables T.38 service using UDP IP packets. The t38none option disables the service.

To enable T.38 fax service for SIP connections:

FaxMALC T.38 Fax Stream using

SIP

POTS VoIP

FaxMALC

Fax MALC T.38 Fax Stream usingSIP

POTS VoIP

VoIP IADFax

POTS

POTS

Configuring Voice


Note: The t38rtp option is currently not supported.

Specify the T.38 option when configuring a voice call with the voice add command for the POTS and SIP connections. The subscriber-voice-voip profile settings are updated based on the command options.

voice add pots 1-voice add pots 1-5-3-0/voicefxs voip 1/6 ethernet1/ip dn 5105330203 name 5105330203 codec g729a t38fax t38udptl reg 1


The subscriber-voice-voip profile can also be updated to enable the T.38 fax service. After updating the subscriber-voice-voip profile, the voice subscriber must be disabled and then re-enabled for the changes to be effective.

zSH> list subscriber-voicesubscriber-voice 1/2/26subscriber-voice 1/2/272 entries found.

zSH> update subscriber-voice 1/2/26Please provide the following: [q]uit.voice-connection-type: --------> {voiptopots}: ** read-only **voice-endpoint1-addr-index: ---> {52}: ** read-only **voice-endpoint2-addr-index: ---> {51}: ** read-only **voice-connection-description: -> {}:voice-admin-status: -----------> {enabled}: disabledhuntgroup: --------------------> {false}: ** read-only **features: ---------------------> {hookflash+onhooksignaling+callwait}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

zSH> update subscriber-voice-voip 52 (the endpoint1-addr-index in subscriber-voice profile.)Please provide the following: [q]uit.voip-username: -------------> {9990002}:directory-number: ----------> {9990002}:ip-interface-index: --------> {ethernet2-2/ip}:preferred-codec: -----------> {g729a}:g711-fallback: -------------> {true}:frames-per-packet: ---------> {4}:g726-byte-order: -----------> {bigendian}:voip-password: -------------> {}:voip-plar: -----------------> {false}:** read-only **voip-plar-dest-ipaddrtype: -> {ipv4}:voip-plar-dest-ipaddr: -----> {}:voip-plar-udp-port: --------> {5060}:registration-server: -------> {0}:

T.38 fax


t38-fax: -------------------> {t38none}:t38udptl....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

zSH> update subscriber-voice 1/2/26Please provide the following: [q]uit.voice-connection-type: --------> {voiptopots}: ** read-only **voice-endpoint1-addr-index: ---> {52}: ** read-only **voice-endpoint2-addr-index: ---> {51}: ** read-only **voice-connection-description: -> {}:voice-admin-status: -----------> {disabled}: enabledhuntgroup: --------------------> {false}: ** read-only **features: ---------------------> {hookflash+onhooksignaling+callwait}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

T.38 fax using SIP PLAR to PSTN

The MALC supports T.38 fax streams across a VoIP network using SIP PLAR. In this configuration, the fax signal is sent to the MALC with the voicegateway card, and then forwarded to the PSTN as either an GR-303 or V5.2 fax signal.

Figure 29 illustrates the T.38 fax stream using SIP PLAR between MALC devices with the voicegateway card connected to a class V switch and the PSTN.

Figure 29: SIP PLAR T.38 between MALC and MALC Voicegateway to PSTN

Configuring T.38 using SIP PLAR to PSTNThe MALC supports T.38 fax streams across a VoIP network using SIP PLAR. In this configuration, one MALC converts the POTS signal to VoIP and sends the T.38 fax signal across the VoIP network. Another MALC with the voicegateway card receives the T.38 signal and sends it to the Class V switch for processing across the PSTN.

1 On the MALC converting the POTS to VOIP signal, specify the T.38 option when configuring a voice call with the voice add command for the POTS and SIP connections. The subscriber-voice-voip profile settings are updated based on the command options.

FaxMALC T.38 Fax Stream using

SIP PLAR

POTS VoIP

MALC with voicegateway

FaxClass Vswitch

PSTN

Configuring Voice



2 On the MALC with the voicegateway card, use the voice add command to configure the connection for VoIP to GR303 or VoIP to V5.2.

For GR303 connections:

voice add voip voip-1-3/ip dn 7350025 name m143-301 plar 172.24.200.143 t38fax t38udptl gr303 1/25

For V5.2 connections:

voice add voip voip-1-3/ip dn 5107777428 name caller plar 172.24.200.143 t38fax t38udptl v52 4/99 type pots

T.38 using SIP PLAR to POTS fax

The MALC supports T.38 fax streams across a VoIP network using SIP PLAR to another MALC device in the network. In this configuration, the fax signal is sent to the MALC with the voicegateway card, and then forwarded to the Class V switch, which routes the call back through the VoIP network to another MALC.

Figure 30 illustrates the T.38 fax stream using SIP PLAR between a MALC connected to a MALC with the voicegateway card. When the signal reaches the MALC with the voicegateway card, the Class V switch routes the signal to another MALC in the VoIP network to process the POTS fax.

Figure 30: SIP PLAR T.38 between MALC and MALC Voicegateway to POTS fax

FaxMALC T.38 Fax

Stream using SIP PLAR

POTS VoIP

MALC with voicegateway

Class Vswitch

MALC

Fax

POTS

GR303/V5.2

T.38 fax


Configuring T.38 using SIP PLAR to POTS fax1 On the MALC devices converting the POTS to VOIP signal, specify the

T.38 option when configuring a voice call with the voice add command for the POTS and voice connections. The subscriber-voice-voip profile settings are updated based on the command options.


2 On the MALC with the voicegateway card, use the voice add command to configure the T.38 connection for VoIP to GR303 or VoIP to V5.2.

For GR303 connections:

voice add voip voip-1-3/ip dn 7350025 name 7350025 plar 172.24.200.143 t38fax t38udptl gr303 1/25

For V5.2 connections:

voice add voip voip-1-3/ip dn 5107777428 name 5107777428 plar 172.24.200.143 t38fax t38udptl v52 4/99 type pots


Configuring Voice



CONFIGURING THE VOICE GATEWAY

This chapter describes how to configure the MALC voice gateway. It includes:


• Configuring voice gateway connections, page 270

• POTS cards running POTS to VoIP in same chassis as voicegateway card, page 293

• Configuring SIP-PRI media gateway, page 297

OverviewThe MALC voice gateway card (VG-T1/E1-32-2S) enables voice connections from an ATM and IP voice network to a TDM local exchange switch using GR-303 or V5.2 protocols. The following connection types are supported.

• Voice over IP: SIP-PLAR to GR-303 or V5.2

• Voice over ATM:

– BLES to GR-303 or V5.2

– ELCP to V5.2

Figure 31: Voice gateway overview

MALC with

voice gatewayPacket

GR303

V5.2

Local Exchange

Switch

TDM

Configuring the Voice Gateway


The MALC voice gateway card can also serve as an aggregation point for multiple downstream MALC or IAD systems aggregating multiple services (PON, SHDSL, T1/E1 ATM) or multiple voice lines on residential services (ADSL, ADSL2+, VDSL) over a single uplink connection.

All the ATM/IP uplink cards can be used to connect VoIP traffic to the voice gateway card.

Figure 32: Voice gateway aggregation point

The MALC now supports a feature bit used to optimize voice gateway performance. When this feature bit is enabled, the MALC supports up to 4 redundant voice gateway cards.

Configuring voice gateway connectionsThe voice gateway card configuration involves validating voice configuration prerequisites, configuring the voice VPIs and VCIs as required, and adding the desired voice connections. Procedures for verifying the voice connections are also provided.

These configuration procedures require the MALC uplink and voice gateway cards to be physically installed and running in the current system with properly configured card profiles.

Note: The voice gateway card requires MALC software version 1.11.1 or higher on the uplink cards.

This section contains procedures for:

• Verifying voice configuration prerequisites on page 271

• VoIP to voice gateway connections on page 272

• Subtended MALC POTS VoIP voice gateway connections on page 277

IAD

MALC withvoice gateway


IP Network

Configuring voice gateway connections


• AAL2 voice gateway connections on page 280

• Subtended MALC ISDN or POTS voice gateway connections on page 290

Verifying voice configuration prerequisitesBefore configuring the voice gateway connection, use the following procedures to ensure that the configuration prerequisites have been configured.

1 Use the slots command to verify the desired uplink and voice gateway card installation and status. This example shows the Uplink-T1/E1-ATM/TDM/IP-16 card running in slot 1 and the MALC voice gateway card running in slot 3. Other line cards can be inserted and running in other slots as desired.

zSH> slots 1: MALC UPLINK T1/E1 TDMF (RUNNING) 3: MALC T1E132VG (RUNNING)13: MALC GSHDSL (RUNNING)17: MALC ADSL + POTS AC6 (RUNNING)

2 Check the system settings to ensure the appropriate country coding and other system-level settings are configured. See Updating system settings on page 198 for details.

3 Create and activate a V5.2 or GR-303 interface group (IG). See Configuring GR-303 or V5.2 Interface Groups on page 177 for details.

Note: Up to 8 interface groups can be supported on each voice gateway card.

4 Ensure there is an active system clock source. See the MALC Hardware Installation Guide.

5 Create a new atm-traf-descr with a unique index for a voice connection.

For ELCP to V5.2 voice connections, both the VPL and VCL traffic descriptors are required. See Configuring ATM on page 157 for more information on ATM traffic descriptors and parameters.

zSH> new atm-traf-descr 1 index can be any valuePlease provide the following: [q]uit.td_type: -----------------> {atmNoClpNoScr}: atmClpNoTaggingScrCdvttd_param1: ---------------> {0}: 4826 PCR . td_param2: ---------------> {0}: 4825 SCR td_param3: ---------------> {0}: 20 MBStd_param4: ---------------> {0}: 15000 CDVTtd_param5: ---------------> {0}:cac-divider: -------------> {1}: 10td_service_category: -----> {ubr}: rtvbr for voicetd_frame_discard: --------> {false}:usage-parameter-control: -> {true}:....................



Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

VoIP to voice gateway connections


• Overview on page 272

• Creating an unnumbered interface for VoIP on page 273

• Configuring voice gateway host for VoIP connections

• Configuring voice connections for VoIP to GR303

• Configuring voice connections for VoIP to V5.2

• Configuring T.38 service on the voicegateway connections

• Deleting voice gateway host and voice connection

OverviewFor VoIP to TDM voice connections, the MALC voice gateway card supports multiple incoming VoIP voice lines going out a single TDM connection to a local voice switch.

Figure 33: Voice gateway VoIP to TDM

For VoIP to TDM connections on the voice gateway card, VoIP packets destined for the voice gateway card enter through one of the MALC uplink card interfaces (GigE, SONET, IP) and are terminated on the voice gateway card. The voice signal is converted to TDM T1/E1 channels and sent to the local switch for TDM voice processing. For traffic coming from the local switch, the TDM voice signals are converted to VoIP packets by the voice gateway card and routed back out the MALC uplink card to the configured VoIP destination.

Configuring a VoIP to TDM voice gateway connection involves configuring the voice gateway for a VoIP host and adding a VoIP to TDM voice connection.

IP Network





Note: Only one IP interface can be configured on the voice gateway card.

Creating an unnumbered interface for VoIPBefore configuring a VoIP to TDM connection, create a new ip-interface-record and unnumbered interface.

1 To create an IP interface record, use the new ip-interface-record command.

zSH> new ip-interface-record vg/ipvpi: ---------------> {0}:vci: ---------------> {0}:rdindex: -----------> {1}:dhcp: --------------> {none}: ** read-only **addr: --------------> {0.0.0.0}: 10.10.10.1netmask: -----------> {0.0.0.0}: 255.255.255.0bcastaddr: ---------> {0.0.0.0}: 10.10.10.255destaddr: ----------> {0.0.0.0}:farendaddr: --------> {0.0.0.0}:mru: ---------------> {1500}:reasmmaxsize: ------> {0}:ingressfiltername: -> {}:egressfiltername: --> {}:pointtopoint: ------> {no}:mcastenabled: ------> {yes}:ipfwdenabled: ------> {yes}:mcastfwdenabled: ---> {yes}:natenabled: --------> {no}:bcastenabled: ------> {yes}:ingressfilterid: ---> {0}:egressfilterid: ----> {0}:ipaddrdynamic: -----> {static}:dhcpserverenable: --> {false}:subnetgroup: -------> {0}:unnumberedindex: ---> {0}:mcastcontrollist: --> {}:vlanid: ------------> {0}:maxVideoStreams: ---> {0}:....................Save new record? [s]ave, [c]hange or [q]uit: sCould not find an appropropriate interface on which to bind the IP record.

Could not automatically bind this IP InterfaceNew record saved.

2 To create an unnumbered IP interface record, use the new ip-unnumbered-record command.

zSH> new ip-unnumbered-record 1ipUnnumberedInterfaceName: -> { }: vg/ip



....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Configuring voice gateway host for VoIP connections The voice gateway VoIP to GR-303 and V5.2 configurations require configuring the voice gateway as an AAL5 proxy on the voice gateway card before adding a VoIP to GR-303 or VoIP to V5.2 voice connection.

1 Locate the if-translate record.

zSH> list if-translate 1-3-1-0/aal5proxyif-translate 1-3-1-0/aal5proxy1 entry found.

2 Verify that the desired ATM traffic descriptor is configured.

zSH> list atm-traf-descratm-traf-descr 11 entry found.

3 Use the voicegateway add command to create the voice gateway host using the available physical interface or slot number of the voicegateway card and traffic descriptor.

zSH> voicegateway add 3 td 1 10.10.10.2

zSH> voicegateway add 1-3-1-0/aal5proxy td 1 10.10.10.2

This adds an IP host on the voice gateway card in slot 3 and assigns the IP address 10.10.10.2. The connection uses traffic descriptor 1 and an AAL5 physical interface of aal5proxy. Use the new voip-server-entry command to add the voip-server-entry 255/255 for SIP binding group and multiple SIP server support if that voip-server-entry profile does not already exist.

Note: The voicegateway add command automatically creates the required ATM VCLs if they do not already exist.

4 Use the voicegateway show command to display the voice gateway host using the slot number of the voicegateway card or the AAL5 physical interface.

zSH> voicegateway show 3Rd/Address Interface Group T Host Address-----------------------------------------------------1 10.10.10.1 1-3-1-0-aal5proxy-0-32 0/32 0 S 10.10.10.2

zSH> voicegateway show 1-3-1-0/aal5proxyRd/Address Interface Group T Host Address-----------------------------------------------------1 10.10.10.1 1-3-1-0-aal5proxy-0-32 0/32 0 S 10.10.10.2



Configuring voice connections for VoIP to GR303After configuring the voice gateway as an AAL5 proxy on the voice gateway card, the voice connection for VoIP to GR-303 requires adding a VoIP to GR-303 voice connection. This example uses the IP interface voip-1-3/ip with the number 735-0025, name m143-301, destination IP address 172.24.200.143, GR-303 switch protocol, IG 1 and CRV 25. This command also sets the VoIP password in the subscriber-voice-voip profile to password.

1 Use the voice add command to add a VoIP to GR-303 voice connection between the voice gateway card and the switch. An optional password is used.

zSH> voice add voip voip-1-3/ip dn 7350025 name m143-301 plar 172.24.200.143 gr303 1/25 pw passwordCreated subscriber-voice 1/330/48Created subscriber-voice-voip 173Created gr303-ig-crv 1/25Created subscriber-voice-gr303 174

2 Display the configured voice connection with the voice show command.

ZSH>voice showSubscriber end-point Remote end-point Voice Prof Id STA---------------------------- ----------------------------- --------------voip-1-3/ip DN 7350025 GR303 one/25 1/330/25 ENATotal number of voice connections : 1

Configuring voice connections for VoIP to V5.2After configuring the voice gateway as an AAL5 proxy on the voice gateway card, the voice connection VoIP to V5.2 requires adding a VoIP to V5.2 voice connection.

1 Use the voice add command to add a VoIP to V5.2 voice connection between the voice gateway card and the switch using IG 4 and user port 99. By default, the registration server is set to 0 and the preferred codec is G.711a. An option password is used.

zSH> voice add voip voip-1-3/ip dn 5107777428 name caller pw password v52 4/99 type potsCreated subscriber 1/2Created subscriber-voice 1/2/1Created subscriber-voice-voip 11Created v52-user-port 4/99/2Created subscriber-voice-v52 12


zSH> voice show Subscriber end-point Remote end-point Voice Prof Id STA------------------------------ ------------------------ -------------- ---voip-1-3/ip DN 5107777428 V52 four/99/pots 1/2/1 ENA

Total number of voice connections : 1



Configuring T.38 service on the voicegateway connectionsSpecify the T.38 option when configuring a voice call with the voice add command. The subscriber-voice-voip profile settings are updated based on the command options.

voice add voip voip-1-3/ip dn 7350025 name m143-301 plar 172.24.200.143 t38fax t38udptl gr303 1/25 voice add voip voip-1-3/ip dn 5107777428 name caller plar 172.24.200.143 t38fax t38udptl v52 4/99 type pots


The subscriber-voice-voip profile can also be updated to enable the T.38 fax service. After updating the subscriber-voice-voip profile, the voice subscriber must be disabled and then re-enabled for the changes to be effective.

zSH> list subscriber-voicesubscriber-voice 1/2/26subscriber-voice 1/2/272 entries found.

zSH> update subscriber-voice 1/2/26Please provide the following: [q]uit.voice-connection-type: --------> {voiptopots}: ** read-only **voice-endpoint1-addr-index: ---> {52}: ** read-only **voice-endpoint2-addr-index: ---> {51}: ** read-only **voice-connection-description: -> {}:voice-admin-status: -----------> {enabled}: disabledhuntgroup: --------------------> {false}: ** read-only **features: ---------------------> {hookflash+onhooksignaling+callwait}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

zSH> update subscriber-voice-voip 52 (the endpoint1-addr-index in subscriber-voice profile.)Please provide the following: [q]uit.voip-username: -------------> {9990002}:directory-number: ----------> {9990002}:ip-interface-index: --------> {ethernet2-2/ip}:preferred-codec: -----------> {g729a}:g711-fallback: -------------> {true}:frames-per-packet: ---------> {4}:g726-byte-order: -----------> {bigendian}:voip-password: -------------> {}:voip-plar: -----------------> {false}:** read-only **voip-plar-dest-ipaddrtype: -> {ipv4}:voip-plar-dest-ipaddr: -----> {}:



voip-plar-udp-port: --------> {5060}:registration-server: -------> {0}:t38-fax: -------------------> {t38none}:t38udptl....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

zSH> update subscriber-voice 1/2/26Please provide the following: [q]uit.voice-connection-type: --------> {voiptopots}: ** read-only **voice-endpoint1-addr-index: ---> {52}: ** read-only **voice-endpoint2-addr-index: ---> {51}: ** read-only **voice-connection-description: -> {}:voice-admin-status: -----------> {disabled}: enabledhuntgroup: --------------------> {false}: ** read-only **features: ---------------------> {hookflash+onhooksignaling+callwait}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Deleting voice gateway host and voice connectionTo remove the configured voice gateway connection, use the voicegateway delete command with the slot number of the voicegateway card or the AAL5 physical interface.

zSH> voicegateway delete 3

zSH> voicegateway delete 1-3-1-0/aal5proxy

Deleting voice connectionTo remove the configured voice connection, use the voice delete command. Do not attempt to manually remove or edit the related subscriber-voice profiles.

zSH> voice delete voip ethernet1/ip DN 5107777428Deleted v52-user-port 4/99/2Deleted subscriber-voice 1/2/1 and its subscriber-voice-xxx profiles

Subtended MALC POTS VoIP voice gateway connections



• Configuring subtended POTS to VoIP voice connection on page 278

• Deleting subtended voice connection on page 279



OverviewUsing a subtended MALC, with an optional IAD, enables the MALC voice gateway card to function as an aggregation point for multiple downstream systems aggregating multiple services (PON, SHDSL, T1/E1 ATM) or multiple voice lines on residential services (ADSL, ADSL2+, VDSL) over a single MALC uplink and voice gateway connection.

Figure 34: Voice gateway VoIP to TDM with subtended IAD

In a subtended MALC configuration, subscriber traffic passes through the subtended MALC’s uplink card and is sent as VoIP packets to the MALC with the voice gateway card. VoIP packets destined for the voice gateway card enter through one of the MALC uplink card interfaces (GigE, SONET, IP) and are terminated on the voice gateway card. The voice signal is converted to TDM T1/E1 channels and sent to the local switch for TDM voice processing. For traffic coming from the local switch, the TDM voice signals are converted to VoIP packets by the voice gateway card and routed back out the MALC’s uplink card, sent to the subtended MALC, and then routed to the configured VoIP destination.

To configure the voice gateway card with a downstream MALC system, first ensure the voice gateway card is configured for a VoIP to TDM connection. See VoIP to voice gateway connections on page 272.

Then, use the voice add command to add a POTS to VoIP voice connection on the subtended MALC. This voice connection transports the voice signals between the subtended MALC and the VoIP interface on the voice gateway card.

Configuring subtended POTS to VoIP voice connection Configure a POTS to VoIP voice connection on the subtended MALC to send its VoIP signals to the voice gateway card. The subtended MALC must have a working Ethernet IP connection and an available IP route to the voice

IAD



IP Network



gateway IP address. Also, a subscriber line POTS card should be installed with the required ports enabled.

1 Create a non-subscriber VCL 0/34 on the MALC uplink card. The VCL 0/34 is required for internal voice processing and must be configured once for each uplink card that will connect to a voice connection from a subtended MALC.

zSH> new atm-vcl 1-1-2-0-dspproxy/atm/0/34vpi: -----------------------------> {0}vci: -----------------------------> {34}admin_status: --------------------> {up}receive_traffic_descr_index: -----> {1}transmit_traffic_descr_index: ----> {1}vcc_aal_type: --------------------> {aal5}vcc_aal5_cpcs_transmit_sdu_size: -> {9188}vcc_aal5_cpcs_receive_sdu_size: --> {9188}vcc_aal5_encaps_type: ------------> {llcencapsulation}vcl_cast_type: -------------------> {p2p}vcl_conn_kind: -------------------> {pvc}fault-detection-type: ------------> {disabled}traffic-container-index: ---------> {0}

2 Reboot the MALC.

3 Use the voice add command on the subtended MALC to add the POTS to VoIP connection. This example connects a POTS subscriber with interface 1-3-1-0/voicefxs to VoIP interface ethernet1/ip with number 735-0025, name of m143-301, and destination IP address 10.177.1.2.

zSH> voice add pots 1-3-1-0/voicefxs voip ethernet1/ip dn 7350025 name m143-301 plar 10.177.1.2Created subscriber-voice 1/2/1Created subscriber-voice-pots 1004Created subscriber-voice-voip 1005

4 Verify the voice connection with the voice show command.

zSH> voice showSubscriber end-point Remote end-point Voice Prof Id STA------------------------------ ------------------------------ -------------- ---1-3-1-0/voicefxs ethernet1/ip DN 7350025 1/2/1 ENATotal number of voice connections : 1

Deleting subtended voice connection To remove the configured voice connection, use the voice delete command.

zSH> voice delete pots 1-3-1-0/voicefxs Deleted subscriber-voice 1/2/1 and its subscriber-voice-xxx profiles



AAL2 voice gateway connections

This section contains the following information:


• Configuring voice gateway for VoATM BLES to GR-303 (VC-switched) on page 282

• Configuring voice gateway for VoATM BLES to GR303 (VP-switched) on page 283

• Configuring voice gateway for VoATM BLES to V5.2 (VC-switched) on page 284

• Configuring voice gateway for VoATM BLES to V5.2 (VP-switched) on page 285

• Configuring voice gateway for VoATM ELCP to V5.2 (VC-switched) ISDN signal on page 286

• Configuring voice gateway for VoATM ELCP to V5.2 (VP-switched) on page 288

• Configuring subtended AAL2 voice connection on page 291

OverviewFor VoATM to TDM voice connections, the MALC voice gateway supports multiple ATM voice lines over the voice gateway card to a local TDM (GR-303 or V5.2) switch.

Figure 35: Voice gateway VoATM to TDM

For VoATM traffic, ATM traffic destined for the voice gateway card enters through one of the MALC uplink card’s ATM interfaces and is terminated on the voice gateway card. The ATM voice signals are converted to TDM T1/E1 channels and sent to the local TDM switch for processing. For traffic coming from the local switch, the TDM voice signals are converted to VoATM signals by the voice gateway card and sent back out the MALC uplink card to configured ATM destination.

ATM





Note: The voice gateway card does not support connection admission control (CAC).

All uplink cards can be used for connecting VoATM traffic to the voice gateway card.

The voice gateway card supports VoATM BLES to GR-303 or V5.2 and VoATM ELCP to V5.2 connection types.

The MALC voice gateway card enables a combination of VP and VC switching for flexible VoATM voice gateway configurations and maximum subscriber support.

• VC-switched

In VC-switching, VCs are switched independently of each other based on VPI and VCI value. The VP range of 0-7 is reserved for VC-switching on the voice gateway card. The VCs in each VC-switched VP must start with 32 and can contain any number up to the maximum number of 448 VCs. The maximum number of VCs that can be allocated to an individual VC-switched VPI is determined by the zhoneAtmVpiMaxVci parameter in the atm-vpi profile.

• VP-switched

In VP-switching, VCs are switched collectively in groups or Virtual Paths (VPs) based on VPI value. The VP range of 16 to 63 is reserved for VP-switching on the voice gateway card. Up to 48 VPs can be switched from the MALC uplink card to a voice gateway card. The VCs in each VP-switched VP must start with 32 and can contain any number up to the maximum number of 7,680 VCs. The maximum VCI value that can be allocated to an individual VP-switched VP is determined by the zhoneAtmMaxVciPerVp parameter in the atm-vpi profile. For example, if this parameter is set to 1023 for VPI 16, a VC with VPI/VCI 16/1024 will not be allowed even if it is the only VC configured on the voice gateway card. The sum of this parameter in all VP-switched atm-vpi profiles on the voice gateway card cannot exceed 7,680.

The voice vpladd command automatically increments the assigned VP starting at 16.

Figure 36 illustrates the voice gateway support for VC-switching and VP-switching.



Figure 36: Voice gateway VoATM VP/VC support

The voice gateway card supports up to 8,128 virtual circuits (VCs). Each VC represents a single IAD and supports from 1 to 8 physical or logical telephones. With 32 DS1 ports, a maximum of 768 (32DS1s x 24 DS0’s) voice subscribers are supported. With 32 E1 ports, a maximum or 960 (32 E1’s x 31 DS0’s) voice subscribers are supported.

For VC-switching, configuring the voice gateway AAL2 voice connection involves using the voicegateway add command to add the required VP, VC, and AAL2 to GR-303 or V5.2 voice connection on the voice gateway card.

For VP-switching, configuring the voice gateway AAL2 voice connection involves using the following commands:

• voice addvpi command builds the VPs on the uplink card interface and voice gateway aal2proxy.

• voice addvpl command builds the VP links and ATM cross connect

• voice add command builds the shared VC and establishes the AAL2 to GR-303 or V5.2 voice connection on the voice gateway card.

Configuring voice gateway for VoATM BLES to GR-303 (VC-switched) This procedure explains how to configure a VC-switched VoATM BLES to GR-303 voice connection on the voice gateway card.

1 Use the voice add command on the voice gateway card to add the voice connection for the specified VC and CID to the GR-303 IG.

zSH> voice add aal2 1-4-1-0/ds1 vc 0/139 cid 48 gr303 1/131Created subscriber-voice 1/266/6Created aal2-cid-profile 340/0/32/48

VP0-7 (VC Switched)

VP0

VP ...

VC32-x

VP7

VC32-x

VC32-x

VC32-x

VC32-x

VC32-x

Total VCs in VC-switched VPs is 448.

VP16-63 (VP Switched)

VP ...

VP63

VP16

Maximum VCI value that can be allocated in each

VP-switched VP is set using the atm-vpi profile paramter

ZhoneAtmMaxVciPerVp.

Total VCs in VP-switched VP is 7680

Total VCs supported on the voice gateway card is 8128.

Maximum number of VCs in each VC-switched VP is set

using the atm-vpi profile paramter ZhoneAtmVpiMaxVci. TDM



Created subscriber-voice-aal2 171Created gr303-ig-crv 1/131Created subscriber-voice-gr303 172

This adds an ATM to GR-303 voice connection with the AAL2 interface 1-4-1-0 and assigns the virtual connection VPI 0, VCI 139 and CID 48. The TDM connection uses GR-303 protocol and interface group 1 with CRV 131.

2 Display the ATM to GR-303 voice connection with the voice show command.

zSH> voice show Subscriber end-point Remote end-point Voice Prof Id STA-------------------------- --------------------------- ------------- ---1-4-1-0/ds1 VC 0/139 CID 48 GR303 one/131 1/266/6 ENATotal number of voice connections : 1zSH>

Configuring voice gateway for VoATM BLES to GR303 (VP-switched)This procedure explains how to configure a VP-switched VoATM BLES to V5.2 voice connection on the voice gateway card. Use the voice vpiadd and voice vpladd commands to build the ATM VP between the uplink card VP and the voice gateway card aal2proxy using the same VC. Then, use the voice add command to build the VCL on the aal2proxy with the same VC that was configured on the uplink card. The allowed VP range on aal2proxy is 16 to 63.

Note: In addition to the GR-303 interface group, the required VPL traffic descriptor and VCL traffic descriptor must be built before performing this procedure.

1 Use the voice vpiadd command to build the ATM VPI for the uplink card and the voice gateway card aal2proxy.

zSH> voice vpiadd uplink/atm 0 gr303 1 501Created atm-vpi 1-3-3-0-aal2proxy/atm/16Created atm-vpi uplink1/atm/0

This example uses the uplink interface uplink/atm with VP 0. The MALC uplink cards support up 256 (0-255) VPs. The voice call type is GR-303 with IG 1. The maximum number of VCs allocated for the specified VP-switched VPI is 512.

2 Reboot the system to install the configured VPIs.

zSH>systemreboot

3 Use the voice vpladd command to build the VPLs and cross connects between the uplink card and aal2proxy.

zSH>voice vpladd uplink/atm 0 td 1/1 gr303 1



Created atm-vpl 1-3-3-0-aal2proxy/atm/16Created atm-vpl uplink1/atm/0Created atm-cc 6

This command builds atm-vpl uplink1/atm/0 on the uplink card using traffic descriptor tx and rx 1/1 with atm-vpl 1-3-3-0-aal2proxy/atm/16 on the voice gateway card. VP 16 is the first available VP in the allowed VP range on the voice gateway card.

4 Use the voice add command on the voice gateway card to add the voice connection for the desired VC and CID to the GR-303 IG.

zSH> voice add atm uplink1/atm vp 0/101 td 1/1 cid 1 alaw gr303 1/1 type potsCreated subscriber-voice 1/51/2Created aal2-cid 109/16/101/1/1Created subscriber-voice-aal2 15Created gr303-cid 1/1/2Created subscriber-voice-gr303 16

This command creates a POTS to GR-303 voice connection between the uplink interface uplink1 with VP 0 and VC 101 to the voice gateway card CID 1 with VP 16 and shared VC 101.

5 Display the ATM to GR-303 voice connection with the voice show command.

zSH> voice show Subscriber end-point Remote end-point Voice Prof Id STA-------------------------- --------------------------- ------------- ---1-1-1-0/sonet VC 0/101 port 1 GR303 100 100/11/35/1 ENA

Total number of voice connections : 1zSH>

Configuring voice gateway for VoATM BLES to V5.2 (VC-switched)This procedure explains how to configure a VC-switched VoATM BLES to V5.2 voice connection on the voice gateway card.

1 Use the voice add command on the voice gateway card to add the voice connection for the specified VC and user port to the V5.2 IG.

zSH> voice add aal2 uplink1/atm vc 6/39 td 1/1 cid 16 v52 4/39 type potsCreated subscriber 1/57Created subscriber-voice 1/57/1Created atm-vcl uplink1/atm/6/39Created atm-vcl 1-5-3-0-aal2proxy/atm/0/32Created atm-cc 2Created aal2-vcl-profile 1-5-3-0-aal2proxy/atm/0/32Created aal2-cid-profile 99/0/32/16Created subscriber-voice-aal2 1Created v52-user-port 4/39/2Created subscriber-voice-v52 2



This adds an ATM to V5.2 voice connection with the uplink1 AAL2 interface and assigns the virtual connection VPI 6, VCI 39 and CID 16.

2 Display the ATM to V5.2 voice connection with the voice show command.

zSH> voice show Subscriber end-point Remote end-point Voice Prof Id STA------------------------------ ------------------------ -------------- ---1-1-1-0/sonet VC 6/39 CID 16 V52 four/39/pots 1/57/1 ENA

3 Delete the voice connection.

zSH> voice delete aal2 1-1-1-0/sonet VC 6/39 CID 16Deleted aal2-cid-profile 99/0/32/16Deleted v52-user-port 4/39/2Deleted subscriber-voice 1/57/1 and its subscriber-voice-xxx profilesDeleted atm-vcl 99/0/32Deleted atm-vcl 15/6/39Deleted atm-cc 2

Configuring voice gateway for VoATM BLES to V5.2 (VP-switched)This procedure explains how to configure a VoATM BLES to V5.2 voice connection on the voice gateway card. Use the voice vpiadd and voice vpladd commands to build the ATM VP between the uplink card VP and the voice gateway card aal2proxy using the same VC. Then, use the voice add command to build the VCL on the aal2proxy using the same VC that was configured on the uplink card. The allowed VP range on aal2proxy is 16 to 63.

Note: In addition to the V5.2 interface group, the required VPL traffic descriptor and VCL traffic descriptor for ELCP lines must be built before performing this procedure.

1 Use the voice vpi add command to build the ATM VPI for the uplink card VP and the voice gateway card aal2proxy.

zSH>voice vpiadd uplink/atm 0 v52 1 2000Created atm-vpi 1-3-3-0-aal2proxy/atm/16Created atm-vpi uplink1/atm/0

This example uses the uplink interface uplink/atm with VP 0. The MALC uplink cards support up 256 (0-255) VPs. The voice call type is V5.2 with IG 1. The maximum VCs allocated to the specified VP-switched VPI is 2048.


zSH>systemreboot

3 Use the voice vpladd command to build the VPLs and cross connects.



zSH>voice vpladd uplink/atm 0 td 1/1 v52 1Created atm-vpl 1-3-3-0-aal2proxy/atm/16Created atm-vpl uplink1/atm/0Created atm-cc 6

This command builds atm-vpl uplink1/atm/0 on the uplink card using traffic descriptor 1 and atm-vpl 1-3-3-0-aal2proxy/atm/16 on the voice gateway card. VP 16 is the first available VP in the allowed VP range on the voice gateway card.

4 Use the voice add command with the VPL option on the voice gateway card to add the voice connection for the specified VC and CID/port to the V5.2 IG.

zSH> voice add atm uplink1/atm vp 0/101 td 1/1 port 1 alaw v52 1/1 type potsCreated subscriber-voice 1/51/2Created aal2-port-profile 109/16/101/1/1Created subscriber-voice-elcp-aal2 15Created v52-user-port 1/1/2Created subscriber-voice-v52 16

This command creates a voice connection between the uplink interface uplink1 with VP 0 and VC 101 to the voice gateway card user port 1.

5 Display the ATM ELCP to V5.2 voice connection with the voice show command.

zSH> voice show Subscriber end-point Remote end-point Voice Prof Id STA-------------------------- --------------------------- ------------- ---1-1-1-0/sonet VC 0/101 port 1 V52 100 100/11/35/1 ENA


Configuring voice gateway for VoATM ELCP to V5.2 (VC-switched) ISDN signalThis procedure explains how to configure an ISDN signal over a VoATM ELCP to V5.2 voice connection on the voice gateway card.

Note: The elcp-trap parameter is available in the aal2-vcl profile. This parameter allows operators to turn ELCP traps on/off for particular AAL2 VCLs. All users on the provisioned AAL2 VCL will have their ELCP trap alerts turned either on or off.

1 Use the cc add command on the voice gateway card to add the cross connect for the specified VC and ISDN connection information using IG 4 and user port 41.

zSH> cc add elcp uplink2/atm vc 6/41 td 1/1 port 1 alaw v52 4/41 type isdn cpath 4



This adds a cross connect between the uplink2 interface and the voice gateway card using VC 7/111. The voice protocol is V5.2 and the connection type is ISDN with Cpath 5.

2 Use the voice add command to specific the voice connection.

zSH> voice add elcp uplink1/atm vc 6/41 td 1/1 port 1 alaw v52 4/41 type isdn cpath 4Created subscriber-voice 1/57/2Created atm-vcl uplink1/atm/6/41Created atm-vcl 1-5-3-0-aal2proxy/atm/0/32Created atm-cc 2Created aal2-vcl-profile 1-5-3-0-aal2proxy/atm/0/32Created aal2-elcp-port 99/0/32/1/2Created subscriber-voice-elcp-aal2 3Created v52-user-port 4/41/3Created subscriber-voice-v52 4Created subscriber-voice 1/57/3Created subscriber-voice-elcp-aal2 5Created subscriber-voice-v52 6Created subscriber-voice 1/57/4Created subscriber-voice-elcp-aal2 7Created subscriber-voice-v52 8

3 Display the ISDN to V5.2 voice connection with the voice show command.

zSH> voice showSubscriber end-point Remote end-point Voice Prof Id STA------------------------- ----------------------------- ------------ ---1-1-1-0/sonet VC 6/41 port 1 V52 four/41/isdn 1/57/2 ENA1-1-1-0/sonet VC 6/41 port 1 V52 four/41/isdn 1/57/3 ENA1-1-1-0/sonet VC 6/41 port 1 V52 four/41/isdn 1/57/4 ENATotal number of voice connections : 3

Configuring voice gateway for VoATM ELCP to V5.2 (VC-switched) POTS signalThis procedure explains how to configure an POTS signal over a VoATM ELCP to V5.2 voice connection on the voice gateway card.


1 Use the cc add command on the voice gateway card to add the cross connect for the specified VC and POTS connection information. using IG 4 and user port 40.

zSH> cc add elcp uplink2/atm vc 6/40 td 1/1 port 1 alaw v52 4/40 type pots



This adds a cross connect between the uplink2 interface and the voice gateway card using VC 7/111. The voice protocol is V5.2 and the connection type is POTS.

2 Use the voice add command to specific the voice connection.

zSH> voice add elcp uplink1/atm vc 6/40 td 1/1 port 1 alaw v52 4/40 type potsCreated subscriber-voice 1/57/5Created atm-vcl uplink1/atm/6/40Created atm-vcl 1-5-3-0-aal2proxy/atm/0/32Created atm-cc 2Created aal2-vcl-profile 1-5-3-0-aal2proxy/atm/0/32Created aal2-elcp-port 99/0/32/1/1Created subscriber-voice-elcp-aal2 9Created v52-user-port 4/40/2Created subscriber-voice-v52 10

3 Display the POTS to V5.2 voice connection with the voice show command.

zSH> voice showSubscriber end-point Remote end-point Voice Prof Id STA------------------------------ ------------------------- -------------- ---1-1-1-0/sonet VC 6/40 port 1 V52 four/40/pots 1/57/5 ENATotal number of voice connections : 1

Configuring voice gateway for VoATM ELCP to V5.2 (VP-switched)This procedure explains how to configure a VoATM ELCP to V5.2 voice connection on the voice gateway card.


Use the voice vpiadd and voice vpladd commands to build the ATM VP between the uplink card VP and the voice gateway card aal2proxy using the same VC. Then, use the voice add command to build the VCL on the aal2proxy using the same VC that was configured on the uplink card. The allowed VP range on aal2proxy is 16 to 63.

Note: In addition to the V5.2 interface group, the required VPL traffic descriptor and VCL traffic descriptor for ELCP lines must be built before performing this procedure.

1 Use the voice vpi add command to build the ATM VPI for the uplink card VP and the voice gateway card aal2proxy.

zSH>voice vpiadd uplink/atm 0 v52 1 2004Created atm-vpi 1-3-3-0-aal2proxy/atm/20



Created atm-vpi uplink1/atm/7

This example uses the uplink interface uplink/atm with VP 0. The MALC uplink cards support up 256 (0-255) VPs. The voice call type is V5.2 with IG 1. The maximum number of VCs allocated to the specified VP-switched VPI is 2048.


zSH>systemreboot

3 Use the voice vpladd command to build the VPLs and cross connects.

zSH>voice vpladd uplink/atm 0 td 1/1 v52 1Created atm-vpl 1-3-3-0-aal2proxy/atm/20Created atm-vpl uplink1/atm/7Created atm-cc 6

This command builds atm-vpl uplink1/atm/0 on the uplink card using traffic descriptor 1/1 and atm-vpl 1-3-3-0-aal2proxy/atm/16 on the voice gateway card. VP 16 is the first available VP in the allowed VP range on the voice gateway card.

4 Use the voice add command with the VPL option on the voice gateway card to add the voice connection for the specified VP/VC, V5.2 IG and user port.

zSH> voice add elcp uplink1/atm vp 0/101 td 1/1 port 1 alaw v52 1/1 type potsCreated subscriber-voice 1/51/2Created aal2-elcp-port 109/16/101/1/1Created subscriber-voice-elcp-aal2 15Created v52-user-port 1/1/2Created subscriber-voice-v52 16

5 Display the ATM ELCP to V5.2 voice connection with the voice show command.

zSH> voice show Subscriber end-point Remote end-point Voice Prof Id STA-------------------------- --------------------------- ------------- ---1-1-1-0/sonet VC 0/101 port 1 V52 100 100/11/35/1 ENA

Total number of voice connections : 1zSH>

Deleting voice connection

To remove the configured voice connection, use the voice delete command.

zSH> voice delete elcp 1-1-1-0/sonet VC 6/41 port 1Deleted aal2-elcp-port 99/0/32/12Deleted v52-user-port 4/41/3



Deleted subscriber-voice 1/57/2 and its subscriber-voice-xxx profilesDeleted subscriber-voice 1/57/3 and its subscriber-voice-xxx profilesDeleted subscriber-voice 1/57/4 and its subscriber-voice-xxx profilesDeleted atm-vcl 99/0/32Deleted atm-vcl 15/6/41

To remove the configured VP, use the voice vp delete command.

zSH> voice vpdelete uplink/atm/0

Subtended MALC ISDN or POTS voice gateway connections

In a subtended MALC configuration, subscriber traffic passes through the subtended MALC uplink card and is sent as AAL2 packets to the MALC with the voice gateway card. The MALC functions as an aggregation point for multiple downstream MALC systems aggregating multiple ATM services (PON, SHDSL, T1/E1 ATM) or multiple ATM voice lines on residential services (ADSL, ADSL2+, VDSL) over a single uplink and voice gateway connection.

Figure 37: Voice gateway VoATM to TDM with subtended IAD

In subtended MALC configuration, subscriber traffic passes through the subtended MALC uplink card and is sent as AAL2 cells to the MALC with the voice gateway card. AAL2 cells destined for the voice gateway card enter through one of the MALC uplink card interfaces (GigE, SONET, IP) and are terminated on the voice gateway card. The voice signal is converted to TDM T1/E1 channels and sent to the local switch for TDM voice processing. For traffic coming from the local switch, the TDM voice signals are converted to AAL2 cells by the voice gateway card and sent back out the MALC uplink card to the subtended MALC and then to the configured AAL2 destination.

IAD



ATM



Before configuring the AAL2 to TDM voice connection on the subtended MALC, ensure the voice gateway AAL2 to GR-303 connection is configured correctly. See AAL2 voice gateway connections on page 280.

Use these procedures to configure the voice connection on the subtended MALC. For AAL2 connections to a voice gateway card, the subtended MALC supports subscriber voice connections for ISDN to AAL2 and POTS to AAL2.

• Configuring subtended AAL2 voice connection

• Deleting subtended voice connection

Configuring subtended AAL2 voice connection Configure the subtended MALC AAL2 to sends its AAL2 signals to the voice gateway. The AAL2 shelf should have a working ATM connection and an available ATM circuit to the voice gateway card. Also, either a subscriber line POTS or ISDN card should be installed with all the required ports enabled.

For subtended voice connections, the MALC voice card supports POTS to AAL2 or ISDN to AAL2 voice connections. For more details about configuring voice connections, see Configuring Voice on page 197.

For these voice configurations, the ATM traffic descriptor is required before the voice connection can be configured.

The ISDN to AAL2 type of voice connection requires an ULC card.

Configuring POTS or ISDN to AAL2 voice connectionsThe voice add command automatically creates the required VPI/VCI, CID, and uplink VCL.


See Configuring ATM on page 157 for more information on ATM traffic descriptors and parameters.




2 Use the voice add command on the subtended MALC to configure an ISDN to AAL2 or POTS to AAL2 voice connection.

For ISDN to AAL2:

zSH> voice add isdn 1-3-1-0/isdnu aal2 uplink1/atm vc 0/38 td 1/1 cid 127Created subscriber-voice 1/5/4Created subscriber-voice-isdn 65Created aal2-cid-profile 38/0/38/127Created subscriber-voice-aal2 66Created subscriber-voice 1/5/5Created subscriber-voice-isdn 67Created subscriber-voice-aal2 68Created subscriber-voice 1/5/6Created subscriber-voice-isdn 69Created subscriber-voice-aal2 70

This example adds an ISDN to AAL2 connection over an ATM VCL with a VPI/VCI of 0/38, traffic descriptor 1, user port 1, and a CID of 16.

For POTS to AAL2:

zSH> voice add pots 1-5-24-0/voicefxs aal2 uplink1/atm vc 0/39 td 1/1 cid 16Created subscriber-voice 1/32/2Created subscriber-voice-pots 10017Created atm-vcl uplink1/atm/0/39Created aal2-cid-profile 38/0/39/16Created subscriber-voice-aal2 10018

This example adds a POTS to AAL2 connection over an ATM VCL with a VPI/VCI of 0/38, traffic descriptor 1, user port 1,and a CID of 16.

3 Display the voice connection with the voice show command.

zSH> voice showSubscriber end-point Remote end-point Voice Prof Id STA------------------------------ ------------------------------ -------------- ---1-5-24-0/voicefxs 1-2-1-0/atmima VC 0/39 CID 16 1/32/2 ENA1-3-1-0/isdnu 1-1-1-0/ds1 VC 0/38 CID 127 1/5/4 ENATotal number of voice connections : 2

Deleting subtended voice connectionTo remove a configured voice connection on the subtended MALC, use the voice delete command.

zSH> voice delete isdn 1-3-1-0/isdnuzSH> voice delete pots 1-5-24-0/voicefxs

POTS cards running POTS to VoIP in same chassis as voicegateway card



ADSL+POTS cards can run POTS to VoIP connections in the same chassis as the voicegateway card running VOIP to GR-303 or V5.2.

Voicegateway configuration

Voicegateway card configuration contains the same steps used when this card is configured in a separate system.

• Creating an unnumbered interface for VoIP on page 273

• Configuring voice gateway host for VoIP connections on page 274

• Configuring voice connections for VoIP to GR303 on page 275

• Configuring voice connections for VoIP to V5.2 on page 275

Creating an unnumbered interface for VoIPBefore configuring a VoIP to TDM connection, create a new ip-interface-record and unnumbered interface.


zSH> new ip-interface-record vg/ipvpi: ---------------> {0}:vci: ---------------> {0}:rdindex: -----------> {1}:dhcp: --------------> {none}: ** read-only **addr: --------------> {0.0.0.0}: 10.10.10.1



netmask: -----------> {0.0.0.0}: 255.255.255.0bcastaddr: ---------> {0.0.0.0}: 10.10.10.255destaddr: ----------> {0.0.0.0}:farendaddr: --------> {0.0.0.0}:mru: ---------------> {1500}:reasmmaxsize: ------> {0}:ingressfiltername: -> {}:egressfiltername: --> {}:pointtopoint: ------> {no}:mcastenabled: ------> {yes}:ipfwdenabled: ------> {yes}:mcastfwdenabled: ---> {yes}:natenabled: --------> {no}:bcastenabled: ------> {yes}:ingressfilterid: ---> {0}:egressfilterid: ----> {0}:ipaddrdynamic: -----> {static}:dhcpserverenable: --> {false}:subnetgroup: -------> {0}:unnumberedindex: ---> {0}:mcastcontrollist: --> {}:vlanid: ------------> {0}:maxVideoStreams: ---> {0}:....................Save new record? [s]ave, [c]hange or [q]uit: sCould not find an appropropriate interface on which to bind the IP record.



zSH> new ip-unnumbered-record 1ipUnnumberedInterfaceName: -> { }: vg/ip....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Configuring voice gateway host for VoIP connections The voice gateway VoIP to GR-303 and V5.2 configurations require configuring the voice gateway as an AAL5 proxy on the voice gateway card before adding a VoIP to GR-303 or VoIP to V5.2 voice connection.

1 Locate the if-translate record.

zSH> list if-translate 1-3-1-0/aal5proxyif-translate 1-3-1-0/aal5proxy1 entry found.

2 Verify that the desired ATM traffic descriptor is configured.



zSH> list atm-traf-descratm-traf-descr 11 entry found.

3 Create and activate a V5.2 or GR-303 interface group (IG). See Configuring GR-303 or V5.2 Interface Groups on page 177 for details.

4 Use the voicegateway add command to create the voice gateway host using the available physical interface or slot number of the voicegateway card and traffic descriptor.

zSH> voicegateway add 3 td 1 10.10.10.2

zSH> voicegateway add 1-3-1-0/aal5proxy td 1 10.10.10.2

This adds an IP host on the voice gateway card in slot 3 and assigns the IP address 10.10.10.2. The connection uses traffic descriptor 1 and an AAL5 physical interface of aal5proxy. Use the new voip-server-entry command to add the voip-server-entry 255/255 for SIP binding group and multiple SIP server support if that voip-server-entry profile does not already exist. The logical VoIP interface of voip-1-3/ip is created.

Note: The voicegateway add command automatically creates the required ATM VCLs if they do not already exist.

Voicegateway connections created from ZMS create a logical VoIP interface with AAL5 proxy in the name, 1-3-1-0-aal5proxy-0-32.

5 Use the voicegateway show command to display the voice gateway host using the slot number of the voicegateway card or the AAL5 physical interface.

zSH> voicegateway show 3Rd/Address Interface Group T Host Address-----------------------------------------------------1 10.10.10.1 1-3-1-0-aal5proxy-0-32 0/32 0 S 10.10.10.2

zSH> voicegateway show 1-3-1-0/aal5proxyRd/Address Interface Group T Host Address-----------------------------------------------------1 10.10.10.1 1-3-1-0-aal5proxy-0-32 0/32 0 S 10.10.10.2

Configuring voice connections for VoIP to GR303After configuring the voice gateway as an AAL5 proxy on the voice gateway card, the voice connection for VoIP to GR-303 requires adding a VoIP to GR-303 voice connection. This example uses the IP interface voip-1-3/ip with the number 735-0025, name m143-301, destination IP address 172.24.200.143, GR-303 switch protocol, IG 1 and CRV 25. This command also sets the VoIP password in the subscriber-voice-voip profile to password.



1 Use the voice add command to add a VoIP to GR-303 voice connection between the voice gateway card and the switch. Specify the logical VoIP interface (voi-1-3/ip) created with the voicegateway add command. For the PLAR connection, enter the IP address of the GigE port on the uplink card, 172.24.200.143. An optional password is used.

zSH> voice add voip voip-1-3/ip dn 7350025 name m143-301 plar 172.24.200.143 gr303 1/25 pw passwordCreated subscriber-voice 1/330/48Created subscriber-voice-voip 173Created gr303-ig-crv 1/25Created subscriber-voice-gr303 174


ZSH>voice showSubscriber end-point Remote end-point Voice Prof Id STA---------------------------- ----------------------------- --------------voip-1-3/ip DN 7350025 GR303 one/25 1/330/25 ENATotal number of voice connections : 1

Configuring voice connections for VoIP to V5.2After configuring the voice gateway as an AAL5 proxy on the voice gateway card, the voice connection VoIP to V5.2 requires adding a VoIP to V5.2 voice connection.

1 Use the voice add command to add a VoIP to V5.2 voice connection between the voice gateway card and the switch using IG 4 and user port 99. By default, the registration server is set to 0 and the preferred codec is G.711a. An option password is used.

zSH> voice add voip voip-1-3/ip dn 5107777428 name caller pw password v52 4/99 type potsCreated subscriber 1/2Created subscriber-voice 1/2/1Created subscriber-voice-voip 11Created v52-user-port 4/99/2Created subscriber-voice-v52 12


zSH> voice show Subscriber end-point Remote end-point Voice Prof Id STA------------------------------ ------------------------ -------------- ---voip-1-3/ip DN 5107777428 V52 four/99/pots 1/2/1 ENA


POTS to VOIP connections

Configure VoIP server and other VoIP feautures as specified in the Voice over IP (VoIP) connections on page 203. Then, create the POTS to VoIP

Configuring SIP-PRI media gateway


connection sending calls to the IP address of the voicegateway card (in this example 10.10.10.2)

Creating POTS to VoIP connections This example creates a POTS to VoIP subscriber.

1 Use the voice command to add the POTS to VoIP connection. This examples creates a connection with a directory number 510-522-0401 and the name smith. The POTS calls are mapped to the GigE port (ethernet-3) on the uplink card using VLAN100. The VoIP endpoint user name is case sensitive and must match the voice switch requirements, for example AAL/1 for MGCP with the Tekelec T6000 or TP/0001 for Megaco with Nortel CS2K. The PLAR address refers to the unnumbered IP address configured for the voicegateway card.


zSH> voice add pots 1-8-1-0/voicefxs voip ethernet3-100/ip DN 5105220401 name smith plar 10.10.10.2 reg 0 enableCreated subscriber-voice 1/2/1Created subscriber-voice-pots 1004Created subscriber-voice-voip 1005


zSH> voice showSubscriber end-point Remote end-point Voice Prof Id STA------------------------------ ------------------------------ ----------- ---1-8-1-0/voicefxs ethernet3-100/ip DN 5105220401 1/2/1 ENATotal number of voice connections : 1


When running POTS and voicegateway cards in the same chassis, delete all local voice connections before deleting any cards.

.

Configuring SIP-PRI media gatewayThe MALC SIP-PRI media gateway feature enables you to convert TDM call signals from a T1/E1 PRI trunk into SIP (Session Initiation Protocol) VOIP packets. This feature leverages the emergence of SIP networking to unify multiple voice and packet network functions into one entity, providing a more tightly integrated voice and data network.



The SIP-PRI feature can be configured over a T1 or E1 connection. On a T1 connection, SIP-to-PRI is configured with 23 B (Bearer) channels and one D (Data) channel. On an E1 connection, it is configured with 31 B channels and 1 D channel. On an T1 connection, it is configured with 23 bi-directional B (Bearer) channels and one D (Data) channel. SIP-to-PRI is unique in its ability to designate the D channel to handle all of the signaling and call control requirements and leave the remaining B channels free for any mix of voice and either virtual private line or circuit-switched data.

SIP-to-PRI uses the Voice Gateway (VG) card on the MALC to connects two entities:

• VOIP endpoint

• SIP-to-PRI endpoint

The VOIP endpoint can be a SIP phone or soft switch on the other side of the IP network. The SIP-to-PRI endpoint is the far side of the PBX switch where the TDM call signal is converted to an IP packet. The ISDN portion of the entity specifies the PBX endpoint to which the call is connected. The softswitch running VOIP translates the PBX phone number to the IP address targeted for the SIP phone, enabling a phone session over the Internet.

The TDM call data that has been converted into IP packets now is sent to a soft switch instead of the traditional Class V switch. The soft switch treats this data as an VOIP endpoint, instead of a POTS call.



Figure 38: SIP to PRI environment

SIP-PRI configuration involves the following procedures:

• Configuring ISDN signaling and DS1 profiles on page 301

• Verifying voice configuration prerequisites on page 302

• Configure SIP, voicegateway and voice connections on page 302

About the VoIP Endpoint

The primary task in creating a SIP-to-ISDN-PRI network is to create a VOIP endpoint on the MALC. Use both the vg add and voice add commands to create a VOIP endpoint on the MALC.

The vg add command specifies an IP address that acts as the identifier for the card. This information is forwarded either to a soft switch or a SIP phone. This vg command creates connections between the SIP-to-PRI entity and the VOIP interface on the card.

The voice add command includes a directory number, a name, an ISDN signalling profile index, and VoIP server index. The voice add command links the DN on a VOIP connection to a specific SIP-to-PRI port. It correlates a specified value on the VOIP network with a specific SIP-to-PRI. There are

PBX phones

SIP phone

SIP phone

MALC with Uplink-2-GigE card and MALC-VG-T1/E1-32-2S card

IP Network

PBX switch

Soft Switch

PRI over T1/E1 links

GigE



up to 32 physical ports on a VG card. Each port can represent a specific SIP-to-PRI.

ISDN Signaling profile

An ISDN signaling profile is used to specified the type of ISDN signaling used between the MALC and a PBX switch. The isdn-signaling record contains the setting for the switch type. A unique ISDN signaling profile should be configured for each voicegateway card in the MALC.

The ISDN signaling profile is specified in the voice add command to map the PRI’s on the PBX to a the voicegateway card. The ds1-group-number field in the ds1-profile record corresponds to the ISDN signaling profile record.

Note: The MALC currently supports SIP to PRI for NI2 switches.

SIP trunks

SIP-to-ISDN-PRI involves the concept of SIP trunking. The logical voice channel established between carrier voice equipment and an enterprise voice device is called a SIP trunk. SIP trunks enable enterprises to create a single IP connection to carrier networks.

An enterprise TDM PBX peers with a carrier SIP server (soft switch) with the appropriate groupings and security between them. SIP sets up and tears down voice calls to and from the enterprise PBX, converting the Q.931 ISDN call setup and release messages to SIP over the IP data network.

A distinguishing characteristic of a PRI trunk is that it has multiple numbers associated with it. This enables you to aggregate more information than was possible using the standard POTS method that associated only one number per connection.

Hardware requirements

For SIP-to-PRI configurations on a MALC, you need a Voice Gateway (VG) card (for example, MALC-VG-T1/E1-32-2S) installed and an Uplink card with GigE support (for example, MALC-UPLINK-2-GE).

Use a TelcoT1 cable to connect the ports on the PBX card to the ports on the VG card. The following messages appears on the MALC console when the ports are connected:

SEP 06 13:23:31: alert : 1/14/1025: alarm_mgr: alarmMgr.c: _laMgrLogMsg(): l=273 : tLineAlarm: 01:14:02 Critical T1 Up Line 1:14:2:0 (Alarm Cleared)

The showline and showlinestatus commands can also be used to verify the line status.



Configuring ISDN signaling and DS1 profiles1 Using the new isdn-signaling command, create an ISDN signaling

profile for each type of ISDN signaling used between the MALC and the PBX. The MALC currently supports NI2 switch type. The following example creates a signaling value of 1.

The isdn-signaling profile ID is used as the isdnsig value in the voice add voip command.

zSH> new isdn-signaling 1Please provide the following: [q]uit.active-dchannel-location: -> {1}: ** read-only **switch-type: --------------> {NONE(0)}: ni2calling-address: ----------> {}: ""sub-address: --------------> {}: ""number-of-bchannels: ------> {24}:enable-traps: -------------> {disabled}:....................Save new record? [s]ave, [c]hange or [q]uit: s New record saved.

2 Associate each DS1 profile to a ISDN signal profile based on the ds1-group-number in the ds1-profile. This association maps the PRIs on the PBX to the configured voice gateway card.

zSH> new ds1-profile 1-3-1-0/ds1line-type: ----------------------> {esf}line-code: ----------------------> {b8zs}send-code: ----------------------> {sendnocode}circuit-id: ---------------------> {ds1}loopback-config: ----------------> {noloop}signal-mode: --------------------> {robbedbit} messageorientedfdl: ----------------------------> {fdlnone}dsx-line-length: ----------------> {dsx0}line-status_change-trap-enable: -> {enabled}channelization: -----------------> {enabledds0}ds1-mode: -----------------------> {csu}csu-line-length: ----------------> {csu00}clock-source-eligible: ----------> {eligible} noteligibletransmit-clock-source: ----------> {looptiming}cell-scramble: ------------------> {true}coset-polynomial: ---------------> {true}protocol-emulation: -------------> {network}signal-type: --------------------> {loopstart}ds1-group-number: ---------------> {0} 1 (maps to ISDN signal profile)line-power: ---------------------> {disabled}timeslot-assignment: ------------> {0+1+2+3+4+5+6+7+8+9+10+11+12+13+14+15+16+17+18+19+20+21+22+23} ....................Save new record? [s]ave, [c]hange or [q]uit: s New record saved.

3 Verify D channel status.



zSH> isdnsigctrp show dchan 1unit 1: D-Channel UP [ifIndex 683]

Verifying voice configuration prerequisitesBefore configuring the voice gateway connection, use the following procedures to ensure that the configuration prerequisites have been configured.

1 Use the slots command to verify the desired uplink and voice gateway card installation and status. This example shows the Uplink-T1/E1-ATM/TDM/IP-16 card running in slot 1 and the MALC voice gateway card running in slot 3. Other line cards can be inserted and running in other slots as desired.

zSH> slots 1: MALC UPLINK T1/E1 TDMF (RUNNING) 3: MALC T1E132VG (RUNNING)13: MALC GSHDSL (RUNNING)17: MALC ADSL + POTS AC6 (RUNNING)

2 Check the system settings to ensure the appropriate country coding and other system-level settings are configured. See Updating system settings on page 198 for details.

3 Ensure there is an active system clock source. See the MALC Hardware Installation Guide.



Configure SIP, voicegateway and voice connectionsThis procedure creates the voip-server-entry, SIP dialplans, and configures the voicegateway and voice connections.



1 Create a VOIP server ID, using the new voip-server-entry command. A VOIP server entry describes a particular soft switch which handles a VOIP protocol like SIP, MGCP, or Megaco. The following example assumes an entry of 255/255 for a SIP binding group.

zSH> new voip-server-entry 255/255Please provide the following: [q]uit.zhoneVoipServerAddrType: ----------> {ipv4}:zhoneVoipServerAddr: --------------> {}: 172.16.88.9zhoneVoipServerUdpPortNumber: -----> {5060}:zhoneVoipServerId: ----------------> {generic}: metaswitchprotocol: -------------------------> {sip}:sendCallProceedingTone: -----------> {false}:rtcpEnabled: ----------------------> {false}:rtcpPacketInterval: ---------------> {5000}:interdigitTimeOut: ----------------> {10}:ipTos: ----------------------------> {0}:systemDomainName: -----------------> {}:expires-invite-value: -------------> {3600}:expires-register-value: -----------> {3600}:expires-header-method: ------------> {register}:session-timer: --------------------> {off}:session-expiration: ---------------> {180}:session-min-session-expiration: ---> {180}:session-caller-request-timer: -----> {no}:session-callee-request-timer: -----> {no}:session-caller-specify-refresher: -> {omit}:session-callee-specify-refresher: -> {uac}:dtmf-mode: ------------------------> {rfc2833}:....................Save new record? [s]ave, [c]hange or [q]uit: s New record saved.

2 Create a SIP dial plan using the new sip-dialplan command. A SIP dial plan maps incoming digits to a particular VOIP server. The dial plans allow the MALC to establish the VOIP end of the call. Based on the dial plan, the MALC also rejects digit strings that don’t match those specified in the dial plan. The dial plan also enables communication between the SIP phone and the provisioned soft switch. The following example uses 1 as the ID of the SIP dial plan and specifies a voip-server-entry-index of 0 to reference the SIP binding group.

zSH> new sip-dialplan 1Please provide the following: [q]uit.match-string: ----------------> {}: 0sip-ip-address: --------------> {0.0.0.0}: 172.16.88.9destination-name: ------------> {}:number-of-digits: ------------> {0}: 10prefix-strip: ----------------> {0}:prefix-add: ------------------> {}: 510777395dialplan-type: ---------------> {normal}:voip-server-entry-index: -----> {0}: (0 indicates SIP binding group)override-interdigit-timeout: -> {0}:



....................Save new record? [s]ave, [c]hange or [q]uit: s New record saved.


zSH> new ip-interface-record vg/ipvpi: ---------------> {0}:vci: ---------------> {0}:rdindex: -----------> {1}:dhcp: --------------> {none}: ** read-only **addr: --------------> {0.0.0.0}: 10.10.10.1netmask: -----------> {0.0.0.0}: 255.255.255.0bcastaddr: ---------> {0.0.0.0}: 10.10.10.255destaddr: ----------> {0.0.0.0}:farendaddr: --------> {0.0.0.0}:mru: ---------------> {1500}:reasmmaxsize: ------> {0}:ingressfiltername: -> {}:egressfiltername: --> {}:pointtopoint: ------> {no}:mcastenabled: ------> {yes}:ipfwdenabled: ------> {yes}:mcastfwdenabled: ---> {yes}:natenabled: --------> {no}:bcastenabled: ------> {yes}:ingressfilterid: ---> {0}:egressfilterid: ----> {0}:ipaddrdynamic: -----> {static}:dhcpserverenable: --> {false}:subnetgroup: -------> {0}:unnumberedindex: ---> {0}:mcastcontrollist: --> {}:vlanid: ------------> {0}:maxVideoStreams: ---> {0}:....................Save new record? [s]ave, [c]hange or [q]uit: sCould not find an appropropriate interface on which to bind the IP record.



zSH> new ip-unnumbered-record 1ipUnnumberedInterfaceName: -> { }: vg/ip....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.



5 Assign an address and add values to the VG card by issuing the vg add command. The following example uses an VG IP address of 10.10.10.1 and a TD of 1.

zSH> vg add -v 14 td 1 10.10.10.1Reading unnumbered profile 1Reading ip-interface profile ifIndex 773Reading unnumbered profile 2Reading ip-interface profile ifIndex 1053Using UNI record 2, ip interface record IfIndex 1053Created proxy atm-vcl 1-1-1-0-aal5proxy VC 0/34Created remote atm-vcl 1-14-1-0-aal5proxy VC 0/32Created cross connect index 5IP record IfIndex is 1054Created near end ip-interface-record 1-14-1-0-aal5proxy-0-34/ipStack bind near end i/f 1-14-1-0-aal5proxy-0-34/ip to RFC14831-1-1-0-aal5proxy successfulChecking to see if 1-14-1-0-aal5proxy-0-34-1/ip exists.Interface 1-14-1-0-aal5proxy-0-34-1/ip does not existIfIndex <= 0IP record IfIndex is 1055Stack binding of 1-14-1-0-aal5proxy-0-34-1/ip interface was successful.IP record IfIndex is 1056

6 Add the voice connection using the voice add voip command. This command creates the VOIP connection and enables the PRI-ISDN endpoint to communicate to the VOIP endpoint. The example assumes a directory number of 5107773950.

zSH> voice add voip voip-1-14/ip dn 5107773950 name 5107773950 reg 0 isdnsig 1Created subscriber 1/642Created subscriber-voice 1/642/1Created subscriber-voice-voip 11Created subscriber-voice-isdnsig 12

7 Display the subscriber voice ISDN signature by issuing the get subscriber-voice-isdnsig command. The following example assumes a subscriber voice ISDN signature of 12. The ISDN signature is displayed in the output of the voice add voip command.

zSH> get subscriber-voice-isdnsig 12voice-isdn-sig-index: -> {1}directory-number: -----> {5107773950hunt-group-index-1: ---> {0}hunt-group-index-2: ---> {0}hunt-group-index-3: ---> {0}



The SIP-to-PRI feature enables you to convert TDM call signals from a T1/E1 PRI trunk into SIP (Session Initiation Protocol) VOIP packets. It takes advantage of the emergence of SIP networking and how it can achieve new efficiencies in network use and application deployment.


CONFIGURING GPON DATA,VOICE, AND VIDEO

This chapter explains how to configure voice, video, and data connections between the MALC-GPON-SC1 card and the Zhone zNID. It includes the following sections:

GPON configurationThe MALC supports configuring GPON voice, data, and video connections between the MALC-GPON-SC-1 card and the Zhone zNID CPE.

By default, the following VLANs are configured on the Zhone zNID:

• VLAN 100 for video traffic

• VLAN 200 for data traffic

• VLAN 300 for VoIP and management traffic

Example GPON configurations specifying the gponport 502:

zSH> host add 1-8-1-502/gponport vlan 100 dynamic 43 5 video 1/5Adding host for 1-8-1-502/gponport

zSH> bridge add 1-8-1-502/gponport downlink vlan 200 tagged Adding bridge on 1-8-1-502/gponportCreated bridge-interface-record 1-6-1-564-gponport-200/bridge

zSH> host add 1-8-1-502/gponport vlan 300 static 172.25.44.64Adding host for 1-8-1-502/gponport

Configuring GPON Data,Voice, and Video



DIAGNOSTICS AND ADMINISTRATION

This chapter describes tasks you might need to perform to administer the MALC. It includes the following information:

• Log message format, page 310

• SNMP, page 319

• Statistics and alarms, page 322

• System maintenance, page 337

• Testing, page 353

LoggingThis section explains how to use logging on the MALC. It includes:


• Enabling/disabling logging on page 310

• Log message format on page 310

• Modifying logging levels on page 312

• Using the log cache on page 313

• Sending messages to a syslog server on page 314

• Specifying different log formats for system and syslog messages on page 316

• Example log messages on page 318

• Log filter command on page 318

Overview

Logging enables administrators to monitor system events by generating system messages. It sends these message to:

• A management session (either on the serial craft port or over a telnet session)

• A log file on the device

Diagnostics and Administration


• A syslog server (optional)

The type of information sent in these messages can be configured using the log command. By default, the system sends the same type of information to all log message destinations. If you want to send different types of messages to the syslog daemon, use the syslog command.

Enabling/disabling logging

By default, log messages are enabled on the serial craft port. Use the log session command and the log serial command to enable/disable logging:

The log session command enables/disables logging messages for that session only. If the user logs out, the logging setting returns to the default. To enable logging for the current session only:zSH> log session on

To disable logging for the session:zSH> log session off

The log serial command enables/disables logging messages for all sessions on the serial craft port. This setting persists across system reboots. To enable/disable logging for the serial craft port:zSH> log serial on

To disable logging for the serial port:zSH> log serial off

Log message format

Log messages contain the following information:Table 11: Default log message fields

Option Description

Date Date stamp of log message. Enabled by default.

Time Time stamp of log message. Enabled by default.

Ticks Current tick count. When the tick option is used, the date and time fields are not displayed.

Level Logging level of the message. Enabled by default.

Address The shelf and slot of the card causing the alarm,

Taskname Name of task that generated the log message. This is generally useful only for Zhone development engineers. Enabled by default.

Function Function that generated the log message. This is generally useful only for Zhone development engineers.

Logging


To change the information displayed in the log messages, use the log option command. First, display the available options:

zSH> log optionUsage: log option < time | 1 > < on | off >

< date | 2 > < on | off >< level | 3 > < on | off >< taskname | 4 > < on | off >< taskid | 5 > < on | off >< file | 6 > < on | off >< function | 7 > < on | off >< line | 8 > < on | off >< port | 9 > < on | off >< category | 10 > < on | off >< system | 11 > < on | off >< ticks | 12 > < on | off >< all | 13 > < on | off >< default | 14 > < on | off >

time: date: level: address: log: port: category: system: (0x707)

Then, turn the option on or off. For example, the following command will turn the task ID off in log messages:

zSH> log option taskid offtime: date: level: address: log: taskname: (0xf)

The following commands will turn ton/off the tick count display in log messages:

zSH> log option ticks ontime: date: level: address: log: port: category: system: ticks: (0xf07)

zSH> log option ticks offtime: date: level: address: log: port: category: system: (0x707)

Line Line in code that generated the log message. This is generally useful only for Zhone development engineers.

Port Port related to the log message.

Category Category of the log message.

System System related to the log message.

All Controls all log message options.

Default Controls the default log message options.

Message text A description of the error that caused the alarm.

Table 11: Default log message fields (Continued)

Option Description



The following command will turn all options on in log messages:

zSH> log option all ontime: date: level: address: log: taskname: taskid: file: function: line: port: category: system: ticks: (0xfff)

Modifying logging levels

To modify logging, use the log command. To modify syslog messages, use the syslog command.

To display the current levels for all logging modules, use the log show command:

zSH> log showMODULE LEVEL STATUSaal2approv error enabledaal2aprec error enabledaal2rp error enabled aal2rpzccapi error enabled aal2rpvcc error enabledalarm_mgr error enabledassert error enabledatm_cc_mib_hdlr error enabledatmmgr error enabledatmmgragnt error enabledbds error enabledbds_client error enabledcallcontrolregistry error enabledcard error enabledcard_resource error enabledcarddeletehdlr error enabledccrp error enabledcli error enabled.........

Logging levels determine the number of messages that are displayed on the console. The higher the log level, the more messages are displayed. The MALC supports the following log levels:

• 1: emergency

• 2: alert

• 3: critical

• 4: error

• 5: warning

• 6: notice

• 7: information

Logging


• 8: debug

To change the log level, use the log module level command. For example, the following command changes the card module logging level to emergency:zSH> log level card emergencyModule: card at level: emergency

To enable or disable log levels for a module, use the log enable or log disable commands. For example:zSH> log disable cardModule: card is now disabled

Using the log cache

The log cache command displays the non-persistent log messages. It uses the following syntax:log cache

Displays the log cache.log cache max length

Sets the maximum number of log messages to store. The maximum log cache size is 2147483647, depending in the amount of memory available. log cache grep pattern

Searches through the log cache for the specified regular expression.log cache clear

Clears the log cache.log cache size

Sets the maximum amount of memory for the log cache. Without options, displays the current log size. log cache help

Displays help on the log cache command.

ExamplesTo change the current configured log cache size:

zSH> log cache max 200 Maximum number of log messages that can be saved: 200

The following example searches through the log cache for the string “Major”:

zSH> log cache grep MajorSearching for: "Major"[1]: FEB 07 11:18:42: alert : 1/1/1025: alarm_mgr: tLineAlarm: 01:01:01 Major DS1 Down Line 1:1:1:0 (FarEnd Rx LOF)[2]: FEB 07 11:18:42: alert : 1/1/1025: alarm_mgr: tLineAlarm: 01:01:02 Major D



S1 Down Line 1:1:2:0 (FarEnd Rx LOF)[3]: FEB 07 11:18:42: alert : 1/1/1025: alarm_mgr: tLineAlarm: 01:01:03 Major DS1 Down Line 1:1:3:0 (FarEnd Rx LOF).........

Viewing the persistent logs

Use the log cache command to view the persistent logs. For example:

zSH> log cache[1]: JAN 13 17:23:40: alert : 1/6/1025: alarm_mgr: tLineAlarm: 01:06:18 Minor DSL Down DSL line[2]: JAN 13 17:23:40: alert : 1/5/1025: alarm_mgr: tLineAlarm: 01:05:26 Minor DSL Down DSL line[3]: JAN 13 17:23:40: alert : 1/5/1025: alarm_mgr: tLineAlarm: 01:05:27 Minor DSL Down DSL line[4]: JAN 13 17:23:40: alert : 1/6/1025: alarm_mgr: tLineAlarm: 01:06:20 Minor DSL Down DSL line[5]: JAN 13 17:23:41: alert : 1/6/1025: alarm_mgr: tLineAlarm: 01:06:21 Minor DSL Down DSL line[6]: JAN 13 17:23:41: alert : 1/6/1025: alarm_mgr: tLineAlarm: 01:06:22 Minor DSL Down DSL line[7]: JAN 13 17:23:41: alert : 1/6/1025: alarm_mgr: tLineAlarm: 01:06:25 Minor DSL Down DSL line[8]: JAN 13 17:23:41: alert : 1/6/1025: alarm_mgr: tLineAlarm: 01:06:29 Minor DSL Down DSL line[9]: JAN 13 17:23:41: alert : 1/6/1025: alarm_mgr: tLineAlarm: 01:06:32 Minor DSL Down DSL line[10]: JAN 13 17:23:41: alert : 1/6/1025: alarm_mgr: tLineAlarm: 01:06:31 MinorDSL Down DSL line[11]: JAN 13 17:23:42: alert : 1/6/1025: alarm_mgr: tLineAlarm: 01:06:37 MinorDSL Down DSL line.........

Sending messages to a syslog server

Modify the following parameters in the syslog-destination profile to send messages to a syslog server.

Logging


zSH> new syslog-destination 1Please provide the following: [q]uit.address: --> {0.0.0.0}: 192.200.42.5 IP address of the syslog serverport: -----> {514}: leave at defaultfacility: -> {local0}:severity: -> {debug}:....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.


address The IP address of the machine hosting the syslog server. Default: 0.0.0.0

port The UDP port to which the syslog messages will be sent. Default: 514

facility The syslog facility to which the syslog messages will be sent. Values: local0 local1local2local3local4local5local6local7no-mapDefault: local0

severity The severity level used to filter messages being set to the syslog server.Values: emergencyalertcriticalerrorwarningnoticeinfodebugDefault: debug



Specifying different log formats for system and syslog messages

The log-module profile supports the configuration of persistent log messages, syslog messages, and persistent storage levels by module. You only need to modify this profile if you want to send different messages to admin sessions, the persistent logs, and the syslog server.


name The name of the module whose logging is controlled by this profile.Default: logtest

display Controls the display of messages on the system. Messages logged at this level and above will be displayed.Values: emergencyalertcriticalerror warning notice info debugDefault: error

Logging


zSH> new log-module 1Please provide the following: [q]uit.name: ----> {logtest}: test1display: -> {error}: warningsyslog: --> {trackdisplay}: store: ---> {trackdisplay}:.................... Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

syslog Controls the format of messages sent to the syslog server described in the syslog-destination profile. This field is similar to the display field, except for the trackdisplay value.Values: emergencyalertcriticalerror warning notice info debugtrackdisplay Messages logged at, and above, the level set in the display parameter will also be recorded in the syslog server.Default: trackdisplay

store Controls the persistent storage of messages. This field is similar to the display field, except for the trackdisplay value.Values: emergencyalertcriticalerror warning notice info debugtrackdisplay Messages logged at, and above, the level set in the display parameter will also be recorded in the syslog server.Default: trackdisplay




Example log messages

This section provides examples of how to interpret log messages.

DSL line down messageThe following message appears when a DSL line comes up or goes down.

.

The most important parts of the message are the date and time the event occurred, the shelf/slot of the event, and the message text. The remainder of the information is only useful for Zhone development engineers.

Slot card up messageThe next message appears after a slot card has finished loading its software and is ready to be provisioned.

The most important parts of the message are the date and time the event occurred, the shelf/slot of the event, and the message text. The remainder of the information is only useful for Zhone development engineers.

Log filter command

The log filter command is available as part of the log command functionality. This command enables users to show, set and delete log filters. Log filters limit the scope of log messages to a specific entity for troubleshooting and diagnostics. When a log filter is set, the filter is assigned an index number and

1 [1]: JAN 07 09:25:42: alert : 1/8/1025: alarm_mgr: _laMgrLogMsg(): l=261 :

tLin eAlarm: 01:08:03 Minor DSL Down DSL line

Date and time Log level physical address (shelf/slot)

Message text

task name function name line number

[24]: JAN 05 20:12:28: notice : 1/2/12 : shelfctrl: _CardUpdateMsgProcess(): l= 381 : tShelfCtrl: Card in slot 1 changed state to RUNNING.

Date and time Log level physical address (shelf/slot)

Message text

task name function name line number

SNMP


only messages relate the specified entity are displayed. Filters can be set for an specific ifindex, slot/port, VCL, or subscriber.

log filter

Restrict the display of log messages to only the log messages for a specified entity.

Syntax log filter show | set (ifindex|port slotport|vcl ifindex vpi vci|subscriber endpoint)| delete

zSH> log filter set ifindex 12New filter saved.

zSH> log filter set port 5 24New filter saved.

zSH> log filter set vcl 100 0 1New filter saved.

zSH> log filter set subscriber 22New filter saved.

zSH> log filter showIndex Type Filter Parameters------ ------------ ----------------------------- 1 Port slot=1, port=1 2 Port slot=1, port=4 3 IfIndex IfIndex=12 4 Port slot=5, port=24 5 ATM VCL IfIndex=100, vpi=0, vci=1 6 IfIndex IfIndex=100 7 IfIndex IfIndex=104 8 IfIndex IfIndex=109 9 IfIndex IfIndex=10310 IfIndex IfIndex=107

zSH> log filter delete 10

Log filter 10 deleted

SNMPThis section describes the following:

• Creating SNMP community names and access lists, page 320

• Configuring traps, page 321



Creating SNMP community names and access lists

Note: By default, the MALC has a single SNMP community defined with the name ZhonePrivate. This community has admin access to the system. Zhone recommends that you configure community names and access lists to prevent unauthorized access to the system.

The community-profile specifies the community name and an access level for SNMP manager to access the system. It can also optionally specify a community-access-profile which is used to verify the source IP address of the SNMP manager. The system supports up to 50 different access lists.

The following community access levels are supported:

• noaccess—the community has no access.

• read—the community has read-only access to the system, with the exception of information in the community-profile and community-access-profile.

• readandwrite—the community has read/write access to the system, with the exception of information in the community-profile and community-access-profile.

• admin—the community has read and write access to the entire system, including information in the community-profile and community-access-profile. Note that the ZMS requires admin access to manage the system.

Creating a community profile

Note: Configuring a community profile disables the ZhonePrivate default community name. If you do change the community name, you must change the name in ZMS or the device will become unmangeable.

The following example defines a community name public with read-only privileges:

zSH> new community-profile 1Please provide the following: [q]uit.community-name: -----> {}: publicpermissions: --------> {read}:access-table-index: -> {0}:....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Creating community access listsThe following example defines a community name private with read/write privileges and also creates an access list to verify that the SNMP managers

SNMP


attempting to access the MALC are coming from known IP addresses 192.168.9.10 and 192.168.11.12:

First, create an access list for the first IP address:zSH> new community-access-profile 2Please provide the following: [q]uit.access-table-index: -> {0}: 1ip-address: ---------> {0.0.0.0}: 192.168.9.10....................Save new record? [s]ave, [c]hange or [q]uit: s New record saved.

Then, create an access list for the second IP address with the same access-table-index (1):zSH> new community-access-profile 3Please provide the following: [q]uit.access-table-index: -> {0}: 1ip-address: ---------> {0.0.0.0}: 192.168.11.12....................Save new record? [s]ave, [c]hange or [q]uit: s New record saved.

Finally, create a community-profile that specifies the community name, and uses the same access-table-index (1) as defined in the two community-access-profiles you just created:

zSH> new community-profile 4Please provide the following: [q]uit.community-name: -----> {}: private ZMS must include this namepermissions: --------> {read}: readandwriteaccess-table-index: -> {0}: 1....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Configuring traps

The trap-destination profile defines a trap recipient the MALC will send traps to. To configure a trap destination you need to know:

• the IP address of the SNMP manager workstation

• the community name the trap recipient expects

Note that the resendseqno and ackedseqno parameters are set by the ZMS. The other parameters in the trap-destination profile can be left at their default values. The following example configures a trap recipient with the IP address 192.168.3.21:

zSH> new trap-destination 32Please provide the following: [q]uit.trapdestination: -> {0.0.0.0}: 192.168.3.21communityname: ---> {}: public



resendseqno: -----> {0}:ackedseqno: ------> {0}:traplevel: -------> {low}:traptype: --------> {(null)}: 0trapadminstatus: -> {enabled}:....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Statistics and alarmsThis section describes the following:

• Bulk statistics on page 322

• Alarm manager on page 327

• Alarm suppression on page 336

Bulk statistics

The MALC can be configured to collect statistics and transfer them to an FTP server. Any supported SNMP OID can be collected.

1. Every 15 minutes, the MALC gathers the specified statistics.

If a statistic is not collected, the MALC sends a ZhoneBulkStatisticsIndividualStatFailure trap to the designated trap recipient.

2. The statistics files are stored on the local flash card with the following filename:

Device-IP_timestamp

where timestamp is in the form YYYY.DD.MM.HH.MM in the device local time. For example:192.168.80.291_2002.11.06.14.37

3. The MALC compresses the files and attempts to send them to the FTP server.

– If the files transfer is successful, the files on the local flash card are deleted.

– If the file transfer is not successful, the MALC will:

a. Send a ZhoneBulkStatisticsIntervalFailure trap to the designated trap recipient.

b. Periodically attempt to reach the FTP server.

c. Continue to collect statistics every 15 minutes, writing a new statistics file to the flash card for every interval, if there is sufficient space on the flash disk.

d. When the FTP server is available, the MALC transfers all remaining files to the FTP server and deletes them from the flash card.

Statistics and alarms


Bulk statistics file formatIf the statistics collected include children, the bulk statistic file uses the following format:

#Version##SysObjectOID#BeginCollectionRecord*<CollectionId><space><CollectionInterval><space><OID><space><InstanceId>1=value12=value2.........n=valuen#EndCollectionRecord#EndFile

where value1, value2, and so on are the SNMP instances for the OID.

If the statistics collected does not include children, the bulk statistic file uses the following format:

#Version##SysObjectOID#BeginCollectionRecord*<CollectionId><space><CollectionInterval><space><OID><space><InstanceId>#EndCollectionRecord#EndFile

For example, if you set up the system collect statistics for an ATM VCL with an Ifindex of 123 and a VPI/VCI of 0/36 and include the child objects, the statistic file would look similar to the following:

#VersionNumber# #Device 1.3.6.1.4.1.5504.4.2.2.5.1#BeginCollectionRecord1000 ZhoneAtmStatsExtEntry 123.0.361=1352=153=83094=832095=236=7877=8438=38209#EndCollectionRecord#EndFile

Where values 1 to 8 are the ZhoneAtmStatsExtEntry entries:

zhoneAtmStatsTotalInitialCellsRx

zhoneAtmStatsTotalFabricCellsRx

zhoneAtmStatsTotalFinalCLP0CellsRx



zhoneAtmStatsTotalFinalCLP1CellsRx

zhoneAtmStatsTotalInitalCellsTx

zhoneAtmStatsTotalFabricCellsTx

zhoneAtmStatsTotalFinalCLP0CellsTx

zhoneAtmStatsTotalFinalCLP1CellsTx

Configuring bulk statistics

Note: You must configure the FTP password used by bulk statistics using ZMS or the Zhone genSystem MIB.

To configure bulk statistics:

1 Create a bulk-statistic record for the statistics you want to gather. For example, to collect ATM VCL statistics:

zSH> new bulk-statistic 1Please provide the following: [q]uit.enabled: ----------> {true}:oid: --------------> {}: ZhoneAtmStatsExtEntryinstance: ---------> {}: 136 ifIndex of ATM interfaceinclude-children: -> {false}: true....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

2 Update the bulk-statistics-config 0 profile to specify the FTP server information:

zSH> update bulk-statistics-config 0Please provide the following: [q]uit.bulk-statistics-enabled: -> {false}: trueftp-server-address: ------> {0.0.0.0}: 192.168.8.100ftp-login: ---------------> {}: zhoneuserftp-password: ------------> {**private**}:**read-only** must be configured using SNMP or ZMSftp-directory-path: ------> {}: /stats....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

Bulk statistics exampleThis example explains how to configure bulk statistics to gather the following SNMP statistics:

ZhoneAtmStatsExtEntry object in the comAtm MIB:

1: zhoneAtmStatsTotalInitialCellsRx

2: zhoneAtmStatsTotalFabricCellsRx



3: zhoneAtmStatsTotalFinalCLP0CellsRx

4: zhoneAtmStatsTotalFinalCLP1CellsRx

5: zhoneAtmStatsTotalInitalCellsTx

6: zhoneAtmStatsTotalFabricCellsTx

7: zhoneAtmStatsTotalFinalCLP0CellsTx

8: zhoneAtmStatsTotalFinalCLP1CellsTx

zhoneDslPerfDataTotalEntry in the phyDsl MIB:

1: zhoneDslPerfTotalLofs

2: zhoneDslPerfTotalLoss

3: zhoneDslPerfTotalLols

4: zhoneDslPerfTotalInits

5: zhoneDslPerfTotalES

6: zhoneDslPerfTotalSES

7: zhoneDslPerfTotalCRCAnomalies

8: zhoneDslPerfTotalLOSWS

9: zhoneDslPerfTotalUAS

To get these statistics:

1 Get the ifIndex for the trunking interface:

zSH> ifxlate 1-1-1-0-sonet/atmifIndex: ----------> {8} shelf: ------------> {1}slot: -------------> {2}port: -------------> {1}subport: ----------> {0}type: -------------> {sonet}adminstatus: ------> {up}physical-flag: ----> {true}iftype-extension: -> {none}ifName: -----------> {1-1-1-0}

2 Get the ifIndex for the subscriber interface:

zSH> ifxlate 1-7-1-0/adslifIndex: ----------> {136}shelf: ------------> {1}slot: -------------> {7}port: -------------> {1}subport: ----------> {0}type: -------------> {adsl}adminstatus: ------> {up}physical-flag: ----> {true}iftype-extension: -> {none}ifName: -----------> {1-7-1-0}



3 Update the bulk-statistics-config profile to specify the FTP server:

zSH> update bulk-statistics-config 0Please provide the following: [q]uit.bulk-statistics-enabled: -> {false}: trueftp-server-address: ------> {0.0.0.0}: 192.168.80.201ftp-login: ---------------> {}: usernameftp-password: ------------> {** private **}: ** read-only **ftp-directory-path: ------> {}: stats....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

4 Modify the zhoneBulkStatsSystemFtpPassword object in the genSystem MIB to change the FTP password.

5 Create a bulk-statistic profile for the trunking interface. Set include-children to true to gather all the child statistics for this object:

zSH> new bulk-statistic 1Please provide the following: [q]uit.enabled: ----------> {true}:oid: --------------> {}: zhoneAtmStatsExtEntryinstance: ---------> {}: 1635 ifIndex of the ATM interfaceinclude-children: -> {false}: true....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

6 Create a bulk-statistic profile for the subscriber interface. Set include-children to true to gather all the child statistics for this object:

zSH> new bulk-statistic 2Please provide the following: [q]uit.enabled: ----------> {true}:oid: --------------> {}: zhoneDslPerfDataTotalEntryinstance: ---------> {}: 136 ifIndex of DSL interfaceinclude-children: -> {false}: true....................Save new record? [s]ave, [c]hange or [q]uit: sNew record saved.

IF-Name in bulk stats (32 character limit)The MALC supports customized interface names using up to 32 characters. The customized name appears in bulk statistics and other output displaying interface names.

To customize an interface name, update the ifName parameter in the if-translate profile for the interface.

zSH> update if-translate 1-1-1-0/ethif-translate 1-1-1-0/ethPlease provide the following: [q]uit.ifIndex: -----------> {1}:



shelf: -------------> {1}:slot: --------------> {1}:port: --------------> {1}:subport: -----------> {0}:type: --------------> {eth}:adminstatus: -------> {up}:physical-flag: -----> {true}:iftype-extension: --> {none}:ifName: ------------> {1-1-1-0}:[interfacename upto 32 characters]redundancy-param1: -> {0}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Example bulk statistics with 1-1-1-0/eth interface name.

1.01.3.6.1.4.1.5504.1.6.2#BeginCollectionRecord1 15 ifHCOutUcastPkts 1(1-1-1-0/eth)=0,29154#EndCollectionRecord#BeginCollectionRecord2 15 ifHCInUcastPkts 1(1-1-1-0/eth)=0,23837#EndCollectionRecord#BeginCollectionRecord3 15 ifHCInOctets 1(1-1-1-0/eth)=0,2814554#EndCollectionRecord

Alarm manager

The MALC central alarm manager includes the ability to view the active alarms on the system (using the alarm command) and the ability to store active alarms on the device. ZMS can use the alarms stored on the device to recreate the state of the alarms if it becomes disconnected.

The alarm command uses the following syntax:alarm show [summary]

For example, the following command displays the number of current active alarms, the total number of alarms, the number of cleared alarms, as well as each active alarm and its severity:

zSH> alarm show************ Central Alarm Manager ************ ActiveAlarmCurrentCount :21 ActiveAlarmTotalCount :42 ClearAlarmTotalCount :21 OverflowAlarmTableCount :0

ResourceId AlarmType AlarmSeverity---------- --------- -------------1-5-2-0/adsl linkDown minor 1-5-3-0/adsl linkDown minor 1-5-4-0/adsl linkDown minor



1-5-5-0/adsl linkDown minor 1-5-6-0/adsl linkDown minor 1-5-7-0/adsl linkDown minor 1-5-8-0/adsl linkDown minor 1-5-17-0/adsl linkDown minor 1-5-18-0/adsl linkDown minor 1-5-19-0/adsl linkDown minor 1-5-20-0/adsl linkDown minor 1-5-21-0/adsl linkDown minor 1-5-22-0/adsl linkDown minor 1-5-23-0/adsl linkDown minor 1-5-24-0/adsl linkDown minor 1-2-1-0/sonet linkDown critical 1-2-2-0/sonet linkDown critical 1-2-1-0/sonet sonetSectionStatusChange major 1-2-2-0/sonet sonetSectionStatusChange major 1-2-1-0/sonet sonetLineStatusChange major 1-2-2-0/sonet sonetLineStatusChange major

The summary option displays the number of current active alarms, the total number of alarms, the number of cleared alarms:

zSH> alarm show summary

************ Central Alarm Manager ************ ActiveAlarmCurrentCount :3 ActiveAlarmTotalCount :3 ClearAlarmTotalCount :0 OverflowAlarmTableCount :0

Supported alarmsThe alarms reported by the alarm show command are based on traps. When these traps are received by ZMS, they generate ZMS alarms.

The following alarms are supported.

Table 12: Supported alarms

Alarm Description

aal2ExternalAIS Alarm Indication Signal associated with a maintenance alarm detected.

aal2ExternalRAI Remote Alarm Indication detected to constitute a received signal failure.

aal2InternalAIS Alarm Indication Signal detected affecting the AAL type 2 connection.

aal2InternalRDI Remote Defect Indication detected affecting the AAL type 2 connection.

aal2PerfCellLossThreshTrap A bad sequence error is detected when some cells have been lost.



aal2PerfCongestionThreshTrap The number of congestion events exceed the congestion threshold.

aal2PvcDown The status of AAL type 2 PVC has gone down.

adslAtucInitFailureTrap Near end modem (ATUC) failure during initialization.

adslAtucPerfESsThreshTrap Errored Second 15-minute interval threshold reached on near end modem (ATUC)

adslAtucPerfLofsThreshTrap Loss of Framing 15-minute interval threshold reached on near end modem (ATUC)

adslAtucPerfLolsThreshTrap Loss of Link 15-minute interval threshold reached on near end modem (ATUC)

adslAtucPerfLossThreshTrap Loss of Signal 15-minute interval threshold reached on near end modem (ATUC)

adslAtucPerfLprsThreshTrap Loss of Power 15-minute interval threshold reached on near end modem (ATUC)

adslAtucRateChangeTrap Near end modem (ATUC) transmit rate changed from adslAtucChanPrevTxRate to adslAtucChanCurrTxRate

adslAturPerfESsThreshTrap Errored Second 15-minute interval threshold reached on far end modem (ATUR)

adslAturPerfLofsThreshTrap Loss of Framing 15-minute interval threshold reached on far end modem (ATUR)

adslAturPerfLossThreshTrap Loss of Signal 15-minute interval threshold reached on far end modem (ATUR)

adslAturPerfLprsThreshTrap Loss of Power 15-minute interval threshold reached on far end modem (ATUR)

adslAturRateChangeTrap Far end modem (ATUR) transmit rate changed from adslAturChanPrevTxRate to adslAturChanCurrTxRate

apsEventChannelMismatch An APS channel mismatch between the transmitted K1 channel and the received K2 channel has occurred.

apsEventFEPLF An APS Far-End Protection-Line Failure (FEPLF) has occurred. This condition is declared based on receiving signal failure (SF) on the protection line in the K1 byte.

Table 12: Supported alarms (Continued)

Alarm Description



apsEventModeMismatch An APS event mode mismatch has occurred.A conflict between the current local mode and the received K2 mode information constitutes a mode mismatch.

apsEventPSBF An APS Protection Switch Byte Failure (PSBF) has occurred.This condition occurs when either an inconsistent APS byte or an invalid code is detected. An inconsistent APS byte occurs when no three consecutive K1 bytes of the last 12 successive frames are identical, starting with the last frame containing a previously consistent byte. An invalid code occurs when the incoming K1 byte contains an unused code or a code irrelevant for the specific switching operation (that is., Reverse Request while no switching request is outstanding) in three consecutive frames. An invalid code also occurs when the incoming K1 byte contains an invalid channel number in three consecutive frames.

apsEventSwitchover The number of times this channel has switched to the protection line.

atmDsx3PlcpAlarmStatusChange

The DS3 Physical Layer Convergence Procedure (PLCP) has received an alarm.

atmInterfaceTCAlarmStateChange

ATM Interface TC Sublayer is currently in the Loss of Cell Delineation defect maintenance state.

atmOamF4PingStatus Indicates whether an OAM F4 ping has succeeded or failed.

atmOamF5PingStatus Indicates whether an OAM F5 ping has succeeded or failed.

atmVclBandwidthUnavailable Bandwidth specified in an ATM traffic descriptor is not available. This alarm is sent when either of the following conditions occurs:

• A VCL is activated with a traffic descriptor that specifies a higher than available rate.

• A VCL is activated with a traffic descriptor that specifies a vcl-rate value which will cause available bandwidth to run out.

atmVclOperStatusChange Subscriber (Id: SubscriberID, Name: SubscriberName) on Vcl (IfIndex: IfIndex, Vpi: VPI, Vci: VCI) is affected


Alarm Description



atmVpiAutoCreateComplete Indicates the system has completed creating VPIs. The system automatically creates VPIs for pre-existing VPLs and VCLs if the VPI/VCI ranges for a card are changed.

atmVplOperStatusChange A VPL has changed state.

dhcpTrapZhoneCpeDetected An IP address is being offered to a Zhone CPE device via DHCP.

dhcpTrapZhoneCpeSysObjectID

The system Object ID of an attached Zhone CPE device that has obtained its address via DHCP.

dhcpTrapZhoneIpAddressUpdate

An IP address has been assigned or modified via DHCP.

coldStart An SNMP entity on the system has reinitialized and its configuration may have changed.

dhcpTrapZhoneCpeDetected An IP address is being offered to a Zhone CPE device

dsx3LineStatusChange Status change for the DS3 interface.

fan_a_failure Fan A is in a fault state.

fan_a_ok Fan A operating normally.

fan_b_failure Fan B is in a fault state.

fan_b_ok Fan B operating normally.

fan_power_supply_a_failure Fan A power supply is in a fault state.

fan_power_supply_a_ok Fan A power supply is operating normally.

fan_power_supply_b_failure Fan B power supply is in a fault state.

fan_power_supply_b_ok Fan B power supply is operating normally.

fan_speed_error There is an irregular fan speed.

fan_speed_ok Fan speed is normal.

fan_tray_added Fan tray added to device.

fan_tray_removed Fan tray removed from device.

igCrvRemoteStateChange A remote GR-303 all reference value (CRV) has changed state.

igCrvTmcStateChange A GR-303 timeslot management channel CRV (TMC) has changed state.

igEocPrimaryStateChange A primary GR-303 embedded operations channel (EOC) has changed state.


Alarm Description



igEocSecondaryStateChange A secondary GR-303 embedded operations channel (EOC) has changed state.

igOperStatusChange A GR-303 interface group (IG) has changed state.

igSystemTimeChange A GR-303 IG system time has changed.

igTmcPrimaryStateChange A primary GR-303 TMC has changed state.

igTmcSecondaryStateChange A secondary GR-303 TMC has changed state.

isdnMibCallInformation This trap indicates the status of a connection request. It is sent whenever:

• an incoming call is rejected

• an outgoing call attempt fails (if the call is configured for retries, this trap is sent after all retires fail)

• a call connects

Note that only one trap is sent for successful or unsuccessful call attempts between two neighbors; subsequent call attempts result in no trap.

isdnTrapAmiViolations Bad Ami violation.

isdnTrapFECV Far end code violation.

isdnTrapFrameSynchLoss Driver receives three successive out of sync frames.

isdnTrapUnbalancedFrame The number of unbalanced ISDN frames has been exceeded.

left_outlet_temp_normal The system is reporting a the temperature on the left outlet is within temperature specifications.

left_outlet_temp_over_limit The system is reporting a high temperature on the left outlet.

linkDown Communication link is about to enter the down state.

power_supply_a_failure Power supply A is in a fault state.

power_supply_a_ok Power supply A is operating normally.

power_supply_b_failure Power supply B is in a fault state.

power_supply_b_ok Power supply B is operating normally.

power_supply_c_failure Power supply C is in a fault state.

power_supply_c_ok Power supply C is operating normally.


Alarm Description



power_supply_d_failure Power supply D is in a fault state.

power_supply_d_ok Power supply D is operating normally.

right_outlet_temp_normal The system is reporting a the temperature on the left outlet is within temperature specifications.

right_outlet_temp_over_limit The system is reporting a high temperature on the right outlet.

sechtor100FanStatusChange The fan on a Zhone Sechtor 100 device has changed state.

sechtor100ThermoStatusChange

The temperature sensor in a Zhone Sechtor 100 device has changed state.

shelf_controller_fault Shelf controller fault.

sipStatusCodeNotif Indicates a session initiation protocol (SIP) status code has been sent or received by the system.

sipStatusCodeThreshExceededNotif

Indicates that a specific SIP status code was found to have been sent or received by the system enough to exceed the configured threshold.

sonetClockTransmitSourceChange

Indicates the SONET clock external recovery or clock transmit settings have been changed.This could be caused by a change to the MALC clocking configuration or a line failure.

sonetLineStatusChange A SONET line has changed state.

sonetPathStatusChange A SONET path has changed state.

sonetSectionStatusChange A SONET section has changed state.

temp_normal The temperature of the device is within specifications.

temp_over_limit The temperature of the device is over specifications.

temp_under_limit The temperature of the device is under specifications.

v52CChannelStatusChange The V5.2 C channel has changed state.

v52CPathOperStatusChange The V5.2 path has changed state.

v52IgOperStatusChange The V5.2 IG has changed state.

v52IgPortAlignmentNotification

A request has been initiated by the operator.


Alarm Description



v52IgProvVariantRequestNotification

A request has been initiated from the AN side.

v52LinkBlockNotification A V5.2 link block request has been sent.

v52LinkCheckIdNotification A V5.2 check link ID request has been received.

v52ProtectionCPathOperStatusChange

A V5.2 protection C path has changed state.

voiceDspChannelInterArrvJitterTrigger

This trap is sent whenever the channelInterArrvJitter exceeds the default setting.

voiceDspChannelPktsLoss This trap is sent whenever the channelPktsPktsLost exceeds the default setting.

voiceDspReset Indicates a voice DSP has reset.

warmStart An SNMP entity on the system has reinitialized and its configuration may have changed.

zapTrapZhoneBanDetected Sent when a BAN detects a MALC or Raptor device.

zapTrapZhoneCpeConnectionDown

Sent when a Zhone CPE device is disconnected.

zapTrapZhoneCpeDetected Sent when a Zhone CPE is detected for the first time.

zapTrapZhoneMalcConnectionDown

A Zhone MALC device has been disconnected.

zapTrapZhoneMalcDetected A Zhone MALC has been detected for the first time.

zapTrapZhoneProvisioningDone

Automatic provisioning is completed.

zhoneAdslPotsBypassRelayChangeNotification

A DSL bypass relay has changed state. This trap is sent on a per-port basis and only applies to the MALC ADSL 32 + splitter cards.

zhoneBulkStatisticsIntervalFailure

Bulk statistics were not successfully gathered for the current interval. This could be caused by the statistics periods overlapping (due to network congestion or too many statistics being gathered), no disk space, file write error, or an FTP error.

zhoneCardRedundancyStatusChange

The specified card has become active.


Alarm Description



ADSL low power alarm

When the MALC detects the ADSL card is in a low power state, it sets all the active DSL ports to admin_down state. When the low power alarm is cleared, the DSL ports are set back to admin_up state. This feature saves back-up battery power until the chassis main power recovers.

zhoneCardServicesStatusChange

Card service is inactive or unavailable (slot SlotNumber)

zhoneDslLineAlarmStatusChange

The SDSL and SHDSL interface has changed state.

zhoneExternalAlarmTrap External relay is open or is not connected.

zhoneImaGroupDown IMA group has gone down.

zhoneLineStatusChange The DS1 interface has changed stated.

zhonePingTestCompleted A ping command has been successful.

zhoneTraceRoutePathChange The path for a traceroute has been changed.

zhoneTraceRouteTestFailed A traceroute command has failed.

zhoneTrapCardMemStatus The memory on a device has changed. This could indicate RAM or flash memory is low or not available.

zhoneTrapCardStatusChange Indicates a card state has changed. This could indicate the card was added, removed, is in a fault state, or has been reset.

zhoneTrapCardVersionCheck Card version CardVersion (SlotNumber) is incompatible with that of active InfoServ card. (BAN only)

zhoneTrapConfigSyncChange A partial config sync update has failed

zhoneTrapCpeConnectionDown

Zhone CPE connection is down

zhoneTrapFlashCardStatusChange

Indicates the flash card in the system has changed state.

zhoneTrapShelfStatusChange A shelf has changed state.

zhoneTrapSnmpSATimeout The SNMP subagent on the system has timed out.

zhoneZmsBlockCliChange At least one CLI session has been unblocked or all CLI sessions are blocked.

zrgBatteryRelayNotification Indicates the state of onboard ZRG battery.


Alarm Description



To enable this feature, configure one of the alarm contacts (1 to 12) to detect low-power alarms in the num2str-profile. The num2str-profile uses an index in the form:shelf/slot/282/alarm-contact

For example:zSH> update num2str-profile 1/12/282/1Please provide the following: [q]uit.name: -> {Relay 1}: low-power....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Alarm suppression

The alarm suppression feature allows alarm/LED notification and output to be disabled based on alarm severity level for existing and future alarms. When an alarm level is disabled, all existing alarms of that type are cleared from the system. Future alarms of that type do not set LEDs or alarm relays and are not displayed in alarm output.

Alarm suppression is also supported in ZMS.

Table 13 lists the alarm suppression options and the resulting behaviors. By default, alarms for all severity levels are enabled.

Table 13: Alarm suppression options

Alarm Levels Enabled Setting Alarm Behavior

critical+major+minor+warning Enables all alarm levels. The default setting.

critical+major+minor Disables all warning alarms.

critical+major Disables all minor, and warning alarms.

critical+major+warning Disables all minor alarms.

critical+minor+warning Disables all major alarms.

critical+minor Disables all major and warning alarms.

critical+warning Disables all major and warning alarms.

critical Disables all major, minor, and warning alarms.

major Disables all critical, minor, and warning alarms.

major+minor+warning Disables all critical alarms.

major+minor Disables all critical and warning alarms.

major+warning Disables all critical and minor alarms.

minor Disables all critical, major, and warning alarms.

minor+warning Disables all critical and major alarms.

System maintenance


This example disables alarm/LED notification and output for all current and future alarms with the severity levels minor and warning.

zSH> update system 0Please provide the following: [q]uit.syscontact: -----------> {Zhone Global Services and Support 7001 Oakport Street Oakland Ca. (877) Zhone20 (946-6320) Fax (510)777-7113 [email protected]}:sysname: --------------> {Malc-M22}:syslocation: ----------> {Oakland}:enableauthtraps: ------> {disabled}:setserialno: ----------> {0}:zmsexists: ------------> {true}:zmsconnectionstatus: --> {inactive}:zmsipaddress: ---------> {172.16.80.160}:configsyncexists: -----> {false}:configsyncoverflow: ---> {true}:configsyncpriority: ---> {high}:configsyncaction: -----> {noaction}:configsyncfilename: ---> {172.16.80.160_4_1149144921639}:configsyncstatus: -----> {synccomplete}:configsyncuser: -------> {zmsftp}:configsyncpasswd: -----> {** private **}: ** read-only **numshelves: -----------> {1}:shelvesarray: ---------> {}:numcards: -------------> {3}:ipaddress: ------------> {172.16.80.160}:alternateipaddress: ---> {0.0.0.0}:countryregion: --------> {us}:primaryclocksource: ---> {0/0/0/0/0}:ringsource: -----------> {internalringsourcelabel}:revertiveclocksource: -> {true}:voicebandwidthcheck: --> {false}:alarm-levels-enabled: -> {critical+major+minor+warning}: critical+major....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.zSH>

System maintenanceThis section describes the following:

• MALC file system on page 338

• Accessing the flash card on page 338

• Deleting card profiles on page 340

(no levels) Disables all alarm levels.

Table 13: Alarm suppression options (Continued)

Alarm Levels Enabled Setting Alarm Behavior



• Manually binding interfaces on page 341

• Renaming interfaces on page 342

• Saving and restoring configurations on page 343

• SNTP on page 344

• User accounts on page 344

• Viewing chassis and slot information on page 350

• Controlling Telnet access on page 352

•

MALC file system

The Uplink card flash memory contains DOS file system that stores the system boot code, software images, and the configuration. During system startup, the software images on the flash are decompressed and loaded into memory.

The following commands can be used to access the file system:

• cd. Changes directory.

• dir. Lists the contents of the directory.

• pwd. Displays the current working directory.

• ata. Used to format or initialize a flash card. This is typically done only for new cards or if you want to completely erase the flash card.

• image. Verifies software images and downloads software images on the flash to system memory.

Accessing the flash cardUse the cd, dir, and pwd commands to list the contents of the file system, as in the following example:

zSH> dirListing Directory .:-rwxrwxrwx 1 0 0 639836 Nov 27 07:00 malct1imaraw.bin-rwxrwxrwx 1 0 0 3321852 Nov 27 07:00 malct1ima.bin-rwxrwxrwx 1 0 0 1032722 Nov 27 07:00 malcmtac.bindrwxrwxrwx 1 0 0 2048 Nov 28 12:50 datastor/-rwxrwxrwx 1 0 0 1682204 Nov 27 07:01 malcadslpots.bin-rwxrwxrwx 1 0 0 3301097 Nov 27 07:01 malcds3.bin-rwxrwxrwx 1 0 0 639756 Nov 27 07:01 malcds3raw.bin-rwxrwxrwx 1 0 0 1510173 Nov 27 07:00 malcgshdsl.bin-rwxrwxrwx 1 0 0 1441233 Dec 6 20001 malcadslac5.bin 75399168 bytes free

System maintenance


Using the ata commandThe ata command formats and initializes flash cards. Formatting formats the files system, but leaves the boot partition on the card intact. Initialization reinitializes the boot partitions on the cards and formats the file system.

The following example formats flash card:zSH> ata format 1

The following example initializes the flash card:zSH> ata init 1

Using the image commandThe MALC contains a TFTP server that enables you to download files from a network to the flash card file system using the image command.

The image command uses the following syntax:image download tftphost image-file destination

The following example downloads the image for the Uplink card (malcoc3.bin) from host 192.168.8.21 to the root directory of the first flash card:image download 192.168.8.21 malcoc3.bin malcoc3.bin

The image command can also verify image files on the flash card. It reads the contents of the file, verifies the file header, and verifies the file checksum. For example:

zSH> image verify malcoc3.binFile: malcoc3.binSize: 3186874 bytesHeader Version: 1Load Type: MALC OC3 Load Address: 0x00010000Checksum: 0x0c847b68Image verify successful

The command reports any errors it finds in the file. Note that files are also verified as part of the download process.

Changing the serial craft port settings

Tip: You only need to modify an rs232-profile if you want to change the default configuration of the serial craft port.

The MALC rs232-profile can be used to configure serial craft ports on the system.

The default settings for the MALC serial control ports are:

• 9600bps



• 8 data bits

• No parity

• 1 stop bit

• No flow control

Changing the serial control port settings

Caution: The serial craft port supports speeds of 9600, 19200, 38400, and 57600 bps. Do not set the speed to an unsupported value. Doing so could render the serial craft port inaccessible.

Update an rs232-profile for the shelf and slot that contains the serial craft port. The following example updates the profile for the serial craft port in slot 1:

zSH> update rs232-profile 1-1-1-0/rs232 shelf-slot-port-subport/typePlease provide the following: [q]uit.rs232PortInSpeed: -------> {9600}: 57600rs232PortOutSpeed: ------> {9600}: 57600rs232PortInFlowType: ----> {none}:rs232PortOutFlowType: ---> {none}:rs232AsyncPortBits: -----> {8}: rs232AsyncPortStopBits: -> {one}: rs232AsyncPortParity: ---> {none}:rs232AsyncPortAutobaud: -> {disabled}: ....................Save new record? [s]ave, [c]hange or [q]uit: Record created.

The settings take effect after the profile is saved.

Note: If the rs232-profile is deleted, the port speed is set to the last configured value.

Deleting card profiles

Caution: Before deleting card profiles, perform the following:

• Back up the MALC configuration. See the release notes for information.

• Delete the ATM cross connects associated with the card.

• For voice cards, ensure all subscribers and voice profiles are deleted before deleting the card.

• Remove the card from the system as explained in the MALC Hardware Installation Guide.

System maintenance


Delete the card-profile for a card to delete all the profiles associated with a card. After deleting a card-profile, the specified card reboots.

Caution: A delete card-profile command deletes profiles associated with the card and may disrupt service until the system is reprovisioned.

The delete command uses the following syntax:delete card-profile 1/slot/type

Where slot is the location of the card and type is the Zhone type for the card. the card.

The following example deletes an ADSL card (Zhone type 5004) in slot 13:

zSH> delete card-profile 1/13/5004 Delete card-profile 1/13/5004? [y]es, [n]o, [q]uit : ycard-profile 1/13/5004 deleted.

You can only delete one card-profile at a time. Wildcards are not supported when deleting card profiles.

Manually binding interfaces

When creating ip-interface-record profiles, the syntax is name/type. The name of the IP interface can be user-defined or match the naming of the if-translate record for the physical interface. The system automatically binds interfaces if the name of the new IP record matches the name of the if-translate profile or if the syntax shelf/slot/port/subport/type is used. Enter a list if-translate command to determine what if-translate records are available on your system.

The example below shows a new ip-interface-record being created with a user-defined name.

zSH> new ip-interface-record myip/ipPlease provide the following: [q]uit.vpi: ---------------> {0}:vci: ---------------> {0}:rdindex: -----------> {1}:dhcp: --------------> {none}: ** read-only **addr: --------------> {0.0.0.0}: 192.168.88.200netmask: -----------> {0.0.0.0}: 255.255.255.0bcastaddr: ---------> {0.0.0.0}: 192.168.88.255destaddr: ----------> {0.0.0.0}:farendaddr: --------> {0.0.0.0}:mru: ---------------> {1500}:reasmmaxsize: ------> {0}:ingressfiltername: -> {}:egressfiltername: --> {}:pointtopoint: ------> {no}:mcastenabled: ------> {yes}:ipfwdenabled: ------> {yes}:



mcastfwdenabled: ---> {yes}:natenabled: --------> {no}:bcastenabled: ------> {yes}:ingressfilterid: ---> {0}:egressfilterid: ----> {0}:ipaddrdynamic: -----> {static}:dhcpserverenable: --> {false}:....................Save new record? [s]ave, [c]hange or [q]uit: sCannot determine binding for this IP interface.Could not automatically bind this IP Interface.New record saved.

Since the system did not automatically bind the new IP interface, manually bind the interface with the stack bind command:

zSH> stack bindEnter the upper layer: myip/ip the IP interface createdEnter the lower layer: 1-1-1-0-ethernetcsmacd/other the line group associated with EthernetStack bind successful.

Note: The stack bind command does not allow binding directly to physical interfaces. You must bind two logical interfaces.

Enter the stack show command (with name/type syntax) to see interface binding:

zSH> stack show myip/ipLine Group: 1-1-1-0-ethernetcsmacd/otherPhysical: 1/1/1/0/ethernetcsmacd

Renaming interfaces

Interfaces on the MALC can be renamed using the ifName parameter in the if-translate profile for the interface.

For example, to rename an Uplink card T1 interface:zSH> update if-translate 1-1-1-0/ds1 Please provide the following: [q]uit.ifindex: -----> {1}: .shelf: -------> {1}:slot: --------> {1}:port: --------> {1}:subport: -----> {0}:type: --------> {ds1}:adminstatus: -> {up}: physical-flag: ----> {true}:iftype-extension: -> {0}:ifName: -----------> {1-1-1-0}: uplink_ds1_1redundancy-param1: -> {0}:....................Save changes? [s]ave, [c]hange or [q]uit: s

System maintenance


Record updated.

Saving and restoring configurations

The dump and restore commands enable you to save and restore the system configuration. You can save the configuration to the console, a local file, or the network.

The command uses the following syntax:dump [console] [file filename] [network host filename ]

Passwords are encrypted when they are saved to the configuration file. The encrypted passwords are used to restore the correct password, but cannot be used to log in.

Note: The dump and restore commands use TFTP to transfer files to the network. Set the TFTP server time-out value to at least 5 seconds, and 5 retries to help prevent TFTP timeout or retry errors.

To save the configuration to a console:1 Configure your terminal emulation software as follows:

– 9600bps

– 8 data bits

– No parity

– 1 stop bit

– No hardware flow control

– VT100

– Set Line Delay and Character Delay to 40 milliseconds

2 Turn on the file capture utility of your terminal emulation software.

3 Save the configuration by entering:dump console

Do not press the Enter key.

4 Start the capture utility on your terminal emulation software and enter a name for the file (use a .txt extension).

5 Press the Enter key.

The configuration file will be displayed on the screen.

6 When configuration file is finished, stop the capture utility.

Backing up the configuration to a local fileTo dump the configuration to a local file:

Specify a file name for the configuration:



zSH> dump file filename

The file is saved on the MALC filesystem.

Backing up the configuration to the networkTo back up the configuration to the network:

1 Create the file in the destination location of the TFTP server and make it writeable.

2 Save the configuration. The following example saves the configuration to a file named device.cfg on the host 192.168.8.21:zSH> dump network 192.168.8.21 device.cfg

Restoring the configurationFor information on restoring your configuration, refer to the release notes for your release.

SNTPTo set up the system to use SNTP:

Update the ntp-client-config profile. For example:

zSH> update ntp-client-config 0Please provide the following: [q]uit.primary-ntp-server-ip-address: ---> {0.0.0.0}: 192.168.8.100secondary-ntp-server-ip-address: -> {0.0.0.0}:local-timezone: ------------------> {gmt}: pacificdaylight-savings-time: -----------> {false}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

User accounts

MALC users have access to the CLI and are able to configure and administer the system.

Adding usersEvery administrative user on the system must have a user account. The account specifies their username and password, as well as their privilege level, which determines their access to commands.

Users with admin privileges have access to all the administrative commands. Users with user privileges have access to a very limited set of commands. The highest level of access is useradmin, which allows the creation of user accounts.

System maintenance


Note: When entering access level responses, enter yes completely or the CLI interprets the response as no.

To add a user, enter the following commands:

zSH> adduserPlease provide the following: [q]uit.User Name: jjsmithUser Prompt[zSH>]:

Please select user access levels.admin: -------> {no}: yeszhonedebug: --> {no}: voice: -------> {no}: data: --------> {no}: manuf: -------> {no}: database: ----> {no}: systems: -----> {no}: tool: --------> {no}: useradmin: ---> {no}: yes..................................User name:(jjsmith) User prompt:(zSH>)Access Levels:(admin)(useradmin)Save new account? [s]ave, [c]hange or [q]uit: sUser record saved.TEMPORARY PASSWORD: hmj4mxFU

Commands with zhonedebug privilege levels are intended for use by Zhone development only.

Immediately after activating the user account, you should change the password something you can remember, as explained in the next section.

Changing default user passwordsWhen adding users, the system automatically assigns a temporary password to each user. Most users will want to change their password. The changepass command changes the password for the current logged in user. The following is an example of changing a password:

zSH> changepassCurrent Password:New Password:Confirm New Password:Password change successful.

Deleting usersTo delete a user, enter the deleteuser command and specify the username:

zSH> deleteuser jsmithOK to delete this account? [yes] or [no]: yes



User record deleted.

Deleting the admin user accountIn addition to deleting regular user accounts, you can also delete the admin user account. This account is automatically created by the system and provides full access to the CLI.

Note: You cannot delete the admin account (or any other user account with useradmin privileges) if you are currently logged into it.

To delete the admin account:zSH> deleteuser admin

If desired, you can recreate an account named admin after deleting it:

zSH> adduser adminPlease provide the following: [q]uit.User Name: adminUser Prompt[zSH>]:

Please select user access levels.admin: -------> {no}: yeszhonedebug: --> {no}: voice: -------> {no}: yesdata: --------> {no}: yesmanuf: -------> {no}: yesdatabase: ----> {no}: yessystems: -----> {no}: yestool: --------> {no}: yesuseradmin: ---> {no}: yes..................................User name:(admin) User prompt:(zSH>)Access Levels:(admin)(voice)(data)(manuf)(database)(systems)(tools)(useradmin)Save new account? [s]ave, [c]hange or [q]uit: sUser record saved.TEMPORARY PASSWORD: hmj4mxFU

Resetting passwordsIf a user forgets their password, an administrative user can reset the password and generate a new one using the resetpass command, as in the following example:

zSH> resetpass jsmithPassword:

System maintenance


Radius support

The MALC supports local and RADIUS (Remote Authentication Dial In User Service) access authentication. The MALC can be configured for local authentication, RADIUS authentication, or RADIUS then local authentication. RADIUS users are configured with the Service-Type attribute as Administrative-User or NAS-Prompt-User. RADIUS is used for only login authentication, not severity levels.

Table 14 shows the mapping of service-type to MALC permissions.

When establishing a connection to the MALC with RADIUS authentication, the MALC passes RADIUS information securely to the RADIUS server. The RADIUS server then authenicates the user and either allows or denies access to the MALC. If access is denied and the local authentication option is also configured, the MALC then authenticates access based on the locally configured users and passwords. For logins and failed logins, a console message is generated with user ID and IP address of the device from which the login originated. Failed logins also are logged as alert level messages in the MALC system log file.

By default, RADIUS access uses the UDP port 1812 for authentication.This parameter can be changed in the radius-client profile.

Figure 39: MALC RADIUS authentication

Table 14: Service type mapping to MALC permissions

Service-Type Attribute MALC permissions

Administrative-User admin, zhonedebug, voice, data, manuf, database, systems, tools, useradmin

NAS-Prompt-User admin, voice, data, manuf, database, systems, tools, useradmin

MALC

Console user

RADIUS server

IP

RADIUS authentication

Local authentication

TelnetTelnet user



Note: Follow the RADIUS server guidelines for RADIUS configuration instructions. For example, when using the MALC with the FreeRadius server:

• Create only one entry in the clients.conf file for each subnet or individual MALC. For individual MALCs, the IP in this file must match the IP address of the outbound interface used by the MALC to connect to the RADIUS server.

• The MALC uses the value stored in the RADIUS system.sysname file for the NAS-Identifier attribute.

• The shared-secret in the MALC radius-client profile, must exactly match the shared-secret in the RADIUS client entry.

Configuring RADIUS supportThe MALC can be configured for local authentication, RADIUS authentication, or RADIUS then local authentication. Multiple radius-client profiles can be defined using the index and subindex numbers. This index scheme can be used to create index numbers for groups of RADIUS servers. When an index number is specified in the system profile, the MALC attempts authenication from each RADIUS server in that group in sequential order of the subindex numbers.

To configure RADIUS support:

Note: Before beginning this procedure, ensure that the MALC has IP connectivity to the RADIUS server.

1 Update the RADIUS server with settings for the Zhone prompts.

2 Create a radius-client profile on the MALC with the desired index number and RADIUS settings for server name, shared secret, number of retries, and other parameters. The first number in the index is used to group radius-client profiles so multiple profiles can be assigned to a MALC. The second number in the index specifies the order in which radius-client profiles are referenced. This example specifies the radius-client 1/1 with server name radius1 and a shared-secret of secret. A DNS resolver must be configured in the system to resolve the server name and IP address.If a DNS resolver is not available, specify the IP address of the The index 1/1 specifies that this profile is the first profile in group 1.

zSH> new radius-client 1/1Please provide the following: [q]uit.server-name: ----> {}: radius1.test.com [DNS resolver must be configured in the system.]udp-port: -------> {1812}:shared-secret: --> {** password **}: secretretry-count: ----> {5}:retry-interval: -> {1}:....................Save new record? [s]ave, [c]hange or [q]uit: s

System maintenance


Record created.

Another method to reference the RADIUS server is by specifying the IP address. This example specifies the radius-client 1/1 with server IP address 172.24.36.148 and a shared-secret of secret. The index 1/1 specifies that this profile is the first profile in group 1.

zSH> new radius-client 1/1Please provide the following: [q]uit.server-name: ----> {}: 172.24.36.248udp-port: -------> {1812}:shared-secret: --> {** password **}: secretretry-count: ----> {5}:retry-interval: -> {1}:....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

3 Create another radius-client profile on the MALC with the desired RADIUS settings for server name, shared secret, number of retries, and other parameters. This example specifies the radius-client 1/2 with server IP address 172.24.36.148 and a shared-secret of secret. The index 1/2 specifies that this profile is the second profile in group 1.

zSH> new radius-client 1/2Please provide the following: [q]uit.server-name: ----> {}: 172.24.36.249udp-port: -------> {1812}:shared-secret: --> {** password **}: secretretry-count: ----> {5}:retry-interval: -> {1}:....................Save new record? [s]ave, [c]hange or [q]uit: sRecord created.

Create additional radius-client profiles for each additional RADIUS server to be assigned to this MALC.

4 In the system profile on the MALC, set the desired user authentication method and specify the index of the radius profile to use. This examples specifies the radiusauthindex of 1. This index is configured with two radius-client profiles (1/1, 1/2). The MALC first attempts authenication using the server specified in radius-client 1/1. If this authenitication fails, the MALC attempts authenication using radius-client 1/2 server. If this authentication also fails, the MALC then attempts authentication based on the authentication mode setting in the system profile. This example uses radiusthenlocal.

Caution: If the radius authentication mode is used, local authentication is disabled so the MALC may become inaccessible if IP connectivity to the RADIUS server is lost or other changes prevent the MALC from receiving RADIUS authentication.



zSH> update system 0Please provide the following: [q]uit.syscontact: -----------> {Zhone Global Services and Support 7001 Oakport Street Oakland Ca. (877) Zhone20 (946-6320) Fax (510)777-7113 [email protected]}:sysname: --------------> {Malc1}:syslocation: ----------> {Oakland}:enableauthtraps: ------> {disabled}:setserialno: ----------> {0}:zmsexists: ------------> {true}:zmsconnectionstatus: --> {inactive}:zmsipaddress: ---------> {172.16.49.76}:configsyncexists: -----> {false}:configsyncoverflow: ---> {false}:configsyncpriority: ---> {high}:configsyncaction: -----> {noaction}:configsyncfilename: ---> {172.16.88.14_4_1178142210378}:configsyncstatus: -----> {synccomplete}:configsyncuser: -------> {zmsftp}:configsyncpasswd: -----> {** private **}: ** read-only **numshelves: -----------> {1}:shelvesarray: ---------> {}:numcards: -------------> {3}:ipaddress: ------------> {172.16.88.14}:alternateipaddress: ---> {0.0.0.0}:countryregion: --------> {us}:primaryclocksource: ---> {0/0/0/0/0}:ringsource: -----------> {internalringsourcelabel}:revertiveclocksource: -> {true}:voicebandwidthcheck: --> {false}:alarm-levels-enabled: -> {critical+major+minor+warning}:userauthmode: ---------> {local}: radiusthenlocalradiusauthindex: ------> {0}: 1....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.zSH>

After completing the RADIUS configuration, the MALC displays console messages for RADIUS login and logout activity.

For users logging in through RADIUS, the system prompt appears as the username@systemname. For example, the system prompt for a basic user on a MALC using the default Zhone Malc system name will appear as basicuser@Zhone malc. The system name is configured using the sysname parameter in the System 0 profile.

Viewing chassis and slot information

The following commands display information about the status of the system:

• shelfctrl

System maintenance


• slots

To view overall status of the system, use the shelfctrl monitor command:zSH> shelfctrl monitorShelf Monitor CPLD version: 1.2Shelf Monitor Firmware version: 1.6Inlet temperature 79 degrees.Left outlet temperature sensor: 78 degrees (normal)Right outlet temperature sensor: 78 degrees (normal)Power Supply A: failurePower Supply B: normalFan status: OK.System: Critical alarm set.Card 12: Critical alarm set.

To view general system statistics:zSH> shelfctrl statsShelf Controller Message Statistics-----------------------------------Card updates: 42Card ECHO: 0Directory services messages: 2Clock messages: 178707Lease messages: 496Heartbeat messages: 470902

Card update errors: 0Card ECHO errors: 0Directory services errors: 0Clock errors: 0Lease errors: 0Heartbeat errors: 0Receive errors: 0

To verify whether the shelf is active:zSH> shelfctrl showShelf Controller Address: 01:02:12Shelf Registry Address: 01:02:75Lease ID: 0x022b0008_00000036State: active

To view the system slot cards and their status:zSH> slots1: MALC OC3 (RUNNING) 5: MALC ADSL AC5 (RUNNING) 6: MALC ADSL AC5 (LOADING) 7: MALC ADSL AC5 (RUNNING) 8: MALC ADSL AC5 (RUNNING) 9: MALC ADSL (RUNNING)13: MALC MTAC (RUNNING)16: MALC ADSL AC6 (RUNNING)20: MALC GSHDSL (RUNNING)



21: MALC GSHDSL (RUNNING)

To view information about a particular slot card, use the slots command and specify a slot number. For example:zSH> slots 1Type : MALC OC3Card Version : 1EEPROM Version : 1Serial # : 7714040CLEI Code : No CLEICard-Profile ID : 1/1/5011Shelf : 1Slot : 1State : RUNNINGMode : FUNCTIONALHeartbeat check : enabledLongest hbeat : 50Fault reset : enabledUptime : 1 hour, 49 minutes

Controlling Telnet access

The port-access profile specifies from which IP addresses users can telnet to the MALC. If a host’s IP address is not specified in a port-access profile, users from that host cannot telnet to the MALC. These restrictions take effect after the first port-access profile has been created.

By default, no port-access profiles are created, so telnet access is not restricted.

Creating port-access profile entriesUp to 100 port-access profile entries can be created on a MALC. To create a port-access profile entry:

Create a new port-access profile and specify the telnet port number, host/network IP address to be granted access, and the netmask applied to the IP address to allow access to a range of IP addresses.

This example creates port-access entry 1 on telnet port 23 and allows hosts on the 172.16.41.xx network to telnet to the MALC.

Note: Typically, only port 23 is used for telnet access.

zSH> new port-access 1Please provide the following: [q]uit.portNumber: -> {0}: 23portArg1: ---> {0.0.0.0}: 172.16.41.0portArg2: ---> {0.0.0.0}: 255.255.255.0....................S=Save new record? [s]ave, [c]hange or [q]uit: s

Testing


New record saved.

Displaying port-access profile entriesTo display configured port-access profile entries use the list command:

zSH> list port-access port-access 11 entry found.

Modifying port-access profile entriesTo modify a configured port-access profile entry use the update command. The following example changes the entry’s source IP address to 172.16.40.0:

zSH> update port-access 1portNumber: -> {23}portArg1: ---> {172.16.41.0} 172.16.40.0portArg2: ---> {255.255.255.0}1 entry found.....................Save new record? [s]ave, [c]hange or [q]uit: sUpdated record saved.

TFTP server support

By default, the MALC runs as an TFTP server enabling files stored in the root/pubs folder to be downloaded to other devices with connectivity to the MALC. The following example downloads the file file.bin from a MALC with the IP address 172.24.15.19.

image download 172.24.15.19 /pub/file.bin file.bin

TestingThis section describes the following:

• Activating or deactivating interfaces on page 353

• BER tests on page 354

• IMA test pattern procedure on page 356

• Loopbacks on page 360

• Viewing IMA group status on page 366

Activating or deactivating interfaces

Physical interfaces on the MALC have associated if-translate profiles, which enable or disable the interfaces. To change the state of an interface, use the



adminstatus parameter in the if-translate profile associated with the interface. The if-translate profile uses the following syntax:if-translate shelf-slot-port-subport/type

For example, to activate a MALC T1 interface:zSH> update if-translate 1-1-1-0/ds1 Please provide the following: [q]uit.ifindex: -----> {1}: .shelf: -------> {1}:slot: --------> {1}:port: --------> {1}:subport: -----> {0}:type: --------> {ds1}:adminstatus: -> {down}: upphysical-flag: ----> {true}:iftype-extension: -> {0}:ifName: -----------> {}: redundancy-param1: -> {0}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

For example, to deactivate a MALC T1 interface:zSH> update if-translate 1-1-1-0/ds1 Please provide the following: [q]uit.ifindex: -----> {1}: .shelf: -------> {1}:slot: --------> {1}:port: --------> {1}:subport: -----> {0}:type: --------> {ds1}:adminstatus: -> {up}: downphysical-flag: ----> {true}:iftype-extension: -> {0}:ifName: -----------> {}: redundancy-param1: -> {0}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

BER tests

The send-code parameter in the ds1-profile controls loopbacks and BER tests on the T1 interface. The following table describes the BERT options.

Testing


Activating a BER test

Note: BER tests disrupt traffic on the interface.

1 Update the ds1-profile to specify the BERT pattern:

zSH> update ds1-profile 1-1-1-0/ds1Please provide the following: [q]uit.line-type: ----------------------> {esf}:line-code: ----------------------> {b8zs}:send-code: ----------------------> {sendnocode}: sendqrsspatterncircuit-id: ---------------------> {ds1}:loopback-config: ----------------> {noloop}:signal-mode: --------------------> {robbedbit}:fdl: ----------------------------> {fdlnone}:dsx-line-length: ----------------> {dsx0}:line-status_change-trap-enable: -> {enabled}:channelization: -----------------> {enabledds0}:ds1-mode: -----------------------> {csu}:csu-line-length: ----------------> {csu00}:clock-source-eligible: ----------> {noteligible}:transmit-clock-source: ----------> {throughtiming}cell-scramble: ------------------> {false}coset-polynomial: ---------------> {true}: protocol-emulation: -------------> {network}signal-type: --------------------> {loopstart}ds1-group-number: ---------------> {0}line-power: ---------------------> {disabled}....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

2 To end a BER test:

zSH> update ds1-profile 1-1-1-0/ds1


send-code Indicates what type of code is being sent across the DS1 interface by the device. Setting this parameter causes the interface to send the requested code.Values: sendQRSSPattern Sends a Quasi-Random Signal Source (QRSS) test pattern.send511Pattern Sends a 511 bit fixed test pattern.send3in24Pattern Sends a fixed test pattern of 3 bits set in 24.send2047Pattern Sends 2047 test pattern.send1in2Pattern Sends alternate one, zero pattern



Please provide the following: [q]uit.line-type: ----------------------> {esf}:line-code: ----------------------> {b8zs}:send-code: ----------------------> {sendqrsspattern}: sendnocodecircuit-id: ---------------------> {ds1}:loopback-config: ----------------> {noloop}:signal-mode: --------------------> {robbedbit}:fdl: ----------------------------> {fdlnone}:dsx-line-length: ----------------> {dsx0}:line-status_change-trap-enable: -> {enabled}:channelization: -----------------> {enabledds0}:ds1-mode: -----------------------> {csu}:csu-line-length: ----------------> {csu00}:clock-source-eligible: ----------> {noteligible}:transmit-clock-source: ----------> {throughtimingcell-scramble: ------------------> {false}coset-polynomial: ---------------> {true}: protocol-emulation: -------------> {network}signal-type: --------------------> {loopstart}ds1-group-number: ---------------> {0}line-power: ---------------------> {disabled}....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

IMA test pattern procedure

The MALC supports IMA test pattern procedures to validate the status of the IMA link. A test pattern sent over a transmit link is looped back over all available receive interfaces. Test pattern procedures do not interrupt traffic.

Testing


The following table describes the test pattern procedure parameters in the ima-group-profile.

Testing the IMA link with a random test patternA test pattern procedure with a random pattern will run continuously until it is disabled. Use the imatppshow command to view the status of the test (as explained in Viewing test procedure status on page 359).

To test the IMA link with a randomly generated test link and pattern (the default):

1 Specify an interface to transmit the test over:

zSH> update ima-group-profile 1/1/1Please provide the following: [q]uit.groupSymmetry: ---> {symmetricoperation}:minNumTxLinks: ---> {1}:minNumRxLinks: ---> {1}:txClkMode: -------> {ctc}:txImaId: ---------> {1}:txFrameLength: ---> {m128}:diffDelayMax: ----> {75}:alphaValue: ------> {2}:betaValue: -------> {2}:gammaValue: ------> {1}:


testLinkIfIndex Indicates the interface used to transmit the test pattern. The test pattern is looped back from the far end device over each active link in the IMA group. Note that this value is not the same as the txImaId value. Values: A valid interface on the system in the form shelf-slot-port-subport/type This is the link whose link identifier (LID) value is inserted in the Tx LID field of the transmitted ICP cells.Default: 0

testPattern Specifies the transmit Test Pattern in an IMA group loopback operation. A value in the range 0 to 254 designates a specific pattern. Values: –1 to 254 –1 indicates that the test pattern is randomly generated. Default: –1

testProcStatus Enables or disables the Test Pattern Procedure.Values: disabled Deactivates the test pattern procedure.operating Activates the test pattern procedure.Default: disabled



testLinkIfIndex: -> {0}: 1-1-1-0/ds1 IMA link to testtestPattern: -----> {-1}:testProcStatus: --> {disabled}: operatingtxTimingRefLink: -> {0}:rxTimingRefLink: -> {0}:groupRestoreNumRetry: -> {0}:groupRestoreNumDelay: -> {0}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

2 To disable the test:

zSH> update ima-group-profile 1/1/1Please provide the following: [q]uit.groupSymmetry: ---> {symmetricoperation}:minNumTxLinks: ---> {1}:minNumRxLinks: ---> {1}:txClkMode: -------> {ctc}:txImaId: ---------> {1}:txFrameLength: ---> {m128}:diffDelayMax: ----> {75}:alphaValue: ------> {2}:betaValue: -------> {2}:gammaValue: ------> {1}:testLinkIfIndex: -> {1/1/1/0/ds1}:testPattern: -----> {-1}:testProcStatus: --> {enabled}: disabledtxTimingRefLink: -> {0}:rxTimingRefLink: -> {0}:groupRestoreNumRetry: -> {0}:groupRestoreNumDelay: -> {0}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Testing the IMA link with a specific test patternA test with a specified test pattern runs until it verifies link connectivity. Use the imatppshow command to view the status of the test (as explained in Viewing test procedure status on page 359).

1 To specify a particular test pattern (for example, 23):

zSH> update ima-group-profile 1/1/1Please provide the following: [q]uit.groupSymmetry: ---> {symmetricoperation}:minNumTxLinks: ---> {1}:minNumRxLinks: ---> {1}:txClkMode: -------> {ctc}:txImaId: ---------> {1}:txFrameLength: ---> {m128}:diffDelayMax: ----> {75}:alphaValue: ------> {2}:

Testing


betaValue: -------> {2}:gammaValue: ------> {1}:testLinkIfIndex: -> {0}: 1-1-1-0/ds1 IMA link to testtestPattern: -----> {-1}: 23testProcStatus: --> {disabled}: operatingtxTimingRefLink: -> {0}:rxTimingRefLink: -> {0}:groupRestoreNumRetry: -> {0}:groupRestoreNumDelay: -> {0}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

To run the test again, update the ima-group-profile without making any changes.

2 To disable the test:

zSH> update ima-group-profile 1/1/1Please provide the following: [q]uit.groupSymmetry: ---> {symmetricoperation}:minNumTxLinks: ---> {1}:minNumRxLinks: ---> {1}:txClkMode: -------> {ctc}:txImaId: ---------> {1}:txFrameLength: ---> {m128}:diffDelayMax: ----> {75}:alphaValue: ------> {2}:betaValue: -------> {2}:gammaValue: ------> {1}:testLinkIfIndex: -> {1/1/1/0/ds1}:testPattern: -----> {-1}:testProcStatus: --> {enabled}: disabledtxTimingRefLink: -> {0}:rxTimingRefLink: -> {0}:groupRestoreNumRetry: -> {0}:groupRestoreNumDelay: -> {0}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Viewing test procedure statusUse the imatppshow command to view the status of the test:

If the test is successful, imaGroupTestProcStatus displays OPERATING:

zSH> imatppshow 1TestLink .....................: 2imaGroupTestPattern ..........: 23imaGroupTestProcStatus .......: OPERATING

If the test fails (if, for example, the remote link is down), imaGroupTestProcStatus displays LINKFAIL:



zSH> imatppshow 1TestLink .....................: 2imaGroupTestPattern ..........: 71imaGroupTestProcStatus .......: LINKFAIL

After the test is disabled, the imaGroupTestProcStatus displays DISABLED:zSH> imatppshow 1TestLink .....................: 2imaGroupTestPattern ..........: 23imaGroupTestProcStatus .......: DISABLED

Loopbacks

The MALC support the following types of loopbacks:

• T1 loopbacks on page 360

• DS3 loopbacks on page 363

• SONET loopbacks on page 362

• ISDN loopbacks on page 365

T1 loopbacksThe loopback-config parameter in the ds1-profile controls T1 loopbacks. The following table describes the loopback options.

Activating a T1 loopback

Note: Loopbacks disrupt traffic on the interface.


loopback-config The loopback configuration of the DS1 interface. Values: noloop Not in the loopback state. A device that is not capable of performing a loopback on the interface always returns this as its value.lineloop The received signal at this interface is looped through the device. Typically the received signal is looped back for retransmission after it has passed through the device's framing function.payloadloop The received signal on this interface does not go through the device (minimum penetration) but is looped back out.Default: noloop

Testing


1 Specify the type of loopback:

zSH> update ds1-profile 1-1-1-0/ds1Please provide the following: [q]uit.line-type: ----------------------> {esf}:line-code: ----------------------> {b8zs}:send-code: ----------------------> {sendnocode}: circuit-id: ---------------------> {ds1}:loopback-config: ----------------> {noloop}: lineloopsignal-mode: --------------------> {robbedbit}:fdl: ----------------------------> {fdlnone}:dsx-line-length: ----------------> {dsx0}:line-status_change-trap-enable: -> {enabled}:channelization: -----------------> {enabledds0}:ds1-mode: -----------------------> {csu}:csu-line-length: ----------------> {csu00}:clock-source-eligible: ----------> {noteligible}:transmit-clock-source: ----------> {throughtiming}cell-scramble: ------------------> {false}coset-polynomial: ---------------> {true}: protocol-emulation: -------------> {network}signal-type: --------------------> {loopstart}ds1-group-number: ---------------> {0}line-power: ---------------------> {disabled}....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Note: Only one loopback can be active at a time. If there is a loopback running, a message similar to the following will appear when you attempt to run another loopback:1/1: ds1rp: : l=3278: Please disable any active loopbacks on line 1:1:0:0

2 To stop the loopback:

zSH> update ds1-profile 1-1-1-0/ds1Please provide the following: [q]uit.line-type: ----------------------> {esf}:line-code: ----------------------> {b8zs}:send-code: ----------------------> {sendlinecode}: circuit-id: ---------------------> {ds1}:loopback-config: ----------------> {lineloop}: noloopsignal-mode: --------------------> {robbedbit}:fdl: ----------------------------> {fdlnone}:dsx-line-length: ----------------> {dsx0}:line-status_change-trap-enable: -> {enabled}:channelization: -----------------> {enabledds0}:ds1-mode: -----------------------> {csu}:csu-line-length: ----------------> {csu00}:clock-source-eligible: ----------> {noteligible}:transmit-clock-source: ----------> {throughtiming}cell-scramble: ------------------> {false}



coset-polynomial: ---------------> {true}: protocol-emulation: -------------> {network}signal-type: --------------------> {loopstart}ds1-group-number: ---------------> {0}line-power: ---------------------> {disabled}....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

SONET loopbacksA SONET terminal loopback is a SONET circuit with a loop that terminates at the MALC OC3-c/STM1 interface.

The medium-loopback-config parameter in the sonet-profile specifies the type of loopback:

Looping back the SONET interfaceThe following example initiates SONET terminal loopbacks.

1 Set the interface to testing:

zSH> update if-translate 1-1-1-0/sonet shelf-slot-port-subport/typePlease provide the following: [q]uit.ifindex: -----> {232}: .shelf: -------> {1}:slot: --------> {1}:port: --------> {1}:subport: -----> {0}:type: --------> {sonet}:


medium-loopback-config How the SONET loopback is configured.Values: sonetnoloop SONET circuit, with no loop.sonetfacilityloop All incoming data on the Rx interface is retransmitted out of the Tx interface. Used to check the circuit between a remote device and the MALC and to test the MALC optical module.sonetterminalloop All of the data transmitted on the Tx interface is also internally looped back to the Rx interface. Used to verify that the ATM and PHY layers are communicating.sonetotherloop All incoming data on the Rx interface is retransmitted out of the Tx interface. Used to check the circuit between the IAD and a remote unit and to verify that the optical module and the SONET PHY are working.

Testing


adminstatus: -> {down}: testingphysical-flag: ----> {false}:iftype-extension: -> {none}:ifName: -----------> {}: ....................Save changes? [s]ave, [c]hange or [q]uit: sRecord updated.

2 Configure the type of loopback:

zSH> update sonet-profile 1-1-1-0/sonetPlease provide the following: [q]uit.medium-type: ---------------> {sonet}:medium-line-coding: --------> {sonetmediumnrz}:medium-line-type: ----------> {sonetshortsinglemode}:medium-circuit-identifier: -> {}:medium-loopback-config: ----> {sonetnoloop}: sonetterminalloopmedium-scramble-config: ----> {sonetscrambleon}:path-current-width: --------> {sts3cstm1}:clock-external-recovery: ---> {enabled}:clock-transmit-source: -----> {looptiming}:medium-cell-scramble-config: -> {true}:medium-line-scramble-config: -> {true}:....................Save changes? [s]ave, [c]hange or [q]uit: sRecord saved.

Note: The adminstatus of the SONET line remains up and SONET communications continue during SONET terminal loopbacks.

DS3 loopbacksThe loopback-config parameter in the ds3-profile controls DS3 loopbacks. The following table describes the loopback options.



Activating a DS3 loopback


1 Specify the type of loopback:

zSH> update ds3-profile 1-1-2-0/ds3line-type: ---------------> {dsx3cbitparity}line-coding: -------------> {dsx3b3zs}send-code: ---------------> {dsx3sendnocode}circuit-id: --------------> {}loopback-config: ---------> {dsx3noloop} specify type of loopbacktransmit-clock-source: ---> {looptiming} line-length-meters: ------> {0} line-status-trap-enable: -> {enabled}channelization: ----------> {disabled}ds1-for-remote-loop: -----> {0}far-end-equip-code: ------> {}far-end-loc-id-code: -----> {}far-end-frame-id-code: ---> {}far-end-unit-code: -------> {}far-end-fac-id-code: -----> {}medium-scramble-config: --> {true}medium-frame-config: -----> {e3frameg832}medium-atmframe-config: --> {dsx3atmframingdirectcellmapped}

Note: Only one loopback can be active at a time.

2 To stop the loopback:


loopback-config Specifies the loopback configuration of the interface.Values: dsx3noloop The DS3 interface is not in the loopback state.dsx3payloadloop The received signal at the DS3 interface is looped through the system for retransmission.dsx3inwardloop The sent signal at the DS3 interface is looped back through the system.dsx3lineloop The received signal at the DS3 interface does not go through the device before it is looped.

Testing


zSH> update ds3-profile 1-1-2-0/ds3line-type: ---------------> {dsx3cbitparity}line-coding: -------------> {dsx3b3zs}send-code: ---------------> {dsx3sendnocode}circuit-id: --------------> {}loopback-config: ---------> {dsx3payloadloop} dsx3nolooptransmit-clock-source: ---> {looptiming} line-length-meters: ------> {0} line-status-trap-enable: -> {enabled}channelization: ----------> {disabled}ds1-for-remote-loop: -----> {0}far-end-equip-code: ------> {}far-end-loc-id-code: -----> {}far-end-frame-id-code: ---> {}far-end-unit-code: -------> {}far-end-fac-id-code: -----> {}medium-scramble-config: --> {true}medium-frame-config: -----> {e3frameg832}medium-atmframe-config: --> {dsx3atmframingdirectcellmapped}

ISDN loopbacksLoopbacks can be run on the ISDN B and D channels.




Modify the loopback parameter in the isdn-profile to configure ISDN loopbacks:

zSH> update isdn-profile 1-14-1-0/isdnuPlease provide the following: [q]uit.line-term-class: ---> {class1}:activation-timer2: -> {t2-50ms}:loopback: ----------> {loop-back-none}: loop-back-b1-idl2-trSave changes? [s]ave, [c]hange or [q]uit: sRecord updated.

Viewing IMA group status

The imarpshow command displays information about the MALC IMA group. The command uses the following syntax:imarpshow [index]

where index is the IMA group number. For example:

zSH> imarpshowRP Info: rp state -------------------> RP_INITIALIZED address --------------------> 01:01:113


loopback Initiates ISDN loopback on the U interface.Values: loop-back-none no loop back loop-back-b1-idl2-tr transparent loopback on the Interchip Digital Link, Version 2 (IDL2), which is used for transporting the ISDN channels towards the system (B1 channel)loop-back-b1-idl2-nt non-transparent loopback on the IDL2 interface towards the system (B1 channel)loop-back-b2-idl2-tr transparent loopback on the IDL2 interface towards the system (B2 channel)loop-back-b2-idl2-nt non-transparent loopback on the IDL2 interface towards the system (B2 channel)loop-back-2bd-idl2-tr transparent loopback on the IDL2 towards the system (2B + D channel)loop-back-2bd-idl2-nt non-transparent loopback on the IDL2 towards the system (2B + D channel)loop-back-2bd-u-interface-tr transparent loopback on the U interface towards the user (2B + D channel)loop-back-2bd-u-interface-nt non-transparent loopback on the U interface (2B + D channel)loop-back-2bd-external-analog loopback on the external analog interface towards the user (2B + D channel)Default: loop-back-none

Testing


rp shelf -------------------> 1 rp slot --------------------> 1 rp ima core started --------> TRUE imaGrpProfLeaseId ----------> 0x02070000_00000057 LineRRProvLeaseId ----------> 0x02070000_00000055 LineRRClientLeaseId --------> 0x02070000_00000056 numImaGroups ---------------> 1 ImaGroupIndecies: 1

To display complete information about an IMA group, specify the group number:

zSH> imarpshow 1RP Info: rp state -------------------> RP_INITIALIZED address --------------------> 01:01:113 rp shelf -------------------> 1 rp slot --------------------> 1 rp ima core started --------> TRUE imaGrpProfLeaseId ----------> 0x02070000_00000057 LineRRProvLeaseId ----------> 0x02070000_00000055 LineRRClientLeaseId --------> 0x02070000_00000056 numImaGroups ---------------> 1 ImaGroupIndecies: 1 IMA Group Index =1.............................................. group status ==========> OOS ......................... group ne state --------> INSUFFICIENTLINKS group fe state --------> OPERATIONAL ......................... group ctlr state ------> GRP_INITIALIZED group ifIndex ---------> 11 group in service ------> TRUE driver attached -------> TRUE driver unit -----------> 0 auto-created ----------> FALSE ifxLeaseId ------------> 0x02070000_00000057 lineProfLeaseId -------> 0x02070000_00000057 lineGrpLeaseId --------> 0x02070000_00000057 ifStackLeaseId --------> 0x02070000_00000057 ds1LeaseId ------------> 0x00000000_00000000 ......................... ifxlateProfValid ----------------> TRUE ifxlatProf.ifIndex --------------> 11 ifxlatProf.shelf ----------------> 1 ifxlatProf.slot -----------------> 1 ifxlatProf.port -----------------> 2 ifxlatProf.ifType ---------------> ATMIMA ifxlatProf.adminStatus ----------> UP ......................... lineProfValid -------------------> TRUE lineProf.profileName ------------> Atm IMA Group default line profile lineProf.physicalAddress.shelf --> 1



lineProf.physicalAddress.slot ---> 1 lineProf.physicalAddress.port ---> 2 lineProf.lineGroupName ----------> 11 ......................... lineGrpProfValid ----------------> TRUE lineGrpProf.groupName -----------> 1/1/1 lineGrpProf.primaryName ---------> 11 lineGrpProf.secondaryName -------> 0 lineGrpProf.primaryWeight -------> 0 lineGrpProf.secondaryWeight -----> 0 lineGrpProf.adminState ----------> UP ......................... imaGrpProfValid -----------------> TRUE imaGrpProf.groupSymmetry --------> SYMMETRICAL imaGrpProf.minNumTxLinks --------> 1 imaGrpProf.minNumRxLinks --------> 1 imaGrpProf.txClkMode ------------> CTC imaGrpProf.txImaId --------------> 1 imaGrpProf.txFrameLength --------> M128 imaGrpProf.diffDelayMax ---------> 75 imaGrpProf.alphaValue -----------> 1 imaGrpProf.betaValue ------------> 1 imaGrpProf.gammaValue -----------> 1 imaGrpProf.testLinkIfIndex ------> 0 imaGrpProf.testPattern ----------> -1 imaGrpProf.testProcStatus -------> DISABLED imaGrpProf.txTimingRefLink ------> 0 imaGrpProf.rxTimingRefLink ------> 0 ......................... Link#1 linkType -----------> DS1_PROFILE_LINETYPE_ESF ifIndex ------------> 2 framerstatus -------> OOS netxlinkstatus -----> NOT-IN-GROUP nerxlinkstatus -----> NOT-IN-GROUP ...................................


MALC ATM OVERVIEW

This chapter describes ATM support on the MALC. It includes the following sections:

• ATM overview, page 369

• ATM data, page 370

• ATM voice, page 370

• Cross connects, page 371

• Early packet discard (EPD) and partial packet discard (PPD), page 372

• Usage parameter control (UPC), page 372

• ATM validation, page 372

• VPI and VCI ranges, page 373

• Virtual channel and virtual path links, page 374

• Service categories, page 375

• Traffic descriptors, page 376

• Connection admission control (CAC), page 379

• ATM traffic policing, page 382

• ATM statistics, page 387

Note: Read this chapter before configuring your device.

ATM overviewThe MALC supports voice, video, and data communications with different networking requirements for each signaling type. Voice traffic is sensitive to delay and transported by ATM Adaption Layer 2 (AAL2) at a Constant Bit Rate (CBR). Data traffic is not sensitive to delay and is carried over ATM Adaption Layer 5 (AAL5) at an Unspecified Bit Rate (UBR). Video streams and video–on–demand applications use Variable Bit Rate–Real Time (VBR-RT) over ATM Adaption Layer 5 (AAL5).

MALC ATM Overview


For VoATM traffic on the voice gateway card, ATM traffic destined for the voice gateway card enters through one of the MALC uplink card’s ATM interfaces and is terminated on the voice gateway card. It is sent as TDM traffic to the local exchange switch.

Figure 40 illustrates ATM on the MALC.

Figure 40: ATM on the MALC

ATM dataThe MALC communicates with subscriber integrated access devices (IADs) or DSL modems using ATM over DSL interfaces. The MALC relays the traffic to the ATM Trunking card, which provides a high-speed interface to an ATM network. The MALC can also terminate management traffic and route it over the Ethernet to a management station.

The MALC supports LLC encapsulation for AAL5 connections that it terminates.

ATM voiceFor voice traffic, the MALC supports derived voice using AAL2 over DSL interfaces. The ATM traffic is sent to the Uplink card, then onto the ATM network.

IP

ATM

Layer 3

IP ATM VCL/VPL ATM CC ATM VCL/VPLLayer 2

IP DSL ATM UNILayer 1

SAR

ATM

ATM VCL/VPL


TDM

Voice Gateway

ATM Video


On the MALC, voice is transported by ATM Adaption Layer 2 (AAL2) at a Constant Bit Rate (CBR).

The MALC supports 120 AAL2 VCLs for POTS to AAL2 and ISDN to AAL2 voice connections.

For VoATM traffic on the voice gateway card using VC-switching, the maximum number of VCs that can be allocated to an individual VC-switched VPI is determined by the zhoneAtmVpiMaxVci parameter in the atm-vpi profile.

In VP-switching, the maximum VCI value that can be allocated to an individual VP-switched VP on the voice gateway card is determined by the zhoneAtmMaxVciPerVp parameter in the atm-vpi profile.

Note: For more information on ATM support for the Voice Gateway card, see the MALC Hardware Installation Guide.

ATM VideoATM video signaling has different networking requirements than voice and data. Video streams and video–on–demand applications use Variable Bit Rate–Real Time (VBR-RT) over ATM Adaption Layer 5 (AAL5).

Each video channel requires enough bandwidth to carry compressed video plus the IP and ATM overhead. For example, if the video stream is 2.5 Mbps with maximum packet size of 1316 bytes per packet, the formula for traffic descriptor is as follows:

2500000 / 8 /1316 = 238 video packets per second

Total IP packet size = 1316 + 20 + 8 + 14 = 1358 bytes/packet

1358 bytes/packet / 48 bytes/cell = 28.333 cells/packet = 29 cells/packet

238 Packets/Sec * 29 Cells/Packet = 6902 cells/sec.

Therefore, the PCR on the traffic descriptor should be 7000.

If a system is deployed with 4 Video channels at 2.5 Mbps encoding, the traffic descriptor should be:

4 * 7000 = 28000 cells/ sec rtvbr.

Cross connectsThe MALC supports creating cross connects between any of its ATM-capable ports.

MALC ATM Overview


Early packet discard (EPD) and partial packet discard (PPD)In EPD, the ATM interface monitors the AAL5 traffic and discards an entire data frame if its output buffers do not have the space to process it. In PPD, the ATM interface drops the remaining cells of the frame if other cells of the frame have already been dropped. Both of these techniques increase the efficiency of the data transfer by dropping frames that have already been determined to be errored and will have to be retransmitted. Both EPD and PPD are disabled by default on the MALC.

Usage parameter control (UPC)UPC is the process of monitoring and controlling the ATM traffic by enforcing the traffic parameters. The MALC allows disabling of UPC on a per-traffic descriptor basis. UPC is enabled by default.

ATM validationThe Zhone CLI performs the following validation on ATM configuration:

• VCLs cannot be created using VCIs in the reserved range (0 to 31), for any VPI.

• VCLs being used in a cross connect cannot be deleted. To delete a VCL, first delete the cross connect.

• ATM traffic descriptors used in VCLs cannot be modified.

• A VCL can be used in only one cross connect.

VPI and VCI ranges


VPI and VCI rangesThe MALC supports configurable VPI/VCI ranges for all ATM-capable cards except the T1/E1 32 port card. VPI/VCI ranges are configured in atm-vpi records. Table 15 lists the VPI/VCI support for MALC cards.

Note the following about VPI/VCI ranges:

• After creating or modifying atm-vpi records, the card must be rebooted.

• A maximum of 256 VPIs can be created on a port.

As atm-vpi records are created, the system allocates connections from this pool. Each VP-switched VP uses one connection and each VC-switched VP uses one connection per allowable VC.

Table 15: VPI/VCI ranges for MALC cards

Card Default ranges Supported ranges Maximum connections per card

Uplink cards

MALC-UPLINK-DS3/E3-ATM/IP

VPI: 0 to 3VCI: 32 to 1,023

VPI: 0 to 255 (per port)VCI: 32 to 4,095 (per VCI)

16,384

MALC-UPLINK-T1/E1-ATM/TDM/IP-16

VPI: 0 to 3VCI: 32 to 511


16,384

MALC-UPLINK-OC-3C/STM1-ATM/IP

VPI: 0 to 7VCI: 32 to 1,023


16,384

Line cards

DSL (except the ADSL 48 port card)

VPI: 0 to 1 (per port)VCI: 32 to 255 (per VCI)


448 (VC-switched to Uplink)48 (VP-switched to Uplink)

MALC-ADSL-48B cards VPI: 0 to 15 (per port)VCI: 0 to 63 (per VCI)



MALC-ADSL-48-A/M VPI: 0-15VCI: 0-63

VPI: 0-63VCI: 0-63


MALC-ADSL+SPLTR-48A/M-2S




MALC-BPON-SC-1 card VPI: 0 to 63VCI: 32 to 255

VPI: 0 to 255VCI: 32 to 1,023


MALC-T1/E1-CES-12 VPI: 0 to 1VCI: 0 to 255



MALC ATM Overview


Virtual channel and virtual path linksThe MALC supports both VC and VP switching. In VC switching, cells are switched based on the VPI/VCI. In VP switching, cells are switched based on

MALC-T1/E1-ATM-32 VPI: 0 to 7(per UNI interface or IMA group)VCI: 32 to 63 (per UNI interface or IMA group)

VPI: 0 to 7VCI: 32 to 63

448 (VC-switched to Uplink)48 (VP-switched to Uplink) 496 total per card

MALC-VG-T1/E1-32-2ST1/E1 32VGMALC-VG-T1/E1-8-2S

VP-switched:VPI: 16 to 63 (per card)VCI: 32 to 8,192 (per card)

VP-switched:VPI: 16 to 63 (per card)VCI: 32 to 8,192 (per card)

448 (VC-switched to Uplink)7,680 (VP-switched to Uplink)(no external ATM interface)

MALC-ReachDSL-24 VPI: 0-7VCI: 32-63

VPI: 0-63VCI: 32-63

224 (VC-switched to Uplink) 24 (VP-switched to Uplink) 248 total per card

MALC-G.SHDSL-48 VPI: 0-7VCI: 32-127

VPI: 0-63VCI: 32-127


MALC-G.SHDSL-24MALC-G.SHDLS-4W-12

VPI: 0-15VCI: 32-63

VPI: 0-63VCI: 32-63

224 (VC-switched to Uplink) 24 (VP-switched to Uplink) 248 total per card

ADSL+POTS-TDM/PKT-48A/M-2S

Not Applicable Not Applicable Not Applicable

ADSL+POTS-TDM-48A/M-2S


MALC- ISDN 4B3T-24 Not Applicable Not Applicable Not Applicable

MALC-ISDN 2B1Q-24 Not Applicable Not Applicable Not Applicable

MALC- POTS-GBL-TDM/PKT-24


MALC-VDSL2-24 Not Applicable Not Applicable Not Applicable

MALC-ACTIVE-ETH-10 Not Applicable Not Applicable Not Applicable

MALC-DS3/E3-4 VPI: 0-3

VCI: 32-1,023

VPI: 0-255VCI: 32-1,023

MALC-EFM-T1/E1-24 Not Applicable Not Applicable Not Applicable

Table 15: VPI/VCI ranges for MALC cards (Continued)

Card Default ranges Supported ranges Maximum connections per card

Service categories


the VPI only. The VCI remains the same on both the incoming and outgoing interfaces.

A virtual channel link (VCL) used for VC switching. It is uniquely identified by an index in the form interface-index/atm/VPI/VCI where:

• interface-index is the unique name or address of the ATM layer on a given port. For example, 1-3-1-adsl/atm.

• VPI/VCI pair is a unique connection identifier on that port.

A virtual path link (VPL) is used for VP switching. It is uniquely identified by an index in the form interface-index/atm/VPI where:

• interface-index is the unique name or address of the ATM layer on a given port. For example, 1-3-1-adsl/atm.

• VPI is a unique connection identifier on that port.

VCLs/VPLs are provisioned according to RFCs 2514 and 2515. Each VCL/VPL on the MALC requires a VCL or VPL record and an associated ATM traffic descriptor.

Note: A VCL/VPL can be used in only one cross connect.

VCLs/VPLs being used in a cross connect cannot be deleted. To delete a VCL/VPL, first delete the cross connect.

If a VCL/VPL is updated with a new traffic descriptor, the VCL/VPL must be brought down, then back up to update the policing value.

Service categoriesThe MALC supports the following ATM service categories:

• constant bit rate (CBR)

• non-real-time variable bit rate (nrt-VBR)

• real-time variable bit rate (rt-VBR)

• unspecified bit rate (UBR)

Constant bit rate (CBR)

The CBR service category is used by connections that require a constant and guaranteed cell rate during the lifetime of the connection. The sampling time for CBR is constant, with no delay. Cells exceeding the provisioned PCR rate are discarded.

Non-real-time variable bit rate (nrt-VBR)

The nrt-VBR service category is used by applications that are tolerant of network delays and do not require a timing relationship on each side of the

MALC ATM Overview


connection. The nrt-VBR service supports somewhat bursty connections having less-stringent delay requirements than rt-VBR and CBR, but still require low cell loss. The source traffic descriptor is characterized by peak cell rate (PCR), sustainable cell rate (SCR), and maximum burst size (MBS).

Real-time variable bit rate (rt-VBR)

The rt-VBR service category is used by applications that require a tightly constrained delay and delay variation. The source traffic descriptor is characterized by peak cell rate (PCR), sustainable cell rate (SCR), and maximum burst size (MBS).

Unspecified bit rate (UBR)

The UBR service category does not specify traffic-related guarantees. No numerical commitments are made with respect to the cell loss ratio (CLR) experienced by the connection, or the cell transfer delay (CTD) experienced by the cells. With UBR service, the available bandwidth is fairly distributed to the active UBR subscribers.

Traffic descriptorsEach ATM endpoint requires a traffic descriptor, which defines the traffic parameters and type of service provided on ATM interfaces. Traffic descriptors are configured in atm-traf-descr records.

Quality of Service (QoS) parameters such as max cell transfer delay (maxCTD) and cell loss ratio (CLR) do not apply to a single node on the network and so are not provisioned for individual VCs.

Configuring PCR and SCR

The atm-vcl-param profile defines the allowable values for the PCR and SCR for certain traffic types. The values in this profile are used as follows:

• The SCR for rt-VBR traffic descriptors must use one of the first 16 rates (vcl-rate-param1 through vcl-rate-param16)

• The PCR for CBR traffic descriptors can use any of the 32 rates.

• For a UBR traffic descriptor, if usage-parameter-control in an ATM traffic descriptor is set to false, or if PCR is greater than the modem trained rate, then the UBR traffic is shaped to one of the 32 rates. The shaper will pick a rate that is equal to or less than the modem trained rate. If there are multiple rates less than the modem trained rate, the one closest to the trained rate will be selected.

Each PVC on the MALC is assigned a PCR of 182 cells per second (for G.711 voice calls) or 91 CPS (for G.726 voice calls). An initial 182 CPS is needed to support sending and receiving of CAS packets.

Traffic descriptors


To support voice VCs use the following formulas:

For G.711 calls, use the formula:

• PCR = (CIDS per VC * 182) + 182

• SCR = (CIDS per VC * 3/5) + (CIDS per VC * 182)

For G.726, use the formula:

• PCR = (CIDS per VC * 91) + 91

• SCR = (CIDS per VC * 3/5) + (CIDS per VC * 91)

For example, 8 CID per VC produces the following values for PCR and SCR:

PCR=1638 CPSSCR=1460 CPS

Note: When fax and modems calls are connected on G.726 compress mode, the full 182 CPS are used.

Traffic descriptor parameters

Table 16 shows the required parameters used to define MALC traffic descriptors and the validation rules associated with them.

Table 16: ATM traffic descriptor parameters

Service category

TD type td_param1 td_param2 td_param3 td_param4

CBRUBR

atmNoClpNoScr (TD type 2) OID 1.3.6.1.2.1.37.1.1.2

PCR for CLP=0+1 trafficmust be > 0For CBR, must match a value in atm-vcl-param profile

Not used Not used Not used

UBR atmClpTaggingNoScr (TD type 4)OID 1.3.6.1.2.1.37.1.1.4

PCR for CLP=0+1 trafficmust be > 0

PCR for CLP=0 traffic, excess traffic tagged as CLP=1must be > 0

Not used Not used

nrt-VBRrt-VBR

atmClpNoTaggingScr(TD type 6)OID 1.3.6.1.2.1.37.1.1.6

PCR for CLP=0+1 traffictd_param1 > td_param2

SCR for CLP=0 trafficFor rt-VBR, must match a value in atm-vcl-param profilemust be > 0

MBSmust be > 1

Not used

MALC ATM Overview


nrt-VBRrt-VBR

atmClpTaggingScr (TD type 7)OID 1.3.6.1.2.1.37.1.1.7


SCR for CLP=0 traffic, excess traffic tagged as CLP=1For rt-VBR, must match a value in atm-vcl-param profilemust be > 0

MBSmust be > 1

Not used

CBR atmClpTransparentNoScr(TD Type 9) OID 1.3.6.1.2.1.37.1.1.9

PCR Must match a value in atm-vcl-param profilemust be > 0

CDVTmust be > 0

Not used Not used

nrt-VBRrt-VBR

atmClpTransparentScr(TD Type 10)OID 1.3.6.1.2.1.37.1.1.10

PCR for CLP=0+1 trafficmust be > 0


MBS CDVT

CBR atmNoClpNoScrCdvt(TD Type 12) OID 1.3.6.1.2.1.37.1.1.12

PCR must be > 0Must match a value in atm-vcl-param profile

CDVTmust be > 0

Not used Not used

nrt-VBRrt-VBR

atmClpNoTaggingScrCdvt (TD type 14)OID 1.3.6.1.2.1.37.1.1.14



MBSmust be > 1

CDVT

nrt-VBRrt-VBR

atmClpTaggingScrCdvt(TD type 15)OID 1.3.6.1.2.1.37.1.1.15


SCR for CLP=0 traffic, excess traffic tagged as CLP=1For rt-VBR, must match a value in atm-vcl-param profilemust be > 0

MBSmust be > 1

CDVT

Table 16: ATM traffic descriptor parameters (Continued)

Service category

TD type td_param1 td_param2 td_param3 td_param4

Connection admission control (CAC)


Tip: Refer to the following specifications for more information about traffic descriptors:

• ATM Forum, ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, 1994.

• ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, November 1994.

Traffic descriptor configuration rules

Note: When configuring the traffic descriptors, it is important that they follow the rules described in this section. A traffic descriptor cannot be saved if the parameters violate these rules.

Note the following information about traffic descriptors on the MALC:

• ATM traffic descriptors used in active VCLs cannot be modified. To modify a traffic descriptor, first bring down VCLs that use the descriptor.

• For atmNoClpNoScr with a service category of rtvbr, trnk-vcl-rate of unused is allowed for backward compatibility. If set to unused, the system uses a rate-16k for the purposes of CAC.

Connection admission control (CAC)MALC Uplink cards support connection admission control (CAC) and provisioning of oversubscription factors on a per port basis. The CAC functions on the Uplink card will not accept new connections if they exceed the remaining bandwidth. Note the following about CAC and service categories:

• For CBR VCLs, the PCR value of each VCL is subtracted from the available rt-VBR bandwidth to determine whether the VCL can be created.

• For rt-VBR VCLs, the SCR value of each VCL is subtracted from the available rt-VBR bandwidth to determine whether the VCL can be created.

• For nrt-VBR VCLs, the SCR of each VCL is subtracted from the available nrt-VBR bandwidth to determine whether the VCL can be created.

• For UBR VCLs, CAC does not apply. The system will provide up to the bandwidth configured for UBR connections, if the bandwidth is available.

MALC ATM Overview


CAC oversubscription

CAC enables the ATM interface to service more data VCL connections than the bandwidth allows. Because not all connections are likely to be active at the same time, an interface can support a larger number of PVCs.

When oversubscription is enabled, CAC calculates available bandwidth in the system by dividing the SCR (for nrt-VBR or rt-VBR VCLs) value by the cac-divider parameter in the atm-traf-descr. It then uses that value to determine if the VCL can be created.

For example, to oversubscribe bandwidth at a rate of 4:1, set cac-divider to 4. By default, oversubscription is not enabled and the cac-divider is set to 1.

Note that CAC oversubscription should not be used to oversubscribe AAL2 voice connections.

Bandwidth allocation for ATM cards

The bandwidth allocated to ATM traffic types and used by CAC is specified in the card-atm-configuration parameter in the card-profile for the Uplink cards. (See Table 17.)

Table 17: ATM bandwidth allocation

Setting DS3 104,268 CPS

E3 80,000 CPS

T1 28,976 CPS total (8 T1s)/ 3622 each

E1 36,224 CPS total (8 E1s)/ 4528 each

OC-3/STM1353,207 CPS

vbnrt95rt5UBR 1%nrt-VBR: 94%CBR/rt-VBR: 5%

1,042 CPS98,011 CPS5,213 CPS

800 CPS75,200 CPS4,000 CPS

289 CPS27,237 CPS1,448 CPS

362 CPS34,050 CPS1,811 CPS

3,532 CPS332,014 CPS17, 660 CPS

vbnrt80rt15UBR: 5%nrt-VBR: 80%CBR/rt-VBR: 15%

5,213 CPS83,414 CPS15,640 CPS

4,000 CPS64,000 CPS12,000 CPS

1,448 CPS 23,180 CPS4,346 CPS

1,811 CPS28,979 CPS5,433 CPS

17, 660 CPS282,565 CPS52,981 CPS


5,213 CPS67,774 CPS31,280 CPS

4,000 CPS52,000 CPS24,000 CPS

1,448 CPS18,834 CPS8,692 CPS

1,812 CPS 23,545 CPS10,867 CPS

17, 660 CPS229,584 CPS105,962 CPS


5,213 CPS52,134 CPS46,920 CPS

4,000 CPS40,000 CPS36,000 CPS

1,448 CPS14,488 CPS13,039 CPS

1,811 CPS 18,112 CPS16,300 CPS

17, 660 CPS176,603 CPS158,943 CPS

Connection admission control (CAC)


Table 18 shows the parameters used by CAC for specified service categories.


5,213 CPS36,493 CPS62,560 CPS

4,000 CPS28,000 CPS48,000 CP

1,448 CPS10,141 CPS17,385 CPS

1,811 CPS 12,678 CPS21,734 CPS

17, 660 CPS123,622 CPS211,924 CPS


5,213 CPS20,853 CPS78,201 CPS

4,000 CPS16,000 CPS60,000 CPS

1,448 CPS5,795 CPS21,732 CPS

1,811 CPS 7,244 CPS27,168 CPS

17, 660 CPS70,641 CPS264,905 CPS


1,042 CPS5,213 CPS98,011 CPS

800 CPS4,000 CPS75,200 CPS

289 CPS1,448 CPS27,237 CPS

362 CPS1,811 CPS 34,050 CPS

3,532 CPS17, 660 CPS332,014 CPS

Table 17: ATM bandwidth allocation (Continued)

Setting DS3 104,268 CPS

E3 80,000 CPS

T1 28,976 CPS total (8 T1s)/ 3622 each

E1 36,224 CPS total (8 E1s)/ 4528 each

OC-3/STM1353,207 CPS

Table 18: Service category traffic descriptor parameters

Service category Parameters specified CAC

CBR td_param1 (peak cell rate (PCR))td_param2 (cell delay variation tolerance (CDVT))

td_param1 (PCR)

nrt-VBR td_param1 (peak cell rate (PCR))td_param2 (sustained cell rate (SCR))td_param3 (maximum burst size (MBS))td_param4 (cell delay variation tolerance (CDVT))

td_param2(SCR)

rt-VBR td_param1 (peak cell rate (PCR))td_param2 (sustained cell rate (SCR))td_param3 (maximum burst size (MBS))td_param4 (cell delay variation tolerance (CDVT))

td_param2(SCR)

UBR td_param1 (peak cell rate (PCR)) N/A

MALC ATM Overview


Example CAC calculation

The following is a sample calculation on DS3 Uplink card with a line speed of 104,268 CPS (the DS3 line rate of 45,000,000 bits/sec minus overhead) and no oversubscription:

If the atm-configuration parameter is set to vbnrt20rt75, the ATM bandwidth allocation is as follows:

104,268 * 0.20 = 20,853 CPS is allocated to nrt-VBR

104,268 * 0.75 = 78,201 CPS is allocated to rt-VBR

104,268 * 0.05 = 5,213 is allocated to UBR

For CBR or rt-VBR traffic, the CAC algorithm is the same.

ATM traffic policingThe MALC polices traffic using the ATM continuous-state leaky bucket algorithm. It monitors the incoming ATM cells to ensure that they adhere to the VCL traffic descriptors. If they do not, they are either dropped or tagged with a lower cell loss priority (CLP), depending on which traffic descriptor is in use for the VCL.

Tip: For more information about traffic policing, refer to ATM Forum Traffic Management Specification Version 4.0 and ITU-T I.371.

Enforcing SCR and MBS

Bucket B polices SCR and MBS parameters. It applies to the following TD types:

• atmClp NoTagging Scr (TD type 6)

• atmClp Tagging Scr (TD type 7)

• atmClpNoTaggingScrCdvt (TD type 14)

Total bandwidth available for rt-VBR VCL 20,853 CPS

nrt-VBR VCL # 1 with SCR 12,000. Since there is enough available bandwidth, CAC allows the VCL

-12,000 CPS

Remaining bandwidth for rt-VBR VCLS 8,853 CPS

nrt-VBR VCL # 2 with SCR of 9,000 -9000 CPS

VCL rejected by CAC, not enough available bandwidth

Traffic shaping


• atmClpTagging ScrCdvt (TD type 15)

Bucket B uses the following formula:

cdvt_btB = 1,000,000/SCR + [(MBS - 1)*(1,000,000/SCR - 1,000,000/PCR)]

For these traffic descriptors, limit = cdvt_btB * F/68.

where F is

• 100 for MALC OC-3c/STM1 cards and MALC DS3/E3 cards

• 50 for DSL line cards and MALC T1/E1 IMA cards

Bucket B either drops or tags non-conforming cells, depending on the TD type. It then passes the cells that have not been dropped to bucket A.

Enforcing PCR and CDVT

Bucket A polices PCR and CDVT parameters. It applies to all TD types. Bucket A uses the following formula:

cdvt_btA = [(td_param2 or td_param4)/10.0]

where:

td_param2 is CDVT for CBR VCLs with the exception of AtmNoClpNoScr traffic type

td_param4 is CDVT for rt-VBR VCLs

If the CDVT is not specified, the default value of 30000 (tenths of microseconds) is used.

For these traffic descriptors, limit = cdvt_btA * F/68.

Bucket A drops cells that do not conform to the PCR.

General policing rules

ATM traffic descriptors must adhere to the following rules:

• The limit must be within the following range:

1 < limit < 1,966,080 (1.8751 * 0x100000)

• cdvt_btA and cdvt_btB must be greater than 68/F

where F is

• 100 for MALC OC-3c/STM1 cards and MALC DS3/E3 cards

• 50 for DSL line cards and MALC T1/E1 IMA cards

Traffic shapingThe MALC provides traffic shaping features for most uplink cards that protects the cards from being disabled by data flooding. Each uplink card has

MALC ATM Overview


a limit to the amount of incoming data that can enter it in a given time interval. Once the threshold of maximum data allowed into the card has been exceeded, the uplink port will partition or become disabled.

Two types of instances exist where port disabling can occur because of data overflow.

• benevolent transmissions are sent to the card that contains large amounts of oversize packets or cells, for video and voice data for use by the customer. Sometimes, the amount of data exceeds the amount of incoming packets or cells that the port can handle, inadvertently disabling the port.

• malicious transmissions are sent to the card that contain deliberately large amounts of oversize packets or cells for any application, designed explicitly to bring down the network. The amount of data exceeds the amount of incoming packets or cells that the port can handle, maliciously disabling the port.

The MALC provides automatic traffic shaping that helps manage the flow of packets or cells sent to the uplink card.Using defined service categories, the MALC now ensures that the uplink card port cannot be overloaded and disabled.

The MALC uses the service categories described in the following table to perform the traffic shaping:

CBR, nrt-VBR, and rt-VBR each enable traffic shaping that will limit incoming packets to the uplink port. Note that if you have the UBR value specified as the Service Category in the profile, traffic shaping will be disabled and no rate limiting will be applied to incoming packets. Other traffic descriptor variables related to service are described in the following table.

Table 19: Common Service Category Values

Service Category Description

CBR Constant bit rate. Used by connections that require a constant and guaranteed cell rate during the lifetime of the connection.

nrt-VBR Non-real-time variable bit rate. Used by applications that are tolerant of network delays and do not require a timing relationship on each side of the connection.

rt-VBR Real-time variable bit rate. Used by applications that require a tightly constrained delay and delay variation.

UBR Unspecified bit rate. Does not specify traffic-related guarantees.

Traffic shaping


Listing traffic descriptors and Peak Cell RatesTo configure traffic shaping limits, you need to change PCRs (Peak Cell Rates) in the traffic descriptor associated with the card. To identify the traffic descriptor you need to change, display existing traffic descriptors by issuing the list atm-traf-descr command.

To list ATM traffic descriptors issue the list atm-traf-descr command:

zSH> list atm-traf-descratm-traf-descr 1atm-traf-descr 49050atm-traf-descr 1210atm-traf-descr 2000

Configuring traffic shaping in traffic descriptorsTo change the PCR values of the traffic descriptor, display the contents of the desired descriptor using the get command. The following example presupposes you want to perform traffic shaping on the traffic descriptor with the 49050 value.

1 To display traffic descriptor values:

zSH> get atm-traf-descr 49050td_type: ----------------------> {atmNoClpNoScr}td_param1: --------------------> {49050}td_param2: --------------------> {0}td_param3: --------------------> {0}td_param4: --------------------> {0}td_param5: --------------------> {0}cac-divider: ------------------> {1}td_service_catgory: -----------> {ubr}td_frame_discard --------------> {false}usage-parameter-control -------> {true}

Table 20: Traffic Descriptor Variables for Traffic Shaping

Variable Description

PCR Peak Cell Rate. This variable indicates the top-level threshold that identifies the most amount of traffic in Mbps that can enter the uplink port. Maps to the td_param1.

SCR Sustained Cell Rate. This variable is time-oriented, indicating the maximum amount of traffic in Mbps that can pass through the uplink port over a preset period of time. Maps to td_param2.

CVR Cell Variation Delay. This variable indicates the amount of time that the uplink can wait to accept traffic. Maps to td_param3.

MALC ATM Overview


Note that td_param1 is the variable that contains the PCR value for this traffic descriptor.

You have now changed the PCR from 49,050 Mbps to 500 Mbps.

2 To change the PCR value, issue the update atm-traf-descr command. This example shows limiting the allowable incoming traffic rate (PCR) of 500 Mbps.

zSH> update atm-traf-descr 49050Please provide the following: [q]uittd_type: ----------------------> {atmNoClpNoScr}:td_param1: --------------------> {49050}: 500td_param2: --------------------> {0}:td_param3: --------------------> {0}:td_param4: --------------------> {0}td_param5: --------------------> {0}cac-divider: ------------------> {1}:td_service_category: ----------> {ubr}td_frame_discard: -------------> {false}usage-parameter-control -------> {true}...................Save changes? [s]ave, [c]hange or [q]uit: s

Shaping for non-ADSL2+ cards with GigE uplinks

Shaping for non-ADSL2+ cards with GigE uplinks is performed on the GigE uplink card (MALC-UPLINK-2-GE, MALC-UPLINK-GE).

Constant Bit Rate (Cbr) is the highest priority.

For Unspecified Bit Rate (Ubr), the Peak Cell Rate (Pcr) as specified in the traffic descriptor parameter td-param1 is enforced.

For Variable Bit Rates (Vbr-nt, Vbr-Nrt), the Peak Cell Rate (Pcr) as specified in the traffic descriptor parameter td-param1 and Sustained Cell Rate (Scr) as specified in the traffic descriptor parameter td-param2. Burst up to the Pcr are allowed with regular traffic at the Scr. The minimum scheduler rate is restricted to multiples of 167 frames per second and 535 frames per second for depending on the type of line card to which traffic is sent.

Line cards with rates restricted to multiples of 167 frames per second:

• MALC-ADSL-48A, MALC-ADSL+POTS-TDM-48A-2S, MALC-ADSL+POTS-TDM/PKT-48A-2S

• MALC-ADSL-48B

Line cards with rates restricted to multiples of 535 frames per second:

• MALC-BPON-SC-1

• MALC-DS3/E3-4

• MALC-POTS-GBL-TDM/PKT-24

• MALC-ISDN4B3T-24

ATM statistics


• MALC-ISDN2B1Q-24

• MALC-SHDSL-48

• MALC-G.SHDSL-24

• MALC-G.SHDSL-4W-12

For all types of rates, the rate specified for the traffic descriptor parameters is rounded up to the next multiple of the minimum rate.

Traffic shaping for 1.13.x and higher mixed IP and ATM networks

When the MALC SLMS software loads transitioned from Release 1.12.x to 1.13.x, traffic descriptor orientations changed so that the concept of an ATM uplink with TX and RX directions do not exist. Instead, the MALC uses the ATM TX and RX settings of the line card and then reflects them, in reverse for the uplink side. For example:

• Line card ATM TX = 4000, RX= 8000

• Uplink ATM TX = 8000, RX = 4000

The required upstream and downstream DSL maximum line rates (service guaranteed rate) should equal the TD rate plus 15% for margin. Also, recommended is to set the asymmetrical min and max rates at the same number creating both a stable and predictable flow control.

The MALC shapes UBR traffic in the downstream direction using the td-param1 traffic descriptor that's set for a particular port. The subscriber will be able to send traffic at the provisioned and trained line rate.

• Downstream Direction = ADSL port at 115% of required downstream line rate. Traffic regulated with the UBR ATM traffic descriptor at 100%

• Upstream Direction = ADSL port set to 115% of required upstream line rate. UBR ATM traffic descriptor is not used and should be set to match the downstream.

Symmetrical (Upstream and Downstream) traffic descriptors are strongly recommend to simplify the TX and RX calculations.

ATM statisticsReal-time ATM statistics on the MALC are provided through the NetHorizhon ZMS client. ZMS supports the following ATM statistics:

• ATM VCL

• ATM VPL

• AAL2

The ZMS performance manager periodically collects real-time statistical data. You can monitor real-time data at a polling interval of your choice. For

MALC ATM Overview


information on how to access ZMS ATM statistics, refer to the NetHorizhon User’s Guide and the NetHorizhon online help.


INDEX

A

accessing the flash cardcd command 338dir command 338pwd command 338

acronyms, described 12activating slot cards

ADSL cards 272, 278, 280, 290adding a user, description of 344adding routes

description 50route add command 50

addressesassigned via DHCP 51

admindeleting user account of 346

administrationconfiguring traps 321creating SNMP access lists 320creating SNMP community names 320logging 309saving and restoring configurations 343user accounts 344

ADSLlow power alarm 335

alarm suppression 336alarms

low power ADSL 335viewing card and shelf 351

alarms, viewing 327A-Law

setting 198always offhook, configuring 217ARP, broadcasts and bridging 103ata command, use of 339ATM

bridging and IP support on VC 96, 98CAC 380cross connects 371EPD and PPD 372overview 369PVCs supported per card 373SCR and PCR 376

SCR and PCR, configuring allowable values for 160

statistics 387traffic descriptor configuration rules 377traffic descriptor validation 383traffic descriptors 376

general rules 379traffic policing 382UBR and usage-parameter-control 160video 371voice overview 370VPI/VCI ranges 373

ATM cell relay connectionconfiguration 157, 163creating cross-connect 170, 171creating traffic descriptor 157, 163creating VCLs 168, 169creating VCLs and VPLs 166

ATM cell termination connectionadding IP route to remote LAN 23configuration 24creating IP interface 25verifying IP interface 23

ATM data connectioncell relay 157, 163configuration 370data communications 370traffic descriptors 376VCLs 375VPLs 375

ATM management connectioncreating IP interface 25

ATM OC3-c interfacesloopbacks 362

ATM on Zhone devicesdata communications 370overview 370virtual channel links 375virtual path links 375

ATM traffic descriptorcreating 24

Index


B

BER test, described 354binding interfaces 341bootfile parameter 55boot-server parameter 55BRAs 137bridge statistics 150bridgeinsertpppoevendortag 141bridging 106

adding untagged bridge 114administrative commands 149ARP broadcast 103broadcasts and 103custom DHCP server 146forbid OUI 141intralinks 97option 82 141, 145overview 96support on VC 96, 98VLAN 107VLAN bridge-paths 106VLAN configuration 106VLAN overview 105VLAN strip and insert 145

broadcast suppression, described 146

C

CACdescribed 380

call conferencing, SIP 225call progress parameters 252caller, rejecting malicious 225caller-id-sig-protocol 253calls

checking bandwidth before accepting a call 199cards

VG-T1/E1-32-2S 269cd command, use of 338cdvt_btA, formula used to calculate 383cdvt_btB, formula used to calculate 383change default passwords, how to 345channel bank, configuring system 230chassis

viewing errors 351viewing temperature 351

Class of Service (COS) 110, 150clid-mode 253

client leases, DHCP 93clientId parameter 63client-match-string parameter 63clock

setting system using NTP 344commands

ata 339cd 338dir 338host add 41host delete 91host show 89ifxlate 25image 339interface add 46interface delete 91interface show 90log 312log show 312mcast 86pwd 338rip 49rip show 90route 79route add 50route delete 91route show 90stack bind 342

configurable jitter buffer 249configuration

ATM cell relay connection 157, 163ATM cell termination connection 24ATM data connection 370ATM VCLs and VPLs 166CLI disabled 26creating DHCP server subnet options 54creating dhcp-server-group profile 62creating dhcp-server-host profile 63DHCP server 51DNS resolver 64Ethernet management channel 39host-based routing 41interface indexes 179, 188IP filters 66local management channel 20logging in 21logging out 21network-based routing 46overview of profiles 15RIP 49


saving and restoring 343configuring ATM data connection

ATM cell termination connection 24ATM on Zhone devices 370cell relay connections 171

configuring IPDHCP server 51displaying routing information 90DNS resolver 64host-based routing 41IP filters 66modifying host and interface routes 87network-based routing 46RIP 49static routes 50

configuring management interfaceaccessing the serial port 20local management channel 20logging in and out 21

configuring physical interfacesloopbacks 362

configuring traps, description of 321COS processing 59COS, in VLAN headers 110, 150craft interface 21creating IP interface

adding route to remote LAN 23description 25ifxlate 25specifying VPI/VCI pair 25verifying the interface 25

creating IP management interfacedescription 25

creating SNMP access lists, description of 320creating SNMP community names, description of

320cross-connect, creation of 170, 171

D

D channel status, ISDN PRI 301Data rate

delay criteria 375throughput criteria 375

data, voice, video 307default configuration, description of 16default passwords, changing 345default-lease-time parameter 55default-router parameter 55

deleting a user, description of 345, 346deleting hosts 91deleting interfaces 91deleting routes

description 91route delete command 91

DHCPaddress assignment 51advanced applications 62broadcast suppression 146creating subnet options 54custom DHCP setting in bridge records 146enabling a DHCP server 56external server 58logging 92logging messages described 92profiles 51relay 57setting server options 52

DHCP client leases 93DHCP server 29DHCP server, enabling 56DHCP, description of 29dhcp-server-group profile 62dhcp-server-host profile 52, 63dhcp-server-subnet profile 54dialing plan 223dir command, use of 338displaying host information 89displaying interface information 90displaying RIP information 90displaying routing information

rip show command 90route show command 90routing table 90

DNS resolver configurationcreating a host profile 65creating a resolver record 65

DNS, description of 28Domain Name System, see DNSdomain parameter 55, 65domain-name parameter 55DS1 to POTS

configuring connection 230DS3

call admission control 379dual counter rotating rings, RPR 119Dynamic Host Control Protocol, see DHCP

Index


E

encodingtypes supported 198

EPD, described 372errors, viewing system 351Ethernet

Linear GigaBit configuration 132Linear GigaBit redundancy configuration 134Resilient Packet Ring (RPR) 116

Ethernet interfaceconfiguration 22creating a default route 23, 40creating a route from management PVC to 25IP interface 22route show command 23, 40verifying 22verifying the route 23, 40

Ethernet management channel 39

F

fax service, T.38 263first-nameserver parameter 65

G

GigE-2 cardLinear GigaBit Ethernet configuration 132Linear GigaBit Ethernet redundancy 134

GPON configuration 307GR-303

configuring 178

H

H.248, configuring 211hookflash

configuring 216configuring timers 216

host add command 41host delete command 91host profile 66host show command 89hostalias1 parameter 66hostalias2 parameter 66hostalias3 parameter 66hostalias4 parameter 66host-based routing

configuration 41description of 34

hostname parameter 66huntgroups 219hwaddr parameter 63

I

if-translate profilerenaming interfaces in 342

image command, use of 339interface add command 46interface delete command 91interface groups

number supported on Voice Gateway card 271interface indexes, configuration of 179, 188interface show command 90

commandsinterface show 90

interfacesrenaming 342

intermediate agent, PPPoE 140internetworking, PPPoA-PPPoE 137Intralinks

configuring 97IP

addresses for redundant Uplink cards 22administrative procedures 86advanced provisioning procedures 62applications 31DHCP external server 58DHCP relay 57overview 27provisioning procedures 39routing 31support on VC 96, 98video, configuring 82

IP filteringdescription of 37

IP filtersconfiguration 66

IPSLA 69ISDN

loopbacks 365

J

jitter buffer 249


L

lease-time parameter 53Linear GigaBit Ethernet, configuration 132Linear GigaBit Ethernet, redundancy configuration

134local management channel 20log messages, description of content for 309logging

description 309DHCP 92DHCP messages described 92displaying persistent logs 314enabling/disabling 310enabling/disabling for session 21enabling/disabling over the serial craft port 21log messages 309modifying logging levels 312syslog, configuring 314

logging in and outdescription 21logout command 21timeout command 21

logging in, restricting telnet access 352logging levels, log command and modifying 312logging out, described 21loopbacks

DS3 363ISDN 365T1 363

loopbacks, SONET and 362

M

malicious caller, rejecting 225management

configuring interface for 22creating route from management PVC to

Ethernet 25creating VLAN for 22ZMS 25

managmentZhone Web Config Tool 17

max-lease-time parameter 53, 55mcast command, described 86Megaco, configuring 211MGCP

configuring 205MGCP, configuring 209

min-lease-time parameter 53, 55Mu-Law

setting 198multicast

creating control list 85

N

name parameter 62, 63netmask parameter 55network parameter 55network-based routing

configuration 46description of 35

NTPconfiguring 344

O

option 82, bridging 145option 82, described 141OUI forbin, described 141

P

packet-rule 144parameters

bootfile 54boot-server 54clientId 63client-match-string 63default-lease-time 54default-router 54domain 54, 65domain-name 54first-nameserver 65hostalias1 66hostalias2 66hostalias3 66hostalias4 66hostname 66hwaddr 63lease-time 53max-lease-time 53, 54min-lease-time 53, 54name 62, 63netmask 54network 54primary-name-server 54

Index


query-order 65range1-end 54range1-start 54range2-end 54range2-start 54range3-end 54range3-start 54range4-end 54range4-start 54reserve-end 53reserve-start 53secondary-name-server 54second-nameserver 65third-nameserver 65vendor-match-string 63

passwords, changing default 345PCM encoding

type supported 198persistent logs, displaying 314policing, ATM 382POTS

DS1 to POTS 230power

ADSL low power alarm 335PPD, described 372PPP tunnel 137PPPoA-PPPoE internetworking 137PPPoE intermediate agent 140primary-name-server parameter 55profiles

dhcp-server-group 62dhcp-server-host 52, 63host 66overview of configuration 15resolver 65, 66

protection switching, RPR 124PVCs

number supported per card 373pwd command, use of 338

Q

QoS and traffic descriptorsQoS categories

described 375non-real-time variable bit rate 375

Quality of Service, see QoSquery-order parameter 65

R

RADIUS 347range1-end parameter 55range1-start parameter 55range2-end parameter 55range2-start parameter 55range3-end parameter 55range3-start parameter 55range4-end parameter 55range4-start parameter 55redundancy

IP addresses and 22reserve-end parameter 53reserve-start parameter 53resetting passwords, description of 346Resilient Packet Ring (RPR)

bridged traffic 130configuration 123configuration display 125overview 116protection switching 124ring status 128statistics 129topology 118topology display 126

resolver profile 65, 66ring cadence 252RIP

configuration 49configuring global defaults 49description 29displaying information 90rip command 49

rip show command 90route command 79routing

description 31routing information base 31

routing in Zhone systemsroute types 31

routing information base, description of 31Routing Information Protocol, see RIProuting table, displaying 90RPR 116

S

SABR 30, 51


Saving and restoring configurations 343saving and restoring configurations

description 339secondary-name-server parameter 55second-nameserver parameter 65security

restricting telnet access 352server-max-timer, voice-system profile 206service level agreement, SLA 69Service, quality objectives 375SIP

connections over different networks 204SIP, call conferencing 225SIP, calls not registering 206sip-dialplan 223SLMS Web Interface Tool 19SNMP

statics, gathering 322SONET

loopbacks 362source address based routing 30, 51stack bind 342static routes

adding routes 50configuration 50deleting routes 91

statisticsATM 387bulk 322

statistics, bridge interfaces 150strip and insert

configuring 145subtending, example

ATMsubtending 172

syslog server, configuring 314system

configuring ATM data connection 370configuring management interface 20data communications 370default configuration 16Ethernet interface 22logging out 21management interface 22Uplink cards 22

system profilevoice configuration 198

T

T.38 fax service 263T.38, on voicegateway 276T1 loopbacks

activating 361, 364tagged bridging

described 96telnet

restricting access 352temperature, viewing chassis 351terminal interface, settings for 20TFTP server 353third-nameserver parameter 65three-way call conferencing 225TOS processing 59tosCOS 61tosOption 61traffic descriptors

configuration rules 377creation 157, 163description 376QoSrules for 379validation for 383

trapsconfiguring 321

Type of Service (TOS) 59

U

UBRmodem train rates and 160

unnumbered IP interfacesdescription of 38

untagged bridgingdescribed 96

Uplink cardredundancy and IP addresses 22

Uplink cardsconfiguration 22VOIP support and 270

user accountsadding a user 344changing default passwords 345deleting a user 345deleting admin 346resetting passwords 346

using flash cards

Index


using the ata command 339using the image command 339

V

V5.2activating the IG 194C-channels 190C-paths 192IG 187parameters 184provisioning links 189

V5.2 profile, configuring 183VCI

allowed ranges 373VCLs

creation 168, 169description 375

VCLs and VPLscreation 166

vendor-match-string 63video

ATM 371configuring IP 82mulitcast control list 85

virtual channel link, see VCLVLAN

bridge-paths and 106creating management 22

VLAN IDs supported 106vlanCOS 61VLANs

adding bridge 107configuring 105, 106IDs supported 106overview 105strip and insert 145

VoATM to TDM voice connections 280voice

always offhook 217configuring MGCP 205configuring VOIP 203hookflash 216hookflash timers 216POTS to DS1 230POTS to VOIP 215, 297VoATM to TDM connections 280voice gateway 269VOIP to TDM connections 272

voice configurationchecking bandwidth before accepting a call 199PCM encoding supported 198system profile 198

voice gatewayconfiguration 270overview 269VoATM to TDM connections 280VOIP to TDM connections 272

Voice Gateway cardnumber of IGs supported 271Uplink cards supported with 270VP- and VC-switching on 281

VOIPalways offhook, configuring 217call progress parameters 252configuring voice gateway connections 203hookflash, configuring 216hookflash, configuring timers 216malicious caller 225POTS to VOIP 215, 297ring cadence 252SIP connections 204Uplink cards that support 270

VOIP to TDM voice connections 272voip, country-specific dialing features 251VPI

allowed ranges 373VPLs

description 375

W

Web Configuration Toolconfiguraiton, Web tool 17

Web Interface Tool 19

Z

ZMSCLI configuration disabled 26managing device with 25

830-00990-13 Configuration Guide for Software Version 1.14.1

Documents

Transcript of 830-00990-13 Configuration Guide for Software Version 1.14.1