|
|
This chapter presents examples of configuring a universal gateway for service as part of the Cisco ASAP Solution. It also presents options for various scenarios, as well as recommendations to optimize performance.
 |
Caution Certain features vary from one Cisco IOS release to another, as do configuration requirements. Before configuring a platform, always refer to the latest release notes for the solution. The release notes for the Cisco ASAP Solution are available at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/solution/asap/index.htm |
For configurations of other solution components, such as gatekeepers and supporting servers, see "Configuring Optional Network Components."
Many of the following configuration and optimization topics are discussed in detail in Chapter 3, "Basic Configuration Using the Command-Line Interface," and Chapter 6, "Configuring Voice over IP," in Cisco AS5350 and Cisco AS5400 Universal Gateway Software Configuration Guide at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5350/sw_conf/53swcg/
The following major topics are covered in this chapter:
This section presents the following fundamental topics and example configurations on the gateway:
"Baseline" includes such universal issues as setting timestamps, establishing a time zone, establishing connections with TFTP servers, and the like. The following annotated configuration excerpt illustrates these issues.
Step 2 Ensure that testing is suppressed, and that console logging is disabled. See Suppressing Modem Startup Tests and Autotests, and Optimizing System Logging.
|
Caution Take care that excessive logging does not overwhelm the CPUs. |
Step 3 Establish a time zone and other clock parameters.
Step 4 Create a loopback interface, to ensure that operations are not dependent on a single physical interface being up. See Enabling Communications between a Gateway and a RADIUS Server.
 |
Note A loopback interface can be used as a source address for many operations (routing protocols, group-async, RADIUS servers. In this case it corresponds to the source interface for TACACS+. |
Step 5 Configure FastEthernet interfaces.
Step 6 Repeat the above for other FastEthernet interfaces as required.
Step 7 Establish an interface for TFTP server connections.
Step 8 Establish a fax interface. The following are defaults.
|
Note The default for interface-type depends on the feature card configuration. If
a modem is present, the default is modem, the case for universal port cards. For fax configuration
information, refer to the following: T.38 Fax for Cisco Universal Gateways at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5400/sw_conf/ios_121/puldtfax.htm Fax Services at the following URL: http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/voipsol/fax_isd.htm The above reference also discusses the command mta, which sets options for SNMP Mail Transport Agents (MTAs). |
|
Note Voice port interfaces are created automatically when ISDN serial D-channels are created. |
References to resources, as well as examples, are provided below for T1, E1, and T3 (channelized T3, or CT3) controllers.
For the fundamentals of configuring T1 and E1 controllers, refer to Configuring Channelized T1 and E1 Trunk Cards in Chapter 3, "Basic Configuration Using the Command-Line Interface," in Cisco AS5350 and Cisco AS5400 Universal Gateway Software Configuration Guide at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5350/sw_conf/53swcg/
For VoIP applications, refer to Configure Signaling on Voice Ports in Chapter 6, "Configuring Voice over IP," in that document.
For a variety of examples of T1 and E1 controller configurations for VoIP, including PRI, refer to Chapter 4, "Provisioning Non-SS7-Based POPs" in the Cisco Wholesale Voice Solution Design and Implementation Guide at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/wv_rel1/wvpg/index.htm
The following configuration examples, although presented for a Cisco AS5300, are also applicable to UGs:
The following example illustrates how to configure T1 controllers.
|
Note The default framing is sf, and the associated default linecode is ami. This and the above framing and linecode are always paired. |
Step 2 Repeat Step 1 for each additional T1 controller. For more details see Enabling SS7 Interconnect on the Gateway (Optional).
|
Note When NFAS (non-facility associated signaling) is implemented, multiple
spans (controllers) will use the same D-channel (see
Step 1). Refer to Chapter 3, "Basic Configuration Using the Command-Line Interface," of Cisco AS5350 and Cisco AS5400 Universal Gateway Software Configuration Guide, at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5350/sw_conf/53swcg/ Refer also to the following in that chapter: Configuring ISDN PRI, Configuring the D Channels for ISDN Signaling, and Configuring ISDN NFAS on CT1 PRI Groups. |
For the fundamentals of configuring T3 Controllers, refer to Configuring Channelized T3 Trunk Cards and Configuring ISDN PRI in Chapter 3, "Basic Configuration Using the Command-Line Interface," in Cisco AS5350 and Cisco AS5400 Universal Gateway Software Configuration Guide at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5350/sw_conf/53swcg/
The following configuration excerpt illustrates the essentials of configuring T3 controllers for PRI service, as well as other key features as noted. Variable options are indicated as follows: <option>.
Step 2 Repeat the above for each additional T3 controller.
|
Note The numbering of steps in this example is for reference only, and generic provisioning not of interest to this solution is not commented on. The order in which various configurations are presented is not the order in which provisioning would occur. Furthermore, privileged EXEC mode is required to enter the commands resulting in the configurations illustrated below. |
Step 2 Ensure that testing is suppressed, and that console logging is disabled. See Suppressing Modem Startup Tests and Autotests, and Optimizing System Logging.
|
Caution Take care that excessive logging does not overwhelm the CPUs. |
Step 3 Establish a time zone and other clock parameters.
Step 4 Establish an interface for TFTP server connections.
Step 5 Configure a T3 controller. Framing and cable length will vary. See Configuring T3 Controllers.
The NTP (Network Timing Protocol) clock period is automatically defined.
|
Caution Do not alter the default clock-period setting. |
|
Note For a discussion of NTP, refer to Enabling Management Protocols: NTP, SNMP, and Syslog at the
following URL: http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/as5xipmo/sysmgt.htm |
Step 2 Define a primary and a secondary NTP server.
ISDN PRI may or may not be required in your network. The following is only an example. For the details of SS7 configuration, see Enabling SS7 Interconnect on the Gateway (Optional).
Step 2 Establish the ISDN switch type of the telco service provider. See Enabling SS7 Interconnect on the Gateway (Optional), and Defining the ISDN Switch Type.
|
Note For a discussion of ISDN switch types, refer to National ISDN Switch Types
for Basic Rate and Primary Rate Interfaces at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_3/natisdn.htm |
|
Caution Cisco recommends that you consult with your telephony service provider to ensure compatibility with the PSTN before proceeding. To support SS7 interconnect, a switch type of primary-ni is required. See Defining the ISDN Switch Type. |
|
Note When a controller is configured for PRI, serial interfaces are created automatically. Repeat the above for each additional serial interface that is automatically created. See also Configuring the ISDN Serial Interfaces 2-9, for information specifically related to enabling synchronous dial services. |
Step 3 Optimize the use of the ISDN B-channel.
This is optional for PRI, but is required for SS7 interconnect.
With NFAS (non-facility-associated signaling) multiple spans share the same D-channel. The D-channel configuration is on the interface associated with the primary NFAS controller. In this case, it is serial 1/0:1:23.
Step 2 Configure, at a minimum, the following:
|
Caution The NFAS interface number (nfas_int number) must be unique to each trunk (controller). All trunks must be placed in the same NFAS group (here nfas_group 0). |
Support for SS7 signaling may or may not be required in your network. On the gateway, the basic configuration consists of the following activities:
Additional options can be configured. For more detail refer to Using SS7 Interconnect References.
|
Note Predefined SS7 resource groups are automatically created when resource pooling is enabled to a Cisco RPMS from a UG that is configured for SS7 interconnect. For details see SS7 Resource Groups. |
SS7 signaling requires a PRI (primary) national ISDN (ni) switch type. Use the following global configuration command:
|
Note The only switch type supported for SS7 interconnect is primary-ni. |
ISDN serial interfaces require signaling that is out of band, over a dedicated data channel, the D-channel. The following configuration is on the D-channel interface (Serial1/0:1:23). [See Configuring ISDN PRI on the Gateway (Optional).]
|
Note Refer to Configuring the D Channels for ISDN Signaling in Chapter 3, "Basic Configuration Using the
Command-Line Interface," of Cisco AS5350 and Cisco AS5400 Universal Gateway Software
Configuration Guide, at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5350/sw_conf/53swcg/ |
|
Note ISDN signaling is from the Cisco RLM. See Configuring RLM and Using Cisco RLM. |
|
Note For more information and references on multilink PPP and multichassis multilink PPP, see Configuring Multilink PPP. |
Where SS7 interconnect is used, Redundant Link Manager (RLM) is a feature that provides virtual link management over multiple IP networks so that the Q.931 signaling protocol and other proprietary protocols can be transported on top of multiple redundant links between the Cisco Signaling Controller (in our case, the Cisco SC2200) and the gateway. In addition, RLM opens, maintains, and closes multiple links, manages buffers of queued signaling messages, and monitors whether links are active for link failover and signaling controller failover. The user can create more than one IP connection between the signaling control and the gateway.
|
Note The following deals with configuring RLM on the gateway only. See
Using Cisco RLM. For more
information about RLM, refer to Redundant Link Manager (RLM) at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5400/sw_conf/ios_121/pull_rlm. htm |
Use the following to establish an RLM group and server.
The server name, SC2200-reference, only has local significance. The link IP address specified, SC2200-IP-address, is that of the Cisco SC2200. The source interface determines the source IP address that will be used by the gateway for RLM traffic.
Two RLM groups can be defined, allowing for redundant links to the Cisco SC2200; however, they must be defined with different weight values. The one with the higher weight is the primary group and is used unless it is out of service.
|
Note The interface defined (for example, Ethernet0) is that of the interface providing the connection to the signaling and management network, not that of the data network connection. |
On the Serial0:23 interface (the D-channel), use the following to assign the rlm-group number that ISDN will start using.
|
Note This ensures that the ISDN protocol stack functions properly while the D-channel information (Q.931
and the Q.921 frames) is transported over possibly multiple IP networks through UDP across links
managed by the RLM. See also Configuring
the ISDN Serial Interfaces. For more details refer to ISDN Module at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t3/isdn_123.h tm |
For complete details of configuring SS7 interconnect, consult the SS7 interconnect solution documentation. References to SS7 interconnect for voice and dial services are presented below.
For the details of configuring SS7 on a gateway for voice services, refer to Configuring Media Gateways for the SS7 Interconnect for Voice Gateways Solution at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/voip13/gateway/dascfg5.htm
For the details of configuring SS7 on a gateway for dial (modem data) services, refer to Configuring Media Gateways for the SS7 Interconnect for Access Servers Solution at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/voip13/gateway/dascfg6.htm
The remainder of the SS7 configuration takes place on the components of the Cisco SC2200 node. See Establishing Additional Components to Support Dial.
This section presents the following service-related topics:
Dial services fall into two fundamental categories, according to whether the data streams rely on a system clock or not: synchronous (ISDN) and asynchronous. Key configurations for each category, respectively, are presented in the following:
To support modem service for analog dial calls, an asynchronous group interface is required, as well as a range of asynchronous interfaces (lines) to be supported. Using an asynchronous group interface makes it easy to configure a large number of interfaces by allowing them to be cloned from a single managed copy. This can reduce the number of lines in the configuration, because each asynchronous group interface configuration can be replaced by at least one group-async.
 |
Tip To assign the asynchronous interfaces to a group-async interface, view the running configuration to determine the number of asynchronous lines that need to be aggregated. |
|
Note For details, refer to Configuring the Asynchronous Group Interface, in Chapter 3, "Basic Configuration
Using the Command-Line Interface," of Cisco AS5350 and Cisco AS5400 Universal Gateway Software
Configuration Guide at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5350/sw_conf/53swcg/ |
Do the following to configure dial-in modem service.
|
Note dialer idle-timeout defaults to a nonzero value. |
|
Note async mode interactive is required only if both EXEC and non-EXEC sessions are to be supported. |
|
Note A noncontiguous range of slots for the DSPs can be entered in the range and the software will adjust accordingly. |
Step 2 Configure lines (support the dial-in interfaces). Configuring lines requires defining a range.
|
Note If the gateway is being used only for dial-in services and COT support is not required, use modem dialin and transport input none. |
Modem capability is defined automatically when the IOS detects the modems.
|
Note The use of autoselect during-login is required only if both EXEC and non-EXEC sessions are to be supported. |
To configure a synchronous dial service, first configure a synchronous dial ("Dialer") interface, then associate a dialer interface group with a serial interface, as shown below.
|
Note The dialer pool 1 (above) must be associated with dialer pool-member 1 (below) on the serial interface. The older method used dialer-group 1. |
|
Caution The command encapsulation ppp is recommended for an ISDN synchronous data call. Of special importance on a UG is the statement ppp multilink, which is required to enable multilink PPP. (See also Enabling Multichassis Multilink PPP., below.) In addition, the command isdn negotiate-bchan resend-setup is recommended for two-way TDM calls. By negotiating for another B-channel if a given channel is occupied, this prevents calls from being rejected. For more detail, see Enabling TDM Switching Services. |
Step 2 Associate the dialer interface group just established with a serial interface.
|
Note The dialer pool-member is associated with dialer pool 1. The older method used dialer rotary-group 1. |
Step 3 Repeat Step 1 and Step 2 for all serial interfaces that are to be associated with the dialer interface group.
ISDN multichassis multilink PPP (MMP) is useful where there are large pools of dial-in users and a single chassis cannot provide enough dial ports. MMP uses Stack Group Bidding Protocol (SGBP) to enable MMP. (See Configuring SGBP (Optional).)
|
Note For background and provisioning information, refer to Layer 2 Tunnel Protocol at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t1/l2tpt.htm |
|
Note For more background and detailed references on Multilink PPP (MLP) and Multichassis Multilink PPP (MMP), see Configuring Multilink PPP 4-34. |
Use the following commands to enable SGBP to support MMP (Multichassis Multilink PPP) connections. See Configuring SGBP (Optional).
In this simple example with a stack that consists of two UGs, sgbp member defines the name and address of the partner UG. That UG would use this command to define the name and address of the current UG. Therefore, an sgbp member line must include all members of the stack with which the current UG must communicate.
|
Note The above information is very basic. For more information and references on multilink PPP and multichassis multilink PPP, see Configuring Multilink PPP. |
Step 4 To enable SGBP, you must enable VPDN. See Enabling VPDN, below.
Generically, an L2TP tunnel is referred to as a VPN (virtual private network) tunnel.
|
Note When L2F is used, the tunnel endpoint is called an
HGW (home gateway). When L2TP is used, the
tunnel endpoint is called an LNS (L2TP network
server). The point of access to the network (in our case the UG) is often referred to as an
LAC (L2TP access concentrator). For an overview and details of configuring virtual private networks, refer to the chapter "Configuring Virtual Private Networks" in the Cisco IOS Dial Technologies Configuration Guide, Release 12.2, at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fdial_c/index.htm |
The establishment of VPDN groups is optional, and is an optimization techniques that employs virtual templates to speed the establishment of call interfaces.For background and information on how to complete this optional provisioning, see Using Virtual Access Interfaces to Optimize Dynamic Interface Configuration.
The following illustrates the establishment of local VPDN groups.
|
Note The gateway provisioning supports interactions with a Cisco RPMS. For details of Cisco RPMS, refer
to Cisco Resource Pool Manager Server 1.1 at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/rpms/rpms_1-1/index.htm (Later versions of Cisco RPMS are known as Cisco Resource Policy Management Server.) See also L2TP Tunneling and VPDNs 4-17 and L2TP Network Server 5-5. |
There are three basic types of VPDN:
Configuration issues related to these VPDN types are discussed in the sections that follow.
|
Note If you are using an LNS as the remote server, before proceeding see L2TP Tunneling and VPDNs. That section illustrates both gateway and server configurations. |
Use the following basic steps to configure VPDN manually on the gateway. If using an LNS, see Configuring VPDN on the LAC. See also Assigning Dial DNIS Groups to Support Local RPM (Optional).
|
Note For an overview and details of configuring virtual private networks, refer to the chapter "Configuring
Virtual Private Networks" in the Cisco IOS Dial Technologies Configuration Guide, Release 12.2, at the
following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fdial_c/index.htm |
|
Note This is the only command required when VPDN definitions are server-based. Continue with the following basic steps if doing local VPDN. |
Step 2 Define a local group number identifier for which other VPDN variables can be assigned. Valid range is from 1 through 3000.
Step 3 Enable the router to request a dial-in tunnel to an IP address, if the dial-in user belongs to a specific domain or dials a specific DNIS.
VPDN must also be enabled on a remote server, such as a Cisco RPMS or Cisco AR. See Configuring VPDN on the LNS.
The details of configuring a UG to interact with a Cisco RPMS server are presented in Enabling Cisco RPMS 1.x.
Virtual access interfaces are logical entities that can optimize the dynamic configuration of serial interfaces for dial services. For the details of configuring this optimization technique, see Using Virtual Access Interfaces to Optimize Dynamic Interface Configuration.
The following sections present optimization techniques that are of value for dial services:
After controllers are configured, the next essential step to enabling voice services is to configure a dial plan. Where universal ports are concerned, a unified dial plan is called for. This section presents the following topics:
A unified dial plan is simply a dial plan that supports both voice and dial numbers. In a converged voice and dial network, a unified dial plan defines how any call, whether voice or dial, should be handled, including whether it should be terminated locally, routed across the network, processed by another element, and so on. This overall unified dial plan is typically implemented on a range of network elements that may include gateways, gatekeepers, route servers, proxy servers, and the like.
The gateway is the main element affected when implementing a unified dial plan (as opposed to a voice-only dial plan), because this is where the decision takes place as to whether or not a call should be processed locally as a dial call. Different called numbers are required to differentiate voice calls from dial calls.
The gateway dial plan implementation continues to define how the gateway should handle all incoming calls, including whether to terminate the call locally, initiate a script to play IVR prompts, forward the call to another gateway, use H.323 RAS (Registration Admission, and Status) messaging, and so on. In a unified dial plan implementation, this is extended to accommodate dial calls that the service provider wishes to have terminated locally.
|
Note For a discussion of dial plans in the context of voice services, refer to Dial
Plans and Number Normalization in Chapter 2, "Provisioning the Gatekeeper Core" in the Cisco
Wholesale Voice Solution Design and Implementation Guide at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/wv_rel1/wvpg/index.htm The topic of static dial plans is discussed in even greater detail in Designing a Static Dial Plan at the following URL: http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/voipsol/dp3_isd.htm |
These are illustrated in the example configuration excerpts that follow.
The following configuration excerpts illustrate assigning dial peers to the voice ports of an H.323 gateway.
|
Note Subsequent steps provide the details of specific dial-peer configurations: POTS, VoIP, and prepaid. The voice ports that are shown are assigned automatically. |
|
Caution Applications that are not compliant with T.38 Fax Relay, such as Microsoft NetMeeting, may not work properly unless certain configurations are applied to the dial peer as well as to the gatekeeper. For details see UG and GK Configuration Requirements for Microsoft NetMeeting with T.38 Fax Relay. |
Step 2 Configure a POTS voice dial peer.
Step 3 Configure a variety of VoIP dial peers.
|
Note For a discussion of direct-inward-dial and
session target ras, refer to the technical note Voice-Understanding How
Inbound and Outbound Dial Peers are Matched on Cisco IOS Platforms at the following URL: http://www.cisco.com/warp/public/788/voip/in_dial_peer_match.html |
Step 4 Configure a dial peer for prepaid calling-card services.
|
Note For a discussion of other aspects of enabling prepaid services for voice, see Enabling Prepaid. |
The following discusses the configuration required to enable H.323 registration on a gateway so that the GW can register with a GK. For a discussion of what is required on the GK, see Establishing a Gatekeeper.
|
Note Refer to Configuring Gateways and a Gatekeeper in a Single Zone, in Chapter 2, "Provisioning the
Gatekeeper Core," of the Cisco Wholesale Voice Solution Design and Implementation Guide, at the
following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/wv_rel1/wvpg/index.htm |
Enabling prepaid billing services for voice calls is discussed in considerable detail in Establishing Billing Services for Calling Card Services, in Chapter 3, "Provisioning Shared Support Services," of the Cisco Wholesale Voice Solution Design and Implementation Guide, at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/wv_rel1/wvpg/index.htm
In addition to establishing a dial peer dedicated to this service, call treatment will need to be enabled and interactive voice response (IVR) facilities will need to be established and provisioned. The following fundamental steps are required:
An example dial peer for prepaid service is illustrated in Step 4 of Assigning Dial Peers to Voice Ports.
Do something similar to the following to enable interactive voice response (IVR) prompts for prepaid calling-card services.
|
Note Refer to Provisioning Services to Support IVR in Chapter 3, "Provisioning Shared Support Services," of
the Cisco Wholesale Voice Solution Design and Implementation Guide, at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/wv_rel1/wvpg/index.htm |
Step 2 Determine a user ID length.
Step 3 In our example, make English the first language of choice.
Step 4 In our example, make Spanish the second language.
Step 5 Declare the location of the two prompt files, respectively.
You will also need to enable H.323-based accounting on the gateway, an AAA feature. See Enabling H.323-Based Accounting for Voice.
Cisco AS5350 and AS5400 UGs support fax over IP services in addition to VoIP. The Cisco T.38 Fax Relay for Universal Gateways feature provides standards-based fax relay protocol support on UGs.
|
Caution Applications that are not compliant with T.38 Fax Relay, such as Microsoft NetMeeting, may not work properly unless certain configurations are applied to the dial peer as well as to the gatekeeper. For details see UG and GK Configuration Requirements for Microsoft NetMeeting with T.38 Fax Relay. |
|
Note For more detail, see Enabling T.38 Fax Relay
Service. Refer also to T.38 Fax for Cisco Universal Gateways at
the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5400/sw_conf/ios_121/puldtfax. htm |
When a fax is sent from an originating GW, an initial voice call is established. The terminating GW detects the fax tone generated by the answering fax machine. The VoIP H.323 call stack then starts a T.38 mode request, using H.245 procedures. (H.245 is a core component of the H.323 standard that specifies messages for opening and closing channels for media streams, and other commands, requests and indications.) If the opposite end of the call acknowledges the T.38 mode request, the initial audio channel is closed and a T.38 Fax Relay channel is opened. When the fax transmission is completed, the call reverts back to voice mode.
The command voice service voip enters the voice service configuration mode. The subsequent command fax protocol specifies the global default fax protocol for all the VoIP dial peers. The keyword t38 specifies the T.38 Fax Relay protocol.
|
Caution T.38 Fax Relay can be configured under dial-peer voice, but the configuration for the specific dial peer takes precedence over the global configuration implemented under voice service voip. |
|
Note For further details, additional references, and configuration examples, refer to T.38 Fax Relay for Cisco
Universal Gateways, at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5400/sw_conf/ios_121/puldtfax. htm |
After receiving an incoming call with SS7, ISDN PRI, or CAS signaling, Cisco UGs analyze the dialed digits and, if required, forward the call outward (using the appropriate outbound signaling) to the designated port or trunk group. This feature, variously referred to as "grooming," "drop and insert," or (in EMEA) "tromboning," is necessary for PSTN interconnects to provide not only legacy voice services but also test calls. The TDM switching feature of the UGs allow cross-connections to be made directly on the time slot interchange (TSI) portion of the DSP.
|
Note TDM switching, the ability of Cisco AS5000 series UGs to switch information directly between two DS0
circuits without affecting the data, is introduced in TDM Switching, in Chapter 2, "Solution Architecture
and Services," of the Cisco ASAP Solution Overview and Planning Guide at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/solution/asap/overview/index.htm |
Any Cisco AS5000 series trunk interface (T1 or E1, including T1s inside a CT3) can be designated as an outbound or inbound trunk for TDM switching purposes. SS7, network-side ISDN PRI, user-side ISDN PRI, or CAS signaling is provided on this outbound trunk to signal calls redirected by the UG. Calls to be redirected are identified simply through a dial-peer match of the called number, or DNIS (Dialed Number Identification Service).
|
Note Dial peers are discussed in TDM Switching, in Chapter 2, "Solution Architecture and Services," of the
Cisco ASAP Solution Overview and Planning Guide at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/solution/asap/overview/index.htm See also Establishing Unified Dial Plans 2-17. |
Refer also to the following useful documents at their respective URLs:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/multi_c/mcprt1/mcdvoip.htm
Network Side ISDN PRI Signalling, Trunking, and Switching
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/dtpri_ni.htm
The example configuration presented below illustrates one way to configure both SS7-to-PRI and PRI-to-SS7 switching. Controllers 1/0:1 through 1/0:14 represent SS7 ingress and egress facilities. Controllers 1/0:15 through 1/0:28 represent ISDN non-NFAS ingress and egress facilities, with a switch type of NI2 (National ISDN-2).
In this example, any incoming SS7 10-digit call with the called-number NPA-NXX digits 904-102 is switched to the ISDN PRIs on controllers 1.0:15 through 1/0:28. Conversely, any incoming 10-digit call on the ISDN PRIs with the called-number NPA-NXX digits 904-704 is switched to the SS7 RLM NFAS group 0, which consists of controllers 1/0:1 through 1/0:14.
On the ISDN PRI egress side, this configuration provides two principal benefits:
In the following excerpt, the first five steps simply configure the controllers. The last step, the configuration of dial peers, is what really enables TDM switching.
|
Note This dial peer begins the SS7-to-PRI hunt. By default its preference is 0, but there is no preference 0 line. |
|
Note This dial peer does not have a preference. It switches calls from the ISDN PRIs to the SS7 T1 controllers 1/0:1 through 1/0:14. |
Step 2 Configure B-channel negotiation to support simultaneous ingress and egress traffic. This is done on the serial controller that supports the SS7 D-channel, as in the following abbreviated example.
Step 3 Reduce the chance of B-channel glare (assignment contention) with bidirectional traffic. To do this, make the near-end hunt proceed in a direction opposite that of the far-end setting.
|
Caution Take care to confirm the far-end hunt direction first. |
Note the following abbreviated example.
As the default is descending, it is probably the setting at the far end.
This section covers the following topics:
Enabling basic AAA service consists of three fundamental steps:
3. Defining methods to apply to each of the three elements of AAA: authentication, authorization, and accounting. This step requires the use of method lists, which will vary according to the needs of each network.
For background, the AAA method lists for authentication, authorization, and accounting are discussed in "AAA Method Lists."
The following examples illustrate how to enable AAA accounting for voice services on the gateway. The following topics are covered:
For prepaid services (see Enabling Prepaid, you will need to enable H.323-based accounting on the gateway. The vsa (vendor-specific attributes) command option is required to support prepaid voice services only.
|
Note For a discussion of VSAs in the context of AAA billing, refer to
Understanding and Provisioning AAA Billing in Chapter 3, "Provisioning Shared Support Services," of
the Cisco Wholesale Voice Solution Design and Implementation Guide, at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/wv_rel1/wvpg/index.htm Refer in particular to Methods to Enable VoIP Accounting on Gateways to Support Billing in that section. |
The following steps illustrate basic AAA provisioning. (There are many options that are beyond the scope of the current discussion.)
Typically AAA groups are used. This allows different servers to be used for each element of AAA. It also defines a redundant set of servers for each element. However, the keywords radius or tacacs+ are also used. The latter approach uses globally defined RADIUS or TACACS+ servers, and is not as flexible as using AAA server groups.
|
Note The above port numbers are defaults, for authorization and accounting, respectively. Explicit port numbers are required only if nondefault ports are used. |
Step 3 Define AAA method lists. The following lines are processed sequentially.
This does the following. By default, authenticate users requesting login access by first checking the local username list. If the username is not listed locally, authentication will be through the AAA servers defined in the AAA group server-group-name. Defining local authentication first is typical where ports are being used by scripted login clients who use generic passwords (such as AOL). If there is no response from the servers, login users will not be able to access the network.
This does the following. By default, authenticate users requesting PPP access only if they have not already been authenticated. Authenticate first through the local database. If that fails, authenticate through the AAA servers defined in the group server-group-name. This can be used to access the gateway locally for administrative purposes in case, for example, network connectivity to the gateway is down.
This does the following. By default, authorize users running EXEC shells through the AAA servers defined in the AAA group server-group-name. If there is no response from the servers (for example, they are not working), just let them run the required services.
You can also define additional AAA accounting options. Select only those steps you want to apply. (The following commands are used in global configuration mode.)
This prevents accounting packets from being sent for users who are autoselected as connecting through PPP. Initially the gateway assumes a login session (rather than a PPP session, which is aborted when PPP is detected).
Step 2 Include the IP address in the start record.
Step 3 Send accounting records on system start/stop.
As in start-stop, this sends both a start and a stop accounting notice to the accounting server. However, if you use the wait-start keyword, the requested user service does not begin until the start accounting notice is acknowledged. A stop accounting notice is also sent.
You may also find one or more of the following useful. (The following commands are used in global configuration mode.)
This allows interfaces in the same slot to be differentiated (for example, 1/0:1 from 1/0:3).
|
Caution The above requires VSAs, so these must be enabled. See Enabling H.323-Based Accounting for Voice. |
Step 2 Use multithreaded AAA processing. [This is required only in IOS releases prior to Cisco IOS Release 12.2(2)XB.]
where n = the number of AAA processes.
Cisco recommends 5 < n < 15 for RADIUS-only environments, and 10 < n < 30 for environments with TACACS+.
|
Caution Adjust n with care, as this creates a bell-curve performance profile that is environment-specific. Increase its value to decrease the PPP queue, and ensure that the CPU is not burdened by PPP queue improvements. |
|
Tip Use show ppp queue to check for improvements. For an example of CPU monitoring, see Scaling AAA Processing. |
Through the use of administrative listnames, you can control authentication, authorization, and accounting for administrative groups. Here we use the example listname ADMIN. Select only those steps you wish to apply. These options can be applied to console (line con 0), auxiliary (line aux 0), and virtual terminal (line vty 0 4) interfaces.
Step 2 Define an administrative authentication method list.
This first authenticates users through the AAA server group LAB, then proceeds to the local username list. The AAA group ADMIN corresponds to the login authentication ADMIN configured in the previous step.
Step 3 Define an administrative authorization method list.
|
Note This does the following. The result is the same as for the previous command, but for the listname ADMIN, through the AAA servers defined in the AAA group LAB. |
Step 4 Define an administrative command level for authorization.
This does the following. The variable level is the specific command level that should be authorized. Valid entries are 0 through 15. Level 1 is normal user EXEC commands. Level 15 is the privileged level. There are five commands associated with privilege level 0: disable, enable, exit, help, and logout. If you configure AAA authorization for a privilege level greater than 0, these five commands will not be included in the privilege level command set.
Step 5 Configure an administrative accounting method list.
Step 6 Run accounting for all commands at the specified privilege level.
This does the following. The variable level is the specific command level that should be tracked. Valid entries are 0 through 15. Level 1 is normal user EXEC commands. Level 15 is the privileged level. There are five commands associated with privilege level 0: disable, enable, exit, help, and logout. If you configure AAA authorization for a privilege level greater than 0, these five commands will not be included in the privilege level command set.
|
Note For details, refer to Accounting Commands at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_r/srprt1/sracct.htm |
Step 7 Provide information about all outbound connections made from the gateway (such as Telnet, local-area transport (LAT), TN3270, packet assembler/disassembler, and rlogin).
After AAA is enabled and RADIUS servers and keys are defined on the client gateway, communications must be established between the gateway and the RADIUS server. This section addresses the recommended configurations on the gateway, with the basic options you should configure there. See also Enabling RADIUS-Based PPM.
|
Caution You must enable AAA on the gateway before you can configure RADIUS. See Enabling Basic AAA Service: Examples. |
|
Note A detailed discussion is also provided in Configure Communication between the Gateway and the
RADIUS Server in Configuring a Gateway for AAA, Chapter 3, "Provisioning Shared Support
Services," of the Cisco Wholesale Voice Solution Design and Implementation Guide, at the following
URL: http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/wv_rel1/wvpg/index.htm The above-referenced section also illustrates how to configure the gateway to use VSAs and how to configure gateway-specific accounting. |
The full RADIUS command syntax on the gateway is as follows:
|
Caution The order of option entry is important, as certain options are no longer available after you enter certain other options. Specifically, the key must be entered at the end. |
|
Note Refer also to RADIUS Commands at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122cssec/ssfrad.ht m There are many other options that are not addressed here. For a discussion of server implementations of RADIUS, refer to Configuring RADIUS at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt2/scdrad.ht m |
Do the following to establish communications. You can selectively define the parameters to override, and leave others at their default values by not defining them. (You cannot define deadtime as a server-specific parameter.)
The above line is required for each RADIUS server listed in an AAA server group. Define on the client gateway the authentication and accounting ports on the RADIUS server. These are the ports on the server to which the client will send authentication and accounting data. Keys are typically defined for each RADIUS server, although a global command is available. There is no default key.
|
Caution You will not be able to configure these ports after the key is established. |
The Cisco defaults for auth-port and acct-port are 1645 and 1646, respectively. (The RFCs define these as 1812 and 1813, respectively.) The important thing is to make sure the client ports match the corresponding ports on the RADIUS server. Server-specific values must be defined as part of the radius-server definition for that server.
Step 2 Define additional communications parameters. These include timeouts, retries, and deadtime, as defined in the substeps below. The values shown in the configuration lines are Cisco's recommendations.
a. Define how many times the client should try to contact the server before giving up. (The default value is 3 retries.)
b. Define how long the client should wait before retrying to get a response from the server. (The default value is 3 seconds.)
c. Define how long the client should wait before attempting to contact the server again. (This is the default.)
This means that, after the RADIUS server is declared dead, the client will wait 1 minute before attempting to communicate with the server again.
Step 3 Define basic RADIUS server attributes. The following are Cisco's recommendations.
This causes the client to send attribute 6 (Service-Type) set to "1" (login) for users connecting through EXEC, and to "2" for users connecting through PPP.
The Accounting Session ID is a unique identifier used to calculate the session context. It is the only identifier provided by the RADIUS protocol that can relate authentication and accounting requests to one another with absolute certainty. Attribute 44 allows the service provider to track all RADIUS information associated with a specific call, from initial connection through termination. This is useful where preauthentication or VPDN is used.
c. If using a management and accounting built around Ascend's port format (Format C), configure the RADIUS server to send Attribute 25 information and use Format C.
|
Note Attribute 25 is not a VSA, but instead is an IETF Class attribute. The above string is typically
included in the access-accept packet. If it is provided, it must also be included by the UG in
accounting-start and accounting-stop packets. Format C applies only if you are using the Ascend port format. For more information, see "Format C." Otherwise, you can use any suitable format. |
Step 4 Define additional RADIUS options. The following are Cisco's recommendations.
The above prepends a value defined to the Acct-Session-Id string. Each time the system reboots, this value increments and is updated in the system configuration.
Following a system reboot, we have
b. Enable vendor-specific attributes (VSAs). These are required for the client to send, receive, and process VSAs. The following lines enable VSAs for accounting and authentication, respectively.
VSAs are needed to support other options such as aaa nas-port extended. In this case both the accounting and authentication attributes are included, and the extended information is included in a VSA that is sent within Attribute 26.
Use this command to set a subinterface's IP address to be used as the source address for all outgoing RADIUS packets. This address is used as long as the interface is in the up state. In this way, the RADIUS server can use one IP address entry for every network access client instead of maintaining a list of IP addresses.
This ensures that the source IP address used for RADIUS packets from the client is deterministic. Typically, a loopback interface ensures that there is no dependence on a single physical interface being up.
|
Tip The above command is especially useful in cases where the router has many interfaces and you want to ensure that all RADIUS packets from a specific router have the same IP address. |
This section discusses how to enable port policy management (PPM) on the gateway. PPM is not required, but is recommended wherever traffic and resources need to be managed. PPM can be enabled locally through RPM features, or it an be enabled remotely in conjunction with a Cisco RPMS or a RADIUS server.
This section presents the following basic topics:
Enabling RPM locally, on the client gateway, requires the following steps:
The following configuration excerpts illustrate the establishment of resource pools on the gateway (that is, for local RPM). The VPDNs are optional.
Step 2 The following illustrates the establishment of local VPDN (virtual private data network) groups. See Enabling Multichassis Multilink PPP, and Enabling VPDN (Optional).
|
Note The establishment of VPDN groups is optional. For details of Cisco RPMS,
refer to Cisco Resource Pool Manager Server 1.1 at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/rpms/rpms_1-1/index.htm |
VPDN groups contain the data required to build a VPDN (VPN) tunnel from the UG to the LNS. See also L2TP Tunneling and VPDNs and L2TP Network Server.
|
Note For additional details see Resource Pool Management at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/rpm1205t.htm |
Step 3 Establish a resource pool profile with AAA parameters.
|
Note See Assigning Dial DNIS Groups to Support Local RPM (Optional). |
Resource pool management (RPM) allows wholesalers to aggregate dial resources across multiple gateways and allocate subsets of those resources to their retail ISP customers. RPM enforces service level agreements (SLAs) for dial access for each ISP. Where a better use of dial resources is required, a Cisco RPMS can be used.
The following illustrates local RPM only. To use a Cisco RPMS, see Enabling Cisco RPMS 1.x.
|
Note Refer to Configuring Media Gateways for the SS7 Interconnect for Voice
Gateways Solution at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/das22/gateway/dascfg5.htm |
For a detailed illustration of enabling Cisco RPMS on the gateway, see Enabling Cisco RPMS 1.x.
Enabling RADIUS-based PPM consists essentially of establishing communications between the host gateway and one or more RADIUS servers, and enabling AAA preauthentication. Preauthentication can be specified according to the following criteria: CLID (Calling Line IDentification) number, call type, or DNIS number. You can also specify a group of DNIS numbers that will be bypassed for preauthentication.
Step 2 Ensure that AAA is enabled. See A Basic AAA Example.
Step 3 To enter AAA preauthentication configuration mode, enter the following in global configuration mode:
Step 4 The prompt changes. To specify a AAA RADIUS server group to use for preauthentication, enter the following at the prompt:
Step 5 Specify preauthentication criteria as needed.
|
Note For details, refer to "Configuring AAA Preauthentication" in Configuring RADIUS at the following
URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/fsecsp/scfrad.h tm |
Step 6 There is another method to configure DNIS preauthentication. For details, refer to the section mentioned in the previous note.
Step 7 In addition to configuring preauthentication on the gateway, you must also configure preauthentication profiles on a RADIUS server. For details, refer to the section mentioned in the previous note.
Call admission control, or CAC, is a feature that gracefully prevents call from entering the gateway if certain resources (for example, CPU capacity, memory, and interfaces) are not available to process those calls. To deal with high CPU use, large call volumes, or occasional large numbers of calls (spikes), CAC allows you to address both call spikes and call thresholds. Configure call spikes to limit the number of incoming calls over a short period of time. Configure call thresholds to define the circumstances under which system resources should be enabled.
For the details of CAC features, both basic and enhanced, see Call Admission Control and RSVP.
|
Caution Managing call spikes and thresholds is especially important in handling transactions involving debit cards, which require AAA and similar types of support. |
|
Note For additional information on CAC, refer to Call Admission Control for H.323 VoIP Gateways at the
following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xa/122xa_2/ft_pfavb.h tm |
The following steps illustrate the use of call treatment to establish a call threshold and a resource threshold. See Call Admission Control and RSVP. Both RAI (Resource Allocation Indicator) and non-RAI examples are shown.
|
Note The above does not use RAI (Resource Allocation Indicators). Not all Call Admission Control (CAC) features are available in early releases of the Cisco ASAP Solution. |
Step 2 Globally set a CAC H.323 RAI resource threshold on all ports. This also causes RAI information to be sent to the GK.
|
Note See also Call Admission Control and RSVP, page 4-2. This topic was introduced in Chapter 5, "Solution Management," of the Cisco ASAP Solution Overview and Planning Guide. |
To be managed properly, networks of any considerable size require the collection of various types of data. This section discusses the fundamentals of reporting (including logging, syslog, and SNMP), as well as of the Cisco IOS feature known as CallTracker, under the following topics, respectively:
The details of enabling such reporting features as logging, syslog, and SNMP are covered in section 7, Enabling Management Protocols, of the Cisco AS5x00 Case Study for Basic IP Modem Services at the following URL:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/as5xipmo/sysmgt.htm
The discussion there is applicable to gateways in general. The following example addresses syslog logging.
Cisco IOS software can send syslog messages to one or more element manager servers. Syslog messages are then collected by a standard UNIX or NT type syslog daemon. With syslog you can do the following:
Syslog is recommended for all but the smallest networks. For syslog to be used, logging must first be enabled.
|
Caution To enable syslog, ensure that console logging is disabled. Use show logging to confirm this, and no logging console to turn off console logging if it is enabled. |
After timestamps are enabled (see Baseline Configuration), there are two more fundamental steps to enabling reporting:
Logging can be enabled by itself on the gateway, and is required for syslog to be used. Do the following to enable basic logging.
Step 2 If you are working with multiple gateways, assign a different logging facility tag to each server.
Step 3 Assign the interface to the syslog server.
Step 4 Assign the address of the syslog server.
The SNMP (Simple Network Management Protocol) traps generated by the gateway can provide a variety of useful information. This section is concerned only with what is required on the UG to enable SNMP. An SNMP server must also be configured. For more information see Enabling SNMP.
Do the following to enable SNMP on the UG. The following example presents just a few options.
Step 2 Define the community access string. Here it is public but read-only.
Step 3 Enable SNMP traps. Here we enable traps for ISDN at layer 2.
|
Note Refer also to Configuring Simple Network Management Protocol (SNMP) at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/fun_c/fcprt3/fcd301.ht m |
CallTracker is a network management subsystem within the Cisco IOS. Relying on syslog and SNMP, CallTracker enables the tracking of calls and their attributes, from the ingress ports (T1, E1, CT3) to the DSP resource used. This feature captures detailed statistics on the status and progress of active calls and retains historical data for disconnected call sessions. CallTracker collects session information such as call states and resources, traffic statistics, total bytes transmitted and received, user IP address, and disconnect reason. The resulting database tables can be accessed through SNMP, syslog, or the Cisco IOS command line interface.
The primary purpose of CallTracker is not only to provide detailed output about the gateway's performance (such as the number of good vs. bad calls), but also to help improve the analysis and use of resources—for example, in determining which DSPs are not functioning properly, or which ingress channels are not in use.
|
Note CallTracker has many features that are not discussed here. CallTracker was originally introduced on
Cisco AS5300 and AS5800 platforms, and is documented in greater detail in CallTracker plus ISDN and
AAA Enhancements for the Cisco AS5300 and Cisco AS5800 at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/dt_cltrk.ht m |
The following steps provide the basic operation of CallTracker on the gateway. You will also need to ensure that syslog and SNMP are enabled. See Enabling Reporting.
Step 2 Send call information to syslog for processing at a later date.
By default, call record logging is disabled. Cisco recommends the options verbose and quiet. The subcommand terse generates a brief set of call records containing a subset of the data stored within CallTracker (used primarily to manage calls). The subcommand verbose generates a complete set of call records containing all of the data stored within CallTracker (used primarily to debug calls). The option quiet causes call records to be sent only a configured syslog server, and not to the console.
Step 3 Configure the history buffer.
|
Caution CallTracker does not report to the syslog server immediately after a call has disconnected. This is because it is not a high-priority process, and must wait for sufficient CPU capability to be available. This can take up to a minute. Consequently, the history buffer needs to be large enough to hold the data before reporting. |
As a rule of thumb, figure out the maximum number of calls you will receive over a 1-minute period. Consider call length, call type, and the fact that ISDN calls are shorter than modem calls. Also consider that a configuration error or hardware failure in one part of the system could force a higher call rate in another part.
As a first estimate for number, Cisco recommends you begin with
number of ports on gateway x 4
where 4 takes into account 4 calls per second arriving on a gateway.
Step 4 Configure polling intervals for modem statistics. The syntax is as follows:
The above sets the polling interval at which link statistics for disconnected calls are retrieved from the modem. As mentioned previously, this information is buffered and sent to the syslog server for later processing.
This section presents a variety of Cisco recommendations that will reduce processing overhead, logging interactions, and other system activities that can impair networks of any substantial size and traffic burden if they are not managed carefully. The following topics are presented:
|
Note Some of these issues have already been addressed previously in this chapter. They are presented again here for convenience and emphasis. |
Overburdening the processing power of a CPU can have a pronounced effect on overall network efficiency. The more overburdened CPUs there are in a network, the greater the impairment. This section discusses a variety of techniques to relieve the CPU of unnecessary tasks and allow it to deal with demanding ones as needed. The following topics are presented:
Processes such as ISDN Layer 2, EXEC sessions, AAA messaging, and the like must not be starved for CPU. Use one or both of the following terminal configuration commands to ensure that processing power is available for those processes:
The above allows low-priority processes to be scheduled every 500 ms, thereby allowing some commands to be typed even if CPU use is at 100%.
Step 2 Guarantee CPU time for low-priority processes.
The above guarantees CPU time for low-priority processes by putting a maximum time allocated to fast switching (3000 ms) and process switching (1000 ms) for each instance of network interruption.
|
Note The above recommendations are found in Troubleshooting Router Hangs at the following URL: http://www.cisco.com/warp/public/63/why_hang.html |
To ensure that resources are available, you can use the following command to specify the percentage of available port resources required to enable a trunk line. (See Delay Trunk Activation.)
Unnecessary logging can place unneeded burdens on platform CPUs. Logging to the console, in particular, can have undesired effects. Cisco recommends the following logging settings.
|
Caution A failure to disable console logging can cause CPU interrupts, dropped packets, and denial of service events. The router might also lock up. |
Step 2 In case you ever need to enable console logging, use the following rate-limit command option to prevent the console from being overwhelmed by messages:
Step 3 Disable logging on serial D-channel interfaces and group async interfaces.
Step 4 Double-check features that generate logging. (See Configuring CallTracker.)
PPP multilink fragmentation is enabled by default. Turning it off can relieve the load on the CPU. To do so, use the following command:
On occasion certain processes can be so demanding that they prevent other processes from using the CPU. The default maximum time for a single process to execute is 200 ms. However, it can be beneficial to set a limit that allows the vast majority of processes to execute while preventing long processes from dominating. To prevent exceptionally busy processes from starving others for CPU processing power, Cisco recommends the following:
Use multithreaded AAA processing to provide for a load-sharing distribution of processes. This is illustrated in Other AAA Options. Note the caution there, and adjust the number of processes with care.
To see, for example, the processes that are related to PPP authorization, use the following command:
To minimize unnecessary processing burdens resulting from the use of access control lists (ACLs), Cisco recommends the following general guidelines.
There are a variety of issues related to the use of Cisco Express Forwarding (CEF) and cache that need to be considered.
CEF optimizes network performance and scalability for networks with large and dynamic traffic patterns. It is less CPU-intensive than fast switching route caching. Distributed CEF, or dCEF, is a default on some platforms.
To enable CEF, use the ip cef command in global configuration mode. To disable CEF, use the no form of this command. The keyword distributed enables dCEF.
There are also cache settings (related to cache aging and I/O caching) that can help improve performance. Table 2-1 lists recommended CEF and cache settings for a variety of Cisco access platforms used in the Cisco ASAP Solution.
|
Caution Do not enable cache aging if you are using multilink PPP or VPDN. |
Recommendations for modem management include the following topics:
Modems may occasionally stop working. However, reloading the firmware generally resets the modem. The gateway can identify which DSPs have gone out of operation, and automatically reloads their firmware with minimal impact on end users or gateway capacity. Do the following for basic modem management.
This is used in the same way the show modem command is used for MICA modems. (The show modem command is not supported on the Cisco AS5350 or Cisco AS5400.)
|
Note The term SPE refers to the universal port card. For details refer to Managing and Troubleshooting the
Universal Port Card at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5350/sw_conf/53swcg/54nextpt.htm |
|
Caution Modem commands differ between MICA and NextPort modems. The syntax for the latter is that used for universal gateways. Refer to Comparing NextPort SPE Commands to MICA Modem Commands at the following URL: http://www.cisco.com/warp/public/76/nextport_compare.html |
Step 2 Use the spe command set, as in the following example, to configure recovery thresholds and download parameters.
|
Note Refer to Chapter 3, "Basic Configuration Using the Command-Line Interface," of Cisco AS5350 and
Cisco AS5400 Universal Gateway Software Configuration Guide, at the URL at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5350/sw_conf/53swcg/ |
|
Tip For more details of setting failure thresholds and configuring download times, refer to Configuring Modem Recovery at the following URL: http://www.cisco.com/warp/public/76/modem-recovery.html |
For modems attached to asynchronous lines, a predefined modem capability, or modemcap, is used as an initialization script. That script facilitates the proper operation of the Cisco modem software in handshaking with and responding to calls from the user's dial-in modem. The Cisco IOS maintains a set of built-in modemcaps for various internal and external user modems. A variable command option, modemcap_name, is used to represent a variety of modem types made by a variety of manufacturers.
|
Note For more detail refer to Modem-Router Connection Guide at the following URL: http://www.cisco.com/warp/public/76/9.html |
Do the following to create a minimum modemcap that will improve handshaking efficiency.
where type in this case is not an existing modem type, but rather, for example, MyGenericModemcap (an arbitrary name).
Step 2 Now use the following global configuration command modemcap edit to edit the new modemcap. The syntax is as follows:
|
Note &F represents the built-in MICA and NextPort modems, and may be used with many modems to reset them to their factory defaults. |
|
Caution Make sure that startup tests and autotests are never enabled. Such tests, unless required, will have a negative impact on network operations. |
The following is the command syntax for suppressing startup tests or autotests on universal gateways, which use SPEs:
Use two separate lines to turn off both test types.
Cisco recommends that you disable traps on serial D-channel interfaces, but allow them to be enabled if a D-channel does go down.
Step 2 Enable traps if a D-channel goes down. This is a global command.
|
Caution Generally speaking, because of the messaging interactions required, be selective when you enable SNMP features and options. |
Virtual access interfaces are logical entities—configurations for a serial interface that are not tied to a physical interface. One way to create virtual access interfaces is to use virtual template interfaces. In this case, the interfaces are cloned dynamically from a predefined configuration template for dial-in services. For example, when a user dials in, a predefined configuration template is used to configure a virtual access interface. When the user is done, the virtual access interface goes down and the resources are free for other dial-in uses.
Each virtual access interface can clone from only one template. However, some applications can take configuration information from multiple sources :virtual profiles can take configuration information from (a) a virtual template interface, (b) interface-specific configuration information from a user stored on an AAA server, (c) network protocol configuration from a user stored on an AAA server, or (d) all three. A virtual profile is a unique Point-to-Point Protocol (PPP) application that can create and configure a virtual access interface dynamically when a dial-in call is received, and tear down the interface dynamically when the call ends. The use of both templates and AAA configuration sources results in a unique virtual access interface for each dial-in user.
In addition, a precloning feature causes virtual access interfaces to be cloned in advance on the gateway, reducing the load on the system during call setup.
In summary, a significant feature of virtual profiles, virtual templates, and precloning is that these features reduce the demands on the gateway CPU. Choose one or both of the following options, as needed:
Do the following to create virtual access interfaces on the inbound connection as required.
|
Note For further information, refer to Configuring Virtual Template Interfaces at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fdial_c/fnsprt8/dafvrtmp.htm |
Step 2 Enable IP without assigning a specific IP address.
Step 3 Enable PPP encapsulation on the virtual template interface.
Step 4 Create virtual-access interfaces only if the inbound connection requires one.
Do the following to specify the number of virtual-access interfaces to be created and cloned from a specific virtual template.
|
Note For further information, refer to PPP Autosense at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121limit/121dc/121dc1/auto_ppp. htm |
In global configuration mode, preclone virtual access interfaces as follows:
In other words, specify the number of virtual-access interfaces (number) to be created and cloned from a specific virtual template (template-number).
There are a variety of Cisco IOS-based configuration settings that can also improve performance. If you have not already implemented the following, Cisco recommends that you review these topics and implement the respective commands.
You can enable trunks to be activated when a defined percentage of SPEs (system processing engines) are ready to process calls, with the following command.
This prevents the platform from attempting to accept calls before a sufficient number of SPEs are ready.
|
Note Refer also to Setting the Port Threshold for the Trunk Card at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dt_port.ht m |
Passive TCP header compression can help improve efficiency.
Where dial-in only service is to be supported, the following commands will optimize the handling of calls:
The following special topics are presented in this section:
This section provides resources for enabling V.44 and V.92 features that are available in Cisco AS5350 and Cisco AS5400 universal gateway modem firmware. (These features are also available on Cisco AS5300 modems.)
ITU-T standard V.44 is a compression algorithm known as LZJH (for Lempel-Ziv-Jeff-Heath). V.44 LZJH compression increases upload and download speeds, making Internet access and Web browsing faster, and also improving the call success rate.
For more information on this feature, as well as how to implement it, refer to the feature module V.44 LZJH Compression for Cisco AS5350 and Cisco AS5400 Universal Gateways at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xb/122xb_2/ft_v44.htm
A new ITU-T modem standard, V.92, has been developed to enhance the existing V.90 standard. V.92 provides faster upstream speeds in analog (client) to digital (ISP) modem connections, while making possible such features as quicker modem negotiation and a modem-on-hold (MOH) capability. These new capabilities are addressed, respectively, by the following feature enhancements to the Cisco IOS and the feature card firmware:
Related statistics are also collected by the feature card, for storage in the Cisco IOS software.
Quick connect (QC) provides a standard method of reducing the negotiation time by storing analog channel characteristics (such as equalizer taps and echo canceller taps) in nonvolatile memory on the modem feature card. Similarly, digital characteristics are also stored. After characteristics have been established and stored, on subsequent calls to a server modem equipped to train fast, the client modem examines the answer tone to verify that line conditions match the saved parameters. If they match, an fast connection is attempted. (Negotiation times can be reduced from 20 to 10 seconds.) If they do not, a regular V.90 handshake commences.
For more information on this feature, as well as how to implement it, refer to the feature module V.92 Quick Connect for Cisco AS5350 and Cisco AS5400 Universal Gateways at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xb/122xb_2/ftv92qc.htm
Modem on hold (MOH) was designed to resolve a problem that resulted in a large number of trouble calls to the ISP. Often users with a single line do not disable call waiting when they are online, and a call waiting signal looks to a modem like a line disconnect. Depending on how the modem is configured, this can often result in the modem hanging up. While some users may prefer this behavior, a hung-up modem is an inconvenience to other users.
MOH allows a dial-in user with a single line to suspend a modem session to answer an incoming voice call—or place an outgoing call while engaged in a modem session. After the session is suspended, the ISP modem listens to the original connection and waits for the user's modem to resume the connection. The interval during which the server remains alert to the reconnection is called the "call-waiting survival," and is configurable.
|
Caution Call-waiting tones vary widely from country to country. Configuring the MOH feature in a specific country for which the client modem does not recognize the tones can cause the modem to disconnect. |
For more information on this feature, as well as how to implement it, refer to the feature module V.92 Modem on Hold for the Cisco AS5350 and Cisco AS5400 Universal Gateways at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xb/122xb_2/ftv92moh.htm
In Cisco AS5400 and AS5350 UGs, echo cancellation is enabled by default, with tail-delay coverage set at 8 milliseconds. However, if you are using the Cisco echo canceller in the UGs, it is important to determine the maximum echo-path tail delay and IP network delay that may exist in your network. In addition, other services (such as wireless) may add additional echo-path delays. If echo delay is longer than the provisioned tail length, echo cancellation will not work.
In general, you should enable echo cancellation in networks where predicted echo-path delays exceed 32 milliseconds. Also, if you plan to use external echo cancellation, Cisco recommends that you disable the echo cancellers in the UGs. This will save memory and other platform resources.
|
Note Information about echo cancellation terminology and guidelines for network design can be found in ITU
recommendation G.168, available at http://www.itu.org. See also
Echo Analysis for Voice over IP at the following URL: http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/voipsol/ea_isd.htm |
The following example echo-cancellation configurations are presented:
The following commands illustrate how to disable echo cancellation on a voice port.
|
Caution Because voice ports are created automatically when an ISDN D-channel or CAS signaling is assigned to a controller, you must determine which voice ports require echo cancellation and which do not. In this SS7 example there is only one voice port, as SS7 requires the instantiation of only one voice port (1/0:1:D), to support the serial D-channel. |
If you decide to use echo cancellation in your UGs, you may have different needs regarding the tail-delay coverage setting. The following commands illustrate how to change the tail-delay coverage setting.
|
Note This sets the echo canceller to cover a tail delay of 128 milliseconds. |
Here are some typical echo-cancellation settings, most of which are defaults. In this SS7 case, the settings are mapped from this port to a port related to a path in the echo canceller.
Applications that are not compliant with T.38 Fax Relay, such as Microsoft NetMeeting, may not work properly unless certain configurations are applied to the dial peer as well as to the gatekeeper. Adjustments need to be made to the NetMeeting application, the UG, and the GK, as discussed below. There are three basic components to configuring Microsoft NetMeeting with T.38 Fax Relay:
Step 2 Select Use a Gatekeeper to Place Calls.
This will allow you to enter a phone number in the Call menu.
On the gateway, if you are using the global command to configure T.38 Fax Relay service (see Enabling T.38 Fax Relay Service), rather than configuring individual dial peers, you must do the following on the incoming VoIP dial peer that serves PC-to-phone calls.
Step 2 Enter the command codec G711ulaw.
If these are not configured, calls will have only a one-way audio path. Note the following.
In addition, NetMeeting currently causes a digital data bearer capability to be built into the outgoing SETUP message on egress PC-to-phone speech calls from the Cisco gateway. Below is an example of what can be done to remedy this.
Step 3 Configure bearer-cap to 3100 Hz, as shown.
Gatekeeper provisioning is discussed in greater detail in "Configuring Optional Network Components." However, for convenience, the following information is presented here.
In order for the gatekeeper to allow calls from a NetMeeting PC, you must configure a series of no use-proxy statements. Configure no-use-proxy as in the following example (zone GK names will vary):
Posted: Wed Jan 22 02:10:15 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.