Cisco 1841 with ISDN backup

see Reliable Static Routing Backup Using Object Tracking

The IP SLA functionality is only, iirc, available in the 'broadband' feature set & up - not the base image which the OP has. I ran into a similar issue at a customer site & ended up using EIGRP across the LES connection instead, which doesn't help here much.

Is the ISDN backup for the Internet connection, or are you connecting via VPN to another site which you would then be dialling into directly for backup? If so, can you use a dynamic routing protocol over the VPN with floating statics on the dialer for backup?

Just my 2p worth....

Ah yes. That is the classic solution.

Dynamic routing protocol on the main link with floating static routes for the dial up one.

ip route 0.0.0.0 0.0.0.0 dialer 200

That's what I would do before going for the SLA one - never having used either:-))

Both connections are for the internet connection, so i don't think i will be able to use routing protocol. Or can i use them?

Ask your ISP if they can send you default route via any dynamic routing protocol

If so then you can float a default route to point to the ISDN dialer interface

Ok, so i followed your advise! (Reliable Static Routing Backup Using Object Tracking)Thanx. I'm trying to set it up now, and i'm running into the following:

I have configured the following:

Configuring the Primary Interface for PPPoE Configuring the Primary Interface for Static Routing Configuring the Backup Interface for Reliable Static Routing Backup Using Object Tracking Configuring Cisco IOS IP SLAs for Cisco IOS Release 12.3(14)T, 12.4 and 12.4(2)T

Now i have to set up a routing policy for PPPoE. The problem is, as you can see in my config, in both Dialer interfaces i'm refering to my FastEthernet 0/0 for the IP-address.

In the routing policy i have to set up an source IP to ensure the tracking is only done over the primary interface.

Is there any way to work around that? I won't be able to set up another IP-adres for the backup interface.

Thanx.

OK, here the deal.

I tried implementing the config is a working enviroment. The primary link is coming up, no problem. But when pull out the primary (DSL) connection, it gives the following message:

*Aug 17 10:49:44.559: Track: 1 Change #3 rtr 1, reachability Up->Down *Aug 17 10:49:44.559: %TRACKING-5-STATE: 1 rtr 1 reachability Up->Down

As far as i can tell, that's good. But after that, nothing happens. The BRI interface is not coming up.

Here is my most recent config:

! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec service password-encryption ! hostname XXXX ! boot-start-marker boot-end-marker ! logging buffered 51200 warnings enable secret ! no aaa new-model ip cef ! ! ! ! ip sla monitor 1 type echo protocol ipIcmpEcho 212.45.32.3

1. post the output of sh ip route after disconnecting the DSL link

1. enable logging buffer

1. post output of sh isdn status

1. enable debug isdn q921

2. enable debug isdn q931

1. disconnect DSL to see what is occurring or not occuring with repsect to ISDN call initiation

also

1. debug ppp negotiation

1. debug ppp authentication

Ok, here are the results:

IP-route without the DSL link:

10.0.0.0/24 is subnetted, 1 subnets C 10.31.0.0 is directly connected, FastEthernet0/0 S* 0.0.0.0/0 is directly connected, Dialer1

Seems good, the 0.0.0.0 is pointing towards the Dialer1 (ISDN). When the DSL is connected, the 0.0.0.0 is pointing towards the Dialer0.

show isdn status:

Global ISDN Switchtype = basic-net3 ISDN BRI0/1/0 interface dsl 2, interface ISDN Switchtype = basic-net3 Layer 1 Status: DEACTIVATED Layer 2 Status: Layer 2 NOT Activated Layer 3 Status: 0 Active Layer 3 Call(s) Active dsl 2 CCBs = 0 The Free Channel Mask: 0x80000003 Total Allocated ISDN CCBs = 0

When i pull down out the DSL cable, the DSL goes down, and nothing happens. This is an output of the debug:

solcon#

