cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
802
Views
0
Helpful
1
Replies

OSPF/VPN backup for BGP MPLS not failing back.

michaelwarner
Level 1
Level 1

I am attempting to set up VPN failover for our MPLS circuits at our remote locations.  We are currently set up to use weighted static routes that give preference to BGP.  This works, but the static routes must be listed on all of the destination routers in order to make those destinations accessible, and we need to reconfigure all of the routes manually every time there is a change.  The VPNs used are standard point-to-point tunnels which are terminated on the MPLS routers, and are always active.

I configured one of the backup tunnels to use OSPF, and it failed over immediately after downing the MPLS interface on the remote router, but after reenabling the MPLS it kept using the OSPF routes.  I had to down the VPN interface manually in order for it to use the BGP routes again.  I assumed the BGP routes would always take precedence due to lower administrative distance?  Am I missing something?

Relevant section of remote MPLS router config (ip addresses changed to protect the innocent):

interface FastEthernet0/0
description TO LAN
ip address 10.1.0.10 255.255.255.0

interface FastEthernet0/1
description TO Internet-Backup-MPLS
ip address 20.20.20.10 255.255.255.248

interface Tunnel100
description Bkup Tunnel to HQ

ip address 172.31.0.1 255.255.255.252

tunnel source 20.20.20.1
tunnel destination 30.30.30.1
crypto map test-map

router ospf 1
log-adjacency-changes
redistribute bgp 65501 subnets
network 10.1.0.0 0.0.0.255 area 0
network 172.31.0.0 0.0.0.3 area 0

router bgp 65501
no synchronization
bgp log-neighbor-changes
network 172.16.5.16 mask 255.255.255.255
redistribute ospf 1
neighbor 40.40.40.1 remote-as 209
no auto-summary

1 Reply 1

michaelwarner
Level 1
Level 1

I've been digging on the Internets, and it seems as if my issue is due to the redistribution of OSPF routes into BGP?  Evidently the weight of the redistributed route is causing it to be preferred over the original BGP route.  There was some mention of fixing this by adding a route-map with a set weight of 0, but couldn't find the details.  Any ideas?

Review Cisco Networking products for a $25 gift card