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

swdickey at rockwellcollins.com swdickey at rockwellcollins.com
Tue Apr 10 14:36:03 PDT 2012


This fixes my issue.

Thanks Igor and to the others who helped with this.

Steve



Igor Maravić <igorm at etf.rs> 
04/10/2012 08:57 AM
Please respond to
igorm at etf.rs


To
xorp-users at xorp.org, xorp-users at icir.org, xorp-hackers at icir.org
cc
swdickey at rockwellcollins.com, david at commroom.net
Subject
Route Redist between RIP and OSPF - working?






Hi all,
I think that I found solution to this problem :)

I started looking where Steve stopped
(PolicyRedistTable<A>::replace_policytags function).
It was just the tip of the iceberg.

Problem was that protocol's existing EXPORT_SOURCE match policies
weren't refreshed when new export filter is created.
In this case problem was with exporting to "connected" protocol.

New protocol always has accurate policy tags for route lookup. It
always searches routes that has no tag, or
older protocol tags or it's tags. If it finds them it prepends it's tag.
Older protocols are searching routes that has no tags, or have older
tags. If it finds such a route it prepends it's tag.

EXPORT_SOURCEMATCH policies are executed in order that depends on protocol 
name.
If newer protocol has lower letter (for example ospf's policies are
executed before rip's, because "o" precedes "r"),
new protocol prepends new tags, that are unrecognizable to older
protocol, to routes that it has found.
Because older protocol is unaware of new tags, it concludes that
routes are deleted and it deletes them.
This is not what we are expecting.

If older protocol is executed first, it prepends it's tag to routes
that it has found. Because old tag is recognizable by
newer protocol new tags are also prepended to routes. This case works
as expected.

Solution - refresh tags for all protocol's EXPORT_SOURCEMATCH routes
when new export filter is created.

I'm sending patch to xorp-hackers list.

I tested it for simple solutions, so it does need more testing :)

It would be nice if someone would post more complicated policies to
test this issue.

BR
Igor


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120410/ae99c394/attachment.html 


More information about the Xorp-users mailing list