10-10-2005 03:53 AM
Hello forum,
we came accross a problem where the ISDN back up of a x.25 connection is not establishing svcs, whereas the serial interface does.
The network topology is as follows:
(FEP)-x.25-(ciscoB)-x25-(ciscoA)-x.25-(client)
+-ISDN back up to ciscoB --+
So, client is attached to ciscoA and through ciscoB it finds the FEP. However, the ISDN back up is attached directly on ciscoB.
The configurations is as follows:
Interface on ciscoB where FEP is:
interface Serial1/0
description ** Connection to FEP
bandwidth 256
no ip address
encapsulation x25 dce
x25 ltc 17
x25 htc 80
x25 t10 180
x25 t11 200
x25 t12 180
x25 t13 180
x25 ips 256
x25 ops 256
x25 facility packetsize 1024 1024
x25 subscribe packetsize permit 64 1024
x25 subscribe windowsize permit 2 7
x25 pvc 3 interface Serial3/7 pvc 1
serial restart-delay 0
clockrate 252000
bridge-group 10
end
Serial interface of the ciscoA where client is attached:
interface Serial2/0:2
description ** Connection to EMPORIKH_SALONIKA (64K-15582)
no ip address
encapsulation x25 dce
x25 htc 16
x25 ips 256
x25 ops 256
x25 facility packetsize 1024 1024
bridge-group 10
ISDN configuration on ciscoB:
controller E1 2/1
pri-group timeslots 1-31
interface Serial2/1:15
bandwidth 64
no ip address
encapsulation x25 dce
dialer pool-member 1
isdn switch-type primary-net5
!
interface Dialer5
description ** EGNATIA ISDN **
no ip address
encapsulation x25 dce
dialer pool 1
dialer caller 2310805841
dialer max-call 1
x25 htc 16
x25 ips 256
x25 ops 256
x25 facility packetsize 1024 1024
x25 subscribe packetsize permit 64 1024
bridge-group 10
!
So, when serial is up, everything is ok.
When w etry the isdn backup, although we see that the isdn call is ok, we get an x25 error on debug x25 events, with cause 3 and diag 65 (facility code not allowed).
What is the meaning of this cause and diag? Looking at cisco reference it doesn't say much, in which cases this combination appears more often? Could this be a routing problem?
Why this is not present at the case where the serial is up?
10-14-2005 11:03 AM
Swap out the cables being used, from PRI-1 to PRI-2 and see if the problem stays with PRI-2. If the problem moves to the first PRI, then this is a cabling issue.
10-17-2005 03:54 AM
Ok,
problem solved. The problem was that at the other end, at the isdn port they have defined a parameter INL (motorola specific) and this resulted in motorola sent a "C8" facility that cisco did not recognize. At their serial they did not have this parameter, that is why the serial always worked fine.
Removing this paramter solved the problem.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: