interface ATM0/0 description XXXXXXXXXX Secondary Internet Connection no ip address no atm ilmi-keepalive pvc 6/42 encapsulation aal5snap protocol ppp dialer dialer pool-member 1 ! dsl operating-mode auto ! interface Dialer0 description Authentication Happens Here ip address XXX.XXX.XXX.XXX 255.255.255.0 encapsulation ppp dialer pool 1 dialer-group 1 ppp chap hostname XXXXXXXXXXXXXXXXX ppp chap password 7 XXXXXXXXXXXXXXXXXX ! dialer-list 1 protocol ip permit
But I do have to admit some confusion over why it suddenly started working. I had this configuration pretty much in place by the end of January but I just couldn't even see the customer's router by DSL (which, as you can see there, is a backup connection in case their router's primary connection goes down). It's hard to debug this since you don't even see the traffic unless you pass an authencation request through the physical lines owned by The Monopolistic Phone Company, and because the radius authentication server wasn't getting any requests, that meant that our Cisco router wasn't seeing any DSL traffic from the customer.
Then earlier this week BAM traffic suddenly was getting through. It's almost as if The Monopolistic Phone Company took their own sweet time in actually enabling the DSL circuit on our customer's phone line.
Good thing too, since their current provider is having issues with connectivity (and twice this week I've had to reprogram their router's primary IP address). Now the issue is why the router is prefering the DSL connection over their primary connection (which is the exact opposite of what is supposed to happen).
Update on March 2nd, 2006
I found out why why the DSL was being prefered over the Ethernet connection.