MADMAN wrote: > > FWIW I have implemented more ISDN backup than I care to > remember but > once configured and tested it works well. I always suggest that > customers periodically test the backup, at least force tha ISDN > connection up by pinging a test loopback or something. I had > one > customer who did't want to loose their SNA sessions, via DLSW, > and ISDN > backup with EIGRP converted fast enough that the SNA session > stayed > active. > > Dave > JMcL: Yep, been there, done that too (with OSPF though). With RSRB as well, before we moved to DLSW (now TN3270...) Despite quite a few Cisco people telling us that SNA was far too sensitive... And I agree about the need to periodically test the failover. Especially since ETSI (Euro-ISDN, Basic-net3, call it what you will) appears to "go to sleep" when not used, so "show isdn status" indicates that the circuit's completely dead... until you need it again (anyone else noticed this?) > > > "Vicuna, Mark" wrote: > > > > Where I work ISDN is primarily used for DDR since it is the > most cost > > effective soln in Aust - especially if you have a large > number of sites > > to cover as Jenny pointed out. With that in mind, the way of > thinking > > being 'we only want to pay for what we use'. There's no > point in having > > an fr circuit as backup for each remote/branch site. > > > > Of course with our main core trunk links into the telco cloud > we > > wouldn't consider ISDN for backup. > > > > The majority of issues regarding ISDN I have had experience > over here > > are with provider's equipement (we have subscription to every > major > > telco in aust. and only one telco [no names mentioned] seems > to give us > > ongoing grief with their dated equipment - lucent att - > framed route > > issues with ldap), and of course dialer watch :) The current > > configuration we have would fail bringing up the isdn circuit > > sporadically on a watched subnet. Resolution? changed dialer > watch > > group to any other number BUT 1. Go figure. > > > > In regards to manual intervention.. i hope not :-) I have > worked for > > the 2 major telco's in Aust and there's no manual > intervention happening > > there in context of servicing their customers. > > > > MV > > > > -----Original Message----- > > From: Jenny McLeod [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, 24 September 2002 9:21 AM > > To: [EMAIL PROTECTED] > > Subject: RE: OT - ISDN viability - WAS: Re: VPDN - ISDN > problem > > [7:53931] > > > > Hell yeah. > > We use ISDN to automatically failover. With over 350 remote > sites, it's > > not > > uncommon to have a main link to an office fail somewhere. > > With automatic failover, our users often don't even know > something's > > failed. Manual intervention? You've got to be kidding. To > tweak and > > tune > > if necessary, sure, but to initiate failover - no way. Been > there, done > > that, bad idea in our network. > > Anyway, in Australia at least, it's still the most > cost-effective > > failover > > for a network like ours (lots of sites, geographically > dispersed). > > It has some annoyances, sure - but it's still definitely an > option for > > me. > > > > JMcL > > > > Chuck's Long Road wrote: > > > > > > I see more complaints / problems / issues with ISDN and DDR > in > > > specific and > > > in general, in real world and in test situations. > > > > > > Idle curiousity. Is ISDN really viable in terms of > reliability > > > for DDR > > > applications? > > > > > > In any number of mission critical applications, I have seen > > > major vendors, > > > major enterprises, and major service providers use manual > > > intervention as > > > the preferred means to apply dial backup. > > > > > > I welcome the informed comments of those who are obviously > more > > > versed in > > > the topic than I am, with my limited exposure.. > > > > > > Chuck > > > > > > [snipped] > -- > David Madland > CCIE# 2016 > Sr. Network Engineer > Qwest Communications > 612-664-3367 > > "You don't make the poor richer by making the rich poorer." > --Winston > Churchill > >
Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=54200&t=54007 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
