The access list number is used for both incoming Transmission Control Protocol (TCP) access and incoming packet assembler/disassembler (PAD) access.

In the case of TCP access, the access server uses the Internet Protocol (IP) access list defined with the access-list command.

For incoming PAD connections, the same numbered X.29 access list is referenced. If you only want to have access restrictions on one of the protocols, you can create an access list that permits all addresses for the other protocol.

Each SVC or PVC supported by the XOT service uses a TCP connection to communicate X.25 packets. A TCP connection is uniquely identified by the data quartet: remote IP address, remote TCP port, local IP address, and local TCP port. This command form is used to forcibly disrupt service on an individual XOT circuit.

XOT connections are sent to TCP port 1998, so XOT connections originated by the router will have that remote port number, and connections received by the router will have that local port number.

This command first appeared prior to Cisco IOS Release 10.0.The dte, dce, multi and protocol argument forms first appeared in Cisco IOS Release 10.3

LAPB encapsulations are appropriate only for private connections, where you have complete control over both ends of the link. Connections to X.25 networks should use an X.25 encapsulation configuration, which operates the X.25 Layer 3 protocol above a LAPB Layer 2.

One end of the link must be a logical DCE, and the other end a logical DTE. (This assignment is independent of the interface's hardware DTE or DCE identity.)

Both ends of the LAPB link must specify the same protocol encapsulation.

LAPB encapsulation is supported on serial lines configured for dial-on-demand routing (DDR). It can be configured on DDR synchronous serial and Integrated Services Digital Network (ISDN) interfaces and on DDR dialer rotary groups. It is not supported on asynchronous dialer interfaces.

A single-protocol LAPB encapsulation exchanges datagrams of the given protocol, each in a separate LAPB information frame. You must configure the interface with the protocol-specific parameters needed---for example, a link that carries IP traffic will have an IP address defined for the interface.

A multiprotocol LAPB encapsulation can exchange any or all of the protocols allowed for a LAPB interface. It exchanges datagrams, each in a separate LAPB information frame. Two bytes of protocol identification data precede the protocol data. You need to configure the interface with all the protocol-specific parameters needed for each protocol carried.

Beginning with Cisco IOS Release 11.0, multiprotocol LAPB encapsulation supports transparent bridging. This feature requires use of the encapsulation lapbmulti command followed by the bridge-group command, which identifies the bridge group associated with multiprotocol LAPB encapsulation. This feature does not support use of the encapsulation lapbprotocol command with a bridge keyword.

This command first appeared prior to Cisco IOS Release 10.0. The dte, dce, ddn, bfe and ietf keywords first appeared in Cisco IOS Release 10.3

One end of an X.25 link must be a logical DCE and the other end a logical DTE. (This assignment is independent of the interface's hardware DTE or DCE identity.) Typically, when connecting to a public data network (PDN), the customer equipment acts as the DTE and the PDN attachment acts as the DCE.

Cisco has long supported the encapsulation of a number of datagram protocols, using a standard means when available and a proprietary means when necessary. More recently the IETF adopted a standard, RFC 1356, for encapsulating most types of datagram traffic over X.25. X.25 interfaces use Cisco's traditional method unless explicitly configured for IETF operation; if the ietf keyword is specified, that standard is used unless Cisco's traditional method is explicitly configured. For details see the x25 map command.

If the window size is changed while the protocol is up, the new value takes effect only when the protocol is reset. You will be informed that the new value will not take effect immediately.

When using the LAPB modulo 128 mode (extended mode), you must increase the window parameter k to send a larger number of frames before acknowledgment is required. This increase is the basis for the router's ability to achieve greater throughput on high-speed links that have a low error rate.

The modulo parameter determines which of LAPB's two modes is to be used. The modulo values derive from the fact that basic mode numbers information frames between 0 and 7, whereas extended mode numbers them between 0 and 127. Basic mode is widely available and is sufficient for most links. Extended mode is an optional LAPB feature that may achieve greater throughput on high-speed links that have a low error rate.

The LAPB operating mode may be set on X.25 links as well as LAPB links. The X.25 modulo is independent of the LAPB layer modulo. Both ends of a link must use the same LAPB mode.

When using modulo 128 mode, you must increase the window parameter k to send a larger number of frames before acknowledgment is required. This increase is the basis for the router's ability to achieve greater throughput on high-speed links that have a low error rate.

If the modulo value is changed while the protocol is up, the new value takes effect only when the protocol is reset. You will be informed that the new value will not take effect immediately.

The largest (maximum) value available for the particular interface is the default. The Cisco IOS software dynamically calculates N1 whenever you change the maximum transmission unit (MTU), the L2/L3 modulo, or compression on a LAPB interface.

The Cisco IOS software uses the following formula to determine for the maximum N1 value:

(hardware MTU + LAPB overhead + X.25 overhead + 2 bytes of CRC) * 8

LAPB overhead is 2 bytes for modulo 8 and 3 bytes for modulo 128.

X.25 overhead is 3 bytes for modulo 8 and 4 bytes for modulo 128.

You need not set N1 to an exact value to support a particular X.25 data packet size. The N1 parameter prevents the processing of any huge frames that result from a "jabbering" interface, an unlikely event.

In addition, the various standards bodies specify that N1 be given in bits rather than bytes. While some equipment can be configured in bytes or will automatically adjust for some of the overhead information present, Cisco devices are configured using the true value, in bits, of N1.

You cannot set the N1 parameter to a value less than that required to support an X.25 data packet size of 128 bytes. All X.25 implementations must be able to support 128-byte data packets. Moreover, if you configure N1to be less than 2104 bits, you receive a warning message that X.25 might have problems because some nondata packets can use up to 259 bytes.

You cannot set the N1parameter to a value larger than the default unless the hardware MTU size is first increased.

The X.25 software accepts default packet sizes and calls that specify maximum packet sizes greater than those the LAPB layer supports, but negotiates the calls placed on the interface to the largest value that can be supported. For switched calls, the packet size negotiation takes place end-to-end through the router so the call will not have a maximum packet size that exceeds the capability of either of the two interfaces involved.

The following example shows how to use the question mark (?) command to display the minimum and maximum N1 value. In this example, X.25 encapsulation has both the LAPB and X.25 modulo set to 8. Any violation of this N1 range results in an "Invalid input" error message.

The retransmission timer determines how long a transmitted frame can remain unacknowledged before the LAPB software polls for an acknowledgment. The design of the LAPB protocol specifies that a frame is presumed to be lost if it is not acknowledged within T1; a T1 value that is too small may result in duplicated control information, which can severely disrupt service.

The following example will poll the other end of an active link if it has been 10 seconds since the last frame was received. If the far host has failed, the service will be declared down after n2 tries are timed out.

To enable all packet assembler/disassembler (PAD) commands and connections between PAD devices and access servers, use the service pad global configuration command. Use the no form of this command to disable this service.

To display X.25 Level 3 parameters for LAN interfaces (such as Ethernet or Token Ring) and other information pertaining to Connection-Mode Network Service (CMNS) traffic activity, use the show cmns EXEC command.

The stability of the X.25 protocol requires that some parameters not be changed without a restart of the protocol. Any change to these parameters are held until a restart is sent or received. If any of these parameters changes, the configuration on restart information will be output as well as the values that are currently in effect.

If the state is R2 or R3, the interface is awaiting acknowledgment of a Restart packet.

modulo 8

Modulo value; determines the packet sequence numbering scheme used.

idle 0

Number of minutes the Cisco IOS software waits before closing idle virtual circuits that it originated or accepted.

timer 0

Value of the interface timer, which is zero unless the interface state is R2 or R3.

nvc 1

Default maximum number of simultaneous virtual circuits permitted to and from a single host for a particular protocol.

Window size: input 2, output 2

Default window sizes (in packets) for the interface. The x25 facility interface configuration command can be used to override these default values for the switched virtual circuits originated by the router.

Packet size: input 128, output 128

Default maximum packet sizes (in bytes) for the interface. The x25 facility interface configuration command can be used to override these default values for the switched virtual circuits originated by the router.

Timers: T20 180, T21 200, T22 180, T23 180

Values of the X.25 timers:

T10 through T13 for a DCE device

T20 through T23 for a DTE device

TH0

Packet acknowledgment threshold (in packets). This value determines how many packets are received before an explicit acknowledgment is sent. The default value (0) sends an explicit acknowledgment only when the incoming window is full.

Channels: Incoming-only none

Two-way 5-1024

Outgoing-only none

Displays the virtual circuit ranges for this interface.

RESTARTs 3/2

Shows Restart packet statistics for the interface using the format Sent/Received.

Address of the station to which the router is transmitting on this session. (The address is the MAC address of the interface on which the connection is established, except when Local Acknowledgment or SDLLC is used, in which case the address used by the router is shown as in this example, following the DTE address and separated by a comma.)

SAP=04/04

Other station's and router's (remote/local) service access point (SAP) for this connection. The SAP is analogous to a "port number" on the router and allows for multiple sessions between the same two stations.

State=

Current state of the LLC2 session, which can be any of the following:

ADM---Asynchronous Disconnect Mode---A connection is not established, and either end can begin one.

SETUP---Request to begin a connection has been sent to the remote station, and this station is waiting for a response to that request.

RESET---A previously open connection has been reset because of some error by this station, and this station is waiting for a response to that reset command.

D_CONN---This station has requested a normal, expected end of communications with the remote station, and is waiting for a response to that disconnect request.

ERROR---This station has detected an error in communications and has told the other station about it. This station is waiting for a reply to its posting of this error.

NORMAL---Connection between the two sides is fully established, and normal communication is occurring.

BUSY---Normal communication state exists, except that busy conditions on this station prevent this station from receiving information frames from the other station at this time.

REJECT---Out-of-sequence frame has been detected on this station, and this station has requested that the other resend this information

AWAIT---Normal communication exists, but this station has had a timer expire, and is trying to recover from it (usually by resending the frame that started the timer).

AWAIT_BUSY---A combination of the AWAIT and BUSY states.

AWAIT_REJ---A combination of the AWAIT and REJECT states.

V(S)=5

Sequence number of the next information frame this station will send.

V(R)=5

Sequence number of the next information frame this station expects to receive from the other station.

Last N(R)=5

Last sequence number of this station's transmitted frames acknowledged by the remote station.

Local Window=7

Number of frames this station may send before requiring an acknowledgment from the remote station.

Remote Window=127

Number of frames this station can accept from the remote station.

ack-max=3, n2=8

Value of these parameters, as given in the previous configuration section.

Next timer in 7768

Number of milliseconds before the next timer, for any reason, goes off.

xid-retry timer 0/60000 ....

A series of timer values in the form of next-time/time-between, where "next-time" is the next time, in milliseconds, that the timer will wake, and "time-between" is the time, in milliseconds, between each timer wakeup. A "next-time" of zero indicates that the given timer is not enabled, and will never wake.

CMNS Connections to

CMNS addendum when LLC2 is running with the CMNS protocol contains the following:

Address 1000.5A59.04F9 via Ethernet2---MAC address of remote station.

Protocol is up---Up indicates the LLC2 and X.25 protocols are in a state in which incoming and outgoing Call Requests can be made on this LLC2 connection.

Type and address of the higher-level protocol(s) mapped to the remote host. Bridge maps do not have a higher-level address; all bridge datagrams are sent to the mapped X.121 address. CLNS maps refer to a configured neighbor as identified by the X.121 address.

PERMANENT

Address-mapping type that has been configured for the interface in this entry. Possible values include the following:

CONSTRUCTED---Derived with the DDN or BFE address conversion scheme.

PERMANENT---Map was entered with the x25 map interface configuration command.

PVC---Map was configured with the x25 pvc interface command.

TEMPORARY---A temporary map was created for an incoming unconfigured CMNS connection.

BROADCAST

If any options are configured for an address mapping, they are listed; the example shows a map that is configured to forward datagram broadcasts to the mapped host.

2 VCs:

If the map has any active virtual circuits, they are identified.

3 4*

Identifies the circuit number of the active virtual circuits. The asterisk (*) marks the virtual circuit last used to send data.

Note that a single protocol virtual circuit can be associated with a multiprotocol map.

To examine a particular virtual circuit number, add an LCN argument to the show x25 vc command.

This command displays information about virtual circuits. Virtual circuits may be used for a number of purposes, such as the following:

Encapsulation traffic

Traffic switched between X.25 services (X.25, CMNS and XOT)

PAD traffic

QLLC traffic

The connectivity information displayed will vary according to the traffic carried by the virtual circuit. For multiprotocol circuits, the output varies depending on the number and identity of the protocols mapped to the X.121 address and the encapsulation method selected for the circuit.

Identifies the type of virtual circuit (switched or permanent) and its LCN (also called its "virtual circuit number").

State

State of the virtual circuit (which is independent of the states of other virtual circuits); D1 is the normal ready state. See the International Telecommunication Union Telecommunication Standardization Sector (ITU-T)1 X.25 Recommendation for a description of virtual circuit states.

Interface

Interface or subinterface on which the virtual circuit is established.

Indicates that the X.25 D-bit (Delivery Confirmation) may be used on this circuit (displayed as needed).

Fast select VC

Indicates that the Fast Select facility was present on the incoming call (displayed as needed).

Reverse charged

Indicates reverse charged virtual circuit (displayed as needed).

Window size

Window sizes for the virtual circuit.

Packet size

Maximum packet sizes for the virtual circuit.

PS

Current send sequence number.

PR

Current receive sequence number.

ACK

Last acknowledged incoming packet.

Remote PR

Last receive sequence number received from the other end of the circuit.

RCNT

Count of unacknowledged input packets.

RNR

State of the Receiver Not Ready flag; this field is true if the network sends a Receiver-not-Ready packet.

Window is closed

This line appears if the router cannot transmit any more packets until the X.25 Layer 3 peer has acknowledged some outstanding packets.

P/D state timeouts

Number of times a supervisory packet (Reset or Clear) has been retransmitted.

Timer

A nonzero time value indicates that a control packet has not been acknowledged yet or that the virtual circuit is being timed for inactivity.

Reassembly

Number of bytes received and held for reassembly. Packets with the M-bit set are reassembled into datagrams for encapsulation virtual circuits; switched X.25 traffic is not reassembled (displayed only when values are non-zero).

Held Fragments/Packets

Number of X.25 data fragments to transmit to complete an outgoing datagram, and the number of datagram packets waiting for transmission (displayed only when values are non-zero).

data bytes m/n packets p/q

Total number of data bytes sent (m), data bytes received (n), data packets sent (p), and data packets received (q) since the circuit was established.

Resets t/r

Total number of Reset packets transmitted/received since the circuit was established.

RNRs t/r

Total number of Receiver Not Ready packets transmitted/received since the circuit was established.

REJs t/r

Total number of Reject packets transmitted/received since the circuit was established.

INTs t/r

Total number of Interrupt packets transmitted/received since the circuit was established.

1The ITU-T carries out the functions of the former Consultative Committee for International Telegraph and Telephone (CCITT).

The higher-level protocol and address values that are mapped to the virtual circuit.

Call PID

Identifies the method used for the protocol identification (PID) in the Call User Data (CUD) field. Because PVCs are not set up using a Call packet, this field is not displayed for encapsulation PVCs. The available methods are as follows:

cisco---Cisco's traditional method was used to set up a single protocol virtual circuit.

ietf---The IETF's standard RFC 1356 method was used to set up a single protocol virtual circuit.

Identifies connection status for a switched connection between two PVCs. See Table 48 for PVC status messages.

170093

Identifies the Calling (source) Address of the connection. If a Calling Address Extension was encoded in the call facilities, it is also displayed. If the source host is a CMNS host, its MAC address is also displayed.

170090

Identifies the Called (destination) Address of the connection. If a Called Address Extension was encoded in the call facilities, it is also displayed. If the destination host is a CMNS host, its MAC address is also displayed.

from Serial1

Indicates the direction of the call and the connecting interface.

VC 5

Identifies the circuit type and LCN for the connecting interface. VC indicates an SVC, and PVC indicates a PVC. If the connecting host is a CMNS host, its MAC address is also displayed.

Identifies the Calling (source) Address of the connection. If a Calling Address Extension was encoded in the call facilities, it is also displayed. If the source host is a CMNS host, its MAC address is also displayed.

201700

Identifies the Called (destination) Address of the connection. If a Called Address Extension was encoded in the call facilities, it is also displayed. If the destination host is a CMNS host, its MAC address is also displayed.

from Serial2

Indicates the direction of the call and the connecting interface.

VC 700

Identifies the circuit type and LCN for the connecting interface. VC indicates an SVC and PVC indicates a PVC. If the remote host is a CMNS host, its MAC address is also displayed.

DDN and BFE encapsulations have a default interface address generated from the interface IP address; for proper DDN or BFE operation, this generated X.121 address must not be changed. Standard X.25 encapsulations do not have a default.

When you are connecting to a public data network (PDN), the PDN administrator will assign the X.121 address to be used. Other applications (for example, a private X.25 service), may assign arbitrary X.121 addresses as required by the network and service design. X.25 interfaces that engage in X.25 switching only do not need to assign an X.121 address.

This command first appeared in Cisco IOS Release 11.2 F. It replaces the functionality that was provided by the alias keyword of the x25 route command.

Encapsulation, PAD, and QLLC calls are normally accepted when the destination address is that of the interface (or the zero-length address). Those calls will also be accepted when the destination address matches a configured alias.

An X.25 call may be addressed to the receiving interface; calls addressed to the receiving interface are eligible for acceptance as a datagram encapsulation, PAD or QLLC connection, and may not be routed. In the following example, serial interface 0 is configured with a native address of 0000123 and a destination alias for any address that starts with 1111123. That is, serial interface 0 can accept its own calls and calls for any destination that starts with 1111123.

Prevents the router from participating in emergency mode and from sending address translation information to the BFE device.

yes

Allows the router to participate in emergency mode and to send address translation information to the BFE when the BFE enters emergency mode. This information is obtained from the table created by the x25 remote-red command.

ask

Configures the Cisco IOS software to prompt you to enter the bfe EXEC command.

The following example configures serial interface 0 to require an EXEC command from you before it participates in emergency mode. The host IP address is 21.0.0.12, and the address of the remote BFE unit is 21.0.0.1. When the BFE enters emergency mode, the Cisco IOS software prompts you for the EXEC command bfe enter to direct the router to participate in emergency mode.

Prevents the router from sending address translation information to the Blacker Front End (BFE). If it does not receive address translation information, the BFE cannot open a new connection for which it does not know the address.

Directs the router to wait until it receives a diagnostic packet from the BFE device indicating that the emergency mode window is open. The window is only open when a condition exists that allows the BFE to enter emergency mode. When the diagnostic packet is received, the participation in emergency mode depends on how the router is configured with the x25 bfe-decision command.

The following example configures serial interface 0 to require an EXEC command from you before it participates in emergency mode. The host IP address is 21.0.0.12, and the address of the remote BFE unit is 21.0.0.1. When the BFE enters emergency mode, the Cisco IOS software prompts you for the EXEC command bfe enter to direct the router to participate in emergency mode.

To force facilities on a per-call basis for calls originated by the router (switched calls are not affected), use the x25 facility interface configuration command. To disable a facility, use the no form of this command.

Proposes the packet count for input windows (in-size) and output windows (out-size) for flow control parameter negotiation. Both values must be in the range 1 to 127 and must not be greater than or equal to the value set for the x25 modulo command.

This command is applicable only if you have the X.25 switch configured for an incoming-only virtual circuit range. Incoming is from the perspective of the X.25 DTE. If you do not want any outgoing calls from your DTE, configure both ends to disable the two-way range (set the values of x25 ltc and x25 htc to 0) and configure an incoming-only range. Any incoming-only range must come before (that is, must be numerically less than) any two-way range. Any two-way range must come before any outgoing-only range.

This command is applicable only if you have the X.25 switch configured for an outgoing-only virtual circuit range. Outgoing is from the perspective of the X.25 DTE. If you do not want any incoming calls on your DTE, disable the two-way range (set the values of x25 ltc and x25 htc to 0) and configure an outgoing-only range. Any outgoing-only range must come after (that is, be numerically greater than) any other range.

If you set the queue-size to 0 when using the no x25 hold-queue command, there will be no hold queue limit. While this setting will prevent drops until the router runs out of memory, it is only rarely appropriate. A virtual circuit hold queue value is determined when it is created; changing this parameter will not affect the hold queue limits of the existing virtual circuits.

To start the timer that prevents additional calls to a destination for a given period of time (thus preventing overruns on some X.25 switches caused by Call Request packets), use the x25 hold-vc-timer interface configuration command. To restore the default value for the timer, use the no form of this command.

Only Call Requests that the router originates are held down; routed X.25 Call Requests are not affected by this parameter.

Upon receiving a Clear Request for an outstanding Call Request, the X.25 support code immediately tries another Call Request if it has more traffic to send, and this action might cause overrun problems.

This command is applicable if the X.25 switch is configured for a two-way virtual circuit range. Any two-way virtual circuit range must come after (that is, be numerically larger than) any incoming-only range, and must come before any outgoing-only range.

This feature is useful only for DDN or BFE encapsulations, because only these methods have an IP precedence facility defined to allow the source and destination devices to both use the virtual circuit for traffic of the given IP priority.

Verify that your host does not send nonstandard data in the IP type of service (TOS) field because it can cause multiple wasteful virtual circuits to be created.

Four virtual circuits may be opened based on IP precedence to encapsulate routine, priority, immediate, and all higher precedences.

This command is applicable only if you have the X.25 switch configured for an incoming-only virtual circuit range. Outgoing is from the perspective of the X.25 DTE. If you do not want any incoming calls on your DTE, disable the two-way range (set the values of x25 ltc and x25 htc to 0) and configure an outgoing-only range. Any outgoing-only range must come after (that is, be numerically greater than) any other range.

This command is applicable if you have the X.25 switch configured for two-way virtual circuit range.

This command is applicable only if you have the X.25 switch configured for an outgoing-only virtual circuit range. Outgoing is from the perspective of the X.25 DTE. If you do not want any incoming calls from your DTE, configure the values of x25 loc and x25 hoc and set the values of x25 ltc and x25 htc to 0.

This command is applicable if you have the X.25 switch configured for a two-way virtual circuit range. Any two-way virtual circuit range must come after (that is, be numerically larger than) any incoming-only range, and must come before any outgoing-only range.

Because no defined protocol can dynamically determine LAN protocol-to-remote host mappings, you must enter all the information for each host with which the router may exchange X.25 encapsulation traffic.

When you configure multiprotocol maps, you can specify a maximum of nine protocol and address pairs in an x25 map command. However, you can specify a protocol only once. For example, you can specify the IP protocol and an IP address, but you cannot specify another IP address. If compressedtcp and ip are both specified, the same IP address must be used.

Bridging is supported only if you are using Cisco's traditional encapsulation method. For correct operation, bridging maps must specify the broadcast option.

Since most datagram routing protocols rely on broadcasts or multicasts to send routing information to their neighbors, the broadcast keyword is needed to run such routing protocols over X.25.

Encapsulation maps might also specify that traffic between the two hosts should be compressed, thus increasing the effective bandwidth between them at the expense of memory and computation time. Because each compression virtual circuit requires memory and computation resources, compression must be used with care and monitored to maintain acceptable resource usage and overall performance.

Note The OSPF broadcast mechanism assumes that IP class D addresses are never used for regular traffic over X.25.

You can modify the options of an x25 map command by restating the complete set of protocols and addresses specified for the map, followed by the desired options. To delete a map command, you must also specify the complete set of protocols and addresses; the options can be omitted when deleting a map.

Once defined, a map's protocols and addresses cannot be changed. This requirement exists because the Cisco IOS software cannot determine whether you want to add to, delete from, or modify an existing map's protocol and address specification, or simply mistyped the command. To change a map's protocol and address specification, you must delete it and create a new map.

A given protocol-address pair cannot be used in more than one map on the same interface.

1Bridging traffic is supported only for Cisco's traditional encapsulation method, so a bridge map cannot specify other protocols.2Packet Assembly/Disassembly (PAD) maps are used to configure session and protocol translation access, therefore, this protocol is not available for multiprotocol encapsulation.3Qualified Logical Link Control (QLLC) is not available for multiprotocol encapsulation.

The CMNS map form is obsolete; its function is replaced by the enhanced x25 route command.

Use a PAD map to configure optional X.25 facility use for PAD access. When used with the x25 pad-access interface configuration command, the x25 map pad command restricts incoming PAD access to those statically mapped hosts.

The following example configures an X.25 interface to restrict incoming PAD access to the single mapped host. This example requires that both incoming and outgoing PAD access use the network user identification (NUID) user authentication.

X.25 supports flow control with a sliding window sequence count. The window counter restarts at zero upon reaching the upper limit, which is called the window modulus. Modulo 128 operation is also referred to as extended packet sequence numbering, which allows larger packet windows.

Circuit count from 1 to 8. A maximum of eight virtual circuits can be configured for each protocol-host pair. Protocols that do not tolerate out-of-order delivery, such as encapsulated TCP/IP header compression, will use only one virtual circuit despite this value. The default is 1. Permitting more than one VC may help throughput on slow networks.

When the windows and output queues of all existing connections to a host are full, a new virtual circuit will be opened to the designated circuit count. If a new connection cannot be opened, the data is dropped.

Note The count value specified for x25 nvc affects the default value for the number of VCs. It does not affect the nvc option for any x25 map commands that are configured.

By default, all PAD connection attempts are processed for session creation or protocol translation, subject to the configuration of those functions. If you use the x25 pad-access command, PAD connections are processed only for incoming calls with a source address that matches a statically mapped address configured with the x25 map pad interface configuration command. PAD connections are refused for any incoming calls with a source address that has not been statically mapped.

You no longer need to specify a datagram protocol-to-address mapping before you can set up a PVC; a map is implied from the PVC configuration. Configurations generated by the router will no longer specify a map for encapsulating PVCs.

When configuring a PVC to carry CLNS traffic, use the X.121 address as the subnetwork point of attachment (SNPA) to associate the PVC with a CLNS neighbor configuration. When configuring a PVC to carry transparent bridge traffic, the X.121 address is required to identify the remote host to the bridging function. Other encapsulation PVCs do not require an X.121 address.

You can configure X.25 PVCs in the X.25 switching software. As a result, DTEs that require permanent circuits can be connected to the router acting as an X.25 switch and have a properly functioning connection. X.25 resets will be sent to indicate when the circuit comes up or goes down.

PVC circuit numbers must come before (that is, be numerically smaller than) the circuit numbers allocated to any SVC range.

The following example configures a PVC connected between two serial interfaces on the same router. In this type of interconnection configuration, the alternate interface must be specified along with the PVC number on that interface. To make a working PVC connection, two commands must be specified, each pointing to the other, as this example illustrates.

Maximum input packet size (in-size) and output packet size (out-size) for both the PVC and SVC. Values may differ but must be one of the following: 16, 32, 64, 128, 256, 512, 1024, 2048, or 4096.

windowsize in-size out-size

Packet count for input window (in-size) and output window (out-size) for both the PVC and SVC. Both values may differ but must be in the range 1 to 127 and must be less than the value set for the x25 modulo command.

Table 56 lists the call control options supported by X.25 during PVC to SVC switching.

Establishes a switched virtual circuit to the specified X.121 address when data is received from the permanent virtual circuit, but does not accept calls from this X.121 address.

no-outgoing

Accepts an incoming call from the specified X.121 address, but does not attempt to place a call when data is received from the permanent virtual circuit. If data is received from the permanent virtual circuit while no call is connected, the PVC will be reset.

accept-reverse

Causes the Cisco IOS software to accept incoming reverse-charged calls. If this option is not present, the Cisco IOS software clears reverse-charged calls unless the interface accepts all reverse-charged calls.

Any call with a destination address beginning with 20 will be routed to serial interface 0. Any call with a destination address beginning with 10 will be routed to serial interface 2. (Note that incoming calls will not be routed back to the same interface from which they arrived.)

Traffic received on PVC 5 on serial interface 0 will cause a call to be placed from address 201700 to the X.121 address 101601. The routing table will then forward the call to serial interface 2. If no data is sent or received on the circuit for two minutes, the call will be cleared, as defined by the x25 idle command. All incoming calls from 101601 to 201700 will be refused, as defined by the no-incoming attribute.

The second x25 pvc command configures the circuit to allow incoming calls from 101602 to 201700 to be connected to PVC 6 on serial interface 1. Because idle is set to 0, the call will remain connected until cleared by the remote host or an X.25 restart. Because outgoing calls are not permitted for this connection, if traffic is received on PVC 6 on serial interface 0 before the call is established, the traffic will be discarded and the PVC will be reset.

The last x25 pvc command configures the circuit to accept an incoming call from 101603 to 201700 and connects the call to PVC 7 on serial interface 0. If no data is sent or received on the circuit for two minutes, the call will be cleared. If traffic is received on PVC 7 on serial interface 0 before the call is established, a call will be placed to 101503 to 201700.

Use the PVC tunnel commands to tell the Cisco IOS software what the far end of the PVC is connected to. The incoming and outgoing packet sizes and window sizes must match the remote PVC outgoing and incoming sizes.

Each X.25-over-TCP (XOT) connection relies on a TCP session to carry traffic. To ensure that these TCP sessions remain connected in the absence of XOT traffic, use the service tcp-keepalives-in and service tcp-keepalives-out global configuration commands. If TCP keepalives are not enabled, XOT permanent virtual circuits (PVCs) might encounter problems if one end of the connection is reloaded. When the reloaded host attempts to establish a new connection, the other host refuses the new connection because it has not been informed that the old session is no longer active. Recovery from this state requires the other host to be informed that its TCP session is no longer viable so that it attempts to reconnect the PVC.

Recognized Operating Agency (ROA, formerly called a Recognized Private Operating Agency, or RPOA), which must be unique with respect to all other ROA names. It is used in the x25 facility and x25 map interface configuration commands.

number

A sequence of 1 or more numbers used to describe an ROA; up to 10 numbers are accepted.

(Optional) A pound sign (#) followed by a number designates the position in the routing table at which to insert the new entry. If no position value is given, the entry is appended to the end of the routing table.

selection

(Optional) The selection options identify when the subsequent modification and disposition elements apply to an X.25 call; any or all variables may be specified for a route. See Table 58 in the "Usage Guidelines" section for the valid selection keyword and argument options.

Although each individual selection criterion is optional, at least one selection or modification element must be specified in the x25 route command.

modification

(Optional) Modifies the source or destination addresses of the selected calls. The standard regular expression substitution rules are used, where a match pattern and rewrite string direct the construction of a new string. See Table 59 in the "Usage Guidelines" section for the valid modification keyword and argument options.

Although each individual modification is optional, at least one selection or modification element must be specified in the x25 route command.

disposition

Specifies the disposition of a call matching the specified selection pattern. See Table 63 in the "Usage Guidelines" section for the valid disposition keyword and argument options.

xot-keepalive

(Optional) Specifies an XOT keepalive period and number of XOT keepalive retries. XOT relies on TCP to detect when the underlying connection is dead. TCP detects a dead connection when transmitted data goes unacknowledged for a given number of attempts over a period of time. See Table 64 in the "Usage Guidelines" section for keepalive options.

The enhanced x25 route command replaces the x25 map cmns command. The x25 route alias form of this command (supported in earlier releases) has been replaced by the x25 alias command.

The selection criteria source and dest-ext first appeared in Cisco IOS Release 11.2 F. The interface disposition to a CMNS destination first appeared in Cisco IOS Release 11.2 F; in prior releases, CMNS routing information was implied by maps defining an NSAP prefix for a CMNS host's MAC address. The clear interface disposition first appeared in Cisco IOS Release 11.2 F; in prior releases, the disposition was implicit in a route to the Null 0 interface. The modification elements are long-standing but newly applicable to all dispositions in Cisco IOS Release 11.2 F.

Selection options specify match criteria. When a call matches all selection criteria in an X.25 route, then the specified modification and disposition are used for the call.

As many as four selection options can be used to determine the route:

Called X.121 network interface address (destination host address)

Calling X.121 network interface address (source host address)

Called address extension (destination NSAP address)

X.25 packet's call user data (CUD) field

Table 58 lists the selection options for the x25 route command. At least one selection or modification element must be specified in the x25 route command.

Table 58:

Selection Options

Description

destination-pattern

(Optional) Destination address pattern, which is a regular expression that can represent either one X.121 address (such as ^1111000$) or any address in a group of X.121 addresses (such as ^1111.*).

sourcesource-pattern

(Optional) Source address pattern, which is a regular expression that can represent either one X.121 source address (such as ^2222000$) or any address in a group of X.121 addresses (such as ^2222.*).

dest-extnsap-destination-pattern

(Optional) NSAP destination address pattern, which is a regular expression that can represent either an NSAP destination address (such as ^11.1111.0000$) or an NSAP prefix (such as ^11.1111.*).

Note: A period (.) in the pattern is interpreted as a character wildcard, which will not interfere with a match to the actual period in the NSAP; if desired, an explicit character match may be used (such as ^11\.1111\..*).

X25 Route Command Selection Options Note The X.121 and NSAP addresses are specified as regular expressions. A common error is to specify the address digits without anchoring them to the beginning and end of the address. For example, the regular expression 1111 will match an X.121 address that has four successive 1s somewhere in the address; to specify the single X.121 address, the form ^1111$ must be used.

Regular expressions are used to allow pattern-matching operations on the addresses and user data. A common operation is to do prefix matching on the X.121 DNIC field and route accordingly. The caret (^) is a special regular expression character that anchors the match at the beginning of the pattern. For example, the pattern ^3306 will match all X.121 addresses with a DNIC of 3306.

Addresses typically need to be modified when traffic from a private network that uses arbitrary X.121 addresses must transit a public data network, which must use its own X.121 addresses. The easiest way to meet the requirement is to specify in the x25 route command a way to modify the private address into a network X.121 address or to modify a network X.121 address into a private address. The addresses are modified so that no change to the private addressing scheme is required.

The modification options use the standard UNIX regular expression substitution operations to change an X.25 field. A pattern match is applied to an address field, which is rewritten as directed by a rewrite pattern.

Table 59 lists the modification options for the x25 route command. At least one selection or modification element must be specified in the x25 route command.

Table 59:

Modification Option

Description

substitute-sourcerewrite-source

(Optional) Calling X.121 address rewrite pattern.

The source address,source-pattern, and this rewrite-source pattern are used to form a new source address. If no source-pattern is specified, any destination-pattern match pattern is used. If neither match pattern is specified, a default match pattern of .* is used.

See Table 60 and Table 61 for summaries of pattern and character matching, respectively. See Table 62 for a summary of pattern rewrite elements.

substitute-destrewrite-dest

(Optional) Called X.121 address rewrite pattern.

The destination address, destination-pattern, and this rewrite-dest pattern are used to form a new destination address. If no destination-pattern is specified, a default match pattern of .* is used.

See Table 60 and Table 61 for summaries of pattern and character matching, respectively. See Table 62 for a summary of pattern rewrite elements.

Source address. A modification of the source address is directed by the rewrite string using one of three possible match patterns. If the source source-pattern selection option is defined, it is used with the source-rewrite string to construct the new source address; otherwise, a destination-pattern regular expression is used (for backwards compatibility) or a wildcard regular expression (.*) is used. In the rewrite-source argument, the backslash character (\) indicates that the digit immediately following the argument selects a portion of the matched address to be inserted into the new called address.

Destination address. A modification of the destination address is directed by the rewrite string using one of two possible match patterns. If the destination-pattern selection option is defined, it is used with the destination-rewrite string to construct the new destination address; otherwise, a wildcard regular expression (.*) is used. In the rewrite-dest argument, the backslash character (\) indicates that the digit immediately following the argument selects a portion of the original called address to be inserted into the new called address.

Refer to Table 60, Table 61, and Table 62 for summaries of pattern matching, character matching, and pattern rewrite elements. Note that up to nine pairs of parentheses can be used to identify patterns to be included in the modified string. A more complete description of the pattern-matching characters is found in the "Regular Expressions" appendix in the Dial Solutions Command Reference.

The xot-source disposition option can improve the resilience of the TCP connection if, for instance, a loopback interface is specified. By default, a TCP connection's source IP address is that of the interface used to initiate the connection; a TCP connection will fail if either the source or destination IP address is no longer valid. Because a loopback interface never goes down, its IP address is always valid. Any TCP connections originated using a loopback interface can be maintained as long as a path exists to the destination IP address, which may also be the IP address of a loopback interface.

Table 63 lists the disposition choices for the x25 route command. You are required to select one of these choices.

TCP maintains each connection using a keepalive mechanism that starts with a default time period and number of retry attempts. If a received XOT connection is dispatched using a route with explicit keepalive parameters, those values will be used for the TCP connection. If an XOT connection is sent using a route with explicit keepalive parameters, those values will be used for the TCP connection.

If a matching route is found, the incoming call is forwarded to the next hop depending on the routing entry. If no match is found, the call is cleared. If the route specifies a serial interface running X.25 or a broadcast interface running CMNS, the router attempts to forward the call to that host. If the interface is not operational, the subsequent routes are checked for forwarding to an operational interface. If the interface is operational but out of available virtual circuits, the call is cleared. Otherwise, the expected Clear Request or Call Accepted message is forwarded back toward the originator. A call cannot be forwarded out the interface on which it arrived.

If the matching route specifies an XOT disposition, a TCP connection is established to port 1998 at the specified IP address, which must be an XOT host. The Call Request packet is forwarded to the remote host, which applies its own criteria to handle the call. If, upon receiving an XOT call, a routing table entry is not present, or the destination is unavailable, a Clear Request is sent back and the TCP connection is closed. Otherwise, the call is handled and the expected Clear Request or Call Accepted packet is returned. Incoming calls received via XOT connections that match a routing entry specifying an XOT destination are cleared. This restriction prevents Cisco routers from establishing an XOT connection to another router that would establish yet another XOT connection.

The following example uses regular expression pattern matching characters to match just the initial portion of the complete X.25 address. Any call with a destination address beginning with 3107 that is received on an interface other than serial 0 is forwarded to serial 0.

x25 route ^3107 interface serial 0

The following example prevents X.25 routing for calls that do not specify a source address:

x25 route source ^$ clear

The following example configures alternate XOT hosts for the routing entry. If the first address listed is not available, subsequent addresses are tried until a connection is made. If no connection can be formed, the call is cleared.

x25 route ^3106$ xot 172.20.2.5 172.20.7.10 172.10.7.9

The following example clears calls that contain a 3 in the source address. The disposition keyword clear is new:

x25 route source 3 clear

The following example clears calls that contain two consecutive 3's in the source address:

x25 route source 33 clear

The following example clears a call to the destination address, 9999:

x25 route ^9999$ clear

The following example specifies a route for specific source and destination addresses. (The ability to combine source and destination patterns is a new feature.)

x25 route ^9999$ source ^333$ interface serial 0

The following example routes the call to the XOT host at the specified IP address. The disposition keyword xot is new. In prior releases the keyword ip was used.

The following example rewrites the destination address as 9999. There must be a minimum of four 8's in the address. (8888888 will change to 9999.)

x25 route 8888 substitute-dest 9999 interface serial 0

The following example substitutes only part of the destination address. "^88" specifies the original destination string must begin with 88. "(.*)" indicates the string can end with any number, 0-9, and can be more than one digit. "99\1" changes the destination address to 99 plus whatever matches ".*" in the original destination address. For example, 8881 will change to 9981.

x25 route ^88(.*) substitute-dest 99\1 interface serial 0

The following example substitutes only part of the destination address and also removes a specified number of digits from the address. "^88" specifies the original destination string must begin with 88. "(..)" matches any two digits. "(.*)" specifies the string can end with any number, 0-9, and can occur zero or more times. Thus any address that starts with 88 and has four or more digits will be rewritten to start with 99 and omit the third and fourth digits. For example, 881234 will change to 9934.

x25 route ^88(..)(.*) substitute-dest 99\2 interface serial 0

The following example looks for a specified destination address and changes the source address. "9999" is the destination address. The original source address changes to "2222" because the call is made to the destination 9999.

x25 route ^9999$ substitute-source 2222 interface serial 0

The following example rewrites the source address based upon the source address. "9999" matches any destination address with four consecutive 9s. "^...(.*)" matches any source address with at least three digits; the command removes the first three digits and rewrites any digits after the first three as the new source address. For example, a call to 9999 from the source address 77721 will be forwarded using the calling address 21 and the called address 9999.

The following example adds a digit to the source and destination addresses patterns. "09990" is the destination address pattern. The source can be any address. "9\0" specifies to add a leading 9 to the destination address pattern. "3\0" specifies to add a leading 3 to the source address pattern. For example, a call using source 03330 and destination 09990 will change to 303330 and 909990, respectively.

The x25 routing command enables X.25 switching between the X.25 services (X.25, CMNS and XOT). X.25 calls will not be forwarded until this command is issued.

The tcp-use-if-defs keyword may be needed for receiving XOT calls from routers using older software versions. Normally, calls received over a TCP connection (remote routing reception) will have the flow control parameters (window sizes and maximum packet sizes) indicated, because proper operation of routed X.25 requires that these values match at both ends of the connection.

Some previous versions of our software, however, do not ensure that these values are present in all calls. In this case, the Cisco IOS software normally forces universally acceptable flow control values (window sizes of 2 and maximum packet sizes of 128) on the connection. Because some equipment disallows modification of the flow control values in the call confirm, the tcp-use-if-defs keyword causes the router to use the default flow control values of the outgoing interface and indicate the resulting values in the call confirm. This modified behavior may allow easier migration to newer versions of the Cisco IOS software.

The router sends an acknowledgment packet when the number of input packets reaches the count you specify, providing there are no other packets to send. For example, if you specify a count of 1, the router will send an acknowledgment per input packet if unable to "piggyback" the acknowledgment of an outgoing data packet. This command improves line responsiveness at the expense of bandwidth.

This command only applies to encapsulated traffic over X.25 (datagram transport), not to routed traffic.

Some X.25 calls, when forwarded by the X.25 switching support, need the calling (source) X.121 address updated to that of the outgoing interface. This update is necessary when you are forwarding calls from private data networks to public data networks (PDNs).

This command determines the default number of packets a virtual circuit can receive before sending an X.25 acknowledgment. To maintain high bandwidth utilization, assign this limit the largest number that the network allows.

This command determines the default number of packets a virtual circuit can send before waiting for an X.25 acknowledgment. To maintain high bandwidth utilization, assign this limit the largest number that the network allows.

If applied as an inbound access class, specifies the X.121 address that can or cannot have access (with or without regular expression pattern-matching characters). The X.121 address is the source address of the incoming packet.

If applied as an outbound access class, then the address specifies a destination to where connections are allowed.

An access list can contain any number of access list items. The list items are processed in the order in which you entered them, with the first match causing the permit or deny condition. If an X.121 address does not match any of the regular expressions in the access list, access is denied.

Access lists take advantage of the message field defined by Recommendation X.29, which describes procedures for exchanging data between two PADs, or between a PAD and a DTE device.

The UNIX-style regular expression characters allow for pattern matching of characters and character strings in the address. Various pattern-matching constructions are available that allow many addresses to be matched by a single regular expressions. For more information, refer to the "Regular Expressions" appendix in the Dial Solutions Command Reference.

The access lists must be applied to a vty with the access-class command.

When an X.25 connection is established, the access server acts as if an X.29 Set Parameter packet had been sent containing the parameters and values set by the x29 profile command and sets the access server accordingly.

For incoming PAD connections, the Protocol Translator uses a default PAD profile to set the remote X.3 PAD parameters unless a profile script is defined with the translate command.

The following profile script turns local edit mode on when the connection is made and establishes local echo and line termination upon receipt of a Return packet. The name linemode is used with the translate command to effect use of this script.

x29 profile linemode 2:1 3:2 15:1

To override the default PAD profile, create a PAD profile script named "default" by using the following command: