Isdn Backup - Bouncing

[kaoslife]

We have 2821's at our primary and remote location. I've configured it that when the primary wan fails, It will use ISDN to restore the connection. Once the ISDN connection is active, It will see the connection, disconnect the ISDN call and start the whole process over. I feel it's something simple, but My mind is blank right now. Can some one help me and point me in the right direction.

Snipped Config:

Int Tunnel0

ip address 10.8.8.1 255.255.255.0

backup interface Dialer0

tunnel source gi0/0

tunnel destination 10.168.150.140

Interface Loopback 10.10.10.3 255.255.255.0

int gi0/0

desc LAN

int gi0/1

Desc WAN

int bri1/0

desc ISDN BACKUP

no ip address

encap ppp

load-interval 30

dialer pool-member 1

int dialer0

ip address 10.9.9.1 255.255.255.0

encap ppp

dialer pool 1

dialer-group 1

router ospf 999

log-adj-changes

network 10.8.8.0 0.0.0.0.255 area 0

network 10.9.9.0 0.0.0.0.255 area 0

[Richard Burts]

You have snipped the config so severely that there is not a lot to go on. I see that dialer0 has defined dialer-group 1. I do not see dialer list 1 and am not sure if you snipped it or if it is missing. A missing or incorrect dialer list could be one thing that would cause a call to be placed, be disconnected, and be placed again.

I see that you are using the backup interface pointing to the dialer from the tunnel interface. What are you doing to cause the tunnel to go down?

Is this the side that is initiating the call or the side that is answering the call?

If you provide some more information we may be able to provide better help.

HTH

Rick

[kaoslife]

I've attached a less snipped version of each router

To casu ethe tunnel to go down I'm disconnectin a cable in between a couple of routers simulating the WAN. The rpimary side initiates all calls

[Richard Burts]

I appreciate having the complete configs to look at. I do see that both sides do have dialer lists to go with the dialer group so that is not the cause of the behavior. I assume that you are unplugging the Gig0/0 interface to bring the tunnel down. Is that correct?

Is the tunnel interface on the primary router flapping - going down when the interface is unplugged and then coming back up, and going down again? If so this would explain the behavior of the ISDN. The ISDN becomes active when the tunnel is down and ISDN goes inactive when the tunnel comes up.

HTH

Rick

[kaoslife]

To bring the tunnel down, It's actually on interface gi0/1. And yes the tunnel is flapping. How do I go about stopping it

[Richard Burts]

You have a very interesting problem here. In normal circumstance the tunnel exits on the Gig interface and the tunnel being up keeps the ISDN down. When the tunnel fails the ISDN comes up. When the ISDN comes up the tunnel re-establishes over the ISDN. When the tunnel comes up it forces the ISDN down. When the ISDN goes down it brings the tunnel down. When the tunnel goes down it brings up the ISDN... over and over.

I believe that there are several solutions that might work. You might think about putting the backup interface command on the physical interface rather than on the tunnel. I would probably prefer to think about not using backup interface to trigger the ISDN and about using some kind of floating static route to bring up the ISDN.

Or you might want to think about configuring the ISDN as OSPF Demand Circuit and assigning OSPF costs such that the routes through the Gig are preferred to routes learned through ISDN but ISDN is available if the routes through the Gig are removed from the routing table. I think this may be the optimum choice.

HTH

Rick

[kaoslife]

Thanks For the responses. I'm trying the floating static route right now, but any having trouble with OSPF keeping the prefered route the ISDN

[Richard Burts]

I am not clear whether you are saying that OSPF is preferring the route learned via ISDN to the floating static (which I am not sure would really be a problem) or are saying that once OSPF learns a route via ISDN it continues to prefer that route when the physical interface comes back up.

It may help to be sure to assign an OSPF cost on the dialer interface that makes the routes learned that way less attractive.

HTH

Rick

[kaoslife]

The problem I'm having is the OSPF is not being passed over the Gi interfaces

[Richard Burts]

The config of the primary router looks to me to include the interfaces correctly (all into area 0). You can verify this by doing show ip ospf interface.

Is it forming OSPF neighbor relationships on the gig interfaces? (If it is not you might try running debug ip ospf adj)

HTH

Rick