|
|
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\
On the last line, packet statistics for the interface are displayed which use the following format:
There is an addendum to the show llc command in the case of CMNS calls; for example, an LLC2 connection provides the following information:
LLC2 Connections to:
Ethernet2 DTE=0800.4E02.1F9F,000000000000 SAP=7E/7E, State=NORMAL
V(S)=2, V(R)=3, Last N(R)=2, Local window=7, Remote Window=7
akmax=3, n2=8, Next timer in 5196
xid-retry timer 0/60000 ack timer 0/1000
p timer 0/1000 idle timer 5196/10000
rej timer 0/3200 busy timer 0/9600
akdelay timer 0/3200
CMNS Connections to:
Address 0800.4E02.1F9F via Ethernet2
Protocol is up
Interface Type X25-DCE RESTARTS 0/1
Timers: T10 60 T11 180 T12 60 T13 60
The general LLC2-related information in above display is documented in the chapter "IBM Media Connectivity." The following information defines fields in the CMNS Connections to: portion of the display.
On the first line, the Address field is the Remote DTE address that connected to via the LAN interface (in this example, Ethernet2).
On the second line, Protocol is up indicates that an existing LLC2 connection exists with the remote DTE and has passed X.25 initialization (Restart negotiation) of that LLC2 connection. Therefore, the link is ready for any incoming/outgoing call request on this LLC2 connection.
On the third line, the Interface Type field indicates the type of this LLC2 connection. Options are X25-DCE, X25-DTE or X25-DXE. The RESTARTS field represents the number of restarts sent/received on this LLC2 connection.
On the last line, Timers shows the value for the Request packet timers for this LLC2 connection (T10 through T13 for a DCE interface type; T20 through T23 for a DTE interface type).
When the protocol type used for the connection is CMNS, the display generated with show x25 vc differs slightly from the display outlined in the preceding description.
A sample display output follows that depicts two complementary interfaces, both running CMNS, providing transport of CMNS traffic to each other:
LCI: 1, State: P4, Interface: Serial1
Started 0:23:00, last input never, output never
Connected to CMNS [37.1111] <--> 313131 via Ethernet1 LCN 4095 to 0000.0c01.487d
Window size input: 6, output: 6
Packet size input: 1024, output: 1024
PS: 0 PR: 0 ACK: 0 Remote PR: 0 RCNT: 0 RNR: FALSE
Retransmits: 0 Timer (secs): 0 Reassembly (bytes): 0
Held Fragments/Packets: 0/0
Bytes 0/0 Packets 0/0 Resets 0/0 RNRs 0/0 REJs 0/0 INTs 0/0
--More--
LCI: 4095, State: P4, Interface: Ethernet1
Started 0:23:01, last input never, output never
Connected to CMNS [36.3030.3030.3030.30] <--> 0000.0c01.487d
via Serial1 LCN 1to 313131
Window size input: 6, output: 6
Packet size input: 1024, output: 1024
PS: 0 PR: 0 ACK: 0 Remote PR: 0 RCNT: 0 RNR: FALSE
Retransmits: 0 Timer (secs): 0 Reassembly (bytes): 0
Held Fragments/Packets: 0/0
Bytes 0/0 Packets 0/0 Resets 0/0 RNRs 0/0 REJs 0/0 INTs 0/0
The following display fields differ for CMNS virtual circuits:
When installing a link on which CMNS is to be used, you can use the EXEC command debug with different keywords as follows:
Enables the monitoring of all X.25 traffic, including CMNS-based 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.
This section describes frame relay configuration, Cisco Systems' implementation of frame relay, the protocols supported, and the hardware needed to operate with a frame relay network.
Frame relay is described as an encapsulation method and is directed mainly to users with large T1 network installations. Cisco supports the two generally implemented specifications for frame relay Local Management Interfaces (LMIs):
Cisco's implementation also conforms to the Link Access Procedure (LAP-D) defined by the CCITT under its I-series (ISDN) recommendation as I122, "Framework for Additional Packet Model Bearer Services."
Cisco's frame relay implementation currently supports routing on AppleTalk, DECnet, IP, ISO CLNS, Novell IPX, VINES, and transparent bridging.
The Cisco network server supports the local management interface (LMI), as specified in the joint Frame Relay Interface specification. The LMI includes support for a keepalive mechanism, a multicast group, and a status message.
The keepalive mechanism provides an exchange of information between the network server and the switch to verify data is flowing. The multicast mechanism provides the network server with its local data link connection identifier (DLCI) and the multicast DLCI. The status mechanism provides an on-going status report on the DLCIs known by the switch.
The following hardware configuration is required for frame relay connections:
The CSU/DSU converts V.35 or RS-449 signals to the properly coded T1 transmission signal for successful reception by the frame relay network. Figure 1-6 illustrates the connections between the different components.
The frame relay interface actually consists of one physical connection between the network server and the switch that provides the service. This single physical connection provides direct connectivity to each device on a network, such as a Stratacom FastPacket wide-area network, using only a single connection.
Use the encapsulation frame-relay interface subcommand to specify frame relay encapsulation on a specific interface.
encapsulation frame-relayThese commands configure frame relay encapsulation on interface serial 1.
interface serial 1
encapsulation frame-relay
Use the frame-relay lmi-type ANSI interface subcommand to specify use of the ANSI LMI. The command syntax is:
frame-relay lmi-type ANSIThis command specifies the exchange of local management interface messages as defined by ANSI standard T1.617.
The no frame-relay lmi-type ANSI returns the LMI type to the default as defined by the Cisco/StrataCom/Northern Telecom/DEC specification. The LMI type is set on a per interface basis and is shown in the output of the show interface command.
The following commands configure frame relay encapsulation on serial 0 and specify use of the ANSI LMI.
interface serial 0
encapsulation frame-relay
frame-relay lmi-type ANSI
The frame-relay keepalive interface subcommand enables and disables the LMI mechanism for serial lines using the frame relay encapsulation. The full syntax of this command follows.
frame-relay keepalive secondsThe argument seconds defines the keepalive interval. The interval must be set, and must match the interval set on the switch. The default keepalive interval is ten seconds.
This command sets the keepalive timer on the Cisco router for a period that is two or three seconds faster (shorter interval) than the interval set on the keepalive timer of the frame relay switch. The difference in keepalive intervals ensures proper synchronization between the Cisco router and the frame relay switch.
frame-relay keepalive 8
The frame-relay map subcommand defines the mapping between an address and the DLCI used to connect to the address. There can be many DLCIs known by a network server that can send data to many different places, but all this data will be multiplexed over the one physical link. The frame relay map tells the network server how to get from a specific protocol and address pair to the correct DLCI. The full syntax of this command follows.
frame-relay map protocol protocol-address DLCI [broadcast]The argument protocol is one of these keywords: ip, decnet, appletalk, xns, novell, vines, or clns. The keyword is followed by the corresponding protocol address and the DLCI number.
This variation of the frame-relay map command is used for the ISO CLNS protocol:
frame-relay map clns DLCI broadcastThis variation of the frame-relay map command is used for bridging:
frame-relay map bridge DLCI broadcastIn both these variations, there is no need to specify a protocol address; however, the broadcast keyword is required for both.
The optional keyword broadcast specifies that broadcasts should be forwarded to this address when the multicast is not enabled. The default is not to forward broadcasts. The broadcast keyword is required for ISO CLNS and bridging applications.
The no frame-relay map subcommand with the appropriate arguments deletes the entry.
Examples of command use follow; see the chapter "Configuring Transparent Bridging" for the procedures to configure bridging on frame relay.
This command maps IP address 131.108.123.1 to DLCI 100. Broadcasts are not forwarded.
frame-relay map IP 131.108.123.1 100
This command uses DLCI 144 for bridging.
frame-relay map bridge 144 broadcast
This command uses DLCI 125 for ISO CLNS routing.
frame-relay map clns 125 broadcast
The frame-relay short-status interface subcommand instructs the network server to request the short status message from the switch (see Version 2.3 of the joint Frame Relay Interface specification). The full syntax of this command follows:
frame-relay short-statusThe default is to request the full status message. Use the no frame-relay short-status command to override the default.
This command returns the interface to the default state of requesting full status messages.
no frame-relay short-status
The frame-relay local-dlci interface subcommand sets the source DLCI for use when the LMI is not supported. If LMI is supported and the multicast information element is present, the network server sets its local DLCI based on information provided via the LMI. The full syntax of this command follows:
frame-relay local-dlci numberThe argument number is the local, or source, DLCI number. The no frame-relay local-dlci command removes DLCI number.
This command specifies 100 as the local DLCI.
frame-relay local-dlci 100
The frame-relay multicast-dlci interface subcommand defines a DLCI to be used for multicasts. The full syntax of this command follows.
frame-relay multicast-dlci numberThis command should only be used when the multicast facility is not supported. Network transmissions (packets) sent to a multicast DLCI are delivered to all network servers defined as members of the multicast group. The multicast DLCI is identified by the argument number. (Note that this is not the multicast group number, which is an entirely different value.) The no frame-relay multicast-dlci command removes the multicast group.
This command specifies 1022 as the multicast DLCI.
frame-relay multicast-dlci 1022
When netbooting over Frame Relay, you cannot netboot via a broadcast. You must netboot from a specific host. Also, a frame-relay 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 frame-relay
frame-relay map IP 131.108.126.2 100 broadcast
The frame-relay map command is used to map an IP address into a DLCI address. In order to netboot over Frame Relay, the address of the machine to netboot off of MUST be given explicitly, and a frame-relay map entry must exist for that site. For example:
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 Frame-Relay
!
frame-relay map IP 131.108.13.111 100 broadcast
In this case, 100 is the DLCI of the remote router than can get to host 131.108.13.111.
The remote router must have the following frame-relay map entry:
frame-relay map IP 131.108.126.200 101 broadcast
This allows the remote router to return a boot image (from the netboot host) to the router netbooting over Frame Relay. Here, 101 is the DLCI of the router being netbooted.
The following examples illustrate how to configure a router to support frame relay connections.
The following examples illustrate how to configure two routers for static mode.
interface serial 0
ip address 131.108.64.2 255.255.255.0
encapsulation frame-relay
frame-relay keepalive 10
frame-relay map ip 131.108.64.1 43
interface serial 0
ip address 131.108.64.1 255.255.255.0
encapsulation frame-relay
frame-relay keepalive 10
frame-relay map ip 131.108.64.2 44
The following example illustrates how to send all DECnet packets destined for address 56.4 out on DLCI 101. In addition, any DECnet broadcasts for interface serial 1 will also be sent on the DLCI.
interface serial 1
decnet routing 32.6
encapsulation frame-relay
frame-relay map decnet 56.4 101 broadcast
The following example illustrates how to send packets destined for Novell address 200.0000.0c00.7b21 out on DLCI 102.
interface ethernet 0
novell network 2abc
!
interface serial 0
novell network 200
encapsulation frame-relay
frame-relay map novell 200.0000.0c00.7b21 102 broadcast
Use the EXEC commands in this section to monitor frame relay connections.
When using the frame relay encapsulation, the EXEC command show interface includes information on the multicast DLCI, the DLCI of the interface, and the LMI DLCI used for the local management interface.
The multicast DLCI and the local DLCI can be set using the frame-relay multicast-dlci and the frame-relay local-dlci subcommands, or provided through the local management interface. The status information is taken from the LMI, when active.
Enter this command at the EXEC prompt:
show interfaces [type unit]Following is sample output.
Serial 2 is up, line protocol is up
Hardware type is MCI Serial
Internet address is 131.108.122.1, subnet mask is 255.255.255.0
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
multicast DLCI 1022, status defined, active
source DLCI 20, status defined, active
LMI DLCI 1023, LMI sent 10, LMI stat recvd 10, LMI upd recvd 2
Last input 7:21:29, output 0:00:37, output hang never
Output queue 0/100, 0 drops; input queue 0/75, 0 drops
Five minute input rate 0 bits/sec, 0 packets/sec
Five minute output rate 0 bits/sec, 0 packets/sec
47 packets input, 2656 bytes, 0 no buffer
Received 5 broadcasts, 0 runts, 0 giants
5 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 57 abort
518 packets output, 391205 bytes
0 output errors, 0 collisions, 0 interface resets, 0 restarts
1 carrier transitions
In this display, the multicast DLCI has been changed to 1022 with the frame-relay multicast-dlci interface subcommand.
In this display, the statistics for the LMI are the number of status inquiry messages sent (LMI sent), the number of status messages received (LMI recvd), and the number of status updates received (upd recvd). See the Frame Relay Interface specification for additional explanations of this output. The "Configuring the Interfaces" chapter also provides an explanation about the other fields seen in the show interfaces command.
Use the show interface EXEC command to determine the LMI type implemented. The following sample display illustrates the resulting display from a show interface command executed for a serial interface with the ANSI LMI enabled.
Serial 1 is up, line protocol is up
Hardware is MCI Serial
Internet address is 131.108.121.1, subnet mask is 255.255.255.0
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation FRAME-RELAY, loopback not set, keepalive set
LMI DLCI 0, LMI sent 10, LMI stat recvd 10
LMI type is ANSI Annex D
Last input 0:00:00, output 0:00:00, output hang never
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
Five minute input rate 0 bits/sec, 1 packets/sec
Five minute output rate 1000 bits/sec, 1 packets/sec
261 packets input, 13212 bytes, 0 no buffer
Received 33 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
238 packets output, 14751 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets, 0 restarts
Two fields distinguish the use of the ANSI LMI from the default LMI. In the sixth line of this display, the LMI DLCI field indicates a 0 value. If the LMI were set to the default, the value would be 1023. In addition, the next line is added to the display, stating that the LMI type is ANSI Annex D.
Use this EXEC command to display the current frame relay map entries and information about these connections:
show frame-relay mapSample output follows:
Serial2: IP 131.108.122.2 dlci 10(0XA,0xA0), dynamic
status defined, active
The display lists the interface, the protocol, the protocol address, and the DLCI being used to reach this address. If the optional broadcast keyword was entered for a static map entry, this will also be shown.
The DLCI is displayed in three forms. For example, if the DLCI is 10, the representations would be 10(0xA,0xA0). The displays show the decimal value, the hexadecimal value, and the value of the DLCI as it would appear on the wire. In addition, the display indicates whether this is a static or dynamic entry. Status information for the DLCI is display if provided by the LMI.
For the CLNS protocol, the map has the following form:
Serial0: CLNS dlci 100(0X64,1840), static, broadcast, BW = 64000
status defined, active
Serial0: CLNS dlci 102(0X66,1860), static, broadcast, BW = 64000
status defined, active
Use the show frame-relay traffic command to display global frame relay statistics. Enter this command at the EXEC prompt:
show frame-relay trafficSample output follows:
Frame Relay statistics:
ARP requests sent 14, ARP replies sent 0
ARP request recvd 0, ARP replies recvd 10
LMI sent 10, LMI stat recvd 10, LMI upd recvd 2, Multicast sent 48
Statistics for all frame relay interfaces in the router are also included in this display.
Use the EXEC commands described in this section to troubleshoot and monitor activity on the interface configured for frame relay. For each debug command, there is a corresponding undebug command that turns messaging off.
Enables logging of key events in the transmission or receipt of packets encapsulated using frame relay.
Enables logging of information on the local management interface packets exchanged between the router and the frame relay service provider.
Displays all packets being sent out on the frame relay network. The display identifies the output interface, the protocol identifier, and the size of the packet being sent.
The Switched Multimegabit Data Service (SMDS) is a wide-area networking service offered by Regional Bell Operating Companies (RBOCs) and other telephone service carriers such as AT&T and MCI/Sprint. The SMDS protocol is based on cell relay technology as defined in the Bellcore Technical advisories, which is in turn based on the IEEE 802.6 Standard (also called the Distributed Queue Dual Bus (DQDB) Metropolitan Area Network Media Access Control protocol). For technical references, please see the bibliography in the "References and Recommended Readings" list at the end of this publication.
Cisco provides an interface to an SMDS network using DS1 transmission facilities at the rate of 1.544 Mbps. Connection to the network is made through a device called an SDSU--an SMDS CSU/DSU (Channel Service Unit/Digital Service Unit) developed jointly by Cisco Systems and Kentrox. The SDSU attaches to a Cisco router through an RS-449 connection. On the other side, the SDSU terminates a DS1 line.
Cisco's implementation of SMDS supports the IP, DECnet, AppleTalk, XNS, Novell IPX, Ungermann-Bass Net/One, and OSI internetworking protocols. Routing of IP is fully dynamic; that is, the routing tables are determined and updated dynamically. Routing of the other supported protocols requires that you establish a static routing table of SMDS neighbors in a user group. Once this is set up, all interconnected routers provide dynamic routing.
This section describes Cisco's implementation of SMDS, and how to configure, maintain, and debug SMDS.
You need the following hardware, equipment. and special software to configure the Cisco Systems' SMDS implementation:
Follow these steps to configure SMDS service on the Cisco router:
Step 1: Determine the protocols you will be running over SMDS. Obtain from the service provider the group addresses that you will need to support those protocols.
Step 2: Obtain the SMDS hardware (individual) address from the service provider for each router that will interface directly into the SMDS network (that is, customer premises equipment).
Step 3: Configure the desired serial interface with SMDS encapsulation.
Step 4: Set up the static map for the desired protocols using the smds static-map command.
Step 5: Set up the multicast map for the desired protocols using the smds multicast command.
All addresses for SMDS service are assigned by the service provider, and may be assigned to individuals and groups.
A group address (also defined as a multicast address) is entered in the Cisco SMDS configuration software using an E1 prefix; a C1 prefix is used to specify individual addresses. The Cisco software expects the addresses to be entered in a slightly modified E.164 format. E.164 format is 64 bits. The first four bits are type code followed by 10 BCD digits padded to the full 60 bits with ones.
An example of an E.164 address follows:
C14155561313FFFF
The addresses may be entered with periods in a manner similar to Ethernet-style notation, or simply as a string of digits.
An example of an individual address entered in Ethernet-style notation would look like this:
C141.5555.1212
An example of a group address would look like this:
E18009999999
Enter the encapsulation smds interface subcommand to enable SMDS service on the desired interface:
encapsulation smdsThe interface to which this command applies must be a serial interface. All subsequent SMDS configuration commands only apply to an interface with encapsulation SMDS.
Following is an example of the commands you use to configure the SMDS service on interface serial 0:
!
interface serial 0
encapsulation smds
Enter the smds address interface subcommand to specify the SMDS individual address for a particular interface. The format of the command follows:
smds address smds-addressEnter an individual address provided by the SMDS service provider for the argument smds-address. Enter the address, as described in the section "Using SMDS Addresses." This address is protocol independent.
Enter the no smds address command to remove the address from the configuration file.
There is no default for this command.
The following example shows how to specify an individual address.
interface serial 0
smds address C141.5797.1313
Enter the smds enable-arp interface subcommand to enable the Address Resolution Protocol (ARP). The full syntax of this command follows.
smds enable-arpThe multicast address for ARP must be set before this command is issued.
By default, ARP is not enabled. Once ARP has been enabled, use the no smds enable-arp command to return the line to the default state.
Enter the smds static-map interface subcommand to configure a static mapping between an individual SMDS address and a higher level protocol address. The full syntax of the command follows:
smds static-map protocol-type protocol-address smds-addressDo not enter this command for broadcast or multicast addresses. For those addresses, use the smds multicast interface subcommand described in the section "Mapping to a Multicast Address."
Enter the name of the protocol for the protocol-type argument, followed with the address (specified in the corresponding protocol address format) in place of the protocol-address argument. Provide the SMDS address for the smds-address argument to complete the mapping. You must use these keywords to define the protocol type: ip, decnet, appletalk, xns, novell, or clns.
Use the no smds static-map command with the appropriate arguments to remove the map.
Following is an example of the smds static-map command.
smds static-map XNS 111.00C0.2711.0123 C141.5688.1212
The command will map XNS address 111.00C0.2711.0123 to the individual SMDS address C141.5688.1212.
Enter the smds multicast interface subcommand to map an SMDS group address to a broadcast or multicast address used by higher level protocols. The full syntax of the command follows:
smds multicast protocol-type smds-addressEnter the name of the protocol for the protocol-type argument, and follow with the SMDS address to answer the smds-address argument to complete the mapping. You may use these keywords to define the protocol type:
Since SMDS does not incorporate broadcast addressing, a group address for a particular protocol must be defined to serve the broadcast function. There is no default for this command.
Use the no smds multicast command with the appropriate arguments to remove a multicast address.
Following is an example of the smds multicast command:
smds multicast IP E180.0999.9999
The command maps the IP broadcast address to the SMDS group address E180.0999.9999.
Cisco's implementation of SMDS includes a configuration option that allows you to enable or disable the router's ability to interface to an AT&T SMDS switch that implements AT&T's SMDS d15-mode. Please consult with your service provider to find out if this command is needed.
Use the smds d15-mode interface subcommand in order to operate with an AT&T SMDS switch that implements the AT&T d15-mode packet structure. The command syntax follows:
smds d15 modeWhen this switch is disabled using the no smds d15-mode specification, the router will use AT&T's d11 packet structure.
When this switch is enabled, the router will use AT&T d15 packet structure. It should be off for systems which have not been upgraded.
Use the no smds d15-mode command to turn this function off. By default, the function is on.
An SMDS network can be thought of in much in the same way as an X25 cloud. The premises equipment, in this case a Cisco router, represents the edge of the cloud. The service provider enables communication across the cloud. However, proper configuration is needed for communication to occur. This configuration will differ between protocol families.
One major difference between protocol families is dynamic versus static routing among the routers (called remote peers) on the periphery of the cloud. For IP and CLNS, routing across the SMDS cloud is fully dynamic. No action on the user's part is needed for the mapping of higher level protocol addresses to SMDS addresses to occur. For the other supported protocols, a static entry must be made for each of the other neighbors. This entry provides a router with the information that it needs to communicate with all other neighbor routers.
Up until now this discussion has centered on the peer routers. What about all of the end nodes and routers behind the SMDS router? The static entries only need to be made for those routers that are SMDS remote peers. Nothing additional needs to be done in order to communicate with other nodes behind the peer routers.
Some protocol families need separate definitions for associated subprotocols. The next sections illustrates how to implement these kind of configurations. See Table 1-8 for a list of protocol families and what multicast is needed.
| Protocol Family | Multicasts Needed |
|---|---|
| IP | IP, ARP |
| DECnet | DECNET, DECNET_NODE, DECNET_ROUTER |
| CLNS | CLNS, CLNS_ES,CLNS_IS |
| Novell | NOVELL |
| XNS | XNS |
| AppleTalk | APPLETALK,AARP |
Both IP and ARP should be configured with the smds multicast command. ARP should be enabled. The results of the ARP activity can be shown with the show arp command. If desired, static ARP entries may be made by using this command:
arp ip-address address smdsThe argument ip-address is the IP address. The argument address is the SMDS address. The keyword smds appended to the end of this command is required.
Currently, dynamic address assignment does not work, and therefore an AppleTalk address must be assigned to the interface, and each remote router peer must be listed with an smds static-map command. The AppleTalk ARP (AARP) multicast address must still be configured with the smds multicast command. ARP should be enabled.
For XNS and/or Novell, the multicast address must be configured.
For Novell, RIP Routing packets, SAP packets, NetBios Name Lookups, directed broadcasts, and traffic to the helper addresses (if that helper address is a broadcast address) will be sent to the SMDS novell multicast address.
For XNS, only RIP, directed broadcasts, and helper traffic will be sent to the XNS multicast address.
For XNS and/or Novell configurations, a static map entry must be made for each remote peer.
Multicasts must be configured for CLNS_ES, and CLNS_IS. No static maps are necessary. ESHs, ISHs, and Router Hellos are sent to the multicast address, and neighbor entries are created automatically.
This section provides some examples of configurations to use as models for your configuration files.
Following is a typical interface configured for IP, DECnet, ISO CLNS, Novell, XNS, and AppleTalk.
interface Serial 4
ip address 1.1.1.2 255.0.0.0
decnet cost 4
appletalk address 92.1
appletalk zone smds
clns router igrp FOO
novell net 1a
xns net 17
encapsulation SMDS
! smds configuration follows
smds address c120.1580.4721
no smds d15-mode
smds static-map APPLETALK 92.2 c120.1580.4592
smds static-map APPLETALK 92.3 c120.1580.4593
smds static-map APPLETALK 92.4 c120.1580.4594
smds static-map NOVELL 1a.0c00.0102.23ca c120.1580.4792
smds static-map XNS 17.0c00.0102.23ca c120.1580.4792
smds static-map NOVELL 1a.0c00.0102.23dd c120.1580.4728
smds static-map XNS 17.0c00.0102.23aa c120.1580.4727
smds multicast NOVELL e180.0999.9999
smds multicast XNS e180.0999.9999
smds multicast ARP e180.0999.9999
smds multicast IP e180.0999.9999
smds multicast APPLETALK e180.0999.9999
smds multicast AARP e180.0999.9999
smds multicast CLNS_IS e180.0999.9990
smds multicast CLNS_ES e180.0999.9990
smds multicast DECNET_ROUTER e180.0999.9992
smds multicast DECNET_NODE e180.0999.9992
smds enable-arp
An example of a remote peer on the same SMDS network follows. Note that this router does not have DECnet routing enabled.
interface Serial 0
ip address 1.1.1.1 255.0.0.0
appletalk address 92.2
appletalk zone smds
clns router igrp FOO
novell net 1a
xns net 17
encapsulation SMDS
! smds configuration follows
smds address c120.1580.4792
no smds d15-mode
smds static-map APPLETALK 92.1 c120.1580.4721
smds static-map APPLETALK 92.3 c120.1580.4593
smds static-map APPLETALK 92.4 c120.1580.4594
smds static-map NOVELL 1a.0c00.0102.23cb c120.1580.4721
smds static-map XNS 17.0c00.0102.23cb c120.1580.4721
smds static-map NOVELL 1a.0c00.0102.23dd c120.1580.4728
smds static-map XNS 17.0c00.0102.23aa c120.1580.4727
smds multicast NOVELL e180.0999.9999
smds multicast XNS e180.0999.9999
smds multicast ARP e180.0999.9999
smds multicast IP e180.0999.9999
smds multicast APPLETALK e180.0999.9999
smds multicast AARP e180.0999.9999
smds multicast CLNS_IS e180.0999.9990
smds multicast CLNS_ES e180.0999.9990
smds enable-arp
Use the following EXEC commands to monitor the SMDS service.
Use the show smds addresses command to display the individual addresses and the interface that they are associated with. Enter this command at the EXEC prompt:
show smds addressesA sample display of the command output follows:
SMDS address - Serial0 c141.5555.1212
Use the show smds map command to display all SMDS addresses that are mapped to higher level protocol addresses. Enter this command at the EXEC prompt:
show smds mapThe display for this command includes all addresses entered with both the smds static-map and smds multicast command.
A sample display of the command output follows:
Serial0: ARP maps to e180.0999.9999 multicast
Serial0: IP maps to e180.0999.9999 multicast
Serial0: XNS 1006.AA00.0400.0C55 maps to c141.5688.1212 static
Use the show smds traffic command to display all the SMDS counters. Enter this command at the EXEC prompt:
show smds trafficA sample display of the command output follows:
0 Bad BA size errors
0 Bad Header extension errors
0 Invalid address errors
In the display:
Bad BA size errors field lists the number of corrupted packets received based on the expected Level 3 PDU buffer allocation size.
Bad Header extension errors field lists the number of invalid packets received in which the header extension length did not match what was expected in the Level 3 PDU.
Invalid address errors field lists the number of packets passed that were incorrectly sent to router. Both individual and multicast address errors are included in this count.
Use the following EXEC commands to debug the SMDS service. For each debug command, there is a corresponding undebug command that turns the messages off.
Use this command to see if ARPs are being sent or received. This command prints one line for each ARP sent or received.
Use this EXEC command to enable logging of SMDS events. This command prints a one-line message for each packet that is sent. The packet size, packet type, and SMDS source and destination addresses is printed. If packets are received with an incorrect destination address, it will be noted and counted.
Summaries of the global configuration commands relevant to each of the packet-switching technologies described in this chapter are collected in the listing that follows. These commands are listed in alphabetical order, according to technology type.
This section provides an alphabetically arranged summary of the X.25 global configuration commands.
[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
[no] x25 route [#position]x121-pattern [substitute-source rewrite-pattern]
[substitute-dest rewrite-pattern] [cud pattern] interface destination-interface
Inserts or removes an entry in the X.25 routing table. The x121-pattern pattern parameter is the X.121 address of the called destination and is required. The alias keyword permits a way for other X.121 addresses to be treated as local. The substitute-source keyword allows substitution of the calling address. The argument rewrite-pattern replaces the called or calling X.121 address in routed X.25 packets.
[no] x25 routing
Enables or disables X.25 switching. X.25 calls will not be forwarded until this command is issued. The command no x25 routing disables the forwarding of X.25 calls.
Summaries of the interface subcommands relevant to each of the packet-switching technologies described in this chapter are collected in the listing the follows. These commands are listed in alphabetical order, according to technology type. Interface subcommands are summarized for the following:
This section provides an alphabetical list of all the interface subcommands used in the X.25 interface.
[no] cmns enable
Enables CMNS on a non-serial interface. After executing the above 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 cmns enable command disables CMNS for the interface.
[no] x25 map cmns NSAP MAC-address
[no] x25 map cmns NSAP [X.121-address]
After enabling CMNS on a non-serial 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 NSAP-prefix, MAC-address, and X.121-address arguments specify the NSAP address-to-X.121 address or NSAP address-to-MAC address mappings.
To retract a mapping, use the no x25 map cmns interface subcommand with the appropriate address arguments.
Following is an alphabetically arranged summary of the frame relay interface subcommands.
encapsulation frame-relay
Specifies frame relay encapsulation on a specific interface.
[no] frame-relay keepalive seconds
Enables and disables the LMI mechanism for serial lines using the frame relay encapsulation.
[no] frame-relay local-dlci number
Sets the source DLCI for use when the LMI is not supported. If LMI is supported and the multicast information element is present, the network server sets its local DLCI based on information provided via the LMI. The argument number is the local, or source, DLCI number.
[no] frame-relay lmi-type ANSI
Specifies the exchange of local management interface messages as defined by ANSI standard T1.617.
The no frame-relay lmi-type ANSI returns the LMI type to the default as defined by the Cisco/Stratacom/Northern Telecom/DEC specification.
[no] frame-relay map protocol protocol-address DLCI [broadcast]
Defines the mapping between an address and the DLCI used to connect to the address.The frame relay map tells the network server how to get from a specific protocol and address pair to the correct DLCI. The argument protocol can be one of these keywords: ip, decnet, appletalk, xns, novell, vines, clns. The keyword is followed by the corresponding protocol address and the DLCI number. The optional broadcast flag specifies that broadcasts should be forwarded to this address when the multicast is not enabled. The default is not to forward broadcasts.
[no] frame-relay map bridge DLCI broadcast
This variation of the frame-relay map command is used for bridging.
[no] frame-relay map clns DLCI broadcast
This variation of the frame-relay map command is used for the ISO CLNS protocol.
no frame-relay map
Deletes the frame relay map entry.
[no] frame-relay multicast-dlci number
Defines a DLCI to be used for multicasts and should only be used when the multicast facility is not supported. Network transmissions (packets) sent to a multicast DLCI are delivered to all network servers defined as members of the multicast group. The argument number identifies the multicast group.
[no] frame-relay short-status
Instructs the network server to request the short status message from the switch (see version 2.3 of the joint Frame Relay Interface specification). The default is to request the full status message.
This section provides an alphabetical list of all the interface subcommands used in the LAPB interface.
encapsulation {lapb|lapb-dce}
Enables the running of datagrams of a single protocol over a serial interface using the LAPB encapsulation. 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.
encapsulation {multi-lapb|multi-lapb-dce}
Enables use of multiple network protocols on the same line at the same time.
lapb k window-size
Specifies the maximum permissible number of outstanding frames, called the window size. The argument window-size is a packet count from one to seven. The default value is seven packets.
lapb n1 bits
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 16,384, and must be a multiple of eight. The default value is 12,000 bits (1500 bytes).
lapb n2 retries
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.
lapb protocol keyword
Enables configuration of other protocols over a serial interface using LAPB encapsulation.Possible protocol keywords include ip, xns, decnet, appletalk, vines, clns, novell, and apollo.
lapb t1 milliseconds
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 3,000 milliseconds.
This section provides an alphabetically arranged summary of the SMDS interface subcommands. These commands must be preceded by an interface command.
arp ip-address address smds
Allows inclusion of static ARP entries. The argument ip-address is the IP address. The argument address is the SMDS address. The keyword smds appended to the end of this command is required.
encapsulation smds
Enables or disables SMDS on a particular interface. It should precede any SMDS command. This command has no default.
[no] smds address smds-address
Sets or removes the SMDS individual address for a particular interface. The argument smds-address is the individual address provided by the SMDS service provider, and is protocol independent. This command has no default.
[no] smds d15-mode
Allows for interoperation with an AT&T SMDS switch that implements the AT&T d15-mode packet structure. When this feature is disabled, using the no smds d15-mode specification, the router will use AT&T's d11-mode implementation.
[no] smds enable-arp
Enables or disables ARP processing on a particular interface. The multicast address for ARP must be set before this command is issued. Default is no smds enable-arp.
[no] smds multicast protocol-type smds-group-address
Maps an SMDS group address to a broadcast or multicast address used by higher-level protocols. This command has no default.
[no] smds static-map protocol-type protocol-address smds-address
Sets up a static mapping between an SMDS address and a higher-level protocol address. This should not be used for broadcast addresses, for broadcast address, use the smds multicast command. This command has no default.
This section provides an alphabetical list of all the interface subcommands used in the X.25 interface.
encapsulation bfex25
This encapsulation provides a mapping from Class A IP addresses to the type of X.121 addresses expected by the BFE encryption device.
encapsulation {ddnx25|ddnx25-dce}
Causes the router to specify the Standard Service facility in the Call Request packet, which notifies the PSNs to use Standard Service.
encapsulation hdh
Enables the HDH protocol.
encapsulation x25
Sets X.25 DTE operation.
encapsulation x25-dce
Sets X.25 DCE operation.
hdh {packet|message}
Enables router support for both the packet and message modes of HDH. The packet keyword specifies the packet mode; the message keyword specifies the message mode.
[no] x25 accept-reverse
Instructs the router to accept all reverse charge calls. This behavior can also be configured on a per-peer basis using the x25 map subcommand. The no form of the command resets the default state.
x25 address X.121-address
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.
[no] x25 default protocol
Specifies or removes the protocol assumed by the CPT to interpret calls with unknown Call User Data. The argument protocol sets the default protocol and is either ip or pad.
x25 facility keyword argument
no x25 facility keyword argument
Overrides interface settings on a per-call basis.
The 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.
x25 hic channel
Sets the highest incoming channel (HIC). The argument channel is a channel number from 1 through 4095. The default value is 1024.
x25 hoc channel
Sets the highest outgoing channel (HOC). The argument channel is a channel number from 1 through 4095. The default value is 1024.
[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. The no form without an argument removes this command from the configuration file; the command with a queue size value of zero returns the default.
[no] x25 hold-vc-timer minutes
Prevents overruns on X.25 switches for traffic through the VCs. The argument minutes is the number of minutes to prevent calls to a previously failed destination. Incoming calls will still be accepted.
x25 htc channel
Sets the highest two-way channel (HTC). The argument channel is a channel number from 1 through 4095. The default value is 1024.
[no] x25 idle minutes
Clears an SVC after a set period of inactivity. The argument minutes is the number of minutes in the period. Both calls originated and terminated by the router are cleared. The default value is 0 (zero), which causes the router to keep the SVC open indefinitely. The no variation restores this default.
[no] x25 ip-precedence
Enables or disables the ability to open a new virtual circuit based on the IP Type of Service (TOS) field. By default, Cisco routers open one virtual circuit for each type of service.
x25 ips bytes
x25 ops bytes
Set the router packet size to match those of the network. The ips keyword specifies the router input packet size while the keyword ops specifies the router output packet size. The argument bytes is a byte count in the range of 128 through 1024. The default value is 128 bytes. Larger packet sizes are better, because smaller packets require more overhead processing.
x25 lic channel
Sets the lowest incoming channel (LIC). The argument channel is a channel number from 1 through 4095. The default value is one.
[no] x25 linkrestart
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 form of the command turns off the default.
x25 loc channel
Sets the lowest outgoing channel (LOC). The argument channel is a channel number from 1 through 4095. The default value is one.
x25 ltc channel
Sets the lowest two-way channel (LTC). The argument channel is a channel number from 1 through 4095. The default value is one.
[no] x25 map protocol-keyword protocol-address X.121-address [option1 ... option6]
Specifies a network-protocol-to-X.121 address mapping such as Internet-to-X.121 or DECnet-to-X.121. The argument protocol-keyword can be one of these protocol types: ip, decnet, chaos, xns, novell, appletalk, vines, apollo, pup, clns, bridge, and cmns. 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.
[no] x25 map compressedtcp ip-address x.121-address [options]
Specifies a network-protocol-to-X.121 address mapping such as Internet-to-X.121 or DECnet-to-X.121. Refer to the description of the x25 map interface subcommand for supported protocols. This version is required to make 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 described in the preceding section.
The Call User Data of compressed TCP calls is the single byte 0xd8.
The no x25 map compressedtcp disables TCP header compression for the link.
x25 modulo modulus
Sets the modulus. The 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.
x25 nvc count
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.
[no] x25 pvc circuit protocol-keyword protocol-address
Establishes or deletes Permanent Virtual Circuits (PVCs). The 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 (set using the lic keyword). The argument protocol-keyword can be one of the supported protocol types: ip, decnet, chaos, xns, novell, appletalk, vines, apollo, pup, and bridge. The argument protocol-address is that of the host at the other end of the PVC.
x25 pvc pvc-number interface interface-name pvc-number
Configures a PVC for a given interface. The 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 keywords.
[no] x25 rpoa name number
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 address in outgoing calls The 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. The no form resets 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 form of the command resets the default state.
x25 t10 seconds
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.
x25 t11 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.
x25 t12 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.
x25 t13 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.
x25 t20 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.
x25 t21 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.
x25 t22 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.
x25 t23 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.
x25 th delay
Instructs 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, which improves line responsiveness at the expense of bandwidth. The 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.
[no] x25 use-source-address
Updates the source address of outgoing calls forwarded over a specific interface use the following command. The no variation prevents the update.
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, and determines how many packets the router can receive before sending an X.25 acknowledgment.
The wout keyword specifies the upper limits of the number of outstanding unacknowledged packets in the output window. The wout limit determines how many sent packets can remain unacknowledged before the router uses a hold queue.
To maintain high bandwidth utilization, assign these limits the largest number that the network allows. The argument packets is a packets count. The packet count for win and wout can range from one to the window modulus. The default value is two packets.
|
|