Table of Contents

Contents
Introduction
System Requirements

Memory Requirements
Hardware Supported
Determining the Software Version
Upgrading to a New Software Release
Feature Set Table

New and Changed Information

New Hardware Feature in Cisco IOS Release 12.0(7)T

Video over ATM Switched Virtual Circuits on the Cisco MC3810

New Software Features in Cisco IOS Release 12.0(7)T

Cisco H.235 Accounting and Security Enhancements for Cisco Gateways
Cisco H.323 Multizone Enhancements
Frame Relay---ATM Service Interworking---FRF.8 on the Cisco MC3810
Frame Relay---ATM Network Interworking---FRF.5 Enhancement on the Cisco MC3810
Gateway Support for Alternate Gatekeeper
Low Latency Queueing (CSCdm84810)
Multicast Source Discovery Protocol
Voice over ATM Switched Virtual Circuits on the Cisco MC3810
X.25 Closed User Groups
X.25 Switch Local Acknowledgment

New Software Features in Cisco IOS Release 12.0(5)T

AAA Server Group
ATM LANE Fast Simple Server Replication Protocol
CNS Client for Cisco IOS Software
DLSw+ Ethernet Redundancy
DLSw+ Fast HPR
DNS-Based X.25 Routing
Frame Relay End-to-End Keepalive
H.323 Version 2 Support (Gatekeeper and Proxy Features)
IP RTP Priority
IPX Display and Debug Enhancements
ISDN Cause Code Override
Multimedia Conference Manager Enhancements
PAD French Enhancement
PGM Router Assist
Service Assurance Agent
Subnetwork Bandwidth Manager
Tunnel Endpoint Discovery
Voice over Frame Relay Queuing Enhancement
X.25 Remote Failure Detection

New Hardware Feature in Cisco IOS Release 12.0(4)T

ISDN BRI Voice on the Cisco MC3810

New Software Features in Cisco IOS Release 12.0(4)T

QSIG Digit Forwarding on the Cisco MC3810
Voice over Frame Relay Using FRF.11 and FRF.12

New Software Features in Cisco IOS Release 12.0(3)T

Annex G (X.25 over Frame Relay)
CDP Additions for Cisco IOS
DLSw+ Enhanced Load Balancing
DLSw+ Peer Clusters
DLSw+ RSVP Bandwidth Reservation
Fancy Queuing on Frame Relay for Cisco HDLC
Local Voice Busy Out
Multimedia Conference Manager
Priority Queuing Support Enhancement for Cisco MC3810-IGX Interworking
Process MIB
Response Time Reporter Enhancements
SNMP v3

New Hardware Feature in Cisco IOS Release 12.0(2)T

Multiflex Trunk Module with Integrated BRI Interface

New Software Features in Cisco IOS Release 12.0(2)T

Call Detail Records
Cisco MC3810 - IGX 8400 Interworking
Common Channel Signaling Features
Default Routes
Facility Data Link (FDL) Capability on the Multiflex Trunk Module
G.726 (ADPCM)
Multi-Length Dial Patterns
OPX Ring-Through
Preference-Based Hunt Group

Existing IOS Features Supported on the Cisco MC3810 in Cisco IOS Release 12.0(2)T

Important Notes

Cisco IOS Syslog Failure

Affected Devices and Software Versions
Solution
Workarounds
Software Versions and Fixes

Serial Interface Command Change in Cisco IOS Release 12.0(2)T
Deprecated MIBs
Using the Cisco MC3810 with QSIG or BRI
Using the Cisco MC3810 with the PSTN

Connections to the PSTN
Switched Access from the PSTN
Non-Switched Calls

Caveats

Release-Specific Documents
Feature Modules
Cisco IOS Software Documentation Set

Documentation Modules
Cisco IOS Release 12.0 Documentation Set

Service and Support

Software Configuration Tips on the Cisco Technical Assistance Center Home Page

Cisco Connection Online
Documentation CD-ROM

Release Notes for Cisco MC3810 for Cisco IOS Release 12.0 T

February 11, 2000

These release notes for the Cisco MC3810 multiservice access concentrator support Cisco IOS Release 12.0 T, up to and including Release 12.0(7)T. These release notes are updated as needed to describe new features, memory requirements, hardware support, software platform deferrals, and changes to related documents.

For a list of software caveats that apply to Release 12.0(7)T, refer to the document Caveats for Cisco IOS Release 12.0 T   that accompanies these release notes. The caveats document is updated for every maintenance release and is located on Cisco Connection Online (CCO) and the Documentation CD-ROM.

Use these release notes with the cross-platform Release Notes for Cisco IOS Release 12.0  located on Cisco Connection Online (CCO) and the Documentation CD-ROM.

Contents

These release notes describe the following topics:

• Introduction

• System Requirements

• New and Changed Information

• Important Notes

• Important Notes

• Caveats

• Related Documentation

• Service and Support

• Cisco Connection Online

• Documentation CD-ROM

Introduction

As part of an enterprise backbone or as customer premises equipment (CPE) to serve provider-managed network services, the Cisco MC3810 multiservice access concentrator reduces operating costs and complexity, and increases network throughput and performance. The Cisco MC3810 is fully supported by Cisco IOS software for multiprotocol routing, bridging, and Systems Network Architecture (SNA).

To make file management easier, the Cisco MC3810 provides a complete file system for software images, message files, and reports. The standard Flash memory size is 8 MB, and a 16-MB upgrade option is available. The 16-MB version can hold two code images simultaneously for fail-safe upgrades.

Management and configuration of the Cisco MC3810 should be familiar to the Cisco IOS user and compatible with existing management systems. As such, it provides a superset of the Cisco command-line interface (CLI). The Cisco MC3810 can be managed by standard Cisco management platforms and facilities such as CiscoView and the native remote log-in facilities provided by Telnet and rlogin. Three types of configuration interfaces are provided:

• Cisco CLI

• HTTP-based configuration server

• SNMP-based Management Information Base (MIB)

The HTTP-based interface allows configuration from any Web browser such as Netscape Navigator or Microsoft Explorer. The SNMP MIB allows management of the Cisco MC3810 from SNMP managers (for example, HP OpenView).

System Requirements

This section describes the system requirements for Cisco IOS Release 12.0(7)T:

• Memory Requirements

• Hardware Supported

• Determining the Software Version

• Upgrading to a New Software Release

• Feature Set Table

• New and Changed Information

Memory Requirements

Hardware Supported

Cisco IOS Release 12.0(7)T supports the Cisco MC3810 multiservice access concentrator. The Cisco MC3810 base chassis is a semi-fixed configuration router that can be customized for a specific application at the factory or in the field by a qualified technician. The base chassis includes the following components:

• One fixed Ethernet LAN port

• A console port and an auxiliary port

• Two synchronous serial ports

• Five mounting areas for functional modules that support additional capabilities

• AC, DC, or redundant power supply option

Cisco MC3810 series concentrators are supplied in various standard hardware configurations. These are equipped with different sets of functional modules to provide specific functional capability. Many configurations are possible, but they are all variations of the basic categories described in Table 2. Supported hardware is shown in Table 3. The chassis opening for any mounting area not equipped with a functional module is closed off with a removable cover plate.

Table 2: Cisco MC3810 Series Standard Hardware Categories

