From kushalahuja at gmail.com Wed Nov 1 04:24:37 2006 From: kushalahuja at gmail.com (kushal ahuja) Date: Wed, 1 Nov 2006 17:54:37 +0530 Subject: [Xorp-users] New User of XORP Message-ID: <3d261bac0611010424k7b05a08bmf09db2fd6ab24c3b@mail.gmail.com> Hi Sir, I am using XORP for first time, after compiling the code when i am running xorp_rtrmgr its giving some error. Mite be the error is in -- Best Regards, Kushal Ahuja -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061101/57f7d42e/attachment.html From pavlin at icir.org Wed Nov 1 08:59:52 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 01 Nov 2006 08:59:52 -0800 Subject: [Xorp-users] New User of XORP In-Reply-To: Message from "kushal ahuja" of "Wed, 01 Nov 2006 17:54:37 +0530." <3d261bac0611010424k7b05a08bmf09db2fd6ab24c3b@mail.gmail.com> Message-ID: <200611011659.kA1Gxq8l002276@possum.icir.org> > I am using XORP for first time, after compiling the code when i am running > xorp_rtrmgr its giving some error. > Mite be the error is in Somehow the particular error messages are missing from your email, so please resend them. FYI, sometimes there are startup or shutdown error messages that are transient and can be ignored. There is some chance you might be observing such transient messages. Regards, Pavlin From yapingz at cs.princeton.edu Thu Nov 2 20:11:32 2006 From: yapingz at cs.princeton.edu (yapingz at cs.princeton.edu) Date: Thu, 02 Nov 2006 23:11:32 -0500 Subject: [Xorp-users] question about reflector/client configuration Message-ID: <20061102231132.7b854iw7w0scgowo@webmail.cs.princeton.edu> Hi xorp-users, I have a problem with route reflector/client configuration, and it's not working correctly. My current configuration is: at reflector side: add route-reflector setting with cluster-id, set client option to be true for client peers. at client side: nothing special, the same as normal ibgp configuration. but, the reflector is not working correctly, and can't propagate the route of one client to another, does anybody know what's wrong with my current configuration? Am I missing anything? or better, sample configuration at both reflector and client side is appreciated. thanks very much, Yaping From santhosh at ku.edu Thu Nov 2 21:29:31 2006 From: santhosh at ku.edu (Santhosh Sundararaman) Date: Thu, 02 Nov 2006 23:29:31 -0600 Subject: [Xorp-users] Using BGP Test Harness to dump mrtd file In-Reply-To: <200611011659.kA1Gxq8l002276@possum.icir.org> References: <200611011659.kA1Gxq8l002276@possum.icir.org> Message-ID: <454AD3BB.9010209@ku.edu> Hi, I have an instance of XORP running on a machine (say host1) with multiple BGP peerings configured on it. I would like to use the BGP test harness on the same machine (host1) in a way such that, one of the test per from the test harness establishes a peering with the BGP of the XORP instance that is already running on host1 and dump routes from an mrtd file to it. (I'd like to do this for load testing purposes). I read a previous thread http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2005-May/000564.html on a similar topic, but would like to know if it is possible to use the test harness to test a different instance of XORP_BGP itself on the same host instead of a third party BGP. If so, could some one guide me on how to go about setting up the harness to perform it. Also, in the thread that i have linked here, it was mentioned that the BGP that is to be tested has to be configured to accept a peering from the test peer, but I was wondering what IP address needs to specified as the test peer's peer id in the configuration of the BGP that needs to be tested. Thanks Santhosh From santhosh at ku.edu Fri Nov 3 11:35:13 2006 From: santhosh at ku.edu (Santhosh Sundararaman) Date: Fri, 03 Nov 2006 13:35:13 -0600 Subject: [Xorp-users] Using bgp/harness/inject.sh to inject routes from mrtd in to BGP routing table?? In-Reply-To: <454AD3BB.9010209@ku.edu> References: <200611011659.kA1Gxq8l002276@possum.icir.org> <454AD3BB.9010209@ku.edu> Message-ID: <454B99F1.4070400@ku.edu> Hi, I came across the inject.sh in the BGP harness and found that it could be used to inject routes from an mrtd file into the BGP process. But when i tried executing the script file, the script terminated with some error from the call_xrl response handler. Error: Configuring fea create_interface 11222865 dc0enable_interface 11222865 dc0create_vif 11222865 dc0 dc0enable_vif 11222865 dc0 dc0create_address4 11222865 dc0 dc0 10.1.0.1enable_address4 11222865 dc0 dc0 10.1.0.1set_prefix4 11222865 dc0 dc0 10.1.0.1 25commit_transaction[ 2006/11/03 13:25:50 ERROR call_xrl:22889 XRL +59 call_xrl.cc response_handler ] Failed. Reason: 102 Command failed Interface error on dc0: interface not recognized ("finder://fea/ifmgr/0.1/commit_transaction?tid:u32=11222865") I am probably not doing something right here. It would be of great help, if someone could help me with using the inject.sh script correctly. I just need to be able to read routes from an mrtd file and dump it to the BGP process on the same host. Thanks Santhosh From pavlin at icir.org Fri Nov 3 15:35:25 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 03 Nov 2006 15:35:25 -0800 Subject: [Xorp-users] Using bgp/harness/inject.sh to inject routes from mrtd in to BGP routing table?? In-Reply-To: Message from Santhosh Sundararaman of "Fri, 03 Nov 2006 13:35:13 CST." <454B99F1.4070400@ku.edu> Message-ID: <200611032335.kA3NZPZS068348@possum.icir.org> > I came across the inject.sh in the BGP harness and found that it could > be used to inject routes from an mrtd file into the BGP process. But > when i tried executing the script file, the script terminated with some > error from the call_xrl response handler. > > Error: > Configuring fea > create_interface 11222865 dc0enable_interface 11222865 dc0create_vif > 11222865 dc0 dc0enable_vif 11222865 dc0 dc0create_address4 11222865 dc0 > dc0 10.1.0.1enable_address4 11222865 dc0 dc0 10.1.0.1set_prefix4 > 11222865 dc0 dc0 10.1.0.1 25commit_transaction[ 2006/11/03 13:25:50 > ERROR call_xrl:22889 XRL +59 call_xrl.cc response_handler ] Failed. > Reason: 102 Command failed Interface error on dc0: interface not > recognized ("finder://fea/ifmgr/0.1/commit_transaction?tid:u32=11222865") > > > I am probably not doing something right here. It would be of great help, > if someone could help me with using the inject.sh script correctly. I > just need to be able to read routes from an mrtd file and dump it to the > BGP process on the same host. My guess is that your machine doesn't have network interface named dc0 (that the script tries to configure). If this is the case, then you need to edit the beginning of the script and change the interface name to something different: VIF0="dc0" You might need to change ADDR0 as well to match your IP address. Also, note that the fea() configuration that uses ADDR0 contains a hard-coded prefix length of 25, so you might need to edit as well. I just committed a fix so the hard-coded value is replaced with ADDR_PREFIX0 variable. In any case, the script might reconfigure the VIF0 interface, so make sure it is not the interface you are using to connect to that machine. Regards, Pavlin From kushalahuja at gmail.com Mon Nov 6 02:57:18 2006 From: kushalahuja at gmail.com (kushal ahuja) Date: Mon, 6 Nov 2006 16:27:18 +0530 Subject: [Xorp-users] Regarding config.boot Message-ID: <3d261bac0611060257u5be56146vc536d8cd3a56581e@mail.gmail.com> Hi All, I am using XORP for the first time, i want to know where to get config.bootfile so that i can change configuration accordingly.If i am using that config.boot.sample it is throwing some errors. If i have to configure configure it myself than what all changes i have to made in "config.boot.sample" . Please help me. Thanks in advance. -- Best Regards, Kushal Ahuja -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061106/f6077677/attachment.html From kristian at spritelink.se Mon Nov 6 04:02:54 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Mon, 6 Nov 2006 13:02:54 +0100 Subject: [Xorp-users] Regarding config.boot In-Reply-To: <3d261bac0611060257u5be56146vc536d8cd3a56581e@mail.gmail.com> References: <3d261bac0611060257u5be56146vc536d8cd3a56581e@mail.gmail.com> Message-ID: <20061106120253.GB32311@spritelink.se> On Mon, Nov 06, 2006 at 04:27:18PM +0530, kushal ahuja wrote: > Hi All, > > I am using XORP for the first time, i want to know where to get > config.bootfile so that i can change configuration > accordingly.If i am using that config.boot.sample it is throwing some > errors. > If i have to configure configure it myself than what all changes i have to > made in "config.boot.sample" . Please help me. > Thanks in advance. I would recommend starting of with a blank config.boot, ie just touch it touch /usr/local/xorp/config.boot (by default) and then startup xorp_rtrmgr and xorpsh If you want to use a sample config.boot you may have to change the interface names and such. What errors are you receiving? Kristian. -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From baobhan at classicnet.net Sun Nov 5 08:59:07 2006 From: baobhan at classicnet.net (Mark Lalich) Date: Sun, 5 Nov 2006 10:59:07 -0600 Subject: [Xorp-users] problems with openssl Message-ID: <20061105165756.D1ED8348FBE@mxo2.broadbandsupport.net> Hi I am also encountering an openssl error on ./configure for XORP on an Ubuntu box. I've run a force-reinstall and rerun ./configure --with-openssl=/etc/ssl. I have also run ./configure --without-openssl, but still no success. This is my first time compiling an app manually in Linux, so I'm not really sure what I'm needing to see so I know I can proceed to make. Also I'm not really sure where OpenSSL is installed to, I've tried looking in Synamptic and looking at OpenSSLs properties/Installed Files. There's so much stuff listed I don't know where to begin. Anyway any help would be greatly appreciated! Here's my actual questions. 1. What am I wanting to see from running ./configure? 2. What will be the result of running ./configure, will is produce a file that make will use? 3. Upon running make will that actually install XORP? Thanks, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061105/afea5068/attachment.html From pavlin at icir.org Mon Nov 6 12:11:45 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 06 Nov 2006 12:11:45 -0800 Subject: [Xorp-users] problems with openssl In-Reply-To: Message from "Mark Lalich" of "Sun, 05 Nov 2006 10:59:07 CST." <20061105165756.D1ED8348FBE@mxo2.broadbandsupport.net> Message-ID: <200611062011.kA6KBjHM023812@possum.icir.org> > Hi I am also encountering an openssl error on ./configure for XORP on an > Ubuntu box. I've run a force-reinstall and rerun ./configure > --with-openssl=/etc/ssl. I have also run ./configure --without-openssl, but > still no success. This is my first time compiling an app manually in Linux, > so I'm not really sure what I'm needing to see so I know I can proceed to > make. Also I'm not really sure where OpenSSL is installed to, I've tried > looking in Synamptic and looking at OpenSSLs properties/Installed Files. > There's so much stuff listed I don't know where to begin. Anyway any help > would be greatly appreciated! What XORP version are you using and what are the particular errors you encounter when you run "./configure" only without any options. The "configure" script tests for OpenSSL installation in several places. Typically, on UNIX it is one of the following locations: /usr /usr/local /usr/local/ssl /opt /usr/sfw . The script in particular checks whether there is sub-directory "include/openssl" in one of the above directories; older XORP versions may omit the automatic checking in some of those directories. Eventually, there should be header file /include/openssl/md5.h and the OpenSSL library should be in /lib/libcrypto.* . > > > > Here's my actual questions. > > 1. What am I wanting to see from running ./configure? On Gentoo with most recent XORP code (from CVS) the related messages are: checking OpenSSL installation prefix... /usr checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking openssl/md5.h usability... yes checking openssl/md5.h presence... yes checking for openssl/md5.h... yes checking for MD5_Init in -lcrypto... yes > 2. What will be the result of running ./configure, will is produce a > file that make will use? ./configure will auto-generate a number of Makefile including one in the top-level directory. Then you ca run "gmake" in the top-level directory to compile everything. > 3. Upon running make will that actually install XORP? No. After compilation with "gmake" you have to run "gmake install" (eventually as a root) to explicitly install XORP. By default the installation will be in the /usr/local/xorp directory. You can change this by using ./configure --prefix=/my/prefix Note that you have to recompile XORP if you change the prefix after an initial compilation. Hope that helps, Pavlin From gianfratetommaso at libero.it Tue Nov 7 02:09:34 2006 From: gianfratetommaso at libero.it (Tommaso Gianfrate) Date: Tue, 7 Nov 2006 11:09:34 +0100 Subject: [Xorp-users] PIM testing results Message-ID: Hi All, I'm trying to test PIM performance in XORP implementation. I've set a static RP in XORP configuration file and then i make a route change to reach the RP. After the multicast routing table update, PIM should send a JOIN on the new output interface. What i can see is that if the RP has the lowest IP in the network (a 100 routers fully meshed network), the time between the end of the OSPF Shortest Path Computation and the PIM Join is approx 6,7 sec, while if the RP has the highest IP, the same time is 24 sec. Why the update time of unicast and multicast routing table is so high? What are the operations made by XORP after the OSPF Shortest Path Computation and before the PIM Join message on the new interface? Thanks, Tommaso Gianfrate From cvrider at yahoo.com Tue Nov 7 08:06:33 2006 From: cvrider at yahoo.com (Mark) Date: Tue, 7 Nov 2006 08:06:33 -0800 (PST) Subject: [Xorp-users] XORP installation Message-ID: <20061107160634.35953.qmail@web55313.mail.re4.yahoo.com> I am new to XORP and I thought I would try installing it on freeBSD. I installed FreeBSD 6.1 on my PC. I then installed XORP 1.3 which looked like it compiled and installed correctly. As root I tried to run the xorp_rtrmgr and get the following errors: INFO xorp_rtrmgr: 17400 RTRMGR +143 userdb.cc add_user Group "xorp" does not exist on this system. If I just run ./xorpsh I get an error saying cannot connect to socket. >From the above I assume I have to add a xorp group to FreeBSD. Reading the XORP docs I don't see where is states this in the installation procedure. Is this the case or am I missing something else? I know this may be trivial, but I appreciate the help. ____________________________________________________________________________________ Sponsored Link Mortgage rates near historic lows: $150,000 loan as low as $579/mo. Intro-*Terms https://www2.nextag.com/ From mhorn at vyatta.com Tue Nov 7 08:31:50 2006 From: mhorn at vyatta.com (Mike Horn) Date: Tue, 7 Nov 2006 09:31:50 -0700 Subject: [Xorp-users] XORP installation In-Reply-To: <20061107160634.35953.qmail@web55313.mail.re4.yahoo.com> Message-ID: <005101c7028a$3c163820$0f02a8c0@caddisconsulting.com> Hi Mark, You are correct, you need to add a group named xorp and you need to add the user(s) to the group that will be configuring the system. Users that aren't in group xorp can run xorpsh, but are read-only, users that are in group xorp can run xorpsh and are read-write (e.g. they can enter configuration mode). -mike -----Original Message----- From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Mark Sent: Tuesday, November 07, 2006 9:07 AM To: xorp-users at xorp.org Subject: [Xorp-users] XORP installation I am new to XORP and I thought I would try installing it on freeBSD. I installed FreeBSD 6.1 on my PC. I then installed XORP 1.3 which looked like it compiled and installed correctly. As root I tried to run the xorp_rtrmgr and get the following errors: INFO xorp_rtrmgr: 17400 RTRMGR +143 userdb.cc add_user Group "xorp" does not exist on this system. If I just run ./xorpsh I get an error saying cannot connect to socket. >From the above I assume I have to add a xorp group to FreeBSD. Reading the XORP docs I don't see where is states this in the installation procedure. Is this the case or am I missing something else? I know this may be trivial, but I appreciate the help. ____________________________________________________________________________ ________ Sponsored Link Mortgage rates near historic lows: $150,000 loan as low as $579/mo. Intro-*Terms https://www2.nextag.com/ _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Tue Nov 7 10:31:36 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 07 Nov 2006 10:31:36 -0800 Subject: [Xorp-users] PIM testing results In-Reply-To: Message from "Tommaso Gianfrate" of "Tue, 07 Nov 2006 11:09:34 +0100." Message-ID: <200611071831.kA7IVa0q004492@possum.icir.org> > I'm trying to test PIM performance in XORP implementation. > I've set a static RP in XORP configuration file and then i make a route change to reach the RP. After the multicast routing table update, PIM should send a JOIN on the new output interface. > What i can see is that if the RP has the lowest IP in the network (a 100 routers fully meshed network), the time between the end of the OSPF Shortest Path Computation and the PIM Join is approx 6,7 sec, while if the RP has the highest IP, the same time is 24 sec. > Why the update time of unicast and multicast routing table is so high? > What are the operations made by XORP after the OSPF Shortest Path Computation and before the PIM Join message on the new interface? Very interesting. I cannot think of any good reason why you see such difference, because all the design is event-driven. This is the sequence of events that should happen: 1. OSPF receives the routing change. I presume the new route is chosen almost immediately and OSPF sends the change to the RIB. The particular XRL from OSPF to RIB is one of the following: - add_route4 - replace_route4 - add_interface_route4 - replace_interface_route4 2. The RIB performs the appropriate route comparison and sends the winning route to the FEA. The particular XRLs from RIB to FEA are: - redist_transaction4/0.1/start_transaction followed by - redist_transaction4/0.1/add_route followed by - redist_transaction4/0.1/commit_transaction 3. After the FEA receives the commit_transaction XRL, it installs the route(s) into the kernel. You could watch the routes being installed by the "route -n monitor" command on BSD or by the "ip monitor" command on Linux. 4. All routes being installed into the kernel should pop-up back to the FEA. The "route -n monitor" and "ip monitor" commands should show that event as well. 5. The FEA should send the route (as received from the kernel) to the FIB2MRIB module by using one of the following XRLs: - fea_fib_client/0.1/add_route4 - fea_fib_client/0.1/replace_route4 6. The FIB2MRIB should send the route to the RIB using one of the XRLs listed in Step 1 (but this time with the multicast flag set). 7. The RIB should send the FIB2MRIB route update (MRIB) to the PIM-SM module using the XRLs described in Step 2. 8. After the PIM-SM receives the MRIB update from RIB, it should send the new PIM Join almost immediately. You could enable the XRL tracing by setting the XRLTRACE environmental variable before starting XORP. Then you can use the XRL event timestamps to follow the event flow. This should help you find which component(s) is/are responsible for the delay. Please let us know if you find something. Thanks, Pavlin From vkaul at research.telcordia.com Tue Nov 7 11:43:44 2006 From: vkaul at research.telcordia.com (Vikram KAUL) Date: Tue, 7 Nov 2006 14:43:44 -0500 (Eastern Standard Time) Subject: [Xorp-users] Forcing xorpsh to return immediately Message-ID: Folks What way (if at all it were possible) can I force my xorpsh command to return immediately if the xorp_rtrmgr is not available ? Typically, it waits for 30 seconds after printing "Waiting for xorp_rtrmgr..." and then dies. I would prefer an option while running xorpsh rather than something that required recompilation Any help will be welcome regards.. Vikram From atanu at ICSI.Berkeley.EDU Tue Nov 7 12:14:16 2006 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 07 Nov 2006 12:14:16 -0800 Subject: [Xorp-users] Using bgp/harness/inject.sh to inject routes from mrtd in to BGP routing table?? In-Reply-To: Message from Pavlin Radoslavov of "Fri, 03 Nov 2006 15:35:25 PST." <200611032335.kA3NZPZS068348@possum.icir.org> Message-ID: <74619.1162930456@tigger.icir.org> Hi, You might find it easier to use bgp/harness/harness.py to inject routes from mrtd files. Atanu. >>>>> "Pavlin" == Pavlin Radoslavov writes: >> I came across the inject.sh in the BGP harness and found that it >> could be used to inject routes from an mrtd file into the BGP >> process. But when i tried executing the script file, the script >> terminated with some error from the call_xrl response handler. >> >> Error: Configuring fea create_interface 11222865 >> dc0enable_interface 11222865 dc0create_vif 11222865 dc0 >> dc0enable_vif 11222865 dc0 dc0create_address4 11222865 dc0 dc0 >> 10.1.0.1enable_address4 11222865 dc0 dc0 10.1.0.1set_prefix4 >> 11222865 dc0 dc0 10.1.0.1 25commit_transaction[ 2006/11/03 >> 13:25:50 ERROR call_xrl:22889 XRL +59 call_xrl.cc >> response_handler ] Failed. Reason: 102 Command failed Interface >> error on dc0: interface not recognized >> ("finder://fea/ifmgr/0.1/commit_transaction?tid:u32=11222865") >> >> >> I am probably not doing something right here. It would be of >> great help, if someone could help me with using the inject.sh >> script correctly. I just need to be able to read routes from an >> mrtd file and dump it to the BGP process on the same host. Pavlin> My guess is that your machine doesn't have network interface Pavlin> named dc0 (that the script tries to configure). If this is Pavlin> the case, then you need to edit the beginning of the script Pavlin> and change the interface name to something different: Pavlin> VIF0="dc0" Pavlin> You might need to change ADDR0 as well to match your IP Pavlin> address. Also, note that the fea() configuration that uses Pavlin> ADDR0 contains a hard-coded prefix length of 25, so you Pavlin> might need to edit as well. I just committed a fix so the Pavlin> hard-coded value is replaced with ADDR_PREFIX0 variable. Pavlin> In any case, the script might reconfigure the VIF0 Pavlin> interface, so make sure it is not the interface you are Pavlin> using to connect to that machine. Pavlin> Regards, Pavlin Pavlin> _______________________________________________ Xorp-users Pavlin> mailing list Xorp-users at xorp.org Pavlin> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Tue Nov 7 17:27:31 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 07 Nov 2006 17:27:31 -0800 Subject: [Xorp-users] Forcing xorpsh to return immediately In-Reply-To: Message from Vikram KAUL of "Tue, 07 Nov 2006 14:43:44 EST." Message-ID: <200611080127.kA81RVx6056456@possum.icir.org> > What way (if at all it were possible) can I force my xorpsh command to > return immediately if the xorp_rtrmgr is not available ? > > Typically, it waits for 30 seconds after printing "Waiting for > xorp_rtrmgr..." and then dies. I would prefer an option while running > xorpsh rather than something that required recompilation Please try setting the XORP_FINDER_CONNECT_TIMEOUT_MS environmental variable before running xorpsh. E.g., if you want to reduce the waiting time to 5 seconds use a command like: env XORP_FINDER_CONNECT_TIMEOUT_MS=5000 ./xorpsh Note that if you set this variable to some very small value before starting other XORP processes, then some of the XORP processes might fail on startup. Also, this variable might have impact on running operational commands inside xorpsh (i.e., the same timeout value will apply to those commands as well). We are open for suggestions if the preference is for a command-line option instead of an environmental variable. Regards, Pavlin From orante2003 at yahoo.it Wed Nov 8 03:17:03 2006 From: orante2003 at yahoo.it (ORANTE TUCCERI) Date: Wed, 8 Nov 2006 12:17:03 +0100 (CET) Subject: [Xorp-users] ORANTE TUCCERI new code for xorp 1.2 /ospf/area_router my problem Message-ID: <20061108111703.93154.qmail@web26811.mail.ukl.yahoo.com> Hello to all, My idea is to insert pairs wich containing for each router and network lsa into database: the link state id value (e.g 192.168.37.130) present into the LSA place of the _db in which found the lsa containing the link state id (e.g 192.168.37.130) in a container map of the template Standard library I have attached my code. Into the attached file is present also the error message which i have had I hope that it can help me to correct the error .-compiling the code no errors is presents orante2003 at yahoo.it Univ Roma La Sapienza - student __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061108/a42d9f3a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: versione doc del file degli errorihfE.doc.tar.gz Type: application/x-gzip Size: 7581 bytes Desc: 2923173646-versione doc del file degli errorihfE.doc.tar.gz Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061108/a42d9f3a/attachment.gz From orante2003 at yahoo.it Wed Nov 8 03:14:31 2006 From: orante2003 at yahoo.it (ORANTE TUCCERI) Date: Wed, 8 Nov 2006 12:14:31 +0100 (CET) Subject: [Xorp-users] ORANTE TUCCERI new code for xorp 1.2 /ospf/area_router my problem Message-ID: <20061108111431.46466.qmail@web26807.mail.ukl.yahoo.com> Hello to all, My idea is to insert pairs wich containing for each router and network lsa into database: the link state id value (e.g 192.168.37.130) present into the LSA place of the _db in which found the lsa containing the link state id (e.g 192.168.37.130) in a container map of the template Standard library I have attached my code. Into the attached file is present also the error message which i have had I hope that it can help me to correct the error .-compiling the code no errors is presents orante2003 at yahoo.it Univ Roma La Sapienza - student __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061108/d36723de/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: versione doc del file degli errorihfE.doc Type: application/msword Size: 41472 bytes Desc: 456596039-versione doc del file degli errorihfE.doc Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061108/d36723de/attachment-0001.doc From pavlin at icir.org Wed Nov 8 09:31:06 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 08 Nov 2006 09:31:06 -0800 Subject: [Xorp-users] ORANTE TUCCERI new code for xorp 1.2 /ospf/area_router my problem In-Reply-To: Message from ORANTE TUCCERI of "Wed, 08 Nov 2006 12:17:03 +0100." <20061108111703.93154.qmail@web26811.mail.ukl.yahoo.com> Message-ID: <200611081731.kA8HV6gl070903@possum.icir.org> > My idea is to insert pairs wich containing for each router and network lsa into database: > > > the link state id value (e.g 192.168.37.130) present into the LSA > > place of the _db in which found the lsa containing the link state id (e.g 192.168.37.130) > in a container map of the template Standard library > > I have attached my code. > > Into the attached file is present also the error message which i have had > > I hope that it can help me to correct the error > > .-compiling the code no errors is presents It appears that the OSPF process has coredumped. You can use gdb to find the reason. There should be a coredump file in the local directory, the name varies by OS, but usually it contains "core" in its name: gdb path/to/xorp_ospfv2 -c my.core Then print the values of the variables that are referred when the process crashed. Typically, some of them will have invalid value (e.g., NULL pointers being followed, etc). Hope that helps, Pavlin P.S. Please don't use DOC files with information about your code changes, log messages, etc. You should use plain ASCII for that purpose (or a tarball with text files). From cvrider at yahoo.com Wed Nov 8 11:29:48 2006 From: cvrider at yahoo.com (Mark) Date: Wed, 8 Nov 2006 11:29:48 -0800 (PST) Subject: [Xorp-users] QoS and XORP Message-ID: <20061108192948.16450.qmail@web55304.mail.re4.yahoo.com> After reading the XORP manual I don't see any mention of any QoS features for it. Does XORP support any form of QoS or packet classification on any level? Is this something that is in the works? __________________________________________________________________________________________ Sponsored Link Talk more and pay less. Vonage can save you up to $300 a year on your phone bill. Sign up now. http://www.vonage.com/startsavingnow/ From kristian at spritelink.se Wed Nov 8 11:37:11 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Wed, 8 Nov 2006 20:37:11 +0100 Subject: [Xorp-users] QoS and XORP In-Reply-To: <20061108192948.16450.qmail@web55304.mail.re4.yahoo.com> References: <20061108192948.16450.qmail@web55304.mail.re4.yahoo.com> Message-ID: <20061108193710.GC32311@spritelink.se> On Wed, Nov 08, 2006 at 11:29:48AM -0800, Mark wrote: > After reading the XORP manual I don't see any mention > of any QoS features for it. Does XORP support any form > of QoS or packet classification on any level? Is this > something that is in the works? XORP does not handle IP pakcets, and thus can do no QoS classification. XORP is merely control plane software, ie functionality for routing protocols and such. For QoS you need to look at netfilter or something equivalent. Though, perhaps one day you will be able to configure how the kernel should handle QoS via XORP, but that's far from where we are today. Kristian. -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From pavlin at icir.org Wed Nov 8 11:39:44 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 08 Nov 2006 11:39:44 -0800 Subject: [Xorp-users] QoS and XORP In-Reply-To: Message from Mark of "Wed, 08 Nov 2006 11:29:48 PST." <20061108192948.16450.qmail@web55304.mail.re4.yahoo.com> Message-ID: <200611081939.kA8Jdil3081279@possum.icir.org> > After reading the XORP manual I don't see any mention > of any QoS features for it. Does XORP support any form > of QoS or packet classification on any level? Is this > something that is in the works? No, currently XORP doesn't support QoS. It is on our radar, but we don't have any concrete plans (yet) wnen it will be implemented. Regards, Pavlin From cvrider at yahoo.com Wed Nov 8 12:38:34 2006 From: cvrider at yahoo.com (Mark) Date: Wed, 8 Nov 2006 12:38:34 -0800 (PST) Subject: [Xorp-users] QoS and XORP In-Reply-To: <20061108193710.GC32311@spritelink.se> Message-ID: <20061108203839.26124.qmail@web55302.mail.re4.yahoo.com> Does this limitation also apply to access lists where we are blocking packets on the ingress or egress interfaces? I'm not sure if this counts as packet handling. Mark --- Kristian Larsson wrote: > On Wed, Nov 08, 2006 at 11:29:48AM -0800, Mark > wrote: > > After reading the XORP manual I don't see any > mention > > of any QoS features for it. Does XORP support any > form > > of QoS or packet classification on any level? Is > this > > something that is in the works? > > XORP does not handle IP pakcets, and thus can do > no QoS classification. XORP is merely control > plane software, ie functionality for routing > protocols and such. > For QoS you need to look at netfilter or something > equivalent. > > Though, perhaps one day you will be able to > configure how the kernel should handle QoS via > XORP, but that's far from where we are today. > > Kristian. > > -- > Kristian Larsson > KLL-RIPE > Network Engineer Net at Once > [AS35706] > +46 704 910401 kristian at spritelink.se > ____________________________________________________________________________________ Sponsored Link Mortgage rates near historic lows: $150,000 loan as low as $579/mo. Intro-*Terms https://www2.nextag.com/ From kristian at spritelink.se Wed Nov 8 12:42:49 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Wed, 8 Nov 2006 21:42:49 +0100 Subject: [Xorp-users] QoS and XORP In-Reply-To: <20061108203839.26124.qmail@web55302.mail.re4.yahoo.com> References: <20061108193710.GC32311@spritelink.se> <20061108203839.26124.qmail@web55302.mail.re4.yahoo.com> Message-ID: <20061108204248.GD32311@spritelink.se> On Wed, Nov 08, 2006 at 12:38:34PM -0800, Mark wrote: > Does this limitation also apply to access lists where > we are blocking packets on the ingress or egress > interfaces? I'm not sure if this counts as packet > handling. Yupp, that sure is packet handling, packet forwarding or whatever you want to call it. What XORP on a theoretical plane could do is configure netfilter or something like it to do filtering/QoS/whatnot for you but I don't XORP will ever actually touch any packets that are to be routed. Kristian. > --- Kristian Larsson wrote: > > > On Wed, Nov 08, 2006 at 11:29:48AM -0800, Mark > > wrote: > > > After reading the XORP manual I don't see any > > mention > > > of any QoS features for it. Does XORP support any > > form > > > of QoS or packet classification on any level? Is > > this > > > something that is in the works? > > > > XORP does not handle IP pakcets, and thus can do > > no QoS classification. XORP is merely control > > plane software, ie functionality for routing > > protocols and such. > > For QoS you need to look at netfilter or something > > equivalent. > > > > Though, perhaps one day you will be able to > > configure how the kernel should handle QoS via > > XORP, but that's far from where we are today. > > > > Kristian. > > > > -- > > Kristian Larsson > > KLL-RIPE > > Network Engineer Net at Once > > [AS35706] > > +46 704 910401 kristian at spritelink.se > > > > > > > > ____________________________________________________________________________________ > Sponsored Link > > Mortgage rates near historic lows: > $150,000 loan as low as $579/mo. Intro-*Terms > https://www2.nextag.com/ -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From cvrider at yahoo.com Wed Nov 8 16:50:43 2006 From: cvrider at yahoo.com (Mark) Date: Wed, 8 Nov 2006 16:50:43 -0800 (PST) Subject: [Xorp-users] QoS and XORP In-Reply-To: <20061108204248.GD32311@spritelink.se> Message-ID: <20061109005043.38455.qmail@web55306.mail.re4.yahoo.com> Why is it then that Quagga can do ACL's yet XORP cannot? I thought they were almost the same as far as functionality. --- Kristian Larsson wrote: > On Wed, Nov 08, 2006 at 12:38:34PM -0800, Mark > wrote: > > Does this limitation also apply to access lists > where > > we are blocking packets on the ingress or egress > > interfaces? I'm not sure if this counts as packet > > handling. > Yupp, that sure is packet handling, packet > forwarding or whatever you want to call it. > What XORP on a theoretical plane could do is > configure netfilter or something like it to do > filtering/QoS/whatnot for you but I don't XORP > will ever actually touch any packets that are to > be routed. > > Kristian. > > > > > --- Kristian Larsson > wrote: > > > > > On Wed, Nov 08, 2006 at 11:29:48AM -0800, Mark > > > wrote: > > > > After reading the XORP manual I don't see any > > > mention > > > > of any QoS features for it. Does XORP support > any > > > form > > > > of QoS or packet classification on any level? > Is > > > this > > > > something that is in the works? > > > > > > XORP does not handle IP pakcets, and thus can do > > > no QoS classification. XORP is merely control > > > plane software, ie functionality for routing > > > protocols and such. > > > For QoS you need to look at netfilter or > something > > > equivalent. > > > > > > Though, perhaps one day you will be able to > > > configure how the kernel should handle QoS via > > > XORP, but that's far from where we are today. > > > > > > Kristian. > > > > > > -- > > > Kristian Larsson > > > > KLL-RIPE > > > Network Engineer Net at > Once > > > [AS35706] > > > +46 704 910401 kristian at spritelink.se > > > > > > > > > > > > > > > > ____________________________________________________________________________________ > > Sponsored Link > > > > Mortgage rates near historic lows: > > $150,000 loan as low as $579/mo. Intro-*Terms > > https://www2.nextag.com/ > > -- > Kristian Larsson > KLL-RIPE > Network Engineer Net at Once > [AS35706] > +46 704 910401 kristian at spritelink.se > ____________________________________________________________________________________ Sponsored Link Get an Online or Campus degree Associate's, Bachelor's, or Master's - in less than one year. http://www.findtherightschool.com From kristian at spritelink.se Wed Nov 8 17:40:02 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Thu, 9 Nov 2006 02:40:02 +0100 Subject: [Xorp-users] QoS and XORP In-Reply-To: <20061109005043.38455.qmail@web55306.mail.re4.yahoo.com> References: <20061108204248.GD32311@spritelink.se> <20061109005043.38455.qmail@web55306.mail.re4.yahoo.com> Message-ID: <20061109014001.GE32311@spritelink.se> On Wed, Nov 08, 2006 at 04:50:43PM -0800, Mark wrote: > Why is it then that Quagga can do ACL's yet XORP > cannot? I thought they were almost the same as far as > functionality. Can it? It was years since I used Quagga though I don't believe much has changed... it's still control plane software. If there are ways to control ACLs it's just that - control. It's still the underlying OS, the kernel, which handles packet forwarding and thus also packet filtering with the ACLs that Quagga has defined. Kristian. > --- Kristian Larsson wrote: > > > On Wed, Nov 08, 2006 at 12:38:34PM -0800, Mark > > wrote: > > > Does this limitation also apply to access lists > > where > > > we are blocking packets on the ingress or egress > > > interfaces? I'm not sure if this counts as packet > > > handling. > > Yupp, that sure is packet handling, packet > > forwarding or whatever you want to call it. > > What XORP on a theoretical plane could do is > > configure netfilter or something like it to do > > filtering/QoS/whatnot for you but I don't XORP > > will ever actually touch any packets that are to > > be routed. > > > > Kristian. > > > > > > > > > --- Kristian Larsson > > wrote: > > > > > > > On Wed, Nov 08, 2006 at 11:29:48AM -0800, Mark > > > > wrote: > > > > > After reading the XORP manual I don't see any > > > > mention > > > > > of any QoS features for it. Does XORP support > > any > > > > form > > > > > of QoS or packet classification on any level? > > Is > > > > this > > > > > something that is in the works? > > > > > > > > XORP does not handle IP pakcets, and thus can do > > > > no QoS classification. XORP is merely control > > > > plane software, ie functionality for routing > > > > protocols and such. > > > > For QoS you need to look at netfilter or > > something > > > > equivalent. > > > > > > > > Though, perhaps one day you will be able to > > > > configure how the kernel should handle QoS via > > > > XORP, but that's far from where we are today. > > > > > > > > Kristian. > > > > > > > > -- > > > > Kristian Larsson > > > > > > KLL-RIPE > > > > Network Engineer Net at > > Once > > > > [AS35706] > > > > +46 704 910401 kristian at spritelink.se > > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________________________________________________ > > > Sponsored Link > > > > > > Mortgage rates near historic lows: > > > $150,000 loan as low as $579/mo. Intro-*Terms > > > https://www2.nextag.com/ > > > > -- > > Kristian Larsson > > KLL-RIPE > > Network Engineer Net at Once > > [AS35706] > > +46 704 910401 kristian at spritelink.se > > > > > > > > ____________________________________________________________________________________ > Sponsored Link > > Get an Online or Campus degree > Associate's, Bachelor's, or Master's - in less than one year. > http://www.findtherightschool.com -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From pavlin at icir.org Wed Nov 8 18:09:53 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 08 Nov 2006 18:09:53 -0800 Subject: [Xorp-users] QoS and XORP In-Reply-To: Message from Kristian Larsson of "Thu, 09 Nov 2006 02:40:02 +0100." <20061109014001.GE32311@spritelink.se> Message-ID: <200611090209.kA929r8d015943@possum.icir.org> Kristian Larsson wrote: > On Wed, Nov 08, 2006 at 04:50:43PM -0800, Mark wrote: > > Why is it then that Quagga can do ACL's yet XORP > > cannot? I thought they were almost the same as far as > > functionality. > Can it? > It was years since I used Quagga though I don't > believe much has changed... it's still control > plane software. If there are ways to control ACLs > it's just that - control. > It's still the underlying OS, the kernel, which > handles packet forwarding and thus also packet > filtering with the ACLs that Quagga has defined. FYI, the XORP FEA has some backend ACL support (IPFW2 and PF for UNIX, and NF for Windows I believe), but it requires a little bit extra work to have it working: front-end configuration glue, testing, etc. Of course, this is just controling the ACLs inside the kernel which you could always do outside the routing suite (XORP, Quagga, etc) by using the appropriate system configuration/commands. Regards, Pavlin From kristian at spritelink.se Wed Nov 8 18:18:26 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Thu, 9 Nov 2006 03:18:26 +0100 Subject: [Xorp-users] QoS and XORP In-Reply-To: <200611090209.kA929r8d015943@possum.icir.org> References: <20061109014001.GE32311@spritelink.se> <200611090209.kA929r8d015943@possum.icir.org> Message-ID: <20061109021824.GF32311@spritelink.se> On Wed, Nov 08, 2006 at 06:09:53PM -0800, Pavlin Radoslavov wrote: > Kristian Larsson wrote: > > > On Wed, Nov 08, 2006 at 04:50:43PM -0800, Mark wrote: > > > Why is it then that Quagga can do ACL's yet XORP > > > cannot? I thought they were almost the same as far as > > > functionality. > > Can it? > > It was years since I used Quagga though I don't > > believe much has changed... it's still control > > plane software. If there are ways to control ACLs > > it's just that - control. > > It's still the underlying OS, the kernel, which > > handles packet forwarding and thus also packet > > filtering with the ACLs that Quagga has defined. > > FYI, the XORP FEA has some backend ACL support (IPFW2 and PF for > UNIX, and NF for Windows I believe), but it requires a little bit > extra work to have it working: front-end configuration glue, > testing, etc. Yeah, I saw a few CVS commits for that, never thought it was any serious though and I haven't had the chance to look at it. Are these in anyway related to how Vyatta have implemented netfilter control? Kristian. -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From robert at vyatta.com Wed Nov 8 18:28:51 2006 From: robert at vyatta.com (Robert Bays) Date: Wed, 08 Nov 2006 18:28:51 -0800 Subject: [Xorp-users] QoS and XORP In-Reply-To: <20061109021824.GF32311@spritelink.se> References: <20061109014001.GE32311@spritelink.se> <200611090209.kA929r8d015943@possum.icir.org> <20061109021824.GF32311@spritelink.se> Message-ID: <45529263.30103@vyatta.com> Not that we are aware of, but we are more than happy to push back our changes. Though they are very much specific to Linux. Cheers, Robert. Kristian Larsson wrote: > On Wed, Nov 08, 2006 at 06:09:53PM -0800, Pavlin Radoslavov wrote: >> Kristian Larsson wrote: >> >>> On Wed, Nov 08, 2006 at 04:50:43PM -0800, Mark wrote: >>>> Why is it then that Quagga can do ACL's yet XORP >>>> cannot? I thought they were almost the same as far as >>>> functionality. >>> Can it? >>> It was years since I used Quagga though I don't >>> believe much has changed... it's still control >>> plane software. If there are ways to control ACLs >>> it's just that - control. >>> It's still the underlying OS, the kernel, which >>> handles packet forwarding and thus also packet >>> filtering with the ACLs that Quagga has defined. >> FYI, the XORP FEA has some backend ACL support (IPFW2 and PF for >> UNIX, and NF for Windows I believe), but it requires a little bit >> extra work to have it working: front-end configuration glue, >> testing, etc. > Yeah, I saw a few CVS commits for that, never > thought it was any serious though and I haven't > had the chance to look at it. > Are these in anyway related to how Vyatta have > implemented netfilter control? > > Kristian. > From orante2003 at yahoo.it Thu Nov 9 00:17:32 2006 From: orante2003 at yahoo.it (ORANTE TUCCERI) Date: Thu, 9 Nov 2006 09:17:32 +0100 (CET) Subject: [Xorp-users] Orante Tucceri: new code for xorp1.2/ospf -- my problem Message-ID: <20061109081732.82413.qmail@web26803.mail.ukl.yahoo.com> Hello to all, My idea is to insert pairs wich containing for each router and network lsa into database: the link state id value (e.g 192.168.37.130) present into the LSA place of the _db in which found the lsa containing the link state id (e.g 192.168.37.130) in a container map of the template Standard library I have attached my code. Into the attached file is present also the error message which i have had I hope that it can help me to correct the error .-compiling the code no errors is presents orante2003 at yahoo.it Univ Roma La Sapienza - student __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061109/98e0339c/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: ultimo_aggiunteweb.zip Type: application/zip Size: 7599 bytes Desc: 3872458821-ultimo_aggiunteweb.zip Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061109/98e0339c/attachment-0001.zip From ar_djp at yahoo.com Fri Nov 10 00:26:47 2006 From: ar_djp at yahoo.com (ar) Date: Fri, 10 Nov 2006 00:26:47 -0800 (PST) Subject: [Xorp-users] XORP MPLS Implementation Message-ID: <20061110082647.62200.qmail@web90404.mail.mud.yahoo.com> Good day. Does XORP supports MPLS/VPN configurations based also on LDP? --------------------------------- Check out the all-new Yahoo! Mail - Fire up a more powerful email and get things done faster. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061110/de852b19/attachment.html From ar_djp at yahoo.com Fri Nov 10 00:43:28 2006 From: ar_djp at yahoo.com (ar) Date: Fri, 10 Nov 2006 00:43:28 -0800 (PST) Subject: [Xorp-users] Xorp on Linux Message-ID: <20061110084328.29792.qmail@web90411.mail.mud.yahoo.com> can i install xorp on linux redhat 7.1 with 2.4.24 kernel? thanks..... --------------------------------- Sponsored Link Get an Online or Campus degree - Associate's, Bachelor's, or Master's - in less than one year. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061110/08488d03/attachment.html From mhorn at vyatta.com Fri Nov 10 07:00:19 2006 From: mhorn at vyatta.com (Mike Horn) Date: Fri, 10 Nov 2006 08:00:19 -0700 Subject: [Xorp-users] XORP MPLS Implementation In-Reply-To: <20061110082647.62200.qmail@web90404.mail.mud.yahoo.com> Message-ID: <033a01c704d8$f0da3db0$0f02a8c0@caddisconsulting.com> Hi, XORP does not currently support any form of MPLS, including MPLS VPNs. -mike _____ From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of ar Sent: Friday, November 10, 2006 1:27 AM To: xorp-users at xorp.org; xorp-hackers at xorp.org Subject: [Xorp-users] XORP MPLS Implementation Good day. Does XORP supports MPLS/VPN configurations based also on LDP? _____ Check out the all-new Yahoo! Mail - Fire up a more powerful email and get things done faster. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061110/d36c0879/attachment.html From pavlin at icir.org Fri Nov 10 09:25:28 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 10 Nov 2006 09:25:28 -0800 Subject: [Xorp-users] [Xorp-hackers] Xorp on Linux In-Reply-To: Message from ar of "Fri, 10 Nov 2006 00:43:28 PST." <20061110084328.29792.qmail@web90411.mail.mud.yahoo.com> Message-ID: <200611101725.kAAHPSRl070744@possum.icir.org> > can i install xorp on linux redhat 7.1 with 2.4.24 kernel? thanks..... We have tested it on RedHat-7.3 with kernel 2.4-20, so I guess it should work for your setup. If it doesn't, please send an email with the error. Regards, Pavlin From ar_djp at yahoo.com Fri Nov 10 19:43:51 2006 From: ar_djp at yahoo.com (ar) Date: Fri, 10 Nov 2006 19:43:51 -0800 (PST) Subject: [Xorp-users] [Xorp-hackers] Xorp on Linux In-Reply-To: <200611101725.kAAHPSRl070744@possum.icir.org> Message-ID: <20061111034351.89524.qmail@web90406.mail.mud.yahoo.com> alright thanks.... Pavlin Radoslavov wrote: > can i install xorp on linux redhat 7.1 with 2.4.24 kernel? thanks..... We have tested it on RedHat-7.3 with kernel 2.4-20, so I guess it should work for your setup. If it doesn't, please send an email with the error. Regards, Pavlin --------------------------------- Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061110/49286350/attachment.html From ar_djp at yahoo.com Fri Nov 10 19:45:07 2006 From: ar_djp at yahoo.com (ar) Date: Fri, 10 Nov 2006 19:45:07 -0800 (PST) Subject: [Xorp-users] XORP MPLS Implementation In-Reply-To: <033a01c704d8$f0da3db0$0f02a8c0@caddisconsulting.com> Message-ID: <20061111034507.36404.qmail@web90404.mail.mud.yahoo.com> ok thanks..... Mike Horn wrote: Hi, XORP does not currently support any form of MPLS, including MPLS VPNs. -mike --------------------------------- From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of ar Sent: Friday, November 10, 2006 1:27 AM To: xorp-users at xorp.org; xorp-hackers at xorp.org Subject: [Xorp-users] XORP MPLS Implementation Good day. Does XORP supports MPLS/VPN configurations based also on LDP? --------------------------------- Check out the all-new Yahoo! Mail - Fire up a more powerful email and get things done faster. --------------------------------- Access over 1 million songs - Yahoo! Music Unlimited. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061110/35341137/attachment.html From sim at compulab.co.il Sun Nov 12 04:07:14 2006 From: sim at compulab.co.il (Sim Zacks) Date: Sun, 12 Nov 2006 14:07:14 +0200 Subject: [Xorp-users] NAT on multiple interfaces Message-ID: <465381860.20061112140714@compulab.co.il> I have 2 WAN lines coming into my xorp router and one going out to my LAN. I would to be able to define the NAT rules once to be effective for both incoming ports. (All IP Addresses listed here are pretend) For example, I want to configure a NAT rule so ssh (port 22) should go to ip address 192.168.0.100. One WAN line is 211.10.5.41 on eth1 and the other is 75.99.8.15 on eth2 I would like one rule so that whether you go to either of the WAN IP addresses it will take you to the correct computer. >From what I understand of this, I need to specify an inbound-interface, which means that a rule only can work for one WAN address. Is this true? Thank You Sim Zacks IT Manager CompuLab 04-829-0145 - Office 04-832-5251 - Fax From lleandro at gmail.com Thu Nov 9 12:28:41 2006 From: lleandro at gmail.com (Leandro Castanheira) Date: Thu, 9 Nov 2006 18:28:41 -0200 Subject: [Xorp-users] Multicast routing Message-ID: Hi. I have tried to configure my xorp to routing multicast packges, but something is going wrong. Well, I have one router that have 2 interfaces, eth0(200.77.0.2) other to the internet and eth1(192.168.0.1) . I have another router link to the first eth1(192.168.0.1) router by the its eth1 (192.168.0.86) and your another interface is eth0(192.168.2.1). Both ara running Xorp with the files configuration below. I had one computer link to the second router by subnet 192.168.2.0/24 with ip (192.168.2.2), who is streaming a movie by VLC to the group 239.255.12.42. And I trying to recieve this streaming by another computer who has this eth0 IP (200.77.0.5). But it does't work. If I stream from another computer from subnet 192.168.0.0/24 like the 192.168.0.21computer, I can recieve in both, the one which has the ip ( 192.168.2.2) and the one which has the (200.77.0.5). And I can ping the 200.77.0.5 from the 192.168.2.2. What can I do to stream from 192.168.2.2 an recieve in 200.77.0.5 Thanks, Leandro Files: *********************************************************************************************** First router (200.17.0.2) *********************************************************************************************** /*XORP Configuration File*/ interfaces { interface eth0 { description: "Ethernet" disable: false vif eth0 { disable: false address 200.17.0.2 { prefix-length: 24 broadcast: 200.17.77.255 disable: false } } } interface eth1 { description: "Ethernet" disable: false vif eth1 { disable: false address 192.168.0.1 { prefix-length: 24 broadcast: 192.168.0.255 disable: false } } } interface lo { description: "Loopback interface" vif lo { } } } fea{ unicast-forwarding4 { disable: false } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } } protocols { igmp { disable: false interface eth0 { vif eth0 { disable: false /* version: 2 */ /* enable-ip-router-alert-option-check: false */ /* query-interval: 125 */ /* query-last-member-interval: 1 */ /* query-response-interval: 10 */ /* robust-count: 2 */ } } interface eth1 { vif eth1 { disable: false /* version: 2 */ /* enable-ip-router-alert-option-check: false */ /* query-interval: 125 */ /* query-last-member-interval: 1 */ /* query-response-interval: 10 */ /* robust-count: 2 */ } } traceoptions { flag all { disable: false } } } } protocols { pimsm4 { disable: false interface eth0 { vif eth0 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface eth1 { vif eth1 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } /*static-rps { rp 10.60.0.1 { group-prefix 224.0.0.0/4 { /* rp-priority: 192 */ /* hash-mask-len: 30 */ /* } } } bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/4 { /* is-scope-zone: false */ /* cand-bsr-by-vif-name: "eth0" /* cand-bsr-by-vif-addr: 10.10.10.10 */ /* bsr-priority: 1 */ /* hash-mask-len: 30 */ /* } } cand-rp { group-prefix 224.0.0.0/4 { /* is-scope-zone: false */ /* cand-rp-by-vif-name: "eth0" /* cand-rp-by-vif-addr: 10.10.10.10 */ /* rp-priority: 192 */ /* rp-holdtime: 150 */ /* } } } */ switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } } *********************************************************************************************** Second router 192.168.2.1 *********************************************************************************************** /*XORP Configuration File*/ interfaces { interface eth0 { description: "Ethernet" disable: false vif eth0 { disable: false address 192.168.2.1 { prefix-length: 24 broadcast: 192.168.2.255 disable: false } } } interface eth1 { description: "Ethernet" disable: false vif eth1 { disable: false address 192.168.0.86 { prefix-length: 24 broadcast: 192.168.0.255 disable: false } } } interface lo { description: "Loopback interface" vif lo { } } } fea{ unicast-forwarding4 { disable: false } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } } protocols { igmp { disable: false interface eth0 { vif eth0 { disable: false /* version: 2 */ /* enable-ip-router-alert-option-check: false */ /* query-interval: 125 */ /* query-last-member-interval: 1 */ /* query-response-interval: 10 */ /* robust-count: 2 */ } } interface eth1 { vif eth1 { disable: false /* version: 2 */ /* enable-ip-router-alert-option-check: false */ /* query-interval: 125 */ /* query-last-member-interval: 1 */ /* query-response-interval: 10 */ /* robust-count: 2 */ } } traceoptions { flag all { disable: false } } } } protocols { pimsm4 { disable: false interface eth0 { vif eth0 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface eth1 { vif eth1 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } /*static-rps { rp 10.60.0.1 { group-prefix 224.0.0.0/4 { /* rp-priority: 192 */ /* hash-mask-len: 30 */ /* } } } bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/4 { /* is-scope-zone: false */ /* cand-bsr-by-vif-name: "eth0" /* cand-bsr-by-vif-addr: 10.10.10.10 */ /* bsr-priority: 1 */ /* hash-mask-len: 30 */ /* } } cand-rp { group-prefix 224.0.0.0/4 { /* is-scope-zone: false */ /* cand-rp-by-vif-name: "eth0" /* cand-rp-by-vif-addr: 10.10.10.10 */ /* rp-priority: 192 */ /* rp-holdtime: 150 */ /* } } } */ switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061109/c77add7e/attachment-0001.html From pavlin at icir.org Mon Nov 13 11:04:24 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 13 Nov 2006 11:04:24 -0800 Subject: [Xorp-users] NAT on multiple interfaces In-Reply-To: Message from Sim Zacks of "Sun, 12 Nov 2006 14:07:14 +0200." <465381860.20061112140714@compulab.co.il> Message-ID: <200611131904.kADJ4OC7065254@possum.icir.org> > I have 2 WAN lines coming into my xorp router and one going out to my > LAN. I would to be able to define the NAT rules once to be effective > for both incoming ports. > (All IP Addresses listed here are pretend) > For example, I want to configure a NAT rule so ssh (port 22) should go > to ip address 192.168.0.100. > One WAN line is 211.10.5.41 on eth1 and the other is 75.99.8.15 on > eth2 > > I would like one rule so that whether you go to either of the WAN IP > addresses it will take you to the correct computer. > From what I understand of this, I need to specify an > inbound-interface, which means that a rule only can work for one > WAN address. > > Is this true? XORP doesn't support NAT configuration (yet). Whatever NAT rules you want to apply, you have to do it outside of XORP by using the mechanism provided by the underlying system. Hence, the answer to your question is OS specific (e.g., natd(8) on FreeBSD, iptables(8) on Linux, etc). >From a quick reading of the iptables(8) manual page (on Gentoo), it appears that the "-i" option is not mandatory: "If this option is omitted, any interface name will match." In other words, it looks like on Linux you can achieve what you want with a single NAT rule. Check the corresponding manual page if you use a different OS. Regards, Pavlin From pavlin at icir.org Mon Nov 13 11:58:40 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 13 Nov 2006 11:58:40 -0800 Subject: [Xorp-users] Multicast routing In-Reply-To: Message from "Leandro Castanheira" of "Thu, 09 Nov 2006 18:28:41 -0200." Message-ID: <200611131958.kADJwemu065725@possum.icir.org> > I have tried to configure my xorp to routing multicast packges, but > something is going wrong. > Well, I have one router that have 2 interfaces, eth0(200.77.0.2) other to ~~~~~~~~~~~~~~~~ In your configuration below the IP address of eth0 is 200.17.0.2 instead of 200.77.0.2. Which one is correct? Also, you have configured the broadcast address for 200.17.0.2/24 as 200.17.77.255. Based on the configured IP address and prefix length, typically this address should be 200.17.0.255, unless you are doing something very unusual on your subnet. Of course, if the IP address of eth0 is indeed 200.77.0.2, then the broadcast address should be 200.77.0.255. BTW, if you start with interfaces that don't have configured IP addresses, you can omit the broadcast address from your configuration, because XORP will automatically calculate it for you. If you have already (mis)configured your IP addresses, then you should delete them first before reconfiguring the interfaces. > the internet and eth1(192.168.0.1) . I have another router link to the > first eth1(192.168.0.1) router by the its eth1 (192.168.0.86) and your > another interface is eth0(192.168.2.1). Both ara running Xorp with the files > configuration below. I had one computer link to the second router by subnet > 192.168.2.0/24 with ip (192.168.2.2), who is streaming a movie by VLC to the > group 239.255.12.42. And I trying to recieve this streaming by another > computer who has this eth0 IP (200.77.0.5). But it does't work. If I stream > from another computer from subnet 192.168.0.0/24 like the > 192.168.0.21computer, I can recieve in both, the one which has the ip > ( > 192.168.2.2) and the one which has the (200.77.0.5). And I can ping the > 200.77.0.5 from the 192.168.2.2. > What can I do to stream from 192.168.2.2 an recieve in 200.77.0.5 In addition of fixing the IP address and the broadcast address, make sure that the TTL of the multicast stream is large enough. Typically, by default the multicast traffic is sent by TTL of 1 so it will be dropped before it reaches the receive. Finally, from reading your configuration I couldn't figure out what is the Cand-RP set, because bunch of things were (partially?) commented-out. I'd recommend to remove the configuration for the bootstrap mechanism, and use a single static RP. That static RP has to be one of the IP addresses of the two XORP routers. The IP address you have configured 10.60.0.1 doesn't seem to belong to any of your XORP routers. Regards, Pavlin > Thanks, > Leandro > > Files: > *********************************************************************************************** > First router (200.17.0.2) > *********************************************************************************************** > /*XORP Configuration File*/ > interfaces { > interface eth0 { > description: "Ethernet" > disable: false > vif eth0 { > disable: false > address 200.17.0.2 { > prefix-length: 24 > broadcast: 200.17.77.255 > disable: false > } > } > } > interface eth1 { > description: "Ethernet" > disable: false > vif eth1 { > disable: false > address 192.168.0.1 { > prefix-length: 24 > broadcast: 192.168.0.255 > disable: false > } > } > } > interface lo { > description: "Loopback interface" > vif lo { > } > } > } > fea{ > unicast-forwarding4 { > disable: false > } > > } > > > plumbing { > mfea4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > > interface eth1 { > vif eth1 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > protocols { > igmp { > disable: false > interface eth0 { > vif eth0 { > disable: false > /* version: 2 */ > /* enable-ip-router-alert-option-check: false */ > /* query-interval: 125 */ > /* query-last-member-interval: 1 */ > /* query-response-interval: 10 */ > /* robust-count: 2 */ > } > } > interface eth1 { > vif eth1 { > disable: false > /* version: 2 */ > /* enable-ip-router-alert-option-check: false */ > /* query-interval: 125 */ > /* query-last-member-interval: 1 */ > /* query-response-interval: 10 */ > /* robust-count: 2 */ > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > protocols { > pimsm4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > /* enable-ip-router-alert-option-check: false */ > /* dr-priority: 1 */ > /* hello-period: 30 */ > /* hello-triggered-delay: 5 */ > /* alternative-subnet 10.40.0.0/16 */ > } > } > interface eth1 { > vif eth1 { > disable: false > /* enable-ip-router-alert-option-check: false */ > /* dr-priority: 1 */ > /* hello-period: 30 */ > /* hello-triggered-delay: 5 */ > /* alternative-subnet 10.40.0.0/16 */ > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > > /*static-rps { > rp 10.60.0.1 { > group-prefix 224.0.0.0/4 { > /* rp-priority: 192 */ > /* hash-mask-len: 30 */ > /* } > } > } > > bootstrap { > disable: false > cand-bsr { > scope-zone 224.0.0.0/4 { > /* is-scope-zone: false */ > /* cand-bsr-by-vif-name: "eth0" > /* cand-bsr-by-vif-addr: 10.10.10.10 */ > /* bsr-priority: 1 */ > /* hash-mask-len: 30 */ > /* } > } > > cand-rp { > group-prefix 224.0.0.0/4 { > /* is-scope-zone: false */ > /* cand-rp-by-vif-name: "eth0" > /* cand-rp-by-vif-addr: 10.10.10.10 */ > /* rp-priority: 192 */ > /* rp-holdtime: 150 */ > /* } > } > } > */ > switch-to-spt-threshold { > /* approx. 1K bytes/s (10Kbps) threshold */ > disable: false > interval: 100 > bytes: 102400 > } > > traceoptions { > flag all { > disable: false > } > } > } > } > > *********************************************************************************************** > Second router 192.168.2.1 > *********************************************************************************************** > /*XORP Configuration File*/ > interfaces { > interface eth0 { > description: "Ethernet" > disable: false > vif eth0 { > disable: false > address 192.168.2.1 { > prefix-length: 24 > broadcast: 192.168.2.255 > disable: false > } > } > } > interface eth1 { > description: "Ethernet" > disable: false > vif eth1 { > disable: false > address 192.168.0.86 { > prefix-length: 24 > broadcast: 192.168.0.255 > disable: false > } > } > } > interface lo { > description: "Loopback interface" > vif lo { > } > } > } > fea{ > unicast-forwarding4 { > disable: false > } > > } > > plumbing { > mfea4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > > interface eth1 { > vif eth1 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > protocols { > igmp { > disable: false > interface eth0 { > vif eth0 { > disable: false > /* version: 2 */ > /* enable-ip-router-alert-option-check: false */ > /* query-interval: 125 */ > /* query-last-member-interval: 1 */ > /* query-response-interval: 10 */ > /* robust-count: 2 */ > } > } > interface eth1 { > vif eth1 { > disable: false > /* version: 2 */ > /* enable-ip-router-alert-option-check: false */ > /* query-interval: 125 */ > /* query-last-member-interval: 1 */ > /* query-response-interval: 10 */ > /* robust-count: 2 */ > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > protocols { > pimsm4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > /* enable-ip-router-alert-option-check: false */ > /* dr-priority: 1 */ > /* hello-period: 30 */ > /* hello-triggered-delay: 5 */ > /* alternative-subnet 10.40.0.0/16 */ > } > } > interface eth1 { > vif eth1 { > disable: false > /* enable-ip-router-alert-option-check: false */ > /* dr-priority: 1 */ > /* hello-period: 30 */ > /* hello-triggered-delay: 5 */ > /* alternative-subnet 10.40.0.0/16 */ > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > > /*static-rps { > rp 10.60.0.1 { > group-prefix 224.0.0.0/4 { > /* rp-priority: 192 */ > /* hash-mask-len: 30 */ > /* } > } > } > > bootstrap { > disable: false > cand-bsr { > scope-zone 224.0.0.0/4 { > /* is-scope-zone: false */ > /* cand-bsr-by-vif-name: "eth0" > /* cand-bsr-by-vif-addr: 10.10.10.10 */ > /* bsr-priority: 1 */ > /* hash-mask-len: 30 */ > /* } > } > > cand-rp { > group-prefix 224.0.0.0/4 { > /* is-scope-zone: false */ > /* cand-rp-by-vif-name: "eth0" > /* cand-rp-by-vif-addr: 10.10.10.10 */ > /* rp-priority: 192 */ > /* rp-holdtime: 150 */ > /* } > } > } > */ > switch-to-spt-threshold { > /* approx. 1K bytes/s (10Kbps) threshold */ > disable: false > interval: 100 > bytes: 102400 > } > > traceoptions { > flag all { > disable: false > } > } > } > } > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From ar_djp at yahoo.com Mon Nov 13 23:23:02 2006 From: ar_djp at yahoo.com (ar) Date: Mon, 13 Nov 2006 23:23:02 -0800 (PST) Subject: [Xorp-users] Does XORP Supports Multicast Routing? In-Reply-To: <200611101725.kAAHPSRl070744@possum.icir.org> Message-ID: <20061114072302.11867.qmail@web90402.mail.mud.yahoo.com> anyone tried using xorp for multicast routing? thanks --------------------------------- Sponsored Link For just $24.99/mo., Vonage offers unlimited local and long- distance calling. Sign up now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061113/f08bf7e6/attachment.html From kristian at spritelink.se Mon Nov 13 23:51:50 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Tue, 14 Nov 2006 08:51:50 +0100 Subject: [Xorp-users] Does XORP Supports Multicast Routing? In-Reply-To: <20061114072302.11867.qmail@web90402.mail.mud.yahoo.com> References: <200611101725.kAAHPSRl070744@possum.icir.org> <20061114072302.11867.qmail@web90402.mail.mud.yahoo.com> Message-ID: <20061114075149.GB31500@spritelink.se> On Mon, Nov 13, 2006 at 11:23:02PM -0800, ar wrote: > anyone tried using xorp for multicast routing? thanks Yes and it's working just fine. There is quite a lot of documentation on the PIM part of XORP. -K -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From mhorn at vyatta.com Tue Nov 14 16:37:31 2006 From: mhorn at vyatta.com (Mike Horn) Date: Tue, 14 Nov 2006 17:37:31 -0700 Subject: [Xorp-users] Policy network4 operator Message-ID: <032c01c7084e$3e73b470$0f02a8c0@caddisconsulting.com> > Hi all, > > Pavlin and I have been discussing what the "right" direction should be for > the network4 operator in policy statements. Right now if you specify > "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 and longer > prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > > My recommendation is to change the operator from "<=" matches longer > prefixes to ">=" matches longer prefixes, since this seems more intuitive > to me (/9 is > /8) and this would make it match the "prefix-length4" > operator where "prefix-length4 > 24" matches all prefixes longer than /24. > > Which do you prefer: > > A) keep it the way it is now, < matches longer prefixes > B) changing it to use > for longer prefix matches > > Btw, the bug on this is 358 > > http://www.xorp.org/bugzilla/show_bug.cgi?id=358 > > -mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061114/673248da/attachment.html From pavlin at icir.org Tue Nov 14 17:11:55 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 14 Nov 2006 17:11:55 -0800 Subject: [Xorp-users] Policy network4 operator In-Reply-To: Message from "Mike Horn" of "Tue, 14 Nov 2006 17:37:31 MST." <032c01c7084e$3e73b470$0f02a8c0@caddisconsulting.com> Message-ID: <200611150111.kAF1Bts6023718@possum.icir.org> > > Pavlin and I have been discussing what the "right" direction should be for > > the network4 operator in policy statements. Right now if you specify > > "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 and longer > > prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > > > > My recommendation is to change the operator from "<=" matches longer > > prefixes to ">=" matches longer prefixes, since this seems more intuitive > > to me (/9 is > /8) and this would make it match the "prefix-length4" > > operator where "prefix-length4 > 24" matches all prefixes longer than /24. > > > > Which do you prefer: > > > > A) keep it the way it is now, < matches longer prefixes > > B) changing it to use > for longer prefix matches The reason I prefer (A) is because my interpretation of the "<=" operator in the context of network prefixes is "subset". E.g., my interpretation of "network4 <= 10.0.0.0/8" is: "Network that is a subset of 10.0.0.0/8." Another interpretation that I found useful and is also consistent with the "<=" direction is: "Network that overlaps with 10.0.0.0/8 and has same as or fewer addresses than 10.0.0.0/8." The whole issue comes down to the meaning of "<=, <, >, >=" within the context of network prefixes. Your interpretation is integer comparison of the corresponding network prefix lengths, while my interpretation is subset/superset relation of the network prefixes themselves. Thanks, Pavlin > > Btw, the bug on this is 358 > > > > http://www.xorp.org/bugzilla/show_bug.cgi?id=358 > > > > -mike > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From robert at vyatta.com Tue Nov 14 17:13:04 2006 From: robert at vyatta.com (Robert Bays) Date: Tue, 14 Nov 2006 17:13:04 -0800 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: <032c01c7084e$3e73b470$0f02a8c0@caddisconsulting.com> References: <032c01c7084e$3e73b470$0f02a8c0@caddisconsulting.com> Message-ID: <455A69A0.4050509@vyatta.com> Maybe it makes more sense to use Juniper terminology; exact, longer, orlonger, through, upto... Short of that, I prefer option B. Cheers, Robert. Mike Horn wrote: > Hi all, > > Pavlin and I have been discussing what the "right" direction should be > for the network4 operator in policy statements. Right now if you > specify "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 and > longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > > My recommendation is to change the operator from "<=" matches longer > prefixes to ">=" matches longer prefixes, since this seems more > intuitive to me (/9 is > /8) and this would make it match the > "prefix-length4" operator where "prefix-length4 > 24" matches all > prefixes longer than /24. > > Which do you prefer: > > A) keep it the way it is now, < matches longer prefixes > B) changing it to use > for longer prefix matches > > Btw, the bug on this is 358 > > _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ > > -mike > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian at spritelink.se Tue Nov 14 23:27:08 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Wed, 15 Nov 2006 08:27:08 +0100 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: <455A69A0.4050509@vyatta.com> References: <032c01c7084e$3e73b470$0f02a8c0@caddisconsulting.com> <455A69A0.4050509@vyatta.com> Message-ID: <20061115072707.GE31500@spritelink.se> I think Roberts idea is just great, why not copy Juniper terminology. We already got a Juniper lookalike shell. And just as robert.. I'd go with option B if I had to choose between the two. -K On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote: > Maybe it makes more sense to use Juniper terminology; exact, longer, > orlonger, through, upto... > > Short of that, I prefer option B. > > Cheers, > Robert. > > Mike Horn wrote: > > Hi all, > > > > Pavlin and I have been discussing what the "right" direction should be > > for the network4 operator in policy statements. Right now if you > > specify "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 and > > longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > > > > My recommendation is to change the operator from "<=" matches longer > > prefixes to ">=" matches longer prefixes, since this seems more > > intuitive to me (/9 is > /8) and this would make it match the > > "prefix-length4" operator where "prefix-length4 > 24" matches all > > prefixes longer than /24. > > > > Which do you prefer: > > > > A) keep it the way it is now, < matches longer prefixes > > B) changing it to use > for longer prefix matches > > > > Btw, the bug on this is 358 > > > > _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ > > > > -mike > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From dave at vyatta.com Wed Nov 15 09:45:43 2006 From: dave at vyatta.com (Dave Roberts) Date: Wed, 15 Nov 2006 09:45:43 -0800 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: <20061115072707.GE31500@spritelink.se> References: <032c01c7084e$3e73b470$0f02a8c0@caddisconsulting.com> <455A69A0.4050509@vyatta.com> <20061115072707.GE31500@spritelink.se> Message-ID: <455B5247.9050304@vyatta.com> Being a product manager at heart, my advice would be to follow industry conventions here. The fact is, the industry has already solved this problem and there are certain expectations of operating behavior and terminology that router users already have. So why reinvent the wheel? Violating the norms of the vast majority of users just seems senseless. My conclusion is that Robert's suggestion of adopting Juniper terminology and behavior seems like a no-brainer. Failing that, look at what Cisco does and base something off that. But whatever you do, don't go inventing new terminology and behavior without a *STRONG* reason for doing so; all you will do is end up confusing the vast majority of users that are schooled on existing products. Complex router configurations are difficult enough to get debugged and working without users having to remember that XORP is the one router on the planet that does something needlessly different. -- Dave Kristian Larsson wrote: > I think Roberts idea is just great, why not copy > Juniper terminology. We already got a Juniper > lookalike shell. > > And just as robert.. I'd go with option B if I had > to choose between the two. > > -K > > On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote: >> Maybe it makes more sense to use Juniper terminology; exact, longer, >> orlonger, through, upto... >> >> Short of that, I prefer option B. >> >> Cheers, >> Robert. >> >> Mike Horn wrote: >>> Hi all, >>> >>> Pavlin and I have been discussing what the "right" direction should be >>> for the network4 operator in policy statements. Right now if you >>> specify "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 and >>> longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). >>> >>> My recommendation is to change the operator from "<=" matches longer >>> prefixes to ">=" matches longer prefixes, since this seems more >>> intuitive to me (/9 is > /8) and this would make it match the >>> "prefix-length4" operator where "prefix-length4 > 24" matches all >>> prefixes longer than /24. >>> >>> Which do you prefer: >>> >>> A) keep it the way it is now, < matches longer prefixes >>> B) changing it to use > for longer prefix matches >>> >>> Btw, the bug on this is 358 >>> >>> _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ >>> >>> -mike >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Xorp-hackers mailing list >>> Xorp-hackers at icir.org >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From pavlin at icir.org Thu Nov 16 16:58:41 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 16 Nov 2006 16:58:41 -0800 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: Message from Dave Roberts of "Wed, 15 Nov 2006 09:45:43 PST." <455B5247.9050304@vyatta.com> Message-ID: <200611170058.kAH0wfAi054219@possum.icir.org> Dave Roberts wrote: > Being a product manager at heart, my advice would be to follow industry > conventions here. The fact is, the industry has already solved this > problem and there are certain expectations of operating behavior and > terminology that router users already have. So why reinvent the wheel? > Violating the norms of the vast majority of users just seems senseless. > > My conclusion is that Robert's suggestion of adopting Juniper > terminology and behavior seems like a no-brainer. Failing that, look at > what Cisco does and base something off that. But whatever you do, don't > go inventing new terminology and behavior without a *STRONG* reason for > doing so; all you will do is end up confusing the vast majority of users > that are schooled on existing products. Complex router configurations > are difficult enough to get debugged and working without users having to > remember that XORP is the one router on the planet that does something > needlessly different. In an ideal world we can change any of the configuration semantics in any way we like so we won't be having this discussion. About the suggestion to follow what other have done. Syntax-wise, even Cisco and Juniper are doing things very differently, so there is no universal solution that we can just reuse. I checked the Cisco documentation online about the relevant policy semantics, and the closest I found is along the lines: ============================================================= Cisco IOS IP Command Reference, Volume 2 of 4: Routing Protocols Release 12.3 T http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a008017d02f.html and Routing Policy Language Commands on Cisco IOS XR Software http://www.cisco.com/en/US/products/ps5763/products_command_reference_chapter09186a00803b0e1b.html Some examples from the first document are: To accept a mask length of up to 24 bits in routes with the prefix 192/8: ip prefix-list abc permit 192.168.0.0/8 le 24 To deny mask lengths greater than 25 bits in routes with a prefix of 192/8: ip prefix-list abc deny 192.168.0.0/8 ge 25 To permit mask lengths from 8 to 24 bits in all address space: ip prefix-list abc permit 0.0.0.0/0 ge 8 le 24 To deny mask lengths greater than 25 bits in all address space: ip prefix-list abc deny 0.0.0.0/0 ge 25 To deny all routes with a prefix of 10/8: ip prefix-list abc deny 10.0.0.0/8 le 32 ============================================================= As you can see, the syntax is very different from XORP, the "ge | le" arguments are of different type (network mask length), etc, so we cannot reuse or adapt this. The Juniper syntax for network address matching is like: route-filter 192.168.0.0/16 exact; route-filter 192.168.0.0/16 longer; route-filter 192.168.0.0/16 orlonger; route-filter 192.168.0.0/16 upto /24 reject; route-filter 192.168.0.0/16 through 192.168.16.0/20; route-filter 192.168.0.0/16 prefix-length-range /26-/30 reject; Futhermore, Juniper allows you to have more than one route-filter statement per block. Our rtrmgr simply cannot be modified to support syntax like this. If we ever rewrite the rtrmgr (see Bugzilla entry #677), then there is some chance it might be easier to extend it with some of this syntax, but for now this is just not an option. The best we could do is to take the exact/longer/orlonger keywords from the first three examples, and support them similar to the existing comparison operators: "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" Note that the last three keywords (shorter/orshorter/not) don't exist in Juniper, so feel free to suggest better names. And, no, the rtrmgr template syntax doesn't allow us to have the tokens ordered same like in Juniper: "network4 10.0.0.0/8 exact". Have in mind that even such change is going to be very ugly (we need to add hacks to the rtrmgr AND the policy manager), and there is no guarantee it will actually work properly before we actually try it. Any other syntax changes are just no-starters with what we have now. About the suggestion of changing the direction of the "<=" operator: if you think that the current direction is wrong (which I strongly disagree with) or confusing, then just changing the direction is going to be ever more confusing, so this shouldn't be an option. To summarize, here are the choices I see: (1) Do nothing and use the current "<=" and friends syntax. (2) Add the hack for the "exact/longer/orlonger..." support as in the examples given above. If anyone has any other suggestions, please be very specific (and realistic) with examples what the syntax should look like, rather than being vague with "follow vendor FOO". Pavlin > -- Dave > > Kristian Larsson wrote: > > I think Roberts idea is just great, why not copy > > Juniper terminology. We already got a Juniper > > lookalike shell. > > > > And just as robert.. I'd go with option B if I had > > to choose between the two. > > > > -K > > > > On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote: > >> Maybe it makes more sense to use Juniper terminology; exact, longer, > >> orlonger, through, upto... > >> > >> Short of that, I prefer option B. > >> > >> Cheers, > >> Robert. > >> > >> Mike Horn wrote: > >>> Hi all, > >>> > >>> Pavlin and I have been discussing what the "right" direction should be > >>> for the network4 operator in policy statements. Right now if you > >>> specify "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 and > >>> longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > >>> > >>> My recommendation is to change the operator from "<=" matches longer > >>> prefixes to ">=" matches longer prefixes, since this seems more > >>> intuitive to me (/9 is > /8) and this would make it match the > >>> "prefix-length4" operator where "prefix-length4 > 24" matches all > >>> prefixes longer than /24. > >>> > >>> Which do you prefer: > >>> > >>> A) keep it the way it is now, < matches longer prefixes > >>> B) changing it to use > for longer prefix matches > >>> > >>> Btw, the bug on this is 358 > >>> > >>> _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ > >>> > >>> -mike > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> Xorp-hackers mailing list > >>> Xorp-hackers at icir.org > >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > >> _______________________________________________ > >> Xorp-users mailing list > >> Xorp-users at xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From mhorn at vyatta.com Thu Nov 16 17:26:40 2006 From: mhorn at vyatta.com (Mike Horn) Date: Thu, 16 Nov 2006 18:26:40 -0700 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: <200611170058.kAH0wfAi054219@possum.icir.org> Message-ID: <00d401c709e7$6f5bc8d0$0f02a8c0@caddisconsulting.com> Hi Pavlin, I agree, Cisco and Juniper syntax are very different, and there really isn't an "industry standard". You only listed the following options: (1) Do nothing and use the current "<=" and friends syntax. (2) Add the hack for the "exact/longer/orlonger..." support as in the examples given above. Isn't another option to flip the meaning of the sign? In which case > would mean longer prefixes, so network4 > 10.0.0.0/8 would be any 10.X prefixes with a prefix length longer than 8. This would be aligned with Cisco's use of "ge" and "le" and seems like from the limited responses to be everyone's preference. What do you think about using this as an interim approach? -mike -----Original Message----- From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Pavlin Radoslavov Sent: Thursday, November 16, 2006 5:59 PM To: Dave Roberts Cc: xorp-users at xorp.org; Robert Bays; Kristian Larsson; mhorn at vyatta.com; xorp-hackers at xorp.org Subject: Re: [Xorp-hackers] [Xorp-users] Policy network4 operator Dave Roberts wrote: > Being a product manager at heart, my advice would be to follow > industry conventions here. The fact is, the industry has already > solved this problem and there are certain expectations of operating > behavior and terminology that router users already have. So why reinvent the wheel? > Violating the norms of the vast majority of users just seems senseless. > > My conclusion is that Robert's suggestion of adopting Juniper > terminology and behavior seems like a no-brainer. Failing that, look > at what Cisco does and base something off that. But whatever you do, > don't go inventing new terminology and behavior without a *STRONG* > reason for doing so; all you will do is end up confusing the vast > majority of users that are schooled on existing products. Complex > router configurations are difficult enough to get debugged and working > without users having to remember that XORP is the one router on the > planet that does something needlessly different. In an ideal world we can change any of the configuration semantics in any way we like so we won't be having this discussion. About the suggestion to follow what other have done. Syntax-wise, even Cisco and Juniper are doing things very differently, so there is no universal solution that we can just reuse. I checked the Cisco documentation online about the relevant policy semantics, and the closest I found is along the lines: ============================================================= Cisco IOS IP Command Reference, Volume 2 of 4: Routing Protocols Release 12.3 T http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_refe rence_chapter09186a008017d02f.html and Routing Policy Language Commands on Cisco IOS XR Software http://www.cisco.com/en/US/products/ps5763/products_command_reference_chapte r09186a00803b0e1b.html Some examples from the first document are: To accept a mask length of up to 24 bits in routes with the prefix 192/8: ip prefix-list abc permit 192.168.0.0/8 le 24 To deny mask lengths greater than 25 bits in routes with a prefix of 192/8: ip prefix-list abc deny 192.168.0.0/8 ge 25 To permit mask lengths from 8 to 24 bits in all address space: ip prefix-list abc permit 0.0.0.0/0 ge 8 le 24 To deny mask lengths greater than 25 bits in all address space: ip prefix-list abc deny 0.0.0.0/0 ge 25 To deny all routes with a prefix of 10/8: ip prefix-list abc deny 10.0.0.0/8 le 32 ============================================================= As you can see, the syntax is very different from XORP, the "ge | le" arguments are of different type (network mask length), etc, so we cannot reuse or adapt this. The Juniper syntax for network address matching is like: route-filter 192.168.0.0/16 exact; route-filter 192.168.0.0/16 longer; route-filter 192.168.0.0/16 orlonger; route-filter 192.168.0.0/16 upto /24 reject; route-filter 192.168.0.0/16 through 192.168.16.0/20; route-filter 192.168.0.0/16 prefix-length-range /26-/30 reject; Futhermore, Juniper allows you to have more than one route-filter statement per block. Our rtrmgr simply cannot be modified to support syntax like this. If we ever rewrite the rtrmgr (see Bugzilla entry #677), then there is some chance it might be easier to extend it with some of this syntax, but for now this is just not an option. The best we could do is to take the exact/longer/orlonger keywords from the first three examples, and support them similar to the existing comparison operators: "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" Note that the last three keywords (shorter/orshorter/not) don't exist in Juniper, so feel free to suggest better names. And, no, the rtrmgr template syntax doesn't allow us to have the tokens ordered same like in Juniper: "network4 10.0.0.0/8 exact". Have in mind that even such change is going to be very ugly (we need to add hacks to the rtrmgr AND the policy manager), and there is no guarantee it will actually work properly before we actually try it. Any other syntax changes are just no-starters with what we have now. About the suggestion of changing the direction of the "<=" operator: if you think that the current direction is wrong (which I strongly disagree with) or confusing, then just changing the direction is going to be ever more confusing, so this shouldn't be an option. To summarize, here are the choices I see: (1) Do nothing and use the current "<=" and friends syntax. (2) Add the hack for the "exact/longer/orlonger..." support as in the examples given above. If anyone has any other suggestions, please be very specific (and realistic) with examples what the syntax should look like, rather than being vague with "follow vendor FOO". Pavlin > -- Dave > > Kristian Larsson wrote: > > I think Roberts idea is just great, why not copy > > Juniper terminology. We already got a Juniper > > lookalike shell. > > > > And just as robert.. I'd go with option B if I had > > to choose between the two. > > > > -K > > > > On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote: > >> Maybe it makes more sense to use Juniper terminology; exact, longer, > >> orlonger, through, upto... > >> > >> Short of that, I prefer option B. > >> > >> Cheers, > >> Robert. > >> > >> Mike Horn wrote: > >>> Hi all, > >>> > >>> Pavlin and I have been discussing what the "right" direction should be > >>> for the network4 operator in policy statements. Right now if you > >>> specify "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 and > >>> longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > >>> > >>> My recommendation is to change the operator from "<=" matches longer > >>> prefixes to ">=" matches longer prefixes, since this seems more > >>> intuitive to me (/9 is > /8) and this would make it match the > >>> "prefix-length4" operator where "prefix-length4 > 24" matches all > >>> prefixes longer than /24. > >>> > >>> Which do you prefer: > >>> > >>> A) keep it the way it is now, < matches longer prefixes > >>> B) changing it to use > for longer prefix matches > >>> > >>> Btw, the bug on this is 358 > >>> > >>> _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ > >>> > >>> -mike > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> Xorp-hackers mailing list > >>> Xorp-hackers at icir.org > >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > >> _______________________________________________ > >> Xorp-users mailing list > >> Xorp-users at xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From mhorn at vyatta.com Thu Nov 16 17:31:43 2006 From: mhorn at vyatta.com (Mike Horn) Date: Thu, 16 Nov 2006 18:31:43 -0700 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: <00d401c709e7$6f5bc8d0$0f02a8c0@caddisconsulting.com> Message-ID: <00d601c709e8$23a00220$0f02a8c0@caddisconsulting.com> Hi, Sorry to respond to my own message, I didn't see the section where Pavlin strongly disagrees with flipping the sign, but I think it's the right thing to do (IMHO). -mike -----Original Message----- From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Mike Horn Sent: Thursday, November 16, 2006 6:27 PM To: 'Pavlin Radoslavov' Cc: xorp-users at xorp.org; xorp-hackers at xorp.org Subject: Re: [Xorp-hackers] [Xorp-users] Policy network4 operator Hi Pavlin, I agree, Cisco and Juniper syntax are very different, and there really isn't an "industry standard". You only listed the following options: (1) Do nothing and use the current "<=" and friends syntax. (2) Add the hack for the "exact/longer/orlonger..." support as in the examples given above. Isn't another option to flip the meaning of the sign? In which case > would mean longer prefixes, so network4 > 10.0.0.0/8 would be any 10.X prefixes with a prefix length longer than 8. This would be aligned with Cisco's use of "ge" and "le" and seems like from the limited responses to be everyone's preference. What do you think about using this as an interim approach? -mike -----Original Message----- From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Pavlin Radoslavov Sent: Thursday, November 16, 2006 5:59 PM To: Dave Roberts Cc: xorp-users at xorp.org; Robert Bays; Kristian Larsson; mhorn at vyatta.com; xorp-hackers at xorp.org Subject: Re: [Xorp-hackers] [Xorp-users] Policy network4 operator Dave Roberts wrote: > Being a product manager at heart, my advice would be to follow > industry conventions here. The fact is, the industry has already > solved this problem and there are certain expectations of operating > behavior and terminology that router users already have. So why > reinvent the wheel? > Violating the norms of the vast majority of users just seems senseless. > > My conclusion is that Robert's suggestion of adopting Juniper > terminology and behavior seems like a no-brainer. Failing that, look > at what Cisco does and base something off that. But whatever you do, > don't go inventing new terminology and behavior without a *STRONG* > reason for doing so; all you will do is end up confusing the vast > majority of users that are schooled on existing products. Complex > router configurations are difficult enough to get debugged and working > without users having to remember that XORP is the one router on the > planet that does something needlessly different. In an ideal world we can change any of the configuration semantics in any way we like so we won't be having this discussion. About the suggestion to follow what other have done. Syntax-wise, even Cisco and Juniper are doing things very differently, so there is no universal solution that we can just reuse. I checked the Cisco documentation online about the relevant policy semantics, and the closest I found is along the lines: ============================================================= Cisco IOS IP Command Reference, Volume 2 of 4: Routing Protocols Release 12.3 T http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_refe rence_chapter09186a008017d02f.html and Routing Policy Language Commands on Cisco IOS XR Software http://www.cisco.com/en/US/products/ps5763/products_command_reference_chapte r09186a00803b0e1b.html Some examples from the first document are: To accept a mask length of up to 24 bits in routes with the prefix 192/8: ip prefix-list abc permit 192.168.0.0/8 le 24 To deny mask lengths greater than 25 bits in routes with a prefix of 192/8: ip prefix-list abc deny 192.168.0.0/8 ge 25 To permit mask lengths from 8 to 24 bits in all address space: ip prefix-list abc permit 0.0.0.0/0 ge 8 le 24 To deny mask lengths greater than 25 bits in all address space: ip prefix-list abc deny 0.0.0.0/0 ge 25 To deny all routes with a prefix of 10/8: ip prefix-list abc deny 10.0.0.0/8 le 32 ============================================================= As you can see, the syntax is very different from XORP, the "ge | le" arguments are of different type (network mask length), etc, so we cannot reuse or adapt this. The Juniper syntax for network address matching is like: route-filter 192.168.0.0/16 exact; route-filter 192.168.0.0/16 longer; route-filter 192.168.0.0/16 orlonger; route-filter 192.168.0.0/16 upto /24 reject; route-filter 192.168.0.0/16 through 192.168.16.0/20; route-filter 192.168.0.0/16 prefix-length-range /26-/30 reject; Futhermore, Juniper allows you to have more than one route-filter statement per block. Our rtrmgr simply cannot be modified to support syntax like this. If we ever rewrite the rtrmgr (see Bugzilla entry #677), then there is some chance it might be easier to extend it with some of this syntax, but for now this is just not an option. The best we could do is to take the exact/longer/orlonger keywords from the first three examples, and support them similar to the existing comparison operators: "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" Note that the last three keywords (shorter/orshorter/not) don't exist in Juniper, so feel free to suggest better names. And, no, the rtrmgr template syntax doesn't allow us to have the tokens ordered same like in Juniper: "network4 10.0.0.0/8 exact". Have in mind that even such change is going to be very ugly (we need to add hacks to the rtrmgr AND the policy manager), and there is no guarantee it will actually work properly before we actually try it. Any other syntax changes are just no-starters with what we have now. About the suggestion of changing the direction of the "<=" operator: if you think that the current direction is wrong (which I strongly disagree with) or confusing, then just changing the direction is going to be ever more confusing, so this shouldn't be an option. To summarize, here are the choices I see: (1) Do nothing and use the current "<=" and friends syntax. (2) Add the hack for the "exact/longer/orlonger..." support as in the examples given above. If anyone has any other suggestions, please be very specific (and realistic) with examples what the syntax should look like, rather than being vague with "follow vendor FOO". Pavlin > -- Dave > > Kristian Larsson wrote: > > I think Roberts idea is just great, why not copy Juniper > > terminology. We already got a Juniper lookalike shell. > > > > And just as robert.. I'd go with option B if I had to choose between > > the two. > > > > -K > > > > On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote: > >> Maybe it makes more sense to use Juniper terminology; exact, > >> longer, orlonger, through, upto... > >> > >> Short of that, I prefer option B. > >> > >> Cheers, > >> Robert. > >> > >> Mike Horn wrote: > >>> Hi all, > >>> > >>> Pavlin and I have been discussing what the "right" direction > >>> should be for the network4 operator in policy statements. Right > >>> now if you specify "network4 <= 10.0.0.0/8" this would match all > >>> the 10.0.0.0/8 and > >>> longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > >>> > >>> My recommendation is to change the operator from "<=" matches > >>> longer prefixes to ">=" matches longer prefixes, since this seems > >>> more intuitive to me (/9 is > /8) and this would make it match the > >>> "prefix-length4" operator where "prefix-length4 > 24" matches all > >>> prefixes longer than /24. > >>> > >>> Which do you prefer: > >>> > >>> A) keep it the way it is now, < matches longer prefixes > >>> B) changing it to use > for longer prefix matches > >>> > >>> Btw, the bug on this is 358 > >>> > >>> _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ > >>> > >>> -mike > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> Xorp-hackers mailing list > >>> Xorp-hackers at icir.org > >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > >> _______________________________________________ > >> Xorp-users mailing list > >> Xorp-users at xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at icir.org Thu Nov 16 17:32:26 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 16 Nov 2006 17:32:26 -0800 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: Message from "Mike Horn" of "Thu, 16 Nov 2006 18:26:40 MST." <00d401c709e7$6f5bc8d0$0f02a8c0@caddisconsulting.com> Message-ID: <200611170132.kAH1WQ1k054688@possum.icir.org> > I agree, Cisco and Juniper syntax are very different, and there really isn't > an "industry standard". You only listed the following options: > > (1) Do nothing and use the current "<=" and friends syntax. > (2) Add the hack for the "exact/longer/orlonger..." support as in > the examples given above. > > Isn't another option to flip the meaning of the sign? In which case > would > mean longer prefixes, so network4 > 10.0.0.0/8 would be any 10.X prefixes > with a prefix length longer than 8. This would be aligned with Cisco's use > of "ge" and "le" and seems like from the limited responses to be everyone's > preference. > > What do you think about using this as an interim approach? I think I already wrote a paragraph about this in my previous email. And, no, it won't be aligned with Cisco's use of "ge" and "le", because they are using "ge" and "le" to compare network mask length (the argument is an integer) while we are using ">=" and "<=" to compare network addresses. Pavlin > -mike > > -----Original Message----- > From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] > On Behalf Of Pavlin Radoslavov > Sent: Thursday, November 16, 2006 5:59 PM > To: Dave Roberts > Cc: xorp-users at xorp.org; Robert Bays; Kristian Larsson; mhorn at vyatta.com; > xorp-hackers at xorp.org > Subject: Re: [Xorp-hackers] [Xorp-users] Policy network4 operator > > Dave Roberts wrote: > > > Being a product manager at heart, my advice would be to follow > > industry conventions here. The fact is, the industry has already > > solved this problem and there are certain expectations of operating > > behavior and terminology that router users already have. So why reinvent > the wheel? > > Violating the norms of the vast majority of users just seems senseless. > > > > My conclusion is that Robert's suggestion of adopting Juniper > > terminology and behavior seems like a no-brainer. Failing that, look > > at what Cisco does and base something off that. But whatever you do, > > don't go inventing new terminology and behavior without a *STRONG* > > reason for doing so; all you will do is end up confusing the vast > > majority of users that are schooled on existing products. Complex > > router configurations are difficult enough to get debugged and working > > without users having to remember that XORP is the one router on the > > planet that does something needlessly different. > > In an ideal world we can change any of the configuration semantics in any > way we like so we won't be having this discussion. > > > About the suggestion to follow what other have done. > Syntax-wise, even Cisco and Juniper are doing things very differently, so > there is no universal solution that we can just reuse. > > I checked the Cisco documentation online about the relevant policy > semantics, and the closest I found is along the lines: > > ============================================================= > Cisco IOS IP Command Reference, > Volume 2 of 4: Routing Protocols > Release 12.3 T > > http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_refe > rence_chapter09186a008017d02f.html > > and > > Routing Policy Language Commands on Cisco IOS XR Software > http://www.cisco.com/en/US/products/ps5763/products_command_reference_chapte > r09186a00803b0e1b.html > > Some examples from the first document are: > > To accept a mask length of up to 24 bits in routes with the prefix > 192/8: > ip prefix-list abc permit 192.168.0.0/8 le 24 To deny mask lengths greater > than 25 bits in routes with a prefix of > 192/8: > ip prefix-list abc deny 192.168.0.0/8 ge 25 To permit mask lengths from 8 to > 24 bits in all address space: > ip prefix-list abc permit 0.0.0.0/0 ge 8 le 24 To deny mask lengths greater > than 25 bits in all address space: > ip prefix-list abc deny 0.0.0.0/0 ge 25 > To deny all routes with a prefix of 10/8: > ip prefix-list abc deny 10.0.0.0/8 le 32 > > ============================================================= > > As you can see, the syntax is very different from XORP, the "ge | le" > arguments are of different type (network mask length), etc, so we cannot > reuse or adapt this. > > > The Juniper syntax for network address matching is like: > > route-filter 192.168.0.0/16 exact; > route-filter 192.168.0.0/16 longer; > route-filter 192.168.0.0/16 orlonger; > route-filter 192.168.0.0/16 upto /24 reject; > route-filter 192.168.0.0/16 through 192.168.16.0/20; > route-filter 192.168.0.0/16 prefix-length-range /26-/30 reject; > > Futhermore, Juniper allows you to have more than one route-filter > statement per block. > > Our rtrmgr simply cannot be modified to support syntax like this. > If we ever rewrite the rtrmgr (see Bugzilla entry #677), then there > is some chance it might be easier to extend it with some of this > syntax, but for now this is just not an option. > > The best we could do is to take the exact/longer/orlonger keywords > from the first three examples, and support them similar to the > existing comparison operators: > > "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" > "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" > "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" > > Note that the last three keywords (shorter/orshorter/not) don't > exist in Juniper, so feel free to suggest better names. > And, no, the rtrmgr template syntax doesn't allow us to have the > tokens ordered same like in Juniper: "network4 10.0.0.0/8 exact". > > Have in mind that even such change is going to be very ugly (we need > to add hacks to the rtrmgr AND the policy manager), and there is no > guarantee it will actually work properly before we actually try it. > Any other syntax changes are just no-starters with what we have now. > > About the suggestion of changing the direction of the "<=" operator: > if you think that the current direction is wrong (which I strongly > disagree with) or confusing, then just changing the direction is > going to be ever more confusing, so this shouldn't be an option. > > To summarize, here are the choices I see: > > (1) Do nothing and use the current "<=" and friends syntax. > (2) Add the hack for the "exact/longer/orlonger..." support as in > the examples given above. > > If anyone has any other suggestions, please be very specific (and > realistic) with examples what the syntax should look like, rather > than being vague with "follow vendor FOO". > > Pavlin > > > > -- Dave > > > > Kristian Larsson wrote: > > > I think Roberts idea is just great, why not copy > > > Juniper terminology. We already got a Juniper > > > lookalike shell. > > > > > > And just as robert.. I'd go with option B if I had > > > to choose between the two. > > > > > > -K > > > > > > On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote: > > >> Maybe it makes more sense to use Juniper terminology; exact, longer, > > >> orlonger, through, upto... > > >> > > >> Short of that, I prefer option B. > > >> > > >> Cheers, > > >> Robert. > > >> > > >> Mike Horn wrote: > > >>> Hi all, > > >>> > > >>> Pavlin and I have been discussing what the "right" direction should be > > >>> for the network4 operator in policy statements. Right now if you > > >>> specify "network4 <= 10.0.0.0/8" this would match all the 10.0.0.0/8 > and > > >>> longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > > >>> > > >>> My recommendation is to change the operator from "<=" matches longer > > >>> prefixes to ">=" matches longer prefixes, since this seems more > > >>> intuitive to me (/9 is > /8) and this would make it match the > > >>> "prefix-length4" operator where "prefix-length4 > 24" matches all > > >>> prefixes longer than /24. > > >>> > > >>> Which do you prefer: > > >>> > > >>> A) keep it the way it is now, < matches longer prefixes > > >>> B) changing it to use > for longer prefix matches > > >>> > > >>> Btw, the bug on this is 358 > > >>> > > >>> _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ > > >>> > > >>> -mike > > >>> > > >>> > > >>> > ------------------------------------------------------------------------ > > >>> > > >>> _______________________________________________ > > >>> Xorp-hackers mailing list > > >>> Xorp-hackers at icir.org > > >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > >> _______________________________________________ > > >> Xorp-users mailing list > > >> Xorp-users at xorp.org > > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From mhorn at vyatta.com Thu Nov 16 17:53:18 2006 From: mhorn at vyatta.com (Mike Horn) Date: Thu, 16 Nov 2006 18:53:18 -0700 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: <200611170132.kAH1WQ1k054688@possum.icir.org> Message-ID: <00d701c709eb$276e40d0$0f02a8c0@caddisconsulting.com> Hi Pavlin, Sorry I missed it originally, see my last email ;-) Obviously we both have strong opinions about which sign direction is "right". If people continue to vote in favor of flipping the sign behavior, would you be willing to consider changing the behavior? Btw, I think the right long term answer is to use something similar to the Juniper syntax, which removes any potential for ambiguity. -mike -----Original Message----- From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Pavlin Radoslavov Sent: Thursday, November 16, 2006 6:32 PM To: mhorn at vyatta.com Cc: xorp-users at xorp.org; xorp-hackers at xorp.org; 'Pavlin Radoslavov' Subject: Re: [Xorp-users] [Xorp-hackers] Policy network4 operator > I agree, Cisco and Juniper syntax are very different, and there really > isn't an "industry standard". You only listed the following options: > > (1) Do nothing and use the current "<=" and friends syntax. > (2) Add the hack for the "exact/longer/orlonger..." support as in > the examples given above. > > Isn't another option to flip the meaning of the sign? In which case > > would mean longer prefixes, so network4 > 10.0.0.0/8 would be any 10.X > prefixes with a prefix length longer than 8. This would be aligned > with Cisco's use of "ge" and "le" and seems like from the limited > responses to be everyone's preference. > > What do you think about using this as an interim approach? I think I already wrote a paragraph about this in my previous email. And, no, it won't be aligned with Cisco's use of "ge" and "le", because they are using "ge" and "le" to compare network mask length (the argument is an integer) while we are using ">=" and "<=" to compare network addresses. Pavlin > -mike > > -----Original Message----- > From: xorp-hackers-bounces at icir.org > [mailto:xorp-hackers-bounces at icir.org] > On Behalf Of Pavlin Radoslavov > Sent: Thursday, November 16, 2006 5:59 PM > To: Dave Roberts > Cc: xorp-users at xorp.org; Robert Bays; Kristian Larsson; > mhorn at vyatta.com; xorp-hackers at xorp.org > Subject: Re: [Xorp-hackers] [Xorp-users] Policy network4 operator > > Dave Roberts wrote: > > > Being a product manager at heart, my advice would be to follow > > industry conventions here. The fact is, the industry has already > > solved this problem and there are certain expectations of operating > > behavior and terminology that router users already have. So why > > reinvent > the wheel? > > Violating the norms of the vast majority of users just seems senseless. > > > > My conclusion is that Robert's suggestion of adopting Juniper > > terminology and behavior seems like a no-brainer. Failing that, look > > at what Cisco does and base something off that. But whatever you do, > > don't go inventing new terminology and behavior without a *STRONG* > > reason for doing so; all you will do is end up confusing the vast > > majority of users that are schooled on existing products. Complex > > router configurations are difficult enough to get debugged and > > working without users having to remember that XORP is the one router > > on the planet that does something needlessly different. > > In an ideal world we can change any of the configuration semantics in > any way we like so we won't be having this discussion. > > > About the suggestion to follow what other have done. > Syntax-wise, even Cisco and Juniper are doing things very differently, > so there is no universal solution that we can just reuse. > > I checked the Cisco documentation online about the relevant policy > semantics, and the closest I found is along the lines: > > ============================================================= > Cisco IOS IP Command Reference, > Volume 2 of 4: Routing Protocols > Release 12.3 T > > http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_comman > d_refe > rence_chapter09186a008017d02f.html > > and > > Routing Policy Language Commands on Cisco IOS XR Software > http://www.cisco.com/en/US/products/ps5763/products_command_reference_ > chapte > r09186a00803b0e1b.html > > Some examples from the first document are: > > To accept a mask length of up to 24 bits in routes with the prefix > 192/8: > ip prefix-list abc permit 192.168.0.0/8 le 24 To deny mask lengths > greater than 25 bits in routes with a prefix of > 192/8: > ip prefix-list abc deny 192.168.0.0/8 ge 25 To permit mask lengths > from 8 to > 24 bits in all address space: > ip prefix-list abc permit 0.0.0.0/0 ge 8 le 24 To deny mask lengths > greater than 25 bits in all address space: > ip prefix-list abc deny 0.0.0.0/0 ge 25 To deny all routes with a > prefix of 10/8: > ip prefix-list abc deny 10.0.0.0/8 le 32 > > ============================================================= > > As you can see, the syntax is very different from XORP, the "ge | le" > arguments are of different type (network mask length), etc, so we > cannot reuse or adapt this. > > > The Juniper syntax for network address matching is like: > > route-filter 192.168.0.0/16 exact; > route-filter 192.168.0.0/16 longer; > route-filter 192.168.0.0/16 orlonger; > route-filter 192.168.0.0/16 upto /24 reject; route-filter > 192.168.0.0/16 through 192.168.16.0/20; route-filter 192.168.0.0/16 > prefix-length-range /26-/30 reject; > > Futhermore, Juniper allows you to have more than one route-filter > statement per block. > > Our rtrmgr simply cannot be modified to support syntax like this. > If we ever rewrite the rtrmgr (see Bugzilla entry #677), then there is > some chance it might be easier to extend it with some of this syntax, > but for now this is just not an option. > > The best we could do is to take the exact/longer/orlonger keywords > from the first three examples, and support them similar to the > existing comparison operators: > > "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" > "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" > "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" > > Note that the last three keywords (shorter/orshorter/not) don't exist > in Juniper, so feel free to suggest better names. > And, no, the rtrmgr template syntax doesn't allow us to have the > tokens ordered same like in Juniper: "network4 10.0.0.0/8 exact". > > Have in mind that even such change is going to be very ugly (we need > to add hacks to the rtrmgr AND the policy manager), and there is no > guarantee it will actually work properly before we actually try it. > Any other syntax changes are just no-starters with what we have now. > > About the suggestion of changing the direction of the "<=" operator: > if you think that the current direction is wrong (which I strongly > disagree with) or confusing, then just changing the direction is going > to be ever more confusing, so this shouldn't be an option. > > To summarize, here are the choices I see: > > (1) Do nothing and use the current "<=" and friends syntax. > (2) Add the hack for the "exact/longer/orlonger..." support as in > the examples given above. > > If anyone has any other suggestions, please be very specific (and > realistic) with examples what the syntax should look like, rather than > being vague with "follow vendor FOO". > > Pavlin > > > > -- Dave > > > > Kristian Larsson wrote: > > > I think Roberts idea is just great, why not copy Juniper > > > terminology. We already got a Juniper lookalike shell. > > > > > > And just as robert.. I'd go with option B if I had to choose > > > between the two. > > > > > > -K > > > > > > On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote: > > >> Maybe it makes more sense to use Juniper terminology; exact, > > >> longer, orlonger, through, upto... > > >> > > >> Short of that, I prefer option B. > > >> > > >> Cheers, > > >> Robert. > > >> > > >> Mike Horn wrote: > > >>> Hi all, > > >>> > > >>> Pavlin and I have been discussing what the "right" direction > > >>> should be for the network4 operator in policy statements. Right > > >>> now if you specify "network4 <= 10.0.0.0/8" this would match all > > >>> the 10.0.0.0/8 > and > > >>> longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.). > > >>> > > >>> My recommendation is to change the operator from "<=" matches > > >>> longer prefixes to ">=" matches longer prefixes, since this > > >>> seems more intuitive to me (/9 is > /8) and this would make it > > >>> match the "prefix-length4" operator where "prefix-length4 > 24" > > >>> matches all prefixes longer than /24. > > >>> > > >>> Which do you prefer: > > >>> > > >>> A) keep it the way it is now, < matches longer prefixes > > >>> B) changing it to use > for longer prefix matches > > >>> > > >>> Btw, the bug on this is 358 > > >>> > > >>> _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_ > > >>> > > >>> -mike > > >>> > > >>> > > >>> > ---------------------------------------------------------------------- > -- > > >>> > > >>> _______________________________________________ > > >>> Xorp-hackers mailing list > > >>> Xorp-hackers at icir.org > > >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > >> _______________________________________________ > > >> Xorp-users mailing list > > >> Xorp-users at xorp.org > > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From sureshkannan at gmail.com Tue Nov 14 00:07:03 2006 From: sureshkannan at gmail.com (Suresh kannan) Date: Tue, 14 Nov 2006 13:37:03 +0530 Subject: [Xorp-users] [Xorp-hackers] Does XORP Supports Multicast Routing? In-Reply-To: <20061114075149.GB31500@spritelink.se> References: <200611101725.kAAHPSRl070744@possum.icir.org> <20061114072302.11867.qmail@web90402.mail.mud.yahoo.com> <20061114075149.GB31500@spritelink.se> Message-ID: <84f679e0611140007lebff1aaocd85f269ecbc66e5@mail.gmail.com> Yep. I've not tried with multple topology and all.. but as far as i tried igmp,pim,ospf are working fine. On 11/14/06, Kristian Larsson wrote: > > On Mon, Nov 13, 2006 at 11:23:02PM -0800, ar wrote: > > anyone tried using xorp for multicast routing? thanks > Yes and it's working just fine. > > There is quite a lot of documentation on the PIM > part of XORP. > > -K > > -- > Kristian Larsson KLL-RIPE > Network Engineer Net at Once [AS35706] > +46 704 910401 kristian at spritelink.se > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061114/dbf8d383/attachment.html From yiwang at cs.princeton.edu Thu Nov 16 19:14:55 2006 From: yiwang at cs.princeton.edu (Yi Wang) Date: Thu, 16 Nov 2006 22:14:55 -0500 Subject: [Xorp-users] Two XORP instances talk to the same Click Message-ID: <455D292F.3030403@cs.princeton.edu> Hello, I was trying to run two instances of XORP on the same node, one runs only OSPF, and the other only runs BGP, and let them both use the same Click as the forwarding engine. What I found was, although this configuration worked at first (both BGP and OSPF routes show up in the Click forwarding table _xorp_rt4), either the BGP process or the OSPF process went wrong / died after a while (several minutes to several hours). Some of them seem because XrlPFSTCPSender died. I wonder whether there is actually a way to make this setting (two XORP talk to the same Click) work, and if yes, how? Thank you very much. Yi ------------------------------------------------------------ error messages from the XORP instance running BGP (log 1): [ 2006/11/15 08:00:07 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc run ] 4 seconds between calls to EventLoop::run [ 2006/11/15 11:00:07 WARNING xorp_policy:146 LIBXORP +75 eventloop.cc run ] 3 seconds between calls to EventLoop::run [ 2006/11/16 11:30:22 ERROR xorp_fea:139 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout [ 2006/11/16 11:30:24 ERROR xorp_bgp:147 LIBXORP +213 buffered_asyncio.cc io_event ] read error 104 [ 2006/11/16 11:30:25 ERROR xorp_bgp:147 XRL +159 xrl_pf_stcp.cc read_event ] Read failed (error = 104) [ 2006/11/16 11:30:25 ERROR xorp_bgp:147 XRL +339 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error ------------------------------------------------------------------------- error messages from the XORP instance running BGP (log 2): [ 2006/11/15 01:47:07 WARNING xorp_bgp:147 LIBXORP +75 eventloop.cc run ] 3 seconds between calls to EventLoop::run [ 2006/11/15 01:50:05 WARNING xorp_rib LIBXORP ] 3 seconds between calls to EventLoop::run [ 2006/11/15 06:05:32 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc run ] 3 seconds between calls to EventLoop::run [ 2006/11/15 06:45:13 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc run ] 5 seconds between calls to EventLoop::run [ 2006/11/15 06:45:14 ERROR xorp_fea:139 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout [ 2006/11/15 06:45:15 ERROR xorp_fea:139 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout [ 2006/11/15 06:45:15 ERROR xorp_fea:139 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout [ 2006/11/15 06:45:15 ERROR xorp_fea:139 LIBXORP +213 buffered_asyncio.cc io_event ] read error 104 [ 2006/11/15 06:45:15 ERROR xorp_fea:139 XRL +159 xrl_pf_stcp.cc read_event ] Read failed (error = 104) [ 2006/11/15 06:45:15 ERROR xorp_fea:139 XRL +339 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error [ 2006/11/15 06:45:15 ERROR xorp_fea:139 LIBXORP +213 buffered_asyncio.cc io_event ] read error 104 [ 2006/11/15 06:45:15 ERROR xorp_fea:139 XRL +159 xrl_pf_stcp.cc read_event ] Read failed (error = 104) [ 2006/11/15 06:45:15 ERROR xorp_fea:139 XRL +339 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error [ 2006/11/15 06:45:15 ERROR xorp_fea:139 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout [ 2006/11/15 13:26:08 ERROR xorp_bgp:147 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout [ 2006/11/15 16:31:04 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc run ] 3 seconds between calls to EventLoop::run [ 2006/11/15 20:53:08 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc run ] 6 seconds between calls to EventLoop::run [ 2006/11/16 01:29:49 WARNING xorp_bgp:147 LIBXORP +75 eventloop.cc run ] 3 seconds between calls to EventLoop::run [ 2006/11/16 06:05:00 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc run ] 3 seconds between calls to EventLoop::run [ 2006/11/16 07:15:11 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc run ] 4 seconds between calls to EventLoop::run [ 2006/11/16 07:45:07 WARNING xorp_bgp:147 LIBXORP +75 eventloop.cc run ] 3 seconds between calls to EventLoop::run [ 2006/11/16 09:55:06 WARNING xorp_rib LIBXORP ] 3 seconds between calls to EventLoop::run [ 2006/11/16 14:21:11 ERROR xorp_rtrmgr:136 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout [ 2006/11/16 14:24:13 ERROR xorp_fea:139 XRL +339 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired [ 2006/11/16 15:05:09 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc run ] 5 seconds between calls to EventLoop::run -------------------------------------------------------------------------- error messages from the XORP instance running OSPF (log 1): [ 2006/11/16 15:15:12 ERROR xorp_rtrmgr:135 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout [ 2006/11/16 15:18:15 ERROR xorp_fea:138 XRL +339 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired -------------------------------------------------------------------------- error messages from the XORP instance running OSPF (log 2): [ 2006/11/16 16:32:47 ERROR xorp_fea:138 FEA +1924 rawsock.cc proto_socket_write ] setsockopt(IP_TTL, 64) failed: Bad file descriptor [ 2006/11/16 16:32:47 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed setsockopt(IP_TTL, 64) failed: Bad file descriptor [ 2006/11/16 16:32:47 ERROR xorp_ospfv2:146 OSPF +185 xrl_io.cc send_cb ] Cannot send a packet on interface eth1 vif eth1: 102 Command failed setsockopt(IP_TTL, 64) failed: Bad file descriptor [ 2006/11/16 16:32:47 ERROR xorp_fea:138 FEA +1924 rawsock.cc proto_socket_write ] setsockopt(IP_TTL, 64) failed: Bad file descriptor [ 2006/11/16 16:32:47 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed setsockopt(IP_TTL, 64) failed: Bad file descriptor From hasso at linux.ee Fri Nov 17 03:34:11 2006 From: hasso at linux.ee (Hasso Tepper) Date: Fri, 17 Nov 2006 13:34:11 +0200 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: <200611170058.kAH0wfAi054219@possum.icir.org> References: <200611170058.kAH0wfAi054219@possum.icir.org> Message-ID: <200611171334.11390.hasso@linux.ee> Pavlin Radoslavov wrote: > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" [snip] > Note that the last three keywords (shorter/orshorter/not) don't > exist in Juniper, so feel free to suggest better names. What networks you'd expect to match these conditions? Ok, 10.0.0.0/8 would match "orshorter" but point being ... ? regards, -- Hasso Tepper Elion Enterprises Ltd. [AS3249] Data Communication Network Administrator From zec at icir.org Fri Nov 17 03:47:57 2006 From: zec at icir.org (Marko Zec) Date: Fri, 17 Nov 2006 12:47:57 +0100 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: <200611171334.11390.hasso@linux.ee> References: <200611170058.kAH0wfAi054219@possum.icir.org> <200611171334.11390.hasso@linux.ee> Message-ID: <200611171247.57660.zec@icir.org> On Friday 17 November 2006 12:34, Hasso Tepper wrote: > Pavlin Radoslavov wrote: > > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > > [snip] > > > Note that the last three keywords (shorter/orshorter/not) don't > > exist in Juniper, so feel free to suggest better names. > > What networks you'd expect to match these conditions? Ok, 10.0.0.0/8 would > match "orshorter" but point being ... ? Perhaps we should consider alternatives to "shorter/longer" terminology here, maybe something like "network4 includes 10.0.0.0/8" or "network4 is_included_in 10.0.0.0/8", with the "strictly_" modifier for current "<" and ">" operators? Or perhaps "covers" / "covered_by" -> native English speakers should do better at picking the right term... Marko From kristian at spritelink.se Fri Nov 17 04:09:32 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Fri, 17 Nov 2006 13:09:32 +0100 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: <200611171334.11390.hasso@linux.ee> References: <200611170058.kAH0wfAi054219@possum.icir.org> <200611171334.11390.hasso@linux.ee> Message-ID: <20061117120931.GJ31500@spritelink.se> On Fri, Nov 17, 2006 at 01:34:11PM +0200, Hasso Tepper wrote: > Pavlin Radoslavov wrote: > > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > > [snip] > > > Note that the last three keywords (shorter/orshorter/not) don't > > exist in Juniper, so feel free to suggest better names. > > What networks you'd expect to match these conditions? Ok, 10.0.0.0/8 would > match "orshorter" but point being ... ? I've been wondering over the same thing Would the following expressions do the same thing? cisco: ip prefix-list standard FOO deny 10.0.0.0/8 le 32 ip prefix-list standard FOO permit 0.0.0.0/0 xorp: network-list BAR { permit orshorter 10.0.0.0/8; } -K -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From mhorn at vyatta.com Fri Nov 17 06:53:25 2006 From: mhorn at vyatta.com (Mike Horn) Date: Fri, 17 Nov 2006 07:53:25 -0700 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: <200611171247.57660.zec@icir.org> Message-ID: <014401c70a58$22b2a000$0f02a8c0@caddisconsulting.com> Hi Marko, I really think that if XORP moves to using terminology, the terms should be something similar to Juniper's "exact, orlonger, etc.". IMHO this makes the most sense 1) because the xorpsh is similar in style to Juniper's so it would be consistent and 2)it seems to be the most intuitive of the ideas I have heard so far. Like Hasso, I'm also confused by what networks the "shorter" or current modifiers ">, >=" would match. -mike -----Original Message----- From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Marko Zec Sent: Friday, November 17, 2006 4:48 AM To: xorp-hackers at icir.org Cc: xorp-users at xorp.org; Hasso Tepper; Pavlin Radoslavov Subject: Re: [Xorp-users] [Xorp-hackers] Policy network4 operator On Friday 17 November 2006 12:34, Hasso Tepper wrote: > Pavlin Radoslavov wrote: > > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > > [snip] > > > Note that the last three keywords (shorter/orshorter/not) don't > > exist in Juniper, so feel free to suggest better names. > > What networks you'd expect to match these conditions? Ok, 10.0.0.0/8 > would match "orshorter" but point being ... ? Perhaps we should consider alternatives to "shorter/longer" terminology here, maybe something like "network4 includes 10.0.0.0/8" or "network4 is_included_in 10.0.0.0/8", with the "strictly_" modifier for current "<" and ">" operators? Or perhaps "covers" / "covered_by" -> native English speakers should do better at picking the right term... Marko _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pepo at linuxmail.org Thu Nov 16 20:34:44 2006 From: pepo at linuxmail.org (Pepo) Date: Thu, 16 Nov 2006 23:34:44 -0500 Subject: [Xorp-users] Begining with Xorp Message-ID: <200611162334.45801.pepo@linuxmail.org> Hi friends. I need to make a multicast LAN for my thesis (The project is IPTV), I want to make first with GNU/Linux and later with CISCO hardware. I was reading about pimd but now I think that Xorp is better; I use Debian Etch and when compile Xorp in my debian box, everything is ok, but I need to compile in a reduce version (to work like router) and receive this error message: .../... Making all in fea make[2]: se ingresa al directorio `/root/xorp-1.3/fea' Making all in . make[3]: se ingresa al directorio `/root/xorp-1.3/fea' source='ifconfig_media.cc' object='ifconfig_media.lo' libtool=yes \ depfile='.deps/ifconfig_media.Plo' tmpdepfile='.deps/ifconfig_media.TPlo' \ depmode=gcc3 /bin/sh ../config/depcomp \ /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o ifconfig_media.lo `test -f ifconfig_media.cc || echo './'`ifconfig_media.cc g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -c ifconfig_media.cc -MT ifconfig_media.lo -MD -MP -MF .deps/ifconfig_media.TPlo -o ifconfig_media.o /usr/include/linux/ethtool.h:18: error: '__u32' does not name a type /usr/include/linux/ethtool.h:19: error: '__u32' does not name a type /usr/include/linux/ethtool.h:20: error: '__u32' does not name a type /usr/include/linux/ethtool.h:21: error: '__u16' does not name a type /usr/include/linux/ethtool.h:22: error: '__u8' does not name a type /usr/include/linux/ethtool.h:23: error: '__u8' does not name a type /usr/include/linux/ethtool.h:24: error: '__u8' does not name a type /usr/include/linux/ethtool.h:25: error: '__u8' does not name a type /usr/include/linux/ethtool.h:26: error: '__u8' does not name a type .../... /usr/include/linux/ethtool.h:255: error: '__u32' does not name a type /usr/include/linux/ethtool.h:256: error: '__u8' does not name a type ifconfig_media.cc: In function 'int ifconfig_media_get_link_status(const std::string&, bool&, std::string&)': ifconfig_media.cc:123: error: 'struct ethtool_value' has no member named 'cmd' ifconfig_media.cc:137: error: 'struct ethtool_value' has no member named 'data' make[3]: *** [ifconfig_media.lo] Error 1 make[3]: se sale del directorio `/root/xorp-1.3/fea' make[2]: *** [all-recursive] Error 1 make[2]: se sale del directorio `/root/xorp-1.3/fea' make[1]: *** [all-recursive] Error 1 make[1]: se sale del directorio `/root/xorp-1.3' make: *** [all] Error 2 Please, which package do I need? Thanks. -- Linux User Registered #232544 Jabber : pepo at jabberes.org Ekiga : pepo at ekiga.net ICQ : 337889406 GnuPG-key : www.keyserver.net ---------------- ------------------------------- dum loquimur, fugerit invida aetas: carpe diem, quam minimum credula postero. _____________________________________ Este mensaje ha sido analizado por el Servicio Gratuito de Proteccion contra Virus de E-mail de Etapatelecom. From pavlin at icir.org Fri Nov 17 11:18:36 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 17 Nov 2006 11:18:36 -0800 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: Message from "Mike Horn" of "Thu, 16 Nov 2006 18:53:18 MST." <00d701c709eb$276e40d0$0f02a8c0@caddisconsulting.com> Message-ID: <200611171918.kAHJIavB064219@possum.icir.org> > Sorry I missed it originally, see my last email ;-) Obviously we both have > strong opinions about which sign direction is "right". If people continue > to vote in favor of flipping the sign behavior, would you be willing to > consider changing the behavior? No, because all mathematicians in the world will scream at me! :) Seriously, though, is it only the person who originally implemented this feature in XORP (Andrea and probably later updated by Marko?), Atanu and me who think that comparing network addresses indeed means comparing network addresses? It doesn't seem we are getting anywhere closer on agreeing what the sign direction should be. So the only remaining (short-term) option we have so far is to try to implement the Juniper-like keywords: "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" > Btw, I think the right long term answer is to use something similar to the > Juniper syntax, which removes any potential for ambiguity. I agree about the long-term solution. The question is what to do about it in short and medium term time scale. Pavlin From pavlin at icir.org Fri Nov 17 13:12:02 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 17 Nov 2006 13:12:02 -0800 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: Message from Hasso Tepper of "Fri, 17 Nov 2006 13:34:11 +0200." <200611171334.11390.hasso@linux.ee> Message-ID: <200611172112.kAHLC2dn065397@possum.icir.org> > > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > > [snip] > > > Note that the last three keywords (shorter/orshorter/not) don't > > exist in Juniper, so feel free to suggest better names. > > What networks you'd expect to match these conditions? Ok, 10.0.0.0/8 would > match "orshorter" but point being ... ? I don't understand your question. Are you asking me to explain how the above two operators work, or are you asking why someone wants to use them? If it is the former: Recall that currently "network4 <= 10.0.0.0/8" means all networks that are SUBSETS of 10.0.0.0/8 (i.e., that are contained by 10.0.0.0/8). Those are 10.0.0.0/8, 10.0.0.0/9, 10.128.0.0/9, and so on. The ">=" operator is just the opposite: "network4 >= 10.0.0.0/8" means all networks that are SUPERSETS of 10.0.0.0/8 (i.e., that contain 10.0.0.0/8). Those are 10.0.0.0/8, 10.0.0.0/7, 8.0.0.0/6, 8.0.0.0/5, 0.0.0.0/4, ... 0.0.0.0/0. The ">" operator is similar to the ">=" except that the 10.0.0.0/8 network itself is excluded (i.e., this is a strict superset). Here is another explanation in term of the proposed "orshorter/orlonger" keywords: The "orshorter" keyword is just the opposite of "orlonger": with "orlonger" the prefix length can be longer (8, 9, 10, ...), while with "orshorter" the prefix length can be shorter (8, 7, 6, ...). If it is the latter: I cannot give you a real-world example when exactly you need them, but they are there to complement the traditionally used longer prefix matching rules. Pavlin From pavlin at icir.org Fri Nov 17 13:46:29 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 17 Nov 2006 13:46:29 -0800 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: Message from Kristian Larsson of "Fri, 17 Nov 2006 13:09:32 +0100." <20061117120931.GJ31500@spritelink.se> Message-ID: <200611172146.kAHLkTnI065737@possum.icir.org> Kristian Larsson wrote: > On Fri, Nov 17, 2006 at 01:34:11PM +0200, Hasso Tepper wrote: > > Pavlin Radoslavov wrote: > > > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > > > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > > > > [snip] > > > > > Note that the last three keywords (shorter/orshorter/not) don't > > > exist in Juniper, so feel free to suggest better names. > > > > What networks you'd expect to match these conditions? Ok, 10.0.0.0/8 would > > match "orshorter" but point being ... ? > I've been wondering over the same thing > > Would the following expressions do the same thing? > cisco: > ip prefix-list standard FOO deny 10.0.0.0/8 le 32 > ip prefix-list standard FOO permit 0.0.0.0/0 > > xorp: > network-list BAR { > permit orshorter 10.0.0.0/8; > } I believe the answer is no, because the second Cisco rule will permit only the default route 0.0.0.0/0 (please correct me if my limited knowledge of Cisco commands is wrong here). The equivalent XORP-like rule (which BTW is not valid configuration) will match the following routes: 10.0.0.0/8, 10.0.0.0/7, 8.0.0.0/6, 8.0.0.0/5, 0.0.0.0/4, 0.0.0.0/3, 0.0.0.0/2, 0.0.0.0/1, 0.0.0.0/0. Pavlin From pavlin at icir.org Fri Nov 17 14:10:31 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 17 Nov 2006 14:10:31 -0800 Subject: [Xorp-users] Two XORP instances talk to the same Click In-Reply-To: Message from Yi Wang of "Thu, 16 Nov 2006 22:14:55 EST." <455D292F.3030403@cs.princeton.edu> Message-ID: <200611172210.kAHMAVGV067008@possum.icir.org> > I was trying to run two instances of XORP on the same node, one runs > only OSPF, and the other only runs BGP, and let them both use the same > Click as the forwarding engine. What I found was, although this > configuration worked at first (both BGP and OSPF routes show up in the > Click forwarding table _xorp_rt4), either the BGP process or the OSPF > process went wrong / died after a while (several minutes to several > hours). Some of them seem because XrlPFSTCPSender died. > > I wonder whether there is actually a way to make this setting (two XORP > talk to the same Click) work, and if yes, how? First I should ask why do you need to run two XORP instances if each instance is running different unicast routing protocol. If you run both OSPF and BGP within a single XORP instance, then you will have RIB merging for you all routes that come from both OSPF and BGP. Even if you have somehow two working instances of XORP on the same node talking to a single Click forwarding engine, who will merge the routes that come from both instances? Anyway, lets assume that you don't have the issue with merging routes. You could try running both instances of XORP, but make sure that you set the XORP_FINDER_SERVER_PORT environmental variable to a different port value before starting each instance (the default value is 19999). Then it depends on whether Click will allow to be controlled by two FEAs at the same time. I hope the answer is yes, given that the control is by reading/writing a control socket or by reading/writing from/to the Click file system. Note however, that on startup the second FEA that attempts to control Click will overwrite the Click configuration from the first FEA, and by doing so eventually it will remove also the routes installed by the first FEA. Hence, you'd better have both XORP instances configured with exactly same network interface information, and this information shouldn't change after startup. Futhermore, to avoid the routes disappearing on startup, your startup XORP configuration should exclude any unicast routing protocols, and only after you have started both instances, you should start/configure BGP and OSPF. In any case, you are entering an area that nobody has tried to explore before, so there could be other issues as well. Pavlin > Thank you very much. > Yi > > ------------------------------------------------------------ > error messages from the XORP instance running BGP (log 1): > > [ 2006/11/15 08:00:07 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc > run ] 4 > seconds between calls to EventLoop::run > [ 2006/11/15 11:00:07 WARNING xorp_policy:146 LIBXORP +75 eventloop.cc > run ] 3 > seconds between calls to EventLoop::run > [ 2006/11/16 11:30:22 ERROR xorp_fea:139 XRL +636 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: Keepalive timeout > [ 2006/11/16 11:30:24 ERROR xorp_bgp:147 LIBXORP +213 > buffered_asyncio.cc io_event ] read error 104 > [ 2006/11/16 11:30:25 ERROR xorp_bgp:147 XRL +159 xrl_pf_stcp.cc > read_event ] Read failed (error = 104) > [ 2006/11/16 11:30:25 ERROR xorp_bgp:147 XRL +339 xrl_pf_stcp.cc die ] > STCPRequestHandler died: read error > > ------------------------------------------------------------------------- > error messages from the XORP instance running BGP (log 2): > > [ 2006/11/15 01:47:07 WARNING xorp_bgp:147 LIBXORP +75 eventloop.cc run > ] 3 seconds between calls to EventLoop::run > [ 2006/11/15 01:50:05 WARNING xorp_rib LIBXORP ] 3 seconds between calls > to EventLoop::run > [ 2006/11/15 06:05:32 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc > run ] 3 > seconds between calls to EventLoop::run > [ 2006/11/15 06:45:13 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc > run ] 5 > seconds between calls to EventLoop::run > [ 2006/11/15 06:45:14 ERROR xorp_fea:139 XRL +636 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: Keepalive timeout > [ 2006/11/15 06:45:15 ERROR xorp_fea:139 XRL +636 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: Keepalive timeout > [ 2006/11/15 06:45:15 ERROR xorp_fea:139 XRL +636 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: Keepalive timeout > [ 2006/11/15 06:45:15 ERROR xorp_fea:139 LIBXORP +213 > buffered_asyncio.cc io_event ] read error 104 > [ 2006/11/15 06:45:15 ERROR xorp_fea:139 XRL +159 xrl_pf_stcp.cc > read_event ] Read failed (error = 104) > [ 2006/11/15 06:45:15 ERROR xorp_fea:139 XRL +339 xrl_pf_stcp.cc die ] > STCPRequestHandler died: read error > [ 2006/11/15 06:45:15 ERROR xorp_fea:139 LIBXORP +213 > buffered_asyncio.cc io_event ] read error 104 > [ 2006/11/15 06:45:15 ERROR xorp_fea:139 XRL +159 xrl_pf_stcp.cc > read_event ] Read failed (error = 104) > [ 2006/11/15 06:45:15 ERROR xorp_fea:139 XRL +339 xrl_pf_stcp.cc die ] > STCPRequestHandler died: read error > [ 2006/11/15 06:45:15 ERROR xorp_fea:139 XRL +636 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: Keepalive timeout > [ 2006/11/15 13:26:08 ERROR xorp_bgp:147 XRL +636 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: Keepalive timeout > [ 2006/11/15 16:31:04 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc > run ] 3 > seconds between calls to EventLoop::run > [ 2006/11/15 20:53:08 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc > run ] 6 > seconds between calls to EventLoop::run > [ 2006/11/16 01:29:49 WARNING xorp_bgp:147 LIBXORP +75 eventloop.cc run > ] 3 seconds between calls to EventLoop::run > [ 2006/11/16 06:05:00 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc > run ] 3 > seconds between calls to EventLoop::run > [ 2006/11/16 07:15:11 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc > run ] 4 > seconds between calls to EventLoop::run > [ 2006/11/16 07:45:07 WARNING xorp_bgp:147 LIBXORP +75 eventloop.cc run > ] 3 seconds between calls to EventLoop::run > [ 2006/11/16 09:55:06 WARNING xorp_rib LIBXORP ] 3 seconds between calls > to EventLoop::run > [ 2006/11/16 14:21:11 ERROR xorp_rtrmgr:136 XRL +636 xrl_pf_stcp.cc die > ] XrlPFSTCPSender died: Keepalive timeout > [ 2006/11/16 14:24:13 ERROR xorp_fea:139 XRL +339 xrl_pf_stcp.cc die ] > STCPRequestHandler died: life timer expired > [ 2006/11/16 15:05:09 WARNING xorp_rtrmgr:136 LIBXORP +75 eventloop.cc > run ] 5 > seconds between calls to EventLoop::run > > -------------------------------------------------------------------------- > error messages from the XORP instance running OSPF (log 1): > > [ 2006/11/16 15:15:12 ERROR xorp_rtrmgr:135 XRL +636 xrl_pf_stcp.cc die > ] XrlPFSTCPSender died: Keepalive timeout > [ 2006/11/16 15:18:15 ERROR xorp_fea:138 XRL +339 xrl_pf_stcp.cc die ] > STCPRequestHandler died: life timer expired > > -------------------------------------------------------------------------- > error messages from the XORP instance running OSPF (log 2): > > > [ 2006/11/16 16:32:47 ERROR xorp_fea:138 FEA +1924 rawsock.cc > proto_socket_write ] setsockopt(IP_TTL, 64) failed: Bad file descriptor > [ 2006/11/16 16:32:47 WARNING xorp_fea XrlFeaTarget ] Handling method > for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed > setsockopt(IP_TTL, 64) failed: Bad file descriptor > [ 2006/11/16 16:32:47 ERROR xorp_ospfv2:146 OSPF +185 xrl_io.cc send_cb > ] Cannot send a packet on interface eth1 vif eth1: 102 Command failed > setsockopt(IP_TTL, 64) failed: Bad file descriptor > [ 2006/11/16 16:32:47 ERROR xorp_fea:138 FEA +1924 rawsock.cc > proto_socket_write ] setsockopt(IP_TTL, 64) failed: Bad file descriptor > [ 2006/11/16 16:32:47 WARNING xorp_fea XrlFeaTarget ] Handling method > for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed > setsockopt(IP_TTL, 64) failed: Bad file descriptor > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Fri Nov 17 14:17:14 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 17 Nov 2006 14:17:14 -0800 Subject: [Xorp-users] Begining with Xorp In-Reply-To: Message from Pepo of "Thu, 16 Nov 2006 23:34:44 EST." <200611162334.45801.pepo@linuxmail.org> Message-ID: <200611172217.kAHMHEE3067558@possum.icir.org> A non-text attachment was scrubbed... Name: ifconfig_media.cc.patch Type: text/x-c++ Size: 870 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061117/436008cd/attachment.bin From kristian at spritelink.se Sat Nov 18 01:35:43 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Sat, 18 Nov 2006 10:35:43 +0100 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: <200611172146.kAHLkTnI065737@possum.icir.org> References: <20061117120931.GJ31500@spritelink.se> <200611172146.kAHLkTnI065737@possum.icir.org> Message-ID: <20061118093543.GK31500@spritelink.se> On Fri, Nov 17, 2006 at 01:46:29PM -0800, Pavlin Radoslavov wrote: > Kristian Larsson wrote: > > > On Fri, Nov 17, 2006 at 01:34:11PM +0200, Hasso Tepper wrote: > > > Pavlin Radoslavov wrote: > > > > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > > > > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > > > > > > [snip] > > > > > > > Note that the last three keywords (shorter/orshorter/not) don't > > > > exist in Juniper, so feel free to suggest better names. > > > > > > What networks you'd expect to match these conditions? Ok, 10.0.0.0/8 would > > > match "orshorter" but point being ... ? > > I've been wondering over the same thing > > > > Would the following expressions do the same thing? > > cisco: > > ip prefix-list standard FOO deny 10.0.0.0/8 le 32 > > ip prefix-list standard FOO permit 0.0.0.0/0 > > > > xorp: > > network-list BAR { > > permit orshorter 10.0.0.0/8; > > } > > I believe the answer is no, because the second Cisco rule will > permit only the default route 0.0.0.0/0 (please correct me if my > limited knowledge of Cisco commands is wrong here). You are correct, however 0.0.0.0/0 le 32 was what I meant. Nevertheless, I understand what shorter does now.. :) > The equivalent XORP-like rule (which BTW is not valid configuration) > will match the following routes: > 10.0.0.0/8, 10.0.0.0/7, 8.0.0.0/6, 8.0.0.0/5, 0.0.0.0/4, 0.0.0.0/3, > 0.0.0.0/2, 0.0.0.0/1, 0.0.0.0/0. Think of it as XORP pseudo code ;) I'm not as used to XORP so I can't write config from heart. Kristian. -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From jfletcher at vyatta.com Fri Nov 17 13:45:22 2006 From: jfletcher at vyatta.com (Justin Fletcher) Date: Fri, 17 Nov 2006 13:45:22 -0800 (PST) Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: <200611171918.kAHJIavB064219@possum.icir.org> Message-ID: <29350240.19511163799922176.JavaMail.root@tahiti.vyatta.com> > Seriously, though, is it only the person who originally implemented > this feature in XORP (Andrea and probably later updated by Marko?), > Atanu and me who think that comparing network addresses indeed means > comparing network addresses? Maybe :-) The operators seem reverse to the last time I implemented it, and the way I'm used to it in a Cisco notation. Justin From santhosh at ku.edu Sat Nov 18 19:29:12 2006 From: santhosh at ku.edu (Santhosh Sundararaman) Date: Sat, 18 Nov 2006 21:29:12 -0600 Subject: [Xorp-users] network4 operator - seems to have no effect on bgp import policy. In-Reply-To: <200611170132.kAH1WQ1k054688@possum.icir.org> References: <200611170132.kAH1WQ1k054688@possum.icir.org> Message-ID: <455FCF88.7000305@ku.edu> Hi all, I have been trying to use a policy with the network4 operator to reject a particular prefix (192.168.61.0/24), but the prefix keeps showing up in the bgp route table. here is the bgp and policy configuarion. protocols { bgp { bgp-id: 10.15.16.4 local-as: 65000 import: "policy_dummy1" peer 10.10.11.2 { /*Testbed110*/ local-ip: 10.11.15.3 as: 65000 next-hop: 10.11.15.3 holdtime: 120 ipv4-unicast: true } } policy { policy-statement "policy_dummy1" { term "dummy1-term" { from { network4: 192.168.61.0/24 } then { trace: 1 reject } } } } I added trace to see if the route was getting rejected. The trace messages in the xorp_rtrmgr showed that the prefix 192.168.61.0/24 was being rejected. [ 2006/11/18 21:09:18 TRACE xorp_bgp POLICY ] Policy filter result: BGP Import route: 192.168.61.0/24: rejected [ 2006/11/18 21:09:18 TRACE xorp_bgp POLICY ] Policy filter result: BGP Import route: 192.168.62.0/24: default action [ 2006/11/18 21:09:18 TRACE xorp_bgp POLICY ] Policy filter result: BGP Import route: 192.168.63.0/24: default action But when i checked the bgp route table from the xorpsh, the prefix 192.168.61.0/24 was still showing up, as shown below. santhosh at testbed115.ittc.ku.edu> show bgp routes Status Codes: * valid route, > best route Origin Codes: i IGP, e EGP, ? incomplete Prefix Nexthop Peer AS Path ------ ------- ---- ------- * 192.168.61.0/24 172.16.10.1 172.16.10.3 65002 65006 e *> 192.168.62.0/24 172.16.10.1 172.16.10.3 65002 65006 e *> 192.168.63.0/24 172.16.10.1 172.16.10.3 65002 65006 e It seems to appear that the the route entry for the prefix 192.168.61.0/24 is not the best route for the prefix, as show by the absence of ">" before the prefix. But if the route is rejected during import itself, shouldn't it not appear in the bgp route table, instead of it appearing and not being chosen. I might be missing something or possibly misinterpreting something, could someone help me understand whats happening. Thanks Santhosh From pavlin at icir.org Mon Nov 20 11:45:00 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 20 Nov 2006 11:45:00 -0800 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: Message from Justin Fletcher of "Fri, 17 Nov 2006 13:45:22 PST." <29350240.19511163799922176.JavaMail.root@tahiti.vyatta.com> Message-ID: <200611201945.kAKJj0nC008991@possum.icir.org> > > Seriously, though, is it only the person who originally implemented > > this feature in XORP (Andrea and probably later updated by Marko?), > > Atanu and me who think that comparing network addresses indeed means > > comparing network addresses? > > Maybe :-) The operators seem reverse to the last time I implemented it, > and the way I'm used to it in a Cisco notation. Again, as I mentioned earlier, the Cisco notation reasoning doesn't apply here. In Cisco, the comparison is network address vs. prefix length. In our case we have network address vs. network address. This thread is getting too long, so let me repeat again my question about the short/medium term solution. If you can't accept the current behavior, would you like us to invest some time trying to implement the Juniper-like keywords: "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" If yes, then please indicate whether we should use the "shorter/orshorter/not" keywords or something else. If you prefer a different solution, now is the time to suggest it (flipping the operator direction excluded). If there are no replies, then probably nothing will change until the rtrmgr is reimplemented (bug #677) and we are in the position to implement the long-term solution. Pavlin From c-otto at gmx.de Mon Nov 20 11:47:07 2006 From: c-otto at gmx.de (Carsten Otto) Date: Mon, 20 Nov 2006 20:47:07 +0100 Subject: [Xorp-users] Multiple IPs for one interface Message-ID: <20061120194706.GM15769@server.c-otto.de> Hi there! I have two networks connected to my internal interface (137.226.108.0/22 and 134.130.48.0/23). I can't get Xorp to do IGMP (and PIM) for both interfaces. With automatic configuration only one of many IPs (so only one net) is detected. With a static configuration and two VIFs I always get "bad vif name". I can't find any information what a _good_ VIF name is, so please tell me. "neuesnetz" and "altesnetz" (German, new and old network) do not work. Even eth0 and eth0b do not work, although a similiar example is in the PDF user manual. Please tell me how to use Xorp with several IPs per interface. Thanks, -- Carsten Otto c-otto at gmx.de www.c-otto.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061120/563ff0ad/attachment.bin From pavlin at icir.org Mon Nov 20 12:15:16 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 20 Nov 2006 12:15:16 -0800 Subject: [Xorp-users] Multiple IPs for one interface In-Reply-To: Message from Carsten Otto of "Mon, 20 Nov 2006 20:47:07 +0100." <20061120194706.GM15769@server.c-otto.de> Message-ID: <200611202015.kAKKFGeX009464@possum.icir.org> > I have two networks connected to my internal interface (137.226.108.0/22 > and 134.130.48.0/23). I can't get Xorp to do IGMP (and PIM) for both > interfaces. With automatic configuration only one of many IPs (so only > one net) is detected. With a static configuration and two VIFs I always > get "bad vif name". I can't find any information what a _good_ VIF name > is, so please tell me. "neuesnetz" and "altesnetz" (German, new and old > network) do not work. Even eth0 and eth0b do not work, although a > similiar example is in the PDF user manual. Please tell me how to use > Xorp with several IPs per interface. Assuming the interface name with the two IP addresses is eth0, you can use one of the following two configurations to configure it with multiple IP addresses. Note that I have randomly chosen 137.226.108.1 and 134.130.48.1 as your real IP addresses, because the 137.226.108.0 and 134.130.48.0 addresses themselves shouldn't be used (the subnet bits are all 0s). /* * Method 1: reuse all addresses that have been configured before * starting XORP. */ interfaces { interface eth0 { default-system-config } } /* * Method 2: explicitly assign the IP addresses. */ interfaces { interface eth0 { vif eth0 { address 137.226.108.1 { prefix-length: 22 } address 134.130.48.1 { prefix-length: 23 } } } } To test that the multi-address configuration really works, I'd recommend that you start XORP with only one of the above two configurations. Then the "show interfaces" xorpsh command should show both addresses. Double check with the Linux "ip addr" command. Note that the Linux "ifconfig -a" command is broken and won't display the secondary IP address. After that you can configure the rest of XORP as usual. E.g., the MFEA part will look like: plumbing { mfea4 { interface eth0 { vif eth0 { disable: false } } interface register_vif { vif register_vif { disable: false } } } } Hope that helps, Pavlin From kristian at spritelink.se Mon Nov 20 12:53:17 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Mon, 20 Nov 2006 21:53:17 +0100 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: <200611201945.kAKJj0nC008991@possum.icir.org> References: <29350240.19511163799922176.JavaMail.root@tahiti.vyatta.com> <200611201945.kAKJj0nC008991@possum.icir.org> Message-ID: <20061120205316.GE7246@spritelink.se> On Mon, Nov 20, 2006 at 11:45:00AM -0800, Pavlin Radoslavov wrote: > > > Seriously, though, is it only the person who originally implemented > > > this feature in XORP (Andrea and probably later updated by Marko?), > > > Atanu and me who think that comparing network addresses indeed means > > > comparing network addresses? > > > > Maybe :-) The operators seem reverse to the last time I implemented it, > > and the way I'm used to it in a Cisco notation. > > Again, as I mentioned earlier, the Cisco notation reasoning doesn't > apply here. > In Cisco, the comparison is network address vs. prefix length. > In our case we have network address vs. network address. > > > This thread is getting too long, so let me repeat again my question > about the short/medium term solution. > If you can't accept the current behavior, would you like us to > invest some time trying to implement the Juniper-like keywords: > > "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" > "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" > "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" > > If yes, then please indicate whether we should use the > "shorter/orshorter/not" keywords or something else. As long as it doesn't take too long to implement I find it a more than welcome interrim solution :) > If you prefer a different solution, now is the time to suggest it > (flipping the operator direction excluded). > > If there are no replies, then probably nothing will change until the > rtrmgr is reimplemented (bug #677) and we are in the position to > implement the long-term solution. -K -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From mhorn at vyatta.com Mon Nov 20 21:33:33 2006 From: mhorn at vyatta.com (Mike Horn) Date: Mon, 20 Nov 2006 21:33:33 -0800 (PST) Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: <20061120205316.GE7246@spritelink.se> Message-ID: <21420941.22701164087213422.JavaMail.root@tahiti.vyatta.com> I would also prefer changing to Juniper-like keywords. For me, the operators I care about are "exact", "longer", "orlonger" and "not". I can't think of a practical application for "shorter" or "orshorter". Btw, can you share your thoughts on what the "long-term" solution would look like? -mike ----- Original Message ----- From: Kristian Larsson To: Pavlin Radoslavov Cc: xorp-users at xorp.org, xorp-hackers at xorp.org, mhorn at vyatta.com, Justin Fletcher Sent: Monday, November 20, 2006 1:53:17 PM GMT-0700 US/Mountain Subject: Re: [Xorp-users] [Xorp-hackers] Policy network4 operator On Mon, Nov 20, 2006 at 11:45:00AM -0800, Pavlin Radoslavov wrote: > > > Seriously, though, is it only the person who originally implemented > > > this feature in XORP (Andrea and probably later updated by Marko?), > > > Atanu and me who think that comparing network addresses indeed means > > > comparing network addresses? > > > > Maybe :-) The operators seem reverse to the last time I implemented it, > > and the way I'm used to it in a Cisco notation. > > Again, as I mentioned earlier, the Cisco notation reasoning doesn't > apply here. > In Cisco, the comparison is network address vs. prefix length. > In our case we have network address vs. network address. > > > This thread is getting too long, so let me repeat again my question > about the short/medium term solution. > If you can't accept the current behavior, would you like us to > invest some time trying to implement the Juniper-like keywords: > > "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" > "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" > "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" > "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" > "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" > "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" > > If yes, then please indicate whether we should use the > "shorter/orshorter/not" keywords or something else. As long as it doesn't take too long to implement I find it a more than welcome interrim solution :) > If you prefer a different solution, now is the time to suggest it > (flipping the operator direction excluded). > > If there are no replies, then probably nothing will change until the > rtrmgr is reimplemented (bug #677) and we are in the position to > implement the long-term solution. -K -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Tue Nov 21 12:42:24 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 21 Nov 2006 12:42:24 -0800 Subject: [Xorp-users] [Xorp-hackers] Policy network4 operator In-Reply-To: Message from Mike Horn of "Mon, 20 Nov 2006 21:33:33 PST." <21420941.22701164087213422.JavaMail.root@tahiti.vyatta.com> Message-ID: <200611212042.kALKgOGF024918@possum.icir.org> > I would also prefer changing to Juniper-like keywords. For me, > the operators I care about are "exact", "longer", "orlonger" and > "not". I can't think of a practical application for "shorter" or > "orshorter". The "shorter" and "orshorter" keywords could be useful if someone wants to write a policy statement that matches all routes that might be used to reach a particular destination. I don't know whether someone will use it in practice, but it can be useful for experimentations. In any case, there shouldn't be any harm having them. > Btw, can you share your thoughts on what the "long-term" solution > would look like? The long-term solution will be determined at some future stage. Few things that come to mind (within the context of the discussed network operators) are: * Some of the syntax can be more Juniper-like. E.g., network 10.0.0.0/8 orlonger network 10.0.0.0/8 through 10.1.0.0/16 * Better support for network lists. E.g., network-list foo { 10.0.0.0/8 orlonger 10.0.0.0/8 through 10.1.0.0/16 } If you have ideas or suggestions about any long-term modifications (not only about the network operator but policy in general), please create a new bugzilla entry that can be used as a placeholder for them. FYI, there is already an entry about Cisco RPL: http://www.xorp.org/bugzilla/show_bug.cgi?id=652 Pavlin From c-otto at gmx.de Tue Nov 21 13:06:58 2006 From: c-otto at gmx.de (Carsten Otto) Date: Tue, 21 Nov 2006 22:06:58 +0100 Subject: [Xorp-users] Multiple IPs for one interface In-Reply-To: <200611202015.kAKKFGeX009464@possum.icir.org> References: <20061120194706.GM15769@server.c-otto.de> <200611202015.kAKKFGeX009464@possum.icir.org> Message-ID: <20061121210658.GE2722@server.c-otto.de> On Mon, Nov 20, 2006 at 12:15:16PM -0800, Pavlin Radoslavov wrote: > /* > * Method 1: reuse all addresses that have been configured before > * starting XORP. > */ > interfaces { > interface eth0 { > default-system-config > } > } This works, which confuses me. Perhaps I forgot the restart of XORP? > /* > * Method 2: explicitly assign the IP addresses. > */ > interfaces { > interface eth0 { > vif eth0 { > address 137.226.108.1 { > prefix-length: 22 > } > address 134.130.48.1 { > prefix-length: 23 > } > } > } > } This is not the way according to the documentation. There it is a second vif instead of just an additional address. Thanks a lot, -- Carsten Otto c-otto at gmx.de www.c-otto.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061121/c040e0fc/attachment.bin From pavlin at icir.org Tue Nov 21 13:12:09 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 21 Nov 2006 13:12:09 -0800 Subject: [Xorp-users] Multiple IPs for one interface In-Reply-To: Message from Carsten Otto of "Tue, 21 Nov 2006 22:06:58 +0100." <20061121210658.GE2722@server.c-otto.de> Message-ID: <200611212112.kALLC9wZ025387@possum.icir.org> > > /* > > * Method 2: explicitly assign the IP addresses. > > */ > > interfaces { > > interface eth0 { > > vif eth0 { > > address 137.226.108.1 { > > prefix-length: 22 > > } > > address 134.130.48.1 { > > prefix-length: 23 > > } > > } > > } > > } > > This is not the way according to the documentation. There it is a second > vif instead of just an additional address. Then probably the documentation is misleading or wrong. Can you point the document title and the page number so we can correct it. Thanks, Pavlin From c-otto at gmx.de Tue Nov 21 13:43:59 2006 From: c-otto at gmx.de (Carsten Otto) Date: Tue, 21 Nov 2006 22:43:59 +0100 Subject: [Xorp-users] Multiple IPs for one interface In-Reply-To: <200611212112.kALLC9wZ025387@possum.icir.org> References: <20061121210658.GE2722@server.c-otto.de> <200611212112.kALLC9wZ025387@possum.icir.org> Message-ID: <20061121214359.GA7300@server.c-otto.de> On Tue, Nov 21, 2006 at 01:12:09PM -0800, Pavlin Radoslavov wrote: > Then probably the documentation is misleading or wrong. > Can you point the document title and the page number so we can > correct it. http://www.xorp.org/releases/current/docs/user_manual/user_manual.pdf p24 p25 Bye, -- Carsten Otto c-otto at gmx.de www.c-otto.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20061121/77a73662/attachment.bin From pavlin at icir.org Tue Nov 21 15:30:02 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 21 Nov 2006 15:30:02 -0800 Subject: [Xorp-users] Multiple IPs for one interface In-Reply-To: Message from Carsten Otto of "Tue, 21 Nov 2006 22:43:59 +0100." <20061121214359.GA7300@server.c-otto.de> Message-ID: <200611212330.kALNU2JG029959@possum.icir.org> Carsten Otto wrote: > On Tue, Nov 21, 2006 at 01:12:09PM -0800, Pavlin Radoslavov wrote: > > Then probably the documentation is misleading or wrong. > > Can you point the document title and the page number so we can > > correct it. > > http://www.xorp.org/releases/current/docs/user_manual/user_manual.pdf > p24 > p25 Problem fixed in CVS, so now the examples are closer to reality: Revision Changes Path 1.17 +33 -60; commitid: 1102c45638b4a7ea6; xorp/docs/user_manual/cli_intro.tex Thanks, Pavlin From ahthamrin at gmail.com Tue Nov 28 00:26:20 2006 From: ahthamrin at gmail.com (A.H.T) Date: Tue, 28 Nov 2006 17:26:20 +0900 Subject: [Xorp-users] XORP 1.3 IPv6 mcast problem on FreeBSD 6.2RC1 Message-ID: <4250f3610611280026o14cdc40vc199490372d4094e@mail.gmail.com> Hi, I am trying to run XORP 1.3 PIM-SMv6 on FreeBSD 6.2RC1, and the XORP complains "Device not configured" on sending an IPv6 multicast packet (both MLD and PIM-SMv6). Sending IPv4 multicast packets is not a problem. The same XORP code is running without a problem on FreeBSD 6.1R. The XORP from CVS creates a compiler's Segmentation Fault during compilation. I guess these problems are very much because of the FreeBSD, but I'd like to know if there are others who experienced (or may have solved) these problems. regards, Below are the errors: 1. XORP IPv6 multicast (MLD only) [ 2006/11/28 11:28:32 ERROR xorp_fea:66931 MFEA +2249 mfea_proto_comm.cc proto_socket_write ] sendmsg(proto 58 size 24 from fe80::20c:29ff:fe35:3766 to ff02::1 on vif em1) failed: Device not configured [ 2006/11/28 11:28:32 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message6 failed: XrlCmdError 102 Command failed Cannot send MLD protocol message from fe80::20c:29ff:fe35:3766 to ff02::1 on vif em1: sendmsg(proto 58 size 24 from fe80::20c:29ff:fe35:3766 to ff02::1 on vif em1) failed: Device not configured [ 2006/11/28 11:28:32 ERROR xorp_mld:67010 MLD6IGMP +1519 xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send MLD protocol message from fe80::20c:29ff:fe35:3766 to ff02::1 on vif em1: sendmsg(proto 58 size 24 from fe80::20c:29ff:fe35:3766 to ff02::1 on vif em1) failed: Device not configured 2. Compiler's segmentation fault (this is just FYI, the error should be forwarded to GNU guys) /usr/include/c++/3.4/bits/stl_list.h: In instantiation of `void std::list<_Tp, _Alloc>::_M_insert(std::_List_iterator<_Tp>, const _Tp&) [with _Tp = XrlAtom, _Alloc = std::allocator]': /usr/include/c++/3.4/bits/stl_list.h:755: instantiated from `void std::list<_Tp, _Alloc>::push_front(const _Tp&) [with _Tp = XrlAtom, _Alloc = std::allocator]' ../../libxipc/xrl_args.hh:470: instantiated from here /usr/include/c++/3.4/bits/stl_list.h:1164: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[3]: *** [print_lsas.o] Error 1 gmake[3]: Leaving directory `/usr/local/src/xorp-cvs/ospf/tools' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/local/src/xorp-cvs/ospf' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/src/xorp-cvs' gmake: *** [all] Error 2 -- From pavlin at icir.org Tue Nov 28 01:55:44 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 28 Nov 2006 01:55:44 -0800 Subject: [Xorp-users] XORP 1.3 IPv6 mcast problem on FreeBSD 6.2RC1 In-Reply-To: Message from "A.H.T" of "Tue, 28 Nov 2006 17:26:20 +0900." <4250f3610611280026o14cdc40vc199490372d4094e@mail.gmail.com> Message-ID: <200611280955.kAS9tix8023799@possum.icir.org> > I am trying to run XORP 1.3 PIM-SMv6 on FreeBSD 6.2RC1, and the XORP > complains "Device not configured" on sending an IPv6 multicast packet > (both MLD and PIM-SMv6). Sending IPv4 multicast packets is not a > problem. > The same XORP code is running without a problem on FreeBSD 6.1R. > The XORP from CVS creates a compiler's Segmentation Fault during compilation. > > I guess these problems are very much because of the FreeBSD, but I'd > like to know if there are others who experienced (or may have solved) > these problems. Could you include your XORP configuration. Also, regarding the compilation problem, could you try to compile the latest XORP code from CVS. There have been few OSPF compilation-related changes recently, so there is a slight chance the problem will not be triggered. Thanks, Pavlin > regards, > > Below are the errors: > > 1. XORP IPv6 multicast (MLD only) > [ 2006/11/28 11:28:32 ERROR xorp_fea:66931 MFEA +2249 > mfea_proto_comm.cc proto_socket_write ] sendmsg(proto 58 size 24 from > fe80::20c:29ff:fe35:3766 to ff02::1 on vif em1) failed: Device not > configured > [ 2006/11/28 11:28:32 WARNING xorp_fea XrlMfeaTarget ] Handling method > for mfea/0.1/send_protocol_message6 failed: XrlCmdError 102 Command > failed Cannot send MLD protocol message from fe80::20c:29ff:fe35:3766 > to ff02::1 on vif em1: sendmsg(proto 58 size 24 from > fe80::20c:29ff:fe35:3766 to ff02::1 on vif em1) failed: Device not > configured > [ 2006/11/28 11:28:32 ERROR xorp_mld:67010 MLD6IGMP +1519 > xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cannot > send a protocol message: 102 Command failed Cannot send MLD protocol > message from fe80::20c:29ff:fe35:3766 to ff02::1 on vif em1: > sendmsg(proto 58 size 24 from fe80::20c:29ff:fe35:3766 to ff02::1 on > vif em1) failed: Device not configured > > 2. Compiler's segmentation fault (this is just FYI, the error should > be forwarded to GNU guys) > > /usr/include/c++/3.4/bits/stl_list.h: In instantiation of `void > std::list<_Tp, _Alloc>::_M_insert(std::_List_iterator<_Tp>, const > _Tp&) [with _Tp = XrlAtom, _Alloc = std::allocator]': > /usr/include/c++/3.4/bits/stl_list.h:755: instantiated from `void > std::list<_Tp, _Alloc>::push_front(const _Tp&) [with _Tp = XrlAtom, > _Alloc = std::allocator]' > ../../libxipc/xrl_args.hh:470: instantiated from here > /usr/include/c++/3.4/bits/stl_list.h:1164: internal compiler error: > Segmentation fault: 11 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > gmake[3]: *** [print_lsas.o] Error 1 > gmake[3]: Leaving directory `/usr/local/src/xorp-cvs/ospf/tools' > gmake[2]: *** [all-recursive] Error 1 > gmake[2]: Leaving directory `/usr/local/src/xorp-cvs/ospf' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/usr/local/src/xorp-cvs' > gmake: *** [all] Error 2 > > > > > -- > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Wed Nov 29 00:24:38 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 29 Nov 2006 00:24:38 -0800 Subject: [Xorp-users] XORP 1.3 IPv6 mcast problem on FreeBSD 6.2RC1 In-Reply-To: Message from Pavlin Radoslavov of "Tue, 28 Nov 2006 01:55:44 PST." <200611280955.kAS9tix8023799@possum.icir.org> Message-ID: <200611290824.kAT8Oc6C048715@possum.icir.org> Pavlin Radoslavov wrote: > > I am trying to run XORP 1.3 PIM-SMv6 on FreeBSD 6.2RC1, and the XORP > > complains "Device not configured" on sending an IPv6 multicast packet > > (both MLD and PIM-SMv6). Sending IPv4 multicast packets is not a > > problem. > > The same XORP code is running without a problem on FreeBSD 6.1R. > > The XORP from CVS creates a compiler's Segmentation Fault during compilation. > > > > I guess these problems are very much because of the FreeBSD, but I'd > > like to know if there are others who experienced (or may have solved) > > these problems. > > Could you include your XORP configuration. > > Also, regarding the compilation problem, could you try to compile > the latest XORP code from CVS. There have been few OSPF > compilation-related changes recently, so there is a slight chance > the problem will not be triggered. I installed FreeBSD-6.2-RC1 (actually upgraded from FreeBSD-6.1) and I didn't see the compilation error with the latest code from CVS. However, I was able to replicate the sendmsg() issue. After some investigation I found the problem (in XORP), and now it is fixed in CVS. Please get the latest code from CVS and let us know if you still see the compilation and/or run-time problem. Regards, Pavlin > Thanks, > Pavlin > > > regards, > > > > Below are the errors: > > > > 1. XORP IPv6 multicast (MLD only) > > [ 2006/11/28 11:28:32 ERROR xorp_fea:66931 MFEA +2249 > > mfea_proto_comm.cc proto_socket_write ] sendmsg(proto 58 size 24 from > > fe80::20c:29ff:fe35:3766 to ff02::1 on vif em1) failed: Device not > > configured > > [ 2006/11/28 11:28:32 WARNING xorp_fea XrlMfeaTarget ] Handling method > > for mfea/0.1/send_protocol_message6 failed: XrlCmdError 102 Command > > failed Cannot send MLD protocol message from fe80::20c:29ff:fe35:3766 > > to ff02::1 on vif em1: sendmsg(proto 58 size 24 from > > fe80::20c:29ff:fe35:3766 to ff02::1 on vif em1) failed: Device not > > configured > > [ 2006/11/28 11:28:32 ERROR xorp_mld:67010 MLD6IGMP +1519 > > xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cannot > > send a protocol message: 102 Command failed Cannot send MLD protocol > > message from fe80::20c:29ff:fe35:3766 to ff02::1 on vif em1: > > sendmsg(proto 58 size 24 from fe80::20c:29ff:fe35:3766 to ff02::1 on > > vif em1) failed: Device not configured > > > > 2. Compiler's segmentation fault (this is just FYI, the error should > > be forwarded to GNU guys) > > > > /usr/include/c++/3.4/bits/stl_list.h: In instantiation of `void > > std::list<_Tp, _Alloc>::_M_insert(std::_List_iterator<_Tp>, const > > _Tp&) [with _Tp = XrlAtom, _Alloc = std::allocator]': > > /usr/include/c++/3.4/bits/stl_list.h:755: instantiated from `void > > std::list<_Tp, _Alloc>::push_front(const _Tp&) [with _Tp = XrlAtom, > > _Alloc = std::allocator]' > > ../../libxipc/xrl_args.hh:470: instantiated from here > > /usr/include/c++/3.4/bits/stl_list.h:1164: internal compiler error: > > Segmentation fault: 11 > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See for instructions. > > gmake[3]: *** [print_lsas.o] Error 1 > > gmake[3]: Leaving directory `/usr/local/src/xorp-cvs/ospf/tools' > > gmake[2]: *** [all-recursive] Error 1 > > gmake[2]: Leaving directory `/usr/local/src/xorp-cvs/ospf' > > gmake[1]: *** [all-recursive] Error 1 > > gmake[1]: Leaving directory `/usr/local/src/xorp-cvs' > > gmake: *** [all] Error 2 > > > > > > > > > > -- > > > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From ahthamrin at gmail.com Wed Nov 29 20:29:12 2006 From: ahthamrin at gmail.com (A.H.T) Date: Thu, 30 Nov 2006 13:29:12 +0900 Subject: [Xorp-users] XORP 1.3 IPv6 mcast problem on FreeBSD 6.2RC1 In-Reply-To: <200611290824.kAT8Oc6C048715@possum.icir.org> References: <200611280955.kAS9tix8023799@possum.icir.org> <200611290824.kAT8Oc6C048715@possum.icir.org> Message-ID: <4250f3610611292029x29ad6f00s6fe813199f7f5f7d@mail.gmail.com> On 11/29/06, Pavlin Radoslavov wrote: > Pavlin Radoslavov wrote: > > I installed FreeBSD-6.2-RC1 (actually upgraded from FreeBSD-6.1) > and I didn't see the compilation error with the latest code from > CVS. > However, I was able to replicate the sendmsg() issue. After some > investigation I found the problem (in XORP), and now it is fixed > in CVS. > > Please get the latest code from CVS and let us know if you still see > the compilation and/or run-time problem. Thank you. I got the latest code from CVS and xorp is working fine so far. I will report back if there are problems. --