[nsp] Dial-Backup for PPPoE-Dialer?
Eric.Knudson at getronics.com
Thu Feb 12 19:08:51 EST 2004
This is the same feature we mentioned earlier:
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Neil Christie
Sent: Thursday, February 12, 2004 5:39 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [nsp] Dial-Backup for PPPoE-Dialer?
Bug ID: CSCds88143 (which has no public description/is Cisco
confidential) has been around for some time AFAICT and was due to be
fixed/implemented in 12.3T.
As 12.3T is now out, I recently asked TAC about it, one engineer told
me it is now there (but couldn't name the commands/feature it relates
to), so I asked again and a different engineer said "code is ready
but not fully tested/rolled into IOS yet" (this was in the the past
week, suggesting the features in 12.3(4)T are not all that is to come
This bug ID was mentioned on this very mailing list (Cisco NSP) in August 2002:
and again December 2002:
refers to CSCds88143 as:
"Add ICMP support for PBR set next-hop verify availability"
and there is mention of it last month in:
We're interested in analog/ISDN backup to PPPoA ADSL services - where
as some of the features recently added to IOS in this regard appear
better suited to PPPoE, where DHCP can be tracked for example (ip
dhcp client route track).
Not having to rely on watching for a route containing a specific IP
address, lest it change / to avoid hard coding it would be preferable.
Confirmation of whether CSCds88143 is still being developed (eg more
is to come) or not would of interest to many I believe / as would a
public bug description.
(back to lurk mode), Neil.
>Cisco's concept of "dialer interfaces are always up" has its merits, but
>makes certain situations quite challenging.
>Imagine the following scenario:
>Cisco 836, at customer premises
> primary internet access: ADSL interface, with PPPoE (over ATM over ADSL)
> secondary access, for backup purposes: dialup via ISDN
>the "standard" configuration for PPPoE access makes use of a dialer
> protocol pppoe
> dsl operating-mode annexb-ur2
>interface atm0.1 point-to-point
> description DSL-Pseudo-Dialup
> no shut
> pvc 1/32
> pppoe-client dial-pool-number 1
> description DSL-Pseudo-Dialup
> ip address negotiated
> ip mtu 1492
> ip nat outside
> encapsulation ppp
> dialer pool 1
> ppp authentication chap callin
> ppp chap hostname XXX
> ppp chap password YYY
>ip route 0.0.0.0 0.0.0.0 dialer1 20
>this works fine. Now, what to do if the ADSL line breaks? The "dialer1"
>interface will *always* be "up", due to the way dialer interfaces work.
>One workaround we have found is to use "backup interface" from the
>ATM0 interface to a dialer2 interface (ATM0 goes down, dialer2 changes
>from "standby" to "up" and a floating static route with a better distance
>than the route to dialer1 goes active).
>This works well for physical line outages.
>It doesn't work for a number of other things that tend to go wrong in
>ATM/DSL/PPPoE scenarios with a wholesale/incumbent Telco in between:
> - physical line up, but ATM circuit screwed
> - physical line up, ATM fine, but PPPoE fails to log in due to
> NAS / radius server breakage at the Telco
>in all these cases we want to have the router switch over to ISDN dialup,
>but I just can't find any trick how to do that.
>Other routers (Bintec comes to mind) disable the PPPoE interface for
>a configurable amount of time after a PPP negotiation failure, and
>subsequently fall back to the PPPoISDN interface. Which is exactly
>what we'd need here.
>USENET is *not* the non-clickable part of WWW!
>Gert Doering - Munich, Germany gert at greenie.muc.de
>fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de
>cisco-nsp mailing list cisco-nsp at puck.nether.net
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>Scanned by IFB http://www.ifb.net for spam/UCE and virus content.
>IFB Spam-Score: (0)
cisco-nsp mailing list cisco-nsp at puck.nether.net
archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp