Re: Am I running into a bug ? (3+ hours still no go on a 1 pt task)

could you post your configuration? there should not be any issues with
filtering the redistributed routes.

Petr Lapukhov

----- Original Message -----
From: "AC439"
Sent: Wed, June 17, 2009 20:31
Subject:[CCIE R&S] Am I running into a bug ? (3+ hours still no go on a 1
pt task)

I run into this problem that I suspect a bug. I'm doing a task in Vol3
Lab9 which
requires filtering out a default route generated by an OSPF router (R1)
from redis
into RIP on boundary routers (R4 & R5).

First I put a route-map to set the tag on R1 so when it generates the
default route,
it will be tagged. Then I went to R4 and R5, config route-map to do deny
10 for the
matching of this tag and permit 20 for everything else. Applied this
config under
RIP process using redis statement on both R4 and R5. The result is no
filtering at
all. It permits the default route as well as all other OSPF routes into
RIP. I did
sh ip route on R4 and confirmed I see a tag as expected. R5
learned about the default route from OSPF, then it changed to learn from
RIP in a
while and stays there. Definitely, the default route is leaked into RIP
on R4 then
passed on to R5 via RIP.

After some troubleshooting to no avail, I opened the SG. SG uses prefix
list to
catch the default route with route-map to block it with the redis
statement. So, I
thought, ok, I'll try it. I changed the config like the SG, and clear the
and ospf process etc. Same thing ! The default route still leaks into
RIP. I did
show route-map and show ip prefix-list and the output shows no matching.

So, puzzling still, I inserted a route-map statement deny 15 on both R4
and R5 to
see if my route-map is not working. Well, I was surprised to watch the
route still allowed while everything else was denied by line 15. So, this is
strange. Tried two different matching methods (tag and prefix-list) still
catch the default route.

IOS is 12.4-16a. Am I missing something simple ?

View this message online at:
Internetwork Expert - The Industry Leader in CCIE Preparation

Subscription information may be found at:

----- End of original message -----


  • Thanks Petr for your response.

    I went back to the lab and studied my config again.  To recap the topology, it is a mutual redis between OSPF and RIP on two ASBRs.  Router R1 in OSPF generates a default route into OSPF, which is not allowed to pass into RIP.

    My solution to the redis was to set the internal OSPF distance to a value lower than RIP and set the external OSPF distance to be higher than RIP (using the same logic as EIGRP).  Redis went fine and I don't have problems with reachability although some paths are probably not optimal.

    Upon injecting that default route from R1 (an OSPF router), definitely the default route has never been filtered by tagging, prefix-list or distribute-list on R4 or R5.  Debug ip rip shows the default route was passed by R4 to R5 even the default route on R4 is referred to as an OSPF route (O*E2).  I watched Brian's COD on redis multiple times and couldn't understand why RIP is picking an OSPF route and pass it on.

    So, anyway, I then followed the SG to change my redis from using plain splitted OSPF distance to route-map with tag filtering. I was still keeping the splitted OSPF INT/EXT distance though just to see what will happen.  Same problem !

    At last, by process of elimination and absolutely no more ideas to run, I went ahead and set the OSPF external distance to be the same as the internal distance and let the route-map/tagging takes care of the routing loop.  Then it works like a champ !

    It doesn't make sense but all is well now.  Maybe I have overlooked but I don't see anywhere mention that setting OSPF external distance to a different value than the internal distance will break filtering.  I still think I'm running into a bug.

    My original config is gone but now my config is the same as the SG.  If I put back a higher OSPF external distance, then it will break.

Sign In or Register to comment.