new updates: when I debug PolicyRedistTable<IPv4>::del_redist and PolicyRedistTable<IPv4>::add_redist in rib, I found that
if ospf6 exports "static-to-ospf", the ipv4 static route is removed from ospfv2, but added to ospfv3. This does not make sense to me. --- On Fri, 12/4/09, Li Zhao <[email protected]> wrote: > From: Li Zhao <[email protected]> > Subject: Re: [Xorp-hackers] ospf4 and ospf6 can not apply export policy at > the same time > To: "Bruce Simpson" <[email protected]> > Cc: [email protected] > Date: Friday, December 4, 2009, 2:20 PM > > Actually, I think the client might be rib: > PolicyRedistTable<IPv4>::del_redist. > > --- On Fri, 12/4/09, Li Zhao <[email protected]> > wrote: > > > From: Li Zhao <[email protected]> > > Subject: Re: [Xorp-hackers] ospf4 and ospf6 can not > apply export policy at the same time > > To: "Bruce Simpson" <[email protected]> > > Cc: [email protected] > > Date: Friday, December 4, 2009, 12:27 PM > > I am not quite familiar with xorp > > code. But based on my past experiences > > and common sense I am guessing ospf4 and ospf6 should > > register with > > policy/rib separately even though they can share the > same > > policy cli name. > > When I debug ospf4, I found > > policy_redist4_0_1_delete_route4 was called > > after I apply same policy to ospf6. I am tracing who > is the > > client side > > which might be policy. Another thing, if I > redistribute > > static to ospf4, but redistribute connected to ospf6, > then > > ospf6 won't collide with ospf4 > > and ospf4 looks fine. If i have same redistribute > same > > protocol no matter > > it is static or connected into ospf4 and ospf6, ospf4 > is > > always shaken > > down. > > > > --- On Fri, 12/4/09, Bruce Simpson <[email protected]> > > wrote: > > > > > From: Bruce Simpson <[email protected]> > > > Subject: Re: [Xorp-hackers] ospf4 and ospf6 can > not > > apply export policy at the same time > > > To: "Li Zhao" <[email protected]> > > > Cc: [email protected] > > > Date: Friday, December 4, 2009, 11:50 AM > > > Li Zhao wrote: > > > > I do not know how to report to Trac ticket > yet. > > But my > > > config is like this: > > > > > > > > 1. create a policy like "static-to-ospf" { > from > > { > > > protocol static} then { accept} }. > > > > > > > > 2. apply to ospf4 by " protocol ospf4 > export > > > static-ospf " I can use "show ospf4 database" > see > > these ipv4 > > > external LSAs related to ipv4 static routes. > > > > > > > > 3. then apply to ospf6 via "protocol ospf6 > 0 > > export > > > static-to-ospf", "show ospf6 database" looks > fine. But > > "show > > > ospf4 databse" will not show previous > > > > ipv4 extrenal LSAs, even if I use different > > policy > > > names that does not help. > > > > > > > > 4. if i remove policy from ospf6 "delete > > protocol > > > ospf6 export". The ipv4 external LSAs are > coiming > > back > > > automatically. > > > > > > > > I am going though the ospf and policy codes > to > > see > > > why? > > > > > > > > > > Thanks for digging into this. From what you've > > described, > > > it sounds like the issue may be in policy. > > > > > > Both ospf4 and ospf6 should register separate > origin > > tables > > > with the RIB process. These tables are > completely > > separate > > > (inside RIB, v6 and v4 are implemented as > separate > > instances > > > of Rib). > > > > > > Static routes, however, get redistributed via > policy. > > If > > > policy is using the same tag(s) to tell if/when > it > > already > > > did a redist, that is the most likely root > cause. > > > > > > cheers, > > > BMS > > > > > > > > > > > > > _______________________________________________ > > Xorp-hackers mailing list > > [email protected] > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > > > _______________________________________________ > Xorp-hackers mailing list > [email protected] > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
