From pavlin at icir.org Mon May 1 14:46:09 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 01 May 2006 14:46:09 -0700 Subject: [Xorp-hackers] Possible fix for XORP bug 603 In-Reply-To: Message from Justin Fletcher of "Thu, 27 Apr 2006 18:00:02 PDT." <6217484.871146186002138.JavaMail.root@mail.vyatta.com> Message-ID: <200605012146.k41Lk9ln095696@possum.icir.org> > > Just don't do it please :) > > > > * Global variables are bad and should be avoid unless there is no > > other solution. > > > > * The patch introduces an "interesting" dependency: the libcli > > library becomes dependent on the xorpsh/rtrmgr code. > > > > * The real problem was somewhere else and the bogus command-line > > completion for the "show ospf4" command was a side effect of that > > problem. This problem is now fixed in CVS. > > See XORP Bugzilla entry #603 for details: > > http://www.xorp.org/bugzilla/show_bug.cgi?id=603 > > The fix to ospfv2.cmds fixes the specific case, but unfortunately > not the general case. > > Template entries of the form > > cmd opt1 opt2 { > } > > where both opt1 and opt2 must be specified end up with "cmd opt1" > being marked as valid in help, even though it's not executable. Indeed. The problem is now fixed in CVS: 1.66 +34 -10; commitid: e8ed44567dd27ea6; xorp/rtrmgr/op_commands.cc > There are also issues with configuration templates; I'll need to come > up with specific examples for both. Yes please. Thanks, Pavlin From jfletcher at vyatta.com Tue May 2 11:26:29 2006 From: jfletcher at vyatta.com (Justin Fletcher) Date: Tue, 2 May 2006 11:26:29 -0700 (PDT) Subject: [Xorp-hackers] Possible fix for XORP bug 603 Message-ID: <11698175.361146594389488.JavaMail.root@mail.vyatta.com> > > Template entries of the form > > > > cmd opt1 opt2 { > > } > > > > where both opt1 and opt2 must be specified end up with "cmd opt1" > > being marked as valid in help, even though it's not executable. > > Indeed. > The problem is now fixed in CVS: > > 1.66 +34 -10; commitid: e8ed44567dd27ea6; > xorp/rtrmgr/op_commands.cc Wonderful. Thanks! Justin Fletcher Vyatta From kristian at juniks.net Thu May 4 12:35:23 2006 From: kristian at juniks.net (Kristian Larsson) Date: Thu, 4 May 2006 21:35:23 +0200 Subject: [Xorp-hackers] VLANs Message-ID: <20060504193523.GC8487@juniks.net> Vyatta have had working VLAN support for some time now. Is there anyone having any objections backporting this into XORP? I know the support is only for Linux, but by starting with the Vyatta code we can work our way from there. The interface configuration changes which from a certain point of view, is a bad thing. From another is not such a bad thing since it's probably more logical. Opinions? Regards, Kristian. From kristian at juniks.net Thu May 4 13:51:21 2006 From: kristian at juniks.net (Kristian Larsson) Date: Thu, 4 May 2006 22:51:21 +0200 Subject: [Xorp-hackers] OSPF.. Message-ID: <20060504205120.GD8487@juniks.net> I would like 'router-dead-interval' to change name to 'dead-time', since it's not really an interval and I don't think "router-" clarifies anything... Kristian. From mhorn at vyatta.com Thu May 4 14:04:21 2006 From: mhorn at vyatta.com (Mike Horn) Date: Thu, 4 May 2006 15:04:21 -0600 Subject: [Xorp-hackers] OSPF.. In-Reply-To: <20060504205120.GD8487@juniks.net> Message-ID: <020201c66fbe$50ea9ca0$6502a8c0@caddisconsulting.com> I second the motion! There are a lot of node names that should probably be simplified and shortened. It might make sense to come up with a list and then submit the changes as a single patch rather then changes the nodes on an individual basis. -mike -----Original Message----- From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Kristian Larsson Sent: Thursday, May 04, 2006 2:51 PM To: xorp-hackers at xorp.org Subject: [Xorp-hackers] OSPF.. I would like 'router-dead-interval' to change name to 'dead-time', since it's not really an interval and I don't think "router-" clarifies anything... Kristian. _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From jfletcher at vyatta.com Thu May 4 14:15:53 2006 From: jfletcher at vyatta.com (Justin Fletcher) Date: Thu, 4 May 2006 14:15:53 -0700 (PDT) Subject: [Xorp-hackers] OSPF.. Message-ID: <23297053.271146777353125.JavaMail.root@mail.vyatta.com> While it's true that there are node names that could and maybe should be simplifed, but I don't think this is one of them. It's straight out of RFC 2328. Justin ----- Mike Horn wrote: > I second the motion! There are a lot of node names that should > probably be > simplified and shortened. It might make sense to come up with a list > and > then submit the changes as a single patch rather then changes the > nodes on > an individual basis. > > -mike > > -----Original Message----- > From: xorp-hackers-bounces at icir.org > [mailto:xorp-hackers-bounces at icir.org] > On Behalf Of Kristian Larsson > Sent: Thursday, May 04, 2006 2:51 PM > To: xorp-hackers at xorp.org > Subject: [Xorp-hackers] OSPF.. > > I would like 'router-dead-interval' to change name to 'dead-time', > since > it's not really an interval and I don't think "router-" clarifies > anything... > > Kristian. > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian at juniks.net Thu May 4 22:35:00 2006 From: kristian at juniks.net (Kristian Larsson) Date: Fri, 5 May 2006 07:35:00 +0200 Subject: [Xorp-hackers] OSPF.. In-Reply-To: <23297053.271146777353125.JavaMail.root@mail.vyatta.com> References: <23297053.271146777353125.JavaMail.root@mail.vyatta.com> Message-ID: <20060505053500.GE8487@juniks.net> On Thu, May 04, 2006 at 02:15:53PM -0700, Justin Fletcher wrote: > While it's true that there are node names that could and maybe > should be simplifed, but I don't think this is one of them. It's > straight out of RFC 2328. Hmm, okey. I thought that interval was the time between two runs of a recurring event. Can't see how the dead time thing is a recurring event. But hey, English is not my native language so what do I know? ;) Kristian. From hasso at linux.ee Thu May 4 22:57:09 2006 From: hasso at linux.ee (Hasso Tepper) Date: Fri, 5 May 2006 08:57:09 +0300 Subject: [Xorp-hackers] OSPF.. In-Reply-To: <20060505053500.GE8487@juniks.net> References: <23297053.271146777353125.JavaMail.root@mail.vyatta.com> <20060505053500.GE8487@juniks.net> Message-ID: <200605050857.10288.hasso@linux.ee> Kristian Larsson wrote: > On Thu, May 04, 2006 at 02:15:53PM -0700, Justin Fletcher wrote: > > While it's true that there are node names that could and maybe > > should be simplifed, but I don't think this is one of them. It's > > straight out of RFC 2328. > > Hmm, okey. > > I thought that interval was the time between two > runs of a recurring event. Can't see how the > dead time thing is a recurring event. > > But hey, English is not my native language so what > do I know? ;) I thought about this as well while writing cli style guide, but I left it out for same reason - I'm not native English speaker. But the idea was same - "-interval" should be used in case of recurring events only, "-time" or "-timer" (it's better in some cases) in case of one time events. And there is "-delay" - something is hold back or period of time (spf-delay in OSPF etc). -- Hasso Tepper From hasso at linux.ee Thu May 4 23:01:56 2006 From: hasso at linux.ee (Hasso Tepper) Date: Fri, 5 May 2006 09:01:56 +0300 Subject: [Xorp-hackers] OSPF.. In-Reply-To: <200605050857.10288.hasso@linux.ee> References: <23297053.271146777353125.JavaMail.root@mail.vyatta.com> <20060505053500.GE8487@juniks.net> <200605050857.10288.hasso@linux.ee> Message-ID: <200605050901.57088.hasso@linux.ee> Hasso Tepper wrote: > And there is "-delay" - something is hold back or period of time > (spf-delay in OSPF etc). s/or period/for period/ -- Hasso Tepper From krn at krn.dk Mon May 8 08:54:34 2006 From: krn at krn.dk (Kristen Nielsen) Date: Mon, 08 May 2006 17:54:34 +0200 Subject: [Xorp-hackers] Question about Template file functionality Message-ID: <445F69BA.30307@krn.dk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi xorp-hackers list In the template file (etc/templates/*tp) I have a short question: in the part below (from bgp.tp): targetname { %help: short "Set the target name"; %set:; } bgp-id { %set: xrl "$(bgp.targetname)/bgp/0.2/set_bgp_id?id:ipv4=$(@)"; %get: xrl "$(bgp.targetname)/bgp/0.2/get_bgp_id->id:ipv4"; } In the targetname: node Does the set:; line map to a function that sets the value of the targetname leaf-node (but do not invoke any xrl calls)? Does the missing %delete:; and %get:; mean that it is not possible to delete and get this value from the node e.g. from the xorpsh? I guess that other lines in the template file will be able to read the targetname value, is this correct? In the bgp-id node lines: does the returned value from the %get: line opdate the bgp-id node value ? Is the %get xrl being executed when other template rules want to read the bgp-id node-value. Thanks Kristen Nielsen Denmark krn at krn.dk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEX2m4e7tFxipD00wRAkRoAKCOL/TWl58UwKCljcTmVKdyz3MeZQCgzy8I rHmi6xUSqz6bIa9KdIQ6yvw= =3rix -----END PGP SIGNATURE----- From mike at vyatta.com Mon May 8 11:31:54 2006 From: mike at vyatta.com (Michael Larson) Date: Mon, 8 May 2006 11:31:54 -0700 (PDT) Subject: [Xorp-hackers] order of create/delete operations Message-ID: <24118679.01147113114146.JavaMail.root@mail.vyatta.com> quick question/random thought... During a commit wouldn't it make sense to apply all the delete xrls prior to the create/sets? I can appreciate that this is not globally possible (across all nodes within a commit) due to transactions--but shouldn't this be true within the scope of a transaction? Mike Larson vyatta From pavlin at icir.org Tue May 9 00:58:20 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 09 May 2006 00:58:20 -0700 Subject: [Xorp-hackers] VLANs In-Reply-To: Message from Kristian Larsson of "Thu, 04 May 2006 21:35:23 +0200." <20060504193523.GC8487@juniks.net> Message-ID: <200605090758.k497wKZI073743@possum.icir.org> > Vyatta have had working VLAN support for some time > now. Is there anyone having any objections > backporting this into XORP? > I know the support is only for Linux, but by > starting with the Vyatta code we can work our way > from there. In general, we would like to port-back (as time allows us) many of the good things the Vyatta folks have added to their code. However, in case of VLAN specifically, the Vyatta solution won't work for us, because it is not portable. E.g., the interfaces.tp rtrmgr template file contains the following %create commands which deal with creating VLAN vifs: %create: program "modprobe 8021q"; %create: program "vconfig add $(ethernet.@) $(@)"; Those external commands are Linux specific and we cannot use them in XORP. Implementing it portably eventually means that we need to add the appropriate support to the FEA, and this is not a trivial task. Pavlin From kristian at spritelink.se Tue May 9 08:34:06 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Tue, 9 May 2006 17:34:06 +0200 Subject: [Xorp-hackers] VLANs In-Reply-To: <200605090758.k497wKZI073743@possum.icir.org> References: <20060504193523.GC8487@juniks.net> <200605090758.k497wKZI073743@possum.icir.org> Message-ID: <20060509153406.GD6943@spritelink.se> On Tue, May 09, 2006 at 12:58:20AM -0700, Pavlin Radoslavov wrote: > > Vyatta have had working VLAN support for some > > time > > now. Is there anyone having any objections > > backporting this into XORP? > > I know the support is only for Linux, but by > > starting with the Vyatta code we can work our > > way > > from there. > > In general, we would like to port-back (as time > allows us) many of > the good things the Vyatta folks have added to > their code. > > However, in case of VLAN specifically, the > Vyatta solution won't > work for us, because it is not portable. E.g., > the interfaces.tp > rtrmgr template file contains the following > %create commands which > deal with creating VLAN vifs: > > %create: program "modprobe 8021q"; This makes sure the 802.1q module is loaded in the kernel. I don't really think it is the job of XORP to make sure the underlying operating system has support for .1q, it is the responsibility of the administrator. I for one would not use a module but rather compile the support into the kernel. > %create: program "vconfig add > $(ethernet.@) $(@)"; This is certainly not an elegant solution. However there is no problem doing this from within the fea. I've provided a very simple code example of adding vlans on a Linux system, it's available at http://www.xorp.org/bugzilla/attachment.cgi?id=79&action=view > Those external commands are Linux specific and > we cannot use them in > XORP. Implementing it portably eventually means > that we need to add > the appropriate support to the FEA, and this is > not a trivial task. Yes I am aware of this. But I feel that we should try to move in the "right" direction, whichever direction that is. And to be honest I don't really see the "non trivial" parts of this as long as you're confident with C it shouldn't be a problem, right ;) Kristian. From kristian at spritelink.se Tue May 9 06:02:43 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Tue, 9 May 2006 15:02:43 +0200 Subject: [Xorp-hackers] VLANs In-Reply-To: <200605090758.k497wKZI073743@possum.icir.org> References: <20060504193523.GC8487@juniks.net> <200605090758.k497wKZI073743@possum.icir.org> Message-ID: <20060509130242.GB6943@spritelink.se> On Tue, May 09, 2006 at 12:58:20AM -0700, Pavlin Radoslavov wrote: > > Vyatta have had working VLAN support for some time > > now. Is there anyone having any objections > > backporting this into XORP? > > I know the support is only for Linux, but by > > starting with the Vyatta code we can work our way > > from there. > > In general, we would like to port-back (as time allows us) many of > the good things the Vyatta folks have added to their code. > > However, in case of VLAN specifically, the Vyatta solution won't > work for us, because it is not portable. E.g., the interfaces.tp > rtrmgr template file contains the following %create commands which > deal with creating VLAN vifs: > > %create: program "modprobe 8021q"; This makes sure the 802.1q module is loaded in the kernel. I don't really think it is the job of XORP to make sure the underlying operating system has support for .1q, it is the responsibility of the administrator. I for one would not use a module but rather compile the support into the kernel. > %create: program "vconfig add $(ethernet.@) $(@)"; This is certainly not an elegant solution. However there is no problem doing this from within the fea. I've provided a very simple code example of adding vlans on a Linux system, it's available at http://www.xorp.org/bugzilla/attachment.cgi?id=79&action=view > Those external commands are Linux specific and we cannot use them in > XORP. Implementing it portably eventually means that we need to add > the appropriate support to the FEA, and this is not a trivial task. Yes I am aware of this. But I feel that we should try to move in the "right" direction, whichever direction that is. And to be honest I don't really see the "non trivial" parts of this as long as you're confident with C it shouldn't be a problem, right ;) Kristian. From pavlin at icir.org Tue May 9 11:32:47 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 09 May 2006 11:32:47 -0700 Subject: [Xorp-hackers] VLANs In-Reply-To: Message from Kristian Larsson of "Tue, 09 May 2006 15:02:43 +0200." <20060509130242.GB6943@spritelink.se> Message-ID: <200605091832.k49IWllj082197@possum.icir.org> Kristian Larsson wrote: > On Tue, May 09, 2006 at 12:58:20AM -0700, Pavlin Radoslavov wrote: > > > Vyatta have had working VLAN support for some time > > > now. Is there anyone having any objections > > > backporting this into XORP? > > > I know the support is only for Linux, but by > > > starting with the Vyatta code we can work our way > > > from there. > > > > In general, we would like to port-back (as time allows us) many of > > the good things the Vyatta folks have added to their code. > > > > However, in case of VLAN specifically, the Vyatta solution won't > > work for us, because it is not portable. E.g., the interfaces.tp > > rtrmgr template file contains the following %create commands which > > deal with creating VLAN vifs: > > > > %create: program "vconfig add $(ethernet.@) $(@)"; > This is certainly not an elegant solution. > However there is no problem doing this from within > the fea. I've provided a very simple code example > of adding vlans on a Linux system, it's available > at > http://www.xorp.org/bugzilla/attachment.cgi?id=79&action=view Yes, we want to do use such system calls in the FEA to manage the VLANs. The "non-trivial" part is that we need to investigate how it is done for different OS-es, provide the mechanisms to read vlan info, etc. There are no big issues in doing this, it is primarily a question of finding the time to design and implementing it carefully to cover various details. Pavlin From pavlin at icir.org Tue May 9 16:02:47 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 09 May 2006 16:02:47 -0700 Subject: [Xorp-hackers] order of create/delete operations In-Reply-To: Message from Michael Larson of "Mon, 08 May 2006 11:31:54 PDT." <24118679.01147113114146.JavaMail.root@mail.vyatta.com> Message-ID: <200605092302.k49N2lt8087760@possum.icir.org> > quick question/random thought... > > During a commit wouldn't it make sense to apply all the delete > xrls prior to the create/sets? > > I can appreciate that this is not globally possible (across all > nodes within a commit) due to transactions--but shouldn't this be > true within the scope of a transaction? I believe it was a semantic decision to have the create/sets before the deletes. Can you give an example that demonstrates it is better to have the deletes before the create/sets. Pavlin From pavlin at icir.org Tue May 9 16:21:57 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 09 May 2006 16:21:57 -0700 Subject: [Xorp-hackers] Question about Template file functionality In-Reply-To: Message from Kristen Nielsen of "Mon, 08 May 2006 17:54:34 +0200." <445F69BA.30307@krn.dk> Message-ID: <200605092321.k49NLvmN087978@possum.icir.org> > In the template file (etc/templates/*tp) I have a short question: > > in the part below (from bgp.tp): > > targetname { > %help: short "Set the target name"; > %set:; > } > > bgp-id { > %set: xrl "$(bgp.targetname)/bgp/0.2/set_bgp_id?id:ipv4=$(@)"; > %get: xrl "$(bgp.targetname)/bgp/0.2/get_bgp_id->id:ipv4"; > } > > In the targetname: node > Does the set:; line map to a function that sets the value of the > targetname leaf-node (but do not invoke any xrl calls)? The empty "set:;" allows you to set the value of the corresponding leaf node using xorpsh. When committing such modification, no XRLs or programs will be invoked, only the value of that node will be modified inside the rtrmgr master configuration tree. BTW, in case of targetname, I wouldn't recommend modifying it, because then all corresponding XRLs will be send to the wrong XRL target. > Does the missing %delete:; and %get:; mean that it is not possible to > delete and get this value from the node e.g. from the xorpsh? Yes, if there is no %delete, then you cannot delete it. Both the targetname and bgp-id are mandatory so under no circumstances they should be deleted. The %get method is a no-op and it will be removed in the future, In fact, it is not really used, and is not even implemented properly. > I guess that other lines in the template file will be able to read the > targetname value, is this correct? Yes. > In the bgp-id node lines: > does the returned value from the %get: line opdate the bgp-id node value ? > Is the %get xrl being executed when other template rules want to read > the bgp-id node-value. No (see above). The master configuration tree inside the rtrmgr should contain the current values. If a template rule wants to read the value of some node and that node is part of the configuration tree (or has a default value), the value should be available inside the master configuration tree. Pavlin From mike at vyatta.com Tue May 9 16:41:48 2006 From: mike at vyatta.com (Michael Larson) Date: Tue, 9 May 2006 16:41:48 -0700 (PDT) Subject: [Xorp-hackers] order of create/delete operations Message-ID: <33424148.601147218108568.JavaMail.root@mail.vyatta.com> Yes, I can understand why the current behavior makes sense. The case I'm thinking of is when an underlying data value is referenced by two distinct nodes that are not directly related to each other (parent/child). So a construction similar to: #note wrapped by a transaction. common_parent { sib1 { foo { %create: %delete } } sib2 { foo { %create: %delete } } } Now, let's say that both foo's point to the same data structure, then the order of creation/deletion are important--for instance: delete common_parent sib1 foo create common_parent sib2 foo is completely different from: create common_parent sib2 foo delete common_parent sib1 foo The order of execute of these two commands is not determinate (or maybe it is, but I haven't figured it out yet). Probably it would be better to re-work the data structure in this case--but this isn't always possible (as in one case we have). Does this make sense? If deletes were always applied first in a transaction then the behavior would be deterministic and the delete operation above would always occur first. Mike ----- Original Message ----- From: Pavlin Radoslavov To: Michael Larson Cc: xorp-hackers at icir.org Sent: Tuesday, May 9, 2006 4:02:47 PM GMT-0800 Subject: Re: [Xorp-hackers] order of create/delete operations > quick question/random thought... > > During a commit wouldn't it make sense to apply all the delete > xrls prior to the create/sets? > > I can appreciate that this is not globally possible (across all > nodes within a commit) due to transactions--but shouldn't this be > true within the scope of a transaction? I believe it was a semantic decision to have the create/sets before the deletes. Can you give an example that demonstrates it is better to have the deletes before the create/sets. Pavlin _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at icir.org Tue May 9 16:58:43 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 09 May 2006 16:58:43 -0700 Subject: [Xorp-hackers] order of create/delete operations In-Reply-To: Message from Michael Larson of "Tue, 09 May 2006 16:41:48 PDT." <33424148.601147218108568.JavaMail.root@mail.vyatta.com> Message-ID: <200605092358.k49Nwhm1088432@possum.icir.org> > The case I'm thinking of is when an underlying data value is > referenced by two distinct nodes that are not directly related to > each other (parent/child). So a construction similar to: > > > #note wrapped by a transaction. > common_parent { > sib1 { > foo { > %create: > %delete > } > } > > sib2 { > foo { > %create: > %delete > } > } > } > > > Now, let's say that both foo's point to the same data structure, Can you clarify what you mean by "same data structure". E.g., does it mean that both "foo" contain same XRLs send to the same target? > then the order of creation/deletion are important--for instance: > > delete common_parent sib1 foo > create common_parent sib2 foo > > is completely different from: > > create common_parent sib2 foo > delete common_parent sib1 foo Are you saying that if we use the above "create/delete" xorpsh commands in different order, then the corresponding %create and %delete methods are also executed in different orders? Do sib1 and sib2 belong to the same module? If yes, then it looks like a bug to me, because I think the %create should always happen before the %delete (unless I am forgetting/missing something). Pavlin > The order of execute of these two commands is not determinate (or maybe it is, but I haven't figured it out yet). > > Probably it would be better to re-work the data structure in this > case--but this isn't always possible (as in one case we > have). Does this make sense? If deletes were always applied first > in a transaction then the behavior would be deterministic and the > delete operation above would always occur first. From mike at vyatta.com Tue May 9 20:35:59 2006 From: mike at vyatta.com (Michael Larson) Date: Tue, 9 May 2006 20:35:59 -0700 (PDT) Subject: [Xorp-hackers] order of create/delete operations Message-ID: <1479548.691147232159921.JavaMail.root@mail.vyatta.com> OK Pavlin--I see your point and it makes sense. All creates are applied before deletes, which is required when operating on single nodes (you need to create the node before you can delete it)--and it makes sense to apply this rule across all nodes. I believe the behavior I'm seeing is consistent with that. Thanks! Mike ----- Original Message ----- From: Pavlin Radoslavov To: Michael Larson Cc: xorp-hackers at icir.org, Pavlin Radoslavov Sent: Tuesday, May 9, 2006 4:58:43 PM GMT-0800 Subject: Re: [Xorp-hackers] order of create/delete operations > The case I'm thinking of is when an underlying data value is > referenced by two distinct nodes that are not directly related to > each other (parent/child). So a construction similar to: > > > #note wrapped by a transaction. > common_parent { > sib1 { > foo { > %create: > %delete > } > } > > sib2 { > foo { > %create: > %delete > } > } > } > > > Now, let's say that both foo's point to the same data structure, Can you clarify what you mean by "same data structure". E.g., does it mean that both "foo" contain same XRLs send to the same target? > then the order of creation/deletion are important--for instance: > > delete common_parent sib1 foo > create common_parent sib2 foo > > is completely different from: > > create common_parent sib2 foo > delete common_parent sib1 foo Are you saying that if we use the above "create/delete" xorpsh commands in different order, then the corresponding %create and %delete methods are also executed in different orders? Do sib1 and sib2 belong to the same module? If yes, then it looks like a bug to me, because I think the %create should always happen before the %delete (unless I am forgetting/missing something). Pavlin > The order of execute of these two commands is not determinate (or maybe it is, but I haven't figured it out yet). > > Probably it would be better to re-work the data structure in this > case--but this isn't always possible (as in one case we > have). Does this make sense? If deletes were always applied first > in a transaction then the behavior would be deterministic and the > delete operation above would always occur first. _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian at spritelink.se Wed May 10 02:04:21 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Wed, 10 May 2006 11:04:21 +0200 Subject: [Xorp-hackers] VLANs In-Reply-To: <200605091832.k49IWllj082197@possum.icir.org> References: <20060509130242.GB6943@spritelink.se> <200605091832.k49IWllj082197@possum.icir.org> Message-ID: <20060510090420.GA17949@spritelink.se> On Tue, May 09, 2006 at 11:32:47AM -0700, Pavlin Radoslavov wrote: > Kristian Larsson wrote: > > > On Tue, May 09, 2006 at 12:58:20AM -0700, Pavlin Radoslavov wrote: > > > > Vyatta have had working VLAN support for some time > > > > now. Is there anyone having any objections > > > > backporting this into XORP? > > > > I know the support is only for Linux, but by > > > > starting with the Vyatta code we can work our way > > > > from there. > > > > > > In general, we would like to port-back (as time allows us) many of > > > the good things the Vyatta folks have added to their code. How far should XORP go, I'm thinking about the vrrpd daemon... is this something that can be integrated into XORP or is that off limits? > > > However, in case of VLAN specifically, the Vyatta solution won't > > > work for us, because it is not portable. E.g., the interfaces.tp > > > rtrmgr template file contains the following %create commands which > > > deal with creating VLAN vifs: > > > > > > > > > %create: program "vconfig add $(ethernet.@) $(@)"; > > This is certainly not an elegant solution. > > However there is no problem doing this from within > > the fea. I've provided a very simple code example > > of adding vlans on a Linux system, it's available > > at > > http://www.xorp.org/bugzilla/attachment.cgi?id=79&action=view > > Yes, we want to do use such system calls in the FEA to manage the > VLANs. The "non-trivial" part is that we need to investigate how it > is done for different OS-es, provide the mechanisms to read vlan > info, etc. There are no big issues in doing this, it is primarily a > question of finding the time to design and implementing it carefully > to cover various details. I see. Keeping it compatible with Linux and *BSD is probably something quite trivial but with Windows or something else I can imagine it's a whole different story. What I want is to start off somewhere. Right now, this seems like some holy grail that noone dare touch. By implementing most of the Vyatta work, ofcourse with some exceptions, I think we would have a good starting point. The vif syntax would probably have to change, I find the Vyatta way of doing it quite natural. Does anyone have any objections against it? Kristian. From deathdealer at gmx.net Wed May 10 09:41:58 2006 From: deathdealer at gmx.net (Patrick Marc Preuss) Date: Wed, 10 May 2006 18:41:58 +0200 Subject: [Xorp-hackers] VLANs In-Reply-To: <20060510090420.GA17949@spritelink.se> References: <20060509130242.GB6943@spritelink.se> <200605091832.k49IWllj082197@possum.icir.org> <20060510090420.GA17949@spritelink.se> Message-ID: <446217D6.2040700@gmx.net> Kristian Larsson said the following on 5/10/2006 11:04 AM: > How far should XORP go, I'm thinking about the > vrrpd daemon... is this something that can be > integrated into XORP or is that off limits? > I think it is a good idea most routing platforms have something like vrrp, in the same line i would see a feature form cisco glbp (Gateway load balancing Protocol), witch load balances incoming IPv4 LAN Traffic from end systems. Can we make a feature list site where we can see what is planed or requested may be we can vote for features. Have anyone seen an article or an implementation for WAN / Application optimisation, like the Boxes from Peribit/Juniper. What does you think about such things? > Keeping it compatible with Linux and *BSD is > probably something quite trivial but with Windows or > something else I can imagine it's a whole > different story. > > What I want is to start off somewhere. Right now, > this seems like some holy grail that noone dare > touch. By implementing most of the Vyatta work, > ofcourse with some exceptions, I think we would > have a good starting point. YES > > The vif syntax would probably have to change, I > find the Vyatta way of doing it quite natural. > Does anyone have any objections against it? How does Vyatta does this? Can you give me a point to the Docs? > > Kristian. > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > Patrick From robert at vyatta.com Wed May 10 11:11:10 2006 From: robert at vyatta.com (Robert Bays) Date: Wed, 10 May 2006 11:11:10 -0700 Subject: [Xorp-hackers] VLANs In-Reply-To: <44613686.9010602@vyatta.com> References: <20060504193523.GC8487@juniks.net> <200605090758.k497wKZI073743@possum.icir.org> <20060509153406.GD6943@spritelink.se> <44613686.9010602@vyatta.com> Message-ID: <44622CBE.4010502@vyatta.com> Sent this out yesterday from the wrong mail account... Robert Bays wrote: > > > Kristian Larsson wrote: >>> %create: program "vconfig add >>> $(ethernet.@) >>> $(@)"; >> >> This is certainly not an elegant solution. >> However there is no problem doing this from within >> the fea. I've provided a very simple code example >> of adding vlans on a Linux system, it's available >> at >> http://www.xorp.org/bugzilla/attachment.cgi?id=79&action=view > > While it may not be elegant, it seems to work. And I would argue is a > more pure implementation than creating vlan devices in the fea (from a > XORP point of view anyway). To date, XORP doesn't create system > interfaces. It relies on the operating system to provide them. Enabling > the fea to know how to create and configure the wide range of interfaces > is probably beyond the scope of the fea, IMHO. vlans are maybe a > borderline example, but also consider a Sangoma or Digium T1/E1 > interface. As long as XORP provides a convenient method for using > existing system tools to create the interface and set layer 2 parameters > before any XRLs are processed, you can add support for many interface > types relatively easily. And that is probably the real goal. XORP need > only know about the layer 3 characteristics of the device in order to > utilize it. > > As for vlans under BSD, I think it would be fairly easy to do the same > thing Vyatta did under Linux by replacing the 'vconfig' call with > something like 'ifconfig $(vif.@) create; ifconfig $(vif.@) vlan > $(vif.id) vlandev $(interface.@)'. Then reference 'interface:($vif.@) > vif:$(vif.@)' in all subsequent XRL calls. To take it one step further, > you could probably hide OS specifics and create a mostly generic > template by defining a parameter in the template and just referencing it > in the program call, much like the tftp/ftp/http mechanism that exists > in the templates now. That parameter could be populated in the template > at compile time. > > Cheers, > Robert > From kristian at spritelink.se Wed May 10 14:19:00 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Wed, 10 May 2006 23:19:00 +0200 Subject: [Xorp-hackers] VLANs In-Reply-To: <44622CBE.4010502@vyatta.com> References: <20060504193523.GC8487@juniks.net> <200605090758.k497wKZI073743@possum.icir.org> <20060509153406.GD6943@spritelink.se> <44613686.9010602@vyatta.com> <44622CBE.4010502@vyatta.com> Message-ID: <20060510211859.GC17949@spritelink.se> On Wed, May 10, 2006 at 11:11:10AM -0700, Robert Bays wrote: > Sent this out yesterday from the wrong mail account... > > Robert Bays wrote: > > > > > > Kristian Larsson wrote: > >>> %create: program "vconfig add > >>> $(ethernet.@) > >>> $(@)"; > >> > >> This is certainly not an elegant solution. > >> However there is no problem doing this from within > >> the fea. I've provided a very simple code example > >> of adding vlans on a Linux system, it's available > >> at > >> http://www.xorp.org/bugzilla/attachment.cgi?id=79&action=view > > > > While it may not be elegant, it seems to work. And I would argue is a > > more pure implementation than creating vlan devices in the fea (from a > > XORP point of view anyway). I tend not to agree. It's not that many extra lines of code. Most things are done by the actual operating system anyway, you just call a few controls. I suspect it's a bit easier handling error cases when doing it via ioctl(or the alike) instead of calling ifconfig. > > To date, XORP doesn't create system > > interfaces. It relies on the operating system to provide them. Enabling > > the fea to know how to create and configure the wide range of interfaces > > is probably beyond the scope of the fea, IMHO. vlans are maybe a > > borderline example, but also consider a Sangoma or Digium T1/E1 > > interface. As long as XORP provides a convenient method for using > > existing system tools to create the interface and set layer 2 parameters > > before any XRLs are processed, you can add support for many interface > > types relatively easily. And that is probably the real goal. XORP need > > only know about the layer 3 characteristics of the device in order to > > utilize it. No.... If we just stick to the layer 3 characteristics no one will use XORP. I don't want to use ifconfig to setup interfaces and then xorp to do the routing. I want a more or less complete routing system with all there is to it. XORP must be able to handle more than just routing. Kristian. From kristian at spritelink.se Wed May 10 14:22:49 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Wed, 10 May 2006 23:22:49 +0200 Subject: [Xorp-hackers] VLANs In-Reply-To: <446217D6.2040700@gmx.net> References: <20060509130242.GB6943@spritelink.se> <200605091832.k49IWllj082197@possum.icir.org> <20060510090420.GA17949@spritelink.se> <446217D6.2040700@gmx.net> Message-ID: <20060510212248.GD17949@spritelink.se> On Wed, May 10, 2006 at 06:41:58PM +0200, Patrick Marc Preuss wrote: > Kristian Larsson said the following on 5/10/2006 11:04 AM: > > > How far should XORP go, I'm thinking about the > > vrrpd daemon... is this something that can be > > integrated into XORP or is that off limits? > > > I think it is a good idea most routing platforms have something like > vrrp, in the same line i would see a feature form cisco glbp (Gateway > load balancing Protocol), witch load balances incoming IPv4 LAN Traffic > from end systems. I don't think the xorp project should spend it's time writing a vrrp or glbp daemon but rather if it's already out there we could integrate it so that it can be configured via xorp. > Can we make a feature list site where we can see what is planed or > requested may be we can vote for features. http://www.xorp.org/bugzilla/index.cgi > Have anyone seen an article or an implementation for WAN / Application > optimisation, like the Boxes from Peribit/Juniper. What does you think > about such things? It's a bit too far in the future for me. First get stable basic routing things like interface configuration and properly working routing protocols with policys. > > > Keeping it compatible with Linux and *BSD is > > probably something quite trivial but with Windows or > > something else I can imagine it's a whole > > different story. > > > > What I want is to start off somewhere. Right now, > > this seems like some holy grail that noone dare > > touch. By implementing most of the Vyatta work, > > ofcourse with some exceptions, I think we would > > have a good starting point. > YES > > > > The vif syntax would probably have to change, I > > find the Vyatta way of doing it quite natural. > > Does anyone have any objections against it? > How does Vyatta does this? Can you give me a point to the Docs? http://www.vyatta.com/twiki/bin/view/Community/VlanConfiguration Kristian. From robert at vyatta.com Wed May 10 16:31:13 2006 From: robert at vyatta.com (Robert Bays) Date: Wed, 10 May 2006 16:31:13 -0700 Subject: [Xorp-hackers] VLANs In-Reply-To: <20060510211859.GC17949@spritelink.se> References: <20060504193523.GC8487@juniks.net> <200605090758.k497wKZI073743@possum.icir.org> <20060509153406.GD6943@spritelink.se> <44613686.9010602@vyatta.com> <44622CBE.4010502@vyatta.com> <20060510211859.GC17949@spritelink.se> Message-ID: <446277C1.8000707@vyatta.com> Hi Kristian, We might have to agree to disagree on this one. ;) Kristian Larsson wrote: > I tend not to agree. It's not that many extra > lines of code. Most things are done by the actual > operating system anyway, you just call a few > controls. > I suspect it's a bit easier handling error cases > when doing it via ioctl(or the alike) instead of > calling ifconfig. As I said before, vlans might be a marginal example. Serial interfaces with proprietary drivers are the best example of where a pure layer 2 integration mechanism breaks down. And I would suggest that creating network devices is the real root of this discussion. > No.... If we just stick to the layer 3 > characteristics no one will use XORP. I don't want > to use ifconfig to setup interfaces and then xorp > to do the routing. I want a more or less complete > routing system with all there is to it. > XORP must be able to handle more than just > routing. Just because XORP doesn't support the implementation of vlans in c code doesn't mean the project can't support it on the whole. In the Vyatta image if you create a vlan in xorpsh the device is still created on the system, sans ifconfig. Once system tools define the device through the program call, rtrmgr configures it. The same thing could be done in BSD using the method I previously outlined. And I believe you would have a faster delivery of a cross platform compatible solution (Linux/BSD anyway) than if you waited for a "true" VLAN integration into the fea. Relying on external tools to create devices is status quo for XORP, vlans being just one example. XORP's view of the world is through devices created outside its scope of execution; rc scripts, user run ifconfig, module loading, etc... Allowing XORP to trigger those creation mechanisms is, IMHO, a "good thing" as it will allow you to type "create interface eth0 vif 106" or "create interface s0 pvc 134" from xorpsh and have the system respond appropriately. I'm not sure that the latter example would ever be possible if driven by the fea. Furthermore, I'm not sure it's realistic to expect XORP to know how to create the multitude of devices on BSD, Linux, and Windows. So in the end all I am advocating is support of that mechanism since some interfaces are unlikely to ever be integrated into the fea. Fortunately, to a large extent this already exists. It just needs some execution sequencing guarantees. Just my 2 cents. Cheers, Robert. From deathdealer at gmx.net Wed May 10 23:32:05 2006 From: deathdealer at gmx.net (Patrick Marc Preuss) Date: Thu, 11 May 2006 08:32:05 +0200 Subject: [Xorp-hackers] VLANs In-Reply-To: <20060510212248.GD17949@spritelink.se> References: <20060509130242.GB6943@spritelink.se> <200605091832.k49IWllj082197@possum.icir.org> <20060510090420.GA17949@spritelink.se> <446217D6.2040700@gmx.net> <20060510212248.GD17949@spritelink.se> Message-ID: <4462DA65.5020208@gmx.net> Hello Kristian, Kristian Larsson said the following on 5/10/2006 11:22 PM: > I don't think the xorp project should spend it's > time writing a vrrp or glbp daemon but rather if > it's already out there we could integrate it so > that it can be configured via xorp. > may or may not from my point of view it should be realy intergrated because you may configure the rounting on the virual ip addresses and so the routing process need knowledge if we have the ip address yet. maybe somewehre in the future ;-) > >> Can we make a feature list site where we can see what is planed or >> requested may be we can vote for features. >> > http://www.xorp.org/bugzilla/index.cgi > > I think bugzilla is in someway inefficent for this because you need to go throuh the whole to find the features planed you does not become an idea in which release we plan to have this you have to sort out bugs and not aproved feature requests >> Have anyone seen an article or an implementation for WAN / Application >> optimisation, like the Boxes from Peribit/Juniper. What does you think >> about such things? >> > It's a bit too far in the future for me. First get > stable basic routing things like interface > configuration and properly working routing > protocols with policys. > yes, you are right the basics must be running, but my primary question was have anybody seen somthing in this direction yet. maybe only an abstract or so. >>> Keeping it compatible with Linux and *BSD is >>> probably something quite trivial but with Windows or >>> something else I can imagine it's a whole >>> different story. >>> >>> What I want is to start off somewhere. Right now, >>> this seems like some holy grail that noone dare >>> touch. By implementing most of the Vyatta work, >>> ofcourse with some exceptions, I think we would >>> have a good starting point. >>> >> YES >> >>> The vif syntax would probably have to change, I >>> find the Vyatta way of doing it quite natural. >>> Does anyone have any objections against it? >>> >> How does Vyatta does this? Can you give me a point to the Docs? >> > http://www.vyatta.com/twiki/bin/view/Community/VlanConfiguration > > Thanks > Kristian. > > > Patrick From chuanhuang_li at pop.zjgsu.edu.cn Tue May 23 07:24:24 2006 From: chuanhuang_li at pop.zjgsu.edu.cn (Li Chuanhuang) Date: Tue, 23 May 2006 22:24:24 +0800 Subject: [Xorp-hackers] comm_sock_open error! Message-ID: Hi, I'm a new user of XORP.I have compiled XORP in my Linux machine(kernel:2.4.20),it seems no problem,but when I run it with my config file,There are some fatal errors!! I attach the config.boot and the error message: My config: interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "ethernet interface" disable: false default-system-config } } fea { unicast-forwarding4 { disable: false } } protocols { ospf4 { router-id: 10.10.10.1 area 0.0.0.0 { interface eth0 { } } } } error message: [ 2006/05/23 22:17:46 INFO xorp_rtrmgr:4966 RTRMGR +240 master_conf_tree.cc exe cute ] Changed modules: interfaces, fea, rib, policy, ospf4 [ 2006/05/23 22:17:46 INFO xorp_rtrmgr:4966 RTRMGR +99 module_manager.cc execut e ] Executing module: interfaces (fea/xorp_fea) [ 2006/05/23 22:17:46 ERROR xorp_fea:4967 LIBCOMM +110 comm_sock.c comm_sock_op en ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol [ 2006/05/23 22:17:46 ERROR xorp_fea:4967 LIBCOMM +110 comm_sock.c comm_sock_op en ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol why the "domain" was setted to "10"(AF_CCITT)!? Is there somewhere I haven't configured? can you give me some suggestions? Thanks and best regards! ????????Robin ????????chuanhuang_li at pop.zjgsu.edu.cn ??????????05-23-2006 From mhorn at vyatta.com Tue May 23 08:04:25 2006 From: mhorn at vyatta.com (Mike Horn) Date: Tue, 23 May 2006 09:04:25 -0600 Subject: [Xorp-hackers] comm_sock_open error! In-Reply-To: Message-ID: <04e101c67e7a$30754720$6502a8c0@caddisconsulting.com> Hi Robin, You are missing two small pieces in your configuration. You need to add a vif and an IP address for eth0 (XORP does not support IP unnumbered today) and you need to add the same vif and IP address under the the "interface" statement in the OSPF area you need to add the IP address on the interface. So your config should look more like: interfaces { interface eth0 { vif eth0 { address 10.0.0.45 { prefix-length: 24 } } } } protocols { ospf4 { router-id: 10.0.0.45 area 0.0.0.0 { interface eth0 { vif eth0 { address 10.0.0.45 { } } } } } } Let us know if that doesn't resolve the socket error. -mike -----Original Message----- From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Li Chuanhuang Sent: Tuesday, May 23, 2006 8:24 AM To: xorp-hackers Subject: [Xorp-hackers] comm_sock_open error! Hi, I'm a new user of XORP.I have compiled XORP in my Linux machine(kernel:2.4.20),it seems no problem,but when I run it with my config file,There are some fatal errors!! I attach the config.boot and the error message: My config: interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "ethernet interface" disable: false default-system-config } } fea { unicast-forwarding4 { disable: false } } protocols { ospf4 { router-id: 10.10.10.1 area 0.0.0.0 { interface eth0 { } } } } error message: [ 2006/05/23 22:17:46 INFO xorp_rtrmgr:4966 RTRMGR +240 master_conf_tree.cc exe cute ] Changed modules: interfaces, fea, rib, policy, ospf4 [ 2006/05/23 22:17:46 INFO xorp_rtrmgr:4966 RTRMGR +99 module_manager.cc execut e ] Executing module: interfaces (fea/xorp_fea) [ 2006/05/23 22:17:46 ERROR xorp_fea:4967 LIBCOMM +110 comm_sock.c comm_sock_op en ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol [ 2006/05/23 22:17:46 ERROR xorp_fea:4967 LIBCOMM +110 comm_sock.c comm_sock_op en ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol why the "domain" was setted to "10"(AF_CCITT)!? Is there somewhere I haven't configured? can you give me some suggestions? Thanks and best regards! ????????Robin ????????chuanhuang_li at pop.zjgsu.edu.cn ??????????05-23-2006 _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From mike at vyatta.com Tue May 23 10:01:19 2006 From: mike at vyatta.com (Michael Larson) Date: Tue, 23 May 2006 10:01:19 -0700 (PDT) Subject: [Xorp-hackers] fix for bug 621 Message-ID: <25686208.01148403679539.JavaMail.root@mail.vyatta.com> Here's a fix for this bug--it fixes the problem downstream, but this should probably be fixed "upstream" if possible. Diff below Mike Larson Vyatta --- cli_client.cc_old 2006-05-22 18:14:43.000000000 +0000 +++ cli_client.cc_new 2006-05-22 18:14:50.000000000 +0000 @@ -1692,6 +1692,7 @@ CliCommand *tmp_cli_command = *iter; if (! tmp_cli_command->has_cli_completion_func()) continue; + if (tmp_cli_command->_cli_completion_func(tmp_cli_command, cpl, NULL, line, word_end, cli_command_match_list)) { @@ -1708,21 +1709,27 @@ ret_value = 0; } } - + // // Separate the type-match commands from the rest // + set no_type_coll; for (iter = cli_command_match_list.begin(); iter != cli_command_match_list.end(); ++iter) { CliCommand *tmp_cli_command = *iter; + if (tmp_cli_command->has_type_match_cb()) type_list.push_back(tmp_cli_command); - else - no_type_list.push_back(tmp_cli_command); + else { + no_type_coll.insert(tmp_cli_command->_name); + } } - if (no_type_list.size() > 1) { + + + + if (no_type_coll.size() > 1) { // Prepare and print the initial message(s) string token_line = string(line, word_end); string token; From pavlin at icir.org Tue May 23 23:18:59 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 23 May 2006 23:18:59 -0700 Subject: [Xorp-hackers] fix for bug 621 In-Reply-To: Message from Michael Larson of "Tue, 23 May 2006 10:01:19 PDT." <25686208.01148403679539.JavaMail.root@mail.vyatta.com> Message-ID: <200605240618.k4O6IxD4003866@possum.icir.org> > Here's a fix for this bug--it fixes the problem downstream, but > this should probably be fixed "upstream" if possible. Diff below Thanks! Fix applied to CVS: 1.56 +7 -6; commitid: 5e714473f9cd7ea6; xorp/cli/cli_client.cc BTW, your patch seems the right place to fix the problem, so I didn't understand your comment regarding fixing it "upstream". Pavlin > > Mike Larson > Vyatta > > > --- cli_client.cc_old 2006-05-22 18:14:43.000000000 +0000 > +++ cli_client.cc_new 2006-05-22 18:14:50.000000000 +0000 > @@ -1692,6 +1692,7 @@ > CliCommand *tmp_cli_command = *iter; > if (! tmp_cli_command->has_cli_completion_func()) > continue; > + > if (tmp_cli_command->_cli_completion_func(tmp_cli_command, > cpl, NULL, line, word_end, > cli_command_match_list)) { > @@ -1708,21 +1709,27 @@ > ret_value = 0; > } > } > - > + > // > // Separate the type-match commands from the rest > // > + set no_type_coll; > for (iter = cli_command_match_list.begin(); > iter != cli_command_match_list.end(); > ++iter) { > CliCommand *tmp_cli_command = *iter; > + > if (tmp_cli_command->has_type_match_cb()) > type_list.push_back(tmp_cli_command); > - else > - no_type_list.push_back(tmp_cli_command); > + else { > + no_type_coll.insert(tmp_cli_command->_name); > + } > } > > - if (no_type_list.size() > 1) { > + > + > + > + if (no_type_coll.size() > 1) { > // Prepare and print the initial message(s) > string token_line = string(line, word_end); > string token; > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From mike at vyatta.com Tue May 30 17:14:37 2006 From: mike at vyatta.com (Michael Larson) Date: Tue, 30 May 2006 17:14:37 -0700 (PDT) Subject: [Xorp-hackers] transaction fix for nodes shared across modules Message-ID: <23860698.511149034477161.JavaMail.root@mail.vyatta.com> Hey all, I've attached a diff file that fixes a problem in the rtrmgr when more than one module is assigned (via modinfo) on a common node. Xorp only allows a single transaction to be assigned per module/node and therefore when more than one module is assigned transactions will be grouped once on the last loaded module. The fix is the assign actions to transactions based on the module and not on the module assigned to the node. This approach allows for multiple transactions to execute within the context of the same node (on different modules). The following files where changed: M master_template_tree_node.cc M module_command.cc M template_commands.cc M module_command.hh M template_commands.h The module assignment is stored per action and not per node in these changes. The majority of the changes are in passing the additional argument. Mike Larson vyatta -------------- next part -------------- A non-text attachment was scrubbed... Name: transact_fix Type: application/octet-stream Size: 11580 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20060530/e3ab634a/attachment.obj