floating static route - isdn backup for ISP connection

[aoshea]

I have been asked to provide assistance to a customer who has an ISP managed router and wishes to implement a separate router for ISDN backup purposes. (they don’t want the ISP to do this because of cost and they have a spare 1721 lying around).

The main problem is that the managed router (2MB lease line) is owned by the ISP and no user configuration is possible. The second router is a 1721 with a wic-1b card installed, this is connected to another ISP via a dialler interface, with a negotiated IP address.

The customer’s 'private' network is located behind a pix firewall.

What is the best way to do this;

ISP managed router a.b.c.241 /29

ISDN router a.b.c.242 /29

pix firewall a.b.c.254 /29

I have played around with defining two routes on the isdn router, one the primary pointing to the ISP router and the second pointing to the dialler 1 interface with an admin distance of 250. (no routing protocol has been defined, just two static routes).

The pix has a route pointing to the isdn router for all external routes.

The problem so far;

Traffic is going from the isdn router to the ISP router ok, when the lease line is up. however when the ISP router is powered off (to test) the isdn dialler interface does not come up. Also when the ISP router is turned on again, traffic does NOT return to normal.

I'm pulling my hair out on this one, I think the reason it isn't working is that I need a static address for the isdn to allow it to be published within the network a.b.c.d command in a routing protocol.

Please find below the config so far, I know it needs to be adjusted. Any help would be appreciated.

Thanks and regards,

Adrian.

=====================================================

isdnbackup#sh run

Building configuration...

Current configuration : 1757 bytes

!

! Last configuration change at 11:20:23 GMT Thu Dec 11 2003

!

version 12.3

service timestamps debug uptime

service timestamps log uptime

service password-encryption

!

hostname isdnbackup

!

logging console notifications

enable password abcdefghijklmnop

!

clock timezone GMT 0

clock summer-time BST recurring last Sun Mar 1:00 last Sun Oct 1:00

ip subnet-zero

!

!

no ip domain lookup

ip name-server w.x.y.z

!

isdn switch-type basic-net3

!

!

!

!

interface BRI0

description connected to Internet

no ip address

ip nat outside

encapsulation ppp

dialer rotary-group 1

dialer-group 1

isdn switch-type basic-net3

no cdp enable

!

interface FastEthernet0

description connected to EthernetLAN

ip address a.b.c.242 255.255.255.240

ip nat inside

speed auto

!

interface Dialer1

description connected to Internet

ip address negotiated

ip nat outside

encapsulation ppp

no ip split-horizon

dialer in-band

dialer idle-timeout 60

dialer string 2nd isp dialup number

dialer hold-queue 10

dialer load-threshold 10 outbound

dialer-group 1

no cdp enable

ppp authentication chap pap callin

ppp chap hostname 2nd isp

ppp chap password password

ppp pap sent-username 2nd isp password password

ppp multilink

!

ip nat inside source list 1 interface Dialer1 overload

ip classless

ip route 0.0.0.0 0.0.0.0 a.b.c.241 permanent name 1st_isp

ip route 0.0.0.0 0.0.0.0 Dialer1 200 permanent name isdnbackup

no ip http server

!

access-list 1 permit a.b.c.240 0.0.0.15

access-list 50 permit a.b.c.240 0.0.0.15

dialer-list 1 protocol ip permit

!

line con 0

exec-timeout 0 0

password password

login

line aux 0

line vty 0 4

access-class 50 in

password password

login

!

!

end

[mark-obrien · Accepted solution]

The reason this is not working is that the ISDN router always has a route to a.b.c.241, even if the ISP router is not up. The ISDN router will see this address as being accessible via a connected address even when the other router fails.

I recommend asking your provider to run a simple routing protocol between their router and yours. Ask them to advertise a default route whenever the serial connection is up. If they agree to this, you will get rid of the static route pointing to the ISP router, since you will normally learn the default route via the routing protocol. If the connection fails for any reason, the ISDN router will delete the default route, the floating static will take over and the ISDN router will place a call.

HTH

Mark

[aoshea]

Many thanks for your help, however the ISP is not forthcoming with helping. I am going to look at using dialer-watch to monitor the next hop from their router.

I'll let you know how I get on, thanks for your help anyway.

Regards, Adrian.

[kkalaycioglu · Accepted solution]

Your static routes include "permanent" keyword so even if the next hop is unaccessible the static route with admin.distance 1 is always in the route table, try to use static routes without "permanent".

[EarlV]

From CCNP Course, Advanced Routing Chapter

Copy Write Cisco.Com

Static routing has disadvantages, one of which is that it cannot adapt to topology changes. However, you can configure static routing to have limited adaptability by creating floating static routes.

Floating static routes are static routes configured with an administrative distance value that is greater than that of the primary route (or routes). Essentially, floating static routes are fallback routes, or backup routes, that do not appear in the routing table until another route to the same destination fails. For example, assume that RTB is connected to network 10.0.0.0/8 via two different links, as shown in Figure . Also, assume that RTB's preferred route to network 10.0.0.0/8 is via RTC because that link has a higher bandwidth. This route is learned by RIP. RTB should use the slower link to 10.0.0.0/8 via RTA only if the primary route fails. The route to RTA is statically configured.

To statically configure RTB so that it will use the slower link to reach 10.0.0.0/8 after the RIP route fails, you must use a floating static route as shown:

RTB(config)#ip route 10.0.0.0 255.0.0.0 1.1.1.1 130

This ip route command includes an administrative distance of 130. Recall that static routes have a default administrative distance of 1 (see Figure ). To create a static route that will float (that is, wait for another route to fail before entering the routing table) you must manually set an administrative distance value. This value must be greater than the primary route's administrative distance value. In this example, the primary route is learned by RIP and thus has an administrative distance of 120. By configuring the static route with an administrative distance of 130, the static route will be less desirable than the primary route and the RIP route via RTC is always preferred. However, if the RIP route is lost, the floating static route takes its place in the routing table. Figure shows RTB's routing table with the RIP route and then, after the RIP route is lost, RTB's routing table with the floating static route.

The output in Figure includes output from the debug ip routing command, which details the loss of the primary route and the subsequent installation of the floating static route.

Floating static routes can be used in conjunction with other static routes to create a semi-adaptable static routing scheme. Consider this configuration :

RTZ(config)#ip route 0.0.0.0 0.0.0.0 s0

RTZ(config)#ip route 0.0.0.0 0.0.0.0 s1 5

RTZ(config)#ip route 4.0.0.0 255.0.0.0 s2

RTZ(config)#ip route 4.0.0.0 255.0.0.0 s3 5

RTZ(config)#ip route 4.0.0.0 255.0.0.0 s4 10

If RTZ is configured with these commands, it installs one route to 0.0.0.0/0 (using S0) and one route to 4.0.0.0/8 (using S2). If S0 becomes unavailable, RTZ will install the floating static route to 0.0.0.0/0 (using S1) into its routing table. If S2 fails, RTZ will fall back to using S3 to reach 4.0.0.0/8. Finally, if both S2 and S3 go down, RTZ will use the least desirable static route to 4.0.0.0/8, with an administrative distance 10.