From Matthias_Bauer at genua.de Wed Aug 1 07:13:30 2007 From: Matthias_Bauer at genua.de (Matthias Bauer) Date: Wed, 1 Aug 2007 16:13:30 +0200 Subject: [Xorp-users] stub multicast routing? Message-ID: <20070801141330.GC15675@uschtu.genua.de> Hi, can xorp be configured to do what Cisco calls "stub multicast routing" ? In this mode, the router proxies IGMP messages between hosts and the uplink multicast router. Best regards, Matthias From eadigun at cs.up.ac.za Wed Aug 1 07:28:01 2007 From: eadigun at cs.up.ac.za (Emmanuel A. Adigun) Date: Wed, 1 Aug 2007 16:28:01 +0200 Subject: [Xorp-users] Address not adding In-Reply-To: <200707311740.l6VHevES070778@possum.icir.org> Message-ID: >Are you intending to configure RIP in such way so you can see the RIP >packets originated by one of the IP addresses on the interface and >received on the same interface (but the other IP address)? >I don't think it will work this way. >You should run RIP instances on two different (neighbor) machines, >and even then you should enable RIP on one IP address per interface. I've tried running RIP on two different interface card on the same machine, using a different address on the cards but still no luck. Part of the config is below as well as the results I get. protocols { rip { export: "connected" interface eth0 { vif eth0 { address 169.254.8.14 { disable: false metric: 1 horizon: "split-horizon-poison-reverse" passive: false accept-non-rip-requests: true accept-default-route: true /* advertise-defaut-route: true */ route-timeout: 180 deletion-delay: 120 triggered-delay: 3 triggered-jitter: 66 update-interval: 30 update-jitter: 16 request-interval: 30 interpacket-delay: 50 /* authentication { simple-password: "password"; md5 @: u32 { password: "password"; start-time: "2006-01-01.12:00" end-time: "2007-01-01.12:00" } } */ } } } export: "connected" interface eth2 { vif eth2 { address 169.254.5.17 { disable: false metric: 1 horizon: "split-horizon-poison-reverse" passive: false accept-non-rip-requests: true accept-default-route: true route-timeout: 180 deletion-delay: 120 triggered-delay: 3 triggered-jitter: 66 update-interval: 30 update-jitter: 16 request-interval: 30 interpacket-delay: 50 } } } export: "connected" } } root at eLinuxBox> show rip statistics all * RIP on eth0 eth0 169.254.8.14 Status: enabled Counter Value -------------------------------- ---------------- Requests Sent 33 Updates Sent 31 Triggered Updates Sent 1 Non-RIP Updates Sent 0 Total Packets Received 0 Request Packets Received 0 Update Packets Received 0 Bad Packets Received 0 Authentication Failures 0 Bad Routes Received 0 Non-RIP Requests Received 0 * RIP on eth2 eth2 169.254.5.17 Status: enabled Counter Value -------------------------------- ---------------- Requests Sent 33 Updates Sent 32 Triggered Updates Sent 0 Non-RIP Updates Sent 0 Total Packets Received 0 Request Packets Received 0 Update Packets Received 0 Bad Packets Received 0 Authentication Failures 0 Bad Routes Received 0 Non-RIP Requests Received 0 From pavlin at icir.org Wed Aug 1 11:01:17 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 01 Aug 2007 11:01:17 -0700 Subject: [Xorp-users] stub multicast routing? In-Reply-To: Message from Matthias Bauer of "Wed, 01 Aug 2007 16:13:30 +0200." <20070801141330.GC15675@uschtu.genua.de> Message-ID: <200708011801.l71I1HmM083894@possum.icir.org> > can xorp be configured to do what Cisco calls > "stub multicast routing" ? In this mode, the > router proxies IGMP messages between hosts and > the uplink multicast router. No, XORP doesn't implement the IGMP proxy mechanism (yet), though it is on our TODO list: http://www.xorp.org/bugzilla/show_bug.cgi?id=700 Regards, Pavlin From inlanderground at gmail.com Wed Aug 1 13:52:33 2007 From: inlanderground at gmail.com (Inlander) Date: Wed, 1 Aug 2007 20:52:33 +0000 Subject: [Xorp-users] Address not adding Message-ID: <2f21df50708011352k77c02863g6fbe683ecd97c2e1@mail.gmail.com> Hi, I'm a new user. I also running rip, with multicast. with 2 ethernet almost like yours. I saw that your configuration doesn't include prefix-length. I think you should add them to each interface. As long as I know. the IP 169.254.xxx.xxx is the autoconfiguration address. MS Windows use it when Windows doesn't find any dhcp address. those IP use prefix-length or subnet mask in 16 length. so I think probably your xorp can't be called as a router if they have same addresses on their interfaces. CMIIW Regards, >Are you intending to configure RIP in such way so you can see the RIP > >packets originated by one of the IP addresses on the interface and > >received on the same interface (but the other IP address)? > >I don't think it will work this way. > >You should run RIP instances on two different (neighbor) machines, > >and even then you should enable RIP on one IP address per interface. > > I've tried running RIP on two different interface card on the same > machine, > using a different address on the cards but still no luck. Part of the > config > is below as well as the results I get. > > protocols { > rip { > export: "connected" > interface eth0 { > vif eth0 { > address 169.254.8.14 { > disable: false > metric: 1 > horizon: "split-horizon-poison-reverse" > passive: false > accept-non-rip-requests: true > accept-default-route: true > /* advertise-defaut-route: true */ > route-timeout: 180 > deletion-delay: 120 > triggered-delay: 3 > triggered-jitter: 66 > update-interval: 30 > update-jitter: 16 > request-interval: 30 > interpacket-delay: 50 > /* > authentication { > simple-password: "password"; > md5 @: u32 { > password: "password"; > start-time: "2006-01-01.12:00" > end-time: "2007-01-01.12:00" > } > } > */ > } > } > } > export: "connected" > > interface eth2 { > vif eth2 { > address 169.254.5.17 { > disable: false > metric: 1 > horizon: "split-horizon-poison-reverse" > passive: false > accept-non-rip-requests: true > accept-default-route: true > route-timeout: 180 > deletion-delay: 120 > triggered-delay: 3 > triggered-jitter: 66 > update-interval: 30 > update-jitter: 16 > request-interval: 30 > interpacket-delay: 50 > } > } > } > export: "connected" > } > } > > root at eLinuxBox> show rip statistics all > > * RIP on eth0 eth0 169.254.8.14 > Status: enabled > > Counter Value > -------------------------------- ---------------- > Requests Sent 33 > Updates Sent 31 > Triggered Updates Sent 1 > Non-RIP Updates Sent 0 > Total Packets Received 0 > Request Packets Received 0 > Update Packets Received 0 > Bad Packets Received 0 > Authentication Failures 0 > Bad Routes Received 0 > Non-RIP Requests Received 0 > > * RIP on eth2 eth2 169.254.5.17 > Status: enabled > > Counter Value > -------------------------------- ---------------- > Requests Sent 33 > Updates Sent 32 > Triggered Updates Sent 0 > Non-RIP Updates Sent 0 > Total Packets Received 0 > Request Packets Received 0 > Update Packets Received 0 > Bad Packets Received 0 > Authentication Failures 0 > Bad Routes Received 0 > Non-RIP Requests Received 0 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070801/39c06b10/attachment.html From pavlin at icir.org Wed Aug 1 16:15:14 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 01 Aug 2007 16:15:14 -0700 Subject: [Xorp-users] Address not adding In-Reply-To: Message from Inlander of "Wed, 01 Aug 2007 20:52:33 -0000." <2f21df50708011352k77c02863g6fbe683ecd97c2e1@mail.gmail.com> Message-ID: <200708012315.l71NFECu014630@possum.icir.org> Inlander wrote: > Hi, I'm a new user. I also running rip, with multicast. with 2 ethernet > almost like yours. > I saw that your configuration doesn't include prefix-length. > I think you should add them to each interface. > As long as I know. the IP 169.254.xxx.xxx is the autoconfiguration address. > MS Windows use it when Windows doesn't find any dhcp address. > those IP use prefix-length or subnet mask in 16 length. > so I think probably your xorp can't be called as a router if they have same > addresses > on their interfaces. Good question about the prefix-length. Independently, I also started looking into that direction, because it wasn'c clear from Emmanuel's email whether the 169.254.8.14 and 169.254.5.17 belong to the same subnet address prefix (i.e., whether the prefix length is 16 or 24 bits for example). Myself I did some tests with both addresses being the same subnet, and I found that the RIP packets originated by XORP are not received back (even though they are originated on two different interfaces). The reason for that is because there is a single UDP socket (that was bind(2) to address ZERO (or any) and port 520), and that socket is used for all sending and receiving. The "multicast_loopback" socket option for that socket is explicitly disabled, hence no packets sent on that socket are received back. Well, this behavior is technically correct because there is no point for RIP itself to receive and process its own packets. Though this probably not the behavior you were expecting :) Anyway, if you REALLY want to receive the RIP packets, then just apply the following patch that will enable the "multicast_loopback" option: Index: xrl_port_io.cc =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/rip/xrl_port_io.cc,v retrieving revision 1.22 diff -u -p -r1.22 xrl_port_io.cc --- xrl_port_io.cc 16 Feb 2007 22:47:17 -0000 1.22 +++ xrl_port_io.cc 1 Aug 2007 23:01:19 -0000 @@ -112,7 +112,7 @@ XrlPortIO::request_no_loop() { XrlSocket4V0p1Client cl(&_xr); return cl.send_set_socket_option( - _ss.c_str(), socket_id(), "multicast_loopback", 0, + _ss.c_str(), socket_id(), "multicast_loopback", 1, callback(this, &XrlPortIO::no_loop_cb)); } @@ -225,7 +225,7 @@ XrlPortIO::request_no_loop() { XrlSocket6V0p1Client cl(&_xr); return cl.send_set_socket_option( - _ss.c_str(), socket_id(), "multicast_loopback", 0, + _ss.c_str(), socket_id(), "multicast_loopback", 1, callback(this, &XrlPortIO::no_loop_cb)); } However, note that this is NOT the intended RIP operation, so if you do this all bets are OFF: there is no guarantee that the received packets will be processed as you might expect, etc. Instead, you might want to try running two different instances of XORP. For that, you need to set the XORP_FINDER_SERVER_PORT environmental variable to two different values before starting each XORP instance. E.g., in csh/tcsh: setenv XORP_FINDER_SERVER_PORT 22222 ./xorp_rtrmgr -b config1.boot setenv XORP_FINDER_SERVER_PORT 22223 ./xorp_rtrmgr -b config2.boot There is no guarantee this will work, because most likely both instances might try to install the same route to the kernel so the result will be unpredictable. To get around this you might need to run, say, two VMWare instances one for each XORP instances, and just interconnect them via some of the virtual vmnet* interfaces. Other solutions that come to mind are using UML (User Mode Linux) and/or something like VINI (http://www.vini-veritas.net/). Again, as I mentioned in my earlier emails, if you have two PCs and you want to avoid the extra hassle of installing and configuring VMWare and friends, then just connect those PCs together and run RIP on each of them. Regards, Pavlin > CMIIW > > Regards, > > >Are you intending to configure RIP in such way so you can see the RIP > > >packets originated by one of the IP addresses on the interface and > > >received on the same interface (but the other IP address)? > > >I don't think it will work this way. > > >You should run RIP instances on two different (neighbor) machines, > > >and even then you should enable RIP on one IP address per interface. > > > > I've tried running RIP on two different interface card on the same > > machine, > > using a different address on the cards but still no luck. Part of the > > config > > is below as well as the results I get. > > > > protocols { > > rip { > > export: "connected" > > interface eth0 { > > vif eth0 { > > address 169.254.8.14 { > > disable: false > > metric: 1 > > horizon: "split-horizon-poison-reverse" > > passive: false > > accept-non-rip-requests: true > > accept-default-route: true > > /* advertise-defaut-route: true */ > > route-timeout: 180 > > deletion-delay: 120 > > triggered-delay: 3 > > triggered-jitter: 66 > > update-interval: 30 > > update-jitter: 16 > > request-interval: 30 > > interpacket-delay: 50 > > /* > > authentication { > > simple-password: "password"; > > md5 @: u32 { > > password: "password"; > > start-time: "2006-01-01.12:00" > > end-time: "2007-01-01.12:00" > > } > > } > > */ > > } > > } > > } > > export: "connected" > > > > interface eth2 { > > vif eth2 { > > address 169.254.5.17 { > > disable: false > > metric: 1 > > horizon: "split-horizon-poison-reverse" > > passive: false > > accept-non-rip-requests: true > > accept-default-route: true > > route-timeout: 180 > > deletion-delay: 120 > > triggered-delay: 3 > > triggered-jitter: 66 > > update-interval: 30 > > update-jitter: 16 > > request-interval: 30 > > interpacket-delay: 50 > > } > > } > > } > > export: "connected" > > } > > } > > > > root at eLinuxBox> show rip statistics all > > > > * RIP on eth0 eth0 169.254.8.14 > > Status: enabled > > > > Counter Value > > -------------------------------- ---------------- > > Requests Sent 33 > > Updates Sent 31 > > Triggered Updates Sent 1 > > Non-RIP Updates Sent 0 > > Total Packets Received 0 > > Request Packets Received 0 > > Update Packets Received 0 > > Bad Packets Received 0 > > Authentication Failures 0 > > Bad Routes Received 0 > > Non-RIP Requests Received 0 > > > > * RIP on eth2 eth2 169.254.5.17 > > Status: enabled > > > > Counter Value > > -------------------------------- ---------------- > > Requests Sent 33 > > Updates Sent 32 > > Triggered Updates Sent 0 > > Non-RIP Updates Sent 0 > > Total Packets Received 0 > > Request Packets Received 0 > > Update Packets Received 0 > > Bad Packets Received 0 > > Authentication Failures 0 > > Bad Routes Received 0 > > Non-RIP Requests Received 0 > > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From c.d.chapman at reading.ac.uk Thu Aug 2 03:10:07 2007 From: c.d.chapman at reading.ac.uk (Christopher David Chapman) Date: Thu, 2 Aug 2007 11:10:07 +0100 Subject: [Xorp-users] Problems verifying compalation Message-ID: <8316105576AA84449272440E676F1314016EE91F@vime1.rdg-home.ad.rdg.ac.uk> Hi Folks, I am trying to get xorp running under gentoo. I compiled the code without any errors but running the verification errors while testing test_vif. A check on google didn't turn up any hits, Has anybody else seen this? Or got it working under gentoo? Error as follows: --------------- PASS PASS: test_trie PASS: test_types PASS: test_utils /bin/sh: line 4: 7241 Segmentation fault ${dir}$tst FAIL: test_vif ==================== 2 of 27 tests failed ==================== make[2]: *** [check-TESTS] Error 1 make[2]: Leaving directory `/usr/src/xorp-1.4/libxorp' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/usr/src/xorp-1.4/libxorp' make: *** [check-recursive] Error 1 Cheers Chris "Why is Gaffa tape like the force? Because it has a light side, a dark side, and it holds the universe together!" ----------------===========---------------- Christopher Chapman Systems Programmer ITNG School of Systems Engineering The University of Reading E-mail: c.d.chapman at reading.ac.uk Phone:? +44 (0)118 3787664 School of Systems Engineering The University of Reading PO Box 225 Whiteknights Reading RG6 6AY ----------------===========---------------- From pavlin at icir.org Thu Aug 2 09:50:41 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 02 Aug 2007 09:50:41 -0700 Subject: [Xorp-users] Problems verifying compalation In-Reply-To: Message from "Christopher David Chapman" of "Thu, 02 Aug 2007 11:10:07 BST." <8316105576AA84449272440E676F1314016EE91F@vime1.rdg-home.ad.rdg.ac.uk> Message-ID: <200708021650.l72GofI4023617@possum.icir.org> Christopher David Chapman wrote: > Hi Folks, > > I am trying to get xorp running under gentoo. I compiled the code without any errors but running the verification errors while testing test_vif. A check on google didn't turn up any hits, Has anybody else seen this? Or got it working under gentoo? > > Error as follows: > > --------------- > PASS > PASS: test_trie > PASS: test_types > PASS: test_utils > /bin/sh: line 4: 7241 Segmentation fault ${dir}$tst > FAIL: test_vif > ==================== > 2 of 27 tests failed > ==================== > make[2]: *** [check-TESTS] Error 1 > make[2]: Leaving directory `/usr/src/xorp-1.4/libxorp' > make[1]: *** [check-am] Error 2 > make[1]: Leaving directory `/usr/src/xorp-1.4/libxorp' > make: *** [check-recursive] Error 1 What Gentoo version and what compiler are you using? We have Gentoo 2006.1 with gcc-4.1.1 and we don't see that problem. Can you run gdb on the coredump file and trace where it failed: gdb test_vif -c bt Thanks, Pavlin > Cheers > Chris > > > "Why is Gaffa tape like the force? > Because it has a light side, a dark side, and it holds the universe together!" > > ----------------===========---------------- > Christopher Chapman > Systems Programmer ITNG > School of Systems Engineering > The University of Reading > > E-mail: c.d.chapman at reading.ac.uk > Phone:? +44 (0)118 3787664 > > School of Systems Engineering > The University of Reading > PO Box 225 > Whiteknights > Reading > RG6 6AY > ----------------===========---------------- > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From c.d.chapman at reading.ac.uk Fri Aug 3 01:51:11 2007 From: c.d.chapman at reading.ac.uk (Christopher David Chapman) Date: Fri, 3 Aug 2007 09:51:11 +0100 Subject: [Xorp-users] Problems verifying compalation In-Reply-To: <200708021650.l72GofI4023617@possum.icir.org> References: Message from "Christopher David Chapman" of "Thu, 02 Aug 2007 11:10:07 BST." <8316105576AA84449272440E676F1314016EE91F@vime1.rdg-home.ad.rdg.ac.uk> <200708021650.l72GofI4023617@possum.icir.org> Message-ID: <8316105576AA84449272440E676F131401742ADF@vime1.rdg-home.ad.rdg.ac.uk> Thanks for getting back to me so soon, I am using gentoo 2007.0-r1 with the hardened profile and gcc 3.4.6. The system is configured with two nics bonded together an then tagged to vlans, so interfaces are bond0.1 bond0.2 etc. Gdb Dump fw-sse-int libxorp # ./test_vif Segmentation fault (core dumped) fw-sse-int libxorp # gdb test_vif -c core GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `./test_vif'. Program terminated with signal 11, Segmentation fault. #0 0xb7d78f09 in _start () from /lib/ld-linux.so.2 (gdb) bt #0 0xb7d78f09 in _start () from /lib/ld-linux.so.2 #1 0xb7d01e6c in ?? () #2 0xb7d03140 in ?? () #3 0x80033188 in ?? () #4 0xbff773a8 in ?? () #5 0x00000000 in ?? () (gdb) Cheers Chris "Why is Gaffa tape like the force? Because it has a light side, a dark side, and it holds the universe together!" ----------------===========---------------- Christopher Chapman Systems Programmer ITNG School of Systems Engineering The University of Reading E-mail: c.d.chapman at reading.ac.uk Phone:? +44 (0)118 3787664 School of Systems Engineering The University of Reading PO Box 225 Whiteknights Reading RG6 6AY ----------------===========---------------- -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin at icir.org] Sent: 02 August 2007 17:51 To: Christopher David Chapman Cc: xorp-users at xorp.org Subject: Re: [Xorp-users] Problems verifying compalation Christopher David Chapman wrote: > Hi Folks, > > I am trying to get xorp running under gentoo. I compiled the code without any errors but running the verification errors while testing test_vif. A check on google didn't turn up any hits, Has anybody else seen this? Or got it working under gentoo? > > Error as follows: > > --------------- > PASS > PASS: test_trie > PASS: test_types > PASS: test_utils > /bin/sh: line 4: 7241 Segmentation fault ${dir}$tst > FAIL: test_vif > ==================== > 2 of 27 tests failed > ==================== > make[2]: *** [check-TESTS] Error 1 > make[2]: Leaving directory `/usr/src/xorp-1.4/libxorp' > make[1]: *** [check-am] Error 2 > make[1]: Leaving directory `/usr/src/xorp-1.4/libxorp' > make: *** [check-recursive] Error 1 What Gentoo version and what compiler are you using? We have Gentoo 2006.1 with gcc-4.1.1 and we don't see that problem. Can you run gdb on the coredump file and trace where it failed: gdb test_vif -c bt Thanks, Pavlin > Cheers > Chris > > > "Why is Gaffa tape like the force? > Because it has a light side, a dark side, and it holds the universe together!" > > ----------------===========---------------- > Christopher Chapman > Systems Programmer ITNG > School of Systems Engineering > The University of Reading > > E-mail: c.d.chapman at reading.ac.uk > Phone:? +44 (0)118 3787664 > > School of Systems Engineering > The University of Reading > PO Box 225 > Whiteknights > Reading > RG6 6AY > ----------------===========---------------- > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Fri Aug 3 09:41:53 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 03 Aug 2007 09:41:53 -0700 Subject: [Xorp-users] Problems verifying compalation In-Reply-To: Message from "Christopher David Chapman" of "Fri, 03 Aug 2007 09:51:11 BST." <8316105576AA84449272440E676F131401742ADF@vime1.rdg-home.ad.rdg.ac.uk> Message-ID: <200708031642.l73GfrnC052912@possum.icir.org> Christopher David Chapman wrote: > Thanks for getting back to me so soon, > > I am using gentoo 2007.0-r1 with the hardened profile and gcc 3.4.6. > The system is configured with two nics bonded together an then tagged to vlans, so interfaces are bond0.1 bond0.2 etc. > > > Gdb Dump > > fw-sse-int libxorp # ./test_vif > Segmentation fault (core dumped) > fw-sse-int libxorp # gdb test_vif -c core > GNU gdb 6.6 > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"... > Using host libthread_db library "/lib/libthread_db.so.1". > Core was generated by `./test_vif'. > Program terminated with signal 11, Segmentation fault. > #0 0xb7d78f09 in _start () from /lib/ld-linux.so.2 > (gdb) bt > #0 0xb7d78f09 in _start () from /lib/ld-linux.so.2 > #1 0xb7d01e6c in ?? () > #2 0xb7d03140 in ?? () > #3 0x80033188 in ?? () > #4 0xbff773a8 in ?? () > #5 0x00000000 in ?? () > (gdb) Thank you for the info. Unfortunately, it seems that XORP has been compiled with the debugging information disabled, so the above backtrace doesn't show where (or why) test_vif has crashed. Could you send the list of your compilation flags. E.g., after you run ./confugure, you should see them at the end: Compiler C flags = -g -Werror -W -Wall -Wwrite-strings -Wbad-function-cast -Wmissing-prototypes -Wcast-qual -Wmissing-declarations -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs -pipe Compiler C++ flags = -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe Also, please re-compile XORP with debugging information enabled (e.g., just by running ./configure). Actually, you need to compile only the libxorp directory: ./configure cd libxorp gmake clean gmake gmake check Then rerun again the ./test_vif program and "gdb" on the result core file. Alternatively, if you can give me a temporary account to your box I will be glad to look at the problem, because most likely it might take few extra rounds of email exchange chaising it and fixing it. Thanks, Pavlin > Cheers > Chris > > "Why is Gaffa tape like the force? > Because it has a light side, a dark side, and it holds the universe together!" > > ----------------===========---------------- > Christopher Chapman > Systems Programmer ITNG > School of Systems Engineering > The University of Reading > > E-mail: c.d.chapman at reading.ac.uk > Phone:? +44 (0)118 3787664 > > School of Systems Engineering > The University of Reading > PO Box 225 > Whiteknights > Reading > RG6 6AY > ----------------===========---------------- > > > -----Original Message----- > From: Pavlin Radoslavov [mailto:pavlin at icir.org] > Sent: 02 August 2007 17:51 > To: Christopher David Chapman > Cc: xorp-users at xorp.org > Subject: Re: [Xorp-users] Problems verifying compalation > > Christopher David Chapman wrote: > > > Hi Folks, > > > > I am trying to get xorp running under gentoo. I compiled the code without any errors but running the verification errors while testing test_vif. A check on google didn't turn up any hits, Has anybody else seen this? Or got it working under gentoo? > > > > Error as follows: > > > > --------------- > > PASS > > PASS: test_trie > > PASS: test_types > > PASS: test_utils > > /bin/sh: line 4: 7241 Segmentation fault ${dir}$tst > > FAIL: test_vif > > ==================== > > 2 of 27 tests failed > > ==================== > > make[2]: *** [check-TESTS] Error 1 > > make[2]: Leaving directory `/usr/src/xorp-1.4/libxorp' > > make[1]: *** [check-am] Error 2 > > make[1]: Leaving directory `/usr/src/xorp-1.4/libxorp' > > make: *** [check-recursive] Error 1 > > What Gentoo version and what compiler are you using? > We have Gentoo 2006.1 with gcc-4.1.1 and we don't see that problem. > Can you run gdb on the coredump file and trace where it failed: > > gdb test_vif -c > bt > > Thanks, > Pavlin > > > Cheers > > Chris > > > > > > "Why is Gaffa tape like the force? > > Because it has a light side, a dark side, and it holds the universe together!" > > > > ----------------===========---------------- > > Christopher Chapman > > Systems Programmer ITNG > > School of Systems Engineering > > The University of Reading > > > > E-mail: c.d.chapman at reading.ac.uk > > Phone:? +44 (0)118 3787664 > > > > School of Systems Engineering > > The University of Reading > > PO Box 225 > > Whiteknights > > Reading > > RG6 6AY > > ----------------===========---------------- > > > > > > > > _______________________________________________ > > 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 greearb at candelatech.com Wed Aug 8 15:07:18 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 08 Aug 2007 15:07:18 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables. Message-ID: <46BA3E96.5090406@candelatech.com> Hello! I am curious how hard it would be to get Xorp to support multiple routing tables. My goal is to support virtual routers (VR). For instance, suppose eth0 and eth1 belong to one VR, and eth2 and eth3 to a second VR. I'd associate eth0 and eth1 with routing table X, and eth2 and eth3 with routing table Y. I'd want the Xorp daemon to treat the two sets of interfaces completely separate, and update the correct routing table as needed. Xorp should NOT, for instance, think that eth2 can talk to eth0 unless OSPF messages or similar are received on the eth0 and eth2 interfaces allowing such communication. I already have scripts to create the proper routing tables and a few patches to the kernel to make this work, but I'd like to support 'real' routing protocols as well. Assuming this cannot currently be done, if anyone is interested in developing this (possibly for a fee), please contact me. (off-list if the $fee option interests you). Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Wed Aug 8 18:33:23 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 08 Aug 2007 18:33:23 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables. In-Reply-To: Message from Ben Greear of "Wed, 08 Aug 2007 15:07:18 PDT." <46BA3E96.5090406@candelatech.com> Message-ID: <200708090133.l791XNVi026816@possum.icir.org> Ben Greear wrote: > Hello! > > I am curious how hard it would be to get Xorp to support > multiple routing tables. My goal is to support virtual routers (VR). > > For instance, suppose eth0 and eth1 belong to one VR, and eth2 and eth3 to > a second VR. I'd associate eth0 and eth1 with routing table X, and eth2 and eth3 > with routing table Y. I'd want the Xorp daemon to treat the two sets of > interfaces completely separate, and update the correct routing table as needed. > Xorp should NOT, for instance, think that eth2 can talk to eth0 unless OSPF > messages or similar are received on the eth0 and eth2 interfaces allowing such > communication. > > I already have scripts to create the proper routing tables and a few patches > to the kernel to make this work, but I'd like to support 'real' routing protocols > as well. What kind of isolation do you want between the VRs? E.g., do you want to run a single XORP instance that will control two forwarding tables, or do you want to run 2+ XORP instances (one per forwarding table). If you want to run 2+ XORP instances, you can probably do it with just a little bit extra work: * Right now all forwarding entries are installed in the main forwarding table RT_TABLE_MAIN. You need to modify the FEA such that it allows to specify the corresponding routing/forwarding table ID it should be manipulating. The table ID is used inside the fea/data_llane/fibconfig/ directory (search for rtm_table). There are total of three places where rtm_table is used. In all those cases it should take some pre-configured table ID. A new configuraion XRL should be added to the FEA that will be used to configure/specify the forwarding table ID. This XRL should be added to xrl/interfaces/fti.xif and should look like: /** * Set the forwarding table ID. * * @param table_id the forwarding table ID. */ set_forwarding_table_id ? table_id:u32 Then, obviously, the processing side for this XRL needs to be implemented inside fea/xrl_fea_target.hh and fea/xrl_target.cc Finally, inside etc/templates/fea.tp there should be a configuration entry for the forwarding table ID. * Before starting each XORP instance you must specify a different port number to be used by the XORP Finder. E.g.: setenv XORP_FINDER_SERVER_PORT 20001 # Start first XORP instance setenv XORP_FINDER_SERVER_PORT 20002 # Start second XORP instance * It is up to you to make sure that inside the XORP configuration for each XORP instance you configure/use only those interfaces that correspond to the particular forwarding table. E.g., in the first XORP instance you should configure only eth1 and eth2, and in the second XORP instance you should configure only eth3 and eth4. BTW, note that the above solution might work for unicast, but won't work for multicast forwarding, because the UNIX kernel allows only one open multicast routing socket per system. If the above is sufficient for your need, then it is relatively easy to implement it. It will be actually useful for XORP itself, so we might actually implement it anyway (for free :). However, if you want to run a single XORP instance that will control 2+ forwarding tables, this will be much more complicated to do. For example, there should be somewhere a mapping which interfaces are associated with each forwarding table. Futhermore, if each routing process needs to be aware about the separation, then it will become ever more complicated. This might lead to a design which will allow you to configure, say, 2 OSPF instances each of them talking to 2 RIB instances. If you have something else in mind, please provide more details. Regards, Pavlin > Assuming this cannot currently be done, if anyone is interested in developing > this (possibly for a fee), please contact me. (off-list if the $fee option > interests you). > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Wed Aug 8 20:38:06 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 08 Aug 2007 20:38:06 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables. In-Reply-To: <200708090133.l791XNVi026816@possum.icir.org> References: <200708090133.l791XNVi026816@possum.icir.org> Message-ID: <46BA8C1E.20405@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > >> Hello! >> >> I am curious how hard it would be to get Xorp to support >> multiple routing tables. My goal is to support virtual routers (VR). >> >> For instance, suppose eth0 and eth1 belong to one VR, and eth2 and eth3 to >> a second VR. I'd associate eth0 and eth1 with routing table X, and eth2 and eth3 >> with routing table Y. I'd want the Xorp daemon to treat the two sets of >> interfaces completely separate, and update the correct routing table as needed. >> Xorp should NOT, for instance, think that eth2 can talk to eth0 unless OSPF >> messages or similar are received on the eth0 and eth2 interfaces allowing such >> communication. >> >> I already have scripts to create the proper routing tables and a few patches >> to the kernel to make this work, but I'd like to support 'real' routing protocols >> as well. >> > > What kind of isolation do you want between the VRs? > E.g., do you want to run a single XORP instance that will control > two forwarding tables, or do you want to run 2+ XORP instances > (one per forwarding table). > > If you want to run 2+ XORP instances, you can probably do it with > just a little bit extra work: > > * Right now all forwarding entries are installed in the main > forwarding table RT_TABLE_MAIN. > You need to modify the FEA such that it allows to specify the > corresponding routing/forwarding table ID it should be > manipulating. The table ID is used inside the > fea/data_llane/fibconfig/ directory (search for rtm_table). > There are total of three places where rtm_table is used. In all > those cases it should take some pre-configured table ID. > > A new configuraion XRL should be added to the FEA that will be > used to configure/specify the forwarding table ID. > This XRL should be added to xrl/interfaces/fti.xif and should > look like: > > /** > * Set the forwarding table ID. > * > * @param table_id the forwarding table ID. > */ > set_forwarding_table_id ? table_id:u32 > > Then, obviously, the processing side for this XRL needs to be > implemented inside fea/xrl_fea_target.hh and fea/xrl_target.cc > > Finally, inside etc/templates/fea.tp there should be a > configuration entry for the forwarding table ID. > > * Before starting each XORP instance you must specify a different > port number to be used by the XORP Finder. E.g.: > > setenv XORP_FINDER_SERVER_PORT 20001 > # Start first XORP instance > > setenv XORP_FINDER_SERVER_PORT 20002 > # Start second XORP instance > > * It is up to you to make sure that inside the XORP configuration > for each XORP instance you configure/use only those interfaces > that correspond to the particular forwarding table. E.g., in the > first XORP instance you should configure only eth1 and eth2, and > in the second XORP instance you should configure only eth3 and > eth4. > > BTW, note that the above solution might work for unicast, but won't > work for multicast forwarding, because the UNIX kernel allows > only one open multicast routing socket per system. > > If the above is sufficient for your need, then it is relatively easy > to implement it. It will be actually useful for XORP itself, so we > might actually implement it anyway (for free :). > This sounds like a good first step, and it sounds like it meets my immediate needs. Instead of an environment variable, I'd prefer a cmd-line variable and/or something in the xorp router config file. However, I know almost nothing about how Xorp is written, so if it needs to be an environ variable, that is OK. I do not need this to support multicast at the moment. Eventually, I'd like to scale to 100s of VRs, so it would probably be more efficient to run a smaller number of Xorp processes, each able to handle a lot of routing tables, but that can be dealt with later. And, it may turn out that running 100+ processes is not such a big deal considering all of the cores on newer systems... > However, if you want to run a single XORP instance that will control > 2+ forwarding tables, this will be much more complicated to do. > For example, there should be somewhere a mapping which interfaces are > associated with each forwarding table. Futhermore, if each routing > process needs to be aware about the separation, then it will become > ever more complicated. This might lead to a design which will allow > you to configure, say, 2 OSPF instances each of them talking to 2 > RIB instances. > I'd expect to configure which route-table an interface belongs to similar to how you add an IP to a interface. Or, could have a larger 'virtual-router' section that holds all the ports & info for that router instance. It's likely the individual logic units would be one per VR, and they would not talk to each other directly (but only through normal message passing on the interfaces). I figure this will be more efficient because there will be only one process, but again, I could be wrong about that. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Thu Aug 9 00:51:23 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 09 Aug 2007 00:51:23 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables. In-Reply-To: Message from Ben Greear of "Wed, 08 Aug 2007 20:38:06 PDT." <46BA8C1E.20405@candelatech.com> Message-ID: <200708090751.l797pNLi043228@possum.icir.org> > >> I am curious how hard it would be to get Xorp to support > >> multiple routing tables. My goal is to support virtual routers (VR). > >> > >> For instance, suppose eth0 and eth1 belong to one VR, and eth2 and eth3 to > >> a second VR. I'd associate eth0 and eth1 with routing table X, and eth2 and eth3 > >> with routing table Y. I'd want the Xorp daemon to treat the two sets of > >> interfaces completely separate, and update the correct routing table as needed. > >> Xorp should NOT, for instance, think that eth2 can talk to eth0 unless OSPF > >> messages or similar are received on the eth0 and eth2 interfaces allowing such > >> communication. > >> > >> I already have scripts to create the proper routing tables and a few patches > >> to the kernel to make this work, but I'd like to support 'real' routing protocols > >> as well. > >> > > > > What kind of isolation do you want between the VRs? > > E.g., do you want to run a single XORP instance that will control > > two forwarding tables, or do you want to run 2+ XORP instances > > (one per forwarding table). > > > > If you want to run 2+ XORP instances, you can probably do it with > > just a little bit extra work: > > > > * Right now all forwarding entries are installed in the main > > forwarding table RT_TABLE_MAIN. > > You need to modify the FEA such that it allows to specify the > > corresponding routing/forwarding table ID it should be > > manipulating. The table ID is used inside the > > fea/data_llane/fibconfig/ directory (search for rtm_table). > > There are total of three places where rtm_table is used. In all > > those cases it should take some pre-configured table ID. > > > > A new configuraion XRL should be added to the FEA that will be > > used to configure/specify the forwarding table ID. > > This XRL should be added to xrl/interfaces/fti.xif and should > > look like: > > > > /** > > * Set the forwarding table ID. > > * > > * @param table_id the forwarding table ID. > > */ > > set_forwarding_table_id ? table_id:u32 > > > > Then, obviously, the processing side for this XRL needs to be > > implemented inside fea/xrl_fea_target.hh and fea/xrl_target.cc > > > > Finally, inside etc/templates/fea.tp there should be a > > configuration entry for the forwarding table ID. > > > > * Before starting each XORP instance you must specify a different > > port number to be used by the XORP Finder. E.g.: > > > > setenv XORP_FINDER_SERVER_PORT 20001 > > # Start first XORP instance > > > > setenv XORP_FINDER_SERVER_PORT 20002 > > # Start second XORP instance > > > > * It is up to you to make sure that inside the XORP configuration > > for each XORP instance you configure/use only those interfaces > > that correspond to the particular forwarding table. E.g., in the > > first XORP instance you should configure only eth1 and eth2, and > > in the second XORP instance you should configure only eth3 and > > eth4. > > > > BTW, note that the above solution might work for unicast, but won't > > work for multicast forwarding, because the UNIX kernel allows > > only one open multicast routing socket per system. > > > > If the above is sufficient for your need, then it is relatively easy > > to implement it. It will be actually useful for XORP itself, so we > > might actually implement it anyway (for free :). > > > This sounds like a good first step, and it sounds like it meets my > immediate needs. Instead OK, I just committed to CVS the changes for configuring the table ID. You can do it with configuration like: fea { unicast-forwarding4 { table-id: 20 } unicast-forwarding6 { table-id: 20 } } Obviously, you won't need the unicast-forwarding6 section if you don't need IPv6. I just did some simple testing and it appears to work. Please get the latest code from anon. CVS and let us know whether it works for you: http://www.xorp.org/cvs.html > of an environment variable, I'd prefer a cmd-line variable and/or > something in > the xorp router config file. However, I know almost nothing about how Xorp > is written, so if it needs to be an environ variable, that is OK. Eventually, in the future we should add support for configuring the Finder's address and port inside the XORP confuguration file, but such change probably won't be trivial. BTW, if you set the environmental variable before starting the XORP rtrmgr, you need to set that variable as well before starting the corresponding xorpsh CLI. > I do not need this to support multicast at the moment. > > Eventually, I'd like to scale to 100s of VRs, so it would probably be > more efficient to run a > smaller number of Xorp processes, each able to handle a lot of routing > tables, but > that can be dealt with later. And, it may turn out that running 100+ > processes > is not such a big deal considering all of the cores on newer systems... Probably you will be the first one to try 100s of XORP instances, so we would be very interested to know how it goes. BTW, in Linux you cannot have more than 255 or so forwarding tables, and some of those tables shouldn't be touched, so ~250 is the max. number of table IDs and XORP instances you can try. > > However, if you want to run a single XORP instance that will control > > 2+ forwarding tables, this will be much more complicated to do. > > For example, there should be somewhere a mapping which interfaces are > > associated with each forwarding table. Futhermore, if each routing > > process needs to be aware about the separation, then it will become > > ever more complicated. This might lead to a design which will allow > > you to configure, say, 2 OSPF instances each of them talking to 2 > > RIB instances. > > > > I'd expect to configure which route-table an interface belongs to > similar to how > you add an IP to a interface. Or, could have a larger 'virtual-router' > section that > holds all the ports & info for that router instance. It's likely the > individual logic > units would be one per VR, and they would not talk to each other > directly (but only > through normal message passing on the interfaces). I figure this will > be more > efficient because there will be only one process, but again, I could be > wrong > about that. Yes, once we have proper VR support in XORP, eventually we will use configuration sections like what you suggest above. However, this is down the road so I am afraid that for the time being the burden is on you to configure properly each XORP instance. Though, the UCL folks who are looking into that space might have some other ideas/suggestions. Regards, Pavlin > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Thu Aug 9 08:50:57 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 09 Aug 2007 08:50:57 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables. In-Reply-To: <200708090751.l797pNLi043228@possum.icir.org> References: <200708090751.l797pNLi043228@possum.icir.org> Message-ID: <46BB37E1.9000903@candelatech.com> Pavlin Radoslavov wrote: >> This sounds like a good first step, and it sounds like it meets my >> immediate needs. Instead >> > > OK, I just committed to CVS the changes for configuring the table > ID. You can do it with configuration like: > > fea { > unicast-forwarding4 { > table-id: 20 > } > unicast-forwarding6 { > table-id: 20 > } > } > > Obviously, you won't need the unicast-forwarding6 section if you > don't need IPv6. > > I just did some simple testing and it appears to work. > Please get the latest code from anon. CVS and let us know whether it > works for you: > > http://www.xorp.org/cvs.html > Thank you! This was a bit faster than I had hoped, so it may take a day or two before we can try it out! I'm going to have to read up on how to configure Xorp, as I haven't configured an OSPF router or set of routers before. In case you have time & inclination, do you have two simple config files to make this route with OSPF: VR1: table 100, eth0, eth1 VR2: table 101, eth2, eth3 Assume eth1 and eth2 are connected to each other via cross-over cable and some separate PCs are connected to eth0 and eth3. In order to make the messages go over the external interfaces, the Xorp code will probably need an option to bind to the local IP and device. For TCP sockets that can do this, my code looks like this (I don't know if this applies to IPv6 or not..I've only tried with IPv4.) int createTcpSocket(unsigned int ip_addr, int ip_port, const char* dev_to_bind_to) { int s = socket(AF_INET, SOCK_STREAM, 0); if (s < 0) { cerr << "ERROR: tcp socket: " << LFSTRERROR << endl; return s; } close_exec(s); reuseaddr_socket(s); if (dev_to_bind_to) { // Bind to specific device. #ifndef __WIN32__ if (setsockopt(s, SOL_SOCKET, SO_BINDTODEVICE, dev_to_bind_to, DEV_NAME_LEN + 1)) { VLOG_ERR(VLOG << "ERROR: tcp-connect, setsockopt (BINDTODEVICE): " << LFSTRERROR << " Not fatal in most cases..continuing...\n"); } #endif }//if struct sockaddr_in my_ip_addr; memset(&my_ip_addr, 0, sizeof(my_ip_addr)); my_ip_addr.sin_family = AF_INET; my_ip_addr.sin_addr.s_addr = htonl(ip_addr); my_ip_addr.sin_port = htons(ip_port); int r; //retval r = bind(s, (struct sockaddr*)(&my_ip_addr), sizeof(my_ip_addr)); if (r < 0) { //system("netstat -an"); cerr << "ERROR: tcp bind: " << LFSTRERROR << endl; closesocket(s); return r; } else { VLOG_INF(VLOG << "Successfully bound to IP: " << toStringIP(ip_addr) << " port: " << ip_port << endl); } nonblock(s, "create tcp socket"); return s; } >> of an environment variable, I'd prefer a cmd-line variable and/or >> something in >> the xorp router config file. However, I know almost nothing about how Xorp >> is written, so if it needs to be an environ variable, that is OK. >> > > Eventually, in the future we should add support for configuring the > Finder's address and port inside the XORP confuguration file, but > such change probably won't be trivial. > > BTW, if you set the environmental variable before starting the XORP > rtrmgr, you need to set that variable as well before starting the > corresponding xorpsh CLI. > So, the environ variable is still needed, in addition to the unicast-forwarding { } sections above? >> I do not need this to support multicast at the moment. >> >> Eventually, I'd like to scale to 100s of VRs, so it would probably be >> more efficient to run a >> smaller number of Xorp processes, each able to handle a lot of routing >> tables, but >> that can be dealt with later. And, it may turn out that running 100+ >> processes >> is not such a big deal considering all of the cores on newer systems... >> > > Probably you will be the first one to try 100s of XORP instances, so > we would be very interested to know how it goes. > > BTW, in Linux you cannot have more than 255 or so forwarding tables, > and some of those tables shouldn't be touched, so ~250 is the > max. number of table IDs and XORP instances you can try. > I worked with someone to get this fixed recently, and have tested 2000+ tables, so this limit no longer exists since kernel 2.6.20 or so. You need the latest 'ip' tool as well... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Thu Aug 9 16:16:39 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 09 Aug 2007 16:16:39 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables. In-Reply-To: Message from Ben Greear of "Thu, 09 Aug 2007 08:50:57 PDT." <46BB37E1.9000903@candelatech.com> Message-ID: <200708092316.l79NGd2O061750@possum.icir.org> Ben Greear wrote: > Pavlin Radoslavov wrote: > >> This sounds like a good first step, and it sounds like it meets my > >> immediate needs. Instead > >> > > > > OK, I just committed to CVS the changes for configuring the table > > ID. You can do it with configuration like: > > > > fea { > > unicast-forwarding4 { > > table-id: 20 > > } > > unicast-forwarding6 { > > table-id: 20 > > } > > } > > > > Obviously, you won't need the unicast-forwarding6 section if you > > don't need IPv6. > > > > I just did some simple testing and it appears to work. > > Please get the latest code from anon. CVS and let us know whether it > > works for you: > > > > http://www.xorp.org/cvs.html > > > Thank you! This was a bit faster than I had hoped, so it may take a day > or two before > we can try it out! I'm going to have to read up on how to configure > Xorp, as I haven't > configured an OSPF router or set of routers before. > > In case you have time & inclination, do you have two simple config files > to make this route with OSPF: > > VR1: table 100, eth0, eth1 > VR2: table 101, eth2, eth3 > > Assume eth1 and eth2 are connected to each other via cross-over cable > and some separate PCs > are connected to eth0 and eth3. The "Getting Started" Web page has quick startup information for configuring XORP. However, it reflects only the latest 1.4 release, so here is a sample config with the table IDs for VR1: interfaces { interface eth0 { vif eth0 { address 10.0.0.1 { prefix-length: 24 } } } interface eth1 { vif eth1 { address 10.1.1.1 { prefix-length: 24 } } } } fea { unicast-forwarding4 { disable: false table-id: 100 } } protocols { ospf4 { router-id: 10.0.0.1 area 0.0.0.0 { interface eth0 { vif eth0 { address 10.0.0.1 { } } } interface eth1 { vif eth1 { address 10.1.1.1 { } } } } } } For VR2 just replace eth0 and eth1 with eth2 and eth3 respectively, change their IP addresses, and set table-id to 101. > In order to make the messages go over the external interfaces, the Xorp > code will probably > need an option to bind to the local IP and device. For TCP sockets that > can do this, my code looks like this (I don't know if this applies to > IPv6 or not..I've only > tried with IPv4.) When we transmit multicast packets (e.g., raw IP packets used by OSPF or UDP used by RIP), we explicitly set the outgoing interface by using setsockopt(IP_MULTICAST_IF). I could be wrong, but for transmitting unicast packets (if we exclude the Linux-specific SO_BINDTODEVICE) I don't think we (can) explicitly specify the outgoing interface. I believe it will be automatically chosen by the kernel (based on the matching forwarding entry toward the destination). Only if the destination is on the same subnet, we could use SO_DONTROUTE socket option or MSG_DONTROUTE flag for send*(); currently we don't which we might need to change. Could you confirm that SO_BINDTODEVICE has impact when choosing the outgoing interface for transmitting packets? The socket(7) Linux manual page describes SO_BINDTODEVICE's impact only for receiving packets, but the manual page itself might be incomplete: If a socket is bound to an interface, only packets received from that particular interface are processed by the socket. > int createTcpSocket(unsigned int ip_addr, int ip_port, const char* > dev_to_bind_to) { > > int s = socket(AF_INET, SOCK_STREAM, 0); > > if (s < 0) { > cerr << "ERROR: tcp socket: " << LFSTRERROR << endl; > return s; > } > > close_exec(s); > > reuseaddr_socket(s); > > if (dev_to_bind_to) { > // Bind to specific device. > #ifndef __WIN32__ > if (setsockopt(s, SOL_SOCKET, SO_BINDTODEVICE, > dev_to_bind_to, DEV_NAME_LEN + 1)) { > VLOG_ERR(VLOG << "ERROR: tcp-connect, setsockopt > (BINDTODEVICE): " > << LFSTRERROR << " Not fatal in most > cases..continuing...\n"); > } > #endif > }//if > > struct sockaddr_in my_ip_addr; > memset(&my_ip_addr, 0, sizeof(my_ip_addr)); > > my_ip_addr.sin_family = AF_INET; > my_ip_addr.sin_addr.s_addr = htonl(ip_addr); > my_ip_addr.sin_port = htons(ip_port); > > int r; //retval > r = bind(s, (struct sockaddr*)(&my_ip_addr), sizeof(my_ip_addr)); > if (r < 0) { > //system("netstat -an"); > cerr << "ERROR: tcp bind: " << LFSTRERROR << endl; > closesocket(s); > return r; > } > else { > VLOG_INF(VLOG << "Successfully bound to IP: " << > toStringIP(ip_addr) << " port: " > << ip_port << endl); > } > > nonblock(s, "create tcp socket"); > return s; > } > > > > >> of an environment variable, I'd prefer a cmd-line variable and/or > >> something in > >> the xorp router config file. However, I know almost nothing about how Xorp > >> is written, so if it needs to be an environ variable, that is OK. > >> > > > > Eventually, in the future we should add support for configuring the > > Finder's address and port inside the XORP confuguration file, but > > such change probably won't be trivial. > > > > BTW, if you set the environmental variable before starting the XORP > > rtrmgr, you need to set that variable as well before starting the > > corresponding xorpsh CLI. > > > So, the environ variable is still needed, in addition to the > unicast-forwarding { } sections above? Yes. The environmental variable is needed so you can run more than one XORP instance on the same machine. > >> I do not need this to support multicast at the moment. > >> > >> Eventually, I'd like to scale to 100s of VRs, so it would probably be > >> more efficient to run a > >> smaller number of Xorp processes, each able to handle a lot of routing > >> tables, but > >> that can be dealt with later. And, it may turn out that running 100+ > >> processes > >> is not such a big deal considering all of the cores on newer systems... > >> > > > > Probably you will be the first one to try 100s of XORP instances, so > > we would be very interested to know how it goes. > > > > BTW, in Linux you cannot have more than 255 or so forwarding tables, > > and some of those tables shouldn't be touched, so ~250 is the > > max. number of table IDs and XORP instances you can try. > > > I worked with someone to get this fixed recently, and have tested 2000+ > tables, > so this limit no longer exists since kernel 2.6.20 or so. You need the > latest 'ip' > tool as well... Thanks for the info. You are right. Originally I was looking inside file "include/linux/rtnetlink.h" I saw that field rtm_table inside "struct rtmsg" is "unsigned char" which explained the 255 limit. After looking into the latest source code for iproute2 I see that the > 255 support is done by using the new RTA_TABLE attribute. For those of you who might be interested in the technical semantics of setting the table ID, it is: If the table ID is <= 0xff, then we set it in rtmsg->rtm_table, otherwise we set rtmsg->rtm_table to RT_TABLE_UNSPEC and add the real value as an RTA_TABLE attribute. Anyway, I fixed the XORP code and now it supports table ID larger than 255. Thanks, Pavlin From greearb at candelatech.com Thu Aug 9 16:33:03 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 09 Aug 2007 16:33:03 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables. In-Reply-To: <200708092316.l79NGd2O061750@possum.icir.org> References: <200708092316.l79NGd2O061750@possum.icir.org> Message-ID: <46BBA42F.5080904@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > The "Getting Started" Web page has quick startup information for > configuring XORP. However, it reflects only the latest 1.4 release, > so here is a sample config with the table IDs for VR1: [snip] > For VR2 just replace eth0 and eth1 with eth2 and eth3 respectively, > change their IP addresses, and set table-id to 101. Thanks for this, it should significantly speed up my testing! >> In order to make the messages go over the external interfaces, the Xorp >> code will probably >> need an option to bind to the local IP and device. For TCP sockets that >> can do this, my code looks like this (I don't know if this applies to >> IPv6 or not..I've only >> tried with IPv4.) > > When we transmit multicast packets (e.g., raw IP packets used by > OSPF or UDP used by RIP), we explicitly set the outgoing interface > by using setsockopt(IP_MULTICAST_IF). > > I could be wrong, but for transmitting unicast packets (if we > exclude the Linux-specific SO_BINDTODEVICE) I don't think we (can) > explicitly specify the outgoing interface. I believe it will be > automatically chosen by the kernel (based on the matching forwarding > entry toward the destination). Only if the destination is on the same > subnet, we could use SO_DONTROUTE socket option or MSG_DONTROUTE > flag for send*(); currently we don't which we might need to change. > > Could you confirm that SO_BINDTODEVICE has impact when choosing the > outgoing interface for transmitting packets? > The socket(7) Linux manual page describes SO_BINDTODEVICE's impact > only for receiving packets, but the manual page itself might be > incomplete: SO_BINDTODEVICE does bind to the out-going interface as well. Please note that I also bind the local IP address (which matches the interface). I then configure the routing tables with rules so that pkts from a particular IP use a particular routing table. I *think* that you could skip the SO_BINDTODEVICE and just bind to the local IP, as long as you have rules set up similar to mine. But, by also binding with SO_BINDTODEVICE I think it will work in slightly more cases where the routing tables may be configured differently. I'm sure you'll want to be able to bind the socket to a local IP, but if you want to leave out the SO_BINDTODEVICE I can test it and see if it works. I can add the SO_BINDTODEVICE if needed and send you a patch. No need to mess with MSG_DONTROUTE. In case it helps, here is a snippet of 'ip ru show' on a test system: 400: from 10.1.0.2 lookup 9 400: from 2.2.2.3 lookup 19 400: from 2.2.2.2 lookup 23 foo# ip route show table 9 10.1.0.0/24 via 10.1.0.2 dev rddVR4 default via 10.1.0.1 dev rddVR4 >> So, the environ variable is still needed, in addition to the >> unicast-forwarding { } sections above? > > Yes. The environmental variable is needed so you can run more than > one XORP instance on the same machine. Ok, that's not a problem. > Anyway, I fixed the XORP code and now it supports table ID larger > than 255. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Thu Aug 9 17:56:09 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 09 Aug 2007 17:56:09 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables. In-Reply-To: Message from Ben Greear of "Thu, 09 Aug 2007 16:33:03 PDT." <46BBA42F.5080904@candelatech.com> Message-ID: <200708100056.l7A0u9Xc074576@possum.icir.org> > > I could be wrong, but for transmitting unicast packets (if we > > exclude the Linux-specific SO_BINDTODEVICE) I don't think we (can) > > explicitly specify the outgoing interface. I believe it will be > > automatically chosen by the kernel (based on the matching forwarding > > entry toward the destination). Only if the destination is on the same > > subnet, we could use SO_DONTROUTE socket option or MSG_DONTROUTE > > flag for send*(); currently we don't which we might need to change. > > > > Could you confirm that SO_BINDTODEVICE has impact when choosing the > > outgoing interface for transmitting packets? > > The socket(7) Linux manual page describes SO_BINDTODEVICE's impact > > only for receiving packets, but the manual page itself might be > > incomplete: > > SO_BINDTODEVICE does bind to the out-going interface as well. Please > note that I also bind the local IP address (which matches the interface). > I then configure the routing tables with rules so that pkts from a > particular IP use a particular routing table. I *think* that you could > skip the SO_BINDTODEVICE and just bind to the local IP, as long as you have > rules set up similar to mine. But, by also binding with SO_BINDTODEVICE I > think it will work in slightly more cases where the routing tables may > be configured differently. Thank you for the info. Yes, I like the semantics of SO_BINDTODEVICE, because it simplifies various things, but unfortunately it is available only on Linux. This doesn't mean that we are definitely opposing using it, it is just that I wish there is a similar solution for other OS-es as well so we get reasonably consistent behavior. Question to Bruce: is there a similar equivalent in BSD and Windows userland? > I'm sure you'll want to be able to bind the socket to a local IP, but > if you want to leave out the SO_BINDTODEVICE I can test it and see > if it works. I can add the SO_BINDTODEVICE if needed and send you a patch. Currently, we don't bind to the local IP (we do but in certain cases only). I believe even if you bind to a local IP you cannot really force the unicast IP packet to exit the system on the particular interface. Anyway, I might be wrong here, so please let me know if you find that bind()-ing only gives us the desired behavior. BTW, what protocols are you planning to run? Without SO_BINDTODEVICE we might have to use different solution for each type of sockets/packets: raw IP packets, TCP, UDP. FYI, the I/O system-specific stuff is inside fea/data_plane/io, though io_tcpudp_socket.cc itself uses the xorp/libcomm wrapper library. BGP only doesn't use the FEA (yet) and does its own TCP connection (inside bgp/socket.{hh,cc}). Also, there could be some gotchas with RIP's UDP socket, but lets address first the protocols you are actually going to use. > No need to mess with MSG_DONTROUTE. > > In case it helps, here is a snippet of 'ip ru show' on a test system: > > 400: from 10.1.0.2 lookup 9 > 400: from 2.2.2.3 lookup 19 > 400: from 2.2.2.2 lookup 23 > > foo# ip route show table 9 > 10.1.0.0/24 via 10.1.0.2 dev rddVR4 > default via 10.1.0.1 dev rddVR4 OK, that's useful to know. Thanks, Pavlin From greearb at candelatech.com Thu Aug 9 18:17:25 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 09 Aug 2007 18:17:25 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables. In-Reply-To: <200708100056.l7A0u9Xc074576@possum.icir.org> References: <200708100056.l7A0u9Xc074576@possum.icir.org> Message-ID: <46BBBCA5.308@candelatech.com> Pavlin Radoslavov wrote: > Thank you for the info. > Yes, I like the semantics of SO_BINDTODEVICE, because it simplifies > various things, but unfortunately it is available only on Linux. > This doesn't mean that we are definitely opposing using it, it is > just that I wish there is a similar solution for other OS-es as > well so we get reasonably consistent behavior. > > Question to Bruce: is there a similar equivalent in BSD and Windows > userland? > I'd be interested to learn if this is supported on other OSs as well. I briefly looked for something similar on Windows but didn't find anything useful... >> I'm sure you'll want to be able to bind the socket to a local IP, but >> if you want to leave out the SO_BINDTODEVICE I can test it and see >> if it works. I can add the SO_BINDTODEVICE if needed and send you a patch. >> > > Currently, we don't bind to the local IP (we do but in certain cases > only). I believe even if you bind to a local IP you cannot really > force the unicast IP packet to exit the system on the particular > interface. Anyway, I might be wrong here, so please let me know if > you find that bind()-ing only gives us the desired behavior. > If you set up the routing tables and rules correctly, then binding to a local IP is probably sufficient. If you are certain that you want the pkt to leave by a certain interface, then I don't think it can ever hurt to bind to that local IP, but just in case, it could also be a config option... > BTW, what protocols are you planning to run? Without SO_BINDTODEVICE > we might have to use different solution for each type of > sockets/packets: raw IP packets, TCP, UDP. > FYI, the I/O system-specific stuff is inside fea/data_plane/io, > though io_tcpudp_socket.cc itself uses the xorp/libcomm wrapper > library. > BGP only doesn't use the FEA (yet) and does its own TCP connection > (inside bgp/socket.{hh,cc}). > > Also, there could be some gotchas with RIP's UDP socket, but lets > address first the protocols you are actually going to use. > At a minimum, I want to support OSPF. However, I'd like to have options to do other protocols as well. In my own experience, binding UDP is very similar to binding TCP, but if you want some sample code I can post it. I'm not sure about raw IP packets. Also, for my application, it will always be running on Linux, so I can depend on SO_BINDTODEVICE being available... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From sanchezmk at yahoo.com Thu Aug 9 18:51:30 2007 From: sanchezmk at yahoo.com (Sanchez) Date: Thu, 9 Aug 2007 18:51:30 -0700 (PDT) Subject: [Xorp-users] Simple multicast configuration Message-ID: <174890.6899.qm@web30413.mail.mud.yahoo.com> I've been trying for a couple of days to configure a very simple multicast configuration: WinXP Pro #1 160.254.1.10 | | | 169.254.1.2 LiveCD 1.4 169.254.2.1 | | | 160.254.2.20 WinXP Pro #2 All 3 machines run as virtual machines in VMWare. The result is that unicast works perfectly fine, but no way for multicast, neither asmping nor VLC can reach from one to the other computer. I'm totally at loss, don't know what else to try, any help will be very appreciated. The xorp.cfg file is: /*XORP Configuration File, v1.0*/ protocols { fib2mrib { disable: false } igmp { disable: false interface lnc0 { vif lnc0 { 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 lnc1 { vif lnc1 { 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 } } } pimsm4 { disable: false interface lnc0 { vif lnc0 { disable: false enable-ip-router-alert-option-check: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } interface lnc1 { vif lnc1 { disable: false enable-ip-router-alert-option-check: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } interface "register_vif" { vif "register_vif" { disable: false enable-ip-router-alert-option-check: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } static-rps { rp 169.254.2.1 { group-prefix 224.0.0.0/4 { rp-priority: 192 hash-mask-len: 30 } } } switch-to-spt-threshold { disable: false interval: 100 bytes: 102400 } } } fea { unicast-forwarding4 { disable: false } } interfaces { restore-original-config-on-shutdown: false interface lnc0 { disable: false discard: false description: "Lan0" vif lnc0 { disable: false address 169.254.1.2 { prefix-length: 24 broadcast: 169.254.1.255 disable: false } } } interface lnc1 { disable: false discard: false description: "Lan1" vif lnc1 { disable: false address 169.254.2.1 { prefix-length: 24 broadcast: 169.254.2.255 disable: false } } } interface lo0 { disable: false discard: false description: "Loopback interface" vif lo0 { disable: false } } } plumbing { mfea4 { disable: false interface lnc0 { vif lnc0 { disable: false } } interface "register_vif" { vif "register_vif" { disable: false } } interface lnc1 { vif lnc1 { disable: false } } } } --------------------------------- Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070809/39bd4b17/attachment-0001.html From pavlin at icir.org Fri Aug 10 00:25:11 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 10 Aug 2007 00:25:11 -0700 Subject: [Xorp-users] Simple multicast configuration In-Reply-To: Message from Sanchez of "Thu, 09 Aug 2007 18:51:30 PDT." <174890.6899.qm@web30413.mail.mud.yahoo.com> Message-ID: <200708100725.l7A7PBFg079389@possum.icir.org> Sanchez wrote: > I've been trying for a couple of days to configure a very simple multicast configuration: > > WinXP Pro #1 > 160.254.1.10 > | > | > | > 169.254.1.2 > LiveCD 1.4 > 169.254.2.1 > | > | > | > 160.254.2.20 > WinXP Pro #2 Is the first octet of the WinXP addresses really 160 or is this a typo? The first octet must be 169, because the hosts must belong to the same subnet as the router. If this is a typo, and the first octet is indeed 169, then first check whether IGMP sees the receiver(s). Start the receiver on one of the WinXP machines, and use the following xorpsh command: show igmp group If you can see the receiver, then start the sender on the other WinXP machine and check whether PIM-SM sees both the sender and the receiver: show pim join Please send the output of the above two commands, and based on that result we can debug the problem further. Regards, Pavlin P.S. What XORP configuration did you use for the unicast test? If WinXP has the traceroute equivalent, please use it to double-check that the unicast routing indeed goes via XORP. P.P.S. Your multicast configuration below seems fine. > > All 3 machines run as virtual machines in VMWare. The result is that unicast works perfectly fine, but no way for multicast, neither asmping nor VLC can reach from one to the other computer. > I'm totally at loss, don't know what else to try, any help will be very appreciated. The xorp.cfg file is: > > /*XORP Configuration File, v1.0*/ > protocols { > fib2mrib { > disable: false > } > igmp { > disable: false > interface lnc0 { > vif lnc0 { > 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 lnc1 { > vif lnc1 { > 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 > } > } > } > pimsm4 { > disable: false > interface lnc0 { > vif lnc0 { > disable: false > enable-ip-router-alert-option-check: false > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > interface lnc1 { > vif lnc1 { > disable: false > enable-ip-router-alert-option-check: false > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > interface "register_vif" { > vif "register_vif" { > disable: false > enable-ip-router-alert-option-check: false > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > static-rps { > rp 169.254.2.1 { > group-prefix 224.0.0.0/4 { > rp-priority: 192 > hash-mask-len: 30 > } > } > } > switch-to-spt-threshold { > disable: false > interval: 100 > bytes: 102400 > } > } > } > fea { > unicast-forwarding4 { > disable: false > } > } > interfaces { > restore-original-config-on-shutdown: false > interface lnc0 { > disable: false > discard: false > description: "Lan0" > vif lnc0 { > disable: false > address 169.254.1.2 { > prefix-length: 24 > broadcast: 169.254.1.255 > disable: false > } > } > } > interface lnc1 { > disable: false > discard: false > description: "Lan1" > vif lnc1 { > disable: false > address 169.254.2.1 { > prefix-length: 24 > broadcast: 169.254.2.255 > disable: false > } > } > } > interface lo0 { > disable: false > discard: false > description: "Loopback interface" > vif lo0 { > disable: false > } > } > } > plumbing { > mfea4 { > disable: false > interface lnc0 { > vif lnc0 { > disable: false > } > } > interface "register_vif" { > vif "register_vif" { > disable: false > } > } > interface lnc1 { > vif lnc1 { > disable: false > } > } > } > } > > > > > --------------------------------- > Luggage? GPS? Comic books? > Check out fitting gifts for grads at Yahoo! Search._______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From sanchezmk at yahoo.com Fri Aug 10 14:41:20 2007 From: sanchezmk at yahoo.com (Sanchez) Date: Fri, 10 Aug 2007 14:41:20 -0700 (PDT) Subject: [Xorp-users] Simple multicast configuration In-Reply-To: <200708100725.l7A7PBFg079389@possum.icir.org> Message-ID: <300536.56888.qm@web30410.mail.mud.yahoo.com> Thank you for replying sir. The 160 was a typo indeed, on the system it's correctly configured as 169. So we have: On WinXP #1 I run: C:\ssmping\ssmpingd On WinXP #2 I run C:\ssmping\asmping 224.1.1.1 169.254.2.20 and it starts to recive back in WinXP#2 only the unicast responses from WinXP#1, but not the multicast responses. Using Ethereal it can be seen that Windows does put the multicast traffic from the sending computer on the ethernet cable, and IGMP requests to join group on the receiving computer's cable. Meanwhile on LiveCD 1.4 we have: xorp at LiveCD> show igmp group Interface Group Source LastReported Timeout V State lnc0 224.0.0.2 0.0.0.0 169.254.1.2 222 2 E lnc0 224.0.0.13 0.0.0.0 169.254.1.2 220 2 E lnc0 224.0.0.22 0.0.0.0 169.254.1.2 222 2 E lnc1 224.0.0.2 0.0.0.0 169.254.2.1 216 2 E lnc1 224.0.0.13 0.0.0.0 169.254.2.1 216 2 E lnc1 224.0.0.22 0.0.0.0 169.254.2.1 220 2 E xorp at LiveCD> show pim join Group Source RP Flags xorp at LiveCD> Running tracert and pathping on one of the windows machines results: C:\ssmping>tracert 169.254.2.20 Tracing route to 169.254.2.20 over a maximum of 30 hops 1 230 ms 10 ms <1 ms 169.254.1.2 2 129 ms 1 ms 1 ms 169.254.2.20 Trace complete. C:\ssmping>pathping 169.254.2.20 Tracing route to 169.254.2.20 over a maximum of 30 hops 0 169.254.1.10 1 169.254.1.2 2 169.254.2.20 Computing statistics for 50 seconds... Source to Here This Node/Link Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address 0 169.254.1.10 0/ 100 = 0% | 1 2ms 0/ 100 = 0% 0/ 100 = 0% 169.254.1.2 0/ 100 = 0% | 2 2ms 0/ 100 = 0% 0/ 100 = 0% 169.254.2.20 Trace complete. C:\ssmping> Pavlin Radoslavov wrote: Sanchez wrote: > I've been trying for a couple of days to configure a very simple multicast configuration: > > WinXP Pro #1 > 160.254.1.10 > | > | > | > 169.254.1.2 > LiveCD 1.4 > 169.254.2.1 > | > | > | > 160.254.2.20 > WinXP Pro #2 Is the first octet of the WinXP addresses really 160 or is this a typo? The first octet must be 169, because the hosts must belong to the same subnet as the router. If this is a typo, and the first octet is indeed 169, then first check whether IGMP sees the receiver(s). Start the receiver on one of the WinXP machines, and use the following xorpsh command: show igmp group If you can see the receiver, then start the sender on the other WinXP machine and check whether PIM-SM sees both the sender and the receiver: show pim join Please send the output of the above two commands, and based on that result we can debug the problem further. Regards, Pavlin P.S. What XORP configuration did you use for the unicast test? If WinXP has the traceroute equivalent, please use it to double-check that the unicast routing indeed goes via XORP. P.P.S. Your multicast configuration below seems fine. > > All 3 machines run as virtual machines in VMWare. The result is that unicast works perfectly fine, but no way for multicast, neither asmping nor VLC can reach from one to the other computer. > I'm totally at loss, don't know what else to try, any help will be very appreciated. The xorp.cfg file is: > > /*XORP Configuration File, v1.0*/ > protocols { > fib2mrib { > disable: false > } > igmp { > disable: false > interface lnc0 { > vif lnc0 { > 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 lnc1 { > vif lnc1 { > 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 > } > } > } > pimsm4 { > disable: false > interface lnc0 { > vif lnc0 { > disable: false > enable-ip-router-alert-option-check: false > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > interface lnc1 { > vif lnc1 { > disable: false > enable-ip-router-alert-option-check: false > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > interface "register_vif" { > vif "register_vif" { > disable: false > enable-ip-router-alert-option-check: false > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > static-rps { > rp 169.254.2.1 { > group-prefix 224.0.0.0/4 { > rp-priority: 192 > hash-mask-len: 30 > } > } > } > switch-to-spt-threshold { > disable: false > interval: 100 > bytes: 102400 > } > } > } > fea { > unicast-forwarding4 { > disable: false > } > } > interfaces { > restore-original-config-on-shutdown: false > interface lnc0 { > disable: false > discard: false > description: "Lan0" > vif lnc0 { > disable: false > address 169.254.1.2 { > prefix-length: 24 > broadcast: 169.254.1.255 > disable: false > } > } > } > interface lnc1 { > disable: false > discard: false > description: "Lan1" > vif lnc1 { > disable: false > address 169.254.2.1 { > prefix-length: 24 > broadcast: 169.254.2.255 > disable: false > } > } > } > interface lo0 { > disable: false > discard: false > description: "Loopback interface" > vif lo0 { > disable: false > } > } > } > plumbing { > mfea4 { > disable: false > interface lnc0 { > vif lnc0 { > disable: false > } > } > interface "register_vif" { > vif "register_vif" { > disable: false > } > } > interface lnc1 { > vif lnc1 { > disable: false > } > } > } > } > > > > > --------------------------------- > Luggage? GPS? Comic books? > Check out fitting gifts for grads at Yahoo! Search._______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users --------------------------------- Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070810/6582df1e/attachment.html From pavlin at icir.org Fri Aug 10 15:19:14 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 10 Aug 2007 15:19:14 -0700 Subject: [Xorp-users] Simple multicast configuration In-Reply-To: Message from Sanchez of "Fri, 10 Aug 2007 14:41:20 PDT." <300536.56888.qm@web30410.mail.mud.yahoo.com> Message-ID: <200708102219.l7AMJEvo002250@possum.icir.org> > On WinXP #1 I run: > C:\ssmping\ssmpingd > > On WinXP #2 I run > C:\ssmping\asmping 224.1.1.1 169.254.2.20 > > and it starts to recive back in WinXP#2 only the unicast responses from WinXP#1, but not the multicast responses. > Using Ethereal it can be seen that Windows does put the multicast traffic from the sending computer on the ethernet cable, and IGMP requests to join group on the receiving computer's cable. > Meanwhile on LiveCD 1.4 we have: > > xorp at LiveCD> show igmp group > Interface Group Source LastReported Timeout V State > lnc0 224.0.0.2 0.0.0.0 169.254.1.2 222 2 E > lnc0 224.0.0.13 0.0.0.0 169.254.1.2 220 2 E > lnc0 224.0.0.22 0.0.0.0 169.254.1.2 222 2 E > lnc1 224.0.0.2 0.0.0.0 169.254.2.1 216 2 E > lnc1 224.0.0.13 0.0.0.0 169.254.2.1 216 2 E > lnc1 224.0.0.22 0.0.0.0 169.254.2.1 220 2 E > xorp at LiveCD> show pim join > Group Source RP Flags > xorp at LiveCD> Thank you for the info. It appears that XORP doesn't see any IGMP reports from the WinXP hosts, because the "show igmp group" doesn't show anything about multicast membership from the WinXP hosts. Also, the multicast traffic from the sender probably didn't reach XORP, otherwise "show pim join" should show (S,G) entry for the directly-connected senders. Which machine did you use to run Ethereal? The Windows machine or the XORP box? If you used the Windows machine, please run "tcpdump" on the XORP box to make sure that the multicast packets (IGMP Joins and multicast data packets) really reach it. FYI, in case you are not familiar with tcpdump, you could use the following command to print everything on interface lnc0: /usr/sbin/tcpdump -i lnc0 -n -vvv -s 0 -x See the tcpdump(1) manual page for details in case you need to filter and print only some of the packets. Regards, Pavlin From sanchezmk at yahoo.com Fri Aug 10 19:35:50 2007 From: sanchezmk at yahoo.com (Sanchez) Date: Fri, 10 Aug 2007 19:35:50 -0700 (PDT) Subject: [Xorp-users] Simple multicast configuration In-Reply-To: <200708102219.l7AMJEvo002250@possum.icir.org> Message-ID: <109170.47377.qm@web30414.mail.mud.yahoo.com> How do I run tcpdump on LiveCD? It only allows me a few commands: configure exit help ping ping6 quit show traceroute traceroute6 I also stopped it before it loaded where it says "Hit [Enter] to boot immediately, or any other key for command prompt". Here it also allows me only a few commands: reboot heap bcachestat .... ... lsmod pnpscan I see the "ls" command is included, but not the "cd" command, so I can't even navigate to the "usr/sbin..." directory. Btw I'm not very proficient with freebsd, am I missing anything? Pavlin Radoslavov wrote: > On WinXP #1 I run: > C:\ssmping\ssmpingd > > On WinXP #2 I run > C:\ssmping\asmping 224.1.1.1 169.254.2.20 > > and it starts to recive back in WinXP#2 only the unicast responses from WinXP#1, but not the multicast responses. > Using Ethereal it can be seen that Windows does put the multicast traffic from the sending computer on the ethernet cable, and IGMP requests to join group on the receiving computer's cable. > Meanwhile on LiveCD 1.4 we have: > > xorp at LiveCD> show igmp group > Interface Group Source LastReported Timeout V State > lnc0 224.0.0.2 0.0.0.0 169.254.1.2 222 2 E > lnc0 224.0.0.13 0.0.0.0 169.254.1.2 220 2 E > lnc0 224.0.0.22 0.0.0.0 169.254.1.2 222 2 E > lnc1 224.0.0.2 0.0.0.0 169.254.2.1 216 2 E > lnc1 224.0.0.13 0.0.0.0 169.254.2.1 216 2 E > lnc1 224.0.0.22 0.0.0.0 169.254.2.1 220 2 E > xorp at LiveCD> show pim join > Group Source RP Flags > xorp at LiveCD> Thank you for the info. It appears that XORP doesn't see any IGMP reports from the WinXP hosts, because the "show igmp group" doesn't show anything about multicast membership from the WinXP hosts. Also, the multicast traffic from the sender probably didn't reach XORP, otherwise "show pim join" should show (S,G) entry for the directly-connected senders. Which machine did you use to run Ethereal? The Windows machine or the XORP box? If you used the Windows machine, please run "tcpdump" on the XORP box to make sure that the multicast packets (IGMP Joins and multicast data packets) really reach it. FYI, in case you are not familiar with tcpdump, you could use the following command to print everything on interface lnc0: /usr/sbin/tcpdump -i lnc0 -n -vvv -s 0 -x See the tcpdump(1) manual page for details in case you need to filter and print only some of the packets. Regards, Pavlin --------------------------------- Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070810/af36e07f/attachment-0001.html From pavlin at icir.org Fri Aug 10 22:00:48 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 10 Aug 2007 22:00:48 -0700 Subject: [Xorp-users] Simple multicast configuration In-Reply-To: Message from Sanchez of "Fri, 10 Aug 2007 19:35:50 PDT." <109170.47377.qm@web30414.mail.mud.yahoo.com> Message-ID: <200708110500.l7B50mvt018258@possum.icir.org> Sanchez wrote: > How do I run tcpdump on LiveCD? It only allows me a few commands: > > configure > exit > help > ping > ping6 > quit > show > traceroute > traceroute6 Those are the xorpsh commands which you get when you login as "xorp". You need to login as user "root" and run tcpdump from the UNIX shell instead of xorpsh. The root password will be the one you entered when started the LiveCD. You could do so by switching to another terminal by pressing Alt-F2, Alt-F3, Alt-F4 and so on (and Alt-F1 to go back to the first terminal). > I also stopped it before it loaded where it says > "Hit [Enter] to boot immediately, or any other key for command prompt". > Here it also allows me only a few commands: > > reboot > heap > bcachestat > .... > ... > lsmod > pnpscan > > I see the "ls" command is included, but not the "cd" command, so I can't even navigate to the "usr/sbin..." directory. Btw I'm not very proficient with freebsd, am I missing anything? Those are the commands you can run before the FreeBSD kernel has booted. You need to boot and configure XORP as usual. After that Alt-F2 to switch to another terminal and login as "root". Regards, Pavlin > > Pavlin Radoslavov wrote: > On WinXP #1 I run: > > C:\ssmping\ssmpingd > > > > On WinXP #2 I run > > C:\ssmping\asmping 224.1.1.1 169.254.2.20 > > > > and it starts to recive back in WinXP#2 only the unicast responses from WinXP#1, but not the multicast responses. > > Using Ethereal it can be seen that Windows does put the multicast traffic from the sending computer on the ethernet cable, and IGMP requests to join group on the receiving computer's cable. > > Meanwhile on LiveCD 1.4 we have: > > > > xorp at LiveCD> show igmp group > > Interface Group Source LastReported Timeout V State > > lnc0 224.0.0.2 0.0.0.0 169.254.1.2 222 2 E > > lnc0 224.0.0.13 0.0.0.0 169.254.1.2 220 2 E > > lnc0 224.0.0.22 0.0.0.0 169.254.1.2 222 2 E > > lnc1 224.0.0.2 0.0.0.0 169.254.2.1 216 2 E > > lnc1 224.0.0.13 0.0.0.0 169.254.2.1 216 2 E > > lnc1 224.0.0.22 0.0.0.0 169.254.2.1 220 2 E > > xorp at LiveCD> show pim join > > Group Source RP Flags > > xorp at LiveCD> > > Thank you for the info. > It appears that XORP doesn't see any IGMP reports from the WinXP > hosts, because the "show igmp group" doesn't show anything about > multicast membership from the WinXP hosts. > Also, the multicast traffic from the sender probably didn't > reach XORP, otherwise "show pim join" should show (S,G) entry for > the directly-connected senders. > > Which machine did you use to run Ethereal? The Windows machine or > the XORP box? > If you used the Windows machine, please run "tcpdump" on the XORP > box to make sure that the multicast packets (IGMP Joins and > multicast data packets) really reach it. > > FYI, in case you are not familiar with tcpdump, you could use the > following command to print everything on interface lnc0: > > /usr/sbin/tcpdump -i lnc0 -n -vvv -s 0 -x > > See the tcpdump(1) manual page for details in case you need to > filter and print only some of the packets. > > Regards, > Pavlin > > > > > > --------------------------------- > Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase._______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From sanchezmk at yahoo.com Sat Aug 11 07:38:08 2007 From: sanchezmk at yahoo.com (Sanchez) Date: Sat, 11 Aug 2007 07:38:08 -0700 (PDT) Subject: [Xorp-users] Simple multicast configuration In-Reply-To: <200708110500.l7B50mvt018258@possum.icir.org> Message-ID: <895202.61055.qm@web30403.mail.mud.yahoo.com> Hurrayyyyyy, it works. Just merely running tcpdump on both interfaces on the xorp box makes it work, without tcpdump it doesn't work, I have no idea why, but it's sufficient for me to continue on my project. Thanks for all the help so far, I hope you can fix this in the next releases, or if you can't reproduce the bug I can send you my virtual machine files if you need them. Thanks again. Pavlin Radoslavov wrote: Sanchez wrote: > How do I run tcpdump on LiveCD? It only allows me a few commands: > > configure > exit > help > ping > ping6 > quit > show > traceroute > traceroute6 Those are the xorpsh commands which you get when you login as "xorp". You need to login as user "root" and run tcpdump from the UNIX shell instead of xorpsh. The root password will be the one you entered when started the LiveCD. You could do so by switching to another terminal by pressing Alt-F2, Alt-F3, Alt-F4 and so on (and Alt-F1 to go back to the first terminal). > I also stopped it before it loaded where it says > "Hit [Enter] to boot immediately, or any other key for command prompt". > Here it also allows me only a few commands: > > reboot > heap > bcachestat > .... > ... > lsmod > pnpscan > > I see the "ls" command is included, but not the "cd" command, so I can't even navigate to the "usr/sbin..." directory. Btw I'm not very proficient with freebsd, am I missing anything? Those are the commands you can run before the FreeBSD kernel has booted. You need to boot and configure XORP as usual. After that Alt-F2 to switch to another terminal and login as "root". Regards, Pavlin > > Pavlin Radoslavov wrote: > On WinXP #1 I run: > > C:\ssmping\ssmpingd > > > > On WinXP #2 I run > > C:\ssmping\asmping 224.1.1.1 169.254.2.20 > > > > and it starts to recive back in WinXP#2 only the unicast responses from WinXP#1, but not the multicast responses. > > Using Ethereal it can be seen that Windows does put the multicast traffic from the sending computer on the ethernet cable, and IGMP requests to join group on the receiving computer's cable. > > Meanwhile on LiveCD 1.4 we have: > > > > xorp at LiveCD> show igmp group > > Interface Group Source LastReported Timeout V State > > lnc0 224.0.0.2 0.0.0.0 169.254.1.2 222 2 E > > lnc0 224.0.0.13 0.0.0.0 169.254.1.2 220 2 E > > lnc0 224.0.0.22 0.0.0.0 169.254.1.2 222 2 E > > lnc1 224.0.0.2 0.0.0.0 169.254.2.1 216 2 E > > lnc1 224.0.0.13 0.0.0.0 169.254.2.1 216 2 E > > lnc1 224.0.0.22 0.0.0.0 169.254.2.1 220 2 E > > xorp at LiveCD> show pim join > > Group Source RP Flags > > xorp at LiveCD> > > Thank you for the info. > It appears that XORP doesn't see any IGMP reports from the WinXP > hosts, because the "show igmp group" doesn't show anything about > multicast membership from the WinXP hosts. > Also, the multicast traffic from the sender probably didn't > reach XORP, otherwise "show pim join" should show (S,G) entry for > the directly-connected senders. > > Which machine did you use to run Ethereal? The Windows machine or > the XORP box? > If you used the Windows machine, please run "tcpdump" on the XORP > box to make sure that the multicast packets (IGMP Joins and > multicast data packets) really reach it. > > FYI, in case you are not familiar with tcpdump, you could use the > following command to print everything on interface lnc0: > > /usr/sbin/tcpdump -i lnc0 -n -vvv -s 0 -x > > See the tcpdump(1) manual page for details in case you need to > filter and print only some of the packets. > > Regards, > Pavlin > > > > > > --------------------------------- > Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase._______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users --------------------------------- Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070811/8a517df0/attachment.html From pavlin at icir.org Sun Aug 12 10:47:00 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sun, 12 Aug 2007 10:47:00 -0700 Subject: [Xorp-users] Simple multicast configuration In-Reply-To: Message from Sanchez of "Sat, 11 Aug 2007 07:38:08 PDT." <895202.61055.qm@web30403.mail.mud.yahoo.com> Message-ID: <200708121747.l7CHl0GP032271@possum.icir.org> Sanchez wrote: > Hurrayyyyyy, it works. Just merely running tcpdump on both > interfaces on the xorp box makes it work, without tcpdump it > doesn't work, I have no idea why, but it's sufficient for me > to continue on my project. > Thanks for all the help so far, I hope you can fix this in the > next releases, or if you can't reproduce the bug I can send > you my virtual machine files if you need them. Thanks again. I guess the problem is in the FreeBSD driver for the (virtual) network interface. If a multicast router is started on an interface, the interface is suppose to be in ALLMULTI mode: it should snoop all multicast packets and pass them to the kernel for further processing. If the driver/interface has problem with snooping all multicast packets, then the kernel and XORP won't receive them. Running tcpdump puts an interface in PROMISC mode, where all packets are snooped. Eventually, running an interface in PROMISC mode helps with snooping the multicast packets as well. If you run "ifconfig -a" before running XORP and/or tcpdump you should see the ALLMULTI and PROMISC flags being set/reset. FYI, the current LiveCD is based on FreeBSD-4.10 which is quite old. For the next XORP release we are planning to use the most recent FreeBSD release (6.2) for the LiveCD. Hopefully the ALLMULTI driver problem is fixed in that FreeBSD release. Regards, Pavlin From c.d.chapman at reading.ac.uk Fri Aug 17 01:26:11 2007 From: c.d.chapman at reading.ac.uk (Christopher David Chapman) Date: Fri, 17 Aug 2007 09:26:11 +0100 Subject: [Xorp-users] Problems verifying compalation In-Reply-To: <200708021650.l72GofI4023617@possum.icir.org> References: Message from "Christopher David Chapman" of "Thu, 02 Aug 2007 11:10:07 BST." <8316105576AA84449272440E676F1314016EE91F@vime1.rdg-home.ad.rdg.ac.uk> <200708021650.l72GofI4023617@possum.icir.org> Message-ID: <8316105576AA84449272440E676F1314017EE015@vime1.rdg-home.ad.rdg.ac.uk> First my deep thanks to Pavlin for all his support. Pavlin has been working with me to resolve this off-list and I thought I should sum up how we sorted it. It turns out that the problem was caused by the SSP protection of the Gentoo hardened toolchain causing run-time problems. To resolve the issue I used gcc-config to switch the gcc profile to "hardenednossp" and recompiled xorp. I then got some errors while running xorp_rtrmgr: [ 2007/08/15 17:35:56 INFO xorp_rtrmgr:6773 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, pimsm4 [ 2007/08/15 17:35:56 INFO xorp_rtrmgr:6773 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2007/08/15 17:35:56 ERROR xorp_fea:6774 LIBCOMM +114 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol [ 2007/08/15 17:35:56 ERROR xorp_fea:6774 LIBCOMM +114 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol This was because I have disabled IPV6 in the kernel and was fixed by recompiling xorp after re-running the configuration with the "--disable-ipv6" switch. Cheers Chris "Why is Gaffa tape like the force? Because it has a light side, a dark side, and it holds the universe together!" ----------------===========---------------- Christopher Chapman Systems Programmer ITNG School of Systems Engineering The University of Reading E-mail: c.d.chapman at reading.ac.uk Phone:? +44 (0)118 3787664 School of Systems Engineering The University of Reading PO Box 225 Whiteknights Reading RG6 6AY ----------------===========---------------- -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin at icir.org] Sent: 02 August 2007 17:51 To: Christopher David Chapman Cc: xorp-users at xorp.org Subject: Re: [Xorp-users] Problems verifying compalation Christopher David Chapman wrote: > Hi Folks, > > I am trying to get xorp running under gentoo. I compiled the code without any errors but running the verification errors while testing test_vif. A check on google didn't turn up any hits, Has anybody else seen this? Or got it working under gentoo? > > Error as follows: > > --------------- > PASS > PASS: test_trie > PASS: test_types > PASS: test_utils > /bin/sh: line 4: 7241 Segmentation fault ${dir}$tst > FAIL: test_vif > ==================== > 2 of 27 tests failed > ==================== > make[2]: *** [check-TESTS] Error 1 > make[2]: Leaving directory `/usr/src/xorp-1.4/libxorp' > make[1]: *** [check-am] Error 2 > make[1]: Leaving directory `/usr/src/xorp-1.4/libxorp' > make: *** [check-recursive] Error 1 What Gentoo version and what compiler are you using? We have Gentoo 2006.1 with gcc-4.1.1 and we don't see that problem. Can you run gdb on the coredump file and trace where it failed: gdb test_vif -c bt Thanks, Pavlin > Cheers > Chris > > > "Why is Gaffa tape like the force? > Because it has a light side, a dark side, and it holds the universe together!" > > ----------------===========---------------- > Christopher Chapman > Systems Programmer ITNG > School of Systems Engineering > The University of Reading > > E-mail: c.d.chapman at reading.ac.uk > Phone:? +44 (0)118 3787664 > > School of Systems Engineering > The University of Reading > PO Box 225 > Whiteknights > Reading > RG6 6AY > ----------------===========---------------- > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Fri Aug 17 15:55:36 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 17 Aug 2007 15:55:36 -0700 Subject: [Xorp-users] Interface & port mgt in Xorp. Message-ID: <46C62768.60705@candelatech.com> Hello! Is there any way to tell a running Xorp (OSPF) server to change the IP of a port without restarting Xorp? Maybe a SIGHUP to tell it to re-read it's config file or similar? I am considering a very dynamic network where routers will be logically changing their network connections. For instance, start with R1-eth0 connected to R2-eth0 but later change R1-eth0 to connect to R3-eth2 (on a different subnet). I would like the routers to deal with this gracefully and re-establish the OSPF routing tree(s) for the affected link quickly. Also can ports be added/removed to/from a running Xorp configuration? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From atanu at ICSI.Berkeley.EDU Fri Aug 17 16:13:19 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 17 Aug 2007 16:13:19 -0700 Subject: [Xorp-users] Interface & port mgt in Xorp. In-Reply-To: Message from Ben Greear of "Fri, 17 Aug 2007 15:55:36 PDT." <46C62768.60705@candelatech.com> Message-ID: <61236.1187392399@tigger.icir.org> Hi, Run the xorpsh interactively and reconfigure. The xorpsh can also be run from a script. Atanu. >>>>> "Ben" == Ben Greear writes: Ben> Hello! Is there any way to tell a running Xorp (OSPF) server Ben> to change the IP of a port without restarting Xorp? Maybe a Ben> SIGHUP to tell it to re-read it's config file or similar? Ben> I am considering a very dynamic network where routers will be Ben> logically changing their network connections. For instance, Ben> start with R1-eth0 connected to R2-eth0 but later change Ben> R1-eth0 to connect to R3-eth2 (on a different subnet). I would Ben> like the routers to deal with this gracefully and re-establish Ben> the OSPF routing tree(s) for the affected link quickly. Ben> Also can ports be added/removed to/from a running Xorp Ben> configuration? Ben> Thanks, Ben Ben> -- Ben Greear Candela Technologies Ben> Inc http://www.candelatech.com Ben> _______________________________________________ Xorp-users Ben> mailing list Xorp-users at xorp.org Ben> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From hengjuen at gmail.com Mon Aug 20 01:46:09 2007 From: hengjuen at gmail.com (HJ) Date: Mon, 20 Aug 2007 16:46:09 +0800 Subject: [Xorp-users] Testing L3 IP packet forward performance on CPU with XORP Message-ID: <686b91b0708200146x1c1eef72lef2c625ba646d1e9@mail.gmail.com> Hi, I am HJ. Currently I am working on a self study project on getting the performance benchmarking on L3 IP packet forwarding on x86 processor using XORP as the software. I am very new in this space. I would like to seek for the advise in this community on what are the neccessary setup that is needed for this test? Also i plan to run it on multi-threaded processor at later stage, which will modify some of the coding with OpenMP. 1. So is like in the config.boot file, what are the element is needed for this? 2. Do i need a external packet generator like Smart Bit to act as low gen? Or just some test file will do? If it is just a test file, anyway that I can do it? 3. If i want to do it as just self alone 1 linux box, how do i need to that? Thanks in advance. Regards, HJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070820/dafb82a2/attachment.html From kristian at spritelink.net Tue Aug 21 01:37:12 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Tue, 21 Aug 2007 10:37:12 +0200 Subject: [Xorp-users] Testing L3 IP packet forward performance on CPU with XORP In-Reply-To: <686b91b0708200146x1c1eef72lef2c625ba646d1e9@mail.gmail.com> References: <686b91b0708200146x1c1eef72lef2c625ba646d1e9@mail.gmail.com> Message-ID: <46CAA438.9030204@spritelink.net> HJ wrote: > Hi, I am HJ. Currently I am working on a self study project on getting > the performance benchmarking on L3 IP packet forwarding on x86 > processor using XORP as the software. XORP will never touch the forwarding of packets, thus the speed at which you can forward is not linked to the implementation of XORP. Although, if XORP eats a lot of resources, less is left to do the actual forwarding of packets (which is done in the kernel). So far the fastest operating system I know of for forwarding is Linux. Given it's support for multiple routing tables and other hacks it is in my opinion the best OS for use as a "PC router". > I am very new in this space. I would like to seek for the advise in > this community on what are the neccessary setup that is needed for > this test? Also i plan to run it on multi-threaded processor at later > stage, which will modify some of the coding with OpenMP. Multi-threading won't do _that_ much in forwarding. It's rather complicated but if you have a lot of interfaces it can help but in most cases it still comes to who has the fastest memory bus. If you want a high performance router I would recommend a dual CPU one where you use one CPU to forward packets and the other for control plane related tasks such as running BGP and OSPF. > 1. So is like in the config.boot file, what are the element is needed > for this? This is quite clear in the documentation I believe. Since XORP is a routing protocol suite, I assume, although you don't mention it, that you want to run some routing protocol. If all you need is static / connected routes you don't need XORP. > 2. Do i need a external packet generator like Smart Bit to act as low > gen? Or just some test file will do? If it is just a test file, anyway > that I can do it? Well, yes and no. You will need something to push a lot of packets and collect measurement data. Smartbits is one way. There is also a module for the Linux kernel which can generate packets - it's bloody fast but won't allow you to do much measuring, that you will have to figure out one your own. > 3. If i want to do it as just self alone 1 linux box, how do i need to > that? That would be very complicated and given that your machine would have to both generate packets and forward them, your measurements results wouldn't be worth much. Kristian. From pavlin at icir.org Tue Aug 21 12:40:28 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 21 Aug 2007 12:40:28 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables. In-Reply-To: Message from Ben Greear of "Thu, 09 Aug 2007 18:17:25 PDT." <46BBBCA5.308@candelatech.com> Message-ID: <200708211940.l7LJeSwJ078885@possum.icir.org> A non-text attachment was scrubbed... Name: test_bindtodevice.c Type: text/x-c Size: 1419 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070821/e80abe7f/attachment.bin From greearb at candelatech.com Tue Aug 21 12:59:45 2007 From: greearb at candelatech.com (Ben Greear) Date: Tue, 21 Aug 2007 12:59:45 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables. In-Reply-To: <200708211940.l7LJeSwJ078885@possum.icir.org> References: <200708211940.l7LJeSwJ078885@possum.icir.org> Message-ID: <46CB4431.2000707@candelatech.com> Pavlin Radoslavov wrote: > I continued the testing by connecting eth0 directly with eth1, and > then used SO_BINDTODEVICE to see whether the UDP packet will be > actually sent out of interface eth1 to eth0's IP address. > It turned out that the preceding ARP request out of eth1 is never > answered by the eth0 interface (probably the kernel recognizes that > the origin of the ARP is that host itself so the ARP reply is > suppressed). > However, after playing a bit I was able to add the ARP entry by > hand, but it was a bit tricky: > > 1. Added the ARP entry, where xx:xx:xx:xx:xx:xx is the Ethernet > address of eth0. Note that it must be done before configuring > the IP address on eth0: > arp -s 10.0.0.3 xx:xx:xx:xx:xx:xx > > 2. Configure the IP address on eth0: > ip addr add 10.0.0.3/8 dev eth0 You can also patch the kernel with a patch similar to this and ARP will resolve as normal once you enable 'sts' for the interfaces: http://lists.openwall.net/netdev/2007/06/09/1 > In conclusion, if you are running 2+ virtual routing instances each > of them with separate forwarding tables in the kernel and a > allocated corresponding subset of the physical interfaces, then it > is possible to use SO_BINDTODEVICE to make sure that unicast packets > transmit by one virtual router are transmit over the physical link > to another virtual router, but it is tricky (see the above ARP > hack). This is what I am trying to do. I am still working on integrating Xorp with my app, but should have some progress soon. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From kristian at spritelink.net Wed Aug 22 01:55:33 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Wed, 22 Aug 2007 10:55:33 +0200 Subject: [Xorp-users] Question on supporting multiple routing tables. In-Reply-To: <200708211940.l7LJeSwJ078885@possum.icir.org> References: <200708211940.l7LJeSwJ078885@possum.icir.org> Message-ID: <46CBFA05.7000705@spritelink.net> Pavlin Radoslavov wrote: > Ben Greear wrote: > >>>> I'm sure you'll want to be able to bind the socket to a local IP, but >>>> if you want to leave out the SO_BINDTODEVICE I can test it and see >>>> if it works. I can add the SO_BINDTODEVICE if needed and send you a patch. >>>> >>> Currently, we don't bind to the local IP (we do but in certain cases >>> only). I believe even if you bind to a local IP you cannot really >>> force the unicast IP packet to exit the system on the particular >>> interface. Anyway, I might be wrong here, so please let me know if >>> you find that bind()-ing only gives us the desired behavior. >>> >> If you set up the routing tables and rules correctly, then binding to a >> local IP >> is probably sufficient. If you are certain that you want the pkt to >> leave by a certain >> interface, then I don't think it can ever hurt to bind to that local IP, >> but just in case, >> it could also be a config option... >>> BTW, what protocols are you planning to run? Without SO_BINDTODEVICE >>> we might have to use different solution for each type of >>> sockets/packets: raw IP packets, TCP, UDP. >>> FYI, the I/O system-specific stuff is inside fea/data_plane/io, >>> though io_tcpudp_socket.cc itself uses the xorp/libcomm wrapper >>> library. >>> BGP only doesn't use the FEA (yet) and does its own TCP connection >>> (inside bgp/socket.{hh,cc}). >>> >>> Also, there could be some gotchas with RIP's UDP socket, but lets >>> address first the protocols you are actually going to use. >>> >> At a minimum, I want to support OSPF. However, I'd like to have options to >> do other protocols as well. In my own experience, binding UDP is very >> similar >> to binding TCP, but if you want some sample code I can post it. I'm not >> sure >> about raw IP packets. >> >> Also, for my application, it will always be running on Linux, so I can >> depend on >> SO_BINDTODEVICE being available... > > I played a bit with SO_BINDTODEVICE, and here is what I found. > For the record, I am using Gentoo 2006.1 with kernel 2.6.20.1. > > In my test I opened an UDP socket, then used > setsockopt(SO_BINDTODEVICE) to bind the socket to a specific > interface (eth1), and then used sendto() to transmit a single UDP packet. > At the end I am attaching the test program in case someone wants to play > with it. > > * If the destination address belongs to the same network interface > that is used with SO_BINDTODEVICE (eth1), then the transmitted packets > are sent over the loopback interface (lo) instead of the external > (physical) interface (eth1). I believe some of your problems might arise from that IP addresses per say don't belong to interfaces in Linux. I'm no real expert here, I'd rather invite Martin Josefsson, a friend and NetFilter developer, to the discussion but with limited time.. you know :) Linux uses the host-based addressing solution approach, so an IP address merely belongs to the system. Routing is used to determine which interface is to be used for outgoing packets and so forth. I can't really go into details here for I simply don't know, but I believe this is what creates your "problem" - it is merely how the system is implemented. "It's a feature, not a bug" ;) Maybe someone with a better view of how Linux and other OSes handle this can give us an overview or perhaps a tip on where to read up on the subject. I know that this host-based vs interface-based addressing is discussed on the netfilter team lists something like once every half year or so ;) > * If the destination address belongs to the same subnet as the > network interface that is used with SO_BINDTODEVICE (eth1), then > an ARP request is sent first by the kernel (as we would expect). > If the ARP is resolved, then the UDP packet should follow. > > * For all other (i.e., remote) destination addresses or IP > addresses that belong to some other interfaces of that host, an > ARP request is sent first by the kernel for the destination > address. If the ARP request is not answered (as it would be the > case for a remote destination unless somebody else is acting as a > proxy), then the UDP transmission will fail. > >>From the above observations, the interesting behavior (at least for > me) is that SO_BINDTODEVICE can be used to force a packet with > destination address that belongs to some other interface of that > host (e.g., eth0) to be transmitted over the specified interface > (eth1). Without SO_BINDTODEVICE such packets are transmitted over > the loopback interface (lo). > > I continued the testing by connecting eth0 directly with eth1, and > then used SO_BINDTODEVICE to see whether the UDP packet will be > actually sent out of interface eth1 to eth0's IP address. > It turned out that the preceding ARP request out of eth1 is never > answered by the eth0 interface (probably the kernel recognizes that > the origin of the ARP is that host itself so the ARP reply is > suppressed). > However, after playing a bit I was able to add the ARP entry by > hand, but it was a bit tricky: > > 1. Added the ARP entry, where xx:xx:xx:xx:xx:xx is the Ethernet > address of eth0. Note that it must be done before configuring > the IP address on eth0: > arp -s 10.0.0.3 xx:xx:xx:xx:xx:xx > > 2. Configure the IP address on eth0: > ip addr add 10.0.0.3/8 dev eth0 > > Finally after that I was able to see the UDP packet going out on > eth1 with destination address the IP address on eth0. > > In conclusion, if you are running 2+ virtual routing instances each > of them with separate forwarding tables in the kernel and a > allocated corresponding subset of the physical interfaces, then it > is possible to use SO_BINDTODEVICE to make sure that unicast packets > transmit by one virtual router are transmit over the physical link > to another virtual router, but it is tricky (see the above ARP > hack). > > However, if we don't care that the unicast packets between the > virtual instances are transmitted over the loopback interface, then > we don't need SO_BINDTODEVICE: just bind(2)-ing to the outgoing > interface's IP address will be sufficient to guarantee the IP source > address is set to the desired value. > > Regards, > Pavlin > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From sweiss at cablematrix.com Wed Aug 22 03:48:43 2007 From: sweiss at cablematrix.com (Shmuel Weiss) Date: Wed, 22 Aug 2007 13:48:43 +0300 Subject: [Xorp-users] TCP MD5 Authentication support Message-ID: <20070822105418.A03CD134A1@sheffield.bcentralhost.com> Does the version 1.4 of XORP support TCP MD5 Signature ? If yes , how to configure it in Linux Red Hat (no freebsd). Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070822/a3159d9e/attachment.html From jfs at computer.org Wed Aug 22 17:25:33 2007 From: jfs at computer.org (Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?=) Date: Thu, 23 Aug 2007 02:25:33 +0200 Subject: [Xorp-users] No logging when using xorp_rtrmgr Message-ID: <20070823002533.GA4295@javifsp.no-ip.org> I've been banging my head with Xorp to try to get a simple multicast setup running. I've finally made it work but one of the reasons it took me so much time is that xorp_rtrmgr would not output any logging information at all when starting up even if using the '-v' flag (and I have been unable to find any syslog messages either) I'm not sure if this is because of my config.boot (attached) but shouldn't the daemon output some information on startup? When I made mistakes with the config.boot the daemon would just die with no error message. Might this be because of some error when compiling Xorp? For reference: - Using Xorp 1.4 - Compiled in a Debian GNU/Linux 3.1 'sarge' chroot (GCC 3.3.5, libc6 2.3.2.ds1-22sarge6) - Running Xorp in UML instances running Debian GNU/Linux 3.1, Linux kernel 2.6.17 Thanks, Javier PS: BTW, Xorp 1.4 does not compile with newer g++ versions (I've tried 4.1.3 in a Debian 'sid' environment). Is this fixed in CVS? -------------- next part -------------- interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "Ethernet interface #1" disable: false default-system-config } interface eth1 { description: "Ethernet interface #2" disable: false default-system-config } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: 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 } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } static-rps { rp 172.16.0.2 { 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 } } } } protocols { fib2mrib { disable: false } } -------------- 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/20070823/389bedef/attachment.bin From pavlin at icir.org Thu Aug 23 11:43:10 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 23 Aug 2007 11:43:10 -0700 Subject: [Xorp-users] No logging when using xorp_rtrmgr In-Reply-To: Message from Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?= of "Thu, 23 Aug 2007 02:25:33 +0200." <20070823002533.GA4295@javifsp.no-ip.org> Message-ID: <200708231843.l7NIhAYi028537@possum.icir.org> > I've been banging my head with Xorp to try to get a simple multicast setup > running. I've finally made it work but one of the reasons it took me > so much time is that xorp_rtrmgr would not output any logging information > at all when starting up even if using the '-v' flag (and I have been unable > to find any syslog messages either) The XORP log messages are output to stdout/stderr when you start the xorp_rtrmgr. XORP doesn't write any syslog messages (yet), which is one of the shortcomings of the log meccanism that needs to be addressed in the future. Do you see any messages printed on the terminal if you start xorp_rtrmgr in foreground? > I'm not sure if this is because of my config.boot (attached) but shouldn't > the daemon output some information on startup? When I made mistakes with the > config.boot the daemon would just die with no error message. Your config.boot seems fine, except that in the PIM-SM configuration section you should use either static-rps or bootstrap configuration. Mixing both mechanisms might result in unpredictable outcome. How do you start the xorp_rtrmgr process? The no-brainer solution is just to run xorp_rtrmgr in background and redirect its stdout and stderr output to a log file. A better solution is to use the contributed code inside xorp/contrib/packages/debian where you will find XORP-related package information for Debian. It also contains an init script for XORP. However, I should point that we (XORP) haven't tested it, but hopefully Benjamin Sonntag (the author of that contributed code) and/or the Debian-knowledgable folks on that list can provide more input on the subject. > Might this be because of some error when compiling Xorp? > > For reference: > - Using Xorp 1.4 > - Compiled in a Debian GNU/Linux 3.1 'sarge' chroot (GCC 3.3.5, libc6 > 2.3.2.ds1-22sarge6) > - Running Xorp in UML instances running Debian GNU/Linux 3.1, Linux kernel > 2.6.17 Did you succeed to compile XORP with the above setup? If there were any compilation errors, then the compilation itself should fail and obviously you can't run XORP. See the Debian section inside xorp/BUILD_NOTES about some information for building XORP on Debian. Note: the information there assumes that you download and compile XORP by hand rather than as part of a Debian package. > Thanks, > > Javier > > PS: BTW, Xorp 1.4 does not compile with newer g++ versions (I've tried 4.1.3 in > a Debian 'sid' environment). Is this fixed in CVS? Which Debian package did you use to get 4.1.3? I just searched http://packages.debian.org/ and the latest 4.1.x gcc package is 4.1.2-15. Anyway, I will give a try of 4.1.2-15 and 4.2.1-4 as well. Regards, Pavlin > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From jfs at computer.org Thu Aug 23 13:36:12 2007 From: jfs at computer.org (Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?=) Date: Thu, 23 Aug 2007 22:36:12 +0200 Subject: [Xorp-users] No logging when using xorp_rtrmgr In-Reply-To: <200708231843.l7NIhAYi028537@possum.icir.org> References: <20070823002533.GA4295@javifsp.no-ip.org> <200708231843.l7NIhAYi028537@possum.icir.org> Message-ID: <20070823203612.GB24713@javifsp.no-ip.org> On Thu, Aug 23, 2007 at 11:43:10AM -0700, Pavlin Radoslavov wrote: > Do you see any messages printed on the terminal if you start > xorp_rtrmgr in foreground? No, none. > > I'm not sure if this is because of my config.boot (attached) but shouldn't > > the daemon output some information on startup? When I made mistakes with the > > config.boot the daemon would just die with no error message. > > Your config.boot seems fine, except that in the PIM-SM configuration > section you should use either static-rps or bootstrap configuration. > Mixing both mechanisms might result in unpredictable outcome. Ok. Will remove that part. > How do you start the xorp_rtrmgr process? Manually, telling it to use the boot file. > A better solution is to use the contributed code inside > xorp/contrib/packages/debian where you will find XORP-related > package information for Debian. It also contains an init script > for XORP. However, I should point that we (XORP) haven't tested it, > but hopefully Benjamin Sonntag (the author of that contributed code) > and/or the Debian-knowledgable folks on that list can provide more > input on the subject. I've already built Debian packages for Xorp (I'm a Debian developer myself). I haven't looked up at the contributed code there, however. But I've based myself on the work done by Jose Calhariz which is based on Benjamin's work http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433467 Actually, my goal is to eventually provide official Debian packages in Debian's repositories for everybody to enjoy Xorp :) > > For reference: > > - Using Xorp 1.4 > > - Compiled in a Debian GNU/Linux 3.1 'sarge' chroot (GCC 3.3.5, libc6 > > 2.3.2.ds1-22sarge6) > > - Running Xorp in UML instances running Debian GNU/Linux 3.1, Linux kernel > > 2.6.17 > > Did you succeed to compile XORP with the above setup? Yes. > If there were any compilation errors, then the compilation itself > should fail and obviously you can't run XORP. Obviously, but that does not happen. I have not reviewed the compiler's warnings, however. > > PS: BTW, Xorp 1.4 does not compile with newer g++ versions (I've tried 4.1.3 in > > a Debian 'sid' environment). Is this fixed in CVS? > > Which Debian package did you use to get 4.1.3? I just searched > http://packages.debian.org/ and the latest 4.1.x gcc package is > 4.1.2-15. > Anyway, I will give a try of 4.1.2-15 and 4.2.1-4 as well. You're right, fingers might have mistyped, I should have said 4:4.1.2-3 (not 4.1.3). Regards Javier -------------- 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/20070823/47390f11/attachment.bin From atanu at ICSI.Berkeley.EDU Thu Aug 23 18:13:33 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 23 Aug 2007 18:13:33 -0700 Subject: [Xorp-users] TCP MD5 Authentication support In-Reply-To: Message from "Shmuel Weiss" of "Wed, 22 Aug 2007 13:48:43 +0300." <20070822105418.A03CD134A1@sheffield.bcentralhost.com> Message-ID: <25512.1187918013@tigger.icir.org> Hi, The 1.4 release will not allow the TCP_MD5SIG option to be set on a socket. However a slight modification to etc/templates/bgp.tp will allow it to be enabled and the function comm_set_tcpmd5 in libcomm/comm_sock.c would need to be modified to set the option on Linux. The actual setting of the password would have to done separately using Linux IPsec tools. Atanu. >>>>> "Shmuel" == Shmuel Weiss writes: Shmuel> Does the version 1.4 of XORP support TCP MD5 Signature ? Shmuel> If yes , how to configure it in Linux Red Hat (no freebsd). Shmuel> Thanks, Shmuel> _______________________________________________ Shmuel> Xorp-users mailing list Shmuel> Xorp-users at xorp.org Shmuel> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Fri Aug 24 00:01:31 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 24 Aug 2007 00:01:31 -0700 Subject: [Xorp-users] No logging when using xorp_rtrmgr In-Reply-To: Message from Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?= of "Thu, 23 Aug 2007 22:36:12 +0200." <20070823203612.GB24713@javifsp.no-ip.org> Message-ID: <200708240701.l7O71VUt034724@possum.icir.org> Javier Fern?ndez-Sanguino Pe?a wrote: > On Thu, Aug 23, 2007 at 11:43:10AM -0700, Pavlin Radoslavov wrote: > > Do you see any messages printed on the terminal if you start > > xorp_rtrmgr in foreground? > > No, none. That's odd. Could you confirm that if you do the following, then the xorp_rtrmgr process doesn't print anything: ./configure gmake cd rtrmgr # Become a root ./xorp_rtrmgr -b my_config.boot > > A better solution is to use the contributed code inside > > xorp/contrib/packages/debian where you will find XORP-related > > package information for Debian. It also contains an init script > > for XORP. However, I should point that we (XORP) haven't tested it, > > but hopefully Benjamin Sonntag (the author of that contributed code) > > and/or the Debian-knowledgable folks on that list can provide more > > input on the subject. > > I've already built Debian packages for Xorp (I'm a Debian developer myself). > I haven't looked up at the contributed code there, however. But I've based > myself on the work done by Jose Calhariz which is based on Benjamin's work > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433467 > > Actually, my goal is to eventually provide official Debian packages in > Debian's repositories for everybody to enjoy Xorp :) Great! :) > > > PS: BTW, Xorp 1.4 does not compile with newer g++ versions (I've tried 4.1.3 in > > > a Debian 'sid' environment). Is this fixed in CVS? > > > > Which Debian package did you use to get 4.1.3? I just searched > > http://packages.debian.org/ and the latest 4.1.x gcc package is > > 4.1.2-15. > > Anyway, I will give a try of 4.1.2-15 and 4.2.1-4 as well. > > You're right, fingers might have mistyped, I should have said 4:4.1.2-3 (not > 4.1.3). Actually, you could be correct when you said 4.1.3: the Debian package version is 4.1.2, but "gcc-4.1 --version" actually says 4.1.3. Anyway, I updated our Debian system to 4.0 (etch) which has gcc-4.1.1. I was able to compile the latest XORP code from CVS with that compiler. After updating the compiler to gcc-4.1.3 I was able again to compiler XORP without any problem. In both cases, "gmake check" passed as well. Hence, please try the latest XORP code from CVS and see whether you still have the compilation problem. BTW, I didn't try the latest 4.2.1-4 compiler, because there were some issues when trying to install it. Thanks, Pavlin From jfs at computer.org Fri Aug 24 00:32:58 2007 From: jfs at computer.org (Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?=) Date: Fri, 24 Aug 2007 09:32:58 +0200 Subject: [Xorp-users] No logging when using xorp_rtrmgr In-Reply-To: <200708240701.l7O71VUt034724@possum.icir.org> References: <20070823203612.GB24713@javifsp.no-ip.org> <200708240701.l7O71VUt034724@possum.icir.org> Message-ID: <20070824073258.GA25785@javifsp.no-ip.org> On Fri, Aug 24, 2007 at 12:01:31AM -0700, Pavlin Radoslavov wrote: > Javier Fern?ndez-Sanguino Pe?a wrote: > > > On Thu, Aug 23, 2007 at 11:43:10AM -0700, Pavlin Radoslavov wrote: > > > Do you see any messages printed on the terminal if you start > > > xorp_rtrmgr in foreground? > > > > No, none. > > That's odd. > > Could you confirm that if you do the following, then the xorp_rtrmgr > process doesn't print anything: > > ./configure > gmake gmake == GNU make, right? > cd rtrmgr > # Become a root > ./xorp_rtrmgr -b my_config.boot Nothing at all. Even though if I strace the process I see that it fails because my_config.boot does not exist: open("my_config.boot", O_RDONLY) = -1 ENOENT (No such file or directory) > Actually, you could be correct when you said 4.1.3: the Debian > package version is 4.1.2, but "gcc-4.1 --version" actually says > 4.1.3. That's probably where I copy & pasted from. > Anyway, I updated our Debian system to 4.0 (etch) which has > gcc-4.1.1. I was able to compile the latest XORP code from CVS with > that compiler. After updating the compiler to gcc-4.1.3 I was able > again to compiler XORP without any problem. In both cases, "gmake > check" passed as well. > Hence, please try the latest XORP code from CVS and see whether you > still have the compilation problem. I'm going to compile CVS in my development system (which runs 'sid', unstable) and see how it fares. Regards Javier From jfs at computer.org Fri Aug 24 06:41:17 2007 From: jfs at computer.org (Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?=) Date: Fri, 24 Aug 2007 15:41:17 +0200 Subject: [Xorp-users] No logging when using xorp_rtrmgr In-Reply-To: <200708240701.l7O71VUt034724@possum.icir.org> References: <20070823203612.GB24713@javifsp.no-ip.org> <200708240701.l7O71VUt034724@possum.icir.org> Message-ID: <20070824134117.GA3960@javifsp.no-ip.org> On Fri, Aug 24, 2007 at 12:01:31AM -0700, Pavlin Radoslavov wrote: > Could you confirm that if you do the following, then the xorp_rtrmgr > process doesn't print anything: > > ./configure > gmake > cd rtrmgr > # Become a root > ./xorp_rtrmgr -b my_config.boot If I do this in the CVS code I do get proper error messages in STDERR, including the fact that there is no 'xorp' group and the fact that the file does not exist. > Hence, please try the latest XORP code from CVS and see whether you > still have the compilation problem. The XORP code from CVS compiles fine. Regards Javier From pavlin at icir.org Fri Aug 24 09:40:43 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 24 Aug 2007 09:40:43 -0700 Subject: [Xorp-users] No logging when using xorp_rtrmgr In-Reply-To: Message from Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?= of "Fri, 24 Aug 2007 09:32:58 +0200." <20070824073258.GA25785@javifsp.no-ip.org> Message-ID: <200708241640.l7OGehEk039108@possum.icir.org> > > Could you confirm that if you do the following, then the xorp_rtrmgr > > process doesn't print anything: > > > > ./configure > > gmake > > gmake == GNU make, right? Yes. > > cd rtrmgr > > # Become a root > > ./xorp_rtrmgr -b my_config.boot > > Nothing at all. Even though if I strace the process I see that it fails > because my_config.boot does not exist: > > open("my_config.boot", O_RDONLY) = -1 ENOENT (No such file or > directory) If the file is not there, then xorp_rtrmgr should fail with the proper error. E.g.: pavlin at xorp[281] ./xorp_rtrmgr -b no_such_file.boot [ 2007/08/24 09:37:19 ERROR xorp_rtrmgr:39085 RTRMGR +330 /home/pavlin/xorp/rtrmgr/main_rtrmgr.cc run ] rtrmgr shutting down due to an init error: Failed to open config file: no_such_file.boot Exit 1 It seems like there is something wrong with printing the log messages. However, from your next email on the subject it seems that the latest code from CVS doesn't have this issue so I won't pursue it. Regards, Pavlin From pavlin at icir.org Fri Aug 24 09:43:43 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 24 Aug 2007 09:43:43 -0700 Subject: [Xorp-users] No logging when using xorp_rtrmgr In-Reply-To: Message from Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?= of "Fri, 24 Aug 2007 15:41:17 +0200." <20070824134117.GA3960@javifsp.no-ip.org> Message-ID: <200708241643.l7OGhhDd039154@possum.icir.org> Javier Fern?ndez-Sanguino Pe?a wrote: > On Fri, Aug 24, 2007 at 12:01:31AM -0700, Pavlin Radoslavov wrote: > > Could you confirm that if you do the following, then the xorp_rtrmgr > > process doesn't print anything: > > > > ./configure > > gmake > > cd rtrmgr > > # Become a root > > ./xorp_rtrmgr -b my_config.boot > > If I do this in the CVS code I do get proper error messages in STDERR, > including the fact that there is no 'xorp' group and the fact that the file > does not exist. Great! I don't have an explanation why the 1.4 code doesn't print anything, because if I remember correctly nothing related to the log mechanism has been changed since then. > > Hence, please try the latest XORP code from CVS and see whether you > > still have the compilation problem. > > The XORP code from CVS compiles fine. I am glad to know that. Thanks, Pavlin From jfs at computer.org Fri Aug 24 17:16:59 2007 From: jfs at computer.org (Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?=) Date: Sat, 25 Aug 2007 02:16:59 +0200 Subject: [Xorp-users] No logging when using xorp_rtrmgr In-Reply-To: <200708231843.l7NIhAYi028537@possum.icir.org> References: <20070823002533.GA4295@javifsp.no-ip.org> <200708231843.l7NIhAYi028537@possum.icir.org> Message-ID: <20070825001659.GA29662@javifsp.no-ip.org> On Thu, Aug 23, 2007 at 11:43:10AM -0700, Pavlin Radoslavov wrote: > > I've been banging my head with Xorp to try to get a simple multicast setup > > running. I've finally made it work but one of the reasons it took me > > so much time is that xorp_rtrmgr would not output any logging information > > at all when starting up even if using the '-v' flag (and I have been unable > > to find any syslog messages either) > > The XORP log messages are output to stdout/stderr when you start the > xorp_rtrmgr. > XORP doesn't write any syslog messages (yet), which is one of the > shortcomings of the log meccanism that needs to be addressed in the > future. After building/testing xorp 1.5 I think we are going to work around this (in Debian) by using the 'daemon' program (http://www.libslack.org/daemon/) this program can send stdout/stderr of programs it runs to either a logfile or syslog and it also takes care of putting it into background, generating its pidfile, etc. Other Linux and *BSD distributions might have a similar program to handle that so it's not that much of an issue, IMHO. Just for reference, attached is the current status of the init.d script I'm working at for the Debian package. Regards Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: xorp.init.d Type: text/x-dsrc Size: 4205 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070825/30a8b875/attachment.bin From hantongs at gmail.com Sun Aug 26 23:25:40 2007 From: hantongs at gmail.com (Hansi) Date: Mon, 27 Aug 2007 14:25:40 +0800 Subject: [Xorp-users] Linux Ubuntu Compile Problem Message-ID: <2f9e317b0708262325t3e21b241pf67b8141be3b96cc@mail.gmail.com> Hi, Does xorp compile on Ubuntu 7.04 Desktop w/ Linux kernel 2.6.20-16? I downloaded sources from CVS, yet when I did ./configure, the following issue was encountered: checking OpenSSL installation prefix... Could not find part of OpenSSL or one it's components in /usr /usr/local /usr/local/ssl /mingw /gnuwin32 /opt /usr/sfw Use --with-openssl=DIR to specify OpenSSL installation root. I happen to come across several discussions in the mailing list specifically having to have these files: md5.h and libcrypto. I do have an openssl installed in my system though. However, it seems that xorp can't locate the files stated. Appreciate for pointers. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070827/4e000dbd/attachment.html From a.greenhalgh at cs.ucl.ac.uk Mon Aug 27 01:00:46 2007 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Mon, 27 Aug 2007 09:00:46 +0100 Subject: [Xorp-users] Linux Ubuntu Compile Problem In-Reply-To: <2f9e317b0708262325t3e21b241pf67b8141be3b96cc@mail.gmail.com> References: <2f9e317b0708262325t3e21b241pf67b8141be3b96cc@mail.gmail.com> Message-ID: <4769af410708270100x37a232b8u7a6a2692b5c8fc49@mail.gmail.com> Hi Try apt-get install libssl-dev Adam On 8/27/07, Hansi wrote: > Hi, > > Does xorp compile on Ubuntu 7.04 Desktop w/ Linux kernel 2.6.20-16? > > I downloaded sources from CVS, yet when I did ./configure, the following > issue was encountered: > > checking OpenSSL installation prefix... Could not find part of OpenSSL or > one it's components in /usr /usr/local /usr/local/ssl /mingw /gnuwin32 /opt > /usr/sfw > Use --with-openssl=DIR to specify OpenSSL installation root. > > I happen to come across several discussions in the mailing list specifically > having to have these files: md5.h and libcrypto. I do have an openssl > installed in my system though. However, it seems that xorp can't locate the > files stated. > > Appreciate for pointers. > > Thanks. > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > From hantongs at gmail.com Tue Aug 28 02:52:33 2007 From: hantongs at gmail.com (Hansi) Date: Tue, 28 Aug 2007 17:52:33 +0800 Subject: [Xorp-users] traceroute missing in CVS? Message-ID: <2f9e317b0708280252q31f1dea8wd208ad7bf73a363a@mail.gmail.com> Hello, I downloaded sources from CVS. Compilation and installation happens to work well. However upon invoking the xorp command line shell, it appears that the traceroute binary wasn't included. I got these Warnings: [ 2007/08/28 17:46:56 WARNING xorpsh RTRMGR ] [Operational Command File: /usr/local/xorp/etc/templates/misc.cmds line 29]: Executable file not found: traceroute Is this so? or did i miss something during compilation? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070828/60c98d08/attachment.html From a.greenhalgh at cs.ucl.ac.uk Tue Aug 28 03:04:33 2007 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Tue, 28 Aug 2007 11:04:33 +0100 Subject: [Xorp-users] traceroute missing in CVS? In-Reply-To: <2f9e317b0708280252q31f1dea8wd208ad7bf73a363a@mail.gmail.com> References: <2f9e317b0708280252q31f1dea8wd208ad7bf73a363a@mail.gmail.com> Message-ID: <4769af410708280304t3551e904o6025d24f293c558c@mail.gmail.com> It uses the external traceroute binary. On ubunut do apt-get install traceroute adam On 8/28/07, Hansi wrote: > Hello, > > I downloaded sources from CVS. Compilation and installation happens to work > well. However upon invoking the xorp command line shell, it appears that the > traceroute binary wasn't included. > > I got these Warnings: [ 2007/08/28 17:46:56 WARNING xorpsh RTRMGR ] > [Operational Command File: > /usr/local/xorp/etc/templates/misc.cmds line 29]: > Executable file not found: traceroute > > Is this so? or did i miss something during compilation? > > Thanks. > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > From jfs at computer.org Tue Aug 28 04:45:15 2007 From: jfs at computer.org (Javier Fernandez-Sanguino) Date: Tue, 28 Aug 2007 13:45:15 +0200 Subject: [Xorp-users] traceroute missing in CVS? In-Reply-To: <4769af410708280304t3551e904o6025d24f293c558c@mail.gmail.com> References: <2f9e317b0708280252q31f1dea8wd208ad7bf73a363a@mail.gmail.com> <4769af410708280304t3551e904o6025d24f293c558c@mail.gmail.com> Message-ID: 2007/8/28, Adam Greenhalgh : > It uses the external traceroute binary. On ubunut do apt-get install traceroute You also need to install additional packages to get the binaries that Xorp's shell uses. IIRC this includes iputils-tracepath too (which provides traceroute6). The binaries are listed in /usr/local/xorp/etc/templates/misc.cmds I think that If you don't have them installed, however, it's not a big deal, you just will not be able to use those commands from the CLI. Regards Javier From hantongs at gmail.com Wed Aug 29 00:25:31 2007 From: hantongs at gmail.com (Hansi) Date: Wed, 29 Aug 2007 15:25:31 +0800 Subject: [Xorp-users] policy connected already exists Message-ID: <2f9e317b0708290025n46c6accdyb10269a68300c9d7@mail.gmail.com> Hello, I have 2 boxes running xorp now and I intend to run RIP as a routing protocol. Though I was successful in configuring through the 'config.boot' file in the first box. I also intend to configure RIP through the xorp command line shell. I was able to successfully commit a policy with policy-statement "static". However, when I tried to commit a policy-statement "connected", I encountered this error: root at hansi-desktop# set policy policy-statement connected term export from protocol connected [edit] root at hansi-desktop# commit Commit Failed 102 Command failed create_policy: PolicyMapError from line 45 of policy_map.cc: Can't create policy connected : already exists[edit] Does this error indicate that the policy 'connected' has been implicitly configured already? Would appreciate some assistance. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070829/15d32414/attachment.html From pavlin at icir.org Wed Aug 29 02:30:39 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 29 Aug 2007 02:30:39 -0700 Subject: [Xorp-users] No logging when using xorp_rtrmgr In-Reply-To: Message from Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?= of "Sat, 25 Aug 2007 02:16:59 +0200." <20070825001659.GA29662@javifsp.no-ip.org> Message-ID: <200708290930.l7T9UdcK017812@possum.icir.org> > > The XORP log messages are output to stdout/stderr when you start the > > xorp_rtrmgr. > > XORP doesn't write any syslog messages (yet), which is one of the > > shortcomings of the log meccanism that needs to be addressed in the > > future. > > After building/testing xorp 1.5 I think we are going to work around this (in > Debian) by using the 'daemon' program (http://www.libslack.org/daemon/) > this program can send stdout/stderr of programs it runs to either a logfile > or syslog and it also takes care of putting it into background, generating > its pidfile, etc. > > Other Linux and *BSD distributions might have a similar program to handle > that so it's not that much of an issue, IMHO. > > Just for reference, attached is the current status of the init.d script I'm > working at for the Debian package. Thank you for the info and the script. The most recent version of the script from Bugzilla entry #119, Comment #9 (http://www.xorp.org/bugzilla/show_bug.cgi?id=119) is committed to CVS: Revision Changes Path 1.1 +208 -0 xorp/contrib/init_scripts/debian/xorp (new) Regards, Pavlin From jfs at computer.org Wed Aug 29 02:37:07 2007 From: jfs at computer.org (Javier Fernandez-Sanguino) Date: Wed, 29 Aug 2007 11:37:07 +0200 Subject: [Xorp-users] No logging when using xorp_rtrmgr In-Reply-To: <200708290930.l7T9UdcK017812@possum.icir.org> References: <20070825001659.GA29662@javifsp.no-ip.org> <200708290930.l7T9UdcK017812@possum.icir.org> Message-ID: 2007/8/29, Pavlin Radoslavov : > Thank you for the info and the script. The most recent version of > the script from Bugzilla entry #119, Comment #9 > (http://www.xorp.org/bugzilla/show_bug.cgi?id=119) is committed to CVS: Great. Thanks. FWIW Debian packages for Xorp have now been uploaded to Debian's incoming queue (http://ftp-master.debian.org/new.html). They should be available in Debian repository (if the FTP masters approve them) shortly. If anyone is interested in testing them out either on Debian or on Ubuntu (they should work well in both) or on other dpkg-based Linux distributions please send me a private mail. Regards Javier From pavlin at icir.org Wed Aug 29 10:22:12 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 29 Aug 2007 10:22:12 -0700 Subject: [Xorp-users] policy connected already exists In-Reply-To: Message from Hansi of "Wed, 29 Aug 2007 15:25:31 +0800." <2f9e317b0708290025n46c6accdyb10269a68300c9d7@mail.gmail.com> Message-ID: <200708291722.l7THMCsD037604@possum.icir.org> > I have 2 boxes running xorp now and I intend to run RIP as a routing > protocol. Though I was successful in configuring through the 'config.boot' > file in the first box. I also intend to configure RIP through the xorp > command line shell. I was able to successfully commit a policy with > policy-statement "static". However, when I tried to commit a > policy-statement "connected", I encountered this error: > > root at hansi-desktop# set policy policy-statement connected term export from > protocol connected > [edit] > root at hansi-desktop# commit > Commit Failed > 102 Command failed create_policy: PolicyMapError from line 45 of > policy_map.cc: Can't create policy connected : already exists[edit] What is your policy configuration before you attempted to add the above statement? You could use the "show policy" command to print it. Also, what XORP version are you using? Thanks, Pavlin > Does this error indicate that the policy 'connected' has been implicitly > configured already? > > Would appreciate some assistance. > > Thanks. > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Wed Aug 29 18:32:45 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 29 Aug 2007 18:32:45 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables. In-Reply-To: <200708211940.l7LJeSwJ078885@possum.icir.org> References: <200708211940.l7LJeSwJ078885@possum.icir.org> Message-ID: <46D61E3D.5060308@candelatech.com> I finally found time to work on this, and it seems like I am making some good progress! I'm using the cvs snapshot from back when you added the custom routing-table support, and have not patched the code at all to date. I see OSPF HELLO messages on the links between my routers, and it seems the routing tables are set up mostly correct. However, I'm still missing something..probably a config file issue. Assume I have: R1 with eth0, eth1 R2 with eth2, eth3 eth1 and eth2 are connected eth0 and eth3 are connected to simple subnets of PCs (ie, no OSPF routers) In my case, I don't see routes to get to the eth3 network on R1, though I do see routes to get to the eth2 subnet. How do I tell Xorp to treat eth0 and eth3 as subnets and populate routes properly? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Aug 29 18:35:25 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 29 Aug 2007 18:35:25 -0700 Subject: [Xorp-users] Unreachable default route. Message-ID: <46D61EDD.4030506@candelatech.com> Is there a way to get Xorp to put in an un-reachable default route if no default gateway is known/configured for a particular routing table? This keeps Linux from trying other routing tables (for instance, when you have specified a particular routing table per some rule.) From the command line, you'd do something like: # 100 is the routing table ID ip route add unreachable 0/0 table 100 Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Wed Aug 29 22:47:36 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 29 Aug 2007 22:47:36 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: Message from Ben Greear of "Wed, 29 Aug 2007 18:35:25 PDT." <46D61EDD.4030506@candelatech.com> Message-ID: <200708300547.l7U5lahH043705@possum.icir.org> Ben Greear wrote: > Is there a way to get Xorp to put in an un-reachable default route > if no default gateway is known/configured for a particular routing table? > This keeps Linux from trying other routing tables (for instance, when you > have specified a particular routing table per some rule.) > > From the command line, you'd do something like: > > # 100 is the routing table ID > ip route add unreachable 0/0 table 100 It sounds like you need to configure a discard interface, and point the default route to that interface. Off the top of my head, for Linux it will be like: interfaces { ... interface discard0 { disable: false discard: true vif discard0 { disable: false address 192.0.2.1 { prefix-length: 32 disable: false } } } } protocols { static { route 0.0.0.0/0 { next-hop: 192.0.2.1 } } } Regards, Pavlin > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Wed Aug 29 22:51:55 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 29 Aug 2007 22:51:55 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: <200708300547.l7U5lahH043705@possum.icir.org> References: <200708300547.l7U5lahH043705@possum.icir.org> Message-ID: <46D65AFB.5000000@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > >> Is there a way to get Xorp to put in an un-reachable default route >> if no default gateway is known/configured for a particular routing table? >> This keeps Linux from trying other routing tables (for instance, when you >> have specified a particular routing table per some rule.) >> >> From the command line, you'd do something like: >> >> # 100 is the routing table ID >> ip route add unreachable 0/0 table 100 >> > > It sounds like you need to configure a discard interface, and point > the default route to that interface. > I only want this to exist _IF_ there is no valid default route. So, I think it would have to be more dynamic than a config file, since I assume OSPF or similar might negotiate a default route (and fail to find one at other times??) Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From hantongs at gmail.com Wed Aug 29 23:19:45 2007 From: hantongs at gmail.com (Hansi) Date: Thu, 30 Aug 2007 14:19:45 +0800 Subject: [Xorp-users] policy connected already exists In-Reply-To: <2f9e317b0708292318l43a9aaa2j3b170fe77b1215b@mail.gmail.com> References: <2f9e317b0708290025n46c6accdyb10269a68300c9d7@mail.gmail.com> <200708291722.l7THMCsD037604@possum.icir.org> <2f9e317b0708292318l43a9aaa2j3b170fe77b1215b@mail.gmail.com> Message-ID: <2f9e317b0708292319k34a03ccdk723e7de3beb05777@mail.gmail.com> cc'ing the mailing list. On 8/30/07, Hansi wrote: > > Hello Pavlin, > > I happen to have another policy configuration [policy-statement 'static'] > configured. I'm not sure what actually happened but when I restarted xorp, > the issue was not encountered anymore. I probably misconfigured something > along the way. I'm using version 1.4. > > I happen to encounter an error raised in this mailing list: > > http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2006-July/001336.html > > > Is there a know solution to it already? I'm testing rip in an isolated > environment, is this a factor? > Furthermore, I dont have a 224.0.0.0/4 installed in my routing table > though upon invoking netstat -ia, I happen to see several multicast > addresses. I'm using FreeBSD. > > Thank you. > > On 8/30/07, Pavlin Radoslavov wrote: > > > > > I have 2 boxes running xorp now and I intend to run RIP as a routing > > > protocol. Though I was successful in configuring through the ' > > config.boot' > > > file in the first box. I also intend to configure RIP through the xorp > > > > > command line shell. I was able to successfully commit a policy with > > > policy-statement "static". However, when I tried to commit a > > > policy-statement "connected", I encountered this error: > > > > > > root at hansi-desktop# set policy policy-statement connected term export > > from > > > protocol connected > > > [edit] > > > root at hansi-desktop# commit > > > Commit Failed > > > 102 Command failed create_policy: PolicyMapError from line 45 of > > > policy_map.cc: Can't create policy connected : already exists[edit] > > > > What is your policy configuration before you attempted to add the > > above statement? > > You could use the "show policy" command to print it. > > > > Also, what XORP version are you using? > > > > Thanks, > > Pavlin > > > > > Does this error indicate that the policy 'connected' has been > > implicitly > > > configured already? > > > > > > Would appreciate some assistance. > > > > > > Thanks. > > > _______________________________________________ > > > Xorp-users mailing list > > > Xorp-users at xorp.org > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070830/f3dfad1f/attachment.html From arvind at macil.in Thu Aug 30 02:28:13 2007 From: arvind at macil.in (arvind) Date: Thu, 30 Aug 2007 14:58:13 +0530 Subject: [Xorp-users] how to start dummy_fea Message-ID: <1188466093.7563.2.camel@localhost.localdomain> Hello everyone, while i started my xorp_rtrmgr with a simple program, it automatically starts the xorp_fea. But i need xorp_fea_dummy to be run instead of xorp_fea. can any one give solution for this? From tdurack at gmail.com Thu Aug 30 05:45:32 2007 From: tdurack at gmail.com (Tim Durack) Date: Thu, 30 Aug 2007 08:45:32 -0400 Subject: [Xorp-users] Unreachable default route. In-Reply-To: <46D65AFB.5000000@candelatech.com> References: <200708300547.l7U5lahH043705@possum.icir.org> <46D65AFB.5000000@candelatech.com> Message-ID: <9e246b4d0708300545v62d4a0efp701807d3a12a7e94@mail.gmail.com> On a Cisco you would configure a floating static route - that is a static with a higher administrative distance than a dynamic routing protocol. The static will be overridden by the dynamic, but if the dynamic default goes away, the static will be installed. Not sure if XORP supports this (I don't think you can change admin distance), so this probably doesn't help. Tim:> On 8/30/07, Ben Greear wrote: > Pavlin Radoslavov wrote: > > Ben Greear wrote: > > > > > >> Is there a way to get Xorp to put in an un-reachable default route > >> if no default gateway is known/configured for a particular routing table? > >> This keeps Linux from trying other routing tables (for instance, when you > >> have specified a particular routing table per some rule.) > >> > >> From the command line, you'd do something like: > >> > >> # 100 is the routing table ID > >> ip route add unreachable 0/0 table 100 > >> > > > > It sounds like you need to configure a discard interface, and point > > the default route to that interface. > > > I only want this to exist _IF_ there is no valid default route. So, I > think it would have to > be more dynamic than a config file, since I assume OSPF or similar might > negotiate a > default route (and fail to find one at other times??) > > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From atanu at ICSI.Berkeley.EDU Thu Aug 30 08:40:43 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 30 Aug 2007 08:40:43 -0700 Subject: [Xorp-users] how to start dummy_fea In-Reply-To: Message from arvind of "Thu, 30 Aug 2007 14:58:13 +0530." <1188466093.7563.2.camel@localhost.localdomain> Message-ID: <93743.1188488443@tigger.icir.org> Hi, In the templates directory run this script: -------------------------------------------------- #!/bin/sh for i in * do if grep xorp_fea $i then ed $i <<\EOF 1,$s/xorp_fea/xorp_fea_dummy/g wq EOF fi done -------------------------------------------------- This is part of the script tests/install_templates.sh, by the way we noticed that Fedora Core 5 does not have ed installed. Atanu. >>>>> "arvind" == arvind writes: arvind> Hello everyone, while i started my xorp_rtrmgr with a simple arvind> program, it automatically starts the xorp_fea. But i need arvind> xorp_fea_dummy to be run instead of xorp_fea. arvind> can any one give solution for this? arvind> _______________________________________________ Xorp-users arvind> mailing list Xorp-users at xorp.org arvind> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Thu Aug 30 10:06:56 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 30 Aug 2007 10:06:56 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: Message from "Tim Durack" of "Thu, 30 Aug 2007 08:45:32 EDT." <9e246b4d0708300545v62d4a0efp701807d3a12a7e94@mail.gmail.com> Message-ID: <200708301706.l7UH6uGQ048960@possum.icir.org> Tim Durack wrote: > On a Cisco you would configure a floating static route - that is a > static with a higher administrative distance than a dynamic routing > protocol. The static will be overridden by the dynamic, but if the > dynamic default goes away, the static will be installed. > > Not sure if XORP supports this (I don't think you can change admin > distance), so this probably doesn't help. No, unfortunately XORP doesn't support floating static routes (yet). The RIB itself has already XRL interface to set the admin distance per protocol, but this interface is not used yet, and it will set the admin distance for all routes for a given protocol. If modifying the admin distance for all static routes (so they are less preferred than, say, OSPF) is acceptable to you, the easiest hack is to modify rib/rib.cc (the RIB constructor) and change the "static" entry for _admin_distances to a value that is larger than the dynamic protocols (e.g., 220). Regards, Pavlin > Tim:> > > On 8/30/07, Ben Greear wrote: > > Pavlin Radoslavov wrote: > > > Ben Greear wrote: > > > > > > > > >> Is there a way to get Xorp to put in an un-reachable default route > > >> if no default gateway is known/configured for a particular routing table? > > >> This keeps Linux from trying other routing tables (for instance, when you > > >> have specified a particular routing table per some rule.) > > >> > > >> From the command line, you'd do something like: > > >> > > >> # 100 is the routing table ID > > >> ip route add unreachable 0/0 table 100 > > >> > > > > > > It sounds like you need to configure a discard interface, and point > > > the default route to that interface. > > > > > I only want this to exist _IF_ there is no valid default route. So, I > > think it would have to > > be more dynamic than a config file, since I assume OSPF or similar might > > negotiate a > > default route (and fail to find one at other times??) > > > > Ben > > > > -- > > Ben Greear > > Candela Technologies Inc http://www.candelatech.com > > > > > > _______________________________________________ > > 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 greearb at candelatech.com Thu Aug 30 10:09:51 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 30 Aug 2007 10:09:51 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: <200708211940.l7LJeSwJ078885@possum.icir.org> References: <200708211940.l7LJeSwJ078885@possum.icir.org> Message-ID: <46D6F9DF.70503@candelatech.com> Here's a CVS diff that appears to add BINDTODEVICE support. I still don't have OSPF working properly..but I am not sure if that is related to my configuration or socket binding. Comments welcome. Thanks, Ben Index: fea/data_plane/io/io_ip_socket.cc =================================================================== RCS file: /cvs/xorp/fea/data_plane/io/io_ip_socket.cc,v retrieving revision 1.10 diff -u -r1.10 io_ip_socket.cc --- fea/data_plane/io/io_ip_socket.cc 26 Jul 2007 01:18:40 -0000 1.10 +++ fea/data_plane/io/io_ip_socket.cc 30 Aug 2007 17:04:40 -0000 @@ -1744,8 +1744,8 @@ if ((ifp == NULL) || (vifp == NULL)) { // No vif found. Ignore this packet. XLOG_WARNING("proto_socket_read() failed: " - "RX packet from %s to %s: no vif found", - cstring(src_address), cstring(dst_address)); + "RX packet from %s to %s: no vif found, pif_index: %u", + cstring(src_address), cstring(dst_address), pif_index); return; // Error } if (! (ifp->enabled() || vifp->enabled())) { @@ -2024,6 +2024,25 @@ return (XORP_ERROR); } +#ifndef HOST_OS_WINDOWS + if (if_name.c_str() && if_name.c_str()[0]) { + if (setsockopt(_proto_socket_out, SOL_SOCKET, SO_BINDTODEVICE, + if_name.c_str(), IFNAMSIZ)) { + error_msg += c_format("setsockopt(SO_BINDTODEVICE, %s) failed: %s", + if_name.c_str(), strerror(errno)); + } + } + else { + // Un-bind just in case we were previously bound... + char nl[1]; + nl[0] = 0; + if (setsockopt(_proto_socket_out, SOL_SOCKET, SO_BINDTODEVICE, nl, 0)) { + error_msg += c_format("setsockopt(SO_BINDTODEVICE, NULL) failed: %s", + strerror(errno)); + } + } +#endif + // // Now hook the data // Pavlin Radoslavov wrote: > Ben Greear wrote: > > >>>> I'm sure you'll want to be able to bind the socket to a local IP, but >>>> if you want to leave out the SO_BINDTODEVICE I can test it and see >>>> if it works. I can add the SO_BINDTODEVICE if needed and send you a patch. >>>> >>>> >>> Currently, we don't bind to the local IP (we do but in certain cases >>> only). I believe even if you bind to a local IP you cannot really >>> force the unicast IP packet to exit the system on the particular >>> interface. Anyway, I might be wrong here, so please let me know if >>> you find that bind()-ing only gives us the desired behavior. >>> >>> >> If you set up the routing tables and rules correctly, then binding to a >> local IP >> is probably sufficient. If you are certain that you want the pkt to >> leave by a certain >> interface, then I don't think it can ever hurt to bind to that local IP, >> but just in case, >> it could also be a config option... >> >>> BTW, what protocols are you planning to run? Without SO_BINDTODEVICE >>> we might have to use different solution for each type of >>> sockets/packets: raw IP packets, TCP, UDP. >>> FYI, the I/O system-specific stuff is inside fea/data_plane/io, >>> though io_tcpudp_socket.cc itself uses the xorp/libcomm wrapper >>> library. >>> BGP only doesn't use the FEA (yet) and does its own TCP connection >>> (inside bgp/socket.{hh,cc}). >>> >>> Also, there could be some gotchas with RIP's UDP socket, but lets >>> address first the protocols you are actually going to use. >>> >>> >> At a minimum, I want to support OSPF. However, I'd like to have options to >> do other protocols as well. In my own experience, binding UDP is very >> similar >> to binding TCP, but if you want some sample code I can post it. I'm not >> sure >> about raw IP packets. >> >> Also, for my application, it will always be running on Linux, so I can >> depend on >> SO_BINDTODEVICE being available... >> > > I played a bit with SO_BINDTODEVICE, and here is what I found. > For the record, I am using Gentoo 2006.1 with kernel 2.6.20.1. > > In my test I opened an UDP socket, then used > setsockopt(SO_BINDTODEVICE) to bind the socket to a specific > interface (eth1), and then used sendto() to transmit a single UDP packet. > At the end I am attaching the test program in case someone wants to play > with it. > > * If the destination address belongs to the same network interface > that is used with SO_BINDTODEVICE (eth1), then the transmitted packets > are sent over the loopback interface (lo) instead of the external > (physical) interface (eth1). > > * If the destination address belongs to the same subnet as the > network interface that is used with SO_BINDTODEVICE (eth1), then > an ARP request is sent first by the kernel (as we would expect). > If the ARP is resolved, then the UDP packet should follow. > > * For all other (i.e., remote) destination addresses or IP > addresses that belong to some other interfaces of that host, an > ARP request is sent first by the kernel for the destination > address. If the ARP request is not answered (as it would be the > case for a remote destination unless somebody else is acting as a > proxy), then the UDP transmission will fail. > > >From the above observations, the interesting behavior (at least for > me) is that SO_BINDTODEVICE can be used to force a packet with > destination address that belongs to some other interface of that > host (e.g., eth0) to be transmitted over the specified interface > (eth1). Without SO_BINDTODEVICE such packets are transmitted over > the loopback interface (lo). > > I continued the testing by connecting eth0 directly with eth1, and > then used SO_BINDTODEVICE to see whether the UDP packet will be > actually sent out of interface eth1 to eth0's IP address. > It turned out that the preceding ARP request out of eth1 is never > answered by the eth0 interface (probably the kernel recognizes that > the origin of the ARP is that host itself so the ARP reply is > suppressed). > However, after playing a bit I was able to add the ARP entry by > hand, but it was a bit tricky: > > 1. Added the ARP entry, where xx:xx:xx:xx:xx:xx is the Ethernet > address of eth0. Note that it must be done before configuring > the IP address on eth0: > arp -s 10.0.0.3 xx:xx:xx:xx:xx:xx > > 2. Configure the IP address on eth0: > ip addr add 10.0.0.3/8 dev eth0 > > Finally after that I was able to see the UDP packet going out on > eth1 with destination address the IP address on eth0. > > In conclusion, if you are running 2+ virtual routing instances each > of them with separate forwarding tables in the kernel and a > allocated corresponding subset of the physical interfaces, then it > is possible to use SO_BINDTODEVICE to make sure that unicast packets > transmit by one virtual router are transmit over the physical link > to another virtual router, but it is tricky (see the above ARP > hack). > > However, if we don't care that the unicast packets between the > virtual instances are transmitted over the loopback interface, then > we don't need SO_BINDTODEVICE: just bind(2)-ing to the outgoing > interface's IP address will be sufficient to guarantee the IP source > address is set to the desired value. > > Regards, > Pavlin > > > ------------------------------------------------------------------------ > > /* Test program to play with setsockopt(SO_BINDTODEVICE) on Linux */ > > #include > #include > #include > > #include > #include > #include > > #define MY_INTERFACE_NAME "eth1" > #define MY_LOCAL_ADDR "10.0.0.1" > #define MY_DST_ADDR "10.0.0.3" > > int > main() > { > char ifname[IFNAMSIZ]; > int s; > char data[50]; > struct sockaddr_in sin; > socklen_t sin_len = sizeof(sin); > > /* Init */ > strncpy(ifname, MY_INTERFACE_NAME, IFNAMSIZ); > memset(data, 1, sizeof(data)); > s = socket(AF_INET, SOCK_DGRAM, 0); > > /* Optionally: bind to a local IP address */ > #if 0 > memset(&sin, 0, sizeof(sin)); > sin.sin_family = AF_INET; > sin.sin_port = htons(0); > sin.sin_addr.s_addr = inet_addr(MY_LOCAL_ADDR); > if (bind(s, (struct sockaddr*)&sin, sin_len) != 0) { > perror("bind()"); > exit(1); > } > #endif > > /* Bind to the interface */ > #if 1 > if (setsockopt(s, SOL_SOCKET, SO_BINDTODEVICE, ifname, sizeof(ifname)) > < 0) { > perror("setsockopt(SO_BINDTODEVICE)"); > exit(1); > } > #endif > > /* Set the dest. address and port */ > memset(&sin, 0, sizeof(sin)); > sin.sin_family = AF_INET; > sin.sin_port = htons(5000); > sin.sin_addr.s_addr = inet_addr(MY_DST_ADDR); > > /* Send the packet */ > if (sendto(s, data, sizeof(data), 0, (struct sockaddr*)&sin, sin_len) > < sizeof(data)) { > perror("sendto()"); > exit(1); > } > > exit(0); > } > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Thu Aug 30 10:16:21 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 30 Aug 2007 10:16:21 -0700 Subject: [Xorp-users] policy connected already exists In-Reply-To: Message from Hansi of "Thu, 30 Aug 2007 14:19:45 +0800." <2f9e317b0708292319k34a03ccdk723e7de3beb05777@mail.gmail.com> Message-ID: <200708301716.l7UHGLEv049121@possum.icir.org> Hansi wrote: > > I happen to encounter an error raised in this mailing list: > > > > http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2006-July/001336.html > > > > > > Is there a know solution to it already? I'm testing rip in an isolated > > environment, is this a factor? > > Furthermore, I dont have a 224.0.0.0/4 installed in my routing table > > though upon invoking netstat -ia, I happen to see several multicast > > addresses. I'm using FreeBSD. Were you seeing exactly same error messages: "send_from_multicast_if failed: Network is unreachable" ? The origin of the issue is the FreeBSD kernel, but I don't know whether the behavior has been changed in FreeBSD-current. Bruce, do you have any info on the subject? The simplest work-around is to add 224.0.0.0/4 route to the kernel. It doesn't matter which particular next-hop address you will choose. E.g.: route add 224.0.0.0/4 10.10.10.10 Alternatively, a default static route will also make the issue go away. Regards, Pavlin From pavlin at icir.org Thu Aug 30 11:06:22 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 30 Aug 2007 11:06:22 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables. In-Reply-To: Message from Ben Greear of "Wed, 29 Aug 2007 18:32:45 PDT." <46D61E3D.5060308@candelatech.com> Message-ID: <200708301806.l7UI6MP1049916@possum.icir.org> Ben Greear wrote: > I finally found time to work on this, and it seems like I am making > some good progress! > > I'm using the cvs snapshot from back when you added the custom > routing-table support, and have not patched the code at all to date. > > I see OSPF HELLO messages on the links between my routers, > and it seems the routing tables are set up mostly correct. > > However, I'm still missing something..probably a config file issue. > > Assume I have: > R1 with eth0, eth1 > R2 with eth2, eth3 > > eth1 and eth2 are connected > > eth0 and eth3 are connected to simple subnets of PCs (ie, no OSPF routers) > > In my case, I don't see routes to get to the eth3 network on R1, though I > do see routes to get to the eth2 subnet. > > How do I tell Xorp to treat eth0 and eth3 as subnets and populate routes > properly? Have you enabled OSPF on all interfaces: eth0, eth1, eth2, eth3. This is probably the simplest way to do it. Alternatively, you might need to use policy and export "connected" routes into OSPF. Regards, Pavlin > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Thu Aug 30 11:09:26 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 30 Aug 2007 11:09:26 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: Message from Ben Greear of "Thu, 30 Aug 2007 10:09:51 PDT." <46D6F9DF.70503@candelatech.com> Message-ID: <200708301809.l7UI9QkV049952@possum.icir.org> Ben Greear wrote: > Here's a CVS diff that appears to add BINDTODEVICE support. I still > don't have OSPF > working properly..but I am not sure if that is related to my > configuration or socket binding. > > Comments welcome. I just committed the small delta for the XLOG_WARNING() message itself (with slight variation of the printed output): Revision Changes Path 1.11 +3 -3; commitid: 115a646d7000f7ea6; xorp/fea/data_plane/io/io_ip_socket.cc About the setsockopt(SO_BINDTODEVICE) code itself, I belive it should be moved to the IoIpSocket::proto_socket_transmit() method, because that method is called from several places, and it is the one that actually transmits the packet. Based on earlier analyses, I believe that for transmission purpose setsockopt(SO_BINDTODEVICE) is not needed for multicast packets, because we already set the outgoing interface/vif for such packets. Hence, IoIpSocket::proto_socket_transmit() should be modified like: if (dst_address.is_multicast()) { .... } else { // Unicast-related setting // Your setsockopt(SO_BINDTODEVICE) setting goes here } The SO_BINDTODEVICE code can be isolated with #ifdef SO_BINDTODEVICE .. #endif because it is available only for Linux. Also, you could use "if_name.empty()" to check whether the interface name is empty. Finally, would it work if you replace "nl" with NULL when you try to un-bind. Regards, Pavlin > Thanks, > Ben > > > Index: fea/data_plane/io/io_ip_socket.cc > =================================================================== > RCS file: /cvs/xorp/fea/data_plane/io/io_ip_socket.cc,v > retrieving revision 1.10 > diff -u -r1.10 io_ip_socket.cc > --- fea/data_plane/io/io_ip_socket.cc 26 Jul 2007 01:18:40 -0000 1.10 > +++ fea/data_plane/io/io_ip_socket.cc 30 Aug 2007 17:04:40 -0000 > @@ -1744,8 +1744,8 @@ > if ((ifp == NULL) || (vifp == NULL)) { > // No vif found. Ignore this packet. > XLOG_WARNING("proto_socket_read() failed: " > - "RX packet from %s to %s: no vif found", > - cstring(src_address), cstring(dst_address)); > + "RX packet from %s to %s: no vif found, pif_index: %u", > + cstring(src_address), cstring(dst_address), pif_index); > return; // Error > } > if (! (ifp->enabled() || vifp->enabled())) { > @@ -2024,6 +2024,25 @@ > return (XORP_ERROR); > } > > +#ifndef HOST_OS_WINDOWS > + if (if_name.c_str() && if_name.c_str()[0]) { > + if (setsockopt(_proto_socket_out, SOL_SOCKET, > SO_BINDTODEVICE, > + if_name.c_str(), IFNAMSIZ)) { > + error_msg += c_format("setsockopt(SO_BINDTODEVICE, > %s) failed: %s", > + if_name.c_str(), strerror(errno)); > + } > + } > + else { > + // Un-bind just in case we were previously bound... > + char nl[1]; > + nl[0] = 0; > + if (setsockopt(_proto_socket_out, SOL_SOCKET, > SO_BINDTODEVICE, nl, 0)) { > + error_msg += c_format("setsockopt(SO_BINDTODEVICE, > NULL) failed: %s", > + strerror(errno)); > + } > + } > +#endif > + > // > // Now hook the data > // > > > Pavlin Radoslavov wrote: > > Ben Greear wrote: > > > > > >>>> I'm sure you'll want to be able to bind the socket to a local IP, but > >>>> if you want to leave out the SO_BINDTODEVICE I can test it and see > >>>> if it works. I can add the SO_BINDTODEVICE if needed and send you a patch. > >>>> > >>>> > >>> Currently, we don't bind to the local IP (we do but in certain cases > >>> only). I believe even if you bind to a local IP you cannot really > >>> force the unicast IP packet to exit the system on the particular > >>> interface. Anyway, I might be wrong here, so please let me know if > >>> you find that bind()-ing only gives us the desired behavior. > >>> > >>> > >> If you set up the routing tables and rules correctly, then binding to a > >> local IP > >> is probably sufficient. If you are certain that you want the pkt to > >> leave by a certain > >> interface, then I don't think it can ever hurt to bind to that local IP, > >> but just in case, > >> it could also be a config option... > >> > >>> BTW, what protocols are you planning to run? Without SO_BINDTODEVICE > >>> we might have to use different solution for each type of > >>> sockets/packets: raw IP packets, TCP, UDP. > >>> FYI, the I/O system-specific stuff is inside fea/data_plane/io, > >>> though io_tcpudp_socket.cc itself uses the xorp/libcomm wrapper > >>> library. > >>> BGP only doesn't use the FEA (yet) and does its own TCP connection > >>> (inside bgp/socket.{hh,cc}). > >>> > >>> Also, there could be some gotchas with RIP's UDP socket, but lets > >>> address first the protocols you are actually going to use. > >>> > >>> > >> At a minimum, I want to support OSPF. However, I'd like to have options to > >> do other protocols as well. In my own experience, binding UDP is very > >> similar > >> to binding TCP, but if you want some sample code I can post it. I'm not > >> sure > >> about raw IP packets. > >> > >> Also, for my application, it will always be running on Linux, so I can > >> depend on > >> SO_BINDTODEVICE being available... > >> > > > > I played a bit with SO_BINDTODEVICE, and here is what I found. > > For the record, I am using Gentoo 2006.1 with kernel 2.6.20.1. > > > > In my test I opened an UDP socket, then used > > setsockopt(SO_BINDTODEVICE) to bind the socket to a specific > > interface (eth1), and then used sendto() to transmit a single UDP packet. > > At the end I am attaching the test program in case someone wants to play > > with it. > > > > * If the destination address belongs to the same network interface > > that is used with SO_BINDTODEVICE (eth1), then the transmitted packets > > are sent over the loopback interface (lo) instead of the external > > (physical) interface (eth1). > > > > * If the destination address belongs to the same subnet as the > > network interface that is used with SO_BINDTODEVICE (eth1), then > > an ARP request is sent first by the kernel (as we would expect). > > If the ARP is resolved, then the UDP packet should follow. > > > > * For all other (i.e., remote) destination addresses or IP > > addresses that belong to some other interfaces of that host, an > > ARP request is sent first by the kernel for the destination > > address. If the ARP request is not answered (as it would be the > > case for a remote destination unless somebody else is acting as a > > proxy), then the UDP transmission will fail. > > > > >From the above observations, the interesting behavior (at least for > > me) is that SO_BINDTODEVICE can be used to force a packet with > > destination address that belongs to some other interface of that > > host (e.g., eth0) to be transmitted over the specified interface > > (eth1). Without SO_BINDTODEVICE such packets are transmitted over > > the loopback interface (lo). > > > > I continued the testing by connecting eth0 directly with eth1, and > > then used SO_BINDTODEVICE to see whether the UDP packet will be > > actually sent out of interface eth1 to eth0's IP address. > > It turned out that the preceding ARP request out of eth1 is never > > answered by the eth0 interface (probably the kernel recognizes that > > the origin of the ARP is that host itself so the ARP reply is > > suppressed). > > However, after playing a bit I was able to add the ARP entry by > > hand, but it was a bit tricky: > > > > 1. Added the ARP entry, where xx:xx:xx:xx:xx:xx is the Ethernet > > address of eth0. Note that it must be done before configuring > > the IP address on eth0: > > arp -s 10.0.0.3 xx:xx:xx:xx:xx:xx > > > > 2. Configure the IP address on eth0: > > ip addr add 10.0.0.3/8 dev eth0 > > > > Finally after that I was able to see the UDP packet going out on > > eth1 with destination address the IP address on eth0. > > > > In conclusion, if you are running 2+ virtual routing instances each > > of them with separate forwarding tables in the kernel and a > > allocated corresponding subset of the physical interfaces, then it > > is possible to use SO_BINDTODEVICE to make sure that unicast packets > > transmit by one virtual router are transmit over the physical link > > to another virtual router, but it is tricky (see the above ARP > > hack). > > > > However, if we don't care that the unicast packets between the > > virtual instances are transmitted over the loopback interface, then > > we don't need SO_BINDTODEVICE: just bind(2)-ing to the outgoing > > interface's IP address will be sufficient to guarantee the IP source > > address is set to the desired value. > > > > Regards, > > Pavlin > > > > > > ------------------------------------------------------------------------ > > > > /* Test program to play with setsockopt(SO_BINDTODEVICE) on Linux */ > > > > #include > > #include > > #include > > > > #include > > #include > > #include > > > > #define MY_INTERFACE_NAME "eth1" > > #define MY_LOCAL_ADDR "10.0.0.1" > > #define MY_DST_ADDR "10.0.0.3" > > > > int > > main() > > { > > char ifname[IFNAMSIZ]; > > int s; > > char data[50]; > > struct sockaddr_in sin; > > socklen_t sin_len = sizeof(sin); > > > > /* Init */ > > strncpy(ifname, MY_INTERFACE_NAME, IFNAMSIZ); > > memset(data, 1, sizeof(data)); > > s = socket(AF_INET, SOCK_DGRAM, 0); > > > > /* Optionally: bind to a local IP address */ > > #if 0 > > memset(&sin, 0, sizeof(sin)); > > sin.sin_family = AF_INET; > > sin.sin_port = htons(0); > > sin.sin_addr.s_addr = inet_addr(MY_LOCAL_ADDR); > > if (bind(s, (struct sockaddr*)&sin, sin_len) != 0) { > > perror("bind()"); > > exit(1); > > } > > #endif > > > > /* Bind to the interface */ > > #if 1 > > if (setsockopt(s, SOL_SOCKET, SO_BINDTODEVICE, ifname, sizeof(ifname)) > > < 0) { > > perror("setsockopt(SO_BINDTODEVICE)"); > > exit(1); > > } > > #endif > > > > /* Set the dest. address and port */ > > memset(&sin, 0, sizeof(sin)); > > sin.sin_family = AF_INET; > > sin.sin_port = htons(5000); > > sin.sin_addr.s_addr = inet_addr(MY_DST_ADDR); > > > > /* Send the packet */ > > if (sendto(s, data, sizeof(data), 0, (struct sockaddr*)&sin, sin_len) > > < sizeof(data)) { > > perror("sendto()"); > > exit(1); > > } > > > > exit(0); > > } > > > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Thu Aug 30 11:21:08 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 30 Aug 2007 11:21:08 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: <200708301809.l7UI9QkV049952@possum.icir.org> References: <200708301809.l7UI9QkV049952@possum.icir.org> Message-ID: <46D70A94.5010009@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > >> Here's a CVS diff that appears to add BINDTODEVICE support. I still >> don't have OSPF >> working properly..but I am not sure if that is related to my >> configuration or socket binding. >> >> Comments welcome. > > I just committed the small delta for the XLOG_WARNING() message > itself (with slight variation of the printed output): > > Revision Changes Path > 1.11 +3 -3; commitid: 115a646d7000f7ea6; xorp/fea/data_plane/io/io_ip_socket.cc > > About the setsockopt(SO_BINDTODEVICE) code itself, I belive it > should be moved to the IoIpSocket::proto_socket_transmit() method, > because that method is called from several places, and it is the one > that actually transmits the packet. I can do this. One question: In the comments for send_packet, it says if_name is optional for unicast packets..however it looks like the actual code will error out if the ifp is not found: ifp = iftree().find_interface(if_name); if (ifp == NULL) { error_msg = c_format("No interface %s", if_name.c_str()); return (XORP_ERROR); } I assume the comments are wrong, or maybe the find_interface will grab some random interface if if_name is blank? For the proto_sock_transmit(), I guess I should just get the name from the ifp and bind to that, or would you rather me pass in if_name ? > Based on earlier analyses, I believe that for transmission purpose > setsockopt(SO_BINDTODEVICE) is not needed for multicast packets, > because we already set the outgoing interface/vif for such packets. Ok, I did see multicast pkts on the 'wire' before making my changes, so I think you are right. > Finally, would it work if you replace "nl" with NULL when you try to > un-bind. Doesn't seem "NULL" is valid according to the man page. Evidently you can set the 'length' argument to 0 and have that work, but I wanted to be doubly sure in case other OSs do things slightly different. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Thu Aug 30 12:00:23 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 30 Aug 2007 12:00:23 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: <200708301809.l7UI9QkV049952@possum.icir.org> References: <200708301809.l7UI9QkV049952@possum.icir.org> Message-ID: <46D713C7.9080005@candelatech.com> This appears to be working..my OSPF instances are now in the 'Full' state, and it's adding routes. Unfortunately, it's adding them to the default routing table, as far as I can tell. Will debug that next. Index: data_plane/io/io_ip_socket.cc =================================================================== RCS file: /cvs/xorp/fea/data_plane/io/io_ip_socket.cc,v retrieving revision 1.11 diff -u -r1.11 io_ip_socket.cc --- data_plane/io/io_ip_socket.cc 30 Aug 2007 17:37:51 -0000 1.11 +++ data_plane/io/io_ip_socket.cc 30 Aug 2007 18:58:23 -0000 @@ -2362,6 +2362,33 @@ } #endif // ! IPV4_RAW_INPUT_IS_RAW +#ifdef SO_BINDTODEVICE + // Bind to DEVICE if platform supports it + // NOTE: We have to do the binding for both multicast and unicast because + // otherwise the socket can be left in stale state (bound to whatever interface the last + // packet was sent through. + // Even if it doesn't help multicast much, it doesn't appear to hurt anything. + if (!ifp->ifname().empty()) { + //XLOG_ERROR("will BINDTODEVICE, dev: %s, this: %p src-addr: %s", + // ifp->ifname().c_str(), this, cstring(src_address)); + if (setsockopt(_proto_socket_out, SOL_SOCKET, SO_BINDTODEVICE, + ifp->ifname().c_str(), IFNAMSIZ)) { + error_msg += c_format("setsockopt(SO_BINDTODEVICE, %s) failed: %s", + ifp->ifname().c_str(), strerror(errno)); + } + } + else { + // Un-bind in case we were previously bound... + //XLOG_ERROR("will un-BINDTODEVICE, dev: %s, this: %p src-addr: %s", + // ifp->ifname().c_str(), this, cstring(src_address)); + if (setsockopt(_proto_socket_out, SOL_SOCKET, SO_BINDTODEVICE, + ifp->ifname().c_str(), 0)) { + error_msg += c_format("setsockopt(SO_BINDTODEVICE, NULL) failed: %s", + strerror(errno)); + } + } +#endif + // // Multicast-related setting // -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Thu Aug 30 12:21:10 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 30 Aug 2007 12:21:10 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: <46D713C7.9080005@candelatech.com> References: <200708301809.l7UI9QkV049952@possum.icir.org> <46D713C7.9080005@candelatech.com> Message-ID: <46D718A6.3000500@candelatech.com> Ben Greear wrote: > This appears to be working..my OSPF instances are now in the 'Full' > state, and it's adding routes. Unfortunately, it's adding them to the > default routing table, as far as I can tell. Will debug that next. Looks like my problem is that my build machine doesn't have the latest netlink headers, so the resulting Xorp doesn't support large routing tables... Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Fri Aug 31 09:54:37 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 31 Aug 2007 09:54:37 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: Message from Ben Greear of "Thu, 30 Aug 2007 11:21:08 PDT." <46D70A94.5010009@candelatech.com> Message-ID: <200708311654.l7VGsblA064249@possum.icir.org> > I can do this. One question: In the comments for send_packet, it says > if_name is optional for unicast packets..however it looks like the > actual code will error out if the ifp is not found: > > ifp = iftree().find_interface(if_name); > if (ifp == NULL) { > error_msg = c_format("No interface %s", if_name.c_str()); > return (XORP_ERROR); > } > > I assume the comments are wrong, or maybe the find_interface will grab > some random interface if if_name is blank? Yes, the comments don't match the current processing, because the original semantics were relaxed so for transmitting unicast packets the interface/vif name can be omitted (and let the kernel choose the outgoing interface). We need to rethink that and decide whether to keep the original semantics and fix the code or redefine the semantics. > For the proto_sock_transmit(), I guess I should just get the name from the ifp > and bind to that, or would you rather me pass in if_name ? You could get the name from the vifp. > > Finally, would it work if you replace "nl" with NULL when you try to > > un-bind. > > Doesn't seem "NULL" is valid according to the man page. Evidently you > can set the 'length' argument to 0 and have that work, but I wanted to > be doubly sure in case other OSs do things slightly different. OK, fair enough. Thanks, Pavlin From pavlin at icir.org Fri Aug 31 09:57:24 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 31 Aug 2007 09:57:24 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: Message from Ben Greear of "Thu, 30 Aug 2007 12:21:10 PDT." <46D718A6.3000500@candelatech.com> Message-ID: <200708311657.l7VGvOmo064303@possum.icir.org> > Ben Greear wrote: > > This appears to be working..my OSPF instances are now in the 'Full' > > state, and it's adding routes. Unfortunately, it's adding them to the > > default routing table, as far as I can tell. Will debug that next. > > Looks like my problem is that my build machine doesn't have the latest > netlink headers, so the resulting Xorp doesn't support large routing > tables... For testing purpose did you try to use table ID that is smaller than 255. Such smaller table IDs should work even if you didn't compile with the latest netlink headers. Regards, Pavlin > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Fri Aug 31 09:58:02 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 31 Aug 2007 09:58:02 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: <200708311654.l7VGsblA064249@possum.icir.org> References: <200708311654.l7VGsblA064249@possum.icir.org> Message-ID: <46D8489A.9000400@candelatech.com> Pavlin Radoslavov wrote: >> I can do this. One question: In the comments for send_packet, it says >> if_name is optional for unicast packets..however it looks like the >> actual code will error out if the ifp is not found: >> >> ifp = iftree().find_interface(if_name); >> if (ifp == NULL) { >> error_msg = c_format("No interface %s", if_name.c_str()); >> return (XORP_ERROR); >> } >> >> I assume the comments are wrong, or maybe the find_interface will grab >> some random interface if if_name is blank? >> > > Yes, the comments don't match the current processing, because the > original semantics were relaxed so for transmitting unicast packets > the interface/vif name can be omitted (and let the kernel choose > the outgoing interface). We need to rethink that and decide whether > to keep the original semantics and fix the code or redefine the > semantics. >> For the proto_sock_transmit(), I guess I should just get the name from the ifp >> and bind to that, or would you rather me pass in if_name ? >> > > You could get the name from the vifp. > It was working for me when I used the ifp. What's the difference between vifp and ifp? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Aug 31 09:59:51 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 31 Aug 2007 09:59:51 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: <200708311657.l7VGvOmo064303@possum.icir.org> References: <200708311657.l7VGvOmo064303@possum.icir.org> Message-ID: <46D84907.10908@candelatech.com> Pavlin Radoslavov wrote: >> Ben Greear wrote: >> >>> This appears to be working..my OSPF instances are now in the 'Full' >>> state, and it's adding routes. Unfortunately, it's adding them to the >>> default routing table, as far as I can tell. Will debug that next. >>> >> Looks like my problem is that my build machine doesn't have the latest >> netlink headers, so the resulting Xorp doesn't support large routing >> tables... >> > > For testing purpose did you try to use table ID that is smaller than > 255. > Such smaller table IDs should work even if you didn't compile with > the latest netlink headers. > Late last night I got it to compile against the latest headers and it started working fine, even with large tables 10000, 10001,... Btw, the code should probably do an error message if the router_id is > 255 but it was not compiled for RTA_TABLE support... Thanks, Ben > Regards, > Pavlin > > >> Ben >> >> -- >> Ben Greear >> Candela Technologies Inc http://www.candelatech.com >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Fri Aug 31 10:15:22 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 31 Aug 2007 10:15:22 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: Message from Ben Greear of "Fri, 31 Aug 2007 09:58:02 PDT." <46D8489A.9000400@candelatech.com> Message-ID: <200708311715.l7VHFM0F064681@possum.icir.org> > It was working for me when I used the ifp. What's the difference > between vifp and ifp? The name from ifp and vifp should be same in case of UNIX (in most cases). It might be different when we add support for VLANs, and in that case it might be better if vifp is used instead of ifp. Regards, Pavlin From greearb at candelatech.com Fri Aug 31 10:38:34 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 31 Aug 2007 10:38:34 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: <200708311715.l7VHFM0F064681@possum.icir.org> References: <200708311715.l7VHFM0F064681@possum.icir.org> Message-ID: <46D8521A.4020106@candelatech.com> Pavlin Radoslavov wrote: >> It was working for me when I used the ifp. What's the difference >> between vifp and ifp? > > The name from ifp and vifp should be same in case of UNIX (in most > cases). > It might be different when we add support for VLANs, and in that > case it might be better if vifp is used instead of ifp. What about IP aliases, ie adding two IPs to the same interface? I'm not sure you can BINDTODEVICE on an alias since it is not a real interface (in Linux). Thanks, Ben > > Regards, > Pavlin -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Fri Aug 31 11:38:44 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 31 Aug 2007 11:38:44 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: Message from Ben Greear of "Fri, 31 Aug 2007 09:59:51 PDT." <46D84907.10908@candelatech.com> Message-ID: <200708311838.l7VIci5g065486@possum.icir.org> > Late last night I got it to compile against the latest headers and it > started working > fine, even with large tables 10000, 10001,... Great! > Btw, the code should probably do an error message if the router_id is > > 255 but it was > not compiled for RTA_TABLE support... True, and I had that in mind when added the support for larger route IDs. However, to do so cleanly by preserving the abstraction between the system-specific plugins at the bottom and the rest of the FEA is going to be slightly more complicated. The plan is to add another set of abstraction to the data plane (e.g., "capability" or something like this), and this abstraction can be used to check (during config time) whether the plugin at the bottom will accept the pre-configured router_id value. In other words, the error checking will be added, but not right now. Thanks, Pavlin From pavlin at icir.org Fri Aug 31 11:40:52 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 31 Aug 2007 11:40:52 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: Message from Ben Greear of "Fri, 31 Aug 2007 10:38:34 PDT." <46D8521A.4020106@candelatech.com> Message-ID: <200708311840.l7VIeqtB065546@possum.icir.org> > >> It was working for me when I used the ifp. What's the difference > >> between vifp and ifp? > > > > The name from ifp and vifp should be same in case of UNIX (in most > > cases). > > It might be different when we add support for VLANs, and in that > > case it might be better if vifp is used instead of ifp. > > > What about IP aliases, ie adding two IPs to the same interface? IP aliases go as IP addresses under the vif, but they will still share the original interface name so this shouldn't be the problem. > I'm not sure you can BINDTODEVICE on an alias since it is not a real > interface (in Linux). True. I think that the fact that "ifconfig" on Linux shows them as different interfaces (with different names) is confusing, but we don't do that inside XORP. Regards, Pavlin From Chris.Robson at nrl.navy.mil Fri Aug 31 13:38:22 2007 From: Chris.Robson at nrl.navy.mil (Chris Robson) Date: Fri, 31 Aug 2007 16:38:22 -0400 Subject: [Xorp-users] Module not foudn problem Message-ID: <46D87C3E.7000209@nrl.navy.mil> Anyone now what is missing to cause this not found error? /usr/local/sbin has the file xorp_mld. 2007/08/31 16:33:41 INFO xorp_rtrmgr:666 RTRMGR +96 module_manager.cc execute ] Executing module: mld (mld6igmp/xorp_mld) [ 2007/08/31 16:33:41 WARNING xorp_rtrmgr:666 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "MLD" does not exist or is not enabled. -- Chris