From kristian@juniks.net Tue Nov 1 08:21:16 2005 From: kristian@juniks.net (Kristian Larsson) Date: Tue, 1 Nov 2005 09:21:16 +0100 Subject: [Xorp-hackers] BGP groups In-Reply-To: <84a612dd0510311212i8e4b60cpcf920f20cd92b2d7@mail.gmail.com> References: <20051031181900.GA7585@juniks.net> <84a612dd0510311212i8e4b60cpcf920f20cd92b2d7@mail.gmail.com> Message-ID: <20051101082116.GH3639@juniks.net> I don't think all of the wanted functionality is possible to implement. Makin something simple work like: protocols bgp { group My_transit_provider { local-as 1337; remote-as 1338; neighbour 1.3.3.7; neighbour 1.3.3.8; neighbour 1.3.3.9; neighbour 1.3.3.10; prefix-list out My_prefixes; } } is feasible. however: protocols bgp { group My_transit_provider { local-as 1337; remote-as 1338; neighbour 1.3.3.7 { prefix-list in peer_1337; neighbour 1.3.3.8; neighbour 1.3.3.9; neighbour 1.3.3.10; prefix-list out My_prefixes; } } is a bit harder. In this case prefix-list "My_prefixes" is to be used for all neighbours except 1.3.3.7 where peer_1337 is to be used. Or is there a way I just don't know of. Kristian On Mon, Oct 31, 2005 at 08:12:17PM +0000, Mark Handley wrote: > You may be able to add this with only a template file change, and no > actual coding changes. > > - Mark > > On 10/31/05, Kristian Larsson wrote: > > I would like to hear peoples opinion on a group configuration under bgp. > > As so often I would like to bring up the "Juniper way" of doing things. In Juniper a normal BGP neighbor would be configured like this: > > protocols bgp { > > local-as 1337; > > group My_transit_provider { > > remote-as 1338; > > neighbour 1.3.3.7; > > prefix-list out My_prefixes; > > } > > } > > > > Having several peers with the same settings is real easy since you just add another neighbor statement, like this: > > protocols bgp { > > group My_transit_provider { > > local-as 1337; > > remote-as 1338; > > neighbour 1.3.3.7; > > neighbour 1.3.3.8; > > neighbour 1.3.3.9; > > neighbour 1.3.3.10; > > prefix-list out My_prefixes; > > } > > } > > > > As group doesn't collide with any present BGP commands it would be easy to add and let the old peer statement remain as is to not surprise anyone ;) > > > > Any thoughts? > > > > Kristian. > > > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers@icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > From tdurack@gmail.com Wed Nov 2 14:48:38 2005 From: tdurack@gmail.com (Tim Durack) Date: Wed, 2 Nov 2005 09:48:38 -0500 Subject: [Xorp-hackers] Re: [Xorp-cvs] XORP cvs commit: xorp/rtrmgr In-Reply-To: <200511020240.jA22edqA082656@xorpc.icir.org> References: <200511020240.jA22edqA082656@xorpc.icir.org> Message-ID: <9e246b4d0511020648q4c00bc9boad69eee74f99673c@mail.gmail.com> Would be even nicer if the default prompt was "hostname>" and "hostname#" Tim:> From kristian@juniks.net Wed Nov 2 15:47:37 2005 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 2 Nov 2005 16:47:37 +0100 Subject: [Xorp-hackers] Re: [Xorp-cvs] XORP cvs commit: xorp/rtrmgr In-Reply-To: <9e246b4d0511020648q4c00bc9boad69eee74f99673c@mail.gmail.com> References: <200511020240.jA22edqA082656@xorpc.icir.org> <9e246b4d0511020648q4c00bc9boad69eee74f99673c@mail.gmail.com> Message-ID: <20051102154737.GK3639@juniks.net> user@hostname> & user@hostname# anyone? http://www.xorp.org/bugzilla/show_bug.cgi?id=188 :) Kristian On Wed, Nov 02, 2005 at 09:48:38AM -0500, Tim Durack wrote: > Would be even nicer if the default prompt was "hostname>" and "hostname#" > > Tim:> > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From deathdealer@gmx.net Wed Nov 2 18:57:50 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Wed, 2 Nov 2005 19:57:50 +0100 Subject: [Xorp-hackers] Config Var <-> Config mode Message-ID: <000c01c5dfdf$56417a80$841cbb50@dedus737> Hello I have seen following if you configure a single line variable you write varname value and you get varname: value or varname: "value". I think this should be varname value; where the cli parser accepts both, varname value and varname value;, I think this is what Juniper does. Currently you cannot cut and past the config;-( Additionally the behavior of bool values should be in the way: Varname; means the variable is true And if you delete it the value is false. Gruss    Patrick Marc Preuss Nordstrasse 28 41569 Rommerskirchen From kristian@juniks.net Wed Nov 2 19:24:12 2005 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 2 Nov 2005 20:24:12 +0100 Subject: [Xorp-hackers] Config Var <-> Config mode In-Reply-To: <000c01c5dfdf$56417a80$841cbb50@dedus737> References: <000c01c5dfdf$56417a80$841cbb50@dedus737> Message-ID: <20051102192412.GA9156@juniks.net> How about removing ":" from the configuration file and simply ignoring ";" at the end of line. This would allow cut and paste with minimal changes. Plus it would be more JunOS like. One of the thing that networking people really love about Juniper is it's CLI, and thus making XORP very similar to it is clever. However there are several points where XORP differ from JunOS, IMHO this is often not to the better. The subject brought up here is one of them. Another is that of the "set" command which in XORP is split into create and set. Makes sense programming wise, not user wise. I know I have brought this up before: JunOS: set prefix-list test 1.0.0.0/24 set prefix-list test 2.0.0.0/24 results in prefix-list test { 1.0.0.0/24; 2.0.0.0/24; } XORP: create network4-list test elements 1.0.0.0/24,2.0.0.0/24 results in network4-list { elements: "1.0.0.0/24,1.0.1.0/24" } Which one is the easier one to scim through? Which one is easier to add prefixes to? I can't see anything other than programming benefits to XORPs way. Am I the only one of this opinion? Kristian. On Wed, Nov 02, 2005 at 07:57:50PM +0100, Patrick Preuss wrote: > Hello > > I have seen following if you configure a single line variable you write > varname value and you get varname: value or varname: "value". I think > this should be varname value; where the cli parser accepts both, varname > value and varname value;, I think this is what Juniper does. > > Currently you cannot cut and past the config;-( > > Additionally the behavior of bool values should be in the way: > Varname; means the variable is true > And if you delete it the value is false. > > Gruss >    Patrick Marc Preuss > Nordstrasse 28 > 41569 Rommerskirchen > > > > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From deathdealer@gmx.net Wed Nov 2 19:48:30 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Wed, 2 Nov 2005 20:48:30 +0100 Subject: AW: [Xorp-hackers] Config Var <-> Config mode In-Reply-To: <20051102192412.GA9156@juniks.net> Message-ID: <000e01c5dfe6$66a5a110$841cbb50@dedus737> Hello > How about removing ":" from the configuration file > and simply ignoring ";" at the end of line. This > would allow cut and paste with minimal changes. > Plus it would be more JunOS like. Yes removing : would be a good idea. But if it works under JunOS with ; we should have them in xorp to, it makes things easier, you see where the line / var ends. > One of the thing that networking people really > love about Juniper is it's CLI, and thus making Yes. > XORP very similar to it is clever. However there > are several points where XORP differ from JunOS, IMHO > this is often not to the better. The subject brought > up here is one of them. > Another is that of the "set" command which in XORP > is split into create and set. Makes sense > programming wise, not user wise. I know I have > brought this up before: Yes I have read it, think the Juniper way has some advantages, and the way of xorp to, some of the concepts in other routing platforms as cisco, riverstone / Enterasys also. > JunOS: > set prefix-list test 1.0.0.0/24 > set prefix-list test 2.0.0.0/24 > results in > prefix-list test { > 1.0.0.0/24; > 2.0.0.0/24; > } > XORP: > create network4-list test elements 1.0.0.0/24,2.0.0.0/24 > results in > network4-list { > elements: "1.0.0.0/24,1.0.1.0/24" > } > Which one is the easier one to scim through? Which > one is easier to add prefixes to? I think for reading and debugging the Juniper version is better to read. The Xorp way double things I think { and elemets: " means at this point the same. For programming the xorp has it vantages, but who should it have easier the programmer or the user network technican in this point, if you have a huge network, round about 500 Sites, you will love all things witch makes the daily tasks easier.;-) > I can't see anything other than programming > benefits to XORPs way. > Am I the only one of this opinion? Your not > Kristian. Patrick From kristian@juniks.net Wed Nov 2 20:00:51 2005 From: kristian@juniks.net ('Kristian Larsson') Date: Wed, 2 Nov 2005 21:00:51 +0100 Subject: [Xorp-hackers] Config Var <-> Config mode In-Reply-To: <000d01c5dfe6$387b8b60$841cbb50@dedus737> References: <20051102192412.GA9156@juniks.net> <000d01c5dfe6$387b8b60$841cbb50@dedus737> Message-ID: <20051102200051.GB9156@juniks.net> On Wed, Nov 02, 2005 at 08:47:03PM +0100, Patrick Preuss wrote: > Hello > > > How about removing ":" from the configuration file > > and simply ignoring ";" at the end of line. This > > would allow cut and paste with minimal changes. > > Plus it would be more JunOS like. > > Yes removing : would be a good idea. > But if it works under JunOS with ; we should have > them in xorp to, it makes things easier, you see > where the line / var ends. I'm just saying that the parser shouldn't react to ";". If we print them in our configuration file is another matter. Although having the parser ignore ";" you can't write several "lines" on one line.. if you get my drift :) Kristian > > > > > One of the thing that networking people really > > love about Juniper is it's CLI, and thus making > > Yes. > > > XORP very similar to it is clever. However there > > are several points where XORP differ from JunOS, IMHO > > this is often not to the better. The subject brought > > up here is one of them. > > > Another is that of the "set" command which in XORP > > is split into create and set. Makes sense > > programming wise, not user wise. I know I have > > brought this up before: > Yes I have read it, think the Juniper way has some advantages, and > the way of xorp to, some of the concepts in other routing platforms as > cisco, riverstone / Enterasys also. > > JunOS: > > set prefix-list test 1.0.0.0/24 > > set prefix-list test 2.0.0.0/24 > > results in > > prefix-list test { > > 1.0.0.0/24; > > 2.0.0.0/24; > > } > > > XORP: > > create network4-list test elements 1.0.0.0/24,2.0.0.0/24 > > results in > > network4-list { > > elements: "1.0.0.0/24,1.0.1.0/24" > > } > > > Which one is the easier one to scim through? Which > > one is easier to add prefixes to? > > I think for reading and debugging the Juniper version is better to read. > The Xorp way double things I think { and elemets: " means at this point the > same. For programming the xorp has it vantages, but who should it have > easier the programmer or the user network technican in this point, if you > have a huge network, round about 500 Sites, you will love all things witch > makes the daily tasks easier.;-) Indeed, "elements" is totally unnecessary, everybodes knows a network list contains elements, what else? ;) And split up the lines! Adding a single prefix to a 500 prefix list would require you to rewrite the whole list in XORP. Not very efficient. > > I can't see anything other than programming > > benefits to XORPs way. > > > Am I the only one of this opinion? > > Your not Sweet. I'm not alone :) Kristian From deathdealer@gmx.net Wed Nov 2 20:12:59 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Wed, 2 Nov 2005 21:12:59 +0100 Subject: AW: [Xorp-hackers] Config Var <-> Config mode In-Reply-To: <20051102200051.GB9156@juniks.net> Message-ID: <001401c5dfe9$d257a360$841cbb50@dedus737> Hello > On Wed, Nov 02, 2005 at 08:47:03PM +0100, Patrick Preuss wrote: > > Hello > > > > > How about removing ":" from the configuration file > > > and simply ignoring ";" at the end of line. This > > > would allow cut and paste with minimal changes. > > > Plus it would be more JunOS like. > > > > Yes removing : would be a good idea. > > But if it works under JunOS with ; we should have > > them in xorp to, it makes things easier, you see > > where the line / var ends. > I'm just saying that the parser shouldn't react > to ";". If we print them in our configuration file > is another matter. > Although having the parser ignore ";" you can't > write several "lines" on one line.. if you get my > drift :) Blame me, have got the same though;) > Kristian > Indeed, "elements" is totally unnecessary, > everybodes knows a network list contains elements, > what else? ;) > And split up the lines! > Adding a single prefix to a 500 prefix list would > require you to rewrite the whole list in XORP. Not > very efficient. Who can I pay to do this for me. This is like the old access-list's on cisco no access-list 101 access-list 101 permit .... awful;) > > > I can't see anything other than programming > > > benefits to XORPs way. > > > > > Am I the only one of this opinion? > > > > Your not > Sweet. I'm not alone :) > Kristian Patrick From doll@tm.uka.de Thu Nov 3 14:28:17 2005 From: doll@tm.uka.de (Mark Doll) Date: Thu, 03 Nov 2005 15:28:17 +0100 Subject: [Xorp-hackers] How to add UDP socket I/O to PIM Message-ID: <436A1E81.105@tm.uka.de> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig180BEFD54C3FEDCDEB982933 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi folks, hi Pavlin! Socket programming in C is normally quite easy and straight forward, but within XORP, I'm totally lost. I'm browsing the XORP sources for some while now, have done some modifications (see P.S.) and am now trying to figure out how XORP modules implement XRL communication in general and socket I/O in particular. I think I've understood how to use XRLs and how they work (i. e. this magic callback factory function or why you can savely destroy your XrlSomeInterfaceV0p1Client object directly after XRL invocation but before receiving the callback with the results). But I'm still quite unsure on how to do queueing and buffering of those XRL calls within a XORP module and coordination via the eventloop, especially within PIM, which I'm trying to modify now. My question is: Has anybody a howto on this or can give me a few lines of documented sample code which I can reuse? Until now I've copy&pasted parts of RIP's socket4/6 and socket4/6_user XRL interface usage/implementation (the complete RIP socket I/O code is unadequately complex because I only have one UDP socket, one neighbor (the BB) and no multicast). Currently I think about something similar to PIM's queueing (class XrlPimNode::XrlTaskBase and derived classes) that are used in communication with the MFEA. I don't know if this is the right way to do it, or if there's an easier way to implement this. So I'll really appreciate any help/hint/reassurance whatsoever. I think I'm lost in option space and can't see the wood for the trees... Regards, Mark. P.S.: Some background about what I'm doing: I'm implementing a simple extension to PIM, in which the PIM daemon informs a bandwidth broker (BB) by (repeatedly) sending a UDP datagram to the BB about an (in respect to QoS) unconfigured MFC entry containing all necessary info for its descision process. The BB in turn answers with one UDP datagram to tell PIM either to forward packets with unmodified diffserv codepoint or to reconfigure the multicast forwarding cache entry in the (FreeBSD) kernel so tha all packets are remarked to lower effort (RFC 3662) to handle the NRS problem (RFC 3754). It's a bit more complex than this, but that's the basic scheme. The modifications to FreeBSD/routing socket/MFEA are done, but the UDP socket to communicate with the BB is still missing. Of course, in the future plain UDP will be replaced by a real signaling protocol and probably a redesign of the complete implementation. But for a basic evaluation of the concept plain UDP is sufficient. --------------enig180BEFD54C3FEDCDEB982933 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkNqHocACgkQIA3R24S6bIEQJACfUKiuTEfkFbC3zAateEF0ApH2 /goAoIOWByC6EoWDF+a+Ca9sWPQ2y/kZ =0Lv1 -----END PGP SIGNATURE----- --------------enig180BEFD54C3FEDCDEB982933-- From deathdealer@gmx.net Thu Nov 3 18:37:23 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Thu, 3 Nov 2005 19:37:23 +0100 Subject: [Xorp-hackers] AW: [Xorp-users] Does xorp latest CVS have some problem with the export command? In-Reply-To: <34284.1131034860@tigger.icir.org> Message-ID: <004601c5e0a5$a488c6a0$c842bb50@dedus737> Hi, I have seen some smaller and bigger rewrites in the way xorp will or would be configured, is it possible for the next release to add a way rtrmgr do Not die when the configuration is "wrong" and to show this to the user only for the startup config? May be add a functionality to rewrite old config into new one. And to provide help in the configure mode so the user would notify, that this way is obsolete, maybe for the next releases until Version 2.0? It would make the system more user friendly. And we can build this into The workflow for all changes how the System is configured. ;-) Regards    Patrick -----Ursprüngliche Nachricht----- Von: xorp-users-admin@xorp.org [mailto:xorp-users-admin@xorp.org] Im Auftrag von Atanu Ghosh Gesendet: Donnerstag, 3. November 2005 17:21 An: riccardo.sciaccaluga@tin.it Cc: xorp-users@xorp.org Betreff: Re: [Xorp-users] Does xorp latest CVS have some problem with the export command? Hi, Previously RIP was using its one mechanism to import and export routes, it now uses the unified policy framework. It is now necessary to define a policy statement to capture what you want to export. To export the static routes: ---------------------------------------- First a policy statment: policy { policy-statement export_static { term static { from { protocol: "static" } } } Also: protocols { rip { export: "export_static" ... ---------------------------------------- To export the connected routes: ---------------------------------------- First a policy statment: policy { policy-statement export_connected { term rib { from { protocol: "rib" } } } Also: protocols { rip { export: "export_connected,export_static" ... ---------------------------------------- Atanu. >>>>> "riccardo" == riccardo writes: riccardo> I upgraded my current xorp version at the latest CVS file riccardo> and i tried to configure xorp with the same config.boot riccardo> file i used with xorp.1-1. It was a file configuring a riccardo> totally rip working network but the lateste CVS look like riccardo> if it didn't accept the export command giving to me the riccardo> following error message and killing the booting of xorp: riccardo> [ 2005/11/04 00:46:13 INFO xorp_rtrmgr:1195 RTRMGR +240 riccardo> master_conf_tree.cc execute ] Changed modules: interfaces, riccardo> fea, rib, policy, rip [ 2005/11/04 00:46: 13 INFO riccardo> xorp_rtrmgr:1195 RTRMGR +484 module_manager.cc run ] riccardo> Running module: interfaces riccardo> (/root/Andrea/xorp/fea/xorp_fea) [ 2005/11/04 00:46: 13 riccardo> INFO xorp_fea MFEA ] MFEA enabled [ 2005/11/04 00:46:13 riccardo> INFO xorp_fea MFEA ] CLI enabled [ 2005/11/04 00:46:13 riccardo> INFO xorp_fea MFEA ] CLI started [ 2005/11/04 00:46:15 riccardo> INFO xorp_rtrmgr:1195 RTRMGR +484 module_manager.cc run ] riccardo> Running module: fea (/root/Andrea/xorp/fea/xorp_fea) [ riccardo> 2005/11/04 00:46:21 INFO xorp_rtrmgr:1195 RTRMGR +484 riccardo> module_manager.cc run ] Running module: rib riccardo> (/root/Andrea/xorp/rib/xorp_rib) [ 2005/11/04 00:46:23 riccardo> INFO xorp_rtrmgr:1195 RTRMGR +484 module_manager.cc run ] riccardo> Running module: policy riccardo> (/root/Andrea/xorp/policy/xorp_policy) [ 2005/11/04 riccardo> 00:46:25 INFO xorp_rtrmgr:1195 RTRMGR +484 riccardo> module_manager.cc run ] Running module: rip riccardo> (/root/Andrea/xorp/rip/xorp_rip) [ 2005/11/04 00:46:27 riccardo> WARNING xorp_policy:1198 XrlPolicyTarget +513 riccardo> policy_base.cc handle_policy_0_1_export ] Handling method riccardo> for policy/0.1/export failed: XrlCmdError 102 Command riccardo> failed Export of rip failed: exports: Protocol rip unknown riccardo> [ 2005/11/04 00:46:27 ERROR xorp_rtrmgr:1195 RTRMGR +671 riccardo> master_conf_tree.cc commit_pass2_done ] Commit failed: 102 riccardo> Command failed Export of rip failed: exports: Protocol rip riccardo> unknown [ 2005/11/04 00:46:27 ERROR xorp_rtrmgr:1195 riccardo> RTRMGR +252 master_conf_tree.cc config_done ] riccardo> Configuration failed: 102 Command failed Export of rip riccardo> failed: exports: Protocol rip unknown [ 2005/11/04 riccardo> 00:46:27 INFO xorp_rtrmgr:1195 RTRMGR +2225 task.cc riccardo> run_task ] No more tasks to run [ 2005/11/04 00:46:27 INFO riccardo> xorp_rtrmgr:1195 RTRMGR +247 module_manager.cc terminate ] riccardo> Terminating module: fea [ 2005/11/04 00: 46:27 INFO riccardo> xorp_rtrmgr:1195 RTRMGR +247 module_manager.cc terminate ] riccardo> Terminating module: interfaces [ 2005/11/04 00:46:27 INFO riccardo> xorp_rtrmgr: 1195 RTRMGR +300 module_manager.cc terminate riccardo> ] Killing module: interfaces (pid = 0x4ac) [ 2005/11/04 riccardo> 00:46:27 INFO xorp_rtrmgr:1195 RTRMGR +247 riccardo> module_manager.cc terminate ] Terminating module: policy [ riccardo> 2005/11/04 00:46:27 INFO xorp_rtrmgr:1195 RTRMGR +300 riccardo> module_manager. cc terminate ] Killing module: policy riccardo> (pid = 0x4ae) [ 2005/11/04 00:46: 27 INFO xorp_rtrmgr:1195 riccardo> RTRMGR +247 module_manager.cc terminate ] Terminating riccardo> module: rib [ 2005/11/04 00:46:27 INFO xorp_rtrmgr:1195 riccardo> RTRMGR +300 module_manager.cc terminate ] Killing module: riccardo> rib (pid = 0x4ad) [ 2005/11/04 00:46:27 INFO riccardo> xorp_rtrmgr:1195 RTRMGR +247 module_manager.cc terminate ] riccardo> Terminating module: rip [ 2005/11/04 00: 46:27 INFO riccardo> xorp_rtrmgr:1195 RTRMGR +300 module_manager.cc terminate ] riccardo> Killing module: rip (pid = 0x4af) [ 2005/11/04 00:46:27 riccardo> INFO xorp_rtrmgr:1195 RTRMGR +664 module_manager.cc killed riccardo> ] Module killed during shutdown: policy [ 2005/11/04 riccardo> 00:46:27 INFO xorp_rtrmgr:1195 RTRMGR +664 riccardo> module_manager.cc killed ] Module killed during shutdown: riccardo> rib [ 2005/11/04 00:46:27 INFO xorp_rtrmgr:1195 RTRMGR riccardo> +664 module_manager.cc killed ] Module killed during riccardo> shutdown: interfaces [ 2005/11/04 00:46:27 INFO riccardo> xorp_rtrmgr:1195 RTRMGR +664 module_manager. cc killed ] riccardo> Module killed during shutdown: rip riccardo> Is there a different syntax for export rip managed route riccardo> or could it be a bug? riccardo> _______________________________________________ Xorp-users riccardo> mailing list Xorp-users@xorp.org riccardo> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From kristian@juniks.net Thu Nov 3 22:00:14 2005 From: kristian@juniks.net (Kristian Larsson) Date: Thu, 3 Nov 2005 23:00:14 +0100 Subject: [Xorp-hackers] redundant definitions Message-ID: <20051103220014.GA6225@juniks.net> I just tried to compile XORP with DEBUG_PRINT_FUNCTION_NAME turned on. This failed due to it being defined both in config.h and in ospf/xrl_io.cc I assume this is a mistake. Could you please remove DEBUG_PRINT_FUNCTION_NAME from ospf/xrl_io.cc? Thank you Kristian From kristian@juniks.net Thu Nov 3 22:35:47 2005 From: kristian@juniks.net (Kristian Larsson) Date: Thu, 3 Nov 2005 23:35:47 +0100 Subject: [Xorp-hackers] redundant definitions In-Reply-To: <20051103220014.GA6225@juniks.net> References: <20051103220014.GA6225@juniks.net> Message-ID: <20051103223546.GB6225@juniks.net> I spoke to soon with too little knowledge as I now see it is defined just about everywhere ;) Anyway ./configure --enable-debug-fnames doesn't work. The compile breaks. In file included from xrl_target.cc:21: ../config.h:50:1: "DEBUG_PRINT_FUNCTION_NAME"redefined xrl_target.cc:19:1: this is the location of the previous definition Kristian On Thu, Nov 03, 2005 at 11:00:14PM +0100, Kristian Larsson wrote: > I just tried to compile XORP with > DEBUG_PRINT_FUNCTION_NAME turned on. This failed > due to it being defined both in config.h and in > ospf/xrl_io.cc > I assume this is a mistake. Could you please > remove DEBUG_PRINT_FUNCTION_NAME from > ospf/xrl_io.cc? > > Thank you > > Kristian > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin@icir.org Fri Nov 4 00:46:50 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 03 Nov 2005 16:46:50 -0800 Subject: AW: [Xorp-hackers] Config Var <-> Config mode In-Reply-To: Message from "Patrick Preuss" of "Wed, 02 Nov 2005 21:12:59 +0100." <001401c5dfe9$d257a360$841cbb50@dedus737> Message-ID: <200511040046.jA40koG2028730@possum.icir.org> To: "Patrick Preuss" cc: "'Kristian Larsson'" , xorp-hackers@xorp.org Fcc: +outgo Subject: Re: AW: [Xorp-hackers] Config Var <-> Config mode In-Reply-To: Message from "Patrick Preuss" of "Wed, 02 Nov 2005 21:12:59 +0100." <001401c5dfe9$d257a360$841cbb50@dedus737> -------- A number of issues have been brought in this thread, so here is a summary (per issue) with a reply: * The configuration should support ";" at the end of each line statement (as Juniper does). The ";" is already supported as statement separator. E.g.: interfaces { interface rl0 { description: "control interface"; default-system-config; } } However, the configuration "show" command does not print ";" at the end of each statement. If printing ";" at the end of each statement when showing or saving the configuration is desired, we can apply this change. Also, I presume you refer only to the configuration files, because Juniper doesn't support ";" as a command separator inside the cli. Nevertheless, we think that supporting ";" inside the cli can be useful, e.g.: Xorp> show host os; show host date but this will require non-trivial changes to implement it. * Accept configuration statements like "varname value" in addition of "varname: value" so it is more Juniper-like. We will consider this and we will look more carefully into it. * "Currently you cannot cut and past the config" True, because we never claimed we are Juniper-compatible. Furthermore, note that even if we support the "varname value" syntax, you still won't be able to use the Juniper configuration as-is because of other differences like the structure of the configuration tree. * A statement that contains only the name of a bool variable should imply that its value is true. The deletion of that variable should imply its value becomes false. We have been thinking about something like this within the context of the "disable" bool flag. Right now you have to specify "disable: true" to disable an entity. To do it as Juniper does it we could need only a statement like "disable". * The subject of the "create" and "set" has been brought in the past, and I think there is an open bugzilla entry about this. There are arguments for keeping them separately, but lets not have the discussion again at this time. We will come back to it at some later stage. * Specifying a list of prefixes within a single variable is not practical: network4-list { elements: "1.0.0.0/24,1.0.1.0/24" } and similar to Juniper we should use instead: prefix-list test { 1.0.0.0/24; 2.0.0.0/24; } We agree with this and we need to do something about it. If I have missed something in this thread, it was unintentional so please specify it again. Pavlin From pavlin@icir.org Fri Nov 4 01:30:47 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 03 Nov 2005 17:30:47 -0800 Subject: [Xorp-hackers] How to add UDP socket I/O to PIM In-Reply-To: Message from Mark Doll of "Thu, 03 Nov 2005 15:28:17 +0100." <436A1E81.105@tm.uka.de> Message-ID: <200511040130.jA41UlUx005413@possum.icir.org> > Socket programming in C is normally quite easy and straight > forward, but within XORP, I'm totally lost. > > I'm browsing the XORP sources for some while now, have done some > modifications (see P.S.) and am now trying to figure out how XORP > modules implement XRL communication in general and socket I/O in > particular. I think I've understood how to use XRLs and how they > work (i. e. this magic callback factory function or why you can > savely destroy your XrlSomeInterfaceV0p1Client object directly > after XRL invocation but before receiving the callback with the > results). But I'm still quite unsure on how to do queueing and > buffering of those XRL calls within a XORP module and coordination > via the eventloop, especially within PIM, which I'm trying to > modify now. > > My question is: Has anybody a howto on this or can give me a few > lines of documented sample code which I can reuse? The docs/xorpdev_101 document contains some information about XORP processes and XRLs, but the question you are asking about is a bit too specific to be answered in that document. > Until now I've copy&pasted parts of RIP's socket4/6 and > socket4/6_user XRL interface usage/implementation (the complete > RIP socket I/O code is unadequately complex because I only have > one UDP socket, one neighbor (the BB) and no multicast). Currently > I think about something similar to PIM's queueing (class > XrlPimNode::XrlTaskBase and derived classes) that are used in > communication with the MFEA. PIM itself doesn't use UDP, hence the code doesn't contain anything about sending/receiving UDP packets. The model to use UDP for sending/receiving messages is similar to C sockets, except that the API is more abstract and sometimes a number of operations are combined with a single one. First, have a look at the xrl/interfaces/socket{4,6}.xif and the xrl/interfaces/socket{4,6}_user.xif XRL interface files. The socket{4,6}.xif interface specifies the API to open a TCP or UDP socket and to send data. The socket{4,6}_user.xif interface is the API for receiving data and for error notification. The PIM module needs to implement the socket{4,6}_user/0.1 XRL target interface so it can receive the XRLs. The xorpdev_101 document should explain how to do that. Also, inside the PIM module you need to call the appropriate XRLs to open the UDP socket. E.g., use udp_open_and_bind to get a handler for the opened socket, and then use that handler to join a multicast group (udp_join_group), send data by the "send_to" XRL, etc. Again, the xorpdev_101 should contain info how to call XRLs in general, and the RIP code itself shows you how to do it for those particular XRLs. The PIM's queueing (class XrlPimNode::XrlTaskBase) is needed primary to ensure that different type XRLs are transmitted in-order to the MFEA . In your case probably it doesn't matter because the UDP packets will be going to a different entity (to the BB via the FEA), but for the sake of being uniform with the XRL transmission from PIM I would still recommend to use that queue. Hope that helps, Pavlin > I don't know if this is the right way to do it, or if there's an > easier way to implement this. So I'll really appreciate any > help/hint/reassurance whatsoever. I think I'm lost in option space > and can't see the wood for the trees... > > Regards, Mark. > > P.S.: Some background about what I'm doing: > I'm implementing a simple extension to PIM, in which the PIM > daemon informs a bandwidth broker (BB) by (repeatedly) sending a > UDP datagram to the BB about an (in respect to QoS) unconfigured > MFC entry containing all necessary info for its descision > process. The BB in turn answers with one UDP datagram to tell PIM > either to forward packets with unmodified diffserv codepoint or to > reconfigure the multicast forwarding cache entry in the (FreeBSD) > kernel so tha all packets are remarked to lower effort (RFC 3662) > to handle the NRS problem (RFC 3754). It's a bit more complex than > this, but that's the basic scheme. The modifications to > FreeBSD/routing socket/MFEA are done, but the UDP socket to > communicate with the BB is still missing. Of course, in the future > plain UDP will be replaced by a real signaling protocol and > probably a redesign of the complete implementation. But for a > basic evaluation of the concept plain UDP is sufficient. From pavlin@icir.org Fri Nov 4 01:51:54 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 03 Nov 2005 17:51:54 -0800 Subject: [Xorp-hackers] AW: [Xorp-users] Does xorp latest CVS have some problem with the export command? In-Reply-To: Message from "Patrick Preuss" of "Thu, 03 Nov 2005 19:37:23 +0100." <004601c5e0a5$a488c6a0$c842bb50@dedus737> Message-ID: <200511040152.jA41psKF018974@possum.icir.org> > I have seen some smaller and bigger rewrites in the way xorp will or would > be configured, is it possible for the next release to add a way rtrmgr do > Not die when the configuration is "wrong" and to show this to the user only > for the startup config? Accidentally, this morning bugzilla entry #180 was resolved: http://www.xorp.org/bugzilla/show_bug.cgi?id=180 It addressed the case when the rtrmgr would exit if you try to change the configuration via xorpsh, and there was a missing executable file for one of the new modules. Probably it doesn't solve all bad "rtrmgr exit" scenarios when changing the configuration, but is a step in that direction. If you come across other cases when the rtrmgr exits during reconfiguration please bring it on. Note that exiting during startup if the configuration is bad is an intentional behavior. > May be add a functionality to rewrite old config into new one. And to > provide help in the configure mode so the user would notify, that this way > is obsolete, maybe for the next releases until Version 2.0? We have already support for notifying the user if some configuration statement is obsoleted: the "%deprecated" keyword in the configuration template files. E.g., add "enabled: true" config statement to an interface and try to start with or load that config file. The rtrmgr will refuse and will print a predefined error message. Unfortunately this mechanism has its limitations. E.g., it can tell you if a node in the configuration tree has been deprecated, but it cannot tell you if the syntax of a node has been changed (as it seems to be the case with the old/new policy for RIP). We don't have yet a functionality to rewrite old configs into new ones, because we are still in the process of tweaking various things, and such tool will quickly become obsolete (or an additional burden to maintain and keep it up to date). Pavlin From caddisconsulting@yahoo.com Fri Nov 4 02:48:25 2005 From: caddisconsulting@yahoo.com (Mike Horn) Date: Thu, 3 Nov 2005 18:48:25 -0800 (PST) Subject: [Xorp-hackers] Re: Prefix Lists In-Reply-To: <200511032001.jA3K1bm5008214@fruitcake.ICSI.Berkeley.EDU> Message-ID: <20051104024825.12240.qmail@web50204.mail.yahoo.com> I agree with Patrick and Kristian that it would be better to have prefix lists that behave like Juniper, this makes adding and deleting elements much easier. -mike --- xorp-hackers-request@icir.org wrote: > Send Xorp-hackers mailing list submissions to > xorp-hackers@icir.org > > To subscribe or unsubscribe via the World Wide Web, > visit > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > or, via email, send a message with subject or body > 'help' to > xorp-hackers-request@icir.org > > You can reach the person managing the list at > xorp-hackers-admin@icir.org > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of Xorp-hackers digest..." > > > Today's Topics: > > 1. Re: Config Var <-> Config mode ('Kristian > Larsson') > 2. AW: [Xorp-hackers] Config Var <-> Config mode > (Patrick Preuss) > 3. How to add UDP socket I/O to PIM (Mark Doll) > 4. AW: [Xorp-users] Does xorp latest CVS have > some problem with the export command? (Patrick > Preuss) > > --__--__-- > > Message: 1 > Date: Wed, 2 Nov 2005 21:00:51 +0100 > From: "'Kristian Larsson'" > To: Patrick Preuss > Cc: xorp-hackers@xorp.org > Subject: Re: [Xorp-hackers] Config Var <-> Config > mode > > On Wed, Nov 02, 2005 at 08:47:03PM +0100, Patrick > Preuss wrote: > > Hello > > > > > How about removing ":" from the configuration > file > > > and simply ignoring ";" at the end of line. This > > > would allow cut and paste with minimal changes. > > > Plus it would be more JunOS like. > > > > Yes removing : would be a good idea. > > But if it works under JunOS with ; we should have > > them in xorp to, it makes things easier, you see > > where the line / var ends. > > I'm just saying that the parser shouldn't react > to ";". If we print them in our configuration file > is another matter. > > Although having the parser ignore ";" you can't > write several "lines" on one line.. if you get my > drift :) > > Kristian > > > > > > > > > One of the thing that networking people really > > > love about Juniper is it's CLI, and thus making > > > > Yes. > > > > > XORP very similar to it is clever. However there > > > are several points where XORP differ from JunOS, > IMHO > > > this is often not to the better. The subject > brought > > > up here is one of them. > > > > > Another is that of the "set" command which in > XORP > > > is split into create and set. Makes sense > > > programming wise, not user wise. I know I have > > > brought this up before: > > Yes I have read it, think the Juniper way has some > advantages, and > > the way of xorp to, some of the concepts in other > routing platforms as > > cisco, riverstone / Enterasys also. > > > JunOS: > > > set prefix-list test 1.0.0.0/24 > > > set prefix-list test 2.0.0.0/24 > > > results in > > > prefix-list test { > > > 1.0.0.0/24; > > > 2.0.0.0/24; > > > } > > > > > XORP: > > > create network4-list test elements > 1.0.0.0/24,2.0.0.0/24 > > > results in > > > network4-list { > > > elements: "1.0.0.0/24,1.0.1.0/24" > > > } > > > > > Which one is the easier one to scim through? > Which > > > one is easier to add prefixes to? > > > > I think for reading and debugging the Juniper > version is better to read. > > The Xorp way double things I think { and elemets: > " means at this point the > > same. For programming the xorp has it vantages, > but who should it have > > easier the programmer or the user network > technican in this point, if you > > have a huge network, round about 500 Sites, you > will love all things witch > > makes the daily tasks easier.;-) > Indeed, "elements" is totally unnecessary, > everybodes knows a network list contains elements, > what else? ;) > And split up the lines! > > Adding a single prefix to a 500 prefix list would > require you to rewrite the whole list in XORP. Not > very efficient. > > > > I can't see anything other than programming > > > benefits to XORPs way. > > > > > Am I the only one of this opinion? > > > > Your not > Sweet. I'm not alone :) > > Kristian > > --__--__-- > > Message: 2 > From: "Patrick Preuss" > To: "'Kristian Larsson'" > Cc: > Subject: AW: [Xorp-hackers] Config Var <-> Config > mode > Date: Wed, 2 Nov 2005 21:12:59 +0100 > > > Hello > > > On Wed, Nov 02, 2005 at 08:47:03PM +0100, Patrick > Preuss wrote: > > > Hello > > > > > > > How about removing ":" from the configuration > file > > > > and simply ignoring ";" at the end of line. > This > > > > would allow cut and paste with minimal > changes. > > > > Plus it would be more JunOS like. > > > > > > Yes removing : would be a good idea. > > > But if it works under JunOS with ; we should > have > > > them in xorp to, it makes things easier, you see > > > > where the line / var ends. > > > I'm just saying that the parser shouldn't react > > to ";". If we print them in our configuration file > > is another matter. > > > Although having the parser ignore ";" you can't > > write several "lines" on one line.. if you get my > > drift :) > > Blame me, have got the same though;) > > > Kristian > > > > Indeed, "elements" is totally unnecessary, > > everybodes knows a network list contains elements, > > what else? ;) > > And split up the lines! > > > Adding a single prefix to a 500 prefix list would > > require you to rewrite the whole list in XORP. Not > > very efficient. > > Who can I pay to do this for me. > > This is like the old access-list's on cisco > > no access-list 101 > access-list 101 permit .... > > === message truncated === Mike Horn Caddis Consulting 303.882.7910 cell From deathdealer@gmx.net Fri Nov 4 09:45:46 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Fri, 4 Nov 2005 10:45:46 +0100 Subject: AW: [Xorp-hackers] AW: [Xorp-users] Does xorp latest CVS have some problem with the export command? In-Reply-To: <200511040152.jA41psKF018974@possum.icir.org> Message-ID: <000501c5e124$8959c080$760b000a@dedus737> > We have already support for notifying the user if some configuration > statement is obsoleted: the "%deprecated" keyword in the > configuration template files. E.g., add "enabled: true" > config statement to an interface and try to start with or load that config > file. The rtrmgr will refuse and will print a predefined error > message. If something similar to this happens during startup, eg. Read the config parts and mark them as obsolete / error, the line in the show config could look like: "E> enable: true" > Unfortunately this mechanism has its limitations. E.g., it can tell > you if a node in the configuration tree has been deprecated, but it > cannot tell you if the syntax of a node has been changed (as it > seems to be the case with the old/new policy for RIP). In this case the config file should contain something like the "version 12.4" line on the cisco's so you could determine witch parts are differ Between versions. So it will be possible to show parts witch have been obsolete, changed and so on. > We don't have yet a functionality to rewrite old configs into new > ones, because we are still in the process of tweaking various > things, and such tool will quickly become obsolete (or an additional > burden to maintain and keep it up to date). I think not to rewrite the config in all parts, may the rip is such a thing where it goes or not, have not thought about it yet, but for example: If the config changes from: Protocols { Ospf4 { .... } } To Protocols { Ospf { .... keeps the same } } The next time you write the config there will be the new version. You can add a mechanism for such rules, something like check config url, it will have the side effect for an "aaa" subsystem, you can control the access to statements for a user, group, like the Juniper does. I know this will be A lot of work ;-) But for Production env. Where you might not have full access it would be a good idea. Patrick From deathdealer@gmx.net Fri Nov 4 09:49:54 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Fri, 4 Nov 2005 10:49:54 +0100 Subject: AW: AW: [Xorp-hackers] Config Var <-> Config mode In-Reply-To: <200511040046.jA40koG2028730@possum.icir.org> Message-ID: <000601c5e125$1df7dd30$760b000a@dedus737> Hello Pavlin, > A number of issues have been brought in this thread, so here is a > summary (per issue) with a reply: > > * The configuration should support ";" at the end of each line > statement (as Juniper does). > It would nice for the same look and feel. > > * Accept configuration statements like "varname value" in > addition of "varname: value" so it is more Juniper-like. > We will consider this and we will look more carefully into it. Nice, because currently supported is the entering of: varname value The resulting config shows varname: value > * "Currently you cannot cut and past the config" > True, because we never claimed we are Juniper-compatible. > Furthermore, note that even if we support the "varname value" > syntax, you still won't be able to use the Juniper configuration > as-is because of other differences like the structure of the > configuration tree. Seams a little misunderstanding, yes cut/past form a juniper would be nice As well but I thought of cut/past from another xorp system where you have all ready configured something like pollcy statements. > * A statement that contains only the name of a bool variable should > imply that its value is true. The deletion of that variable should > imply its value becomes false. > We have been thinking about something like this within the context > of the "disable" bool flag. Right now you have to specify > "disable: true" to disable an entity. To do it as Juniper does it > we could need only a statement like "disable". > > * The subject of the "create" and "set" has been brought in the > past, and I think there is an open bugzilla entry about this. > There are arguments for keeping them separately, but lets not have > the discussion again at this time. We will come back to it at > some later stage. > * Specifying a list of prefixes within a single variable is not > practical: > network4-list { > elements: "1.0.0.0/24,1.0.1.0/24" > } > and similar to Juniper we should use instead: > prefix-list test { > 1.0.0.0/24; > 2.0.0.0/24; > } > > We agree with this and we need to do something about it. Regards patrick From kristian@juniks.net Fri Nov 4 10:41:54 2005 From: kristian@juniks.net (Kristian Larsson) Date: Fri, 4 Nov 2005 11:41:54 +0100 Subject: [Xorp-hackers] AW: [Xorp-users] Does xorp latest CVS have some problem with the export command? In-Reply-To: <000501c5e124$8959c080$760b000a@dedus737> References: <200511040152.jA41psKF018974@possum.icir.org> <000501c5e124$8959c080$760b000a@dedus737> Message-ID: <20051104104153.GA27036@juniks.net> On Fri, Nov 04, 2005 at 10:45:46AM +0100, Patrick Preuss wrote: > > > > > We have already support for notifying the user if some configuration > > statement is obsoleted: the "%deprecated" keyword in the > > configuration template files. E.g., add "enabled: true" > > config statement to an interface and try to start with or load that config > > file. The rtrmgr will refuse and will print a predefined error > > message. > If something similar to this happens during startup, eg. Read the config > parts and mark them as obsolete / error, the line in the show config could > look like: "E> enable: true" I'm not sure if I understand you correctly, but I think I do and it's a great idea ;) When xorp reads a line it doesn't know what to do with (ie corrupt line, old configuration statement ...) it comments the line and marks it with error: E> or whatever is suitable. > > Unfortunately this mechanism has its limitations. E.g., it can tell > > you if a node in the configuration tree has been deprecated, but it > > cannot tell you if the syntax of a node has been changed (as it > > seems to be the case with the old/new policy for RIP). > > In this case the config file should contain something like the "version > 12.4" line on the cisco's so you could determine witch parts are differ > Between versions. So it will be possible to show parts witch have been > obsolete, changed and so on. My patch to BugZilla 53 includes this :) > > > We don't have yet a functionality to rewrite old configs into new > > ones, because we are still in the process of tweaking various > > things, and such tool will quickly become obsolete (or an additional > > burden to maintain and keep it up to date). > > I think not to rewrite the config in all parts, may the rip is such a thing > where it goes or not, have not thought about it yet, but for example: > If the config changes from: > > Protocols { > Ospf4 { > .... > } > } > > To > > Protocols { > Ospf { > .... keeps the same > } > } > > The next time you write the config there will be the new version. > > You can add a mechanism for such rules, something like check config url, it > will have the side effect for an "aaa" subsystem, you can control the access > to statements for a user, group, like the Juniper does. I know this will be > A lot of work ;-) > > But for Production env. Where you might not have full access it would be a > good idea. I think it's both difficult and dangerous to have XORP change stuff automatically for you, it would be better to just warn and let the user decide on action. I don't really understand what you mean with the AAA system? Kristian > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From deathdealer@gmx.net Fri Nov 4 12:53:16 2005 From: deathdealer@gmx.net (Patrick Marc Preuss) Date: Fri, 4 Nov 2005 13:53:16 +0100 (MET) Subject: [Xorp-hackers] =?ISO-8859-1?Q?Re:_[Xorp-hackers]_AW:_[Xorp-users]_Does_xorp_latest_CVS_h?= =?ISO-8859-1?Q?ave_some_problem_with_the_export_command=3F?= References: <20051104104153.GA27036@juniks.net> Message-ID: <1756.1131108796@www20.gmx.net> > --- Ursprüngliche Nachricht --- > Von: Kristian Larsson > An: Patrick Preuss > Kopie: xorp-hackers@xorp.org > Betreff: Re: [Xorp-hackers] AW: [Xorp-users] Does xorp latest CVS have > some problem with the export command? > Datum: Fri, 4 Nov 2005 11:41:54 +0100 > > On Fri, Nov 04, 2005 at 10:45:46AM +0100, Patrick Preuss wrote: > > > > > > > > > We have already support for notifying the user if some configuration > > > statement is obsoleted: the "%deprecated" keyword in the > > > configuration template files. E.g., add "enabled: true" > > > config statement to an interface and try to start with or load that > config > > > file. The rtrmgr will refuse and will print a predefined error > > > message. > > If something similar to this happens during startup, eg. Read the config > > parts and mark them as obsolete / error, the line in the show config > could > > look like: "E> enable: true" > > I'm not sure if I understand you correctly, but I > think I do and it's a great idea ;) > When xorp reads a line it doesn't know what to do > with (ie corrupt line, old configuration statement > ...) it comments the line and marks it with error: > E> or whatever is suitable. Yes thats right. > > > > Unfortunately this mechanism has its limitations. E.g., it can tell > > > you if a node in the configuration tree has been deprecated, but it > > > cannot tell you if the syntax of a node has been changed (as it > > > seems to be the case with the old/new policy for RIP). > > > > In this case the config file should contain something like the "version > > 12.4" line on the cisco's so you could determine witch parts are differ > > Between versions. So it will be possible to show parts witch have been > > obsolete, changed and so on. > My patch to BugZilla 53 includes this :) > > > > > We don't have yet a functionality to rewrite old configs into new > > > ones, because we are still in the process of tweaking various > > > things, and such tool will quickly become obsolete (or an additional > > > burden to maintain and keep it up to date). > > > > I think not to rewrite the config in all parts, may the rip is such a > thing > > where it goes or not, have not thought about it yet, but for example: > > If the config changes from: > > > > Protocols { > > Ospf4 { > > .... > > } > > } > > > > To > > > > Protocols { > > Ospf { > > .... keeps the same > > } > > } > > > > The next time you write the config there will be the new version. > > > > You can add a mechanism for such rules, something like check config url, > it > > will have the side effect for an "aaa" subsystem, you can control the > access > > to statements for a user, group, like the Juniper does. I know this will > be > > A lot of work ;-) > > > > But for Production env. Where you might not have full access it would be > a > > good idea. > > > I think it's both difficult and dangerous to have > XORP change stuff automatically for you, it would > be better to just warn and let the user decide on > action. Yes for the most things right, but i have experrenced on IOS if you configure in 12.3T line "crypto pki ..." you would be warned in 12.4 line this command is obsolete and will be replaced with "crypto ca ...", underlying the same config. its only smallthings like a change from ospf4 to ospf in the nameing which should be replaced by such a mechanism. While loading the saved config this is done sillent;-) Nice the system comes up and you have the things running;-) I think this would be nice so you can upgrade routers at remote locations, my company has 500 locations all over Europe, so you can't drive to any routerdo this by hand. > > I don't really understand what you mean with the > AAA system? aaa stands usualy for autentication, authorisation and accounting. With this you can say user a can do all things on the router, user b can not or can only edit interface config or can change the state of interfaces but is not allowed to edit routing processes. You can use this subsystem for Dial-In, ipsec and so on. > > Kristian > > > > > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers@icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > Patrick -- best regards Patrick Marc Preuss ---------------------------------------------------------------------- -- "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" (1979) Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie From kristian@juniks.net Fri Nov 4 13:43:37 2005 From: kristian@juniks.net (Kristian Larsson) Date: Fri, 4 Nov 2005 14:43:37 +0100 Subject: [Xorp-hackers] AW: [Xorp-users] Does xorp latest CVS have some problem with the export command? In-Reply-To: <1756.1131108796@www20.gmx.net> References: <20051104104153.GA27036@juniks.net> <1756.1131108796@www20.gmx.net> Message-ID: <20051104134337.GB27036@juniks.net> On Fri, Nov 04, 2005 at 01:53:16PM +0100, Patrick Marc Preuss wrote: > > --- Ursprüngliche Nachricht --- > > Von: Kristian Larsson > > An: Patrick Preuss > > Kopie: xorp-hackers@xorp.org > > Betreff: Re: [Xorp-hackers] AW: [Xorp-users] Does xorp latest CVS have > > some problem with the export command? > > Datum: Fri, 4 Nov 2005 11:41:54 +0100 > > > > On Fri, Nov 04, 2005 at 10:45:46AM +0100, Patrick Preuss wrote: > > > > > > > > > > > > > We have already support for notifying the user if some configuration > > > > statement is obsoleted: the "%deprecated" keyword in the > > > > configuration template files. E.g., add "enabled: true" > > > > config statement to an interface and try to start with or load that > > config > > > > file. The rtrmgr will refuse and will print a predefined error > > > > message. > > > If something similar to this happens during startup, eg. Read the config > > > parts and mark them as obsolete / error, the line in the show config > > could > > > look like: "E> enable: true" > > > > I'm not sure if I understand you correctly, but I > > think I do and it's a great idea ;) > > When xorp reads a line it doesn't know what to do > > with (ie corrupt line, old configuration statement > > ...) it comments the line and marks it with error: > > E> or whatever is suitable. > > Yes thats right. Great! > > > > > > Unfortunately this mechanism has its limitations. E.g., it can tell > > > > you if a node in the configuration tree has been deprecated, but it > > > > cannot tell you if the syntax of a node has been changed (as it > > > > seems to be the case with the old/new policy for RIP). > > > > > > In this case the config file should contain something like the "version > > > 12.4" line on the cisco's so you could determine witch parts are differ > > > Between versions. So it will be possible to show parts witch have been > > > obsolete, changed and so on. > > My patch to BugZilla 53 includes this :) > > > > > > > We don't have yet a functionality to rewrite old configs into new > > > > ones, because we are still in the process of tweaking various > > > > things, and such tool will quickly become obsolete (or an additional > > > > burden to maintain and keep it up to date). > > > > > > I think not to rewrite the config in all parts, may the rip is such a > > thing > > > where it goes or not, have not thought about it yet, but for example: > > > If the config changes from: > > > > > > Protocols { > > > Ospf4 { > > > .... > > > } > > > } > > > > > > To > > > > > > Protocols { > > > Ospf { > > > .... keeps the same > > > } > > > } > > > > > > The next time you write the config there will be the new version. > > > > > > You can add a mechanism for such rules, something like check config url, > > it > > > will have the side effect for an "aaa" subsystem, you can control the > > access > > > to statements for a user, group, like the Juniper does. I know this will > > be > > > A lot of work ;-) > > > > > > But for Production env. Where you might not have full access it would be > > a > > > good idea. > > > > > > I think it's both difficult and dangerous to have > > XORP change stuff automatically for you, it would > > be better to just warn and let the user decide on > > action. > > Yes for the most things right, but i have experrenced on IOS if you > configure in 12.3T line "crypto pki ..." you would be warned in 12.4 line > this command is obsolete and will be replaced with "crypto ca ...", > underlying the same config. its only smallthings like a change from ospf4 to > ospf in the nameing which should be replaced by such a mechanism. > While loading the saved config this is done sillent;-) Nice the system comes > up and you have the things running;-) I think this would be nice so you can > upgrade routers at remote locations, my company has 500 locations all over > Europe, so you can't drive to any routerdo this by hand. I still think it's dangerous. What if you just wanna try out a new version, you find out it sucks. You switch back. But the new xorp has rearranged your configuration file so now the old version won't accept it. Warning is enough ;) > > I don't really understand what you mean with the > > AAA system? > > aaa stands usualy for autentication, authorisation and accounting. > With this you can say user a can do all things on the router, user b can not > or can only edit interface config or can change the state of interfaces but > is not allowed to edit routing processes. You can use this subsystem for > Dial-In, ipsec and so on. I am aware of what it is. I've setup a numerous TACACS solutions ;) What I don't understand is how this automagic check of configuration files will affect AAA? Kristian > > > > Kristian > > > > > > > > > > > > _______________________________________________ > > > Xorp-hackers mailing list > > > Xorp-hackers@icir.org > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers@icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > Patrick > > -- > best regards > Patrick Marc Preuss > ---------------------------------------------------------------------- > -- > > "...a hundred billion castaways looking for a home." > - Sting "Message in a > Bottle" (1979) > > Telefonieren Sie schon oder sparen Sie noch? > NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie From deathdealer@gmx.net Fri Nov 4 15:35:13 2005 From: deathdealer@gmx.net (Patrick Marc Preuss) Date: Fri, 4 Nov 2005 16:35:13 +0100 (MET) Subject: [Xorp-hackers] =?ISO-8859-1?Q?Re:_[Xorp-hackers]_AW:_[Xorp-users]_Does_xorp_latest_CVS_h?= =?ISO-8859-1?Q?ave_some_problem_with_the_export_command=3F?= References: <20051104134337.GB27036@juniks.net> Message-ID: <30111.1131118513@www20.gmx.net> > I still think it's dangerous. > What if you just wanna try out a new version, you > find out it sucks. You switch back. But the new > xorp has rearranged your configuration file so now > the old version won't accept it. > Warning is enough ;) Oh, well what i meant was no to save the config automaticly, only the running config should be affected. and if you have as system like Juniper where you have up to 50 Versions it might also be possible to go back. Normaly you wouldn't jump from: 10.1 -> 12.4 on all routers you would check this with some routers nearby. Normaly you would go from 12.4.1 -> 12.4.1a or 12.4.3 some minor steps where such big changes normaly would not made. This is a thing how the lifecycle of the versions is. > > > > I don't really understand what you mean with the > > > AAA system? > > > > aaa stands usualy for autentication, authorisation and accounting. > > With this you can say user a can do all things on the router, user b can > not > > or can only edit interface config or can change the state of interfaces > but > > is not allowed to edit routing processes. You can use this subsystem for > > Dial-In, ipsec and so on. > I am aware of what it is. I've setup a numerous > TACACS solutions ;) > What I don't understand is how this automagic > check of configuration files will affect AAA? >From my point of view the same function in the code can check if the command is valid for the actual system and for the user who whants to do this. -- best regards Patrick Marc Preuss ---------------------------------------------------------------------- -- "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" (1979) Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat, DSL-Flatrate für nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl From atanu@ICSI.Berkeley.EDU Fri Nov 4 20:56:48 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 04 Nov 2005 12:56:48 -0800 Subject: [Xorp-hackers] redundant definitions In-Reply-To: Message from Kristian Larsson of "Thu, 03 Nov 2005 23:35:47 +0100." <20051103223546.GB6225@juniks.net> Message-ID: <99647.1131137808@tigger.icir.org> This problem should now be fixed. Atanu. >>>>> "Kristian" == Kristian Larsson writes: Kristian> I spoke to soon with too little knowledge as I now see it Kristian> is defined just about everywhere ;) Kristian> Anyway ./configure --enable-debug-fnames doesn't work. The Kristian> compile breaks. Kristian> In file included from xrl_target.cc:21: ../config.h:50:1: Kristian> "DEBUG_PRINT_FUNCTION_NAME"redefined xrl_target.cc:19:1: Kristian> this is the location of the previous definition Kristian> Kristian Kristian> On Thu, Nov 03, 2005 at 11:00:14PM +0100, Kristian Larsson Kristian> wrote: >> I just tried to compile XORP with DEBUG_PRINT_FUNCTION_NAME >> turned on. This failed due to it being defined both in config.h >> and in ospf/xrl_io.cc I assume this is a mistake. Could you >> please remove DEBUG_PRINT_FUNCTION_NAME from ospf/xrl_io.cc? >> >> Thank you >> >> Kristian >> >> _______________________________________________ Xorp-hackers >> mailing list Xorp-hackers@icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers Kristian> _______________________________________________ Kristian> Xorp-hackers mailing list Xorp-hackers@icir.org Kristian> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian@juniks.net Fri Nov 4 22:58:59 2005 From: kristian@juniks.net (Kristian Larsson) Date: Fri, 4 Nov 2005 23:58:59 +0100 Subject: [Xorp-hackers] AW: [Xorp-users] Does xorp latest CVS have some problem with the export command? In-Reply-To: <30111.1131118513@www20.gmx.net> References: <20051104134337.GB27036@juniks.net> <30111.1131118513@www20.gmx.net> Message-ID: <20051104225858.GB30265@juniks.net> On Fri, Nov 04, 2005 at 04:35:13PM +0100, Patrick Marc Preuss wrote: > > > I still think it's dangerous. > > What if you just wanna try out a new version, you > > find out it sucks. You switch back. But the new > > xorp has rearranged your configuration file so now > > the old version won't accept it. > > Warning is enough ;) > > Oh, well what i meant was no to save the config automaticly, > only the running config should be affected. and if you have as > system like Juniper where you have up to 50 Versions it might also > be possible to go back. > > Normaly you wouldn't jump from: 10.1 -> 12.4 on all routers you would check > this with some routers nearby. Normaly you would go from 12.4.1 -> 12.4.1a > or 12.4.3 some minor steps where such big changes normaly would not made. > > This is a thing how the lifecycle of the versions is. Still, I don't see why stuff should change automagically? You test the new software on one system, you'll notice ospf4 has changed name to ospf, you change your configs and voila it works ;) Perhaps this should be an option in that alternative configuraion we've discussed (you know the one with a second config file or compile time options). > > > > > > > I don't really understand what you mean with the > > > > AAA system? > > > > > > aaa stands usualy for autentication, authorisation and accounting. > > > With this you can say user a can do all things on the router, user b can > > not > > > or can only edit interface config or can change the state of interfaces > > but > > > is not allowed to edit routing processes. You can use this subsystem for > > > Dial-In, ipsec and so on. > > I am aware of what it is. I've setup a numerous > > TACACS solutions ;) > > What I don't understand is how this automagic > > check of configuration files will affect AAA? > > From my point of view the same function in the code can check if the command > is valid for the actual system and for the user who whants to do this. Aha! Although it is a good idea I don't beleive that these functions would share very much code-wise. Though I'm probably wrong ;) Kristian From kristian@juniks.net Fri Nov 4 23:18:42 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sat, 5 Nov 2005 00:18:42 +0100 Subject: [Xorp-hackers] fea Message-ID: <20051104231841.GC30265@juniks.net> Is there more specific information on the FEA? I tried reading the fea.pdf document but it gave very little. I am trying to understand how xorp handles vif configuration. add_vif seems to be just about a dummy function, is it ever called? Kristian From pavlin@icir.org Sat Nov 5 01:03:55 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 04 Nov 2005 17:03:55 -0800 Subject: [Xorp-hackers] fea In-Reply-To: Message from Kristian Larsson of "Sat, 05 Nov 2005 00:18:42 +0100." <20051104231841.GC30265@juniks.net> Message-ID: <200511050103.jA513tVg017079@possum.icir.org> > Is there more specific information on the FEA? > I tried reading the fea.pdf document but it gave > very little. I am trying to understand how xorp > handles vif configuration. It uses the xrl/interfaces/fea_ifmgr.xif XRL interface: start_transaction -> tid create_interface ... set_... create_vif set_... create_address4 set_... create_address6 set_... commit_transaction The interfaces template etc/templates/interfaces.tp contains the particular XRLs invoked when the interface-related configuration is changed. Note that any changes to the configured interface tree are wrapped inside "start_transaction/commit_transaction". > add_vif seems to be just about a dummy function, > is it ever called? Do you mean the add_vif methods declared inside fea/ifconfig_set.hh? Those are used inside fea/ifconfig_set.cc Pavlin From deathdealer@gmx.net Sat Nov 5 02:03:30 2005 From: deathdealer@gmx.net (Patrick Marc Preuss) Date: Sat, 05 Nov 2005 03:03:30 +0100 Subject: [Xorp-hackers] AW: [Xorp-users] Does xorp latest CVS have some problem with the export command? In-Reply-To: <20051104225858.GB30265@juniks.net> References: <20051104134337.GB27036@juniks.net> <30111.1131118513@www20.gmx.net> <20051104225858.GB30265@juniks.net> Message-ID: <436C12F2.9040009@gmx.net> Kristian Larsson wrote: >On Fri, Nov 04, 2005 at 04:35:13PM +0100, Patrick Marc Preuss wrote: > > >>>I still think it's dangerous. >>>What if you just wanna try out a new version, you >>>find out it sucks. You switch back. But the new >>>xorp has rearranged your configuration file so now >>>the old version won't accept it. >>>Warning is enough ;) >>> >>> >>Oh, well what i meant was no to save the config automaticly, >>only the running config should be affected. and if you have as >>system like Juniper where you have up to 50 Versions it might also >>be possible to go back. >> >>Normaly you wouldn't jump from: 10.1 -> 12.4 on all routers you would check >>this with some routers nearby. Normaly you would go from 12.4.1 -> 12.4.1a >>or 12.4.3 some minor steps where such big changes normaly would not made. >> >>This is a thing how the lifecycle of the versions is. >> >> >Still, I don't see why stuff should change >automagically? >You test the new software on one system, you'll >notice ospf4 has changed name to ospf, you change >your configs and voila it works ;) > >Perhaps this should be an option in that >alternative configuraion we've discussed (you know >the one with a second config file or compile time >options). > > Yes seams to be a good idea ;-) >>>>>I don't really understand what you mean with the >>>>>AAA system? >>>>> >>>>> >>>>aaa stands usualy for autentication, authorisation and accounting. >>>>With this you can say user a can do all things on the router, user b can >>>> >>>> >>>not >>> >>> >>>>or can only edit interface config or can change the state of interfaces >>>> >>>> >>>but >>> >>> >>>>is not allowed to edit routing processes. You can use this subsystem for >>>>Dial-In, ipsec and so on. >>>> >>>> >>>I am aware of what it is. I've setup a numerous >>>TACACS solutions ;) >>>What I don't understand is how this automagic >>>check of configuration files will affect AAA? >>> >>> >>From my point of view the same function in the code can check if the command >>is valid for the actual system and for the user who whants to do this. >> >> >Aha! >Although it is a good idea I don't beleive that >these functions would share very much code-wise. >Though I'm probably wrong ;) > > I have tought of a routine witch simply might look like, but if have not found the time to dig into the code yet ;-( : void check_fup (cfgvars, etc. ) { if ( cfgvars == "regex_rewrite_var") { do_rewrite(vars); return; } if ( cfgvars != "regex_valid_cmds_user") { print_err ("This is not valid for user pmp"); } } Patrick From kristian@juniks.net Sat Nov 5 10:25:13 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sat, 5 Nov 2005 11:25:13 +0100 Subject: [Xorp-hackers] TID? Message-ID: <20051105102513.GC29892@juniks.net> XORP# create interfaces ? Possible completions: <[Enter]> Execute this command TID -- no help available -- interface Configure a network interface restore-original-config-on-shutdown Restore original configuration on shutdown targetname Set the target name { enter text on multiple lines XORP# create interfaces TID = transaction ID, right? but what is it doing there? testing stuff or can we actually something with it? Kristian From pavlin@icir.org Sat Nov 5 20:30:09 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sat, 05 Nov 2005 12:30:09 -0800 Subject: [Xorp-hackers] TID? In-Reply-To: Message from Kristian Larsson of "Sat, 05 Nov 2005 11:25:13 +0100." <20051105102513.GC29892@juniks.net> Message-ID: <200511052030.jA5KU9JY001821@possum.icir.org> > XORP# create interfaces ? > Possible completions: > <[Enter]> Execute this command > TID -- no help available -- > interface Configure a network interface > restore-original-config-on-shutdown Restore original configuration on shutdown > targetname Set the target name > { enter text on multiple lines > XORP# create interfaces > > TID = transaction ID, right? > but what is it doing there? > testing stuff or can we actually something with it? Yes, TID = transaction ID. It is used internally by the rtrmgr to store intermediate state when (re)configuring the network interfaces. Given that it is needed only by the rtrmgr itself, there is no reason it should be listed as a possible completion for the "create", or "set" xorpsh commands. Furthermore, it shouldn't be printed by the "show" or by the "save" commands. To isolate that internal variable, we need to declare it in some special way (e.g., by using some new template keyword like %hidden). I just added a bugzilla entry for this: http://www.xorp.org/bugzilla/show_bug.cgi?id=333 Pavlin From hasso@linux.ee Sun Nov 6 13:35:20 2005 From: hasso@linux.ee (Hasso Tepper) Date: Sun, 6 Nov 2005 15:35:20 +0200 Subject: [Xorp-hackers] Some thoughts Message-ID: <200511061535.20799.hasso@linux.ee> I have been looking through current state of Xorp project, made some tests and reported some bugs (more to follow hopefully) and read quickly through hackers list with hope that I can use Xorp as base of some inhouse platforms in long term. Here are some of my thoughts. Interface handling. Xorp ignores runtime address/interface deletes/adds from OS and users have to configure all interfaces in Xorp. As I understand it, it's done by design and I remember some of developers saying that it will not change as main focus of Xorp is research platform. It prevents to use Xorp as software for production in many cases (including mine, seems). But this requirement is IMHO strange even for research platform: * You have to configure even IPv6 link local addresses which is business of underlying stack and out of users control in every platform I know * It doesn't allow to use Xorp together with software which modify addresses and routes - high availability stuff for example (vrrp, carp etc.) Ability to configure nonexistant (yet) devices is must be as well (in the cases like hotlug, tunnels etc.) in any production system. If device will appear, it will be configured by Xorp. Interface/vif concept is a little bit strange as well - ie. mostly naming decision. Forcing to use just the same name of vif by default is bad enough. What "show interface fxp0" shows to me? Interface or vif? It might not be so important at the moment, but I'm almost sure that there will be cases in future when it matters. And how to fit existing vlan naming schemes in unixes to that model? It might sound lame (how many times it was written in this list? ;), but I really think that Junos way is better in this respect - . and vif define vif 0 as special - vif directly on top of physical interface without any virtual device in system. (I know that it doesn't solve any problems for systems where virtual interface naming scheme doesn't contain any link to physical interface though.) Configuration handling I have read through threads in list and object strongly to ideas to have functionality to rewrite configuration by new version to be compatible. Nothing like this should happen in routers I maintain ;). My idea to define behaviour to deal with deprecated and incompatible changes via template keywords: %deprecated - Using this command is not recommended any more, but software still handles this. It's hidden in CLI (doesn't appear in possible completions list) and if used by user, comment is added to the configuration - "use xxx instead". With clearly defined deprecating mechanism it gives good way to handle just syntax changes gracefully. For example "deprecated command is there for one stable version and will be removed after that". %incompatible - Software doesn't handle this construct any more. There should be way to parse configuration before executing (restart) the new software and to give error in these cases (and in case of just error) - "This construct will be ignored by version you are upgrading to." Anyway, project looks very promising and I hope to contribute at least via bugreports in the future as well. And I'm sure that at least one Xorp install will stay there in my lab. with my best wishes, -- Hasso Tepper From deathdealer@gmx.net Sun Nov 6 17:25:58 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Sun, 6 Nov 2005 18:25:58 +0100 Subject: AW: [Xorp-hackers] Some thoughts In-Reply-To: <200511061535.20799.hasso@linux.ee> Message-ID: <000001c5e2f7$278b3080$1608000a@dedus737> Hello > Configuration handling > I have read through threads in list and object strongly to ideas to have > functionality to rewrite configuration by new version to be compatible. > Nothing like this should happen in routers I maintain ;). My idea to You are right should not ;) But major vendors have it allway done and for some parts of configurations it might be ok, as you followed the discussion, It might be a compile time option to do this and I spoke about to rewrite things only in the case when some naming conventions change eg.: ospf4 -> ospf. For my part this is ok, to correct things to new naming scheme, but if major Funtionality changes, like in the rip process, there must be a way to transition from Version 1.1 -> 1.2 without rewriteing the config in advance. The Config should be written by the rtrmgr, and not by hand. >From my point of view the Software should help you doing an upgrade from one version to another. Major rewrites shouldn't be done, that's right, this should be marked as "E>" in the show, so the user has the chance to see there is something wrong. And may be the software should accept old and new things for a while. Regards, Patrick From kristian@juniks.net Sun Nov 6 17:37:31 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sun, 6 Nov 2005 18:37:31 +0100 Subject: [Xorp-hackers] Some thoughts In-Reply-To: <200511061535.20799.hasso@linux.ee> References: <200511061535.20799.hasso@linux.ee> Message-ID: <20051106173731.GE29892@juniks.net> On Sun, Nov 06, 2005 at 03:35:20PM +0200, Hasso Tepper wrote: > I have been looking through current state of Xorp project, made some > tests and reported some bugs (more to follow hopefully) and read quickly > through hackers list with hope that I can use Xorp as base of some > inhouse platforms in long term. Here are some of my thoughts. > > Interface handling. > > Xorp ignores runtime address/interface deletes/adds from OS and users > have to configure all interfaces in Xorp. As I understand it, it's done > by design and I remember some of developers saying that it will not > change as main focus of Xorp is research platform. It prevents to use > Xorp as software for production in many cases (including mine, seems). > But this requirement is IMHO strange even for research platform: > > * You have to configure even IPv6 link local addresses which is business > of underlying stack and out of users control in every platform I know > * It doesn't allow to use Xorp together with software which modify > addresses and routes - high availability stuff for example (vrrp, carp > etc.) > > Ability to configure nonexistant (yet) devices is must be as well (in the > cases like hotlug, tunnels etc.) in any production system. If device will > appear, it will be configured by Xorp. Indeed. The hard focus on research should not impare the functionality in such way that it's not suited for production work and neither should it be the other way around. In lots of cases I think there are compromises in other we would need to leave it to the user in the form of compile time options or regular configuration statements which alter the behaviour of XORP. > Interface/vif concept is a little bit strange as well - ie. mostly naming > decision. Forcing to use just the same name of vif by default is bad > enough. What "show interface fxp0" shows to me? Interface or vif? It > might not be so important at the moment, but I'm almost sure that there > will be cases in future when it matters. And how to fit existing vlan > naming schemes in unixes to that model? It might sound lame (how many > times it was written in this list? ;), but I really think that Junos way > is better in this respect - . and vif define vif 0 as > special - vif directly on top of physical interface without any virtual > device in system. > (I know that it doesn't solve any problems for systems where virtual > interface naming scheme doesn't contain any link to physical interface > though.) I would agree as also proposed in http://www.xorp.org/bugzilla/show_bug.cgi?id=329 And for systems such as FreeBSD where the virtual interface naming scheme doesn't contain any link to physical interfaces, as pointed out by Hasso, we would have some form of hidden variable which keeps track of what virtual interface connect to which physical ones. > > Configuration handling > > I have read through threads in list and object strongly to ideas to have > functionality to rewrite configuration by new version to be compatible. > Nothing like this should happen in routers I maintain ;). My idea to > define behaviour to deal with deprecated and incompatible changes via > template keywords: > > %deprecated - Using this command is not recommended any more, but > software still handles this. It's hidden in CLI (doesn't appear in > possible completions list) and if used by user, comment is added to the > configuration - "use xxx instead". With clearly defined deprecating > mechanism it gives good way to handle just syntax changes gracefully. For > example "deprecated command is there for one stable version and will be > removed after that". > > %incompatible - Software doesn't handle this construct any more. There > should be way to parse configuration before executing (restart) the new > software and to give error in these cases (and in case of just error) - > "This construct will be ignored by version you are upgrading to." This sounds like an excellent idea. > > Anyway, project looks very promising and I hope to contribute at least > via bugreports in the future as well. And I'm sure that at least one Xorp > install will stay there in my lab. I'm glad to hear. Kind regards, Kristian Larsson From M.Handley@cs.ucl.ac.uk Sun Nov 6 21:04:30 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Sun, 6 Nov 2005 21:04:30 +0000 Subject: [Xorp-hackers] Some thoughts In-Reply-To: <200511061535.20799.hasso@linux.ee> References: <200511061535.20799.hasso@linux.ee> Message-ID: <84a612dd0511061304o7198cf6eib31651f63b00c341@mail.gmail.com> On 11/6/05, Hasso Tepper wrote: > Interface handling. > > Xorp ignores runtime address/interface deletes/adds from OS and users > have to configure all interfaces in Xorp. As I understand it, it's done > by design and I remember some of developers saying that it will not > change as main focus of Xorp is research platform. It prevents to use > Xorp as software for production in many cases (including mine, seems). > But this requirement is IMHO strange even for research platform: > > * You have to configure even IPv6 link local addresses which is business > of underlying stack and out of users control in every platform I know > * It doesn't allow to use Xorp together with software which modify > addresses and routes - high availability stuff for example (vrrp, carp > etc.) This is nothing to do with it being a research platform, and everything to do with not having a well-defined alternative. The question is really one of who is in charge. The long-term goal is to have a complete router, where you never want or need to bypass the FEA for something as basic as interface config. Now, suppose I configure the IP address of an interface through the rtrmgr. The FEA will set this interface address. And now someone changes it through ifconfig or whatever. What is the correct action for XORP to do? The IP address has been configured in XORP, so XORP should in principle believe this is still what is wanted. If it observes the change, then it should re-configure it back, as XORP is still configured to set this particular address. An alternative is for XORP to monitor the machine state, and consider the rest of the machine is in charge. In which case it would then change it's running config automatically. But the general idea is the running config is set by a human, so having this change under you isn't principle of least surprise. The end result is that there is no good answer to this. As XORP is intended not as just a routing daemon, but as the entire router control plane (yes, long-term plan), then the most sensible (and certainly simplest) answer is "XORP is in charge". We discussed this ad-nauseum in the early days of XORP, and ended up with this decision. There is simply no good solution to this that everyone would be happy with - you have to decide who is in charge. Now, the IPv6 link-local address issue is one where the kernel should be in charge. Not any other user-space daemon. Thus this is obviously one we should handle better than we do. And issues such as CARP/VRRP should be handled in a what that the user specifies somehow that this address is to be set automatically, and so can change under you. We don't have the hooks for this right now, and should have. But there's only so much time, and so many things to do. Cheers, Mark From M.Handley@cs.ucl.ac.uk Sun Nov 6 21:13:20 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Sun, 6 Nov 2005 21:13:20 +0000 Subject: [Xorp-hackers] Some thoughts In-Reply-To: <200511061535.20799.hasso@linux.ee> References: <200511061535.20799.hasso@linux.ee> Message-ID: <84a612dd0511061313r52912688j3917d8178b6980ae@mail.gmail.com> On 11/6/05, Hasso Tepper wrote: > Interface/vif concept is a little bit strange as well - ie. mostly naming > decision. Forcing to use just the same name of vif by default is bad > enough. What "show interface fxp0" shows to me? Interface or vif? It > might not be so important at the moment, but I'm almost sure that there > will be cases in future when it matters. And how to fit existing vlan > naming schemes in unixes to that model? It might sound lame (how many > times it was written in this list? ;), but I really think that Junos way > is better in this respect - . and vif define vif 0 as > special - vif directly on top of physical interface without any virtual > device in system. > (I know that it doesn't solve any problems for systems where virtual > interface naming scheme doesn't contain any link to physical interface > though.) This is another area where there is no good solution. The standard Unix naming scheme sucks, and was a hack to retro-fit virtual interface naming into a framework that was intended only for physical interface naming. Juniper's naming scheme is the ideal. But they re-wrote the networking stack, and we only get that luxury when we run on click, which we don't want to mandate. We couldn't do this and run on a stock Unix forwarding path. So, the compromise is what we ended up with. We have the physical/virtual split being explicit, which allows properties of physical interfaces to be dealt with as a whole, and provides an appropriate framework for dealing with things such as creating VLANs or ATM VCs on a physical interface (where we have a forwarding path such as click, and control over naming). But we also have a namespace (VIFs) which can directly map to Unix interface names when we're running on regular Unix kernels. It may seem a bit odd, but the requirements are a bit odd too. Cheers, Mark From caddisconsulting@yahoo.com Mon Nov 7 04:22:56 2005 From: caddisconsulting@yahoo.com (Mike Horn) Date: Sun, 6 Nov 2005 21:22:56 -0700 Subject: [Bulk] [Xorp-hackers] Some thoughts In-Reply-To: <200511061535.20799.hasso@linux.ee> Message-ID: <200511070423.jA74N2tN089433@wyvern.icir.org> Hi Tasso, First, I want to say that I think this type of dialog is very important for XORP to progress forward into a platform that can be run in production networking environments. There have been a large number of bug fixes and enhancements recently that greatly improve XORP's deployability (thanks to Atanu, Pavlin and team!). I have also been testing the software and opening bugs, unfortunately I don't write much code, so I haven't been able to contribute fixes. I agree that there are a number of areas that can still be improved, however I'm pretty sure that the current interface structure can be integrated with VRRP, tunnels, etc. but might take some additional development. I think your ideas on using template keywords for deprecated and incompatible commands is excellent! -mike -----Original Message----- From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On Behalf Of Hasso Tepper Sent: Sunday, November 06, 2005 6:35 AM To: xorp-hackers@xorp.org Subject: [Bulk] [Xorp-hackers] Some thoughts I have been looking through current state of Xorp project, made some tests and reported some bugs (more to follow hopefully) and read quickly through hackers list with hope that I can use Xorp as base of some inhouse platforms in long term. Here are some of my thoughts. Interface handling. Xorp ignores runtime address/interface deletes/adds from OS and users have to configure all interfaces in Xorp. As I understand it, it's done by design and I remember some of developers saying that it will not change as main focus of Xorp is research platform. It prevents to use Xorp as software for production in many cases (including mine, seems). But this requirement is IMHO strange even for research platform: * You have to configure even IPv6 link local addresses which is business of underlying stack and out of users control in every platform I know * It doesn't allow to use Xorp together with software which modify addresses and routes - high availability stuff for example (vrrp, carp etc.) Ability to configure nonexistant (yet) devices is must be as well (in the cases like hotlug, tunnels etc.) in any production system. If device will appear, it will be configured by Xorp. Interface/vif concept is a little bit strange as well - ie. mostly naming decision. Forcing to use just the same name of vif by default is bad enough. What "show interface fxp0" shows to me? Interface or vif? It might not be so important at the moment, but I'm almost sure that there will be cases in future when it matters. And how to fit existing vlan naming schemes in unixes to that model? It might sound lame (how many times it was written in this list? ;), but I really think that Junos way is better in this respect - . and vif define vif 0 as special - vif directly on top of physical interface without any virtual device in system. (I know that it doesn't solve any problems for systems where virtual interface naming scheme doesn't contain any link to physical interface though.) Configuration handling I have read through threads in list and object strongly to ideas to have functionality to rewrite configuration by new version to be compatible. Nothing like this should happen in routers I maintain ;). My idea to define behaviour to deal with deprecated and incompatible changes via template keywords: %deprecated - Using this command is not recommended any more, but software still handles this. It's hidden in CLI (doesn't appear in possible completions list) and if used by user, comment is added to the configuration - "use xxx instead". With clearly defined deprecating mechanism it gives good way to handle just syntax changes gracefully. For example "deprecated command is there for one stable version and will be removed after that". %incompatible - Software doesn't handle this construct any more. There should be way to parse configuration before executing (restart) the new software and to give error in these cases (and in case of just error) - "This construct will be ignored by version you are upgrading to." Anyway, project looks very promising and I hope to contribute at least via bugreports in the future as well. And I'm sure that at least one Xorp install will stay there in my lab. with my best wishes, -- Hasso Tepper _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From caddisconsulting@yahoo.com Mon Nov 7 04:30:35 2005 From: caddisconsulting@yahoo.com (Mike Horn) Date: Sun, 6 Nov 2005 21:30:35 -0700 Subject: [Bulk] AW: [Xorp-hackers] Some thoughts In-Reply-To: <000001c5e2f7$278b3080$1608000a@dedus737> Message-ID: <200511070430.jA74Ue1V089534@wyvern.icir.org> Hi Patrick, In cases like ospf4 -> ospf and other configuration mappings, what if we developed a separate configuration converter for these types of situations? I agree with Hasso that I would prefer to have the configuration interpreted literally, exactly as it is in the configuration file, otherwise what you view in the configuration file will not match what you see in rtrmgr after the configuration is loaded. Just my $0.02! -mike -----Original Message----- From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On Behalf Of Patrick Preuss Sent: Sunday, November 06, 2005 10:26 AM To: 'Hasso Tepper'; xorp-hackers@xorp.org Subject: [Bulk] AW: [Xorp-hackers] Some thoughts Hello > Configuration handling > I have read through threads in list and object strongly to ideas to > have functionality to rewrite configuration by new version to be compatible. > Nothing like this should happen in routers I maintain ;). My idea to You are right should not ;) But major vendors have it allway done and for some parts of configurations it might be ok, as you followed the discussion, It might be a compile time option to do this and I spoke about to rewrite things only in the case when some naming conventions change eg.: ospf4 -> ospf. For my part this is ok, to correct things to new naming scheme, but if major Funtionality changes, like in the rip process, there must be a way to transition from Version 1.1 -> 1.2 without rewriteing the config in advance. The Config should be written by the rtrmgr, and not by hand. >From my point of view the Software should help you doing an upgrade from one version to another. Major rewrites shouldn't be done, that's right, this should be marked as "E>" in the show, so the user has the chance to see there is something wrong. And may be the software should accept old and new things for a while. Regards, Patrick _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From deathdealer@gmx.net Mon Nov 7 07:30:40 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Mon, 7 Nov 2005 08:30:40 +0100 Subject: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <200511070430.jA74Ue1V089534@wyvern.icir.org> Message-ID: <000601c5e36d$31a255f0$9b3dbb50@dedus737> > -----Ursprüngliche Nachricht----- > Von: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] Im > > Auftrag von Mike Horn > Gesendet: Montag, 7. November 2005 05:31 > An: 'Patrick Preuss'; xorp-hackers@xorp.org > Betreff: RE: [Bulk] AW: [Xorp-hackers] Some thoughts > Hi Patrick, > In cases like ospf4 -> ospf and other configuration mappings, what if we > developed a separate configuration converter for these types of situations? > I agree with Hasso that I would prefer to have the configuration interpreted > literally, exactly as it is in the configuration file, otherwise what you > view in the configuration file will not match what you see in rtrmgr after > the configuration is loaded. Just my $0.02! Yes you are right you will have a difference between startup and running configuration, but in this case only until the point you save the config Then there will be the new values. To have a tool witch does this is a nice idea, but how to deal with this? I think you can argue this or that way how to do this, but from my point of view we should provide a way to deal with this and not go the hard way, witch mean to drop the old once and maybe not to start the system at all. But from my point of view there must be a way to deal with such things, maybe rewrite the config to the new values, or support both ways for some time, so the users have the chance to do the things by them self. Because some you will not have always the chance to change things in advance. The Reasons wary why you have not or can not do this, but you have the need to upgrade the software for maintenance reason, so the software have the need to deal with this. For example framework for rip witch deals with route import and export, hope I remember correct, from my point of view we have the need to deal with both ways for some time so the users have the chance to update the configs, maybe the way could: 1.1 old way, 1.2 introduce the new way, but support the old also and inform the user that this will be obsolete in later releases, 1.3 drop the support for the old way. > -mike > patrick From deathdealer@gmx.net Mon Nov 7 07:31:21 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Mon, 7 Nov 2005 08:31:21 +0100 Subject: [Xorp-hackers] Some thoughts In-Reply-To: <84a612dd0511061304o7198cf6eib31651f63b00c341@mail.gmail.com> Message-ID: <000701c5e36d$4373a540$9b3dbb50@dedus737> Hello, > Now, suppose I configure the IP address of an interface through the > rtrmgr. The FEA will set this interface address. And now someone > changes it through ifconfig or whatever. What is the correct action > for XORP to do? > The IP address has been configured in XORP, so XORP should in > principle believe this is still what is wanted. If it observes the > change, then it should re-configure it back, as XORP is still > configured to set this particular address. > An alternative is for XORP to monitor the machine state, and consider > the rest of the machine is in charge. In which case it would then > change it's running config automatically. But the general idea is the > running config is set by a human, so having this change under you > isn't principle of least surprise. > The end result is that there is no good answer to this. As XORP is > intended not as just a routing daemon, but as the entire router > control plane (yes, long-term plan), then the most sensible (and > certainly simplest) answer is "XORP is in charge". Yes the answer is not simple, but on thought may be there could be an option, compile time or in the configuration as global and or per interface variable, where you can specify how xorp should deal with this, something like an enforce the value configured in xorp or not. > We discussed this ad-nauseum in the early days of XORP, and ended up > with this decision. There is simply no good solution to this that > everyone would be happy with - you have to decide who is in charge. > Now, the IPv6 link-local address issue is one where the kernel should > be in charge. Not any other user-space daemon. Thus this is > obviously one we should handle better than we do. > And issues such as CARP/VRRP should be handled in a what that the user > specifies somehow that this address is to be set automatically, and so > can change under you. We don't have the hooks for this right now, and > should have. But there's only so much time, and so many things to do. Maybe such things like CARP/VRRP should be an integrated part of xorp, because such things are primary defined/developed for Routers, so why not integrate them in a later stage. > Cheers, > Mark Patrick _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From hasso@linux.ee Mon Nov 7 12:29:01 2005 From: hasso@linux.ee (Hasso Tepper) Date: Mon, 7 Nov 2005 14:29:01 +0200 Subject: [Xorp-hackers] Some thoughts In-Reply-To: <84a612dd0511061304o7198cf6eib31651f63b00c341@mail.gmail.com> References: <200511061535.20799.hasso@linux.ee> <84a612dd0511061304o7198cf6eib31651f63b00c341@mail.gmail.com> Message-ID: <200511071429.01956.hasso@linux.ee> Mark Handley wrote: > Now, suppose I configure the IP address of an interface through the > rtrmgr. The FEA will set this interface address. And now someone > changes it through ifconfig or whatever. What is the correct action > for XORP to do? What is "change"? Two actions can be done by kernel (via ifconfig or any other mechanism) - add address or delete address. > The IP address has been configured in XORP, so XORP should in > principle believe this is still what is wanted. If it observes the > change, then it should re-configure it back, as XORP is still > configured to set this particular address. Xorp has to force the use of address which is configured in rtrmgr. If address is deleted by kernel and event to delete is not initiated by Xorp, it has to send address_add message again to the kernel. > An alternative is for XORP to monitor the machine state, and consider > the rest of the machine is in charge. In which case it would then > change it's running config automatically. But the general idea is the > running config is set by a human, so having this change under you > isn't principle of least surprise. No way. Nothing should change running config automatically. All addresses coming from system should have meaning for rib only. > The end result is that there is no good answer to this. As XORP is > intended not as just a routing daemon, but as the entire router > control plane (yes, long-term plan), then the most sensible (and > certainly simplest) answer is "XORP is in charge". > > We discussed this ad-nauseum in the early days of XORP, and ended up > with this decision. There is simply no good solution to this that > everyone would be happy with - you have to decide who is in charge. > > Now, the IPv6 link-local address issue is one where the kernel should > be in charge. Not any other user-space daemon. Thus this is > obviously one we should handle better than we do. > > And issues such as CARP/VRRP should be handled in a what that the user > specifies somehow that this address is to be set automatically, and so > can change under you. We don't have the hooks for this right now, and > should have. But there's only so much time, and so many things to do. My view is something like this: * Xorp is in charge, but it listens kernel if it doesn't conflict with Xorp's view of things. * All addresses and connected routes configured/added by kernel have meaning for rib only - no configuration changes. Situations: Interface is created in Xorp (it has to exist in the system for now, but hopefully this will change). Addresses already on interface are added to the RIB (like it's done with default-system-config at the moment). If there are addresses configured in Xorp, they are added to the interface. Xorp receives address_add message from kernel - address are added to the RIB with connected route (if it isn't there already). Xorp receives address_del message from kernel. If it is the address not configured from Xorp, delete it from RIB. If it is configured from Xorp, add it back - ie. send address_add to the kernel. Interface is deleted in Xorp. Only the addresses configured from Xorp are removed from interface. If you see any problem with this approach, please tell me. This fixes both link-local and vrrp/carp cases. Btw, it also fixes secondary address handling in Linux for example. At the moment you can try something like this on Linux: XORP# create interfaces interface eth0 vif eth0 address 10.10.10.1 prefix-length 24 XORP# commit XORP# create interfaces interface eth0 vif eth0 address 10.10.10.2 prefix-length 24 XORP# commit XORP# delete interfaces interface eth0 vif eth0 address 10.10.10.1 XORP# commit Result is that interface eth0 has no addresses configured, but 10.10.10.2 is still configured in Xorp. That's because Linux deletes all secondary addresses from interface if primary is deleted. with my bets wishes, -- Hasso Tepper From kristian@juniks.net Mon Nov 7 12:41:13 2005 From: kristian@juniks.net (Kristian Larsson) Date: Mon, 7 Nov 2005 13:41:13 +0100 Subject: [Xorp-hackers] Some thoughts In-Reply-To: <200511071429.01956.hasso@linux.ee> References: <200511061535.20799.hasso@linux.ee> <84a612dd0511061304o7198cf6eib31651f63b00c341@mail.gmail.com> <200511071429.01956.hasso@linux.ee> Message-ID: <20051107124112.GD27036@juniks.net> On Mon, Nov 07, 2005 at 02:29:01PM +0200, Hasso Tepper wrote: > Mark Handley wrote: > > Now, suppose I configure the IP address of an interface through the > > rtrmgr. The FEA will set this interface address. And now someone > > changes it through ifconfig or whatever. What is the correct action > > for XORP to do? > > What is "change"? Two actions can be done by kernel (via ifconfig or > any other mechanism) - add address or delete address. > > > The IP address has been configured in XORP, so XORP should in > > principle believe this is still what is wanted. If it observes the > > change, then it should re-configure it back, as XORP is still > > configured to set this particular address. > > Xorp has to force the use of address which is configured in rtrmgr. If > address is deleted by kernel and event to delete is not initiated by > Xorp, it has to send address_add message again to the kernel. > > > An alternative is for XORP to monitor the machine state, and consider > > the rest of the machine is in charge. In which case it would then > > change it's running config automatically. But the general idea is the > > running config is set by a human, so having this change under you > > isn't principle of least surprise. > > No way. Nothing should change running config automatically. All addresses > coming from system should have meaning for rib only. > > > The end result is that there is no good answer to this. As XORP is > > intended not as just a routing daemon, but as the entire router > > control plane (yes, long-term plan), then the most sensible (and > > certainly simplest) answer is "XORP is in charge". > > > > We discussed this ad-nauseum in the early days of XORP, and ended up > > with this decision. There is simply no good solution to this that > > everyone would be happy with - you have to decide who is in charge. > > > > Now, the IPv6 link-local address issue is one where the kernel should > > be in charge. Not any other user-space daemon. Thus this is > > obviously one we should handle better than we do. > > > > And issues such as CARP/VRRP should be handled in a what that the user > > specifies somehow that this address is to be set automatically, and so > > can change under you. We don't have the hooks for this right now, and > > should have. But there's only so much time, and so many things to do. > > My view is something like this: > > * Xorp is in charge, but it listens kernel if it doesn't conflict with > Xorp's view of things. > * All addresses and connected routes configured/added by kernel have > meaning for rib only - no configuration changes. > > Situations: > > Interface is created in Xorp (it has to exist in the system for now, but > hopefully this will change). Addresses already on interface are added to > the RIB (like it's done with default-system-config at the moment). If > there are addresses configured in Xorp, they are added to the interface. > > Xorp receives address_add message from kernel - address are added to the > RIB with connected route (if it isn't there already). > > Xorp receives address_del message from kernel. If it is the address not > configured from Xorp, delete it from RIB. If it is configured from Xorp, > add it back - ie. send address_add to the kernel. > > Interface is deleted in Xorp. Only the addresses configured from Xorp are > removed from interface. > > If you see any problem with this approach, please tell me. This fixes > both link-local and vrrp/carp cases. > > Btw, it also fixes secondary address handling in Linux for example. At > the moment you can try something like this on Linux: > > XORP# create interfaces interface eth0 vif eth0 address 10.10.10.1 > prefix-length 24 > XORP# commit > XORP# create interfaces interface eth0 vif eth0 address 10.10.10.2 > prefix-length 24 > XORP# commit > XORP# delete interfaces interface eth0 vif eth0 address 10.10.10.1 > XORP# commit > > Result is that interface eth0 has no addresses configured, but 10.10.10.2 > is still configured in Xorp. That's because Linux deletes all secondary > addresses from interface if primary is deleted. I beleive there is an option for this. Promote secondary IPs When deleting a primary the 'next' secondary will become primary. Of course, most people don't have this ( I think it is available as of 2.6.13 or .14) so what you're saying still holds true. Kristian. > > > with my bets wishes, > > -- > Hasso Tepper > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From hasso@linux.ee Mon Nov 7 13:01:55 2005 From: hasso@linux.ee (Hasso Tepper) Date: Mon, 7 Nov 2005 15:01:55 +0200 Subject: [Xorp-hackers] Some thoughts In-Reply-To: <84a612dd0511061313r52912688j3917d8178b6980ae@mail.gmail.com> References: <200511061535.20799.hasso@linux.ee> <84a612dd0511061313r52912688j3917d8178b6980ae@mail.gmail.com> Message-ID: <200511071501.55266.hasso@linux.ee> Mark Handley wrote: > The standard Unix naming scheme sucks, and was a hack to retro-fit > virtual interface naming into a framework that was intended only for > physical interface naming. Yes, I agree that it really sucks. > Juniper's naming scheme is the ideal. But they re-wrote the > networking stack, and we only get that luxury when we run on click, > which we don't want to mandate. We couldn't do this and run on a > stock Unix forwarding path. In theory this can be done. There are virtual interface naming schemes which fit to Junos scheme (vlans in linux and freebsd > 5.3 AFAIK etc). So there two choices - not 1:1 xorp vif <-> kernel interface name mapping or just not to deal with these interfaces which don't fit to this scheme. Both are quite bad choices of course. > So, the compromise is what we ended up with. We have the > physical/virtual split being explicit, which allows properties of > physical interfaces to be dealt with as a whole, and provides an > appropriate framework for dealing with things such as creating VLANs > or ATM VCs on a physical interface (where we have a forwarding path > such as click, and control over naming). But we also have a namespace > (VIFs) which can directly map to Unix interface names when we're > running on regular Unix kernels. OK. So basically this means that if someone (I'm not saying that this "someone" will be me, but it might happen ;) will implement vlans in linux, configuration will look like something like this?: interfaces { interface eth0 { vif eth0 { } vif eth0.1 { } } } In *BSD systems this will be something like this: interfaces { interface fxp0 { vif fxp0 { } vif vlan0 { } } } Several small problems/questions: * BSD's need command to configure vlan tag, in Linux it's already there in vlan name. Mandate command to Linux scheme as well? Maybe it's even good idea to show that it's vlan? ("vlan-id " command in Junos) * In BSD's vlans on different interfaces must not conflict, no problem in Linux. * Additional command in interface node to show that vif's (except default) will be vlans (vlan-tagging in Junos)? with my best wishes, -- Hasso Tepper From hasso@linux.ee Mon Nov 7 13:22:22 2005 From: hasso@linux.ee (Hasso Tepper) Date: Mon, 7 Nov 2005 15:22:22 +0200 Subject: [Xorp-hackers] Some thoughts In-Reply-To: <20051107124112.GD27036@juniks.net> References: <200511061535.20799.hasso@linux.ee> <200511071429.01956.hasso@linux.ee> <20051107124112.GD27036@juniks.net> Message-ID: <200511071522.22682.hasso@linux.ee> Kristian Larsson wrote: > I beleive there is an option for this. > Promote secondary IPs > When deleting a primary the 'next' secondary will become primary. > Of course, most people don't have this ( I think it is available > as of 2.6.13 or .14) so what you're saying still holds true. I know. It's available from 2.6.13 and never worked with more secondaries than one (and still doesn't). And it's not default and never will probably. So, we can safely say that it doesn't exist ;). -- Hasso Tepper From kristian@juniks.net Mon Nov 7 18:16:06 2005 From: kristian@juniks.net (Kristian Larsson) Date: Mon, 7 Nov 2005 19:16:06 +0100 Subject: [Xorp-hackers] Some thoughts In-Reply-To: <200511071522.22682.hasso@linux.ee> References: <200511061535.20799.hasso@linux.ee> <200511071429.01956.hasso@linux.ee> <20051107124112.GD27036@juniks.net> <200511071522.22682.hasso@linux.ee> Message-ID: <20051107181605.GB12875@juniks.net> On Mon, Nov 07, 2005 at 03:22:22PM +0200, Hasso Tepper wrote: > Kristian Larsson wrote: > > I beleive there is an option for this. > > Promote secondary IPs > > When deleting a primary the 'next' secondary will become primary. > > Of course, most people don't have this ( I think it is available > > as of 2.6.13 or .14) so what you're saying still holds true. > > I know. It's available from 2.6.13 and never worked with more > secondaries than one (and still doesn't). And it's not default and > never will probably. So, we can safely say that it doesn't exist ;). Oh, I wasn't away of the limit to one secondary. Seems like a strange limit ;) Now, in my mind, the Linux people screwed up, I can't see any reason till why the adresses should actually be removed but hey, I'm no kernel hacker. It won't be default but from someone who's using xorp I think you can expect them to turn on a few kernel options or do propose that xorp should handle the problem? Kristian > > -- > Hasso Tepper > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From M.Handley@cs.ucl.ac.uk Tue Nov 8 00:19:11 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Tue, 8 Nov 2005 00:19:11 +0000 Subject: [Xorp-hackers] Some thoughts In-Reply-To: <200511071501.55266.hasso@linux.ee> References: <200511061535.20799.hasso@linux.ee> <84a612dd0511061313r52912688j3917d8178b6980ae@mail.gmail.com> <200511071501.55266.hasso@linux.ee> Message-ID: <84a612dd0511071619t383ff4f8sa8117975a6c9d84b@mail.gmail.com> On 11/7/05, Hasso Tepper wrote: > OK. So basically this means that if someone (I'm not saying that this > "someone" will be me, but it might happen ;) will implement vlans in > linux, configuration will look like something like this?: > > interfaces { > interface eth0 { > vif eth0 { > } > vif eth0.1 { > } > } > } > > In *BSD systems this will be something like this: > > interfaces { > interface fxp0 { > vif fxp0 { > } > vif vlan0 { > } > } > } That's certainly what I was thinking, yes. > Several small problems/questions: > > * BSD's need command to configure vlan tag, in Linux it's already there > in vlan name. Mandate command to Linux scheme as well? Maybe it's even > good idea to show that it's vlan? ("vlan-id " command in Junos) The config should probably have an a vif-type attribute to identify that this is a tagged VLAN, just to make everything explicit. And then an attribute to indicate the tag. I'm not sure of the precise syntax, but perhaps: interfaces { interface fxp0 { vif fxp0 { } vif vlan0 { type vlan { tag: 0 } } } } That's a little verbose, but it would avoid namespace clashes with other vif types such as ATM VCs or various forms of tunnels. Done right, you might be able to default the setting of these parameters on some OSes, so you don't need to type superflous stuff when the FEA can infer that it's a VLAN and that it has a tag of 0. > * In BSD's vlans on different interfaces must not conflict, no problem > in Linux. Yes, you'd need some way to prevent commit-time errors. Not sure what that would be. > * Additional command in interface node to show that vif's (except > default) will be vlans (vlan-tagging in Junos)? I'm not quite sure what you mean by this. Is this what I already wrote above, or were you talking about operational mode ocommands? Cheers, Mark From caddisconsulting@yahoo.com Tue Nov 8 03:59:53 2005 From: caddisconsulting@yahoo.com (Mike Horn) Date: Mon, 7 Nov 2005 20:59:53 -0700 Subject: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <84a612dd0511071619t383ff4f8sa8117975a6c9d84b@mail.gmail.com> Message-ID: <200511080359.jA83xxB8007317@wyvern.icir.org> Here a couple of thoughts on the configuration portion of VLAN interfaces. 1. We should have a configuration flag under the master interface indicating that the interface is configured for 802.1Q tagging. 2. It might be simpler to have a single node with the vlan-id value. Here's what I'm suggesting: interfaces { interface fxp0 { vlan-tagging: true; vif fxp0 { } vif vlan0 { vlan-id: 20; } } } This is similar to how it is done on the Juniper. -mike -----Original Message----- From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On Behalf Of Mark Handley Sent: Monday, November 07, 2005 5:19 PM To: Hasso Tepper Cc: xorp-hackers@xorp.org Subject: [Bulk] Re: [Xorp-hackers] Some thoughts On 11/7/05, Hasso Tepper wrote: > OK. So basically this means that if someone (I'm not saying that this > "someone" will be me, but it might happen ;) will implement vlans in > linux, configuration will look like something like this?: > > interfaces { > interface eth0 { > vif eth0 { > } > vif eth0.1 { > } > } > } > > In *BSD systems this will be something like this: > > interfaces { > interface fxp0 { > vif fxp0 { > } > vif vlan0 { > } > } > } That's certainly what I was thinking, yes. > Several small problems/questions: > > * BSD's need command to configure vlan tag, in Linux it's already there > in vlan name. Mandate command to Linux scheme as well? Maybe it's even > good idea to show that it's vlan? ("vlan-id " command in Junos) The config should probably have an a vif-type attribute to identify that this is a tagged VLAN, just to make everything explicit. And then an attribute to indicate the tag. I'm not sure of the precise syntax, but perhaps: interfaces { interface fxp0 { vif fxp0 { } vif vlan0 { type vlan { tag: 0 } } } } That's a little verbose, but it would avoid namespace clashes with other vif types such as ATM VCs or various forms of tunnels. Done right, you might be able to default the setting of these parameters on some OSes, so you don't need to type superflous stuff when the FEA can infer that it's a VLAN and that it has a tag of 0. > * In BSD's vlans on different interfaces must not conflict, no problem > in Linux. Yes, you'd need some way to prevent commit-time errors. Not sure what that would be. > * Additional command in interface node to show that vif's (except > default) will be vlans (vlan-tagging in Junos)? I'm not quite sure what you mean by this. Is this what I already wrote above, or were you talking about operational mode ocommands? Cheers, Mark _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From M.Handley@cs.ucl.ac.uk Tue Nov 8 09:21:14 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Tue, 8 Nov 2005 09:21:14 +0000 Subject: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <200511080359.jA83xxB8007317@wyvern.icir.org> References: <84a612dd0511071619t383ff4f8sa8117975a6c9d84b@mail.gmail.com> <200511080359.jA83xxB8007317@wyvern.icir.org> Message-ID: <84a612dd0511080121x3b577aabm9c5f1aa4ee80625@mail.gmail.com> On 11/8/05, Mike Horn wrote: > Here a couple of thoughts on the configuration portion of VLAN interfaces. > > 1. We should have a configuration flag under the master interface indicating > that the interface is configured for 802.1Q tagging. > > 2. It might be simpler to have a single node with the vlan-id value. > > Here's what I'm suggesting: > > interfaces { > interface fxp0 { > vlan-tagging: true; > vif fxp0 { > } > vif vlan0 { > vlan-id: 20; > } > } > } You're right - this is much cleaner. The only issue then is ensuring you can't set vlan-id unless vlan-tagging is enabled - primarily to avoid confusion where you set it, and it doens't do anything, but also to avoid a huge list of config options that aren't relevant when you attempt command-line completion. Also, the vlan-tagging option probably shouldn't be available unless the interface has VLAN capability, for the same reasons. But these are details - the general idea looks good. - Mark From hasso@linux.ee Tue Nov 8 09:37:01 2005 From: hasso@linux.ee (Hasso Tepper) Date: Tue, 8 Nov 2005 11:37:01 +0200 Subject: [Xorp-hackers] Some thoughts In-Reply-To: <20051107181605.GB12875@juniks.net> References: <200511061535.20799.hasso@linux.ee> <200511071522.22682.hasso@linux.ee> <20051107181605.GB12875@juniks.net> Message-ID: <200511081137.01421.hasso@linux.ee> Kristian Larsson wrote: > Oh, I wasn't away of the limit to one secondary. Seems like a strange > limit ;) It's not a limit, it's a bug. > It won't be default but from someone who's using xorp I think you can > expect them to turn on a few kernel options or do propose that xorp > should handle the problem? And you would mandate using not even yet released kernel? Anyway, it's irrelevant to the current discussion. It was mentioned only as side effect of addresses add/remove handling scheme. -- Hasso Tepper From kristian@juniks.net Tue Nov 8 09:35:33 2005 From: kristian@juniks.net (Kristian Larsson) Date: Tue, 8 Nov 2005 10:35:33 +0100 Subject: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <84a612dd0511080121x3b577aabm9c5f1aa4ee80625@mail.gmail.com> References: <84a612dd0511071619t383ff4f8sa8117975a6c9d84b@mail.gmail.com> <200511080359.jA83xxB8007317@wyvern.icir.org> <84a612dd0511080121x3b577aabm9c5f1aa4ee80625@mail.gmail.com> Message-ID: <20051108093533.GE27036@juniks.net> Shouldn't you enable vlan-tagging on the physical interface instead of on a vif? interfaces { interface fxp0 { vlan-tagging: true; vif fxp0 { bla bla } vif vlan0 { vlan-tag: 20; } } } though I'd still rather go with interfaces { interface fxp0 { vlan-tagging: true; vif 0 { description: "this is untagged"; } vif 20 { description: "this is tagged with tag 20"; perhaps including vlan-tag 20; } } } I like the skip superflous stuff like "vlan" :) and it would be quite easy to treat 0 in a special way ie untagged. I'm not sure how you intend that "vlan0" in your example should be handled. Is it like FreeBSD-vlan0 ie you can only have one per system, if so the user would have to keep track of all the vlan interfaces. not good. Or is it per interface, would the following work? interfaces { interface fxp0 { vif vlan0 { address 1.3.3.7 { prefix-length 27; } } } interface fxp1 { vif vlan0 { address 10.1.1.0 { prefix-length 27; } } } } ie, two vlan0 interfaces. Kristian On Tue, Nov 08, 2005 at 09:21:14AM +0000, Mark Handley wrote: > On 11/8/05, Mike Horn wrote: > > Here a couple of thoughts on the configuration portion of VLAN interfaces. > > > > 1. We should have a configuration flag under the master interface indicating > > that the interface is configured for 802.1Q tagging. > > > > 2. It might be simpler to have a single node with the vlan-id value. > > > > Here's what I'm suggesting: > > > > interfaces { > > interface fxp0 { > > vlan-tagging: true; > > vif fxp0 { > > } > > vif vlan0 { > > vlan-id: 20; > > } > > } > > } > > You're right - this is much cleaner. > > The only issue then is ensuring you can't set vlan-id unless > vlan-tagging is enabled - primarily to avoid confusion where you set > it, and it doens't do anything, but also to avoid a huge list of > config options that aren't relevant when you attempt command-line > completion. Also, the vlan-tagging option probably shouldn't be > available unless the interface has VLAN capability, for the same > reasons. But these are details - the general idea looks good. > > - Mark > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From deathdealer@gmx.net Tue Nov 8 10:05:04 2005 From: deathdealer@gmx.net (Patrick Marc Preuss) Date: Tue, 8 Nov 2005 11:05:04 +0100 (MET) Subject: [Bulk] Re: [Xorp-hackers] Some thoughts References: <20051108093533.GE27036@juniks.net> Message-ID: <31778.1131444304@www51.gmx.net> > though I'd still rather go with > interfaces { > interface fxp0 { > vlan-tagging: true; > vif 0 { > description: "this is untagged"; > } > vif 20 { > description: "this is tagged with tag 20"; > perhaps including vlan-tag 20; > } > } > } Yes good way but some points about all the things should vlan-tagging not called encapsulation or something like that, so it would be possible to say we run pppoe, ppp, pppoa, hdlc, frame-relay or dot1q on the line, maybe mpls tagging. Most of this things are only valid on special lines and or concurent each other, so it would be possible to have one way to configure all things. Yes please shorten the name of the vif. ;-) Patrick -- best regards Patrick Marc Preuss ---------------------------------------------------------------------- -- "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" (1979) Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie From M.Handley@cs.ucl.ac.uk Tue Nov 8 10:14:56 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Tue, 8 Nov 2005 10:14:56 +0000 Subject: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <20051108093533.GE27036@juniks.net> References: <84a612dd0511071619t383ff4f8sa8117975a6c9d84b@mail.gmail.com> <200511080359.jA83xxB8007317@wyvern.icir.org> <84a612dd0511080121x3b577aabm9c5f1aa4ee80625@mail.gmail.com> <20051108093533.GE27036@juniks.net> Message-ID: <84a612dd0511080214i34885c73w6ac2e6d21b3c7c78@mail.gmail.com> On 11/8/05, Kristian Larsson wrote: > Shouldn't you enable vlan-tagging on the physical > interface instead of on a vif? > > interfaces { > interface fxp0 { > vlan-tagging: true; > vif fxp0 { > bla bla > } > vif vlan0 { > vlan-tag: 20; > } > } > } Yes, this is what Mike also suggested. > though I'd still rather go with > interfaces { > interface fxp0 { > vlan-tagging: true; > vif 0 { > description: "this is untagged"; > } > vif 20 { > description: "this is tagged with tag 20"; > perhaps including vlan-tag 20; > } > } > } > > I like the skip superflous stuff like "vlan" :) The issue is that you really want vif names to be something that has direct meaning to the kernel or it gets really hard to integrate any non-XORP software (eg dhcpd, etc). > I'm not sure how you intend that "vlan0" in your > example should be handled. Is it like > FreeBSD-vlan0 ie you can only have one per system, > if so the user would have to keep track of all the > vlan interfaces. not good. > Or is it per interface, would the following work? On FreeBSD you can create as many vlan virtual interfaces as you need. But there's only on namespace. For example (trimmed a little to remove IP addresses, etc): vulture 107 # ifconfig sk0: flags=8802 mtu 1500 ether 00:11:d8:71:0f:d1 dc0: flags=108843 mtu 1500 options=8 ether 00:a0:cc:39:95:1c vlan0: flags=8842 mtu 1500 ether 00:a0:cc:39:95:1c vlan: 33 parent interface: dc0 vlan1: flags=8842 mtu 1500 ether 00:a0:cc:39:95:1c vlan: 34 parent interface: dc0 vlan2: flags=8842 mtu 1496 ether 00:11:d8:71:0f:d1 vlan: 33 parent interface: sk0 This machine has two physical interfaces (sk0 and dc0), and three vlan vifs configured, vlan0, vlan1, vlan2. vlan- and vlan 1 are on dc0. vlan2 is on sk0. Both vlan0 and vlan2 are using vlan tag 33. This would then map to a XORP config of: interfaces { interface sk0 { vlan-tagging: true vif sk0 { } vif vlan0 { vlan-tag: 33 } vif vlan1 { vlan-tag: 34 } } interface dc0 { vlan-tagging: true vif dc0 { } vif vlan2 { vlan-tag: 33 } } Thus the vif namespace maps directly to the kernel namespace on FreeBSD. - Mark From kristian@juniks.net Tue Nov 8 17:28:44 2005 From: kristian@juniks.net (Kristian Larsson) Date: Tue, 8 Nov 2005 18:28:44 +0100 Subject: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <84a612dd0511080214i34885c73w6ac2e6d21b3c7c78@mail.gmail.com> References: <84a612dd0511071619t383ff4f8sa8117975a6c9d84b@mail.gmail.com> <200511080359.jA83xxB8007317@wyvern.icir.org> <84a612dd0511080121x3b577aabm9c5f1aa4ee80625@mail.gmail.com> <20051108093533.GE27036@juniks.net> <84a612dd0511080214i34885c73w6ac2e6d21b3c7c78@mail.gmail.com> Message-ID: <20051108172843.GF27036@juniks.net> On Tue, Nov 08, 2005 at 10:14:56AM +0000, Mark Handley wrote: > On 11/8/05, Kristian Larsson wrote: > > Shouldn't you enable vlan-tagging on the physical > > interface instead of on a vif? > > > > interfaces { > > interface fxp0 { > > vlan-tagging: true; > > vif fxp0 { > > bla bla > > } > > vif vlan0 { > > vlan-tag: 20; > > } > > } > > } > > Yes, this is what Mike also suggested. Sorry for repeating. > > > > though I'd still rather go with > > interfaces { > > interface fxp0 { > > vlan-tagging: true; > > vif 0 { > > description: "this is untagged"; > > } > > vif 20 { > > description: "this is tagged with tag 20"; > > perhaps including vlan-tag 20; > > } > > } > > } > > > > I like the skip superflous stuff like "vlan" :) > > The issue is that you really want vif names to be something that has > direct meaning to the kernel or it gets really hard to integrate any > non-XORP software (eg dhcpd, etc). We could store the actual interface in a variable somewhere :) > > > > I'm not sure how you intend that "vlan0" in your > > example should be handled. Is it like > > FreeBSD-vlan0 ie you can only have one per system, > > if so the user would have to keep track of all the > > vlan interfaces. not good. > > Or is it per interface, would the following work? > > On FreeBSD you can create as many vlan virtual interfaces as you need. > But there's only on namespace. For example (trimmed a little to > remove IP addresses, etc): > > vulture 107 # ifconfig > sk0: flags=8802 mtu 1500 > ether 00:11:d8:71:0f:d1 > dc0: flags=108843 mtu 1500 > options=8 > ether 00:a0:cc:39:95:1c > vlan0: flags=8842 mtu 1500 > ether 00:a0:cc:39:95:1c > vlan: 33 parent interface: dc0 > vlan1: flags=8842 mtu 1500 > ether 00:a0:cc:39:95:1c > vlan: 34 parent interface: dc0 > vlan2: flags=8842 mtu 1496 > ether 00:11:d8:71:0f:d1 > vlan: 33 parent interface: sk0 > > This machine has two physical interfaces (sk0 and dc0), and three vlan > vifs configured, vlan0, vlan1, vlan2. vlan- and vlan 1 are on dc0. > vlan2 is on sk0. Both vlan0 and vlan2 are using vlan tag 33. > > This would then map to a XORP config of: > > interfaces { > interface sk0 { > vlan-tagging: true > vif sk0 { > } > vif vlan0 { > vlan-tag: 33 > } > vif vlan1 { > vlan-tag: 34 > } > } > interface dc0 { > vlan-tagging: true > vif dc0 { > } > vif vlan2 { > vlan-tag: 33 > } > } > > Thus the vif namespace maps directly to the kernel namespace on FreeBSD. This would have to be done automatically. We have boxes here with close to or perhaps even beyond thousand VLANs spread on different interfaces, although we're not running FreeBSD I bet there are people out there who do. You can't keep track of the vlan interfaces therefore I thought that the user specifys: interfaces { interface fxp0 { vif 0 { } vif 3 { } } interface fxp1 { vif 0 { } vif 3 { } } } Which would result in xorp> show interfaces fxp0/0: Flags: mtu 1500 inet 1.3.3.7 subnet 1.3.3.0/24 broadcast 1.3.3.255 vlan: untagged, interface fxp0 physical index 6 ether 0:80:c8:cd:20:8c fxp0/3: Flags: mtu 1500 inet 1.3.3.7 subnet 1.3.3.0/24 broadcast 1.3.3.255 vlan: 3, interface vlan0 physical index 6 ether 0:80:c8:cd:20:8c fxp1/0: Flags: mtu 1500 inet 1.3.3.7 subnet 1.3.3.0/24 broadcast 1.3.3.255 vlan: untagged, interface fxp1 physical index 6 ether 0:80:c8:cd:20:8c fxp1/3: Flags: mtu 1500 inet 1.3.3.7 subnet 1.3.3.0/24 broadcast 1.3.3.255 vlan: 3, interface vlan1 physical index 6 ether 0:80:c8:cd:20:8c I realise this might be harder to program but if xorp is going for production environments I beleive there is little choice. Kristian > > - Mark From deathdealer@gmx.net Tue Nov 8 18:04:58 2005 From: deathdealer@gmx.net (Patrick Marc Preuss) Date: Tue, 08 Nov 2005 19:04:58 +0100 Subject: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <20051108172843.GF27036@juniks.net> References: <84a612dd0511071619t383ff4f8sa8117975a6c9d84b@mail.gmail.com> <200511080359.jA83xxB8007317@wyvern.icir.org> <84a612dd0511080121x3b577aabm9c5f1aa4ee80625@mail.gmail.com> <20051108093533.GE27036@juniks.net> <84a612dd0511080214i34885c73w6ac2e6d21b3c7c78@mail.gmail.com> <20051108172843.GF27036@juniks.net> Message-ID: <4370E8CA.5060206@gmx.net> Kristian Larsson wrote: >On Tue, Nov 08, 2005 at 10:14:56AM +0000, Mark Handley wrote: > > >>On 11/8/05, Kristian Larsson wrote: >> >> >>>Shouldn't you enable vlan-tagging on the physical >>>interface instead of on a vif? >>> >>>interfaces { >>> interface fxp0 { >>> vlan-tagging: true; >>> vif fxp0 { >>> bla bla >>> } >>> vif vlan0 { >>> vlan-tag: 20; >>> } >>> } >>>} >>> >>> >>Yes, this is what Mike also suggested. >> >> >Sorry for repeating. > > >> >> >>>though I'd still rather go with >>>interfaces { >>> interface fxp0 { >>> vlan-tagging: true; >>> vif 0 { >>> description: "this is untagged"; >>> } >>> vif 20 { >>> description: "this is tagged with tag 20"; >>> perhaps including vlan-tag 20; >>> } >>> } >>>} >>> >>>I like the skip superflous stuff like "vlan" :) >>> >>> >>The issue is that you really want vif names to be something that has >>direct meaning to the kernel or it gets really hard to integrate any >>non-XORP software (eg dhcpd, etc). >> >> >We could store the actual interface in a variable somewhere :) > > >> >> >>>I'm not sure how you intend that "vlan0" in your >>>example should be handled. Is it like >>>FreeBSD-vlan0 ie you can only have one per system, >>>if so the user would have to keep track of all the >>>vlan interfaces. not good. >>>Or is it per interface, would the following work? >>> >>> >>On FreeBSD you can create as many vlan virtual interfaces as you need. >> But there's only on namespace. For example (trimmed a little to >>remove IP addresses, etc): >> >>vulture 107 # ifconfig >>sk0: flags=8802 mtu 1500 >> ether 00:11:d8:71:0f:d1 >>dc0: flags=108843 mtu 1500 >> options=8 >> ether 00:a0:cc:39:95:1c >>vlan0: flags=8842 mtu 1500 >> ether 00:a0:cc:39:95:1c >> vlan: 33 parent interface: dc0 >>vlan1: flags=8842 mtu 1500 >> ether 00:a0:cc:39:95:1c >> vlan: 34 parent interface: dc0 >>vlan2: flags=8842 mtu 1496 >> ether 00:11:d8:71:0f:d1 >> vlan: 33 parent interface: sk0 >> >>This machine has two physical interfaces (sk0 and dc0), and three vlan >>vifs configured, vlan0, vlan1, vlan2. vlan- and vlan 1 are on dc0. >>vlan2 is on sk0. Both vlan0 and vlan2 are using vlan tag 33. >> >>This would then map to a XORP config of: >> >>interfaces { >> interface sk0 { >> vlan-tagging: true >> vif sk0 { >> } >> vif vlan0 { >> vlan-tag: 33 >> } >> vif vlan1 { >> vlan-tag: 34 >> } >> } >> interface dc0 { >> vlan-tagging: true >> vif dc0 { >> } >> vif vlan2 { >> vlan-tag: 33 >> } >>} >> >>Thus the vif namespace maps directly to the kernel namespace on FreeBSD. >> >> >This would have to be done automatically. We have >boxes here with close to or perhaps even beyond >thousand VLANs spread on different interfaces, >although we're not running FreeBSD I bet there are >people out there who do. You can't keep track of >the vlan interfaces therefore I thought that the >user specifys: >interfaces { > interface fxp0 { > vif 0 { > } > vif 3 { > } > } > interface fxp1 { > vif 0 { > } > vif 3 { > } > } >} > >Which would result in > xorp> show interfaces > fxp0/0: Flags: mtu 1500 > inet 1.3.3.7 subnet 1.3.3.0/24 broadcast 1.3.3.255 > vlan: untagged, interface fxp0 > physical index 6 > ether 0:80:c8:cd:20:8c > fxp0/3: Flags: mtu 1500 > inet 1.3.3.7 subnet 1.3.3.0/24 broadcast 1.3.3.255 > vlan: 3, interface vlan0 > physical index 6 > ether 0:80:c8:cd:20:8c > fxp1/0: Flags: mtu 1500 > inet 1.3.3.7 subnet 1.3.3.0/24 broadcast 1.3.3.255 > vlan: untagged, interface fxp1 > physical index 6 > ether 0:80:c8:cd:20:8c > fxp1/3: Flags: mtu 1500 > inet 1.3.3.7 subnet 1.3.3.0/24 broadcast 1.3.3.255 > vlan: 3, interface vlan1 > physical index 6 > ether 0:80:c8:cd:20:8c > > Greate, but i would suggest the result will be a dot and not a slash, i would suggest to uses slashes for different hardware buses or somthing like that: fxp1.3: Flags: mtu 1500 inet 1.3.3.7 subnet 1.3.3.0/24 broadcast 1.3.3.255 vlan: 3, interface vlan1 physical index 6 ether 0:80:c8:cd:20:8c >I realise this might be harder to program but if xorp is going for >production environments I beleive there is little choice. > > Patrick > Kristian > > > >> - Mark >> >> >_______________________________________________ >Xorp-hackers mailing list >Xorp-hackers@icir.org >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > From caddisconsulting@yahoo.com Tue Nov 8 22:16:59 2005 From: caddisconsulting@yahoo.com (Mike Horn) Date: Tue, 8 Nov 2005 15:16:59 -0700 Subject: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <4370E8CA.5060206@gmx.net> Message-ID: <200511082217.jA8MH6Ct021380@wyvern.icir.org> I too would prefer using a numbering convention for sub-interfaces (e.g. fxp1.1, fxp1.2, etc.) if this is feasible. -mike -----Original Message----- From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On Behalf Of Patrick Marc Preuss Sent: Tuesday, November 08, 2005 11:05 AM To: Kristian Larsson Cc: Mark Handley; xorp-hackers@xorp.org Subject: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts Kristian Larsson wrote: >On Tue, Nov 08, 2005 at 10:14:56AM +0000, Mark Handley wrote: > > >>On 11/8/05, Kristian Larsson wrote: >> >> >>>Shouldn't you enable vlan-tagging on the physical interface instead >>>of on a vif? >>> >>>interfaces { >>> interface fxp0 { >>> vlan-tagging: true; >>> vif fxp0 { >>> bla bla >>> } >>> vif vlan0 { >>> vlan-tag: 20; >>> } >>> } >>>} >>> >>> >>Yes, this is what Mike also suggested. >> >> >Sorry for repeating. > > >> >> >>>though I'd still rather go with >>>interfaces { >>> interface fxp0 { >>> vlan-tagging: true; >>> vif 0 { >>> description: "this is untagged"; >>> } >>> vif 20 { >>> description: "this is tagged with tag 20"; >>> perhaps including vlan-tag 20; >>> } >>> } >>>} >>> >>>I like the skip superflous stuff like "vlan" :) >>> >>> >>The issue is that you really want vif names to be something that has >>direct meaning to the kernel or it gets really hard to integrate any >>non-XORP software (eg dhcpd, etc). >> >> >We could store the actual interface in a variable somewhere :) > > >> >> >>>I'm not sure how you intend that "vlan0" in your example should be >>>handled. Is it like FreeBSD-vlan0 ie you can only have one per >>>system, if so the user would have to keep track of all the vlan >>>interfaces. not good. >>>Or is it per interface, would the following work? >>> >>> >>On FreeBSD you can create as many vlan virtual interfaces as you need. >> But there's only on namespace. For example (trimmed a little to >>remove IP addresses, etc): >> >>vulture 107 # ifconfig >>sk0: flags=8802 mtu 1500 >> ether 00:11:d8:71:0f:d1 >>dc0: flags=108843 mtu 1500 >> options=8 >> ether 00:a0:cc:39:95:1c >>vlan0: flags=8842 mtu 1500 >> ether 00:a0:cc:39:95:1c >> vlan: 33 parent interface: dc0 >>vlan1: flags=8842 mtu 1500 >> ether 00:a0:cc:39:95:1c >> vlan: 34 parent interface: dc0 >>vlan2: flags=8842 mtu 1496 >> ether 00:11:d8:71:0f:d1 >> vlan: 33 parent interface: sk0 >> >>This machine has two physical interfaces (sk0 and dc0), and three vlan >>vifs configured, vlan0, vlan1, vlan2. vlan- and vlan 1 are on dc0. >>vlan2 is on sk0. Both vlan0 and vlan2 are using vlan tag 33. >> >>This would then map to a XORP config of: >> >>interfaces { >> interface sk0 { >> vlan-tagging: true >> vif sk0 { >> } >> vif vlan0 { >> vlan-tag: 33 >> } >> vif vlan1 { >> vlan-tag: 34 >> } >> } >> interface dc0 { >> vlan-tagging: true >> vif dc0 { >> } >> vif vlan2 { >> vlan-tag: 33 >> } >>} >> >>Thus the vif namespace maps directly to the kernel namespace on FreeBSD. >> >> >This would have to be done automatically. We have boxes here with close >to or perhaps even beyond thousand VLANs spread on different >interfaces, although we're not running FreeBSD I bet there are people >out there who do. You can't keep track of the vlan interfaces therefore >I thought that the user specifys: >interfaces { > interface fxp0 { > vif 0 { > } > vif 3 { > } > } > interface fxp1 { > vif 0 { > } > vif 3 { > } > } >} > >Which would result in > xorp> show interfaces > fxp0/0: Flags: mtu 1500 > inet 1.3.3.7 subnet 1.3.3.0/24 broadcast 1.3.3.255 > vlan: untagged, interface fxp0 > physical index 6 > ether 0:80:c8:cd:20:8c > fxp0/3: Flags: mtu 1500 > inet 1.3.3.7 subnet 1.3.3.0/24 broadcast 1.3.3.255 > vlan: 3, interface vlan0 > physical index 6 > ether 0:80:c8:cd:20:8c > fxp1/0: Flags: mtu 1500 > inet 1.3.3.7 subnet 1.3.3.0/24 broadcast 1.3.3.255 > vlan: untagged, interface fxp1 > physical index 6 > ether 0:80:c8:cd:20:8c > fxp1/3: Flags: mtu 1500 > inet 1.3.3.7 subnet 1.3.3.0/24 broadcast 1.3.3.255 > vlan: 3, interface vlan1 > physical index 6 > ether 0:80:c8:cd:20:8c > > Greate, but i would suggest the result will be a dot and not a slash, i would suggest to uses slashes for different hardware buses or somthing like that: fxp1.3: Flags: mtu 1500 inet 1.3.3.7 subnet 1.3.3.0/24 broadcast 1.3.3.255 vlan: 3, interface vlan1 physical index 6 ether 0:80:c8:cd:20:8c >I realise this might be harder to program but if xorp is going for >production environments I beleive there is little choice. > > Patrick > Kristian > > > >> - Mark >> >> >_______________________________________________ >Xorp-hackers mailing list >Xorp-hackers@icir.org >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From M.Handley@cs.ucl.ac.uk Tue Nov 8 22:51:19 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Tue, 8 Nov 2005 22:51:19 +0000 Subject: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <200511082217.jA8MH6Ct021380@wyvern.icir.org> References: <4370E8CA.5060206@gmx.net> <200511082217.jA8MH6Ct021380@wyvern.icir.org> Message-ID: <84a612dd0511081451q1ae43ce8u485777fb0654c25d@mail.gmail.com> On 11/8/05, Mike Horn wrote: > I too would prefer using a numbering convention for sub-interfaces (e.g. > fxp1.1, fxp1.2, etc.) if this is feasible. I don't really think it is, for the reasons I've listed in previous mail. I agree it would be nicer from a user point of view, but it would be a developer nightmare. - Mark From hasso@estpak.ee Tue Nov 8 10:33:29 2005 From: hasso@estpak.ee (Hasso Tepper) Date: Tue, 8 Nov 2005 12:33:29 +0200 Subject: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <84a612dd0511080214i34885c73w6ac2e6d21b3c7c78@mail.gmail.com> References: <84a612dd0511071619t383ff4f8sa8117975a6c9d84b@mail.gmail.com> <20051108093533.GE27036@juniks.net> <84a612dd0511080214i34885c73w6ac2e6d21b3c7c78@mail.gmail.com> Message-ID: <200511081233.29779.hasso@estpak.ee> Mark Handley wrote: > On FreeBSD you can create as many vlan virtual interfaces as you need. > But there's only on namespace. For example (trimmed a little to > remove IP addresses, etc): For clarification - according to this presentation - http://people.freebsd.org/~andre/FreeBSD-5.3-Networking.pdf, FreeBSD 5.3 supports . naming as well (see page 8). Not that it should change something. -- Hasso Tepper From kristian@juniks.net Wed Nov 9 06:28:27 2005 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 9 Nov 2005 07:28:27 +0100 Subject: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <84a612dd0511081451q1ae43ce8u485777fb0654c25d@mail.gmail.com> References: <4370E8CA.5060206@gmx.net> <200511082217.jA8MH6Ct021380@wyvern.icir.org> <84a612dd0511081451q1ae43ce8u485777fb0654c25d@mail.gmail.com> Message-ID: <20051109062826.GE12875@juniks.net> On Tue, Nov 08, 2005 at 10:51:19PM +0000, Mark Handley wrote: > On 11/8/05, Mike Horn wrote: > > I too would prefer using a numbering convention for sub-interfaces (e.g. > > fxp1.1, fxp1.2, etc.) if this is feasible. > > I don't really think it is, for the reasons I've listed in previous > mail. I agree it would be nicer from a user point of view, but it > would be a developer nightmare. why? ;) Say we do it like this. XORP first has to recognize and differ between the systems. Linux and FreeBSD with the new naming scheme would go under one category while system with vlan naming that has no link to it's physical interface, ie old FreeBSD, NetBSD?, OpenBSD? and some others perhaps is in another category. For the linux category it's not too hard just creating the correct interfaces. For the old FreeBSD category, when adding a new vlan xorp will simply ask the system for a new vlan interface. It receives the next available and configures it. In addition to this it also stores it in the configuration file. interfaces { interface fxp0 { vif 0 { use-interface: fxp0; } vif 5 { use-interface: vlan0; } vif 6 { use-interface: vlan1; } } interface fxp1 { vif 0 { use-interface: fxp0; } vif 1 { use-interface: vlan2; } vif 3 { use-interface: vlan3; } } } ie, the "use-interface" part would be automatically generated. Is this really so hard to implement? Linux and freebsd with similar naming scheme should work with the configuration described in earlier emails. Kristian. From M.Handley@cs.ucl.ac.uk Wed Nov 9 09:52:54 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Wed, 9 Nov 2005 09:52:54 +0000 Subject: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <20051109062826.GE12875@juniks.net> References: <4370E8CA.5060206@gmx.net> <200511082217.jA8MH6Ct021380@wyvern.icir.org> <84a612dd0511081451q1ae43ce8u485777fb0654c25d@mail.gmail.com> <20051109062826.GE12875@juniks.net> Message-ID: <84a612dd0511090152j53126b46u96032f72386f2e4c@mail.gmail.com> On 11/9/05, Kristian Larsson wrote: > ie, the "use-interface" part would be > automatically generated. > Is this really so hard to implement? The problem is how do you automatically generate this? The FEA could do this, but the rtrmgr has no inbuild knowledge of the FEA or of interfaces, so it can't generate this information. Currently there's no way for the rtrmgr to dynamically update a running config from the running processes - the model is that the running config is what the user said it was. The rtrmgr that would need to use this information to configure routing protocols, so it would need to know. - Mark From caddisconsulting@yahoo.com Wed Nov 9 14:39:52 2005 From: caddisconsulting@yahoo.com (Mike Horn) Date: Wed, 9 Nov 2005 07:39:52 -0700 Subject: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <84a612dd0511090152j53126b46u96032f72386f2e4c@mail.gmail.com> Message-ID: <200511091439.jA9Edux0033101@wyvern.icir.org> Hi, Another potential drawback of auto generating interface names or numbers is that the user can't create their own logical mappings. For instance I usually align sub-interface number and vlan-tag, sub-interface and FR PVC, etc. For example, on a Juniper you can define. fe-0/0/3 { vlan-tagging; unit 10 { vlan-id 10; } unit 20 { vlan-id 20; } } This helps make the troubleshooting process easier since you know fe-0/0/3.20 uses VLAN 20. -mike -----Original Message----- From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On Behalf Of Mark Handley Sent: Wednesday, November 09, 2005 2:53 AM To: Kristian Larsson; Mark Handley; xorp-hackers@xorp.org Subject: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts On 11/9/05, Kristian Larsson wrote: > ie, the "use-interface" part would be > automatically generated. > Is this really so hard to implement? The problem is how do you automatically generate this? The FEA could do this, but the rtrmgr has no inbuild knowledge of the FEA or of interfaces, so it can't generate this information. Currently there's no way for the rtrmgr to dynamically update a running config from the running processes - the model is that the running config is what the user said it was. The rtrmgr that would need to use this information to configure routing protocols, so it would need to know. - Mark _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From doll@tm.uka.de Wed Nov 9 17:06:10 2005 From: doll@tm.uka.de (Mark Doll) Date: Wed, 09 Nov 2005 18:06:10 +0100 Subject: [Xorp-hackers] Duplicated code in RIP Message-ID: <43722C82.6050007@tm.uka.de> I wonder why some member functions of class XrlPortIO (i.e. request_socket_server, see file ~/rip/xlr_port_io.cc) are not generally defined using template parameter 'A' but are instead defined two times as specializations for 'IPv4' and 'IPv6', although the specializations only differ in constants and types, differences that are otherwise handled with class RIP_AF_CONSTANTS throughout RIP. Wouldn't it be less error prone for future modifications/extensions/code reuse and easier to read/understand the code for newbies like me if there's no duplicated code within XORP? Mark. From a.greenhalgh@cs.ucl.ac.uk Wed Nov 9 02:51:20 2005 From: a.greenhalgh@cs.ucl.ac.uk (Adam Greenhalgh) Date: Tue, 8 Nov 2005 21:51:20 -0500 Subject: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <200511081233.29779.hasso@estpak.ee> References: <84a612dd0511071619t383ff4f8sa8117975a6c9d84b@mail.gmail.com> <20051108093533.GE27036@juniks.net> <84a612dd0511080214i34885c73w6ac2e6d21b3c7c78@mail.gmail.com> <200511081233.29779.hasso@estpak.ee> Message-ID: <4769af410511081851i1e606172h@mail.gmail.com> Equally freebsd supports interface renaming so you no longer need to have interface names based on the driver. I thought linux supported interface renaming too, but I can't seem to find a reference. So perhaps one idea for xorp might be to provide unified naming across os's ;-) adam On 08/11/05, Hasso Tepper wrote: > Mark Handley wrote: > > On FreeBSD you can create as many vlan virtual interfaces as you need. > > But there's only on namespace. For example (trimmed a little to > > remove IP addresses, etc): > > For clarification - according to this presentation - > http://people.freebsd.org/~andre/FreeBSD-5.3-Networking.pdf, FreeBSD 5.3 > supports . naming as well (see page 8). Not that it > should change something. > > > -- > Hasso Tepper > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From zec@icir.org Wed Nov 9 18:13:28 2005 From: zec@icir.org (Marko Zec) Date: Wed, 9 Nov 2005 19:13:28 +0100 Subject: [Xorp-hackers] Duplicated code in RIP In-Reply-To: <43722C82.6050007@tm.uka.de> References: <43722C82.6050007@tm.uka.de> Message-ID: <200511091913.28177.zec@icir.org> On Wednesday 09 November 2005 18:06, Mark Doll wrote: > I wonder why some member functions of class XrlPortIO (i.e. > request_socket_server, see file ~/rip/xlr_port_io.cc) are not > generally defined using template parameter 'A' but are instead > defined two times as specializations for 'IPv4' and 'IPv6', although > the specializations only differ in constants and types, differences > that are otherwise handled with class RIP_AF_CONSTANTS throughout > RIP. Another difference is that RIP sends / receives packets on IPv4 sockets, while RIPng uses IPv6 sockets. Different socket types -> different XRL interfaces that need to be used, thus the need for specialization (socket4 vs socket6) in certain member functions. Marko > Wouldn't it be less error prone for future > modifications/extensions/code reuse and easier to read/understand the > code for newbies like me if there's no duplicated code within XORP? From kristian@juniks.net Wed Nov 9 19:24:17 2005 From: kristian@juniks.net ('Kristian Larsson') Date: Wed, 9 Nov 2005 20:24:17 +0100 Subject: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <20051109143535.58FF774815@mail.juniks.net> References: <84a612dd0511090152j53126b46u96032f72386f2e4c@mail.gmail.com> <20051109143535.58FF774815@mail.juniks.net> Message-ID: <20051109192417.GA12610@juniks.net> Well, yes and no. If you're inside xorp all the time you don't have to mess with the names. You can align the names within xorp. interface fxp0 { vlan-tagging: true; vif 10 { } vif 20 { } } would represent what you have below. On old FreeBSDs or other OSs you can't align them anyhow since you might have several vlan interfaces with the same tag though on different physical interfaces. And on Linux and newer FBSDs we would automatically align them. Kristian. On Wed, Nov 09, 2005 at 07:39:52AM -0700, Mike Horn wrote: > Hi, > > Another potential drawback of auto generating interface names or numbers is > that the user can't create their own logical mappings. For instance I > usually align sub-interface number and vlan-tag, sub-interface and FR PVC, > etc. For example, on a Juniper you can define. > > fe-0/0/3 { > vlan-tagging; > unit 10 { > vlan-id 10; > } > unit 20 { > vlan-id 20; > } > } > > This helps make the troubleshooting process easier since you know > fe-0/0/3.20 uses VLAN 20. > > -mike > > -----Original Message----- > From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On > Behalf Of Mark Handley > Sent: Wednesday, November 09, 2005 2:53 AM > To: Kristian Larsson; Mark Handley; xorp-hackers@xorp.org > Subject: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts > > On 11/9/05, Kristian Larsson wrote: > > > ie, the "use-interface" part would be > > automatically generated. > > Is this really so hard to implement? > > The problem is how do you automatically generate this? The FEA could do > this, but the rtrmgr has no inbuild knowledge of the FEA or of interfaces, > so it can't generate this information. Currently there's no way for the > rtrmgr to dynamically update a running config from the running processes - > the model is that the running config is what the > user said it was. The rtrmgr that would need to use this information > to configure routing protocols, so it would need to know. > > - Mark > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > From kristian@juniks.net Wed Nov 9 19:29:44 2005 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 9 Nov 2005 20:29:44 +0100 Subject: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <84a612dd0511090152j53126b46u96032f72386f2e4c@mail.gmail.com> References: <4370E8CA.5060206@gmx.net> <200511082217.jA8MH6Ct021380@wyvern.icir.org> <84a612dd0511081451q1ae43ce8u485777fb0654c25d@mail.gmail.com> <20051109062826.GE12875@juniks.net> <84a612dd0511090152j53126b46u96032f72386f2e4c@mail.gmail.com> Message-ID: <20051109192944.GB12610@juniks.net> On Wed, Nov 09, 2005 at 09:52:54AM +0000, Mark Handley wrote: > On 11/9/05, Kristian Larsson wrote: > > > ie, the "use-interface" part would be > > automatically generated. > > Is this really so hard to implement? > > The problem is how do you automatically generate this? The FEA could > do this, but the rtrmgr has no inbuild knowledge of the FEA or of > interfaces, so it can't generate this information. Currently there's > no way for the rtrmgr to dynamically update a running config from the > running processes - the model is that the running config is what the > user said it was. The rtrmgr that would need to use this information > to configure routing protocols, so it would need to know. I'm not sure how to do this as I don't have an indepth knowledge of XORP internal workings. I just know that if I tell ifconfig: ifconfig vlan add It will create the next available vlan. So that part can't be too hard. Perhaps we don't need to store it in the configuration? I just thought it would be a good idea so that it would be persistent over reboots. Kristian. > > - Mark From caddisconsulting@yahoo.com Wed Nov 9 21:40:06 2005 From: caddisconsulting@yahoo.com (Mike Horn) Date: Wed, 9 Nov 2005 14:40:06 -0700 Subject: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <20051109192417.GA12610@juniks.net> Message-ID: <200511092140.jA9Le4sA037457@wyvern.icir.org> Hi Kristian, Your example assumes that XORP creates a user defined interface name space (e.g. vif 10), which I'm not sure has been agreed upon. The example you listed would more preferrable (for me at least) than: interface eth0 { vlan-tagging: true; vif vlan0 { } } -mike -----Original Message----- From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On Behalf Of 'Kristian Larsson' Sent: Wednesday, November 09, 2005 12:24 PM To: Mike Horn Cc: xorp-hackers@xorp.org Subject: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts Well, yes and no. If you're inside xorp all the time you don't have to mess with the names. You can align the names within xorp. interface fxp0 { vlan-tagging: true; vif 10 { } vif 20 { } } would represent what you have below. On old FreeBSDs or other OSs you can't align them anyhow since you might have several vlan interfaces with the same tag though on different physical interfaces. And on Linux and newer FBSDs we would automatically align them. Kristian. On Wed, Nov 09, 2005 at 07:39:52AM -0700, Mike Horn wrote: > Hi, > > Another potential drawback of auto generating interface names or > numbers is that the user can't create their own logical mappings. For > instance I usually align sub-interface number and vlan-tag, > sub-interface and FR PVC, etc. For example, on a Juniper you can define. > > fe-0/0/3 { > vlan-tagging; > unit 10 { > vlan-id 10; > } > unit 20 { > vlan-id 20; > } > } > > This helps make the troubleshooting process easier since you know > fe-0/0/3.20 uses VLAN 20. > > -mike > > -----Original Message----- > From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] > On Behalf Of Mark Handley > Sent: Wednesday, November 09, 2005 2:53 AM > To: Kristian Larsson; Mark Handley; xorp-hackers@xorp.org > Subject: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts > > On 11/9/05, Kristian Larsson wrote: > > > ie, the "use-interface" part would be automatically generated. > > Is this really so hard to implement? > > The problem is how do you automatically generate this? The FEA could > do this, but the rtrmgr has no inbuild knowledge of the FEA or of > interfaces, so it can't generate this information. Currently there's > no way for the rtrmgr to dynamically update a running config from the > running processes - the model is that the running config is what the > user said it was. The rtrmgr that would need to use this information > to configure routing protocols, so it would need to know. > > - Mark > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian@juniks.net Thu Nov 10 05:49:52 2005 From: kristian@juniks.net (Kristian Larsson) Date: Thu, 10 Nov 2005 06:49:52 +0100 Subject: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts In-Reply-To: <200511092140.jA9Le4sA037457@wyvern.icir.org> References: <20051109192417.GA12610@juniks.net> <200511092140.jA9Le4sA037457@wyvern.icir.org> Message-ID: <20051110054952.GD12610@juniks.net> On Wed, Nov 09, 2005 at 02:40:06PM -0700, Mike Horn wrote: > Hi Kristian, > > Your example assumes that XORP creates a user defined interface name space > (e.g. vif 10), which I'm not sure has been agreed upon. The example you > listed would more preferrable (for me at least) than: Well, of course not. These are all just suggestions. Why a mailing list to discuss things if it had already been decided what to do? :) > > interface eth0 { > vlan-tagging: true; > vif vlan0 { > } > } You prefer using vlan0 over just vif 0? How should vlan0 be interpreted? Is it an old-style FreeBSD interface which has been configured outside of XORP or is it actually a vlan interface. If the latter it's untagged right, since you cannot use VLAN tag 0. Since I understand it is very hard to write the code for this perhaps we should incorporate several solutions. One where vif automagically is matched to a vlan tagging and one where the user may specify a interface to use. XORP# create interfaces interface fxp0 vif ? Possible completions: <0-4094> Add a VLAN interface, 0 being untagged vlan Specify a vlan interface to use. XORP# create interfaces interface fxp0 vif So, old style freebsd would look like: interface fxp0 { vif vlan fxp0 { description: "untagged"; } vif vlan vlan0 { description; "We already know the parent interface however tagging needs to be specified"; vlan-tag: 23; } interface fxp1 { vif vlan vlan1 { vlan-tag: 23; } } On systems such as newer FreeBSDs or Linux we could simply have: interface eth0 { vif 0 { description: "untagged"; } vif 23 { description: "this would be tagged vlan 23"; } interface eth1 { vif 0 { description: "untagged"; } vif 23 { } /* Of course, we could also use: */ vif vlan eth1.47 { description: "this would have the same effect as using just 'vif 47'"; } } I think that adding "vlan-tag" to a vif would only complicate things. In Linux the interface name is . you can't have an arbitrary last part. Thus having vif 20 with a vlan tag of 40 would be really strange. The system would know it as eth0.40 but xorp would refer to it as eth0 vif 20. Kristian. > > -mike > > -----Original Message----- > From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On > Behalf Of 'Kristian Larsson' > Sent: Wednesday, November 09, 2005 12:24 PM > To: Mike Horn > Cc: xorp-hackers@xorp.org > Subject: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some > thoughts > > Well, yes and no. > If you're inside xorp all the time you don't have to mess with the names. > You can align the names within xorp. > > interface fxp0 { > vlan-tagging: true; > vif 10 { > } > vif 20 { > } > } > > would represent what you have below. > On old FreeBSDs or other OSs you can't align them anyhow since you might > have several vlan interfaces with the same tag though on different physical > interfaces. > > And on Linux and newer FBSDs we would > automatically align them. > > Kristian. > > On Wed, Nov 09, 2005 at 07:39:52AM -0700, Mike Horn wrote: > > Hi, > > > > Another potential drawback of auto generating interface names or > > numbers is that the user can't create their own logical mappings. For > > instance I usually align sub-interface number and vlan-tag, > > sub-interface and FR PVC, etc. For example, on a Juniper you can define. > > > > fe-0/0/3 { > > vlan-tagging; > > unit 10 { > > vlan-id 10; > > } > > unit 20 { > > vlan-id 20; > > } > > } > > > > This helps make the troubleshooting process easier since you know > > fe-0/0/3.20 uses VLAN 20. > > > > -mike > > > > -----Original Message----- > > From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] > > On Behalf Of Mark Handley > > Sent: Wednesday, November 09, 2005 2:53 AM > > To: Kristian Larsson; Mark Handley; xorp-hackers@xorp.org > > Subject: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Xorp-hackers] Some thoughts > > > > On 11/9/05, Kristian Larsson wrote: > > > > > ie, the "use-interface" part would be automatically generated. > > > Is this really so hard to implement? > > > > The problem is how do you automatically generate this? The FEA could > > do this, but the rtrmgr has no inbuild knowledge of the FEA or of > > interfaces, so it can't generate this information. Currently there's > > no way for the rtrmgr to dynamically update a running config from the > > running processes - the model is that the running config is what the > > user said it was. The rtrmgr that would need to use this information > > to configure routing protocols, so it would need to know. > > > > - Mark > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers@icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From doll@tm.uka.de Thu Nov 10 07:14:33 2005 From: doll@tm.uka.de (Mark Doll) Date: Thu, 10 Nov 2005 08:14:33 +0100 Subject: [Xorp-hackers] Duplicated code in RIP In-Reply-To: <200511091913.28177.zec@icir.org> References: <43722C82.6050007@tm.uka.de> <200511091913.28177.zec@icir.org> Message-ID: <4372F359.6050605@tm.uka.de> Hi Marko! Marko Zec wrote: > On Wednesday 09 November 2005 18:06, Mark Doll wrote: > >>I wonder why some member functions of class XrlPortIO (i.e. >>request_socket_server, see file ~/rip/xlr_port_io.cc) are not >>generally defined using template parameter 'A' but are instead >>defined two times as specializations for 'IPv4' and 'IPv6', although >>the specializations only differ in constants and types, differences >>that are otherwise handled with class RIP_AF_CONSTANTS throughout >>RIP. > > > Another difference is that RIP sends / receives packets on IPv4 sockets, > while RIPng uses IPv6 sockets. Different socket types -> different XRL > interfaces that need to be used, thus the need for specialization > (socket4 vs socket6) in certain member functions. No, the interfaces socket4 and socket6 are identical except the address type (ipv4 vs. ipv6) and one minor naming difference in a socket option ("multicast_ttl" vs. "multicast_hops", just try a 'diff xrl/interfaces/socket{4,6}.xif'). So the code to access these two interfaces stays the same and can be programmed generically using templates. The code only has to declare the object used to access these interfaces to be of a different type (XrlSocket4V0p1Client vs. XrlSocket6V0p1Client). This and the different naming of the ttl socket option can be easily handled with RIP_AF_CONSTANTS (which already handles the different port, group, default route and version of RIP and RIPng, cf. ~/rip/constants.hh). I just wondered why they just stop in the middle and don't handle the remaining two differences with RIP_AF_CONSTANTS, too. Maybe there's a good reason I'm not aware of. Mark. P.S.: Since a type is not a constant, it might make (semantically) more sense not to use RIP_AF_CONSTANTS but to define another object, something like this: template struct XrlSocketClientType; template<> struct XrlSocketClientType { typedef XrlSocket4V0p1Client type; }; template<> struct XrlSocketClientType { typedef XrlSocket6V0p1Client type; }; template class XrlPortIO : ... { public: typedef typename XrlSocketClientType::type XrlSocketClient; ... and then use 'XrlSocketClient' in the functions instead of 'XrlSocket4V0p1Client' and 'XrlSocket6V0p1Client'. This has the convenient side effect that you only have to change one typedef in case the version of the socket interfaces changes in the future (and the changes in the interface don't affect RIP's usage of it). From zec@icir.org Thu Nov 10 10:49:01 2005 From: zec@icir.org (Marko Zec) Date: Thu, 10 Nov 2005 11:49:01 +0100 Subject: [Xorp-hackers] Duplicated code in RIP In-Reply-To: <4372F359.6050605@tm.uka.de> References: <43722C82.6050007@tm.uka.de> <200511091913.28177.zec@icir.org> <4372F359.6050605@tm.uka.de> Message-ID: <200511101149.01230.zec@icir.org> On Thursday 10 November 2005 08:14, Mark Doll wrote: > Hi Marko! > > Marko Zec wrote: > > On Wednesday 09 November 2005 18:06, Mark Doll wrote: > >>I wonder why some member functions of class XrlPortIO (i.e. > >>request_socket_server, see file ~/rip/xlr_port_io.cc) are not > >>generally defined using template parameter 'A' but are instead > >>defined two times as specializations for 'IPv4' and 'IPv6', > >> although the specializations only differ in constants and types, > >> differences that are otherwise handled with class > >> RIP_AF_CONSTANTS throughout RIP. > > > > Another difference is that RIP sends / receives packets on IPv4 > > sockets, while RIPng uses IPv6 sockets. Different socket types -> > > different XRL interfaces that need to be used, thus the need for > > specialization (socket4 vs socket6) in certain member functions. > > No, the interfaces socket4 and socket6 are identical except the > address type (ipv4 vs. ipv6) and one minor naming difference in a > socket option ("multicast_ttl" vs. "multicast_hops", just try a 'diff > xrl/interfaces/socket{4,6}.xif'). > > So the code to access these two interfaces stays the same and can be > programmed generically using templates. The code only has to declare > the object used to access these interfaces to be of a different type > (XrlSocket4V0p1Client vs. XrlSocket6V0p1Client). This and the > different naming of the ttl socket option can be easily handled with > RIP_AF_CONSTANTS (which already handles the different port, group, > default route and version of RIP and RIPng, cf. ~/rip/constants.hh). > > I just wondered why they just stop in the middle and don't handle the > remaining two differences with RIP_AF_CONSTANTS, too. Maybe > there's a good reason I'm not aware of. > > Mark. > > P.S.: Since a type is not a constant, it might make (semantically) > more sense not to use RIP_AF_CONSTANTS but to define another > object, something like this: > > template struct XrlSocketClientType; > template<> struct XrlSocketClientType { typedef > XrlSocket4V0p1Client type; }; template<> struct > XrlSocketClientType { typedef XrlSocket6V0p1Client type; }; > > template > class XrlPortIO : ... > { > public: > typedef typename XrlSocketClientType::type XrlSocketClient; > ... > > and then use 'XrlSocketClient' in the functions instead of > 'XrlSocket4V0p1Client' and 'XrlSocket6V0p1Client'. This has the > convenient side effect that you only have to change one typedef in > case the version of the socket interfaces changes in the future (and > the changes in the interface don't affect RIP's usage of it). I think you are right, and basically like the proposal to further reduce the specialization. Unfortunately RIP has other more fundamental problems that have to be dealt with first - it listens on a single wildcard socket instead of multiple per-interface ones. Once this gets cleaned up I agree that templatizing the XRL socket interface code might be worth a try. Cheers, Marko From doll@tm.uka.de Fri Nov 18 07:44:46 2005 From: doll@tm.uka.de (Mark Doll) Date: Fri, 18 Nov 2005 08:44:46 +0100 Subject: [Xorp-hackers] ~/libxorp/heap.cc:293 missing 'const' Message-ID: <437D866E.8020404@tm.uka.de> Sorry for being nit-picky, but in ~/libxorp/heap.cc:293 'char *blanks="" ;' should be 'const char *blanks="" ;'. It's in the test code, so the code is normally unused. It seems to be the only time this deprecated C++ feature is used in XORP. Mark. From pavlin@icir.org Fri Nov 18 08:46:18 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 18 Nov 2005 00:46:18 -0800 Subject: [Xorp-hackers] ~/libxorp/heap.cc:293 missing 'const' In-Reply-To: Message from Mark Doll of "Fri, 18 Nov 2005 08:44:46 +0100." <437D866E.8020404@tm.uka.de> Message-ID: <200511180846.jAI8kIKH086431@possum.icir.org> > Sorry for being nit-picky, but in ~/libxorp/heap.cc:293 'char > *blanks="" ;' should be 'const char *blanks="" ;'. It's in the > test code, so the code is normally unused. It seems to be the only > time this deprecated C++ feature is used in XORP. Problem fixed and committed to CVS. Thanks, Pavlin From hasso@linux.ee Fri Nov 25 10:26:26 2005 From: hasso@linux.ee (Hasso Tepper) Date: Fri, 25 Nov 2005 12:26:26 +0200 Subject: [Xorp-hackers] CVS tree via rsync? Message-ID: <200511251226.26850.hasso@linux.ee> Is there way to get entire CVS tree via rsync? I'm asking because I'm using SVK (http://svk.elixus.org/) for all my development locally and it would give to me the way to use it for Xorp as well (ie. to mirror cvs tree to my local SVK repo). Yes, I know that I can use pserver for that as well, but I'd prefer not to do that. Mirroring from local copy is much cleaner and less problematic. -- Hasso Tepper