11-01-2010 04:29 AM - edited 03-06-2019 01:49 PM
Hi all experts.
I was viewing the purpose of this command came around this link
http://blog.zakir.net/index.php?/archives/20-BGP-suppress-inactive.html
"That's what the “bgp suppress-inactive” command do. It supresses the advertisement of BGP inactive/rib-failure route. Now here is a gotcha. BGP doesn't always supress inactive/rib-failure routes. It supresses the rib-failure routes only if the next-hop of BGP rib-failure route is different from the next-hop of same route currently installed in the routing table."
I just wanted to know that, i didnt see the above point in any cisco doc. When i tested it in lab, the point was 100% correct. Can someone help me to find where this point is listed in cisco docs ? or any more insight about this particular behaviour.
thanks
Solved! Go to Solution.
11-04-2010 06:02 AM
Hello!
The intention of the suppress-inactive command is indeed to advertise rib-failure routes only when IGP and BGP nexthop are matching.
And it is also true that the command reference is not very explicit about this.
If you are looking for a more 'official' statement regarding this command, you can refer to the release notes of the following bug, which was actually fixing
a problem where rib-failure routes with BGP and IGP nexthop mismatch were still advertised:
CSCdx26714
Symptom :
If the prefix get Rib-Failre when installing into bgp table because of
there is already has a prefix in the routing table with a prefered admin
distance (like already learnd by ospf), then this prefix should not be
advertised to other bgp peers unless the next-hop is the same as the prefix
in the ip routing table.
But the behavior is that even if the next-hop is the same, this prefix still
does not advertise to it's bgp peers.
Regards,
Herve
11-04-2010 06:02 AM
Hello!
The intention of the suppress-inactive command is indeed to advertise rib-failure routes only when IGP and BGP nexthop are matching.
And it is also true that the command reference is not very explicit about this.
If you are looking for a more 'official' statement regarding this command, you can refer to the release notes of the following bug, which was actually fixing
a problem where rib-failure routes with BGP and IGP nexthop mismatch were still advertised:
CSCdx26714
Symptom :
If the prefix get Rib-Failre when installing into bgp table because of
there is already has a prefix in the routing table with a prefered admin
distance (like already learnd by ospf), then this prefix should not be
advertised to other bgp peers unless the next-hop is the same as the prefix
in the ip routing table.
But the behavior is that even if the next-hop is the same, this prefix still
does not advertise to it's bgp peers.
Regards,
Herve
11-04-2010 10:12 PM
Really really thanks alot !!!!
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