|
|
This chapter describes how to configure connections through X.25 networks, including Level 2 Link Access Procedure-Balanced (LAPB) connections and connections to a packet assembly/disassembly (PAD) facility. You will find the following information in this chapter:
To configure X.25, you must be in the configuration command collection mode. To enter this mode, type the EXEC command configure at the EXEC prompt. Once in the collection mode, start configuring the interface by entering the interface command
A command summary is included at the end of the chapter.
The software for the communication server and protocol translator products supports the 1980 and 1984 Recommendation X.25, published by the French International Telegraph and Telephone Consultative Committee (CCITT). The X.25 standards specify connections between data terminal equipment (DTE) and data circuit-terminating equipment (DCE). The Defense Data Network (DDN) and the International Standards Organization (ISO) specify the X.25 protocol for computer communications. Many public and private networks also use Recommendation X.25 as their interface technology.
The X.25 standards provide a telephone network model for computer data communications. To start data communications, one computer system calls another to request a communi-cations session. The called computer system can accept or refuse the call. If the called system accepts the call, the two computer systems can begin transferring data in both directions; either system can terminate the call.
The X.25 standards also provide recommendations for the data link layer (OSI Level 2), to facilitate reliable interchange of data between devices across a link. The Cisco software supports Level 2 connections using X.25 Link Access Procedure-Balanced (LAPB) serial encapsulation methods.
The communication server uses the CCITT Recommendation X.25 for transferring raw data over X.25 networks. Communication servers with protocol translation also support use of X.25 as a transport mechanism for Internet packets. In addition, the communication server supports X.3 and X.29-based PAD connections. This allows the communication servers to connect to an X.25 Public Data Network (PDN). This X.25 connection allows transport of the TCP/IP packets across the X.25 packet switching network in the same way as would occur on a router.
Routers do not support an X.25 PAD function, so they are unable to communicate with hosts directly connected to the X.25 PDN. The routers encapsulate TCP/IP packets in X.25 packets for transfer over a packet switching network. These packets can be received by routers, communication servers, or other Cisco protocol translators. Only Cisco's protocol translators include PAD capabilities. However, other servers can communicate with a protocol translator using the Telnet or LAT protocols. The protocol translator can translate this into X.25, which then would be able to communicate with the X.25 host. The protocol translators support all PAD standards (X.28, X.29, and X.3). The connection to the packet switching network is through a synchronous line.
The X.25 software provides support for Level 2 LAPB connections, X.25 Level 3
connections, and with protocol translation, PAD connections. Summaries of the configuration procedure for each connection type are described in the following sections.
LAPB connections are supported by encapsulating datagrams so they may be transmitted over serial interfaces. The basic LAPB configuration procedure follows:
Step 1: Select the LAPB operation--either DTE or DCE--and then configure the interface with the appropriate LAPB encapsulation command.
Step 2: Specify the LAPB parameter settings. These settings are determined by the network and service over which the datagrams will be transmitted. Table 1-1 summarizes the LAPB parameters.
The commands for these tasks are described in the section "Configuring X.25 Level 2 (LAPB)" This section includes information about troubleshooting LAPB connections.
The basic X.25 configuration procedure follows:
Step 1: Assign the X.25 address to the interface. Obtain the X.25 address from the X.25 service provider.
Step 2: Select the X.25 operation--either DTE or DCE--and then configure the interface with the appropriate X.25 encapsulation command.
Step 3: Specify the X.25 Level 3 parameter settings. The default values provided by the software are sufficient for most X.25 networks; however, some parameters may need to be configured, depending on the network.
Optionally, protocol translation can be configured over multiple interfaces using the x25 route command. You can create tables by which to map IP datagrams to X.25 datagrams and thereby transmit IP data through an X.25 network. This is done using the x25 map command.
The commands for these tasks are described in the sections "Setting the X.25 Interface Address" ""Configuring X.25 DTE or DCE Operation"," ""Mapping to the Internet Address"," and ""Configuring X.25 Parameters"" in this chapter. If you are connecting to a DDN X.25 network, see the section ""Configuring DDN X.25"." Commands for maintaining, monitoring, and troubleshooting the X.25 connections follow these sections.
Connections to a PAD are made using the EXEC commands pad, resume, and x3. You can configure PAD parameter profiles that can be used to set PAD parameters by other commands, and access lists to control X.25 network access. Both features make use of the message fields defined in Recommendation X.29, which describes procedures for exchanging data between two PADS or a PAD and a DTE. These tasks are described in the sections "Configuring X.29 Access Lists" and "Creating an X.29 Profile" in this chapter. Making PAD connections is described in the "User Commands" chapter.
The X.25 standards distinguish between two types of X.25 hosts: data terminal equipment (DTE), and data circuit-terminating equipment (DCE). At Level 2, or the data link layer in the OSI model, X.25 provides the Link Access Procedure-Balanced (LAPB) to provide for orderly and reliable exchange of data between a DTE and a DCE.
Using LAPB under noisy conditions can result in greater throughput than HDLC encapsulation. When LAPB detects a damaged frame, the communication server immediately retransmits the frame instead of waiting for host timers to expire. This behavior is good only if the host timers are relatively slow. In the case of quickly expiring host timers, however, you will discover that LAPB is spending much of its time retransmitting host transmissions.
If the line is not noisy, the lower overhead of HDLC encapsulation is more efficient than LAPB. When using long delay satellite links, for example, the lock-step behavior of LAPB makes HDLC encapsulation the better choice.
It is possible to only use LAPB as a serial encapsulation method. This can be done using a leased serial line. You must use one of the X.25 packet-level encapsulations when attaching to an X.25 network. A communication server or protocol translator using LAPB encapsulation can act as a DTE or DCE device at the protocol level.
To run datagrams over a serial interface using the LAPB encapsulation, use the following encapsulation interface subcommand:
encapsulation {lapb|lapb-dce}The keyword lapb sets DTE operation; the keyword lapb-dce sets DCE operation. One end of the link must be DTE and the other must be DCE.
In the following example of LAPB encapsulation configuration, the frame size (N1), window size (K), hold timer (TH), and maximum retransmission (N2) parameters retain their default values. The encapsulation subcommand sets DCE operation for IP packets only, and the lapb t1 subcommand sets the retransmission timer to 4,000 milliseconds
(4 seconds).
interface serial 3 encapsulation lapb-dce lapb t1 4000
For more information on LAPB parameters, see the next section, "Setting the X.25 Level 2 (LAPB) Parameters"
X.25 Level 2, or LAPB (Link Access Procedure-Balanced), is a data encapsulation protocol that operates at Level 2 (the data link layer) of the OSI reference model. LAPB specifies methods for exchanging data (in units called frames), detecting out-of-sequence or missing frames, retransmitting frames, and acknowledging frames.
LAPB parameters are set with the lapb interface subcommand. The interface must be running with either a LAPB or X.25 encapsulation method specified by the encapsulation interface subcommand. The command syntax follows:
lapb parameter valueThe argument parameter is one of several keywords described in the following text, and the argument value is a decimal number representing a period of time, a bit count, or a frame count, depending on the parameter. Table 1-1 summarizes the LAPB parameters.
| Parameter | Value | Value Range | Default |
|---|---|---|---|
| k | window size | 1-7 | 7 |
| n1 | bits | 1-16384 | 12000 |
| n2 | retries | 1-255 | 20 |
| t1 | milliseconds | 1-64000 | 3000 |
The retransmission timer determines how long a transmitted frame can remain unacknow-ledged before the communication server polls for an acknowledgment. To set the limit for the
retransmission timer (the LAPB T1 parameter), use the lapb t1 subcommand. The command syntax follows:
The argument milliseconds is the number of milliseconds from 1 through 64,000. The default value is 3,000 milliseconds.
For X.25 networks, the communication server retransmission timer setting should match that of the network. Mismatched retransmission timers can cause excessive retransmissions and an effective loss of bandwidth.
For leased-line circuits, the retransmission timer setting is critical. The timer setting must be large enough to permit a maximum-sized frame to complete one round trip on the link. If the timer setting is too small, the communication server will poll before the acknowledgment frame can return, which results in an effective loss of bandwidth. If the timer setting is too large, the communication server waits longer than necessary before requesting an acknowledgment, which also reduces bandwidth.
To determine an optimal value for the retransmission timer, use the privileged EXEC command ping to measure the round-trip time of a maximum-sized frame on the link. Multiply this time by a safety factor that takes into account the speed of the link, the link quality, and the distance. A typical safety factor is 1.5. Choosing a larger safety factor can result in slower data transfer if the line is noisy. However, this disadvantage is minor compared to the excessive retransmissions and effective bandwidth reduction caused by a timer setting that is too small.
To specify the maximum number of bits a frame can hold, use the lapb n1 interface subcommand:
lapb n1 bitsThe n1 keyword specifies the maximum number of bits (N1) a frame can hold. The argument bits is the number of bits from 1 through 12000, and must be a multiple of eight. The default value is 12000 bits (1500 bytes).
When connecting to an X.25 network, use the N1 parameter value set by the network
administrator, which is the maximum size of an X.25 packet. When using LAPB over leased lines, the N1 parameter should be eight times the MTU.
To specify the maximum number of times an acknowledgment frame can be retransmitted, use the lapb n2 interface subcommand:
lapb n2 retriesThe argument retries is the retransmission count from 1 through 255. The default value is 20 retransmissions.
To specify the maximum permissible number of outstanding frames, called the "window size," use the lapb k interface subcommand:
lapb k window-sizeThe argument window-size is a packet count from 1 to 7. The default value is 7 packets.
The following configuration commands change the LAPB window size (the K parameter) to 3 packets:
interface serial 0 lapb k 3
To adjust the Level 3 (packet level) parameters of an X.25 interface, use the x25 subcommand of the interface configuration command.
To display operation statistics for an interface using LAPB encapsulation, use the EXEC command show interfaces.
The following example output shows the state of the LAPB protocol, the current parameter settings, and a count of the different types of frames. Each frame count is displayed in the form sent/received.
LAPB state is DISCONNECT, T1 3000, N1 12000, N2 20, K 7,TH 3000 IFRAMEs 12/28 RNRs 0/1 REJs 13/1 SABMs 1/13 FRMRs 3/0 DISCs 0/11
For a description of the variable names in the show interface output, see the X.25 recommendation.
To debug LAPB problems, you must understand of the X.25 recommendation.
To enable the logging of all packets received and generated, use the privileged EXEC command debug lapb. Note that this command slows down processing considerably on heavily loaded links. The following shows example output:
Serial0: LAPB 0 CONNECT (5) IFRAME 0 1 Serial0: LAPB I CONNECT (2) RR 1 (R) Serial0: LAPB I CONNECT (5) IFRAME P 2 1 (C) Serial0: LAPB 0 REJSENT (2) REJ P/F 1 Serial0: LAPB I REJSENT (2) DM F (C) Serial0: LAPB I DISCONNECT (2) SABM (C) Serial0: LAPB 0 CONNECT (2) UA . . . Serial0: LAPB T SABMSENT 357964 0 Serial0: LAPB 0 SABMSENT (2) SABM P
In the example output, each line represents a LAPB frame entering or exiting the communication server. The first field shows the interface type and unit number of the interface reporting the frame event. The second field is the protocol that provided the information.
The third field is I, O, or T for "frame input," "frame output," or "T1 timer expired," respectively. The fourth field indicates the state of the protocol when the frame event occurred. In a timer event, the state name is followed by the current timer value and the number of retransmissions.
In a packet input or output event, the state name is followed by the size of the frame in bytes (in parentheses) and the frame type name. The next field is an optional indicator: P/F, P, or F, which stand for "Poll/Final," "Poll," and "Final," respectively. For IFRAME frames only, the next two numbers are the receive and send sequence numbers, respectively. For RR, RNR, and REJ frames, the next number is the receive sequence number. For FRMR frames, the next three numbers are three bytes of error data. The last optional indicator is (C) for "command" or (R) for "response."
To set the X.121 address of a particular network interface, use the x25 address interface subcommand:
x25 address X.121-addressThe argument X.121-address is a variable-length X.121 address. The address is assigned by the X.25 network service provider.
The following configuration commands set the X.121 address for the interface:
interface serial 0 x25 address 00000123005
The value must match that assigned by the X.25 network.
To display the current X.25 parameter settings, use the EXEC command show interfaces. Refer to the "Monitoring X.25" section later in this chapter for more information.
This section describes the different encapsulation methods for selecting device operation. Methods of encapsulation for DDN networks are described in the section "Configuring DDN X.25" later in this chapter.
A communication server using X.25 Level 3 encapsulation can act as a DTE or DCE device on general X.25 networks.
To set X.25 DTE operation, use the encapsulation x25 interface subcommand:
encapsulation x25To set X.25 DCE operation, use the encapsulation x25-dce interface subcommand:
encapsulation x25-dceDefault serial encapsulation is HDLC. You must choose one of these X.25 encapsulation methods.
The Cisco X.25 software allows you to connect to multiple X.25 interfaces. Use the global configuration command x25 route to make these connections. Configure each of the X.25 interfaces as appropriate for the network it is connected to, and then use the x25 route command to build the tables of network addresses.The full syntax and variations of the x25 route command follow.
x25 route [# position]x121-pattern [cud pattern] interface interface-nameThe order in which entries are specified is significant; the list is scanned linearly for the first match. The optional argument pair # position is a pound sign (#) followed by an integer. This positional parameter designates after which existing entry to insert or delete the new entry. If no positional parameter is given, the entry is appended to the end of the routing table.
The argument x121-pattern is the called X.121 address and is required. Optional Call User Data corresponding to this X.121 address can be specified as a printable ASCII string. The Call User Data field (cud pattern) specifies the data after the protocol identification field, which is four bytes. Both the X.121 address and Call User Data can be written using UNIX-style regular expressions.
See Table 1-2 and Table 1-3 for a summary of pattern- and character-matching symbols and their use. A more complete description of the pattern matching characters is found in Appendix B.
The interface keyword and interface-name argument define the interface.
The ip keyword and ip-address argument specify an IP address.
The alias keyword and interface-name argument permit a way for other X.121 addresses to be treated as local address. An alias accepts calls for the communication server.
Enter the no x25 route command with the appropriate arguments and keywords to remove an entry from the table. Use the show x25 route command to display the X.25 routing table. The interface routes will show up after any routes used for translation commands. Because the interface routes are expected to be less specific, they should come last. This is done automatically.
| Pattern Description | |
|---|---|
| \0 | Replaces the entire original address. |
| \1...9 | Replaces strings that match the first through ninth parenthesized part of the X.121 address. |
| * | Matches 0 or more sequences of the regular expressions. |
| + | Matches 1 or more sequences of the regular expressions. |
| ? | Matches the regular expression of the null string. |
| Character Description | |
|---|---|
| ^ | Matches the null string at the beginning of the input string. |
| $ | Matches the null string at the end of the input string. |
| \char | Matches char. |
| . | Matches any single character. |
The following example illustrates how to use three interfaces to connect to three different X.25 services. The x25 address command assigns the X.25 address to the interface, then the table is generated using the x25 route command. Notice that regular expression pattern matching characters are used to match just the initial portion of the complete X.25 addresses. Finally, protocol translation is defined as IP packets encapsulated into X.25 data using the translate command.
! ! This PT has three X.25 interfaces. One is connected to infonet, one ! to tymnet, and one to an internal private X.25 network ! interface serial 0 description InfoNet Connection x25 address 3107012332004 ! interface serial 1 description Tymnet connection x25 address 3106012332001 ! interface serial 2 description Internal X.25 net x25 address 111110000001 x25 win 7 x25 wout 7 x25 ips 512 x25 ops 512 ! x25 route ^3107 interface serial 0 x25 route ^3106 interface serial 1 x25 route ^1111 interface serial 2 ! translate tcp infonet-noc x25 31070 translate tcp tymnet-noc x25 3106011 translate tcp x25noc x25 11110000022 !
The communication servers can use three methods to map Internet addresses to X.121 addresses used by X.25.
A communication server set up for DDN service uses the dynamic mapping technique specified in Appendix A of the DDN X.25 Host Interface Specification, available from the DDN Network Information Center (NIC). This technique has two severe limitations: it applies only to Class A Internet addresses, and it ignores the third octet of the Internet address; this technique works well for the DDN, but not for any other network.
You can establish the X.121 address of a particular network interface using the x25 address interface subcommand. If you do not specify the address, the communication server uses the DDN mapping technique to obtain the X.121 address of an interface. This command is described in the section "Setting the X.25 Level 3 Parameters" in this chapter.
You can set up the Internet-to-X.121 address mapping for the host using the x25 map interface subcommand. Because no defined protocol can dynamically determine such mappings, you must enter a mapping for each host with which the communication server will exchange traffic. The full command syntax follows:
x25 map protocol-keyword protocol-address X.121-address [option1... [option]]For the communication server, the argument protocol-keyword can only be ip. The address arguments specify the network-protocol-to-X.121 mapping.
The option arguments add certain features to the mapping specified, and can be any of the following, up to six, specified in the order listed.
To retract a network-protocol-to-X.121 mapping, use the no x25 map command with the appropriate network protocol and X.121 address arguments.
You can define a static host-name-to-address mapping in the host cache using the x25 host subcommand. The command syntax follows:
x25 host name 121-address [cud call-user-data]The argument name is the host name. The optional keyword and argument cud call-user-data sets the Call User Data (CUD) field in the X.25 call request packet.
The implementation of Compressed TCP over X.25 uses another virtual circuit (VC) to pass the compressed packets. The noncompressed packets use one VC and the compressed packets take another VC.
Use this interface subcommand to implement head compression on IP packets:
ip tcp header-compression [passive]Use the following interface subcommand to make the X.25 calls complete for compressed packets:
x25 map compressedtcp ip-address x.121-address [options]The argument ip-address is the IP address and x.121-address is the X.121 address. The options arguments are the same options as those for the x25 map command described in"Mapping to the Internet Address" The Call User Data of compressed TCP calls is the single byte 0xd8.
The DDN X.25 protocol has two versions: Basic Service and Standard Service. Using the DDN X.25 Basic Service, network devices send raw X.25 data across the DDN and assume no structure within the data portion of the X.25 packet. Basic Service users can interoperate only with other Basic Service users.
DDN X.25 Standard Service requires that the X.25 data packets carry IP datagrams. Because the DDN Packet Switch Nodes (PSNs) can extract the Internet packet from within the X.25 packet, they can pass data to either an 1822-speaking-host or to another Standard Service host. Thus, hosts using the older 1822 network interface can interoperate with hosts using Standard Service.
The DDN X.25 Standard is the required protocol for use with DDN PSNs. The Defense Communications Agency (DCA) has certified the Cisco Systems DDN X.25 Standard
implementation for attachment to the Defense Data Network.
A router using DDN X.25 Basic Service can act as either a DTE or a DCE device. To set operation type, use the encapsulation interface subcommand:
encapsulation {ddnx25|ddnx25-dce}Both of these keywords cause the router to specify the Standard Service facility in the Call Request packet, which notifies the PSNs to use Standard Service.
Using Standard Service, the DDN can provide efficient service for virtual circuits with high precedence values. If the router receives an Internet packet with a nonzero Internet precedence field, it opens a new virtual circuit and sets the precedence facility request to the DDN-specified precedence mapping in the Call Request packet. Different virtual circuits are maintained based on the precedence mapping values and the number of virtual circuits permitted.
For environments that require a high level of security, your router software supports the Defense Data Network Blacker Front-End Encryption (BFE) and Blacker Emergency Mode.
Blacker Emergency Mode allows your BFE device and your router to function in emergency situations. When the router is configured to participate in emergency mode and the BFE device is in emergency mode, the router sends address translation information to the BFE device to assist the it in sending information.
Cisco's implementation of Blacker Emergency Mode adheres to the specifications outlined in the DCA Blacker Interface Control document, published March 21, 1989.
Your BFE device is configured to be in one of three possible modes as follows:
If the router is attached to a BFE device, the bfex25 keyword must be used with the encapsulation subcommand. Use this command to configure BFE encapsulation:
encapsulation bfex25This encapsulation provides a mapping from Class A IP addresses to the type of X.121 addresses expected by the BFE encryption device.
The table resulting from the following x25 remote-red command provides the address translation information the router sends to the BFE when the BFE is in emergency mode. Use the following command to set up the table that lists the BFE nodes (host or gateways) to which the router will send packets:
x25 remote-red host-ip-address remote-black Blacker-Internet-addressThe host-ip-address argument is the IP address of the host or a router that the packets are being sent to. The Blacker-Internet-address argument is the IP address of the remote BFE device in front of the host that the packet is being sent to.
Use the following command to configure the circumstances under which the router will participate in emergency mode:
x25 bfe-emergency {never|always|decision}The default keyword is never. When set to never, the router does not send address translation information to the BFE. When it does not receive address translation information, the BFE cannot open a new connection for which it does not know the address.
When the always keyword is used and the router has been configured to create an address translation table, the router passes address translations to the BFE when the BFE enters emergency mode.
When the decision keyword is used, the router waits 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 is to enter emergency mode.) When the diagnostic packet is received, the router's participation in emergency mode depends on how it is configured using the x25 bfe-decision command described next in this section.
Use the following command to configure how a router configured as x25 bfe-emergency decision will participate in emergency mode:
x25 bfe-decision {no|yes|ask}The default value is no. When set to no, the router will not participate in emergency mode and will not send address translation information to the BFE device.
When set to yes, the router will participate in emergency mode, sending address translation information to the BFE when the BFE enters emergency mode. The router gets this information from the table set up by using the x25 remote-red command described earlier in this section.
When the ask keyword is used, the router will prompt the administrator to use the EXEC bfe {enter|leave} command to send or not send address translation information to the BFE device.
Use the following interface EXEC command to set the router to participate in emergency mode or to end participation in emergency mode if your system is configured for x25 bfe-emergency decision and x25 bfe-decision ask.
bfe {enter|leave} interface-type unitThe keyword options are enter and leave. The keyword enter will cause the router to send a special address translation packet that includes an "enter emergency mode" command to the BFE if the emergency mode window is open. If the BFE is already in emergency mode, this command enables the sending of address translation information.
If the BFE is in emergency mode, the leave keyword disables the sending of address translation information from the router to the BFE.
The interface-type argument is the interface name, and unit is the interface number.
In the example that follows, interface Serial 0 is configured to require an EXEC command from the administrator 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 router will prompt the administrator for EXEC command bfe enter to direct the router to participate in emergency mode.
interface serial 0 x25 bfe-emergency decision x25 remote-red 21.0.0.12 remote-black 21.0.0.1 x25 bfe-decision ask
Use the following command to display the one-to-one mapping of the host IP addresses and the remote BFE device's IP addresses:
show x25 remote-redWhen all of the X.25 bfe nodes (host or gateways) are entered by using the x25 remote-red command, the show command that follows can be used to display the table.
The following show display provides the IP addresses of the host unit (remote-red) and remote BFE units (bfe-remote) for each BFE entry:
router>show x25 remote-redEntry Remote-red fe-remote Interface 1 21.0.0.3 21.0.0.7 serial3 2 21.0.0.10 21.0.0.6 serial1 3 21.0.0.24 21.0.0.8 serial3
A communication server using the DDN X.25 Basic Service can act as a DTE or DCE device. To set operation type, use this interface subcommand:
encapsulation {ddnx25|ddnx25-dce}These keywords cause the communication server to specify the Standard Service facility in the Call Request packet, which notifies the PSNs to use Standard Service.
Using Standard Service, the DDN can provide better service for virtual circuits with higher precedence values. If the communication server receives an Internet packet with a nonzero Internet precedence field, it opens a new virtual circuit and sets the precedence facility request to the DDN-specified precedence mapping in the Call Request packet. Different virtual circuits are maintained based on the precedence mapping values and the permitted number of virtual circuits.
Normally the X.25 parameters of a DDN connection are configured using the x25 and lapb interface subcommand described in the section "Configuring X.25 Parameters" however, there are a few DDN-specific subcommands.
Cisco's X.25 implementation allows you to enable or disable the ability to open a new virtual circuit based on the IP Type of Service (TOS) field. To do this, use the x25 ip-precedence interface subcommand. The full syntax of this command follows:
x25 ip-precedence By default, communication servers open one virtual circuit for each type of service. There is a problem associated with this in that some hosts send nonstandard data in the TOS field, thus causing multiple, wasteful virtual circuits to be created. The command no x25
ip-precedence causes the TOS field to be ignored when opening virtual circuits.
The HDH protocol (also known as the HDLC Distant Host or 1822-J protocol) provides a method for running the 1822 protocol over synchronous serial lines instead of over special-purpose 1822 hardware. HDH packets consist of 1822-LH/DH leaders and data encapsulated in LAPB (X.25 Level 2) format. The HDH hardware is on the Multiport Communications Interface (MCI) card. Strictly speaking, HDH is not X.25, however, it is still commonly used for attaching to the Defense Data Network.
The communication server supports both the packet and message modes of HDH. It is enabled with the hdh interface subcommand with the appropriate keyword. The syntax follows:
hdh {packet|message}The packet keyword specifies the packet mode; the message keyword specifies the message mode.
To enable the HDH protocol, use the following encapsulation command:
encapsulation hdhTo enable logging of HDH transactions, use the privileged EXEC command debug hdh. To enable logging of the underlying LAPB protocol transactions, use the privileged EXEC command debug lapb.
To display information about HDH, use the EXEC command show imp-hosts. This command displays information about the hosts with which the network server has communication during the past five minutes via its CSC-A (1822-LH/DH) interfaces or serial interface using HDH (1822-J) encapsulation.
Use the EXEC command debug psn to log information about the Packet Switch Node. This command enables logging of noteworthy Packet Switch Node (PSN) events for DDN network servers that are equipped with CSC-A (1822-LH/DH) interfaces or serial interfaces using HDH (1822-J) encapsulation.
The debug psn-events EXEC command enables logging of a subset of the PSN and 1822 debugging messages.
The communication server software provides subcommands to configure the standard Level 2 and Level 3 X.25 parameters and user facilities.
This section discuses the commands and procedures needed to set these parameters including interface addresses, virtual circuit channel sequences, and addresses.
This section describes the keywords for the x25 subcommand of the interface configuration command, used to adjust certain X.25 Level 3 parameters. These parameters must be adjusted to match the values used by the X.25 network. It is common for networks to require values different from the Cisco defaults.
The X.25 protocol maintains multiple connections over one physical link between a DTE and a DCE. These connections may be called virtual circuits (VCs) or logical channels (LCs). X.25 can maintain up to 4095 VCs numbered 1 through 4095. An individual VC is identified by giving its logical channel identifier (LCI) or virtual circuit number (VCN). Many documents use the terms VC and LC, and VCN, LCN, and LCI interchangeably. Each of these terms refer to the virtual circuit number.
An important part of X.25 operation is the range of virtual circuit numbers. Virtual circuit numbers are broken into four ranges (listed here in numerically increasing order):
The incoming-only, two-way, and outgoing-only ranges define the VC numbers over which a switched virtual circuit (SVC) can be established by placing an X.25 call, much like a telephone network establishes a switched voice circuit when a call is placed.
Rules about DCE and DTE devices initiating calls are as follows:
There is no difference in the operation of the SVCs except the restrictions on which device can initiate a call. These ranges can be used to prevent one side from monopolizing the virtual circuits, which can be useful for X.25 interfaces with a small total number of SVCs available.
Six X.25 parameters define the upper and lower limit of each of the three SVC ranges. A permanent virtual circuit (PVC) must be assigned a number less than the numbers assigned to the SVC ranges. An SVC range is not allowed to overlap another range.
To set the SVC range upper and lower limit parameters, use the x25 subcommand keywords listed in Table 1-4. Each keyword takes a circuit number as its argument. Note that the values for these parameters must be the same on both ends of an X.25 link. For connection to a Public Data Network (PDN), these values must be set to the values assigned by the network. An SVC range is unused if its lower and upper limits are set to 0.
| Keyword | Limit Type | Range | Default |
|---|---|---|---|
| lic | Lower-limit, incoming-only circuits | 1-4095 | 0 |
| hic | Upper-limit, incoming-only circuits | 1-4095 | 0 |
| ltc | Lower-limit, two-way circuits | 1-4095 | 1 |
| htc | Upper-limit, two-way circuits | 1-4095 | 1024 |
| loc | Lower-limit, outgoing-only circuits | 1-4095 | 0 |
| hoc | Upper-limit, outgoing-only circuits | 1-4095 | 0 |
The hic keyword sets the highest incoming-only virtual-circuit number.
x25 hic circuit-numberThe argument circuit-number is a virtual circuit number from 1 through 4095, or 0 if there is no incoming-only virtual circuit range. The default value is 0.
The hoc keyword sets the highest incoming-only virtual circuit number.
x25 hoc circuit-numberThe argument circuit-number is a virtual circuit number from 1 through 4095, or 0 if there is no outgoing-only virtual range. The default value is 0.
The htc keyword sets the highest incoming-only virtual circuit number.
x25 htc circuit-numberThe argument circuit-number is a virtual circuit number from 1 through 4095, or 0 if there is no two-way virtual circuit range. The default value is 1024 for X.25 network service interfaces; CMNS network service interfaces have default value of 4095.
The lic keyword sets the lowest incoming-only virtual circuit number.
x25 lic circuit-numberThe argument circuit-number is a virtual circuit number from 1 through 4095, or 0 if there is no incoming-only VC range. The default value is 0.
The loc keyword sets the lowest incoming-only VCN.
x25 loc circuit-numberThe argument circuit-number is a VCN from 1 through 4095, or 0 if there is no outgoing-only virtual circuit range. The default value is 0.
The ltc keyword sets the lowest incoming-only virtual circuit number.
x25 ltc circuit-numberThe argument circuit-number is a virtual circuit number from 1 through 4095, or 0 if there is no two-way virtual circuit range. The default value is 1.
The configuration in this example sets the following Virtual Circuit ranges: 5-20 dedicated to incoming calls only (from the DCE to the DTE), 25-1024 for either incoming or outgoing calls, no virtual circuit range dedicated to outgoing calls (from the DTE to the DCE). Up to four permanent virtual circuits can be defined on the Virtual Circuit Numbers 1 through 4.
x25 lic 5 x25 hic 20 x25 ltc 25
The communication server can clear a switched virtual circuit (SVC) after a set period of inactivity. To set this period, use the x25 idle interface subcommand.
x25 idle minutesThe argument minutes is the number of minutes in the period. The default value is zero, which causes the communication server to keep the SVC open indefinitely. Both calls originated and terminated by the communication server are cleared.
To clear all virtual circuits at once, use the privileged EXEC command clear x25-vc. This command takes an interface type keyword (usually serial) and a unit number as arguments to identify the interface with which the virtual circuits are associated.
To clear a particular virtual circuit, the clear x25-vc command takes the two arguments described above and a logical circuit number (LCN) value as a third argument to specify the circuit.
To increase throughput across networks, you can establish up to eight switched virtual circuits to a host. To specify the maximum number of switched virtual circuits that can be open simultaneously to one host, use the x25 nvc interface subcommand:
x25 nvc countThe argument count is a circuit count from 1 to 8. The default is 1.
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. This can overrun some X.25 switches. To prevent this problem, use the x25 hold-vc-timer configuration command:
x25 hold-vc-timer minutesThe argument minutes is the number of minutes it takes to prevent calls from going to a previously failed destination. Incoming calls will still be accepted.
The X.25 Level 3 retransmission timers determine how long the communication server must wait before retransmitting various Call Request packets. You can set these timers independently using the x25 subcommand keywords listed in Table 1-5. Each keyword requires a time value in seconds as its argument. The last column shows the default timer values, in seconds. Four of the timers apply to DTE devices, and the other four apply to DCE devices.
| Keyword (DTE/DCE) | Affected Request Packet | Time (seconds) (DTE/DCE) |
|---|---|---|
| t20/t10 | Restart Request | 180/60 |
| t21/t11 | Call Request | 200/180 |
| t22/t12 | Reset Request | 180/60 |
| t23/t13 | Clear Request | 180/60 |
The t20 keyword sets the limit for the Restart Request retransmission timer (T20) on DTE devices.
x25 t20 secondsThe argument seconds is the amount of time in seconds. The default is 180 seconds.
The t10 keyword sets the limit for the Restart Request retransmission timer (T10) on DCE devices.
x25 t10 secondsThe argument seconds is the amount of time in seconds. The default value is 60 seconds.
The t21 keyword sets the limit for the Call Request completion timer (T21) on DTE devices.
x25 t21 secondsThe argument seconds is the amount of time in seconds. The default value is 200 seconds.
The t11 keyword sets the limit for the Call Request completion timer (T11) on DCE devices.
x25 t11 secondsThe argument seconds is the amount of time in seconds. The default value is 180 seconds.
The t22 keyword sets the limit for the Reset Request retransmission timer (T22) on DTE devices.
x25 t22 secondsThe argument seconds is the amount of time in seconds. The default value is 180 seconds.
The t12 keyword sets the limit for the Reset Request retransmission timer (T12) on DCE devices.
x25 t12 secondsThe argument seconds is the amount of time in seconds. The default value is 60 seconds.
The t23 keyword sets the limit for the Clear Request retransmission timer (T23) on DTE devices.
x25 t23 secondsThe argument seconds is the amount of time in seconds. The default value is 180 seconds.
The t13 keyword sets the limit for the Clear Request retransmission timer (T13) on DCE devices.
x25 t13 secondsThe argument seconds is the amount of time in seconds. The default value is 60 seconds.
X.25 networks use maximum input and output packet sizes set by the network administration. You can set the communication server input and output packet sizes to match those of the network with the x25 subcommand keywords ips and ops respectively. Use the following commands:
x25 ips bytes x25 ops bytes The argument bytes is a byte count in the range of 16 through 1024. The default value is
128 bytes. Larger packet sizes are better because smaller packets require more overhead
processing. The only valid packet size values are 16, 32, 64, 128, 256, 512, 1024, 2048, and 4096.
To send a packet larger than the X.25 packet size over an X.25 virtual circuit, a communication server must break the packet into two or more X.25 packets with the M-bit ("more data" bit) set. The receiving device collects all packets with the M-bit set and reassembles them.
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. To set the window modulus, use the x25 modulo interface subcommand:
x25 modulo modulusThe argument modulus is either 8 or 128. The default value is 8. The value of the modulo parameter must agree with that of the device on the other end of the X.25 link.
To specify upper limits on the number of outstanding unacknowledged packets, use the x25 subcommand keywords win (for input window) and wout (for output window):
x25 win packets x25 wout packetsThe argument packets is a packet count. The packet count for win and wout can range from 1 to the window modulus. The default value is 2 packets.
The x25 win determines how many packets the communication server can receive before sending an X.25 acknowledgment; the number is one less than win. The wout limit determines how many sent packets can remain unacknowledged before the communication server uses a hold queue. To maintain high bandwidth utilization, assign these limits the largest number that the network allows.
You can instruct the communication server to send acknowledgment packets when it is not busy sending other packets, even if the number of input packets has not reached the win count. This approach improves line responsiveness at the expense of bandwidth.
To enable this option, use the x25 th subcommand:
x25 th delayThe argument delay must be between zero and the input window size. A value of 1 sends one Receiver Ready acknowledgment per packet at all times. The default value is zero, which disables the delayed acknowledgment strategy.
The communication server sends acknowledgment packets 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 communication server can send an acknowledgment per input packet.
This section describes the x25 keywords for setting the X.25 Level 3 facilities.
To set the default protocol, use the x25 default interface subcommands:
x25 default protocolThe default keyword specifies the protocol assumed by the communication server to interpret incoming calls with unknown Call User Data.
The argument protocol is one of the following keywords:
There is no initial default value. If you do not use the x25 default subcommand, the communication server clears any incoming calls with unknown Call User Data.
If you use this subcommand, the communication server assumes that these calls use the specified protocol.
Use the no x25 default subcommand to remove the protocol specified.
This subcommand is used when an incoming call is received without identifying Call User Data. Normally, the call is cleared when this subcommand is used; the incoming call is assumed to contain the specified default protocol.
To omit the calling address in outgoing calls, use the x25 suppress-calling-address interface subcommands:
x25 suppress-calling-addressThe suppress-calling-address keyword omits the calling (source) X.121 address in Call Request packets. This option is required for networks that expect only subaddresses in the calling address field. The calling address is sent by default.
Use the no x25 suppress-calling-address subcommand to reset this subcommand to the default state.
To omit the called address in outgoing calls, use the x25 suppress-called-address interface subcommands:
x25 suppress-called-addressThe suppress-called-address keyword omits the called (destination) X.121 address in Call Request packets. This option is required for networks that expect only subaddresses in the called address field. The called address is sent by default.
Use the no x25 suppress-called-address subcommand to reset this subcommand to the default state.
To instruct the communication server to accept all reverse charge calls, use the x25 accept-reverse interface subcommands:
x25 accept-reverseThe accept-reverse keyword causes the interface to accept reverse charge calls by default. This behavior can also be configured on a per-peer basis using the x25 map subcommand.
The no form disables this facility.
To force a packet-level restart when the link level is restarted, use the x25 linkrestart interface subcommand:
x25 linkrestartThe linkrestart keyword restarts X.25 Level 2 (LAPB) when errors occur. This behavior is the default and is necessary for networks that expect this behavior. The no option disables this facility.
To set the packet network carrier, use the following interface subcommand:
x25 rpoa name numberThe x25 rpoa interface subcommand specifies a list of transit Recognized Private Operating Agencies (RPOAs) to use, referenced by name. The argument name must be unique with respect to all other RPOA names. It is used in the x25 facility and x25 map interface subcommands. The argument number is a number that is used to describe an RPOA.
To define the number of packets to be held until a virtual circuit is established, use the x25 hold-queue interface subcommand:
x25 hold-queue queue-sizeThe argument queue-size defines the number of packets. By default, this number is zero. Use the no x25 hold-queue command without an argument to remove this command from the configuration file; enter the command with a queue size value of zero to return the default.
To override interface settings on a per-call basis, use the x25 facility interface subcommand:
x25 facility parameter valueThe facility keyword enables X.25 facilities, which are sent between DTE and DCE devices to negotiate certain link parameters.
The arguments parameter and value specify one of the following:
The following list illustrates how to configure a communication server interface to run DDN X.25:
interface serial 0 address 192.31.7.50 255.255.255.240 encapsulation DDNX25 x25 win 6 x25 wout 6 x25 ips 1024 x25 ops 1024 x25 t20 10 x25 t21 10 x25 t22 10 x25 t23 10 x25 nvc 2 x25 map IP 192.31.7.49 000000010300 BROADCAST
The communication server software makes it possible to limit access to the communication server from certain X.25 hosts using access lists. These access lists take advantage of the message field defined by Recommendation X.29, which describes procedures for exchanging data between two PADS or a PAD and a DTE device.
To define an item in an X.29 access list, use the x29 access-list configuration command. The command syntax follows:
x29 access-list number {permit|deny} regular-expressionThe argument number is a number between 1 and 199 you assign to the access list using the access-class line subcommand. It should be noted that the number does not determine priority of the access list, but rather is an arbitrary number assigned as a designation.
The keyword permit allows matching source X.121 addresses to access the communication server. The keyword deny allows users to specify that their call requests clear immediately.
The X.121 address follows the permit or deny keyword. The argument regular-expression is the address, with or without regular expression pattern matching characters, with which to compare for access. 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 will allow many addresses to be matched by a single regular expression. Refer to Table 1-2 and Table 1-3 earlier in this chapter and Appendix B for more information.
An access list can contain any number of access list items. The lists are processed in the order in which they are entered, with the first match causing the permit or deny condition, as specified. If an X.121 address does not match any of the regular expressions in the access list, access will be denied.
The no x29 access-list command deletes an entire access list. There is no way to delete a specific item from an X.29 access list.
The virtual terminals on a communication server can be configured with an incoming access class using the access-class line configuration command as follows:
access-class number inThe argument number is the number of the access list. This can be between 1 and 199.
This access-list number is used for both incoming TCP access and for incoming PAD access. In the case of TCP access, the communication server uses the IP access list defined using the access-list command. For incoming PAD connections, the same numbered X.29 access list is referenced. If you actually only want to have access restrictions on one of the protocols, then you can create an access list that permits all addresses for the other protocol.
Each translate subcommand can be configured with an access-list number. In the case of translation sessions that result from incoming PAD connections, the corresponding X.29 access list is used.
The following is an extensive example illustrating incoming permit conditions for all IP hosts and LAT nodes with specific characters in their names and a deny condition for X.25
connections to a printer. Outgoing connections, however, are less restricted.
! ! Permit all IP hosts, LAT nodes beginning with "VMS" and no X.25 ! connections to the printer on line 5 ! access-list 1 permit 0.0.0.0 255.255.255.255 lat access-list 1 permit ^VMS.* x29 access-list 1 deny .* ! line 5 access-class 1 in ! ! Meanwhile, permit outgoing connections to various places on all the ! other lines. ! ! Permit IP access within cisco access-list 2 permit 131.108.0.0 0.0.255.255 ! ! Permit LAT access to the Stella/blue complexes. lat access-list 2 permit ^STELLA$ lat access-list 2 permit ^BLUE$ ! ! Permit X25 connections to infonet hosts only. x29 access-list 2 permit ^31370 ! line 0 199 access-class 2 out
To create an X.3 profile script, use the x29 profile subcommand. The command syntax follows:
x29 profile name parameter:value [parameter:value]This subcommand sets up an X.3 profile script for use by the translate command.
The argument name is the name assigned to the profile.
The arguments parameter and value are the X.3 PAD parameter number and value separated by a colon. Optionally, more than one parameter and value can be included in the script.
When an X.25 connection is established, the system acts as if an X.29 SET PARAMETER packet has been sent containing the parameters and values set by this subcommand and sets the system accordingly.
The following profile turns local edit mode on when the connection is made and establishes local echo and line termination upon receipt of a Return. The name "linemode" is used with the translate subcommand to effect use of the profile.
x29 profile linemode 2:1 3:2 15:1
Refer to the "Protocol Translation" chapter for more information about the translate
subcommand.
The X.3 PAD parameters are described in the section "X.3 PAD Parameters," in the "User Commands" chapter.
To clear all virtual circuits at once, use the privileged EXEC command clear x25-vc. This command takes an interface type keyword (usually serial) and a unit number as arguments to identify the interface with which the virtual circuits are associated.
To clear a particular virtual circuit, use the clear x25-vc command. The command syntax follows:
clear x25 vc interface unit [lcn]This command clears all X.25 virtual circuits at once.
The argument interface is the interface type.
The argument unit is the interface unit number.
The optional argument lcn clears the specified virtual circuit.
Use the EXEC show commands described in this section to display information about the X.25 interface and virtual circuit operation. Use the EXEC command show interfaces to display general interface parameters and statistics.
To display a mapping of Internet to X.121 addresses, use the show x25 map EXEC command. The command syntax follows:
show x25 mapEach line of output shows the interface name, the Internet address, the X.121 address, and the type of mapping entry. Address-mapping types are PERMANENT (entered with the x25 map interface subcommand), INTERFACE, indicating the address of a network interface, and Defense Data Network (DDN), derived using the DDN mapping standard. If broadcasts are enabled for an address mapping, the keyword BROADCAST also appears in the output line.
If applicable, the line also shows the count of any logical channel numbers (LCNs) and a list of the LCNs for that address. An asterisk indicates the current LCN.
The following is sample command output:
Serial0: 192.31.7.49 000000010300 PERMANENT, BROADCAST, 2 LCNS: 1024, 1* Serial0: 000000020300 INTERFACE
To display information about packet transmission and X.3 PAD parameter settings, use the show x25 pad EXEC command. The command syntax follows:
show x25 padMost of the information displayed by this command will be used by an engineer to track problems.
The following is sample command output:
tty2, Incoming PAD connection
Total input: 61, control 6, bytes 129. Queued: 0 of 7 (0 bytes).
Total output: 65, control 6, bytes 696.
Flags: 1, State: 3, Last error: 1
ParamsIn: 1:1, 2:0, 3:2, 4:1, 5:1, 6:0, 7:21,
8:0, 9:0, 10:0, 11:14, 12:0, 13:0, 14:0, 15:1,
16:127, 17:21, 18:18, 19:0, 20:0, 21:0, 22:0,
ParamsOut: 1:1, 2:1, 3:2, 4:1, 5:0, 6:0, 7:4,
8:0, 9:0, 10:0, 11:14, 12:0, 13:0, 14:0, 15:0,
16:127, 17:21, 18:18, 19:0, 20:0, 21:0, 22:0,
LCI: 1, State: D1, Interface: Serial0
Started 0:11:10, last input 0:00:16, output 0:00:16
Connected to 313700540651
Window size input: 7, output: 7
Packet size input: 512, output: 512
PS: 1 PR: 5 ACK: 5 Remote PR: 1 RCNT: 0 RNR: FALSE
Retransmits: 0 Timer (secs): 0 Reassembly (bytes): 0
Held Fragments/Packets: 0/0
Bytes 696/129 Packets 65/61 Resets 0/0 RNRs 0/0 REJs 0/0 INTs 0/0
Total input/output displays the number of packets received or sent for this connection. Control displays the number of packets with Qbit set (X.29 control packets). Bytes displays the number of bytes in each direction. Queued displays the number of unread packets waiting for this connection. Waiting to send displays the local data packetized bit not sent (part of a line). Flags, state, last error displays data useful only to Cisco, for detecting errors and tracing initialization status. Params In displays the parameters read from the PAD at the start of the connection. ParamsOut displays the active X.3 parameters. LCI data displays the x25 state of the connection.
The line beginning LCI: starts a display of the status of the X.25 virtual circuit associated with this PAD connection, and is the same display seen when the show x25 vc command is executed.
To display the details of the active X.25 switched virtual circuits, use the show x25vc EXEC command. The command syntax follows:
show x25 vc [lcn]The optional argument lcn is specified to examine a particular virtual circuit. The following is sample command output:
LCI: 1024, State: D1, Interface: Serial0 Started 0:00:06, last input 0:00:06, output 0:00:06 Connected to 31370 Window size input: 7, output: 7 Packet size input: 512, output: 512 PS: 2 PR: 2 ACK: 2 Remote PR: 2 RCNT: 0 RNR: FALSE Retransmits: 0 Timer (secs): 0 Reassembly (bytes): 0 Held Fragments/Packets: 0/0 Bytes 48/10 Packets 2/2 Resets 0/0 RNRs 0/0 REJs 0/0 INTs 0/0
Some of the command output is specific to the Cisco implementation of X.25. For example, the Started field shows the number of hours, minutes, and seconds since the virtual circuit was created. A Precedent field on the third line will appear only when you have specified DDN encapsulation, and will indicate IP precedence.
On the sixth line, the PS and PR fields show the current send and receive sequence numbers, respectively. The Remote PR field shows the last number received from the other end of the circuit. The RCNT field shows the count of unacknowledged input packets. The RNR field shows the state of the Receiver Not Ready flag.
On the seventh line, the Retransmits field shows the number of times the current packet has been retransmitted. The Timer field, if nonzero, shows the current value in seconds of the LCI event timer. The Reassembly field shows the number of bytes received for a partial packet (a packet in which the M-bit is set).
On the eighth line, the Fragments part of the Held Fragments/Packets field shows the number of X.25 packets being held. (In this case, fragment refers to the X.25 fragmentation of IP data packets.) The Packets part of the Held Fragments/Packets field shows the number of IP packets currently being held pending the availability of resources, such as the establishment of the virtual circuit.
On the last line, the Bytes field shows the number of bytes sent and received. The Packets, Resets, RNRs, REJs, and INTs fields show sent and received counts for each packet type.
To display the routes assigned by the x25 route command, enter the show x25 route EXEC command.
show x25 routeSample output follows:
Number X.121 CUD Forward To 1 03$ translation, 0 uses 2 22220102 translation, 0 uses 3 11110101 translation, 0 uses 4 ^1111 Serial0, 0 uses 5 ^2222 Serial1, 0 uses 6 ^3333 Serial2, 0 uses 7 ^4444 Serial3, 0 uses
Use the privileged EXEC debugging commands described in this section to monitor error information about X.25 traffic. For each debug command, there is a corresponding undebug command to disable the reports.
To enable logging of LAPB (X.25 Level 2) transactions, use the debug lapb EXEC command.
To log all the X.25 circuit activities and traffic, use the debug x25 EXEC command:
To log X.25 events, use the debug x25-events EXEC command.
This command enables the monitoring of all X.25 traffic but does not display information about X.25 data or acknowledgment packets. Unlike the debug x25 command, the debug x25-events command does not report all data activity, thus reducing the volume of output.
Unlike the debug x25 command, the debug x25-events command does not report all data activity, thereby producing terse output.
The debug pad command shows debugging for all PAD connections.
To log X.25 activity on virtual circuits, use the debug x25-vc EXEC command.
This command enables logging of X.25 activity on all virtual circuits. To log this activity for a particular virtual circuit, specify an LCN by adding the optional argument lcn.
The following is a sample debug x25-vc command output:
Serial0 (704760940): X25 O R2 RESTART (5) 8 lci 0 cause 0 diag 0 Serial0 (704760944): X25 I R2 RESTART (5) 8 lci 0 cause 7 diag 0 Serial0 (704762944): X25 O D2 RESET REQUEST (5) 8 lci 1 cause 0 diag 0 Serial0 (704762952): X25 I D2 RESET CONFIRMATION (3) 8 lci 1 Serial0 (704763372): X25 O P2 CALL REQUEST (19) 8 lci 10 From(14): 31250000000101 To(14): 31109090096101 Facilities: (0) Cannot route call Serial0 (704763372): X25 I P6 CLEAR REQUEST (5) 8 lci 10 cause 19 diag 67 Serial0 (704763839): X25 O P6 CLEAR CONFIRMATION (3) 8 lci 10
For each event, the first field identifies the interface on which the activity occurred, the second field indicates the time between packets (in milliseconds), and the third field indicates that it was an X.25 event. The fourth field indicates whether the X.25 packet was input (I) or output (O). The fifth field is the state of the interface: R1 is the normal ready state, R2 indicates the DTE not-ready state, and R3 indicates the DCE not-ready state.
The sixth field is the type of the X.25 packet that triggered the event, and the seventh field (in parentheses) gives the total length of the X.25 packet in bytes. The eighth field is the window modulus. The ninth field (labeled lci) shows the virtual circuit number. The tenth field (labeled cause) gives the cause code, and the eleventh field (labeled diag) gives the diagnostic code.
For Call Request and Call Connected packets, the communication server shows additional information on separate lines. The From field shows the calling X.121 address and the To field shows the called X.121 address. The number in parentheses after the field name [(14)] specifies the number of digits in the address. The Facilities field indicates the length (in bytes) of the requested facilities and the facilities contents.
This section provides an alphabetical list of the global configuration commands.
Displays the one-to-one mapping of the host IP addresses and the remote BFE IP addresses.
[no] x25 route [# position] x121-pattern [cud pattern] interface interface-name
[no] x25 route [# position] x121-pattern [cud pattern] ip ip-address
[no] x25 route [# position] x121-pattern [cud pattern] alias interface-name
Inserts or removes an entry in the X.25 routing table. The optional positional parameter (# followed by an integer) designates after which existing entry to insert or delete the new entry. No positional parameter appends the entry. The argument x121-pattern is the X.121 called address. The Call User Data field (cud pattern) can be entered as an ASCII string and specifies the data after the protocol identification field, which is four bytes. All pattern arguments can be entered as regular expressions. The interface keyword and interface-name argument define the interface. The ip keyword and ip-address argument specify an IP address. The alias keyword and interface-name argument permits a way for other X.121 addresses to be treated as local addresses. Enter the no x25 route command with the appropriate arguments and keywords to remove an entry from the table.
[no] x29 access-list number {permit|deny} regular-expression
Defines an item in an X.29 access list. The argument number is the number of the access list. This can be between 1 and 199. The keyword permit allows the source X.121 addresses matching the regular expression to access the server. The keyword deny allows users to specify that their call requests clear immediately. The argument regular expression is a regular expression similar to those used in the translate and X.25-route commands. The no x29 access-list command deletes an entire access list.
This section provides an alphabetical list of all the interface subcommands used to configure the X.25 interface.
encapsulation encapsulation-type
Specifies the type of X.25 support (commercial or DDN) and whether the connection is Data Terminal Equipment (DTE) or Data Communications Equipment (DCE). DDN X.25, a variant of X.25 with automatic Internet-to-X.121 address conversion, is used primarily to pass Internet traffic on the Defense Data Network. Most connections to X.25 switches are DTE. This subcommand takes one argument, encapsulation-type. X.25 types are: bfex25, ddnx25, ddnx25-dce, hdh, lapb, lapb-dce, x25, x25-dce.
Enables the HDH protocol (also known as the HDLC Distant Host or 1822-J protocol) which provides a method for running the 1822 protocol over synchronous serial lines instead of over special-purpose 1822 hardware. The packet keyword specifies the HDH packet mode; the message keyword specifies the HDH message mode.
[no] ip tcp header-compression [passive]
Implements header compression on IP packets.
Specifies the maximum permissible number of outstanding frames, called the "window size." The argument window-size is a packet count from 1 to 7. The default value is 7 packets.
Specifies the maximum number of bits a frame can hold. The n1 keyword specifies the maximum number of bits (N1) a frame can hold. The argument bits is the number of bits from 1 through 12000, and must be a multiple of eight. The default value is 12000 bits (1500 bytes).
Specifies the maximum number of times an acknowledgment frame can be retransmitted. The argument retries is the retransmission count from 1 through 255. The default value is 20 retransmissions.
Sets the limit for the retransmission timer (the LAPB T1 parameter). The argument milliseconds is the number of milliseconds from 1 through 64000. The default value is 3000 milliseconds.
Instructs the communication server to accept all reverse charge calls. This behavior can also be configured on a per-peer basis using the x25 map subcommand. The no variation resets the default state.
Sets the X.121 address of a particular network interface. The address is assigned by the X.25 network. The argument X.121-address is a variable-length X.121 address.
Configures how or if the communication server will participate in making the decision to enter emergency mode. The default value is no. When the communication server's mode is set to decision, you must indicate the type of decision. If the decision type is set to no the communication server will not participate in making the decision to enter or leave emergency mode. If the decision type is set to yes, then the communication server will participate in entering emergency mode. The communication server will enter emergency mode when diagnostic packet 226 is received, indicating the emergency mode window is open, and when it receives clear request packets indicating that address translation is required. If the decision type is set to ask, the communication server will prompt the administrator to use an EXEC command to put the communication server into emergency mode and take the communication server out of emergency mode.
x25 bfe-emergency {never|always|decision}
Configures under what circumstances the communication server will enter emergency mode. The default value is never. When set to never the communication server does not go into emergency mode. When set to always, the communication server enters emergency mode when directed to by the BFE. When set to decision, the communication server waits until it receives a diagnostic packet from the Blacker Front End (BFE), indicating that an emergency mode window is open, before it enters into emergency mode.
Specifies or removes the protocol assumed by the communication server to interpret calls with unknown Call User Data. The argument protocol sets the default protocol and is either ip or pad.
[no] x25 facility parameter value
Overrides interface settings on a per-call basis and enables X.25 facilities, which are sent between DTE and DCE devices to negotiate certain link parameters.
The arguments parameter and value can be as follows:
x25 hic circuit-number
Sets the highest incoming-only channel (HIC) virtual circuit number. The argument circuit-number is a VCN from 1 through 4095, or 0 if there is no incoming-only VC range. The default value is 0. This parameter may not be changed while the line protocol is up.
x25 hoc circuit-number
Sets the highest outgoing-only channel (HOC) virtual circuit number. The argument circuit-number is a VCN from 1 through 4095, or 0 if there is no outgoing-only VC range. The default value is 0. This parameter may not be changed while the line protocol is up.
[no] x25 hold-queue queue-size
Defines the number of packets to be held until a virtual circuit is established. The argument queue-size defines the number of packets. By default, this number is zero. Use the no x25 hold-queue command without an argument to remove this command from the configuration file; enter the command with a queue size value of zero to return the default.
Prevents overruns on X.25 switches for traffic through the VCs. The argument minutes is the number of minutes by which to prevent calls to a previously failed destination. Incoming calls will still be accepted.
[no] x25 host name 121-address [cud call-user-data]
Defines a static host-name-to-address mapping in the host cache. The argument name is the host name. The keyword cud sets the Call User Data field in the X.25 call request packet.
x25 htc circuit-number
Sets the highest two-way virtual circuit number. The argument circuit-number is a VCN from 1 through 4095, or 0 if there is no two-way VC range. The default value is 1024 for X.25 network service interfaces; CMNS network service interfaces have a default value of 4095. This parameter cannot be changed while the line protocol is up.
Sets the period of inactivity once an SVC has been cleared. The argument minutes is the number of minutes in the period. The default value is zero, which causes the communication server to keep the SVC open indefinitely. Both calls originated and terminated by the communication server are cleared.
Enables or disables the ability to open a new virtual circuit based on the IP Type of Service (TOS) field. By default, communication servers open one virtual circuit for each type of service.
Set the communication server packet size to match those of the network. The ips keyword specifies the communication server input packet size while the keyword ops specifies the communication server output packet size. The argument bytes is a byte count from the set {16, 32, 64, 128, 256, 512, 1024, 2048, 4096}. The default value is 128 bytes. Larger packet sizes are better, because smaller packets require more overhead processing. These parameters may not be changed while the line protocol is up.
x25 lic circuit-number
Sets the lowest incoming-only channel virtual circuit number. The argument circuit-number is a VCN from 1 through 4095, or 0 if there is no incoming-only VC range. The default value is 0. This parameter may not be changed while the line protocol is up.
Forces a packet-level restart when the link level is restarted and restarts X.25 Level 2 (LAPB) when errors occur. This behavior is the default and is necessary for networks that expect this behavior. The no variation resets the default state.
x25 loc circuit-number
Sets the lowest outgoing-only channel virtual circuit number. The argument circuit-number is a VCN from 1 through 4095, or 0 if there is no outgoing-only VC range. The default value is 0. Do not change this parameter while the line protocol is up.
x25 ltc circuit-number
Sets the lowest two-way channel virtual circuit number. The argument circuit-number is a VCN from 1 through 4095, or 0 if there is no two-way VC range. The default value is 1. This parameter may not be changed while the line protocol is up.
[no] x25 map protocol-keyword protocol-address X.121-address [option1 ... [option]]
Specifies a network-protocol-to-X.121 address mapping from Internet-to-X.121. For the communication server, the argument protocol-keyword can only be ip. The address arguments specify the network-protocol-to-X.121 mapping. The option arguments add certain features to the mapping specified, and can be any of the following, up to six. (They must be specified in the order listed.)
x25 map compressedtcp ip-address x.121-address [options]
Makes the X.25 calls complete for compressed packets. The argument ip-address is the IP address and x.121-address is the X.121 address. The options arguments are the same options as those for the x25 map command. The Call User Data of compressed TCP calls is the single byte 0xd8.
Sets the modulus. The argument modulus is either 8 or 128. The default value is 8. The value of the modulo parameter must agree with that of the device on the other end of the X.25 link. Do not change this parameter while the line protocol is up.
Specifies the maximum number of switched virtual circuits that can be open simultaneously to one host. The argument count is a circuit count from 1 to 8; the default is 1.
x25 remote-red host-ip-address remote-black Blacker-Internet-address
Sets up a table containing the BFE nodes (host or gateways) to which the communication server would be sending packets. The host-ip-address argument is the IP address of the host or a router that the packet are being sent to. The Blacker-Internet-address argument is the IP address of the remote Blacker front end unit in front of the host that the packet is being sent to.
Specifies a list of transit RPOAs to use, referenced by name. The argument name must be unique with respect to all other RPOA names. It is used in the x25 facility and x25 map interface subcommands. The argument number is a number that is used to describe an RPOA.
[no] x25 suppress-called-address
Omits the called (destination) X.121 address in Call Request packets. This option is required for networks that expect only subaddresses in the called address field. The called address is sent by default. Use the no x25 suppress-called-address subcommand to reset this subcommand to the default state.
[no] x25 suppress-calling-address
Omits the calling (source) X.121 address in Call Request packets. This option is required for networks that expect only subaddresses in the calling address field. The calling address is sent by default. The no variation resets the default state.
Sets the limit for the Restart Request retransmission timer (T10) on DCE devices. The argument seconds is a time value in seconds. The default value is 60 seconds.
Sets the limit for the Call Request retransmission timer (T11) on DCE devices. The argument seconds is a time value in seconds. The default value is 180 seconds.
Sets the limit for the Reset Request retransmission timer (T12) on DCE devices. The argument seconds is a time value in seconds. The default value is 60 seconds.
Sets the limit for the Clear Request retransmission timer (T13) on DCE devices. The argument seconds is a time value in seconds. The default value is 60 seconds.
Sets the limit for the Restart Request retransmission timer (T20) on DTE devices. The argument seconds is a time value in seconds. The default is 180 seconds.
Sets the limit for the Call Request retransmission timer (T21) on DTE devices. The argument seconds is a time value in seconds. The default value is 200 seconds.
Sets the limit for the Reset Request retransmission timer (T22) on DTE devices. The argument seconds is a time value in seconds. The default value is 180 seconds.
Sets the limit for the Clear Request retransmission timer (T23) on DTE devices. The argument seconds is a time value in seconds. The default value is 180 seconds.
Instructs the communication server to send acknowledgment packets when it is not busy sending other packets, even if the number of input packets has not reached the win count, which improves line responsiveness at the expense of bandwidth.
The argument delay must be between zero and the input window size. A value of 1 sends one Receiver Ready acknowledgment per packet at all times. The default value is zero, which disables the delayed acknowledgment strategy.
x25 win packets
x25 wout packets
Set the upper limits on the number of outstanding unacknowledged packets.
The win keyword specifies the upper limits of the number of outstanding unacknowledged packets in the input window.
The wout keyword specifies the upper limits of the number of outstanding unacknowledged packets in the output window.
The argument packets is a packets count. The packet count for win and wout can range from 1 to the window modulus. The default value is 2 packets. These parameters may not be changed while the line protocol is up.
[no] x29 profile name parameter:value [parameter:value]
Creates an X.3 profile for use by the translate command. The argument name is the name assigned to the profile. The arguments parameter and value are the X.3 PAD parameter numbers and values separated by a colon.
This section provides a summary of the X.25 EXEC command.
bfe {enter|leave} interface-type unit
If the system is configured with the x25 bfe-decision command and decision type ask, you will be prompted to indicate whether you want the communication server to enter or leave Blacker Emergency Mode. Respond with this EXEC command. Enter the keyword enter to enter this mode. Enter the keyword leave to leave this mode. The interface-type argument is the interface name and unit is the interface number.
|
|