cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
677
Views
0
Helpful
5
Replies

Persistent Dial-Attempts on backup link - OSPF ?

ajenks
Level 1
Level 1

I have a number of remote sites connected to a core router via leased line, with ISDN backup.

This is the ISDN i/f on remote router REMOTE_A :

interface BRI0/0/0

description Backup ISDN Link

bandwidth 64

ip address 192.168.101.5 255.255.255.0

ip access-group NoVoice out

encapsulation ppp

ip ospf authentication message-digest

ip ospf authentication-key

ip ospf demand-circuit

dialer map ip 192.168.101.1 name CORE broadcast [destination_number]

dialer hold-queue 100

dialer-group 1

ipx network 400

isdn switch-type basic-net3

isdn point-to-point-setup

no fair-queue

no cdp enable

ppp authentication chap

ppp chap hostname REMOTE_A

!

This is defined as a backup to the leased line circuit.

It is my understanding that in event on leased line failiure, "REMOTE_A" will call "CORE" and the connection will only be established in this direction.

On the "CORE" however, I am getting persistent dialer failiures :

1519942: May 30 11:30:34.730 BST: Di0 DDR: ip (s=192.168.101.1, d=224.0.0.5), 11

6 bytes, outgoing interesting (list 101)

1519943: May 30 11:30:34.730 BST: Di0 DDR: sending broadcast to ip 192.168.101.2

1519944: May 30 11:30:34.730 BST: Se1/0:15 DDR: rotor dialout [best] least recen

t failure is also most recent failure

1519945: May 30 11:30:34.730 BST: Se1/0:15 DDR: rotor dialout [best] also has mo

st recent failure

1519946: May 30 11:30:34.730 BST: Se1/0:15 DDR: rotor dialout [best]

1519947: May 30 11:30:34.730 BST: Se1/0:15 DDR: place call

1519948: May 30 11:30:34.730 BST: Se1/0:15 DDR: Dialing cause ip (s=192.168.101.

1, d=224.0.0.5)

1519949: May 30 11:30:34.730 BST: Se1/0:15 DDR: Attempting to dial [destination_number] -

- failed, not connected

Now, I believe the call (from "CORE" is failing as the "REMOTE_A" has the ISDN BRI interface in backup mode so will not answer the call. My question is 1) Why is CORE attempting to place the call ? and 2) What is this traffic ? - I think it might be OSPF related.

The CORE router has a ISDN i/f config as follows :

interface Dialer0

bandwidth 64

ip address 192.168.101.1 255.255.255.0

...

ip ospf demand-circuit

...

dialer map ip 192.168.101.2 name REMOTE_A broadcast [destination_number]

Is this config necessary if the connection is only to be established from REMOTE_A -> CORE ?

All I want to achieve is that traffic (including OSPF updates etc.) are sent across ISDN but only when WAN link has failed. The network has gone through numerous changes and I'm not sure the config on the "CORE" is now relevant.

ISDN backup does currently work in event of leased line failiure (from REMOTE_A -> CORE) - the issues is the 1000's of failed dial attempts from CORE per day.

Any help would be greatly appreciated.

5 Replies 5

Richard Burts
Hall of Fame
Hall of Fame

Alastair

With a destination address of 224.0.05 according to the dialer debug that you posted it is most certainly related to OSPF. I notice that you have both sides configured with ospf demand-circuit (and I believe that demand-circuit is a good feature). One aspect of demand circuit is that once the OSPF neighbor relationship is established over the dialer connection the routers do not send hello messages (which would keep the circuit active). They do need to use the dialer when there has been a change in the OSPF topology data base and the router needs to send LSAs to its neighbors. My guess is that the dial activity is related to OSPF routing changes on the core.

It is a little unclear in your description how the primary link at the remote identifies the ISDN as a backup. But I am guessing that the primary uses the backup-interface command. In my experience trying to combine demand-circuit and backup-interface is frequently problematic. I would suggest that you use one or the other. If you are going to use demand-circuit then set the cost of the ISDN high enough that the router will prefer the primary link (the cost should usually be high enough by default) and recognize that the circuit will become active when there are genuine routing updates. (It is usually good practive to put interfaces with deman circuit into OSPF areas where there will not be a high degree of routing updates - putting the demand circuit into area 0 means that you will probably see the ISDN circuit active quite often)

HTH

Rick

HTH

Rick

Rick, thanks for your reply.

Yes, you are right, on REMOTE_A, the primary link has the backup-interface command referencing the dialer interface. However, on CORE the dialer interface is not referenced as a backup-interface. I believe at one point a number of these sites connected over ISDN ONLY (not as a backup method) so I believe some config on CORE may be left from this.

I have done some debugging on OSPF and as far as I could make out, there where no changes outstanding (but this doesn't rule this out completely).

I was thinking about this some more last night, and there is one thing I want to try and get cleared up (please excuse my ignorance in this area), why is CORE even trying to make a call, routing updates or not ? - If REMOTE_A initiates a dial-up connection in event of primary link failiure, surely it would not be a good idea to have CORE trying to initiate a dialup connection at the same time (with REMOTE_A only having BRI, the incoming/outgoing calls could conflict/busy the channels). Also, with the dialer interface being configured as a backup-interface on REMOTE_A, it couldn't answer an incoming call anyway, could it ?

I know that these failed dial attempts are not due to link failiure, but my point is, CORE should not try and initiate a dial-up connection, period.

Can I set CORE to recieve calls only and never try to initiate a call itself, or am I taking a too simplistic view of things ?

the demand circuit will need to make one successful call before going into 'quiet' mode

as the remote end is in backup and the call fails then ospf will keep attemptin the call.

http://www.cisco.com/warp/public/104/dc.html

You can set the CORE to receive calls only by removing the dialer map statement.

Alastair

I would suggest that you run "debug ip ospf spf" for a bit (remember terminal monitor if you are telnetted to the router). This will show if there are OSPF updates being done. See if there is a relationship between the attempts of CORE to dial out and running of the SPF. The impact of this debug is quite minimal.

I would also suggest that attempting to prevent CORE from dialing is counter productive to configuring ospf demand-circuit. If the router is configured with demand circuit it needs to be able to send LSAs to its neighbor over the dial circuit. To do that it needs to be able to initiate a call. So if you remove the ability to dial out from CORE then I suggest that you remove the demand circuit from both routers.

I do not know much about your network but I would guess that implementing ospf demand-circuit on CORE may be a sub-optimal design. Assuming that CORE is the middle of your network it is likely to be in area 0 and to experience a relatively high amount of routing change activity. It is generally recommended to configure demand circuit on routers in areas that are relatively low rate of routing update. I also believe that it is sub-optimal design to try to combine demand circuit with backup interface.

So I would suggest that you might want to re-think the design of this aspect of your network.

As a last thought: if you want to configure CORE to receive calls only and not to initiate calls, do not take the easy and obvious way and remove the dialer-group or dialer list from the configuration. If you do this you will find that calls are terminated when the idle timer expires (by default that is 2 minutes). The better way to make CORE receive only is to remove the dial number from the dialer map (or the dialer profile whichever way the router is configured).

HTH

Rick

HTH

Rick
Review Cisco Networking products for a $25 gift card