«

Morning all,

I am trying to configure an 1841 router to give ADSL access to an ISP
with an ISDN backup in case the ADSL fails. I have just about got it
working using the backup interface command on the ATM interface. The
problem is that when simulating an ADSL failure by pulling the cable,
the BRI interface comes up and the dialer connects but the ADSL dialer
stays up which leaves the route out via the ADSL dialer in the routing
table so no traffic can get out. Any one got any ideas?

When you pull out ADSL cable is your dialer goes down in a couple of
minutes? I tried this on 851W router and dialer goes down in a few
minutes... If this period matches the period that you see under 'idle timer'
variable in the 'show dialer' output, then try to reduce this value to
something more comfortable to you...

B.R.
Igor




"Guyster" <> wrote in message
news: oups.com...
> Morning all,
>
> I am trying to configure an 1841 router to give ADSL access to an ISP
> with an ISDN backup in case the ADSL fails. I have just about got it
> working using the backup interface command on the ATM interface. The
> problem is that when simulating an ADSL failure by pulling the cable,
> the BRI interface comes up and the dialer connects but the ADSL dialer
> stays up which leaves the route out via the ADSL dialer in the routing
> table so no traffic can get out. Any one got any ideas?
>

I tried that - I had it set at 10 seconds for testing but the dialer
was staying up, could this be because the default route was still in
the routing table and inbound traffic was still being sent that way so
the router doensnt think the dialer is idle? From the info I found on
setting this up I got the impression that when the backup ISDN
interface comes up the ATM should go down and take the dialer with it,
is it possible to force this?.

hm...strange thing... I never used before ATM interface for connecting to
ADSL. I usually use PPPoE client on my Cisco routers and after provider
disconnects those every 24h, dialer also comes down and up (it bounds to
the virtual-profile actually).

Can I see how you defined your default route?