*Aug 20 08:03:22.603: %TRACKING-5-STATE: 1 rtr 1 reachability Up->Down *Aug 20 08:03:24.331: %CONTROLLER-5-UPDOWN: Controller DSL 0/0/0, changed state to down *Aug 20 08:03:26.331: %LINK-3-UPDOWN: Interface ATM0/0/0, changed state to down *Aug 20 08:03:27.307: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state t o down *Aug 20 08:03:27.307: Vi2 IPCP: Remove link info for cef entry 212.45.33.132 *Aug 20 08:03:27.307: Vi2 PPP: Sending Acct Event[Down] id[3] *Aug 20 08:03:27.307: Vi2 IPCP: State is Closed *Aug 20 08:03:27.307: Vi2 PPP: Phase is ESTABLISHING, renegotiate LCP *Aug 20 08:03:27.307: Vi2 PPP: Authorization required *Aug 20 08:03:27.307: Vi2 PPP: No remote authentication for call-out *Aug 20 08:03:27.307: Vi2 LCP: O CONFREQ [Closed] id 8 len 14 *Aug 20 08:03:27.307: Vi2 LCP: MRU 1492 (0x010405D4) *Aug 20 08:03:27.307: Vi2 LCP: MagicNumber 0x138E8A93 (0x0506138E8A93) *Aug 20 08:03:27.307: %DIALER-6-UNBIND: Interface Vi2 unbound from profile Di0 *Aug 20 08:03:27.307: Di0 IPCP: Remove route to 212.45.33.132 *Aug 20 08:03:27.311: Vi2 PPP: Sending Acct Event[Down] id[3] *Aug 20 08:03:27.311: Vi2 LCP: State is Closed *Aug 20 08:03:27.311: Vi2 PPP: Phase is DOWN *Aug 20 08:03:27.331: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0/0/0, changed state to down *Aug 20 08:03:28.307: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Ac cess2, changed state to down

It seems that the ISDN is not triggered to connect, even tough i am constantly pinging from my pc.

Layer 1 status of DEACTIVATEDi s not a good sign

follow the steps in the Cisco troubleshooting doc for ISN BRI layer 1:

AFAIK layer 1 and layer 2 must be in ACTIVATED state before a call can be placed

This is correct.

All ISDN interfaces that I have seen look like this when no call is in progress.

Layer 1 Status: ACTIVE Layer 2 Status: TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: 0 Active Layer 3 Call(s) (This is a voice PRI but that does not matter)

When calls are active the Layer 3 count increments with each call.

There are a number of "debug isdn ....". they are hard to interpret though, since I do not understand ISDN:-)

The OP{ may want to power cycle the router to ensure the BRI interface was truly reset from when it was configured with backup interface command.

Ok, the config works now. I was missing:

dialer-list 2 protocol ip permit

My traffic wasn't allowed over the dialer1 interface, so my ISDN never saw 'interesting' traffic

Now the following problem comes to light:

When i pull out my DSL cable, i get the following message:

*Aug 20 14:08:38.935: %TRACKING-5-STATE: 1 rtr 1 reachability Up->Down

After this, the ISDN connection starts dialing in. The problem is, that both my dialers are pointing to the same IP- adres. And as soon as the ISDN interface is online, since i'm tracking a DNS server, the tracking seems to think that the DSL connection is up again, and starts routing the traffic over the Dialer 0 interface which in fact is down.

After that, i keep getting the following:

*Aug 20 14:08:38.935: %TRACKING-5-STATE: 1 rtr 1 reachability Down->Up *Aug 20 14:08:43.935: %TRACKING-5-STATE: 1 rtr 1 reachability Up->Down *Aug 20 14:08:38.935: %TRACKING-5-STATE: 1 rtr 1 reachability Down->Up *Aug 20 14:08:53.935: %TRACKING-5-STATE: 1 rtr 1 reachability Up->Down

Pff, i 1 thing works, i keep getting another problem :)

I was going to suggest adding a static host route through the dialer0 interface, but of course as it is the DNS server (which I assume you will need to be reachable over ISDN) this might break more stuff :o)

