[Xorp-hackers] ospf4 and ospf6 can not apply export policy at the same time

[Li Zhao]

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 <lizhaous2000 at yahoo.com> wrote:

> From: Li Zhao <lizhaous2000 at yahoo.com>
> Subject: Re: [Xorp-hackers] ospf4 and ospf6 can not apply export policy at the same time
> To: "Bruce Simpson" <bms at incunabulum.net>
> Cc: xorp-hackers at xorp.org
> 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 <lizhaous2000 at yahoo.com>
> wrote:
> 
> > From: Li Zhao <lizhaous2000 at yahoo.com>
> > Subject: Re: [Xorp-hackers] ospf4 and ospf6 can not
> apply export policy at the same time
> > To: "Bruce Simpson" <bms at incunabulum.net>
> > Cc: xorp-hackers at xorp.org
> > 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 <lizhaous2000 at yahoo.com>
> > wrote:
> > 
> > > From: Li Zhao <lizhaous2000 at yahoo.com>
> > > Subject: Re: [Xorp-hackers] ospf4 and ospf6 can
> not
> > apply export policy at the same time
> > > To: "Bruce Simpson" <bms at incunabulum.net>
> > > Cc: xorp-hackers at xorp.org
> > > 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 <bms at incunabulum.net>
> > > wrote:
> > > 
> > > > From: Bruce Simpson <bms at incunabulum.net>
> > > > Subject: Re: [Xorp-hackers] ospf4 and ospf6
> can
> > not
> > > apply export policy at the same time
> > > > To: "Li Zhao" <lizhaous2000 at yahoo.com>
> > > > Cc: xorp-hackers at xorp.org
> > > > 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
> > > Xorp-hackers at icir.org
> > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> > > 
> > 
> > 
> >       
> > 
> > _______________________________________________
> > Xorp-hackers mailing list
> > Xorp-hackers at icir.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> > 
> 
> 
>       
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: redist.patch
Type: application/octet-stream
Size: 7833 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20091218/e9b6ba1c/attachment.obj