01-27-2009 12:27 PM - edited 03-04-2019 12:59 AM
Hello,
I have an IBGP full mesh between 8 routers. 4 core routers connected in a ring, and 4 edge routers dual connected to 2 of the core routers, depending which location they are in, 2 to core and 1 and 2 in location A and 2 to core 3 and 4 in location B.
The 2 edge routers in location A have bgp redistribute-internal, it is legacy commands that we may remove but I believe this is causing the problem I cam going to describe below.
I have an EBGP peer on core router 1 at location A, and an EBGP pper on edge router 1 at location A. I turned down the ebgp peer from core router 1 at location A, and right after that, the CPU on both of the edge routers that have the redistribute-internal on spiked to 99, and the OSPF neighbors dropped, probably because the router got overloaded.
Why did this happen, considering that I do not have OSPF on the edge routers saying to redistribute ebgp into it. Does the OSPF process process all of those ibgp routes, but deny them, but still takes the time and CPU to process all 200,000 routes?
I am still unsure why downing an eBGP peer triggered that redistribution, when things were stable.
Other then clear ip bgp * what can trigger that bgp redistribute-internal command to start importing all of the 200,000 ibgp routers it has to ospf?
02-02-2009 02:46 PM
To allow the redistribution of internal Border Gateway Protocol (iBGP) routes into an Interior Gateway Protocol (IGP), such as Intermediate System-to-Intermediate System (IS-IS) or Open Shortest Path First (OSPF), use the bgp redistribute-internal command in an appropriate configuration mode. To disable the redistribution of iBGP routes into IGPs, use the no form of this command.
bgp redistribute-internal
no bgp redistribute-internal
02-03-2009 01:57 AM
Hello Jason,
>> I am still unsure why downing an eBGP peer triggered that redistribution, when things were stable.
in your iBGP full mesh do you provide preference to core routers with weight or local preference commands ?
If so shutting down a peer caused a big BGP table recalculation and older devices with less poweful cpu suffered most.
if you haven't a redistribute bgp xx subnets into OSPF no redistribution of BGP into OSPF should happen.
the bgp internal command given in BGP allows to redistribute iBGP routes into an IGP but it is not enough alone to cause distribution to occur.
Then of course spiking cpu to 100% you see also OSPF going down.
Hope to help
Giuseppe
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