ISDN and pstn backup

[nabylbt]

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

[iNViCTuS]

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

[KorpDeath]

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.

[gold eagle]

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

[nabylbt]

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)

[iNViCTuS]

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.

[nabylbt]

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 ....

[iNViCTuS]

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

[nabylbt]

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 !

[iNViCTuS]

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