cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
471
Views
0
Helpful
8
Replies

AS5300 problem using ISDN

carlos.villegas
Level 1
Level 1

We have an AS5300 configured for POTS and ISDN backup. the as5300 is configured with two PRI's. When I shut down the frame interface on one of my 2610's it should dial out to the as5300 and the isdn should come up. However you never see the ISDN on the 2610 connect to the access server with both PRI's up. When I shut down the second PRI and leave one up the ISDN works fine. I have also called out from the access server to the 2610 with both pri's up and you never see the call connecting. Both Pri's are configured the same. see below:

interface Serial0:23

description S0:23 Verizon ISDN ***REMOVED***

no ip address

encapsulation ppp

dialer rotary-group 0

dialer-group 1

isdn switch-type primary-5ess

isdn incoming-voice modem

no fair-queue

no cdp enable

ppp authentication chap

ppp multilink

!

interface Serial1:23

description s1:23 Verizon secondary ***REMOVED***

no ip address

encapsulation ppp

shutdown

dialer rotary-group 0

dialer-group 1

isdn switch-type primary-5ess

isdn incoming-voice modem

no fair-queue

no cdp enable

ppp authentication chap

ppp multilink

As you can see I have shutdown interface Serial1:23 in order for ISDN to work on the AS5300. Im curios as to what the problem could be. My show ISDN status shows that i have Multiple frame established and my spids are valid. However this second isdn ckt seems to be causing some sort of conflict with the other. Thanks in Advance for any input provided.

-CMV

8 Replies 8

tepatel
Cisco Employee
Cisco Employee

I assume that you be using "backup interface .." command for backup. Command "shutdown" will not activate the back as "shutdown" leaves the primary inteface in "adminisratively down" mode.

In order to test the backup, you need to bring the layer 1 down by removing the cable from the primary interface port OR change the encapsulation type to bing the layer 2 down.

Another thing to make sure that, you need to have interesting traffic defind. Also that interesting traffic will activate the backup line to dialout once the primary line is down. so we need to see the running config for "interface dialer 0" from the PRI router and the relevent config from 2610 router.

If the config is fine, then we need to see the debug for following

debug dialer

debug isdn q931

debug ppp nego

debug ppp auth

term mon

from the router receiving the call and also from the router originating the call.

interface Dialer0

description For ISDN base routers

ip address ***REMOVED***

encapsulation ppp

dialer in-band

dialer idle-timeout 60

dialer map ip ***REMOVED***

dialer map ip ***REMOVED***

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap

ppp chap hostname rwdb1-as5300

ppp chap password ***REMOVED***

Here is the 2610 config:

interface BRI0/0

description BRI ISDN Ckt#

ip address **REMOVED***

encapsulation ppp

dialer idle-timeout 60

dialer string 17326022341

dialer string 19727920229

dialer load-threshold 240 either

dialer-group 1

isdn switch-type basic-ni

isdn spid1 70367156430101 6715643

isdn spid2 70367156440101 6715644

no cdp enable

ppp authentication chap

ppp chap hostname rdca2-0011

ppp chap password ***REMOVED***

ppp multilink

rwdb1-as5300#debug isdn events

ISDN events debugging is on

rwdb1-as5300#term mon

rwdb1-as5300#ping 10.10.240.37

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.240.37, timeout is 2 seconds:

*Feb 3 23:20:48.955 utc: Se1:23 DDR: rotor dialout [priority]

*Feb 3 23:20:48.955 utc: Se1:23 DDR: place call

*Feb 3 23:20:48.955 utc: Se1:23 DDR: Dialing cause ip (s=10.10.240.5, d=10.10.)

*Feb 3 23:20:48.955 utc: Se1:23 DDR: Attempting to dial 17039793574

*Feb 3 23:20:48.955 utc: ISDN Se1:23: Outgoing call id = 0x840A, dsl 1

*Feb 3 23:20:48.955 utc: ISDN Se1:23: Event: Call to 17039793574 at 64 Kb/s

*Feb 3 23:20:48.955 utc: ISDN Se1:23: process_pri_call(): call id 0x840A, numbf

*Feb 3 23:20:48.955 utc: callED type/plan overridden by call_decode

*Feb 3 23:20:48.959 utc: did't copy oct3a reason: not CALLER_NUMBER_IE

*Feb 3 23:20:48.959 utc: building outgoing channel id for call nfas_int is 0 0

*Feb 3 23:20:49.083 utc: ISDN Se1:23: LIF_EVENT: ces/callid 1/0x840A CALL_PROCG

*Feb 3 23:20:49.083 utc: ISDN Se1:23: CALL_PROCEEDING id 0x840A

*Feb 3 23:20:49.083 utc: ISDN Se1:23: PRI Event: 6, bchan = 22, call type = DAA

*Feb 3 23:20:50.191 utc: ISDN Se1:23: LIF_EVENT: ces/callid 1/0x840A CALL_DISC

*Feb 3 23:20:50.191 utc: ISDN Se1:23: process_disc_ack(): call id 0x840A, ces F

*Feb 3 23:20:50.235 utc: ISDN Se1:23: CCPRI_ReleaseCall(): bchan 23, call id 0A

*Feb 3 23:20:50.235 utc: CCPRI_ReleaseChan released b_dsl 1 B_Chan 23

*Feb 3 23:20:50.235 utc: ISDN Se1:23: LIF_EVENT: ces/callid 1/0x840A CALL_CLEAD

