Fix has been implemented and tested in two cases: 1. redistributing static routes to ospf4 and ospf6. 2. redistributing connected routes to ospf4 and ospf6.
In both two cases, the improper behavior was gone. So this is a generic fix not limited to specific protocol. Based on the current policy code architecture, I think this is a reasonably fix to the root cause. I attached the patch file here. Li --- On Fri, 12/18/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 18, 2009, 11:34 AM > There is a _currtag in the class > Configuration and this member _currtag was > passed down as a reference deep into class > SourceMatchCodeGenerator as a > pass-by value, but it was written back to the global > _currtag before the > SourceMatchCodegenerator instance died. So _currtag can > remeber. My proposed fix would be make _protocol_tags behave > similarly. Plus reverse the > order in which IvExec::runpolicy is traversing all > policies. > > --- On Thu, 12/17/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: Thursday, December 17, 2009, 4:50 PM > > Two problems: > > 1. in SourceMatchCodeGenerator::do_term, the _currtag > was > > inserted correctly into _protocol_tags, but in the > second > > time this do_term was called, the _protocol_tags was > > cleared even though > > _currtag was keeping the right value. So the protocol > set > > was not > > complete. > > 2. in IvExec::run, the order of policies in > _policies[] was > > oposite to the > > order in which code generator was writing policies > into > > lex/yacc parsed > > files. So it will always fail when sunset checking if > > number of policies > > are more than 1. > > > > These should be fixed. The second is easy, but the > first I > > can not trace > > who was bad guy. > > > > --- On Thu, 12/17/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: Thursday, December 17, 2009, 1:03 PM > > > Now I can understand that part. > > > Basically, the policy generates the code > whenever > > > new pilicy is exported. In the function > > > SourceMatchCodeGenerator::do_term, > > > action "<=" means "check that the route's tags > are > > > subset of this protocol tags". > > > I am even more closer to the root cause now. > Stay > > tuned. > > > > > > --- On Thu, 12/17/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: Thursday, December 17, 2009, 11:56 AM > > > > Li Zhao wrote: > > > > > Now can anybody tell me why tags are > > compared > > > when > > > > policy terms are processed? Because ospf4 > tag is > > > greater > > > > than ospf6 policy tag. That is why > > > > > ospf4 tag is left out? > > > > > > > > > > > > > I'm not a great expert on the policy code; > > Andrea > > > Bittau is > > > > the original author. He is sometimes around, > I > > would > > > try > > > > contacting him about the issue you've > found. > > > > > > > > Thanks for really drilling down into this > issue. > > I may > > > be > > > > able to pick up on it in the new year. > > > > > > > > regards, > > > > 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 >
redist.patch
Description: Binary data
_______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
