From pavlin at icir.org Thu Jun 1 11:46:13 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 01 Jun 2006 11:46:13 -0700 Subject: [Xorp-hackers] transaction fix for nodes shared across modules In-Reply-To: Message from Michael Larson of "Tue, 30 May 2006 17:14:37 PDT." <23860698.511149034477161.JavaMail.root@mail.vyatta.com> Message-ID: <200606011846.k51IkD7l040750@possum.icir.org> > 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, Could you send a short sample template file with a brief description of how the semantics have changed, so it would be easier to understand the original issue. Thanks, Pavlin From mike at vyatta.com Thu Jun 1 12:34:01 2006 From: mike at vyatta.com (Michael Larson) Date: Thu, 1 Jun 2006 12:34:01 -0700 (PDT) Subject: [Xorp-hackers] transaction fix for nodes shared across modules Message-ID: <3038465.391149190441245.JavaMail.root@mail.vyatta.com> Pavlin, I've attached the two template files that we are using here that demonstrate the problem (and some additional information the problematic behavior). If a user creates an interface (with vrrp): >create interfaces ethernet eth0 vrrp virtual-address 1.1.1.1 So that that both the modules interfaces and rl_interfaces are created. Both these modules specify transactions, and within the context of the ethernet node the transactions look like: start_transaction (interfaces) restore-original-config-on-shutdown commit_transaction (interfaces) start_transaction (rl_interfaces) create_interface set_interface_enabled create_vif set_vif_enabled commit_transaction (rl_interfaces) The problem above is that the XRL's between the rl_interfaces transaction are meant to be sandwiched between the interfaces transaction--when executing the create_interfaces the rtrmgr generates an error stating the TID is incorrect. If the rl_module creation is moved to another (subnode for instance), then the interface transaction proceeds correctly. The problem is when there are multiple transactions (which are caused by having more than one module transaction on the same node) on the same node. Note that loading order of the template file alters this behavior (if rl_interfaces.tp were changed to a_interfaces.tp--the transaction structure above would be different). Mike ----- Original Message ----- From: Pavlin Radoslavov To: Michael Larson Cc: xorp-hackers at icir.org Sent: Thursday, June 1, 2006 11:46:13 AM GMT-0800 Subject: Re: [Xorp-hackers] transaction fix for nodes shared across modules > 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, Could you send a short sample template file with a brief description of how the semantics have changed, so it would be easier to understand the original issue. Thanks, Pavlin _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -------------- next part -------------- A non-text attachment was scrubbed... Name: interfaces.tp Type: application/octet-stream Size: 25574 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20060601/63904bd5/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: rl_interfaces.tp Type: application/octet-stream Size: 5062 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20060601/63904bd5/attachment-0003.obj From pavlin at icir.org Thu Jun 1 14:00:06 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 01 Jun 2006 14:00:06 -0700 Subject: [Xorp-hackers] transaction fix for nodes shared across modules In-Reply-To: Message from Michael Larson of "Thu, 01 Jun 2006 12:34:01 PDT." <3038465.391149190441245.JavaMail.root@mail.vyatta.com> Message-ID: <200606012100.k51L06V4042059@possum.icir.org> > If a user creates an interface (with vrrp): > > >create interfaces ethernet eth0 vrrp virtual-address 1.1.1.1 > > So that that both the modules interfaces and rl_interfaces are > created. Both these modules specify transactions, and within the > context of the ethernet node the transactions look like: > > start_transaction (interfaces) > restore-original-config-on-shutdown > commit_transaction (interfaces) > > start_transaction (rl_interfaces) > create_interface > set_interface_enabled > create_vif > set_vif_enabled > commit_transaction (rl_interfaces) With your modification, what is the ordering of the XRLs. Is it something like the following: ==== start_transaction (interfaces) restore-original-config-on-shutdown start_transaction (rl_interfaces) create_interface set_interface_enabled create_vif set_vif_enabled commit_transaction (rl_interfaces) commit_transaction (interfaces) ==== If the %modinfo definitions are nested, then I believe the start/commit transactions should also be nested. BTW, I believe originally the %modinfo definitions were not designed to be nested, so I am not surprised that the XRL order is not as expected. > The problem above is that the XRL's between the rl_interfaces > transaction are meant to be sandwiched between the interfaces > transaction--when executing the create_interfaces the rtrmgr > generates an error stating the TID is incorrect. > > > If the rl_module creation is moved to another (subnode for > instance), then the interface transaction proceeds correctly. Are you saying that if the %modinfo declaration for the nested rl_interfaces module is moved to one of the "ethernet" children nodes, then the start_transaction(rl_interfaces)/commit_transaction(rl_interfaces) is nested within start_transaction(interfaces)/commit_transaction(interfaces) even without your modification? > The problem is when there are multiple transactions (which are > caused by having more than one module transaction on the same > node) on the same node. Note that loading order of the template > file alters this behavior (if rl_interfaces.tp were changed to > a_interfaces.tp--the transaction structure above would be > different). I am confused here. Are you saying that if the template file ordering was changed, then the XRL ordering for the nested transaction would be different? Is this true with or without your modifications? In any case, can you list the result XRL order. Thanks, Pavlin From mike at vyatta.com Thu Jun 1 14:21:18 2006 From: mike at vyatta.com (Michael Larson) Date: Thu, 1 Jun 2006 14:21:18 -0700 (PDT) Subject: [Xorp-hackers] transaction fix for nodes shared across modules Message-ID: <32262106.451149196878757.JavaMail.root@mail.vyatta.com> Pavlin comments below: Mike ----- Original Message ----- From: Pavlin Radoslavov To: Michael Larson Cc: Pavlin Radoslavov , xorp-hackers at icir.org Sent: Thursday, June 1, 2006 2:00:06 PM GMT-0800 Subject: Re: [Xorp-hackers] transaction fix for nodes shared across modules > If a user creates an interface (with vrrp): > > >create interfaces ethernet eth0 vrrp virtual-address 1.1.1.1 > > So that that both the modules interfaces and rl_interfaces are > created. Both these modules specify transactions, and within the > context of the ethernet node the transactions look like: > > start_transaction (interfaces) > restore-original-config-on-shutdown > commit_transaction (interfaces) > > start_transaction (rl_interfaces) > create_interface > set_interface_enabled > create_vif > set_vif_enabled > commit_transaction (rl_interfaces) With your modification, what is the ordering of the XRLs. Is it something like the following: ==== start_transaction (interfaces) restore-original-config-on-shutdown start_transaction (rl_interfaces) create_interface set_interface_enabled create_vif set_vif_enabled commit_transaction (rl_interfaces) commit_transaction (interfaces) ==== ML> In debug print statements the transactions were not nested but sequential--with the interfaces transaction closing before the rl_interfaces transaction started. So more along the lines of the following: start_transaction (interfaces) restore-original-config-on-shutdown commit_transtion (interfaces) start_transaction (rl_interfaces) create_interface set_interface_enabled create_vif set_vif_enabled commit_transaction (rl_interfaces) If the %modinfo definitions are nested, then I believe the start/commit transactions should also be nested. BTW, I believe originally the %modinfo definitions were not designed to be nested, so I am not surprised that the XRL order is not as expected. > The problem above is that the XRL's between the rl_interfaces > transaction are meant to be sandwiched between the interfaces > transaction--when executing the create_interfaces the rtrmgr > generates an error stating the TID is incorrect. > > > If the rl_module creation is moved to another (subnode for > instance), then the interface transaction proceeds correctly. Are you saying that if the %modinfo declaration for the nested rl_interfaces module is moved to one of the "ethernet" children nodes, then the start_transaction(rl_interfaces)/commit_transaction(rl_interfaces) is nested within start_transaction(interfaces)/commit_transaction(interfaces) even without your modification? ML> I don't recall if the transactions were nested in this case, but the xrls for interfaces/ethernet will correctly sequenced between the interfaces start/commit transaction statements in this case. > The problem is when there are multiple transactions (which are > caused by having more than one module transaction on the same > node) on the same node. Note that loading order of the template > file alters this behavior (if rl_interfaces.tp were changed to > a_interfaces.tp--the transaction structure above would be > different). I am confused here. Are you saying that if the template file ordering was changed, then the XRL ordering for the nested transaction would be different? Is this true with or without your modifications? In any case, can you list the result XRL order. ML> A module owns a node within the context of XrlAction::_module_name--which is assigned by the node that this XRL resides in. The assignment occurs when template_tree_node is passed into the constructor of the Action() base class. The class TemplateTreeNode only has a single slot for TemplateTreeNode::_module_name. I believe that the variable TemplateTreeNode::_module_name is assigned on start of the rtrmgr and the _module_name is assigned by the last module to be declared within the context of the node. Transactions use XrlAction::_module_name to determine the owner/scope of the transaction. So if the order of the loading of the template files is changed and the definition of modules are overloaded at the same node then the behavior of the transactions could change. There might have left out a couple details as this is from memory--but should be close... Thanks, Pavlin From M.Handley at cs.ucl.ac.uk Thu Jun 1 14:33:12 2006 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Thu, 1 Jun 2006 22:33:12 +0100 Subject: [Xorp-hackers] transaction fix for nodes shared across modules In-Reply-To: <200606012100.k51L06V4042059@possum.icir.org> References: <3038465.391149190441245.JavaMail.root@mail.vyatta.com> <200606012100.k51L06V4042059@possum.icir.org> Message-ID: <84a612dd0606011433g3763d928o421ace5d30539a2b@mail.gmail.com> On 6/1/06, Pavlin Radoslavov wrote: > > If a user creates an interface (with vrrp): > > > > >create interfaces ethernet eth0 vrrp virtual-address 1.1.1.1 > > > > So that that both the modules interfaces and rl_interfaces are > > created. Both these modules specify transactions, and within the > > context of the ethernet node the transactions look like: > > > > start_transaction (interfaces) > > restore-original-config-on-shutdown > > commit_transaction (interfaces) > > > > start_transaction (rl_interfaces) > > create_interface > > set_interface_enabled > > create_vif > > set_vif_enabled > > commit_transaction (rl_interfaces) > > With your modification, what is the ordering of the XRLs. Is it > something like the following: > > ==== > start_transaction (interfaces) > restore-original-config-on-shutdown > > start_transaction (rl_interfaces) > create_interface > set_interface_enabled > create_vif > set_vif_enabled > commit_transaction (rl_interfaces) > > commit_transaction (interfaces) > ==== > > If the %modinfo definitions are nested, then I believe the > start/commit transactions should also be nested. This was not the design. The router manager will figure out the entire set of XRLs to call, then it will re-order them so that all the XRLs on one module are called before starting the XRLs on any other module. The order of modules is determined by the dependencies specified in the template files. If there are two modules and no direct or indirect dependency between them that determines their order, then the order of those two is arbitrary. I strongly believe that this is still the right solution - interleaving XRLs between two or more modules makes it pretty much impossible to reason about the dependencies, and makes it awfully hard to know what should be configured before what when two modules are changed together. Basically you can't end up with one module half-configured and have another module then try to be reconfigured and as a result talk to the first module and hit it in the half-configured state. You just don't want to go down that track - too many race conditions and too much non-determinism. - Mark From pavlin at icir.org Thu Jun 1 18:42:19 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 01 Jun 2006 18:42:19 -0700 Subject: [Xorp-hackers] transaction fix for nodes shared across modules In-Reply-To: Message from Michael Larson of "Thu, 01 Jun 2006 14:21:18 PDT." <32262106.451149196878757.JavaMail.root@mail.vyatta.com> Message-ID: <200606020142.k521gJO0044831@possum.icir.org> > > If a user creates an interface (with vrrp): > > > > >create interfaces ethernet eth0 vrrp virtual-address 1.1.1.1 > > > > So that that both the modules interfaces and rl_interfaces are > > created. Both these modules specify transactions, and within the > > context of the ethernet node the transactions look like: > > > > start_transaction (interfaces) > > restore-original-config-on-shutdown > > commit_transaction (interfaces) > > > > start_transaction (rl_interfaces) > > create_interface > > set_interface_enabled > > create_vif > > set_vif_enabled > > commit_transaction (rl_interfaces) > > With your modification, what is the ordering of the XRLs. Is it > something like the following: > > ==== > start_transaction (interfaces) > restore-original-config-on-shutdown > > start_transaction (rl_interfaces) > create_interface > set_interface_enabled > create_vif > set_vif_enabled > commit_transaction (rl_interfaces) > > commit_transaction (interfaces) > ==== > > ML> In debug print statements the transactions were not nested but sequential--with the interfaces transaction closing before the rl_interfaces transaction started. So more along the lines of the following: > > start_transaction (interfaces) > restore-original-config-on-shutdown > commit_transtion (interfaces) > > start_transaction (rl_interfaces) > create_interface > set_interface_enabled > create_vif > set_vif_enabled > commit_transaction (rl_interfaces) You confused me here. If this is the output after your modification, then what is the order before the modification. If the order doesn't change, then what kind of issue was fixed with your mod? After re-reading your earlier emails it looks to me that you want to have two actions that belong to the same template node, but each action belongs to a different module. This seems dangerous and may be a source of other issues in the fiture. I will reply in a separate email about the nesting of modules. Pavlin From pavlin at icir.org Thu Jun 1 18:54:49 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 01 Jun 2006 18:54:49 -0700 Subject: [Xorp-hackers] transaction fix for nodes shared across modules In-Reply-To: Message from "Mark Handley" of "Thu, 01 Jun 2006 22:33:12 BST." <84a612dd0606011433g3763d928o421ace5d30539a2b@mail.gmail.com> Message-ID: <200606020154.k521snhM044973@possum.icir.org> > > > If a user creates an interface (with vrrp): > > > > > > >create interfaces ethernet eth0 vrrp virtual-address 1.1.1.1 > > > > > > So that that both the modules interfaces and rl_interfaces are > > > created. Both these modules specify transactions, and within the > > > context of the ethernet node the transactions look like: > > > > > > start_transaction (interfaces) > > > restore-original-config-on-shutdown > > > commit_transaction (interfaces) > > > > > > start_transaction (rl_interfaces) > > > create_interface > > > set_interface_enabled > > > create_vif > > > set_vif_enabled > > > commit_transaction (rl_interfaces) > > > > With your modification, what is the ordering of the XRLs. Is it > > something like the following: > > > > ==== > > start_transaction (interfaces) > > restore-original-config-on-shutdown > > > > start_transaction (rl_interfaces) > > create_interface > > set_interface_enabled > > create_vif > > set_vif_enabled > > commit_transaction (rl_interfaces) > > > > commit_transaction (interfaces) > > ==== > > > > If the %modinfo definitions are nested, then I believe the > > start/commit transactions should also be nested. > > This was not the design. I understand. Mike was already using nested modules, and my reply was within the context of just getting the right order of the XRLs. > The router manager will figure out the entire set of XRLs to call, > then it will re-order them so that all the XRLs on one module are > called before starting the XRLs on any other module. The order of > modules is determined by the dependencies specified in the template > files. If there are two modules and no direct or indirect dependency > between them that determines their order, then the order of those two > is arbitrary. > > I strongly believe that this is still the right solution - > interleaving XRLs between two or more modules makes it pretty much > impossible to reason about the dependencies, and makes it awfully hard > to know what should be configured before what when two modules are > changed together. Basically you can't end up with one module > half-configured and have another module then try to be reconfigured > and as a result talk to the first module and hit it in the > half-configured state. You just don't want to go down that track - > too many race conditions and too much non-determinism. I think you are right. I forgot about the bigger issue of taking care of module dependencies. In fact, by looking into the sample template with the nested module, the nested module inside "interfaces" depends on "fea" and "static", so there is an interesting dependency graph already. Then, nested modules shouldn't be allowed, and the rtrmgr should explicitly check for that. Mike, it seems to me that you don't need to use nested modules for what you want to achieve. First, decide whether you really need to declare a new module (e.g., you might be able to achieve same thing with the right %create, %update, %activate, etc. actions). Only if you really need to declare a new module, then compose it such that it doesn't overlap with other modules, and then declare its dependencies as appropriate. Pavlin From mike at vyatta.com Thu Jun 1 20:46:19 2006 From: mike at vyatta.com (Michael Larson) Date: Thu, 1 Jun 2006 20:46:19 -0700 (PDT) Subject: [Xorp-hackers] transaction fix for nodes shared across modules Message-ID: <25725643.641149219979286.JavaMail.root@mail.vyatta.com> OK--That makes sense that defining multiple modules at the same node results in an undefined order of execution. But, I don't see how this is different than allowing XRL's on the same node that are owned by different modules. The order of execution of the XRL's are undefined as well. For instance: template file 1: foo { bar { //module defined here within file 1 zoo { %create: module_1_xrl_on_create } } } template file 2: foo { //module defined here within file 2 bar { zoo { %create: module_2_xrl_on_create } } } In the example above, which xrl should be executed first? I think the same question applies to modules declared on the same node. In regards to the original issue I have found it useful to define a module on the same node as a previously defined xorp module (in this instance)--the main benefit being seperation of the source code. Mike ----- Original Message ----- From: Pavlin Radoslavov To: Mark Handley Cc: Michael Larson , Pavlin Radoslavov , xorp-hackers at icir.org Sent: Thursday, June 1, 2006 6:54:49 PM GMT-0800 Subject: Re: [Xorp-hackers] transaction fix for nodes shared across modules > > > If a user creates an interface (with vrrp): > > > > > > >create interfaces ethernet eth0 vrrp virtual-address 1.1.1.1 > > > > > > So that that both the modules interfaces and rl_interfaces are > > > created. Both these modules specify transactions, and within the > > > context of the ethernet node the transactions look like: > > > > > > start_transaction (interfaces) > > > restore-original-config-on-shutdown > > > commit_transaction (interfaces) > > > > > > start_transaction (rl_interfaces) > > > create_interface > > > set_interface_enabled > > > create_vif > > > set_vif_enabled > > > commit_transaction (rl_interfaces) > > > > With your modification, what is the ordering of the XRLs. Is it > > something like the following: > > > > ==== > > start_transaction (interfaces) > > restore-original-config-on-shutdown > > > > start_transaction (rl_interfaces) > > create_interface > > set_interface_enabled > > create_vif > > set_vif_enabled > > commit_transaction (rl_interfaces) > > > > commit_transaction (interfaces) > > ==== > > > > If the %modinfo definitions are nested, then I believe the > > start/commit transactions should also be nested. > > This was not the design. I understand. Mike was already using nested modules, and my reply was within the context of just getting the right order of the XRLs. > The router manager will figure out the entire set of XRLs to call, > then it will re-order them so that all the XRLs on one module are > called before starting the XRLs on any other module. The order of > modules is determined by the dependencies specified in the template > files. If there are two modules and no direct or indirect dependency > between them that determines their order, then the order of those two > is arbitrary. > > I strongly believe that this is still the right solution - > interleaving XRLs between two or more modules makes it pretty much > impossible to reason about the dependencies, and makes it awfully hard > to know what should be configured before what when two modules are > changed together. Basically you can't end up with one module > half-configured and have another module then try to be reconfigured > and as a result talk to the first module and hit it in the > half-configured state. You just don't want to go down that track - > too many race conditions and too much non-determinism. I think you are right. I forgot about the bigger issue of taking care of module dependencies. In fact, by looking into the sample template with the nested module, the nested module inside "interfaces" depends on "fea" and "static", so there is an interesting dependency graph already. Then, nested modules shouldn't be allowed, and the rtrmgr should explicitly check for that. Mike, it seems to me that you don't need to use nested modules for what you want to achieve. First, decide whether you really need to declare a new module (e.g., you might be able to achieve same thing with the right %create, %update, %activate, etc. actions). Only if you really need to declare a new module, then compose it such that it doesn't overlap with other modules, and then declare its dependencies as appropriate. Pavlin _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at icir.org Thu Jun 1 21:45:08 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 01 Jun 2006 21:45:08 -0700 Subject: [Xorp-hackers] transaction fix for nodes shared across modules In-Reply-To: Message from Michael Larson of "Thu, 01 Jun 2006 20:46:19 PDT." <25725643.641149219979286.JavaMail.root@mail.vyatta.com> Message-ID: <200606020445.k524j8ac046208@possum.icir.org> > OK--That makes sense that defining multiple modules at the same > node results in an undefined order of execution. > > But, I don't see how this is different than allowing XRL's on the > same node that are owned by different modules. The order of We cannot have same node partially owned by different modules. In your example below you have done this by using nested modules. It doesn't matter whether whether the nested modules are defined in a single file or separate files. As Mark pointed earlier, nested modules are problematic for other reasons (module dependency, etc). Pavlin > execution of the XRL's are undefined as well. For instance: > > template file 1: > > foo { > bar { > //module defined here within file 1 > zoo { > %create: module_1_xrl_on_create > } > } > } > > template file 2: > > foo { > //module defined here within file 2 > bar { > zoo { > %create: module_2_xrl_on_create > } > } > } > > In the example above, which xrl should be executed first? I think > the same question applies to modules declared on the same node. > > In regards to the original issue I have found it useful to define > a module on the same node as a previously defined xorp module (in > this instance)--the main benefit being seperation of the source > code. > > Mike > > ----- Original Message ----- > From: Pavlin Radoslavov > To: Mark Handley > Cc: Michael Larson , Pavlin Radoslavov , xorp-hackers at icir.org > Sent: Thursday, June 1, 2006 6:54:49 PM GMT-0800 > Subject: Re: [Xorp-hackers] transaction fix for nodes shared across modules > > > > > If a user creates an interface (with vrrp): > > > > > > > > >create interfaces ethernet eth0 vrrp virtual-address 1.1.1.1 > > > > > > > > So that that both the modules interfaces and rl_interfaces are > > > > created. Both these modules specify transactions, and within the > > > > context of the ethernet node the transactions look like: > > > > > > > > start_transaction (interfaces) > > > > restore-original-config-on-shutdown > > > > commit_transaction (interfaces) > > > > > > > > start_transaction (rl_interfaces) > > > > create_interface > > > > set_interface_enabled > > > > create_vif > > > > set_vif_enabled > > > > commit_transaction (rl_interfaces) > > > > > > With your modification, what is the ordering of the XRLs. Is it > > > something like the following: > > > > > > ==== > > > start_transaction (interfaces) > > > restore-original-config-on-shutdown > > > > > > start_transaction (rl_interfaces) > > > create_interface > > > set_interface_enabled > > > create_vif > > > set_vif_enabled > > > commit_transaction (rl_interfaces) > > > > > > commit_transaction (interfaces) > > > ==== > > > > > > If the %modinfo definitions are nested, then I believe the > > > start/commit transactions should also be nested. From mike at vyatta.com Thu Jun 1 22:43:11 2006 From: mike at vyatta.com (Michael Larson) Date: Thu, 1 Jun 2006 22:43:11 -0700 (PDT) Subject: [Xorp-hackers] transaction fix for nodes shared across modules Message-ID: <28237304.701149226991529.JavaMail.root@mail.vyatta.com> OK, if I understand what you are saying is that the only way to extend functionality on xorp defined nodes is to modify/rewrite the xorp modules but you cannot add any additional modules to these nodes. Mike ----- Original Message ----- From: Pavlin Radoslavov To: Michael Larson Cc: xorp-hackers at icir.org, Pavlin Radoslavov , Mark Handley Sent: Thursday, June 1, 2006 9:45:08 PM GMT-0800 Subject: Re: [Xorp-hackers] transaction fix for nodes shared across modules > OK--That makes sense that defining multiple modules at the same > node results in an undefined order of execution. > > But, I don't see how this is different than allowing XRL's on the > same node that are owned by different modules. The order of We cannot have same node partially owned by different modules. In your example below you have done this by using nested modules. It doesn't matter whether whether the nested modules are defined in a single file or separate files. As Mark pointed earlier, nested modules are problematic for other reasons (module dependency, etc). Pavlin > execution of the XRL's are undefined as well. For instance: > > template file 1: > > foo { > bar { > //module defined here within file 1 > zoo { > %create: module_1_xrl_on_create > } > } > } > > template file 2: > > foo { > //module defined here within file 2 > bar { > zoo { > %create: module_2_xrl_on_create > } > } > } > > In the example above, which xrl should be executed first? I think > the same question applies to modules declared on the same node. > > In regards to the original issue I have found it useful to define > a module on the same node as a previously defined xorp module (in > this instance)--the main benefit being seperation of the source > code. > > Mike > > ----- Original Message ----- > From: Pavlin Radoslavov > To: Mark Handley > Cc: Michael Larson , Pavlin Radoslavov , xorp-hackers at icir.org > Sent: Thursday, June 1, 2006 6:54:49 PM GMT-0800 > Subject: Re: [Xorp-hackers] transaction fix for nodes shared across modules > > > > > If a user creates an interface (with vrrp): > > > > > > > > >create interfaces ethernet eth0 vrrp virtual-address 1.1.1.1 > > > > > > > > So that that both the modules interfaces and rl_interfaces are > > > > created. Both these modules specify transactions, and within the > > > > context of the ethernet node the transactions look like: > > > > > > > > start_transaction (interfaces) > > > > restore-original-config-on-shutdown > > > > commit_transaction (interfaces) > > > > > > > > start_transaction (rl_interfaces) > > > > create_interface > > > > set_interface_enabled > > > > create_vif > > > > set_vif_enabled > > > > commit_transaction (rl_interfaces) > > > > > > With your modification, what is the ordering of the XRLs. Is it > > > something like the following: > > > > > > ==== > > > start_transaction (interfaces) > > > restore-original-config-on-shutdown > > > > > > start_transaction (rl_interfaces) > > > create_interface > > > set_interface_enabled > > > create_vif > > > set_vif_enabled > > > commit_transaction (rl_interfaces) > > > > > > commit_transaction (interfaces) > > > ==== > > > > > > If the %modinfo definitions are nested, then I believe the > > > start/commit transactions should also be nested. _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at icir.org Thu Jun 1 23:00:18 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 01 Jun 2006 23:00:18 -0700 Subject: [Xorp-hackers] transaction fix for nodes shared across modules In-Reply-To: Message from Michael Larson of "Thu, 01 Jun 2006 22:43:11 PDT." <28237304.701149226991529.JavaMail.root@mail.vyatta.com> Message-ID: <200606020600.k5260Io4046956@possum.icir.org> > OK, if I understand what you are saying is that the only way to > extend functionality on xorp defined nodes is to modify/rewrite > the xorp modules but you cannot add any additional modules to > these nodes. Yes. Of course, you can define new modules that are not nested. Pavlin From love-centry at hotmail.com Fri Jun 2 01:58:17 2006 From: love-centry at hotmail.com (=?gb2312?B?sswgtrA=?=) Date: Fri, 02 Jun 2006 16:58:17 +0800 Subject: [Xorp-hackers] about add new process to xorp Message-ID: Hi xorp I'm newer to xorp and also newer to automake/autoconf. Now I want to add new function to xorp. from <> ,I've setup my interface file(ids.xif) in xrl/interfaces.In order to setup ids_xif.cc and ids_xif.hh by python, I must modify Makefile.am to add : noinst_LTLIBRARIES += libidsxif.la libtestxif_la_SOURCES = ids_xif.hh ids_xif.cc and then execute 'automake' in xorp's directory and then make. but xorp didn't build ids_xif.cc & ids_xif.hh. I'd know why??? further More when I create ids directory which store my ids stub file. How can i build makefile automatically??? _________________________________________________________________ ?????????????? MSN Messenger: http://messenger.msn.com/cn From kristian at spritelink.se Fri Jun 2 04:07:04 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Fri, 2 Jun 2006 13:07:04 +0200 Subject: [Xorp-hackers] State of OSPF Message-ID: <20060602110704.GF3242@spritelink.se> Hi I'm trying to get a XORP router communicating with a Cisco 2811. I've setup OSPF on both ends. The 2811 is already talking to a 7206 and a 3620 so no problems there. However the 2811 will not form an adjacency with the XORP machine. Something wrong with the hellos. Is OSPF supposed to work now? This is my first shot at OSPF with XORP.. only used BGP before. I will fill in a little more information as soon as I get to my office. Could post a few tcpdumps and so on. Regards, Kristian. From kristian at spritelink.se Fri Jun 2 04:15:12 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Fri, 2 Jun 2006 13:15:12 +0200 Subject: [Xorp-hackers] about add new process to xorp In-Reply-To: References: Message-ID: <20060602111511.GG3242@spritelink.se> On Fri, Jun 02, 2006 at 04:58:17PM +0800, ?? ?? wrote: > Hi xorp > I'm newer to xorp and also newer to automake/autoconf. Now I want to add > new function to xorp. from <> > ,I've setup my interface file(ids.xif) in xrl/interfaces.In order to setup > ids_xif.cc and ids_xif.hh by python, I must modify Makefile.am to add : > noinst_LTLIBRARIES += libidsxif.la > libtestxif_la_SOURCES = ids_xif.hh ids_xif.cc > and then execute 'automake' in xorp's directory and then make. but xorp > didn't build ids_xif.cc & ids_xif.hh. > I'd know why??? further More when I create ids directory which store my ids > stub file. How can i build makefile automatically??? I'm not really the guy to answer all these questions.. but have a look at the bootstrap file in the xorp root directory. I think it will help you build new makefiles and stuff :) Kristian. From mhorn at vyatta.com Fri Jun 2 06:04:09 2006 From: mhorn at vyatta.com (Mike Horn) Date: Fri, 2 Jun 2006 07:04:09 -0600 Subject: [Xorp-hackers] State of OSPF In-Reply-To: <20060602110704.GF3242@spritelink.se> Message-ID: <08fd01c68645$09e2c600$0f02a8c0@caddisconsulting.com> Hi Kristian, I have XORP running OSPF with 2 Cisco's (2600, 4500) and a Juniper (J2300) here, perhaps you could send out your config? The most common issue I have seen is that for OSPF to work properly XORP requires that you specify the IP addres of the interface that is running XORP. Here's an example: set protocols ospf4 router-id 10.0.0.50 set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.0.0.50 Hope that helps! -mike -----Original Message----- From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Kristian Larsson Sent: Friday, June 02, 2006 5:07 AM To: xorp-hackers at xorp.org Subject: [Xorp-hackers] State of OSPF Hi I'm trying to get a XORP router communicating with a Cisco 2811. I've setup OSPF on both ends. The 2811 is already talking to a 7206 and a 3620 so no problems there. However the 2811 will not form an adjacency with the XORP machine. Something wrong with the hellos. Is OSPF supposed to work now? This is my first shot at OSPF with XORP.. only used BGP before. I will fill in a little more information as soon as I get to my office. Could post a few tcpdumps and so on. Regards, Kristian. _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian at spritelink.se Fri Jun 2 06:52:35 2006 From: kristian at spritelink.se ('Kristian Larsson') Date: Fri, 2 Jun 2006 15:52:35 +0200 Subject: [Xorp-hackers] State of OSPF In-Reply-To: <08fd01c68645$09e2c600$0f02a8c0@caddisconsulting.com> References: <20060602110704.GF3242@spritelink.se> <08fd01c68645$09e2c600$0f02a8c0@caddisconsulting.com> Message-ID: <20060602135234.GH3242@spritelink.se> On Fri, Jun 02, 2006 at 07:04:09AM -0600, Mike Horn wrote: > Hi Kristian, > > I have XORP running OSPF with 2 Cisco's (2600, 4500) and a Juniper (J2300) > here, perhaps you could send out your config? The most common issue I have > seen is that for OSPF to work properly XORP requires that you specify the IP > addres of the interface that is running XORP. > > Here's an example: > > set protocols ospf4 router-id 10.0.0.50 > set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.0.0.50 My configuration: root at crs1# show protocols { ospf4 { router-id: 195.182.5.227 area 0.0.0.0 { interface "eth1.3910" { vif "eth1.3910" { address 195.182.5.227 { } } } } } } interfaces { interface "eth1.3910" { vif "eth1.3910" { address 195.182.5.227 { prefix-length: 28 } } } } cisco conf (relevant sections): interface FastEthernet0/1.3910 description AS39525 CNV Linknet encapsulation dot1Q 3910 ip address 195.182.5.225 255.255.255.248 ip pim sparse-dense-mode no cdp enable router ospf 39525 router-id 195.182.5.252 log-adjacency-changes redistribute connected subnets passive-interface default no passive-interface FastEthernet0/1.3909 no passive-interface FastEthernet0/1.3910 no passive-interface Tunnel10 no passive-interface Tunnel11 no passive-interface Tunnel12 network 195.182.5.0 0.0.0.255 area 0 neighbor 195.182.5.116 priority 1 default-information originate root at crs1# run show ospf4 neighbor Address Interface State ID Pri Dead root at crs1# show ip ospf neighbor on the cisco does not show it as a neighbor either. running tcpdump on the xorp machine I see: 14:54:23.569081 IP 195.182.5.225 > 224.0.0.5: OSPFv2, Hello (1), length: 60 14:54:28.732384 IP 195.182.5.227 > 224.0.0.5: OSPFv2, Hello (1), length: 44 so both are sending packets.. hmm, how about some debugging!? terminal monitor; debug ip ospf hello (on the cisco) gives me: *Jun 2 13:52:20.460: OSPF: Rcv hello from 195.182.5.227 area 0 from FastEthernet0/1.3910 195.182.5.227 *Jun 2 13:52:20.460: OSPF: Mismatched hello parameters from 195.182.5.227 I've captured a small tcpdump that you may look at... it contains some other traffic as well, but the ospf traffic is not very hard to spot ;) XORP is not latest (but not very old) CVS. I'd say it's from a month ago or so. The XORP machine is a Celeron 2.66GHz machine with dual Broadcom Tigon3 Gigabit Ethernet controllers. XORP was not built on that machine but on another Celeron machine. No strange config paramters to ./configure, just a straight build. Hope I've given enough debug data. Regards, Kristian. -------------- next part -------------- A non-text attachment was scrubbed... Name: debug Type: application/octet-stream Size: 10475 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20060602/36611f64/attachment-0001.obj From mhorn at vyatta.com Fri Jun 2 07:30:58 2006 From: mhorn at vyatta.com (Mike Horn) Date: Fri, 2 Jun 2006 08:30:58 -0600 Subject: [Xorp-hackers] State of OSPF In-Reply-To: <20060602135234.GH3242@spritelink.se> Message-ID: <092801c68651$2a6bf930$0f02a8c0@caddisconsulting.com> Hi Kristian, The key is from the Cisco debug message, "OSPF: Mismatched hello parameters from 195.182.5.227". So there is an OSPF setting(s) the 2 routers are not agreeing upon. Based on your configs, I think the issue is that you have the XORP ethernet interface configured as a /28 and the Cisco interface is a /29. Try changing those to match and let me know if that fixes the issue. -mike -----Original Message----- From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of 'Kristian Larsson' Sent: Friday, June 02, 2006 7:53 AM To: Mike Horn Cc: xorp-hackers at xorp.org Subject: Re: [Xorp-hackers] State of OSPF On Fri, Jun 02, 2006 at 07:04:09AM -0600, Mike Horn wrote: > Hi Kristian, > > I have XORP running OSPF with 2 Cisco's (2600, 4500) and a Juniper > (J2300) here, perhaps you could send out your config? The most common > issue I have seen is that for OSPF to work properly XORP requires that > you specify the IP addres of the interface that is running XORP. > > Here's an example: > > set protocols ospf4 router-id 10.0.0.50 set protocols ospf4 area > 0.0.0.0 interface eth0 vif eth0 address 10.0.0.50 My configuration: root at crs1# show protocols { ospf4 { router-id: 195.182.5.227 area 0.0.0.0 { interface "eth1.3910" { vif "eth1.3910" { address 195.182.5.227 { } } } } } } interfaces { interface "eth1.3910" { vif "eth1.3910" { address 195.182.5.227 { prefix-length: 28 } } } } cisco conf (relevant sections): interface FastEthernet0/1.3910 description AS39525 CNV Linknet encapsulation dot1Q 3910 ip address 195.182.5.225 255.255.255.248 ip pim sparse-dense-mode no cdp enable router ospf 39525 router-id 195.182.5.252 log-adjacency-changes redistribute connected subnets passive-interface default no passive-interface FastEthernet0/1.3909 no passive-interface FastEthernet0/1.3910 no passive-interface Tunnel10 no passive-interface Tunnel11 no passive-interface Tunnel12 network 195.182.5.0 0.0.0.255 area 0 neighbor 195.182.5.116 priority 1 default-information originate root at crs1# run show ospf4 neighbor Address Interface State ID Pri Dead root at crs1# show ip ospf neighbor on the cisco does not show it as a neighbor either. running tcpdump on the xorp machine I see: 14:54:23.569081 IP 195.182.5.225 > 224.0.0.5: OSPFv2, Hello (1), length: 60 14:54:28.732384 IP 195.182.5.227 > 224.0.0.5: OSPFv2, Hello (1), length: 44 so both are sending packets.. hmm, how about some debugging!? terminal monitor; debug ip ospf hello (on the cisco) gives me: *Jun 2 13:52:20.460: OSPF: Rcv hello from 195.182.5.227 area 0 from FastEthernet0/1.3910 195.182.5.227 *Jun 2 13:52:20.460: OSPF: Mismatched hello parameters from 195.182.5.227 I've captured a small tcpdump that you may look at... it contains some other traffic as well, but the ospf traffic is not very hard to spot ;) XORP is not latest (but not very old) CVS. I'd say it's from a month ago or so. The XORP machine is a Celeron 2.66GHz machine with dual Broadcom Tigon3 Gigabit Ethernet controllers. XORP was not built on that machine but on another Celeron machine. No strange config paramters to ./configure, just a straight build. Hope I've given enough debug data. Regards, Kristian. From pavlin at icir.org Fri Jun 2 08:42:26 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 02 Jun 2006 08:42:26 -0700 Subject: [Xorp-hackers] about add new process to xorp In-Reply-To: Message from Kristian Larsson of "Fri, 02 Jun 2006 13:15:12 +0200." <20060602111511.GG3242@spritelink.se> Message-ID: <200606021542.k52FgQse053250@possum.icir.org> Kristian Larsson wrote: > On Fri, Jun 02, 2006 at 04:58:17PM +0800, ?? ?? wrote: > > Hi xorp > > I'm newer to xorp and also newer to automake/autoconf. Now I want to add > > new function to xorp. from <> > > ,I've setup my interface file(ids.xif) in xrl/interfaces.In order to setup > > ids_xif.cc and ids_xif.hh by python, I must modify Makefile.am to add : > > noinst_LTLIBRARIES += libidsxif.la > > libtestxif_la_SOURCES = ids_xif.hh ids_xif.cc > > and then execute 'automake' in xorp's directory and then make. but xorp > > didn't build ids_xif.cc & ids_xif.hh. > > I'd know why??? further More when I create ids directory which store my ids > > stub file. How can i build makefile automatically??? > I'm not really the guy to answer all these > questions.. but have a look at the bootstrap file > in the xorp root directory. I think it will help > you build new makefiles and stuff :) Yes, after a Makefile.am is modified, you must run the top-level ./bootstrap to generate the new Makefile.in file(s). Note that your autoconf/automake/libtool versions must match the versions specified in the top-level README file. Currently, those versions are: - autoconf version 2.53 - automake version 1.5 - libtool version 1.3.4 After that you must run ./configure to generate the new Makefile file(s). Finally, you must run gmake, and the ids_xif.hh and ids_xif.cc files will generated. FYI, for testing purpose you could generate those auto-generated files by hand: cd xrl/interfaces python ../scripts/clnt-gen ids.xif Pavlin From pavlin at icir.org Fri Jun 2 09:27:59 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 02 Jun 2006 09:27:59 -0700 Subject: [Xorp-hackers] about add new process to xorp In-Reply-To: Message from Pavlin Radoslavov of "Fri, 02 Jun 2006 08:42:26 PDT." <200606021542.k52FgQse053250@possum.icir.org> Message-ID: <200606021627.k52GRxnV073108@possum.icir.org> Pavlin Radoslavov wrote: > Kristian Larsson wrote: > > > On Fri, Jun 02, 2006 at 04:58:17PM +0800, ?? ?? wrote: > > > Hi xorp > > > I'm newer to xorp and also newer to automake/autoconf. Now I want to add > > > new function to xorp. from <> > > > ,I've setup my interface file(ids.xif) in xrl/interfaces.In order to setup > > > ids_xif.cc and ids_xif.hh by python, I must modify Makefile.am to add : > > > noinst_LTLIBRARIES += libidsxif.la > > > libtestxif_la_SOURCES = ids_xif.hh ids_xif.cc > > > and then execute 'automake' in xorp's directory and then make. but xorp > > > didn't build ids_xif.cc & ids_xif.hh. > > > I'd know why??? further More when I create ids directory which store my ids > > > stub file. How can i build makefile automatically??? > > I'm not really the guy to answer all these > > questions.. but have a look at the bootstrap file > > in the xorp root directory. I think it will help > > you build new makefiles and stuff :) > > Yes, after a Makefile.am is modified, you must run the top-level > ./bootstrap to generate the new Makefile.in file(s). Note that your > autoconf/automake/libtool versions must match the versions specified > in the top-level README file. Currently, those versions are: > - autoconf version 2.53 > - automake version 1.5 > - libtool version 1.3.4 > > After that you must run ./configure to generate the new Makefile > file(s). > Finally, you must run gmake, and the ids_xif.hh and ids_xif.cc files > will generated. Forgot to mention that you need to run ./bootstrap and ./configure only once (after you modify the Makefile.am). After that, if you make any changes to your ids.xif file, the "gmake" will take care of auto-generating the ids_xif.hh and ids_xif.cc files. Pavlin > FYI, for testing purpose you could generate those auto-generated > files by hand: > > cd xrl/interfaces > python ../scripts/clnt-gen ids.xif > > Pavlin > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian at spritelink.se Fri Jun 2 09:26:21 2006 From: kristian at spritelink.se ('Kristian Larsson') Date: Fri, 2 Jun 2006 18:26:21 +0200 Subject: [Xorp-hackers] State of OSPF In-Reply-To: <092801c68651$2a6bf930$0f02a8c0@caddisconsulting.com> References: <20060602135234.GH3242@spritelink.se> <092801c68651$2a6bf930$0f02a8c0@caddisconsulting.com> Message-ID: <20060602162621.GI3242@spritelink.se> On Fri, Jun 02, 2006 at 08:30:58AM -0600, Mike Horn wrote: > Hi Kristian, > > The key is from the Cisco debug message, "OSPF: Mismatched hello parameters > from 195.182.5.227". So there is an OSPF setting(s) the 2 routers are not > agreeing upon. > > Based on your configs, I think the issue is that you have the XORP ethernet > interface configured as a /28 and the Cisco interface is a /29. Try > changing those to match and let me know if that fixes the issue. what a typo! I've probably done the same typo for a month now ;) anyway, I've now changed and the problem seem to persist... and I've also spotted this line in my cisco: *Jun 2 16:30:10.487: OSPF: Dead R 40 C 40, Hello R 10 C 10 Mask R 255.255.255.240 C 255.255.255.248 which seems to indicate the differences.. ie, one would seem to be that XORP OSPF hasn't actually changed the subnet size but keeps sending the old one.. I'll report this as a bug. so.. I delete the interface address under ospf4 and then add it again and voila. working! Thanks for you help Mike Kristian. > > -mike > > > -----Original Message----- > From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] > On Behalf Of 'Kristian Larsson' > Sent: Friday, June 02, 2006 7:53 AM > To: Mike Horn > Cc: xorp-hackers at xorp.org > Subject: Re: [Xorp-hackers] State of OSPF > > On Fri, Jun 02, 2006 at 07:04:09AM -0600, Mike Horn wrote: > > Hi Kristian, > > > > I have XORP running OSPF with 2 Cisco's (2600, 4500) and a Juniper > > (J2300) here, perhaps you could send out your config? The most common > > issue I have seen is that for OSPF to work properly XORP requires that > > you specify the IP addres of the interface that is running XORP. > > > > Here's an example: > > > > set protocols ospf4 router-id 10.0.0.50 set protocols ospf4 area > > 0.0.0.0 interface eth0 vif eth0 address 10.0.0.50 > My configuration: > root at crs1# show > protocols { > ospf4 { > router-id: 195.182.5.227 > area 0.0.0.0 { > interface "eth1.3910" { > vif "eth1.3910" { > address 195.182.5.227 { > } > } > } > } > } > } > interfaces { > interface "eth1.3910" { > vif "eth1.3910" { > address 195.182.5.227 { > prefix-length: 28 > } > } > } > } > > > > cisco conf (relevant sections): > interface FastEthernet0/1.3910 > description AS39525 CNV Linknet > encapsulation dot1Q 3910 > ip address 195.182.5.225 255.255.255.248 ip pim sparse-dense-mode no cdp > enable > > router ospf 39525 > router-id 195.182.5.252 > log-adjacency-changes > redistribute connected subnets > passive-interface default > no passive-interface FastEthernet0/1.3909 no passive-interface > FastEthernet0/1.3910 no passive-interface Tunnel10 no passive-interface > Tunnel11 no passive-interface Tunnel12 network 195.182.5.0 0.0.0.255 area > 0 neighbor 195.182.5.116 priority 1 default-information originate > > > root at crs1# run show ospf4 neighbor > Address Interface State ID Pri Dead > root at crs1# > > show ip ospf neighbor on the cisco does not show it as a neighbor either. > > running tcpdump on the xorp machine I see: > 14:54:23.569081 IP 195.182.5.225 > 224.0.0.5: OSPFv2, Hello (1), length: 60 > 14:54:28.732384 IP 195.182.5.227 > 224.0.0.5: OSPFv2, Hello (1), length: 44 > > so both are sending packets.. hmm, how about some debugging!? > terminal monitor; debug ip ospf hello (on the cisco) gives me: > *Jun 2 13:52:20.460: OSPF: Rcv hello from 195.182.5.227 area 0 from > FastEthernet0/1.3910 195.182.5.227 *Jun 2 13:52:20.460: OSPF: Mismatched > hello parameters from 195.182.5.227 > > > I've captured a small tcpdump that you may look at... it contains some other > traffic as well, but the ospf traffic is not very hard to spot ;) > > XORP is not latest (but not very old) CVS. I'd say it's from a month ago or > so. > The XORP machine is a Celeron 2.66GHz machine with dual Broadcom Tigon3 > Gigabit Ethernet controllers. > XORP was not built on that machine but on another Celeron machine. > No strange config paramters to ./configure, just a straight build. > > Hope I've given enough debug data. > > Regards, > Kristian. > > From mhorn at vyatta.com Fri Jun 2 09:44:31 2006 From: mhorn at vyatta.com (Mike Horn) Date: Fri, 2 Jun 2006 10:44:31 -0600 Subject: [Xorp-hackers] State of OSPF In-Reply-To: <20060602162621.GI3242@spritelink.se> Message-ID: <096a01c68663$d2d24e00$0f02a8c0@caddisconsulting.com> Hi Kristian, Glad to hear it is working, yes please do report the subnet not dynamically changing as a bug. Btw, I have seen this with other parameters as well, here are a few open XORP bugs you might want to keep an eye out for: 405 484 492 496 589 590 618 In addition to the bugs above, I have submitted a few OSPF related crashes that I haven't been able to reproduce consistently, so if you could keep an eye out for crashes during your OSPF testing I would really appreciate it. -mike -----Original Message----- From: 'Kristian Larsson' [mailto:kristian at spritelink.se] Sent: Friday, June 02, 2006 10:26 AM To: Mike Horn Cc: xorp-hackers at xorp.org Subject: Re: [Xorp-hackers] State of OSPF On Fri, Jun 02, 2006 at 08:30:58AM -0600, Mike Horn wrote: > Hi Kristian, > > The key is from the Cisco debug message, "OSPF: Mismatched hello > parameters from 195.182.5.227". So there is an OSPF setting(s) the 2 > routers are not agreeing upon. > > Based on your configs, I think the issue is that you have the XORP > ethernet interface configured as a /28 and the Cisco interface is a > /29. Try changing those to match and let me know if that fixes the issue. what a typo! I've probably done the same typo for a month now ;) anyway, I've now changed and the problem seem to persist... and I've also spotted this line in my cisco: *Jun 2 16:30:10.487: OSPF: Dead R 40 C 40, Hello R 10 C 10 Mask R 255.255.255.240 C 255.255.255.248 which seems to indicate the differences.. ie, one would seem to be that XORP OSPF hasn't actually changed the subnet size but keeps sending the old one.. I'll report this as a bug. so.. I delete the interface address under ospf4 and then add it again and voila. working! Thanks for you help Mike Kristian. > > -mike > > > -----Original Message----- > From: xorp-hackers-bounces at icir.org > [mailto:xorp-hackers-bounces at icir.org] > On Behalf Of 'Kristian Larsson' > Sent: Friday, June 02, 2006 7:53 AM > To: Mike Horn > Cc: xorp-hackers at xorp.org > Subject: Re: [Xorp-hackers] State of OSPF > > On Fri, Jun 02, 2006 at 07:04:09AM -0600, Mike Horn wrote: > > Hi Kristian, > > > > I have XORP running OSPF with 2 Cisco's (2600, 4500) and a Juniper > > (J2300) here, perhaps you could send out your config? The most > > common issue I have seen is that for OSPF to work properly XORP > > requires that you specify the IP addres of the interface that is running XORP. > > > > Here's an example: > > > > set protocols ospf4 router-id 10.0.0.50 set protocols ospf4 area > > 0.0.0.0 interface eth0 vif eth0 address 10.0.0.50 > My configuration: > root at crs1# show > protocols { > ospf4 { > router-id: 195.182.5.227 > area 0.0.0.0 { > interface "eth1.3910" { > vif "eth1.3910" { > address 195.182.5.227 { > } > } > } > } > } > } > interfaces { > interface "eth1.3910" { > vif "eth1.3910" { > address 195.182.5.227 { > prefix-length: 28 > } > } > } > } > > > > cisco conf (relevant sections): > interface FastEthernet0/1.3910 > description AS39525 CNV Linknet > encapsulation dot1Q 3910 > ip address 195.182.5.225 255.255.255.248 ip pim sparse-dense-mode > no cdp enable > > router ospf 39525 > router-id 195.182.5.252 > log-adjacency-changes > redistribute connected subnets > passive-interface default > no passive-interface FastEthernet0/1.3909 no passive-interface > FastEthernet0/1.3910 no passive-interface Tunnel10 no > passive-interface > Tunnel11 no passive-interface Tunnel12 network 195.182.5.0 0.0.0.255 > area 0 neighbor 195.182.5.116 priority 1 default-information > originate > > > root at crs1# run show ospf4 neighbor > Address Interface State ID Pri Dead > root at crs1# > > show ip ospf neighbor on the cisco does not show it as a neighbor either. > > running tcpdump on the xorp machine I see: > 14:54:23.569081 IP 195.182.5.225 > 224.0.0.5: OSPFv2, Hello (1), > length: 60 > 14:54:28.732384 IP 195.182.5.227 > 224.0.0.5: OSPFv2, Hello (1), > length: 44 > > so both are sending packets.. hmm, how about some debugging!? > terminal monitor; debug ip ospf hello (on the cisco) gives me: > *Jun 2 13:52:20.460: OSPF: Rcv hello from 195.182.5.227 area 0 from > FastEthernet0/1.3910 195.182.5.227 *Jun 2 13:52:20.460: OSPF: > Mismatched hello parameters from 195.182.5.227 > > > I've captured a small tcpdump that you may look at... it contains some > other traffic as well, but the ospf traffic is not very hard to spot > ;) > > XORP is not latest (but not very old) CVS. I'd say it's from a month > ago or so. > The XORP machine is a Celeron 2.66GHz machine with dual Broadcom > Tigon3 Gigabit Ethernet controllers. > XORP was not built on that machine but on another Celeron machine. > No strange config paramters to ./configure, just a straight build. > > Hope I've given enough debug data. > > Regards, > Kristian. > > From benjamin at sonntag.fr Mon Jun 5 09:13:45 2006 From: benjamin at sonntag.fr (Benjamin Sonntag) Date: Mon, 05 Jun 2006 18:13:45 +0200 Subject: [Xorp-hackers] debian packaging of xorp 1.2 Message-ID: <44845839.5040908@sonntag.fr> Hi all, I just created a debian package for xorp-1.2 current. I did not test it yet on CVS but it should work fluently too. You can use the debian package just by adding the following to /etc/apt/sources.list deb http://benjamin.sonntag.fr/ sarge main you can download the package source at http://benjamin.sonntag.fr/dists/sarge/main/source/net/ The only difference with xorp 1.2 standard is the debian/ folder. If you want to add it to CVS, don't hesitate. Just one point : the debian/control file contains a quite sparse description of xorp and xorp-doc. You may make them better since you know your project very well ... Last point : we (Gitoyen-NCC, a small french operator based in Paris) are making some tests of xorp under debian and freebsd, and last quagga and openbgpd too. We will certainly tell you our conclusion. We want to be able to route more than 100Mbps on each link on our PC routers, and stay as free as possible. See you later, Regards, Benjamin Sonntag, From kristian at spritelink.se Thu Jun 8 02:45:02 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Thu, 8 Jun 2006 11:45:02 +0200 Subject: [Xorp-hackers] BGP show tools Message-ID: <20060608094502.GF21791@spritelink.se> I sent a mail some time ago about new format for the `show bgp *`commands.. I've thought of it a bit more and I would like to suggest the following me at mybox> show bgp peers ? Possible completions: <[Enter]> Execute this command Show BGP peers with Show BGP peer with me at mybox> show bgp peers Total Paths Active Paths Damped Paths Paths with Penalties 220568 183521 12 4 Peer ASN Flaps Time Accepted Filtered Sent Out 53.123.53.25 34853 0 0w,1d,03:45:23 Active (retry in 67s) 23 87.13.214.1 4834 0 0w,4d,06:23:57 Admin Down 123.123.123.123 12345 1028 100w,5d,12:23:54 183521 126051 183521 153921 217.10.127.17 39525 0 00:12:43 182145 0 23 0 217.10.127.19 39525 0 00:11:38 182145 0 23 0 2001:6E8:1:3:2:2:3:1 39525 214 12w,5d,12:44:22 182213 0 23 0 me at mybox> show bgp peers 39525 Peer ASN Flaps Time Accepted Filtered Sent Out 217.10.127.17 39525 0 00:12:43 182145 0 23 0 217.10.127.19 39525 0 00:11:38 182145 0 23 0 me at mybox> show bgp peers 123.123.123.123 Peer ASN Flaps Time Accepted Filtered Sent Out 123.123.123.123 12345 1028 0w,0d,0:0:43 *183521 12 8 15 The first field with the IP address of the neighbor can take the "longest" IPv4 addresses, ie one where all octets contain three digits. ASN (perhaps we should use 'AsNum' instead?) allow the full 2byte numbers we have today. Flaps is just the number of times the session has gone to established (as it is called now). Time is the time since the session went to its current state. The four last fields are accepted prefixes, filtered prefixes, sent prefixes and outgoing prefixes. When a session is in established state these are shown, if we're in another state the state is shown instead, just as in the above example. Accepted prefixes is pretty self explanatory.. it is the number of prefixes you have received and that has passed all route-maps and filters. Filtered are those that didn't quite make it due to some filter. Sent prefixes are the amount of prefixes that you have sent to a peer. Out is the amount of prefixes you intend to send to a peer. It's kind of dual-purpose.. you can see the equivalent of the Out queue on a Cisco, ie if there are any packets you need to send to keep your neighbor updated. And when the session isn't up yet you can still see how many prefixes your router intends to send. Great for a quick lock - "ah, my router intends to send 23 routes... that's just my customer and internal routes" so that you dont't accidentally send a full table to a peer or the alike. The asterisk (*) in the last example signifies that the router is working, ie the In queue is not empty. Having a separate field for InQ seems to overdo it, the asterisk is enough... Now some considerations.. what of IPv4 unicast, IPv4 multicast, IPv6 unicast and IPv6 multicast. Should everything be displayed under one "summary" display or should we have separate displays - compare to ciscos `show ip bgp ipv4 multicast summary`... What do we do with IPv6 adresses that are to long to fit (which should be most of them) or when 4 byte AS number are implemented (RIPE has a proposal so it's not that far in the future)?? Both these scenarios would mean longer lines than 80 chars. If xorpsh is aware of the term width it's not a problem. Ff the user uses a terminal wider than 80 chars we'll simply use the current width to fit as much information as possible. I think this is quite common today, but not common enough to completely scrap the 80wide limit and if someone would use say a 100 wide terminal that might still not be enough. So we need some rules for wrapping... too long IPv6 address, pretty easy case: We'll do it like this, just as in the above example 2001:6E8:1:3:2:2:3:1 39525 214 12w,5d,12:44:22 182213 0 23 0 Comments please. Then there are 4 bytes ASNs, even though I don't think there's actually any standard on this yet, there are some proposals http://www.ripe.net/ripe/policies/proposals/2005-12.html for one. It seems likely that the model in that url will be the one commonly accepted and so when redesigning these tools we might as well take that draft into consideration. When doing IPv4 and 4 bytes ASN longer than 6 digits I suggest the following: 123.123.123.123 65535.65535 214 12w,5d,12:44:22 182213 0 23 0 With both long IPv6 addresses and 4 bytes ASNs longer than 6 digits it becomes a bit trickier... I find the following the best utilization of space. 2000:2000:1234:DEAD:BEEF:1234:AAAA 65535.65535 214 12w,5d,12:44:22 182213 0 23 0 However it becomes a tad harder placing descriptions over this when there's 'mixed' output... me at mybox> show bgp peers Total Paths Active Paths Damped Paths Paths with Penalties 220568 183521 12 4 (Peer) (ASN) (Peer) (ASN) Flaps Time Accepted Filtered Sent Out 53.123.53.25 34853 0 0w,1d,03:45:23 Active (retry in 67s) 23 87.13.214.1 4834 0 0w,4d,06:23:57 Admin Down 123.123.123.123 12345 1028 100w,5d,12:23:54 183521 126051 183521 153921 2000:2000:1234:DEAD:BEEF:1234:AAAA 65535.65535 214 12w,5d,12:44:22 182213 0 23 0 This is not very clear at all, but considering the alternatives I think it is the best we an achieve and as I stated before I don't think we should wrap lines if the users terminal is wide enough to fit all information on one line. This ofcourse requires that xorpsh is aware of the term width. Please leave some comments on this. Last time I spoke to Atanu about this he didn't like the code in the BGP show tools and so they need to be rewritten, I will give it a shot but with my far from perfect C skills I expect the code to be pretty ugly. If anyone wants to help out you are welcome. Thank you Regards, -- Kristian Larsson KLL-RIPE IPv6 & Peering coordinator SpriteLink [AS39525] +46 704 910401 kristian at spritelink.se From pavlin at icir.org Thu Jun 8 11:41:34 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 08 Jun 2006 11:41:34 -0700 Subject: [Xorp-hackers] BGP show tools In-Reply-To: Message from Kristian Larsson of "Thu, 08 Jun 2006 11:45:02 +0200." <20060608094502.GF21791@spritelink.se> Message-ID: <200606081841.k58IfYYO032507@possum.icir.org> Kristian, In general I like your proposal. I've added it to Bugzilla, so the info is not lost: http://www.xorp.org/bugzilla/show_bug.cgi?id=634 Pavlin Kristian Larsson wrote: > I sent a mail some time ago about new format for > the `show bgp *`commands.. I've thought of it a > bit more and I would like to suggest the following > > me at mybox> show bgp peers ? > Possible completions: > <[Enter]> Execute this command > Show BGP peers with > Show BGP peer with > > me at mybox> show bgp peers > Total Paths Active Paths Damped Paths Paths with Penalties > 220568 183521 12 4 > > Peer ASN Flaps Time Accepted Filtered Sent Out > 53.123.53.25 34853 0 0w,1d,03:45:23 Active (retry in 67s) 23 > 87.13.214.1 4834 0 0w,4d,06:23:57 Admin Down > 123.123.123.123 12345 1028 100w,5d,12:23:54 183521 126051 183521 153921 > 217.10.127.17 39525 0 00:12:43 182145 0 23 0 > 217.10.127.19 39525 0 00:11:38 182145 0 23 0 > 2001:6E8:1:3:2:2:3:1 > 39525 214 12w,5d,12:44:22 182213 0 23 0 > > me at mybox> show bgp peers 39525 > Peer ASN Flaps Time Accepted Filtered Sent Out > 217.10.127.17 39525 0 00:12:43 182145 0 23 0 > 217.10.127.19 39525 0 00:11:38 182145 0 23 0 > > me at mybox> show bgp peers 123.123.123.123 > Peer ASN Flaps Time Accepted Filtered Sent Out > 123.123.123.123 12345 1028 0w,0d,0:0:43 *183521 12 8 15 > > > The first field with the IP address of the neighbor can take the "longest" IPv4 > addresses, ie one where all octets contain three digits. ASN (perhaps we should > use 'AsNum' instead?) allow the full 2byte numbers we have today. > Flaps is just the number of times the session has gone to established (as it is > called now). Time is the time since the session went to its current state. > The four last fields are accepted prefixes, filtered prefixes, sent prefixes and > outgoing prefixes. When a session is in established state these are shown, if > we're in another state the state is shown instead, just as in the above example. > > Accepted prefixes is pretty self explanatory.. it is the number of prefixes you > have received and that has passed all route-maps and filters. Filtered are those > that didn't quite make it due to some filter. > Sent prefixes are the amount of prefixes that you have sent to a peer. > Out is the amount of prefixes you intend to send to a peer. It's kind of > dual-purpose.. you can see the equivalent of the Out queue on a Cisco, ie if there > are any packets you need to send to keep your neighbor updated. And when the > session isn't up yet you can still see how many prefixes your router intends to > send. Great for a quick lock - "ah, my router intends to send 23 routes... that's > just my customer and internal routes" so that you dont't accidentally send a full > table to a peer or the alike. > > The asterisk (*) in the last example signifies that the router is working, ie the > In queue is not empty. Having a separate field for InQ seems to overdo it, the > asterisk is enough... > > Now some considerations.. what of IPv4 unicast, IPv4 multicast, IPv6 unicast and > IPv6 multicast. Should everything be displayed under one "summary" display > or should we have separate displays - compare to ciscos > `show ip bgp ipv4 multicast summary`... > > What do we do with IPv6 adresses that are to long to fit (which should be most of > them) or when 4 byte AS number are implemented (RIPE has a proposal so it's not > that far in the future)?? > Both these scenarios would mean longer lines than 80 chars. If xorpsh is aware of > the term width it's not a problem. Ff the user uses a terminal wider than 80 chars > we'll simply use the current width to fit as much information as possible. I think > this is quite common today, but not common enough to completely scrap the 80wide > limit and if someone would use say a 100 wide terminal that might still not be > enough. So we need some rules for wrapping... > too long IPv6 address, pretty easy case: > We'll do it like this, just as in the above example > 2001:6E8:1:3:2:2:3:1 > 39525 214 12w,5d,12:44:22 182213 0 23 0 > Comments please. > > Then there are 4 bytes ASNs, even though I don't think there's actually any > standard on this yet, there are some proposals > http://www.ripe.net/ripe/policies/proposals/2005-12.html for one. It seems likely > that the model in that url will be the one commonly accepted and so when redesigning > these tools we might as well take that draft into consideration. > When doing IPv4 and 4 bytes ASN longer than 6 digits I suggest the following: > 123.123.123.123 65535.65535 > 214 12w,5d,12:44:22 182213 0 23 0 > With both long IPv6 addresses and 4 bytes ASNs longer than 6 digits it becomes a bit > trickier... I find the following the best utilization of space. > 2000:2000:1234:DEAD:BEEF:1234:AAAA 65535.65535 > 214 12w,5d,12:44:22 182213 0 23 0 > However it becomes a tad harder placing descriptions over this when there's 'mixed' > output... > > me at mybox> show bgp peers > Total Paths Active Paths Damped Paths Paths with Penalties > 220568 183521 12 4 > > (Peer) (ASN) > (Peer) (ASN) Flaps Time Accepted Filtered Sent Out > 53.123.53.25 34853 0 0w,1d,03:45:23 Active (retry in 67s) 23 > 87.13.214.1 4834 0 0w,4d,06:23:57 Admin Down > 123.123.123.123 12345 1028 100w,5d,12:23:54 183521 126051 183521 153921 > 2000:2000:1234:DEAD:BEEF:1234:AAAA 65535.65535 > 214 12w,5d,12:44:22 182213 0 23 0 > This is not very clear at all, but considering the alternatives I think it is the > best we an achieve and as I stated before I don't think we should wrap lines if > the users terminal is wide enough to fit all information on one line. This ofcourse > requires that xorpsh is aware of the term width. > > Please leave some comments on this. > > Last time I spoke to Atanu about this he didn't like the code in the BGP show tools > and so they need to be rewritten, I will give it a shot but with my far from > perfect C skills I expect the code to be pretty ugly. If anyone wants to help out > you are welcome. > > Thank you > Regards, > > -- > Kristian Larsson KLL-RIPE > IPv6 & Peering coordinator SpriteLink [AS39525] > +46 704 910401 kristian at spritelink.se > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian at spritelink.se Thu Jun 8 12:51:34 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Thu, 8 Jun 2006 21:51:34 +0200 Subject: [Xorp-hackers] BGP show tools In-Reply-To: <200606081841.k58IfYYO032507@possum.icir.org> References: <20060608094502.GF21791@spritelink.se> <200606081841.k58IfYYO032507@possum.icir.org> Message-ID: <20060608195134.GA3687@spritelink.se> On Thu, Jun 08, 2006 at 11:41:34AM -0700, Pavlin Radoslavov wrote: > Kristian, > > In general I like your proposal. I've added it to Bugzilla, so the > info is not lost: > http://www.xorp.org/bugzilla/show_bug.cgi?id=634 There's actually already a bug open for this and by coincidence I opened it ;) http://www.xorp.org/bugzilla/show_bug.cgi?id=217 I'm closing 634 and adding the info to 217. Hope you don't mind :) I've also added lot of the email conversations back and forth. I would be very interested in hearing how you would like the tool to be written, just roughly outlined and I'll see what I can come up with =) Regards, Kristian. > > Pavlin > > Kristian Larsson wrote: > > > I sent a mail some time ago about new format for > > the `show bgp *`commands.. I've thought of it a > > bit more and I would like to suggest the following > > > > me at mybox> show bgp peers ? > > Possible completions: > > <[Enter]> Execute this command > > Show BGP peers with > > Show BGP peer with > > > > me at mybox> show bgp peers > > Total Paths Active Paths Damped Paths Paths with Penalties > > 220568 183521 12 4 > > > > Peer ASN Flaps Time Accepted Filtered Sent Out > > 53.123.53.25 34853 0 0w,1d,03:45:23 Active (retry in 67s) 23 > > 87.13.214.1 4834 0 0w,4d,06:23:57 Admin Down > > 123.123.123.123 12345 1028 100w,5d,12:23:54 183521 126051 183521 153921 > > 217.10.127.17 39525 0 00:12:43 182145 0 23 0 > > 217.10.127.19 39525 0 00:11:38 182145 0 23 0 > > 2001:6E8:1:3:2:2:3:1 > > 39525 214 12w,5d,12:44:22 182213 0 23 0 > > > > me at mybox> show bgp peers 39525 > > Peer ASN Flaps Time Accepted Filtered Sent Out > > 217.10.127.17 39525 0 00:12:43 182145 0 23 0 > > 217.10.127.19 39525 0 00:11:38 182145 0 23 0 > > > > me at mybox> show bgp peers 123.123.123.123 > > Peer ASN Flaps Time Accepted Filtered Sent Out > > 123.123.123.123 12345 1028 0w,0d,0:0:43 *183521 12 8 15 > > > > > > The first field with the IP address of the neighbor can take the "longest" IPv4 > > addresses, ie one where all octets contain three digits. ASN (perhaps we should > > use 'AsNum' instead?) allow the full 2byte numbers we have today. > > Flaps is just the number of times the session has gone to established (as it is > > called now). Time is the time since the session went to its current state. > > The four last fields are accepted prefixes, filtered prefixes, sent prefixes and > > outgoing prefixes. When a session is in established state these are shown, if > > we're in another state the state is shown instead, just as in the above example. > > > > Accepted prefixes is pretty self explanatory.. it is the number of prefixes you > > have received and that has passed all route-maps and filters. Filtered are those > > that didn't quite make it due to some filter. > > Sent prefixes are the amount of prefixes that you have sent to a peer. > > Out is the amount of prefixes you intend to send to a peer. It's kind of > > dual-purpose.. you can see the equivalent of the Out queue on a Cisco, ie if there > > are any packets you need to send to keep your neighbor updated. And when the > > session isn't up yet you can still see how many prefixes your router intends to > > send. Great for a quick lock - "ah, my router intends to send 23 routes... that's > > just my customer and internal routes" so that you dont't accidentally send a full > > table to a peer or the alike. > > > > The asterisk (*) in the last example signifies that the router is working, ie the > > In queue is not empty. Having a separate field for InQ seems to overdo it, the > > asterisk is enough... > > > > Now some considerations.. what of IPv4 unicast, IPv4 multicast, IPv6 unicast and > > IPv6 multicast. Should everything be displayed under one "summary" display > > or should we have separate displays - compare to ciscos > > `show ip bgp ipv4 multicast summary`... > > > > What do we do with IPv6 adresses that are to long to fit (which should be most of > > them) or when 4 byte AS number are implemented (RIPE has a proposal so it's not > > that far in the future)?? > > Both these scenarios would mean longer lines than 80 chars. If xorpsh is aware of > > the term width it's not a problem. Ff the user uses a terminal wider than 80 chars > > we'll simply use the current width to fit as much information as possible. I think > > this is quite common today, but not common enough to completely scrap the 80wide > > limit and if someone would use say a 100 wide terminal that might still not be > > enough. So we need some rules for wrapping... > > too long IPv6 address, pretty easy case: > > We'll do it like this, just as in the above example > > 2001:6E8:1:3:2:2:3:1 > > 39525 214 12w,5d,12:44:22 182213 0 23 0 > > Comments please. > > > > Then there are 4 bytes ASNs, even though I don't think there's actually any > > standard on this yet, there are some proposals > > http://www.ripe.net/ripe/policies/proposals/2005-12.html for one. It seems likely > > that the model in that url will be the one commonly accepted and so when redesigning > > these tools we might as well take that draft into consideration. > > When doing IPv4 and 4 bytes ASN longer than 6 digits I suggest the following: > > 123.123.123.123 65535.65535 > > 214 12w,5d,12:44:22 182213 0 23 0 > > With both long IPv6 addresses and 4 bytes ASNs longer than 6 digits it becomes a bit > > trickier... I find the following the best utilization of space. > > 2000:2000:1234:DEAD:BEEF:1234:AAAA 65535.65535 > > 214 12w,5d,12:44:22 182213 0 23 0 > > However it becomes a tad harder placing descriptions over this when there's 'mixed' > > output... > > > > me at mybox> show bgp peers > > Total Paths Active Paths Damped Paths Paths with Penalties > > 220568 183521 12 4 > > > > (Peer) (ASN) > > (Peer) (ASN) Flaps Time Accepted Filtered Sent Out > > 53.123.53.25 34853 0 0w,1d,03:45:23 Active (retry in 67s) 23 > > 87.13.214.1 4834 0 0w,4d,06:23:57 Admin Down > > 123.123.123.123 12345 1028 100w,5d,12:23:54 183521 126051 183521 153921 > > 2000:2000:1234:DEAD:BEEF:1234:AAAA 65535.65535 > > 214 12w,5d,12:44:22 182213 0 23 0 > > This is not very clear at all, but considering the alternatives I think it is the > > best we an achieve and as I stated before I don't think we should wrap lines if > > the users terminal is wide enough to fit all information on one line. This ofcourse > > requires that xorpsh is aware of the term width. > > > > Please leave some comments on this. > > > > Last time I spoke to Atanu about this he didn't like the code in the BGP show tools > > and so they need to be rewritten, I will give it a shot but with my far from > > perfect C skills I expect the code to be pretty ugly. If anyone wants to help out > > you are welcome. > > > > Thank you > > Regards, > > > > -- > > Kristian Larsson KLL-RIPE > > IPv6 & Peering coordinator SpriteLink [AS39525] > > +46 704 910401 kristian at spritelink.se > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Kristian Larsson KLL-RIPE IPv6 & Peering coordinator SpriteLink [AS39525] +46 704 910401 kristian at spritelink.se From acb at cs.princeton.edu Tue Jun 13 10:34:26 2006 From: acb at cs.princeton.edu (Andy Bavier) Date: Tue, 13 Jun 2006 13:34:26 -0400 Subject: [Xorp-hackers] OSPF not recomputing routes when neighbor "down" Message-ID: <448EF722.6060108@cs.princeton.edu> Hi, When XORP's OSPF decides a neighbor is "down" because it has stopped responding to Hello packets, I would expect that it would recompute routes and send out new LSAs. However, this isn't happening: if a neighbor crashes, XORP marks it as "down" after 30 seconds... but then no other action is taken. This problem is similar to Bug 387, which handles the case when the link actually goes down -- but here the link is still up and the neighbor is down. The fix to Bug 387 was pretty simple. Can someone suggest a similar bug fix for a neighbor going down? I'm not familiar enough with the XORP code to figure out the right change myself. Thanks, Andy From atanu at ICSI.Berkeley.EDU Tue Jun 13 13:22:55 2006 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 13 Jun 2006 13:22:55 -0700 Subject: [Xorp-hackers] OSPF not recomputing routes when neighbor "down" In-Reply-To: Message from Andy Bavier of "Tue, 13 Jun 2006 13:34:26 EDT." <448EF722.6060108@cs.princeton.edu> Message-ID: <57181.1150230175@tigger.icir.org> Hi, It would really help us to track this problem if you could create a bugzilla entry. Additionally a simple configuration file along with a way to reproduce the problem would also be very helpful. In particular it would be useful to know if the failed neighbour is connected by a Broadcast or Point-to-Point link. Atanu. >>>>> "Andy" == Andy Bavier writes: Andy> Hi, When XORP's OSPF decides a neighbor is "down" because it Andy> has stopped responding to Hello packets, I would expect that Andy> it would recompute routes and send out new LSAs. However, Andy> this isn't happening: if a neighbor crashes, XORP marks it as Andy> "down" after 30 seconds... but then no other action is taken. Andy> This problem is similar to Bug 387, which handles the case Andy> when the link actually goes down -- but here the link is still Andy> up and the neighbor is down. The fix to Bug 387 was pretty Andy> simple. Can someone suggest a similar bug fix for a neighbor Andy> going down? I'm not familiar enough with the XORP code to Andy> figure out the right change myself. Andy> Thanks, Andy Andy> _______________________________________________ Xorp-hackers Andy> mailing list Xorp-hackers at icir.org Andy> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From acb at cs.princeton.edu Tue Jun 13 13:38:34 2006 From: acb at cs.princeton.edu (Andy Bavier) Date: Tue, 13 Jun 2006 16:38:34 -0400 Subject: [Xorp-hackers] OSPF not recomputing routes when neighbor "down" In-Reply-To: <57181.1150230175@tigger.icir.org> References: <57181.1150230175@tigger.icir.org> Message-ID: <448F224A.7010604@cs.princeton.edu> Hi, No problem, I'll file a bugzilla entry. My actual setup is a bit complicated -- I'm running XORP inside UML and using it to control a routing overlay built from Click forwarders -- but I'll try to show the problem with a simple configuration. I'm using Point-to-Point links. Andy Atanu Ghosh wrote: > Hi, > > It would really help us to track this problem if you could create a > bugzilla entry. Additionally a simple configuration file along with a > way to reproduce the problem would also be very helpful. > > In particular it would be useful to know if the failed neighbour is > connected by a Broadcast or Point-to-Point link. > > Atanu. > > >>>>>>"Andy" == Andy Bavier writes: > > > Andy> Hi, When XORP's OSPF decides a neighbor is "down" because it > Andy> has stopped responding to Hello packets, I would expect that > Andy> it would recompute routes and send out new LSAs. However, > Andy> this isn't happening: if a neighbor crashes, XORP marks it as > Andy> "down" after 30 seconds... but then no other action is taken. > > Andy> This problem is similar to Bug 387, which handles the case > Andy> when the link actually goes down -- but here the link is still > Andy> up and the neighbor is down. The fix to Bug 387 was pretty > Andy> simple. Can someone suggest a similar bug fix for a neighbor > Andy> going down? I'm not familiar enough with the XORP code to > Andy> figure out the right change myself. > > Andy> Thanks, Andy > > Andy> _______________________________________________ Xorp-hackers > Andy> mailing list Xorp-hackers at icir.org > Andy> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at icir.org Fri Jun 23 16:43:33 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 23 Jun 2006 16:43:33 -0700 Subject: [Xorp-hackers] debian packaging of xorp 1.2 In-Reply-To: Message from Benjamin Sonntag of "Mon, 05 Jun 2006 18:13:45 +0200." <44845839.5040908@sonntag.fr> Message-ID: <200606232343.k5NNhXaD054555@possum.icir.org> > Hi all, > > I just created a debian package for xorp-1.2 current. > > I did not test it yet on CVS but it should work fluently too. > > You can use the debian package just by adding the following to > /etc/apt/sources.list > > deb http://benjamin.sonntag.fr/ sarge main > > you can download the package source at > http://benjamin.sonntag.fr/dists/sarge/main/source/net/ > > The only difference with xorp 1.2 standard is the debian/ folder. > > If you want to add it to CVS, don't hesitate. > Just one point : the debian/control file contains a quite sparse > description of xorp and xorp-doc. You may make them better since you > know your project very well ... Thank you for the package. I committed the original version to CVS, and then did minor edits of some of the XORP-related comments, etc: xorp/contrib/packages/debian I have a question. Is there any specific reason that you install everything in /usr/lib/xorp instead of the default /usr/local/xorp, especially given that (according to xorp.README.Debian) you are symlink to those files. > Last point : we (Gitoyen-NCC, a small french operator based in Paris) > are making some tests of xorp under debian and freebsd, and last quagga > and openbgpd too. We will certainly tell you our conclusion. We want to > be able to route more than 100Mbps on each link on our PC routers, and > stay as free as possible. Do you have any of the comparison results available? Even negative feedback for XORP is welcome, because it will help us improve it :) Thanks, Pavlin > > See you later, > > Regards, > > Benjamin Sonntag, > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian at spritelink.se Fri Jun 23 16:49:20 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Sat, 24 Jun 2006 01:49:20 +0200 Subject: [Xorp-hackers] Per peer policies Message-ID: <20060623234904.GB30854@spritelink.se> Hi is per peer routing policies anywhere on the road map. This is a feature I really miss with the current XORP setup and it's present in just about any other BGP implementation. Regards, Kristian. -- Kristian Larsson KLL-RIPE IPv6 & Peering coordinator SpriteLink [AS39525] +46 704 910401 kristian at spritelink.se From a.bittau at cs.ucl.ac.uk Sat Jun 24 01:03:22 2006 From: a.bittau at cs.ucl.ac.uk (Andrea Bittau) Date: Sat, 24 Jun 2006 09:03:22 +0100 Subject: [Xorp-hackers] Per peer policies In-Reply-To: <20060623234904.GB30854@spritelink.se> References: <20060623234904.GB30854@spritelink.se> Message-ID: <20060624080322.GA2673@shorty.sorbonet.org> On Sat, Jun 24, 2006 at 01:49:20AM +0200, Kristian Larsson wrote: > is per peer routing policies anywhere on the road Isn't that just the neigbor variable? Something like: from { neighbor: "1.2.3.4" } then { /* your per peer policy */ } From kristian at spritelink.se Sat Jun 24 02:32:33 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Sat, 24 Jun 2006 11:32:33 +0200 Subject: [Xorp-hackers] Per peer policies In-Reply-To: <20060624080322.GA2673@shorty.sorbonet.org> References: <20060623234904.GB30854@spritelink.se> <20060624080322.GA2673@shorty.sorbonet.org> Message-ID: <20060624093233.GC30854@spritelink.se> On Sat, Jun 24, 2006 at 09:03:22AM +0100, Andrea Bittau wrote: > On Sat, Jun 24, 2006 at 01:49:20AM +0200, Kristian Larsson wrote: > > is per peer routing policies anywhere on the road > > Isn't that just the neigbor variable? Something like: > > from { > neighbor: "1.2.3.4" > } > then { > /* your per peer policy */ > } Well, yes. and No ;) Of course, it can be done this way but it results in a long and cumbersome policy (imho). I'd rather have separate policies that I can apply to certain peers as not to mix things up. A small "neighor blabla" in the from statement is easily forgotten ;) Internally XORP would probably handle it just the same. Kristian. -- Kristian Larsson KLL-RIPE IPv6 & Peering coordinator SpriteLink [AS39525] +46 704 910401 kristian at spritelink.se From s8066410 at kmitl.ac.th Tue Jun 27 09:09:12 2006 From: s8066410 at kmitl.ac.th (s8066410 at kmitl.ac.th) Date: Tue, 27 Jun 2006 23:09:12 +0700 (ICT) Subject: [Xorp-hackers] web-based user interface Message-ID: <28127.125.24.19.59.1151424552.squirrel@125.24.19.59> Hi XORP I want to write web-based user interface to control XORP from web. Can I connect web-base user interface with write by PHP to XORP ? Please tell me how to connect my web-base to XORP with API or shell script. Thank you. Chatree Chalothorn. From robert at vyatta.com Tue Jun 27 13:51:36 2006 From: robert at vyatta.com (Robert Bays) Date: Tue, 27 Jun 2006 13:51:36 -0700 Subject: [Xorp-hackers] web-based user interface In-Reply-To: <28127.125.24.19.59.1151424552.squirrel@125.24.19.59> References: <28127.125.24.19.59.1151424552.squirrel@125.24.19.59> Message-ID: <44A19A58.3000905@vyatta.com> Hi Chatree, You will need to translate data collected from the web interface into a series of XRL calls. I would start by reading the "XORP Design Overview", "XORP Inter-Process Communication Library Overview", and "XRL Interfaces: Specifications and Tools". All of these documents can be found at http://www.xorp.org/design_docs.html and they describe the basic usage of the XRL system. The source code for xorpsh is also a very helpful resource. Its routines can be used as examples for all the back end services you would need to support in a GUI. Finally, you can check out an example of a C++ GUI implementation at http://suva.vyatta.com/viewvc/build/vyatta/xorp/rl_xg/ Cheers, Robert. s8066410 at kmitl.ac.th wrote: > Hi XORP > I want to write web-based user interface to control XORP from web. > Can I connect web-base user interface with write by PHP to XORP ? > Please tell me how to connect my web-base to XORP with API or shell script. > Thank you. > Chatree Chalothorn. > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers