Table Of Contents
Configuring a LAPB Datagram Transport
Configuring Compression of LAPB Data
Modifying LAPB Protocol Parameters
Configuring Priority and Custom Queueing for LAPB
Configuring Transparent Bridging over Multiprotocol LAPB
Configuring X.25 Encapsulation
Setting the Virtual Circuit Ranges
Setting the Packet Numbering Modulo
Configuring X.25 Switch Local Acknowledgment
Enabling Flow Control Parameter Negotiation
Verifying Flow Control Parameter Negotiation
Setting Default Flow Control Values
Enabling Asymmetrical Flow Control
Configuring Additional X.25 Interface Parameters
Configuring the X.25 Level 3 Timers
Configuring an Interface Alias Address
Suppressing or Replacing the Calling Address
Suppressing the Called Address
Establishing a Default VC Protocol
Configuring an X.25 Datagram Transport
Configuring Point-to-Point and Multipoint Subinterfaces
Creating and Configuring X.25 Subinterfaces
Mapping Protocol Addresses to X.121 Addresses
Understanding Protocol Encapsulation for Single-Protocol and Multiprotocol VCs
Understanding Protocol Identification
Mapping Datagram Addresses to X.25 Hosts
Establishing an Encapsulation PVC
Setting X.25 TCP/IP Header Compression
Configuring Additional X.25 Datagram Transport Features
Configuring X.25 Payload Compression
Configuring the Encapsulation VC Idle Time
Increasing the Number of VCs Allowed
Configuring the Ignore Destination Time
Establishing the Packet Acknowledgment Policy
Configuring X.25 User Facilities
Defining the VC Packet Hold Queue Size
Configuring a PVC Switched Between X.25 Interfaces
Configuring X.25 Switching Between PVCs and SVCs
Configuring Additional X.25 Routing Features
Configuring X.25 Load Balancing
Configuring XOT to Use Interface Default Flow Control Values
Configuring Calling Address Interface-Based Insertion and Removal
Verifying Interface-Based Calling Address Insertion
Substituting Addresses in an X.25 Route
Configuring XOT Alternate Destinations
Configuring DNS-Based X.25 Routing
Verifying DNS-Based X.25 Routing
Verifying DNS-Based X.25 Mnemonic Resolution
Configuring X.25 over Frame Relay (Annex G)
Configuring a Route to a CMNS Host
Configuring Priority Queueing or Custom Queueing for X.25
Configuring X.25 Closed User Groups
Incoming and Outgoing Access CUGs
Incoming and Outgoing Calls Barred within a CUG
Configuring X.25 CUG Service, Access, and Properties
Configuring a POP with No CUG Access
Configuring a POP with Access Restricted to One CUG
Configuring a POP with Multiple CUGs and No Public Access
Configuring a POP with Multiple CUGs and Public Access
Troubleshooting Tips for X.25 CUG Service
Understanding DDN X.25 Dynamic Mapping
Defining IP Precedence Handling
Configuring Blacker Front End (BFE) X.25
Entering Blacker Emergency Mode
Configuring X.25 Remote Failure Detection
X.25 Remote Failure Detection with IP Static Routes
X.25 Remote Failure Detection and the Backup Interface
Verifying X.25 Remote Failure Detection
Applying an Access List to a Virtual Terminal Line
Creating an X.29 Profile Script
Monitoring and Maintaining LAPB and X.25
X.25 and LAPB Configuration Examples
Typical LAPB Configuration Example
Transparent Bridging for Multiprotocol LAPB Encapsulation Example
Typical X.25 Configuration Example
PVC Switching on the Same Router Example
X.25 Route Address Pattern Matching Example
PVC Used to Exchange IP Traffic Example
Point-to-Point Subinterface Configuration Example
Simple Switching of a PVC over XOT Example
PVC Switching over XOT Example
X.25 Load Balancing Using VC-Count Distribution Method Example
X.25 Load Balancing with Multiple Hunt Groups Example
X.25 Switching Between PVCs and SVCs Example
Inserting and Removing X.121 Addresses as Calls Are Routed Example
Forwarding Calls Using the continue Keyword Example
X.25 Routing Statements Before continue Keyword
Same X.25 Network Configuration with continue Keyword
DNS-Based X.25 Routing Example
X.25 over Frame Relay (Annex G) Example
CMNS Switching over a PDN Example
CMNS Switched over Leased Lines Example
Configuring Local Acknowledgment Example
Setting Asymmetrical Window and Packet Sizes Flow Control Never Example
Configuring Flow Control Always Example
X.25 CUG Service, Access, and CUG Properties Example
POP with No CUG Access Example
POP with Access Restricted to One CUG Example
POP with Multiple CUGs and No Public Access Example
POP with Multiple CUGs and Public Access Example
DDN X.25 Configuration Example
Blacker Emergency Mode Example
X.25 Ping Support over Multiple Lines Example
Booting from a Network Server over X.25 Example
X.25 Remote Failure Detection Examples
X.25 Remote Failure Detection with IP Static Routes Example
X.25 Remote Failure Detection and the Backup Interface Example
Configuring X.25 and LAPB
This chapter describes how to configure connections through Link Access Procedure, Balanced (LAPB) connections and X.25 networks. LAPB tasks are presented first for users who only want to configure a simple, reliable serial encapsulation method. This chapter contains the following sections:
This chapter describes how to configure Defense Data Network (DDN) X.25 and the Blacker Front End (BFE), and how to create X.29 access lists. This chapter also describes the following new features:
•
Closed user groups (CUGs)
•
•
•
These X.25 command configuration modes have been introduced within the following commands:
•
•
For a complete description of the commands mentioned in this chapter, refer to the "X.25 and LAPB Commands" chapter in the Cisco IOS Wide-Area Networking Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
The following table lists related topics and their chapter and book location for further information:
LAPB Overview
You can only use LAPB as a serial encapsulation method if you have a private serial line. You must use one of the X.25 packet-level encapsulations when attaching to an X.25 network.
LAPB standards distinguish between the following two types of hosts:
•
•
At Level 2 (data link layer) in the OSI model, LAPB allows orderly and reliable exchange of data between a DTE and a DCE device. A router using LAPB encapsulation can act as a DTE or DCE at the protocol level, which is distinct from the hardware DTE or DCE identity.
Using LAPB under heavy traffic conditions can result in greater throughput than is possible using High-Level Data Link Control (HDLC) encapsulation. When LAPB detects a missing frame, the router resends the frame instead of waiting for the higher layers to recover the lost information. This behavior is useful only if the host timers are relatively slow. In the case of quickly expiring host timers, however, LAPB spends much time sending host retransmissions. If the line is not busy with data traffic, HDLC encapsulation is more efficient than LAPB. When long-delay satellite links are used, for example, the lock-step behavior of LAPB makes HDLC encapsulation the better choice.
LAPB Configuration Task List
Perform the tasks in the following sections to configure LAPB:
•
•
•
•
•
To monitor and maintain LAPB, see the "Monitoring and Maintaining LAPB and X.25" section later in this chapter.
For an example of configuring LAPB operation, see the "Typical LAPB Configuration Example" and "Transparent Bridging for Multiprotocol LAPB Encapsulation Example" sections later in this chapter.
Configuring a LAPB Datagram Transport
To set the appropriate LAPB encapsulation to run datagrams over a serial interface, use the following command in global configuration mode. One end of the link must be a DTE device, and the other must be DCE. Because the default serial encapsulation is HDLC, you must explicitly configure a LAPB encapsulation method. You should shut down the interface before changing the encapsulation.
To select an encapsulation and protocol (if using a single protocol), or to select the multiple protocol operation, use one or more of the following commands in interface configuration mode:
encapsulation lapb dce [protocol]1
Enables encapsulation of a single protocol on the line using DCE operation.
encapsulation lapb dte [protocol]1
Enables encapsulation of a single protocol on the line using DTE operation.
encapsulation lapb dce multi
Enables use of multiple protocols on the line using DCE operation.
encapsulation lapb dte multi2
Enable use of multiple protocols on the line using DTE operation.
1 Single protocol LAPB defaults to IP encapsulation.
2 Multiprotocol LAPB does not support source-route bridging or TCP/IP header compression, but does support transparent bridging. A multiprotocol LAPB encapsulation supports all of the protocols available to a single-protocol LAPB encapsulation plus transparent bridging.
For an example of configuring LAPB operation, see the "Typical LAPB Configuration Example" section later in this chapter.
Configuring Compression of LAPB Data
You can configure point-to-point software compression on serial interfaces that use a LAPB or multi-LAPB encapsulation. Compression reduces the size of a LAPB or multi-LAPB frame via lossless data compression. Compression is performed in the software and can substantially affect system performance. You should disable compression if the router CPU load exceeds 65 percent. To display the CPU load, use the show process cpu command.
Predictor compression is recommended when the bottleneck is caused by the load on the router or access server. Stacker compression is recommended when the bottleneck is the result of line bandwidth. Compression is not recommended if the majority of your traffic is already compressed files. Compression is also not recommended for line speeds greater than T1. The added processing time slows performance on fast lines.
To configure compression over LAPB, use the following commands in interface configuration mode:
Step 1
encapsulation lapb [protocol]
Enables encapsulation of a single protocol on the serial line.
Step 2
compress [predictor | stac]
Enables compression.
To configure compression over multi-LAPB, use the following commands in interface configuration mode:
Step 1
encapsulation lapb multi
Enables encapsulation of multiple protocols on the serial line.
Step 2
compress [predictor | stac]
Enables compression.
When using compression, adjust the maximum transmission unit (MTU) for the serial interface and the LAPB N1 parameter as in the following example, to avoid informational diagnostics regarding excessive MTU or N1 sizes:
interface serial 0encapsulation lapbcompress predictormtu 1509lapb n1 12072For information about configuring X.25 TCP/IP header compression and X.25 payload compression, see the "Setting X.25 TCP/IP Header Compression" and "Configuring X.25 Payload Compression" sections later in this chapter.
Modifying LAPB Protocol Parameters
LAPB specifies methods for exchanging data (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 Packet Level Protocol (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 9. Detailed descriptions of each parameter are given after the table.
The following sections provide more information about the LAPB parameters in the above table:
•
•
•
Caution
•
•
For leased-line circuits, the T1 timer setting is critical because the design of LAPB assumes that a frame has been lost if it is not acknowledged within period T1. The timer setting must be large enough to permit a maximum-sized frame to complete one round trip on the link. If the timer setting is too small, the software will poll before the acknowledgment frame can return, which may result in duplicated frames and severe protocol problems. If the timer setting is too large, the software waits longer than necessary before requesting an acknowledgment, slowing throughput.
•
•
For an example of configuring the LAPB T1 timer, see the "Typical LAPB Configuration Example" section later in this chapter.
Configuring Priority and Custom Queueing for LAPB
LAPB uses priority and custom queueing, which improves the responsiveness of a link to a given type of traffic by specifying the handling of that type of traffic for transmission on the link.
Priority queueing is a mechanism that classifies packets based on certain criteria and then assigns packets to one of four output queues, with high, medium, normal, or low priority.
Custom queueing similarly classifies packets, assigns them to one of ten output queues, and controls the percentage of the available bandwidth of an interface that is used for a queue.
For example, you can use priority queueing to ensure that all Telnet traffic is processed promptly and that Simple Mail Transfer Protocol (SMTP) traffic is sent only when there is no other traffic to send. Priority queueing in this example can starve the non-Telnet traffic; custom queueing can be used instead to ensure that some traffic of all categories is sent.
Both priority and custom queueing can be defined, but only one can be assigned to a given interface. To configure priority and custom queueing for LAPB, perform these tasks in the following order:
1.
2.
3.
Note
Configuring Transparent Bridging over Multiprotocol LAPB
To configure transparent bridging over multiprotocol LAPB, use the following commands beginning in global configuration mode:
Note
For an example of configuring transparent bridging over multiprotocol LAPB, see the "Transparent Bridging for Multiprotocol LAPB Encapsulation Example" section later in this chapter.
X.25 Configuration Task List
To configure X.25, complete the tasks in the following sections. The interface, datagram transport, and routing tasks are divided into sections based on how common the feature is and how often it is used. Those features and parameters that are less common are found in the "Additional" sections. LAPB frame parameters can be modified to optimize X.25 operation, as described earlier in this chapter. All 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. Cisco also provides additional configuration settings to optimize your X.25 usage.
Note
For examples of configuring X.25, see the "X.25 and LAPB Configuration Examples" section later in this chapter.
Configuring an X.25 Interface
The following tasks describe essential parameters for correct X.25 behavior. To configure an X.25 interface, perform the tasks in the following sections. The first task is required, the others might be required or optional, depending on what the router is expected to do with the X.25 attachment.
•
•
•
•
•
•
•
•
You can also configure less common parameters as specified in the "Configuring Additional X.25 Interface Parameters" section.
Configuring X.25 Encapsulation
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 Internet Engineering Task Force (IETF) standard encapsulation, as specified by RFC 1356.
Because the default serial encapsulation is HDLC, you must explicitly configure an X.25 encapsulation method.
Note
To configure the mode of operation and encapsulation type for a specified interface, use the following command in interface configuration mode:
encapsulation x25 [dte | dce] [[ddn | bfe] | [ietf]]
Sets the X.25 mode of operation.
Typically a public data network (PDN) will require attachment as a DTE device. (This requirement is distinct from the hardware interface DTE or DCE identity.) The default mode is DTE, and the default encapsulation method is the Cisco 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 "Typical X.25 Configuration Example" section later in this chapter.
Setting the Virtual Circuit Ranges
X.25 maintains multiple connections—virtual circuits (VCs) or logical circuits (LCs)—over one physical link between a DTE and a DCE device. X.25 can maintain up to 4095 VCs. A VC is identified by its logical channel identifier (LCI) or virtual circuit number (VCN).
Note
An important part of X.25 operation is the range of VC numbers. These numbers are broken into the following four ranges:
1.
2.
3.
4.
The incoming-only, two-way, and outgoing-only ranges define the VC numbers over which a switched virtual circuit (SVC) can be established by the placement of 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:
•
•
•
Note
There is no difference in the operation of SVCs in the different ranges except the restrictions on which device can initiate a call. These ranges can be used to prevent one side from monopolizing the VCs, which is important for X.25 interfaces with a small number of SVCs available. Six X.25 parameters define the upper and lower limit of each of the three SVC ranges. These ranges cannot overlap. A PVC must be assigned a number lower than those assigned to the SVC ranges.
Note
To configure X.25 VC ranges, use the following commands in interface configuration mode:
Each of these parameters can range from 1 to 4095. The values for these parameters must be the same on both ends of the X.25 link. For connection to a 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, VC 0 is not available. For an example of configuring VC ranges, see the "VC Ranges Example" section later in this chapter.
Setting the Packet Numbering Modulo
The Cisco implementation of X.25 supports modulo 8 (default) and modulo 128 packet sequence numbering.
To set the packet numbering modulo, use the following command in interface configuration mode:
Note
The X.25 modulo and the LAPB modulo are distinct and serve different purposes. LAPB modulo 128 (or extended mode) can be used to achieve higher throughput across the DTE or DCE interface, which affects only the local point of attachment. X.25 PLP modulo 128 can be used to achieve higher end-to-end throughput for VCs by allowing more data packets to be in transit across the X.25 network.
Setting the X.121 Address
If your router does not originate or terminate calls but only participates in X.25 switching, this task is optional. However, if your 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, use the following command in interface configuration mode:
For an example of configuring the X.25 interface address, see the "Typical X.25 Configuration Example" section later in this chapter.
Configuring X.25 Switch Local Acknowledgment
X.25 switch local acknowledgment allows you the choice of configuring local or end-to-end acknowledgment on your router. Until now, end-to-end acknowledgment was the only option, resulting in lower overall throughput and restrictive performance because an endpoint could only have a maximum number of its packets in transit at any given time. End-to-end acknowledgment could not send more packets until all had been acknowledged by the transmission and receipt of the delivery-confirming packet containing the D-bit.
Local acknowledgment means that the Cisco router can send acknowledgments for packets that do not have the D-bit set, before receiving an acknowledgment from the interface to which the packet was forwarded. This results in higher throughput of packets because acknowledgment is sent between local hops much faster and more efficiently than between end-to-end hops.
Figure 31 shows the Cisco router receiving packets from DTE A destined for DTE B. Without local acknowledgment enabled, the router forwards packets to the X.25 network and then forwards acknowledgments from the network back to DTE A. With local acknowledgment enabled, the router can acknowledge packets received from DTE A before it has received acknowledgments from the network for the forwarded packets. In this illustration, the X.25 network may also generate local acknowledgments.
Figure 31 Local Acknowledgment Between DTE A and DTE B
To configure local acknowledgment, enable the following command beginning in global configuration mode:
Router(config)# x25 routing acknowledge local
Enables X.25 switching with local acknowledgment.
For an example of configuring local acknowledgment, see the "Configuring Local Acknowledgment Example" section later in this chapter, and for verification see the "Verifying Local Acknowledgment" section, next.
Verifying Local Acknowledgment
To verify local acknowledgment is configured on your router, use the show running-configuration command in EXEC mode. In the following example, X.25 encapsulation has been set on serial interface 1/4 with acknowledgment set to "local":
Router# show running-configurationx25 routing acknowledge localYou can also use the show protocol command in EXEC mode to verify local acknowledgment:
Router# show protocolGlobal values:Internet Protocol routing is enabledX.25 routing is enabled, acknowledgements have local significance onlyEnabling Flow Control Parameter Negotiation
Flow control is an X.25 optional user facility. When the new x25 subscribe flow-control command is used, it permits flow control parameter negotiation of packet sizes and window sizes. This command can be altered to one of three states: default behavior (no x25 subscribe flow-control), facilities always included, or facilities never included (flow control parameter negotiation is not enabled). By default, these flow control parameter negotiation facilities are included in call setup (outgoing) packets only when their values differ from the default values.
When flow control parameter negotiation is enabled, the two new X.25 commands—x25 subscribe windowsize and x25 subscribe packetsize—allow you to configure flow control restrictions by specifying window size and packet size ranges for permitted and target values. A value that cannot be negotiated into the permitted range is treated as illegal, causing the call to fail. The router first attempts values within the target range, but allows values outside the target range to be considered as long as the range complies with procedures defined in the ITU-T Recommendation X.25. With this feature, the Cisco router allows different flow control value configurations and acceptable window and packet size formats for both DTE devices.
The ability to disable flow control parameter negotiation provides compatibility with equipment that does not support flow control parameter negotiation. Similarly, forcing flow control parameter negotiation provides compatibility with devices that require the flow control parameter negotiation facilities to be present in all calls.
To control packet transmission flow values on the interface, use one or more of the flow control commands—x25 subscribe flow-control, x25 subscribe windowsize, or x25 subscribe packetsize—in interface configuration mode.
The flow control subscription commands may be applied to an X.25 interface, to an X.25 profile, or to a LAN interface on which the cmns enable command has been configured. For X.25 over TCP (XOT), the flow control parameter negotiation facilities are always included (the equivalent of x25 subscribe flow-control always).
For an example of setting flow control parameter negotiation, see the sections "Setting Asymmetrical Window and Packet Sizes Flow Control Never Example" and "Configuring Flow Control Always Example" later in this chapter, and for verification see the following section, "Verifying Flow Control Parameter Negotiation."
Verifying Flow Control Parameter Negotiation
To verify flow control parameter settings, use the show running-configuration command in EXEC mode. In the following example, X.25 encapsulation has been set on serial interface 1/4 with flow control negotiation set to "always." Permitted packet sizes are set at 64 (minimum) and 1024 (maximum), with target packet sizes set at 128 (minimum) and 1024 (maximum). Permitted window sizes are set at 1 (minimum) and 7 (maximum), with target window sizes set at 2 (minimum) and 4 (maximum).
Router# show running-configurationx25 subscribe flow-control alwaysx25 subscribe packetsize permit 64 1024 target 128 1024x25 subscribe windowsize permit 1 7 target 2 4Setting Default Flow Control Values
Setting correct default flow control parameters of 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 (2 packets incoming and outgoing).
Note
Setting Default Window Sizes
X.25 networks have a default input and output window size (the default is 2) that is defined by your network administrator. You must set the Cisco IOS software default input and output window sizes to match those of the network. These defaults are the values that an SVC takes on if it is set up without explicitly negotiating its window sizes. Any PVC also uses these default values unless different values are configured.
To set the default window sizes, use the following commands in interface configuration mode:
Step 1
x25 win packets
Sets input maximum window size.
Step 2
x25 wout packets
Sets output maximum window size.
For an example of setting the default window sizes, see the "Typical X.25 Configuration Example" and "DDN X.25 Configuration Example" sections later in this chapter.
Setting Default Packet Sizes
X.25 networks have a default maximum input and output packet size (the default is 128) that is defined by your network administrator. You must set the Cisco IOS software default input and output maximum packet sizes to match those of the network. These defaults are the values that an SVC takes on if it is set up without explicitly negotiating its maximum packet sizes. Any PVC also uses these default values unless different values are configured.
To set the default input and output maximum packet sizes, use the following commands in interface configuration mode:
Step 1
x25 ips bytes
Sets input maximum packet size.
Step 2
x25 ops bytes
Sets output maximum packet size.
To send a packet larger than the agreed-on X.25 packet size over an X.25 VC, the Cisco IOS software 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-on sizes can be carried. The Cisco IOS software 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.
Enabling Asymmetrical Flow Control
Asymmetrical flow control is now supported by the permitted configuration of asymmetrical window and packet sizes. For data flow from a channel with a smaller packet size than its outbound channel, the switch may combine data packets, and for a channel with a larger packet size than its outbound channel, the switch will fragment the packets.
Figure 32 shows asymmetrical configuration of the Cisco router. DTE A (window size 3; packet size 128) and DTE B (window size 5; packet size 256) are able to communicate despite differing window and packet sizes.
Figure 32 Asymmetrical Window and Packet Sizes Between DTE A and DTE B
To use asymmetrical flow control effectively, use the x25 subscribe flow-control never command to disable flow control parameter negotiation, and use the x25 routing acknowledge local command to enable local acknowledgment.
For an example of enabling asymmetrical flow control, see the "Setting Asymmetrical Window and Packet Sizes Flow Control Never Example" later in this chapter.
Configuring Additional X.25 Interface Parameters
Some X.25 applications have less common or special needs. Several X.25 parameters are available to modify X.25 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:
•
•
Configuring the X.25 Level 3 Timers
The X.25 Level 3 event timers determine how long the Cisco IOS software waits 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 event timers, use any of the following commands in interface configuration mode:
For an example of setting the event timers, see the "DDN X.25 Configuration Example" section later in this chapter.
Configuring X.25 Addresses
When you establish SVCs, X.25 uses addresses 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.
The X.121 address of an X.25 interface 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 address of the interface.
Cisco IOS X.25 software 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 VC. An X.25 VC, 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 acts as 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 acts as the destination host for an incoming PAD call with a destination that is a subaddress of the address of the interface; the trailing digits specify which line a PAD connection is requesting. This feature is described in the "Configuring Protocol Translation and Virtual Asynchronous Devices" chapter in the Cisco IOS Dial Services Configuration Guide: Terminal Services. 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 destination host of the call.
To configure X.25 addresses, perform the tasks in the following sections:
•
•
•
Configuring an Interface Alias Address
You can supply alias X.121 addresses for an interface. Supplying alias addresses allows the interface to act as the destination host for calls having a destination address that is neither the address of the interface, an allowed subaddress of the interface, nor the null address.
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, use the following command in interface configuration mode:
x25 alias x121-address-pattern [cud pattern]
Enables an alias X.121 address for the interface.
Suppressing or Replacing the Calling Address
Some attachments require that no calling (source) address be presented in outgoing calls. This requirement is called suppressing the calling address. When attached to a PDN, X.25 may need to ensure that outgoing calls only use the assigned X.121 address for the calling (source) address. Routed X.25 normally uses the original source address. Although individual X.25 route configurations can modify the source address, Cisco provides a simple command to force the use of the interface address in all calls sent; this requirement is called replacing the calling address.
To suppress or replace the calling address, use the appropriate command in interface configuration mode:
x25 suppress-calling-address
Suppresses the calling (source) X.121 address in outgoing calls.
x25 use-source-address
Replaces the calling (source) X.121 address in switched calls.
Suppressing the Called Address
Some attachments require that no called (destination) address be presented in outgoing calls; this requirement is called suppressing the called address.
To suppress the called address, use the following command in interface configuration mode:
x25 suppress-called-address
Suppresses the called (destination) X.121 address in outgoing calls.
Establishing a Default VC Protocol
The Call Request packet that sets up a VC can encode a field called the Call User Data (CUD) field. Typically the first few bytes of the CUD field identify which high-level protocol is carried by the VC. The router, when acting as a destination host, normally refuses a call if the CUD is absent or the protocol identification is not recognized. The PAD protocol, however, specifies that unidentified calls be treated as PAD connection requests. Other applications require that they be treated as IP encapsulation connection requests, per RFC 877.
To configure either PAD or IP encapsulation treatment of unidentified calls, use the following command in interface configuration mode:
Disabling PLP Restarts
By default, a PLP restart is performed when the link level resets (for example, when LAPB reconnects). Although PLP restarts can be disabled for those few networks that do not allow restarts, We do not recommend disabling these restarts because doing so can cause anomalous packet layer behavior.
Caution
To disable PLP restarts, use the following command in interface configuration mode:
Configuring an X.25 Datagram Transport
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 communicating across an X.25 network. You configure datagram transport by establishing a mapping on the encapsulating interface between the protocol address of the far host (for example, IP or DECnet) and its X.121 address. Because the call identifies the protocol that the VC will carry (by encoding a Protocol Identifier, or PID, in the first few bytes of the CUD field), the terminating host can accept the call if it is configured to exchange the identified traffic with the source host.
Figure 33 illustrates two routers sending datagrams across an X.25 PDN.
Figure 33 Transporting LAN Protocols Across an X.25 PDN
To complete the X.25 configuration for your network needs, perform the tasks in the following sections:
•
•
•
•
Configuring the X.25 parameters and special features, including payload compression and X.25 user facilities, is described in the "Configuring Additional X.25 Datagram Transport Features" section later in this chapter.
Configuring Point-to-Point and Multipoint Subinterfaces
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 Cisco 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 you to connect routers by separate physical interfaces, Cisco provides subinterfaces that are treated as separate interfaces. You can separate hosts into subinterfaces on a physical interface, X.25 is unaffected, and routing processes recognize 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 the x25 map or x25 pvc commands) for a given protocol, so there can be only one destination for the protocol. (However, you can use multiple encapsulation commands, one for each protocol, or multiple protocols for one map or PVC.) All protocol traffic routed to a point-to-point subinterface is forwarded to the one destination host defined for the protocol. (Because only one destination is defined for the interface, the routing process need not 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 destination address of the datagram to a configured encapsulation command. If the routing process cannot find a map for the datagram destination address, the encapsulation will fail.
Note
To configure subinterfaces on your X.25 network, perform the tasks in section "Creating and Configuring X.25 Subinterfaces" below.
Creating and Configuring X.25 Subinterfaces
To create and configure a subinterface, use the first command and one or both of the second commands beginning in global configuration mode:
