[Xorp-users] Route Redist between RIP and OSPF - working?

[David Davidson]

Thank you for your testing and your report. it seems to me that you did 
find something anomalous related to the OSPF export policies that seem 
to affect RIP routes. It seems like somebody should look into that a 
little further and maybe we could help to discover why that behavior is 
going on. I would be open to helping or testing if anyone wants more 
volunteers to try to get to the bottom of it.

Steve was right - connected routes aren't working in some cases also.

I finally did figure out a way to solve it, for this scenario. I still 
think that there is an issue because this was a little convoluted and 
this was very tricky and it seems like too much clever work for 
exporting routes.

The thing I noticed was this: I was able to export OSPF routes into RIP, 
and RIP routers would see those OSPF routes. I was also able to export 
RIP routes into OSPF, and the OSPF routers would correctly see those RIP 
routes.

What wasn't happening in this scenario was this problem: Routes that 
were learned via "CONNECTED" protocol were NOT necessarily injected back 
into either protocol on the OSPF side. For example, had I written the 
export policies like so:

Policy A (to be exported into the RIP domain):
1. if proto=connected then accept
2. if proto=ospf then accept

and:

Policy B (to be exported into the OSPF domain):
1. if proto=connected then accept
2. if proto=rip then accept

Policy "A" seemed to work fine on the RIP side in the RIP domain. I 
could see connected routes, and I could see OSPF routes. I still had to 
configure a "connected" policy on xorp3 (same with other vendors' RIP 
implementation so I am not worried about that).

But policy "B" did NOT work on the OSPF side. The connected routes would 
not propagate. For example, xorp1 could not see any route to 
192.168.40.0/24. Since eth1 on xorp1 was assigned 192.168.40.1/24, and 
this is a "connected" protocol, this policy B should have injected that 
route back into the OSPF domain, but it did not.

The way I solved this particular problem in the end was to for that 
interface into OSPF and then make it a passive interface. This forces 
xorp1 and xorp5 to learn about that network. This changes the "learning 
method" in that it becomes an OSPF interface (albeit, a passive one) and 
LSA's are forced back into the OSPF domain because it's part of the OSPF 
domain. When this worked, I decided to pull out the "if proto=connected" 
on the OSPF side since it didn't appear to be working anyway and all the 
routes were still good.

My final configurations are attached. Using the attachment, I was able 
to get certain and predictable converging of all routes, from every 
router. All routers could reach all destinations using these 
configurations. Again, this seems like too much clever work was needed 
in order to get this accomplished. I suspect something is anomalous 
because, like you mentioned, many of us are seeing this same kind of 
weirdness. Thank you again for your input.



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: steves_lab_on_xorp.txt
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120325/70e463ca/attachment.txt