Downloads |
Table Of Contents
Incoming and Outgoing Access CUGs
Incoming and Outgoing Calls Barred within a CUG
Supported Standards, MIBs, and RFCs
Configuring X.25 CUG Service, Access, and Properties
Configuring a POP with No CUG Access
Configuring a POP with Access Restricted to One CUG
Configuring a POP with Multiple CUGs and No Public Access
Configuring a POP with Multiple CUGs and Public Access
Troubleshooting Tips for X.25 CUG Service
X.25 CUG Service, Access, and CUG Properties
POP with Access Restricted to One CUG
POP with Multiple CUGs and no Public Access
POP with Multiple CUGs and Public Access
X.25 Closed User Groups
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:
•
Supported Standards, MIBs, and RFCs
Feature Overview
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.
A CUG is a collection of DTE devices for which the network controls access between two members and between a member and a non-member. An X.25 network can support up to 10,000 CUGs (numbered between 0 and 9999), each of which can have any number of member DTE devices. An individual DTE becomes a member of a specific network CUG by subscription. The subscription data includes the local number the DTE will use to identify the network CUG (which may or may not be the same as the network number, as determined by network administration and the DTE device's requirements), and any restriction that prohibits the DTE from placing a call within the CUG or, conversely, prohibits the network from presenting a call within the CUG to the DTE.
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.
CUGs are a network service to allow various network subscribers (DTE devices) to be segregated into private subnetworks with limited incoming or outgoing access, which means that a DTE must obtain membership from its network service (POP) for the set of CUGs it needs access to. A DTE may subscribe to none, one, or several CUGs at the same time. A DTE that does not require CUG membership for access is considered to be in the open part of the network. Each CUG typically permits subscribing users to connect to each other, but precludes connections with non-subscribing DTE devices.
However, CUG behavior is highly configurable. For instance, a CUG configuration may subscribe a DTE to a given CUG, but bar it from originating calls within the CUG or, conversely, bar it from receiving calls identified as being within the CUG. CUG configuration can also selectively permit the DTE to originate calls to a DTE on the open network, or permit the DTE to receive calls from a DTE on the open network.
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.
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.
Note
Figure 1 DTE Devices A, B, C, and D Connecting to CUGs 1 and 2 over a PDN
Point of Presence
X.25 is not a POP by default, and POP behavior does not automatically enforce CUG security. Within PDNs, all devices are connected by POPs, which are open entry points into a network and, as such, pose a potential security risk.
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.
Note
CUG Membership Selection
CUG membership selection occurs from the calling DTE in an outgoing (call request) packet to specify the CUG membership selected for the call. CUG membership selection is requested or received by a DTE only after the DTE has subscribed to one or more of the following facilities:
•
•
•
Preferential CUGs
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:
•
•
•
•
Incoming and Outgoing Access CUGs
CUG service with incoming access allows you to receive incoming calls from the open part of the network, and from DTE devices belonging to other outgoing access CUGs. If the DTE does not subscribe to incoming access, any incoming call without the CUG membership selection facility will not be accepted.
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.
Incoming and Outgoing Calls Barred within a CUG
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.
Benefits
Additional Security
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.
Access Control
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.
Protocol Translation
X.25 CUG service can be applied to X.25 calls needing protocol translation.
Restrictions
•
•
Related Documents
•
•
Supported Platforms
•
•
•
•
•
•
•
•
•
Supported Standards, MIBs, and RFCs
Standards
•
•
•
•
•
•
•
MIBs
•
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.
RFCs
•
Prerequisites
Answers to the following questions, will help you determine how to set up your CUG service and CUGs:
•
If so, configure thex25 subscribe cug-service incoming-access command on the DCE, so that the CUG service allows incoming calls to the DTE.
•
If so, configure the x25 subscribe cug-service outgoing-access command on the DCE, so that the CUG service allows public outgoing calls from the DTE to the open network.
•
If so, configure the x25 subscribe local-cug command for mapping the local CUG to the network CUG for the same CUG entity. To obtain full access to the PDN, the CUG service will need to be subscribed to both incoming and outgoing access.
If you want a secure CUG with no access to the PDN, subscribe the CUG to no incoming or outgoing access, and configure it to only communicate with other attachments within CUGs that it has defined.
After establishing that you want PDN CUG access, you must then answer these questions:
•
The default is set for users to be able to place calls. If you do not want this setting, use the no-outgoing keyword.
•
The default is set for users to be able to receive calls. If you do not want this setting, use the no-incoming keyword.
•
If so, use the preferential keyword.
Configuration Tasks
See the following sections for a selection of configuration tasks for the X.25 CUGs feature:
•
•
•
•
•
Configuring X.25 CUG Service, Access, and Properties
Note
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:
Configuring a POP with No CUG Access
CautionThis configuration is critical to enforce full CUG security on your network. You must conduct this configuration on every POP in your network. If you do not configure this for all POPs in your network you will not have a secure network, which could result in a security breach.
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:
Configuring a POP with Access Restricted to One CUG
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:
Configuring a POP with Multiple CUGs and No Public Access
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:
Configuring a POP with Multiple CUGs and Public Access
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:
.
Verifying X.25 CUG Service
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-cugX.25 Serial0, 4 CUGs subscribed with incoming and outgoing public accesslocal-cug 100 <-> network-cug 11local-cug 200 <-> network-cug 22local-cug 300 <-> network-cug 33local-cug 5000 <-> network-cug 55, preferentialTroubleshooting Tips for X.25 CUG Service
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 events00:48:33:Serial1:X.25 I R1 Call (14) 8 lci 102400:48:33: From (3):111 To (3):44400:48:33: Facilities:(2)00:48:33: Closed User Group (basic):4000: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 subscribed00:48:33: Serial1:X.25 O R1 Clear (5) 8 lci 102400:48:33: Cause 11, Diag 65 (Access barred/Facility code not allowed)Configuration Examples
This section provides the following configuration examples:
•
•
•
•
X.25 CUG Service, Access, and CUG Properties
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 serial0Router(config-if)# encapsulation x25 dceRouter(config-if)# x25 subscribe cug-service incoming-access outgoing-accessRouter(config-if)# x25 subscribe local-cug 5000 network-cug 55 preferentialRouter(config-if)# x25 subscribe local-cug 100 network-cug 11Router(config-if)# x25 subscribe local-cug 200 network-cug 22Router(config-if)# x25 subscribe local-cug 300 network-cug 33POP with No CUG Access
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 serial0Router(config-if)# encapsulation x25 dceRouter(config-if)# x25 subscribe cug-service incoming-access outgoing-accessPOP with Access Restricted to One CUG
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 serial0Router(config-if)# encapsulation x25 dceRouter(config-if)# x25 subscribe cug-serviceRouter(config-if)# x25 subscribe local-cug 5000 network-cug 55POP with Multiple CUGs and no Public Access
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 serial0Router(config-if)# encapsulation x25 dceRouter(config-if)# x25 subscribe cug-serviceRouter(config-if)# x25 subscribe local-cug 5000 network-cug 55 preferentialRouter(config-if)# x25 subscribe local-cug 100 network-cug 11Router(config-if)# x25 subscribe local-cug 200 network-cug 22Router(config-if)# x25 subscribe local-cug 300 network-cug 33POP with Multiple CUGs and Public Access
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 serial0Router(config-if)# encapsulation x25 dceRouter(config-if)# x25 subscribe cug-service incoming-access outgoing-accessRouter(config-if)# x25 subscribe local-cug 1 network-cug 101Router(config-if)# x25 subscribe local-cug 2 network-cug 202Router(config-if)# x25 subscribe local-cug 3 network-cug 303Router(config-if)# x25 subscribe local-cug 4 network-cug 404Command Reference
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.
show x25 cug
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}
Syntax Description
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).
Command Modes
EXEC
Command History
Usage Guidelines
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.
Examples
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-cugX.25 Serial0, 4 CUGs subscribed with incoming and outgoing public accesslocal-cug 100 <-> network-cug 11local-cug 200 <-> network-cug 22local-cug 300 <-> network-cug 33local-cug 5000 <-> network-cug 55, preferentialThe 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 33network-cug 33 <-> local-cug 300describes the fields shown in the display for the show x25 cug command.
Related Commands
Enables and controls standard CUG behavior on an X.25 DCE interface.
Configures an interface for CUG subscription.
x25 subscribe cug-service
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]
no x25 subscribe cug-service [incoming-access | outgoing-access]
Syntax Description
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.
Default
No incoming-access and no-outgoing-access. (This is the most restrictive setting.)
Command Modes
Interface configuration
Command History
Usage Guidelines
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:
•
•
•
Examples
The following example subscribes both incoming and outgoing CUG service on the interface:
Router(config)# interface serial0Router(config-if)# encapsulation x25 dceRouter(config-if)# x25 subscribe cug-service incoming-access outgoing-accessRelated Commands
x25 subscribe local-cug
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]
no x25 subscribe local-cug number network-cug number [no-incoming | no-outgoing | preferential]
Syntax Description
Default
Incoming and outgoing access. (Preferential - if this is the only CUG specified on the interface.)
Command Modes
Interface configuration
Command History
Usage Guidelines
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.
Examples
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 serial0Router(config-if)# encapsulation x25 dceRouter(config-if)# x25 subscribe cug-service incoming-access outgoing-accessRouter(config-if)# x25 subscribe local-cug 5000 network-cug 55 preferentialRouter(config-if)# x25 subscribe local-cug 100 network-cug 11Router(config-if)# x25 subscribe local-cug 200 network-cug 22Router(config-if)# x25 subscribe local-cug 300 network-cug 33Related Commands
Debug Commands
This section documents the modifed debug x25 command related to the X.25 CUGs feature. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command reference publications.
debug x25
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.
CautionThis 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 x25
To 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 events
To 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 number
[events | all]To 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]]
[events | all]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
Syntax Description
Default
all
Command History
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.)
Usage Guidelines
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.
Examples
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 x25Serial0: X.25 I R/Inactive Restart (5) 8 lci 0Cause 7, Diag 0 (Network operational/No additional information)Serial0: X.25 O R3 Restart Confirm (3) 8 lci 0Serial0: X.25 I P1 Call (15) 8 lci 1From(6): 170091 To(6): 170090Facilities: (0)Call User Data (4): 0xCC000000 (ip)Serial0: X.25 O P3 Call Confirm (3) 8 lci 1Serial0: X.25 I D1 Data (103) 8 lci 1 PS 0 PR 0Serial0: X.25 O D1 Data (103) 8 lci 1 PS 0 PR 1Serial0: X.25 I P4 Clear (5) 8 lci 1Cause 9, Diag 122 (Out of order/Maintenance action)Serial0: X.25 O P7 Clear Confirm (3) 8 lci 1describes the fields shown in the display.
