[nsp] Dial-Backup for PPPoE-Dialer?

[Neil Christie]

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 
from CSCds88143)

This bug ID was mentioned on this very mailing list (Cisco NSP) in August 2002:
https://puck.nether.net/pipermail/cisco-nsp/2002-August/000104.html

and again December 2002:
https://puck.nether.net/pipermail/cisco-nsp/2002-December/001775.html

http://groups.google.com/groups?q=CSCds88143&hl=en&lr=&ie=UTF-8&selm=3dc80116.2331232%40usenet.cisco.com&rnum=3
refers to CSCds88143 as:
"Add ICMP support for PBR set next-hop verify availability"

and there is mention of it last month in:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=njke00d3lccb6s635ijgetngbel5kdpo9n%404ax.com

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.



>Hi,
>
>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
>interface:
>
>vpdn enable
>
>vpdn-group pppoe
>  request-dialin
>   protocol pppoe
>
>interface ATM0
>     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
>!
>interface Dialer1
>     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.
>
>Suggestions?
>
>gert
>--
>USENET is *not* the non-clickable part of WWW!
>                                                            //www.muc.de/~gert/
>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
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>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)