*Feb 3 23:20:50.235 utc: ISDN Se1:23: received CALL_CLEARED call_id 0x840A

*Feb 3 23:20:50.235 utc: no resend setup, no redial

*Feb 3 23:20:50.235 utc: no resend setup, no redial.

Success rate is 0 percent (0/5)

rwdb1-as5300#

Also one thing I should mention, the AS5300 always worked fine UNTIL the second pri was put in. I think my config is tight but maybe I have a connectivity issue, regardless the other pri should at least work. The strange part to me is that by shutting down the one pri on the as5300 seems to "fix" the issue.

Here is the debug off the router 2610

5d22h: BR0/0 DDR: Dialing cause ip (s=**REMOVED**, d=**REMOVED**)

5d22h: BR0/0 DDR: Attempting to dial 17326022341

5d22h: ISDN BR0/0: TX -> SETUP pd = 8 callref = 0x1E

5d22h: Bearer Capability i = 0x8890

5d22h: Channel ID i = 0x83

5d22h: Keypad Facility i = '17326022341'

5d22h: ISDN BR0/0: RX <- CALL_PROC pd = 8 callref = 0x9E

5d22h: Channel ID i = 0x89..

5d22h: ISDN BR0/0: RX <- PROGRESS pd = 8 callref = 0x9E

5d22h: Progress Ind i = 0x8A81 - Call not end-to-end ISDN, may have in-

5d22h: Signal i = 0x01 - Ring back tone on

5d22h: ISDN BR0/0: HOST_PROGRESS: Got IE of INBAND or Not End-To-End.

Thank you

-CMV

Its very strange that by shutting down the new PRI line, the calls between 5300 and 2610 works fine for both the direction.

I do not see the CONNECT at the isdn q931 layer so I think the debug you have posted is not if full. We only need to see the debug for following in order to see the clear issue. Enable that on the router receiving the call and originating the call too.

debug dialer

debug ppp nego

debug isdn q931

debug ppp authentication

That way we can verify that the call is originated and forwarded to the terminating router. You can also follow the link below for more isdn troubleshooting

http://www.cisco.com/warp/public/471/isdn_q931_ts.html

Here are the debugs you requested, and again thank you for your help. I removed ips and replaced with the appropriate hostname.

rwdb1-as5300#ping 2610 router

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2610 router, timeout is 2 seconds:

May 20 14:30:49.215 utc: Di0 DDR: No free dialer - starting fast idle timer.

May 20 14:30:51.215 utc: Di0 DDR: No free dialer - starting fast idle timer.

May 20 14:30:53.215 utc: Di0 DDR: No free dialer - starting fast idle timer.

May 20 14:30:55.215 utc: Di0 DDR: No free dialer - starting fast idle timer.

May 20 14:30:57.215 utc: Di0 DDR: No free dialer - starting fast idle timer.

Success rate is 0 percent (0/5)

rwdb1-as5300#sho debug

Dial on demand:

Dial on demand events debugging is on

PPP:

PPP authentication debugging is on

PPP protocol negotiation debugging is on

ISDN:

ISDN Q931 packets debugging is on

ISDN Q931 packets debug DSLs. (On/Off/No DSL:1/0/-)

DSL 0 --> 7

1 1 - - - - - -

I have never seen this message before about the no free dialer. I have nothing on the access server right now.

Here is the one from the 2610. THis is all I get.

rdca2-0011#debug dialer

Dial on demand events debugging is on

rdca2-0011#debug ppp negotiation

PPP protocol negotiation debugging is on

rdca2-0011#debug isdn q931

ISDN Q931 packets debugging is on

rdca2-0011#debug ppp auth

PPP authentication debugging is on

rdca2-0011#term mon

rdca2-0011#ping AS-5300

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to AS-5300 , timeout is 2 seconds:

6d03h: BR0/0 DDR: Dialing cause ip (s=2610router, d=as5300)

6d03h: BR0/0 DDR: Attempting to dial 17326022341

6d03h: ISDN BR0/0: TX -> SETUP pd = 8 callref = 0x20

6d03h: Bearer Capability i = 0x8890

6d03h: Channel ID i = 0x83

6d03h: Keypad Facility i = '17326022341'

6d03h: ISDN BR0/0: RX <- CALL_PROC pd = 8 callref = 0xA0

6d03h: Channel ID i = 0x89...

6d03h: ISDN BR0/0: RX <- PROGRESS pd = 8 callref = 0xA0

6d03h: Progress Ind i = 0x8A81 - Call not end-to-end ISDN, may have in-

6d03h: Signal i = 0x01 - Ring back tone on

6d03h: ISDN BR0/0: HOST_PROGRESS: Got IE of INBAND or Not End-To-End..

Success rate is 0 percent (0/5)

As you can see the call is not getting forward at the isdn layer. So you can talk to local provider about the outgoing call. Also have you seen that the call is even showed up pr received at as5300.

If not, then again something is really wrong with the circuit.

Thanks for all your help again. I really appreciate it. I have called out the PRI giving me trouble to the provider to test. I guess I dont really understand why I would still have layer 2 up on the sh isdn status. I will post telco results. Luckily we have someone from cisco coming here today to discuss eigrp maybe he knows isdn as well :)

-CMV

make sure the line has been provisoned to send and receive calls.

Telco tested good, im back to where I started. I sat there and watched the verizon tech do loops and pattern tests on his t-berd and all passed. Im more convinced than before now that its a config issue on the as-5300. All the trunks on the PRI are working. I think I will just open a tac case with cisco now. Thanks for your help

-CMV