cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
340
Views
0
Helpful
2
Replies

x.25 connection to FEP not working with ISDN

a.mountouris
Level 1
Level 1

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?

2 Replies 2

ssoberlik
Level 4
Level 4

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.

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.

Getting Started

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: