failover takes too long

[wilson2468]

Posted by: richmorrow624 - Jul 4, 2006, 6:02pm PST


I have several remote sites that I want to set up in the
following way, I have it set up in a lab now:

The primary is connected via MPLS and is using OSPF for connectivity to the HQ
site.

The secondary has a VPN connection to the Internet as a failover connection.

Both connections are always up.

When the primary fails, it seems to take about two minutes before the switchover provides connectivity back via the VPN connection using RIP. When the
connection to the MPLS cloud is re-established, it takes about 3 minutes to
connect via OSPF.

Keep in mind this is a lab situation and has not been implemented just yet,the
configs are provided for the remote lab sites.

I would like the switch over to take only 10 seconds or so both ways, can this
be done?

If both connections are up all the time, it seems it should switch faster,
unless the routers have to let the routes die and repopulate with the other
protocol.

Would this be the reason it is taking so long?

Is this what I should expect as far as efficient failover?

What can I do to speed this up?

 

[jonks]

We have a similar setup to what you are trying to achieve. We run a MPLS primary line and a IPSec VPN as a backup. Our failover takes less than 10 seconds to cutacross and a similar time to cut back. We use GRE tunnels with OSPF on the MPLS and floating statics to failover to the VPN. You need to make sure that there are keepalives configured on the MPLS link. We have had ours in place for 2 years and it works a treat.

 

[wilson2468]

Thanks for the reply

would it be possible for me to see how you have that configured?

 

[jonks]

Building configuration...

Current configuration : 2328 bytes
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname Southend
!
boot-start-marker
boot-end-marker
!
enable secret 5 $
enable password 7
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
!
!
!
!
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
logging enable
notify syslog
hidekeys
!
!
!
!
interface Tunnel0
bandwidth 2000
ip unnumbered Loopback0
ip ospf network point-to-point
ip ospf cost 25
ip ospf mtu-ignore
keepalive 10 2
tunnel source x.x.x.x
tunnel destination x.x.x.x
!
interface Tunnel1
bandwidth 2000
ip unnumbered Loopback1
ip ospf network point-to-point
ip ospf mtu-ignore
keepalive 10 2
tunnel source x.x.x.x
tunnel destination x.x.x.x
!
interface Loopback0
ip address x.x.x.x 255.255.255.255
!
interface Loopback1
ip address x.x.x.x 255.255.255.255
!
interface Ethernet0/0
no ip address
shutdown
half-duplex
!
interface FastEthernet0/0
ip address x.x.x.x 255.255.255.0
speed auto
full-duplex
!
interface Serial1/0
bandwidth 2000
no ip address
encapsulation frame-relay IETF
ip ospf network broadcast
fair-queue
frame-relay lmi-type ansi
!
interface Serial1/0.10 point-to-point
bandwidth 2000
ip unnumbered Loopback0
frame-relay interface-dlci 101 IETF
!
interface Serial1/0.20 point-to-point
bandwidth 2000
ip unnumbered Loopback1
!
router ospf 1
log-adjacency-changes
area 0 range x.x.x.x 255.255.255.0
area 0 range x.x.x.x 255.255.255.0
area 0 range x.x.x.x 255.255.255.0
network x.x.x.x 0.0.0.255 area 0
network x.x.x.x 0.0.0.255 area 0
network x.x.x.x 0.0.0.255 area 0
!
ip classless
ip route 0.0.0.0 0.0.0.0 Tunnel0
ip route 0.0.0.0 0.0.0.0 Tunnel1 100
ip route 0.0.0.0 0.0.0.0 x.x.x.x 200 (VPN Link)
ip route x.x.x.x 255.255.255.255 Serial1/0.10
ip route x.x.x.x 255.255.255.255 Serial1/0.10
no ip http server
!
!
!
logging trap notifications
logging x.x.x.x
logging x.x.x.x
logging x.x.x.x
snmp-server community x.x.x.x RO
snmp-server enable traps tty
!
!
control-plane
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
password 7
login
!
end

 

[lgarner]

RIP might be the problem, since it's relatively slow. When I set up something similar, I used a routing protocol (EIGRP in my case) to establish the WAN and set the default routes to the VPN. When the WAN link was down the route was lost very quickly and traffic used the default gateway.