Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

isdn link: how prove to telco that we're fine

i have two 2610s that have been connecting via BRIs for months . A couple of weeks ago something changed. One channel will stay up but the other will disconect after several hundred seconds. Sometimes it will re-connect but usually it stays down unless i bring it down and let it start over.

here is the config for Hilltop, which calls Whitlock (it's Centrex so it's 4 digit dialing):

interface BRI0/0

bandwidth 64

ip address 10.254.251.5 255.255.255.0

encapsulation ppp

no ip mroute-cache

load-interval 30

keepalive 1000

dialer idle-timeout 86400

dialer map ip 10.254.251.18 name PA_WHITLOCK broadcast 2073

dialer map ip 10.254.251.18 name PA_WHITLOCK broadcast 2072

dialer load-threshold 1 either

dialer-group 1

isdn switch-type basic-ni

isdn spid1 61025120700101

isdn spid2 61025120710101

peer default ip address pool USERS

no cdp enable

ppp authentication chap

ppp multilink

here is the config for Hilltop and an isdn activity:

Whitlock BRI0/0

bandwidth 64

ip address 10.254.251.18 255.255.255.0

encapsulation ppp

no ip mroute-cache

load-interval 30

keepalive 1000

dialer idle-timeout 86400

dialer map ip 10.254.251.5 name PA_HILLTOP broadcast 2070

dialer map ip 10.254.251.5 name PA_HILLTOP broadcast 2071

dialer load-threshold 1 either

dialer-group 1

ipx network 252002

isdn switch-type basic-ni

isdn spid1 61025120720101 2512072

isdn spid2 61025120730101 2512073

peer default ip address pool USERS

no cdp enable

ppp authentication chap

ppp multilink

PA_WHITLOCK#sh isdn act

--------------------------------------------------------------------------------

ISDN ACTIVE CALLS

--------------------------------------------------------------------------------

Call Calling Called Remote Seconds Seconds Seconds Charges

Type Number Number Name Used Left Idle Units/Currency

--------------------------------------------------------------------------------

In 6102512070 2512073 PA_HILLTOP +54484 - -

--------------------------------------------------------------------------------

here is debug dialer on Hilltop:

Sep 2 09:53:09.363: BR0/0 DDR: Attempting to dial 2073

Sep 2 09:53:09.587: BRI0/0: wait for isdn carrier timeout, call id=0xE4F7

Sep 2 09:53:09.587: BR0/0 DDR: Already 1 call(s) in progress on BR0/0, dialing not allowed

here is debug ppp pack on Hilltop:

PPP packet display debugging is on

PA_HILLTOP#

Sep 2 09:58:51.832: Vi1 PPP: O pkt type 0x0021, datagramsize 64

Sep 2 09:58:53.482: BR0/0:1 PPP: I pkt type 0x0021, datagramsize 536

Sep 2 09:58:53.482: BR0/0:1 IP: Non-NCP packet, discarding

Sep 2 09:58:53.482: Vi1 PPP: I pkt type 0x0021, datagramsize 536

Sep 2 09:58:53.482: Vi1 PPP: I pkt type 0x0021, datagramsize 536

Sep 2 09:58:53.551: BR0/0:1 PPP: I pkt type 0x0021, datagramsize 536

Sep 2 09:58:53.551: BR0/0:1 IP: Non-NCP packet, discarding

here is debug isdn q931 on Hilltop;

debug isdn q931

ISDN Q931 packets debugging is on

PA_HILLTOP#

Sep 2 09:55:09.567: ISDN BR0/0: TX -> SETUP pd = 8 callref = 0x24

Sep 2 09:55:09.567: Bearer Capability i = 0x8890

Sep 2 09:55:09.567: Channel ID i = 0x83

Sep 2 09:55:09.571: Keypad Facility i = '2073'

Sep 2 09:55:09.743: ISDN BR0/0: RX <- CALL_PROC pd = 8 callref = 0xA4

Sep 2 09:55:09.747: Channel ID i = 0x8A

Sep 2 09:55:09.747: Locking Shift to Codeset 5

Sep 2 09:55:09.751: Codeset 5 IE 0x2A i = 0x80830A, '6102512073', 0x80010A800114800114800114

Sep 2 09:55:09.779: ISDN BR0/0: RX <- DISCONNECT pd = 8 callref = 0xA4

Sep 2 09:55:09.783: Cause i = 0x8291 - User busy

