ISDN Voice Configuration Guide, Cisco IOS Release 15M&T
PRI Backhaul and IUA Support Using SCTP
Downloads: This chapterpdf (PDF - 390.0KB) The complete bookPDF (PDF - 1.91MB) | The complete bookePub (ePub - 1.38MB) | Feedback

PRI Backhaul and IUA Support Using SCTP

PRI Backhaul and IUA Support Using SCTP

Last Updated: December 4, 2012

This chapter describes how to implement Stream Control Transmission Protocol (SCTP) features. SCTP is not explicitly configured on routers, but it underlies several Cisco applications. This chapter describes how to configure several features that use SCTP and how to troubleshoot SCTP problems.

SCTP is used with the following Cisco IOS software features:

  • PRI Backhaul Using SCTP and the ISDN Q.921 User Adaptation Layer
  • Support for IUA with SCTP for Cisco Access Servers

Feature History for PRI Backhaul Using SCTP and the ISDN Q.921 User Adaptation Layer

Release

Modification

12.1(1)T

This feature was introduced on the Cisco AS5300.

12.2(4)T

This feature was introduced on the Cisco 2600 series, Cisco 3600 series, and Cisco MC3810 series.

12.2(2)XB1

This feature was implemented on the Cisco AS5850.

Feature History for Support for IUA with SCTP for Cisco Access Servers

Release

Modification

12.2(15)T

This feature was introduced.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Prerequisites for Implementing SCTP Features

  • Perform the prerequisites that are listed in the "Prerequisites for Configuring an ISDN Voice Interface" section.

PRI Backhaul Using SCTP and the ISDN Q.921 User Adaptation Layer Feature

  • Configure ISDN to backhaul Q.921 signaling to the media gateway controller
  • For Cisco AS5850, install or implement the following:
    • MGCP 1.0
    • IUA 0.4
    • ISDN network-side support to terminate multiple voice PRIs

Restrictions for Implementing SCTP Features

Restrictions are described in the "Restrictions for Configuring ISDN Voice Interfaces" section. In addition, the following apply.

PRI Backhaul Using SCTP and the ISDN Q.921 User Adaptation Layer Feature

  • Backhaul: Does not support backhauling for Basic Rate Interface (BRI).
  • Capacity: Supports only two application-server processes (ASPs) per application server. Supports only three explicit IP addresses per SCTP association endpoint.
  • IUA messages: Does not support new-traffic failover.

Note


The IUA specification describes an optional feature known as New Traffic Failover. In this process, all messages for calls pending completion during failover are sent to the inactive media-gateway controller, and messages for new calls are sent to the newly active controller. These IUA messages for new calls are not supported.
  • Load balancing: Does not support load balancing between ASPs on a per-call basis.
  • Platforms: Is not supported on the Cisco 2600XM series, Cisco 2691, Cisco 2800 series, Cisco 3700 series, and Cisco 3800 series.
  • Signaling: Supports Facility Associated Signaling (FAS) and Non-Facility Associated Signaling (NFAS) PRI D-channel signaling only; does not support any other signaling protocols, including NFAS with backup D-channel signaling.

Support for IUA with SCTP for Cisco Access Servers Feature

  • Backhaul: Does not support Q.931 PRI backhaul on the Cisco PGW 2200.
  • Platforms: Is not supported on the Cisco 2600XM series or Cisco 2691.
  • Transport: Does not support concurrent Redundant Link Manager (RLM) and SCTP transport on the access-server gateway. You can configure one or the other but not both at the same time.

Note


For more information about the Cisco PGW 2200, see Support for IUA with SCTP.

Information About SCTP and SCTP Features

The following is an example of an application-server configuration on a gateway:

AS as1 10.4.8.69 10.4.9.69 2577

Application server as1 is configured to use two local IP addresses and port 2577. IP address values that are set apply to all IP addresses of the application-server process.

An application-server process can be viewed as a local representation of an SCTP association since it specifies a remote endpoint that communicates with an application-server local endpoint. An application-server process is defined for a given application server. For example, the following configuration defines remote signaling controller asp1 at two IP addresses for application server as1. The remote SCTP port number is 2577:

AS as1 10.4.8.69 10.4.9.69 2477
ASP asp1 AS as1 10.4.8.68 10.4.9.68 2577

Multiple application-server processes can be defined for a single application server for the purpose of redundancy, but only one process can be active. The other process is inactive and becomes active at failover.

In the Cisco media-gateway-controller solution, a signaling controller is always the client that initiates association with a gateway. During initiation, you can request outbound and inbound stream numbers, but the gateway allows only a number that is at least one digit higher than the number of interfaces (T1/E1) allowed for the platform.

The number of streams to assign to a given association is implementation dependent. During initialization of the IUA association, you need to specify the total number of streams that can be used. Each D channel is associated with a specific stream within the association. With multiple-trunk-group support, every interface can potentially be a separate D channel.

At startup, the IUA code checks for all the possible T1, E1, or T3 interfaces and sets the total number of inbound and outbound streams supported accordingly. In most cases, there is only a need for one association between the GW and the media gateway controller. For the rare case that you are configuring multiple application server associations to various media gateway controllers, the overhead from the unused streams would have minimal impact. The NFAS D channels are configured for one or more interfaces, where each interface is assigned a unique stream ID.

The total number of streams for the association needs to include an additional stream for the SCTP management messages. So during startup the IUA code adds one to the total number of interfaces (streams) found.

You can manually configure the number of streams per association. In the backhaul scenario, if the number of D-channel links is limited to one, allowing the number of streams to be configurable avoids the unnecessary allocation of streams in an association that will never be used. For multiple associations between a GW and multiple media gateway controllers, the configuration utility is useful in providing only the necessary number of streams per association. Overhead from the streams allocated but not used in the association is negligible.

If you manually configure the number of streams through the CLI, the IUA code cannot distinguish between a startup event, which automatically sets the streams to the number of interfaces, or if the value is set manually during runtime. If you configure the number of SCTP streams manually, you must add one plus the number of interfaces using the sctp-streams keyword. Otherwise, IUA needs always to add one for the management stream, and the total number of streams increments by one after every reload.

When you set the SCTP stream with the command-line interface, you cannot change the inbound and outbound stream support once the association is established with SCTP. The value takes effect when you first remove the IUA application server configuration and then configure it back as the same application server or a new one. The other option is to reload the router.


Note


General information about ISDN voice interfaces is presented in the "Information About ISDN Voice Interfaces" section on page 4 .

SCTP Topology

SCTP is a reliable datagram-oriented IP transport protocol specified by RFC 2960. It provides the layer between an SCTP user application and an unreliable end-to-end datagram service such as IP. The basic service offered by SCTP is the reliable transfer of user datagrams between peer SCTP users, within the context of an association between two SCTP hosts. SCTP is connection-oriented, but SCTP association is a broader concept than, for example, TCP connection.

SCTP provides the means for each SCTP endpoint to provide its peer with a list of transport addresses during association startup (address and UDP port combinations, for example) through which that endpoint can be reached and from which messages originate. The association spans transfer over all of the possible source and destination combinations that might be generated from the two endpoint lists (also known as multihoming).

SCTP provides the following services and features:

  • Acknowledged reliable nonduplicated transfer of user data
  • Application-level segmentation to conform to the maximum transmission unit (MTU) size
  • Sequenced delivery of user datagrams within multiple streams
  • Optional multiplexing of user datagrams into SCTP datagrams
  • Enhanced reliability through support of multihoming at either end or both ends of the association
  • Congestion avoidance and resistance to flooding and masquerade attacks
  • Interoperability with third-party call agents

SCTP allows you to terminate multiple switches and trunk groups on a gateway to add scalability. Adding trunk groups does not require more memory or processing resources because SCTP supports multiple streams in a single SCTP association. SCTP is a reliable transport protocol for message-oriented communications; SCTP is specifically designed to support PSTN signaling messages over IP networks.

SCTP allows you to configure at least one trunk group per T1 or E1 interface available on a given platform. A gateway platform with four T1 or E1 interfaces, for example, can control four unique trunk groups per device. Certain platforms, such as the Cisco AS5800 and Cisco AS5850, can deliver the individual T1 or E1 trunk groups over a high-speed interface, such as T3, which operates at 45 Mbps.

The table below shows the number of trunk groups supported per gateway platform.

Table 1 SS7 Interconnect for Voice-Gateway Trunk Groups per Gateway

Platform

Supported Trunk Groups

Comments

Cisco AS5300

4

Verify both T1 and E1 cards.

Cisco AS5350

8

Verify both T1 and E1 cards.

Verify with Integrated SLT option.

Note    For more information, see Integrated Signaling Link Terminal , Cisco IOS Release 12.2(11)T.

Cisco AS5350 CT3

28

Verify CT3 DS-3 card.

Verify with Integrated SLT option.

Cisco AS5400

16

Verify both T1 and E1 cards.

Verify with Integrated SLT option.

Cisco AS5400 CT3

28

Verify CT3 DS-3 card.

Verify with Integrated SLT option.

Cisco AS5850

112

Verify E1 cards and CT3 DS-3 cards.

Note    T1 ports and the 112 supported trunk groups are available only with CT3 cards.

In a typical network topology, only one SCTP association is configured between a signaling controller and a gateway. Multiple IP addresses on either side can be designated to the same association to achieve link redundancy. On a gateway, signaling messages for all trunk groups are carried over on the same SCTP association to the same signaling controller. Trunk groups on a gateway can also be controlled through different signaling controllers. In such cases, you can configure multiple associations on a gateway and direct them to different signaling controllers.

IUA

IUA is the adaptation layer that makes SCTP services available to Q.921 services users, such as Q.931, Q Signaling (QSIG), and National ISDN-2 with Cisco extensions (Cisco NI2+). IUA supports the standard interlayer primitives provided by Q.921. As a result, an upper-layer protocol (ULP) that typically used Q.921 services can easily migrate to IUA.

IUA service points are represented to the upper-layer protocol as application servers. Each application server is bound to an SCTP local endpoint managed by an SCTP instance. A remote signaling controller is known as an ASP. An ASP is connected to the local endpoint through a single SCTP association.

The IUA module creates associations between the signaling gateway and the MGC based on configuration requests. It also manages multiple ASPs as defined in the IETF IUA specification. IUA performs the following functions:

  • Requests SCTP associations based on configuration information.
  • Manages the destination address list and requests a new primary destination in the event of a failure.
  • Manages the ASP state machine for each association.
  • Manages the application-server state machine across all ASPs associated with a single application.
  • Provides service for multiple applications simultaneously to handle different Layer 3 signaling protocols (Q.931 and Q.SIG, for example), or to communicate with different sets of call agents.

The figure below shows IUA with SCTP transport stack.

Figure 1 IUA with SCTP Transport Stack


To use IUA services, you must make the application server and ASP available and bind a trunk group to an application server for its Layer 2 server. For configuration information, see the Configuring IUA.

Multiple NFAS Groups

On a gateway, trunk groups are defined as Non-Facility Associated Signaling (NFAS) groups. An NFAS group is a group of ISDN PRI trunks with a single dedicated D channel. In a voice-gateway solution, the D channel in a trunk group is symbolic because SS7 is used as the signaling mechanism. The D channels defined for each NFAS group are actually DS0 bearer channels for voice or modem calls. Therefore, each NFAS has a corresponding D channel for which it is allocated.

A symbolic D-channel interface is dedicated to a trunk group. Each D-channel interface is bound to an application server and a dedicated stream is associated with this interface. Thus, the NFAS group identification can be recovered on each side of the SCTP association through this two-stage mapping as long as both sides share the same configuration information. Multiplexing of multiple trunk groups through a single association is accomplished this way, for example. If all interfaces on a gateway are controlled through a single SC, all interfaces are bound to the same application server.

The SCTP stream is a logical identification of the grouping of messages and consumes little additional memory and processing power. Each association can support as many as 65,355 streams.

The figure below shows the mapping between the trunk group, D-channel interface, and SCTP stream.

Figure 2 Mapping Between Trunk Group, Interface, and Stream


The figure below shows the NFAS group and SCTP association.

Figure 3 NFAS Group and SCTP Association


The IUA transport protocol using SCTP is supported on the Cisco PGW 2200; the Cisco PGW 2200 now uses IUA to communicate with Cisco access servers.

IUA with SCTP on the Cisco PGW 2200 provides the following services:

  • Eliminates the scaling limitations in previous releases of Cisco MGC software for the number of NFAS-groups allowed per RLM.
  • Supports upgrading from RLM-based communication to IUA-based communication without losing stable active calls.
  • RLM-based communication is still supported. However, since this is a new functionality, the backward compatibility of the SCTP-based transports is not applicable.
  • IUA interface can be used with Cisco access servers that support NAS and Digital Private Network Signaling System (DPNSS) signaling.
  • Introduces IUA and SCTP operational measurements.

Note


For more information about IUA and SCTP on the Cisco PGW 2200, see Support for IUA with SCTP .

Features That Use SCTP

The following features use SCTP:

PRI Backhaul Using SCTP and the ISDN Q.921 User Adaptation Layer

This feature (sometimes called PRI Q.921 Signaling Backhaul) provides standards-based ISDN signaling backhaul capability on Cisco IOS gateways. It fills the need for PRI Q.921 signaling backhaul that works with third-party call agents or media-gateway controllers (MGCs) where call processing for voice calls is carried out by call-control servers, and packet-network connections are made using protocols such as Media Gateway Control Protocol (MGCP) and Simple Gateway Control Protocol (SGCP). It enables solutions such as Integrated Access, IP PBX, and Telecommuter on the Cisco 3600 series, Cisco AS5300, and Cisco AS5850. It provides a configuration interface for Cisco IOS software implementation and implements protocol message flows for SCTP and IUA.

This feature provides the following:

  • PRI backhaul--Specific implementation for backhauling PRI

Note


For more information about PRI backhaul using SCTP, see PRI Backhaul Using the Stream Control Transmission Protocol and the ISDN Q.921 User Adaptation Layer.
  • SCTP--New general-transport protocol that can be used for backhauling signaling messages
  • IDSN User Adaptation Layer (IUA)--Mechanism for backhauling any Layer 3 protocol that normally uses Q.921

This feature supports interoperability with third-party call agents. It also supports the following solutions that require signaling backhaul:

  • IP PBX
  • IP Centrex
  • Enterprise toll bypass
  • IXC/tandem bypass

Signaling backhaul facilitates the handling of voice traffic coming from the signaling endpoints that communicate using facility-associated signaling. Facility-associated signaling requires the signaling channel (channel that carries call-signaling information) to share a digital facility with the bearer channels. ISDN PRI is one example of facility-associated signaling. ISDN signaling backhaul is required in the MGCP-based call-control architecture to enable end-to-end voice solutions.

This feature implements the IETF standards-based signaling backhaul protocols. This standards-based signaling transport support enables any third-party call agent that supports the standards to work with Cisco gateways. ISDN signaling backhaul is required in the MGCP-based call-control architecture to enable end-to-end voice solutions.

This feature migrates the proprietary PRI backhaul infrastructure to open standards. Backhaul is carried out using industry-standard SCTPs and ISDN IUA protocols as defined by the SIGTRAN working group of the IETF. It supports backhauling for ISDN-based signaling protocols only.

The figure below shows an example of PRI signaling backhaul. The MGC provides call processing and gateway control.

Figure 4 PRI Signaling Backhaul


Ordinarily, signaling backhaul occurs at a common boundary for all protocols. For ISDN, signaling backhaul occurs at the Layer 2 (Q.921) and Layer 3 (Q.931) boundaries. The lower layers of the protocol (Q.921) are terminated and processed on the gateway, while the upper layers (Q.931) are backhauled to the MGC using SCTP. Signaling backhaul provides the advantage of distributed protocol processing. This permits greater expandability and scalability while offloading lower-layer protocol processing from the MGC.

Signaling transport between entities is applied to ensure that signaling information is transported with the required functionality and performance. The signaling gateway or MGC receives both ISDN signaling and bearer-channel data. ISDN signaling is backhauled up to an MGC or call agent using the SIG protocol stack. You can configure each signaling gateway to use up to three MGCs within an application server for redundancy. Multiple application servers can also be supported on a signaling gateway. MGCP is then used to control the bearer channels.

The figure below shows the functional model for PRI signaling transport.

Figure 5 Signaling Transport Model


SCTP is a peer-to-peer protocol; IUA is a client-server protocol. The figure below shows the protocol flow from an ISDN endpoint, through the signaling gateway, and then to a call agent or media gateway controller.

Figure 6 Protocol Flow


PRI Backhaul Using the Stream Control Transmission Protocol and the ISDN Q.921 User Adaptation Layer on the Cisco 3660 supports the following on a Cisco 3660:

  • 20 calls per hour per DS-0 bearer circuit (3-minute average call duration)
  • 460 calls per hour per PRI circuit (23 bearer channels): 20 x 23 = 460
  • 5520 calls per hour per Cisco 3660 (12 PRI trunks): 460 x 12 = 5520
  • 1.5333 calls per Cisco 3660 per second. 5520 divided by (60*60) = 1.5333
  • 7 signaling messages per call (both setup and tear down)
  • 10.8 signaling messages per second per Cisco 3660: 7 x 1.5333 = 10.8

Support for IUA with SCTP for Cisco Access Servers

This feature supports IUA with SCTP for the Cisco AS5x00, Cisco 2420, Cisco 2600 series, Cisco 3600 series, and Cisco 3700 series. It is to be used as an alternative to the existing IP-based User Datagram Protocol (UDP)-to-Reliable Link Manager (RLM) transport between the Cisco PGW 2200 and Cisco gateways.

IUA with SCTP acts as the call signaling IP transport mechanism in a voice-gateway solution. These combined protocols are also used for Signaling System 7 (SS7) Interconnect solutions, which allow required flexibility in connecting Intermachine trunks from more than one PSTN switch (multiple trunk groups) to the Cisco gateways. This feature also allows you to interconnect with multiple carriers on high-capacity Cisco AS5x00 gateways for load balancing and redundancy.

IUA and SCTP protocols provide the following services:

  • Trunk groups are defined on a T1/E1 interface basis.
  • All DS0 bearer channels in a specific T1/E1 interface are included in the same trunk group and cannot be split into different trunk groups.
  • Multiple T1/E1 interfaces on the same gateway can be provisioned in a single trunk group or split into multiple trunk groups. The maximum number of trunk groups that a platform can support is equal to the maximum number of T1/E1 interfaces that the platform can configure.

This feature supports SCTP, multiple non-facility associated signaling, and IUA.

How to Configure SCTP Features

Configuring PRI Backhaul Using the SCTP and the ISDN Q.921 User Adaptation Layer

To configure the PRI Backhaul Using SCTP and the ISDN Q.921 User Adaptation Layer feature, perform the following tasks:


Caution


When the Fast Ethernet interface is configured for auto negotiation, it can take up to two seconds to initialize. Two examples of the interface initializing is when the no shutdown command is entered, or if the cable is removed and then plugged back in. To avoid any problems, the Fast Ethernet interface should not be configured for auto negotiation. The duplex and speed parameters should be set according to the requirements of the network, and should not be set to auto.


Configuring IUA

To configure IUA, perform the following steps.


Note


The steps below direct you to configure an application server and the ASP first to allow an NI2+ to be bound to the IUA transport layer protocol. The application server is a logical representation of the SCTP local endpoint. The local endpoint can have more than one IP address but must use the same port number.
Before You Begin
  • Ensure that Cisco IOS Release 12.2(15)T or later is installed and running on your system.
  • Configure ISDN to backhaul Q.921 signaling to the third-party call agent (MGC).
  • Ensure that your Cisco AS5850 has the following:
    • MGCP 1.0
    • IUA 0.4
    • ISDN network side support to terminate multiple voice PRIs

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    iua

4.    as as-name {local-ip1 [local-ip2]} [local-sctp-port]

5.    asp asp-name as as-name remote-ip1 remote-ip2 ]}[remote-sctp-port

6.    asp asp-name sctp-keepalives remote-ip keepalive-value

7.    asp asp-name ip-precedence remote-ip ip-precedence-level

8.    as as-name fail-over-timer time

9.    exit


DETAILED STEPS
  Command or Action Purpose
Step 1
enable


Example:

Router> enable

 

Enters privileged EXEC mode. Enter your password if prompted.

 
Step 2
configure terminal


Example:

Router# configure terminal

 

Enters global configuration mode.

 
Step 3
iua


Example:

Router(config)# iua

 

Enters IUA configuration mode and specifies backhaul using SCTP.

 
Step 4
as as-name {local-ip1 [local-ip2]} [local-sctp-port]


Example:

Router(config-iua)# as as5400-3 10.1.2.34 10.1.2.35 2577

 

Defines an application server on a gateway.

You can specify up to three local IP addresses (note that SCTP has built-in support for multihomed machines).

 
Step 5
asp asp-name as as-name remote-ip1 remote-ip2 ]}[remote-sctp-port


Example:

Router(config-iua)# asp asp1 as as5400-3 10.4.8.68 10.4.9.68 2577

 

Defines an ASP. Use this command to establish SCTP associations.

Note    A maximum of three ASPs can be configured per application server.
 
Step 6
asp asp-name sctp-keepalives remote-ip keepalive-value


Example:

Router(config-iua)# asp asp1 sctp-keepalives 10.1.2.234 600

 

(Optional) Sets SCTP keepalive behavior, in ms, for the specified ASP and IP address. Range: 1000 to 60000. Default: 500.

Note    Find the current value by examining the show ip sctp association parameters command output under heartbeats.
 
Step 7
asp asp-name ip-precedence remote-ip ip-precedence-level


Example:

Router(config-iua)# asp asp1 ip-precedence 10.1.2.345 7

 

(Optional) Sets the IP precedence level for protocol data units (PDUs) for the specified IP address.

Range for a given address is 0 to 7. Default for normal IP precedence handling is 0.

 
Step 8
as as-name fail-over-timer time


Example:

Router(config-iua)# as as5400-3 fail-over-timer 10000

 

(Optional) Sets the failover timer value, in ms. IUA waits for this amount of time for one ASP to take over from another ASP during failover.

Note    Find the current failover timer value by examining the show iua as all command output.
 
Step 9
exit


Example:

Router(config-iua)# exit

 

Exits the current mode.

 

Configuring ISDN Signaling (PRI) Backhaul

To configure ISDN signaling (PRI) backhaul, perform the following steps.

Before You Begin

Ensure that Cisco IOS Release 12.2(4)T or later is installed and running on your system.


SUMMARY STEPS

1.    enable

2.    configure terminal

3.    controller t1 0

4.    pri-group timeslots timeslot-range service mgcp

5.    exit

6.    interface serial slot/port : timeslot

7.    isdn switch-type switch-type

8.    isdn bind-l3 iua-backhaul as as-name

9.    Repeat the preceding steps for each T1 interface that uses backhaul.

10.    exit


DETAILED STEPS
  Command or Action Purpose
Step 1
enable


Example:

Router> enable

 

Enters privileged EXEC mode. Enter your password if prompted.

 
Step 2
configure terminal


Example:

Router# configure terminal

 

Enters global configuration mode.

 
Step 3
controller t1 0


Example:

Router(config)# controller t1 0

 

Enters controller configuration mode for slot 0.

 
Step 4
pri-group timeslots timeslot-range service mgcp


Example:

Router(config-control)# pri-group timeslots 1-24 service mgcp

 

Sets the control protocol used for backhaul to MGCP. You cannot share controller timeslots between backhaul and other Layer 3 protocols.

 
Step 5
exit


Example:

Router(config-control)# exit

 

Exits the current mode.

 
Step 6
interface serial slot/port : timeslot


Example:

Router(config)# interface serial 0:23

 

Enters serial-interface configuration mode for the specified controller and timeslot.

The D-channel timeslot is (channelized T1): 23 or (channelized E1):15.

 
Step 7
isdn switch-type switch-type


Example:

Router(config-if)# isdn switch-type primary-4ess

 

Specifies the ISDN switch type (can be done in either global configuration mode or interface mode).

 
Step 8
isdn bind-l3 iua-backhaul as as-name


Example:

Router(config-if)# isdn bind-l3 iua-backhaul as server1

 

Configures ISDN to backhaul Q.931 to the media gateway controller.

 
Step 9
Repeat the preceding steps for each T1 interface that uses backhaul. 

--

 
Step 10
exit


Example:

Router(config-if)# exit

 

Exits the current mode.

 

Verifying PRI Backhaul

To verify PRI backhaul, perform the following steps (listed alphabetically).

SUMMARY STEPS

1.    show iua as {all name as-name}

2.    show iua asp {all name asp-name}

3.    show isdn status

4.    show running-config


DETAILED STEPS
Step 1   show iua as {all name as-name}

Use this command to display the current state of the active application server and show the PRI interfaces configured on the application server.

The following output shows that the current state of the application server (as1) is active and that there are four PRI interfaces configured to use this application server:



Example:
Router# show iua as all
Name of AS :as1
        Total num of ASPs configured :2
        Current state :  ACTIVE
        Active ASP :asp1
        Number of ASPs up :1
        Fail-Over time : 4000 milli seconds
        Local address list : 10.21.0.2
        Local port  9900
        Interface IDs registered with this AS
                 Interface ID            stream #
                 256 (serial1/0:23)      1
                 257 (serial1/1:23)      2
                 512 (serial2/0:23)      3
                 513 (serial2/1:23)      4
Step 2   show iua asp {all name asp-name}

Use this command to display the current state of the active ASP and show information about the SCTP association being used by this ASP.

The following output shows that the current state of the ASP (asp1) is active. It also shows information about the SCTP association being used by this ASP.



Example:
Router# show iua asp all
Name of ASP :asp1
Current State of ASP:ASP-Active
Current state of underlying SCTP Association IUA_ASSOC_ESTAB , assoc  id
0
SCTP Association information :
         Local Receive window :9000
         Remote Receive window :9000
         Primary Dest address requested by IUA 10.23.0.16
         Effective Primary Dest address 10.23.0.16
Remote  address list : 10.23.0.16
Remote Port :9900
Statistics :
        Invalid SCTP signals Total :0  Since last  0
        SCTP Send failures :0
Name of ASP :asp2
Current State of ASP:ASP-Down
Current state of underlying SCTP Association IUA_ASSOC_INIT , assoc  id
0
Remote  address list : 10.23.0.16
Remote Port :9911
Statistics :
        Invalid SCTP signals Total :0  Since last  0
        SCTP Send failures :0
Step 3   show isdn status

Use this command to display the status of all ISDN interfaces, including active layers, timer information, and switch-type settings.

Use it also to display the status of ISDN backhaul. If connection to the media gateway controller is lost, the router shuts down Layer 2 so that it cannot receive calls. When the connection is back up, you can use this command to verify that Layer 2 was also brought back up correctly.

The following sample output shows Layer 2 status, as defined by the MULTIPLE_FRAME_ESTABLISHED message, to be up. The L3 protocol and state status are highlighted:



Example:
Router# show isdn status
Global ISDN Switchtype = primary-5ess
ISDN Serial1/0:23 interface
        dsl 0, interface ISDN Switchtype = primary-5ess
        L2 Protocol = Q.921  L3 Protocol(s) = IUA BACKHAUL
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Active dsl 0 CCBs = 0
    The Free Channel Mask: 0x807FFFFF
ISDN Serial1/1:23 interface
        dsl 1, interface ISDN Switchtype = primary-5ess
        L2 Protocol = Q.921  L3 Protocol(s) = IUA BACKHAUL
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Active dsl 1 CCBs = 0
    The Free Channel Mask: 0x807FFFFF
ISDN Serial2/0:23 interface
        dsl 2, interface ISDN Switchtype = primary-5ess
        L2 Protocol = Q.921  L3 Protocol(s) = IUA BACKHAUL
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Active dsl 2 CCBs = 0
    The Free Channel Mask: 0x807FFFFF
ISDN Serial2/1:23 interface
        dsl 3, interface ISDN Switchtype = primary-5ess
L2 Protocol = Q.921  L3 Protocol(s) = IUA BACKHAUL
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Active dsl 3 CCBs = 0
    The Free Channel Mask: 0x807FFFFF
    Total Allocated ISDN CCBs = 0
Step 4   show running-config

Use this command to display basic router configuration.


What to Do Next


Note


For troubleshooting tips, see the Troubleshooting Tips.

Configuring Support for IUA with SCTP for Cisco Access Servers Feature

This section contains the following procedures:

Configuring IUA for Cisco Access Servers

To configure IUA for Cisco access servers, follow the steps for configuring IUA for PRI Q.921 backhaul, as described in the Configuring IUA.

Configuring the SCTP T1 Initiation Timer

To configure the SCTP T1 initiation timer, perform the following steps.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    iua

4.    as as-name {localip1 [localip2]} [local-sctp-port]

5.    as as-name fail-over-timer time

6.    as as-name sctp-startup-rtx number

7.    as as-name sctp-streams number

8.    as as-name sctp-t1init number

9.    asp asp-name as as-name ip-address

10.    asp asp-name ip-precedence remote-ip-address number

11.    asp asp-name as as-name remote-ip remote-ip2 ]}[remote-sctp-port

12.    asp asp-name sctp-keepalive remote-ip-address number

13.    asp asp-name sctp-max-association ip-address number

14.    asp asp-name sctp-path-retransmission ip-address number

15.    asp asp-name sctp-t3-timeout ip-address number

16.    exit


DETAILED STEPS
  Command or Action Purpose
Step 1
enable


Example:

Router> enable

 

Enters privileged EXEC mode. Enter your password if prompted.

 
Step 2
configure terminal


Example:

Router# configure terminal

 

Enters global configuration mode.

 
Step 3
iua


Example:

Router(config)# iua

 

Enters IUA configuration mode and specifies backhaul using SCTP.

 
Step 4
as as-name {localip1 [localip2]} [local-sctp-port]


Example:

Router(config-iua)# as as5400-3 10.1.2.34 10.1.2.35 2577

 

Defines an application server on a gateway.

 
Step 5
as as-name fail-over-timer time


Example:

Router(config-iua)# as as5400-3 fail-over 10000

 

(Optional) Sets the failover timer value, in ms.

Note    Find the failover timer value by examining the show iua as all command output.
 
Step 6
as as-name sctp-startup-rtx number


Example:

Router(config-iua)# as as5400-3 sctp-startup-rtx 8

 

Configures the SCTP startup retransmission interval.

 
Step 7
as as-name sctp-streams number


Example:

Router(config-iua)# as as5400-3 sctp-streams 56

 

Configures the number of SCTP streams for this application server.

Although the gateway help function displays a range of 2 to 57, the upper end of the range (also the default) is determined by your hardware, and is equal to the number of controllers on that gateway and NAS one plus. If you enter a number higher than that, the system assumes the default.

Note    If you want to set this value to something other than the default, add one to the number of D channel interfaces that you want to use concurrently.
 
Step 8
as as-name sctp-t1init number


Example:

Router(config-iua)# as as1 sctp-t1init 1000

 

Sets the SCTP T1 initiation timer, in ms.

 
Step 9
asp asp-name as as-name ip-address


Example:

Router(config-iua)# asp asp1 as as1 10.4.8.68 10.4.9.68

 

Creates an ASP and specifies to which application server it belongs.

 
Step 10
asp asp-name ip-precedence remote-ip-address number


Example:

Router(config-iua)# asp asp1 ip-precedence 10.1.2.345 7

 

Specifies the IP precedence level for protocol data units (PDUs) for a given IP address.

Default for normal IP precedence handling is 0.

 
Step 11
asp asp-name as as-name remote-ip remote-ip2 ]}[remote-sctp-port


Example:

Router(config-iua)# asp asp1 as as5400-3 10.4.8.68 10.4.9.68 2577

 

Defines an ASP. Use this command to establish SCTP associations.

 
Step 12
asp asp-name sctp-keepalive remote-ip-address number


Example:

Router(config-iua)# asp asp1 sctp-keepalive 10.1.2.234 1000

 

(Optional) Specifies the IP address to enable and disable keepalives and control SCTP keepalives on destination IP addresses.

 
Step 13
asp asp-name sctp-max-association ip-address number


Example:

Router(config-iua)# asp asp1 sctp-max-association 10.10.10.10 20

 

Sets the maximum association retransmissions for this ASP.

 
Step 14
asp asp-name sctp-path-retransmission ip-address number


Example:

Router(config-iua)# asp asp1 sctp-path-retransmission 10.10.10.10 2

 

Sets the SCTP path retransmissions for this ASP.

 
Step 15
asp asp-name sctp-t3-timeout ip-address number


Example:

Router(config-iua)# asp asp1 sctp-t3-timeout 10.10.10.10 60000

 

Enters IUA-SCTP configuration mode and sets the SCTP T3 retransmission timeout for this ASP.

 
Step 16
exit


Example:

Router(config-iua-sctp)# exit

 

Exits the current mode.

 

Creating NFAS Groups and Bind Them to the Application Server

To create NFAS groups and bind them to the application server, perform the following steps.


Note


This procedure configures two T1 interfaces into two NFAS groups or trunk groups that are served by the same application server with two different SCTP streams (ASPs). It allows you to configure the NFAS primary D channel and bind the channel to an IUA application server.
  • The steps for configuring the T1/E1 interface are the same as the steps using RLM, but multiple NFAS groups can now be defined to support multiple trunk groups. All interfaces in an NFAS are treated as one trunk group.
SUMMARY STEPS

1.    enable

2.    configure terminal

3.    controller t1 1/0/0

4.    pri-group timeslots timeslot-range nfas-d primary nfas-int number nfas-group number iua as-name

5.    exit

6.    controller t1 1/0/1

7.    pri-group timeslots timeslot-range nfas-d primary nfas-int number nfas-group number iua as-name

8.    exit


DETAILED STEPS
  Command or Action Purpose
Step 1
enable


Example:

Router> enable

 

Enters privileged EXEC mode. Enter your password if prompted.

 
Step 2
configure terminal


Example:

Router# configure terminal

 

Enters global configuration mode.

 
Step 3
controller t1 1/0/0


Example:

Router(config)# controller t1 1/0/0

 

Enters controller configuration mode on the first T1 controller.

 
Step 4
pri-group timeslots timeslot-range nfas-d primary nfas-int number nfas-group number iua as-name


Example:

Router(config-controller)# pri-group timeslots 1-23 nfas-d primary nfas-int 0 nfas-group 1 iua as-1

 

Configures the NFAS primary D channel on one channelized T1 controller and binds the D channel to an IUA application server. You can choose any timeslot other than 24 to be the virtual container for the D channel parameters for ISDN. Keywords and arguments are as follows:

  • nfas-group number --NFAS group
  • iua as-name --Must match the name of an application server that was set up during IUA configuration.
Note    For more information, see the Configuring IUA.
 
Step 5
exit


Example:

Router(config-controller)# exit

 

Exits the current mode on the first controller.

 
Step 6
controller t1 1/0/1


Example:

Router# controller t1 1/0/1

 

Enters controller configuration mode on the second T1 controller.

 
Step 7
pri-group timeslots timeslot-range nfas-d primary nfas-int number nfas-group number iua as-name


Example:

Router(config-controller)# pri-group timeslots 1-23 nfas-d primary nfas-int 0 nfas-group 1 iua as-1

 

Configures the NFAS primary D channel on another channelized T1 controller and binds the D channel to an IUA application server. Keywords and arguments are as above. The argument as-name must match the name of an application server that was set up during IUA configuration.

 
Step 8
exit


Example:

Router(config-if)# exit

 

Exits the current mode.

 

Migrating from RLM to IUA with SCTP

To migrate from RLM to IUA with SCTP, perform the following steps.

The following changes have been made between RLM and IUA with SCTP:

  • Application server and ASP configuration lines must precede the controller configuration lines in the configuration text file.
  • RLM group configuration must be removed from the D channel configuration.
  • For the D channel, the interface serial commands are now replaced by interface D channel commands.
  • Any isdn bind commands must be removed from the D channel. Binding of the NFAS groups now takes place when you use the pri-group commands for IUA with SCTP.

For more information, see the SCTP Migration from RLM to IUA Example.

SUMMARY STEPS

1.    enable

2.    copy run tftp

3.    For RLM, remove the "isdn rlm-group 1" line shown in bold.

4.    copy tftp start

5.    reload


DETAILED STEPS
  Command or Action Purpose
Step 1
enable


Example:

Router> enable

 

Enters privileged EXEC mode. Enter your password if prompted.

 
Step 2
copy run tftp


Example:

Router# copy run tftp

 

Copies the running configuration to a TFTP server. Make a backup copy of the running configuration. Enter the IP address and destination filename when prompted.

Note    Make all edits to the configuration text file that you have copied over to your TFTP server. Some TFTP servers might require that the name of the file that you intend to copy over is already existing and has write permissions on the TFTP server onto which you are copying.
 
Step 3
For RLM, remove the "isdn rlm-group 1" line shown in bold.

Example:

interface Serial3/0:1:23



Example:

no ip address



Example:

isdn switch-type primary-ni



Example:

isdn incoming-voice modem



Example:

isdn T321 30000



Example:

isdn T303 20000



Example:

isdn T200 2000



Example:

isdn rlm-group 1



Example:

isdn negotiate-bchan resend-setup



Example:

isdn bchan-number-order ascending



Example:

no cdp enable

 

Links IUA instead of RLM by removing the "isdn rlm-group 1" line from the interface serial output.

 
Step 4
copy tftp start


Example:

Router# copy tftp start

 

Copies the new configuration to the startup configuration.

 
Step 5
reload


Example:

Router# reload

 

Reloads the router.

 

Modifying a PRI Group on an MGC

To modify a PRI group on an MGC, perform the following steps.

Before You Begin
  • Remove isdn bind commands from the D channel. Binding of the NFAS groups takes place when you use the pri-group commands for IUA with SCTP.

Note


For more information, see the Trunk Group Bound to an Application Server Example.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface Dchannel3/0:1

4.    shutdown

5.    exit


DETAILED STEPS
  Command or Action Purpose
Step 1
enable


Example:

Router> enable

 

Enters privileged EXEC mode. Enter your password if prompted.

 
Step 2
configure terminal


Example:

Router# configure terminal

 

Enters global configuration mode.

 
Step 3
interface Dchannel3/0:1


Example:

Router(config)# interface Dchannel3/0:1

 

Enters interface configuration mode for the specified D channel that is to be shut down. This is the format used for IUA.

 
Step 4
shutdown


Example:

Router(config-if)# shutdown

 

Shuts down the D channel.

 
Step 5
exit


Example:

Router(config-if)# exit

 

Exits the current mode.

 

Verifying Support for IUA with SCTP

To verify support for IUA with SCTP, perform the following steps (listed alphabetically).

SUMMARY STEPS

1.    show ip sctp association list

2.    show ip sctp association parameters

3.    show ip sctp association statistics

4.    show ip sctp errors

5.    show ip sctp instances

6.    show ip sctp statistics

7.    show isdn service

8.    show isdn status

9.    show running-config


DETAILED STEPS
Step 1   show ip sctp association list

Use this command to display current SCTP association and instance identifiers, current state of SCTP associations, and local and remote port numbers and addresses that are used in the associations.

The example below shows two current associations that are in the established state. Each association belongs to a different instance, as noted by their instance identifiers.



Example:
Router# show ip sctp association list
*** SCTP Association List ****
AssocID: 0,  Instance ID: 0
Current state: ESTABLISHED
Local port: 8787, Addrs: 10.1.0.2 10.2.0.2
Remote port: 8787, Addrs: 10.5.0.4 10.6.0.4
AssocID: 1,  Instance ID: 1
Current state: ESTABLISHED
Local port: 6790, Addrs: 10.1.0.2 10.2.0.2
Remote port: 6789, Addrs: 10.5.0.4 10.6.0.4
Step 2   show ip sctp association parameters

Use this command to display parameter values for the specified association. This command requires an association identifier as an argument. Association identifiers can be obtained from the output of the show ip sctp association list command.

Many parameters are defined for each association, some of them configured and some of them calculated. They fall into the following main groupings:

  • Association configuration parameters
  • Destination address parameters
  • Association boundary parameters
  • Current association congestion parameters


Example:
Router# show ip sctp association parameters 0
** SCTP Association Parameters **
AssocID: 0  Context: 0  InstanceID: 0
Assoc state: ESTABLISHED  Uptime: 00:00:34.280
Local port: 8787
Local addresses: 10.1.0.2 10.2.0.2
Remote port: 8787
Primary dest addr: 10.5.0.4
Effective primary dest addr: 10.5.0.4
Destination addresses:
10.5.0.4:   State:  ACTIVE
  Heartbeats:  Enabled   Timeout: 30000 ms
  RTO/RTT/SRTT: 1000/0/0 ms   TOS: 0  MTU: 1500
  cwnd: 5000  ssthresh: 18000  outstand: 0
  Num retrans: 0  Max retrans: 5  Num times failed: 0
10.6.0.4:   State:  ACTIVE
  Heartbeats:  Enabled   Timeout: 30000 ms
  RTO/RTT/SRTT: 1000/0/0 ms   TOS: 0  MTU: 1500
  cwnd: 3000  ssthresh: 18000  outstand: 0
  Num retrans: 0  Max retrans: 5  Num times failed: 0
Local vertag: DA3C3BD  Remote vertag: 4D95E3A
Num inbound streams: 13  outbound streams: 13
Max assoc retrans: 5  Max init retrans: 8
CumSack timeout: 200 ms  Bundle timeout: 100 ms
Min RTO: 1000 ms  Max RTO: 60000 ms
LocalRwnd: 9000  Low: 6400   RemoteRwnd: 16800  Low: 14900
Congest levels: 0  current level: 0  high mark: 1
Step 3   show ip sctp association statistics

Use this command to display statistics about the specified association, including the following: The first numbers show the total number of chunks, both data and control, sent and received. The second group of statistics focuses on the data chunks sent, showing the total number sent, the number retransmitted, the number that were ordered and unordered, the average number that were bundled together, and the total bytes sent. The third group of statistics focuses on the data chunks received. It displays the total number received and the number discarded (because of duplicates), the number of ordered and unordered chunks received, the average number of chunks that were bundled, the number of bytes received, and the number of sequenced chunks that were received out of order. The last section indicates how many datagrams have been sent, received, or are ready to be received by the calling application or ULP. The ULP statistics may be different from the chunk statistics if the datagrams are large and have been segmented by SCTP.

Note    This command requires an association identifier argument, which you can obtain from output of the show ip sctp association list command.

The following example was taken from a network with known dropped packets in one direction. The number of total chunks sent and received is larger than the number of data chunks sent and received because it also includes the control chunks sent. The number of chunks received out of sequence indicates that there are some chunks not being received in the correct order. However, the number of chunks discarded is zero, indicating that only one copy of each is arriving at this peer (some chunks are probably being dropped and the peer is retransmitting them, but there are no duplicates being received). The number of chunks being retransmitted is zero, indicating that there is no network problem in the direction of sending from this peer to the remote.



Example:
Router# show ip sctp association statistics 0
** SCTP Association Statistics **
AssocID/InstanceID: 0/0
Current State: ESTABLISHED
Control Chunks
  Sent: 1009  Rcvd: 988
Data Chunks Sent
  Total: 18073  Retransmitted: 0
  Ordered: 9095  Unordered: 8978
  Avg bundled: 9  Total Bytes: 1807300
Data Chunks Rcvd
  Total: 18073  Discarded: 0
  Ordered: 9095  Unordered: 8978
  Avg bundled: 9  Total Bytes: 1807300
  Out of Seq TSN: 586
ULP Dgrams
  Sent: 18073  Ready: 18073  Rcvd: 18073
Step 4   show ip sctp errors

Use this command to display errors logged since last time that the statistics were cleared.

The following output shows one example in which no errors have been logged, and another in which there have been several different types of errors.



Example:
Router# show ip sctp errors
*** SCTP Error Statistics ****
No SCTP errors logged.
Router# show ip sctp errors
*** SCTP Error Statistics ****
Communication Lost:              95
Unknown INIT params rcvd:        8
Missing parameters:              18
No room for incoming data:       11
Step 5   show ip sctp instances

Use this command to display information for each of the currently configured instances. The instance number, local port, and address information is displayed. The instance state is either available or deletion pending . An instance enters the deletion pending state when a request is made to delete it but there are currently established associations for that instance. The instance cannot be deleted immediately and instead enters the pending state. No new associations are allowed in this instance, and when the last association is terminated or fails, the instance is deleted.

The default inbound and outbound stream numbers are used for establishing incoming associations, and the maximum number of associations allowed for this instance is shown. Finally, a snapshot of each existing association is shown, if any exist.

In this example, two current instances are active and available. The first is using local port 8787, and the second is using local port 6790. Instance identifier 0 has one current association, and instance identifier 1 has no current associations.



Example:
Router# show ip sctp instances
*** SCTP Instances ****
Instance ID: 0  Local port: 8787
Instance state: available
Local addrs: 10.1.0.2 10.2.0.2
Default streams inbound: 1  outbound: 1
  Current associations:  (max allowed: 6)
  AssocID: 0  State: ESTABLISHED  Remote port: 8787
    Dest addrs: 10.5.0.4 10.6.0.4
Instance ID: 1  Local port: 6790
Instance state: available
Local addrs: 10.1.0.2 10.2.0.2
Default streams inbound: 13  outbound: 13
No current associations established for this instance.
Max allowed: 6
Step 6   show ip sctp statistics

Use this command to display the overall SCTP statistics accumulated since the last clear ip sctp statisticscommand for currently established associations and those that have terminated. The command also displays the number of aborts and shutdowns received and the number of times the T1 (initialization) and T2 (shutdown) timers expired.



Example:
Router# show ip sctp statistics
** SCTP Overall Statistics **
Control Chunks
  Sent: 7872  Rcvd: 8547
Data Chunks Sent
  Total: 98681  Retransmitted: 5
  Ordered: 50241  Unordered: 48435
  Total Bytes: 9868100
Data Chunks Rcvd
  Total: 98676  Discarded: 0
  Ordered: 50241  Unordered: 48435
  Total Bytes: 9867600
  Out of Seq TSN: 2845
SCTP Dgrams
  Sent: 17504  Rcvd: 19741
ULP Dgrams
  Sent: 98676  Ready: 98676  Rcvd: 98676
Additional Stats
  Assocs Currently Estab: 0
  Active Estab: 0  Passive Estab: 2
  Aborts: 0  Shutdowns: 0
  T1 Expired: 11  T2 Expired: 0
Step 7   show isdn service

Use this command to display information about ISDN channels and the service states.

Step 8   show isdn status

Use this command to display the status of all ISDN interfaces, including active layers, timer information, and switch-type settings.

Step 9   show running-config

Use this command to display the basic router configuration.


Troubleshooting Tips

In a live system, debug commands for performance, state, signal, and warnings are most useful. These commands show any association or destination address failures and can be used to monitor the stability of any established associations.


Caution


Use debug commands with extreme caution or not at all in live systems, depending on the amount of traffic. Debug commands other than those for performance, state, signal, and warnings can generate a great deal of output and therefore cause associations to fail. Use these commands only in test environments or during times of very low traffic volume.



Note


SCTP debug commands display information for all current SCTP associations and cannot be limited to particular associations.
  • SCTP debug commands that display statistical information show only the information that is available since the last time a clear ip sctp statistics command was executed. The clear ip sctp statisticscommand clears all SCTP statistics, both those compiled for individual associations and those compiled overall.
  • Sample outputs for the debug commands are shown in the Examples.
  • You can use debugs with timestamps enabled to see the relevant timing of the events indicated. To add timestamps to debug output, use the service timestampscommands (service timestamps debug and service timestamps log), optionally with the msec keyword. Output is in the format MMM DD HH:MM:SS, which indicates the date and time according to the system clock. If the system clock is not set, the date and time are preceded by an asterisk (*) to indicate that the date and time are probably not correct.
  • For more information on SCTP debug commands, see Stream Control Transmission Protocol (SCTP) .
  • Use the debug ip sctp api command to show all SCTP calls to the application programming interface (API) that are being executed and the parameters associated with these calls.
  • Use the debug ip sctp congestion command to display various events related to calculating the current congestion parameters, including congestion window (cwnd) values per destination address and local and remote receiver window (rwnd) parameters. Information is displayed when bundling and sending data chunks, indicating the current cwnd and rwnd values and remote rwnd values, thus showing when data can or can not be sent or bundled. When chunks are acknowledged by the remote peer, the number of bytes outstanding and remote rwnd values are updated. Information is also displayed when new chunks are received, thus decreasing the local rwnd space, and when chunks are freed because the ULP is receiving datagrams from SCTP and thus freeing local rwnd space.
  • Use the debug ip sctp init command to display datagrams and other information related to the initializing of new associations. All initialization chunks are shown, including the INIT, INIT_ACK, COOKIE_ECHO, and COOKIE_ACK chunks. You can use this command to see the chunks associated with any initialization sequence, but it does not display data chunks sent once the association is established. Therefore, it is safe to use in a live system that has traffic flowing when you have trouble with associations that fail and have to be reestablished.
  • Use the debug ip sctp multihome command to display the source and destination of datagrams in order to monitor use of the multihome addresses. More than one IP address parameter can be included in an INIT chunk when the INIT sender is multihomed. Datagrams should mostly be sent to the primary destination addresses unless the network is experiencing problems, in which case they can be sent to the secondary addresses.
  • Use the debug ip sctp performance command to display the average number of chunks and datagrams being sent and received per second once every 10 seconds. Averages are cumulative since the last time the statistics were cleared and so may not accurately reflect the number of datagrams and chunks currently being sent and received.
  • Use the debug ip sctp rcvchunks command to display information about chunks that are received, including the following: stream number, sequence number, chunk length, and chunk transmission sequence number (TSN) for each chunk received; and whether the chunk is for a new datagram or a datagram that is already being reassembled. Command output shows whether the datagram is complete after receiving this chunk or not and, if complete, whether it is in sequence within the specified stream and can be delivered to the ULP. It shows the SACKs that are sent back to the remote, indicating the cumulative TSN acknowledged, the number of fragments included, and that the datagram is received by the ULP.
  • Use the debug ip sctp rto command to display adjustments to the retransmission (retrans) timeout value due to retransmission of data chunks or unacknowledged heartbeats.
  • Use the debug ip sctp segments command to display every datagram that is sent or received and the chunks that are contained in each. The command has two forms: simple and verbose. This simple form of the command shows basic information for each chunk type.
  • Use the debug ip sctp segmentv command to show every datagram that is sent or received and the chunks that are contained in each. The command has two forms: simple and verbose. This verbose form of the output shows detailed information for each chunk type.
  • Use the debug ip sctp signal command to display signals that are sent from SCTP to the application or ULP. These signals inform the ULP of state transitions for associations or destination addresses. Signal s sent to the ULP when new data is available to be received may not be shown because they occur infrequently. You can use this command to determine whether or not the current associations are stable. Because it does not generate output except on state transitions, it is safe to use in a live environment. It still should be used with caution, however, depending on the number of associations being handled by the system and the stability of the network.

Note


The debug ip sctp state and debug ip sctp signalcommands are often used together to provide insight into the stability of associations.
  • Use the debug ip sctp sndchunks command to display the following types of information about all chunks that are being sent to remote SCTP peers:
    • Application send requests from the local SCTP peer
    • Chunks being bundled and sent to the remote peer
    • Processing of the SACKs from the remote peer, indicating which chunks were successfully received
    • Chunks that are marked for retransmission
  • Use the debug ip sctp state command with the debug ip sctp signal command to provide insight into the stability of associations.
  • Use the debug ip sctp timer command to display information about all started, stopped, and triggering SCTP timers. Many SCTP timers, after they are started, are not restarted until they expire or are stopped; the first call starts the timer, and subsequent calls do nothing until the timer either expires or is stopped.
  • Use the debug ip sctp warnings command to display information on any unusual situation that is encountered. These situations may or may not indicate problems, depending on the particulars of the situation.
  • Use the debug iua as command to display debug messages for the IUA application server when an ISDN backhaul connection is initially established.
  • Use the debug iua asp command to display debug messages for the IUA ASP when an ISDN backhaul connection is initially established.

Examples

Sample Output for the debug ip sctp api Command

Caution


Do not use this command in a live system that has any significant amount of traffic running. It can generate significant traffic, and cause associations to fail.


Router# debug ip sctp api
*Mar  1 00:31:14.211: SCTP: sctp_send: Assoc ID: 1
*Mar  1 00:31:14.211: SCTP:            stream num: 10
*Mar  1 00:31:14.211: SCTP:            bptr: 62EE332C, dptr: 4F7B598
*Mar  1 00:31:14.211: SCTP:            datalen: 100
*Mar  1 00:31:14.211: SCTP:            context: 1
*Mar  1 00:31:14.211: SCTP:            lifetime: 0
*Mar  1 00:31:14.211: SCTP:            unorder flag: FALSE
*Mar  1 00:31:14.211: SCTP:            bundle flag: TRUE
*Mar  1 00:31:14.211: SCTP: sctp_send successful return
*Mar  1 00:31:14.211: SCTP: sctp_receive: Assoc ID: 1
*Mar  1 00:31:14.215: SCTP:               max data len: 100
*Mar  1 00:31:14.215: SCTP: sctp_receive successful return
*Mar  1 00:31:14.215: SCTP: Process Send Request
*Mar  1 00:31:14.951: SCTP: sctp_receive: Assoc ID: 0
*Mar  1 00:31:14.951: SCTP:               max data len: 100
*Mar  1 00:31:14.951: SCTP: sctp_receive successful return
*Mar  1 00:31:14.951: SCTP: sctp_send: Assoc ID: 0
*Mar  1 00:31:14.951: SCTP:            stream num: 12
*Mar  1 00:31:14.951: SCTP:            bptr: 62EE00CC, dptr: 4F65158
*Mar  1 00:31:14.951: SCTP:            datalen: 100
*Mar  1 00:31:14.951: SCTP:            context: 0
*Mar  1 00:31:14.951: SCTP:            lifetime: 0
*Mar  1 00:31:14.951: SCTP:            unorder flag: FALSE
*Mar  1 00:31:14.951: SCTP:            bundle flag: TRUE
*Mar  1 00:31:14.951: SCTP: sctp_send successful return
*Mar  1 00:31:14.951: SCTP: sctp_receive: Assoc ID: 0
*Mar  1 00:31:14.951: SCTP:               max data len: 100
*Mar  1 00:31:14.951: SCTP: sctp_receive successful return
Sample Output for the debug ip sctp congestion Command
Router# debug ip sctp congestion
SCTP: Assoc 0: Slow start 10.6.0.4, cwnd 3000
SCTP: Assoc 0: Data chunks rcvd, local rwnd 7800
SCTP: Assoc 0: Free chunks, local rwnd 9000
SCTP: Assoc 0: Data chunks rcvd, local rwnd 8200
SCTP: Assoc 0: Add Sack, local a_rwnd 8200
SCTP: Assoc 0: Free chunks, local rwnd 9000
SCTP: Assoc 0: Data chunks rcvd, local rwnd 7800
SCTP: Assoc 0: Data chunks rcvd, local rwnd 7000
SCTP: Assoc 0: Add Sack, local a_rwnd 7000
SCTP: Assoc 0: Free chunks, local rwnd 9000
SCTP: Assoc 0: Bundle for 10.5.0.4, rem rwnd 14000, cwnd 19500, outstand 0
SCTP: Assoc 0: Bundled 12 chunks, remote rwnd 12800, outstand 1200
SCTP: Assoc 0: Bundling data, next chunk dataLen (100) > remaining mtu size
SCTP: Assoc 0: Bundle for 10.5.0.4, rem rwnd 12800, cwnd 19500, outstand 1200
SCTP: Assoc 0: Bundled 12 chunks, remote rwnd 11600, outstand 2400
SCTP: Assoc 0: Bundling data, next chunk dataLen (100) > remaining mtu size
SCTP: Assoc 0: Bundle for 10.5.0.4, rem rwnd 11600, cwnd 19500, outstand 2400
SCTP: Assoc 0: Bundled 12 chunks, remote rwnd 10400, outstand 3600
SCTP: Assoc 0: Bundling data, next chunk dataLen (100) > remaining mtu size
SCTP: Assoc 0: Bundle for 10.5.0.4, rem rwnd 10400, cwnd 19500, outstand 3600
SCTP: Assoc 0: Bundled 4 chunks, remote rwnd 10000, outstand 4000
SCTP: Assoc 0: No additional chunks waiting.
SCTP: Assoc 0: Data chunks rcvd, local rwnd 7800
SCTP: Assoc 0: Data chunks rcvd, local rwnd 7000
SCTP: Assoc 0: Add Sack, local a_rwnd 7000
SCTP: Assoc 0: Chunk A22F3B45 ack'd, dest 10.5.0.4, outstanding 3900
SCTP: Assoc 0: Chunk A22F3B46 ack'd, dest 10.5.0.4, outstanding 3800
SCTP: Assoc 0: Chunk A22F3B47 ack'd, dest 10.5.0.4, outstanding 3700
SCTP: Assoc 0: Chunk A22F3B48 ack'd, dest 10.5.0.4, outstanding 3600
SCTP: Assoc 0: Chunk A22F3B49 ack'd, dest 10.5.0.4, outstanding 3500
SCTP: Assoc 0: Chunk A22F3B4A ack'd, dest 10.5.0.4, outstanding 3400
SCTP: Assoc 0: Chunk A22F3B4B ack'd, dest 10.5.0.4, outstanding 3300
SCTP: Assoc 0: Chunk A22F3B4C ack'd, dest 10.5.0.4, outstanding 3200
SCTP: Assoc 0: Chunk A22F3B4D ack'd, dest 10.5.0.4, outstanding 3100
SCTP: Assoc 0: Chunk A22F3B4E ack'd, dest 10.5.0.4, outstanding 3000
SCTP: Assoc 0: Chunk A22F3B4F ack'd, dest 10.5.0.4, outstanding 2900
SCTP: Assoc 0: Chunk A22F3B50 ack'd, dest 10.5.0.4, outstanding 2800
SCTP: Assoc 0: Chunk A22F3B51 ack'd, dest 10.5.0.4, outstanding 2700
SCTP: Assoc 0: Chunk A22F3B52 ack'd, dest 10.5.0.4, outstanding 2600
SCTP: Assoc 0: Chunk A22F3B53 ack'd, dest 10.5.0.4, outstanding 2500
SCTP: Assoc 0: Chunk A22F3B54 ack'd, dest 10.5.0.4, outstanding 2400
SCTP: Assoc 0: Chunk A22F3B55 ack'd, dest 10.5.0.4, outstanding 2300
SCTP: Assoc 0: Chunk A22F3B56 ack'd, dest 10.5.0.4, outstanding 2200
Sample Output for the debug ip sctp init Command
Router# debug ip sctp init
*Mar  1 00:53:07.279: SCTP Test: Attempting to open assoc to remote port 8787...assoc ID is 0
*Mar  1 00:53:07.279: SCTP: Process Assoc Request
*Mar  1 00:53:07.279: SCTP: Assoc 0: dest addr list:
*Mar  1 00:53:07.279: SCTP:                 addr 10.5.0.4
*Mar  1 00:53:07.279: SCTP:                 addr 10.6.0.4
*Mar  1 00:53:07.279:
...
*Mar  1 00:53:13.279: SCTP: Assoc 0: Send Init
*Mar  1 00:53:13.279: SCTP:        INIT_CHUNK, len 42
*Mar  1 00:53:13.279: SCTP:        Initiate Tag: B4A10C4D, Initial TSN: B4A10C4D, rwnd 9000
*Mar  1 00:53:13.279: SCTP:        Streams Inbound: 13, Outbound: 13
*Mar  1 00:53:13.279: SCTP:        IP Addr: 10.1.0.2
*Mar  1 00:53:13.279: SCTP:        IP Addr: 10.2.0.2
*Mar  1 00:53:13.279: SCTP:        Supported addr types: 5
*Mar  1 00:53:13.307: SCTP: Process Init
*Mar  1 00:53:13.307: SCTP:        INIT_CHUNK, len 42
*Mar  1 00:53:13.307: SCTP:        Initiate Tag: 3C2D8327, Initial TSN: 3C2D8327, rwnd 18000
*Mar  1 00:53:13.307: SCTP:        Streams Inbound: 13, Outbound: 13
*Mar  1 00:53:13.307: SCTP:        IP Addr: 10.5.0.4
*Mar  1 00:53:13.307: SCTP:        IP Addr: 10.6.0.4
*Mar  1 00:53:13.307: SCTP:        Supported addr types: 5
*Mar  1 00:53:13.307: SCTP: Assoc 0: Send InitAck
*Mar  1 00:53:13.307: SCTP:        INIT_ACK_CHUNK, len 124
*Mar  1 00:53:13.307: SCTP:        Initiate Tag: B4A10C4D, Initial TSN: B4A10C4D, rwnd 9000
*Mar  1 00:53:13.307: SCTP:        Streams Inbound: 13, Outbound: 13
*Mar  1 00:53:13.307: SCTP:        Responder cookie len 88
*Mar  1 00:53:13.307: SCTP:        IP Addr: 10.1.0.2
*Mar  1 00:53:13.307: SCTP:        IP Addr: 10.2.0.2
*Mar  1 00:53:13.311: SCTP: Assoc 0: Process Cookie
*Mar  1 00:53:13.311: SCTP:        COOKIE_ECHO_CHUNK, len 88
*Mar  1 00:53:13.311: SCTP: Assoc 0: dest addr list:
*Mar  1 00:53:13.311: SCTP:                 addr 10.5.0.4
*Mar  1 00:53:13.311: SCTP:                 addr 10.6.0.4
*Mar  1 00:53:13.311:
*Mar  1 00:53:13.311: SCTP: Instance 0 dest addr list:
*Mar  1 00:53:13.311: SCTP:                 addr 10.5.0.4
*Mar  1 00:53:13.311: SCTP:                 addr 10.6.0.4
*Mar  1 00:53:13.311:
*Mar  1 00:53:13.311: SCTP: Assoc 0: Send CookieAck
*Mar  1 00:53:13.311: SCTP:        COOKIE_ACK_CHUNK
Sample Output for the debug ip sctp multihome Command

Caution


This command generates one debug line for each datagram sent or received. Use with extreme caution in a live network.


Router# debug ip sctp multihome
SCTP: Rcvd s=10.5.0.4  8787, d=10.1.0.2  8787, len 1404
SCTP: Rcvd s=10.5.0.4  8787, d=10.1.0.2  8787, len 476
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 28
SCTP: Assoc 0: Send Data to dest 10.5.0.4
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 1404
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 1404
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 1404
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 476
SCTP: Rcvd s=10.5.0.4  8787, d=10.1.0.2  8787, len 28
SCTP: Rcvd s=10.5.0.4  8787, d=10.1.0.2  8787, len 28
SCTP: Rcvd s=10.5.0.4  8787, d=10.1.0.2  8787, len 1404
SCTP: Rcvd s=10.5.0.4  8787, d=10.1.0.2  8787, len 1404
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 28
SCTP: Rcvd s=10.5.0.4  8787, d=10.1.0.2  8787, len 1404
SCTP: Rcvd s=10.5.0.4  8787, d=10.1.0.2  8787, len 476
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 28
SCTP: Assoc 0: Send Data to dest 10.5.0.4
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 1404
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 1404
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 1404
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 476
SCTP: Rcvd s=10.6.0.4  8787, d=10.2.0.2  8787, len 44
SCTP: Sent:  Assoc 0: s=10.2.0.2  8787, d=10.6.0.4  8787, len 44
SCTP: Rcvd s=10.5.0.4  8787, d=10.1.0.2  8787, len 28
SCTP: Rcvd s=10.5.0.4  8787, d=10.1.0.2  8787, len 28
SCTP: Rcvd s=10.5.0.4  8787, d=10.1.0.2  8787, len 1404
SCTP: Rcvd s=10.5.0.4  8787, d=10.1.0.2  8787, len 1404
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 28
SCTP: Rcvd s=10.5.0.4  8787, d=10.1.0.2  8787, len 1404
SCTP: Rcvd s=10.5.0.4  8787, d=10.1.0.2  8787, len 476
Sample Output for the debug ip sctp performance Command

In the following example, when the performance debug was first enabled, it showed a very low rate of traffic. However, it was expected that these numbers were not accurate, so a clear ip sctp command was executed. The average numbers adjusted quickly to reflect the accurate amount of flowing traffic.

Router# debug ip sctp performance
SCTP Sent: SCTP Dgrams 5, Chunks 28, Data Chunks 29, ULP Dgrams 29
SCTP Rcvd: SCTP Dgrams 7, Chunks 28, Data Chunks 29, ULP Dgrams 29
Chunks Discarded: 0,  Retransmitted 0
SCTP Sent: SCTP Dgrams 6, Chunks 29, Data Chunks 30, ULP Dgrams 30
SCTP Rcvd: SCTP Dgrams 7, Chunks 29, Data Chunks 30, ULP Dgrams 30
Chunks Discarded: 0,  Retransmitted 0
SCTP Sent: SCTP Dgrams 6, Chunks 29, Data Chunks 31, ULP Dgrams 31
SCTP Rcvd: SCTP Dgrams 7, Chunks 30, Data Chunks 31, ULP Dgrams 31
Chunks Discarded: 0,  Retransmitted 0
SCTP Sent: SCTP Dgrams 6, Chunks 30, Data Chunks 31, ULP Dgrams 31
SCTP Rcvd: SCTP Dgrams 7, Chunks 31, Data Chunks 32, ULP Dgrams 31
Chunks Discarded: 0,  Retransmitted 0
SCTP Sent: SCTP Dgrams 6, Chunks 31, Data Chunks 32, ULP Dgrams 32
SCTP Rcvd: SCTP Dgrams 7, Chunks 32, Data Chunks 32, ULP Dgrams 32
Chunks Discarded: 0,  Retransmitted 0
Router# clear ip sctp statistics
SCTP Sent: SCTP Dgrams 30, Chunks 210, Data Chunks 199, ULP Dgrams 201
SCTP Rcvd: SCTP Dgrams 30, Chunks 208, Data Chunks 198, ULP Dgrams 198
Chunks Discarded: 0,  Retransmitted 0
SCTP Sent: SCTP Dgrams 30, Chunks 210, Data Chunks 199, ULP Dgrams 200
SCTP Rcvd: SCTP Dgrams 30, Chunks 209, Data Chunks 199, ULP Dgrams 199
Chunks Discarded: 0,  Retransmitted 0
SCTP Sent: SCTP Dgrams 30, Chunks 211, Data Chunks 200, ULP Dgrams 199
SCTP Rcvd: SCTP Dgrams 30, Chunks 209, Data Chunks 198, ULP Dgrams 198
Chunks Discarded: 0,  Retransmitted 0
Sample Output for the debug ip sctp rcvchunks Command

Caution


This command generates multiple debug lines for each chunk received. Use with extreme caution in a live network.


In the following example, a segmented datagram is received in two chunks, for stream 0 and sequence number 0. The length of the first chunk is 1452, and the second is 1 byte. The first chunk indicates that it is for a new datagram, but the second chunk indicates that it is part of an existing datagram that is already being reassembled. When the first chunk is processed, it is noted to be in sequence, but is not complete and so cannot be delivered yet. When the second chunk is received, the datagram is both in sequence and complete. The application receives the datagram, and a SACK is shown to acknowledge that both chunks were received with no missing chunks indicated (that is, with no fragments).

Router# debug ip sctp rcvchunks
SCTP: Assoc 0: New chunk (0/0/1452/2C33D822) for new dgram (0)
SCTP: Assoc 0: dgram (0) is in seq
SCTP: Assoc 0: Add Sack Chunk, CumTSN=2C33D822, numFrags=0
SCTP: Assoc 0: New chunk (0/0/1/2C33D823) for existing dgram (0)
SCTP: Assoc 0: dgram (0) is complete
SCTP: Assoc 0: ApplRecv chunk 0/0/1452/2C33D822
SCTP: Assoc 0: ApplRecv chunk 0/0/1/2C33D823
SCTP: Assoc 0: Add Sack Chunk, CumTSN=2C33D823, numFrags=0

The following example is taken from a specific test in which chunks are both sent out of sequence and duplicated. The first chunk received is for stream 0, with sequence number 5. The datagram is complete, but is not in sequence because the previously received datagram was sequence number 3. A SACK chunk is sent, indicating that there is a gap after TSN 15755E58. This same chunk is received again, and the debug indicates that this chunk is a duplicate and so is not processed. The next chunk received is sequence number 7, also complete but not in sequence. The number of fragments specified is now 2, because both datagrams 4 and 6 have not been received. The duplicate chunk is discarded again. Sequence number 6 is then received, also complete, but not in sequence. The next earliest datagram received is 5, and even though that is in sequence, datagram 5 is not in sequence because datagram 4 has not been received and so neither 5 nor 6 can be delivered. Thus, there are occasions when the previous sequence number shown is in sequence, but the datagram itself is specified as not in sequence. The SACK sent at that point indicates just one fragment, because datagrams 5 through 7 are all in sequence in a block. Finally, datagram 4 is received. It is complete and in sequence, and datagrams 5 through 7 become in sequence as well, and all the datagrams can be received by the application.

Router# debug ip sctp rcvchunks
SCTP: Assoc 0: New chunk (0/5/50/15755E5A) for new dgram (5)
SCTP: Assoc 0: dgram (5) is complete
SCTP: Assoc 0: dgram (5) is not in seq, prev seq (3)
SCTP: Assoc 0: Add Sack Chunk, CumTSN=15755E58, numFrags=1
SCTP: Assoc 0: Rcvd duplicate chunk: 0/5/50/15755E5A
SCTP: Assoc 0: Add Sack Chunk, CumTSN=15755E58, numFrags=1
SCTP: Assoc 0: New chunk (0/7/50/15755E5C) for new dgram (7)
SCTP: Assoc 0: dgram (7) is complete
SCTP: Assoc 0: dgram (7) is not in seq, prev seq (5)
SCTP: Assoc 0: Add Sack Chunk, CumTSN=15755E58, numFrags=2
SCTP: Assoc 0: Rcvd duplicate chunk: 0/7/50/15755E5C
SCTP: Assoc 0: Add Sack Chunk, CumTSN=15755E58, numFrags=2
SCTP: Assoc 0: New chunk (0/6/50/15755E5B) for new dgram (6)
SCTP: Assoc 0: dgram (6) is complete
SCTP: Assoc 0: dgram (6) is not in seq, prev seq (5)
SCTP: Assoc 0: Add Sack Chunk, CumTSN=15755E58, numFrags=1
SCTP: Assoc 0: Rcvd duplicate chunk: 0/6/50/15755E5B
SCTP: Assoc 0: Add Sack Chunk, CumTSN=15755E58, numFrags=1
SCTP: Assoc 0: New chunk (0/4/50/15755E59) for new dgram (4)
SCTP: Assoc 0: dgram (4) is complete
SCTP: Assoc 0: dgram (4) is in seq
SCTP: Assoc 0: dgram (5) is now in seq
SCTP: Assoc 0: dgram (6) is now in seq
SCTP: Assoc 0: dgram (7) is now in seq
SCTP: Assoc 0: Rcvd duplicate chunk: 0/4/50/15755E59
SCTP: Assoc 0: Add Sack Chunk, CumTSN=15755E5C, numFrags=0
SCTP: Assoc 0: ApplRecv chunk 0/4/50/15755E59
SCTP: Assoc 0: ApplRecv chunk 0/5/50/15755E5A
SCTP: Assoc 0: ApplRecv chunk 0/6/50/15755E5C
SCTP: Assoc 0: ApplRecv chunk 0/7/50/15755E5B
Sample Output for the debug ip sctp rto Command

Caution


This command can generate a great deal of output. Use with extreme caution in a live network.


In the following example, there is only one destination address available. Each time the chunk needs to be retransmitted, the retransmission timeout (RTO) value is doubled.

Router# debug ip sctp rto
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 942BAC55
SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 2000 ms
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 942BAC55
SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 4000 ms
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 942BAC55
SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 8000 ms
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 942BAC55
SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 16000 ms
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 942BAC55
SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 32000 ms

In the next example, there is again only one destination address available. The data chunk is retransmitted several times, and the heartbeat timer also expires, causing the RTO timer to back off as well. Note that the heartbeat timer is expiring along with the data chunk retransmission timer, because SCTP is continually trying to send a chunk on which it can calculate the current round trip time (RTT). Because the data chunk is being retransmitted, an RTT calculation cannot be made on it, and the heartbeat is used instead.

Router# debug ip sctp rto
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 98432842
SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 2000 ms
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 98432842
SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 4000 ms
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 98432842
SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 8000 ms
SCTP: Assoc 0: destaddr 10.5.0.4, heartbeat rto backoff 16000 ms
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 98432842
SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 32000 ms
SCTP: Assoc 0: destaddr 10.5.0.4, heartbeat rto backoff 60000 ms
Sample Output for the debug ip sctp segments Command

Caution


This command generates several lines of output for each datagram sent or received. Use with extreme caution in a live network.


The following output shows an example in which an association is established, a few heartbeats are sent, the remote endpoint fails, and the association is restarted.

Router# debug ip sctp segments
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 56
SCTP:        INIT_CHUNK, Tag: 3C72A02A, TSN: 3C72A02A
SCTP: Recv:  Assoc 0: s=10.5.0.4  8787, d=10.1.0.2  8787, len 56
SCTP:        INIT_CHUNK, Tag: 13E5AD6C, TSN: 13E5AD6C
SCTP: Sent:  Assoc NULL: s=10.1.0.2  8787, d=10.5.0.4  8787, len 136
SCTP:        INIT_ACK_CHUNK, Tag: 3C72A02A, TSN: 3C72A02A
SCTP: Recv:  Assoc 0: s=10.5.0.4  8787, d=10.1.0.2  8787, len 100
SCTP:        COOKIE_ECHO_CHUNK, len 88
SCTP: Sent:  Assoc NULL: s=10.1.0.2  8787, d=10.5.0.4  8787, len 16
SCTP:        COOKIE_ACK_CHUNK
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 52
SCTP:        HEARTBEAT_CHUNK
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 52
SCTP:        HEARTBEAT_CHUNK
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 52
SCTP:        HEARTBEAT_CHUNK
SCTP: Recv:  Assoc 0: s=10.5.0.4  8787, d=10.1.0.2  8787, len 56
SCTP:        INIT_CHUNK, Tag: 4F2D8235, TSN: 4F2D8235
SCTP: Sent:  Assoc NULL: s=10.1.0.2  8787, d=10.5.0.4  8787, len 136
SCTP:        INIT_ACK_CHUNK, Tag: 7DD7E424, TSN: 7DD7E424
SCTP: Recv:  Assoc 0: s=10.5.0.4  8787, d=10.1.0.2  8787, len 100
SCTP:        COOKIE_ECHO_CHUNK, len 88
SCTP: Sent:  Assoc NULL: s=10.1.0.2  8787, d=10.5.0.4  8787, len 16
SCTP:        COOKIE_ACK_CHUNK
SCTP: Recv:  Assoc 0: s=10.5.0.4  8787, d=10.1.0.2  8787, len 144
SCTP:        SACK_CHUNK, TSN ack: 7DD7E423, rwnd 18000, num frags 0
SCTP:        DATA_CHUNK, 4/0/100/4F2D8235
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 28
SCTP:        SACK_CHUNK, TSN ack: 4F2D8235, rwnd 8900, num frags 0
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 128
SCTP:        DATA_CHUNK, 4/0/100/7DD7E424
SCTP: Recv:  Assoc 0: s=10.5.0.4  8787, d=10.1.0.2  8787, len 28
SCTP:        SACK_CHUNK, TSN ack: 7DD7E424, rwnd 17900, num frags 0
SCTP: Recv:  Assoc 0: s=10.6.0.4  8787, d=10.2.0.2  8787, len 44
SCTP:        HEARTBEAT_CHUNK
SCTP: Sent:  Assoc 0: s=10.2.0.2  8787, d=10.6.0.4  8787, len 44
SCTP:        HEARTBEAT_ACK_CHUNK
SCTP: Recv:  Assoc 0: s=10.5.0.4  8787, d=10.1.0.2  8787, len 128
SCTP:        DATA_CHUNK, 7/0/100/4F2D8236
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 144
SCTP:        SACK_CHUNK, TSN ack: 4F2D8236, rwnd 9000, num frags 0
SCTP:        DATA_CHUNK, 7/0/100/7DD7E425
SCTP: Recv:  Assoc 0: s=10.5.0.4  8787, d=10.1.0.2  8787, len 28
SCTP:        SACK_CHUNK, TSN ack: 7DD7E424, rwnd 18000, num frags 0
SCTP: Recv:  Assoc 0: s=10.5.0.4  8787, d=10.1.0.2  8787, len 28
SCTP:        SACK_CHUNK, TSN ack: 7DD7E425, rwnd 17900, num frags 0
SCTP: Recv:  Assoc 0: s=10.5.0.4  8787, d=10.1.0.2  8787, len 128
SCTP:        DATA_CHUNK, 4/1/100/4F2D8237
Sample Output for the debug ip sctp segmentv Command

Caution


This command generates multiple lines of output for each datagram sent and received.Use with extreme caution in a live network.


The following output shows an example in which an association is established, a few heartbeats are sent, the remote endpoint fails, and the association is restarted.

Router# debug ip sctp segmentv
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 56, ver tag 0
SCTP:        INIT_CHUNK, len 42
SCTP:        Initiate Tag: B131ED6A, Initial TSN: B131ED6A, rwnd 9000
SCTP:        Streams Inbound: 13, Outbound: 13
SCTP:        IP Addr: 10.1.0.2
SCTP:        IP Addr: 10.2.0.2
SCTP:        Supported addr types: 5
SCTP: Recv:  Assoc 0: s=10.5.0.4  8787, d=10.1.0.2  8787, len 56, ver tag 0
SCTP:        INIT_CHUNK, len 42
SCTP:        Initiate Tag: 5516B2F3, Initial TSN: 5516B2F3, rwnd 18000
SCTP:        Streams Inbound: 13, Outbound: 13
SCTP:        IP Addr: 10.5.0.4
SCTP:        IP Addr: 10.6.0.4
SCTP:        Supported addr types: 5
SCTP: Sent:  Assoc NULL: s=10.1.0.2  8787, d=10.5.0.4  8787, len 136, ver tag 5516B2F3
SCTP:        INIT_ACK_CHUNK, len 124
SCTP:        Initiate Tag: B131ED6A, Initial TSN: B131ED6A, rwnd 9000
SCTP:        Streams Inbound: 13, Outbound: 13
SCTP:        Responder cookie len 88
SCTP:        IP Addr: 10.1.0.2
SCTP:        IP Addr: 10.2.0.2
SCTP: Recv:  Assoc 0: s=10.5.0.4  8787, d=10.1.0.2  8787, len 100, ver tag B131ED6A
SCTP:        COOKIE_ECHO_CHUNK, len 88
SCTP: Sent:  Assoc NULL: s=10.1.0.2  8787, d=10.5.0.4  8787, len 16, ver tag 5516B2F3
SCTP:        COOKIE_ACK_CHUNK
SCTP: Recv:  Assoc 0: s=10.5.0.4  8787, d=10.1.0.2  8787, len 144, ver tag B131ED6A
SCTP:        SACK_CHUNK, len 16
SCTP:        TSN ack: (0xB131ED69)
SCTP:        Rcv win credit: 18000
SCTP:        Num frags: 0
SCTP:        DATA_CHUNK, flags 3, chunkLen 116
SCTP:        DATA_CHUNK, 0/0/100/5516B2F3
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 28, ver tag 5516B2F3
SCTP:        SACK_CHUNK, len 16
SCTP:        TSN ack: (0x5516B2F3)
SCTP:        Rcv win credit: 8900
SCTP:        Num frags: 0
SCTP: Sent:  Assoc 0: s=10.1.0.2  8787, d=10.5.0.4  8787, len 128, ver tag 5516B2F3
SCTP:        DATA_CHUNK, flags 3, chunkLen 116
SCTP:        DATA_CHUNK, 0/0/100/B131ED6A
SCTP: Recv:  Assoc 0: s=10.6.0.4  8787, d=10.2.0.2  8787, len 44, ver tag B131ED6A
SCTP:        HEARTBEAT_CHUNK
SCTP: Sent:  Assoc 0: s=10.2.0.2  8787, d=10.6.0.4  8787, len 44, ver tag 5516B2F3
SCTP:        HEARTBEAT_ACK_CHUNK
SCTP: Recv:  Assoc 0: s=10.5.0.4  8787, d=10.1.0.2  8787, len 28, ver tag B131ED6A
SCTP:        SACK_CHUNK, len 16
Sample Output for the debug ip sctp signal Command and the debug ip sctp state Command

This example shows signals that are sent from SCTP to the application or ULP. A signal is also sent to the ULP when new data is available to be received, but this signal is not shown in the output below because it occurs infrequently.

In the following example, a new association is requested and established. The peer then restarts the association and notes that the association failed and is being reestablished. The local peer then indicates that the association has failed because it has tried to retransmit the specified chunk more than the maximum number of times without success. As a result, the association fails (because of communication loss) and is terminated. The ULP requests that the association be attempted again, and this attempt succeeds. A shutdown is then received from the remote peer, and the local peer enters the shutdown acknowledge sent state, which is followed by the association being terminated. Again, another association attempt is made and succeeds.

Router# debug ip sctp signal
Router# debug ip sctp state
<new assoc attempt>
00:20:08: SCTP: Assoc 0:  state CLOSED -> COOKIE_WAIT
00:20:15: SCTP: Assoc 0:  state COOKIE_WAIT -> ESTABLISHED
00:20:15: SCTP: Assoc 0: Sent ASSOC_UP signal for CONFIGD_ASSOC
00:21:03: SCTP: Assoc 0: Restart rcvd from peer
00:21:03: SCTP: Assoc 0: Sent ASSOC_RESTART signal
00:21:04: SCTP: Assoc 0: chunk 62EA7F40 retransmitted more than max times, failing assoc
00:21:04: SCTP: Assoc 0: Sent ASSOC_FAILED signal, reason: SCTP_COMM_LOST
00:21:04: SCTP: Assoc 0: Sent ASSOC_TERMINATE signal
00:21:04: SCTP: Assoc 0:  state ESTABLISHED -> CLOSED
<new assoc attempt>
00:21:04: SCTP: Assoc 0:  state CLOSED -> COOKIE_WAIT
00:21:04: SCTP: Assoc 0:  state COOKIE_WAIT -> COOKIE_ECHOED
00:21:04: SCTP: Assoc 0:  state COOKIE_ECHOED -> ESTABLISHED
00:21:04: SCTP: Assoc 0: Sent ASSOC_UP signal for CONFIGD_ASSOC
00:21:04: SCTP: Assoc 0: Sent TERMINATE_PENDING signal
00:21:04: SCTP: Assoc 0:  state ESTABLISHED -> SHUTDOWN_ACKSENT
00:21:04: SCTP: Assoc 0: Sent ASSOC_TERMINATE signal
00:21:04: SCTP: Assoc 0:  state SHUTDOWN_ACKSENT -> CLOSED
<new assoc attempt>
00:21:04: SCTP: Assoc 0:  state CLOSED -> COOKIE_WAIT
00:21:04: SCTP: Assoc 0:  state COOKIE_WAIT -> COOKIE_ECHOED
00:21:04: SCTP: Assoc 0:  state COOKIE_ECHOED -> ESTABLISHED
00:21:04: SCTP: Assoc 0: Sent ASSOC_UP signal for CONFIGD_ASSOC

In the following example, the associations themselves are stable, but a particular destination address fails. Because both currently established associations are using the same destination addresses (with different ports), both of the associations indicate the destination address failure. When the destination address again becomes active, the upper-layer protocols are informed.

Router#
00:26:27: SCTP: Assoc 1: Sent DESTADDR_FAILED signal for destaddr 10.6.0.4
00:26:28: SCTP: Assoc 0: Sent DESTADDR_FAILED signal for destaddr 10.6.0.4
Router#
00:30:41: SCTP: Assoc 1: Sent DESTADDR_ACTIVE signal for destaddr 10.6.0.4
00:30:41: SCTP: Assoc 0: Sent DESTADDR_ACTIVE signal for destaddr 10.6.0.4
Sample Output for the debug ip sctp sndchunks Command

Caution


This command generates significant data if there is any significant amount of traffic flowing. Use with extreme caution in live networks.


Router# debug ip sctp sndchunks
SCTP: Assoc 0: ApplSend, chunk: 0/10412/100/A23134F8 to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 5/10443/100/A23134F9 to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 5/10448/100/A231355C to 10.5.0.4
SCTP: Assoc 0: Set oldest chunk for dest 10.5.0.4 to TSN A23134F8
SCTP: Assoc 0: Bundling data, added 0/10412/100/A23134F8, outstanding 100
SCTP: Assoc 0: Bundling data, added 5/10443/100/A23134F9, outstanding 200
SCTP: Assoc 0: Bundling data, added 4/10545/100/A23134FA, outstanding 300
SCTP: Assoc 0: Bundling data, added 10/10371/100/A23134FB, outstanding 400
SCTP: Assoc 0: Bundling data, added 11/10382/100/A23134FC, outstanding 500
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A231350F, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A2313510
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A2313527, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A2313528
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A231353F, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A2313540
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A2313557, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A2313558
SCTP: Assoc 0: ApplSend, chunk: 10/10385/100/A23135BE to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 8/10230/100/A23135BF to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 5/10459/100/A23135C0 to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 4/10558/100/A23135C1 to 10.5.0.4
SCTP: Assoc 0: Set oldest chunk for dest 10.5.0.4 to TSN A231355D
SCTP: Assoc 0: Bundling data, added 5/10449/100/A231355D, outstanding 100
SCTP: Assoc 0: Bundling data, added 3/10490/100/A231355E, outstanding 200
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A23135A4, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A23135A5
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A23135BC, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A23135BD
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A23135C1, numFrags=0
SCTP: Assoc 0: ApplSend, chunk: 5/10460/100/A23135C2 to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 5/10461/100/A23135C3 to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 11/10403/100/A2313626 to 10.5.0.4
SCTP: Assoc 0: Set oldest chunk for dest 10.5.0.4 to TSN A23135C2
SCTP: Assoc 0: Bundling data, added 5/10460/100/A23135C2, outstanding 100
SCTP: Assoc 0: Bundling data, added 5/10461/100/A23135C3, outstanding 200
SCTP: Assoc 0: Bundling data, added 5/10462/100/A23135C4, outstanding 300
SCTP: Assoc 0: Bundling data, added 4/10559/100/A23135C5, outstanding 400
SCTP: Assoc 0: Bundling data, added 4/10560/100/A23135C6, outstanding 500
SCTP: Assoc 0: Bundled 12 chunk(s) in next dgram to 10.5.0.4
SCTP: Assoc 0: Bundling data, added 1/10418/100/A2313622, outstanding 9700
SCTP: Assoc 0: Bundling data, added 3/10502/100/A2313623, outstanding 9800
SCTP: Assoc 0: Bundling data, added 7/10482/100/A2313624, outstanding 9900
SCTP: Assoc 0: Bundling data, added 3/10503/100/A2313625, outstanding 10000
SCTP: Assoc 0: Bundling data, added 11/10403/100/A2313626, outstanding 10100
SCTP: Assoc 0: Bundled 5 chunk(s) in next dgram to 10.5.0.4
SCTP: Assoc 0: Mark chunk A23135C2 for retrans
SCTP: Assoc 0: Mark chunk A23135C3 for retrans
SCTP: Assoc 0: Mark chunk A23135C4 for retrans
SCTP: Assoc 0: Mark chunk A23135C5 for retrans
SCTP: Assoc 0: Mark chunk A23135C6 for retrans
SCTP: Assoc 0: Mark chunk A23135C7 for retrans
SCTP: Assoc 0: Mark chunk A23135C8 for retrans
SCTP: Assoc 0: Mark chunk A23135C9 for retrans
SCTP: Assoc 0: Mark chunk A23135CA for retrans
SCTP: Assoc 0: Bundled 6 chunk(s) in next dgram to 10.6.0.4
SCTP: Assoc 0: Mark chunk A23135C2 for retrans
SCTP: Assoc 0: Mark chunk A23135C3 for retrans
SCTP: Assoc 0: Mark chunk A23135C4 for retrans
Sample Output for the debug ip sctp timer Command

Caution


This command generates a significant amount of output. Use with extreme caution in a live network.


Router# debug ip sctp timer
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Timer BUNDLE triggered
SCTP: Assoc 0: Starting RETRANS timer for destaddr 10.5.0.4
SCTP: Assoc 0: Starting RETRANS timer for destaddr 10.5.0.4
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Starting RETRANS timer for destaddr 10.5.0.4
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Starting RETRANS timer for destaddr 10.5.0.4
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Stopping RETRANS timer for destaddr 10.5.0.4
SCTP: Assoc 0: Starting RETRANS timer for destaddr 10.5.0.4
SCTP: Assoc 0: Stopping RETRANS timer for destaddr 10.5.0.4
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Stopping CUMSACK timer
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
Sample Output for the debug ip sctp warnings Command
Router# debug ip sctp warnings
SCTP: Assoc 0: No cookie in InitAck, discarding
SCTP: Assoc 0: Incoming INIT_ACK: inbound streams reqd 15, allowed 13
SCTP: Assoc 0: Incoming INIT_ACK request: outbound streams req'd 13, allowed 1
SCTP: Assoc 0: Remote verification tag in init ack is zero, discarding
SCTP: Remote verification tag in init is zero, discarding
SCTP: Assoc 0: Rwnd less than min allowed (1500) in incoming INITACK, rcvd 0
SCTP: Assoc 0: Rwnd less than min allowed (1500) in incoming INITACK, rcvd 1499
SCTP: Rwnd in INIT too small (0), discarding
SCTP: Rwnd in INIT too small (1499), discarding
SCTP: Unknown INIT param 16537 (0x4099), length 8
SCTP: Assoc 0: Unknown INITACK param 153 (0x99), length 8
SCTP: Assoc 0: No cookie in InitAck, discarding
SCTP: Assoc 0: No cookie in InitAck, discarding
SCTP: Processing INIT, invalid param len 0, discarding...
SCTP: Assoc 0: Processing INITACK, invalid param len 0, discarding...
Sample Output for the debug iua Command

The following example shows that state debugging is turned on for all application servers and that the application server is active:

Router# debug iua as state all
IUA :state debug turned ON for ALL AS
00:11:52:IUA:AS as1 number of ASPs up is 1
00:11:57:IUA:AS as1 xsition AS-Up -->  AS-Active, cause - ASP asp1

The following example shows that peer message debugging is turned on for all digital signal processors (DSPs) and that the ASP is active:

Router# debug iua asp peer-msg all
IUA :peer message debug turned ON for ALL ASPs
Router#
00:04:58:IUA :recieved ASP_UP message on ASP asp1
00:04:58:IUA:ASP asp1 xsition ASP-Down -->  ASP-Up , cause -  rcv peer
msg
ASP-UP
00:04:58:IUA:sending ACK of type 0x304 to asp asp1
00:05:03:IUA:recv ASP_ACTIVE message for ASP asp1
00:05:03:IUA:ASP asp1 xsition ASP-Up -->  ASP-Active, cause - rcv peer
msg
ASP-Active

Configuration Examples for SCTP Options

Application-Server and Application-Server-Process Example

The following shows sample SCTP configuration options using the help menu for the as and asp commands:

Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# iua
Router(config-iua)# as as1 ?
  A.B.C.D           Specify (up to two) Local IP address
  Fail-Over-Timer   Configure the Fail-Over timer for this AS
  sctp-startup-rtx  Configure the SCTP max startup retransmission timer
  sctp-streams      Configure the number of SCTP streams for this AS
  sctp-t1init       Configure the SCTP T1 init timer
Router(config-iua)# as as1 sctp-startup-rtx ?
  <2-20>  Set SCTP Maximum Startup Retransmission Interval
Router(config-iua)# as as1 sctp-streams ?
  <1-56>  Specify number of SCTP streams for association
Router(config-iua)# as as1 sctp-t1init ?
  <1000-60000>  Set SCTP T1 init timer (in milliseconds)
Router(config-iua)# asp asp1 as as1 ?
  A.B.C.D  Specify (up to two) IP addresses of the call-agent
Router(config-iua)# asp asp1 ?
  AS                Specify which AS this ASP belongs to
  IP-Precedence     Set IP precedence bits for a IP address in this ASP
  sctp-keepalives   Modify the keep-alive behaviour of an IP address in this
                    ASP
  sctp-max-assoc    Set SCTP max association retransmissions for this ASP
  sctp-path-retran  Set SCTP path retransmissions for this ASP
  sctp-t3-timeout   Set SCTP T3 retransmission timeout for this ASP
Router(config-iua)# asp asp1 sctp-keep ?
  A.B.C.D  specify the IP address to enable/disable keep alives
Router(config-iua)# asp asp1 sctp-keepalive 10.10.10.10 ?
  <1000-60000>  specify keep alive interval (in milliseconds)
Router(config-iua)# asp asp1 sctp-max-assoc ?
  A.B.C.D  specify the IP address
Router(config-iua)# asp asp1 sctp-max-assoc 10.10.10.10 ?
  <2-20>   specify maximum associations
  default  use default value of max associations for this address
Router(config-iua)# asp asp1 sctp-path-retran ?
  A.B.C.D  specify the IP address
Router(config-iua)# asp asp1 sctp-path-retran 10.10.10.10 ?
  <2-10>   specify maximum path retransmissions
  default  use default value of max path retrans for this address
Router(config-iua)# asp asp1 sctp-t3-timeout ?
  A.B.C.D  specify the IP address
Router(config-iua)# asp asp1 sctp-t3-timeout 10.10.10.10 ?
  <300-60000>  specify T3 retransmission timeout (in milliseconds)
  default      use default value of T3 for this address

Application-Server and Application-Server-Process with IUA Example

The following example shows a running application-server configuration with IUA configured with one application server (as1) and two application-server processes (asp1 and asp2). Four T1s (T1 1/0, 1/1, 2/0, 2/1) are configured to use IUA backhaul.

Router# show running-config
Building configuration...
Current configuration :2868 bytes
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname iua_3660_b
!
logging rate-limit console 10 except errors
!
memory-size iomem 30
voice-card 1
!
voice-card 2
!
voice-card 3
!
voice-card 4
!
voice-card 5
!
voice-card 6
!
ip subnet-zero
!
no ip domain-lookup
!
no ip dhcp-client network-discovery
iua
  AS as1 10.21.0.2 9900
   ASP asp1 AS as1 10.23.0.16 9900
   ASP asp2 AS as1 10.23.0.16 9911
isdn switch-type primary-5ess
!
fax interface-type modem
mta receive maximum-recipients 0
!
controller T1 1/0
 framing esf
 clock source line primary
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 1/1
 framing esf
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 2/0
 framing esf
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 2/1
 framing esf
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 3/0
 framing sf
 linecode ami
!
controller T1 3/1
 framing sf
 linecode ami
!
controller T1 4/0
 framing sf
 linecode ami
!
controller T1 4/1
 framing sf
 linecode ami
!
controller T1 5/0
 framing sf
 linecode ami
!
controller T1 5/1
 framing sf
 linecode ami
!
controller T1 6/0
 framing sf
 linecode ami
!
controller T1 6/1
 framing sf
 linecode ami
!
interface FastEthernet0/0
 ip address 10.21.0.3 255.255.0.0 secondary
 ip address 10.21.0.2 255.255.0.0
 speed 10
 half-duplex
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial1/0:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
interface Serial1/1:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn guard-timer 3000
 isdn T203 10000
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
interface Serial2/0:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn guard-timer 3000
 isdn T203 10000
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
interface Serial2/1:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn T203 10000
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
ip classless
ip route 10.0.0.0 255.0.0.0 10.21.0.17
ip route 11.0.0.10 255.255.255.255 FastEthernet0/0
ip route 172.0.0.0 255.0.0.0 172.18.194.1
ip http server
!
snmp-server manager
!
call rsvp-sync
!
voice-port 1/0:23
!
voice-port 1/1:23
!
voice-port 2/0:23
!
voice-port 2/1:23
!
no mgcp timer receive-rtcp
!
mgcp profile default
!
dial-peer cor custom
!
line con 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

ISDN Signaling Backhaul Example

The following sample output shows that Layers 1, 2, and 3 are enabled and active. Layer 3 shows the number of active ISDN calls.

Notice that the Layer 2 protocol is Q.921 and the Layer 3 protocol is BACKHAUL. This verifies that the system is configured to backhaul ISDN.

If you are connected to a live line, you should see that Layer 1 is active and Layer 2 is MULTIPLE_FRAME_ESTABLISHED, meaning that the ISDN line is up and active.

Router# show isdn status
*00:03:34.423 UTC Sat Jan 1 2000
Global ISDN Switchtype = primary-net5
ISDN Serial1:23 interface
        dsl 0, interface ISDN Switchtype = primary-net5
        L2 Protocol = Q.921  L3 Protocol(s) = BACKHAUL
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        NLCB:callid=0x0, callref=0x0, state=31, ces=0 event=0x0
        NLCB:callid=0x0, callref=0x0, state=0, ces=1 event=0x0
        0 Active Layer 3 Call(s)
    Activated dsl 0 CCBs = 0
    Number of active calls = 0
    Number of available B-channels = 23
    Total Allocated ISDN CCBs = 0

IUA Configuration Example

The following is an example of an application-server configuration on a gateway:

as as5400-3 10.4.8.69 10.4.9.69 2577

In the configuration above, an application server named as-named as5400-3 is configured to use two local IP addresses and a port number of 2577. IP address values that are set apply to all IP addresses of the ASP.

The following configuration example defines a remote signaling controller asp1 at two IP addresses for the application server named as5400-3. The remote SCTP port number is 2577:

Router(config-iua)# as as5400-3 10.4.8.69 10.4.9.69 2477
Router(config-iua)# asp asp1 as as5400-3 10.4.8.68 10.4.9.68 2577

Multiple ASPs can be defined for a single application server for the purpose of redundancy, but only one ASP can be active. The other ASP is inactive and only becomes active after fail-over.

In the Cisco MGC solution, a signaling controller is always the client that initiates the association with a gateway. During the initiation phase, you can request outbound and inbound stream numbers, but the gateway only allows a number that is at least one digit higher than the number of interfaces (T1/E1) allowed for the platform.

The number of streams to assign to a given association is implementation dependent. During the initialization of the IUA association, you need to specify the total number of streams that can be used. Each D channel is associated with a specific stream within the association. With multiple trunk group support, every interface can potentially be a separate D channel.

At startup, the IUA code checks for all the possible T1, E1, or T3 interfaces and sets the total number of inbound and outbound streams supported accordingly. In most cases, there is only a need for one association between the GW and the MGC. For the rare case that you are configuring multiple application-server associations to various MGCs, the overhead from the unused streams would have minimal impact. The NFAS D channels are configured for one or more interfaces, where each interface is assigned a unique stream ID.

The total number of streams for the association needs to include an additional stream for the SCTP management messages. So during startup the IUA code adds one to the total number of interfaces (streams) found.

You have the option to manually configure the number of streams per association. In the backhaul scenario, if the number of D channel links is limited to one, allowing the number of streams to be configurable avoids the unnecessary allocation of streams in an association that will never be used. For multiple associations between a GW and multiple MGCs, the configuration utility is useful in providing only the necessary number of streams per association. The overhead from the streams allocated but not used in the association is negligible.

If the number of streams is manually configured through the CLI, the IUA code cannot distinguish between a startup event, which automatically sets the streams to the number of interfaces, or if the value is set manually during runtime. If you are configuring the number of SCTP streams manually, you must add one plus the number of interfaces using the sctp-streams keyword with the as command. Otherwise, IUA needs to always add one for the management stream, and the total number of streams increments by one after every reload.

When you set the SCTP stream with the CLI, you cannot change the inbound and outbound stream support once the association is established with SCTP. The value takes effect when you first remove the IUA application-server configuration and then configure it back as the same application server or a new one. The other option is to reload the router.

The following is an example of an application-server configuration on a gateway. The configuration shows that an application server named as5400-3 is configured to use two local IP addresses and a port number of 2577:

Router(config-iua)# as as5400-3 10.1.2.34 10.1.2.35 2577

The following example sets the failover time (in milliseconds) between 1 and 10 seconds. Entering a value of 1000 would equal one second. Entering a value of 10000 would equal 10 seconds. In this example, the failover timer has been set to 10 seconds:

Router(config-iua)# as as5400-3 fail-over 10000

The following example specifies the number of SCTP streams for this association. In this example, 57 is the maximum number of SCTP streams allowed:

Router(config-iua)# as as5400-3 sctp-streams 57

The following example sets the SCTP maximum startup retransmission interval. In this example, 20 is the maximum interval allowed:

Router(config-iua)# as as5400-3 sctp-startup 20

The following example sets the SCTP T1 initiation timer in milliseconds. In this example, 60000 is the maximum time allowed:

Router(config-iua)# as as5400-3 sctp-t1init 60000

The following example specifies the IP address to enable and disable keepalives:

Router(config-iua)# asp asp1 sctp-keepalive 10.1.2.34

The following example specifies the keepalive interval in milliseconds. Valid values range from 1000 to 60000. In this example, the maximum value of 60000 ms is used:

Router(config-iua)# asp asp1 sctp-keepalive 10.10.10.10 60000

The following example specifies the IP address for the SCTP maximum association and the maximum association value. Valid values are from 2 to 20. The default is 20, which is the maximum value allowed:

Router(config-iua)# asp asp1 sctp-max-association 10.10.10.10 20

The following example specifies the IP address for the SCTP path retransmission and the maximum path retransmission value. Valid values are from 2 to 10. The default is 10, which is the maximum value allowed:

Router(config-iua)# asp asp1 sctp-path-retransmissions 10.10.10.10 10

The following examples specifies the IP address for SCTP T3 timeout and specifies the T3 timeout value in milliseconds. Valid timeout values are from 300 to 60000. The default is 60000, which is the maximum timeout value allowed:

Router(config-iua)# asp asp1 sctp-t3-timeout 10.10.10.10 60000

The following example configures the following:

  1. Creates an IUA application server (Cisco AS5300-17) that has two local IP addresses (10.0.0.07 and 10.1.1.17) and local port 2097.
  2. IUA application server Cisco AS5300-17 is connected by two SCTP associations (ASP PGW A and ASP PGW B) to two hot-standby Cisco PGW 2200s (Cisco PGW 2200 PGW A and Cisco PGW 2200 PGW B). Cisco PGW 2200 PGW A has remote IP addresses 10.0.0.00 and 10.1.1.10, and Cisco PGW 2200 PGW B has remote IP addresses 10.0.0.06 and 10.1.1.16.
  3. Two NFAS groups (nfas-group 1 and nfas-group 2), which are both bound to IUA application server as5300-17.
  4. Two trunk groups (trunk-group 11 and trunk-group 22)--Trunk-group 11 is bound to interface Dchannel0 and trunk-group 22 is bound to interface Dchannel2.
Router(config-iua)# as as5300-17 10.0.0.07 10.1.1.17 2097
Router(config-iua)# asp pgwa AS as5300-17  10.0.0.00 10.1.1.10 2097
Router(config-iua)# asp pgwb AS as5300-17  10.0.0.06 10.1.1.16 2097

The figure below shows the configuration above in diagram form with two outgoing POTS dial-peers (dial-peer 1 and dial-peer 2)--dial-peer 1 points to trunk-group 11, and dial-peer 2 points to trunk-group 22.

Figure 7 Specific ASP Example Configuration


The following is example output from the above configuration:

iua
   AS as5300-17 10.0.0.07 10.1.1.17 2097
   ASP pgwa AS as5300-17  10.0.0.00 10.1.1.10 2097
   ASP pgwb AS as5300-17  10.0.0.06 10.1.1.16 2097
!
!
controller E1 0
 framing NO-CRC4
 clock source line primary
 pri-group timeslots 1-31 nfas-d primary nfas-int 0 nfas-group 1 iua as5300-17
!
controller E1 1
 framing NO-CRC4
 clock source line secondary 1
 pri-group timeslots 1-31 nfas-d none nfas-int 1 nfas-group 1
!
controller E1 2
 framing NO-CRC4
 pri-group timeslots 1-31 nfas-d primary nfas-int 0 nfas-group 2 iua as5300-17
!
controller E1 3
 framing NO-CRC4
 pri-group timeslots 1-31 nfas-d none nfas-int 1 nfas-group 2
!
!
interface Ethernet0
 description the ip is 10.0.0.06 for interface e0
 ip address 10.0.0.06 255.255.255.0
 no ip route-cache
 no ip mroute-cache
!
interface FastEthernet0
 description the primary ip is 10.1.1.16 for interface f0
 ip address 10.1.1.10 255.255.255.0
 no ip route-cache
 no ip mroute-cache
 duplex auto
 speed auto
!
interface Dchannel0
 no ip address
 trunk-group 11
 isdn timer t309 100
 isdn timer t321 30000
 isdn incoming-voice modem
 isdn T303 20000
 isdn negotiate-bchan resend-setup
 no cdp enable
!
interface Dchannel2
 no ip address
 trunk-group 22
 isdn timer t309 100
 isdn timer t321 30000
 isdn incoming-voice modem
 isdn T303 20000
 isdn negotiate-bchan resend-setup
 no cdp enable
!
trunk group 11
!
trunk group 22
!
dial-peer voice 1 pots
 incoming called-number
 destination-pattern 997001
 direct-inward-dial
 trunk-group 11
 forward-digits all
!
dial-peer voice 2 pots
 incoming called-number
 destination-pattern 997002
 direct-inward-dial
 trunk-group 22
 forward-digits all
!

The following example shows a running application-server configuration with IUA configured with one application server (as1) and two ASPs (asp1 and asp2). Four T1s (T1 1/0, 1/1, 2/0, 2/1) are configured to use IUA backhaul.

Router# show running config
Building configuration...
Current configuration :2868 bytes
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname iua_3660_b
!
logging rate-limit console 10 except errors
!
memory-size iomem 30
voice-card 1
!
voice-card 2
!
voice-card 3
!
voice-card 4
!
voice-card 5
!
voice-card 6
!
ip subnet-zero
!
no ip domain-lookup
!
no ip dhcp-client network-discovery
iua
  AS as1 10.21.0.2 9900
   ASP asp1 AS as1 10.23.0.16 9900
   ASP asp2 AS as1 10.23.0.16 9911
isdn switch-type primary-5ess
!
fax interface-type modem
mta receive maximum-recipients 0
!
controller T1 1/0
 framing esf
 clock source line primary
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 1/1
 framing esf
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 2/0
 framing esf
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 2/1
 framing esf
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 3/0
 framing sf
 linecode ami
!
controller T1 3/1
 framing sf
 linecode ami
!
controller T1 4/0
 framing sf
 linecode ami
!
controller T1 4/1
 framing sf
 linecode ami
!
controller T1 5/0
 framing sf
 linecode ami
!
controller T1 5/1
 framing sf
 linecode ami
!
controller T1 6/0
 framing sf
 linecode ami
!
controller T1 6/1
 framing sf
 linecode ami
!
interface FastEthernet0/0
 ip address 10.21.0.3 255.255.0.0 secondary
 ip address 10.21.0.2 255.255.0.0
 speed 10
 half-duplex
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial1/0:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
interface Serial1/1:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn guard-timer 3000
 isdn T203 10000
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
interface Serial2/0:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn guard-timer 3000
 isdn T203 10000
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
interface Serial2/1:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn T203 10000
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
ip classless
ip route 10.0.0.0 255.0.0.0 10.21.0.17
ip route 11.0.0.10 255.255.255.255 FastEthernet0/0
ip route 172.0.0.0 255.0.0.0 172.18.194.1
ip http server
!
snmp-server manager
!
call rsvp-sync
!
voice-port 1/0:23
!
voice-port 1/1:23
!
voice-port 2/0:23
!
voice-port 2/1:23
!
no mgcp timer receive-rtcp
!
mgcp profile default
!
dial-peer cor custom
!
line con 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

PRI Group on an MGC Example

To modify a PRI group on a third-party call agent (MGC), the isdn bind commands must be removed from the D channel. The binding of the NFAS groups now takes place when you use the pri-group (pri-slt) command for IUA with SCTP.

Use the following examples to help you with your configuration:

  • Controller configuration for primary span in an NFAS group for RLM. You can choose any time slot other than 24 to be the virtual container for the D channel parameters for ISDN:
controller T1 3/0:1
 framing esf
 pri-group timeslots 1-23 nfas-d primary nfas-int 0 nfas-group 1
  • Controller configuration for primary span in an NFAS group for IUA:
controller T1 3/0:1
 framing esf
 pri-group timeslots 1-23 nfas-d primary nfas-int 0 nfas-group 1 iua as-1

SCTP Configuration Example

You can implicitly configure the number of streams in SCTP by specifying only the serial interfaces that are configured to use IUA. The number of streams is bound to the actual number of interfaces supporting IUA. To support Cisco MGC solutions, you can configure any number of streams for each NFAS D channel, up to the total number of interfaces available in a given GW. For platforms using the PRI backhaul with SCTP and the ISDN Q.921 User Adaptation Layer (UAL), such as the Cisco 3660, you can configure the number of streams to match the number of PRIs that are actually backhauled to the Telcordia session manager.

The following example sets the failover time (in milliseconds) between 1 and 10 seconds. Entering a value of 1000 would equal one second. Entering a value of 10000 would equal 10 seconds. In this example, the failover timer has been set to 10 seconds. The default value is 4000 msec. Once you have set the failover timer to a value, you can return it to its default of 4000 msec by using the no form of this command.

Router(config-iua)# as as5400-3 fail-over 10000

The following example sets the SCTP maximum startup retransmission interval. Valid values are from 2 to 20:

Router(config-iua)# as as1 sctp-startup-rtx 20

The following example specifies the number of SCTP streams for an association. Valid values are from 1 to 56:

Router(config-iua)# as as1 sctp-streams 56

The following example sets the SCTP T1 initiation timer in milliseconds. Valid values are from 1000 to 60000:

Router(config-iua)# as as1 sctp-t1init 60000

SCTP Migration from RLM to IUA Example

The following changes have been made between RLM and IUA with SCTP. Use the examples in this section to help you with your configuration:

  • The D channel interface serial commands are now replaced by interface D channel commands.

For RLM, the following format was used:

interface Serial3/0:1:23

Note


The :23 in the RLM example above, which typically corresponds with T1 configuration (:15 for E1 configuration), is no longer used.

For IUA, the following format is used:

interface Dchannel3/0:1
  • The RLM group configuration must be removed from the D channel configuration.

For RLM, remove the "isdn rlm-group 1" line shown in bold:

interface Serial3/0:1:23
 no ip address
 isdn switch-type primary-ni
 isdn incoming-voice modem
 isdn T321 30000
 isdn T303 20000
 isdn T200 2000
 isdn rlm-group 1
 isdn negotiate-bchan resend-setup
 isdn bchan-number-order ascending
 no cdp enable

For IUA, use the following format:

interface Dchannel3/0:1
 no ip address
 isdn timer t309 100
 isdn timer t321 30000
 isdn incoming-voice modem
 isdn T303 20000
 no isdn send-status-enquiry
 isdn negotiate-bchan resend-setup
 isdn bchan-number-order ascending
 no cdp enable

Trunk Group Bound to an Application Server Example

You can configure the NFAS primary D channel on one channelized T1 controller, and bind the D channel to an IUA application server by using the pri-group (pri-slt) command.

This example uses a Cisco AS5400 and applies to T1, which has 24 timeslots and is used mainly in North America and Japan. You can choose any timeslot other than 24 to be the virtual container for the D channel parameters for ISDN.

Router(config-controller)# pri-group timeslots 1-23 nfas-d primary nfas-int 0 nfas-group 1 iua as5400-4-1

The following example applies to E1, which has 32 timeslots and is used by countries other than North America and Japan. You can choose any timeslot other than 32 to be the virtual container for the D channel parameters for ISDN.

Router(config-controller)# pri-group timeslots 1-31 nfas-d primary nfas-int 0 nfas-group 1 iua as5400-4-1

Additional References

General ISDN References

  • "Overview of ISDN Voice Interfaces" --Describes relevant underlying technology; lists related documents, standards, MIBs, and RFCs; and describes how to obtain technical assistance
  • "Additional References" section --Lists additional ISDN references

References Mentioned in This Chapter

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2012 Cisco Systems, Inc. All rights reserved.