|
|
This chapter describes the configuration tasks for the Cisco packet-switched software. These tasks include configuring the following protocols and services:
Summaries of the configuration commands available for these protocols and services are provided at the end of this chapter.
X.25 Level 2, or LAPB (Link Access Procedure, Balanced), is a data encapsulation protocol that operates at Level 2 (the data link level) 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.
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.
Using LAPB under noisy conditions can result in greater throughput than HDLC encapsulation. When LAPB detects a damaged frame, the router 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 retransmissions.
However, if the line is not noisy, the lower overhead of HDLC encapsulation is more efficient than LAPB. When using long delay satellite links, the lock step behavior of LAPB makes the use of HDLC encapsulation the better choice.
The X.25 Recommendation distinguishes between two types of X.25 hosts: data terminal equipment (DTE) in LAPB encapsulation hosts, and data circuit-terminating equipment (DCE) in LAPB encapsulation hosts.
A router using LAPB encapsulation can act as a DTE or DCE device at the protocol level.
To run datagrams of a single protocol over a serial interface using the LAPB encapsulation, use the 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. By default, the single protocol is IP.
To configure another protocol, use the interface subcommand:
lapb protocol keywordPossible protocol keywords include ip, xns, decnet, appletalk, vines, clns, novell, and apollo.
To enable use of multiple network protocols on the same line at the same time, use the keyword multi-lapb or multi-lapb-dce for DTE or DCE operation, respectively:
encapsulation {multi-lapb|multi-lapb-dce}For example, with the multi-lapb or multi-lapb-dce keyword, you can use IP, DECnet, and XNS at the same time. Both ends of the line must use the same encapsulation: either lapb or multi-lapb. One end of each line 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."
LAPB parameters are set with the lapb interface subcommand. The interface must be running with either the LAPB or X.25 encapsulation method specified by the encapsulation interface subcommand. This subcommand takes two required arguments, parameter and value. The 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 | frames | 1-7 | 7 |
| n1 | bits | 1-16384 | 12000 |
| n2 | times | 1-255 | 20 |
| t1 | milliseconds | 1-64000 | 3000 |
The retransmission timer determines how long a transmitted frame can remain unacknowledged before the router polls for an acknowledgment. To set the limit for the retransmission timer (the LAPB T1 parameter), use the following interface subcommand:
lapb t1 millisecondsThe argument milliseconds is the number of milliseconds from 1 through 64000. The default value is 3,000 milliseconds.
For X.25 networks, the router 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 several maximum-sized frames to complete one round trip on the link. If the timer setting is too small, the router will poll before the acknowledgment frame can return, which results in an effective loss of bandwidth. If the timer setting is too large, the router 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 four. 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 16,384, and must be a multiple of eight. The default value is 12,000 bits (1500 bytes).
When connecting to an X.25 network, use the N1 parameter value set by the network administration, 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 one to seven. The default value is seven packets.
To define the number of packets to be held on an interface, use the lapb hold-queue interface subcommand:
lapb hold-queue queue-sizeThe argument queue-size defines the number of packets. By default, this number is 10. Use the no lapb hold-queue command without an argument to remove this command from the configuration file. Enter the command with a queue-size of zero to allow an unlimited number of packets.
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 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 router. 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) or (R) for "command" or "response," respectively.
The software for the Cisco network server products supports the 1980 and 1984 Recommendation X.25 published by the French International Telegraph and Telephone Consultative Committee (CCITT). The Recommendations specify connections between data terminal equipment (DTE) and data communications equipment (DCE). The Defense Data Network (DDN) and the International Standards Organization (ISO) specify the use of X.25 protocol for computer communications. Many public and private networks also use Recommendation X.25 as their interface technology.
The X.25 model is a telephone network for computer data communications. To start data communications, one computer system calls another to request a communications 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.
In addition to providing remote terminal access, X.25 networks provide bridging capability using a growing list of protocols--the Internet Protocol (IP), DECnet, XNS, ISO CLNS, AppleTalk, Novell IPX, Banyan VINES, and Apollo Domain.
The following sections provide an overview of the Cisco X.25 implementation, describing the different encapsulation methods supported by X.25, and X.25 as a datagram transport, with special attention to the IP protocol. This is followed by descriptions of the DDN X.25 support provided by the Cisco routers, and descriptions of how to configure X.25 switching and bridging. Finally, the configuration of the X.25 Level 3 parameters, and the X.25 Level 2 facilities are discussed. A summary of the interface subcommands are provided at the end of the chapter.
Cisco Systems' X.25 support can be used in two different ways:
Remote X.25 switching encapsulates the X.25 packet-level inside a TCP connection, allowing disjointed X.25 networks to be connected via a TCP/IP-based network.
This section describes the different encapsulation methods and commands that Cisco supports for commercial and private X.25 networks.
Methods of encapsulation for DDN networks are described in the section "Configuring the Datagram Transport on DDN Networks" later in this chapter.
A router 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-dceCisco Systems' X.25 support is most commonly configured as a transport for datagrams across an X.25 network. This is accomplished by first establishing a mapping between protocol addresses (for example, IP or DECnet) and the X.121 addresses of the X.25 network. When datagrams for a particular destination are routed for the first time, a virtual circuit is set up to the appropriate X.121 address. The Call User Data portion of the initial Call Request identifies the protocol of the datagrams being carried by a particular virtual circuit. If multiple protocols are in use, multiple virtual circuits will be opened.
To transport datagrams using X.25 Level 3, the router must map network-protocol addresses to X.121 addresses and vice versa. For example, Figure 1-1 illustrates Hosts A and B that want to communicate via Routers X and Y, which have an X.25 link between them.
To send a packet to Host B, Host A must first send the packet to Router X. From the destination address in the packet and from its routing information, Router X determines that it must send the packet to Router Y over the X.25 network. Router X must then determine the X.121 address for Router Y to open a virtual circuit. Router X uses its network-protocol-to-X.121 address map to convert the protocol address of Router Y to the equivalent X.121 address. Router X can now make the call to create a virtual circuit.
Except in the case of IP using DDN X.25 encapsulation, there is no standard method for dynamically determining these mappings. Instead, static mapping tables must be configured into each router.
To display the network-protocol-to-X.121 address mapping, use the EXEC command show x25 map.
To specify a network-protocol-to-X.121 address mapping such as Internet-to-X.121 or DECnet-to-X.121, use the x25 map interface subcommand:
x25 map protocol-keyword protocol-address X.121-address [option1... option6]The argument protocol-keyword is one of these keywords:
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.
When included in the x25 map command, these options must be specified in the order listed below:
To retract a network-protocol-to-X.121 mapping, use the no x25 map interface subcommand with the appropriate network protocol and X.121 address arguments.
For ping commands to work in an X.25 environment (when load-sharing over multiple serial lines), you must include entries for all adjacent interface IP addresses in the x25 map command for each serial interface. The example configuration that follows illustrates this point.
For example, consider two routers, CiscoA and CiscoB, communicating with each other over two serial lines via an X.25 PDN (see Figure 1-2) or over leased lines. In either case, all serial lines must be configured for the same IP subnet address space. In order to allow for successful ping commands, the configuration might be as in the following lists.In any event, a similar configuration is required for the same subnet IP addresses to work across X.25.
! Configuration for Cisco A ! ------------------------- int s 1 ip 131.108.170.1 255.255.255.0 x25 address 31370054068 x25 map ip 131.108.170.3 31370054065 x25 map ip 131.108.170.4 31370054065 int s 2 ip 131.108.170.2 255.255.255.0 x25 address 31370054069 x25 map ip 131.108.170.4 31370054067 x25 map ip 131.108.170.3 31370054067 ! allow either source address x25 route 31370054069 alias Serial1 x25 route 31370054068 alias Serial2 ! Configuration for Cisco B ! ------------------------- int s 0 ip 131.108.170.3 255.255.255.0 x25 address 31370054065<<<<<<< x25 map ip 131.108.170.1 31370054068 x25 map ip 131.108.170.2 31370054068 int s 3 ip 131.108.170.4 255.255.255.0 x25 address 31370054067<<<<<<< x25 map ip 131.108.170.2 31370054069 x25 map ip 131.108.170.1 31370054069 ! allow either source address x25 route 31370054067 alias Serial0 x25 route 31370054065 alias Serial3
When netbooting over X.25, you cannot netboot via a broadcast. You must netboot from a specific host. Also, an x25 map command must exist for the host that you will netboot from.
For example, if file gs3-bfx is to be booted from a host with IP address 131.108.126.2, the following would need to be in the configuration:
boot system gs3-bfx 131.108.126.2 interface Serial 0 encapsulation x25 x25 map IP 131.108.126.2 10001 broadcast
The x25 map command is used to map an IP address into an X.121 address. There must be an x25 map command which matches the IP address given on the boot system command line. The following is an example of such a configuration:
boot system gs3-bfx.83-2.0 131.108.13.111 ! interface Serial 1 ip address 131.108.126.200 255.255.255.0 encapsulation X25-DCE x25 address 10004 x25 map IP 131.108.13.111 10002 broadcast lapb n1 12040 clockrate 56000
In this case, 10002 is the X.121 address of the remote router that can get to host 131.108.13.111.
The remote router must have the following x25 map entry:
x25 map IP 131.108.126.200 10004 broadcast
This allows the remote router to return a boot image (from the netboot host) to the router netbooting over X.25.
TCP header compression is supported over X.25 links through the use of two interface subcommands:
The interface subcommand ip tcp header-compression is detailed in the chapter "Routing IP."
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 compressed packets take another VC.
The interface subcommand x25 map compressedtcp is required to make the X.25 calls complete for compressed packets. The command syntax is:
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 argument accepts the same options as those for the x25 map command described in the preceding section.
The Call User Data (CUD) of compressed TCP calls is the single byte 0xd8.
The no x25 map compressedtcp disables TCP header compression for the link.
Cisco's transparent bridging software supports bridging of X.25 frames. To configure this capability, add this variation of the x25 map interface subcommand to the bridging configuration file:
x25 map bridge X.121-address broadcast [options-keywords]The command specifies Internet-to-X.121 address mapping. The keyword bridge specifies bridging over X.25. The argument X.121-address is the X.121 address. The keyword broadcast is required for bridging X.25 frames. The argument options-keywords represents services that may be added to this map. See the section "Setting Address Mappings," earlier in this chapter. For further information about bridging on X.25, and for an example configuration, refer to the chapter "Configuring Transparent Bridging."
The Cisco router 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 sequence, and addresses.
Permanent Virtual Circuits (PVCs) are the X.25 equivalent of leased lines; they are never disconnected. To establish a PVC, use the x25 pvc interface subcommand:
x25 pvc circuit protocol-keyword protocol-addressThe argument circuit is a virtual-circuit channel number and it must be less than the lower limit of the incoming call range in the virtual circuit channel sequence.
The argument protocol-keyword can be one of these keywords:
The argument protocol-address is that of the host at the other end of the PVC.
PVCs are not supported for ISO CLNS. Switched Virtual Circuits (SVCs) are sufficient for CLNS connections over X.25.
To delete a PVC, use the no x25 pvc interface subcommand with the appropriate channel number, protocol keyword, and protocol address.
The Call Request packet that sets up a virtual circuit contains a field called the Call User Data field. Typically, the first byte of Call User Data is used by Cisco software to distinguish which high-level protocol will be carried by a particular virtual circuit.
Table 1-2 lists the hexadecimal values of the initial byte of Call User Data and its corresponding network level protocol. The use of 0x81 for ISO 8473 (CLNS) is an ISO standard. The use of 0xCC for Department of Defense IP is defined by RFC 877. The use of C0 00 80 C4 is defined by Banyan. The other values are meaningful only to Cisco software. All the values are padded with three bytes of 0x00, except for VINES, the BFE X.25 encapsulation and CLNS, which follow ISO 8473 requirements.
| Protocol | Initial CUD Byte |
|---|---|
| ISO CLNS | 0x81 |
| DOD IP | 0xCC |
| PUP | 0xCE |
| Chaosnet | 0xCF |
| DECnet | 0xD0 |
| XNS | 0xD1 |
| AppleTalk | 0xD2 |
| Novell | 0xD3 |
| Apollo Domain | 0xD4 |
| VINES | 0xC0 0x00 0x800xC4 |
| Bridges | 0xD5 |
To set the default protocol, use the x25 default command. The full syntax follows:
x25 default protocolThe x25 default command specifies the protocol assumed by the router to interpret calls with unknown Call User Data. The argument protocol sets the default protocol and is either ip or pad. Use this subcommand to change the action taken when an incoming call is received without identifying Call User Data. Normally, the call is cleared. When you use this subcommand, the incoming call is assumed to contain the specified default protocol.
The no x25 default subcommand removes the protocol specified.
To display the network-protocol-to-X.121 address mappings, enter this command at the EXEC prompt:
show x25 mapThe following is a sample output:
Serial0: novel 10.0.0c00.7b22 000000220200 PERMANENT, 1 LCN: 4* Serial0: IP 10.1.0.1 000000010100 CONSTRUCTED Serial1: appletalk 128.1 000000010000 PERMANENT Serial1: decnet 28.1 000000020000 PERMANENT BROADCAST Serial1: ip 128.1.0.3 000000030000 PERMANENT, 2 LCN: 1023*, 1024
Each line of output shows the interface name, the protocol type, the protocol address, the X.121 address, and the address-mapping type. The address-mapping types are PERMANENT, entered with the x25 map interface subcommand, INTERFACE, indicating the address of a router network interface, and CONSTRUCTED (derived using the DDN address conversion scheme).
If broadcasts are enabled for an address mapping, the word BROADCAST also appears on the output line. Finally, each line also shows the number of Logical Circuit Numbers (LCNs) and, if greater than zero, a list of the LCNs for the protocol/X.121 address. An asterisk marks the current LCN.
The following example shows the complete configuration for a serial interface connected to a commercial X.25 PDN for routing the IP protocol. The IP subnetwork address 131.108.9.0 has been assigned for the X.25 network.
interface serial 2 ip address 131.108.9.1 255.255.255.0 ! encapsulation X25 ! ! The "bandwidth" command is not part of the X.25 configuration. It is ! especially important to understand that it does not have any connection with ! with the X.25 entity of the same name. Cisco "bandwidth" commands are used by ! IP routing processes (currently only IGRP) to determine which lines are the best ! choices for traffic. Since the default is 1544, and X.25 service at that rate ! is not generally available, most X.25 interfaces that are being used with IGRP ! in a real environment will have "bandwidth" settings. ! ! This is a 9.6 Kbaud line: ! bandwidth 10 ! ! These Level 3 parameters are defaults; they need to ! match PDN defaults. They are negotiable on a per-call basis: ! x25 win 7 x25 wout 7 x25 ips 512 x25 ops 512 ! ! You must specify an X.25 address, which you get from the PDN: ! x25 address 31370054065 ! ! The following Level 3 parameters have been set to match the network. ! You generally need to change some Level 3 parameters, most often ! those listed below. You may not need to change any Level 2 ! parameters, however. ! x25 hic 32 x25 htc 32 x25 hoc 32 x25 idle 5 x25 nvc 2 ! ! The following commands configure the X.25 map. If you want to exchange ! routing updates with any of the routers, they would need "broadcast" flags. ! If the X.25 network is the only path to them, static routes are ! generally used to save on packet charges. If there is a redundant path, ! it might be desirable to run a dynamic routing protocol. ! x25 map IP 131.108.9.3 31370019134 ACCEPT-REVERSE ! (ACCEPT-REVERSE allows collect calls) x25 map IP 131.108.9.1 31370054065 x25 map IP 131.108.9.2 31370053087 ! ! The PDN cannot handle fast back-to-back packets, so the !"transmitter-delay" command is used to slow down the MCI card: ! transmitter-delay 1000
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 the DDN X.25 Basic Service can act as a DTE or DCE device. To set operation type, use the encapsulation interface subcommand:
encapsulation {ddnx25|ddnx25-dce}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 better service for virtual circuits with higher 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 permitted number of virtual circuits.
For situations requiring a high degree of security, the Defense Data Network Blacker Front- End Encryption (BFE) device is supported. If the router is attached to such a device, the bfex25 keyword must be used with the encapsulation subcommand:
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 DDN X.25 standard implementation includes a scheme for dynamically mapping all classes of Internet addresses to X.121 addresses without a table. This scheme requires that the Internet addresses conform to the formats shown in Table 1-3. These formats segment the Internet addresses into network (N), host (H), logical address (L), and IMP (I) portions. (The acronym IMP, which stands for Interface Message Processor, is the predecessor of PSN, which stands for Packet Switch Node.) For the BFE encapsulation, the Internet address is segmented into Port (P), Domain (D), and BFE ID number (B).
The DDN conversion scheme uses the host and IMP portions of an Internet address to create the corresponding X.121 address. Strictly speaking, the DDN conversion mechanism is limited to Class A Internet addresses. However, the router can convert Class B and Class C addresses as well. As indicated in Table 1-3, this method uses the last two octets of a Class B address as the host and IMP identifiers, and the upper and lower four bits in the last octet of a Class C address as the host and IMP identifiers, respectively.
The DDN conversion scheme uses a physical address mapping if the host identifier is numerically less than 64. (This limit derives from the fact that a PSN cannot support more than 64 nodes.) If the host identifier is numerically larger than 64, the resulting X.121 address is called a logical address. The DDN does not use logical addresses.
The format of physical DDN X.25/X.121 addresses is ZZZZFIIIHHZZ(SS), where each character represents a digit. ZZZZ represents four zeros, F is zero to indicate a physical address, III represents the IMP (PSN) octet from the Internet address padded with leading zeros, HH is the host octet from the Internet address padded with leading zeros, and ZZ represents two zeros. (SS) represents the optional and unused subaddress.
The physical and logical mappings of the DDN conversion scheme always generate a 12-digit X.121 address. Subaddresses are optional; when added to this scheme, the result is a 14-digit X.121 address. The DDN does not use subaddressing.
Packets using routing and other protocols that require broadcast support can successfully traverse X.25 networks, including the DDN. This traversal requires the use of network-protocol-to-X.121 maps because the router must know explicitly where to deliver broadcast datagrams. (X.25 does not support broadcasts.) You can mark network-protocol-to-X.121 map entries to accept broadcast packets; the router then sends broadcast packets to hosts with marked entries. If you do not specify the address for an interface configured for DDN X.25, the router uses the DDN mapping technique to obtain the X.121 address of an interface.
To display the network-protocol-to-X.121 address mapping, enter this command at the EXEC prompt:
show x25 mapNormally the X.25 parameters of a DDN connection are configured using the x25 and lapb interface subcommands described earlier in this chapter. There are a few DDN-specific subcommands, however.
The Cisco 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-precedenceBy default, Cisco routers 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.
As mentioned earlier, 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 router 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 interface subcommand:
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 CSA-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.
In addition to transporting datagrams, the Cisco X.25 software implementation allows switched virtual circuits to be forwarded from one X.25 interface to another and from one Cisco router to another. The forwarding behavior can be controlled based on a locally built table.
The X.25 switching subsystem supports the following facilities and parameters:
Higher-level protocols may share an X.25 encapsulated serial interface with the X.25 switching support. The ability to switch or forward X.25 virtual circuits can be done in two different ways:
Running X.25 over TCP/IP provides a number of benefits. The IP datagram containing the X.25 packet can be switched by other routers using the Cisco high-speed switching abilities. It also allows X.25 connections to be sent over networks running only the TCP/IP protocols. The TCP/IP protocol suite runs over many different networking technologies including Ethernet, Token Ring, T1 serial, and FDDI. Thus X.25 data can be forwarded over these media to another Cisco router where it can be output to an X.25 interface.
To enable X.25 switching, use the x25 routing global configuration command. The full syntax of this command follows:
x25 routingX.25 calls will not be forwarded until this command is issued. The command no x25 routing disables the forwarding of X.25 calls.
The X.25 routing table is consulted when an incoming call is received that should be forwarded to its destination. Two fields are used to determine the route: the called X.121 network interface address or the destination host address, and the X.25 packet's Called User Data (CUD) field. When the destination address and the CUD of the incoming packet fit the X.121 and CUD patterns in the routing table, the packet is forwarded.
An entry in the X.25 routing table is set up or removed with the x25 route global configuration commands. The full syntax and variations of these commands follow:
x25 route [# position] x121-pattern [cud pattern] interface interface-type unitThe order in which X.25 routing table entries are specified is significant; the list is scanned for the first match. The optional argument # position (# followed by an integer) designates the line number of an existing entry. The new entry will be inserted after the existing entry indicated by the position argument. If no position parameter is given, the entry is appended to the end of the routing table.
The argument x121-pattern can be either an actual X.121 destination address or a regular expression representing a group of X.121 addresses (for example, 1111.*).
The optional Call User Data pattern can also be specified as a printable ASCII string. Both the X.121 address and Call User Data can be written using UNIX-style regular expressions. The Call User Data field is matched against the data that follows the protocol identification field, which is four bytes. The argument interface-type is the type of interface (for example, serial) and unit is the interface unit number. For connections routed through a LAN, the ip-address argument is the IP address of the network interface or DTE. Use the show x25 route command to display the X.25 routing table.
In the alias version of this command, the type argument is the type of interface and the unit argument is the unit number of the destination interface on the destination router. With the alias command, if a call comes in on the specified interface and the call's destination address fits the X.121 pattern, the call is received on the destination interface. In other words, an alias route is valid only for calls that come in on the named interface.
Enter the no x25 route command with the appropriate arguments and keywords to remove the entry from the table.
In the following example, if a call comes in on interface serial 0 and matches any x121-pattern, the call will be accepted for the type of connectivity configured for the interface and the CUD.
x25 route .* alias serial 0
In the following example, the call will be accepted because both this vax-x.121 address and the address given in the x25 address interface command will be treated as local addresses for interface serial 0.
x25 route vax-x121-address alias serial 0
When interconnecting two separate X.25 networks, it is sometimes necessary to provide for address translation. Cisco's X.25 switch supports translation of X.25 called and calling addresses using the substitute-dest or substitute-source keyword with the x25 route configuration subcommand. Addresses can be rewritten using regular expression replacement.
The substitute-source keyword allows substitution of the calling address. For backwards compatibility, the substitute keyword will be accepted as substitute-dest and written to nonvolatile memory in the new format. When used with the x25 use-source-address command, this option allows the calling address to be modified.
x25 route [# position] x121-pattern [substitute-source rewrite-pattern] [substitute-dest rewrite-pattern] [cud pattern] interface destination-interfaceFor typographical reasons, this command is shown on two lines. When using the optional keywords in this variation of the x25 route subcommand, the substitute-source keyword must precede the substitute-dest keyword, and both must precede the cud keyword. The entire command must be on one line.
The argument x121-pattern can be either an actual x.121 destination address or a regular expression representing a group of X.121 addresses.
The argument rewrite-pattern will replace the called or calling X.121 address in routed X.25 packets, as appropriate. The backslash (\) character is treated specially in the argument rewrite-pattern; it indicates that the digit immediately following it selects a portion of the original called address to be inserted in the new called address. The characters \0 are replaced with the entire original address. The characters \1 through \9 are replaced with the strings that matched the first through ninth parenthesized parts of X121-pattern. See Table 1-4 and Table 1-5 for a summary of pattern and character matching. A more complete description of the pattern matching characters is found in the "Pattern Matching" appendix.
| Pattern | Matching |
|---|---|
| \0 | Replaces entire original address. |
| \1..9 | Replaces strings that match first through ninth parenthesized part of 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 | Matching |
|---|---|
| ^ | 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. |
Note that address substitution is only performed on routes to an interface. When running X.25 over IP, address substitution can be performed on the destination IP system if the destination system is configured with the appropriate X.25 routing commands.
This example indicates that X.25 calls to addresses whose first four Data Network Identification Code (DNIC) digits are 1111 should be routed through interface serial 3, but that the DNIC field in the addresses presented to the equipment connected to that interface should be changed to 2222. The \1 characters in the rewrite pattern indicate that the portion of the original address matched by the characters. The asterisk should be inserted in the rewritten address.
x25 route ^1111(.*) substitute-dest 2222\1 interface serial 3
Figure 1-3 shows a more contrived example intended to illustrate the power of the rewriting scheme:
This sample would cause all X.25 calls with 14-digit called addresses to be routed through interface serial 0. The incoming DNIC field would be moved to the end of the address. The fifth, sixth, ninth, and tenth digits would be deleted, and the thirteenth and fourteenth would be moved before the eleventh and twelfth.
You may configure X.25 Permanent Virtual Circuits (PVCs) in the X.25 switching software. This means that DTEs that require permanent circuits can be connected to the Cisco router acting as an X.25 switch and have a properly functioning connection. X.25 RESETs will be sent indicating when the circuit comes up or goes down.
Use the x25 pvc interface subcommand to configure a PVC for a given interface. The syntax of this command follows.
x25 pvc pvc-number interface interface-name pvc-numberThe argument pvc-number is the PVC number that will be used on the local interface (as defined by the primary interface command). The argument interface-name is the interface type and unit number (serial 0, for example), as specified by the interface command.
Consider a PVC linked across two serial interfaces on the same device. 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.
interface serial 0 encapsulation x25 x25 pvc 1 interface serial 1 1 interface serial 1 encapsulation x25 x25 pvc 1 interface serial 0 1
When you are configuring X.25 to use a PVC, you must ensure that no traffic is sent towards the remote router between the time the X.25 map command is issued and the time that X25 pvc command is issued. Otherwise, the local router will create an SVC, and then the pvc command will not be allowed.
Map entries with the Broadcast attribute are particularly likely to get traffic, due to routing protocol traffic. The simplest way to ensure that no traffic is sent while configuring is to shut down the interface while configuring it for a PVC.
The following two examples illustrate how to enable an X.25 switch, how to enable call forwarding, and how to configure a router on a Tymnet/PAD switch to accept and forward calls.
This configuration shows how to enable X.25 switching, as well as how to enter routes into the X.25 routing table.
! Enable X.25 forwarding x25 routing ! ! Enter routes into the table. Without a positional parameter, entries ! are appended to the end of the table x25 route ^100$ interface serial 0 x25 route 100 cud ^pad$ interface serial 2 x25 route 100 interface serial 1 x25 route ^3306 interface serial 3 x25 route.* ip 10.2.0.2
This routing table forwards calls for X.121 address 100 out via interface serial 0. Otherwise, if the X.121 address contains 100 anywhere within it and contains no Call User Data or the Call User Data is not the string pad, it is forwarded onto serial 1. If the X.121 address contains 100 somewhere within and the Call User Data is the string pad, the call is forwarded onto serial 2. All X.121 addresses that do not match the first three routes are checked for a DNIC of 3306 as the first four digits. If it does match, it is forwarded over serial 3. All other X.121 addresses will match the fifth entry which is a match-all pattern and will have a TCP connection established to the IP address 10.2.0.2. The Cisco router at 10.2.0.2 will then route the call according to its X.25 routing table.
This configuration configures a Cisco router that sits on a Tymnet PAD/switch to accept calls and have them forwarded to a DEC VAX system. This feature permits running X.25 network over a generalized, already existing IP network, thereby making it unnecessary to get another physical line for one protocol.
The Cisco router positioned next to the DEC VAX system is configured with X.25 routes, as follows:
x25 route vax-x121-address interface serial 0 x25 route.* ip cisco-on-tymnet-ipaddress
This would route all calls to the DEC VAX X.121 address out to serial 0, where the VAX is connected running PSI. All other X.121 addresses would be forwarded to the cisco-on-tymnet address using its IP address. This would take all outgoing calls from the VAX and send them to cisco-on-tymnet for further processing.
On the router named cisco-on-tymnet, you would enter these commands.
x25 route vax-x121-address ip cisco-on-vax x25 route .* interface serial 0
This forces all calls with the VAX X.121 address to be sent to the Cisco router with the VAX connected to it. All other calls with X.121 addresses will be forwarded out to Tymnet. If Tymnet can route them, then a CALL ACCEPTED packet will be returned and everything will proceed normally. If Tymnet can not handle it, it will clear the call and the CLEAR REQUEST packet will be forwarded back toward the VAX.
Once you establish X.25 Level 3 encapsulation, you can set X.25 Level 3 parameters. These parameters are described in the following sections.
To set the X.121 address of a particular network interface, use the x25 address subcommand. The address is assigned by the X.25 network:
x25 address X.121-addressThe argument X.121-address is a variable-length X.121 address.
The following subcommand sets the X.121 address of the current interface to address 2.
x25 address 2
The value must match that assigned by the X.25 network.
The section "DDN X.25 Dynamic Mapping," earlier in this chapter, describes the addressing scheme for DDN X.25 networks.
An important part of X.25 operation is the virtual circuit channel sequence. This sequence is a range of virtual circuit channel numbers broken into four groups (listed here in numerically increasing order):
Several X.25 parameters determine the numerical ranges of the last three groups; the range for permanent virtual circuits falls numerically below the incoming call range.
X.25 communications devices use the virtual circuit channel sequence when allocating virtual circuits. When initiating a call, these devices must search for an available channel in the sequence in one of two ways. For outgoing calls (made by a DTE device), the search starts at the upper end of the outgoing call range and proceeds in the direction of decreasing channel numbers. The search continues until the device finds an available channel or reaches the lower limit of the two-way call range.
For incoming calls (handled by a DCE device), the search for channel numbers to allocate starts at the lower end of the incoming call range, and proceeds in the direction of increasing channel numbers. The search continues until the device finds an available channel or reaches the upper limit of the two-way call range. The DTE and DCE devices fail to find an available channel only if the overall sequence range is very small or when all of the channels are in use.
To set the upper-limit and lower-limit parameters of the channel ranges, use the x25 subcommand keywords listed in Table 1-6. Each keyword takes a channel number as its argument. Note that the values for these parameters must be the same on both ends of an X.25 link.
The default lower limit for all channel ranges on the router is 1; the default upper limit for all ranges is 1024, except for CMNS. For CMNS the default upper limit for hic, htc, and hoc parameters is 4095. These defaults reflect a simple approach to allocating the channel ranges: assign the same low value to all lower limits, and assign the same high value to all upper limits. This approach causes the three ranges to overlap and become one large range.
Keyword | Limit Type | Range | Non-CMNS Default | CMNS Default |
|---|---|---|---|---|
| lic | Lower limit, incoming call range | 1-4095 | 1 | 1 |
| hic | Upper limit, incoming call range | 1-4095 | 1024 | 4095 |
| ltc | Lower limit, two-way call range | 1-4095 | 1 | 1 |
| htc | Upper limit, two-way call range | 1-4095 | 1024 | 4095 |
| loc | Lower limit, outgoing call range | 1-4095 | 1 | 1 |
| hoc | Upper limit, outgoing call range | 1-4095 | 1024 | 4095 |
The hic keyword sets the highest incoming channel (HIC).
x25 hic channelThe argument channel is a channel number from 1 through 4095. The default value is 1024.
The hoc keyword sets the highest outgoing channel (HOC).
x25 hoc channelThe argument channel is a channel number from 1 through 4095. The default value is 1024.
The htc keyword sets the highest two-way channel (HTC).
x25 htc channelThe argument channel is a channel number from 1 through 4095. The default value is 1024.
The lic keyword sets the lowest incoming channel (LIC).
x25 lic channelThe argument channel is a channel number from 1 through 4095. The default value is one.
The loc keyword sets the lowest outgoing channel (LOC).
x25 loc channelThe argument channel is a channel number from 1 through 4095. The default value is one.
The ltc keyword sets the lowest two-way channel (LTC).
x25 ltc channelThe argument channel is a channel number from 1 through 4095. The default value is one.
The following commands set these channels.
Commands us to set these channels:
x25 hic 20 x25 htc 20 x25 hoc 20
The router can clear a switched virtual circuit (SVC) after a set period of inactivity. To set this period, use the x25 idle interface subcommands:
x25 idle minutesThe argument minutes is the number of minutes in the period. The default value is zero, which causes the router to keep the SVC open indefinitely. Both calls originated and terminated by the router are cleared. The no x25 idle command returns the default.
To increase throughput across networks, you can establish up to eight SVCs to a host. To specify the maximum number of SVCs 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 commands:
x25 hold-vc-timer minutesThe argument minutes is the number of minutes to prevent calls to a previously failed destination. Incoming calls will still be accepted. The default value is 0, and the no x25 hold-vc-timer command restores this default.
The X.25 Level 3 retransmission timers determine how long the router must wait before retransmitting various Request packets. You can set these timers independently using the x25 subcommand keywords listed in Table 1-7. 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) | Time (seconds) (DXE) |
|---|---|---|---|
| t20/t10 | Restart Request | 180/60 | 60 |
| t21/t11 | Call Request | 200/180 | 180 |
| 122/t12 | Reset Request | 180/60 | 60 |
| t23/t13 | Clear Request | 180/60 | 180 |
The t20 keyword sets the limit for the Restart Request retransmission timer (T20) on DTE devices.
x25 t20 secondsThe argument seconds is a time value 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 a time value in seconds. The default value is 60 seconds.
The t21 keyword sets the limit for the Call Request retransmission timer (T21) on DTE devices.
x25 t21 secondsThe argument seconds is a time value in seconds. The default value is 200 seconds.
The t11 keyword sets the limit for the Call Request retransmission timer (T11) on DCE devices.
x25 t11 secondsThe argument seconds is a time value 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 a time value 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 a time value 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 a time value 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 a time value in seconds. The default value is 60 seconds.
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 is necessary when forwarding calls from private data networks to public data networks.
Outgoing calls forwarded over a specific interface can have their calling X.121 address updated by using the x25 use-source-address subcommand. The full syntax is:
x25 use-source-addressThe no x25 use-source-address command prevents updating of the source address of outgoing calls.
X.25 networks use maximum input and output packet sizes set by the network administration. You can set the router input and output packet sizes to match those of the network with the x25 subcommand keywords ips and ops, respectively:
x25 ips bytesThe argument bytes is a byte count in the range of 128 through 2048. The default value is 128 bytes.
Larger packet sizes are better, because smaller packets require more overhead processing.
To send a packet larger than the X.25 packet size over an X.25 virtual circuit, a router 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 eight. 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 commands x25 win (for input window) and x25 wout (for output window):
x25 win packetsThe argument packets is a packet count. The packet count for win and wout can range from one to the window modulus. The default value is two packets.
The x25 win command determines how many packets the router can receive before sending an X.25 acknowledgment. The wout limit determines how many sent packets can remain unacknowledged before the router uses a hold queue. To maintain high bandwidth use, assign these limits the largest number that the network allows.
You can instruct the router 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 one sends one Receiver Ready acknowledgment per packet at all times. The default value is zero, which disables the delayed acknowledgment strategy.
The router 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 one, the router can send an acknowledgment per input packet.
To omit the calling address in outgoing calls, use the x25 suppress-calling-address interface subcommand:
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 subcommand:
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 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 10. A hold-queue value of 0 allows an unlimited number of packets in the hold queue. 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 instruct the router to accept all reverse charge calls, use the x25 accept-reverse interface subcommand:
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 x25 accept-reverse command disables this facility.
To force a packet-level restart when the link level is restarted, use the x25 linkrestart interface subcommand:
x25 linkrestartThis command restarts X.25 Level 2 (LAPB) when errors occur. This behavior is the default and is necessary for networks that expect this behavior. Use the no x25 linkrestart to turn this feature off.
To set the packet network carrier, use the x25 rpoa interface subcommand:
x25 rpoa name numberThe x25 rpoa interface subcommand 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. The no x25 rpoa command removes the specified name.
To override interface settings on a per-call basis, use the x25 facility interface subcommand. The full syntax of the command follows:
x25 facility keyword argumentThe command enables X.25 facilities, which are sent between DTE and DCE devices to negotiate certain link parameters.
The argument keyword specifies one of the following keywords, followed by the required argument:
The no x25 facility command with the appropriate keyword and argument removes the facility.
To clear all virtual circuits at once, use the privileged EXEC command clear x25-vc. This command takes an interface type keyword and a unit number as arguments to identify the interface with which the virtual circuits are associated.
To clear a particular virtual circuit, add the two arguments described above the clear x25-vc command, and include a logical circuit number (LCN) value as a third argument. The command syntax is:
clear x25-vc interface unit [lcn]The clear x25-vc 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.
The router provides EXEC show commands to provide information on interface operation and virtual circuit operation. Use the EXEC command show interfaces to display interface parameters and statistics. Use the EXEC command show x25 vc to display virtual circuit parameters and statistics.
To display parameter information for a serial interface using the X.25 Level 3 protocol, use the EXEC command show interfaces. To display X.25 Level 3 parameters for LAN interfaces (such as Ethernet or Token Ring), use the show cmns EXEC command described later in this chapter. For serial X.25 interfaces, the following is an example of output:
X25 address 000000010100, state R1, modulo 8, idle 0, timer 0, nvc 1 Window size: input 2, output 2, Packet size: input 128, output 128 Timers: T20 180 T21 200 T22 180 T23 180 TH 0 Channels: Incoming 1-1024 Two-way 1-1024 Outgoing 1-1024 RESTARTs 1/20 CALLs 1000+2/1294+190/0+0 DIAGs 0/0
On the first line, the address field indicates the calling address used in the Call Request packet. The state field indicates 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. If the state is R2 or R3, the device is awaiting acknowledgment for a Restart Request packet. The modulo field displays the modulo value, which determines the sequence numbering scheme used. The idle field shows the number of minutes the router waits before closing idle virtual circuits. The timer field displays the value of the interface timer, which is zero unless the interface state is R2 or R3. The nvc field displays the maximum number of simultaneous virtual circuits permitted to and from a single host.
On the second line, the Window size and Packet size fields show the default window and packet sizes for the interface. Each virtual circuit can override these values using facilities specified with the x25 map or x25 facility subcommands.
The third line shows the values of the Request packet timers (T10 through T13 for a DCE device, and T20 through T23 for a DTE device). The fourth line shows the channel sequence ranges. The last line shows packet statistics for the interface using these formats:
sent/received\ successful+failed\ callssent+callssentfailed/\ callsreceived+callsreceivedfailed/\ callsforwarded+callsforwardedfailed\
The EXEC command show x25 vc displays the details of the active X.25 switched virtual circuits. To examine a particular virtual circuit, add an LCN argument to the show x25 vc command. The following is example output:
LC1: 1, State: D1, Interface: Serial0 Started 0:55:03, last input 0:54:56, output 0:54:56 Connected to IP [10.4.0.32] <->000000320400 Precedent: 0 Window size input: 7, output: 7 Packet size input: 1024, output: 1024 PS: 2 PR: 6 Remote PR: 2 RCNT: 1 RNR: FALSE Retransmits: 0 Timer (secs): 0 Reassembly (bytes): 0 Held Fragments/Packets: 0/0 Bytes 1111/588 Packets 18/22 Resets 0/0 RNRs 0/0 REJs 0/0 INTs 0/0 Window is closed
On the first line, the LCI field displays the virtual circuit number. The State field displays the state of the virtual circuit (which is independent of the states of other virtual circuits); D1 is the normal ready state. (See the CCITT X.25 recommendation for a description of virtual circuit states.) The Interface field shows the interface used for the virtual circuit.
On the second line, the Started field shows the time elapsed since the virtual circuit was created, the last input field shows time of last input, and the output field shows time of last output.
On the third line, the Connected to field shows in brackets the network-protocol address and then the X.121 address. The Precedent field, which appears only if you have specified DDN encapsulation, indicates IP precedence.
The fourth and fifth lines show window and packet sizes. These sizes can differ from the interface default values if facilities were offered and accepted in the Call Request and Call Accepted packets.
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 PR 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; this field is true of the network sends a receiver-not-ready packet.
On the seventh line, the Retransmits field shows the number of times a packet has been retransmitted. The Timer field shows a nonzero time value if a packet has not been acknowledged or if virtual circuits are being timed for inactivity. The Reassembly field shows the number of bytes received for a partial packet (a packet in which the more data 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, Fragments refers to the X.25 fragmentation of higher-level data packets.) The Packets part of the Held Fragments/Packets field shows the number of higher-level protocol packets currently being held pending the availability of resources, such as the establishment of the virtual circuit.
On the ninth line, the Bytes field shows the total numbers of bytes sent and received. The Packets, Resets, RNRs, REJs, and INTs fields show the total sent and received packet counts of the indicated types. (RNR is Receiver Not Ready, REJ is Reject, and INT is Interrupt).
On the last line, the Window is closed fieldshows when a full link-level frame has been transmitted and is waiting for acknowledgment from the other end of the virtual circuit in order to transmit the next full link-level frame. Flow control is being used on the serial interface.
When installing an X.25 link, you can use the EXEC commands debug with different keywords as follows:
Enables the monitoring of all X.25 traffic.
Enables the monitoring of all X.25 traffic but does not display information about X.25 data or acknowledgment packets.
Allows you to watch the specified port number with a virtual circuit using the debug x25 and debug x25-events commands.
The following is example output:
Serial0: X25 I R1 RESTART (5) 8 lci 0 cause 7 diag 250 Serial0: X25 0 R1 RESTART CONFIRMATION (3) 8 lci 0 Serial0: X25 0 P2 CALL REQUEST (19) 8 lci 1 From(14): 31250000000101 To(14): 31109090096101 Facilities (0) Serial0: X25 0 P6 CLEAR REQUEST (5) 8 lci 1 cause diag 122
For each event, the first field identifies the interface on which the activity occurred, and the second field indicates that it was an X.25 event. The third field indicates whether the X.25 packet was input (I) or output (O). The fourth 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 fifth field is the type of the X.25 packet that triggered the event, and the sixth field (in parentheses) gives the total length of the X.25 packet in bytes. The seventh field is the window modulus. The eighth field (labeled lci) shows the virtual circuit number. The ninth field (labeled cause) gives the cause code, and the tenth field (labeled diag) gives the diagnostic code.
For Call Request and Call Connected packets, the router 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) for example--specifies the number of digits in the address. The Facilities field indicates the length (in bytes) of the requested facilities and the facilities contents.
Cisco's support of Connection-Mode Network Service (CMNS) provides a mechanism through which local X.25 switching can be extended to different media (Ethernet, FDDI, and Token Ring) through the use of OSI-based NSAP addresses. This implementation essentially runs X.25 (packet level) over LLC2 (frame level), to facilitate the extension of X.25 to other media. Cisco's CMNS implementation supports services defined in ISO Standards 8208 (packet level) and 8802-2 (frame level).
In addition, Cisco's CMNS-implementation allows LAN-based OSI resources, such as a DTE host and a Sun workstation, to be interconnected to each other via the router's LAN interfaces and to a remote OSI-based DTE through a WAN interface (using, for example, an X.25 PSN).
All local mapping is performed by statically mapping MAC addresses to NSAP addresses and X.121 addresses to NSAP addresses. Refer to the chapter "Switching ISO CLNS" for a discussion of NSAP addresses and to the chapter "SDLLC: SDLC to LLC2 Media Translation" for more information about Cisco's use of Link Layer Control Type 2 (LLC2).
Implementing CMNS routing on Cisco routers involves the following basic steps:
Step 1: Enable CMNS on an interface.
Step 2: Map NSAP addresses to a MAC-address or X.121 address.
The discussions that follow detail commands used to perform these steps and provide example configurations illustrating CMNS-based routing.
To enable CMNS on a nonserial interface, use the cmns enable interface subcommand. The command syntax is:
cmns enableAfter executing this command, all the X.25-related interface subcommands are made available on the LAN interfaces (Ethernet, FDDI, and Token Ring), as well as on serial interfaces. The no version disables this feature.
After enabling CMNS on a nonserial interface (or specifying X.25 encapsulation on a serial interface), you must use the x25 map cmns interface subcommand to map NSAP addresses to either MAC-layer addresses or X.121 addresses, depending on the application. The syntax for this command is:
x25 map cmns NSAP MAC-addressThe NSAP, MAC-address, and X.121-address arguments specify the NSAP address-to-MAC address or NSAP address-to-X.121 address mappings. The argument NSAP can be either the actual DTE NSAP address or the NSAP prefix of the NSAP address. The NSAP prefix is sufficient for a best match to route a call.
To retract a mapping, use the no x25 map cmns interface subcommand with the appropriate address arguments.
The following examples illustrate enabling CMNS and configuring X.121 and MAC-address mappings:
interface ethernet 0 cmns enable x25 map cmns 38.8261.1000.0150.1000.17 0000.0c00.ff89 ! Above maps NSAP to MAC-address on Ethernet0 ! interface serial 0 encapsulation x25 x25 map cmns 38.8261.1000.0150.1000.18 3110451 ! Above maps NSAP to X.121-address on Serial0 ! assuming the link is over a PDN ! interface serial 1 encapsulation x25 x25 map cmns 38.8261.1000.0150.1000.20 ! Above specifies cmns support for Serial1 ! assuming that the link is over a leased line
The following two examples illustrate common implementations of CMNS for switching traffic over different media. The first example depicts switching CMNS over packet-switched public data network (PDN); the second example illustrates switching CMNS over a leased line. These application are quite similar, with subtle differences in the use of the x25 map cmns command.
Figure 1-4 illustrates the general network topology for a CMNS switching application where calls are being made between resources on opposite sides of a remote link to Host A (on an Ethernet) and Host B (on a Token Ring), with a PDN providing the connection.
The following configuration listing allows resources on either side of the PDN to call Host A or Host B. This configuration allows traffic intended for the remote NSAP address specified in the x25 map cmns commands (for the serial ports) to be switched through the serial interface for which CMNS is configured.
The CMNS-related configuration for Cisco Router C2 in Figure 1-4 would be as follows:
! This configuration specifies that any traffic from any other ! interface intended for any NSAP address with NSAP prefix 38.8261.17 ! will be switched to MAC address 0800.4e02.1f9f ! through Token Ring 0 ! interface token 0 cmns enable x25 map cmns 38.8261.17 0800.4e02.1f9f ! ! This configuration specifies that traffic from any other interface ! on Cisco Router C2 that is intended for any NSAP address with ! NSAP-prefix 38.8261.18 will be switched to ! X.121 address 2095551000 through Serial 0 ! interface serial 0 encapsulation x25 x25 address 4085551234 x25 map cmns 38.8261.18 2095551000
The CMNS-related configuration for Cisco Router C1 in Figure 1-4 would be as follows:
! This configuration specifies that any traffic from any other ! interface intended for any NSAP address with NSAP 38.8261.18 ! will be switched to MAC address 0800.4e02.2abc through Ethernet 0 ! interface ethernet 0 cmns enable x25 map cmns 38.8261.18 0800.4e02.2abc ! ! This configuration specifies that traffic from any other interface ! on Cisco Router C1 that is intended for any NSAP address with ! NSAP-prefix 38.8261.17 will be switched to X.121 address ! 4085551234 through Serial 1 ! interface serial 1 encapsulation x25 x25 address 2095551000 x25 map cmns 38.8261.17 4085551234
Figure 1-5 illustrates the general network topology for a CMNS switching application where calls are being made by resources on the opposite side a remote link to Host C (on an Ethernet) and Host D (on a Token Ring), with a dedicated leased-line providing the connection.
The following configuration listing allows resources on either side of the leased line to call Host C or Host D. This configuration allows traffic intended for the remote NSAP address specified in the x25 map cmns commands (for the serial ports) to be switched through the serial interface for which CMNS is configured.
A key difference for this configuration in comparison with Example 1 is that with no PDN, the specification of an X.121 address in the x25 map cmns command is not necessary. The specification of an X.25 address is also not needed, but is included for symmetry with Example 1.
The CMNS-related configuration for Cisco Router C4 in Figure 1-5 would be as follows:
! This configuration specifies that any traffic from any other ! interface intended for any NSAP address with NSAP 38.8261.21 ! will be switched to MAC address 0800.4e02.bcd0 through Token Ring 0 ! interface token 0 cmns enable x25 map cmns 38.8261.21 0800.4e02.bcd0 ! ! This configuration specifies that traffic from any other interface ! on Cisco Router C4 that is intended for any NSAP address with ! NSAP-prefix 38.8261.20 will be switched through Serial 0 ! interface serial 0 encapsulation x25 x25 address 00002 x25 map cmns 38.8261.20
The CMNS-related configuration for Cisco Router C3 in Figure 1-5 would be as follows:
! This configuration specifies that any traffic from any other ! interface intended for any NSAP address with NSAP 38.8261.20 ¡ will be switched to MAC address 0800.4e02.123f through Ethernet 0 ! interface ethernet 0 cmns enable x25 map cmns 38.8261.20 0800.4e02.123f ! ! This configuration specifies that traffic from any other interface ! on Cisco Router C3 that is intended for any NSAP address with ! NSAP-prefix 38.8261.21 will be switched through Serial 1 ! interface serial 1 encapsulation x25 x25 address 00001 x25 map cmns 38.8261.21
To display information pertaining to CMNS traffic activity, use the show cmns EXEC command. The command syntax is:
show cmns interface-nameThe following is an example of the output of show cmns interface.
Ethernet 0 is up, line protocol is up CMNS protocol processing disabled
This example indicates that CMNS is disabled on Ethernet0.
The following display sample illustrates show cmns displays for serial interfaces respectively.
Serial 0 is down, line protocol is down
X25 address 222222, state R1, modulo 8, idle 0, timer 0, nvc 1
Window size: input 2, output 2, Packet size: input 1024, output 1024
Timers: T10 60 T11 180 T12 60 T13 60 TH 0
Channels: Incoming 1-1024 Two-way 1-1024 Outgoing 1-1024
RESTARTs 0/0 CALLs 0+0/0+0/0+0 DIAGs 0/0
Please refer to "Monitoring X.25 Level 3 Operations" earlier in this chapter for description of the interface parameters and statistic provided in preceding display.
The following display illustrates CMNS-related information presented on an Ethernet display for show cmns.
Ethernet 1 is up, line protocol is up
Hardware address is 0000.0c01.1515 (bia 0000.0c01.1515), state R1
Modulo 8, idle 0, timer 0, nvc 1
Window size: input 2, output 2, Packet size: input 128, output 128
Timer: TH 0
Channels: Incoming 1-1024 Two-way 1-1024 Outgoing 1-1024
RESTARTs 0/0 CALLs 0+0/0+0/0+0 DIAGs 0/0\