Category	Service Types Supported	Required Modules	Optional Modules
Base chassis	Base chassis services1	None	Optional modules can be added to create other chassis variations.
Analog voice chassis	Base chassis services1 plus compressed analog voice connections to telephone, fax, central office, analog PBX	AVM (analog voice module) with 1 to 6 APMs (analog personality modules) VCM3 or VCM6 (voice compression modules	MFT2 to support a channelized T1 or E1 trunk MFT2 and VDM3 to support video codec dialing
Digital voice chassis	Base chassis services1 plus compressed digital voice through digital PBX	DVM VCM3 and/or VCM6 (1 or 2 VCMs)	MFT2 to support a channelized T1 or E1 trunk MFT2 and VDM to support video codec dialing
BRI voice chassis	Base chassis services1 plus compressed digital voice through PINX	BVM and MFT1 VCM3 and/or VCM6 (1 VCM required)	MFT to support a channelized T1 or E1 trunk MFT2 and VDM3 to support video codec dialing
T1/E1 trunk chassis	Base chassis services1 plus channelized T1 or E1	MFT1	DVM to support digital cross-connect voice (channel bank functionality/ drop-and-insert) through digital PBX or channel bank VDM3 to support video codec dialing VCM3 and/or VCM6 (1 or 2 VCMs) to support voice compression

1Base chassis services include administrative access, Ethernet, data transport, and video transport. 2The MFT is available with or without BRI backup. 3If a VDM is installed, an MFT is required to support ATM for the video dialing network connection.

Determining the Software Version

To determine the version of Cisco IOS software running on a Cisco MC3810, log in and enter the show version EXEC command:

MC3810>show version
Cisco Internetwork Operating System Software
IOS (tm) MC3810 Software (mc3810-js-mz), Version 12.0(7)T, RELEASE SOFTWARE

Upgrading to a New Software Release

For information about upgrading to a new software release, see the product bulletin Cisco IOS Software Release 12.0 T Upgrade Paths and Packaging Simplification (#819 1/99) on CCO at:

Service & Support: Software Center: Cisco IOS Software: Product Bulletins: Software

Feature Set Table

Cisco IOS software is packaged in feature sets consisting of software images---depending on the platform. Each feature set contains a specific set of Cisco IOS features.

Table 4: Feature Sets Supported by the Cisco MC3810

Feature Sets	Feature Set Matrix Term	Software Image
IP Standard Feature Sets	IP Plus	mc3810-is-mz
	IP/ATM Plus	mc3810-a2is-mz
	IP Plus ATM MCM H323	mc3810-a2isx-mz
Enterprise Standard Feature Sets	Enterprise Plus	mc3810-js-mz
	Enterprise ATM Plus	mc3810-a2js-mz
	Enterprise Plus ATM MCM H323	mc3810-a2jsx-mz

Table 5 lists the features and feature sets supported by the Cisco MC3810 in Cisco IOS Release 12.0(7)T and uses the following conventions:

• Yes---The feature is supported in the software image.

• No---The feature is not supported in the software image.

• In---The number in the "In" column indicates the Cisco IOS release in which the feature was first introduced. For example, (3) means a feature was introduced in Release 12.0(3)T. If a cell in this column is empty, the feature was included in the initial base release.

New and Changed Information

The following sections list the new hardware and software features supported by the Cisco MC3810 for Release 12.0 T.

New Hardware Feature in Cisco IOS Release 12.0(7)T

Release 12.0(7)T supports a new hardware feature for the Cisco MC3810.

Video over ATM Switched Virtual Circuits on the Cisco MC3810

Video over ATM switched virtual circuits (SVCs) on the Cisco MC3810 expands the capabilities of the Cisco MC3810 multiservice access concentrator to provide cost-effective, dynamic, and flexible videoconferencing system support. By using a plug-in video dialing module (VDM) to provide an RS-366 dialing interface to an H.320 video codec, the Cisco MC3810 automatically accepts dial-out requests from the video system. The codec connects to either one of the Cisco MC3810 serial ports and also to the Cisco MC3810 RS-366 dial-up port.

In addition, permanent virtual circuit (PVC) support is enhanced to permit PVC connections with automatic connection through a serial port. Each codec must place a call to the other videoconferencing system before the expiration of the video codec time-out period. By using a video dial map, each system reconciles the dialed number with a PVC that has already been configured, allowing fast connectivity.

For details, see the online feature module .

New Software Features in Cisco IOS Release 12.0(7)T

Release 12.0(7)T supports new software features for the Cisco MC3810.

Cisco H.235 Accounting and Security Enhancements for Cisco Gateways

The Cisco H.323 gateway now supports the use of CryptoH323Tokens for authentication.

The CryptoH323Token Is defined in H.225 Version 2 and supports the following features:

• Used in a "password-with-hashing" security scheme described in section 10.3.3 of the H.235 specification.

• Can be included in any RAS message

• Is used to authenticate the sender of the message.

• A separate database for user ID and password verification.

With this release, Cisco H.323 gateways support three levels of authentication:

• Endpoint---The RAS channel used for gateway-to-gatekeeper signaling is not a secure channel. To ensure secure communications, H.235 allows gateways to include an authentication key in their RAS messages. The gatekeeper uses this key to authenticate the source of the messages. At the endpoint level, all messages from the gateway are validated. The cryptoTokens are validated by using the password configured for the gateway.

• Per-Call---When the gateway receives a call over the telephony leg, the gateway prompts the user for an account number and personal identification number (PIN). These two numbers are included in certain RAS messages sent from the endpoint and authenticate the originator of the call.

• All---This option is a combination of the other two levels of authentication. With this option, the validation of cryptoTokens in ARQ messages is based on an the account number and PIN of the user making a call; the validation of cryptoTokens sent in all the other RAS messages is based on the password configured for the gateway.

You can configure the level of authentication for the gateway by using the Cisco IOS software command line interface.

CryptoTokens for registration requests (RRQ), unregistration request (URQ), disengage request (DRQ) and the terminating side of admission request (ARQ) messages contain information about the gateway that generated the token, including the gateway ID (which is the H.323 ID configured on the gateway) and the gateway password.

CryptoTokens for the originating side ARQ messages contain information about the user who is placing the call, including the user ID, and personal identification number (PIN).

Cisco H.323 Multizone Enhancements

Cisco H.323 Multizone enhancements allow a Cisco gateway to provide information to the gatekeeper with additional fields in the RAS (registration, admission, and status) messages.

Previously, the source gateway attempted to set up a call to a destination IP address as provided by the gatekeeper in an Admission Confirm (ACF) message. If the gatekeeper was unable to resolve the destination E.164 phone number to an IP address, the incoming call was terminated.

This version of the H.323 software adds support to allow a gatekeeper to provide additional destination information and modify the destinationInfo field in the ACF. The gateway includes the canMapAlias associated destination information in setting up the call to the destination gateway.

With the canMapAlias functionality, this version includes support for the gatekeeper to indicate to the gateway that the call should be sent to a new E.164 number. The gatekeeper indicates this by sending an Admission Confirm message with an IP address of 0.0.0.0 in the destCallSignalAddress field and the new destination E.164 phone number in the destinationInfo field.

The gateway receiving such an ACF falls back to routing the call based on this new E.164 address and performing a new lookup of the gateway's configured dial plan. This can result in the call being routed back to the PSTN or to an H.323 endpoint.

Frame Relay---ATM Service Interworking---FRF.8 on the Cisco MC3810

Frame Relay-to-ATM Service Interworking for data transfer is outlined in Frame Relay Forum implementation agreement FRF.8 and designed for the Cisco MC3810 multiservice access concentrator.

FRF.8 Frame Relay-ATM Service Interworking:

• Allows Frame Relay traffic to connect across high-speed ATM trunks.

• Connects a Frame Relay network to an ATM network while the networks:

  • function independently

  • allow bidirectional PVC protocol conversion functions

  • provide a standards-based solution for service providers, enterprises, and end users.

• Supports two modes of operation of the interworking function (IWF) for upper-layer user protocol encapsulation:

  • In Service Interworking translation mode, Frame Relay PVCs are mapped to ATM PVCs without the need for symmetric topologies---the paths can terminate on the ATM side. The ATM-connected Cisco MC3810 does not have to be directly linked to a Frame Relay network, and some network devices in a Frame Relay network can evolve to ATM without all the network devices doing so.

  • In Service Interworking, transparent mode does not map encapsulations but sends them unaltered. This mode is used when translation is not practical because encapsulation methods do not conform to the supported standards for Service Interworking.

For details, see the online feature module .

Frame Relay---ATM Network Interworking---FRF.5 Enhancement on the Cisco MC3810

The Frame Relay-ATM Network Interworking (FRF.5) feature that was first introduced in 11.3(1)MA has been enhanced to allow setting the mode of the Discard Eligibility and Cell Loss Priority fields as defined in the FRF.5 implementation agreement.

Network Interworking allows the transparent tunneling of Frame Relay user traffic and PVCs over ATM. This function is often used to link Frame Relay networks over an ATM backbone. The most distant nodes must be configured to interoperate with one another---in contrast to Service Interworking---because intact Frame Relay frames are sent over the ATM network. The ATM backbone is used as an alternative to a leased line and provides cost savings over leased lines. There can be a one-to-one relationship between Frame Relay and ATM PVCs, or multiple Frame Relay PVCs can be multiplexed into a single ATM PVC.

For details, see the online feature module .

Gateway Support for Alternate Gatekeeper

The Alternate Gatekeeper feature provides redundancy for a gatekeeper in a system where gatekeepers are used. This enhancement allows a gateway to use up to two alternate gatekeepers as a backup in case a primary gatekeeper failure.

A gatekeeper manages H.323 endpoints in a consistent manner, allowing the endpoints to register with the gateway and to locate another gatekeeper.

The gatekeeper provides logic variables for proxies or gateways in a call path to:

• Provide connectivity with the public switched telephone network (PSTN)

• Improve Quality of Service (QoS)

• Enforce security policies

You can configure multiple gatekeepers to communicate with one another either by integrating their addresses into the Domain Naming System (DNS) or by using Cisco IOS configuration options.

Low Latency Queueing (CSCdm84810)

The Low-Latency Queueing (LLQ) featurette brings strict priority queueing to Class-Based Weighted Fair Queueing (CBWFQ). Strict priority queueing allows delay-sensitive data, such as voice, to be dequeued and sent first (before packets in other queues are dequeued), giving delay-sensitive data preferential treatment over other traffic.

Without LLQ, CBWFQ provides weighted fair queueing based on defined classes with no strict priority queue available for real-time traffic. CBWFQ allows you to define traffic classes and then assign characteristics to that class. For example, you can designate the minimum bandwidth delivered to the class during congestion. This scheme poses problems for voice traffic, which is largely intolerant of delay---especially variation in delay. The delay introduces irregularities of transmission manifesting as jitter in the heard conversation.

The LLQ feature provides strict priority queueing for CBWFQ, reducing jitter in voice conversations. Configured by using the priority command, LLQ enables use of a single, strict priority queue within CBWFQ at the class level, allowing you to direct traffic belonging to a class to the CBWFQ strict priority queue.

Although it is possible to enqueue various types of real-time traffic to the strict priority queue, we strongly recommend that you direct only voice traffic to it. Voice traffic is well-behaved, whereas other types of real-time traffic are not. Furthermore, voice traffic requires that delay be nonvariable in order to avoid jitter. Real-time traffic, such as video, can introduce variation in delay, thereby thwarting the steadiness of delay required for successful voice traffic transmission.

When the bandwidth has been exceeded during congestion, policing is used to drop packets. Voice traffic enqueued to the priority queue is UDP-based; therefore it is not adaptive to the early packet drop characteristic of Weighted Random Early Detection (WRED).

When congestion occurs, traffic destined for the priority queue is metered to ensure that the bandwidth allocation configured for the class to which the traffic belongs is not exceeded.

Multicast Source Discovery Protocol

Multicast Source Discovery Protocol (MSDP):

• Connects multiple Protocol Independent Multicast (PIM) sparse-mode (SM) domains.

• Allows multicast sources for a group to be known to all rendezvous points (RPs) in different domains.

Each PIM-SM domain uses its own RPs and does not depend on RPs in other domains. An RP runs MSDP over TCP to discover multicast sources in other domains.

An RP in a PIM-SM domain has an MSDP peering relationship with MSDP-enabled routers in another domain. The peering relationship occurs over a TCP connection where primarily a list of sources sending to multicast groups is exchanged. The TCP connections between RPs are achieved by the underlying routing system. The receiving RP uses the source lists to establish a source path.

The purpose of this topology is to have domains discover multicast sources in other domains. If the multicast sources are of interest to a domain that has receivers, multicast data is delivered over the normal source-tree building mechanism in PIM-SM.

• Allows you to announce sources that are sending to a group. These announcements must originate at the domain's RP. You should run MSDP in your domain's RPs that act as sources, and that send to global groups for announcement to the Internet.

• Depends heavily on (M)BGP for interdomain operation.

Voice over ATM Switched Virtual Circuits on the Cisco MC3810

Voice over Asynchronous Transfer Mode (VoATM) switched virtual circuits (SVCs) on the Cisco MC3810:

• Allows the Cisco MC3810 to transfer voice data dynamically and as needed---without tying up the resources required for static, manually provisioned permanent virtual circuits (PVCs). An SVC connection is initiated for each call, and each request includes the bandwidth and quality-of-service (QoS) information required for the connection. SVCs are ideal for networks that are highly interconnected, where scalability is essential, and in situations where traffic is sporadic. In addition, service providers often offer more advantageous, usage-based pricing options for SVCs than they do for PVCs.

• Includes all the voice features that the Cisco MC3810 supports for PVCs and for Frame Relay transport.

• Is based on dial peers.

• Uses ATM Adaptation Layer 5 (AAL5).

For details, see the online feature module .

X.25 Closed User Groups

The X.25 specification for Closed User Groups (CUG):

• Provides an application access security service that restricts users who do not have subscribed access to the host location.

• Provides a privacy technique that you can use to create private subnets or virtual networks out of a public data network.

X.25 Switch Local Acknowledgment

Cisco offers an X.25 switch function that creates virtual connections (VC) by connecting channels between X.25 class services.

The following X.25 class services are supported:

• X.25, Connection-Mode Network Service (CMNS)

• X.25 over TCP (XOT)

• Switched Virtual Circuits (SVCs) and Permanent Virtual Circuits (PVCs) are both supported and can be switched to each other (converted).

The current Cisco implementation provides end-to-end acknowledgment, which means that flow control or window and packet size acknowledgment is between the originating and terminating data terminal equipment (DTE).

Acknowledgment is not local to the DTE and data communications equipment (DTE), and the overall effect is low throughput.

New Software Features in Cisco IOS Release 12.0(5)T

Release 12.0(5)T supports new software features for the Cisco MC3810.

AAA Server Group

The AAA server-group feature introduces a way to group the existing server hosts. The server-group feature allows the user to select a subset of the configured server hosts and use them for a particular service.

A server-group is a list of server hosts of a particular type. Currently supported server host types are Remote Authentication Dial In User Service (RADIUS) server hosts and Terminal Access Controller Access Control System+ (TACACS+) server hosts. Server-group is used in conjunction with a global server host list. The server-group lists the IP addresses of the selected server hosts.

ATM LANE Fast Simple Server Replication Protocol

To improve the ATM LAN Emulation (LANE) Simple Server Redundancy Protocol (SSRP), Cisco has introduced the ATM LANE Fast Simple Server Redundancy Protocol (FSSRP). FSSRP differs from LANE SSRP in that all configured LANE servers of an emulated LAN (ELAN) are always active. FSSRP-enabled LANE clients have VCs linked to up to four LANE server broadcast-and-unknown servers (BUSs). If a LANE server goes down, the LANE client quickly switches over to a new LANE server and BUS resulting in no data or LE-ARP table entry losses and no extraneous signaling.

CNS Client for Cisco IOS Software

Cisco Networking Services (CNS) Client feature for Cisco IOS software enables authenticated directory access. CNS Client for Cisco IOS software includes the following components:

• Lightweight Directing Access Protocol (LDAP) V.3 client

• Support to use Kerberos V.5 as security protocol for LDAP V.3 client

• CNS Event Services Client

• CNS Locator Services Client

• CNS IP Security (IPSec) virtual private network (VPN) Provisioning Agent

• CNS Configuration Change Notification Agent

• CNS Provisioning Agent

LDAP V.3 client functionality enables Cisco IOS software-based applications to securely authenticate to a CNS for Active Directory (CNS/AD) server using Kerberos V.5 as security protocol to retrieve or store information such as policy and configuration data. Cisco IOS software-based applications publish or subscribe to events using CNS event services client, enabling external applications using the application programming interface (API) features of CNS to receive events or publish events to the Cisco IOS device. This Cisco IOS software-based device will use CNS locator services client to locate the nearest directory server using Domain Name System. The administrator need not configure the device to locate the nearest directory server.

All the above-mentioned functionality is intended for use by internal Cisco IOS application developers. CNS IPSec VPN provisioning agent enables the router to retrieve IPSec policies stored in the CNS/AD server and configure itself, automating the provisioning of customer premises equipment devices for IPSec VPN. CNS provisioning agent enables Cisco IOS device to be provisioned using CNS event services.

DLSw+ Ethernet Redundancy

The DLSw+ Ethernet Redundancy feature provides redundancy in an Ethernet environment. It enables DLSw+ to support parallel paths between two points in an Ethernet environment, ensuring resiliency in the case of a router failure and providing load balancing for traffic load.

DLSw+ could provide redundancy prior to this feature in a Token Ring environment or via backup peers. When an end station on an Ethernet LAN had multiple active paths into a DLSw+ network, problems occurred.

Redundancy is not possible in an Ethernet environment because, unlike Token Ring, it does not have a RIF field in its packet. The RIF notifies a router of the path a packet has traveled by tracking each ring number and bridge it travels along a path. If a bridge notices that the next ring matches a ring already in the RIF, then the frame is not copied on to that ring. The RIF prevents unreliable local reachability information, circuit contention, and undetected looping explorers.

DLSw+ Fast HPR

The DLSw+ Fast HPR feature provides mechanisms by which DLSw+ can more efficiently switch and prioritize APPN ANR traffic. APPN nodes use LLC1 UI frames to encapsulate HPR over LAN media such as Token Ring or Ethernet. In Cisco IOS Release11.3, DLSw+ was enhanced to allow circuits to start when the peer received a non-broadcast UI frame. Currently, DLSw+ creates lite circuits to carry APPN HPR traffic. Although this method is sufficient to transport HPR data flows, it has some performance weaknesses.

HPR has its own retransmission mechanism and does not need the reliable transport provided by DLSw+ TCP peer connections.When DLSw+ with TCP/IP encapsulation transports the HPR data, the TCP/IP layer of the DLSw+ packet handles the retransmission and sequencing necessary for traffic traveling across a WAN. HPR, however, has no knowledge about the underlying secured transport layer. Performance issues arise because APPN HPR has its own retransmission and sequencing capabilities that compete against the capabilities of DLSw+. The result is unreliable transport of HPR frames over DLSw+.

DLSw+ with FST encapsulation is another method to transport HPR traffic. Because FST does not terminate the local media DLC, data packet delivery is not guaranteed. DLSw+ with FST encapsulation does, however, drop "out-of-order" packets to prevent packet retransmissions. While this reliability mechanism is necessary, HPR has its own resequencing capabilities. The DLSw+ FST encapsulation of "out-of-order" packets competes against the HPR resequencing capabilities. The result is that DLSw+ drops the frames that are received out of sequence for an FST peer, causing unnecessary retransmission of HPR traffic.

DNS-Based X.25 Routing

Managing a large TCP/IP network requires accurate and up-to-date maintenance of IP addresses and X.121 address mapping information on each router database in the network. Currently, this data is managed manually. Because these addresses are constantly being added and removed in the network, the routing table of every router frequently needs to be updated, which is a time-consuming and error-prone task.

X.25 has long operated over an IP network, specifically using Transmission Control Protocol (TCP) as a reliable transport mechanism. This method is known as X.25 over TCP (XOT). However, large networks and financial legacy environments experienced problems with the amount of route configuration that needed to be performed manually because each router switching calls over TCP needed every destination configured. Every destination from the host router needed a static IP route statement, and for larger environments, these destinations could be as much as several thousand per router. Until now, the only way to map X.121 addresses and IP addresses was on a one-to-one basis using the x25 route x121address xot ipaddress command.

The solution to this problem was to centralize route configuration that routers could then access for their connectivity needs. This centralization is the function of the DNS-Based X.25 Routing feature, because the DNS server is a database of all domains and addresses on a network.

Frame Relay End-to-End Keepalive

The Frame Relay End-to-End Keepalive feature enables the router to keep track of permanent virtual circuit (PVC) status, independent of the switches in the Frame Relay network. The routers at both ends of a PVC in a Frame Relay network engage in a keepalive session where one router issues keepalive messages and the router at the other end of the PVC connection responds. The time interval for the keepalive is configurable and is enabled on a per-PVC basis. As long as the keepalive-issuing router receives response messages, the PVC status is up. When response messages are not received (because of line failure, a faulty switch in the Frame Relay network, or a router failure), the PVC is down. This mechanism enables bidirectional communication of PVC status to both routers at the ends of a PVC connection.

H.323 Version 2 Support (Gatekeeper and Proxy Features)

The H.323 Version 2 Support feature upgrades Cisco IOS software to comply with the mandatory requirements in the version 2 specification. This upgrade enhances the existing Voice over IP (VoIP) Gateway, the Multimedia Conference Manager (gatekeeper and proxy), and the DTMF digital relay using H.245.

DTMF is the tone generated on a touch-tone telephone when you press keypad digits. The tones are compressed into a single stream at one end of a call and decompressed at the other end by using H.245 messages. However, this compression and decompression can lead to distortion, depending upon the codec used. Thus, the DTMF-relay is used to configure one of three methods to transport DTMF tones generated after the call is established out-of-band. The three methods are:

• The standard H.323 out-of-band method uses H.245 to send digits as audible DTMF tones along with voice (the "h245-signal" option).

• The H.245 "alphanumeric" method (the "h245-alphanumeric" option) uses User Input Indication as part of a control channel, and is another standard H.245 transmission method.

• The "cisco-rtp" method sends the voice stream but with an identifier indicating that the DTMF tones are added.

H.323 Version 2 defines a lightweight registration procedure that requires full registration for initial registration, but uses an abbreviated renewal procedure to update the gatekeeper and minimize overhead. Lightweight registration requires each endpoint to specify a Time To Live (TTL) value in its Registration Request (RRQ) message.

The H.323 Version 2 gateway supports the registration of fully qualified E.164 numbers with the gatekeeper for telephones connected directly to the gateway. Tunneling through H.225 User-to-User Information Element (UUIE) facilitates transparent handling of supplementary services between two endpoints through a VoIP network. This tunneling eliminates the need to interpret various supplementary signaling messages in the VoIP gateways.

H.323 Version 2 gatekeeper selects a destination gateway by choosing from among all gateways registered in a zone by allowing you to assign selection priorities to these gateways based on the dialed prefix. Gateway resource reporting allows the gateway to notify the gatekeeper when H.323 resources are getting low. The gatekeeper uses this information to determine which gateway it will use to complete a call. The gatekeeper maintains a separate gateway list, ordered by priority, for each of its zone-prefixes.

IP RTP Priority

The new IP RTP Priority feature provides a strict priority queueing scheme for delay-sensitive data such as voice. Voice traffic can be identified by its Real-Time Transport Protocol (RTP) port numbers and classified into a priority queue configured by the ip rtp priority command. The result is that voice is serviced as strict priority in preference to other nonvoice traffic.

This feature extends and improves on the functionality offered by the IP RTP Reserve feature by allowing you to specify a range of UDP/RTP ports whose voice traffic is guaranteed strict priority service over any other queues or classes using the same output interface. Strict priority means that if packets exist in the priority queue, they are dequeued and sent first---that is, before packets in other queues are dequeued. Cisco recommends that you use the ip rtp priority command instead of the ip rtp reserve command for voice configurations.

IPX Display and Debug Enhancements

Several IPX display and debug enhancements have been added to the Cisco IOS 12.0(5)T software to improve its flexibility and ease of maintenance:

• Watchdog spoofing prevents watchdog keepalive packets from causing unnecessary calls on dial-on-demand routing (DDR) interfaces. Spoofing makes a server view a client as always connected, even when it isn't, thus reducing the number of available licenses. Users can set the duration of IPX watchdog spoofing and periodically disable it so that NetWare servers can clean up inactive connections.

• A Get General Service (GGS) response filter allows users to filter services advertised in general SAP response packets.

• To aid network debugging, you can now clear IPX and NLSP traffic counters and display a snapshot of them.

ISDN Cause Code Override

the ISDN Cause Code Override function overrides cause codes that are sent to ISDN applications. Currently, the Cisco IOS software contains ISDN cause codes that handle specific functions such as modem availability and resource pooling. The ISDN Cause Code Override feature is more general in its functionality and will override the specific ISDN cause codes.

When the command associated with this feature is implemented, the configured cause codes are sent to the switch; otherwise, default cause codes of the application are sent.

To override an ISDN cause code, enter the following command:

isdn disconnect-cause {cause-code-number | busy | not-available}

where cause-code-number is a cause code number from 1 to 127.

Multimedia Conference Manager Enhancements

Multimedia Conference Manager provides gatekeeper and proxy capabilities required for service provisioning and management of H.323-compliant networks. It conforms to the H.323 standard (version 1) for transmitting audio, video, and data conferencing data on an IP-based internetwork. The Multimedia Conference Manager Enhancements feature provides additional functionality for the gatekeeper endpoint. It provides:

• A way to force a disconnect on a specific call or all calls active on a particular gatekeeper.

• Enhanced output for the show gatekeepers calls command.

PAD French Enhancement

Extended dialog mode for packet assembler/disassembler (PAD) service signals is now available in the French language as well as English with the PAD French Enhancement. The French language service signals will be maintained in a table. When configured for French language via PAD parameter 6, the PAD service signals will map to this table, giving the appropriate French equivalent output. The internal table maintenance will be based upon the contents of the Annex-C/X.28 standard. Section 3.5/X.28 outlines Parameter 6 and how it relates to extended mode dialog in multiple languages.

PGM Router Assist

The PGM Router Assist feature allows Cisco routers to support the optimal operation of Pragmatic General Multicast (PGM). The PGM Reliable Transport Protocol itself is implemented on the hosts of the customer.

Service Assurance Agent

The Service Assurance (SA) Agent is both an enhancement to and a new name for the Response Time Reporter (RTR) feature that was introduced in Cisco IOS Release 11.2. The feature allows you to monitor network performance by measuring key Service Level Agreement metrics such as response time, network resources, availability, jitter, connect time, packet loss, and application performance.

With Cisco IOS Release 12.0(5)T, the SA Agent provides new capabilities that enable you to:

• Monitor the Domain Name Server, DHCP Server, and DLSw peer stack and tunnel performance. Thresholds can be used to trigger additional collection of time delay statistics.

• Monitor network one-way delay variance (jitter) and packet loss.

• Monitor web server response time.

Subnetwork Bandwidth Manager

Resource Reservation Protocol (RSVP) is a signaling mechanism that supports request of specific levels of service such as reserved bandwidth from the network. RSVP and its service class definitions are largely independent of the underlying network technologies. This independence requires that a user define the mapping of RSVP onto subnetwork technologies.

The Subnetwork Bandwidth Manager (SBM) feature answers this requirement for RSVP in relation to IEEE 802-based networks. SBM specifies a signaling method and protocol for LAN-based admission control for RSVP flows. SBM allows RSVP-enabled routers and Layer 2 and Layer 3 devices to support reservation of LAN resources for RSVP-enabled data flows. The SBM signaling method is similar to that of RSVP itself.

SBM protocol entities have the following features:

• Reside in Layer 2 or Layer 3 devices.

• Can manage resources on a segment. A segment is a Layer 2 physical segment shared by one or more senders, such as a shared Ethernet or Token Ring wire.

• Can become candidates in a dynamic election process that designates one SBM as the segment manager. The elected candidate is called the Designated Subnetwork Bandwidth Manager (DSBM). The elected DSBM is responsible for exercising admission control over requests for resource reservations on a managed segment.

Tunnel Endpoint Discovery

IP Security Protocol (IPSec) requires a peer router to be statically configured before initiating an Internet Key Exchange (IKE). An IKE is necessary to encrypt and decrypt packets. The Cisco router crypto maps require the capability to dynamically determine the IPSec peer. The Tunnel Endpoint Discovery protocol automatically discovers remote tunnel endpoints and enables secure IPSec communications.

Dynamic Tunneling Endpoint Discovery allows IPSec to scale to larger networks by reducing the multiple encryptions, reducing the setup time, and allowing for simple configurations on participating peer routers. Each node has a simple configuration that defines the local network that the router is protecting and the IPSec transforms required, if any.

Voice over Frame Relay Queuing Enhancement

When there are multiple sets of flows being handled by weighted fair queueing (WFQ), the algorithm provides the low weight/reserved queued voice packets with higher priority but only until some of the other data packets have waited enough time and therefore it is now their turn to be dequeued. Even if interleaving is active, the WFQ algorithm will not dequeue a voice packet until these data packets are transmitted. This causes voice quality problems.

The solution consists of adding a special queue at the PVC level where all VoFR packets will be queued. This special queue runs in parallel to the WFQ and is serviced before any of the WFQs.

As of this release, reserved queues are no longer required to support VoFR.

X.25 Remote Failure Detection

Static routes are used over a packet-switched data network in order to reduce volume-based costs of the network. Until now, if two routers were connected by multiple X.25 links (a primary and a secondary), a router could not detect failure of the primary link. If a failure occurred, the data was not transferred to the second link because X.25 was unable to determine whether remote links were up or down. Therefore X.25 could not use an alternate connection to a destination.

The X.25 Remote Failure Detection feature is important for X.25 users because now, after a primary link failure, the router can establish a secondary link and continue sending data. This feature is a way for the router to detect a call failure and to use a secondary route to send subsequent packets to the remote destination, at the same time as making periodic attempts to reconnect to its primary link.

New Hardware Feature in Cisco IOS Release 12.0(4)T

Release 12.0(4)T supports a new hardware feature for the Cisco MC3810.

ISDN BRI Voice on the Cisco MC3810

With the optional BRI voice module (BVM) installed, the Cisco MC3810 multiservice access concentrator provides four ISDN Basic Rate Interface (BRI) ports for connection to ISDN PBXs (PINXs). The BVM has four ISDN BRI ports for voice traffic. Each BRI port supports two voice channels (ISDN B channels) and one signaling channel (ISDN D channel). The BRI voice ports have the following features:

• ITU I.430 BRI

• Full-duplex S/T interfaces supporting 2 bearer channels and 1 signaling channel (2B + D)

• Total of 8 simultaneous voice channels

• LT-S mode: Line termination of subscriber lines from PINX, with port configured as network termination (NT)

• LT-T mode: Line termination of an ISDN trunk from an ISDN exchange switch, with port configured as terminal equipment (TE)

• Each port individually configurable as NT or TE

• Configurable clock recovery and distribution

New Software Features in Cisco IOS Release 12.0(4)T

Release 12.0(4)T supports new software features for the Cisco MC3810.

QSIG Digit Forwarding on the Cisco MC3810

The QSIG Digit Forwarding feature extends support for dial-peer digit forwarding to ISDN PRI QSIG signaling calls on the Cisco MC3810. When ISDN PRI QSIG signaling was first introduced on the Cisco MC3810 in Cisco IOS Release 12.0(2)T, digit forwarding on POTS dial peers was not supported with ISDN PRI QSIG. In this release, digit forwarding is now supported with ISDN PRI QSIG.

Voice over Frame Relay Using FRF.11 and FRF.12

The Voice over Frame Relay (VoFR) capabilities that were introduced on the Cisco MC3810 multiservice access concentrator beginning with IOS Release 11.3 are now extended to the Cisco 2600, 3600, and 7200 series router platforms.

The following additional functionality is supported in Release 12.0(4)T:

• FRF.11-compliant Voice over Frame Relay trunking

• FRF.12-compliant end-to-end fragmentation

• Dynamic call switching and termination

• Permanent trunks over dynamic switched calls

When VoFR is implemented on a Cisco router, the router is able to carry voice traffic, such as telephone calls and faxes over a Frame Relay network.

This feature also adds support for full FRF.11 and FRF.12 compliance to the Cisco MC3810 and is backward-compatible with earlier versions of the Cisco MC3810, which used a fragmentation format based on an early draft version of FRF.12.

New Software Features in Cisco IOS Release 12.0(3)T

New software features are available for the Cisco MC3810 in Cisco IOS Release 12.0(3)T.

Annex G (X.25 over Frame Relay)

Annex G (X.25 over Frame Relay) facilitates the migration from an X.25 backbone to a Frame Relay backbone by permitting encapsulation of CCITT X.25/X.75 traffic within a Frame Relay connection. Annex G has been developed to accommodate the many Cisco customers in Europe, where X.25 still is a popular protocol. With Annex G, the process of transporting X.25 over Frame Relay has been simplified, by allowing direct X.25 encapsulation over a Frame Relay network.

This simple process is largely achieved using X.25 profiles (similar to dialer profiles), which were created to streamline the configuration of X.25 on a per-DLCI basis. X.25 profiles can contain any existing X.25 command and, once created and named, can be simultaneously associated with more than one Annex G DLCI connection, just using the profile name.

CDP Additions for Cisco IOS

The Cisco Discovery Protocol (CDP) is a media-independent device discovery protocol that runs on all Cisco-manufactured equipment, including routers, bridges, access servers, and switches. Each device sends periodic messages to a multicast address. Each device listens to the periodic messages sent by others in order to learn about neighboring devices and determine when their interfaces to the media go up or down. With CDP, network management applications can learn the device type and the SNMP agent address of neighboring devices. This process enables applications to send SNMP queries to neighboring devices.

CDP runs on all media that support Subnetwork Access Protocol (SNAP), including local-area network (LAN), Frame Relay, and Asynchronous Transfer Mode (ATM) media. CDP runs over the data link layer only. Therefore, two systems that support different network-layer protocols can learn about each other.

Each device configured for CDP sends periodic messages to a multicast address. Each device advertises at least one address at which it can receive SNMP messages. The advertisements also contain time-to-live, or holdtime, information, which indicates the time a receiving device should hold CDP information before discarding it.

Additions for Cisco Discovery Protocol (CDP) include a new cdp advertise-v2 command and new output from show cdp commands

The benefits include, transparent support of X.25 encapsulation over the Frame Relay network; direct X.25 configurations on a per DLCI basis; multiple Annex G DLCIs can use the same X.25 profile; multiple logical X.25 SVCs per Annex G link, and the fact that Cisco routers already contain the functionality necessary to perform the framing and frame removal required by Annex G.

DLSw+ Enhanced Load Balancing

In a network with multiple capable paths, the DLSw+ Load Balancing Enhancements feature improves traffic load balancing between peers by distributing new circuits based on existing loads and the desired ratio.

For each capable peer (peers that have the lowest or equal cost specified), the DLSw+ Load Balancing feature calculates the difference between the desired and the actual ratio of circuits being used on a peer. It detects the path that is underloaded in comparison to the other capable peers and assigns new circuits to that path until the desired ratio is achieved.

DLSw+ Peer Clusters

The DLSw+ Peer Clusters feature reduces the explorer packet replication that typically occurs in a large DLSw+ Peer Group design, where there are multiple routers connected to the same LAN.

The DLSw+ Peer Clusters feature associates DLSw+ peers (that are connected to the same LAN) into logical groups. When the multiple peers are defined in the same peer group cluster, the DLSw+ Border Peer recognizes that it does not have to forward explorers to more than one member within the same peer group cluster.

DLSw+ RSVP Bandwidth Reservation

The DLSw+ RSVP Bandwidth Reservation feature allows DLSw+ to reserve network bandwidth for the DLSw+ TCP connection between DLSw+ peers.

Although it has been possible in the past to reserve bandwidth for a particular existing DLSw+ peer connection through the RSVP CLI support in Cisco IOS software, the CLI required prior knowledge of the TCP ports for which the reservation was being made. Because DLSw+ uses one well-known port and one randomly assigned port, the reservation could not be made until after the peer connection was active.

The DLSw+ RSVP feature permits new DLSw+ peer connections to automatically request bandwidth reservations upon connection, thereby removing the need for user intervention after the peer is connected. This feature assures the reservation will survive a network or device failure and that the DLSw+ traffic carried over a TCP connection is not affected by congestion.

Fancy Queuing on Frame Relay for Cisco HDLC

In previous releases, when the voice-encap option was configured on Frame Relay or Cisco HDLC, all fancy queuing (such as weighted fair queuing, custom queuing, and priority queuing) on the interface was disabled, and queuing was handled on a first-come first-served (FCFS) basis. In this release, new enhancements have been made to support fancy queuing on Frame Relay and Cisco HDLC.

For Frame Relay, a new interface command, frag-pre-queuing, has been added that allows you to set the queuing to be performed after the data segmentation. The command is available for Frame Relay interfaces only. The syntax for this new command is:

By default, this command is enabled, which allows only FCFS queuing at the interface level. If you enter no frag-pre-queuing, you can configure weighted fair queuing, custom queuing, or priority queuing at the interface level. Note that if you enter no frag-pre-queuing, you still must explicitly configure the fancy queuing type on the interface.

For HDLC encapsulation, the queuing now takes place after segmentation when the voice-encap option is entered. Weighted fair queuing, custom queuing, and priority queuing are now supported on an interface configured for Cisco HDLC.

Local Voice Busy Out

The local voice busyout feature for the Cisco MC3810 is designed to busy out the trunks assigned to a PVC whose pipe is broken so that the PBX will not attempt to seize the circuit. This allows the PBX to route or reroute a given call based on the actual availability of trunks.

This feature is different from the concept of busy-back. Busy-back refers to the signal sent from within the network to the calling party that indicates a busy (or congested) state anywhere along the route, up to and including the condition of the called part. When the number of available DSPs is less than the number of incoming trunks from a PBX, a call from the PBX will connect to dead air. The capability to provide a busy-back signal because no DSPs are available is not supported on the Cisco MC3810 as part of this feature.

Multimedia Conference Manager

Use the Multimedia Conference Manager to enable your current internetwork to route bit-intensive data such as audio telephony, video and audio telephony, and data conferencing using existing telephone and ISDN links, without degrading the network's current level of service. The Multimedia Conference Manager feature provides H.323 application options previously unavailable. Using Multimedia Conference Manager, you can implement H.323-compliant applications on existing networks in an incremental fashion without upgrades.

This feature also provides networking capabilities, including:

• A means to implement Quality of Service (QoS), which is required for the successful deployment of H.323 applications.

• Interzone routing in the E.164 address space. When using H.323-ID format addresses, interzone routing is done through domain names.

The Multimedia Conference Manager feature provides network administration mechanisms to support H.323 applications without impacting the mission critical applications running on today's networks. Multimedia Conference Manager is implemented on Cisco IOS software. Multimedia Conference Manager provides the network administrator with these abilities:

• Identify H.323 traffic and apply appropriate policies

• Limit H.323 traffic on the local-area network (LAN) and wide-area network (WAN)

• Provide user accounting for records based on service utilization

• Insert QoS for the H.323 traffic generated by applications such as Voice over IP (VoIP), data conferencing, and video conferencing

• Implement security for H.323 communications

Multimedia Conference Manager has two principal functions: gatekeeper and proxy. This document describes the value of the Multimedia Conference Manager gatekeeper and proxy functions for end-to-end implementation of H.323-compliant multimedia applications. These functions are unique to Multimedia Conference Manager. Similar robust features are currently not available in other vendor solutions.

Gatekeeper subsystems provide:

• User authorization where authorization, authentication, and accounting (AAA) account holders are permitted to register and use the services of Multimedia Conference Manager

• Accounting using AAA call detail records

• Zone bandwidth management to limit the number of active sessions

• H.323 call routing

• Address resolution

Starting with Cisco IOS Releases 11.3(6)Q and 11.3(7)NA and later, you can configure Cisco gatekeepers to use the Cisco Hot Standby Routing Protocol (HSRP), so that when one gatekeeper fails, the standby gatekeeper assumes its role.

Proxy subsystems provide:

• H.323 traffic consolidation

• Tight bandwidth controls

• QoS mechanisms such as IP Precedence and RSVP

• Secure communication over extranets

Priority Queuing Support Enhancement for Cisco MC3810-IGX Interworking

When the Cisco MC3810-IGX Interworking feature for the Cisco MC3810 was introduced in Cisco IOS Release 12.0(2)T, the FTC trunk could only support first-come-first-served queuing. In Cisco IOS Release 12.0(3)T, the Cisco MC3810-IGX Interworking feature has been enhanced to support priority queuing, custom queuing, and generic traffic shaping. Standard IOS commands for priority queuing, custom queuing, and generic traffic shaping are supported.

Process MIB

The addition of the CISCO-PROCESS-MIB and changes to the CISCO-MEMORY-POOL-MIB allow the retrieval of additional CPU and memory statistics and their reporting by SNMP. The CISCO-PROCESS-MIB provides CPU 5-second, 1-minute, and 5-minute statistics. In addition, this MIB provides CPU utilization and memory allocation/deallocation statistics for each process on each CPU listed in the CISCO-PROCESS-MIB.

The CISCO-PROCESS-MIB is enabled when the first SNMP command is configured. The background statistics collection for VIP cards and the master CPU occurs even if the SNMP subsystem is not initialized.

Response Time Reporter Enhancements

The Response Time Reporter (RTR) feature allows you to monitor network performance, network resources, and applications by measuring response times and availability. RTR statistics can be used to perform troubleshooting, problem notifications and pre-problem analysis. The RTR enhancements extend IP support, such as Type of Service, and allow you to measure various types of IP traffic, such as UDP, TCP, and HTTP.

SNMP v3

Simple Network Management Protocol version 3 (SNMPv3) addresses issues related to the large scale deployment of SNMP for configuration, accounting, and fault management. Currently, SNMP is predominantly used for monitoring and performance management. The primary goal of SNMPv3 is to define a secure version of the SNMP protocol. SNMPv3 also facilitates remote configuration of the SNMP entities which make remote administration of SNMP entities a much simpler task. SNMPv3 builds on top of SNMPv1 and SNMPv2 to provide a secure environment for the management of systems and networks.

SNMPv3 provides an identification strategy for SNMP devices to facilitate communication only between known SNMP entities. Each SNMP device has an identifier called the SNMP EngineID which is a copy of SNMP. Each SNMP message contains an SNMP EngineID. SNMP communication is possible only if an SNMP entity knows the identity of its peer SNMP device.

SNMPv3 also contains a security model or security strategy that exists between an SNMP user and the SNMP group to which the user belongs. A security model may define the security policy within an administrative domain or an intranet. The SNMPv3 protocol consists of the specification for the User-Based Security Model (USM).

Definition of security goals where the goals of message authentication service include the following protection strategies:

• Modification of Information or protection against some unauthorized SNMP entity altering in-transit SNMP messages generated on behalf of an authorized principal

• Masquerade or protection against attempting management operations not authorized for some principal by assuming the identity of another principal that has the appropriate authorizations

• Message Stream Modification or protection against messages getting maliciously re-ordered, delayed, or replayed in order to effect unauthorized management operations

• Disclosure or protection against eavesdropping on the exchanges between SNMP engines. Three different types of communication mechanisms are available for this protection strategy. They are:

  • Communication without authentication and privacy (NoAuthNoPriv)

  • Communication with authentication and without privacy (AuthNoPriv)

  • Communication with authentication and privacy (AuthPriv)

New Hardware Feature in Cisco IOS Release 12.0(2)T

The following section describes a new hardware feature that the Cisco MC3810 supports in Cisco IOS Release 12.0(2)T.

Multiflex Trunk Module with Integrated BRI Interface

This module provides all the same functionality as the existing MFT module but supplies an additional interface for BRI data backup. The BRI module provides an S/T interface only, which can be used for European deployment. An inexpensive NT1 can be used to provide connectivity to ISDN services in the United States.

New Software Features in Cisco IOS Release 12.0(2)T

The following sections describe new software features that the Cisco MC3810 supports in Cisco IOS Release 12.0(2)T.

Call Detail Records

The Call Detail Records (CDR) feature provides the ability to track records for calls being processed by the Cisco MC3810. CDR data is collected for all POTS call attempts, and the data is collected for each call leg and also by each Cisco MC3810 involved in the call session.

The call legs for which CDR data is collected are:

• POTS lines if the call both originates and terminates on the same Cisco MC3810

• POTS line and the trunk for calls that either originate or terminate on another Cisco MC3810

• Two trunks in the case of a tandem call

CDR data is stored in an internal buffer on the Cisco MC3810 at call termination time, and becomes available to be polled periodically by the Cisco network management system (NMS) applications. The CDR/call history entries cannot be retrieved after a power loss or a software reload on the Cisco MC3810, so the Cisco NMS is considered the final destination for storing and tailoring the CDR call history table into report form.

Cisco MC3810 - IGX 8400 Interworking

For locations terminating a large number of voice channels, the Cisco IGX provides scalability for a network design in which connections can be made between remote Cisco MC3810 concentrators.

Cisco MC3810 - IGX 8400 Interworking allows the Cisco IGX 8400 to be used as a larger, central site access device that can do the following:

• Support greater numbers of voice channels

• Connect PBXs and larger routers

• Provide Quality of Service

• Provide an integrated network topology view via StrataView+

• Extend the segmented connection type to the Cisco MC3810. There are two connection segment types:

  • A connection within the IGX cloud.

  • A connection segment on the Cisco MC3810 from the concentrator's network port to the concentrator's user port. This segmented connection applies to both data and voice.

Common Channel Signaling Features

Cisco IOS Release 12.0(2)T introduces support for three new Common Channel Signaling (CCS) features that are described in the following sections.

QSIG PRI Voice Switching

CCS Frame Forwarding

CCS Transparent Signaling

Default Routes

The default routes feature can be used to reduce the number of dial peers to be configured. It is designed for situations where, for example, the ports on a Cisco MC3810 have extension numbers, but all calls not terminating on those extensions should be sent to a central Cisco MC3810, usually for forwarding to a PBX. Instead of defining all the number blocks that can be called, the default route is a dial peer that automatically matches any call not terminated by other dial peers on the Cisco MC3810.

Facility Data Link (FDL) Capability on the Multiflex Trunk Module

This release adds support for Facility Data Link (FDL) on the MFT module. You can specify the FDL format to use as either the ANSI T1.403 standard, or the AT&T TR54016 standard, or both.

G.726 (ADPCM)

This newly supported vocoder provides higher reliability for digit transport in networks with greater hop counts and can be used to support lower-speed modems (up to 9.6 kbps).

Multi-Length Dial Patterns

Dial strings of multiple lengths can now be supported in the same network and on the same Cisco MC3810.

OPX Ring-Through

This feature allows a port on the Cisco MC3810 to act like an "Off-Premise Extension" to the PBX. When the PBX attempts to make a connection to the remote voice port on a Cisco MC3810, OPX Ring-through allows the PBX to reroute the call if there is no answer.

Preference-Based Hunt Group

The Multichassis hunt group has been enhanced to allow the preference command to be used to select remote dial peers before local dial peers using the priority values. This greatly extends the capability to support on-net to off-net rerouting of calls and alternate call center applications.

Existing IOS Features Supported on the Cisco MC3810 in Cisco IOS Release 12.0(2)T

The Cisco MC3810 supports the following existing IOS features in Cisco IOS Release 12.0(2)T:

• Bisync

• Polled Async

• PPP over ATM

For more information on Bisync and Polled Async, refer to the Cisco IOS Release 12.0 Bridging and IBM Networking Configuration Guide.  For more information on PPP Over ATM, refer to the Cisco IOS Release 12.0 Wide-Area Networking Configuration Guide . 

Important Notes

This section contains important information about the use of your Cisco IOS Release 12.0 T software.

The last maintenance release of the 12.0T release train is 12.0(7)T. The migration path for customers needing bug fixes for the 12.0 T features is 12.1 Mainline. 12.1 Mainline has the complete feature content of 12.0T and this release will eventually reach General Deployment (GD).

The last maintenance release was renamed from 12.0(6)T to 12.0(7)T to reflect that 12.0(7)T has all the bug fixes of 12.0(7) mainline. 12.0 T is a superset of 12.0 mainline, hence any defect fixed in 12.0 mainline is also fixed in 12.0 T. The set of features for 12.0(6)T is the same as that of 12.0(7)T. There was no change in the feature content of the release. The release was renamed so that the releases would be consistent with Cisco's release process.

Cisco IOS Syslog Failure

Certain versions of Cisco IOS software can fail or hang when they receive invalid User Datagram Protocol (UDP) packets sent to their syslog ports (port 514). At least one commonly-used Internet scanning tool generates packets that can cause such problems. This fact has been published on public Internet mailing lists, which are widely read both by security professionals and by security crackers. This information should be considered in the public domain.

Attackers can cause Cisco IOS devices to repeatedly fail and reload, resulting in a completely disabled Cisco IOS device that will need to be reconfigured by its administrator. Some Cisco IOS devices have been observed to hang instead of failing when attacked. These devices do not recover until they are manually restarted by reset or power cycling. An administrator must personally visit an attacked, hung device to restart it, even if the attacker is no longer actively sending any traffic. Some devices have failed without providing stack traces; some devices might indicate that they were "restarted by power-on," even when that is not the case.

Assume that any potential attacker is likely to know about this problem and the ways to exploit it. An attacker can use tools available to the public on the Internet. An attacker does not need to write any software to exploit the problem. Minimal skills and no special equipment are required.

Despite Cisco specifically inviting such reports, Cisco has received no actual reports of malicious exploitation of this problem.

This vulnerability notice was posted on Cisco's World Wide Web site:

http://www.cisco.com/warp/public/770/iossyslog-pub.shtml  
 

This information was also sent to the following e-mail and Usenet news recipients:

• cust-security-announce@cisco.com

• bugtraq@netspace.org

• first-teams@first.org (includes CERT/CC)

• first-info@first.org

• cisco@spot.colorado.edu

• comp.dcom.sys.cisco

• nanog@merit.edu

Affected Devices and Software Versions

Vulnerable devices and software versions are specified in Table 6. Affected versions include 11.3AA, 11.3DB, and all 12.0 versions (including 12.0 mainline, 12.0 S, 12.0 T, and any other regular releases whose number starts with 12.0), up to the repaired releases listed in Table 6. Cisco is correcting the problem in certain special releases and will correct it in future maintenance and interim releases. See the "Software Versions and Fixes" section for details. Cisco intends to provide fixes for all affected Cisco IOS variants.

No particular configuration is needed to make a Cisco IOS device vulnerable. It is possible to filter out attack traffic by using access lists. See the "Workarounds" section for techniques. However, except at Internet firewalls, the appropriate filters are not common in customer configurations. Carefully evaluate your configuration before assuming that any filtering protects you against this attack.

The most commonly used or asked-about products are listed below. If you are unsure whether your device is running classic Cisco IOS software, log in to the device and issue the show version command. Cisco IOS software will identify itself simply as "IOS" or "Internetwork Operating System Software". Other Cisco devices will not have the show version command, or they will identify themselves differently in their output. The most common Cisco devices that run Cisco IOS software include the following:

• Cisco routers in the AGS/MGS/CGS/AGS+, IGS, RSM, 800, ubr900, 1000, 2500, 2600, 3000, 3600, 3800, 4000, 4500, 4700, AS5200, AS5300, AS5800, 6400, 7000, 7200 (including the ubr7200), 7500, and 12000 series

• Most recent versions of the LS1010 ATM switch

• Some versions of the Catalyst 2900XL LAN switch

• Cisco DistributedDirector

Affected software versions, which are relatively new, are not necessarily available on every device listed above. If you are not running Cisco IOS software, you are not affected by this problem.

The following Cisco devices are not affected:

• 700 dialup routers (750, 760, and 770 series)

• Catalyst 1900, 2800, 2900, 3000, and 5000 LAN switches are not affected, except for some versions of the Catalyst 2900XL. However, optional router modules running Cisco IOS software in switch backplanes, such as the RSM module for the Catalyst 5000 and 5500, are affected.

• WAN switching products in the IGX and BPX lines

• MGX (formerly known as the AXIS shelf)

• Host-based software

• Cisco PIX Firewall

• Cisco LocalDirector

• Cisco Cache Engine

This problem has been assigned Cisco caveat ID CSCdk77426.

Solution

Cisco offers free software updates to correct this problem for all affected customers---regardless of their contract status. However, because this vulnerability information has been disseminated by third parties, Cisco has released this notice before updates are available for all software versions. Table 6 gives Cisco's projected fix dates.

Make sure your hardware had adequate RAM to support the new software before installing it. The amount of RAM is seldom a problem when you upgrade within a major release (say, from 11.2(11)P to 11.2(17)P), but it is often a factor when you upgrade between major releases (say, from 11.2 P to 11.3 T).

Because fixes will be available for all affected releases, this problem will rarely, if ever, require an upgrade to a new major release. Cisco recommends very careful planning for any upgrade between major releases. Make certain no known bugs will prevent the new software from working properly in your environment.

Further upgrade planning assistance is available on Cisco's World Wide Web site at:

http://www.cisco.com  
 

If you have a service contract, you should obtain new software through your regular update channels (generally via Cisco's World Wide Web site). You can upgrade to any software release, but you must remain within the boundaries of the feature sets you have purchased.

If you do not have a service contract, you may upgrade to obtain only the bug fixes; Cisco is not offering upgrades to versions newer than the versions required to resolve the defects. In general, you will be restricted to upgrading to a version represented within a single row of Table 6, However, Cisco will make an exception to this policy when no upgrade within the same row is available in a timely manner. Obtain updates by contacting one of the following Cisco Technical Assistance Centers (TACs):

• +1 800 553 2447 (toll-free from within North America)

• +1 408 526 7209 (toll call from anywhere in the world)

• tac@cisco.com

Give the URL of this notice (http://www.cisco.com/warp/public/770/iossyslog-pub.shtml) as evidence for a free update. Non-contract customers must request free updates through the TAC. Please do not contact either "psirt@cisco.com" or "security-alert@cisco.com" for software updates.

Workarounds

You can work around this problem by preventing any affected Cisco IOS device from receiving or processing UDP datagrams addressed to its port 514. This can be done either using packet filtering on surrounding devices, or by using input access list filtering on the affected Cisco IOS device itself.

If you use an input access list, apply that list to all interfaces to which attackers might be able to send datagrams. Interfaces include---not only physical LAN and WAN interfaces---but virtual subinterfaces of those physical interfaces, as well as virtual interfaces and interface templates corresponding to GRE, L2TP, L2F, and other tunneling protocols.

The input access list must block traffic destined for UDP port 514 at any of the Cisco IOS device's own IP addresses, as well as at any broadcast or multicast addresses on which the Cisco IOS device might be listening. Be sure to block both old-style "all-zeros" broadcasts and new-style "all-ones" broadcasts. It is not necessary to block traffic being forwarded to other hosts; only traffic actually addressed to the Cisco IOS device is of interest.

No single input access list works in all configurations. Know the effect of your access list in your specific configuration before activating it.

The following example shows a possible access list for a three-interface router, along with the configuration commands needed to apply the list. The example assumes input filtering is not needed, other than as a workaround for this problem:

! Deny all multicasts, and all unspecified-net broadcasts, to port 514
access-list 101 deny udp any 224.0.0.0 31.255.255.255 eq 514
! Deny old-style unspecified-net broadcasts
access-list 101 deny udp any host 0.0.0.0 eq 514
! Deny network-specific broadcasts. This example assumes that all of
! the local interfaces are on the class B network 172.16.0.0, subnetted
! everywhere with mask 255.255.255.0. This will differ from network
! to network. Note that we block both new-style and old-style broadcasts.
access-list 101 deny udp any 172.16.0.255 0.0.255.0 eq 514
access-list 101 deny udp any 172.16.0.0   0.0.255.0 eq 514
! Deny packets sent to the addresses of our own network interfaces.
access-list 101 deny udp any host 172.16.1.1 eq 514
access-list 101 deny udp any host 172.16.2.1 eq 514
access-list 101 deny udp any host 172.16.3.3 eq 514
! Permit all other traffic (default would be to deny)
access-list 101 permit ip any any
 
! Apply the access list to the input side of each interface
interface ethernet 0
ip address 172.16.1.1 255.255.255.0
ip access-group 101 in
 
interface ethernet 2
ip address 172.16.2.1 255.255.255.0
ip access-group 101 in
 
interface ethernet 3
ip address 172.16.3.3 255.255.255.0
ip access-group 101 in
 

Listing all possible addresses---especially all possible broadcast addresses---to which attack packets can be sent is complicated. If you do not need to forward any legitimate syslog traffic received on an interface, you can block all syslog traffic arriving on that interface. Remember that blocking will affect traffic routed through the Cisco IOS device as well as traffic destined to the device; if the IOS device is expected to forward syslog packets, you will have to do the detailed filtering. Because input access lists impact system performance, install them with caution---especially on systems running very near their capacity.

Software Versions and Fixes

Many Cisco software images have been or will be specially reissued to correct this problem. For example, Release 12.0(2) is vulnerable, as are interim Releases 12.0(2.1) through 12.0(2.3). The first fixed interim version of Release 12.0 mainline software is Release 12.0(2.4). However, a special Release 12.0(2a), contains only the fix for this problem and does not include any other bug fixes from later 12.0 interim releases.

If you are running Release 12.0(2) and want to fix this problem without risking possible instability presented by installing the Release 12.0(2.4) interim release, you can upgrade to Release 12.0(2a). Release 12.0(2a) is a "code branch" from the Release 12.0(2) base, which will merge back into the 12.0 mainline at Release 12.0(2.4).

Special releases, like Release 12.0(2a), are one-time, spot fixes, and they will not be maintained. Thus, the upgrade path from Release 12.0(2a) is to 12.0(3).

Table 6 specifies information about affected and repaired software versions.