Routing redistribution

July 16, 2007 – 2:01 pm

I had a problem a little while ago with a customer who was using RIP between us and them. We’re redistributing RIP routes into BGP to be passed along internally. The problem was, a routing advertisement loop manifested itself. Dagnabbit! Took me a while to figure out what was going on. The symptom was that only about 10-20% of pings were succeeding. I then tracked it down to a route that was coming and going, its metric was winding up to 16 (RIP limit) then being discarded. To cut a long story short, what was happening was; A) a BGP route was advertised to one AS (lets call it 1 ) from another (lets call it 2). B) this route was then redist’d into RIP (for the customer device). C) another router in AS1 has an interface in the same subnet as the RIP advertisement. This router picks up the RIP route and dutifully pops it into BGP. D) the first router gets the route via BGP from the second router and there is the loop.


I had to figure out how to stop the route going around in the loop. In the end i settled on making RIP unicast. I put neighbor statements into the RIP config for each CPE device. This seemed to fix the problem. Later i discovered that i could filter the routes being advertised and learned, either based on tags applied when redistributing or based on a list of networks. I’m not sure what the best way is or the pros and cons of each. The RIP neighbor statements seem to be the easiest, just one line of config! I’m just worried I’ve missed something or there’s some gotcha. The tagging of routes when they’re redistributed from BGP to RIP and then filtering when redistributing from RIP to BGP seems to be the most comprehensive fix, but it is a lot of config. If unicast RIP is just as effective, then I’d rather use that. I like simple fixes. Comments?

  1. 2 Responses to “Routing redistribution”

  2. In the end after a bit of discussion I went with example two on this cisco page; tagging redistributed routes and then filtering based on the tag.

    By Daniel on Jul 16, 2007

  3. A solution I would use (because you have BGP) is tagging the routes inbound to hte BGP process so that you can always filter the routes.

    You have a route map attached to the redistribute statement so when the route comes in they are tagged with an arbitrary number. You then have a filter on the redist out that does not allow a route with that same tag to be sent back into the originating network.

    By Changing the Admin distances you will definitely solve the issue for now, however it may cause more issues in the future.

    By Ian on Jul 17, 2007

Post a Comment