Is there anything else you can ping instead, which would be OK to route over the Di0 interface, even if that connection is down?

One word of caution about this whole setup though: you're at the mercy of the admins of whatever system you are pinging & if they decide to suddenly block ICMP inbound, you could get a large ISDN bill unless you monitor the line. (The users would almost certainly complain about speed issues I guess). This does happen - when Cisco acknowledged a vulnerability to specifically crafter ICMP packets, a lot of people I think took it as an opportunity to block ICMP. We certainly found this to be the case with BT & as we were tracking one or two things based on being able to ping their routers, it did break stuff for a short while.

The IPSLA echo packet must be routed only via the "primary" interface for this solution to work.

config t no ip local policy route-map test ip local policy LOCAL-POLICY

no access-list 101 access-list 101 permit icmp any host 212.45.32.3

route-map LOCAL-POLICY permit 10 match ip address 101 set interface Dialer 0 Null0 end

Please post full output of show ip route when the DSL interface is in up & up state

On 20 aug, 23:36, Merv wrote:

IT WORKS!!! Merv, you're the best.

sorry for the massive delay, but i had troubles with dialing into a specific number, which needed CHAP as authentication instead of the regular PAP. It works now. My DSL connection is primary, with ISDN as backup. When the DSL connection fails, the ISDN interface starts dialing, and works. When the DSL connection comes up again, after the 300 second timeout the ISDN interface goes down.

Right here is the working config:

! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec service password-encryption ! hostname ! boot-start-marker boot-end-marker ! logging buffered 51200 warnings enable secret ! no aaa new-model ip cef ! ! no ip dhcp use vrf connected ! ! ip sla monitor 1 type echo protocol ipIcmpEcho timeout 1000 threshold 2 frequency 3 ip sla monitor schedule 1 life forever start-time now isdn switch-type basic-net3 username password ! ! controller DSL 0/0/0 mode atm line-term cpe line-mode 2-wire line-zero dsl-mode shdsl symmetric annex B line-rate auto ! ! track 1 rtr 1 reachability ! ! interface FastEthernet0/0 description LAN klant ip address duplex auto speed auto no keepalive ! interface FastEthernet0/1 no ip address shutdown duplex auto speed auto ! interface ATM0/0/0 no ip address no atm ilmi-keepalive pvc 0 0/36 encapsulation aal5mux ppp dialer dialer pool-member 1 ! ! interface BRI0/1/0 description Inbel interface no ip address encapsulation ppp no ip route-cache cef no ip route-cache no ip mroute-cache dialer pool-member 2 isdn switch-type basic-net3 isdn point-to-point-setup no fair-queue ! interface Dialer0 mtu 1492 ip unnumbered FastEthernet0/0 encapsulation ppp ip tcp adjust-mss 1452 dialer pool 1 dialer-group 1 no cdp enable ppp authentication pap callin ppp pap sent-username password ! interface Dialer1 ip unnumbered FastEthernet0/0 encapsulation ppp dialer pool 2 dialer remote-name dialer idle-timeout 300 dialer wait-for-carrier-time 10 dialer string XXXXXXXX dialer-group 2 no cdp enable ppp authentication chap callin ppp chap hostname ppp chap password (I need CHAP for authentication, but pap is also possible here) ! ip local policy route-map LOCAL-POLICY ip route 0.0.0.0 0.0.0.0 Dialer0 track 1 ip route 0.0.0.0 0.0.0.0 Dialer1 254 ! no ip http server ip http authentication local ip http timeout-policy idle 5 life 86400 requests 10000 ! access-list 101 permit icmp any host dialer-list 1 protocol ip permit dialer-list 2 protocol ip permit route-map LOCAL-POLICY permit 10 match ip address 101 set interface Dialer0 Null0 ! ! control-plane ! ! line con 0 login local line aux 0 line vty 0 4 privilege level 15 login local transport input telnet line vty 5 15 privilege level 15 login local transport input telnet ! scheduler allocate 20000 1000 end