From microflux@yahoo.com Thu Oct 6 19:27:03 2005 From: microflux@yahoo.com (David) Date: Thu, 6 Oct 2005 11:27:03 -0700 (PDT) Subject: [Xorp-hackers] Is it possible for XORP to act like N independent routers ? Message-ID: <20051006182703.23991.qmail@web40425.mail.yahoo.com> 1. there are multiple physical interfaces on a Linux box 2. each physical interface has the same set of VLAN interfaces 3. the router should treat each set of VLAN interfaces with the same ID as an independent "routing domain" that is completely independence of the other "routing domains" and the addresses might even overlap, i believe i am misusing the term "routing domain" here but please forgive me for a lack of a better term. 4. at the kernel routing layer each "routing domain" will have its own routing table 5. packets are fwmarked at the VLAN interfaces 6. packets are policy routed according to the fwmark to the corresponding routing tables 7. the routing software maintains all the independent route tables some one tell me am i insane ? some how the project I'm working on has led me to this conclusion. could this be easily done ? would people accept this into the XORP code base ? can it already be done ? __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From pavlin@icir.org Thu Oct 6 20:51:19 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 06 Oct 2005 12:51:19 -0700 Subject: [Xorp-hackers] Is it possible for XORP to act like N independent routers ? In-Reply-To: Message from David of "Thu, 06 Oct 2005 11:27:03 PDT." <20051006182703.23991.qmail@web40425.mail.yahoo.com> Message-ID: <200510061951.j96JpJL0002526@possum.icir.org> > 1. there are multiple physical interfaces on a Linux > box > 2. each physical interface has the same set of VLAN > interfaces > 3. the router should treat each set of VLAN interfaces > with the same ID as an independent "routing domain" > that is completely independence of the other "routing > domains" and the addresses might even overlap, i > believe i am misusing the term "routing domain" here > but please forgive me for a lack of a better term. > 4. at the kernel routing layer each "routing domain" > will have its own routing table > 5. packets are fwmarked at the VLAN interfaces > 6. packets are policy routed according to the fwmark > to the corresponding routing tables > 7. the routing software maintains all the independent > route tables > > > some one tell me am i insane ? > some how the project I'm working on has led me to this > conclusion. could this be easily done ? > would people accept this into the XORP code base ? > can it already be done ? One simple solution that comes to mind is to run N independent instances of XORP on the same machine. E.g., N FEAs, N RIBs, N BGPs, etc, and each instance configured with its own configuration file. This should work in case of unicast routing, but if you want to run multicast routing as well the solution needs to be adjusted to run only one FEA/MFEA, because the UNIX kernel allows only one multicast routing socket open at a time. To run more than one XORP instance at a time, you need to do the following, but I should warn you upfront that there is a small catch: Set the XORP_FINDER_SERVER_PORT environmental variable to use an unique TCP port for each XORP instance. The default value I believe is 19999. You need to set it before running the rtrmgr (e.g., "setenv XORP_FINDER_SERVER_PORT 30000" in case of tcsh), and you also need to set it before starting the corresponding xorpsh instance that will communicate with that rtrmgr. The catch is that on startup the FEA removes all leftover unicast routes installed by XORP in the UNIX kernel (those routes are marked with a special flag so the FEA can recognize them when it pulls the forwarding table from the kernel). Also, on shutdown it removes all XORP routes as well. Unfortunately, currently this removal is unconditional, but ideally it should be configurable. What that means is that if the first instance of XORP adds some routes to the kernel, then if you start a second instance of XORP, the second FEA instance will remove all XORP routes already installed in the kernel by the first XORP instance. The simple way to get around the above catch is to comment-out the following lines: delete_all_entries4(); delete_all_entries6(); Those are inside methods start() and stop() inside the following files: fticonfig_table_set_click.cc fticonfig_table_set_dummy.cc fticonfig_table_set_iphelper.cc fticonfig_table_set_netlink.cc fticonfig_table_set_rtsock.cc Strictly speaking, typically you need to comment them out in only one file. E.g., in case of Linux it would be fticonfig_table_set_netlink.cc and in case of BSD it would be fticonfig_table_set_rtsock.cc. Probably there are other solutions of your problem so I would be interested to hear other ideas. Pavlin From microflux@yahoo.com Fri Oct 7 16:23:51 2005 From: microflux@yahoo.com (David) Date: Fri, 7 Oct 2005 08:23:51 -0700 (PDT) Subject: [Xorp-hackers] Is it possible for XORP to act like N independent routers ? In-Reply-To: <200510061951.j96JpJL0002526@possum.icir.org> Message-ID: <20051007152351.8750.qmail@web40424.mail.yahoo.com> --- PavlPavlinoRadoslavovvlpavlinricir> wrote: > > 1. there are multiple physical interfaces on a > Linux > > box > > 2. each physical interface has the same set of > VLANVLAN> interfaces > > 3. the router should treat each set of VLANVLANinterfaces > > with the same ID as an independent "routing > domain" > > that is completely independence of the other > "routing > > domains" and the addresses might even overlap, i > > believe i am misusing the term "routing domain" > here > > but please forgive me for a lack of a better term. > > 4. at the kernel routing layer each "routing > domain" > > will have its own routing table > > 5. packets are fwmafwmarkedthe VLANVLANerfaces > > 6. packets are policy routed according to the > fwmafwmark> to the corresponding routing tables > > 7. the routing software maintains all the > independent > > route tables > > > > > > some one tell me am i insane ? > > some how the project I'm working on has led me to > this > > conclusion. could this be easily done ? > > would people accept this into the XORPXORPe base ? > > can it already be done ? > > One simple solution that comes to mind is to run N > independent > instances of XORPXORPthe same machine. E.g., N FEAsFEAs N RIBsRIBsBGPsBGPs etc, and each instance configured with its own > configuration file. > This should work in case of unicunicastting, but if > you want to run > multmulticastting as well the solution needs to be > adjusted to run > only one FEA/FEAAMFEAcause the UNIX kernel allows > only one multmulticastrouting socket open at a time. > > To run more than one XORPXORPtance at a time, you > need to do the > following, but I should warn you upfront that there > is a small > catch: > > Set the XORPXORPDER_SERVER_PORT environmental > variable to use an > unique TCP TCPt for each XORPXORPtance. The default > value I believe > is 19999. You need to set it before running the > rtrmrtrmgrg., > "setesetenvPXORPDER_SERVER_PORT 30000" in case of > tcshtcshnd you > also need to set it before starting the > corresponding xorpxorpshinstance that will communicate with that rtrmrtrmgr > The catch is that on starstartup FEA FEAoves all > leftover unicunicastroutes installed by XORPXORPthe UNIX kernel (those > routes are marked > with a special flag so the FEA FEA recognize them > when it pulls the > forwarding table from the kernel). Also, on shutdown > it removes all > XORPXORPtes as well. Unfortunately, currently this > removal is > unconditional, but ideally it should be > configurable. > What that means is that if the first instance of > XORPXORPs some > routes to the kernel, then if you start a second > instance of XORPXORP the second FEA FEAtance will remove all XORPXORPtes > already > installed in the kernel by the first XORPXORPtance. > > The simple way to get around the above catch is to > comment-out the > following lines: > > delete_all_entries4(); > delete_all_entries6(); > > Those are inside methods start() and stop() inside > the following > files: > > fticfticonfigle_set_click.cc > fticfticonfigle_set_dummy.cc > fticfticonfigle_set_ipheiphelper > fticfticonfigle_set_netlnetlink > fticfticonfigle_set_rtsortsock > > Strictly speaking, typically you need to comment > them out in only > one file. E.g., in case of Linux it would be > fticfticonfigle_set_netlnetlinkand in case of BSD it > would be > fticfticonfigle_set_rtsortsock > > > Probably there are other solutions of your problem > so I would be > interested to hear other ideas. > > PavlPavlin Thanks for the quick response. That sounds like a good solution, but one problem is that there might potepotentiallya dozen or so of these domains. I would realreallye to avoid running all those processes. I am not an XORPXORPeloper, but I had the following idea. if internal structures were modified to also include a VLANVLANtag field. Then all the looklook ups matches would have to be modified to take the tags into account. So when a routing packet comes in on an interface with ID A then all the logic is based on stored routes that have been tagetaggedh ID A and the results are sent out interfaces that have ID A and the VLANVLAN What do you guys think ? This can also be genegeneralizeduppose. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From pavlin@icir.org Fri Oct 7 17:02:04 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 07 Oct 2005 09:02:04 -0700 Subject: [Xorp-hackers] Is it possible for XORP to act like N independent routers ? In-Reply-To: Message from David of "Fri, 07 Oct 2005 08:23:51 PDT." <20051007152351.8750.qmail@web40424.mail.yahoo.com> Message-ID: <200510071602.j97G24Wd043415@possum.icir.org> > Thanks for the quick response. That sounds like a good > solution, but one problem is that there might > potepotentiallya dozen or so of these domains. I would > realreallye to avoid running all those processes. > > I am not an XORPXORPeloper, but I had the following > idea. if internal structures were modified to also > include a VLANVLANtag field. Then all the looklook ups > matches would have to be modified to take the tags > into account. So when a routing packet comes in on an > interface with ID A then all the logic is based on > stored routes that have been tagetaggedh ID A and the > results are sent out interfaces that have ID A and the > VLANVLAN > > What do you guys think ? This can also be > genegeneralizeduppose. If you have a reasonably fast machine, I'd recommend to try first running a dozen of XORP instances before completely disregarding this option. While in this space, you may want to consider IMUNES (http://www.imunes.net) which (among many things) can give you much better isolation and convenience running multiple XORP instances. With IMUNES you can run XORP out-of-the-box without any of the mods or without setting any environmental variables that I described in my previous email. Alternatively, maybe you can use the recently added policy support to do something like what you describe above? Other folks who know the details of the policy framework can tell you what exactly you can do with it. Pavlin From tdurack@gmail.com Sat Oct 8 15:13:18 2005 From: tdurack@gmail.com (Tim Durack) Date: Sat, 8 Oct 2005 10:13:18 -0400 Subject: [Xorp-hackers] IPv6 commands Message-ID: <9e246b4d0510080713u39128a73nc8fff022def17ce6@mail.gmail.com> ------=_Part_4674_14097974.1128780798142 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Would it be possible to add ping6/traceroute6 to misc.cmd? I just copied th= e ping entries and made ping6 entries. This would make configuring and testing IPv6 much easier. Tim:> ------=_Part_4674_14097974.1128780798142 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Would it be possible to add ping6/traceroute6 to misc.cmd? I just copied th= e ping entries and made ping6 entries.

This would make configuring and testing IPv6 much easier.

Tim:>
------=_Part_4674_14097974.1128780798142-- From kristian@juniks.net Sun Oct 9 18:49:25 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sun, 9 Oct 2005 19:49:25 +0200 Subject: [Xorp-hackers] Patches not commited!? Message-ID: <20051009174925.GA15788@juniks.net> Dear developers-with-CVS-access, there seems to be a few patches on the BugZilla that has not yet been commited although they have been there for quite some time now. Is there any way one should mark the particular bugzilla entry for you to see that the bug is actually "resolved" though it needs to be synced/commited with/to the CVS? Regards, Kristian From pavlin@icir.org Sun Oct 9 19:21:52 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 09 Oct 2005 11:21:52 -0700 Subject: [Xorp-hackers] Patches not commited!? In-Reply-To: Message from Kristian Larsson of "Sun, 09 Oct 2005 19:49:25 +0200." <20051009174925.GA15788@juniks.net> Message-ID: <200510091821.j99ILqoa008410@possum.icir.org> > Dear developers-with-CVS-access, > > there seems to be a few patches on the BugZilla > that has not yet been commited although they have > been there for quite some time now. > Is there any way one should mark the particular > bugzilla entry for you to see that the bug is > actually "resolved" though it needs to be > synced/commited with/to the CVS? Sigh, I am probably the one to blame for not committing them. Recently there has been an explosion of new bugzilla entries so the speed of resolving them is way behind the incoming rate :( So far the entries are resolved in a mixture of order of priority and FIFO. If you would like the entries with patch inside to be resolved sooner, please send me the list of those entries. Thanks, Pavlin From pavlin@icir.org Mon Oct 10 08:15:20 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 10 Oct 2005 00:15:20 -0700 Subject: [Xorp-hackers] IPv6 commands In-Reply-To: Message from Tim Durack of "Sat, 08 Oct 2005 10:13:18 EDT." <9e246b4d0510080713u39128a73nc8fff022def17ce6@mail.gmail.com> Message-ID: <200510100715.j9A7FK4a048365@possum.icir.org> > Would it be possible to add ping6/traceroute6 to misc.cmd? I just copied th= > e > ping entries and made ping6 entries. > > This would make configuring and testing IPv6 much easier. Done. The new commands are in CVS (etc/templates/misc.cmds rev. 1.8) Pavlin From tdurack@gmail.com Mon Oct 10 13:57:35 2005 From: tdurack@gmail.com (Tim Durack) Date: Mon, 10 Oct 2005 08:57:35 -0400 Subject: [Xorp-hackers] IPv6 commands In-Reply-To: <200510100715.j9A7FK4a048365@possum.icir.org> References: <9e246b4d0510080713u39128a73nc8fff022def17ce6@mail.gmail.com> <200510100715.j9A7FK4a048365@possum.icir.org> Message-ID: <9e246b4d0510100557k17ff15b9r3062bd8ae807824@mail.gmail.com> ------=_Part_11230_33515125.1128949055730 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thanks! On 10/10/05, Pavlin Radoslavov wrote: > > > Would it be possible to add ping6/traceroute6 to misc.cmd? I just copie= d > th=3D > > e > > ping entries and made ping6 entries. > > > > This would make configuring and testing IPv6 much easier. > > Done. > The new commands are in CVS (etc/templates/misc.cmds rev. 1.8) > > Pavlin > ------=_Part_11230_33515125.1128949055730 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thanks!

On 10/10/05, Pavlin Radoslavov <pavlin@icir.org> wrote:
> Would it be possible to add ping6/traceroute6 to misc.cmd? I just copi= ed th=3D
> e
> ping entries and made ping6 entries.
>
= > This would make configuring and testing IPv6 much easier.

Done.
The new commands are in CVS (etc/templates/misc.cmds rev. 1.8)

P= avlin

------=_Part_11230_33515125.1128949055730-- From VEROPDUR@terra.es Tue Oct 11 18:54:16 2005 From: VEROPDUR@terra.es (VEROPDUR@terra.es) Date: Tue, 11 Oct 2005 19:54:16 +0200 (MEST) Subject: [Xorp-hackers] help with FEA Message-ID: <19728401.1129053256702.JavaMail.root@cps6> ------=_Part_9739_8336376.1129053256701 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I'm Ver=C3=B3nica, a spanish student of Computer Sciencie, I'm thinking= about developing an application on xorp. I need to analyze some informatio= n about a package (it isn't sufficient wiht IP direction) for according to = those data, to modify the information of same and redirect it. I have been = watching the API FEA and I haven't found a method that allows me to do this= . Is it posible? What method I could apply? Thanks a lot. Ver=C3=B3nica. Prueba el Nuevo Correo Terra; Seguro, Rápido, Fiable. ------=_Part_9739_8336376.1129053256701 Content-Type: text/html;charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I'm Ver=C3=B3nica, a spanish student of Computer Sciencie, I'm thinking= about developing an application on xorp. I need to analyze some informatio= n about a package (it isn't sufficient wiht IP direction) for according to = those data, to modify the information of same and redirect it. I have been = watching the API FEA and I haven't found a method that allows me to do this= . Is it posible? What method I could apply?
Thanks a lot.
Ver=C3=B3= nica.


Prueba el Nuevo Correo Terra; Seguro, Rápido, Fiable.
------=_Part_9739_8336376.1129053256701-- From pavlin@icir.org Tue Oct 11 19:05:10 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 11 Oct 2005 11:05:10 -0700 Subject: [Xorp-hackers] help with FEA In-Reply-To: Message from "VEROPDUR@terra.es" of "Tue, 11 Oct 2005 19:54:16 +0200." <19728401.1129053256702.JavaMail.root@cps6> Message-ID: <200510111805.j9BI5Aro008557@possum.icir.org> > Hi, I'm Ver=C3=B3nica, a spanish student of Computer Sciencie, I'm thinking= > about developing an application on xorp. I need to analyze some informatio= > n about a package (it isn't sufficient wiht IP direction) for according to = > those data, to modify the information of same and redirect it. I have been = > watching the API FEA and I haven't found a method that allows me to do this= > . Is it posible? What method I could apply? It looks like you want to intercept and modify the packets on the fly. You cannot do this with the XORP FEA. Probably Click will be your best option. Then it is up to you to decide whether you need Click (only) without XORP, or whether you want to run XORP+Click. If the later, have a look at the fea section inside rtrmgr/config.boot.sample which contains information how to run XORP with Click. Pavlin From kristian@juniks.net Thu Oct 13 07:03:59 2005 From: kristian@juniks.net (Kristian Larsson) Date: Thu, 13 Oct 2005 08:03:59 +0200 Subject: [Xorp-hackers] Patches not commited!? In-Reply-To: <200510111648.j9BGlxOB007823@possum.icir.org> References: <20051011094531.GB21187@juniks.net> <200510111648.j9BGlxOB007823@possum.icir.org> Message-ID: <20051013060359.GA2768@juniks.net> On Tue, Oct 11, 2005 at 09:47:59AM -0700, Pavlin Radoslavov wrote: > > I understand you have quite a lot to do ;) > > It seems that not many of the developers listed on > > the xorp webpage are actually active. Perhaps > > another person with CVS access could help out. And > > with that person having bugs/BugZilla as main > > focus all these small bugs could be resolved very > > quickly. > > > > Anyway here is a (partial?) list. > > 53 > > 54 > > 64 > > 161 > > 199 > > 212 > > 217 > > Thanks for the list. Accidentally, last night I found by accident > and already fixed the problem described in Bugzilla entry #212, so I > just marked that FIXED. > > Atanu is the one to take care of #217, but recently he is overloaded > with the OSPF implementation so probably after that he will take > care of it. > > Note that in general even if there is a patch for a problem it is > not just a question of applying that patch. We need to verify it and > modify it if necessary (e.g., to match the XORP codingguidelines, > etc). Occasionally, we need to think about the high-level impact of > a solution. A not so good example could be whether we want to have a > special template that defines the header of the XORP configuration > files or whether the format of that header would be hardcoded inside > the *.cc files. > > Anyway, I created a note for myself with the above bugzilla entries > so I will try to address them sooner than later (though note that > some of them may have to be postponed until after the release > because of the significant impact they have on the system). > > Unfortunately, it is quite hard to have a person that addresses all > the bugzilla entries, because typically fixing a bug requires deep > understanding of how the particular module works. E.g., I deal with > multicast bugs, Atanu deals with BGP bugs, etc. Valid point ;) I was thinking of all the small trivial fixes. Somehow I feel they should be given some form of priority. If someone sends a patch to BZ I think it's important that the patch is at least looked over. Perhaps an addition to BugZilla which makes it possible to search for bugs with patches. This way you could search for patched bugs ones a week, verify and commit :) Kristian. From kristian@juniks.net Fri Oct 14 12:33:57 2005 From: kristian@juniks.net (Kristian Larsson) Date: Fri, 14 Oct 2005 13:33:57 +0200 Subject: [Xorp-hackers] Patches not commited!? In-Reply-To: <82629.1129187802@tigger.icir.org> References: <20051013060359.GA2768@juniks.net> <82629.1129187802@tigger.icir.org> Message-ID: <20051014113357.GA1711@juniks.net> On Thu, Oct 13, 2005 at 12:16:42AM -0700, Atanu Ghosh wrote: > Hi, > > I believe the code as we wrote it has a design flaw, the fetching of the > data about the peer and the printing should not be mixed. > > I was going to rewrite the code to fetch all the data about the peer and > then when it had all been accumulated pass it to different output > routines. I believe that would make it easier to manage. I wasn't > ignoring your patch I just didn't think that it could be applied as it > is. So should I try to clean up my code or is it pointless since you will change the code anyway? > > I actually applied your patch as I liked the form of the output but a > number of things concerned me when I looked at the code. I'm glad you liked it :) > This construct writes a zero to an arbitary location. > ---------------------------------------- > char *host; > strcpy(host, ""); > ---------------------------------------- > > Try this: > ---------------------------------------- > main() > { > char *host = 0; > strcpy(host, ""); > } > ---------------------------------------- > > We have a TimeVal structure that can be used for manipulating time: > ---------------------------------------- > + w = (time - time%604800)/604800; > + d = ((time%604800) - (time%604800)%86400)/86400; > + h = ((time%604800)%86400 - ((time%604800)%86400)%3600)/3600; > + m = (((time%604800)%86400)%3600 - (((time%604800)%86400)%3600)%60)/60; > + s = (((time%604800)%86400)%3600)%60; > ---------------------------------------- Hmm, were do I find docuemntation on the above? > > There were a bunch of unused variable: > ---------------------------------------- > stringstream ss,tin,tout; > string t,in,out; > ---------------------------------------- > > There is also mixed usage of cout and stdio I wasn't sure that this > would work portably. I think I've seen this in other utilities, but I'm not sure. > I should have sent you a commentary earlier but I was hoping to have > the time to restructure the code and then adapt your output routine > which I really like. Right now it "show bgp peers" doesn't seem to work at all; " Xorp> show bgp peers Usage: xorpsh_print_peers show bgp peers [detail] where detail enables verbose output. ERROR: Xorp> " Kristian. > Atanu. > > >>>>> "Kristian" == Kristian Larsson writes: > > Kristian> On Tue, Oct 11, 2005 at 09:47:59AM -0700, Pavlin > Kristian> Radoslavov wrote: > >> > I understand you have quite a lot to do ;) > It seems that not > >> many of the developers listed on > the xorp webpage are actually > >> active. Perhaps > another person with CVS access could help > >> out. And > with that person having bugs/BugZilla as main > focus > >> all these small bugs could be resolved very > quickly. > >> > > >> > Anyway here is a (partial?) list. > 53 > 54 > 64 > 161 > 199 > > >> 212 > 217 > >> > >> Thanks for the list. Accidentally, last night I found by accident > >> and already fixed the problem described in Bugzilla entry #212, > >> so I just marked that FIXED. > >> > >> Atanu is the one to take care of #217, but recently he is > >> overloaded with the OSPF implementation so probably after that he > >> will take care of it. > >> > >> Note that in general even if there is a patch for a problem it is > >> not just a question of applying that patch. We need to verify it > >> and modify it if necessary (e.g., to match the XORP > >> codingguidelines, etc). Occasionally, we need to think about the > >> high-level impact of a solution. A not so good example could be > >> whether we want to have a special template that defines the > >> header of the XORP configuration files or whether the format of > >> that header would be hardcoded inside the *.cc files. > >> > >> Anyway, I created a note for myself with the above bugzilla > >> entries so I will try to address them sooner than later (though > >> note that some of them may have to be postponed until after the > >> release because of the significant impact they have on the > >> system). > >> > >> Unfortunately, it is quite hard to have a person that addresses > >> all the bugzilla entries, because typically fixing a bug requires > >> deep understanding of how the particular module works. E.g., I > >> deal with multicast bugs, Atanu deals with BGP bugs, etc. > > Kristian> Valid point ;) I was thinking of all the small trivial > Kristian> fixes. Somehow I feel they should be given some form of > Kristian> priority. If someone sends a patch to BZ I think it's > Kristian> important that the patch is at least looked over. > > Kristian> Perhaps an addition to BugZilla which makes it possible to > Kristian> search for bugs with patches. This way you could search > Kristian> for patched bugs ones a week, verify and commit :) > > > Kristian> Kristian. > Kristian> _______________________________________________ > Kristian> Xorp-hackers mailing list Xorp-hackers@icir.org > Kristian> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From atanu@ICSI.Berkeley.EDU Fri Oct 14 17:35:05 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 14 Oct 2005 09:35:05 -0700 Subject: [Xorp-hackers] Patches not commited!? In-Reply-To: Message from Kristian Larsson of "Fri, 14 Oct 2005 13:33:57 +0200." <20051014113357.GA1711@juniks.net> Message-ID: <59217.1129307705@tigger.icir.org> Hi, I would wait to submit a patch until we have refactored the code. The documentation on TimeVal: . We have a draft coding standards that could do with being more prominent: Some recent change seems to have stopped the bgp show commands from working. We are looking into this now. Atanu. >>>>> "Kristian" == Kristian Larsson writes: Kristian> On Thu, Oct 13, 2005 at 12:16:42AM -0700, Atanu Ghosh Kristian> wrote: >> Hi, >> >> I believe the code as we wrote it has a design flaw, the fetching >> of the data about the peer and the printing should not be mixed. >> >> I was going to rewrite the code to fetch all the data about the >> peer and then when it had all been accumulated pass it to >> different output routines. I believe that would make it easier to >> manage. I wasn't ignoring your patch I just didn't think that it >> could be applied as it is. Kristian> So should I try to clean up my code or is it pointless Kristian> since you will change the code anyway? >> I actually applied your patch as I liked the form of the output >> but a number of things concerned me when I looked at the code. Kristian> I'm glad you liked it :) >> This construct writes a zero to an arbitary location. >> ---------------------------------------- >> char *host; strcpy(host, ""); >> ---------------------------------------- >> >> Try this: >> ---------------------------------------- >> main() { char *host = 0; strcpy(host, ""); } >> ---------------------------------------- >> >> We have a TimeVal structure that can be used for manipulating >> time: >> ---------------------------------------- >> + w = (time - time%604800)/604800; + d = ((time%604800) - >> (time%604800)%86400)/86400; + h = ((time%604800)%86400 - >> ((time%604800)%86400)%3600)/3600; + m = >> (((time%604800)%86400)%3600 - >> (((time%604800)%86400)%3600)%60)/60; + s = >> (((time%604800)%86400)%3600)%60; >> ---------------------------------------- Kristian> Hmm, were do I find docuemntation on the above? >> There were a bunch of unused variable: >> ---------------------------------------- >> stringstream ss,tin,tout; string t,in,out; >> ---------------------------------------- >> >> There is also mixed usage of cout and stdio I wasn't sure that >> this would work portably. Kristian> I think I've seen this in other utilities, but I'm not Kristian> sure. >> I should have sent you a commentary earlier but I was hoping to >> have the time to restructure the code and then adapt your output >> routine which I really like. Kristian> Right now it "show bgp peers" doesn't seem to work at all; Kristian> " Xorp> show bgp peers Kristian> Usage: xorpsh_print_peers show bgp peers [detail] where Kristian> detail enables verbose output. ERROR: Xorp> " Kristian> Kristian. >> Atanu. >> >> >>>>> "Kristian" == Kristian Larsson >> writes: >> Kristian> On Tue, Oct 11, 2005 at 09:47:59AM -0700, Pavlin Kristian> Radoslavov wrote: >> >> > I understand you have quite a lot to do ;) > It seems that >> not >> many of the developers listed on > the xorp webpage are >> actually >> active. Perhaps > another person with CVS access >> could help >> out. And > with that person having bugs/BugZilla as >> main > focus >> all these small bugs could be resolved very > >> quickly. >> >> > >> >> > Anyway here is a (partial?) list. > 53 > 54 > 64 > 161 > >> 199 > >> 212 > 217 >> >> >> >> Thanks for the list. Accidentally, last night I found by >> accident >> and already fixed the problem described in Bugzilla >> entry #212, >> so I just marked that FIXED. >> >> >> >> Atanu is the one to take care of #217, but recently he is >> >> overloaded with the OSPF implementation so probably after that he >> >> will take care of it. >> >> >> >> Note that in general even if there is a patch for a problem it >> is >> not just a question of applying that patch. We need to >> verify it >> and modify it if necessary (e.g., to match the XORP >> >> codingguidelines, etc). Occasionally, we need to think about >> the >> high-level impact of a solution. A not so good example >> could be >> whether we want to have a special template that >> defines the >> header of the XORP configuration files or whether >> the format of >> that header would be hardcoded inside the *.cc >> files. >> >> >> >> Anyway, I created a note for myself with the above bugzilla >> >> entries so I will try to address them sooner than later (though >> >> note that some of them may have to be postponed until after >> the >> release because of the significant impact they have on the >> >> system). >> >> >> >> Unfortunately, it is quite hard to have a person that >> addresses >> all the bugzilla entries, because typically fixing a >> bug requires >> deep understanding of how the particular module >> works. E.g., I >> deal with multicast bugs, Atanu deals with BGP >> bugs, etc. >> Kristian> Valid point ;) I was thinking of all the small trivial Kristian> fixes. Somehow I feel they should be given some form of Kristian> priority. If someone sends a patch to BZ I think it's Kristian> important that the patch is at least looked over. >> Kristian> Perhaps an addition to BugZilla which makes it possible to Kristian> search for bugs with patches. This way you could search Kristian> for patched bugs ones a week, verify and commit :) >> Kristian> Kristian. _______________________________________________ Kristian> Xorp-hackers mailing list Xorp-hackers@icir.org Kristian> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin@icir.org Fri Oct 14 19:06:18 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 14 Oct 2005 11:06:18 -0700 Subject: [Xorp-hackers] Patches not commited!? In-Reply-To: Message from Atanu Ghosh of "Fri, 14 Oct 2005 09:35:05 PDT." <59217.1129307705@tigger.icir.org> Message-ID: <200510141806.j9EI6IsJ015206@possum.icir.org> > Some recent change seems to have stopped the bgp show commands from > working. We are looking into this now. Thanks to the detailed debugging info I received from Atanu, the problem is now fixed and committed to CVS. Thanks for the catch, Kristian! Pavlin From kristian@juniks.net Sat Oct 15 00:17:47 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sat, 15 Oct 2005 01:17:47 +0200 Subject: [Xorp-hackers] Rtrmgr start without config.boot Message-ID: <20051014231747.GA2660@juniks.net> Hey everybody :) Right now the rtrmgr won't start without a configraution file and this doesn't go well with my rtrmgr-should-always-start-no-matter-what-policy ;) Seriously though, isn't a warning message enough? I mean you touch the file and xorp starts, no one bothers actually writing a correct configuration file. I've created a bug and a patch for it on the BugZilla for everyones evaluation :) Kristian. From kristian@juniks.net Sat Oct 15 00:28:06 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sat, 15 Oct 2005 01:28:06 +0200 Subject: [Xorp-hackers] show commands Message-ID: <20051014232806.GB2660@juniks.net> Hey, Is there a way to combine the "hardcoded" commands withing cli.cc with the template files? I would like to have a "show configuration" command available from the operational mode, but as it is right now it seems I must write a separate program and call it with a few lines in a template file, right? It would be much easier if one could just call show_func... Another thing on my mind; I know this has been brought up before, I even think there is a BugZilla entry for it, but shouldn't show commands be available all the time? If you start rtrmgr with a clean configuration there are almost no show commands at all. This confused me and I know it has others as well. If the "%module bgp" line is removed, the bgp commands appear and if run when bgp isn't started you simply get a "No BGP exists" which IMHO is much better than not seing the show command at all. Other opinions? Kristian. From kristian@juniks.net Sat Oct 15 00:44:25 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sat, 15 Oct 2005 01:44:25 +0200 Subject: [Xorp-hackers] BGP configuration Message-ID: <20051014234425.GC2660@juniks.net> I have been labbing with BGP now for a while and I have a few thoughts about it... You have to configure local-ip, this is something I like, it forces the user to pick a interface, be it a loopback for iBGP or a fixed interface for eBGP. But the next-hop? Why on earth do I need to set a next-hop? Alright if it's an option but it shouldn't be required or have I missed something? There's also a small annoying bug. Try doing: create protocols bgp set protocols bgp bgp-id 1.1.1.1 set protocols bgp local-as 112 commit (everthings fine) create protocols bgp peer commit (it will complain over missing arguments) now fill in the mising stuff, local-ip, next-hop and as. Try to commit, at least for me it won't work. I also would like to rename 'protocols bgp peer _as_' to 'peer-as' as it's not crystal clear as to what AS (local/peer) 'as' is actually referring to. Kristian. From atanu@ICSI.Berkeley.EDU Sat Oct 15 05:47:31 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 14 Oct 2005 21:47:31 -0700 Subject: [Xorp-hackers] BGP configuration In-Reply-To: Message from Kristian Larsson of "Sat, 15 Oct 2005 01:44:25 +0200." <20051014234425.GC2660@juniks.net> Message-ID: <51313.1129351651@tigger.icir.org> Kristian> I have been labbing with BGP now for a while and I have a Kristian> few thoughts about it... You have to configure local-ip, Kristian> this is something I like, it forces the user to pick a Kristian> interface, be it a loopback for iBGP or a fixed interface Kristian> for eBGP. But the next-hop? Why on earth do I need to set Kristian> a next-hop? Alright if it's an option but it shouldn't be Kristian> required or have I missed something? For eBGP peerings we require the next-hop so we have annotated it as mandatory. We don't yet have a way of annotating a parameter as conditionally mandatory. Even worse at the moment if you configure an IPv6 only peering its still necessary to provide an IPv4 nexthop. This issue has come up a number of times recently and we have been trying to figure out how the condition should be specified. Your example is particularly interesting as it would require us to test the local as and the peer as for inequality before demanding a next-hop. Kristian> There's also a small annoying bug. Try doing: create Kristian> protocols bgp set protocols bgp bgp-id 1.1.1.1 set Kristian> protocols bgp local-as 112 commit (everthings fine) create Kristian> protocols bgp peer commit (it will complain over Kristian> missing arguments) now fill in the mising stuff, local-ip, Kristian> next-hop and as. Try to commit, at least for me it won't Kristian> work. It failed for me when the local-ip was an illegal value, which is very bad. It worked when the values were legal. Kristian> I also would like to rename 'protocols bgp peer Kristian> _as_' to 'peer-as' as it's not crystal clear as to what AS Kristian> (local/peer) 'as' is actually referring to. You may be right that peer-as would be clearer. We don't want to break existing configurations as soon as we have an aliasing story we can try and support both. Atanu. From kristian@juniks.net Sat Oct 15 10:01:12 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sat, 15 Oct 2005 11:01:12 +0200 Subject: [Xorp-hackers] BGP configuration In-Reply-To: <20051015085413.GA7368@juniks.net> References: <20051014234425.GC2660@juniks.net> <51313.1129351651@tigger.icir.org> <20051015085413.GA7368@juniks.net> Message-ID: <20051015090112.GC7368@juniks.net> On Fri, Oct 14, 2005 at 09:47:31PM -0700, Atanu Ghosh wrote: > Kristian> I have been labbing with BGP now for a while and I have a > Kristian> few thoughts about it... You have to configure local-ip, > Kristian> this is something I like, it forces the user to pick a > Kristian> interface, be it a loopback for iBGP or a fixed interface > Kristian> for eBGP. But the next-hop? Why on earth do I need to set > Kristian> a next-hop? Alright if it's an option but it shouldn't be > Kristian> required or have I missed something? > > For eBGP peerings we require the next-hop so we have annotated it as > mandatory. We don't yet have a way of annotating a parameter as > conditionally mandatory. Even worse at the moment if you configure an > IPv6 only peering its still necessary to provide an IPv4 nexthop. This > issue has come up a number of times recently and we have been trying to > figure out how the condition should be specified. Your example is > particularly interesting as it would require us to test the local as and > the peer as for inequality before demanding a next-hop. Why is it necessary for eBGP? In my experience eBGP is seldom multihop and when it is I have never had to specify the next-hop. Can not such a value be calculated from the routing table? And IPv6, it's a bit confusing that one could actually specify both ipv4 and ipv6 next-hop addresses for one peer. Is it possible to have "next-hop" receive both v4 and v6 addresses? Last, isn't "local-ip-address" or "local-address" more correct than "local-ip" as "ip" is a protocol and we're talking about an ip address here. It's just a minor ... ;) > Kristian> There's also a small annoying bug. Try doing: create > Kristian> protocols bgp set protocols bgp bgp-id 1.1.1.1 set > Kristian> protocols bgp local-as 112 commit (everthings fine) create > Kristian> protocols bgp peer commit (it will complain over > Kristian> missing arguments) now fill in the mising stuff, local-ip, > Kristian> next-hop and as. Try to commit, at least for me it won't > Kristian> work. > > It failed for me when the local-ip was an illegal value, which is very > bad. It worked when the values were legal. Strange, it does not for me. It complains on some resolving error. I can't reproduce now as I lack a computer to run XORP but I shall try as soon as I get home. > > Kristian> I also would like to rename 'protocols bgp peer > Kristian> _as_' to 'peer-as' as it's not crystal clear as to what AS > Kristian> (local/peer) 'as' is actually referring to. > > You may be right that peer-as would be clearer. We don't want to break > existing configurations as soon as we have an aliasing story we can try > and support both. No offence here, but do you really think people are using XORP in production and we need to honour the old configuration? Perhaps I am wrong but I still find XORP to be in it's cradle and so making "drastic" changes like this should be no problem. It's better to do it now than later when people actually start using it. Kristian. From atanu@ICSI.Berkeley.EDU Sat Oct 15 19:24:59 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Sat, 15 Oct 2005 11:24:59 -0700 Subject: [Xorp-hackers] BGP configuration In-Reply-To: Message from Kristian Larsson of "Sat, 15 Oct 2005 11:01:12 +0200." <20051015090112.GC7368@juniks.net> Message-ID: <21929.1129400699@tigger.icir.org> Kristian> I have been labbing with BGP now for a while and I Kristian> have a few thoughts about it... You have to configure Kristian> local-ip, this is something I like, it forces the user to Kristian> pick a interface, be it a loopback for iBGP or a fixed Kristian> interface for eBGP. But the next-hop? Why on earth do I Kristian> need to set a next-hop? Alright if it's an option but it Kristian> shouldn't be required or have I missed something? >> For eBGP peerings we require the next-hop so we have annotated >> it as mandatory. We don't yet have a way of annotating a >> parameter as conditionally mandatory. Even worse at the moment if >> you configure an IPv6 only peering its still necessary to provide >> an IPv4 nexthop. This issue has come up a number of times >> recently and we have been trying to figure out how the condition >> should be specified. Your example is particularly interesting as >> it would require us to test the local as and the peer as for >> inequality before demanding a next-hop. Kristian> Why is it necessary for eBGP? In my experience eBGP is Kristian> seldom multihop and when it is I have never had to specify Kristian> the next-hop. Can not such a value be calculated from the Kristian> routing table? We wanted to provide maximum flexibility to the user by allowing her to select the next-hop value. I have just looked at the draft again and it does look like under certain circumstances we should be selecting the next-hop from the routing table. Kristian> And IPv6, it's a bit confusing that one could actually Kristian> specify both ipv4 and ipv6 next-hop addresses for one Kristian> peer. Is it possible to have "next-hop" receive both v4 Kristian> and v6 addresses? You missed my point, we have annotated the next-hop as mandatory therefore in cases where it is not used we still require it to be in the configuration. I cited the IPv6 case as an even more egregious example of the problem. There is a "next-hop6" parameter that takes the IPv6 next-hop address. Kristian> Last, isn't "local-ip-address" or "local-address" more Kristian> correct than "local-ip" as "ip" is a protocol and we're Kristian> talking about an ip address here. It's just a minor ... ;) You are probably right. Kristian> There's also a small annoying bug. Try doing: create Kristian> protocols bgp set protocols bgp bgp-id 1.1.1.1 set Kristian> protocols bgp local-as 112 commit (everthings fine) create Kristian> protocols bgp peer commit (it will complain over Kristian> missing arguments) now fill in the mising stuff, local-ip, Kristian> next-hop and as. Try to commit, at least for me it won't Kristian> work. >> It failed for me when the local-ip was an illegal value, which >> is very bad. It worked when the values were legal. Kristian> Strange, it does not for me. It complains on some Kristian> resolving error. I can't reproduce now as I lack a Kristian> computer to run XORP but I shall try as soon as I get Kristian> home. Okay. Kristian> I also would like to rename 'protocols bgp peer Kristian> _as_' to 'peer-as' as it's not crystal clear as to what AS Kristian> (local/peer) 'as' is actually referring to. >> You may be right that peer-as would be clearer. We don't want to >> break existing configurations as soon as we have an aliasing >> story we can try and support both. Kristian> No offence here, but do you really think people are using Kristian> XORP in production and we need to honour the old Kristian> configuration? Perhaps I am wrong but I still find XORP Kristian> to be in it's cradle and so making "drastic" changes like Kristian> this should be no problem. It's better to do it now than Kristian> later when people actually start using it. Making this change without aliasing is already going to be a pain for us. We have many config files, the regression tests all use this name, as well as embedded IMUNES configurations. There are often going to be times that we make a bad naming or syntax choice. Last time we made a major change we introduced a "%deprecated" keyword in order to help when configurations broke. I think that making the change with aliasing will allow us to deal with this and future naming issues. Atanu. From M.Handley@cs.ucl.ac.uk Sat Oct 15 21:44:43 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Sat, 15 Oct 2005 21:44:43 +0100 Subject: [Xorp-hackers] Rtrmgr start without config.boot In-Reply-To: <20051014231747.GA2660@juniks.net> References: <20051014231747.GA2660@juniks.net> Message-ID: <84a612dd0510151344o49bf4700m40218a5d575ab2f@mail.gmail.com> I looked at your patch. I think we need to discuss what it is we actually want. There are a number of reasons why the read_file might fail, including: - the file doesn't exist. - the file isn't readable. - the directory isn't executable. Do we want the rtrmgr to start in all three cases? I think the last two should probably be fatal errors, because something is badly broken, and you want to force the user to fix it. In the case of the file not being readable, there is also the possibility that it *is* writable. So continuing would be very weird in that case, as you'd be able to save without an error, but never able to load the config you saved. In the case where the file doesn't exist, should we create the file at this point? Then at least there is a config file that matches the running config. Or should we only do this on an explicit save? I think we should probably create it - best do that, rather than discover a permissions problem later when the user has typed in a long config. But what then should happen if the create failed? Probably we'd want a warning on the xorpsh when a new xorpsh first connects. Anyway, I'd like feedback on this before committing any changes. - Mark On 10/15/05, Kristian Larsson wrote: > Hey everybody :) > > Right now the rtrmgr won't start without a > configraution file and this doesn't go well with my > rtrmgr-should-always-start-no-matter-what-policy ;) > Seriously though, isn't a warning message enough? > I mean you touch the file and xorp starts, no one > bothers actually writing a correct configuration > file. > > I've created a bug and a patch for it on the > BugZilla for everyones evaluation :) > > Kristian. > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > From krn@krn.dk Sun Oct 16 12:55:07 2005 From: krn@krn.dk (Kristen Nielsen) Date: Sun, 16 Oct 2005 13:55:07 +0200 Subject: [Xorp-hackers] NAT support for XORP Message-ID: <43523F9B.1000508@krn.dk> Hi XORP-Hackers. Thank you for doing this great project - it really thrills me that an opensource router project has appeared and got this far already. I am a Graduate Computer Science student from Univesity of Copenhagen, who is looking into doing some work/implementation projects in XORP as a part of my next 1-2 projects and eventually for my final thesis. I am considering to implement a Network Address Translation (NAT) module to XORP, but as I understand it, it seems that I need to add functionality to the FEA module to be able to change IP-packets that flows through the router. Is there a design plan / roadmap / ideas / thoughts / ? for how the XORP project will handle implementation of functionality the requires tratment/changs of all packets that belongs to a trafficflow or to interfaces, that my NAT project can fit into or take into concideration? Also if sometime later Virtulisation of the XORP router e.g. with MPLS functionality will come up - as I see it the same functionality will be needed. I hope you will comment on this. Sincerely Mr. Kristen Nielsen Copenhagen, Denmark. krn@krn.dk From M.Handley@cs.ucl.ac.uk Sun Oct 16 18:01:07 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Sun, 16 Oct 2005 18:01:07 +0100 Subject: [Xorp-hackers] NAT support for XORP In-Reply-To: <43523F9B.1000508@krn.dk> References: <43523F9B.1000508@krn.dk> Message-ID: <84a612dd0510161001q24e22c66rec3855e7dcf99b1d@mail.gmail.com> I think that if the kernel has native NAT support, then XORP should be able to use it. But if it doesn't, then it would make sense doing NAT in the FEA. As the latter is the lowest common denominator, then it probably makes sense doing it first, but you'd really want to study NAT on several platforms with native implementations before getting started, just to make sure the FEA's API was suitably cross-platform. A good starting point would be to draft a .xif file for configuring the FEA to handle NAT, and discuss this on this list before starting coding. - Mark On 10/16/05, Kristen Nielsen wrote: > Hi XORP-Hackers. > > Thank you for doing this great project - it really thrills me that an > opensource router project has appeared and got this far already. > > I am a Graduate Computer Science student from Univesity of Copenhagen, > who is looking into doing some work/implementation projects in XORP as a > part of my next 1-2 projects and eventually for my final thesis. > > I am considering to implement a Network Address Translation (NAT) module > to XORP, but as I understand it, it seems that I need to add > functionality to the FEA module to be able to change IP-packets that > flows through the router. > > Is there a design plan / roadmap / ideas / thoughts / ? for how the XORP > project will handle implementation of functionality the requires > tratment/changs of all packets that belongs to a trafficflow or to > interfaces, that my NAT project can fit into or take into concideration? > > Also if sometime later Virtulisation of the XORP router e.g. with MPLS > functionality will come up - as I see it the same functionality will be > needed. > > I hope you will comment on this. > > Sincerely > Mr. Kristen Nielsen > Copenhagen, Denmark. > krn@krn.dk > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > From bms@spc.org Sun Oct 16 19:31:52 2005 From: bms@spc.org (Bruce M Simpson) Date: Sun, 16 Oct 2005 19:31:52 +0100 Subject: [Xorp-hackers] NAT support for XORP In-Reply-To: <43523F9B.1000508@krn.dk> References: <43523F9B.1000508@krn.dk> Message-ID: <20051016183152.GA13906@empiric.icir.org> On Sun, Oct 16, 2005 at 01:55:07PM +0200, Kristen Nielsen wrote: > I am considering to implement a Network Address Translation (NAT) module > to XORP, but as I understand it, it seems that I need to add > functionality to the FEA module to be able to change IP-packets that > flows through the router. One big problem with this is that it requires a means of intercepting network traffic such that the host's TCP/IP stack doesn't process it. libpcap, for example, won't let you do this, although we'd find libpcap functionality in the FEA very useful (for IS-IS and so on). On FreeBSD, this can be achieved with the use of a 'divert' socket, but once you go down this route, you may as well use kernel-space NAT anyway, in the form of pf, ipf or iptables on Linux. One possible place for you to start would be to work on a design for a Click-based NAT implementation, and the control plane functionality needed for this in the FEA. You may find the firewall driver code (fea/pa_*) useful here. Regards, BMS From pavlin@icir.org Sun Oct 16 21:50:32 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 16 Oct 2005 13:50:32 -0700 Subject: [Xorp-hackers] Rtrmgr start without config.boot In-Reply-To: Message from Mark Handley of "Sat, 15 Oct 2005 21:44:43 BST." <84a612dd0510151344o49bf4700m40218a5d575ab2f@mail.gmail.com> Message-ID: <200510162050.j9GKoWar099123@possum.icir.org> > I looked at your patch. I think we need to discuss what it is we actually want. > > There are a number of reasons why the read_file might fail, including: > > - the file doesn't exist. > - the file isn't readable. > - the directory isn't executable. > > Do we want the rtrmgr to start in all three cases? I think the last > two should probably be fatal errors, because something is badly > broken, and you want to force the user to fix it. In the case of the > file not being readable, there is also the possibility that it *is* > writable. So continuing would be very weird in that case, as you'd be > able to save without an error, but never able to load the config you > saved. > > In the case where the file doesn't exist, should we create the file at > this point? Then at least there is a config file that matches the > running config. Or should we only do this on an explicit save? I > think we should probably create it - best do that, rather than > discover a permissions problem later when the user has typed in a long > config. But what then should happen if the create failed? Probably > we'd want a warning on the xorpsh when a new xorpsh first connects. > > Anyway, I'd like feedback on this before committing any changes. In my testings, I need quite often to start the rtrmgr without any configuration. The simple solution I am using so far is to: ./xorp_rtrmgr -b empty.boot where "empty.boot" is an empty file. By doing something like this there is no ambiguity what is happening and no need to worry about the above semantics that Mark has analyzed very well. Pavlin > > - Mark > > On 10/15/05, Kristian Larsson wrote: > > Hey everybody :) > > > > Right now the rtrmgr won't start without a > > configraution file and this doesn't go well with my > > rtrmgr-should-always-start-no-matter-what-policy ;) > > Seriously though, isn't a warning message enough? > > I mean you touch the file and xorp starts, no one > > bothers actually writing a correct configuration > > file. > > > > I've created a bug and a patch for it on the > > BugZilla for everyones evaluation :) > > > > Kristian. > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers@icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin@icir.org Sun Oct 16 22:20:16 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 16 Oct 2005 14:20:16 -0700 Subject: [Xorp-hackers] show commands In-Reply-To: Message from Kristian Larsson of "Sat, 15 Oct 2005 01:28:06 +0200." <20051014232806.GB2660@juniks.net> Message-ID: <200510162120.j9GLKGCQ099338@possum.icir.org> > Is there a way to combine the "hardcoded" commands > withing cli.cc with the template files? If there is a way, it will probably require a major rewrite of the rtrmgr/xorpsh. > I would like to have a "show configuration" > command available from the operational mode, but > as it is right now it seems I must write a > separate program and call it with a few lines in a > template file, right? > It would be much easier if one could just call > show_func... I would argue that the users shouldn't be allowed to see the running configuration when they are in operational mode. Think of the security implications it may have if, say, the running configuration contains sensitive information (e.g., passwords). Remember that sometimes you may want to give "visitors" access to your router so people can run operational commands only, but you don't want to allow them to mess with your configuration (or even look at it). > Another thing on my mind; I know this has been > brought up before, I even think there is a > BugZilla entry for it, but shouldn't show commands > be available all the time? > If you start rtrmgr with a clean configuration > there are almost no show commands at all. This > confused me and I know it has others as well. If > the "%module bgp" line is removed, the bgp > commands appear and if run when bgp isn't started > you simply get a "No BGP exists" which IMHO is > much better than not seing the show command at > all. > > Other opinions? Why a command should be in the tree if it cannot do anything? This is a feature that was explicitly added to XORP, and my personal preference is to keep it. Simply removing the "%module foo" line is not the right thing because without that line the external command will be executed anyway, and the result may be unpredictable. If many other users also prefer to always have all commands in the tree and to see the "No foo exists" message, then ideally this feature should be configurable. Unfortunately, we don't have a mechanism (yet) to configure things like this. Pavlin From kristian@juniks.net Mon Oct 17 12:37:58 2005 From: kristian@juniks.net (Kristian Larsson) Date: Mon, 17 Oct 2005 13:37:58 +0200 Subject: [Xorp-hackers] show commands In-Reply-To: <200510162120.j9GLKGCQ099338@possum.icir.org> References: <20051014232806.GB2660@juniks.net> <200510162120.j9GLKGCQ099338@possum.icir.org> Message-ID: <20051017113758.GC1711@juniks.net> On Sun, Oct 16, 2005 at 02:20:16PM -0700, Pavlin Radoslavov wrote: > > Is there a way to combine the "hardcoded" commands > > withing cli.cc with the template files? > > If there is a way, it will probably require a major rewrite of the > rtrmgr/xorpsh. I was afraid of that. > > I would like to have a "show configuration" > > command available from the operational mode, but > > as it is right now it seems I must write a > > separate program and call it with a few lines in a > > template file, right? > > It would be much easier if one could just call > > show_func... > > I would argue that the users shouldn't be allowed to see the running > configuration when they are in operational mode. Think of the > security implications it may have if, say, the running configuration > contains sensitive information (e.g., passwords). > Remember that sometimes you may want to give "visitors" access to > your router so people can run operational commands only, but you > don't want to allow them to mess with your configuration (or even > look at it). I somewhat agree with you. Giving access to operational/configure mode is quite a crude way. A better way would be to allow/dissallow commands based on user but since it's sometime till where there I would agree that it's better to not have "show configuration" within the operational mode. > > Another thing on my mind; I know this has been > > brought up before, I even think there is a > > BugZilla entry for it, but shouldn't show commands > > be available all the time? > > If you start rtrmgr with a clean configuration > > there are almost no show commands at all. This > > confused me and I know it has others as well. If > > the "%module bgp" line is removed, the bgp > > commands appear and if run when bgp isn't started > > you simply get a "No BGP exists" which IMHO is > > much better than not seing the show command at > > all. > > > > Other opinions? > > Why a command should be in the tree if it cannot do anything? > This is a feature that was explicitly added to XORP, and my personal > preference is to keep it. It's probably most old habit. I'm used to having all the configuration commands available. "show bgp *" is not such a good example, a better one would be "show interfaces". It's always nice to have some of these show commands so that you can easily get a grip on the router. > Simply removing the "%module foo" line is not the right thing > because without that line the external command will be executed > anyway, and the result may be unpredictable. Ah. The external command would need some error handling, yes. > If many other users also prefer to always have all commands in the > tree and to see the "No foo exists" message, then ideally this > feature should be configurable. Unfortunately, we don't have a > mechanism (yet) to configure things like this. I have given it some thought, and I think you're right with a few exceptions such as the "show interfaces" command. What's your opinion on the "show interfaces" command? Kristian. From M.Handley@cs.ucl.ac.uk Mon Oct 17 20:39:26 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Mon, 17 Oct 2005 20:39:26 +0100 Subject: [Xorp-hackers] XORP Routing Policy paper Message-ID: <84a612dd0510171239k1af34548i6a37fc6c3eef0a65@mail.gmail.com> Andrea and I have written a paper that details the issues surrounding the design and implemenation of the routing policy mechanisms in XORP. A copy is here if you're interested in how this works: http://nrg.cs.ucl.ac.uk/mjh/tmp/policy.pdf Cheers, Mark From pavlin@icir.org Mon Oct 17 22:16:44 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 17 Oct 2005 14:16:44 -0700 Subject: [Xorp-hackers] show commands In-Reply-To: Message from Kristian Larsson of "Mon, 17 Oct 2005 13:37:58 +0200." <20051017113758.GC1711@juniks.net> Message-ID: <200510172116.j9HLGiX6028036@possum.icir.org> > > > Another thing on my mind; I know this has been > > > brought up before, I even think there is a > > > BugZilla entry for it, but shouldn't show commands > > > be available all the time? > > > If you start rtrmgr with a clean configuration > > > there are almost no show commands at all. This > > > confused me and I know it has others as well. If > > > the "%module bgp" line is removed, the bgp > > > commands appear and if run when bgp isn't started > > > you simply get a "No BGP exists" which IMHO is > > > much better than not seing the show command at > > > all. > > > > > > Other opinions? > > > > Why a command should be in the tree if it cannot do anything? > > This is a feature that was explicitly added to XORP, and my personal > > preference is to keep it. > It's probably most old habit. I'm used to having > all the configuration commands available. > "show bgp *" is not such a good example, a better > one would be "show interfaces". It's always nice > to have some of these show commands so that you > can easily get a grip on the router. > > > Simply removing the "%module foo" line is not the right thing > > because without that line the external command will be executed > > anyway, and the result may be unpredictable. > Ah. The external command would need some error > handling, yes. > > > If many other users also prefer to always have all commands in the > > tree and to see the "No foo exists" message, then ideally this > > feature should be configurable. Unfortunately, we don't have a > > mechanism (yet) to configure things like this. > I have given it some thought, and I think you're > right with a few exceptions such as the "show > interfaces" command. What's your opinion on the > "show interfaces" command? The "show interfaces" command obtains the information from the FEA (to be more specific, from the module named "interface" that is inside the FEA), hence if the FEA is not running the "show interfaces" command won't be there. Practically all XORP modules depend (directly or indirectly) on the "interface" module inside the FEA so the "show interfaces" command should be almost always there. Only if you are running XORP with an empty configuration for example, then you won't see that command. Pavlin From kristian@juniks.net Sun Oct 23 14:52:28 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sun, 23 Oct 2005 15:52:28 +0200 Subject: [Xorp-hackers] show commands In-Reply-To: <200510172116.j9HLGiX6028036@possum.icir.org> References: <20051017113758.GC1711@juniks.net> <200510172116.j9HLGiX6028036@possum.icir.org> Message-ID: <20051023135228.GA8522@juniks.net> On Mon, Oct 17, 2005 at 02:16:44PM -0700, Pavlin Radoslavov wrote: > > > > Another thing on my mind; I know this has been > > > > brought up before, I even think there is a > > > > BugZilla entry for it, but shouldn't show commands > > > > be available all the time? > > > > If you start rtrmgr with a clean configuration > > > > there are almost no show commands at all. This > > > > confused me and I know it has others as well. If > > > > the "%module bgp" line is removed, the bgp > > > > commands appear and if run when bgp isn't started > > > > you simply get a "No BGP exists" which IMHO is > > > > much better than not seing the show command at > > > > all. > > > > > > > > Other opinions? > > > > > > Why a command should be in the tree if it cannot do anything? > > > This is a feature that was explicitly added to XORP, and my personal > > > preference is to keep it. > > It's probably most old habit. I'm used to having > > all the configuration commands available. > > "show bgp *" is not such a good example, a better > > one would be "show interfaces". It's always nice > > to have some of these show commands so that you > > can easily get a grip on the router. > > > > > Simply removing the "%module foo" line is not the right thing > > > because without that line the external command will be executed > > > anyway, and the result may be unpredictable. > > Ah. The external command would need some error > > handling, yes. > > > > > If many other users also prefer to always have all commands in the > > > tree and to see the "No foo exists" message, then ideally this > > > feature should be configurable. Unfortunately, we don't have a > > > mechanism (yet) to configure things like this. > > I have given it some thought, and I think you're > > right with a few exceptions such as the "show > > interfaces" command. What's your opinion on the > > "show interfaces" command? > > The "show interfaces" command obtains the information from the FEA > (to be more specific, from the module named "interface" that is > inside the FEA), hence if the FEA is not running the "show interfaces" > command won't be there. Practically all XORP modules depend > (directly or indirectly) on the "interface" module inside the FEA so > the "show interfaces" command should be almost always there. Only if > you are running XORP with an empty configuration for example, then > you won't see that command. This makes sense however: XORP> create fea XORP> commit XORP> exit Xorp> show interfaces Xorp> imho, "show interfaces" should list all interfaces available on the system, not just the ones configured. On systems such as FreeBSD where the interfaces are named fxp,em,xl and so forth it becomes a guess work to configure a interface. I understand from a development perspective it's much easier to just list the ones configured but I really think this should be changed to include all interfaces. Kristian. From pavlin@icir.org Sun Oct 23 16:29:35 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 23 Oct 2005 08:29:35 -0700 Subject: [Xorp-hackers] show commands In-Reply-To: Message from Kristian Larsson of "Sun, 23 Oct 2005 15:52:28 +0200." <20051023135228.GA8522@juniks.net> Message-ID: <200510231529.j9NFTZ5q058518@possum.icir.org> > > The "show interfaces" command obtains the information from the FEA > > (to be more specific, from the module named "interface" that is > > inside the FEA), hence if the FEA is not running the "show interfaces" > > command won't be there. Practically all XORP modules depend > > (directly or indirectly) on the "interface" module inside the FEA so > > the "show interfaces" command should be almost always there. Only if > > you are running XORP with an empty configuration for example, then > > you won't see that command. > This makes sense however: > XORP> create fea > XORP> commit > XORP> exit > Xorp> show interfaces > Xorp> > > imho, "show interfaces" should list all interfaces > available on the system, not just the ones > configured. On systems such as FreeBSD where the > interfaces are named fxp,em,xl and so forth it > becomes a guess work to configure a interface. > I understand from a development perspective it's > much easier to just list the ones configured but I > really think this should be changed to include all > interfaces. I would argue that the existing "show interfaces" command should show only the interfaces that XORP knows about, but yes I agree that there should be a separate command to show all available interfaces on the system. Please add this feature as a bugzilla entry. Pavlin From kristian@juniks.net Sun Oct 23 17:24:46 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sun, 23 Oct 2005 18:24:46 +0200 Subject: [Xorp-hackers] show commands In-Reply-To: <200510231529.j9NFTZ5q058518@possum.icir.org> References: <20051023135228.GA8522@juniks.net> <200510231529.j9NFTZ5q058518@possum.icir.org> Message-ID: <20051023162445.GB22900@juniks.net> On Sun, Oct 23, 2005 at 08:29:35AM -0700, Pavlin Radoslavov wrote: > > > The "show interfaces" command obtains the information from the FEA > > > (to be more specific, from the module named "interface" that is > > > inside the FEA), hence if the FEA is not running the "show interfaces" > > > command won't be there. Practically all XORP modules depend > > > (directly or indirectly) on the "interface" module inside the FEA so > > > the "show interfaces" command should be almost always there. Only if > > > you are running XORP with an empty configuration for example, then > > > you won't see that command. > > This makes sense however: > > XORP> create fea > > XORP> commit > > XORP> exit > > Xorp> show interfaces > > Xorp> > > > > imho, "show interfaces" should list all interfaces > > available on the system, not just the ones > > configured. On systems such as FreeBSD where the > > interfaces are named fxp,em,xl and so forth it > > becomes a guess work to configure a interface. > > I understand from a development perspective it's > > much easier to just list the ones configured but I > > really think this should be changed to include all > > interfaces. > > I would argue that the existing "show interfaces" command should > show only the interfaces that XORP knows about, but yes I agree that > there should be a separate command to show all available interfaces > on the system. I would argue to the contrary, the "show interfaces" should show all the interfaces on the system. I imagine our different opinions spring from our different use of XORP. I would use XORP mainly in a production network where it makes sense to see all interfaces. On the other hand in a lab setup with click you may have dozens of interfaces and showing all interfaces would only clutter the output. I am also arguing that xorp should adept the behaviour of other common router systems such as IOS and JunOS, both which behave the way I argue. Compile-time option? Perhaps a little flag saying if the interface has been configured in XORP or not? Anyone else care to comment? :) >Please add this feature as a bugzilla entry. There is already such a bug registerd - BG237. Kristian. From deathdealer@gmx.net Sun Oct 23 17:48:32 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Sun, 23 Oct 2005 18:48:32 +0200 Subject: AW: [Xorp-hackers] show commands In-Reply-To: <20051023162445.GB22900@juniks.net> Message-ID: <000001c5d7f1$9d0248f0$1608000a@dedus737> > Compile-time option? > Perhaps a little flag saying if the interface has > been configured in XORP or not? Yes I would argue in the same manner for production it would Be useful to see all interfaces in the system. I think it would be nice to have something like a private config, Witch define such things like: show all interfaces, interface naming convetions, and such things witch "should/could" not be changed during "runtime" ;-) Regards Patrick Preuss From kristian@juniks.net Sun Oct 23 20:14:01 2005 From: kristian@juniks.net ('Kristian Larsson') Date: Sun, 23 Oct 2005 21:14:01 +0200 Subject: [Xorp-hackers] show commands In-Reply-To: <000001c5d7f1$9d0248f0$1608000a@dedus737> References: <20051023162445.GB22900@juniks.net> <000001c5d7f1$9d0248f0$1608000a@dedus737> Message-ID: <20051023191401.GC22900@juniks.net> On Sun, Oct 23, 2005 at 06:48:32PM +0200, Patrick Preuss wrote: > > Compile-time option? > > Perhaps a little flag saying if the interface has > > been configured in XORP or not? > > Yes I would argue in the same manner for production it would > Be useful to see all interfaces in the system. > > I think it would be nice to have something like a private config, > Witch define such things like: show all interfaces, interface naming > convetions, and such things witch "should/could" not be changed during > "runtime" I beleive the easiest thing would be compile time options. In my environment I would compile XORP on one machine and then distribute it to all my routers. By setting the appropriate compile-options I can affect the behaviour of XORP and being compile-time options I'm sure they won't change thus reducing number of things that can go wrong on my production machines. Introducing a secondary configuration file increases the complexity quite a lot imho. Kristian. From kristian@juniks.net Mon Oct 24 13:11:37 2005 From: kristian@juniks.net ('Kristian Larsson') Date: Mon, 24 Oct 2005 14:11:37 +0200 Subject: [Xorp-hackers] show commands In-Reply-To: <000a01c5d85f$58df5050$2351bb50@dedus737> References: <20051023191401.GC22900@juniks.net> <000a01c5d85f$58df5050$2351bb50@dedus737> Message-ID: <20051024121137.GA16874@juniks.net> On Mon, Oct 24, 2005 at 07:54:00AM +0200, Patrick Preuss wrote: > > Hello Kristian, > > > I beleive the easiest thing would be compile time > > options. In my environment I would compile XORP on > > one machine and then distribute it to all my > > routers. By setting the appropriate > > compile-options I can affect the behaviour of > > XORP and being compile-time options I'm sure they > > won't change thus reducing number of things that > > can go wrong on my production machines. > > > > Introducing a secondary configuration file > > increases the complexity quite a lot imho. > > You are right it would increase the complexity a lot, but what I want to say > > It would be nice to have a switch, maybe commandline, with witch you can > chose the behavior, so you can use the same binarys for production and > testing, it would ensure if you have problems with a version it will be the > same version;-) I don't beleive these kind of options would change between your production boxes and test boxes. Essentially a testing machine is exactly the same as a production machine though it's not connected to anything important. Then there's the lab machines with which you might want to simulate whole networks using Click/IMUNES, these would need a totally different version. Although I see your point I still hold on to my previous opinion. Compile-time options are easy to implement and will cover the mayority of scenarios. Kristian. From deathdealer@gmx.net Mon Oct 24 16:34:56 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Mon, 24 Oct 2005 17:34:56 +0200 Subject: [Xorp-hackers] show commands In-Reply-To: <20051024121137.GA16874@juniks.net> Message-ID: <001601c5d8b0$7ede2aa0$2d2cbb50@dedus737> > I don't beleive these kind of options would change > between your production boxes and test boxes. > Essentially a testing machine is exactly the same > as a production machine though it's not connected > to anything important. > > Then there's the lab machines with which you might > want to simulate whole networks using > Click/IMUNES, these would need a totally different > version. > > Although I see your point I still hold on to my > previous opinion. Compile-time options are easy to > implement and will cover the mayority of > scenarios. Yes you are right it would cover most of the scenarios, And it would relative easy to manage. Regards Patrick Preuss From caddisconsulting@yahoo.com Mon Oct 24 21:34:29 2005 From: caddisconsulting@yahoo.com (Mike Horn) Date: Mon, 24 Oct 2005 14:34:29 -0600 Subject: [Xorp-hackers] Show commands In-Reply-To: <200510241901.j9OJ1ZSt011300@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200510242036.j9OKacPS053326@wyvern.icir.org> Hi, I have been wathcing the ideas float around about the interface configurations. Quick question, if you do a compile time option would that require you to recompile the software each time you added an interface to an existing configuration? -mike -----Original Message----- From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On Behalf Of xorp-hackers-request@icir.org Sent: Monday, October 24, 2005 1:02 PM To: xorp-hackers@icir.org Subject: [Bulk] Xorp-hackers digest, Vol 1 #219 - 3 msgs Send Xorp-hackers mailing list submissions to xorp-hackers@icir.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers or, via email, send a message with subject or body 'help' to xorp-hackers-request@icir.org You can reach the person managing the list at xorp-hackers-admin@icir.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Xorp-hackers digest..." Today's Topics: 1. Re: show commands ('Kristian Larsson') 2. Re: show commands ('Kristian Larsson') 3. show commands (Patrick Preuss) --__--__-- Message: 1 Date: Sun, 23 Oct 2005 21:14:01 +0200 From: "'Kristian Larsson'" To: Patrick Preuss Cc: xorp-hackers@xorp.org Subject: Re: [Xorp-hackers] show commands On Sun, Oct 23, 2005 at 06:48:32PM +0200, Patrick Preuss wrote: > > Compile-time option? > > Perhaps a little flag saying if the interface has been configured in > > XORP or not? > > Yes I would argue in the same manner for production it would Be useful > to see all interfaces in the system. > > I think it would be nice to have something like a private config, > Witch define such things like: show all interfaces, interface naming > convetions, and such things witch "should/could" not be changed during > "runtime" I beleive the easiest thing would be compile time options. In my environment I would compile XORP on one machine and then distribute it to all my routers. By setting the appropriate compile-options I can affect the behaviour of XORP and being compile-time options I'm sure they won't change thus reducing number of things that can go wrong on my production machines. Introducing a secondary configuration file increases the complexity quite a lot imho. Kristian. --__--__-- Message: 2 Date: Mon, 24 Oct 2005 14:11:37 +0200 From: "'Kristian Larsson'" To: Patrick Preuss Cc: xorp-hackers@xorp.org Subject: Re: [Xorp-hackers] show commands On Mon, Oct 24, 2005 at 07:54:00AM +0200, Patrick Preuss wrote: > > Hello Kristian, > > > I beleive the easiest thing would be compile time options. In my > > environment I would compile XORP on one machine and then distribute > > it to all my routers. By setting the appropriate compile-options I > > can affect the behaviour of XORP and being compile-time options I'm > > sure they won't change thus reducing number of things that can go > > wrong on my production machines. > > > > Introducing a secondary configuration file increases the complexity > > quite a lot imho. > > You are right it would increase the complexity a lot, but what I want > to say > > It would be nice to have a switch, maybe commandline, with witch you > can chose the behavior, so you can use the same binarys for production > and testing, it would ensure if you have problems with a version it > will be the same version;-) I don't beleive these kind of options would change between your production boxes and test boxes. Essentially a testing machine is exactly the same as a production machine though it's not connected to anything important. Then there's the lab machines with which you might want to simulate whole networks using Click/IMUNES, these would need a totally different version. Although I see your point I still hold on to my previous opinion. Compile-time options are easy to implement and will cover the mayority of scenarios. Kristian. --__--__-- Message: 3 From: "Patrick Preuss" To: "'Kristian Larsson'" Cc: Subject: [Xorp-hackers] show commands Date: Mon, 24 Oct 2005 17:34:56 +0200 > I don't beleive these kind of options would change between your > production boxes and test boxes. > Essentially a testing machine is exactly the same as a production > machine though it's not connected to anything important. > > Then there's the lab machines with which you might want to simulate > whole networks using Click/IMUNES, these would need a totally > different version. > > Although I see your point I still hold on to my previous opinion. > Compile-time options are easy to implement and will cover the mayority > of scenarios. Yes you are right it would cover most of the scenarios, And it would relative easy to manage. Regards Patrick Preuss --__--__-- _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers End of Xorp-hackers Digest From kristian@juniks.net Mon Oct 24 22:05:08 2005 From: kristian@juniks.net (Kristian Larsson) Date: Mon, 24 Oct 2005 23:05:08 +0200 Subject: [Xorp-hackers] Show commands In-Reply-To: <200510242036.j9OKacPS053326@wyvern.icir.org> References: <200510241901.j9OJ1ZSt011300@fruitcake.ICSI.Berkeley.EDU> <200510242036.j9OKacPS053326@wyvern.icir.org> Message-ID: <20051024210507.GA29500@juniks.net> On Mon, Oct 24, 2005 at 02:34:29PM -0600, Mike Horn wrote: > Hi, > > I have been wathcing the ideas float around about the interface > configurations. Quick question, if you do a compile time option would that > require you to recompile the software each time you added an interface to an > existing configuration? No it would not. It would require you to recompile if you would like to change the behaviour of xorp. In this case it would mean that if by default xorp does not show all interfaces and you wanted it to you would have to recompile xorp. Now if you would like to go back and not show all interfaces you would need to recompile xorp again. People often have a preference and so would most oftenly not need to recompile. One thing which we should keep in mind though is that unices with binary distribution will not allow people such freedom, but perhaps this can be sacrificed as "powerusers" often choose source tarballs anyway. Kristian. > -mike > > -----Original Message----- > From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On > Behalf Of xorp-hackers-request@icir.org > Sent: Monday, October 24, 2005 1:02 PM > To: xorp-hackers@icir.org > Subject: [Bulk] Xorp-hackers digest, Vol 1 #219 - 3 msgs > > Send Xorp-hackers mailing list submissions to > xorp-hackers@icir.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > or, via email, send a message with subject or body 'help' to > xorp-hackers-request@icir.org > > You can reach the person managing the list at > xorp-hackers-admin@icir.org > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of Xorp-hackers digest..." > > > Today's Topics: > > 1. Re: show commands ('Kristian Larsson') > 2. Re: show commands ('Kristian Larsson') > 3. show commands (Patrick Preuss) > > --__--__-- > > Message: 1 > Date: Sun, 23 Oct 2005 21:14:01 +0200 > From: "'Kristian Larsson'" > To: Patrick Preuss > Cc: xorp-hackers@xorp.org > Subject: Re: [Xorp-hackers] show commands > > On Sun, Oct 23, 2005 at 06:48:32PM +0200, Patrick Preuss wrote: > > > Compile-time option? > > > Perhaps a little flag saying if the interface has been configured in > > > XORP or not? > > > > Yes I would argue in the same manner for production it would Be useful > > to see all interfaces in the system. > > > > I think it would be nice to have something like a private config, > > Witch define such things like: show all interfaces, interface naming > > convetions, and such things witch "should/could" not be changed during > > "runtime" > I beleive the easiest thing would be compile time options. In my environment > I would compile XORP on one machine and then distribute it to all my > routers. By setting the appropriate compile-options I can affect the > behaviour of XORP and being compile-time options I'm sure they won't change > thus reducing number of things that can go wrong on my production machines. > > Introducing a secondary configuration file increases the complexity quite a > lot imho. > > Kristian. > > --__--__-- > > Message: 2 > Date: Mon, 24 Oct 2005 14:11:37 +0200 > From: "'Kristian Larsson'" > To: Patrick Preuss > Cc: xorp-hackers@xorp.org > Subject: Re: [Xorp-hackers] show commands > > On Mon, Oct 24, 2005 at 07:54:00AM +0200, Patrick Preuss wrote: > > > > Hello Kristian, > > > > > I beleive the easiest thing would be compile time options. In my > > > environment I would compile XORP on one machine and then distribute > > > it to all my routers. By setting the appropriate compile-options I > > > can affect the behaviour of XORP and being compile-time options I'm > > > sure they won't change thus reducing number of things that can go > > > wrong on my production machines. > > > > > > Introducing a secondary configuration file increases the complexity > > > quite a lot imho. > > > > You are right it would increase the complexity a lot, but what I want > > to say > > > > It would be nice to have a switch, maybe commandline, with witch you > > can chose the behavior, so you can use the same binarys for production > > and testing, it would ensure if you have problems with a version it > > will be the same version;-) > I don't beleive these kind of options would change between your production > boxes and test boxes. > Essentially a testing machine is exactly the same as a production machine > though it's not connected to anything important. > > Then there's the lab machines with which you might want to simulate whole > networks using Click/IMUNES, these would need a totally different version. > > Although I see your point I still hold on to my previous opinion. > Compile-time options are easy to implement and will cover the mayority of > scenarios. > > Kristian. > > --__--__-- > > Message: 3 > From: "Patrick Preuss" > To: "'Kristian Larsson'" > Cc: > Subject: [Xorp-hackers] show commands > Date: Mon, 24 Oct 2005 17:34:56 +0200 > > > > > I don't beleive these kind of options would change between your > > production boxes and test boxes. > > Essentially a testing machine is exactly the same as a production > > machine though it's not connected to anything important. > > > > Then there's the lab machines with which you might want to simulate > > whole networks using Click/IMUNES, these would need a totally > > different version. > > > > Although I see your point I still hold on to my previous opinion. > > Compile-time options are easy to implement and will cover the mayority > > of scenarios. > > Yes you are right it would cover most of the scenarios, And it would > relative easy to manage. > > Regards > Patrick Preuss > > > > > --__--__-- > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > End of Xorp-hackers Digest > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From doll@tm.uka.de Tue Oct 25 09:29:54 2005 From: doll@tm.uka.de (Mark Doll) Date: Tue, 25 Oct 2005 10:29:54 +0200 Subject: [Xorp-hackers] bool SelectorList::Node::is_empty() Message-ID: <435DED02.6060607@tm.uka.de> This function is defined in ~/libxorp/selector.cc:117 as inline bool SelectorList::Node::is_empty() { return (_mask[SEL_RD_IDX] == _mask[SEL_WR_IDX] == _mask[SEL_EX_IDX] == 0); } Shoudn't the return statement be return (_mask[SEL_RD_IDX] == 0 && _mask[SEL_WR_IDX] == 0 && _mask[SEL_EX_IDX] == 0); because i. e. 0 == 1 == 2 == 0 returns true, too? Regards, Mark. From pavlin@icir.org Tue Oct 25 18:22:18 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 25 Oct 2005 10:22:18 -0700 Subject: [Xorp-hackers] bool SelectorList::Node::is_empty() In-Reply-To: Message from Mark Doll of "Tue, 25 Oct 2005 10:29:54 +0200." <435DED02.6060607@tm.uka.de> Message-ID: <200510251722.j9PHMINH002480@possum.icir.org> > This function is defined in ~/libxorp/selector.cc:117 as > > inline bool > SelectorList::Node::is_empty() > { > return (_mask[SEL_RD_IDX] == _mask[SEL_WR_IDX] == _mask[SEL_EX_IDX] == 0); > } > > Shoudn't the return statement be > > return (_mask[SEL_RD_IDX] == 0 && _mask[SEL_WR_IDX] == 0 && _mask[SEL_EX_IDX] == 0); > > because i. e. 0 == 1 == 2 == 0 returns true, too? Yes, this is a bug which is now double-checked with "gmake check" and is corrected in CVS. Thanks for the catch! Pavlin P.S. I did some "egrep"-bases search for similar bugs, but seems like there aren't any other. From pavlin@icir.org Thu Oct 27 07:46:53 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 26 Oct 2005 23:46:53 -0700 Subject: WG: [Xorp-hackers] Bugzilla #161 In-Reply-To: Message from "Patrick Preuss" of "Tue, 06 Sep 2005 18:47:15 +0200." <200509061647.j86GloPw006084@wyvern.icir.org> Message-ID: <200510270646.j9R6krGT043480@possum.icir.org> [Note: a reply to an 1.5 month old email] > And at last I think it is not optimal to determine the protocol from witch a > > Route was learn by the admin distance, there should be a sepperate field, > because in production environment sometimes you have the need to change the > ad for a protocol when you transit from a protocol to another. And If xorp > Should support more then one vrf, or mpls, more then one ospf daemon there > Should be a way to decide from witch we have learned the route. The issue is now fixed in CVS, so the "show_routes" operational command receives from RIB the protocol-origin for each route rather than using a hackish mechanism to guess it. Also, note that now the "show routes" output format has changed a bit to accomodate the extra information (the admin distance). Thanks for pointing the problem, Pavlin From kristian@juniks.net Thu Oct 27 19:34:18 2005 From: kristian@juniks.net (Kristian Larsson) Date: Thu, 27 Oct 2005 20:34:18 +0200 Subject: [Xorp-hackers] Re: [Xorp-users] "Gunmeetsingh Nagpal": Does Xorp Support Solaris Platform? In-Reply-To: <200510271615.j9RGF7nM048912@possum.icir.org> References: <200510271615.j9RGF7nM048912@possum.icir.org> Message-ID: <20051027183418.GD3639@juniks.net> I could setup a Solaris box over the weekend. Kristian. On Thu, Oct 27, 2005 at 09:15:07AM -0700, Pavlin Radoslavov wrote: > [Note: email forwarded to xorp-users@xorp.org because it is the > right ML for such questions]. > > Currently XORP doesn't support Solaris, but we are interested in > having it working on that OS. > > Has anyone succeeded or at least tried building XORP on Solaris? > If there were compilation issues, obtaining a temporary login > account on a Solaris box to fix those issues is always welcome :) > > Pavlin > > ------- Forwarded Message > Subject: Does Xorp Support Solaris Platform? > Date: Thu, 27 Oct 2005 08:29:42 -0700 > Message-ID: <69B4FF51CCC44540A75309838116485BA4E640@roamexchange.mobileum.com> > From: "Gunmeetsingh Nagpal" > > - ------_=_NextPart_001_01C5DB0B.4072EDD5 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hi > =20 > I am interested in using Xorp . Can anyone confirm me if Xorp support = > Solaris Platform .=20 > =20 > thanks & regards > Gunmeet > > - ------_=_NextPart_001_01C5DB0B.4072EDD5-- > > ------- End of Forwarded Message > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From wxf@csnet1.cs.tsinghua.edu.cn Fri Oct 28 17:23:39 2005 From: wxf@csnet1.cs.tsinghua.edu.cn (Melvin) Date: Sat, 29 Oct 2005 0:23:39 +0800 Subject: [Xorp-hackers] XORP PIMSM6 and IPv6 multicast forwarding patch Message-ID: <200510281623.j9SGNhu1037690@wyvern.icir.org> Hi, all I Tried this with XORP but it looks like does not work. There is already IPv6 multicast forwarding patch for the Linux kernel (http://clarinet.u-strasbg.fr/~hoerdt/linux_ipv6_mforwarding/) The error message is "adopt_mrouter_socket() failed: IPv6 multicast routing not supported" in xorp/fea/mfea_mrouter.cc line 419( I used Xorp 1.1 tarball) as follows: #ifndef HAVE_IPV6_MULTICAST_ROUTING XLOG_ERROR("adopt_mrouter_socket() failed: " "IPv6 multicast routing not supported"); return (XORP_ERROR); #else blabla.... HAVE_IPV6_MULTICAST_ROUTING is not defined. Any hint on this? What is the best place should I define this? Any other similar defination? Thanks in advance. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Melvin ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡wxf@csnet1.cs.tsinghua.edu.cn ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-10-29 From pavlin@icir.org Fri Oct 28 18:28:27 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 28 Oct 2005 10:28:27 -0700 Subject: [Xorp-hackers] XORP PIMSM6 and IPv6 multicast forwarding patch In-Reply-To: Message from "Melvin" of "Sat, 29 Oct 2005 00:23:39 +0800." <200510281623.j9SGNhu1037690@wyvern.icir.org> Message-ID: <200510281728.j9SHSRFx079870@possum.icir.org> > Hi, all > > I Tried this with XORP but it looks like does not work. > > There is already IPv6 multicast forwarding patch for the Linux kernel > (http://clarinet.u-strasbg.fr/~hoerdt/linux_ipv6_mforwarding/) > > The error message is "adopt_mrouter_socket() failed: IPv6 multicast routing not supported" in xorp/fea/mfea_mrouter.cc line 419( I used Xorp 1.1 tarball) as follows: > #ifndef HAVE_IPV6_MULTICAST_ROUTING > XLOG_ERROR("adopt_mrouter_socket() failed: " > "IPv6 multicast routing not supported"); > return (XORP_ERROR); > #else > blabla.... > > HAVE_IPV6_MULTICAST_ROUTING is not defined. Any hint on this? > What is the best place should I define this? > Any other similar defination? The ./configure script should detect whether the system has IPv6 multicast forwarding support and it will #define HAVE_IPV6_MULTICAST_ROUTING if detected. I think that the particular test for multicast routing support (defined in config/acipv6.m4) does not work for Linux. To fix the test, could you try to compile the following program. If it fails, please let me know the particular error message and I will try to fix it. Quite likely the failure would be because of some additional header files that should be included. Also, please double-check that in your config.h HAVE_IPV6 and HAVE_IPV6_MULTICAST are defined to 1. Pavlin /*****************************/ #include #include #include #include /* #include */ #include /* #include */ /* #include */ #include int main() { int dummy = 0; /* Dummy integer values that must be defined in some of the header files */ dummy += IPPROTO_ICMPV6; dummy += MRT6_INIT; dummy += MRT6_ADD_MIF; dummy += MRT6_DEL_MIF; dummy += MRT6_ADD_MFC; dummy += MRT6_DEL_MFC; dummy += MRT6MSG_NOCACHE; dummy += MRT6MSG_WRONGMIF; dummy += MRT6MSG_WHOLEPKT; #ifndef SIOCGETSGCNT_IN6 #error Missing SIOCGETSGCNT_IN6 #endif #ifndef SIOCGETMIFCNT_IN6 #error Missing SIOCGETMIFCNT_IN6 #endif exit (0); } /*****************************/ From wxf@csnet1.cs.tsinghua.edu.cn Sat Oct 29 10:20:15 2005 From: wxf@csnet1.cs.tsinghua.edu.cn (Melvin) Date: Sat, 29 Oct 2005 17:20:15 +0800 Subject: [Xorp-hackers] Re: XORP PIMSM6 and IPv6 multicast forwarding patch Message-ID: <200510290917.j9T9HOdd047477@wyvern.icir.org> This is a multi-part message in MIME format. --=====001_Dragon424706684415_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi,Pavlin Thanks for your quick response! You are right, I did the compile check on my system and at first it failed. Later on when i copy the mroute6.h into /usr/include/linux where IPv4 mroute.h exists.Then everything is OK (No message when compile). I confirm that HAVE_IPV6 and HAVE_IPV6_MULTICAST are defined to 1 in myconfig.h . Looks like I have to wait your correctness. FYI only: The mroute6.h is not in the right place. I did compile a new kernel on RH9(2.4.20-8) to upgrade it to Linux kernel 2.6.7 as the multicast forwarding patch required. The file still stay in the place where new kernel source files and didnot installed in! When I force the HAVE_IPV6_MULTICAST_ROUTING to 1, gmake failed with many message related. See attachement. Also tried renamed the mroute6.h to netinet6/ip6_mroute.h but failed gmake too. The error message is icmp6_filter struct redefination or some kind of info(caused by the HAVE_NETINET6_IP6_MROUTE_H some where) Thank you for your kindly help. I will keep you informed if I met any problem. Melvin --=====001_Dragon424706684415_===== Content-Type: application/octet-stream; name="testmsg.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="testmsg.txt" L2Jpbi9zaCAuLi9saWJ0b29sIC0tbW9kZT1jb21waWxlIGcrKyAtREhBVkVfQ09ORklHX0ggLUku IC1JLiAtSS4uIC1JLi4gICAgLWcgLVcgLVdhbGwgLVd3cml0ZS1zdHJpbmdzIC1XY2FzdC1xdWFs IC1XZXJyb3IgLVdwb2ludGVyLWFyaXRoIC1XY2FzdC1hbGlnbiAtV3N0cmljdC1wcm90b3R5cGVz IC1Xb3ZlcmxvYWRlZC12aXJ0dWFsIC1XdHJhZGl0aW9uYWwgLWZ0ZW1wbGF0ZS1kZXB0aC0yMiAt cGlwZSAtYyAtbyBtZmVhX21yb3V0ZXIubG8gYHRlc3QgLWYgbWZlYV9tcm91dGVyLmNjIHx8IGVj aG8gJy4vJ2BtZmVhX21yb3V0ZXIuY2MKZysrIC1ESEFWRV9DT05GSUdfSCAtSS4gLUkuIC1JLi4g LUkuLiAtZyAtVyAtV2FsbCAtV3dyaXRlLXN0cmluZ3MgLVdjYXN0LXF1YWwgLVdlcnJvciAtV3Bv aW50ZXItYXJpdGggLVdjYXN0LWFsaWduIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdvdmVybG9hZGVk LXZpcnR1YWwgLVd0cmFkaXRpb25hbCAtZnRlbXBsYXRlLWRlcHRoLTIyIC1waXBlIC1jIG1mZWFf bXJvdXRlci5jYyAtTVQgbWZlYV9tcm91dGVyLmxvIC1NRCAtTVAgLU1GIC5kZXBzL21mZWFfbXJv dXRlci5UUGxvIC1vIG1mZWFfbXJvdXRlci5vCkluIGZpbGUgaW5jbHVkZWQgZnJvbSBtZmVhX21y b3V0ZXIuY2M6NTc6Cm1mZWFfb3NkZXAuaGg6MTQwOjQ6ICNlcnJvciAiTUZFQSBtZXNzYWdlIGhh bmRsaW5nIG5lZWRzIGZpeCwgYmVjYXVzZSBJR01QTVNHX05PQ0FDSEUgIT0gTVJUNk1TR19OT0NB Q0hFIgptZmVhX29zZGVwLmhoOjE0NDo0OiAjZXJyb3IgIk1GRUEgbWVzc2FnZSBoYW5kbGluZyBu ZWVkcyBmaXgsIGJlY2F1c2UgSUdNUE1TR19XUk9OR1ZJRiAhPSBNUlQ2TVNHX1dST05HTUlGIgpt ZmVhX29zZGVwLmhoOjE0ODo0OiAjZXJyb3IgIk1GRUEgbWVzc2FnZSBoYW5kbGluZyBuZWVkcyBm aXgsIGJlY2F1c2UgSUdNUE1TR19XSE9MRVBLVCAhPSBNUlQ2TVNHX1dIT0xFUEtUIgptZmVhX21y b3V0ZXIuY2M6IEluIG1lbWJlciBmdW5jdGlvbiBgYm9vbAogICBNZmVhTXJvdXRlcjo6aGF2ZV9t dWx0aWNhc3Rfcm91dGluZzYoKSBjb25zdCc6Cm1mZWFfbXJvdXRlci5jYzozMDI6IGBNUlQ2X0lO SVQnIHVuZGVjbGFyZWQgKGZpcnN0IHVzZSB0aGlzIGZ1bmN0aW9uKQptZmVhX21yb3V0ZXIuY2M6 MzAyOiAoRWFjaCB1bmRlY2xhcmVkIGlkZW50aWZpZXIgaXMgcmVwb3J0ZWQgb25seSBvbmNlIGZv ciBlYWNoCiAgIGZ1bmN0aW9uIGl0IGFwcGVhcnMgaW4uKQptZmVhX21yb3V0ZXIuY2M6IEluIG1l bWJlciBmdW5jdGlvbiBgaW50IE1mZWFNcm91dGVyOjpzdG9wX21ydCgpJzoKbWZlYV9tcm91dGVy LmNjOjczMDogYE1SVDZfRE9ORScgdW5kZWNsYXJlZCAoZmlyc3QgdXNlIHRoaXMgZnVuY3Rpb24p Cm1mZWFfbXJvdXRlci5jYzogSW4gbWVtYmVyIGZ1bmN0aW9uIGBpbnQgTWZlYU1yb3V0ZXI6OnN0 YXJ0X3BpbSgpJzoKbWZlYV9tcm91dGVyLmNjOjc3ODogYE1SVDZfUElNJyB1bmRlY2xhcmVkIChm aXJzdCB1c2UgdGhpcyBmdW5jdGlvbikKbWZlYV9tcm91dGVyLmNjOiBJbiBtZW1iZXIgZnVuY3Rp b24gYGludCBNZmVhTXJvdXRlcjo6YWRkX211bHRpY2FzdF92aWYoc2hvcnQKICAgdW5zaWduZWQg aW50KSc6Cm1mZWFfbXJvdXRlci5jYzo5MDU6IGFnZ3JlZ2F0ZSBgbWlmNmN0bCBtYycgaGFzIGlu Y29tcGxldGUgdHlwZSBhbmQgY2Fubm90IGJlCiAgIGRlZmluZWQKbWZlYV9tcm91dGVyLmNjOjkx MTogYE1JRkZfUkVHSVNURVInIHVuZGVjbGFyZWQgKGZpcnN0IHVzZSB0aGlzIGZ1bmN0aW9uKQpt ZmVhX21yb3V0ZXIuY2M6OTE3OiBgTVJUNl9BRERfTUlGJyB1bmRlY2xhcmVkIChmaXJzdCB1c2Ug dGhpcyBmdW5jdGlvbikKbWZlYV9tcm91dGVyLmNjOiBJbiBtZW1iZXIgZnVuY3Rpb24gYGludAog ICBNZmVhTXJvdXRlcjo6ZGVsZXRlX211bHRpY2FzdF92aWYoc2hvcnQgdW5zaWduZWQgaW50KSc6 Cm1mZWFfbXJvdXRlci5jYzoxMDAzOiBhZ2dyZWdhdGUgYG1pZjZjdGwgbWMnIGhhcyBpbmNvbXBs ZXRlIHR5cGUgYW5kIGNhbm5vdCBiZQogICBkZWZpbmVkCm1mZWFfbXJvdXRlci5jYzogSW4gbWVt YmVyIGZ1bmN0aW9uIGBpbnQgTWZlYU1yb3V0ZXI6OmFkZF9tZmMoY29uc3QgSVB2WCYsCiAgIGNv bnN0IElQdlgmLCBzaG9ydCB1bnNpZ25lZCBpbnQsIHVpbnQ4X3QqLCB1aW50OF90KiwgY29uc3Qg SVB2WCYpJzoKbWZlYV9tcm91dGVyLmNjOjExMDY6IGFnZ3JlZ2F0ZSBgbWY2Y2N0bCBtYycgaGFz IGluY29tcGxldGUgdHlwZSBhbmQgY2Fubm90IGJlCiAgIGRlZmluZWQKbWZlYV9tcm91dGVyLmNj OjExMTA6IGBJRl9aRVJPJyB1bmRlY2xhcmVkIChmaXJzdCB1c2UgdGhpcyBmdW5jdGlvbikKbWZl YV9tcm91dGVyLmNjOjExMTY6IGBJRl9TRVQnIHVuZGVjbGFyZWQgKGZpcnN0IHVzZSB0aGlzIGZ1 bmN0aW9uKQptZmVhX21yb3V0ZXIuY2M6MTEyNjogYE1SVDZfQUREX01GQycgdW5kZWNsYXJlZCAo Zmlyc3QgdXNlIHRoaXMgZnVuY3Rpb24pCm1mZWFfbXJvdXRlci5jYzogSW4gbWVtYmVyIGZ1bmN0 aW9uIGBpbnQgTWZlYU1yb3V0ZXI6OmRlbGV0ZV9tZmMoY29uc3QgSVB2WCYsCiAgIGNvbnN0IElQ dlgmKSc6Cm1mZWFfbXJvdXRlci5jYzoxMTg3OiBhZ2dyZWdhdGUgYG1mNmNjdGwgbWMnIGhhcyBp bmNvbXBsZXRlIHR5cGUgYW5kIGNhbm5vdCBiZQogICBkZWZpbmVkCm1mZWFfbXJvdXRlci5jYzox MTkyOiBgTVJUNl9ERUxfTUZDJyB1bmRlY2xhcmVkIChmaXJzdCB1c2UgdGhpcyBmdW5jdGlvbikK bWZlYV9tcm91dGVyLmNjOiBJbiBtZW1iZXIgZnVuY3Rpb24gYGludCBNZmVhTXJvdXRlcjo6Z2V0 X3NnX2NvdW50KGNvbnN0IElQdlgmLAogICBjb25zdCBJUHZYJiwgU2dDb3VudCYpJzoKbWZlYV9t cm91dGVyLmNjOjE3MzI6IGFnZ3JlZ2F0ZSBgc2lvY19zZ19yZXE2IHNncmVxJyBoYXMgaW5jb21w bGV0ZSB0eXBlIGFuZAogICBjYW5ub3QgYmUgZGVmaW5lZAptZmVhX21yb3V0ZXIuY2M6MTczNzog YFNJT0NHRVRTR0NOVF9JTjYnIHVuZGVjbGFyZWQgKGZpcnN0IHVzZSB0aGlzIGZ1bmN0aW9uKQpt ZmVhX21yb3V0ZXIuY2M6IEluIG1lbWJlciBmdW5jdGlvbiBgaW50IE1mZWFNcm91dGVyOjpnZXRf dmlmX2NvdW50KHNob3J0CiAgIHVuc2lnbmVkIGludCwgVmlmQ291bnQmKSc6Cm1mZWFfbXJvdXRl ci5jYzoxODEzOiBhZ2dyZWdhdGUgYHNpb2NfbWlmX3JlcTYgbXJlcScgaGFzIGluY29tcGxldGUg dHlwZSBhbmQKICAgY2Fubm90IGJlIGRlZmluZWQKbWZlYV9tcm91dGVyLmNjOjE4MTc6IGBTSU9D R0VUTUlGQ05UX0lONicgdW5kZWNsYXJlZCAoZmlyc3QgdXNlIHRoaXMgZnVuY3Rpb24pCm1mZWFf bXJvdXRlci5jYzogSW4gbWVtYmVyIGZ1bmN0aW9uIGB2b2lkIE1mZWFNcm91dGVyOjptcm91dGVy X3NvY2tldF9yZWFkKGludCwKICAgU2VsZWN0b3JNYXNrKSc6Cm1mZWFfbXJvdXRlci5jYzoxOTM0 OiBgc2l6ZW9mJyBhcHBsaWVkIHRvIGluY29tcGxldGUgdHlwZSBgbXJ0Nm1zZycKbWZlYV9tcm91 dGVyLmNjOjE5MzU6IGBzaXplb2YnIGFwcGxpZWQgdG8gaW5jb21wbGV0ZSB0eXBlIGBtbGRfaGRy JwptZmVhX21yb3V0ZXIuY2M6MTk0MDogYHNpemVvZicgYXBwbGllZCB0byBpbmNvbXBsZXRlIHR5 cGUgYG1ydDZtc2cnCm1mZWFfbXJvdXRlci5jYzoxOTQwOiBgc2l6ZW9mJyBhcHBsaWVkIHRvIGlu Y29tcGxldGUgdHlwZSBgbWxkX2hkcicKbWZlYV9tcm91dGVyLmNjOjE5NDM6IGludmFsaWQgdXNl IG9mIHVuZGVmaW5lZCB0eXBlIGBzdHJ1Y3QgbXJ0Nm1zZycKbWZlYV9tcm91dGVyLmNjOjE5MzE6 IGZvcndhcmQgZGVjbGFyYXRpb24gb2YgYHN0cnVjdCBtcnQ2bXNnJwptZmVhX21yb3V0ZXIuY2M6 IEluIG1lbWJlciBmdW5jdGlvbiBgaW50CiAgIE1mZWFNcm91dGVyOjprZXJuZWxfY2FsbF9wcm9j ZXNzKHVpbnQ4X3QqLCB1bnNpZ25lZCBpbnQpJzoKbWZlYV9tcm91dGVyLmNjOjIwOTI6IGludmFs aWQgdXNlIG9mIHVuZGVmaW5lZCB0eXBlIGBzdHJ1Y3QgbXJ0Nm1zZycKbWZlYV9tcm91dGVyLmNj OjIwODc6IGZvcndhcmQgZGVjbGFyYXRpb24gb2YgYHN0cnVjdCBtcnQ2bXNnJwptZmVhX21yb3V0 ZXIuY2M6MjA5MzogaW52YWxpZCB1c2Ugb2YgdW5kZWZpbmVkIHR5cGUgYHN0cnVjdCBtcnQ2bXNn JwptZmVhX21yb3V0ZXIuY2M6MjA4NzogZm9yd2FyZCBkZWNsYXJhdGlvbiBvZiBgc3RydWN0IG1y dDZtc2cnCm1mZWFfbXJvdXRlci5jYzoyMDk0OiBgTVJUNk1TR19XSE9MRVBLVCcgdW5kZWNsYXJl ZCAoZmlyc3QgdXNlIHRoaXMgZnVuY3Rpb24pCm1mZWFfbXJvdXRlci5jYzoyMDk5OiBpbnZhbGlk IHVzZSBvZiB1bmRlZmluZWQgdHlwZSBgc3RydWN0IG1ydDZtc2cnCm1mZWFfbXJvdXRlci5jYzoy MDg3OiBmb3J3YXJkIGRlY2xhcmF0aW9uIG9mIGBzdHJ1Y3QgbXJ0Nm1zZycKbWZlYV9tcm91dGVy LmNjOjIxMDA6IGBzaXplb2YnIGFwcGxpZWQgdG8gaW5jb21wbGV0ZSB0eXBlIGBtcnQ2bXNnJwpt ZmVhX21yb3V0ZXIuY2M6MjEwNzogaW52YWxpZCB1c2Ugb2YgdW5kZWZpbmVkIHR5cGUgYHN0cnVj dCBtcnQ2bXNnJwptZmVhX21yb3V0ZXIuY2M6MjA4NzogZm9yd2FyZCBkZWNsYXJhdGlvbiBvZiBg c3RydWN0IG1ydDZtc2cnCm1mZWFfbXJvdXRlci5jYzoyMTA4OiBpbnZhbGlkIHVzZSBvZiB1bmRl ZmluZWQgdHlwZSBgc3RydWN0IG1ydDZtc2cnCm1mZWFfbXJvdXRlci5jYzoyMDg3OiBmb3J3YXJk IGRlY2xhcmF0aW9uIG9mIGBzdHJ1Y3QgbXJ0Nm1zZycKbWZlYV9tcm91dGVyLmNjOjIxMTU6IGBN UlQ2TVNHX05PQ0FDSEUnIHVuZGVjbGFyZWQgKGZpcnN0IHVzZSB0aGlzIGZ1bmN0aW9uKQptZmVh X21yb3V0ZXIuY2M6MjExNjogYE1SVDZNU0dfV1JPTkdNSUYnIHVuZGVjbGFyZWQgKGZpcnN0IHVz ZSB0aGlzIGZ1bmN0aW9uKQptZmVhX21yb3V0ZXIuY2M6MjE2MzogYHNpemVvZicgYXBwbGllZCB0 byBpbmNvbXBsZXRlIHR5cGUgYG1ydDZtc2cnCm1mZWFfbXJvdXRlci5jYzoyMTY0OiBgc2l6ZW9m JyBhcHBsaWVkIHRvIGluY29tcGxldGUgdHlwZSBgbXJ0Nm1zZycKZ21ha2VbM106ICoqKiBbbWZl YV9tcm91dGVyLmxvXSBFcnJvciAxCmdtYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3d4Zi94 b3JwLTEuMS9mZWEnCmdtYWtlWzJdOiAqKiogW2FsbC1yZWN1cnNpdmVdIEVycm9yIDEKZ21ha2Vb Ml06IExlYXZpbmcgZGlyZWN0b3J5IGAvd3hmL3hvcnAtMS4xL2ZlYScKZ21ha2VbMV06ICoqKiBb YWxsLXJlY3Vyc2l2ZV0gRXJyb3IgMQpnbWFrZVsxXTogTGVhdmluZyBkaXJlY3RvcnkgYC93eGYv eG9ycC0xLjEnCmdtYWtlOiAqKiogW2FsbF0gRXJyb3IgMgoK --=====001_Dragon424706684415_=====-- From deathdealer@gmx.net Sat Oct 29 22:46:03 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Sat, 29 Oct 2005 23:46:03 +0200 Subject: [Xorp-hackers] Introduce a Bug Day Message-ID: <001e01c5dcd2$28bf0f60$1608000a@dedus737> Hello all, What you are thinking about to introduce a bugday, Where bugs are reviewed and consolidated? I think there are a lot of bugs witch may fixed, or can be consolidated in the bugzilla database. Second what you are thinking about to introduce a command like the "show tech-support" on the ciscos witch includes all nessesary information about the system? Third is it possible to add a unique version information to the CVS/HEAD Code so it will be easily to say witch Version I use. Regards    Patrick Marc Preuss From pavlin@icir.org Sun Oct 30 22:51:41 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 30 Oct 2005 14:51:41 -0800 Subject: [Xorp-hackers] Re: XORP PIMSM6 and IPv6 multicast forwarding patch In-Reply-To: Message from "Melvin" of "Sat, 29 Oct 2005 17:20:15 +0800." <200510290917.j9T9HOdd047477@wyvern.icir.org> Message-ID: <200510302251.j9UMpfEp048134@possum.icir.org> > You are right, I did the compile check on my system and at first it failed. Later on when i copy the mroute6.h into /usr/include/linux where IPv4 mroute.h exists.Then everything is OK > (No message when compile). > I confirm that HAVE_IPV6 and HAVE_IPV6_MULTICAST are defined to 1 in myconfig.h . > > Looks like I have to wait your correctness. > > > FYI only: > The mroute6.h is not in the right place. I did compile a new kernel on RH9(2.4.20-8) to upgrade it to Linux kernel 2.6.7 as the multicast forwarding patch required. The file still stay in the place where new kernel source files and didnot installed in! > > When I force the HAVE_IPV6_MULTICAST_ROUTING to 1, gmake failed with many message related. See attachement. Also tried renamed the mroute6.h to netinet6/ip6_mroute.h but failed gmake too. The error message is icmp6_filter struct redefination or some kind of info(caused by the HAVE_NETINET6_IP6_MROUTE_H some where) Yes, mroute6.h is not in the right place so you have to copy it by hand to the /usr/include/linux/ directory. However, it contains a number of definitions that shouldn't be there (e.g., the PIM-specific stuff should be in ). Anyway, I just committed some mods to XORP itself so now it can compile with the Linux IPv6 multicast forwarding patch. The catch however is that you have to comment-out some of the stuff in the new (see the patch below). Note that I have only tested that XORP compiles, but I haven't tested whether it can work with the modified kernel. Please let me know what happens when you try to run it. Pavlin --- mroute6.h.broken 2005-10-30 03:50:10.000000000 -0800 +++ mroute6.h 2005-10-30 21:43:17.000000000 -0800 @@ -204,7 +204,9 @@ #define IGMPMSG_WRONGVIF 2 /* For PIM assert processing (unused) */ #define IGMPMSG_WHOLEPKT 3 /* For PIM Register processing */ +#if 0 #define PIM_REGISTER 1 +#endif #ifdef __KERNEL__ @@ -257,6 +259,7 @@ struct in6_addr im6_src, im6_dst; }; +#if 0 /* * PIM packet header */ @@ -279,10 +282,12 @@ #define PIM_MINLEN 8 /* The header min. length is 8 */ #define PIM6_REG_MINLEN (PIM_MINLEN+40) /* Register message + inner IP6 header */ +#endif /* 0 */ #define IPV6_VERSION 0x60 #define IPV6_VERSION_MASK 0xf0 +#if 0 /* XXX :there should not be there */ #include @@ -292,5 +297,6 @@ }; #define mld_type mld_icmp6_hdr.icmp6_type +#endif /* 0 */ #endif From kristian@juniks.net Mon Oct 31 11:55:29 2005 From: kristian@juniks.net (Kristian Larsson) Date: Mon, 31 Oct 2005 12:55:29 +0100 Subject: [Xorp-hackers] BGP/OSPF test tools Message-ID: <20051031115528.GF3639@juniks.net> We have been having problems with a Foundry switch lately. We're going to use it for BGP and OSPF, considering the other problems which seem to be caused by software bugs I'd thought it would be a good idea to thouroughly test the OSPF/BGP processes before proceeding. I have seen BugZilla entries originating from programs developed to test BGP/OSPF/RIP. Does anyone know of such programs? Kristian From kristian@juniks.net Mon Oct 31 18:19:00 2005 From: kristian@juniks.net (Kristian Larsson) Date: Mon, 31 Oct 2005 19:19:00 +0100 Subject: [Xorp-hackers] BGP groups Message-ID: <20051031181900.GA7585@juniks.net> I would like to hear peoples opinion on a group configuration under bgp. As so often I would like to bring up the "Juniper way" of doing things. In Juniper a normal BGP neighbor would be configured like this: protocols bgp { local-as 1337; group My_transit_provider { remote-as 1338; neighbour 1.3.3.7; prefix-list out My_prefixes; } } Having several peers with the same settings is real easy since you just add another neighbor statement, like this: protocols bgp { group My_transit_provider { local-as 1337; remote-as 1338; neighbour 1.3.3.7; neighbour 1.3.3.8; neighbour 1.3.3.9; neighbour 1.3.3.10; prefix-list out My_prefixes; } } As group doesn't collide with any present BGP commands it would be easy to add and let the old peer statement remain as is to not surprise anyone ;) Any thoughts? Kristian. From vjardin@free.fr Mon Oct 31 18:26:26 2005 From: vjardin@free.fr (Vincent Jardin) Date: Mon, 31 Oct 2005 19:26:26 +0100 Subject: [Xorp-hackers] Re: XORP PIMSM6 and IPv6 multicast forwarding patch In-Reply-To: <200510302251.j9UMpfEp048134@possum.icir.org> References: <200510302251.j9UMpfEp048134@possum.icir.org> Message-ID: <436661D2.4040503@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, This patch has been designed to reuse BSD PIM6 on Linux where you do not have linux/ directory ! So, you should not need to copy it into usr/include/linux Regards, ~ Vincent Pavlin Radoslavov wrote: |> You are right, I did the compile check on my system and at first it failed. Later on when i copy the mroute6.h into /usr/include/linux where IPv4 mroute.h exists.Then everything is OK |>(No message when compile). |> I confirm that HAVE_IPV6 and HAVE_IPV6_MULTICAST are defined to 1 in myconfig.h . |> |> Looks like I have to wait your correctness. |> |> |>FYI only: |>The mroute6.h is not in the right place. I did compile a new kernel on RH9(2.4.20-8) to upgrade it to Linux kernel 2.6.7 as the multicast forwarding patch required. The file still stay in the place where new kernel source files and didnot installed in! |> |>When I force the HAVE_IPV6_MULTICAST_ROUTING to 1, gmake failed with many message related. See attachement. Also tried renamed the mroute6.h to netinet6/ip6_mroute.h but failed gmake too. The error message is icmp6_filter struct redefination or some kind of info(caused by the HAVE_NETINET6_IP6_MROUTE_H some where) | | | | Yes, mroute6.h is not in the right place so you have to copy it by | hand to the /usr/include/linux/ directory. | However, it contains a number of definitions that shouldn't be | there (e.g., the PIM-specific stuff should be in ). | | Anyway, I just committed some mods to XORP itself so now it can | compile with the Linux IPv6 multicast forwarding patch. | The catch however is that you have to comment-out some of the stuff | in the new (see the patch below). | | Note that I have only tested that XORP compiles, but I haven't | tested whether it can work with the modified kernel. | Please let me know what happens when you try to run it. | | Pavlin | | | --- mroute6.h.broken 2005-10-30 03:50:10.000000000 -0800 | +++ mroute6.h 2005-10-30 21:43:17.000000000 -0800 | @@ -204,7 +204,9 @@ | #define IGMPMSG_WRONGVIF 2 /* For PIM assert processing (unused) */ | #define IGMPMSG_WHOLEPKT 3 /* For PIM Register processing */ | | +#if 0 | #define PIM_REGISTER 1 | +#endif | | #ifdef __KERNEL__ | | @@ -257,6 +259,7 @@ | struct in6_addr im6_src, im6_dst; | }; | | +#if 0 | /* | * PIM packet header | */ | @@ -279,10 +282,12 @@ | | #define PIM_MINLEN 8 /* The header min. length is 8 */ | #define PIM6_REG_MINLEN (PIM_MINLEN+40) /* Register message + inner IP6 header */ | +#endif /* 0 */ | | #define IPV6_VERSION 0x60 | #define IPV6_VERSION_MASK 0xf0 | | +#if 0 | /* XXX :there should not be there */ | #include | | @@ -292,5 +297,6 @@ | }; | | #define mld_type mld_icmp6_hdr.icmp6_type | +#endif /* 0 */ | | #endif | _______________________________________________ | Xorp-hackers mailing list | Xorp-hackers@icir.org | http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDZmHRj1uHAMmANdgRArsuAKCNWRHVWfacVNBj4krEWUl60we3IwCfWT0P sLFiMFQlIDv4duPEpYQeo48= =Qc08 -----END PGP SIGNATURE----- From deathdealer@gmx.net Mon Oct 31 18:43:35 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Mon, 31 Oct 2005 19:43:35 +0100 Subject: AW: [Xorp-hackers] BGP groups In-Reply-To: <20051031181900.GA7585@juniks.net> Message-ID: <000901c5de4b$04e1fd80$674dbb50@dedus737> Hello Cool, like it. ;-) Regards,    Patrick Marc Preuss -----Ursprüngliche Nachricht----- Von: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] Im Auftrag von Kristian Larsson Gesendet: Montag, 31. Oktober 2005 19:19 An: xorp-hackers@xorp.org Betreff: [Xorp-hackers] BGP groups I would like to hear peoples opinion on a group configuration under bgp. As so often I would like to bring up the "Juniper way" of doing things. In Juniper a normal BGP neighbor would be configured like this: protocols bgp { local-as 1337; group My_transit_provider { remote-as 1338; neighbour 1.3.3.7; prefix-list out My_prefixes; } } Having several peers with the same settings is real easy since you just add another neighbor statement, like this: protocols bgp { group My_transit_provider { local-as 1337; remote-as 1338; neighbour 1.3.3.7; neighbour 1.3.3.8; neighbour 1.3.3.9; neighbour 1.3.3.10; prefix-list out My_prefixes; } } As group doesn't collide with any present BGP commands it would be easy to add and let the old peer statement remain as is to not surprise anyone ;) Any thoughts? Kristian. _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin@icir.org Mon Oct 31 18:51:49 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 31 Oct 2005 10:51:49 -0800 Subject: [Xorp-hackers] Re: XORP PIMSM6 and IPv6 multicast forwarding patch In-Reply-To: Message from Vincent Jardin of "Mon, 31 Oct 2005 19:26:26 +0100." <436661D2.4040503@free.fr> Message-ID: <200510311851.j9VIpnnl067056@possum.icir.org> > This patch has been designed to reuse BSD PIM6 on Linux where you do not > have linux/ directory ! > > So, you should not need to copy it into usr/include/linux Understandable. However, the patch as-is does not not put anything under /usr/include, because it has been generated only as kernel patch. Userland programs cannot be compiled without a header file that defines the BSD-derived API, so there has to be a header file under /usr/include that defines the new API. If the BSD API is to be followed 100% percent, then the new header file should be By looking into the sample mroute6.c program that is in the tarball with that patch, it includes header file hence this is why I adviced that the new file mroute6.h should be copied to the /usr/include/linux directory. Myself, I also don't like the fact that some header files on Linux have to be included from (including the IPv4 equivalent), but this is a different topic. Pavlin From thomas.mangin@exa-networks.co.uk Mon Oct 31 19:08:44 2005 From: thomas.mangin@exa-networks.co.uk (Thomas Mangin) Date: Mon, 31 Oct 2005 19:08:44 +0000 Subject: [Xorp-hackers] BGP groups In-Reply-To: <20051031181900.GA7585@juniks.net> References: <20051031181900.GA7585@juniks.net> Message-ID: <43666BBC.7050909@exa-networks.co.uk> This is a Juniper BGP conf which use the some of the feature of the language which are really nice when you have lots of sessions. # show protoocols bgp apply-groups bgp-log; path-selection always-compare-med; damping; remove-private; graceful-restart; group ibgp { type internal; inactive: traceoptions { file log-bgp-ibgp size 1m files 5; } local-address ; import blackhole; ## Used to null route some tagged routes authentication-key "$....."; ## SECRET-DATA peer-as ; neighbor ; neighbor ; } group transit { type external; local-preference 75; remove-private; neighbor { inactive: traceoptions { file log-bgp-transit1 size 1m files 5; } local-address ; import [ no-ix no-bogons no-small-prefixes tag-transit1 damping local-preference-transit community-clear ]; export [ originate export-transit export-transit1 community-clear next-hop-self ]; peer-as ; } neighbor 212.187.136.41 { inactive: traceoptions { file log-bgp-transit2 size 1m files 5; } local-address ; import [ no-ix no-bogons no-small-prefixes tag-transit2 damping local-preference-transit community-clear ]; export [ originate export-transit export-transit2 community-clear next-hop-self ]; peer-as ; } } group internet_exchange { type external; traceoptions { file log-bgp-exchange size 1m files 5; flag all; } local-preference 150; local-address ; import [ no-ix no-bogons no-small-prefixes tag-ix damping local-preference-peer community-clear ]; export [ originate export-peering export-ix community-clear next-hop-self ]; neighbor { apply-groups bgp-limit-50; description "IX / Route Collector"; authentication-key "$...."; ## SECRET-DATA peer-as ; } neighbor { apply-groups bgp-limit-50; description "ISP Name / AS-MACRO"; peer-as ; } neighbor { apply-groups bgp-limit-500; description "ISP Name / AS-MACRO"; peer-as ; } } with #show groups bgp-log { protocols { bgp { traceoptions { file log-bgp size 1m files 5; flag state; flag normal; flag general; } log-updown; group <*> { traceoptions { flag normal; flag general; flag state; } log-updown; } } } } bgp-limit-50 { protocols { bgp { group <*> { neighbor <*> { family inet { unicast { prefix-limit { maximum 50; teardown 80; } } } } } } } } .... Thomas From M.Handley@cs.ucl.ac.uk Mon Oct 31 20:12:17 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Mon, 31 Oct 2005 20:12:17 +0000 Subject: [Xorp-hackers] BGP groups In-Reply-To: <20051031181900.GA7585@juniks.net> References: <20051031181900.GA7585@juniks.net> Message-ID: <84a612dd0510311212i8e4b60cpcf920f20cd92b2d7@mail.gmail.com> You may be able to add this with only a template file change, and no actual coding changes. - Mark On 10/31/05, Kristian Larsson wrote: > I would like to hear peoples opinion on a group configuration under bgp. > As so often I would like to bring up the "Juniper way" of doing things. In Juniper a normal BGP neighbor would be configured like this: > protocols bgp { > local-as 1337; > group My_transit_provider { > remote-as 1338; > neighbour 1.3.3.7; > prefix-list out My_prefixes; > } > } > > Having several peers with the same settings is real easy since you just add another neighbor statement, like this: > protocols bgp { > group My_transit_provider { > local-as 1337; > remote-as 1338; > neighbour 1.3.3.7; > neighbour 1.3.3.8; > neighbour 1.3.3.9; > neighbour 1.3.3.10; > prefix-list out My_prefixes; > } > } > > As group doesn't collide with any present BGP commands it would be easy to add and let the old peer statement remain as is to not surprise anyone ;) > > Any thoughts? > > Kristian. > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers >