|
|
This feature module describes the X.25 Closed User Groups (CUGs) feature. It includes information on the benefits of the new feature, supported platforms, related documents, and so forth.
This document includes the following sections:
Until now, the Cisco X.25 implementation acted only as an extension between X.25 devices and an X.25 PDN, as a way of remaining minimally intrusive on the X.25 behavior that would occur if the DTE devices were directly connected. Now, Cisco has introduced a conforming closed user groups (CUGs) service that can be configured for those DTE devices that require this service from the routers, allowing Cisco routers to perform this function normally provided by a PDN.
With the X.25 CUGs feature, the router's X.25 DCE interfaces can be configured to perform the standard CUG access controls normally associated with a direct attachment to an X.25 network POP. The router's DCE interface acts as the boundary between the DTE and the network, and CUG use ensures that only those incoming and outgoing SVCs consistent with the configured CUG subscriptions are permitted. X.25 CUG configuration commands on the router are specified at every POP, and CUG security decisions are made solely from those commands.
CUG security depends on CUG decisions made by the two POPs used to connect an SVC through the network, so CUG security depends on the collective configuration of all POPs that define the network boundary. The standalone interface configuration determines if the POP will permit user access for a given incoming or outgoing call within the authorized CUG.
CUG access control is first applied when the originating DTE places a call to the POP, and again when the destination DTE device's POP receives the call for presentation. Changes to the POP CUG subscriptions will not affect any SVCs that have already been established.
When a DTE belongs to more than one CUG, it must specify its preferential CUG, unless a call is specifically aimed at devices outside the CUG network. However, the number of CUGs to which a DTE can belong depends on the size of the network. Unsubscribing from one CUG or the overall CUG service will not result in the termination of the SVC connections.
CUG behavior is a cooperative process between two network devices. The DCE offers this service to the connecting subscribers via the DTE. There is no global database regarding CUG membership, therefore, the Cisco router uses information configured for the various X.25 devices and the encoded CUG information in the outgoing and incoming packets.
The X.25 CUGs feature is used for additional X.25 access protection and security. In a setup where DTE devices are attached to a PDN, you can derive a private subnetwork by subscribing your DTE devices to a set of CUGs, which allows closer control of your DTE devices, such as permitting or restricting which DTE can talk to other DTE devices and for what particular purpose. For example, a distinct CUG can be defined to handle each of the different modes of connectivity, such as:
One site could have different CUG subscriptions, depending on connectivity requirements. These sites could all have restrictions regarding which other company devices can be reached (within a CUG), whether a device is permitted to call the open network for a given function, and whether a public terminal can access the device for a given function.
By default, no CUG behavior is implemented. Therefore, in order to observe CUG restrictions, all users attached to the network must be subscribed to CUG behavior (CUG membership) even if they are not subscribed to a specific CUG.
Figure 1 shows two CUGs (CUG 1 and CUG 2). DTE devices A, B, and C are members of CUG 1. They can initiate and receive calls only from the other members of CUG 1. They are therefore members of a private subnet and cannot be accessed by other DTE devices. DTE A is also a member of CUG 2 with DTE D, but DTE D cannot send calls to or receive calls from DTE B or DTE C. The routers connected to each DTE check each call they receive to determine if that call is intended for their CUG. If not, the router will reject that call.
You can subscribe to multiple CUGs per interface, but each CUG that is permitted must be specifically configured. All CUGs are sorted by their local identifier. The main limitation to the number of CUGs configured is the amount of non-volatile memory available to store the configuration. Having subscribed to a CUG, the DTE indicates which CUG is being called. If the DTE does not indicate a CUG, its DCE will determine which CUG is used and if the call should be allowed.
When you enable X.25 CUG service you are configuring your network like a PDN, and so for every POP with attachments in the network you must configure CUG security, especially on those POPs that do not subscribe to CUGs, because they could act as a "back door" into your CUGs.
For details on configuring CUG security on your network POPs, see the "Configuration Tasks" section.
A DTE that subscribes to more than one CUG (and permits neither incoming nor outgoing access from or to the open network) must designate a preferential CUG. Its use is assumed when no CUG selection is enabled in the outgoing call (call request) or incoming call. Using a preferential CUG achieves a higher level of security. Preferential CUG designation is for DTE devices to operate without requiring a CUG selection facility in every outgoing call, or for DTE devices not capable of encoding a CUG selection.
Preferential CUG designation options are as follows:
A CUG with outgoing access allows you to make outgoing calls to the open part of the network, and to DTE devices with incoming access capability. Subscribing to the outgoing access CUG allows a DTE to belong to one or more CUGs, and originate calls to DTE devices in the open part of the network (DTE devices not belonging to any CUGs), and DTE devices belonging to incoming access CUGs. If the DTE has not subscribed to outgoing access, the outgoing packets must contain a valid CUG membership selection facility. If not present, the local DCE defaults to the preferential CUG, or rejects the call if a preferential CUG is not specified.
When a DTE wishes to only initiate outgoing calls, it initiates incoming calls barred. With this CUG option subscribed to, a subscriber DTE is permitted to only originate calls but not receive calls within the CUG. The DCE will clear an incoming call before it reaches the DTE.
If a DTE subscribes to the outgoing calls barred option, it is permitted to receive calls but not originate calls within the CUG. An attempted outgoing call will be cleared by the DCE, which in turn will notify the DTE of its actions.
When you implement X.25 CUG service, you get additional X.25 access protection. You can create a private subnetwork and thus control your DTE devices more closely by subscribing the DTE devices to a set of CUGs and restricting access.
You can control CUG access type by implementing either plain CUG access where communication only occurs within your CUG, or full PDN access where communication is more extensive over the network.
X.25 CUG service can be applied to X.25 calls needing protocol translation.
For descriptions of supported MIBs and how to use MIBs, see the Cisco MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
Answers to the following questions, will help you determine how to set up your CUG service and CUGs:
See the following sections for a selection of configuration tasks for the X.25 CUGs feature:
You must establish X.25 DCE encapsulation and X.25 CUG service on the interface to enable this feature. Within the x25 subscribe cug-service command, establish the type of CUG public access (incoming or outgoing) you want. If you do not enter this command, the default will be enabled.
To set up the individual CUGs, use the x25 subscribe local-cug command to specify each local CUG and map it to a network CUG, setting the access properties of the local CUG---no-incoming, no-outgoing, preferential, all, or none---at the same time.
To configure X.25 CUG service, access and properties, use the following commands:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)#interface number | Selects the interface to be configured. | ||
| Router(config-if)#encapsulation x25 dce | Enables X.25 DCE network operation. | ||
| Router(config-if)#x25 subscribe cug-service [incoming-access | outgoing-access] | Enables and controls standard CUG behavior on an X.25 DCE interface. | ||
| Router(config-if)#x25 subscribe local-cug number network-cug number [no-incoming | no-outgoing | preferential] | Maps the desired local CUG number to its corresponding network CUG. |
With this POP configuration of no individual CUG subscriptions, the POP is a member of the open network. Even though it does not have a CUG attached, you must configure CUG security on it to ensure that the rest of your network remains secure. The POP has CUG incoming access and outgoing access permitted---the least restrictive setting. The POP will allow calls that do not require CUG authorization to and from the open network, but will refuse any CUG specified calls because the POP does not belong to a CUG. A call from an intranetwork connection with no CUG selected is permitted as incoming access from the open network, but a call that requires CUG access will be refused.
To configure a POP with no CUG access, use the following commands:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)#interface number | Selects the interface to be configured. | ||
| Router(config-if)#encapsulation x25 dce | Enables X.25 DCE network operation. | ||
| Router(config-if)#x25 subscribe cug-service incoming-access outgoing-access | Permits incoming and outgoing CUG access on an X.25 DCE interface. |
With this POP configuration of having one CUG subscribed, it is important to have no public access permitted on it. This is done by configuring the default setting (no incoming and no outgoing access) for the x25 subscribe cug-service command. When an outgoing call not specifying a CUG is made, the POP assumes the call to be for its one subscribed CUG. An incoming call that does not specify that CUG is rejected. This single CUG configuration assumes the CUG to be the preferential CUG.
To configure a POP with access restricted to one CUG, use the following commands:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)#interface number | Selects the interface to be configured. | ||
| Router(config-if)#encapsulation x25 dce | Enables X.25 DCE network operation. | ||
| Router(config-if)#x25 subscribe cug-service | Sets default behavior on an X.25 DCE interface. | ||
| Router(config-if)#x25 subscribe local-cug number network-cug number [no-incoming | no-outgoing | preferential] | Maps the desired local CUG number to its corresponding network CUG. |
With this POP configuration of multiple CUGs and no public access permitted, the only difference from the previous configuration is that one of the CUGs must be chosen as preferential. If you do not specify a preferential CUG, no calls can be made or accepted. Notice the omission of the keywords with the x25 subscribe cug-service command. This omission enables the default settings of no incoming and no outgoing access.
To configure a POP with multiple CUGs and no public access, use the following commands:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)#interface number | Selects the interface to be configured. | ||
| Router(config-if)#encapsulation x25 dce | Enables X.25 DCE network operation. | ||
| Router(config-if)#x25 subscribe cug-service | Sets default CUG behavior on an X.25 DCE interface. | ||
| Router(config-if)#x25 subscribe local-cug number network-cug number [no-incoming | no-outgoing | preferential] | Maps the desired local CUG number to its corresponding network CUG. | ||
| Router(config-if)#x25 subscribe local-cug number network-cug number [no-incoming | no-outgoing | preferential] | Configures another CUG interface. |
This POP is being configured for public access to members of several CUGs, and to originate and receive calls from the open network (that is, to or from users that do not subscribe to one of the CUGs this POP subscribes to). This is the least restrictive setting. Configuring the POP with multiple CUGs and public access is achieved using the x25 subscribe cug-service command with keywords incoming-access and outgoing-access being added to allow calls to be made and received to and from outside hosts not in the specified CUG network.
To set up the individual CUGs, use the x25 subscribe local-cug command to specify each local CUG and map it to a network CUG, setting the access properties of the local CUG---no-incoming, no-outgoing, preferential, all, or none---at the same time.
An outgoing call may select any of the local CUGs or not. When no CUG is selected, it is assumed the call is intended for the open network. The call will be refused if it specifies a different local CUG to one that the POP is subscribed to. An incoming call may or may not select related network CUGs. If no CUG is selected, the call is accepted as coming from the open network. A call that requires access to a different CUG will be refused
To configure a POP with multiple CUGs and public access, use the following commands:.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)#interface number | Selects the interface to be configured. | ||
| Router(config-if)#encapsulation x25 dce | Enables X.25 DCE network operation. | ||
| Router(config-if)#x25 subscribe cug-service incoming-access outgoing-access | Permits incoming and outgoing CUG access on an X.25 DCE interface. | ||
| Router(config-if)#x25 subscribe local-cug number network-cug number [no-incoming | no-outgoing | preferential] | Maps the desired local CUG number to its corresponding network CUG. | ||
| Router(config-if)#x25 subscribe local-cug number network-cug number [no-incoming | no-outgoing | preferential] | Configures another CUG interface. |
To show current settings of the X.25 CUGs feature, use the show x25 cug (either keyword local-cug or network-cug must be designated) command in EXEC mode. In the following example local CUGs 100, 200, 300, and 5000 are shown mapped to their related network CUGs 11, 22, 33, and 55, respectively, all with incoming and outgoing public access, and with network CUG 55 being set as the preferential:
Router# show x25 cug local-cug X.25 Serial0, 4 CUGs subscribed with incoming and outgoing public access local-cug 100 <-> network-cug 11 local-cug 200 <-> network-cug 22 local-cug 300 <-> network-cug 33 local-cug 5000 <-> network-cug 55, preferential
The debug x25 events command can be used to verify if and when CUG calls are being made, and how the CUGs are behaving. The following example shows messages concerning a DCE rejecting a call because CUG 40 is not configured at the DCE interface, either by design or administrative mistake:
Router# debug x25 events 00:48:33:Serial1:X.25 I R1 Call (14) 8 lci 1024 00:48:33: From (3):111 To (3):444 00:48:33: Facilities:(2) 00:48:33: Closed User Group (basic):40 00:48:33: Call User Data (4):0x01000000 (pad) 00:48:33:X.25 Incoming Call packet, Closed User Group (CUG) protection, selected network CUG not subscribed 00:48:33:Serial1:X.25 O R1 Clear (5) 8 lci 1024 00:48:33: Cause 11, Diag 65 (Access barred/Facility code not allowed)
This section provides the following configuration examples:
In the following example, X.25 CUG service is being subscribed on serial 0, which then permits the subscription to local CUGs (5000, 100, 200, and 300). Subscription to local CUGs cannot be achieved without subscription to X.25 CUG service (although this occurs automatically---with CUG service default settings of no incoming and no outgoing access---the first time you subscribe to a specific CUG using the x25 subscribe local-cug command).
Local CUG 5000 has been designated as the preferential CUG, which means that it will be used when a call with no CUG membership selection was made. These local CUGs all belong to different network identifiers (IDs) (local 5000 = network 55; local 100 = network 11; local 200 = network 22; local 300 = network 33), but they could also subscribe to the same network ID if desired.
Router(config)#interface serial0 Router(config-if)#encapsulation x25 dce Router(config-if)#x25 subscribe cug-service incoming-access outgoing-access Router(config-if)#x25 subscribe local-cug 5000 network-cug 55 preferential Router(config-if)#x25 subscribe local-cug 100 network-cug 11 Router(config-if)#x25 subscribe local-cug 200 network-cug 22 Router(config-if)#x25 subscribe local-cug 300 network-cug 33
In the following example, serial interface 0 is being configured as a POP for a user that has no access to any of the CUGs in the network, but full public access (incoming and outgoing access)---the least restrictive setting.
Router(config)#interface serial0 Router(config-if)#encapsulation x25 dce Router(config-if)#x25 subscribe cug-service incoming-access outgoing-access
In the following example, serial interface 0 is configured as a POP with access only to members of its own CUG and no public access. The POP is being configured for CUG service security using the most restrictive settings (the default) of the x25 subscribe cug-service command---no incoming and no outgoing access permitted. Local CUG 5000, which is associated with network 55, is being subscribed to this POP.
An outgoing call from the DTE may select local CUG 5000 or not. Because there is only one CUG subscribed, its use is implicit and will always select its related network CUG 55. An outgoing call that specifies a different local CUG will be refused. An incoming call must specify network CUG 55, otherwise the call will be refused.
Router(config)#interface serial0 Router(config-if)#encapsulation x25 dce Router(config-if)#x25 subscribe cug-service Router(config-if)#x25 subscribe local-cug 5000 network-cug 55
In the following example, serial interface 0 is being configured as a POP with access to members of several CUGs, using the most restrictive settings (the default) of the x25 subscribe cug-service command---no incoming and no outgoing access permitted. Local CUGs (5000, 100, 200, and 300) are then subscribed to this POP. Local CUG 5000 has been designated as the preferential CUG, which means that it will be used when a call with no CUG membership selection was made.
These local CUGs all belong to different networks (local 5000 = network 55; local 100 = network 11; local 200 = network 22; local 300 = network 33), but they could also subscribe to the same network if desired.
An outgoing call from the DTE may select any of the local CUGs (5000, 100, 200, and 300) or not. Because there is a preferential CUG (5000), its use will be implicit when no CUG is specified. The related network CUG (55) will be selected when switched to an intra-network connection. A call specifying a different local CUG will be refused. An incoming call must select one of the network CUGs (55, 11, 22, or 33), otherwise the call will be refused.
Router(config)#interface serial0 Router(config-if)#encapsulation x25 dce Router(config-if)#x25 subscribe cug-service Router(config-if)#x25 subscribe local-cug 5000 network-cug 55 preferential Router(config-if)#x25 subscribe local-cug 100 network-cug 11 Router(config-if)#x25 subscribe local-cug 200 network-cug 22 Router(config-if)#x25 subscribe local-cug 300 network-cug 33
In the following example, serial interface 0 is being configured as a POP with public access to members of several CUGs, and to originate and receive calls from the open network (that is, to or from users that do not subscribe to one of the CUGs this POP subscribes to).
An outgoing call from the DTE may select any of the local CUGs (1, 2, 3, or 4) or not. When no CUG is selected, it is assumed the call is intended for the open network. When a CUG is selected, the related network CUG will be selected when switched to an intra network connection. The call will be refused if it specifies a different local CUG to one that the POP is subscribed to.
An incoming call to the DTE from an intra network connection may select related network CUGs (101, 202, 303, or 404) or no CUG. If no CUG is selected, the call is accepted as coming from the open network. A call that requires access to a different CUG will be refused.
Router(config)#interface serial0 Router(config-if)#encapsulation x25 dce Router(config-if)#x25 subscribe cug-service incoming-access outgoing-access Router(config-if)#x25 subscribe local-cug 1 network-cug 101 Router(config-if)#x25 subscribe local-cug 2 network-cug 202 Router(config-if)#x25 subscribe local-cug 3 network-cug 303 Router(config-if)#x25 subscribe local-cug 4 network-cug 404
This section documents new commands. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command reference publications.
In Cisco IOS Release 12.0(1)T or later, you can search and filter the output for show and more commands. This functionality is useful when you need to sort through large amounts of output, or if you want to exclude output that you do not need to see.
To use this functionality, enter a show or more command followed by the "pipe" character (|), one of the keywords begin, include, or exclude, and an expression that you want to search or filter on:
command | {begin | include | exclude} regular-expression
Following is an example of the show atm vc command in which you want the command output to begin with the first line where the expression "PeakRate" appears:
show atm vc | begin PeakRate
For more information on the search and filter functionality, refer to the Cisco IOS Release 12.0(1)T feature module titled CLI String Search.
To display information about all or specific (defined by the local or network closed user group (CUG) number) CUGs, use the show x25 cug EXEC command.
show x25 cug {local-cug number | network-cug number}
local-cug | Locally significant CUG identifier. |
number | Local CUG number (0 to 9999). |
network-cug | Network translated CUG identifier. |
number | Network CUG number (0 to 9999). |
EXEC
| Release | Modification |
|---|---|
12.0(7)T | This command was introduced. |
You must designate either local-cug or network-cug with this command. Within these designations you can view all CUGs or a specific CUG defined by its local or network CUG identifier.
The following is sample output from the show x25 cug local-cug command, displaying information about all local CUGs on X.25 serial interface 0. Four CUGs have been subscribed to on serial interface 0, and they all have been configured for incoming and outgoing public access.
Router#show x25 cug local-cug X.25 Serial0, 4 CUGs subscribed with incoming and outgoing public access local-cug 100 <-> network-cug 11 local-cug 200 <-> network-cug 22 local-cug 300 <-> network-cug 33 local-cug 5000 <-> network-cug 55, preferential
The following is sample output from the show x25 cug network-cug command specifically for network number 33 showing local CUG 300 is associated with it:
Router#show x25 cug network-cug 33 network-cug 33 <-> local-cug 300
Table 1 describes the fields shown in the display for the show x25 cug command.
| Field | Description |
|---|---|
X.25 Serial 0 | DCE interface with X.25 CUG service subscription. |
local-cug | Local CUG details. |
network-cug | Network CUG details. |
preferential | Identifies which CUG, if any, is preferential. A single CUG listed for an interface is assumed to be preferential. |
| Command | Description |
Enables and controls standard CUG behavior on an X.25 DCE interface. | |
Configures an interface for CUG subscription. |
To enable and control standard closed user group (CUG) behavior on an X.25 data communications equipment (DCE) interface, use the x25 subscribe cug-service interface configuration command. To disable standard CUG behavior on an X.25 DCE interface, use the no form of this command.
x25 subscribe cug-service [incoming-access | outgoing-access]
incoming-access | (Optional) Allows incoming access from the open network to the data terminating equipment (DTE). |
outgoing-access | (Optional) Allows outgoing access from the DTE to the open network. |
No incoming-access and no-outgoing-access. (This is the most restrictive setting.)
Interface configuration
| Release | Modification |
|---|---|
12.0(7)T | This command was introduced. |
When entering this command, specify either incoming-access or outgoing-access, unless you intend to have neither incoming nor outgoing access on that interface.
This command assumes that an X.25 network connection is being implemented and observes rules defined by X.25 and X.301 for CUG access. This command is enabled on a per-interface basis. Use this command to modify existing specified options without otherwise affecting the CUGs already defined. The following restrictions apply:
The following example subscribes both incoming and outgoing CUG service on the interface:
Router(config)#interface serial0 Router(config-if)#encapsulation x25 dce Router(config-if)#x25 subscribe cug-service incoming-access outgoing-access
| Command | Description |
Displays information about CUG services. | |
Configures an interface for CUG subscription. | |
x25 map | (With CUG encoding option.) Sets up the LAN protocols-to-remote host mapping. |
x25 facility | (With the CUG keyword.) Forces facilities on a per-call basis for calls originated by the router (switched calls are not affected). |
To configure a data circuit-terminating equipment (DCE) X.25 interface for a specific closed user group (CUG) subscription, use the x25 subscribe local-cug interface configuration command. To disable the interface for a specific CUG subscription, use the no form of this command.
x25 subscribe local-cug number network-cug number [no-incoming | no-outgoing | preferential]
local-cug | Locally significant CUG identifier. |
number | Specific local CUG number (0 to 9999). |
network-cug | Network translated CUG identifier. |
number | Specific network CUG number (0 to 9999). |
no-incoming | |
no-outgoing | (Optional) Calls from DTE barred within the specified CUG, unless x25 subscribe cug-service outgoing-access is configured. |
preferential |
Incoming and outgoing access. (Preferential - if this is the only CUG specified on the interface.)
Interface configuration
| Release | Modification |
|---|---|
12.0(7)T | This command was introduced. |
The first x25 subscribe local-cug command in a group of configurations will automatically enable CUG service behavior on the interface, if it is not already enabled, with the default settings of no public access.
A CUG number only has local significance. Because CUG service is a cooperative process between the network attachments (DCE devices), the local CUG number may need to be translated into a number that is significant to the network as a whole. For instance, two DTE devices may use CUG numbers 1 and 5 to refer to the global CUG number 1043 of the network. In this instance, both DCE devices would be configured to translate between the local CUG number of their DTE and the network CUG number. Duplicate network CUG identifiers are permitted for different local CUG identifiers.
A DTE subscription to a CUG that also includes the no-incoming option prevents incoming calls on that CUG (however, the DTE may still receive calls within other CUGs to which it is subscribed, or from the open network if incoming public access is subscribed).
CUG subscription of a DTE will not permit an outgoing call (call request) from the CUG if the no-outgoing option is configured.
The CUG will be assumed to be set to "preferential" if there is only one CUG subscribed on that interface.
The following example subscribes local CUGs 5000, 100, 200, and 300 to networks 55, 11, 22, and 33, respectively, with local CUG 5000 being set as the preferential CUG:
Router(config)#interface serial0 Router(config-if)#encapsulation x25 dce Router(config-if)#x25 subscribe cug-service incoming-access outgoing-access Router(config-if)#x25 subscribe local-cug 5000 network-cug 55 preferential Router(config-if)#x25 subscribe local-cug 100 network-cug 11 Router(config-if)#x25 subscribe local-cug 200 network-cug 22 Router(config-if)#x25 subscribe local-cug 300 network-cug 33
| Command | Description |
Displays information about CUG services. | |
Enables and controls standard CUG behavior on an X.25 DCE interface. | |
x25 map | (With CUG encoding option.) Sets up the LAN protocols-to-remote host mapping. |
x25 facility | (With the CUG keyword.) Forces facilities on a per-call basis for calls originated by the router (switched calls are not affected). |
To display information about X.25 traffic, use one of the following debug x25 commands. The commands allow you to display all information or an increasingly restrictive part of the information.
 | Caution This command is processor intensive and can render the router useless. Use this command only when the aggregate of all reportable X.25 traffic is fewer than five packets per second (pps). The generic forms of this command should be restricted to low-speed, low-usage links running at less than 19.2 kbps. Because the debug x25 vc command and the debug x25 vc events command display traffic for only a small subset of virtual circuits, they are safer to use under heavy traffic conditions, as long as events for that virtual circuit are fewer than 25 pps. |
To display information about all X.25 traffic, including traffic for X.25, Connection-Mode Network Service (CMNS), and X.25 over TCP (XOT) services, use the debug x25 EXEC command (default all). Use the no form of this command to disable debugging output.
[no] debug x25To display information about all X.25 traffic except data and resource record packets, use the debug x25 events command. Use the no form of this command to disable debugging output.
[no] debug x25 eventsTo display information about a specific X.25 service class, use the following form of the debug x25 EXEC command. Use the no form of this command to disable debugging output.
[no] debug x25 [only | cmns | xot] [events | all]To display information about a specific X.25 or CMNS context, use the following form of the debug x25 EXEC command. Use the no form of this command to disable debugging output.
[no] debug x25 interface {serial-interface | cmns-interface mac mac-address} [events | all]To display information about a specific X.25 or CMNS virtual circuit, use the following form of the debug x25 EXEC command. Use the no form of this command to disable debugging output.
[no] debug x25 interface {serial-interface | cmns-interface mac mac-address} vc numberTo display information about traffic for all virtual circuits using a given number, use the following form of the debug x25 EXEC command. The no form of this command removes the filter for a particular virtual circuit from the debug x25 all or debug x25 events output. Use the no form of this command to disable debugging output.
[no] debug x25 vc number [events | all]To display information about traffic to or from a specific XOT host, use the following form of the debug x25 xot EXEC command. Use the no form of this command to disable debugging output.
[no] debug x25 xot [remote ip-address [port number]] [local ip-address [port number]]Use the debug x25 EXEC command with the aodi keyword to display information about an interface running PPP over an X.25 session. The no form of this command disables debugging output. Use the no form of this command to disable debugging output.
[no] debug x25 aodi
events | (Optional) Displays all traffic except Data and Receiver Ready (RR) packets. |
all | (Optional) Displays all traffic. |
only | cmns | xot | (Optional) Displays information about the specified services: X.25 only, CMNS, or XOT. |
serial-interface | X.25 serial interface. |
cmns-interface mac mac-address | MAC address of the CMNS interface and remote host. The interface type can be Ethernet, Token Ring, or FDDI. |
vc number | Virtual circuit number, in the range 1 to 4095. |
remote ip-address [port number] | (Optional) Remote IP address and, optionally, a port number in the range 1 to 65535. |
local ip-address [port number] | (Optional) Local host IP address and, optionally, a port number in the range 1 to 65535. |
aodi | Causes the debug x25 command to display Always On/Dynamic ISDN (AO/DI) events and processing information. |
all
| Release | Modification |
|---|---|
10.0 | This command was introduced. |
12.0(5)T | For DNS-based X.25 routing, additional functionality was added to the debug x25 events command to describe the events occurring while resolving the X.25 address to an IP address using a DNS server. The debug domain command can be used along with debug x25 events to observe the whole DNS-based X.25 routing data flow. (For more details, see "debug x25 events for DNS-Based X.25 Routing" in the "Examples" section.) |
12.0(7)T | For the X.25 CUGs feature, functionality was added to the debug x25 events command to describe events occurring during CUG activity. (For more details, see "debug x25 events for X.25 CUGs" in the "Examples" section.) |
This command is particularly useful for diagnosing problems encountered when placing calls. The debug x25 all output includes data, control messages, and flow control packets for all virtual circuits of the router.
All debug x25 command forms can take either the events or all keyword. The keyword all is the default and causes all packets meeting the other debug criteria to be reported. The keyword events omits reports of any Data or Receiver Ready (RR) flow control packets; the normal flow of data and RR packets is commonly large and less interesting to the user, so event reporting can significantly decrease the processor load induced by debug reporting.
The debug x25 interface command is useful for diagnosing problems encountered with a single X.25 or CMNS host or virtual circuit.
Because no interface is specified by the debug x25 vc command, traffic on any virtual circuit that has the specified number is reported.
Virtual circuit zero (vc 0) cannot be specified. It is used for X.25 service messages, such as RESTART packets, not virtual circuit traffic. Service messages can be monitored only when no virtual circuit filter is used.
The debug x25 xot output allows you to restrict the debug output reporting to XOT traffic for one or both hosts or host/port combinations. Because each XOT virtual circuit uses a unique TCP connection, an XOT debug request that specifies both host addresses and ports will report traffic only for that virtual circuit. Also, you can restrict reporting to sessions initiated by the local or remote router by specifying 1998 for the remote or local port. (XOT connections are received on port 1998.)
Use the debug x25 aodi command to display interface PPP events running over an X.25 session and to debug X.25 connections between a client and server configured for AO/DI.
The following is sample output from the debug x25 command, displaying output concerning the functions X.25 restart, call setup, data exchange, and clear:
Router# debug x25 Serial0: X.25 I R/Inactive Restart (5) 8 lci 0 Cause 7, Diag 0 (Network operational/No additional information) Serial0: X.25 O R3 Restart Confirm (3) 8 lci 0 Serial0: X.25 I P1 Call (15) 8 lci 1 From(6): 170091 To(6): 170090 Facilities: (0) Call User Data (4): 0xCC000000 (ip) Serial0: X.25 O P3 Call Confirm (3) 8 lci 1 Serial0: X.25 I D1 Data (103) 8 lci 1 PS 0 PR 0 Serial0: X.25 O D1 Data (103) 8 lci 1 PS 0 PR 1 Serial0: X.25 I P4 Clear (5) 8 lci 1 Cause 9, Diag 122 (Out of order/Maintenance action) Serial0: X.25 O P7 Clear Confirm (3) 8 lci 1
Table 2 describes the fields shown in the display.
| Field | Description |
|---|---|
Serial0 | Interface on which the X.25 event occurred. |
X.25 | Type of event this message describes. |
I | Letter indicating whether the X.25 packet was input (I) or output (O) through the interface. |
R3 | State of the service or virtual circuit (VC). Possible values follow: R/Inactive---Packet layer awaiting link layer service R1---Packet layer ready R2---Data terminal equipment (DTE) restart request R3---Data circuit-terminating equipment (DCE) restart indication
P/Inactive---VC awaiting packet layer service P1---Idle P2---DTE waiting for DCE to connect CALL P3---DCE waiting for DTE to accept CALL P4---Data transfer P5---CALL collision P6---DTE clear request P7---DCE clear indication
D/Inactive---VC awaiting setup D1---Flow control ready D2---DTE reset request D3---DCE reset indication See Annex B of the ITU-T Recommendation X.25 for more information on these states. |
Restart | The type of X.25 packet. Possible values follow:
|
(5) | Number of bytes in the packet. |
8 | Modulo of the virtual circuit. Possible values are 8 or 128. |
lci 0 | VC number. See Annex A of the ITU-T Recommendation X.25 for information on VC assignment. |
Cause 7 | Code indicating the event that triggered the packet. The Cause field can only appear in entries for Clear, Reset, and Restart packets. Possible values for the Cause field can vary, depending on the type of packet. Refer to the "X.25 Cause and Diagnostic Codes" appendix in the Cisco IOS Release 12.0 Debug Command Reference publication for an explanation of these codes. |
Diag 0 | Code providing an additional hint as to what, if anything, went wrong. The Diag field can only appear in entries for Clear, Diagnostic (as "error 0"), Reset, and Restart packets. Refer to the "X.25 Cause and Diagnostic Codes" appendix in the Cisco IOS Release 12.0 Debug Command Reference publication for an explanation of these codes. |
(Network operational/ | The standard explanations of the Cause and Diagnostic codes (cause/diag). |
The following example shows a sequence of increasingly restrictive debug x25 commands:
Router# debug x25 X.25 packet debugging is on Router# debug x25 events X.25 special event debugging is on Router# debug x25 interface serial 0 X.25 packet debugging is on X.25 debug output restricted to interface Serial0 Router# debug x25 vc 1024 X.25 packet debugging is on X.25 debug output restricted to VC number 1024 Router# debug x25 interface serial 0 vc 1024 X.25 packet debugging is on X.25 debug output restricted to interface Serial0 X.25 debug output restricted to VC number 1024 Router# debug x25 interface serial 0 vc 1024 events X.25 special event debugging is on X.25 debug output restricted to interface serial 0 X.25 debug output restricted to VC number 1024
The following examples show the normal sequence of events for both the AO/DI client and server sides:
Router# debug x25 aodi PPP-X25: Virtual-Access1: Initiating AODI call request PPP-X25: Bringing UP X.25 AODI VC PPP-X25: AODI Client Call Confirm Event Received PPP-X25: Cloning interface for AODI is Di1 PPP-X25: Queuing AODI Client Map Event PPP-X25: Event:AODI Client Map PPP-X25: Created interface Vi2 for AODI service PPP-X25: Attaching primary link Vi2 to Di1 PPP-X25: Cloning Vi2 for AODI service using Di1 PPP-X25: Vi2: Setting the PPP call direction as OUT PPP-X25: Vi2: Setting vectors for RFC1598 operation on BRI3/0:0 VC 0 PPP-X25: Vi2: Setting the interface default bandwidth to 10 Kbps PPP-X25: Virtual-Access2: Initiating AODI call request PPP-X25: Bringing UP X.25 AODI VC PPP-X25: AODI Client Call Confirm Event Received
Router# debug x25 aodi PPP-X25: AODI Call Request Event Received PPP-X25: Event:AODI Incoming Call Request PPP-X25: Created interface Vi1 for AODI service PPP-X25: Attaching primary link Vi1 to Di1 PPP-X25: Cloning Vi1 for AODI service using Di1 PPP-X25: Vi1: Setting vectors for RFC1598 operation on BRI3/0:0 VC 1 PPP-X25: Vi1: Setting the interface default bandwidth to 10 Kbps PPP-X25: Binding X.25 VC 1 on BRI3/0:0 to Vi1
The following example of the debug x25 events command shows output related to the X.25 CUGs feature. It shows messages concerning a DCE rejecting a call because the selected network CUG had not been subscribed to by the caller.
Router# debug x25 events 00:48:33:Serial1:X.25 I R1 Call (14) 8 lci 1024 00:48:33: From (3):111 To (3):444 00:48:33: Facilities:(2) 00:48:33: Closed User Group (basic):40 00:48:33: Call User Data (4):0x01000000 (pad) 00:48:33:X.25 Incoming Call packet, Closed User Group (CUG) protection, selected network CUG not subscribed 00:48:33:Serial1:X.25 O R1 Clear (5) 8 lci 1024 00:48:33: Cause 11, Diag 65 (Access barred/Facility code not allowed)
The following example of the debug x25 events command shows output related to the DNS-Based X.25 Routing feature. It shows messages concerning access of the DNS server. In the following example, nine alternate addresses for one XOT path are entered in the DNS server database. All nine addresses are returned to the host cache of the router by the DNS server. However, only six addresses will be used during the XOT switch attempt, because this is the limit that XOT allows.
Router# debug x25 events 00:18:25:Serial1:X.25 I R1 Call (11) 8 lci 1024 00:18:25: From (0): To (4):444 00:18:25: Facilities:(0) 00:18:25: Call User Data (4):0x01000000 (pad) 00:18:25:X.25 host name sent for DNS lookup is "444" 00:18:26:%3-TRUNCATE_ALT_XOT_DNS_DEST:Truncating excess XOT addresses (3) returned by DNS 00:18:26:DNS got X.25 host mapping for "444" via network 00:18:32:[10.1.1.8 (pending)]:XOT open failed (Connection timed out; remote host not responding) 00:18:38:[10.1.1.7 (pending)]:XOT open failed (Connection timed out; remote host not responding) 00:18:44:[10.1.1.6 (pending)]:XOT open failed (Connection timed out; remote host not responding) 00:18:50:[10.1.1.5 (pending)]:XOT open failed (Connection timed out; remote host not responding) 00:18:56:[10.1.1.4 (pending)]:XOT open failed (Connection timed out; remote host not responding) 00:20:04:[10.1.1.3,1998/10.1.1.3,11007]:XOT O P2 Call (17) 8 lci 1 00:20:04: From (0): To (4):444 00:20:04: Facilities:(6) 00:20:04: Packet sizes:128 128 00:20:04: Window sizes:2 2 00:20:04: Call User Data (4):0x01000000 (pad) 00:20:04:[10.1.1.3,1998/10.1.1.3,11007]:XOT I P2 Call Confirm (11) 8 lci 1 00:20:04: From (0): To (0): 00:20:04: Facilities:(6) 00:20:04: Packet sizes:128 128 00:20:04: Window sizes:2 2 00:20:04:Serial1:X.25 O R1 Call Confirm (5) 8 lci 1024 00:20:04: From (0): To (0): 00:20:04: Facilities:(0)
| Command | Description |
debug ppp bap | Displays general BACP transactions. |
debug ppp bap negotiation | Displays general BACP transactions, as well as successive steps in negotiations between peers. |
debug ppp multilink | Displays information about important multilink events. |
debug ppp multilink negotiation | Displays information about important multilink events and events affecting multilink groups controlled by BACP. |
call request---An X.25 packet sent from a DTE (subscriber) to its DCE (network attachment) that initiates a connection to a destination DTE.
CUG--- closed user group. An X.25 network service whereby the various subscribers (DTE devices) can be segregated into private subnetworks that limit incoming or outgoing access. A DTE may subscribe to zero, one, or more CUGs. A DTE that does not subscribe to a CUG is considered in the open part of the network. This means that a DTE must contract with its network service provider to obtain membership in each restricted subnetwork (that is, a set of CUGs).
DCE---data circuit-terminating equipment. Devices and connections of a communications network that comprise the network end of the user-to-network interface (for example, modem). The DCE provides a physical connection to the network, forwards traffic, and provides a clocking signal used to synchronize data transmission between DCE and DTE devices.
DTE---data terminal equipment. A device (for example, computer, protocol translator, or multiplexer) at the user end of a user-network interface that serves as a data source, destination, or both. The DTE connects to a data network through a DCE device (for example, modem) and typically uses clocking signals generated by the DCE. A network identifies each attached subscriber (DTE) by assigning an X.121 address.
incoming call---An X.25 packet sent from a DCE (network attachment) to its DTE (subscriber) that presents a connection requested by the source DTE.
PAD---packet assembler/disassembler. A device used to connect simple devices (like character-mode terminals) that do not support the full functionality of a particular protocol to a network. PADs buffer data and assemble and disassemble packets sent to such end devices.
PDN---public data network. A network operated either by a government (as in Europe) or by a private concern to provide computer communications to the public, usually for a fee. PDNs enable small organizations to create a WAN without all the equipment costs of long-distance circuits.
POP---point of presence. A physical location where an interexchange carrier installed equipment to interconnect with a local exchange carrier (LEC).
QLLC---Qualified Logical Link Control. Data link layer protocol defined by IBM that allows SNA data to be transported across X.25 networks.
SVC---switched virtual circuit. Virtual circuit that is dynamically established on demand and is torn down when transmission is complete. SVCs are used in situations where data transmission is sporadic. Called a switched virtual connection in ATM terminology.
X.121---A 14-digit address that directs calls to a unique X.25 element/device.
XOT---X.25 over TCP.
Posted: Fri Dec 10 19:06:54 PST 1999
Copyright 1989-1999©Cisco Systems Inc.