12-22-2009 05:35 AM - edited 03-04-2019 07:02 AM
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
Solved! Go to Solution.
12-30-2009 09:37 AM
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
12-22-2009 09:06 AM
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
12-22-2009 09:32 AM
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.
12-22-2009 09:49 AM
12-22-2009 03:58 PM
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
12-23-2009 06:28 AM
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.
12-28-2009 10:39 AM
Have not tried summary suggestion. Tested with another setup simliar to what I have been using. Primary path OSPF with backup path via IPSEC connection running BGP. See attached document which includes configurations and routing output during each phase of testing.
Any ideas would be greatly appeciated.
Thanks
12-28-2009 04:50 PM
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
12-29-2009 10:54 AM
12-29-2009 11:45 AM
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
12-30-2009 08:41 AM
That worked for the local networks, 10.1.228.0 and 10.1.229.0
The loopback is a /32, any to address this. The other location we are trying to use the same OSPF/BGP backup design has several /32 host static routes at that location. Many thanks for the help.
12-30-2009 09:37 AM
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
12-30-2009 10:07 AM
Thanks for the help and I believe this will help solve the issue, this will be useful until we can migrate to all BGP, primary and secondary.
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