From ar_djp at yahoo.com Fri Nov 10 00:26:47 2006 From: ar_djp at yahoo.com (ar) Date: Fri, 10 Nov 2006 00:26:47 -0800 (PST) Subject: [Xorp-hackers] XORP MPLS Implementation Message-ID: <20061110082647.62200.qmail@web90404.mail.mud.yahoo.com> Good day. Does XORP supports MPLS/VPN configurations based also on LDP? --------------------------------- Check out the all-new Yahoo! Mail - Fire up a more powerful email and get things done faster. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20061110/de852b19/attachment.html From ar_djp at yahoo.com Fri Nov 10 00:43:28 2006 From: ar_djp at yahoo.com (ar) Date: Fri, 10 Nov 2006 00:43:28 -0800 (PST) Subject: [Xorp-hackers] Xorp on Linux Message-ID: <20061110084328.29792.qmail@web90411.mail.mud.yahoo.com> can i install xorp on linux redhat 7.1 with 2.4.24 kernel? thanks..... --------------------------------- Sponsored Link Get an Online or Campus degree - Associate's, Bachelor's, or Master's - in less than one year. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20061110/08488d03/attachment.html From mhorn at vyatta.com Fri Nov 10 07:00:19 2006 From: mhorn at vyatta.com (Mike Horn) Date: Fri, 10 Nov 2006 08:00:19 -0700 Subject: [Xorp-hackers] [Xorp-users] XORP MPLS Implementation In-Reply-To: <20061110082647.62200.qmail@web90404.mail.mud.yahoo.com> Message-ID: <033a01c704d8$f0da3db0$0f02a8c0@caddisconsulting.com> Hi, XORP does not currently support any form of MPLS, including MPLS VPNs. -mike _____ From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of ar Sent: Friday, November 10, 2006 1:27 AM To: xorp-users at xorp.org; xorp-hackers at xorp.org Subject: [Xorp-users] XORP MPLS Implementation Good day. Does XORP supports MPLS/VPN configurations based also on LDP? _____ Check out the all-new Yahoo! Mail - Fire up a more powerful email and get things done faster. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20061110/d36c0879/attachment.html From pavlin at icir.org Fri Nov 10 09:25:28 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 10 Nov 2006 09:25:28 -0800 Subject: [Xorp-hackers] Xorp on Linux In-Reply-To: Message from ar of "Fri, 10 Nov 2006 00:43:28 PST." <20061110084328.29792.qmail@web90411.mail.mud.yahoo.com> Message-ID: <200611101725.kAAHPSRl070744@possum.icir.org> > can i install xorp on linux redhat 7.1 with 2.4.24 kernel? thanks..... We have tested it on RedHat-7.3 with kernel 2.4-20, so I guess it should work for your setup. If it doesn't, please send an email with the error. Regards, Pavlin From ar_djp at yahoo.com Fri Nov 10 19:43:51 2006 From: ar_djp at yahoo.com (ar) Date: Fri, 10 Nov 2006 19:43:51 -0800 (PST) Subject: [Xorp-hackers] Xorp on Linux In-Reply-To: <200611101725.kAAHPSRl070744@possum.icir.org> Message-ID: <20061111034351.89524.qmail@web90406.mail.mud.yahoo.com> alright thanks.... Pavlin Radoslavov wrote: > can i install xorp on linux redhat 7.1 with 2.4.24 kernel? thanks..... We have tested it on RedHat-7.3 with kernel 2.4-20, so I guess it should work for your setup. If it doesn't, please send an email with the error. Regards, Pavlin --------------------------------- Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20061110/49286350/attachment.html From ar_djp at yahoo.com Fri Nov 10 19:45:07 2006 From: ar_djp at yahoo.com (ar) Date: Fri, 10 Nov 2006 19:45:07 -0800 (PST) Subject: [Xorp-hackers] [Xorp-users] XORP MPLS Implementation In-Reply-To: <033a01c704d8$f0da3db0$0f02a8c0@caddisconsulting.com> Message-ID: <20061111034507.36404.qmail@web90404.mail.mud.yahoo.com> ok thanks..... Mike Horn wrote: Hi, XORP does not currently support any form of MPLS, including MPLS VPNs. -mike --------------------------------- From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of ar Sent: Friday, November 10, 2006 1:27 AM To: xorp-users at xorp.org; xorp-hackers at xorp.org Subject: [Xorp-users] XORP MPLS Implementation Good day. Does XORP supports MPLS/VPN configurations based also on LDP? --------------------------------- Check out the all-new Yahoo! Mail - Fire up a more powerful email and get things done faster. --------------------------------- Access over 1 million songs - Yahoo! Music Unlimited. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20061110/35341137/attachment.html From hasso at linux.ee Sat Nov 11 04:16:45 2006 From: hasso at linux.ee (Hasso Tepper) Date: Sat, 11 Nov 2006 14:16:45 +0200 Subject: [Xorp-hackers] Mercurial mirror of the XORP CVS repository Message-ID: <200611111416.46357.hasso@linux.ee> Due to moving inhouse development into Mercurial source control management system, I made upstream repository mirrors, which are managed by me, publicly available. This includes XORP CVS repository. Mirror is available at http://hg.estpak.ee/mirrors/xorp and is updated every three hours. For more info about Mercurial see http://www.selenic.com/mercurial/. Quickstart: hg clone http://hg.estpak.ee/mirrors/xorp regards, -- Hasso Tepper From ar_djp at yahoo.com Mon Nov 13 23:23:02 2006 From: ar_djp at yahoo.com (ar) Date: Mon, 13 Nov 2006 23:23:02 -0800 (PST) Subject: [Xorp-hackers] Does XORP Supports Multicast Routing? In-Reply-To: <200611101725.kAAHPSRl070744@possum.icir.org> Message-ID: <20061114072302.11867.qmail@web90402.mail.mud.yahoo.com> anyone tried using xorp for multicast routing? thanks --------------------------------- Sponsored Link For just $24.99/mo., Vonage offers unlimited local and long- distance calling. Sign up now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20061113/f08bf7e6/attachment.html From kristian at spritelink.se Mon Nov 13 23:51:50 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Tue, 14 Nov 2006 08:51:50 +0100 Subject: [Xorp-hackers] [Xorp-users] Does XORP Supports Multicast Routing? In-Reply-To: <20061114072302.11867.qmail@web90402.mail.mud.yahoo.com> References: <200611101725.kAAHPSRl070744@possum.icir.org> <20061114072302.11867.qmail@web90402.mail.mud.yahoo.com> Message-ID: <20061114075149.GB31500@spritelink.se> On Mon, Nov 13, 2006 at 11:23:02PM -0800, ar wrote: > anyone tried using xorp for multicast routing? thanks Yes and it's working just fine. There is quite a lot of documentation on the PIM part of XORP. -K -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From sureshkannan at gmail.com Tue Nov 14 00:07:03 2006 From: sureshkannan at gmail.com (Suresh kannan) Date: Tue, 14 Nov 2006 13:37:03 +0530 Subject: [Xorp-hackers] [Xorp-users] Does XORP Supports Multicast Routing? In-Reply-To: <20061114075149.GB31500@spritelink.se> References: <200611101725.kAAHPSRl070744@possum.icir.org> <20061114072302.11867.qmail@web90402.mail.mud.yahoo.com> <20061114075149.GB31500@spritelink.se> Message-ID: <84f679e0611140007lebff1aaocd85f269ecbc66e5@mail.gmail.com> Yep. I've not tried with multple topology and all.. but as far as i tried igmp,pim,ospf are working fine. On 11/14/06, Kristian Larsson wrote: > > On Mon, Nov 13, 2006 at 11:23:02PM -0800, ar wrote: > > anyone tried using xorp for multicast routing? thanks > Yes and it's working just fine. > > There is quite a lot of documentation on the PIM > part of XORP. > > -K > > -- > Kristian Larsson KLL-RIPE > Network Engineer Net at Once [AS35706] > +46 704 910401 kristian at spritelink.se > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20061114/dbf8d383/attachment.html From carlo.debonis at libero.it Tue Nov 14 00:08:24 2006 From: carlo.debonis at libero.it (carlo.debonis at libero.it) Date: Tue, 14 Nov 2006 09:08:24 +0100 Subject: [Xorp-hackers] OSPF's performance Message-ID: Are there experiment that evaluate the OSPF's performance (performs SPF or switching time)in XORP?thanks ------------------------------------------------------ Chi punta sull?inglese naturale Wall Street Institute, vince un English Box! Scopri come ritirare i tuoi premi, clicca qui! http://click.libero.it/wallstreet14nov From allan at vyatta.com Tue Nov 14 06:42:09 2006 From: allan at vyatta.com (Allan Leinwand) Date: Tue, 14 Nov 2006 06:42:09 -0800 (PST) Subject: [Xorp-hackers] OSPF's performance In-Reply-To: Message-ID: <1334271.5421163515329948.JavaMail.root@tahiti.vyatta.com> Hello Carlo, We worked with the XORP team to put the code through the University of New Hampshire Inter Operability Lab (UNH-IOL) for OSPF. There are not specific performance numbers in this third-party report, but there is a detailed report on the OSPF conformance and interoperability (two separate reports) found on our wiki: http://www.vyatta.com/twiki/bin/view/Community/UnhTestResults I hope ths is useful to you and if you do measure the OSPF SPF performance and switching time, please let us know the results. Thanks, Allan ----- Original Message ----- From: carlo debonis To: xorp-hackers Sent: Tuesday, November 14, 2006 0:08:24 AM GMT-0800 US/Pacific Subject: [Xorp-hackers] OSPF's performance Are there experiment that evaluate the OSPF's performance (performs SPF or switching time)in XORP?thanks ------------------------------------------------------ Chi punta sull?inglese naturale Wall Street Institute, vince un English Box! Scopri come ritirare i tuoi premi, clicca qui! http://click.libero.it/wallstreet14nov _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian at spritelink.se Tue Nov 14 15:04:56 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Wed, 15 Nov 2006 00:04:56 +0100 Subject: [Xorp-hackers] Rewrite of rtrmgr and xorpsh Message-ID: <20061114230455.GD31500@spritelink.se> I browsed the Bugzilla just now and saw #677 I'm a bit curious to where the limitations of the current rtrmgr and xorpsh lies? What great new features might one expect from this? :) This is rather nitpicky but there's one feature I'd like to see, not sure if it's in anyway related to #677 though, and that is to simply have a parameter set to true or false based on whether it's present or lacking in the configuration. like: interface fxp0 { vif fxp0 { disable; } } instead of disable = true/false. Last but not least, is this something high priority or something rather far down on the priority list? Cheers, Kristian. -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From mhorn at vyatta.com Tue Nov 14 16:37:31 2006 From: mhorn at vyatta.com (Mike Horn) Date: Tue, 14 Nov 2006 17:37:31 -0700 Subject: [Xorp-hackers] Policy network4 operator Message-ID: <032c01c7084e$3e73b470$0f02a8c0@caddisconsulting.com> > Hi all, > > Pavlin and I have been discussing what the "right" direction should be for > the network4 operator in policy statements. Right now if you specify > "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 and longer > prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > > My recommendation is to change the operator from "<=" matches longer > prefixes to ">=" matches longer prefixes, since this seems more intuitive > to me (/9 is > /8) and this would make it match the "prefix-length4" > operator where "prefix-length4 > 24" matches all prefixes longer than /24. > > Which do you prefer: > > A) keep it the way it is now, < matches longer prefixes > B) changing it to use > for longer prefix matches > > Btw, the bug on this is 358 > > http://www.xorp.org/bugzilla/show_bug.cgi?id=358 > > -mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20061114/673248da/attachment.html From pavlin at icir.org Tue Nov 14 17:11:55 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 14 Nov 2006 17:11:55 -0800 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: Message from "Mike Horn" of "Tue, 14 Nov 2006 17:37:31 MST." <032c01c7084e$3e73b470$0f02a8c0@caddisconsulting.com> Message-ID: <200611150111.kAF1Bts6023718@possum.icir.org> > > Pavlin and I have been discussing what the "right" direction should be for > > the network4 operator in policy statements. Right now if you specify > > "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 and longer > > prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > > > > My recommendation is to change the operator from "<=" matches longer > > prefixes to ">=" matches longer prefixes, since this seems more intuitive > > to me (/9 is > /8) and this would make it match the "prefix-length4" > > operator where "prefix-length4 > 24" matches all prefixes longer than /24. > > > > Which do you prefer: > > > > A) keep it the way it is now, < matches longer prefixes > > B) changing it to use > for longer prefix matches The reason I prefer (A) is because my interpretation of the "<=" operator in the context of network prefixes is "subset". E.g., my interpretation of "network4 <= 10.0.0.0/8" is: "Network that is a subset of 10.0.0.0/8." Another interpretation that I found useful and is also consistent with the "<=" direction is: "Network that overlaps with 10.0.0.0/8 and has same as or fewer addresses than 10.0.0.0/8." The whole issue comes down to the meaning of "<=, <, >, >=" within the context of network prefixes. Your interpretation is integer comparison of the corresponding network prefix lengths, while my interpretation is subset/superset relation of the network prefixes themselves. Thanks, Pavlin > > Btw, the bug on this is 358 > > > > http://www.xorp.org/bugzilla/show_bug.cgi?id=358 > > > > -mike > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From robert at vyatta.com Tue Nov 14 17:13:04 2006 From: robert at vyatta.com (Robert Bays) Date: Tue, 14 Nov 2006 17:13:04 -0800 Subject: [Xorp-hackers] Policy network4 operator In-Reply-To: <032c01c7084e$3e73b470$0f02a8c0@caddisconsulting.com> References: <032c01c7084e$3e73b470$0f02a8c0@caddisconsulting.com> Message-ID: <455A69A0.4050509@vyatta.com> Maybe it makes more sense to use Juniper terminology; exact, longer, orlonger, through, upto... Short of that, I prefer option B. Cheers, Robert. Mike Horn wrote: > Hi all, > > Pavlin and I have been discussing what the "right" direction should be > for the network4 operator in policy statements. Right now if you > specify "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 and > longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > > My recommendation is to change the operator from "<=" matches longer > prefixes to ">=" matches longer prefixes, since this seems more > intuitive to me (/9 is > /8) and this would make it match the > "prefix-length4" operator where "prefix-length4 > 24" matches all > prefixes longer than /24. > > Which do you prefer: > > A) keep it the way it is now, < matches longer prefixes > B) changing it to use > for longer prefix matches > > Btw, the bug on this is 358 > > _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ > > -mike > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian at spritelink.se Tue Nov 14 23:27:08 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Wed, 15 Nov 2006 08:27:08 +0100 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: <455A69A0.4050509@vyatta.com> References: <032c01c7084e$3e73b470$0f02a8c0@caddisconsulting.com> <455A69A0.4050509@vyatta.com> Message-ID: <20061115072707.GE31500@spritelink.se> I think Roberts idea is just great, why not copy Juniper terminology. We already got a Juniper lookalike shell. And just as robert.. I'd go with option B if I had to choose between the two. -K On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote: > Maybe it makes more sense to use Juniper terminology; exact, longer, > orlonger, through, upto... > > Short of that, I prefer option B. > > Cheers, > Robert. > > Mike Horn wrote: > > Hi all, > > > > Pavlin and I have been discussing what the "right" direction should be > > for the network4 operator in policy statements. Right now if you > > specify "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 and > > longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > > > > My recommendation is to change the operator from "<=" matches longer > > prefixes to ">=" matches longer prefixes, since this seems more > > intuitive to me (/9 is > /8) and this would make it match the > > "prefix-length4" operator where "prefix-length4 > 24" matches all > > prefixes longer than /24. > > > > Which do you prefer: > > > > A) keep it the way it is now, < matches longer prefixes > > B) changing it to use > for longer prefix matches > > > > Btw, the bug on this is 358 > > > > _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ > > > > -mike > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From dave at vyatta.com Wed Nov 15 09:45:43 2006 From: dave at vyatta.com (Dave Roberts) Date: Wed, 15 Nov 2006 09:45:43 -0800 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: <20061115072707.GE31500@spritelink.se> References: <032c01c7084e$3e73b470$0f02a8c0@caddisconsulting.com> <455A69A0.4050509@vyatta.com> <20061115072707.GE31500@spritelink.se> Message-ID: <455B5247.9050304@vyatta.com> Being a product manager at heart, my advice would be to follow industry conventions here. The fact is, the industry has already solved this problem and there are certain expectations of operating behavior and terminology that router users already have. So why reinvent the wheel? Violating the norms of the vast majority of users just seems senseless. My conclusion is that Robert's suggestion of adopting Juniper terminology and behavior seems like a no-brainer. Failing that, look at what Cisco does and base something off that. But whatever you do, don't go inventing new terminology and behavior without a *STRONG* reason for doing so; all you will do is end up confusing the vast majority of users that are schooled on existing products. Complex router configurations are difficult enough to get debugged and working without users having to remember that XORP is the one router on the planet that does something needlessly different. -- Dave Kristian Larsson wrote: > I think Roberts idea is just great, why not copy > Juniper terminology. We already got a Juniper > lookalike shell. > > And just as robert.. I'd go with option B if I had > to choose between the two. > > -K > > On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote: >> Maybe it makes more sense to use Juniper terminology; exact, longer, >> orlonger, through, upto... >> >> Short of that, I prefer option B. >> >> Cheers, >> Robert. >> >> Mike Horn wrote: >>> Hi all, >>> >>> Pavlin and I have been discussing what the "right" direction should be >>> for the network4 operator in policy statements. Right now if you >>> specify "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 and >>> longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). >>> >>> My recommendation is to change the operator from "<=" matches longer >>> prefixes to ">=" matches longer prefixes, since this seems more >>> intuitive to me (/9 is > /8) and this would make it match the >>> "prefix-length4" operator where "prefix-length4 > 24" matches all >>> prefixes longer than /24. >>> >>> Which do you prefer: >>> >>> A) keep it the way it is now, < matches longer prefixes >>> B) changing it to use > for longer prefix matches >>> >>> Btw, the bug on this is 358 >>> >>> _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ >>> >>> -mike >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Xorp-hackers mailing list >>> Xorp-hackers at icir.org >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From pavlin at icir.org Thu Nov 16 11:44:57 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 16 Nov 2006 11:44:57 -0800 Subject: [Xorp-hackers] Rewrite of rtrmgr and xorpsh In-Reply-To: Message from Kristian Larsson of "Wed, 15 Nov 2006 00:04:56 +0100." <20061114230455.GD31500@spritelink.se> Message-ID: <200611161944.kAGJivua051095@possum.icir.org> > I browsed the Bugzilla just now and saw #677 > I'm a bit curious to where the limitations of the > current rtrmgr and xorpsh lies? They are not maintainable. > What great new features might one expect from this? > :) None. The purpose of the rewrite is to have simple and clean implementation. > This is rather nitpicky but there's one feature > I'd like to see, not sure if it's in anyway > related to #677 though, and that is to simply have > a parameter set to true or false based on whether > it's present or lacking in the configuration. > > like: > interface fxp0 { > vif fxp0 { > disable; > } > } > > instead of disable = true/false. Please add this request to the bugzilla entry. If the new implementation is simple and clean enough, it _might_ be easier to add later features like this, but don't count on that. > Last but not least, is this something high > priority or something rather far down on the > priority list? It is very low priority, and it might never happen, because most likely it would have to be done in some spare cycles. Regards, Pavlin > Cheers, > Kristian. > > -- > Kristian Larsson KLL-RIPE > Network Engineer Net at Once [AS35706] > +46 704 910401 kristian at spritelink.se > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at icir.org Thu Nov 16 16:58:41 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 16 Nov 2006 16:58:41 -0800 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: Message from Dave Roberts of "Wed, 15 Nov 2006 09:45:43 PST." <455B5247.9050304@vyatta.com> Message-ID: <200611170058.kAH0wfAi054219@possum.icir.org> Dave Roberts wrote: > Being a product manager at heart, my advice would be to follow industry > conventions here. The fact is, the industry has already solved this > problem and there are certain expectations of operating behavior and > terminology that router users already have. So why reinvent the wheel? > Violating the norms of the vast majority of users just seems senseless. > > My conclusion is that Robert's suggestion of adopting Juniper > terminology and behavior seems like a no-brainer. Failing that, look at > what Cisco does and base something off that. But whatever you do, don't > go inventing new terminology and behavior without a *STRONG* reason for > doing so; all you will do is end up confusing the vast majority of users > that are schooled on existing products. Complex router configurations > are difficult enough to get debugged and working without users having to > remember that XORP is the one router on the planet that does something > needlessly different. In an ideal world we can change any of the configuration semantics in any way we like so we won't be having this discussion. About the suggestion to follow what other have done. Syntax-wise, even Cisco and Juniper are doing things very differently, so there is no universal solution that we can just reuse. I checked the Cisco documentation online about the relevant policy semantics, and the closest I found is along the lines: ============================================================= Cisco IOS IP Command Reference, Volume 2 of 4: Routing Protocols Release 12.3 T http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a008017d02f.html and Routing Policy Language Commands on Cisco IOS XR Software http://www.cisco.com/en/US/products/ps5763/products_command_reference_chapter09186a00803b0e1b.html Some examples from the first document are: To accept a mask length of up to 24 bits in routes with the prefix 192/8: ip prefix-list abc permit 192.168.0.0/8 le 24 To deny mask lengths greater than 25 bits in routes with a prefix of 192/8: ip prefix-list abc deny 192.168.0.0/8 ge 25 To permit mask lengths from 8 to 24 bits in all address space: ip prefix-list abc permit 0.0.0.0/0 ge 8 le 24 To deny mask lengths greater than 25 bits in all address space: ip prefix-list abc deny 0.0.0.0/0 ge 25 To deny all routes with a prefix of 10/8: ip prefix-list abc deny 10.0.0.0/8 le 32 ============================================================= As you can see, the syntax is very different from XORP, the "ge | le" arguments are of different type (network mask length), etc, so we cannot reuse or adapt this. The Juniper syntax for network address matching is like: route-filter 192.168.0.0/16 exact; route-filter 192.168.0.0/16 longer; route-filter 192.168.0.0/16 orlonger; route-filter 192.168.0.0/16 upto /24 reject; route-filter 192.168.0.0/16 through 192.168.16.0/20; route-filter 192.168.0.0/16 prefix-length-range /26-/30 reject; Futhermore, Juniper allows you to have more than one route-filter statement per block. Our rtrmgr simply cannot be modified to support syntax like this. If we ever rewrite the rtrmgr (see Bugzilla entry #677), then there is some chance it might be easier to extend it with some of this syntax, but for now this is just not an option. The best we could do is to take the exact/longer/orlonger keywords from the first three examples, and support them similar to the existing comparison operators: "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" Note that the last three keywords (shorter/orshorter/not) don't exist in Juniper, so feel free to suggest better names. And, no, the rtrmgr template syntax doesn't allow us to have the tokens ordered same like in Juniper: "network4 10.0.0.0/8 exact". Have in mind that even such change is going to be very ugly (we need to add hacks to the rtrmgr AND the policy manager), and there is no guarantee it will actually work properly before we actually try it. Any other syntax changes are just no-starters with what we have now. About the suggestion of changing the direction of the "<=" operator: if you think that the current direction is wrong (which I strongly disagree with) or confusing, then just changing the direction is going to be ever more confusing, so this shouldn't be an option. To summarize, here are the choices I see: (1) Do nothing and use the current "<=" and friends syntax. (2) Add the hack for the "exact/longer/orlonger..." support as in the examples given above. If anyone has any other suggestions, please be very specific (and realistic) with examples what the syntax should look like, rather than being vague with "follow vendor FOO". Pavlin > -- Dave > > Kristian Larsson wrote: > > I think Roberts idea is just great, why not copy > > Juniper terminology. We already got a Juniper > > lookalike shell. > > > > And just as robert.. I'd go with option B if I had > > to choose between the two. > > > > -K > > > > On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote: > >> Maybe it makes more sense to use Juniper terminology; exact, longer, > >> orlonger, through, upto... > >> > >> Short of that, I prefer option B. > >> > >> Cheers, > >> Robert. > >> > >> Mike Horn wrote: > >>> Hi all, > >>> > >>> Pavlin and I have been discussing what the "right" direction should be > >>> for the network4 operator in policy statements. Right now if you > >>> specify "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 and > >>> longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > >>> > >>> My recommendation is to change the operator from "<=" matches longer > >>> prefixes to ">=" matches longer prefixes, since this seems more > >>> intuitive to me (/9 is > /8) and this would make it match the > >>> "prefix-length4" operator where "prefix-length4 > 24" matches all > >>> prefixes longer than /24. > >>> > >>> Which do you prefer: > >>> > >>> A) keep it the way it is now, < matches longer prefixes > >>> B) changing it to use > for longer prefix matches > >>> > >>> Btw, the bug on this is 358 > >>> > >>> _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ > >>> > >>> -mike > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> Xorp-hackers mailing list > >>> Xorp-hackers at icir.org > >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > >> _______________________________________________ > >> Xorp-users mailing list > >> Xorp-users at xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From mhorn at vyatta.com Thu Nov 16 17:26:40 2006 From: mhorn at vyatta.com (Mike Horn) Date: Thu, 16 Nov 2006 18:26:40 -0700 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: <200611170058.kAH0wfAi054219@possum.icir.org> Message-ID: <00d401c709e7$6f5bc8d0$0f02a8c0@caddisconsulting.com> Hi Pavlin, I agree, Cisco and Juniper syntax are very different, and there really isn't an "industry standard". You only listed the following options: (1) Do nothing and use the current "<=" and friends syntax. (2) Add the hack for the "exact/longer/orlonger..." support as in the examples given above. Isn't another option to flip the meaning of the sign? In which case > would mean longer prefixes, so network4 > 10.0.0.0/8 would be any 10.X prefixes with a prefix length longer than 8. This would be aligned with Cisco's use of "ge" and "le" and seems like from the limited responses to be everyone's preference. What do you think about using this as an interim approach? -mike -----Original Message----- From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Pavlin Radoslavov Sent: Thursday, November 16, 2006 5:59 PM To: Dave Roberts Cc: xorp-users at xorp.org; Robert Bays; Kristian Larsson; mhorn at vyatta.com; xorp-hackers at xorp.org Subject: Re: [Xorp-hackers] [Xorp-users] Policy network4 operator Dave Roberts wrote: > Being a product manager at heart, my advice would be to follow > industry conventions here. The fact is, the industry has already > solved this problem and there are certain expectations of operating > behavior and terminology that router users already have. So why reinvent the wheel? > Violating the norms of the vast majority of users just seems senseless. > > My conclusion is that Robert's suggestion of adopting Juniper > terminology and behavior seems like a no-brainer. Failing that, look > at what Cisco does and base something off that. But whatever you do, > don't go inventing new terminology and behavior without a *STRONG* > reason for doing so; all you will do is end up confusing the vast > majority of users that are schooled on existing products. Complex > router configurations are difficult enough to get debugged and working > without users having to remember that XORP is the one router on the > planet that does something needlessly different. In an ideal world we can change any of the configuration semantics in any way we like so we won't be having this discussion. About the suggestion to follow what other have done. Syntax-wise, even Cisco and Juniper are doing things very differently, so there is no universal solution that we can just reuse. I checked the Cisco documentation online about the relevant policy semantics, and the closest I found is along the lines: ============================================================= Cisco IOS IP Command Reference, Volume 2 of 4: Routing Protocols Release 12.3 T http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_refe rence_chapter09186a008017d02f.html and Routing Policy Language Commands on Cisco IOS XR Software http://www.cisco.com/en/US/products/ps5763/products_command_reference_chapte r09186a00803b0e1b.html Some examples from the first document are: To accept a mask length of up to 24 bits in routes with the prefix 192/8: ip prefix-list abc permit 192.168.0.0/8 le 24 To deny mask lengths greater than 25 bits in routes with a prefix of 192/8: ip prefix-list abc deny 192.168.0.0/8 ge 25 To permit mask lengths from 8 to 24 bits in all address space: ip prefix-list abc permit 0.0.0.0/0 ge 8 le 24 To deny mask lengths greater than 25 bits in all address space: ip prefix-list abc deny 0.0.0.0/0 ge 25 To deny all routes with a prefix of 10/8: ip prefix-list abc deny 10.0.0.0/8 le 32 ============================================================= As you can see, the syntax is very different from XORP, the "ge | le" arguments are of different type (network mask length), etc, so we cannot reuse or adapt this. The Juniper syntax for network address matching is like: route-filter 192.168.0.0/16 exact; route-filter 192.168.0.0/16 longer; route-filter 192.168.0.0/16 orlonger; route-filter 192.168.0.0/16 upto /24 reject; route-filter 192.168.0.0/16 through 192.168.16.0/20; route-filter 192.168.0.0/16 prefix-length-range /26-/30 reject; Futhermore, Juniper allows you to have more than one route-filter statement per block. Our rtrmgr simply cannot be modified to support syntax like this. If we ever rewrite the rtrmgr (see Bugzilla entry #677), then there is some chance it might be easier to extend it with some of this syntax, but for now this is just not an option. The best we could do is to take the exact/longer/orlonger keywords from the first three examples, and support them similar to the existing comparison operators: "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" Note that the last three keywords (shorter/orshorter/not) don't exist in Juniper, so feel free to suggest better names. And, no, the rtrmgr template syntax doesn't allow us to have the tokens ordered same like in Juniper: "network4 10.0.0.0/8 exact". Have in mind that even such change is going to be very ugly (we need to add hacks to the rtrmgr AND the policy manager), and there is no guarantee it will actually work properly before we actually try it. Any other syntax changes are just no-starters with what we have now. About the suggestion of changing the direction of the "<=" operator: if you think that the current direction is wrong (which I strongly disagree with) or confusing, then just changing the direction is going to be ever more confusing, so this shouldn't be an option. To summarize, here are the choices I see: (1) Do nothing and use the current "<=" and friends syntax. (2) Add the hack for the "exact/longer/orlonger..." support as in the examples given above. If anyone has any other suggestions, please be very specific (and realistic) with examples what the syntax should look like, rather than being vague with "follow vendor FOO". Pavlin > -- Dave > > Kristian Larsson wrote: > > I think Roberts idea is just great, why not copy > > Juniper terminology. We already got a Juniper > > lookalike shell. > > > > And just as robert.. I'd go with option B if I had > > to choose between the two. > > > > -K > > > > On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote: > >> Maybe it makes more sense to use Juniper terminology; exact, longer, > >> orlonger, through, upto... > >> > >> Short of that, I prefer option B. > >> > >> Cheers, > >> Robert. > >> > >> Mike Horn wrote: > >>> Hi all, > >>> > >>> Pavlin and I have been discussing what the "right" direction should be > >>> for the network4 operator in policy statements. Right now if you > >>> specify "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 and > >>> longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > >>> > >>> My recommendation is to change the operator from "<=" matches longer > >>> prefixes to ">=" matches longer prefixes, since this seems more > >>> intuitive to me (/9 is > /8) and this would make it match the > >>> "prefix-length4" operator where "prefix-length4 > 24" matches all > >>> prefixes longer than /24. > >>> > >>> Which do you prefer: > >>> > >>> A) keep it the way it is now, < matches longer prefixes > >>> B) changing it to use > for longer prefix matches > >>> > >>> Btw, the bug on this is 358 > >>> > >>> _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ > >>> > >>> -mike > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> Xorp-hackers mailing list > >>> Xorp-hackers at icir.org > >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > >> _______________________________________________ > >> Xorp-users mailing list > >> Xorp-users at xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > _______________________________________________ > 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 From mhorn at vyatta.com Thu Nov 16 17:31:43 2006 From: mhorn at vyatta.com (Mike Horn) Date: Thu, 16 Nov 2006 18:31:43 -0700 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: <00d401c709e7$6f5bc8d0$0f02a8c0@caddisconsulting.com> Message-ID: <00d601c709e8$23a00220$0f02a8c0@caddisconsulting.com> Hi, Sorry to respond to my own message, I didn't see the section where Pavlin strongly disagrees with flipping the sign, but I think it's the right thing to do (IMHO). -mike -----Original Message----- From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Mike Horn Sent: Thursday, November 16, 2006 6:27 PM To: 'Pavlin Radoslavov' Cc: xorp-users at xorp.org; xorp-hackers at xorp.org Subject: Re: [Xorp-hackers] [Xorp-users] Policy network4 operator Hi Pavlin, I agree, Cisco and Juniper syntax are very different, and there really isn't an "industry standard". You only listed the following options: (1) Do nothing and use the current "<=" and friends syntax. (2) Add the hack for the "exact/longer/orlonger..." support as in the examples given above. Isn't another option to flip the meaning of the sign? In which case > would mean longer prefixes, so network4 > 10.0.0.0/8 would be any 10.X prefixes with a prefix length longer than 8. This would be aligned with Cisco's use of "ge" and "le" and seems like from the limited responses to be everyone's preference. What do you think about using this as an interim approach? -mike -----Original Message----- From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Pavlin Radoslavov Sent: Thursday, November 16, 2006 5:59 PM To: Dave Roberts Cc: xorp-users at xorp.org; Robert Bays; Kristian Larsson; mhorn at vyatta.com; xorp-hackers at xorp.org Subject: Re: [Xorp-hackers] [Xorp-users] Policy network4 operator Dave Roberts wrote: > Being a product manager at heart, my advice would be to follow > industry conventions here. The fact is, the industry has already > solved this problem and there are certain expectations of operating > behavior and terminology that router users already have. So why > reinvent the wheel? > Violating the norms of the vast majority of users just seems senseless. > > My conclusion is that Robert's suggestion of adopting Juniper > terminology and behavior seems like a no-brainer. Failing that, look > at what Cisco does and base something off that. But whatever you do, > don't go inventing new terminology and behavior without a *STRONG* > reason for doing so; all you will do is end up confusing the vast > majority of users that are schooled on existing products. Complex > router configurations are difficult enough to get debugged and working > without users having to remember that XORP is the one router on the > planet that does something needlessly different. In an ideal world we can change any of the configuration semantics in any way we like so we won't be having this discussion. About the suggestion to follow what other have done. Syntax-wise, even Cisco and Juniper are doing things very differently, so there is no universal solution that we can just reuse. I checked the Cisco documentation online about the relevant policy semantics, and the closest I found is along the lines: ============================================================= Cisco IOS IP Command Reference, Volume 2 of 4: Routing Protocols Release 12.3 T http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_refe rence_chapter09186a008017d02f.html and Routing Policy Language Commands on Cisco IOS XR Software http://www.cisco.com/en/US/products/ps5763/products_command_reference_chapte r09186a00803b0e1b.html Some examples from the first document are: To accept a mask length of up to 24 bits in routes with the prefix 192/8: ip prefix-list abc permit 192.168.0.0/8 le 24 To deny mask lengths greater than 25 bits in routes with a prefix of 192/8: ip prefix-list abc deny 192.168.0.0/8 ge 25 To permit mask lengths from 8 to 24 bits in all address space: ip prefix-list abc permit 0.0.0.0/0 ge 8 le 24 To deny mask lengths greater than 25 bits in all address space: ip prefix-list abc deny 0.0.0.0/0 ge 25 To deny all routes with a prefix of 10/8: ip prefix-list abc deny 10.0.0.0/8 le 32 ============================================================= As you can see, the syntax is very different from XORP, the "ge | le" arguments are of different type (network mask length), etc, so we cannot reuse or adapt this. The Juniper syntax for network address matching is like: route-filter 192.168.0.0/16 exact; route-filter 192.168.0.0/16 longer; route-filter 192.168.0.0/16 orlonger; route-filter 192.168.0.0/16 upto /24 reject; route-filter 192.168.0.0/16 through 192.168.16.0/20; route-filter 192.168.0.0/16 prefix-length-range /26-/30 reject; Futhermore, Juniper allows you to have more than one route-filter statement per block. Our rtrmgr simply cannot be modified to support syntax like this. If we ever rewrite the rtrmgr (see Bugzilla entry #677), then there is some chance it might be easier to extend it with some of this syntax, but for now this is just not an option. The best we could do is to take the exact/longer/orlonger keywords from the first three examples, and support them similar to the existing comparison operators: "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" Note that the last three keywords (shorter/orshorter/not) don't exist in Juniper, so feel free to suggest better names. And, no, the rtrmgr template syntax doesn't allow us to have the tokens ordered same like in Juniper: "network4 10.0.0.0/8 exact". Have in mind that even such change is going to be very ugly (we need to add hacks to the rtrmgr AND the policy manager), and there is no guarantee it will actually work properly before we actually try it. Any other syntax changes are just no-starters with what we have now. About the suggestion of changing the direction of the "<=" operator: if you think that the current direction is wrong (which I strongly disagree with) or confusing, then just changing the direction is going to be ever more confusing, so this shouldn't be an option. To summarize, here are the choices I see: (1) Do nothing and use the current "<=" and friends syntax. (2) Add the hack for the "exact/longer/orlonger..." support as in the examples given above. If anyone has any other suggestions, please be very specific (and realistic) with examples what the syntax should look like, rather than being vague with "follow vendor FOO". Pavlin > -- Dave > > Kristian Larsson wrote: > > I think Roberts idea is just great, why not copy Juniper > > terminology. We already got a Juniper lookalike shell. > > > > And just as robert.. I'd go with option B if I had to choose between > > the two. > > > > -K > > > > On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote: > >> Maybe it makes more sense to use Juniper terminology; exact, > >> longer, orlonger, through, upto... > >> > >> Short of that, I prefer option B. > >> > >> Cheers, > >> Robert. > >> > >> Mike Horn wrote: > >>> Hi all, > >>> > >>> Pavlin and I have been discussing what the "right" direction > >>> should be for the network4 operator in policy statements. Right > >>> now if you specify "network4 <= 10.0.0.0/8" this would match all > >>> the 10.0.0.0/8 and > >>> longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > >>> > >>> My recommendation is to change the operator from "<=" matches > >>> longer prefixes to ">=" matches longer prefixes, since this seems > >>> more intuitive to me (/9 is > /8) and this would make it match the > >>> "prefix-length4" operator where "prefix-length4 > 24" matches all > >>> prefixes longer than /24. > >>> > >>> Which do you prefer: > >>> > >>> A) keep it the way it is now, < matches longer prefixes > >>> B) changing it to use > for longer prefix matches > >>> > >>> Btw, the bug on this is 358 > >>> > >>> _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ > >>> > >>> -mike > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> Xorp-hackers mailing list > >>> Xorp-hackers at icir.org > >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > >> _______________________________________________ > >> Xorp-users mailing list > >> Xorp-users at xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > _______________________________________________ > 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 From pavlin at icir.org Thu Nov 16 17:32:26 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 16 Nov 2006 17:32:26 -0800 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: Message from "Mike Horn" of "Thu, 16 Nov 2006 18:26:40 MST." <00d401c709e7$6f5bc8d0$0f02a8c0@caddisconsulting.com> Message-ID: <200611170132.kAH1WQ1k054688@possum.icir.org> > I agree, Cisco and Juniper syntax are very different, and there really isn't > an "industry standard". You only listed the following options: > > (1) Do nothing and use the current "<=" and friends syntax. > (2) Add the hack for the "exact/longer/orlonger..." support as in > the examples given above. > > Isn't another option to flip the meaning of the sign? In which case > would > mean longer prefixes, so network4 > 10.0.0.0/8 would be any 10.X prefixes > with a prefix length longer than 8. This would be aligned with Cisco's use > of "ge" and "le" and seems like from the limited responses to be everyone's > preference. > > What do you think about using this as an interim approach? I think I already wrote a paragraph about this in my previous email. And, no, it won't be aligned with Cisco's use of "ge" and "le", because they are using "ge" and "le" to compare network mask length (the argument is an integer) while we are using ">=" and "<=" to compare network addresses. Pavlin > -mike > > -----Original Message----- > From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] > On Behalf Of Pavlin Radoslavov > Sent: Thursday, November 16, 2006 5:59 PM > To: Dave Roberts > Cc: xorp-users at xorp.org; Robert Bays; Kristian Larsson; mhorn at vyatta.com; > xorp-hackers at xorp.org > Subject: Re: [Xorp-hackers] [Xorp-users] Policy network4 operator > > Dave Roberts wrote: > > > Being a product manager at heart, my advice would be to follow > > industry conventions here. The fact is, the industry has already > > solved this problem and there are certain expectations of operating > > behavior and terminology that router users already have. So why reinvent > the wheel? > > Violating the norms of the vast majority of users just seems senseless. > > > > My conclusion is that Robert's suggestion of adopting Juniper > > terminology and behavior seems like a no-brainer. Failing that, look > > at what Cisco does and base something off that. But whatever you do, > > don't go inventing new terminology and behavior without a *STRONG* > > reason for doing so; all you will do is end up confusing the vast > > majority of users that are schooled on existing products. Complex > > router configurations are difficult enough to get debugged and working > > without users having to remember that XORP is the one router on the > > planet that does something needlessly different. > > In an ideal world we can change any of the configuration semantics in any > way we like so we won't be having this discussion. > > > About the suggestion to follow what other have done. > Syntax-wise, even Cisco and Juniper are doing things very differently, so > there is no universal solution that we can just reuse. > > I checked the Cisco documentation online about the relevant policy > semantics, and the closest I found is along the lines: > > ============================================================= > Cisco IOS IP Command Reference, > Volume 2 of 4: Routing Protocols > Release 12.3 T > > http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_refe > rence_chapter09186a008017d02f.html > > and > > Routing Policy Language Commands on Cisco IOS XR Software > http://www.cisco.com/en/US/products/ps5763/products_command_reference_chapte > r09186a00803b0e1b.html > > Some examples from the first document are: > > To accept a mask length of up to 24 bits in routes with the prefix > 192/8: > ip prefix-list abc permit 192.168.0.0/8 le 24 To deny mask lengths greater > than 25 bits in routes with a prefix of > 192/8: > ip prefix-list abc deny 192.168.0.0/8 ge 25 To permit mask lengths from 8 to > 24 bits in all address space: > ip prefix-list abc permit 0.0.0.0/0 ge 8 le 24 To deny mask lengths greater > than 25 bits in all address space: > ip prefix-list abc deny 0.0.0.0/0 ge 25 > To deny all routes with a prefix of 10/8: > ip prefix-list abc deny 10.0.0.0/8 le 32 > > ============================================================= > > As you can see, the syntax is very different from XORP, the "ge | le" > arguments are of different type (network mask length), etc, so we cannot > reuse or adapt this. > > > The Juniper syntax for network address matching is like: > > route-filter 192.168.0.0/16 exact; > route-filter 192.168.0.0/16 longer; > route-filter 192.168.0.0/16 orlonger; > route-filter 192.168.0.0/16 upto /24 reject; > route-filter 192.168.0.0/16 through 192.168.16.0/20; > route-filter 192.168.0.0/16 prefix-length-range /26-/30 reject; > > Futhermore, Juniper allows you to have more than one route-filter > statement per block. > > Our rtrmgr simply cannot be modified to support syntax like this. > If we ever rewrite the rtrmgr (see Bugzilla entry #677), then there > is some chance it might be easier to extend it with some of this > syntax, but for now this is just not an option. > > The best we could do is to take the exact/longer/orlonger keywords > from the first three examples, and support them similar to the > existing comparison operators: > > "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" > "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" > "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" > > Note that the last three keywords (shorter/orshorter/not) don't > exist in Juniper, so feel free to suggest better names. > And, no, the rtrmgr template syntax doesn't allow us to have the > tokens ordered same like in Juniper: "network4 10.0.0.0/8 exact". > > Have in mind that even such change is going to be very ugly (we need > to add hacks to the rtrmgr AND the policy manager), and there is no > guarantee it will actually work properly before we actually try it. > Any other syntax changes are just no-starters with what we have now. > > About the suggestion of changing the direction of the "<=" operator: > if you think that the current direction is wrong (which I strongly > disagree with) or confusing, then just changing the direction is > going to be ever more confusing, so this shouldn't be an option. > > To summarize, here are the choices I see: > > (1) Do nothing and use the current "<=" and friends syntax. > (2) Add the hack for the "exact/longer/orlonger..." support as in > the examples given above. > > If anyone has any other suggestions, please be very specific (and > realistic) with examples what the syntax should look like, rather > than being vague with "follow vendor FOO". > > Pavlin > > > > -- Dave > > > > Kristian Larsson wrote: > > > I think Roberts idea is just great, why not copy > > > Juniper terminology. We already got a Juniper > > > lookalike shell. > > > > > > And just as robert.. I'd go with option B if I had > > > to choose between the two. > > > > > > -K > > > > > > On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote: > > >> Maybe it makes more sense to use Juniper terminology; exact, longer, > > >> orlonger, through, upto... > > >> > > >> Short of that, I prefer option B. > > >> > > >> Cheers, > > >> Robert. > > >> > > >> Mike Horn wrote: > > >>> Hi all, > > >>> > > >>> Pavlin and I have been discussing what the "right" direction should be > > >>> for the network4 operator in policy statements. Right now if you > > >>> specify "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 > and > > >>> longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > > >>> > > >>> My recommendation is to change the operator from "<=" matches longer > > >>> prefixes to ">=" matches longer prefixes, since this seems more > > >>> intuitive to me (/9 is > /8) and this would make it match the > > >>> "prefix-length4" operator where "prefix-length4 > 24" matches all > > >>> prefixes longer than /24. > > >>> > > >>> Which do you prefer: > > >>> > > >>> A) keep it the way it is now, < matches longer prefixes > > >>> B) changing it to use > for longer prefix matches > > >>> > > >>> Btw, the bug on this is 358 > > >>> > > >>> _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ > > >>> > > >>> -mike > > >>> > > >>> > > >>> > ------------------------------------------------------------------------ > > >>> > > >>> _______________________________________________ > > >>> Xorp-hackers mailing list > > >>> Xorp-hackers at icir.org > > >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > >> _______________________________________________ > > >> Xorp-users mailing list > > >> Xorp-users at xorp.org > > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > > > > _______________________________________________ > > 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 From mhorn at vyatta.com Thu Nov 16 17:53:18 2006 From: mhorn at vyatta.com (Mike Horn) Date: Thu, 16 Nov 2006 18:53:18 -0700 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: <200611170132.kAH1WQ1k054688@possum.icir.org> Message-ID: <00d701c709eb$276e40d0$0f02a8c0@caddisconsulting.com> Hi Pavlin, Sorry I missed it originally, see my last email ;-) Obviously we both have strong opinions about which sign direction is "right". If people continue to vote in favor of flipping the sign behavior, would you be willing to consider changing the behavior? Btw, I think the right long term answer is to use something similar to the Juniper syntax, which removes any potential for ambiguity. -mike -----Original Message----- From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Pavlin Radoslavov Sent: Thursday, November 16, 2006 6:32 PM To: mhorn at vyatta.com Cc: xorp-users at xorp.org; xorp-hackers at xorp.org; 'Pavlin Radoslavov' Subject: Re: [Xorp-users] [Xorp-hackers] Policy network4 operator > I agree, Cisco and Juniper syntax are very different, and there really > isn't an "industry standard". You only listed the following options: > > (1) Do nothing and use the current "<=" and friends syntax. > (2) Add the hack for the "exact/longer/orlonger..." support as in > the examples given above. > > Isn't another option to flip the meaning of the sign? In which case > > would mean longer prefixes, so network4 > 10.0.0.0/8 would be any 10.X > prefixes with a prefix length longer than 8. This would be aligned > with Cisco's use of "ge" and "le" and seems like from the limited > responses to be everyone's preference. > > What do you think about using this as an interim approach? I think I already wrote a paragraph about this in my previous email. And, no, it won't be aligned with Cisco's use of "ge" and "le", because they are using "ge" and "le" to compare network mask length (the argument is an integer) while we are using ">=" and "<=" to compare network addresses. Pavlin > -mike > > -----Original Message----- > From: xorp-hackers-bounces at icir.org > [mailto:xorp-hackers-bounces at icir.org] > On Behalf Of Pavlin Radoslavov > Sent: Thursday, November 16, 2006 5:59 PM > To: Dave Roberts > Cc: xorp-users at xorp.org; Robert Bays; Kristian Larsson; > mhorn at vyatta.com; xorp-hackers at xorp.org > Subject: Re: [Xorp-hackers] [Xorp-users] Policy network4 operator > > Dave Roberts wrote: > > > Being a product manager at heart, my advice would be to follow > > industry conventions here. The fact is, the industry has already > > solved this problem and there are certain expectations of operating > > behavior and terminology that router users already have. So why > > reinvent > the wheel? > > Violating the norms of the vast majority of users just seems senseless. > > > > My conclusion is that Robert's suggestion of adopting Juniper > > terminology and behavior seems like a no-brainer. Failing that, look > > at what Cisco does and base something off that. But whatever you do, > > don't go inventing new terminology and behavior without a *STRONG* > > reason for doing so; all you will do is end up confusing the vast > > majority of users that are schooled on existing products. Complex > > router configurations are difficult enough to get debugged and > > working without users having to remember that XORP is the one router > > on the planet that does something needlessly different. > > In an ideal world we can change any of the configuration semantics in > any way we like so we won't be having this discussion. > > > About the suggestion to follow what other have done. > Syntax-wise, even Cisco and Juniper are doing things very differently, > so there is no universal solution that we can just reuse. > > I checked the Cisco documentation online about the relevant policy > semantics, and the closest I found is along the lines: > > ============================================================= > Cisco IOS IP Command Reference, > Volume 2 of 4: Routing Protocols > Release 12.3 T > > http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_comman > d_refe > rence_chapter09186a008017d02f.html > > and > > Routing Policy Language Commands on Cisco IOS XR Software > http://www.cisco.com/en/US/products/ps5763/products_command_reference_ > chapte > r09186a00803b0e1b.html > > Some examples from the first document are: > > To accept a mask length of up to 24 bits in routes with the prefix > 192/8: > ip prefix-list abc permit 192.168.0.0/8 le 24 To deny mask lengths > greater than 25 bits in routes with a prefix of > 192/8: > ip prefix-list abc deny 192.168.0.0/8 ge 25 To permit mask lengths > from 8 to > 24 bits in all address space: > ip prefix-list abc permit 0.0.0.0/0 ge 8 le 24 To deny mask lengths > greater than 25 bits in all address space: > ip prefix-list abc deny 0.0.0.0/0 ge 25 To deny all routes with a > prefix of 10/8: > ip prefix-list abc deny 10.0.0.0/8 le 32 > > ============================================================= > > As you can see, the syntax is very different from XORP, the "ge | le" > arguments are of different type (network mask length), etc, so we > cannot reuse or adapt this. > > > The Juniper syntax for network address matching is like: > > route-filter 192.168.0.0/16 exact; > route-filter 192.168.0.0/16 longer; > route-filter 192.168.0.0/16 orlonger; > route-filter 192.168.0.0/16 upto /24 reject; route-filter > 192.168.0.0/16 through 192.168.16.0/20; route-filter 192.168.0.0/16 > prefix-length-range /26-/30 reject; > > Futhermore, Juniper allows you to have more than one route-filter > statement per block. > > Our rtrmgr simply cannot be modified to support syntax like this. > If we ever rewrite the rtrmgr (see Bugzilla entry #677), then there is > some chance it might be easier to extend it with some of this syntax, > but for now this is just not an option. > > The best we could do is to take the exact/longer/orlonger keywords > from the first three examples, and support them similar to the > existing comparison operators: > > "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" > "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" > "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" > > Note that the last three keywords (shorter/orshorter/not) don't exist > in Juniper, so feel free to suggest better names. > And, no, the rtrmgr template syntax doesn't allow us to have the > tokens ordered same like in Juniper: "network4 10.0.0.0/8 exact". > > Have in mind that even such change is going to be very ugly (we need > to add hacks to the rtrmgr AND the policy manager), and there is no > guarantee it will actually work properly before we actually try it. > Any other syntax changes are just no-starters with what we have now. > > About the suggestion of changing the direction of the "<=" operator: > if you think that the current direction is wrong (which I strongly > disagree with) or confusing, then just changing the direction is going > to be ever more confusing, so this shouldn't be an option. > > To summarize, here are the choices I see: > > (1) Do nothing and use the current "<=" and friends syntax. > (2) Add the hack for the "exact/longer/orlonger..." support as in > the examples given above. > > If anyone has any other suggestions, please be very specific (and > realistic) with examples what the syntax should look like, rather than > being vague with "follow vendor FOO". > > Pavlin > > > > -- Dave > > > > Kristian Larsson wrote: > > > I think Roberts idea is just great, why not copy Juniper > > > terminology. We already got a Juniper lookalike shell. > > > > > > And just as robert.. I'd go with option B if I had to choose > > > between the two. > > > > > > -K > > > > > > On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote: > > >> Maybe it makes more sense to use Juniper terminology; exact, > > >> longer, orlonger, through, upto... > > >> > > >> Short of that, I prefer option B. > > >> > > >> Cheers, > > >> Robert. > > >> > > >> Mike Horn wrote: > > >>> Hi all, > > >>> > > >>> Pavlin and I have been discussing what the "right" direction > > >>> should be for the network4 operator in policy statements. Right > > >>> now if you specify "network4 <= 10.0.0.0/8" this would match all > > >>> the 10.0.0.0/8 > and > > >>> longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > > >>> > > >>> My recommendation is to change the operator from "<=" matches > > >>> longer prefixes to ">=" matches longer prefixes, since this > > >>> seems more intuitive to me (/9 is > /8) and this would make it > > >>> match the "prefix-length4" operator where "prefix-length4 > 24" > > >>> matches all prefixes longer than /24. > > >>> > > >>> Which do you prefer: > > >>> > > >>> A) keep it the way it is now, < matches longer prefixes > > >>> B) changing it to use > for longer prefix matches > > >>> > > >>> Btw, the bug on this is 358 > > >>> > > >>> _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ > > >>> > > >>> -mike > > >>> > > >>> > > >>> > ---------------------------------------------------------------------- > -- > > >>> > > >>> _______________________________________________ > > >>> Xorp-hackers mailing list > > >>> Xorp-hackers at icir.org > > >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > >> _______________________________________________ > > >> Xorp-users mailing list > > >> Xorp-users at xorp.org > > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > > > > _______________________________________________ > > 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 _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From edrt at citiz.net Thu Nov 16 18:14:14 2006 From: edrt at citiz.net (edrt) Date: Fri, 17 Nov 2006 10:14:14 +0800 Subject: [Xorp-hackers] Rewrite of rtrmgr and xorpsh Message-ID: <200611170215.kAH2Firs031105@pork.ICSI.Berkeley.EDU> >> I browsed the Bugzilla just now and saw #677 >> I'm a bit curious to where the limitations of the >> current rtrmgr and xorpsh lies? > >They are not maintainable. > >> What great new features might one expect from this? >> :) > >None. >The purpose of the rewrite is to have simple and clean >implementation. > Good news, seems I'll get the last chance to understand this part of code :) From hasso at linux.ee Fri Nov 17 03:34:11 2006 From: hasso at linux.ee (Hasso Tepper) Date: Fri, 17 Nov 2006 13:34:11 +0200 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: <200611170058.kAH0wfAi054219@possum.icir.org> References: <200611170058.kAH0wfAi054219@possum.icir.org> Message-ID: <200611171334.11390.hasso@linux.ee> Pavlin Radoslavov wrote: > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" [snip] > Note that the last three keywords (shorter/orshorter/not) don't > exist in Juniper, so feel free to suggest better names. What networks you'd expect to match these conditions? Ok, 10.0.0.0/8 would match "orshorter" but point being ... ? regards, -- Hasso Tepper Elion Enterprises Ltd. [AS3249] Data Communication Network Administrator From zec at icir.org Fri Nov 17 03:47:57 2006 From: zec at icir.org (Marko Zec) Date: Fri, 17 Nov 2006 12:47:57 +0100 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: <200611171334.11390.hasso@linux.ee> References: <200611170058.kAH0wfAi054219@possum.icir.org> <200611171334.11390.hasso@linux.ee> Message-ID: <200611171247.57660.zec@icir.org> On Friday 17 November 2006 12:34, Hasso Tepper wrote: > Pavlin Radoslavov wrote: > > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > > [snip] > > > Note that the last three keywords (shorter/orshorter/not) don't > > exist in Juniper, so feel free to suggest better names. > > What networks you'd expect to match these conditions? Ok, 10.0.0.0/8 would > match "orshorter" but point being ... ? Perhaps we should consider alternatives to "shorter/longer" terminology here, maybe something like "network4 includes 10.0.0.0/8" or "network4 is_included_in 10.0.0.0/8", with the "strictly_" modifier for current "<" and ">" operators? Or perhaps "covers" / "covered_by" -> native English speakers should do better at picking the right term... Marko From kristian at spritelink.se Fri Nov 17 04:09:32 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Fri, 17 Nov 2006 13:09:32 +0100 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: <200611171334.11390.hasso@linux.ee> References: <200611170058.kAH0wfAi054219@possum.icir.org> <200611171334.11390.hasso@linux.ee> Message-ID: <20061117120931.GJ31500@spritelink.se> On Fri, Nov 17, 2006 at 01:34:11PM +0200, Hasso Tepper wrote: > Pavlin Radoslavov wrote: > > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > > [snip] > > > Note that the last three keywords (shorter/orshorter/not) don't > > exist in Juniper, so feel free to suggest better names. > > What networks you'd expect to match these conditions? Ok, 10.0.0.0/8 would > match "orshorter" but point being ... ? I've been wondering over the same thing Would the following expressions do the same thing? cisco: ip prefix-list standard FOO deny 10.0.0.0/8 le 32 ip prefix-list standard FOO permit 0.0.0.0/0 xorp: network-list BAR { permit orshorter 10.0.0.0/8; } -K -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From mhorn at vyatta.com Fri Nov 17 06:53:25 2006 From: mhorn at vyatta.com (Mike Horn) Date: Fri, 17 Nov 2006 07:53:25 -0700 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: <200611171247.57660.zec@icir.org> Message-ID: <014401c70a58$22b2a000$0f02a8c0@caddisconsulting.com> Hi Marko, I really think that if XORP moves to using terminology, the terms should be something similar to Juniper's "exact, orlonger, etc.". IMHO this makes the most sense 1) because the xorpsh is similar in style to Juniper's so it would be consistent and 2)it seems to be the most intuitive of the ideas I have heard so far. Like Hasso, I'm also confused by what networks the "shorter" or current modifiers ">, >=" would match. -mike -----Original Message----- From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Marko Zec Sent: Friday, November 17, 2006 4:48 AM To: xorp-hackers at icir.org Cc: xorp-users at xorp.org; Hasso Tepper; Pavlin Radoslavov Subject: Re: [Xorp-users] [Xorp-hackers] Policy network4 operator On Friday 17 November 2006 12:34, Hasso Tepper wrote: > Pavlin Radoslavov wrote: > > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > > [snip] > > > Note that the last three keywords (shorter/orshorter/not) don't > > exist in Juniper, so feel free to suggest better names. > > What networks you'd expect to match these conditions? Ok, 10.0.0.0/8 > would match "orshorter" but point being ... ? Perhaps we should consider alternatives to "shorter/longer" terminology here, maybe something like "network4 includes 10.0.0.0/8" or "network4 is_included_in 10.0.0.0/8", with the "strictly_" modifier for current "<" and ">" operators? Or perhaps "covers" / "covered_by" -> native English speakers should do better at picking the right term... Marko _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Fri Nov 17 11:18:36 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 17 Nov 2006 11:18:36 -0800 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: Message from "Mike Horn" of "Thu, 16 Nov 2006 18:53:18 MST." <00d701c709eb$276e40d0$0f02a8c0@caddisconsulting.com> Message-ID: <200611171918.kAHJIavB064219@possum.icir.org> > Sorry I missed it originally, see my last email ;-) Obviously we both have > strong opinions about which sign direction is "right". If people continue > to vote in favor of flipping the sign behavior, would you be willing to > consider changing the behavior? No, because all mathematicians in the world will scream at me! :) Seriously, though, is it only the person who originally implemented this feature in XORP (Andrea and probably later updated by Marko?), Atanu and me who think that comparing network addresses indeed means comparing network addresses? It doesn't seem we are getting anywhere closer on agreeing what the sign direction should be. So the only remaining (short-term) option we have so far is to try to implement the Juniper-like keywords: "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" > Btw, I think the right long term answer is to use something similar to the > Juniper syntax, which removes any potential for ambiguity. I agree about the long-term solution. The question is what to do about it in short and medium term time scale. Pavlin From pavlin at icir.org Fri Nov 17 13:12:02 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 17 Nov 2006 13:12:02 -0800 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: Message from Hasso Tepper of "Fri, 17 Nov 2006 13:34:11 +0200." <200611171334.11390.hasso@linux.ee> Message-ID: <200611172112.kAHLC2dn065397@possum.icir.org> > > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > > [snip] > > > Note that the last three keywords (shorter/orshorter/not) don't > > exist in Juniper, so feel free to suggest better names. > > What networks you'd expect to match these conditions? Ok, 10.0.0.0/8 would > match "orshorter" but point being ... ? I don't understand your question. Are you asking me to explain how the above two operators work, or are you asking why someone wants to use them? If it is the former: Recall that currently "network4 <= 10.0.0.0/8" means all networks that are SUBSETS of 10.0.0.0/8 (i.e., that are contained by 10.0.0.0/8). Those are 10.0.0.0/8, 10.0.0.0/9, 10.128.0.0/9, and so on. The ">=" operator is just the opposite: "network4 >= 10.0.0.0/8" means all networks that are SUPERSETS of 10.0.0.0/8 (i.e., that contain 10.0.0.0/8). Those are 10.0.0.0/8, 10.0.0.0/7, 8.0.0.0/6, 8.0.0.0/5, 0.0.0.0/4, ... 0.0.0.0/0. The ">" operator is similar to the ">=" except that the 10.0.0.0/8 network itself is excluded (i.e., this is a strict superset). Here is another explanation in term of the proposed "orshorter/orlonger" keywords: The "orshorter" keyword is just the opposite of "orlonger": with "orlonger" the prefix length can be longer (8, 9, 10, ...), while with "orshorter" the prefix length can be shorter (8, 7, 6, ...). If it is the latter: I cannot give you a real-world example when exactly you need them, but they are there to complement the traditionally used longer prefix matching rules. Pavlin From pavlin at icir.org Fri Nov 17 13:46:29 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 17 Nov 2006 13:46:29 -0800 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: Message from Kristian Larsson of "Fri, 17 Nov 2006 13:09:32 +0100." <20061117120931.GJ31500@spritelink.se> Message-ID: <200611172146.kAHLkTnI065737@possum.icir.org> Kristian Larsson wrote: > On Fri, Nov 17, 2006 at 01:34:11PM +0200, Hasso Tepper wrote: > > Pavlin Radoslavov wrote: > > > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > > > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > > > > [snip] > > > > > Note that the last three keywords (shorter/orshorter/not) don't > > > exist in Juniper, so feel free to suggest better names. > > > > What networks you'd expect to match these conditions? Ok, 10.0.0.0/8 would > > match "orshorter" but point being ... ? > I've been wondering over the same thing > > Would the following expressions do the same thing? > cisco: > ip prefix-list standard FOO deny 10.0.0.0/8 le 32 > ip prefix-list standard FOO permit 0.0.0.0/0 > > xorp: > network-list BAR { > permit orshorter 10.0.0.0/8; > } I believe the answer is no, because the second Cisco rule will permit only the default route 0.0.0.0/0 (please correct me if my limited knowledge of Cisco commands is wrong here). The equivalent XORP-like rule (which BTW is not valid configuration) will match the following routes: 10.0.0.0/8, 10.0.0.0/7, 8.0.0.0/6, 8.0.0.0/5, 0.0.0.0/4, 0.0.0.0/3, 0.0.0.0/2, 0.0.0.0/1, 0.0.0.0/0. Pavlin From jfletcher at vyatta.com Fri Nov 17 13:45:22 2006 From: jfletcher at vyatta.com (Justin Fletcher) Date: Fri, 17 Nov 2006 13:45:22 -0800 (PST) Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: <200611171918.kAHJIavB064219@possum.icir.org> Message-ID: <29350240.19511163799922176.JavaMail.root@tahiti.vyatta.com> > Seriously, though, is it only the person who originally implemented > this feature in XORP (Andrea and probably later updated by Marko?), > Atanu and me who think that comparing network addresses indeed means > comparing network addresses? Maybe :-) The operators seem reverse to the last time I implemented it, and the way I'm used to it in a Cisco notation. Justin From kristian at spritelink.se Sat Nov 18 01:35:43 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Sat, 18 Nov 2006 10:35:43 +0100 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: <200611172146.kAHLkTnI065737@possum.icir.org> References: <20061117120931.GJ31500@spritelink.se> <200611172146.kAHLkTnI065737@possum.icir.org> Message-ID: <20061118093543.GK31500@spritelink.se> On Fri, Nov 17, 2006 at 01:46:29PM -0800, Pavlin Radoslavov wrote: > Kristian Larsson wrote: > > > On Fri, Nov 17, 2006 at 01:34:11PM +0200, Hasso Tepper wrote: > > > Pavlin Radoslavov wrote: > > > > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > > > > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > > > > > > [snip] > > > > > > > Note that the last three keywords (shorter/orshorter/not) don't > > > > exist in Juniper, so feel free to suggest better names. > > > > > > What networks you'd expect to match these conditions? Ok, 10.0.0.0/8 would > > > match "orshorter" but point being ... ? > > I've been wondering over the same thing > > > > Would the following expressions do the same thing? > > cisco: > > ip prefix-list standard FOO deny 10.0.0.0/8 le 32 > > ip prefix-list standard FOO permit 0.0.0.0/0 > > > > xorp: > > network-list BAR { > > permit orshorter 10.0.0.0/8; > > } > > I believe the answer is no, because the second Cisco rule will > permit only the default route 0.0.0.0/0 (please correct me if my > limited knowledge of Cisco commands is wrong here). You are correct, however 0.0.0.0/0 le 32 was what I meant. Nevertheless, I understand what shorter does now.. :) > The equivalent XORP-like rule (which BTW is not valid configuration) > will match the following routes: > 10.0.0.0/8, 10.0.0.0/7, 8.0.0.0/6, 8.0.0.0/5, 0.0.0.0/4, 0.0.0.0/3, > 0.0.0.0/2, 0.0.0.0/1, 0.0.0.0/0. Think of it as XORP pseudo code ;) I'm not as used to XORP so I can't write config from heart. Kristian. -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From santhosh at ku.edu Sat Nov 18 19:29:12 2006 From: santhosh at ku.edu (Santhosh Sundararaman) Date: Sat, 18 Nov 2006 21:29:12 -0600 Subject: [Xorp-hackers] network4 operator - seems to have no effect on bgp import policy. In-Reply-To: <200611170132.kAH1WQ1k054688@possum.icir.org> References: <200611170132.kAH1WQ1k054688@possum.icir.org> Message-ID: <455FCF88.7000305@ku.edu> Hi all, I have been trying to use a policy with the network4 operator to reject a particular prefix (192.168.61.0/24), but the prefix keeps showing up in the bgp route table. here is the bgp and policy configuarion. protocols { bgp { bgp-id: 10.15.16.4 local-as: 65000 import: "policy_dummy1" peer 10.10.11.2 { /*Testbed110*/ local-ip: 10.11.15.3 as: 65000 next-hop: 10.11.15.3 holdtime: 120 ipv4-unicast: true } } policy { policy-statement "policy_dummy1" { term "dummy1-term" { from { network4: 192.168.61.0/24 } then { trace: 1 reject } } } } I added trace to see if the route was getting rejected. The trace messages in the xorp_rtrmgr showed that the prefix 192.168.61.0/24 was being rejected. [ 2006/11/18 21:09:18 TRACE xorp_bgp POLICY ] Policy filter result: BGP Import route: 192.168.61.0/24: rejected [ 2006/11/18 21:09:18 TRACE xorp_bgp POLICY ] Policy filter result: BGP Import route: 192.168.62.0/24: default action [ 2006/11/18 21:09:18 TRACE xorp_bgp POLICY ] Policy filter result: BGP Import route: 192.168.63.0/24: default action But when i checked the bgp route table from the xorpsh, the prefix 192.168.61.0/24 was still showing up, as shown below. santhosh at testbed115.ittc.ku.edu> show bgp routes Status Codes: * valid route, > best route Origin Codes: i IGP, e EGP, ? incomplete Prefix Nexthop Peer AS Path ------ ------- ---- ------- * 192.168.61.0/24 172.16.10.1 172.16.10.3 65002 65006 e *> 192.168.62.0/24 172.16.10.1 172.16.10.3 65002 65006 e *> 192.168.63.0/24 172.16.10.1 172.16.10.3 65002 65006 e It seems to appear that the the route entry for the prefix 192.168.61.0/24 is not the best route for the prefix, as show by the absence of ">" before the prefix. But if the route is rejected during import itself, shouldn't it not appear in the bgp route table, instead of it appearing and not being chosen. I might be missing something or possibly misinterpreting something, could someone help me understand whats happening. Thanks Santhosh From hasso at linux.ee Sun Nov 19 03:08:11 2006 From: hasso at linux.ee (Hasso Tepper) Date: Sun, 19 Nov 2006 13:08:11 +0200 Subject: [Xorp-hackers] Rewrite of rtrmgr and xorpsh In-Reply-To: <20061114230455.GD31500@spritelink.se> References: <20061114230455.GD31500@spritelink.se> Message-ID: <200611191308.11809.hasso@linux.ee> Kristian Larsson wrote: > interface fxp0 { > vif fxp0 { > disable; > } > } > > instead of disable = true/false. Idea itself is good of course, but example is bad. There is much cleaner and better way to implement the disable feature - "deactivate" keyword is the key. Without clutter of CLI, without any support from protocol modules etc. you will get this functionality automatically for every node - for multinodes and leaf nodes as well. Anyway, I took some time and wrote down my thoughts regarding XORP you (all readers of the list) may find interesting - it covers this as well. http://hasso.linux.ee/doku.php/english:network:xorpsucks regards, -- Hasso Tepper Elion Enterprises Ltd. [AS3249] Data Communication Network Administrator From kristian at spritelink.se Sun Nov 19 04:10:29 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Sun, 19 Nov 2006 13:10:29 +0100 Subject: [Xorp-hackers] Rewrite of rtrmgr and xorpsh In-Reply-To: <200611191308.11809.hasso@linux.ee> References: <20061114230455.GD31500@spritelink.se> <200611191308.11809.hasso@linux.ee> Message-ID: <20061119121029.GA7246@spritelink.se> On Sun, Nov 19, 2006 at 01:08:11PM +0200, Hasso Tepper wrote: > Kristian Larsson wrote: > > interface fxp0 { > > vif fxp0 { > > disable; > > } > > } > > > > instead of disable = true/false. > > Idea itself is good of course, but example is bad. There is much cleaner > and better way to implement the disable feature - "deactivate" keyword is > the key. Without clutter of CLI, without any support from protocol > modules etc. you will get this functionality automatically for every > node - for multinodes and leaf nodes as well. You're right and I've already added this to the BugZilla a long time ago (#331). And as you know, I wasn't trying to show how the disable keyword should work but rather point out that there should be "leaf nodes without values". > Anyway, I took some time and wrote down my thoughts regarding XORP you > (all readers of the list) may find interesting - it covers this as well. > > http://hasso.linux.ee/doku.php/english:network:xorpsucks Interesting read. As I wouldn't dare call myself a developer I haven't looked at XORP from that perspective. Reading your paper however, I realize you pinpoint the faults that I just couldn't quite get a grip on. Leafnodes without value being just one example. I find XORP terrible to work with, there are not a lot of "show" commands and those available generally lack in information or formatting (see the BGP show command improvement bug #217 for an example). You're job overloading route and a few other commands improved a lot but there's still plenty left. I've been looking forward to the coding of the IS-IS module in XORP, but I've realized that I don't even use the BGP part because I think the policy language is just horrible and so I would probably end up not using the ISIS part either. You're probably right in that XORP needs to revamp it's core so that more external developers will help out doing those small improvements that XORP needs to become that nice routing suite we all want. Kristian. -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From pavlin at icir.org Mon Nov 20 11:45:00 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 20 Nov 2006 11:45:00 -0800 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: Message from Justin Fletcher of "Fri, 17 Nov 2006 13:45:22 PST." <29350240.19511163799922176.JavaMail.root@tahiti.vyatta.com> Message-ID: <200611201945.kAKJj0nC008991@possum.icir.org> > > Seriously, though, is it only the person who originally implemented > > this feature in XORP (Andrea and probably later updated by Marko?), > > Atanu and me who think that comparing network addresses indeed means > > comparing network addresses? > > Maybe :-) The operators seem reverse to the last time I implemented it, > and the way I'm used to it in a Cisco notation. Again, as I mentioned earlier, the Cisco notation reasoning doesn't apply here. In Cisco, the comparison is network address vs. prefix length. In our case we have network address vs. network address. This thread is getting too long, so let me repeat again my question about the short/medium term solution. If you can't accept the current behavior, would you like us to invest some time trying to implement the Juniper-like keywords: "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" If yes, then please indicate whether we should use the "shorter/orshorter/not" keywords or something else. If you prefer a different solution, now is the time to suggest it (flipping the operator direction excluded). If there are no replies, then probably nothing will change until the rtrmgr is reimplemented (bug #677) and we are in the position to implement the long-term solution. Pavlin From kristian at spritelink.se Mon Nov 20 12:53:17 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Mon, 20 Nov 2006 21:53:17 +0100 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: <200611201945.kAKJj0nC008991@possum.icir.org> References: <29350240.19511163799922176.JavaMail.root@tahiti.vyatta.com> <200611201945.kAKJj0nC008991@possum.icir.org> Message-ID: <20061120205316.GE7246@spritelink.se> On Mon, Nov 20, 2006 at 11:45:00AM -0800, Pavlin Radoslavov wrote: > > > Seriously, though, is it only the person who originally implemented > > > this feature in XORP (Andrea and probably later updated by Marko?), > > > Atanu and me who think that comparing network addresses indeed means > > > comparing network addresses? > > > > Maybe :-) The operators seem reverse to the last time I implemented it, > > and the way I'm used to it in a Cisco notation. > > Again, as I mentioned earlier, the Cisco notation reasoning doesn't > apply here. > In Cisco, the comparison is network address vs. prefix length. > In our case we have network address vs. network address. > > > This thread is getting too long, so let me repeat again my question > about the short/medium term solution. > If you can't accept the current behavior, would you like us to > invest some time trying to implement the Juniper-like keywords: > > "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" > "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" > "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" > > If yes, then please indicate whether we should use the > "shorter/orshorter/not" keywords or something else. As long as it doesn't take too long to implement I find it a more than welcome interrim solution :) > If you prefer a different solution, now is the time to suggest it > (flipping the operator direction excluded). > > If there are no replies, then probably nothing will change until the > rtrmgr is reimplemented (bug #677) and we are in the position to > implement the long-term solution. -K -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From mhorn at vyatta.com Mon Nov 20 21:33:33 2006 From: mhorn at vyatta.com (Mike Horn) Date: Mon, 20 Nov 2006 21:33:33 -0800 (PST) Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: <20061120205316.GE7246@spritelink.se> Message-ID: <21420941.22701164087213422.JavaMail.root@tahiti.vyatta.com> I would also prefer changing to Juniper-like keywords. For me, the operators I care about are "exact", "longer", "orlonger" and "not". I can't think of a practical application for "shorter" or "orshorter". Btw, can you share your thoughts on what the "long-term" solution would look like? -mike ----- Original Message ----- From: Kristian Larsson To: Pavlin Radoslavov Cc: xorp-users at xorp.org, xorp-hackers at xorp.org, mhorn at vyatta.com, Justin Fletcher Sent: Monday, November 20, 2006 1:53:17 PM GMT-0700 US/Mountain Subject: Re: [Xorp-users] [Xorp-hackers] Policy network4 operator On Mon, Nov 20, 2006 at 11:45:00AM -0800, Pavlin Radoslavov wrote: > > > Seriously, though, is it only the person who originally implemented > > > this feature in XORP (Andrea and probably later updated by Marko?), > > > Atanu and me who think that comparing network addresses indeed means > > > comparing network addresses? > > > > Maybe :-) The operators seem reverse to the last time I implemented it, > > and the way I'm used to it in a Cisco notation. > > Again, as I mentioned earlier, the Cisco notation reasoning doesn't > apply here. > In Cisco, the comparison is network address vs. prefix length. > In our case we have network address vs. network address. > > > This thread is getting too long, so let me repeat again my question > about the short/medium term solution. > If you can't accept the current behavior, would you like us to > invest some time trying to implement the Juniper-like keywords: > > "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" > "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" > "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" > > If yes, then please indicate whether we should use the > "shorter/orshorter/not" keywords or something else. As long as it doesn't take too long to implement I find it a more than welcome interrim solution :) > If you prefer a different solution, now is the time to suggest it > (flipping the operator direction excluded). > > If there are no replies, then probably nothing will change until the > rtrmgr is reimplemented (bug #677) and we are in the position to > implement the long-term solution. -K -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Tue Nov 21 12:42:24 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 21 Nov 2006 12:42:24 -0800 Subject: [Xorp-hackers] [Xorp-users] Policy network4 operator In-Reply-To: Message from Mike Horn of "Mon, 20 Nov 2006 21:33:33 PST." <21420941.22701164087213422.JavaMail.root@tahiti.vyatta.com> Message-ID: <200611212042.kALKgOGF024918@possum.icir.org> > I would also prefer changing to Juniper-like keywords. For me, > the operators I care about are "exact", "longer", "orlonger" and > "not". I can't think of a practical application for "shorter" or > "orshorter". The "shorter" and "orshorter" keywords could be useful if someone wants to write a policy statement that matches all routes that might be used to reach a particular destination. I don't know whether someone will use it in practice, but it can be useful for experimentations. In any case, there shouldn't be any harm having them. > Btw, can you share your thoughts on what the "long-term" solution > would look like? The long-term solution will be determined at some future stage. Few things that come to mind (within the context of the discussed network operators) are: * Some of the syntax can be more Juniper-like. E.g., network 10.0.0.0/8 orlonger network 10.0.0.0/8 through 10.1.0.0/16 * Better support for network lists. E.g., network-list foo { 10.0.0.0/8 orlonger 10.0.0.0/8 through 10.1.0.0/16 } If you have ideas or suggestions about any long-term modifications (not only about the network operator but policy in general), please create a new bugzilla entry that can be used as a placeholder for them. FYI, there is already an entry about Cisco RPL: http://www.xorp.org/bugzilla/show_bug.cgi?id=652 Pavlin From elcinturapartida at yahoo.es Wed Nov 22 23:48:36 2006 From: elcinturapartida at yahoo.es (David H. Guerrero) Date: Thu, 23 Nov 2006 07:48:36 +0000 (GMT) Subject: [Xorp-hackers] Compiler error when trying to compile XORP Message-ID: <20061123074836.5507.qmail@web26005.mail.ukl.yahoo.com> Hello all, I have been trying to compile the lastest XORP code from the anon-CVS repository (VERSION 1.4-WIP) on Debian 4.0 Etch. david at xorp-hp:~/xorp$ uname -a Linux xorp-hp 2.6.17-2-k7 #1 SMP Wed Sep 13 17:18:46 UTC 2006 i686 GNU/Linux david at xorp-hp:~/xorp$ dpkg -l gc* | grep ii ii gcc 3.3.5-3 The GNU C compiler ii gcc-3.3 3.3.6-13 The GNU C compiler ii gcc-3.3-base 3.3.6-13 The GNU Compiler Collection (base package) ii gcc-3.4 3.4.6-4 The GNU C compiler ii gcc-3.4-base 3.4.6-4 The GNU Compiler Collection (base package) ii gcc-4.1-base 4.1.1-19 The GNU Compiler Collection (base package) david at xorp-hp:~/xorp$ dpkg -l g+* | grep ii ii g++ 3.3.5-3 The GNU C++ compiler ii g++-3.3 3.3.6-13 The GNU C++ compiler ii g++-3.4 3.4.6-4 The GNU C++ compiler I get error with gcc-3.3 and g++-3.3 ... source='xrl_pf_stcp.cc' object='xrl_pf_stcp.lo' libtool=yes \ depfile='.deps/xrl_pf_stcp.Plo' tmpdepfile='.deps/xrl_pf_stcp.TPlo' \ depmode=gcc3 /bin/sh ../config/depcomp \ /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o xrl_pf_stcp.lo `test -f xrl_pf_stcp.cc || echo './'`xrl_pf_stcp.cc g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded-virtual -ftemplate-depth-25 -pipe -c xrl_pf_stcp.cc -MT xrl_pf_stcp.lo -MD -MP -MF .deps/xrl_pf_stcp.TPlo -o xrl_pf_stcp.o echo timestamp > xrl_pf_stcp.lo source='xrl_pf_stcp_ph.cc' object='xrl_pf_stcp_ph.lo' libtool=yes \ depfile='.deps/xrl_pf_stcp_ph.Plo' tmpdepfile='.deps/xrl_pf_stcp_ph.TPlo' \ depmode=gcc3 /bin/sh ../config/depcomp \ /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o xrl_pf_stcp_ph.lo `test -f xrl_pf_stcp_ph.cc || echo './'`xrl_pf_stcp_ph.cc g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded-virtual -ftemplate-depth-25 -pipe -c xrl_pf_stcp_ph.cc -MT xrl_pf_stcp_ph.lo -MD -MP -MF .deps/xrl_pf_stcp_ph.TPlo -o xrl_pf_stcp_ph.o In file included from /usr/include/c++/3.3/bits/locale_facets.h:528, from /usr/include/c++/3.3/bits/basic_ios.h:44, from /usr/include/c++/3.3/ios:51, from /usr/include/c++/3.3/ostream:45, from /usr/include/c++/3.3/iostream:45, from ../libxorp/xorp.h:31, from xrl_pf_stcp_ph.cc:18: /usr/include/c++/3.3/bits/codecvt.h:179: error: syntax error before `&' token /usr/include/c++/3.3/bits/codecvt.h:185: error: syntax error before `&' token /usr/include/c++/3.3/bits/codecvt.h:189: error: syntax error before `&' token make[2]: *** [xrl_pf_stcp_ph.lo] Error 1 make[2]: Leaving directory `/home/david/xorp/libxipc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/david/xorp' make: *** [all] Error 2 Even though XORP compiles with gcc-3.4 and g++-3.4 and I can install (make install), I get error when running xoprsh: david at xorp-hp:/usr/local/xorp/bin$ ./xorpsh [ 2006/11/22 19:52:04 WARNING xorpsh RTRMGR ] [Operational Command File: /usr/lo cal/xorp/etc/templates/misc.cmds line 39]: Executable file not found: traceroute 6 Waiting for xorp_rtrmgr... [ 2006/11/22 19:52:34 ERROR xorpsh:5858 RTRMGR +90 xorpsh_main.cc wait_for_xrl_router_ready ] XrlRouter failed. No Finder? [ 2006/11/22 19:52:34 ERROR xorpsh:5858 RTRMGR +897 xorpsh_main.cc main ] xorpsh exiting due to an init error: Failed to connect to the router manager david at xorp-hp:/usr/local/xorp/bin$ ./xorpsh [ 2006/11/22 20:04:48 WARNING xorpsh RTRMGR ] [Operational Command File: /usr/local/xorp/etc/templates/misc.cmds line 39]: Executable file not found: traceroute6 Waiting for xorp_rtrmgr... [ 2006/11/22 20:05:18 ERROR xorpsh:6213 RTRMGR +90 xorpsh_main.cc wait_for_xrl_router_ready ] XrlRouter failed. No Finder? [ 2006/11/22 20:05:18 ERROR xorpsh:6213 RTRMGR +897 xorpsh_main.cc main ] xorpsh exiting due to an init error: Failed to connect to the router manager Furthermore, I get error when running 'make check' after compile: make[2]: `test_finder_messenger' is up to date. make[2]: `test_finder_msgs' is up to date. make[2]: `test_finder' is up to date. make[2]: `test_finder_events' is up to date. make[2]: `test_xrl_parser' is up to date. /bin/sh ../libtool --mode=link /usr/bin/g++-3.4 -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -o test_finder_to test_finder_to.o libfinder.la ./libfinder.la ./libxipc.la ../libxorp/libxorp.la ../libcomm/libcomm.la -lcrypto /usr/bin/g++-3.4 -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -o test_finder_to test_finder_to.o ./.libs/libfinder.a ./.libs/libxipc.a ../libxorp/.libs/libxorp.a ../libcomm/.libs/libcomm.a -lcrypto make[2]: Leaving directory `/home/david/xorp/libxipc' make[1]: Leaving directory `/home/david/xorp/libxipc' collect2: ld terminated with signal 11 [Segmentation fault] make[2]: *** [test_finder_to] Error 1 make[2]: Leaving directory `/home/david/xorp/libxipc' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/home/david/xorp/libxipc' make: *** [check-recursive] Error 1 Any advice will be much appreciated. Thanks David ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. http://es.voice.yahoo.com From M.Handley at cs.ucl.ac.uk Thu Nov 23 02:46:16 2006 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Thu, 23 Nov 2006 10:46:16 +0000 Subject: [Xorp-hackers] Compiler error when trying to compile XORP In-Reply-To: <20061123074836.5507.qmail@web26005.mail.ukl.yahoo.com> References: <20061123074836.5507.qmail@web26005.mail.ukl.yahoo.com> Message-ID: <84a612dd0611230246n38d4c782mbe29c73d0e713b65@mail.gmail.com> At first glance, it looks like your linux system is somewhat broken. The first error is a problem compiling the standard C++ iostream module - gcc 3.3 is complaining that some of the standard gcc 3.3 header files are illegal syntax. Doesn't seem to be a XORP-specific problem to me. Maybe a bad compiler installation? The second problem looks like rtrmgr doesn't want to start because it can't find traceroute. Make sure that traceroute is in your command path. I'm not certain if this is the only problem though, but I am pretty sure that rtrmgr failed to start properly. The 3rd problem is a segfault in ld. This seems to point to a broken linux install, or perhaps a machine that has flakey hardware. If the results are non-deterministic (things fail in a different place each time), then I'd suspect bad hardware. Of course it could be something else, but it doesn't look good from the errors you've show us. - Mark On 11/23/06, David H. Guerrero wrote: > > Hello all, I have been trying to compile the lastest XORP code from the anon-CVS repository (VERSION 1.4-WIP) on Debian 4.0 Etch. > > david at xorp-hp:~/xorp$ uname -a > Linux xorp-hp 2.6.17-2-k7 #1 SMP Wed Sep 13 17:18:46 UTC 2006 i686 GNU/Linux > david at xorp-hp:~/xorp$ dpkg -l gc* | grep ii > ii gcc 3.3.5-3 The GNU C compiler > ii gcc-3.3 3.3.6-13 The GNU C compiler > ii gcc-3.3-base 3.3.6-13 The GNU Compiler Collection (base package) > ii gcc-3.4 3.4.6-4 The GNU C compiler > ii gcc-3.4-base 3.4.6-4 The GNU Compiler Collection (base package) > ii gcc-4.1-base 4.1.1-19 The GNU Compiler Collection (base package) > david at xorp-hp:~/xorp$ dpkg -l g+* | grep ii > ii g++ 3.3.5-3 The GNU C++ compiler > ii g++-3.3 3.3.6-13 The GNU C++ compiler > ii g++-3.4 3.4.6-4 The GNU C++ compiler > > I get error with gcc-3.3 and g++-3.3 > ... > source='xrl_pf_stcp.cc' object='xrl_pf_stcp.lo' libtool=yes \ > depfile='.deps/xrl_pf_stcp.Plo' tmpdepfile='.deps/xrl_pf_stcp.TPlo' \ > depmode=gcc3 /bin/sh ../config/depcomp \ > /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o xrl_pf_stcp.lo `test -f xrl_pf_stcp.cc || echo './'`xrl_pf_stcp.cc > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded-virtual -ftemplate-depth-25 -pipe -c xrl_pf_stcp.cc -MT xrl_pf_stcp.lo -MD -MP -MF .deps/xrl_pf_stcp.TPlo -o xrl_pf_stcp.o > echo timestamp > xrl_pf_stcp.lo > source='xrl_pf_stcp_ph.cc' object='xrl_pf_stcp_ph.lo' libtool=yes \ > depfile='.deps/xrl_pf_stcp_ph.Plo' tmpdepfile='.deps/xrl_pf_stcp_ph.TPlo' \ > depmode=gcc3 /bin/sh ../config/depcomp \ > /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o xrl_pf_stcp_ph.lo `test -f xrl_pf_stcp_ph.cc || echo './'`xrl_pf_stcp_ph.cc > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded-virtual -ftemplate-depth-25 -pipe -c xrl_pf_stcp_ph.cc -MT xrl_pf_stcp_ph.lo -MD -MP -MF .deps/xrl_pf_stcp_ph.TPlo -o xrl_pf_stcp_ph.o > In file included from /usr/include/c++/3.3/bits/locale_facets.h:528, > from /usr/include/c++/3.3/bits/basic_ios.h:44, > from /usr/include/c++/3.3/ios:51, > from /usr/include/c++/3.3/ostream:45, > from /usr/include/c++/3.3/iostream:45, > from ../libxorp/xorp.h:31, > from xrl_pf_stcp_ph.cc:18: > /usr/include/c++/3.3/bits/codecvt.h:179: error: syntax error before `&' token > /usr/include/c++/3.3/bits/codecvt.h:185: error: syntax error before `&' token > /usr/include/c++/3.3/bits/codecvt.h:189: error: syntax error before `&' token > make[2]: *** [xrl_pf_stcp_ph.lo] Error 1 > make[2]: Leaving directory `/home/david/xorp/libxipc' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/david/xorp' > make: *** [all] Error 2 > > Even though XORP compiles with gcc-3.4 and g++-3.4 and I can install (make install), I get error when running xoprsh: > > david at xorp-hp:/usr/local/xorp/bin$ ./xorpsh > [ 2006/11/22 19:52:04 WARNING xorpsh RTRMGR ] [Operational Command File: /usr/lo cal/xorp/etc/templates/misc.cmds line 39]: Executable file not found: traceroute 6 > Waiting for xorp_rtrmgr... > [ 2006/11/22 19:52:34 ERROR xorpsh:5858 RTRMGR +90 xorpsh_main.cc wait_for_xrl_router_ready ] XrlRouter failed. No Finder? > [ 2006/11/22 19:52:34 ERROR xorpsh:5858 RTRMGR +897 xorpsh_main.cc main ] xorpsh exiting due to an init error: Failed to connect to the router manager > david at xorp-hp:/usr/local/xorp/bin$ ./xorpsh > [ 2006/11/22 20:04:48 WARNING xorpsh RTRMGR ] [Operational Command File: /usr/local/xorp/etc/templates/misc.cmds line 39]: Executable file not found: traceroute6 > Waiting for xorp_rtrmgr... > [ 2006/11/22 20:05:18 ERROR xorpsh:6213 RTRMGR +90 xorpsh_main.cc wait_for_xrl_router_ready ] XrlRouter failed. No Finder? > [ 2006/11/22 20:05:18 ERROR xorpsh:6213 RTRMGR +897 xorpsh_main.cc main ] xorpsh exiting due to an init error: Failed to connect to the router manager > > Furthermore, I get error when running 'make check' after compile: > > make[2]: `test_finder_messenger' is up to date. > make[2]: `test_finder_msgs' is up to date. > make[2]: `test_finder' is up to date. > make[2]: `test_finder_events' is up to date. > make[2]: `test_xrl_parser' is up to date. > /bin/sh ../libtool --mode=link /usr/bin/g++-3.4 -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -o test_finder_to test_finder_to.o libfinder.la ./libfinder.la ./libxipc.la ../libxorp/libxorp.la ../libcomm/libcomm.la -lcrypto > /usr/bin/g++-3.4 -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -o test_finder_to test_finder_to.o ./.libs/libfinder.a ./.libs/libxipc.a ../libxorp/.libs/libxorp.a ../libcomm/.libs/libcomm.a -lcrypto > make[2]: Leaving directory `/home/david/xorp/libxipc' > make[1]: Leaving directory `/home/david/xorp/libxipc' > collect2: ld terminated with signal 11 [Segmentation fault] > make[2]: *** [test_finder_to] Error 1 > make[2]: Leaving directory `/home/david/xorp/libxipc' > make[1]: *** [check-am] Error 2 > make[1]: Leaving directory `/home/david/xorp/libxipc' > make: *** [check-recursive] Error 1 > > Any advice will be much appreciated. > > Thanks > > David > > > > > > > ______________________________________________ > LLama Gratis a cualquier PC del Mundo. > Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. > http://es.voice.yahoo.com > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From santhosh at ku.edu Fri Nov 24 00:14:24 2006 From: santhosh at ku.edu (Santhosh Sundararaman) Date: Fri, 24 Nov 2006 02:14:24 -0600 Subject: [Xorp-hackers] Issue in implementing PER PEER BGP POLICY. kindly help asap. In-Reply-To: <75907.1154561852@tigger.icir.org> References: <75907.1154561852@tigger.icir.org> Message-ID: <4566A9E0.2010003@ku.edu> Hi, I have been trying to implement Per Peer Policy for BGP in xorp by modifying the template file and doing changes in the background (Policy, BGP) as Atanu had suggested in the bugzilla thread. I was able to get the mechanism work for IMPORT policies in BGP. But Im having problems with export policies (for now im trying to apply simple export policies without any redistribution). After poking around a bit I figured out where the problem was, but am not able to understand why the BGP export policy tables are behaving the way they are. Here is what i did. In the bgp.hh file i found that the filters were maintained in the object _policy_filters (of type VersionFilters). And this object is being used as the filter for all the PolicyTableFilterOut (export) tables in the plumbing. After trying several things, I created another object _peer_filters (of type VersionFilters) and now I used this object as the filter for the PolicyTableFilterOut tables of all the pipelines in the plumbing EXCEPT for the RIB's pipeline. The RIB's piplene still uses _policy_filters in its PolicyTableFilterOut. Now irrespective of the filter configuration (in config.boot) the filters seems to be working only when it is applied in the PolicyTableFilterOut of the RIB's pipeline and policies configured on the PolicyTableFilterOut of all other pipelines does not have any effect at all. Here is an example i tried. network4-list "PrefixesFrom105" { elements: "192.168.41.0/24,192.168.42.0/24,192.168.43.0/24" } policy-statement "BlockRoutesFrom105" { term "RoutesFrom105Blocked" { to { neighbor: 172.16.10.3 network4-list: "PrefixesFrom105" } then { trace: 1 reject } } } Here are my test cases and results Case 1: When this configuration is used to configure _peer_filters (I changed the BGPMain::configure_filter method to configure _peer_filters instead of _policy_filters and i left _policy_filters unconfigured thereby using an empty filter on RIB's export filter table), the filter had no effect despite the fact that 172.16.10.3 is the router id of one of the established peers. Case2: Now i swapped configurations. I applied the above configuration for _policy_filters (effectively applying them to the RIB's export pipeline alone) and left _peer_filters empty (the export filter tables in all other pipelines except RIB will have no configuration and should let all routes through). This is where i noticed unexpected results. I expected this filter to have no effect on routes going to 172.16.10.3, as even though the filter config blocks routes to 172.16.10.3 it is applied only in the export pipeline of RIB and not on others, the other export pipelines had empty filters. But now the routes in the list were blocked from going to 172.16.10.3 but other peer and local RIB received the routes, despite the fact that the filter config was applied only to the RIB's export pipeline. Case 3: Finally i removed the neighbor parameter from the config, letting it take default value. Now, when the config was applied to RIB's pipeline alone and not to others, the routes were blocked from all the peers and from the local RIB. When i swapped the config (with no neighbor set) by applying it to all the export pipelines except RIB's and leaving RIB's export policy config empty, the config had no effect and the routes were getting passed to all the peers and the RIB. From this it appears to me that RIB pipeline's PolicyTableFilterOut seems to be doing the bulk of export filtering (even for other pipelines) and the PolicyTableFilterOut in all other pipelines have no effect on export filtering at all. Have I overlooked something, or have I completely misunderstood Policy implementation in BGP. Kindly help me understand why im experiencing this behavior, is it supposed to work this way: is the RIB's PolicyTableFilterOut supposed to filter routes for all the peer's pipelines?? Kindly help me out!!! Expecting a response asap. Thanks, Santhosh From santhosh at ku.edu Fri Nov 24 02:01:59 2006 From: santhosh at ku.edu (Santhosh Sundararaman) Date: Fri, 24 Nov 2006 04:01:59 -0600 Subject: [Xorp-hackers] Issue in implementing PER PEER BGP POLICY. kindly help asap. In-Reply-To: <4566A9E0.2010003@ku.edu> References: <75907.1154561852@tigger.icir.org> <4566A9E0.2010003@ku.edu> Message-ID: <4566C317.7000809@ku.edu> Hi, I proceeded to do the following tests which have left me more confused. I removed the PolicyTableFilterOut from the the pipeline of every peer, except RIB (by changing the plumbing's add_peering method). Now when I used the filter config mentioned earlier (with neighbor set to 172.16.10.3) to setup the PolicyTableFilterOut of RIB, no filtering occured. But when I inserted the PolicyFilterTableOut for every peer back (even now only the policytable of RIB is set with the config, policytables of other peers have no configuration: allowing all routes) the routes going to 172.16.10.3 are being blocked although this config is only in RIB's pipeline. So from this it looks to me that the config works only when the RIB's policytable has been configured with it, and the at the same time when the policytables of other peers are present in the plumbing (just thier presence in the plumbing seems to be necassary, whether they have been configured with some filter configuration or they are empty does not seem to make a difference as long as they are in the plumbing). Is there some interaction between the PolicyTableFilterOuts of all pipelines with the RIB pipeline's PolicyTableFilterOut. These results have left me totally confused. Is this a problem or is it just the way xorp is supposed to work and I have misunderstood the export policy implementation. I presumed that the PolicyTableFilterOut of individual pipelines work independed of the RIB pipeline's PolicyTableFilterOut or for that matter independed of the entire RIB pipeline or the local RIB, isn't that so?? Some one kindly bail me out of this situation. Thanks, Santhosh Santhosh Sundararaman wrote: >Hi, >I have been trying to implement Per Peer Policy for BGP in xorp by >modifying the template file and doing changes in the background (Policy, >BGP) as Atanu had suggested in the bugzilla thread. I was able to get >the mechanism work for IMPORT policies in BGP. But Im having problems >with export policies (for now im trying to apply simple export policies >without any redistribution). After poking around a bit I figured out >where the problem was, but am not able to understand why the BGP export >policy tables are behaving the way they are. > >Here is what i did. In the bgp.hh file i found that the filters were >maintained in the object _policy_filters (of type VersionFilters). And >this object is being used as the filter for all the PolicyTableFilterOut >(export) tables in the plumbing. After trying several things, I created >another object _peer_filters (of type VersionFilters) and now I used >this object as the filter for the PolicyTableFilterOut tables of all the >pipelines in the plumbing EXCEPT for the RIB's pipeline. The RIB's >piplene still uses _policy_filters in its PolicyTableFilterOut. > >Now irrespective of the filter configuration (in config.boot) the >filters seems to be working only when it is applied in the >PolicyTableFilterOut of the RIB's pipeline and policies configured on >the PolicyTableFilterOut of all other pipelines does not have any effect >at all. > >Here is an example i tried. > > network4-list "PrefixesFrom105" { > elements: "192.168.41.0/24,192.168.42.0/24,192.168.43.0/24" > } > policy-statement "BlockRoutesFrom105" { > term "RoutesFrom105Blocked" { > to { > neighbor: 172.16.10.3 > network4-list: "PrefixesFrom105" > } > then { > trace: 1 > reject > } > } > } > >Here are my test cases and results > >Case 1: >When this configuration is used to configure _peer_filters (I changed >the BGPMain::configure_filter method to configure _peer_filters instead >of _policy_filters and i left _policy_filters unconfigured thereby using >an empty filter on RIB's export filter table), the filter had no effect >despite the fact that 172.16.10.3 is the router id of one of the >established peers. > >Case2: >Now i swapped configurations. I applied the above configuration for >_policy_filters (effectively applying them to the RIB's export pipeline >alone) and left _peer_filters empty (the export filter tables in all >other pipelines except RIB will have no configuration and should let all >routes through). This is where i noticed unexpected results. I expected >this filter to have no effect on routes going to 172.16.10.3, as even >though the filter config blocks routes to 172.16.10.3 it is applied only >in the export pipeline of RIB and not on others, the other export >pipelines had empty filters. > But now the routes in the list were blocked from going to >172.16.10.3 but other peer and local RIB received the routes, despite >the fact that the filter config was applied only to the RIB's export >pipeline. > >Case 3: >Finally i removed the neighbor parameter from the config, letting it >take default value. Now, when the config was applied to RIB's pipeline >alone and not to others, the routes were blocked from all the peers and >from the local RIB. When i swapped the config (with no neighbor set) by >applying it to all the export pipelines except RIB's and leaving RIB's >export policy config empty, the config had no effect and the routes were >getting passed to all the peers and the RIB. > > From this it appears to me that RIB pipeline's PolicyTableFilterOut >seems to be doing the bulk of export filtering (even for other >pipelines) and the PolicyTableFilterOut in all other pipelines have no >effect on export filtering at all. Have I overlooked something, or have >I completely misunderstood Policy implementation in BGP. Kindly help me >understand why im experiencing this behavior, is it supposed to work >this way: is the RIB's PolicyTableFilterOut supposed to filter routes >for all the peer's pipelines?? Kindly help me out!!! > >Expecting a response asap. > >Thanks, >Santhosh > >_______________________________________________ >Xorp-hackers mailing list >Xorp-hackers at icir.org >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > From santhosh at ku.edu Sat Nov 25 13:30:01 2006 From: santhosh at ku.edu (Santhosh Sundararaman) Date: Sat, 25 Nov 2006 15:30:01 -0600 Subject: [Xorp-hackers] [SPAM][RBL+] Re: Issue in implementing PER PEER BGP POLICY. kindly help asap. In-Reply-To: <4566C317.7000809@ku.edu> References: <75907.1154561852@tigger.icir.org> <4566A9E0.2010003@ku.edu> <4566C317.7000809@ku.edu> Message-ID: <4568B5D9.4000308@ku.edu> Hi, I have finally located what was happening and why. 1. The issue had nothing to do with the RIB's pipeline as I had presumed earlier. I realized (by removing the RIB policy out filters from the plumbing) that only the filter that was first used for a route was used thereafter on all the plumbings irrespective of the filter configuration in that pipeline. 2. This issues was due to the fact that when a route goes through a version filter a reference to that filter is maintained in the internal route message and everytime a route goes through a version filter it is checked if the route already has a reference to any filters and if so that filter (referenced in the route) was being applied rather than the filter config present in policy table of that pipeline. This i learned was done to identify the the older version of filter that was applied to a route when a policy (filter) configuration changes and to take an appropriate decision based on how the route was treated by the older filter and how it is being treated by the newer filter. To implement peer specific policies, this has to be slightly modified so that the filter referenced in the route is not applied to the route on all the pipelines as each pipeline would have a different filter configuration. This was not an issue in the normal XORP case as all the pipelines would have the same filter configuration. I guess there should be some way of identifying the the recent most filter that was applied to a route on a per peer basis, so that when a policy configuration changes for a particular peer add/delete/replace messages are generated appropriately for a route based on the previous version of that peer's filter which was applied to that route; to ensure that the route information in that peer is consistent with the policy change. I would appreciate any suggestions regarding maintaining peer specific filter version information for routes. Thanks Santhosh. Santhosh Sundararaman wrote: > Hi, > I proceeded to do the following tests which have left me more confused. > > I removed the PolicyTableFilterOut from the the pipeline of every > peer, except RIB (by changing the plumbing's add_peering method). Now > when I used the filter config mentioned earlier (with neighbor set to > 172.16.10.3) to setup the PolicyTableFilterOut of RIB, no filtering > occured. But when I inserted the PolicyFilterTableOut for every peer > back (even now only the policytable of RIB is set with the config, > policytables of other peers have no configuration: allowing all > routes) the routes going to 172.16.10.3 are being blocked although > this config is only in RIB's pipeline. > > So from this it looks to me that the config works only when the RIB's > policytable has been configured with it, and the at the same time when > the policytables of other peers are present in the plumbing (just > thier presence in the plumbing seems to be necassary, whether they > have been configured with some filter configuration or they are empty > does not seem to make a difference as long as they are in the > plumbing). Is there some interaction between the PolicyTableFilterOuts > of all pipelines with the RIB pipeline's PolicyTableFilterOut. > > These results have left me totally confused. Is this a problem or is > it just the way xorp is supposed to work and I have misunderstood the > export policy implementation. I presumed that the PolicyTableFilterOut > of individual pipelines work independed of the RIB pipeline's > PolicyTableFilterOut or for that matter independed of the entire RIB > pipeline or the local RIB, isn't that so?? > > Some one kindly bail me out of this situation. > > Thanks, > Santhosh > > Santhosh Sundararaman wrote: > >> Hi, >> I have been trying to implement Per Peer Policy for BGP in xorp by >> modifying the template file and doing changes in the background >> (Policy, BGP) as Atanu had suggested in the bugzilla thread. I was >> able to get the mechanism work for IMPORT policies in BGP. But Im >> having problems with export policies (for now im trying to apply >> simple export policies without any redistribution). After poking >> around a bit I figured out where the problem was, but am not able to >> understand why the BGP export policy tables are behaving the way they >> are. >> >> Here is what i did. In the bgp.hh file i found that the filters were >> maintained in the object _policy_filters (of type VersionFilters). >> And this object is being used as the filter for all the >> PolicyTableFilterOut (export) tables in the plumbing. After trying >> several things, I created another object _peer_filters (of type >> VersionFilters) and now I used this object as the filter for the >> PolicyTableFilterOut tables of all the pipelines in the plumbing >> EXCEPT for the RIB's pipeline. The RIB's piplene still uses >> _policy_filters in its PolicyTableFilterOut. >> >> Now irrespective of the filter configuration (in config.boot) the >> filters seems to be working only when it is applied in the >> PolicyTableFilterOut of the RIB's pipeline and policies configured on >> the PolicyTableFilterOut of all other pipelines does not have any >> effect at all. >> >> Here is an example i tried. >> >> network4-list "PrefixesFrom105" { >> elements: "192.168.41.0/24,192.168.42.0/24,192.168.43.0/24" >> } >> policy-statement "BlockRoutesFrom105" { >> term "RoutesFrom105Blocked" { >> to { >> neighbor: 172.16.10.3 >> network4-list: "PrefixesFrom105" >> } >> then { >> trace: 1 >> reject >> } >> } >> } >> >> Here are my test cases and results >> >> Case 1: >> When this configuration is used to configure _peer_filters (I changed >> the BGPMain::configure_filter method to configure _peer_filters >> instead of _policy_filters and i left _policy_filters unconfigured >> thereby using an empty filter on RIB's export filter table), the >> filter had no effect despite the fact that 172.16.10.3 is the router >> id of one of the established peers. >> >> Case2: >> Now i swapped configurations. I applied the above configuration for >> _policy_filters (effectively applying them to the RIB's export >> pipeline alone) and left _peer_filters empty (the export filter >> tables in all other pipelines except RIB will have no configuration >> and should let all routes through). This is where i noticed >> unexpected results. I expected this filter to have no effect on >> routes going to 172.16.10.3, as even though the filter config blocks >> routes to 172.16.10.3 it is applied only in the export pipeline of >> RIB and not on others, the other export pipelines had empty filters. >> But now the routes in the list were blocked from going to >> 172.16.10.3 but other peer and local RIB received the routes, despite >> the fact that the filter config was applied only to the RIB's export >> pipeline. >> >> Case 3: >> Finally i removed the neighbor parameter from the config, letting it >> take default value. Now, when the config was applied to RIB's >> pipeline alone and not to others, the routes were blocked from all >> the peers and from the local RIB. When i swapped the config (with no >> neighbor set) by applying it to all the export pipelines except RIB's >> and leaving RIB's export policy config empty, the config had no >> effect and the routes were getting passed to all the peers and the RIB. >> >> From this it appears to me that RIB pipeline's PolicyTableFilterOut >> seems to be doing the bulk of export filtering (even for other >> pipelines) and the PolicyTableFilterOut in all other pipelines have >> no effect on export filtering at all. Have I overlooked something, or >> have I completely misunderstood Policy implementation in BGP. Kindly >> help me understand why im experiencing this behavior, is it supposed >> to work this way: is the RIB's PolicyTableFilterOut supposed to >> filter routes for all the peer's pipelines?? Kindly help me out!!! >> >> Expecting a response asap. >> >> Thanks, >> Santhosh >> >> _______________________________________________ >> Xorp-hackers mailing list >> Xorp-hackers at icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers >> >> >