12-15-2003 06:50 AM - edited 03-02-2019 12:21 PM
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 dont 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 customers '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
Solved! Go to Solution.
12-15-2003 08:33 AM
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
12-17-2003 06:35 AM
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".
12-15-2003 08:33 AM
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
12-17-2003 05:02 AM
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.
12-17-2003 06:35 AM
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".
12-17-2003 05:55 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide