Redundant WAN Paths, OSPF primary and BGP secondary

Answered Question

We use OSPF MPLS as our primary WAN cloud,

recently added BGP MPLS as our secondary WAN cloud.

Currently only two locations have both paths

OSPF and BGP. All traffic transverses the primary path "OSPF", when I fail the primary connection, traffic fails over to the BGP path. So far everything works as expected. I am redistributing BGP into OSPF. When I bring the primary path back online, traffic does switch back to the primary path, traffic between these two locations stay using the BGP path, until I fail one of the secondary connections. When I fail the secondary, traffic moves to primary and stays on primary until another failure. The question I have is why traffic does not move back to primary when the primary is restored. I can provide drawing and configs.

Thanks

I have this problem too.
0 votes
Correct Answer by Giuseppe Larosa about 6 years 11 months ago

Hello Jeff,

I'm happy that this workaround worked for some prefixes.

A similar approach may be possible also if component routes are /32 = 255.255.255.255

router bgp xx

network x.y.z.k 255.255.255.255

aggregate-address x.y.z.k1 255.255.255.252 summary-only

k1 is the base address that includes k and k1 has to be a multiple of 4

example x.y.z.245 /32    k1 = 244

Hope to help

Giuseppe

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Giuseppe Larosa Tue, 12/22/2009 - 09:06

Hello Jeff,

>> I can provide drawing and configs.

In a case like this is needed. My guess is you are performing mutual redistribution in at least one point of your network and this can lead to some problems. But without seeing your current configurations and some sh ip route taken in normal conditions, during failure, and after restore it it is difficult to say more.

Also it would important to verify that primary OSPF routes are all of intra area and inter-area types this could be a measure of sanity to be able to overcome the OSPF external routes generated by redistribution of BGP into OSPF.

In remote branches network ... area + passive interface has to be used instead of redistribute connected.

The first combination of commands generates inter-area routes that are preferred over external routes.

Red connected produces external routes that compete with routes originated by BGP redistribution into OSPF.

Also in complex environments without additional tuning it may become a question of who proposed first the prefix wins.

Hope to help

Giuseppe

Many thanks for the reply. I tested the failover again this past Sunday and unfortantly did not capture the routing table. Never used this form before, so not sure what I should post in the way of documentation. If you are game and have a few minutes, I can provide drawing, config and current routing table. In short, have two locations with OSPF WAN connecting them. At each location, installed another router to terminate the BGP cloud. Primary location I am advertising default route into BGP, the other secondary location I'm advertising the specific routes at that location into BGP.

Thanks for the reply and your efforts, I will try summary routes in BGP, it was my understanding you had to have a summary route in OSPF routing table before BGP will insert route. I am attaching show ip bgp rib-failure for both BGP routers before failing "normal state". Will test again soon and then can provide show ip bgp rib-failure output when running on backup BGP path, then after restoring.

Marwan ALshawi Mon, 12/28/2009 - 16:50

what i am suspecting is that you have the BGP peering over

tunnel4 and this tunnel configured as passive interface

can you try to mak eit not passive

also during th failover ( i mean when you fail over back to ospf and the route still showing from bgp )

what is  the result of

show ip ospf nei

show ip route 10.1.229.0

Giuseppe Larosa Tue, 12/29/2009 - 11:45

Hello Jeff,

I've looked at your attachments and the behaviour is still strange and requires you to shut the tunnel to be able to see primary OSPF routes re-installed in routing table.

primary routes are OSPF IA routes and this is good.

When the primary link fails the local router originates OSPF external LSAs representing the networks of the remote site.

When the primary link recovers it should use the O IA routes coming on primary link but it is not doing this.

There is still one dimension that can be used: prefix length

on remote router under process BGP you should use

router bgp xx

network 10.1.229.0 netmask 255.255.255.0

aggregate-address 10.1.228.0 255.255.254.0 summary-only

in this way you should receive only the /23 and not the /24.

This approach is feasible if your address plan allows for this.

This should allow primary most specific routes to be used when they come back on primary link.

Hope to help

Giuseppe

Correct Answer
Giuseppe Larosa Wed, 12/30/2009 - 09:37

Hello Jeff,

I'm happy that this workaround worked for some prefixes.

A similar approach may be possible also if component routes are /32 = 255.255.255.255

router bgp xx

network x.y.z.k 255.255.255.255

aggregate-address x.y.z.k1 255.255.255.252 summary-only

k1 is the base address that includes k and k1 has to be a multiple of 4

example x.y.z.245 /32    k1 = 244

Hope to help

Giuseppe

Marwan ALshawi Tue, 12/22/2009 - 15:58

can you try this command before and after you do manual fail over

show ip bgp rib-failure

the idea here is to see wither your router see ospf as better route than bgp as you changed bgp distance to 130

i did a quick test to your config and worked fine !!!

Although it supposed to work as you wanted but you may try a work around

as long as you receive specific routes through ospf

you can send summary routes through bgp, in this case you will use ospf for all specific routes and if that specific routes disappear ( ospf down) the summary bgp will be used

but becareful from have balckholing ( send big summary without more specific networks in the remote location )

good luck

if helpful rate

Message was edited by: marwanshawi in this case use the method highlighted above

Actions

This Discussion