ISDN and pstn backup

Hey,

I was approached by a client who need to set up isdn access with a regular phone dialup backup. I know it sounds weird but it's the way the client wants it due to budget retrainst and also because in the area's he wants it there are no other services available....
He is gettting cisco 3640 with a nm4bst and nm-8as and a whole bunch of 1720 ....
the problem i got while writing the configs is that if the isdn goes down, the pots does take over yet once the isdn is reestablished, the pots still stays up ....
i got a tac opened on priority 2 for 3 weeks and they still ahve no clue...
would anyone have any ideas ?

here are a couple of things i tried:
-1 dialer pool with both isdn and pots tied to it so that there would be one route only
has the results described above ...
-2 dialer pools with 2 routes:
*2 routes of different metrics does'nt work since it won't switch over, even when using priorities ...
*2 routes of equal metrics: splits the packets on both routes ... that was predictable yet i had to try it... if you assign priorities, there won't be any switch over yet it will only use one route...
-dynamic routing: rip &ospf i know it's pointless over ddr and one/two routes yet it doesn't work (that is the only thing the tac was certain)

so if you have any suggestions let me know !!!
thanks

I have never heard of this specific problem, but I can tell you it is kind of odd to be backing up an ISDN dialer group with another dialer, even if it is POTS. Usually, the dialer backups are used to back up dedicated circuits. Here is how it works (in case others are wondering):

Backup dialer monitors the main circuit for an outage. Then the dialer will automatically take over for the downed circuit. The problem in your scenario could be that ISDN is not an "always on" connection. Therefore, when not in use, the circuit shuts down. Just like POTS. It is possible that this may be causing some confusion with your router, because it doesn't know exactly what to do and when.

I don't know the answer however, so please keep me informed if you do find a solution; I would be interested to hear ;)

~iNViCTuS

From my experiences this won't work or it won't work reliably... At least not with a Cisco router.

You should look into an "always on" technology like satellite.

I haven't seen it done either. Let us know if you figure it out.

Sorry for the late feedback...
the automatic backup function isn't an option in the bri/seri interface thus can't be used...
they do want to have the isdn connection on ddr so that is why it's not always on....
their main problem is that they are REALLY concerned with prices... yet they still wants cisco's routers....
so far no solutions yet,but i'll post the confs as soons as i get it to work (either me or the tac)

I am not so sure this is a Cisco issue to begin with. I think it is more of a technology issue. there is probably a better way to do this anyway at a better cost. I don't know where they are located, but have you looked into the option of a fractional t-1/e-1 or maybe even a DSL. My experience has been that people have gone with ISDN because it is not always on and they think it will save $$. But it ends up that they pay more because you are paying usage charges.

Plus if they are so concerned about the price of an Internet connection must not feel it is important to the business, so why the hell do they care if they have a backup in case it goes down in the first place.

well actually the dial up is not for internet, plus the t1 would not be practical cuz that service is not available where they have the central...

they plan on time delaying the connections so that they get the lowest rates at night too...
i know they sound crazy but they are the client/paying decent money so whatever...if they want **** they'll get it ....

Well...all you can to is do (or try to do) what they ask for...so that works for me. Still keep us informed if u find a solution

here is the latest from the tac:
Thanks for your further test input. This time the debugs clearly show
the drawback of the DDR solution: when the local and/or remote BRI are
disconnected, DDR will still use the BRI for all outgoing calls because
it has the highest priority within the dialer pool.

IOS behaves this way because the Dialer interface is configured for
'dialer rotor priority' by default. Only when the outbound interface
with the highest priority in the pool or rotary-group is shutdown or
completely used, outgoing calls will be initiated on the outbound
interface with the 2nd highest priority (i.e. the Serial in your
case).

The alternative is to configure 'dialer rotor best'. IOS will now
select the outbound interface with the most recent success. If that
interface also has the most recent failure, then it will try the
interface with the least recent failure. This would be no solution
for you either, because IOS would continue using the Serial once it
has switched from BRI to Serial. Or would your customer agree to
switch off the remote async modem as long as backup is not needed?


so basically the dude is giving up.... what is the point of having a router if you have to manually turn off the remote async modem .... not practical

This was my first case with the tac and probably the last one; they spent some 20 days on it to get that answer while the results has in no way improved whatsoever....
Thanks for the interest !

Well...let me tell you now that Cisco TAC is probably the best tech support in the world. the problem here is that you are trying to do something that technology doesn't support. This is not necessarily Cisco's fault. The reason it probably took so long to get the answer is that is was rated as a priority 4. This means that you network is currently operational, but there is something you would like to do to improve it.

I have had many calls to TAC and they are always very responsive. Especially when it is a P1 or P2 case. Like we said originally, you might just have to come up with a different solution, this one won't work.

Thanks for the update though...much appreciated

actually, the feedback from the tac is still open, they are suggesting a sys~wich (ios enhencement)...
true that the tech doesn't support is but it the hardware is there, i don't see i reason why youcan't use it as you want .... (but i do agree that what i'm trying to implement is dumb ... customer's always right ...)

If you assign the higher prority to the ISDN and unplug it (from what I read above it does switch over) then plug it back in does it sucsesfully come back or are you still getting the issue?

still get the same issue, with or without the priority and the dialer rotary best doesn't solve the problem either ....

but the dail up is supposed to come up when the isdn goes down?
and the ISDN is supposed to come up when it is availabe,

thats really wierd because the router should stop using the dail up when the isdn comes back up because of the priority,

dont mind me I am not the brightest in the world, but this is intresting and I want to help never set up ISDN with a dial up back up before,
I can ask some of my other CCNA buddies and see what they can think of.

the other guy here cant think of any thing
sorry
good luck

YEp it is possible !!! i tried the suggestions form the tac even if they said it wouldn't work and well it did it!!! well the rip with floating static is not working out but the rotary dialer is working out 'fine' ....
after a isdn failure, the async int take over the dialer profile and establishes a connection after the second try ( the first number dilaed is the isdn # of the other router wich fails automatically....) when the isdn is back on, the dialer switches back to isdn by itself since isdn has priority over any other connection( by default and hardcodded ....) the interval for the switcover is quiet long 1.5 mins but i don't want to fool with at commands to save 10 secs ...

Anyways thanks for your help/suggestions


here is the config do not hesitate in contacting me if you have any more questions:
Current configuration : 1930 bytes
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname office
!
aaa new-model
aaa authentication login default local
aaa authentication login NO_AUTHEN none
aaa authentication ppp default local
enable secret 5 $1$SSMd$RzXwmXaFE8.kYpijR0x1T0
!
username central password 0 cisco
username admin password 0 cisco
!
!
!
!
memory-size iomem 25
ip subnet-zero
no ip domain-lookup
ip host lap 192.168.1.151
ip host modem 2002 192.168.1.1
ip host central 192.168.1.0
!
isdn switch-type basic-net3
!
!
!
interface Loopback1
ip address 1.1.1.2 255.255.255.0
!
interface Serial0
no ip address
shutdown
no cdp enable
!
interface Serial1
physical-layer async
no ip address
encapsulation ppp
dialer in-band
dialer pool-member 1
async mode interactive
no peer default ip address
no fair-queue
no cdp enable
ppp authentication chap callin
!
interface BRI0
no ip address
encapsulation ppp
no ip route-cache
dialer pool-member 1
isdn switch-type basic-net3
no cdp enable
!
interface FastEthernet0
ip address 192.168.2.1 255.255.255.0
speed auto
no cdp enable
!
interface Dialer1
ip address 10.10.10.20 255.255.255.0
encapsulation ppp
dialer pool 1
dialer remote-name central
dialer rotor best
dialer idle-timeout 45
dialer fast-idle 1
dialer string AAAAAAAA
dialer string BBBBBBBB
dialer-group 1
pulse-time 0
no cdp enable
ppp authentication chap
ppp multilink
!
ip classless
ip route 192.168.1.0 255.255.255.0 10.10.10.21
ip route 192.168.1.151 255.255.255.255 FastEthernet0
no ip http server
!
dialer-list 1 protocol ip permit
no cdp run
!
line con 0
line 2
modem InOut
modem autoconfigure type usr_sportster
transport input all
autoselect ppp
speed 115200
flowcontrol hardware
line aux 0
line vty 0 4
password cisco
!
end

Hmmm...very interesting, but now at least we know it will work. That is not an issue you come across every day, but it sure is interesting to know.

Thanks for the hard work in figuring this out and keeping us updated..and also, thanks for the sample config, it is going straight to my library..

I'm snagging that to mine as well. Thks nabylbt.