Downloads |
Table Of Contents
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Configuring X.25 Remote Failure Detection with IP Static Routes
Configuring X.25 Remote Failure Detection and the Backup Interface
Verifying X.25 Remote Failure Detection
Configuring X.25 Remote Failure Detection with IP Static Routes
Configuring X.25 Remote Failure Detection and the Backup Interface
X.25 Remote Failure Detection
This document contains the following sections:
•
Supported Standards, MIBs, and RFCs
Feature Overview
Static routes are used over a packet-switched data network (PSDN) in order to reduce the network's volume-based costs. Until now, if two routers were connected via multiple X.25 links (a primary and a secondary), a router could not detect failure of the primary link. If a failure occurred, the data was not transferred to the second link because X.25 was unable to determine whether remote links were up or down. Therefore X.25 could not use an alternate connection to a destination.
X.25 remote failure detection is an important feature for X.25 users because now, after a primary link failure, the router can establish a secondary link and continue sending data. This feature is a way for the router to detect a call failure and to use a secondary route to send subsequent packets to the remote destination, at the same time as making periodic attempts to reconnect to its primary link.
X.25 remote failure detection controls the number of these attempts and the interval between such attempts using the x25 retry command. The down link is marked up again when any of the following occurs:
•
•
•
X.25 remote failure detection needs to be manually configured on each subinterface you intend to use this option. However, because it is a per-destination configuration rather than a per-user configuration, you only need it enabled on the subinterface needing the retry option—typically your primary interface.
If you issue the clear x25 command for the interface configured with X.25 remote failure detection or if a call comes in during retry, the x25 retry command will discontinue and the subinterface will be marked "up." An incoming call can be conducted in a similar way that the ping command is used to check connectivity (by definition, a successful incoming call indicates that connectivity is functioning). Also, if the router reaches its retry attempts limit, the x25 retry command will discontinue and the subinterface will remain down.
The x25 retry command is activated by a call failure notification. Retry only occurs with calls initiated on a subinterface configured with the x25 retry command. This command only works when no VCs are up. When reconnection occurs, traffic begins to reuse the primary interface. This resetting of the line protocol to up is the last activity that the x25 retry command conducts.
X.25 remote failure detection is designed to work with any network layer routed protocol. However, the feature depends on the ability of the protocol to handle more than one static route to the same destination at the same time. Currently, only IP can accomplish this multi-static route handling. Alternatively, X.25 remote failure detection can be used to activate a backup link should the subinterface configured for retry be marked down via the retry mechanism. See the "Configuring X.25 Remote Failure Detection and the Backup Interface" section for further details.
X.25 remote failure detection is not necessary if you are running IP routing, because IP routing already implements alternate routing. This feature is targeted at environments that have static IP routing across an X.25 network, where these static IP routes currently need to be manually added to the route tables.
shows how X.25 remote failure detection works:
1
2
3
Figure 1 X.25 Remote Failure Detection in Action over an X.25 Cloud
Benefits
•
•
•
Restrictions
The X.25 Remote Failure Detection feature has the following restrictions:
•
•
•
•
Related Features and Technologies
Other features that have a relation to X.25 remote failure detection are Asynchronous Serial Traffic over UDP, L2TP Dialout, and Frame Relay End-to-End Keepalive.
Supported Platforms
•
•
•
•
•
•
•
•
•
•
•
Supported Standards, MIBs, and RFCs
MIBs
No new or modified MIBs are supported by this feature.
For descriptions of supported MIBs and how to use MIBs, see the Cisco MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
RFCs
None
Standards
None
Prerequisites
You must have X.25 encapsulation activated for X.25 remote failure detection to function. You must also have IP static routes or a backup link configured for X.25 encapsulation. Details of configuring IP static routes and backup links can be found in the Cisco IOS Release 12.0 Wide-Area Networking Configuration Guide.
Configuration Tasks
To configure X.25 remote failure detection, perform either one of the following tasks:
•
•
Configuring X.25 Remote Failure Detection with IP Static Routes
To configure X.25 remote failure detection with IP static routes, perform the following steps beginning in configuration mode:
Configuring X.25 Remote Failure Detection and the Backup Interface
To configure X.25 remote failure detection and create a backup interface, perform the following steps beginning in configuration mode. Note that IP static routes need not be configured because this backup route is only being configured as a secondary route.
Verifying X.25 Remote Failure Detection
To verify that X.25 remote failure detection is configured, use the show interface command on whichever interface you have configured the x25 retry command. The line indicated with an arrow in the following output shows the X.25 retry mechanism currently in action on subinterface 1.1, which is currently down—as indicated by the "(retry in progress)" statement—and which has "tried" once out of its possible 100 retry attempts.
Router# show interface serial1Serial1 is up, line protocol is upHardware is QUICC SerialMTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,reliability 255/255, txload 1/255, rxload 1/255Encapsulation X25, loopback not setX.25 DTE, address 11111, state R1, modulo 8, timer 0Defaults:idle VC timeout 0cisco encapsulationinput/output window sizes 2/2, packet sizes 128/128Timers:T20 180, T21 200, T22 180, T23 180Channels:Incoming-only none, Two-way 1-1024, Outgoing-only noneRESTARTs 2/0 CALLs 0+0/0+0/0+0 DIAGs 0/0Interface Serial1.1:retry-interval 5, attempts 100, tried 1 (retry in progress)LAPB DTE, state CONNECT, modulo 8, k 7, N1 12056, N2 20T1 3000, T2 0, interface outage (partial T3) 0, T4 0VS 2, VR 0, tx NR 0, Remote VR 2, Retransmissions 0Queues:U/S frames 0, I frames 0, unack. 0, reTx 0IFRAMEs 18/16 RNRs 0/0 REJs 0/0 SABM/Es 0/1 FRMRs 0/0 DISCs 0/0Last input 00:00:11, output 00:00:02, output hang neverLast clearing of "show interface" counters 00:01:03Queueing strategy:fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec34 packets input, 398 bytes, 0 no bufferReceived 0 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort27 packets output, 424 bytes, 0 underruns0 output errors, 0 collisions, 1 interface resets0 output buffer failures, 0 output buffers swapped out1 carrier transitionsDCD=down DSR=up DTR=up RTS=up CTS=upTo verify which route is currently in use by IP, use the show ip route command.
The debug x25 events command can be also activated, so that you can see a call being attempted by the X.25 retry mechanism every configured interval.
Configuration Examples
These configuration examples show the x25 retry command only being used with a secondary route. However, the x25 retry command can be configured for as many subinterfaces that require an alternative route. Use either one of the following examples to configure X.25 remote failure detection:
•
•
Configuring X.25 Remote Failure Detection with IP Static Routes
The following is an example of X.25 remote failure detection being configured on subinterfaces 1.1 and 1.2 using the x25 retry command. Subinterface 1.1 has been set at a retry every 60 seconds up to a maximum of 10 attempts.
Observe the weighting of 100 on subinterface 1.1 over 200 on subinterface 1.2 in the ip route command, because subinterface 1.1 is the primary route and 1.2 is the secondary route—the latter only becomes activated when subinterface 1.1 is unable to function. Weights make for predictable routing events and, therefore, promote the concept of primary and secondary routes.
Router(config)# interface serial1Router(config-if)# encapsulation x25Router(config-if)# x25 address 11111Router(config-if)# no shutRouter(config-if)# exitRouter(config)# interface serial1.1 point-to-pointRouter(config-subif)# ip address 172.30.22.1 255.255.255.0Router(config-subif)# x25 map ip 172.30.22.2 22222Router(config-subif)# x25 retry interval 60 attempts 10Router(config-subif)# no shutRouter(config-subif)# exitRouter(config)# interface serial1.2 point-to-pointRouter(config-subif)# ip address 172.30.22.1 255.255.255.0Router(config-subif)# x25 map ip 172.30.22.4 44444Router(config-subif)# no shutRouter(config-subif)# exitRouter(config)# ip route 172.30.11.1 255.255.255.0 serial1.1 100Router(config)# ip route 172.30.11.1 255.255.255.0 serial1.2 200Configuring X.25 Remote Failure Detection and the Backup Interface
The following is an alternative configuration example to the method previously described. X.25 remote failure detection is configured on subinterface 1.1, and interface 2 is made the backup interface. The x25 retry command has been set with an interval of 50 seconds up to a maximum of 20 attempts. In this example, there is no need to configure any IP static routes (as is done with the above configuration) because the backup interface is functioning as the secondary route. In other situations, there may be a need for static IP routes depending on how the backup interface is configured.
For more details about backup, see the backup interface serial command in the "Interface Commands" chapter in the Cisco IOS Release 12.0 Configuration Fundamentals Command Reference publication.
Router(config)# interface serial1Router(config-if)# encapsulation x25Router(config-if)# x25 address 11111Router(config-if)# no shutRouter(config-if)# exitRouter(config)# interface serial1.1 point-to-pointRouter(config-subif)# ip address 172.30.22.1 255.255.255.0Router(config-subif)# x25 map ip 172.30.22.2 22222Router(config-subif)# x25 retry interval 50 attempts 20Router(config-subif)# backup interface serial2Router(config-subif)# no shutRouter(config-subif)# exitRouter(config)# interface serial2Router(config-if)# encapsulation x25Router(config-if)# x25 address 11111Router(config-if)# ip address 172.30.22.1 255.255.255.0Router(config-if)# x25 map ip 172.30.22.3 33333Router(config-if)# no shutRouter(config-if)# exitCommand Reference
This section documents the new x25 retry command. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command references.
x25 retry
To implement secondary X.25 routing while also retrying failed primary X.25 routes, use the x25 retry interface configuration command. To discontinue implementing secondary X.25 routes and retrying of primary X.25 routes, use the no form of this command.
x25 retry interval seconds attempts count
no x25 retry interval seconds attempts count
Syntax Description
Defaults
No default behavior or values.
Command Modes
Interface configuration
Command History
Usage Guidelines
The x25 retry command is triggered when no SVCs are up, and an outgoing call fails.
The retry attempts will continue until any of the following happens:
•
•
•
•
If the number of retry attempts exceeds the configured limit, the interface will remain marked "down" until any of the following happens:
•
•
Examples
The following example shows the x25 retry command being configured on subinterface 1.1 with a retry interval of 60 seconds up to a maximum of 10 attempts:
Router(config)# interface serial1.1 point-to-pointRouter(config-if)# x25 retry interval 60 attempts 10Related Commands
clear x25
Restarts an X.25 service or Connection-Mode Network Service (CMNS), or clears an SVC or PVC.
Glossary
CMNS—Connection-Mode Network Service. Extends local X.25 switching to a variety of media (Ethernet, FDDI, Token Ring).
PSDN—packet-switched data network.
