From: Aaron K. Dixon (adixon@xxxxxxxxxxxxxxxxx)
Date: Thu Aug 10 2000 - 02:04:47 GMT-3
Look at your routing table and you will see the problem. RIP is advertising
a route of 4.0.0.0/8 which allows the BGP neighbors to establish because
they know of a route to 4.0.0.0. Once BGP is established the routes are
passed with the next-hop eBGP address. A recursive problem is now created
because BGP is advertising a more specific route of 4.4.4.0/24. If you do a
'show ip bgp 4.4.4.4' at this point you will probably see that 4.4.4.4 has a
next hop of 4.4.4.4.
This route now replaces the rip route and creates a recursive lookup
problem. Now for the router to get to it's neighbor 4.4.4.4 it will use the
more specific route which fails on the recursive lookup because it's
basically in the same subnet. This ultimately affects all BGP routes and
they will be dropped from the table due to an invalid next-hop. Then the
RIP route will take over and the whole process starts all over again.
The solution is to ensure that there is always a route to the BGP next-hop
that is not learned via BGP.
This is what I believe the problem is, but I'm going to set it up in my lab
and see if I can replicate the problem.
Regards,
Aaron K. Dixon
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:24:23 GMT-3