|
|
This chapter describes how to configure connections through X.25 networks and Link Access Procedure, Balanced (LAPB) connections. LAPB procedures are presented first for those users who only want to configure a simple, reliable serial encapsulation method. For a complete description of the commands mentioned in this chapter, refer to the "X.25 and LAPB Commands" chapter in the Router Products Command Reference publication. For historical background and a technical overview of X.25 and LAPB, see the Internetworking Technology Overview publication. To translate between an X.25 PAD connection and another protocol, refer to the Protocol Translator Configuration Guide and Command Reference publication.
X.25 is one of a group of specifications published by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T); these specifications are international standards that are formally called Recommendations. The ITU-T Recommendation X.25 defines how connections between data terminal equipment (DTE) and data communications equipment (DCE) are maintained for remote terminal access and computer communications. The X.25 specification defines protocols for two layers of the OSI reference model. The data link layer protocol defined is LAPB. The network layer is sometimes called the packet layer protocol (PLP), but is commonly (although less correctly) referred to as "the X.25 protocol."
The ITU-T updates its Recommendations periodically. The specifications dated 1980 and 1984 are the most common versions currently in use. Additionally, the International Standards Organization (ISO) has published ISO 7776:1986 as an equivalent to the LAPB standard, and ISO 8208:1989 as an equivalent to the ITU-T 1984 X.25 Recommendation packet layer. Our X.25 software follows the ITU-T 1984 X.25 Recommendation, except for its Defense Data Network (DDN) and Blacker Front End (BFE) operation, which follow the ITU-T 1980 X.25 Recommendation.
In addition to providing remote terminal access, our X.25 software provides transport for LAN protocols—IP, DECnet, XNS, ISO CLNS, AppleTalk, Novell IPX, Banyan VINES, and Apollo Domain—and bridging. For information about these protocols, refer to the specific protocol chapters in the this manual.
Briefly, the Cisco Systems X.25 software provides the following capabilities:
Our X.25 implementation does not support fast switching.
Reference information about X.25 facility handling by the capabilities listed above is found in the "X.25 Facility Handling" section before the examples at the end of this chapter.
It is possible to use only LAPB as a serial encapsulation method. This can be done when using a private serial line. You must use one of the X.25 packet-level encapsulations when attaching to an X.25 network.
The LAPB standards distinguish between two types of hosts: data terminal equipment (DTE), and data circuit-terminating equipment (DCE). At Level 2, or the data link layer in the OSI model, LAPB allows for orderly and reliable exchange of data between a DTE and a DCE. A router using LAPB encapsulation can act as a DTE or DCE device at the protocol level, which is distinct from the hardware DTE or DCE identity.
Using LAPB under noisy conditions can result in greater throughput than HDLC encapsulation. When LAPB detects a missing frame, the router retransmits the frame instead of waiting for the higher layers to recover the lost information. 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 transmitting host retransmissions. If the line is not noisy, the lower overhead of HDLC encapsulation is more efficient than LAPB. When using long delay satellite links, for example, the lock-step behavior of LAPB makes HDLC encapsulation the better choice.
To configure LAPB, complete the tasks in the following sections. The tasks in the first section are required; the remaining are optional.
Examples of LAPB configurations are given at the end of this chapter.
Set the appropriate LAPB encapsulation to run datagrams over a serial interface. One end of the link must be DTE and the other must be DCE.
| Task | Command |
| Specify a serial interface. | interface serial type number1 |
| 1This command is documented in the "Interface Commands" chapter in the Router Products Command Reference publication. |
To select an encapsulation and the protocol if using a single protocol, or to select the multiple protocol operation, perform one or more of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Enable encapsulation of a single protocol on the line using DCE operation. | encapsulation lapb dce [protocol]1 |
Enable encapsulation of a single protocol on the line using DTE operation. | encapsulation lapb [dte] [protocol]1 |
Enable use of multiple protocols on the line using DCE operation. | |
Enable use of multiple protocols on the line using DTE operation. |
| 1Single protocol LAPB defaults to IP encapsulation. 2Multi-LAPB does not support bridging (SRB and transparent) or TCP header compression. 3Only protocols supported by a single protocol encapsulation are supported by multiprotocol LAPB encapsulation. |
For an example of configuring LAPB DCE operation, see the section "Typical LAPB Configuration Example" later in this chapter.
X.25 Level 2 or LAPB operates at the data link layer of the OSI reference model. LAPB specifies methods for exchanging data (in units called frames), detecting out-of-sequence or missing frames, retransmitting frames, and acknowledging frames. Several protocol parameters can be modified to change LAPB protocol performance on a particular link. Because X.25 operates the PLP on top of the LAPB protocol, these tasks apply to both X.25 links and LAPB links. The parameters and their default values are summarized in Table 12-1.
| Task (LAPB Parameter) | Command | Values or Ranges | Default |
|---|---|---|---|
Set the modulo. | lapb modulo modulus | 8 or 128 | 8 |
Set the window size (k). | lapb k window-size | 1- (modulo minus 1) frames | 7 |
Set maximum bits per frame (N1). | lapb n1 bits | Bits (must be a multiple of 8) | Based on hardware MTU and protocol overhead |
Set count for sending frames (N2). | lapb n2 tries | 1-255 tries | 20 |
Set the retransmission timer (T1). | lapb t1 milliseconds | 1-64000 milliseconds | 3000 |
Set the hardware outage period. | lapb interface-outage milliseconds |
| 0 (disabled) |
Set the idle link period (T4). | lapb t4 seconds |
| 0 (disabled) |
The LAPB modulo determines the operating mode. Modulo 8 (basic mode) is widely available, because it is required for all standard LAPB implementations and is sufficient for most links. Modulo 128 (extended mode) can achieve greater throughput on high-speed links that have a low error rate (some satellite links, for example) by increasing the number of frames that can be transmitted before waiting for acknowledgment (as configured by the LAPB window parameter, k). By its design, LAPB's k parameter can be at most one less than the operating modulo. Modulo 8 links can typically send seven frames before an acknowledgment must be received; modulo 128 links can set k to a value as large as 127. By default, LAPB links use the basic mode with a window of 7.
When connecting to an X.25 network, use the N1 parameter value set by the network administrator. This value is the maximum number of bits in a LAPB frame, which determines the maximum size of an X.25 packet. When using LAPB over leased lines, the N1 parameter should be eight times the hardware maximum transmission unit (MTU) size plus any protocol overhead.
The LAPB N1 range is dynamically calculated by the Cisco IOS software whenever an MTU change, an L2/L3 modulo change, or a compression change occurs on a LAPB interface.
 | Caution The LAPB N1 parameter provides little benefit beyond the interface MTU, and can easily cause link failures if misconfigured. Cisco recommends that this parameter be left at its default value. |
