Building network automation solutions

9 module online course

Start now!

Almost-Dynamic Routing over ADSL Interfaces

Recently I had to implement Internet access using ADSL as the primary link and ISDN as the backup link. Obviously the most versatile solution would use the techniques described in my Small Site Multi-homing articles, but the peculiarities of Cisco IOS implementation of the ADSL technology resulted in a much simpler solution.

IOS implementation of PPPoE links uses dialer interfaces. However, the “dialing” on these interfaces is activated as soon as the underlying PPPoE session is active (before the first interesting packet is routed to the interface). When the simulated dial-out occurs, the router starts PPP negotiations including the IPCP handshake, which usually results in an IP address assigned to the dialer interface. Net result: if the dialer interface has an IP address, the PPPoE session is obviously active (and vice versa).

As my ADSL link and the ISDN backup used the same service provider (and very probably the same Radius servers), it made no sense to define additional IP SLA measurements to figure out if the service provider's network is operational; the IP route to the primary dialer interface is installed as soon as the interface is ready to route IP packets. The relevant parts of the router's configuration are included below.

interface FastEthernet0
 description outside LAN
 no ip address
 ip virtual-reassembly
 duplex auto
 speed auto
 pppoe enable group global
 pppoe-client dial-pool-number 3
interface BRI0
 description ISDN line
 encapsulation ppp
 dialer pool-member 1
 isdn switch-type basic-net3
interface Dialer0
 description ADSL primary uplink
 ip address negotiated
 ip mtu 1492
 ip nat outside
 encapsulation ppp
 dialer pool 3
interface Dialer1
 description ISDN backup
 ip address negotiated
 ip nat outside
 dialer pool 1
track 100 interface Dialer0 ip routing
 delay down 10 up 10
ip route Dialer0 10 track 100
ip route Dialer1 250


  1. Should the line
    "track 100 interface Dialer3 ip routing"
    point to Dialer0 instead? I'm still pretty rough with this stuff so ignore me if I've missed something obvious. Very neat though.
  2. You're absolutely right. I've fixed the post and (like any good electronic engineer :) color-coded the interface names.
  3. Hello Ivan, why is the tracking needed? Wouldn't it work without? Thanks regards, Christian
  4. A "dialer" interface is always in an up/up state, even when it's not connected to a remote peer (otherwise the regular dialing functionality wouldn't work).

    If the PPPoE session underlying the Dialer interface is not operational, the static route without the "track" option would still point to the interface and attract the traffic.
  5. You may also want to check this very recent document:
  6. You do not need the route "ip route Dialer0 10 track 100" and the tracking if you configure "ppp ipcp route default" on interface Dialer0.
    Works the same way... :-)
  7. @wolruf: Yeah, I know those documents ... they were a year or so behind me :).
  8. hi ivan, with 2 adsl connection to the same connection, is it possible to do load balancing? thanks.
  9. sorry, with 2 adsl connections to the same ISP, is it possible to do load balancing? thanks.
  10. Thanks for the great articles, Ivan. One quick question: how would you implement port forwarding from the Internet into the LAN using this scenario?

    I've been using a setup similar to this for about a year now, and haven't found an answer to that. For now, each host has to have 2 private IP's, with each statically mapped to a single IP in both ISP 1 and ISP 2 subnet blocks. Then port forwarding works. Any ideas?
  11. Just wait a few days, this topic is covered in my next IP Corner article.
  12. Hi Ivan, Great blog site! Instead of the tracking, could you get away with:

    ip route <Dialer0's default router IP>
    ip route Dialer1 250
  13. ... assuming you're always connected to the same BRAS. Once the SP reconfigures the network you're toast.
Add comment