Problem with an ISDN backup line

[Kevin Melton]

I am working at a client site today.  The client has tasked me with being able to resolve an ISDN backup issue.  They have a hub and spoke Frame Relay network which consists of a hub router and effectively 15 spokes, which are branch offices.

The ISDN component is configured on each of the spoke routers as backup in case the frame fails.  There is a separate ISDN router at the cleint office (same place as the Frame Hub) that will receive the call (or it may initiate it, I am not sure).

When examined, all but one of the spoke routers shows its ISDN BRI interface as UP.  see below.

COOP-Choptank#sho ip int brief
Interface                  IP-Address        OK?       Method Status                Protocol
Ethernet0/0              10.10.20.2        YES         NVRAM  up                    up 
Serial0/0                  unassigned       YES         NVRAM  up                    up 
Serial0/0.1                192.168.10.6    YES         NVRAM  up                    up 
Serial0/0.360             192.168.9.6     YES        NVRAM  up                    up 
BRI0/0                     unassigned      YES          NVRAM  up                    up 
BRI0/0:1                   unassigned      YES         unset  down                  down
BRI0/0:2                   unassigned      YES         unset  down                  down
Dialer1                    192.168.250.18  YES        NVRAM  up                    up 
Loopback0              192.168.250.105 YES        NVRAM  up                     up

I have the following debugs running:

VAPOWER#sho debug
Dial on demand:
  Dial on demand events debugging is on
  Dial on demand packets 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/-)

And here is the output when I use the "isdn test call interface BRI0/0 XXXXXXXXXXX" command:

Jan  6 09:45:08.015: BR0/0 DDR: Attempting to dial 18047471259
Jan  6 09:45:08.031: ISDN BR0/0: TX -> SETUP pd = 8  callref = 0x03
Jan  6 09:45:08.031:         Bearer Capability i = 0x8890
Jan  6 09:45:08.031:         Channel ID i = 0x83
Jan  6 09:45:08.035:         Keypad Facility i = '18047471259'
VAPOWER#
Jan  6 09:45:08.761: ISDN BR0/0: RX <- RELEASE_COMP pd = 8  callref = 0x83
Jan  6 09:45:08.761:         Cause i = 0x82D8 - Incompatible destination
Jan  6 09:45:08.765:         Signal i = 0x03 - Network congestion tone on

I am curious about the incompatable destination portion of the message.  I looked this up online, and it tells me that this means

1. This usually means that the Number To Dial in the Connection Profile is in the wrong format. You may need to dial a 10 or 11 digit number, or dial a 9 in front of the number if it is a Centrex line.
2. This problem may also give a Cause 111.
3. Dialing at the wrong line speed can also give this Cause.

This is all very strange.  I have concurred with the client that this ISDN backup has worked before.

Any and all help on this will be greatly appreciated.

Thank You

Kevin

[Richard Burts]

Kevin

Given what we know so far it would seem somewhat likely that the format of the number in your test command was not what the router was expecting. As a place to start it might be helpful to know how the router at the spoke site is configured. In particular it might help to know if the spoke site is supposed to initiate a call how it is configured (what in the configuration has the called number) and how the called number is identified in the configuration. Does your test format match up to the format used in the configuration?

HTH

Rick

[Kevin Melton]

Thanks for the response Rick.

I am thinking I may have initiated the dial test from the remote end by mistake.  I and the customer thinks that the hub router is to dial the remote side when it knows that the frame is down...

I think I had set up the call correctly, but maybe just from the wrong end.  The format I used was:

isdn test call interface BRI0/0 18047471259 (this is the number from the config on the remote end).

I am going to cut and paste the relevant pieces of each config:

Remote router:

interface Dialer1
ip address 192.168.250.26 255.255.255.252
ip authentication mode eigrp 13 md5
ip authentication key-chain eigrp 13 secure-eigrp
encapsulation ppp
ip route-cache flow
dialer pool 1
dialer remote-name ODEC3640-ISDN
dialer idle-timeout 86400
dialer string 18047471259
dialer-group 1
ppp authentication chap

Hub Router

interface Dialer7
description To Va Pwr 804-935-0671
bandwidth 48
ip address 192.168.250.25 255.255.255.252
ip access-group ODEC-OUTBOUND out
ip authentication mode eigrp 13 md5
ip authentication key-chain eigrp 13 secure-eigrp
encapsulation ppp
ip route-cache flow
delay 50
dialer pool 1
dialer remote-name VAPOWER
dialer idle-timeout 300
dialer string 9350671
dialer watch-group 7
dialer-group 1
fair-queue 64 256 0
ppp authentication chap dialbackup
ppp authorization dialbackup

Please let me know if you need anyting else from me.  I appreciate your expertise with this!

Kevin

[Richard Burts]

Kevin

The dialer watch-group configured on the hub router is one way of initiating calls (when routes that are specified in the watch-group are no longer in the routing table then initiate a call). So it supports the assumption that the hub is dialing the remote.

That does not yet tell us whether the remote is also configured to initiate a call to the hub. There are several ways that a router might be configured to initiate a call. Some of them include backup-interface, floating static route, dialer watch among the possibilities. Can you look through the configuration of the remote and see if there is any mechanism to initiate the call?

Or perhaps it is not worth much effort to investigate the remote and you just want to conclude that the test needs to be initiated from the hub.

I find it interesting that the description found on the hub router has an area code of 804 but the dialer string configured does not include the area code.

HTH

Rick

[Kevin Melton]

After looking at the Hub configuration as well as the spoke router configuration on the remote end, I see the dialer watch groups

as you have described Rick on the Hub.  I do have a question about this:

interface Dialer7
description To Va Pwr 804-935-0671
bandwidth 48
ip address 192.168.250.25 255.255.255.252
ip access-group ODEC-OUTBOUND out
ip authentication mode eigrp 13 md5
ip authentication key-chain eigrp 13 secure-eigrp
encapsulation ppp
ip route-cache flow
delay 50
dialer pool 1
dialer remote-name VAPOWER
dialer idle-timeout 300
dialer string 9350671
dialer watch-group 7
dialer-group 1
fair-queue 64 256 0
ppp authentication chap dialbackup
ppp authorization dialbackup

What does the 7 indicate.  I thought this would be linked to an ACL but there is not ACL 7 in the configuration.  I am not sure what the dialer watch group is watching...

On the remote end, there is no dialer watch group configured.  At this point, can we safely assume that the Hub needs to dial?  I would think that would be the case.

I think the reason that the Dialer Interface does not contain the area code is because that connection is very close by - literally a mile up the road or so.  All the other Dialer interfaces on the Hub router do have an area code, i think since they are long distance.

I will go ahead and initiate a test dial from the Hub and see if it will work.  I will let you know.

Thanks Rick

Kevin

[Richard Burts · Accepted solution]

Kevin

It would be logical if the 7 in dialer watch-group 7 pointed to an access list 7 (which is what I thought when I first looked at it). But when I look at the config guide for how to configure dialer watch I find that it should point to a dialer watch-list 7 (which is coded very much like a standard access list to permit an address and mask). Is there a dialer watch-list 7 in the hub config?

At this point I believe that we are pretty safe in assuming that it should work when the hub initiates the call. We do not yet know enough about the remote to say that it can not initiate the dialing. I am guessing that this is the case, but do not have enough information about the remote to be sure of that.

HTH

Rick

[Kevin Melton]

Rick

we did find the dialer watch list in the configuration on the hub.  Here is a snippet which does show the corresponding dialer watch 7:

dialer watch-list 100 ip 192.168.250.110 255.255.255.255
dialer watch-list 106 ip 192.168.250.106 255.255.255.255
dialer watch-list 101 ip 192.168.250.101 255.255.255.255
dialer watch-list 16 ip 192.168.250.116 255.255.255.255
dialer watch-list 8 ip 192.168.250.108 255.255.255.255
dialer watch-list 13 ip 192.168.250.113 255.255.255.255
dialer watch-list 12 ip 192.168.250.112 255.255.255.255
dialer watch-list 11 ip 192.168.250.111 255.255.255.255
dialer watch-list 10 ip 192.168.250.110 255.255.255.255
dialer watch-list 9 ip 192.168.250.109 255.255.255.255
dialer watch-list 7 ip 192.168.250.107 255.255.255.255
dialer watch-list 5 ip 192.168.250.105 255.255.255.255
dialer watch-list 4 ip 192.168.250.104 255.255.255.255
dialer watch-list 2 ip 192.168.250.102 255.255.255.255
dialer watch-list 3 ip 192.168.250.103 255.255.255.255
dialer watch-list 14 ip 192.168.250.114 255.255.255.255
dialer watch-list 15 ip 192.168.250.115 255.255.255.255
dialer watch-list 17 ip 192.168.250.166 255.255.255.255

I am not so sure that there is a problem anymore.  I received the following debug output once I turned on the debug dialer and debug dialer packet:

Jan 11 11:17:37.070: %ISDN-6-CONNECT: Interface Serial1/0:22 is now connected to 9350671
Jan 11 11:17:37.126: %LINK-3-UPDOWN: Interface Serial1/0:22, changed state to down
Jan 11 11:17:37.126: Se1/0:22 DDR: disconnecting call
Jan 11 11:17:37.194: DDR: Dialer Watch: watch-group = 106
Jan 11 11:17:37.194: DDR:         network 192.168.250.106/255.255.255.255 UP,
Jan 11 11:17:37.194: DDR:         primary UP
Jan 11 11:17:37.194: DDR: Dialer Watch: watch-group = 16
Jan 11 11:17:37.198: DDR:         network 192.168.250.116/255.255.255.255 UP,
Jan 11 11:17:37.198: DDR:         primary UP
Jan 11 11:17:37.198: DDR: Dialer Watch: watch-group = 8
Jan 11 11:17:37.198: DDR:         network 192.168.250.108/255.255.255.255 UP,
Jan 11 11:17:37.198: DDR:         primary UP
Jan 11 11:17:37.198: DDR: Dialer Watch: watch-group = 12
Jan 11 11:17:37.198: DDR:         network 192.168.250.112/255.255.255.255 UP,
Jan 11 11:17:37.198: DDR:         primary UP
Jan 11 11:17:37.198: DDR: Dialer Watch: watch-group = 11
Jan 11 11:17:37.198: DDR:         network 192.168.250.111/255.255.255.255 UP,
Jan 11 11:17:37.198: DDR:         primary UP
Jan 11 11:17:37.198: DDR: Dialer Watch: watch-group = 10
Jan 11 11:17:37.198: DDR:         network 192.168.250.110/255.255.255.255 UP,
Jan 11 11:17:37.198: DDR:         primary UP
Jan 11 11:17:37.198: DDR: Dialer Watch: watch-group = 9
Jan 11 11:17:37.198: DDR:         network 192.168.250.109/255.255.255.255 UP,
Jan 11 11:17:37.202: DDR:         primary UP
Jan 11 11:17:37.202: DDR: Dialer Watch: watch-group = 7
Jan 11 11:17:37.202: DDR:         network 192.168.250.107/255.255.255.255 UP,
Jan 11 11:17:37.202: DDR:         primary UP
Jan 11 11:17:37.202: DDR: Dialer Watch: watch-group = 5
Jan 11 11:17:37.202: DDR:         network 192.168.250.105/255.255.255.255 UP,
Jan 11 11:17:37.202: DDR:         primary UP
Jan 11 11:17:37.202: DDR: Dialer Watch: watch-group = 4
Jan 11 11:17:37.202: DDR:         network 192.168.250.104/255.255.255.255 UP,
Jan 11 11:17:37.202: DDR:         primary UP
Jan 11 11:17:37.202: DDR: Dialer Watch: watch-group = 2
Jan 11 11:17:37.202: DDR:         network 192.168.250.102/255.255.255.255 UP,
Jan 11 11:17:37.202: DDR:         primary UP
Jan 11 11:17:37.202: DDR: Dialer Watch: watch-group = 3
ODEC3640-ISDN#
Jan 11 11:17:37.202: DDR:         network 192.168.250.103/255.255.255.255 UP,
Jan 11 11:17:37.202: DDR:         primary UP
Jan 11 11:17:37.202: DDR: Dialer Watch: watch-group = 14
Jan 11 11:17:37.206: DDR:         network 192.168.250.114/255.255.255.255 UP,
Jan 11 11:17:37.206: DDR:         primary UP
Jan 11 11:17:37.206: DDR: Dialer Watch: watch-group = 15
Jan 11 11:17:37.206: DDR:         network 192.168.250.115/255.255.255.255 UP,
Jan 11 11:17:37.206: DDR:         primary UP
Jan 11 11:17:37.206: DDR: Dialer Watch: watch-group = 17
Jan 11 11:17:37.206: DDR:         network 192.168.250.166/255.255.255.255 UP,
Jan 11 11:17:37.206: DDR:         primary UP

I also found it interesting that these dialer watch group messages popped up after the dial completed and then disconnected...

Thanks Rick

[Richard Burts]

Kevin

I am glad that we have a better understanding of the issue and that you have it working. If you do not believe that there is a problem any more then I am happy to believe that there is no problem. Thanks for marking the issue as answered (and thanks for the points). It makes the forum more useful when people can read about an issue and can know that they will find a solution for that issue. Your marking this issue helps readers to know that a solution was found.

HTH

Rick

[maikal55]

Fascinating it is to how it has helped me even after 13 years!! Kudos to the internet and thanks to the one who provided the solution. I had this client from Reliable washing machine  and we were stuck for more than 3 months in this issue, I KNOW!!!! THREE MONTHS LONG TORTURE! but alas finally it is solved thanks to this post in cisco community which brought peace to my loins!