Also, I have another option for you: PBR with tracking option (it may not
apply to your topology)
(http://www.cisco.com/en/US/products/...80457bcc.html).
This will send IP SLA probes (icmp echo requests) to some Internet host that
you define in it. When IP SLA probe fails (you don't get ICMP echo reply),
your router will use next route-map 'set ip next-hop' statement (you will
define it to use) to send packets to the Internet. Unfortunately, this only
works if you are able to specifie next-hop ip address. I'm afraid that in
your case you have to specifie one of your dialer interfaces ...

But send me your default route first...

B.R.
Igor


"Guyster" <> wrote in message
news: oups.com...
>I tried that - I had it set at 10 seconds for testing but the dialer
> was staying up, could this be because the default route was still in
> the routing table and inbound traffic was still being sent that way so
> the router doensnt think the dialer is idle? From the info I found on
> setting this up I got the impression that when the backup ISDN
> interface comes up the ATM should go down and take the dialer with it,
> is it possible to force this?.
>

Hi, thanks for your help, here are the highlights of the config,
including the default route - I dont have a next hop address or routing
protocol so it looks like the only option I have is the backup
interface command
Cheers
Guy

clock timezone . 0
clock summer-time BST recurring last Sun Mar 1:00 last Sun Oct 2:00
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
ip subnet-zero
!
ip name-server 62.241.162.200
isdn switch-type basic-net3
!
interface FastEthernet0/1
ip address *.*.*.* 255.255.255.248
duplex auto
speed auto
!
interface ATM0/0/0
no ip address
backup interface BRI0/1/0
no atm ilmi-keepalive
dsl operating-mode auto
pvc 0/38
encapsulation aal5mux ppp dialer
dialer pool-member 2
!
!
interface BRI0/1/0
no ip address
encapsulation ppp
dialer pool-member 1
isdn switch-type basic-net3
no keepalive
!
interface Dialer0
ip address negotiated
encapsulation ppp
dialer pool 1
dialer string 08450795056
dialer-group 1
ppp chap hostname *
ppp chap password *
!
interface Dialer2
ip address negotiated
encapsulation ppp
dialer pool 2
dialer idle-timeout 10
dialer-group 2
no cdp enable
ppp chap hostname *
ppp chap password *
!
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer2
ip route 0.0.0.0 0.0.0.0 Dialer0 80

Try with this:

interface Dialer2
no dialer-group 2

This should eliminate interesting traffic issue, that is, maybe there is
always some interesting traffic that keeps this dialer up...

B.R.
Igor


"Guyster" <> wrote in message
news: oups.com...
> Hi, thanks for your help, here are the highlights of the config,
> including the default route - I dont have a next hop address or routing
> protocol so it looks like the only option I have is the backup
> interface command
> Cheers
> Guy
>
> clock timezone . 0
> clock summer-time BST recurring last Sun Mar 1:00 last Sun Oct 2:00
> mmi polling-interval 60
> no mmi auto-configure
> no mmi pvc
> mmi snmp-timeout 180
> ip subnet-zero
> !
> ip name-server 62.241.162.200
> isdn switch-type basic-net3
> !
> interface FastEthernet0/1
> ip address *.*.*.* 255.255.255.248
> duplex auto
> speed auto
> !
> interface ATM0/0/0
> no ip address
> backup interface BRI0/1/0
> no atm ilmi-keepalive
> dsl operating-mode auto
> pvc 0/38
> encapsulation aal5mux ppp dialer
> dialer pool-member 2
> !
> !
> interface BRI0/1/0
> no ip address
> encapsulation ppp
> dialer pool-member 1
> isdn switch-type basic-net3
> no keepalive
> !
> interface Dialer0
> ip address negotiated
> encapsulation ppp
> dialer pool 1
> dialer string 08450795056
> dialer-group 1
> ppp chap hostname *
> ppp chap password *
> !
> interface Dialer2
> ip address negotiated
> encapsulation ppp
> dialer pool 2
> dialer idle-timeout 10
> dialer-group 2
> no cdp enable
> ppp chap hostname *
> ppp chap password *
> !
> ip classless
> ip route 0.0.0.0 0.0.0.0 Dialer2
> ip route 0.0.0.0 0.0.0.0 Dialer0 80
>

Thanks again, I will give that a go - I cant try it until wednesday
evening though, I will let you know how it goes

Cheers
Guy

In article < .com>,
Guyster <> wrote:
>Morning all,
>
>I am trying to configure an 1841 router to give ADSL access to an ISP
>with an ISDN backup in case the ADSL fails. I have just about got it
>working using the backup interface command on the ATM interface. The
>problem is that when simulating an ADSL failure by pulling the cable,
>the BRI interface comes up and the dialer connects but the ADSL dialer
>stays up which leaves the route out via the ADSL dialer in the routing
>table so no traffic can get out. Any one got any ideas?

You need to take a different approach to failover. Backup interface
requires the interface being backed up to fail but dialer interfaces
never go down, they are either UP (for real) or UP (spoofing).

You need to design your backup scheme using a mechanism which does
not depend on the dialer going down. Normally, this is done through a
routing protocol, but that is rarely an option with ADSL ISPs. Most
people in your situation use "ping based routing" to detect loss of
the ADSL link (a fringe benefit of Cisco's Response Time Recorder
feature) and use that to activate/deactivate the default route
through the ADSL link. A floating static route can then be used
to activate the ISDN backup. But be aware that this approach has
some nasty side effects if you are performing NAT on both ADSL and
ISDN paths inside the router. It also may require you to manually
reactivate the ADSL link before its return to action can be detected.

Good luck and have fun!
--
Vincent C Jones, Consultant Expert advice and a helping hand
Networking Unlimited, Inc. for those who want to manage and
Tenafly, NJ Phone: 201 568-7810 control their networking destiny
http://www.networkingunlimited.com

Vince,

If you don't think on PBR with tracking option, can you provide some links
for "ping based routing"?... I didn't know until now that this feature
exists... I used before only PBR with tracking option and Cisco IP SLA
monitoring.

Thanks in advance...
B.R.
Igor

"Vincent C Jones" <> wrote in message
news:dnkdhh$h6s$...
> In article < .com>,
> Guyster <> wrote:
>>Morning all,
>>
>>I am trying to configure an 1841 router to give ADSL access to an ISP
>>with an ISDN backup in case the ADSL fails. I have just about got it
>>working using the backup interface command on the ATM interface. The
>>problem is that when simulating an ADSL failure by pulling the cable,
>>the BRI interface comes up and the dialer connects but the ADSL dialer
>>stays up which leaves the route out via the ADSL dialer in the routing
>>table so no traffic can get out. Any one got any ideas?
>
> You need to take a different approach to failover. Backup interface
> requires the interface being backed up to fail but dialer interfaces
> never go down, they are either UP (for real) or UP (spoofing).
>
> You need to design your backup scheme using a mechanism which does
> not depend on the dialer going down. Normally, this is done through a
> routing protocol, but that is rarely an option with ADSL ISPs. Most
> people in your situation use "ping based routing" to detect loss of
> the ADSL link (a fringe benefit of Cisco's Response Time Recorder
> feature) and use that to activate/deactivate the default route
> through the ADSL link. A floating static route can then be used
> to activate the ISDN backup. But be aware that this approach has
> some nasty side effects if you are performing NAT on both ADSL and
> ISDN paths inside the router. It also may require you to manually
> reactivate the ADSL link before its return to action can be detected.
>
> Good luck and have fun!
> --
> Vincent C Jones, Consultant Expert advice and a helping hand
> Networking Unlimited, Inc. for those who want to manage and
> Tenafly, NJ Phone: 201 568-7810 control their networking destiny
> http://www.networkingunlimited.com

Igor Mamuzic <> wrote:
>Vince,
>
>If you don't think on PBR with tracking option, can you provide some links

Could you rephrase the clause leading up to the first comma? I
can't parse it, which makes it hard to reply.

>for "ping based routing"?... I didn't know until now that this feature

http://www.cisco.com/en/US/tech/tk36...80211f5c.shtml

>exists... I used before only PBR with tracking option and Cisco IP SLA
>monitoring.

In Cisco IOS, "ping based routing" can be done using PBR with
tracking option, so I think we're using different terms for the same
features. When first introduced, Cisco called it their "Response
Time Recorder" (RTR) feature.

>
>Thanks in advance...
>B.R.
>Igor
>
>"Vincent C Jones" <> wrote in message
>news:dnkdhh$h6s$.. .
>> In article < .com>,
>> Guyster <> wrote:
>>>Morning all,
>>>
>>>I am trying to configure an 1841 router to give ADSL access to an ISP
>>>with an ISDN backup in case the ADSL fails. I have just about got it
>>>working using the backup interface command on the ATM interface. The
>>>problem is that when simulating an ADSL failure by pulling the cable,
>>>the BRI interface comes up and the dialer connects but the ADSL dialer
>>>stays up which leaves the route out via the ADSL dialer in the routing
>>>table so no traffic can get out. Any one got any ideas?
>>
>> You need to take a different approach to failover. Backup interface
>> requires the interface being backed up to fail but dialer interfaces
>> never go down, they are either UP (for real) or UP (spoofing).
>>
>> You need to design your backup scheme using a mechanism which does
>> not depend on the dialer going down. Normally, this is done through a
>> routing protocol, but that is rarely an option with ADSL ISPs. Most
>> people in your situation use "ping based routing" to detect loss of
>> the ADSL link (a fringe benefit of Cisco's Response Time Recorder
>> feature) and use that to activate/deactivate the default route
>> through the ADSL link. A floating static route can then be used
>> to activate the ISDN backup. But be aware that this approach has
>> some nasty side effects if you are performing NAT on both ADSL and
>> ISDN paths inside the router. It also may require you to manually
>> reactivate the ADSL link before its return to action can be detected.
>>
>> Good luck and have fun!
>> --
>> Vincent C Jones, Consultant

--
Vincent C Jones, Consultant Expert advice and a helping hand
Networking Unlimited, Inc. for those who want to manage and
Tenafly, NJ Phone: 201 568-7810 control their networking destiny
http://www.networkingunlimited.com