From pavlin at ICSI.Berkeley.EDU Mon Dec 1 10:46:17 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Mon, 01 Dec 2008 10:46:17 -0800 Subject: [Xorp-hackers] XORP and/or Click with an overlay protocol In-Reply-To: <38f1dbe80811280732k221b904cx4db443ef6c0932e2@mail.gmail.com> References: <38f1dbe80811280732k221b904cx4db443ef6c0932e2@mail.gmail.com> Message-ID: <200812011846.mB1IkHoS028166@fruitcake.ICSI.Berkeley.EDU> Victor Faion wrote: > Hello, > > I wanted to use my forwarding engine (which has its own forwarding table) > together with my own protocol (at the application layer, using sockets) with > XORP. I wasn't sure if it's better to implement a separate process that > interacts with XORP's FEA (this would be the forwarding engine) and another > process that represents the protocol or if I should implement all of this > using Click and then plug it into XORP (or just use it only with Click). In > other words, how much of XORP's code I would need to change to do this and > would it be easier to do it in Click or to use both? Without additional info about your protocol it is difficult to give you advice that will fit best your specific needs. If I make the assumption that your control protocol is similar to, say, OSPF or RIP, my generalized advice would be to implement your control protocol as a separate process that interacts with the XORP FEA. If you don't have any specific requirements, you shouldn't need any additional changes to XORP. Re. your question of XORP vs. Click. >From XORP's perspective, Click is an IPv4/IPv6 data plane, though Click itself is much more than that. Hence, if you implement your protocol in XORP, the "shall I use XORP+Click" question becomes a question of whether you want to use Click as the IPv4/IPv6 data plane. On the other hand, if you have a relatively simple protocol with some unusual requirements (say, it requires tight integration with the data plane), and the existing UNIX kernel API is not sufficient, you might be able to save time getting the initial prototype working if you use only Click. Hope that helps, Pavlin > Victor > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From vfaion at gmail.com Wed Dec 3 15:18:35 2008 From: vfaion at gmail.com (Victor Faion) Date: Wed, 3 Dec 2008 23:18:35 +0000 Subject: [Xorp-hackers] XORP and/or Click with an overlay protocol In-Reply-To: <200812011846.mB1IkHoS028166@fruitcake.ICSI.Berkeley.EDU> References: <38f1dbe80811280732k221b904cx4db443ef6c0932e2@mail.gmail.com> <200812011846.mB1IkHoS028166@fruitcake.ICSI.Berkeley.EDU> Message-ID: <38f1dbe80812031518l2d7d16e7g140dcc1441cb099f@mail.gmail.com> On Mon, Dec 1, 2008 at 18:46, Pavlin Radoslavov wrote: > Victor Faion wrote: > > > Hello, > > > > I wanted to use my forwarding engine (which has its own forwarding table) > > together with my own protocol (at the application layer, using sockets) > with > > XORP. I wasn't sure if it's better to implement a separate process that > > interacts with XORP's FEA (this would be the forwarding engine) and > another > > process that represents the protocol or if I should implement all of this > > using Click and then plug it into XORP (or just use it only with Click). > In > > other words, how much of XORP's code I would need to change to do this > and > > would it be easier to do it in Click or to use both? > > Without additional info about your protocol it is difficult to give > you advice that will fit best your specific needs. > > If I make the assumption that your control protocol is similar to, say, > OSPF or RIP, my generalized advice would be to implement your > control protocol as a separate process that interacts with the XORP > FEA. If you don't have any specific requirements, you shouldn't need > any additional changes to XORP. > > > Re. your question of XORP vs. Click. > From XORP's perspective, Click is an IPv4/IPv6 data plane, > though Click itself is much more than that. > Hence, if you implement your protocol in XORP, the "shall I use > XORP+Click" question becomes a question of whether you want to use > Click as the IPv4/IPv6 data plane. > On the other hand, if you have a relatively simple protocol with > some unusual requirements (say, it requires tight integration with > the data plane), and the existing UNIX kernel API is not sufficient, > you might be able to save time getting the initial prototype working > if you use only Click. > > Hope that helps, > Pavlin > > > > > Victor > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > Hello, Thank you for the response, the control protocol is a link-state routing protocol. It uses LSR but also needs to associate additional information with hosts and this is why I think I might need to make another XORP process for this protocol, and I think its easier to plug in a new protocol into XORP rather than Click. As for using Click as the data plane, I could make my forwarding table as a Click element, or would it be simpler to do it as a separate XORP process without relying on Click? Victor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20081203/938d63d9/attachment.html From pavlin at ICSI.Berkeley.EDU Wed Dec 3 16:41:09 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 03 Dec 2008 16:41:09 -0800 Subject: [Xorp-hackers] XORP and/or Click with an overlay protocol In-Reply-To: <38f1dbe80812031518l2d7d16e7g140dcc1441cb099f@mail.gmail.com> References: <38f1dbe80811280732k221b904cx4db443ef6c0932e2@mail.gmail.com> <200812011846.mB1IkHoS028166@fruitcake.ICSI.Berkeley.EDU> <38f1dbe80812031518l2d7d16e7g140dcc1441cb099f@mail.gmail.com> Message-ID: <200812040041.mB40f95B007666@fruitcake.ICSI.Berkeley.EDU> Victor Faion wrote: > On Mon, Dec 1, 2008 at 18:46, Pavlin Radoslavov wrote: > > > Victor Faion wrote: > > > > > Hello, > > > > > > I wanted to use my forwarding engine (which has its own forwarding table) > > > together with my own protocol (at the application layer, using sockets) > > with > > > XORP. I wasn't sure if it's better to implement a separate process that > > > interacts with XORP's FEA (this would be the forwarding engine) and > > another > > > process that represents the protocol or if I should implement all of this > > > using Click and then plug it into XORP (or just use it only with Click). > > In > > > other words, how much of XORP's code I would need to change to do this > > and > > > would it be easier to do it in Click or to use both? > > > > Without additional info about your protocol it is difficult to give > > you advice that will fit best your specific needs. > > > > If I make the assumption that your control protocol is similar to, say, > > OSPF or RIP, my generalized advice would be to implement your > > control protocol as a separate process that interacts with the XORP > > FEA. If you don't have any specific requirements, you shouldn't need > > any additional changes to XORP. > > > > > > Re. your question of XORP vs. Click. > > From XORP's perspective, Click is an IPv4/IPv6 data plane, > > though Click itself is much more than that. > > Hence, if you implement your protocol in XORP, the "shall I use > > XORP+Click" question becomes a question of whether you want to use > > Click as the IPv4/IPv6 data plane. > > On the other hand, if you have a relatively simple protocol with > > some unusual requirements (say, it requires tight integration with > > the data plane), and the existing UNIX kernel API is not sufficient, > > you might be able to save time getting the initial prototype working > > if you use only Click. > > > > Hope that helps, > > Pavlin > > > > > > > > > Victor > > > _______________________________________________ > > > Xorp-hackers mailing list > > > Xorp-hackers at icir.org > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > > Hello, > > Thank you for the response, the control protocol is a link-state routing > protocol. It uses LSR but also needs to associate additional information > with hosts and this is why I think I might need to make another XORP process > for this protocol, and I think its easier to plug in a new protocol into > XORP rather than Click. > > As for using Click as the data plane, I could make my forwarding table as a > Click element, or would it be simpler to do it as a separate XORP process > without relying on Click? If it is just a routing protocol you don't need Click. It will be simpler if you use the existing UNIX kernel forwarding, and implement LSR as a separate XORP process. Pavlin > Victor > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From vfaion at gmail.com Thu Dec 4 02:48:09 2008 From: vfaion at gmail.com (Victor Faion) Date: Thu, 4 Dec 2008 10:48:09 +0000 Subject: [Xorp-hackers] XORP and/or Click with an overlay protocol In-Reply-To: <200812040041.mB40f95B007666@fruitcake.ICSI.Berkeley.EDU> References: <38f1dbe80811280732k221b904cx4db443ef6c0932e2@mail.gmail.com> <200812011846.mB1IkHoS028166@fruitcake.ICSI.Berkeley.EDU> <38f1dbe80812031518l2d7d16e7g140dcc1441cb099f@mail.gmail.com> <200812040041.mB40f95B007666@fruitcake.ICSI.Berkeley.EDU> Message-ID: <38f1dbe80812040248r181cb3bbya7a0f0aff273b6d4@mail.gmail.com> OK I will try to implement it the way you suggested. Thank you for all the help, I'm sure I'll be back with more questions :) Victor On Thu, Dec 4, 2008 at 00:41, Pavlin Radoslavov wrote: > Victor Faion wrote: > >> On Mon, Dec 1, 2008 at 18:46, Pavlin Radoslavov wrote: >> >> > Victor Faion wrote: >> > >> > > Hello, >> > > >> > > I wanted to use my forwarding engine (which has its own forwarding table) >> > > together with my own protocol (at the application layer, using sockets) >> > with >> > > XORP. I wasn't sure if it's better to implement a separate process that >> > > interacts with XORP's FEA (this would be the forwarding engine) and >> > another >> > > process that represents the protocol or if I should implement all of this >> > > using Click and then plug it into XORP (or just use it only with Click). >> > In >> > > other words, how much of XORP's code I would need to change to do this >> > and >> > > would it be easier to do it in Click or to use both? >> > >> > Without additional info about your protocol it is difficult to give >> > you advice that will fit best your specific needs. >> > >> > If I make the assumption that your control protocol is similar to, say, >> > OSPF or RIP, my generalized advice would be to implement your >> > control protocol as a separate process that interacts with the XORP >> > FEA. If you don't have any specific requirements, you shouldn't need >> > any additional changes to XORP. >> > >> > >> > Re. your question of XORP vs. Click. >> > From XORP's perspective, Click is an IPv4/IPv6 data plane, >> > though Click itself is much more than that. >> > Hence, if you implement your protocol in XORP, the "shall I use >> > XORP+Click" question becomes a question of whether you want to use >> > Click as the IPv4/IPv6 data plane. >> > On the other hand, if you have a relatively simple protocol with >> > some unusual requirements (say, it requires tight integration with >> > the data plane), and the existing UNIX kernel API is not sufficient, >> > you might be able to save time getting the initial prototype working >> > if you use only Click. >> > >> > Hope that helps, >> > Pavlin >> > >> > >> > >> > > Victor >> > > _______________________________________________ >> > > Xorp-hackers mailing list >> > > Xorp-hackers at icir.org >> > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers >> > >> >> >> >> Hello, >> >> Thank you for the response, the control protocol is a link-state routing >> protocol. It uses LSR but also needs to associate additional information >> with hosts and this is why I think I might need to make another XORP process >> for this protocol, and I think its easier to plug in a new protocol into >> XORP rather than Click. >> >> As for using Click as the data plane, I could make my forwarding table as a >> Click element, or would it be simpler to do it as a separate XORP process >> without relying on Click? > > If it is just a routing protocol you don't need Click. It will be > simpler if you use the existing UNIX kernel forwarding, and > implement LSR as a separate XORP process. > > Pavlin > > >> Victor >> _______________________________________________ >> Xorp-hackers mailing list >> Xorp-hackers at icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From eshe168 at gmail.com Thu Dec 4 22:51:42 2008 From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=) Date: Fri, 5 Dec 2008 14:51:42 +0800 Subject: [Xorp-hackers] About timeout in Debug. Message-ID: <56f9e0990812042251x31b279d2l85032d0893cfd745@mail.gmail.com> Hi, all When I use gdb to debug a process in the Debian, I found there are some timeout information in xorp_rtrmgr. Then I can not go on debuging the process. Could you give me a clue to avoid it. -- Best Regard Xiaoshuai Yang From atanu at xorp.org Fri Dec 5 08:41:26 2008 From: atanu at xorp.org (Atanu Ghosh) Date: Fri, 05 Dec 2008 08:41:26 -0800 Subject: [Xorp-hackers] About timeout in Debug. In-Reply-To: Message from "=?GB2312?B?0e7Qocun?=" of "Fri, 05 Dec 2008 14:51:42 +0800." <56f9e0990812042251x31b279d2l85032d0893cfd745@mail.gmail.com> Message-ID: <27969.1228495286@xorps.icir.org> Hi, XORP needs to track the state of its processes. Part of this tracking involves exchanging keepalive messages between the FINDER (a component in the RTRMGR) and all the other processes. If the RTRMGR is single stepped using a debugger then the keepalive messages cannot be exchanged, hence the problem that you are seeing. This is a common problem when attempting to debug a procss that is communicating with another process. There is no simple way to avoid the problem. If by using a debugger you stop the RTRMGR from running for too long the system will fail. If you understand this then you can set breakpoints debug the piece of interest and then restart XORP. Atanu. >>>>> "eshe168" == eshe168 writes: eshe168> Hi, all When I use gdb to debug a process in the Debian, I eshe168> found there are some timeout information in eshe168> xorp_rtrmgr. Then I can not go on debuging the process. eshe168> Could you give me a clue to avoid it. eshe168> -- Best Regard Xiaoshuai Yang eshe168> _______________________________________________ eshe168> Xorp-hackers mailing list Xorp-hackers at icir.org eshe168> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From jiaqing.du at gmail.com Sat Dec 6 14:10:51 2008 From: jiaqing.du at gmail.com (Jiaqing Du) Date: Sat, 6 Dec 2008 23:10:51 +0100 Subject: [Xorp-hackers] OSPF Problem with Running Multiple Instances of XORP Message-ID: Hi, List I'm trying to run multiple instances of XORP(v1.5) inside one Linux OS. I have set up several virtual network interfaces using VLAN. Multiple instances of XORP run on top of these virtual interfaces. The problem is OSPF processes can't communicate with each other because OSPF Hello multicast messages are not able to reach other virtual interfaces. I just started to read code related to FEA. Could anyone give me a hint about this problem? What I have done is listed below. (1) add virtual interfaces to the system (Debian with kernel 2.6.19) #vconfig add eth0 2 #vconfig add eth0 3 Network configuration is like this: #ifconfig eth0 Link encap:Ethernet HWaddr 00:0C:29:A6:16:EC inet addr:193.168.0.3 Bcast:193.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fea6:16ec/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:116443 errors:0 dropped:0 overruns:0 frame:0 TX packets:87493 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:61967657 (59.0 MiB) TX bytes:53828956 (51.3 MiB) Interrupt:16 Base address:0x2000 eth0.2 Link encap:Ethernet HWaddr 00:0C:29:A6:16:EC inet addr:10.0.0.3 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fea6:16ec/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:250 (250.0 b) eth0.3 Link encap:Ethernet HWaddr 00:0C:29:A6:16:EC inet addr:10.0.1.3 Bcast:10.0.1.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fea6:16ec/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:250 (250.0 b) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:432974 errors:0 dropped:0 overruns:0 frame:0 TX packets:432974 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:83683923 (79.8 MiB) TX bytes:83683923 (79.8 MiB) (2) configuration files for two different XORP instances. [configuration 1] interfaces { interface eth0.2 { vif eth0.2 { address 10.0.0.3 { prefix-length: 24 } } } interface eth0.3 { vif eth0.3 { address 10.0.1.3 { prefix-length: 24 } } } interface eth0 { vif eth0 { address 193.168.0.3 { prefix-length: 24 } } } } fea { unicast-forwarding4 { disable: false } } protocols { ospf4 { router-id: 10.0.0.3 area 0.0.0.0 { interface eth0.2 { link-type: "p2p" vif eth0.2 { address 10.0.0.3 { hello-interval: 5 router-dead-interval: 10 interface-cost: 2 neighbor 10.0.1.3 { router-id: 10.0.1.3 } } } } } } } [configuration 2] interfaces { interface eth0.3 { vif eth0.3 { address 10.0.1.3 { prefix-length: 24 } } } interface eth0.2 { vif eth0.2 { address 10.0.0.3 { prefix-length: 24 } } } interface eth0 { vif eth0 { address 193.168.0.3 { prefix-length: 24 } } } } fea { unicast-forwarding4 { disable: false } } protocols { ospf4 { router-id: 10.0.1.3 area 0.0.0.0 { interface eth0.3 { link-type: "p2p" vif eth0.3 { address 10.0.1.3 { hello-interval: 5 router-dead-interval: 10 interface-cost: 2 neighbor 10.0.0.3 { router-id: 10.0.0.3 } } } } } } } (3) output of XORP instances At line 1765 of $xorp/fea/data_plane/io/io_ip_socket.cc, inside functioin "IoIpSocket::proto_socket_read()", I add following code to print out packet recv information. +----------+ XLOG_WARNING("packet received"); XLOG_WARNING("ifname = %s, vifname = %s", (ifp->ifname()).c_str(), (vifp->vifname()).c_str()); XLOG_WARNING("src_addr = %s, dst_addr = %s", (src_address.str()).c_str(), (dst_address.str()).c_str()); XLOG_WARNING("---------------------------------------"); +---------+ After running two XORP instances simultaneously, I got the following output. [instance 1 on eth0.2(10.0.0.3)] [ 2008/12/06 10:19:18 WARNING xorp_fea FEA ] packet received [ 2008/12/06 10:19:18 WARNING xorp_fea FEA ] ifname = eth0.2, vifname = eth0.2 [ 2008/12/06 10:19:18 WARNING xorp_fea FEA ] src_addr = 10.0.0.3, dst_addr = 224.0.0.5 [ 2008/12/06 10:19:18 WARNING xorp_fea FEA ] --------------------------------------- [ 2008/12/06 10:19:22 WARNING xorp_fea FEA ] packet received [ 2008/12/06 10:19:22 WARNING xorp_fea FEA ] ifname = eth0.2, vifname = eth0.2 [ 2008/12/06 10:19:22 WARNING xorp_fea FEA ] src_addr = 10.0.0.3, dst_addr = 224.0.0.5 [ 2008/12/06 10:19:22 WARNING xorp_fea FEA ] --------------------------------------- [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] packet received [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] ifname = eth0.3, vifname = eth0.3 [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] src_addr = 10.0.1.3, dst_addr = 224.0.0.5 [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] --------------------------------------- [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] packet received [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] ifname = eth0.2, vifname = eth0.2 [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] src_addr = 10.0.0.3, dst_addr = 224.0.0.5 [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] --------------------------------------- [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] packet received [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] ifname = eth0.3, vifname = eth0.3 [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] src_addr = 10.0.1.3, dst_addr = 224.0.0.5 [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] --------------------------------------- [instance 2 on eth0.3(10.0.1.3)] [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] packet received [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] ifname = eth0.3, vifname = eth0.3 [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] src_addr = 10.0.1.3, dst_addr = 224.0.0.5 [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] --------------------------------------- [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] packet received [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] ifname = eth0.2, vifname = eth0.2 [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] src_addr = 10.0.0.3, dst_addr = 224.0.0.5 [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] --------------------------------------- [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] packet received [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] ifname = eth0.3, vifname = eth0.3 [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] src_addr = 10.0.1.3, dst_addr = 224.0.0.5 [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] --------------------------------------- [ 2008/12/06 10:19:32 WARNING xorp_fea FEA ] packet received [ 2008/12/06 10:19:32 WARNING xorp_fea FEA ] ifname = eth0.2, vifname = eth0.2 [ 2008/12/06 10:19:32 WARNING xorp_fea FEA ] src_addr = 10.0.0.3, dst_addr = 224.0.0.5 [ 2008/12/06 10:19:32 WARNING xorp_fea FEA ] --------------------------------------- [ 2008/12/06 10:19:33 WARNING xorp_fea FEA ] packet received [ 2008/12/06 10:19:33 WARNING xorp_fea FEA ] ifname = eth0.3, vifname = eth0.3 [ 2008/12/06 10:19:33 WARNING xorp_fea FEA ] src_addr = 10.0.1.3, dst_addr = 224.0.0.5 [ 2008/12/06 10:19:33 WARNING xorp_fea FEA ] --------------------------------------- The status of ospf neighbor is: [instance 1 on eth0.2] admin at debian> show ospf4 neighbor Address Interface State ID Pri Dead 10.0.1.3 eth0.2/eth0.2 Init 10.0.1.3 0 0 [instance 2 on eth0.3] admin at debian> show ospf4 neighbor Address Interface State ID Pri Dead 10.0.0.3 eth0.3/eth0.3 Init 10.0.0.3 0 0 Based on the above output, it seems that OSPF Hello multicast message never reaches the corresponding receiver sides. They are just sent back to where they come from. Regards, Jiaqing -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20081206/1957fa34/attachment.html From pavlin at ICSI.Berkeley.EDU Sat Dec 6 14:28:08 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Sat, 06 Dec 2008 14:28:08 -0800 Subject: [Xorp-hackers] OSPF Problem with Running Multiple Instances of XORP In-Reply-To: References: Message-ID: <200812062228.mB6MS9c6027180@fruitcake.ICSI.Berkeley.EDU> In Linux interface name like "eth0.2" is not real interface, but an IP alias address on interface eth0. Hence, in your XORP config the interface/vif name should be eth0, and have the corresponding IP aliases within the vif block. Pavlin Jiaqing Du wrote: > Hi, List > > I'm trying to run multiple instances of XORP(v1.5) inside one Linux OS. > > I have set up several virtual network interfaces using VLAN. Multiple > instances of XORP run on top of these virtual interfaces. > > The problem is OSPF processes can't communicate with each other because OSPF > Hello multicast messages are not able to reach other virtual interfaces. > > I just started to read code related to FEA. Could anyone give me a hint > about > this problem? > > What I have done is listed below. > > (1) add virtual interfaces to the system (Debian with kernel 2.6.19) > > #vconfig add eth0 2 > #vconfig add eth0 3 > > Network configuration is like this: > > #ifconfig > eth0 Link encap:Ethernet HWaddr 00:0C:29:A6:16:EC > inet addr:193.168.0.3 Bcast:193.168.0.255 Mask:255.255.255.0 > inet6 addr: fe80::20c:29ff:fea6:16ec/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:116443 errors:0 dropped:0 overruns:0 frame:0 > TX packets:87493 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:61967657 (59.0 MiB) TX bytes:53828956 (51.3 MiB) > Interrupt:16 Base address:0x2000 > > eth0.2 Link encap:Ethernet HWaddr 00:0C:29:A6:16:EC > inet addr:10.0.0.3 Bcast:10.0.0.255 Mask:255.255.255.0 > inet6 addr: fe80::20c:29ff:fea6:16ec/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:250 (250.0 b) > > eth0.3 Link encap:Ethernet HWaddr 00:0C:29:A6:16:EC > inet addr:10.0.1.3 Bcast:10.0.1.255 Mask:255.255.255.0 > inet6 addr: fe80::20c:29ff:fea6:16ec/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:250 (250.0 b) > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:432974 errors:0 dropped:0 overruns:0 frame:0 > TX packets:432974 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:83683923 (79.8 MiB) TX bytes:83683923 (79.8 MiB) > > > (2) configuration files for two different XORP instances. > > [configuration 1] > interfaces { > interface eth0.2 { > vif eth0.2 { > address 10.0.0.3 { > prefix-length: 24 > } > } > } > interface eth0.3 { > vif eth0.3 { > address 10.0.1.3 { > prefix-length: 24 > } > } > } > interface eth0 { > vif eth0 { > address 193.168.0.3 { > prefix-length: 24 > } > } > } > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > protocols { > ospf4 { > router-id: 10.0.0.3 > area 0.0.0.0 { > interface eth0.2 { > link-type: "p2p" > vif eth0.2 { > address 10.0.0.3 { > hello-interval: 5 > router-dead-interval: 10 > interface-cost: 2 > neighbor 10.0.1.3 { > router-id: 10.0.1.3 > } > } > } > } > } > } > } > > [configuration 2] > interfaces { > interface eth0.3 { > vif eth0.3 { > address 10.0.1.3 { > prefix-length: 24 > } > } > } > interface eth0.2 { > vif eth0.2 { > address 10.0.0.3 { > prefix-length: 24 > } > } > } > interface eth0 { > vif eth0 { > address 193.168.0.3 { > prefix-length: 24 > } > } > } > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > protocols { > ospf4 { > router-id: 10.0.1.3 > area 0.0.0.0 { > interface eth0.3 { > link-type: "p2p" > vif eth0.3 { > address 10.0.1.3 { > hello-interval: 5 > router-dead-interval: 10 > interface-cost: 2 > neighbor 10.0.0.3 { > router-id: 10.0.0.3 > } > } > } > } > > } > } > } > > (3) output of XORP instances > At line 1765 of $xorp/fea/data_plane/io/io_ip_socket.cc, inside functioin > "IoIpSocket::proto_socket_read()", I add following code to print out packet > recv information. > > +----------+ > XLOG_WARNING("packet received"); > XLOG_WARNING("ifname = %s, vifname = %s", (ifp->ifname()).c_str(), > (vifp->vifname()).c_str()); > XLOG_WARNING("src_addr = %s, dst_addr = %s", > (src_address.str()).c_str(), (dst_address.str()).c_str()); > XLOG_WARNING("---------------------------------------"); > +---------+ > > After running two XORP instances simultaneously, I got the following output. > > [instance 1 on eth0.2(10.0.0.3)] > [ 2008/12/06 10:19:18 WARNING xorp_fea FEA ] packet received > [ 2008/12/06 10:19:18 WARNING xorp_fea FEA ] ifname = eth0.2, vifname = > eth0.2 > [ 2008/12/06 10:19:18 WARNING xorp_fea FEA ] src_addr = 10.0.0.3, dst_addr = > 224.0.0.5 > [ 2008/12/06 10:19:18 WARNING xorp_fea FEA ] > --------------------------------------- > [ 2008/12/06 10:19:22 WARNING xorp_fea FEA ] packet received > [ 2008/12/06 10:19:22 WARNING xorp_fea FEA ] ifname = eth0.2, vifname = > eth0.2 > [ 2008/12/06 10:19:22 WARNING xorp_fea FEA ] src_addr = 10.0.0.3, dst_addr = > 224.0.0.5 > [ 2008/12/06 10:19:22 WARNING xorp_fea FEA ] > --------------------------------------- > [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] packet received > [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] ifname = eth0.3, vifname = > eth0.3 > [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] src_addr = 10.0.1.3, dst_addr = > 224.0.0.5 > [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] > --------------------------------------- > [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] packet received > [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] ifname = eth0.2, vifname = > eth0.2 > [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] src_addr = 10.0.0.3, dst_addr = > 224.0.0.5 > [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] > --------------------------------------- > [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] packet received > [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] ifname = eth0.3, vifname = > eth0.3 > [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] src_addr = 10.0.1.3, dst_addr = > 224.0.0.5 > [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] > --------------------------------------- > > [instance 2 on eth0.3(10.0.1.3)] > [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] packet received > [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] ifname = eth0.3, vifname = > eth0.3 > [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] src_addr = 10.0.1.3, dst_addr = > 224.0.0.5 > [ 2008/12/06 10:19:23 WARNING xorp_fea FEA ] > --------------------------------------- > [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] packet received > [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] ifname = eth0.2, vifname = > eth0.2 > [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] src_addr = 10.0.0.3, dst_addr = > 224.0.0.5 > [ 2008/12/06 10:19:27 WARNING xorp_fea FEA ] > --------------------------------------- > [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] packet received > [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] ifname = eth0.3, vifname = > eth0.3 > [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] src_addr = 10.0.1.3, dst_addr = > 224.0.0.5 > [ 2008/12/06 10:19:28 WARNING xorp_fea FEA ] > --------------------------------------- > [ 2008/12/06 10:19:32 WARNING xorp_fea FEA ] packet received > [ 2008/12/06 10:19:32 WARNING xorp_fea FEA ] ifname = eth0.2, vifname = > eth0.2 > [ 2008/12/06 10:19:32 WARNING xorp_fea FEA ] src_addr = 10.0.0.3, dst_addr = > 224.0.0.5 > [ 2008/12/06 10:19:32 WARNING xorp_fea FEA ] > --------------------------------------- > [ 2008/12/06 10:19:33 WARNING xorp_fea FEA ] packet received > [ 2008/12/06 10:19:33 WARNING xorp_fea FEA ] ifname = eth0.3, vifname = > eth0.3 > [ 2008/12/06 10:19:33 WARNING xorp_fea FEA ] src_addr = 10.0.1.3, dst_addr = > 224.0.0.5 > [ 2008/12/06 10:19:33 WARNING xorp_fea FEA ] > --------------------------------------- > > > The status of ospf neighbor is: > > [instance 1 on eth0.2] > admin at debian> show ospf4 neighbor > Address Interface State ID Pri Dead > 10.0.1.3 eth0.2/eth0.2 Init 10.0.1.3 0 0 > > [instance 2 on eth0.3] > admin at debian> show ospf4 neighbor > Address Interface State ID Pri Dead > 10.0.0.3 eth0.3/eth0.3 Init 10.0.0.3 0 0 > > Based on the above output, it seems that OSPF Hello multicast message never > reaches the corresponding receiver sides. They are just sent back to where > they > come from. > > > Regards, > Jiaqing > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From greearb at candelatech.com Sat Dec 6 19:35:44 2008 From: greearb at candelatech.com (Ben Greear) Date: Sat, 06 Dec 2008 19:35:44 -0800 Subject: [Xorp-hackers] OSPF Problem with Running Multiple Instances of XORP In-Reply-To: <200812062228.mB6MS9c6027180@fruitcake.ICSI.Berkeley.EDU> References: <200812062228.mB6MS9c6027180@fruitcake.ICSI.Berkeley.EDU> Message-ID: <493B4490.5000904@candelatech.com> Pavlin Radoslavov wrote: > In Linux interface name like "eth0.2" is not real interface, but > an IP alias address on interface eth0. > Hence, in your XORP config the interface/vif name should be eth0, > and have the corresponding IP aliases within the vif block. > ethX.Y can be an 802.1Q VLAN naming configuration, and he mentions using vconfig, so at least that part of his config should work OK. >> The problem is OSPF processes can't communicate with each other because OSPF >> Hello multicast messages are not able to reach other virtual interfaces. >> Two VLAN devices on the same ethernet port cannot talk to each other because pkts transmitted out that physical interface will not normally be returned. They will NOT be routed to other local VLAN interfaces by the local OS. If you want two XORPs to talk to each other on the same machine, you will also need clever routing table rules and linux patches, use something like the 'veth' driver or redirdev (in my kernel tree only), and so forth. We (Candela Technologies) have a product that sets up everything, but it's not normally free unless you are a student working on your own hardware. Each individual piece of getting this to work isn't so hard, but there are a lot of details, so I can't really explain it all in any detail. If you just want two XORPs to run on the same system, but NOT talk to each other, then that is probably easier and shouldn't require any kernel patches or overly complex routing table rules. Our kernel and xorp can be obtained with the commands below (no passwords required, should be read-only). I just checked these...I sent out bad syntax that required ssh access in the past, so use this instead: git clone git://dmz1.candelatech.com/xorp.git git clone git://dmz1.candelatech.com/linux-2.6.dev.25.git Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at ICSI.Berkeley.EDU Sat Dec 6 22:00:56 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Sat, 06 Dec 2008 22:00:56 -0800 Subject: [Xorp-hackers] OSPF Problem with Running Multiple Instances of XORP In-Reply-To: <493B4490.5000904@candelatech.com> References: <200812062228.mB6MS9c6027180@fruitcake.ICSI.Berkeley.EDU> <493B4490.5000904@candelatech.com> Message-ID: <200812070600.mB760u52021491@fruitcake.ICSI.Berkeley.EDU> Ben Greear wrote: > Pavlin Radoslavov wrote: > > In Linux interface name like "eth0.2" is not real interface, but > > an IP alias address on interface eth0. > > Hence, in your XORP config the interface/vif name should be eth0, > > and have the corresponding IP aliases within the vif block. > > > > ethX.Y can be an 802.1Q VLAN naming configuration, and he mentions > using vconfig, so at least that part of his config should work OK. Yes, you are right. There were so many "IP aliases" cases of "ethX.Y" in the past so I did a FAQ reply :) Pavlin From eshe168 at gmail.com Tue Dec 9 18:57:58 2008 From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=) Date: Wed, 10 Dec 2008 10:57:58 +0800 Subject: [Xorp-hackers] About compile with snmp! Message-ID: <56f9e0990812091857p764c0162g1d6defd751f22579@mail.gmail.com> Hi, all When I compile Xorp with snmp, I have something wrong. The error information is follow: /usr/bin/ld: ../libxipc/.libs/libxipc.a(hmac_md5.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC ../libxipc/.libs/libxipc.a(hmac_md5.o): could not read symbols: Bad value My OS is Debian. Net-snmp version is 5.4. How can I resolve it, please? -- Best Regard Xiaoshuai Yang From pavlin at ICSI.Berkeley.EDU Tue Dec 9 23:08:33 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 09 Dec 2008 23:08:33 -0800 Subject: [Xorp-hackers] About compile with snmp! In-Reply-To: <56f9e0990812091857p764c0162g1d6defd751f22579@mail.gmail.com> References: <56f9e0990812091857p764c0162g1d6defd751f22579@mail.gmail.com> Message-ID: <200812100708.mBA78Xat025790@fruitcake.ICSI.Berkeley.EDU> ??? wrote: > Hi, all > > When I compile Xorp with snmp, I have something wrong. > The error information is follow: > /usr/bin/ld: ../libxipc/.libs/libxipc.a(hmac_md5.o): relocation > R_X86_64_32S against `a local symbol' can not be used when making a > shared object; recompile with -fPIC > ../libxipc/.libs/libxipc.a(hmac_md5.o): could not read symbols: Bad value > > My OS is Debian. Net-snmp version is 5.4. How can I resolve it, please? See the SNMP entry in the xorp/ERRATA file. Pavlin > -- > Best Regard > Xiaoshuai Yang > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From eshe168 at gmail.com Tue Dec 9 23:49:08 2008 From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=) Date: Wed, 10 Dec 2008 15:49:08 +0800 Subject: [Xorp-hackers] About compile with snmp! In-Reply-To: <200812100708.mBA78Xat025790@fruitcake.ICSI.Berkeley.EDU> References: <56f9e0990812091857p764c0162g1d6defd751f22579@mail.gmail.com> <200812100708.mBA78Xat025790@fruitcake.ICSI.Berkeley.EDU> Message-ID: <56f9e0990812092349r5bb80a0v512d184afdb73aba@mail.gmail.com> Hi, Sorry, I cannot find xorp/ERRATA file. 2008/12/10 Pavlin Radoslavov : > ??? wrote: > >> Hi, all >> >> When I compile Xorp with snmp, I have something wrong. >> The error information is follow: >> /usr/bin/ld: ../libxipc/.libs/libxipc.a(hmac_md5.o): relocation >> R_X86_64_32S against `a local symbol' can not be used when making a >> shared object; recompile with -fPIC >> ../libxipc/.libs/libxipc.a(hmac_md5.o): could not read symbols: Bad value >> >> My OS is Debian. Net-snmp version is 5.4. How can I resolve it, please? > > See the SNMP entry in the xorp/ERRATA file. > > Pavlin > >> -- >> Best Regard >> Xiaoshuai Yang >> >> _______________________________________________ >> Xorp-hackers mailing list >> Xorp-hackers at icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > -- Best Regard Xiaoshuai Yang From pavlin at ICSI.Berkeley.EDU Wed Dec 10 00:23:15 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 10 Dec 2008 00:23:15 -0800 Subject: [Xorp-hackers] About compile with snmp! In-Reply-To: <56f9e0990812092349r5bb80a0v512d184afdb73aba@mail.gmail.com> References: <56f9e0990812091857p764c0162g1d6defd751f22579@mail.gmail.com> <200812100708.mBA78Xat025790@fruitcake.ICSI.Berkeley.EDU> <56f9e0990812092349r5bb80a0v512d184afdb73aba@mail.gmail.com> Message-ID: <200812100823.mBA8NFr9003268@fruitcake.ICSI.Berkeley.EDU> ??? wrote: > Hi, > > Sorry, I cannot find xorp/ERRATA file. It is in the top-level XORP directory (the one that contains the ./configure script). Anyway, here are the commands you need to run to fix the problem (FYI, the problem is triggered only on 64-bit machines): ./configure --with-snmp --enable-shared gmake clean gmake Pavlin > 2008/12/10 Pavlin Radoslavov : > > ??? wrote: > > > >> Hi, all > >> > >> When I compile Xorp with snmp, I have something wrong. > >> The error information is follow: > >> /usr/bin/ld: ../libxipc/.libs/libxipc.a(hmac_md5.o): relocation > >> R_X86_64_32S against `a local symbol' can not be used when making a > >> shared object; recompile with -fPIC > >> ../libxipc/.libs/libxipc.a(hmac_md5.o): could not read symbols: Bad value > >> > >> My OS is Debian. Net-snmp version is 5.4. How can I resolve it, please? > > > > See the SNMP entry in the xorp/ERRATA file. > > > > Pavlin > > > >> -- > >> Best Regard > >> Xiaoshuai Yang > >> > >> _______________________________________________ > >> Xorp-hackers mailing list > >> Xorp-hackers at icir.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > > -- > Best Regard > Xiaoshuai Yang > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From vfaion at gmail.com Wed Dec 10 09:56:09 2008 From: vfaion at gmail.com (Victor Faion) Date: Wed, 10 Dec 2008 17:56:09 +0000 Subject: [Xorp-hackers] Adding a XORP Process Message-ID: <38f1dbe80812100956p21b63612kd0edf8a4b17ab18a@mail.gmail.com> Hello, I was trying to create a new XORP process by following the guide. I created an interface (.xif file in /xrl/interfaces) and then added this to /xrl/intefaces/Makefile.am : noinst_LTLIBRARIES += libipsfxif.la libipsfxif_la_SOURCES = ipsf_xif.hh ipsf_xif.cc Then I was trying to generate the Makefile.in with automake but it wasn't working. I ran automake from the root folder but I go some errors: ... xrl/interfaces/Makefile.am:11: Libtool library used but `LIBTOOL' is undefined xrl/interfaces/Makefile.am:11: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' xrl/interfaces/Makefile.am:11: to `configure.in' and run `aclocal' and `autoconf' again. xrl/interfaces/Makefile.am:11: If `AC_PROG_LIBTOOL' is in `configure.in', make sure xrl/interfaces/Makefile.am:11: its definition is in aclocal's search path. ... I checked and AC_PROG_LIBTOOL is in configure.in but when I run aclocal I get these errors /usr/share/aclocal/libmcrypt.m4:17: warning: underquoted definition of AM_PATH_LIBMCRYPT /usr/share/aclocal/libmcrypt.m4:17: run info '(automake)Extending aclocal' /usr/share/aclocal/libmcrypt.m4:17: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal and from autoconf I get the following: configure.in:173: error: possibly undefined macro: AC_DISABLE_SHARED If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:174: error: possibly undefined macro: AC_DISABLE_FAST_INSTALL configure.in:175: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL configure.in:176: error: possibly undefined macro: AC_PROG_LIBTOOL Not really sure if this is the right way to regenerate the /xrl/interfaces/Makefile.in from /xrl/interfaces/Makefile.am, perhaps XORP has its own scripts to do this? From pavlin at ICSI.Berkeley.EDU Wed Dec 10 10:29:50 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 10 Dec 2008 10:29:50 -0800 Subject: [Xorp-hackers] Adding a XORP Process In-Reply-To: <38f1dbe80812100956p21b63612kd0edf8a4b17ab18a@mail.gmail.com> References: <38f1dbe80812100956p21b63612kd0edf8a4b17ab18a@mail.gmail.com> Message-ID: <200812101829.mBAIToiC019008@fruitcake.ICSI.Berkeley.EDU> Victor Faion wrote: > Hello, > > I was trying to create a new XORP process by following the guide. I > created an interface (.xif file in /xrl/interfaces) and then added > this to /xrl/intefaces/Makefile.am : > > noinst_LTLIBRARIES += libipsfxif.la > libipsfxif_la_SOURCES = ipsf_xif.hh ipsf_xif.cc > > Then I was trying to generate the Makefile.in with automake but it > wasn't working. I ran automake from the root folder but I go some > errors: > > ... > xrl/interfaces/Makefile.am:11: Libtool library used but `LIBTOOL' is undefined > xrl/interfaces/Makefile.am:11: The usual way to define `LIBTOOL' is > to add `AC_PROG_LIBTOOL' > xrl/interfaces/Makefile.am:11: to `configure.in' and run `aclocal' > and `autoconf' again. > xrl/interfaces/Makefile.am:11: If `AC_PROG_LIBTOOL' is in > `configure.in', make sure > xrl/interfaces/Makefile.am:11: its definition is in aclocal's search path. > ... > > I checked and AC_PROG_LIBTOOL is in configure.in but when I run > aclocal I get these errors > > /usr/share/aclocal/libmcrypt.m4:17: warning: underquoted definition of > AM_PATH_LIBMCRYPT > /usr/share/aclocal/libmcrypt.m4:17: run info '(automake)Extending aclocal' > /usr/share/aclocal/libmcrypt.m4:17: or see > http://sources.redhat.com/automake/automake.html#Extending-aclocal > > and from autoconf I get the following: > > configure.in:173: error: possibly undefined macro: AC_DISABLE_SHARED > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > configure.in:174: error: possibly undefined macro: AC_DISABLE_FAST_INSTALL > configure.in:175: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL > configure.in:176: error: possibly undefined macro: AC_PROG_LIBTOOL > > Not really sure if this is the right way to regenerate the > /xrl/interfaces/Makefile.in from /xrl/interfaces/Makefile.am, perhaps > XORP has its own scripts to do this? Yes, please run ./bootstrap in the top-level XORP directory. However, first make sure that your autoconf/automake/libtool versions are same as those specified in README. After that check the beginning of bootstrap about the executable names that bootstrap assumes. If they are different on your system, then use the corresponding environmental variables to overwrite them. Pavlin > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From atanu at xorp.org Wed Dec 10 10:41:14 2008 From: atanu at xorp.org (Atanu Ghosh) Date: Wed, 10 Dec 2008 10:41:14 -0800 Subject: [Xorp-hackers] Adding a XORP Process In-Reply-To: Message from Pavlin Radoslavov of "Wed, 10 Dec 2008 10:29:50 PST." <200812101829.mBAIToiC019008@fruitcake.ICSI.Berkeley.EDU> Message-ID: <17560.1228934474@xorps.icir.org> Hi, You may want to also look in the examples directory, there is a directory usermgr that has a simple working example of add a XORP process. Atanu. >>>>> "Pavlin" == Pavlin Radoslavov writes: Pavlin> Victor Faion wrote: >> Hello, >> >> I was trying to create a new XORP process by following the guide. I >> created an interface (.xif file in /xrl/interfaces) and then added >> this to /xrl/intefaces/Makefile.am : >> >> noinst_LTLIBRARIES += libipsfxif.la >> libipsfxif_la_SOURCES = ipsf_xif.hh ipsf_xif.cc >> >> Then I was trying to generate the Makefile.in with automake but it >> wasn't working. I ran automake from the root folder but I go some >> errors: >> >> ... >> xrl/interfaces/Makefile.am:11: Libtool library used but `LIBTOOL' is undefined >> xrl/interfaces/Makefile.am:11: The usual way to define `LIBTOOL' is >> to add `AC_PROG_LIBTOOL' >> xrl/interfaces/Makefile.am:11: to `configure.in' and run `aclocal' >> and `autoconf' again. >> xrl/interfaces/Makefile.am:11: If `AC_PROG_LIBTOOL' is in >> `configure.in', make sure >> xrl/interfaces/Makefile.am:11: its definition is in aclocal's search path. >> ... >> >> I checked and AC_PROG_LIBTOOL is in configure.in but when I run >> aclocal I get these errors >> >> /usr/share/aclocal/libmcrypt.m4:17: warning: underquoted definition of >> AM_PATH_LIBMCRYPT >> /usr/share/aclocal/libmcrypt.m4:17: run info '(automake)Extending aclocal' >> /usr/share/aclocal/libmcrypt.m4:17: or see >> http://sources.redhat.com/automake/automake.html#Extending-aclocal >> >> and from autoconf I get the following: >> >> configure.in:173: error: possibly undefined macro: AC_DISABLE_SHARED >> If this token and others are legitimate, please use m4_pattern_allow. >> See the Autoconf documentation. >> configure.in:174: error: possibly undefined macro: AC_DISABLE_FAST_INSTALL >> configure.in:175: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL >> configure.in:176: error: possibly undefined macro: AC_PROG_LIBTOOL >> >> Not really sure if this is the right way to regenerate the >> /xrl/interfaces/Makefile.in from /xrl/interfaces/Makefile.am, perhaps >> XORP has its own scripts to do this? Pavlin> Yes, please run ./bootstrap in the top-level XORP directory. Pavlin> However, first make sure that your autoconf/automake/libtool Pavlin> versions are same as those specified in README. After that Pavlin> check the beginning of bootstrap about the executable names that Pavlin> bootstrap assumes. If they are different on your system, then use Pavlin> the corresponding environmental variables to overwrite them. Pavlin> Pavlin >> _______________________________________________ >> Xorp-hackers mailing list >> Xorp-hackers at icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers Pavlin> _______________________________________________ Pavlin> Xorp-hackers mailing list Pavlin> Xorp-hackers at icir.org Pavlin> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From vfaion at gmail.com Wed Dec 10 11:46:34 2008 From: vfaion at gmail.com (Victor Faion) Date: Wed, 10 Dec 2008 19:46:34 +0000 Subject: [Xorp-hackers] Adding a XORP Process In-Reply-To: <17560.1228934474@xorps.icir.org> References: <200812101829.mBAIToiC019008@fruitcake.ICSI.Berkeley.EDU> <17560.1228934474@xorps.icir.org> Message-ID: <38f1dbe80812101146g132a96d5ia2fdf7cdb0649225@mail.gmail.com> On Wed, Dec 10, 2008 at 18:41, Atanu Ghosh wrote: > Hi, > > You may want to also look in the examples directory, there is a > directory usermgr that has a simple working example of add a XORP > process. > > Atanu. > >>>>>> "Pavlin" == Pavlin Radoslavov writes: > > Pavlin> Victor Faion wrote: > > >> Hello, > >> > >> I was trying to create a new XORP process by following the guide. I > >> created an interface (.xif file in /xrl/interfaces) and then added > >> this to /xrl/intefaces/Makefile.am : > >> > >> noinst_LTLIBRARIES += libipsfxif.la > >> libipsfxif_la_SOURCES = ipsf_xif.hh ipsf_xif.cc > >> > >> Then I was trying to generate the Makefile.in with automake but it > >> wasn't working. I ran automake from the root folder but I go some > >> errors: > >> > >> ... > >> xrl/interfaces/Makefile.am:11: Libtool library used but `LIBTOOL' is undefined > >> xrl/interfaces/Makefile.am:11: The usual way to define `LIBTOOL' is > >> to add `AC_PROG_LIBTOOL' > >> xrl/interfaces/Makefile.am:11: to `configure.in' and run `aclocal' > >> and `autoconf' again. > >> xrl/interfaces/Makefile.am:11: If `AC_PROG_LIBTOOL' is in > >> `configure.in', make sure > >> xrl/interfaces/Makefile.am:11: its definition is in aclocal's search path. > >> ... > >> > >> I checked and AC_PROG_LIBTOOL is in configure.in but when I run > >> aclocal I get these errors > >> > >> /usr/share/aclocal/libmcrypt.m4:17: warning: underquoted definition of > >> AM_PATH_LIBMCRYPT > >> /usr/share/aclocal/libmcrypt.m4:17: run info '(automake)Extending aclocal' > >> /usr/share/aclocal/libmcrypt.m4:17: or see > >> http://sources.redhat.com/automake/automake.html#Extending-aclocal > >> > >> and from autoconf I get the following: > >> > >> configure.in:173: error: possibly undefined macro: AC_DISABLE_SHARED > >> If this token and others are legitimate, please use m4_pattern_allow. > >> See the Autoconf documentation. > >> configure.in:174: error: possibly undefined macro: AC_DISABLE_FAST_INSTALL > >> configure.in:175: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL > >> configure.in:176: error: possibly undefined macro: AC_PROG_LIBTOOL > >> > >> Not really sure if this is the right way to regenerate the > >> /xrl/interfaces/Makefile.in from /xrl/interfaces/Makefile.am, perhaps > >> XORP has its own scripts to do this? > > Pavlin> Yes, please run ./bootstrap in the top-level XORP directory. > Pavlin> However, first make sure that your autoconf/automake/libtool > Pavlin> versions are same as those specified in README. After that > Pavlin> check the beginning of bootstrap about the executable names that > Pavlin> bootstrap assumes. If they are different on your system, then use > Pavlin> the corresponding environmental variables to overwrite them. > > Pavlin> Pavlin > > >> _______________________________________________ > >> Xorp-hackers mailing list > >> Xorp-hackers at icir.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > Pavlin> _______________________________________________ > Pavlin> Xorp-hackers mailing list > Pavlin> Xorp-hackers at icir.org > Pavlin> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > Sorry Pavlin I had missed that bit of the guide as it was at the end. Thanks for the help it's all working now :-) Atanu: Where did you get the examples directory from? I don't have that one. Victor From atanu at xorp.org Wed Dec 10 12:20:24 2008 From: atanu at xorp.org (Atanu Ghosh) Date: Wed, 10 Dec 2008 12:20:24 -0800 Subject: [Xorp-hackers] Adding a XORP Process In-Reply-To: Message from "Victor Faion" of "Wed, 10 Dec 2008 19:46:34 GMT." <38f1dbe80812101146g132a96d5ia2fdf7cdb0649225@mail.gmail.com> Message-ID: <34702.1228940424@xorps.icir.org> Hi, The examples directory is not in the last release, it is only in CVS, it will appear in the next release. Atanu. >>>>> "Victor" == Victor Faion writes: Victor> On Wed, Dec 10, 2008 at 18:41, Atanu Ghosh wrote: >> Hi, >> >> You may want to also look in the examples directory, there is a >> directory usermgr that has a simple working example of add a XORP >> process. >> >> Atanu. >> >>>>>>> "Pavlin" == Pavlin Radoslavov writes: >> Pavlin> Victor Faion wrote: >> >> >> Hello, >> >> >> >> I was trying to create a new XORP process by following the guide. I >> >> created an interface (.xif file in /xrl/interfaces) and then added >> >> this to /xrl/intefaces/Makefile.am : >> >> >> >> noinst_LTLIBRARIES += libipsfxif.la >> >> libipsfxif_la_SOURCES = ipsf_xif.hh ipsf_xif.cc >> >> >> >> Then I was trying to generate the Makefile.in with automake but it >> >> wasn't working. I ran automake from the root folder but I go some >> >> errors: >> >> >> >> ... >> >> xrl/interfaces/Makefile.am:11: Libtool library used but `LIBTOOL' is undefined >> >> xrl/interfaces/Makefile.am:11: The usual way to define `LIBTOOL' is >> >> to add `AC_PROG_LIBTOOL' >> >> xrl/interfaces/Makefile.am:11: to `configure.in' and run `aclocal' >> >> and `autoconf' again. >> >> xrl/interfaces/Makefile.am:11: If `AC_PROG_LIBTOOL' is in >> >> `configure.in', make sure >> >> xrl/interfaces/Makefile.am:11: its definition is in aclocal's search path. >> >> ... >> >> >> >> I checked and AC_PROG_LIBTOOL is in configure.in but when I run >> >> aclocal I get these errors >> >> >> >> /usr/share/aclocal/libmcrypt.m4:17: warning: underquoted definition of >> >> AM_PATH_LIBMCRYPT >> >> /usr/share/aclocal/libmcrypt.m4:17: run info '(automake)Extending aclocal' >> >> /usr/share/aclocal/libmcrypt.m4:17: or see >> >> http://sources.redhat.com/automake/automake.html#Extending-aclocal >> >> >> >> and from autoconf I get the following: >> >> >> >> configure.in:173: error: possibly undefined macro: AC_DISABLE_SHARED >> >> If this token and others are legitimate, please use m4_pattern_allow. >> >> See the Autoconf documentation. >> >> configure.in:174: error: possibly undefined macro: AC_DISABLE_FAST_INSTALL >> >> configure.in:175: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL >> >> configure.in:176: error: possibly undefined macro: AC_PROG_LIBTOOL >> >> >> >> Not really sure if this is the right way to regenerate the >> >> /xrl/interfaces/Makefile.in from /xrl/interfaces/Makefile.am, perhaps >> >> XORP has its own scripts to do this? >> Pavlin> Yes, please run ./bootstrap in the top-level XORP directory. Pavlin> However, first make sure that your autoconf/automake/libtool Pavlin> versions are same as those specified in README. After that Pavlin> check the beginning of bootstrap about the executable names that Pavlin> bootstrap assumes. If they are different on your system, then use Pavlin> the corresponding environmental variables to overwrite them. >> Pavlin> Pavlin >> >> >> _______________________________________________ >> >> Xorp-hackers mailing list >> >> Xorp-hackers at icir.org >> >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers >> Pavlin> _______________________________________________ Pavlin> Xorp-hackers mailing list Pavlin> Xorp-hackers at icir.org Pavlin> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers >> Victor> Sorry Pavlin I had missed that bit of the guide as it was at the end. Victor> Thanks for the help it's all working now :-) Victor> Atanu: Where did you get the examples directory from? I don't have that one. Victor> Victor From vfaion at gmail.com Wed Dec 10 12:31:23 2008 From: vfaion at gmail.com (Victor Faion) Date: Wed, 10 Dec 2008 20:31:23 +0000 Subject: [Xorp-hackers] Adding a XORP Process In-Reply-To: <34702.1228940424@xorps.icir.org> References: <38f1dbe80812101146g132a96d5ia2fdf7cdb0649225@mail.gmail.com> <34702.1228940424@xorps.icir.org> Message-ID: <38f1dbe80812101231m5c4b4f6dg29c78c85ecba74af@mail.gmail.com> On Wed, Dec 10, 2008 at 20:20, Atanu Ghosh wrote: > Hi, > > The examples directory is not in the last release, it is only in CVS, it > will appear in the next release. > > Atanu. > >>>>>> "Victor" == Victor Faion writes: > > Victor> On Wed, Dec 10, 2008 at 18:41, Atanu Ghosh wrote: > >> Hi, > >> > >> You may want to also look in the examples directory, there is a > >> directory usermgr that has a simple working example of add a XORP > >> process. > >> > >> Atanu. > >> > >>>>>>> "Pavlin" == Pavlin Radoslavov writes: > >> > Pavlin> Victor Faion wrote: > >> > >> >> Hello, > >> >> > >> >> I was trying to create a new XORP process by following the guide. I > >> >> created an interface (.xif file in /xrl/interfaces) and then added > >> >> this to /xrl/intefaces/Makefile.am : > >> >> > >> >> noinst_LTLIBRARIES += libipsfxif.la > >> >> libipsfxif_la_SOURCES = ipsf_xif.hh ipsf_xif.cc > >> >> > >> >> Then I was trying to generate the Makefile.in with automake but it > >> >> wasn't working. I ran automake from the root folder but I go some > >> >> errors: > >> >> > >> >> ... > >> >> xrl/interfaces/Makefile.am:11: Libtool library used but `LIBTOOL' is undefined > >> >> xrl/interfaces/Makefile.am:11: The usual way to define `LIBTOOL' is > >> >> to add `AC_PROG_LIBTOOL' > >> >> xrl/interfaces/Makefile.am:11: to `configure.in' and run `aclocal' > >> >> and `autoconf' again. > >> >> xrl/interfaces/Makefile.am:11: If `AC_PROG_LIBTOOL' is in > >> >> `configure.in', make sure > >> >> xrl/interfaces/Makefile.am:11: its definition is in aclocal's search path. > >> >> ... > >> >> > >> >> I checked and AC_PROG_LIBTOOL is in configure.in but when I run > >> >> aclocal I get these errors > >> >> > >> >> /usr/share/aclocal/libmcrypt.m4:17: warning: underquoted definition of > >> >> AM_PATH_LIBMCRYPT > >> >> /usr/share/aclocal/libmcrypt.m4:17: run info '(automake)Extending aclocal' > >> >> /usr/share/aclocal/libmcrypt.m4:17: or see > >> >> http://sources.redhat.com/automake/automake.html#Extending-aclocal > >> >> > >> >> and from autoconf I get the following: > >> >> > >> >> configure.in:173: error: possibly undefined macro: AC_DISABLE_SHARED > >> >> If this token and others are legitimate, please use m4_pattern_allow. > >> >> See the Autoconf documentation. > >> >> configure.in:174: error: possibly undefined macro: AC_DISABLE_FAST_INSTALL > >> >> configure.in:175: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL > >> >> configure.in:176: error: possibly undefined macro: AC_PROG_LIBTOOL > >> >> > >> >> Not really sure if this is the right way to regenerate the > >> >> /xrl/interfaces/Makefile.in from /xrl/interfaces/Makefile.am, perhaps > >> >> XORP has its own scripts to do this? > >> > Pavlin> Yes, please run ./bootstrap in the top-level XORP directory. > Pavlin> However, first make sure that your autoconf/automake/libtool > Pavlin> versions are same as those specified in README. After that > Pavlin> check the beginning of bootstrap about the executable names that > Pavlin> bootstrap assumes. If they are different on your system, then use > Pavlin> the corresponding environmental variables to overwrite them. > >> > Pavlin> Pavlin > >> > >> >> _______________________________________________ > >> >> Xorp-hackers mailing list > >> >> Xorp-hackers at icir.org > >> >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > >> > Pavlin> _______________________________________________ > Pavlin> Xorp-hackers mailing list > Pavlin> Xorp-hackers at icir.org > Pavlin> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > >> > > > Victor> Sorry Pavlin I had missed that bit of the guide as it was at the end. > Victor> Thanks for the help it's all working now :-) > Victor> Atanu: Where did you get the examples directory from? I don't have that one. > > Victor> Victor > Thanks, I will check it out. Victor From atanu at xorp.org Wed Dec 24 18:59:49 2008 From: atanu at xorp.org (Atanu Ghosh) Date: Wed, 24 Dec 2008 18:59:49 -0800 Subject: [Xorp-hackers] Announcing XORP Release Candidate 1.6 Message-ID: <51866.1230173989@xorps.icir.org> Dear XORP developers, We are pleased to announce availability of the release candidate (RC) for version 1.6. The XORP team and contributors have worked very hard over the last 6 months and 1.6 is a huge milestone in the history of the XORP project. Please download and use it and provide us with feedback. We are targeting January 7th as the general availability date of this release. Per my announcement in July, XORP is now commercially backed by two well-known and highly-respected venture capitalists, and one of the benefits for all of us in the XORP community is the additional amount of resources we have been able to bring to the project. These increased resources have resulted in our ability to release 1.6 just months after our announcement of XORP, Inc and release 1.5. In terms of project milestones, 1.6 marks the first time we have put the codebase through a comprehensive and rigorous QA process, using some of the leading test tools in the market for layer 3 testing. Of course, there will be areas where we have not completely tested the codebase and we are looking forward to hearing from the development community once you've had the opportunity to try out release 1.6. Here are some of the key improvements in 1.6, based on your contributions and user feedback: - Significantly improved memory performance on the BGP code (especially in scenarios with many peers) - XRL performance improvements - Improved policy code - *NEW* VRRP support - Numerous bug fixes (entire list is in 1.6 Release Notes available at http://www.xorp.org/releases/1.6-RC/docs/RELEASE_NOTES To file bugs, please visit http://bugzilla.xorp.org/ Of late, we have noticed more users incorporating XORP into their projects, both non-profit and commercial and want to continue to encourage the community to do so. With the recent world financial crisis, organizations will be looking more to open-source as a cost-effective alternative to the high premiums other networking vendors charge, so help us spread the word about XORP.org and help all of us build the momentum behind open-source networking! Thank you very much for your interest and continued participation in the XORP open networking platform project. We appreciate the help and support the community has shown us over the years and hope that you will enjoy this latest release. If you have any questions, please feel free to contact us at info at xorp.net. --The XORP Team P.S. Release notes included below. ------------------------------------------------------------------ XORP RELEASE NOTES Release 1.6-RC (12/24/2008) ============================ ALL: - XORP now builds on Linux CentOS 5.2, Linux openSUSE-11.0, Linux Debian-5.0 (lenny, unreleased), Linux Ubuntu 8.10, Linux Red Hat Enterprise Linux Server release 5 (Tikanga), Linux Fedora 10, and OpenBSD-4.4. - XORP now builds on Linux systems with kernel 2.6.26 which is the first one to support IPv6 multicast routing. CONFIGURATION: - If a PIM-SM router is suppose to receive and process the PIM-SM Bootstrap messages, the configuration must have the "bootstrap {}" block included (even if it is empty): protocols { pimsm4 { bootstrap { } } } protocols { pimsm6 { bootstrap { } } } Previously, the Bootstrap messages were unconditionally processed even if the "bootstrap {}" block contained "disable: true" statement. - The following CLI operational command prefix has been changed: OLD: "show route admin distances" NEW: "show route admin distance" - The CLI "show version" command is supported - Addition of run-time configuration trace options for RIP/RIPng: protocols { rip { traceoptions { disable: false } } } LIBXORP: - Class EtherMac is removed and is replaced/superseded by the existing class Mac. - Performance improvements and various bug fixes in the EventLoop and SelectorList implementation. LIBXIPC: - XRL performance enhancements. (Bug 808) - Issues that might be triggered under heavy system load have been fixed (Bug 800) LIBFEACLIENT: - No significant changes. XRL: - See LIBXIPC RTRMGR: - No significant changes. XORPSH: - Incorrect help "show bgp peers detail" command (Bug 280) - Xorpsh exiting immediately on error doesn't work (Bug 763) - "Show version" CLI supported (Bug 789) - Show route admin distance not working (Bug 812) POLICY: - Tag per route is not reset in case the policies are removed (Bug 567) - Implement per-peer BGP import/export policies (Bug 667) - Enhance policy network-lists to included prefix length (Bug 674) FEA/MFEA: - Bug fix for OpenBSD when transmitting IGMP packets. RIB: - No significant changes RIP/RIPng: - Added traceoption support OLSR: - OSPF: - When the designated router was restarted the MaxAge LSAs that it generated when reflected back would be responded to with a MaxAge LSA, this process could continue indefinitely, leaving the neighbor state in EXCHANGE. (Bug 785) BGP: - Support for Red Hat Linux (Bug 793) STATIC_ROUTES: - No significant changes. MLD/IGMP: - Bug fix when checking the source address of IGMP packet if the source address is allowed to be 0.0.0.0. MLD/IGMP-Lite: - Bug fix when checking the source address of IGMP packet if the source address is allowed to be 0.0.0.0. PIM-SM: Ability to add candidate BSR after inserting Cand-RP with same group (Bug 803) FIB2MRIB: - No significant changes. SNMP: - VRRP: - Initial implementation of VRRP version 2 as described in RFC 3768. - Supports running more than one VRRP instances on the same box although they need to be on different interfaces and different LANs for correct behavior (see ERRATA). - The following master failure modes have been tested and are known to work (i.e., backup becomes master): bringing the master's interface down, rebooting / crashing the master, physically removing the network cable. Note that in the latter case the master may fail to resume operations when the cable is restored (see ERRATA). - Successfully interoperates with vrrpd.