From karnik.jain at einfochips.com Mon Sep 1 02:37:14 2008 From: karnik.jain at einfochips.com (karnik.jain at einfochips.com) Date: Mon, 1 Sep 2008 15:07:14 +0530 (IST) Subject: [Xorp-users] [OSPF]: xorpsh error Message-ID: <32987.10.100.3.224.1220261834.squirrel@india.einfochips.com> when i tried to configure router id of router using xorpsh at that time sometimes i get error like this : Failed to register with router manager process 201 Resolve failed i applied command : set protocols ospf4 router-id 10.10.10.12 i did not understand any thing why it happens like this because many times this commands works and sometimes it fails. my configuration file is displayed below....................................................................... /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $ */ interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "data interface" disable: false /*default-system-config*/ vif eth0 { disable: false address 192.168.14.16 { prefix-length: 24 broadcast: 192.168.14.255 disable: false } } } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } protocols { ospf4 { router-id: 10.10.10.16 /* export: "static" */ traceoptions { flag { all { disable: false } } } area 0.0.0.0 { interface eth0 { /* link-type: "broadcast" */ vif eth0 { address 192.168.14.16 { priority: 3 hello-interval: 10 /*router-dead-interval: 40*/ /*interface-cost: 1*/ /*retransmit-interval: 5*/ /*transit-delay: 1 */ /* authentication { simple-password: "password"; md5 @: u32 { password: "password"; start-time: "2006-01-01.12:00" end-time: "2007-01-01.12:00" max-time-drift: 3600 } } */ /* passive: false */ /* disable: false */ } } } } } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } } /* * Note: fib2mrib is needed for multicast only if the unicast protocols * don't populate the MRIB with multicast-specific routes. */ protocols { fib2mrib { disable: false } } With regards, K at rN|K, Embedded Dept. -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __________________________________________________________________________ From bms at incunabulum.net Mon Sep 1 03:28:19 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon, 01 Sep 2008 11:28:19 +0100 Subject: [Xorp-users] [OSPF]: xorpsh error In-Reply-To: <32987.10.100.3.224.1220261834.squirrel@india.einfochips.com> References: <32987.10.100.3.224.1220261834.squirrel@india.einfochips.com> Message-ID: <48BBC3C3.6020507@incunabulum.net> karnik.jain at einfochips.com wrote: > when i tried to configure router id of router using xorpsh at that time > sometimes i get error like this : > > Failed to register with router manager process > 201 Resolve failed > Questions to consider: * What are the XORP log messages when this condition occurs? * Are you running any of the XORP processes on different nodes? * Did you have any interruption to DNS service? * Did you have any connectivity problems on the machine running xorpsh? From obonhomme at nerim.net Thu Sep 4 04:01:48 2008 From: obonhomme at nerim.net (Olivier BONHOMME) Date: Thu, 04 Sep 2008 13:01:48 +0200 Subject: [Xorp-users] Running XORP considering an interface without connectivity Message-ID: <48BFC01C.8010903@nerim.net> Hello Everybody, I am running XORP on a Linux System with two interface. My problem is that on this system, I can have one of these interface not connected to any network equipments. So, the link is considered down by the Linux. In this configuration, my Xorp system doesn't want to start when I want to use MFEA. The logs tell me that the VIF interface is not UP. (The concerned VIF is linked to the physical interface which is not connected) I would want to know if there is a solution or a workaround in order to force XORP to start when my interface doesn't have physical connectivity ? Thank you for your answers. Best Regards, Olivier BONHOMME From bms at incunabulum.net Thu Sep 4 05:31:18 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 04 Sep 2008 13:31:18 +0100 Subject: [Xorp-users] Running XORP considering an interface without connectivity In-Reply-To: <48BFC01C.8010903@nerim.net> References: <48BFC01C.8010903@nerim.net> Message-ID: <48BFD516.6090606@incunabulum.net> Olivier BONHOMME wrote: > Hello Everybody, > > I am running XORP on a Linux System with two interface. My problem is > that on this system, I can have one of these interface not connected to > any network equipments. So, the link is considered down by the Linux. In > this configuration, my Xorp system doesn't want to start when I want to > use MFEA. The logs tell me that the VIF interface is not UP. (The > concerned VIF is linked to the physical interface which is not connected) > This is a known issue, bug 520, and is already being worked on: http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=560 In the meantime: * Can you post the log message(s) and XORP configuration which are failing? * Which kernel version and Linux distro are you using? * Which protocol(s) are you attempting to run? I can readily reproduce the condition when attempting to run PIM with the rtrmgr/config/multicast4.boot sample config, on FreeBSD 7.0-RELEASE, where one interface is not connected to a switch. cheers BMS From obonhomme at nerim.net Thu Sep 4 06:00:59 2008 From: obonhomme at nerim.net (Olivier BONHOMME) Date: Thu, 04 Sep 2008 15:00:59 +0200 Subject: [Xorp-users] Running XORP considering an interface without connectivity In-Reply-To: <48BFD516.6090606@incunabulum.net> References: <48BFC01C.8010903@nerim.net> <48BFD516.6090606@incunabulum.net> Message-ID: <48BFDC0B.60600@nerim.net> Bruce M Simpson a ?crit : > Olivier BONHOMME wrote: >> Hello Everybody, >> >> I am running XORP on a Linux System with two interface. My problem is >> that on this system, I can have one of these interface not connected >> to any network equipments. So, the link is considered down by the >> Linux. In this configuration, my Xorp system doesn't want to start >> when I want to use MFEA. The logs tell me that the VIF interface is >> not UP. (The concerned VIF is linked to the physical interface which >> is not connected) >> > > This is a known issue, bug 520, and is already being worked on: > http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=560 It seems to be the same issue as described in this bug report. > > In the meantime: > * Can you post the log message(s) and XORP configuration which are > failing? Log Messages from router.log [ 2008/09/04 17:00:28 INFO xorp_fea MFEA ] Interface added: Vif[dvbsat0] pif_index: 5 vif_index: 0 addr: 10.128.0.3 subnet: 10.128.0.0/16 broadcast: 10.128.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2008/09/04 17:00:28 INFO xorp_fea MFEA ] Interface added: Vif[eth0] pif_index: 2 vif_index: 1 Flags: MULTICAST BROADCAST MTU: 1500 [ 2008/09/04 17:00:28 INFO xorp_fea MFEA ] MFEA started [ 2008/09/04 17:00:28 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] pif_index: 2 vif_index: 1 Flags: MULTICAST BROADCAST MTU: 1500 DOWN IPv4 ENABLED [ 2008/09/04 17:00:28 ERROR xorp_fea:19857 MFEA +1186 mfea_node.cc start_vif ] Cannot start vif eth0: underlying vif is not UP [ 2008/09/04 17:00:28 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot start vif eth0: underlying vif is not UP Configuration File : interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "User Interface #1" disable: false default-system-config } interface dvbsat0 { description: "Satellite Interface #1" 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 dvbsat0 { vif dvbsat0 { 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 } } interface dvbsat0 { vif dvbsat0 { 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 } } interface dvbsat0 { vif dvbsat0 { 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 */ } } 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 } } } } /* * Note: fib2mrib is needed for multicast only if the unicast protocols * don't populate the MRIB with multicast-specific routes. */ protocols { fib2mrib { disable: false } } > * Which kernel version and Linux distro are you using? 2.6.18 Kernel on a Debian Etch > * Which protocol(s) are you attempting to run? IGMP. Regards, Olivier BONHOMME From james.dutton at gmail.com Thu Sep 4 08:36:42 2008 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Thu, 4 Sep 2008 16:36:42 +0100 Subject: [Xorp-users] Avoiding asynchronous routing with OSPF In-Reply-To: References: Message-ID: On 12/08/2008, Dirk H. Schulz wrote: > > The problem I have is that packets from servers in subnet B go out via > router2 and answers partially come back via router1. I tried to avoid this > by setting interface costs: > 1. The hightest interface cost is on eth1 which connects my routers > directly (so data traffic between MY routers should be avoided). > 2. The interface ethA without virtual ip address A (that is ethA on > router2) has a significantly higher cost than the other; with ethB it is > similar. > Do you understand the cost setting in OSPF? The ospf cost set on an interface is the cost to SEND packets out. The ospf cost set on an interface has no affect on incoming packets. I only ask in case you have set the cost on the wrong end of the link. James From irfan_area47 at yahoo.co.id Thu Sep 4 09:36:24 2008 From: irfan_area47 at yahoo.co.id (irfan irfan) Date: Fri, 5 Sep 2008 00:36:24 +0800 (SGT) Subject: [Xorp-users] change default location xrl and templates Message-ID: <615934.48777.qm@web76513.mail.sg1.yahoo.com> how to change default location xrl and templates. By default xrl location /usr/local/xorp/xrl/targets and templates location /usr/local/xorp/etc/templates. I want to change change location templates to /etc/templates [standart directory redhat] ___________________________________________________________________________ Yahoo! Toolbar kini dilengkapi dengan Search Assist. Download sekarang juga. http://id.toolbar.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080905/99c1ecd5/attachment.html From bms at incunabulum.net Thu Sep 4 10:25:33 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 04 Sep 2008 18:25:33 +0100 Subject: [Xorp-users] change default location xrl and templates In-Reply-To: <615934.48777.qm@web76513.mail.sg1.yahoo.com> References: <615934.48777.qm@web76513.mail.sg1.yahoo.com> Message-ID: <48C01A0D.7050009@incunabulum.net> irfan irfan wrote: > how to change default location xrl and templates. By default xrl > location /usr/local/xorp/xrl/targets and templates location > /usr/local/xorp/etc/templates. I want to change change location > templates to /etc/templates [standart directory redhat] Unfortunately changing this would require modifying the configure script and Router Manager code; please use the -t command line option or set XORP_ROOT in the environment. thanks BMS From Jackalynn.Sproat at gdcanada.com Mon Sep 8 10:06:20 2008 From: Jackalynn.Sproat at gdcanada.com (Sproat, Jackalynn) Date: Mon, 8 Sep 2008 11:06:20 -0600 Subject: [Xorp-users] OLSR route redistribution in XORPv1.5 Message-ID: <6D5FB6745F80EC45986ACD47D70799AD0412528F@CGYSVW100.gdcan.com> Hello, I am new to XORP and am interested in redistributing routes between XORP OLSR and XORP OSPF. At www.mail-archive.com/xorp-hackers at icir.org/msg00413.html it was mentioned that CenGen had success with exporting inot OSPF in their testbed. I was just wondering how I can get more information w.r.t to doing the same. For example, is this a simple as including the statement export ospf on the OSLR router? Where in the .boot file should this statement be inserted? Cheers, Jackie GENERAL DYNAMICS Canada 1020-68th Avenue NE Calgary, Alberta Canada T2E 8P2 The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080908/21ebd73f/attachment.html From bms at incunabulum.net Mon Sep 8 10:28:44 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon, 08 Sep 2008 18:28:44 +0100 Subject: [Xorp-users] OLSR route redistribution in XORPv1.5 In-Reply-To: <6D5FB6745F80EC45986ACD47D70799AD0412528F@CGYSVW100.gdcan.com> References: <6D5FB6745F80EC45986ACD47D70799AD0412528F@CGYSVW100.gdcan.com> Message-ID: <48C560CC.4060902@incunabulum.net> Sproat, Jackalynn wrote: > > Hello, > > I am new to XORP and am interested in redistributing routes between > XORP OLSR and XORP OSPF. > > At www.mail-archive.com/xorp-hackers at icir.org/msg00413.html > it > was mentioned that CenGen had success with exporting inot OSPF in > their testbed. I was just wondering how I can get more information > w.r.t to doing the same. For example, is this a simple as including > the statement export ospf on the OSLR router? Where in the .boot file > should this statement be inserted? > The OLSR implementation is a standard XORP routing process, which supports route redistribution using the standard mechanisms, and uses a similar syntax as the other processes (BGP, RIP etc). You need to define an export policy and include it like this: %%% protocols { olsr4 { ... export: "ospf-to-olsr" ... } } policy { ... policy-statement ospf-to-olsr { term a { from { protocol: "ospf" } then { accept } } } ... } %%% Currently the OLSR redist support doesn't allow you to specify a metric, as this isn't part of the OLSRv1 spec. ETX link metrics aren't supported however this support could be added at a later date if there is further interest. Also, the policy tags/varmap which xorp_olsr uses are not currently documented. You can try experimenting with the syntax for the various tags in etc/templates/olsr4.tp. These can be used to filter various announcements if going in the opposite direction (OLSR to OSPF or other protocol). For docs, see docs/olsr. You'll need LaTeX installed to build PDFs of the OLSR documentation. thanks BMS From mingcy.xu at gmail.com Wed Sep 10 03:43:22 2008 From: mingcy.xu at gmail.com (Mingcy.Xu) Date: Wed, 10 Sep 2008 18:43:22 +0800 Subject: [Xorp-users] How to notify the OSPF process to use FEA on a different machine? Message-ID: Hi, As described in the FEA document, the forwarding plane may be distributed across multiple machines. So it must be possible to run the OSFP process on one machine with its FEA disabled, and to run its associated FEA on another machine. But how to configure this? How to write the configuration file? It seems that no XORP documents have covered this. Anybody can help me? Regards, Mingcy.Xu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080910/1611a97a/attachment.html From karnik.jain at einfochips.com Wed Sep 10 05:32:16 2008 From: karnik.jain at einfochips.com (karnik) Date: Wed, 10 Sep 2008 18:02:16 +0530 Subject: [Xorp-users] How to notify the OSPF process to use FEA on a different machine? Message-ID: <48C7BE50.4060703@einfochips.com> Please, find the attachment ........... And if u still find any problem than mail me on this id. -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __________________________________________________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.boot.sample Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080910/b858a531/attachment.ksh From pavlin at ICSI.Berkeley.EDU Wed Sep 10 10:07:20 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 10 Sep 2008 10:07:20 -0700 Subject: [Xorp-users] How to notify the OSPF process to use FEA on a different machine? In-Reply-To: References: Message-ID: <200809101707.m8AH7K5Q027027@fruitcake.ICSI.Berkeley.EDU> Mingcy.Xu wrote: > Hi, > > As described in the FEA document, the forwarding plane may be distributed > across multiple machines. So it must be possible to run the OSFP process on > one machine with its FEA disabled, and to run its associated FEA on another > machine. > > But how to configure this? How to write the configuration file? It seems > that no XORP documents have covered this. Anybody can help me? You configure XORP as usual, and you need to do a bit of extra work to start the FEA on a remote machine. Please see the following email for details: http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-October/002134.html Note that the example in that email is how to run static_routes on a remote machine, but the solution is basically same for running the FEA. A small clarification re. the instructions: the sample script that is at the end of the above email should be named fea/xorp_fea, and the real xorp_fea binary should be placed on the remote host. Please let us know how it goes. Pavlin From Jackalynn.Sproat at gdcanada.com Thu Sep 11 09:57:35 2008 From: Jackalynn.Sproat at gdcanada.com (Sproat, Jackalynn) Date: Thu, 11 Sep 2008 10:57:35 -0600 Subject: [Xorp-users] OLSR warnings In-Reply-To: <48C560CC.4060902@incunabulum.net> References: <6D5FB6745F80EC45986ACD47D70799AD0412528F@CGYSVW100.gdcan.com> <48C560CC.4060902@incunabulum.net> Message-ID: <6D5FB6745F80EC45986ACD47D70799AD041252A4@CGYSVW100.gdcan.com> The following warning is shown on all three machines: WARNING: Reuseport undefined! - Is this something of concern, can it be addressed in the config file? The following warning is shown repeatedly on Linux1 and Linux2 only Node already exists OLSR Node Type 3 ID 28877 WARNING: xorp_olsr4: 8105 OLSR +577 ../../libproto/spt.hh [add_node]- Is this something of concern? I have three linux machines running XORP v1.5 wired together as follows: Linux1-eth1 ---> eth1-Linux2-eth2 ---> eth1-Linux3 with OLSR configurd on each machine as follows (where x is the machine number): interfaces { interface eth1 { vif eth1 { address 10.10.10.x { prefix-length: 24 broadcast: 10.10.10.255 } } } /* eth2 is only included on Linux2*/ /*interface eth2 { vif eth2 { address 10.10.10.x-1{ prefix-length: 24 broadcast: 10.10.10.255 } } }*/ } fea { unicast-forwarding4{ disable: false } } protocols { olsr4 { main-address: 10.10.10.x interface eth1 { vif eth1 { address 10.10.10.x { } } } /* eth2 is only included on Linux2*/ /*interface eth2 { vif eth2 { address 10.10.10.x-1 { } } }*/ } } Cheers, Jackie The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. Thank you. From bms at incunabulum.net Thu Sep 11 15:18:17 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 11 Sep 2008 23:18:17 +0100 Subject: [Xorp-users] OLSR warnings In-Reply-To: <6D5FB6745F80EC45986ACD47D70799AD041252A4@CGYSVW100.gdcan.com> References: <6D5FB6745F80EC45986ACD47D70799AD0412528F@CGYSVW100.gdcan.com> <48C560CC.4060902@incunabulum.net> <6D5FB6745F80EC45986ACD47D70799AD041252A4@CGYSVW100.gdcan.com> Message-ID: <48C99929.4090208@incunabulum.net> Sproat, Jackalynn wrote: > The following warning is shown on all three machines: > WARNING: Reuseport undefined! - Is this something of concern, can it be > addressed in the config file? > That can be ignored. If I recall correctly, Linux doesn't have the SO_REUSEPORT option. It is needed to ensure correct broadcast/multicast behaviour in BSD derived networking code; this is explained in "UNIX Network Programming" and "TCP/IP Illustrated Vol 2". > The following warning is shown repeatedly on Linux1 and Linux2 only > Node already exists OLSR Node Type 3 ID 28877 > WARNING: xorp_olsr4: 8105 OLSR +577 ../../libproto/spt.hh [add_node]- Is > this something of concern? > Node type 3 refers to VT_TOPOLOGY -- see enum VertexType in olsr_types.hh. Most likely one or more of the TC records in the link state databases are redundant. This can be expected to happen as multiple nodes can announce the same TC information. It is still necessary to consider *all* of the information, including redundant records, when populating the OLSR shortest path tree, because some of the originating next-hops in the TC database may not be reachable otherwise. thanks BMS From mingcy.xu at gmail.com Fri Sep 12 00:34:27 2008 From: mingcy.xu at gmail.com (Mingcy.Xu) Date: Fri, 12 Sep 2008 15:34:27 +0800 Subject: [Xorp-users] How to notify the OSPF process to use FEA on a different machine? In-Reply-To: <200809112125.m8BLP010015662@fruitcake.ICSI.Berkeley.EDU> References: <200809101707.m8AH7K5Q027027@fruitcake.ICSI.Berkeley.EDU> <03C0666354DA47D3A08097B968660168@wovensystems.local> <200809111850.m8BIoZv4025973@fruitcake.ICSI.Berkeley.EDU> <200809112125.m8BLP010015662@fruitcake.ICSI.Berkeley.EDU> Message-ID: <9F59FA64A6AE456B821982D3B0D16EEE@wovensystems.local> I tried the script approach but got a different result. The following is the detailed information. Host Lab_62(10.20.1.1) : xorp_rtrmgr Host Lab_59(10.20.1.2) : xorp_fea 1. On the FEA host I have XORP built inside the /home/Martin/xorp-1.5 directory 2. Create the following script and place it instead of the fea/xorp_fea binary on the rtrmgr side: #!/bin/sh ssh root at 10.20.1.2 'env XORP_FINDER_SERVER_ADDRESS=10.20.1.1 XORP_FINDER_CLIENT_ADDRESS=10.20.1.2 /home/Martin/xorp-1.5/fea/xorp_fea' Note that 10.20.1.1 is the IP address of the rtrmgr (local) host, and 10.20.1.2 is the IP address of the fea (remote)host. When I run this script on rtrmgr host, I did notice the fea process was started on the FEA host. 3. Setup environmental variables for the Finder on the rtrmgr host: [root at Lab_62 xorp-1.5]# env |more HOSTNAME=Lab_62 TERM=vt100 SHELL=/bin/bash XORP_FINDER_SERVER_ADDRESS=10.20.1.1 XORP_FINDER_CLIENT_ADDRESS=10.20.1.1 ... /////////////////////////////////////////// 4. Make sure that ssh without typing a password works to the fea host. [root at Lab_62 ~]# ssh 10.20.1.2 Last login: Fri Sep 12 13:43:01 2008 from 10.20.1.1 [root at Lab_59 ~]# (No password needed.) To achieve this,I use the following scheme: 1. Run ssh-keygen on the rtrmgr host to create an RSA key-pair with an empty password. 2. Copy the public key to the FEA host. 3. Add the public key to the /root/.ssh/authorized_keys file on the FEA host. 5. Start the rtrmgr on the local host: (the config.boot file used is listed below.) [root at Lab_62 rtrmgr]# ./xorp_rtrmgr -a 10.20.1.2 [ 2008/09/12 15:02:05 INFO xorp_rtrmgr:3348 IPC +477 sockutil.cc set_preferred_ipv4_addr ] Changing to address 10.20.1.1 for IPv4 based XRL communication. [ 2008/09/12 15:02:05 INFO xorp_rtrmgr:3348 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces, firewall, fea, rib, policy, ospf4 [ 2008/09/12 15:02:06 INFO xorp_rtrmgr:3348 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2008/09/12 15:02:08 INFO xorp_rtrmgr:3348 RTRMGR +96 module_manager.cc execute ] Executing module: firewall (fea/xorp_fea) [ 2008/09/12 15:02:12 INFO xorp_rtrmgr:3348 RTRMGR +96 module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 XRL +639 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout [ 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 RTRMGR +1400 task.cc execute_done ] 210 Transport failed [ 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 RTRMGR +1998 task.cc task_fail ] Shutting down fatally wounded process (fea) [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +171 module_manager.cc terminate ] Terminating module: fea [ 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 RTRMGR +681 master_conf_tree.cc commit_pass2_done ] Commit failed: 210 Transport failed [ 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 RTRMGR +251 master_conf_tree.cc config_done ] Configuration failed: 210 Transport failed [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +171 module_manager.cc terminate ] Terminating module: firewall [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +171 module_manager.cc terminate ] Terminating module: interfaces [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +194 module_manager.cc terminate ] Killing module: interfaces Killed by signal 15. [ 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 RTRMGR +747 module_manager.cc done_cb ] Command "/home/Martin/xorp-1.5/fea/xorp_fea": terminated with signal 15. [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: interfaces [root at Lab_62 rtrmgr]# [root at Lab_62 rtrmgr]# At this point, I encountered something strange: 1) the rtrmgr host could not reach FEA host. Its route talbe stayed unchanged. 2) the FEA host could still reach rtrmgr host. But when I tried to ssh rtrmgr host( #ssh 10.20.1.1), I got @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 5e:00:30:a9:72:3e:89:de:4a:07:4e:d8:ca:f7:ae:a6. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending key in /root/.ssh/known_hosts:3 RSA host key for 20.1.1.1 has changed and you have requested strict checking. Host key verification failed. 3) After I rebooted the FEA host and deleted its /root/.ssh/known_hosts, the above two problems were resolved. I have done this experiment for four times, each time I got the same result. Hi, Pavlin, do you have any doubt that running xorp_static_routes on a separate machine with xorp_rtrmgr might be a little different from the situation regarding xorp_fea? The config.boot used: /* $XORP: xorp/rtrmgr/config/ospfv2.boot,v 1.1 2007/08/29 06:49:43 pavlin Exp $ */ policy { policy-statement connected { term export { from { protocol: "connected" } } } } interfaces { interface eth0 { disable: false discard: false vif eth0 { disable: false address 10.20.1.1 { prefix-length: 24 broadcast: 10.20.1.255 disable: false } } } interface eth1 { disable: false discard: false vif eth1 { disable: false address 10.30.1.1 { prefix-length: 24 broadcast: 10.30.1.255 disable: false } } } } fea { unicast-forwarding4 { disable: false } } protocols { ospf4 { router-id: 10.20.1.1 area 0.0.0.0 { interface eth0 { link-type: "broadcast" vif eth0 { address 10.20.1.1 { disable: false } } } interface eth1 { link-type: "broadcast" vif eth1 { address 10.30.1.1 { disable: false } } } } traceoptions { flag { all { disable: false } } } export: "connected" } } -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin at ICSI.Berkeley.EDU] Sent: Friday, September 12, 2008 5:25 AM To: Pavlin Radoslavov Cc: Mingcy.Xu Subject: Re: [Xorp-users] How to notify the OSPF process to use FEA on a different machine? > I wonder why replacing xorp_fea with the script didn't work for you. > Later this afternoon I will do some experiments to see what happens. I just tried the script approach, and it worked for me. Here is what I did: 1. On the fea host I have XORP precompiled inside the /home/pavlin/cxorp directory 2. Create the following script and place it instead of the fea/xorp_fea binary on the rtrmgr side: #!/bin/sh ssh vm-freebsd env XORP_FINDER_SERVER_ADDRESS=192.168.113.1 \ XORP_FINDER_CLIENT_ADDRESS=192.168.113.130 /home/pavlin/cxorp/fea/xorp_fea Note that 192.168.113.1 is the IP address of the rtrmgr (local) host, and 192.168.113.130 is the IP address of the fea (remote) host. 3. Setup the following environmental variables on the rtrmgr host: setenv XORP_FINDER_SERVER_ADDRESS 192.168.113.1 setenv XORP_FINDER_CLIENT_ADDRESS 192.168.113.1 4. Make sure that ssh without typing a password works to the fea host (I use ssh-agent), and that running the fea/xorp_fea script actually executes the xorp_fea binary on the remote fea host: pavlin at rtrmgr[49] /Users/pavlin/cxorp/fea/xorp_fea [ 2008/09/11 14:20:11 INFO xorp_fea IPC ] Changing to address 192.168.113.130 for IPv4 based XRL communication. [ 2008/09/11 14:20:11 INFO xorp_fea IPC ] Changing to address 192.168.113.130 for IPv4 based XRL communication. [ 2008/09/11 14:20:11 INFO xorp_fea IPC ] Changing to address 192.168.113.130 for IPv4 based XRL communication. [ 2008/09/11 14:20:11 INFO xorp_fea IPC ] Changing to address 192.168.113.130 for IPv4 based XRL communication. [ 2008/09/11 14:20:11 ERROR xorp_fea:72561 LIBCOMM +609 /home/pavlin/xorp/libcomm/comm_sock.c comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr = 192.168.113.1, remote_port = 19999): Connection refused [ 2008/09/11 14:20:11 ERROR xorp_fea:72561 FINDER +384 /home/pavlin/xorp/libxipc/finder_tcp_messenger.cc do_auto_connect ] Failed to connect to 192.168.113.1/19999: Connection refused [ 2008/09/11 14:20:11 ERROR xorp_fea:72561 LIBCOMM +609 /home/pavlin/xorp/libcomm/comm_sock.c comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr = 192.168.113.1, remote_port = 19999): Connection refused ... (Type Ctrl-C to stop) 5. Start the rtrmgr on the local host: ./xorp_rtrmgr -a 192.168.113.130 -b static.boot Please let me know how it goes. Pavlin From mingcy.xu at gmail.com Fri Sep 12 02:53:17 2008 From: mingcy.xu at gmail.com (Mingcy.Xu) Date: Fri, 12 Sep 2008 17:53:17 +0800 Subject: [Xorp-users] How to notify the OSPF process to use FEA on a different machine? In-Reply-To: <200809111850.m8BIoZv4025973@fruitcake.ICSI.Berkeley.EDU> References: <200809101707.m8AH7K5Q027027@fruitcake.ICSI.Berkeley.EDU> <03C0666354DA47D3A08097B968660168@wovensystems.local> <200809111850.m8BIoZv4025973@fruitcake.ICSI.Berkeley.EDU> Message-ID: <31879F79D46C43F0B812FF8BD7309447@wovensystems.local> Things are getting better after I used the command "egrep fea *.tp |egrep path" to find all the files including "%modinfo: path "fea/xorp_fea" and then removed this line from these files. [root at Lab_62 templates]# egrep fea *.tp | egrep path fea.tp: %modinfo: path "fea/xorp_fea"; firewall.tp: %modinfo: path "fea/xorp_fea"; interfaces.tp: %modinfo: path "fea/xorp_fea"; mfea4.tp: %modinfo: path "fea/xorp_fea"; mfea6.tp: %modinfo: path "fea/xorp_fea"; [root at Lab_62 templates]# Note: Lab_62(10.20.1.1): rtrmgr Lab_59(10.20.1.2): fea But the rtrmgr can still not be started successfully. The following is the detailed information. 1. Remove line "%modinfo: path "fea/xorp_fea" " in all .tp files as described above. 2. On the rtrmgr side setup the finder server and client addresses: [root at Lab_62 templates]# env | more HOSTNAME=Lab_62 TERM=vt100 SHELL=/bin/bash XORP_FINDER_SERVER_ADDRESS=10.20.1.1 XORP_FINDER_CLIENT_ADDRESS=10.20.1.1 ... 3. On the remote fea side setup the finder server and client addresses: [root at Lab_59 templates]# env|more HOSTNAME=Lab_59 TERM=vt100 SHELL=/bin/bash XORP_FINDER_SERVER_ADDRESS=10.20.1.1 XORP_FINDER_CLIENT_ADDRESS=10.20.1.2 ... 4. Run the rtrmgr on 10.20.1.1 and enable connections from host 10.20.1.2: (The config.boot used is listed below.) [root at Lab_62 rtrmgr]# ./xorp_rtrmgr -a 10.20.1.2 [ 2008/09/12 16:35:38 INFO xorp_rtrmgr:16706 IPC +477 sockutil.cc set_preferred_ipv4_addr ] Changing to address 10.20.1.1 for IPv4 based XRL communication. [ 2008/09/12 16:35:38 INFO xorp_rtrmgr:16706 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces, firewall, fea, rib, policy, ospf4 [ 2008/09/12 16:35:38 INFO xorp_rtrmgr:16706 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces () [ 2008/09/12 16:35:40 WARNING xorp_rtrmgr:16706 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 "fea" does not exist or is not enabled. [ 2008/09/12 16:35:41 WARNING xorp_rtrmgr:16706 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 "fea" does not exist or is not enabled. [ 2008/09/12 16:35:42 WARNING xorp_rtrmgr:16706 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 "fea" does not exist or is not enabled. [ 2008/09/12 16:35:43 WARNING xorp_rtrmgr:16706 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 "fea" does not exist or is not enabled. [ 2008/09/12 16:35:44 WARNING xorp_rtrmgr:16706 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 "fea" does not exist or is not enabled. [ 2008/09/12 16:35:45 WARNING xorp_rtrmgr:16706 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 "fea" does not exist or is not enabled. [ 2008/09/12 16:35:46 WARNING xorp_rtrmgr:16706 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 "fea" does not exist or is not enabled. (Note: at this point the xorp_fea on the remoter machine was started.) [ 2008/09/12 16:35:47 INFO xorp_rtrmgr:16706 RTRMGR +96 module_manager.cc execute ] Executing module: firewall () [ 2008/09/12 16:35:51 INFO xorp_rtrmgr:16706 RTRMGR +96 module_manager.cc execute ] Executing module: fea () [ 2008/09/12 16:36:07 ERROR xorp_rtrmgr:16706 XRL +639 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout [ 2008/09/12 16:36:07 ERROR xorp_rtrmgr:16706 RTRMGR +1400 task.cc execute_done ] 210 Transport failed [ 2008/09/12 16:36:07 ERROR xorp_rtrmgr:16706 RTRMGR +1998 task.cc task_fail ] Shutting down fatally wounded process (fea) [ 2008/09/12 16:36:07 INFO xorp_rtrmgr:16706 RTRMGR +171 module_manager.cc terminate ] Terminating module: fea [ 2008/09/12 16:36:07 ERROR xorp_rtrmgr:16706 RTRMGR +681 master_conf_tree.cc commit_pass2_done ] Commit failed: 210 Transport failed [ 2008/09/12 16:36:07 ERROR xorp_rtrmgr:16706 RTRMGR +251 master_conf_tree.cc config_done ] Configuration failed: 210 Transport failed [ 2008/09/12 16:36:07 INFO xorp_rtrmgr:16706 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2008/09/12 16:36:07 INFO xorp_rtrmgr:16706 RTRMGR +171 module_manager.cc terminate ] Terminating module: firewall [ 2008/09/12 16:36:07 INFO xorp_rtrmgr:16706 RTRMGR +171 module_manager.cc terminate ] Terminating module: interfaces [root at Lab_62 rtrmgr]# 5.Run the fea on 10.20.1.2: [root at Lab_59 fea]# ./xorp_fea [ 2008/09/12 15:32:48 INFO xorp_fea IPC ] Changing to address 10.20.1.2 for IPv4 based XRL communication. [ 2008/09/12 15:32:48 INFO xorp_fea IPC ] Changing to address 10.20.1.2 for IPv4 based XRL communication. [ 2008/09/12 15:32:48 INFO xorp_fea IPC ] Changing to address 10.20.1.2 for IPv4 based XRL communication. [ 2008/09/12 15:32:48 INFO xorp_fea IPC ] Changing to address 10.20.1.2 for IPv4 based XRL communication. [ 2008/09/12 15:32:49 INFO xorp_fea MFEA ] MFEA enabled [ 2008/09/12 15:32:49 INFO xorp_fea MFEA ] CLI enabled [ 2008/09/12 15:32:49 INFO xorp_fea MFEA ] CLI started [ 2008/09/12 15:32:49 INFO xorp_fea MFEA ] MFEA enabled [ 2008/09/12 15:32:49 INFO xorp_fea MFEA ] CLI enabled [ 2008/09/12 15:32:49 INFO xorp_fea MFEA ] CLI started (Note: the xorp_finder was not started manually on this machine. So the above message showed the fea had found its finder server on another machine.) At this point, the rtrmgr host lost its connection to the fea host. The connection can be established again only after the fea host is rebooted(this is similar when I used the script approach.). The config.boot used: /* $XORP: xorp/rtrmgr/config/ospfv2.boot,v 1.1 2007/08/29 06:49:43 pavlin Exp $ */ policy { policy-statement connected { term export { from { protocol: "connected" } } } } interfaces { interface eth0 { disable: false discard: false vif eth0 { disable: false address 10.20.1.1 { prefix-length: 24 broadcast: 10.20.1.255 disable: false } } } interface eth1 { disable: false discard: false vif eth1 { disable: false address 10.30.1.1 { prefix-length: 24 broadcast: 10.30.1.255 disable: false } } } } fea { unicast-forwarding4 { disable: false } } protocols { ospf4 { router-id: 10.20.1.1 area 0.0.0.0 { interface eth0 { link-type: "broadcast" vif eth0 { address 10.20.1.1 { disable: false } } } interface eth1 { link-type: "broadcast" vif eth1 { address 10.30.1.1 { disable: false } } } } traceoptions { flag { all { disable: false } } } export: "connected" } } -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin at ICSI.Berkeley.EDU] Sent: Friday, September 12, 2008 2:51 AM To: Mingcy.Xu Cc: 'Pavlin Radoslavov' Subject: Re: [Xorp-users] How to notify the OSPF process to use FEA on a different machine? Thank you for the detailed information. It looks like the issue is that the xorp_fea process was still started locally. I think the reason is because more than one *.tp template file can actually start the fea. Hence, you would need to do the same "%modinfo: path ..." change/removal for all files: egrep fea *.tp |egrep path You shouldn't replace xorp_fea with xorp_static_routes, so you should try removing the line. I wonder why replacing xorp_fea with the script didn't work for you. Later this afternoon I will do some experiments to see what happens. Pavlin P.S. In general, unless you have reasons to keep things private, I'd recommend that you send XORP-related emails to one of the XORP mailing lists, so other folks can have the opportunity to provide (better) answer and/or they can benefit from the answers. Mingcy.Xu wrote: > Hi Pavlin, > > I am very grateful to you for taking your time to help me. I have > followed your guide to do the experiment but surprisingly it does not > work out. I guess there must be something I did wrong. I have tried > but can not figure it out. So I hope you could give me more clues. The > following are the details about the experiment. > > > Host 20.1.1.1: Run xorp_rtrmgr (the config.boot used is listed below) > Host 20.1.1.2: Run xorp_fea > ///////////////////////////////////////////////////////////// > > > > Step 1: For xorp_rtrmgr,replace "%modinfo: path" data in > /etc/templates/fea.tp with "static_routes/xorp_static_routes": > .... > fea { > %help: short "Configure the Forwarding Engine > Abstraction"; > %modinfo: provides fea; > %modinfo: depends firewall; > %modinfo: path "static_routes/xorp_static_routes"; > %modinfo: default_targetname "fea"; > > Also tried: > > .... > fea { > %help: short "Configure the Forwarding Engine > Abstraction"; > %modinfo: provides fea; > %modinfo: depends firewall; > %modinfo: default_targetname "fea"; > > (i.e,just remove the line "%modinfo: path".the result seems to make no > difference though.) > ///////////////////////////////////////////////////////////// > > > > Step 2: For xorp_rtrmgr,set required environments : > [root at 20.1.1.1 ~]# env > .... > SHELL=/bin/bash > XORP_FINDER_SERVER_ADDRESS=20.1.1.1 > XORP_FINDER_CLIENT_ADDRESS=20.1.1.1 > .... > ///////////////////////////////////////////////////////////// > > > > Step 3: For xorp_fea,set required environments : > [root at 20.1.1.2 ~]# env > SHELL=/bin/bash > XORP_FINDER_SERVER_ADDRESS=20.1.1.1 > XORP_FINDER_CLIENT_ADDRESS=20.1.1.2 > .......... > ///////////////////////////////////////////////////////////// > > > Step 4: Run xorp_rtrmgr: > [root at 20.1.1.1 rtrmgr]# ./xorp_rtrmgr -a 20.1.1.2 >debug [ 2008/09/11 > 16:52:47 INFO xorp_rtrmgr:2878 IPC +477 sockutil.cc > set_preferred_ipv4_addr ] Changing to address 20.1.1.1 for IPv4 based > XRL communication. > [ 2008/09/11 16:52:47 INFO xorp_rtrmgr:2878 RTRMGR +239 > master_conf_tree.cc execute ] Changed modules: interfaces, firewall, > fea, rib, policy, ospf4 [ 2008/09/11 16:52:47 INFO xorp_rtrmgr:2878 > RTRMGR +96 module_manager.cc execute ] Executing module: interfaces > (fea/xorp_fea) [ 2008/09/11 16:52:49 INFO xorp_rtrmgr:2878 RTRMGR +96 > module_manager.cc execute ] Executing module: firewall (fea/xorp_fea) > [ 2008/09/11 16:52:53 INFO xorp_rtrmgr:2878 RTRMGR +96 > module_manager.cc execute ] Executing module: fea > (static_routes/xorp_static_routes) > [ 2008/09/11 16:52:59 INFO xorp_rtrmgr:2878 RTRMGR +96 > module_manager.cc execute ] Executing module: rib (rib/xorp_rib) [ > 2008/09/11 16:53:01 INFO xorp_rtrmgr:2878 RTRMGR +96 > module_manager.cc execute ] Executing module: policy > (policy/xorp_policy) [ 2008/09/11 16:53:03 INFO xorp_rtrmgr:2878 > RTRMGR +96 module_manager.cc execute ] Executing module: ospf4 > (ospf/xorp_ospfv2) [ 2008/09/11 16:53:05 INFO xorp_rtrmgr:2878 RTRMGR > +2228 task.cc run_task ] No more tasks to run > > When xorp_fea invoked at 20.1.1.2,the following two lines came up: > [ 2008/09/11 16:53:50 INFO xorp_rtrmgr:2878 RTRMGR +275 > module_manager.cc module_exited ] Module normal exit: fea [ 2008/09/11 > 16:53:50 ERROR xorp_rtrmgr:2878 LIBXORP +717 asyncio.cc > complete_transfer ] Write error 104 > ///////////////////////////////////////////////////////////// > > > [root at 20.1.1.1 ~]# ps -a > PID TTY TIME CMD > 2878 pts/0 00:00:01 xorp_rtrmgr > 2879 pts/0 00:00:00 xorp_fea > 2882 pts/0 00:00:00 xorp_rib > 2883 pts/0 00:00:00 xorp_policy > 2885 pts/0 00:00:00 xorp_ospfv2 > 2890 pts/1 00:00:00 ps > ///////////////////////////////////////////////////////////// > > > > Step 5: Run xorp_fea: > [root at 20.1.1.2 fea]# ./xorp_fea > [ 2008/09/11 15:51:14 INFO xorp_fea IPC ] Changing to address 20.1.1.2 > for > IPv4 based XRL communication. > [ 2008/09/11 15:51:14 INFO xorp_fea IPC ] Changing to address 20.1.1.2 > for > IPv4 based XRL communication. > [ 2008/09/11 15:51:14 INFO xorp_fea IPC ] Changing to address 20.1.1.2 > for > IPv4 based XRL communication. > [ 2008/09/11 15:51:14 INFO xorp_fea IPC ] Changing to address 20.1.1.2 > for > IPv4 based XRL communication. > [ 2008/09/11 15:51:14 INFO xorp_fea MFEA ] MFEA enabled [ 2008/09/11 > 15:51:14 INFO xorp_fea MFEA ] CLI enabled [ 2008/09/11 15:51:14 INFO > xorp_fea MFEA ] CLI started [ 2008/09/11 15:51:14 INFO xorp_fea MFEA ] > MFEA enabled [ 2008/09/11 15:51:14 INFO xorp_fea MFEA ] CLI enabled [ > 2008/09/11 15:51:14 INFO xorp_fea MFEA ] CLI started [ 2008/09/11 > 15:51:14 FATAL xorp_fea:2610 MFEA +519 xrl_mfea_node.cc > cli_manager_client_send_add_cli_command_cb ] Cannot add a command to > CLI > manager: 102 Command failed Cannot install command 'show mfea': Error > installing 'show mfea' on '': Command 'mfea' already installed > Aborted ///////////////////////////////////////////////////////////// > > > > > > ///////////////////////////////////////////////////////////// > the config.boot used at 20.1.1.1: > > /* $XORP: xorp/rtrmgr/config/ospfv2.boot,v 1.1 2007/08/29 06:49:43 > pavlin Exp $ */ > > interfaces { > > interface eth0 { > disable: false > discard: false > vif eth0 { > disable: false > address 20.1.1.1 { > prefix-length: 24 > broadcast: 20.1.1.255 > disable: false > } > } > } > > > interface eth1 { > disable: false > discard: false > vif eth1 { > disable: false > address 30.1.1.1 { > prefix-length: 24 > broadcast: 30.1.1.255 > disable: false > } > } > } > > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > > /* > plumbing{ > mfea4{ > disable: true > } > mfea6{ > disable: true > } > } > */ > > > protocols { > > ospf4 { > router-id: 30.1.1.1 > area 0.0.0.0 { > interface eth0 { > link-type: "broadcast" > vif eth0 { > address 20.1.1.1 { > disable: false > } > } > } > > interface eth1 { > link-type: "broadcast" > vif eth1 { > address 30.1.1.1 { > disable: false > } > } > } > > } > > > traceoptions { > flag { > all { > disable: false > } > } > } > } > } > ///////////////////////////////////////////////////////////// > > > I have also tried the script way, but failed either. The xorp_fea does > be invoked by the remote xorp_rtrmgr,but exit after about 20 seconds. > > I saved the following script as file xorp_fea and replaced the one at > xorp-1.5/fea/, and made sure that the fea.tp stay unchanged. > > #!/bin/sh > # > ssh 20.1.1.2 env XORP_FINDER_SERVER_ADDRESS=20.1.1.1 > XORP_FINDER_CLIENT_ADDRESS=20.1.1.2 /home/Martin/xorp-1.5/fea/xorp_fea > > > > > -----Original Message----- > From: Pavlin Radoslavov [mailto:pavlin at ICSI.Berkeley.EDU] > Sent: Thursday, September 11, 2008 1:07 AM > To: Mingcy.Xu > Cc: Xorp-Users > Subject: Re: [Xorp-users] How to notify the OSPF process to use FEA on > a different machine? > > Mingcy.Xu wrote: > > > Hi, > > > > As described in the FEA document, the forwarding plane may be > > distributed across multiple machines. So it must be possible to run > > the OSFP process on one machine with its FEA disabled, and to run > > its associated FEA on another machine. > > > > But how to configure this? How to write the configuration file? It > > seems that no XORP documents have covered this. Anybody can help me? > > You configure XORP as usual, and you need to do a bit of extra work to > start the FEA on a remote machine. > > Please see the following email for details: > http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-October/002 > 134.ht > ml > > Note that the example in that email is how to run static_routes on a > remote machine, but the solution is basically same for running the > FEA. A small clarification re. the instructions: the sample script > that is at the end of the above email should be named fea/xorp_fea, > and the real xorp_fea binary should be placed on the remote host. > > Please let us know how it goes. > > Pavlin From dirk.schulz at kinzesberg.de Fri Sep 12 08:33:44 2008 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Fri, 12 Sep 2008 17:33:44 +0200 Subject: [Xorp-users] Avoiding asynchronous routing with OSPF In-Reply-To: References: Message-ID: <141453438E4CF1CFE1CBE487@Dirks-MacBook-Pro.local> Hi James, --On 4. September 2008 16:36:42 +0100 James Courtier-Dutton wrote: > On 12/08/2008, Dirk H. Schulz wrote: >> >> The problem I have is that packets from servers in subnet B go out via >> router2 and answers partially come back via router1. I tried to avoid >> this by setting interface costs: >> 1. The hightest interface cost is on eth1 which connects my routers >> directly (so data traffic between MY routers should be avoided). >> 2. The interface ethA without virtual ip address A (that is ethA on >> router2) has a significantly higher cost than the other; with ethB it is >> similar. >> > Do you understand the cost setting in OSPF? > The ospf cost set on an interface is the cost to SEND packets out. > The ospf cost set on an interface has no affect on incoming packets. > I only ask in case you have set the cost on the wrong end of the link. I did not understand that detail yet, but it does not make any difference in my scenario - I have recalculated the path costs with that information. Seems that my problem is a bit more complicated: ------------- ------------- | 1 |-----------------| 2 | upstream routers | | | | | | | ------------- ------------- | | | | | | ------------- ------------- | 1 |-----------------| 2 | my routers (connected via eth1) | | | | | | ------------- ------------- | | | | | | | | | | ----------- | | -----------| |-------- | switch A (subnet A) | | | | | | | ----------- | | | | ----------- | -----| |---------------| switch B (subnet B) | | | | ----------- I want packets destined for subnet B always to come in on my router nr. 2 (and subnet A vice versa). But if a packet for subnet B arrives on upstream router 1, that means it has to do one more hop using upstream router 2 to reach my router 2 (compared to going via my router 1). Can I configure OSPF so that path costs are weighed higher than hop count? Dirk From pavlin at ICSI.Berkeley.EDU Fri Sep 12 10:13:15 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 12 Sep 2008 10:13:15 -0700 Subject: [Xorp-users] How to notify the OSPF process to use FEA on a different machine? In-Reply-To: <9F59FA64A6AE456B821982D3B0D16EEE@wovensystems.local> References: <200809101707.m8AH7K5Q027027@fruitcake.ICSI.Berkeley.EDU> <03C0666354DA47D3A08097B968660168@wovensystems.local> <200809111850.m8BIoZv4025973@fruitcake.ICSI.Berkeley.EDU> <200809112125.m8BLP010015662@fruitcake.ICSI.Berkeley.EDU> <9F59FA64A6AE456B821982D3B0D16EEE@wovensystems.local> Message-ID: <200809121713.m8CHDKYw020611@fruitcake.ICSI.Berkeley.EDU> Please try the same experiment (i.e., by using the help of the ssh script), but exclude eth0 from your XORP configuration. This interface is your control communication channel to the fea and it has to be stable. We want to avoid any changes to the remote host (xorp_fea) that might affect this interface configuration or the routing between the xorp_fea and xorp_rtrmgr hosts. To make things simpler and easier to debug, I'd suggest that initially you use static routes instead of OSPF, so it is obvious what is happening (i.e., what routes are added to the xorp_fea kernel). Pavlin Mingcy.Xu wrote: > I tried the script approach but got a different result. The following is the > detailed information. > > Host Lab_62(10.20.1.1) : xorp_rtrmgr > Host Lab_59(10.20.1.2) : xorp_fea > > > 1. On the FEA host I have XORP built inside the > /home/Martin/xorp-1.5 directory > > > 2. Create the following script and place it instead of the > fea/xorp_fea binary on the rtrmgr side: > > #!/bin/sh > ssh root at 10.20.1.2 'env XORP_FINDER_SERVER_ADDRESS=10.20.1.1 > XORP_FINDER_CLIENT_ADDRESS=10.20.1.2 /home/Martin/xorp-1.5/fea/xorp_fea' > > Note that 10.20.1.1 is the IP address of the rtrmgr (local) > host, and 10.20.1.2 is the IP address of the fea (remote)host. > > When I run this script on rtrmgr host, I did notice the fea process was > started on the FEA host. > > > 3. Setup environmental variables for the Finder on the rtrmgr host: > > [root at Lab_62 xorp-1.5]# env |more > HOSTNAME=Lab_62 > TERM=vt100 > SHELL=/bin/bash > XORP_FINDER_SERVER_ADDRESS=10.20.1.1 > XORP_FINDER_CLIENT_ADDRESS=10.20.1.1 > ... > /////////////////////////////////////////// > > 4. Make sure that ssh without typing a password works to the fea host. > > [root at Lab_62 ~]# ssh 10.20.1.2 > Last login: Fri Sep 12 13:43:01 2008 from 10.20.1.1 > [root at Lab_59 ~]# > (No password needed.) > > To achieve this,I use the following scheme: > 1. Run ssh-keygen on the rtrmgr host to create an RSA key-pair with an > empty password. > 2. Copy the public key to the FEA host. > 3. Add the public key to the /root/.ssh/authorized_keys file on the > FEA host. > > > 5. Start the rtrmgr on the local host: > (the config.boot file used is listed below.) > > [root at Lab_62 rtrmgr]# ./xorp_rtrmgr -a 10.20.1.2 > [ 2008/09/12 15:02:05 INFO xorp_rtrmgr:3348 IPC +477 sockutil.cc > set_preferred_ipv4_addr ] Changing to address 10.20.1.1 for IPv4 based XRL > communication. > [ 2008/09/12 15:02:05 INFO xorp_rtrmgr:3348 RTRMGR +239 master_conf_tree.cc > execute ] Changed modules: interfaces, firewall, fea, rib, policy, ospf4 > [ 2008/09/12 15:02:06 INFO xorp_rtrmgr:3348 RTRMGR +96 module_manager.cc > execute ] Executing module: interfaces (fea/xorp_fea) > [ 2008/09/12 15:02:08 INFO xorp_rtrmgr:3348 RTRMGR +96 module_manager.cc > execute ] Executing module: firewall (fea/xorp_fea) > [ 2008/09/12 15:02:12 INFO xorp_rtrmgr:3348 RTRMGR +96 module_manager.cc > execute ] Executing module: fea (fea/xorp_fea) > [ 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 XRL +639 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: Keepalive timeout > [ 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 RTRMGR +1400 task.cc > execute_done ] 210 Transport failed > [ 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 RTRMGR +1998 task.cc task_fail > ] Shutting down fatally wounded process (fea) > [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +171 module_manager.cc > terminate ] Terminating module: fea > [ 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 RTRMGR +681 > master_conf_tree.cc commit_pass2_done ] Commit failed: 210 Transport failed > [ 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 RTRMGR +251 > master_conf_tree.cc config_done ] Configuration failed: 210 Transport failed > [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +2228 task.cc run_task ] > No more tasks to run > [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +171 module_manager.cc > terminate ] Terminating module: firewall > [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +171 module_manager.cc > terminate ] Terminating module: interfaces > [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +194 module_manager.cc > terminate ] Killing module: interfaces > Killed by signal 15. > [ 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 RTRMGR +747 module_manager.cc > done_cb ] Command "/home/Martin/xorp-1.5/fea/xorp_fea": terminated with > signal 15. > [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +282 module_manager.cc > module_exited ] Module killed during shutdown: interfaces > [root at Lab_62 rtrmgr]# > [root at Lab_62 rtrmgr]# > > > At this point, I encountered something strange: > > 1) the rtrmgr host could not reach FEA host. Its route talbe stayed > unchanged. > 2) the FEA host could still reach rtrmgr host. But when I tried to ssh > rtrmgr host( #ssh 10.20.1.1), I got > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone could be eavesdropping on you right now (man-in-the-middle attack)! > It is also possible that the RSA host key has just been changed. > The fingerprint for the RSA key sent by the remote host is > 5e:00:30:a9:72:3e:89:de:4a:07:4e:d8:ca:f7:ae:a6. > Please contact your system administrator. > Add correct host key in /root/.ssh/known_hosts to get rid of this message. > Offending key in /root/.ssh/known_hosts:3 > RSA host key for 20.1.1.1 has changed and you have requested strict > checking. > Host key verification failed. > > 3) After I rebooted the FEA host and deleted its /root/.ssh/known_hosts, the > above two problems were resolved. > > > I have done this experiment for four times, each time I got the same result. > > > Hi, Pavlin, do you have any doubt that running xorp_static_routes on a > separate machine with xorp_rtrmgr might be a little different from the > situation regarding xorp_fea? > > > > The config.boot used: > > /* $XORP: xorp/rtrmgr/config/ospfv2.boot,v 1.1 2007/08/29 06:49:43 pavlin > Exp $ */ > > policy { > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > > interfaces { > > interface eth0 { > disable: false > discard: false > vif eth0 { > disable: false > address 10.20.1.1 { > prefix-length: 24 > broadcast: 10.20.1.255 > disable: false > } > } > } > > interface eth1 { > disable: false > discard: false > vif eth1 { > disable: false > address 10.30.1.1 { > prefix-length: 24 > broadcast: 10.30.1.255 > disable: false > } > } > } > > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > protocols { > > ospf4 { > router-id: 10.20.1.1 > area 0.0.0.0 { > interface eth0 { > link-type: "broadcast" > vif eth0 { > address 10.20.1.1 { > disable: false > } > } > } > > interface eth1 { > link-type: "broadcast" > vif eth1 { > address 10.30.1.1 { > disable: false > } > } > } > > } > > traceoptions { > flag { > all { > disable: false > } > } > } > > export: "connected" > } > } > > > > > > > -----Original Message----- > From: Pavlin Radoslavov [mailto:pavlin at ICSI.Berkeley.EDU] > Sent: Friday, September 12, 2008 5:25 AM > To: Pavlin Radoslavov > Cc: Mingcy.Xu > Subject: Re: [Xorp-users] How to notify the OSPF process to use FEA on a > different machine? > > > I wonder why replacing xorp_fea with the script didn't work for you. > > Later this afternoon I will do some experiments to see what happens. > > I just tried the script approach, and it worked for me. > Here is what I did: > > 1. On the fea host I have XORP precompiled inside the > /home/pavlin/cxorp directory > > 2. Create the following script and place it instead of the > fea/xorp_fea binary on the rtrmgr side: > > #!/bin/sh > ssh vm-freebsd env XORP_FINDER_SERVER_ADDRESS=192.168.113.1 \ > XORP_FINDER_CLIENT_ADDRESS=192.168.113.130 > /home/pavlin/cxorp/fea/xorp_fea > > Note that 192.168.113.1 is the IP address of the rtrmgr (local) > host, and 192.168.113.130 is the IP address of the fea (remote) > host. > > 3. Setup the following environmental variables on the rtrmgr host: > setenv XORP_FINDER_SERVER_ADDRESS 192.168.113.1 setenv > XORP_FINDER_CLIENT_ADDRESS 192.168.113.1 > > 4. Make sure that ssh without typing a password works to the fea > host (I use ssh-agent), and that running the fea/xorp_fea script > actually executes the xorp_fea binary on the remote fea host: > > pavlin at rtrmgr[49] /Users/pavlin/cxorp/fea/xorp_fea [ 2008/09/11 14:20:11 > INFO xorp_fea IPC ] Changing to address 192.168.113.130 for IPv4 based XRL > communication. > [ 2008/09/11 14:20:11 INFO xorp_fea IPC ] Changing to address > 192.168.113.130 for IPv4 based XRL communication. > [ 2008/09/11 14:20:11 INFO xorp_fea IPC ] Changing to address > 192.168.113.130 for IPv4 based XRL communication. > [ 2008/09/11 14:20:11 INFO xorp_fea IPC ] Changing to address > 192.168.113.130 for IPv4 based XRL communication. > [ 2008/09/11 14:20:11 ERROR xorp_fea:72561 LIBCOMM +609 > /home/pavlin/xorp/libcomm/comm_sock.c comm_sock_connect4 ] Error connecting > socket (family = 2, remote_addr = 192.168.113.1, remote_port = 19999): > Connection refused [ 2008/09/11 14:20:11 ERROR xorp_fea:72561 FINDER +384 > /home/pavlin/xorp/libxipc/finder_tcp_messenger.cc do_auto_connect ] Failed > to connect to 192.168.113.1/19999: Connection refused [ 2008/09/11 14:20:11 > ERROR xorp_fea:72561 LIBCOMM +609 /home/pavlin/xorp/libcomm/comm_sock.c > comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr = > 192.168.113.1, remote_port = 19999): Connection refused ... > (Type Ctrl-C to stop) > > 5. Start the rtrmgr on the local host: > ./xorp_rtrmgr -a 192.168.113.130 -b static.boot > > > Please let me know how it goes. > Pavlin > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at ICSI.Berkeley.EDU Fri Sep 12 10:14:15 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 12 Sep 2008 10:14:15 -0700 Subject: [Xorp-users] How to notify the OSPF process to use FEA on a different machine? In-Reply-To: <31879F79D46C43F0B812FF8BD7309447@wovensystems.local> References: <200809101707.m8AH7K5Q027027@fruitcake.ICSI.Berkeley.EDU> <03C0666354DA47D3A08097B968660168@wovensystems.local> <200809111850.m8BIoZv4025973@fruitcake.ICSI.Berkeley.EDU> <31879F79D46C43F0B812FF8BD7309447@wovensystems.local> Message-ID: <200809121714.m8CHEFo8020842@fruitcake.ICSI.Berkeley.EDU> Mingcy.Xu wrote: > > > Things are getting better after I used the command "egrep fea *.tp |egrep > path" to find all the files including > "%modinfo: path "fea/xorp_fea" > and then removed this line from these files. Please use the ssh-based script approach instead of removing the above lines (see my previous email on the subject). Pavlin > [root at Lab_62 templates]# egrep fea *.tp | egrep path > fea.tp: %modinfo: path "fea/xorp_fea"; > firewall.tp: %modinfo: path "fea/xorp_fea"; > interfaces.tp: %modinfo: path "fea/xorp_fea"; > mfea4.tp: %modinfo: path "fea/xorp_fea"; > mfea6.tp: %modinfo: path "fea/xorp_fea"; > [root at Lab_62 templates]# > > Note: Lab_62(10.20.1.1): rtrmgr > Lab_59(10.20.1.2): fea > > But the rtrmgr can still not be started successfully. The following is the > detailed information. > > > 1. Remove line "%modinfo: path "fea/xorp_fea" " in all .tp files as > described above. > > > 2. On the rtrmgr side setup the finder server and client addresses: > > [root at Lab_62 templates]# env | more > HOSTNAME=Lab_62 > TERM=vt100 > SHELL=/bin/bash > XORP_FINDER_SERVER_ADDRESS=10.20.1.1 > XORP_FINDER_CLIENT_ADDRESS=10.20.1.1 > ... > > 3. On the remote fea side setup the finder server and client addresses: > > [root at Lab_59 templates]# env|more > HOSTNAME=Lab_59 > TERM=vt100 > SHELL=/bin/bash > XORP_FINDER_SERVER_ADDRESS=10.20.1.1 > XORP_FINDER_CLIENT_ADDRESS=10.20.1.2 > ... > > 4. Run the rtrmgr on 10.20.1.1 and enable connections from host 10.20.1.2: > (The config.boot used is listed below.) > > [root at Lab_62 rtrmgr]# ./xorp_rtrmgr -a 10.20.1.2 > [ 2008/09/12 16:35:38 INFO xorp_rtrmgr:16706 IPC +477 sockutil.cc > set_preferred_ipv4_addr ] Changing to address 10.20.1.1 for IPv4 based XRL > communication. > [ 2008/09/12 16:35:38 INFO xorp_rtrmgr:16706 RTRMGR +239 > master_conf_tree.cc execute ] Changed modules: interfaces, firewall, fea, > rib, policy, ospf4 > [ 2008/09/12 16:35:38 INFO xorp_rtrmgr:16706 RTRMGR +96 module_manager.cc > execute ] Executing module: interfaces () > [ 2008/09/12 16:35:40 WARNING xorp_rtrmgr:16706 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 "fea" does not exist or is not enabled. > [ 2008/09/12 16:35:41 WARNING xorp_rtrmgr:16706 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 "fea" does not exist or is not enabled. > [ 2008/09/12 16:35:42 WARNING xorp_rtrmgr:16706 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 "fea" does not exist or is not enabled. > [ 2008/09/12 16:35:43 WARNING xorp_rtrmgr:16706 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 "fea" does not exist or is not enabled. > [ 2008/09/12 16:35:44 WARNING xorp_rtrmgr:16706 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 "fea" does not exist or is not enabled. > [ 2008/09/12 16:35:45 WARNING xorp_rtrmgr:16706 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 "fea" does not exist or is not enabled. > [ 2008/09/12 16:35:46 WARNING xorp_rtrmgr:16706 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 "fea" does not exist or is not enabled. > > (Note: at this point the xorp_fea on the remoter machine was started.) > > [ 2008/09/12 16:35:47 INFO xorp_rtrmgr:16706 RTRMGR +96 module_manager.cc > execute ] Executing module: firewall () > [ 2008/09/12 16:35:51 INFO xorp_rtrmgr:16706 RTRMGR +96 module_manager.cc > execute ] Executing module: fea () > [ 2008/09/12 16:36:07 ERROR xorp_rtrmgr:16706 XRL +639 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: Keepalive timeout > [ 2008/09/12 16:36:07 ERROR xorp_rtrmgr:16706 RTRMGR +1400 task.cc > execute_done ] 210 Transport failed > [ 2008/09/12 16:36:07 ERROR xorp_rtrmgr:16706 RTRMGR +1998 task.cc > task_fail ] Shutting down fatally wounded process (fea) > [ 2008/09/12 16:36:07 INFO xorp_rtrmgr:16706 RTRMGR +171 module_manager.cc > terminate ] Terminating module: fea > [ 2008/09/12 16:36:07 ERROR xorp_rtrmgr:16706 RTRMGR +681 > master_conf_tree.cc commit_pass2_done ] Commit failed: 210 Transport failed > [ 2008/09/12 16:36:07 ERROR xorp_rtrmgr:16706 RTRMGR +251 > master_conf_tree.cc config_done ] Configuration failed: 210 Transport failed > [ 2008/09/12 16:36:07 INFO xorp_rtrmgr:16706 RTRMGR +2228 task.cc run_task > ] No more tasks to run > [ 2008/09/12 16:36:07 INFO xorp_rtrmgr:16706 RTRMGR +171 module_manager.cc > terminate ] Terminating module: firewall > [ 2008/09/12 16:36:07 INFO xorp_rtrmgr:16706 RTRMGR +171 module_manager.cc > terminate ] Terminating module: interfaces > [root at Lab_62 rtrmgr]# > > > 5.Run the fea on 10.20.1.2: > > [root at Lab_59 fea]# ./xorp_fea > [ 2008/09/12 15:32:48 INFO xorp_fea IPC ] Changing to address 10.20.1.2 for > IPv4 based XRL communication. > [ 2008/09/12 15:32:48 INFO xorp_fea IPC ] Changing to address 10.20.1.2 for > IPv4 based XRL communication. > [ 2008/09/12 15:32:48 INFO xorp_fea IPC ] Changing to address 10.20.1.2 for > IPv4 based XRL communication. > [ 2008/09/12 15:32:48 INFO xorp_fea IPC ] Changing to address 10.20.1.2 for > IPv4 based XRL communication. > [ 2008/09/12 15:32:49 INFO xorp_fea MFEA ] MFEA enabled > [ 2008/09/12 15:32:49 INFO xorp_fea MFEA ] CLI enabled > [ 2008/09/12 15:32:49 INFO xorp_fea MFEA ] CLI started > [ 2008/09/12 15:32:49 INFO xorp_fea MFEA ] MFEA enabled > [ 2008/09/12 15:32:49 INFO xorp_fea MFEA ] CLI enabled > [ 2008/09/12 15:32:49 INFO xorp_fea MFEA ] CLI started > (Note: the xorp_finder was not started manually on this machine. So the > above message showed the fea had found its finder server on another > machine.) > > > > At this point, the rtrmgr host lost its connection to the fea host. The > connection can be established again only after the fea host is rebooted(this > is similar when I used the script approach.). > > > > The config.boot used: > > /* $XORP: xorp/rtrmgr/config/ospfv2.boot,v 1.1 2007/08/29 06:49:43 pavlin > Exp $ */ > > policy { > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > > interfaces { > > interface eth0 { > disable: false > discard: false > vif eth0 { > disable: false > address 10.20.1.1 { > prefix-length: 24 > broadcast: 10.20.1.255 > disable: false > } > } > } > > interface eth1 { > disable: false > discard: false > vif eth1 { > disable: false > address 10.30.1.1 { > prefix-length: 24 > broadcast: 10.30.1.255 > disable: false > } > } > } > > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > protocols { > > ospf4 { > router-id: 10.20.1.1 > area 0.0.0.0 { > interface eth0 { > link-type: "broadcast" > vif eth0 { > address 10.20.1.1 { > disable: false > } > } > } > > interface eth1 { > link-type: "broadcast" > vif eth1 { > address 10.30.1.1 { > disable: false > } > } > } > > } > > traceoptions { > flag { > all { > disable: false > } > } > } > > export: "connected" > } > } > > > > > > > -----Original Message----- > From: Pavlin Radoslavov [mailto:pavlin at ICSI.Berkeley.EDU] > Sent: Friday, September 12, 2008 2:51 AM > To: Mingcy.Xu > Cc: 'Pavlin Radoslavov' > Subject: Re: [Xorp-users] How to notify the OSPF process to use FEA on a > different machine? > > > Thank you for the detailed information. > It looks like the issue is that the xorp_fea process was still started > locally. > I think the reason is because more than one *.tp template file can actually > start the fea. Hence, you would need to do the same > "%modinfo: path ..." change/removal for all files: > > egrep fea *.tp |egrep path > > You shouldn't replace xorp_fea with xorp_static_routes, so you should try > removing the line. > > I wonder why replacing xorp_fea with the script didn't work for you. > Later this afternoon I will do some experiments to see what happens. > > Pavlin > > P.S. In general, unless you have reasons to keep things private, I'd > recommend that you send XORP-related emails to one of the XORP mailing > lists, so other folks can have the opportunity to provide > (better) answer and/or they can benefit from the answers. > > Mingcy.Xu wrote: > > > Hi Pavlin, > > > > I am very grateful to you for taking your time to help me. I have > > followed your guide to do the experiment but surprisingly it does not > > work out. I guess there must be something I did wrong. I have tried > > but can not figure it out. So I hope you could give me more clues. The > > following are the details about the experiment. > > > > > > Host 20.1.1.1: Run xorp_rtrmgr (the config.boot used is listed below) > > Host 20.1.1.2: Run xorp_fea > > ///////////////////////////////////////////////////////////// > > > > > > > > Step 1: For xorp_rtrmgr,replace "%modinfo: path" data in > > /etc/templates/fea.tp with "static_routes/xorp_static_routes": > > .... > > fea { > > %help: short "Configure the Forwarding Engine > > Abstraction"; > > %modinfo: provides fea; > > %modinfo: depends firewall; > > %modinfo: path "static_routes/xorp_static_routes"; > > %modinfo: default_targetname "fea"; > > > > Also tried: > > > > .... > > fea { > > %help: short "Configure the Forwarding Engine > > Abstraction"; > > %modinfo: provides fea; > > %modinfo: depends firewall; > > %modinfo: default_targetname "fea"; > > > > (i.e,just remove the line "%modinfo: path".the result seems to make > no > > difference though.) > > ///////////////////////////////////////////////////////////// > > > > > > > > Step 2: For xorp_rtrmgr,set required environments : > > [root at 20.1.1.1 ~]# env > > .... > > SHELL=/bin/bash > > XORP_FINDER_SERVER_ADDRESS=20.1.1.1 > > XORP_FINDER_CLIENT_ADDRESS=20.1.1.1 > > .... > > ///////////////////////////////////////////////////////////// > > > > > > > > Step 3: For xorp_fea,set required environments : > > [root at 20.1.1.2 ~]# env > > SHELL=/bin/bash > > XORP_FINDER_SERVER_ADDRESS=20.1.1.1 > > XORP_FINDER_CLIENT_ADDRESS=20.1.1.2 > > .......... > > ///////////////////////////////////////////////////////////// > > > > > > Step 4: Run xorp_rtrmgr: > > [root at 20.1.1.1 rtrmgr]# ./xorp_rtrmgr -a 20.1.1.2 >debug [ 2008/09/11 > > 16:52:47 INFO xorp_rtrmgr:2878 IPC +477 sockutil.cc > > set_preferred_ipv4_addr ] Changing to address 20.1.1.1 for IPv4 based > > XRL communication. > > [ 2008/09/11 16:52:47 INFO xorp_rtrmgr:2878 RTRMGR +239 > > master_conf_tree.cc execute ] Changed modules: interfaces, firewall, > > fea, rib, policy, ospf4 [ 2008/09/11 16:52:47 INFO xorp_rtrmgr:2878 > > RTRMGR +96 module_manager.cc execute ] Executing module: interfaces > > (fea/xorp_fea) [ 2008/09/11 16:52:49 INFO xorp_rtrmgr:2878 RTRMGR +96 > > module_manager.cc execute ] Executing module: firewall (fea/xorp_fea) > > [ 2008/09/11 16:52:53 INFO xorp_rtrmgr:2878 RTRMGR +96 > > module_manager.cc execute ] Executing module: fea > > (static_routes/xorp_static_routes) > > [ 2008/09/11 16:52:59 INFO xorp_rtrmgr:2878 RTRMGR +96 > > module_manager.cc execute ] Executing module: rib (rib/xorp_rib) [ > > 2008/09/11 16:53:01 INFO xorp_rtrmgr:2878 RTRMGR +96 > > module_manager.cc execute ] Executing module: policy > > (policy/xorp_policy) [ 2008/09/11 16:53:03 INFO xorp_rtrmgr:2878 > > RTRMGR +96 module_manager.cc execute ] Executing module: ospf4 > > (ospf/xorp_ospfv2) [ 2008/09/11 16:53:05 INFO xorp_rtrmgr:2878 RTRMGR > > +2228 task.cc run_task ] No more tasks to run > > > > When xorp_fea invoked at 20.1.1.2,the following two lines came up: > > [ 2008/09/11 16:53:50 INFO xorp_rtrmgr:2878 RTRMGR +275 > > module_manager.cc module_exited ] Module normal exit: fea [ 2008/09/11 > > 16:53:50 ERROR xorp_rtrmgr:2878 LIBXORP +717 asyncio.cc > > complete_transfer ] Write error 104 > > ///////////////////////////////////////////////////////////// > > > > > > [root at 20.1.1.1 ~]# ps -a > > PID TTY TIME CMD > > 2878 pts/0 00:00:01 xorp_rtrmgr > > 2879 pts/0 00:00:00 xorp_fea > > 2882 pts/0 00:00:00 xorp_rib > > 2883 pts/0 00:00:00 xorp_policy > > 2885 pts/0 00:00:00 xorp_ospfv2 > > 2890 pts/1 00:00:00 ps > > ///////////////////////////////////////////////////////////// > > > > > > > > Step 5: Run xorp_fea: > > [root at 20.1.1.2 fea]# ./xorp_fea > > [ 2008/09/11 15:51:14 INFO xorp_fea IPC ] Changing to address 20.1.1.2 > > for > > IPv4 based XRL communication. > > [ 2008/09/11 15:51:14 INFO xorp_fea IPC ] Changing to address 20.1.1.2 > > for > > IPv4 based XRL communication. > > [ 2008/09/11 15:51:14 INFO xorp_fea IPC ] Changing to address 20.1.1.2 > > for > > IPv4 based XRL communication. > > [ 2008/09/11 15:51:14 INFO xorp_fea IPC ] Changing to address 20.1.1.2 > > for > > IPv4 based XRL communication. > > [ 2008/09/11 15:51:14 INFO xorp_fea MFEA ] MFEA enabled [ 2008/09/11 > > 15:51:14 INFO xorp_fea MFEA ] CLI enabled [ 2008/09/11 15:51:14 INFO > > xorp_fea MFEA ] CLI started [ 2008/09/11 15:51:14 INFO xorp_fea MFEA ] > > MFEA enabled [ 2008/09/11 15:51:14 INFO xorp_fea MFEA ] CLI enabled [ > > 2008/09/11 15:51:14 INFO xorp_fea MFEA ] CLI started [ 2008/09/11 > > 15:51:14 FATAL xorp_fea:2610 MFEA +519 xrl_mfea_node.cc > > cli_manager_client_send_add_cli_command_cb ] Cannot add a command to > > CLI > > manager: 102 Command failed Cannot install command 'show mfea': Error > > installing 'show mfea' on '': Command 'mfea' already installed > > Aborted ///////////////////////////////////////////////////////////// > > > > > > > > > > > > ///////////////////////////////////////////////////////////// > > the config.boot used at 20.1.1.1: > > > > /* $XORP: xorp/rtrmgr/config/ospfv2.boot,v 1.1 2007/08/29 06:49:43 > > pavlin Exp $ */ > > > > interfaces { > > > > interface eth0 { > > disable: false > > discard: false > > vif eth0 { > > disable: false > > address 20.1.1.1 { > > prefix-length: 24 > > broadcast: 20.1.1.255 > > disable: false > > } > > } > > } > > > > > > interface eth1 { > > disable: false > > discard: false > > vif eth1 { > > disable: false > > address 30.1.1.1 { > > prefix-length: 24 > > broadcast: 30.1.1.255 > > disable: false > > } > > } > > } > > > > } > > > > fea { > > unicast-forwarding4 { > > disable: false > > } > > } > > > > > > /* > > plumbing{ > > mfea4{ > > disable: true > > } > > mfea6{ > > disable: true > > } > > } > > */ > > > > > > protocols { > > > > ospf4 { > > router-id: 30.1.1.1 > > area 0.0.0.0 { > > interface eth0 { > > link-type: "broadcast" > > vif eth0 { > > address 20.1.1.1 { > > disable: false > > } > > } > > } > > > > interface eth1 { > > link-type: "broadcast" > > vif eth1 { > > address 30.1.1.1 { > > disable: false > > } > > } > > } > > > > } > > > > > > traceoptions { > > flag { > > all { > > disable: false > > } > > } > > } > > } > > } > > ///////////////////////////////////////////////////////////// > > > > > > I have also tried the script way, but failed either. The xorp_fea does > > be invoked by the remote xorp_rtrmgr,but exit after about 20 seconds. > > > > I saved the following script as file xorp_fea and replaced the one at > > xorp-1.5/fea/, and made sure that the fea.tp stay unchanged. > > > > #!/bin/sh > > # > > ssh 20.1.1.2 env XORP_FINDER_SERVER_ADDRESS=20.1.1.1 > > XORP_FINDER_CLIENT_ADDRESS=20.1.1.2 /home/Martin/xorp-1.5/fea/xorp_fea > > > > > > > > > > -----Original Message----- > > From: Pavlin Radoslavov [mailto:pavlin at ICSI.Berkeley.EDU] > > Sent: Thursday, September 11, 2008 1:07 AM > > To: Mingcy.Xu > > Cc: Xorp-Users > > Subject: Re: [Xorp-users] How to notify the OSPF process to use FEA on > > a different machine? > > > > Mingcy.Xu wrote: > > > > > Hi, > > > > > > As described in the FEA document, the forwarding plane may be > > > distributed across multiple machines. So it must be possible to run > > > the OSFP process on one machine with its FEA disabled, and to run > > > its associated FEA on another machine. > > > > > > But how to configure this? How to write the configuration file? It > > > seems that no XORP documents have covered this. Anybody can help me? > > > > You configure XORP as usual, and you need to do a bit of extra work to > > start the FEA on a remote machine. > > > > Please see the following email for details: > > http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-October/002 > > 134.ht > > ml > > > > Note that the example in that email is how to run static_routes on a > > remote machine, but the solution is basically same for running the > > FEA. A small clarification re. the instructions: the sample script > > that is at the end of the above email should be named fea/xorp_fea, > > and the real xorp_fea binary should be placed on the remote host. > > > > Please let us know how it goes. > > > > Pavlin > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From jfs at computer.org Sat Sep 13 15:27:04 2008 From: jfs at computer.org (Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?=) Date: Sun, 14 Sep 2008 00:27:04 +0200 Subject: [Xorp-users] Debian packages of Xorp 1.5 (+patches) available Message-ID: <20080913222703.GA7060@javifsp.no-ip.org> [ Hopefully this is useful for some Xorp users ] The recent stable release of Xorp (1.5) is now available in Debian's 'unstable' distribution, replacing the CVS-based released previously being distributed. The Debian v1.5 package includes some fixes that have been introduced after the release, such as a fix IPv6 multicast issue that prevents MLD from running in Linux kernels 2.6.26 and above. The Debian 'testing' (aka 'lenny') distribution is currently 'frozen' in preparation for the next Debian release, which means that no changes in packages are currently introduced in testing (from unstable). However, the Debian release team members have approved this version for Lenny so that it will be included in the next Debian release. Jolly! Needless to say, the Debian maintainers would be very grateful if users tested the Debian packages and reported any errors in the Debian Bug Tracking System. More information about the Debian Xorp packages can be found at: http://packages.qa.debian.org/x/xorp.html Happy hacking! 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/20080914/eaa5ff8d/attachment.bin From pavlin at ICSI.Berkeley.EDU Sun Sep 14 14:33:05 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Sun, 14 Sep 2008 14:33:05 -0700 Subject: [Xorp-users] Debian packages of Xorp 1.5 (+patches) available In-Reply-To: <20080913222703.GA7060@javifsp.no-ip.org> References: <20080913222703.GA7060@javifsp.no-ip.org> Message-ID: <200809142133.m8ELX50X011984@fruitcake.ICSI.Berkeley.EDU> Great! Thank You!! Pavlin Javier Fern?ndez-Sanguino Pe?a wrote: > > [ Hopefully this is useful for some Xorp users ] > > The recent stable release of Xorp (1.5) is now available in Debian's > 'unstable' distribution, replacing the CVS-based released previously being > distributed. The Debian v1.5 package includes some fixes that have been > introduced after the release, such as a fix IPv6 multicast issue that > prevents MLD from running in Linux kernels 2.6.26 and above. > > The Debian 'testing' (aka 'lenny') distribution is currently 'frozen' in > preparation for the next Debian release, which means that no changes in > packages are currently introduced in testing (from unstable). However, the > Debian release team members have approved this version for Lenny so that it > will be included in the next Debian release. Jolly! > > Needless to say, the Debian maintainers would be very grateful if users > tested the Debian packages and reported any errors in the Debian Bug Tracking > System. > > More information about the Debian Xorp packages can be found at: > http://packages.qa.debian.org/x/xorp.html > > > Happy hacking! > > Javier > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From mingcy.xu at gmail.com Mon Sep 15 17:40:56 2008 From: mingcy.xu at gmail.com (Mingcy.Xu) Date: Tue, 16 Sep 2008 08:40:56 +0800 Subject: [Xorp-users] How to notify the OSPF process to use FEA on a different machine? In-Reply-To: <200809121713.m8CHDKYw020611@fruitcake.ICSI.Berkeley.EDU> References: <200809101707.m8AH7K5Q027027@fruitcake.ICSI.Berkeley.EDU> <03C0666354DA47D3A08097B968660168@wovensystems.local> <200809111850.m8BIoZv4025973@fruitcake.ICSI.Berkeley.EDU> <200809112125.m8BLP010015662@fruitcake.ICSI.Berkeley.EDU> <9F59FA64A6AE456B821982D3B0D16EEE@wovensystems.local> <200809121713.m8CHDKYw020611@fruitcake.ICSI.Berkeley.EDU> Message-ID: Hi Pavlin, The script approach works fine after I excluded the eth0 from the XORP configuration. Thanks a lot for your great help. I do feel sorry for having taken so much of your time. Have a nice day. Regards, Mingcy.Xu -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin at ICSI.Berkeley.EDU] Sent: Saturday, September 13, 2008 1:13 AM To: Mingcy.Xu Cc: 'Pavlin Radoslavov'; Xorp-Users Subject: Re: [Xorp-users] How to notify the OSPF process to use FEA on a different machine? Please try the same experiment (i.e., by using the help of the ssh script), but exclude eth0 from your XORP configuration. This interface is your control communication channel to the fea and it has to be stable. We want to avoid any changes to the remote host (xorp_fea) that might affect this interface configuration or the routing between the xorp_fea and xorp_rtrmgr hosts. To make things simpler and easier to debug, I'd suggest that initially you use static routes instead of OSPF, so it is obvious what is happening (i.e., what routes are added to the xorp_fea kernel). Pavlin Mingcy.Xu wrote: > I tried the script approach but got a different result. The following > is the detailed information. > > Host Lab_62(10.20.1.1) : xorp_rtrmgr > Host Lab_59(10.20.1.2) : xorp_fea > > > 1. On the FEA host I have XORP built inside the > /home/Martin/xorp-1.5 directory > > > 2. Create the following script and place it instead of the > fea/xorp_fea binary on the rtrmgr side: > > #!/bin/sh > ssh root at 10.20.1.2 'env XORP_FINDER_SERVER_ADDRESS=10.20.1.1 > XORP_FINDER_CLIENT_ADDRESS=10.20.1.2 /home/Martin/xorp-1.5/fea/xorp_fea' > > Note that 10.20.1.1 is the IP address of the rtrmgr (local) > host, and 10.20.1.2 is the IP address of the fea (remote)host. > > When I run this script on rtrmgr host, I did notice the fea process > was started on the FEA host. > > > 3. Setup environmental variables for the Finder on the rtrmgr host: > > [root at Lab_62 xorp-1.5]# env |more > HOSTNAME=Lab_62 > TERM=vt100 > SHELL=/bin/bash > XORP_FINDER_SERVER_ADDRESS=10.20.1.1 > XORP_FINDER_CLIENT_ADDRESS=10.20.1.1 > ... > /////////////////////////////////////////// > > 4. Make sure that ssh without typing a password works to the fea host. > > [root at Lab_62 ~]# ssh 10.20.1.2 > Last login: Fri Sep 12 13:43:01 2008 from 10.20.1.1 > [root at Lab_59 ~]# > (No password needed.) > > To achieve this,I use the following scheme: > 1. Run ssh-keygen on the rtrmgr host to create an RSA key-pair > with an empty password. > 2. Copy the public key to the FEA host. > 3. Add the public key to the /root/.ssh/authorized_keys file on > the FEA host. > > > 5. Start the rtrmgr on the local host: > (the config.boot file used is listed below.) > > [root at Lab_62 rtrmgr]# ./xorp_rtrmgr -a 10.20.1.2 [ 2008/09/12 15:02:05 > INFO xorp_rtrmgr:3348 IPC +477 sockutil.cc set_preferred_ipv4_addr ] > Changing to address 10.20.1.1 for IPv4 based XRL communication. > [ 2008/09/12 15:02:05 INFO xorp_rtrmgr:3348 RTRMGR +239 > master_conf_tree.cc execute ] Changed modules: interfaces, firewall, > fea, rib, policy, ospf4 [ 2008/09/12 15:02:06 INFO xorp_rtrmgr:3348 > RTRMGR +96 module_manager.cc execute ] Executing module: interfaces > (fea/xorp_fea) [ 2008/09/12 15:02:08 INFO xorp_rtrmgr:3348 RTRMGR +96 > module_manager.cc execute ] Executing module: firewall (fea/xorp_fea) > [ 2008/09/12 15:02:12 INFO xorp_rtrmgr:3348 RTRMGR +96 > module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ > 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 XRL +639 xrl_pf_stcp.cc > die ] XrlPFSTCPSender died: Keepalive timeout [ 2008/09/12 15:02:28 > ERROR xorp_rtrmgr:3348 RTRMGR +1400 task.cc execute_done ] 210 > Transport failed [ 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 RTRMGR > +1998 task.cc task_fail ] Shutting down fatally wounded process (fea) > [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +171 > module_manager.cc terminate ] Terminating module: fea [ 2008/09/12 > 15:02:28 ERROR xorp_rtrmgr:3348 RTRMGR +681 master_conf_tree.cc > commit_pass2_done ] Commit failed: 210 Transport failed [ 2008/09/12 > 15:02:28 ERROR xorp_rtrmgr:3348 RTRMGR +251 master_conf_tree.cc > config_done ] Configuration failed: 210 Transport failed [ 2008/09/12 > 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +2228 task.cc run_task ] No > more tasks to run [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR > +171 module_manager.cc terminate ] Terminating module: firewall [ > 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +171 > module_manager.cc terminate ] Terminating module: interfaces [ > 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +194 > module_manager.cc terminate ] Killing module: interfaces Killed by > signal 15. > [ 2008/09/12 15:02:28 ERROR xorp_rtrmgr:3348 RTRMGR +747 > module_manager.cc done_cb ] Command > "/home/Martin/xorp-1.5/fea/xorp_fea": terminated with signal 15. > [ 2008/09/12 15:02:28 INFO xorp_rtrmgr:3348 RTRMGR +282 > module_manager.cc module_exited ] Module killed during shutdown: > interfaces > [root at Lab_62 rtrmgr]# > [root at Lab_62 rtrmgr]# > > > At this point, I encountered something strange: > > 1) the rtrmgr host could not reach FEA host. Its route talbe stayed > unchanged. > 2) the FEA host could still reach rtrmgr host. But when I tried to ssh > rtrmgr host( #ssh 10.20.1.1), I got > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone could be eavesdropping on you right now (man-in-the-middle attack)! > It is also possible that the RSA host key has just been changed. > The fingerprint for the RSA key sent by the remote host is > 5e:00:30:a9:72:3e:89:de:4a:07:4e:d8:ca:f7:ae:a6. > Please contact your system administrator. > Add correct host key in /root/.ssh/known_hosts to get rid of this message. > Offending key in /root/.ssh/known_hosts:3 RSA host key for 20.1.1.1 > has changed and you have requested strict checking. > Host key verification failed. > > 3) After I rebooted the FEA host and deleted its > /root/.ssh/known_hosts, the above two problems were resolved. > > > I have done this experiment for four times, each time I got the same result. > > > Hi, Pavlin, do you have any doubt that running xorp_static_routes on a > separate machine with xorp_rtrmgr might be a little different from the > situation regarding xorp_fea? > > > > The config.boot used: > > /* $XORP: xorp/rtrmgr/config/ospfv2.boot,v 1.1 2007/08/29 06:49:43 > pavlin Exp $ */ > > policy { > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > > interfaces { > > interface eth0 { > disable: false > discard: false > vif eth0 { > disable: false > address 10.20.1.1 { > prefix-length: 24 > broadcast: 10.20.1.255 > disable: false > } > } > } > > interface eth1 { > disable: false > discard: false > vif eth1 { > disable: false > address 10.30.1.1 { > prefix-length: 24 > broadcast: 10.30.1.255 > disable: false > } > } > } > > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > protocols { > > ospf4 { > router-id: 10.20.1.1 > area 0.0.0.0 { > interface eth0 { > link-type: "broadcast" > vif eth0 { > address 10.20.1.1 { > disable: false > } > } > } > > interface eth1 { > link-type: "broadcast" > vif eth1 { > address 10.30.1.1 { > disable: false > } > } > } > > } > > traceoptions { > flag { > all { > disable: false > } > } > } > > export: "connected" > } > } > > > > > > > -----Original Message----- > From: Pavlin Radoslavov [mailto:pavlin at ICSI.Berkeley.EDU] > Sent: Friday, September 12, 2008 5:25 AM > To: Pavlin Radoslavov > Cc: Mingcy.Xu > Subject: Re: [Xorp-users] How to notify the OSPF process to use FEA on > a different machine? > > > I wonder why replacing xorp_fea with the script didn't work for you. > > Later this afternoon I will do some experiments to see what happens. > > I just tried the script approach, and it worked for me. > Here is what I did: > > 1. On the fea host I have XORP precompiled inside the > /home/pavlin/cxorp directory > > 2. Create the following script and place it instead of the > fea/xorp_fea binary on the rtrmgr side: > > #!/bin/sh > ssh vm-freebsd env XORP_FINDER_SERVER_ADDRESS=192.168.113.1 \ > XORP_FINDER_CLIENT_ADDRESS=192.168.113.130 > /home/pavlin/cxorp/fea/xorp_fea > > Note that 192.168.113.1 is the IP address of the rtrmgr (local) > host, and 192.168.113.130 is the IP address of the fea (remote) > host. > > 3. Setup the following environmental variables on the rtrmgr host: > setenv XORP_FINDER_SERVER_ADDRESS 192.168.113.1 setenv > XORP_FINDER_CLIENT_ADDRESS 192.168.113.1 > > 4. Make sure that ssh without typing a password works to the fea > host (I use ssh-agent), and that running the fea/xorp_fea script > actually executes the xorp_fea binary on the remote fea host: > > pavlin at rtrmgr[49] /Users/pavlin/cxorp/fea/xorp_fea [ 2008/09/11 > 14:20:11 INFO xorp_fea IPC ] Changing to address 192.168.113.130 for > IPv4 based XRL communication. > [ 2008/09/11 14:20:11 INFO xorp_fea IPC ] Changing to address > 192.168.113.130 for IPv4 based XRL communication. > [ 2008/09/11 14:20:11 INFO xorp_fea IPC ] Changing to address > 192.168.113.130 for IPv4 based XRL communication. > [ 2008/09/11 14:20:11 INFO xorp_fea IPC ] Changing to address > 192.168.113.130 for IPv4 based XRL communication. > [ 2008/09/11 14:20:11 ERROR xorp_fea:72561 LIBCOMM +609 > /home/pavlin/xorp/libcomm/comm_sock.c comm_sock_connect4 ] Error > connecting socket (family = 2, remote_addr = 192.168.113.1, remote_port = 19999): > Connection refused [ 2008/09/11 14:20:11 ERROR xorp_fea:72561 FINDER > +384 /home/pavlin/xorp/libxipc/finder_tcp_messenger.cc do_auto_connect > ] Failed to connect to 192.168.113.1/19999: Connection refused [ > 2008/09/11 14:20:11 ERROR xorp_fea:72561 LIBCOMM +609 > /home/pavlin/xorp/libcomm/comm_sock.c > comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr > = 192.168.113.1, remote_port = 19999): Connection refused ... > (Type Ctrl-C to stop) > > 5. Start the rtrmgr on the local host: > ./xorp_rtrmgr -a 192.168.113.130 -b static.boot > > > Please let me know how it goes. > Pavlin > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From Jackalynn.Sproat at gdcanada.com Wed Sep 17 13:18:41 2008 From: Jackalynn.Sproat at gdcanada.com (Sproat, Jackalynn) Date: Wed, 17 Sep 2008 14:18:41 -0600 Subject: [Xorp-users] Route redistribution... In-Reply-To: <48C99929.4090208@incunabulum.net> References: <6D5FB6745F80EC45986ACD47D70799AD0412528F@CGYSVW100.gdcan.com> <48C560CC.4060902@incunabulum.net> <6D5FB6745F80EC45986ACD47D70799AD041252A4@CGYSVW100.gdcan.com> <48C99929.4090208@incunabulum.net> Message-ID: <6D5FB6745F80EC45986ACD47D70799AD041252BE@CGYSVW100.gdcan.com> I am trying to get RIP-OSPF route redistribution working and not having much success. Hoping someone can shed some light on the following: Three Linux 2.6.24-19 generic xorp routers: --|R1|--eth1---.---eth2--|R2|--eth3---.--eth4--|R3|--- Configuration on R1: interfaces { interface eth1 { description: "Rip LAN 1" disable: false vif eth1 { disable: false address 10.1.0.5 { prefix-length: 24 broadcast: 10.1.0.255 } } } } fea { unicast-forwarding4 { disable: false forwarding-entries { } } } /* end fea */ protocols { rip { interface eth1 { vif eth1 { address 10.1.0.5 { } } } } } Configuration on R2: interfaces { interface eth2 { description: "Rip LAN 1" disable: false vif eth2 { disable: false address 10.1.0.50 { prefix-length: 24 broadcast: 10.1.0.255 } } } interface eth3 { description: "OSPF LAN 1" disable: false vif eth3 { disable: false address 10.10.0.50 { prefix-length: 24 broadcast: 10.10.0.255 } } } } fea { unicast-forwarding4 { disable: false forwarding-entries { } } } /* end fea */ policy { policy-statement connected-to-rip { term export { from { protocol: "connected" } then { accept } } } } protocols { rip { export: "connected-to-rip" /* 10.10.0.x (connected,OSPF route)is advertised via rip*/ interface eth2 { vif eth2 { address 10.1.0.50 { } } } } ospf { router-id: 10.10.0.50 area 0.0.0.0 { interface eth3 { vif eth3 { address 10.10.0.50 { } } } } } } Configuration on R3: interfaces { interface eth4 { description: "OSPF LAN 1" disable: false vif eth4 { disable: false address 10.10.0.5 { prefix-length: 24 broadcast: 10.10.0.255 } } } } fea { unicast-forwarding4 { disable: false forwarding-entries { } } } /* end fea */ protocols { ospf { router-id: 10.10.0.5 area 0.0.0.0 { interface eth4 { vif eth4 { address 10.10.0.5 { } } } } } } In summary: |R1|-10.1.0.5--rip---10.1.0.50-|R2|-10.10.0.50--ospf---10.10.0.5-|R3| R1 learns of the 10.10.0.x subnet via R2 exporting all "connected routes" into rip. However, R2 does not by default advertise (export) it's "connected" rip subnet to its OSPF neighbors. I.e., R3 doesn't have a route to 10.1.0.0 network in routing table. Is this expected? Therefore, I can either: 1. have R2 export "connected" to ospf (similar to how it how it is redistributing routes for connected interfaces into rip. NOTE: However if the network is expanded - learnt ospf routes would not be redistributed; only "connected". So, a better option: 2. have R2 export rip into ospf, by adding the following policy: policy { policy-statement rip-to-ospf { term export { from { protocol: "rip" } then { accept } } } } protocols { ospf { router-id: 10.10.0.50 export: "rip-to-ospf" area 0.0.0.0 { interface eth3 { .... However, this didn't work. Why??? Do I have to set the OSPF "ebit" to true or false when exporting RIP entries to OSPF? Should export command be inside "area 0.0.0.0{}"? So, then I decided to try option 1 on R2: policy { policy-statement connected-to-ospf { term export { from { protocol: "connected" } then { accept } } } } ospf { router-id: 10.10.0.50 export: "connected-to-ospf" area 0.0.0.0 { interface eth3 { ..... This worked. I.e., R3 learnt of route to 10.1.0.x via redistribution of connected routes into OSPF. However, R1 no longer had route to 10.10.0.x eventhough redistribution of connected-to-rip was still configured. Why is this? Cheers, Jackie The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. Thank you. From bms at incunabulum.net Wed Sep 17 16:55:08 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 18 Sep 2008 00:55:08 +0100 Subject: [Xorp-users] Route redistribution... In-Reply-To: <6D5FB6745F80EC45986ACD47D70799AD041252BE@CGYSVW100.gdcan.com> References: <6D5FB6745F80EC45986ACD47D70799AD0412528F@CGYSVW100.gdcan.com> <48C560CC.4060902@incunabulum.net> <6D5FB6745F80EC45986ACD47D70799AD041252A4@CGYSVW100.gdcan.com> <48C99929.4090208@incunabulum.net> <6D5FB6745F80EC45986ACD47D70799AD041252BE@CGYSVW100.gdcan.com> Message-ID: <48D198DC.2070207@incunabulum.net> Sproat, Jackalynn wrote: > ... > |R1|-10.1.0.5--rip---10.1.0.50-|R2|-10.10.0.50--ospf---10.10.0.5-|R3| > > R1 learns of the 10.10.0.x subnet via R2 exporting all "connected > routes" into rip. > However, R2 does not by default advertise (export) it's "connected" rip > subnet to its OSPF neighbors. I.e., R3 doesn't have a route to 10.1.0.0 > network in routing table. Is this expected? > Yup, 10.1.0.0/24 is not part of any OSPF area in the first set of configs, nor is any external route explicitly redistributed for it -- so there is no reason why it would appear in any LSAs. > Therefore, I can either: > ... > 2. have R2 export rip into ospf, by adding the following policy: > .. > However, this didn't work. Why??? Do I have to set the OSPF "ebit" to > true or false when exporting RIP entries to OSPF? Should export command > be inside "area 0.0.0.0{}"? > Area 0 has special meaning, i.e. "backbone". OSPF backbone routers expect the E-bit capability in HELLO by default. It looks like the policy you provided should work, however, off the top of my head, you wouldn't see 10.1.0.0/24 in RIP advertisements because that *is* the LAN that RIP is running on. Advertising a prefix *on* the LAN itself would clash with the other peers' "connected" route. If in doubt, capture packets. > ... > This worked. I.e., R3 learnt of route to 10.1.0.x via redistribution of > connected routes into OSPF. However, R1 no longer had route to > 10.10.0.x eventhough redistribution of connected-to-rip was still > configured. Why is this? > Did you remove the policy statement(s) which redist connected into RIP on R2? 10.10.0/24 is not part of any RIP config, and RIP needs to be explicitly told to advertise prefixes which weren't learned via RIP. thanks BMS From obonhomme at nerim.net Fri Sep 19 04:46:49 2008 From: obonhomme at nerim.net (Olivier BONHOMME) Date: Fri, 19 Sep 2008 13:46:49 +0200 Subject: [Xorp-users] OSPF Over GRE Tunnel using XORP Message-ID: <48D39129.8000306@nerim.net> Hello everybody, I am trying to set up an OSPF network between 2 routers. My problem is that my routers are only visible from each other considering a GRE tunnel. I tried to set up a XORP configuration but the Hello Messages are not sent in the GRE tunnel and my tunnel interface didn't join the 224.0.0.5 group. I would like to know if a such architecture (OSPF over GRE) is possible and if there is a specific clue in XORP configuration to do this ? Thanks for your answers Regards, Olivier BONHOMME From obonhomme at nerim.net Fri Sep 19 05:08:00 2008 From: obonhomme at nerim.net (Olivier BONHOMME) Date: Fri, 19 Sep 2008 14:08:00 +0200 Subject: [Xorp-users] OSPF Over GRE Tunnel using XORP In-Reply-To: <48D39346.4080204@macil.in> References: <48D39129.8000306@nerim.net> <48D39346.4080204@macil.in> Message-ID: <48D39620.8000802@nerim.net> A r v i n d k u m a r S a ?crit : > Did u add the 224.0.0.0 network on the systems where u r running the > application? Do you mean in the kernel routing table ? A thing like that : route -net add 224.0.0.0/8 dev tun0 ? From bms at incunabulum.net Fri Sep 19 06:30:20 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri, 19 Sep 2008 14:30:20 +0100 Subject: [Xorp-users] OSPF Over GRE Tunnel using XORP In-Reply-To: <48D39129.8000306@nerim.net> References: <48D39129.8000306@nerim.net> Message-ID: <48D3A96C.1040504@incunabulum.net> Olivier BONHOMME wrote: > I tried to set up a XORP configuration but the Hello Messages are not > sent in the GRE tunnel and my tunnel interface didn't join the 224.0.0.5 > group. > > I would like to know if a such architecture (OSPF over GRE) is possible > and if there is a specific clue in XORP configuration to do this ? > Sure, you can run OSPF over tunnels, however XORP has no specific support for tunnel interfaces. If your host operating system has tunnel driver support, you need to configure XORP to use the tunnel driver. It sounds like you've already done this. XORP does require that you assign addresses to the tunnel interface -- unnumbered interfaces are not supported. At least FreeBSD and Linux will set the MULTICAST flag on gre interfaces. You may wish to verify that the IGMP messages are going out on startup using a packet sniffer. thanks BMS From Jackalynn.Sproat at gdcanada.com Fri Sep 19 07:22:36 2008 From: Jackalynn.Sproat at gdcanada.com (Sproat, Jackalynn) Date: Fri, 19 Sep 2008 08:22:36 -0600 Subject: [Xorp-users] OLSR route redistribution in XORPv1.5 In-Reply-To: <48C560CC.4060902@incunabulum.net> References: <6D5FB6745F80EC45986ACD47D70799AD0412528F@CGYSVW100.gdcan.com> <48C560CC.4060902@incunabulum.net> Message-ID: <6D5FB6745F80EC45986ACD47D70799AD041252CE@CGYSVW100.gdcan.com> Hello, I just wanted to clarify what you meant by: "... experiment with the syntax for the various tags in etc/templates/olsr4.tp... to filter various announcements if going in the opposite direction (OLSR to OSPF or other protocol)." Why can't I just define an export policy similar to "ospf-to-olsr", but in the opposite direction? For example: %%% protocols { ospf4 { ... export: "olsr-to-ospf" ... } } policy { ... policy-statement olsr-to-ospf { term a { from { protocol: "olsr" } then { accept } } } ... } %%% Cheers, Jackie -----Original Message----- From: Bruce M Simpson [mailto:bms at incunabulum.net] Sent: Monday, September 08, 2008 11:29 AM To: Sproat, Jackalynn Cc: xorp-users at xorp.org Subject: Re: [Xorp-users] OLSR route redistribution in XORPv1.5 Sproat, Jackalynn wrote: > > Hello, > > I am new to XORP and am interested in redistributing routes between > XORP OLSR and XORP OSPF. > > At www.mail-archive.com/xorp-hackers at icir.org/msg00413.html > it > was mentioned that CenGen had success with exporting inot OSPF in > their testbed. I was just wondering how I can get more information > w.r.t to doing the same. For example, is this a simple as including > the statement export ospf on the OSLR router? Where in the .boot file > should this statement be inserted? > The OLSR implementation is a standard XORP routing process, which supports route redistribution using the standard mechanisms, and uses a similar syntax as the other processes (BGP, RIP etc). You need to define an export policy and include it like this: %%% protocols { olsr4 { ... export: "ospf-to-olsr" ... } } policy { ... policy-statement ospf-to-olsr { term a { from { protocol: "ospf" } then { accept } } } ... } %%% Currently the OLSR redist support doesn't allow you to specify a metric, as this isn't part of the OLSRv1 spec. ETX link metrics aren't supported however this support could be added at a later date if there is further interest. Also, the policy tags/varmap which xorp_olsr uses are not currently documented. You can try experimenting with the syntax for the various tags in etc/templates/olsr4.tp. These can be used to filter various announcements if going in the opposite direction (OLSR to OSPF or other protocol). For docs, see docs/olsr. You'll need LaTeX installed to build PDFs of the OLSR documentation. thanks BMS The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. Thank you. From bms at incunabulum.net Fri Sep 19 07:33:14 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri, 19 Sep 2008 15:33:14 +0100 Subject: [Xorp-users] OLSR route redistribution in XORPv1.5 In-Reply-To: <6D5FB6745F80EC45986ACD47D70799AD041252CE@CGYSVW100.gdcan.com> References: <6D5FB6745F80EC45986ACD47D70799AD0412528F@CGYSVW100.gdcan.com> <48C560CC.4060902@incunabulum.net> <6D5FB6745F80EC45986ACD47D70799AD041252CE@CGYSVW100.gdcan.com> Message-ID: <48D3B82A.7040007@incunabulum.net> Sproat, Jackalynn wrote: > I just wanted to clarify what you meant by: > > "... experiment with the syntax for the various > tags in etc/templates/olsr4.tp... to filter various > announcements if going in the opposite direction (OLSR to OSPF or other > protocol)." > > Why can't I just define an export policy similar to "ospf-to-olsr", but > in the opposite direction? You certainly can, but as with all routing protocols, information present in one might not be desired to be present in the other, which is why the policy tags mechanism exists. For example if you exported all the N1/N2 topology in a highly mobile environment, this might cause a lot of unnecessary route updates to be propagated into the protocol you are redistributing into, and with the policy you provided, that is what would happen. i.e. every time a one-hop or two-hop neighbour changed link status, this would cause an OSPF LSA to be advertised upstream with the E bit set, and if you are not redistributing into a stub area, that's a lot of route updates just because someone moved their laptop. Currently there is no hysteresis mechanism for this, nor any means of automatically inferring an aggregate prefix (all IPv4 OLSR node routes are /32), as nobody has needed it yet. > For example: > > %%% > protocols { > ospf4 { > ... > export: "olsr-to-ospf" > ... > } > } > > policy { > ... > policy-statement olsr-to-ospf { > term a { > from { > protocol: "olsr" > } > then { > accept > } > } > } > ... > } > %%% > Cheers, > Jackie > > -----Original Message----- > From: Bruce M Simpson [mailto:bms at incunabulum.net] > Sent: Monday, September 08, 2008 11:29 AM > To: Sproat, Jackalynn > Cc: xorp-users at xorp.org > Subject: Re: [Xorp-users] OLSR route redistribution in XORPv1.5 > > Sproat, Jackalynn wrote: > >> Hello, >> >> I am new to XORP and am interested in redistributing routes between >> XORP OLSR and XORP OSPF. >> >> At www.mail-archive.com/xorp-hackers at icir.org/msg00413.html >> it >> was mentioned that CenGen had success with exporting inot OSPF in >> their testbed. I was just wondering how I can get more information >> w.r.t to doing the same. For example, is this a simple as including >> the statement export ospf on the OSLR router? Where in the .boot file >> should this statement be inserted? >> >> > > The OLSR implementation is a standard XORP routing process, which > supports route redistribution using the standard mechanisms, and uses a > similar syntax as the other processes (BGP, RIP etc). > > You need to define an export policy and include it like this: > > %%% > protocols { > olsr4 { > ... > export: "ospf-to-olsr" > ... > } > } > > policy { > ... > policy-statement ospf-to-olsr { > term a { > from { > protocol: "ospf" > } > then { > accept > } > } > } > ... > } > %%% > > Currently the OLSR redist support doesn't allow you to specify a metric, > > as this isn't part of the OLSRv1 spec. ETX link metrics aren't supported > > however this support could be added at a later date if there is further > interest. > > Also, the policy tags/varmap which xorp_olsr uses are not currently > documented. You can try experimenting with the syntax for the various > tags in etc/templates/olsr4.tp. These can be used to filter various > announcements if going in the opposite direction (OLSR to OSPF or other > protocol). > > For docs, see docs/olsr. You'll need LaTeX installed to build PDFs of > the OLSR documentation. > > thanks > BMS > > The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. > Thank you. > > From yapingz at CS.Princeton.EDU Mon Sep 22 09:13:32 2008 From: yapingz at CS.Princeton.EDU (Yaping Zhu) Date: Mon, 22 Sep 2008 12:13:32 -0400 Subject: [Xorp-users] running IP multicast using xorp with click Message-ID: <007c01c91cce$2a3077f0$3c0ca8c0@IBM06886B7F48C> hi, I wonder if anybody knows how to run IP multicast using xorp with click. I only saw the following link that multicast package is available. http://read.cs.ucla.edu/click/packages/multicast does anybody can help to let me know: how can I get the package? better, where I can get a xorp and click config to run IP multicast? thanks a lot, Yaping -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080922/c96740ee/attachment.html From pavlin at ICSI.Berkeley.EDU Mon Sep 22 10:39:12 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Mon, 22 Sep 2008 10:39:12 -0700 Subject: [Xorp-users] running IP multicast using xorp with click In-Reply-To: <007c01c91cce$2a3077f0$3c0ca8c0@IBM06886B7F48C> References: <007c01c91cce$2a3077f0$3c0ca8c0@IBM06886B7F48C> Message-ID: <200809221739.m8MHdCkK007691@fruitcake.ICSI.Berkeley.EDU> Yaping Zhu wrote: > hi, > I wonder if anybody knows how to run IP multicast using xorp with click. I only saw the following link that multicast package is available. > http://read.cs.ucla.edu/click/packages/multicast > does anybody can help to let me know: > how can I get the package? > better, where I can get a xorp and click config to run IP multicast? I am not familiar with the above mentioned Click multicast package, but on the XORP side the answer is that XORP doesn't have any Click-specific support for IP multicast routing. Pavlin > thanks a lot, > Yaping_______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From yapingz at CS.Princeton.EDU Mon Sep 22 11:47:13 2008 From: yapingz at CS.Princeton.EDU (Yaping Zhu) Date: Mon, 22 Sep 2008 14:47:13 -0400 Subject: [Xorp-users] running IP multicast using xorp with click References: <007c01c91cce$2a3077f0$3c0ca8c0@IBM06886B7F48C> <200809221739.m8MHdCkK007691@fruitcake.ICSI.Berkeley.EDU> Message-ID: <002801c91ce3$a31dc180$3c0ca8c0@IBM06886B7F48C> hi Pavlin, I have some quick followup questions for you: for the control plane, xorp supports the following: - IGMP group management protocol: for group registration and management - PIM-SM: for constructing/compute multicast tree, and construct fwd table for multicast and, the only interface between xorp and Click (or whatever data plane environment) is the multicast forward table, is it correct? so that the data plane (of Click) has to support: multicast forwarding. when receiving packets destinated to multicast group address, it looks up the forwarding table, and copy the packets through multiple interfaces for the group. is it also correct? thanks, Yaping ----- Original Message ----- From: "Pavlin Radoslavov" To: "Yaping Zhu" Cc: Sent: Monday, September 22, 2008 1:39 PM Subject: Re: [Xorp-users] running IP multicast using xorp with click > Yaping Zhu wrote: > >> hi, >> I wonder if anybody knows how to run IP multicast using xorp with click. >> I only saw the following link that multicast package is available. >> http://read.cs.ucla.edu/click/packages/multicast >> does anybody can help to let me know: >> how can I get the package? >> better, where I can get a xorp and click config to run IP multicast? > > I am not familiar with the above mentioned Click multicast package, > but on the XORP side the answer is that XORP doesn't have any > Click-specific support for IP multicast routing. > > Pavlin > >> thanks a lot, >> Yaping_______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From bms at ICSI.Berkeley.EDU Mon Sep 22 12:37:41 2008 From: bms at ICSI.Berkeley.EDU (Bruce M. Simpson) Date: Mon, 22 Sep 2008 20:37:41 +0100 Subject: [Xorp-users] running IP multicast using xorp with click In-Reply-To: <002801c91ce3$a31dc180$3c0ca8c0@IBM06886B7F48C> References: <007c01c91cce$2a3077f0$3c0ca8c0@IBM06886B7F48C> <200809221739.m8MHdCkK007691@fruitcake.ICSI.Berkeley.EDU> <002801c91ce3$a31dc180$3c0ca8c0@IBM06886B7F48C> Message-ID: <48D7F405.2010709@icsi.berkeley.edu> Yaping Zhu wrote: > ... > and, the only interface between xorp and Click (or whatever data plane > environment) is the multicast forward table, is it correct? > > so that the data plane (of Click) has to support: multicast forwarding. when > receiving packets destinated to multicast group address, it looks up the > forwarding table, and copy the packets through multiple interfaces for the > group. is it also correct? > It seems like the following work would need to be done: * implement Click elements which can run to implement multicast forwarding. Someone's already done this for IPv6, IPv4 may require work: http://read.cs.ucla.edu/click/packages/multicast6 * implement the parts of the XORP MFEA necessary to communicate with Click. Currently these don't exist. * The autoconf scripts in config/ would need to be updated to learn about the existence of Click elements supporting a new multicast forwarding API. * The Click version of the FEA process would need to be modified to pick up the new MFEA back-end supporting Click. XORP's MFEA uses the IP MROUTING family of interfaces which exist in the BSDs and which are also supported by Linux to talk to the multicast forwarding cache. Pavlin may have more to say on this as most likely the MFEA would need refactoring to accomodate multiple APIs. Windows, for example, uses a completely different API which involves a number of userland DLLs. This is not an insignificant amount of work, as it requires refactoring the MFEA, however, it's not a huge project either. cheers BMS From yapingz at CS.Princeton.EDU Mon Sep 22 14:23:11 2008 From: yapingz at CS.Princeton.EDU (Yaping Zhu) Date: Mon, 22 Sep 2008 17:23:11 -0400 Subject: [Xorp-users] running IP multicast using xorp with click References: <007c01c91cce$2a3077f0$3c0ca8c0@IBM06886B7F48C> <200809221739.m8MHdCkK007691@fruitcake.ICSI.Berkeley.EDU> <002801c91ce3$a31dc180$3c0ca8c0@IBM06886B7F48C> <48D7F405.2010709@icsi.berkeley.edu> Message-ID: <000801c91cf9$6cc516e0$aea9b48c@IBM06886B7F48C> hi Bruce, thanks a lot! Yaping ----- Original Message ----- From: "Bruce M. Simpson" To: "Yaping Zhu" Cc: "Pavlin Radoslavov" ; Sent: Monday, September 22, 2008 3:37 PM Subject: Re: [Xorp-users] running IP multicast using xorp with click > Yaping Zhu wrote: >> ... >> and, the only interface between xorp and Click (or whatever data plane >> environment) is the multicast forward table, is it correct? >> >> so that the data plane (of Click) has to support: multicast forwarding. >> when receiving packets destinated to multicast group address, it looks up >> the forwarding table, and copy the packets through multiple interfaces >> for the group. is it also correct? >> > > It seems like the following work would need to be done: > > * implement Click elements which can run to implement multicast > forwarding. > Someone's already done this for IPv6, IPv4 may require work: > http://read.cs.ucla.edu/click/packages/multicast6 > > * implement the parts of the XORP MFEA necessary to communicate with > Click. > Currently these don't exist. > > * The autoconf scripts in config/ would need to be updated to learn about > the existence of Click elements supporting a new multicast forwarding API. > > * The Click version of the FEA process would need to be modified to pick > up the new MFEA back-end supporting Click. > > XORP's MFEA uses the IP MROUTING family of interfaces which exist in the > BSDs and which are also supported by Linux to talk to the multicast > forwarding cache. > > Pavlin may have more to say on this as most likely the MFEA would need > refactoring to accomodate multiple APIs. Windows, for example, uses a > completely different API which involves a number of userland DLLs. > > This is not an insignificant amount of work, as it requires refactoring > the MFEA, however, it's not a huge project either. > > cheers > BMS >