Sep 2 09:55:09.783: Signal i = 0x04 - Busy tone on

Sep 2 09:55:09.791: ISDN BR0/0: TX -> RELEASE pd = 8 callref = 0x24

Sep 2 09:55:09.875: ISDN BR0/0: RX <- RELEASE_COMP pd = 8 callref = 0xA4

Sep 2 09:55:09.879: Signal i = 0x3F - Tones off

Sep 2 09:55:39.617: ISDN BR0/0: TX -> SETUP pd = 8 callref = 0x25

Sep 2 09:55:39.617: Bearer Capability i = 0x8890

Sep 2 09:55:39.617: Channel ID i = 0x83

Sep 2 09:55:39.621: Keypad Facility i = '2073'

Sep 2 09:55:39.793: ISDN BR0/0: RX <- CALL_PROC pd = 8 callref = 0xA5

Sep 2 09:55:39.797: Channel ID i = 0x8A

Sep 2 09:55:39.797: Locking Shift to Codeset 5

Sep 2 09:55:39.797: Codeset 5 IE 0x2A i = 0x80830A, '6102512073', 0x80010A800114800114800114

Sep 2 09:55:39.829: ISDN BR0/0: RX <- DISCONNECT pd = 8 callref = 0xA5

Sep 2 09:55:39.833: Cause i = 0x8291 - User busy

Sep 2 09:55:39.833: Signal i = 0x04 - Busy tone on

Sep 2 09:55:39.841: ISDN BR0/0: TX -> RELEASE pd = 8 callref = 0x25

Sep 2 09:55:39.925: ISDN BR0/0: RX <- RELEASE_COMP pd = 8 callref = 0xA5

Sep 2 09:55:39.929: Signal i = 0x3F - Tones off

Sep 2 09:56:09.667: ISDN BR0/0: TX -> SETUP pd = 8 callref = 0x26

Sep 2 09:56:09.667: Bearer Capability i = 0x8890

Sep 2 09:56:09.667: Channel ID i = 0x83

Sep 2 09:56:09.671: Keypad Facility i = '2073'

Sep 2 09:56:09.843: ISDN BR0/0: RX <- CALL_PROC pd = 8 callref = 0xA6

Sep 2 09:56:09.847: Channel ID i = 0x8A

Sep 2 09:56:09.847: Locking Shift to Codeset 5

Sep 2 09:56:09.847: Codeset 5 IE 0x2A i = 0x80830A, '6102512073', 0x80010A800114800114800114

Sep 2 09:56:09.879: ISDN BR0/0: RX <- DISCONNECT pd = 8 callref = 0xA6

Sep 2 09:56:09.883: Cause i = 0x8291 - User busy

Sep 2 09:56:09.883: Signal i = 0x04 - Busy tone on

Sep 2 09:56:09.891: ISDN BR0/0: TX -> RELEASE pd = 8 callref = 0x26

Sep 2 09:56:09.975: ISDN BR0/0: RX <- RELEASE_COMP pd = 8 callref = 0xA6

Sep 2 0

The telco did find a bad extension but then tested the circuits at both locations and says everything is fine. I didn't change anything so it's gotta be them.

2 REPLIES
Bronze

Re: isdn link: how prove to telco that we're fine

These debugs don't seem relevent to the issue of dropping the call. They show the call failing with a busy signal.

On that note, you have both ends configured to dial. Are you sure nothing has changed so that the host is calling at the same time as the remote? Its my understanding that having the two dialer map statements should make it roll over to the other line when it gets a busy but I dont see that in your debugs. Maybe they dont go long enough.

You could try swapping the dialer maps so the 1st channel on one end calls the second on the other end to avoid the deadly embrace. Or figure out why the host end might be calling.

If you prove to yourself that the host is not calling then try calling the number with your phone and see if it is really busy while you are looking at the host end a making sure it is not active.

You need debugs of the drop to figure out why its dropping.

Bronze

Re: isdn link: how prove to telco that we're fine

You mentioned that the connection was working fine and then this started happening. When it started happening did the routers get reloaded at all, or did you just shut down the BRI's or some thing to get them to work again ? Can you provide the following from both routers while the problem is happening.

debug isdn q931

debug isdn event

debug dialer

sh isdn active

sh isdn stat

Daniel

254
Views
0
Helpful
2
Replies
CreatePlease to create content