The transmit counter (N2) is the number of unsuccessful transmit attempts will be made before the link is declared down.
The retransmission timer (T1) determines how long a transmitted frame can remain unacknowledged before the router polls for an acknowledgment. For X.25 networks, the router retransmission timer setting should match that of the network.
For an example of configuring the LAPB T1 timer, see the section "Typical LAPB Configuration Example" later in this chapter.
Cisco priority queuing and custom queuing are available for LAPB to allow administrators to improve a link's responsiveness to a given type of traffic by specifying the priority of that type of traffic for transmission on the link.
Priority queuing is a mechanism that classifies packets based on certain criteria and then assigns the packets to one of four output queues, with high, medium, normal, or low priority. Custom queuing similarly classifies packets and assigns them to one of ten output queues, and controls the percentage of an interface's available bandwidth that is used for a queue.
For example, an administrator can use priority queuing to ensure that all Telnet traffic is processed promptly and that SMTP traffic is sent only when there is no other traffic to send. Priority queuing in this example can starve the non-Telnet traffic; custom queuing can be used instead if the administrator wants to ensure that some traffic of all categories will get a chance to send.
Both priority queuing and custom queuing can be defined, but only one of them can be assigned to a given interface.
To configure priority and custom queuing for LAPB, perform the following tasks:
1. Perform the standard priority and custom queuing tasks except the task of assigning a priority or custom group to the interface, as described in the "Managing the System" chapter.
2. Perform the standard LAPB encapsulation tasks, as specified in the "Configure a LAPB Datagram Transport" section of this chapter.
3. Assign either a priority group or a custom queue to the interface, as described in the "Managing the System" chapter.
To configure X.25, complete the tasks in one or more of the following sections, depending upon the X.25 application or task required for your network. The interface, datagram transport, and routing tasks are divided into sections based generally on how common the feature is and how often it is used. Those features and parameters that are relatively uncommon are found in the "Additional" sections. LAPB frame parameters can be modified to optimize X.25 operation, as described earlier in this chapter.
All of these features can coexist on an X.25 interface.
Default parameters are provided for X.25 operation; however, you can change the settings to meet the needs of your X.25 network or as defined by your X.25 service supplier. We also provide additional configuration settings to optimize your X.25 usage.
See the end of this chapter for examples of configuring X.25.
To configure an X.25 interface on the router, perform the tasks in the following sections:
These tasks describe the parameters that are essential for correct X.25 behavior. The first task is required. The others might be required or optional, depending on what the router is expected to do and on the X.25 network.
You can also configure other, less common parameters, as specified in the "Configure Additional Interface Parameters" section.
A router using X.25 Level 3 encapsulation can act as a DTE or DCE protocol device (according to the needs of your X.25 service supplier), can use DDN or BFE encapsulation, or can use the IETF standard encapsulation, as specified by RFC 1356.
Because the default serial encapsulation is HDLC, you must explicitly configure an X.25 encapsulation method.
To configure the mode of operation and one of these encapsulation types for a specified interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Set X.25 mode of operation. |
Typically a public data network will require attachment as a DTE. (This is distinct from the hardware interface DTE/DCE identity.)
The default mode of operation is DTE, and the default encapsulation method is Cisco's pre-IETF method. If either DDN or BFE operation is needed, it must be explicitly configured.
For an example of configuring X.25 DTE operation, see the section "Typical X.25 Configuration Example" later in this chapter.
The X.25 protocol maintains multiple connections over one physical link between a DTE and a DCE. These connections are called virtual circuits or logical channels (LCs). X.25 can maintain up to 4095 virtual circuits numbered 1 through 4095. An individual virtual circuit is identified by giving its logical channel identifier (LCI) or virtual circuit number (VCN). Many documents use the terms virtual circuit and LC, and VCN, LCN, and LCI interchangeably. Each of these terms refer to the virtual circuit number.
An important part of X.25 operation is the range of virtual circuit numbers. Virtual circuit numbers are broken into four ranges (listed here in numerically increasing order):
1. Permanent virtual circuits (PVCs)
2. Incoming-only circuits
3. Two-way circuits
4. Outgoing-only circuits
The incoming-only, two-way, and outgoing-only ranges define the virtual circuit numbers over which a switched virtual circuit (SVC) can be established by placing an X.25 call, much like a telephone network establishes a switched voice circuit when a call is placed.
The rules about DCE and DTE devices initiating calls are as follows:
(The ITU-T Recommendation defines "incoming" and "outgoing" in relation to the DTE/DCE interface role; Cisco's documentation uses the more intuitive sense. Unless the ITU-T sense is explicitly referenced, a call received from the interface is an incoming call and a call sent out the interface is an outgoing call.)
There is no difference in the operation of the SVCs except the restrictions on which a device can initiate a call. These ranges can be used to prevent one side from monopolizing the virtual circuits, which can be useful for X.25 interfaces with a small total number of SVCs available.
Six X.25 parameters define the upper and lower limit of each of the three SVC ranges. A PVC must be assigned a number less than the numbers assigned to the SVC ranges. An SVC range is not allowed to overlap another range.
To configure X.25 virtual circuit ranges, complete the following tasks:
| Task | Command | Default |
|---|---|---|
Set the lowest incoming-only circuit number. | x25 lic limit | 0 |
Set the highest incoming-only circuit number. | x25 hic limit | 0 |
Set the lowest two-way circuit number. | x25 ltc limit | 1 |
Set the highest two-way circuit number. | x25 htc limit | 1024 (serial) |
Set the lowest outgoing-only circuit number. | x25 loc limit | 0 |
Set the highest outgoing-only circuit number. | x25 hoc limit | 0 |
Each of these parameters can range from 1 to 4095, inclusive. Note that the values for these parameters must be the same on both ends of an X.25 link. For connection to a public data network (PDN), these values must be set to the values assigned by the network. An SVC range is unused if its lower and upper limits are set to 0; other than this use for marking unused ranges, virtual circuit 0 is not available.
For an example of configuring virtual circuit ranges, see the section "Virtual Circuit Ranges Example" later in this chapter.
Our implementation of X.25 supports both modulo 8 and modulo 128 packet sequence numbering; module 8 is the default. To set the packet numbering modulo, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Set the packet numbering modulo (the default is 8). | x25 modulo {8 | 128} |
The X.25 modulo and the LAPB modulo are distinct, and each serves a different purpose. LAPB modulo 128 (or extended mode) can be used to achieve higher throughput across the DTE/DCE interface; it only affects the local point of attachment. X.25 PLP modulo 128 can be used to achieve higher end-to-end throughput for virtual circuits by allowing more data packets to be in-transit through the X.25 network.
If your router does not originate or terminate Calls but only participates in X.25 switching, this task is optional. However, if the router is attached to a PDN, you must set the interface X.121 address assigned by the X.25 network service provider. Interfaces that use the DDN or BFE mode will have an X.121 address generated from the interface IP address; for correct DDN or BFE operation, any such X.121 address must not be modified.
To set the X.121 address, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Set the X.121 address. | x25 address x.121-address |
For an example of configuring the X.25 interface address, see the section "Typical X.25 Configuration Example" later in this chapter.
Setting correct default flow control parameters (window size and packet size) is essential for correct operation of the link because X.25 is a strongly flow controlled protocol. However, it is easy to overlook this task because many networks use standard default values. Mismatched default flow control values will cause X.25 local procedure errors, evidenced by CLEAR and RESET events.
To configure flow control parameters, complete the tasks in the following sections. These tasks are optional if your X.25 attachment uses the standard default values for maximum packet sizes (128 bytes incoming and outgoing) and window sizes (two packets incoming and outgoing).
X.25 networks have a default input and output window size that is defined by the network administrator. You must set the router default input and output window sizes to match those of the network. These defaults are the values that are assumed if an SVC is set up without explicitly negotiating its window sizes. Any PVC also assumes these default values unless different values are configured. To set the default window sizes (default is 2), perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Set the default virtual circuit receive window size. | x25 win packets |
Set the default virtual circuit transmit window size. |
For an example of setting the default window sizes, see the sections "Typical X.25 Configuration Example" and "DDN X.25 Configuration Example" later in this chapter.
X.25 networks have a default maximum input and output packet size (default is 128) that is defined by the network administrator. You must set the router default input and output maximum packet sizes to match those of the network. These defaults are the values that are assumed if an SVC is set up without explicitly negotiating its maximum packet sizes. Any PVC will also assume these default values unless different values are configured. To set the router default input and output maximum packet sizes, perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Set the default input maximum packet size. | |
Set the default output maximum packet size. | x25 ops bytes |
To send a packet larger than the agreed 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 in the M-bit sequence and reassembles them into the original packet.
It is possible to define default packet sizes that cannot be supported by the lower layer (see the LAPB N1 parameter). However, the router will negotiate lower maximum packet sizes for all SVCs so the agreed sizes can be carried. The router will also refuse a PVC configuration if the resulting maximum packet sizes cannot be supported by the lower layer.
For an example of setting the default maximum packet sizes, see the sections "Typical X.25 Configuration Example" and "DDN X.25 Configuration Example" later in this chapter.
Some X.25 applications have less common or special needs. Several X.25 parameters are available to modify the X.25 protocol behavior for these applications.
To configure less common X.25 interface parameters for these special needs, perform the tasks in the following sections, as needed:
The X.25 Level 3 retransmission timers determine how long the router will wait for acknowledgment of control packets. You can set these timers independently. Only those timers that apply to the interface are configurable. (A DTE interface does not have the T1x timers, and a DCE interface does not have the T2x timers.)
To set the retransmission timers, perform any of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Set DTE T20 Restart Request. | x25 t20 seconds |
Set DCE T10 Restart Indication. | x25 t10 seconds |
Set DTE T21 Call Request. | x25 t21 seconds |
Set DCE T11 Incoming Call. | x25 t11 seconds |
Set DTE T22 Reset Request. | x25 t22 seconds |
Set DCE T12 Reset Indication. | x25 t12 seconds |
Set DTE T23 Clear Request. | x25 t23 seconds |
Set DCE T13 Clear Indication. | x25 t13 seconds |
For an example of setting the retransmission timers, see the section "DDN X.25 Configuration Example" later in this chapter.
When establishing SVCs, X.25 uses address in the form defined by the ITU-T Recommendation X.121 (or simply an "X.121 address"). An X.121 address has zero to 15 digits. Because of the importance of addressing to call setup, several interface addressing features are available for X.25.
To configure X.25 addresses, perform the tasks in the following sections:
An X.25 interface's X.121 address is used when it is the source or destination of an X.25 call. The X.25 call setup procedure identifies both the calling (source) and the called (destination) X.121 addresses. When an interface is the source of a call, it encodes the interface X.121 address as the source address.An interface determines that it is the destination of a received call if the destination address matches the interface's address.
Cisco's X.25 can also route X.25 calls, which involves placing and accepting calls, but the router is neither the source nor the destination for these calls. Routing X.25 does not modify the source or destination addresses, thus preserving the addresses specified by the source host. Routed (switched) X.25 simply connects two logical X.25 channels to complete an X.25 virtual circuit. An X.25 virtual circuit, then, is a connection between two hosts (the source host and the destination host) that is switched between zero or more routed X.25 links.
The null X.121 address (the X.121 address that has zero digits) is a special case. The router will assume that it is the destination host for any call it receives that has the null destination address.
A subaddress is an X.121 address that matches the digits defined for the interface's X.121 address, but has one or more additional digits after the base address. X.25 will act as the destination host for an incoming PAD call that specifies a destination that is a subaddress of the interface's address; the trailing digits specify which line a PAD connection is requesting. This feature is described in the Protocol Translation Configuration Guide and Command Reference publication. Other calls that use a subaddress can be accepted if the trailing digit or digits are zeros; otherwise the router will not act as the call's destination host.
Local processing (for example, IP encapsulation) can be performed only for incoming calls whose destination X.121 address matches the serial interface or alias of the interface.
To configure an alias, perform the following task in global configuration mode:
| Task | Command |
|---|---|
Supply an alias X.121 address for the interface. | x25 route [#position] x121-address-pattern [cud pattern] alias type number |
Some attachments require that no calling (source) address be presented in outgoing calls; this is called suppressing the calling address.
When attached to a Public Data Network, X.25 may need to ensure that outgoing calls only use the assigned X.121 address for the calling (source) address. Routed X.25 will normally use the original source address. Although individual X.25 route configurations can modify the source address, we provide a simple command to force the use of the interface address in all calls sent; this is called replacing the calling address.
To suppress or replace the calling address, perform the appropriate task in interface configuration mode:
| Task | Command |
|---|---|
Suppress the calling (source) X.121 address in outgoing calls. | |
Replace the calling (source) X.121 address in switched calls. |
Some attachments require that no called (destination) address be presented in outgoing calls; this is called suppressing the called address.
To suppress the called address, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Suppress the called (destination) X.121 address in outgoing calls. |
The Call Request packet that sets up a virtual circuit can encode a field called the Call User Data (CUD) field. Typically the first few bytes of Call User Data identify which high-level protocol will be carried by the virtual circuit. The router, when acting as a destination host, normally refuses a call if the Call User Data is absent or the protocol identification isn't recognized. The PAD protocol, however, specifies that unidentified calls be treated as PAD connection requests. Other applications require they be treated as IP encapsulation connection requests, per RFC 877. To configure either PAD or IP encapsulation treatment of unidentified calls, perform the following task in interface configuration mode
| Task | Command |
|---|---|
Establish a default virtual circuit protocol. | x25 default {ip | pad} |
By default, a PLP protocol restart is performed when the link level resets (for example, when LAPB reconnects). This behavior can be disabled for those few networks that do not allow it, but disabling this behavior is not recommended because it can cause anomalous packet layer behavior. To disable packet-level protocol restarts, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Disable packet-level restarts. |
X.25 Level 2 or LAPB operates at the data link layer of the OSI reference model. LAPB specifies methods for exchanging data (in units called frames), detecting out-of-sequence or missing frames, retransmitting frames, and acknowledging frames. Several protocol parameters can be modified to change LAPB protocol performance on a particular link. Because X.25 operates the PLP on top of the LAPB protocol, these tasks apply to both X.25 links and LAPB links. The parameters and their default values are summarized in Table 12-2.
| Task (LAPB Parameter) | Command | Values or Ranges | Default |
|---|---|---|---|
Set the modulo. | lapb modulo modulus | 8 or 128 | 8 |
Set the window size (k). | lapb k window-size | 1- (modulo minus 1) frames | 7 |
Set maximum bits per frame (N1). | lapb n1 bits | 1088-32840 bits (must be a multiple of 8) | Based on hardware MTU and protocol overhead |
Set count for sending frames (N2). | lapb n2 tries | 1-255 tries | 20 |
Set the retransmission timer (T1). | lapb t1 milliseconds | 1-64000 milliseconds | 3000 |
Set the hardware outage period. | lapb interface-outage milliseconds |
| 0 (disabled) |
Set the idle link period (T4). | lapb t4 seconds |
| 0 (disabled) |
The LAPB modulo determines the operating mode. Modulo 8 (basic mode) is widely available, because it is required for all standard LAPB implementations and is sufficient for most links. Modulo 128 (extended mode) can achieve greater throughput on high-speed links that have a low error rate (some satellite links, for example) by increasing the number of frames that can be transmitted before waiting for acknowledgment (as configured by the LAPB window parameter, k). By its design, LAPB's k parameter can be at most one less than the operating modulo. Modulo 8 links can typically send seven frames before an acknowledgment must be received; modulo 128 links can set k to a value as large as 127. By default, LAPB links use the basic mode with a window of 7.
When connecting to an X.25 network, use the N1 parameter value set by the network administrator. This value is the maximum number of bits in a LAPB frame, which determines the maximum size of an X.25 packet. When using LAPB over leased lines, the N1 parameter should be eight times the hardware maximum transmission unit (MTU) size plus any protocol overhead.
The transmit counter (N2) is the number of unsuccessful transmit attempts will be made before the link is declared down.
The retransmission timer (T1) determines how long a transmitted frame can remain unacknowledged before the router polls for an acknowledgment. For X.25 networks, the router retransmission timer setting should match that of the network.
For an example of configuring the LAPB T1 timer, see the section "Typical LAPB Configuration Example" later in this chapter.
X.25 support is most commonly configured as a transport for datagrams across an X.25 network. Datagram transport (or encapsulation) is a cooperative effort between two hosts across an X.25 network. This is configured by establishing a mapping on the encapsulating interface between the far host's protocol address (for example, IP or DECnet) and its X.121 address. The Call identifies the protocol that the virtual circuit will carry (in the Call User Data field), so the terminating host can accept the Call if it is configured to exchange the identified traffic with the source host.
Figure 12-1 illustrates two routers sending datagrams across an X.25 public data network.
Perform the tasks in the following sections, as necessary, to complete the X.25 configuration for your network needs:
The following sections describe how to perform these configuration tasks. Configuring the X.25 parameters and special features, including TCP header compression and X.25 bridging, are described in the section "Configure Additional X.25 Datagram Transport Features" later in this chapter.
Subinterfaces are virtual interfaces that can be used to connect several networks to each other through a single physical interface. Subinterfaces are made available on our routers because routing protocols, especially those using the split horizon principle, may need help to determine which hosts need a routing update. The split horizon principle, which allows routing updates to be distributed to other routed interfaces except the interface on which the routing update was received, works well in a LAN environment in which other routers reached by the interface have already received the routing update.
However, in a WAN environment using connection-oriented interfaces (like X.25 and Frame Relay), other routers reached by the same physical interface might not have received the routing update. Rather than forcing network administrators to connect routers by separate physical interfaces, we provide subinterfaces that are treated as separate interfaces. A network administrator can separate hosts into subinterfaces of a physical interface, the X.25 protocol is unaffected, and routing processes see each subinterface as a separate source of routing updates, so all subinterfaces are eligible to receive routing updates.
There are two types of subinterfaces: point-to-point and multipoint. Subinterfaces are implicitly multipoint, unless configured as point-to-point.
A point-to-point subinterface is used to encapsulate one or more protocols between two hosts. An X.25 point-to-point subinterface will accept only a single encapsulation command (such as x25 map or x25 pvc) for a given protocol (though you can use multiple encapsulation commands, one for each protocol, or multiple protocols for one map or PVC), so there can be only one destination for the protocol. All protocol traffic routed to a point-to-point subinterface will be forwarded to the one destination host defined for the protocol. (Because only one destination is defined for the interface, the routing process does not even have to consult the destination address in the datagrams.)
A multipoint subinterface is used to connect one or more hosts for a given protocol. There is no restriction on the number of encapsulation commands that can be configured on a multipoint subinterface. Because the hosts appear on the same subinterface, they are not relying on the router to distribute routing updates between them. When a routing process forwards a datagram to a multipoint subinterface, the X.25 encapsulation process must be able to map the datagram's destination address to a configured encapsulation command. If the routing process cannot find a map for the datagram destination address, the encapsulation will fail.
To create and configure a subinterface, complete the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Create a point-to-point or multipoint subinterface. | interface serial number.subinterface-number [point-to-point | multipoint]1 |
Configure an X.25 encapsulation map for the subinterface or Establish an encapsulation PVC for the subinterface or both. | x25 map protocol address [protocol2 address2 [... [protocol9 address9]]] x.121-address [option] x25 pvc circuit protocol address [protocol2 address2 [...[protocol9 address9]]] x.121-address [option] |
| 1This command is documented in the "Interface Commands" chapter of the Router Products Command Reference publication. |
For an example of configuring an X.25 subinterface and using multiple encapsulation commands for a single destination address, see the "Point-to-Point Subinterface Configuration Example" section later in this chapter. For more general information about configuring subinterfaces, refer to the "Configuring Interfaces" chapter of this manual.
This section describes the X.25 single-protocol and multiprotocol encapsulation options that are available and describes how to map protocol addresses to an X.121 address for a remote host. This section also includes reference information about how protocols are identified.
We also support a newer standard, RFC 1356, which standardizes a method for encapsulating most datagram protocols over X.25. It also specifies how one virtual circuit can carry datagrams from more than one protocol.
A router can be configured to use any of the available encapsulation methods with a particular host.
Once an encapsulation virtual circuit is established using any method, sending and receiving a datagram is a simple process of fragmenting and reassembling the datagram into and from an X.25 complete packet sequence. An X.25 complete packet sequence is one or more X.25 data packets that have the More bit set in all but the last packet. A virtual circuit that can carry multiple protocols includes protocol identification data as well as the protocol data at the start of each complete packet sequence.
This section contains background material only.
The various methods and protocols used in X.25 SVC encapsulation are identified in a specific field of the call packet; this field is defined by X.25 to carry Call User Data (CUD). Only PVCs do not use Call User Data to identify its encapsulation (since PVCs do not use the X.25 call setup procedures).
Table 12-3 summarizes the values used in the Call User Data field to identify protocols.
| Protocol | Cisco Protocol Identifier | IETF RFC 1356 Protocol Identifier |
|---|---|---|
Apollo Domain | 0xD4 | 0x80 (5-byte SNAP encoding1) |
AppleTalk | 0xD2 | 0x80 (5-byte SNAP encoding) |
Banyan VINES | 0xC0 00 80 C42 | 0x80 (5-byte SNAP encoding) |
Bridging | 0xD5 | (Not implemented) |
ISO CLNS | 0x81 | 0x813 |
Compressed TCP | 0xD8 | 0x00 (5-byte SNAP encoding)4 |
DECnet | 0xD0 | 0x80 (5-byte SNAP encoding) |
IP | 0xCC | 0xCC5 |
Novell IPX | 0xD3 | 0x80 (5-byte SNAP encoding) |
PAD | 0x016 | 0x016 |
QLLC | 0xC3 | (Not available) |
XNS | 0xD1 | 0x80 (5-byte SNAP encoding) |
Multiprotocol | (Not available) | 0x00 |
Once a multiprotocol virtual circuit has been established, datagrams on the virtual circuit have protocol identification data before the actual protocol data; the protocol identification values are the same used by RFC 1356 in the CUD field for an individual protocol.
Encapsulation is a cooperative process between the router and another X.25 host. Since X.25 hosts are reached using an X.121 address (an X.121 address has between 0 and 15 decimal digits), the router must have a means to map a host's protocols and addresses to its X.121 address.
Each encapsulating X.25 interface should be configured with the relevant datagram parameters. For example, an interface that encapsulates IP will typically have an IP address.
A router set up for DDN or BFE service uses a dynamic mapping technique to convert between IP and X.121 addresses. These techniques have been designed specifically for attachment to the DDN network and to Blacker encryption equipment. Their design, restrictions, and operation make them work well for these specific applications, but not for other networks.
You should also establish the X.121 address of an encapsulating X.25 interface using the x25 address interface configuration command. This is the address that encapsulation calls should be directed to. It will also be used as the source X.121 address when originating an encapsulation call, which is how the destination host will be able to map the source host and protocol to the protocol address; thus an encapsulation virtual circuit must be a mapped at both the source and destination host interfaces. A DDN or BFE interface will have an X.121 address generated from the interface IP address, which for proper operation, should not be modified.
For each X.25 interface, you must explicitly map each destination host's protocols and addresses to its X.121 address. If needed and the destination host has the capability, one host map can be configured to support several protocols; alternatively, you can define one map for each supported protocol.
To establish a map, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Map one or more host protocol addresses to the host's X.121 address. | x25 map protocol address [protocol2 address2[...[protocol9 address9]]] x.121-address [option] |
As an example, if you are encapsulating IP over a given X.25 interface, you should define an IP address for the interface and, for each of the desired destination hosts, map the host's IP address to its X.121 address.
An individual host map can use the given keyword to specify the following protocols:
Each mapped protocol takes a datagram address except bridging (all bridged datagrams are sent to all bridge maps on an interface) and CLNS (which uses the mapped X.121 address as the SNPA, which is referenced by a clns neighbor command); the configured datagram protocol(s) and their relevant address are mapped to the destination host's X.121 address. All protocols that are supported for RFC 1356 operation can be specified in a single map (bridging and QLLC are not supported for RFC 1356 encapsulation). If IP and TCP header compression are both specified, the same IP address must be given for both protocols.
When setting up the address map, you can include options, such as enabling broadcasts and specifying the number of virtual circuits allowed, and defining various user facility settings.
For specific information about how to establish a protocol to run over X.25, refer to the appropriate protocol chapters in this publication or in the Router Products Command Reference publication.
By default, packet assembler/disassembler (PAD) connection attempts are processed for session creation or protocol translation (subject to the configuration of those functions) from all hosts. To restrict PAD connections to only statically mapped X.25 hosts, perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Restrict PAD access. | |
Configure a host for PAD access. | x25 map pad x121-address [option] |
You can configure outgoing PAD access using the optional features of the x25 map pad command without restricting incoming PAD connections to the configured hosts.
Permanent virtual circuits (PVCs) are the X.25 equivalent of leased lines; they are never disconnected. You no longer need to configure an address map before defining a PVC; an encapsulation PVC implicitly defines a map.
To establish a PVC, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Set a encapsulation PVC. | x25 pvc circuit protocol address [protocol2 address2 [...[protocol9 address9]]] x.121-address [option] |
The x25 pvc command uses the same protocol keywords as the x25 map command. See the "Map Datagram Addresses to X.25 Hosts" section of this chapter for a list of protocol keywords. Encapsulation PVCs also use a subset of the options defined for the x25 map command.
For an example of configuring a PVC, see the section "PVC Used to Exchange IP Traffic Example" later in this chapter.
We support RFC 1144 TCP/IP header compression (THC) on serial lines using HDLC and X.25 encapsulation. THC encapsulation is only slightly different from other encapsulation traffic, but these differences are worth noting. The implementation of compressed TCP over X.25 uses one virtual circuit to pass the compressed packets. Any IP traffic (including standard TCP) is separate from TCH traffic; it will be carried over separate IP encapsulation virtual circuits or identified separately in a multiprotocol virtual circuit.
To set up a separate virtual circuit for X.25 TCP header compression, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Allow a separate virtual circuit for compressed packets. | x25 map compressedtcp ip-address [protocol2 address2 [...[protocol9 address9]]] x.121-address [option] |
Our transparent bridging software supports bridging over X.25 virtual circuits. Bridging is not supported for RFC 1356 operation. Bridge maps should include the broadcast option for correct operation,
To enable the X.25 bridging capability, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Define bridging of X.25 frames. | x25 map bridge x.121-address broadcast [option] |
The router software allows you to configure additional X.25 datagram transport features, including various user facilities defined for X.25 call setup.
This section describes the X.25 datagram transport features you can configure; these features are configured using the option field in the x25 map or x25 pvc encapsulation commands (or by setting an interface default). Which tasks you perform depends upon your needs, the structure of your network and the requirements of the service provider
To configure the optional parameters, user facilities, and special features, perform one or more of the tasks described in the following sections:
For increased efficiency on relatively slow networks, our routers support X.25 payload compression of outgoing encapsulation traffic.
Several restrictions apply to X.25 payload compression:
To enable payload compression over X.25, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Enable payload compression over X.25. | x25 map protocol address [protocol2 address2 [...[protocol9 address9]]] x.121-address compress |
This command specifies that X.25 compression is to be used between the two hosts. Because each virtual circuit established for compressed traffic uses significant amounts of memory, compression should be used with careful consideration of its impact on the router's performance.
The compress option may be specified for an encapsulation PVC.
The router can clear a datagram transport SVC after a set period of inactivity. PAD and routed SVCs are not timed for inactivity. You can set this time by performing the following task in interface configuration mode:
| Task | Command |
|---|---|
Set an idle time for clearing encapsulation. | x25 idle minutes |
Specify an idle time for clearing a map's SVCs. | x25 map protocol address [protocol2 address2 [...[protocol9 address9]]] x.121-address idle minutes |
For an example of configuring the SVC idle timer, see the section "Typical X.25 Configuration Example" later in this chapter. See the section "Monitor and Maintain LAPB and X.25" later in this chapter for additional commands that clear virtual circuits.
For X.25 datagram transport, you can establish up to eight switched virtual circuits to one host for each map. To increase the number of virtual circuits allowed, perform one or both of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Specify the default maximum number of SVCs that can be open simultaneously to one host for each map. | |
Specify the maximum number of SVCs allowed for a map. | x25 map protocol address [protocol2 address2 [...[protocol9 address9]]] x.121-address nvc count |
For an example of increasing the number of virtual circuits allowed, see the sections "Typical X.25 Configuration Example" and "DDN X.25 Configuration Example" later in this chapter.
Upon receiving a Clear for an outstanding datagram transport Call Request, the X.25 encapsulation code immediately tries another Call Request if it has more traffic to send. This action can overrun some X.25 switches.To define the number of minutes the router will prevent calls from going to a previously failed destination, perform the following task in interface configuration mode (incoming calls will still be accepted):
| Task | Command |
|---|---|
Configure the ignore destination time. | x25 hold-vc-timer minutes |
You can instruct the router to send an acknowledgment packet when it has received a threshold of data packets it has not acknowledged, instead of waiting until its input window is full. A value of 1 will send an acknowledgment for each data packet received if it cannot be acknowledged in an outgoing data packet. This approach improves line responsiveness at the expense of bandwidth. A value of 0 restores the default behavior of waiting until the input window is full.
To establish the acknowledgment threshold, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Establish the threshold at which to acknowledge data packets. | x25 th delay-count |
The packet acknowledgment threshold also applies to encapsulation PVCs.
The X.25 software provides commands to support X.25 user facilities—options specified by the creators of the X.25 Recommendation—that allow you to implement features such as accounting, user identification, and flow control negotiation. You can choose to configure facilities on a per-map basis or on a per-interface basis. In the following table, the x25 map commands configure facilities on a per-map basis; the x25 facility commands specify the values sent for all encapsulation calls originated by the interface. Routed calls are not affected by the facilities specified for the outgoing interface.
To set the supported X.25 user facilities, perform one or more of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Select closed user group. | x25 facility cug number |
Set flow control parameter negotiation values to request on outgoing calls. | x25 facility packetsize in-size out-size x25 facility windowsize in-size out-size |
x25 facility reverse | |
x25 accept-reverse | |
x25 facility throughput in out | |
Select transit delay. | x25 facility transit-delay number |
x25 facility rpoa name | |
Set the Cisco standard network user identification. | x25 map protocol address [protocol2 address2 [...[protocol9 address9]]] x.121-address nuid username password |
Set a user-defined network user identification allowing format determined by the network administrator | x25 map protocol address [protocol2 address2 [...[protocol9 address9]]] x.121-address nudata string |
The windowsize and packetsize options are supported for PVCs, although they have a slightly different meaning since PVCs do not use the call setup procedure. If the PVC does not use the interface defaults for the flow control parameters, these options must be used to specify the values. Not all networks will allow a PVC to be defined with arbitrary flow control values.
Additionally, the D-bit is supported, if negotiated. PVCs allow the D-bit procedure since there is no call setup to negotiate its use. Both restricted and unrestricted fast select are also supported and are transparently handled by the software. No configuration is required for use of the D-bit or fast select facilities.
To define the maximum number of packets that can be held while a virtual circuit is unable to send data, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Define the virtual circuit packet hold queue size. | x25 hold-queue queue-size |
An encapsulation virtual circuit's hold queue size is determined when it is created; the x25 hold-queue command will not affect existing virtual circuits. This command also defines the hold queue size of encapsulation PVCs.
An X.25 map can be restricted so that it will not be used to place calls or so that it will not be considered when mapping incoming calls.
To restrict X.25 map usage, use the following map options as needed:
| Task | Command |
|---|---|
Restrict incoming calls from a map. | x25 map protocol address [protocol2 address2 [...[protocol9 address9]]] x.121-address no-incoming |
Restrict outgoing calls from a map. | x25 map protocol address [protocol2 address2 [...[protocol9 address9]]] x.121-address no-outgoing |
The X.25 software implementation allows virtual circuits to be routed from one X.25 interface to another and from one router to another. The routing behavior can be controlled with switching and XOT configuration commands, based on a locally built table.
X.25 encapsulation can share an X.25 serial interface with the X.25 switching support. Switching or forwarding X.25 virtual circuits can be done two ways:
Running X.25 over TCP/IP provides a number of benefits. The datagram containing the X.25 packet can be switched by other routers using their high-speed switching abilities. X.25 connections can 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 router, where it can be output to an X.25 interface.
When the connection is made locally, the switching configuration is used; when the connection is across a LAN, the XOT configuration is used. The basic function is the same for both types of connections, but different configuration commands are required for the two types of connections.
The X.25 switching subsystem supports the following facilities and parameters:
The handing of these facilities is described in the "X.25 Facility Handling" section.
To configure X.25 routing, perform the tasks in the following sections:
You may also need to configure additional X.25 routing features, as required for your network. Each task is described in a following section.
You must enable X.25 routing to use local switching or XOT. To enable local X.25 routing, perform the following task in global configuration mode:
| Task | Command |
|---|---|
Enable X.25 routing. |
The USE-TCP-IF-DEFS keyword is used by some routers that receive remote routed calls from older versions of XOT; it might be needed if the originating router cannot be migrated to a new software release. The use of this keyword is described in the "Configure XOT to Use Interface Default Flow Control Values" section later in this chapter.
For an example of configuring X.25 routing, see the sections "X.25 Route Address Pattern Matching Example" and "X.25 Routing Example" later in this chapter.
When an incoming call is received that should be forwarded, two fields in the X.25 routing table are consulted to determine a local X.25 route: the destination X.121 address and, optionally, the X,25 packet's 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 call is forwarded. Forwarding to a specified interface is called local routing or local switching.
To configure a local X.25 route (thus adding the local route to the routing table), perform the following task in global configuration mode:
| Task | Command |
|---|---|
Configure a local X.25 route (switching). | x25 route [#position] x121-address [cud pattern] interface type number |
A remote X.25 route is one that crosses a TCP connection. Such routes are called X.25 over TCP (XOT) routes (formerly remote routes or tunneled routes).
When an incoming call is received that should be forwarded, two fields in the X.25 routing table are consulted to determine a remote X.25 route: the destination X.121 address and, optionally, the X.25 packet's 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 call is forwarded.
You can also specify an XOT source that causes the XOT TCP connection to use the IP address of a specified interface as the source address of the TCP connection. If, for instance, a loopback interface is specified for the XOT connection's source address, TCP can use a primary interface or any backup interface to reach the other end of the connection. However, if a physical interface's address is specified as the source address, the XOT connection is terminated if that interface goes down.
To configure an XOT route (thus adding it to the X.25 routing table), perform the following task in global configuration mode:
| Task | Command |
|---|---|
Configure an XOT (remote) X.25 route (tunneling). | x25 route [#position] x121-address |
You can configure an X.25 PVC in the X.25 switching software. This means that DTEs that require permanent circuits can be connected to a router acting as an X.25 switch and have a properly functioning connection. X.25 RESETs will be sent to indicate when the circuit comes up or goes down. Both interfaces must define complementary locally switched PVCs.
To configure a locally switched PVC, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Configure a locally switched PVC. |
The command options are packetsize in out and windowsize in out; they allow a PVC's flow control values to be defined if they differ from the interface defaults.
For an example of configuring a local switched PVC, see the section "PVC Switching on the Same Router Example" later in this chapter.
A PVC can be connected to another router over a LAN using the XOT protocol. When the interfaces come up, a TCP connection is established to the router that is acting as the switch for the destination. All X.25 packets will be sent and received over this reliable data stream. Flow control is maintained end-to-end. This was previously called remote PVC switching or tunneling.
Running X.25 over TCP/IP provides a number of benefits. Other routers can switch IP datagrams containing the X.25 packets using the router's high-speed switching abilities. X.25 data can be sent over networks running only 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 XOT host where it can be output to an X.25 interface. Both interfaces must define complementary tunneled PVCs.
To configure a remote PVC to connect across a TCP/IP LAN, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Configure a remote PVC to connect across a TCP/IP LAN. | x25 pvc number1 tunnel address interface serial string pvc number2 [option] |
The command options are packetsize in out and windowsize in out; they allow a PVC's flow control values to be defined if they differ from the interface defaults.
For an example of configuring a remote tunneled PVC, see the section "Remote PVC Tunneling Example" later in this chapter.
To configure other, less common X.25 routing features, perform the tasks in the following sections:
When setting up a connection, the source and destination XOT implementations need to cooperate to determine the flow control values that apply to the SVC. The source XOT does this by encoding the X.25 flow control facilities (the window sizes and maximum packet sizes) in the X.25 call packet; the far host's XOT implementation can then correctly negotiate the flow control values at the destination interface and, if needed, indicate the final values in the X.25 call confirm packet.
The versions of XOT prior to software Release 9.1(4.1) will not, however, ensure that these flow control values are encoded in the X.25 call packet. When XOT receives a call that leaves one or both of the flow control values unspecified, it must assume what those values are. The safest values to assume are window sizes of two packets and maximum packet sizes of 128 bytes; according to the standards, any SVC can be negotiated to use these values. Thus when XOT receives a call from an older XOT implementation, it can specify in the call confirm that these flow control values must revert to the lowest common denominator.
What the older XOT implementations required was that the source and destination XOT router use the same default flow control values on the two X.25 interfaces that connect the SVC; it was easy to create connection with mismatched flow control values if this assumption was not true, which results in mysterious problems. The current implementation's practice of signalling the values in the call confirm avoids these problems.
Occasionally the older XOT implementation will be connected to a piece of X.25 equipment that cannot handle modification of the flow control parameters in the call confirm packet. These configurations should be upgraded to use a more recent version of XOT; when this is not possible, XOT's behavior causes a migration problem. In this situation, the user may configure the router to cause XOT to assume that any unspecified flow control facility values should come from the destination interface's default values. To configure this behavior, add the option use-tcp-if-defs when enabling X.25 routing in global configuration mode:
| Task | Command |
|---|---|
Enable X.25 routing; optionally modify XOT's assumption of unencoded flow control values. |
When interconnecting two separate X.25 networks, it is sometimes necessary to provide for address translation for local routes. Your X.25 switch supports translation of X.25 source and destination addresses for local switching. To translate addresses, perform either or both of the following tasks in global configuration mode:
| Task | Command |
|---|---|
Translate X.25 source address when local switching. | x25 route [#position] x121-address [cud pattern] [substitute-source pattern] interface interface number |
Translate X.25 destination address when local switching. | x25 route [#position] x121-address [cud pattern] [substitute-dest pattern] interface interface number |
Address substitution is not available for XOT routes.
XOT routes can be configured with alternate addresses. On routing a call, XOT will try each XOT destination host in sequence; if the TCP connection establishment fails, the next destination will be tried. Up to six XOT destination addresses can be entered.
To configure an XOT route with alternate addresses, (thus adding it to the X.25 routing table), perform the following task in global configuration mode:
| Task | Command |
|---|---|
Configure an XOT route; optionally define alternate XOT destination hosts. | x25 route [#position] x121-address [cud pattern] ip ip-address [ip-address2 [...[ip-address6]]] |
The sequence of alternate destination XOT host addresses is simply added to the normal XOT route configuration command.
For an example of constructing the routing table, see the section "X.25 Routing Example" later in this chapter.
The Connection-Mode Network Service (CMNS) provides a mechanism through which local X.25 switching can be extended to nonserial media by using OSI-based NSAP addresses. This implementation runs packet-level X.25 over frame-level LLC2.
In addition, our 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 and X.121 addresses to NSAP addresses.
Implementing CMNS routing involves completing the tasks in the following sections:
Enable CMNS on a nonserial interface by performing the following task in interface configuration mode:
| Task | Command |
|---|---|
Enable CMNS. |
For an example of enabling CMNS on an interface, see the section "Enabling CMNS for X.121 and MAC Addresses Example" later in this chapter.